Cycle de vie des logiciels

Cycle de vie des logiciels

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

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

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

Etapes 0 : Les Processus Préliminaires
L'objectif de cette étape préliminaire est de permettre la définition et la mise en place des processus de la relation client/fournisseur. Non seulement les bases de la collaboration doivent être établies avec précision dès le départ, mais aussi les modalités de leur évolution éventuelle doivent être prévues afin d'être en mesure de supporter sans encombre les événements qui ne manqueront pas de survenir pendant la vie du projet. C'est à cet endroit qu'il importe de préciser les rôles et responsabilités de : La maîtrise d'ouvrage qui commande et qui finance le projet. La maîtrise d'oeuvre qui réalise les différents produits à livrer. Pour des projets clairement définie par le client ,Le Cahier des Charges peut être fournie a cette étape , il sera contractuel

Cette étape est capitale pour le bon déroulement du projet. Elle s'applique quelles que soient les caractéristiques des produits logiciels à fabriquer (logiciel sur mesure, progiciel, intégration de solution ou simplement prestations intellectuelles). La place prépondérante du client dans tout système de management de la qualité implique une attention toute particulière à ces processus client/fournisseur qui mettent en jeu des métiers et des hommes qui ne sont pas tous des techniciens de l'informatique. Dans cette étape il y aura les processus suivants Préparation. Sélection des fournisseurs. Administration des fournisseurs

Les livrables Les livrables auront une structure spécifique en fonction des besoins du client et du fournisseur. Ils seront donc agréés en commun par l'organisme ou par l'entreprise. Il y aura les différents documents d'appel d'offres, de contrat, de suivi fournisseur et d'évaluation de produits.

ÉTAPE 1:INITIALISATION D'UN PROJET -LA PLANIFICATION
L'objectif de cette première étape est d'initialiser le projet et de planifier les travaux nécessaires à l'accomplissement de la réalisation du projet dans de bonnes conditions. L'initialisation du projet sera matérialisée par la rédaction et la diffusion d'une note de lancement. Pour la planification des travaux, le projet va être décomposé en plusieurs lots, chaque lot comportant un certain nombre d'étapes. Ce découpage va être observé selon deux axes: Une vue organisation de la qualité, dont les résultats des travaux d'étude seront consignés dans le document plan d'assurance qualité logiciel. Une vue évaluation initiale du projet (véritable devis du projet), dont les résultats des travaux d'étude seront consignés dans le document plan de développement logiciel.

Le plan qualité logiciel/plan d'assurance qualité logiciel (PAQL) Le plan d'assurance qualité logiciel est le document par lequel le chef de projet (et son équipe) décrivent les dispositions spécifiques prévues par l'organisation ou l'entreprise afin d'obtenir la qualité du produit logiciel ou du service résultant du projet en question. L'appellation «assurance qualité» dans le nom de ce document signifie qu'il s'applique à la relation client/fournisseur définie pour un projet donné et qu'il est communicable à l'extérieur de l'entreprise en respectant bien sûr les limites du périmètre de confidentialité des informations contenues

Ainsi le PAQL va décrire le système de management de la qualité du projet, c'est-à-dire La démarche qualité. Le référentiel et les méthodes utilisés. Les outils mis en place. Les contrôles prévus et planifiés. Les procédures d'assurance qualité Elles font références aux procédures qualité générales de l'entreprise et aux procédures générales définies pour l'ingénierie du logiciel. Elles seront complétées et enrichies si besoin est pour répondre aux exigences particulières du projet.

Les livrables La note de lancement La note de lancement est le document par lequel la direction de la maîtrise d'ouvrage d'un projet fait connaître officiellement sa volonté et sa décision d'engager le projet concerné. Ce document rappellera les objectifs et les contours du projet lancé. Il doit impérativement comporter l'identification du chef de projet (ou de l'équipe) qui a été choisi pour diriger les opérations et les moyens qui lui ont été alloués pour réussir. Ce document ne requiert pas de formalisme particulier autre que le respect des règles de la gestion documentaire instaurées au sein de l'entreprise.

ETAPE2 : LES SPECIFICATIONS
L'objectif de cette étape de spécifications c'est l'étude et la prise en compte des exigences fonctionnelles et des contraintes des utilisateurs du système d'information ou du logiciel. Spécifier c'est répondre à la question « Quoi » ? Cette réflexion amène à définir les besoins. Il importe de préciser le plus clairement possible ce que les futurs utilisateurs attendent du projet. Dans cette étape il y aura les processus suivants :

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

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

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

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

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

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

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 questionsré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 conception Détaillées Logigramme de
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 Navigation Description Objets Algo de calcul Recette technique Dossier d’exploitation et d’utilisation Évaluation étape suivante Validation

ETAPE3 : LA CONCEPTION Les livrables Les objectifs du dossier.
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

Le codage Le codage des programmes consiste à traduire en code, compréhensible par un ordinateur, l'architecture technique, qui a été conçue. Chaque programme, ou sous-programme, va être confié à un développeur qui le traduira dans un langage de programmation qui sera fonction du projet (exemples de language : Cobol, Fortran, C, C++, Visual Basic, HTML, Java, DELPHI , C#...), compatible avec le système d'exploitation (exemple de système d'exploitation : OS. UNIX, DOS,WINDOWS xx, NT,XP, Linux...) et le matériel utilisé. De plus eu plus, on utilise des outils automatiques de production de code. des générateurs de programmes et des ateliers de génie logiciel qui déchargent le développeur des parties graphiques (IHM)

Le code crée doit répondre à des critères de qualité : clarté, lisibilité, modularité... Il doit être documenté avec des commentaires nombreux et explicites qui permettront une compréhension aisée pour les personnels chargés de la maintenance ultérieurement. Des règles d'identification et de nommage sont constituées pour les programmes, les fonctions, les données (fichiers et bases de données), les traitements communs. L'industrialisation de la programmation conduit à réaliser des briques logiciel réutilisables, brique technique (exemple : accès à des données, traitement d'erreur... ) ou brique métier (par exemple : calcul d'intérêts). Ensuite, le développeur travaille comme un «ensemblier» qui assemble des modules préfabriqués et déjà testés unitairement. Il en résulte un important gain de productivité.

Le service méthode et qualité de l'entreprise va définir des standards de programmation par catégorie de technologie utilisée. De même des procédures sont rédigées pour normaliser l'utilisation des différents environnements de travail mis à disposition sur un site. Les développeurs doivent appliquer ces normes, standards et procédures. La standardisation des programmes permet d'harmoniser la communication entre les développeurs d'une même équipe, voire entre les personnels de plusieurs équipes de projet. Puis entre les projets et la maintenance. Des revues de code servent à vérifier le respect de ces standards et le bon usage qui en est fait.

Traduire la conception détaillé en code Saisir le code Inclure les commentaires Compléter les dossiers de tests unitaires Revoir les dossiers d’exploitation et intégration Faire la revue de code Vers tests unitaires

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

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

La préparation des tests Le jeu d'essai unitaire est conçu afin de satisfaire aux exigences suivantes Passer au moins une fois dans chacune des branches de l'arborescence du programme. Contrôler la validité des algorithmes de calcul. Tester tous les cas non passants (cas qui déclenchent un message d' anomalie). Tester les valeurs limites prévues dans le dossier de conception détaillée. Tester les accès à des informations externes en créant des « répondeurs » qui simuleront la mise à disposition de l'information nécessaire. Les cas d'un test unitaire permettent de vérifier les règles d'intégrité, de contrôler la cohérence sur les valeurs de chaque rubrique, de s'assurer que les valeurs saisies sont valides, qu'elles répondent aux critères, (obligatoire, facultatif, existe dans une table la liste de valeurs autorisées). Exemples Le format de la date est invalide. La rubrique est obligatoire. La date est au-delà des valeurs limites (date saisie < date du jour).

L'exécution des tests A partir des plans de tests élaborés lors du processus de préparation, les personnes en charge des tests vont : - Dérouler les scénarios. - Vérifier que les résultats obtenus sont conformes, aux résultats attendus. - Relever dans une fiche d'anomalie tous les écarts constatés. - Tenir à jour une main courante des essais effectués. Les données d'essai, les scénarios de test et les résultats obtenus sont conservés afin de pouvoir servir de référence ultérieure. Le chef de projet s'assure que les essais ont été effectués, valide la fiabilité des résultats obtenus et contrôle que les données d'essai sont bien archivées.

Les tests d'intégration C'est le deuxième niveau de contrôle. Il correspond aux essais effectués sur la branche droite du « V » du processus de développement du logiciel . Les tests d'intégration comportent deux parties : la préparation et l'exécution. La préparation des essais a été établie pendant la conception générale pour déterminer sur quels critères le logiciel répond aux exigences fonctionnelles. L'exécution des essais, vérification proprement dite, sera confiée à une équipe de « recetteurs » distincte des développeurs du logiciel.

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

La préparation des tests Les jeux d'essai d'intégration sont conçus afin de satisfaire aux exigences suivantes - Essayer les fonctionnalités prévues au dossier de conception générale. - Contrôler chacune des règles de gestion. - Passer au moins une fois dans chacun des modules de l'arborescence de la chaîne/du système.

- Vérifier l'impact des événements qui se répercutent à d'autres endroits de la chaîne. - Choisir des cas passants en nombre suffisant pour tester les débordements. - Tester les interfaces avec les autres systèmes en créant des « répondeurs » qui simuleront la mise à disposition de l'information nécessaire

Les scénarios de tests d'intégration, obtenus par assemblage organisé de cas de test, permettent de vérifier les règles de gestion, la cohérence des données entre elles, les valeurs résultats de formules de calcul et les structures conditionnelles (déclencheurs). C'est aussi le moyen de contrôler les fonctionnalités unitaires et intégrées du système/logiciel. Les tests d'intégration portent sur : Une chaîne de traitement batch. Un menu et ses transactions associées. Une chaîne informatique complète

L'exécution des tests À partir des plans de tests élaborés lors du processus de préparation, les personnes en charge des tests vont Dérouler les scénarios (appelés aussi scripts). Vérifier que les résultats obtenus sont conformes aux résultats attendus. Relever dans une fiche d'anomalie tous les écarts constatés. Tenir à jour une main courante des essais effectués. Les données d'essai, les scénarios de test et les résultats obtenus sont conservés afin de pouvoir servir de référence ultérieure. Les tests d'intégration sont sous la responsabilité du chef de projet. Il va assembler les différents programmes ou briques logicielles en chaînes de traitement. Puis, d'une manière analogue, il assemble les chaînes en système d'information. Leur exécution peut être déléguée.

Les livrables À la fin de la phase de codage on obtient des produits documentés (avec des dossiers de programme) et après chaque étape d’exécution de tests on obtient : Des fiches d'anomalies à transmettre au développeur pour correction, Des fiches d'évolutions à prendre en compte dans une version ultérieure, du logiciel La liste des scénarios testés avec date de passage de résultat du test (bon ou mauvais),

Les dossiers de programme Le formalisme des dossiers de programme est fonction des technologies utilisées et des normes et standards de programmation en vigueur sur un site de développement. À titre d'exemple, il est possible, de structurer des modèles types pour : Les modules temps réel. modules temps différé. modules d'édition. Les modules communs (sous-programmes), etc.

Les dossiers de tests unitaires A la fin de la phase de préparation des tests unitaires, on obtient un dossier de test unitaire qui comprend : L'enchaînement chronologique des tests (plan de test). La description détaillée de chaque cas de test. Les données d'essais qui permettent de valoriser chaque cas. La description des résultats attendus, Les paramètres à utiliser pour les essais (dates, conditionnement...

Les dossiers de tests d'intégration Chaque dossier de test d'intégration doit contenir au moins les informations suivantes: Des plans de tests définissant et organisant le séquencement des actions. La planification de ces actions. La liste des scénarios formalisés et leur ordre de passage.

Et pour chaque test les composants à tester l'environnement nominal nécessaire les moyens nécessaires les conditions d'activation du test les données de tests (jeux d'essais) les résultats attendus les critères d'arrêt du test les dispositions à suivre en cas d'échec du test; - les mesures à effectuer Dans le cas de scénarios complexes les tests seront modélisés au moyen de graphes, Des diagrammes représentent les éléments déclenchants, l'enchaînement opératoire et les résultats

Le cahier de tests unitaires/d'intégration À la différence du dossier de tests qui est élaboré à l'avance pour décrire les essais à faire, le cahier de tests unitaires et le cahier de tests d'intégration sont les outils qui accompagnent respectivement l’exécution des essais. Le cahier de tests est de même structure pour les tests unitaires et d'intégration. Il comprend Une main courante, Un recueil de fiches d'anomalies. Un enregistrement électronique des scénarios (si utilisation d'outil de tests automatiques)

La main courante C'est la liste de tous les essais effectués. Elle assure la traçabilité des essais et précise aussi les résultats constatés pour les tests : conforme/non-conforme. Dans ce document on va retrouver les informations suivantes . La date du test. Le nom du recetteur. Le numéro de scénario et les numéros des cas testés. Les résultats obtenus. L'indicateur de conformité (oui/non). Et dans le cas où le test est non-conforme : le numéro de la fiche d'anomalie, les actions en cours

La fiche d'anomalie Chaque fois qu'une non-conformité est détectée lors d'un essai, une fiche d'anomalie est dressée afin d'en tracer les incidences et les actions correctives que l'on va décider d'entreprendre. Dans cette fiche on va retrouver les informations suivantes Une partie signalétique avec : le numéro et la date de la fiche le nom du recetteur le numéro du scénario ainsi que le cas de test concerné le statut de l'anomalie : bloquant ou non bloquant. Une partie question avec : la référence de l'écran ou la référence du document papier; la référence de la table ou du fichier concerné; - la description de l'anomalie; des annexes éventuelles permettant de préciser le problème (copie écran). Une partie réponse avec la date de la réponse le nom de l'auteur de la réponse la description de la solution préconisée la date à laquelle la correction a été faite.

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

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 fournisseur 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 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, 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 diagrammes 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

Tout d'abord une installation ne peut intervenir que sur un produit logiciel qui a fait l'objet d'une recette satisfaisante, c'est-à-dire pour lequel il ne reste plus aucune anomalie bloquante pour les utilisateurs. Sinon la mise en production doit être systématiquement refusée. Ensuite, l'identification des éléments composant la configuration (logiciels, données, procédures, documentation) sera réalisée. Pour les tâches d'identification des composants on se reportera a La gestion de configuration. Toutes les opérations d'une installation doivent être effectuées sans risque d’erreurs. Une installation comporte des travaux entièrement automatiques et des travaux manuels .

Une planification de l'installation doit être rédigée. Elle identifie de manière détaillée les travaux à faire, en précisant l'ordre d'enchaînement des tâches et les affectations de responsabilités. Un mode doit expliquer les actions à entreprendre en cas d'anomalies. Le plan d'installation du système doit être élaboré en collaboration entre les équipes de développement et d’exploitation . Il doit être compatible avec l'environnement cible, conformément aux exigences prévues au contrat. Les ressources nécessaires pour l'installer doivent être identifiées et disponibles. La procédure peut être diversifiée, avec par exemple La procédure d'installation automatique. La procédure d'installation manuelle. Le mode d'emploi.

L'équipe de développement assistera l'équipe d'exploitation pour la mise en place du système. I’installation doit être conforme au plan d'installation. Le déroulement et les résultats de l'installation doivent être documentés. La traçabilité doit être assurée ainsi que l’enregistrement des références de la version installée La de tâche de l'installation sera obligatoirement une tâche de vérification comme une revue d'acceptation qui permet de valider les travaux réalisés.

L'organisation de la diffusion à mettre, en place est conditionnée par la dispersion des sites cibles sur lesquels il est prévu d'exploiter le système logiciel. Dans le cas d'un nombre restreint de sites d'installation, la diffusion va se limiter à une duplication de la procédure d'installation sur chacun des sites. La principale difficulté réside alors à gérer les montées de version pour chaque site et à garantir I’intégrité de l'ensemble des systèmes lorsque, à un instant donné, tous les sites ne sont pas au même niveau de version

Pour réussir ce type de diffusion il importera de définir les relations avec les partenaires. Par exemple pour un projet de dimension nationale ou internationale, plusieurs sites cibles peuvent être concernés. Il importe de préciser les engagements et les responsabilités de chacun. Par contre, dans le cas d'un produit logiciel mis sur le marché et destiné, à une large commercialisation, le fournisseur va devoir faire le choix du canal de distribution (un ou plusieurs) comme pour n'importe quel produit manufacturé. Alors, la diffusion sous-entend le recours à un tiers entre le fabriquant et le client utilisateur. Si le nombre de licences d'utilisation est important ou bien si le fabriquant est situé à l’étrangers

le fabricant a besoin d'un représentant local qui joue le rôle d'intermédiaire. Ce maillon supplémentaire dans la chaîne de distribution implique des moyens qualité adéquats qu'il importe de concevoir, de développer, de mettre, en place, de suivre et de faire vivre. La maîtrise des tâches de diffusion nécessite la mise au point et le contrôle : D'une procédure d'échange aller vers les distributeurs, D'une procédure d'échange retour depuis le distributeur; Du traitement des anomalies. De la définition de l'assistance à apporter au diffuseur. De la documentation. De la formation. De la mise en place d'une hot line.

L’Exploitation Une fois que le système/logiciel est installé correctement dans l'environnement de production d'un site, les équipes d'exploitation vont prendre le relais des équipes de développement. A partir de ce moment le système/logiciel va être exploité en utilisant des données réelles, il est mis a la disposition des utilisateurs dans le cadre de l’exercice de leurs métiers. La montée en puissance peut se faire progressivement , par exemple une agence après l'autre, une usine après l'autre, une société après l'autre .

Les livrables Dossier d’installation Il regroupe toutes les informations nécessaire a l’installation du logiciel, La liste des tâches ainsi que l’ordre d’exécution , les ressources …

Etape 7 : La Maintenance Les processus
L’objectif de cette septième étape est de conserver le système/logiciel dans un état tel qu'il pourra continuer d'être exploité, longtemps après son installation. En fajt avec le temps, des événements surgissent qui viennent perturber plus ou moins gravement l'exploitation. Ces événements, sont générateurs de modifications. Il est possible de, les classer en deux catégories : Les anomalies de fonctionnement. Les évolutions fonctionnelles ou techniques

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

Il faut y ajouter Tous les documents d'organisation, tels que procédure, contrat, planning, plan de développement, plan de configuration, fiches techniques... Tous les documents de type exploitation (guide d'installation, d'utilisation). Nous nous référerons aussi a la norme ISO 9001 (et la version 2000). Ce paragraphe contient les exigences pour la maîtrise de tous les documents inclus dans un système qualité.

États d'un document A l’exception des courriers et des comptes-rendus de réunion, tout document passe par les étapes d'un cycle de vie. En effet il est successivement identifié, rédigé, puis validé et enfin diffusé. Afin de suivre correctement les évolutions d’un document et d'assurer la cohérence de leur niveau de fraîcheur des informations, il est impératif de connaître l'état de sa version/révision. Ainsi tout document va connaître trois états comme suit Provisoire : le document est en cours d'élaboration (version 0.0). À valider : le document est complet, il est en cours de validation (Version 0.1). Validé/approuvé : le document est conforme, il est diffusé pour action (Version 1.0).

Le cycle de vie d'un document La gestion documentaire consiste à assurer la prise en compte de tous les événements qui interviennent sur un document tout au long de son cycle de vie. Un document, quelque soit son type, passe par les étapes suivantes-: Naissance (ou création). Jeunesse pour son développement (ou rédaction). Adolescence (ou validation/approbation). Âge mûr et adulte pendant lequel il est actif Retraite (archivage pour conservation) Mort (destruction).

Il y a deux types de documents Ceux soumis à la gestion des versions (versionning,traçabilité). Ceux non soumis à la gestion des versions (non versionning).

Pour les premiers types de documents, soumis au versionning le cycle de vie va décrire les différents processus suivants La création d'un document. La rédaction d'un document. La validation d'un document. L'approbation d'un document. La diffusion d'un document. La modification d'un document. La validation et la diffusion d'un document modifié. La conservation un document. Le retrait d'un document.

Pour les seconds types de dossiers, non soumis au versionning, elle va décrire les différents processus suivants La création d'un document. La rédaction d'un document. La diffusion d'un document. La conservation d'un document

Le circuit de validation/approbation Lorsque la rédaction d'un document soumis à validation est achevée, le document est prêt à entrer dans le circuit de validation. Chacun des valideurs sélectionnés à l'avance, mentionnés sur la page bordereau de validation, devra relire le document, exprimer ses remarques sur le fond et sur la forme du document, puis formaliser l'expression de ses remarques, et enfin donner son accord (validation ou approbation suivant le cas. pour la mise en diffusion du document. Pour la validation/approbation on peut faire appel aux techniques du groupware, c'est-à-dire en utilisant une diffusion électronique des documents.

La Charte Graphique La charte graphique est le document qui va consigner toutes les informations décrivant les règles et formats de documents qui ont été choisis et approuvés pour l'entreprise. On va notamment y trouver précisés: La forme, la taille, la couleur le dessin du logo de l'entreprise. La représentation du sigle de l'entreprise. Le contenu et la forme des bas de page standards. La présentation officielle du papier entête La présentation officielle des factures. La présentation Powerpoint utilisée La police de caractères couramment utilisée, sa taille et sa couleur. Les caractéristiques des feuilles de styles utilisées en bureautique. Le graphisme, les couleurs des documents sortant de l'entreprise. Tout ce qui peut contribuer à uniformiser les supports servant de communication entre l'entreprise et le monde extérieur et qui peuvent avoir une action sur l'image de marque de la société.

LA Gestion de Configuration
La problématique Les activités de gestion de configuration permettent de connaître, à tout moment, toutes les informations concernant un système d'information installé sur un site. Par exemple Les programmes d'application avec leur version. Les matériels installés (y compris les périphériques et les cartes). Les outils de conception et de développement utilisés. Les logiciels de test utilisés. Les logiciels d'exploitation et logiciels de base avec leur version. Les interfaces. Les logiciels associés. La documentation technique. La documentation et les guides d'utilisa ion. Les dernières corrections réalisées... Cela implique d'identifier et de répertorier toutes les informations qui apparaissent tout au long de la vie du logiciel, depuis sa conception, son développement et sa maintenance en exploitation..

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

Les éléments de configuration d'un logiciel vont comprendre Les documents de conception. Les documents de réalisation. Les documents d'utilisation. Les documents d'exploitation. Les composants programmes. Les données des tables et paramètres. Les procédures (installation, exécution...) L'environnement de développement. L'environnement de recette. Les jeux d'essais (données, procédures, scénarios et cas de tests)...

La gestion de configuration comporte quatre activités principales Identifier. Contrôler. Administrer. Auditer

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

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

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

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

Cycle de vie des logiciels

Présentations similaires

Présentation au sujet: "Cycle de vie des logiciels"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Cycle de vie des logiciels

Présentations similaires

Présentation au sujet: "Cycle de vie des logiciels"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back