Контрольные вопросы

1. Опишите дерево характеристик качества ПИ.

2. От чего зависит надежность программного изделия?

3. Для чего используется единица измерения «KAELOC»?

4. Что называется дефектом ППП? Причины появления дефектов?

5. В чем суть концепции качества «Six Sigma»?

6. Сколько дефектов может содержаться в коде программного продукта (в соответствии с нормальным распределением), если принять концепцию качества «2 »?

7. Приведите аргументы «за» и «против» внедрения в фирме, занимающейся разработкой заказного и коммерческого ПО, стандартов качества ISO 9000.

8 Оценка затрат на разработку ппп

8.1 Экономическая эффективность пи

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

Критерии эффективности могут быть разные. Например, для фирмы, занимающейся разработкой ПИ, это соотношение суммарного дохода, полученного от внедрения заказанной программы или продажи копий программы (на основе фактических или прогнозных данных) и затрат на ее разработку, производство и сопровождение. Для предприятия, внедряющего у себя ППП – это соотношение суммарного дохода от использования ППП (за расчетный период) и расходов на его покупку (заказ), эксплуатацию и сопровождение. Для предприятий, самих разрабатывающих и внедряющих у себя ППП – это соотношение суммарного дохода от использования ППП и затрат на его разработку, эксплуатацию и сопровождение за весь жизненный цикл.

Но в любом случае при анализе экономической эффективности приходится оценивать суммарные затраты С_S на ППП за весь его жизненный цикл, состоящие из затрат на разработку C_P, эксплуатацию C_Э и сопровождение C_C (рис. 8.1) [15]: C_S = C_P + C_Э + C_C.

8.2 Исследование затрат на разработку ппп

Оценка затрат на разработку программных изделий является одним из наиболее важных видов деятельности в процессе создания ПИ, хотя она и не выделена в стандарте ISO 12207 как отдельный процесс. Недооценка стоимости, времени и ресурсов, требуемых для создания ППП, влечет за собой недостаточную численность проектной команды, чрезмерно сжатые сроки разработки (проект «death march» – см. п. 5.1) и, как результат, утрату доверия к разработчикам в случае нарушения графика. С другой стороны, перестраховка и переоценка могут оказаться ничуть не лучше. Если для проекта выделено больше ресурсов, чем реально необходимо, причем без должного контроля за их использованием, то ни о какой экономической эффективности говорить не приходится. Такой проект окажется более дорогостоящим, чем должен был быть при грамотной оценке, и приведет к запаздыванию с началом следующего проекта.

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

Для решения таких проблем необходимы специальные знания, которые являются областью экономики программирования, развивающей метрологический подход к процессу производства программ [16]. Основные разделы этой дисциплины:

• структурное описание процесса производства программ в виде моделей жизненного цикла программного обеспечения, иерархической модели целей проекта, сетевых графиков работ;

• оценка стоимости ПО, планирования затрат на его разработку, анализ факторов повышения производительности труда (модели стоимости ПО);

• применение методов микроэкономики в задачах проектирования сложных систем – анализе эффективности затрат, предельном анализе чистой стоимости, анализе степени риска, условной оптимизации, теории статистических решений.

Использование этих методов позволяет решить следующие практические задачи:

• выбор оптимальной конфигурации вычислительной системы;

• согласование конфликтующих целей надежности и производительности вычислительной системы;

• оптимальное распределение ресурсов при разработке систем;

• покупка готового ППП (или его компонентов) или проведение собственной разработки;

• лизинг или покупка аппаратного обеспечения;

• оптимальный расчет бюджета проекта при разработке ППП;

• максимизация прибыли при планировании работы программистской фирмы.

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

Шаг 1. Оценка размера разрабатываемого продукта. Раньше основной мерой оценки являлось уже упоминаемое количество строк кода (LOC – Lines Of Code); в настоящее же время чаще используют количество функциональных точек (FPs – Function Points).

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

• входной элемент приложения (входной документ или экранная форма);

• выходной элемент приложения (отчет, документ, экранная форма);

• запрос (пара «вопрос/ответ»);

• логический файл (совокупность записей данных, используемых внутри приложения);

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

Шаг 2. Оценка трудоемкости в человеко-днях или человеко-месяцах. Выводится на основании размера ППП. Для такой оценки существуют два основных способа:

1) использование накопленных у фирмы-разработчика архивных данных, позволяющих сопоставить трудоемкость нового проекта с трудоемкостью предыдущих проектов аналогичного размера. Однако это возможно только при следующих условиях:

• в организации аккуратно документируются реальные результаты предыдущих проектов;

• по крайней мере один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

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

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

Наибольшее значение в составе С_Р при разработке сложных программных комплексов имеют следующие составляющие затрат [15, 17]:

• на непосредственное проектирование, программирование, отладку и испытания программ в соответствии с требованиями пользователя или заказчика;

• на изготовление опытного образца ППП как продукции производственно-технического назначения, допускающего тиражирование;

• на подготовку и применение технологий и программных средств автоматизации разработки программ (программная «энерговооруженность»);

• на электронно-вычислительную технику, используемую для автоматизации разработки данного ППП (аппаратная «энерговооруженность»);

• на подготовку и повышение квалификации специалистов-разработчиков.

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

Таблица 8.1  Основные составляющие затрат в процессе разработки

Составляющие затрат	Группы затрат	Основные факторы, влияющие на составляющую затрат
На непосредственную разработку комплекса программ	Затраты по этапам разработки Затраты по категориям специалистов	Объем ППП Надежность функционирования ППП Ограничения реализующей ЭВМ Длительность разработки ППП Длительность эксплуатации ППП Переносимость программ Уровень технологии разработки ППП Уровень языка проектирования ППП
На изготовление опытного образца ППП	Затраты на изготовление магнитных носителей ППП Затраты на изготовление документации ППП	Объем ППП Уровень технологии разработки ППП Способ материализации программ
На технологию и программные средства автоматизации разработки ППП	Затраты на создание технологий проектирования ППП Затраты на внедрение ТП ППП Затраты на эксплуатацию ТП ППП	Объем ППП Уровень технологии разработки ППП Уровень языка проектирования ППП Длительность эксплуатации ППП
Продолжение таблицы 8.1
На ЭВТ, используемую для разработки ППП	Затраты на реализующую ЭВТ Затраты на технологическую ЭВТ Затраты на моделирующую ЭВТ	Объем ППП Уровень технологии разработки ППП Длительность разработки ППП Степень использования ЭВТ для разработки ППП Характеристики ЭВТ
На подготовку и повышение квалификации специалистов разработчиков		Предметная квалификация Технологическая квалификация Программистская квалификация

Шаг 3. Оценка стоимости проекта. Здесь также используются либо сравнительный анализ, либо аналитические методы оценки, например, модель СОСОМО (Constructive COst MOdel - конструктивная модель стоимости - КОМОСТ Б. Боэма), разработанная в начале 80-х годов [11].

КОМОСТ является статистической моделью. При ее построении использовались фактические данные по 63 программным проектам. Для каждого проекта определялись значения 42 параметров, характеризующих создаваемое программное изделие и условия работ. Методами статистического анализа была получена аналитическая зависимость влияния 17 основных параметров на показатели затрат.

Модель КОМОСТ базируется на каскадной модели ЖЦПО (п.5.3). Это означает, что все оценки стоимости и затрат ресурсов на этапах программного проекта относятся к этапам, задаваемым каскадной моделью. Виды и содержание работ на этапах также определяются каскадной моделью.

Модель КОМОСТ представляет собой иерархию из трех моделей в порядке возрастания детальности и точности.

Первый уровень: базовая КОМОСТ. Дает первичную приближенную оценку затрат на разработку ПО.

Определив всего два входных параметра (тип разработки и объем создаваемой программы в тысячах исходных команд (строк кода) KLOC), по уравнениям затрат (таблица 8.2) можно оценить суммарную трудоемкость работ, сроки работ и число исполнителей. Кроме этого, базовая КОМОСТ дает оценки распределения указанных затрат по этапам работ.

Таблица 8.2  Основные уравнения затрат

Тип разработки	Трудоемкость работ (чел./мес.)	Сроки работ (мес.)
Распространенный	R=2,4*КLOC1,05	T=2,5*R0,38
Полунезависимый	R=3,0*KLOC1,12	T=2,5*R0,35
Встроенный	R=3,6*KLOC1,2	T=2,5*R0,32

Среднее число исполнителей (N) на проект по каждому типу разработки определяется соотношением: N=R/T, а средняя производительность труда разработчика: Р= KLOC /R.

Производительность труда не относится к основным уравнениям затрат. Она является удобным показателем для оценки проекта в целом и для сравнения проектов.

В модели КОМОСТ выделяется три типа разработок по степени их сложности.

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

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

Полунезависимый тип занимает промежуточное положение между распространенным и встроенным – это проекты средней сложности. Исполнители знакомы лишь с некоторыми характеристиками (или компонентами) создаваемой системы, имеют средний опыт работы с подобными изделиями, изделие имеет элемент новизны. Только часть требований к изделию жестко фиксируется, в остальном разработки имеют степени выбора.

Поскольку не учитываются различия в аппаратуре, квалификации исполнителей, технологической оснащенности проекта, сложности ПО, прогноз базовой КОМОСТ является весьма неточным. Только для 29% проектов относительная погрешность оценки была меньше 30%.

Второй уровень: промежуточная КОМОСТ. Дает более точную оценку стоимости затрат за счет включения 15 атрибутов, характеризующих особенности конкретного программного проекта. Выходные параметры остаются такими же, как в базовой КОМОСТ. К двум входным параметрам добавляются еще пятнадцать, распределяемых по категориям, характеризующих создаваемое ПО, используемую аппаратуру, исполнителей, технологическую оснащенность работ. Их сводное влияние на показатели затрат учитывается коэффициентом К в уравнении затрат (табл. 8.3):

,

где k_i – коэффициент затрат для i-ого атрибута стоимости.

Уравнения затрат отличаются от уравнений базовой КОМОСТ только коэффициентами. Если не брать в расчет новый коэффициент К, то различие в других коэффициентах объясняется тем, что влияние 15 атрибутов стоимости неодинаков для различных типов разработки.

Таблица 8.3  Уравнения затрат промежуточной КОМОСТ

Тип разработки	Трудоемкость работ (чел./мес.)	Сроки работ (мес.)
Распространенный	R=K*3,2*КLOC1,05	T=2,5*R0,38
Полунезависимый	R= K*3,0*KLOC1,12	T=2,5*R0,35
Встроенный	R= K*2,8*KLOC1,2	T=2,5*R0,32

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

1. Атрибуты изделия:

к₁ – требуемая надежность ПО (2…2,5);

к₂ – размер базы данных (1,05…1,1);

к₃ – сложность программного изделия (2…3);

2. Атрибуты ЭВМ:

к₄ – ограничение по быстродействию (1,3…1,5);

к₅ – ограничение на оперативную память (1,3…1,5);

к₆ – изменяемость виртуальной машины (1,1…1,2);

к₇ – цикл обращения к ЭВМ (1,2 … 1,3);

3. Атрибуты исполнителей:

к₈ – квалификация аналитика (0,6…0,8);

к₉ – опыт работы аналитика (0,7…0,8);

к₁₀ – квалификация программиста (0,9);

к₁₁ – опыт работы программиста с виртуальной машиной (0,8…0,9);

к₁₂ – опыт работы программиста с языком программирования (0,8…0,9);

4. Атрибуты проекта:

к₁₃ – применение методов современного программирования (0,6…0,7);

к₁₄ – использование инструментальных средств разработки (0,5…0,6);

к₁₅ – ограничение сроков разработки (1,3…1,5).

Точность оценки существенно возрастает. Для 68% проектов относительная погрешность оценки меньше 20%.

Третий уровень: детальная КОМОСТ. Повышает точность оценки за счет иерархической декомпозиции создаваемого ПО и учета стоимостных факторов на каждом уровне иерархии и по фазам работ.

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

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

На высшем уровне иерархии (система) используются основные соотношения проекта, такие как уравнения номинальных затрат труда и плановых сроков, с разбиением их по фазам.

Другое отличие детальной КОМОСТ от промежуточной состоит в учете влияния каждого стоимостного фактора на отдельных этапах работ. Так, например, фактор знания исполнителем данного языка программирования важен на этапе кодирования и может не иметь значения на этапе проектирования ПО.

Детальная КОМОСТ использует уравнения затрат промежуточной КОМОСТ в качестве основы для оценки. Для каждого уровня иерархии системы и каждой фазы работ имеются поправочные коэффициенты к основным уравнениям затрат. Эти поправочные коэффициенты задают относительное влияние каждого из 15 атрибутов стоимости в зависимости от фазы и уровня иерархии.

Точность оценки в сравнении с промежуточной КОМОСТ возрастает незначительно – ошибка прогноза меньше 20% для 70% проектов.

Применение детальной КОМОСТ возможно только для завершения этапа проектирования, когда определена модульная структура будущей программной системы.

Специальные исследования автора модели КОМОСТ показали, что она обладает двумя важными свойствами:

1. уравнения затрат не меняются при добавлении в модель данных по новым проектам – свойство устойчивости;

2. соотношения между факторами стоимости сохраняют постоянство при переходе от низшего уровня модели к высшим – свойство инвариантности.

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

Известны и другие модели, представляющие собой расширение модели КОМОСТ за счет введения дополнительных атрибутов стоимости [15].

Существуют программные средства оценки затрат и стоимости проекта по разработке ПО, с помощью которых можно автоматизировать этот процесс, такие как, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)) и др. Конечно, эти продукты нельзя назвать совершенными; все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «что заложишь, то и получишь», или, используя программистский сленг, принцип DIDO: Dreck In – Dreck Out). В лучшем случае с помощью таких продуктов можно получить оценку с точностью ±10%. Но даже если точность будет ±50%, это все равно лучше, чем брать данные «с потолка».

Например, ППП KnowledgePLAN создан на основе исследований, проведенных в фирме SPR, в области оценок сложности, трудоемкости и производительности при разработке программного обеспечения. Оценка и планирование в пакете KnowledgePLAN ведутся на основе статистических закономерностей, выведенных путем анализа более чем 8 тыс. успешно завершенных проектов из различных областей применения. Исходные данные для вычислений находятся в специальном репозитории, который обновляется по результатам выполнения реальных проектов. В качестве метрик для оценки размеров программного обеспечения используются методика подсчета функциональных точек и метод оценки сложности программного продукта (собственная разработка фирмы SPR) – метрика, позволяющая учесть алгоритмическую сложность разрабатываемых программ.

KnowledgePLAN имеет следующие возможности:

• формирование близкого к реальному плана работ по проекту;

• определение трудоемкости и стоимости планируемых проектов;

• учет влияния условий разработки, применяемых инструментальных средств и используемых технологий на прогнозируемую трудоемкость, сроки и стоимость разработки;

• проведение анализа «what – if» («что, если») для поиска лучших решений;

• проведение сравнительного анализа качества и производительности разработки разнотипных проектов или однотипных проектов, при выполнении которых использовались различные технологии;

• накопление статистической многомерной информации о проекте и его участниках;

• классификация проектов для принятия решения о структуре управления проектом;

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