Objectifs de ce cours

Processus de conception de SI ! Notion de méthode de conception de SI

! Méthodes OO de conception
– Généralités sur les méthodes
– Processus unifié
• description générale
M1 MIAGE - SIMA - 2005-2006 • exemples de déclinaisons
Yannick Prié – Processus AGILE
UFR Informatique - Université Claude Bernard Lyon 1

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 2

Plan Plan
! Introduction ! Avant-propos
! Méthodes et processus ! Méthodes et processus
! Processus unifié : caractéristiques ! Processus unifié : caractéristiques
essentielles essentielles
! Description du processus unifié ! Description du processus unifié
! Illustration : deux déclinaisons du ! Illustration : deux déclinaisons du
processus unifiés processus unifié
! Méthodes Agile ! Méthodes Agile
! Conclusion ! Conclusion

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 3 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 4

(B. Morand)

Ce qu’il faut aimer pour arriver à

UML : No silver bullet concevoir
! Connaître UML (ou maîtriser un AGL) n’est pas ! Être à l’écoute du monde extérieur
suffisant pour réaliser de bonnes conceptions ! Dialoguer et communiquer avec les gens qui utiliseront le
– malgré ce que le marketing peut affirmer système
– UML n’est qu’un langage ! Observer et expérimenter : une conception n’est jamais
! Il faut en plus bonne du premier coup
– savoir penser / coder en termes d’objets ! Travailler sans filet : en général, il y a très peu de recettes
• maîtriser des techniques de conception et de toutes faites
programmation objet ! Abstraire
– avoir un certain nombre de qualités ! Travailler à plusieurs : un projet n’est jamais réalisé tout
! Méthodes de conception seul
– propositions de cheminements à suivre pour concevoir ! Aller au résultat : le client doit être satisfait, il y a des enjeux
– pas non plus de méthode ultime (= nouvelle silver bullet) financiers
• certains bon principes se retrouvent cependant partout

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 5 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 6
Avertissement Plan
! Beaucoup de concepts dans ce cours ! Avant-propos
– proviennent du domaine du développement logiciel
• ancien (plusieurs décennies)
! Méthodes et processus
• plus récent ! Processus unifié : caractéristiques
! Tout l’enjeu est de comprendre essentielles
– ce qu’ils décrivent / signifient
! Description du processus unifié
– comment ils s’articulent
! Méthode ! Illustration : deux déclinaisons du
– construire petit à petit une compréhension globale processus unifié
• lire et relire ! Méthodes Agile
• chercher de l’information par soi même
• poser des questions ! Conclusion
• pratiquer

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 7 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 8

(O. Boissier) (O. Boissier)

Génie logiciel Projet en général

! Définition
! Définition – ensemble d’actions à entreprendre afin de répondre à un besoin défini (avec
une qualité suffisante), dans un délai fixé, mobilisant des ressources humaines
– ensemble de méthodes, techniques et outils pour la et matérielles, possédant un coût.
production et la maintenance de composants logiciels ! Maître d’ouvrage
– personne physique ou morale propriétaire de l’ouvrage. Il détermine les objectifs,
de qualité le budget et les délais de réalisation.

! Pourquoi ? ! Maître d’oeuvre

– personne physique ou morale qui reçoit mission du maître d’ouvrage pour
– logiciels de plus en plus gros, technologies en assurer la conception et la réalisation de l’ouvrage.
évolution, architectures multiples ! Conduite de projet
– organisation méthodologique mise en oeuvre pour faire en sorte que l’ouvrage
! Principes 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é.
– rigueur et formalisation, séparation des problèmes, ! Direction de projet
modularité, abstraction, prévision du changement, – gestion des hommes : organisation, communication, animation
– gestion technique : objectifs, méthode, qualité
généricité, utilisation d’incréments – gestion de moyens : planification, contrôle, coûts, délais
– prise de décision : analyse, reporting, synthèse

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 9 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 10

(O. Boissier)

Projet logiciel Modèles de cycle de vie d’un logiciel

! Cycle de vie d’un logiciel
! Problème – débute avec la spécification et s'achève sur les phases
d'exploitation et de maintenance
– comment piloter un projet logiciel ? ! Modèles de cycle de vie
! Solution – organiser les différentes phases du cycle de vie pour
l'obtention d'un logiciel fiable, adaptable et efficace
– définir et utiliser des méthodes – guider le développeur dans ses activités techniques
• spécifiant des processus de développement – fournir des moyens pour gérer le développement et la
maintenance
• organisant les activités du projet • ressources, délais, avancement, etc.
• définissant les artefacts du projet ! Modèles linéaires
– en cascade et variantes
• se basant sur des modèles
! Modèles non linéaires
– en spirale, incrémentaux, itératifs

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 11 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 12
Modèle en cascade Modèle en V
Expression des besoins Validation des besoins

Analyse des besoins

Spécification fonctionnelle Validation fonctionnelle
Spécification

Conception Conception du système Tests du système

! Années 70 Production
! Linéaire, flot descendant Validation
Conception des composants Tests des composants

! Retour limité à une phase en amont

Maintenance
Implémentation
! Validation des phases par des revues
! Échecs majeurs sur de gros systèmes
– délais longs pour voir quelquechose ! Variante du modèle en cascade
– test de l’application globale ! Tests bien structurés
– difficulté de définir tous les besoins au début du projet ! Hiérarchisation du système (composants)
! Bien adapté lorsque les besoins sont clairement identifiés et stables ! Validation finale trop tardive (très coûteuse s’il y a des erreurs)
! Variante : W (validation d’un maquette avant conception)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 13 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 14

Modèle en spirale Méthode en général

Identification Evaluation

! Définition
– guide plus ou moins formalisé, démarche reproductible
permettant d’obtenir des solutions fiables à un problème
– capitalise l’expérience de projets antérieurs et les règles dans
le domaine du problème
Vers un système
complet
! Une méthode définit
– des 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)
Construction
– une chronologie des activités (" construction de modèles)
Vérification/validation
– un ensemble de règles et de conseils pour tous les participants
! Incréments successifs ! itérations
! Description d’une méthode
! Approche souvent à base de prototypes
– des gens, des activités, des résultats
! Spécification des incréments difficile
! De plus en plus difficile de modifier
! Gestion de projet pas évidente
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 15 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 16

Pour le génie logiciel Processus

! Grandes classes (Bézivin) ! Qui fait quoi à quel moment et de quelle façon
– organisation stratégique pour atteindre un certain objectif
– méthodes de développement
– méthodes de conduite de projet
! Ensemble de directives et jeu partiellement
– méthode d’assurance et de contrôle qualité
ordonné d’activités (d’étapes) destinées à
! Méthode de développement produire des logiciels de manière contrôlée et
– construire des systèmes opérationnels reproductible, avec des coûts prévisibles,
– organiser le travail dans le projet présentant un ensemble de bonnes pratiques
– gérer le cycle de vie complet autorisées par l’état de l’art.
– gérer les risques ! Deux axes
– obtenir de manière répétitive des produits de qualité constante – développement technique
! Processus – gestion du développement
– soit à peu près la même chose (spécification)
– soit la réalisation effective du travail (cf. processus métier)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 17 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 18
Notation et artefacts Évolution des méthodes
! Notation ! Origine : fin des années 60
– permet de représenter de façon uniforme l'ensemble des artefacts – problèmes de qualité et de productivité dans les grandes entreprises,
logiciels produits ou utilisés pendant le cycle de développement mauvaise communication utilisateurs / informaticiens
– formalisme de représentation qui facilite la communication, – méthodes = guides pour l’analyse et aide à la représentation du futur SI
l’organisation et la vérification – conception par découpage en sous-problèmes, analytico-fonctionnelle
! Artefact – méthodes d’analyse structurée
– tout élément d'information utilisé ou généré pendant la totalité du cycle ! Ensuite
de développement d'un système logiciel – conception par modélisation : « construire le SI, c'est construire sa base
– facilite les retours sur conception et l’évolution des applications de données »
– Exemple: morceau de code, commentaire, spécification statique d'une – méthodes globales qui séparent données et traitements
classe, spécification comportementale d'une classe, jeu de test,
programme de test, interview d'un utilisateur potentiel du système, ! Maintenant
description du contexte d'installation matériel, diagramme d'une – conception pour et par réutilisation
architecture globale, prototype, rapport de réalisation, modèle de • Frameworks, Design Patterns, bibliothèques de classes
dialogue, rapport de qualimétrie, manuel utilisateur… – méthodes
! Méthode / processus • exploitant un capital d'expériences
– notation + démarche (+ outils) • unifiées par une notation commune (UML)
• procédant de manière incrémentale
– façon de modéliser et façon de travailler
• validant par simulation effective

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 19 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1

Modélisation par les fonctions Modélisation par les données

! Approches dites « systémiques »
! Approche dite « cartésienne »
! SI = structure + comportement
! Décomposition d’un problème en sous-problèmes ! Modélisation des données et des traitements
! Analyse fonctionnelle hiérarchique : fonctions et sous- – privilégie les flots de données et les relations entre structures de données
fonctions (apparition des SGBD)
– avec fonctions entrées, sorties, contrôles (proche du – traitements = transformations de données dans un flux (notion de
fonctionnement de la machine) processus)
– les fonctions contrôlent la structure : si la fonction bouge, tout ! Exemple : MERISE
bouge – plusieurs niveaux d’abstraction
– données non centralisées – plusieurs modèles
! Méthodes de programmation structurée ! Points forts
– IDEF0 puis SADT – cohérence des données, niveaux d’abstraction bien définis.
! Points faibles ! Points faibles
– focus sur fonctions en oubliant les données, règles de – manque de cohérence entre données et traitements, faiblesse de la
décomposition non explicitées, réutilisation hasardeuse modélisation de traitement (mélange de contraintes et de contrôles), cycles
de développement trop figés (cascade)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 21 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1

Modélisation orientée-objet Développement logiciel et activités

! Mutation due au changement de la nature des logiciels
– gestion > bureautique, télécommunications ! Ces activités émergent de la pratique
! Approche « systémique » avec grande cohérence données/traitements
! Système / des projets
– ensemble d’objets qui collaborent
– considérés de façon statique (ce que le système est : données) et – spécification des besoins
dynamique (ce que le système fait : fonctions)
– évolution fonctionnelle possible sans remise en cause de la structure – analyse
statique du logiciel
! Démarche – conception
– passer 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) – implémentation
– à la fois ascendante et descendante, récursive, encapsulation
– abstraction forte – tests
– orientée vers la réutilisation : notion de composants, modularité,
extensibilité, adaptabilité (objets du monde), souples
! Exemples : nombreux à partir de la fin des années 80

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 24
Activités : spécification des besoins Besoins : modèle FURPS+
! Fonctionnalités
– fonctions, capacité et sécurité
! Fondamentale mais difficile ! Utilisabilité
! Règle d’or – facteurs humains, aide et documentation
! Fiabilité
– les informaticiens sont au service du client, et – fréquence des pannes, possibilité de récupération et prévisibilité
pas l’inverse ! Performance
! Exigences fonctionnelles – temps de réponse, débit, exactitude, disponibilité et utilisation des ressources
! Possibilité de prise en charge
– à quoi sert le système – adaptabilité, facilité de maintenance, internationalisation et configurabilité
– ce qu’il doit faire ! +
– implémentation : limitation des ressources, langages et outils, matériel, etc.
! Exigences non fonctionnelles – interface : contraintes d’interfaçage avec des systèmes externes
– exploitation : gestion du système dans l’environnement de production
– performance, sûreté, portabilité, etc.
– conditionnement
– critères souvent mesurables – aspects juridiques : attribution de licences, etc.

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 25 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 26

Activités : analyse / conception Activités : implémentation / tests

! Un seule chose est sûre : ! Implémentation
– l’analyse vient avant la conception
! Analyse
– dans un ou plusieurs langage(s)
– plus liée à l’investigation du domaine, à la compréhension du – activité la plus coûteuse
problème et des besoins, au quoi
– recherche du bon système
! Tests
! Conception – tests unitaires
– plus liée à l’implémentation, à la mise en place de solutions, au • classe, composant
comment
– test du système intégré
– construction du système
! Frontière floue entre les deux activités – non régression
– certains auteurs ne les différencient pas • ce qui était valide à un moment doit le rester
• et doutent qu’il soit possible de distinguer • impossible à réaliser sans outils
– d’autres placent des limites
• ex. : analyse hors technologie / conception orientée langage spécifique

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 27 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 28

Outils et processus Des outils pour gérer un projet

! Une méthode spécifie ! Outils de planification
– des activités ! Outils de gestion des versions
– des artefacts à réaliser ! Outils de gestion de documentation
! Il est souvent vital de disposer d’outil(s) ! Outils de maquettage
soutenant le processus en
! Outils de gestion des tests
– pilotant / permettant les activités
– gérant les artefacts du projet ! Outils de modélisation
– pro, rétro, roundtrip
! Les outils peuvent être plus ou moins
– intégrés à la méthode ! Ateliers de développement logiciel
– interopérables ! Outils de vérification
– achetés / fabriqués / transformés… ! …
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 29 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 30
 Processus unifié : caractéristiques
Plan
essentielles
! Avant-propos ! Dans cette partie
! Méthodes et processus – trame du processus
! Processus unifié : caractéristiques – itératif et incrémental
essentielles – piloté par les besoins
! Description du processus unifié – piloté par les risques
! Illustration : deux déclinaisons du – centré sur l’architecture
processus unifié ! Partie suivante
! Méthodes Agile – activités, métiers et artefacts
! Conclusion – phases d’un projet UP

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 31 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 32

Unified Software Development Process /

Unified Process (UP)
USDP
! Beaucoup de méthodes ! Un processus capable de
– liées à des outils, à l’adaptation à UML (comme langage de – dicter l’organisation des activités de l’équipe
notation) de méthodes pré-existantes , aux entreprises, etc. – diriger les tâches de chaque individu et de l’équipe dans son
– …finalement, autant de méthodes que de concepteurs / projets ensemble
– spécifier les artefacts à produire
! USDP : Rumbaugh, Booch, Jacobson (les concepteurs
– proposer des critères pour le contrôle de produits et des
d’UML) activités de l’équipe
– purement objet ! Bref
– prend de la hauteur par rapport à RUP (Rational) – gérer un projet logiciel de bout en bout
– méthode / processus ! Regroupement de bonnes pratiques, mais
– regroupement des meilleures pratiques de développement – non figé
! Ici : beaucoup généralités liées à USDP, qui s’appliquent à – générique (hautement adaptable : individus, cultures, …)
peu près à toute méthode objet • choisir un UP (« cas de développement » dans RUP) qui
correspond au projet du moment, appliquer
• seul un expert peut en décider

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 33 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 34

Phases 1 / 2
Cycles de vie et phases étude préliminaire et élaboration
Cycle 1 Cycle 2 Cycle 3 ! Étude préliminaire
– que fait le système ?
– à quoi pourrait ressembler l’architecture ?
– quels sont les risques ?
Étude – quel est le coût estimé du projet ? Comment le planifier ?
Élaboration Construction Transition
préliminaire – accepter le projet ?
Phases – jalon : « vision du projet »
! Élaboration
! Considérer un produit logiciel quelconque par rapport à ses – spécification de la plupart des cas d’utilisation
versions – conception de l’architecture de base (squelette du système)
– un cycle produit une version – mise en œuvre de cette architecture (CU critiques, <10 % des besoins)
! Gérer chaque cycle de développement comme un projet ayant – planification complète
quatre phases – besoins, architecture, planning stables ? Risques contrôlés ?
– vue gestionnaire (manager) – jalon : « architecture du cycle de vie »
– chaque phase se termine par un point de contrôle (ou jalon) ! Remarque
permettant aux chefs de projet de prendre des décisions – phases (surtout préliminaire) effectuées à coût faible

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 35 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 36
Phases 3 / 4
construction et transition
Phases et activités
temps

! Construction activités Étude Élaboration Construction Transition

– développement par incréments préliminaire
• architecture stable malgré des changements mineurs
– le produit contient tout ce qui avait été planifié Capture
• il reste quelques erreurs des besoin
– produit suffisamment correct pour être installé chez un client ? Analyse
– jalon : « capacité opérationnelle initiale »
! Transition Conception

– produit livré (version bêta) Réalisation

– correction du reliquat d’erreurs
– essai et amélioration du produit, formation des utilisateurs, installation Test
de l’assistance en ligne
– tests suffisants ? Produit satisfaisant ? Manuels prêts ?
! Le cycle met en jeu des activités
– jalon : « livraison du produit »
– vue du développement sous l’angle technique (développeur)
! Remarque
– les activités sont réalisées au cours des phases, avec des
– construction = phase la plus coûteuse (> 50% du cycle), englobe
conception/codage/tests/intégration) importances variables

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 37 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 38

Processus unifié : caractéristiques

Modèles d’un projet USDP
! Les activités consistent à créer (entre autres) des modèles
essentielles
! Dans cette partie
– trame du processus
– itératif et incrémental
Modèle Modèle Modèle
des cas d’analyse de conception – piloté par les besoins
d’utilisation
– piloté par les risques
– centré sur l’architecture
! Partie suivante
Modèle
– activités, métiers et artefacts
de test – phases d’un projet UP
Modèle
Modèle
d’implémentation
de déploiement

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 39 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 40

Risque
Période
Les problèmes du d’intégration
et de tests
Anti-cascade
cycle en cascade ! Point commun à toutes les méthodes OO
! Risques élevés et non contrôlés ! Nécessité de reconnaître que le changement est une
– identification tardive des problèmes
Temps constante (normale) des projets logiciels
– preuve tardive de bon fonctionnement – feedback et adaptation
! Grand laps de temps entre début de fabrication et sortie du produit – convergence vers un système satisfaisant
! Décisions stratégiques prise au moment où le système est le moins ! Idées
bien connu
– construction du système par incréments
! Non-prise en compte de l’évolution des besoins pendant le cycle
– gestion des risques
! Les études montrent :
– passage d’une culture produit à une culture projet
– 25 % des exigences d’un projet type sont modifiées (35-50 % pour les
gros projet) (Larman 2005) – souplesse de la démarche
– 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 Cycle 1 Cycle 2 Cycle 3
activité prévisible ou de production de masse
– la stabilité des spécifications est une illusion
! Distinction entre activités trop stricte
Itération 1 Itération 2 Itération 3 … Itération n
– modèle théoriquement parfait, mais inadapté aux humains
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 41 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 42
Itérations et incréments Itérations et phases
temps
! Des itérations
activités Étude Élaboration Construction Transition
– chaque phase comprend des itérations préliminaire
– une itération a pour but de maîtriser une partie des risques et
apporte une preuve tangible de faisabilité Capture
• produit un système partiel opérationnel (exécutable, testé et des besoin
intégré) avec une qualité égale à celle d’un produit fini
• qui peut être évalué
– permet de savoir si on va dans une bonne direction ou non
Analyse

! Un incrément par itération

Conception
– le logiciel et le modèle évoluent suivant des incréments
• série de prototypes qui vont en s’améliorant
– de plus en plus de parties fournies Réalisation
– retours utilisateurs
• processus incrémental Test
– les versions livrées correspondent à des étapes de la chaîne des
prototypes Itération 1 Itér 2 Itér… Itér… Itér… Itér… Itér…

itérations
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 43 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 44

Avantages d’un processus itératif et incrémental

Itérations et risque
! Gestion de la complexité
– pas tout en même temps, Étalement des décisions importantes
! Une itération
! Maîtrise des risques élevés précoce
– est un mini-projet
– diminution de l’échec
• plan pré-établi et objectifs pour le prototype, critères d’évaluation,
– architecture mise à l’épreuve rapidement (prototype réel)
– comporte toutes les activités (mini-cascade)
! Intégration continue
– est terminée par un point de contrôle
– progrès immédiatement visibles
• ensemble de modèles agréés, décisions pour les itérations suivantes
– maintien de l’intérêt des équipes (court terme, prototypes vs
– conduit à une version montrable implémentant un certain nombre de CU documents)
– dure entre quelques semaines et 9 mois (au delà : danger) ! Prise en compte des modifications de besoins
• butée temporelle qui oblige à prendre des décisions
– feedback, implication des utilisateurs et adaptation précoce
! On ordonne les itérations à partir des priorités établies pour les cas ! Apprentissage rapide de la méthode
d’utilisation et de l’étude du risque – amélioration de la productivité et de la qualité du logiciel
– plan des itérations ! Adaptation de la méthode
– chaque prototype réduit une part du risque et est évalué comme tel – possibilité d'explorer méthodiquement les leçons tirées d'une itération
– les priorités et l’ordonnancement de construction des prototypes peuvent (élément à conserver, problèmes, éléments à essayer…)
changer avec le déroulement du plan ! Mais gestion de projet plus complexe : planification adaptative

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 45 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 46

Processus unifié : caractéristiques

Un processus piloté par les besoins
essentielles
! Dans cette partie ! Objectif du processus
– trame du processus – construction d’un système qui réponde à des besoins
– par construction complexe de modèles
– itératif et incrémental
! Cas d’utilisation
– piloté par les besoins
– expression / spécification des besoins
– centré sur l’architecture
• que fait le système, pour qui, dans quel environnement ?
! Partie suivante – utilisation tout au long du cycle
– activités, métiers et artefacts • validation des besoins / utilisateurs
• point de départ pour l’analyse (découverte des objets, de leurs
– phases d’un projet UP
relations, de leur comportement) et la conception (sous-systèmes)
• guide pour la construction des interfaces
• guide pour la mise au point des plans de tests

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 47 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 48
 Les CU lient les modèles Avantages des cas d’utilisation
! Centrés utilisateurs
– support de communication en langue naturelle entre utilisateurs et
Besoins spécifié par concepteurs basé sur les scénarios (et non liste de fonctions)
Modèle – dimension satisfaction de l’utilisateur (vs fonction intéressante à
des cas réalisé par ajouter)
d’utilisation distribué par • également pour les utilisateurs informaticiens (administration)
Analyse
Modèle – besoins fonctionnels en boîte noire, pour acteurs humains et non
d’analyse humains à identifier précisément
implémenté par ! Assurent la traçabilité par rapport aux besoins de toute décision de
Conception Modèle Modèle conception sur l’ensemble du projet
de conception de déploiement
– tout modèle s’y réfère
vérifié par
! Assurent le lien pour une vision commune des membres du projet
Implémentation sur l’architecture
Modèle
d’implémentation ! Attention
– créer de bons CU est un art
Tests Modèle – danger de décomposition fonctionnelle des CU qui reviendrait à une
de test conception fonctionnelle à l’ancienne

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 49 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 50

Processus unifié : caractéristiques

Processus piloté par les risques
essentielles
! Dans cette partie ! Nature des risques
– besoins / technique / autres
– trame du processus
! Exemples
– itératif et incrémental
– le système construit n’est pas le bon
– piloté par les besoins – architecture inadaptée, utilisation de technologies mal
– piloté par les risques maîtrisées, performances insuffisantes
– centré sur l’architecture – personnel insuffisant, problèmes commerciaux ou financiers
(risques non techniques, mais bien réels)
! Partie suivante ! Gestion des risques
– activités, métiers et artefacts – identifier et classer les risques par importance
– phases d’un projet UP – agir pour diminuer les risques
• Ex. changer les besoins, confiner la portée à une petite partie du
projet, faire des test pour vérifier leur présence et les éliminer
– s’ils sont inévitables, les évaluer rapidement
• tout risque fatal pour le projet est à découvrir au plus tôt

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 51 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 52

Processus unifié : caractéristiques

Risques et itérations
! Principe de pilotage par les risques
essentielles
– identification, listage et évaluation de dangerosité ! Dans cette partie
– construire les itérations en fonction des risques
– trame du processus
– s’attaquer en priorité aux risques les plus importants qui menacent le
plus la réussite du projet : « provoquer des changements – itératif et incrémental
précoces ») – piloté par les besoins
• ex. stabiliser l’architecture et les besoins liés le plus tôt possible
– piloté par les risques
Risque – centré sur l’architecture
Inception Cascade Période d’intégration
! Partie suivante
et de tests
Élaboration
– activités, métiers et artefacts
Itératif – phases d’un projet UP

Construction

Transition

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 53

Temps/itérations M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 54
Architecture ? Quelques axes pour considérer
! Difficile à définir
l’architecture
– exemple du bâtiment : plombier, électricien, peintre, etc.
! Architectures client/serveurs en niveaux
! Définitions – aussi appelés tiers
– Software architecture is not only concerned with structure and behavior, but ! Architectures en couches
also with usage, functionality, performance, resilience, reuse, – Présentation, Application, Domaine/métier, Infrastructure métier (services métiers de
comprehensibility, economic and technological constraints and tradeoffs, bas-niveau), Services techniques (ex. sécurité), Fondation (ex. accès et stockage
and esthetics. (RUP, 98) des données)
– A Technical Architecture is the minimal set of rules governing the ! Architectures en zones de déploiement
arrangement, interaction, and interdependance of the parts or elements – déploiement des fonctions sur les postes de travail des utilisateurs (entreprise :
that together may be used to form an information system. (U.S. Army 1996) central/départemental/local)
! Pour nous ! Architectures à base de composants
– art d’assembler des composants en respectant des contraintes, ensemble – réutilisation de composants
des décisions significatives sur ! On pourra parler
• l’organisation du système – d’architecture logicielle (ou architecture logique) : organisation à grande échelle des
• les éléments qui structurent le système classes logicielles en packages, sous-systèmes et couches
• la composition des sous-systèmes en systèmes – d’architecture de déploiement : décision de déploiement des différents éléments
• le style architectural guidant l’organisation (couches…) ! Notion de patterns architecturaux
– ensemble des éléments de modélisation les plus signifiants – ex. : Couches, MVC…
qui constituent les fondations du système à développer

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 55 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 56

Processus centré sur l’architecture Facteurs influençant l’architecture

Domaine d’application Expérience
! Les cas d’utilisation ne sont pas suffisants comme lien pour
l’ensemble des membres du projet Cas d’utilisation Capacités d’évolution
! L’architecture joue également ce rôle, en insistant sur la
réalisation concrète de prototypes incrémentaux qui Contraintes
« démontrent » les décisions prises non fonctionnelles Réutilisation
Architecture
! D’autre part
– plus le projet avance, plus l’architecture est difficile à modifier Standards imposés,
IHM
politique d’entreprise
– les risques liés à l’architecture sont très élevés, car très coûteux
! Objectif pour le projet Middleware,
Systèmes existants Système support
– établir dès la phase d’élaboration des fondations solides et (SE, SGBD) framework
évolutives pour le système à développer, en favorisant la
réutilisation
– l’architecture s’impose à tous, contrôle les développements ! Points à considérer
ultérieurs, permet de comprendre le système et d’en gérer la Performances, qualité, testabilité, convivialité, sûreté, disponibilité,
complexité extensibilité, exactitude, tolérance aux changements, robustesse,
! L’architecture est contrôlée et réalisée par l’architecte du projet facilité de maintenance, fiabilité, portabilité, risque minimum,
rentabilité économique…
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 57 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 58

Principe de construction Principe de construction

! Architecture ! Méthode (suite)
– forme dans laquelle le système doit s’incarner – ensuite : construction de l’architecture de référence
• les CU réalisés doivent y trouver leur place / la réalisation • confrontation un à un des cas d’utilisation les plus
des CU suivant doit s’appuyer sur l’architecture. significatifs à l’ébauche, construction de parties de
– doit promouvoir la réutilisation l’application réelle (sous-systèmes spécifiques),
– doit ne pas trop changer : converger vers une bonne l’architecture se stabilise autour des fonctions essentielles
architecture rapidement (sous-ensemble des CU). Traiter les besoins non
fonctionnel dans le contexte des besoins fonctionnels.
! Méthode Identifier les points de variation et les points d'évolution les
– d’abord : choix d’une architecture de haut-niveau et plus probables.
construction des parties générales de l’application – enfin : les cas d’utilisation sont réalisés incrémentalement
• ébauche à partir de solutions existantes et de la • l’architecture continue à se stabiliser sans changement
compréhension du domaine, parties générales aux majeur, contribue à la maturation des cas d’utilisation
applications du domaine (quasi-indépendant des CU), choix
de déploiement
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 59 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 60
 Architecture et élaboration Description de l’architecture
! L’architecture doit être une vision partagée sur un système très
! Phase d’élaboration complexe qui permet de guider le développement
– aller directement vers une architecture robuste, à coût limité, – elle doit aussi rester compréhensible
architecture de référence ! Mettre en place une description (ou documentation) explicite de
– 10% des classes suffisent (ce qui est à l’intérieur des sous- l’architecture, servira de référence jusqu’à la fin du cycle et après, et
systèmes n’est pas pertinent qui doit rester aussi stable que l’architecture de référence
! L’architecture de référence ! Une description contient une restriction du modèle
– permettra d’intégrer les CU incrémentalement – extraits les plus significatifs des modèles de l’architecture de référence
– guidera le raffinement et l’expression des CU pas encore détaillés • vue architecturale du modèle des CU : quelques CU
• vue du modèle d’analyse (éventuellement non maintenue)
• vue du modèle de conception : principaux sous-systèmes et interfaces,
collaborations
Architecture de • vue du modèle de déploiement : diagramme de déploiement
référence : • vue du modèle d’implémentation : artefacts
« petite et maigre » – besoins significatifs sur le plan architectural non décrits par les CU, exigences non
fonctionnelles (ex. sécurité)
– description de la plateforme, des systèmes, des middleware utilisés
– description des frameworks avec mécanismes génériques (qui pourront être
réutilisés)
Modèle des cas Modèle Modèle de Modèle de Modèle de Modèle de – patterns d’architecture utilisés
d’utilisation d’analyse conception déploiement réalisation tests

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 61 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 62

(USDP, 2000)

Architecture : en résumé Processus orienté composants

! Qu’est ce que l’architecture ?
– C’est ce que l’architecte spécifie dans une description d’architecture. La description
de l’architecture laisse à l’architecte la maîtrise technique du développement du ! On cherche à développer et à réutiliser des
système. L’architecture logicielle s’intéresse à la fois aux éléments structuraux
significatifs du système, tels que les sous-systèmes, les classes, les composants et
composants
les nœuds, et aux collaborations se produisant entre ces éléments par l’intermédiaire – souplesse, préparation de l’avenir
des interfaces.
– Les cas d’utilisation orientent l’architecture de telle sorte que le système offre les ! Au niveau modélisation
usages et les fonctionnalités désirés tout en satisfaisant des objectifs de performance. – regroupement en packages d’analyse, de conception
Outre son exhaustivité, l’architecture doit montrer assez de souplesse pour accueillir
de nouvelles fonctions et permettre la réutilisation de logiciels existants. réutilisables
! Comment l’obtient-on ? – utilisation de design patterns
– L'architecture est développée de façon itérative au cours de la phase d’élaboration au • architecturaux
travers [des différentes activités]. Les CU signifiants sur le plan de l’architecture, ainsi
que certaines entrées d’une autre type, permettent d’implémenter l’architecture de
• objets (création, comportement, structure)
référence, ou « squelette », du systè[Link] ensemble d’entrées supplémentaires
comprend les besoins logiciels du système, les middleware, les systèmes existants à
! Au niveau production
réutiliser, les besoins non fonctionnels… – utilisation de frameworks
! Comment la décrit-on ? – achats de composants
– La description de l’architecture est une vue des modèles du système […]. Elle décrit
les parties du système qu’il est important, pour les développeurs et les autres
intervenants, de comprendre.
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 63 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 64

Tous les critères caractérisant les

Patterns
processus UP sont liés
! Patron en français
! La description d’une bonne pratique Processus Piloté par
– un nom itératif et les risques
– un problème récurrent en conception OO incrémental
– une solution (texte + diagrammes)
– une discussion
! Permet le transfert de compétence
Piloté par
! Exemple de pattern Centré sur
les cas
– Composite
d’utilisation l’architecture
! Voir le cours sur les patterns
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 65 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 66
Activités et phases du projet Les activités selon les phases
temps
activités
! Activités
Étude Élaboration Construction Transition
– que faut-il décrire ? préliminaire
– sous quelle forme (modèles, documents textuels…) ?
– comment obtenir les produits ? Capture itération
des besoin
– description technique de la méthode
! Phases Analyse
– planifier les itérations / phases suivantes
– pour chaque phase : Conception
• quels sont les buts à atteindre ?
• quels sont les livrables ? Réalisation
• quels aspects décrire, avec quel niveau d’abstraction ?
Test
– description du déroulement du projet
itérations

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 67 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 68

Plan Description du processus unifié

! Avant-propos ! Dans cette partie
! Méthodes et processus – les différentes activités pour passer des
! Processus unifié : caractéristiques besoins au code
essentielles
– les différentes phases permettant de
! Description du processus unifié
piloter les activités
! Illustration : deux déclinaisons du
processus unifié – quelques focus sur des points
particuliers
! Méthodes Agile
! Conclusion

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 69 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 70

Principes de conception objet USDP

! UP définit un enchaînement d’activités
! Passer des besoins aux classes – réalisées par un ensemble de travailleurs (rôles, métiers)
implémentées en réalisant des scénarios – ayant pour objectif de passer des besoins à un ensemble
comme des collaborations entre objets cohérent d’artefacts constituant un système informatique
– déduire les responsabilités des collaborations – et de favoriser le passage à un autre système quand les
besoins évolueront (nouvelle version)
! S’appuyer sur un modèle du domaine pour
créer des objets métiers susceptibles ! UP n’est qu’un cadre général de processus
– un projet particulier est une instance de ce cadre adaptée
d’évoluer avec les besoins au contexte du projet (taille, personnels, entreprise,
– assumer l’évolutivité des besoins compréhension du processus, etc.)
! Favoriser systématiquement la réutilisation
– en conception : patterns
– en construction : composants, frameworks
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 71 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 72
Activités, travailleurs, artefacts
Travailleurs et activités
! Artefacts (quoi)
– documentent le système et le projet (traces et produits)
– ex. : modèle architectural, code source, exécutable,
modèle des CU, etc.
! Travailleurs ou discipline (qui)
– rôle par rapport au projet
– ex. : architecte, analyste de CU
! Activités (comment)
– 5 grandes activités, multiples sous-activités
• tâches réalisée par un travailleur, impliquant une
manipulation d’information
– ex. : concevoir une classe, corriger un document,
détailler un CU

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 73 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 74

RUP : pour quelques disciplines de plus

Workflows
! Enchaînement d’activités qui produisent des artefacts
! Diagramme d’activité

Project management

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 75 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 76

Exemple RUP : requirement workflow Retour sur les modèles du processus

! Objectif
– créer un modèle global composé de modèles
– et pas une montagne de documents
! Les modèles sont liés
– par les CU
– par les enchaînement d’activité qui les mettre en place
! Rappel
– la description de l’architecture utilise une sous-partie des
modèles

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 77 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 78
Vue globale des modèles Avertissement sur la suite
Capture des besoins
!
– le modèle des CU représente le système vu de l’extérieur, son insertion
! Ce n’est pas forcément du UP générique
dans l’organisation, ses frontières fonctionnelles. complet
! Analyse
– le modèle d’analyse représente le système vu de l’intérieur. Les objets – insistance sur certains points plutôt que
sont des abstractions des concepts manipulées par les utilisateurs. Point d’autres, utilisation de plusieurs sources à peu
de vue statique et dynamique sur les comportements.
! Conception près cohérentes
– le modèle de conception correspond aux concepts utilisés par les outils,
les langages et les plateformes de développement. Le modèle de ! S’appuie sur le cours de JL Sourrouille
déploiement spécifie les nœuds physiques et la distribution des
composants. Permet d’étudier, documenter, communiquer et d’anticiper (INSA-Lyon)
une conception
! Implémentation
– trame description / exemple
– le modèle d’implémentation lie le code et les classes de conception
! Tests
– le modèle de tests décrits les cas de tests

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 79 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 80

1- Activité : expression des besoins Exemple : liste initiale des besoins

Une chaîne d'hôtels a décidé de mettre sur le réseau un système de réservation de
! Quelles valeurs sont attendues du nouveau système et de chambres ouvert à tout client via un navigateur, et d'autre part elle veut automatiser la
gestion de ses hôtels. Un hôtel est géré par un directeur assisté d'employés.
la nouvelle organisation ?
Pour réserver à distance, après avoir choisi hôtels et dates, le client fournit un numéro de
– arriver à un accord client / développeurs carte bleue. Lorsque le retrait a été accepté (1h après environ), la réservation devient
# Recenser les besoins potentiels effective et une confirmation est envoyée par mail. Les clients sous contrat (agences de
voyage...) bénéficient d'une réservation immédiate.
– caractéristiques potentielles, priorité, risques… Le directeur de l'hôtel enregistre les réservations par téléphone. Si un acompte est reçu
# Comprendre le contexte du système avant 72h, la réservation devient effective, sinon elle est transformée en option (toute
personne ayant payé a la priorité). Si la réservation intervient moins de 72h avant la date
– association d’analystes et d’experts métier pour construire un d'occupation souhaitée, le client doit se présenter avant 18h.
vocabulaire commun Le directeur fait les notes des clients, perçoit l'argent et met à jour le planning d'occupation
– modèle du domaine (ou modèle de l’entreprise) effectif des chambres.
• diagramme de classes Une chambre est nettoyée soit avec l'accord du client lorsqu'il reste plusieurs jours, soit
après le départ du client s'il s'en va, et dans ce cas avant occupation par un nouveau
– modèle du métier (éventuellement)
client. Les employés s'informent des chambres à nettoyer et indiquent les chambres
• modélisation des processus (CU métier, diagrammes de nettoyées au fur et à mesure. Pour cela les chambres vides à nettoyer doivent être
séquences, activité) affichées, et les employés doivent pouvoir indiquer les chambres nettoyées de façon
– glossaire très simple. Un historique des chambres nettoyées par chaque employé est conservé un
mois.

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 81 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 82

Modèle du domaine Exemple : modèle du domaine

! Représentation des classes conceptuelles d’une situation réelle
– objets métier (ex. Commande), du monde réel (ex. Avion), événements
– quelques attributs, peu d’opérations Occupation
Hôtel
– associations (s’il y a nécessité de conserver la mémoire de la relation) dateDébut
– les classes non retenues sont placées dans un glossaire Numéro dateFin
! « Dictionnaire visuel » du domaine construit surtout pendant la phase
d’élaboration, itérativement en fonction des CU considérés
! Servira à réduire le décalage des représentation entre domaine et 0..*
objets logiciels 0..*
Chambre Hôte
– inspiration pour la construction de la couche domaine de l'architecture 0..* 0..*
Sdb : douche
logicielle (parfois aussi appelée MD : ne pas mélanger)
! Méthodes de construction (Larman) Réservation
– réutiliser/modifier des modèles existants dateDébut
– liste de catégories dateFin
• classes : objets physiques, transactions, autre systèmes informatiques,
organisations, documents de travail, etc.
• associations : A est membre de B, A est une transaction liée à une transaction B,
A est une description de B, etc.
– groupes nominaux (extraits par exemple des CU détaillés)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 83 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 84
 Modèle du métier (facultatif) Produits de l’acquisition des besoins
Concepts de
Utilisateurs
Expérience l’application Documents
! Modèle des CU métier du domaine -manuel AQ
– représenter les processus -…
– acteurs métier Client Acquisition des besoins
Gérant Compréhension du système
– CU métier
! Modèle objet métier Modèle du domaine
– montre comment les Liste des besoins
(modèle du métier)
CU métier sont réalisés par potentiels
• acteurs métier
• travailleurs métier Réservation Planning Spécification des besoins
• entités métier
! Modélisation du domaine
– modélisation métier simplifiée entités métier
! Possibilité d’identifier les CU à partir
du modèle métier Ménage

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 85 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 86

Expression des besoins (suite) Exemple : description des CU

Le système à développer est divisé en deux sous systèmes indépendants!:
le système de réservation à distance et le système de gestion local à
# Appréhender les besoins fonctionnels l'hôtel.
– trouver les acteurs La base de données des réservations est considérée comme un système
• à partir des besoins (ou du modèle du métier) externe mais non détaillé (sous-système classique).
• délimiter le système par rapport à son environnement Localement, la base de données est considérée comme interne au
(système = boîte noire) système et ignorée pour l'instant.
• chercher qui interagit avec le système (rôles)
– trouver les cas d’utilisation Réservation distante
• examiner comment chaque acteur interagit avec le « actor »
système pour que celui-ci lui rende un service Base de données
• regrouper les interactions similaires en cas d’utilisation des réservations

– décrire brièvement les cas d’utilisation Réservation

• description abrégée (1 paragraphe) Client « actor »
• ou/puis description informelle (plusieurs paragraphes) Système
– construire le modèle des cas d’utilisation Confirmation
bancaire
• les considérer dans leur ensemble
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 87 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 88

Exemple : description des CU

Gestion de l’hôtel
Expression des besoins (suite)
Administration
# Classer les cas d’utilisation par priorité
Le gérant entre la liste de – la priorité dépend des risques associés au cas
Facturation ses chambres, leur
catégorie, leur prix... Il
d’utilisation et de leur importance pour l’architecture, des
peut déclarer qu'une nécessités de réalisation et de tests
chambre est
Administration
momentanément non
utilisable (travaux...). Il
! Exemple : classement des CU par importance
« actor »
Système de fait le bilan mensuel des
Gérant Gestion planning Réservation employés de nettoyage. Il Les traitements très classiques de la gestion locale sont à examiner en
tient à jour une liste des dernier (risque faible). Les réservations (client ou gérant) mettent en jeu
services et les prix (petit une architecture plus complexe et sont à examiner en priorité :
déjeuner en salle, dans la
chambre...)... Réservation (distante)
Réservation
Facturation Réservation locale
...
Administration
Mise à jour
Nettoyage
nettoyage ...

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 89 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 90
 Exemple : détails des cas d’utilisation
Expression des besoins (suite)
! Description détaillée
# Détailler et formaliser les cas d’utilisation – scénario nominal, alternatives (extensions), exceptions, etc.
– un cas d’utilisation représente un ensemble de scénarios – style essentiel (intentions des utilisateurs, responsabilités du
– donner pour chaque cas les scénarios principaux système) plutôt que style concret (évocation IHM)
– détailler le déroulement des scénarios (texte)
– compléter la description des scénarios (diagrammes de CU : Réservation d’une chambre
séquences système, éventuellement de collaboration, Portée : système de réservation
d’activité, d’états) Niveau : objectif utilisateur
# Structurer le modèle (révision des cas si besoin) Acteur principal : Gérant
– ex. généralisation entre cas Intervenants et intérêts : Client, Chaîne hôtelière
Préconditions : une chambre est libre pour la période désirée
# Faire une maquette de l’interface utilisateur
Garanties minimales : rien ne se passe
– uniquement si l’interface est complexe ou nécessite une Garanties en cas de succès : la chambre est réservée
évaluation par le client
Scénario nominal
1. Le gérant demande le planning d'occupation pour la période qui vient. Le système
Utilisateurs non spécialistes, interface simple et logique. affiche le planning sur plusieurs semaines.
Problème classique, sans risque majeur, donc pas de 2. Le gérant sélectionne une chambre libre pour une date qui l’intéresse. Le système
maquette. lui présente le récapitulatif de cette chambre, et sa disponibilité quelques jours avant
et après la date choisie.
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 91 …M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 92

Exemple : diagramme de séquence

système pour un scénario Expression des besoins (suite)
# Appréhender les besoins non fonctionnels (contraintes sur le
système : environnement, plate-forme, fiabilité, vitesse…)
: Gestion : Système de – rattacher si possible les besoins aux cas d’utilisation
hôtel réservation • description dans les descriptions des CU (section « exigences
: Gérant
particulières » pour UP)
Planning(période) – sinon, dresser une liste des exigences supplémentaires

plan := Planning(période) La chaîne possède 117 hôtels de 30 chambres en moyenne. Les appels sur le
réseau sont évalués à 300 par jour (au début, prévoir des évolutions).
Afficher(plan)
Pour des raisons d'extensibilité, de performances et de sécurité, la chaîne de
Réserver(chambre, nom, période)
traitement des réservations des clients doit être indépendante des liaisons des
ok := Réserver(hôtel,chambre, nom, période) hôtels avec le système de ré[Link] hôtels ne sont pas reliés en permanence
au système de réservation (économie) et les postes devront être fiables (coupures
[ok] Informer(résultat) de courant...).
Le temps d’apprentissage du logiciel par les acteurs professionnels ne doit pas
[non ok] Problème(nature)
dépasser une demi-journée.
Une société tierce s'occupera de la maintenance du système et abritera les
serveurs.
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 93 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 94

Expression des besoins : artefacts

Concepts de
Expression des besoins : travailleurs
Utilisateurs
Expérience l’application Documents
du domaine -manuel AQ
-…
! Analyste système, du domaine
Acquisition des besoins – modèle du domaine / du métier
Compréhension du système – modèle des CU / acteurs
Modèle du domaine – glossaire
Liste des besoins
(modèle du métier)
potentiels ! Spécificateur de cas d’utilisation
Spécification des besoins
– CU détaillés
Besoins /
spécifications Classement des cas ! Concepteur d’interface utilisateur
(non fonctionnels) (" vue architecture)
supplémentaires
– maquette/prototype

Modèle des cas

Maquette(s) interface(s) ! Architecte
utilisateur
d’utilisation Analyse – vue architecturale du modèle des CU
(texte) Glossaire
Vision
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 95 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 96
2- Activité : analyse Exemple : découpage en paquetages
! Objectif :
– construction du modèle d’analyse pour préparer la
Gestion réservations
conception
• forme générale stable du système, haut-niveau d’abstraction Réservations
• vision plus précise et formelle des CU, réalisation par des Clients/gérants
objets d’analyse Réservations
• passage du langage du client à celui du développeur Gestion hôtel
Requêtes
# Analyse architecturale gérants

– identifier les paquetages d’analyse

• regroupement logique indépendant de la réalisation
Comptabilité
• relations de dépendances, navigabilité entre classes de
paquetage différents Connexion
système
• à partir des CU et du domaine
bancaire
• point de départ du découpage en sous-systèmes

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 97 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 98

Exemple : premier modèle structurel

Analyse architecturale (suite)
Paquetage : Gestion hôtel

! Identifier les classes entités manifestes (premier

modèle structurel) << InterfaceUtilisateur >>
GestionHotel
Hôtel Emploie
AgentNettoyage

– modèle des 10-20 classes constituant l’essence du +lesAgents

numéro
domaine (à partir du modèle du domaine/métier) Historique
<<InterfaceLogicielle >>
– 3 stéréotypes de classe : frontière, contrôle, entité CComptabilité
Nettoyage Nettoie
– responsabilités évidentes
! Identifier les exigences particulières communes
<< InterfaceLogicielle >>
– distribution, sécurité, persistance, tolérance aux fautes… SystèmeRéservation +lesChambres
Hôte Occupe Chambre
– les rattacher aux classes et cas d’utilisation
dateDébut : Date Responsabilités :
dateFin : Date
<< InterfacePhysique >> - connaître sa taille
CommunicationRéseau - connaître son
équipement
- savoir si elle est
occupée
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 99 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 100

Exemple : diagramme de collaboration

Activité : analyse (suite)
Raffinement du scénario 2.3: Ajouter(nouvNettoyage)
# Analyse des cas d'utilisation « Mise à jour Nettoyage »
– raffinement de tous les scénarios des cas d'utilisation "
découverte des classes, attributs, relations, interactions entre
2:ChambreNettoyée(noCh,noEmpl)
objets, et des besoins spéciaux
– identifier les classes, attributs et relations
• examiner l'information nécessaire pour réaliser chaque scénario 2.4: Afficher(resteANettoyer)
:IUGestionHôtel : Hôtel
• ajouter les classes isolant le système de l'extérieur (interfaces
physiques, vues externes des objets…) 2.1: marquer(nettoyée)
• éliminer les classes qui n’en sont pas : redondantes, vagues, de
conception, etc. 1:Chambre nettoyée 2.2: nouvNettoyage :=
– décrire les interactions entre objets New(date,
• raffiner les diagrammes de séquence système des scénarios (boîte lesAgents[noEmpl]…)
blanche)
• construire les diagrammes de collaboration
• si scénario trop complexe, modéliser par parties (enchaînements), et
indiquer les branchements lesChambres[noCh] :
Chambre : Nettoyage
! Le modèle structurel sera construit pour supporter l'union des {new}
collaborations et interactions exprimées
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 101 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 102
 Produits de l’analyse
Activité : analyse (suite)
Produits des activités précédentes

# Préciser les classes d’analyse

– faire le bilan des responsabilités à partir des
Analyse
collaborations Modèle de
Réalisation des cas
• responsabilité d’une classe = union des rôles dans tous les paquetages
cas (négliger en analyse les opérations implicites) (collaboration,
séquences)
– identifier les attributs
Description de
• rester simple, pas choix de conception à ce nivea Modèle d’analyse l’architecture
– identifier les associations (structurel) (analyse)
Conception
– identifier les relations d’héritage
– identifier les besoins spéciaux des classes
# Vérifier les paquetages d’analyse
– dépendances, couplages
– ils seront à la base des sous-systèmes

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 103 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 104

Analyse : travailleurs Comparaison des modèles CU et analyse

Modèle des cas d'utilisation Modèle d’analyse

! Architecte
Langage du client Langage du développeur
– intégrité du modèle d’analyse
– description de l’architecture Vue externe du système Vue interne du système
• extrait du modèle d’analyse Structuré par les cas Structuré par les classes et
! Ingénieur des CU (vue externe) paquetages (vue interne)
Utilisé comme "contrat" avec
– réalisation/analyse des CU le client Utilisé pour comprendre le système
! Ingénieur des composants Informel Cohérent, non redondant...
– classes d’analyse Capture les fonctions du Esquisse la manière de réaliser les
– paquetages d’analyse système et ce qui conditionne fonctions dans le système et leur
l'architecture répartition dans des classes

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 105 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 106

Différentes sortes de classes 3- Activité : conception

! Propose une réalisation de l'analyse et des cas d’utilisation
! Classe conceptuelle en prenant en compte toutes les exigences
– objets du monde réel # Conception architecturale
– identifier les nœuds et la configuration du réseau
! Classe d’analyse (déploiement), les sous-systèmes et leurs interfaces (modèle
– stéréotypes de Jacobson : frontière, contrôle, entité en couche en général), les classes significatives de
l'architecture
! Classe logicielle # Concevoir les cas d'utilisation
– composant logiciel du point de vue des spécifications ou – identifier les classes nécessaires à la réalisation des cas ...
de l’implémentation # Concevoir les classes et les interfaces
– classe de conception (cf. La 253) – ... décrire les méthodes, les états, prendre en compte les
besoins spéciaux
! Classe d'implémentation
# Concevoir les sous-systèmes
– classe implémentée dans un langage OO – mettre à jour les dépendances, les interfaces...
– sous-systèmes de service, liés à l’appli, de middelware…
– permettra de distribuer le travail aux développeurs
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 107 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 108
Exemple : diagramme de déploiement Exemple : découpage en sous-systèmes
<<subsystem>> <<subsystem>>
Client 1 Client i Paiement
Client n Accès BD
Stockage Accès
internet internet internet
réservations système bancaire

Serveur
intranet
Système internet clients BD <<subsystem>>
bancaire réservations <<subsystem>>
Réservation Services gérant Requêtes
intranet
Serveur Réservations gérant
Gérants
internet
internet internet <<subsystem>>
Gérant 1 Gérant n
Gérant i Gestion hôtel

• Les deux serveurs et la BD des réservations peuvent être sur un même nœud tant que les <<subsystem>>
liaisons clients ne pénalisent pas les liaisons gérants <<subsystem>>
• Les liaisons gérant-serveur démarrent par le réseau téléphonique BD gestion
Comptabilité ODBC
• Sur le Gérant, la facturation doit pouvoir être sur une autre machine Compta
• ...
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 109 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 110

Produits de l’analyse Conception : travailleurs

Produits des activités précédentes ! Architecte
– intégrité des modèles de conception et de
déploiement
Conception
Modèle des – Description de l’architecture
Diagrammes
d’interactions sous-systèmes ! Ingénieur de CU
détaillés (cas)
Description de
– réalisation/conception des CU
Modèle de classe l’architecture ! Ingénieur de composants
(structurel) (conception)
Réalisation – classes de conception
Modèle de – sous-systèmes de conception
déploiement
– interfaces

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 111 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 112

Comparaison des modèles analyse et conception

4- Activité : réalisation
Modèle d’analyse Modèle de conception

Modèle conceptuel, abstraction du Modèle physique qui sera mis en # Mise en oeuvre architecturale
système oeuvre
– identifier les artefacts logiciels et les associer à
Générique vis à vis de la conception Spécifique des nœuds
# Intégrer le système
Moins formel Plus formel
– planifier l'intégration, intégrer les incréments
Donne les grandes lignes de la Réalise cette conception. réalisés
conception, dont l'architecture. Définit Façonne le système en essayant
une structure essentielle pour le de conserver la structure définie # Réaliser les sous-systèmes
système
Représente 1/ 5ème du coût de la
# Réaliser les classes
conception # Faire les tests unitaires
Éventuellement non maintenu durant Nécessairement maintenu durant – tests de spécification en boîte noire, de
le cycle le cycle
structure en boîte blanche
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 113 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 114
 Produits de la réalisation Réalisation : travailleurs

Produits des activités précédentes ! Architecte

– modèles d’implémenation et de déploiement
– description de l’architecture
Réalisation ! Ingénieur de composants
Interfaces Sous-systèmes
(composants et
– artefacts logiciels, sous-systèmes d’implémentation,
sous-systèmes) interfaces
Plan ! Intégrateur système
Artefacts : d’intégration
– plan de construction de l’intégration
exécutables, fichiers, Test
données…

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 115 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 116

5- Activité : test Produits de l’activité de test

# Rédiger le plan de test Produits des activités précédentes

– décrire la stratégie de test, estimer les besoins
pour l'effort de test, planifier l'effort dans le
temps Test
Cas de tests, Modèle de test
# Concevoir les tests procédures de test,
# Automatiser les tests composants de test
Défauts
# Réaliser les tests d'intégration
Plan de test
# Réaliser les tests du système
# Évaluer les tests Couverture des
tests

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 117 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 118

Tests : travailleurs Généralités sur les phases

! Déroulement du projet par phases
! Concepteur de tests
! Chaque phase spécifie les activités à effectuer
– modèle de tests, cas de test, procédures de
test, évaluation des tests, plan de tests Inception Élaboration Construction Transition
! Ingénieur de composants
– test unitaires Capture
des besoin
! Testeur d’intégration
Analyse
– tests d’intégration
! Testeur système Conception
– vérification du système dans son ensemble
Réalisation

Test

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 119 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 120
 Phase d’étude préliminaire
Gestion des phases (inception)
! Objectif : lancer le projet
! Planifier les phases
– établir les contours du système et spécifier sa portée
– allouer le temps, fixer les points de contrôle de fin de phase,
– définir les critères de succès, estimer les risques, les ressources
les itérations par phase et le planning général du projet nécessaires et définir un plan
! Dans chaque phase – à la fin de cette phase, on décide de continuer ou non
– planifier les itérations et leurs objectifs de manière à réduire – attention à ne pas définir tous les besoins, à vouloir des
• les risques spécifiques du produit estimation fiables (coûts, durée), etc.
• les risques de ne pas découvrir l'architecture adaptée • on serait dans le cadre d’une cascade
• les risques de ne pas satisfaire les besoins
– définir les critères d'évaluation de fin d'itération Ressources

! Dans chaque itération

– faire les ajustements indispensables (planning, modèles,
processus, outils...)

Besoins Analyse Conception Tests

Réalisation
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 121 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 122

Activités principales de l’étude préliminaire Livrables de l’étude préliminaire

! Capture des besoins ! Première version du modèle du domaine ou de contexte de
– comprendre le contexte du système (50-70% du contexte) l’entreprise
– établir les besoins fonctionnels et non fonctionnels (80%) – parties prenantes, utilisateurs
– traduire les besoins fonctionnels en cas d'utilisation (50%) ! Liste des besoins
– détailler les premiers cas par ordre de priorité (10% max)
– fonctionnels et non fonctionnels
! Analyse
! Ébauche des modèles de cas, d’analyse et de conception
– analyse des cas d'utilisation (10% considérés, 5% raffinés)
– pour mieux comprendre le système à réaliser, guider le choix ! Esquisse d’une architecture
de l'architecture ! Liste ordonnée de risques et liste ordonnée de cas
! Conception ! Grandes lignes d’un planning pour un projet complet
– première ébauche de la conception architecturale : sous-
systèmes, nœuds, réseau, couches logicielles
! Première évaluation du projet, estimation grossière des coûts
– examen des aspects importants et à plus haut risque ! Glossaire

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 123 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 124

Phase d’élaboration Activités principales de l’élaboration

! Objectif : analyser le domaine du problème ! Capture des besoins
– capturer la plupart des besoins fonctionnels – terminer la capture des besoins et en détailler de 40 à 80%
– planifier le projet et éliminer ses plus hauts risques – faire un prototype de l'interface utilisateur (éventuellement)
– établir un squelette de l’architecture ! Analyse
– analyse architecturale complète (paquetages...)
– réaliser un squelette du système
– raffinement des cas d'utilisation (pour l'architecture, < 10%)
! Conception
Ressources – terminer la conception architecturale
– effectuer la conception correspondant aux cas sélectionnés
! Réalisation
– limitée au squelette de l'architecture
– faire en sorte de pouvoir éprouver les choix
! Test
Besoins Analyse Conception Tests – du squelette réalisé
Réalisation

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 125 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 126
Livrables de l’élaboration Phase de construction
Un modèle de l'entreprise ou du domaine complet
!
! Objectif : Réaliser une version bêta
! Une version des modèles : cas, analyse et conception,
(<10%), déploiement, implémentation (<10%)
! Une architecture de base exécutable
! La description de l'architecture (extrait des autres modèles)
– document d’architecture logicielle
! Une liste des risques mise à jour Ressources
! Un projet de planning pour les phases suivantes
! Un manuel utilisateur préliminaire (optionnel)
! Évaluation du coût du projet

Besoins Analyse Conception Tests

Réalisation

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 127 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 128

Activités principales de la construction Livrables de la construction

! Capture des besoins ! Un plan du projet pour la phase de
– spécifier l'interface utilisateur
! Analyse transition
– terminer l'analyse de tous les cas d'utilisation, la construction
du modèle structurel d'analyse, le découpage en paquetages...
! L'exécutable
! Conception ! Tous les documents et les modèles du
– l'architecture est fixée et il faut concevoir les sous-systèmes
dans l'ordre de priorité (itérations de 30 à 90j, max. 9 mois) système
– concevoir les cas puis les classes
! Une description à jour de l'architecture
! Réalisation
– réaliser, faire des tests unitaires, intégrer les incréments ! Un manuel utilisateur suffisamment détaillé
! Test pour les tests
– toutes les activités de test : plan, conception, évaluation...

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 129 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 130

Activités principales de la phase de

Phase de transition transition (déploiement)
! Objectif : mise en service chez l’utilisateur ! Préparer la version bêta à tester
! Installer la version sur le site, convertir et faire migrer les données
– test de la bêta-version, correction des erreurs nécessaires...
– préparation de la formation, la ! Gérer le retour des sites
commercialisation ! Le système fait- il ce qui était attendu ? Erreurs découvertes ?
! Adapter le produit corrigé aux contextes utilisateurs (installation...)
! Terminer les livrables du projet (modèles, documents...)
Ressources
! Déterminer la fin du projet
! Reporter la correction des erreurs trop importantes (nouvelle
version)
! Organiser une revue de fin de projet (pour apprendre)
! ...
Besoins Analyse Conception Tests ! Planifier le prochain cycle de développement
Réalisation

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 131 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 132
Livrables de la transition Modèles / phases
! L'exécutable et son programme d'installation Création Élaboration

! Les documents légaux : contrat, licences, U A C D I T U A C D I T

garanties, etc. modèle
des cas d'utilisation
! Un jeu complet de documents de développement modèle
à jour d’analyse
modèle
! Les manuels utilisateur, administrateur et de conception
modèle
opérateur et le matériel d'enseignement Construction Transition de déploiement
modèle
! Les références pour le support utilisateur (site U A C D I T U A C D I T d’implémentation
modèle
Web...) de tests

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 133 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 134

(Larman, 2004)

Compléments UP Retour sur l’architecture

! Analyse architecturale
! Analyse architecturale – identifier et traiter les besoins non fonctionnels dans le
contexte des besoins fonctionnels. Consiste notamment à
! Planification des itérations identifier les points de variation et les points d'évolution les
plus probables.
! Les tentations de la cascade • points de variation : variations dans le système existant ou dans
les besoins
• points d’évolution : points de variation spéculatifs, actuellement
! Personnes, environnement et outils absents des besoins
! Identifier un problème
– facteur architectural
! Résoudre le problème (solution)
– principes
• faible couplage, forte cohésion, protection des variations, patterns
architecturaux
• au niveau du système
– description dans un mémo technique
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 135 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 136

(Larman, 2004) (Larman, 2004)

Facteurs architecturaux Mémo technique

! Facteurs qui ont une influence significative sur l’architecture ! Décrire les solutions choisies et la motivation
– fonctionnalités, performance, fiabilité, facilité de maintenance,
– traçabilité des décisions, raisons, alternatives, etc.
implémentation et interface, etc.
! Description d’un facteur ! Mémo technique (texte + diagrammes)
– nom – problème
• ex. : « fiabilité, possibilité de récupération »
– résumé de la solution
– mesures et scénarios de qualité
• ce qu’il doit se passer et comment le vérifier – facteurs architecturaux
• ex. : « si pb, récupétation dans la minute » – solution
– variabilité – motivation
• souplesse actuelle et évolutions futures
• ex. : «pour l’instant service simplifiés acceptables en cas de rupture, – problèmes non résolus
évolution : services complets » – autres solutions envisagées
– impacts
• pour les parties prenantes, l’architecture…
• ex. : « fort impact, rupture de service non acceptable »
– priorité (ex. : élevée)
– difficulté ou risque (ex. : moyen)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 137 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 138
 (Larman, 2004)

Document d’architecture du logiciel Les 4+1 vues de Philip Kruchten

! Vue architecturale
– vue de l’architecture du système depuis un point de vue
particulier
• texte + diagrammes
– se 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
! DAL : récapitulatif des décisions architecturales
– introduction, facteurs, mémos technique
– ensemble de vues architecturales
! Modèle N+1 vues : permettent aux différents intervenants de
se concentrer sur les problèmes de l'architecture du système
qui les concernent le plus
– logique, processus, déploiement, données, sécurité,
implémentation, développement, etc.
– + la vue des cas d’utilisation pour fédérer les autres vues
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 139 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 140

Itération pilotées par la réduction des risques

Planification des itérations
! Planification des itérations dès l’élaboration Risques initiaux
Définir les scénarios Planifier l’itération N
– précise pour la suivante, imprécise pour la fin permettant de prendre • coût
du projet
en compte les risques • planning
– la planification générale est adaptée en fonction des risques Objectif initial
les plus importants
du projet
identifiés/traités et des résultats obtenus dans les itérations
Développer l’itération N
! Planification adaptative (vs. prédictive) • Collecter les dépenses
– fixer des butées temporelles et les métriques de
qualité
– gérer l’adaptation avec le client Iteration N
! Itération Valider l’itération N
– toutes les activités des besoins aux tests, résultats différents en
fonction de la phase dans laquelle on se trouve Réviser l’ensemble de
L’objectif du projet
– mini-projet : planning, ressources, revue • coût
– premières itérations : suivre une méthode • planning
Réviser les risques Risques
• objectifs/contenu
– à la fin d’une itération : retrospective du projet éliminés
• éléments à conserver, problèmes, éléments à essayer • nouvelles priorités

Copyright © 1997 by Rational Software Corporation

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 141 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 142

Attention aux tentations de la cascade Attention aux personnes

! Le processus a un impact sur les personnes
! Les « principes cascade » ne doivent pas – changements de rôles
envahir le processus – on passe des « ressources » aux « travailleurs »
– on ne peut pas tout modéliser avant de réaliser ! Mérites UP par rapport aux personnes
– favorise le travail d’équipe
! Exemples de problèmes • chaque membre comprend son rôle
• les développeurs appréhendent mieux l’activité des autres
– « nous avons une itération d’analyse suivie de développeurs
deux itérations de conception » • les dirigeants comprennent mieux
– diagrammes d’architecture
– « le code de l’itération est très bogué, mais
– si tout le monde le connaît
nous corrigerons tout à la fin » • meilleure productivité de l’entreprise (passage d’un projet à l’autre,
– « la phase d’élaboration sera bientôt finie : il ne formation)
reste que quelques cas d’utilisation à ! Nécessités de la communication
détailler » – les artefacts soutiennent la communication dans le projet
– il faut également des moyens de communications

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 143 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 144
 Personnes, environnement et outils Plan
! Un mixte de facteurs à prendre en compte ! Avant-propos
dans la gestion du projet ! Méthodes et processus
– équilibre entre outils et processus (gérer leur ! Processus unifié : caractéristiques
influence réciproque)
essentielles
– nécessaire gestion de tous les artefacts et de
la communication ! Description du processus unifié
• site web du projet, wiki, cvs, etc. ! Illustration : deux déclinaisons du
– organisation physiques des personnes et processus unifié
artefacts physiques
• tableaux, outils de projection et de capture, pièces et
! Méthodes Agile
circulation, etc. ! Conclusion

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 145 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 146

Two Tracks Unified Process Two Tracks Unified Process

! Processus proposé par Valtech (consulting), présenté dans ! Principe général
– Pascal Roques, Franck Vallée (2004) UML2 en action (3ème – toute évolution imposée au système d’information peut se
édition), Eyrolles, 386 pp. décomposer et se traiter parallèlement, suivant un axe
! Objectif fonctionnel et un axe technique
– prendre en compte les contraintes de changement continuel ! TTUP
imposées aux systèmes d’information des organisations
– processus unifié (itératif, centré sur l’architecture et piloté par
! Création d’un nouveau SI les CU)
– deux grandes sortes de risques
– deux branches
• imprécision fonctionnelle : inadéquation aux besoins
• besoins techniques : réalisation d’une architecture technique
• incapacité à intégrer les technologies : inadaptation technique
• besoins fonctionnels : modèle fonctionnel
! Evolution du SI
– réalisation du système
– deux grandes sortes d’évolutions
• fusionner les résultats des deux branches du processus
• évolution fonctionnelle
• évolution technique

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 147 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 148

Branche Branche
Contraintes fonctionnelle technique Contraintes
fonctionnelles techniques TTUP : commentaires
Capture de besoins Capture des besoins
fonctionnels techniques
! Côté fonctionnel
Analyse Conception générique – relativement classique, indépendant des technologies
– modèle d’analyse réutilisable
Architecture
Modèle d’analyse technique ! Côté technique
Prototype
Conception préliminaire
– insistance sur l’architecture technique indépendamment
des besoins fonctionnels
• c’est un problème de conception en soi
Conception détaillée
– notion de CU techniques
• dépend de l’existant
Codage et tests
• architecture à base de composant
– architecture technique réutilisable
Recette
! Branche commune
Branche conception et – conception préliminaire : le plus délicat
développement logiciel

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 149 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 150
 Itérations et TTUP UP Agile (Larman)
! Proposé par Craig Larman, présenté dans
Inception Elaboration Construction – Craig Larman (2005) UML 2 et les Design Patterns (3e
édition), Pearson Education, 655 p.
! Parce que UP est souvent considéré comme
complexe, formel et lourd
– dans sa description générale,
• essaye de prendre en compte toutes les options possibles,
pour toutes les entreprises, et toutes les tailles de projets
– nombreux artefacts, activités, workflows
• doit être adapté à chaque projet
Incrément 1 Incr.2 Incr.3 Incr.4 Incr.5 … – ce dont tout le monde ne se rend pas forcément compte
– dans son utilisation
• application « à l’ancienne »
– suivi strict des activités : rigidité
• tendance à la cascade
– les mauvaises habitudes sont difficiles à perdre
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 151 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 152

Sample UP Artifact Relationships

Domain Model

Sale 1 1..* Sales

Business ...
LineItem
Modeling
date
...

UP agile = les bonnes pratiques de UP

... quantity

Use-Case Model

Process Sale
Process
use
! Itérations courtes (3 semaines max) Cashier
Sale
case
names
1. Customer
arrives ...
Supplementary
Specification
2. ...
! Mode organisationnel léger 3. Cashier
enters item
non-functional
– petit ensemble d’activités et d’artefacts
identifier.
functional requirements
Require-
Use Case Diagram Use Case Text requirements
ments
! Fusion analyse / conception ideas for system
events
that must be
realized by
domain rules

the post- the objects

! Utilisation de UML pour comprendre et concevoir inspiration for
conditions
: System
names of Glossary
– plus que pour générer du code some
software
Operation:
enterItem(…)
: Cashier
make
system NewSale()
! Planification adaptative domain
objects Post-conditions:
-...
operations
enterItem
item details,
(id, quantity)
! Bref, application de UP dans l’ « esprit Agile »
formats,
Operation Contracts System Sequence Diagrams validation
starting events to

– vs. esprit cascade design for, and

detailed post-
condition to
– en considérant que UP est agile naturellement dans sa satisfy
: Register
Design Model
: ProductCatalog : Sale

conception (et pour ses concepteurs), mais ne l’est pas dans enterItem
ses applications Design (itemID, quantity)

d = getProductDescription(itemID)
! Transparents suivants addLineItem( d, quantity )

– liens entre artefacts dans UP agile Register

ProductCatalog
– mise en œuvre physique des réunions ...
...
* 1 makeNewSale()
getProductDescription(...)
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 153 enterItem(...)
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université
...
... Claude Bernard Lyon 1 154

Organisation physique : CU When Where

Organisation physique : modélisation objet
Once during inception. Short; do not try to At a requirements workshop.
define or polish all requirements. When Where
Near the beginning of each iteration, for a In a project room with lots of support
Several times during elaboration iterations. "short" period before programming. for drawing and viewing drawings.

January February
January February

Two adjacent projections.

Two adjacent projections.

Use Case: Capture a Sale Use Case: Handle Returns

... ... whiteboards Sto r e
1 a d d r e s s : Ad d r e s s 1

Main Success Scenario: Main Success Scenario:

1
n a me : Te x t
Pr o d u c tSp e c ific a tio n
: R e g is te r : Pr o d u c tC a ta lo g a d d Sa le ( )
Pr o d u c tC a ta lo g
d e s c r ip tio n : Te x t

1. ... 1. ...
p r ic e : M o n e y
1 1 1 1 ..* ite m ID : Ite m ID : R e g is te r : Pr o d u c tC a ta lo g
m a k e N e w Sa le ( ) g e tSp e c ific a tio n ( )

c r e a te ( )
2. ... 2. ... e n te r Ite m : Sa le
1 1 Sa le
1
m a k e N e w Sa le ( )

e n te r Ite m
c r e a te ( ) : Sa le
( ite m ID , q u a n tity ) * ( ite m ID , q u a n tity )
3. ... 3. ... s p e c := g e tSp e c ific a tio n ( ite m ID )
R e g is te r d a te : D a te
is C o m p le te : Bo o le a n
tim e : T im e
Sa le s L in e Ite m
s p e c := g e tSp e c ific a tio n ( ite mID )
a d d L in e Ite m ( s p e c , q u a n tity )
a d d L in e Ite m ( s p e c , q u a n tity ) q u a n tity : In te g e r

Extensions: Extensions: ...

e n d Sa le ( )
e n te r Ite m ( )
m a k e N e w Sa le ( )
1 1
b e c o m e C o m p le te ( )
ma k e L in e Ite m( )
ma k e Pa y m e n t( )
1 1 ..*
g e tSu b to ta l( )
...

m a k e Pa y m e n t( )
g e tT o ta l( ) ...
1
* Pa y m e n t
...
amo un t : Mon e y
1

System
Analyst Customer
Software
Software Developer
End User Developer Architect
Architect Developer

How: Tools
Who Software:
Many, including end users and developers, will play For use case text, use a web-enabled requirements tool Who How: Tools
the role of requirements specifier, helping to write that integrates with a popular word processor. Perhaps developers will do some design work in Software: A UML CASE tool that can also reverse engineer
use cases. For use case diagrams, a UML CASE tool. pairs. The software architect will collaborate, mentor, diagrams from code.
Hyperlink the use cases; present them on the project website. and visit with different design groups.
Led by system analyst who is responsible for Hardware:
requirements definition. Hardware: Use two projectors attached to dual video cards and - Use two projectors attached to dual video cards.
set the display width double to improve the spaciousness of the - For whiteboard drawings, perhaps a digital camera.
drawing area or display 2 adjacent word processor windows . - To print noteworthy diagrams for the entire team, a plotter
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 155 M1 MIAGE - SIMA 2005-2006 / Yannick Prié -forUniversité Claude
large-scale drawings Bernard
to hang Lyon 1
on walls. 156
Plan Petite histoire des méthodes Agile

! Avant-propos ! Années 90
– réaction contre les grosses méthodes
! Méthodes et processus – prise en compte de facteurs liés au développement logiciel
! Processus unifié : caractéristiques ! Fin années 90
essentielles – méthodes
• d’abord des pratiques liées à des consultants, puis des livres
! Description du processus unifié • XP, Scrum, FDD, Crystal…
! Illustration : deux déclinaisons du ! 1991
processus unifié – les principaux méthodologues s’accordent sur le « Agile
manifesto »
! Méthodes Agile ! Années 2000
! Conclusion – projets Agile mixent des éléments des principales méthodes

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 157 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 158

Du rien au monumental à l’agile Principes communs des méthodes Agile

! Rien ! Méthodes adaptatives (vs. prédictives)
– « code and fix »
– itérations courtes
– marche bien sur les petits projets, suicidaire ensuite
! Monumental – lien fort avec le client
– méthodes, processus, contrats : rationalisation à tous les étages – fixer les délai et les coûts, mais pas la portée
– problèmes et échecs ! Insistance sur les hommes
• trop de choses sont faites qui ne sont pas directement liées au produit
logiciel à construire – les programmeurs sont des spécialistes, et pas des
• planification trop rigide unités interchangeables
! Agile – attention à la communication humaine
– trouver un compromis : le minimum de méthode permettant de mener
à bien les projets en restant agile – équipes auto-organisées
• capacité de réponse rapide et souple au changement ! Processus auto-adaptatif
• orientation vers le code plutôt que la documentation
– révision du processus à chaque itération

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 159 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 160

Méthodes agiles Manifeste Agile

Février 1991, rencontre et accord sur un manifeste
! Simplicité
!
! Mise en place de la « Agile alliance »
! Légèreté – objectif : promouvoir les principes et méthodes Agile
– [Link]
! Orientées
participants plutôt que plan ! Les signataires privilégient
– les individus et les interactions davantage que les processus et les
! Nombreuses outils
– les logiciels fonctionnels davantage que l’exhaustivité et la
– XP est la plus connue documentation
– la collaboration avec le client davantage que la négociation de
! Pas de définition unique contrat
– la réponse au changement davantage que l’application d’un plan
! Mais un manifeste ! 12 principes
– (transparents suivants)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 161 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 162
 [Link] [Link]

Manifeste Agile : principes Manifeste Agile : principes

1. Our highest priority is to satisfy the costumer through early and 7. Working software is the primary measure of progress
continuous delivery of valuable software. 8. Agile processes promote sustainable development. The
2. Welcome changing requirements, even late in development. sponsors, developers, and users should be able to
Agile process harness change for the customer´s competitive maintain a constant pace indefinitely
advantage.
3. Deliver working software frequently, from a couple of weeks to a 9. Continuous attention to technical excellence and good
couple of months, with a preference to the shorter timescale. design enhances agility
4. Business people and developers must work together daily 10. Simplicity – the art of maximizing the amount of work not
throughout the project. done – is essential
5. Build projects around motivated individuals. Give them the 11. The best architectures, requirements, and designs emerge
environment and support they need, and trust them to get the job from self-organizing teams
done.
12. At regular intervals, the team reflects on how to become
6. The most efficient and effective method of conveying information more effective, then tunes and adjusts its behavior
to and within a development team is face-to-face conversation.
accordingly

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 163 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 164

(Larman 2005, p.36-37)

Processus agile et modélisation Dans la suite

! Utilisation d’UML ! Description rapide de quelques méthodes
! La modélisation vise avant tout à comprendre et à – XP (Kent Beck)
communiquer
– Scrum (Ken Schwaber)
! Modéliser pour les parties inhabituelles, difficiles ou
délicates de la conception. – Crystal (Alistair Cockburn)
! Rester à un niveau de modélisation minimalement suffisant ! Autres méthodes
! Modélisation en groupe – UP, FDD (Feature Driven Development) , DSDM
! Outils simples et adaptés aux groupes (Dynamic System Development Method), …
! Les développeurs créent les modèles de conception qu’ils
développeront

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 165 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 166

[Link]

XP (eXtreme Programming) XP : vue d’ensemble

! Site officiel
toutes les
– [Link] 2 ou 3 semaines
! Caractéristiques principales ([Link]
Planning
[Link]/methodes/XP/)
– Le client (maîtrise d’ouvrage) pilote lui-même le projet, et ce de très
près grâce à des cycles itératifs extrêmement courts (1 ou 2 Écriture des tests
semaines).
– L’équipe autour du projet livre très tôt dans le projet une première
version du logiciel, et les livraisons de nouvelles versions s’enchaînent Release Programmation par pairs développement
ensuite à un rythme soutenu pour obtenir un feedback maximal sur + Refactoring piloté par les tests
l’avancement des développements.
– L’équipe s’organise elle-même pour atteindre ses objectifs, en
favorisant une collaboration maximale entre ses membres. Test
– L’équipe met en place des tests automatiques pour toutes les
fonctionnalités qu’elle développe, ce qui garantit au produit un niveau
de robustesse très élevé. Integration
– Les développeurs améliorent sans cesse la structure interne du logiciel chaque jour
pour que les évolutions y restent faciles et rapides. (intégration continue)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 167 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 168
 [Link]

XP : rôles et responsabilités XP : pratiques (1)

! Programmeur ! Le « jeu de la planification »
– écrit les tests et puis code – regroupement des intervenants pour planifier l’itération
! Client – les développeurs évaluent les risques techniques et les efforts
– écrit les histoires et les tests fonctionnels prévisibles liés à chaque fonctionnalité (user story, sortes de
! Testeur scénarios abrégés)
– aide le client à écrire les tests et à les exécuter – les clients estiment la valeur (l’urgence) des fonctionnalités, et
! Consultant décident du contenu de la prochaine itération
– fournit les connaissances spécialisées au besoin ! Temps court entre les releases
! Coach – au début : le plus petit ensemble de fonctionnalités utiles
– aide l’équipe par rapport au processus – puis : sorties régulières de prototypes avec fonctionnalités
! Tracker ajoutées
– vérifie que l’équipe ne perd pas la bonne direction ! Métaphore
! Manager – chaque projet a une métaphore pour son organisation, qui
– prend les décisions fournit des conventions faciles à retenir

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 169 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 170

XP : pratiques (2) XP : pratiques (3)

! Conception simple ! Programmation par paires (pair programming)
– toujours utiliser la conception la plus simple qui fait ce qu’on veut – tout le code de production est écrit par deux programmeurs devant un
ordinateur
• doit passer les tests
– l’un pense à l’implémentation de la méthode courante, l’autre à tout le
• assez claire pour décrire les intentions du programmeur
système
– pas de généricité spéculative – les paires échangent les rôles, les participants des paires changent
! Tests ! Propriété collective du code
– développement piloté par les tests : on écrit d’abord les tests, puis – tout programmeur qui voit une opportunité d’améliorer toute portion de
on implémente les fonctionnalités code doit le faire, à n’importe quel moment
– les programmeurs s’occupent des tests unitaires ! Intégration continue
– les clients s’occupent des tests d’acceptation (fonctionnels) – utilisation d’un gestionnaire de versions (e.g., CVS)
! Refactoring – tous les changements sont intégrés dans le code de base au minimum
chaque jour : une construction complète (build) minimum par jour
– réécriture, restructuration et simplification permanente du code – 100% des tests doivent passer avant et après l’intégration
– le code doit toujours être propre

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 171 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 172

XP : pratiques (4) XP : pratiques (5)

! Semaine de 40 heures (35 en France ?) ! Règles
– les programmeurs rentrent à la maison à l’heure – l’équipe décide des règles qu’elle suit, et peut les
– faire des heures supplémentaire est signe de problème changer à tout moment
– moins d’erreurs de fatigue, meilleure motivation
! Espace de travail
! Des clients sur place
– tout le monde dans la même pièce
– l’équipe de développement a un accès permanent à un vrai • awareness
client/utilisateur (dans la pièce d’à côté)
– tableaux au murs
! Des standards de codage
– matérialisation de la progression du projet
– tout le monde code de la même manière • par les histoires (user stories) réalisées et à faire
• tout le monde suit les règles qui ont été définies – papiers qui changent de position, sont réorganisés
• il ne devrait pas être possible de savoir qui a écrit quoi • par les résultats des tests
• …

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 173 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 174
 XP : quelques point du site web XP : avantages
! Planning ! Coding ! Concept intégré et simples
– User stories are written. – The customer is always available.
– Release planning creates the schedule. – Code must be written to agreed standards. ! Pas trop de management
– Make frequent small releases. – Code the unit test first.
– The Project Velocity is measured. – All production code is pair programmed.
– pas de procédures complexes
– The project is divided into iterations. – Only one pair integrates code at a time. – pas de documentation à maintenir
– Iteration planning starts each iteration. – Integrate often.
– Move people around. – Use collective code ownership.
– communication directe
– A stand-up meeting starts each day. – Leave optimization till last. – programmation par paires
– Fix XP when it breaks. – No overtime.
! Designing ! Testing
! Gestion continuelle du risque
– Simplicity. – All code must have unit tests. ! Estimation permanente des efforts à fournir
– Choose a system metaphor. – All code must pass all unit tests before it
– Use CRC cards for design sessions. can be released. ! Insistance sur les tests : facilite l’évolution et la maintenance
– Create spike solutions to reduce risk. – When a bug is found tests are created.
– No functionality is added early. – Acceptance tests are run often and the
– Refactor whenever and wherever score is published.
possible.

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 175 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 176

[Link]

XP : inconvénients Scrum
! Approprié pour de petites équipes (pas plus de 10 ! Scrum : mêlée
développeurs), ne passe pas à l’échelle ! Phases
– pour des groupes plus gros, il faut plus de structure et – Initiation / démarrage
de documentation (ceremony) • Planning
! Risque d’avoir un code pas assez documenté – définir le système : product Backlog = liste de fonctionnalités,
ordonnées par ordred de priorité et d’effort
– des programmeur qui n’auraient pas fait partie de
l’équipe de développement auront sans doute du mal à • Architecture
– conception de haut-niveau
reprendre le code
– Développement
! Pas de design générique • Cycles itératifs (sprints) : 30j
– pas d'anticipation des développements futurs – amélioration du prototype
– Clôture
• Gestion de la fin du projet : livraison…

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 177 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 178

[Link] [Link]

Principes Scrum Scrum : rôles responsabilités

! Isolement de l'équipe de développement ! Scrum Master
– l'équipe est isolée de toute influence extérieure qui pourrait lui nuire.
Seules l'information et les tâches reliées au projet lui parviennent : pas – expert de l’applicatron de Scrum
d’évolution des besoins dans chaque sprint.
! Développement progressif
! Product owner
– afin de forcer l'équipe à progresser, elle doit livrer une solution tous les – responsable officiel du projet
30 jours. Durant cette période de développement l'équipe se doit de
livrer une série de fonctionnalités qui devront être opérationnelles à la ! Scrum Team
fin des 30 jours.
– équipe projet.
! Pouvoir à l'équipe
– l'équipe reçoit les pleins pouvoirs pour réaliser les fonctionnalités. ! Customer
C'est elle qui détient la responsabilité de décider comment atteindre
ses objectifs. Sa seule contrainte est de livrer une solution qui – participe aux réunions liées aux fonctionnalités
convienne au client dans un délai de 30 jours.
! Management
! Contrôle du travail
– le travail est contrôlé quotidiennement pour savoir si tout va bien pour – prend les décisions
les membres de l'équipe et à la fin des 30 jours de développement
pour savoir si la solution répond au besoin du client.

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 179 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 180
 [Link]

Scrum : pratiques Méthodologies « Crystal »

! Product Backlog ! Alistair Cockburn (2002). Agile Software Development.
Addison Wesley
– état courant des tâches à accomplir
! Le développement logiciel vu comme un jeu coopératif de
! Effort Estimation communication et d’invention
– permanente, sur les entrées du backlog – des projets différents et des méthodes différentes
! Sprint – le projet change à mesure que les gens changent
– itération de 30 jours ! Choix de la méthode en fonction de différents facteurs
! Sprint Planning Meeting – taille en nombre de personnes / criticité pour le client (LEDC)
– réunion de décision des objectifs du prochain sprint et de la manière
de les implémenter air-traffic
control system
! Sprint Backlog
banking system
– Product Backlog limité au sprint en cours
! Daily Scrum meeting
– ce qui a été fait, ce qui reste à faire, les problèmes
! Sprint Review Meeting
medium-sized
– présentation des résultats du sprint
small productivity tool
utilities
M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 181 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 182

La famille de méthodes Crystal Crystal Clear

! Familles conçues à partir de ! “C6-D6”
l'observation et des interviews ! Une seule équipe, à un seul
! Trouver à chaque fois la méthode la endroit
moins rigide qui réussira quand même – Good, small teams produce
– haute productivité, haute tolérance good, small software
– focus sur la communication products
! Exemples – Communication étroite
– Crystal Clear ! Rôles
– Crystal Yellow – sponsor
– Crystal Orange – développeur sénior
– Crystal Red – concepteurs-programmeurs
– utilisateurs
! Livraison incrémentale tous
les 2/3 mois

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 183 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 184

Crystal Orange Plan

“C40-E40”
!
– plus de structure d’équipes
! Avant-propos
!
– lus de coordination
Tout le monde dans le même
! Méthodes et processus
immeuble ! Processus unifié : caractéristiques
! Rôles
– Sponsor essentielles
– Expert métier
– Expert IHM ! Description du processus unifié
– Expert techniques
– Analyste concepteur métier ! Illustration : deux déclinaisons du
– Manager processus unifié
– Architecte
– Concepteur mentor ! Méthodes Agile
– …
! 1-2 ans de développement ! Conclusion
! Importance du respect des délais et
de l’adaptation au marché

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 185 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 186
Conclusion Crédits – remerciements
! « There is no silver bullet » : le retour ! J.L. Sourrouille (INSA de Lyon)
Même si le développement incrémental permet de
s’affranchir de beaucoup de problèmes, il y aura quand ! Sources
même des problèmes. Mais ceux-ci seront normalement
d’ampleur plus faible, et mieux gérés. – [Link]
! Toute méthode est adaptable et doit être adaptée CE355-05/lectures/Lect3-Ch15-
Mais, lorsque l’on débute, il vaut mieux ne pas trop
s’écarter de la voie décrite pour bien comprendre au [Link]
départ (cf. musique)
– [Link]
lasses/[Link]

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 187 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 188

Annexe :
Annexe : coders’ dojo
gestion des composants et bibliothécaire
! Qualité ! Idée
– niveau plus élevé que celui d’une application
(surcoût minimum 50%, en pratique 100%) – parallèle arts martiaux / conception-
– une confiance absolue est nécessaire pour que la programmation OO
réutilisation soit effective • il faut s’entraîner à appliquer des « routines »
! Une fonction : bibliothécaire connues avant de pouvoir commencer à les utiliser
– participe au choix des produits à généraliser de façon créative, voire à en inventer de nouvelles
– contribue ou procède à la généralisation • les débutant doivent apprendre des maîtres
– établit des normes, règles, niveaux de qualité, – un exemple de formation
protocoles de mise en bibliothèque
• [Link]
– classifie les produits de la bibliothèque (critères)
– diffuse, informe, facilite l’accès (outils)

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 189 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 190

(O. Boissier) (O. Boissier)

Annexe : qualité du logiciel Qualité du logiciel

! Facteur externes (utilisateur) ! Facteurs externes (suite)
– Correction (validité) – Compatibilité
• facilité avec laquelle un logiciel peut être combiné avec
• aptitude à répondre aux besoins et à remplir les d’autres
fonctions définies dans le cahier des charges
– Efficacité
– Robustesse (fiabilité) • utilisation optimale des ressources matérielles
• aptitude à fonctionner dans des conditions non (processeur, mémoires, réseau, …)
prévues au cahier des charges, éventuellement – Convivialité
anormales • facilité d’apprentissage et d’utilisation, de préparation des
– Extensibilité données, de correction des erreurs d’utilisation,
d’interprétation des retours
• facilité avec laquelle de nouvelles fonctionnalités
peuvent être ajoutées – Intégrité (sécurité)
• aptitude d’un logiciel à se protéger contre des accès non
autorisés.

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 191 M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 192
 (O. Boissier)

Qualité du logiciel
! Facteurs internes (concepteur)
– Ré-utilisabilité
• aptitude d’un logiciel à être réutilisé, en tout ou en
partie, pour d’autres applications
– Vé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érents
– Lisibilité
– Modularité

M1 MIAGE - SIMA 2005-2006 / Yannick Prié - Université Claude Bernard Lyon 1 193