ЛК. 10 – СУЧАСНІ МЕТОДОЛОГІЇ УПРАВЛІННЯ ПРОГРАМНИМИ ПРОЕКТАМИ

Анотація

Введення до методологій управління програмними проектами. Загальна характеристика методології MSF в управлінні програмними проектами. Моделі, які складають методологію MSF. Модель процесу MSF. Планування з урахуванням ризиків у MSF. Орієнтація на випуск версій продукту у MSF. Орієнтація на продукт у MSF. Загальна характеристика методології RUP в управління програмними проектами. Виміри процесу розробки у методології RUP. Статичний зміст процесу у RUP.

10.1 Введення до методологій управління програмними проектами

Методології управління програмними проектами являють собою набір вивірених підходів, які регламентують організацію процесу розробки ПЗ.

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

10.2 Загальна характеристика методології MSF в управлінні програмними проектами

Корпорація Microsoft є розробником двох взаємодоповнюючих стандартів – MSF (Microsoft Solutions Framework) та MOF (Microsoft Operations Framework). Стандарт MSF відповідає за розробку ПЗ, а MOF – за розгортання і використання ПЗ .

MSF являє собою «виважений і дисциплінований підхід до технологічних проектів, оснований на наборі принципів, моделей, дисциплін, концепцій, рекомендацій і доведених практик від Microsoft» [141, С. 4]. MOF розроблено на основі стандарту ITIL (IT Infrastructure Library), який створений за участі уряду Великобританії і є найбільш поширеним у даний час підходом до управління службами інформаційних технологій у світі [17].

В основі MSF лежать наступні ідеї:

-       управління ризиками і їхнє планування;

-       випуск проміжних версій;

-       планування активності;

-       чітко позначені контрольні віхи;

-       проектні групи невеликої чисельності.

10.3 Моделі, які складають методологію MSF

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

Модель проектної групи MSF

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

Характеристики ефективної проектної групи відповідно до MSF:

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

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

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

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

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

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

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

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

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

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

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

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

Модель процесу MSF

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

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

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

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

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

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

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

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

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

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

Рис. 10.2 – Діаграма моделі процесу MSF

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

Планування з урахуванням ризиків у MSF

Планування з урахуванням ризиків:

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

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

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

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

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

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

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

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

10.4 Орієнтація на випуск версій продукту у MSF

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

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

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

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

10.5 Орієнтація на продукт у MSF

MSF є орієнтованою на продукт методологією. Орієнтація на продукт означає, що, на відміну від орієнтації на процес, яка характерна, наприклад, для стандартів CMM/CMMI, пріоритетом є створення продукту високої якості.

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

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

10.6 Загальна характеристика методології RUP в управління програмними проектами

Методологія Rational Unified Process (RUP) – ітеративний процес, що передбачає управління вимогами і змінами на основі об’єктно-орієнтованої та компонентно-орієнтованої технологій і побудови та обслуговування моделей, які дають семантично багаті представлення програмної системи під час її розробки

Ключові терміни:

Робітник – визначає поведінку однієї особи чи групи осіб, які виконують певну роль.

Дія – найменша частина роботи (технічна операція).

Артефакти – штучні об’єкти (конструкції моделювання і документи), які виділяють, підтримують і використовують як вихідну інформацію

Рис. 10.3 – Основні ідеї RUP

10.7 Виміри процесу розробки у методології RUP

RUP представляє процес розробки в двох вимірах:

-       за змістом дій учасників груп розробки (основним потокам робіт) – статичний аспект процесу – описано в термінах основних потоків робіт (виконавці, їх дії і т.д.);

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

Рис. 10.4 – Виміри процесу розробки у методології RUP

Статичний зміст процесу у RUP

Шість потоків робіт процесу розробки:

-       бізнес-моделювання;

-       вимоги;

-       аналіз та проектування;

-       виконання;

-       тестування;

-       розгортання.

Три потоки робіт підтримки:

-       управління конфігураціями та змінами;

-       управління проектом;

- середовище.

Життєвий цикл програмного проекту згідно з методологією RUP

Рис. 10.5 – Життєвий цикл програмного проекту згідно з методологією RUP

10.8 Методології швидкої розробки при управлінні програмними проектами

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

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

Екстремальне програмування (XP) – підхід, основна ідея якого полягає у тому, що робити потрібно лише те, що приносить користь для проекту і не робити того, що користь не приносить.

Важливі принципи XP: сумісне володіння кодом; юніт-тести; парне програмування; розробки на основі «user stories».

СP.10 – Сучасні методології управління програмними проектами

1.     Модель програмного забезпечення MSF [4, С. 145-157].

2.     Терміни основних потоків робіт у RUP [4, С. 99-120].