Texte de la conférence

SWEBOK
Les exigences logicielles et la
conception logicielle dans le
Guide du corpus de
connaissances en génie
logiciel
Pierre Bourque
ÉTS
www.swebok.org
1
Support corporatif :
Projet géré par :
www.swebok.org
2
1
Guide to the SoftWare Engineering
Body of Knowledge (SWEBOK®)
¤
¤
¤
¤
¤
¤
Projet a débuté comme une collaboration entre
IEEE Computer Society, Association for Computing Machinery
et UQAM
Participation internationale de membres de l’industrie, des
sociétés professionnelles, des organismes de normalisation,des
universitaires et des auteurs
Plus de 500 professionnels ont commenté le document
Projet réalisé en trois phases.
La version Trial du Guide est disponible depuis 2001 et la
version 2004 est depuis mai 2004.
La version 2004 est aussi publiée comme rapport technique
ISO.
® Registered in U.S. Patent Office
www.swebok.org
3
Trial Version (2001)
www.swebok.org
4
2
2004 SWEBOK Guide
¤
Disponible à www.swebok.org
¤
Est aussi disponible en format livre par
IEEE Computer Society Press
¤
Est publié comme ISO/IEC Technical
Report 19759
¤
Traduction et adaptation
en d’autres langues?
www.swebok.org
5
Liste des domaines de connaissance
¤
Exigences logicielles
¤
Conception du logiciel
¤
Construction du logiciel
¤
Test du logiciel
¤
Maintenance du logiciel
¤
Gestion de la configuration logicielle
¤
Gestion du génie logiciel
¤
Processus du génie logiciel
¤
Outils et méthodes du génie logiciel
¤
Qualité du logiciel
www.swebok.org
6
3
Objectifs de la présentation
¤
Présenter le projet de développement du guide au
corpus des connaissances en génie logiciel
¤
Situer le projet dans le cadre de la
« professionnalisation » du génie logiciel
¤
Présenter quelques applications du Guide
¤
Présenter un survol sur le chapitre sur les exigences
logicielles
¤
Présenter un survol du chapitre sur la conception
logicielle
www.swebok.org
7
Plan de la présentation
¤
Contexte
¤
Portée, objectifs et publics prévus
Stratégie de développement
Contenu du Guide
Applications du Guide
Évolution du Guide
Les exigences logicielles dans le Guide
La conception logicielle dans le Guide
Conclusion
¤
¤
¤
¤
¤
¤
¤
www.swebok.org
8
4
“Software Engineering”
¤
¤
Utilisé depuis 30 ans!
Des millions de pages sur le sujet!
¤
Des centaines de conférences chaque
année!
¤
Plusieurs programmes universitaires
Des millions de praticiens partout dans le
monde
¤
Niveau ré
réel de maturité
maturit é?
9
www.swebok.org
Qu’est-ce que le génie logiciel?
¤
IEEE 610.12:
v L’application d’une approche
systématique, disciplinée, quantifiable au
développement, l’exploitation et la
maintenance du logiciel; c’est-à-dire
l’application du génie au logiciel.
v (2) L’étude des approches telles que
définies dans (1).
www.swebok.org
10
5
Profession?
¤
Starr*:
v Connaissances et compétence validées par la
communauté des pairs
v Connaissances validées par consensus et ayant
des bases rationnelles et/ou scientifiques
v Les décisions et conseils sont basés sur des
valeurs communes aux membres
Ø *P. Starr, The Social Transformation of American
Medicine: BasicBooks, 1982.
11
www.swebok.org
Développement professionnel
Éducation
professionnelle
initiale
Accréditation
Développement des
habiletés
Sociétés
professionnels
Un ou les deux
Certification
Octroi de
permis
Plein statut
professionnel
Développement
professionnel
Code d’éthique
www.swebok.org
Adapté de Steve
McConnell, After
the Gold Rush,
Microsoft Press,
1999, p. 93
12
6
Plan de la présentation
¤
Contexte
¤
Porté
Port
ée, objectifs et publics pré
prévus
¤
Stratégie de développement
Contenu du Guide
Applications du Guide
Évolution du Guide
Les exigences logicielles dans le Guide
La conception logicielle dans le Guide
Conclusion
¤
¤
¤
¤
¤
¤
www.swebok.org
13
Objectifs du Guide
¤
Identifier le contenu du corpus des
connaissances en génie logiciel
¤
Fournir un index au corpus des
connaissances
¤
Promouvoir une vision uniforme du
génie logiciel
www.swebok.org
14
7
Objectifs du Guide
¤
Préciser la place et définir la frontière
du génie logiciel par rapport aux autres
disciplines: en particulier l ’informatique, la
gestion de projets, le génie informatique et les
mathématiques
¤
Fournir la base pour le développement
de programmes universitaires et du
matériel de certification / permis des
individus
www.swebok.org
15
Publics visés
¤
Organisations privées et publiques
¤
Praticiens
¤
Responsables des politiques
¤
Sociétés professionnelles
¤
Étudiants
¤
Enseignants
www.swebok.org
16
8
Hors mandat :
¤
Développement d’un curriculum
¤
Description exhaustive d’un domaine
de connaissance
¤
Toutes les catégories de
connaissances (ex. R & D)
17
www.swebok.org
Spécialisée
Catégories de connaissance
Généralement
Reconnue
Point de mire du
Guide SWEBOK
Avancée
et
Recherche
Généralement reconnue :
« Applicable à la plupart
des projets la plupart du
temps et il existe un large
consensus sur sa valeur et
son efficacité » PMI
En termes opérationnels, le point de mire du Guide
SWEBOK est un baccalauréat « anglo-saxon »
suivi de quatre
ans d’expérience
www.swebok.org
18
9
Connaissances
du domaine
d’application
Connaissances
GL avancées
Inform.
Connaissances
GL spécialisées
Guide
SWEBOK
Connaissances
d’un
Ingénieur
Logiciel
Maths
...
www.swebok.org
19
Trois principes conducteurs
¤
¤
¤
Transparence : le processus de
développement est documenté et public
Recherche de consensus :
établissement d’un consensus parmi les
intervenants de l’industrie, des sociétés
professionnelles, des sociétés normatives
et des universités
Gratuit sur le Web
www.swebok.org
20
10
Plan de la présentation
¤
Contexte
¤ Portée, objectifs et publics prévus
¤
Straté
Strat
égie de dé
développement
¤
Contenu du Guide
Applications du Guide
Évolution du Guide
Les exigences logicielle dans le Guide
La conception logicielle dans le Guide
Conclusion
¤
¤
¤
¤
¤
www.swebok.org
21
Intervenants
¤
Équipe éditoriale
¤
Comité aviseur : Industrial Advisory
Board
¤
Éditeurs associés des domaines de
connaissances
¤
Réviseurs internationaux
www.swebok.org
22
11
Composition du Industrial
Advisory Board:
¤
Industrie
¤
Société professionnelle
¤
Organisme de normalisation : ISO
www.swebok.org
23
Équipe éditoriale
¤
« Champion » du projet :
v Leonard Tripp, Président, 1999,
IEEE Computer Society
¤
Éditeurs exécutifs :
v Alain Abran, ÉTS
v James W. Moore, The MITRE Corp.
¤
Éditeurs :
v Pierre Bourque, ÉTS
v Robert Dupuis, UQAM
www.swebok.org
24
12
Rôles du Industrial Advisory
Board
¤
Fournir les points de vue des divers publics
Réviser et approuver la stratégie et les
rapports
¤
Contrôler le processus de développement
¤
¤
Aider à la promotion du Guide
Fournir du financement au projet
¤
Accroître la crédibilité du projet
¤
www.swebok.org
25
Éditeurs associ és des
domaines de connaissance
¤
21 spécialistes dans leurs domaines
respectifs
¤
Provenant d’Amérique du Nord, de
l’Europe et de l’Océanie
¤
Rédaction des textes et résolution des
commentaires
www.swebok.org
26
13
Approche en trois phases
Straw Man
Straw Man
Version
Version
Stone Man Phase
Stone Man Phase
(Trial Version)
(Trial Version)
Iron Man Phase
Iron Man Version
(2004 Version)
(Sub-phase 1)
1998
1999
2000
2001
2002
2003
www.swebok.org
27
Phase Straw Man
¤
Définir la stratégie de développement
¤
Créer un « élan » dans la profession
¤
Démarrer la phase Stone Man
v Liste suggérée de domaines de
connaissance
v Liste suggérée des disciplines connexes
www.swebok.org
28
14
Approche en trois phases
Straw Man
Straw Man
Version
Version
Stone Man Phase
Stone Man Phase
(Trial Version)
(Trial Version)
Iron Man Phase
Iron Man Version
(2004 Version)
(Sub-phase 1)
1998
1999
2000
2001
2002
2003
www.swebok.org
29
Processus de ré
révision - Trial Version
Version 0.1
Limited number of domain experts
Review
Cycle 1
Selected users
Version 0.5
Review
cycle 2
Version 0.7
Community
Review
Cycle 3
Version 0.9
www.swebok.org
30
15
Réviseurs (Trial Version)
Version 0.1: 33 réviseurs
Version 0.5: 195 réviseurs
Version 0.7: 378 + 5 pays ISO
USA
Europe
Canada
Australie
Asie
Amer. L.
Pas connu
Niveau d'éducation
Doctorat
Maîtrise
Bacc.
Autres
Nombre d'employés
0-50
50-500
500+
www.swebok.org
31
www.swebok.org
32
16
Résolution des commentaires
www.swebok.org
33
Résolutions formelles au
printemps 2001
¤
SWEBOK Industrial Advisory Board et
IEEE Computer Society Board of
Governors
v Un processus rigoureux a été suivi
v Le guide est prêt pour des essais sur le
terrain
www.swebok.org
34
17
Approche en trois phases
Straw Man
Straw Man
Version
Version
Stone Man Phase
Stone Man Phase
(Trial Version)
(Trial Version)
Sous-Phase 1
Iron Man Phase
(2004 Version)
1998
1999
2000
SousPhase 2
2001
2002
2003
35
www.swebok.org
Réviseurs (2004 Version)
¤
¤
¤
Années d’expérience dans le domaine
60
Number of Reviewers
¤
Réviseurs inscrits: 573
Nombre de pays
représentés: 55
Nombre de
commentaires traités:
1020
Nombre de réviseurs
ayant fourni des
commentaires: 124
Nombre de pays
représentés: 21
50
48
40
44
30
20
10
13
17
2
0
0-9 years
10-19 years
20-29 years
30-39 years
40-49 years
Années d’expérience en industrie
50
45
Number of Reviewers
¤
40
47
35
41
30
25
28
20
15
10
8
5
0
www.swebok.org
0-9 years
10-19 years
20-29 years
30-39 years
36
18
Résolutions formelles à
l’hiver 2004
¤
Endossement du Guide SWEBOK par
Industrial Advisory Board et IEEE
Computer Society Board of Governors
www.swebok.org
37
Plan de la présentation
¤
Contexte
¤ Portée, objectifs et publics prévus
¤ Strat
Straté
égie de dé
d é veloppement
¤
Contenu du Guide
¤
Applications du Guide
Évolution du Guide
Les exigences logicielles dans le Guide
La conception logicielle dans le Guide
Conclusion
¤
¤
¤
¤
www.swebok.org
38
19
Bien livrables
¤
Consensus international sur les
domaines de connaissance
¤
Consensus international sur les sujets
et références de chaque domaine
¤
Consensus international sur les
disciplines connexes
39
www.swebok.org
Description des domaines de
connaissance du génie logiciel
Classification
des Sujets
Description
des sujets
Matrice Sujets
& Références
Classification
de Bloom
www.swebok.org
Références
Disciplines
connexes
40
20
*XLGHW
RW
KH6 RIW
Z DUH( QJ LQHHULQJ %RG\ RI . QRZ O
HGJ H
9
6RIW
ZDUH
&RQILJXUDWLRQ
0DQDJHPHQW
6RIWZDUH
(QJLQHHULQJ
0DQDJHPHQW
6RIW
ZDUH
&RQILJXUDWLRQ
0DQDJHPHQW
)XQGDPHQWDOV
Q
, LWLDWLRQDQG
6FRSH
' HL
IQLWLRQ
.H\V
,VVXHVLQ
6&0
6RIW
ZDUH
&RQILJXUDWLRQ
&RQWURO
6RIW
ZDUH
&RQILJXUDWLRQ
6WDWXV$ FFRXQW
LQJ
3URFHVV
,PSOHPHQWDWLRQ
DQG&KDQJH
6RIW
ZDUH
3URMHFW
3 ODQQLQJ
3URFHVV
' HILQLWLRQ
6RIWZDUH3URMHFW
(QDFW
PHQW
3URFHVV
$VVHVVPHQW
6RIWZDUH
(QJLQHHULQJ 7RRO
V
DQG0 HW
KRGV
6RIWZDUH4 XDOLW
\
6RIW
ZDUH7 RRO
V
6RIWZDUH4 XDOLW
\
)XQGDPHQWDOV
&RPSXWHU
(QJLQHHULQJ
6RIWZDUH4 XDOLW
\
0DQDJHPHQW
3URFHVVHV
&RPSXWHU
6FLHQFH
3UDFWLFDO
&RQVLGHUDWLRQV
0DQDJHPHQW
6RIWZDUH 5 HT XLUHPHQW
V
7RROV
6RIWZDUH' HVLJQ 7RRO
V
6RIWZDUH&RQVW
UXFW
LRQ
7RROV
6RIWZDUH7 HVW
LQJ 7 RRO
V
5HODWHG
' LVFLSOLQHV
6RIWZDUH 0 DLQW
HQDQF H
7RROV
5HYLHZ DQG
(YDOXDWLRQ
3URFHVVDQG
3URGXFW
0HDVXUHPHQW
6RIWZDUH( QJLQHHULQJ
3URFHVV7 RRO
V
6RIW
ZDUH
&RQILJXUDWLRQ
$XGLWLQJ
6RIWZDUH( QJLQHHULQJ
0DQDJHPHQW7RRO
V
,QIUDVWUXFWXUH6 XSSRUW
7RROV
6 : ( QJLQHHULQJ
0HDVXUHPHQW
0DWKHPDWLFV
6RIWZDUH4 XDO
LW
\ 7RRO
V
6RIWZDUH&RQILJXUDW
LRQ
0DQDJHPHQW7RRO
V
&ORVXUH
6RIW
ZDUH5 HO
HDVH
0DQDJHPHQW
DQG
' HOLYHU\
6RIWZDUH
(QJLQHHULQJ
3URFHVV
0LVFHOODQHRXV7RRO
,VVXHV
3URMHFW
PDQDJHPHQW
4XDOLW\
PDQDJHPHQW
6RIW
ZDUH
( UJRQRPLFV
6RIW
ZDUH0 HW
KRGV
+HXULVWLF0 HWKRGV
6\VW
HPV
HQJLQHHULQJ
)RUPDO0 HW
KRGV
3URWRW\SLQJ0 HW
KRGV
0LVFHOODQHRXV0 HW
KRG
,VVXHV
21
6RIW
ZDUH
5 HTXLUHP H
Q
W
V
6RIW
ZDUH
5HTXLUHPHQWV
)XQGDPHQWDOV
5HTXLUHPHQWV
3URFHVV
5HTXLUHPHQWV
( OLFLWDWLRQ
5HTXLUHPHQWV
$QDO\VLV
5HTXLUHPHQWV
6SHFLILFDWLRQ
5HTXLUHPHQWV
9DOLGDWLRQ
3UDFWLFDO
&RQVLGHUDWLRQ
' HILQLWLRQRI
6RIW
ZDUH
5HTXLUHPHQW
3URFHVV0 RGHOV
5HTXLUHPHQWV
6RXUFHV
5HTXLUHPHQWV
&ODVVLILFDWLRQ
6\VWHP
' HILQLWLRQ
' RFXPHQW
5HTXLUHPHQWV
5HYLHZV
,WHUDWLYH1 DW
XUH
RI 5 HTXLUHP HQW
V
3URFHVV
3URGXFW
DQG
3URFHVV
5HTXLUHPHQWV
3URFHVV$ FW
RUV
( OLFLWDWLRQ
7HFKQLTXHV
&RQFHSWXDO
0 RGHOLQJ
6\VWHPV
5HTXLUHPHQWV
6SHFLILFDWLRQ
3URWRW\SLQJ
&KDQJH
0 DQDJHPHQW
)XQFWLRQDODQG
1RQIXQFW
LRQDO
5HTXLUHPHQW
V
3URFHVV6XSSRUW
DQG0 DQDJ HP HQW
$ UFKLWHFWXUDO
' HVLJQDQG
5HTXLUHPHQWV
$ OORFDWLRQ
6RIW
ZDUH
5HTXLUHPHQWV
6SHFLILFDWLRQ
0 RGHO
9DOLGDWLRQ
5HTXLUHPHQWV
$ WWULEXWHV
(PHUJHQW
3URSHUWLHV
3URFHVV4 XDOLW
\
DQG,P SURYHP HQW
5HTXLUHPHQWV
1HJRWLDWLRQ
$FFHSWDQFH
7HVWV
5HTXLUHPHQWV
7UDFLQJ
4XDQWLILDEOH
5HTXLUHPHQWV
0 HDVXULQJ
5HTXLUHPHQWV
6\VWHP
5HTXLUHPHQWV
DQG6RIW
Z DUH
5HTXLUHPHQWV
Principales am éliorations
apportées à la Version 2004
¤
Uniformisation du contenu des chapitres en termes
de table des matières, décomposition des sujets,
concepts véhiculés, terminologie, références citées
et style de rédaction
¤
Améliorations structurelles importantes: Software
Construction, Software Engineering Management,
Software Quality, Software Engineering Process
¤
Amélioration de la cohésion entre le texte et la
décomposition des sujets proposés : Software
Requirements, Software Testing, Software
Maintenance
www.swebok.org
44
22
Principales am éliorations
apportées à la Version 2004
¤
Rajout d’un chapitre sur les disciplines connexes
(au lieu d’une annexe)
¤
Ajout d’une annexe sur les normes en génie logiciel
et renforcement significatif des liens entre les
chapitres et les normes du domaine
¤
Mise à jour du matériel de référence
¤
Analyse et prise d’action selon les essais
documentés du Guide
¤
Résolution des commentaires des réviseurs
www.swebok.org
45
Plan de la présentation
¤
Contexte
¤ Portée, objectifs et publics prévus
¤ Strat
Straté
égie de dé
d é veloppement
¤ Contenu du Guide
¤
Applications du Guide
¤
Évolution du Guide
¤ Les exigences logicielles dans le Guide
¤ La conception logicielle dans le Guide
¤ Conclusion
www.swebok.org
46
23
Applications du Guide
¤
Industrie & gouvernement
v Description de postes (Bombardier Transport)
v Embauche
v Création d’équipe de projets
v Planification de carrières (Construx)
v Négociation de contrats
v Politique gouvernementale (Turquie)
www.swebok.org
47
Applications du Guide
¤
Développement professionnel
v Formation interne, “corporate
universities” (SAP)
v Conception de cours
v Auto-évaluation
v Auto-formation
www.swebok.org
48
24
Applications du Guide
¤
Certification (IEEE CS) et « licensing»
(Ordre des ingénieurs du Québec)
v Questions d’examen
v Matériels d’étude
v En génie logiciel et pour d’autres
disciplines
v Pourrait être sur un sous-ensemble du
Guide
www.swebok.org
49
Applications du Guide
¤
Éducation :
v Conception et évaluation de curriculum
Ø (CC2001, ÉTS, Iceland, Monash)
v Accréditation
v Conception et évaluation de cours
Ø (Arizona State, ETS)
www.swebok.org
50
25
Plan de la présentation
¤
¤
Contexte
Portée, objectifs et publics prévus
Stratégie de développement
Contenu du Guide
Application du Guide
¤
Évolution du Guide
¤
¤
¤
¤
Les exigences logicielles dans le Guide
¤ La conception logicielle dans le Guide
¤ Conclusion
www.swebok.org
51
Modalités d’évolution du Guide
(en cours de définition)
¤
Droits d’auteur appartiennent à la Computer Society
v C’est à eux de définir les modalités d’évolution
¤
¤
¤
¤
¤
¤
Autofinancement de l’évolution
Dirigé par des professionnels du domaine (comme
les normes)
Coordination avec les projets reliés et implication
des parties concernées
Mise à jour continuelle avec publication officielle
selon des périodes fixes
Ouverture à tous et transparence du processus
Excellence technique
www.swebok.org
52
26
Plan de la présentation
¤
¤
Contexte
Portée, objectifs et publics prévus
Stratégie de développement
Contenu du Guide
Applications du Guide
Évolution du Guide
¤
Les exigences logicielles dans le Guide
¤
¤
¤
¤
¤
La conception logicielle dans le Guide
¤ Conclusion
53
www.swebok.org
6RIW
ZDUH
5 HTXLUHP H
Q
W
V
6RIW
ZDUH
5HTXLUHPHQWV
)XQGDPHQWDOV
5HTXLUHPHQWV
3URFHVV
5HTXLUHPHQWV
( OLFLWDWLRQ
5HTXLUHPHQWV
$QDO\VLV
5HTXLUHPHQWV
6SHFLILFDWLRQ
5HTXLUHPHQWV
9DOLGDWLRQ
3UDFWLFDO
&RQVLGHUDWLRQ
' HILQLWLRQRI
6RIW
ZDUH
5HTXLUHPHQW
3URFHVV0 RGHOV
5HTXLUHPHQWV
6RXUFHV
5HTXLUHPHQWV
&ODVVLILFDWLRQ
6\VWHP
' HILQLWLRQ
' RFXPHQW
5HTXLUHPHQWV
5HYLHZV
,WHUDWLYH1 DW
XUH
RI 5 HTXLUHP HQW
V
3URFHVV
3URGXFW
DQG
3URFHVV
5HTXLUHPHQWV
3URFHVV$ FW
RUV
( OLFLWDWLRQ
7HFKQLTXHV
&RQFHSWXDO
0 RGHOLQJ
6\VWHPV
5HTXLUHPHQWV
6SHFLILFDWLRQ
3URWRW\SLQJ
&KDQJH
0 DQDJHPHQW
)XQFWLRQDODQG
1RQIXQFW
LRQDO
5HTXLUHPHQW
V
3URFHVV6XSSRUW
DQG0 DQDJ HP HQW
$ UFKLWHFWXUDO
' HVLJQDQG
5HTXLUHPHQWV
$ OORFDWLRQ
6RIW
ZDUH
5HTXLUHPHQWV
6SHFLILFDWLRQ
0 RGHO
9DOLGDWLRQ
5HTXLUHPHQWV
$ WWULEXWHV
(PHUJHQW
3URSHUWLHV
3URFHVV4 XDOLW
\
DQG,P SURYHP HQW
5HTXLUHPHQWV
1HJRWLDWLRQ
$FFHSWDQFH
7HVWV
5HTXLUHPHQWV
7UDFLQJ
4XDQWLILDEOH
5HTXLUHPHQWV
0 HDVXULQJ
5HTXLUHPHQWV
6\VWHP
5HTXLUHPHQWV
DQG6RIW
Z DUH
5HTXLUHPHQWV
www.swebok.org
54
27
Taxonomie SWEBOK pour les
exigences logicielles
¤ Software
requirements fundamentals-1
vDefinition of a software requirement
Ø“a property which must be exhibited by
software developed or adapted to solve a
particular problem.”
Ø“an essential property of all software
requirements is that they be verifiable.”
vProduct and Process Requirements
www.swebok.org
55
Taxonomie SWEBOK pour les
exigences logicielles
¤ Software
requirements fundamentals-2
vFunctional and non-functional
requirements
ØFunctional requirements describe the functions
that the software is to execute
ØNon-functional requirements are the ones that
act to constrain the solution.
vEmergent properties
ØRequirements which cannot be addressed by a
single component
www.swebok.org
56
28
Taxonomie SWEBOK pour les
exigences logicielles
¤
Software requirements fundamentals -3
vQuantifiable requirements
Ø Very important and often not easy to specify for the nonfunctional requirements
vSystem and software requirements
Ø System means ‘an interacting combination of elements to
accomplish a defined objective. These include hardware,
software, firmware, people, information, techniques,
facilities, services, and other support elements,’
“International Council on Systems Engineering”
www.swebok.org
57
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
engineering process-1
vProcess models
Øgeneric models
Ønot a discrete front-end activity
Ørequirements must be put under configuration
management
Ømust be tailored to context
vProcess actors
ØWho are they?
www.swebok.org
58
29
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
engineering process-2
vProcess support
Ømakes the link from process activities to issues
of cost, human resources training and tools
www.swebok.org
59
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
engineering process-3
vProcess quality and improvement
Ørequirements engineering coverage by process
improvement standards and models
Ørequirements engineering measurement and
benchmarking
Øimprovement planning and implementation
www.swebok.org
60
30
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
elicitation
vRequirements sources
ØGoals,domain knowledge, stakeholders,
operational environment, organizational
environment
vElicitation techniques
ØInterviews, scenarios, prototypes, facilitated
meetings,observation
www.swebok.org
61
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
analysis-1
vRequirements classification
ØFunctional, non-functional,
priority,scope,volatility
vConceptual modeling
ØUnderstanding of the problem rather than
initiate the design of the solution
ØUML
www.swebok.org
62
31
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
analysis-2
vArchitectural design and requirements
allocation
ØOverlaps with design
ØOften same notations and requirements
ØImportant for project management
vRequirements negotiation
ØConflicting requirements
www.swebok.org
63
Taxonomie SWEBOK pour les
exigences logicielles
¤
Requirement specification
vSystem Definition Document
Ø Concept of Operations
Ø Vision Document
vSystem requirements specification
vSoftware requirements specification
www.swebok.org
64
32
Taxonomie SWEBOK pour les
exigences logicielles
¤ Requirements
validation
vRequirements reviews
vPrototyping
vModel validation
vAcceptance tests
www.swebok.org
65
Taxonomie SWEBOK pour les
exigences logicielles
¤
Practical Considerations
vIterative nature of requirements
vChange management
Ø Importance and required procedures
Ø Strongly linked to CM
vRequirement attributes
Ø Unique Identifier
Ø Strong link to Requirements Classification
vRequirements tracing
vMeasuring requirements
www.swebok.org
66
33
Plan de la présentation
¤
Contexte
¤
Portée, objectifs et publics prévus
¤
Stratégie de développement
¤
Contenu du Guide
¤
Applications du Guide
¤
É volution du Guide
¤
Les exigences logicielles dans le Guide
¤
La conception logicielle dans le Guide
¤
Conclusion
www.swebok.org
67
Conception logicielle
¤
La définition utilisée est celle de IEEE
qui dit que la conception logicielle est
à la fois :
v « Le processus de d éfinition de
l ’architecture, des composantes, des
interfaces et autres caractéristiques d ’un
système ou d ’une composante ».
v « Le résultat de ce processus ».
www.swebok.org
34
Objectifs de la conception
logicielle
¤
Doit analyser les exigences pour produire une
description de la structure interne du logiciel qui
servira à la construction du logiciel.
v Doit décrire l’architecture du logiciel.
v Doit décrire les composantes et les interfaces entre les
composantes avec suffisamment de détails pour
construire ces composantes
v Sert à faire le liens entre les exigences et la
construction(code et test).
v Produire en quelque sorte un plan (blueprint) du logiciel.
www.swebok.org
Software Design
Software Design
Fundamentals
Key Issues in
Software Design
Software Structure
and Architecture
General design
concepts
Concurrency
The context of
software design
Control and handling
of events
Architectural
structures and
viewpoints
The software
design process
Enabling techniques
Distribution of
components
Architectural styles
(macroarchitectural
patterns)
Error and exception
handline and fault
tolerance
Design patterns
(microarchitectural
patterns)
Interaction and
presentation
Software Design
Quality Analysis
and Evaluation
Quality attributes
Quality analysis and
evaluation techniques
Software
Design Notations
Structural
descriptions
( static view)
Behavior descriptions
(dynamic view)
Measures
Families of programs
and frameworks
Software Design
Strategies and
Methods
General Strategies
Function-oriented
(structured) design
Object-oriented
design
Data-structrure
centered design
Component- based
design
Data persistence
Other methods
Figure 1 Breakdown of topics for the Software Design KA
www.swebok.org
70
35
Software Design Fundamentals
¤
Cette section introduit 4 concepts qui offre une base
pour la compréhension du rôle et de la portée
du software design
General Design Concepts
Software Design Process
Context of Software Design
Enabling Techniques for Software Design
www.swebok.org
71
General Design Concepts
¤
Le « design » peut être vu comme une forme de
résolution de problème
¤
Par exemple un problème sans solution définitive
est intéressant pour comprendre les limites du
« design »
¤
Sert à comprendre le « design » dans le sens
général : buts, contraintes, alternatives,
représentations et solutions
www.swebok.org
72
36
Context of Software Design
¤
Sert à comprendre le rôle et la place de Software
Design
¤
Il est important de comprendre le contexte dans
lequel le design s ’harmonise, i.e., le cycle de vie
logiciel.
¤
Les caractéristiques majeures des exigences vs le
Software Design vs la construction(code) vs les
tests doivent être comprises.
www.swebok.org
73
Software Design Process
¤
Se divise en 2 parties importantes
v Architectural Design
Ø Décrit comment le logiciel est décomposé et organis é en
composantes.
v Detailed Design
Ø Décrit chaque composante
¤
Le résultat de ce processus sera un ensemble de
modèles et d’artéfacts qui décrit les décisions
majeures qui auront été prises.
www.swebok.org
74
37
Enabling techniques for
Software Design
¤
Ce concepts décrit les « principes » sous-jacents
aux différentes approches du Software Design
v Abstraction
v Couplage et cohésion
v Décomposition et modularité
v Encapsulation (data abstraction and information hiding)
v Séparer l’interface de l’implantation
v Complétude, suffisance et « primitivité »
www.swebok.org
75
Key Issues in Software Design
¤
Un certains nombre d’éléments clés doivent être
considérés
v Concurrence des composantes.
v Contrôle et manipulation des événements
v Distribution des composantes
v Manipulation des erreurs et des exceptions et la tolérance
aux fautes.
v Interaction et présentation
v Persistance des données
www.swebok.org
76
38
Software Structure and
Architecture
Architectural structures and
viewpoints
Design patterns
(micro-architectural design)
Architectural style
(macro-architectuiral patterns)
Families of programs and
framework
www.swebok.org
77
Architectural Structure and
Viewpoints
¤
S. D. doit être décrit et documenté
selon différents points de vue. Ex:
v Logical view(point de vue des exigences)
v Process view(concurrence)
v Physical view(distribution)
v Development view(découpage des
composants)
www.swebok.org
78
39
Architectural Styles
¤
Un style d’architecture est « Un
ensemble de contraintes qui
définissent un ensemble ou une famille
d ’architectures. » Ex:
v Pipes and Filters
v Client-Server
v Rule-Based
www.swebok.org
79
Design Patterns
¤
Un patron de conception est « une
solution commune à un problème
commun dans un contexte donné » Ex:
v Singleton, Decorator, Mediator
www.swebok.org
80
40
Families of Programs and
Frameworks
¤
Une possibilité pour la réutilisation des conceptions
logicielles est de faire des familles de
logiciels.(software product lines). Lesquelles sont
faites en identifiant les points communs et en
utilisant des composantes réutilisables qui satisfont
les membres des différentes familles.
¤
Un « framework » est un sous-système
partiellement complet qui peut être étendu en
« instanciant » correctement quelques « plug-ins »
spécifiques (aussi appelés « hot spots »).
www.swebok.org
81
Software Design Quality
Analysis and Evaluation
Quality attributes
Measures
Quality analysis and evaluation
tools
www.swebok.org
82
41
Quality Attributes
¤
Différents attributs de qualité sont
considérés pour obtenir une conception
logicielle de qualité.
v Détectables à l ’exécution
v Non-détectables à l ’exécution
v Reliés à la qualité de l’architecture
www.swebok.org
83
Quality Analysis and
Evaluation Tools
¤
On peut décomposer les outils et
techniques qui peuvent assurer la
qualité du design en plusieurs
catégories.
v Software design reviews
v Static analysis
v Simulation and prototyping
www.swebok.org
84
42
Measures
¤
2 grandes catégories de mesures
quantitatives.
v Orientées-fonction
v Orientées-objet
www.swebok.org
85
Software Design Notations
¤
Différentes notations sont utilisées
autant dans la partie architecturale que
dans la partie détaillée.
Structural descriptions
Behavioral descriptions
www.swebok.org
86
43
Structural Descriptions
¤
C ’est une vue statique souvent
graphique qui décrit et représente
l ’aspect structurel de la conception
logicielle Elle permet aussi de décrire
les composantes et leurs relations. Ex:
v Class and object diagrams
v Component diagrams
v Entity-Relationship diagrams(ERD)
www.swebok.org
87
Behavioral Descriptions
¤
C ’est une vue dynamique utilisant
notations, graphiques et langages
pour décrire le comportement des
composantes et du logiciel. Ex:
v Activity diagrams
v Collaboration diagrams
v Sequence diagrams
v State transition ans statechart diagrams
www.swebok.org
88
44
Software Design Strategies
and Methods
Les méthodes offrent un ensemble de notations, descriptions
et d ’heuristiques qui permettent de les utiliser.
General strategies
Data structure centered
Function oriented(structured)
Others
Object-oriented
www.swebok.org
89
General strategies
¤
Les exemples les plus souvent citées sont :
v diviser pour régner et raffinement successif
v approche descendante et ascendante
v abstraction et camouflage d ’informations
v utilisation de patterns et PDL
v utilisation d ’approche incrémentale et itérative
www.swebok.org
90
45
Function-oriented (structured )
design
¤
Une des stratégies classiques en conception
logicielle
¤
Décomposition en fonctions importantes du logiciel
et leur élaboration en utilisant une approche
descendante (top-down)
¤
Habituellement utilisée après une analyse structurée
produisant les diagramme de flux de données (DFD)
et la description des processus associés.
¤
Il y a eu plusieurs stratégies et heuristiques
proposées pour améliorer les DFD.
www.swebok.org
91
Object-oriented design
¤
Certains éléments clés de cette
méthode sont :
v L ’encapsulation
v L ’héritage
v Le polymorphisme
www.swebok.org
92
46
Data structure-centered
¤
La moins populaire des stratégies en
Amérique du nord.
v La définition des entrées/sorties du
système est faites en premier.
v Les structures de contrôle du programme
sont définies à partir des structures de
données.
www.swebok.org
93
Plan de la présentation
¤
¤
Contexte
Portée, objectifs et publics prévus
Stratégie de développement
Contenu du Guide
Applications du Guide
Évolution du Guide
Les exigences logicielles dans le Guide
La conception logicielle dans le Guide
¤
Conclusion
¤
¤
¤
¤
¤
¤
www.swebok.org
94
47
Conclusion
¤
Les exigences logicielles occupent une
place importante en génie logiciel et
dans le Guide SWEBOK
¤
Un consensus sur un corpus de
connaissances est un élément-clé dans
l’évolution de la discipline
www.swebok.org
95
www.swebok.org
www.swebok.org
96
48