Identification du document. Identification des intervenants dans le projet

Transcription

1 Projet ITIN / Université de Cergy-Pontoise Page : 1 / 24 Identification du document Titre du document : Charte qualité Référence : v0.3 Date : 11 avril 2012 Nom du fichier : paq_v1.docx Identification des intervenants dans le projet Nom : Philippe GAUSSIER Nom de la société : ETIS Téléphone : gaussier@ensea.fr Adresse : Université de Cergy- Pontoise ETIS - UMR avenue Adolphe Chauvin Cergy Pontoise Cedex Contact 1 Contact 2 Contact 3 Nom : PELLISSON Prénom : Damien Téléphone : dpelliss@gmail.com Nom : DESSALLE Prénom : Bruce Téléphone : bdessalle@cergy.itin.fr Contact 4 Contact 5 Nom : NESTY Prénom : Olivier Téléphone : nesty.olivier@gmail.com Nom : KAISER Prénom : Florian Téléphone : mail.de.florian.kaiser@gmail.com Nom : NOIROT Prénom : Julien Téléphone : noirotj@gmail.com 1

2 Projet ITIN / Université de Cergy-Pontoise Page : 2 / 24 Evolutions du Document Version Date modifiés Auteur v0.1 17/10/2011 Premier jet Florian KAISER v0.2 08/12/2011 Complément sur le suivi des risques Florian KAISER v0.3 25/01/2012 Finalisation du document, avec une mise à jour des risques Florian KAISER v1.0 25/01/2012 Validation Bruce DESSALLE V1.1 11/04/2012 Validation et finalisation Olivier NESTY 2

3 Projet ITIN / Université de Cergy-Pontoise Page : 3 / 24 Sommaire 1 Présentation du client Activité du client Besoins exprimés par le client Description du document Responsabilité Exigence Code Nommage Indentation Commentaires En Java En C/C Documents Analyse des risques Tableau des risques Diagramme des risques Document applicable sur le projet Terminologie Organisation du projet Mode de communication interne Mode de communication avec le client Principaux acteurs et rôles Chef de projet Responsable qualité Responsable matériel Responsable du déploiement Développement du projet

4 Projet ITIN / Université de Cergy-Pontoise Page : 4 / Planification Gestion de la documentation Suivi qualité Tests unitaires et couverture de code Tests d intégration Validation du client Gestion de la configuration matériel Gestion des achats/sous-traitance Maîtrise du produit fini Indicateurs de performance/qualité

5 Projet ITIN / Université de Cergy-Pontoise Page : 5 / 24 1 Présentation du client 1.1 Activité du client Philippe GAUSSIER est le responsable du laboratoire ETIS, spécialiste en sciences de l information et de la communication, il travaille sur la modélisation des mécanismes cognitifs impliqués dans la perception visuelle (vision pré-attentive et attentionnelle) et sur la modélisation de structures telles que l'hippocampe (pour des problèmes d'intégration d'informations spatio-temporelles). Ces modèles servent de base pour imaginer des architectures de contrôle permettant à des robots mobiles d'apprendre à survivre dans un environnement à priori inconnu. Ces robots utilisent généralement la vision comme source principale d'information ce qui met en avant l importance du traitement de l image. Les tâches étudiées sont : l'apprentissage de conditionnements visio-moteurs, la reconnaissance de lieux (retour au nid), la construction et l'utilisation de cartes cognitives et enfin l'apprentissage de la discrimination d'objets et/ou de lieux. 1.2 Besoins exprimés par le client L objectif du client est de concevoir un drone pouvant se déplacer de façon entièrement autonome. Pour cela, il est mis à notre disposition deux plateformes pour effectuer nos tests, à savoir : Un modèle réduit de quadricoptère très maniable, simple d accès et plus facile à mettre en œuvre (possibilité de tests en intérieur, en revanche plus sensible aux intempéries) Un modèle réduit d hélicoptère bien plus puissant, pouvant embarquer plusieurs kilos de matériels et donc plus difficile à utiliser pour des raisons de sécurité La plateforme quadricoptère est considérée comme la solution prioritaire et constitue le produit final qui sera présenté au client au terme du projet. Au contraire, nous considérons la plateforme hélicoptère comme un objectif bonus ou secondaire qui sera avancé au fur et à mesure en fonction de l avancement des développements sur l autre plateforme. Le fait de disposer de deux supports pour nos tests nous permettra de paralléliser certaines phases de conception et éventuellement de sous-traiter à des étudiants de M1 la partie hélicoptère. Les cartes de développement, également commandées en double, pourront nous permettre de répartir les tâches de développement en deux groupes. Les applications possibles du drone peuvent être très diverses : 5 Exploration de zones difficilement accessibles o Ex : Entretien matériel et vérifications sur les avions, les buildings, les ponts etc. Surveillance d une zone et reconnaissance des lieux et objets

6 Projet ITIN / Université de Cergy-Pontoise Page : 6 / 24 o o o Recherche de personnes disparues (avalanches, naufrages, catastrophes naturelles) Reconnaissance morphologique de personnes (personnes recherchées, terroristes) Détection d intrusion, d incendie de forêt Il est essentiel et c est l un des buts finaux du projet d avoir un vol en autonomie au moment où l on vient à perdre le signal radio avec le drone. Ce dernier devra effectuer sa mission avant de revenir au lieu de départ. Le projet est évidemment complexe et présente beaucoup de possibilités. Le client serait très satisfait d obtenir à la fin du projet au moins une plateforme de développement opérationnelle et un système en boucle fermée sur l hélicoptère qui lui permettrait des déplacements simples en toute autonomie. 6

7 Projet ITIN / Université de Cergy-Pontoise Page : 7 / 24 2 Description du document Le plan d assurance qualité sert à décrire l'ensemble des dispositions spécifiques prises pour assurer la qualité du produit fourni dans le cadre d'un projet ainsi que la qualité du processus de développement. Il nous permettra également de référencer tous les documents de la gestion de projet ainsi que les documents techniques. Le principe est d écrire ce que l on fait (qui, quoi, où, comment, quand). Ensuite nous devons faire ce qu il est écrit, vérifier la conformité de ce que nous avons fait par rapport à ce qu il est écrit. 7

8 Projet ITIN / Université de Cergy-Pontoise Page : 8 / 24 3 Responsabilité Le qualiticien, comme on l appelle aussi, occupe une fonction clé. Il est non seulement garant de la qualité des produits, mais il est aussi chargé de la prévention des risques. Il participe à l élaboration de la politique qualité. Il en assure la gestion, la mise en place et le suivi. Le responsable contrôle qualité doit être une personne consciencieuse puisqu elle est garante de la qualité des produits de l entreprise. Elle doit donc connaître toutes les étapes de fabrication pour s assurer de cette qualité. 8

9 Projet ITIN / Université de Cergy-Pontoise Page : 9 / 24 4 Exigence 4.1 Code Tout le code doit être en anglais : aussi bien les commentaires que le nom des variables et méthodes. Les méthodes ne doivent pas être trop longues. Pour l IHM nous utiliserons le langage JAVA car il est multiplateforme et permet de faire des interfaces graphiques rapidement et conviviales. Le reste, entre autre le code sur les cartes embarquées, se fera en C/C++ car se sont des langages puissants et rapides : ils sont donc adaptés à nos systèmes temps réels. 4.2 Nommage Pour les classes, la première lettre de chaque mot sera en majuscule (exemple : MyClass). Pour les variables et les fonctions, elles commenceront par une minuscule, puis la première lettre de chaque mot sera en majuscule. Les attributs et les méthodes privées doivent être précédés d un underscore (exemple : mypublicvar, _myprivatevar). Les constantes doivent être en majuscules. Les mots doivent être séparés par un underscore (exemple : MY_CONST). 4.3 Indentation Le code doit être lisible et correctement indenté. L accolade ouvrante doit être alignée avec l accolade fermante. Si un bloc ne contient qu une instruction, les accolades doivent être supprimées. Exemple : for (int i; i < 10; i++) { if (condition) instruction1; instruction2; instruction3; } 9

10 Projet ITIN / Université de Cergy-Pontoise Page : 10 / Commentaires Toutes les méthodes publiques doivent être commentées. Les autres méthodes peuvent l être si cela semble nécessaire. Les algorithmes complexes doivent être commentés En Java /** * Description de la méthode arg1 Rôle de l argument 1 arg2 Rôle de l argument 2 0 si MyException si */ public int mymethod(int arg1, char arg2) throws MyExcepetion { instruction1; instruction2; } return 0; En C/C++ /*! * \brief Description de la méthode * \param arg1 Rôle de l argument 1 * \param arg2 Rôle de l argument 2 * \return 0 si * \throws MyException si */ public int mymethod(int arg1, char arg2) throw(myexcepetion) { instruction1; instruction2; } return 0; 4.5 Documents Tous les documents doivent avoir le même en-tête comportant le nom du projet, le nom du document, la version et la date de création. Tous les documents seront enregistrés sur un SVN ce qui nous permettra d avoir un historique des versions précédentes. 10

11 Projet ITIN / Université de Cergy-Pontoise Page : 11 / 24 5 Analyse des risques 5.1 Tableau des risques Réf Description Impacts Probabilité Impact Détection Criticité Apparition 1 Perte d effectif Baisse de la productivité Perte du SVN Perte de notre gestionnaire de documents Panne de matériel Retard sur les développements Mauvaises conditions Retard sur les tests en vol météorologiques Achat de matériel non Retard sur les développements conforme Manque de compétences Retard sur la conception techniques d architecture Retard sur les développements /09/

12 Projet ITIN / Université de Cergy-Pontoise Page : 12 / Diagramme des risques Criticité Perte d'effectif 40 Manque de compétences techniques 20 Perte du SVN 0 Achat de matériel non conforme Panne matérielle Mauvaises conditions météorologiques 12

13 Projet ITIN / Université de Cergy-Pontoise Page : 13 / 24 6 Document applicable sur le projet Digrammes permettant de modéliser les données et décrire le fonctionnement du logiciel (UML) o CasUtilisation.vsd o DiagrammeClasses.vsd o SequenceVolAuto.vsd o SequenceVolManuel.vsd Décomposition du matériel o DecompositionMateriel.vsd Spécifications Exigences Fonctionnelles (SEF) o CharteFonctionnement.docx o SAF.docx Plan d'assurance Qualité (PAQ) : décrit les règles et les méthodes servant à piloter le projet afin d atteindre l objectif du projet. o CharteQualite.docx Note De Cadrage (NDC) o ndc.docx 13

14 Projet ITIN / Université de Cergy-Pontoise Page : 14 / 24 7 Terminologie PAQ : pour «Plan d Assurance Qualité». MOA : pour «Maîtrise d Ouvrage». Le maître d'ouvrage (noté MOA) représente les intérêts des utilisateurs, et est garant de l'expression de leurs besoins, des contraintes, des choix organisationnels, et des exigences de qualité. Il est responsable du projet devant le Client et/ou sa Direction (coût, délai, qualité, performance). Il participe à la conception. Il valide la conformité du système livré et est garant du déploiement et de l'appropriation par les utilisateurs. Il contrôle le retour sur investissement des projets. MOE : pour «Maîtrise d'œuvre». Le maître d œuvre a la responsabilité de concevoir et de réaliser les applications. Il s'organise pour les produire avec ses équipes ou avec des fournisseurs externes. Il est garant de la faisabilité, de la conception et de la réalisation technologique, et des choix techniques. Il est garant de la cohérence de l'architecture applicative globale des systèmes, en collaboration avec les responsables MOA. Il conseille la MOA dans le choix des solutions fonctionnelles. NDC : pour «Note De Cadrage». Cadre le projet pour déterminer les besoins et les attentes du client pour le projet. IDE : pour «Integrated Development Environment». Environnement de développement logiciel, en informatique. IHM : pour «Interface Homme/Machine». Définit les moyens et outils mis en œuvre afin qu'un humain puisse contrôler et communiquer avec une machine. SIHM : pour «Spécifications d Interface Homme/Machine». SAL : pour «Spécifications d'architecture Logicielle». SEF : pour «Spécifications d Exigence Fonctionnelles». Document formulant le besoin, au moyen de fonctions détaillant les services rendus par le produit et les contraintes auxquelles il est soumis. PT : pour «Plan de test». PTU : pour «Plan de test unitaire». PTI : pour «Plan de test d intégration». PTV : pour «Plan de test de validation». SOC : pour «System On Chip». UAV : pour «Unmanned Aerial Vehicle». Aéronef sans pilote humain à bord. 14

15 Projet ITIN / Université de Cergy-Pontoise Page : 15 / 24 8 Organisation du projet 8.1 Mode de communication interne Afin d optimiser la communication dans le groupe, nous avons choisi d utiliser GMail pour pouvoir communiquer en discutions instantanées, par mail. Nous utilisons également un SVN pour centraliser nos documents et effectuer un historique. 8.2 Mode de communication avec le client Nous effectuons des retours vers le client régulièrement afin de valider l avancer de nos travaux. Ces retours sont effectués soit par mail soit par des réunions. 8.3 Principaux acteurs et rôles Chef de projet Titre : Chef de projet Assigné à : Bruce DESSALLE Rôle : 15 Veiller à l avancement du projet Veiller à la bonne organisation du groupe Veiller au respect des règles propres au groupe Veiller au respect des dates limites pour le rendu des livrables Chargé du planning (sous MS Project) Chargé d attribuer les tâches courantes Chargé du contrôle de la réalisation des taches Chargé de la communication Chargé du contrôle des livrables Responsable qualité Titre : Responsable qualité Assigné à : Florian KAISER Rôle : Définir les plans de test Suivre la réalisation des tests Mettre en œuvre la politique qualité définie pour le projet Suivre la politique qualité

16 Projet ITIN / Université de Cergy-Pontoise Page : 16 / 24 Contrôler chaque étape du projet en fonction de la politique qualité Chargé de la définition de la politique qualité Chargé de la mise en place des processus Chargé du contrôle du code au niveau du nommage Chargé de la traque aux bugs et des fonctionnements non désirés Chargé des tests unitaires Chargé des tests de validation Responsable matériel Titre : Responsable matériel Assigné à : Olivier NESTY Rôle : Définir les méthodes de mise en commun du code Veiller aux aspects techniques Chargé de la veille technologique Chargé de l analyse des spécificités techniques Responsable des attributions des tâches techniques au sein du groupe Responsable des choix techniques Responsable de la commande du matériel et de la réception Responsable du déploiement Titre : Responsable logiciel Assigné à : Damien PELLISON Rôle : Définir le processus de mise en place des logiciels Chargé du suivi des installations des logiciels Chargé du déploiement de l application chez le client Chargé du versioning du code Chargé de la certification du code Chargé de l analyse fonctionnel 16

17 Projet ITIN / Université de Cergy-Pontoise Page : 17 / 24 9 Développement du projet Pour le développement sur les cartes électroniques et pour l IHM en java nous utilisons l IDE Eclipse ainsi que l éditeur de texte Vim. 17

18 Projet ITIN / Université de Cergy-Pontoise Page : 18 / Planification Pour la gestion du planning nous utilisons Microsoft Project Le planning devra être mis à jour au minimum une fois par semaine. Chaque ressource (membre du groupe) devra informer le chef de projet au moins une fois par semaine le temps qu elle a passé sur le projet et sur quelle(s) tâche(s) en particulier. 18

19 Projet ITIN / Université de Cergy-Pontoise Page : 19 / Gestion de la documentation Tous les documents que nous réalisons sont au format (.docx,.xlsx,.etc) car ils sont moins lourds. Nous utilisons SVN afin de gérer nos documents ainsi que nos codes sources. Chaque fois qu une modification sera «commit», il faut impérativement ajouter un commentaire qui spécifiera les modifications apportées et la raison de ces modifications. 19

20 Projet ITIN / Université de Cergy-Pontoise Page : 20 / Suivi qualité 12.1 Tests unitaires et couverture de code Nous allons effectuer des tests unitaires qui nous permettront de valider différentes parties du code. Nous devrons également vérifier que nous avons une bonne couverture de code, c est-à-dire vérifié que nous testons la plus grande partie de notre code Tests d intégration Les tests d intégration seront utilisés pour valider que chaque module fonctionne bien avec le reste des modules. Lors de ces tests nous allons vérifier également qu il n y a pas de régression survenue après les modifications Validation du client Les tests de validation seront effectués en recette. La recette est notre environnement de test où le client peut tester lui-même les fonctionnalités du produit. Le client nous validera les fonctionnalités lors de différentes réunions au cours du projet. 20

21 Projet ITIN / Université de Cergy-Pontoise Page : 21 / Gestion de la configuration matériel Pour la partie développement C/C++ nous utilisons les éditeurs de texte Vi, Vim et Gedit sous Ubuntu (10.4, 11.4) avec le compilateur GCC et les options pour les SOC OMAP. Pour les développements Java nous utilisons le JRE 1.6 et nous utilisons l IDE Eclipse (Galileo, Helios, Indigo) sous Windows et Ubuntu. 21

22 Projet ITIN / Université de Cergy-Pontoise Page : 22 / Gestion des achats/sous-traitance Nous avons un gestionnaire de matériel. Il est chargé de faire la liste des composants nécessaires. Une fois la liste validée par le client, nous avons groupé notre commande avec d autres projets afin de simplifier la commande. 22

23 Projet ITIN / Université de Cergy-Pontoise Page : 23 / Maîtrise du produit fini Nous allons faire une démonstration du projet et fournir toute la documentation ainsi que le code source au client qui est M. GAUSSIER. 23

24 Projet ITIN / Université de Cergy-Pontoise Page : 24 / Indicateurs de performance/qualité Afin d anticiper tous problèmes pouvant survenir lors du projet, nous effectuerons un suivi des risques tout au long du projet. Pour maîtriser les risques, plusieurs activités sont à mettre en œuvre et ce, de manière itérative pendant toute la durée du projet : l'analyse des risques du projet, la réduction des risques et leur suivi. Les résultats de ces activités doivent être capitalisés au sein de l'organisme afin de faire profiter les futurs projets de l'expérience acquise. Le suivi des risques est une activité régulière qui permet de suivre l'évolution de la probabilité d'apparition des risques (stable, à la hausse, à la baisse), de contrôler la pertinence des actions préventives engagées et éventuellement de corriger les dispositions prévues. Egalement, de nouveaux facteurs de risques peuvent apparaître ; il faut les ajouter à la liste initiale. Enfin, il s'agit de surveiller le déclenchement des événements redoutés et leurs conséquences réelles. Le suivi des risques s'effectue au cours de réunions de projet dans lesquelles les différents intervenants concernés sont conviés. L'ordre du jour et le tableau de suivi des risques doit être communiqué suffisamment tôt afin de pouvoir proposer des actions. Un compte-rendu de réunion est fait par le chef de projet, auquel est joint le tableau de suivi des risques mis à jour. La date de la prochaine réunion de suivi est fixée. 24