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

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

Выполнение оценки проекта на основе LOC- и FP-метрик

Цель этой деятельности - сформировать предварительные оценки, которые позволят:

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

· составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

· в качестве оценочных переменных, определяющих размер каждого элемента продукта;

· в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.

Обсудим шаги процесса оценки.

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

 

f₁,f₂,...,f_n.

 

· Шаг 2. Для каждой функции f₁ планировщик формирует лучшую LОС_лучшi (FР_лучшi), худшую LOС_ХУДШi (FР_ХУДШi) и вероятную оценку LOС_{вероятнi} (FР_{вероятнi}). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

· Шаг 3. Для каждой функции f_i в соответствии с β-распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:

 

LOC_ожi = LOC_лучшi + LOC_худшi + 4 x LOC_{вероятнi}) / 6.

 

· Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.

Используется один из трех подходов:

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

2. для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВ_i = ПРОИЗВ_ср х (LOС_ср / LOС_ожi),

где LOC_cp - средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

Конструктивная модель стоимости

 

В данной модели для вывода формул использовался статистический подход - учитывались реальные результаты огромного количества проектов. Автор оригинальной модели - Барри Боэм (1981) - дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [1].

Иерархию подмоделей Боэма (версии 1981 года) образуют:

· базисная СОСОМО - статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;

· промежуточная СОСОМО - дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

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

Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

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

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

· встроенный тип - программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.

Уравнения базовой подмодели имеют вид

Е = a_b x (KLOC^b_b [чел-мес];

D = c_b x (E)^d_b[Mec],

 

где Е- затраты в человеко-месяцах, D - время разработки, KLOC - количество строк в программном продукте.

Заключение

 

СОСОМО II - авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

Рассмотрим возможности этой модели в задачах анализа чувствительности - чувствительности программного проекта к изменению условий разработки.

Будем считать, что корпорация "СверхМобильныеСвязи" заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО - 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.

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

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

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

Список литературы

 

1. Боэм Б. У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.

2. Липаев В. В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.

3. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.

4. Орлов С. А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.

5. Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

6. Abreu, F. В., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS'96. Santa Barbara, California 20 pp. July 1996.