• 4.1                    Основні принципи уніфікованого процесу розроблення ПЗ
• 4.2                    Уніфікований процес керується варіантами використання
• 4.3                    Уніфікований процес, орієнтований на архітектуру

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

Аналіз результатів виконання програмних проектів, виконаний службою Microsoft Consulting Services, виявив, що лише чверть  проектів можна визнати успішними, половина проектів мала великі проблеми (рис. 1).

Основними причинами невдач були визнані такі:

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

Для подолання цих труднощів був запропонований набір моделей Мicrosoft Solution Framework (MSF) [34], в якому врахований досвід, накопичений групами розроблення програмних продуктів.

В основу MSF покладено вісім базових принципів (foundational principles):

• Сприяння відкритої комунікації (Foster open communications). Модель процесу MSF запроваджує вільний інформаційний потік сред членів команди та зацікавлених сторін (key stakeholders) для забезпечення однакового розуміння завдань. Документування ходу проекту та доступ до цих даних членів команди, зацікавлених сторін та замовників.
• Робота у напрямку спільного бачення проекту (Work toward a shared vision). Модель процесу MSF запроваджує фазу формування концепції (Envisioning Phase) та окремий ключовий момент затвердження бачення (milestone Vision/Scope Approved) для формування спільного бачення проекту. Бачення включає детальне розуміння цілей та завдань для досягнення рішення поставленої проблеми. Спільне бачення виявляє припущення команди та замовників, потрібні для отримання рішення.
• Надання прав і можливостей членам команди (Empower team members). Розширення прав і можливостей членів команди для прийняття ними відповідальності за виконану роботу. Таке збільшення відповідальності може бути затверджене  у графіках, де фіксується дата закінчення робіт, що також може бути засобом виявлення можливих затримок проекту.
• Визначення індивідуальної та спільної відповідальності (Establish clear accountability and shared responsibility). Модель командної групи MSF ґрунтується на принципі важливості роботи кожного для отримання якісного рішення проблеми. Усі члени групи розділяють відповідальність за проект.
• Зосередження на бізнес-цілях (Focus on delivering business value). Рішення повинне приносити користь організації у вигляді додавання вартості бізнесу. Це додавання досягається тільки після повного розгортання рішення у виробничому середовищі.
• Бути гнучкими, очікувати на зміни (Stay agile, expect change). MSF припускає, що у виробничому середовищі на рішення постійно впливають зміни. Команда повинна бути обізнаною та готовою до керування змінами вимог.
• Інвестування у якість (Invest in quality). У MSF кожен член команди відповідальний за якість вирішення завдання.Для підтримки якості протягом проекту формується команда тестувальників. Це гарантує, що рішення відповідає рівню якості, визначеному зацікавленими сторонами.
• Навчання за досвідом (Learn from all experiences). MSF вимагає використання досвіду, отриманого у попередніх проектах. Це дозволяє знайти найкращі методики розроблення.

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

• моделі командної групи;
• моделі процесу;
• дисципліни управління проектами;
• дисципліни управління ризиками;
• дисципліни управління підготовкою.

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

Формування колективу є складним завданням, що повинне виконуватися психологами та враховувати такі основні положення:

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

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

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

Product management – керування продуктом. Виконавці цієї ролі відповідають за спілкування із замовником, написання специфікації, роз'яснення завдань розроблювачам.

Development – найбільш традиційна роль – розроблення і початкове тестування продукту.

User expirience – підвищення ефективності роботи користувачів, написання користувальницької документації.

Release management – розгортання релізу продукту, супровід і його технічна підтримка.

Test – визначення відповідності показників якості релізу встановленим значенням. Виявлення й усунення недоробок, виправлення помилок, інші функції QA.

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

Модель процесу (MSF Process Model) визначає, коли і які роботи повинні бути виконані.

Основні принципи і практичні прийоми, на яких ґрунтується модель:

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

Process model має три основні особливості:

• розбивка всього процесу на фази;
• використання опорних точок (milestones);
• ітеративність.

Увесь процес розбивається на п’ять взаємозалежних фаз (рис. 3). Перш ніж переходити до наступної фази, на попередній повинні бути отримані певні результати (досягнуті головні опорні точки). Фактично процес ітеративний і відповідає спіральній моделі ЖЦ ПЗ.

Envisioning Phase – вироблення єдиного розуміння проекту всіма членами колективу. Ця фаза закінчується розробленням формалізованого документа, що містить:

• problem statement – опис завдання на розроблення ПЗ обсягом не більше однієї сторінки;
• vision statement – опис того, від чого відштовхується розроблення і яким результатом закінчується;
• solution concept - що буде впроваджене в результаті вирішення поставленої проблеми;
• user profiles – опис потенційних користувачів системи;
• business goals – опис бізнес-функцій, виконання яких за допомогою розробленого ПЗ поверне інвестиції;
• design goals – конкретні цілі й обмеження програмного продукту, його конкретні властивості.

Planning Phase – планування чергового циклу розроблення:

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

Developing Phase – розроблення, причому рекомендуються різні технологічні прийоми, наприклад, повторне використання фрагментів коду, програмування за контрактом, написання захищеного від помилок ПЗ та ін.

Stabilizing Phase – створення стабільної β-версії, готової до використання.

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

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

Усередині кожної фази визначаються проміжні опорні точки (interium milestones). Вони, як і головні, слугують для аналізу й синхронізації досягнутого, а не для заморожування проекту. Але на відміну від головних опорних точок проміжні видні тільки членам колективу розробників.

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

4.1                    Основні принципи уніфікованого процесу розроблення ПЗ

Як було зазначено у темі 3 уніфікований процес розроблення ПЗ (RUP) реалізує ітеративний та інкрементний ЖЦ програмного забезпечення, який керується варіантими використанння проектованої системи. RUP відповідає таким вимогам:

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

4.2                    Уніфікований процес керується варіантами використання

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

Як видно із рис.3.2 процес розроблення проходить серії робочих процесів, кожен з яких ініціюється варіантами використання (ВВ): прецеденти визначаються, вони проектуються, і врешті-решт варіанти використання є вхідними даними, за якими тестери створюють тестові приклади. Оскільки прецеденти дійсно керують процесом, вони не виділяються ізольовано, а розробляються в парі з архітектурою системи. Відповідно і архітектура системи, і ВВ розвиваються впродовж життєвого циклу ПЗ. Таким чином, прецеденти не лише ініціюють процес розроблення, але й слугують для зв'язку окремих його частин. 

4.3                    Уніфікований процес, орієнтований на архітектуру

Архітектура програми включає в себе найбільш важливі статичні і динамічні аспекти системи та будується на основі вимог до результату. Як було відмічено вище, вимоги відбиваються у варіантах використання. Однак прецеденти також залежать від безлічі інших чинників, таких, як вибір платформи для роботи програми (тобто комп'ютерної архітектури, операційної системи, СКБД, мережевих протоколів), доступність готових блоків багаторазового використання (наприклад, каркасу GUI), спосіб розгортання, успадковані системи і нефункціональні вимоги (наприклад, продуктивність і надійність). Архітектура ПЗ – це представлення всього проекту із виділенням важливих характеристик без акценту на деталях.

Кожен продукт має функції і форму. Одне без іншого не існує. Функції відповідають ВВ, а форма - архітектурі. В реальних умовах архітектура і прецеденти розробляються паралельно. Архітектура повинна бути спроектована так, щоб дозволити системі розвиватися не тільки в момент початкового розроблення, але і в майбутніх поколіннях. Щоб знайти таку форму, архітектор повинен працювати, повністю розуміючи ключові функції, тобто ключові варіанти використання системи. Ці ключові варіанти використання становлять 5-10% усіх ВВ, але вони дуже важливі, оскільки містять функції ядра системи. Архітектор виконує такі кроки:

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

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

Розробники вибирають завдання, які повинні бути вирішені у ході ітерації, враховуючи два фактори:

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

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

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

Керований ітеративний процес має такі переваги [32]:

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

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

Структура моделей  уніфікованого процесу описана у розділі 3.5  Моделі уніфікованого процесу розроблення ПЗ лекції "Нотації візуального моделювання ПЗ" до теми 3.