Le document présente un cours sur les méthodes et processus de conception de systèmes d'information, axé sur le génie logiciel et les approches comme le processus unifié et les méthodes agiles. Il aborde également les concepts de qualité logicielle, de gestion de projet et d'évolution des méthodes de modélisation, en soulignant l'importance d'une approche itérative et collaborative. Enfin, il établit des distinctions entre différentes générations de méthodes, de la modélisation fonctionnelle à l'approche orientée objet.

1. Processus de conception de SI1/3 – Méthodes et processusYannick PriéDépartement Informatique – Facultés des Sciences et TechnologiesUniversité Claude Bernard Lyon 12011-2012

2. Objectifs du cours globalNotion de méthode de conception de SIMéthodes OO de conceptionGénéralités sur les méthodesProcessus unifiédescription généraleexemples de déclinaisonsProcessus AGILE 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 12

3. Ce qu’il faut éviter2011-2012 / Yannick Prié - Université Claude Bernard Lyon 13(Kimberly Wiefling)

4. Plan du cours global1/3 – Méthodes et processus2/3 – Processus unifié3/3 – Méthodes Agile2011-2012 / Yannick Prié - Université Claude Bernard Lyon 14

5. Plan de ce cours Avant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 15

6. UML : No silverbulletConnaître UML (ou maîtriser un AGL) n’est pas suffisant pour réaliser de bonnes conceptionsmalgré ce que le marketing peut affirmerUML n’est qu’un langageIl faut en plussavoir penser / coder en termes d’objets maîtriser des techniques de conception et de programmation objetavoir un certain nombre de qualités Méthodes de conceptionpropositions de cheminements à suivre pour concevoirpas de méthode ultime non pluscertains bon principes se retrouvent cependant partout2011-2012 / Yannick Prié - Université Claude Bernard Lyon 16

7. Ce qu’il faut aimer pour arriver à concevoirÊtre à l’écoute du monde extérieurDialoguer et communiquer avec les gens qui utiliseront le systèmeObserver et expérimenter : une conception n’est jamais bonne du premier coupTravailler sans filet : en général, il y a très peu de recettes toutes faitesAbstraireTravailler à plusieurs : un projet n’est jamais réalisé tout seulAller au résultat : le client doit être satisfait, il y a des enjeux financiers 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(B. Morand)7

8. AvertissementBeaucoup de concepts dans ce coursproviennent du domaine du développement logiciel ancien (plusieurs décennies)plus récent Tout l’enjeu est de comprendrece qu’ils décrivent / signifientcomment ils s’articulentMéthodeconstruire petit à petit une compréhension globale lire et relirechercher de l’information par soi mêmeposer des questionspratiquer2011-2012 / Yannick Prié - Université Claude Bernard Lyon 18

9. PlanAvant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 19

10. Génie logicielDéfinition ensemble de méthodes, techniques et outils pour la production et la maintenance de composants logiciels de qualitéPourquoi ?logiciels de plus en plus gros, technologies en évolution, architectures multiplesPrincipes rigueur et formalisation, séparation des problèmes, modularité, abstraction, prévision du changement, généricité, incréments2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)10

11. Qualité du logiciel (1)Facteur externes (utilisateur) Correction (validité)aptitude à répondre aux besoins et à remplir les fonctions définies dans le cahier des chargesRobustesse (fiabilité)aptitude à fonctionner dans des conditions non prévues au cahier des charges, éventuellement anormalesExtensibilitéfacilité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)11

12. Qualité du logiciel (2)Facteurs externes (suite)Compatibilitéfacilité avec laquelle un logiciel peut être combiné avec d’autresEfficacitéutilisation optimale des ressources matérielles (processeur, mémoires, réseau, …)Convivialitéfacilité d’apprentissage et d’utilisation, de préparation des données, de correction des erreurs d’utilisation, d’interprétation des retoursIntégrité (sécurité)aptitude d’un logiciel à se protéger contre des accès non autorisés.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)12

13. Qualité du logiciel (3)Facteurs internes (concepteur) Ré-utilisabilitéaptitude d’un logiciel à être réutilisé, en tout ou en partie, pour d’autres applicationsVérifiabilitéaptitude d’un logiciel à être testé (optimisation de la préparation et de la vérification des jeux d’essai)Portabilitéaptitude d’un logiciel à être transféré dans des environnements logiciels et matériels différentsLisibilitéModularité2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)13

14. Projet en général (1/2)Définitionensemble d’actions à entreprendre afin de répondre à un besoin défini (avec une qualité suffisante), dans un délai fixé, mobilisant des ressources humaines et matérielles, possédant un coût.Maître d’ouvrage personne physique ou morale propriétaire de l’ouvrage. Il détermine les objectifs, le budget et les délais de réalisation.Maître d’oeuvrepersonne physique ou morale qui reçoit mission du maître d’ouvrage pour assurer la conception et la réalisation de l’ouvrage.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)14

15. Projet en général (2/2)Conduite de projet organisation méthodologique mise en oeuvre pour faire en sorte que l’ouvrage réalisé par le maître d’oeuvre réponde aux attentes du maître d’ouvrage dans les contraintes de délai, coût et qualité.Direction de projetgestion des hommes : organisation, communication, animationgestion technique : objectifs, méthode, qualitégestion de moyens : planification, contrôle, coûts, délaisprise de décision : analyse, reporting, synthèse2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)15

16. Projet logicielProblème comment piloter un projet de développement logiciel ? Solutiondéfinir et utiliser des méthodes spécifiant des processus de développementorganisant les activités du projetdéfinissant les artefacts du projetse basant sur des modèles2011-2012 / Yannick Prié - Université Claude Bernard Lyon 116

17. Cycle de vie d’un logicielCycle de vie d’un logicieldébute avec la spécification et s'achève sur les phases d'exploitation et de maintenanceModèles de cycle de vieorganiser les différentes phases du cycle de vie pour l'obtention d'un logiciel fiable, adaptable et efficaceguider le développeur dans ses activités techniquesfournir des moyens pour gérer le développement et la maintenanceressources, délais, avancement, etc.Deux types principaux de modèlesModèle linéairesen cascade et variantesModèles non linéaires en spirale, incrémentaux, itératifs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(O. Boissier)17

18. Modèle en cascade2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Analyse des besoinsSpécificationConceptionAnnées 70Linéaire, flot descendantRetour limité à une phase en amontValidation des phases par des revuesÉchecs majeurs sur de gros systèmesdélais longs pour voir quelque chose qui tournetest de l’application globale uniquement à la findifficulté de définir tous les besoins au début du projetBien adapté lorsque les besoins sont clairement identifiés et stablesProduction ValidationMaintenance18

19. Modèle en V2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Expression des besoinsValidation des besoinsSpécification fonctionnelleValidation fonctionnelleConception du systèmeTests du systèmeConception des composantsTests des composantsImplémentationVariante du modèle en cascadeTests bien structurésHiérarchisation du système (composants)Validation finale trop tardive (très coûteuse s’il y a des erreurs)Variante : W (validation d’un maquette avant conception)19

20. Les problèmes ducycle en cascadeRisques élevés et non contrôlésidentification tardive des problèmespreuve tardive de bon fonctionnementGrand laps de temps entre début de fabrication et sortie du produitDécisions stratégiques prise au moment où le système est le moins bien connuNon-prise en compte de l’évolution des besoins pendant le cycle Les études montrent :25 % des exigences d’un projet type sont modifiées (35-50 % pour les gros projet) (Larman 2005)45% de fonctionnalités spécifiées ne sont jamais utilisées (Larman 2005, citant une étude 2002 sur des milliers de projets)le développement d’un nouveau produit informatique n’est pas une activité prévisible ou de production de massela stabilité des spécifications est une illusionDistinction entre activités trop strictemodèle théoriquement parfait, mais inadapté aux humains2011-2012 / Yannick Prié - Université Claude Bernard Lyon 120RisquePériode d’intégration et de testsTemps

21. Anti-cascadeNécessité de reconnaître que le changement est une constante (normale) des projets logicielsfeedback et adaptation : décision tout au long du processusconvergence vers un système satisfaisantIdées construction du système par incrémentsgestion des risquespassage d’une culture produit à une culture projetsouplesse de la démarche2011-2012 / Yannick Prié - Université Claude Bernard Lyon 121

22. Modèle en spirale2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1IdentificationEvaluationConstructionVérification/validationVers un système completIncréments successifs  itérationsApproche souvent à base de prototypesNécessite de bien spécifier les incrémentsFigement progressif de l’application Gestion de projet pas évidenteLes méthodesobjet en dérivent 22

23. Plan de ce cours Avant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 123

24. Qu’est ce qu’une méthode ?Définitionsguide plus ou moins formalisédémarche reproductible permettant d’obtenir des solutions fiables à un problème donnéCapitalise l’expérience de projets antérieurs les règles dans le domaine du problèmeUne méthode définitdes concepts de modélisation (obtenir des modèles à partir d’éléments de modélisation, sous un angle particulier, représenter les modèles de façon graphique)une chronologie des activités ( construction de modèles)un ensemble de règles et de conseils pour tous les participantsDescription d’une méthodedes gens, des activités, des résultats2011-2012 / Yannick Prié - Université Claude Bernard Lyon 124

25. Méthodes en génie logicielGrandes classes de méthodes (Bézivin)méthodes pour l’organisation stratégiqueméthodes de développementméthodes de conduite de projetméthodes d’assurance et de contrôle qualitéMéthodes de développement pourconstruire des systèmes opérationnelsorganiser le travail dans le projetgérer le cycle de vie completgérer les coûts (eg. Cocomo 2)gérer les risquesobtenir de manière répétitive des produits de qualité constante2011-2012 / Yannick Prié - Université Claude Bernard Lyon 125

26. ProcessusPour décrire qui fait quoi à quel moment et de quelle façon pour atteindre un certain objectifDéfinition ensemble de directives et jeu partiellement ordonné d’activités (d’étapes) destinées à produire des logiciels de manière contrôlée et reproductible, avec des coûts prévisibles, présentant un ensemble de bonnes pratiques autorisées par l’état de l’artDeux axesdéveloppement techniquegestion du développement2011-2012 / Yannick Prié - Université Claude Bernard Lyon 126

27. Artefacts d’un projetTout élément d'information utilisé ou généré pendant un cycle de développement d'un système logicielmorceau de code, commentaire, spécification statique d'une classe, spécification comportementale d'une classe, jeu de test, programme de test, interview d'un utilisateur potentiel du système, description du contexte d'installation matériel, diagramme d'une architecture globale, prototype, rapport de réalisation, modèle de dialogue, rapport de qualimétrie, manuel utilisateur…2011-2012 / Yannick Prié - Université Claude Bernard Lyon 127

28. Notation et artefactsNotation = formalisme graphique de représentation (e.g. UML) pour représenter de façon uniforme l'ensemble des artefacts logiciels produits ou utilisés pendant le cycle de développementpour faciliter la communication, l’organisation et la vérificationMéthode / processus types d’artefacts + notation + démarche (+ outils) façon de modéliser et façon de travailler 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 128

29. Évolution des méthodesOrigine : fin des années 60 problèmes de qualité et de productivité dans les grandes entreprises, mauvaise communication utilisateurs / informaticiensméthodes = guides pour l’analyse et aide à la représentation du futur SIconception par découpage en sous-problèmes, analytico-fonctionnelleméthodesd’analysestructuréeEnsuiteconception par modélisation : « construire le SI, c'estconstruiresa base de données » méthodesglobales qui séparentdonnées et traitementsMaintenantconception pour et par réutilisationFrameworks, Design Patterns, bibliothèques de classesméthodesexploitant un capital d'expériencesunifiées par une notation commune (UML)procédant de manièreincrémentalevalidant par simulation effective 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 129

30. 1ère générationModélisation par les fonctionsApproche dite « cartésienne »Décomposition d’un problème en sous-problèmesAnalyse fonctionnelle hiérarchique : fonctions et sous-fonctionsavec fonctions entrées, sorties, contrôles (proche du fonctionnement de la machine)les fonctions contrôlent la structure : si la fonction bouge, tout bougedonnées non centraliséesMéthodes de programmation structuréeIDEF0 puis SADTPoints faibles focus sur fonctions en oubliant les données, règles de décomposition non explicitées, réutilisation hasardeuse2011-2012 / Yannick Prié - Université Claude Bernard Lyon 130

31. 2ème générationModélisation par les donnéesApproches dites « systémiques »SI = structure + comportementModélisation des données et des traitementsprivilégie les flots de données et les relations entre structures de données (apparition des SGBD)traitements = transformations de données dans un flux (notion de processus)Exemple : MERISE plusieurs niveaux d’abstractionplusieurs modèlesPoints fortscohérence des données, niveaux d’abstraction bien définis. Points faiblesmanque de cohérence entre données et traitements, faiblesse de la modélisation de traitement (mélange de contraintes et de contrôles), cycles de développement trop figés (cascade)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 131

32. générationactuelleModélisationorientée-objetMutation due au changement de la nature des logicielsgestion > bureautique, télécommunicationsApproche « systémique » avec grande cohérence données/traitementsSystèmeensemble d’objets qui collaborentconsidérés de façonstatique (ceque le systèmeest : données) et dynamique (ceque le système fait : fonctions)évolutionfonctionnelle possible sans remise en cause de la structure statique du logicielDémarchepasser du monde des objets (du discours) àcelui de l’application en complétant des modèles (pas de transfert d’un modèleàl’autre)à la foisascendante et descendante, récursive, encapsulationabstraction forteorientéevers la réutilisation : notion de composants, modularité, extensibilité, adaptabilité (objets du monde), souplesExemples : nombreuxàpartir de la fin des années 802011-2012 / Yannick Prié - Université Claude Bernard Lyon 132

33. Plan de ce cours Avant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 133

34. Développement logiciel et activités Cinq grandes activités qui ont émergé de la pratique et des projets spécification des besoinsanalyseconceptionimplémentationtests2011-2012 / Yannick Prié - Université Claude Bernard Lyon 134

35. Activités : spécification des besoinsFondamentale mais difficileRègle d’orles informaticiens sont au service du client, et pas l’inverse Deux types d’exigencesExigences fonctionnellesà quoi sert le systèmece qu’il doit faireExigences non fonctionnellesperformance, sûreté, portabilité, etc.critères souvent mesurableNotion de conception participative2011-2012 / Yannick Prié - Université Claude Bernard Lyon 135

36. Besoins : modèle FURPS+Fonctionnalitésfonctions, capacité et sécuritéUtilisabilitéfacteurs humains, aide et documentationFiabilité (Reliability)fréquence des pannes, possibilité de récupération et prévisibilitéPerformancetemps de réponse, débit, exactitude, disponibilité et utilisation des ressourcesPossibilité de prise en charge (Supportability)adaptabilité, facilité de maintenance, internationalisation et configurabilité+implémentation : limitation des ressources, langages et outils, matériel, etc.interface : contraintes d’interfaçage avec des systèmes externesexploitation : gestion du système dans l’environnement de productionconditionnement aspects juridiques : attribution de licences, etc.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 136

37. Activités : analyse / conceptionUn seule chose est sûre : l’analyse vient avant la conceptionAnalyse plus liée à l’investigation du domaine, à la compréhension du problème et des besoins, au quoirecherche du bon systèmeConception plus liée à l’implémentation, à la mise en place de solutions, au commentconstruction du systèmeFrontière floue entre les deux activitéscertains auteurs ne les différencient paset doutent qu’il soit possible de distinguerd’autres placent des limites ex. : analyse hors technologie / conception orientée langage spécifique2011-2012 / Yannick Prié - Université Claude Bernard Lyon 137

38. Activités : implémentation / testsImplémentationdans un ou plusieurs langage(s)activité la plus coûteuseTeststests unitairesclasse, composanttest du système intégrénon régressionce qui était valide à un moment doit le resterimpossible à réaliser sans outils2011-2012 / Yannick Prié - Université Claude Bernard Lyon 138

39. Plan de ce cours Avant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 139

40. Outils et processusUne méthode spécifie des activités des artefacts à réaliserIl est souvent vital de disposer d’outil(s) soutenant le processus enpilotant / permettant les activitésgérant les artefacts du projetLes outils peuvent être plus ou moinsintégrés à la méthodeinter-opérablesachetés / fabriqués / transformés… 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 140

41. Des outils pour gérer un projet (1)Outils de planificationOutils de gestion des versionsOutils de gestion de documentationOutils de maquettageOutils de gestion des tests2011-2012 / Yannick Prié - Université Claude Bernard Lyon 141

42. Des outils pour gérer un projet (2)Outils de modélisationpro, rétro, roundtripAteliers de développement logicielOutils de vérificationOutils de communication…2011-2012 / Yannick Prié - Université Claude Bernard Lyon 142

43. Plan de ce cours Avant-proposGénie logicielMéthodesActivitésOutilsDocumentation de projetSpécification fonctionnellesDocument d’Architecture logicielle2011-2012 / Yannick Prié - Université Claude Bernard Lyon 143

44. Cahier des chargesSpécification d’un système à réaliserFonctionnalités, description du contexte, contraintes de délais, de prix, préférences…Document très importantPermet de se mettre d’accord en interne sur le système à construirePermet de lancer un appel d’offreEst une partie du contrat entre le demandeur et le prestataireSert de base et de guide au chef de projet…2011-2012 / Yannick Prié - Université Claude Bernard Lyon 144

45. Cahier des charges fonctionnelPréciser les orientations et le champ du domaine étudié,Analyser l'existant au niveau organisation, documents utilisés, traitements effectués, données manipulées,Proposer des solutions d'organisation, fonctionnelles et techniques répondant aux exigences et besoins exprimés,2011-2012 / Yannick Prié - Université Claude Bernard Lyon 145http://www.dsi.cnrs.fr/conduite-projet/

46. Cahier des charges fonctionnel Obtenir une description globale du système (organisationnelle, fonctionnelle, technique, contraintes majeures de sécurité, de performance, interfaces avec d'autres systèmes...),Vérifier la faisabilité organisationnelle et technique,Aboutir à un choix argumenté d'une solution type de développement.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 146http://www.dsi.cnrs.fr/conduite-projet/

47. Spécifications fonctionnellesBesoins fonctionnels métierListe de fonctions que le système devra remplirScénariosCas d’utilisation…Ne pas parler de réalisation technique2011-2012 / Yannick Prié - Université Claude Bernard Lyon 147

48. Spécifications techniquesComment réaliser les chosesListe de fonctions à coderArchitecture...Attentionle mélange technique / métier est facile à faire !Un exemple http://www.pcinpact.com/actu/news/63190-hadopi-specification-fonctionnelles.htm2011-2012 / Yannick Prié - Université Claude Bernard Lyon 148

49. Architecture ?Difficile à définirEx. bâtiment : plombier, électricien, peintre, ne voient pas la même chose.DéfinitionsSoftware architecture is not onlyconcernedwith structure and behavior, but alsowith usage, functionality, performance, resilience, reuse, comprehensibility, economic and technologicalconstraints and tradeoffs, and esthetics. (RUP, 98)A Technical Architecture is the minimal set of rulesgoverning the arrangement, interaction, and interdependance of the parts or elementsthattogethermaybeused to form an information system. (U.S. Army 1996)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 149

50. ArchitectureDéfinition pour ce coursart d’assembler des composants en respectant des contraintes, ensemble des décisions significatives surl’organisation du systèmeles éléments qui structurent le systèmela composition des sous-systèmes en systèmesle style architectural guidant l’organisation (couches…)ensemble des éléments de modélisation les plus signifiants qui constituent les fondations du système à développer2011-2012 / Yannick Prié - Université Claude Bernard Lyon 150

51. Facteurs influençant l’architecture2011-2012 / Yannick Prié - Université Claude Bernard Lyon 151ExpérienceDomaine d’applicationCapacités d’évolutionCas d’utilisationContraintesnon fonctionnellesRéutilisationArchitectureStandards imposés, politique d’entrepriseIHMMiddleware, frameworkSystème support(SE, SGBD)Systèmes existantsPoints à considérer Performances, qualité, testabilité, convivialité, sûreté, disponibilité, extensibilité, exactitude, tolérance aux changements, robustesse, facilité de maintenance, fiabilité, portabilité, risque minimum, rentabilité économique…

52. Axes pour considérer l’architectureArchitecture logicielle (ou architecture logique) :organisation à grande échelle des classes logicielles en packages, sous-systèmes et couchesarchitectures client/serveurs en niveaux (tiers)architectures en couches architecture à base de composantsArchitecture de déploiement décision de déploiement des différents élémentsdéploiement des fonctions sur les postes de travail des utilisateurs (entreprise : central/départemental/local)Existence de patterns architecturaux2011-2012 / Yannick Prié - Université Claude Bernard Lyon 152

53. Description de l’architecture (1)L’architecture doit être une vision partagéesur un système très complexe pour guider le développement tout en restant compréhensibleIl faut donc mettre en place une description (ou documentation) explicite de l’architecturequi servira de référence jusqu’à la fin du cycle (et après)qui doit rester aussi stable que l’architecture de référence2011-2012 / Yannick Prié - Université Claude Bernard Lyon 153

54. Description de l’architecture (2)Comment décrire l’architecture ? décrire les facteurs qui influencent l’architecturefacteurs architecturauxdécrire les choix qui ont été faitsmémos techniquesdécrire l’architecturedocument d’architecture du logiciel 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 154(Larman, 2004)

55. Description de l’architecture : Facteurs architecturauxFacteurs qui ont une influence significative sur l’architecture fonctionnalités, performance, fiabilité, facilité de maintenance, implémentation et interface, etc.Un facteur architectural doit être identifié et décrit dans une fiche2011-2012 / Yannick Prié - Université Claude Bernard Lyon 155(Larman, 2004) Nomex. : « fiabilité, possibilité de récupération » Mesures et scénarios de qualitéce qu’il doit se passer et comment le vérifierex. : « si problème, récupération dans la minute » Variabilitésouplesse actuelle et évolutions futuresex. : «pour l’instant service simplifiés acceptables en cas de rupture, évolution : services complets » Impactspour les parties prenantes, l’architecture…ex. : « fort impact, rupture de service non acceptable » Prioritéex. : élevée Difficulté ou risque ex. : moyen

56. Description de l’architecture Mémos techniquesLes choix architecturaux doivent prendre en compte les facteurs architecturauxIl est important de décrire les solutions choisies et leur motivationassurer la traçabilité des décisions architecturales raisons des choix alternatives étudiées, etc.Les « mémos techniques » décrivent les choix architecturaux

57. texte + diagrammes2011-2012 / Yannick Prié - Université Claude Bernard Lyon 156(Larman, 2004)Mémo technique : Nom du problème étudié

58. Résumé de la solution choisie

59. Facteurs architecturaux concernés

60. Solution

61. Motivation

62. Problèmes non résolus

63. Autres solutions envisagéesDescription de l’architecture Vue architecturalevue de l’architecture du système depuis un point de vue particuliertexte + diagrammesse concentre sur les informations essentielles et documente la motivation« ce que vous diriez en 1 minute dans un ascenseur à un collègue »description a posteriori 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 157(Larman, 2004)

64. DAL :Document d’architecture du logiciel= récapitulatif des décisions architecturalesRésumé rapide de l’architecture 1 diagramme + texteFacteurs architecturaux quels sont les points qui ont eu une influence importante sur les choix d’architecture ?Ensemble de vues architecturales description du matériel et du logiciel utilisésMémos techniquesquelles sont les décisions qui ont été prises, pourquoi, etc.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 158http://www.codingthearchitecture.com/pages/book/software-architecture-document-guidelines.html