Les exigences logicielles et la conception logicielle dans ...©rencePierreBour… · ⁄ Situer le projet dans le cadre de la ... Description des domaines de connaissance du génie

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)


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


1998 1999 2000 2001 2002 2003

Straw ManVersion

Straw ManVersion



Iron Man Version(Sub-phase 1)


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


1998 1999 2000 2001 2002 2003

Straw ManVersion

Straw ManVersion



Sous-Phase 1

Sous-Phase 2


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


6WDWXV�$FFRXQWLQJ


$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


¤ Développement professionnel

vFormation interne, “corporateuniversities” (SAP)

vConception de cours

vAuto-évaluation

vAuto-formation

25

www.swebok.org 49


¤ 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


¤ É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


¤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


¤ 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


¤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


¤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


¤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


¤Requirements elicitation

vRequirements sourcesØGoals,domain knowledge, stakeholders,

operational environment, organizational environment

vElicitation techniquesØInterviews, scenarios, prototypes, facilitated

meetings,observation

www.swebok.org 62


¤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


¤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


¤ Requirement specificationvSystem Definition DocumentØConcept of Operations

ØVision Document

vSystem requirements specification

vSoftware requirements specification

33

www.swebok.org 65


¤Requirements validation

vRequirements reviews

vPrototyping

vModel validation

vAcceptance tests

www.swebok.org 66


¤ 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

Documents

Les exigences logicielles et la conception logicielle dans ...©rencePierreBour… · ⁄ Situer le projet dans le cadre de la ... Description des domaines de connaissance du génie