Научная электронная библиотека

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

ОЦЕНКА ЗАТРАТ НА РАЗРАБОТКУ ППП

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

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

Но в любом случае при анализе экономической эффективности приходится оценивать суммарные затраты C_s на ППП за весь его жизненный цикл, состоящие из затрат на разработку С_Р, эксплуатацию С_э и сопровождение С_с (рис. 19): C_s = С_Р+ С_э + С_с.

Рис. 19. Распределение эффекта и затрат в жизненном цикле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 1. Оценка размера разрабатываемого продукта. Раньше основной мерой оценки являлось количество строк кода (LOC - Lines Of Code).

В настоящее время чаще используют количество функциональных точек (FPs - Function Points).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

k₁ - требуемая надежность ПО (2...2,5);

k₂- размер базы данных (1,05...1,1);

k₃ - сложность программного изделия (2,3).

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

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

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

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

k₇ - цикл обращения к ЭВМ (1,2...1,3).

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

k₈ - квалификация аналитика (0,6...0,8);

k₉ - опыт работы аналитика (0,7...0,8);

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

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

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

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

k₁₃ - применение методов современного программирования (0,6...0,7);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Составляющие затрат на эксплуатацию, влияющие на процесс разработки ППП

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

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

Затраты на производство и внедрение каждого экземпляра комплекса программ включают в себя затраты:

 на тиражирование носителей программ и документации при массовом производстве сложных ППП;

 на подготовку каждого экземпляра ППП к конкретным условиям применения перед использованием;

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

Затраты на эксплуатацию реализующей ЭВМ в основном связаны со стоимостью затраченного машинного времени.

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

Составляющие затрат на сопровождение, влияющие на процесс разработки ППП

Сопровождение сложных ППП состоит в их развитии и модернизации, в обнаружении и устранении ошибок, а также в тиражировании и конфигурационном контроле распространяемых версий. Долгоживущие, многократно модернизируемые и широко тиражируемые ППП требуют довольно больших затрат на сопровождение, и перспективы массового использования ППП могут заметно влиять на затраты при его разработке. Эти затраты в течение жизненного цикла могут значительно (в 5-10 раз) превышать затраты на разработку того же ППП (табл. 15).

Затраты на обнаружение и устранение ошибок в ППП определяются двумя факторами: затратами на обнаружение каждой ошибки и затратами на устранение выявленных ошибок при формировании очередной версии.

Затраты на развитие и модернизацию программ близки по содержанию к затратам на первичную разработку программ С_Р. В процессе сопровождения обычно эксплуатируется та же технологическая система, которая использовалась при первичной разработке ППП. Поэтому в качестве опорной можно использовать величину С_Р с учетом поправочного коэффициента. При этом следует учитывать наличие готовой технологической базы для сопровождения, заложенной при первичной разработке, что снижает или исключает влияние некоторых факторов в составе С_Р

Затраты на тиражирование каждой версии включают совокупные затраты на производство экземпляра копии ППП, его установку в реализующей ЭВМ и освоение для эксплуатации.

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