Лекція 9

Формалізовані методології Microsoft Solutions Framework та RUP

9.1 Формалізовані методології, розроблені ІТ-компаніями

Rational Unified Process (RUP) - ітеративний процес розробоки ІС, орієнтований на створення та супровід моделей на базі UML. Проходження через чотири основні фази називається циклом розробки, кожен цикл завершується генерацією працездатної версії системи. В ході супроводу продукт продовжує розвиватися і знову проходить ті ж фази. Розробка ПЗ на базі RUP базується на створенні та супроводі моделей на базі UML.
Microsoft Solution Framework (MSF) – ітеративний підхід, передбачає використання об’єктно-орієнтованого моделювання, орієнтований на розробку бізнес-додатків. Методологія подібна до RUP, також включає чотири фази: аналіз, проектування, розробка, стабілізація, є ітераційною, припускає використання об'єктно-орієнтованого моделювання.

9.2 Уніфікований процес розроблення ПЗ - Rational Unified Process (RUP)

ітеративний та інкрементний ЖЦ
керується варіантами використання проектованої системи
орієнтований на архітектуру

9.2.1 Ітеративна розробка ПЗ в RUP

9.2.2 Життєвий цикл ПЗ в RUP

Робочий процес визначення вимог

Робочий процес аналіз вимог

Робочий процес проектування

Робочий процес реалізація

Робочий процес тестування

9.3 Стандарт CMMІ на зрілість процесів розробки ПЗ

Стандарт міністерства оборони США для вибору підрядника для виконання державних замовлень ПЗ.
1987 р. Software Engineering Institute (SEI) розробив модель огляду зрілості процесів розроблення програмного забезпечення Capability Maturity Model (CMM). Модель розвивалась до 1997 р.
2002 р. розроблена Capability maturity model integration (CMMI) v.1.1 – методологія удосконалення процесів організації, спрямована на поліпшення зручності використання моделей зрілості шляхом інтеграції моделей в одну структуру

Shape1

2010 р. вийшла версія 1.3 CMMI, яка містила підтримку гнучкої розробки та безперервної поставки ПЗ

2018 р. вийшла версія 2.0 CMMI, яка об’єднала три моделі в одну

Ключове поняття – Зрілість організації (Maturity).

Містить критерії оцінки зрілості компанії та перелік дій для подальшого вдосконалення.

9.3.1 Capability Maturity Model Integration (CMMI)

Незріла організація

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

Зріла організація

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

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

Зріла організація

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

9.3.2 Рівні CMMI 2.0

Shape2

Ключові області процесу (Key Process Area) на рівнях зрілості організації містять-

цілі (Goal)
обов'язки з виконання (Commitment to Perform)
можливість виконання (Ability to Perform)
виконувані дії (Activity Performed)
їх вимірення та аналіз (Measurement and Analysis)
перевірку впровадження (Verifying Implementation)

9.4 Microsoft Solution Framework (MSF)

MSF - набір принципів, моделей та дисциплін керування персоналом, технологічними елементами та пов'язаними з ними питаннями

Shape3

9.4.1 Накопичення знань для керування діяльністю

Shape4

9.4.2 MSF Базові принципи

1. Сприяння відкритому спілкуванню
2. Забезпечення спільного бачення
3. Допомога членам команди
4. Чітка звітність та спільна відповідальність
5. Зосередження на підвищенні вартості бізнесу
6. Забезпечення гнучкості, очікування змін
7. Інвестування в якість
8. Навчання з досвіду (власного і чужого)
9. Партнерство з клієнтами

9.5 MSF

9.5.1 Модель проектної групи (Team Model)

Основні принципи:

- Розподіл відповідальності з фіксацією у звітах
- Надання членам команди повноважень
- Концентрація на бізнес-пріоритетах
- Єдине бачення проекту
- Гнучкість
- Вільне спілкування

Ключові концепції:

- Команда однодумців
- Фокус на потребах замовника
- Націленість на кінцевий результат
- Відсутність дефектів
- Прагнення до самовдосконалення
- Зацікавленість команди для підвищення ефективності

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

Рольові кластери

Shape5

проектна група MSF складається з шести рольових кластерів, кожен з яких відповідає за:
управління програмою (program manager) - розробку архітектури рішення, адміністративні служби;
тестування (QAE) - планування, розробку тестів і звітність по тестах;
управління випуском (release manager) - інфраструктуру, супровід, бізнес-процеси, випуск готового продукту;
задоволення замовника (user experience) - навчання, ергономіку, графічний дизайн, технічну підтримку;
управління продуктом (product manager) - бізнес-пріоритети, маркетинг, представництво інтересів замовника.

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

Program management – керування програмою відповідно до проектних обмежень:

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

Product management – забезпечення задоволення клієнта:

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

Release / Operations – керування випуском:

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

Architecture – відповідальність за систему в цілому:

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

Development – розробка відповідно до специфікацій:

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

User experience – підвищення ефективності роботи користувачів:

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

Test – затвердження випуску релізу після вирішення усіх проблем якості:

виявлення й усунення недоробок, виправлення помилок, інші функції QA (Quality assurance)

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

Команда:

- група виконавців, що ділять відповідальність та доповнюють компетенції;
- Min розмір – 3 особи. Команди більше 10 осіб ділять на профільні команди (feature teams);
- Обов'язкове виконання всіх рольових кластерів;
- Роль розробника (developer) не об'єднується із іншими;
- Відповідальність на лідерах рольових кластерів;
- Професійні менеджери консультують команду.

9.5.4 MSF. Модель управління (Governance model)

Основні принципи:

- Ітеративний підхід (послідовний випуск версій)
- Підготовка чіткої документації
- Врахування невизначеності майбутнього
- Облік компромісів
- Керування ризиками
- Підтримка відповідальності колективу за строки
- Великі проекти розбиваються на дрібні керовані частини
- Постійний аналіз ходу робіт

Особливості:

- Розбивка всього процесу на 5 взаємозалежних фаз (Envisioning, Planning, Developing, Stabilizing, Deploying), кожна з яких має мету щодо якості
- Введення контрольних точок (milestones) – моментів, у яких аналізується стан робіт і виконується їх синхронізація
- Поєднує каскадну та спіральну моделі ЖЦ;
- Гнучкий процес, який складається з коротких циклів;
- MSF 4.0 забезпечує весь життєвий цикл програмного продукту та IT-проектів та ділиться на:
  - MSF for Agile software development (MSF4ASD)
  - MSF for the Capability Maturity Model (MSF4CMMI)

Фази:

- Envisioning – вироблення єдиного розуміння проекту всіма членами колективу
- Planning – планування чергового циклу розробки;
- Developing – розробка, рекомендуються різні технологічні прийоми (перевикористання фрагментів коду, програмування за контрактом, написання захищеного від помилок ПЗ й т.п.)
- Stabilizing – створення стабільної версії (визначення, що рішення відповідає потребам та очикуванням)
- Deploying – розгортання системи

Envisioning – закінчується виробленням формалізованої документації, яка складається з:

- problem statement - опис завдання (1 стор.);
- vision statement - від йдемо, чого хочемо домогтися;
- solution concept - що хочемо впровадити і як;
- user profiles - хто буде цим користуватися;
- business goals - повернення інвестицій;
- design goals - конкретні цілі й обмеження продукту, його конкретні властивості.

Planning – закінчується виробленням формалізованої документації, яка складається з:

- функціональних специфікацій;
- плану-графіку робіт;
- оцінки ризиків.

9.5.5 MSF. Дисципліна Керування ризиками

(risk management discipline)

Галузь знань стосовно принципів та рекомендацій з покроковим описом процесу для керування ризиками:

- Передбачення ризиків
- Безперервна оцінка ризиків
- Врахування ризиків в ході прийняття рішень протягом усього життєвого циклу

Процес управління ризиками MSF визначає шість логічних кроків, які команда використовує для управління поточними ризиками, планування та виконання стратегій управління ризиками, а також отримання знань для підприємства. Наступний список містить детальну інформацію про кожну з шести кроків управління ризиками.
Визначите (Identify). Процес ідентифікації ризиків вимагає, щоб усі члени команди брали участь у виникненні ризиків, щоб команда була обізнана про потенційні проблеми. Як внесок у процес управління ризиками, ідентифікація ризику повинна здійснюватися якомога раніше і часто повторюватися протягом всього життєвого циклу проекту.
Проаналізувати та визначити пріоритети (Analyze and Prioritize). Аналіз ризиків перетворює оцінки або дані про конкретні ризики проекту, що виникають під час ідентифікації ризику, у форму, яку команда може використовувати для прийняття рішень щодо визначення пріоритетів. Визначення пріоритетності ризиків дає змогу команді залучати ресурси проекту для управління найважливішими ризиками.
Спланувати (Plan and Schedule). Планування ризиків приймає інформацію, отриману в результаті аналізу ризиків і визначення пріоритетів, і використовує її для формулювання стратегій, планів і дій. Планування ризиків гарантує, що ці плани будуть затверджені, а потім включені в процес управління проектами та інфраструктуру для забезпечення того, щоб управління ризиками здійснювалося як частина повсякденної діяльності команди. Планування ризиків явно пов'язує планування ризиків з плануванням проекту.
Відстежувати та звітувати (Track and Report). Відстеження ризиків контролює стан конкретних ризиків та прогрес у їхніх відповідних планах дій. Відстеження ризиків також включає в себе моніторинг ймовірності, впливу, впливу та інших заходів ризику для змін, які можуть змінити пріоритет, плани ризиків та особливості проекту, ресурси або графік. Відстеження ризиків забезпечує видимість процесу управління ризиками в рамках проекту з точки зору рівнів ризику, на відміну від перспективи завершення завдання стандартного операційного процесу управління проектами. Звіт про ризики гарантує, що команда, спонсор та інші зацікавлені сторони знають про стан проектних ризиків та плани щодо управління ними.
Контролювати (Control). Контроль ризиків - це процес виконання планів дій щодо ризиків та відповідного звітування про стан. Контроль ризиків також включає в себе ініціювання запитів на контроль змін у проекті, коли зміни в статусі ризику або планах ризику можуть призвести до змін у характеристиках проекту, ресурсах або графіку.
Вчитися (Learn). Навчання ризику формалізує уроки, засвоєні в проекті, збирає відповідні артефакти та інструменти проекту, і захоплює ці знання у багаторазовій формі.

9.5.6 MSF. Дисципліна Керування проектом

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

- Відповідальність на лідерах рольових кластерів
- Професійні менеджери консультують команду
- Базові принципи відповідають принципам моделі проектної групи

Професійні менеджери є консультантами і наставниками команди, але не контролюють її.

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

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

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

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

Моніторинг прогресу проводиться всією командою і стає допоміжним.

Базові принципи:

- Плануйте та контролюйте зміни
- Визначте та керуйте обсягом проекту
- Підготуйте бюджет і керуйте витратами
- Формуйте та відстежуйте графіки
- Переконайтеся, що для проекту виділено відповідні ресурси
- Управляйте договорами та постачальниками
- Сприяйте команді та зовнішнім комунікаціям
- Сприяйте процесу управління ризиками

Документуйте та контролюйте процес управління якістю.

Матриця компромісів:

9.5.7 MSF. Дисципліна керування підготовкою (readiness management)

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

Розвиток засобів забезпечення процесів життєвого циклу

Shape6