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



 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

65


 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

66


цього часто створюються CD-image стандартних серверних конфігурацій для швидкого відновлення після переформатування жорстких дисків.

 

Якщо в організації відсутня та, що відповідає вимогам проекту лабораторія тестування, її необхідно створити. Середовище тестування повинне бути максимально наближена до виробничої. Цього важливо досягти навіть тоді, коли підготовка такого середовища вимагає великих витрат. Інакше ряд специфічних помилок може залишитися невиявленим до моменту впровадження рішення у виробниче середовище. Організації, MOF, що застосовують, можуть скористатися інформацією з бази даних управління конфігураціями (Configuration Management Database - CMDB) для відтворення в тестовому середовищі всіх характеристик реального виробничого середовища.

 

Фаза розробки

 

Введення

 

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

 

Слід звернути увагу , що активність проектної команди на цьому етапі не обмежується написанням розробниками коди – всі ролеві кластери беруть діяльну участь в створенні і тестуванні рішення.

 

Віха "Розробка завершена"

 

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

 

Результати

 

Результатами фази розробки є:

 

• Початковий і здійснимий код застосувань.

 

• Скрипти установки і конфігурації.

 

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

 

• Матеріали підтримки рішення.

 

• Специфікації і сценарії тестів.

 


Дата добавления: 2018-05-09; просмотров: 246; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!