1. PAQL GPA Auteur : AAB Rf : MU_GPA_001.V1.00 2012/2013 Plan Assurance Qualit Logicielle Gestion d'un parc automobile Andrea, Arnold, Bellon Objet Version Auteur Date Rdaction initiale 0.70 A.A.B 27/11/12 Modifications 0.90 A.A.B 08/01/13 Validation 1.00 A.A.B 18/01/13

2. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 2 Sommaire 1. But, porte, responsabilit.................................................................................................................. 3 1.1 Objectif du document.................................................................................................................... 3 1.2 Porte du document...................................................................................................................... 3 1.3 Responsabilits associes.............................................................................................................. 3 1.4 Procdure d'volution du PAQL .................................................................................................... 3 1.5 Dveloppement du projet............................................................................................................. 4 2. Documentation utilise....................................................................................................................... 4 2.1 Documents de rfrence............................................................................................................... 4 3. Terminologie........................................................................................................................................ 4 4. Organisation ........................................................................................................................................ 5 5. Cycle de vie.......................................................................................................................................... 7 5.1 Motivation du choix ...................................................................................................................... 7 5.2 Description des tapes du cycle de vie ......................................................................................... 8 5.3 Phases du cycle de vie ................................................................................................................... 9 6. Planning de Gantt.............................................................................................................................. 10 7. Documentation produite................................................................................................................... 10 8. Gestion de la configuration............................................................................................................... 11 9. Gestion des modifications................................................................................................................. 12 10. Les modifications............................................................................................................................. 13 11. Mthodes, outils, rgles et normes................................................................................................. 14 12. Convention de nommage................................................................................................................ 15 13. Assurance qualit et contrle ......................................................................................................... 17 13. Reproduction, production, livraison................................................................................................ 18 13.1 procdure de reproduction....................................................................................................... 18 13.2 Protection du site ...................................................................................................................... 18 13.3 Livraison et installation ............................................................................................................. 18 14. Suivi de l'application du PAQL......................................................................................................... 19 14.1 Validation des documents......................................................................................................... 19 14.2 Relecture ................................................................................................................................... 19 3. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 3 1. But, porte, responsabilit 1.1 Objectif du document Le plan dassurance qualit (PAQL) a pour but de dfinir les mthodes et outils utiliss par le projet, ainsi que les mesures prendre et les tapes pour contrler et sassurer de la qualit du projet. Tout document produit sera soumis au contrle de qualit. Il devra tre conforme aux rgles dfinies dans ce document. Tout document non conforme devra tre corrig. 1.2 Porte du document Ce document est destin : A Michel Belkacem Au jury du Master 1 pour la prsentation de projet A lquipe du projet : Arnold, Bellon, Andrea 1.3 Responsabilits associes Le responsable qualit est charg de la rdaction du prsent PAQL ainsi que de veiller son application et son volution, en collaboration avec le chef de projet. Cest lui de dcider des actions entreprendre si le PAQL nest pas appliqu. 1.4 Procdure d'volution du PAQL Le PAQL est labor au dbut du projet. A chaque tape, il est susceptible dtre modifi, auquel cas la modification sera indique dans la table de lhistorique. 4. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 4 1.5 Dveloppement du projet Lingnieur Andrea est charg dlaborer le dossier de conception dans sa totalit et responsable de la rdaction des documents du projet. Lingnieur Arnold est charg dlaborer le dossier de spcification dans sa totalit et responsable de la validation, les diffrents documents et de l'ensemble de processus. Lingnieur Bellon est charg dlaborer le Plan d'AssuranceQualitLogicielle et responsable du Contrle AQ 2. Documentation utilise 2.1 Documents de rfrence Le tableau suivant rcapitule les principales sources documentaires qui seront utilises dans le cadre de ce projet. BUT SOURCE Rdaction des documents Cours de Mr. BELKACEM Dveloppement PHP Documentation PHP Dveloppement de la nouvelle version Documentation produite pour la version prcdente 3. Terminologie Les termes suivants sont les termes spcifiques utiliss dans le PAQL. CdC : Cahier des charges CdB : Cahier de bord DCG : Dossier de Conception Globale DCD : Document de Conception Dtaille DES : Dossier de Spcifications Externes PAQL : Plan dAssurance Qualit Logiciel PDL : Plan de Dveloppement Logiciel MOA : Maitrise douvrage MOAD : Maitrise douvrage Dlgue MOE : Maitrise duvre MOE : Maitrise duvre dlgue CV : Cycle de Vie 5. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 5 4. Organisation Maitrise douvrage La maitrise d'ouvrage reprsente l'ensemble des concessionnaires automobile qui possdent des points de vente. Les intervenants de la MOA Une enqutes sera effectu avec des questionnaires au niveau des employs des concessionnaires cibls. Maitrise duvre La maitrise douvrage est lquipe compose de Andrea, Bellon et Arnold ; tudiants linstitut limayrac en premire anne master chef de projet informatique. Chef de projet L'quipe projet est compose de Andrea, Arnold et Bellon LOUBAKI, tous responsable: de la planification du projet. du contrle de l'avancement du projet. de la mobilisation des moyens ncessaire la coordination des travaux de chacun. Affectation des tches. Suivi des tches. Coordination technique. Responsable qualit (AQ) Les responsables de qualit tout le long du projet sont Andrea, Arnold et Bellon LOUBAKI, nous avons pour objectifs: de dfinir les rgles de retour en arrire et les procdures de modification veiller la diffusion et au respect des rgles particulires au projet grer l'volution du PAQL 6. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 6 Rdacteur Lerdacteur du document, reprsent par Andrea, est charg de rdig les diffrents documents; il utilise un langage clair et pertinent adapt au public concern. Le rdacteur est capable d'excuter une grande varit de tches : il mne des tudes sur la documentation de l'entreprise et tout particulirement la documentation technique, il recueille les besoins de ses interlocuteurs, il joue le rle d'interface entre l'ingnieur, les techniciens et l'utilisateur, il ralise le travail de mise en forme sur diffrents supports, il rdige les documents pour les concepteurs comme pour les utilisateurs. Validateur Le validateur est reprsent par Arnold, il a pour rle: dapprouver les diffrents documents et de l'ensemble de validation processus vrifier l'ensemble des saisies contrler la conformit du fichier dpos Communication Le mode de communication privilgier entre les diffrents intervenants est le courrier lectronique. Les documents contractuels) devront tre prsents la matrise d'ouvrage en version papier afin qu'elle puisse conserver une version signe et approuve par les deux parties desdits documents. Les documents attachs l'envoi de courriers lectroniques seront au format Microsoft Office. Ces documents ne pourront tre considrs comme des documents finaux. Des enqutes terrain afin de connaitre la gestion des diffrents sites l'aide de questionnaires. 7. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 7 5. Cycle de vie 5.1 Motivation du choix Chaque attente du client peut tre atteinte indpendamment des autres. Lutilisation dun cycle de vie permettant de dvelopper chacun des modules de bout en bout sparment est donc approprie. Le produit final sera livr en lots successifs. Le cycle de vie choisi est un cycle incrmental. 8. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 8 5.2 Description des tapes du cycle de vie Spcifications : Cette tape permet de dfinir larchitecture interne du logiciel, dacqurir et dinstaller les outils de programmation Conception et Codage : Cette tape regroupe la phase de conception dtaille et de codage. Elle permet de dtailler prcisment la conception globale par module afin de pouvoir les dvelopper et prparer les tests unitaires. Le codage permet de traduire la conception dtaille en un programme. Tests : Cette tape permet de tester le logiciel dans lordre suivant. Tests dintgration, tests unitaires, tests de validation. Les rsultats obtenus permettront de modifier si ncessaire le logiciel. Mise en production : Livraison du logiciel final. Maintenance : Phase de surveillance et de stabilit du logiciel. 9. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 9 5.3 Phases du cycle de vie 10. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 10 6. Planning de Gantt VOIR ANNEXE 7. Documentation produite Le tableau ci-dessous fait linventaire des documents fournir tout au long du projet, ainsi que leur statut. Document Statut CDC Livrable PAQL Livrable Dossier de Spcifications Livrable Plan de test Livrable Jeu de test Livrable Manuel utilisateur Livrable Dossier de conception Livrable Code source Priv Description des diffrents statuts : Livrable : Doit tre fournit au client Consultable : Peut tre consult par le client Priv : Destin l'quipe du projet uniquement 11. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 11 8. Gestion de la configuration La configuration est l'ensemble des lments suivants : code source excutable, outils de dveloppement et de test utiliss, documents et donnes. Outils de travail collaboratif Pour grer le travail collaboratif, nous allons utiliser GitHub. GitHub est un service web d'hbergement et de gestion de dveloppement de logiciels permettant chaque dveloppeur de travailler sparment puis de faire des intgrations par la suite. Lavantage est que lon a une trace de chaque version et des modifications apportes par chaque dveloppeur. Le retour une version prcdente en cas de problme est facilit. Gestion des documents Les documents est fichier seront stocks dans des rpertoires. (Voir lorganisation dans les dossiers (nomm Dispocar) fournis avec le PAQL). 12. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 12 Environnement technique Le dveloppement sera effectu sous environnement Windows (Windows seven ). Lapplication sera ralise sur WampServer (WAMP signifiant Windows Apache Mysql PHP), qui est une plate-forme de dveloppement Web pour des applications Web dynamiques laide du serveur Apache2, du langage de scripts PHP(on utilisera KOMODO IDE6 et Notpad++) et dune base de donnes MySQL. Il possde galement PHPMyAdmin et pour grer plus facilement vos base de donnes. A cela est ajout le Framework Cakephp dans sa dernire version, sur lequel nous allons dvelopper en grande partie notre application. Il offre un dveloppement rapide pour PHP qui fournit une architecture extensible pour dvelopper, maintenir et dployer des applications. Utilisant des motifs de conception bien connus tels ModelVueContrleur (MVC) et mapping-objet-relationnel (ORM) ainsi que le paradigme "convention plutt que configuration", CakePHP rduit les cots de dveloppement et aide les dveloppeurs crire moins de code. 9. Gestion des modifications Procdure de modification Les modifications peuvent avoir deux origines : Dtection d'une anomalie Demande d'volution Dans le cas d'une dtection d'anomalie, il faut en trouver la source puis la corriger dans les plus brefs dlais. Dans le cas d'une demande d'volution du logiciel par le client, il faut dans un premier tempsraliser une tude de faisabilit, pour ensuite modifier le logiciel en consquence. Les membres de la MOE (Mise en uvre) sont responsables de la mise en uvre de ces modifications. Rfrences et versions Les rfrences et les versions respecteront une nomenclature de type numrotation 3 chiffres. Exemple de version : 1.2.3 Si les modifications ne sont pas importante, on incrmente le denier chiffre droite. Si les modifications sont moyennes ou grandes, on incrmente respectivement et les chiffres des positions prcdentes deviennent 0 (zro) : Version : 0.0.2 13. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 13 0.0.3 modification mineure. 1.2.1 modification moyenne. Exemple de rfrence : PAQL_LRH_001.V0.0.1 Les deux premiers blocks reprsente les la terminologie du document et celle de lapplication. Le premier groupe de chiffre reprsente lID du logiciel, et le dernier groupe la version. 10. Les modifications Quand une anomalie majeure est dtecte dans le fonctionnement du systme, une correction doit tre faite rapidement. Le client peut aussi dcider de faire voluer lapplication, mais dans ce dernier cas, lquipe de projet doit donner son accord et surtout approuver la faisabilit de ces modifications dans les dlais impartis. Tout cela entraine un changement de version. Trois cas peuvent ncessiter un changement de version : Une nouvelle livraison de l'application ou du document : On incrmente le numro de version. Les numros de rvision et de correctionreviennent zro. Une volution : On incrmente le numro de rvision. Le numro de correction revient zro. Une correction d'anomalie(s) : On incrmente le numro de correction 14. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 14 11. Mthodes, outils, rgles et normes Mthodes La mthodologie UML sera utilise pour toutes les phases d'analyse de ce projet. Les testsseront prpars pendant les premires tapes du projet, savoir : Analyse des besoins : Prparation des tests d'acceptation Spcifications externes : Prparation des tests systmes Conception globale : Prparation des tests d'intgration Conception dtaille : Prparation des tests unitaires Ces tests devront tre prpars au fur et mesure de l'avancement du projet. Ainsi, chaquetape, ils devront tre rpertoris dans le document PlanDeTests*.odt . Outils Le tableau suivant rcapitule les outils qui seront utiliss dans le cadre de ce projet. Fonctions Outils Editeur de texte Notpad++) Editeur UML ArgoUML Environnement de dveloppement Wamp, CakePHP Dveloppement collaboratif GitHub Gestion de projets Cocomo Rgles de prsentation Tous les documents lis ce projet devront respecter un mme modle : Page de garde Nom du projet Nom du document Date de dernire modification Numro de version Auteur(s) Cartouche d'entte : Logo Bull, nom du document, logo du projet 15. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 15 Pages suivantes Cartouche d'entte : Logo Bull, nom du document, logo du projet Numro de page Nombre de pages 12. Convention de nommage Pour les rgles de codage, nous allons respecter celle de Cakephp, qui sont bien dfinies et permettent doptimiser les fonctionnalits de Cakephp. Conventions pour le nom des fichiers et des classes Pour une classe VehiculeClasse, le fichier devrait tre nomm vehicule_classe.php. La classe Contrleur vehicule_controller.php (notez l'ajout de _controller ) La classe Vue vue_vehicules devrait se trouver dans un fichier nomm view.ctp Chaque fichier serait situe dans ou sous les rpertoires appropris (qui peuvent tre dans un sous- rpertoire) du rpertoire principal App de cakephp. Conventions pour les modles Les noms de classe de modle sont au singulier et commencent par une majuscule : Vehicule, VehiculePetit. Les noms de tables en base de donnes correspondant aux modles CakePHP sont au pluriel et utilisent le caractre soulign (underscore). Les tables correspondantes aux modles mentionns ci- dessus seront donc vehicules, vehicule_petits. Les cls trangres des relations hasMany, belongsTo ou hasOne sont reconnues par dfaut grce au nom (singulier) de la table associe, suivi de _id. Les tables de jointure utilises dans les relations hasAndBelongsToMany (HABTM) entre modles devraient tre nommes d'aprs le nom des tables des modles qu'elles unissent, dans l'ordre. Toutes les tables avec lesquelles les modles de CakePHP interagissent ( l'exception des tables de jointure), ncessitent une cl primaire simple pour identifier chaque ligne de manire unique. CakePHP n'accepte pas les cls primaires composes. 16. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 16 Conventions pour les Contrleurs Les noms des classes de contrleur sont au pluriel par 'Controller'. Exemple : VehiculesController, VehiculePetitsController. Convention pour les Vues Les fichiers de gabarits de vue (Template) sont nomms d'aprs les fonctions du contrleur qu'elles affichent, sous une forme "souligne" (underscored). La mthode soyezPret() de la classe VehiculesController cherchera un gabarit de vue dans : /app/views/personnes/soyez_pret.ctp Le schma classique est "/app/views/contrleur/nom_de_fonction_avec_underscore.ctp". En utilisant les conventions CakePHP dans le nommage des diffrentes parties de lapplication, nous gagnons en fonctionnalit et facilit de codage. Voici un exemple rcapitulant les conventions abordes : Nom de la table dans la base de donnes : vehicules Classe du Modle : Vehicule, trouve dans /app/models/vehicule.php Classe du Contrleur : VehiculesController, trouve dans le rpertoire/app/controllers/vehicules_controller.php Gabarit de la Vue : trouv dans /app/views/vehicules/index.ctp En utilisant ces conventions, CakePHP sait qu'une requte http://exemple.com/vehicules/ sera lie un appel la fonction index() du Contrleur VehiculesController, dans lequel le modle Vehicule est automatiquement disponible (et automatiquement li la table vehicules dans la base) et rendue dans un fichier. 17. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 17 13. Assurance qualit et contrle Le tableau ci-dessous rsume les principales mesures d'assurances et de contrle qualit, elles sont tries par ordre d'importance selon la norme : NF ISO/CEI 9126 (de A, le plus exigent, Z le moins exigent). Caractristiques 1 Rutilisabilit Remarques Etapes concernes Exigence L'application doit pouvoir tre adapt sur n'importe quelle station distante Conception prliminaire Dveloppement C Caractristiques 2 volutivit et Maintenabilit Remarques Etapes concernes Exigence L'ajout de nouvelles fonctionnalits de ne doit poser aucun problmes Tout le cycle de production Phase de dveloppement B Caractristiques 3 Souplesse Remarques Etapes concernes Exigence Capable de tourner sur nimporte quelle station de travail, serveur web, systme dexploitation Tests Livraison A 18. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 18 Caractristiques 4 Fiabilit Remarques Etapes concernes Exigence En cas d'chec ou d'erreur renouvellera l'change Conception prliminaire et dtaille Dveloppement Tests B 13. Reproduction, production, livraison 13.1 procdure de reproduction Aucune procdure de reproduction particulire n'est prvu. 13.2 Protection du site Les commerciaux et l'administrateur auront accs leur environnement par l'intermdiaire des logins et mots de passe . 13.3 Livraison et installation L'accs au site final sera remis l'quipe commerciale. Lors de la livraison du produit, le manuel utilisateur sera livr afin de permettre des personnes trangres l'quipe d'utiliser le produit sans difficults. 19. PAQL GPA Auteur : AAB Rf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 19 14. Suivi de l'application du PAQL 14.1 Validation des documents Tous les documents rdigs seront relus par le responsable qualit et modifis en cas de non conformit avec le prsent Plan d'Assurance Qualit Logicielle. De la mme faon, les documents de type livrables seront relus et devront tre valids par le maitre d'uvre (Michel Belkacem). 14.2 Relecture La lecture croise sera effectue au minimum par les 2 membres de l'quipe de dveloppement (l'un rdige, l'autre relit). L'auteur d'un document assure la ralisation des corrections proposs par les relecteurs et gre le changement des numros de versions. L'enchanement des tches est le suivant : Cration du document Diffusion aux relecteurs Intgration des modifications par l'auteur et modification ventuelle du numro de version en fonction des modifications effectues Validation finale