Cycle De Vie Des Logiciels

Cycle de vie des logiciels

Démarche Projet Classique Etape0

Etape1

Demande Client

1ere Rencontre Pour définir le besoin

Création équipe projet

Cahier des charges Cahier des charges Choix d’un cycle de développement

Etape2

Devis et Planning

Étude coût & Délais

GO client

Plan qualité

Retouche sur demande client

Recueil existant Analyse Fonctionnelle Etape3

Etape5 Analyse F. OK

Cycle de Développement Spécifications détaillé Plan test Plan déploiement

Etape4

Déploiement

maintenance Etape6

Recette

Post Mortem Etape7

Cycle en V Exploitation et maintenance

Analyse du besoin

Qualification opérationnel le Validation système

Spécificatio n système

Validation Soussystèmes

Spécification sous-systèmes

Conceptio n préliminair e

Test d’intégratio n

Conception détaillée

Test soussystèmes

Réalisatio

Étapes du cycle de vie

Principaux documents

Contrôles qualité

0 Préliminaires

- Cahier des charges

Revue de contrat

- Appel d'offres - Contrat

1 Planification

- Note de lancement

Revue de planification

-. Plan d'assurance qualité - Plan de développement

2 Spécifications

- Dossier de définition des besoins/ Cahier des charges

Revue de spécifications

- Spécifications d'interface - Dossier tests de validation

3 Conception générale

- Dossier de conception générale

Revue de conception générale

- Dossier tests d'intégration

4 Conception détaillée

- Dossier de conception détaillée

Revue de conception détaillée

- Dossier tests unitaires

5 Codage

- Listings de programme

Revue de code

- Documentation programme

6 Tests unitaires

- Cahier de tests unitaires

Revue de tests unitaires

- Bilan des tests unitaires

7 Intégration

- Cahier de tests d'intégration

Revue d'intégration

- Bilan de l'intégration - Dossier d'installation - Dossier d'exploitation

8 Recette

- Cahier de tests de validation

Revue de recette

- Bilan de la recette

9 Installation/diffusion

- Cahier de l'installation

Exploitation Maintenance (hors projet)

- Dossier de maintenance

Revue d'installation

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.

Etapes 0 : Les Processus Préliminaires

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 Cette étape est capitale pour le bon Préliminaires

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

É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

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

ETAPE2 : LES Les livrables SPECIFICATIONS Le dossier de définition des besoins (qui dans certains

cas fait office de cahier des charges) Le dossier de définition .des besoins est le document par lequel le chef de projet (et son équipe) formalisent avec un maximum de précision les exigences et spécifications exprimées par les utilisateurs. Ce support représente le consensus sur lequel l'accord de tous a été obtenu sur les fonctions supportées par le nouveau système logiciel et ses livrables. Le dossier de définition des besoins doit être rédigé en commun avec les utilisateurs, les organisateurs et les informaticiens. Il est écrit en langage compréhensible par les utilisateurs non informaticiens. Le recueil des besoins s'opère en suivant une démarche intellectuelle itérative entre : L'observation de l'état actuel de l'organisation (analyse de l'existant). La projection des spécifications pour répondre aux exigences (système cible).

ETAPE2 : LES SPECIFICATIONS On se souviendra qu'il existe une difficulté majeure dans l'expression des besoins. Il y a les besoins explicites relativement facilement saisissables car ils sont exprimés. Par contre les besoins implicites, invisibles par définition, sont souvent les plus importants, lourds de conséquences et les plus complexes à appréhender. Il est aussi nécessaire d'identifier puis de lister les contraintes. Les contraintes peuvent être d'ordre fonctionnel ou d'ordre technique

ETAPE2 : LES SPECIFICATIONS Les spécifications du futur système comprendront une architecture générale du fonctionnement du système projeté avec les liaisons entre les fonctions. Chaque fonction et sous-fonction sera décrite. Une description de fonction comporte : les entrées, les sorties, les principaux traitements, les règles de gestion et les blocs de données manipulées. Pour illustrer le fonctionnement du futur système l'équipe de projet aura recours à des représentations graphiques. Le modèle conceptuel de communication peux donner une vue rapide des échanges. Le diagramme fonctionnel donne une image

ETAPE2 : LES SPECIFICATIONS En parallèle à l'étude des principales fonctions, l'équipe de projet s'attachera à recueillir des éléments en vue de la recette utilisateur . la recette qui s'appuie sur le dossier de tests de validation. Pour chaque fonction retenue on identifiera les critères d'acceptation correspondants. Ces critères permettront d'apprécier pendant les tests métier (qualification), si les exigences des utilisateurs, exprimées dans le dossier de définition

ETAPE2 : LES SPECIFICATIONS Exemple de modèle de communication flux2 Acteur1

Acteur3

flux3

flux1 Acteur2

ETAPE2 : LES SPECIFICATIONS Exemple de diagramme fonctionnel Fonction 1 Fonction 2 Fonction 4

Fonction 5

Fonction 6

Fonction 3

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.

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

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

Lot n° n

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

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.

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

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 

ETAPE3 : LA CONCEPTION Architecture Technique

• Logigramme

de conception Détaillées

Graphe générale Decoupage en UT Diagramme de type MOT par UT

Description transaction

Description batch

Description Client-SRV Description Objets Algo de calcul Recette technique

Dossier d’exploitation et d’utilisation Évaluation étape suivante Validation

Description Navigation

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 

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

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

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

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

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 sousensembles 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

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

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

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 Le codage d’intégration)  

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 Le code crée doit répondre à des critères de d’intégration)

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

ETAPE4 : LA REALISATION (codage, tests unitaires, tests Le service méthode et qualité de l'entreprise va d’intégration)

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

ETAPE4 : LA REALISATION (codage, tests unitaires, tests d’intégration) Codage Traduire la conception détaillé en code Saisir le code Inclure les commentaires Compléter les dossiers de tests unitaires Revoir les dossiers d’exploitation et intégration Faire la revue de code Vers tests unitaires

ETAPE4 : LA REALISATION (codage, tests unitaires, tests  Les tests unitaires d’intégration)

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 Cahier De recette unitaire

Modèle validé oui

non

ETAPE4 : LA REALISATION (codage, tests unitaires, tests La préparation des tests d’intégration) 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).

ETAPE4 : LA REALISATION (codage, tests unitaires, tests L'exécution des tests d’intégration)

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

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

ETAPE4 : LA REALISATION (codage, tests unitaires, tests d’intégration) Dossier des tests D’intégration

Cahier De recette D’intégration

Tests d’integration Sous-système validé Modèle validé oui

non

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

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  Les scénarios de tests d'intégration, obtenus d’intégration) 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  L'exécution des tests d’intégration)

À 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

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  Et pour chaque test d’intégration) les composants à tester        



l'environnement nominal nécessaire les moyens nécessaires les conditions d'activation du test les données de tests (jeux d'essais) les résultats attendus les critères d'arrêt du test les dispositions à suivre en cas d'échec du test; - les mesures à effectuer

Dans le cas de scénarios complexes les tests seront modélisés au moyen de graphes, Des diagrammes représentent les éléments déclenchants, l'enchaînement opératoire et les résultats

ETAPE4 : LA REALISATION (codage, tests unitaires, tests  Le cahier de tests unitaires/d'intégration 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

ETAPE4 : LA REALISATION (codage, tests unitaires, tests  La main courante d’intégration)

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

ETAPE4 : LA REALISATION (codage, tests unitaires, tests  La fiche d'anomalie d’intégration) Chaque fois qu'une non-conformité est détectée lors d'un essai,

une fiche d'anomalie est dressée afin d'en tracer les incidences et les actions correctives que l'on va décider d'entreprendre. Dans cette fiche on va retrouver les informations suivantes  Une partie signalétique avec :    



numéro et la date de la fiche nom du recetteur numéro du scénario ainsi que le cas de test concerné statut de l'anomalie : bloquant ou non bloquant.

Une partie question avec :  





le le le le

la référence de l'écran ou la référence du document papier; la référence de la table ou du fichier concerné; - la description de l'anomalie; des annexes éventuelles permettant de préciser le problème (copie écran).

Une partie réponse avec   

la date de la réponse le nom de l'auteur de la réponse la description de la solution préconisée

Etape 5 : La Recette Les processus pourquoi faire une recette alors que le fournisseur (la maîtrise d’œuvre) a déjà réalisé des campagnes d'essais au niveau unitaire et au niveau intégration? En fait les essais réalisés jusque-là ont été des tests que l'on peut qualifier de « techniques ». Il importe maintenant de réceptionner tous les livrables du projet (logiciel, documentation et prestations associées). Pour cela il va falloir procéder à des tests « métiers » réalisés par les utilisateurs du futur système afin de vérifier que les exigences formulées par le client (la maîtrise d'ouvrage) sont bien satis­ 

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

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 

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

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

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

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

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

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

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

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,presta tions) livrés par la maîtrise d’œuvre (le fournisseur) sont accepté .

Etape 6 : L’installation / la diffusion(déploiement) 

Les processus



Concevoir et réaliser un produit logiciel représente une partie importante des activités d'ingénierie. Toutefois, lorsque le nombre de sites à installer est important, il ne faut pas négliger de maîtriser l'installation puis la diffusion d'un produit logiciel. La mise sous assurance qualité de ces activités doit alors s'exercer dans le temps et dans l'espace. Les impacts ne seront pas de la même nature pour gérer cinq, dix ou cent sites ou plus. Par ailleurs, les activités d'installation et de diffusion concernent non seulement la première mise en place du système logiciel, mais elles devront être intégralement reprises et supportées dans le

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

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

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

Etape 6 : L’installation / la diffusion(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

Etape 6 : L’installation / la  Pour réussir ce type de diffusion il importera diffusion(déploiement) 



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

Etape 6 : L’installation / la le fabricant a besoin d'un représentant local qui diffusion(déploiement) 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. 

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

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

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

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 

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

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

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

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.

LA Gestion de Configuration 

La problématique

Les activités de gestion de configuration permettent de connaître, à tout moment, toutes les informations concernant un système d'information installé sur un site. Par exemple Les programmes d'application avec leur version. Les matériels installés (y compris les périphériques et les cartes). Les outils de conception et de développement utilisés. Les logiciels de test utilisés. Les logiciels d'exploitation et logiciels de base avec leur version. Les interfaces. Les logiciels associés. La documentation technique. La documentation et les guides d'utilisa ion. Les dernières corrections réalisées...

La Gestion de Configuration  



Les éléments composant la configuration Par définition (ISO/('EI 12207 : 1995), un «élément de configuration est une entité au sein d'une configuration satisfaisant une fonction; pour un utilisateur et pouvant être identifiée de façon unique à un instant spécifique du cycle de vie. » Chaque élément doit posséder un identifiant unique, attribué le plus tôt possible, permettant de le référencer de façon non ambiguë. Dans le cas fréquent de progiciels achetés, il faut parfois recourir à une double identification des éléments. C'est-à-dire qu'il faut gérer l'identification prévue par le fournisseur, et, en parallèle, l'identification

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