PLAN ASSURANCE QUALITE

Transcription

1 PLAN ASSURANCE QUALITE Page : 1/56

2 Sommaire 1 Objet et domaine d application Objet Domaine d application Documents applicables et documents de référence Documents applicables Documents de référence Normes existantes Modalités d évolution du PAQ Dispositions générales Présentation générale du projet Contexte et objectifs Périmètre du projet Environnement technique Organisation Suivi du projet Le comité de pilotage MOE-MOA Le comité de coordination MOE-MOA L équipe projet MOONLIKESTUDIO (en fonction du périmètre projet : les CV sont présentés au CLIENT) Les modes de communication Gestion des réunions Suivi de l'avancement Page : 2/56

3 3 Outils du projet Outils de gestion et de documentation Outil de gestion de la configuration Outils de sauvegarde Méthodes et référentiels Description des activités du projet Reprise de l existant Appropriation technologique Appropriation organisationnelle Récupération des codes et documentations Bilan de la phase de reprise Interface avec l hébergeur Spécifications des évolutions Objectif des spécifications Travaux Produits de la phase Design, ergonomie, graphisme Ergonomie et graphisme Produits de la phase Nouvel espace coloriel Prise en compte de l accessibilité Iconographie Conception générale Objectif de la conception générale Travaux Produits de la phase Codage Objectif du codage Page : 3/56

4 5.5.2 Travaux Produits de la phase Prise en compte de l accessibilité Tests d intégration (recette «interne») Objectifs des tests d intégration Prise en compte de l accessibilité Travaux Produits de la phase Livraison itérative Déroulement Produits de la phase Validation finale Recette probatoire (recette de vérification d aptitude ou VA) Mise en place Recette définitive (validation de service régulier ou VSR) Le transfert de compétence La garantie Déclaration d anomalie Démarche de résolution Délais de prise en compte Délais de résolution Maintenance corrective Objet de la maintenance corrective Démarche de résolution Délais de prise en compte Délais de résolution Maintenance évolutive Objet de la maintenance évolutive Démarche de réalisation Délais de prise en compte Page : 4/56

5 Délais de réalisation Suivi Activités récurrentes Activités ponctuelles Modalités de reporting vers la CLIENT Outil de gestion en ligne (gestion des modifications) Gestion de la documentation Objectifs Règles de gestion et règles de nommage Les documents du projet Macro-planning Les différents environnements techniques mis en place et les responsabilités associées Le dispositif de contrôle qualité mis en place Responsabilités Obligations de MOONLIKESTUDIO Obligations de la CLIENT Page : 5/56

6 1 Objet et domaine d application 1.1 Objet CLIENT a décidé de confier à un prestataire la réalisation, le suivi, et la maintenance de son offre PROJET. CLIENT a choisi la société MOOLIKESTUDIO pour cette prestation. Ce Plan d'assurance Qualité (PAQ) a pour but : - d'anticiper la trajectoire du projet (anticipation d éventuelles dérives, etc.), - d'énoncer les dispositions nécessaires à prendre pour sa bonne conduite et son aboutissement, - de définir les moyens à mobiliser dans le cadre de ce projet, - de préciser le rôle de chaque intervenant, - de définir les procédures de travail à utiliser. 1.2 Domaine d application Le PAQ s'applique à l'ensemble du projet (réalisation, déploiement, vérification, formation, utilisation, maintenance corrective et évolutive, garantie). Il couvre l'ensemble des activités et des fournitures constituant la solution (scripts, exécutables, documentation, formation). Page : 6/56

7 1.3 Documents applicables et documents de référence Documents applicables Les documents applicables au projet sont des documents dont l'application est imposée et vérifiable, en voici la liste : - le cahier des charges PROJET ; - la réponse de MOONLIKESTUDIO à l appel d offre PROJET ; - le présent Plan d Assurance Qualité en date du.. Ces documents sont applicables prioritairement dans l ordre listé ci-dessus Documents de référence - CAHIER DES CHARGES - PROJET Normes existantes - norme ISO 9000 sur la «Gestion de la qualité et assurance de qualité», - norme AFNOR Z sur les «Recommandations de plan qualité logiciel». 1.4 Modalités d évolution du PAQ Ce Plan a pour vocation d évoluer si le projet le nécessite, pour ce faire, l évolution devra être proposée à l ensemble des intervenants concernés par ce Ceci fait, l évolution devra être approuvée à l unanimité avant d être intégrée définitivement dans le Plan d Assurance Qualité. Page : 7/56

8 2 Dispositions générales 2.1 Présentation générale du projet Contexte et objectifs Périmètre du projet Dans le cadre de ce projet, MOONLIKESTUDIO est missionné pour : Environnement technique L environnement technique qui s applique est celui décrit dans le cahier des charges support de l appel d offres. 2.2 Organisation Ce chapitre décrit l organigramme des intervenants du projet et précise le rôle et les responsabilités de chacun. Les principales instances sont au nombre de trois : - le comité de pilotage MOE-MOA, - le comité de coordination MOE-MOA - l équipe projet. Ces instances s appuient sur les compétences fonctionnelles et techniques propres au domaine du projet. Page : 8/56

9 2.3 Suivi du projet Le comité de pilotage MOE-MOA Le comité de pilotage comprend les personnes suivantes : Il a en charge : - le suivi de l avancement du programme (calendrier, budget, périmètre fonctionnel du site, bon de commandes, développements à envisager) ; - l arbitrages et la prise de décision stratégiques, (ces arbitrages et prises de décisions incombent au CLIENT nonobstant la présence de MOONLIKESTUDIO) ; - l analyse des risques. Il a pour périodicité : - Il est prévu tous les mois, en complément ou en lieu et place d un comité de coordination ou selon les besoins du projet Le comité de coordination MOE-MOA Le comité comprend les personnes suivantes : - chef de projet CLIENT, - directeur technique MOONLIKESTUDIO, - différents contributeurs extérieurs en accord avec le CLIENT. Il a en charge : - le suivi des problématiques opérationnelles rencontrées ; - la discussion des évolutions à mettre en place, des plannings ; - la validation par le CLIENT des propositions fonctionnelles, graphiques et techniques faites par l équipe MOONLIKESTUDIO, arbitrages et prise de décision par le CLIENT ; - la validation par le CLIENT des différents produits finis / livrables décrits dans la présente proposition ; Page : 9/56

10 - le suivi des risques identifiés par la MOE et présenté par MOONLIKESTUDIO Il a pour périodicité : - Il est prévu tous les 15 jours L équipe projet MOONLIKESTUDIO (en fonction du périmètre projet : les CV sont présentés au CLIENT) Directeur technique Le directeur technique du projet est le garant de la qualité technique des développements, de la maintenance et des évolutions produites. Il agit au mieux des intérêts techniques du projet : pérennité, simplicité, capacité à être maintenu, performance. Il propose et valide les choix techniques pour les évolutions majeures dans le cadre des intérêts techniques du projet. Coach IT Le coach IT organise la vie du projet. Il pilote et coordonne les différentes ressources nécessaires, rédige ou fait rédiger la documentation, gère les plannings et le séquencement des tâches, s assure de la bonne fin des différents travaux. Ces compétences métier et technique lui donne une vision globale du projet. Il maîtrise les différentes technologies mises en œuvre. Développeur Le développeur prend principalement en charge les trois sous-phases de la tâche de codage des évolutions à mener. Il effectue la conception détaillée de ces programmes, le codage et les tests unitaires. Il rédige la documentation associée à cette tâche. Les développeurs maîtrisent l ensemble des technologies Web & Framework associés (PHP, J2EE, XML, HTML, scripts, bases de données ). Page : 10/56

11 Le directeur artistique et son équipe Le directeur artistique et son équipe sont chargés : - du conseil en communication ; - de la création graphique et ergonomique des sites Web ; Les prestations du directeur artistique et de son équipe sont formalisées dans une charte graphique ou exprimées sur des pages écrans types (maquettes créatives). Infographiste L infographiste traite trois types de travaux différents. Ce sont : - la déclinaison de page issues de la création en pages «réelles» ou en tout cas très proches de ce qu elles seront dans la réalité opérationnelle du site ; - la découpe et l optimisation des images et pictogrammes pour leur insertion dans les pages HTML du site ; - le développement d animations graphiques Les modes de communication Le mode de communication à privilégier entre les différents intervenants est le courrier électronique. Les documents contractuels (PV de recette provisoire, documentation technique, PAQ, etc.) 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. Le référentiel de document est disponible dans l outil collaboratif mis à la disposition du projet «TRACK» disponible via login & mot de passe à tous les CLIENTS MOONLIKESTUDIO (suivi en temps réel) Gestion des réunions D'une manière générale, c'est le chef de projet assisté de l AMOA dans chacune des instances de réunion qui sera chargé de : - formuler l'ordre du jour, Page : 11/56

12 - réaliser les éventuels documents associés (en complément des documents à préparer par la MOE tels que planning détaillé, indicateurs d avancement ), - assurer la diffusion desdits documents aux personnes présentes lors de la réunion, - rédiger le compte rendu de réunion. (En dehors des réunions à dominante technique dont les CR seront rédigés par la MOE) - diffuser celui-ci aux personnes concernées dans un délai maximum de trois jours. Les éventuelles remarques sont à faire parvenir au chef de projet dans un délai d'une semaine à partir de la réception du compte rendu ou, deux jours avant une seconde réunion traitant du même sujet. Les comptes-rendus seront réputés validés, et publiés sur l outil collaboratif, si aucun commentaire n a été reçu dans les cinq (5) jours ouvrés suivant la date de réception des dits comptes-rendus. 2.4 Suivi de l'avancement Le comité de projet (coordination MOE-MOA) se réunira régulièrement pour faire le point sur l'état d'avancement du projet et régler les problèmes rencontrés éventuels (de une fois par semaine à une fois toutes les deux semaines en fonction des besoins de suivi du projet). Tout problème qui n'est pas du ressort du comité du projet ou qui ne peut être résolu au sein des groupes de travail sera soumis au comité de pilotage avec une ou plusieurs propositions de résolutions. Un planning général du projet ainsi qu'un échéancier seront établis par CLIENT assisté par l AMOA sur la base des plannings détaillés préparés par MOONLIKESTUDIO pour les parties lui incombant, ce planning général étant mis à jour et diffusé chaque mois. Le planning des évolutions principales (études, conception, développement, ) aura un suivi de réalisation et sera diffusé de manière hebdomadaire par le biais d'une note fournie à CLIENT (afin de pouvoir consolider les indicateurs d avancement dans le planning général). Page : 12/56

13 3 Outils du projet 3.1 Outils de gestion et de documentation Les logiciels suivants seront utilisés à la gestion du présent projet : - Microsoft Excel 2000 : pour le suivi des charges, des risques ou données d étude; - Microsoft Word 2000 : pour la documentation ; - Microsoft Project 2000 : pour la planification et le suivi du projet. 3.2 Outil de gestion de la configuration Les codes sources des programmes, des pages, des scripts seront stockés via un outil de type CVS. Ce type d outil permet de gérer les versions et de conserver les traces des modifications apportées aux fichiers sources. De ce fait, une livraison sur la plate-forme de production est caractérisée, à un instant donné, par l ensemble des niveaux de version de chacun des fichiers présents sur la plate-forme de production. Cette ensemble est dénommé «fiche de version». 3.3 Outils de sauvegarde L ensemble de la documentation, des documents de gestion et des fichiers sources sera sauvegardé quotidiennement. - Outils de développement : (en fonction des contraintes PROJET) - Outils de suivi de la recette : (en fonction des contraintes PROJET) - Outils de suivi des anomalies & évolutions : TRACK : rubrique Support - Outils d'automatisation des tests : (en fonction des contraintes PROJET) Page : 13/56

14 4 Méthodes et référentiels Seront référencés les référentiels : - normes de développement : - règles de sécurité : Seront référencés les méthodes mises en œuvre : - XP 5 Description des activités du projet 5.1 Reprise de l existant La phase de reprise de l existant comprend plusieurs activités qui devront être menées de front : - l appropriation technologique ; - l appropriation organisationnelle ; - la mise en place des plates-formes matérielles et logicielles ; - l interfaçage avec l hébergeur ; - la récupération des codes sources et du référentiel documentaire. Cette phase se conclut par un bilan. Page : 14/56

15 5.1.1 Appropriation technologique Objectif Durant cette sous-phase, MOONLIKESTUDIO s appropriera l ensemble des aspects technologiques de l offre PROJET. Il s agit de comprendre et de savoir faire évoluer l architecture technique générale mais aussi chacun des modules mis en œuvre. Travaux Rôle MOONLIKESTUDIO - prendre connaissance de la documentation technique existante ; - assister au transfert de compétence ; - faire une revue générale de l architecture technique générale ; - faire une revue de code des principaux modules ; Rôle CLIENT - s assurer la collaboration de la SSII actuellement en charge du développement pour faciliter le transfert de compétences Appropriation organisationnelle Objectif Il s agit, durant cette sous-phase de connaître les différents intervenants et de connaître les principales procédures du projet. Travaux Rôle MOONLIKESTUDIO - prendre connaissance des procédures ; - rencontrer les intervenants principaux au cours d une réunion de démarrage de la maintenance ; Page : 15/56

16 Rôle CLIENT - s assurer de la présence des différents participants à la réunion de démarrage de la maintenance Récupération des codes et documentations Objectif Il s agit, durant cette sous-phase de récupérer l ensemble des codes sources actuels et passés de l application, ainsi que toutes les documentations existantes. Travaux Rôle MOONLIKESTUDIO - Récupérer les codes sources actuels et passés et les documentations existantes ; Rôle CLIENT - fournir les codes sources (si possible) et les documentations. Note Pour nous assurer d une reprise de l existant complète et consistante, nous avons imaginé un processus décomposé en trois phases. Phase 1 : il s agit de : - récupérer l ensemble des fichiers sources en cours de développement et en production ; - les installer sur l environnement de développement ; - vérifier que les fichiers dits «en production» le sont réellement. Phase 2 : il s agit de : - faire une copie complète de tous les éléments sources dit «en production» vers les plates-formes d intégration et de recette ; - une nouvelle fois, faire un différentiel avec la plate-forme de production afin de s assurer que tous les fichiers présents sur la plate-forme de production Page : 16/56

17 sont indiqués comme en «en production» dans l outil de gestion de configuration ; - solliciter la plate-forme de recette pour vérifier qu elle supporte correctement l offre PROJET. Phase 3 : il s agit de: - valider le processus de livraison d un élément modifié en suivant le processus des plates-formes de développement jusqu à la plate-forme de production (via un fichier test par exemple) Bilan de la phase de reprise Sous réserve de la bonne collaboration des différentes parties, cette phase de reprise de l existant sera effectuée en moins de 15 jours ouvrés. A son issue, un cahier de recommandations des actions de maintenance et des évolutions à envisager sera présenté. Les différentes actions et évolutions seront ordonnancées afin de maximiser la qualité et l efficacité de la maintenance. Un planning sera aussi proposé Interface avec l hébergeur La majorité des opérations de maintenance de l offre PROJET conduit à une mise en ligne sur la plate-forme de production de nouveaux éléments. De ce fait, une interactivité importante entre l hébergeur et MOONLIKESTUDIO existera. Ces échanges nous permettront de vérifier le bon fonctionnement de l hébergement et des différentes procédures mises en place pour parer aux problèmes principaux. La disponibilité des plates-formes, la compétence des équipes et la qualité intrinsèque de l hébergement seront vérifiées fréquemment. 5.2 Spécifications des évolutions La phase de spécifications est aussi appelée «conception fonctionnelle». Page : 17/56

18 5.2.1 Objectif des spécifications Les objectifs de la phase de spécifications sont de définir finement les attentes fonctionnelles et techniques d une évolution souhaitée par CLIENT Travaux Rôle MOONLIKESTUDIO Pour chacune des évolutions envisagées et en fonction de celle-ci, les différents travaux à réaliser sont les suivants : - définir le contenu et l arborescence d une nouvelle rubrique ; - définir le modèle de navigation de la nouvelle rubrique ; - définir les fonctions des nouveaux programmes à réaliser ou à ajouter à un programme ancien ; - dans certains cas, il est souhaitable de construire une maquette en HTML afin de montrer l ergonomie générale de l évolution envisagée. Cette maquette permet de valider des fonctionnements, les navigations et l organisation des pages. Rôle CLIENT - fournir tous les éléments permettant de spécifier au mieux les contenus, rubriques ou programmes à réaliser ; - valider les spécifications élaborées par Axidea ; - validation des maquettes éventuelles Produits de la phase - Dossier des Spécifications Fonctionnelles Détaillées élaborés et validés ; o Ce document doit être un document unique, exhaustif et de référence ; il doit donc reprendre de façon exhaustive l expression de besoins MOA (spécifications MOA) ; o Il doit présenter une séparation claire des aspects fonctionnels détaillés et des aspects techniques ; Page : 18/56

19 o Pour chaque cas d'utilisation - ie fonctions ou services rendus- le statut ( en cours de rédaction - à valider - validé) facilitera sa lecture par l ensemble des acteurs qui s appuient sur ce document pour leur travaux (préparation des cas de tests, des supports de formation ) - Maquettes éventuelles validées. 5.3 Design, ergonomie, graphisme Pour toutes ces prestations, le directeur artistique et son équipe sont les intervenants principaux Ergonomie et graphisme La démarche générale pour les prestations d ergonomie et de graphisme est la suivante : - prise en compte du brief ; - réalisation de la conception -création graphique de l élément demandé (nouveau modèle de document, nouvel écran, ) ; - présentation de 3 propositions au format papier et jpg à CLIENT ; - prise en compte des remarques de la CLIENT ; - finalisation des maquettes sur la base du choix réalisé et des remarques formulées Produits de la phase - Document de charte graphique et référentiel associé ; Nouvel espace coloriel La démarche générale pour la création d un nouvel espace coloriel est la suivante : - prise en compte du brief ; - présentation des univers coloriels sous forme de boards présentant les couleurs ; Page : 19/56

20 - sur la base du choix de CLIENT, habillage des différents écrans présentés sur maquettes papier (2 à 3 maquettes) Prise en compte de l accessibilité En terme de validation complémentaire par la MOA, une phase de revue des propositions graphiques au regard des objectifs d accessibilité sera faite par l AMOA et restitué lors d une réunion de travail avec MOONLIKSTUDIO Iconographie La démarche générale pour développer et céder une nouvelle iconographie est la suivante : - définition du cahier des charges des illustrations avec CLIENT et l illustrateur (thème, style, couleurs, ) ; - réalisation d une série d illustrations ; - prise en compte des remarques de CLIENT; - réalisation des aménagements à ces illustrations ; - direction artistique de la réalisation des illustrations et coordination de leur réalisation ; - cession des droits d exploitation des illustrations pour un usage monde pour une période de 10 ans, pour tout support (en France, la cession de droits d auteur s effectue obligatoirement sur une durée définie) ; - négociation des droits sur l image ; - formalisation du contrat de droit pour le/les auteurs ; - remise au CLIENT du contrat de droit. A vérifier selon contrat Le Cahier des Charges présente 2 prestations de création : - Les illustrations dans le cadre de la charte graphique et - Les visuels dans le cadre de la banque d image. Page : 20/56

21 5.4 Conception générale Objectif de la conception générale L objectif de la conception générale est de définir une architecture logicielle PROJET Travaux Les principaux travaux de conception sont : - la définition du modèle de données (ou son adaptation) ; - la définition de la structure des nouveaux programmes (ou l adaptation des structures existantes) ; - la rédaction (ou la modification) des documents de conception Produits de la phase - un document de conception (Dossier d Architecture Technique). - Un document spécifique relatif l implémentation technique de l'accessibilité sera fourni (reprise des critères pour le FO/BO, implémentation de telles ou telles balises XHTML ) : Dossier Détaillé des Spécifications d Accessibilité 5.5 Codage Objectif du codage La phase de codage est divisée en trois sous-phases très liées mais distinctes. Ces sous-phases sont : - la conception détaillée ; - le codage des programmes à proprement parlé ; - les tests unitaires. Page : 21/56

22 5.5.2 Travaux La conception détaillée est en fait l organisation des différentes procédures, variables et objets des programmes afin d écrire un code cohérent. Le codage des programmes consiste en l écriture des instructions (condition et action) qui vont agir sur les variables et objets manipulés. La conception détaillée et le codage sont effectués en suivant les recommandations décrites dans le plan d assurance qualité. Si pendant cette phase des incohérences ou des oublis sont détectés dans les spécifications détaillées la MOE devra produire et diffuser des fiches de revues décrivant l écart entre les spécifications détaillées et la solution implémentée. L équipe recette devra faire évoluer les plans de test en conséquence. Les tests unitaires permettent de vérifier que chacune des procédures envisagées dans la conception détaillée fonctionne comme attendu Produits de la phase Les trois sous-phases du codage produisent : - les codes sources de l application (code, script, ) ; - les codes HTML des pages statiques et dynamiques (gabarits HTML FO); - le document de validation des tests unitaires. - Les fiches de revues éventuelles Prise en compte de l accessibilité En terme de validation par la MOA, une phase de revue, prévue au début de cette phase de codage (technique/fonctionnel/ergonomique), est conduite par l AMOA sur un ensemble de gabarits HTML en début de développement (gabarits représentatifs et d un nombre limité < 10) ; une réunion de présentation des conclusions de cette revue pour valider les éventuelles corrections à mettre en œuvre serait alors organisée Cette phase initiale d analyse sera complétée par des échanges interactifs de travail (sous forme de réunions de travail sollicitées par la MOE et par exemple de sous forme de questions/réponses formalisées dans un environnement partagé tel que TRACK). Page : 22/56

23 5.6 Tests d intégration (recette «interne») Une recette «interne» qui est sous la responsabilité du Titulaire qui a pour objectif de vérifier un premier niveau de conformité des livrables constitués de logiciel par rapport aux CCTP et aux spécifications détaillées relatifs à ces livrables. Ce travail sera effectué sur un environnement dit de recette interne par MOONLIKESTUDIO, dans des conditions similaire à celles de l environnement de recette externe afin d éliminer le risque de biais introduit par un environnement différent. Cette recette est préparatoire à la recette externe. Le processus général des tests est le suivant. A partir du plan de tests, les tests d intégration sont conduits sur la plate-forme d intégration par Axidea, s ils sont concluants, le site est déployé par la MOE sur la plate-forme de recette où la CLIENT valide les comportements avec l assistance de MOONLIKESTUDIO. Une fois les comportements validés, le site est livré sur la plateforme de production et rendu accessible au grand public. Ce processus général pourra être adapté marginalement pour répondre à des contraintes particulières, non connues aujourd hui, de mise en ligne. Le plan de test décrit : - les principes généraux des tests ; - pour chaque rubrique ou fonction à tester : o le périmètre de la rubrique ou fonction à tester ; o les ressources nécessaires pour conduire le test ; o les cas de tests et résultats attendus Objectifs des tests d intégration Les tests d intégration permettent de vérifier que les différentes fichiers sources ayant évolués fonctionnent toujours ensembles et au cœur de l offre PROJET. Ces tests d intégration sont nécessaires car : - différentes évolutions peuvent être traitées concurremment ; - une évolution peut nécessiter des modifications sur de très nombreux fichiers sources ; Page : 23/56

24 - une évolution peut nécessiter l intervention de deux ou plus de développeurs. Les tests d intégration permettent de valider toute la chaîne fonctionnelle de l offre PROJET. Les tests d intégration autorisent une correction rapide des anomalies et autres disfonctionnement repérés pendant cette phase Prise en compte de l accessibilité Le plan d assurance qualité qui sera proposé par la MOE devra préciser les moyens mis en œuvre pour réaliser les tests de conformité aux critères d'accessibilité lors de la phase d intégration (à définir une fois l environnement cible défini) Travaux Les tests d intégration s effectuent en utilisant un serveur d intégration. Ce serveur est une copie similaire à la plate-forme de production sur lequel les fichiers sources ayant évolués ont été copiés. Afin de faciliter les tests et de leur donner une «réalité», des données issues de la plate-forme de production sont utilisées. Les tests d intégrations consistent en : - la validation de la procédure de livraison des éléments ayant évolués ; - le déroulé du plan de test décrit précédemment. Toutes les anomalies identifiées lors des tests d intégration sont traitées immédiatement par les équipes de développement. Une nouvelle livraison sur la plate-forme des tests d intégration et une nouvelle phase de tests sont alors organisées. Et ce, jusqu à ce qu il n y ait plus d anomalies identifiées Produits de la phase Pour chaque correction, chaque évolution majeure, le dossier des tests d intégration comprend : - les objectifs du test ; - une description succincte de la rubrique, de la page, de la fonctionnalité à tester ; Page : 24/56

25 - le résultat des tests pour chaque élément à tester ainsi que les modalités de test de l élément considéré ; - le tableau de synthèse des résultats obtenus. 5.7 Livraison itérative Déroulement La livraison itérative fait suite aux expressions de besoins et à la rédaction du dossier de spécifications fonctionnelles détaillées. Chacune de ces livraisons se déroule comme présenté ci-dessous, dans la suite logique d une phase de codage et de tests d intégration : 1. information à la MOA de mise à disposition sur le serveur de RECETTE de l itération, via un mail. Ce mail est accompagné d une «fiche de livraison itérative» (Microsoft Word). 2. Selon le périmètre de l itération, la livraison peut être accompagnée par une réunion de travail permettant de présenter et de parcourir les éléments livrés. 3. Des tests sont effectués part de la MOA : le retour de ces tests conditionne la prise en compte de ceux-ci dans l itération suivante ou non. Le délai de retour et le volume de modifications sont à prendre en compte pour les délais de relivraison. Ces retours sont faits via l outil mis à disposition par la MOE permettant de relier les remarques et corrections à l itération concernée. 4. Une consolidation des spécifications détaillées est faite en deux phases, lors du codage et suite à la validation de l itération : Une mise à jour pourra être livrée en même temps que la fiche d itération, la deuxième mise à jour liée à l itération étant liée à la validation de la livraison concernant la couverture du besoin fonctionnel. 5. Un rapport de l état de l itération et des tests peut être édité, selon un certain nombre de critères de sélection. Page : 25/56