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

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

Наприклад, переглядаючи такі методології:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Чи можемо ми сказати, що:
прототипування, ітератив, спіраль та водоспад - це «фундамент» для інших?

Або немає такого поняття, як "основи", і чи кожна методика має свою унікальну історію?

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

Імена у вашому списку не всі методики, і вони масштабуються на різних рівнях:

• Ітератив - це характеристика, риса, якою поділяють декілька методів і прийомів. Scrum - ітеративна методологія, TDD - ітеративна методика.
• Я розглядаю Agile як сукупність методології, яка залишається на концептуальному / філософському рівні. У об'єктно-орієнтованому програмуванні ви можете описати це як абстрактне - це набір значень та принципів, які неможливо створити і потрібно отримати та реалізувати. Ось що роблять Scrum і XP.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model є належними методологіями, тобто процесами розробки програмного забезпечення (хоча Scrum стверджує, що це легкий «каркас» на відміну від важкого процесу)
• Прототипування та TDD - це техніка, діяльність. TDD - це практика XP.

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

Ще один спосіб поглянути на це - з покоління. Щодо корпоративного програмного забезпечення, я б сказав, що ми знали 2 покоління методологій. Перші, серед яких водоспад та V-Model, здебільшого були попередньо існуючими процесами з інших інженерних дисциплін, застосованих до програмного забезпечення. Друге покоління (можна назвати Agile, але воно почалося задовго до того, як був введений термін Agile) було ініційовано як реакція на важкість процесів першого покоління, коли люди почали розуміти, що програмне забезпечення - зовсім інша тварина і що критерії, які роблять хорошими програмне забезпечення та кроки, що забезпечують ці критерії, справді були специфічними і їх ще потрібно було вивчити.

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

Є три:

1. жодна (кодування ковбоя)
2. водоспад
3. швидка розробка додатків (RAD або спіраль)

решта - це варіанти та комбінації цих

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

будь ласка, опублікуйте посилання на ваші результати, коли закінчите, це здається цікавим документом!

Можливо, ви хочете лише згадати античні методології (а не "методології"):

1. пакетна обробка: подайте колоду карт і отримайте вихід на наступний день. Недоліки: занадто багато часу між поданнями; для налагодження вивчіть основний дамп.

2. cli методи - використовуйте vi або emacs, потім компілюйте; все з командного рядка так само робиться в оболонці Linux навіть понині. Недоліки: важко налагодити (gdb? Ти мене жартуєш?), Незрозумілі команди оболонки 40 років.

Просто думка.

Можна згадати три основні підходи: прототипування, спіраль та водоспад. Я б не розглядав Lean, TDD або Cleanroom як методологію, а швидше процес, який може бути частиною методології.