Методологія розробки програмного забезпечення
| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
| Стандарти та галузі знань |
Методологія розробки програмного забезпечення (англ. Software development methodology) — сукупність методів, застосовуваних на різних стадіях життєвого циклу розробки програмного забезпечення, що мають спільний філософський підхід та, відповідно до цього підходу, дозволяють забезпечити найкращу ефективність процесів розробки.
Кожна методологія характеризується:
- Філософським підходом або основними принципами. Ці принципи, від яких залежить ефективність всієї методології, зазвичай можна коротко сформулювати і легко пояснити;
- Узгодженою множиною моделей та методів, які реалізують дану методологію;
- Концепціями (поняттями), що дозволяють більш точно визначити методи.
У вужчому значенні, коли методологія застосовується на стадії програмування (конструювання), її зазвичай називають парадигмою програмування.
Поширені методології програмування: водоспадна модель (waterfall), макетування (prototyping), Ітеративна та інкрементна розробка (iterative and incremental development), (spiral development), спіральна модель (spiral model), швидка розробка програмного забезпечення (rapid application development), екстремальне програмування (extreme programming), різні види методологій гнучкої розробки (agile methodology).
Походження[ред. | ред. код]
Можна простежити три шляхи виникнення методологій. По-перше, вони можуть бути вираженням практичного досвіду. По-друге, методології можуть походити від однієї з чотирьох моделей алгоритму: абстрактна машина Тюрінга (імперативне програмування), рекурсивні функції Гільберта і Аккермана (структурне програмування), лямбда-числення Черча (функціональне програмування), нормальні алгоритми Маркова (логічне програмування). По-третє, методології можна пояснити через відображення однієї з трьох структур мови моделювання на структуру мови програмування. Складовими частинами можуть бути структура даних, структура управління і логіка. Кожне з дев'яти відображень визначає або методологію, або досить серйозний метод програмування. Наприклад, відображення логіка-логіка лежить в основі логічного програмування.
Класифікація[ред. | ред. код]
Класифікація за ядрами[ред. | ред. код]
При зверненні до методології, яка має ядро (англ. core), відповідне способу опису алгоритму, та додаткові особливості, можна виділити такі п'ять основних ядер методологій:
- Методологія імперативного програмування
- Методологія ООП
- Методологія функціонального програмування
- Методологія логічного програмування
- Методологія програмування в обмеженнях
Можна помітити, що ці методології знаходяться на шкалі від навігаційних (покрокове управління виконанням) до специфічних (визначення вимог до результату).
Класифікація за топологічною специфікою[ред. | ред. код]
Специфіка (топологічна специфіка) — спосіб вибору методів для уточнення ядра методології. Критерієм якості тієї чи іншої топології можуть бути загальні витрати на розробку ПЗ. Своєю чергою, витрати на розробку залежать серед іншого від ключових мовних абстракцій: абстракції даних, управління і модульності. Наприклад, в імперативній методології можна дотримуватися методів структурного програмування, що дає більш вигідну топологію з погляду мовних засобів. Результатом є методологія структурного програмування.
Класифікація за специфікою реалізації[ред. | ред. код]
Відповідно до архітектури апаратного забезпечення, реалізація може бути централізованою або паралельною. Наприклад, методологія (імперативного) паралельного програмування, методологія логічного паралельного програмування.
Крім того, методологія може бути гібридної. Наприклад, найбільш часта суміш функціонального та логічного програмування.
Проводяться дослідження щодо уніфікації методологій програмування.
Приклади методологій[ред. | ред. код]
Екстремальне програмування[ред. | ред. код]
З усіх гнучких методологій методологія екстремального програмування (XP) — найбільше відома. Частково це сталося тому, що лідери ХР, особливо Кент Бек (Kent Beck) наділені чудовою здатністю привертати до себе увагу. Важливу роль зіграв і талант Кента вербувати прихильників свого руху і вести їх за собою. Можна навіть сказати, що популярність ХР стала в деякому роді проблемою, бо ця методологія практично витіснила всі інші, а разом з ними і ті цінні ідеї, які вони несуть.
XP стоїть на чотирьох китах: Комунікація, Зворотний зв'язок, Простота і Сміливість. Із них слідують дванадцять практик, яким повинні слідувати проєкти, що використовують ХР. Багато з цих практик являють собою старі перевірені техніки, які, однак, багато встигли забути (включаючи більшість передбачуваних процесів). ХР не тільки воскрешає до життя такі техніки, але і з'єднує їх таким чином, що всі вони підтримують і підсилюють один одного.
На цьому фундаменті ХР будує еволюційний процес проєктування, оснований на реорганізації коду системи протягом кожної наступної ітерації. При цьому проєктується тільки та функціональність, яка належить до поточної ітерації, а будь-які майбутні потреби не враховуються. Одержаний в результаті процес вимагає від розробників дисципліни, і водночас поєднує її з високою адаптивністю. Таке дивне поєднання дозволяє припустити, що ХР є найбільш розвиненою адаптивної методології.
Open Source[ред. | ред. код]
У більшості проєктів з відкритим вихідним кодом є один або кілька координаторів. Координатор є лідером проєкту, єдиною людиною, яка може робити зміни безпосередньо в репозиторій вихідного коду. Однак, інші розробники теж можуть робити код зміни, з тієї лише різницею, що їм доведеться спочатку відіслати їх координатору, який прогляне виправлений код і вже потім робить зміни в репозиторій. Зазвичай такі зміни мають вигляд патч-файлів, що спрощує подібну процедуру. Таким чином, лідер проєкту координує патчі і стежить тим, щоб вони відповідали загальним планом розроблюваного ПЗ.
Ще однією особливістю розробки проєктів з відкритим вихідним кодом є те, що налагодження програми може вестися паралельно. Таким чином, до неї можна залучити велику кількість людей. Знайшовши в програмі помилку, вони можуть відіслати патч лідеру проєкту. Таким чином, не-координатори виконують дуже важливу функцію, тому що більша частина часу витрачається саме на пошук помилок. Крім того, ця робота підходить тим, у кого немає хороших навичок проєктування.
SCRUM[ред. | ред. код]
Методологія Scrum досить давно відома серед тих, хто займається об'єктно-орієнтованими розробками. Як і в інших гнучких методологіях, в ній робиться наголос на тому, що визначений і повторюваний процес годиться тільки для вирішення певних і повторюваних проблем у певному і повторюваному середовищі, в якому працюють і певні повторювані розробники.
Згідно з методом SCRUM, проєкт поділяється на ітерації (які називаються «спринт»), за 30 днів кожна. Перед початком спринту визначається функціональність, яка потрібна на цьому етапі, після чого починає роботу команда розробників. Важливо, щоб протягом одного спринту вимоги залишалися незмінними. Щодня команда розробників збирається на короткі (чверть години) збори, іменовані «scrum» («сутичка»), де побіжно проговорюється, чим займатиметься кожен з розробників протягом наступного дня. Крім того, на таких зборах керівникам компанії дають знати про проблеми в просуванні проєкту, які їм необхідно вирішити, а також повідомляють про виконану роботу, щоб вони ясно уявляли собі, в якій стадії знаходиться розробка.
В методології SCRUM основну увагу приділяють ітеративному плануванню і відстеження процесу. В цілому SCRUM дуже близький до інших гнучких методологій і повинен добре поєднуватися з правилами кодування ХР.
Вибір[ред. | ред. код]
Мови програмування можуть добре підтримувати ті чи інші методології, але це не означає, що деяку мову взагалі не можна використовувати з невластивою їй методологією, а тільки ту, у якій потрібно затратити більше зусиль і ресурсів.
Методології програмування розрізняються за загальним витратам на вирішення завдань з різними характеристиками (наукові розрахунки, фінансові завдання, системи реального часу тощо). Масштаб завдань і ефективність створюваного програмного забезпечення також є важливими факторами при виборі методології програмування.
Примітки[ред. | ред. код]
- Одінцов, 2004, с. 73
- Тузов В. А. Языки представления знаний. Л., ЛГУ, 1990
- Одинцов, 2004, с. 78
- Одинцов, 2004, с. 78-79
- Одинцов, 2004, с. 79
- Одинцов, 2004, с. 75
Див. також[ред. | ред. код]
Джерела[ред. | ред. код]
- Martin Fowler. The New Methodology (англ.) (Переклад (рос.))
- A spiral model of software development and enhancement (англ.)
| ||||||||||||||||||||||||||||