Paql intégration v1.00

795 vues

Publié le

Projet : Création d'un logiciel de gestion de parc automobile.
CPI. Institut Limayrac, Toulouse

1 commentaire
1 j’aime
Statistiques
Remarques
  • Avec plus de 700 véhicules en gestion externalisée, Buy Made Easy adopte une approche résolument NEUTRE et INDÉPENDANTE vis-à-vis des financeurs et constructeurs.

    Gestion de parc automobile dans sa globalité, Buy Made Easy prend en charge votre flotte à 100% avec un tarif unique mensuel par véhicule afin d'adapter le budget aux variations de votre activité.

    http://www.buymadeeasy.com/nos-metiers-solutions/consulting-en-achats/flotte-automobile.html#gestions-de-parc
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
795
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
26
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Paql intégration v1.00

  1. 1. PAQL GPA Auteur : AAB Réf : MU_GPA_001.V1.00 2012/2013 Plan Assurance Qualité Logicielle Gestion d'un parc automobile Andrea, Arnold, Bellon Objet Version Auteur Date Rédaction 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. 2. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 2 Sommaire 1. But, portée, responsabilité.................................................................................................................. 3 1.1 Objectif du document.................................................................................................................... 3 1.2 Portée du document...................................................................................................................... 3 1.3 Responsabilités associées.............................................................................................................. 3 1.4 Procédure d'évolution du PAQL .................................................................................................... 3 1.5 Développement du projet............................................................................................................. 4 2. Documentation utilisée....................................................................................................................... 4 2.1 Documents de référence............................................................................................................... 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. Méthodes, outils, règles et normes................................................................................................. 14 12. Convention de nommage................................................................................................................ 15 13. Assurance qualité et contrôle ......................................................................................................... 17 13. Reproduction, production, livraison................................................................................................ 18 13.1 procédure 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. 3. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 3 1. But, portée, responsabilité 1.1 Objectif du document Le plan d’assurance qualité (PAQL) a pour but de définir les méthodes et outils utilisés par le projet, ainsi que les mesures à prendre et les étapes pour contrôler et s’assurer de la qualité du projet. Tout document produit sera soumis au contrôle de qualité. Il devra être conforme aux règles définies dans ce document. Tout document non conforme devra être corrigé. 1.2 Portée du document Ce document est destiné :  A Michel Belkacem  Au jury du Master 1 pour la présentation de projet  A l’équipe du projet : Arnold, Bellon, Andrea 1.3 Responsabilités associées Le responsable qualité est chargé de la rédaction du présent PAQL ainsi que de veiller à son application et son évolution, en collaboration avec le chef de projet. C’est à lui de décider des actions à entreprendre si le PAQL n’est pas appliqué. 1.4 Procédure d'évolution du PAQL Le PAQL est élaboré au début du projet. A chaque étape, il est susceptible d’être modifié, auquel cas la modification sera indiquée dans la table de l’historique.
  4. 4. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 4 1.5 Développement du projet  L’ingénieur Andrea est chargé d’élaborer le dossier de conception dans sa totalité et responsable de la rédaction des documents du projet.  L’ingénieur Arnold est chargé d’élaborer le dossier de spécification dans sa totalité et responsable de la validation, les différents documents et de l'ensemble de processus.  L’ingénieur Bellon est chargé d’élaborer le Plan d'AssuranceQualitéLogicielle et responsable du Contrôle AQ 2. Documentation utilisée 2.1 Documents de référence Le tableau suivant récapitule les principales sources documentaires qui seront utilisées dans le cadre de ce projet. BUT SOURCE Rédaction des documents Cours de Mr. BELKACEM Développement PHP Documentation PHP Développement de la nouvelle version Documentation produite pour la version précédente 3. Terminologie Les termes suivants sont les termes spécifiques utilisés dans le PAQL.  CdC : Cahier des charges  CdB : Cahier de bord  DCG : Dossier de Conception Globale  DCD : Document de Conception Détaillée  DES : Dossier de Spécifications Externes  PAQL : Plan d’Assurance Qualité Logiciel  PDL : Plan de Développement Logiciel  MOA : Maitrise d’ouvrage  MOAD : Maitrise d’ouvrage Déléguée  MOE : Maitrise d’œuvre  MOE : Maitrise d’œuvre déléguée  CV : Cycle de Vie
  5. 5. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 5 4. Organisation Maitrise d’ouvrage La maitrise d'ouvrage représente l'ensemble des concessionnaires automobile qui possèdent des points de vente. Les intervenants de la MOA Une enquêtes sera effectué avec des questionnaires au niveau des employés des concessionnaires ciblés. Maitrise d’œuvre La maitrise d’ouvrage est l’équipe composée de Andrea, Bellon et Arnold ; étudiants à l’institut limayrac en première année master chef de projet informatique. Chef de projet L'équipe projet est composée de Andrea, Arnold et Bellon LOUBAKI, tous responsable:  de la planification du projet.  du contrôle de l'avancement du projet.  de la mobilisation des moyens nécessaire à la coordination des travaux de chacun.  Affectation des tâches.  Suivi des tâches.  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 définir les règles de retour en arrière et les procédures de modification  veiller à la diffusion et au respect des règles particulières au projet  gérer l'évolution du PAQL
  6. 6. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 6 Rédacteur Lerédacteur du document, représenté par Andrea, est chargé de rédigé les différents documents; il utilise un langage clair et pertinent adapté au public concerné. Le rédacteur est capable d'exécuter une grande variété de tâches :  il mène des études sur la documentation de l'entreprise et tout particulièrement la documentation technique,  il recueille les besoins de ses interlocuteurs,  il joue le rôle d'interface entre l'ingénieur, les techniciens et l'utilisateur,  il réalise le travail de mise en forme sur différents supports,  il rédige les documents pour les concepteurs comme pour les utilisateurs. Validateur Le validateur est représenté par Arnold, il a pour rôle:  d’approuver les différents documents et de l'ensemble de validation processus  vérifier l'ensemble des saisies  contrôler la conformité du fichier déposé Communication Le mode de communication à privilégier entre les différents intervenants est le courrier électronique. Les documents contractuels) devront être présentés à la maîtrise d'ouvrage en version papier afin qu'elle puisse conserver une version signée et approuvée par les deux parties desdits documents. Les documents attachés à l'envoi de courriers électroniques seront au format Microsoft Office. Ces documents ne pourront être considérés comme des documents finaux. Des enquêtes terrain afin de connaitre la gestion des différents sites à l'aide de questionnaires.
  7. 7. PAQL GPA Auteur : AAB Réf : 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 indépendamment des autres. L’utilisation d’un cycle de vie permettant de développer chacun des modules de bout en bout séparément est donc appropriée. Le produit final sera livré en lots successifs. Le cycle de vie choisi est un cycle incrémental.
  8. 8. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 8 5.2 Description des étapes du cycle de vie Spécifications : Cette étape permet de définir l’architecture interne du logiciel, d’acquérir et d’installer les outils de programmation Conception et Codage : Cette étape regroupe la phase de conception détaillée et de codage. Elle permet de détailler précisément la conception globale par module afin de pouvoir les développer et préparer les tests unitaires. Le codage permet de traduire la conception détaillée en un programme. Tests : Cette étape permet de tester le logiciel dans l’ordre suivant. Tests d’intégration, tests unitaires, tests de validation. Les résultats obtenus permettront de modifier si nécessaire le logiciel. Mise en production : Livraison du logiciel final. Maintenance : Phase de surveillance et de stabilité du logiciel.
  9. 9. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 9 5.3 Phases du cycle de vie
  10. 10. PAQL GPA Auteur : AAB Réf : 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 l’inventaire des documents à fournir tout au long du projet, ainsi que leur statut. Document Statut CDC Livrable PAQL Livrable Dossier de Spécifications Livrable Plan de test Livrable Jeu de test Livrable Manuel utilisateur Livrable Dossier de conception Livrable Code source Privé  Description des différents statuts : – Livrable : Doit être fournit au client – Consultable : Peut être consulté par le client – Privé : Destiné à l'équipe du projet uniquement
  11. 11. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 11 8. Gestion de la configuration La configuration est l'ensemble des éléments suivants : code source exécutable, outils de développement et de test utilisés, documents et données. Outils de travail collaboratif Pour gérer le travail collaboratif, nous allons utiliser GitHub. GitHub est un service web d'hébergement et de gestion de développement de logiciels permettant à chaque développeur de travailler séparément puis de faire des intégrations par la suite. L’avantage est que l’on a une trace de chaque version et des modifications apportées par chaque développeur. Le retour à une version précédente en cas de problème est facilité. Gestion des documents Les documents est fichier seront stockés dans des répertoires. (Voir l’organisation dans les dossiers (nommé Dispocar) fournis avec le PAQL).
  12. 12. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 12 Environnement technique Le développement sera effectué sous environnement Windows (Windows seven ). L’application sera réalisée sur WampServer (WAMP signifiant Windows Apache Mysql PHP), qui est une plate-forme de développement Web pour des applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP(on utilisera KOMODO IDE6 et Notpad++) et d’une base de données MySQL. Il possède également PHPMyAdmin et pour gérer plus facilement vos base de données. A cela est ajouté le Framework Cakephp dans sa dernière version, sur lequel nous allons développer en grande partie notre application. Il offre un développement rapide pour PHP qui fournit une architecture extensible pour développer, maintenir et déployer des applications. Utilisant des motifs de conception bien connus tels Model–Vue–Contrôleur (MVC) et mapping-objet-relationnel (ORM) ainsi que le paradigme "convention plutôt que configuration", CakePHP réduit les coûts de développement et aide les développeurs à écrire moins de code. 9. Gestion des modifications Procédure de modification Les modifications peuvent avoir deux origines : ➢Détection d'une anomalie ➢Demande d'évolution Dans le cas d'une détection d'anomalie, il faut en trouver la source puis la corriger dans les plus brefs délais. Dans le cas d'une demande d'évolution du logiciel par le client, il faut dans un premier tempsréaliser une étude de faisabilité, pour ensuite modifier le logiciel en conséquence. Les membres de la MOE (Mise en œuvre) sont responsables de la mise en œuvre de ces modifications. Références et versions Les références et les versions respecteront une nomenclature de type numérotation à 3 chiffres. Exemple de version : 1.2.3 Si les modifications ne sont pas importante, on incrémente le denier chiffre à droite. Si les modifications sont moyennes ou grandes, on incrémente respectivement et les chiffres des positions précédentes deviennent 0 (zéro) : Version : 0.0.2
  13. 13. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 13 0.0.3 modification mineure. 1.2.1 modification moyenne. Exemple de référence : PAQL_LRH_001.V0.0.1 Les deux premiers blocks représente les la terminologie du document et celle de l’application. Le premier groupe de chiffre représente l’ID du logiciel, et le dernier groupe la version. 10. Les modifications Quand une anomalie majeure est détectée dans le fonctionnement du système, une correction doit être faite rapidement. Le client peut aussi décider de faire évoluer l’application, mais dans ce dernier cas, l’équipe de projet doit donner son accord et surtout approuver la faisabilité de ces modifications dans les délais impartis. Tout cela entraine un changement de version. Trois cas peuvent nécessiter un changement de version : ➢Une nouvelle livraison de l'application ou du document : ✔On incrémente le numéro de version. Les numéros de révision et de correctionreviennent à zéro. ➢Une évolution : ✔On incrémente le numéro de révision. Le numéro de correction revient à zéro. ➢Une correction d'anomalie(s) : ✔On incrémente le numéro de correction
  14. 14. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 14 11. Méthodes, outils, règles et normes Méthodes La méthodologie UML sera utilisée pour toutes les phases d'analyse de ce projet. Les testsseront préparés pendant les premières étapes du projet, à savoir : ➢Analyse des besoins : Préparation des tests d'acceptation ➢Spécifications externes : Préparation des tests systèmes ➢Conception globale : Préparation des tests d'intégration ➢Conception détaillée : Préparation des tests unitaires Ces tests devront être préparés au fur et à mesure de l'avancement du projet. Ainsi, à chaqueétape, ils devront être répertoriés dans le document « PlanDeTests*.odt ». Outils Le tableau suivant récapitule les outils qui seront utilisés dans le cadre de ce projet. Fonctions Outils Editeur de texte Notpad++) Editeur UML ArgoUML Environnement de développement Wamp, CakePHP Développement collaboratif GitHub Gestion de projets Cocomo Règles de présentation Tous les documents liés à ce projet devront respecter un même modèle : ➢Page de garde ✔Nom du projet ✔Nom du document ✔Date de dernière modification ✔Numéro de version ✔Auteur(s) ✔Cartouche d'entête : Logo Bull, nom du document, logo du projet
  15. 15. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 15 ➢Pages suivantes ✔Cartouche d'entête : Logo Bull, nom du document, logo du projet ✔Numéro de page ✔Nombre de pages 12. Convention de nommage Pour les règles de codage, nous allons respecter celle de Cakephp, qui sont bien définies et permettent d’optimiser les fonctionnalités 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 Contrôleur 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 située dans ou sous les répertoires appropriés (qui peuvent être dans un sous- répertoire) du répertoire principal App de cakephp. Conventions pour les modèles Les noms de classe de modèle sont au singulier et commencent par une majuscule : Vehicule, VehiculePetit. Les noms de tables en base de données correspondant aux modèles CakePHP sont au pluriel et utilisent le caractère souligné (underscore). Les tables correspondantes aux modèles mentionnés ci- dessus seront donc vehicules, vehicule_petits. Les clés étrangères des relations hasMany, belongsTo ou hasOne sont reconnues par défaut grâce au nom (singulier) de la table associée, suivi de _id. Les tables de jointure utilisées dans les relations hasAndBelongsToMany (HABTM) entre modèles devraient être nommées d'après le nom des tables des modèles qu'elles unissent, dans l'ordre. Toutes les tables avec lesquelles les modèles de CakePHP interagissent (à l'exception des tables de jointure), nécessitent une clé primaire simple pour identifier chaque ligne de manière unique. CakePHP n'accepte pas les clés primaires composées.
  16. 16. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 16 Conventions pour les Contrôleurs Les noms des classes de contrôleur sont au pluriel par 'Controller'. Exemple : VehiculesController, VehiculePetitsController. Convention pour les Vues Les fichiers de gabarits de vue (Template) sont nommés d'après les fonctions du contrôleur qu'elles affichent, sous une forme "soulignée" (underscored). La méthode soyezPret() de la classe VehiculesController cherchera un gabarit de vue dans : /app/views/personnes/soyez_pret.ctp Le schéma classique est "/app/views/contrôleur/nom_de_fonction_avec_underscore.ctp". En utilisant les conventions CakePHP dans le nommage des différentes parties de l’application, nous gagnons en fonctionnalité et facilité de codage. Voici un exemple récapitulant les conventions abordées : Nom de la table dans la base de données : vehicules Classe du Modèle : Vehicule, trouvée dans /app/models/vehicule.php Classe du Contrôleur : VehiculesController, trouvée dans le répertoire/app/controllers/vehicules_controller.php Gabarit de la Vue : trouvé dans /app/views/vehicules/index.ctp En utilisant ces conventions, CakePHP sait qu'une requête à http://exemple.com/vehicules/ sera liée à un appel à la fonction index() du Contrôleur VehiculesController, dans lequel le modèle Vehicule est automatiquement disponible (et automatiquement lié à la table vehicules dans la base) et rendue dans un fichier.
  17. 17. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 17 13. Assurance qualité et contrôle Le tableau ci-dessous résume les principales mesures d'assurances et de contrôle qualité, elles sont triées par ordre d'importance selon la norme : NF ISO/CEI 9126 (de A, le plus exigent, à Z le moins exigent). Caractéristiques 1 Réutilisabilité Remarques Etapes concernées Exigence L'application doit pouvoir être adapté sur n'importe quelle station distante • Conception préliminaire • Développement C Caractéristiques 2 Évolutivité et Maintenabilité Remarques Etapes concernées Exigence L'ajout de nouvelles fonctionnalités de ne doit poser aucun problèmes • Tout le cycle de production • Phase de développement B Caractéristiques 3 Souplesse Remarques Etapes concernées Exigence Capable de tourner sur n’importe quelle station de travail, serveur web, système d’exploitation… • Tests • Livraison A
  18. 18. PAQL GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 18 Caractéristiques 4 Fiabilité Remarques Etapes concernées Exigence En cas d'échec ou d'erreur renouvellera l'échange • Conception préliminaire et détaillée • Développement • Tests B 13. Reproduction, production, livraison 13.1 procédure de reproduction Aucune procédure de reproduction particulière n'est prévu. 13.2 Protection du site Les commerciaux et l'administrateur auront accès à leur environnement par l'intermédiaire des logins et mots de passe . 13.3 Livraison et installation L'accès au site final sera remis à l'équipe commerciale. Lors de la livraison du produit, le manuel utilisateur sera livré afin de permettre à des personnes étrangères à l'équipe d'utiliser le produit sans difficultés.
  19. 19. PAQL GPA Auteur : AAB Réf : 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 rédigés seront relus par le responsable qualité et modifiés en cas de non conformité avec le présent Plan d'Assurance Qualité Logicielle. De la même façon, les documents de type « livrables » seront relus et devront être validés par le maitre d'œuvre (Michel Belkacem). 14.2 Relecture La lecture croisée sera effectuée au minimum par les 2 membres de l'équipe de développement (l'un rédige, l'autre relit). L'auteur d'un document assure la réalisation des corrections proposés par les relecteurs et gère le changement des numéros de versions. L'enchaînement des tâches est le suivant : ➢Création du document ➢Diffusion aux relecteurs ➢Intégration des modifications par l'auteur et modification éventuelle du numéro de version en fonction des modifications effectuées ➢Validation finale

×