Ключевые участники и заинтересованные стороны

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

К ключевым участникам программного проекта, как правило, относятся:

· Спонсор проекта — лицо или группа лиц, предоставляющая финансовые ресурсы для проекта в любом виде.

· Заказчик проекта — лицо или организация, которые будут использовать продукт, услугу или результат проекта. Следует учитывать, что заказчик и спонсор проекта не всегда совпадают.

· Пользователи результатов проекта.

· Куратор проекта — представитель исполнителя, уполномоченный принимать решение о выделении ресурсов и изменениях в проекте.

· Руководитель проекта — представитель исполнителя, ответственный за реализацию проекта в срок, в пределах бюджета и с заданным качеством.

· Соисполнители проекта. Субподрядчики и поставщики.

Содержание этого раздела в концепции-примере будет иметь вид.

6. Ключевые участники и заинтересованные стороны

6.1. Спонсор проекта — директор Департамента информатизации ОАО «XYZ» В.Васильев.

6.2. Заказчик — начальник Отдела «123» Ф.Федотов

6.3. Пользователи автоматизированной системы:

6.4. Клиенты ОАО «XYZ» (поиск и заказ документации).

6.5. Руководство ОАО «XYZ» (анализ деятельности Отдела «123»).

6.6. Сотрудники производственных департаментов ОАО «XYZ» (сопровождение каталога).

6.7. Сотрудники Отдела «123» (обработка заявок и поставка документации).

6.8. Сотрудники департамента информатизации ОАО «XYZ» (администрирование системы).

6.9. Куратор проекта — начальник отдела заказных разработок И.Иванов.

6.10. Руководитель проекта — ведущий специалист отдела заказных разработок МП П.Петров.

7. Соисполнители:

7.1. Поставщик оборудования и операционно-системного ПО — ООО «Альфа».

7.2. Поставщик базового ПО — ООО «Бета».

Ресурсы

Для того чтобы понять, сколько будет стоить реализация программного проекта, требуется определить и оценить ресурсы необходимые для его выполнения:

· Людские ресурсы и требования к квалификации персонала.

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

· Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта.

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. О том, как следует подходить к оценкам трудозатрат на реализацию проекта разработки ПО, мы будем подробно говорить в следующих лекциях. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100%.

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

Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО

Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы.

Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час. Исходя из эмпирической кривой Б. Боэма (рисунок 14), численность команды, близкая к оптимальной, составила 10 человек, из них

8. Ресурсы проекта

8.1. Требования к персоналу

8.1.1. 1 — руководитель проекта,

8.1.2. 1 — технический лидер (архитектура, проектирование),

8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование),

8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению),

8.1.5. 3 — тестировщика.

8.2. Материальные и другие ресурсы

8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий

8.2.2. 2 серверных комплекса (для разработки и тестирования):

8.2.3. Сервер приложений с установленным BEA Weblogic AS

8.2.4. Сервер оперативной БД с установленной Oracle RDBMS

8.2.5. Сервер каталога с установленной OODB "Poet"

8.3. Лицензии на средства разработки и тестирования:

8.3.1. Oracle Designer — 1 лицензия

8.3.2. Symantec Visual Cafe for Java — 5 лицензий.

8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент).

8.4. Расходная часть бюджета проекта

8.4.1. Разработка и сопровождение прикладного ПО:

8.4.1.1. 9000 чел.*час. * $40 = $360 000

8.4.2. Поставка оборудования и операционно-системного ПО:

8.4.2.1. 3 сервера * $10 000 = $30 000

8.4.3. Поставка базового ПО:

8.4.3.1. BEA Weblogic AS $20 000

8.4.3.2. Oracle RDBMS $20 000

Итого: $430 000

Сроки

Ф. Брукс писал: «Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер».

Там же Брукс приводит исключительно полезную, но почему-то редко применяемую, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барии Боэмом (Barry Boehm) на основе анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м. (человеко-месяцев), пожно утверждать что:

· Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)^1/3. То есть оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в человеко-месяцах. Следствием является кривая, дающая оптимальную численность проектной команды (рисунок 15).

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

· Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне зависимости от количества занятых в нем! (рисунок 16)

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

Рисунок 15. Закон Б.Боэма

Для сколь-нибудь серьезного программного проекта недостаточно определить только срок его завершения. Необходимо еще определить его этапы — контрольные точки, в которых будет происходить переоценка проекта на основе реально достигнутых показателей.

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

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

Рисунок 16. Следствия закона Б.Боэма

Соответствующий раздел концепции нашего проекта-примера будет иметь следующий вид.

9. Сроки проекта

9.1. 03.03 старт

9.2. 28.11 завершение

9.3. Контрольные точки:

9.3.1. 15.04 ТЗ утверждено

9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).

9.3.3. 15.05 Монтаж оборудования у заказчика завершен.

9.3.4. 30.05 Базовое ПО установлено у заказчика.

9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика

9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную эксплуатацию утвержден

9.3.7. 28.11 Система передана в промышленную эксплуатацию.

Риски

Риск — неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта.

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

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

В случае нашего проекта-примера раздел «риски» будет выглядеть следующим образом.

10. Риски проекта

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

Критерии приемки

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

В рассматриваемом примере раздел «Критерии приемки» будет выглядеть следующим образом:

11. Критерии приемки. По итогам опытной эксплуатации система должна продемонстрировать следующие показатели:

11.1. Средние затраты сотрудников Отдела «123» на регламентную обработку одного заказа не превышают 4 чел.*час.

11.2. Срок регламентной обработки 1-го заказа не более 2 недель.

11.3. Время поиска и предоставления информации о наличии дополнительной документации не более 1 мин.

11.4. Время предоставления информации о сделанных заказах и истории их обработки не более 1 мин.

11.5. Система хранит всю информацию о сделанных заказах и истории их обработки.

11.6. Показатель доступности системы 98%.

Поиск по сайту: