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

Лабораторная работа № 22

«Оценка затрат на разработку ПО»

 

 

Цель: Освоить основы оценки затрат на разработку ПО.

Содержание отчета:

1) Цель, название лабораторной работы.

2) Документирование затрат на разработку ПО.

Теория

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

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

Оценка трудозатрат на разработку программного продукта определяется производительностью труда группы разработчиков, на которую влияет следующая совокупность факторов:
1. Человеческий фактор, связан с опытом и знаниями компании которая занимается разработкой ПО;
2. Ресурсные факторы, характеризующие наличие ресурсов для разработки программных продуктов;
3. Проблемный фактор, определяемый сложностью проблемы которая должна быть решена;
4. Факторы технологий разработки, которые могут быть охарактеризованы используемые методами анализа и проектирования, имеющимися средствами CASE и средствами контроля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Методы:

 Метод Дельфи

 COCOMO

 SLIM

Параметрическая оценка усилий, времени, затрат и риска. Основывается на оценке минимального времени вовлечения персонала в соответствии с законом Брука Экстремальное программирование включает «игру в планирование», которую можно рассматривать, как метод оценки затрат PERT это способ анализа задач, необходимых для выполнения проекта. В особенности, анализа времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта. PERT предназначена для очень масштабных, единовременных, сложных, не рутинных проектов. Техника подразумевала наличие неопределённости, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих.

 Метод Дельфи.

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

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

Трудоемкость = ab(KLOC0)bb [человеко-месяцев]

Срок разработки или длительность = cb(Трудоемкость)db [месяцев]

Число разработчиков = Трудоемкость/ Срок разработки [человек]

 Коэффициенты ab, bb, cb и db берутся из специальных таблиц Средний уровень рассчитывает трудоемкость разработки как функцию от размера программы и множества «факторов стоимости», включающих субъективные оценки характеристик продукта, проекта, персонала и аппаратного обеспечения. Детальный уровень включает в себя все характеристики среднего уровня с оценкой влияния данных характеристик на каждый этап процесса разработки ПО

 

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

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

Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:

Размер проекта (P) чаще всего исчисляется в количестве строк кода, хотя известны случаи успешного применения модели и для других единиц, например функциональных точек. C – фактор среды, некая технологическая константа, учитывающая, помимо уровня технологий, также и производительность персонала, которая может различаться от команд к команде. td – ограничение на срок поставки (в годах).

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