Методы оценки размера программной системы, страница 5

Общий функциональный размер. Общий размер разрабатываемой ПС5, вы­числяемый в УЕФ, определяется по формуле:

FP= Кслож • ПФР

7.2. FPA-подобные методы измерения размера 7.2.1. Метод Feature Points

Метод FeaturePoints (FeP), предложенный К. Джоунсом в 19856 году, пред­ставляет собой развитие FP-метода, предпринятое с целью улучшения точности оценок функционального размера программных систем, обладающих вычислитель­ной сложностью, в частности, систем реального времени, операционных систем,

FP-метод может применяться для определения размера ПС не только на стадиях ее
разработки, но и при сопровождении и развитии. Однако мы ограничились только форму­
лой расчета размера разрабатываемой ПС.

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


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

Наряду с пятью базовыми логическими элементами FP-модели (ВЛО, ВИО, ВВД, ВЫВ, ЗАП), FeP-модель использует один дополнительный элемент - алго­ритм (АЛ). Этот элемент имеет по умолчанию вес 3, но может варьироваться от 1 до 10, в зависимости от сложности алгоритма. Все остальные элементы имеют по одному фиксированному значению веса сложности, что отражает снижение важно­сти учета данных для определения размера ПК и устраняет проблему классифика­ции сложности элементов по данным (таблица 7.22).

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

Для учета сложности технических требований к ПС метод FeP предлагает оценивать 3 общесистемные характеристики по уровням сложности от 1 до 5 и по полученному суммарному уровню сложности характеристик (СУС) определять Кслож, пользуясь специальной таблицей, предлагаемой Software Productivity Re­search, Inc (таблица 7.23).

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

FeP = КсложПФР

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

В отличие от FP-метода, метод Mark-IIFunctionPoints (MK-II), предложен­ный Ч.Саймонсом в 1988 году, основан на выделении только одного (а не пяти, как в FP-методе) базового логического элемента - логической транзакции. Функцио­нальные требования рассматриваются как совокупность логических транзакций, а функциональный размер приложения представляется суммой размеров всех логи­ческих транзакций. Метод ориентирован на измерение размера и сложности обра­ботки информации приложений с базами данных [4].

Каждая логическая транзакция - эквивалент элементарного процесса обра­ботки данных. Она включает три компонента:


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

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

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

Каждый тип сущности трактуется как независимый, а ссылки на типы сущно­стей в каждой транзакции подсчитываются при определении размера приложения. Для сравнения, в FP-методе типы сущностей группировались в ВЛО и ВИО, а ссылки на типы сущностей подсчитывались как СОФ и ЭДФ по каждому ВВД, ВЫВ и ЗАП. Кроме того, в МК-II-методе различают основные сущности (primary entities), имеющие непосредственное отношение к прикладной области, и так назы­ваемую единую системную сущность (system entity) - совокупность таблиц, содер­жащих информацию исключительно реализационного характера.

Сложность входов и выходов транзакции определяется числом элементов данных (типов полей), которые они содержат (аналогичное понятие в FP-методе -ЭДО для ВЛО и ВИО).

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

пфp = nbx*wbx+ Nвыx*Wвыx + Noбp*Woбp,

где N - число входных данных, выходных данных и ссылок на сущности (основные и системную), соответственно, a W - относительные веса, присваиваемые элемен­там в зависимости от их «вклада» в сложность приложения. Значения этих весов -wвх = 0.58, Wвыx = 0.26 и Woбp = 1.66 - получены экспериментальным путем.

Учет сложности технических требований к приложению выполняется по 19 характеристикам (14 из которых взяты из метода FP). Оценивается уровень слож­ности каждой характеристики (от 0 до 5) и по полученному суммарному СУС рас­считывается Кслож по формуле:

Кслож = (СУС • 0.005) + 0.65

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

Mk-II_FP= Кслож • ПФР

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

Нужно отметить, что методы FP и Mk-II дают сопоставимые результаты оце­нивания размера на относительно небольших приложениях с базами данных (при­мерно 400 УЕФ). Для более крупных приложений метод Mk-II дает более точные значения, чем FP-метод.

Текущая версия метода - версия 1.3.1, датированная сентябрем 1998 - сво­бодно доступна на сайте UKSMA: www.uksma.co.uk/.

7.2.3. Метод 3D FunctionPoints

Метод 3D FunctionPoints (3D_FP), разработан С. Вайтмайером для компании Boeing в 1992 году. Основная цель разработки метода - решение проблем, связан­ных с измерением функционального размера любых приложений, не попадающих в категорию информационных [5]. Предлагаемый метод расчета основан на предпо­ложении, что сложность любого разрабатываемого приложения можно рассматри-


вать с трех точек зрения (или в трех измерениях, откуда и название модели - 3-Dimensions) - сложности данных, функций и управления (поведенческий аспект). В зависимости от назначения системы в приложении может преобладать то или иное измерение размера и сложности, например, данные - в информационных системах, функции - в программах инженерных расчетов и научных исследований, управле­ние - в системах реального времени и т.д. Могут также существовать приложения, не имеющие явно выраженной доминанты, то есть смешенные приложения.

Для получения общего размера приложения модель 3D_FP оценивает уро­вень сложности одной-двух характеристик по каждому измерению, независимо от проблемной области или технологии реализации.

Для оценки сложности данных (СлД) непосредственно используется FP-метод (определяются УЕФ для ВЛО, ВИО, ВВД, ВЫВ и ЗАП).