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

Обоснование полезности проекта

Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта:

· Для кого предназначены результаты проекта.

· Описание текущей ситуации «As Is». Какие у потенциального заказчика существуют проблемы.

· Каким образом результаты проекта решают эти проблемы («To Be»).

· Насколько значимо для клиента решение данных проблем (оценка экономического эффекта).

· Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта.

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

12. Обоснование полезности проекта

12.1. Для Заказчика:
12.1.1. Повышение производительности обработки заказов в 2 раза.
12.1.1.1. "As Is": 2500 заказов/год по 8 чел.*час.
12.1.1.2. "To Be": 2500 заказов/год по 4 чел.*час.
12.1.1.3. Экономия: 2500 * 4 * $50 = $500 000 в год.
12.1.2. Повышение оперативности контроля
12.1.2.1. "As Is": Ежемесячная отчетность.
12.1.2.2. "To Be": Отчетность on-line.
12.1.3. Повышение удовлетворенности клиентов:
12.1.3.1. Сокращение срока обработки заказа в 2 раза.
12.1.3.2. Сокращение времени на поиск необходимой документации в 10 раз
12.1.3.3. Повышение оперативности обновления каталога 10 раз. 12.2. Для компании-исполнителя:
12.2.1. Высокая стратегическая ценность. Дает устойчивое увеличение рынка и завоевание нового рынка.
12.2.2. Финансовая ценность выше среднего. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы.

Выводы

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

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

Приоритет проекта определяется на основе оценки трех показателей:

· Финансовая ценность.

· Стратегическая ценность.

· Уровень рисков.

Дополнительная литература и источники

1. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.

2. С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

3. Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.

Уточнение содержания и состава работ

«Если не получается проглотить слона целиком, то его надо порезать на отбивные». Человечество пока не придумало ничего более эффективного для решения сложной задачи, чем анализ и ее декомпозиция на боле простые подзадачи, которые, в свою очередь, могут быть разделены на еще боле простые подзадачи и так далее. Получается некоторая иерархическая структура, дерево, в корне которого находится проект, а на листьях элементарные задачи или работы, которые надо выполнить, чтобы завершить проект в условиях заданных ограничений. Согласно [1]:

Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) — ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.

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

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

Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект

5. Внедрение

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход не эффективен. Как мы уже говорили, современный процесс разработки коммерческого ПО должен быть инкрементальным. Это означает, что на верхнем уровне декомпозиции нашего проекта должны находиться продукты проекта, а на следующем уровне — компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на «фичи» — функции, которые они должны реализовывать.

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

При составлении базового плана работ не стоит стремиться максимально детализировать все работы. ИСР не должна содержать слишком много уровней, достаточно 3-5. Например, ИСР нашего проекта-примера разработки «Автоматизированной системы продажи документации» может выглядеть следующим образом (Рисунок 17).

1. Проект разработки «Автоматизированной системы продажи документации»
1.1. Подготовка технического задания на автоматизацию
1.1.1.1. Проведение аналитического обследования
1.1.1.2. Разработка функциональных требований
1.1.1.3. Разработка требований базовому ПО
1.1.1.4. Разработка требований к оборудованию и к операционно-системному ПО
1.1.1.5. Согласование и утверждение ТЗ
1.1.1.6. ТЗ утверждено
1.2. Поставка и монтаж оборудования
1.2.1.Разработка спецификации на оборудование 1.2.2.Закупка и поставка оборудования
1.2.3. Монтаж оборудования
1.2.4. Установка и настройка опреационно-системного ПО
1.2.5. Монтаж оборудования завершен
1.3. Поставка и установка базового ПО
1.3.1.Разработка спецификаций на базовое ПО 1.3.2.Закупка базового ПО
1.3.3. Развертывание и настройка базового ПО
1.3.4. Базовое ПО установлено у заказчика
1.4. Разработка и тестирование прикладного ПО
1.4.1. Разработка спецификаций на прикладное ПО
1.4.2. Установка и конфигурирование рабочей среды
1.4.3. Проектирование и разработка ПО
1.4.3.1. Авторизация и аутентификация пользователей.
1.4.3.2. Разработка подсистемы заказа документации
1.4.3.2.1. Просмотр каталога продуктов.
1.4.3.2.2. Поиск продуктов по каталогу.
1.4.3.2.3. Заказ выбранных продуктов.
1.4.3.2.4. Просмотр информации о статусе заказа.
1.4.3.2.5. Информирование клиента об изменении статуса заказа.
1.4.3.2.6. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).
1.4.3.3. Разработка подсистемы обработки заказов
1.4.3.3.1. Просмотр и обработка заказов исполнителями из службы продаж.
1.4.3.3.2. Просмотр статистики поступления и обработки заказов за период.
1.4.3.3.3. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика
1.4.3.4. Разработка подсистемы сопровождения каталога 1.4.3.4.1. Подготовка и сопровождение каталога продукции.
1.4.3.5. Исправление ошибок
1.4.4. Тестирование ПО
1.4.4.1. Раунд 1
1.4.4.2. Раунд 2
1.4.4.3. Раунд 3
1.4.4.4. Выходное тестирование
1.4.5. Документирование прикладного ПО
1.5. Обучение пользователей
1.5.1.Подготовка учебных курсов 1.5.2.Обучение сотрудников Отдела 123 1.5.3.Обучение руководства ОАО XYZ 1.5.4.Обучение администраторов системы
1.6. Ввод в опытную эксплуатацию
1.6.1. Развертывание и настройка прикладного ПО
1.6.2. Проведение приемо-сдаточных испытаний
1.6.3. Акт передачи системы в опытную эксплуатацию утвержден
1.7. Сопровождение системы в период опытной эксплуатации
1.8. Система передана в промышленную эксплуатацию

Рисунок 17. Иерархическая структура работ проекта разработки «Автоматизированной системы продажи документации» (курсивом выделены контрольные точки проекта)

Должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). Для каждого пакета работ должен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами.

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

Планирование управления содержанием

Одна из распространенных «болезней» программных проектов называется «ползучий фичеризм». Это, когда к изначально спроектированной будке для любимой собаки сначала пристраивают сарайчик для хранения садового инвентаря, а потом и домик в несколько этажей для ее хозяина. И все это пытаются построить на одном и том же фундаменте и из тех же самых материалов. Эта болезнь стала причиной летального исхода многих проектов разработки ПО.

Поэтому, сразу, как только удалось стабилизировать и согласовать ИСР, необходимо разработать план управления содержанием проекта. Для этого следует:

· Определить источники запросов на изменение.

· Установить порядок анализа, оценки и утверждения/отклонения изменения содержания.

· Определить порядок документирования изменений содержания.

· Определить порядок информирования об изменении содержания.

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

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

Дата добавления: 2014-11-16