Методологія розробки програмного забезпечення

При зверненні до методології,  яка має ядро (англ. core), відповідне способу опису алгоритму, та додаткові особливості, можна виділити такі п'ять основних ядер методологій:

• Методологія імперативного програмування
• Методологія ООП
• Методологія функціонального програмування
• Методологія логічного програмування
• Методологія програмування в обмеженнях

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

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

У відповідності до архітектури апаратного забезпечення, реалізація може бути централізованою або паралельною. Наприклад, методологія (імперативного) паралельного програмування, методологія логічного паралельного програмування.

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

Проводяться дослідження щодо уніфікації методологій програмування.

З усіх гнучких методологій методологія екстремального програмування (XP) — найбільше відома. Частково це сталося тому, що лідери ХР, особливо Кент Бек (Kent Beck) наділені чудовою здатністю привертати до себе увагу. Важливу роль зіграв і талант Кента вербувати прихильників свого руху і вести їх за собою. Можна навіть сказати, що популярність ХР стала в деякому роді проблемою, так як ця методологія практично витіснила всі інші, а разом з ними і ті цінні ідеї, які вони несуть.

XP стоїть на чотирьох китах: Комунікація, Зворотній зв'язок, Простота і Сміливість. Із них слідують дванадцять практик, яким повинні слідувати проєкти, що використовують ХР. Багато з цих практик являють собою старі перевірені техніки, які, тим не менш, багато встигли забути (включаючи більшість передбачуваних процесів). ХР не тільки воскрешає до життя такі техніки, але і з'єднує їх таким чином, що всі вони підтримують і підсилюють один одного.

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

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

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

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

Згідно з методом SCRUM, проєкт ділиться на ітерації (які називаються «спринт»), за 30 днів кожна. Перед початком спринту визначається функціональність, яка потрібна на даному етапі, після чого починає роботу команда розробників. Важливо, щоб протягом одного спринту вимоги залишалися незмінними. Щодня команда розробників збирається на короткі (чверть години) збори, іменовані «scrum» («сутичка»), де побіжно проговорюється, чим буде займатися кожен з розробників протягом наступного дня. Крім того, на таких зборах керівникам компанії дають знати про проблеми в просуванні проєкту, які їм необхідно вирішити, а також повідомляють про виконану роботу, щоб вони ясно уявляли собі, в якій стадії знаходиться розробка.

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