Функционально-ориентированные метрики. Существенным недостатком моделей, основанных на тысячах условных строк кода, как метрике размера программного комплекса

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

Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем (опубликован в 1979 г.). В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), было опубликовано несколько ревизий метода.

Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании.

Другими аналогичными методами являются Feature Points, разработанный Кэйперсом Джонсом (Capers Jones) и 3D Points, разработанный в компаниии Боинг (Boeing).

Рассмотрим ниже подход FPA IFPUG. Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассма­тривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик.

1) Количество внешних вводов. Подсчитываются все вводы пользователя, по кото­рым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

2) Количество внешних выводов. Подсчитываются все выводы, по которым к поль­зователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не под­считываются.

3) Количество внешних запросов. Под запросом понимается диалоговый ввод, ко­торый приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалого­вый вывод не требует выполнения вычислений. Подсчитываются все запросы — каждый учитывается отдельно.

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

5) Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. Вводы, выводы и запросы относят к категории транзакция. Транзакция — это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции исполь­зуют внутренние и внешние файлы. Приняты следующие определения.

Внешний ввод — элементарный процесс, перемещающий данные из внешней сре­ды в приложение. Данные могут поступать с экрана ввода или из другого прило­жения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информа­цию. Управляющие данные не должны модифицировать внутренний логический файл.

Внешний вывод — элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, по­сылаемые другим приложениям. Отчеты и файлы создаются на основе внутрен­них логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внут­реннем логическом файле.

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

Внешний интерфейсный файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддержи­вается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.

Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем фор­мируется числовая оценка ранга.

Для транзакций ранжирование основано на количестве ссылок на файлы и коли­честве типов элементов данных. Для файлов ранжирование основано на количе­стве типов элементов-записей и типов элементов данных, входящих в файл.

Тип элемента-записи — подгруппа элементов данных, распознаваемая пользова­телем в пределах файла.

Тип элемента данных — уникальное не рекурсивное (неповторяемое) поле, рас­познаваемое пользователем.

Примеры элементов данных для различных характеристик приведены в табл. 7.2, а табл. 7.3 содержит правила учета элементов данных из графического интерфейса пользователя (GUI).

Таблица 7.2 - Примеры элементов данных

Таблица 7.3 - Правила учета элементов данных из графического интерфейса пользователя

Например, GUI для обслуживания клиентов может иметь поля Имя, Адрес, Город, Стра­на, Почтовый Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элемен­тов данных. Восьмым элементом данных может быть командная кнопка (добавить, изменить, удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Уда­лить будет состоять из 8 элементов данных (7 полей плюс командная кнопка). Обычно одному экрану GUI соответствует несколько транзакций. Типичный эк­ран включает несколько внешних запросов, сопровождающих внешний ввод. Обсудим порядок учета сообщений. В приложении с GUI генерируются 3 типа сообщений: сообщения об ошибке, сообщения подтверждения и сообщения уве­домления. Сообщения об ошибке (например, Требуется пароль) и сообщения под­тверждения (например, Вы действительно хотите удалить клиента?) указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не об­разуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции. С другой стороны, уведомление является независимым элементарным процессом. Например, при попытке получить из банкомата сумму денег, превышающую их количество на счете, генерируется сообщение Не хватает средств для завершения транзакции. Оно является результатом чтения информации из файла счета и фор­мирования заключения. Сообщение уведомления рассматривается как внешний вывод.

Данные для определения ранга и оценки сложности транзакций и файлов приведе­ны в табл. 7.4-7.8 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на 2 файла и имеет 7 элементов данных, по табл. 7.4 назначается средний ранг и оценка сложности 4.

Таблица 7.4 - Ранг и оценка сложности внешних вводов

Таблица 7.5 - Ранг и оценка сложности внешних выводов

Таблица 7.6 - Ранг и оценка сложности внешних запросов

Таблица 7.7 - Ранг и оценка сложности внутренних логических файлов

Таблица 7.8 - Ранг и оценка сложности внешних интерфейсных файлов

Отметим, что если во внешнем запросе ссылка на файл используется как на этане ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется и на элемент данных (однократный учет). После сбора всей необходимой информации приступают к расчету метрики — ко­личества функциональных указателей FP (Function Points).

Исходные данные для расчета сводятся в табл. 7.9.

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

Таблица 7.9 - Исходные данные для расчета FP метрик (_– поле ввода)

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

FP = Общее_количество * (0,65+ 0,01 *å ¹⁴_i=1F_i), (7.1)

где F_i — коэффициенты регулировки сложности.

Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 - случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное.

Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл. 7.10).

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

Область применения метода функциональных указателей — коммерческие инфор­мационные системы.