Фаза планування

Введення

На фазі планування (planning) проводиться основна робота по складанню планів проекту. Вона включає підготовку проектною групою функціональної специфікації, розробку дизайнів, підготовку робочих планів, оцінку проектних витрат і термінів розробки різних складових проекту.

На початку фази планування проектна група аналізує і документує проектні вимоги. Вони розділяються на чотири загальні категорії: бізнес - вимоги (business requirements),

споживчі вимоги (user requirements), експлуатаційні вимоги (operational requirements) і

системні вимоги, що відносяться до рішення в цілому (system requirements). В ході проектування рішення і створення його функціональної специфікації необхідно стежити за відповідністю (traceability) між наявними вимогами і проектованою функціональністю. Ця відповідність не обов'язково буде взаємно однозначною. Воно служить одним із способів контролю коректності дизайну і його придатності для досягнення поставлених перед рішенням цілей.

Процес проектування – це систематичний спосіб просування від абстрактних концепцій до конкретних технічних деталей. Він починається з методичного аналізу профілів користувачів (user profiles, іноді званих "персонажами" - "personas"), які описують різні типи користувачів (включаючи персонал супроводу) і їх робочі функції. Значна частина цієї роботи часто проводиться під час фази вироблення концепції. Потім формується набір сценаріїв використання (usage scenarios), в кожному з яких моделюється виконання якоїнебудь операції певним типом користувача (наприклад, реєстрація відвідувачів в готелі або адміністрування паролів користувачів в комп'ютерній системі). Врешті-решт, кожен сценарій використання розбивається на послідовність специфічних дій, званих прикладами користування (use cases), які необхідно виконати користувачеві для здійснення операції. Цей процес аналізу дій користувачів називається сторі-боардінг ("story-boarding").

Існує три рівні процесу проектування: концептуальний дизайн (conceptual design), логічний дизайн (logical design) і фізичний дизайн (physical design). Робота над логічним дизайном починається через деякий час після початку концептуального дизайну, і робота над фізичним дизайном стартує через деякий час після початку роботи над логічним.

Результати процесу проектування документуються у функціональній(-х) специфікації(- ях) (functional specification(s)). Функціональні специфікації детально описують вигляд і поведінку кожної складової рішення. Також для всіх складових описується їх архітектура і дизайн.

Функціональна специфікація служить багатьом цілям. Основні з них – це:

•Інструкції команді розробників про те, що вони повинні будуть створити.

•Основа для оцінювання об'єму роботи.

•Чітка угода із замовником про те, що повинне бути зроблене.

•Синхронізація роботи всієї проектної команди.

Як тільки створена базова версія функціональної специфікації, може бути почате детальне планування. Кожен з керівників ролевих кластерів проектної групи готує план або плани, що відносяться до його ролі, і бере участь в командних сесіях планування. Приклади планів включають план впровадження, план тестування, план експлуатації, план мерів безпеки, план навчання.

Потім проектна група колективно аналізує плани і виявляє взаємозалежності між ними. Всі плани синхронізуються і представляються разом у вигляді звідного плану проекту. Не варто плутати цю діяльність із створенням .mpp файлу Microsoft® Project®. Залежно від проекту, число планів, утворюючих звідний план, може мінятися.

63

Члени проектної групи, що представляють кожен з ролевих кластерів, оцінюють необхідне для виконання запланованих завдань час і складають календарний графік здачі результатів (деталі див. в розділі "Оцінка від низу до верху"). Потім відбувається синхронізація календарних графіків з подальшою їх інтеграцією в звідний календарний графік проекту (master project schedule).

Кульмінацією фази планування є віха "Плани проекту затверджені" (project plans approved). Вона знаменує собою досягнення детальної угоди між замовником і проектною групою про склад рішення, що поставляється, і терміни постачань. Також на цій вісі проектна група уточнює оцінки рисок, коректує (при необхідності) пріоритети і остаточно оцінює необхідні ресурси.

Віха "Плани проекту затверджені"

Ця віха знаменує собою угоду між проектною групою і ключовими зацікавленими сторонами про те, що проміжні віхи фази планування успішно пройдені, складені календарні графіки реалістичні, розподіл ролей і відповідальності в команді визначений належним чином, і механізми управління ризиками приведені в дію. Функціональні специфікації, звідний план і звідний календарний графік проекту служать основою для ухвалення компромісних рішень в майбутньому.

Затверджені специфікації, плани і календарні графіки утворюють базову версію проекту (project baseline). Вона включає всі угоди, прийняті на основі консенсусу з урахуванням трьох планових параметрів проекту: ресурсів, часу і функціональності рішення. Після того, як базова версія проекту створена і затверджена, проектна група приступає до фази розробки.

Зміни в створеній базовій версії проекту піддаються строгому контролю. Це не означає, що всі ухвалені під час фази планування рішення остаточні – в ході подальшої фази розробки проектна група повинна аналізувати і формально затверджувати (або відкидати) всі пропоновані зміни базовій версії.

У організаціях, що використовують MOF, проектна група на цій вісі подає запит на зміну (Request for Change - RFC) команді супроводу.

Результати

Результатами фази планування є:

•Функціональна специфікація.

•План управління ризиками.

•Звідний план і звідний календарний графік проекту.

Основні завдання проектної групи на фазі планування

Наступна таблиця описує основні завдання і сфери відповідальності кожного з ролевих кластерів проектної групи під час фази планування.

64