Cycle de vie des logiciels

Cycle de vie des logiciels

---

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


Etape6
Etape7

---

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


Réalisation

---

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

---

Etapes 0 : Les Processus
Prél
L'obje ictm
if i
denai
cetteres
é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

---

Etapes 0 : Les Processus
Prél
Cette i
é m
tap i
e nai
est c r
a es
pitale 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

---

Etapes 0 : Les Processus
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.

---

ÉTAPE 1:INITIALISATION
D'UN PROJET -LA PLANIFICATION
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

---

ÉTAPE 1:INITIALISATION
D'UN PROJET -LA PLANIFICATION
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.

---

ÉTAPE 1:INITIALISATION
D'UN PROJET -LA PLANIFICATION
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 :

---

ETAPE2 : LES SPECIFICATIONS
Phase1
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).
L'élaboration d'une/des solution(s) possible(s) pour atteindre la cible
(trans-formation).
La justification des choix retenus

---

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

---

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

---

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

---

ETAPE3 : LA CONCEPTION
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.

---

ETAPE3 : LA CONCEPTION
 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 questions-réponses

---

ETAPE3 : LA CONCEPTION
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

---

ETAPE3 : LA CONCEPTION

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

---

ETAPE3 : LA CONCEPTION
 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 :

---

ETAPE3 : LA CONCEPTION
 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é.

---

ETAPE3 : LA CONCEPTION
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.

---

ETAPE3 : LA CONCEPTION
 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

---

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

---

ETAPE3 : LA CONCEPTION
 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)

---

ETAPE3 : LA CONCEPTION
 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

---

ETAPE3 : LA CONCEPTION
 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é).

---

ETAPE3 : LA CONCEPTION
 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.

---

ETAPE3 : LA CONCEPTION
Il y a trois catégories de processus
 Temps réel (ou TP).
 Temps différé (ou batch).
 De service

---

ETAPE3 : LA CONCEPTION
 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.

---

ETAPE3 : LA CONCEPTION
 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.

---

ETAPE3 : LA CONCEPTION
 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.

---

ETAPE3 : LA CONCEPTION
 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).

---

ETAPE3 : LA CONCEPTION
 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 »)

---

ETAPE3 : LA CONCEPTION
 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).

---

ETAPE3 : LA CONCEPTION
 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é.

---

ETAPE3 : LA CONCEPTION
 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.

---

ETAPE3 : LA CONCEPTION
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.

---

ETAPE3 : LA CONCEPTION
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é).

---

ETAPE3 : LA CONCEPTION
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.

---

ETAPE3 : LA CONCEPTION
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

---

ETAPE3 : LA CONCEPTION
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

---

ETAPE3 : LA CONCEPTION
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»

---

ETAPE3 : LA CONCEPTION
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).

---

ETAPE3 : LA CONCEPTION
É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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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)

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 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é.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 standards et le
bon usage qui en est fait.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests d’intégration)
Codage
Traduire la conception détail é 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests d’intégration)
Dossier
des tests
unitaires
Tests unitaires
non
Cahier
Modèle validé
De recette
unitaire
oui

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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).
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).

---

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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 du logiciel.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 chaîne/du système.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 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.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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),

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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...

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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.

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests d’intégration)
 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

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 (si
utilisation d'outil de tests automatiques)

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests 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 cours

---

ETAPE4 : LA REALISATION (codage,
tests unitaires, tests d’intégration)
 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 c
orrection 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 satis-faites avec
le niveau de qualité requis.

---

Etape 5 : La Recette
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

---

Etape 5 : La Recette
RECEVABILITE
QUALIFICATION

---

Etape 5 : La Recette

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 fourni

sseur peut être signé pour marquer l'accord du client.

---

Etape 5 : La Recette

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.

---

Etape 5 : La Recette

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 exceptionnel es 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 organisationnel es.

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

---

Etape 5 : La Recette
 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.

---

Etape 5 : La Recette
 À 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

---

Etape 5 : La Recette
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

---

Etape 5 : La Recette
 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.

---

Etape 5 : La Recette
 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 diagr
ammes représentent les éléments déclenchants,
l'enchaînement opératoire et les résultats.

---

Etape 5 : La Recette
 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).

---

Etape 5 : La Recette
 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

---

Etape 6 : L’installation / la
diffu
L' s
in ion
sta (d
llati ép
on loiement)
 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 .

---

Etape 6 : L’installation / la diffusion(déploiement)
 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.

---

Etape 6 : L’installation / la diffusion(déploiement)
 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.

---

Etape 6 : L’installation / la
diffus

ion(déploiement)
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

---

Etape 6 : L’installation / la
diffus
 Po io
ur r n
é (dé
ussir p
clo
e ie
ty m
pe en
de t)
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

---

Etape 6 : L’installation / la
d
leif
f fu
abrsion
ican (d
t a ép
besloiem
oin d e
'un n
r t)
epré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.

---

Etape 6 : L’installation / la diffusion(déploiement)
 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 .

---

Etape 6 : L’installation / la
diffusion(déploiement)
 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

---

Etape 7 : La Maintenance
 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).

---

Etape 7 : La Maintenance
 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 ».

---

Etape 7 : La Maintenance
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.

---

Etape 7 : La Maintenance
 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.

---

Etape 7 : La Maintenance
 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

---

Etape 7 : La Maintenance

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.

---

Etape 7 : La Maintenance
 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.

---

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

---

La Gestion Documentaire
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é.

---

La Gestion Documentaire
 É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).

---

La Gestion Documentaire
 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).

---

La Gestion Documentaire
 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).

---

La Gestion Documentaire
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.

---

La Gestion Documentaire
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

---

La Gestion Documentaire
 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é.

---

La Gestion de Configuration
 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
La gestion de configuration comporte quatre
activités principales
 Identifier.
 Contrôler.
 Administrer.
 Auditer

---

La Gestion de Configuration
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.

---

La Gestion de Configuration
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

---

La Gestion de Configuration
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.

---

La Gestion de Configuration
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

---