[Important] Cycle de vie des logiciels.ppt

Démarche Projet Classique
Demande Client
1ere Rencontre
Pour définir le besoin
Création
équipe projet
GO client
Cahier des charges
Choix d’un cycle
de développement
Étude coût & Délais
Devis et Planning
Recueil
existant
Analyse
Fonctionnelle
Analyse
F. OK
Retouche sur demande client
Cycle de Développement Déploiement Recette
Spécifications détaillé
Plan test
Plan déploiement
Plan qualité
Etape0 Etape1
Etape3
Etape4
Post Mortem
maintenance
Etape5
Etape6 Etape7
Etape2
Cahier des charges

Cycle en V
Analyse du
besoin
Spécification
système
Conception
préliminaire
Conception
détaillée
Réalisation
Validation
système
Validation Sous-
systèmes
Spécification sous-
systèmes
Qualification
opérationnelle
Test
d’intégration
Test sous-
systèmes
Exploitation et
maintenance

Étapes du cycle de vie Principaux documents Contrôles qualité
0 Préliminaires - Cahier des charges
- Appel d'offres
- Contrat
Revue de contrat
1 Planification - Note de lancement
-. Plan d'assurance qualité
- Plan de développement
Revue de planification
2 Spécifications - Dossier de définition des besoins/ Cahier des charges
- Spécifications d'interface
- Dossier tests de validation
Revue de spécifications
3 Conception générale - Dossier de conception générale
- Dossier tests d'intégration
Revue de conception générale
4 Conception détaillée - Dossier de conception détaillée
- Dossier tests unitaires
Revue de conception détaillée
5 Codage - Listings de programme
- Documentation programme
Revue de code
6 Tests unitaires - Cahier de tests unitaires
- Bilan des tests unitaires
Revue de tests unitaires
7 Intégration - Cahier de tests d'intégration
- Bilan de l'intégration
- Dossier d'installation
- Dossier d'exploitation
Revue d'intégration
8 Recette - Cahier de tests de validation
- Bilan de la recette
Revue de recette
9 Installation/diffusion - Cahier de l'installation Revue d'installation
Exploitation
Maintenance (hors projet)
- Dossier de maintenance

Etapes 0 : Les Processus Préliminaires
L'objectif de cette étape préliminaire est de permettre la définition et
la mise en place des processus de la relation client/fournisseur. Non
seulement les bases de la collaboration doivent être établies avec
précision dès le départ, mais aussi les 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

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

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 sûr les limites du périmètre de
confidentialité des informations contenues

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 suivants :

Phase1
Définition des objectifs
Recueil des besoins
Liste des contraintes
Phase2
Spécifications du système
Formalisation du Dossier
Validation spécifications

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).
L'élaboration d'une/des solution(s) possible(s) pour atteindre la cible
(transformation).
La justification des choix retenus

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

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 synthétique de
l'architecture générale.

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 des besoins,
sont satisfaites.

Exemple de modèle de communication
Acteur1
Acteur3
Acteur2
flux1
flux2
flux3

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.
Conception du logiciel (conception détaillée).

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
Découpage en lots
Architecture fonctionnelle
Lot n° 1 Lot n° 2 Lot n° n
Conception du lot
Procédures dégradées
Éléments de tests
Élémentsd'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 sont levées, en particulier à propos de :

 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.
 Le respect des niveaux de confidentialité et de sécurité.

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 homogènes composés de données
et de traitements qui réagissent entre eux.

 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 cohérence afin de garantir la
stabilité du système/logiciel complet

Diagramme de type MOT par UT
Decoupage en UT
Description transaction Description
Navigation
Algo de calcul
Recette technique
Dossier d’exploitation et d’utilisation
Évaluation étape suivante
Validation
• Logigramme de
conception Détaillées
Graphe générale
Architecture Technique
Description batch Description Client-SRV
Description Objets

 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
- la description des interfaces
- tous les graphes communs a tous les lots (ex:MCD)

 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 lesquelles il est rarement possible d'agir.

 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 contrôles fins. Une analyse
précise et une planification soignée des tâches à faire est
une condition de réussite.

 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
place.

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, faire une
réévaluation de la planification (plan de développement et
éventuellement plan qualité).

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 exécutables, chargés et exécutés sur le
poste de travail, et des données

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 mode d'emploi)
et de formation (supports de cours et exercices
pratiques).

É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 garder la maîtrise du projet.

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

 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)

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 comme un
«ensemblier» qui assemble des modules préfabriqués et déjà
testés unitairement. Il en résulte un important gain de
productivité.

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 standards et le bon usage
qui en est fait.

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

 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

Tests unitaires
Modèle validé
non
oui
Dossier
des tests
unitaires
Cahier
De recette
unitaire

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).
Exemples
Le format de la date est invalide.
La rubrique est obligatoire.
La date est au-delà des valeurs limites (date saisie < date du jour).

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 été effectués,
valide la fiabilité des résultats obtenus et contrôle que les
données d'essai sont bien archivées.

 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 du logiciel.

Tests
d’integration
Modèle validé
non
oui
Dossier
des tests
D’intégration
Cahier
De recette
D’intégration
Sous-système
validé

 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 chaîne/du système.

- 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

 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

 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 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.
Les tests d'intégration sont sous la responsabilité du chef
de projet. Il va assembler les différents programmes ou
briques logicielles en chaînes de traitement. Puis, d'une manière
analogue, il assemble les chaînes en système d'information.
Leur exécution peut être déléguée.

 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),

 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.

 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...

 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
 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

 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 (si utilisation
d'outil de tests automatiques)

 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 cours

 La fiche d'anomalie
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
 la date à laquelle la correction a été faite.

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 satisfaites avec le niveau de qualité
requis.

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 spécifications
fonctionnelles et techniques

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 mentionne les
réserves constatées, Cette liste est signée par les parties contractantes, Si
aucune anomalie de livraison n'est constatée, le bordereau de livraison du
fournisseur peut être signé pour marquer l'accord du client.

 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 des utilisateurs du futur système logiciel.

 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, tables...
 L'organisation de l'enchaînement (les tests : dates,
paramètres.
 La planification et exécution des tests.

 À 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 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
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 ne reste plus aucune fiche d'anomalie Ouverte
Ou sans réponse), la recette du système logiciel peut alors être
prononcée par la maîtrise d’ouvrage

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 générateur
du départ de la période de garantie

 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
 les mesures à effectuer.
Dans le cas de scénarios complexes les tests sont 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.

 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
 D'un recueil de fiches d'anomalies,et si possible d'un enregistrement
électronique des scénarios testés (tests automatiques).

 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,prestations)
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
processus de maintenance

 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 automatiques et des travaux manuels .

 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 exemple
 La procédure d'installation automatique.
 La procédure d'installation manuelle.
 Le mode d'emploi.

 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
d'acceptation qui permet de valider les travaux
réalisés.

 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 instant donné, tous les sites ne sont
pas au même niveau de version

 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
fabriquant est situé à l’étrangers

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.
 De la formation.
 De la mise en place d'une hot line.

 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 progressivement , par exemple une
agence après l'autre, une usine après l'autre, une
société après l'autre .

 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 mis en conformité,. La correction de
ces anomalies passe par des évolutions.

 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 contingences
commerciales dictées parles lois de la concurrence.

 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'amélioration.

 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 éventuellement
les différentes solutions envisageables.

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 documents
relatifs au système qualité.

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, il est diffusé
pour action (Version 1.0).

 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.
Tout ce qui peut contribuer à uniformiser les supports servant de
communication entre l'entreprise et le monde extérieur et qui peuvent
avoir une action sur l'image de marque de la société.

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...
Cela implique d'identifier et de répertorier toutes les informations qui
apparaissent tout au long de la vie du logiciel, depuis sa conception, son
développement et sa maintenance en exploitation..

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 propre à l'entreprise et qui
permette de suivre les évolutions du produit livré.

 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

[Important] Cycle de vie des logiciels.ppt

Recommandé

Recommandé

Contenu connexe

Similaire à [Important] Cycle de vie des logiciels.ppt

Similaire à [Important] Cycle de vie des logiciels.ppt (20)

[Important] Cycle de vie des logiciels.ppt