Quelles méthodologies de développement logiciel peuvent être considérées comme des fondations

J'écris un petit document de recherche qui concerne la méthodologie de développement de logiciels. Je regardais toutes les méthodologies disponibles et je me demandais, parmi toutes les méthodologies, y en a-t-il qui ont jeté les bases des autres?

Par exemple, en examinant les méthodologies suivantes:
Agile, Prototypage, Salle blanche, Itératif, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Peut-on dire que: le
prototypage, l'itératif, la spirale et la cascade sont le «fondement» des autres?

Ou n'existe-t-il pas de «fondations» et chaque méthodologie a-t-elle sa propre histoire?

Je voudrais bien sûr décrire toutes les méthodologies dans mon document de recherche, mais je n'ai tout simplement pas le temps de le faire et c'est pourquoi je voudrais savoir quelles méthodologies peuvent être considérées comme représentatives.

Les noms dans votre liste ne sont pas toutes des méthodologies et ils évoluent à différents niveaux:

• L'itératif est une caractéristique, un trait commun à plusieurs méthodes et techniques. Scrum est une méthodologie itérative, TDD est une technique itérative.
• Je vois Agile comme un sur-ensemble de méthodologie qui reste à un niveau conceptuel / philosophique. Dans la programmation orientée objet, vous pouvez la décrire comme abstraite - c'est un ensemble de valeurs et de principes qui ne peuvent pas être instanciés et doivent être dérivés et mis en œuvre. C'est ce que font Scrum et XP.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model sont des méthodologies appropriées, c'est-à-dire des processus de développement de logiciels (bien que Scrum prétend être un "framework" léger par opposition à un processus lourd)
• Le prototypage et le TDD sont des techniques, des activités. TDD est une pratique XP.

Distinguer qui est le fondement de laquelle est un travail difficile. Vous pouvez évidemment tracer une ligne historique, mais une méthodologie est rarement directement basée sur une autre. Ils se chevauchent plutôt, s'empruntent, se répondent parfois ... Je ne vois pas de classification clairement définie, bien que vous puissiez probablement décrire quelques grandes familles.

Une autre façon de voir les choses est dans une perspective de génération. En termes de logiciels d'entreprise, je dirais que nous avons connu 2 générations de méthodologies. Les premiers, parmi lesquels Waterfall et V-Model, étaient pour la plupart des processus préexistants d'autres disciplines d'ingénierie appliquées aux logiciels. La deuxième génération (vous pouvez l'appeler Agile mais elle a commencé bien avant que le terme Agile ait été inventé) a été lancée en réaction à la lourdeur des processus de première génération, lorsque les gens ont commencé à se rendre compte que le logiciel était un animal totalement différent et que les critères qui font le bien Les logiciels et les étapes permettant de garantir ces critères étaient vraiment spécifiques et devaient encore être explorés.

Enfin, vous devez noter que, dans le logiciel, peut-être même plus que dans d'autres disciplines, les méthodologies ne sont pas des recettes que vous pouvez simplement appliquer pour faire fonctionner les choses. Le développement de logiciels comporte autant d'aspects humains que d'aspects techniques et une équipe ou un gestionnaire proposant une méthodologie miracle et une liste de points à appliquer aveuglément peuvent s'attendre à quelques surprises. En regardant les études sur les taux de réussite des projets logiciels comme le rapport Chaos année après année, vous pouvez voir que l'histoire des méthodologies logicielles a plus à voir avec une série de tentatives infructueuses qu'avec la règle des processus solides, scientifiquement établis et reproductibles.

Il ya trois:

1. aucun (alias codage cowboy)
2. cascade
3. développement rapide d'applications (RAD ou spirale)

les autres sont des variantes et des combinaisons de ceux-ci

Notez que les artefacts de la cascade (création, exigences, spécifications fonctionnelles, spécifications de conception, spécifications de test, spécifications de contrôle de qualité, etc.) couvrent tous des éléments importants pour le projet, la plupart sinon tous couverts par d'autres méthodologies, mais dans des façons très différentes. Par exemple, dans TDD, les fonctionnalités, les user stories et les descriptions de test couvrent les exigences, les spécifications fonctionnelles et les spécifications de test de la cascade. Dans RUP, encore plus d'artefacts sont ajoutés qui rompent une partie des spécifications de la cascade (le document des parties prenantes, par exemple, est une partie du document de démarrage), mais procède de manière en spirale

veuillez publier un lien vers vos résultats une fois terminé, cela ressemble à un article intéressant!

Peut-être voulez-vous simplement mentionner des méthodologies anciennes (pas des «méthodologies») comme:

1. traitement par lots: soumettez un jeu de cartes et récupérez la sortie le lendemain. Inconvénients: trop de temps entre les soumissions; pour le débogage, étudiez un vidage de mémoire.

2. méthodes cli - utilisez vi ou emacs, puis compilez; tout à partir de la ligne de commande, tout comme cela se fait dans un shell Linux même à ce jour. Inconvénients: difficile à déboguer (gdb? Vous plaisantez?), Obscures commandes shell de 40 ans.

Juste une pensée.

Vous pouvez mentionner trois approches de base: le prototypage, la spirale et la cascade. Je ne considérerais pas Lean, TDD ou Cleanroom comme une méthodologie, mais plutôt un processus qui peut faire partie de la méthodologie.