Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Cycle de vie S. Chollet D’après le cours de P. Lalanda Problématique Comment s

Cycle de vie S. Chollet D’après le cours de P. Lalanda Problématique Comment s’enchaînent les différentes activités ? Plus ou moins bien car : On ne dispose pas de toutes les informations au bon moment Les besoins et les contraintes évoluent Les décisions à prendre sont parfois trop complexes (stratégie « do and see ») Les bonnes personnes ne sont pas toujours disponibles Utilisation d’un cycle de vie S. Chollet 2 Processus logiciel – 1/2 Un processus logiciel est un ensemble d’étapes Une étape comprend un ensemble d’activités, de ressources, de contraintes et de procédures à réaliser Les étapes sont les mêmes pour la plupart des processus Un processus logiciel définit comment les étapes sont liées les unes aux autres Certaines étapes sont génériques ou spécifiques à des organisations S. Chollet 3 Processus logiciel – 2/2 Les processus logiciel sont des processus intellectuels et créatifs Dépendant des personnes Les tentatives visant à automatiser les processus ont eu un succès limité Il existe un grande diversité de processus logiciel : Pas de processus logiciel idéal Doit être conforme aux personnes disponibles, au domaine applicatif… Les systèmes critiques requièrent des processus très structurés, d’autres systèmes supportent des processus plus flexibles S. Chollet 4 Les modèles de processus logiciels Un modèle de processus logiciel est une représentation abstraite d’un processus logiciel Les principaux modèles de processus : Modèle en cascade (waterfall) Développement évolutif Les approches agiles S. Chollet 5 Modèles en cascade • En cascade de 1970 • En cascade avec itérations • Processus en V Modèle en cascade – Définition Succession d’étapes, strictement séquentielles : Chaque étape est une activité de base Chaque étape est validée Il n’y a pas (ou peu) de retours en arrière S. Chollet 7 Modèle en cascade – Fonctionnement On code d’abord, après on modifie Développement effréné Peu d’analyse, beaucoup de code Votre dernier TP ? Modèle primitif (avant 1970) Pas adapté à des développements de grande taille avec plusieurs équipes Construction de la V0 Modifications Requirements 2% Specification 5% Design 6% Module coding 5% Module testing 7% Integration 8% Maintenance 67% Relative costs of phases S. Chollet 8 Modèle en cascade de 1970 Grand nombre d’activités Orienté documents Pas de retour en arrière Ingénierie classique Analyse des besoins Analyse du système Conception du système Programmation et tests unitaires Intégration et tests d’intégration Installation Exploitation et maintenance Etude préliminaire S. Chollet 9 Modèle en cascade avec des itérations Possibilité de retours en arrière Plus flexible Plus difficile à gérer Nombre limité d’itérations Analyse des besoins Analyse du système Conception du système Programmation et tests unitaires S. Chollet 10 Processus en V Les tests sont définis à chaque phase Analyse des besoins Analyse du système Conception architecturale Conception détaillée Codage Orientation, faisabilité Tests d’acceptation Tests d’intégration Tests unitaires Maintenance Chronologie Cahier des charges Spécifications architecturales Spécifications détaillées Préparation de la … validation vérification vérification module logiciel système abstraction S. Chollet 11 Avantages des modèles en cascade Simples et faciles à comprendre Imposent de la documentation Une étape n’est pas terminée tant que la documentation n’est pas validée La préparation des tests est incluse à chaque étape (cycle en V) Les avancées sont tangibles : Pour l’équipe de développement Pour les managers, aussi ! S. Chollet 12 Limites des modèles en cascade Dirigés par les documents Sans signification pour les clients et les utilisateurs Le produit final est le premier artefact vu par les utilisateurs Font l’hypothèse que le projet est faisable, réalisable Problème qui peut être résolu De nombreux problèmes sont découverts à la fin Pas flexibles Requièrent de la stabilité, pas d’évolutions possibles Pas réalistes dans la majorité des cas S. Chollet 13 Synthèse sur les modèles en cascade Facilement applicables Besoins connus à l’avance et stables Technologies solides Très populaires Simples et similaires à d’autres domaines d’ingénierie Souvent utilisés par des non spécialistes ou des ingénieurs logiciels inexpérimentés S. Chollet 14 Modèles de développements évolutifs • 2 modèles incrémentaux Constat : des changements ! Les changements sont inévitables Les environnements techniques et commerciaux changent Les besoins des clients changent Les priorités de gestion changent On ne peut pas compter sur la stabilité pour commencer Tyrannie du « Time-to-market » Illusion de la perfection Les modèles en cascade sont inefficaces ! S. Chollet 16 Modèles incrémentaux – Définition Idée : diviser le projet en incréments : Un incrément est une sous-partie fonctionnelle du produit final Chaque incrément ajoute de nouvelles fonctionnalités Chaque incrément est testé Les incréments sont différents a priori – priorisation des besoins (par le client si possible) Définition des incréments Conception de l’architecture globale Développement d’un incrément Intégration et validation de l’incrément Produit final S. Chollet 17 1er modèle incrémental – architecture évolutive Architecture évolutive Le premier incrément constitue le noyau Les incréments suivants sont construits sur ce noyau Chaque incrément suit un cycle de vie complet Noyau Noyau Noyau Cycle de vie complet Cycle de vie complet Version 1 Version 2 Version 3 S. Chollet 18 2ème modèle incrémental – architecture stable Architecture stable La première version fournit une enveloppe complète Chaque nouvelle version fournit un ou plusieurs sous-système(s) en respectant l’architecture Le développement en parallèle est possible Cycle de vie complet Cycle de vie complet Version 1 Version 2 Version 3 S. Chollet 19 Avantages des modèles incrémentaux Un premier incrément est vite délivré Retour sur investissement rapide Réduit le stress des managers ! Risques d’échec sont diminués Détection assez tôt des problèmes Les parties importantes sont fournies en premier et seront donc testées plus longuement Les clients peuvent ajouter des besoins S. Chollet 20 Limites des modèles incrémentaux Les incréments : Difficiles à définir (la définition des besoins ne correspond pas à la définition des incréments) Trop d’incréments : difficile à gérer Peu d’incréments : revient à un processus en cascade Architecture : Difficile de définir une architecture stable au début Difficile d’identifier les services communs Ne peut pas supporter toutes les évolutions possibles ! Surtout celles qui remettent en cause l’architecture S. Chollet 21 Méthodes agiles Constat : manque de souplesse Approche contrôlée du développement Planning précis Assurance qualité (au moins pour le management) Méthode d’analyse et de conception Utilisation d’outils Forte applicabilité Gros projet (plusieurs équipes, sites, entreprises) Projet long (développement et maintenance) En suivant ces cycles de vie, on peut passer plus de temps sur la façon de développer un système que sur le développement lui-même ! S. Chollet 23 Méthodes agiles – Définition Caractéristiques : Ciblées sur le développement Ciblées sur les personnes Itératives Fournit rapidement un logiciel que les clients peuvent amender Dédiées pour des domaines avec « une évolution rapide » Extreme Programming (Beck) Crystal (Cockburn) Adaptive Software Development (Highsmith) Feature Driven Development (Palmer) … S. Chollet 24 Principes généraux Utilisateur • Implication dans le développement • Fourniture des exigences et priorisation • Evaluation des itérations Incréments • Fourniture incrémentale du logiciel People • Reconnaissance du talent des développeurs • Pas de processus imposé Changements • Conception orientée évolution Simplicité • Chasser toute forme de complexité Tests • Jouent le rôle de spécifications Binômes • Les développeurs travaillent par binôme S. Chollet 25 eXtreme Programming (XP) Approche basée sur des itérations fréquentes : Sélection de scénarios à réaliser (sous forme de cartes) Définition et répartition des tâches Planification du développement et des tests Fourniture d’un logiciel exécutable et évaluation Sélection des scénarios Création des tâches Planification de l’incrément Développement intégration/test Fourniture de l’incrément Evaluation du système S. Chollet 26 Principes de l’eXtreme Programming Réalisation d’un incrément (scénario) : Réunion debout tous les matins (tous) Programmation à deux dans une « war room » La « war room » se trouve de préférence chez le client Les programmeurs définissent et exécutent les tests Conception minimale Constante adaptation du code pour simplifier Intégration continue Cadence intense 1 à 2 semaines S. Chollet 27 Gestion des scénarios sous forme de cartes Scénarios codés Scénarios non planifiés Scénarios planifiés Liste des bugs Scénarios détaillés S. Chollet 28 Méthodes agiles : programmation en binôme « egoless programming » : le code est à tout le monde Rotation des binômes et diffusion de la connaissance dans le projet Revue constante du code Efficace et moins coûteuse que les inspections formelles Favorise la re-factorisation du code Vers la simplicité Aussi productif que deux programmeurs indépendants S. Chollet 29 Méthodes agiles : priorité aux tests/vérifications Beaucoup de tests mais les approches itératives traitent souvent mal le test Pas de spécifications sur lesquelles se baser Gestion des tests dans l’eXtreme Programming : Définition des tests en premier Chaque tâche donne lieu à des tests Définis avant l’implantation avec le client Ecriture de tests qui seront exécutés automatiquement Codés avant l’applicatif S. Chollet 30 Nouveaux outils liés aux méthodes agiles L’intégration continue est un ensemble de pratiques qui consistent à vérifier qu’à chaque modification du code source, les résultats des modifications ne produisent pas de régression de l’application en cours de développement S. Chollet 31 Gestionnaire de versions Limites des méthodes agiles Aucune documentation n’est disponible pour la maintenance Ces méthodes sont parfois difficiles à uploads/Industriel/ cm7-cycledevie.pdf