Количество дефектов / количество строк кода

Фаза кодирования в большинстве проектов занимает от 7% до 20% трудозатрат, поэтому более важным является качество кода, а не его объем.

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

Первой и наиболее удачной альтернативой методу подсчета исходных строк кода стала разработанная в 1979 году Алланом Альбрехтом из IBМ методология, названная «Анализ показателей функциональности» (FPA, от Function Points Analysis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не «со стороны» ее внутренних свойств (таких, как LOC). В результате анализа исходных требований к ПС и выяснения реальных потребностей пользователей определяется объем функциональных возможностей системы, показателями которых служат функции обработки информации настолько низкого уровня, насколько они укладываются в систему мышления пользователей, а кроме функций — данные, которые эти функции обрабатывают. Таким образом, методология FPA базируется на идее декомпозиции функций и данных до предельно допустимого (с точки зрения пользователя) уровня. Объем функциональных возможностей ПС (далее просто функциональный размер) определяется в так называемых условных единицах функциональности FP — от Function Points.

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

Метод функциональных точек позволяет решать следующие задачи:

• · Оценивать категории пользовательских бизнес-функций.
• · Разрешить проблему, связанную с трудностью получения LOC — оценок на ранних стадиях жизненного цикла.
• · Определять количество и сложность входных и выходных данных, их структуру, а также внешние интерфейсы, связанные с программной системой.

В методе функциональных точек используется 5 информационных характеристик.

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

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

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

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

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

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

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

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

программный трудоемкость жизненный цикл.