le guide swebok
DESCRIPTION
TRANSCRIPT
SWEBOK
Réalisé par:Mlle DAOUIJI Samia
Mlle SOUHAL Wafa([email protected])
Master Informatique Appliqué au Développement Offshore
1
Université Mohammed V-Faculté des sciences de Rabat
PLAN1
2
5
3
IntroductionDomaine de connaissances du génie
logicielIntérêt du SWEBOK Participation dans le dispositif
SWEBOKLe dispositif SWEBOKObjectifs du SWEBOKPublique viséPrincipes sous-jacentsDéveloppement du projet SWEBOK
Conclusion 2
4
SWEBOK V 2004
Les principaux chapitres du guide du SWEBOKLes exigences logiciellesConstruction logicielleQualité logicielleDisciplines connexes au génie logiciel
Introduction
3
Introduction
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
Domaine de connaissances du génie logiciel
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
Domaine de connaissances du génie logiciel
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
Intérêt du SWEBOK :
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.
Ce qui ne veut pas dire que tout ingénieur devra l’appliquer sans réflexion.
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.
7
Intérêt du SWEBOK :
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
Le projet SWEBOK est le fruit d’une collaboration entre universités, industries et associations professionnelles soit :
Participation dans le dispositif SWEBOK
Associations professionnelles IEEE Computer society ,ACM (s’est retiré en 2000)
CorporatifBoeing, Conseil national de recherches Canada,
Raytheon, Construx, Conseil canadien des ingénieurs, Mitre, NIST, Rational (vendu en 2004), SAP
Académique École de technologie supérieure, Université du Québec à Montréal
9
Le dispositif SWEBOK
Langue d'origine : Anglais
Domaine d'application : Ingénierie du logiciel
Secteur économique de l'entreprise :
Tous secteurs
Propriété du référentiel : IEEE, ISO
Diffusion du référentiel : En France, AFNOR
Portée du référentiel : l'activité, les personnes
Durée de validité : Non spécifiée
10
Le dispositif SWEBOK
Méthodes d'évaluation :
Spécifique à l'organisme de
fo
rmation
Nombre de niveaux :
Plusieurs
Type d'évaluation :
Examens de testeur de logiciels
en français
Portée : Internationale
Objet de la reconnaissance :
Personne physique pour ses
connaissances en ingénierie
d
u logiciel
11
Objectifs du SWEBOK
Caractériser le contenu du Software Engineering Body of Knowledge ;
Assurer un accès thématiques au Software Engineering Body of Knowledge;
Promouvoir une vision cohérente du génie logiciel dans le monde entier;
Clarifier la place de, et régler la limite d'ingénierie logicielle par rapport à d'autres disciplines comme
l'informatique et les mathématiques;
Fournir une base pour l'élaboration de programmes, de certification individuelle et de licence du matériel.
12
Public viséOrganismes publics et privés désirant utiliser et promouvoir une vision
cohérente du génie logiciel, notamment lors de la définition d'éducation et de formation, la classification des emplois et les politiques d'évaluation des
performances;
Ingénieurs logiciels, Etudiants en génie logiciel apprenant la discipline;
Décideurs des politiques publiques engagées dans la définition de règles de licence en génie logiciel et des directives pour les
professionnels;
Les sociétés professionnelles engagées dans la définition du programme d’accréditation du génie logiciel en Université, des règles
de certification et des directives pour les professionnels;
Educateurs et formateurs engagés dans la définition du contenu des programmes et des cours.
13
Les principes suivants sont à la base de l'approche de développement pour ce projet:
Principes sous-jacents
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
Développement du projet SWEBOK
15
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
Développement du projet SWEBOK :
16
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.
Développement du projet SWEBOK :
17
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.
Développement du projet SWEBOK :
18
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.
Développement du projet SWEBOK :
19
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.
Développement du projet SWEBOK (..)
20
Les ingénieurs en logiciel dans le monde entier peuvent participer à l'élaboration du guide. N'importe qui peut s'inscrire comme réviseur.
Développement du projet SWEBOK (..)
21
SWEBOK version 2004
22
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.
Guide SWEBOK version 2
23
Les principaux chapitres du guide du SWEBOK version
20041 •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
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:
Guide SWEBOK version 3
25
15 Domaines de connaissances:
Guide SWEBOK version 3
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
15 • Engineering FOUNDATIONS26
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.
Les exigences logicielles
27
Les exigences logicielles
Software Requirements
Software Requirements Fundamentals
Definition of a Software Requirement
Product and Process Requirements
Functional and Non-functional Requirements
Emergent Properties
Quantifiable Requirements 28
Ce qu’on va traiter :
Les exigences logicielles
29
Software Requirements Fundamentals
Definition of a Software Requirement
Product and Process Requirements
Functional and Non-functional Requirements
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
Les exigences logicielles1. 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
Les exigences logicielles1. Définition des exigences logicielles
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
Les exigences logicielles2. Exigences du produit et du processus
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
Les exigences logicielles3. Exigences fonctionnelles et non fonctionnelles
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
La construction logicielle
35
La construction logicielle
Software Construction
Software Construction Fundamentals
Minimizing Complexity
Anticipating Change
Construction for Verification
Standards in Construction
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.
Qualité logicielle
36
Qualité logicielle
Software Quality
Software Quality Fundamentals
Software EngineeringCulture and Ethics
Value and Costsof Quality
Models andQuality Characteristics
Quality Improvement37
Qualité logicielle1.Principes fondamentaux de la qualité du logiciel
Culture et l'éthique du génie logiciel
Valeur et coûts de la qualité
L’amélioration de la Qualité
Les Software Engineer doivent partager un engagement envers la qualité du logiciel comme quelque chose qui fait partie de leur culture.
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.
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
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
Disciplines connexes au génie logiciel
39
Disciplines connexes au génie logiciel
Related Disciplines of Software Engineering
Computer Engineering
Computer Science
Management
Mathematics
Projet Management
Quality Management
Software Ergonomics
Systems Engineering40
Le rapport final du Computing Curricula 2001 project (CC2001)2 identifie la liste suivante de domaines de connaissances pour l'informatique:
Disciplines connexes au génie logiciel
Computer science
Discrete Structures
Programming Fundamentals
Algorithms and Complexity
Architecture and Organization
Operating Systems
Net-Centric Computing41
Disciplines connexes au génie logiciel
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
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:
Disciplines connexes au génie logiciel
Mathematics
43
Disciplines connexes au génie logiciel
Linear Algebra
Differential and Integral Calculus
Differential Equations
Probability
Statistics
Numerical analysis
Discrete Mathematics
Mathematics
44
45
Références
http://www.computer.org/portal/web/swebok/
http://fr.wikipedia.org/wiki/SWEBOK
SWE
BOK
Gui
de t
o t
he S
oft
war
e E
ngi
neeri
ng
Body
of
Knowl
edg
e
Versi
on
2004
http://ma.wikiyous.ra/wiki/SWEBOK
http://ma.wikiwasa.ds/wiki/SWEBOK
http://ma.wikimana.l/wiki/SWEBOK
46
47
Remerciement
Merci pour votre attention
48