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

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

СИСТЕМЫ

7.1. Методология анализа функционального размера

7.1.1. Истоки и перспективы

Организации-разработчики программных систем в течение многих лет иска­ли приемлемые количественные методы для измерения производительности труда, оценивания эффективности процессов и управления затратами на разработку ПС. Камнем преткновения было отсутствие надежной единицы измерения размера про­граммного обеспечения. Такая, на первый взгляд очевидная метрика, как число строк исходного кода SLOC (Source Lines of Code), не могла давать достоверные результаты, поскольку не учитывала следующее:

•  число строк исходного кода зависит от уровня мастерства программиста.
Фактически, чем выше мастерство программиста, тем меньшим количеством строк
кода ему удастся обойтись для реализации определенной функциональной возмож­
ности (или функциональности) ПС;

•  высокоуровневые языки или языки визуального программирования тре­
буют гораздо меньшего числа строк кода, чем, например, язык Ассемблера или С
для отражения одной и той же функциональности. Достаточно представить себе два
приложения, имеющих одни и те же функциональные возможности (те же экраны,
отчеты, таблицы базы данных), но реализованные на разных языках, например, С и
Clarion. Очевидно, что существует обратная взаимосвязь между уровнем языка и
производственной выработкой программиста;

•  фактическое число SLOC остается неизвестным до тех пор, пока проект
не будет почти завершен. Поэтому SLOC нельзя использовать для предварительной
оценки усилий на разработку и построения план-графика проекта;

•  в программистском сообществе не достигнуто соглашения о методе под­
счета строк кода. Языковые конструкции, используемые, например, в Visual C++,
Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для
любых приложений, в том числе использующих комбинацию различных языков;

•  заказчику сложно понять, каково соотношение указанных им функцио­
нальных и нефункциональных (технических) требований к ПС и объемов програм­
мистской работы.

Нужна была новая мера размера, применяемая унифицировано по всему ЖЦ ПС, понятная заказчику и легко интерпретируемая в терминах прикладной области его деятельности. И такая мера появилась в конце 70-х годов.

Однако нужно сразу отметить, что несмотря на проблемы, SLOC по-прежнему остается той единицей измерения размера, к которой «приводятся» (в которую конвертируются) результаты вычисления размера, выполненные другими методами, для последующего использования в «старых» моделях трудоемкости, надежности, тестирования, стоимости и др. Ее вполне можно также применять и для определения размера ПС на завершающих стадиях разработки и при сопровож­дении (разумеется, учитывая вышеуказанные замечания) [1].

Первой и наиболее удачной альтернативой методу подсчета исходных строк кода стала разработанная в 1979 году Алланом Альбрехтом из IBМ методология,

названная «Анализ показателей функциональности» (FPA, от Function Points Analy­sis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не «со стороны» ее внутренних свойств (таких, как SLOC). В результате анализа ис­ходных требований к ПС и выяснения реальных потребностей пользователей опре­деляется объем функциональных возможностей системы, показателями которых служат функции обработки информации настолько низкого уровня, насколько они укладываются в систему мышления пользователей, а кроме функций - данные, ко­торые эти функции обрабатывают. Таким образом, методология FPA базируется на идее декомпозиции функций и данных до предельно допустимого (с точки зрения пользователя) уровня¹. Объем функциональных возможностей ПС (далее просто функциональный размер} определяется в так называемых условных единицах функ­циональности, УЕФ (или FP - от Function Points).

В течение пяти лет с момента появления, методология FPA и метод расчета размера отшлифовывались А. Альбрехтом и проходили практическую апробацию, а в середине 80-х годов была создана Международная группа пользователей показа­телей функциональности (IFPUG, от International Function Points User Group), кото­рая и поддерживает дальнейшую эволюцию метода.

Текущая версия метода (версия 4.1), называемого базовым методом опреде­ления функционального размера (FP-методом) зафиксирована в практическом ру­ководстве по расчету размера в единицах функциональности СРМ (Counting Prac­tices Manual, 4.1), выпущенном в январе 1999 и доступном на сайте IFPUG: www.ifpug.org. Подробнее положения FP-метода рассматриваются далее в этом разделе.

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

В 1992 Группы Пользователей (User Groups)² из Австралии, Великобритании, Нидерландов и США, занимающихся измерением программных средств, создали рабочую группу WG12 в рамках подкомитета ISO/IEC/JTC1/SC7 и предложили концепцию измерения функционального размера (FSM, от Functional Size Measure­ment) и проект одноименного стандарта измерения размера - ISO/IEC 14143. Этот стандарт поможет решить проблему несовместимости методов и создать эталонную модель метода. Структура стандарта вкратце рассматривается в разделе 7.3.

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

[2]

² Группы Пользователей (User Groups) - добровольные национальные или междуна­родные профессиональные сообщества пользователей, создаваемые для анализа состояния проблемы, представляющей общий интерес, и выработки согласованных коллективных ре­шений (или стандартов). Примеры - IFPUG (International FP) , UFPUG (UK FP), LUG (Li­nux), APCUG (Association of Personal Computer) и др.

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

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

Поскольку базовый FP-метод ориентирован для применения при разработке информационных систем, процесс проектирования которых является в большинст­ве случаев процессом, «управляемым данными», размер и функциональная слож­ность измеряемого ПК оценивается исходя из оценок сложности данных, являю­щихся входными, выходными и обрабатываемыми данными для каждой функции ПК.

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