View
217
Download
1
Category
Preview:
Citation preview
1
www.swebok.org 1
Les exigences logicielles et la Les exigences logicielles et la conception logicielle dans le conception logicielle dans le
Guide du corpus de Guide du corpus de connaissances en gconnaissances en géénie nie
logiciellogiciel
Pierre BourquePierre BourqueSW
EB
OK
ÉTS
www.swebok.org 2
Projet géré par :
Support corporatif :
2
www.swebok.org 3
Guide to the Guide to the SoftWareSoftWare Engineering Engineering Body of Knowledge (SWEBOKBody of Knowledge (SWEBOK®®))
¤ Projet a débuté comme une collaboration entreIEEE Computer Society, Association for Computing Machineryet 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 4
Trial Version (2001)Trial Version (2001)
3
www.swebok.org 5
2004 SWEBOK Guide2004 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 6
Liste des domaines de connaissanceListe 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
4
www.swebok.org 7
Objectifs de la prObjectifs de la préésentationsentation
¤ 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 8
Plan de la prPlan de la préésentationsentation
¤¤ ContexteContexte¤ 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
5
www.swebok.org 9
““Software EngineeringSoftware 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 rNiveau rééel de maturitel de maturitéé??
www.swebok.org 10
QuQu’’estest--ce que le gce que le géénie logiciel?nie logiciel?
¤ IEEE 610.12:
vL’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).
6
www.swebok.org 11
Profession?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 AmericanMedicine: BasicBooks, 1982.
www.swebok.org 12
DDééveloppement professionnelveloppement professionnel
Éducation professionnelle
initiale
Développement des habiletés
Un ou les deux
Plein statut professionnel
Certification Octroi de permis
Accréditation
Développement professionnel
Code d’éthique
Sociétés professionnels
Adapté de Steve McConnell, Afterthe Gold Rush, Microsoft Press, 1999, p. 93
7
www.swebok.org 13
Plan de la prPlan de la préésentationsentation¤ Contexte
¤¤ PortPortéée, objectifs et publics pre, objectifs et publics préévusvus¤ 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 14
Objectifs du GuideObjectifs 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
8
www.swebok.org 15
Objectifs du GuideObjectifs 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 16
Publics visPublics visééss
¤ Organisations privées et publiques
¤ Praticiens
¤ Responsables des politiques
¤ Sociétés professionnelles
¤ Étudiants
¤ Enseignants
9
www.swebok.org 17
Hors mandatHors mandat : :
¤ Développement d’un curriculum
¤ Description exhaustive d’un domaine de connaissance
¤ Toutes les catégories de connaissances (ex. R & D)
www.swebok.org 18
CatCatéégories de connaissance gories de connaissance
GénéralementReconnue
Avancée
Spé
cial
isée
etRecherche
Point de mire du Guide SWEBOK
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
10
www.swebok.org 19
Maths
Connaissances GL avancées
GuideSWEBOK
Inform.
...
Connaissancesd’un
IngénieurLogiciel
ConnaissancesGL spécialisées
Connaissancesdu domaine
d’application
www.swebok.org 20
Trois principes conducteursTrois 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
11
www.swebok.org 21
Plan de la prPlan de la préésentationsentation¤ Contexte¤ Portée, objectifs et publics prévus
¤¤ StratStratéégie de dgie de dééveloppementveloppement¤ 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 22
IntervenantsIntervenants
¤ Équipe éditoriale
¤ Comité aviseur : Industrial AdvisoryBoard
¤ Éditeurs associés des domaines de connaissances
¤ Réviseurs internationaux
12
www.swebok.org 23
CompositionComposition du du IndustrialIndustrialAdvisoryAdvisory BoardBoard::¤ Industrie
¤ Société professionnelle
¤ Organisme de normalisation : ISO
www.swebok.org 24
ÉÉquipe quipe ééditorialeditoriale¤ « Champion » du projet :
v Leonard Tripp, Président, 1999, IEEE Computer Society
¤ Éditeurs exécutifs : v Alain Abran, ÉTSv James W. Moore, The MITRE Corp.
¤ Éditeurs :v Pierre Bourque, ÉTSv Robert Dupuis, UQAM
13
www.swebok.org 25
Rôles du Rôles du IndustrialIndustrial AdvisoryAdvisoryBoardBoard¤ 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 26
ÉÉditeurs associditeurs associéés des s des domaines de connaissancedomaines 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
14
www.swebok.org 27
Approche en trois phases Approche en trois phases
1998 1999 2000 2001 2002 2003
Straw ManVersion
Straw ManVersion
Stone Man Phase(Trial Version)
Stone Man Phase(Trial Version)
Iron Man Version(Sub-phase 1)
Iron Man Phase(2004 Version)
www.swebok.org 28
Phase Phase StrawStraw ManMan
¤ Définir la stratégie de développement
¤ Créer un « élan » dans la profession
¤ Démarrer la phase Stone Man
vListe suggérée de domaines de connaissance
vListe suggérée des disciplines connexes
15
www.swebok.org 29
Approche en trois phases Approche en trois phases
1998 1999 2000 2001 2002 2003
Straw ManVersion
Straw ManVersion
Stone Man Phase(Trial Version)
Stone Man Phase(Trial Version)
Iron Man Version(Sub-phase 1)
Iron Man Phase(2004 Version)
www.swebok.org 30
Processus de rProcessus de réévision vision -- Trial VersionTrial Version
Version 0.1
ReviewCycle 1
Version 0.5
Reviewcycle 2
Version 0.7
ReviewCycle 3
Version 0.9
Limited number of domain experts
Selected users
Community
16
www.swebok.org 31
RRééviseursviseurs (Trial Version)(Trial Version)
Niveau d'éducation
DoctoratMaîtriseBacc.Autres
USAEuropeCanadaAustralieAsieAmer. L.Pas connu
Nombre d'employés
0-5050-500500+
Version 0.1: 33 réviseurs
Version 0.5: 195 réviseurs
Version 0.7: 378 + 5 pays ISO
www.swebok.org 32
17
www.swebok.org 33
RRéésolution des commentairessolution des commentaires
www.swebok.org 34
RRéésolutions formelles au solutions formelles au printemps 2001printemps 2001¤ SWEBOK Industrial Advisory Board et
IEEE Computer Society Board of Governors
vUn processus rigoureux a été suivi
vLe guide est prêt pour des essais sur le terrain
18
www.swebok.org 35
Approche en trois phases Approche en trois phases
1998 1999 2000 2001 2002 2003
Straw ManVersion
Straw ManVersion
Stone Man Phase(Trial Version)
Stone Man Phase(Trial Version)
Sous-Phase 1
Sous-Phase 2
Iron Man Phase(2004 Version)
www.swebok.org 36
RRééviseurs (2004 Version)viseurs (2004 Version)
¤ 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
4 741
28
8
0
5
1 0
1 5
2 0
2 5
3 0
3 5
4 0
4 5
5 0
0-9 years 10-19 years 20-29 years 30-39 years
Num
ber
of R
evie
wer
s
17
48 44
13
20
1 0
2 0
3 0
4 0
5 0
6 0
0-9 years 10-19 years 20-29 years 30-39 years 40-49 years
Num
ber
of R
evie
wer
s
Années d’expérience dans le domaine
Années d’expérience en industrie
19
www.swebok.org 37
RRéésolutions formelles solutions formelles ààll’’hiver 2004hiver 2004¤ Endossement du Guide SWEBOK par
Industrial Advisory Board et IEEE Computer Society Board of Governors
www.swebok.org 38
Plan de la prPlan de la préésentationsentation¤ Contexte¤ Portée, objectifs et publics prévus¤¤ StratStratéégie de dgie de dééveloppementveloppement
¤ Contenu du Guide¤ Applications du Guide¤ Évolution du Guide¤ Les exigences logicielles dans le Guide¤ La conception logicielle dans le Guide¤ Conclusion
20
www.swebok.org 39
Bien livrablesBien 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
www.swebok.org 40
Description des domaines de Description des domaines de connaissance du gconnaissance du géénie logicielnie logiciel
Classification des Sujets
Matrice Sujets & Références Références
Description des sujets
Classification de Bloom
Disciplinesconnexes
21
5HODWHG' LVFLSOLQHV
&RPSXWHU6FLHQFH
0DQDJHPHQW
0DWKHPDWLFV
3URMHFWPDQDJHPHQW
4XDOLW\PDQDJHPHQW
6RIWZDUH( UJRQRPLFV
6\VWHPVHQJLQHHULQJ
&ORVXUH
3URFHVV$VVHVVPHQW
6RIWZDUH�' HVLJQ�7RROV
*XLGH�WR�WKH�6 RIWZ DUH�( QJLQHHULQJ�%RG\ � RI�. QRZOHGJH
������9�
6RIWZDUH&RQILJXUDWLRQ0DQDJHPHQW
6RIWZDUH(QJLQHHULQJ�7RROV
DQG�0 HWKRGV
6RIWZDUH(QJLQHHULQJ
3URFHVV6RIWZDUH�4XDOLW\
6RIWZDUH&RQILJXUDWLRQ0DQDJHPHQW)XQGDPHQWDOV
.H \V,VVXHV�LQ
6&0
6RIWZDUH&RQILJXUDWLRQ
&RQWURO
6RIWZDUH&RQILJXUDWLRQ
6WDWXV�$FFRXQWLQJ
6RIWZDUH&RQILJXUDWLRQ
$XGLWLQJ
6RIWZDUH�5HOHDVH0DQDJHPHQW�DQG
' HOLYHU\ 6RIWZDUH�0 HWKRGV
6RIWZDUH�7RROV3URFHVV
,PSOHPHQWDWLRQDQG�&KDQJH
3URFHVV�DQG3URGXFW
0HDVXUHPHQW
6RIWZDUH�4XDOLW\)XQGDPHQWDOV
6RIWZDUH�4XDOLW\0DQDJHPHQW3URFHVVHV
+HXULVWLF�0 HWKRGV
)RUPDO�0 HWKRGV
3URWRW\SLQJ�0 HWKRGV
6RIWZDUH�5 HTXLUHPHQWV7RROV
6RIWZDUH�7 HVWLQJ�7 RROV
6RIWZDUH�0 DLQWHQDQFH7RROV
6RIWZDUH�( QJLQHHULQJ3URFHVV�7 RROV
3URFHVV' HILQLWLRQ
3UDFWLFDO&RQVLGHUDWLRQV
6RIWZDUH�&RQVWUXFWLRQ7RROV
6RIWZDUH�4 XDOLW\ � 7RROV
6RIWZDUH�&RQILJXUDWLRQ0DQDJHPHQW�7RROV
6RIWZDUH�( QJLQHHULQJ0DQDJHPHQW�7RROV
,QIUDVWUXFWXUH�6 XSSRUW7RROV
0LVFHOODQHRXV�7RRO,VVXHV
0LVFHOODQHRXV�0 HWKRG,VVXHV
6RIWZDUH(QJLQHHULQJ0DQDJHPHQW
,QLWLDWLRQ�DQG6FRSH
' HILQLWLRQ
6RIWZDUH3URMHFW
3ODQQLQJ
6RIWZDUH�3URMHFW(QDFWPHQW
5HYLHZ�DQG(YDOXDWLRQ
6 : � ( QJLQHHULQJ0HDVXUHPHQW
&RPSXWHU(QJLQHHULQJ
22
6RIWZDUH5 HTXLUHP HQWV
5HTXLUHPHQWV( OLFLWDWLRQ
6RIWZDUH5HTXLUHPHQWV)XQGDPHQWDOV
' HILQLWLRQ�RI6RIWZDUH5HTXLUHPHQW
3URGXFW�DQG3URFHVV5HTXLUHPHQWV
)XQFWLRQDO�DQG1RQ�IXQFWLRQDO5HTXLUHPHQWV
(PHUJHQW3URSHUWLHV
4XDQWLILDEOH5HTXLUHPHQWV
6\VWHP5HTXLUHPHQWVDQG�6RIWZDUH5HTXLUHPHQWV
5HTXLUHPHQWV3URFHVV
3URFHVV�0 RGHOV
3URFHVV�$ FWRUV
3URFHVV�6XSSRUWDQG�0 DQDJ HP HQW
3URFHVV�4 XDOLW\DQG�,P SURYHP HQW
5HTXLUHPHQWV6RXUFHV
( OLFLWDWLRQ7HFKQLTXHV
5HTXLUHPHQWV&ODVVLILFDWLRQ
&RQFHSWXDO0 RGHOLQJ
$ UFKLWHFWXUDO' HVLJQ�DQG5HTXLUHPHQWV$ OORFDWLRQ
5HTXLUHPHQWV1HJRWLDWLRQ
5HTXLUHPHQWV6SHFLILFDWLRQ
6\VWHP' HILQLWLRQ' RFXPHQW
6\VWHPV5HTXLUHPHQWV6SHFLILFDWLRQ
3UDFWLFDO&RQVLGHUDWLRQ
5HTXLUHPHQWV9DOLGDWLRQ
5HTXLUHPHQWV5HYLHZV
3URWRW\SLQJ
0 RGHO9DOLGDWLRQ
$FFHSWDQFH7HVWV
&KDQJH0 DQDJHPHQW
5HTXLUHPHQWV$ WWULEXWHV
5HTXLUHPHQWV7UDFLQJ
6RIWZDUH5HTXLUHPHQWV6SHFLILFDWLRQ
,WHUDWLYH�1 DWXUHRI�5 HTXLUHP HQWV3URFHVV
0 HDVXULQJ5HTXLUHPHQWV
5HTXLUHPHQWV$QDO\VLV
www.swebok.org 44
Principales amPrincipales amééliorations liorations apportapportéées es àà la Version 2004la 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
23
www.swebok.org 45
Principales amPrincipales amééliorations liorations apportapportéées es àà la Version 2004la 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 46
Plan de la prPlan de la préésentationsentation¤ Contexte¤ Portée, objectifs et publics prévus¤¤ StratStratéégie de dgie de dééveloppementveloppement¤ Contenu du Guide
¤ Applications du Guide¤ Évolution du Guide¤ Les exigences logicielles dans le Guide¤ La conception logicielle dans le Guide¤ Conclusion
24
www.swebok.org 47
Applications du GuideApplications du Guide
¤ Industrie & gouvernementv 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 48
Applications du GuideApplications du Guide
¤ Développement professionnel
vFormation interne, “corporateuniversities” (SAP)
vConception de cours
vAuto-évaluation
vAuto-formation
25
www.swebok.org 49
Applications du GuideApplications du Guide
¤ Certification (IEEE CS) et « licensing»(Ordre des ingénieurs du Québec)vQuestions d’examen
vMatériels d’étudevEn génie logiciel et pour d’autres
disciplinesvPourrait être sur un sous-ensemble du
Guide
www.swebok.org 50
Applications du GuideApplications du Guide
¤ Éducation :
vConception et évaluation de curriculumØ (CC2001, ÉTS, Iceland, Monash)
vAccréditation
vConception et évaluation de coursØ (Arizona State, ETS)
26
www.swebok.org 51
Plan de la prPlan de la préésentationsentation¤ 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 52
ModalitModalitéés ds d’é’évolution du Guide volution du Guide (en cours de d(en cours de dééfinition)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
27
www.swebok.org 53
Plan de la prPlan de la préésentationsentation¤ 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 54
6RIWZDUH5 HTXLUHP HQWV
5HTXLUHPHQWV( OLFLWDWLRQ
6RIWZDUH5HTXLUHPHQWV)XQGDPHQWDOV
' HILQLWLRQ�RI6RIWZDUH5HTXLUHPHQW
3URGXFW�DQG3URFHVV5HTXLUHPHQWV
)XQFWLRQDO�DQG1RQ�IXQFWLRQDO5HTXLUHPHQWV
(PHUJHQW3URSHUWLHV
4XDQWLILDEOH5HTXLUHPHQWV
6\VWHP5HTXLUHPHQWVDQG�6RIWZDUH5HTXLUHPHQWV
5HTXLUHPHQWV3URFHVV
3URFHVV�0 RGHOV
3URFHVV�$ FWRUV
3URFHVV�6XSSRUWDQG�0 DQDJ HP HQW
3URFHVV�4 XDOLW\DQG�,P SURYHP HQW
5HTXLUHPHQWV6RXUFHV
( OLFLWDWLRQ7HFKQLTXHV
5HTXLUHPHQWV&ODVVLILFDWLRQ
&RQFHSWXDO0 RGHOLQJ
$ UFKLWHFWXUDO' HVLJQ�DQG5HTXLUHPHQWV$ OORFDWLRQ
5HTXLUHPHQWV1HJRWLDWLRQ
5HTXLUHPHQWV6SHFLILFDWLRQ
6\VWHP' HILQLWLRQ' RFXPHQW
6\VWHPV5HTXLUHPHQWV6SHFLILFDWLRQ
3UDFWLFDO&RQVLGHUDWLRQ
5HTXLUHPHQWV9DOLGDWLRQ
5HTXLUHPHQWV5HYLHZV
3URWRW\SLQJ
0 RGHO9DOLGDWLRQ
$FFHSWDQFH7HVWV
&KDQJH0 DQDJHPHQW
5HTXLUHPHQWV$ WWULEXWHV
5HTXLUHPHQWV7UDFLQJ
6RIWZDUH5HTXLUHPHQWV6SHFLILFDWLRQ
,WHUDWLYH�1 DWXUHRI�5 HTXLUHP HQWV3URFHVV
0 HDVXULQJ5HTXLUHPHQWV
5HTXLUHPHQWV$QDO\VLV
28
www.swebok.org 55
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤Software requirements fundamentals-1vDefinition 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 56
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤Software requirements fundamentals-2vFunctional 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
29
www.swebok.org 57
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤ Software requirements fundamentals -3 vQuantifiable requirementsØVery important and often not easy to specify for the non-
functional 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 58
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤Requirements engineering process-1vProcess 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?
30
www.swebok.org 59
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences 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 60
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences 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
31
www.swebok.org 61
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤Requirements elicitation
vRequirements sourcesØGoals,domain knowledge, stakeholders,
operational environment, organizational environment
vElicitation techniquesØInterviews, scenarios, prototypes, facilitated
meetings,observation
www.swebok.org 62
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences 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
32
www.swebok.org 63
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences 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 64
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤ Requirement specificationvSystem Definition DocumentØConcept of Operations
ØVision Document
vSystem requirements specification
vSoftware requirements specification
33
www.swebok.org 65
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤Requirements validation
vRequirements reviews
vPrototyping
vModel validation
vAcceptance tests
www.swebok.org 66
Taxonomie SWEBOK pour les Taxonomie SWEBOK pour les exigences logiciellesexigences logicielles
¤ Practical ConsiderationsvIterative 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
34
www.swebok.org 67
Plan de la prPlan de la préésentationsentation¤ 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
Conception logicielleConception 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 ».
35
www.swebok.org
Objectifs de la conception Objectifs de la conception logiciellelogicielle¤ 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 70
Software Design
Software Design Fundamentals
Key Issues in Software Design
Software Structure and Architecture
Software Design Notations
Software Design Strategies and
Methods
General design concepts
Concurrency
The context of software design
Enabling techniques
The software design process
Control and handling of events
Architectural structures and
viewpoints
Structural descriptions ( static view)
General Strategies
Distribution of components
Interaction and presentation
Error and exception handline and fault
tolerance
Data persistence
Design patterns (microarchitectural
patterns)
Architectural styles (macroarchitectural
patterns)
Families of programs and frameworks
Behavior descriptions (dynamic view)
Object-oriented design
Function-oriented (structured) design
Data-structrure centered design
Software Design Quality Analysis and Evaluation
Quality attributes
Measures
Quality analysis and evaluation techniques
Other methods
Figure 1 Breakdown of topics for the Software Design KA
Component- based design
36
www.swebok.org 71
Software Design Fundamentals 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
Context of Software Design
Software Design Process
Enabling Techniques for Software Design
www.swebok.org 72
GeneralGeneral Design ConceptsDesign 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
37
www.swebok.org 73
ContextContext of Software Designof 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 74
Software Design Software Design ProcessProcess
¤ Se divise en 2 parties importantesv 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.
38
www.swebok.org 75
EnablingEnabling techniques for techniques for Software DesignSoftware Design
¤ Ce concepts décrit les « principes » sous-jacents aux différentes approches du Software Designv 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 76
Key Issues in Software DesignKey Issues in Software Design
¤ Un certains nombre d’éléments clés doivent être considérésv 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
39
www.swebok.org 77
Architectural structures and viewpoints
Architectural style(macro-architectuiral patterns)
Design patterns(micro-architectural design)
Families of programs andframework
Software Structure Software Structure andandArchitectureArchitecture
www.swebok.org 78
Architectural Structure Architectural Structure andandViewpointsViewpoints¤ S. D. doit être décrit et documenté
selon différents points de vue. Ex:
vLogical view(point de vue des exigences)
vProcess view(concurrence)
vPhysical view(distribution)
vDevelopment view(découpage des composants)
40
www.swebok.org 79
Architectural StylesArchitectural Styles
¤ Un style d’architecture est « Un ensemble de contraintes qui définissent un ensemble ou une famille d ’architectures. » Ex:
vPipes and Filters
vClient-Server
vRule-Based
www.swebok.org 80
Design PatternsDesign Patterns
¤ Un patron de conception est « une solution commune à un problème commun dans un contexte donné » Ex:
vSingleton, Decorator, Mediator
41
www.swebok.org 81
FamiliesFamilies ofof ProgramsPrograms andandFrameworksFrameworks¤ 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 82
Software Design Software Design QualityQualityAnalysisAnalysis andand EvaluationEvaluation
Quality attributes
Quality analysis and evaluationtools
Measures
42
www.swebok.org 83
QualityQuality AttributesAttributes
¤ Différents attributs de qualité sont considérés pour obtenir une conception logicielle de qualité.
vDétectables à l ’exécution
vNon-détectables à l ’exécution
vReliés à la qualité de l’architecture
www.swebok.org 84
QualityQuality AnalysisAnalysis andandEvaluationEvaluation ToolsTools¤ On peut décomposer les outils et
techniques qui peuvent assurer la qualité du design en plusieurs catégories.
vSoftware design reviews
vStatic analysis
vSimulation and prototyping
43
www.swebok.org 85
MeasuresMeasures
¤ 2 grandes catégories de mesures quantitatives.
vOrientées-fonction
vOrientées-objet
www.swebok.org 86
Software Design NotationsSoftware Design Notations
¤ Différentes notations sont utilisées autant dans la partie architecturale que dans la partie détaillée.
Structural descriptions Behavioral descriptions
44
www.swebok.org 87
Structural DescriptionsStructural 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:
vClass and object diagrams
vComponent diagrams
vEntity-Relationship diagrams(ERD)
www.swebok.org 88
BehavioralBehavioral DescriptionsDescriptions
¤ C ’est une vue dynamique utilisant notations, graphiques et langages pour décrire le comportement des composantes et du logiciel. Ex:
vActivity diagrams
vCollaboration diagrams
vSequence diagrams
vState transition ans statechart diagrams
45
www.swebok.org 89
General strategies
Function oriented(structured)
Object-oriented
Data structure centered
Others
Les méthodes offrent un ensemble de notations, descriptions et d ’heuristiques qui permettent de les utiliser.
Software Design Software Design StrategiesStrategiesandand MethodsMethods
www.swebok.org 90
GeneralGeneral strategiesstrategies
¤ 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
46
www.swebok.org 91
FunctionFunction--orientedoriented ((structuredstructured) ) designdesign¤ 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 92
ObjectObject--orientedoriented designdesign
¤ Certains éléments clés de cette méthode sont :
vL ’encapsulation
vL ’héritage
vLe polymorphisme
47
www.swebok.org 93
Data Data structurestructure--centeredcentered
¤ La moins populaire des stratégies en Amérique du nord.
vLa définition des entrées/sorties du système est faites en premier.
vLes structures de contrôle du programme sont définies à partir des structures de données.
www.swebok.org 94
Plan de la prPlan de la préésentationsentation¤ 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
48
www.swebok.org 95
ConclusionConclusion
¤ 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 96
www.swebok.orgwww.swebok.org
Recommended