Processus de développement PDF

Processus de développement Aussi appelé : processus d’ingénierie logiciel (Software Engineering Process (SEP)) Définit le qui, quoi, quand et comment pour développer un logiciel Processus qui consiste à transformer les exigences utilisateur en logiciel Dével...

Processus de développement Aussi appelé : processus d’ingénierie logiciel (Software Engineering Process (SEP)) Définit le qui, quoi, quand et comment pour développer un logiciel Processus qui consiste à transformer les exigences utilisateur en logiciel Développement de logiciel Le processus de développement logiciel que nous appellerons pour la suite le développement de logiciel est l’ensemble des acGvités nécessaires à la créaGon d’un logiciel. Ces activités se regroupent en deux catégories : 1. Les activités de base : L’analyse de exigences La conception La réalisation Les tests Le déploiement La maintenance 2. Les activités secondaires (support aux activités de base): La gestion des configurations et des changements La gestion de projet Environnements Le cycle de vie du logiciel : L’analyse des exigences La Conception La réalisaGon Les tests Le déploiement La maintenance Analyse des exigences Capturer ce que le logiciel doit faire (quoi) Raffiner et structurer les exigences(besoins) Exigences fonctionnelles (cas d’utilisation) Exigences non-fonctionnelles(performance, fiabilité, etc.) Traduire les besoins de l’usager en spécifications du logiciel Rédaction des exigences du logiciel  Conception Ensemble d’acGvités qui permeTent de définir comment le logiciel devra être réalisé L’objecGf est de définir la structure du logiciel ConcepBon architecturale (décomposiBon en modules) ConcepBon détaillée (définiBon des algorithmes des modules) Réalisation (Implémentation) Construire le logiciel Produire du code source (programmation) Tests Exécuter le logiciel pour trouver des fautes ou gagner en confiance dans le système Vérifier que l’implémentaGon foncGonne comme désiré Déploiement Le moment où le logiciel est mise en œuvre (installer) chez le client pour que les utilisateurs l’utilisent réellement. Maintenance Mises à jour; correcGons de bogues; adaptaGon La maintenance n’est souvent pas considérée comme une étape du processus de développement. Par contre, beaucoup de développements ont lieu sur des logiciels déjà en maintenance. On peut regrouper les activités de maintenance en 4 catégories: Perfective : ajout de nouvelles exigences ou amélioration des performances Corrective : réparer des défauts du système Adaptative : suivre les changements d’environnements (OS, Compilateurs, …) Préventive : simplifier l’évolution du système Qualité logiciel de qualité Selon IEEE STD 610, un logiciel de qualité est un logiciel qui répond aux attentes de ses utilisateurs code source de qualité Un code source de qualité : Facile à lire (lisibilité) Facile à comprendre (compréhensibilité) Facile à modifier (maintenabilité) Facile à tester (testabilité) La qualité du logiciel a un impact sur la satisfaction des utilisateurs. La qualité du code source a un impact sur la durée du développement et sur les coûts (de développement et de maintenance). Productivité Les outils et les pratiques sont directement liés à la productivité des développeurs. Plus le développement est rapide et efficace, meilleur est la productivité. On ne doit jamais sacrifier la qualité pour améliorer la productivité. Chaque pratique du processus de développement doit avoir comme objectif d’améliorer simultanément la qualité et la productivité Équipe Le développement de logiciel est généralement un travail d’équipe. Ceci implique : Une certaine autonomie et maturité des membres de l’équipe. Le respect entre coéquipiers. L’uGlisaGon d’ouGl de collaboraGon. Modèles de développement Modèle en cascade (Waterfall) : le modèle traditionnel Met l’accent sur des phases séquentielles et l’analyse de tendance de jalons Phases séquentielles : Toutes les spécifications doivent être Complétées avant de passer à la conception et à l’implémentation Problèmes du modèle en cascade Rigidité du processus Difficulté à s’adapter aux changements Absence du client Vérification (tests) trop tardive Donne l’impression d’avancer mais produit rien de concrète ++ Approche disciplinée mais très rigide Idéale lorsque toutes les spécifications sont connues d’avance et ne changeront pas Analyse de tendance de jalons Limiter les dégâts (se protéger) dans un modèle en cascade Modèle itératif Le cycle de vie du logiciel est divisé en mini-projet appelés itérations : + Chaque itération inclut les activités d’analyse, de conception, d’implémentation et de test + Le résultat d’une itération est un logiciel fonctionnel constitué d’un sous- ensemble des fonctionnalités du logiciel Modéles itératifs et accent sur : Construction incrémentale : Cycles itératifs de développement, de vérification et de démonstration Chaque itération ajoute des fonctionnalités à la base existante Les parties les plus critiques sont construites d’abord Spirale : gestion de risque Évolutif : Développement exploratoire Agile : Participation clientéle Le manifeste agile Les individus et leurs interac:on plus que les processus et les ou:ls Des logiciels fonc:onnels plus qu’une documenta:on exhaus:ve La collabora:on avec le client plus que la négocia:on contractuelle L’adapta:on au changement plus que le suivi d’un plan Les principales méthodes agiles : SCRUM Extreme Programming (XP) Cristal Clear Lean SoIware Development Feature Driven Development Adapta:ve soIware Development SCRUM Framework de résoluKon de problèmes complexes Développement itéraKf et incrémental Objectifs : Rendre le processus plus prévisible Contrôler les risques Piliers Contrôle du processus de développement La transparence : les aspects du processus qui affectent le résultat sont visibles/observables et conformes à la réalité  L’inspection : les différents aspects du processus doivent être inspectés -égulièrement pour que les écarts soient détectés rapidement L’adaptation : si l’inspecDon relève que le processus s’écarte de ce qui est attendu, le processus doit être adapté Carnet du produit (Product backlog) Carnet du produit (Product backlog) Liste des fonc:onnalités (user stories) à développer Priorisé par le propriétaire du produit Cette liste évolue durant le projet Pour chaque élément, on indique une descrip:on, une priorité et une estimation Récits d’utilisateurs (User stories) Une user story décrit une fonctionnalité du point de vue de l’utilisateur selon le principe des 3C : La carte : définit la story en terme de rôle, fonction et bénéfice Exp : En tant qu’étudiant, je peux consulter mes notes, pour savoir si j’ai réussi ou échoué le cours Conversation ou communication; on veut encourager la communicaDon entre le client et le développeur. Confirmation ou critère d’acceptaDon (quoi faire pour accepter le produit) Carnet du Sprint (Sprint backlog) Carnet du sprint (Sprint backlog) Contient la liste des fonctionnalités du sprint en cours Sous-ensemble du carnet du produit Responsabilité de l’équipe gardé visible pour l’équipe Scrum à travers le tableau de bord Terminé Lorsqu'une tâche est terminée, on doit l'identifier comme telle La définition du terme « terminé » peut varier d'une équipe à l'autre « Terminé » pourrait vouloir dire, par exemple : - Le code a été écrit - Le code a été nettoyé - Compilé - Testé - La révision a été faite L’équipe Scrum Rôles : Product Owner (le propriétaire du produit): Porteur de la vision globale du produit Gère le carnet du produit (product backlog)  Défini les priorités Accepte ou rejette les livrables Une personne pas un comité Scrum Master (maître de mêlée): Veille au bon fonctionnement de l’équipe (enlève les obstacles) Gardien des pratiques Scrum Serviteur de l’équipe (facilitateur) N’est pas un chef de projet Development Team (l’équipe de développement) : 5 à 9 personnes (7 + ou - 2) Autogéré (décisions prises collectivement) Possède toutes les compétences pour le projet (multidisciplinaire) Développe de façon itérative et incrémental Ne change pas pendant un sprint Événements Scrum Assure la transparence, l’inspection et donc l’adaptation - Sprint - Planification de sprint (Sprint planning) - Mêlée quotidienne (Daily Scrum) - Revue de sprint (Sprint review) - Rétrospective de sprint Sprint C’est une itération La composition de l'équipe et les objectifs de qualité doivent rester les mêmes durant le sprint Activités : + Planification de sprint + Développement + Revue de sprint + Rétrospective du sprint Planification du sprint o Création et estimation du sprint backlog Faire un plan de développement Ce qui sera fait chaque jour Décomposer les fonctionnalités choisies en tâches d’une journée Dure 8 heures pour un sprint d’un mois Estimation par Poker planning Mêlée quo&dienne (Daily Scrum): Réunion quoTdienne de 15 minutes Uniquement la présence du Development Team est requise objecTfs : Déterminer ce qui a été accompli depuis la veille IdenTfier les obstacles idenTfiés entre temps Déterminer ce qui sera réalisé́ d'ici le lendemain Revue de sprint (Sprint review) : Revue du sprint L’équipe de développement fait une démonstration  L'équipe et les parties prenantes discutent de ce qui a été accompli durant le sprint et de ce qui devra être fait durant le prochain sprint Une réunion de 4 heures pour une itération d’un mois Rétrospective de sprint L'équipe revoit son processus de développement pour l'améliorer Inspecter le déroulement du sprint, plus spécifiquement évaluer : Les individus Les relations interpersonnelles Les processus Les outils Créer un plan pour la mise en œuvre/adop7on des améliorations JSON Le fait de rendre les données persistantes s’appelle la sérialisation Le format = un standard de représentation (une façon de représenter des données) Il existe plusieurs standards de représentation des données : XML, YAML, JSON, … Le processus inverse s’appelle la désérialisation JSON Un format pour échanger des données (fichier texte)+ Indépendant de tout langage+ Multi-plateforme (interopérabilité)+ Simple et léger+ Lisible par une machine et un humain+ Extension :.json La clé doit être une chaîne de caractères Aucun mot-clé réservé et sensible à la casse Gestionnaire de sources Un système de gestion de sources est comme une machine à remonter le temps (UNDO) sur un projet C’est un logiciel qui permet de : Conserver tout le code source Prendre note de tous les changements effectués au code source et à sa documenta6on Retourner à une version antérieure (qui, elle, fonc-onnait !!) Identifier quels fichiers ont été modifiés Déterminer qui a modifié un bout de code Comparer des versions Fusionner des versions développées de façon concurrente Résolution des conflits de fusion Identifier et gérer les releases, les versions et les branches de développement Il existe 2 types de ges2onnaire de sources : Centralisés L’historique des fichier est conservé dans un serveur central (distant) Distribués L’historique des fichiers est conservé localement Gratuits : CVS, subversion, git payants : perforce, Team foundation server, bitkeepr Ce qu’on inclut dans le ges2onnaire de sources : Code sources (évidemment) Tests, documenta6ons, fichiers de configura6on Les scripts de construc6on (de build) Les manifestes de dépendances Les fichiers binaires nécessaires au déploiement. Ceci inclus parfois les librairies dépendantes et certains utilitaires de construction. Ce qu’il faut exclure du gestionnaire de sources : Le code généré (par un générateur de code ou par l’IDE) Le code compilé, les pages de résultats de tests Les configurations personnelles dans un projet en équipe Documents d’analyse, les rapports de test Diagrammes UML Working directory ou Working tree : Le répertoire ou vous faites vos modifica3ons dans le code source Stage area ou Index : L’espace ou l’on place les fichiers du prochain commit Local Repository : L’historique de tous les changements du projet, placée sur votre poste Remote Le serveur distant se nomme remote et sa copy du repository, remote repository Un remote repository est un dépôt git qui réside sur une autre machine L'outil habituel pour se connecter à une machine distante est ssh. Certaines commandes de git uOlisent ssh pour échanger les fichiers du repository entre la machine locale et la machine distante (nommée « remote »  Clean Code Choisir le nom Révéler l‘inten/on Éviter la désinforma/on Nom prononçable / sans encodage Facile à rechercher Éviter les associa/ons mentales Choisir le nom Un nom de classe devrait débuter par un nom Un nom de méthode devrait débuter par un verbe Éviter les jeux de mots (un nom par concept) Utiliser la terminologie du domaine Écrire une méthode Courte Ne fait qu’une seule chose Une méthode pose une action ou obtient l'information sur le système - jamais les deux (Command-Query Separation) Nom descriptif Limiter les paramètres (max. 3) Éviter les paramètres « flag» Préférer les excep/ons dans la ges/on d’erreurs DRY : Don’t Reapeat Yourself commentaires bon commentaires : Commentaires légaux Donner de l’informa5on u5le Clarifier le fonc5onnement d’un algorithme Préciser les raisons d’un choix technologie ou les conséquences d’une modifica5on Indiquer des endroits à corriger, à compléter (TODO) Javadoc pour une librairie Mauvais commentaires Écrit parce que les procédures l’obligent Est redondant  Induit le lecteur en erreur Documenté des trivialités Remplace un bon iden5fiant (nom) Commente du code source Mal placé Refactoring Modifier, améliorer, réécrire une partie du code dans le but de le rendre plus facile à lire et à comprendre, Ne change pas la fonctionnalité SRP Single Responsibility Principle Une entité ne devrait avoir qu‘une seule responsabilité; une seule raison de changer Loi de Déméter (LoD) Mo5va5on Only talk to your immediate friends Don't talk to strangers Least Knowledge Principle (Principe de connaissance minimale) LoD entre deux classes Si ces deux classes n'ont pas besoin de se communiquer directement, on utilisera une troisième classe entre les deux pour assurer la communicaBon LoD générale Couplage faible entre les modules d'un système Restreindre les accessibilités Dette technique En bref : Livrer maintenant, ajuster plus tard Don’t live with broken windows Corriger les erreurs, les défauts, et le code mal écrit dès qu'ils sont détectés. La dégrada5on de la qualité du système s’accélère si les problèmes ne sont pas immédiatement corrigés DRY : Don‘t Repeat Yourself Chaque connaissance du système ou du domaine du problème doit avoir une et une seule représenta5on dans le système. La duplication peut être imposée, peut arrivée par inadvertance ou peut être causée par l'impatience des développeurs ou un manque de communication. YAGNI – You Aren‘t Gonna Need It  Ne faire que ce qui est absolument nécessaire. Ceci s'applique à l’implémentation des fonctionnalités, au design des modules, à la documenta5on ainsi qu'à l'analyse. Les ac5vités de refactoring et de tests en sont exclues. On construit le système afin que les décisions puissent être faites le plus tard possible. Minimize coupling between modules Le code d'un module devrait être « timide ». La Loi de Déméter permet de minimiser le couplage. Le code d'une méthode peut appeler Les méthodes du même objet Les méthodes des objets passés en paramètre, les méthodes desobjets créés, les méthodes des variables d'instance. Eliminate efects between unrelated components Chaque module doit avoir un fonc5onnement interne indépendant et un but précis et unique. On dit que les modules d'un système doivent être orthogonaux: les modifications à l'un n'occasionnent pas d'impact dans le fonctionnement interne d'un autre. Refactor early and ofen Refactoriser lorsqu'on détecte de la duplication, un design non-orthogonal, des connaissances désuètes et problèmes de performance. Avoir confiance en ses refactorings implique la présence de tests. Smells Un smell est un élément que l‘on remarque dans le code qui semble indiquer un problème de réalisation ou de conception Un smell ne doit pas être évité à tout prix, mais c‘est souvent signe qu‘il est possible d‘améliorer le code BUILD REQUIRES MORE THAN 1 STEP Une seule commande devrait être en mesure de compiler le code et les tests, exécuter l'analyse sta5que et exécuter les tests. Tout devrait être automatisé, répétable et uniforme entre les ordinateurs des développeurs. Too many arguments Le nombre de paramètres ne devrait jamais dépasser 3. Il ne devrait pas y avoir des paramètres « flag ». Les paramètres servent d’entrée, pas de sortie. Dead functions Toutes les méthodes présentes doivent être appelées Feature envy Une méthode ne respecte pas la Loi de Déméter ou appelle plusieurs méthodes d'une autre instance Inconsistency  Le comportement de deux modules similaires est différent. Deux variables séman5quement équivalente n'ont pas la même convention de nommage. Généralement, si deux modules sont proches en responsabilités et en sens, ils devrait se ressembler. Functions name should say what they do À la lecture de la signature d'une méthode, le lecteur devrait avoir toute l'informa5on nécessaire pour en comprendre la responsabilité. Function should do 1 thing Même dans l’implémentation d'un algorithme, une méthode ne devrait faire qu'une seule chose : Par exemple : boucler sur une liste, filtrer les éléments, appeler une méthode, etc. Ceci mène à des fonc5ons de moins de 10 lignes en Java.