Реінженірінг програмних продуктів в гнучких технологіях з використанням патернів

Abstract

Процес розробки програмного забезпечення (ПЗ) суттєво змінюють та покращують такі методи гнучких технологій як екстремальне програмування (XP), гнучкий підхід управління проектами (Scrum), Kanban та інші. Прихильники даних методів запевняють, що якість гнучких програмних проектів є закономірним результатом застосованого методу через саму природу таких методів. В результаті очікується, що гнучка система забезпечення якості розробки програмного забезпечення (ASDQA) буде вбудована в гнучкі програмні процеси, поки методи забезпечення якості програмного забезпечення (SQA) вбудовані протягом всього життєвого циклу(ЖЦ), від початку встановлення вимог і до останнього випуску включно. Отже, гнучкі методи дозволяють інакше розглянути контролювання якості при розробці програмного забезпечення. Гнучкі технології мають дозволити випускати ПЗ у короткі терміни, з меншою кількістю помилок, з певними бюджетними обмеженнями, використовувати непостійні та мінливі вимоги протягом усього ЖЦ розробки програмного продукту. Такий поступовий спосіб розробки дозволяє забезпечити механізм зворотного зв’язку, завжди розуміти вимоги замовника і залучати його у процес прийняття рішень, що в результаті призводить до задоволення кінцевим продуктом. Таким чином, гнучкі методи також змушують замовників допомагати покращувати та забезпечувати якість продукту. Використання таких практик як парне програмування, просте планування та проектування, метафора, невеликі випуски, спільне володіння кодом, короткі ітераційні цикли та постійні ітерації потенційно посилює забезпечення якості. Тому метою першого розділу є розширити розуміння та дати всебічне визначення гнучким технологіям та пояснити, вирішити проблеми, пов’язані з адаптацією гнучких технологій, а також яким чином гнучкі методи можуть удосконалити забезпечення якості ПЗ, порівняно з традиційними підходами. Дане розуміння також представить можливість виявити, що означає якість у гнучких технологіях. Коли частини архітектури програмної системі можуть змінюватися та коли розробляються подібні системи з різними сценаріями використання, важливу роль займає змінюваність – очікувані і попередньо заплановані зміни. Змінюваність включена та відображається в архітектурі ПЗ у великій кількості сучасних систем, наприклад, само-адаптивні системи, системи, які підтримують динамічні веб-сервіси тощо. Тобто під час проектування архітектури ПЗ необхідно пам’ятати про керування змінюваністю – процеси, які стосуються ідентифікації, обмеження, впровадження та керування змінюваністю. Важливою є гнучка парадигма – гнучкі методи, які створені на основі принципів маніфесту, та практик, які забезпечують адаптацію до змін. Змінюваність зручно використовувати у випадках проектування систем, коли потреби клієнтів або контексти недостатньо відомі, а гнучку розробку – з будови програмних рішень ще до того, як продукт буде цілковито зрозумілим. Тож за допомогою поєднання при проектуванні архітектури гнучкої парадигми та змінюваності можливо досягти гнучкої адаптивної програмної архітектури, і відповідно системи. Такі зміни забезпечують доступність інформації про змінність на різних етапах розробки – при тестування та реалізації системи. Тому такий підхід поєднання може бути корисний проектам з часто змінюваними вимогами, важливістю постійного зворотного зв’язку з клієнтами, короткими термінами та графіками, необхідністю зосередитися у більшій мірі на розробці ПЗ, а не на документації та плануванні, що дозволить керувати змінюваністю за короткий проміжок часу і з невеликої кількістю зусиль. Останнім часом популярною темою в гнучкій методології є тема виникаючої архітектури, яка тісно пов'язана з суперечками, чи архітектор є важливою і необхідною частиною в гнучких проектах або всі архітектурні роботи можуть бути виконані командою розробників. Тому інша частина цього розділу розглядатиме виникаючу архітектуру, як і в якій мірі претензії на виникаючу архітектуру є істинними. Тому спочатку буде розглянута мета, діяльність і завдання архітектурної роботи. Згодом буде проаналізовано, чи підходить виникаюча архітектура для заміни різних видів діяльності та цілей архітектурної роботи, зважаючи на її мету. Під час обговорення, сильні та слабкі сторони явних і виникаючих архітектурних робіт будуть протиставлятися одна одній, і буде запропонований спільний підхід. З кожним роком у сфері програмування відбувається все більше змін, які в результаті спричиняють до труднощів, які зустрічаються в архітектурі та які усунути стає складніше та дорожче по витратам. Прикладами таких змін можуть бути: зміна технологій розробки та інфраструктури, створення/введення/перегляд додаткових вимог, які і призводять до виникнення помилок(багів) і прийнятих помилкових рішень. Але зосереджуватися важливо не на змінах, які відбуваються в системі, а саме на архітектурі ПЗ, так як якщо вона буде спрямована на внесення нових функцій, то вони можуть настільки збільшити і розширити даний проект, що в кінці кінців він стане некерованим і супроводжувати такий програмний продукт стане неможливим. Це стосується і певних випадків розробки архітектури, коли кожне помилково прийняте рішення призводить до незворотного результату та наслідків. Аби уникнути такої долі проекту, обов’язковим фактором в архітектурі ПЗ є періодичне чергування проектних робіт з ітеративною оцінкою архітектури та проведення рефакторингу – метод покращення внутрішньої структури ПЗ без зміни зовнішньої поведінки системи. Якщо впровадити систематичне проведення рефакторингу у свій проект, це дозволяє розробникам ПЗ використовувати рішення, які є вже перевіреними та які приносять успішний результат. Тобто проведення оцінювання архітектури та рефакторингу допомагає уникнути ерозії проекту. Мета рефакторингу покращити область, яка в цілому може поліпшити архітектуру. Для того аби визначити проблеми цієї області, а отже, і архітектури, і в подальшому провести рефакторинг було введено поняття «код з душком». Покращити якість внутрішньої архітектури можна за допомогою моделей та патернів рефакторингу. Одним із шляхів проведення рефакторингу архітектури – використання патернів, коли архітектура складається із стандартних компонентів і внесення змін відбувається пошарово. Однак існує багато альтернативних шаблонів, тому необхідно їх якось оцінювати і вибрати кращий. Є декілька методів оцінювання, найбільш конструктвний і обгрунтваний, на наш погляд – метод аналізу ієрархій. І в останньому розділі створено проектування програмного комплексу аналізу якості архітектури та проведення рефакторингу, описано процес створення альтернативних архітектур, оцінювання їх та прийняття рішень, що є досить актуальним, так як це допомагає визначити якість програмного продукту. Тому метою цієї роботи є проектування програмного комплексу аналізу якості архітектури та проведення рефакторингу, який вирішить задачі перепроектування архітектури при внесенні змін у вимоги і як результат забезпечить високу задоволеність замовника, який постійно контактує з розробниками і вносить свої корективи у розробку програмного продукту.