1
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 2
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 : Maîtres d'œuvre : Consultant du projet : Rôle : UJF 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. 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. 3
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. 4
2. TERMINOLOGIE ET POLICES UTILISEES 2.1. Abréviations et définitions Abréviations Signification M2PGI PAQL CDC GMF EMF GEF SVN 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 Plan d'assurance QuaLité Cahier des Charges Graphical Modeling Framework Eclipse Modeling Framework Graphical Editing Framework SubVerSion est un logiciel libre de gestion de version sous licence Apache/BSD 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 Titre de niveau 2 16 Times New Roman Normal Noir Noir Titre de niveau 3 Times New Roman 15 Normal Noir Style des paragraphes Times New Roman 12 Normal, retrait Noir 5
La page de garde de chacun des documents est calquée sur le format ci-dessous : Figure 1 : Page de garde 6
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é 7
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 STMicroelectronics Maîtrise d œuvre Université Joseph Fourier Maître d ouvrage GUILLAUME Philippe Chef de l équipe OSPM Maîtres d œuvre 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 8
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 9
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/ 10
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 1 er 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 C g le nombre de classes générées à partir du modèle sans modification et C m le nombre de classes modifiées. 11
L écart par rapport au code généré est de E = C m / C g * 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 2 iè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. 12
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 A d l auto-description, N c le nombre de lignes de commentaires du code et N t le nombre total de lignes de code.on a : A d = N c / N t *100 Nous estimons ce facteur atteint si A d >15%. Ce seuil résulte des comparaisons avec d autres projet de M2PGI. 13
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 Etape de Etape d utilisation production Cahier des charges Livrable Analyse des besoins Spécifications externes Plan d assurance qualité Livrable Analyse des besoins Spécifications externes Plan de Livrable Analyse des besoins Spécifications développement Dossier des spécifications externes Livrable Spécifications externes externes Conception Dossier de conception Livrable Conception Codage Tests Livrable Conception Tests 6. GESTION DE LA CONFIGURATION ET DES 14
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 15
Nom Description Version Eclipse EMF GEF GMF Plates-formes de développement Environnement de développement intégré libre Framework de modélisation pour Eclipse Framework graphique pour Eclipse 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 1.1.5 Javadoc Documentation du code GANTT project Gestionnaire de projet 2.0.4 Systèmes d exploitation Linux Redhat MS Windows XP professionnel Gestionnaire de versions Documentation du code 16