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

Ãëàâà 2
Ðóêîâîäñòâî ïðîãðàììíûì
ïðîåêòîì
В этой главе детально рассматриваются вопросы руководства программным проектом. Читатель знакомится с основными понятиями процесса руководства. Далее
здесь описываются пять видов защитной деятельности: планирование проекта,
управление риском, управление персоналом, управление документацией и управление конфигурацией.
Îñíîâíûå ïîíÿòèÿ ðóêîâîäñòâà ïðîåêòîì
Руководство программным проектом является защитной деятельностью программной инженерии, пронизывающей все виды основной деятельности — подготовку,
планирование, моделирование, конструирование и развертывание (рис. 2.1). Мало
того, именно руководство программным проектом интегрирует в жизненный цикл
ПО все остальные виды защитной деятельности.
Ðèñ. 2.1. Ðóêîâîäñòâî â ïðîöåññå ðàçðàáîòêè ÏÎ
Руководство применяется ко всем четырем «П» разработки: персоналу (тем, кто
это делает), процессу (порядку, в котором это делается), проекту (среде, в которой
это делается), продукту (итогу всех дел).
50
Ãëàâà 2. Ðóêîâîäñòâî ïðîãðàììíûì ïðîåêòîì
Цель любого программного проекта состоит в производстве определенного
программного продукта. Понятие «продукт» задает не только текст на языке программирования и откомпилированный двоичный код. Например, туда включаются
документация, отчеты по промежуточным итогам, результаты проверок, оценки
качества и т. д. Эти элементы обычно называют артефактами. То, как в рамках
проекта создается продукт, представляет собой процесс. Поскольку критичным для
успеха дела является взаимодействие членов команды, в рассмотрение включается
персонал.
Персонал должен быть организован как эффективная команда, в которой обеспечено эффективное взаимодействие и которая мотивирована на выполнение работы
с высоким качеством. Требования к продукту должны быть переданы (без искажений) от заказчика к разработчикам, правильно разбиты на части и распределены
для обработки между инженерами команды. Процесс должен быть адаптирован как
к персоналу, так и к продукту. Должна быть правильно сконфигурирована среда
для выполнения процесса, разумно выбран такой набор рабочих задач, который
гарантирует оптимальную загрузку персонала. Наконец, организация проекта
должна быть нацелена на успешную работу команды.
Руководство проектом заключается в управлении производством продукта
в рамках отведенных средств и времени. Поскольку для этого требуются человеческие ресурсы, то для управления проектом необходимы не только технические
и организационные навыки, но еще и искусство управления людьми. Управление
проектом — очень сложное занятие, привлекающее широкий спектр многоплановых
знаний и навыков.
Для проведения успешного проекта нужно понять объем предстоящих работ,
возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи,
необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается
перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ [52, 88, 94].
Проблемы управления программными проектами начали проявляться уже
в 60–70-х годах 20-го столетия. Именно в это время заговорили о провалах многих
программных проектов. Причем подавляющее большинство провалов связывалось
с крупными недостатками в руководстве разработкой.
Обычно применяемые методики заимствовали опыт управления проектами из
других инженерных областей и «пробуксовывали» при создании программного
обеспечения. В чем причина? Ответ прост: разработка ПО существенно отличается
от разработки обычных, физических продуктов. Приведем примеры.
Менеджер авиационного проекта физически наблюдает результаты производства самолета и легко замечает, если работа отстает от графика. Напротив, менеджер программного проекта не может увидеть рост программного продукта — он
нематериален, а значит ему нужны иные средства для наблюдения и контроля.
Большие программные проекты чаще всего оригинальны, то есть сильно отличаются от прошлых проектов и являются инновационными. Поэтому, чтобы уменьшить промахи в планировании, менеджеры должны полагаться лишь на личный
Îñíîâíûå ïîíÿòèÿ ðóêîâîäñòâà ïðîåêòîì
51
опыт и «чутье». Но стремительные и революционные изменения в компьютерных
средствах и технологиях быстро сводят их к нулю.
Таким образом, отличительной особенностью многих программных проектов
является предрасположенность к нарушению ограничений по бюджету и времени.
И эту черту надо обязательно учитывать при организации руководства.
Обсудим характерные точки руководства проектом.
Íà÷àëî ïðîåêòà
Перед планированием проекта следует:
установить цели и проблемную (предметную) область проекта;
обсудить альтернативные решения;
выявить технические и управленческие ограничения.
Без этой информации нельзя обоснованно оценить стоимость, реально распределить задачи проекта, составить такой план руководства проектом, который
обеспечивает всестороннее отображение состояния дел.
Цели и область проекта определяются разработчиком и заказчиком. Цели идентифицируют задачи проекта (без обсуждения способов их решения). Проблемная
область задает основные функции ПО, их количественные границы, а также иные
характеристики.
ÏÐÈÌÅ×ÀÍÈÅ
Другое название проблемной области — предметная область. Предметная область
(domain) — это область знаний или деятельности с характерными понятиями и терминами, которыми владеют профессионалы, работающие в данной области.
Далее обсуждаются альтернативные решения. Менеджеры и инженеры выбирают лучший подход с точки зрения функциональных ограничений, бюджетных
ограничений, возможностей персонала, технических интерфейсов и т. д.
Èçìåðåíèÿ, ìåðû è ìåòðèêè
Измерения помогают понять как процесс разработки продукта, так и сам продукт.
Измерения процесса производятся в целях его улучшения, измерения продукта —
для повышения его качества. В результате измерения определяется мера — количественная характеристика какого-либо свойства объекта. Путем непосредственных
измерений могут определяться только опорные свойства объекта. Все остальные
свойства оцениваются в результате вычисления тех или иных функций от значений опорных характеристик. Вычисления этих функций проводятся по формулам,
которые дают числовые значения и называются метриками.
В IEEE Standard Glossary of Software Engineering Terms метрика определена как
мера степени обладания свойством, имеющая числовое значение. В программной
инженерии понятия мера и метрика очень часто рассматривают как синонимы.
Типичные вопросы в этой области:
Как выбрать наиболее подходящие метрики для процессов и продуктов?
Как использовать полученные данные?
52
Ãëàâà 2. Ðóêîâîäñòâî ïðîãðàììíûì ïðîåêòîì
Корректно ли использовать измерения для сравнения людей, процессов, про-
дуктов?
Ïðîöåññ îöåíêè
При планировании программного проекта надо оценить людские ресурсы (в человеко-месяцах), продолжительность (в календарных датах), стоимость (в тыс. $).
Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям
похож на предыдущий проект, вполне вероятно, что потребуются такие же ресурсы,
время и деньги. Ну, а если такого аналога нет? Кроме того, может оказаться, что
прошлого опыта недостаточно. Словом, надо изучать способы оценки.
Àíàëèç ðèñêà
На этой стадии исследуется область неопределенности, имеющаяся в наличии
перед созданием программного продукта. Анализируется ее влияние на проект.
Действительно ли поняты пожелания заказчика? Можно ли реализовать требуемые
функции в рамках ограничений проекта? Нет ли скрытых от внимания трудных
технических проблем? Не станут ли изменения, проявившиеся в ходе проекта, причиной недопустимого отставания по срокам? В результате принимается решение:
выполнять проект или нет. Специальный аппарат анализа позволяет атаковать риск
прежде, чем он атакует программный проект.
Ïëàíèðîâàíèå
В каждом программном проекте существует планирование, но не все планы одинаковы. Предусмотрена ли в плане возможность усовершенствования? Не допускает
ли план работу в режиме «ошпаренной кошки»? Имеется ли резерв времени на непредвиденный случай? Как измеряется прогресс? По формуле «что еще сделать?»,
или есть набор хорошо расставленных вех — контрольных рубежей.
Суть планирования заключается в следующем. Определяется набор задач проекта. Устанавливаются связи между задачами, оценивается сложность каждой задачи. Определяются людские и другие ресурсы. Создается сетевой график задач,
проводится его временная разметка.
Òðàññèðîâêà è êîíòðîëü
Каждая задача, помеченная в плане, отслеживается руководителем проекта. При
отставании в решении задачи применяются утилиты повторного планирования.
С помощью утилит определяется влияние этого отставания на промежуточную
веху и общее время разработки. Под вехой понимается временная метка, к которой
привязано подведение промежуточных итогов.
В результате повторного планирования:
могут быть перераспределены ресурсы;
могут быть реорганизованы задачи;
могут быть пересмотрены выходные обязательства.
Ïëàíèðîâàíèå ïðîãðàììíîãî ïðîåêòà
53
Ðèñ. 2.2. Ïîñëåäîâàòåëüíîñòü äåéñòâèé ïðè ïëàíèðîâàíèè
Ïëàíèðîâàíèå ïðîãðàììíîãî ïðîåêòà
Эффективность руководства программным проектом целиком определяется правильностью планирования работ, которые необходимы для его выполнения. План
помогает предвидеть возможные проблемы разработки ПО и ввести защитные меры
для их предупреждения и решения. План создается на начальном этапе проекта
(в ходе основной деятельности «планирование) и рассматривается менеджерами
и инженерами-разработчиками как руководящий документ, выполнение которого
должно привести к успешному завершению проекта. Этот начальный план должен
максимально подробно описывать все этапы работы проекта.
Как показано на рис. 2.2, планирование является многошаговым итерационным
процессом. Очень важно, чтобы план регулярно пересматривался — ведь по мере
54
Ãëàâà 2. Ðóêîâîäñòâî ïðîãðàììíûì ïðîåêòîì
работы в проект непрерывно поступают новые сведения. Важными факторами,
которые должны учитываться при разработке плана, являются контрактные обязательства фирмы, требования заказчика, бюджетные и временные ограничения. Их
изменения должны оперативно отражаться в плане работ программного проекта.
Планирование начинается с оценки предметной области программной системы,
ее размера, трудозатрат и времени на разработку. Формируется команда исполнителей, распределяются их функции. При этом учитываются ограничения по времени, бюджету, наличию и возможностям сотрудников, материально-техническому
обеспечению. Затем определяются этапы разработки, контрольные вехи проекта
и перечень артефактов — результатов каждого этапа. Напомним, в состав артефактов
входит документация, макеты, отчеты, листинги, модели, программный код версий
продукта и т. д. Составляется начальный план-график (расписание) работ команды.
Далее начинается итерационная часть планирования. Выполняется текущий этап
проекта. Его ход отслеживается и контролируется. Выявляются расхождения между
реальным и плановым ходом работ.
Если зафиксированы внутренние проблемы или заказчик изменил/расширил
список требований, возможен пересмотр первоначальных оценок проекта. Такой
пересмотр может привести к модификации начального (или уже промежуточного) графика работ. Если изменения влияют на сроки завершения или стоимость
проекта, с заказчиком согласовываются новые ограничения проекта. После этого
продолжают проект — переходят к следующему этапу работы.
Конечно, опытные менеджеры закладывают в график резервы на случай неприятностей. Иными словами, в планах фиксируются пессимистические графики
работ. Но, разумеется, невозможно построить план, учитывающий все реальные
проблемы, поэтому и возникает необходимость периодической коррекции этого
руководящего документа.
Ñòðóêòóðà ïëàíà óïðàâëåíèÿ ïðîãðàììíûì ïðîåêòîì
План управления проектом должен ясно показать ресурсы, необходимые для воплощения проекта, разделение работ на этапы и временной график выполнения этих
этапов. План управления проектом должен быть составлен так, чтобы каждый знал,
что и когда ему надо делать. Существует множество стандартов для таких планов.
Но в любом случае большинство планов содержат следующие разделы.
1. Введение.
1.1. Обзор проекта. Должен определять проект, но не пытаться охватить все требования к нему. Сами требования приводятся в Спецификации требований
к программному обеспечению.
1.2. Результирующие артефакты проекта. Список всех документов, исходных
файлов и конечных программных продуктов, которые должны быть созданы.
1.3. Развитие плана. Направления ожидаемого расширения и изменения.
1.4. Ссылочные материалы.
1.5. Определения и аббревиатуры.
Ïëàíèðîâàíèå ïðîãðàììíîãî ïðîåêòà
55
2. Организация проекта.
2.1. Модель процесса. Ссылаются на тип процесса разработки, который будет
использован (например, водопадный, спиральный, инкрементальный).
2.2. Организационная структура. Описывается внутренняя организация команды.
2.3. Организационные рамки и взаимосвязи. Пути возможного взаимодействия
между организациями. Все это зависит от заинтересованных в проекте сторон. Например, здесь определяется, каким образом будет осуществляться
взаимодействие между отделом разработки и маркетинговым, будут ли это
регулярные встречи или переписка по электронной почте и т. д.
2.4. Ответственность за проект. Определяет границы ответственности, то есть
кто за что отвечает. Например, за что несет ответственность координатор
повышения эффективности команды при горизонтальной организации?
Отвечает ли он за общий успех проекта, предоставляет ли персональные
рекомендации или занимается только руководством?
3. Анализ рисков.
3.1. Цели и приоритеты. Провозглашается рабочая философия проекта.
3.2. Допущения, зависимости и ограничения.
3.3. Управление рисками.
3.4. Механизмы мониторинга и контроля. Определяют, кто будет управлять,
контролировать и (или) осуществлять проверку проекта, а также предписывает, как и когда это должно быть сделано.
3.5. План расстановки кадров.
4. Технический процесс.
4.1. Методы, инструменты и технологии. Накладываются ограничения на языки
и используемые инструменты. Может содержать информацию о повторно
используемых требованиях и использовании таких техник, как образцы
проектирования.
4.2. Документация программного обеспечения.
4.3. Функции сопровождения проекта. Описаны действия для поддержания
процесса разработки, такие как управление конфигурацией и обеспечение качества. Если же функция поддержки представлена в различных документах
(например, в плане управления конфигурациями или в плане качества), то
в этом пункте будут ссылки на эти документы. В противном случае здесь
полностью специфицируются функции поддержки.
5. Распределение работ, график и бюджет.
5.1. Распределение работ. Описывает то, как работа должна распределяться
и предоставляться после выполнения. Поскольку программная архитектура
еще не утверждена, первая версия этого пункта будет поверхностной. Детали
появляются в последующих версиях плана.
5.2. Зависимости.
56
Ãëàâà 2. Ðóêîâîäñòâî ïðîãðàììíûì ïðîåêòîì
5.3. Потребности в ресурсах. Оцениваются трудозатраты, аппаратное и программное обеспечение, необходимые для сборки и технической поддержки
продукта. Могут быть приведены результаты оценки стоимости. Этот пункт
уточняется и детализируется с каждой итерацией.
5.4. Выделение бюджета и ресурсов. Распределяются ресурсы между различными
частями проекта в течение всего его жизненного цикла. Приводятся оценки
стоимости человеко-дней, могут указываться оценки стоимости аппаратуры
и программного обеспечения.
5.5. План-график. Содержит расписание, определяющее, как и когда должны
быть выполнены различные этапы процесса.
По мере выполнения проекта план должен регулярно пересматриваться. Одни
разделы плана (например, график работ) меняются часто, другие более стабильны.
Для внесения изменений в план требуется специальная защитная деятельность,
ориентированная на обновление документов.
Ñòðóêòóðà ãðàôèêà ðàáîò ïðîãðàììíîãî ïðîåêòà
Составление графика — одна из самых ответственных работ менеджера проекта.
Здесь менеджер оценивает длительность проекта, определяет ресурсы, необходимые для реализации рабочих задач, и разворачивает последовательность задач во
времени. Как правило, это действие выполняется с помощью специализированной
утилиты планирования проекта.
Планирующие утилиты позволяют:
определить критический путь (цепочку задач, задающих длительность всего
проекта);
определить длительность критического пути;
установить для каждой задачи наиболее вероятную временную оценку (по прикладной статистической модели);
вычислить границы, определяющие временное окно для отдельной задачи.
Результат работы такой утилиты представляется в виде сетевой диаграммы.
Типовая сетевая диаграмма приведена на рис. 2.3. Она создается на основе иерархической структуры распределения работ, называемой WBS — Work Breakdown
Structure.
Первыми выполняемыми задачами являются сбор требований и анализ требований. Они закладывают фундамент для последующих параллельных задач.
Сбор требований проводится с целью:
1) выяснения потребностей заказчика;
2) оценки выполнимости программной системы;
3) выполнения экономического и технического анализа;
4) определения стоимости и ограничений планирования;
5) создания системной спецификации.
В системной спецификации описываются функции, характеристики программной системы, ограничения разработки, входная и выходная информация.
Ïëàíèðîâàíèå ïðîãðàììíîãî ïðîåêòà
57
Ðèñ. 2.3. Òèïîâàÿ ñåòåâàÿ äèàãðàììà ðàáîò ïðîåêòà
Анализ требований дает возможность:
уточнить функции и характеристики программного продукта;
обозначить интерфейс продукта с другими системными элементами;
определить проектные ограничения программного продукта;
построить модели: процесса, данных, режимов функционирования продукта;
создать такие формы представления информации и функций системы, которые
можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию анализа, содержащую конкретизированные требования к программному продукту.
Как видно из типовой структуры, задачи по проектированию и планированию
тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого
модуля можно предусмотреть параллельный путь для детального (процедурного)
проектирования, кодирования и тестирования. После получения всех модулей ПО
решается задача тестирования интеграции — объединения элементов в единое целое.
Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика.
Ромбиками на рис. 2.3 обозначены вехи — процедуры контроля промежуточных
результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст возможность менеджеру регулярно получать информацию о текущем положении дел. Вехи распространяются
и на документацию как на один из результатов успешного решения задачи.
Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить
межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, менеджер проекта должен знать задачи, лежащие на критическом
пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять
в срок все критические задачи.
1)
2)
3)
4)
5)
58
Ãëàâà 2. Ðóêîâîäñòâî ïðîãðàììíûì ïðîåêòîì
Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.
Обычно используют следующие оценки:
in
1. Раннее время начала решения задачи Tmin
(при условии, что все предыдущие
задачи решены в кратчайшее время).
in
2. Позднее время начала решения задачи Tmax
(еще не вызывает общую задержку
проекта).
out
3. Раннее время конца решения задачи Tmin
out
in
Tmin
= Tmin
+ Tðåø .
out
4. Позднее время конца решения задачи Tmin
out
in
Tmax
= Tmax
+ Tðåø .
5. Общий резерв — количество избытков и потерь планирования задач во времени,
не приводящих к увеличению длительности критического пути Têï .
Все эти значения позволяют менеджеру (планировщику) количественно оценить
успех в планировании, выполнении задач.
Рекомендуемое правило распределения затрат проекта — 40–20–40:
на анализ и проектирование приходится 40% затрат (из них на планирование
и сбор требований — 5%);
на кодирование — 20%;
на тестирование и отладку — 40%.
Данное правило отражает накопленный мировой опыт индустрии программной
инженерии и базируется на следующих фактах:
Работы, связанные со сбором и формализацией требований, определением
и детализацией архитектуры ПО, наиболее трудоемки. Они требуют привлечения специалистов высочайшей квалификации, работающих в условиях
существенной неопределенности. Ментальные усилия разработчиков здесь
максимальны: ведь приходится принимать стратегические решения, сложность
которых сравнима со сложностью их творцов.
Кодирование (программирование) хорошо проработанных проектных решений
имеет меньшую сложность. Здесь разработка переходит на тактический уровень.
Степень определенности существенно выше, применяются хорошо известные,
испытанные приемы и методики.
Трудоемкость третьего сегмента — тестирования и отладки — тоже очень ве-
лика. Это обусловлено доминирующим стилем человеческой деятельности:
«методом проб и ошибок». Никого не удивляет, что человек, выполняя работу,
часто ошибается. На поиск и устранение ошибок (а это цель данных действий)
тратится много усилий.