CM Methodes Fin 6pp

Plan
Two Tracks Unified Process

Processus propos par Valtech (consulting), prsent dans
Avant-propos Mthodes et processus Processus unifi : caractristiques essentielles Description du processus unifi Illustration : deux dclinaisons du processus unifi Mthodes Agile Conclusion
142
Pascal Roques, Franck Valle (2004) UML2 en action (3me dition), Eyrolles, 386 pp.
Objectif
prendre en compte les contraintes de changement continuel imposes aux systmes dinformation des organisations
Cration dun nouveau SI
deux grandes sortes de risques

imprcision fonctionnelle : inadquation aux besoins incapacit intgrer les technologies : inadaptation technique Evolution du SI
deux grandes sortes dvolutions

volution fonctionnelle volution technique
M1 MIAGE - SIMA 2005-2006 / Yannick Pri - Universit Claude Bernard Lyon 1
143
Two Tracks Unified Process

Principe gnral
Contraintes fonctionnelles
Branche fonctionnelle
Branche technique
Contraintes techniques
Capture de besoins fonctionnels Analyse

Modle danalyse
Capture des besoins techniques Conception gnrique

Architecture technique
toute volution impose au systme dinformation peut se dcomposer et se traiter paralllement, suivant un axe fonctionnel et un axe technique
TTUP
Prototype Conception prliminaire Conception dtaille Codage et tests Recette
processus unifi (itratif, centr sur larchitecture et pilot par les CU) deux branches
besoins techniques : ralisation dune architecture technique besoins fonctionnels : modle fonctionnel
ralisation du systme
fusionner les rsultats des deux branches du processus
Branche conception et dveloppement logiciel

144
145
TTUP : commentaires
Itrations et TTUP
Inception Elaboration Construction
Ct fonctionnel
relativement classique, indpendant des technologies modle danalyse rutilisable
Ct technique
insistance sur larchitecture technique indpendamment des besoins fonctionnels
cest un problme de conception en soi
notion de CU techniques
dpend de lexistant architecture base de composant
Incrment 1
Incr.2
Incr.3
Incr.4
Incr.5
architecture technique rutilisable
Branche commune
conception prliminaire : le plus dlicat
146 147
UP Agile (Larman)
UP agile = les bonnes pratiques de UP

Itrations courtes (3 semaines max) Mode organisationnel lger
Propos par Craig Larman, prsent dans

Craig Larman (2005) UML 2 et les Design Patterns (3e dition), Pearson Education, 655 p.
Parce que UP est souvent considr comme complexe, formel et lourd

dans sa description gnrale,
essaye de prendre en compte toutes les options possibles, pour toutes les entreprises, et toutes les tailles de projets
nombreux artefacts, activits, workflows
petit ensemble dactivits et dartefacts

Fusion analyse / conception Utilisation de UML pour comprendre et concevoir
plus que pour gnrer du code

Planification adaptative Bref, application de UP dans l esprit Agile
doit tre adapt chaque projet

ce dont tout le monde ne se rend pas forcment compte
dans son utilisation

application lancienne
suivi strict des activits : rigidit
vs. esprit cascade en considrant que UP est agile naturellement dans sa conception (et pour ses concepteurs), mais ne lest pas dans ses applications
Transparents suivants
tendance la cascade
les mauvaises habitudes sont difficiles perdre
liens entre artefacts dans UP agile mise en uvre physique des runions 148
149
Sample UP Artifact Relationships Domain Model
Business Modeling
Sale date ...
1..*
Sales LineItem quantity ...
...
Organisation physique : CU
When
Once during inception. Short; do not try to define or polish all requirements. Several times during elaboration iterations.
Where
At a requirements workshop.
Use-Case Model
Process Sale
Process Sale Cashier
use case names
1. Customer arrives ... 2. ... 3. Cashier enters item identifier. Use Case Text system events : System
Supplementary Specification
January
February
Requirements
Use Case Diagram
ideas for the postconditions inspiration for names of some software domain objects
Operation: enterItem() Post-conditions: -... Operation Contracts
: Cashier
functional requirements that must be realized by the objects

Glossary
non-functional requirements
Two adjacent projections.
domain rules
system operations
make NewSale() enterItem (id, quantity)
Use Case: Capture a Sale ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:
Use Case: Handle Returns ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:
starting events to design for, and detailed postcondition to satisfy
System Sequence Diagrams
item details, formats, validation
System Analyst
: ProductCatalog : Sale
Customer Software Architect
: Register enterItem (itemID, quantity)
Design Model
End User
Developer
How: Tools Who

d = getProductDescription(itemID) addLineItem( d, quantity )
Design
Many, including end users and developers, will play the role of requirements specifier, helping to write use cases.
ProductCatalog
Software: For use case text, use a web-enabled requirements tool that integrates with a popular word processor. For use case diagrams, a UML CASE tool. Hyperlink the use cases; present them on the project website. Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows .
Register ... makeNewSale() enterItem(...) ... ...
Led by system analyst who is responsible for requirements definition.
1 * getProductDescription(...) ... M1 MIAGE - SIMA 2005-2006 / Yannick Pri - Universit Claude Bernard Lyon 1
150
151
Organisation physique : modlisation objet

When
Near the beginning of each iteration, for a "short" period before programming.
Where
In a project room with lots of support for drawing and viewing drawings.
Plan

January
February
Two adjacent projections.
whiteboards
1
Sto r e a d d r e s s : Ad d r e s s n a me : Te x t a d d Sa le ( ) 1 1 g e tSp e c ific a tio n ( ) 1 1 Pr o d u c tSp e c ific a tio n Pr o d u c tC a ta lo g 1 1 ..* d e s c r ip tio n : Te x t p r ic e : M o n e y ite m ID : Ite m ID
: R e g is te r m a k e N e w Sa le ( ) e n te r Ite m ( ite m ID , q u a n tity )
: Pr o d u c tC a ta lo g
: R e g is te r m a k e N e w Sa le ( ) e n te r Ite m ( ite m ID , q u a n tity )
: Pr o d u c tC a ta lo g
c r e a te ( ) s p e c := g e tSp e c ific a tio n ( ite m ID ) a d d L in e Ite m ( s p e c , q u a n tity ) ... ...
: Sa le
1 R e g is te r 1 Sa le d a te : D a te is C o m p le te : Bo o le a n tim e : T im e 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( ) g e tT o ta l( )
c r e a te ( ) 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 ) ... ...
: Sa le
*
Sa le s L in e Ite m 1 ..* q u a n tity : In te g e r g e tSu b to ta l( )
e n d Sa le ( ) e n te r Ite m ( ) m a k e N e w Sa le ( ) m a k e Pa y m e n t( )
Pa y m e n t 1 amo un t : Mon e y
Software Architect
Developer Developer
Who
Perhaps developers will do some design work in pairs. The software architect will collaborate, mentor, and visit with different design groups.
How: Tools
Software: A UML CASE tool that can also reverse engineer diagrams from code. Hardware: - Use two projectors attached to dual video cards. - For whiteboard drawings, perhaps a digital camera. - To print noteworthy diagrams for the entire team, a plotter Pri -for large-scale drawings to hang on walls. Universit Claude Bernard Lyon 1
153
M1 MIAGE - SIMA 2005-2006 / Yannick
152
Petite histoire des mthodes Agile

Annes 90
Du rien au monumental lagile
Rien
code and fix marche bien sur les petits projets, suicidaire ensuite
raction contre les grosses mthodes prise en compte de facteurs lis au dveloppement logiciel
Fin annes 90
Monumental
mthodes, processus, contrats : rationalisation tous les tages problmes et checs
trop de choses sont faites qui ne sont pas directement lies au produit logiciel construire planification trop rigide
mthodes
dabord des pratiques lies des consultants, puis des livres XP, Scrum, FDD, Crystal 1991
Agile
trouver un compromis : le minimum de mthode permettant de mener bien les projets en restant agile
capacit de rponse rapide et souple au changement orientation vers le code plutt que la documentation
les principaux mthodologues saccordent sur le Agile manifesto

Annes 2000
projets Agile mixent des lments des principales mthodes
154
155
Principes communs des mthodes Agile
Mthodes agiles
Simplicit Lgret Orientes
Mthodes adaptatives (vs. prdictives)

itrations courtes lien fort avec le client fixer les dlai et les cots, mais pas la porte
Insistance sur les hommes

les programmeurs sont des spcialistes, et pas des units interchangeables attention la communication humaine quipes auto-organises
participants plutt que plan Nombreuses

XP est la plus connue
Pas Mais
156
Processus auto-adaptatif
rvision du processus chaque itration
de dfinition unique un manifeste

157
http://agilemanifesto.org/principles.html
Manifeste Agile
Fvrier 1991, rencontre et accord sur un manifeste Mise en place de la Agile alliance
Manifeste Agile : principes

1. 2.
objectif : promouvoir les principes et mthodes Agile http://www.agilealliance.com/

Les signataires privilgient
3. 4. 5.
les individus et les interactions davantage que les processus et les outils les logiciels fonctionnels davantage que lexhaustivit et la documentation la collaboration avec le client davantage que la ngociation de contrat la rponse au changement davantage que lapplication dun plan
12 principes
6.
Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile process harness change for the customers competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
(transparents suivants) 158 159
http://agilemanifesto.org/principles.html
(Larman 2005, p.36-37)
Manifeste Agile : principes

Working software is the primary measure of progress Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility 10. Simplicity the art of maximizing the amount of work not done is essential 11. The best architectures, requirements, and designs emerge from self-organizing teams 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
7. 8.
Processus agile et modlisation

Utilisation dUML La modlisation vise avant tout comprendre et
communiquer
Modliser pour les parties inhabituelles, difficiles ou
dlicates de la conception.
Rester un niveau de modlisation minimalement suffisant Modlisation en groupe Outils simples et adapts aux groupes Les dveloppeurs crent les modles de conception quils
dvelopperont
160
161
Dans la suite
XP (eXtreme Programming)

Description rapide de quelques mthodes

XP (Kent Beck) Scrum (Ken Schwaber) Crystal (Alistair Cockburn)
Site officiel
http://www.extremeprogramming.org/
Caractristiques principales (http://www.designup.com/methodes/XP/)

Le client (matrise douvrage) pilote lui-mme le projet, et ce de trs prs grce des cycles itratifs extrmement courts (1 ou 2 semaines). Lquipe autour du projet livre trs tt dans le projet une premire version du logiciel, et les livraisons de nouvelles versions senchanent ensuite un rythme soutenu pour obtenir un feedback maximal sur lavancement des dveloppements. Lquipe sorganise elle-mme pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres. Lquipe met en place des tests automatiques pour toutes les fonctionnalits quelle dveloppe, ce qui garantit au produit un niveau de robustesse trs lev. Les dveloppeurs amliorent sans cesse la structure interne du logiciel pour que les volutions y restent faciles et rapides.
Autres mthodes
UP, FDD (Feature Driven Development) , DSDM (Dynamic System Development Method),
162
163
http://www.swen.uwaterloo.ca/~kostas/ECE355-05/lectures/Lect3-Ch15-Unit2.ppt
http://web.engr.oregonstate.edu/~cook/classes/cs569.agile.ppt
XP : vue densemble
toutes les 2 ou 3 semaines Planning
XP : rles et responsabilits

Programmeur
crit les tests et puis code
Client
crit les histoires et les tests fonctionnels
Testeur
aide le client crire les tests et les excuter
criture des tests Release Programmation par pairs + Refactoring Test dveloppement pilot par les tests chaque jour (intgration continue) M1 MIAGE - SIMA 2005-2006 / Yannick Pri - Universit Claude Bernard Lyon 1
Consultant
fournit les connaissances spcialises au besoin
Coach
aide lquipe par rapport au processus
Tracker
vrifie que lquipe ne perd pas la bonne direction
Integration
Manager
prend les dcisions
164
165
XP : pratiques (1)
Le jeu de la planification
XP : pratiques (2)
Conception simple
regroupement des intervenants pour planifier litration les dveloppeurs valuent les risques techniques et les efforts prvisibles lis chaque fonctionnalit (user story, sortes de scnarios abrgs) les clients estiment la valeur (lurgence) des fonctionnalits, et dcident du contenu de la prochaine itration
Temps court entre les releases
toujours utiliser la conception la plus simple qui fait ce quon veut

doit passer les tests assez claire pour dcrire les intentions du programmeur
pas de gnricit spculative

Tests
au dbut : le plus petit ensemble de fonctionnalits utiles puis : sorties rgulires de prototypes avec fonctionnalits ajoutes
Mtaphore
dveloppement pilot par les tests : on crit dabord les tests, puis on implmente les fonctionnalits les programmeurs soccupent des tests unitaires les clients soccupent des tests dacceptation (fonctionnels)
Refactoring
chaque projet a une mtaphore pour son organisation, qui fournit des conventions faciles retenir
rcriture, restructuration et simplification permanente du code le code doit toujours tre propre
166
167
XP : pratiques (3)
XP : pratiques (4)
Semaine de 40 heures (35 en France ?) les programmeurs rentrent la maison lheure faire des heures supplmentaire est signe de problme moins derreurs de fatigue, meilleure motivation Des clients sur place
Programmation par paires (pair programming)

tout le code de production est crit par deux programmeurs devant un ordinateur lun pense limplmentation de la mthode courante, lautre tout le systme les paires changent les rles, les participants des paires changent
Proprit collective du code

tout programmeur qui voit une opportunit damliorer toute portion de code doit le faire, nimporte quel moment
lquipe de dveloppement a un accs permanent un vrai client/utilisateur (dans la pice d ct)

Des standards de codage
Intgration continue
utilisation dun gestionnaire de versions (e.g., CVS) tous les changements sont intgrs dans le code de base au minimum chaque jour : une construction complte (build) minimum par jour 100% des tests doivent passer avant et aprs lintgration
tout le monde code de la mme manire

tout le monde suit les rgles qui ont t dfinies il ne devrait pas tre possible de savoir qui a crit quoi
168
169
XP : pratiques (5)
XP : quelques point du site web
Rgles
lquipe dcide des rgles quelle suit, et peut les changer tout moment
Planning
User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks.
Coding
The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime. All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.
Espace de travail
tout le monde dans la mme pice
awareness
tableaux au murs matrialisation de la progression du projet

par les histoires (user stories) ralises et faire
papiers qui changent de position, sont rorganiss
Designing
Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.
Testing

par les rsultats des tests
170
171
XP : avantages
Concept intgr et simples Pas trop de management
XP : inconvnients
pas de procdures complexes pas de documentation maintenir communication directe programmation par paires
Appropri pour de petites quipes (pas plus de 10 dveloppeurs), ne passe pas lchelle
pour des groupes plus gros, il faut plus de structure et de documentation (ceremony)
Risque davoir un code pas assez document

des programmeur qui nauraient pas fait partie de lquipe de dveloppement auront sans doute du mal reprendre le code
Gestion continuelle du risque Estimation permanente des efforts fournir Insistance sur les tests : facilite lvolution et la maintenance
Pas de design gnrique

pas d'anticipation des dveloppements futurs
172
173
http://fr.wikipedia.org/wiki/Scrum
Scrum

Principes Scrum
Scrum : mle Phases

Initiation / dmarrage
Planning
dfinir le systme : product Backlog = liste de fonctionnalits, ordonnes par ordred de priorit et deffort
Isolement de l'quipe de dveloppement

l'quipe est isole de toute influence extrieure qui pourrait lui nuire. Seules l'information et les tches relies au projet lui parviennent : pas dvolution des besoins dans chaque sprint.
Dveloppement progressif
afin de forcer l'quipe progresser, elle doit livrer une solution tous les 30 jours. Durant cette priode de dveloppement l'quipe se doit de livrer une srie de fonctionnalits qui devront tre oprationnelles la fin des 30 jours.
Architecture
conception de haut-niveau
Dveloppement
Cycles itratifs (sprints) : 30j
amlioration du prototype
Pouvoir l'quipe
l'quipe reoit les pleins pouvoirs pour raliser les fonctionnalits. C'est elle qui dtient la responsabilit de dcider comment atteindre ses objectifs. Sa seule contrainte est de livrer une solution qui convienne au client dans un dlai de 30 jours.
Clture
Gestion de la fin du projet : livraison
Contrle du travail
le travail est contrl quotidiennement pour savoir si tout va bien pour les membres de l'quipe et la fin des 30 jours de dveloppement pour savoir si la solution rpond au besoin du client.
174
175
Scrum : rles responsabilits

Scrum : pratiques

Scrum Master
expert de lapplicatron de Scrum
Product Backlog
tat courant des tches accomplir
Effort Estimation
permanente, sur les entres du backlog
Product owner
responsable officiel du projet
Sprint
itration de 30 jours
Scrum Team
quipe projet.
Sprint Planning Meeting

runion de dcision des objectifs du prochain sprint et de la manire de les implmenter
Customer
participe aux runions lies aux fonctionnalits
Sprint Backlog
Product Backlog limit au sprint en cours
Management
prend les dcisions
Daily Scrum meeting

ce qui a t fait, ce qui reste faire, les problmes
Sprint Review Meeting

prsentation des rsultats du sprint
176
177
Mthodologies Crystal

La famille de mthodes Crystal

Alistair Cockburn (2002). Agile Software Development. Addison Wesley Le dveloppement logiciel vu comme un jeu coopratif de communication et dinvention
des projets diffrents et des mthodes diffrentes le projet change mesure que les gens changent
Familles conues partir de l'observation et des interviews Trouver chaque fois la mthode la moins rigide qui russira quand mme
haute productivit, haute tolrance focus sur la communication
Choix de la mthode en fonction de diffrents facteurs

taille en nombre de personnes / criticit pour le client (LEDC)
Exemples
Crystal Clear Crystal Yellow Crystal Orange Crystal Red
air-traffic control system banking system
small utilities
medium-sized productivity tool
178
179
Crystal Clear
C6-D6 Une seule quipe, un seul
Crystal Orange
C40-E40
plus de structure dquipes lus de coordination
endroit
Good, small teams produce good, small software products Communication troite
Rles
Tout le monde dans le mme immeuble Rles

Sponsor Expert mtier Expert IHM Expert techniques Analyste concepteur mtier Manager Architecte Concepteur mentor
sponsor dveloppeur snior concepteurs-programmeurs utilisateurs

Livraison incrmentale tous
les 2/3 mois
1-2 ans de dveloppement Importance du respect des dlais et de ladaptation au march 181
180
Plan

Conclusion
182
There is no silver bullet : le retour

Mme si le dveloppement incrmental permet de saffranchir de beaucoup de problmes, il y aura quand mme des problmes. Mais ceux-ci seront normalement dampleur plus faible, et mieux grs.
Toute mthode est adaptable et doit tre adapte

Mais, lorsque lon dbute, il vaut mieux ne pas trop scarter de la voie dcrite pour bien comprendre au dpart (cf. musique)
183
Crdits remerciements
J.L.
Annexe : gestion des composants et bibliothcaire
Sourrouille (INSA de Lyon) Sources

http://www.swen.uwaterloo.ca/~kostas/E CE355-05/lectures/Lect3-Ch15Unit2.ppt http://web.engr.oregonstate.edu/~cook/c lasses/cs569.agile.ppt
Qualit
niveau plus lev que celui dune application (surcot minimum 50%, en pratique 100%) une confiance absolue est ncessaire pour que la rutilisation soit effective
Une fonction : bibliothcaire

participe au choix des produits gnraliser contribue ou procde la gnralisation tablit des normes, rgles, niveaux de qualit, protocoles de mise en bibliothque classifie les produits de la bibliothque (critres) diffuse, informe, facilite laccs (outils)
184
185
(O. Boissier)
Annexe : coders dojo
Annexe : qualit du logiciel
Ide
parallle arts martiaux / conceptionprogrammation OO
il faut sentraner appliquer des routines connues avant de pouvoir commencer les utiliser de faon crative, voire en inventer de nouvelles les dbutant doivent apprendre des matres
Facteur externes (utilisateur)

Correction (validit)
aptitude rpondre aux besoins et remplir les fonctions dfinies dans le cahier des charges
Robustesse (fiabilit)
aptitude fonctionner dans des conditions non prvues au cahier des charges, ventuellement anormales
un exemple de formation
http://www.xpday.net/Xpday2005/CodersDojo.html
Extensibilit
facilit avec laquelle de nouvelles fonctionnalits peuvent tre ajoutes
186
187
(O. Boissier)
(O. Boissier)
Qualit du logiciel
Qualit du logiciel
Facteurs externes (suite)

Compatibilit
facilit avec laquelle un logiciel peut tre combin avec dautres
Facteurs internes (concepteur)

R-utilisabilit
aptitude dun logiciel tre rutilis, en tout ou en partie, pour dautres applications
Efficacit
utilisation optimale des ressources matrielles (processeur, mmoires, rseau, )
Vrifiabilit
aptitude dun logiciel tre test (optimisation de la prparation et de la vrification des jeux dessai)
Convivialit
facilit dapprentissage et dutilisation, de prparation des donnes, de correction des erreurs dutilisation, dinterprtation des retours
Portabilit
aptitude dun logiciel tre transfr dans des environnements logiciels et matriels diffrents
Intgrit (scurit)
aptitude dun logiciel se protger contre des accs non autoriss. 188
Lisibilit Modularit
189

CM Methodes Fin 6pp

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CM Methodes Fin 6pp

Transféré par

Droits d'auteur :

Formats disponibles

Plan

Two Tracks Unified Process

deux grandes sortes de risques

deux grandes sortes dvolutions

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

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

Two Tracks Unified Process

Capture de besoins fonctionnels Analyse

Capture des besoins techniques Conception gnrique

Prototype Conception prliminaire Conception dtaille Codage et tests Recette

Branche conception et dveloppement logiciel

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

dpend de lexistant architecture base de composant

architecture technique rutilisable

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

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

UP agile = les bonnes pratiques de UP

Propos par Craig Larman, prsent dans

Parce que UP est souvent considr comme complexe, formel et lourd

petit ensemble dactivits et dartefacts

plus que pour gnrer du code

doit tre adapt chaque projet

dans son utilisation

Sample UP Artifact Relationships Domain Model

Sale date ...

Sales LineItem quantity ...

use case names

Use Case Diagram

functional requirements that must be realized by the objects

make NewSale() enterItem (id, quantity)

starting events to design for, and detailed postcondition to satisfy

System Sequence Diagrams

item details, formats, validation

Customer Software Architect

: Register enterItem (itemID, quantity)

How: Tools Who

Register ... makeNewSale() enterItem(...) ... ...

Led by system analyst who is responsible for requirements definition.

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

Organisation physique : modlisation objet

Two adjacent projections.

: R e g is te r m a k e N e w Sa le ( ) e n te r Ite m ( ite m ID , q u a n tity )

: R e g is te r m a k e N e w Sa le ( ) e n te r Ite m ( ite m ID , q u a n tity )

c r e a te ( ) s p e c := g e tSp e c ific a tio n ( ite m ID ) a d d L in e Ite m ( s p e c , q u a n tity ) ... ...

c r e a te ( ) 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 ) ... ...

M1 MIAGE - SIMA 2005-2006 / Yannick

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

Petite histoire des mthodes Agile

Du rien au monumental lagile

les principaux mthodologues saccordent sur le Agile manifesto

projets Agile mixent des lments des principales mthodes

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

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

Principes communs des mthodes Agile

Mthodes adaptatives (vs. prdictives)

Insistance sur les hommes

participants plutt que plan Nombreuses

de dfinition unique un manifeste

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

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

Manifeste Agile : principes

objectif : promouvoir les principes et mthodes Agile http://www.agilealliance.com/

(transparents suivants) 158 159