Методы получения оценок для проекта программного изделия

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

Очевидно, что оценка трудозатрат на разработку изделия опре­деляется производительностью труда разработчиков, на которую влияет следующая совокупность факторов:

1. Человеческий фактор, связанный с размером и опытом орга­низации — разработчика программного обеспечения.

2. Проблемный фактор, определяемый сложностью проблемы, которая должна быть решена и числом возможных изменений в ис­ходных требованиях и ограничениях.

3. Факторы технологии разработки, которые могут быть оха­рактеризованы используемыми методами анализа и проектирова­ния, имеющимися средствами CASE и средствами контроля и т.п.

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

5. Ресурсные факторы, характеризующие наличие ресурсов для разработки программных изделий (технические, программные сред­ства и специальные средства автоматизации разработки).

Перечисленные факторы оказывают различное влияние на про­изводительность труда разработчиков. Наибольшее воздействие, как показывает многолетний опыт, оказывают факторы программ­ной продукции — изменения производительности могут достигать 150%, в то время как изменения за счет ресурсных факторов не пре­вышают 50%.

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

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

1. Откладывайте оценку на более поздний срок.

2. Используйте для оценки простые методы декомпозиции.

3. Разрабатывайте и используйте эмпирические модели для оценки стоимости и усилий.

4. Приобретайте и используйте одно или несколько автоматизи­рованных средств для получения оценок.

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

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


При этом оценка стоимости и усилий может быть проведена поша­гово применительно к отдельным блокам программного изделия.

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

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

11.4.1. Методы функциональной декомпозиции

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

На практике широко используются оценки, основанные на раз­мере программного продукта — числе строк кода. (LOC — lines of code.) Данные о числе строк кода при оценке проекта программно­го изделия используются:

• как оценочные переменные для разрабатываемого проекта ("размер" его отдельных элементов);

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

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


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

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

1. Получить интегральную оценку для всего проекта в целом, используя суммарное число строк кода и усредненные показатели производительности и стоимости работ. В результате будет получе­на оценка общих затрат на проектирование изделия в рублях и оценка усилий (в человеко-месяцах) на разработку проекта.

2. Получить оценку затрат и усилий для каждой отдельной функции, используя для каждой функции свои Показатели по про­изводительности и стоимости работ. Этот подход дает более точ­ные оценки, но требует более детальной информации из прошлых проектов.

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

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


Значительные рас­хождения в оценках могут быть из-за:

• неадекватного понимания сферы применения проекта или не­правильной интерпретации границ его использования;

• неправильных или устаревших данных о производительности труда в LOC-методе или их несоответствия прикладной области.

В этом случае необходимо выявить причину расхождения оце­нок и провести повторные расчеты.

 

11.4.2. Эмпирические оценочные модели

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

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

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

Одной из наиболее распространенных и используемых на прак­тике является Конструктивная модель стоимости — СОСОМО (Constructive Cost Model). Эта модель применима к трем типам про­граммных систем:

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

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

3. Встроенный тип — когда проект разрабатывается внутри очень строгих ограничений и требований.

Конструктивная модель стоимости представлена иерархией мо­делей:

1. Базовая модель — основная — это статическая модель с одной переменной.


Модель позволяет рассчитать усилия и стои­ мость разработки программного изделия. Параметром модели слу­жит размер изделия в тысячах строк кода (KLOC).

Базовая модель дает возможность получить не только интег­ральные оценки показателей трудозатрат в целом по всему проекту, но и определить трудозатраты и сроки выполнения работ как по фазам ЖЦПИ, так и по основным видам деятельности.

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

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

Основная особенность детальной модели — трехуровневая ие­рархическая декомпозиция программного изделия: система — под­система — модуль. Другое отличие от промежуточной модели со­стоит в том, что коэффициенты изменения трудоемкости определя­ются индивидуально для каждой фазы ЖЦПИ.

Для оценки стоимости и затрат усилий на разработку исполь­зуются следующие уравнения базовой модели СОСОМО:

Е = а • (KLOC) • ехр (Ь);

D = с - (Е) • exp (d),

где Е —

требуемые усилия (в человеко-месяцах);

D — хронологическое время разработки (в месяцах);

а, Ь, с, d — коэффициенты, представленные в табл. 11.1.

Таблица 11.1

Тип программного проекта	а	b	с	d
1. Изолированный 2. Полуизолированный 3. Встроенный	2,4 3,0 3,6	1,05 1,12 1.20	2,5 2.5 2.5	0,38 0,35 0,32

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

1. Атрибуты программного продукта:

• требуемая надежность;

• размер прикладной базы данных;

• сложность программного продукта.

2. Атрибуты технических средств:

• ограничения на время прогона программы;

• ограничения на объем памяти;

• требуемое время цикла обработки.

3. Атрибуты персонала разработчиков:

• квалификация системного аналитика;

• опыт в данной прикладной области;

• опыт работы с принятой в проекте средой разработки.

4. Атрибуты среды проектирования:

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

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

Каждый из перечисленных атрибутов располагается в пределах шкалы значений, диапазон которой изменяется от "очень низкий" до "чрезвычайно высокий". На основе специально составленной таблицы, основанной на опыте разработки подобных проектов, оп­ределяется множитель корректировки усилий. Типичные значения этих множителей лежат в пределах от 0,9 до 1,4.


Содержание раздела

---

---