Материал: 970

Продолжение табл. 2.1

Окончание табл. 2.1

Планирование программного проекта относится к работам,

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

метод критического пути — CPM (Critical Path Method) и ме-

тод анализа и оценки программPERT (Program Evaluation and Review Technique).

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

Анализ состояния разработки проекта предлагается проводить на основе анкетирования, отражающего состояние направлений аудита [26]. Направлениями аудита являются:

1) четкость постановки целей проекта:

·концепция определяет ясные недвусмысленные цели;

·все члены команды считают концепцию реалистичной;

·у проекта имеется обоснование экономической эффективности;

·разработан прототип пользовательского интерфейса;

·разработана спецификация целевых функций программного продукта;

·с конечными пользователями продукта налажена двухсторонняя связь;

2) конкретизированность способов достижения целей:

·имеется детальный письменный план разработки продукта;

·в список задач проекта включены«второстепенные» задачи

(управление конфигурациями, конвертация данных, интеграция

сдругими системами);

·после каждой фазы проекта обновляется расписание и бюджет;

·архитектура и проектные решения документированы;

·имеется план обеспечения качества, определяющий тестирование и рецензирование;

·определен план многоэтапной поставки продукта;

·в плане учтены обучение, выходные, отпуска, больничные;

·план проекта и расписание одобрены всеми участниками команды;

3) наличие определенной формы организации контроля и управления реализацией проекта:

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

·у проекта есть менеджер, причем только один;

·в плане проекта определены «бинарные» контрольные точки;

·все заинтересованные стороны могут получить необходимую информацию о ходе проекта;

·между руководством и разработчиками установлены доверительные отношения;

·установлена процедура управления изменениями в проекте;

·определены лица, ответственные за решение о принятии изменений в проекте;

·план, расписание и статусная информация по проекту доступны каждому участнику;

·код системы проходит автоматическое рецензирование;

·применяется система управления дефектами;

4) проведение периодического анализа угроз и рисков:

·имеется список рисков проекта. Осуществляется его регулярный анализ и обновление;

·руководитель проекта отслеживает возникновение новых рисков;

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

5) организация командной работы над проектом:

·опыт команды достаточен для выполнения проекта;

·у команды достаточная компетенция в прикладной области;

·в проекте имеется технический лидер;

·численность персонала достаточна;

·у команды имеется достаточная сплоченность;

·все участники привержены проекту.

Каждый вопрос предлагается оценить по следующей схеме: оценка 0 проставляется, если руководитель даже не знает об этом; 1 — знает, но пока не реагирует на это; 2 — знает, но реагирует периодически; 3 — реагирует постоянно. В зависимости от численности команды при расчете итогового балла предлагается учитывать следующие поправочные коэффициенты: для малых проектов (до 5 человек) — 1,5; для средних (от 5 до 20 человек) — 1,25. Результаты самооценки: если итоговый балл меньше40 — завершение проекта сомнительно; 40–59 — в ходе реализации проекта следует ожидать серьезные проблемы; 60–79 — проект, скорее всего, будет успешным; 80–89 — вероятность успеха высока; больше 90 — 100 % шансов на успех.

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