Modèles de développement logiciel et méthodologies

Modèle évolutif

• Tenter d'obtenir des retours en primeur

• Utilisation de l'évolution : premier produit (prototype) puis évolution progressive.
• Que les changements sont attendus au fil du temps.
• Ne permet jamais de stabiliser complètement les besoins ; impact sur le cycle de vie des projets =

Inconvénients

• Manque de planification.
• Production de logiciels mal structurée.
• Difficulté à modifier le code si des livraisons ont été faites avant une analyse complète du système.
• Difficulté d'intégration avec d'autres applications.
• Peu utilisé pour les grands systèmes, risque d'être incapable de traiter les changements de contrôle.
• Il n'est pas conseillé de remplacer des systèmes bien définis sans précautions.

Modèle incrémental

• Comme dans le modèle évolutionnaire, le système est créé en ajoutant des composants fonctionnels (incréments).
• À chaque étape, on effectue des mises à jour du système.
• Intégration progressive du logiciel et des résultats.

Inconvénients

• Les solutions peuvent nécessiter des retests fréquents ; gestion des erreurs parfois non structurée.
• L'utilisateur peut être réticent si le développement ne montre pas clairement le résultat final attendu.

Modèle en spirale

• Introduit par Barry Boehm (1986) [Boehm, 1986 ; références complémentaires 1998].
• Conçu pour atténuer les problèmes rencontrés dans le cycle de vie logiciel.

Présentation classique :

• L'analyse des risques est au centre du modèle.
• Composé d'une série de cycles.
• La spirale est divisée en quatre quadrants.
• Le projet commence au centre de la spirale et progresse vers l'extérieur jusqu'à la fin.
• Déterminer les objectifs, planifier et produire.
• Étudier les alternatives et les contraintes.
• Analyse des risques et évaluation des alternatives par rapport aux objectifs et contraintes.
• Analyse de l'incertitude et prototypage.

Éléments de risque identifiés :

• Manque de personnel qualifié.
• Contraintes budgétaires ou de planification.
• Développement réaliste des fonctions : risque de produire un mauvais logiciel.
• Mauvaise définition des besoins des utilisateurs.
• Problèmes d'interface persistants.
• Problèmes liés aux composants achetés à l'étranger ou aux travaux externalisés.
• Restrictions réelles sur le plan technique.
• Dépassement des possibilités actuelles de l'ingénierie informatique pour le développement, les essais et la production.

Niveau suivant : révision et évaluation.

Avantages

• Permet de tirer le meilleur et d'éviter le pire des autres modèles selon la situation.
• Les options de réutilisation sont prises en compte dès le départ.
• Prépare au développement, à la croissance et au changement.
• Fournit un mécanisme pour intégrer les objectifs de qualité dans le développement.
• Permet d'identifier et d'éliminer tôt les erreurs et les options peu attrayantes.
• Permet de déterminer le niveau d'effort pour chaque phase de chaque projet.
• Suivi cohérent pour le développement et la maintenance, évitant les problèmes liés aux "améliorations de routine" à haut risque.
• Permet une grande flexibilité.

• Il s'adapte bien à la programmation orientée conception et orientée objet.

Inconvénients

• Développé initialement pour des contrats commerciaux ; moins évident pour le développement interne sans expérience évaluatrice des risques.
• Des experts en évaluation des risques ne sont pas toujours disponibles.
• L'approche demande des traitements et mesures supplémentaires.
• Modèle relativement nouveau ; son usage n'est pas aussi répandu que celui de la cascade ou du prototypage.

Le modèle reconnaît explicitement différentes alternatives pour atteindre les objectifs du projet et se concentre sur l'identification des risques de chaque alternative et sur les moyens de les résoudre. La division des projets en étapes, chacune avec une validation finale, signifie qu'il existe un cadre d'accord pour les modifications à apporter en fonction de ce qui a été appris au cours du projet. C'est une méthode qui s'adapte à tout type d'activité, notamment l'intervention de consultants externes.

Méthodologies

Il est nécessaire d'établir une approche systématique et disciplinée pour mener à bien le développement de logiciels. Les méthodologies de développement interviennent directement dans le processus de construction et sont développées à partir du cadre défini par un ou plusieurs cycles de vie. Il n'y a pas de consensus parmi les auteurs sur la définition exacte du concept de méthodologie.

Définition

Ensemble de mesures et procédures à suivre pour le développement de logiciels.

Quelle méthodologie ?

• Meilleure application du processus de développement.
• Meilleure standardisation.
• Respect d'une norme organisationnelle.

Objectifs des méthodologies

• Établir les exigences d'un système logiciel clairement.
• Livrer un système logiciel avec succès dans un délai approprié et à un coût acceptable.
• Construire un système bien documenté et facile à entretenir.
• Aider à identifier, le plus tôt possible, tout changement nécessaire dans le processus de développement.
• Fournir un système qui saura satisfaire les utilisateurs finaux.

Caractéristiques souhaitables

Caractéristiques souhaitables dans une méthodologie :

• Existence de règles prédéfinies.
• Couverture complète du cycle de vie, y compris les étapes intermédiaires.
• Mécanismes de contrôle, planification et suivi.
• Communication efficace entre parties prenantes.
• Utilisation d'une vaste gamme d'outils et de formations adaptés aux projets.
• Simplicité d'utilisation.
• Cas d'activités pour améliorer le processus de développement.
• Support pour la maintenance et la réutilisation des logiciels.

Méthode vs Méthodologie

Il existe souvent une confusion entre les termes "méthode", "méthodologie" et "cycle de vie". Une méthode est une façon concrète de procéder et peut s'appuyer sur un ou plusieurs modèles de cycle de vie ; le cycle de vie indique quoi livrer et quand, mais pas toujours comment. La méthodologie est une notion plus large que la méthode : une méthodologie peut regrouper plusieurs méthodes et fournir un cadre global pour le projet.

Classification

• Structuré.
• Orientée processus.
• Orientée données.
• Structures de données hiérarchiques.
• Mixte.
• Orientée objet.