TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES

GESTION, SUIVI ET PILOTAGE - MAITRISE DES RISQUES PROJET

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Sommaire
Sommaire.............................................................................................................................................................................2 1 TYPE DE RISQUES PAR PHASE..............................................................................................................................................3 1.1Risques en Etude pralable et Planification........................................................................................................................3 1.1.1 Risques stratgiques...............................................................................................................................................3 1.1.2 Risques contractuels...............................................................................................................................................3 1.1.3 Risques rglementaires...........................................................................................................................................3 1.1.4 Risques dfinition de lapplication.............................................................................................................................4 1.1.5 Risques budgtaires...............................................................................................................................................4 1.1.6 Risques dorganisation............................................................................................................................................4 1.1.7 Risques ressources.................................................................................................................................................5 1.1.8 Risques de dlai.....................................................................................................................................................5 1.2 Risques Architecture Technique......................................................................................................................................5 1.3 Risques Processus Techniques........................................................................................................................................6 1.4 Risques de Mise en uvre.............................................................................................................................................6 1.5 Risques Utilisation........................................................................................................................................................ 7 1.6 Risques Scurit...........................................................................................................................................................7 1.7 Risques Maintenance.....................................................................................................................................................7 2 LISTES DAIDE LIDENTIFICATION DES RISQUES PAR PHASE.................................................................................................8 2.1 A reprendre sur chaque phase........................................................................................................................................8 2.2 Lancement du projet.....................................................................................................................................................8 2.3 Etude pralable............................................................................................................................................................9 2.4 Conception densemble..................................................................................................................................................9 2.5 Spcification fonctionnelle............................................................................................................................................10 2.6 Conception technique..................................................................................................................................................10 2.7 Prparation de la Mise en uvre...................................................................................................................................11 2.8 Ralisation et Tests.....................................................................................................................................................12 2.9 Recette......................................................................................................................................................................12 2.10 Dmarrage de lapplication.........................................................................................................................................13

Memphis / tude paliers techniques / recette fonctionnelle - page 2

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

1 TYPE DE RISQUES PAR PHASE 1.1Risques en Etude pralable et Planification 1.1.1 Risques stratgiques
Les risques stratgiques sont les risques qui en fonction des objectifs, du droulement et des rsultats attendus du projet ont des consquences directes ou indirectes sur les choix, la structure ou le positionnement de lenseigne dans son ensemble. Les risques stratgiques diffrent des autres classes de risques, non par leur nature (il peut sagir dun risque dlai par exemple), mais par leur impact. Risques stratgiques type peuvent tre classs en vnements (dlai, dysfonctionnement, ...) : affectant dune manire gnrale la productivit et les missions de lenseigne ayant un impact direct sur la relation commerciale de lenseigne avec le client affectant le rapport de lenseigne avec ces fournisseurs et avec les organismes en relation ou dpendances (outre les clients) affectant limage externe de lenseigne, et ayant un impact indirect sur la relation commerciale de lenseigne avec le client ou avec les fournisseurs et les dpendances Les consquences de ce type de risque peuvent svaluer en : Pertes financires directes et indirectes pour lenseigne. Leur valuation prcise est souvent complexe (perte dimage, par exemple) et les sommes en jeu dpassent largement le simple primtre du projet.

1.1.2 Risques contractuels

Les risques contractuels sont les risques lis aux contrats engags avec des tiers qui contraignent lapplication ou lexcution du projet. Risques contractuels type : Consquences sur le projet de lexcution de contrats diffrents que le tiers ralise par ailleurs pour lenseigne Obligation contractuelle infaisable dans le cadre du projet (calendrier, performance, recette,...) Choix par le projet d'une option en rponse une obligation contractuelle imprcise ou absente Obligations contractuelles contradictoires (ex: rfrences des normes diffrentes dans plusieurs contrats,....) Obligation contractuelle entranant des cots non rmunrs au contractant et/ou un allongement des dlais Obligation contractuelle non dfinie (processus de recette indfini, calendrier insuffisamment dfini, liste des fournitures imprcise, etc.) Rupture unilatrale du contrat par le tiers Les consquences de ce type de risque peuvent svaluer en : Paiement de pnalits Retard de livraison de la part du tiers Refus de livrer de la part du tiers Cot de contentieux Cots des actions de mise en conformit

1.1.3 Risques rglementaires

Les risques rglementaires sont les risques lis aux lgislations qui contraignent lapplication et lexcution du projet. Risques Type : Choix d'une option par le projet en rponse une obligation lgale non encore connue, imprcise ou absente Contexte rglementaire en volution
Memphis / tude paliers techniques / recette fonctionnelle - page 3

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Obligation lgale infaisable dans le cadre du projet dans son avancement actuel (calendrier, performance, vrification,...) Obligations lgales contradictoires (ex: rfrences des lgislations multiples) Les consquences de ce type de risque peuvent svaluer : en mise niveau de lapplication : cot des volutions et consquences du retard de mise disposition

1.1.4 Risques dfinition de lapplication

Les risques Dfinition de lapplication dont les risques lis la dfinition des besoins et la spcification de lapplication livrer en rponse aux attentes relles du ou des demandeurs (fonctionnalits, interfaces, performances,...). Risques Type : Expression de besoins incomplte (besoins non dfinis, mal apprhends) Couverture incomplte des besoins par les spcifications Sur-satisfaction du besoin (fonctionnalits ou performances inutiles) Rponse des besoins obsoltes Faisabilit de la spcification (ex : faisabilit d'une performance ou d'un ensemble de performances) non assure Dfinition imprcise ou inadapte des interfaces de lapplication (ex : ergonomie, IHM) Dfinition inexistante ou imprcise des contraintes prendre en compte (Qualits, logistique, production, disponibilit, fiabilit,.....) Mauvaise dfinition des objectifs de performances Difficults d'tablissement des spcifications (difficults de trouver des solutions aux besoins ou d'accord sur ces solutions) Spcification insuffisante pour valider lapplication Erreurs de Spcifications (contradiction interne, silence, ambigut, erreur dans une performance ou dans une description de fonctions ou d'interfaces, performance non dfinie ou non value) Dfinition de lapplication rpondant des contraintes diffrentes des besoins (montage contractuel, remploi de composants ou de savoir-faire,....) Dfinition de lapplication instable ou volutive Dure de projet trop longue par rapport la stabilit de la dfinition du besoin

1.1.5 Risques budgtaires

Les risques budgtaires sont les risques lis aux besoins budgtaires du projet un moment donn et la gestion de ces budgets. Risques Type : Estimations des cots projet (Affectation de personnel de lenseigne, sous-traitance, approvisionnement,...) imprcises, bties partir d'hypothses fausses (complexit du travail, productivit,...), lacunaires ou non relles Cots des ressources variant hors des limites prvues (ex : augmentation du prix ressource sur le march) Budgets prvus non compatibles avec le calendrier des engagements budgtaires du projet (Ressources budgtaires instantanes insuffisantes ou demploi diffr ou anticip) Projet dpassant les budgets que lenseigne peut allouer sur le domaine

1.1.6 Risques dorganisation

Les risques dorganisation sont les risques lis aux choix d'organisation des intervenants sur le projet : relations entre la (ou les) matrises d'ouvrage et la (ou les) matrises d'uvre, les ples de comptences, la sous-traitance interne et externe, les tiers divers. Risques Type : "Dcoupage" des responsabilits entre intervenants complexifiant la ralisation du projet (processus de transfert dinformation ou dlaboration en commun, processus de validation ou de dcision, interfaces techniques,...) Accords avec les intervenants ne permettant pas de remplir tous les objectifs projet (niveaux de performance diffrents, allocation de responsabilits incomplte, objectifs contradictoires,....)
Memphis / tude paliers techniques / recette fonctionnelle - page 4

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Moyens de matrise des intervenants (transmission de directives, exigences de management, prise de dcision, contrles des intervenants et de leurs livrables,...) insuffisants ou trop complexes pour garantir un management correct du projet Organisation de la coordination multi-projets faible ou pnalisante pour le projet Systme de dcision et de direction sur le projet, inadquat (pas de systme de rsolution des conflits ou de hirarchisation des priorits) Processus de conduite de projet ne permettant pas une direction et une visibilit suffisante Objectifs propres d'un ou de plusieurs intervenants divergeant des objectifs projet (dlais, cots, dfinition de lapplication,....) Niveau de comptence d'un intervenant insuffisant pour la tenue des objectifs projets Surcot de lorganisation du projet (gestion, interfaces, dlais de prise de dcision)

1.1.7 Risques ressources

Les risques ressources sont les risques lis la dfinition des besoins en ressources (humaines, techniques...), la gestion et aux performances de ces ressources du projet Risques Type : Monte en puissance mal gre, trop lente Conflit d'utilisation des ressources (ressources critiques sur le projet ou partages avec dautres projets) Ressources non disponibles temps ou dans les plages prvues R-affectation des ressources sur dautres projets de priorit plus forte. Ressources disponibles trop tt sur le projet et donc sans occupation productive Dfaillance d'une ressource en cours de projet (mutation, maladie, maternit, dpart,....) Insuffisance des ressources affectes au projet Qualification ou comptence insuffisante des ressources Productivit insuffisante des ressources Productivit des ressources mal estime Dfaillance, instabilit ou manque de disponibilit d'un intervenant

1.1.8 Risques de dlai

Les risques de dlai sont les risques lis au respect des engagements de dates externes et internes du projet. Risques Type : Non respect des dates Projet par les intervenants (Retard de livraison, retard dans l'approbation de documents ou la fourniture d'informations ncessaires au projet,) Mauvaise synchronisation des tches communes Estimations des dlais imprcises ou bties partir d'hypothses fausses (nature des travaux, complexit du travail, productivit,...) Planification lacunaire ou errone (tche ou liaison entre tches absente, dcoupage des tches inadquat) Etat rel de tches non vrifies ou non vrifiables (conditions exactes de fin, reporting insuffisant,...) Planning trop contraint (pas de marges, contraintes "limites" sur les ressources,....) Gnration de surcots (immobilisation de stocks, immobilisation de ressources) dus la planification Dpendance forte du planning projet envers des jalons ou des livrables dautres projets de lenseigne

1.2 Risques Architecture Technique

Les risques Architecture Technique sont les risques lis l'adquation fonctionnelle de la solution technique retenue, sa faisabilit dans le cadre du projet, sa qualit et son bon fonctionnement. Risques Type : Couverture de la spcification insuffisante (fonctionnalit, performance, qualit non implmente ou partiellement implmente) Non prise en compte ou prise en compte insatisfaisante d'une contrainte particulire dans la solution (logistique, scurit, utilisabilit,...) Dfaut de conception (non fonctionnement de la solution ou fonctionnement non satisfaisant)
Memphis / tude paliers techniques / recette fonctionnelle - page 5

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Choix dune solution base sur une tude qui ne rpond pas aux contraintes particulires du projet (ex : tude de la solution faite sur un autre projet ou pour un besoin diffrent) Performance irralisable avec la solution retenue (Fiabilit, disponibilit,...) Performance difficile obtenir (performance aux limites des capacits de l'architecture) Solution technique base sur un principe pouvant entraner des difficults d'intgration, de maintenance ou de fiabilit (composant central ou critique, technologie difficile, dcoupage en composants niveaux de difficults de ralisation trop diffrents, performance limite d'un composant central,.....) Solution imposant certains composants un niveau d'exigences trop lev pour savoir l'obtenir sur le projet ou avec ce type de technologie (ex : niveau de fiabilit suppos d'un logiciel) Dfinition insuffisante ou incomplte des composants ou des interfaces entre composants Dpendances fortes avec des applications externes actuellement en dveloppement (contexte multiprojets) Architecture rendant difficile, voire impossible, l'intgration (couplage trop fort des composants, absence de points de tests,....) Risques propres lis une technologie (ex: Client/serveur, IA, SGBD,....).

1.3 Risques Processus Techniques

Les risques Processus Techniques sont les risques lis au choix, la dfinition et la matrise des processus mis en uvre sur le projet : processus de Conception (mthode, approche,), dveloppement (outils et technologies,...), paramtrage, reprise de donnes, tests, Assurance Qualit, Gestion des corrections, Gestion des configurations,. Risques Type : Matrise insuffisante d'une technologie (pas de certitude sur les rsultats, cots d'apprentissage incompatibles avec le projet) Changement d'chelle dans l'emploi d'un processus ou dune technologie (emploi en grand dune technologie teste en petit ) Choix technologique aboutissant une solution dpasse (difficults d'approvisionnements, peu de ressources disponibles, qualit ou comptitivit des rsultats insuffisante,...) Choix d'une technologie inadapte aux objectifs viss (fiabilit ou qualit insuffisantes) Processus technique incomplet (dfinitions, tudes, vrifications absents) ou mal synchronis avec les autres processus Processus technique difficilement grable dans le projet (points de contrle, rsultats intermdiaires, visibilit, contrles,...) Qualit des donnes reprendre en dessous du niveau prvu Chane de reprise des donnes complexe ou peu performante Processus de tests ou de recette incomplets ou mal adapts (processus informels, objectifs de vrification trop limits ou trop forts) Tests ou recette non suffisants en regard de la criticit de lapplication (Compltude, formation des testeurs, dure de prparation) Assurance et contrle Qualit un niveau non compatible avec les objectifs Qualit du projet (trop formel, trop faible,.....) Gestion des configurations inexistante, mal adapte ou non respecte Gestion des corrections et volutions insuffisante ou non suivie Tests de non-rgression trop faibles

1.4 Risques de Mise en uvre

Les Risques de Mise en uvre concernent les phases de dmarrage et dvaluation de lapplication ou du systme. Risques Type : Contraintes logistiques de dploiement, d'installation ou de mise en route mal ou insuffisamment dcrites et peu compatibles avec les performances ou fonctionnalits de lapplication Description des interfaces externes diffrente des interfaces relles lors de la mise en service Spcificits du (des) site(s) de mise en service mal prises en compte par la version livre

Memphis / tude paliers techniques / recette fonctionnelle - page 6

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Application non rellement acheve (fonctionnalits, tests en environnement rel,...) et ncessitant un effort de dveloppement pendant la mise en service Anomalies en reprise des donnes (Qualit des donnes, programmes, incompatibilits,) Absence de prparation du (des) site(s) de mise en service (site, outillage, connexions, organisation, personnel,....) Sous-estimation de l'effort de mise en service (accs, dure, ressources, tches,...) Mconnaissance de l'environnement rel par les quipes charges de la mise en service Coordination insatisfaisante des quipes projet et du personnel du (des) site(s) de mise en service Basculement mal coordonn Erreurs dans le processus de basculement Nombre de dfauts non dtects en dveloppement et apparaissant la mise en service Maintenance non oprationnelle lors de la mise en service (moyens, procds,....) Scurit du systme en cours d'installation insuffisante

1.5 Risques Utilisation

Les risques utilisation sont les risques lis l'emploi de lapplication ou du systme et peuvent se rvler aprs la fin du projet. Risques Type : Inadaptation de lapplication aux conditions d'utilisation (concepts, ergonomie, fonctionnalits implmentes ou absentes, performances,...) Disponibilit oprationnelle de lapplication fournie insuffisante en regard des contraintes d'utilisation Fiabilit insuffisante du systme Non conformit de lapplication la lgislation Difficult d'apprentissage ou de mise en uvre par les utilisateurs Connaissance de lapplication par les utilisateurs insuffisante pour un emploi oprationnel rel Les consquences de ce type de risque peuvent svaluer en : Cot de rparation de lapplication pour une utilisation conforme Cot de modification du contexte d'utilisation pour adaptation lapplication Cot de remise en tat du site d'utilisation

1.6 Risques Scurit

Les risques Scurit sont les risques lis au niveau de protection assur par lapplication Risques Type : Confidentialit non garantie des informations gres Modification accidentelle des informations gres Scurit insuffisante des accs au systme Possibilit de malversation par un emploi frauduleux de lapplication Possibilit de malversation intgre la ralisation du systme Scurit des personnes et des biens compromise par l'emploi de lapplication

1.7 Risques Maintenance

Les risques maintenance sont les risques lis la rparation, l'volution et la mise jour de lapplication Risques Type : Architecture de la solution ne permettant pas ou permettant difficilement les oprations de maintenance Erreur de calcul ou de principes dans la prvision du droulement des oprations de maintenance (sousdimensionnement, inadaptation au contexte rel de maintenance,...) Flexibilit insuffisante de lapplication (concepts, architecture,...) ou incompatible avec les volutions de l'environnement de production Qualits de lapplication insuffisantes pour les oprations de maintenance (fiabilit, volutivit, testabilit,....) Application non rellement acheve (fonctionnalits, tests,...) et ncessitant un effort important de dveloppement pendant la priode de maintenance
Memphis / tude paliers techniques / recette fonctionnelle - page 7

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Technologie employe inadapte la maintenance (difficults intrinsques, perte de comptences, obsolescence,....) Documentation de maintenance insuffisante ou non jour Difficults pour assurer la non-rgression des versions Systme de gestion des configurations (identification, rgles de versionnement, procdures de mise en gestion des configurations,...) inadapt aux oprations de maintenance Passage de responsabilit et/ou de comptences des quipes de dveloppement aux quipes de maintenance inadquat Dure de vie ou de conservation des moyens de maintenance insuffisante en regard de la dure de la maintenance Htrognit trop forte du parc maintenir Inadaptation des contrats de maintenance la ralit des oprations de maintenance Inadquation et formation insuffisante du personnel de maintenance et des moyens prvus aux oprations de maintenance Les consquences de ce type de risque peuvent svaluer en : Surcot des oprations de maintenance de lapplication Cot de remise en tat de maintenabilit de lapplication Cot de modification du processus de maintenance

2 LISTES DAIDE LIDENTIFICATION DES RISQUES PAR PHASE

Ces listes sont constitues de points vrifier. Elles ne rclament pas une rponse formelle positive mais veulent centrer la rflexion sur les difficults possibles, les incertitudes et les points surveiller.

2.1 A reprendre sur chaque phase

De nouveaux lments externes remettent en cause lapplication Un ou plusieurs domaines affects par le projet sont en forte volution Le niveau dacceptation des demandeurs est satisfaisant Le niveau dimplication des acteurs est satisfaisant Les carts de charge sont recenss et expliqus. Leur ventuelle extrapolation aux tches prvues a t examine Les carts de planning sont recenss et expliqus. Leur ventuelle extrapolation aux tches prvues a t examine Le niveau de qualit des livrables intermdiaires est connu.

2.2 Lancement du projet

Lapplication est stratgique pour lenseigne La dfinition du champ du projet identifie les domaines et les mtiers impacts Les rsultats de lemploi de lapplication peuvent affecter limage de lenseigne Lapplication sinscrit dans les Plans de lenseigne (Entreprise, triennal,) Tous les domaines impacts dans le ou les mtiers, par le projet sont tudis La mise en service de lapplication aura un impact sur lorganisation du travail Les demandeurs impliqus dans le processus de construction de la note de lancement sont reprsentatifs de lensemble des acteurs concerns Les structures projet dfinies (Comits, diffusion de documentation, futurs acteurs impliqus,) couvrent bien lensemble des domaines impacts Les objectifs du projet sont connus de (diffuss ) tous les acteurs concerns Un examen des projets actuels et prvus a permis de dgager les interactions prendre en compte Les moyens de planification sont dfinis et en place Les principaux intervenants projet sont connus ou en cours de recrutement La dure de la phase dEtude pralable est correctement estime et approuve par tous Les participants de ltude Pralable sont identifis et disponibles Les Chefs de projet ont une exprience suffisante du domaine et de la conduite de projet pour mener leurs tches Les calculs de budget et de dlais prennent comme base explicite des projets similaires
Memphis / tude paliers techniques / recette fonctionnelle - page 8

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Lensemble des facteurs et influences prsente une bonne synergie

2.3 Etude pralable

Le recensement de lexistant (organisation, documentation, procdures, donnes, ) a t organis et est considr comme complet Lanalyse de lexistant a t accepte par tous les acteurs concerns par sa validation Lanalyse de lexistant a t correctement ralise : primtre, mthode, rsultats. Les demandeurs ont une bonne pratique de lidentification des besoins La dfinition de lapplication est stabilise Tous les domaines impacts par le projet sont pris en considration Lensemble des acteurs actuels recenss a t interview Les contraintes sur lapplication ayant un impact sur sa dfinition ont t inventories Les utilisateurs impliqus dans le processus de dfinition du besoin sont reprsentatifs de lensemble des acteurs concerns Les besoins sont clairement matriss par les demandeurs Les besoins recenss ont t revus et approuvs par les demandeurs Les besoins susceptibles dvolution (rglementaire, organisationnelle ou technique) sont clairement identifis La matrise douvrage a dfini lorganisation future (ou les scnarios dorganisation) associe au systme Le ou les scnarios de transition (y compris de reprise de donnes) et les contraintes de calendrier associes ont t dfinis Les besoins ont t reports dans le cahier des charges Les contraintes associes aux besoins ont t clairement identifies Les choix de solutions ont t effectus dans de bonnes conditions Les solutions proposes ont t valides par tous les acteurs Les solutions proposes sont cohrentes avec les options actuelles de lenseigne Les techniques et outils de dveloppement prvus sont matriss aujourdhui Les techniques et solutions innovantes prvues sont accessibles et bnficient dun support interne ou externe. La mise en uvre de solutions innovantes fait lobjet dune estimation claire des cots et dlais Le ou les prototypes raliss sont reprsentatifs du futur systme et bass sur des hypothses que lon peut considrer comme adaptes Les rsultats tirs de lemploi des prototypes sont clairs et non ambigus. Ils sont compris et approuvs Lestimation des cots du projet est base sur une liste dtaille et complte des travaux Lestimation des cots dinvestissement matriels et logiciels est base sur la prise en compte de lexistant, de la solution technique et des moyens de transition. Chaque poste de cot est bas sur des rfrences externes ou internes prcises. Lestimation des cots de fonctionnement est construite sur une liste de postes de cots valids par les exploitants et utilisateurs. Lanalyse des gains et contreparties attendus part dun constat de lexistant valid

2.4 Conception densemble

Les acteurs de la conception densemble ont tous les comptences et lexprience requises autant dans la matrise douvrage que dans la matrise duvre. Le modle conceptuel de communication (MCC) recense lensemble des acteurs et champs d'activit La description des donnes est satisfaisante (MCD) : formalisation, compltude et clart La description des traitements est satisfaisante (MCT) Les fonctions attendues sur chaque domaine sont clairement inventories Les carts entre besoins pris en compte dans la Conception densemble et les besoins lists pendant la phase dEtude pralable sont identifis, expliqus et leurs consquences sont connues et acceptes La modlisation est clairement comprise par la Matrise douvrage Les traitements prvus permettent de satisfaire les besoins et matrise douvrage et matrise duvre sont en accord sur ce point La cohrence entre les modles a t revue Le ou les prototypes raliss sont reprsentatifs du futur systme et bass sur des hypothses que lon peut considrer comme adaptes
Memphis / tude paliers techniques / recette fonctionnelle - page 9

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Les rsultats tirs de lemploi des prototypes sont clairs et non ambigus. Ils sont compris et approuvs La stratgie de reprise des donnes est base sur une connaissance suffisante des donnes actuelles (y compris leur niveau de qualit) et des systmes et conditions dexploitation de ces donnes Les outils de reprise des donnes ne prsentent pas de difficults ou dincertitudes de ralisation Les contraintes dorganisation sur la reprise des donnes sont clairement identifies et juges comme faisables par les acteurs concerns Les sous-projets et les lots dfinis sont prvus pour minimiser les relations et interfaces (indpendance maximale) Les sous-projets et les lots dfinis sont homognes au niveau technique et contenus Le dcoupage prvu en sous-projets favorise la tenue des dlais. Les dures et cots dintgration des sous-projets sont pris en compte dans les estimations. Le dcoupage en sous-projets favorise les tests indpendants des diffrents lots Lensemble des acteurs concerns a effectivement pris connaissance des documents et fourni son avis. Les remarques ont t prises en compte Les responsables des sous-projets ont lexprience requise Les estimations de charge prennent en compte le niveau de productivit des intervenants rels du projet

2.5 Spcification fonctionnelle

Les spcifications dtailles sont approuves par les acteurs comptents La dfinition fonctionnelle dtaille dcrit exactement la conception densemble Les cas particuliers ont t dcrits: cas derreurs, cas de reprise sur erreurs, absence dinformations, traitements exceptionnels,. Les donnes prises en compte sont homognes et compltes par rapport au MCD Les rgles de gestion et de contrle sont clairement listes et leurs interactions mutuelles ont t tudies Les tats produits sont lisibles par les utilisateurs et ne posent pas de difficults techniques de ralisation Les documentations produites pourront tre utilises sans difficults pour la suite du projet Lenchanement des crans correspond aux oprations du poste de travail et est compatible avec les principes dergonomie retenus pour les postes Les fonctions et traitements dfinis sur la phase de spcification fonctionnelle naccroissent pas la charge prvue pour le projet : dcouverte de fonctionnalits, de difficults, de rgles complexes, Lergonomie du poste est accepte par les utilisateurs terminaux et permet la productivit requise. Elle est compatible avec lenvironnement du poste. Les procdures de secours sont dfinies Les volumes de donnes migrer sont connus La qualit des donnes reprendre est connue et les procdures de test et correction sont ventuellement prvues Une valuation de la charge et de la dure de la reprise des donnes est effectue sur la base des procdures et des outils dfinis Les traitements recetter sont clairement identifis Les rles pour la recette et la prparation de la recette sont connus et accepts Les conditions dacceptation du systme lissue de la recette sont connues et acceptes La dure prvue de la recette prend en compte les difficults ventuelles (corrections, changements mineurs, ) Lenvironnement de dveloppement est en place et est dimensionn pour le nombre de dveloppeurs prvus. Lenvironnement de dveloppement est oprationnel : compatibilit et stabilit des versions de logiciels, compltude des outils, Lenvironnement de dveloppement est connu et matris par les dveloppeurs

2.6 Conception technique

Les mthodes de conception technique mises en uvre permettent dobtenir lensemble des rsultats attendus Le modle physique des donnes (MPD) et le MCD sont totalement en phase Les choix de construction du MPD sont connus, expliqus et valids Les volumes de donnes traiter sont connus et pris en compte dans le MPD Les traitements sont compltement dcoups et recenss
Memphis / tude paliers techniques / recette fonctionnelle - page 10

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

Le prototype (Performances) est reprsentatif du futur systme et bas sur des hypothses que lon peut considrer comme adaptes Les rsultats tirs de lemploi du prototype sont clairs et non ambigus. Ils sont compris et approuvs Les performances attendues sont possibles avec la solution technique retenue Les rsultats de la Conception technique ne changent pas le volume de travail prvu en Ralisation Le Manuel dexploitation est approuv par les exploitants Le Manuel dexploitation prend en compte lensemble des traitements de lapplication Le Manuel dexploitation est cohrent avec lenvironnement technique prvu Le Manuel dexploitation est bas sur les volumes dinformation rels grer Lenvironnement technique prvu est prcisment dfini par rapport aux environnements actuels La description de lenvironnement technique a t ralise avec un niveau de comptence technique suffisant. La compltude de la description de lenvironnement technique a t valide par tous les acteurs comptents et/ou concerns. Les choix denvironnement technique sont compatibles avec les Budgets projet Les choix denvironnement technique sont compatibles avec les choix des projets parallles La mise en place de lenvironnement technique est compatible avec le planning du projet

2.7 Prparation de la Mise en uvre

Les jeux d'essais ont t prpars par la matrise d'ouvrage Les utilisateurs ont une connaissance des mthodes d'laboration des jeux d'essais Tous les utilisateurs finaux ont t identifis Les procdures dorganisation sont cohrentes avec les choix et orientations dfinis dans les phases amont (Dcoupage des traitements, ergonomie, organisation cible,..) La transition entre les procdures actuelles et les nouvelles procdures est tudie Le Plan de formation est compatible avec le planning du projet : moyens disponibles, formations cales sur les besoins des utilisateurs, dates des sessions compatibles avec leurs contraintes Les supports de formation sont btis par des intervenants qui connaissent bien lapplication en dveloppement et les pratiques actuelles des Utilisateurs. Lenvironnement de formation prvu fait partie du plan de dmarrage. Le manuel Utilisateur est bti par des utilisateurs qui connaissent bien lapplication en dveloppement et les pratiques actuelles des Utilisateurs. Il a t vrifi que le Manuel Utilisateur prend en compte lensemble des traitements. Le Manuel Utilisateur recense les messages derreur prvus et les limites de lapplication Le vocabulaire et les exemples du Manuel Utilisateur sont comprhensibles des utilisateurs. Les procdures dcrites dans le manuel des procdures sont cohrentes, non contradictoires et troitement interfaces avec les autres procdures applicables conjointement ou connexes. Les obligations de service de lexploitant sont dlimites et lies des indicateurs vrifiables. Les engagements mutuels de la matrise douvrage et de lexploitant sont prciss Lexploitant a les moyens matriels, techniques et humains pour remplir ses obligations. La priode de monte en charge de lexploitant est dlimite dans le temps et dfinie en termes d'objectifs Les habilitations dfinies pour les utilisateurs sont cohrentes avec leurs autres habilitations sur dautres applications et leurs positions et statuts lenseigne. Le plan dinformation sur le dmarrage est revu avant son lancement : Cible, messages, calendrier annonc. Les contrles de donnes reprises manuellement ont t raliss Les moyens de vrification de la qualit des donnes reprises sont suffisants / faibles Les rsultats de la vrification de la qualit des donnes correspondent ce qui tait attendu et la reprise sera donc possible avec les dlais et moyens prvus. Les travaux dinfrastructure et les achats de matriels sont lancs ou prvus. Les reproductions de manuels et des supports sont lances en nombre suffisant et les exemplaires sont adresss aux acteurs concerns. Le Plan de dploiement est cohrent avec les choix denvironnement technique Le plan de dmarrage est construit en prenant en compte toutes les activits dcrites pendant la phase de PMO Le plan de dmarrage est connu et approuv par les Utilisateurs
Memphis / tude paliers techniques / recette fonctionnelle - page 11

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

2.8 Ralisation et Tests

Les rgles de programmation sont connues de tous et respectes Lenvironnement de dveloppement est matris et ses volutions gres Les spcifications fonctionnelles sont connues, comprises et suffisantes pour la ralisation, les claircissements ventuels sont reports dans la documentation Les intervenants nouveaux sur le projet ont les moyens dobtenir rapidement une connaissance fonctionnelle et la matrise de lenvironnement de dveloppement et des rgles de ralisation et de tests Des revues de code sont organises et leurs rsultats sont analyss Les problmes techniques rencontrs pendant la phase de ralisation ont t rsolus sans affecter la qualit du code. Les consquences en dlais des problmes techniques de programmation ou dintgration sont globalement gres sur le projet (pas dimpasses implicites) La couverture des tests unitaires est connue et juge comme suffisante Les dfauts relevs en tests unitaires sont tous corrigs Les tests unitaires ont permis dobtenir un niveau de qualit suffisant Les tests dintgration ont permis de mettre en uvre lensemble des relations entre les Modules / Composants / Programmes Les donnes de tests sont reprsentatives et ralistes Les performances sont mesures et satisfaisantes Les scnarios de test dintgration ont une couverture fonctionnelle suffisante pour permettre le passage en recette. Les dfauts trouvs en intgration ont tous t corrigs Lavancement des tests (essais concluants, anomalies dtectes, anomalies corriges) est connu et satisfaisant Les volutions et corrections ont fait lobjet dune programmation de qualit suffisante et ont pass des tests de non-rgression. Les contraintes de dlai nont pas entran dimpasses sur les tests Les outils de reprise de donnes ont suivi un processus de ralisation garantissant un niveau de qualit suffisant Les outils de reprise de donnes ont t tests sur des jeux dessais reprsentatifs et dans un environnement raliste. La documentation de ralisation est crite, suffisante pour la maintenance et homogne avec le code

2.9 Recette
Les utilisateurs qui ralisent la recette ont une connaissance suffisante de lapplication, des mthodes de tests et de lenvironnement Les utilisateurs qui ralisent la recette ont une disponibilit suffisante Lenvironnement de recette est stable et suivi par lquipe de dveloppement Les tests d'essais sont prpars pour tre rejouables. Les donnes employes pour la recette sont reprsentatives et suffisantes pour un test concluant Les conditions de recette (environnement et liens avec les autres applicatifs) sont dfinies Lapplicatif employ en recette est lapplicatif qui sera oprationnel ou ses carts sont recenss Lavancement de la recette (essais concluants, anomalies dtectes, anomalies corriges) est connu et satisfaisant Les contraintes de dlai nont pas entran dimpasses sur la recette Les anomalies dtectes sont correctement caractrises par les utilisateurs Les rsultats de la recette sont connus : couverture, compltude de la ralisation, utilisabilit , performances Le processus de correction des anomalies est matris : priorit, prvision du dlai, qualit du code et de la documentation, tests de non-rgression Les demandes dvolution sont recenses et matrises, leur impact en charge et dlai est connu et ne contraint pas des impasses par ailleurs. Le manuel utilisateur a t rellement employ et revu Le Procs-verbal de recette est bas sur la qualit de lapplication : nombre de dfauts et compltude de la ralisation.

Memphis / tude paliers techniques / recette fonctionnelle - page 12

TYPES DE RISQUES ET AIDES A LIDENTIFICATION DES RISQUES Gestion, suivi et pilotage maitrise des risques projet

La version de l'applicatif livre lexploitation a t compltement teste et ses spcificits (anomalies connues, carts de ralisation) sont connues et recenses Les procdures dexploitation sont conformes aux normes en vigueur Les procdures dexploitation sont livres, documentes, testes, intgres et gres par lexploitant qui les connat. Lenvironnement dexploitation a t contrl, y compris ses aspects secours et reprise Lapplicatif est oprationnel dans son environnement dexploitation. Les outils et manuels dadministration et de pilotage de lapplication sont prts Lexploitant a intgr la charge dexploitation de lapplicatif dans son planning La Cellule dassistance Utilisateurs est oprationnelle

2.10 Dmarrage de lapplication

Le niveau de prparation de lenvironnement applicatif est correct La reprise des donnes est mesure dans son avancement et suivie dans ses dfauts La compltude des donnes reprises est contrle Le service est ouvert dans des conditions dexploitation acceptables Le service est accessible lensemble des utilisateurs dans les conditions prvues pour le dploiement Les sauvegardes et archivages de lancien applicatif garantissent quil peut tre rellement rutilis pour reprise ou recherche dinformations La synchronisation de louverture du service aux utilisateurs et de la mise en uvre des nouvelles procdures organisationnelles est suivie et satisfaisante. Lassistance utilisateurs est suffisamment prpare et dimensionne pour rsoudre dans un dlai normal les difficults de dmarrage Une premire vrification du niveau de service (conformment aux rgles du contrat de service) est ralise La documentation technique et les sources du logiciel et des procdures sont jour. La configuration exacte de lenvironnement de dveloppement et de test est recense. Les jeux dessais sont archivs, ainsi que leurs rsultats Les quipes dvolution sont formes aux procdures de modification, de recherche dinformations, de corrections et de tests.

Memphis / tude paliers techniques / recette fonctionnelle - page 13