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

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

На практике широко используются оценки, основанные на размере программного продукта числе строк кода. (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 была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня.