Présenter les principes, méthodes et outils du génie logiciel
Parler de développement: méthodes, test, code,
gestion de versions/de configurations, OBJECTIFS DU métriques
COURS Références
• cours d’Olivier Perrin et de P. Fontaine
• cours de M. Dumas • cours/livre de I. Sommerville présentation de L. Torvalds PLAN • Introduction
• Méthodes
• Tests
• Gestion des configurations
• Code/patrons
• Métriques
• Outils L’ARCHITECTURE … cela évolue lentement… L’ARCHITECTURE … cela grossit petit à petit… L’ARCHITECTURE …pour devenir dense… L’ARCHITECTURE … et complexe !!! L’ARCHITECTURE …voir fantastique ! DANS LE DOMAINE DU LOGICIEL... ARCHITECTURE/ L’ENNEMI Côté fiabilité: le bug
2ème guerre mondiale : problèmes électroniques dans les radars appelés
bugs. Utilisation de “bug” serait beaucoup plus ancienne.
Cause d’un mal-fonctionnement dans un Mark II : papillon de nuit coincé dans
un relais. Bug soigneusement intégré au livre de bord, le 9 septembre 1947 LES BUGS CÉLÈBRES Therac-25 (1985-1987) : appareil radio-thérapeutique. Ariane 5 (1996) : réutilisation inappropriée de code d’Ariane Problème lié aux filtres. Coût : ≥ 5 décès. 4. Effet : explosion. Coût : 109 $
Mars
1985–1987 1996
NASA Mars Rover (21 janvier 2004) : paralysé à cause
d’une erreur système : trop de fichiers ouverts sur la mémoire flash LES BUGS CÉLÈBRES(CONT.) Intel Pentium FDIV : erreur dans l’opération FDIV, précision
Plus récemment, Intel Sandy Bridge et les failles de sécurité Spectre et Meltdown
Le défaut affecte particulièrement les composants Cougar Point (Intel H67 et P67) dédiés à Sandy Bridge. « Dans certains cas, explique Intel, les ports le Serial-ATA (SATA) gérés par les chipsets peuvent se dégrader au fil du temps, ce qui pourrait affecter les performances ou les fonctionnalités des périphériques SATA liés tels que les disques durs et les lecteurs DVD. » Ennuyeux. Même si le processeur n’est pas directement touché par ce défaut de fabrication, il n’en risque pas moins d’entraîner une baisse des performances globale du système, freiné par la fluidité de circulation des données. Un comble pour une plate-forme de dernière génération dont les hautes performances sont mises en avant. LES BUGS CÉLÈBRES(CONT.) Airbus 320 (http://www.youtube.com/watch?v=2eQpUgHkBcg)
Collection de bugs
‣ http://www5.in.tum.de/~huckle/bugse.html
‣ http://en.wikipedia.org/wiki/Software_bug
‣ http://www.risks.org/ L’ENNEMI Côté délais LESDÉLAIS FF4
‣ de juin à mars: 10 mois
LES DÉLAIS (CONT.) Chrome
Anthony Laforge LES DÉLAIS (CONT.) « We market features, not releases. » IDÉESREÇUES Idée grossière du logiciel à réaliser suffisant pour commencer le programme ‣ idée imprécise = source d’erreur Programme terminé et fonctionne : travail terminé ‣ maintenance = travail important
‣ coût de maintenance élevé
Changement des spécifications possible car logiciel = produit souple ‣ changement de spécifications : coûteux, allongent délais Si réalisation logiciel en retard % délais prévus : ajouter programmeurs, ajouter personnel : ‣ nécessite période de familiarisation ‣ temps passé à communiquer augmente avec taille du ‣ groupe réduction productivité de chacun CONSTAT D’ÉCHEC « The CHAOS Summary Report » :
‣ 24% des développements applicatifs sont des échecs
‣ 84% des projets critiques n'atteignent pas leurs objectifs
‣ 54% ont rencontré des dépassements de coûts
‣ 79% ont des dépassements d'échéanciers
« Le coût moyen d'une mise à jour technologique est de 18% du coût original du projet » (CIO Magazine) QUESTIONS QUE SEPOSE UN CHEF DE PROJET
Comment diminuer les délais et les coûts de mes projets ?
Où sont mes spéciifications à jour ?
Comment capitaliser le savoir faire de mes équipes ?
Comment être plus agile avec les évolutions ?
COMMENT JUGER DE LA QUALITÉ DU LOGICIEL • Répond aux attentes
• Correct : réalise les spécifications
• Coût initial contrôlé
• Délai initial contrôlé
• Maintenance facile : extension aisée, coûts, et délais contrôlés
LA VISIONIDÉALE LARÉALITÉ… POURQUOI EST-CE DE PLUS EN PLUS COMPLEXE ? • Exigences en hausse
Spécifier : ‣ entrées, avec sources, précision, valeurs acceptées, format ‣ sorties, avec destination, précision, plage de valeur,
‣ format formats pour les rapports, pages web...
‣ interfaces hardware et softwares
‣ interfaces de communication, avec protocoles, hand-shaking, correction d’erreur ‣ tâches de l’utilisateur ‣ données utilisées pour chaque tâche, et les données résultant de chaque tâche SPÉCIFICATION DES BESOINS(CONT.) Besoins non-fonctionnels
Spécifier
‣ temps de réponses pour toutes les opérations
‣ autres temps: transfert de données...
‣ niveau de sécurité, conséquences d’une erreur, informations vitales,
détection d’erreur, recouvrement après erreur
‣ caractéristiques techniques nécessaires : CPU, espae disque et mémoire
‣ développements futurs, changement d’OS, d’interface à prévoir
SPÉCIFICATION DES BESOINS(CONT.) Qualité de l’expression des besoins
‣ besoins écrits dans le langage de l’utilisateur ? Qu’en pense l’utilisateur ?
‣ besoins suffisamment bien décrits pour être livrés à un tiers
‣ besoins vérifiables (test) ?
‣ spécification des modifications probables des besoins
SPÉCIFICATION DES BESOINS(CONT.) Complétude des besoins
‣ si un besoin n’est pas encore totalement connu, est-ce spécifié ?
‣ un produit vérifiant tous les besoins (et que les besoins) sera-t-il acceptable ?
‣ n’y a-t-il pas des “besoins de complaisance” ? des besoins irréalisables ?
ANALYSE ET FORMALISATION DES BESOINS AU SEIN DU PROJET Contexte et projet • Présentation du contexte • Décrire le contenu du projet Architecture fonctionnelle • Représenter l’intégration de l’application dans le système existant • Identifier les flux externes de façon exhaustive • Identifier et lister la totalité des fonctions attendues • Décrire de façon détaillée chaque fonction : • définition et objectif • description fonctionnelle : traitements, enchaînements, règles de gestion, contrôles sur les données • Reprise de l’existant • Décrire de façon détaillée les principes de reprise • Indiquer le scénario de reprise Les flux • Schéma général des flux • Représenter la totalité des flux externes et internes, exprimés en entrée/sortie Identification des Partenaires
acteurs externes Clients
ANALYSE ET Répartition Production
FORMALISATION DES géographique Ventes
BESOINS Liste des différents Fonctions profils de chaque Habilitations acteur concerné
Fonctionnel Contraintes Technique identifiées dans les Réglementaire Organisationnel domaines suivants : … CAS PRATIQUE EXEMPLE DE MISE EN APPLICATION Contexte du projet • Vous êtes une entreprise de fabrication de vêtements de sport, ayant un site de prod. et magasin d'usine • L'entreprise compte 60 personnes, ayant un site de production et un magasin d'usine (Nouveau site) • Dernière modification du site vitrine réalisée il y a plus de 2 ans • Information du Système d'Information interne : • Catalogue produits (~ 80 000 articles) • Tarification par famille de pdts (5)/ remise/famille/client ou / article • 10 000 comptes client avec un besoin de vendre en ligne • Relation B commerciale en BtoB (Relation difficile avec les revendeurs) • Parc informatique géré en interne (système AS400) • Informaticien dédié à l'ensemble des tâches (intéressé par les nouvelles technologies Web) Questions • Que pouvez vous déduire du contexte et besoins exprimés par ce client ? • Quels sont les services que vous pourriez proposer ? • Quelles sont les difficultés de ce type de projet ? • Quelle stratégie prendriez vous pour faire ce projet et éviter les dépassements de temps et d’argent ? ARCHITECTURE • Organisation du programme, aperçu de l’architecture, avec justification
• Blocs principaux définis, avec tâches, et interfaces
• Modules critiques décrits et justifiés
• Description de l’organisation des données (et BD), avec justification
Description de l’interface utilisateur
• Description de l’estimation de l’utilisation des ressources rares (threads,
connexions BD, réseau...)
• Besoin en termes de sécurité
ARCHITECTURE (CONT.) Estimation budget et délais pour chaque module
Passage à l’échelle
Internationalisation
Étude de faisabilité technique
Réutilisation de code Architecture évolutive
LESCLASSIQUES...
• Cascade
• V
• Spirale ...ET LES PLUS RÉCENTES • XP
• Scrum CASCADE Waterfall
Requirements definition
software design acteurs: client, analyste, chef de projet Implementation
system testing
Operation and maintenance CASCADE(CONT.) Modèle orienté plan
Linéaire
‣ succession d’étapes
Une étape doit être achevée avant de pouvoir passer à la
suivante Pas de changement possible une fois que le
processus est lancé
CASCADE(CONT.) Modèle adapté lorsqu’il y a plusieurs sites de développement ‣ tous les sites se coordonnent grâce au plan de développement
Difficulté pour répondre à des changements de spécifications
‣ modèle adapté lorsqu’il y a peu de changements au niveau des spécifications
‣ …mais il y a très souvent des changements !
Projet monolithique ‣ produit global livré en une seule fois Phase d’intégration souvent problématique !
‣ Phase de développement sans les utilisateurs
MODÈLE ENV
Analyse besoins Recette
Spécification Validation
Conception Intégration architectural e Conception détaillée Test unitaire
Programmation MODÈLE ENV (CONT.) Ne pas voir ce modèle comme un cycle de vie
‣ par exemple, test ko Test unitaire
• retour en arrière ? Programmation • pendant le test, on code ?
Mais plutôt comme les dépendances entre les disciplines du développement
‣ les activités à gauche génèrent des entrées pour les activités à droite
Conception Test unitaire détaillée MODÈLE ENV (CONT.)
Analyse besoins Recette
Spécification Validation
Conception Intégration architectural e Conception Test unitaire détaillée
Programmation SPIRALE Le processus de développement est représenté grâce à une spirale
‣ plus de problème lié à la séquence (par ex. backtracking)
‣ Chaque étape de la spirale représente une étape du processus
Pas d’étapes prédéfinies (e.g. spécification, conception): les itérations de la
spirale sont choisies en fonction de ce dont on a besoin
Prise en compte explicite des risques, et résolution au cours du processus
SPIRALE (CONT.)
Determine objectives,
1 2 Evaluate alternatives, alternatives and identify, resolve risks constraints Risk analysis Risk analysis Risk analysis Opera- Prototype 3 tional Prototype 2 protoype Risk analysis Proto- REVIEW type 1 Requirements plan Simulations, models, benchmarks Life-cycle plan Concept of Operation S/W requirements Product design Detailed Requirement design Development plan validation Code Unit test Integration Design V&V Integration and test plan Plan next phase test Acceptance
4 3 test Develop, verify Service next-level product SPIRALE (CONT.) Modèle itératif et évolutif
Permet très tôt des retours sur :
‣ les modifications des
spécifications ‣ l’adéquation entre la spécification, la conception et l’implantation ‣ l’acceptation par le client ‣ les domaines à risque potentiel (performances du réseau par exemple) ‣ la validité de la planification du projet PROTOTYPAGE Un prototype est une version initiale d’un système destinée à démontrer des concepts et à tester des options
Un prototype peut être utilisé lors:
‣ de la phase de spécification des besoins (explication,
vérification) ‣ de la phase liée à la conception de l’interface utilisateur ‣ de la phase de tests BÉNÉFICES DUPROTOTYPAGE Utilisabilité du système améliorée
plan definition prototype report MDA (Model Driven Architecture) POINT DE DÉPART: CONSTAT D’ÉCHEC ! MDA (CONT.) L’architecture a une influence sur l’implantation
‣ e.g. MVC
Solution imaginée en 2000
‣ utiliser des modèles pour monter en abstraction et faciliter la
communication métiers / IT
‣ séparer les aspects techniques et
fonctionnels ‣ avoir une démarche basée sur les standards UML MDA (CONT.)
Démarche
Computation Independent Model
Présente ce que le système doit faire
Platform Independent Model
Ensemble de services permettant L’extraction des données techniques Platform Specific Model Spécificité du PIM + détails nécessaires ! Sur utilisation du système sur une Plateforme donné QUELQUE SOIT LAMÉTHODE… Cela n’évite pas de penser aux bonnes pratiques d'ingénierie :
‣ svn/Git
‣ build automatique et reproductible
‣ intégration continue
‣ tests automatisés
‣ métriques MÉTHODES AGILES
eXtreme Programming
Si vous voulez
‣ plus de ‣ moins de logiciel personnes ‣ de qualité ‣ moins de supérieure gestion ‣ avec des délais ‣ moins de réduits complexité ‣ pour des budgets ‣ moins d’outils moindres ‣ avec plus de ‣ engagement des certitude développeurs XP
CYCLE DE DÉVELOPPEMENT
Petites releases
Métaphore
Conception
simple Test
Refactoring Stats. 2018
Pair programming XP(CONT.) Propriété collective
Intégration
continue
40h/semaine
Client sur site
Standard de
codage IDENTIFIER LES FLUX D'INFORMATIONS
Objectifs Identifier les points clés du projet, Lever les difficultés ou problèmes techniques, Accompagner le client dans la compréhension du futur système IDENTIFIER LES PROCESSUS MAQUETTES FONCTIONNELLES
Objectifs Exigences
• Permettre au client de • Temps de conception
se projeter dans le • Approche fortement projet, ergonomique, • Comprendre le • Contraintes techniques raisonnement appliqué, et technologiques à ne • Aide à la validation pas minimiser et/ou la conception • Démonstration par d'un CDC l'exemple LES OUTILS : TRELLO ET WEKAN LES OUTILS : SLACK ET MATTERMOST LES OUTILS : REDMINE
