Учебно-методический комплекс ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ   А. М. Гудов, С. Ю. Завозкин, С. Н. Трофимов

[Титульная] [Программа] [Учебное пособие] [Лабораторный практикум] [Дополнительные материалы]

[Глава 1] [Глава 2] [Глава 3] [Глава 4] [Глава 5] [Глава 6] [Глава 7] [Глоссарий] [Метод. рекомендации]

Глава 4. Управление проектами по созданию и внедрению ПО

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

«Хорошее управление не гарантирует успешного завершения проекта, но плохое управление обязательно приведет к его провалу.»

Отличия процесса разработки ПО от процессов реализации технических проектов:

• Программный продукт нематериален

• Не существует стандартных процессов разработки ПО

• Большие программные проекты - это часто "одноразовые" проекты

Процессы управления:

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

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

• Оценивание стоимости проекта.

• Контроль за ходом выполнения работ. Менеджер должен постоянно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью.

• Подбор персонала. Руководители — менеджеры проектов обычно обязаны сами подбирать исполнителей для своих проектов. В идеальном случае профессиональный уровень исполнителей должен со­ответствовать той работе, которую они будут выполнять в ходе реализации проекта. Однако во многих случаях менеджеры должны полагаться на команду разработчиков, которая далека от идеальной.

• Написание отчетов и представлений. Менеджер проекта обычно обязан посылать отчеты о ходе его выполнения как заказ­чику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извлекаемой из подробных' отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта.

Планирование проекта

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

 Таблица 11 – Планирование проекта

Алгоритм планирования проекта можно представить следующим образом:

Определение проектных ограничений

Первоначальная оценка параметров проекта

Определение этапов выполнения проекта и контрольных отметок

while пока проект не завершится или не будет остановлен

loop

         Составление графика работ

         Начало выполнения работ

         Ожидание окончания очередного этапа работ

         Отслеживание хода выполнения работ

         Пересмотр оценок параметров проекта

         Изменение графика работ

         Пересмотр проектных ограничений

         if (возникла проблема) then

                   Пересмотр технических или организационных параметров проекта

         end if

end loop

План проекта:

1.     Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.

2.     Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.

3.     Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение.

4.     Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.

5.     Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки.

6.     График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.

7.     Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.

Контрольные отметки— вехи, отмечающие окончание определенного этапа работ.

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

Рис. 57 ‑ Контрольные отметки

Рис. 58 ‑ График работ

Рис. 59 – Сетевая диаграмма

Таблица 12 – Описание сетевой диаграммы

Рис. 60 – Временная диаграмма

Рис. 61 – Диаграмма распределения исполнителей по этапам

Таблица 13 – Распределение исполнителей

Управление рисками

Риск можно понимать как вероятность проявления каких-либо неблагопри­ятных обстоятельств, негативно влияющих на реализацию проекта.

Возможные риски для программных проектов:

1.     Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.

2.     Риски для разрабатываемого продукта, влияющие на качество или производитель­ность разрабатываемого программного продукта.

3.     Бизнес-риски, относящиеся к организации-разработчику или поставщикам.

Таблица 14 ‑ Возможные риски программных проектов

1.     Определение рисков. Определяются возможные риски для проекта, для разрабатывае­мого продукта и бизнес-риски.

2.     Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций.

3.     Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.

4.     Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.

Рис. 62 ‑ Схема процесса управления рисками

Список возможных категорий рисков:

1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.

2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.

3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.

4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.

5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.

6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.

Таблица 15 – Категория рисков

Таблица 16 ‑ Список рисков после проведения их анализа

* Вероятность риска считается очень низкой, если она имеет значение менее 10%; низ­кой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.

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

Таблица  17 – Стратегии управления рисками

Существует три категории стратегий управления рисками:

1. Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов.

2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков.

3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой си­туации. В табл. 4.7 это стратегия поведения при возникновении финансовых про­блем у организации разработчика.

Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести.

 Таблица 18 – Типы рисков

Вопросы для обсуждения

1. Объясните, почему нематериальность программных систем порождает особые проблемы в процессе управления программными проектами.

2. Объясните, почему хорошие программисты не всегда могут быть хорошими менеджера проектов.

3. Объясните, почему процесс планирования проекта является итерационным и почему план должен постоянно пересматриваться в течение всего срока выполнения проекта.

4. Менеджер проекта предупреждает о возможной задержке выполнения работ, которой можно избежать только за счет бесплатных сверхурочных работ команды разработчиков. Все члены команды имеют семьи, требующие определенной доли внимания. Обсудите возможность отклонения предло­жения менеджера о бесплатных сверхурочных работах либо согласия предпочесть интересы организации семейным интересам. Какие аргументы наиболее весомы в этой дискуссии?

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

[Глава 1] [Глава 2] [Глава 3] [Глава 4] [Глава 5] [Глава 6] [Глава 7] [Глоссарий] [Метод. рекомендации]

[Титульная] [Программа] [Учебное пособие] [Лабораторный практикум] [Дополнительные материалы]