Проміжні віхи, що рекомендуються

Верифікація технологій

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

Часто верифікація технологій включає відбір найбільш відповідних з конкуруючих технологій (іноді званий "shoot out").

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

Базова версія функціональної специфікації створена

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

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

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

Базова версія звідного плану проекту створена

У MSF звідний план проекту – це не окремий самостійний план, а сукупність планів роботи різних ролевих кластерів. Залежно від проекту в нім можуть бути зібрані плани різних типів. Деякі з них показані на рис. 9.

65

Рисунок 13. Звідний план проекту

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

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

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

Середовища розробки і тестування розгорнені

Незалежне середовище розробки (development environment) дає можливість створювати і тестувати рішення поза виробничими системами, що знаходяться в експлуатації, що дозволяє уникнути негативного впливу на ці системи. Правильним підходом є використання для розробки окремих серверів. При цьому проектна група повинна знати, що інстальоване на цих серверах програмне забезпечення може стати нестабільним і зажадати надалі переустановлення.

У цьому середовищі проводиться розробка таких компонент інфраструктури, як конфігураційні файли, інсталяційні скрипти, нове апаратне забезпечення і так далі

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

66