SourceForgegendiapo.sourceforge.net/documents/03 - Plan Qualite … · Web viewLes différentes règles énoncées ci-dessous concernent uniquement les documents rédigés avec le

ProjetProjet GenDiapoGenDiapo

Rédacteurs FLAMENT Alexandre le 23/08/2001QUAY-THEVENON Christophe

Responsable DAVID Jean-Pierre

Plan QualitéVersion G.2.2

Statut Final

Disponibilité Consultable

Site : http://gendiapo.sourceforge.net/

http://www.gendiapo.free.fr/

SOMMAIRE

Historique____________________________________________4

1. But et Domaine d’application__________________51.1. Identification des logiciels concernés_____________51.2. Responsabilité_______________________________________51.3. Procédure d’évolution______________________________51.4. Procédure en cas de non application du plan qualité______________________________________________________6

2. Documents applicables et documents de référence_____________________________________________7

2.1. Documents imposés et vérifiables_________________72.2. Documents non imposés____________________________7

3. Organisation_____________________________________8

4. Démarche de développement__________________94.1. Etude de l’existant_________________________________104.2. Incrément 1________________________________________114.3. Incrément 2________________________________________13

5. Documentation_________________________________155.1. Documents générés_______________________________15

5.1.1. Documents de gestion de projet_____________________________155.1.2. Documents techniques______________________________________16

5.2. Gestion de la nomenclature_______________________165.2.1. Règles de nomenclature_____________________________________17

5.2.1.1. En-tête commun_________________________________________175.2.1.2. Gestion des versions_____________________________________17

5.2.2. Comptes rendus de réunion__________________________________18

6. Gestion des modifications_____________________196.1. Origine des modifications_________________________19

6.2. Procédure et organisation________________________19

7. Méthodes, Outils et Règles___________________207.1. Outils_______________________________________________207.2. Règles______________________________________________21

7.2.1. Rédaction de documents_____________________________________217.2.1.1. Table des matières______________________________________217.2.1.2. Glossaire________________________________________________217.2.1.3. Historique_______________________________________________217.2.1.4. Enregistrement Documents______________________________21

7.2.2. Codage______________________________________________________227.2.2.1. Gestion des versions_____________________________________22

7.2.3. Fichier exécutable___________________________________________227.2.4. Sauvegarde_________________________________________________227.2.5. Mise à disposition du code___________________________________23

7.2.5.1. Code____________________________________________________237.2.5.2. Code plugin______________________________________________23

8. Contrôle des fournisseurs_____________________248.1. Sous-traitants______________________________________248.2. Co-traitants________________________________________248.3. Logiciels achetés, loués ou imposés______________24

9. Protection et Livraison________________________25

10. Suivi du plan qualité_________________________2610.1. Réunions___________________________________________2610.2. Tests________________________________________________26

10.2.1. Types de tests_____________________________________________2710.2.2. Gestion des bugs__________________________________________27

10.3. Procédures d’acceptation_________________________2710.3.1. Respect des attributs de qualité___________________________2810.3.2. Documents________________________________________________2910.3.3. Réalisations Logicielles____________________________________29

Historique

Version Date Publication Causes Changement

G.0.1 12/04/2001 Version initiale

G.1.0 01/05/2001 Changement Cahier des Charges et Plan de Développement

G.1.1 05/06/2001 Changement Cahier des Charges et Plan de Développement

G.2.0 09/07/2001 Mise à jour du second incrémentMise en place d’un CVS

G.2.1 06/08/2001 Mise à jour du Plan de développementRévision Critères Qualités

G.2.2 23/08/2001Modifications des phases des deux incréments dans le Plan de DéveloppementRévision Mesures Critères Qualités

Projet GenDiapo 5 / 30 CLIPS / SYNERGIE3R

Le Plan Qualité n’ayant été rédigé qu’au début de la période à plein temps, il a été décidé que les documents produits, durant la phase d’étude, ne feraient pas l’objet de contrôle qualité.

1. But et Domaine d’application

Le plan qualité logiciel décrit l’ensemble des dispositions spécifiques prises par l’équipe de développement pour obtenir la qualité du logiciel considéré. Pour la rédaction de ce plan qualité, nous aurons besoin du planning associé au plan de développement.

1.1. Identification des logiciels concernés

Ce document décrit le plan qualité logiciel qui sera appliqué au développement du système GenDiapo. Ce système permettra la saisie d’un cours, par un enseignant, sans souci de présentation, puis la génération de l’HyperDiaporama correspondant.

L’équipe de développement sera composée de 2 stagiaires (FLAMENT Alexandre et QUAY-THEVENON Christophe) qui auront la responsabilité de mener à bien le projet.

1.2. Responsabilité

Le responsable qualité s’occupera de la qualité deux demi-journées par semaine : Il sera chargé de surveiller l’application du Plan Qualité logiciel et, dans le cas de non-respect, il décidera seul des actions à entreprendre. Par exemple, il pourra décider la modification de certains documents.

De plus, il sera le principal responsable de la rédaction et de l’évolution du plan qualité logiciel.

1.3. Procédure d’évolution

Notre responsable de stage ne s’estimant pas assez compétent dans ce domaine, l’évolution du Plan Qualité est laissé à l’appréciation du responsable qualité.Toute modification du présent document devra être soumise aux deux personnes de l’équipe et une nouvelle copie leur sera remise le cas échant.

REMARQUE Chaque nouvelle version du Plan Qualité contiendra l’historique des modifications apportées et leurs causes


1.4. Procédure en cas de non application du plan qualité

En cas de non-application du Plan Qualité, une première notification des personnes concernées aura lieu.Dans le cas où ces notifications ne seraient pas prises en compte, la phase de développement serait stoppée jusqu’à l’application correcte du Plan Qualité.

En dernier recours, dans le cas où le respect du Plan Qualité ne pourrait être assuré, ce dernier devra être modifié, mais de façon minime pour garder les mêmes objectifs qu’au début.


2. Documents applicables et documents de référence

Ce sont l’ensemble des documents appelés dans le Plan Qualité.

2.1. Documents imposés et vérifiables

Aucun document à appliquer n’est imposé par notre responsable.

2.2. Documents non imposés

Les documents suivants nous permettront de mener à bien notre projet :

Les documents provenant des cours de DESS GI : Initiation à la conduite de projet, G.Vigliano, 2000, UFR IMA. Cours de génie logiciel, I.Parissis, 2000, UFR IMA. Guide de rédaction d’un plan qualité logiciel, AFCIQ, 1986.

Les différentes documentations trouvées (notamment sur le Web) sur : Les outils et technologies utilisés Le développement de logiciel Open source


3. Organisation

Cette partie identifie l'ensemble des personnes intervenant dans le projet GenDiapo avec leurs rôles et responsabilités ainsi que les liens hiérarchiques entre eux.

Nom Prénom Fonction Rôle dans le projet

DAVID Jean-Pierre Enseignant Responsable du projet (MOAd)

PROMAYON EmmanuelEnseignant-chercheur

Laboratoire TIMC(Intégré à CRIMEI)

Instigateur du projetFutur utilisateur

(MOEd)

ENSEIGNANTS Groupe CRIMEI Futurs utilisateurs(MOEd)

SYNERGIE3R Start UpE-learning

Suivi du projet(MOAd)

MONNET Pierre-Yves Chef de projetCap Gemini Consultant extérieur

FLAMENT Alexandre StagiaireEquipe GenDiapo

Analyste ProgrammeurResponsable Technique

QUAY-THEVENON Christophe Stagiaire

Equipe GenDiapoAnalyste ProgrammeurResponsable Qualité

GUILLOUX Cécile Ingénieur Ariadne Co-Traitance(Phase de Publication)

GATEAUD Stéphanie Graphiste CO-TICE Co-Traitante(Phase de Publication)


4. Démarche de développement

Nous allons identifier les différentes phases mises en œuvre dans le cadre du développement de GenDiapo et soumises à des actions de qualité : Elles sont regroupées en 3 parties (l’étude de l’existant et les deux incréments) décrites plus précisément dans le document « Plan de développement ».

En outre, elles contiendront les précisions suivantes : Les activités soumises à des actions qualité Les documents ou produits nécessaires en entrée de la phase Les documents ou produits réalisés durant la phase Les conditions de fin de cette phase


4.1. Etude de l’existant

Ces différentes phases correspondent à l’étude de l’existant, la définition des besoins à long terme et du cahier des charges.

REMARQUE Le terme de validation, dans le cas des enseignants, se limitera à la présentation aux enseignants des documents correspondants et à la prise en considération de leur remarques

Phases Activités Qualité

Documents Entrée

Documents Sortie

Condition Fin

Etude existant Etude faisabilité

Documentation Sujet Documentation GenEval

Etat de l’art sur XML, Conversion formats propriétaires vers XML

Accord Responsable

Objectifs Principaux Documentation Etat de l’art Objectifs Principaux Présentation Enseignants et Responsable

Définition Besoins Documentation Objectifs Principaux Cahier des ChargesPlan DéveloppementPlanningPlan Qualité

Validation Cahier des charges par ResponsableValidation Autres documents par Consultant


4.2. Incrément 1

Les différentes phases concernent la réalisation de l’outil auteur de GenDiapo.


Documents Entrée

Documents Sortie

Condition Fin

Vérification faisabilité Documentation Cahier des ChargesPlan Qualité

Gestion Risques Accord Responsable et Consultant

Architecture Externe DocumentationConception ArchitectureStructure Document

Cahier des ChargesPlan Qualité

DTDArchitecture Externe

Validation DTD par ResponsablePrésentation Architecture Externe à Responsable et Enseignants

Ré-Ingénierie Merlot Documentation Architecture Externe Architecture Externe Présentation Architecture Externe à Responsable et Enseignants

Maquettage Codage Architecture Externe Maquette Vue Stylée Présentation Maquette à Responsable

Architecture Interne Documentation Cahier des ChargesArchitecture ExternePlan Qualité

Architecture Interne

CodageTests Unitaires

Codage Cahier des ChargesArchitecture ExterneArchitecture InternePlan Qualité

Code Prototype conforme aux tests

Tests Documentation Cahier des Charges Code Prototype conforme aux


Codage Architecture ExterneArchitecture InternePlan Qualité

testsMise en ligne d’une version de GenDiapo

REMARQUE Parallèlement à la phase d’architecture externe, une formation de l’équipe à Java sera nécessaire


4.3. Incrément 2

Le but des différentes phases décrites ci-dessous est l’intégration de l’outil de publication à l’outil auteur de GenDiapo.

REMARQUE Afin de différencier les éléments entre les deux incréments, les éléments associées à l’incrément 2 seront suivi de II


Documents Entrée

Documents Sortie

Condition Fin

Révision de documents Documentation Documents Incrément I Mêmes Documents II Documents mis à jourPrésentation au Responsable

Publication PDF DocumentationCodage

Cahier des Charges II Architecture Externe IIArchitecture Interne IIPlan Qualité II

Réalisation Plugin IISquelette Plugin IICode II

Conforme aux testsMise en ligne d’une version de GenDiapoMise en ligne d’un squelette pour la réalisation d’un Plugin

Tests Manuel Utilisateur

DocumentationCodage

Code IICahier des Charges IIArchitecture Externe IIArchitecture Interne IIPlan Qualité II

Tests Unitaires IITests Intégration IIDossier Bugs IIManuel Utilisateur II

Prototype conforme aux testsMise en ligne du Manuel Utilisateur

Publication HTML Codage Code IIRéalisation Plugin IISquelette Plugin II

Code II Intégration à GenDiapo(réalisée par Cécile Guilloux et l’équipe GenDiapo)

Corrections GenDiapo DocumentationCodage

Code IITests Intégration II

Code IITests Intégration II

Prototype conforme aux tests


Dossier Bugs II Dossier Bugs II Mise en ligne d’une version de GenDiapo

Mise à Jour Documents Documentation Tous les documents Tous les documents Tous les documents révisésPrésentation au Responsable


5. Documentation

Ce chapitre va permettre de classer les documents générés suivant deux catégories :

Documentation de gestion de projet

Documentation technique et manuel utilisateur

Pour chacun de ces documents, sa disponibilité devra être précisée (livrable, consultable) ainsi que la phase de développement correspondante. Aucun plan type n’a été préalablement défini pour les documents (sauf les comptes rendus de réunion), néanmoins les rédacteurs devront s’appuyer sur les documents référencés au paragraphe 2.2.

5.1. Documents générés

La disponibilité des documents est répartie en deux catégories :

Livrable : Le document est à livrer aux enseignants donc à faire valider

Consultable : Le document peut être consulté par le responsable, les enseignants ou le consultant mais aucune validation n’est demandée

5.1.1. Documents de gestion de projet

Ces documents étant présent tout au long du développement, ils ne sont affectés à aucune phase précisément.

Documents générés Disponibilité

Plan de développement Consultable

Planning Consultable

Plan qualité logiciel Consultable

Suivi de l’avancement de projet (Carnet de bord) Consultable

Comptes rendus de réunions Consultable

Comptes rendus d’audits(Documents rédigés par le consultant)

Consultable(si l’équipe GenDiapo en a une copie)


5.1.2. Documents techniques

Nous avons regroupé ici l’ensemble des documents produits durant les 3 grandes phases de développement.

Phase de développement

Documents générés Disponibilité

Etude de l’existant Etat de l’art Consultable

Définition Besoins Objectifs Principaux Consultable

Définition Besoins Cahier des charges Livrable

Vérification Faisabilité Gestion Risques Consultable

Architecture Externe Structure Document Livrable

Architecture Externe Architectures externes Livrable

Architecture Interne Architectures internes Consultable

Codage Code source Consultable

Codage Réalisation Plugin Livrable

Manuel Utilisateur Manuel utilisateur Livrable

Bugs Dossier Bugs Consultable

Tests Unitaires Dossier Tests Unitaires Consultable

Tests Intégration Dossier Tests Intégration Consultable

Tests Intégration Résultats des Tests Consultable

5.2. Gestion de la nomenclature

Cette partie va permettre de détailler les différentes normes de nomenclature pour les documents (décrits ci-dessus) réalisés avec le logiciel Word. Seuls les comptes rendus de réunion auront une nomenclature différente et feront l’objet d’un chapitre spécifique.

Le responsable de la mise en œuvre et de la vérification du bon respect de ces normes est le responsable qualité.


REMARQUE Pour homogénéiser tous les documents produits, les rédacteurs doivent utiliser le document de référence nommé « GenDiapo.dot ».

5.2.1. Règles de nomenclature

Les différentes règles vont permettre de préciser l’en-tête commun et la gestion des versions.

5.2.1.1. En-tête commun

L’en-tête comporte le nom des rédacteurs du document, le nom du responsable du projet, le logo de GenDiapo la date de rédaction.Ensuite, nous avons le titre du document avec ses caractéristiques :

Le numéro de version Le statut : Il correspond soit à Provisoire, soit à Final La disponibilité : elle correspond à celle énoncée dans les paragraphes

précédents

Pour terminer, nous avons l’adresse du site de GenDiapo.

5.2.1.2. Gestion des versions

Notre système se déroule suivant trois grandes phases, il nous a donc semblé important de notifier pour tous les documents à quelle phase ils se rapportent. De plus, pour les documents généraux à l’ensemble du développement (Plan Qualité, Plan Développement, …), une référence particulière a été instaurée.


X.

Y. Z

Référence de la phase de développement

X = 0 pour l’étude X = I pour l’incrément 1 X = II pour l’incrément 2 X = G pour les documents

généraux

Incrément de Version

L’incrémentation est effectuée pour des modifications minimes

Nous allons maintenant donner les règles d’incrémentation des versions :

Dans le cas où aucune version d’un document n’aurait été rédigée pour une phase donnée, la numérotation de la première version sera de la forme X.0.1 où X est la référence à la phase de développement

A chaque incrémentation de Y, la nouvelle valeur de Z est 0

5.2.2. Comptes rendus de réunion

Ces documents étant des documents moins volumineux et plus internes au projet, la nomenclature sera un peu différente : leur document de référence se nomme « Reunion.dot » et il suffira au rédacteur de le compléter.

Chaque réunion sera en effet référencée par sa date. Dans le cas d’une réunion externe au projet, le but de la réunion devra être précisé dans le titre.

De plus, l’objet devra préciser rapidement le but de la réunion et le ou les personnes présentes.


Incrément de Version

L’incrémentation est effectuée pour des modifications importantes

6. Gestion des modifications

Afin de réagir efficacement à une demande de modification, le système suivant de gestion des modifications sera mise en place.

6.1. Origine des modifications

Les demandes de modifications ont deux origines : un constat d’anomalie une demande d’évolution

Elles seront mises en évidence par l’équipe GenDiapo, le responsable de stage ou par le consultant.

6.2. Procédure et organisation

La procédure mise en place sera la suivante :

Processus de gestion des modifications


Demande de modification

AnalyseEvaluation

Faisabilité

NotificationResponsable

RéalisationModification

Mise à jourDocumentsRéférence

Livraison

OUI

NON

7. Méthodes, Outils et Règles

7.1. Outils

Voici la liste de tous les outils mis en œuvre pour le développement de GenDiapo. Pour chacun d’entre eux, nous préciserons les phases de leurs utilisations ainsi que leurs fonctions.

Outils Phase d’utilisation Fonction

Word 2000 Toutes Traitement de texte

MSProject 98 Toutes Gestion de Projet

COCOMO Définitions Besoins Calcul Effort

JDK 1.3 (Sun) CodageTests

Compilateur JAVA

Ant Codage Outil de compilation

CVS CodageTests

Outil de gestion de version

Emacs CodageTests

EditeurLinux

HTML Kit CodageTests

EditeurWindows

Saxon CodageTests

Moteur XSLT

FOP CodageTests

Moteur XSL-FO

JTest Tests Unitaires Outil de Tests

Source Forge Toutes Mise à disposition des versions de GenDiapo et des documents associés

Linux Toutes Serveur de sauvegarde et CVS


7.2. Règles

Nous allons détailler l’ensemble des règles et normes pour les activités suivantes :

La rédaction de document Le codage La gestion des versions des fichiers sources Le fichier exécutable La sauvegarde La mise à disposition du code

7.2.1. Rédaction de documents

Les différentes règles énoncées ci-dessous concernent uniquement les documents rédigés avec le logiciel Word.

7.2.1.1. Table des matières

Pour tous les documents ayant un nombre de pages supérieur ou égale à 10, une table des matières détaillée devra être éditée. Le style des différents types de titres possibles sont référencés dans le document type

7.2.1.2. Glossaire

La mise en place d’un glossaire devra être étudiée dans les cas où certains mots employés ont un sens particulier dans le document.Afin d’identifier facilement les mots contenus dans le glossaire, un astérisque sera placé à la suite de la première occurrence du mot dans le document

7.2.1.3. Historique

Lors du changement de version d’un document, les raisons doivent être clairement explicitées dans l’historique : Il est représenté par un tableau où sont stockées le numéro de version, la date de publication de la version et les causes de modification.

7.2.1.4. Enregistrement Documents

Chaque version de document doit être sauvegardée sous cette forme : « Titre v.X » où Titre représente le titre du document et X le numéro de version.

Pour les comptes rendus de réunions, afin de pouvoir facilement les classer par date, ils doivent être sauvés sous cette forme :

« Reunion AAAAMMJJ » pour les réunions d’avancement « Reunion AAAAMMJJ – Mots Clés » pour les réunions externes au projet

avec les mots clés du but de la réunion


7.2.2. Codage

Comme nous reprenons le logiciel Open Source Merlot, nous utiliserons les mêmes normes de codage.

Ces normes correspondent essentiellement aux règles de programmation Java avec la spécificité suivante : chaque variable de classe est précédée du caractère « _ » suivi d’une minuscule.

Dans le cas où des modifications seraient réalisées dans le code de Merlot, elles devront être précédées et terminées par la chaîne « =$* » afin de pouvoir rapidement lister les modifications.Cette liste nous permettra de pouvoir réadapter facilement GenDiapo avec les versions futures de Merlot.

7.2.2.1. Gestion des versions

Depuis le second incrément, l’équipe GenDiapo a mis en place un CVS permettant aux deux stagiaires de travailler sur des mêmes fichiers. Le but du CVS est de contenir une copie valide de tous les fichiers sources de GenDiapo et de garder en mémoire les modifications entre les différentes versions de chaque fichier.

Pour cela, chaque personne doit récupérer sur la machine blackjack.imag.fr une copie du répertoire contenant tous les fichiers sources de GenDiapo et la mettre sur sa machine.

Ensuite, une fois qu’une modification a été réalisée (et testée) sur un ou plusieurs fichiers, la personne copie ses fichiers sur blackjack.imag.fr : le CVS se charge de faire évoluer les versions des fichiers modifiés et d’enregistrer les modifications.

7.2.3. Fichier exécutable

Le fichier qui permet de lancer l’outil auteur sera sous la forme d’un jar qui aura pour nom : « GenDiapo-X.Y-lettre.jar » où X.Y représente la version (ex : 1.0) et lettre représentant la stabilité de la version (ex : alpha1, alpha2 ou beta1)

7.2.4. Sauvegarde

Elle concerne tous les documents et tous les fichiers sources relatifs à GenDiapo afin de pourvoir les défaillances matérielles ou logicielles.

Cette sauvegarde sera effectuée chaque nuit par la machine blackJack.imag.fr. Elle se connectera au répertoire relatif aux documents (machine bridge.imag.fr) et au CVS des fichiers sources (machine blackjack.imag.fr) pour récupérer leur contenu.


Ensuite, ce dernier sera compressé en un seul fichier qui sera stocké sur la machine blackJack.imag.fr avec le nom suivant : «AAAAMMJJ-HHMMSS -X» où X = (Document ou Code) suivant le répertoire.

REMARQUE Cette sauvegarde pourra être également réalisée dès qu’un membre de l’équipe la jugera nécessaire

7.2.5. Mise à disposition du code

Les éléments livrables et consultables (codes et documents), du projet GenDiapo, sont rendus disponible sur le site : http://gendiapo.sourceforge.net/

7.2.5.1. Code

Le code de l’outil auteur est rendu disponible sous formes d’archive, dont le nom est :

GenDiapo-X.Y-lettre.format

Les numéros X, Y et la référence lettre correspondent à ceux de l’archive jarLe format est zip (pour la plate-forme Windows) ou tar.gz (pour la plate-forme Unix)

7.2.5.2. Code plugin

Le code permettant le développement du plugin est enregistrer sous le nom :

GenDiapo-sdk-X.Y-lettre.format

Les éléments X, Y, lettre et format utilise la même norme que précédemment.


http://www.gendiapo.free.fr/

8. Contrôle des fournisseurs

8.1. Sous-traitants

Notre système ne fait appel à aucun sous-traitant.

8.2. Co-traitants

Pour les co-traitants de la phase de publication (Cécile Guilloux et Stéphanie Gateaud), aucun contrôle de qualité ne sera fait par l’équipe GenDiapo. Elles devront cependant livrer leurs produits aux dates fixées dans le plan de développement.

Pour Cécile Guilloux, qui collabore avec l’équipe GenDiapo sur les traitements de publication, une réunion sera organisée pour spécifier les données échangées entre l’édition et la publication. En outre, si des modifications surviennent lors du développement, l’équipe GenDiapo devra les lui transmettre.

8.3. Logiciels achetés, loués ou imposés

Le choix de langages de programmation JAVA, XML et XSL permet d’utiliser des systèmes libres dont la compatibilité descendante est assurée.


9. Protection et Livraison

Pour la protection, aucune mesure particulière n’est à mettre en place car nous allons réaliser des prototypes.

Nous nous contenterons de livrer les prototypes à notre responsable aux échéances fixées dans le plan de développement.

La livraison du mois de septembre comprendra le prototype, les fichiers sources ainsi que tous les documents de référence.


10. Suivi du plan qualité

Le suivi du Plan Qualité sera réalisé au moyen des actions suivantes : Réunions Tests Procédures d’acceptation

10.1. Réunions

L’équipe de développement n’étant composée que de deux personnes et ayant le plus souvent des relations avec le responsable, la plupart des actions de vérifications se feront suivant un cycle auteur-lecteur.Pour les documents concernant la gestion de projet, ils seront en plus vérifiés par des audits avec le consultant extérieur.

Les réunions seront de trois types :

Des réunions d’avancement (équipe GenDiapo et responsable) avec pour but de :

Contrôler l’avancement du projet Vérifier que les besoins sont bien réalisés Définir les tâches suivantes Discuter des choix techniques Discuter sur les documents produits par l’équipe GenDiapo

Des réunions de présentation (équipe GenDiapo, responsable et enseignants) avec pour but de :

Valider les choix de l’équipe GenDiapo Présenter et valider les prototypes Vérifier la satisfaction du client Faire un bilan de l’avancement du projet

REMARQUE Les dates des différentes réunions sont données dans le plan de développement

Des audits (équipe GenDiapo, responsable et consultant) au nombre de trois répartis sur l’ensemble du projet, avec comme but, le contrôle de la gestion de projet de l’équipe GenDiapo

10.2. Tests

Les responsables de l’exécution des tests seront l’équipe de réalisation.


Nous allons décrire les différents types de tests qui vont être effectués ainsi que la gestion des bugs de GenDiapo.

10.2.1. Types de tests

Les tests de GenDiapo seront réalisés de trois façons différentes :

Des tests unitaires sont effectués sur le code avec l’aide du logiciel JTest et un document contenant les résultats

Des tests d’intégration réalisés à l’aide d’un document contenant les différents tests obtenus à partir du document d’architectures externes : ces tests seront réalisés sur les plates-formes Windows et Linux et les résultats seront édités dans un document spécifique suivant la version testée de GenDiapo

Des tests des enseignants qui pourront saisir et générer des documents de cours avec les versions de GenDiapo mises en ligne : Les impressions des enseignants sur le système pourront éventuellement être répertoriées dans un document

10.2.2. Gestion des bugs

La gestion des différents bugs s’effectue de deux façons différentes :

Lors du codage, chaque nouveau bug est reporté dans le fichier « TODO.txt » présent dans le CVS. Dans ce fichier, chaque bug est précédé d’un des 3 caractères suivants :

* : signifie que le bug a été corrigé + : signifie que le bug est en cours de correction - : signifie que le bug n’a pas encore été corrigé

Les différents bugs résolus ou trouvés sont également répertoriés dans un document avec une description plus précise que dans le fichier « TODO.txt » et des informations supplémentaires

10.3. Procédures d’acceptation

Les procédures d’acceptation se porteront sur le respect des critères de qualité, les documents produits et les réalisations logicielles.Ces dernières seront effectuées par tous les intervenants du projet à des degrés plus ou moins importants.


10.3.1. Respect des attributs de qualité

A l’aide des attributs de qualité énoncés dans «le Cahier des Charges», nous avons déduit une liste de critères de qualités. Pour chacun d’eux, nous donnerons les étapes importantes pour leur respect ainsi que les mesures d’évaluation de leur satisfaction.

Evolution

Etapes importantes : Les phases d’Architectures devront prendre en compte les objectifs à

long terme et la séparation des modules d’interface et des modules de données

La mise en place de plugin devra permettre également de pouvoir personnaliser GenDiapo ou de lui ajouter des traitements

Mesures :

Le temps mis par Cécile Guilloux pour intégrer le publication HTML (plugin) dans GenDiapo permettra de mesurer ce critère

Si Synergie3R et l’équipe de Merlot le permettent, ce critère peut être atteint complètement en fusionnant notre code dans celui de Merlot : la pérennité du code serait alors garantie.

Modularité

Etapes importantes : Les phases d’Architectures Externes et Internes devront permettre la

conception de modules les plus indépendants possibles de Merlot tout en conservant une relation avec ces derniers

La phase de codage devra vérifier cette indépendance

Mesure : La modularité par rapport à Merlot peut être mesurée de la façon

suivante : Le nombre total de classes (Merlot et GenDiapo) est comptabilisé, puis le nombre de classes dépendant à la fois de Merlot et de GenDiapo. Plus le rapport entre le nombre de classes dépendantes et le nombre de classes totales est faible, plus la modularité est importante : Ce critère ne peut pas être atteint complètement.

Indépendance avec les outils systèmes

Etape importante : La phase de définition des besoins définira l’ensemble des langages et

techniques à utiliser pour respecter ce critère

Mesure : La méthode pour vérifier cet attribut sera d’effectuer de tests sur une

machine Windows et une machine Unix. Les tests, dont le résultat est


différent sur les deux machines, seront considérés comme posant des problèmes de compatibilité.

Un pourcentage de compatibilité pourra être donné : Cet attribut sera donc atteint si on a 100% de compatibilité

10.3.2. Documents

Avant d’être donné en lecture au responsable, tout document doit être lu et vérifié par les deux stagiaires et validé par le responsable qualité.

Pour la validation d’un document, elle sera faite obligatoirement par notre responsable de stage avec les enseignants dans certains cas.

L’entreprise Synergie3R faisant plus du suivi, sa validation ne sera pas attendue pour passer aux phases suivantes mais son approbation sera souhaitée.

10.3.3. Réalisations Logicielles

La validation des prototypes réalisés sera faite par notre responsable, les enseignants représentant les futurs utilisateurs et l’entreprise Synergie 3R (si elle est présente).

Cela permettra de valider les prototypes et de prendre en compte les remarques de chaque partie.
