Externalisation RSI2

DOSSIER
EXTERNALISATION
POUR
RSI LILLE 2008
Copyright 2008 ps_testware SAS
Titre Version Rvision Date de cration Date de rvision Statut Auteur Nom du document ID Projet Version duTemplate
Externalisation 1 0 14/03/2008 20/03/2008 Distribution Olivier Denoo Externalisation-RSI2.doc 27032008-1 v1.4
Externalisation Dossier
Distribution
Date de mise jour : 14/03/2008 Olivier Denoo
INFORMATIONS DE GESTION DU DOCUMENT

Historique des Versions Date Version 10/03/2008 0 20/03/2008 1 Historique de Distribution Date Version jj-mm-aaaa 1 1 1 1 Rvision 0 0 Remarques version prliminaire premire version officielle
Rvision 0 0 0 0
Nom N/A
Socit
Contrle qualit et autorisation Date Version Rvision 20/03/2008 1 0 20/03/2008 1 0
Tche Contrle orthographique Autorisation de distribution
Nom
Validation
PUBLIC CIBLE
RSI-Lille 2008
DOCUMENTS DE REFERENCE
ps_testware knowledge base ps_testware test book
CONFIDENTIALITE
Ce document est destin la distribution externe. .
Externalisation-RSI2.doc version: 1 rvision: 0
Copyright 2008 ps_testware S.A.S
2/43
Distribution
Ce document a t prpar par ps_testware S.A.S. en tant que livrable soutenant une intervention faite dans le cadre de RSI Lille 2008. Bien que tous les efforts aient t faits pour que le contenu de ce document soit exact, ps_testware n.v. nassume pas la responsabilit dventuelles erreurs dans son contenu et dventuelles actions que le client pourrait engager sur la base de celui-ci .
Copyright 2008 by ps_testware S.A.S.
ps_testware S.A.S. 4 rue Louis Neel (Synergie Park) 59260 Lezennes France - Nord Tel.: +33.(3).59.30.42.02 Fax: +33.(3).59.30.42.03 e-mail: infofr@pstestware.com Internet: www.pstestware.fr
RCS Lille 500. 411.467.00011 TVA FR 42 500 411 467 Capital 37000
3/43
Distribution
Tester, c'est excuter un programme logiciel dans l'intention d'y trouver des erreurs.1
Myers, Glenford J: The Art of Software Testing Copyright 2008 ps_testware S.A.S 4/43
Distribution
CONTENU
1. COMMENT LA QUALIT EST-ELLE DFINIE DANS LAPPEL DOFFRE ? 6 1.1. 1.2. 2. CRITRES DE SLECTION DU PARTENAIRE LES ATTENTES EN MATIRE DE QUALIT 7 9 22 23 23 24 25 26 27 27 28 28 28 29 29
COMMENT LA QUALIT EST-ELLE DFINIE DANS LE CONTRAT ? 2.1. LES INCITATIONS ET LES PNALITS BASES SUR LE RISQUE 2.1.1. KPI 2.1.1.1. Performance 2.1.1.2. Disponibilit/performance 2.1.1.3. Satisfaction utilisateur index/Qualit 2.1.2. SLA 2.1.2.1. Dfinition des services 2.1.3. CRITRE DE QUALIT 2.1.4. RLES ET RESPONSABILITS (R&R) 2.1.5. COPYRIGHT ET PROPRIT 2.1.6. BONIFICATIONS/PNALITS
3.
CES PROBLMES QUE PERSONNE NE SOUHAITE 3.1.
QUELQUES CONSEILS PRATIQUES SUR LA FAON DONT LA QUALIT POURRAIT TRE VALUE, MESURE ET SUIVIE TOUT AU LONG DU PROCESSUS 30 3.1.1. CAS DUN NIVEAU DE PARTICIPATION MINIMUM 32 3.1.2. CAS DUN NIVEAU DE PARTICIPATION MOYEN 35 3.1.3. CAS DUN NIVEAU DE PARTICIPATION LEV 37 PS_TESTWARE : MINIMISER LES RISQUES MAXIMISER LA CONFIANCE 40
5/43
Distribution
1.
COMMENT LA QUALIT EST-ELLE DFINIE DANS LAPPEL DOFFRE ?

Lappel doffre ou moindre chelle la spcification de la problmatique qui est lorigine de la demande- est sans doute le moment le plus crucial pour dfinir les attentes en matire de qualit. Cest sur cette base que les futurs partenaires sauront quoi sen tenir, identifieront le niveau de maturit respective (tant au sein de lappel que dans les rponses qui y seront apportes). Sil serait erron de se limiter lappel doffre pour juger un partenaire la phase de suivi, une fois le partenaire slectionn, reste en effet cruciale, tant pour contrler que pour remettre en question ou recadrer sil y a lieu il reste le critre dterminant pour la slection. Une erreur courante consiste mettre en exergue uniquement les aspects de la problmatique et les aspects oprationnels du projet parfois mme avec un niveau de dtails et de spcificit tellement lev quil dcrit presque la solution souhaite, coupant ainsi libre court toute crativit dans la rponse tout en ngligeant les attentes en matire de suivi, de qualit ou dorganisation. Cest l une porte ouverte toutes les drives. La suite de ce dossier devrait vous donner quelques clefs pour mieux caractriser votre choix et vos attentes en matire de partenaire externes. Prenons un exemple simple tout dabord : vous devez passer quelques nuits lhtel pour des raisons familiales ou professionnelles. Pensez une exprience rcente et tchez dvaluer les raisons qui vous ont pouss choisir cet htel et non un autre : o Est-ce parce que o Le nom vous plaisait? o Il fait partie dune chane/cest une enseigne connue? o Seul le prix comptait? o Il sagissait dun htel renomm ? o Les chambres sont confortables et spacieuses ? o Lendroit est calme et reposant ? o Il est proche dun lieu de visite/dun centre commercial ? o Il dispose dun quipement/dune infrastructure spcifique ? o Il est proche de votre centre dintrt/de votre destination finale ? o On peut rserver en ligne ? o Autres critres? o La recherche/slection a-t-elle t facile ? o Quel est, selon vous, le degr dobjectivit de vos critres? o Lexprience sur place rpondait-elle aux attentes ou avez-vous t du(e) ? o Comment avez-vous mesur votre degr de satisfaction? Sur quels critres?
6/43
Distribution
o Leur avez-vous fait part de vos remarques et si oui, comment ont-ils ragi ? o Ont-ils t proactifs ? Vous ont-ils propos spontanment de rpondre une enqute de satisfaction ? o Pensez-vous, lavenir revoir vos critres initiaux ? o Que changerez-vous ? Quelles leons ont t tires de cette exprience ? Pensiez-vous avoir besoin de toutes ces questions pour simplement slectionner un htel ? Pourtant, nous avons sans doute tous souffert dun mauvais choix. Au pire, nous avons pass une nuit blanche et nous payons la note de mauvaise grce, mais en gnral, les consquences sarrtent l. Par contre, lorsquil sagit dun processus dentreprise, dexternaliser des tches qui impliquent la fois des cots et des ressources humaines, les consquences dun mauvais choix peuvent savrer bien plus dramatiques. Regardons maintenant ensemble quelques rgles de bonnes pratiques, base sur notre longue exprience des projets TIC, qui pourront, nous lesprons, vous viter bien des dsagrments :
1.1.
Critres de slection du partenaire
La question principale se poser ici est bien sr pourquoi eux?. Voici donc quelques pistes et remises en question des critres les plus courants:
Critres
Ils sont les moins chers
Ce quil faut aussi avoir lesprit?

o o o o o o o o o o o o Comment les cots sont-ils contrls? Oui, et quelle est la qualit dlivre? Quelles garanties avez-vous? Vraiment? Quest-ce qui est inclus et quels sont les motifs ventuels de correction/dviation? Quels sont les standards en application ? Quest ce qui constitue un changement ? Comment se proposent-ils de grer limprcision, lincertitude dans les besoins ? Daccord, et leurs analystes? Comprennent-ils votre mtier, votre culture, vos processus? Et de votre infrastructure technique? Comprennent-ils vos contraintes, votre architecture? Les grandes maisons font aussi des erreurs, nest-ce pas? Quelle importance avez-vous leurs yeux, jusquo se sentent-ils impliqus et responsables? Avez-vous vrifi? Etait-ce un succs? Quest ce qui tait diffrent de votre situation? Tout ce qui est trs cher est forcment bon, non? Avez-vous vrifi si le papier rencontre bien la pratique? Tout le monde peut prtendre avoir une mthodologie, mais la leur, que vous apporte-t-elle exactement? Comment cette mthodologie va-t-elle sintgrer votre situation, vos projets? 7/43
Le prix est fixe et sans surprise
Leurs experts techniques sont vraiment comptents et convaincants Ils me parlent si bien de ce que je fais/de mon mtier Ils sont connus/renomms
Ils lont fait de nombreuses fois, non? Leurs consultants sont trs chers par rapport au reste du march, ils ont des CV en bton Ils ont une mthodologie et de nombreux outils
o o o o o o o
Externalisation Dossier o o o o Les grandes structures sont plus comptentes. Et en plus elles savent tout faire Les grandes structures sont plus stables et elles offrent plus de garanties financires? Les petites structures sont plus combatives, plus flexibles, lus spcialises Les petites structures sont plus attentives aux besoins de leur client Cest moins risqu de poursuivre en justice une petite structure Finalement on dveloppe/teste mieux en interne o o o o o o o o o o o o o o o o o o o o o o o
Distribution
Une tierce partie est plus efficace Avec mon fournisseur cest gagnant-gagnant
Vous reconnaissez-vous dans leur approche? Ces outils, sont ils spcifiques et propritaires ou portables et ouverts? Si vous souhaitiez changer de partenaire, cette opration serait-elle aise ou non? Les outils et la mthodologie quils proposent fontils partie de vos objectifs? Ah bon, ils nengagent pas de juniors alors? Avez-vous besoin de ce niveau dexpertise? Elles savent tout faire, certes, mais le font-elles bien ? Pourtant de grands noms disparaissent aussi? Et vous, que reprsentez-vous pour elles? Quels sont vos choix, votre force de ngociation? Ah bon? Vous apportent-elles la masse ncessaire, les garanties suffisantes en terme de prennit? Est-ce bien toujours le cas? Peuvent-elles pour autant rpondre vos attentes ? Peuvent-elles voluer assez vite et avec vous ? Ce nest pas sr et dailleurs nest-ce pas exactement ce que lon veut viter? Quelles sont vos garanties en cas de dpt de bilan? Peut tre, mais les internes sont-ils aussi bien arms face aux jeux politiques? Vos quipes ont-elles les comptences, ont-elles reu les formations appropris, sont-elles au fait de la technique et des volutions? Sont elles assez flexibles, peuvent-elles ragir/monter en charge rapidement? Ces activits sont-elles bien leur cur de mtier, ne seraient-elles pas plus utiles si elles se consacraient dautres tches? Comprennent-ils ce que vous faites? Peuvent-ils vous apporter des mtriques pleines de sens et comprhensibles sur leurs projets? Quelle part du risque prend-il au fait? Est-il impliqu dans le transfert de connaissances et la maintenance? De quel support disposez-vous? Comment les changements sont-ils faits, par quel mcanisme? Quel est le risque quils soient le prtexte pour faire grimper les prix Comment pouvez-vous laffirmer, sur base de quoi au juste? Quelles sont vos garanties relles? Avez-vous clairement dfini le niveau de documentation requis? Vos attentes en matire de qualit sont elles mesurables, spcifiques, clairement dfinies, inscrites dans le temps et contraignantes pour le fournisseur? Quels sont leurs standards et comment en ont-ils fait publicit auprs de vous? Ces standards sont-ils compatibles avec votre situation, votre approche? Certes, mais on peut parfaitement dcrire un mauvais processus et tre du coup certifi ISO Est-ce important pour vous et si oui en quoi ? 8/43
Mon fournisseur est plus structur/mthodique, il fournit une qualit suprieure
o o o o
o o Ils sont certifis ISO x, IEEE x ou CMM x ou quoi que ce soit dautre en rapport avec Externalisation-RSI2.doc version: 1 rvision: 0 o o
Externalisation Dossier nos attentes et/ou obligations Ils fournissent une offre complte, elle inclut mme du test
Distribution
o o o
Bien sr, tout dveloppement se doit au moins dtre test, non? Mais ces tests, sont-ils indpendants, ou sont-ils lies par la mme offre, es mmes impratifs et contraintes? Quelles sont les comptences de lquipe de test? Est-ce intressant pour vous dun point de vue mtier/technique? Quels sont les risques quils sen servent pour rcuprer le manque gagner dcoulant dune offre prix cass? Quel est votre niveau de contrle sur lapplication de patches et autres maintenances correctives ou dinfrastructure? Avez-vous le choix/un droit de regard ? Quels sont les risques associs ces pratiques ? Pouvez-vous refuser de mettre jour, et si oui, disposez-vous encore dun support appropri et des mmes conditions ? Quel est votre degr de dpendance vis vis de votre fournisseur? Avez-vous tudi la faisabilit, ladquation vos besoins, la mise en uvre? Est-ce adaptable? Y-a-t-il une raison srieuse de ladopter ou est-ce juste un effet de mode? Bien! Mais comment vont-ils sentendre? Leurs approches/mthodes sont-elles compatibles? Quel est le risque quils sopposent au lieu de travailler en symbiose, et bloquent ainsi votre projet ou pire encore, vous forcent jouer la police/les arbitres? Sont-ils vraiment diffrents et indpendants ou sontce seulement deux dpartements/filiales dun mme groupe/dune mme compagnie)? /
Ils nous offrent un contrat de maintenance
o o o
o o La fonctionnalit xxx, technologie yyy, outil zzz a vraiment fait la diffrence pour emporter notre choix. Le fournisseur X a t engag pour diminuer notre dpendance vis vis du fournisseur Y o o o o o o
o Et encore o
Quoi quil en soit, il est impratif de jouer franc jeu ds le dbut et de ne pas hsiter mettre sur la table toutes les craintes, les hsitations, mais aussi les contraintes et les attentes, de sorte que les rgles soient connues davance. De la sorte, une bonne partie des mauvaises surprises pourront tre vites et personne ne pourra prtendre ignorer ou avoir t mal inform. Bien entendu, le fait davoir clairement dfini les attentes, ds les premiers contacts, permet aussi dobtenir des offres de bonne qualit, plus circonstancies et plus en adquation avec les attentes, car dans ce processus, tous ont intrt identifier au plus juste, les besoins et les contraintes de lautre.
1.2.
Les attentes en matire de qualit
Tout comme pour les critres de slection du partenaire, et pour les mmes raisons, les attentes en matire de qualit doivent tre claires et explicites. Il est aussi impratif de les dfinir au plus tt, afin dviter toute non-conformit dans la prestation de services, voire une longue et coteuse rengociation, si ces besoins sont exprims tardivement (ex : aprs la signature de laccord).
Externalisation-RSI2.doc version: 1 rvision: 0 Copyright 2008 ps_testware S.A.S 9/43
Distribution
Parfois, il est opportun dexpliquer les raisons qui justifient la demande (ou certains points prcis de celle-ci) ; ceci afin de permettre aux diffrents candidats, voire au candidat dj slectionn, de proposer des alternatives quivalentes mais plus faciles mettre en uvre, plus ralistes ou plus appropries. (ex: alternative dans le choix dun outil en raison dune meilleure intgration la plateforme choisie, dune meilleure matrise au sein de lquipe). Il va de soi que ces aspects font partie dune ngociation plus gnrale aboutissant au choix de la solution dfinitive. NOTE: Tout comme pour les critres prcdents, une certaine redondance peut exister, voire parfois une apparente contradiction. Celles-ci sont intentionnelles et rsultent dune volont dtre aussi complet que possible. De mme toutes les options souleves dans les tableaux ci-dessous ne sont pas applicables toutes les situations...
Aspects garder lesprit lors de leur dfinition
o o o o o o o o Y-a-t-il des standards de qualit incorpors aux mthodes de dveloppement? Le code est-il document et si oui comment (avec quel souci de compltude, de faciliter la lecture et la comprhension)? Le dveloppement prvoit-il dinclure des conventions de nommage? Le dveloppement est-il en ligne avec les standards industriels en vigueur? Le mode de dveloppement choisi, le langage sontils compatibles avec une ventuelle automatisation (ex: outils de tests fonctionnels automatiss)? Y-a-t-il une gestion des versions et du code source (code management, version management)? Si oui, est-il en ligne avec vos besoins, vos attentes ? Y-a-t-il un systme de sauvegardes? Si oui, est-il jour et a-t-il t test ? Comment le code est-il test, avec quelle intensit/tnacit/profondeur? o Les tests unitaires sont-ils documents? o La performance des modules est-elle teste ou value? o Les modules sont-ils dvelopps et tests en accord avec les spcifications techniques? o Y-a-t-il des revues/audits du code? o Le dveloppeur teste-t-il sont propre code ou est-ce laiss un collgue ou une quipe de test? o Les dfauts trouvs dans le code sont-ils documents et suivis? Si oui, comment ? o Combien de dfauts sont trouvs par ligne de code (LOC)? o Combien de tests sont excuts par ligne de code (LOC)? 10/43
Critres de slection communment employs

Qualit du code (source)
Distribution o
o o o o o o Procdures o o o
o o o o o o o
o o o o o
Les rsultats attendus des tests sont-ils connus davance? o Quelle est la couverture du code/des dcisions /des instructions? o Des outils de tests automatiss sont-ils mis en uvre? Le code source dpend-il dun tiers (autre que lintgrateur ou le fournisseur choisi par exemple) ? Si oui, quel pouvoir de dcision/pression a-t-on sur ce dernier? Quelle est la taille de lapplication (ex: nombre de lignes de code)? Le code est-il portable, recyclable? Le code est-il modulaire/segment? Y-a-t-il des procdures et des mthodes claires? La plateforme de dveloppement est-elle connue et renomme? Est-elle supporte par des groupes de discussion, des fora actifs dutilisateurs ? La plateforme de dveloppement bnficie-t-elle encore dun support? Est-elle encore dactualit ? Les procdures en vigueur sont-elles claires et documentes ? Les procdures laissent-elles la place linterprtation/sont-elles quivoques ? Les procdures sot-elles connues, vrifies, approuves, comprises et appliques par tous ? si oui, sont-elles appliques de force ou font-elles partie intgrante de la culture de lquipe ? Les procdures de communication sont-elles en place? o Escalade et gestion des conflits o Reporting formel et runions de suivi o Reporting oprationnel et runions de suivi techniques o Reporting formel et comit de pilotage/gouvernance o Reporting formel et suivi des anomalies o Reporting formel et gestion des livrables, versions et mises en production Outil/procdure de suivi des versions? Outil/procdure de suivi des livrables? Outil/procdure de suivi des mises en production (release management)? Procdure de documentation du projet? Procdure de sauvegarde? Procdure de passation de tmoin/prise en charge/livraison? Des indicateurs (Key Performance Indicators KPI) ou des accords de services (SLA service level agreement) ont-ils t mis en place et approuvs par les parties? La chane de coordination et de management estelle claire et connue? Les rles et responsabilits de chacun sont-ils clairs et connus? Outil/procdure de gestion des documents? Les livrables sont-ils clairs, circonstancis, documents et valids? Y-a-t-il une procdure de distribution des documents? 11/43
Externalisation Dossier o o o Mtriques Suivi - Reporting o
Distribution
o o
o o o o o
o o o o o o o
Y-a-t-il une procdure de recette/approbation des documents? Le processus de vrification est-il dcrit/dfini? Le processus de suivi des anomalies est-il extensivement dfini (qui fait quoi, quand, quelle svrit, quelle priorit)? Y-a-t-il des mtriques claires dcrivant la couverture (du dveloppement, des tests), les progrs raliss? o Effort de dveloppement? o Effort de design des tests? o Effort dexcution des tests? o %Couverture ? o Anomalies reportes? o Dfauts classes par impact/priorit/svrit? Y-a-t-il des mtriques claires dcrivant la qualit du livrable/produit? o Dfauts corrigs par unit de temps (Defect Removal Effectiveness)? o Flux des dfauts o Nombre de dfauts trouvs? 1. par livraison 2. par svrit/impact 3. par configuration/environnement Y-a-t-il des mtriques dcrivant les performances (mise lchelle, trajet de bout en bout) ? Y-a-t-l des mtriques indiquant : o Les dfauts non reproductibles ou abandonns? o Le %disponibilit de lenvironnement de test? Des runions techniques sont-elles organises (si oui quelle frquence) ? Des runions oprationnelles sont-elles organises (si oui quelle frquence) ? Des runions stratgiques/de pilotage sont-elles organises (si oui quelle frquence) ? Des runions de suivi des anomalies sont-elles organises (si oui quelle frquence) ? Les livrables sont-ils annoncs aux testeurs et utilisateurs? Saccompagnent-ils dun descriptif, de commentaires et/ou rserves ventuelles (instabilits ou dfauts connus)? Y-a-t-il un suivi des ressources au regard des charges initialement estimes? Y-a-t-il un suivi des budgets au regard des charges initialement estimes? Y-a-t-il un suivi des dates de livraison au regard des charges initialement estimes? Y-a-t-il un suivi des KPI/SLA au regard des charges initialement estimes? Les mtriques employes/proposes permettentelles de suivre les progrs avec une acuit suffisante? Les mtriques employes/proposes permettentelles de mettre en places des mcanismes correctifs ou damlioration? Les mtriques sont-elles claires, interprtes et comments? 12/43
Externalisation Dossier o o o Planning o o o o o
Distribution
o o o o o
o o o o Gestion de projet o o o o o o o o o o
Standards
Y-a-t-il une mesure de la satisfaction du client parmi les mtriques? Y-a-t-il un suivi/une prsentation formaliss lors des moments cls (milestones/bornes kilomtriques)? Lordre de grandeur des mtriques est-il adapt laudience Le planning semble-t-il raliste ou dispose-t-on dlments tendant prouver le contraire (historique, exprience)? Comment a-t-on conu le planning? Sur base de quelles estimations ? Le planning propos est-il en ligne avec des projets similaires raliss par le pass? Quy-a-t-il sur le chemin critique? Est-ce acceptable ? Le planning tient-il compte des ressources et des contraintes (ex : degr de paralllisation des tches, nombre dutilisateurs concurrents, nombre denvironnements, heures ouvrables? Disposez-vous dune vision optimiste, pessimiste et la plus probable? Le planning initial est-il revu au cours du projet et si oui quelle frquence les rvisions sont-elles prvues? Les moments cls apparaissent-ils clairement (milestones plans)? Y-a-t-il un planning dtaill et un planning dactivits? Si oui, sont-ils en ligne avec le planning haut niveau ? Le planning tient-il compte des contraintes en terme de taille ou de ressources (ex: les programmeurs plus junior font en gnral plus de fautes, les projets de grande taille glissent plus facilement) Le planning tient-il compte de tous les acteurs impliqus dans le projet? Si oui, a-t-il t approuv par ces derniers ? Le planning tient-il compte des temps de dploiement, de mise jour? Le planning intgre-t-il le temps ncessaire la correction des dfauts? Le planning intgre-t-il contingence, dpendances et contraintes? La gestion de projet couvre-t-elle tout le primtre de lorganisation? Y-a-t-il un contrle? Si oui, couvre-t-il bien tout le primtre ? Le suivi de projet est-il bien intgr la gouvernance? A quelle frquence revoit-on le planning? A quelle frquence revoit-on le budget? A quelle frquence revoit-on lutilisation des ressources? Y-a-t-il des outils de gestion de projet? Y-a-t-il des documents types de suivi de projet? Y-a-t-il une coordination formelle? Y-a-t-il des standards en place au niveau du dveloppement ? o Standards dans le code 13/43
Distribution
o o o o o o o o o o o o o o o o o o o
Outils
o o Documentation et transfert de savoir-faire o o
o Standards dans la documentation o Conventions de nommage explicites o Mthodologie Y-a-t-il des standards en place au niveau du test ? o Livrables ? o Standards de conception ? o Standards de script ? o Conventions de nommage ? Y-a-t-il des standards en place au niveau de la documentation ? Y-a-t-il des standard en place au niveau de la gestion de la documentation? Y-a-t-il des standards et des conventions en place au niveau de la planification ? Y-a-t-il des documents types ( templates ) et des outils en place? Les standards du projet sont-ils compatibles avec les standards industriels internationaux (ISO, IEEE, ITIL, TickIT) ? Les standards sont-ils tous dfinis, reconnus, approuvs et utiliss ? (sont-ils institutionnaliss ou utiliss de force ?) Des outils sont-ils ncessaires dans le projet ? Pourquoi ? quelles sont vos attentes? Avez-vous l'intention dexcuter au moins 5 cycles de rgression sur la mme version? Est-ce que le mode de dveloppement est compatible avec l'automatisation ? (ex. la stabilit, la gestion des changements ) Les outils sont-ils compatibles avec lenvironnement de dveloppement ? Les outils sont-ils compatibles avec larchitecture? Les outils fournissent-ils linformation que les membres de lquipe projet attendent (suffisante, spcifique, mesurable, prcise)? Les outils sont-ils fiables et compatibles avec une stratgie long terme? Y a-t-il un support ainsi quun contrat de maintenance raliste pour les outils ? Les outils proviennent ils dun fournisseur ou sont-ils conus en interne (propritaire)? Les outils sont-ils reconnus et approuvs lchelle internationale? Le fournisseur de vos outils prsente-t-il une situation financire suffisamment viable? Les outils vous fournissent-ils toutes les fonctions de reporting souhaites? Les outils peuvent-ils sintgrer correctement dans votre environnement ? (ex. reconnaissance, import, export, intgration avec le back office, intgration avec la gestion de projet et le reporting ) Quel niveau dindpendance avez-vous par rapport aux fournisseurs de ces outils une fois leur solution adopte? Quelle est votre pouvoir de dcision par rapport ces outils et leurs fournisseurs ? Un processus de documentation est-il prvu? Ce processus de documentation est-il men en parallle au processus de dveloppement/de livraison ? 14/43
Externalisation Dossier o o o o o o o o o o o o o o o o o o o o o o
Distribution
o o o o o
Y a-t-il un systme de gestion de documentation en place ? Les documents sont-ils explicites et aisment accessibles ? Le processus de documentation est-il compatible avec le systme de gestion des connaissances ? Le processus de documentation sappuie-t-il sur des standards? Le transfert de savoir-faire est il clairement dfini (en amont, niveau, audience cible, dtail)? La forme de ce transfert est-elle clairement dfinie ? (formation, document, base de connaissance) Le langage des documents est-il dfini et clair ? Lenvironnement et larchitecture en gnral sontils dfinis prcisment? Les configurations et les tests sont-ils prcisment dfinis? Les rsultats de tests sont-ils prcisment dfinis? Existe-t-il une gestion de lhistorique ? Les changements et les problmes sont-ils prcisment dfinis? Existe-t-il une gestion de leur historique? Les documents sont-ils correctement versionns et leur historique suivi ? Y-a-t-il des conventions de nommage et de numrotage en place ? Les documents respectent-ils des templates standards ? Y a-t-il un contrle qualit au niveau de la documentation ? La documentation est-elle vrifie au moyen d'inspections formelles, de rvisions ou de revues ( walkthrough )? Les rsultats de ces inspections formelles, rvisions ou revues ( walkthrough ) sont-ils documents et tracs? Y a-t-il des standards visuels en place? La documentation est-elle crite dans un format contrl (ex.. .doc, .pdf, .html)? Le format de la documentation est-il compatible avec les standards et la politique de lentreprise? La documentation passe-t-elle par un processus formel dapprobation? Cette procdure est-elle dcrite? Le statut de la documentation est-il clairement dfini dans le respect des tapes de la qualit et du processus de vrification (ex.. brouillon, approuv, orthographe vrifie )? La documentation est-elle adresse une liste de distribution dfinie? La documentation mentionne-t-elle les clauses lgales ou de confidentialit, si ncessaire? Les niveaux de confidentialit sont-ils clairement dfinis (ex. confidentiel, interne)? La mention copyright est-elle prsente et clairement identifie? Existe-t-il un plan de test convenablement document (porte, approche, stratgie, livrables, standards, rles et responsabilits, 15/43
Distribution
o o o o o o o o o o o o o o o o
Intgration dans une organisation existante
communication)? Est-ce clair et appliqu? Existe-t-il des modles de test prcisment documents (administration, approche logique, approche physique, jeux de donnes, scenario, points de validation)? Sont-ils clairs et appliqus? Existe-t-il des scripts de test prcisment documents (administration, approche logique, approche physique, jeux de donnes, scenario, points de validation)? Sont-ils clairs et appliqus? Existe-t-il un rapport de progression clair (Do venons-nous? O en sommes-nous aujourdhui ? O devons-nous tre demain?) fournissant des mtriques claires et des aides la dcision? Les entraves et anomalies connues sont-elles documentes? Existe-t-il des fichiers ou des modules daide implments dans lapplication? Y-a-t-il un guide utilisateur clair pour cette application? Y-a-t-il une documentation de dploiement et dinstallation claire pour cette application? Y a-t-il une documentation pour le dpannage de cette application? Laide est-elle contextuelle? Existe-t-il une aide et un support proactif orients vers les mcanismes de prvention des erreurs? L'application comporte-t-elle une approche ergonomique destine guider lutilisateur pas pas ? Le problme est-il bien compris et dcrit? La solution est-elle bien comprise et dcrite? Les spcificits de votre organisation sont-elles bien comprises et bien saisies? Les mthodes et les standards de dveloppement sont-ils compatibles avec la politique et les standards de votre entreprise? Les standards de communication et de reporting sont-ils compatibles avec la politique et les standards de votre entreprise? Le logiciel est-il compatible avec larchitecture et lenvironnement existant? Les procdures de communication et de suivi sontelles compatibles avec la politique et les standards de votre entreprise? Les standards et mthodes de test sont-ils compatibles avec la politique et les standards de votre entreprise?
16/43
Externalisation Dossier Les contraintes du projet o o o o o o o o o o o o Comptences et certification o o o o o o o o o o o Mthodologie et processus o o
Distribution
o o o o o o
Les contraintes techniques sont-elles analyses, discutes et identifies ? Les contraintes oprationnelles sont-elles analyses, discutes et identifies ? Les contraintes lies la taille sont-elles analyses, discutes et identifies ? Les contraintes organisationnelles sont-elles analyses, discutes et identifies ? Les contraintes budgtaires sont-elles analyses, discutes et identifies ? Les contraintes de temps sont-elles analyses, discutes et identifies ? Les contraintes de qualit sont-elles analyses, discutes et identifies ? Les risques et les priorits sont-ils analyss, discuts et identifis ? Le chemin critique est-il analys, discut et identifi ? Les dpendances sont-elles analyses, discutes et identifies ? Les imprvus sont-ils analyss, discuts et identifis ? Les sauvegardes et les solutions de repli sont elles envisages ? Les responsables sont-ils assez forms/coachs ? Les personnes travaillant sur le projet sont-elles dment certifies ? Les personnes connaissent-elles/ sont-elles familires avec les standards utiliss ? Les personnes connaissent-elles/ sont-elles familires avec les techniques utilises ? Les personnes connaissent-elles/ sont-elles familires avec les mthodes utilises ? Les personnes connaissent-elles/ sont-elles familires avec la(les) mthodologie(s) utilise(s) ? Les profils correspondent-ils aux tches qui leurs sont assignes? Le problme est-il bien compris et dfini? La solution est-elle bien comprise et dfinie ? Les personnes sont-elles motives et satisfaites de leur job ? Les responsables sont-ils reconnus professionnellement? Y a-t-il une mthodologie en place? La mthodologie propose est-elle compatible avec la politique et les standards de lentreprise? Peutelle tre mise en place dans votre organisation et avec quelle rapidit? La mthodologie propose est-elle compatible avec les standards industriel/qualit? La mthodologie propose a-t-elle fait preuve de succs sur un projet similaire/diffrent? La mthodologie propose est-elle portable? La mthodologie propose est-elle souple? La mthodologie propose est-elle adapte la phase de test/au niveau de test/ la mission en cours? La mthodologie propose intgre-t-elle tous les aspects ncessaires au processus de dveloppement et de test? 17/43
Externalisation Dossier Gestion des exigences et approche mtier o o o o o o o o o o o o o o o o o o
Distribution
Performance
o o o o
o o o o Externalisation-RSI2.doc version: 1 rvision: 0
Y a-t-il un processus de gestion des exigences? Le processus de gestion des exigences est-il compatible avec la politique et les standards de lentreprise? Le processus de gestion des exigences est-il compatible avec les standards industriels/qualit ? Le processus de gestion des exigences a-t-il fait preuve de succs sur un projet similaire/diffrent? Le processus de gestion des exigences est-il portable? Le processus de gestion des exigences est-il souple? Le processus de gestion des exigences est-il adapt la phase de test/au niveau de test/ la mission en cours? Le processus de gestion des exigences intgre-t-il tous les aspects ncessaires au processus de dveloppement et de test? Le processus de gestion des exigences intgre-t-il lanalyse de risque/dimpact ? Le processus de gestion des exigences intgre-t-il la gestion des risques et des priorits ? Le processus de gestion des exigences intgre-t-il les utilisateurs /les mtiers concerns (niveaux de tests systme et de validation)? Le systme de gestion des exigences est-il entirement intgr au processus de test? Le systme de gestion des exigences est-il entirement intgr avec le processus de mtriques et de mesures ? Le systme de gestion des exigences permet-il un suivi complet des dfauts et incidents? Le systme de gestion des exigences peut-il tre aisment suivi et gr dans un outil intgr? Le systme de gestion des exigences est-il compatible avec les outils de test automatis? Le systme de gestion des exigences peut-il tre partag entre diffrents groupes cibles et tre utilis comme une mthode de communication? Le systme de gestion des exigences est-il construit dans un processus dmocratique (bas sur le consensus) et comme une vue partage de toutes les parties impliques? Lobjectif en terme de performance est-il dfini et raliste? Lobjectif en terme de performance est-il compatible avec les standards technologiques/dutilisabilit ? Le test de performance dbute-t-il ds le commencement du projet ? Le test de performance est-il effectu dans un environnement rel (tel celui de production - plus il est proche de lenvironnement de production et mieux cest)? Le test de performance est-il effectu sur le code? Le test de performance est-il effectu sur des ressources et composants matriels? Le test de performance est-il effectu sur larchitecture ? Le test de performance est-il effectu au niveau de 18/43
Distribution
o o o o o o o o o o o o o o o Ergonomie o o o o o o o o o o o o o o Externalisation-RSI2.doc version: 1 rvision: 0
lapplication (de bout en bout)? Le test dvolutivit est-il men (baisse de performance en fonction de la charge) ? Le test de charge est-il men (temps de rponse en utilisation normale)? Le test de volume est-il men (chargement maximum acceptable, breakthrough point) ? Le test de stress est-il men (stabilit, fiabilit)? Le test de performance est-il combin avec le test de configuration (ex.. types de connexion, localisation, fuseaux horaires )? Le test de performance est-il combin avec le test de scurit (ex. Dni de service) ? Les tests de rcupration sont-ils effectus? Le test de performance est-il surveill? Le test de performance est-il combin des alertes? Un systme d'quilibrage de charge est-il mis en place le cas chant? Existe-t-il un systme de cache le cas chant? Des tests de performance sont-ils mens en dehors des DMZ et des pare-feux ( firewalls ) (ex.. bas sur Internet)? Une performance acceptable est-elle dfinie en fonction des attentes de lutilisateur final ou de la satisfaction des clients ? Des indicateurs de performance sont-ils utiliss dans le KPI ou le SLA? Y a-t-il des barres de progression/chronomtres dans lapplication? Des tests dergonomie sont-ils mens ? Les tests dergonomie dmarrent-ils tt dans le processus (ex. conception participative..)? Les tests dergonomie impliquent-ils de vritables utilisateurs? Y a-t-il des barres de progression/chronomtres dans lapplication? La performance acceptable est-elle dfinie sur les attentes des utilisateurs ou la satisfaction client ? La performance et le temps de rponse dune transaction de bout en bout sont-ils mesurs dun simple point de vue utilisateur? Lobjectif en terme de performance est-il compatible avec les standards technologiques/ dutilisabilit? La satisfaction des utilisateurs est-elle mesure? Comment? Existe-t-il des mtriques sur la satisfaction client dans le KPI ou le SLA? LInterface Graphique (GUI) ou simplement lInterface(UI) sont-elles dveloppes par rapport des standards dutilisabilit? Y a-t-il des fichiers daide ou des mcanismes daide dans lapplication ? Y a-t-il un guide utilisateur clair dans lapplication? Y a-t-il une documentation dinstallation et de dploiement claire de lapplication? Y a-t-il une documentation de dpannage de cette application? Laide est-elle contextuelle? 19/43
Externalisation Dossier o o o o o o o o Portabilit (considr comme attribut spcifique la qualit) o o o o Gestion du changement o o o o o o Prix/Qualit o o o o o o o o o o
Distribution
Maintenance et support
Existe-t-il une aide et un support proactif et orient vers les mcanismes de prvention des erreurs? L'application comporte-t-elle une approche ergonomique destine guider lutilisateur pas pas ? Les fonctionnalits sont-elles dveloppes par rapport aux standards de dveloppement? Cela fonctionne-t-il comme attendu ? Lapplication est-elle fiable et viable ? Y a-t-il un contrat de maintenance inclus ou fourni en tant que service supplmentaire? Les activits de maintenance et support sont-elles prolonges en production? Comment le processus de demande d'entretien/changement est-il abord? Quel en est le cot et comment est-il dfini? Le niveau support et maintenance est-il inclus dans le SLA? Le code est-il modulaire et rutilisable/adapt dautre projet? La mthodologie et le processus sont-ils rutilisables/ adapts dautre projet? Les standards et procdures sont-ils rutilisables/adapts dautre projet? Les documents et outils sont-ils rutilisables/adapts dautre projet? Les conditions permettent-elles un processus rgulier de gestion du changement (sponsor, agents, support, information, ressources)? Le processus de gestion du changement est-il pris en compte au niveau oprationnel (procdures de travail, standards, mthodes)? Le processus de gestion du changement est-il pris en compte au niveau stratgique (mthodologie, standards et normes, stratgie de test)? Les R&R (rles et responsabilits) sont-ils clairs, reconnus, approuvs et institutionnaliss? Les structures de travail sont-elles claires et dfinies? Est-ce que les nouvelles procdures relatives sont reconnues, approuves et institutionnalises? Le prix est-il clair et prcisment dfini (dtaill)? Le prix est-il acceptable compar la concurrence? Quelles garanties sont incluses dans le prix? Vos associs sont-ils lis par un accord SLA? Les contenus et livrables inclus dans le prix sont-ils clairs et sans ambigit? Le processus de demande de changement est-il bien dfini et sous contrle? En cas de dcalage ou de retards, le mcanisme des prix est-il juste et sous contrle (responsabilits, bonification, honoraires)? La documentation, le transfert de savoir-faire, le suivi et les soucis de maintenance sont-ils discuts et budgts? Les cots internes, l'effort et le support sont-ils bien dfinis et pris en considration ? Comment les notions telles que acceptable et qualit sont-elles dfinies dans le contrat? 20/43
Externalisation Dossier o o
Distribution
Test
o o o o
o o
o o o o o o o
o o o o o o Externalisation-RSI2.doc version: 1 rvision: 0
Comment les notions telles que deadlines et dlai de mise en production sont-elles dfinies et prise en compte? Une ventuelle tierce partie pour le support, les conseils et les services est-elle prise en compte (ex. compatibilit logicielle, expert rseau ou analyse de performance )? Tous les outils et services sont-ils inclus ? Y a-t-il des phases de test clairement dfinies? Le test est-il structur? Le test est-il fait en suivant une mthodologie (ou est-il compltement fait de manire ad-hoc)? Si oui est-ce une mthodologie connue et ayant fait ses preuves? La mthode ou la mthodologie dcrite est-elle directement traduite en actions, procdures et documents type ( templates ) (ex.il ny a pas dcart ou un cart limit entre ce qui a t dcrit/promis et ce qui a rellement t fait)? Le test est-il clair, mesur, et comprhensible? Si vous comparez les efforts de test et de dveloppement, le ratio est-il compris entre 30/70 (+/- 40%) et 50/50 (100%) ce qui correspond la fourchette gnralement admise par les standards industriels? Les rsultats de test sont-ils interprts, documents et mesurs? Lindpendance de test est-elle suffisamment garantie (ex. X teste le code de Y et non X teste son propre code)? Le test et le dveloppement sont-ils bien intgrs lun par rapport lautre? Le test est-il impliqu ds le commencement du processus de dveloppement ? Commence-t-il assez tt? Les utilisateurs sont-ils consults ou impliqus? Les tests systme et dacceptation sont-ils conus par rapport la vision utilisateur/mtier ? Le test est-il prioritaire de sorte que si le budget temps s'puise, les tests importants puissent tre excuts d'abord (les dfauts importants sont trouvs en premier)? Le test est-il prioritaire de sorte que si le budget temps s'puise, seuls les tests importants puissent tre excuts d'abord (le risque est minimis)? Les zones grises ou sombres (non testes ou partiellement testes) sont-elles clairement identifies? Connaissez vous ce que vous ne savez pas = ce qui na pas t test ? La couverture de test et la progression sont-elles mesures et contrles? Le test est-il visible? Y a-t-il un propre suivi? Les tests sont-ils documents et reproductibles? Est-ce que la quantit de dfauts non reproductibles ne dpasse pas une quantit acceptable (ex. 510%)? Est-ce que la quantit de faux positifs/mauvais tests ne dpasse pas une quantit acceptable (ex. 510%)? Le test est-il contrlable? Pouvez-vous dcider des 21/43
Distribution
o o o o o o
o o o o o /
actions correctives pour que le test atteigne son objectif/vos attentes ? Est-ce que le test apporte une vue en temps rel de o vous vous situez, o vous allez, ce quil reste faire, est-ce de bonne qualit et vous situez-vous dans les temps? Les rsultats de test sont-ils prcieux pour vous ? Pouvez-vous dduire ou dclencher des actions correctives partir de leur interprtation ? Les rsultats de test sont-ils de granularit approprie ? Sont-ils adapts l'assistance ? Y a-t-il des critres dfinis pour le dmarrage/larrt/la reprise/le report du test ? Sur quoi sont-ils bass? Les dfauts et les cas de test sont-ils totalement accessibles ? Les dfauts sont ils relis aux risques et aux exigences mtier (niveaux systme et validation)? Les dfauts sont-ils relis aux risques et aux exigences fonctionnelles/techniques/ de code (niveau unitaire, intgration et partiellement systme)? Le test met-il en application des standards et des procdures documents? Le processus dexigence de test est-il mature? Estil bien adapt votre situation? Le processus de test est-il support par des outils et templates appropris? Le test intgre-t-il des attributs de qualit et des tests appropris? Sont-ils appliqus au bon moment/au bon niveau? Y a-t-il une stratgie de test approprie? Est-elle bien dtaille dans un plan de test?
En pratique, orienter les questions de la 2me colonne vers les critres et contraintes spcifiques de lappel doffre limitera certainement les risques et rendront les choses claires ds le dbut.
2.
COMMENT LA QUALIT EST-ELLE DFINIE DANS LE CONTRAT ?

Une des choses que nous voyons souvent lors de lexcution des tests est que, bien que tout le monde parle de Qualit en permanence, il y a rarement un accord sur la dfinition si toutefois il en existe une de ce quest ou devrait tre la Qualit. Le plus souvent, tout le monde (fournisseur tiers, dveloppeur, IT, mtier, testeurs, QA, utilisateurs, gestionnaire, marketing) a sa propre dfinition de la qualit et celle-ci dpend largement de ses propres perceptions et intrts. Si nous ajoutons que les tres humains sont enclins rduire leurs perceptions, sont sujet la gnralisation et doivent habituellement classifier tout dans des
22/43
Distribution
catgories bien dfinies, nous commenons comprendre comment cette nouvelle tour de Babel appele Qualit - a t construite. Quand nous analysons ces contrats alors, presque tous mentionnent, d'une manire ou d'une autre qu une qualit dcente ou acceptable doit tre fournie, alors que la plupart d'entre eux ne dfinit ni acceptable ni dcent ni, naturellement, la qualit elle-mme. Car de tels contrats sont plutt pauvres, en particulier dans ce domaine, de sorte que quand les discussions ou les conflits se produisent, toutes les parties peuvent prtendre quelles ont respect les clauses contractuelles la lettre selon leur propre dfinition ou normes, naturellement, qui peuvent varier selon des intrts personnels ou des circonstances. L'absence de rigueur dans la dfinition contractuelle de la qualit ne nuirait pas autant si elle ne dplaait pas les discussions ; aprs tout rien ni personne nest parfait. Le vrai problme vient plutt du fait que, lorsquon les dcouvre, bien souvent trop tard, les problmes de qualit sont gnralement vacus du dbat, ou mis au deuxime rang, au nom darguments budgtaires et/ou de dlai de mise en production. Ce qui est plus facile dfinir, plus pragmatique (moins d'effort est consacr aux discussions sur des notions floues ou interprtables) et ordinairement plus urgent. Dans le meilleur des cas, dans les meilleurs contrats, la Qualit est dfinie et rendue contrlable, mesurable travers de mtriques spcifiques ou dindicateurs (Key Processus Indicators KPI). Dans ces cas la dfinition est souvent combine un niveau de service minimum (Service Level Agreement - SLA) habituellement li un mcanisme de concession/pnalit (ex. des concessions sont donnes dans le SLA pour atteindre lobjectif dans un dlai convenu tandis que parfois simplement symbolique, parfois rellement trs astucieuse des pnalits sont demandes lorsque le SLA nest pas respect). L'avantage davoir un tel processus est que le niveau de qualit est dfini et convenu d'avance, tout comme les proccupations et les attentes. Cela permet aux dveloppeurs de protger leur application contre de vritables soucis commerciaux afin d'viter des pnalits ou des honoraires et ainsi de dvelopper la meilleure application possible. Un autre avantage est qu'elle permet de se concentrer sur la Qualit et limpact mtier, sil est dfini correctement, limitant ainsi les phases de ngociation.
2.1.
Les incitations et les pnalits bases sur le risque

2.1.1. KPI
Les indicateurs de processus cl (Key Processus Indicators) sont des mtriques-qualit tablies dans le but de garantir un niveau de service minimum (ou SLA) en mesurant les indicateurs et en comparant les rsultats aux valeurs ou aux rapports prdfinis. Ils sont habituellement lis de vraies
23/43
Distribution
proccupations ou risques commerciaux et relis une sorte de mcanisme de concession/pnalit. Les KPI devraient tre discuts ds le commencement du processus (le mieux tant de ltre avant de signer le contrat) de sorte qu'ils puissent tre tablis et convenus de manire intelligente par toutes les parties intresses. Les KPI devraient tre naturellement justes et parfois comporter des compromis (ex. fonctionnalit ou performance des applications Web sont habituellement infrieures celle d'applications client/serveur). Cependant, de bons KPI devraient tre labors sur la base des proccupations utilisateur ou mtier comme ils le sont dans la plupart des cas pour les niveaux postvalidation ou daudit (en production). Nanmoins, le test de validation (et mme systme) au regard des KPI peut aussi apporter beaucoup dans la mise au point des futurs processus de production. Voici quelques exemples de KPI (non exhaustif): 2.1.1.1.Performance o Temps de rponse : les temps de rponse dun processus/transaction ne devraient pas excder une certaine limite o Une page web devrait safficher entre 3-7 s. Si les temps de rponse dpassent 7 s. cela signifie que 30% des clients potentiels abandonneront la consultation (sauf en cas de besoin impratif). o Si les temps de rponse dun processus dpassent 10 s. les utilisateurs commencent perdre patience. Cest la limite acceptable maximale perue par le visiteur. o Les temps de rponse du nouveau logiciel ne devraient pas dpasser les temps de rponse du logiciel interne actuel, particulirement avec des transactions X, Y, Z o Les temps de rponse du nouveau logiciel ne devraient pas dpasser les temps de rponse de nos concurrents, particulirement avec des transactions X, Y, Z o Les temps de rponse perus, issus dun panel utilisant le protocole dergonomie suivant (dfinition des cas de test et/ou processus) doivent tre jugs acceptables par au moins X% du groupe cible 1 et au moins Y% du groupe cible 2 o Evolutivit & avance technologique :
24/43
Distribution
o Le systme devrait pouvoir supporter au moins X utilisateurs tant le groupe cible potentiel prvu (prenant en compte la situation d'aujourd'hui et prenant en considration la croissance de frquentation prvue) o Le systme devrait tre capable de supporter Y < X utilisateurs en parallle (actions excutes de manire concurrente) o Les temps de rponse de toutes les transactions majeures ne devraient pas nuire plus de Z% des utilisateurs de 1 T < Y o Lquilibre de la charge et larchitecture devraient permettre au systme de se comporter correctement jusqu ce que U utilisateurs soient connects. Lutilisateur U+1 ne devrait pouvoir se connecter et devrait recevoir un message spcifique linvitant se connecter ultrieurement. o Le systme devrait tre capable de supporter un mlange de transactions spcifiques de X% transaction A, Y% transaction B et Z% transaction C. 2.1.1.2. Disponibilit/performance o MTBE/MTBF (dlai avant erreurs et dfauts mean time between error / failure ) o MTBE ou MTBF devraient rester sous X s. o Le nombre derreurs en production (absence de service, mauvaise facture) devrait tre infrieur Y par unit de temps et/ou estim moins de X par unit de temps. o Fiabilit/dure de panne en production o La stabilit/disponibilit du systme devrait tre au-dessus de X% en production (en dehors des oprations techniques ou des interruptions normales de service chaque fois que cest ncessaire ou appropri) o La production devrait tre disponible X heures/jour ; Y jours/semaine ; Z jours/an sans interruption. En cas de besoin, des solutions de retrait et de sauvegarde seront disponibles pour prendre en charge et assurer un service minimum ( dfinir). o La moyenne mensuelle de priode de non-production ne devrait pas excder X (unit de temps). o La moyenne mensuelle de periode de disponibilit en production devrait tre dau moins X % (ratio temps de fonctionnement attendu/temps de fonctionnement mensuel
Distribution
total) o Le nombre derreurs de svrit X en production devrait se situer sous Y par unit de temps. o Les interventions manuelles devraient tre ramenes X% (ex. compar au produit/processus prcdent) 2.1.1.3. Satisfaction utilisateur index/Qualit o Amlioration et adquation avec le mtier (cible) o Les protocoles dutilisation (description des cas de tests dutilisation ou processus mtier tests) avec pour cible que le groupe X montre un indice de satisfaction de Y% (ex. bas sur des calculs ou une valuation de type choix multiples) o La productivit (ex. nombre de transactions/personne /unit de temps) est amliore de X% (ex. compar au produit prcdent) o Les appels au Helpdesk ou les interventions du Backoffice devraient tre ramens X% (ex. compar au produit prcdent) o Le service/produit dlivr est fourni dans les temps. Les dcalages sont mesurs par X (nombre dunit de temps entre le dlai de livraison rel et le dlai prvu) o Maintenance et support o Le temps dattente ne devrait pas excder X ou Y sonneries (unit de temps) o Le temps de rsolution de problme moyen (dure entre lidentification du problme (= premier appel) et le moment o le problme est rgl) ne devrait pas excder X (unit de temps) o Une remonte dinformation devrait tre donne chaque fois (numro de ticket, heure, personne en charge) aprs X (unit de temps) o Les appels perdus ne devraient pas excder X % (ratio appels perdus/nombre total dappels) o Les problmes non rsolus ou obsoltes (hors dlai) ne devraient pas excder X % (ratio problmes non rsolus ou obsoltes/total nombre de problmes) o Les appels au Helpdesk ou les interventions du fournisseur devraient tre ramenes X% (ex. compar au produit
Distribution
prcdent) o Svrit des dfauts o Le nombre derreurs de svrit X restant dans le code/la version V.nn.mm devrait tre infrieur Y. o Le nombre derreurs de svrit X restant dans laire fonctionnelle F devrait tre infrieur Y o Le nombre derreurs de svrit X li au profil (ou groupe cible) P devrait tre infrieur Y 2.1.2. SLA D'une manire trs simpliste, la dfinition du SLA apparait ce niveau pour dfinir les services qui seront couverts par le contrat, comment ils seront valus ou mesurs, qui sera jug responsable si le SLA n'est pas rencontr et qui validera que le SLA est respect. 2.1.2.1. Dfinition des services o Quel service sera valu ? (ex. Fourniture de service Internet, incluant la navigation, les botes mail, news, le transfert de fichier, lhbergeur ) o Qui dlivre ce service ? (ex. SuperNet) o Qui en est le bnficiaire ? (ex. le client, les usagers du web) o Quelles sont les conditions dutilisation, le primtre et le horsprimtre ? (ex. profil et manipulation, conditions gnrales et lthique, la taille maximum disponible des mail box et des sites web, aucune garantie sur la fiabilit des informations disponibles sur le Web ) o Y-a-t-il des problmes connus ou des aires en dehors du primtre ? (ex. les services ne sont pas garantis en cas problme gnral de rseau/daccs, de guerre ou d'attaque de masse hacking ) o Ces termes utiliss sont-ils clairs et dfinis ? Les donnes de contexte sont-elles claires et dfinies ? o Les attentes par rapport ces services sont-elles claires et ralistes ? Les consquences sont-elles mises dans leur bon contexte ? o Le fournisseur peut-il obtenir une vue claire sur la taille ou la complexit du projet ? Peut-il s'assurer qu'il n'y a aucun agenda cach, aucune consquence implicite peu claire ou problmes potentiels inattendus qui pourraient entraver la prestation de service ?
Distribution
2.1.3. Critre de Qualit o Quels KPI seront utiliss ? (ex. taux de transfert minimum = 10 Mbits /s, disponibilit dau moins 99.8% durant les pics daffluence et 80% des heures hors pic daffluence) o Comment seront-ils mesurs ? (ex. analyse du trafic rseau laide doutils : ps_trafic_web, outils danalyse de donnes qui utiliseront les protocoles suivants : http, tcp, ip, ftp, smtp, pop) o O seront-ils mesurs ? (ex. entre le modem et la ligne, partir de diffrents PC dusagers, par fuseau horaire couvert) o Quand seront-ils mesurs ? (ex. 7 chantillons par jour des heures alatoirement choisies durant les priodes daffluence et 7 chantillons par jour des priodes hors de pic daffluence alatoirement choisies, chaque jour durant un mois) o Par qui seront-ils mesurs ? (ex. par des outils tournant en tches de fond sur les pc dutilisateurs, par des donnes recueillies et analyses par le contact technique de lutilisateur) o Y a-t-il des limites, conditions dusage ou dnis ? (ex. id utilisateur valide, pas de notification des interruptions de service) 2.1.4. Rles et Responsabilits (R&R) o Quand le contrat dbute-t-il ? (ex. le service est disponible ds que lutilisateur obtient son identifiant et au-del de 10 jours aprs son inscription ) o Qui peut interrompre le contrat et quelles sont les consquences ? (ex. les deux parties peuvent dcider d'arrter le contrat tout moment sans frais du fait qu'une notification des 10 jours a t envoye ) o Que se passe-t-il si un dfaut est avr ? (ex. SuperNet peut poursuivre lutilisateur sil est dmontr que lutilisateur a dit des donnes peu convenables qui sont explicitement identifies dans la description morale du contrat, SuperNet est responsable de la diffusion de ces donnes peu convenables, SuperNet peut faire payer le support additionnel sil est dmontr que lutilisateur a abus du service ou des applications) o Quest-ce qui est couvert par les accords de service et la maintenance ? o Quest-ce qui nest pas dans le primtre ? 2.1.5. Copyright et proprit o A qui appartient le service ? (ex. SuperNet a le droit de changer ou mettre jour n'importe quel composant de son architecture sans avis
Distribution
pralable ) o A qui appartient le service ? (ex. Les donnes et les contenus de lutilisateur sont exclusivement sa proprit et engage lutilisateur seulement, SuperNet gagne le droit d'employer des logiciels spcifiques et des logiciels d'exploitation sur ses machines, HiBeaM conserve le code et les droits de ces logiciels et OS spcifiques ) o Les droits et licences peuvent-ils tre transfrs (utiliss par un autre dpartement, autre client ou partenaire, connects une autre application) ? o A qui appartient le code ? Peut-il tre cass ou modifi ? Si oui quelles sont les garanties ? 2.1.6. Bonifications/Pnalits o Que se passe-t-il si le SLA est respect (ex. les factures sont payes en avance, les factures sont augmentes de 5%)? o Que se passe-t-il si le SLA nest pas respect (ex. les factures ne sont pas dues pour ce mois, SuperNet accorde l'utilisateur une somme d'argent qui est proportionnelle la dure de la panne ) ? o Que se passe-t-il si la prestation de service arrive tardivement ? (ex. lutilisateur peut poursuivre en justice SuperNet pour ne pas avoir fourni le service temps) ?
3.
CES PROBLMES QUE PERSONNE NE SOUHAITE

Soyons trs clairs : le vrai but d'un SLA est de s'assurer qu'un niveau de qualit dfini acceptable est atteint la fin du projet (ex. dans le cas du dveloppement dun logiciel), ou quun niveau de service dfini acceptable est livr durant toute la collaboration. Il en va de mme de linclusion des critres de qualit dans le contrat de service et de lapplication de critres stricts lors de la slection du partenaire. Dfinir ce niveau de qualit, ces rgles et le contexte dans un contrat est un processus qui doit tre juste et convenu par tous les partenaires concerns. Par consquent - personne n'est vraiment enclin tre poursuivi ou blm tous les partenaires devraient croire que l'accord est ralisable, juste et raliste. Dans un approche raisonnable du SLA, le demandeur accepte gnralement de payer un peu plus si le taux de disponibilit est atteint (ex. meilleure continuit oprationnelle ou baisses des plaintes ou des dpenses) tandis que le fournisseur de services convient de ddommager dcemment son client, de manire gnralement proportionnelle aux dommages, lorsque le taux de disponibilit n'est pas atteint.
29/43
Distribution
NOTE : En aucun cas, obtenir de l'argent, des avantages, ou des pnalits arrires, mme symboliques, ne devrait tre le but d'un SLA, car il cre une ambiance de travail dsastreuse lorsque la qualit n'importe plus et lorsque la mise en avant des intrts personnels au dpend des autres (vengeance) devient lobjectif principal. Nous avons malheureusement vu des processus o des associations ont soufferts fortement des KPI lorsque ceux-ci ont t prsents en dehors de leur contexte logique et dans le cas o des pnalits symboliques ont t rclames. Dans ce cas particulier, les pnalits taient denviron 0.1% des dommages oprationnels potentiels rels, mais taient simplement dues cette insupportable absence de bon contexte. Le fournisseur de services n'avait aucun contrle sur les processus ascendants impactant fortement sa capacit de fournir le service attendu de sa part - les KPI que le demandeur soumettait ont t pris comme une forme de vexation et le fournisseur de services a refus de signer ce qui a eu comme consquence un arrt du contrat. Le SLA devrait tre vu comme un outil dassurance qualit, dont le but est de garantir que le juste niveau de service est fourni par le partenaire de bon droit, ni plus, ni moins. En soi, le SLA devrait tre le garant de la confiance et des bonnes relations entre les partenaires.
3.1.
Quelques conseils pratiques sur la faon dont la qualit pourrait tre value, mesure et suivie tout au long du processus
Prenons le cas d'une compagnie ou d'une organisation qui est dispose externaliser son dveloppement de logiciel des dveloppeurs ou intgrateurs tiers. De manire logique, cette compagnie souhaite limiter sa participation au projet. En substance, son rle est donc double : o Sassurer que les besoins et les conditions sont bien communiqus aux tiers et bien compris par eux Avant dveloppement o Sassurer que l'application qui a t fournie rpond bien aux besoins et aux exigences initiales (niveau d'acceptation utilisateur) Aprs livraison L'approche comporte habituellement toutes sortes de tests ncessaires pour assurer la rception (ex. non exhaustif : ergonomie, tests de validation excuts au niveau des processus, tests d'intgration de plate-forme, tests de performance).
Distribution
Si nous adoptons le point de vue du demandeur, la qualit dans son ensemble peut tre aborde de 3 niveaux diffrents, chacun deux impliquant des actions des budgets, des eforts et des missions diffrents : o Minimum : La compagnie ou l'organisation joue un rle de validation au niveau acceptation seulement et le reste est considr comme une bote noire. Les seules actions o elle engage formellement sa responsabilit sont la dfinition des critres de qualit appropris (ex. lexamen des entre-sortie de/vers toutes les autres phases) et lassurance que ces critres de qualit sont respects lorsque l'application est dlivre (validation). Ces tches peuvent tre menes en interne voire externalises des partenaires indpendants spcialistes de la qualit. o Medium : Ce qui a t dfini prcdemment reste un minimum , mais plus en amont, lentreprise ou lorganisation est implique en assurant un rle actif d'auditeur dans les phases de dveloppement. De cette manire son rle est non seulement daccepter/valider l'application, mais galement dassurer que ses processus et tapes de construction atteignent un niveau de qualit (prcdemment convenu) suffisant. Ceci peut se traduire en audits de contrle qualit QC (ex. les normes sont-elles en place, les rapports de tests sont-ils disponibles) ; ou par des points de contrle des test (ex. participer au processus formel d'inspection, coordonner l'excution du test dutilisabilit, dfinir les cibles de performance). Quelquefois, les rles, les responsabilits, la frquence, les rsultats et les attentes sont clairement communiqus d'avance. A nouveau, ces tches peuvent tre menes en interne ou externalises des partenaires indpendants spcialistes de la qualit. o Optimis : Ce qui a t dfini prcdemment reste un minimum , mais encore plus en amont, lentreprise ou lorganisation est activement implique dans laudit et le contrle des processus QA et QC (contrle et assurance qualit) tout au long du projet de dveloppement. Cela signifie que la compagnie ou l'organisation a non seulement la responsabilit deffectuer les contrles prvus des standards de qualit dfinis, mais a galement une responsabilit dans la coordination des tests en dfinissant ses propres standards de qualit adapts, en participant aux contrles de qualit cibls, en excutant des audits Ces tches peuvent tre menes en interne ou externalises certains partenaires indpendants spcialistes de la qualit.
31/43
Distribution
Figure 1: SLA - levels of action
3.1.1. Cas dun niveau de participation minimum Dans cette approche, lentreprise ou lorganisation joue un rle plutt passif dans le sens o elle est le dernier acteur dans la chane et se limite une pure validation. Le paramtrage minimale de critre qualit consiste dfinir les critres minimum d'entre-sortie (ou les conditions initiales obligatoires qui proviennent des phases prcdentes pour accepter lapplication dans cette phase de test). Si lun des critres dentre/sortie dfinis et convenus prcdemment ntait pas respect, lapplication resterait alors en phase prcdente de test/dveloppement jusqu ce que ces critres soient respects. D'ailleurs, dans cet exemple, l'accent est mis sur le test de rception, le reste du processus de test/ dveloppement tant peru comme bote noire (aucune participation, aucune responsabilit). Par consquent, tous les efforts seront concentrs sur : o Effectuer le contrle qualit (QC) sur la phase prcdente de test systme et vrifier que les critres de sortie de ce test systme rejoignent les critres dentre du test de validation. o Sassurer que le plan de test de validation, incluant la stratgie, lapproche, les critres et les standards est prt et mis en application
Distribution
tout au long du processus de test. o Dfinir les critres de sortie dans les premires phases du processus de test de validation (plan de test). Sassurer quils sont bass sur des problmatiques qualit. o Mener le contrle qualit durant le processus de test de validation. Sassurer que les procdures et standards sont mis en application avec le niveau de qualit convenu. o Sassurer que le test est men jusqu' ce que tous les critres d'arrt obligatoires (dfinis dans le plan de test de validation) soient remplis. ATTN: Ces critres devraient seulement tre dfinis en termes de qualit, non en termes budgtaires ou de contraintes de temps.
Critre dentre /de sortie pour le niveau de Validation:
Test Y a-t-il un plan de test document dcrivant les phases de test prcdentes? o Les lments obligatoires sont-ils mentionns (ex. stratgie, approche, standards, phases et types de test, communication et rles et responsabilits)? o Comment le processus a-t-il t cre (quels tests, quelle stratgie, quels jeux de donnes, quels cas dutilisation ou points de validation fonctionnelle)? o Comment ont-t abordes les campagnes de test non bases sur les exigences (performance, utilisabilit) le cas chant ? o La stratgie de test est-elle compatible avec la phase et les objectifs? Est-ce que tous les types de test ncessaires ont t excuts? o Le concept de test de rgression a-t-il t appliqu de faon satisfaisante? Y a-t-il un processus rgulier de reporting et de suivi? o Les rapports de test intermdiaires sont-ils disponibles? o Les rapports de test intermdiaires sont-ils rsums dans un rapport de test final? o Les dfauts rencontrs sont-ils saisis et documents dans un outil de suivi des dfauts? o Les statuts des dfauts sont-ils documents et mis jour? Les tests sont-ils identifis et documents? Existe-t-il des modles de test clairs ainsi que des jeux de donnes? Lenvironnement de test est-il appropri et suffisamment reprsentatif?
33/43
Distribution
Y a-t-il un rapport de test (des phases prcdentes)? o Quelles en sont les conclusions? (nombre de dfauts rencontrs, nombre de dfauts restants) o O sont les points faibles ou les points d'intrt qui peuvent en tre dduits ? o Y a-t-il une analyse de risque et si oui quel est le niveau de risque si accept il est? o Y a-t-il une vision claire de ce qui a t test et de la manire avec laquelle cela a t fait? o Y a-t-il une vision clair de ce qui na pas t test et pourquoi? o Les critres de qualit ont-ils t rencontrs (ex. % couverture; % du produit pass; nombre de dfauts restants et svrit; taux de dtection des dfauts ) Dveloppement Le dveloppement est-il document (ex. spcifications au niveau logique, technique et au niveau du code, modle de donnes, workflows, architecture)? Y avait-il un bon processus de configuration/version/gestion du changement et comment a-t-il t abord? o Comment les changements sont-ils pris en compte? Sont-ils documents? o Les documents/parties de code/objets ont-ils t correctement versionns et mis jour? Les standards de dveloppement ont-ils t appliqus durant la phase prcdente? o Documentation du code et commentaires? o Modle de donnes document ou modle de navigation? o Standards GUI et dutilisabilit? o Standards de lentreprise? o Conventions de nommage? o / Les exigences se retrouvent-elles dans les spcifications de conception et limplmentation? Quelle a t la mthodologie de dveloppement, quels taient les standards en place? Quelle est la qualit des documents types templates /standards? Estce que cela correspond aux standards en vigueur? Est-ce quune vrification/inspection du processus a eu lieu dans les documents crits ( la fois partie dveloppement et partie test)? Y a-t-il un mcanisme de validation pour tous les documents crits ? Si oui, les documents fournis sont-ils tous approuvs par toutes les autorits identifies? Les documents ncessaires sont-ils tous correctement reconnus, identifis, rendus disponibles et versionns correctement ? o Tous les dossiers de documentation, d'aide et d'installation sont-ils livrs ? Sont-ils assez clairs et approuvs ? o Toutes les spcifications sont-elles fournies et mises jour ? o Est-ce que toutes les conditions d'entre et demandes de changement sont fournies et tenues jour ? o Est-ce que tous les rsultats de test sont fournis et tenus jour? o /
QA (assurance qualit)
34/43
Distribution
Figure 2: Input/Output criteria
3.1.2. Cas dun niveau de participation moyen Comme prcis prcdemment, les critres dentre/sortie dfinis pour lapproche minimum restent valables. La grande diffrence est quils sont tendus aux phases de test/dveloppement situes en amont et en aval. Par consquent, si nous exceptons le niveau de validation sur lequel nous devons rester focaliss, le reste du processus de test/dveloppement n'est plus peru comme bote noire, mais est valu de temps en temps par lentreprise ou l'organisation elle-mme. Dans cette approche, lentreprise ou l'organisation joue un rle plus actif en tant quexpert occasionnel de lassurance qualit l'intrieur de la chane et ne se limite plus entirement la validation pure. Parfois cela reste un rle relativement passif, car la dfinition des standards et des critres restent toujours de la responsabilit des autres intervenants (si nous exceptons bien sr le niveau de validation). Toutefois, lorganisation peut valuer sils sont correctement contrls et appliqus et peut participer aux actions de contrle qualit avec les autres acteurs. L'avantage par rapport la situation prcdente est que lentreprise ou l'organisation a une vue plus transverse (ce qui permet plus de contrle) de lensemble du processus. Elle peut prvoir, affiner, adapter et corriger sa propre approche ou stratgie en analysant les points les plus faibles dans la chane (ex. si l'analyse logique ne semble pas bonne, elle peut avoir des consquences au niveau du test systme ; ou si le code n'est pas aux normes ou correctement document, l'effort de maintenance peut tre plus important ).
35/43
Distribution
Au niveau du test de validation (sa principale proccupation), le paramtrage des critres de qualit consiste spcifier les critres minimum dentre /sortie (ou les conditions initiales obligatoires issues des phases prcdentes pour accepter lapplication dans cette phase de test ; et les critres obligatoires d'arrt qui sont ncessaires pour dfinir si l'application doit tre livre ou mise en production). Si lun des critres dentre/sortie dfinis et convenus prcdemment ntait pas respect, lapplication resterait alors en phase prcdente de test/dveloppement jusqu ce que les critres soient respects. L'anticipation des problmes et des attentes au niveau de la qualit est assume par un rle (partag) encore plus actif dans le domaine de lassurance qualit et du contrle qualit tout au long du processus de test. La participation peut se faire de faon opportuniste (ex. centre d'intrt ou connaissance du dtail) ou bien pour chaque processus stratgique. Les rgles et standards sont dfinis par les entreprises externes (fournisseurs ou prestataires de service), dont les documents ou services sont vrifis au regard de leur propre dfinition de la qualit. Dans tous les cas, les rles, responsabilits, la frquence et la priode de ces contrles sont clairement connus et convenus ds le dbut (ex. inclus comme clauses ou procdures du SLA) afin d'viter les problmes et les conflits d'intrt potentiels. Les recommandations et les rapports peuvent tre livrs la fin de ces valuations ou audits afin de dclencher des actions correctives ou des modifications des attentes si ncessaire. Les conclusions devraient tre approuves et discutes dans un groupe de travail spcifique chaque fois que le besoin sen fait sentir. Par consquent, des efforts supplmentaires (en plus de ceux prcdemment dfinis) seront dploys pour : o Effectuer le contrle qualit (QC) sur les autres phases et vrifier que les critres de sortie rejoignent les critres dentre de la phase de test suivante. o Sassurer que le plan de test de validation, incluant la stratgie, lapproche, les critres et les standards est prt et mis en application tout au long du processus de test o Evaluer les critres de sortie. Sassurer quils sont bass sur des problmatiques qualit (et non sur des contraintes de temps ou de budget). o Mener le contrle qualit durant lensemble du processus de test et de dveloppement. Sassurer que les procdures et standards sont mis en application avec le niveau de la qualit convenu.
36/43
Distribution
o Sassurer que le test est men jusqu' ce que tous les critres d'arrt obligatoires (dfinis dans le plan de test de validation) soient remplis. o Excuter des revues formelles et des vrifications (inspection) sur les processus, documents et standards existants. o Aider dfinir les standards de qualit si besoin. 3.1.3. Cas dun niveau de participation lev Comme prcis prcdemment, les critres dentre/sortie dfinis pour lapproche mdium restent valables. La grande diffrence est quils sont tendus aux phases de test/dveloppement situes encore plus en amont et en aval. Par consquent, si nous exceptons le niveau de validation sur lequel nous devons rester focaliss, le reste du processus de test/dveloppement est dsormais compltement transparent pour lentreprise ou lorganisation, qui dclenche et dfinit tous les processus transversaux importants. Dans cette approche, lentreprise ou l'organisation joue un rle actif en tant que responsable final de lassurance qualit (QA) l'intrieur de la chane. Elle a galement la responsabilit du suivi du processus global (responsabilit de fin et autorit transverse), de llaboration de la dfinition des normes et des critres, de lorganisation ou de la participation aux actions de contrle qualit avec (ou au nom de) les autres acteurs impliqus de la chane. L'avantage par rapport la situation prcdente est que l'organisation ou l'entreprise a une vue transversale complte (et donc plus de contrle) de la totalit du processus. Elle peut prvoir, affiner, adapter et corriger les approches ou les stratgies transverses ou locales en analysant les points les plus faibles dans la chane (ex. si l'analyse logique ne semble pas bonne, elle peut avoir des consquences au niveau du test systme ; ou si le code n'est pas aux normes ou correctement document, l'effort de maintenance peut tre plus important). Au niveau du test de validation (sa principale proccupation) le paramtrage des critres de qualit consiste spcifier les critres minimum dentre /sortie, mais ces critres sont tendus toutes les autres phases du processus de test/dveloppement. D'ailleurs, les processus de contrle qualit et dassurance qualit sont paramtrs dans le but de comparer les livraisons ou les services par rapport aux attentes prvues (base du contrat) dans toute la chane. Si lun des critres dentre/sortie dfinis et convenus prcdemment ntait pas respect, lapplication resterait alors en phase prcdente de test/dveloppement jusqu ce que les critres soient respects. En outre, dans cet exemple, bien que l'accent soit encore mis sur le test de validation, le reste du processus de test/dveloppement devient compltement transparent, rgulirement suivi et valu.
Distribution
L'anticipation des problmes et des attentes au niveau de la qualit est faite par un rle (partag) trs actif dans le domaine de lassurance qualit et du contrle qualit tout au long du processus de test. Lentreprise ou lorganisation participe au moins tous les processus stratgiques. Les rgles et les standards sont dfinis et adapts par l'organisation ou l'entreprise elle-mme. Les documents ou les services des tierces parties sont vrifis au regard des dfinitions de qualit propres lorganisation ou l'entreprise. Dans tous les cas, les rles, responsabilits, la frquence et la priode de ces contrles sont clairement connus et convenus ds le dbut (ex. inclus comme clauses ou procdures du SLA) afin d'viter les problmes et les conflits d'intrt potentiels. Les recommandations et les rapports peuvent tre livrs la fin de ces valuations ou audits afin de dclencher des actions correctives ou des modifications des attentes si ncessaire. Les conclusions devraient tre approuves et discutes dans un groupe de travail spcifique chaque fois que le besoin sen fait sentir. Par consquent, des efforts supplmentaires (en plus de ceux prcdemment dfinis) seront dploys pour : o Effectuer le contrle qualit (QC) sur les autres phases et vrifier que les critres de sortie rejoignent les critres dentre de la phase de test suivante. o Sassurer que les plans de test, incluant la stratgie, lapproche, les critres et les standards est (sont) prt(s) et mis en application tout au long du processus de test o Evaluer activement les critres de sortie. Sassurer quils sont bass exclusivement sur des critres de qualit. o Mener le contrle qualit durant lensemble du processus de test et de dveloppement. Sassurer que les procdures et standards sont mis en application avec le niveau de qualit prvu. o Sassurer que le test est men jusqu' ce que tous les critres d'arrt obligatoires (dfinis dans le plan de test de validation) soient remplis. o Excuter systmatiquement des revues formelles et des vrifications (inspection) sur les processus, documents et standards existants. o Dfinir les processus, procdures et standards de qualit chaque fois que ncessaire.
38/43
Distribution
Il est noter que ces approches peuvent aussi voluer au fil du temps et en fonction de la confiance que lon accorde ou non au partenaire externe. Ainsi, on peut parfaitement imaginer une situation telle quune approche optimale soit applique lors dun premier contrat avec un nouveau partenaire ceci afin de tester ses capacits et son niveau de services, tout en limitant fortement les risques puisquun contrle important est exerc tout au long du processus puis que cette approche volue vers un contrle minimal si, aprs une certain nombre de projets, le partenaire satisfait pleinement aux exigences. De mme, le niveau dapproche peut tre choisi en fonction du risque li au projet (taille, impact). Ainsi un projet critique pourrait requrir un contrle accr mme avec un partenaire tout fait digne de confiance alors quune approche minimale serait pleineement suffisante pour tout autre projet. Il va aussi sans dire que lapproche minimale est bien moins coteuse (effort et ressources, aspects contractuels...) court terme et quelle est souvent privilgie lorsque les gains esprs lors de lexternalisation se situent au niveau des cots de ralisation. Toutefois, il convient de sassurer que la livraison rpond aux exigences et aux attentes, car le cot li la nonconformit pourrait de beacoup excder le gain ralis par lexternalisation et le suivi minimum exerc sur le projet.
39/43
Distribution
PS_TESTWARE : MINIMISER LES RISQUES MAXIMISER LA CONFIANCE
40/43
Distribution
41/43
Distribution
42/43
Distribution
43/43

Externalisation RSI2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Externalisation RSI2

Uploaded by

Copyright:

Available Formats

DOSSIER

RSI LILLE 2008

Copyright 2008 ps_testware SAS

Externalisation 1 0 14/03/2008 20/03/2008 Distribution Olivier Denoo Externalisation-RSI2.doc 27032008-1 v1.4

Date de mise jour : 14/03/2008 Olivier Denoo

INFORMATIONS DE GESTION DU DOCUMENT

Contrle qualit et autorisation Date Version Rvision 20/03/2008 1 0 20/03/2008 1 0

Tche Contrle orthographique Autorisation de distribution