Методології розроблення ПЗ

Найбільш помітними є такі методології розроблення ПЗ:

• Rational Unified Process (RUP), що пропонує ітеративну модель розроблення, що включає чотири фази: початок, дослідження, побудову та впровадження [33]. Проходження через чотири основні фази називається циклом розроблення, кожен цикл завершується генерацією працездатної версії системи. У ході супроводу продукт продовжує розвиватися і знову проходить ті самі фази. Розроблення ПЗ на базі RUP базується на створенні та супроводі моделей на базі UML.
• Microsoft Solution Framework (MSF) – методологія, що розроблялася для підвищення керованості процесів розроблення окремого підприємства (Microsoft), а потім стала застосовуватися розробниками, які використовують продукти Microsoft. Методологія, подібна до RUP, також включає чотири фази: аналіз, проектування, розроблення, стабілізацію, є ітераційною, припускає використання об’єктно-орієнтованого моделювання. MSF порівняно з RUP здебільшого орієнтована на розроблення бізнес- додатків [34].
• eXtreme Programming (XP) – методологія, що приділяє основну увагу ефективній комунікації між замовником і виконавцем упроовж усього проекту з розроблення ІС для відслідковування зміни вимог [19]. В основу підходу покладена командна робота та постійне тестування прототипів.
• Гнучке розроблення ПЗ (Agile) – клас методологій розроблення програмного забезпечення на основі ітеративної моделі ЖЦ, в якій вимоги та рішення еволюціонують через співпрацю між самоорганізовуваними командами [35].

Методологія Rational Unified Process (RUP)

Уніфікований процес розроблення ПЗ Rational Unified Process (RUP) [33] виник як відповідь на потребу розробників у процесі, що об’єднує безліч аспектів розроблення програм і відповідає таким вимогам:

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

Уніфікований процес розроблення    ПЗ       передбачає розподіл ЖЦ програмного забезпечення на фази (рис.27).

Рисунок 27 – Робочі процеси ЖЦ в уніфікованому процесі розроблення ПЗ

Специфіка уніфікованого процесу полягає у трьох словосполученнях – керований варіантами використання, архітектурно-орієнтований, ітеративний та інкрементний.

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

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

Взаємодія актора із системою називається варіантом використання, або прецендентом. Варіант використання (ВВ), або прецендент, (use case) – це частина функціональності системи, необхідна для отримання користувачем значущого для нього, відчутного і вимірюваного результату. ВВ забезпечують функціональні вимоги. Сума всіх ВВ становить модель ВВ (use- case model), що описує повну функціональність системи. Ця модель заміняє традиційно опис функцій системи. На основі прецедентів в уніфікованому процесі будуються інші моделі для кожного етапу ЖЦ (рис.28)

Рисунок 28 – Моделі ПЗ на кожному етапі ЖЦ

За набором реалізацій ВВ будується концептуальна модель системи – модель аналізу (analysis model), що є детальним описом усіх вимог та потрібних для реалізації робіт. Ґрунтуючись на моделі ВВ, розробники створюють серію моделей проектування і реалізації, які здійснюють прецеденти.

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

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

Модель реалізації (implementation model) – дає опис, як елементи моделі проектування реалізуються у вигляді компонентів, таких, як файли із кодом програм та виконувані файли.

Модель тестування (test model) – дає опис, як виконувані компоненти моделі реалізації тестуються на цілісність та проходять системні тести.

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

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

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

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

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

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

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

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

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

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

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

виконала свого завдання, розробники повинні переглянути свої рішення і спробувати інший підхід.

Рисунок 29 – Ітеративність уніфікованого процесу розроблення ПЗ

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

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

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

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

---