Cycle de Vie Des Logiciels

Cycle de vie des
logiciels
Démarche Projet Classique
Etape0 Etape1
1ere Rencontre Création

Demande Client
Pour définir le besoin équipe projet
Cahier des
charges
Etape2
Cahier des charges
Choix d’un cycle Recueil

de développement Devis et Planning GO client
existant
Étude coût & Délais
Plan qualité Analyse
Retouche sur demande client Fonctionnelle
Etape5 Etape3
Analyse
F. OK
Cycle de Déploiement Recette
Développement
Spécifications détaillé
Plan test
maintenance Post Mortem
Plan déploiement
Etape4 Etape6 Etape7
Cycle en V
Analyse du Exploitation
besoin et
maintenance
Qualification
opérationnel
le
Spécificatio Validation
n système système
Spécification Validation
sous-systèmes Sous-
systèmes
Conceptio Test
n d’intégratio
préliminair n
e
Conception Test sous-
détaillée systèmes
Réalisatio
Étapes du cycle de vie Principaux documents Contrôles qualité
0 Préliminaires - Cahier des charges Revue de contrat

- Appel d'offres
- Contrat
1 Planification - Note de lancement Revue de planification

-. Plan d'assurance qualité
- Plan de développement
2 Spécifications - Dossier de définition des besoins/ Cahier des charges Revue de spécifications
- Spécifications d'interface
- Dossier tests de validation
3 Conception générale - Dossier de conception générale Revue de conception générale

- Dossier tests d'intégration
4 Conception détaillée - Dossier de conception détaillée Revue de conception détaillée

- Dossier tests unitaires
5 Codage - Listings de programme Revue de code

- Documentation programme
6 Tests unitaires - Cahier de tests unitaires Revue de tests unitaires

- Bilan des tests unitaires
7 Intégration - Cahier de tests d'intégration Revue d'intégration

- Bilan de l'intégration
- Dossier d'installation
- Dossier d'exploitation
8 Recette - Cahier de tests de validation Revue de recette

- Bilan de la recette
9 Installation/diffusion - Cahier de l'installation Revue d'installation
Exploitation - Dossier de maintenance

Maintenance (hors projet)
processus de la relation client/fournisseur. Non
seulement les bases de la collaboration doivent être
Etapes 0 : Les Processus
établies avec précision dès le départ, mais aussi les
Préliminaires
modalités de leur évolution éventuelle doivent être
prévues afin d'être en mesure de supporter sans
encombre les événements qui ne manqueront pas de
survenir pendant la vie du projet.
C'est à cet endroit qu'il importe de préciser les rôles

et responsabilités de :
La maîtrise d'ouvrage qui commande et qui finance le
projet.
La maîtrise d'oeuvre qui réalise les différents produits
à livrer.
Pour des projets clairement définie par le client ,Le
Cahier des Charges peut être fournie a cette étape , il
sera contractuel
Préliminaires
Cette étape est capitale pour le bon
déroulement du projet. Elle s'applique quelles
que soient les caractéristiques des produits
logiciels à fabriquer (logiciel sur mesure,
progiciel, intégration de solution ou
simplement prestations intellectuelles). La
place prépondérante du client dans tout
système de management de la qualité
implique une attention toute particulière à
ces processus client/fournisseur qui mettent
en jeu des métiers et des hommes qui ne
sont pas tous des techniciens de
l'informatique. Dans cette étape il y aura les
processus suivants
Préparation.
Sélection des fournisseurs.
Administration des fournisseurs
Préliminaires
Les livrables
Les livrables auront une structure
spécifique en fonction des besoins du
client et du fournisseur. Ils seront
donc agréés en commun par
l'organisme ou par l'entreprise. Il
y aura les différents documents
d'appel d'offres, de contrat, de
suivi fournisseur et d'évaluation
de produits.
ÉTAPE 1:INITIALISATION
D'UN PROJET -LA PLANIFICATION
L'objectif de cette première étape est d'initialiser le projet
et de planifier les travaux nécessaires à
l'accomplissement de la réalisation du projet dans de
bonnes conditions. L'initialisation du projet sera
matérialisée par la rédaction et la diffusion d'une note
de lancement.
Pour la planification des travaux, le projet va être
décomposé en plusieurs lots, chaque lot comportant un
certain nombre d'étapes. Ce découpage va être observé
selon deux axes:
Une vue organisation de la qualité, dont les résultats des
travaux d'étude seront consignés dans le document plan
d'assurance qualité logiciel.
Une vue évaluation initiale du projet (véritable devis du
projet), dont les résultats des travaux d'étude seront
consignés dans le document plan de développement
logiciel.
Le plan qualité logiciel/plan d'assurance qualité
logiciel (PAQL)
Le plan d'assurance qualité logiciel est le
document par lequel le chef de projet (et son
équipe) décrivent les dispositions spécifiques
prévues par l'organisation ou l'entreprise afin
d'obtenir la qualité du produit logiciel ou du
service résultant du projet en question.
L'appellation «assurance qualité» dans le
nom de ce document signifie qu'il s'applique
à la relation client/fournisseur définie pour un
projet donné et qu'il est communicable à
l'extérieur de l'entreprise en respectant bien
Ainsi le PAQL va décrire le système de
management de la qualité du projet, c'est-à-
dire
La démarche qualité.
Le référentiel et les méthodes utilisés.
Les outils mis en place.
Les contrôles prévus et planifiés.
Les procédures d'assurance qualité
Elles font références aux procédures qualité
générales de l'entreprise et aux procédures
générales définies pour l'ingénierie du
logiciel. Elles seront complétées et enrichies
si besoin est pour répondre aux exigences
particulières du projet.
Les livrables
La note de lancement
La note de lancement est le document par
lequel la direction de la maîtrise d'ouvrage
d'un projet fait connaître officiellement sa
volonté et sa décision d'engager le projet
concerné. Ce document rappellera les
objectifs et les contours du projet lancé. Il doit
impérativement comporter l'identification du
chef de projet (ou de l'équipe) qui a été choisi
pour diriger les opérations et les moyens qui
lui ont été alloués pour réussir. Ce document
ne requiert pas de formalisme particulier
autre que le respect des règles de la gestion
documentaire instaurées au sein de
l'entreprise.
ETAPE2 : LES
SPECIFICATIONS
L'objectif de cette étape de spécifications
c'est l'étude et la prise en compte des
exigences fonctionnelles et des
contraintes des utilisateurs du système
d'information ou du logiciel. Spécifier
c'est répondre à la question « Quoi » ?
Cette réflexion amène à définir les
besoins. Il importe de préciser le plus
clairement possible ce que les futurs
utilisateurs attendent du projet. Dans
cette étape il y aura les processus
ETAPE2 : LES
Phase1
SPECIFICATIONS
Définition des objectifs
Recueil des besoins
Liste des contraintes
Phase2
Spécifications du système
Formalisation du Dossier
Validation spécifications
ETAPE2 : LES
SPECIFICATIONS
Les livrables
Le dossier de définition des besoins (qui dans certains
cas fait office de cahier des charges)
Le dossier de définition .des besoins est le document par
lequel le chef de projet (et son équipe) formalisent
avec un maximum de précision les exigences et
spécifications exprimées par les utilisateurs. Ce
support représente le consensus sur lequel l'accord de
tous a été obtenu sur les fonctions supportées par le
nouveau système logiciel et ses livrables. Le dossier
de définition des besoins doit être rédigé en commun
avec les utilisateurs, les organisateurs et les
informaticiens. Il est écrit en langage compréhensible
par les utilisateurs non informaticiens. Le recueil des
besoins s'opère en suivant une démarche
intellectuelle itérative entre :
L'observation de l'état actuel de l'organisation (analyse
de l'existant).
La projection des spécifications pour répondre aux
exigences (système cible).
ETAPE2 : LES
SPECIFICATIONS
On se souviendra qu'il existe une
difficulté majeure dans l'expression des
besoins. Il y a les besoins explicites
relativement facilement saisissables car
ils sont exprimés. Par contre les besoins
implicites, invisibles par définition, sont
souvent les plus importants, lourds de
conséquences et les plus complexes à
appréhender. Il est aussi nécessaire
d'identifier puis de lister les contraintes.
Les contraintes peuvent être d'ordre
fonctionnel ou d'ordre technique
ETAPE2 : LES
SPECIFICATIONS
Les spécifications du futur système
comprendront une architecture générale du
fonctionnement du système projeté avec les
liaisons entre les fonctions. Chaque fonction
et sous-fonction sera décrite. Une description
de fonction comporte : les entrées, les
sorties, les principaux traitements, les règles
de gestion et les blocs de données
manipulées. Pour illustrer le fonctionnement
du futur système l'équipe de projet aura
recours à des représentations graphiques. Le
modèle conceptuel de communication peux
donner une vue rapide des échanges. Le
diagramme fonctionnel donne une image
ETAPE2 : LES
SPECIFICATIONS
En parallèle à l'étude des principales
fonctions, l'équipe de projet s'attachera
à recueillir des éléments en vue de la
recette utilisateur . la recette qui
s'appuie sur le dossier de tests de
validation. Pour chaque fonction
retenue on identifiera les critères
d'acceptation correspondants. Ces
critères permettront d'apprécier
pendant les tests métier (qualification),
si les exigences des utilisateurs,
exprimées dans le dossier de définition
ETAPE2 : LES
SPECIFICATIONS
Exemple de modèle de communication
flux2
Acteur3
Acteur1
flux1 flux3
Acteur2
ETAPE2 : LES
SPECIFICATIONS
Exemple de diagramme fonctionnel
Fonction 1
Fonction 2
Fonction 4 Fonction 3
Fonction 5 Fonction 6 Fonction 7

ETAPE3 : LA CONCEPTION
L'objectif de cette troisième étape est de concevoir
l'architecture du système logiciel. La solution pensée en
terme de métier utilisateur, ébauchée et retenue lors
des spécifications, va être imaginée en prenant en
compte la dimension technique des outils informatiques.
Concevoir c'est répondre à la question « Comment » ?
Cette réflexion, pour être plus efficace, est conduite en
deux temps
La conception générale (ou préliminaire). La conception
détaillée.
Les réponses apportées se distinguent par des niveaux de
granularité différents, allant d'une vue globale pour la
conception générale à une vue plus rapprochée pour la
conception détaillée.. Dans cette étape il y aura les
processus suivants
Conception de l'architecture du système (conception
générale).
Analyse des exigences du logiciel.
La conception générale
Elle a pour objectif d'étudier 1'architeclure générale
du système/logiciel par ensembles fonctionnels
homogène conformément aux exigences des
utilisateurs exprimées dans le dossier de
définition des besoins (cahier des charges). Les
concepteurs chargés de cette étude vont
imaginer les moyens techniques informatiques de
construction de la solution à partir
De l'analyse de l'existant.
De l'ébauche de solution proposée en définition des
besoins.
Puis, comme des architectes du bâtiment, ils vont
dessiner cette architecture fonctionnelle qu'ils ont
imaginée. Une représentation explicite des
projets est obtenue au moyen de graphes.
 Pour une conception de gestion selon la méthode
Merise, les concepteurs utiliseront des graphes de
type modèle conceptuel de communication
(MCC), modèle conceptuel des traitements (MCT)
et modèle conceptuel des données (MCD).
 Pour une conception de type objet selon la
méthode UML, les concepteurs utiliseront des
graphes de type diagramme de collaboration,
diagramme de séquence, diagramme de classes,
diagramme d'objets, diagramme d'états
transitions, diagramme d'activités, diagramme de
composants, diagramme de déploiement.
 Pour une conception de type traitement
asynchrone, les concepteurs utiliseront des
graphes de type modèle des cas d'utilisation,
diagramme de questionsréponses
Toutefois la représentation graphique

(choisie en fonction de la technologie
de développement utilisée) n'exclut pas
la production d'un texte clair et précis
décrivant chacune des fonctions
supportées par le futur système. Les
deux formulations sont
complémentaires
 Logigramme de conception générale
Architecture fonctionnelle
Découpage en lots
Lot n° 1 Lot n° 2 Lot n° n
Conception du lot
Procédures dégradées
Éléments de tests
Éléments d'exploitation , d'utilisation
Évaluation étape suivante
Validation de la solution
 La conception détaillée
 Elle a pour objectif d'étudier l'architecture
technique du système/logiciel par ensembles
techniques conformément au découpage
fonctionnel réalisé lors de la conception
générale. Les concepteurs chargés de cette
étude vont imaginer finement l'architecture
technique à mettre en oeuvre. L'impact des
technologies envisagées pour l'étape suivante
de réalisation est très fort. Les choix
fonctionnels de la conception générale sont,
confirmés dans leur implémentation technique.
Les choix organisationnels sont arrêtés
définitivement. Les dernières options techniques
 la répartition des traitements entre homme et
machine
 Les volumes et les temps de transfert sur les
réseaux.
 Les temps de réponse aux requêtes.
 La détermination des meilleurs outils
répondant aux problèmes posés.
 La réutilisation de briques logicielles
techniques ou métiers.
 La résolution des contraintes d'exploitation et
d'utilisabilité.
 La disponibilité du service offert aux
utilisateurs.
Puis, les concepteurs vont dessiner cette
architecture technique qu'ils ont
imaginée et choisie. Unes
représentation explicite des projets est
obtenue au moyen de graphes. Ainsi,
pour une conception de gestion selon la
méthode Merise, les concepteurs
utiliseront des graphes de type modèle
organisationnel des traitements (MOT)
et modèle logique des données (MLD).
L'architecture technique retenue fait
apparaître des sous-ensembles
 Ces sous-ensembles étant eux-mêmes
décomposés en unités de traitement (UT),
c'est-à-dire en programmes exécutables (exe,
dll, applet...) qui s'enchaînent entre eux. À ce
niveau de l'analyse, la qualité de la
description doit être suffisamment fine et
précise pour permettre la programmation.
Pour chaque unité de programme à
construire, il faudra notamment préciser
 Quelles sont les entrées ?
 Quelles sont les sorties?
 Quels sont les traitements (par exemple : lecture,

calcul, mise à jour, écriture...) ?
 Quels sont les contrôles à effectuer?
 Quels sont les algorithmes à utiliser?
 Quelles sont les données a Manipuler
Si plusieurs concepteurs travaillent en parallèle, il sera

nécessaire d'effectuer une vérification de la
Architecture Technique
• Logigramme de Graphe générale
conception Détaillées Decoupage en UT
Diagramme de type MOT par UT
Description transaction Description batch Description Client-SRV Description

Navigation
Description Objets
Algo de calcul
Recette technique
Dossier d’exploitation et d’utilisation
Évaluation étape suivante
Validation
 Les livrables
 Le dossier de conception générale
Le dossier de conception générale est le document par
lequel l'équipe projet formalise l'architecture
fonctionnelle du futur système/logiciel objet du projet.
Ce document explicite, pour un projet logiciel donné,
comment les moyens organisationnels seront utilisés
afin de répondre aux exigences de la maîtrise d'ouvrage
et aux standards de développement mis en place. Il
traite les thèmes suivants :
 Les objectifs du dossier.
 la description de l'environnement du projet.
 Le processus de conception générale proprement
dit, avec:
- la représentation de l'architecture organisationnelle des
fonctions
- le découpage éventuel en lots
 ensuite chaque lot possède ses
éléments d'analyse avec :
 le graphe modèle conceptuel des
traitements (MCT),
 les processus fonctionnels de gestion,
 les règles de gestion utilisées
 les maquettes des écrans
 les maquettes des états d'édition
 les traitements prévus de conversion/reprise
des données des systèmes existants
 les procédures de fonctionnement dégradé en
cas d'incident (service partiel)
 les éléments qui serviront de critères pour les
essais de tests d'intégration, les premiers
éléments d'exploitation et d'utilisation tel
qu'on peut les imaginer ,compte tenu des
résultas de la conception générale, faire une
réévaluation de la planification (plan de
développement et éventuellement plan
qualité).
 Les processus fonctionnels

 Un processus fonctionnel est un
ensemble d’actions et d’opérations qui
se déroulent sans interruption en
suivant un ordre préétabli et dans un
intervalle de temps donné. Le
processus est initialisé par un ou des
événement déclenchants synchronisés
entre eux. Il produit un ou plusieurs
résultats qui peuvent être événements
d’un autre processus fonctionnel.
Il y a trois catégories de processus
 Temps réel (ou TP).

 Temps différé (ou batch).
 De service
 Maquettes des écrans et des éditions
 Les maquettes permettent de donner une
idée des sorties du futur système bien avant
que celles-ci n'existent. Elles favorisent le
dialogue entre les concepteurs et les
utilisateurs, en effet elles sont indispensables
à la conception (partie visible du produit
logiciel). L'accord des utilisateurs, est obtenu
sur les moindres détails de présentation.
Des critères ergonomiques sont pris en
compte.
 Le prototypage des entrées/sorties est une
aide à la validation des choix.
 Les interfaces
 Les liaisons entre les différents modules
du système ne doivent pas être
négligées. De même, il ne faudra pas
oublier de décrire les structures et les
protocoles de communication entre le
système projeté et les autres systèmes
internes et externes à
l'organisation/entreprise et constituant
toutes les couches environnementales.
Souvent l'environnement est
générateur de contraintes fortes et sur
 Conversion et reprise des données
 De plus en plus, les nouveaux systèmes se
substituent à des logiciels existants ou bien il
existe des données stockées dans des
fichiers. Pour gagner du temps et bénéficier
des données acquises il va falloir procéder à
des traitements spéciaux de reprise et de
conversion ou de transcodage de données.
Dans certains cas ces travaux sont si
importants qu'ils nécessitent un projet
complet et spécifique pour les traiter. Il s'agit
de réutiliser des anciens fichiers, des tables
et des bases de données représentant des
données actives ou des historiques sur
plusieurs années. Il ne faut pas oublier ou
sous-estimer ces travaux qui sont longs,
partiellement automatisables, nécessitant des
 Procédures dégradées
 Aujourd'hui les systèmes doivent
fonctionner 24 heures sur 24 et 7 jours
sur 7. Dès la conception il faut prévoir
impérativement des procédures
simplifiées et réduites assurant une
aide aux utilisateurs dans les cas
d'anomalie de fonctionnement ou de
communication (service minimum).
 Préparation des essais (tests

d'intégration)
 Pour chaque fonction essentielle, les
concepteurs identifieront le plan de
tests et les critères d'acceptation qui
permettront de qualifier le
système/logiciel dans l'étape de tests
d'intégration qui est symétrique à la
conception générale (voir la branche
droite du modèle en « V »)
 Préparation de l'exploitation et de
l'utilisation
 À ce stade il s'agit de recueillir toutes
les informations disponibles qui sont
susceptibles de conditionner l'utilisation
et l'exploitation future du
système/logiciel. Notamment il faut
tenir compte des contraintes
fonctionnelles (domaine utilisateur) et
des contraintes techniques
(environnement du site d'exploitation).
 Les outils de modélisation

 Dans le cas d'une modélisation avec les
outils de la méthodologie Merise, pour
cette conception générale, nous
proposons d'utiliser la modélisation
conceptuelle des données et des
traitements. Le niveau conceptuel étant
le premier niveau d'abstraction du
monde réel observé.
 Le dossier de conception détaillée
 Le dossier de conception détaillée est le
document par lequel l'équipe de projet
formalise l'architecture technique du
future système/logiciel objet du projet.
Ce document explicite, pour un projet
logiciel donné, comment les moyens
techniques seront utilisés afin de
répondre aux exigences de la maîtrise
d'ouvrage, à la conception
organisationnelle générale et aux
standards de développement mis en
Le dossier de conception détaillé

matérialise la fin des étapes d'études
avant le passage à l'étape de
réalisation. Il doit être finalisé avec le
plus grand soin et recueillir l'accord
(validation) de la maîtrise d'ouvrage, de
la même façon que la construction
d'une maison n'est entreprise que
lorsque les plans sont terminés et
approuvés par le client.
Le dossier de conception détaillée traite les
thèmes suivants
 Les objectifs du dossier.
 La description de l'environnement du projet.
 Le processus de conception détaillée
proprement dit, avec

 la structure technique finement décrite du
système/logiciel;
 le contenu précis du système/logiciel
 le dossier de tests unitaires qui servira pour les
essais de tests unitaires

 le dossier d'exploitation et le manuel d'utilisation ;
 un contrôle de cohérence sera réalisé sur
l'architecture technique
compte tenu des résultats de la conception détaillée,
L'architecture technique
Elle a pour objectif de décrire les composants et leur
disposition à l'intérieur du système/logiciel. Ces
descriptions doivent couvrir
 La manière dont s'enchaînent les traitements.
 La structure des données et leurs agrégations.
 Les interfaces qui réalisent les liaisons entre les sous-

ensembles du syst
 Les interfaces avec les autres systèmes internes ou
externes a l'entreprise.
 Les protocoles de communication.
 La formulation exacte des algorithmes de calcul.
 La désignation de tous les outils utilisés : matériels,

logiciels système, utilitaires, progiciels, système de
gestion de données, atelier de Génie logiciel etc.
Les Technologies
Les techniques pour le traitement des données
seront de type
 Temps différé : Le traitement s’effectue en
l’absence de l’utilisateur
 Temps réel : L’utilisateur connecté à un site
central par un terminal passif
 Client serveur : l'utilisateur est situé sur un
micro-ordinateur qui effectue la présentation
graphique, il est connecté à un serveur qui
gère les données (ou des applications).
 Navigationnel : l'utilisateur situé sur un poste
de travail est connecté au moyen d'un réseau
à des serveurs qui lui envoient des modules
Les unités de traitement
Un diagramme des traitements de l'unité logicielle
permettra de disposer d'une vue précise des tâches
réalisées par le logiciel. Ce type de diagramme sera
réutilisé ultérieurement en maintenance. La description
doit nécessairement comprendre :
 Les entrées.
 Les sorties.
 Les traitements (par exemple : lecture, calcul, mise à

jour, écriture...).
 Les contrôles à effectuer.
 Les algorithmes (règles de calcul) à utiliser.
 Les données à manipuler.
 Les formes et structures des interfaces.
 Les règles de conversion des données

Préparation des essais (tests unitaires)

 Pour chaque unité de traitement, les
concepteurs identifieront le plan de

tests et les critères d'acceptation qui
permettront de qualifier le logiciel dans
l'étape de tests unitaires qui est
symétrique à la conception détaillée
(voir la branche droite du modèle en «
V»
Préparation de l'exploitation et de
l'utilisation
 Les informations relatives à l'utilisation
et l'exploitation du futur
système/logiciel, recueillies en
conception générale, sont complétées
avec les éléments techniques
disponibles maintenant. Le dossier
d'exploitation est formalisé. Pendant ce
temps, les organisateurs et les
utilisateurs de la maîtrise d'ouvrage
vont préparer les procédures
d'utilisation (manuel utilisateur ou
Évaluation précise de la réalisation -

révision de la planification
 À ce stade, le chef de projet dispose
des plans précis et détaillés du
système/logiciel à construire. Il est donc
en mesure de dresser le chiffrage
précis de la phase suivante de
réalisation. À cette occasion le plan de
développement (et éventuellement le
plan qualité) devra être revu et
actualisé afin de tenir compte des
dernières informations disponibles et de
ETAPE4 : LA REALISATION
(codage, tests unitaires, tests
d’intégration)
L'objectif de cette quatrième étape est de
réaliser le système/logiciel tel qu'il a été
imaginé par les concepteurs. La réalisation
comprend trois parties distinctes
 Le codage des programmes.
 Les tests unitaires programmes par

programme.
 Et les tests d'intégration du système/logiciel

d’intégration)
 Le codage
 Le codage des programmes consiste à traduire en code,
compréhensible par un ordinateur, l'architecture
technique, qui a été conçue. Chaque programme, ou
sous-programme, va être confié à un développeur qui le
traduira dans un langage de programmation qui sera
fonction du projet (exemples de language : Cobol,
Fortran, C, C++, Visual Basic, HTML, Java, DELPHI ,
C#...), compatible avec le système d'exploitation
(exemple de système d'exploitation : OS. UNIX,
DOS,WINDOWS xx, NT,XP, Linux...) et le matériel utilisé.
De plus eu plus, on utilise des outils automatiques de
production de code. des générateurs de programmes et
des ateliers de génie logiciel qui déchargent le
développeur des parties graphiques (IHM)
d’intégration)
Le code crée doit répondre à des critères de
qualité : clarté, lisibilité, modularité... Il doit
être documenté avec des commentaires
nombreux et explicites qui permettront une
compréhension aisée pour les personnels
chargés de la maintenance ultérieurement.
Des règles d'identification et de nommage
sont constituées pour les programmes, les
fonctions, les données (fichiers et bases de
données), les traitements communs.
L'industrialisation de la programmation
conduit à réaliser des briques logiciel
réutilisables, brique technique (exemple :
accès à des données, traitement d'erreur... )
ou brique métier (par exemple : calcul
d'intérêts). Ensuite, le développeur travaille
d’intégration)
Le service méthode et qualité de l'entreprise va
définir des standards de programmation par
catégorie de technologie utilisée. De même
des procédures sont rédigées pour normaliser
l'utilisation des différents environnements de
travail mis à disposition sur un site. Les
développeurs doivent appliquer ces normes,
standards et procédures. La standardisation
des programmes permet d'harmoniser la
communication entre les développeurs d'une
même équipe, voire entre les personnels de
plusieurs équipes de projet. Puis entre les
projets et la maintenance. Des revues de
code servent à vérifier le respect de ces
d’intégration) Codage
Traduire la conception détaillé en code
Saisir le code
Inclure les commentaires
Compléter les dossiers de tests unitaires
Revoir les dossiers d’exploitation et intégration
Faire la revue de code
Vers tests unitaires

d’intégration)
 Les tests unitaires
C'est le premier niveau de test. Il correspond aux
essais effectués sur la pointe du « V » du processus
de développement du logiciel. Les tests unitaires
comportent deux parties : la préparation et
l'exécution. La préparation des essais a été établie
pendant la conception détaillée pour déterminer sur
quels critères le logiciel répond aux exigences
techniques. L'exécution des essais, vérification
proprement dite, sera confiée au développeur qui a
codé le programme ou la brique logicielle
d’intégration)
Dossier
des tests
unitaires
Tests unitaires non
Cahier Modèle validé

De recette
unitaire oui
d’intégration)
La préparation des tests
Le jeu d'essai unitaire est conçu afin de satisfaire aux exigences
suivantes
Passer au moins une fois dans chacune des branches de
l'arborescence du programme.
Contrôler la validité des algorithmes de calcul.
Tester tous les cas non passants (cas qui déclenchent un message
d' anomalie).
Tester les valeurs limites prévues dans le dossier de conception
détaillée.
Tester les accès à des informations externes en créant des «
répondeurs » qui simuleront la mise à disposition de
l'information nécessaire.
Les cas d'un test unitaire permettent de vérifier les règles
d'intégrité, de contrôler la cohérence sur les valeurs de chaque
rubrique, de s'assurer que les valeurs saisies sont valides,
qu'elles répondent aux critères, (obligatoire, facultatif, existe
dans une table la liste de valeurs autorisées).
d’intégration)
L'exécution des tests
A partir des plans de tests élaborés lors du
processus de préparation, les personnes en
charge des tests vont :
- Dérouler les scénarios.
- Vérifier que les résultats obtenus sont conformes,
aux résultats attendus.
- Relever dans une fiche d'anomalie tous les écarts
constatés.
- Tenir à jour une main courante des essais
effectués.
Les données d'essai, les scénarios de test et les
résultats obtenus sont conservés afin de pouvoir
servir de référence ultérieure.
Le chef de projet s'assure que les essais ont
d’intégration)
 Les tests d'intégration
 C'est le deuxième niveau de contrôle. Il
correspond aux essais effectués sur la
branche droite du « V » du processus de
développement du logiciel . Les tests
d'intégration comportent deux parties : la
préparation et l'exécution. La préparation des
essais a été établie pendant la conception
générale pour déterminer sur quels critères le
logiciel répond aux exigences fonctionnelles.
L'exécution des essais, vérification
proprement dite, sera confiée à une équipe
de « recetteurs » distincte des développeurs
d’intégration)
Dossier
des tests
D’intégration
Tests
d’integration non
Cahier Sous-système
De recette
D’intégration validé
Modèle validé
oui
d’intégration)
 La préparation des tests
Les jeux d'essai d'intégration sont conçus
afin de satisfaire aux exigences
suivantes
- Essayer les fonctionnalités prévues au
dossier de conception générale.
- Contrôler chacune des règles de
gestion.
- Passer au moins une fois dans chacun
des modules de l'arborescence de la
d’intégration)
- Vérifier l'impact des événements qui se
répercutent à d'autres endroits de la
chaîne.
- Choisir des cas passants en nombre
suffisant pour tester les débordements.
- Tester les interfaces avec les autres
systèmes en créant des « répondeurs »
qui simuleront la mise à disposition de
l'information nécessaire
d’intégration)
 Les scénarios de tests d'intégration, obtenus
par assemblage organisé de cas de test,
permettent de vérifier les règles de gestion,
la cohérence des données entre elles, les
valeurs résultats de formules de calcul et les
structures conditionnelles (déclencheurs).
C'est aussi le moyen de contrôler les
fonctionnalités unitaires et intégrées du
système/logiciel.
Les tests d'intégration portent sur :
 Une chaîne de traitement batch.
 Un menu et ses transactions associées.
 Une chaîne informatique complète

d’intégration)
 L'exécution des tests
À partir des plans de tests élaborés lors du

processus de préparation, les personnes en
charge des tests vont Dérouler les scénarios
(appelés aussi scripts).
Vérifier que les résultats obtenus sont conformes
Relever dans une fiche d'anomalie tous les écarts
constatés.
Tenir à jour une main courante des essais
effectués.
Les données d'essai, les scénarios de test et les
résultats obtenus sont conservés afin de pouvoir
servir de référence ultérieure. Les tests
d'intégration sont sous la responsabilité du
d’intégration)
 Les livrables
À la fin de la phase de codage on obtient des
produits documentés (avec des dossiers de
programme) et après chaque étape
d’exécution de tests on obtient :
 Des fiches d'anomalies à transmettre au
développeur pour correction,

 Des fiches d'évolutions à prendre en compte
dans une version ultérieure, du logiciel

 La liste des scénarios testés avec date de
passage de résultat du test (bon ou mauvais),

d’intégration)
 Les dossiers de programme
Le formalisme des dossiers de programme est
fonction des technologies utilisées et des
normes et standards de programmation en
vigueur sur un site de développement.
À titre d'exemple, il est possible, de structurer
des modèles types pour :
 Les modules temps réel.
 modules temps différé.
 modules d'édition.
 Les modules communs (sous-programmes), etc.
d’intégration)
 Les dossiers de tests unitaires
 A la fin de la phase de préparation des tests
unitaires, on obtient un dossier de test
unitaire qui comprend :
 L'enchaînement chronologique des tests
(plan de test).
 La description détaillée de chaque cas de
test.
 Les données d'essais qui permettent de
valoriser chaque cas.
 La description des résultats attendus,
 Les paramètres à utiliser pour les essais
(dates, conditionnement...
d’intégration)
 Les dossiers de tests d'intégration
 Chaque dossier de test d'intégration
doit contenir au moins les informations
suivantes:
 Des plans de tests définissant et organisant
le séquencement des actions.
 La planification de ces actions.
 La liste des scénarios formalisés et leur
ordre de passage.
 Et pour chaque test
d’intégration)
les composants à tester

 l'environnement nominal nécessaire

 les moyens nécessaires
 les conditions d'activation du test
 les données de tests (jeux d'essais)
 les résultats attendus
 les critères d'arrêt du test
 les dispositions à suivre en cas d'échec du test; - les
mesures à effectuer
 Dans le cas de scénarios complexes les tests
seront modélisés au moyen de graphes, Des
diagrammes représentent les éléments
déclenchants, l'enchaînement opératoire et
les résultats
d’intégration)
 Le cahier de tests unitaires/d'intégration
À la différence du dossier de tests qui est
élaboré à l'avance pour décrire les essais à
faire, le cahier de tests unitaires et le cahier
de tests d'intégration sont les outils qui
accompagnent respectivement l’exécution
des essais.
Le cahier de tests est de même structure pour
les tests unitaires et d'intégration. Il
comprend
 Une main courante,
 Un recueil de fiches d'anomalies.
 Un enregistrement électronique des scénarios

d’intégration)
 La main courante
C'est la liste de tous les essais effectués. Elle

assure la traçabilité des essais et précise
aussi les résultats constatés pour les tests :
conforme/non-conforme. Dans ce document
on va retrouver les informations suivantes .
 La date du test.
 Le nom du recetteur.
 Le numéro de scénario et les numéros des
cas testés.
 Les résultats obtenus.
 L'indicateur de conformité (oui/non).
 Et dans le cas où le test est non-conforme : le
numéro de la fiche d'anomalie, les actions en
 La fiche d'anomalie
d’intégration)
Chaque fois qu'une non-conformité est détectée lors d'un essai,
une fiche d'anomalie est dressée afin d'en tracer les incidences
et les actions correctives que l'on va décider d'entreprendre.
Dans cette fiche on va retrouver les informations suivantes
 Une partie signalétique avec :
 le numéro et la date de la fiche
 le nom du recetteur
 le numéro du scénario ainsi que le cas de test concerné
 le statut de l'anomalie : bloquant ou non bloquant.
 Une partie question avec :
 la référence de l'écran ou la référence du document papier;
 la référence de la table ou du fichier concerné; - la description de
l'anomalie;
 des annexes éventuelles permettant de préciser le problème (copie
écran).
 Une partie réponse avec
 la date de la réponse
 le nom de l'auteur de la réponse
 la description de la solution préconisée
Etape 5 : La Recette
 Les processus
pourquoi faire une recette alors que le
fournisseur (la maîtrise d’œuvre) a déjà
réalisé des campagnes d'essais au niveau
unitaire et au niveau intégration? En fait les
essais réalisés jusque-là ont été des tests que
l'on peut qualifier de « techniques ». Il
importe maintenant de réceptionner tous les
livrables du projet (logiciel, documentation et
prestations associées). Pour cela il va falloir
procéder à des tests « métiers » réalisés par
les utilisateurs du futur système afin de
vérifier que les exigences formulées par le
client (la maîtrise d'ouvrage) sont bien satis
La recette va se dérouler en deux phases.
Tout d'abord une phase de recevabilité
pendant laquelle le client acquéreur des
produits logiciels et des prestations
associées va vérifier que tous les
composants commandés et figurant sur
le contrat, ont bien été livrés. En fait,
dans cette phase on se contente de
pointer le bordereau de livraison afin de
vérifier sa complétude. Puis une phase
de qualification pendant laquelle le
client utilisateur va vérifier que tous les
composants livrés fonctionnent
correctement et répondent aux
RECEVABILITE
QUALIFICATION
 La recevabilité
C'est la phase pendant laquelle le client (ou ses
représentants) vérifie la livraison qui vient de lui être
faite, Sachant que la livraison peut être effectuée une
seule fois en totalité ou partiellement en plusieurs fois
conformément aux conditions prévues au contrat.
 Lors de la recevabilité le client se limite à vérifier par des
contrôles à caractère « visuels » :
 La date de la livraison réelle correspond à la date de
livraison prévue,
 La livraison est effectuée à l'endroit initialement prévu
(support, site...).
 La présence effective des composants commandés
(logiciel, documentation,tables).
 Le nombre exact de pièces livrées par composant
(nombre de modules).
 L'aspect extérieur des composants.
 Une liste des composants manquants est dressée , elle

 La qualification et les tests de validation
 C'est le troisième niveau de contrôle. Il correspond aux
«tests de validation» effectués sur la branche droite` du
« V » du processus de développement du logiciel et aux
traitement des « spécifications » situés sur la branche
gauche.
 Ces tests de dimension métier sont appelés par la norme
les tests de validation. Ils permettent de vérifier
l'adéquation du système intégré dans son
environnement définitif, par rapport aux exigences
formulées par les utilisateurs en matière fonctionnelle et
aux contraintes organisationnelles.
 Comme, les autres catégories de tests, les tests de
validation comportent deux parties : la préparation et
l'exécution, La préparation des essais a été établie
pendant la définition des besoins pour déterminer sur
quels critères le logiciel répond aux exigences du métier,
L'exécution des essais, vérification proprement dite, sera
confiée à une équipe de « recetteurs » composée par
 La préparation des tests
 Les jeux d'essai métier pour la validation sont conçus afin de satisfaire aux
exigences suivantes :
 Vérifier que le logiciel traite les fonctionnalités du dossier de définition des
besoins,
 Contrôler la validité des règles de gestion et de calcul.
 Tester tous les cas fonctionnels non passants (par exemple : message
d'anomalie).
 Vérifier l'impact des événements de gestion sur le reste des traitements.
 Tester les opérations quotidiennes effectuées par les utilisateurs.
 Tester les opérations exceptionnelles effectuées par les utilisateurs,
 Valider les nouvelles fonctions offertes par le système.
 Tester les interfaces avec les autres systèmes (par exemple : la comptabilité),
 Les tests de validation portent sur
 Une activité complète de gestion.
 Les processus fonctionnels.
 Les procédures organisationnelles.
 Le suivi du cheminement d'une information a l'intérieur du système.
 Les réactions du système logiciel à une sollicitation extérieure.
 Et chacun des outils utilisés dans l'exercice du métier des utilisateurs
 Les scénarios de tests de validation
permettent de vérifier la bonne couverture
(les travaux de gestion que les utilisateurs
doivent réaliser dans l'exercice de leur
métier). Les contrôles fonctionnels et des
formules de calcul de gestion doivent
produire des résultats exacts, vérifiables.
C'est aussi le moyen de contrôler que dans
des conditions normales, proches de
l'environnement réel, le système logiciel
réagira convenablement.
la formalisation des plans de tests dans le
dossier de tests de validation comprend :
 La description des scénarios (cas de tests
valorisés, règles de gestion, résultats,
attendus...).
 L'environnement des tests : matériel, fichiers,
 À partir des plans de tests élaborés lors du
processus de préparation, pour qualifier le
système logiciel, les utilisateurs en charge
des tests vont, dans l'ordre chronologique
 Dérouler les scénarios (appelés en anglais : scripts).
 Vérifier que les résultats obtenus sont conformes
 Relever dans une fiche d'anomalie tous les écarts
constatés.
 Tenir à jour une main courante des essais effectués.
 Les données d'essai, les scénarios de test et les
résultats obtenus seront conservés afin de pouvoir
servir de référence ultérieure.
 Lorsque l'ensemble des tests de validation prévus a
été déroulé et a donné les résultats escomptés (il
Cet accord est consigné dans un document
procès verbal de recette signé
respectivement par les parties contractantes.
Par ce document le client (maîtrise d'ouvrage)
reconnaît prendre livraison officiellement des
livrables logiciels et prestations associées
objet du contrat. Le fournisseur (maîtrise
d'oeuvre) est donc déchargé de la
responsabilité de la conception et de la
réalisation du système logiciel. C'est la
concrétisation du transfert de responsabilité
et de propriété avec les conséquences
financières en matière de paiement des
sommes restant dues et c'est souvent le fait
 Les livrables
 Bordereau de Livraison – Fiche de
recevabilité
C’est l’inventaire précis et détaillé des
composants
(logiciels,documentation,prestations) que le
fournisseur à livré au client.
 Les dossiers de tests de
validation
Chaque dossier de test de validation doit contenir au moins
les informations suivantes :
Des plans de tests définissant et organisant le
séquencement des actions.
 La planification de ces actions.
 La liste des scénarios métier formalisés et leur ordre de

passage.
Et pour chaque test :
 les fonctions à tester
 l'environnement nominal nécessaire
 les moyens nécessaires
 les conditions d'activation du test
 les jeux d'essais
 les résultats attendus
 les critères d'arrêt du test
 les dispositions à suivre en cas d'échec du test

 Le cahier de recette de validation
(métier)
Comme pour les tests d'intégration, le cahier de
recette de validation est l'outil qui
accompagne l'exécution des essais métiers.
Les structures de documents sont identiques
aux autres cahiers de tests et de recette.
Seule la maille et la portée des tests sont
différentes dans le niveau de précision du
contenu.
 Le cahier de recette va être formalisé au
moyen
 D'une main courante

 Le procès verbal de recette
 C’est le document officiel par
lequel la maîtrise d’ouvrage (le

client) , entérine que les
composants
(Logiciels,documentation,presta
tions) livrés par la maîtrise
d’œuvre (le fournisseur) sont
accepté .
Etape 6 : L’installation / la
diffusion(déploiement)
 Les processus
 Concevoir et réaliser un produit logiciel
représente une partie importante des
activités d'ingénierie. Toutefois, lorsque le
nombre de sites à installer est important, il ne
faut pas négliger de maîtriser l'installation
puis la diffusion d'un produit logiciel. La mise
sous assurance qualité de ces activités doit
alors s'exercer dans le temps et dans
l'espace. Les impacts ne seront pas de la
même nature pour gérer cinq, dix ou cent
sites ou plus. Par ailleurs, les activités
d'installation et de diffusion concernent non
seulement la première mise en place du
système logiciel, mais elles devront être
intégralement reprises et supportées dans le
 L'installation
 Tout d'abord une installation ne peut intervenir
que sur un produit logiciel qui a fait l'objet d'une
recette satisfaisante, c'est-à-dire pour lequel il
ne reste plus aucune anomalie bloquante pour
les utilisateurs. Sinon la mise en production doit
être systématiquement refusée.
 Ensuite, l'identification des éléments composant
la configuration (logiciels,
données, procédures, documentation) sera
réalisée. Pour les tâches d'identification des
composants on se reportera a La gestion de
configuration.
Toutes les opérations d'une installation doivent
être effectuées sans risque d’erreurs. Une
installation comporte des travaux entièrement
 Une planification de l'installation doit être
rédigée. Elle identifie de manière détaillée les
travaux à faire, en précisant l'ordre
d'enchaînement des tâches et les affectations
de responsabilités. Un mode doit expliquer les
actions à entreprendre en cas d'anomalies. Le
plan d'installation du système doit être
élaboré en collaboration entre les équipes de
développement et d’exploitation .
 Il doit être compatible avec l'environnement
cible, conformément aux exigences prévues
au contrat. Les ressources nécessaires pour
l'installer doivent être identifiées et
disponibles.
 La procédure peut être diversifiée, avec par
L'équipe de développement assistera
l'équipe d'exploitation pour la mise en
place du système. I’installation doit être
conforme au plan d'installation. Le
déroulement et les résultats de
l'installation doivent être documentés.
La traçabilité doit être assurée ainsi que
l’enregistrement des références de la
version installée
 La de tâche de l'installation sera
obligatoirement une tâche de
vérification comme une revue
 La diffusion
L'organisation de la diffusion à mettre, en

place est conditionnée par la dispersion
des sites cibles sur lesquels il est prévu
d'exploiter le système logiciel.
 Dans le cas d'un nombre restreint de
sites d'installation, la diffusion va se
limiter à une duplication de la
procédure d'installation sur chacun des
sites. La principale difficulté réside alors
à gérer les montées de version pour
chaque site et à garantir I’intégrité de
l'ensemble des systèmes lorsque, à un
 Pour réussir ce type de diffusion il importera
de définir les relations avec les partenaires.
 Par exemple pour un projet de dimension
nationale ou internationale, plusieurs sites
cibles peuvent être concernés. Il importe de
préciser les engagements et les
responsabilités de chacun.
 Par contre, dans le cas d'un produit logiciel
mis sur le marché et destiné, à une large
commercialisation, le fournisseur va devoir
faire le choix du canal de distribution (un ou
plusieurs) comme pour n'importe quel produit
manufacturé. Alors, la diffusion sous-entend
le recours à un tiers entre le fabriquant et le
client utilisateur. Si le nombre de licences
d'utilisation est important ou bien si le
le fabricant a besoin d'un représentant local qui
joue le rôle d'intermédiaire. Ce maillon
supplémentaire dans la chaîne de distribution
implique des moyens qualité adéquats qu'il
importe de concevoir, de développer, de
mettre, en place, de suivre et de faire vivre.
La maîtrise des tâches de diffusion nécessite la
mise au point et le contrôle :
 D'une procédure d'échange aller vers les
distributeurs,
 D'une procédure d'échange retour depuis le
distributeur;
 Du traitement des anomalies.
 De la définition de l'assistance à apporter au
diffuseur.
 De la documentation.

 L’Exploitation
 Une fois que le système/logiciel est
installé correctement dans
l'environnement de production d'un
site, les équipes d'exploitation vont
prendre le relais des équipes de
développement.
 A partir de ce moment le
système/logiciel va être exploité en
utilisant des données réelles, il est mis
a la disposition des utilisateurs dans le
cadre de l’exercice de leurs métiers. La
montée en puissance peut se faire
 Les livrables
 Dossier d’installation
Il regroupe toutes les
informations nécessaire a
l’installation du logiciel, La liste
des tâches ainsi que l’ordre
d’exécution , les ressources …
Etape 7 : La Maintenance
 Les processus
 L’objectif de cette septième étape est de

conserver le système/logiciel dans un état tel
qu'il pourra continuer d'être exploité,
longtemps après son installation. En fajt avec
le temps, des événements surgissent qui
viennent perturber plus ou moins gravement
l'exploitation. Ces événements, sont
générateurs de modifications. Il est possible
de, les classer en deux catégories :
 Les anomalies de fonctionnement.
 Les évolutions fonctionnelles ou techniques
 La gestion des anomalies
 Tout d'abord une anomalie est la
manifestation d'une non-conformité du
logiciel à ses spécifications ou à ses
manuels d'utilisation et d'exploitation.
C'est un incident dans le
fonctionnement du logiciel qui a été
détecté. Une anomalie va engendrer
deux types de maintenance :
 Maintenance corrective.
 Maintenance évolutive (impact sur la
conception).
 La maintenance corrective consiste en
une stricte mise en conformité du
logiciel ou de sa documentation par
rapport aux spécifications annoncées et
validées. Suivant le degrés d'urgence il
faudra mettre place une correction à
chaud afin de débloquer une situation
urgente. Par contre, si la criticité le
permet, il sera souhaitable de bien
étudier tous les impacts avant
d'entreprendre une correction «à froid
».
En revanche, il arrive que les anomalies
détectées fassent apparaître un impact sur la
conception du système. Un cas fonctionnel
n'est pas supporté parce qu'il a été oublié ou
analysé incomplètement. Il importe alors de
commencer par la mise à niveau de la
conception générale puis de la conception
détaillée. Ensuite, interviendra la mise en
conformité du logiciel et de sa
documentation. Enfin, il ne faudra pas oublier
d'ajouter les cas de tests correspondants
dans les jeux d'essais et plans de tests avant
d'effectuer les tests de recette. Si nécessaire,
le dossier d'exploitation devait, lui aussi, être
La gestion des évolutions
Une demande d'évolution du système/logiciel
représente un changement des spécifications
pour ajouter, supprimer ou modifier des
fonctionnalités. Une évolution va engendrer
deux typologies de maintenance
 Maintenance adaptative.
 Maintenance préventive.
Le logiciel et sa documentation, tout en étant
conformes, doivent prendre en compte les
évolutions de l'environnement. Ces évolutions
seront souhaitées et négociées par les
utilisateurs ou les décideurs de l'entreprise. Il
arrive souvent qu'elles soient aussi imposées
à l'entreprise par des contraintes extérieures
qui résulteront, par exemple, d'impératifs
légaux ou réglementaires, voire de
 La gestion des modifications
Pour maintenir dans le temps la cohérence
entre les programmes et leur documentation
il est nécessaire de mettre en place un
système rigoureux de gestion des
modifications.
 On distingue les étapes suivantes :
 Établissement d'un constat d'anomalie ou d'une
demande d'évolution.
 Analyse et évaluation.
 Ordre de modification.
 Prise de décision de faire la modification
 Réalisation et suivi de la modification
 L'établissement d'un constat d'anomalie ou d'une
demande d'évolution
En présence d'un constat d'anomalie la demande doit être
formalisée et stipuler au moins :
 Le nom du demandeur.
 La date.
 La description complète des conditions et des résultats
de non-conformités.
 En présence d'une demande d'évolution la demande doit
être formalisée et stipuler au moins :
 Le demandeur (client, utilisateur, personnel de
développement ou test).
 La date
 Le but de la modification.
 Le délai d'obtention souhaité.
 La description complète du besoin et de la modification
demandée.
 L'évaluation des bénéfices estimés résultant de
 L'analyse et l'évaluation
 Il s'agit de déterminer les actions à effectuer
pour éliminer les défauts ayant entraîné
l'anomalie décrite ou répondre à la demande
d'évolution. Les travaux consistent a :
 Rechercher le document le plus en amont
touché par le constat d'anomalie ou par la
demande d'évolution.
 Lister tous les éléments (documents et
programmes) touchés par la modification et
déterminer les phases du développement
concernées.
 Définir les actions à engager en présentant
Processus Horizontaux
La Gestion Documentaire
 La maîtrise de la documentation
 La gestion documentaire passe par la
maîtrise des documents qui est la
capacité à concevoir, rédiger, diffuser
et retirer de la circulation si nécessaire,
les documents adaptés à l'usage pour
lequel ils sont prévus. Cette maîtrise
doit couvrir toutes les étapes de
l'ingénierie du logiciel : les
spécifications, la conception, le
développement, l'installation et
l'exploitation. Sans oublier tous les
Il faut y ajouter
Tous les documents d'organisation, tels que
procédure, contrat, planning, plan de
développement, plan de configuration, fiches
techniques...
Tous les documents de type exploitation (guide
d'installation, d'utilisation).
Nous nous référerons aussi a la norme ISO 9001
(et la version 2000). Ce paragraphe contient
les exigences pour la maîtrise de tous les
documents inclus dans un système qualité.
 États d'un document
A l’exception des courriers et des comptes-
rendus de réunion, tout document passe par
les étapes d'un cycle de vie. En effet il est
successivement identifié, rédigé, puis validé
et enfin diffusé.
Afin de suivre correctement les évolutions d’un
document et d'assurer la cohérence de leur
niveau de fraîcheur des informations, il est
impératif de connaître l'état de sa
version/révision. Ainsi tout document va
connaître trois états comme suit
Provisoire : le document est en cours
d'élaboration (version 0.0).
À valider : le document est complet, il est en
cours de validation (Version 0.1).
Validé/approuvé : le document est conforme,
 Le cycle de vie d'un document
La gestion documentaire consiste à assurer la
prise en compte de tous les événements qui
interviennent sur un document tout au long
de son cycle de vie. Un document, quelque
soit son type, passe par les étapes suivantes-:
Naissance (ou création).
Jeunesse pour son développement (ou
rédaction).
Adolescence (ou validation/approbation).
Âge mûr et adulte pendant lequel il est actif
Retraite (archivage pour conservation)
Mort (destruction).
 Il y a deux types de documents
 Ceux soumis à la gestion des versions
(versionning,traçabilité).
 Ceux non soumis à la gestion des versions
(non versionning).
Pour les premiers types de documents, soumis
au versionning le cycle de vie va décrire les
différents processus suivants
 La création d'un document.
 La rédaction d'un document.
 La validation d'un document.
 L'approbation d'un document.
 La diffusion d'un document.
 La modification d'un document.
 La validation et la diffusion d'un document
modifié.
 La conservation un document.
 Le retrait d'un document.
Pour les seconds types de dossiers, non

soumis au versionning, elle va décrire
les différents processus suivants
 La création d'un document.
 La rédaction d'un document.
 La diffusion d'un document.
 La conservation d'un document

 Le circuit de validation/approbation
Lorsque la rédaction d'un document soumis à
validation est achevée, le document est prêt
à entrer dans le circuit de validation. Chacun
des valideurs sélectionnés à l'avance,
mentionnés sur la page bordereau de
validation, devra relire le document, exprimer
ses remarques sur le fond et sur la forme du
document, puis formaliser l'expression de ses
remarques, et enfin donner son accord
(validation ou approbation suivant le cas.
pour la mise en diffusion du document.
 Pour la validation/approbation on peut faire
appel aux techniques du groupware, c'est-à-
dire en utilisant une diffusion électronique
des documents.
La Charte Graphique
La charte graphique est le document qui va consigner
toutes les informations
décrivant les règles et formats de documents qui ont été
choisis et approuvés pour l'entreprise. On va notamment
y trouver précisés:
La forme, la taille, la couleur le dessin du logo de
l'entreprise.
La représentation du sigle de l'entreprise.
Le contenu et la forme des bas de page standards.
La présentation officielle du papier entête
La présentation officielle des factures.
La présentation Powerpoint utilisée
La police de caractères couramment utilisée, sa taille et sa
couleur.
Les caractéristiques des feuilles de styles utilisées en
bureautique.
Le graphisme, les couleurs des documents sortant de
l'entreprise.
LA Gestion de Configuration
 La problématique
Les activités de gestion de configuration permettent de
connaître, à tout moment, toutes les informations
concernant un système d'information installé sur un site.
Par exemple
Les programmes d'application avec leur version.
Les matériels installés (y compris les périphériques et les
cartes).
Les outils de conception et de développement utilisés.
Les logiciels de test utilisés.
Les logiciels d'exploitation et logiciels de base avec leur
version.
Les interfaces.
Les logiciels associés.
La documentation technique.
La documentation et les guides d'utilisa ion.
Les dernières corrections réalisées...
La Gestion de Configuration
 Les éléments composant la configuration
 Par définition (ISO/('EI 12207 : 1995), un
«élément de configuration est une entité au
sein d'une configuration satisfaisant une
fonction; pour un utilisateur et pouvant être
identifiée de façon unique à un instant
spécifique du cycle de vie. » Chaque élément
doit posséder un identifiant unique, attribué
le plus tôt possible, permettant de le
référencer de façon non ambiguë.
 Dans le cas fréquent de progiciels achetés, il
faut parfois recourir à une double
identification des éléments. C'est-à-dire qu'il
faut gérer l'identification prévue par le
fournisseur, et, en parallèle, l'identification
 Les éléments de configuration d'un logiciel
vont comprendre
Les documents de conception.
Les documents de réalisation.
Les documents d'utilisation.
Les documents d'exploitation.
Les composants programmes.
Les données des tables et paramètres.
Les procédures (installation, exécution...)
L'environnement de développement.
L'environnement de recette.
Les jeux d'essais (données, procédures,
scénarios et cas de tests)...
La gestion de configuration comporte quatre

activités principales
 Identifier.
 Contrôler.
 Administrer.
 Auditer
Identifier c'est désigner tous les
composants qui appartiennent à une
configuration. Ensuite, c'est leur
attribuer un identifiant afin de les
reconnaître pour les gérer. Enfin, il
faudra enregistrer les caractéristiques
de chacun de ces composants pour en
retrouver aisément les informations.
Contrôler une configuration c'est

s'assurer de la maîtrise de ses
évolutions. Ainsi, on vérifiera que les
modifications demandées sont
souhaitables, puis qu'elles sont
effectuées correctement et que leur
impact n'affecte pas l'intégrité du
système d'information
Administrer une configuration consiste

à historiser toutes les informations
intervenues sur l'état passé de cette
configuration. Cette mémoire est
obtenue par la capture des informations
sur l'état courant qui s'écoule dans le
temps. Ainsi, c'est une véritable trace
des changements qui est obtenue sur la
vie complète du système d'information,
passé, présent et futur.
Auditer une configuration c'est vérifier

tout d'abord l'état dans lequel se trouve
le système d'information et si son
intégrité est bien garantie. Puis la
vérification portera sur l'exactitude des
informations acquises et sur leur état
de conservation

Cycle de Vie Des Logiciels

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cycle de Vie Des Logiciels

Uploaded by

Copyright:

Available Formats

Cycle de vie des

1ere Rencontre Création

Choix d’un cycle Recueil

0 Préliminaires - Cahier des charges Revue de contrat

1 Planification - Note de lancement Revue de planification

3 Conception générale - Dossier de conception générale Revue de conception générale

4 Conception détaillée - Dossier de conception détaillée Revue de conception détaillée

5 Codage - Listings de programme Revue de code

6 Tests unitaires - Cahier de tests unitaires Revue de tests unitaires

7 Intégration - Cahier de tests d'intégration Revue d'intégration

8 Recette - Cahier de tests de validation Revue de recette

9 Installation/diffusion - Cahier de l'installation Revue d'installation

Exploitation - Dossier de maintenance

C'est à cet endroit qu'il importe de préciser les rôles

Recueil des besoins

Liste des contraintes

Fonction 5 Fonction 6 Fonction 7

Toutefois la représentation graphique

Lot n° 1 Lot n° 2 Lot n° n

Éléments d'exploitation , d'utilisation

Évaluation étape suivante

 Quels sont les traitements (par exemple : lecture,

 Quels sont les algorithmes à utiliser?

 Quelles sont les données a Manipuler

Si plusieurs concepteurs travaillent en parallèle, il sera

Diagramme de type MOT par UT

Description transaction Description batch Description Client-SRV Description

Dossier d’exploitation et d’utilisation

Évaluation étape suivante

 la description de l'environnement du projet.

 Le processus de conception générale proprement

 Les processus fonctionnels

Il y a trois catégories de processus

 Temps réel (ou TP).

 Préparation des essais (tests

 Les outils de modélisation

Le dossier de conception détaillé

 La description de l'environnement du projet.

 Le processus de conception détaillée

proprement dit, avec

 le dossier de tests unitaires qui servira pour les

essais de tests unitaires

 un contrôle de cohérence sera réalisé sur

 La structure des données et leurs agrégations.

 Les interfaces qui réalisent les liaisons entre les sous-

 La formulation exacte des algorithmes de calcul.

 La désignation de tous les outils utilisés : matériels,

 Les traitements (par exemple : lecture, calcul, mise à

 Les algorithmes (règles de calcul) à utiliser.

 Les données à manipuler.

 Les formes et structures des interfaces.

 Les règles de conversion des données

Préparation des essais (tests unitaires)

concepteurs identifieront le plan de

Évaluation précise de la réalisation -

 Le codage des programmes.

 Les tests unitaires programmes par

 Et les tests d'intégration du système/logiciel

Inclure les commentaires

Compléter les dossiers de tests unitaires

Revoir les dossiers d’exploitation et intégration

Faire la revue de code

Vers tests unitaires

Tests unitaires non