Оценка стоимости ПО

Лекция №8

Развитие моделей, методов и средств оценки стоимости программного обеспечения (ПО) достигло уровня практического применения. Однако из-за отсутствия информации, средств и специалистов они не используются при разработке ПО в Украине.

1. Единицы размера ПО

В оценке стоимости ПО используют две единицы размера: строка кода Line of Code (LOC) и функциональная точка Function Point (FP).

Line of Code – это строка исходного кода ПО (исключаются пустые строки, комментарии и специфические операторы).

К преимуществам использования LOC, как единицы размера ПО, относят простоту, а недостатками являются следующие: размер проекта в LOC может быть определён только после его завершения; LOC зависит от языка программирования; LOC не учитывает качество кода.

Производительность (S) программиста с использованием LOC подсчитывается по следующей формуле

,

где n – количество строк кода, написанных программистом (LOC); m – время работы программиста (в человеко-часах).

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

Существуют также проблемы с применением LOC и в проектах, использующих несколько языков программирования. Например, 10.000 LOC языка C++ очевидно нельзя сравнивать с 10.000 LOC языка COBOL, а в случае применения автоматизированных или основанных на шаблонах, визуальных средств разработки подсчёт LOC тем менее эффективен, чем больше кода создаётся автоматически.

Function Point была введена как альтернатива LOC. Методика анализа функциональных точек была разработана А. Дж. Альбректом (A. J. Albrecht) для компании IBM в середине 70-х годов прошлого столетия, когда возникла потребность в подходе к оценке затрат труда на разработку ПО, который бы не зависел от языка и среды разработки. С 1986 года продвижение методики и разработку соответствующего стандарта продолжает International Function Point User Group (IFPUG). Эта организация разработала руководство по практическому применению методики расчёта функциональных точек Function Point Counting Practices Manual (FPCPM) и последняя версия этого документа (4.1) официально признана ISO как стандарт оценки размера ПО.

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

В соответствии с принятым стандартом [ Software engineering: IFPUG 4.1 Unadjusted functional size measurement method: Counting practices manual.– ISO/IEC.– 2003. – 430 p.] используются пять классов компонентов, на которых основывается анализ:

- внутренний логический файл Internal Logical File (ILF) – группа логически связанных данных, находящихся внутри границ приложения и поддерживаемых вводом извне;

- внешний интерфейсный файл External Interface File (EIF) – группа логически связанных данных, находящихся вне границ приложения и являющихся внутренним логическим файлом для другого приложения;

- внешний ввод External Input (EI) – транзакция, при выполнении которой данные пересекают границу приложения извне. Это могут быть как данные, получаемые от другого приложения, так и данные, вводимые в программу пользователем. Получаемые данные могут быть командами управления или статическими данными. В последнем случае может возникнуть необходимость обновить внутренний логический файл;

- внешний вывод External Output (EO) – транзакция, при выполнении которой данные пересекают границу приложения изнутри. Из ILF и EIF создаются файлы вывода или сообщения и отправляются другому приложению. Вывод также содержит производные данные, получаемые из ILF;

- внешний запрос External Inquiry (EQ) – транзакция, при выполнении которой происходит одновременный ввод и вывод. В результате информация возвращается из одного или более ILF и EIF. Вывод не содержит производных данных, а ILF не обновляются.

По использованию также выделяют компоненты:

RET (Record Element Type) – Элемент записи

FTR (File Type Referenced) – Ссылка на файл

DET (Data Element Type) – Элемент данных

Классы компонентов оцениваются по сложности и относятся к категории высокого, среднего или низкого уровней сложности. Для транзакций (EI, EO, EQ) уровень определяется по количеству файлов, на которые ссылается транзакция File Types Referenced (FTR) и количеству типов элементов данных Data Element Types (DET). Для ILF и EIF имеют значение типы элементов записей Record Element Types (RET) и DET (таблица 7.1).

Типы элементов записей это подгруппа элементов данных в ILF или EIF. Типы элементов данных – это уникальное не рекурсивное поле подмножества ILF или EIF. Уровни сложности и соответствующие им значения FTR и DET описаны в FPCPM [ Software engineering: IFPUG 4.1 Unadjusted functional size measurement method: Counting practices manual.– ISO/IEC.– 2003. – 430 p].

Например, для EI с количеством FTR от 3 и более и DET от 5 до 15 уровень сложности определяется как высокий (таблица 7.2).

Таблица 7.1

Дата добавления: 2014-01-06