Оценка затрат на разработку программного продукта

Методика расчета

Оценка затрат на разработку ПО является одним из наиболее важных видов деятельности в процессе создания ПО, хотя она и не выделена в стандарте ISO 12207 как отдельный процесс. При отсутствии адекватной и достоверной оценки невозможно обеспечить четкое планирование и управление проектом.

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

• 1. оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOC - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Под функциональной точкой понимается любой из следующих элементов разрабатываемого продукта:
  • · входной элемент приложения (входной элемент или экранная форма);
  • · выходной элемент приложения (отчет, документ, экранная форма);
  • · запрос (пара "вопрос/ответ");
  • · логический файл (совокупность записей данных, используемых внутри приложения);
  • · интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него)
• 2. оценка трудоемкости в человеко-месяцах или человеко-часах;
• 3. оценка продолжительности проекта в календарных месяцах;
• 4. оценка стоимости проекта.

Для расчетов используются Функционально ориентированные метрики.

Они косвенно измеряют программный продукт и процесс его разработки. Рассматриваются функциональность и полезность продукта. Используются 5 информационных характеристик:

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

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

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

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

• · Внешний запрос - это элементарный процесс, работающий как с вводимыми, так и выводимыми данными. Его результат это данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует данных ВЛФ, а выходная часть не несёт данных вычисляемых приложением.
• · Внутренний логический файл - это распознаваемая пользователем группа логически связанных данных, которая размещается внутри приложения и обслуживается через внешние вводы.
• · Внешний интерфейсный файл - это распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.

Данные для расчета сводятся в таблицу:

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

,

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

F_i - может иметь значения: 0-нет влияния; 1-случайное; 2-небольшое; 3-среднее; 4-важное; 5-основное.

F₁ - сколько средств связи требуется для передачи или обмена информации с приложением.

F₂ - как обрабатываются распределённые данные.

F_{3 -} нуждается ли пользователь в фиксации времени ответа или производительности.

F_{4 -} насколько распространена текущая аппаратная система на которой будет выполнятся приложение.

F₅ - как часто выполняются транзакции.

F₆ - какой % информации вводится в оперативном режиме.

F₇ - приложение проектировалось для обеспечения эффективной работы конечного пользователя.

F₈ - как много внутренних файлов обновляется в транзакции.

F₉ - выполняет ли приложение интенсивную логическую или математическую обработку.

F₁₀ - приложение разрабатывалась для удовлетворения требований одного или многих пользователей.

F₁₁ - насколько трудны инсталляция и преобразование приложения.

F₁₂ - насколько эффективно и/или автоматизированы процедуры запуска, резервирования и восстановления.

F₁₃ - была ли спроектирована, разработана и поддержана возможность инсталляции в разных местах для различных организаций.

F₁₄ - была ли спроектирована, разработана и поддержана в приложении простота изменений.

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

Произведем расчет следующих характеристик по формулам: