Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

374 Глава 7

25. Software unit test coverage and adequacy. / H.Zhu., P.A.V.Hall, J.H.R.May // ACM Comput-

ing Surveys.-1997.- V.29.-N.4. -P. 336-427.

26. Software testing based on formal specifications: a theory and tool. / G.Bernot., M.C.Gaudel,

B.Marre // Software Engineering Journal.-1991.- November. – P. 287-405.

27. Dick J., Faivre A. Automating the generation and sequencing of test cases from model-based

specification. // FME’93: Industrial-Strenght formal method, LNCS 670, Springer Vertag,

1993. -P. 268-284.

28. Horcher H., Peleska J. Using formal specifications to support software testing. // Software

Quality Journal.-1995.- № 4. – P. 309-327.

29. Липаев В.В. Тестирование программ. -М.: Радио и связь, 1986. -296 с.

30. Wendy W. Peng, Dolores R. Wallace. Software Error Analysis. // NIST Special Publication

500-209. - March, - 1993.

31. Аллен Э. Типичные ошибки проектирования. Библиотека программиста (Bug Patterns in

Java) /СПб.: Питер, 2003. – 224 с.

32. . Определение целей и задач инженерии надежности программного обеспечения. /

Г.Б.Мороз, Г.И.Коваль, Т.М.Коротун // Проблемы программирования. Вып.1, 1997.- С.

98-106.

33. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process. Addison-

Wesley, 1999. – 463 р.

34. Hartman A. Ten Years of Model Based Testing /http://react.cs.uni-sb.de/mbt2006/talks/

ModelBasedTestingSoberEvaluation.PDF

35. Макгрегор Дж., Сайкс Д. Тестирование объектно-ориентированного программного

обеспечения. Практическое пособие (A Practical Guide to Testing Object-Oriented Soft-

ware). ДИАСОФТ (ISBN 966-7992-12-8), 2002, 432 с.

36. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в со-

стояниях. – К.: Диалектика., 1993. – 240 с.

37. Crnkovic I., Larsson S., Chaudron M. Component-based Development Process and Compo-

nent Lifecycle./ http://www.mrtc.mdh.se/publications/0953.pdf

38. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Тестирование телекоммуникационных про-

токолов: проблемы и подходы. / Сети и системы связи online -

http://www.ccc.ru/magazine/depot/02_12/read.html?0303.htm 20023.pdfISO 9646

39. ISO 9646:1994. Information Theory - Open System Interconnection - Conformance Testing

Methodology and Framework.

40. Leveson N. Safeware: system safety and computers. Addison-Wesley Publishing Company,

1995. - 680 p.

41. Bach J. General Functionality and Stability Test Procedure.

http://www.satisfice.com/tools/procedure.pdf.

42. Функциональное тестирование программного обеспечения информационно-расчетного

типа. / Бернатович О.В., Коваль Г.И., Коротун Т.М.. // Проблемы программирования,

Вып. 3, 1998. -С. 51-58.

43. Hartman A. Ten Years of Model Based Testing. A Sober Evaluation - http://react.cs.uni-

sb.de/mbt2006/talks/ModelBasedTestingSoberEvaluation.PDF

44. Сортов А.А., Хорошилов А.В. Функциональное тестирование Web-приложений на ос-

нове технологии UniTesK. http://citforum.ru/SE/testing/func_testing/#1

45. Общий оценочный лист тестирования usability web-сайта http://software-testing.ru/lib/it-

online/site-usability-checklist.htm

Глава 7 375

46. Whittaker J.A. How to Break Web Software: Functional and Security Testing of Web

Applications and Web Services, Addison-Wesley Professional (ISBN 0-321-36944-0), 2006.

47. Nguyen H., Johnson R., Hackett M. Testing Applications on the Web (2nd Edition): Test

Planning for Mobile and Internet-Based Systems ( ISBN 0-471-20100-6)

48. Тестирование производительности Web-серверов http://www.sibinfo.ru/archive/news/

03_01_08/server_testing.html

49. Мельбурн Д., Джорм Д. Тестирование web-приложений "на проникновение" (часть 1)

(перевод Дмитрия Леонова) /http://www.bugtraq.ru/library

50. Стотлемайер Д. Тестирование Web-приложений //М.: «КУДИЦ-ОБРАЗ» (ISBN 5-

93378-064-2), 2003. - 240 с.

51. IEEE Std 1044:1993. Standard Classification for Software Anomalies. -21 p.

52. Dreger, Brian J. Function Point Analysis. New Jersey; Prentice-Hall Advanced Reference

Series, Computer Science; 1989.

53. ДСТУ 2851-94. Програмнi засоби ЕОМ. Документування результатiв випробувань.

54. Lutz R. et al. Applying Integrated Safety Analysis Techniques (Software FMEA and FTA) //

JPL D161168, Quality Assurance Office, 1988. - 15 p.

55. Daich G.T. et al. Software Test Technology Report. / STSC, August 1994. - P. 70.

56. Eckerson, W.W. Client-Server Test Tools: Client-Server Computing Has Created a Need for

Robust New Test Tools and Test Methodologies. //Open Information Systems.-1994.- V.9.-

№11. - P. 3-21.

376

Глава 8. МЕТОДЫ ОЦЕНКИ РАЗМЕРА ПРОГРАММНОЙ

СИСТЕМЫ

8.1. Методология анализа показателей функциональности

8.1.1. Истоки методологии FPA

Организации-разработчики программных систем в течение многих лет иска-

ли приемлемые количественные методы для измерения производительности труда,

оценивания эффективности процессов и управления затратами на разработку ПС.

Камнем преткновения было отсутствие надежной единицы измерения размера про-

граммного обеспечения. Такая, на первый взгляд очевидная метрика, как число

строк исходного кода SLOC (Source Lines of Code), не могла давать достоверные

результаты, поскольку не учитывала следующее:

• число строк исходного кода зависит от уровня мастерства программиста.

Фактически, чем выше мастерство программиста, тем меньшим количеством строк

кода ему удастся обойтись для реализации определенной функциональной возмож-

ности (или функциональности) ПС;

• высокоуровневые языки или языки визуального программирования тре-

буют гораздо меньшего числа строк кода, чем, например, язык Ассемблера или C

для отражения одной и той же функциональности. Достаточно представить себе два

приложения, имеющих одни и те же функциональные возможности (те же экраны,

отчеты, таблицы базы данных), но реализованные на разных языках, например, C и

Clarion. Очевидно, что существует обратная взаимосвязь между уровнем языка и

производственной выработкой программиста;

• фактическое число SLOC остается неизвестным до тех пор, пока проект

не будет почти завершен. Поэтому SLOC нельзя использовать для предварительной

оценки усилий на разработку и построения план-графика проекта;

• в программистском сообществе не достигнуто соглашения о методе под-

счета строк кода. Языковые конструкции, используемые, например, в Visual C++,

Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для

любых приложений, в том числе использующих комбинацию различных языков;

• заказчику сложно понять, каково соотношение указанных им функцио-

нальных и технических требований к ПС и объемов программистской работы.

Нужна была новая мера размера, применяемая унифицировано по всему ЖЦ

ПС, понятная заказчику и легко интерпретируемая в терминах прикладной области

его деятельности. И такая мера появилась в конце 70-х годов.

Однако нужно сразу отметить, что несмотря на проблемы, SLOC по-

прежнему остается той единицей измерения размера, к которой «приводятся» (в

которую конвертируются) результаты вычисления размера, выполненные другими

методами, для последующего использования в «старых» моделях трудоемкости,

надежности, тестирования, стоимости и др. Ее вполне можно также применять и

для определения размера ПС на завершающих стадиях разработки и при сопровож-

дении (разумеется, учитывая вышеуказанные замечания) [1].

Первой и наиболее удачной альтернативой методу подсчета исходных строк

кода стала разработанная в 1979 году Алланом Альбрехтом из IBM методология,

названная «Анализ показателей функциональности» (FPA, от Function Points Analy-

sis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не

Глава 8 377

«со стороны» ее внутренних свойств (таких, как SLOC). В результате анализа ис-

ходных требований к ПС и выяснения реальных потребностей пользователей опре-

деляется объем функциональных возможностей системы, показателями которых

служат функции обработки информации настолько низкого уровня, насколько они

укладываются в систему мышления пользователей, а кроме функций – данные, ко-

торые эти функции обрабатывают. Таким образом, методология FPA базируется на

идее декомпозиции функций и данных до предельно допустимого (с точки зрения

пользователя) уровня

. Объем функциональных возможностей ПС (далее просто

функциональный размер) определяется в так называемых условных единицах функ-

циональности, УЕФ (или FP – от Function Points).

В течение пяти лет с момента появления, методология FPA и метод расчета

размера отшлифовывались А. Альбрехтом и проходили практическую апробацию, а

в середине 80-х годов была создана Международная группа пользователей показа-

телей функциональности (IFPUG, от International Function Points User Group), кото-

рая и поддерживает дальнейшую эволюцию метода.

Текущая версия метода (версия 4.2), называемого базовым методом опреде-

ления функционального размера (FP-методом) зафиксирована в практическом ру-

ководстве по расчету размера в единицах функциональности CPM (Counting Prac-

tices Manual, 4.2), выпущенном летом 2004 и доступном на сайте IFPUG:

www.ifpug.org или Дэвида Лонгстрита www.softwaremetrics.com/freemanual.htm.

Подробнее положения FP-метода рассматриваются далее в этом разделе.

Со времени опубликования FP-метода, появилось много его разновидностей,

основанных на той же концепции (таблица 8.1). Наиболее известные из них пред-

ставлены в разделе 8.2. Однако, различия в интерпретации изначальной концепции,

привели к несовместимости методов определения размера и несопоставимости

результатов их применения, что снизило привлекательность каждого из них.

Таблица 8.1. Методы определения размера ПС, основанные на FPA

Название Автор Организация Рекомендации по применению

Function

Points

(FP)

A. Al-

brecht

IBM (1979).

Сопровождается IFPUG

(International Function

Point User Group) (1986)

Автоматизированные информацион-

ные системы, системы организаци-

онного управления и др., опери-

рующие большими объемами ин-

формации в базах данных.

Feature

Points

C. Jones Software Productivity Re-

search (1985)

Системы со сложными вычисления-

ми и умеренными объемами данных

Mark-II

Function

Points

С.Sy-

mons

UKSMA (UK Software

Metrics Association) (1988)

Сопровождается UFPUG

(United Kingdom Function

Point User Group)

Те же, что и для FP-метода. Приме-

няется преимущественно в Велико-

британии (стандартизован в SSADM)

3D Func-

tion Points

(3D_FP)

S.Whit-

mire

Boeing (1992) ПС любого класса, в частности сис-

темы реального времени.

Методология не замыкается на конкретных методах декомпозиции ПС. Авторам

книги известны, например, работы по использованию метода Саати для указанных целей

[2].

378 Глава 8

Название Автор Организация Рекомендации по применению

Object

Points

S.Whit-

mire

ASMA OO-SIG (1993) Объектно-ориентированные распре-

деленные системы.

Highly

Con-

strained

Systems

G.Rule EFPUG FPE-SIG (1993) Системы, состоящие из четко разме-

жеванных прикладных подсистем.

Object

Points for

ICASE

R.Ban-

ker

Carlson School of Manage-

ment (University Minisota

(1994)

ПС, разрабатываемые в среде интег-

рированных CASE.

PRICE

Object

Points

A.Min-

kiewicz

PRICE Systems, Lockheed

Martin Corporation (1996)

ПС, при разработке которых приме-

няется объектно-ориентированный

подход.

Модель учитывает число классов

верхнего уровня, средневзвешенное

число методов в классе, среднюю

глубину дерева наследования, сред-

нее число потомков в классе.

Bang Met-

ric

T.De

Marco

Atlantic Systems Guild

(1982)

Метод подобен 3D_FP-методу.

В 1992 Группы Пользователей (User Groups)

из Австралии, Великобритании,

Нидерландов и США, занимающихся измерением программных средств, создали

рабочую группу WG12 в рамках подкомитета ISO/IEC/JTC1/SC7 и предложили

концепцию измерения функционального размера (FSM, от Functional Size Measure-

ment) и проект одноименного стандарта измерения размера - ISO/IEC 14143. Этот

стандарт поможет решить проблему несовместимости методов и создать эталонную

модель метода. Структура стандарта вкратце рассматривается в разделе 8.4.

8.1.2. Программный компонент. Взгляд пользователя

Согласно базовому FP-методу размер программной системы вычисляется пу-

тем суммирования размеров ее отдельных программных компонентов (ПК). Здесь

программный компонент определяется как часть программного обеспечения сис-

темы (программное приложение, пакет, комплекс программ), реализующая отдель-

ную задачу (комплекс задач) пользователя системы.

Поскольку базовый FP-метод ориентирован для применения при разработке

информационных систем, процесс проектирования которых является в большинст-

ве случаев процессом, «управляемым данными», размер и функциональная слож-

ность измеряемого ПК оценивается исходя из оценок сложности данных, являю-

щихся входными, выходными и обрабатываемыми данными для каждой функции

ПК.

Группы Пользователей (User Groups) – добровольные национальные или междуна-

родные профессиональные сообщества пользователей, создаваемые для анализа состояния

проблемы, представляющей общий интерес, и выработки согласованных коллективных ре-

шений (или стандартов). Примеры – IFPUG (International FP) , UFPUG (UK FP), LUG (Li-

nux), APCUG (Association of Personal Computer) и др.

Глава 8 379

Исходная информация, необходимая для выполнения оценки размера на ран-

них стадиях ЖЦ, может быть получена из документации на ПС (описания требова-

ний, проекта, постановок задач, диаграмм потоков данных, описаний моделей дан-

ных и др.), а также путем интервьюирования конечных пользователей каждого ПК.

Метод оценивания не требует знания технологии реализации ПК и особенно-

стей среды его функционирования. Оцениванию подлежат запрошенные пользова-

телем функции ПК по обработке данных и связанные с ними информационные объ-

екты. Степень детализации функций и информационных объектов ограничивается

тем уровнем декомпозиции функциональных требований к ПК, который приемлем

для понимания конечным пользователем ПК функциональных возможностей ПК по

преобразованию информации в ходе выполнения запрошенной функции (рисунок

8.1).

Граница оцениваемого ПК

ПК

Внутренние

данные

ПК

Ввод

Вывод

Запрос

Используемые

внешние

данные

Ввод

Вывод

Запрос

Пользователь

Рис. 8.1. Взгляд пользователя на процесс функционирования ПК

Определения. Важными для правильного применения метода являются опре-

деления следующих понятий:

Граница ПК - установленная пользователем граница между информационно-

функциональными объектами измеряемого ПК и других (внешних) ПК или пред-

метной области пользователя.

Внутренние данные ПК - идентифицируемая конечным пользователем группа

логически связанных данных или управляющая информация, сохраняемая, обнов-

ляемая, добавляемая или удаляемая в пределах границы ПК.

Внешние данные ПК - идентифицируемая конечным пользователем группа

логически связанных данных или управляющая информация, используемая (но не

изменяемая) в пределах границы ПК, и являющаяся внутренними данными в пре-

делах границы другого ПК.

Вход - данные или управляющая информация, попадающая извне (от пользо-

вателя либо другого ПК) в пределы границы измеряемого ПК.

Выход - данные или управляющая информация, покидающая границы ПК (и

направляемая пользователю или другому ПК).

Запрос - запрашиваемая и в ответ получаемая пользователем информация.

Это выход, непосредственно связанный со входом и получаемый без выполнения

каких-либо действий над внутренними или внешними данными ПК (кроме выборки

и элементарного редактирования).

380 Глава 8

Размер ПК – суммарное число условных единиц функциональности, припи-

сываемых каждой функции в зависимости от количества и сложности информаци-

онных объектов, с которыми она работает.

Процесс подсчета УЕФ (FP) по методу FPA можно условно разделить на два

подпроцесса:

• измерение объема и сложности информационных объектов, с которыми

работает ПК;

•

измерение объема и сложности элементарных функций по обработке

данных в ПК.

8.1.3. Оценка размера и сложности объектов данных

Процесс измерения данных ПК включает перечисленные ниже шаги.

Шаг 1. Анализ документации ПС и определение перечня всех логически свя-

занных групп данных, с которыми должен работать ПК (например, больничная кар-

та, договор, ведомость, командный файл, диагностическое сообщение и др.).

Шаг 2. Определение границы измеряемого ПК и классификация данных на:

• внутренние логические объекты;

• внешние интерфейсные объекты.

Внутренний логический объект (ВЛО) - идентифицируемая конечным поль-

зователем группа логически связанных данных и управляющая информация, сохра-

няемая и сопровождаемая (добавляемая, обновляемая или удаляемая) в пределах

границы ПК.

Внешний интерфейсный объект (ВИО) - идентифицируемая конечным поль-

зователем группа логически связанных данных или управляющая информация, ис-

пользуемая измеряемым ПК, но сопровождаемая в пределах границы другого ПК.

ВИО является внутренним логическим объектом в другом ПК. Например, к ВИО

могут относиться классификаторы, нормативно-справочная информация, вспомога-

тельная информация (помощь) по работе с ПК и др.

Правила отнесения логической группы данных или управляющей информа-

ции к ВЛО таковы:

• группа данных выделяется в соответствии с требованиями пользователя к

данным ПК;

• группа данных сопровождается в пределах границы ПК;

• модификация группы данных выполняется в рамках элементарного про-

цесса, идентифицируемого пользователем.

Элементарный процесс – это элементарная единица действия, идентифици-

руемая (воспринимаемая) конечным пользователем в предметной области. Это са-

мостоятельная технологическая операция в ПК, по завершении выполнения кото-

рой предметная область остается в целостном состоянии;

• группа данных не может быть отнесена к ВИО для данного ПК.

Правила отнесения логической группы данных или управляющей информа-

ции к ВИО таковы:

• группа данных выделяется в соответствии с требованиями пользователя к

данным ПК;

• группа данных используется в ПК;

• группа данных не сопровождается в измеряемом ПК;

Глава 8 381

• группа данных является ВЛО по крайней мере в одном из других ПК;

• группа данных не может быть отнесена к ВЛО измеряемого ПК.

Шаг 3. Определение сложности каждого ВЛО и ВИО.

Уровень сложности может квалифицироваться как «низкий», «средний» и

«высокий». Отнесение объекта к тому или иному уровню сложности производится

исходя из числа подгрупп данных и числа элементарных данных ВЛО или ВИО.

Подгруппа данных объекта (ПДО) - идентифицируемая пользователем под-

группа группы данных ВЛО или ВИО. ПДО не является самостоятельной группой

данных. Например, объект «больничная карта» может иметь ПДО «информация о

болезни» (диагноз, назначение и др.) и «информация о больном» (паспортные дан-

ные, адрес) и др.

Элементарное данное объекта (ЭДО) - уникальное (неповторяющееся) иден-

тифицируемое пользователем данное (поле) ВЛО или ВИО.

Матрица оценки уровня сложности ВЛО и ВИО представлена в таблице 8.2.

Таблица 8.2. Матрица оценки сложности данных ПК

Число элементарных данных объекта (ЭДО) Число подгрупп данных

объекта (ПДО)

1 - 19 20 – 50 > 50

0 – 1

Низкий Низкий Средний

2 – 5

Низкий Средний Высокий

> 5

Средний Высокий Высокий

Если необходимый уровень детализации данных ПК в документации ПС от-

сутствует - присваивание уровня сложности может производиться на основе экс-

пертных оценок.

Шаг 4. Взвешивание ВЛО и ВИО по уровням сложности.

Веса, присваиваемые ВЛО и ВИО в зависимости от принятого уровня слож-

ности, представлены в таблице 8.3.

Таблица 8.3. Веса ВЛО и ВИО

Веса по уровням сложности Тип

Объекта

Низкий Средний Высокий

ВЛО

7 10 15

ВИО

5 7 10

Шаг 5. Подсчет условных единиц функциональности по всем ВЛО и ВИО.

Для подсчета условных единиц функциональности информационных объек-

тов (УЕФ

) необходимо определить количество ВЛО и ВИО по каждому уровню

сложности и полученные значения просуммировать.

Например, если выявлено 2 ВЛО низкого уровня сложности, 3 - среднего, а

также 1 ВИО среднего уровня сложности и 2 - высокого, то

711027110372

=⋅+⋅+⋅+⋅=УЕФ

условная единица.

8.1.4. Оценка размера и сложности функций обработки данных

Каждое функциональное требование к ПК представляет собой совокупность

элементарных функций обработки данных, поддерживаемых элементарными про-

цессами.

382 Глава 8

Процесс измерения элементарных функций обработки данных ПК включает

перечисленные ниже шаги.

Шаг 1. Анализ функциональных требований к ПК и выделение технологиче-

ских процессов, поддерживающих их реализацию. Технологический процесс может

включать несколько технологических операций (элементарных процессов), каждая

их которых реализует элементарную функцию ПК.

Шаг 2. Отнесение каждой элементарной функции в пределах одного функ-

ционального требования к одной из трех категорий:

• внешний ввод;

• внешний вывод;

• внешний запрос.

Внешний ввод (ВВД) – элементарный процесс обработки входа в ПК. ВВД

выполняет функцию управления ПК или сопровождения (добавления, обновления

или удаления) данных в ВЛО. Например, ввод данных в поле экрана, выбор данных

из списка, обработка щелчка на кнопке.

Внешний вывод (ВЫВ) - элементарный процесс генерации выхода из ПК. На-

пример, формирование и печать отчета, формирование и вывод данных на экран.

Внешний запрос (ЗАП) - элементарный процесс непосредственной выборки

запрашиваемых пользователем по определенному критерию данных из ВЛО или

ВИО без какого-либо изменения и без сопровождения данных в ВЛО. Например,

получение тематической справки, получение контекстной помощи, вывод класси-

фикатора, многокритериальный поиск информации.

Правила отнесения функции к внешнему вводу:

• данные или управляющие воздействия, обрабатываемые функцией, по-

ступают извне границы ПК;

• данные сохраняются в ВЛО, и производится сопровождение ВЛО;

• функция реализуется элементарным процессом;

• для функции, отождествляемой с элементарным процессом, выполняется

одно из следующих правил:

- логика обработки данных функцией отличает ее от других ВВД;

- данные, обрабатываемые функцией, отличаются от данных в других ВВД.

Правила отнесения функции к внешнему выводу:

• функция посылает данные или управляющую информацию за пределы

границы ПК;

• функция реализуется элементарным процессом;

• для функции, отождествляемой с элементарным процессом, выполняется

одно из следующих правил:

- логика обработки данных функцией отличает ее от других ВЫВ;

- данные, обрабатываемые функцией, отличаются от данных в других ВЫВ

Правила отнесения функции к внешнему запросу:

• данные, составляющие критерий запроса, получены извне границы ПК;

• данные, составляющие результат запроса, покидают границу ПК;

• результирующие данные являются выборкой (данные в ВЛО не изменя-

ются, логические или математические действия над данными не производятся);

• функция реализуется элементарным процессом;

Глава 8 383

• для функции, отождествляемой с элементарным процессом, выполняется

одно из следующих правил:

- логика обработки данных (в части ввода и в части вывода) отличает

функцию от других ЗАП;

- данные, которые обрабатывает функция (в части ввода и в части вывода),

отличаются от данных в других ЗАП.

Шаг 3. Определение сложности каждого ВВД, ВЫВ и ЗАП.

Уровень сложности функции может квалифицироваться как «низкий», «сред-

ний» и «высокий». Отнесение функции к тому или иному уровню сложности про-

изводится исходя из числа ссылочных объектов функции и числа элементарных

данных функции, представляющих вход, выход или выборку.

Ссылочный объект функции (СОФ) - внутренний логический объект, кото-

рый сопровождается функцией, или внешний интерфейсный объект, который ис-

пользуется функцией измеряемого ПК.

Элементарное данное функции (ЭДФ) - уникальное (неповторяющееся) иден-

тифицируемое пользователем данное (поле), относящееся ко входу, выходу или

выборке функции. Например, вводимое поле, список, управляющее воздействие,

отождествляемое со щелчком на управляющем объекте экрана (кнопке).

Элементарные данные функции связываются с элементарными данными объ-

екта в ВИО и ВЛО, которые используются или сопровождаются функцией (рисунок

8.2).

Граница оцениваемого ПК

ПК

Внутренние

данные

ПК

(

ВЛО

внутренний

логический

объект)

ВВД

- Ввод

ВЫВ

- Вывод

ЗАП

- Запрос

Используемые

внешние

данные

(

ВИО

- внешний

интерфейсный

объект)

Ввод

Вывод

Запрос

Пользователь

ПДО 1

ПДО 2

ЭДО

ВЛО

содержит

ПДО

ЭДО

Функция ссылается

на

СОФ

- ссылочный

объект функции

(ВЛО или ВИО)

Функция

использует

ЭДФ

элементарное

данное функции

(ЭДО из ВЛО,

ВИО)

Рис. 8.2. Взаимосвязь понятий в FPA

Матрица оценки уровня сложности ВВД представлена в таблице 8.4.