Методики оценки затрат на разработку программного продукта.

2 вида методик:

1. Инженерно-технические методики.

2. Математические методики.

Инженерно- технические методики:

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

2. Метод алгоритмического анализа – используется некий алгоритм, по которому производится расчет стоимости. Алгоритм составляется по спецификации на ПО. Если спецификация четкая и правильная, метод дает хорошие оценочные результаты.

3. Пошаговый метод – полуалгоритмический метод, делается оценка стоимости по уровням разработки. Оценка по уровням идет с помощью метода ЭО (1 уровень – главное меню. 2 – подменю, …). Складывая стоимость, получаем стоимостную оценку (хорошие результаты).

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

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

6. Психологический метод – объявляется конкурс на исполнителя. Заказчик формирует задачу и ждет начальные предложения от фирм-разработчиков (как разработать, средства и методы, стоимость). По такой методике работают все фонды (РФФИ, Сореса,…).

Математические методы оценивают:

  • общую стоимость разработки.
  • срок завершения разработки.

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

, где

E(t) – суммарные затраты на момент времени t.

k – общая стоимость системы.

a – максимальные затраты за единицу времени.

Ежегодные затраты на систему:


Зависимость Рэлея:

a – максимальные затраты за единицу времени.

От 0 до Tmax – период создания системы.

От Tmax – период сопровождения системы.


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

1. Количество задач, решаемых при создании программного продукта, конечно.

2. Последовательность решения задач образует пуассоновский поток случайных событий с интенсивностью λ.

3. Количество исполнителей пропорционально числу решаемых задач (каждый исполнитель работает над своим модулем независимо от других исполнителей).

4. Зависимость вероятности правильного решения от времени выражается прямой пропорциональной зависимостью:

Для пуассоновского потока вероятность того, что в интервале [0.t] не произошло ни одного события, имеет показательное распределение.

T – момент времени, когда событие произошло, т.е. задача решена. Тогда по определению функции распределения:

Вероятность того, что событие произошло:

Скорость решения задачи (частота событий) – плотность распределения случайной величины (производная от функции распределения :

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

Прореженные потоки называются p-преобразованиями. Согласно свойствам пуассоновского потока p-преобразованный поток – пуассоновский поток с интенсивностью pλ. Для потока правильных решений выписывается соотношение:

(1)

=> скорость правильного решения:

(2)

Если вероятность правильного решения задачи p является функцией времени, то по определению функции распределения выражения (1) и (2) примут следующий вид:

 
Согласно допущению 4 P(t)=α·t =>

Пусть , тогда

И общие затраты

Ежегодные затраты выражаются как производная от общих затрат:

Исходят из того, что нужно рассчитать 2 параметра.

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

Из опыта крупных компаний следует, что допущения 1-4 выполняются.