Microsoft Solutions Framework – передова методика управління процесом розробки і впровадження інформаційних систем

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

Одним з підходів до рішення цього завдання, що успішно використовується в багатьох компаніях усього світу, є Microsoft Solutions Framework (MSF). Це узагальнений, найбільш успішний досвід груп розробки продуктів і IT-підрозділів корпорації Microsoft, досвід замовників і партнерів у всьому світі. Він збирається і аналізується з метою виділити повторювані фактори, що забезпечують успіх проекту. Потім ці фактори успіху інтегруються у взаємозалежні моделі, застосування яких дозволяє одержати технологічні рішення в контексті конкретного бізнесу.

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

Microsoft Solutions Framework – це комплект взаємозалежних моделей, концепцій і посібників зі створення і впровадження розподілених інформаційних систем рівня підприємства. Він містить набір інтегрованих ресурсів (практичні посібники, аудиторні заняття, описи методик і методологій) і принципів, що приводять проектні групи до успіху. MSF не є методологією, а скоріше надає гнучкі і практичні шляхи застосування інформаційних технологій для рішення проблем, забезпечує структуру, що допомагає локалізувати проблеми і полегшити прийняття ефективних рішень.

У Microsoft Solutions Framework є чотири характерні особливості:

1. Орієнтація на віхи (milestone - based approach). Проектні віхи (як зовнішні, так і внутрішні) служать в якості контрольних точок для синхронізації відчужуваних матеріалів проекту.

2. Чітке розмежування зон відповідальності (clear ownership and accountability). Відповідальність за кожну з віх чітко визначена і прив'язана до проектної ролі.

3. Планування з урахуванням ризиків (risk - driven scheduling). Частини проекту, пов'язані з найбільшими ризиками, виявляються і розробляються якнайскоріше.

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

Моделі, що входять до складу MSF (модель проектної групи, модель процесу) допомагають знайти відповіді на критично важливі питання на кожному з етапів проектування. Раннє пророблення цих питань допоможе знизити вартість володіння продуктом і визволить час менеджерам ІТ для стратегічного планування (на відміну від щоденної підтримки). Ці моделі можна використовувати як самостійно, так і в різних комбінаціях, залежно від поставлених завдань і потреб.

Розглянемо модель проектної групи MSF. У даному випадку центральним постає питання: як має бути побудована і структурована проектна група для того, щоб можна було оптимізувати процес проектування у термінах якості і витратах.

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

Така група буде мати такі характеристики:

• кожний спілкується з кожним, і кожен робить реальну роботу;

• загальні для всіх членів групи цілі і плани;

• кожний розуміє як проблеми кінцевого користувача, так і проблеми розробника;

• кожен несе відповідальність за свою роботу, у тому числі і перед групою.

Суттєвою особливістю даного підходу, що істотно відрізняє його від класичного, є заперечення ієрархічного способу структурування проектної групи. Для проектної групи MSF питання «хто кому підлеглий?» не має сенсу. Вона відрізняється від традиційної проектної групи правилами формування і складом.

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

Але й у випадку ефективної проектної групи є кілька важливих моментів, на які варто звертати увагу:

• велика чисельність проектної групи може вимагати дуже багато часу для спілкування, щоб реалізувати концепцію «кожний спілкується з кожним»;

• вище керівництво має обмежений контроль за внутрішніми взаєминами і процесами в проектній групі;

• члени проектної групи повинні цілком розуміти і приймати свої ролі.

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

Під якісним продуктом мається на увазі такий продукт, що:

• задовольняє очікування замовника і кінцевих користувачів;

• задовольняє проектні обмеження;

• відповідає реальним потребам замовника;

• зрозумілий у використанні замовнику і кінцевим користувачам;

• упроваджується без ускладнень (що забезпечується на етапі проектування).

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

 

 

Рисунок 4.4 – Основні ролі проектної групи MSF

 

Основні ідеї, що лежать в основі моделі проектної групи MSF:

• взаємозалежні ролі в малій групі;

• визначення ролі, особливої місії і зони відповідальності для кожного члена проектної групи;

• розподілені управління проектом і відповідальність;

• кожний налаштований на успіх проекту і на роботу протягом усього його циклу;

• комунікації між членами проектної групи є ключовим чинником успіху;

• користувачі і навчальний персонал включені в проектну групу;

• рівнобіжна робота всіх учасників групи над проектом.

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

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

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

Основні ролі моделі проектної групи MSF:

1. Менеджер продукту. Ця роль забезпечує комунікаційний канал між замовником і проектною групою. Менеджер продукту керує очікуваннями замовника, розробляє і підтримує бізнес-контекст проекту. Його робота не пов’язана прямо з продажем продукту, він сфокусований на продукті, його завдання – визначити і забезпечити задоволення замовника. Краща кандидатура на цю роль – існуючий користувач, співробітник комерційного відділу або інший представник замовника, якщо він розуміє завдання і механіку бізнесу.

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

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

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

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

Дуже важливо розрізняти тестування і контроль якості. Тестування зосереджене на проекті й оперує деталями і технікою роботи.

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

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

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

Параметри різних ролей у складі проектної групи формалізовані в табл. 4.4.

 

 

Таблиця 4.4 – Ролі у складі проектної групи

Роль	Відповідальність	Навички	Пріоритети
Менеджер продукту	Визначення проблеми Просування продукту	Висока комунікабельність	Задоволеність замовника
Менеджер проекту	Керування специфікаціями Координація робіт Відстеження стану проекту	Досвід керування проектами Висока комунікабельність Уміння писати тексти	Розробка якісного продукту в термін і в рамках виділеного бюджету Пошук і рішення проблем
Розробник	Проектування функціональності Створення продукту Тестування продукту	Рішення проблем Досвід розробки	Надійний і повний продукт
Тестувальник	Визначення стратегії тестування Проведення тестування Відстеження результатів тестування	Уміння розрізняти причини і наслідки, гарні навички діагностування ситуації Уміння моделювати критичні ситуації Розуміння того, „як усе працює”	Погоджений і надійний продукт
Інструктор	Розробка документації Ведення глосарію Тестування Навчання користувачів	Технічний письменник	Продукт, який можна використовувати і супроводжувати
Логістик	Прогнозування ситуації Підготовка впровадження Супровід продукту на етапі впровадження Забезпечення адекватної інфраструктури, коли в ній є необхідність	Розуміння оперативної ситуації Комунікабельність Розуміння і відстеження динаміки взаємин між організаціями	Забезпечення гладкого впровадження і розвитку продукції

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

Таблиця 4.5 – Можливість об'єднання ролей в проектній групі

	Менеджер продукту	Менеджер проекту	Розробник	Тестувальник	Інструктор	Логістик
Менеджер продукту	-	Ні			Так	Так
Менеджер проекту	Ні	-	Ні	Ні	Так	Так
Розробник		Ні	-	Ні
Тестувальник		Ні	Ні	-
Інструктор	Так	Так			-
Логістик	Так	Так				-

 

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

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

В основі цієї моделі лежить кілька основних ідей:

• конструювання рішень з доступних для огляду і керованих частин;

• фази проекту завершуються віхами;

• випускаються версії продукту;

• планування виконується з урахуванням ризиків.

Модель процесу проектування MSF (рис. 4.4) складається з чотирьох фаз і чотирьох віх, якими завершуються ці фази.

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

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

Необхідно відмітити, що на діаграмі процесу (рис. 4.4) зображені саме фази проекту і немає прив’язки до часу. Крім того, дана діаграма не стверджує, що тривалість усіх чотирьох фаз збігається.

Рисунок 4.4 – Діаграма моделі процесу проектування MSF

 

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

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

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

Таблиця 4.6 – Набір документів, що створюються і погоджуються з замовником при досягненні кожної віхи

№ з/п	Назва віхи	Набір документів
1.	Загальний опис проекту	Образ та границі проекту Оцінка ризиків Структура проекту
2.	Функціональні специфікації	Функціональні специфікації Оцінка ризиків План проекту Графік проекту
3.	Завершення розробки	Оцінка ризиків Чорнові версії документів Функціональні специфікації на нинішню версію Зміни у Графіку проекту
4.	Реліз	Продукт Вихідні коди для нинішньої версії Навчальні посібники База даних помилок та побажань

 

Особливу увагу слід зосередити на визнанні того факту, що випуск декількох версій продукту є більш доцільною дією, ніж спроба зробити єдиний кінцевий продукт, що відразу має повну функціональність. Розвиток технологій дуже швидко змінює можливості, а отже, і очікування користувачів персональних комп’ютерів. Границі проекту можуть уточнюватися тоді, коли це необхідно. Потреба в зміні границь проекту може викликатися зміною вимог замовника або ризиками, що трансформувалися в проблеми. Модель процесу проектування MSF орієнтується на реальні ситуації реального світу.

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

Основним результатом першої фази є складання документа «Образ і границі проекту» (англ. «Vision/Scope Document»). Це документ обсягом п’ять-сім сторінок, він складається менеджером продукту (відповідає за правильне відображення потреб замовника) і менеджером програми (відповідає за відповідність задачі очікуванням замовника) і призначений для чіткого і ясного визначення наступного:

• цілі проекту, очікування замовника, база для вихідної оцінки ризиків проекту. Даний документ визначає, яка концепція рішення закладається в основу;

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

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

Що характерно, на успіх проекту більше впливає не те, наскільки докладно розглянуті ці питання, а те, наскільки усебічно вони були розглянуті.

Після аналізу даних, моделювання різних процесів і планування процесу розробки даний документ має бути доповнений з урахуванням кращого розуміння потреб замовника, виявлених технічних рішень або ризиків, досягнутого компромісу між обсягами і термінами робіт. Зміни, внесені в документ «Образ і границі проекту» у міру його розробки, повинні ставати усе менш і менш значущими, тому що вони все більше починають впливати на ризики, пов’язані з часом виконання проекту.

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

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

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

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

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

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

Фаза «Стабілізація» завершується віхою «Випуск версії (Реліз)». Досягнення цієї віхи означає, що продукт або послуга працездатні і що вони передаються групам підтримки і супроводу.

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

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

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

Планування з урахуванням ризиків – це прийом, коли компоненти проекту, зв’язані з найбільшим ризиком, розробляються першими. Особливо важливо планувати з урахуванням ризиків у проекті, зв’язаному з розробкою програмного забезпечення або створенням інфраструктури:

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

• визначається, які можливості і коли повинні бути реалізовані; пріоритети завданням розставляються на підставі:

- управлінських і бізнесів-ризиків – гарантія того, що в черговій версії будуть реалізовані особливо важливі для бізнесу функції;

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

• розробляється план по запобіганню найбільш імовірних і небезпечних ситуацій і, про усякий випадок, план «ліквідації катастрофи»;

• обов’язково переглядається проектний план для включення в нього цього «пом’якшуючого» ризики плану. Як правило, це вимагає збільшення необхідних ресурсів і часу, а також виконання додаткових завдань.

Якщо компоненти, пов’язані з високим ступенем ризику, потребують більше часу, ніж було розраховано, то планування з урахуванням ризиків надасть додатковий час для реагування.

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

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

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

Звичайно для управління процесом випуску версії продукту потрібно відслідковувати:

- ідеї, що знаходяться на етапі аналізу і пророблення за межами границь поточної версії;

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

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

Таким чином, можна зробити такі висновки.

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

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