LE GUIDE DU CORPUS DES CONNAISSANCES EN GNIE LOGICIEL1

Pierre Bourque, Robert Dupuis, Alain Abran Universit du Qubec Montral, James W.
Moore The Mitre Corporation & Leonard Tripp The Boeing Company
Rsum : Les auteurs, membres de lquipe
directrice du projet SWEBOK, dcrivent les
trois phases de leur projet, qui vise
caractriser un corpus de connaissances, ce
qui est une tape essentielle pour amener le
gnie logiciel au stade de vritable
profession.
L'IEEE Computer Society et l'Association for
Computing Machinery collaborent un projet
dont l'objectif est d'laborer un guide
prsentant le corpus des connaissances dans
le domaine du gnie logiciel, le projet
SWEBOK (en anglais, Software Engineering
Body of Knowledge). La description d'un
corpus de connaissances est une tape
essentielle vers la reconnaissance d'une
profession ; un corpus de ce type permet
dtablir un consensus sur le contenu de la
discipline concerne. En l'absence d'un tel
consensus, on ne peut ni valider un examen
qui mne lobtention dune licence, ni
instituer un cursus qui prpare les candidats
pour cet examen, ni formuler des critres
daccrditation de ce cursus.
Le projet SWEBOK (http://www.swebok.org)
en est actuellement la fin de la deuxime de
ses trois phases. Dans cet article, nous en
prsentons une vue densemble et en
rsumons les rsultats obtenus jusqu
maintenant.
OBJECTIFS ET PUBLIC VIS
Les objectifs du projet SWEBOK sont les
suivants :
1. Dcrire le contenu de la discipline du gnie
logiciel ;
2. Donner un accs, selon les sujets, au
corpus des connaissances du gnie logiciel ;
3. Promouvoir lchelle mondiale une vue
cohrente sur le gnie logiciel ;
4. Dfinir la place et tracer les frontires du
gnie logiciel relativement d'autres
disciplines comme l'informatique, la gestion
de projets, le gnie informatique et les
mathmatiques ;
5. Poser les fondations du cursus et de l'octroi
de certificats de comptence professionnelle.
Le projet SWEBOK ne cherche pas tablir
un corpus de connaissances proprement dit,

mais plutt mettre sur pied un guide

prsentant ce corpus. Les connaissances
existent dj ; notre but est de recueillir le
consensus sur le noyau de connaissances
caractrisant la discipline du gnie logiciel.
Pour atteindre ces objectifs, nous avons vis
diffrents publics cibles. Dabord, des
organismes publics et privs, qui ont besoin
d'une vue cohrente du gnie logiciel afin
den dfinir l'enseignement et la formation,
de catgoriser les emplois et d'tablir des
politiques d'valuation de la performance.
Ensuite, les praticiens en gnie logiciel et les
services
publics
responsables
de
ltablissement des rgles relatives l'octroi
de licences et aux pratiques professionnelles.
Enfin, les associations professionnelles et les
enseignants qui dfinissent les rgles et les
politiques daccrditation pour les cursus
universitaires ainsi que les tudiants qui ont
choisi la profession du gnie logiciel.
LE GUIDE
Le projet comporte trois phases, appeles
Strawman ( homme de paille ), Stoneman
( homme de pierre ) et Ironman ( homme
de fer ). Le guide correspondant la
premire phase, Strawman, achev neuf mois
aprs le dbut du projet, a servi de modle
pour organiser le guide SWEBOK [1]. La
version Stoneman sera complte au
printemps 2000. Ironman, la troisime phase,
suivra et durera deux ou trois ans. Fonde sur
des principes tablis dans la deuxime phase,
la version Ironman sera enrichie par des
analyses plus approfondies, un processus de
rvision plus large ainsi que par
lexprimentation.
Le guide SWEBOK structurera le corpus de
connaissances selon plusieurs domaines de
connaissances. Actuellement, la version
Stoneman identifie dix domaines. Le tableau
1 prsente les spcialistes responsables de la
prparation du document descriptif de
chacun de ces domaines. Nous envisageons
en outre sept disciplines connexes (voir le
tableau 2).
Tableau 1
Tableau 2. Les disciplines connexes

1999 IEEE. Cet article est paru originalement en anglais dans IEEE Software, Vol. 16, No 6, pp.
35-44, November/December 1999. Il est reproduit ici avec la permission de IEEE.
1

Sciences cognitives et facteurs humains

Ingnierie informatique
Informatique
Gestion et sciences de la gestion
Mathmatiques
Gestion de projets
Ingnierie de systmes
Dans le guide, la distinction entre domaines
de connaissances et disciplines connexes est
importante. Le projet identifiera les domaines
de connaissances (ainsi que leurs sujets) qui
sont considrs comme fondamentaux pour
les ingnieurs en logiciel. Ces ingnieurs
devraient connatre des lments relevant des
disciplines connexes, mais le projet
SWEBOK ne les spcifiera pas. Dautres sen
chargent, comme le comit de coordination
conjoint IEEE Computer Society-ACM pour
le gnie logiciel, ou le groupe de travail sur
l'enseignement du gnie logiciel [2].
Comme le montre la figure 1, et comme il est
expliqu dans la partie suivante, chaque
descriptif de domaine de connaissances
(dune dizaine de pages chacun) contient
plusieurs composants importants.
L'organisation hirarchique
Le guide SWEBOK utilisera une organisation
hirarchique pour dcomposer chaque
domaine de connaissances. On pourra alors
facilement reprer un ensemble de sujets.
Une organisation en deux ou trois niveaux
permettra aux lecteurs de trouver aisment
les sujets qui les intressent. Le traitement
des sujets sera compatible avec celui des
principales coles de pense et avec celui en
usage dans l'industrie, dans la littrature
technique et dans les normes relatives au
gnie logiciel. Le traitement ne prsupposera
ni domaines d'application, ni utilisations
commerciales,
ni
philosophies
de
management, ni mthodes de dveloppement
en particulier. L'tendue de la description de
chaque sujet se limitera celle qui est
ncessaire au lecteur pour trouver les
documents de rfrence. Aprs tout, le corpus
de connaissances se trouve dans les
documents de rfrence et non dans le guide
lui-mme.
Ds le dbut du projet, on a soulev la
question du dtail du traitement que le guide
devait prsenter. Aprs de longues
discussions, nous avons adopt le concept de
connaissances gnralement admises [3],
connaissances que nous devions distinguer
des connaissances avances et de celles
propres la recherche (en fonction de leur
maturit) ainsi que de celles considres
comme spcialises ( partir de la gnralit

de leur application). Les connaissances

gnralement admises s'appliquent la
plupart des projets la plupart du temps et un
large consensus permet de valider leur intrt
et leur efficacit.
Cependant, ceci ne signifie pas que nous
devrions appliquer les connaissances
gnralement admises de faon uniforme
tous les travaux relevant du gnie logiciel
ce sont les besoins propres de chaque projet
qui les dterminent, mais les ingnieurs en
logiciel comptents devraient matriser ces
connaissances et tre en mesure de les
appliquer. Dune faon plus prcise, ces
connaissances sont des lments qui
devraient tre tudis en vue dun examen
conduisant lobtention dune licence en
gnie logiciel. Les candidats pourront faire
cet examen aprs quatre annes de pratique.
Spcifique au contexte de l'enseignement aux
tats-Unis, ce critre ne s'applique toutefois
pas ncessairement dans d'autres pays. Mais
nous croyons quil est tout de mme utile et
que les deux dfinitions des connaissances
gnralement
admises
devraient
tre
considres
comme
complmentaires.
Mentionnons enfin que lorganisation
propose est prospective ; ainsi, nous
considrons non seulement ce qui est
gnralement admis aujourd'hui, mais aussi
ce qui le sera probablement dans trois ou cinq
ans.
Documents de rfrence
matriciel de croisement

et

tableau

Le guide identifiera des documents de

rfrence pour chacun des domaines de
connaissances. Ces documents sont soit des
chapitres d'ouvrages, soit des articles ayant
t valus par des pairs ou toute autre
source d'information faisant autorit. Les
documents de rfrence doivent tre en
anglais et facilement accessibles. Nous avons
donn la prfrence aux documents dont les
droits de reproduction sont dtenus par
l'IEEE Computer Society ou l'ACM, car nous
dsirons les rendre accessibles gratuitement
par Internet.
Le guide comportera aussi une matrice qui
reliera les documents de rfrence la liste
des sujets. videmment, une rfrence
donne pourra s'appliquer plus d'un sujet.
Classification
Pour permettre daborder les sujets de
diffrentes faons et de les relier aux autres
disciplines de lingnierie, le guide classera
les sujets selon la taxinomie des
connaissances de la conception en ingnierie

que Walter Vincenti a propose dans son

histoire de l'ingnierie aronautique publie
en 1990 [4]. Ses six catgories de
connaissances relatives la conception en
ingnierie sont respectivement les concepts
fondamentaux de la conception, les critres et
les spcifications, les outils thoriques, les
donnes quantitatives, les aspects pratiques
et les approches de la rsolution de
problmes.
Niveaux
Pour aider notamment ceux qui tablissent les
programmes dtudes, le guide attribuera
chaque sujet un niveau correspondant aux
catgories pdagogiques proposes par
Benjamin Bloom. Selon lui, les objectifs
pdagogiques peuvent tre classs en six
catgories qui reprsentent chacune un
niveau de matrise croissant : connaissances,
comprhension,
application,
analyse,
synthse et valuation. On trouvera la
taxinomie de Bloom sur le site Web suivant :
http://www.valdosta.peachnet.edu/~whuitt/ps
y702/cogsys/bloom.html
Les domaines de
disciplines connexes

connaissances

des

Chaque description de domaine de

connaissances du guide SWEBOK identifiera
aussi les domaines de connaissances des
disciplines connexes pertinents. Sans
description ni rfrences, lidentification de
ces domaines de connaissances devrait
malgr tout tre utile aux concepteurs de
programmes dtudes.
LES DOMAINES DE CONNAISSANCES
La slection, les titres et les descriptions des
domaines de connaissances peuvent tre
revus et corrigs selon les critiques qui
auront t formules. De plus, certains
thmes, comme les mesures, les outils et les
normes,
sont
transversaux
et
sont
actuellement traits de faon spare dans
chaque domaine. Ces dcisions seront
rexamines dans les versions ultrieures du
guide. Dans cet article, nous prsentons, par
ordre alphabtique (selon le titre anglais), les
domaines de connaissances tels qu'ils sont
bauchs. La figure 2 rsume ces dix
domaines de connaissances et les sujets
importants qui leur sont associs.

manire excuter une fonction ou un

ensemble de fonctions. La configuration d'un
systme est la fonction ou les caractristiques
physiques du matriel, des microprogrammes,
du logiciel, ou une combinaison de ces
lments, noncs dans la documentation
technique et mis en uvre dans un produit.
La gestion de configuration, quant elle, est
la discipline correspondant l'identification,
certains moments, de la configuration afin
den
contrler
systmatiquement
les
modifications, d'en maintenir l'intgrit et de
les retracer tout au long du cycle de vie du
systme.
Les concepts de la gestion de configuration
s'appliquent tous les lments requrant un
contrle, bien qu'il y ait des diffrences entre
la mise en uvre de la gestion de
configuration du matriel et celle du logiciel.
Les activits principales de la gestion de
configuration du logiciel servent de cadre
pour lorganisation et la description des
sujets de ce domaine de connaissances. Ce
sont : la conduite du processus de la gestion
de configuration, l'identification, le contrle,
le compte rendu de l'tat de la configuration,
sa vrification ainsi que la gestion et la
livraison des diffrentes versions du logiciel
(voir figure 2a).
Construction
Construction)

du

logiciel

(Software

La construction du logiciel constitue un acte

fondamental du gnie logiciel; les
programmeurs doivent construire des
logiciels qui fonctionnent et qui ont un sens,
au moyen de la programmation, de
lautovalidation et des tests unitaires. Loin
d'tre une simple traduction mcanique d'une
bonne conception en un logiciel qui
fonctionne, la construction du logiciel
concerne troitement certaines des questions
les plus dlicates du gnie logiciel.

(Software

La division de ce domaine de connaissances

en sujets est faite selon deux perspectives
complmentaires. La premire prsente trois
styles principaux pour les interfaces de la
construction du logiciel : linguistique,
mathmatique et visuel (voir la figure 2b).
Puis, pour chaque style, les sujets sont classs
selon quatre principes d'organisation de base
qui ont une forte influence sur la faon dont
la construction du logiciel est effectue : la
rduction de la complexit, lanticipation de
la diversit, la structuration de la validation
et lutilisation de normes externes.

Un systme peut tre dfini comme une

collection de composants organiss de

Ainsi, les sujets qui figurent sous la rubrique

anticipation de la diversit , en ce qui
concerne les mthodes linguistiques de la

Gestion
de
configuration
Configuration Management)

construction du logiciel, sont : le masquage

de
l'information,
la
documentation
incorpore, les ensembles de mthodes
complets et suffisants, l'hritage de classes de
l'orient-objet, la cration de langages
colle
pour
lier
les
composants
patrimoniaux, le logiciel gr par tables, les
fichiers de configuration ainsi que le logiciel
et le matriel autodescriptifs.
Conception du logiciel (Software Design)
La conception transforme les exigences,
habituellement nonces en des termes
appropris au domaine du problme
concern, en une description qui explique
comment rsoudre le problme. Elle explique
aussi comment le systme est dcompos et
organis en composants ainsi que les
interfaces entre ces composants. De plus, la
conception
affine
suffisamment
la
description
pour
entreprendre
leur
construction.
Les concepts et les principes de base
constituent le premier sous-domaine de ce
domaine de connaissances quest la
conception du logiciel (voir la figure 2c). La
qualit de la conception et les mesures en
constituent le deuxime sous-domaine, qui
comprend les attributs de la qualit,
lassurance-qualit et les mesures. Dans le
troisime
sous-domaine,
l'architecture
logicielle, on trouve les structures et les
points
de
vue,
les
descriptions
architecturales, les patrons et les cadres
orients-objet. Ce sous-domaine comprend
aussi une partie sur les styles architecturaux
une notion importante en ce qui concerne
l'architecture logicielle , dans laquelle on
prsente quelques-uns des principaux styles
identifis par diffrents auteurs.

Les mthodes de dveloppement imposent

une structure l'activit de dveloppement et
de maintenance du logiciel dans le but de la
rendre systmatique et, en fin de compte, plus
. Ces mthodes fournissent habituellement
une notation et un lexique, des procdures
qui permettent deffectuer des tches
identifiables ainsi que des lignes directrices
permettant de vrifier la fois le processus et
le produit. La porte des mthodes de
dveloppement varie largement, allant d'une
phase du cycle de vie isole au cycle
complet. Le guide SWEBOK divisera ce sousdomaine en trois sujets principaux lis entre
eux : les mthodes heuristiques se rapportant
aux approches informelles, les mthodes
formelles
concernant
les
approches
mathmatiques et, enfin, les mthodes de
prototypage concernant les approches qui
reposent sur diverses formes de prototypage.
Les outils logiciels sont informatiss et
destins tayer le processus de l'ingnierie
du logiciel. Ces outils sont souvent conus
pour supporter certaines mthodes et rduire
la charge administrative qui accompagne
habituellement leur mise en uvre manuelle.
Comme les mthodes, ils ont pour but de
rendre le dveloppement plus systmatique,
et leur porte va du support des tches
individuelles la prise en compte du cycle de
vie complet. Le plus haut niveau de la
dcomposition du domaine des
outils
logiciels permet de faire la distinction entre
les outils conus pour le dveloppement et la
maintenance, ceux pour les activits de
support et, enfin, pour le management. Les
autres catgories recouvrent les ensembles
d'outils
intgrs
(nomms
aussi
environnements de gnie logiciel ) et les
techniques d'valuation d'outils.

Le sous-domaine des notations de conception

porte sur les notations documentant une
conception spcifique de haut niveau ou une
conception dtaille de systmes. Les
stratgies et les mthodes de conception, le
dernier sous-domaine, touchent quatre sujets
principaux, savoir les stratgies gnrales,
la conception guide par la structure des
donnes, la conception guide par les
fonctions et la conception oriente-objet.

L'mergence de composants logiciels comme

approche viable du dveloppement du
logiciel traduit une maturation de la
discipline qui vainc le syndrome du noninvent soi-mme. Le sous-domaine de
l'intgration des composants est divis en
sujets concernant les composants individuels,
les modles de rfrence qui dcrivent
comment les composants peuvent tre
combins et aborde le sujet plus gnral de la
rutilisation.

Infrastructure du gnie logiciel (Software

Engineering Infrastructure)

Management du gnie logiciel (Software

Engineering Management)

Ce domaine de connaissances regroupe trois

sous-domaines transversaux. Ce sont les
mthodes de dveloppement, les outils
logiciels et lintgration de composants (voir
la figure 2d).

Le
domaine
de
connaissances
du
management de lingnierie du logiciel
regroupe le sous-domaine du processus du
management et celui des mesures (voir la
figure 2e). Ces deux sous-domaines sont
souvent considrs comme distincts (et sont

en gnral enseigns comme tels). Mais ceuxci, tout en tant uniques, ont des relations
troites, ce qui a motiv leur traitement
combin.
Car,
essentiellement,
un
management sans mesures, qualitatives ou
quantitatives, indique un manque de rigueur,
et des mesures sans management indiquent,
elles, une absence dobjectifs ou de contexte.
Le sous-domaine
du
processus
de
management considre la notion de
management grande chelle dans le
thme de la coordination, qui se rapporte
des questions comme le choix de projets, le
dveloppement et limplantation de normes
ainsi que la constitution dquipes et le
dveloppement en quipe. Dans ce sousdomaine sont prsents aussi les sujets
restants en fonction des tapes dans le cycle
de vie du dveloppement du projet :
dmarrage et dfinition de la porte du projet,
planification (y compris le calendrier et
lvaluation des cots et des risques),
excution et, finalement, revue, valuation et
clture du projet.
Le sous-domaine des mesures regroupe
quatre sujets : les buts du programme de
mesure, le choix des mesures, la cueillette des
donnes et le dveloppement des modles.
Les trois premiers concernent principalement
la thorie et lutilit des mesures et traitent,
entre autres, du choix de celles-ci. Il est aussi
question de la prise de mesures, qui comporte
la fois des questions techniques (comme
lextraction automatique) et des questions
humaines (la conception des questionnaires
et la rponse aux mesures effectues). Le
quatrime sujet (le dveloppement de
modles) traite de lutilisation des donnes et
des
connaissances
ncessaires
pour
construire des modles.
Processus du gnie
Engineering Process)

logiciel

(Software

Ce domaine de connaissances recouvre la

dfinition, la mise en uvre, la mesure, le
management, la modification et l'amlioration
des processus logiciels. Dans le premier sousdomaine, les concepts de base et les
dfinitions, sont tablis les thmes et la
terminologie (voir la figure 2f).
Le but et les mthodes pour dfinir des
processus logiciels, comme les diffrentes
dfinitions des processus et leur support
automatis sont dcrits dans le sous-domaine
de la dfinition des processus. Diffrents
thmes y figurent : les types de dfinitions de
processus, les modles de cycle de vie, les
modles de processus de cycle de vie, les
notations pour les dfinitions des processus,

les mthodes de dfinition de processus et

l'automatisation.
Le sous-domaine de l'valuation des
processus dcrit les approches des analyses
quantitative et qualitative. La mesure tant
importante dans l'valuation des processus, la
mthodologie pour la mesure du processus
est le premier sujet abord dans ce sousdomaine. Un paradigme analytique et un
paradigme dvaluation des performances
divisent les types d'valuation. Le paradigme
analytique repose sur une preuve quantitative
pour dterminer o une amlioration est
ncessaire ou si une amlioration a port ses
fruits. Sous ce paradigme, on trouve
l'valuation qualitative, l'analyse des causes
premires, la simulation des processus, la
classification orthogonale des dfauts, les
tudes exprimentales et le processus logiciel
individuel. Le paradigme dvaluation des
performances repose, quant lui, sur
l'identification d'une organisation qui fait
preuve d'excellence dans un domaine afin de
documenter ses pratiques et outils. Les
modles et mthodes d'valuation de
processus sont les deux sujets principaux de
ce paradigme.
Le sous-domaine de la mise en uvre et de la
modification de processus dcrit les
paradigmes, l'infrastructure et les facteurs
ncessaires cette mise en uvre et la
russite de la modification de processus. On
trouve, dans ce sous-domaine, les paradigmes
pour la mise en uvre et la modification des
processus,
l'infrastructure,
les
lignes
directrices ainsi que l'valuation de la mise
en uvre et de la modification de processus.
volution et maintenance du logiciel
(Software Evolution and Maintenance)
La maintenance du logiciel est dfinie par la
norme IEEE 1219-1998 (IEEE Standard for
Software Maintenance) comme tant la
modification apporte un produit logiciel
aprs sa livraison pour en corriger des
dfauts ou amliorer ses performances ou
d'autres attributs, ou encore adapter le
produit un environnement modifi.
Cependant, les systmes logiciels sont
rarement figs et voluent constamment dans
le temps. Par consquent, seront abords dans
ce domaine de connaissances les sujets
touchant l'volution du logiciel.
Le sous-domaine des concepts de la
maintenance dfinit la maintenance et dcrit
ses concepts de base ainsi que la place
quoccupe le concept d'volution de systme
dans le gnie logiciel (voir la figure 2g). Il
explique aussi les tches que les quipes de

maintenance ont assumer. Le sous-domaine

des rles et des activits de maintenance
porte sur les types formels de maintenance et
les activits courantes. Comme pour le
dveloppement du logiciel, le processus est
crucial pour la russite et la comprhension
de l'volution du logiciel et de sa
maintenance. Le sous-domaine suivant porte
sur les processus de maintenance standard.
Lorganisation de la maintenance peut en
effet
tre
diffrent
de
celle
du
dveloppement ; le sous-domaine relatif aux
aspects organisationnels traite prcisment
de ces diffrences.
Comme on peut le voir dans le sous-domaine
relatif aux problmes de la maintenance,
l'volution et la maintenance du logiciel
prsentent pour le gnie logiciel diffrents
problmes techniques et managriaux. Le
cot est toujours capital lorsqu'il est question
d'volution et de maintenance du logiciel. Le
sous-domaine relatif aux cots de la
maintenance et l'estimation de ces cots
concerne ceux du cycle de vie du logiciel
autant que ceux des tches individuelles qui
se rapportent ces deux fonctions. Le sousdomaine concernant la mesure relative la
maintenance traite des mesures et de la
qualit. Le dernier sous-domaine, celui des
outils et des techniques de la maintenance,
rassemble de nombreux sous-thmes que la
description du domaine de connaissances
naborderait pas autrement.

Analyse de la qualit du logiciel (Software

Quality Analysis
L'laboration de produits de qualit est la cl
de la satisfaction du client. Des logiciels sans
les caractristiques et le niveau de qualit
requis indiquent un chec ou une
insuffisance du gnie logiciel. Cependant,
mme dans le cas des meilleurs processus
logiciels, la spcification des exigences peut
ne pas rpondre aux besoins du client, le
code, ne pas correspondre aux exigences, et
des erreurs peuvent rester subtilement
caches jusqu' ce qu'elles causent des
problmes mineurs ou majeurs, voire des
pannes catastrophiques. Ce domaine de
connaissances traite de ce qui est relatif
l'assurance-qualit du logiciel et aux activits
de vrification et de validation qui y sont
lies.
Le but du gnie logiciel est de faire un
produit de qualit, mais la qualit en soi peut
avoir plusieurs significations. Malgr des
terminologies diffrentes, il y a, pour tout un
ventail de produits, un certain consensus sur
les dfinitions de la qualit et la scurit de
fonctionnement du logiciel. Ces dfinitions
offrent les connaissances de base partir
desquelles des produits de qualit sont
planifis, construits, analyss, mesurs et
amliors. Le sous-domaine de la dfinition
des produits de qualit examine ces
dfinitions (voir la figure 2h).
L'assurance-qualit est un processus conu
pour assurer la qualit du produit; il sagit
dun cadre planifi et systmatique o sont
dfinies toutes les actions ncessaires pour
sassurer de la conformit du produit ses
exigences techniques. La vrification et la
validation du logiciel mnent une
valuation objective des produits et des
processus logiciels tout le long du cycle de
vie du logiciel ; en d'autres termes, le
processus de vrification et de validation
permet au management de contrler la qualit
du produit.
Ces deux processus constituent les
fondements du sous-domaine de lanalyse de
la qualit du logiciel, sous-domaine qui se
subdivise en quatre : la dfinition de
lanalyse de la qualit, les plans des
processus, les activits et les techniques de
lanalyse de la qualit et, enfin, les mesures
dans lanalyse de la qualit du logiciel.
Analyse des exigences du logiciel (Software
Requirements Analysis)
Le domaine de connaissances de lanalyse
des exigences du logiciel est divis en cinq

sous-domaines
qui
correspondent
approximativement aux tches du processus,
qui sont souvent excutes en parallle et
itrativement plutt que squentiellement
(voir la figure 2i).
Le sous-domaine du processus dingnierie
des exigences introduit le processus de
lingnierie des exigences, oriente les quatre
sous-domaines suivants et montre comment
lingnierie des exigences sinsre dans le
cycle de vie global du logiciel. Ce chapitre
traite aussi des questions contractuelles et
organisationnelles relatives aux projets.
Le sous-domaine de la clarification des
exigences recouvre ce quon appelle aussi
saisie, dcouverte ou acquisition des
exigences. Dans ce sous-domaine, il est
question de lorigine des exigences et de la
faon dont elles peuvent tre colliges par les
ingnieurs spcialistes du logiciel. Il sagit de
la premire tape dans ltablissement de la
comprhension du problme que le logiciel
doit
rsoudre.
Cest
une
activit
fondamentalement humaine dont le but est
didentifier les dpositaires des enjeux et
dtablir les relations entre lquipe de
dveloppement et le client.
Le sous-domaine de lanalyse des exigences
concerne le processus consistant vrifier les
exigences pour y dtecter les conflits
possibles et les rsoudre, dcouvrir les
limites du systme et la faon dont celui-ci
doit interagir avec son environnement et
passer des exigences du client celles du
logiciel.
Le sous-domaine de la validation des
exigences vrifie que celles-ci ne comportent
ni omissions, ni conflits, ni ambiguts et
sassure quelles suivent les normes de
qualit prescrites. Les exigences devraient
tre obligatoires, suffisantes et tre dcrites
de faon minimiser les fausses
interprtations.
Le sous-domaine du management des
exigences recouvre le cycle de vie du logiciel
dans son entier. Il sagit fondamentalement
den grer les modifications et de maintenir
les exigences de faon reflter le logiciel
qui a t ou sera construit.
Test du logiciel (Software Testing)
Le test du logiciel consiste vrifier
dynamiquement, par le biais d'un ensemble fini
de jeux d'essai, le comportement rel d'un
programme par rapport au comportement
spcifi et attendu. Les jeux d'essai sont
slectionns, de manire adquate, partir du

domaine habituellement infini d'excutions

possibles du programme. Ce procd
dvaluation ainsi que dautres concepts de
base et dfinitions constituent le premier
sous-domaine (voir la figure 2j).

les secteurs de la communaut. Au moment

o la version Stoneman du guide sera
termine, des centaines de collaborateurs et
de relecteurs auront particip au projet dune
faon ou dune autre.

Ce domaine de connaissances divise le sousdomaine des niveaux de test en deux parties

orthogonales, la premire tant organise
selon les phases traditionnelles de test des
grands systmes logiciels ; la deuxime est
consacre aux tests pour des conditions ou
des proprits particulires.

Les collaborateurs du projet

Le sous-domaine suivant dcrit les

connaissances
relatives

plusieurs
techniques de test gnralement admises. Ces
techniques sont classes partir de leurs
fondements : elles sont bases sur les
spcifications, sur le code, sur les dfauts, sur
lutilisation ou sont spcialises. Ce domaine
de connaissances traite des mesures lies aux
tests dans leur propre sous-domaine. Le
suivant aborde les questions relatives
lorganisation et au contrle du processus de
test, y compris les problmes de management
et les activits de test. Le sous-domaine du
test automatique porte sur les outils existants
et les concepts lis lautomatisation du
processus de test.
LE PROJET
Depuis 1993, lIEEE Computer Society et
lACM collaborent la promotion de la
professionnalisation du gnie logiciel par
leur participation au comit de coordination
sur le gnie logiciel Software Engineering
Coordinating Committee ou SWECC (site
Web : http://computer.org/tab/swecc).
La porte du projet SWEBOK, la diversit des
communauts qui y sont engages et la
ncessit dune participation importante
requirent un management temps plein
plutt que reposant sur le volontariat. Cest
pourquoi le SWECC a donn le mandat de la
gestion du projet au Laboratoire de recherche
en gestion des logiciels (LRGL) de
lUniversit du Qubec Montral. Le LRGL
est supervis par le SWECC.

linstar de tout projet logiciel, le projet

SWEBOK prsente plusieurs dpositaires
d'enjeux certains d'entre eux tant
officiellement reprsents. Un comit
consultatif de lindustrie (Industrial Advisory
Board ou IAB), compos de reprsentants de
lindustrie (Boeing, le National Institute of
Standards and Technology, le Conseil
national de recherches du Canada, Raytheon
et SAP Labs Canada) et d'associations
professionnelles (IEEE Computer Society et
ACM), apporte au projet son aide financire.
Grce la gnrosit de lIAB, les produits
du projet sont publics et gratuits. Ils peuvent
tre consults sur le site Web :
http://www.swebok.org. la participation de
lIAB sajoutent celles d'organismes de
normalisation (IEEE Software Engineering
Standards Committee et ISO/IECJTC1/SC7) et
de projets connexes (Computing Curricula
2001 Initiative). LIAB vrifie et approuve
les plans du projet, veille la bonne marche
des processus d'tablissement du consensus
et de relecture fait la promotion du projet et
lui donne de la crdibilit. De faon gnrale,
il garantit ladquation des travaux aux
besoins du monde rel.
Toutefois, nous sommes conscients quun
corpus de connaissances implicite existe dj
dans les ouvrages denseignement sur le
gnie logiciel. Aussi, pour sassurer que nous
caractrisons correctement la discipline,
Steve McConnell, Roger Pressman et Ian
Sommerville, les auteurs de trois ouvrages
succs sur le gnie logiciel, ont accept de
faire
partie
dun
comit
dexperts
reprsentant la voix de lexprience. De plus,
le processus de relecture (dcrit plus loin)
permet aux communauts concernes de
sexprimer sur le projet. Rappelons ici que
nous visons une participation internationale.
La littrature normative

Lquipe du projet a nonc deux principes

importants : transparence et consensus. Par
souci de transparence, en effet, le processus
de dveloppement est lui-mme document,
publi et diffus pour faire en sorte que les
dcisions importantes et lavancement des
travaux soient connus par toutes les parties
concernes. En outre, nous croyons quun
consensus est la seule mthode pratique pour
lgitimer notre guide ; ainsi, il doit y avoir
une forte participation et un accord de tous

Le rapport du projet la littrature normative

diffre des travaux antrieurs. La majeure
partie de la littrature relative au gnie
logiciel fournit des informations utiles aux
ingnieurs spcialistes du logiciel, mais une
faible proportion en est normative. Un
document normatif prescrit ce quun
ingnieur doit faire plutt que la diversit des
choses que cet ingnieur peut ou pourrait
faire. La littrature normative est valide par

le consensus tabli entre les praticiens et est

concentre sur les normes et documents
connexes.
Ds le dbut, le projet SWEBOK a t conu
pour quil soit en relation troite avec la
littrature normative du gnie logiciel. Les
deux organismes principaux de normalisation
pour le gnie logiciel y sont ainsi reprsents.
En fait, une premire bauche des domaines
de connaissances reposait directement sur les
17 processus dcrits dans la norme ISO/IEC
12207 (Technologie de linformation Processus du cycle de vie des logiciels). Nous
esprons que, ultimement, les normes
relatives la pratique du gnie logiciel et
leurs principes se retrouvent aisment dans le
guide SWEBOK.
Relectures
Nous avons organis l'laboration de la
version Stoneman en trois cycles de relecture.
Le premier cycle sest concentr sur la
pertinence de la division par sujets propose
pour chaque domaine de connaissances.
Trente-quatre experts ont particip cette
relecture en avril 1999. Les commentaires des
relecteurs ainsi que leur identit sont
disponibles sur le site Web du projet.
Le deuxime cycle a t organis autour des
consignes que nous avions donnes
lorigine aux spcialistes des domaines de
connaissances. Un groupe beaucoup plus
important de professionnels, mis sur pied
partir de diffrents points de vue de relecture,
a rpondu un questionnaire dtaill pour
chaque description de domaine de
connaissances. Les points de vue (par
exemple, ceux des praticiens, des enseignants
et des responsables de politiques publiques)
ont t formuls de faon sassurer de
ladquation du guide aux divers publics
viss. Les commentaires des relecteurs de ce
cycle, qui a pris fin en octobre 1999, sont
aussi disponibles sur le site Web du projet.
Les
spcialistes
des
domaines
de
connaissances dcriront leur tour comment
les commentaires des relecteurs ont t pris
en compte dans les descriptions des domaines
de connaissances.
Le troisime cycle de relecture portera sur la
justesse et lutilit du guide. Ce cycle, dont le
dmarrage est prvu pour janvier 2000, sera
effectu par des personnes et des organismes
dfinissant un profil des groupes dintrt
potentiels (voir lencadr Comment
contribuer au projet ). Nous avons dj
recrut des centaines de professionnels pour
relire le guide au complet et nous en
sollicitons davantage pour en assurer la
couverture complte.

Conclusion
Tout au cours du projet, lquipe SWEBOK a
rendu disponibles des documents dcrivant
concrtement lavancement du projet. La
plupart de ces documents sont publics et
peuvent tre consults sur le site Web du
projet. (Par courtoisie envers les spcialistes
des domaines de connaissances, les
documents provisoires ne seront pas diffuss
avant leur achvement.) Lquipe du projet
met actuellement jour les descriptions des
domaines de connaissances en tenant compte
des rsultats du deuxime cycle de relecture.
Au tout dbut de lan 2000, nous inviterons
les associations professionnelles et la
communaut du gnie logiciel participer au
troisime cycle de relecture et faire part de
leurs commentaires sur lensemble du guide.
La version Stoneman du guide ainsi termine
sera disponible sur le site Web au cours du
printemps 2000 et, dans la mesure du
possible, les documents de rfrence cits
seront gratuits.
Avant de dvelopper la version Ironman du
guide, nous utiliserons la version Stoneman
dans le cadre dapplications exprimentales
afin den dterminer la facilit dutilisation.
Bien que la couverture vise soit identique, le
dveloppement dIronman aura recours un
processus de relecture plus large et plus
exhaustif ; ce processus reposera en effet sur
des utilisations exprimentales du guide.
REMERCIEMENTS
Lquipe du projet SWEBOK tient
remercier les membres du comit industriel
consultatif pour leur support. Le financement
du projet est assur par lAssociation for
Computing Machinery, Boeing, Conseil
national de recherches du Canada, lIEEE
Computer Society, le National Institute of
Standards and Technology, Raytheon et SAP
Labs (Canada). Lquipe tient remercier
aussi les spcialistes des domaines de
connaissances pour leur travail considrable.
Enfin, lquipe est reconnaissante aux
relecteurs
pour
leur
indispensable
contribution.
Les auteurs tiennent galement remercier
M. Jean-Claude Rault, Mme Sybille Wolff et
Mme Louise Tremblay qui ont tous contribu
la traduction de cet article.
Les lecteurs peuvent contacter les auteurs en
s'adressant James W. Moore ladresse
suivante :
The MITRE Corp., 1820 Dolley Madison
Blvd., W534, McLean, VA 22102, tats-Unis
;

Courriel : james.w.moore@ieee.org
RFRENCES
[1] P. Bourque et coll., Guide to the Software
Engineering Body of Knowledge: A Strawman
Version, Universit du Qubec Montral,
1998, http://www.swebok.org .
[2] D.J. Bagert et coll., Guidelines for
Software Engineering Education, Version 1.0,
Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, novembre
1999
http://www.sei.cmu.edu/collaborating/ed/wor
kgroup-ed.html .
[3] Project Management Institute, A Guide to
the Project Management Body of Knowledge,
Upper Darby, Pennsylvanie, 1996 ;
http://pmi.org/publictn/pmboktoc.htm
[4] W. Vincenti, What Engineers Know and
How They Know It: Analytical Studies from
Aeronautical History, The Johns Hopkins
University Press, Baltimore, 1990.

COMMENT CONTRIBUER AU PROJET

Les lecteurs souhaitant participer au troisime cycle de relecture qui portera sur lensemble du
guide du corpus des connaissances sur le gnie logiciel peuvent sinscrire sur le site Web du projet
(http://www.swebok.org). Le passage de la version Stoneman la version Ironman reposera
principalement sur les ractions aux applications exprimentales du guide Stoneman. Les personnes
intresses
par
ces
applications
sont
invites

contacter
Pierre
Bourque
(bourque.pierre@uqam.ca).

Tableau 1. Les domaines de connaissances du projet SWEBOK et leurs spcialistes

Domaine de connaissances
Spcialistes
Gestion de configuration du logiciel
John A. Scott et David Nisse, Lawrence
Livermore Laboratory, tats-Unis
Construction du logiciel
Terry Bollinger, The Mitre Corporation, tatsUnis
Conception du logiciel
Guy Tremblay, Universit du Qubec
Montral, Canada
Infrastructure du gnie logiciel
David Carrington, University of Queensland,
Australie
Management du gnie logiciel
Stephen G. MacDonnell et Andrew R. Gray,
University of Otago, Nouvelle-Zlande
Processus du gnie logiciel
Khaled El Eman, Conseil national de recherches
, Canada
volution et maintenance du logiciel
Thomas M. Pigoski, Techsoft, tats-Unis
Analyse de la qualit du logiciel
Dolores Wallace et Larry Reeker, National
Institute of Standards and Technology, tatsUnis
Analyse des exigences du logiciel
Pete Sawyer et Gerald Kotonya, Lancaster
University, Grande-Bretagne
Test du logiciel
Antonia Bertolino, Consiglio Nazionale delle
Ricerche, Italie

Figure 1. Lorganisation de la description dun domaine de connaissances

Division hirarchique des sujets
Tableau matriciel des sujets et des documents de rfrence
Documents de rfrence
Descriptions des sujets
Classification selon la taxinomie de Vincenti
Catgories pdagogiques selon la taxinomie de Bloom
Rfrences relatives aux disciplines connexes
Figure 2. Une reprsentation visuelle du guide
LE GUIDE DU CORPUS DES CONNAISSANCES EN GNIE LOGICIEL
GESTION DE CONFIGURATION DU LOGICIEL
- Conduite du processus de gestion de configuration
- Identification de la configuration logicielle
- Contrle de la configuration logicielle
- Compte rendu de ltat de la configuration logicielle
- Vrification de la configuration logicielle
- Gestion et livraison des versions du logiciel
(a)

CONSTRUCTION DU LOGICIEL
- Mthodes de construction linguistiques
- Mthodes de construction mathmatiques
- Mthodes de construction visuelles
- Rduction de la complexit
- Anticipation de la diversit
- Structuration pour la validation
- Utilisation de normes externes
(b)
CONCEPTION DU LOGICIEL
- Concepts de base et principes
- Qualit de la conception et mesures
- Architecture logicielle
- Notations de conception
- Stratgies et mthodes de conception
(c)
INFRASTRUCTURE DU GNIE LOGICIEL
- Mthodes de dveloppement
Mthodes heuristiques
Mthodes formelles
Mthodes de prototypage
- Outils logiciels
Outils de dveloppement et de maintenance
Outils pour activits de support
Outils de management
Ateliers : outils intgrs et environnements de gnie logiciel
Techniques dvaluation des outils
- Intgration des composants
Dfinition des composants
Modles de rfrence
Rutilisation
(d)
MANAGEMENT DU GNIE LOGICIEL
- Processus du management
Coordination
Dmarrage et dfinition de la porte
Planification
Excution
Revue et valuation
Clture
- Mesure
(e)
PROCESSUS DU GNIE LOGICIEL
- Concepts de base et dfinitions
Thmes
Terminologie
- Dfinition des processus
Dfinitions des types de processus
Modles de cycle de vie
Modles de processus de cycle de vie
Notations pour les dfinitions de processus
Mthodes de dfinition des processus

Automatisation
- valuation des processus
Mthodologie de la mesure des processus
Paradigme analytique
Paradigme de lvaluation des performances
- Mise en uvre et modification des processus
Paradigmes pour la mise en uvre et la modification des processus
Infrastructure
Consignes pour la mise en uvre et la modification des processus
valuation de la mise en uvre et de la modification des processus
(f)
VOLUTION ET MAINTENANCE DU LOGICIEL
- Concepts de la maintenance
Activits et rles de la maintenance Processus de la maintenance Aspect organisationnel de la
maintenance
Problmes de la maintenance du logiciel
Cot de la maintenance et estimation du cot de la maintenance
Mesures de la maintenance
- Outils et techniques pour la maintenance
(g)
ANALYSE DE LA QUALIT DU LOGICIEL
- Dfinition de la qualit des produits
Caractristiques de la qualit selon la norme ISO 9126
Scurit de fonctionnement
Volets de la qualit relatifs aux processus et aux contextes particuliers
- Analyse de la qualit du logiciel
Dfinition de lanalyse de la qualit
Plans des processus
Activits et techniques de lanalyse de la qualit
Mesure en matire danalyse de la qualit du logiciel
(h)
ANALYSE DES EXIGENCES DU LOGICIEL
- Processus de lingnierie des exigences
- Clarification des exigences
- Analyse des exigences
- Validation des exigences
- Management des exigences
(i)
TEST DU LOGICIEL
- Concepts de base et dfinitions
- Niveaux de test
- Techniques de test
- Mesures relatives au test
- Organisation et contrle du processus de test
- Automatisation du test
(j)