1. Université Mohammed V-Faculté des sciences de Rabat
Master Informatique Appliqué au Développement Offshore
SWEBOK
Réalisé par:
Mlle DAOUIJI Samia (s.daouiji@gmail.com)
Mlle SOUHAL Wafa(souhal.wafa@gmail.com)
1

2. 1 Introduction
PLAN







2 Développement du projet SWEBOK
3 SWEBOK V 2004
4 Les principaux chapitres du guide du SWEBOK
Les exigences logicielles
Construction logicielle
Qualité logicielle
Disciplines connexes au génie logiciel
5 Conclusion 2

3. 3

4.  Le SWEBOK est le document de base de l’IEEE-Computer-
Society pour la normalisation en ingénierie du logiciel.
 Bien qu’il n’ait pas comme objectif d’être totalement
conforme à la norme ISO 12207 sur le cycle de vie des
processus logiciels, il prête une attention particulière au
respect de la comptabilité avec cette norme.
 La norme ISO 12207 a pour objectif de poser la référence
pour les processus du cycle de vie logiciel pris dans sa
généralité avec des processus de bases, des processus
supports et des processus organisationnels.
4

5.  Le domaine de connaissances du génie logiciel couvre en
particulier:
le cycle de vie d'un logiciel,
les activités clés du cycle de vie (depuis la demande d'un maître
d'ouvrage jusqu'à la mise hors service définitive du produit),
l'ordre dans lequel ces activités sont effectuées.
 Il couvre également les différentes personnes impliquées:
technico commercial,
les ingénieurs,
les acheteurs,
les utilisateurs,
le directeur des systèmes d'information.
5

6.  Selon le SWEBOK les activités clés du cycle de vie d'un logiciel
sont :
* • L’analyse fonctionnelle
* • L’architecture
* • La programmation
* • Les tests
* • La validation
* • La maintenance
* • La gestion de projet
6

7.  Le projet SWEBOK a pour but de formaliser de manière
consensuelle le contenu de la discipline d’ingénierie du logiciel
en 10 domaines distincts.
Le SWEBOK s’adresse aux :
enseignants chargés de bâtir des programmes de
l’enseignement supérieur et étudiants
entreprises privées et publiques : comme un guide de
connaissances du domaine pour mettre en place des
bonnes pratiques d’ingénierie du logiciel.
 Ce qui ne veut pas dire que tout ingénieur devra l’appliquer
sans réflexion.
7

8.  Le Guide SWEBOK n’inclut pas directement un processus de
certification.
 Ce Guide peut néanmoins être utilisé pour se préparer à des
certifications de l’IEEE comme le ‘CSDP’ : Certified software
development professionnal’.
8

9.  Le projet SWEBOK est le fruit d’une collaboration entre
universités, industries et associations professionnelles soit :
Associations
IEEE Computer society ,ACM (s’est retiré en
professionnel
les 2000)
Boeing, Conseil national de recherches
Canada, Raytheon, Construx, Conseil canadien
Corporatif des ingénieurs, Mitre, NIST, Rational (vendu en
2004), SAP
École de technologie supérieure, Université du
Académique
Québec à Montréal
9

10. 10

11. 11

12. 12

13. 13

14.  Les principes suivants sont à la base de l'approche de
développement pour ce projet:
La transparence
• le processus de développement est lui même publiés
et complètement documenté;
Consensus-building
• le processus de développement est conçu pour
construire, au fil du temps, un consensus (accord) dans
l'industrie, les sociétés professionnelles et les organismes
de normalisation;
Large distribution
• le guide restera libre au moins dans un format pour
assurer une diffusion aussi large que possible. 14

15. 15

16.  Le Guide SWEBOK a été développé en trois phases:
La version Straw Man - 1997
La version Stone Man - 2001
La version Iron Man - 2004
16

17. La version Straw Man - 1997:
 Publiée en Septembre 1998.
 Objectif principal du rapport initial : proposer une liste
provisoire des domaines de connaissances pour le SWEBOK.
 Ce rapport propose également une liste provisoire des
disciplines qui interagissent avec le génie logiciel.
 Comme son nom l'indique, cette version homme de paille est
destinée à être remis en question et de susciter un débat
vigoureux.
17

18. La version Stone Man - 2001 :
 Basé sur les résultats de la phase de Strawman, une deuxième
phase Stoneman a été initiée.
 Le développement de la version Stoneman du SWEBOK a passé
par trois cycles de révision:
 Cycle de révision 1: L'accent a été mis sur le choix des thèmes et les
définitions des domaines de connaissances par un ensemble
limité d'experts .
Période de révision: avril et mai 1999
 Cycle de révision 2: La révision a été organisé par des des
formateurs, éducateurs, praticiens, chercheurs, praticiens de
de petite / moyenne organisations..
Période d'examen: Juillet, Août et Septembre 1999.
 Cycle d'examen 3: L'accent a été basé sur une révision à grande
échelle par des individus et des organisations
représentant une section adaptée de groupes d'intérêts potentiels.
Période d'examen: mai 2000. 18

19. La version Iron Man - 2004:
 Une version ultérieure Ironman a été achevée environ trois ans
après la version Stoneman.
 La phase Ironman sera composée de deux grandes sous-
phases (conditionnel au financement):
Sous-phase 1 (2000-2002):
- Expérimentation et utilisation d'essai du Guide
- Promotion du Guide
- Développement des "normes de performance" pour les
professionnels du génie logiciel
Sous-phase 2 (2002-2003):
- Développement de la version Ironman du Guide sur la base
des commentaires recueillis dans les sous-phases 1 et d'une
étude approfondie similaire à la procédure d'examen de la phase
de Stoneman. 19

20. Remarques :
 Fort développement du SWEBOK sur le plan international :
 Le nombre de références a été multiplié par 10 en l’espace
d’un an et demi.
 Utilisé avec la norme ISO 12207, permet de décrire les profils
des membres d’une équipe de projet informatique à recruter
et négocier des contrats de travail en fonction de ces profils.
 Le SWEBOK devra suivre l’évolution des connaissances de
bases en ingénierie logiciel, en fonction de l’avancement des
travaux de recherche et de l’évolution des pratiques
industrielles.
 La version 2004 du SWEBOK est la dernière version. Cette
version a été publiée en 2005 sous la forme d’un rapport
technique ISO 19759. 20

21.  Les ingénieurs en logiciel dans le monde
entier peuvent participer à l'élaboration du
guide. N'importe qui peut s'inscrire comme
réviseur.
21

22. 22

23.  Le Guide SWEBOK décrit les domaines de
connaissances généralement admises sur le génie logiciel.
 Ses 10 domaines de connaissances résument les concepts de
base et incluent une liste de référence pointant vers des
informations détaillées.
 Pour le Guide 2004 SWEBOK, les éditeurs du SWEBOK ont reçu
et répondu à près de 10000 commentaires de
378 réviseurs dans 41 pays.
 Une version HTML du guide est disponible gratuitement pour
tous grâce aux généreuses contributions de sociétés
commanditaires.
 Le Guide 2004 a également acquis une reconnaissance
internationale comme l’ISO Technical Report 19759.
23

24. 1 • Software REQUIREMENTS
2 • Software DESIGN
3 • Software CONSTRUCTION
4 • Software TESTING
5 • Software MAINTENANCE
6 • Software CONFIGURATION MANAGEMENT
7 • Software ENGINEERING MANAGEMENT
8 • Software ENGINEERING PROCESS
9 • Software ENGINEERING TOOLS AND METHODS
10 • Software QUALITY
24

25.  La version 3 du guide SWEBOK est développée et
sera achevé fin 2011 ou début 2012.
 La version 3 du guide SWEBOK contient 15
domaines de connaissances:
25

26. 15 Domaines de connaissances:
1 • Software REQUIREMENTS
2 • Software DESIGN
3 • Software CONSTRUCTION
4 • Software TESTING
5 • Software ENGINEERING METHODS
6 • Software MAINTENANCE
7 • Software CONFIGURATION MANAGEMENT
8 • Software QUALITY
9 • Software ENGINEERING PROCESS
10 • Software ENGINEERING MANAGEMENT
11 • Software PROFESSIONAL PRACTICE
12 • Software ECONOMICS
13 • Computing FOUNDATIONS
14 • Mathematical FOUNDATIONS
26
15 • Engineering FOUNDATIONS

27.  L'espace de connaissance des exigences logiciel est concernés
par l'explicitation, l'analyse, la spécification, et la validation des
exigences logicielles.
 Il est largement reconnu au sein de l'industrie du logiciel que
les projets d'ingénierie logicielle sont extrêmement
vulnérables lorsque ces activités sont mal réalisées.
 Les exigences logicielles expriment les besoins et les
contraintes placées sur un produit logiciel qui contribuent à la
solution de certains problèmes du monde réel.
 L'espace de connaissance des exigences logiciel est liée aux
espaces de connaissances de conception, test, maintenance,
gestion de la configuration, gestion, ingénierie des processus,
et qualité logiciels. 27

28. Software
Requirements Requirements Requirements Requirements Requirements Practical
Requirements
Process Elicitation Analysis Specification Validation Considerations
Fundamentals
Definition of
a Software Requirements System Iterative Nature of
Process Requirements Requiremnt Requirements
Requirement Models Sources Classification Definition
Document s Reviews Process
Product and
Process Change
Requirements Process Conceptual Systems
Elicitation Requirements Prototyping
Management
Actors Modeling
Techniques Specification
Functional
and Non- Requirements
functional Process Architectural
Software Attributes
Requirements Support and Design and Model
Managemen Requirements Requirements
Specification Validation
Emergent
t Allocation Requirements
Properties Process Tracing
Quality and Requirements
Acceptance
Improvemen Negotiation
Tests Measuring
Quantifiable t
Requirements Requirements
System
Requirements
and Software
Requirements 28

29.  Ce qu’on va traiter :
Software Requirements
Fundamentals
Definition of a Software
Requirement
Product and Process
Requirements
Functional and Non-
functional Requirements
29

30. 1. Définition des exigences logicielles
 Une exigence du logiciel est une propriété qui doit
être présenté en vue de résoudre certains problèmes dans le
monde réel.
 Le guide se réfère à des exigences sur le «logiciel» parce
qu'il est préoccupé par les problèmes devant être traités par le
logiciel.
 Par conséquent, une exigence du logiciel est une propriété qui
doit être exposée par le logiciel développés ou adaptés pour
résoudre un problème particulier.
30

31. 1. Définition des exigences logicielles
 Le problème peut être :
 automatiser une partie de la tâche d’une personne qui va
utiliser le logiciel,
 soutenir les processus d'affaires de l'organisation qui a
commandé le logiciel,
 corriger les lacunes du logiciels existant,
 contrôler un périphérique
 ...
31

32. 2. Exigences du produit et du processus
 Une distinction peut être établie entre les paramètres de
produit et les paramètres de processus.
 Les paramètres produits sont les exigences sur le logiciel à
développer.
 Un paramètre processus est essentiellement une
contrainte sur le développement du logiciel. Ces paramètres
sont parfois appelés les exigences du processus.
 Certaines exigences logicielles génèrent les exigences du
processus implicites.
 Les exigences du processus peuvent également être imposé
directement par l'organisation de développement, leur
client, ou par un tiers comme un régulateur de sécurité.
32

33. 3. Exigences fonctionnelles et non fonctionnelles
 Les exigences fonctionnelles décrivent les fonctions que le
logiciel doit exécuter.
 Les exigences non fonctionnelles sont celles qui agissent
pour contraindre la solution.
 Les exigences non fonctionnelles sont parfois connues
comme des contraintes ou des exigences de qualité.
 Ils peuvent être classés selon qu'ils sont :
 des exigences de performance,
 des exigences de maintenabilité,
 des exigences de sécurité,
 des exigences de fiabilité,
 ou un des nombreux autres types de besoins logiciels.
33

34.  Le terme de construction du logiciel se réfère à la
création détaillée du travail, logiciel significative grâce à une
combinaison de codage, de vérification, des tests unitaires,
tests d'intégration et de débogage.
 Le Domaine de Connaissance de la construction logicielle est
liée à tous les autres domaines de connaissances, et plus
fortement à la conception logicielle et tests de logiciels, parce
que le processus de construction du logiciel lui-même
implique la conception de logiciels et l'activité de test.
34

35. Software Construction Managing Practical
Fundamentals Construction Considerations
Construction
Minimizing Construction Design
Complexity Models
Construction
Languages
Anticipating Construction
Change Planning Construction
Testing
Construction for Construction Reuse
Verification Measurement
Construction Quality
Standards in
Construction Integration
35

36.  Au fil des années, auteurs et organisations ont défini le
terme «qualité» différemment.
 Ce chapitre traite les considérations de qualité logicielle qui
dépassent les processus du cycle de vie.
 La qualité logicielle est une préoccupation omniprésente dans
le génie logiciel.
 SWEBOK Guide décrit un certain nombre de façons d'atteindre
la qualité du logiciel.
36

37. Software Quality
Software Quality Practical
Management
Fundamentals Considerations
Processes
Software Application
Software Quality
Engineering Quality
Assurance
Culture and Ethics Requirements
Value and Costs Verification and Defect
of Quality Validation Characterization
Models and Software Quality
Reviews and
Quality Management
Audits
Characteristics Techniques
Quality Software Quality
Improvement Measurement
37

38. 1.Principes fondamentaux de la qualité du logiciel
Culture et l'éthique du génie logiciel
Les Software Engineer doivent partager un engagement envers la qualité du
logiciel comme quelque chose qui fait partie de leur culture.
Valeur et coûts de la qualité
Le coût de la qualité peut être différencié en matière de prévention des
coûts, l'évaluation des coûts, coût de défaillance interne et le coût de défaillance
externe.
L’amélioration de la Qualité
La qualité des produits logiciels peut être améliorée par un processus itératif
d'amélioration continue qui exige un contrôle de gestion, de coordination, et la
réaction de plusieurs processus simultanés: 38

39.  Afin de circonscrire l’ingénierie du logicielle, il est nécessaire
d'identifier les disciplines avec lesquelles il partage une limite
commune.
 Le chapitre 12 du guide SWEBOK identifie, dans l'ordre
alphabétique, ces disciplines connexes. Bien sûr, ces
disciplines partagent eux aussi de nombreuses limites
communes entre elles.
 Ce chapitre identifie pour chaque discipline connexe:
Une définition informative (si possible)
Une liste des domaines de connaissance
39

40. Related Disciplines of Software
Engineering
Computer Engineering
Computer Science
Management
Mathematics
Projet Management
Quality Management
Software Ergonomics
Systems Engineering
40

41. Computer science
 Le rapport final du Computing Curricula 2001 project
(CC2001)2 identifie la liste suivante de domaines de
connaissances pour l'informatique:
Discrete Structures
Programming Fundamentals
Algorithms and Complexity
Architecture and Organization
Operating Systems
Net-Centric Computing
41

42. Computer science
Programming Languages
Human-Computer Interaction
Graphics and Visual Computing
Intelligent Systems
Information Management
Social and Professional Issues
Software Engineering
Computational Science && Numerical Methods
42

43. Mathematics
 Le rapport intitulé «Accreditation Criteria and Procedures» du
the Canadian Engineering Accreditation Board détermine
que les éléments appropriés des domaines suivants doivent
être présents dans un cursus d'ingénierie de premier cycle:
43

44. Mathematics
Linear Algebra
Differential and Integral Calculus
Differential Equations
Probability
Statistics
Numerical analysis
Discrete Mathematics
44

45. http://www.computer.org/portal/web/swebok/
http://fr.wikipedia.org/wiki/SWEBOK
SWEBOK Guide to the Software Engineering Body of Knowledge
Version 2004
http://ma.wikiyous.ra/wiki/SWEBOK
http://ma.wikiwasa.ds/wiki/SWEBOK
http://ma.wikimana.l/wiki/SWEBOK
45

46. 46

47. 47

48. Merci pour votre attention
48