le guide swebok

SWEBOK

Réalisé par:Mlle DAOUIJI Samia

([email protected])

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.


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.


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.


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:


25

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

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


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 :


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


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:


Computer science

Discrete Structures

Programming Fundamentals

Algorithms and Complexity

Architecture and Organization

Operating Systems

Net-Centric Computing41


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:


Mathematics

43


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
















































































































































































47

Remerciement

Merci pour votre attention

48

le guide swebok

Documents

Transcript of le guide swebok