Руководство программным проектом

Трассировка и контроль

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

· могут быть перераспределены ресурсы;

· могут быть реорганизованы задачи;

· могут быть пересмотрены выходные обязательства.

3. Планирование проектных задач

Основной задачей при планировании является определение WBS - Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

Системный анализ проводится с целью:

1. выяснения потребностей заказчика;

2. оценки выполнимости системы;

3. выполнения экономического и технического анализа;

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

5. определения стоимости и ограничений планирования;

6. создания системной спецификации.

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

Анализ требований дает возможность:

1. определить функции и характеристики Программного продукта;

2. обозначить интерфейс продукта с другими системными элементами;

3. определить проектные ограничения программного продукта;

4. построить модели: процесса, данных, режимов функционирования продукта;

5. создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

Рис. 2.2. Типовая структура распределения проектных работ

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

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

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

Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует "непрерывность движения к объединению". Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.

Основной рычаг в планирующих методах - вычисление границ времени выполнения задачи.

Обычно используют следующие оценки:

1. Раннее время начала решения задачи Tⁱⁿ_min (при условии, что все предыдущие задачи решены в кратчайшее время).

2. Позднее время начала решения задачи Tⁱⁿ_max (еще не вызывает общую задержку проекта).

3. Раннее время конца решения задачи T^out_min

T^out_min = Tⁱⁿ_min + T_реш

4. Позднее время конца решения задачи T^out_max

T^out_max = Tⁱⁿ_max + T_реш.

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

Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач.

Рекомендуемое правило распределения затрат проекта - 40-20-40:

· на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ - 5%);

· на кодирование - 20%;

· на тестирование и отладку - 40%.

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

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

Выполнение оценки проекта на основе 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-оценка, взятая из метрического базиса (соответствует средней производительности);

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

В данной модели для вывода формул использовался статистический подход - учитывались реальные результаты огромного количества проектов. Автор оригинальной модели - Барри Боэм (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.