Quelle est la différence entre l'approche incrémentielle et itérative du développement logiciel?
approche incrémentale est une méthode de développement logiciel où le modèle est conçu, implémenté et testé de manière incrémentielle (un peu plus est ajouté à chaque fois) jusqu'à ce que le produit soit terminé. Cela implique à la fois le développement et la maintenance. Le produit est défini comme fini lorsqu'il répond à toutes ses exigences
Iterative Design est une méthodologie de conception basée sur un processus cyclique de prototypage, de test, d'analyse et de raffinement d'un produit ou d'un processus. Sur la base des résultats des tests de l'itération la plus récente d'une conception, des modifications et des améliorations sont apportées. Ce processus est destiné à améliorer à terme la qualité et la fonctionnalité d'un design. Dans la conception itérative, l'interaction avec le système conçu est utilisée comme une forme de recherche pour informer et faire évoluer un projet, lorsque des versions successives ou des itérations d'une conception sont mises en œuvre.
Il semble que les deux méthodes consistent à créer une partie du système, à l'affiner pour passer tous les cas de test, à ajouter un autre composant du système et à le raffiner à nouveau, cela se répète jusqu'à ce que le système soit terminé.
Quelle est la différence réelle entre ces deux façons de concevoir un logiciel
Comment est-il possible de combiner ces deux méthodes pour former approche de conception itérative et incrémentale
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. Waterfall Model est une approche traditionnelle de développement incrémental.
L'approche itérative n'a pas de nombre d'étapes défini, 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. Modélisation Agile est une approche itérative typique.
Le modèle incrémental a été initialement développé pour suivre le modèle traditionnel de ligne d'assemblage 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 devrait ê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.
Comme pour tout adjectif, et la plupart des choses dans le développement de logiciels ... cela dépend!
Cela dépend du contexte et de la façon dont le terme est utilisé. Vous vous demandez donc la différence entre les approches incrémentielles et itératives du développement logiciel, mais votre citation porte sur la conception itérative, ce qui est différent (bien que similaire).
Donc répondre spécifiquement comme une approche du développement logiciel.
La question est déplacée. Ce n'est ni l'un ni l'autre. Vous ne pouvez pas les comparer directement car ils font référence à différentes parties du processus.
Le développement logiciel itératif est par nature incrémental. Le développement incrémentiel de logiciels ne doit pas être itératif.
Un incrément est un petit pas, espérons-le. C’est une manière de se référer à chaque étape du travail qui est réalisé.
Une itération est un cycle de travail.
Ainsi, une itération fait référence au cycle de développement global utilisé. Un incrément fait référence à chaque étape individuelle du travail. Une itération produira un incrément, qui est composé d'un ou plusieurs incréments réels pour le logiciel (généralement plus).
En conclusion ...
Le développement logiciel itératif est un type spécifique d'approche du développement logiciel, fonctionnant par itérations par opposition à une approche traditionnelle en cascade. Scrum est un bon exemple.
Le développement incrémentiel de logiciels est plus général et fait référence à l'avancement du travail par étapes, ce qui est une caractéristique de la plupart (peut-être toutes?) Des approches. Cela dit, le terme est plus souvent utilisé en relation avec des approches modernes et agiles, ce qui explique probablement la confusion entre les deux termes très similaires.
Et enfin, bien sûr, cela dépend de la signification du terme lorsqu'il est utilisé, qui varie souvent considérablement selon le locuteur, la période du mois, etc.!
Une question plus intéressante est: où se situe une approche empirique du développement logiciel dans tout cela. La beauté d'une approche itérative est qu'elle permet l'empirisme, c'est là que la magie opère.
J'espère que cela t'aides.
Cet article le décrit bien, avec des exemples.