IGL - Chapitre 1 - Méthodologies de Développement - Partie 2 PDF

– Résumé – Chapitre 1 : Méthodologies de développement – Partie 2 – Module – IGL – S1 – 1CS Made by : Batta aka. AGAL Imene  Activités de développement Etapes de développement Le développement d’un logiciel passe généraleme...

– Résumé – Chapitre 1 : Méthodologies de développement – Partie 2 – Module – IGL – S1 – 1CS Made by : Batta aka. AGAL Imene  Activités de développement Etapes de développement Le développement d’un logiciel passe généralement par 3 étapes essentielles : Principales activités de développement  Un projet de développement est composé de plusieurs activités, dont chacune est réalisée par certains acteurs et possède des entrées et des sorties (livrables). Les activités principales de développement sont : 1) Conception 2) Analyse de besoins  Choix des solutions techniques pour répondre aux attentes client.  Collecter les attentes du client (entretiens, cahier de charge, rapports,  Etablissement d’un planning de réalisation. présentations).  Elaboration de l’architecture de la solution (à base de service, client-  Comprendre le métier (spécialité) et l’environnement du client.  Formaliser les besoins du client. serveur, application mobile, site web, …) et des prototypes.  Contractualisation (réaliser un contrat définitif). Difficultés : dépendance forte envers les résultats de l’analyse – Difficultés : le client parle un autre langage – oublis, incompréhensions, difficulté de choisir la meilleure solution – nécessité d’une compétence complexités, … – difficultés d’estimation du coût et du délai du projet – technique accrue – évolution rapide de la technologie. changement de besoins en cours du projet.  3) Codage 4) Tests  Transformation des solutions proposées en un code opérationnel en se  Détermination de la qualité du logiciel et sa conformité par rapport basent sur les langages de programmation. aux spécifications.  Consomme beaucoup de ressources et la plus grande équipe, et  Plusieurs types de tests : unitaires ou fonctionnels, en boite noire représente la plus grande part du travail. (sans code) ou en boite blanche (avec code), sans/avec succès du  Utilisation d’un référentiel unique du code source par les développeurs code source, … (emplacement -GitHub-, modèles, …). Difficultés : activité lassante et coûteuse (temps & argent) – Difficultés : gestion de projets pour des équipes nombreuses – intégration difficilement automatisables (dépend des humains) – nécessite la du code – uniformisation de la compréhension du projet, des méthodes de concentration. travail et du code – mobilité des développeur – différences de niveau technique entre développeurs. Outils et Métiers Principaux métiers de développement Activités Métier Expression de Implémentation Livrables Analyse Conception Tests besoins (Codage) Développeur Code source Analyste Documents, modèles Architecture (conception générale), Architecte diagramme de classes (conception détaillée) Testeur Plans de test Chef de projet (CDP) Plannings  Outils ComputerAidedSoftwareEngineering  Les outils (logiciels) utilisés dans les activités de GL (compilateurs, éditeurs, débogueurs, …) sont nommés CASE et leur but est d’automatiser les taches et/ou gérer les projets de développement.  Ces outils peuvent être classés : - D’un point de vue fonctionnel (selon leur fonction). - D’un point de vue activité (selon les activités dans lesquelles ils sont utilisés). Classification fonctionnelle Outil Exemples Références Métiers (Fonctions générales) (Fonctions spécifiques) (Exemples d’outils) (Qui utilise ces outils ?) Outils PERT, outils d’estimation (délai & Microsoft Project, Excel, GanttProject, Outils de planification coût), tableurs DotProject CDP Editeurs de texte, éditeurs d’image, Editeurs éditeurs de diagrammes vi, bloc notes, GIMP, Photoshop, Visio Tous Gestion de Gestion de versions,gestion de builds SVN, CVS, Team Foundation Server, CDP, Développeur, Architecte configuration ClearCase Outils de support Générateurs de code, outils d’assistance, Team Foundation Server, Accurev, Tous de procédé ★ IDE Enterprise Architect Outils de traitement GCC, Clang, Javac, LLDB, WinDbg Compilateurs, interpréteurs, débogueurs Développeur, Architecte de langage Environnements de tests, outils de tests Junit, Nunit, TestWorks, Bugzilla Outils de test unitaires ★★ + Selenium (automatise les tests) Testeur, Développeur Outils de Word, Open Office, Sandcastle, Doxygen, Développeur Documents de projet, documents de code javadoc documentation Remarques : ★ Les outils de support de procédé couvrent le développement du début jusqu’à la fin, permettant d’assister le suivi des différentes activités. ★★ Les tests unitaires sont effectués par le codeur pour tester les fonctions et procédures qu’il développe.  Méthodologies de Développement Qu’est-ce qu’une méthodologie ? Motivation – pourquoi les méthodes ?  Une méthodologie de développement (procédé logiciel, software process, cycle ☺ Maitriser les gros projets. de vie d’un logiciel « SDLC ») est un ensemble d’activités conduisant à la production d’un logiciel. ☺ Découper le projet et affecter les taches  Elle définit les étapes d’un projet de développement, leur enchainement et correctement. comment les différentes activités sont affectées aux développeurs. ☺ Réduire la complexité.  Les méthodes sont complexes et dépendent sur les acteurs dirigeant les activités – qui ne peuvent pas être automatisées – (on peut utiliser les outils CASE pour ☺ Anticiper et gérer les risques. nous aider, mais on a toujours besoin des humains). Générations Typologie  D’un point de vue historique, il y a 2 classes de méthodes :  D’un point de vue typologique, les méthodes respectent trois modèles : 1) Séquentiel 2) Incrémental 3) Itératif  Remarques  Modèle séquentiel : la progression du développement s’effectue à travers des étapes séquentielles.  Modèle incrémental : divise le développement en plusieurs petites parties fonctionnelles, appelées incréments, qui sont développées et livrées au client de manière indépendante (exemple : pour développer une application de gestion des RH à l'ESI, le projet pourrait être divisé en 3 incréments : le 1er pour la gestion des étudiants, le 2nd pour celle des enseignants, et un 3ème pour la gestion administrative).  Modèle itératif : consiste à construire un produit progressivement, en itérant à travers un cycle de développement court et répété. A chaque itération, une petite partie du produit est construite, testée et validée avant de passer à la suivante. Comment choisir une méthode ? Quand utiliser X ? Les critères de choix d’une méthodologie pour le développement d’un logiciel sont : I can’t fill this space with useful info, se here’s a fun fact about GL : The first bug in the history of software engineering was an actual bug ! In 1947, computer pioneer Grace Hopper found a moth trapped in a relay of the Harvard Mark II computer. This "bug" caused a malfunction, giving rise to the term "debugging."  Méthodologies de Développement Classiques Définition Avantages Inconvénients Quand l’utiliser ? – Un modèle séquentiel qui  Les besoins sont rarement est l’un des premiers  Facile à utiliser. stables et clairs. modèles de développement  Besoins connus et stables.  Procédé structuré pour une  Sensibilité aux besoins Modèle proposés. (nécessité de refaire tout le  La technologie utilisée est équipe inexpérimentée. en maitrisée par l’équipe.  Idéal pour la gestion et le procédé). cascade – Chaque phase produit un  Création d’une nouvelle suivi de projets.  Une phase ne peut démarrer ensemble de livrables, et ne version d’un produit (modèle  Fonctionne bien quand la que si la précédente est finie. peut commencer que si la existant, ou portage / linéaire) phase précédente est finie. qualité est plus importante  Le produit n’est visible qu’à la réadaptation d’un produit que les coûts et les délais fin. sur une autre plateforme. – Modèle académique (utilisé (projets gouvernementaux).  Faible implication du client. pour l’apprentissage du GL).  Risques décalés vers la fin.  Ne gère pas les activités – Une variante du modèle en parallèles (une activité ne peut cascade (aussi séquentiel)  Facile à utiliser et à planifier commencer que si la  Très hautes exigences de qui fait l’accent sur la dans une gestion de projets. Modèle précédente est finie). qualité. vérification et la validation.  Chaque livrable doit être  Adaptabilité difficile : le modèle  Besoins connus à l’avance. en V testable. ne gère pas les changements  Technologies à utiliser – La tâche de test du produit  Accroit la qualité du logiciel des spécifications. connues à l’avance se fait en parallèle aux (grâce aux tests). autres activités.  Ne contient pas d’activités d’analyse de risques. Implémentation (besoins client) Spécifications Maintenance Déploiement Conception Tests En cascade En V  Définition Avantages Inconvénients Quand l’utiliser ? – Le projet se déroule en plusieurs  Implication active du client.  Implique un code itérations (modèle itératif) : lors  S’adapte rapidement aux faiblement structuré (à ⚠ Déconseillé en situations de chaque itération, un changements de besoins. cause des nombreux professionnelles. prototype du logiciel est construit  Progrès constant et visible changements).  Très petits projets. en se basent sur les attentes du de développement.  Maintenabilité très faible.  Exigence des livraisons Prototypage client qui fournit un feedback.  Grande interaction avec le  Le processus peut ne rapides. produit dès le départ, ce jamais s’arrêter !  Besoins instables et/ou – Le prototype est adapté chaque qui favorise l’adoption du  Difficulté d’établir un nécessitant des clarifications fois selon les feedbacks et les produit par le client. planning et de faire une (on peut l’utiliser avec le nouvelles exigences client, modèle en cascade pour la jusqu’à la validation d’un  Le développeur apprend évaluation (estimation) des coûts & délais. clarification des besoins). prototype par le client. du client directement. – Modèle incrémental qui trie les besoins par priorité et les  Développement des regroupent dans des « groupes fonctionnalités à risques en  Exige une bonne  Projets de longues durées. de spécifications ». premier (grâce au trie des planification et une bonne  Projets impliquant de – Chaque incrément produit une besoins par priorité). conception. nouvelles technologies. Modèle partie indépendante  Chaque incrément donne  Exige une vision claire  Le client veut rapidement un fonctionnelle du logiciel, en un produit fonctionnel. sur le produit fini pour incrémental produit fonctionnel. implémentant un ou plusieurs  Le client intervient à la fin pouvoir le diviser en de chaque incrément (il se incréments.  La plupart des groupes de spécifications, familiarise avec le produit  Le coût total du système spécifications sont connues jusqu’à la finition du produit (chaque partie est livrée dès que dès le départ). peut être cher à l’avance & peu évolutifs. son incrément est terminé et peut  « Diviser pour régner ». être utilisée par le client). Modèle incrémental Prototypage Spécifications Conception Implémentation Tests Incrément 1 Spécifications Conception Implémentation Tests Incrément 2 Spécifications Conception Implémentation Tests Incrément N  Modèle en spirale Définition – On effectue des itérations (modèle itératif) sous forme de cycles ou chaque cycle est composé de 4 phases, et inclue les mêmes activités que du modèle en cascade (spécifications, conception, implémentation, tests, déploiement, maintenance). – A la fin de chaque cycle, on détermine les objectifs du cycle suivant (basé sur le feedback client). – Le modèle inclut l’analyse de risques (la partie la plus importante) et le prototypage. Détermination des Identification et évaluation objectifs de risques En terme de fonctionnalité, Etudier les alternatives de dév. performance, coût,... (réutiliser, acheter,...) En prenant les contraintes de Identification et évaluation des développement en risques (ompétences, planning, considération technologies,...) Développement et test Planification de la Contient la plupart des prochaine itération activités de développement Planning de l'itération (conception, codage, test,...) Planning des tests ainsi que le prototypage. Modèle en spirale Une itération du modèle  Avantages et Inconvénients (➕) (➖)  Identification des risques et feedback du client rapides.  L’évaluation des risques prend beaucoup de temps.  Fonctions critiques développées en premier (grâce à la phase de  Modèle très complexe. détermination des objectifs).  La spirale peut s’éterniser ∞ (keeps spiraling forever).  Impacts minimaux des risques sur le projet.  Les développeurs doivent être réaffectés pendant les phases de non-développement.  Evaluation continue par le client.  Objectifs difficiles à formuler. Quand l’utiliser ?  Prototypage exigé par le client.  Spécifications instables.  Risque de développement considérable.  Développement de nouveaux produits.  Le projet implique de la recherche & de l’investigation. Méthodologies de Développement Agiles Remarque Spécifications Conception Implémentation Tests Itération 1 Incrément 1 Les modèles de développement agiles sont tous des modèles incrémentales et itératifs en même temps, c-à-d : Spécifications Conception Implémentation Tests Itération 2 ils font, lors de chaque incrément, des itérations pour produire des prototypes d’une certaine partie du logiciel et Spécifications Conception Implémentation Tests Itération N évaluer ce qui est développé. … Une fois un prototype de cette partie est validé, cette dernière est livrée au client, l’incrément est terminé et un Spécifications Conception Implémentation Tests Itération 1 Incrément N nouvel incrément peut commencer pour construire une autre Spécifications Conception Implémentation Tests Itération 2 partie. Ce processus se répète (incrémentation) jusqu’à ce que la totalité du logiciel soit développée. Spécifications Conception Implémentation Tests Itération N  Principes Agiles (Les priorités par rapport aux méthodes classiques) Principales Agiles  Les méthodes agiles sont basées sur 4 principes : 1) Individus et interactions au lieu de processus et outils  La priorité est aux individus et aux interactions entre eux, au lieu de se focaliser sur le respect d’un processus et sur l’utilisation des outils coûteux sans améliorer la qualité de développement.  Construire l’équipe et avoir de bonnes collaborations est plus important que construire l’environnement de développement. 2) Logiciel fonctionnel au lieu de documentation massive  Un code sans documentation est un désastre ; on ne peut certainement pas la négliger. Mais, trop de documents est pire que pas de documents ! Il faut toujours produire le minimum de documents, qui doivent être eux-mêmes aussi courts que possible. 3) Collaboration du client au lieu de négociation de contrats  Au lieu de négocier les spécifications, le coût et les délais avec le client dès le départ, il faut l’impliquer d’une manière directe, fréquente et régulière avec l’équipe de développement, et discuter les objectifs et les coûts au fur et à mesure avec lui. 4) Réagir aux changements au lieu de suivre le plan  Les CDP classiques fonctionnent sur la base de diagrammes (Gantt, PERT, …) qui se dégradent à cause des changements en technologies, environnements et besoins & exigences client ; cette manière de planification est peu flexible.  Il faut planifier très court (02 semaines à 01 mois).  Principales Méthodes Principales Méthodes Agiles Remarque Une autre méthode agile connue est « Kanban », inventée par Toyota. L’idée de cette méthode et de produire à la demande (production JIT « Just in Time »), afin de réduire le gaspillage et mieux gérer les risques. Méthodologie eXtremeProgramming Définition – XP est un moyen léger, à bas risques, flexible, scientifique (offre des moyens – formules – de mesure de délais & coûts) et amusant (met tous les membres de l’équipe à l’aise) de développement qui est destiné à des équipes de moyennes tailles (6-10) avec des spécifications incomplètes. – Le noyau de XP est le codage (elle est orientée développement). Fondamentaux  Implication massive du client.  Programmation par paires (en binômes).  Itérations courtes et livraisons fréquentes.  Tests unitaires continus (TDD). TDD = « Test Driven Development » : chaque fonction/procédure est accompagnée de sa fonction de test, qui est écrite avant la fonction elle-même  Principales activités Conception (minimale, basée sur le Tests (unitaires, Ecoûte Codage codage, à améliorer pendant le (client/partenaire) (noyau de XP) progressivement) codage) Pratiques XP – Le client et les développeurs collaborent pour établir le planning de la prochaine livraison en triant les Jeu de planning spécifications par priorité. – Ceci inclut la gestion des risques et l'estimation (faite par les développeurs, pas le CDP/client). De petites et D'abord livrer un système minimaliste, puis le faire évoluer à travers des versions à des délais très courts (DOD = « Definition Of Done » : considérer une phase - conception, codage, tests, déploiement - ou une livraison comme fréquentes livraisons "faite" dépend de la définition établie de "faite" par l'équipe et le client !) Les métaphores Le client et les développeurs doivent s'accorder sur les métaphores à utiliser pour simplifier l'expression des fonctions attendues par le client. Conception simple Système conçu de la manière la plus simple possible et d'une façon incrémentale. Refactoring Les développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel (refactoring du code = (remaniement, réusinage) restructuration du code sans changer sa fonctionnalité originale) Programmation en – Le code est écrit par deux programmeurs sur une seule machine ; l’un est appelé « conducteur » (driver, pilote) et l’autre navigateur (co-pilote). Les rôles s’inversent régulièrement. binôme – Le co-pilote peut utiliser une 2ème machine pour la recherche (résolution de bugs, réutilisation de code).  Priorité collective N’importe qui peut changer le code n’importe où dans le système à n’importe quel moment (le code est maîtrisé par tout le monde) 40 heures la semaine Le travail ne doit pas dépasser 40 heures par semaine. Intégration continue L’équipe construit le système (intègre les nouvelles parties) à chaque fois qu’une tache est terminée. Le client est sur site Le client est tout le temps présent avec l’équipe de développement pour participer et répondre aux questions. Standards de A cause de la priorité collective, des standards (charte de codage) doivent être adhérés par l’équipe de codage développement. Inconvénients ☹ Demande une certaine maturité des développeurs (car elle est basée sur le codage). ☹ La programmation par paires n’est toujours pas applicable. ☹ Difficulté de planifier et de budgétiser le projet (car elle est itérative incrémentale). ☹ Stress du au devoir de l’intégration continue et des livraisons fréquentes. ☹ La faible documentation peut nuire en cas de départ de développeurs. ☹ Ne donne pas une manière claire d’organiser les activités à l’intérieur d’un cycle (XP est plutôt un ensemble de pratiques qu’une méthode).  Méthodologie Scrum Principes Simple – Peut être combinée avec les pratiques de XP ou avec d’autres méthodes. – Compatible avec les « best practices » de GL. Empirique Repose sur l’expérience pratique ; on apprend du terrain et on utilise des moyens de mesure pour évaluer chaque phase du projet et améliorer le développement à fur et à mesure. Techniques simples – Sprints (itérations) courts de 2-4 semaines. – Besoins client capturés en tant que « user stories ». Equipes – Auto-organisation (l’équipe est organisée selon les spécifications que chaque membre prend en charge). – Multi-compétences. – Détection rapide des anomalies. Optimisation – Organisation simple. – Requiert l’ouverture et la visibilité. Déroulement L’équipe prend certaines Réalisation des récits + storylines et les évalue, réunions quotidiennes pour détaille et décortique pour évaluer l’état d’avancement estimer les délais & coûts Collecte des « storylines » du client Production d’un prototype dans le backlog du qui peut être livrable produit (cahier de charge) Itérations Concepts Processus : Sprints Le projet est divisé en cycles courts, appelés sprints, généralement de 2 à 4 semaines. Chaque sprint a pour objectif de livrer un incrément fonctionnel du logiciel. Roles Product Owner : Définit les priorités et s'assure que le produit correspond aux besoins du client. Scrum Master : Facilite le processus Scrum et élimine les obstacles pour l'équipe. Équipe de développement (Team) : Multidisciplinaire et autonome, elle est responsable de produire le logiciel. Users & stackholders : utilisateurs du produit final (clients) et personnes intéressés par le projet (sponsors, direction). Réunions Daily Scrum : Réunion quotidienne de l'équipe pour suivre l'avancement. Sprint planning : l'équipe, le Product Owner et le Master se réunissent pour planifier le travail à réaliser pendant le sprint. Sprint Review : à la fin de chaque sprint, une démonstration du produit est faite pour recueillir des retours. Sprint Retrospective : détecter les spécifications incomplètes ou sur/sous-estimées pour les refaire lors du sprint suivant. Artefacts Product Backlog : liste des "user-storylines" (en FR : récits client ; les fonctionnalités à développer, décrites d'une manière métaphore par le client). Sprint Backlog : sélection des éléments du Product Backlog à réaliser durant le sprint. Suivi Rapports Vélocité (évaluation des sprints en points, sur une échelle de 10).  Avantages & inconvénients (➕) (➖)  Très simple, très efficace.  Adoptée par les géants (Microsoft, Google, Nokia, …).  Pas 100% spécifique au GL.  Orientée projet (contrairement à XP = orientée développement).  Difficulté de budgétiser un projet (puisque itératif incrémental)  Peut inclure d’autres activités venant d’autres méthodes (ex : XP). Processus Unifié (UP) Définition  Méthodologie classique, incrémentale et itérative, très populaire qui décrit et détaille les étapes de développement à suivre très bien.  UP est exécutée à travers ses différentes variantes (implémentations), chacune utilisant ses propres outils, dont la plus célèbre est : RUP (Rational Unified Process). D’autres variantes incluent : Agile UP (AUP), Basic UP (BUP) par IBM, Enterprise UP (EUP), Essential UP (EssUP), Open UP (OUP) par Eclispe et Oracle Unified Method (OUM). Principes  1) Processus itératif et incrémental  UP est composé de 4 phases : analyse de besoins (Inception), élaboration, construction et transition.,  Chaque phase peut être décomposée en plusieurs itérations, dont chaque itération produit un incrément du logiciel. 2) Basé sur les cas d’utilisation  Les cas d’utilisation, qui sont les interactions entre le logiciel et le monde extérieur (autres logiciels, utilisateurs), formalisent les spécifications fonctionnelles du produit.  Chaque itération prend un ensemble de cas d’utilisation et les traite selon plusieurs « workflows » (modélisation métier, analyse de besoins, analyse et conception, implémentation, tests et déploiement). N.B : modélisation métier = représentation graphique des taches qui constituent une activité 3) Centré sur l’architecture 4) Met l’accent sur les risques  La méthode UP supporte plusieurs architectures  Identification rapide des risques. logicielles.  Traitement des risques dans les premières phases du projet.  UP commence par la phase d’élaboration, qui produit l’architecture globale du logiciel. Cette dernière est une 5) Utilisation de modèles UML implémentation partielle qui sert de base aux développements futurs.  Les activités UP sont basées sur les diagrammes UML. Cycle de vie  Méthodologie – Toutes les activités sont exécutées de manière itérative au cours de développement, mais le temps alloué à chaque activité change selon la phase courante. – UP est appelée « méthode bidirectionnelle » parce qu’elle avance (évolue) sur les phases (temps) et les activités en même temps. Phases Activités La plus courte phase (peut annuler le projet si elle prend trop de temps). Expression des besoins Analyse Etablit une vision globale du projet (architectures possibles, principaux cas Livrable : diagramme UML Livrable : ébauche de la Inception d'utilisation, risques, planning préliminaire). de cas d'utilisation conception Recensement des besoins Détaille les besoins en du systèmes. spécifications détaillées Elimine les facteurs de risque (si c'est impossible, le projet est abandonné) Capture la majorité des cas d'utilisation et valide l'architecture. Elaboration Livrables : prototype exécutable d'architecture, planning de la contruction. Conception Implémentation Livrable : abstractions de la Traduire les résultats de la solution conception en un système La phase la plus longue. Définit les sous-systèmes, opérationnel Développement du reste du système sur plusieurs itérations. les composants et les étapes Livrables : code source, Construction de construction exécutables,.... Déploiement du système chez les utilisateurs. Tests Les feedbacks client serviront à améliorer le système. Vérification et validation des Transition résultats de l'implémentation Avantages & inconvénients I found this illustration while trying to understand what FIN “itératif incrémental” means and it changed my life, I thought it may change one of your lives too, so here it is ! :)