Z Recette Fonctionnelle

Organiser une Formation Recette fonctionnelle
recette Formation Recette fonctionnelle: 08 au 09 Février 2005

fonctionnelle
SOPRA Group
RECETTE
FONCTIONNELLE
Objet du document
Ce document a pour objectif de présenter les méthodes essentielles pour l’organisation d’une
recette fonctionnelle
Liste de diffusion :
Prénom et Nom Société - Direction Nature *
Diffusion
730526459.doc Page 1 sur 53 Dernière mise à jour le 27/02/2024 par Hospice JP. ZINSOU
fonctionnelle
SOPRA Group
fonctionnelle
SOPRA Group
TABLE DES MATIERES
1 QU’EST- CE QU’UNE RECETTE FONCTIONNELLE....................................................5

1.1 INTRODUCTION...................................................................................................................5
1.2 DÉFINITION.........................................................................................................................5
1.3 IDENTIFICATION DES ACTEURS D’UNE RECETTE.................................................................5
1.4 LES ENJEUX DE LA RECETTE FONCTIONNELLE...................................................6
1.4.1 Planification et rationalisation de la recette fonctionnelle.......................................7
1.5 LE PLAN DE RECETTE..................................................................................................7
1.5.1 Objectifs et enjeux du plan de recette........................................................................7
1.5.2 Exercice d’application...............................................................................................8
1.5.3 LA QUALITE DE LA RECETTE..............................................................................10
1.5.4 La recette est un projet dans un projet....................................................................12
1.6 CONSÉQUENCES DE LA RECETTE......................................................................................12
2 TEST ET VALIDATION......................................................................................................15
2.1 DÉFINITION DE TEST.......................................................................................................15
3 PLAN DE TEST.....................................................................................................................18
3.1 CONTENU D'UN PLAN DE TEST (1)....................................................................................19
3.4 DIFFÉRENTS TYPES DE TEST.............................................................................................21
3.4.1 Tests unitaires..........................................................................................................21
3.4.2 Tests de performance...............................................................................................21
3.4.3 Tests de validation...................................................................................................21
3.4.4 Tests de réception.....................................................................................................21
3.4.5 Tests d’intégration...................................................................................................21
3.4.6 Tests de non régression............................................................................................21
3.5 CRITÈRES D'ARRÊT DES DÉVELOPPEMENTS DE TESTS.......................................................22
3.6 RAPPORT QUALITÉ PRIX....................................................................................................22
3.7 ESTIMATION DE TEMPS.....................................................................................................22
4 LES GRANDS MODÈLES, MÉTHODOLOGIES ET NORMES D'ORGANISATION
DES TESTS....................................................................................................................................23
4.1 CMM : CAPABILITY MATURITY MODEL (MODÈLE DE MATURITÉ DE CAPACITÉ).........23
4.1.1 Qu'est-ce que le modèle CMM ?..............................................................................23
4.1.2 Le modèle CMMi......................................................................................................32
4.2 LA MÉTHODE SPICE........................................................................................................36
4.2.1 Architecture du modèle............................................................................................36
4.2.2 La dimension processus...........................................................................................36
4.2.3 La dimension niveau de maturité.............................................................................37
4.2.3.1 Comment évalue t – on les niveaux ?.......................................................................38
4.3 COMPARAISON ENTRE DEUX NORMES..............................................................................40
fonctionnelle
SOPRA Group
5 LE DOSSIER DE TEST........................................................................................................42
5.1 COMMENT RÉALISER UN BON DOSSIER DE TEST..............................................................43
5.1.1 Aspects psychologiques 1.........................................................................................43
5.1.2 Aspects psychologiques 2.........................................................................................43
5.1.3 Testabilité.................................................................................................................44
5.1.4 Facteurs de testabilité..............................................................................................44
5.1.5 Limites théoriques (1)..............................................................................................44
5.1.6 Organisation de l'activité de test.............................................................................45
5.1.7 Tâches......................................................................................................................45
5.1.8 Environnements (outils) de test................................................................................45
5.1.9 Types de test (éléments testés et phases)..................................................................45
5.1.10 Types de test (nature des propriétés testées)...........................................................46
5.1.11 Types de test (selon les informations accédées).......................................................46
6 OUTILS DE TEST ET DÁNALYSE POUR LA QUALITÉ ET LA PRODUCTIVITÉ
48
6.1 CTC++ OUTIL DE COUVERTURE DE TESTS POUR C/C++..................................................48
6.2 CMT++ ANALYSE DE COMPLEXITÉ DE CODE POUR C/C++..............................................48
6.3 CONFORMIQ TEST GENERATOR - UN OUTIL DE TEST DE LA NOUVELLE GÉNÉRATION.....48
6.4 OUTILS DE TEST ET DÁNALYSE POUR JAVA....................................................................48
6.5 JEVOLVE...........................................................................................................................49
6.6 ASSISTANT DE TESTS DE RÉGRESSION POUR JAVA - JEVOLVETM....................................49
6.6.1 Points Forts du Produit............................................................................................49
Voici comment JEvolve peut aider.....................................................................................50
Comparaison de textes........................................................................................................50
Voici quelques aperçus d'écran :........................................................................................51
Voici quelques aperçus d'écran :........................................................................................53
Installations nécessaires......................................................................................................55
6.7 OUTILS STANDARD...........................................................................................................55
6.7.1 Mercury WinRunner:...............................................................................................55
6.7.2 TestDirector:............................................................................................................55
7 Les estimation en Charge.........................................................................................................57
fonctionnelle
SOPRA Group
1 QU’EST- CE QU’UNE RECETTE FONCTIONNELLE
1.1 Introduction
La recette fonctionnelle est toujours une étape délicate. Des tensions apparaissent entre le maître
d’œuvre et le maître d’ouvrage, les problèmes sont souvent le fait de la méconnaissance de l’objet
de la recette et des techniques associées. Ce stage présente de façon concrète les règles à respecter,
les tâches à réaliser et propose une démarche constructive pour réussir sa recette.
1.2 Définition
La recette fonctionnelle correspond à la vérification de la conformité d'un SI livré par rapport
aux spécifications de la commande…
C’est plus simplement, l'attestation qu'un contrat entre deux parties à bien été respecté.
1.3 Identification des acteurs d’une recette
Nous pouvons identifier les acteurs suivants dans un processus de recette:

 Un client qui passe une commande
 Un réalisateur qui réalise la commande du client
La recette fonctionnelle consiste donc pour le client à vérifier la conformité de l'objet réalisé par
rapport à sa commande (Le plus souvent spécifié dans le cahier des charges).
Qui fait la recette ?
Le client peut décider de faire lui-même la recette du produit ou bien demander à un tiers de la
faire pour lui, mais le principe reste le même.
fonctionnelle
SOPRA Group
1.4 LES ENJEUX DE LA RECETTE FONCTIONNELLE
Pour monter les enjeux d’une recette fonctionnelle nous allons prendre un exemple simple qui est
plus familier à tous les acteurs de recette fonctonnelle :
Votre requête
Vous avez décidé de faire construire une maison ou un appartement, vous êtes donc le client et
vous demandez à un entrepreneur de vous construire votre future maison.
Sa réalisation
L’entrepreneur réalise donc après moult négociations votre maison.
Quelques mois plus tard, la maison est construire et vous pouvez le constater du moins
visuellement.
Vous avez donc bien validé le fait que l'entrepreneur ait bien construit votre maison.
Début des anomalies - ANO –
Oui mais lorsque vous vous installez, vous découvrez de nombreuses anomalies : l'interrupteur qui
n'est pas à la bonne place, le mur devait faire 2m il n'en fait que 1.90m et donc vous ne pouvez
plus placer l'armoire de votre grand-mère etc...
Spécification des ano et demande de correction
Vous vous retournez alors vers l'entrepreneur pour lui faire constater que votre maison n'est pas
comme elle devait être.
Ce qui tombe bien puisque de par la loi vous avez trois mois pour contester la livraison.
Analogie avec la recette fonctionnelle d’un SI
La recette d'un SI passe par une même logique :
On essaye la maison pour savoir si tout est comme il se doit
fonctionnelle
SOPRA Group
La recette serait par conséquent une méthode « pragmatique » qui consiste à essayer tous les
éléments, toutes les pièces, et toutes les options de la maison.
Mais cette méthode est longue.
En effet, il faut essayer, tester, et valider dans la limite des trois mois.
Oui mais pour un SI vous n'avez bien souvent pas trois mois pour essayer votre système, il doit
être mis en service à une date précise qui ne peut être modifiée.
Par conséquent, il va falloir anticiper et prévoir l’essayage avant même la livraison/

Donc anticiper la recette.
1.4.1 Planification et rationalisation de la recette fonctionnelle
1.4.1.1 Quand commencer la recette fonctionnelle ?
L’organisation de la recette fonctionnelle doit commencer longtemps avant la livraison du produit.

Dans notre cas avant la fin de la construction de la maison.
Cette date est choisie en fonction des éléments à tester et de la disponibilité du « RECETTEUR »
1.5 LE PLAN DE RECETTE
Quand le réaliser ?
Qui le réalise ?
L’acceptation du plan.
Rôle des utilisateurs.
Contenu.
1.5.1 Objectifs et enjeux du plan de recette.
Une bonne recette repose sur un « plan de recette »
Un plan de recette définit l'ensemble des réactions attendues de votre SI suite à une action.
 les réactions à des actions qui sont définies (comme l'utilisation de votre porte de
chambre qui doit s'ouvrir dans votre chambre et non pas vers le couloir).
fonctionnelle
SOPRA Group
 les réactions à des actions non définies (vous décider de faire vos exercices de
gymnastique quotidienne suspendus au chambranle de votre porte de salon et il ne doit pas
se briser…)
Un plan de test contient donc des scénarii de test.
Comme un scénariste vous allez mettre sur papier le déroulement du film qui va prochainement
être tourné.
Le plan de recette liste :
 toutes les fonctionnalités à tester,

 tous les cas possibles d'utilisation.
 Tous les cas de désagrément à éviter
 Toutes les omissions qui peuvent être volontaires ou involontaires
1.5.1.1 Comment imaginer tous les cas possibles? : Le cadre des fonctionnalités à tester
Le plan de recette doit donc reposer sur le contenu même du cahier des charges de votre SI.
ou dans le cas de notre exemple dans « le plan de construction » de la maison et/ou le contrat que
vous avez passé avec l'entrepreneur.
Le cahier des charges va donc aider à définir le cadre des fonctionnalités que vous allez devoir
tester.
1.5.2 Exercice d’application
Imaginons à présent un scénario simple :

Le Nom de la scène : Vérification du fonctionnement de la porte de ma chambre
Objectif du scénario : Vérifier l'ouverture de la porte de votre chambre.
Correction :
Les acteurs du scénario : Vous

Le décor :
 La chambre,
 le couloir de la maison et
 une porte fermée entre votre chambre et le couloir.
Les actions du scénario :
 Vous êtes dans votre chambre

 Vous vous avancez vers la porte
fonctionnelle
SOPRA Group
 Vous tournez la poigné de la porte

 Vous tirez la porte
Les résultats du scénario :
 La porte s'ouvre
 Vous marchez dans le couloir
Voilà un scénario classique d'utilisation, mais est ce que votre travail est fini pour autant ?
Non pour des soucis de qualité vous allez devoir tester un autre scénario complémentaire de celui
qui vous a été spécifié.
On rappelle :
Le Nom de la scène : Vérification du fonctionnement de la porte de ma chambre

Objectif du scénario : Vérifier l'ouverture de la porte de votre chambre.
Le décor : La chambre, le couloir de la maison et une porte fermée entre votre chambre et le
couloir.
 Vous êtes dans votre chambre

 Vous vous avancez vers la porte
 Vous tournez la poigné de la porte
 Vous poussez la porte
Résultat
 La porte ne s'ouvre pas
Donc vous avez testé la non ouverture de votre porte dans le mauvais sens
Si vous voulez vraiment être complet dans vos tests, vous allez devoir tester :
 L’ouverture de la porte depuis le couloir,
 L’ouverture de la porte en tournant la poignée dans le sens des aiguilles d'une montre
 L’ouverture de la porte en tournant la poignée dans le sens inverse ou en fermant la porte
à clé
 L’ouverture de la porte en tournant la poignée en changeant l'acteur du scénario une petite
fille de dix ans par exemple ou un ami poids lourd…
fonctionnelle
SOPRA Group
1.5.3 LA QUALITE DE LA RECETTE
La qualité de la recette dépend de la quantité réaliste des scénarii mis en place.
Imaginons à présent que vous avez bien travaillé et que les scénarii sont écrits.
Ce qui en fait beaucoup, il faut donc les regrouper en grande fonctionnalité pour pouvoir s'y
retrouver.
1.5.3.1 LES FAMILLES DE SCENARII
Les familles de scénarios pourraient donc être dans notre exemple :

 Tester les portes,
 tester l'ouverture de la porte de la chambre,
 tester le fonctionnement normal,
 tester le fonctionnement anormal,
 tester l'ouverture de la porte du salon,
 tester les fenêtres,
 tester la fermeture de la fenêtre de la cuisine
 etc. …
Une autre méthode pour classer les scénarii de test, consiste à les trier par gravité.
On peut noter les gravités :
 Elevée
 Moyenne
 Petite
 Faible
 inexistante
Le principe de cette méthode est d'anticiper la gravité des problèmes résultant du déroulement des
scénarii de test.
Exemple :
Constater que les prises électriques ne sont pas aux normes n'a pas la même gravité que constater
qu'il manque un rang de carrelage dans la salle de bain.
Les classes d’erreur
Alors que la première erreur peut être considérée comme bloquante, la seconde n'est que mineure.
Cette méthode de classement permet de porter une attention particulière aux points cruciaux du
projet.
De plus, cela va permettre d'alerter le réalisateur sur l'importance de certains points.
fonctionnelle
SOPRA Group
1.5.3.2 Différence entre gravité de scénario et gravité des erreurs
I ne faut pas confondre, gravité du scénario et gravité des erreurs.
D'un scénario de test peut découler plusieurs erreurs à niveaux de gravité est différents.
Exercice 02 :
Objectif du scénario : Installation de votre four dans votre cuisine

Les acteurs du scénario : Vous
Le décor : La cuisine
Vous placez votre four devant le meuble qui doit l'accueillir
Vous branchez la prise à 32 Ampère
Vous placez votre four dans le meuble
Les résultats du jeu de votre scénario peuvent être différents :
Tout est OK
La prise pour votre four n'est pas une 32 Ampère (Gravité de l'erreur : Bloquante)
La longueur du câble électrique de votre four ne vous permet pas d'atteindre la prise (Gravité de
l'erreur : Majeure)
La deuxième erreur est considérée comme moins grave car vous pouvez avez des parades, installer
une rallonge au niveau du câble ou bien au niveau de la prise.
Cette seconde méthode est une analyse de risque des scénarios eux mêmes. Ce principe permet
comme je le disais précédemment d'alerter à l'avance les réalisateurs de l'importance de certains
points, mais également de perde moins de temps lors de la recette avec les points d'erreurs déjà
envisagés pour ce concentrer sur les erreurs non répertoriées.
Le dernier exemple que nous avons pris introduisait également une autre notion de la recette, que
vous avez peut être entrevue… La notion de dépendance entre scénarios.
En effet le scénario d'installation du four suppose avec la première action que le meuble du four
est présent dans la cuisine. Par conséquent la scène d'installation du four doit être précédée par la
scène qui consiste à vérifier la présence du meuble four qui lui-même peut avoir d'autres
prédécesseurs.
Par conséquent la préparation de la recette consiste également à donner les séquences
d'enchaînement des scénarios. Et établir par la suite une campagne de test, c'est-à-dire un planning
de la recette qui prend en compte les scénarios avec leurs contraintes de séquence, mais également
les durées de réalisation des scénarios ainsi que les différentes ressources nécessaires pour
l'exécution des scénarios.
Vous venez donc de finir de préparer votre recette. Pour cela vous avez fait un plan de recette qui
contient l'ensemble des scénarios. Ces scénarios vous les avez regroupés en arborescence pour
vous y retrouver. Vous avez également déterminé la gravité des erreurs potentielles résultant de
l'exécution des scénarios de test. De plus vous avez conçu votre campagne de test en donnant un
ordre chronologique dans la réalisation des tests.
fonctionnelle
SOPRA Group
1.5.4 La recette est un projet dans un projet
La recette est un projet à part entière, un projet dans le projet.

C’est est la validation du produit livrée.
Mais cette vision aboutit à deux conséquences qui ne la favorisent pas.

 La première est que bien souvent la recette est un projet qui ne démarre qu'une fois que la
réalisation du SI a débuté, ce qui est trop tard comme nous l'avons vu précédemment.
 La seconde conséquence est dans la nature de ce projet qui est de valider un produit, ce
qui implique que vous n'êtes pas dans une démarche collaborative de projet.
Une autre vision de la recette est de la voir comme faisant partie intégrante de votre projet de
SI, c'est le baromètre de la qualité de votre SI.
Elle doit donc se préparer dès la mise en place de votre projet.
La préparation de la recette doit vous aider à établir le cahier des charges ainsi que les
spécifications fonctionnelles.
La recette en elle-même est un travail de collaboration entre vous et les fournisseurs qui n'a
qu'un seul objectif, celui de la réussite du projet, c'est-à-dire mettre en service un Système
d'Information de qualité.
Pour obtenir une bonne qualité il faut nécessairement une bonne recette.
Pour réussir une recette il faut tester le produit, le valider et l’accepter.
1.6 Conséquences de la recette
Donc Tout va bien, vous avez fait la plus grande partie du travail et la plus noble, il ne vous reste
plus qu'à exécuter votre recette. Rien de plus simple puisque vous avez tout préparé.
Un des problèmes les plus difficiles que vous allez avoir à traiter est relationnel.
Votre relation en tant que testeur face aux réalisateurs de votre projet.
Tout d'abord le langage employé dans la recette de SI ne vous aide pas :

Vous faite une recette, vous allez donc établir une sanction.
Vous avez un plan de test, vous êtes donc prêt à entrer dans l'arène
Vous allez engager votre campagne de test, ce n'est pas tout à fait une croisade mais presque…
Vous allez donc être mal vu par les réalisateurs parce que vous allez critiquer leurs travaux. Il est
par conséquent inutile de chercher le conflit avec les réalisateurs. Ce qui est loin d'être évident :
les anomalies vont vous énerver, retrouver quinze fois le même problème est stressant…
La recherche d'anomalie est un travail perfide, votre travail ne se justifie bien souvent que par la
découverte de nouvelles anomalies.
La "dead line" arrive, tout le monde attend la sortie de votre SI… Et donc la pression monte.
Conscient de tous ces problèmes, il faut aborder la recette avec l'idée suivante en tête : vous allez
trouver obligatoirement des erreurs… Donc autant s'y faire dès le début de la recette… Et ce
demander plutôt comment faire pour que ces problèmes soient résolus rapidement.
fonctionnelle
SOPRA Group
Une première chose qui va vous aider est le catalogue des erreurs que vous avez réalisé lors de la
phase de préparation de la recette. Il permet tout d'abord une identification plus rapide du
problème. En effet ces erreurs ont déjà été référencées et de plus le réalisateur se sent responsable
de cette erreur, il ne vous reproche plus que le cahier des charges n'était pas complet… Cela peut
vous paraître anodin comme constat, mais il faut bien prendre conscience que la recette est une
phase par définition conflictuelle et la présence de ce catalogue des erreurs potentielles vous
permet de ne pas avoir à supporter l'éternelle discussion de la responsabilité de l'erreur.
Mais il ne faut pas se leurrer, ce catalogue des erreurs n'est pas complet. Certaines erreurs n'y
seront pas référencées. Le problème consiste alors à expliquer le disfonctionnement, ce qui n'est
pas toujours évidemment si par exemple le problème n'est pas constamment constaté.
Imaginons la situation suivante : vous constaté que le disjoncteur de votre maison saute par
moment. Vous allez donc décider de créer une nouvelle anomalie qui explique que par moment le
disjoncteur électrique s'arrête. La réponse à cette anomalie sera alors certainement : "Nous
n'arrivons pas à reproduire cette erreur… Nous classons donc cette anomalie dans le dossier :
Instruite sans suite". Commence alors pour vous le challenge qui consiste à déplacer votre
anomalie du classeur "Instruite sans suite" à celui "Anomalie en résolution". En plus de la perte de
temps, vous allez devoir entrer en conflit avec le constructeur.
La première solution qui vient à l'esprit serait d'avoir des preuves de l'anomalie. Peut être serait-il
pertinent de filmer la réalisation des scénarios, vous seriez ainsi suivi par un caméraman pendant
le déroulement des scénarios. Et ce principe on le retrouve dans la recette fonctionnelle. En effet il
existe des automates qui réalisent vos scénarios en enregistrant toutes les opérations et qui
comparent les résultats obtenus aux résultats attendus. Ces outils sont bien entendus des atouts
pour les personnes qui font la recette, ils sont malheureusement encore très complexes et surtout
très contraignants. De plus même si vous avez une preuve de l'anomalie, vous n'avez en rien fait
avancer les choses dans sa résolution.
fonctionnelle
SOPRA Group
Une autre solution est donc une fois que vous avez constaté l'anomalie de fonctionnement de votre
disjoncteur électrique, de démarrez ce que j'appelle des scénarios d'exploration d'anomalie. Ce
sont bien sûr des scénarios qui n'ont pas été préparés à l'avance puisqu'ils dépendent de l'anomalie
détectée. L'intérêt de ces scénarios va être de cerner de manière plus précise la nature de
l'anomalie. Si vous reprenez l'exemple précédent, vous allez devoir tester les prises électriques les
une après les autres ou augmenter progressivement le nombre d'appareil électrique fonctionnant en
même temps…. Tous les résultats de ces scénarios ont un intérêt et pas uniquement les anomalies
comme avec les scénarios classiques. Tous les résultats obtenus par vos scénarios d'exploration
peuvent conduire les réalisateurs à comprendre la nature de l'erreur. Cette construction des
scénarios d'exploration peut prendre souvent beaucoup de temps et vous pouvez aussi considérer
que c'est le travail du réalisateur de trouver les causes de l'anomalie. Mais dans cette démarche
vous n'êtes plus à la recherche des anomalies mais à la recherche d'une solution, votre relation
avec les réalisateurs n'est plus conflictuelle mais collaboratrice. Une collaboration qui a pour
objectif la qualité de votre future SI.
Bien entendu, le sujet du déroulement de la recette n'est pas restreint à ces seuls points que nous
venons d'évoquer. Il faudrait également aborder le problème de la gestion des anomalies, c'est-à-
dire des nouvelles versions du SI qui corrigent les anomalies que vous avez détectées. Ce
problème étant plus ou moins important en fonction de la modularité du SI (concept objet).
Un autre sujet qu'il faudrait également aborder est l'environnement des tests, c'est-à-dire la
simulation de l'environnement de production. Imaginons que vous testez votre nouvelle maison
dans un environnement différent, votre maison a été déposée pour les tests en pleine campagne
alors que vous allez habiter près d'une nationale. Etes vous certain de pouvoir tester correctement
les problèmes d'insonorisations ? Pour ça il va falloir simuler le bruit d'une nationale et la qualité
de vos tests va dépendre de cette simulation audio.
D'autres problèmes sont également à aborder pour le déroulement de la recette fonctionnelle mais
l'essentielle à retenir dans ce processus est la collaboration entre les personnes qui font la recette et
ceux qui apportent les modifications au SI.
fonctionnelle
SOPRA Group
2 TEST ET VALIDATION
2.1 Définition de TEST
Il n’y a pas de définition unique de test.

Ce terme s’adapte à des domaines différents.Mais la définition la plus courante est la suivante :
Le Test consiste à exécuter une application pour trouver les anomalies qui y sont enfouies.
Il permet de vérifier que l’application fonctionne en fonction des spécifications et des
données qu’elle manipule.
C’est un ensemble des contrôles effectués au cours du cycle de vie afin de vérifier l'adéquation
entre ce qui est fourni et ce qui est attendu pour chaque étape.
CubicSoft a défini des méthodes de test et de validation qui ont pour but de détecter le plus tôt
possible les éventuelles erreurs ou dysfonctionnements logiciels.
Ces méthodes formalisent une autre étape clé du processus d'élaboration de la qualité de nos
réalisations.
L'objectif global est ainsi de pouvoir tester une première version opérationnelle d'un
développement à un taux d'avancement de 50%.
Les tests réalisés s'appuient systématiquement sur des configurations physiques et logiques les
plus représentatives possibles des environnements réels de nos clients.
Ils font notamment appel aux règles suivantes :

 Relecture croisée de code et tests mutuels entre développeurs
 "Smoke tests" quotidiens sur les builds
 Débuggage systématisé avec utilisation intensive d'outils spécialisés : Boundchecker,
Purify...
Leur application quotidienne se trouve facilitée par l'homogénéité et la cohérence de
programmation des différents développeurs.
Des procédures d'automatisation sont développées, dès que possible, afin de fiabiliser et
systématiser les validations et réduire ainsi les risques de régression tout au long des évolutions
d'un produit.
fonctionnelle
SOPRA Group
Une formalisation du reporting et du traitement des anomalies a également été mise en place :
 Base d'anomalies interne gérée à l'aide d'outils de groupware
 Base de connaissances accessible via Web dans l'Espace Client
Règles de codage
Les règles de programmation structurées sont un maillon clé dans le processus de construction de
la qualité de nos produits.
La pérennité et la maintenabilité des réalisations CubicSoft repose en grande partie sur ces règles
strictes. Elles assurent une homogénéité et une cohérence du code, améliorent la productivité des
développeurs et facilitent la réutilisation du code existant. Les règles de codage intègrent aussi
toutes les contraintes génériques garantissant la portabilité des applicatifs ou la centralisation des
problèmes (Y2K, localisation, multidevises...).
Exemples :
 Notation hongroise
 Taux de commentaires > 25% du volume de code
 Externalisation des messages (multi langues)
 Règles de découpage en fichiers
fonctionnelle
SOPRA Group
3 PLAN DE TEST
Description :
S’il n’est pas toujours évident pour un responsable du SI de tester une application, il n’en demeure
pas moins que lorsque l’idée du test est acceptée, le projet n’en est pas réussi pour autant. Les tests
doivent être menés selon une démarche et être organisés. On parlera de campagne, de scénarios,
de cas de test, ainsi que de tests unitaires, fonctionnels, de non régression...
Problématique :
Les tests doivent être menés de manière organisée et être gérés en tant que projet à part entière.
Dans une application, il n’est pas possible de tout tester, des facteurs humains entrent en ligne de
compte et dès lors ne peuvent être pris en compte par l’informatique, cependant il faut bien
s’assurer que ce que l’on décide de tester réponde à une couverture soit fonctionnelle soit
technique d’une telle ampleur que les risques pris soient minimes, par rapport au SI.
Dossier :
DEFINITIONS :
CAMPAGNE DE TEST :
C’est l’élément le plus important et qui consiste à organiser les tests. Une campagne de test décrit
quels sont les scénarios qui seront testés et donc enchaînés les uns aux autres. Dans le cadre de la
recette fonctionnelle, il s’agira de décliner les scénarii à exécuter permettant par exemple de créer
une situation applicative et ensuite dans un second scénario de faire subir des traitements
applicatifs à ces données, pour enfin vérifier les résultats obtenus. Ce sont les règles de gestion qui
font référence et constituent le résultat attendu. L’exécution de la fonction dans l’application
permettra de constituer le résultat obtenu.
PLAN DE TEST :
C’est un Document définissant l'organisation des tests :
 responsabilités,
 étapes,
 environnement de test,
 enchaînement,
 planning...
Il existe un plan de test par niveau de test.

En ce qui concerne les tests de réception, on parle de "Protocole de réception".
ou protocole de test. C’est un document qui précise ce que sera le test, quelles fonctionnalités de
l’application seront testées en précisant leur ordre ainsi que leur enchaînement. Le plan de test
décrit quelles sont les règles de gestion du dossier de conception qui seront testées.
fonctionnelle
SOPRA Group
3.1 Contenu d'un plan de test (1)
 Définition des cas de test

configuration matérielle et logicielle
pré conditions
étapes du test
critères de satisfaction
 Classifications
Classification des degrés d’importance de tests (optionnel)
Classification des degrés d’importance des erreurs éventuelles
 Chronologie et durée des étapes de test
pour chaque étape, chronologie et moyens de mise
en oeuvre des différents jeux de test
modes d'intégration
 Équipes concernées et responsabilités

 Procédures de suivi
évaluation du degré de réalisation des tests
procédures de collecte de données statistiques
 Actions à prendre en cas d'erreur
procédure de contrôle et de report des corrections
 Tests de non régression

 Classifcation
 Normes
 Outils et méthodes recommandés
 Bibliothèques de tests
 Délais et temps de calcul
fonctionnelle
SOPRA Group
SCENARIO DE TEST :
C’est le concept qui précise la fonction à tester, ce document est lié à un document de jeux de
données de test. La description y est précise et se réfère pour la recette fonctionnelle aux dossiers
de conception. Un scénario de test est composé de un ou plusieurs cas de tests.
CAS DE TEST :
C’est un composant du scénario, et représente une variante du scénario. Par exemple pour le test
d’un changement d’adresse, le cas numéro un prévoira un changement d’adresse en France, alors
que le cas de test 2 prévoira un changement d’adresse dans un pays étranger.
JEUX DE TEST :
C’est un jeu de données, inscrit dans un document dans lequel figurera de manière précise quelles
sont les données qui seront saisies dans l’application. Ce document inclura aussi le résultat attendu
au niveau des données rendues par le système, et ce en fonction des règles de gestion.
EXECUTION DES TESTS
INDUSTRIALISATION
L’industrialisation est un élément qui s’il permet selon toute évidence de limiter les taches
répétitives avec l’emploi d’un outil du marché (Qarun de Compuware, Winrunner de Mercury), on
doit toute fois encadrer cette industrialisation, laquelle peut-être considérée comme un projet à
part entière.
Une fois l’outil d’industrialisation choisi, il faut se donner le temps de définir le cadre d’emploi de
cet outil, à savoir quelle est la population qui va utiliser cet outil. Selon que l’on dispose d’une
majorité d’informaticiens ou d’une majorité d’utilisateurs métiers, la démarche ne sera pas la
même, (s’il l’on a le choix de la population, le problème ne se pose pas ici). En effet disposer
d’utilisateurs signifie enregistrer des saisies transactionnelles sur l’application avec l’outil. Alors
qu’avec des informaticiens il s’agira de programmer les saisies et de bénéficier de tout de ce que la
programmation peut apporter notamment en termes de réutilisation de code.
Il peut-être possible de choisir une voie entre les deux et qui consistera à encadrer la saisie avec
des squelettes de scénario déjà programmés et mis au point dans une phase préalable avec des
informaticiens et quelques utilisateurs fonctionnels. Cette démarche peut être facilitée avec des
outils Bureautique tels que Excel ou Access.
Niveau de Test
Types de tests à exécuter successivement pour s'assurer de la conformité du logiciel
aux spécifications fonctionnelles et spécifications techniques : les tests unitaires, tests
d'intégration, tests de validation (performances) et tests de non régression sont de la
responsabilité du titulaire du marché de production ou de TMA (Maintenance réalisée
par une entreprise qui n’est ni le fournisseur ni le propriétaire du logiciel.) à la DSI ;
les tests de réception sont de la responsabilité de l'équipe projet DSI : le MOA.
fonctionnelle
SOPRA Group
3.4 Différents types de Test
3.4.1 Tests unitaires
Tests permettant de vérifier le fonctionnement de chaque composant logiciel modifié ou

nouveau dans des cas de fonctionnement normal, aux limites ou dégradé. Ils s'appuient sur
la structure interne du composant (tests "boîte blanche"). Les vérifications portent sur :
l'initialisation des rubriques, les contrôles de saisie, les règles de gestion, les messages
d'erreur, la gestion du curseur, la gestion des touches fonctions, l'enchaînement des écrans,
...
3.4.2 Tests de performance
Tests permettant de vérifier des contraintes de temps de réponse et d'occupation mémoire.

Ils peuvent faire partie des tests de validation ou des tests de non-régression.
3.4.3 Tests de validation
Tests permettant de vérifier que les exigences fonctionnelles et techniques du cahier des
charges sont respectées. Ils s'effectuent sans connaissance de la structure interne (tests
"boîte noire").
3.4.4 Tests de réception
Tests permettant à un client de s'assurer que le cahier des charges a été respecté.
3.4.5 Tests d’intégration
Tests permettant de vérifier progressivement que l'ensemble constitué par les composants
logiciels assemblés répond aux spécifications fonctionnelles et spécifications techniques. Ils
doivent, s'il y a lieu, activer les interfaces avec les applications connexes (progiciels et
spécifiques).
3.4.6 Tests de non régression
Tests qui, dans le cas de changement de version, permettent de vérifier que les modifications
apportées n'ont pas entraîné d'effets de bord non prévus qui pourraient dégrader le
comportement du logiciel antérieurement validé. Ils portent sur l'exécution de tests déjà
joués afin de s'assurer que le système répond toujours aux exigences spécifiées.
fonctionnelle
SOPRA Group
3.5 Critères d'arrêt des développements de tests
 Taux de couverture atteint (critère a priori) suffisamment d'aspects testés

 Nombre ou taux d'erreurs découvertes (critère a posteriori)
arrêt sous un certain seuil étude de la courbe en fonction de la durée
séparation des erreurs par catégorie
 Épuisement des ressources dédiées au test ()
effort humain et/ou durée
3.6 Rapport qualité prix
 Nombre de cas de test arbitrairement grand

 Nécessité d'un compromis
précision, bon degré de couverture, bonnes informations pour les développeurs (debug)
coût (définition, réalisation, passage, dépouillement) temps d'exécution de tests
nb de ressources de calcul (machines) mobilisées
3.7 Estimation de temps
1/10 du nombre de jours homme
fonctionnelle
SOPRA Group
4 LES GRANDS MODÈLES, MÉTHODOLOGIES ET NORMES

D'ORGANISATION DES TESTS
4.1 CMM : Capability Maturity Model (Modèle de Maturité de Capacité)
Modèle d'évaluation et d'évolution des processus logiciels, le CMM repose sur les bonnes
pratiques et s'étend à de nombreux domaines.
4.1.1 Qu'est-ce que le modèle CMM ?
Le CMM (Capability Maturity Model) est un modèle d'évaluation et d'évolution des processus
logiciels.
Le CMM est un référentiel de pratiques clés à mettre en oeuvre pour l'entreprise qui développe des
logiciels. Son objectif est de la guider dans sa démarche d'amélioration des processus. En raison
de l'adhésion croissante dont il fait l'objet, le « Capability Maturity Model » est devenu une
référence.
Il a été élaboré en 1987 par Watts Humphrey, du SEI (Software Engineering Institute) de
l'université Carnegie Mellon de Pittsburgh (Pennsylvanie).
Il comporte cinq niveaux de maturité :
 initial,
 reproductible,
 défini,
 maîtrisé et
 optimisé.
Ces niveaux constituent autant d'étapes sur le chemin menant à des processus matures, c'est-à-dire
conformes à un ensemble de bonnes pratiques observées à travers le monde dans des entreprises
réputées pour bien gérer leurs processus.
Par exemple la conformité au modèle CMM est notamment requise pour contracter avec le
département américain de la défense.
4.1.1.1 Comment fonctionne le modèle ?
Chacun des cinq niveaux de maturité est divisé en plusieurs secteurs clés.
A titre d'exemples, en voici certains pour les niveaux de 2 à 5 (le niveau 1 n'en contient pas) :
 Niveau 2 : planification de projet, assurance qualité.

 Niveau 3 : définition des processus, ingéniérie des produits logiciels.
 Niveau 4 : gestion quantitative des processus et de la qualité logicielle.
 Niveau 5 : gestion des changements technologiques et des changements de processus.
fonctionnelle
SOPRA Group
Chaque secteur clé est décrit par un ensemble de caractéristiques communes qu'il convient de
remplir si l'on veut satisfaire aux exigences d'un secteur clé.
Les caractéristiques communes contiennent des pratiques clés dont la réalisation est nécessaire
pour atteindre les objectifs. Pour passer d'un niveau à l'autre, il faut obtenir la certification du SEI.
4.1.1.2 Quelles évolutions et déclinaisons pour le CMM ?
Le CMM évolue et a récemment donné naissance au CMMI (Capability Maturity Model

Integrated) qui concerne, outre l'aspect logiciel, les aspects "systèmes" des développements.
Le CMM se décline sinon en quatre sous-modèles.
 Le SW-CMM (SW signifiant software), modèle le plus connu et qui s'applique aux
logiciels.
 Le SA-CMM (Software Acquisition CMM) concerne la normalisation des processus
d’acquisition des progiciels.
 Le SE-CMM (Systems Engineering CMM) est propre à l'ingéniérie système tandis que
l'IPD-CMM (Integrated Product Development CMM) touche la conception et la production
de produits.
 Enfin, le P-CMM semble lui aussi émerger, il s'applique à la gestion du personnel.
4.1.1.3 Quels autres modèles se rapprochent du CMM ?
Le modèle ISO-SPICE (Software Process Improvement Capability dEtermination) peut être

assimilé au CMM, même s'il se veut plus généraliste et pratique une évaluation processus par
processus.
Depuis quelques années, la tendance de SPICE est de se définir comme un méta-modèle, c'est-à-
dire une référence à laquelle des modèles tels que CMM devront se référer.
4.1.1.4 Quelles limites à ce modèle ?
Les détracteurs du modèle CMM lui reprochent parfois son manque de fondement théorique, le
modèle reposant essentiellement sur des bonnes pratiques constatées dans diverses entreprises,
notamment des administrations.
Un référentiel clair et unique, base de toute démarche s'appuyant sur un modèle, pourrait donc
faire défaut au CMM.
Par ailleurs, les fondamentaux sur lesquels repose le CMM sont sources de contestation.
Le CMM présuppose en effet que des processus stables et éprouvés sont les principaux garants
fonctionnelle
SOPRA Group
d'un fonctionnement optimal, tenant peu compte des aspects organisationnels et humains.
Le CMM a malgré tout gagné ses lettres de noblesse à travers le monde et a certainement séduit
ses partisans justement par ses bonnes pratiques.
Résumé
Le Capability Maturity Model (CMM) est un système qualité qui vise à améliorer le
processus de développement logiciel.
Il permet à une organisation de mesurer son niveau de maturité et de faire évoluer sa

capacité de développement logiciel.
Ce modèle d'évaluation et d'évolution des capacités se base sur une grille de maturité
hiérarchisée.
Historique
Bien que les ingénieurs d'étude et les dirigeants connaissent leurs problèmes dans
les moindres détails ; souvent, ils ne peuvent pas se mettre d'accord sur les
importantes améliorations à apporter. Sans une stratégie organisée pour
l'amélioration, il est difficile de choisir, entre la direction et les professionnels, les
activités d'amélioration à entreprendre en premier. Une organisation d'évolution de
processus logiciel en "échafaudage" a été inventée, elle permet de réaliser des
résultats de processus d'amélioration. Ce sont les travaux de Watts Humphrey qui
ont découpé cet "échafaudage" en différents "étages" ordonnés afin que les
améliorations réalisées à chaque étage fournissent la fondation. Par conséquent,
une amélioration de la stratégie réalisée avec la mise en ?uvre des processus de
maturité de logiciel fournit une carte routière pour des processus d'amélioration
continus. Cela guide l'avancement et identifie des défaillances dans l'organisation.
La méthode CMM a été désignée pour guider à la construction d'organisation logiciel en

sélectionnant les processus d'amélioration de la stratégie en déterminant le processus actuel
d'évaluation et en identifiant les quelques issues les plus critiques pour les logiciels de
qualité et le processus d'amélioration. En se focalisant sur un ensemble limité d'activités et
en travaillant agressivement afin de les achever, une organisation peut régulièrement
perfectionner sa vaste organisation de processus logiciel pour être capable d'avoir des gains
continus et durables.
L'organisation en étages de la méthode CMM est basée sur les principes de production de
qualité qui existent depuis les six dernières années.
Dans les années 1930, Walter Shewart a promulgué les principes du contrôle de qualité. Ses
principes ont été énormément développés et démontrés avec succès dans le monde par W.
Edward Deming et Joseph Juran. Ces principes ont été adaptés par le SEI (Software
Engineering Institute) dans une structure de maturité qui établit un projet de direction et une
technique de fondation pour les contrôles de quantités de production logiciel.
fonctionnelle
SOPRA Group
La structure de maturité dans laquelle les principes de qualité avaient été adaptés à inspiré en
premier Philip Crosby. La grille de maturité de ce dernier décrit cinq niveaux évolutifs en
adoptant les principes de qualité. Cette structure de maturité a été adaptée au processus de
logiciel par Ron Radice et ses collègues qui travaillaient sous la direction de Watts
Humphrey chez IBM. Humphrey a amené la structure de maturité au SEI en 1986, en
ajoutant le concept de niveaux de maturité et en développant la fondation pour son utilisation
courante et entière des logiciels de l'industrie.
Les versions de la structure de maturité de Humphrey sont décrites dans les rapports
techniques du SEI. Un premier questionnaire de maturité a été réalisé en 1987 comme un
outil pour fournir les organisations avec un chemin pour caractériser la maturité de leurs
logiciels de processus. Deux méthodes, un logiciel de processus d'évaluation et un logiciel de
capacité d'évaluation, ont été développées pour estimer les logiciels des processus de
maturité en 1987. Depuis 1990, le SEI, avec l'aide du gouvernement et de l'industrie, a
favorisé l'expansion et redéfinie le modèle basé sur plusieurs années d'expérience dans cette
application de processus d'amélioration logiciel.
En conclusion, CMM est donc un modèle d'évaluation et d'évolution des capacités de
développement logiciel qui a été mis au point par le SEI à la demande du gouvernement
américain. Le cadre conceptuel du modèle d'évolution des capacités logiciel a pour origine
les travaux de Watts Humphrey. Dans le cadre du développement d'applications, CMM
permet à une organisation de s'évaluer et d'améliorer par paliers ses pratiques
méthodologiques.
fonctionnelle
SOPRA Group
Principe et Structure
Dans le développement logiciel, les ingénieurs d'études et les dirigeants connaissent les
problèmes à résoudre, mais leurs opinions divergent quant aux améliorations à apporter.
Ils ne disposent pas toujours d'un cadre structuré, définissant les étapes à suivre dans l'évolution
de la qualité logiciel.
Le CMM - Capability Maturity Model ou encore modèle d'évaluation et d'évolution des capacités
de développement logiciel, est un système qualité permettant d'atteindre des objectifs de coûts, de
délais et de qualité.
Contrairement à la norme ISO 9000, CMM a été conçu spécifiquement pour le développement
logiciel.
Ce modèle offre à une organisation ou une entreprise cherchant à améliorer ses capacités de
développement logiciel les trois points suivants :
o une structure d'évaluation de son niveau de maturité
o un ensemble de procédures documentées pour améliorer son niveau de maturité
o un ensemble de processus de contrôle pour valider les étapes de cette progression
Pour pouvoir s'améliorer, l'organisation doit tout d'abord prendre connaissance de son niveau de
maturité actuel.
 Pour ce faire, elle rempli des questionnaires produit par le SEI (Software Engineering
Institute). Ces questionnaires servent de base pour mettre en évidence ses lacunes et se
positionner dans la grille de maturité définie par le SEI.
 Puis l'organisation se fixe un niveau de maturité supérieur à atteindre.
Grâce au CMM, elle dispose alors d'une liste détaillée des actions à entreprendre.
En réalisant l'ensemble des étapes intermédiaires du plan d'action, l'organisation atteint le niveau
de maturité recherché.
fonctionnelle
SOPRA Group
Le schéma ci-dessous décrit la structure interne des niveaux de maturités
Le CMM défini cinq niveaux de maturité, qui hiérarchisent la compétence

d'une organisation dans le développement logiciel. Ces niveaux sont :
o initial
o reproductible
o défini
o maîtrisé
o optimisé
fonctionnelle
SOPRA Group
A l'exception du niveau 1, chaque niveau de maturité comporte plusieurs secteurs clés.

Ces secteurs clés caractérisent les domaines à améliorer, pour répondre aux exigences de
chaque niveau de maturité. A titre d'exemple, les secteurs clés du niveau 2 sont :
o la gestion des exigences
o la planification du projet
o le suivi et la supervision du projet
o la gestion de la sous-traitance
o l'assurance qualité
o la gestion de configuration
Chaque secteur clé comprend cinq caractéristiques communes.
Celles-ci indiquent si la mise en œuvre d'un secteur clé est efficace, reproductible et
durable.
Les caractéristiques communes à chaque secteur clés sont les suivantes :
o Engagement de réalisation
o Capacité de réalisation
o Activités réalisées
o Mesure et analyse
o Vérification de mise en œuvre
Enfin chaque secteur clé est décrit par des pratiques clés à respecter.
Si ces pratiques clés sont mises en œuvre, on atteint l'amélioration requise pour le secteur
clé.
Il est à noter que les pratiques clés sont regroupées en terme de caractéristiques communes
dans la documentation du CMM.
fonctionnelle
SOPRA Group
Les 5 niveaux de maturité
CMM comporte 5 niveaux de maturité.
Les niveaux de 2 à 5 peuvent être caractérisés à travers une activité réalisée par :
o Une organisation pour établir un processus logiciel
o Chaque projet
o Le résultat des processus de capacité obtenus à travers les projets

La caractéristique du niveau 1 est d'établir une base de comparaison pour
l'amélioration des processus aux niveaux de maturité supérieurs.
 Niveau 1 - le niveau "initial"
A ce niveau, l'organisation n'est pas dans un environnement stable, pour

l'évaluation, le développement et la maintenance de logiciels.
Lors d'un projet, souvent des moments de crise surviennent , le peu de
méthode qui existait est alors abandonnée pour tenter des raccourcis dans le
processus de réalisation et de validation, c'est à dire que des pratiques
d'engagement purement réactives seront choisies : « le codage et les tests ».
Cela aura pour effet d'amplifier la dérive du projet.

A ce moment là, le succès du projet dépend entièrement des capacités de ses
dirigeants et/ou de l'équipe qui le réalise.
Ce succès varie avec leur connaissance et leur motivation.
Par conséquent, la stabilité du projet dépend entièrement de ces personnes
mais quand ces dernières quittent le projet alors il n'est plus stable.
 Niveau 2 - le niveau "reproductible"
A ce niveau, la gestion de nouveaux projets est basée sur l'expérience

d'anciens projets similaires.
Par conséquent, c'est l'engagement permanent des ressources humaines qui
garantie une pérennité du savoir-faire dans la limite de leur présence au sein de
l'organisation des nouveaux projets.
fonctionnelle
SOPRA Group
 Niveau 3 - le niveau "défini"
A ce niveau, les directives de gestion de projet sont établies.

Le processus standard de développement et d'évolution du logiciel est
documenté, il contient de façon claire les procédés d'ingénieries logiciel et de
gestion de projet.
Un programme de formation est également mis en place au sein de
l'organisation afin que les utilisateurs et les informaticiens acquièrent les
connaissances et les compétences nécessaires pour assumer le nouveau rôle
qui leur a été confié.
 Niveau 4 - le niveau "maîtrisé"
A ce niveau, l'organisation se fixe des objectifs qualitatifs et quantitatifs

La productivité et la qualité sont mesurées.
Un contrôle est assuré, il se base sur la validité des jalons majeurs du projet
dans le cadre d'un programme planifié sur mesure. Quand les limites (à
respecter) sont dépassées, cela déclenche une action particulière afin de
modifier la situation.
 Niveau 5 - le niveau "optimisé"
A ce niveau, l'organisation entière est centrée sur l'amélioration continue

des processus, c'est sa principale préoccupation.
L'organisation a les moyens d'identifier et de mesurer les faiblesses de ses
processus et a pour but de limiter le nombre de défections en déterminant leurs
causes.
Une cellule de veille technologique identifie puis acquiert et met en œuvre les
produits innovant.
Elle cherche les pratiques d'ingénierie logiciel les plus efficaces
particulièrement celles dont la synergie permet l'amélioration continue de la
qualité.
L'amélioration se fait donc tout d'abord par une plus grande maîtrise des
avancements dans les processus existants et puis par les innovations utilisant les
nouvelles technologies et méthodes.
fonctionnelle
SOPRA Group
Ce schéma montre bien l'évolution d'un processus logiciel à chaque niveau de

maturité : au fur et à mesure de son évolution, il est de plus en plus complet.
4.1.2 Le modèle CMMi
C'est le successeur du CMM, un modèle d'évaluation des processus de développement d'un

produit logiciel.
Depuis deux ans, le CMMi (i pour integrated) a été intronisé comme successeur du CMM.
Il couvre un domaine plus vaste que ce dernier.
Au développement logiciel s'adjoignent d'autres secteurs.
 Notamment l'ingénierie systèmes et l'acquisition de logiciels. « Le seul aspect à n'être

pas bien couvert est l'exploitation informatique », précise Annie Combelles, présidente de
Q-Labs France, spécialiste du génie logiciel.
Comme le CCM, le CMMi permet de classer en cinq niveaux de maturité les pratiques de
l'entreprise (voir plus haut).
Le niveau de maturité 1 étant le niveau par défaut que détient toute organisation.
Le niveau 3 est le niveau moyen généralement visé.
fonctionnelle
SOPRA Group
Pour atteindre chaque étage, l'entreprise doit mener des actions d'amélioration au niveau de
processus clés. Actions qui peuvent concerner l'entreprise entière, ou simplement une division ou
un service.
La méthode utilisée s'apparente à un véritable projet d'entreprise formalisé selon une « roue de
l'amélioration » .
Il s'agit d'un processus itératif, que l'entreprise doit répéter autant de fois qu'il le faut pour passer
au niveau supérieur.
Le modèle CMMi n'induit pas d'organisation particulière.
Seules les pratiques doivent satisfaire aux exigences du modèle. Son champ d'action n'est pas non
plus la qualité du produit fini. Seuls les procédés sont concernés.
Le postulat étant que l'entreprise a plus de chances de concevoir un logiciel de qualité si le

processus pour le fabriquer est de qualité.
fonctionnelle
SOPRA Group
Tableau récapitulatif
La représentation continue
Dans cette représentation, les secteurs clés sont regroupés en quatre catégories:
 gestion de processus,
 gestion de projet,
 ingénierie et support, comprenant respectivement 5, 8, 6 et 6 secteurs clés.
À chaque secteur clé est associé
 un niveau de capacité, sur une échelle allant de 0 à 5:
Niveau Description
Niveau 0 - Les objectifs associés à ce secteur clé ne sont pas

Incomplet remplis.
Niveau 1 - Les objectifs sont atteints, mais cette réussite repose

Réalisé essentiellement sur les individus.
Niveau 2 - Géré Les objectifs sont remplis en suivant des plans préétablis.
Une politique de normalisation des processus est mise en

Niveau 3 - Défini
place au niveau de l'organisation.
Des mesures sont effectuées pour contrôler les

Niveau 4 -
processus et agir en cas de déviation par rapport aux
Maîtrisé
objectifs de l'organisation.
Les processus sont sans cesse remis en question afin

Niveau 5 - En
d'être toujours en adéquation avec les objectifs de
optimisation
l'organisation.
 Niveau 1 - Initial : le processus de développement n'est pas défini. La réussite des projets dépend
du savoir-faire de quelques personnes clés dans l'organisation. Ce savoir-faire n'est pas formalisé
ni partagé par les différentes équipes projet de l'organisation,
 Niveau 2 - Reproductible : les entrées et les sorties des différentes activités sont gérées et
contrôlées. Les règles sont connues et appliquées par les équipes. Le développement est planifié
et suivi. Les produits sont vérifiés par rapport aux exigences initiales,
 Niveau 3 - Défini : les meilleures pratiques mises en oeuvre au niveau 2 sur les projets sont
généralisées à toute l'organisation. Un projet instancie le processus standard afin de définir la
fonctionnelle
SOPRA Group
meilleure solution répondant à ses propres objectifs. L'efficacité de chacun des processus est
mesurée et renforcée,
 Niveau 4 - Maîtrisé : chaque processus est systématiquement mesuré. Les données sont
consolidées et exploitées pour la prise de décision et l'anticipation des risques,
 Niveau 5 - Optimisation : les processus sont totalement maîtrisés et optimisés en permanence.

Toute évolution est anticipée et gérée.
Il est ainsi possible de déterminer le profil d'une organisation, en étudiant pour chaque secteur clé
son niveau de capacité. Tous les secteurs clés n'atteignent pas forcément le même niveau, ce qui
permet de déceler les points forts et les points faibles de l'organisation
fonctionnelle
SOPRA Group
4.2 La méthode SPICE
SPICE: Software Process Improvement and Capability dEtermination)
C’est un modèle de maturité
En 1991, l'ISO a décidé de lancer une étude destinée à analyser les besoins et les exigences d'un
standard pour l'évaluation des processus logiciels.
Le résultat de cette étude a conduit à la définition d'un standard, le modèle SPICE (Software
Process Improvement and Capability dEtermination), sous forme d'un rapport technique
préliminaire de l'ISO.
4.2.1 Architecture du modèle
Le modèle SPICE est bidimensionnel : un axe correspond aux processus et l'autre au niveau de
maturité.
4.2.2 La dimension processus
Le modèle de référence SPICE identifie des processus pour les activités liées au développement, à
la maintenance, à l'exploitation, à l'acquisition et à la fourniture de logiciel.
Ces processus sont regroupés en 5 catégories :
1. Relations client-fournisseur : toutes les interactions avec le lient
2. Ingénierie : construction du produit logiciel
3. Support : soutien à l'exécution des autres processus
4. Gestion : gestion de la construction du produit logiciel
5. Organisation : infrastructure et environnement dans lesquels opèrent les autres processus.
Ces catégories peuvent être structurées selon la figure suivante :
fonctionnelle
SOPRA Group
4.2.3 La dimension niveau de maturité
Le modèle SPICE comprend 6 niveaux (contre 5 pour CMM) de maturité :
 Incomplet : Les pratiques de base ne sont pas effectuées, il n'y a pas de produit ou de
résultat du processus facilement identifiable.
 Effectué : Les pratiques de base sont effectuées, des produits en fournissent la preuve. Le
processus est géré au niveau de l'individu.
 Géré : Les activités sont planifiées et suivies par rapport au plan. Les produits sont vérifiés
et respectent les standards. La planification s'effectue au niveau projet.
 Etabli : Les activités s'effectuent suivant un (ou plusieurs) processus standard défini(s) au
niveau de l'organisation. Ce processus standard est adapté aux besoins de chaque projet.
 Prévisible : Des mesures sont utilisées pour le contrôle quantitatif du processus et de la
qualité des produits.
 Optimisé : Les processus standards de l'organisation font l'objet d'améliorations continues.
Ces améliorations sont évaluées sur la base du feed-back quantitatif provenant de
l'exécution des processus.
Forme pyramidale des 6 niveaux du modèle « SPICE »
fonctionnelle
SOPRA Group
4.2.3.1 Comment évalue t – on les niveaux ?
L'évaluation d'un niveau se fait indirectement, en considérant un ensemble d'indicateurs (ou

attributs).
Neuf indicateurs sont définis, chacun étant lié à un niveau de maturité :
Chaque indicateur est évalué selon l'échelle suivante :

N Pas effectué
P Partiellement réalisé
L Largement réalisé
F Totalement effectué
Le profil d'un processus est alors mesuré comme dans l'exemple ci-dessous :
fonctionnelle
SOPRA Group
4.2.3.2 Démarche d'évaluation
Une grande liberté est laissée quant à l'approche de l'évaluation. Celle-ci peut être conduite par
une équipe interne, externe ou mixte. L'évaluation peut être instantanée ou s'effectuer en continu
sur une longue période.
Au niveau des processus également, il est possible de choisir un nombre variable de processus et
d'instances de ces processus :
fonctionnelle
SOPRA Group
4.3 Comparaison entre deux normes
Comparaison avec d'autres modèles d'évaluation
ISO 9001
La norme ISO 9001 spécifie un ensemble d'exigences pour systèmes de qualité, dans un cadre
contractuel (client fournisseur).
Elle ne contient pas de modèle d'évaluation.
Le domaine couvert par ISO 9001 appliqué au développement logiciel est, en gros, similaire
à celui de SPICE.
Etant utilisée dans un contexte de certification, ISO 9001 ne fournit qu'un résultat binaire, de type
réussi / échoué.
La comparaison SPICE - ISO 9001 est résumée dans le tableau suivant :
SPICE ISO 9001

Référentiel volumineux Référentiel concis
Modèle détaillé Modèle abstrait, de haut niveau
Conçu pour le développement du logiciel Conçu pour un usage général
Orienté amélioration des processus et évaluation de la Orienté certification d'une organisation
maturité
Six niveaux de maturité pour chaque processus Réussi / échoué
Evaluation Audit
Peut servir de guide pour l'obtention de la certification Peut constituer un point de départ pour démarrer un
ISO 9001 projet d'amélioration selon SPICE
fonctionnelle
SOPRA Group
5 LE DOSSIER DE TEST
Un bon dossier de Test contient :
 Un Plan de Test (fait en amont depuis le cahier des charges. Tout le Tes repose sur le
plan)
Etape du Test
 Un journal de Test daté et si possible « versionné » (conseillé)
 Un ou plusieurs rapports d’anomalies (rapport d’ano)
 Un procès verbal PV signé (Négatif ou Positif )
 Une conclusion obligatoire (Possibilité éventuelle à une sollicitation de demande de
norme)
On rappelle que le Test :
 Vérifie que le produit est conforme aux intentions

 Est l’aspects surtout fonctionnels
 Le Moyen de l'assurance qualité
 Est le plus utilisé, aussi « vieux » que le développement
 Est la Méthode dynamique (en exécutant le logiciel)
 vient après les méthodes statiques
 est le dernier rempart contre les erreurs
 Est encore trop souvent empirique
fonctionnelle
SOPRA Group
5.1 Comment réaliser un bon dossier de Test
5.1.1 Aspects psychologiques 1
5.1.1.1 Importance de l'intention
les tests sont élaborés en fonction de l'intention :

vouloir démontrer que le programme marche = mauvaise approche car les tests sont choisis en
conséquence (ne trouvent rien de neuf)
5.1.1.2 Activité de test
Processus « destructif »
Objectif visé : mettre en évidence des erreurs si on n'y aboutit pas, c'est un échec ((!!)) et c’est
vrai.
5.1.2 Aspects psychologiques 2
5.1.2.1 Importance de l'intention
 Plus facile de trouver les erreurs des autres que les siennes
 on ne détruit pas bien ce qu'on a construit soi-même
 à force de regarder, on ne voit plus rien
 regard neuf : nouvelle interprétation des spécifications (Spec)
5.1.2.2 Séparation des tâches e des liens
 équipes de développement équipes d'intégration et de qualification

 budget de qualification et de développement séparés
 Collègues de pause de café (développeurs et « Testeurs »)
fonctionnelle
SOPRA Group
5.1.3 Testabilité
 Facilité avec laquelle des tests peuvent être développés à partir du document
 faisabilité
 coût
 critères de décision de succès ou d'échec d'un test
 couverture
 Se prépare tout au long du cycle de vie
 spécifications, conception globale et détaillée
 (compréhensibles, précises, pertinentes, quantifiées...)
5.1.4 Facteurs de testabilité
 Facteurs de bonne testabilité

 précision, complétude, traçabilité des documents
 architecture simple et modulaire
 abstraction à travers des interfaces
 politique claire des traitements d'erreur
 Facteurs de mauvaise testabilité
 forte contraintes d'espace mémoire et d'efficacité
 intégration forte des traitements
 longue chaîne de traitement
5.1.5 Limites théoriques (1)
 Notion d'indécidabilité
 propriété qui ne peut pas être prouvée dans le cas
 général (pas de procédé systématique)
 Exemples de propriétés indécidables :deux programmes calculent la même fonction
un programme n'a pas d'erreur
un paramètre fait passer l'exécution
sur une instruction, une branche, un chemin donné
sur toutes les instruction, branches ou chemins
Une bataille perdue d'avance :

 un jeu de tests n'examine qu'un nombre fini (petit) d'exécutions possibles
 un programme a un nombre infini (ou gigantesque) d'exécutions possibles
 Trouver des heuristiques :
approcher l'infini (ou le gigantesque) avec le fini (petit)
tester les exécutions les plus « représentatives »
fonctionnelle
SOPRA Group
5.1.6 Organisation de l'activité de test
 Activité coûteuse : optimiser l'investissement

 effort minimum / probabilité max. de détection d'erreur
 incrémentalité
 Construction des tests
 comme celle d'un produit (!)
 ( sociétés qui vendent / achètent des suites de test)
 Gestion projet
 planification suffisamment tôt (difficile d'accroître les ressources en fin de
développement)
5.1.7 Tâches
 Définition des tests

 Implémentation des jeux de tests
 Soumission des jeux de tests
 Dépouillement des résultats
 Évaluation de la qualité des tests
 Décision d'arrêter les tests
 Rejeu (maintenance, non régression)
5.1.8 Environnements (outils) de test
 Mise en oeuvre des jeux de test

 construction de données et de contexte d'exécution
 Automatisation du diagnostic
 définition de critères de conclusion
 Synthèse des résultats car les sorties des tests sont souvent très grosses et surtout ne pas
rater une erreur dans une masse de succès
 Diffusion des résultats
5.1.9 Types de test (éléments testés et phases)
 Tests unitaires
test d'une fonction, une classe, un module (pendant le développemente en interne si possible)
 Tests d'intégration
test de l'assemblage des modules (pendant le développement)
 Tests de validation chez le fournisseur, par l'équipe de qualification, puis chez le client
 Tests de suivi d'exploitation
fonctionnelle
SOPRA Group
5.1.10 Types de test (nature des propriétés testées)
 Tests fonctionnels
réaction à certaines entrées (sorties produites)
 Tests de performance
vitesse, charge, ...
 Tests de fiabilité
résistance aux pannes
 Tests de sécurité
Tous types et étapes de test pas nécessairement présents : dépend de la criticité du logiciel
5.1.11 Types de test (selon les informations accédées)
 Test boîte noire [black box testing]

évaluation de l'extérieur (sans regarder le code) uniquement en fonction des entrées et des
sorties sur le logiciel ou un de ses composants
 Test boîte blanche [white/glass box testing] exploite le code ( peut nécessiter le source)
tests de portions de code : bloc, branche, etc.
fonctionnelle
SOPRA Group
6 OUTILS DE TEST ET DÁNALYSE POUR LA QUALITÉ ET LA PRODUCTIVITÉ
6.1 CTC++ outil de couverture de tests pour C/C++
meilleurs tests et plus de sécurité avec lún des plus puissants outils de couverture du marché: couverture
de fonction, de décision, de condition, de condition multiple et de condition/décision modifiée (MC/DC) -
répond à la norme DO-178B pour líndustrie aéronautique.
Systèmes embarqués: toutes cibles
6.2 CMT++ analyse de complexité de code pour C/C++
analysez la complexité de vos applications afin de trouver des parties trop complexes - facile à utiliser,
résultats rapides et clairs - métriques de McCabe, d´Halstead, et lignes de code, "index de maintainabilité"
6.3 Conformiq Test Generator - un outil de test de la nouvelle génération
génération automatique de cas de tests basée sur des modèles graphiques

facilite le test de fonction, de système, dácceptation, de régression, díntégration, de protocole et de
plateforme, tous languages de programmation
6.4 Outils de test et dánalyse pour Java
Analyses de couverture de tests, analyses d´évolution de code source, tests unitaires et díntégration
basés sur le principe d´"Invasive Testing", tests de syntaxe, analyse de complexité de code, ...
fonctionnelle
SOPRA Group
6.5 JEvolve
JEvolve aide à comprendre l´évolution de votre code Java dans ses différentes versions. Lóutil indique par
exemple les modifications du code dans les différentes versions de JDK et montre également les effets des
modifications de code sur les tests de régression.
6.6 Assistant de Tests de Régression pour Java - JEvolveTM
L'outil que les développeurs de Java attendaient impatiemment est finalement arrivé. Si vous avez déjà dû
faire face à la gestion de plusieurs versions d'un projet, si les changements entre versions vous ont déjà
inquiété, voici l'outil qui va réellement simplifier votre travail.
JEvolve est un assistant de tests de régression Java "intelligent". Il analyse automatiquement les mulitiples
versions d'un programme Java et montre comment les différentes classes ont évolué au cours des
versions. Il raisonne ensuite sur l'impact que ces changements ont sur les tests de régression et vous
indique quelles classes⁄méthodes doivent être retestées. Cela implique que même si une classe a subi des
modifications, il n'est parfois pas nécessaire de la retester. Imaginez les efforts de revalidation et le temps
épargnés!
6.6.1 Points Forts du Produit
 Analyse "intelligente" des tests de régression
 Haute performance - peut travailler sur des projets complexes
 Nombreux rapports et graphiques
 Nombreuses possibilités de supports de scripts
 Compris gratuitement: "Java source beautifier" et "class file browser"
6.6.1.1 JEvolve est utile pour
 Identifier les portions d'un programme Java qui ont changé et qui ont besoin d'être retestées
 Les équipes de travail de maintenance pour les aider à comprendre comment une classe a évolué
 Les responsables de projet afin d'établir la traçabilité des changements de code
 "Les configuration managers" afin de valider et de répertorier les changements de code
 Les développeurs afin d'identifier l'impact de l'intégration avec une bibliothèque modifiée, tel que le
JDK
fonctionnelle
SOPRA Group
Voici comment JEvolve peut aider

 En analysant automatiquement les multiples versions de code source Java
 En mettant en évidence ce qui a changé à travers les versions
 En vous indiquant quelles seront les conséquences sur les autres classes lorsque vous modifiez
une classe donnée
 En montrant le contexte de changement entre les anciennes et les nouvelles versions
 En comprenant quelles conséquences auront les changements de versions de JDK sur votre
application
 En indiquant quelles méthodes⁄classes n'ont pas besoin d'être retestées
Comparaison de textes
Comment comparer l'"intelligence" de différenciation de JEvolve avec l'approche des outils de comparaison
de textes ordinaires ? Les outils classiques de comparaison de textes font une comparaison lexicale sans
comprendre le texte comparé.
JEvolve, quant à lui, connait le langage Java; il peut donc comparer les deux programmes Java
"intelligemment".
fonctionnelle
SOPRA Group
Voici un exemple:
Considérez une classe Java qui a subi des modifications d'une version à une autre.
Version 1 Version 2
class MyClass { public final class MyClass {
private int i; public void g(int arg) {
value = arg;
void f() { }
i = 90;
} void f() {
value = 90;
public void g(int k) { }
i = k;
} private int value;
} }
Exécutez un utilitaire de comparaison de texte sur ces deux programmes et notez les différences. Ensuite, essayez de
les deux programmes en utilisant JEvolve. Vous serez sans doute agréablement surpris par ce que JEvolve a été c
remarquer. Son "intelligence" compare pour vous.
Vous pouvez visualiser d'autres détails sur l'approche de recherche ici (en anglais).
Voici quelques aperçus d'écran :

Comparison View:
File Comparison View:
fonctionnelle
SOPRA Group
Atomic Changes Report View:
fonctionnelle
SOPRA Group
Version 1 Version 2
class MyClass { public final class MyClass {
private int i; public void g(int arg) {
value = arg;
void f() { }
i = 90;
} void f() {
value = 90;
public void g(int k) { }
i = k;
} private int value;
} }
Exécutez un utilitaire de comparaison de texte sur ces deux programmes et notez les différences. Ensuite, essayez de
les deux programmes en utilisant JEvolve. Vous serez sans doute agréablement surpris par ce que JEvolve a été c
remarquer. Son "intelligence" compare pour vous.
Vous pouvez visualiser d'autres détails sur l'approche de recherche ici (en anglais).
Voici quelques aperçus d'écran :

Comparison View:
File Comparison View:
fonctionnelle
SOPRA Group
Atomic Changes Report View:
fonctionnelle
SOPRA Group
Installations nécessaires
Processeur
Intel Pentium ou plus
Système d'exploitation
Windows 95/98/ME/2000/XP/NT (patch 4)
Version JDK
1.0 à 1.4
RAM
64 MB ou plus
Disque dur
au moins 10 MB d'espace libre pour l'installation
6.7 Outils standard
6.7.1 Mercury WinRunner:
 Diminution du temps de test grâce à l'automatisation des tâches répétitives.

 Optimisation des tests en couvrant divers environnements avec un seul outil de test.
 Retour sur investissement maximal grâce à la modification et à la réutilisation des scripts
de test à mesure de l'évolution de l'application.
6.7.2 TestDirector:
 Les analystes métier définissent les besoins au niveau des applications ainsi que les
objectifs des tests
 Les responsables des tests et les chefs de projet conçoivent des plans de test et développent
des cas de test
 Les ingénieurs en automatisation des tests créent des scripts automatisés et les stockent
dans le référentiel
 Les testeurs d'assurance qualité exécutent des tests manuels et automatisés, indiquent les
résultats d'exécution et saisissent les anomalies
 Les développeurs révisent et réparent les anomalies enregistrées dans la base de données
 Les chefs de projet créent des rapports sur l'état de l'application et gèrent l'affectation des
ressources
 Les responsables produits décident quand une application est prête à être déployée
fonctionnelle
SOPRA Group
7 LES ESTIMATION EN CHARGE
Formaliser l’estimation
 Procédures et moyens à mettre en place.
 Guide d’estimation des charges et des délais.
 L’estimation initiale, interaction entre estimation et organisation du développement, l’analyse du risque.
 Historiser l’estimation
 La mise en place des métriques sur les produits et les processus, des mesures de productivité.
 Le référentiel, base de données des projets, et les procédures de collecte des données associées pour autoriser le
benchmarking.
 Calibrer l’estimation
 Le suivi des activités et l’affinage des estimations.

La classification des projets et la mise en place de barèmes et ratios de référence.
Règle de 1/9

Z Recette Fonctionnelle

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Z Recette Fonctionnelle

Transféré par

Droits d'auteur :

Formats disponibles

Organiser une Formation Recette fonctionnelle

recette Formation Recette fonctionnelle: 08 au 09 Février 2005

TABLE DES MATIERES

1 QU’EST- CE QU’UNE RECETTE FONCTIONNELLE....................................................5

1 QU’EST- CE QU’UNE RECETTE FONCTIONNELLE

1.3 Identification des acteurs d’une recette

Nous pouvons identifier les acteurs suivants dans un processus de recette:

1.4 LES ENJEUX DE LA RECETTE FONCTIONNELLE

L’entrepreneur réalise donc après moult négociations votre maison.

Début des anomalies - ANO –

Spécification des ano et demande de correction

Analogie avec la recette fonctionnelle d’un SI

La recette d'un SI passe par une même logique :

On essaye la maison pour savoir si tout est comme il se doit

Mais cette méthode est longue.

Par conséquent, il va falloir anticiper et prévoir l’essayage avant même la livraison/

1.4.1 Planification et rationalisation de la recette fonctionnelle

1.4.1.1 Quand commencer la recette fonctionnelle ?

L’organisation de la recette fonctionnelle doit commencer longtemps avant la livraison du produit.

1.5 LE PLAN DE RECETTE

1.5.1 Objectifs et enjeux du plan de recette.

Une bonne recette repose sur un « plan de recette »

Le plan de recette liste :

 toutes les fonctionnalités à tester,

1.5.2 Exercice d’application

Imaginons à présent un scénario simple :

Les acteurs du scénario : Vous

Les actions du scénario :

 Vous êtes dans votre chambre

 Vous tournez la poigné de la porte

Les résultats du scénario :

Le Nom de la scène : Vérification du fonctionnement de la porte de ma chambre

Les actions du scénario :

 Vous êtes dans votre chambre

 La porte ne s'ouvre pas

1.5.3 LA QUALITE DE LA RECETTE

La qualité de la recette dépend de la quantité réaliste des scénarii mis en place.

1.5.3.1 LES FAMILLES DE SCENARII

Les familles de scénarios pourraient donc être dans notre exemple :

Les classes d’erreur

De plus, cela va permettre d'alerter le réalisateur sur l'importance de certains points.

1.5.3.2 Différence entre gravité de scénario et gravité des erreurs

I ne faut pas confondre, gravité du scénario et gravité des erreurs.

Objectif du scénario : Installation de votre four dans votre cuisine

1.5.4 La recette est un projet dans un projet

La recette est un projet à part entière, un projet dans le projet.

Mais cette vision aboutit à deux conséquences qui ne la favorisent pas.

Elle doit donc se préparer dès la mise en place de votre projet.

1.6 Conséquences de la recette

Tout d'abord le langage employé dans la recette de SI ne vous aide pas :

2.1 Définition de TEST

Il n’y a pas de définition unique de test.

Ils font notamment appel aux règles suivantes :

Il existe un plan de test par niveau de test.

3.1 Contenu d'un plan de test (1)

 Définition des cas de test

3.2 Contenu d'un plan de test (2)

 Équipes concernées et responsabilités

3.3 Contenu d'un plan de test (3)

 Tests de non régression

les tests de réception sont de la responsabilité de l'équipe projet DSI : le MOA.

3.4 Différents types de Test

3.4.1 Tests unitaires