L' approche incrémentale utilise un nombre défini d'étapes et le développement va du début à la fin dans un chemin linéaire de progression.
Le développement incrémental se fait par étapes depuis la conception, la mise en œuvre, les tests / vérifications, la maintenance. Ceux-ci peuvent être décomposés davantage en sous-étapes, mais la plupart des modèles incrémentiels suivent ce même modèle. Le modèle Waterfall est une approche traditionnelle de développement incrémental.
L' approche itérative n'a pas de nombre défini d'étapes, mais le développement se fait par cycles.
Le développement itératif est moins concerné par le suivi de la progression des fonctionnalités individuelles. Au lieu de cela, l'accent est mis sur la création d'un prototype fonctionnel et l'ajout de fonctionnalités dans les cycles de développement où les étapes de développement incrémentiel sont effectuées pour chaque cycle. La modélisation agile est une approche itérative typique.
Le modèle incrémental a été initialement développé pour suivre le modèle de chaîne de montage traditionnel utilisé dans les usines. Malheureusement, la conception et le développement de logiciels ont peu en commun avec la fabrication de biens physiques. Le code est le modèle et non le produit fini du développement. De bons choix de conception sont souvent «découverts» au cours du processus de développement. Enfermer les développeurs dans un ensemble d'hypothèses sans le contexte approprié peut conduire à de mauvaises conceptions dans le meilleur des cas ou à un déraillement complet du développement dans le pire des cas.
L'approche itérative est en train de devenir une pratique courante car elle correspond mieux au chemin naturel de progression dans le développement de logiciels. Au lieu d'investir beaucoup de temps / d'efforts pour chasser la `` conception parfaite '' sur la base d'hypothèses, l'approche itérative consiste à créer quelque chose de `` assez bon '' pour commencer et à évoluer pour répondre aux besoins de l'utilisateur.
tl; dr - Si vous écriviez un essai sous le modèle incrémental, vous tenteriez de l'écrire parfaitement du début à la fin d'une phrase à la fois. Si vous l'écriviez dans le cadre du modèle itératif, vous rédigeriez un brouillon rapide et vous vous efforceriez de l'améliorer grâce à un ensemble de phases de révision.
Mise à jour:
J'ai modifié ma définition de «l'approche incrémentielle» pour l'adapter à un exemple plus pratique.
Si vous avez déjà eu à traiter avec la passation de marchés, l'approche incrémentale est la façon dont la plupart des contrats sont exécutés (en particulier pour les militaires). Malgré les nombreuses variations subtiles du «modèle en cascade» typique, la plupart / tous sont appliqués de la même manière dans la pratique.
Les étapes se déroulent comme suit:
- Attribution du contrat
- Revue de conception préliminaire
- Examen critique de la conception
- Gel des spécifications
- Développement
- Mise en service / intégration
- Vérification
- Test de fiabilité
Le PDR et le CDR sont l'endroit où la spécification est créée et révisée. Une fois la spécification terminée, elle doit être gelée pour éviter le fluage de la portée. L'intégration se produit si le logiciel est utilisé pour étendre un système préexistant. La vérification sert à vérifier que l'application correspond aux spécifications. La fiabilité est un test pour prouver que l'application sera fiable à long terme, cela peut être spécifié un peu comme un SLA (Service Level Agreement) où le système est nécessaire pour maintenir un certain pourcentage de disponibilité (ex 99% de disponibilité pendant 3 mois ).
Ce modèle fonctionne très bien pour les systèmes qui sont simples à spécifier sur papier mais difficiles à produire. Le logiciel est très difficile à spécifier sur papier avec un degré de détail appréciable (ex UML). La plupart des «types d'entreprises» en charge de la gestion / passation de marchés ne réalisent pas que - en ce qui concerne le développement de logiciels - le code lui - même est la spécification. Les spécifications de papier prennent souvent autant ou plus de temps / d'efforts pour écrire que le code lui-même et elles s'avèrent généralement incomplètes / inférieures dans la pratique.
Les approches incrémentales tentent de réduire le temps / les ressources perdues en traitant le code lui-même comme la spécification. Au lieu d'exécuter la spécification papier à travers plusieurs étapes de révision, le code lui-même passe par plusieurs cycles de révision.