Хоча RUP фактично став стандартом розробки програмного забезпечення, у галузі існують інші методології, що активно розвиваються, підтримуються і використовуються. Прикладом є Microsoft Solutions Framework (MSF, структура рішень Microsoft), початково випущена у 1994 р. як пакет настанов з ефективного проектування, розроблення, впровадження і супроводу рішень на основі технологій компанії.
До складу MSF входять дві моделі:
1) модель проектної групи (модель команди, MSF Team Model) регламентує ролі учасників проекту, ділянки їх компетенції та відповідальності, а також містить рекомендації щодо виконання відповідних завдань. Передбачено шість ролей: менеджер з розроблення (program manager), розробник (developer), тестувальник (tester), менеджер релізів (release manager), фахівець з підтримки користувачів (user experience specialist);
2) модель процесів (MSF Process Model) — загальна методологія розроблення і впровадження ITрішень, що характеризується гнучкістю, рекомендаційним характером і може застосовуватися для різноманітних проектів. Вона охоплює весь життєвий цикл і поєднує каскадну та спіральну моделі життєвого циклу. Передбачено такі основні фази процесу розробки:
— розроблення концепції (Envisioning) — визначення складу команди, структури проекту та бізнесцілей, оцінювання поточної ситуації, створення загальної картини і області дії проекту, визначення вимог і профілів користувачів, розроблення концепції рішення, оцінювання ризику;
— планування (Planning) — розроблення проекту та архітектури рішення, створення функціональної специфікації, розроблення планів і календарного графіка, створення середовища розроблення, тестування і пілотної експлуатації;
— розробка (Developing) — створення прототипу додатку, програмних компонентів додатку, рішення (послідовність щоденних або частіших складань), закриття розробки (реалізація всіх функцій, поставка коду і документації);
— стабілізація (Stabilizing) — тестування (тестування компонентів, баз даних, інфраструктури, захисту, інтеграції, аналіз зручності роботи з продуктом, навантажувальне тестування, регресивне тестування, ведення звітності), пілотна експлуатація в тестовому середовищі за участі користувачів і застосування реальних сценаріїв роботи;
— упровадження (Deploying) — розгортання основних компонентів, рішення в цілому, стабілізація, розгортання і передавання в експлуатацію замовнику.
Для кожної фази моделі процесів MSF визначає артефакти, що є результатом проходження фази, і зміст робіт для кожної ролі. У процесі також визначаються віхи (milestones) — ключові точки проекту, що позначають досягнення певного суттєвого (проміжного або кінцевого) результату (рис. 2.10). Додаткові проміжні віхи поділяють великі роботи на менші складові і відображають перебіг виконання проекту.
,
У MSF передбачено три дисципліни — керування проектами, керування ризиками і керування підготовкою.
Методологія MSF підтримується Microsoft Visual Studio Team System (VSTS) — набором інструментів Microsoft для розроблення програмних додатків, спрощення сумісної роботи над проектами, тестування і відлагодження програм та підготовки звітів. VSTS складається з п’яти продуктів, основним з яких є серверний додаток Team Foundation Server (TFS), що складається з бази даних на SQL Server, у якій містяться всі проектні дані, і компонентів середнього рівня на базі Windows Server 2003, ASP.NET і Windows SharePoint Services (див. також п. 7.4.2).
Методології забезпечення процесів життєвого циклу підтримуються в TFS за допомогою відповідних шаблонів. Шаблон процесу — це набір XMLфайлів , що містять специфікації процесів та артефактів, які становлять методологію розробки. Шаблон містить такі складові:
— керівництва з процесу — для будьякого нового проекту створюється свій webпортал, що містить повний опис процесу (рис. 2.11), на основі якого ведеться розроблення. Керівництво подає детальний опис ролей, виконуваних ролями робіт, робочих елементів, їх полів і станів;
— робочі елементи з описом полів, їх розміщення на формі, станів і можливих переходів між ними з можливістю зміни полів, форм і життєвого циклу робочих елементів (табл. 2.3);
— звіти, що будуть створюватися для кожного нового проекту. Наприклад, шаблон MSF Agile містить, за умовчанням, звіти про дефекти за пріоритетністю, частоту дефектів, складання, швидкість виконання проекту, показники якості, результати навантажувального тестування, реактивації, взаємопов’язані робочі елементи, залишок роботи, незаплановані роботи, черговість робіт, робочі елементи;
— шаблони документів — проектної документації, планів робіт, планів тестування тощо.
Крім цього, шаблони процесів включають налаштування версійного контролю, інтеграції з MS Project, групи доступу тощо. У шаблоні процесу MSF Agile за умовчанням доступні такі групи доступу: читачі (Readers), які мають право лише читати, учасники (Contributors), які можуть додавати, змінювати і видаляти елементи групового проекту, сервіси складання (Build Services), що мають доступ до відповідного сервіса, та адміністратори проекту (Project Administrators), що можуть здійснювати в груповому проекті всі операції.
Архітектура шаблона процесу містить три основні частини: модулі шаблона процесу, що підключаються, XMLфайли опису процесу та майстер створення групового проекту (New Team Project Wizard).
Модулі шаблона процесу, що підключаються, — це компоненти, що запускаються під час створення нового групового проекту. Вони налаштовують необхідні файли і конфігурують дані для певної ділянки шаблона. Стандартними є такі модулі:
— класифікація — визначає початкову ітерацію і ділянки групового проекту;
— групи і права доступу — визначає початкові групи доступу групового проекту та їхні права доступу;
— сервіси Windows SharePoint — визначає портал проекту для групи на основі шаблона сайта Microsoft Windows SharePoint, а також файли шаблона і керівництва з процесу;
— відстеження робочих елементів — визначає початкові типи робочих елементів, запити та екземпляри робочих елементів групового проекту;
— звіти — визначає початкові звіти групового проекту і налаштовує сайт звітів;
— контроль версій — визначає початкові права доступу до системи контролю версій групового проекту і наявність коментарів до реєстрації змін.
Щоб налаштувати шаблон процесу, можна змінити будьякий файл опису модуля, що підключається. Також можна видалити будьякий файл опису, крім класифікації.
XMLфайли опису процесу — набір XMLфайлів, що описують задачі, виконання яких забезпечить правильне конфігурування нового групового проекту для процесу. Майстер New Team Project, що використовується для створення групового проекту, виконує необхідні модулі, що підключаються. Кожен такий модуль зчитує з відповідного XMLфайла опису процесу список задач для виконання, конфігурації та настройки, що мають бути реалізовані:
1) XMLфайл відстеження робочих елементів — файл
Workitems.xml у папці Work Item Tracking визначає:
— типи робочих елементів — правила, поля, стани і переходи для елементів роботи, що будуть відстежуватися для групового проекту (задач, дефектів, вимог тощо, див. рис. 2.12);
— запити до робочих елементів використовуються для групування робочих елементів, наприклад задач або активних дефектів. Розташовуються у файлах WIQ (work item query) у папці
Queries з папки Work Item Tracking;
— екземпляри робочих елементів, що створюються за умовчанням;
2) XMLфайл класифікації — файл Classification.xml у папці Classification. Складається з двох частин:
— ітерації (Iterations) — використовуються для визначення кількості повторів групою певного набору основних дій, таких як планування, розроблення, тестування;
— ділянки (Areas) — використовуються для організації роботи в груповому проекті. Прикладами можуть бути ділянка користувацького інтерфейсу, ділянка додатку і ділянка бази даних. За допомогою ділянок робочі елементи групують для запитів і звітів;
3) XMLфайл сервісів Windows SharePoint — файл WssTasks.xml у папці Windows SharePoint Services. Задає три основні задачі — створення шаблона сайта (Site Template), на якому буде базуватися портал проекту, бібліотек документів (Document Libraries), папок і файлів (Folders and Files);
4) XMLфайл контролю версій — файл VersionControl.xml у
папці Version Control. Визначає початкові права доступу до системи контролю версій, наявність коментарів до реєстрації змін і необхідність у забезпеченні можливості вилучення версії файла з репозиторію для редагування лише одним користувачем, а також права доступу для групи або окремих її членів;
5) XMLфайл звітів — файл ReportsTasks.xml у папці Reports.
Визначає сайт звітів, папки звітів на сайті звітів та власне звіти, що додають за допомогою файлів .rdl;
6) XMLфайл груп і прав доступу — файл
GroupsandPermissions.xml у папці Groups and Permissions. Визначає початкові групи доступу TFS і прав доступу для кожної з них.
Майстер New Team Project Wizard використовує модулі, що підключаються, та XMLфайли опису процесу для створення нового групового проекту.
TFS має два вбудовані шаблони процесів, що відрізняються компонентами і можуть бути відредаговані згідно з особливостями конкретного проекту:
— MSF for Agile — шаблон процесу для організації роботи за гнучкими методологіями, коли додатки створюються на основі сценаріїв через множину ітерацій із мінімальною формалізацією. Шаблон містить невелику кількість робочих елементів, достатніх для розподілу завдань в команді, опису можливостей системи або сценаріїв використання і відстеження помилок, які слід виправити. Кількість станів і переходів для цих елементів у шаблоні мінімальна;
— MSF for CMMI — шаблон процесу розробки згідно з третім рівнем моделі якості процесів розробки CMMI Інституту з розробки ПЗ (Software Engineering Institute, SEI). Цей шаблон більш вимогливий до якості процесу порівняно з MSF for Agile і використовує ширший набір робочих елементів.
Оскільки ці шаблони процесів мають різну спрямованість, то вони містять різні набори робочих елементів (див. табл. 2.3). І навіть схожі робочі елементи з різних шаблонів мають різний життєвий цикл.
Таблиця 2.3
СПИСОК РОБОЧИХ ЕЛЕМЕНТІВ ДЛЯ AGILE И CMMI
| Назва робочого елемента |
Опис |
Наявність у шаблоні |
| MSF for Agile |
MSF for CMMI |
| Задача |
Визначає потреби у виконанні певної роботи |
+ |
+ |
| Помилка |
Використовується для керування і документування виявлених помилок у системі, що розробляється |
+ |
+ |
| Ризик |
Описує можливі ситуації або умови, що можуть негативно вплинути на успіх проекту |
+ |
+ |
| Вимога якості обслуговування |
Вимоги, не пов’язані напряму з функціональними можливостями системи: вимоги до безпеки, продуктивності тощо |
+ |
|
| Сценарій |
Описує методи взаємодії користувачів у системі |
+ |
|
| Вимога |
Документує вимоги до системи — як функціональні, так і нефункціональні характеристики системи |
|
+ |
| Запит на зміни |
Використовується для реєстрації і керування вхідними запитами від зацікавлених осіб щодо внесення змін до проектованої системи |
|
+ |
| Проблема |
Проблеми, що негативно впливають на виконання проекту |
|
+ |
| Перевірка |
Описує роботи, пов’язані з оглядом |
|
+ |
Наприклад, робочий елемент «задача» має такий набір станів:
у шаблоні MSF for Agile (рис. 2.13, а):
— активно — стан, у який задача переходить при реєстрації.
З цього стану можливий лише перехід у стан «Закрито» в разі завершення всіх робіт із задачі, відкладання задачі до наступної ітерації або видалення задачі як застарілої;
— закрито — задачу можна визначити як активну, якщо відповідні роботи не було завершено; у шаблоні MSF for CMMI (рис. 2.13, б):
— запропоновано — цей стан автоматично встановлюється для всіх нових задач, оскільки деталі їх виконання ще слід узгодити. Після розгляду задача передається до виконання, на уточнення або відміняється через непотрібність;
— активно — було прийнято рішення щодо виконання задачі і були ініційовані відповідні роботи. Згодом задачу можна перевести у стан «Запропоновано», якщо роботи вивчено і необхідно приймати рішення з її реалізації. Якщо роботи виконано, задача переводиться в наступний стан для перевірки результатів. Крім цього, задачу можна закрити в разі відміни або відкладення робіт;
— дозволено — виконані роботи потребують перевірки. Якщо перевірку виконано успішно, задача закривається, в іншому разі повертається у стан «Активно»;
— закрито — всі роботи припинено, їх можна відновити в разі помилкового закриття або необхідності продовження відкладених раніше робіт.
Після ознайомлення зі змістом та керівництвами з процесів, що поставляються разом з TFS, організація обирає підхожий для її потреб шаблон. Можливий також проектнопроцесний підхід, за яким процеси комбінуються залежно від його типів і важливості проектів.
Реальний проект може не відповідати стандартним шаблонам. Наприклад, в організації прийнятий процес SCRUM, а шаблон не має відповідних елементів. У таких випадках можна створити новий шаблон процесу, змінити наявні або вибрати один із шаблонів, що пропонуються партнерами Microsoft.
Налаштування шаблона процесу відбувається в такій послідовності: перегляд шаблонів процесів у TFS і вибір найдоцільнішого до реальних процесів організації, скачування вибраного шаблона, налаштування його компонентів, завантаження шаблона в TFS і перевірка задоволення вимог реального процесу. Налаштування XMLфайлів можна здійснювати вручну, що потенційно є точнішим, але пов’язане з великою кількістю помилок, а також за допомогою утиліт Power Tools, що розширюють можливості TFS і містять всі засоби для змінення робочих елементів: редактор полів (рис. 2.14) з можливістю їх тонкого налаштування, візуальний редактор форм, візуальний редактор життєвого циклу (рис. 2.15).
Робочі елементи можна редагувати безпосередньо в описі шаблона процесів, при цьому виконані зміни фіксуються лише в шаблоні і застосовуються тільки для нових проектів, що створюються після внесення змін. Інший варіант — редагування робочих елементів у проекті, що функціонує, за допомогою спеціальних утиліт для експорту та імпорту описів робочих елементів, що поставляються разом з TFS. У цьому варіанті зміни застосовують лише для поточного проекту. Якщо зміни необхідні і для загального шаблона, і для деяких робочих проектів, тоді зміни вносять у шаблон, а згодом на основі його файлів здійснюють оновлення за допомогою утиліт імпортуекспорту для всіх необхідних проектів.
