plan assurance qualite - moonlike studio · plan assurance qualite . p.a.q. moonlike studio – 9,...

P.A.Q. MOONLIKE STUDIO – 9, quai Aulagnier – 92600 – Asnières Sur Seine

Contact Mail : [email protected]

TVA Intra-Communautaire : FR 15 452921422 RCS PARIS : B 452 921 422

Page : 1/56

PLAN ASSURANCE QUALITE




Page : 2/56

Sommaire

1 Objet et domaine d’application ............................................................................ 6

1.1 Objet............................................................................................................. 6

1.2 Domaine d’application .................................................................................. 6

1.3 Documents applicables et documents de référence..................................... 7 1.3.1 Documents applicables............................................................................. 7 1.3.2 Documents de référence .......................................................................... 7 1.3.3 Normes existantes .................................................................................... 7

1.4 Modalités d’évolution du PAQ ...................................................................... 7

2 Dispositions générales ........................................................................................ 8

2.1 Présentation générale du projet ................................................................... 8 2.1.1 Contexte et objectifs ................................................................................. 8 2.1.2 Périmètre du projet ................................................................................... 8 2.1.3 Environnement technique ......................................................................... 8

2.2 Organisation................................................................................................. 8

2.3 Suivi du projet .............................................................................................. 9 2.3.1 Le comité de pilotage MOE-MOA ............................................................. 9 2.3.2 Le comité de coordination MOE-MOA ...................................................... 9 2.3.3 L’équipe projet MOONLIKESTUDIO (en fonction du périmètre projet : les CV sont présentés au CLIENT) ......................................................................... 10 2.3.4 Les modes de communication ................................................................ 11 2.3.5 Gestion des réunions.............................................................................. 11

2.4 Suivi de l'avancement ................................................................................ 12




Page : 3/56

3 Outils du projet .................................................................................................. 13

3.1 Outils de gestion et de documentation ....................................................... 13

3.2 Outil de gestion de la configuration ............................................................ 13

3.3 Outils de sauvegarde ................................................................................. 13

4 Méthodes et référentiels .................................................................................... 14

5 Description des activités du projet ..................................................................... 14

5.1 Reprise de l’existant ................................................................................... 14 5.1.1 Appropriation technologique ................................................................... 15 5.1.2 Appropriation organisationnelle .............................................................. 15 5.1.3 Récupération des codes et documentations........................................... 16 5.1.4 Bilan de la phase de reprise ................................................................... 17 5.1.5 Interface avec l’hébergeur ...................................................................... 17

5.2 Spécifications des évolutions ..................................................................... 17 5.2.1 Objectif des spécifications ...................................................................... 18 5.2.2 Travaux................................................................................................... 18 5.2.3 Produits de la phase ............................................................................... 18

5.3 Design, ergonomie, graphisme .................................................................. 19 5.3.1 Ergonomie et graphisme......................................................................... 19 5.3.2 Produits de la phase ............................................................................... 19 5.3.3 Nouvel espace coloriel............................................................................ 19 5.3.4 Prise en compte de l’accessibilité ........................................................... 20 5.3.5 Iconographie........................................................................................... 20

5.4 Conception générale .................................................................................. 21 5.4.1 Objectif de la conception générale.......................................................... 21 5.4.2 Travaux................................................................................................... 21 5.4.3 Produits de la phase ............................................................................... 21

5.5 Codage....................................................................................................... 21 5.5.1 Objectif du codage.................................................................................. 21




Page : 4/56

5.5.2 Travaux................................................................................................... 22 5.5.3 Produits de la phase ............................................................................... 22 5.5.4 Prise en compte de l’accessibilité ........................................................... 22

5.6 Tests d’intégration (recette « interne »)...................................................... 23 5.6.1 Objectifs des tests d’intégration.............................................................. 23 5.6.2 Prise en compte de l’accessibilité ........................................................... 24 5.6.3 Travaux................................................................................................... 24 5.6.4 Produits de la phase ............................................................................... 24

5.7 Livraison itérative ....................................................................................... 25 5.7.1 Déroulement ........................................................................................... 25 5.7.2 Produits de la phase ............................................................................... 26

5.8 Validation finale.......................................................................................... 26 5.8.1 Recette probatoire (recette de vérification d’aptitude ou VA).................. 27 5.8.2 Mise en place.......................................................................................... 44 5.8.3 Recette définitive (validation de service régulier ou VSR) ...................... 44

5.9 Le transfert de compétence........................................................................ 45

5.10 La garantie ................................................................................................. 45 5.10.1 Déclaration d’anomalie ........................................................................... 46 5.10.2 Démarche de résolution.......................................................................... 46 5.10.3 Délais de prise en compte ...................................................................... 46 5.10.4 Délais de résolution ................................................................................ 47

5.11 Maintenance corrective .............................................................................. 47 5.11.1 Objet de la maintenance corrective ........................................................ 47 5.11.2 Démarche de résolution.......................................................................... 47 5.11.3 Délais de prise en compte ...................................................................... 48 5.11.4 Délais de résolution ................................................................................ 48

5.12 Maintenance évolutive................................................................................ 48 5.12.1 Objet de la maintenance évolutive.......................................................... 48 5.12.2 Démarche de réalisation......................................................................... 49 5.12.3 Délais de prise en compte ...................................................................... 49




Page : 5/56

5.12.4 Délais de réalisation ............................................................................... 49

5.13 Suivi ........................................................................................................... 49 5.13.1 Activités récurrentes ............................................................................... 49 5.13.2 Activités ponctuelles ............................................................................... 50 5.13.3 Modalités de reporting vers la CLIENT ................................................... 51

5.14 Outil de gestion en ligne (gestion des modifications) ................................. 51

5.15 Gestion de la documentation...................................................................... 52 5.15.1 Objectifs.................................................................................................. 52 5.15.2 Règles de gestion et règles de nommage .............................................. 52 5.15.3 Les documents du projet ........................................................................ 52

5.16 Macro-planning........................................................................................... 53

6 Les différents environnements techniques mis en place et les responsabilités associées.................................................................................................................. 54

7 Le dispositif de contrôle qualité mis en place .................................................... 54

8 Responsabilités ................................................................................................. 54

8.1 Obligations de MOONLIKESTUDIO........................................................... 54

8.2 Obligations de la CLIENT........................................................................... 55




Page : 6/56

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 : 7/56

1.3 Documents applicables et documents de référence

1.3.1 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.

1.3.2 Documents de référence - CAHIER DES CHARGES - PROJET

1.3.3 Normes existantes - norme ISO 9000 sur la « Gestion de la qualité et assurance de qualité », - norme AFNOR Z67-130 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 P.A.Q. 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 : 8/56

2 Dispositions générales

2.1 Présentation générale du projet

2.1.1 Contexte et objectifs

2.1.2 Périmètre du projet Dans le cadre de ce projet, MOONLIKESTUDIO est missionné pour :

2.1.3 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 : 9/56

2.3 Suivi du projet

2.3.1 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.

2.3.2 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 : 10/56

- 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.

2.3.3 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 : 11/56

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.

2.3.4 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).

2.3.5 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 : 12/56

- 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 : 13/56

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 : 14/56

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 : 15/56

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.

5.1.2 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.


- prendre connaissance des procédures ; - rencontrer les intervenants principaux au cours d’une réunion de démarrage

de la maintenance ;




Page : 16/56

Rôle CLIENT - s’assurer de la présence des différents participants à la réunion de démarrage

de la maintenance.

5.1.3 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.


- 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 : 17/56

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).

5.1.4 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é.

5.1.5 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 : 18/56

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

5.2.2 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.

5.2.3 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 : 19/56

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.

5.3.1 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.

5.3.2 Produits de la phase - Document de charte graphique et référentiel associé ;

5.3.3 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 : 20/56

- sur la base du choix de CLIENT, habillage des différents écrans présentés sur maquettes papier (2 à 3 maquettes).

5.3.4 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.

5.3.5 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 : 21/56

5.4 Conception générale

5.4.1 Objectif de la conception générale L’objectif de la conception générale est de définir une architecture logicielle PROJET.

5.4.2 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.

5.4.3 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

5.5.1 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 : 22/56

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.

5.5.3 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.

5.5.4 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 : 23/56

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 plate-forme 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.

5.6.1 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 : 24/56

- 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.

5.6.2 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).

5.6.3 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.

5.6.4 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 : 25/56

- 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

5.7.1 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 : 26/56

5.7.2 Produits de la phase Chaque livraison possède une « fiche de livraison itérative » indexée et comprenant les informations suivantes :

• Les auteurs

• Les destinataires

• Le rappel du périmètre fonctionnel

• Les paramètres de connexion

• Le cheminement de test

• Le respect de l’expression de besoin, indiquant les éventuelles digressions, et présentant les modifications majeures mises en place

• La complétude de l’itération, notifiée de 0 à 100%, avec une description des éléments manquants dans le cas d’une complétude inférieure à 100%

Le suivi et les retours sur les livraisons sont centralisés dans un outil web-based (TRACK), il permet d’accéder aux fiches d’itération, et aux retours effectués par la MOA. Cette fiche de livraison est complétée par une mise à disposition de la liste des retours de TRACK (liste triée par statut). Les spécifications détaillées subissent un enrichissement régulier au cours de ces livraisons, ces livrables sont mis à disposition sous forme de version du document initial.

5.8 Validation finale Les produits ensuite livrés doivent être validés par CLIENT. Pour ce faire, trois sous-étapes sont nécessaires :

- la recette probatoire (recette de vérification d’aptitude ou VA); - la mise en place sur la plate-forme de production; - la recette définitive (validation de service régulier ou VSR).

Cette recette est de la responsabilité du maître d’ouvrage. Toutefois, Axidéa propose son assistance à la CLIENT afin d’effectuer cette recette.




Page : 27/56

5.8.1 Recette probatoire (recette de vérification d’aptitude ou VA)

5.8.1.1 Objectifs de la recette probatoire La recette probatoire consiste à vérifier, sur la plate-forme de recette, la bonne conformité des travaux effectués par MOONLIKESTUDIO au regard des spécifications ou du cahier des charges validés par la CLIENT.

5.8.1.2 Travaux Les tests de recette probatoire consistent en des enchaînements fonctionnels permettant de vérifier que :

- le fonctionnement des nouveaux produits livrés est conforme aux spécifications;

- le fonctionnement général n’a pas été impacté par la dernière livraison. Pour ce faire la MOA rédigera un cahier de recette qui devra permettre d’apprécier la qualité de l’application livrée dans son intégralité, fonctionnalité par fonctionnalité.




Page : 28/56

5.8.1.3 Cahier de recette

Le cahier de recette sera composé :




Page : 29/56

- D’un plan de test : liste de cas de tests rassemblés par fonctionnalité. Les cas de test représentent les cas qu’il est important de vérifier car nécessaires au bon fonctionnement de l’application. C’est une sorte de check-list de la recette.

- De fiches de test : chaque fiche est composée de 4 onglets : un mode opératoire (recommandations), un jeu de test permettant la saisie de paramètre si nécessaire, d’un scénario indiquant les enchainements à tester, un tableau de bord récapitulatif (automatique)

- La fiche : contient un scénario qui déroule sous forme de suite d’actions tous les traitements qu’il est possible d’effectuer sur une fonctionnalité donnée. Dans chaque fiche on retrouvera tous les cas de tests liés à la fonctionnalité testée ainsi que les enchaînements menés pour les tester.




Page : 30/56




Page : 31/56

- Jeux d’essai : données pré requises pour le déroulement d’un scénario de recette. Ces jeux d’essais seront externalisés afin que les scenarii puissent être rejoués indéfiniment. Les travaux de recette probatoire sont réalisés sur la plate-forme de recette. Les données utilisées sont les données réelles de la plate-forme de production. Le mode




Page : 32/56

d’accès à la plate-forme est un mode Web sécurisé par un firewall, comme pour les accès à la plate-forme de production. Le cahier de recette sera également fourni à la MOE afin qu’elle puisse dérouler les tests avant les livraisons du logiciel à la MOA.

- Tableau de bord : récapitulatif automatique permettant de visualiser les différents problèmes, c’est cet onglet qui permettra l’édition du tableau de bord général, présenté dans les paragraphes suivants.




Page : 33/56

Livraison de l’application La livraison est reçue par la MOA en provenance de la MOE. Elle doit contenir :

- Un bordereau de livraison établi par la MOE listant les éléments livrés et décrivant leur configuration (identification, définition et version) ;

- Les composants logiciels implémentant les fonctionnalités identifiées du lot concerné, le cas échéant ;

- La documentation des composants logiciels livrés, le cas échéant. - La liste des composants logiciels impactés par les modifications apportées au

logiciel (nouvelles fonctionnalités, évolutions, corrections de fiches d’anomalies).

- La liste des fiches d’anomalies détectées dans les livraisons précédentes et corrigées pour cette livraison.

- La liste des fiches tests passées lors de la recette interne MOE suite aux modifications apportées au logiciel pour s’assurer qu’il n’y a pas de régression sur les modules impactés par celles-ci.

- La liste des corrections de fiches d’anomalies programmées pour la prochaine livraison.

Avant le démarrage de la recette probatoire, MOONLIKESTUDIO doit valider le bon fonctionnement de l’environnement installé sur la plate-forme de recette afin de s’assurer que les tests de la MOA peuvent être engagés dans les meilleures conditions. Le nombre de livraisons effectuées par MOONLIKESTUDIO est à définir dans le document d’organisation de recette (à définir pour chaque recette).

Gravité des anomalies :

Niveau Gravité Définition (issue du CCAP) Seuil de rejet d’une livraison

Délai de correction & livraison

1 Bloquante Situation d’urgence ou de blocage provoquant l’arrêt complet du système ou l’indisponibilité du service.

Dés 1 anomalie Au fil de l’eau




Page : 34/56

2 Sévère

Anomalie ayant un impact significatif sur tout ou partie du service offert et rendant des fonctionnalités importantes indisponibles sans qu’aucune solution de contournement acceptable n’ait été fournie ; Sont aussi classées dans cette catégorie les anomalies entraînant une perte d’intégrité des données sans correction possible via l’application. Enfin nous y ajoutons les anomalies dues à un non-respect des éléments de volumétrie et des performances de l’application.

Dés que 30% des scenarii de recette sont bloqués.

Au fil de l’eau

3 Majeure

Anomalie rendant une fonctionnalité indisponible mais pour laquelle il existe une voie de contournement ; Sont aussi classées dans cette catégorie les anomalies entraînant une perte d’intégrité des données réversible via l’application.

Pas de seuil Pour la livraison suivante

4 Mineure Anomalie mineure n’entachant pas de façon significative le bon fonctionnement d’une fonctionnalité (exemple : défaut de présentation)

Pas de seuil Pour la livraison suivante

Tableau 1




Page : 35/56

Démarrage de la recette - Critères d’acceptation de la première livraison et de démarrage de la recette probatoire : Un échantillon de scénarios de tests fonctionnels est sélectionné par la MOA (y compris de la non régression) ne pouvant excéder 20% du plan de test sur des fonctions jugées « critiques » (ie indispensable à la bonne exécution du logiciel, un dysfonctionnement de cette fonction étant fatale pour les missions assumées par celui-ci). Si les seuils de rejet de la livraison définis dans le tableau ci-dessus et ramenés à l’échantillon testé sont dépassés, la livraison de la MOE sera rejetée. Plus précisément la livraison sera rejetée si la MOA détecte une anomalie bloquante ou si plus de 30% des scenarii choisis sont bloqués.

Echéance de la recette probatoire - Critères d’acceptation de la recette Avant l’acceptation de la recette, des tests de montée en charge sont organisés et réalisés. Leurs modalités sont définies dans le document d’organisation de la recette. Il sera aussi effectué une revue technique du code généré pour vérifier la prise en compte des critères d’accessibilité, revue formalisée dans le cahier de recette. Ces tests peuvent donner lieu à des anomalies qui seront intégrées à la liste des anomalies résiduelles de la recette provisoire. Au terme de la recette la MOA effectue une analyse des anomalies résiduelles et prend la décision de prononcer ou non la recette probatoire. Le tableau ci-dessous récapitule les cas de figures identifiés. Etat des lieux des anomalies résiduelles à l'échéance de la recette probatoire

Décision Actions MOE

Aucun dysfonctionnement La recette probatoire est prononcée sans réserve

- Déployer les nouveaux éléments sur la plate-forme de production.

Dysfonctionnements mineurs (< 3 par fiche de test)

La recette probatoire est prononcée avec réserve

- Corriger les anomalies résiduelles pour la prochaine livraison. - Déployer les nouveaux éléments sur la plate-forme de production (après décision du comité de pilotage de la recette).




Page : 36/56

Dysfonctionnements bloquants, sévères ou majeurs.

La recette probatoire n’est pas prononcée.

- Corriger Les anomalies résiduelles pour la prochaine livraison. - Refaire une livraison pour présentation à la recette.

Déroulement de la recette Les tests de recette probatoire sont conduits par la CLIENT avec le support de MOONLIKESTUDIO. Ce support consiste en :

- une aide à la définition des scénarios de tests ; - une aide au passage de certains scénarios de tests ; - une aide à l’analyse des comportements de l’application ;

Le délai de la recette et le nombre de livraisons sont à définir dans le document d’organisation de la recette. Cycle de vie d’une anomalie (Les bloquantes et sévères ne passent pas par le comité de pilotage)




Page : 37/56

Découv erte d'une anomalie

Ouverte

Clôturée

( Correction validée )

( Correction non validée )

Annulée

Evolution

En cours de traitement

Corrigée

Livrée

Liv raison

Correction et test

Test

( Conforme aux spécifications )

( Non conforme aux spécifications )

( Non reproductible - Demande de complément )

( Anomalie )

( Non anomalie ou Doublon )

AXIDEACOMITE DE PILOTAGE DE RECETTECNAMTS

Périmètre de la MOA : Chaque non-conformité constatée lors de la recette fait l’objet d’une fiche d’anomalie. En cas d’intervenants multiples sur la recette, le chef de projet MOA recette pour la CLIENT est responsable de la vérification des pertinences des fiches saisies et du niveau de gravité indiqué et sera l’interlocuteur du chef de projet MOE recette. Deux (2) sources de détection d’une anomalie existent : - Par scénarii de recette : si le résultat des tests est différent du résultat attendu. - Par le test « du singe » : si un dysfonctionnement est détecté en dehors des scenarii. Dans les deux cas, la MOA doit créer une fiche d’anomalie la plus détaillée possible (causes, contexte, manipulations effectuées, copie d’écran).




Page : 38/56

Dans le cas où l’anomalie provient d’un scénario la MOA indique la référence du scénario et met à jour la fiche de test associée. Les modalités de mise à jour du plan de test et des fiches de test seront indiquées dans le cahier de recette. De manière à favoriser la tenue du délai de la phase de recette : - Les anomalies bloquantes et sévères seront transmises à MOONLIKESTUDIO au fil de l’eau pour correction dans les plus brefs délais. Ceci doit permettre de minimiser la durée des blocages potentiels des scénarii de recette. - Les anomalies majeures et mineures seront transmises de manière groupée avant les comités de pilotage de manière à ce qu’elles puissent y être discutées et priorisées. La fréquence des comités de pilotage (chaque fin de journée, 1 fois par semaine…) est à définir dans le document d’organisation de la recette. Une fois les anomalies corrigées et livrées par la MOE, la MOA doit tester et valider ou non leur correction. Les étapes préconisées pour ce faire sont les suivantes :

- Etape 1 : passage des tests de non régression sur les fonctions « critiques » (définies dans le plan de test) susceptibles d’être impactées. Pour déterminer ces fonctions la MOA s’appuiera sur les indications fournies par la MOE dans le bordereau de livraison (qui analyse les impacts et indique la liste des fonctions nécessitant des tests de non régression). Si une régression bloquante, sévère ou majeure est détectée la livraison peut être rejetée par la MOA. Si une régression mineure est détectée elle prend une gravité majeure et doit donc être corrigée avant la prononciation de la recette probatoire.

- Etape 2 : Passage des scénarii de recette relatifs aux fonctions livrées. Si les corrections sont validées la MOA met à jour les états des anomalies (voir le paragraphe cycle de vie des anomalies).

- Etape 3 : Passage des scenarii de recette restants (y compris non régression). La MOA saisit les anomalies détectées au fil de l’eau.

Ce mode de fonctionnement permet de pouvoir revenir sur une correction si elle impacte des fonctions « critiques ».




Page : 39/56

Périmètre de la MOE : Les anomalies bloquantes et sévères sont reçues par la MOE de façon unitaire au fil de l’eau. Elles sont prioritaires et doivent donc être traitées dès leur réception sans attendre le comité de pilotage de recette suivant. Les anomalies majeures et mineures sont transmises à la MOE avant le comité de pilotage de recette. La MOE en prend connaissance et en fait une première analyse pour le comité de pilotage de recette. Les états des anomalies évoluent suite au comité de pilotage comme indiqué dans le paragraphe cycle de vie d’une anomalie. Livraisons (après test incluant les tests de non régression sur l’environnement de la MOE) : - Livraison et validation des corrections d’anomalies bloquantes et sévères (livraisons « à chaud ») : les temps de livraisons « à chaud » doivent être très courts pour ne pas invalider les tests MOA pendant une longue période (à valider entre les chefs de projet recette MOA et MOE). De plus la MOE doit alerter la MOA lors de ces livraisons afin que celle-ci puisse terminer ses tests en cours. La validation des corrections d’anomalies bloquantes et sévère se fait au fil de l’eau. - Livraison et validation des corrections d’anomalies majeures et mineures : ces corrections sont livrées en même temps que l’intégralité de l’application. Les délais sont définis dans le tableau de définition des gravités d’anomalies. Toutefois si la MOE estime avoir corrigé assez d’anomalies pour effectuer une livraison avancée cela reste possible et peut être organisée avec le chef de projet recette MOA. La validation de ces corrections se fait dans le cadre du passage des scenarii de recette suite à la livraison intégrale de l’application. Il est demandé à la MOE de fournir à la MOA les éléments permettant la mise à jour des indicateurs définis plus loin dans le tableau de bord de pilotage (extraction quotidienne du nombre d’anomalies par état de l’outil de gestion des anomalies…). Comités de pilotage de recette Participants :

- Chef de projet recette MOA - Chef de projet recette MOE




Page : 40/56

La tenue régulière d’un comité de pilotage de recette permet à partir d’un tableau de bord présenté plus loin de :

- D’informer sur l’avancement de la recette : o Avancement par rapport aux cas de tests. o Avancement par rapport aux fiches de test (ou scenarii de recette). Cet

indicateur permet de vérifier s’il a été possible de mener des fonctionnalités (des scenarii) de bout en bout tout en appréciant leur qualité. Il est important de vérifier le pourcentage de scenarii bloqués. En effet, c’est un seuil de rejet de livraison.

- D’informer sur l’état du « stock » anomalies : o Répartition des « signalisations » ouvertes par la MOA. Une

signalisation étant une non-conformité relevée par la MOA qu’elle soit annulée par la suite ou non. Cet indicateur permet d’avoir une vue d’ensemble sur les non-conformités. En effet, une signalisation peut être soit annulée car incorrecte, soit encore ouverte car non analysée ou en attente de complément, soit une évolution, soit une anomalie. Un pourcentage élevé d’évolutions signifierait qu’il faudrait revoir les spécifications. Un pourcentage élevé de signalisations annulées voudrait dire que la MOA devrait vérifier l’efficacité de son organisation (ex : manque de communication car plusieurs personnes saisissent le mêmes anomalies) ou que l’environnement de test est instable. Un pourcentage élevé de signalisations ouvertes peut aussi être inquiétant dans la mesure où ce sont des anomalies qui ne sont pas prises en charge.

o Répartition des anomalies par sévérité. Cet indicateur permet d’apprécier la qualité de l’application fournie. Un pourcentage élevé d’anomalies bloquantes et sévères signifie que l’application est encore de très mauvaise qualité. En effet, cela indique que la MOA n’a pas encore commencé à relever les anomalies mineures. Une répartition optimale serait celle ou les anomalies mineures domineraient.

o Répartition des états des anomalies bloquantes, sévères et majeures. Ceci permet de connaître l’avancement des corrections d’anomalies. Le but étant que le stock d’anomalies « non corrigées » se résorbe avec le temps. Cet indicateur permet de réajuster à chaque comité de pilotage la taille des lots d’anomalies à corriger par la MOE pour les prochaines livraisons.




Page : 41/56

- De traiter les anomalies ouvertes (Voir le cycle de vie d’une anomalie). - D’informer de la validation ou non des corrections testées par la MOA. - De prioriser un nouveau lot d’anomalie à corriger pour la livraison suivante. - De prendre des décisions en fonction de l’analyse des indicateurs le cas

échéant. Un modèle de tableau de bord de pilotage de recette est défini ci-après. Il pourrait être enrichi par la suite en fonction des besoins. Il serait par exemple intéressant de visualiser l’évolution des indicateurs dans le temps. Remarque : un autre indicateur pourra être mis en place (nombre de régressions total) en s’appuyant sur la validation des cas de test au niveau du plan de test permettant d’identifier si une régression est à signaler.




Page : 42/56

Avancement de la recette - passe 1

Zoom sur les cas de test critiques Avancement des scénarii

* Total cas de tests 250 * Total des Scenarii

35

* OK 34 14% * Validés 1 3%* KO 21 8% * Non validés 2 11%

Reste à tester 195 78% Bloqués 4Reste à traiter 28 80%

Traités 7 20% 1%0% 0%

Analyse des dysfonctionnements

Total signalisations 36 Anomalies 24 Corrigées 6 Livrées 3 Clôturées 2

* Ouvertes 5 * Bloquantes 1 * Bloquantes 0 * Bloquantes 0 * Bloquantes 1* Annulées 3 * Sévères 5 * Sévères 2 * Sévères 2 * Sévères 1* Evolutions 4 * Majeures 10 * Majeures 4 * Majeures 1 * Majeures 0

Anomalies 24 * Mineures 8 * Mineures 0 * Mineures 0 * Mineures 0-6

total 16Non corrigées 5Corrigées 6Livrées 3Clôturées 2

Zoom Anomalies Zoom Anomalies bloquantes, sévères et majeures

Traités20% 80%

Graphe 3 : Répartition des signalisations

Evolutions11%

Ouvertes14%

Annulées8%

Anomalies67%

OK14%

KO8%

78%Validés

1Non validés

2Bloqués

4

Graphe 4 : Répartition des anomalies par gravité

Mineures8

Majeures10

Bloquantes1

Sévères5

Graphe 5 : Répartition des anomlies bloquantes, sévères et majeures par etat

Corrigées6

Livrées3

Clôturées2

Non corrigées

5




Page : 43/56

Tableau de bord de la recette PROJET au <date>




Page : 44/56

5.8.2 Mise en place Après la prononciation de la recette probatoire, les modifications effectuées sont livrées sur la plate-forme de production. Il s’agit donc de :

- référencer tous les produits à livrer, - noter leur version, - composer la fiche de version - déployer les produits à livrer sur la plate-forme de production.

Des scripts de mise à jour des bases de données peuvent être nécessaires à la bonne livraison des nouveaux fichiers sources. Après la livraison un rapide test général est conduit par Axidéa sur un échantillon de fiches de tests à proposer à la MOA. Ce test permet de s’assurer de la qualité de l’application livrée à la MOA.

5.8.3 Recette définitive (validation de service régulier ou VSR) Elle a pour objet de s’assurer du fonctionnement régulier des solutions livrées et qualifiées au préalable par une recette de vérification d’aptitude. Cette recette s’effectue sur l’environnement de production, lors de l’exploitation réelle de PROJET les utilisateurs normaux de la solution (Internautes, personnel de la PROJET et de son réseau…). La recette de vérification de service régulier débutera uniquement après qu’une recette de vérification d’aptitude afférente aux différents livrables faisant l’objet de la recette ait été prononcée, et que les éventuelles réserves émises aient été levées. Elle se déroulera sur une période de 30 jours. Cette période écoulée, et l’ensemble des anomalies trouvé pendant cette phase ayant été corrigé par le Titulaire, et validé par la MOA, la vérification de service régulier des livrables faisant l’objet de la recette pourra être définitivement prononcée et faire l’objet d’un PV. Les conditions sont définis dans le § précédent relatif à la VA.




Page : 45/56

Dès la recette définitive prononcée, les éléments livrés entrent dans la période de garantie.

5.9 Le transfert de compétence Le transfert de compétence permettra à d’autres équipes de prendre, éventuellement la suite de MOONLIKESTUDIO, sur la maintenance de l’offre PROJET Il s’agit donc de fournir les supports et de délivrer les formations nécessaires aux équipes externes pour qu’elles maîtrisent rapidement le sujet. Les supports sont :

- la documentation du projet ; - les supports spécifiques de formation (procédure générale de correction, liste

des intervenants chez l’hébergeur, paramètres et configuration des outils de livraison, …).

Les formations sont : - les formations du projet (utilisateur, administrateur, …) ; - la présentation de l’architecture générale ; - la présentation des processus de maintenance.

5.10 La garantie Tous les produits livrés par MOONLIKESTUDIO et recettés par la CLIENT sont garantis (3) trois mois (période ajustable en fonction de la dimension du PROJET). La garantie ne s’applique qu’aux éléments produits par MOONLIKESTUDIO durant le contrat de refonte et de maintenance de l’offre PROJET et ce, en dehors de tous produits modifiés par des tiers extérieurs à MOONLIKESTUDIO sans l’accord express de MOONLIKESTUDIO.




Page : 46/56

5.10.1 Déclaration d’anomalie Les anomalies seront déclarées via une fiche de fait technique (FFT). Une anomalie est un disfonctionnement d’une rubrique, d’une page, d’une fonction par rapport à sa description dans les spécifications ou le cahier des charges. Les différentes typologies d’anomalies sont définies dans le § relatif à la Validation par la CLIENT. C’est à partir de cette FFT que l’investigation débutera et qu’un premier diagnostic sera posé. Les moyens adéquats à mettre en œuvre seront ensuite actionnés. Les interventions de maintenance corrective s’inscrivent dans la démarche générale d’un projet informatique. Les phases de conception, codage, tests d’intégration, tests de recette devront être conduites pour s’assurer que la correction effectuée est valide.

5.10.2 Démarche de résolution Les principaux éléments guidant MOONLIKESTUDIO pour la correction devront être détaillés dans une fiche de fait technique (FFT). C’est à partir de cette FFT que l’investigation débutera et qu’un premier diagnostic sera posé. Les moyens adéquats à mettre en œuvre seront ensuite actionnés. Si nécessaire, MOONLIKESTUDIO interviendra sur la plate-forme de production afin de recueillir le maximum d’élément pour son diagnostic. Les corrections des anomalies s’inscrivent dans la démarche générale d’un projet informatique. Les phases de conception, codage, tests d’intégration, tests de recette devront être conduites pour s’assurer que la correction effectuée est valide.

5.10.3 Délais de prise en compte Les délais afin de poser un premier diagnostic et déterminer les moyens nécessaires à la correction sont les suivants :

- les FFT bloquantes : quatre heures ouvrées ; - les FFT majeures : un jour ouvrés ; - les FFT mineures : deux jours ouvrés.




Page : 47/56

Les anomalies non reproductibles posent un problème épineux car, par essence, il est impossible de les reproduire à volonté. Les délais indiqués ci-dessus ne peuvent s’appliquer.

5.10.4 Délais de résolution Les anomalies bloquantes seront traitées avec une forte priorité. Si une correction rapide n’est pas possible, une solution de contournement sera recherchée et mise en œuvre si celle-ci est viable pour les internautes. Dans tous les cas, les délais de résolution des anomalies seront précisés lors du diagnostic du fait technique.

5.11 Maintenance corrective

5.11.1 Objet de la maintenance corrective L’objet de la maintenance corrective est la correction des disfonctionnements identifiés. Il peut s’agir :

- d’une fonction donnant des résultats erronés ; - d’une rubrique (ou page) ne délivrant pas les contenus attendus ; - d’une fonctionnalité ne répondant pas comme décrit dans les spécifications ou

le cahier des charges. La maintenance corrective peut intervenir sur les différents éléments de l’offre PROJET afin de réaliser les corrections.

5.11.2 Démarche de résolution Les principaux éléments guidant MOONLIKESTUDIO pour la correction devront être détaillés dans la fiche de fait technique (FFT). C’est à partir de cette FFT que l’investigation débutera et qu’un premier diagnostic sera posé. Les moyens adéquats à mettre en œuvre seront ensuite actionnés. Si nécessaire, MOONLIKESTUDIO interviendra sur la plate-forme de production afin de recueillir le maximum d’élément pour son diagnostic.




Page : 48/56

Les interventions de maintenance corrective s’inscrivent dans la démarche générale d’un projet informatique. Les phases de conception, codage, tests d’intégration, tests de recette devront être conduites pour s’assurer que la correction effectuée est valide. Une réunion mensuelle avec la CLIENT permettra de faire le point sur l’ensemble des demandes de correction traitées et à traiter.

5.11.3 Délais de prise en compte Les délais afin de poser un premier diagnostic et déterminer les moyens nécessaires à la correction sont les suivants :

- les FFT bloquantes : quatre heures ouvrées ; - les FFT majeures : un jour ouvrés ; - les FFT mineures : deux jours ouvrés.

Comme pour les anomalies, les corrections envisagées suite à un problème non reproductibles ne pourront vraisemblablement pas être diagnostiquées dans les délais prévus.

5.11.4 Délais de résolution Comme pour les anomalies, les demandes de correction bloquantes seront traitées avec une forte priorité. Si une correction rapide n’est pas possible, une solution de contournement sera recherchée et mise en œuvre si celle-ci est viable pour les internautes. Dans tous les cas, les délais de résolution des demandes de correction seront précisés lors du diagnostic du fait technique.

5.12 Maintenance évolutive

5.12.1 Objet de la maintenance évolutive La maintenance évolutive consiste en la prise en la réalisation des rubriques et fonctionnalités non décrites dans le cahier des charges initial du site.




Page : 49/56

La maintenance évolutive sera l’une des tâches principale de la maintenance de l’offre PROJET.

5.12.2 Démarche de réalisation Chaque évolution est traitée comme un projet à part entière. Les étapes du traitement sont celles de la réalisation d’un logiciel : spécification, conception, codage, tests d’intégration, recette. L’ensemble des livrables associés au projet est mis à jour (planning détaillé, documentations…). La CLIENT et MOONLIKESTUDIO devront prendre en charges les travaux qui leur incombent dans ces différentes phases. Il s’agit notamment pour la CLIENT de fournir tous les éléments qui permettront de spécifier fonctionnellement et techniquement l’évolution à réaliser. Une réunion mensuelle avec la CLIENT permettra de faire le point sur l’ensemble des demandes d’évolution traitées et à traiter.

5.12.3 Délais de prise en compte MOONLIKESTUDIO proposera à la CLIENT un projet de réalisation de l’évolution (planning, ressources mise en œuvre, architecture générale de la solution) dans les 5 jours ouvrés.

5.12.4 Délais de réalisation Le délai de réalisation sera fixé dans le projet de réalisation de l’évolution (cf. paragraphe précédent).

5.13 Suivi Le suivi général de l’offre PROJET se décompose en des activités récurrentes quotidiennes et des activités ponctuelles.

5.13.1 Activités récurrentes Les activités récurrentes sont des activités d’administration des bases de données, de vérification des états des systèmes et de veille technologique.




Page : 50/56

Administration des bases de données Les travaux d’administration des bases de données consistent en :

- la vérification de l’intégrité des données ; - la vérification de la cohérence des données ; - la vérification des index des différentes tables ; - la vérification des espaces disques utilisés par les bases de données et la

capacité d’expansion possible.

Vérification des systèmes La vérification des systèmes s’attache à évaluer le fonctionnement du système d’exploitation et des applications. Les principaux points à surveiller sont :

- l’état des disques des différents serveurs ; - l’état des index du moteur de recherche ; - les résultats des exécutions des opérations quotidiennes.

Veille technologique Une veille technologique permanente est nécessaire. Elle permet d’être alerté sur les principaux problèmes de hacking, les failles des logiciels utilisés, les nouvelles fonctionnalités disponibles et pouvant être intéressante pour PROJET.

5.13.2 Activités ponctuelles

Upgrades logiciels L’upgrade de logiciels consiste en la mise à jour de versions logicielles. Ces mises à jour peuvent s’avérer nécessaires pour des raisons de sécurité, de performance ou de service. Après validation sur la plate-forme de recette. Une distribution sur l’ensemble des serveurs en production sera effectuée. Pour mener à bien cette phase, une bonne coordination avec l’hébergeur est nécessaire. A la suite de l’upgrade, la documentation sera mise à jour.




Page : 51/56

5.13.3 Modalités de reporting vers la CLIENT Un suivi en ligne est disponible au jour le jour. Un rapport d’activité trimestriel est fourni sur les charges de maintenance corrective et leur nature. Les maintenances évolutives (Bon de commande) font l’objet de reporting dissociés.

5.14 Outil de gestion en ligne (gestion des modifications) Toutes les évolutions, modifications, corrections à apporter à l’offre PROJET pourront être référencées dans un outil de gestion. Pour ce faire, toutes les demandes d’évolutions, modifications, corrections devront être consignées dans un document unique : la fiche de fait technique (cette fiche n’est pas exclusive des autres documents à produire). Ces fiches de faits techniques seront gérées grâce un outil en ligne dont les caractéristiques principales sont :

- demande d’évolution, déclaration d’anomalie ; - qualification du fait technique :

o évolution : le fait technique ne constitue pas une anomalie de fonctionnement ;

o bloquant : certaines fonctionnalités ou rubriques principales du site ne sont plus opérationnelles – le site ne fonctionne pas – aucun contournement simple n’est disponible ;

o majeur : des fonctionnalités ou rubriques secondaires ne sont plus opérationnelles ;

o mineur : une rubrique ou une fonctionnalité ne rend pas le service tel qu’attendu mais est tout de même utilisable ;

- gestion des états du fait technique. Les différents états possibles sont : o créé ; o analysé (contournement éventuel mis en place) ; o en cours de correction ; o en cours de validation ; o validé ou corrigé ;




Page : 52/56

- récapitulatif des évolutions, modifications et corrections en cours.

5.15 Gestion de la documentation

5.15.1 Objectifs La documentation est un élément essentiel dans la réussite d’un projet : en effet il doit résulter de ce projet un produit qu’il sera nécessaire de maintenir et éventuellement d’adapter en fonction de l’évolution du mode d’exploitation.

5.15.2 Règles de gestion et règles de nommage Toute la documentation doit pouvoir être livrée à la CLIENT sous format électronique éditable : au format Microsoft Office et sous format non modifiable : au format Adobe PDF. Tout document doit respecter la charte de nommage suivant : code_XXX_Date_D_version, avec

- code : avec une liste de trigrammes normée (PV, BDL, NOT, CR,...) - XXX : libellé sur 20 caractères maximum - Date : date de mise à jour au format AAAAMMJJ - Statut : D (Draft : si document en version de travail) - Version : version de l’édition diffusée

Exemple : CR_Comité MOE-MOA_20050323_v1.0

5.15.3 Les documents du projet Cette section liste les documents qui sont associés au projet.

Documentation fonctionnelle Liste et présentation des fonctions du système, des concepts et règles de gestion, description du paramétrage et des facteurs qui impactent l’organisation, description de la gestion des accès et de la confidentialité des informations (telles




Page : 53/56

que décrites dans la phase de spécifications des évolutions ou conception fonctionnelle),

Documentation utilisateur - Documentation d’administration (paramétrage, emplacement des fichiers de

configuration…); - Documentation d’exploitation (exploitation au quotidien, procédure en cas de

crash des bases) notamment à destination de l’hébergeur ; - Documentation utilisateur & administrateur du BO.

Documentation technique

- les créations graphiques ; - le dossier conception technique générale ; - les dossiers de conception techniques détaillés ; - les codes sources des programmes ; - les dossiers des tests unitaires ; - le plan de tests ; - les résultats des tests d’intégration ; - les résultats des tests de recette ; - la documentation de livraison du site.

5.16 Macro-planning - Plannings prévisionnels puis définitifs insérés dans le PAQ




Page : 54/56

6 Les différents environnements techniques mis en place et les responsabilités associées

Description des environnements (pré-production,...) et des responsabilités associées dont l’interface avec l’hébergeur et les responsabilités hébergeur / MOONLIKESTUDIO par rapport aux activités relatives à la gestion et à l’évolution de ces environnements.

7 Le dispositif de contrôle qualité mis en place Dispositifs et organisation de contrôle qualité (Revues de code…)

8 Responsabilités

8.1 Obligations de MOONLIKESTUDIO MOONLIKESTUDIO s'oblige à apporter les moyens humains et matériels et la diligence appropriée à la maintenance étendue de l’offre PROJET. MOONLIKESTUDIO s’engage à respecter les délais de réalisation prévus dans sa réponse à l’appel d’offre et dans les plannings qui seront élaborés par Axidéa et validés par la CLIENT durant le cours du projet MOONLIKESTUDIO s’engage à tenir informer régulièrement la CLIENT du déroulement du projet. MOONLIKESTUDIO s'engage à respecter les dispositions du présent Plan d'Assurance Qualité.




Page : 55/56

8.2 Obligations du CLIENT Comme le décrit de manière détaillée la proposition de MOONLIKESTUDIO, compte tenu de la nature même du projet et des prestations à réaliser, la contrepartie des obligations de MOONLIKESTUDIO au titre du marché réside dans l’indispensable collaboration active et coordonnée de la CLIENT, et de tout intervenant au marché sous la responsabilité de la CLIENT (hébergeur notamment). Cette étroite collaboration comprend des travaux réalisés en commun avec la CLIENT. La transparence et l’importance des échanges d’information pour faciliter la prise de décisions et les arbitrages communs constituent une condition déterminante du succès du projet et seule de nature à permettre la réalisation des prestations des différentes parties dans les délais prévus par le calendrier. Il est essentiel que chacun de ces intervenants de la CLIENT assure les travaux et missions à sa charge au titre des différentes phases de la solution proposée, notamment en terme de participation à la réalisation des produits attendus, de validations et décisions, ainsi qu’en terme d’identification de ressources, de fourniture d’informations, de données et autres documents, d’accès et droits sur les logiciels/progiciels/matériels et locaux des différents sites. A ce titre, la CLIENT et chacun de ses intervenants devront faire part, en temps utiles, de toute information ou difficulté rencontrées susceptibles d’avoir un impact sur le bon déroulement du projet. De même, pour permettre à MOONLIKESTUDIO de réaliser la prestation conformément aux dispositions du cahier des charges, il incombe à la CLIENT de :

- effectuer conformément à l’état de l’art dans ce domaine les sauvegardes nécessaires des données, fichiers, programmes, documentations et informations de toute nature qui pourraient être mis à la disposition de MOONLIKESTUDIO ou auxquels MOONLIKESTUDIO pourraient avoir accès dans le cadre du projet ; il est précisé que la CLIENT demeure responsable de la cohérence et de l’intégrité des données, en particulier des données du site, ceci s’entendant sous réserve des prestations incombant au titulaire en vertu du marché ;

- effectuer, en tant que de besoin dans des délais compatibles avec le calendrier du projet, les déclarations et obtenir les autorisations réglementaires et/ou administratives nécessaires pour les besoins des prestations (CNIL, …) ;




Page : 56/56

- procéder aux consultations et informations nécessaires des instances et organismes devant être consultés et informés, tout particulièrement eu égard à la nature même du projet dans la mesure où notamment il pourra entraîner des modifications des méthodes et habitudes de travail ;

- diligenter le cas échéant tout expert juridique interne ou externe de son choix, pour s’assurer de la validation juridique des spécifications et solutions présentées par le titulaire.