PLAN D`ASSURANCE QUALITE 1

PLAN D’ASSURANCE QUALITE
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
1
PLAN D’ASSURANCE QUALITE
TABLE DES MATIERES
1.
But, portée, responsabilité........................................................................................... 3
1.1.
But et portée ........................................................................................................ 3
1.2.
Responsabilités.................................................................................................... 3
1.3.
Procédure dévolution du plan d’assurance qualité.............................................. 3
1.4.
Procédure en cas de non-respect du PAQL......................................................... 4
2. Terminologie et polices utiliseés................................................................................. 5
2.1.
Abréviations et définitions .................................................................................. 5
2.2.
Polices utilisées et page de garde ........................................................................ 5
3. Organisation ................................................................................................................ 7
3.1.
Description des activités de qualité..................................................................... 7
3.1.1.
Lecture croisée ............................................................................................ 7
3.1.2.
Réunion de validation.................................................................................. 7
3.1.3.
Les audits..................................................................................................... 7
3.2.
Organisation générale.......................................................................................... 7
4. Qualités du logiciel...................................................................................................... 9
4.1.
Cycle de vie......................................................................................................... 9
4.1.1.
Conditions de passage d'une étape à une autre du cycle de vie ................ 10
4.2.
Facteurs de qualité du logiciel........................................................................... 10
4.2.1.
Extensibilité............................................................................................... 10
4.2.2.
Utilisabilité................................................................................................ 12
4.2.3.
Réutilisabilité ............................................................................................ 12
5. Documentation produite............................................................................................ 14
6. Gestion de la configuration et des modifications ...................................................... 14
6.1.
Règle de gestion et d'archivage des documents ................................................ 15
6.2.
Règle de gestion et d'archivage du code ........................................................... 15
7. Outils utilisés............................................................................................................. 15
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
2
PLAN D’ASSURANCE QUALITE
1. BUT, PORTEE, RESPONSABILITE
1.1. But et portée
Le but de ce document est de spécifier les mesures qui doivent être prises en vue
d'assurer la qualité du logiciel. Ces mesures sont principalement issues de l'analyse des
besoins, mais aussi de notre propre réflexion sur la nature du projet.
Qui plus est, dans ce document, nous présenterons les différents acteurs qui
interagissent dans le cadre du projet, des styles et normes de programmation ainsi que la
liste des documents à produire.
Le projet se déroule dans l'entreprise STMicroelectronics à Grenoble, au sein de
l'équipe OSPM.
Le produit logiciel à réaliser est un outil permettant de programmer/composer
graphiquement une architecture logicielle obéissant à la logique et au modèle Fractal.
1.2. Responsabilités
Les différents acteurs qui apparaissent sont classés comme suit :
Maître d'ouvrage :
Rôle :
Monsieur GUILLAUME Philippe
Chef de l'équipe OSPM
Validation des documents, suivi du projet global
Maître d'ouvrage délégué : Monsieur LECLERCQ Matthieu
Membre de l'équipe OSPM
Rôle :
Encadrement du projet ,validation des documents
Maîtrise d'oeuvre :
UJF
Maîtres d'œuvre :
DIALLO Thierno Ousmane, SAADA KHELKHAL Fateh
Etudiants en M2PGI Option SRR
Chef de projet : SAADA KHELKHAL Fateh
Responsable Assurance Qualité : DIALLO Thierno Ousmane
Monsieur BARON Jean-Philippe
ATOSORIGIN
S'assurer du bon déroulement du stage.
Consultant du projet :
Rôle :
1.3. Procédure dévolution du plan d’assurance qualité
Toute modification du PAQL devra être réalisée sur la base d'une concertation entre le
responsable qualité du projet, le maître d'ouvrage et le maître d'ouvrage délégué. Si la
modification est adoptée, une nouvelle version du PAQL devra être rédigée.
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
3
PLAN D’ASSURANCE QUALITE
1.4. Procédure en cas de non-respect du PAQL
En cas de non-respect d'un critère de qualité, le responsable qualité du projet devra
alors informer le maître d'ouvrage et le maître d'ouvrage délégué. Une réunion de
concertation devra ensuite être organisée en vue de statuer sur le problème.
Si le respect du critère est jugé nécessaire, le responsable qualité et le chef du projet
sont tenus de respecter le PAQL tel qu'il a été validé. Dans le cas contraire, une nouvelle
version du PAQL sera rédigée.
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
4
PLAN D’ASSURANCE QUALITE
2. TERMINOLOGIE ET POLICES UTILISEES
2.1. Abréviations et définitions
Abréviations
Signification
M2PGI
Master 2 Professionnel Génie Informatique de l’université Joseph
Fourier de Grenoble Master 2 Professionnel Génie Informatique de
l’université Joseph Fourier de
Grenoble
PAQL
Plan d'Assurance QuaLité
CDC
Cahier des Charges
GMF
Graphical Modeling Framework
EMF
Eclipse Modeling Framework
GEF
Graphical Editing Framework
SubVerSion est un logiciel libre de gestion de version sous licence
Apache/BSD
SVN
Logique de projet
Ensemble de ressources (code source, fichiers de configuration, …) liées à un projet.
2.2. Polices utilisées et page de garde
L'ensemble des documents à rédiger utilisera les polices suivantes
Style
Police
Taille
Attributs
Couleur
Titre de niveau 1
Times New Roman
18
Majuscule et
normal
Noir
Normal
Noir
Normal
Noir
Titre de niveau 2
16
Times New Roman
Titre de niveau 3
Times New Roman
15
Style des paragraphes
Noir
Times New Roman
12
Normal, retrait
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
5
PLAN D’ASSURANCE QUALITE
La page de garde de chacun des documents est calquée sur le format ci-dessous :
Figure 1 : Page de garde
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
6
PLAN D’ASSURANCE QUALITE
3. ORGANISATION
3.1. Description des activités de qualité
3.1.1.
Lecture croisée
La rédaction des documents est répartie uniformément entre les deux étudiants.
Lorsqu’une version d'un document est achevée, l'auteur demande à son binôme de le
relire. Ceci a pour but d'une part de s'assurer que le contenu du document reflète
clairement l'idée du groupe et d'autre part de corriger d'éventuelles fautes d'orthographe,
et vérifier la cohérence avec les autres documents.
3.1.2.
Réunion de validation
Après la lecture croisée, le document est envoyé aux maîtres de stage. Ceux-ci organisent
alors une réunion avec les stagiaires. Ces réunions ont pour objectif de vérifier que le
contenu du document reflète bien l'objectif visé et reste cohérent dans l'ensemble. La
rédaction de nouvelles versions du document peuvent être produites à l'issue de ces
réunions ou bien entraîner une première validation de celui-ci.
3.1.3.
Les audits
Les audits sont au nombre de trois pour l'ensemble du projet et ont pour but de s'assurer
de la bonne marche du projet et du respect des méthodes de génie logiciel. Y assistent le
groupe de M2PGI, le consultant et les maîtres de stage.
Les documents seront fournis une semaine avant l'audit à chaque participant.
A l'issue de l'audit, les documents fournis sont soit validés de manière définitive, soit
sujets à des modifications.
3.2. Organisation générale
Le Maître d’ouvrage
Mr GUILLAUME Philippe, chef de l’équipe OSPM, vérifie la bonne marche du projet,
organise des réunions de concertation et contribue à la validation des différents
documents.
Le Maître d’ouvrage délégué
Mr LECLERCQ Matthieu, oriente le projet et vérifie la réalisation des différentes taches.
Il s’assure de l’avancement du projet et participe aussi à la validation des documents.
Mr LECLERCQ est un spécialiste du modèle de composants Fractal. Il nous éclairera
tout au long du projet sur les aspects techniques et/ou complexes de ce modèle de
composants.
Maîtres d’œuvre
SAADA KHELKHAL Fateh : Chef de projet
DIALLO Thierno Ousmane : Responsable qualité
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
7
PLAN D’ASSURANCE QUALITE
Le chef de projet a pour rôle de répartir et organiser les différentes taches du projet.
Le responsable qualité veille à l’application du PAQL.
Maîtrise d’ouvrage
Maîtrise d’œuvre
STMicroelectronics
Université Joseph Fourier
Maître d’ouvrage
Maîtres d’œuvre
GUILLAUME Philippe
Chef de l’équipe OSPM
DIALLO Thierno Ousmane
SAADA KHELKHAL Fateh
Etudiants M2PGI Option SRR
Maître d’ouvrage délégué
LECLERCQ Matthieu
Membre de l’équipe OSPM
Figure 2 : Organisation générale
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
8
PLAN D’ASSURANCE QUALITE
4. QUALITES DU LOGICIEL
4.1. Cycle de vie
Le logiciel que nous allons produire s’articule principalement autour de deux parties :
1. Le moteur graphique
C’est le noyau du logiciel. Il regroupe toutes les fonctionnalités nécessaires à la
réalisation d’une boite à outils graphique pour la composition d’une architecture de
composants Fractal. Sa mise en œuvre repose sur une architecture extensible qui
favorise l’ajout de fonctionnalités supplémentaires de façon aisée.
2. Les fonctionnalités additionnelles
Il s’agit d’un ensemble de fonctionnalités avancées qui viendront se greffer sur le
moteur graphique en vue de l’étendre. Ces fonctionnalités apporteront des facilités
d’édition aux programmeurs de composants Fractal et intégrerons une logique de
projet au moteur graphique.
La nature même du projet se révèle assez proche du cycle de vie incrémental.
Nous utiliserons donc cette approche pour ce projet.
Analyse des besoins
Spécifications externes
Conception
Codage
Tests
Livraison
Figure 3 : Cycle de vie incrémental
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
9
PLAN D’ASSURANCE QUALITE
4.1.1. Conditions de passage d'une étape à une autre du cycle de vie
Le passage d'une étape à la suivante se fait lorsque l'étape courante est terminée et
validée. Cependant, un chevauchement est permis dans la plupart des cas. Une étape est
validée si les documents qu'elle produit sont validés.Un incrément est validé si tous les
tests ont été effectués.
4.2. Facteurs de qualité du logiciel
4.2.1. Extensibilité
Définition
Faculté du logiciel à être étendu par d’autres personnes autres que les développeurs
du logiciel, avec un minimum d’effort.
Motivation
Ce facteur constitue un aspect essentiel pour le projet. Il est étroitement lié à la nature
des composants Fractal, en particulier l’ADL Fractal.
Le moteur graphique du logiciel repose sur la définition du modèle du domaine dans
un premier temps. Ce modèle du domaine est basé sur l’ADL Fractal qui constitue luimême un modèle extensible. Par conséquent, une évolution du modèle ADL Fractal
devra inévitablement s’accompagner d’une évolution du modèle du domaine dont il
constitue la base.
L’architecture du moteur graphique devra donc garantir une extensibilité permettant de
suivre les futures évolutions du modèle de l’ADL Fractal.
Dans un second temps, il faudra définir un modèle graphique pour le moteur
graphique. Il a pour but de définir tous les aspects relatifs à la représentation graphique
des composants Fractal (hiérarchies entre les composants graphiques, formes utilisées,
…).
La programmation à base de composants Fractal est utilisée dans de nombreux
domaines. La représentation graphique (sur papier) des différents éléments constituant
une architecture logicielle des composants Fractal varie d’un domaine à l’autre et reste
étroitement lié à la logique métier du domaine. Certaines conventions graphiques existent
mais ne sont pas utilisées par la majorité1.
De ce fait, le moteur graphique devra être extensible de façon à supporter des
spécialisations du modèle graphique.
Par ailleurs, le moteur graphique devra pouvoir supporter de façon aisée les
fonctionnalités additionnelles. Certaines ont été identifiées et seront mises en oeuvre au
cours de ce projet, cependant le logiciel devra fournir le moyen de pouvoir ajouter des
fonctionnalités non encore définies.
1
Voir certaines conventions sur le site https://codex/cro.st.com/plugins/docman/
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
10
PLAN D’ASSURANCE QUALITE
Mise en oeuvre
Une extension de notre logiciel peut se situer à deux niveaux :
-Une extension de premier niveau :
Une évolution de l’ADL Fractal ou du modèle graphique constitue une étape majeure
en terme de modification du logiciel car elle concerne le noyau de celui-ci.
- Une extension de second niveau
Il s’agit de l’ajout de nouvelles fonctionnalités additionnelles.
Mise en œuvre de l’extensibilité de 1er niveau
Extensibilité apportée par EMF, GEF, GMF
Le logiciel que nous allons produire sera entièrement basé sur l’utilisation du
framework GMF, qui sert de pont entre les frameworks EMF et GEF. Ces trois
technologies sont des plug-ins Eclipse et reposent sur l’approche de l’ingénierie dirigée
par les modèles. L’utilisation de GMF se déroule en trois étapes principales :
•
•
•
La définition du modèle du domaine
La définition du modèle graphique
La définition de la liaison entre les deux modèles définis
Une fois ces modèles définis, le framework génère le code correspondant à chacun
d’eux.
Une grande extensibilité est offerte au programmeur et ceci à deux niveaux :
Niveau modèle
Le programmeur peut à tout moment modifier un modèle suivant ses besoins, puis
effectuer une simple régénération du code correspondant. Le code régénéré reste
conforme au nouveau modèle.
Niveau du code généré
Le générateur de code se base sur le modèle pour produire le code associé, cependant il
utilise aussi une multitude d’informations qui ne font pas partie du modèle. Ces
informations sont souvent des valeurs prédéfinies et utilisées par défaut. Cela se
manifeste dans le code par des classes par défaut. Le programmeur peut définir ses
propres classes et les utiliser à la place de ces classes par défaut.
Cependant, le nombre important de classes générées ne facilite pas la recherche de
telles classes d’une part, et d’autre part d’éventuelles résolutions de dépendance avec
d’autres classes peut s’avérer fastidieuses.
Critères de mesure
Il apparaît donc judicieux d’utiliser au maximum l’extensibilité des modèles dans le
souci de produire un logiciel extensible.
Soit Cg le nombre de classes générées à partir du modèle sans modification et Cm le
nombre de classes modifiées.
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
11
PLAN D’ASSURANCE QUALITE
L’écart par rapport au code généré est de E = Cm / Cg * 100
Nous estimons que notre logiciel garantit l’extensibilité de premier niveau si cet écart
reste inférieur à 20%.
Mise en œuvre de l’extensibilité de 2ième niveau
Les fonctionnalités additionnelles seront réalisées sous forme de plug-ins, qui
représentent l’unité d’extension de la plate-forme Eclipse. Ces plug-ins viendront étendre
le moteur graphique qui leur sert de contexte d’exécution et qui est lui-même un plug-in.
4.2.2. Utilisabilité
Définition
Faculté du logiciel à proposer une interface facile à apprendre et à utiliser.
Motivation
Le logiciel est destiné en particulier aux membres de l’équipe OSPM qui ont beaucoup
d’expérience en programmation de composants basés sur le modèle Fractal.
En général, ils commencent par dessiner l’architecture de leurs composants sur papier
ou sur tableau avant de passer à la programmation. Les formes utilisées pour le dessin des
différents composants sont souvent similaires d’un membre à l’autre, moyennant une
légère différence, mais convergent vers la même interprétation.
Il apparaît primordial que l’interface graphique fournie par le logiciel soit conforme à
la logique graphique utilisée par les programmeurs en composants Fractal de l’équipe en
particulier, pour une rapide prise en main.
Par ailleurs, le logiciel à pour but de faciliter la tache des programmeurs de
composants Fractal, ce qui suppose une interface graphique facilement manipulable et
facilement compréhensible.
Mise en oeuvre
Les conventions graphiques utilisées pour le logiciel seront entièrement définies par
le Maître d’ouvrage Mr GUILLAUME Philippe et le Maître d’ouvrage délégué Mr
LECLERCQ Matthieu, en accord avec les autres membres de l’équipe et la communauté
extérieure des programmeurs de composants Fractal.
Critère de mesure
Un formulaire sera mis en place sur l’utilisabilité de l’interface graphique. Il sera
destiné en particulier aux membres de l’équipe, mais aussi à d’autres équipes de
programmeurs en composants de l’entreprise.
Nous estimons ce facteur garanti si nous obtenons au moins 80 % de satisfaction.
4.2.3. Réutilisabilité
Faculté du logiciel à être utilisé dans d’autres applications, avec un minimum d’effort
d’intégration.
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
12
PLAN D’ASSURANCE QUALITE
Motivation
Le logiciel à produire sera Open Source et pourrait être proposé à la communauté
ObjectWeb, en tant que contribution. Il pourrait donc être utilisé en tout ou en partie par
d’autres programmeurs pour l’intégrer à d’autres applications et/ou l’étendre.
Mise en œuvre
Elle sera principalement assurée par :
-Une bonne documentation du code
-Une rédaction détaillée du manuel utilisateur et du plan de développement.
Critères
Modularité héritée de GMF, EMF, GEF
Le code généré par les frameworks GMF, EMF et GEF reste très modulaire et bien
organisé. Notre objectif est de rester très proche de ce code généré en effectuant un
minimum de modifications.
Avec un écart souhaité de moins de 20 % par rapport au code généré (voir paragraphe
4.2.1 sur l’extensibilité), ce facteur sera de fait hérité des technologies GMF, EMF et
GEF.
Auto-description
Pour que l’application soit réutilisable, il faut qu’elle soit auto-descriptive.
Nous définissons la mesure d’auto-description en termes du nombre de lignes de
commentaires et du nombre de lignes total du module.
Soit Ad l’auto-description, Nc le nombre de lignes de commentaires du code et Nt
le nombre total de lignes de code .On a :
Ad = Nc / Nt *100
Nous estimons ce facteur atteint si Ad >15%. Ce seuil résulte des comparaisons avec
d’autres projet de M2PGI.
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
13
PLAN D’ASSURANCE QUALITE
5. DOCUMENTATION PRODUITE
Le tableau suivant énumère les documents produits, leurs statuts, ainsi que les étapes
dans lesquelles ils sont produits, et celles pour lesquelles ils sont requis.
ar Requis pour
Documents
Statut
Cahier des charges
Livrable
Etape de
production
Analyse des besoins
Etape d’utilisation
Plan d’assurance
qualité
Plan de
développement
Dossier des
spécifications
externes
Dossier de conception
Livrable
Analyse des besoins
Livrable
Analyse des besoins
Livrable
Spécifications
externes
Livrable
Conception
Codage
Tests
Livrable
Conception
Tests
Spécifications
externes
Spécifications
externes
Spécifications
externes
Conception
6. GESTION DE LA CONFIGURATION ET DES
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
14
PLAN D’ASSURANCE QUALITE
MODIFICATIONS
6.1. Règle de gestion et d'archivage des documents
• Les documents seront numérotés de la façon suivante: Version.Révision.
• Les révisions vont correspondre à des changements moyens et les versions à des
changements majeurs.
6.2. Règle de gestion et d'archivage du code
• Le code source sera géré par un gestionnaire de versions (SVN) intégré à Eclipse. Le
répertoire partagé du projet a pour racine /gui.
• Toute mise à jour ou commit doit être commenté de façon claire.
• Le nommage des révisions sera géré par SVN.
7. OUTILS UTILISES
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
15
PLAN D’ASSURANCE QUALITE
Nom
Description
Version
Plates-formes de développement
Eclipse
Environnement de développement intégré libre
EMF
Framework de modélisation pour Eclipse
GEF
Framework graphique pour Eclipse
GMF
Framework de modélisation graphique basée sur EMF et
GEF
Gestion de projet
Subversion(SVN) Gestionnaire de versions
Javadoc
Documentation du code
GANTT project
Gestionnaire de projet
2.0.4
Traitements de texte
Openoffice
Outil de traitement de texte
Javadoc
Documentation du code
GANTT project
Gestionnaire de projet
1.1.5
2.0.4
Systèmes d’exploitation
Linux Redhat
Gestionnaire de versions
MS Windows XP
professionnel
Documentation du code
Ed iteur grap hique d ’architecture de co mpo sa nts Fractal
16