PLAN DE QUALITE DU PROJET SIRAGI 

Introduction

Eléments de qualité

Introduction

Objectif global du logiciel

 Le projet open source SIRAGI a pour but de concevoir une application permettant à une personne mal voyante ou aveugle d'utiliser de manière productive un PC  sous Windows ou Linux.  

Versions du document
Version Auteur Date Apport
0.1 Timité Hassan 30/12/2003 Création du document
0.2 Timité Hassan 10/01/2004 Mise à jour de l'ensemble du document
0.3 Timité Hassan 11/01/2004 Mise à jour du cycle de vie du logiciel
1.0 Timité Hassan 18/01/2004 Ajout d'informations sur doxygène et mise à jour des documents à produire
Retourner au sommet du document

Eléments de qualité

Cycle de vie du logiciel:

 Vu la nature risquée de notre projet,nous utiliserons le prototypage comme cycle de vie. De ce fait notre projet se découpera suivant les phases ci-dessus:
  1. Analyse
    2. phase durant laquelle tous les besoins sont spécifiés
  2. Planification servant à planifier tout le cycle de vie du logiciel
  3. Conception,phase durant laquelle les besoins sont transformés en  spécifications fonctionnelles
  4. Elaboration du prototype permettant de s'assurer que les spécifications  fonctionnelles correspondent bien aux besoins et de prendre en compte les remarques   et suggestions
  5. Développement,cette phase est celle de production des programmes et de la  documentation technique.
  6. Diffusion correspond à la phase de mise à disposition du logiciel.
  7. Support phase de support et de maintenance.
Retourner au sommet du document

Documents à produire:

  1. Le Cahier des Charges
  2. Le Plan du projet
  3. Le Plan de qualité
  4. Un document de spécification
  5. Un document de conception
  6. Un manuel utilisateur
  7. Un guide de référence
  8. Un guide d'installation
  9. Un fichier Readme
 Retourner au sommet du document

Traçabilité bidirectionnelle:

 Toute spécification dans le rapport des exigences devra se référer explicitement aux documents de base. Tout changement des exigences devra également se référer explicitement aux demandes faites par l'utilisateur avec des documents à l'appui si possible. Le rapport de spécification devra impérativement contenir les éléments suivants:   Chaque fonctionnalité décrite devra être numérotée avec un numéro de référence de style SPn où n est le numéro de la fonctionnalité. Chaque règle de gestion devra porter un numéro de type RGn où n est le numéro de la règle. Chaque état ou consultation décrite devra porter un numéro de type ETn où n est le numéro d'état. Pour garder une traçabilité des modifications dans les spécifications, chaque nouvelle version du rapport devra garder la même numérotation des SPn, RGn ou ETn. Si de nouvelles fonctionnalités sont rajoutées,elles devront avoir de nouveaux numéros. Lorsque des fonctionnalités sont supprimées,leur numéro ne devra plus être utilisée et il sera clairement mentionnée que telle fonctionnalité a disparu dans la version courante du document. Lors de la création du document de conception,les éléments suivants devront être  pris en compte: Retourner au sommet du document

Suivi des bugs:

 Vu l'importance de la détection et de la correction des bugs,nous suggérons l'utilisation de l'outil de réclamation de sourceforge.net. Cet outil permet de suivre les informations suivantes: Ce système pourra être mis à la disposition de l'utilisateur via internet. A ce propos chaque projet dispose de son propre système de suivi. Retourner au sommet du document

Normes de développement:

Modularité:

 Dans la mesure du possible chaque classe devra se trouver dans son propre fichier portant le même nom. Chaque fichier ne devra pas excédé dans la mesure du possible 300 lignes. La classe principale devra se trouver dans un fichier nommé  SIRAGI_FS_X_Y.java(X et Y déterminant bien sur la version du document).

L'entête de fichier:

 Chaque fichier devra avoir une entête contenant les informations suivantes:

L'entête de classe:

L'entête des méthodes:
  • Une brève description de la méthode et de ses paramètres

    • Commentaires:

     Chaque commentaire devra être clair et ne devra pas dépasser 2 lignes sauf cas particulier(entête notamment).

    Règles de Nom:

     Nous utiliserons les règles de nomination de Java. Additionnement chaque classe,attribut ou méthode devra avoir un nom indiquant  explicitement son rôle.

    Efficacité:

     Nous devrons nous assurer que notre logiciel soit assez efficace  pour tourner sur une machine de puissance moyenne.  

    Livrables:

     A la fin de la phase développement,les produits suivants devront  être fournis: (*):Doxygene est une application générant automatiquement de la documentation sous  forme de page web incluant des réferences croisées,des diagrammes,l'hiérarchie des  classes et des facilités de recherche.

    Retourner au sommet du document

    Gestion des configurations:

     La gestion de configuration permet de gérer la codification,les versions,le stockage et l'intégrité des produits crées lors de la vie d'un produit logiciel. Ces produits sont de deux types:les documents et les applications. Les documents se présentent sous la forme de texte formaté au format papier ou électronique. Dans notre cas nous préconiserons le format html pour la version électronique  de documents. Les programmes se présentent sous forme de code source et sous forme d'exécutable.

    Version des produits:

     Chaque produit possèdera un numéro de version. Le numéro de version des documents sera codé de la façon suivante:X.Y. X est le numéro de version majeure et varie chaque fois qu'est effectuée une  version majeure. Y est le numéro de version mineure et est incrémentée chaque fois qu'est  effectuée une mise à jour mineure. Le numéro de version des applications sera codée de la façon suivante: Les versions alpha seront codées comme suit: 0.Y.Z avec Y commençant à 0 et Z à 1. A chaque modification majeure du logiciel Y sera incrémenté. A chaque modification mineure du logiciel Z sera incrémenté. Les versions bêta seront codées comme suit: X.Y.Z avec X commençant à 1,Y fixé,Z s'incrémentant à chaque nouvelle version. A la fin d'une phase de tests Bêta Y sera incrémentée et la version finale produite  sera de la forme X.Y.  

    Codification des documents:

     Chaque document possèdera les attributs suivants: La forme électronique du document possèdera les attributs supplémentaires  suivants:
  • Nom de fichier
  • Extension du fichier
    •   Pour une bonne gestion des documents,tous les attributs cités devront apparaître  clairement sur le document. Les références des documents seront codées comme suit: Code_X_Y Ou X_Y détermine la version et Code est un des codes suivants,déterminant  le type de document:
    Type de document Code associé
    Plan du projet PL
    Plan de qualité PQ
    Manuel utilisateur MU
    Guide de référence GR
    Guide d'installation GI
    Readme RM
    Install IL
    Fichiers Source FS
    Résultat des test de qualité RTQ
    Procédure et standards PS
    Documentation générale DG
    Rapport de Conclusion du Projet RCP
    Les versions électroniques des documents seront de la forme Nom_Code_X_Y.ext. Ou Nom est le nom du fichier et ext son extension.

    Codification des applications:

  • Une référence
  • Une version
  • Une date de création
  • Une date de dernière mise à jour/li>
  • Un historique des mises à jour
  • La liste des auteurs
  • Nom de fichier
  • Liste des fichiers sources et/ou librairies nécessaires pour compiler l'application
  • Extension du fichier
    • Les références des applications seront de la forme: numero_X_Y_Z:pour les versions alpha et bêta. numero_X_Y:pour les versions finales. Ou numéro est le numéro du module tributaire de l'application. Les fichiers correspondant aux applications seront de la forme: Nom_numero_X_Y_Z.ext/Nom_numero_X_Y.ext où Nom est le nom du fichier et ext l'extension de  l'application.

    Stockage des produits:

    Les produits seront stockés sur le serveur de sourceforge.net dans le dossier  relatif à notre projet.  Le dit dossier contiendra 2 sous-dossiers:  Documents et Applications.  Documents contiendront les documents.  Le dossier applications contiendra 2 sous-dossier:  Le dossier source qui contiendra les fichiers sources.  Le dossier runtime(executable) qui contiendra les applications sous format exe.  Par souci de clarté nous stockerons de préférence les versions finales des fichiers.   Retourner au sommet du document

    Outils de développement et plateformes utilisées:

     Retourner au sommet du document

    Corrections et tests:

    Corrections:

     Tout document ou programme doit être revu par une personne autre que l'auteur (ou les auteurs). Cette méthode permet de juger de manière objective le dit document ou programme et de vérifier sa conformité avec les normes établies par l'équipe de qualité. La correction pourra être effectuée par l'auteur ou les auteurs(de préférence) ou  par un autre membre du projet.

    Tests:

     Nous aurons à effectuer 4 types de tests: Retourner au sommet du document