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

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

394 Глава 8

Показатель сложности технических требований. После того, как опреде-

лена степень влияния всех 14 общесистемных характеристик на размер и сложность

разработки ПС, может быть рассчитан поправочный (настроечный) коэффициент

сложности ПС (Кслож):

∑

]100/)[(65.0

CКслож

где C

- степень влияния каждой общесистемной характеристики.

Как правило, этот коэффициент модифицирует значение ПФР на ±35%.

Нужно отметить, также, что различные организации могут не использовать

все 14 характеристик сложности технических требований к ПС. Например, Software

Productivity Research, Inc. рекомендует применение только трех.

Общий функциональный размер. Общий размер разрабатываемой ПС

, вы-

числяемый в УЕФ, определяется по формуле:

ПФРКсложFP

⋅

8.2. Методы измерения, основанные на концепции FSM

8.2.1. Метод Fеature Points

Метод Feature Points (FeP), предложенный К. Джоунсом в 1985

году, пред-

ставляет собой развитие FP-метода, предпринятое с целью улучшения точности

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

ной сложностью, в частности, систем реального времени, операционных систем,

встроенных систем, систем телекоммуникации и программных систем управления

процессами [3].

Наряду с пятью базовыми логическими элементами FP-модели (ВЛО, ВИО,

ВВД, ВЫВ, ЗАП), FеP-модель использует один дополнительный элемент - алго-

ритм (AЛ). Этот элемент имеет по умолчанию вес 3, но может варьироваться от 1

до 10, в зависимости от сложности алгоритма. Все остальные элементы имеют по

одному фиксированному значению веса сложности, что отражает снижение важно-

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

ции сложности элементов по данным (таблица 8.23).

Таблица 8.23. Веса базовых логических элементов модели FeP

Вес элемента Значение Вес элемента Значение

AЛв 1-10 (по умолчанию 3) ЗАПв 4 (фиксированный)

ВВДв 4 (фиксированный) ВЛОв 7 (фиксированный)

ВЫВв 5 (фиксированный) ВИОв 7 (фиксированный)

ПФР вычисляется так же, как и в FP-методе.

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

FP-метод может применяться для определения размера ПС не только на стадиях ее

разработки, но и при сопровождении и развитии. Однако мы ограничились только форму-

лой расчета размера разрабатываемой ПС.

Методы в обзоре упорядочены по годам их разработки.

Глава 8 395

оценивать 3 общесистемные характеристики по уровням сложности от 1 до 5 и по

полученному суммарному уровню сложности характеристик (СУС) определять

Кслож, пользуясь специальной таблицей, предлагаемой Software Productivity Re-

search, Inc (таблица 8.24).

Таблица 8.24. Значения Кслож по уровням сложности

СУС по трем

характеристикам

Значение Кслож СУС по трем

характеристикам

Значение Кслож

2 0.6 7 1.1

3 0.7 8 1.2

4 0.8 9 1.3

5 0.9 10 1.4

6 1.0 11 1.5

Общий функциональный размер ПС определяется по формуле:

ПФРКсложFeP

⋅

8.2.2. Метод Mark-II Function Points

В отличие от FP-метода, метод Mark-II Function Points (MK-II), предложен-

ный Ч.Саймонсом в 1988 году, основан на выделении только одного (а не пяти, как

в FP-методе) базового логического элемента - логической транзакции. Функцио-

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

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

ческих транзакций. Метод ориентирован на измерение размера и сложности обра-

ботки информации приложений с базами данных [4].

Каждая логическая транзакция - эквивалент элементарного процесса обра-

ботки данных. Она включает три компонента:

• входные данные, поступающие извне границ приложения;

• выходные данные, покидающие границы приложения,

• обработку хранимых в приложении данных, представленных в виде ти-

пов сущностей (реляционных таблиц) в третьей нормальной форме.

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

стей в каждой транзакции подсчитываются при определении размера приложения.

Для сравнения, в FP-методе типы сущностей группировались в ВЛО и ВИО, а

ссылки на типы сущностей подсчитывались как СОФ и ЭДФ по каждому ВВД,

ВЫВ и ЗАП. Кроме того, в МК-II-методе различают основные сущности (primary

entities), имеющие непосредственное отношение к прикладной области, и так назы-

ваемую единую системную сущность (system entity) - совокупность таблиц, содер-

жащих информацию исключительно реализационного характера.

Сложность входов и выходов транзакции определяется числом элементов

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

ЭДО для ВЛО и ВИО).

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

муле:

WобрNобрWвыхNвыхWвхNвхПФР

⋅

396 Глава 8

где N - число входных данных, выходных данных и ссылок на сущности (основные

и системную, соответственно), а W - относительные веса, присваиваемые элемен-

там в зависимости от их «вклада» в сложность приложения. Значения этих весов -

Wвх = 0.58, Wвых = 0.26 и Wобр = 1.66 - получены экспериментальным путем.

Учет сложности технических требований к приложению выполняется по 19

характеристикам (14 из которых взяты из метода FP). Оценивается уровень слож-

ности каждой характеристики (от 0 до 5) и по полученному суммарному СУС рас-

считывается Кслож по формуле:

65.0)005.0(

⋅

СУСКслож

Результирующее значение функционального размера приложения определя-

ется как:

ПФРКсложFPIIMk

⋅

Коэффициент Кслож модифицирует значение ПФР на ±12,5%.

Нужно отметить, что методы FP и Mk-II дают сопоставимые результаты оце-

нивания размера на относительно небольших приложениях с базами данных (при-

мерно 400 УЕФ). Для более крупных приложений метод Mk-II дает более точные

значения, чем FP-метод. Результаты сопоставительного анализа Mark-II и FP пред-

ставлены на сайте http://www.measuresw.com/library/Papers/Rule/MK2IFPUG.html.

Текущая версия метода – версия 1.3.1, датированная сентябрем 1998 - дос-

тупна на сайте UKSMA: www.uksma.co.uk/.

Методы FP и Mk-II имеют обширную инструментальную поддержку, в част-

ности, в CASE-инструментах (например, в Oracle Designer’2000 (приложение 4).

8.2.3. Метод 3D Function Points

Метод 3D Function Points (3D_FP), разработан С. Вайтмайером для компании

Boeing в 1992 году. Основная цель разработки метода - решение проблем, связан-

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

категорию информационных [5]. Предлагаемый метод расчета основан на предпо-

ложении, что сложность любого разрабатываемого приложения можно рассматри-

вать с трех точек зрения (или в трех измерениях, откуда и название модели - 3-

Dimensions) - сложности данных, функций и управления (поведенческий аспект). В

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

измерение размера и сложности, например, данные - в информационных системах,

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

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

не имеющие явно выраженной доминанты, то есть смешенные приложения.

Для получения общего размера приложения модель 3D_FP оценивает уро-

вень сложности одной-двух характеристик по каждому измерению, независимо от

проблемной области или технологии реализации.

Для оценки сложности данных (СлД) непосредственно используется FP-

метод (определяются УЕФ для ВЛО, ВИО, ВВД, ВЫВ и ЗАП).

Для оценки сложности функций (СлФ) устанавливается число трансформа-

ций (Nтранс) - совокупность шагов процесса обработки данных (то есть число опе-

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

выполнением операций. Каждая трансформация «взвешивается» по трем уровням

Глава 8 397

сложности («низкая», «средняя» и «высокая»), подобно тому, как это делалось в

FP-методе.

Для оценки сложности управления (СлУ) определяется множество уникаль-

ных состояний (Nс), в которых может находиться процесс, а также множество пе-

реходов (Nп) между состояниями. Для состояний и переходов устанавливается

только один уровень сложности - 1. Значение СлУ определяется по формуле:

NпNcСлУ

Общий функциональный размер приложения вычисляется по формуле:

СлУСлФСлДFPD

8.2.4. Метод Use Case Points для объектно-ориентированных приложений

Идея применения методологии FPA для определения размера объектно-

ориентированных ПС, разрабатываемых по методологии А.Джекобсона OOSE (от

Object Oriented Software Engineering), принадлежит С. Вайтмайеру (1992 г.).

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

сообщений между классами [6]. Каждый класс рассматривался как внутренний ло-

гический объект, а сообщения, посылаемые за пределы границ системы, трактова-

лись как транзакции. Существование внешних интерфейсных объектов отверга-

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

допущения этого подхода приводили к отклонению от концепции FPA. Во-первых,

в FPA посылаемое сообщение необязательно является транзакцией (с точки зрения

пользователя), а во-вторых, к ВИО есть доступ, по крайней мере, для чтения.

В 1993 году Г.Кернер из Objectory Systems inc. (ныне Rational Software) пред-

ложил новую меру размера объектно-ориентированных ПС, называемую Use Case

Points (UCP) и основанную на анализе сущностей в Модели сценариев использова-

ния ПС [7], [8]. С помощью этой модели в OOSE описываются функциональные

требования к ПС.

Модель сценариев использования UCM (от Use Case Model) имеет два вида

элементов – акторы и собственно функциональные сценарии использования. Акто-

ры – это субъекты, находящиеся вне системы, взаимодействующие с системой или

обменивающиеся с ней информацией. Последовательность действий акторов с сис-

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

Показатели UCP вычисляются в ходе анализа модели сценариев использова-

ния следующим образом.

Сначала выполняется классификация акторов – на «простые», «средние» и

«сложные» - и каждому типу акторов приписывается вес (таблица 8.25).

Таблица 8.25. Классификация акторов

Тип актора Назначение Вес

Простой Другая система (приложение) с определенным API-интерфейсом 1

Средний Другая система (приложение), взаимодействующая через прото-

кол, например, TCP/IP

Сложный Человек, взаимодействующий с приложением через GUI или

Web-страницу

Количество показателей функциональности для акторов (УЕФ

) вычисляется

по формуле

398 Глава 8

WNУЕФ ⋅=

∑

где N – число простых, средних или сложных акторов, а W - относительные веса,

присваиваемые им в зависимости от «вклада» в сложность приложения.

Сценарии использования также делятся на «простые», «средние» и «слож-

ные». Существует три способа определения сложности сценариев:

1) в зависимости от числа транзакций в описании сценария, включая вторич-

ные сценарии (таблица 8.26, колонка «Транзакции»);

Таблица 8.26. Классификация сценариев использования

Тип сценария Транзакции Классы Сложность реализации Вес

Простой <= 3 <= 5 Простой интерфейс пользова-

теля, одна таблица БД

Средний 4 - 7 5 -10 Интерфейс пользователя

средней сложности, 2 и более

таблицы БД

Сложный >= 7 >= 10 Очень сложный интерфейс

пользователя или более 3

таблиц БД

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

рии (таблица 8.26, колонка «Классы»);

3) в зависимости от уровня сложности работ по реализации (таблица 8.26, ко-

лонка «Сложность реализации»).

«Взвешивание» сценариев использования производится так же, как и акторов.

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

риев (УЕФ

Показатель функционального размера объектно оиентированного приложе-

ния (ПФРО) вычисляется по формуле

ПФРО = УЕФ

+ УЕФ

Для учета сложности реализации общесистемных характеристик и нефунк-

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

таблице 8.27.

Таблица 8.27. Общесистемные характеристики

№ Фактор (характеристика системы) Вес

1 Распределенная обработка информации 2

2 Высокая производительность 1

3 Эффективность работы конечного пользователя 1

4 Сложная внутренняя обработка данных 1

5 Возможность повторного использования приложения 1

6 Простота установки 5

7 Простота использования 5

8 Переносность 2

9 Простота внесения изменений 1

10 Параллельная обработка 1

11 Включение специальных свойств защиты информации 1

12 Предоставление непосредственного доступа для третьей стороны 1

13 Предоставление специальных возможностей обучения пользователей 1

Глава 8 399

Каждому фактору приписана оценка сложности (вес), отражающая «вклад»

соответствующего фактора в сложность приложения.

Рейтинг влияния факторов оценивается экспертным путем по уровням слож-

ности от 0 до 5, где 0 – означает, что фактор не оказывает никакого влияния на вы-

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

Поправочный (настроечный) коэффициент, учитывающий сложность обще-

системных характеристик К1слож, рассчитывается по формуле

∑

⋅+=

)(01.06.01

CWсложK

где W

– вес i-го фактора, C

– экспертная оценка влияния i-го фактора на слож-

ность реализации приложения.

Для учета условий среды разработки приложений используются факторы,

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

ды разработки (вес), отражающая «вклад» соответствующего фактора в успех про-

екта.

Таблица 8.28. Характеристики среды разработки

№ Фактор (характеристика среды разработки) Вес

1 Владение основами методологии RUP 1.5

2 Знание проблемной области 0.5

3 Опыт объектно-ориентированной разработки 1

4 Лидерские задатки аналитика 0.5

5 Мотивация коллектива 1

6 Стабильность требований 2

7 Частичная занятость специалистов -1

8 Сложность языка программирования -2

Рейтинг влияния факторов среды разработки, указанных в таблице 8.28 оце-

нивается таким же образом, как и факторов сложности приложений.

Поправочный (настроечный) коэффициент, учитывающий условия среды

разработки К2слож, рассчитывается по формуле

∑

⋅−+=

)(03.0(4.12

CWсложК

где W

– вес i-го фактора, C

– экспертная оценка влияния i-го фактора на успех

проекта.

Общий функциональный размер объектно-ориентированного приложения

рассчитывается по формуле

сложКсложКПФРOUCP 21

⋅

Нужно отметить, что структура UCP, предложенная Г.Кернером, не основы-

вается на элементах, представляющих размер в FPA, что не позволяет сопоставлять

результаты измерений приложений.

400 Глава 8

8.2.5. Отображение элементов объектно-ориентированного подхода на

FPA

Способ «примирения» концепций OOSE и FPA предложил Т.Фецке [9], по-

строив отображение элементов базовых моделей подхода OOSE на элементы под-

хода FPA

В OOSE модель сценариев использования является основой для построения

других моделей – модели объектов предметной области (домена) и модели анали-

за (на самых ранних стадиях ЖЦ); модели проекта, модели реализации и модели

тестирования (на более поздних стадиях ЖЦ).

Для построения отображения элементов подхода OOSE на FPA Т.Фецке ис-

пользовал первые две модели – модель предметной области и модели анализа.

Модель предметной области включает объекты ПрО, между которыми уста-

навливаются взаимосвязи наследования и агрегации.

Модель анализа основана на типах объектов – объект-сущность, объект-

интерфейс и объект-воздействие (управление). Объекты-сущности – это объекты

ПрО, моделирующие информацию в системе и связанные отношениями наследова-

ния и агрегации. Объекты-интерфейсы моделируют поведение системы и инфор-

мацию, которая представляет систему во внешней среде. Объекты-воздействия мо-

делируют функциональность, не охватываемую другими типами объектов (напри-

мер, вычисления, в которые вовлечены несколько объектов-сущностей). Такая ти-

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

требований к отдельным типам объектов (например, только к интерфейсу системы).

Модель анализа строится по модели сценариев использования. Функциональность

каждого сценария декомпозируется и назначается типизированным объектам.

Процедура построения отображения включает следующие этапы.

Этап 1. Отображение понятия «граница приложения». Граница приложения

в OOSE устанавливается с помощью модели сценариев использования UCM, по-

скольку акторы находятся вне приложения, а сценарии определяют функциональ-

ность приложения. В сумме все акторы формируют исчерпывающий взгляд на из-

меряемое приложение. Однако понятие «актор» шире, чем «пользователь» и

«внешнее приложение» в FPA, поскольку как акторы могут рассматриваться функ-

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

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

ниях.

Правила отображения для этапа 1 таковы:

1.1) рассматривать каждого актора – человека - как пользователя системы;

1.2) рассматривать каждого актора- не человека, который является отдельной

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

нее приложение;

1.3) отвергать акторы (не являющиеся людьми), решающие задачи системы.

Этап 2. Идентификация элементов внутри границ приложения. В FPA внут-

ри границ приложения идентифицируются логические объекты и элементарные

функции.

Кандидатами на группы элементарных функций (ввода, вывода и запросы)

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

как одна или более функций в зависимости от выполняемых в нем задач. В целом,

Глава 8 401

модель сценариев использования не дает достаточно информации для принятия

решения о том, как учитывать каждый сценарий при расчете размера.

Т. Фецке предлагает следующую процедуру отображения для этапа 2:

2.1) в качестве кандидата на одну или несколько функций выбрать сценарии,

имеющие непосредственное отношение к акторам, отобранным по правилам 1.1 и

1.2 на этапе 1;

2.2) выбрать все сценарии, расширяющие каждый сценарий, выбранный в 2.1.

Эти расширения могут включать взаимодействие с пользователем или внешним

приложением;

2.3) не выбирать никакие другие сценарии.

Понятию логических объектов соответствует в OOSE понятия объектов ПрО

в модели ПрО (домена) и типов объектов в модели анализа, причем объекты-

сущности отображаются непосредственно на логические объекты, объекты-

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

моделируют внутренние процессы.

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

раничивается объектами-сущностями и применяются приведенные ниже правила

отображения 2.4 и 2.5:

2.4) выбрать каждый объект-сущность в качестве кандидата на логический

объект (если это не противоречит правилам 2.8 - 2.10);

2.5) не выбирать никакие другие объекты.

Если используется только модель ПрО, применяются правила 2.6 и.2.7:

2.6) выбрать каждый объект ПрО в качестве кандидата на логический объект

(если это не противоречит правилам 2.8 – 2.10);

2.7) не выбирать никакие другие объекты.

Для объектов, связанных отношениями агрегации и наследования, Т.Фецке

предлагает такие правила отображения:

2.8) объект ПрО или объект-сущность, являющийся частью другого объекта

(агрегированный в другой объект), не может быть кандидатом на логический объ-

ект FPA, но может быть кандидатом на подгруппу данных объекта (ПДО), связан-

ного с объектом верхнего уровня в агрегации;

2.9) абстрактный объект не может быть кандидатом на логический объект, но

может быть кандидатом на ПДО каждого объекта, который наследует его свойства;

2.10) подобъекты конкретного объекта могут быть кандидатами на логиче-

ский объект или его ПДО.

В FPA рассматриваются также логические объекты, которым может не быть

соответствия в модели ПрО, хотя они и нужны пользователю. Это, например, со-

общения об ошибках, подсказки. В этом случае применяется следующее правило:

2.11) если в сценарии предполагается использование логических объектов,

которые не представлены в модели объектов, такие объекты все равно должны

быть учтены в измерениях.

Этап 3. Определение типов элементов. На этом этапе элементы, выбранные

на этапе 2, классифицируются в соответствии с требованиями FPA: кандидаты

функции – как функции ВВД, ВЫВ и ЗАП, а кандидаты в логические объекты – как

ВЛО и ВИО, и к ним применяются правила расчета УЕФ, установленные в FPA.

Этап 4. Определение весовых коэффициентов. Используется руководство

IFPUG по расчету размера в FPA. Подсчитывается число подгрупп данных объек-

402 Глава 8

тов (ПДО), элементарных данных объектов (ЭДО) и функций (ЭДФ), ссылочных

объектов функций (СОФ). Аналогом элементарных данных являются атрибуты

объектов. Применяется следующие правила отображения:

4.1) атрибуты объектов являются кандидатами в элементарные данные объек-

тов и функций, используемых для их чтения или ведения;

4.2) кандидаты в подгруппы данных объектов определяются по правилам 2.8-

2.10;

4.3) каждый объект, читаемый или сопровождаемый в сценарии использова-

ния, учитывается как ссылочный объект функции для соответствующих функций

тогда и только тогда, когда объект может быть идентифицирован как логический

объект на этапе 3.

Таким образом, применение правил отображения элементов приложений,

разрабатываемых по объектно-ориентированной методологии OOSE, позволяет

расширить сферу традиционного использования FPA, обеспечить согласованность

измерений объектно-ориентированных приложений в проектах ПС и получать со-

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

Парадигма «трансформации» подходов в FPA в дальнейшем нашла отраже-

ние в работах Дж.Кэммилера [10] (метод COP – Component object points),

Г.Тиологли [11] (метод POP – Predictive object points), С.Эбрехи и О.Пастора [12]

(метод OOmFP - OO-Method Function Points) и др.

8.2.6. Метод Object Points for ICASE

Метод Object Points for ICASE (I_FP), разработанный Д. Бенкером в 1994 го-

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

дом. Под объектами здесь понимаются экранные формы (или экраны), формы от-

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

элементы приложений при разработке средствами интегрированных CASE-

инструментов.

Расчет функционального размера производится следующим образом [13].

Определяется число объектов каждого вида. Далее для каждого из этих объ-

ектов устанавливается уровень сложности (как «простой», «средний» и «сложный»)

в зависимости от значений характеристик, представленных в таблице 8.29.

Таблица 8.29. Матрица оценки сложности экранов и отчетов

Для экранов Для отчетов

Число и источник таблиц данных Число и источник таблиц данных

Число полей

экрана

Всего <4:

<2 серве-

ров

<3 кли-

ентов

Всего <8:

2 или 3

сервера

3-5 кли-

ентов

Всего 8+:

>3 серве-

ров

>5 клиен-

тов

Число полей

отчета

Всего <4:

<2 серве-

ров

<3 клиен-

тов

Всего <8:

2 или 3

сервера

3-5 кли-

ентов

Всего 8+:

>3 серве-

ров

>5 клиен-

тов

простой простой средний

0 / 1

простой простой средний

3-7

простой средний сложный

2 / 3

простой средний сложный

средний сложный сложный

Затем определяются относительные веса элементов в зависимости от уровня

сложности (таблица 8.30)

Глава 8 403

Таблица 8.30. Веса объектов

Вес по сложности Тип объекта

Простой Средний Сложный

Экран 1 2 3

Отчет 2 5 8

Модуль - - 10

И, наконец, функциональный размер приложения вычисляется как сумма по-

лученных значений по всем объектам.

8.2.7. Метод Early Function Points. Раннее прогнозирование размера

Метод раннего прогнозирования функционального размера (EFP, от Early

Function Points) предложен Роберто Мели (Италия) в 1997 году. EFP – это не аль-

тернатива базовому FP-методу (IFPUG 4.0), а его адаптация для быстрого и раннего

оценивания размера.

Метод основывается на идентификации объектов будущего приложения - ло-

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

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

максимум», тем выше, чем выше уровень, на котором останавливается процесс

идентификации объектов приложения. Однако многоуровневый подход делает воз-

можным использование любых знаний (в любой форме и любой глубины), оставляя

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

ствующей детальной информации о части системы.

Ключевыми объектами оценивания являются: функциональные примитивы,

микрофункции, функции, макрофункции и логические элементы данных. Каждому

из этих объектов может быть назначено множество значений УЕФ, основанных на

статистических данных.

Логические элементы данных (ЛЭД) - группы связанных элементов данных,

соответствующих ВЛО и ВИО в базовом FP-методе. Они классифицируются по

пяти уровням сложности: «низкий», «средний», «высокий», «сложный», «сверх-

сложный». Первые три оценки выводятся по правилам FP-метода, вторые две –

предназначены для оценивания крупных (составных) объектов данных без их дета-

лизации (например, объектов, состоящих из нескольких взаимосвязанных таблиц).

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

ются. Матрица оценки сложности составных объектов представлена в таблице 8.31.

Таблица 8.31. Матрица оценки сложности составных объектов данных

Количество отдельных объектов в составном Уровень сложности

2 - 4 Сложный

5 - 8 Сверхсложный

Четыре основные категории объектов-функций, характеризующих функцио-

нальность приложения таковы:

• функциональные примитивы (ФПр) – мельчайшие элементарные процес-

сы, которые не могут быть далее детализированы. Это процессы ввода (ПрВВД),

вывода (ПрВЫВ) и запроса (ПрЗАП), соответствующие объектам ВВД, ВЫВ и ЗАП

в базовом FP-методе;

• микрофункции (МиФ) - набор из четырех функциональных примитивов -