Файл: Методические указания по выполнению практических работ по профессиональному модулю.doc

Таблица 1 - Виды планов

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

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

 

Листинг 1. Процесс планирования проекта

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

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

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

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

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

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

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

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

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

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

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

---

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

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

end if

end loop

Процесс планирования начинается с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого (обычно через 2-3 недели) проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ.

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

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

План проекта

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

---

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

1. 
   Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.
   
2. 
   Организация выполнения проекта. Описание способа подбора команды разработчи­ков и распределение обязанностей между членами команды.
   
3. 
   Анализ рисков. Описание возможных проектных рисков, вероятности их проявле­ния и стратегий, направленных на их уменьшение. Тема управления рисками рас­смотрена ниже.
   
4. 
   Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень ап­паратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.
   
5. 
   Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание резуль­татов ("выходов") каждого этапа и контрольные отметки. Эта тема представлена ниже.
   
6. 
   График работ. В этом графике отображаются зависимости между отдельными про­цессами (этапами) разработки ПО, оценки времени их выполнения и распределе­ние членов команды разработчиков по отдельным этапам.
   
7. 
   Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются пре­доставляемые менеджером отчеты о ходе выполнения работ, сроки их предостав­ления, а также механизмы мониторинга всего проекта.
   

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

 Контрольные отметки этапов работ

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

---

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

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

Для определения контрольных отметок весь процесс создания ПО должен быть разбит на отдельные этапы с указанным "выходом" (результатом) каждого этапа. Например, на рис. 1 показаны этапы разработки спецификации требований в случае, когда для ее проверки используется прототип системы, а также представлены выходные результаты (контрольные отметки) каждого этапа. Здесь контрольными проектными элементами являются требования и спецификация требований.

---

Рис. 1. Этапы процесса разработки спецификации

График работ

Составление графика - одна из самых ответственных работ, выполняемых менедже­ром проекта. Здесь менеджер оценивает длительность проекта, определяет ресурсы, не­обходимые для реализации отдельных этапов работ, и представляет их (этапы) в виде со­гласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего проекта можно взять за основу для данного проекта. Но затем следует учесть, что на отдельных этапах нового проекта могут использоваться методы и подходы, отличные от использованных ранее.

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

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

Длительность этапов обычно должна быть не меньше недели. Если она будет мень­ше, то окажется ниже точности временных оценок этапов, что может привести к час­тому пересмотру графика работ. Также целесообразно (в аспекте управления проектом) установить максимальную длительность этапов, не превышающую 8 или 10 недель. Если есть этапы, имеющие большую длительность, их следует разбить на этапы меньшей дли­тельности.

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

---