Paql intégration v1.00

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

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

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
9
5.3 Phases du cycle de vie

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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).

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
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.

PAQL
GPA
Auteur : AAB
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é
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
Capable de tourner sur
n’importe quelle station
de travail, serveur web,
système d’exploitation…
• Tests
• Livraison
A

PAQL
GPA
Auteur : AAB
18
Caractéristiques 4 Fiabilité
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.

PAQL
GPA
Auteur : AAB
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

Paql intégration v1.00

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Paql intégration v1.00

Similaire à Paql intégration v1.00 (20)

Plus de Arnold Stellio

Plus de Arnold Stellio (9)

Paql intégration v1.00