01-GeĢnieLogicielProcessus.pdf
Document Details
Uploaded by Deleted User
Full Transcript
LOG1410 ā Analyse et Conception logicielle Chapitre 1 GĆ©nie logiciel et processus Ā© FranƧois Guibault ā 2006 - 2022 GĆ©nie logiciel, processus et modĆ©lisation Introduction au gĆ©nie logiciel 1. Pourquoi un gĆ©nie logiciel ? 2...
LOG1410 ā Analyse et Conception logicielle Chapitre 1 GĆ©nie logiciel et processus Ā© FranƧois Guibault ā 2006 - 2022 GĆ©nie logiciel, processus et modĆ©lisation Introduction au gĆ©nie logiciel 1. Pourquoi un gĆ©nie logiciel ? 2. DĆ©fis actuels en logiciel 3. UtilitĆ© dāune approche gĆ©nie 4. Processus de dĆ©veloppement Ć partir de matĆ©riel produit par Mathieu LavallĆ©e, Bram Adams, Michel Gagnon et Nikolay Radoev Ā© FranƧois Guibault ā 2006 - 2022 1- 2 GĆ©nie logiciel, processus et modĆ©lisation Pourquoi un gĆ©nie logiciel ? Grande variĆ©tĆ© dans les types de logiciels : Logiciels de base, SystĆØmes d'exploitation, Applications Web, Jeux vidĆ©os (surtout Ć MontrĆ©al), Logiciels embarquĆ©s (sur circuit Ć©lectronique), Modules d'intelligence artificielle, Etc. Chaque logiciel est dĆ©veloppĆ© en utilisant une approche diffĆ©rente, qui demande rĆ©flexion ! Ā© FranƧois Guibault ā 2006 - 2022 1- 3 GĆ©nie logiciel, processus et modĆ©lisation Pourquoi un gĆ©nie logiciel ? Exemple : On ne programme pas de la mĆŖme maniĆØre un jeu vidĆ©o et un Ć©lectrocardiogramme. Livraison : Pression du Livraison : PrĆ©fĆ©rable marchĆ© (ex.: sortir pour NoĆ«l, dāĆŖtre en retard que de pour une plateforme, pour livrer un produit dangereux. devancer la compĆ©tition). Impact dāun bogue : Peut Impact dāun bogue : On fera ĆŖtre trĆØs grave. un correctif (Ā« patch Ā»). Ā© FranƧois Guibault ā 2006 - 2022 1- 4 GĆ©nie logiciel, processus et modĆ©lisation Pourquoi un gĆ©nie logiciel ? Exemple : On ne dĆ©veloppe pas un logiciel de la mĆŖme maniĆØre qu'on le maintient. Firefox version 1.0 (2004) Firefox version 91.0.2 (2022) PrioritĆ©s de la maintenance PrioritĆ©s du dĆ©veloppement Corriger les bogues, fermer les DĆ©couvrir les besoins des failles de sĆ©curitĆ©, identifier des clients, trouver des solutions, besoins Ć©mergents, assurer implĆ©menter, et valider que Ƨa que lāarchitecture reste saine, correspond aux besoins, etc. etc. Ā© FranƧois Guibault ā 2006 - 2022 1- 5 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel Ćquipes globalisĆ©es : Airbus 380 : 16 sites dans 4 pays. ProblĆØme : Utilisation de CATIA v5 en France et de CATIA v4 en Allemagne qui provoque une erreur de calcul ā 530km de fils Ć changer... Ćquipes nombreuses : Entre 400 et 500 personnes pour un jeu AAA, Environ 4000 personnes ont travaillĆ© sur Windows 7. Ćquipes multidisciplinaires : Programmeur backend, Programmeur frontend, architecte logiciel, expert sĆ©curitĆ©, artiste visuel, artiste sonore, analyste des besoins, expert du domaine, testeur, gestionnaire de projet, etc. Ā© FranƧois Guibault ā 2006 - 2022 1- 6 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel La loi de Brooks : "Ajouter des dĆ©veloppeurs Ć un projet en retard fera qu'il sera encore plus en retard." ā Fred Brooks dans son livre Mythical Man Month, 1975 Pourquoi ? ā Besoin de former la nouvelle personne (souvent fait par les dĆ©veloppeurs originaux), ā La nouvelle personne doit lire toute la documentation du projet (s'il y en a une) ā La nouvelle personne doit comprendre comment l'Ć©quipe fonctionne (dynamique souvent implicite), ConsĆ©quence : ā La nouvelle personne est laissĆ©e souvent Ć elle-mĆŖme et ne sait pas quoi faire. ā Ce que la nouvelle personne produit n'est pas cohĆ©rent avec le reste et est donc rejetĆ©. Ā© FranƧois Guibault ā 2006 - 2022 1- 7 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel Le marchĆ© demande plus de flexibilitĆ© : AccĆ©lĆ©rer le dĆ©ploiement de correctifs. ā MĆ©triques: MTTR (mean time to repair/recovery). Raccourcir le temps entre l'Ć©noncĆ© du besoin et le dĆ©ploiement de la nouvelle fonctionnalitĆ©. ā Solutions: approches agiles, dĆ©ploiement en parallel. Raccourcir le temps entre les versions pour donner une impression d'innovation continue. ā Ex.: Chrome/Firefox Ā« browser wars Ā». Source : shoze.blogspot.com Ā© FranƧois Guibault ā 2006 - 2022 1- 8 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel Plusieurs processus diffĆ©rents dans l'industrie : Firefox: ā RapidRelease ā Six semaines. Facebook, Netflix, Amazon : ā ImplĆ©mentation en multiples micro-projets (micro- services), ā Lorsqu'une micro-projet est prĆŖt, il est mis sur le pipeline de dĆ©ploiement, ā Plusieurs dĆ©ploiements par jour. Eve Online (jeu vidĆ©o, processus hybride) : ā Frontend, amĆ©lioration de l'interface : Six semaines. ā Backend, changement majeurs dans l'architecture : Six mois. Ā© FranƧois Guibault ā 2006 - 2022 1- 9 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel Perception qu'on ne peut Ć©valuer la qualitĆ© que d'un produit fonctionnel : Faux : La qualitĆ© doit ĆŖtre planifiĆ©e, Ć©valuĆ©e durant la totalitĆ© du projet. ā QualitĆ© des exigences, qualitĆ© de la conception, qualitĆ© du code, qualitĆ© des tests eux-mĆŖmes... Il faut donc rĆ©flĆ©chir aux activitĆ©s de qualitĆ© nĆ©cessaires pour atteindre nos objectifs. Objectifs typiques: Produire un produit de qualitĆ©, Avant la date limite, Que Ƨa ne coĆ»te pas trop cher, Et que Ƨa se passe agrĆ©ablement. Ā© FranƧois Guibault ā 2006 - 2022 1- 10 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en gĆ©nie logiciel Utiliser le logiciel ne l'use pas. Modifier le logiciel peut cependant causer de l' Ā« usure Ā» : AppelĆ© software aging ou technical debt. Ex.: ajouter des fonctionnalitĆ©s que l'architecture initiale ne supporte pas bien ā problĆØmes de performance. Ex.: faire des changements sans ĆŖtre pleinement conscients des consĆ©quences (ignorant surgery) ā introduction de bogues. Ex.: ne pas supporter de nouvelles fonctionnalitĆ©s qui deviennent populaires ā dĆ©gradation de l'expĆ©rience utilisateur. Etc. On retire rarement des logiciels ā le bagage logiciel Ā© FranƧois Guibault ā 2006 - 2022 des entreprises ne cesse dāaugmenter... 1- 11 GĆ©nie logiciel, processus et modĆ©lisation Exemples dāĆ©checs majeurs Therac-25 (1985-1987) : Machine de radiothĆ©rapie canadienne avec dĆ©fauts logiciels : ā RĆ©utilisation de code dĆ©ficient ā Code fonctionnel dans lāancienne machine Ć cause de blocages matĆ©riels ā Code rĆ©utilisĆ© non-testĆ© parce que lāancienne machine nāavait jamais eu dāaccident. ā ProblĆØme rare difficile Ć reproduire + Suivi inadĆ©quat des plaintes = Plus de deux ans pour dĆ©couvrir quāil y avait un problĆØme. ā RĆ©sultat ā Application de 100x la dose prĆ©vue ā Six incidents connus rĆ©sultants en plusieurs morts. ProblĆØmes: ā Mauvaise approche de rĆ©utilisation du code, ā Mauvais suivi des plaintes, ā Mauvais enseignement : MĆŖme problĆØme au Panama (2001) et avec la machine Ā« Varian SRS Ā» (2010). Ā© FranƧois Guibault ā 2006 - 2022 1- 12 GĆ©nie logiciel, processus et modĆ©lisation Exemples dāĆ©checs majeurs Mars Climate Orbiter (1999) : MĆ©lange entre Newton-secondes (SI) et Livre-secondes (ImpĆ©rial) : ā Exigences initiales envoyĆ©es au sous-contractant en impĆ©rial ā Client sāattendait finalement Ć des donnĆ©es mĆ©triques. ā ProblĆØme de trajectoire dĆ©tectĆ© lors du vol entre la Terre et Mars ā Les navigateurs et navigatrices nāont pas Ć©tĆ© Ć©coutĆ©s. ā RĆ©sultat ā Perte d'une sonde de 330M$ ! ProblĆØmes : ā Mauvaise gestion des exigences : les documents des utilisateurs (NASA) et des dĆ©veloppeurs (Lockheed) Ć©taient diffĆ©rents. ā Manque de tests durant lāutilisation. ā Consultation inadĆ©quate des experts. Ā© FranƧois Guibault ā 2006 - 2022 1- 13 GĆ©nie logiciel, processus et modĆ©lisation DĆ©fis actuels en logiciel - rĆ©sumĆ© ComplexitĆ© : ā Tout Ć©lĆ©ment logiciel est unique. Il nāy a pas de redondance, mais de la rĆ©utilisation. ā Le gĆ©nie traditionnel se base sur des modĆØles simplifiĆ©s de rĆ©alitĆ©s complexes. En logiciel, cāest le contraire. ConformitĆ© : ā Pas de loi fondamentale comme en physique (ex.: E=mc2) ā Le logiciel doit se conformer Ć des rĆØgles arbitraires parfois illogiques (ex.: architecture von Neumann, TCP et QoS). FlexibilitĆ© : ā Un bon logiciel aura des mises-Ć -jours importantes, qui peuvent toucher nāimporte quelle partie de celui-ci. ā Les bĆ¢timents changent aussi, mais il est plus facile de convaincre et de mesurer le coĆ»t et lāimpact dāun changement ayant une rĆ©alitĆ© physique. Avancement rapide : ā Les outils de dĆ©veloppement (librairies, matĆ©riel, plateformes, etc.) Ć©voluent trĆØs rapidement. Ā© FranƧois Guibault ā 2006 - 2022 1- 14 GĆ©nie logiciel, processus et modĆ©lisation Quāest-ce que lāapproche dāingĆ©nierie ? "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." Ā« L'application d'une approche systĆ©matique, disciplinĆ©e, quantifiable au dĆ©veloppement, l'opĆ©ration et la maintenance du logiciel ; soit l'application de l'ingĆ©nierie au logiciel. Ā» IEEE (Institute of Electrical and Electronics Engineers) SystĆ©matique : pas limitĆ©e au code, mais appliquĆ© Ć toutes les Ć©tapes. DisciplinĆ©e : basĆ©e sur une mĆ©thodologie structurĆ©e. Quantifiable : basĆ©e sur des donnĆ©es objectives. Ā© FranƧois Guibault ā 2006 - 2022 1- 15 GĆ©nie logiciel, processus et modĆ©lisation Quāest-ce que lāapproche dāingĆ©nierie ? Exemple d'une donnĆ©e objective provenant de la recherche : ā Dans un projet typique, entre 60% et 80% de l'effort consacrĆ© au logiciel a lieu aprĆØs la livraison ā correction de bogues et maintenance. ā ConsĆ©quence ā le dĆ©veloppement doit produire un logiciel maintenable ā Ā« Le seul logiciel qui n'est pas modifiĆ© est celui qui n'est jamais utilisĆ©. Ā» - David Parnas (1994) Ā© FranƧois Guibault ā 2006 - 2022 1- 16 GĆ©nie logiciel, processus et modĆ©lisation Quāest-ce que lāapproche dāingĆ©nierie ? Discipline Exemple dāactivitĆ©s Exigences DĆ©finition du problĆØme DĆ©finition des exigences (ou spĆ©cifications) Conception Conception architecturale Conception dĆ©taillĆ©e ImplĆ©mentation Codage et dĆ©bogage Tests unitaires IntĆ©gration et tests dāintĆ©gration Tests Tests boĆ®te blanche (vĆ©rification) Tests boĆ®te noire (validation) DĆ©ploiement PĆ©riode de rodage (ajustements post-livraison) Maintenance corrective (correction de bogues) Maintenance perfective (ajout de fonctionalitĆ©s) Ā© FranƧois Guibault ā 2006 - 2022 1- 17 GĆ©nie logiciel, processus et modĆ©lisation Quāest-ce que lāapproche dāingĆ©nierie ? Ā© FranƧois Guibault ā 2006 - 2022 Version adaptĆ©e d'une figure prĆ©parĆ©e par professeur Nikolay Radoev 1- 18 GĆ©nie logiciel, processus et modĆ©lisation Cāest quoi un ingĆ©nieur logiciel? Voici ce qui fait un bon ingĆ©nieur logiciel, selon des recherches faites chez Microsoft (2015) : ā Ćtre prĆŖt Ć sāamĆ©liorer, Ć sāadapter, ā Bien connaĆ®tre les gens et lāorganisation, ā Ćtre capable de communiquer avec les autres, ā Produire du matĆ©riel simple et intuitif. Où sont les compĆ©tences techniques ? ā Ćtre bon programmeur se trouve plus loin derriĆØre. Une Ć©quipe de programmeurs ordinaires rĆ©ussit typiquement mieux que des cracks qui travaillent de maniĆØre isolĆ©e. ā Un peu comme une Ć©quipe de hockey, de football. Ā© FranƧois Guibault ā 2006 - 2022 1- 19 GĆ©nie logiciel, processus et modĆ©lisation Processus de dĆ©veloppement en cascade Version adaptĆ©e d'une figureGuibault Ā© FranƧois prĆ©parĆ©e par ā 2006 M. Ćric Demers - 2022 1- 20 GĆ©nie logiciel, processus et modĆ©lisation Approche en cascade Ā© FranƧois Guibault ā 2006 - 2022 1- 21 GĆ©nie logiciel, processus et modĆ©lisation Requis Planification Analyse et initiale Planification conception Processus de dĆ©veloppement itĆ©ratif (en spirale) ImplĆ©mentation Ćvaluation Test et DĆ©ploiement validation Ā© FranƧois Guibault ā 2006 - 2022 1- 22 GĆ©nie logiciel, processus et modĆ©lisation Processus unifiĆ© Ā© FranƧois Guibault ā 2006 - 2022 [fr.wikipedia.org/wiki/Processus_unifiĆ©] 1- 23 GĆ©nie logiciel, processus et modĆ©lisation EnchaĆ®nements d'activitĆ©s et la relation entre les disciplines et les phases Ā© FranƧois Guibault ā 2006 - 2022 1- 24