Définition des besoins pour le logiciel

Définition des besoins pour le logiciel REMERCIEMENTS Un grand merci à mon confrère et ami Alain COULON, secrétaire d...

Author: Yves Constantinidis

66 downloads 1685 Views 867KB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Définition des besoins pour le logiciel

REMERCIEMENTS Un grand merci à mon confrère et ami Alain COULON, secrétaire d’ADELI, qui m’a fourni des éléments pour la rédaction du guide du cahier des charges, ainsi qu’une définition « alternative » du mot besoin ; merci à tous mes clients, maîtres d’œuvre, maîtres d’ouvrage et utilisateurs, qui m’ont donné l’occasion de travailler avec eux sur leurs besoins ; merci à Nicolas MANSON, directeur de collection, pour ses précieux conseils et ses encouragements ; merci à Nicolas, Mélina et Karin pour leur soutien moral.

© LAVOISIER, 2006 LAVOISIER 11, rue Lavoisier 75008 Paris www.hermes-science.com www.lavoisier.fr ISBN 2-7462-1237-4 Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une part, que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du Code de la propriété intellectuelle. Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins d’identification et sont des marques de leurs détenteurs respectifs.


Yves Constantinidis

COLLECTIONS SOUS LA DIRECTION DE NICOLAS MANSON

Collection Management et Informatique Collection Etudes et Logiciels Informatiques Collection Nouvelles Technologies Informatiques Collection Synthèses Informatiques CNAM

La liste des titres de chaque collection se trouve en fin d’ouvrage.

TABLE DES MATIÈRES

Chapitre 1. Le besoin et l’exigence . . . . . . . . . . . . . . . . . . . . . . . 1.1. La relation client-fournisseur . . . . . . . . . 1.2. Besoin, demande, exigence, spécification . 1.2.1. Le besoin . . . . . . . . . . . . . . . . . . 1.2.2. La demande . . . . . . . . . . . . . . . . 1.2.3. L’exigence . . . . . . . . . . . . . . . . . 1.2.4. La spécification . . . . . . . . . . . . . . 1.3. Le cycle de vie du logiciel. . . . . . . . . . . 1.4. A qui s’adresse ce livre ? . . . . . . . . . . . 1.5. Guide de lecture . . . . . . . . . . . . . . . . .

. . . . . . . . .

13 14 14 15 15 16 17 19 20

Chapitre 2. Qu’est-ce qu’un « bon » logiciel ? . . . . . . . . . . . . . . .

23

2.1. Les attributs fondamentaux du logiciel . . 2.2. Trois niveaux de vision de la qualité . . . 2.3. Les caractéristiques de la qualité. . . . . . 2.4. La fiabilité. . . . . . . . . . . . . . . . . . . . 2.5. La maintenabilité . . . . . . . . . . . . . . . 2.6. La portabilité et la facilité d’installation . 2.7. La transparence . . . . . . . . . . . . . . . . 2.8. L’esthétique. . . . . . . . . . . . . . . . . . . 2.9. La variabilité . . . . . . . . . . . . . . . . . . 2.9.1. Importance de la variabilité. . . . . . 2.9.2. Les axes de réflexion. . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

13

. . . . . . . . . . .

. . . . . . . . . . .

23 24 25 26 28 29 31 32 33 33 35

6


Chapitre 3. La maîtrise de l’ouvrage . . . . . . . . . . . . . . . . . . . . . 3.1. Projet, œuvre et ouvrage . . . . . . . . . . . . . . 3.2. Les trois activités sous la responsabilité de la maîtrise d’ouvrage . . . . . . . . . . . . . . . . . 3.3. Le cahier des charges . . . . . . . . . . . . . . . . 3.3.1. Formulation, négociation, reformulation 3.4. La validation . . . . . . . . . . . . . . . . . . . . . 3.5. Le suivi du projet . . . . . . . . . . . . . . . . . .

39

............

39

. . . . .

. . . . .

41 43 45 46 47

Chapitre 4. La définition des objectifs. . . . . . . . . . . . . . . . . . . . .

49

. . . . .

4.1. Au préalable : une décision de changement. . . . 4.2. Le contenu de la phase d’objectifs. . . . . . . . . . 4.3. Les activités de la phase d’objectifs. . . . . . . . . 4.3.1. Définir l’importance du produit et du projet 4.3.2. Définir et clarifier les enjeux . . . . . . . . . . 4.3.3. Tracer la vision du produit . . . . . . . . . . . 4.3.4. Définir le périmètre actuel et futur . . . . . . 4.3.5. Définir le contexte . . . . . . . . . . . . . . . . 4.3.6. Evaluer la complexité du projet . . . . . . . . 4.3.7. Le diagramme de contexte . . . . . . . . . . . 4.4. L’analyse de l’existant . . . . . . . . . . . . . . . . . 4.5. L’analyse des parties prenantes (les acteurs) . . . 4.5.1. Qui sont les acteurs ?. . . . . . . . . . . . . . . 4.5.2. Les moteurs et les freins au changement . . 4.5.3. Techniques d’analyse des parties prenantes 4.6. L’étude comparative . . . . . . . . . . . . . . . . . . 4.7. La déclaration d’objectifs . . . . . . . . . . . . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

65

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

Chapitre 5. Recueil et analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

49 50 51 51 52 52 53 53 53 54 55 56 57 58 59 60 61

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . .

5.1. Activités de l’ingénierie des besoins 5.2. Les grandes étapes . . . . . . . . . . . 5.2.1. Recueil des besoins. . . . . . . . 5.2.2. Analyse des besoins . . . . . . . 5.2.3. Spécification des exigences. . . 5.2.4. Validation. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

65 66 66 66 67 68

Table des matières

5.2.5. Négociation. . . . . . . . . . . . . . . . . . . . . . . . 5.2.6. Gestion des évolutions. . . . . . . . . . . . . . . . . 5.2.7. Un processus cyclique . . . . . . . . . . . . . . . . . 5.3. De la difficulté d’exprimer les besoins . . . . . . . . . . 5.4. L’intervention de recueil des besoins . . . . . . . . . . . 5.5. Typologie des exigences . . . . . . . . . . . . . . . . . . . 5.5.1. Pourquoi classer les exigences par catégories ? . 5.5.2. Les catégories d’exigences . . . . . . . . . . . . . . 5.6. Les diverses techniques de recueil et d’analyse . . . . 5.6.1. Le questionnaire. . . . . . . . . . . . . . . . . . . . . 5.6.2. L’interview . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3. Les groupes de travail . . . . . . . . . . . . . . . . . 5.6.4. L’observation sur le terrain . . . . . . . . . . . . . . 5.6.5. L’analyse de la concurrence . . . . . . . . . . . . . 5.6.6. Le remue-méninges (brainstorming) . . . . . . . . 5.6.7. Les diagrammes d’affinités . . . . . . . . . . . . . . 5.6.8. Le modèle de Kano . . . . . . . . . . . . . . . . . . . 5.6.9. Les matrices de priorité . . . . . . . . . . . . . . . . 5.6.10. Les cas d’utilisation et les scénarios . . . . . . . 5.6.11. La modélisation des données, des traitements et des processus . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.12. Maquettes et prototypes . . . . . . . . . . . . . . . 5.6.13. Mixage des techniques, précautions à prendre .

. . . . . . . . . . . . . . . . . . .

69 69 70 71 74 75 75 75 77 77 79 81 82 83 83 84 86 87 88

....... ....... .......

89 90 90

Chapitre 6. Sept critères d’ergonomie. . . . . . . . . . . . . . . . . . . . .

93

6.1. Qu’est-ce que l’ergonomie ? . . . . . . . . . 6.2. Ergonomie : la qualité vue de l’utilisateur . 6.3. Les sept règles d’ergonomie . . . . . . . . . 6.3.1. Compatibilité. . . . . . . . . . . . . . . . 6.3.2. Guidage . . . . . . . . . . . . . . . . . . . 6.3.3. Homogénéité . . . . . . . . . . . . . . . . 6.3.4. Souplesse . . . . . . . . . . . . . . . . . . 6.3.5. Contrôle explicite . . . . . . . . . . . . . 6.3.6. Gestion des erreurs . . . . . . . . . . . . 6.3.7. Concision . . . . . . . . . . . . . . . . . . 6.4. L’application des principes d’ergonomie à la construction du logiciel. . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

7

. . . . . . . . . .

. 93 . 94 . 95 . 96 . 96 . 97 . 99 . 100 . 100 . 101

. . . . . . . . . . . . . . 102

8


Chapitre 7. Le cahier des charges : élaboration . . . . . . . . . . . . . . 105 7.1. L’utilité du cahier des charges . . . . . . . . . . . . . . . . . . 7.2. Producteurs et consommateurs des exigences . . . . . . . . 7.3. Centrer le projet autour du cahier des charges . . . . . . . . 7.4. Présentation de la démarche . . . . . . . . . . . . . . . . . . . 7.5. Lancer le projet d’élaboration du cahier des charges . . . . 7.5.1. Constituer l’équipe de préparation du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2. Prévoir, suivre et contrôler l’étude . . . . . . . . . . . . 7.5.3. Choisir les moyens . . . . . . . . . . . . . . . . . . . . . . 7.6. Spécifier l’objectif. . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1. Définir les finalités de l’application . . . . . . . . . . . 7.6.2. Déterminer les limites et les interfaces de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.3. Indiquer les contraintes . . . . . . . . . . . . . . . . . . . 7.6.4. Déterminer les domaines fonctionnels . . . . . . . . . . 7.7. Analyser l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.1. Recueillir les informations . . . . . . . . . . . . . . . . . 7.7.2. Analyser et quantifier les informations . . . . . . . . . 7.7.3. Modéliser le système actuel . . . . . . . . . . . . . . . . 7.8. Proposer des améliorations . . . . . . . . . . . . . . . . . . . . 7.8.1. Remédier aux dysfonctionnements . . . . . . . . . . . . 7.8.2. Fixer les objectifs d’évolution . . . . . . . . . . . . . . . 7.8.3. En déduire les caractéristiques du système cible . . . 7.9. Réviser l’organisation . . . . . . . . . . . . . . . . . . . . . . . 7.9.1. Identifier les conditions du changement . . . . . . . . . 7.9.2. Choisir les conditions de réalisation . . . . . . . . . . . 7.9.3. Construire le scénario . . . . . . . . . . . . . . . . . . . . 7.9.3.1. Découper en groupes de fonctions . . . . . . . . . 7.9.3.2. Intégrer les caractéristiques de chaque fonction. 7.9.3.3. Intégrer les caractéristiques non fonctionnelles . 7.9.3.4. Faire le bilan prévisionnel . . . . . . . . . . . . . . 7.9.3.5. Choisir le meilleur scénario . . . . . . . . . . . . . 7.9.4. Structurer et rédiger le cahier des charges. . . . . . . . 7.9.5. Valider le cahier des charges . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

105 106 107 108 109

. . . . .

. . . . .

. . . . .

. . . . .

109 110 110 110 110

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

111 111 112 112 112 113 114 114 114 114 115 115 116 116 116 116 117 117 117 118 118 119

Table des matières

7.10. Les défauts fréquents sur un cahier des charges 7.10.1. La description technique. . . . . . . . . . . . 7.10.2. Les contradictions . . . . . . . . . . . . . . . . 7.10.3. Les ambiguïtés . . . . . . . . . . . . . . . . . . 7.10.4. Le bruit . . . . . . . . . . . . . . . . . . . . . . 7.10.5. Le silence . . . . . . . . . . . . . . . . . . . . . 7.10.6. La sur-spécification . . . . . . . . . . . . . . . 7.10.7. Les références en avant . . . . . . . . . . . . 7.10.8. Le vœu pieux . . . . . . . . . . . . . . . . . . . 7.11. Conseils pratiques et précautions à prendre . . . 7.11.1. Prise en compte de l’état de l’art. . . . . . . 7.11.2. Doit-on tenir compte des technologies ? . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

9

119 120 120 120 121 121 121 121 122 122 122 123

Chapitre 8. Le cahier des charges : guide de rédaction . . . . . . . . . 125 8.1. Présentation de ce chapitre . . . . . . . . . . . . . . . . . . 8.2. La norme X50-151 . . . . . . . . . . . . . . . . . . . . . . . 8.3. Autres modes de présentation du cahier des charges . . 8.4. Guide de rédaction du cahier des charges . . . . . . . . . 8.4.1. Introduction : présentation du cahier des charges . 8.4.2. Première partie : contexte et objectifs . . . . . . . . 8.4.3. Deuxième partie : analyse de l’existant et axes d’évolution . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4. Troisième partie : expression des exigences . . . . 8.4.4.1. Exigences fonctionnelles du système . . . . . 8.4.4.2. Exigences non fonctionnelles . . . . . . . . . . 8.4.5. Quatrième partie : contraintes . . . . . . . . . . . . . 8.4.5.1. Services d’accompagnement. . . . . . . . . . . 8.4.5.2. Environnement technique de la solution . . . 8.4.5.3. Environnement humain et organisationnel . . 8.4.6. Cinquième partie : projet de réalisation, facteurs de risque, incertitudes . . . . . . . . . . . . . . . . . 8.4.6.1. Projet de réalisation . . . . . . . . . . . . . . . . 8.4.6.2. Facteurs de risque, incertitudes, complexités 8.4.7. Sixième partie : critères d’appréciation . . . . . . . 8.4.7.1. Conditions de recette . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

125 126 127 127 129 130

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

131 133 133 134 135 135 135 136

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

136 136 137 138 138

10


8.4.7.2. Flexibilité des niveaux 8.4.7.3. Appel à des variantes . 8.4.7.4. Cadre de réponse . . . . 8.4.8. Septième partie : annexes . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

138 139 139 139

Chapitre 9. Validation et diagnostics . . . . . . . . . . . . . . . . . . . . . 141 9.1. Validation des exigences. . . . . . . . . . . . . . . . . . 9.1.1. Une opération cyclique et continue . . . . . . . . 9.1.2. Les critères de passage. . . . . . . . . . . . . . . . 9.1.3. Valider à tous les niveaux. . . . . . . . . . . . . . 9.2. Les différentes méthodes de validation. . . . . . . . . 9.2.1. Les inspections et revues . . . . . . . . . . . . . . 9.2.2. La création des scénarios et cas de tests . . . . . 9.2.3. Les autres méthodes de validation . . . . . . . . 9.3. Audits et diagnostics de logiciel . . . . . . . . . . . . . 9.3.1. Pourquoi un diagnostic ? . . . . . . . . . . . . . . 9.3.2. Le déroulement d’un diagnostic d’application . 9.4. Mesure de l’utilisabilité : le questionnaire SUMI . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

141 141 142 143 143 143 145 146 147 147 149 150

Chapitre 10. La gestion et le suivi des exigences . . . . . . . . . . . . . . 153 10.1. Pourquoi les exigences doivent être gérées ? . . . . . . 10.1.1. Une activité nécessaire . . . . . . . . . . . . . . . . . 10.1.2. Risques induits par des changements incontrôlés 10.1.3. La nécessité de gérer . . . . . . . . . . . . . . . . . . 10.1.4. Organisation . . . . . . . . . . . . . . . . . . . . . . . 10.2. Comment les exigences doivent être gérées . . . . . . . 10.2.1. Le processus . . . . . . . . . . . . . . . . . . . . . . . 10.2.2. La commission de contrôle des changements. . . 10.2.3. L’analyse d’impact . . . . . . . . . . . . . . . . . . . 10.3. Les activités de gestion des exigences . . . . . . . . . . 10.3.1. La gestion des attributs des exigences . . . . . . . 10.3.2. L’évolution des demandes de changement . . . . 10.4. De la rentabilité des opérations de gestion . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

153 153 154 154 155 156 156 157 158 158 158 160 161

Table des matières

11

Chapitre 11. Quelques conseils techniques. . . . . . . . . . . . . . . . . . 163 11.1. Considérer la définition des exigences comme un vrai projet. . . . . . . . . . . . . . . . . . . . . 11.2. Gérer par les objectifs. . . . . . . . . . . . . . . . . 11.3. Choisir le bon modèle de cahier des charges . . 11.4. Utiliser les outils avec discernement . . . . . . . 11.5. Utiliser de multiples techniques et formalismes 11.6. Maquetter et prototyper juste ce qu’il faut . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

163 164 165 166 167 168

Chapitre 12. Aspects managériaux et facteurs humains . . . . . . . . . 169 12.1. Savoir quels sont les acteurs. . . . . . . . . . . . . . . . . . 12.2. Ne pas croire que le client a toujours raison . . . . . . . . 12.3. Gérer les priorités dynamiquement et chercher le consensus . . . . . . . . . . . . . . . . . . . . . . . . 12.4. Connaître le coût et la valeur de chaque exigence . . . . 12.5. Gérer la qualité, par la qualité et avec la qualité du produit 12.6. Alterner rigueur et imagination . . . . . . . . . . . . . . . . 12.7. Choisir un représentant des utilisateurs dynamique et volontaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8. Garder en permanence le contact avec les utilisateurs . 12.9. Informer et faire participer toutes les parties prenantes . 12.10. Perdre du temps pour en gagner . . . . . . . . . . . . . .

. . . . . 169 . . . . . 170 . . . .

. . . .

. . . .

. . . .

. . . .

172 173 174 174

. . . .

. . . .

. . . .

. . . .

. . . .

175 176 177 178

Chapitre 13. Trois études de cas. . . . . . . . . . . . . . . . . . . . . . . . . 181 13.1. Une histoire de communication. . . . . 13.2. Cas numéro 1 : le RAD perverti . . . . 13.3. Cas numéro 2 : la lourdeur qui tue . . . 13.4. Cas numéro 3 : la simplicité gagnante

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

181 181 186 189

Chapitre 14. Un nouveau métier : le designer de logiciel . . . . . . . . 195 14.1. Rigueur et innovation . . . . . . . . . . . . . . . 14.2. La construction de la qualité . . . . . . . . . . 14.3. Le besoin d’un designer . . . . . . . . . . . . . 14.4. Un homme de terrain, une vision stratégique

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

195 196 198 200

12


14.4.1. Avoir une vision globale. . . . . . . . . . . 14.4.2. Naviguer dans la zone d’ombre . . . . . . 14.4.3. Viser l’efficacité, percevoir l’esthétique, travailler sur l’élégance . . . . . . . . . . . . . . . . 14.5. Quel avenir pour le designer ? . . . . . . . . . .

. . . . . . . . . . . 200 . . . . . . . . . . . 201 . . . . . . . . . . . 202 . . . . . . . . . . . 202

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Sites web utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

CHAPITRE 1

Le besoin et l’exigence

Avant de nous embarquer dans l’ingénierie des besoins proprement dite, il est important de définir les mots besoins et exigences dans un double contexte : d’une part, la relation entre client et fournisseur, et d’autre part, le cycle de vie du logiciel. 1.1. La relation client-fournisseur La relation client fournisseur est la relation fondamentale de la vie économique. Le client est celui qui a un besoin, qui fait une demande auprès d’un fournisseur ; lequel traduit cette demande en une solution (produit ou service) vendue au client1. En théorie, les choses sont simples : le client éprouve un besoin et s’adresse à un fournisseur. Le fournisseur traduit cette demande en spécifications, qu’il fait valider par le client, et réalise ensuite un service, ou fabrique un produit selon ces spécifications. 1. Cette définition n’exclut pas que le client et le fournisseur appartiennent à la même entreprise. Dans cet ouvrage le mot client (resp. fournisseur) pourra être considéré comme un synonyme de maître d’ouvrage (resp. maître d’œuvre).

14


Dans la réalité, bien sûr, les choses sont beaucoup plus complexes. Dans la majorité des cas, la demande reflète très mal le besoin ; elle en privilégie quelques aspects, à un instant donné, qui traduisent plus le problème du moment que de véritables nécessités à long terme. De plus, la demande est maladroitement formulée et le fournisseur perçoit un message brouillé d’où il extrait des spécifications inadaptées. Enfin, client et fournisseur ont rarement la même culture : leurs vocabulaires sont différents et ils ne portent pas attention aux mêmes éléments. A partir de ce message brouillé, le fournisseur réalise souvent une solution qui a peu de chances de satisfaire le véritable besoin de l’utilisateur. 1.2. Besoin, demande, exigence, spécification 1.2.1. Le besoin Derrière le mot besoin se cachent deux significations, parfois fort différentes. La première concerne les besoins affichés, généralement liés à l’entreprise : amélioration de l’efficacité de l’entreprise, gain de parts de marché, avantage concurrentiel durable, réduction des coûts, service à la clientèle. Mais sous ces besoins exprimés se cachent d’autres préoccupations, plus secrètes, en rapport avec les objectifs personnels : conserver son autorité, renforcer sa place dans l’entreprise, se débarrasser des gêneurs, renforcer son pouvoir, se mettre en valeur, se soustraire aux responsabilités, ou préparer son évolution de carrière hors de l’entreprise… qui se résument dans l’acronyme mnémonique besoin utilisé par les vendeurs : – bien-être : confort matériel, environnement de travail ; – estime : besoin de considération, reconnaissance des capacités ; – sécurité : craintes de prise de risques individuels ;


15

– orgueil : réussite d’un défi, promotion ; – intérêt : salaires, primes, avantages divers ; – nouveauté : curiosité vis-à-vis d’un nouveau produit, d’un projet innovant. Une des activités du consultant en ingénierie des besoins est de distinguer les besoins personnels des besoins de l’entreprise, de négocier les conflits entre les différents types de besoins, et de chercher à obtenir un équilibre entre eux. 1.2.2. La demande La demande est une description subjective et partielle de la perception d’un besoin, par une personne, à un instant donné. Très souvent, la demande dépasse largement le véritable besoin, du moins sur certains points. Sur d’autres points, ou exprimée par d’autres personnes, la demande passe sous silence des besoins essentiels. La solution pragmatique réside dans un compromis. Il appartient aux deux parties de définir ensemble une cible commune à michemin entre un besoin inaccessible et une demande trop partielle. Nous appellerons exigence l’expression formelle de cette cible. Dans l’intérêt des deux parties, il faut pouvoir facilement mesurer le degré de satisfaction d’une exigence. 1.2.3. L’exigence Une exigence est la formalisation d’une cible commune pour le client et le fournisseur. Par rapport à la demande, l’exigence tient compte des contraintes, et introduit une notion de consensus. L’exigence est une caractéristique demandée par le client et acceptée par le fournisseur.

16


L’exigence introduit une notion de mesure. Il faut que l’on puisse objectivement à la fin des travaux constater qu’une exigence a été satisfaite ou non. Ce qu’on appelle « la qualité » est avant tout la conformité aux exigences. 1.2.4. La spécification Enfin, la spécification est la traduction des exigences dans un langage convenu entre le client et le fournisseur. Elle permet d’éviter les effets pervers qui irritent leurs relations, y compris dans le cas où les deux parties, client et fournisseur, sont de bonne foi. L’activité de spécifier est une démarche industrielle. Besoins

Demande les exigences

le besoin non exprimé

le rêve

Spécifications le réaliste

le faisable

La tentation du technicien Contraintes Figure 1.1. Des besoins à la solution : le développement des exigences

La démarche d’ensemble, qui consiste à passer des besoins aux exigences spécifiées par un certain nombre d’étapes contrôlées, s’appelle développement des exigences. Ce qui rend l’exercice extrêmement difficile est la nécessité de tenir compte en permanence des écarts entre le besoin (exprimé ou non), la demande (qui peut correspondre à un besoin ou non, être


17

faisable ou non) et les contraintes, en découvrant le besoin non exprimé, et en filtrant la demande irréaliste (le rêve) et en résistant à la tentation du technicien (réaliser ce qui ne correspond pas à un besoin). 1.3. Le cycle de vie du logiciel Le cycle de vie du logiciel peut être représenté de plusieurs manières. Le schéma de la figure 1.2 en donne une représentation en huit phases. En effet, contrairement au « cycle de développement », qui correspond à un projet, et comporte donc un début et une fin, la vie du logiciel est véritablement cyclique : dans la majorité des cas, la dernière phase d’un cycle s’enchaîne avec la première étape du cycle suivant. Cette représentation permet de mettre en avant une idée importante dans le cadre de cet ouvrage : la technologie du logiciel est une technologie de l’évolution.

Retrait

Objectifs et concepts

Exigences

Exploitation et maintenance

Installation et déploiement

Conception

Tests et qualification

Réalisation

Figure 1.2. Le cycle de vie du logiciel

18


Décrivons très brièvement ces huit phases : – objectifs et concepts : c’est lors de cette première phase que sont définis les objectifs du produit à construire, et qu’une première vision du logiciel est apportée ; cette phase est cruciale, car elle conditionne toutes les autres ; – exigences : les besoins sont recueillis, analysés et formalisés lors de cette phase ; il en résulte un document appelé spécification des exigences ou cahier des charges fonctionnel ; – conception : le logiciel est spécifié et modélisé, en fonction des objectifs et des exigences précédemment définis ; – réalisation : cette phase correspond à la programmation et aux tests unitaires ; – tests et qualification : le logiciel est testé dans son ensemble ; – installation : mise en œuvre opérationnelle et déploiement ; – exploitation et maintenance : mise à disposition du logiciel auprès des utilisateurs ; – retrait : cette phase, souvent passée sous silence, correspond à l’arrêt de l’exploitation et de l’utilisation du logiciel ; elle peut coïncider avec la mise en exploitation d’un nouveau logiciel ou d’une nouvelle version du logiciel. Ce découpage en huit phases est un modèle. Suivant les méthodologies mises en œuvre, ces phases peuvent se chevaucher. Dans la réalité, ces phases se chevauchent toujours plus ou moins, même avec les méthodes où les phases sont censées se succéder de manière cloisonnée. Par exemple, de nouvelles exigences peuvent surgir à tout moment, en cours de conception, de réalisation, et pendant l’exploitation du logiciel, et les objectifs être redéfinis en cours de projet.


19

Néanmoins, même avec les méthodes de développement souples où le chevauchement entre phases est explicitement prévu, le passage d’une phase à la suivante constituent autant de « passages de frontière », avec les « contrôles frontaliers » qui s’imposent (revues, inspections et contrôles). Par exemple, si une nouvelle exigence apparaît au cours de la réalisation, elle devra être analysée et validée, et les documents correspondants mis à jour préalablement au passage en conception et en réalisation. 1.4. A qui s’adresse ce livre ? Cet ouvrage s’adresse avant tout aux clients de l’informatique en contact avec les fournisseurs informaticiens, et à ceux qui les conseillent ou les représentent : maîtres d’ouvrage, assistants à la maîtrise d’ouvrage et, chez les éditeurs de logiciel, responsables marketing et chefs de produit. Il se concentre essentiellement, mais non exclusivement, sur la phase de cycle de vie appelée exigences. Il présente le processus de définition des exigences et quelques techniques, classiques ou innovantes, de mise en œuvre de ce processus. Ce livre s’adresse également aux fournisseurs de produits logiciels et de services, en particulier ceux qui « font » le logiciel, tout en étant directement en contact avec le maître d’ouvrage : les architectes, directeurs et chefs de projet, et dans une certaine mesure les responsables de la validation, de la mise en exploitation et du support du produit, car cet ouvrage traite en particulier du dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre, de la contractualisation de ce dialogue et des techniques de communication à même de le faciliter.

20


1.5. Guide de lecture Cet ouvrage a été écrit pour que chaque chapitre soit, dans la mesure du possible, autonome, et qu’il puisse être lu indépendamment des autres. Il gagne cependant à être lu dans l’ordre des chapitres : – le chapitre 2 parle essentiellement de qualité du produit qui se traduit par ce qu’il est convenu d’appeler les exigences non fonctionnelles ; – le chapitre 3 aborde la conduite d’un projet de développement avec la perspective du maître d’ouvrage. Il intéressera les directeurs et chefs de projet ; – le chapitre 4 insiste sur l’importance de la phase des objectifs, qui précède la phase de développement des exigences proprement dite ; – le chapitre 5 détaille les étapes de recueil et d’analyse des exigences, et décrit quelques techniques utiles ; – le chapitre 6 se concentre sur les exigences d’ergonomie, une catégorie d’exigences non fonctionnelles particulièrement importante et souvent négligée ; – le chapitres 7 et 8 traitent de l’étape de spécification des exigences : processus d’élaboration d’un cahier des charges, et guide pratique pour sa rédaction ; – le chapitre 9 aborde rapidement les aspects de validation des exigences et les moyens de contrôler la qualité du produit et sa conformité aux besoins ; – le chapitre 10 aborde le suivi des exigences, leur gestion ; – on donne au chapitre 11 quelques recommandations techniques, suivies, au chapitre 12, par des conseils plus centrés sur les facteurs humains ; – le chapitre 13 raconte trois histoires vécues ; le but est de montrer comment la manière de traiter les besoins des utilisateurs,


21

et le dialogue entre fournisseur et client, peuvent avoir des conséquences importantes sur le produit logiciel ; – enfin, le chapitre 14 fait un peu de prospective ; ne faudrait-il pas inventer un nouveau métier, celui de designer logiciel, analogue au designer industriel, qui ferait le lien entre exigences, architecture, ergonomie et qualité du produit logiciel ?

CHAPITRE 2

Qu’est-ce qu’un « bon » logiciel ?

2.1. Les attributs fondamentaux du logiciel Les utilisateurs ont tendance à décrire un logiciel (existant ou à venir) par leurs seules fonctions. Les informaticiens ont tendance à le décrire par ses seules caractéristiques techniques. Quant aux qualiticiens, ils attachent de l’importance à sa fiabilité et au processus de son développement. Rien n’est plus difficile, en effet, que de définir ce qu’est un « bon » logiciel. Immatériel, le logiciel échappe aux descriptions et aux catégories habituellement utilisées pour les objets physiques. Dans les paragraphes qui suivent, nous allons néanmoins, modestement, tenter de décrire ses attributs fondamentaux. Dans le jargon de l’ingénierie des exigences, ces attributs sont désignés sous le vocable d’exigences de qualité ou exigences non fonctionnelles1.

1. Pour une description détaillée des attributs de qualité, on pourra consulter l’ouvrage du même auteur intitulé Le logiciel à valeur ajoutée (Hermès).

24


2.2. Trois niveaux de vision de la qualité La norme ISO 9126, relative à la qualité du produit logiciel, conçue à l’origine pour évaluer la qualité du logiciel, peut être utilisée pour construire la qualité2. Selon cette norme, la qualité du logiciel peut être perçue sur trois niveaux : – la qualité interne (internal quality) correspond au niveau structurel d’analyse, et peut être évaluée par examen du code source, de l’architecture, des spécifications ; – la qualité externe (external quality) correspond au niveau comportemental, visible et mesurable, en particulier lors de tests ; – la qualité de fonctionnement (quality in use) correspond au point de vue de l’utilisateur. Elle se décompose en quatre caractéristiques : l’efficacité (relative à l’atteinte des objectifs de l’utilisateur), la productivité (économie de temps, d’efforts) la sécurité (risques sur l’utilisateur, le logiciel, l’environnement), et la satisfaction de l’utilisateur. Ces trois niveaux de qualité du produit sont empilés et interdépendants : la qualité de fonctionnement dépend de la qualité externe, qui dépend de la qualité interne, qui elle-même dépend de la qualité du processus. Mesures du processus

Mesures internes

Mesures externes

Mesures du fonctionnement Contextes d'utilisation

dépend de Qualité du processus

influence

Attributs de la qualité interne

dépend de influence

Attributs de la qualité externe

dépend de influence

Attributs de la qualité de fonctionnement

Source : ISO/CEI 9126:2001

Figure 2.1. Le cycle de vie du logiciel

2. La norme ISO 25000 qui lui succède tient compte de cette évolution. Elle se surnomme SQuaRE (Software Quality Requierements and Evaluation).


25

A chaque niveau, la qualité est traditionnellement perçue et manipulée par des acteurs dont les métiers sont très différents. La qualité interne est l’affaire de l’architecte, du concepteur, du développeur. La qualité externe est visible du chef de projet et des équipes de validation. La qualité de fonctionnement est définie et mesurée par le maître d’ouvrage, le marketing, le consultant métier, l’ergonome, le responsable sécurité. Quant à la qualité du processus, elle est depuis longtemps sous la responsabilité des qualiticiens. Les dépendances entre niveaux de perception de la qualité ne sont pas exclusives. C’est d’ailleurs pour cela que des mesures doivent être effectuées à la fois sur le processus, le produit (final et en cours de développement) et la satisfaction de l’utilisateur. Imaginer qu’un bon processus aboutira nécessairement à un bon produit conduit à des effets pervers que l’on commence à bien connaître : « notre processus est certifié, donc nos produits sont bons ». Erreur grossière, car d’une part, un processus peut être excellent sans jamais avoir été certifié (voire formalisé), et d’autre part aucun processus n’est parfait, qu’il soit certifié ou non. Le développement du logiciel (au sens large du terme, incluant les phases d’architecture et de conception) est une activité créative, par essence non entièrement formalisable. 2.3. Les caractéristiques de la qualité Ces six caractéristiques, bien qu’indépendantes, s’influencent mutuellement et peuvent se trouver antagonistes. Ainsi, la portabilité et la maintenabilité peuvent avoir une influence négative sur le rendement, la fiabilité peut influencer la facilité d’utilisation, etc. Un logiciel sera de qualité s’il satisfait les exigences du client eu égard à ces six caractéristiques. Cependant, chercher à maximiser toutes les caractéristiques à la fois se révèle en général irréaliste

26


en termes de coût ou de délais. La qualité du logiciel ne vient pas de la perfection, mais de l’équilibre entre ses différents attributs. La priorité à donner à chaque caractéristique lors de l’achat ou de la conception d’un logiciel dépend bien entendu de nombreux paramètres : type d’application, client, contexte d’utilisation, profil et culture des utilisateurs, contraintes techniques. 2.4. La fiabilité Le mot fiable vient du latin fidare, confier, de fidus, fidèle, ce mot dérivant de fides, la foi. Un produit informatique fiable est donc un produit auquel on peut avoir confiance, auquel on peut confier certaines tâches ou opérations, et qui restera fidèlement à notre service. Vue sous cet angle, la fiabilité devient presque synonyme de l’existence, en tout cas pour le logiciel. Que peuton demander de moins à un outil qui est sensé automatiser des tâches pénibles ou répétitives, éviter les erreurs humaines, et exécuter rapidement une série d’opérations complexes ? Paradoxalement, lorsque l’on interroge un utilisateur, lors d’un audit ou d’un diagnostic, pour connaître les points forts et les points faibles d’un logiciel ou d’un système, on entend rarement parler de fiabilité. L’utilisateur se plaint volontiers des performances en temps (« le système est trop lent, certains ralentissements sont gênants »), de l’absence de certaines fonctions ou de la simplicité de leur mise en œuvre (« on devrait pouvoir faire telle ou telle manipulation, de telle ou telle manière »). Il est rare qu’un utilisateur se plaigne spontanément du manque de fiabilité. Mais en approfondissant l’interview, on s’aperçoit vite que la fiabilité est la première qualité exigée d’un logiciel, et sur laquelle l’utilisateur ne transigera pas.


27

Pourquoi l’utilisateur a-t-il tendance à occulter les problèmes de fiabilité ? Tout se passe comme si l’absence de fiabilité exacerbait les autres caractéristiques : s’il perd la confiance vis-à-vis du logiciel qu’il manipule, tout le reste va mal et chaque imperfection est perçue comme un obstacle insurmontable. D’autre part, l’industrie du logiciel nous a (trop) longtemps habitués à la non-qualité. Un ouvrage humoristique sur l’informatique intitulé Encore planté ! était à ce titre représentatif de la situation. La non-fiabilité fait partie, pour ainsi dire, de la tradition, et les logiciels fiables sont l’exception plutôt que la règle. C’est là une situation qu’il faudra un jour changer. Utilisateurs et informaticiens sont d’ailleurs d’accord sur le fait que la fiabilité du logiciel est la première raison de l’améliorer, et d’améliorer les processus de sa construction. La fiabilité a trois facettes : – la maturité, liée au faible nombre de défaillances ; – la tolérance aux fautes : capacité du logiciel à assurer ses autres fonctions suite à une défaillance ; – la possibilité de récupération : possibilité de récupérer tout ou partie des informations perdues suite à une défaillance. Prenons un exemple simple dans le domaine de l’informatique individuelle. L’utilisateur d’un logiciel de traitement de texte fait appel à la fonction « imprimer la page courante » d’un fichier en cours de traitement. C’est là une opération tout à fait banale, mais sur certains fichiers, le logiciel est défaillant. et refuse d’imprimer la page. Il s’agit d’un défaut de maturité. Si, à l’occasion de cette défaillance, le logiciel se bloque et que ses autres fonctions (saisie de texte, mise en forme) sont inutilisables, c’est aussi la tolérance aux fautes qui est en cause.

28


Si par la même occasion le fichier est abîmé, rendu inutilisable, c’est la possibilité de récupération qui est absente. La fiabilité est si importante et si souvent négligée, qu’elle doit être intégrée comme une exigence à chaque étape de la conception et de la réalisation du logiciel. Nous verrons dans le chapitre consacré au cahier des charges qu’il est nécessaire de la quantifier aussi précisément que possible. 2.5. La maintenabilité La maintenabilité, c’est-à-dire la capacité d’un logiciel à être maintenu et modifié facilement et dans de bonnes conditions, est une caractéristique du logiciel qui n’est a priori visible et contrôlable que par les gens du métier, les informaticiens. En réalité, le maître d’ouvrage et l’utilisateur ont leur mot à dire, et peuvent le faire à condition de maîtriser quelques concepts et d’être au courant de certaines pratiques. Un logiciel peut parfaitement donner satisfaction, posséder toutes les fonctions requises, être agréable et pratique à utiliser, être efficient, tout en étant très difficilement maintenable. C’est souvent le cas de certains logiciels anciens, tout à fait satisfaisants tant qu’aucune modification ne leur est demandée. Certaines fonctions sont enfouies dans des milliers de lignes de programme, et il n’est pas possible de les retoucher, même légèrement, sans remettre en cause la totalité de l’édifice. Sur un tel logiciel, une modification minime peut demander des jours de travail, alors qu’elle ne demanderait que quelques minutes sur un logiciel bien conçu, bien écrit, et bien documenté. C’est qu’il faut parfois analyser des milliers de lignes pour trouver la seule et unique ligne à modifier. Une même fonction peut être répartie à différents endroits du logiciel, et demander des interventions répétées pour modifier un détail en apparence minime. Dans d’autres cas, une


29

modification en un seul point du logiciel peut avoir des conséquences en un point différent ou même en plusieurs points, et fragiliser l’ensemble, rendant les modifications de plus en plus coûteuses et risquées. Enfin, une fois la modification opérée, il peut être nécessaire de faire passer des batteries de test extrêmement coûteuses pour tester le logiciel. Cet exemple permet de percevoir les différentes facettes de la maintenabilité : – la facilité d’analyse : il est facile, pour un informaticien, de comprendre sa structure et son fonctionnement interne ; – la facilité de modification : le logiciel peut être modifié avec un effort faible ; – la stabilité : une modification mineure ne met pas l’édifice en cause ; – la testabilité : suite à une modification, l’effort de test est réduit. Maintenir un logiciel est, certes, un travail de spécialiste, et le restera. Mais si celui qui commande, achète, ou utilise un logiciel est au courant des différents aspects de la maintenabilité et de ses conséquences, il pourra agir en connaissance de cause, mieux négocier avec le fournisseur, voire trouver des arguments pour se retourner contre lui. A moyen terme le manque de maintenabilité est toujours visible, à la fois de l’utilisateur et du maître d’ouvrage : la maintenance coûte de plus en plus cher, le produit est de moins en moins adaptable aux nouveaux besoins, et les demandes de modifications (corrections d’anomalies, ajouts) se font avec lenteur et à un coût anormalement élevé. 2.6. La portabilité et la facilité d’installation La portabilité est l’aptitude d’un logiciel à s’adapter d’un environnement technique à un autre. Cette capacité ne correspond pas toujours à un besoin. En général, on acquiert (ou on fait

30


développer) un logiciel pour un environnement particulier. Le besoin de portabilité doit cependant être sérieusement pris en compte dans toute étude préalable. Quels seront les besoins de l’entreprise ou de l’administration dans cinq ans ? La facilité d’installation (installabilité) est considérée comme un cas particulier de la portabilité. En effet, les environnements techniques évoluent d’une version à l’autre. Déployer un logiciel sur des plates-formes qui ne sont pas toutes exactement identiques, ou réinstaller un logiciel sur une version suivante du même système d’exploitation revient à le porter sur un environnement nouveau. Prenons le cas bien connu d’un logiciel de bureautique que l’on veut installer sur plusieurs versions successives d’un système d’exploitation d’ordinateur de bureau. On a bien à faire, dans ce cas, à un problème de portabilité. La « compatibilité ascendante » (c’est-à-dire l’aptitude de la version N + 1 d’un système d’exploitation à recevoir un logiciel prévu pour la version N) n’est jamais totalement garantie. Pensons également au cas de macrocommandes (les « macros ») d’un logiciel de bureautique qui fonctionnent sur une version du logiciel et refusent de s’exécuter sur la version suivante. Ce sont là des problèmes banals, quotidiens. Les environnements d’exploitation des applications évoluent plus fréquemment qu’on ne le pense. Par exemple, les applications de gestion fonctionnent souvent sur un navigateur web. Les navigateurs évoluent, les environnements sur lesquels ils s’exécutent évoluent également. Au final, le système d’information de l’entreprise ressemble à un millefeuille où des couches technologiques se superposent. Le logiciel doit s’adapter à cet environnement à la fois stratifié et mouvant. On touche ainsi à la notion de variabilité abordée plus loin.


31

2.7. La transparence Le terme transparent concerne habituellement les actions d’un logiciel vis-à-vis de l’utilisateur. Un système est transparent s’il cache les détails techniques. Par exemple, la technologie du serveur sur lequel s’exécute une application de gestion est souvent transparente pour l’utilisateur. Si elle change, il ne s’en apercevra pas. Le mot transparent peut être utilisé dans un sens tout à fait différent, celui de la clarté. Rien n’est caché à l’utilisateur. L’exemple le plus connu est le WYSIWYG (acronyme anglais de what you see is what you get : vous obtenez ce que vous voyez). Cela se traduit, sur un logiciel de dessin ou de traitement de texte, par un dessin ou un texte qui aura la même apparence sur l’écran et sur le papier. Mais cette clarté peut aller beaucoup plus loin. Elle consiste à donner à l’utilisateur, à tout moment, la carte des actions possibles, la représentation mentale des actions en cours et des actions déjà effectuées. Elle correspond à la notion de navigabilité d’un site web, mais ne se limite pas à ce type d’applications. Comme nous le verrons dans le chapitre sur l’ergonomie, cette sensation de contrôle est fondamentale. Elle apporte du confort à l’utilisateur, augmente la sécurité, et minimise le stress. Malheureusement, malgré les évolutions de la technologie, sa mise en pratique est moins fréquente qu’il n’y paraît. Remarquons que les deux acceptions du mot transparent se rejoignent. Il s’agit de cacher à l’utilisateur les aspects techniques du système (la technologie du serveur) tout en montrant au grand jour sa richesse fonctionnelle en la lui rendant accessible.

32


2.8. L’esthétique Qu’est-ce qu’un « beau » logiciel ? La notion de beau n’a rien de scientifique, ni a fortiori de technique, et s’en préoccuper pourrait paraître frivole à certains. C’est pourtant un attribut de la qualité. A tel point que la dernière version de la très sérieuse norme ISO 9126 sur la qualité du logiciel présente l’attractivité comme un attribut de l’utilisabilité, et donc de la qualité. Sous prétexte d’immatérialité, un produit logiciel a-t-il le droit d’être laid ? A-t-on le droit d’agresser l’utilisateur avec des produits mal faits, bâclés, incohérents ? Certes, les environnements d’exploitation actuels permettent de faire des applications en apparence beaucoup plus esthétiques qu’il y a trente ans. Mais ces possibilités techniques sont souvent peu exploitées, voire exploitées de manière perverse, apportant à l’utilisateur un environnement de travail confus et surchargé. De plus, l’esthétique d’un logiciel va beaucoup plus loin que l’interface graphique. Elle touche la navigation dans le logiciel, l’intelligence du dialogue, la pertinence de l’aide en ligne, la cohérence d’ensemble. « La laideur se vend mal » proclamait Raymond Loewy, un des fondateurs du design industriel. Cette affirmation est également vraie pour le logiciel : de plus en plus d’utilisateurs et d’acheteurs sont sensibles à l’esthétique. De plus, il y a fort à parier qu’un logiciel laid sera moins souvent et moins longtemps utilisé qu’un logiciel agréable et joli, avec des conséquences sur la productivité de l’utilisateur. Mais surtout, l’esthétique d’une application informatique, notion certes toute subjective et intuitive, est un des meilleurs indicateurs de qualité, immédiatement perceptible. Si un logiciel est laid, c’est qu’il a été mal pensé, et il y a fort à parier que l’efficacité, la maintenabilité, la fonctionnalité, et surtout la fiabilité ne soient pas au rendez-vous.


33

Certains éditeurs s’en sont d’ailleurs aperçu, et soignent particulièrement l’interface utilisateur (même si, comme nous l’avons écrit, l’esthétique de l’interface utilisateur n’est pas le seul critère). 2.9. La variabilité 2.9.1. Importance de la variabilité L’industrie du logiciel doit répondre à des exigences de plus en plus fortes : le logiciel doit être de meilleure qualité, coûter moins cher, et livré plus vite. Les méthodes traditionnelles de développement atteignent ici leurs limites. Mais ces dernières années une contrainte vient s’ajouter aux autres d’une façon de plus en plus pressante : le logiciel doit s’adapter en permanence à son environnement. La variabilité d’un logiciel ou d’un système est son aptitude à être modifié, personnalisé ou configuré en fonction de l’environnement ou du métier de l’utilisateur. Elle a deux dimensions : – une dimension temporelle : un logiciel déjà installé peut être reconfiguré, reparamétré pour un usage différent ; – une dimension spatiale : un même logiciel peut être paramétré, lors de son installation, pour s’adapter à un contexte, des besoins, ou une typologie d’utilisateur particuliers. On pense immédiatement aux progiciels de gestion intégrés, dont le paramétrage en vue de l’adaptation à une entreprise est un véritable projet informatique. Cependant, des exemples courants de variabilité nous sont donnés sur un nombre grandissant de logiciels d’utilisation personnelle qui dialoguent avec l’utilisateur lors de l’installation pour s’autoconfigurer selon ses besoins (variabilité spatiale) ou qui permettent de modifier l’interface utilisateur (le skin) pour s’adapter aux goûts

34


de l’utilisateur, ou pour changer de langue de dialogue (variabilité dans le temps). La variabilité, notion assez récemment formalisée, s’apparente à la maintenabilité et à la portabilité. Cependant, maintenabilité et portabilité sont des attributs internes au logiciel. La variabilité, caractéristique visible de tous, ne va pas sans poser quelques intéressants challenges aux informaticiens. Il est en effet beaucoup plus simple de construire un logiciel monolithique et rigide qu’un logiciel reconfigurable à volonté. Les plus importants challenges sont posés aux architectes, aux ergonomes et aux qualiticiens : – si le logiciel est reconfigurable à souhait, que doit-on spécifier ? – le cahier des charges doit-il porter sur un produit standard ou sur une configuration particulière ? – si l’on considère deux variantes d’un même logiciel, dans quelle mesure s’agit-il d’un même produit ? – si le logiciel est reconfigurable, qui est en charge de gérer le passage entre les diverses configurations ? – à la réception d’un logiciel, doit-on tester uniquement la configuration livrée ? – dans quelles limites peut-on laisser les utilisateurs (et quels utilisateurs ou super-utilisateurs) modifier ou paramétrer le logiciel ? – la configuration « à chaud » doit-elle être possible pendant que le logiciel fonctionne ? – en cas de défaillance du logiciel reconfiguré, qui porte la responsabilité commerciale, civile ou pénale des conséquences de cette défaillance ? Ces problèmes, qui commencent à être maîtrisés dans l’industrie manufacturière, n’en sont même pas à leurs balbutiements dans le monde du logiciel. Des réflexions sont menées sur ces problèmes, essentiellement dans le monde de la recherche. Dans


35

l’industrie du logiciel commercial, les produits sont « customisés » (adaptés au client), rendus paramétrables, configurables ou modifiables en fonction des demandes du marché, avec peu de recul et de réflexion stratégique. 2.9.2. Les axes de réflexion Les avancées des approches par objets et par composants ont mis en avant l’importance des notions de réutilisabilité et de modularité pour le logiciel. Il s’agit là de percées significatives, mais un long chemin reste à faire. Si l’on veut que le logiciel soit variable, il est nécessaire d’identifier le plus en amont possible le tronc commun et les parties « variables », et prévoir la réutilisabilité des composants dès la conception. Mais différencier, depuis le recueil des besoins jusqu’à la livraison du produit, le tronc commun d’un logiciel et ses parties variables, est une tâche ardue. La variabilité peut être obtenue à différents niveaux du développement du logiciel, par différents mécanismes : – au niveau de la définition des exigences, il est possible de définir des cas d’utilisation abstraits qui incluent des cas d’utilisation plus particuliers, ou de réutiliser un cas d’utilisation dans un contexte nouveau ; – au niveau de la conception, l’héritage, qui est la base de l’approche par objets, permet de spécialiser ou de généraliser les données et opérations attachées à des entités ; ainsi, tous les comptes en banque possèdent certaines propriétés communes, mais un compte chèque et un compte épargne, qui héritent de ces propriétés, possèdent des propriétés qui leur sont propres ; – au niveau de la réalisation, il est possible de prévoir de multiples configurations d’un même produit ; – au niveau de l’exploitation du produit, la variabilité est obtenue par paramétrage.

36


Configurabilité et paramétrabilité sont extensivement utilisées sur les progiciels de gestion intégrés, et l’approche par composants est de plus en plus pratiquée dans l’industrie du logiciel. Mais comment fait-on pour mettre en œuvre ces pratiques de manière systématique et sûre ? Les changements d’exigences que demande le marché sont difficiles à prévoir. Pour relever le défi de l’adaptabilité, cette variabilité doit être planifiée et industrialisée. Trois approches, par ailleurs complémentaires, commencent à voir le jour : – la première approche est l’approche par ligne de produit (product line practice) : elle consiste à identifier les briques de base, existantes ou à développer, puis à réaliser le produit par assemblage de ces briques de base ; – la seconde approche est la programmation générative (generative programming) : elle consiste à prévoir la variabilité du produit en identifiant le tronc commun et les branches variables du produit très en amont, au niveau des objectifs, et à analyser les besoins, non pas du système, mais de l’ensemble du domaine, pour en déduire les composants réutilisables ; – enfin, une troisième approche est la programmation par aspects (aspect oriented programming) : c’est un ensemble de méthodes et de techniques permettant de décomposer le problème, non seulement en « briques » fonctionnelles, mais aussi en composants transverses (les différents « aspects » ou « points de vue ») et de réaliser le produit par combinaison des composants et des aspects. Ces trois approches sont en réalité basées sur le même principe de développement par modèle (model driven development) : ce n’est plus le logiciel, mais le modèle, c’est-à-dire l’abstraction du logiciel, qui devient le véritable produit.


37

Quelles que soient les évolutions futures, une idée semble se dégager d’emblée, et elle découle en particulier de cette contrainte de variabilité : la qualité du produit ne peut plus être attribuée à la seule qualité de la programmation (qui reste évidemment fondamentale), ni même à la qualité de la conception. Elle doit être cherchée dans la manière dont les différentes exigences sont traitées, selon une combinatoire de points de vue. D’où l’importance de l’ingénierie des besoins, qui permet de tenir compte de ces points de vue bien avant la conception.

CHAPITRE 3

La maîtrise de l’ouvrage

3.1. Projet, œuvre et ouvrage Un projet est un ensemble d’activités dont on a défini l’objectif, les délais et les ressources. Un projet informatique de développement ou d’intégration répond, bien entendu, à cette définition, mais d’autres ensembles d’activités, par exemple le choix d’un logiciel ou l’amélioration des méthodes de développement peuvent, et devraient, être considérés comme des projets. Un projet est une œuvre (ensemble de travaux) destinée à produire (concevoir, réaliser, installer) un ouvrage conforme à ses spécifications. Œuvre Expression des besoins

Ouvrage

Figure 3.1. Œuvre et ouvrage

40


Le maître d’ouvrage est le propriétaire du produit du projet (l’ouvrage). Il est responsable de l’expression des besoins auxquels doit satisfaire l’ouvrage final. Le maître d’ouvrage agit au nom de l’ensemble des futurs utilisateurs de l’ouvrage. La maîtrise d’œuvre conduit les travaux (l’œuvre) en respectant les conditions de coûts et de délais. Elle doit livrer un résultat (ouvrage) de qualité, c’est-à-dire conforme aux besoins exprimés (tels que fonctions et performances spécifiées) mais également, comme nous le verrons plus loin en détail, conforme à des besoins implicites ou à des standards de droit ou de fait. La maîtrise d’œuvre est représentée par un chef de projet ou un directeur de projet.

Maîtrise d’ouvrage Pilotage - décision

Maîtrise d’œuvre Conduite

Utilisateurs Consultation

Equipe projet Réalisation Expertise Conseil aux différents acteurs

Figure 3.2. Responsabilités sur l’œuvre et l’ouvrage

Remarquons que la maîtrise d’œuvre comprend deux familles d’activités : – les activités de production de l’ouvrage, comme la programmation ou les tests ; – les activités de conduite, de direction et de management du projet.


41

3.2. Les trois activités sous la responsabilité de la maîtrise d’ouvrage Un projet informatique passe par un certain nombre de phases. Pour un projet de développement ou d’intégration, la manière dont ces phases sont enchaînées et organisées s’appelle modèle de développement ou modèle de cycle de vie du logiciel. Par exemple, dans le modèle dit « en cascade », les phases s’enchaînent linéairement l’une à l’autre, alors que dans le modèle dit « en spirale », l’enchaînement des phases est plus cyclique. Selon le modèle le plus classique dit « modèle en V » (dont on voit un exemple dans la figure 3.3), les phases de conception se situent sur la partie gauche, et les phases de test et de validation, sur la branche de droite du V. Ainsi, à chaque phase de spécifications correspond une phase des tests.

Expression des besoins

Validation

Conception générale

Intégration

Conception détaillée

tests

Programmation Figure 3.3. Les phases du cycle en V

Les deux branches du V sont symétriques : l’enchaînement des phases est séquentiel (par exemple, la conception générale est suivie de la conception détaillée), mais la validation du résultat d’une phase se fait lors de la phase « en miroir ». Ainsi, dans notre exemple, la phase d’intégration doit valider le résultat de la phase de conception générale.

42


Ce modèle « en V » est actuellement dépassé par les méthodes modernes de développement, mais il sert toujours de base et de référence. Remarquons également que les phases représentées dans la partie haute du V correspondent à des activités dans lesquelles une vision globale du produit est nécessaire, alors que les phases représentées en bas du cycle correspondent aux activités techniques et à un travail dans le détail. Le maître d’ouvrage est précisément responsable des phases « hautes » du cycle en V : – l’expression des besoins, qui se concrétise par l’élaboration, puis à la livraison à la maîtrise d’œuvre, d’un cahier des charges ; – la validation du produit livré, conformément au cahier des charges. Le maître d’ouvrage est également responsable du suivi du projet. Il doit vérifier qu’à tout moment le maître d’œuvre est en train de réaliser le produit en suivant les indications du cahier des charges.

Expression des besoins

Validation

Conception générale

Intégration

Conception détaillée

tests

Programmation Suivi de projet maîtrise d’oeuvre

Figure 3.4. Les responsabilités de la maîtrise d’ouvrage


43

Souvent, le maître d’ouvrage, pour des raisons diverses (absence de compétences en interne), délègue une ou plusieurs de ces activités à un ou plusieurs experts ou consultants que l’on a l’habitude d’appeler « assistants à la maîtrise d’ouvrage ». Contrairement à ce que l’on pense souvent (et contrairement, aussi, à ce qui se pratique parfois), l’assistance à la maîtrise d’ouvrage est un vrai métier, croisement entre le consultant, l’expert et le manager de projet, faisant appel à des compétences spécifiques, en fonction de la phase du projet et du métier du client. 3.3. Le cahier des charges L’ensemble des exigences du maître d’ouvrage est consigné dans un document appelé cahier des charges. Le cahier des charges est donc un document de première importance, et il est placé sous le contrôle du maître d’ouvrage. De ce document dépendra en grande partie la réussite du projet. Pour améliorer la relation entre client et fournisseur, le cahier des charges doit viser plusieurs objectifs : – cerner le véritable besoin : - par une analyse systématique et exhaustive des souhaits, - par une synthèse auprès des utilisateurs, - par une mise en évidence des priorités, - par la définition des critères d’appréciation ; – stimuler le fournisseur : - par une ouverture du champ de la recherche, - par une incitation à l’optimisation technologique, - par une libération du choix de solutions, - dans le cadre des contraintes imposées ; – favoriser le dialogue : - en soulignant les exigences intangibles, - en délimitant les marges de manœuvre, - en énumérant les contraintes, - en s’ouvrant aux suggestions.

44


Le cahier des charges est le tableau de bord du projet. Il définit le projet ainsi que les conditions qui permettront de le mener à bien. Il fournit des informations sur le client, ses besoins, et renseigne le fournisseur sur l’usage qui sera fait et sur les aspects techniques et commerciaux. Le fournisseur partira de ce document de référence pour proposer des solutions. Le cahier des charges fixe les objectifs et les contraintes du projet. Très souvent, il indique aussi les éléments à prendre en compte pour le mener à bien. Il permet au fournisseur d’avoir une idée claire sur ce qu’il peut ou ne peut pas proposer au client, et sur les objectifs et les contraintes internes au client, qui devront en tout état de cause être prises en compte. Il fournit au concepteur les renseignements nécessaires pour réaliser le projet. C’est à la fois un document de référence (pour tous les responsables impliqués dans le projet) et de dialogue entre le fournisseur et le client. Cette « double personnalité » échappe parfois aux fournisseurs. Un cahier des charges a toujours deux faces. L’une est procédurière, contractuelle, rigide. L’autre est un appel à la créativité et à l’imagination du fournisseur. Un tel document est indispensable pour permettre à chaque acteur de prendre connaissance des règles du jeu qui s’imposent à tous, permettant à chacun d’agir en connaissance de cause. Un bon cahier des charges permet de gagner du temps et d’éviter de s’engager dans une fausse direction. C’est la base de travail de tout projet de réalisation. Cependant, ce document ne doit pas être figé. Il peut être complété, voire modifié en cours de route, et il est rare qu’il ne soit pas modifié. Le client apporte souvent de nouvelles contraintes ou de nouvelles exigences en cours de projet. Le fournisseur apporte souvent des solutions auxquelles le client n’avait pas pensé : interface graphique originale, nouvelles


45

technologies, nouvelles contraintes de sécurité, de fiabilité, de performance, voire un autre type de produit exploitant mieux les capacités du client ou du marché. C’est pourquoi le client, tout en restant maître de ses choix, peut avoir intérêt à associer le fournisseur à la rédaction, ou du moins à la finalisation, du cahier des charges. 3.3.1. Formulation, négociation, reformulation Dans le prochain chapitre, nous détaillerons les diverses méthodes et techniques permettant de découvrir, de formuler, de suivre et de valider les exigences. Considérons pour le moment un cas simple : celui ou toutes les exigences du client sont formulées dans un cahier des charges1. Et simplifions le cas à l’extrême en supposant que les exigences sont présentées dans un document, sous forme de liste (dans notre exemple, le client présente au fournisseur une liste de dix exigences, notées par des lettres de A à J). Après réception, le fournisseur peut répondre à ces exigences. Il est en effet rare qu’un cahier des charges soit accepté en l’état, et même dans le cas d’un appel d’offres public, le cahier des charges prévoit souvent un cadre de réponse, que le fournisseur utilisera pour réagir par écrit, soit en demandant des éclaircissements, soit pour apporter des idées nouvelles, des alternatives que le client n’avait pas imaginées. Le cahier des charges fera alors un « aller-retour » (voire plusieurs) entre client et fournisseur. Ce sera au fournisseur de travailler pour reformuler les exigences. Les exigences pourront évoluer selon le tableau 3.1.

1. Le cahier des charges est un support de la formulation des exigences parmi d’autres. C’est cependant le support le plus fréquemment utilisé en France pour les applications de gestion.

46


N° exigence

Remarques du fournisseur

A

Qu’entend-on par cursus ?

B C

Qui saisit ? La formulation est ambiguë Qu’entend-on par commande simple ?

D E

Pouvez-vous préciser ?

G H

Qu’entend-on par « édition » ? Quelles statistiques ? Pouvez-vous préciser ?

I

Pouvez-vous préciser ?

J

Semble auto-contradictoire

F

Exigence modifiée par le client Les classes et écoles des trois dernières années Le principal ou le proviseur Un clic sur un bouton, ou choix dans un menu Abscisses = mois/ ordonnées = note ; une courbe par matière L’impression de masse Voir annexe B De 8h à 18h du lundi au samedi Respect du guide de style en annexe Voir norme de sécurité en annexe

Tableau 3.1. Modification d’exigences

3.4. La validation Le maître d’ouvrage est donc, avant tout, le maître de ses exigences. C’est lui qui doit mener le jeu. Le fournisseur peut proposer des variantes, chercher à négocier, apporter des idées nouvelles, mais c’est au maître d’ouvrage que revient le dernier mot. A la livraison du produit, le maître d’ouvrage doit vérifier la conformité de ce produit aux exigences. C’est la nécessaire phase de validation, où le logiciel, avant d’être mis en production, doit passer par une batterie de tests. Cette phase est plus ou moins complexe et longue en fonction de la complexité du produit, du niveau d’exigence du client (en fiabilité, sécurité, etc.). Le maître d’ouvrage peut s’en acquitter soit seul, soit en faisant appel à un prestataire de service.


47

Mais, dans tous les cas, la validation est grandement facilitée si le cahier des charges a été correctement formulé. En particulier, la constitution du « cahier de tests » est rendue plus simple, ce dernier étant en quelque sorte l’équivalent en « miroir » du cahier des charges. On peut dire, en paraphrasant un proverbe connu, qu’une exigence qui s’énonce clairement se valide facilement. 3.5. Le suivi du projet Le client ne peut pas se contenter d’envoyer le cahier des charges, d’attendre que le développement soit fini, et de valider le produit livré. Il doit véritablement suivre le projet. On l’oublie trop souvent : le suivi de projet du côté de la maîtrise d’ouvrage est un véritable métier. En fait, dans une véritable relation entre maîtrise d’œuvre et maîtrise d’ouvrage, deux suivis de projet s’opèrent, de manière pour ainsi dire antagoniste. Les points de vue des deux chefs de projet sont confrontés, le dialogue s’engage, la négociation est permanente. La réussite du projet, et la concrétisation de cette réussite, à savoir la qualité du produit, dépendent pour une grande partie du bon dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre.

CHAPITRE 4

La définition des objectifs

4.1. Au préalable : une décision de changement La décision initiale de développer, faire développer ou acquérir un logiciel peut avoir des origines très diverses : détection d’une opportunité d’affaire (pour un éditeur de logiciel), décision stratégique, avantage compétitif apporté par une nouvelle application (par exemple, dans le secteur tertiaire), alignement sur le schéma directeur stratégique (par exemple, dans l’administration), ou plan d’urbanisation permettant d’aligner le système d’information avec les objectifs stratégiques de l’entreprise. Ce processus de décision dépasse l’informatique et est hors du périmètre de cet ouvrage. En revanche, la phase qui va suivre est la première phase du cycle de vie et l’objet de ce chapitre fait bien partie de l’ingénierie des systèmes d’information. Selon les terminologies, elle peut s’appeler cadrage, centrage ou phase exploratoire1.

1. Cependant, parler d’objectifs permet de se concentrer sur le résultat, sur le produit, alors que le document de centrage se concentre souvent sur le projet.

50


En tout état de cause, à l’issue de cette phase, les objectifs du produit et le périmètre du projet doivent être clairement définis dans leurs grandes lignes. Il s’agit de décrire le produit à larges mailles en termes de résultats en indiquant les contraintes. Il ne s’agit pas tant de décrire ce que le produit devra faire (c’est là l’objet de la phase d’exigences) mais à quoi il devra servir. On peut distinguer deux types d’objectifs : – les objectifs en termes de produit : description des grandes fonctions et des résultats attendus ; – les objectifs en termes de projet, qui définissent dans les grandes lignes le délai, le budget, les moyens. Comme cette phase conditionne la réussite de toutes les phases qui suivent, il est important de lui apporter le plus grand soin. C’est là un investissement à long terme et à très haute valeur ajoutée. Cette phase devrait aboutir à un document de spécification des objectifs qui constitue en quelque sorte l’amorce du cahier des charges. Ce terme est à prendre à la fois au sens d’ébauche et de détonateur : il peut lui-même être inclus dans le cahier de spécification d’exigences qui lui succèdera, mais il déclenche aussi la « réaction en chaîne » du développement. 4.2. Le contenu de la phase d’objectifs Il s’agit d’aboutir à un document contenant : – la description, à très larges mailles, du produit attendu : le « quoi » ; – ses intentions (quels sont les buts poursuivis) ; – ce qui a déclenché le projet : personnes ou entités à l’origine du projet, éventuel projet précurseur, projets analogues, ayant abouti ou non, dans d’autres entités de l’entreprise ;


51

– dans quelle mesure le projet répond aux orientations stratégiques, au schéma directeur… – la finalité à long terme : qu’aura-t-on de plus lorsque le projet sera réalisé ? – les enjeux : ce que l’on gagne à faire ou à ne pas faire ce développement. 4.3. Les activités de la phase d’objectifs Cette phase permettra de spécifier, à larges mailles mais avec précision, les enjeux, la vision, le périmètre et le contexte du produit. Une fois ces éléments recueillis, précisés, ils devront être mis par écrit et diffusés à tous les intéressés sous forme d’un document global. Ce document peut porter des noms divers (rapport d’étude de cadrage, lettre d’objectifs…). L’important est de disposer de ce document de référence qui constitue la déclaration d’intentions du produit à venir. 4.3.1. Définir l’importance du produit et du projet L’introduction (acquisition ou développement) d’un produit, et par conséquent, le lancement d’un projet, peuvent avoir des impacts sur les plans stratégique, organisationnel, humain et social. Quelle est la finalité du produit, sur le long terme ? En d’autres termes, que se passera-t-il une fois que le produit sera livré ? Il est important que ces aspects soient discutés, mis par écrit, et publiés. Il s’agit ici de décrire le besoin auquel répond le produit, la finalité première.

52


4.3.2. Définir et clarifier les enjeux Il s’agit de préciser, dans leurs grandes lignes : – l’origine de la décision de développer le logiciel (ou de l’acquérir) ; – les opportunités auxquelles il répond (sur le plan stratégique, marketing) ; – les besoins de l’entreprise auxquels il répond ; – les bénéfices escomptés ; – les risques. D’une manière plus générale, il est important de déterminer ce que l’on gagnera et ce que l’on perdra à réaliser le projet, et aussi à ne pas le réaliser. 4.3.3. Tracer la vision du produit La vision du produit permettra d’orienter les décisions ultérieures, en particulier lors de la phase d’exigences. Il s’agit de « penser » le produit dans ses grandes lignes, et de préciser par écrit : – son objectif à long terme ; – ses fonctions ; – les catégories d’utilisateurs, et les besoins « métier » auxquels il répondra ; – la manière dont il sera utilisé, son impact sur le métier de l’utilisateur, sur sa façon de travailler ; – ce qu’il présente de nouveau par rapport à la situation existante (à ce titre, une étude de l’existant peut s’avérer utile) ; – ses caractéristiques, comparativement à d’autres produits du même type (produits concurrents, produits analogues utilisés par des concurrents), à des produits sur étagère…


53

– son intégration dans le système d’information de l’entreprise, et son interdépendance vis-à-vis des autres logiciels. 4.3.4. Définir le périmètre actuel et futur Parmi les fonctions décrites, il est important de déterminer celles qui seront développées pour la première version du produit, et celles que l’on réserve pour une version ultérieure. Il est également utile de spécifier lors de cette phase ce qui est hors périmètre, donc ce que le produit ne fera pas. De même, on définira explicitement les limites du produit, en termes de caractéristiques, de performances. 4.3.5. Définir le contexte Afin que, par la suite, les bonnes décisions soient prises, il est important de déterminer : – les acteurs du projet et les futurs utilisateurs du produit ; – les priorités : contraintes, facteurs limitants, degrés de liberté ; – l’environnement du projet, sur les plans fonctionnel, technique, géographique. 4.3.6. Evaluer la complexité du projet La complexité dépend de plusieurs paramètres : – parties prenantes impliquées ; – organisation du projet ; – dépendance entre le produit à développer et le système d’information existant ; – nombre de sites et de pays concernés ;

54


– nombre d’utilisateurs, leur dispersion géographique ; – langues de travail et contraintes de localisation ; – nombre de types d’utilisateurs (profils) ; – caractère innovant du projet, sur le plan technique ou organisationnel ; – degré d’urgence dans la livraison du produit ; – changements (organisationnel, technique...) introduits ; – flexibilité (variabilité, adaptabilité) attendue. 4.3.7. Le diagramme de contexte Un diagramme de contexte est un diagramme de flux au niveau le plus global. Il permet de décrire le logiciel à venir dans ses grandes lignes : le logiciel lui-même est une boîte noire (représentée par un cercle dans le diagramme) sans aucun détail.

Compta Directeur

Rapports données médicales

dossier scolaire

Notre logiciel

Médecin Dossier scolaire Dossier médical

Dossier scolaire

Personnel Admin. Données administratives

Etab. scolaire Figure 4.1. Diagramme de contexte


55

Le diagramme de contexte constitue le premier pas de la modélisation du flux de données, qui sera poursuivi lors des phases d’exigences et de conception. 4.4. L’analyse de l’existant Lors de cette étape, il s’agit d’examiner la ou les applications existantes qui vont éventuellement être remplacées par l’application à venir, afin de déterminer par la suite la trajectoire d’évolution. L’analyse de l’existant est intimement liée à la définition des objectifs. En effet, le développement ou l’acquisition d’un nouveau logiciel peut répondre à trois types d’objectifs : – préserver l’existant : ne rien changer à la situation actuelle en termes de services fournis par le système ; – améliorer l’existant : apporter un service supplémentaire, ou améliorer un service existant ; – innover : apporter un nouveau service, soit à l’intérieur de l’entreprise, soit vis-à-vis des clients de celle-ci. Le scénario d’évolution dépend à la fois de l’objectif stratégique (préserver, améliorer ou innover) défini en amont, et de l’existant en termes de système d’information (et en particulier de son patrimoine applicatif). De nombreux cas de figure peuvent se présenter : – une application existante va être remplacée point par point par une nouvelle application qui aura les mêmes fonctions (réécriture isofonctionnelle) ; en réalité, ce cas de figure est assez rare : même lorsque le client demande, dans un premier temps, une réécriture isofonctionnelle « légèrement améliorée », l’analyse ultérieure révèle de nouveaux besoins ;

56


– certaines fonctions vont être réécrites à l’identique, mais des fonctions nouvelles vont devoir être développées, et certaines fonctions obsolètes ne seront pas réécrites ; – le logiciel mis en place sera entièrement comparativement à la situation existante.

nouveau

Mais, plus qu’une éventuelle application existante à remplacer ou à réécrire, c’est l’environnement qui sera examiné : – applications ; – modèles de données ; – flux de données ; – volumes de données échangées ; – tableau croisé des fonctions disponibles par type d’utilisateur ; – dépendances entre applications. Bien entendu, dans la plupart des cas, la situation est une combinaison des situations décrites ci-dessus. La démarche est itérative : connaître l’existant va souvent amener à redéfinir les objectifs, et cette redéfinition va amener à valider les objectifs vis-à-vis de l’existant. 4.5. L’analyse des parties prenantes (les acteurs) Cette étape est préliminaire à l’ingénierie des exigences : savoir qui commande le logiciel, qui paye, et qui va l’utiliser. En d’autres termes, déterminer avec précision les parties prenantes (en anglais, stakeholders, mot très souvent utilisé dans la littérature anglo-saxonne). Cette étape n’en est pas vraiment une. Il s’agit presque, pour ainsi dire, d’une activité continue. Sur tout projet, tout participant devrait se poser à tout moment la même questionclé : « Qui veut quoi, pourquoi, pour quand, pour qui, pour quoi


57

faire ? ». Il est cependant essentiel de lui consacrer un effort important en phase d’objectifs. 4.5.1. Qui sont les acteurs ? Les parties prenantes d’un projet (puis d’un produit) sont : – les utilisateurs ; – le client (ou maître d’ouvrage) : il peut être utilisateur du produit ou non ; – le demandeur (ou donneur d’ordre) qui commande le produit ; – le directeur ou chef de projet ; – les développeurs ; – ceux qui maintiennent ; – le support aux utilisateurs, à divers niveau. Les intérêts et les besoins des acteurs sont très différents, et il est important de les connaître le plus tôt possible. Les acteurs sont plus nombreux que l’on imagine à première vue, et leurs préoccupations (leurs besoins a priori) peuvent être extrêmement variés. Voici quelques exemples : – un utilisateur expert du métier a besoin de productivité, avec des raccourcis clavier lui permettant d’atteindre les fonctions voulues en une fraction de seconde, alors que l’utilisateur débutant a besoin d’un logiciel à la fois facile à apprendre et pédagogique, lui permettant d’apprendre le métier du même coup ; ces deux besoins ne sont pas toujours faciles à concilier ; – l’équipe de support technique a, a priori, des besoins de traçabilité, c’est-à-dire de la possibilité de remonter à la cause des erreurs et d’en connaître les circonstances (la date, l’heure, l’utilisateur, la machine, le réseau) ; mais une fois l’erreur

58


analysée à ce niveau, le logiciel est pris en main par l’équipe de maintenance qui, elle, a besoin d’un logiciel analysable, lui permettant de naviguer dans les programmes pour les modifier ; ces deux besoins sont souvent antinomiques : truffer le programme de « traceurs » ne le rend pas toujours plus lisible ; de plus, à chaque modification, les personnes de la maintenance devront faire attention à conserver la fragile traçabilité d’origine, ce qui peut engendrer des surcoûts ; – un responsable marketing peut vouloir un logiciel attractif qui va plaire aux futurs utilisateurs ; souci légitime si l’on veut vendre un produit sur étagère ou attirer les utilisateurs d’un logiciel spécifique, mais… souvent contradictoire avec les véritables besoins en ergonomie. Connaître ces préoccupations, ces besoins a priori, ne fait pas partie de l’analyse des besoins proprement dite, car elle existe indépendamment de tout produit. Elle doit se faire avant même de mettre les objectifs sur le papier. 4.5.2. Les moteurs et les freins au changement Il est également important de connaître le niveau d’adhésion ou d’opposition des différents acteurs vis-à-vis d’un projet ou d’un produit donné, ce qui est une autre paire de manches. Les raisons d’adhérer ou de s’opposer au projet peuvent être très diverses : peur de perdre son travail, ou une partie de son travail, ou une partie de son pouvoir, refus de changer ses habitudes ou, au contraire, opportunité de mettre en valeur des compétences. Quelles que soient les raisons de s’opposer ou d’adhérer au projet, il est important de savoir qui adhère et qui s’oppose (le « pourquoi » n’est pas toujours avouable, mais l’important n’est pas là : ce qui importe en l’occurrence est le « comment »).


59

4.5.3. Techniques d’analyse des parties prenantes Des milliers de pages d’articles et d’ouvrages ont été écrites sur l’analyse des parties prenantes (en anglais, stakeholder analysis) et chaque expert propose des outils différents pour mener cette analyse. Pouvoir fort + Direction générale -

+

Médecins

-

Comptables

Développement Peu impactés

Fortement impactés

Secrétaires + Moteurs

+ Support bureautique Faible pouvoir

0 Indifférents - Opposants

Figure 4.2. Analyse des parties prenantes

Un moyen simple pour examiner les rapports de force entre intervenants au projet et parties prenantes au produit consiste à classer chacun d’eux (chaque profil ou chaque personne, selon la taille et le type de projet) selon trois axes : – fortement ou faiblement impactés ; – pouvoir d’influence sur le projet ; – adhésion ou opposition au projet ou au produit à venir.

60


On se retrouve donc avec une matrice à trois dimensions, que l’on représente le plus souvent par un diagramme à deux axes. Pour le troisième axe, on utilise des couleurs ou des signes.

Sécurité

Oui

Oui Oui

Oui

…

Ergonomie

Oui

Performance

Priorité fonctions

Oui

Fiabilité

Expertise métier

Un autre aspect de l’analyse des parties prenantes, beaucoup plus technique, concerne l’utilité des différents acteurs en tant que fournisseur d’informations lors du recueil d’exigences.

DG Médecins Secrétaires Gestionnaires

Oui

Oui

… Tableau 4.1. Informations fournies par les parties prenantes

4.6. L’étude comparative Une étude comparative est en général menée lorsqu’une entreprise ou administration souhaite acquérir un logiciel du marché, afin de choisir le produit le plus adéquat avec toute l’objectivité nécessaire. Cependant, une étude comparative peut être menée même dans le cas où il a été décidé de développer un logiciel en interne. En effet, comparer plusieurs logiciels offrant des fonctions plus ou moins similaires à celles que l’on veut faire développer permet de recueillir des idées nouvelles, de connaître l’état de l’art, de voir ce qui peut être fait et ce qui ne pourra être réalisé qu’avec difficulté. Mais une étude comparative (même rapide


61

et superficielle) a un autre avantage, beaucoup plus important : elle permet de valider l’opportunité de développer un produit. Autrement, comment peut-on s’assurer que rien de ce qui existe ne convient ? Enfin, une étude comparative permet de rester humble : ce qui n’a pas été fait ailleurs, ou qui a été fait de façon imparfaite, eston sûrs de mieux pouvoir le réaliser en interne ? 4.7. La déclaration d’objectifs La phase d’objectif aboutira à un document décrivant : – l’existant et le contexte ; – l’opportunité du projet ; – les objectifs. Le préambule de ce document fera une présentation brève, compacte, stratégique du produit à venir. Il peut s’agir d’un texte d’une page, pour un projet de plusieurs millions d’euros. Il sera diffusé aussi largement que possible. Cette déclaration d’intention a pour objectif de faire partager une vision commune, claire, connue de tous, du futur produit. Il pourra servir de « contrat » entre les parties prenantes. Il complètera si nécessaire la lettre de mission du chef de projet (maîtrise d’ouvrage et maîtrise d’œuvre). Ce texte sera autonome (pouvant être diffusé dans une revue interne de l’entreprise) et indiquera : – le nom du produit ou, à défaut, du projet qui y aboutira ; – le caractère stratégique, tactique ou opérationnel du produit ; – le type de produit, sa catégorie ; – qui seront les futurs utilisateurs ; – à quels besoins de ces utilisateurs ce produit répondra ;

62


– ses caractéristiques particulières ; – ce qui le distingue des produits concurrents ou d’un logiciel déjà en place. L’exemple suivant est tiré d’un cas réel (les noms sont imaginaires). Royaume de Syldavie Ministère de la Jeunesse

Ministère de la Musique

Refonte de l’application informatique des conservatoires L’application SERIEL La mesure Numéro 8 du plan « Musicol » vise à achever et optimiser la gestion des conservatoires municipaux et cantonaux. La refonte de l’application informatique nationale des conservatoires – projet SERIEL (Système pour l’éducation régionale et l’inscription des élèves) – en constitue un élément essentiel. A l’usage des directeurs et professeurs des conservatoires, le logiciel SERIEL, système de gestion des élèves musiciens, aura pour vocation la gestion automatisée des professeurs et des élèves, ainsi que le suivi des cours et l’attribution des notes au fil de l’eau. Il poursuit un double objectif : – améliorer au quotidien la gestion des dossiers et les tâches de secrétariat des conservatoires, afin de permettre aux équipes pédagogiques de consacrer davantage de temps au suivi des cas individuels ; – améliorer le pilotage local des activités de chaque conservatoire (notamment l’orientation des élèves vers des carrières de musiciens professionnels) et faire remonter aux administrations cantonales et centrales les informations nécessaires au pilotage de la politique en direction des jeunes musiciens. SERIEL remplacera l’actuel système TONAL, et sera expérimenté dès avril 2007 puis installé dans les conservatoires au cours de l’année 2008. La première version privilégie les fonctions de gestion administrative. SERIEL bénéficie toutefois, par rapport à l’actuelle application informatique TONAL utilisée dans les conservatoires, d’une ergonomie et de fonctionnalités rénovées, et sera utilisable avec un simple navigateur web. Ainsi, les données saisies dans l’application permettront des éditions automatiques de dossiers, la réalisation de listes thématiques et la consultation rapide des dossiers, ainsi que l’édition d’une synthèse du dossier du jeune musicien.


63

On remarquera que ce texte distingue les objectifs du logiciel (améliorer la gestion et le pilotage) de la vocation (conséquence à long terme de la réussite des objectifs). Il situe le logiciel dans son contexte et en indique l’origine (plan ministériel).

CHAPITRE 5

Recueil et analyse des besoins

5.1. Activités de l’ingénierie des besoins L’ingénierie des exigences est la discipline regroupant : – le recueil des besoins ; – l’analyse des besoins ; – la formulation des exigences ; – la vérification et la validation des exigences ; – et enfin, la gestion des exigences et de leurs évolutions. Dans ce chapitre, nous allons expliciter ces étapes, puis indiquer quelques méthodes, techniques et outils de recueil et d’analyse. Il ne s’agit pas d’un catalogue exhaustif, mais une description des méthodes les plus courantes et aussi les plus innovantes. Comme nous allons le voir, certaines méthodes sont plutôt formelles, d’autres font appel à l’intuition et à la créativité. L’ingénierie des exigences n’est pas une science exacte, ni une activité totalement déterministe. Ce qui explique pourquoi, sur un même projet, plusieurs outils et techniques peuvent être utilisés, simultanément ou alternativement.

66


Recueillir, analyser et exprimer les exigences est un métier difficile. L’art du conseiller à la maîtrise d’ouvrage, ou de l’ingénieur des besoins, consiste à utiliser une ou plusieurs de ces techniques et outils pour faire ressortir les besoins, les expliciter et les formaliser. Il doit donner une vision exhaustive des exigences du futur produit, sans cependant s’engouffrer dans la technique de sa construction. 5.2. Les grandes étapes 5.2.1. Recueil des besoins Première étape de l’ingénierie des exigences (et par conséquent, première étape de tout projet de construction de logiciel) : capturer le besoin. Cette activité fait appel à différentes techniques : interviews, observation directe, réunions. Plusieurs de ces techniques seront exposées dans les paragraphes suivants. Cette activité est beaucoup moins simple et facile qu’il n’y paraît à première vue, et ce, pour plusieurs raisons : un utilisateur n’est en général pas conscient de ce qu’une application informatique peut ou ne peut pas faire, ni de la difficulté à mettre en œuvre. En d’autres termes, il ne connaît pas le coût et la faisabilité de ses exigences. D’autre part, chaque catégorie d’utilisateurs exprime des besoins dans un jargon qui lui est propre, que la personne chargée du recueil devra clarifier. Le vocabulaire devra être unifié. Enfin, de très nombreux besoins sont passés sous silence, car ils sont évidents pour l’utilisateur et semblent aller de soi. Ils devront être explicités. 5.2.2. Analyse des besoins Lors de cette étape, les besoins « bruts » devront être raffinés. D’une part, en éliminant les ambiguïtés, incohérences, redondances et incomplétudes entre les besoins exprimés.


67

D’autre part, en les passant à travers plusieurs filtres successifs : objectifs exprimés en amont, contexte de l’entreprise, système d’information existant. 5.2.3. Spécification des exigences N° exigence A B C D E F G H I J

Formulation de l’exigence L’application permettra la saisie rapide du nom de l’élève, de son âge, de son cursus et de ses coordonnées postales, ainsi que de commentaires. L’application permettra la saisie, en début d’année, des matières, des noms des professeurs, et des coefficients des différentes matières. L’application permettra la saisie au fil de l’eau des notes obtenues par un élève pendant l’année en cours. L’application présentera, au moyen d’une commande simple, l’évolution des notes d’un élève dans différentes matières, sous forme de courbe. Pour chaque élève, l’application permettra de calculer la moyenne pondérée, résultant des notes obtenues par cet élève. L’application permettra l’édition en masse de bulletins scolaires. L’application permettra d’effectuer des statistiques sur l’évolution des résultats d’une classe sur plusieurs années. L’application sera disponible et fiable. L’application sera ergonomique. L’accès à l’application sera sécurisée, et accessible à tous les utilisateurs. Tableau 5.1. Liste d’exigences

Cette dernière étape consiste à rassembler dans un document unique (appelé, selon la méthodologie employée, cahier des charges, dossier des besoins du système, dossier de spécification de exigences, spécifications générales…) l’ensemble des exigences du système sous forme cohérente. Ce document tient compte des besoins exprimés par les utilisateurs ou d’autres parties prenantes, des objectifs, du contexte, et des contraintes techniques.

68


Il inclut : – les exigences fonctionnelles (ce que le système doit faire) ; – les exigences non fonctionnelles (fiabilité, ergonomie…) ; – des contraintes techniques. La réalisation d’un dossier de spécification d’exigences est un exercice d’une grande difficulté. Pour s’en convaincre, le lecteur pourra se livrer à l’exercice suivant soit un mini-cahier des charges (voir tableau 5.1)comportant dix exigences, rechercher les ambiguïtés, incohérences, imprécisions et incomplétudes. Le lecteur trouvera un début de réponse à cet exercice au tableau 3.1. 5.2.4. Validation Les exigences devront être vérifiées et validées par toutes les parties prenantes. Bien qu’une partie importante de la validation se fasse suite à la première diffusion des exigences spécifiées (par exemple, après la première version du cahier des charges), la validation peut être considérée comme une activité continue. Les exigences sont validées après recueil (validation des comptes rendus d’interviews ou de réunions), après analyse (relectures partielles), après spécifications (revue formelle des exigences). Outre les revues de documents, divers moyens existent pour valider les exigences comme les maquettes et prototypes. La rédaction de scénarios de test, le plus en amont possible, est également un excellent moyen de validation. En réalité, la validation des exigences a lieu tout au long du cycle de vie, avant, pendant et après développement. Ce n’est qu’en phase de service régulier que l’on peut être certain que les exigences ont été correctement traitées, et ce, jusqu’à la prochaine demande d’évolution ?


69

5.2.5. Négociation Le développement des exigences est une affaire de compromis : les besoins peuvent être très différents d’un utilisateur à l’autre ; également entre les utilisateurs et la maîtrise d’ouvrage ; de plus chaque nouvelle exigence apporte de nouvelles contraintes en termes de délais, de coût et d’impact sur les autres fonctions du système et sur la qualité du système. Le recueil des besoins, l’analyse et la spécification des exigences ne sont pas « un long fleuve tranquille ». Les techniques de négociation, de résolution de conflits, l’empathie sont ici aussi utiles (sinon plus) que l’expertise du métier de la maîtrise d’ouvrage ou que les connaissances techniques. Le travail sur les exigences est un travail de négociation. Lors de leur recueil, de leur analyse et de leur spécification, les retours en arrière sont innombrables et inévitables. Ces retours en arrière ne doivent pas être considérés comme une perte de temps, mais comme un investissement : l’insatisfaction et la frustration sont un excellent moyen de mettre à jour des exigences « cachées », passées inaperçues. Il n’en demeure pas moins que, plus les changements sont traités en amont, moins ils seront longs et coûteux à mettre en œuvre. 5.2.6. Gestion des évolutions Les changements dans les exigences, à tous les stades du projet, est un phénomène inévitable, même lorsque tout a été mis en œuvre pour capter, analyser et spécifier les exigences de manière exhaustive. Les raisons peuvent être très diverses : changement des objectifs initiaux, évolution du contexte, mutations technologiques, nouvelles règles de gestion, nouvelles contraintes, ou apparition de nouveaux besoins.

70


La gestion des changements est une activité de l’ingénierie du logiciel parmi les plus complexes, et dépasse le cadre de cet ouvrage. Les techniques qui permettent de limiter les risques sont multiples : – établissement de liens de traçabilité entre exigences de différents niveaux, ainsi que de la traçabilité entre les exigences et les autres produits de sortie (spécifications détaillées, programmes, documentation, scénarios de test) ; – établissement de processus formalisés et de procédures strictes de gestion des changements ; – mise en place d’un comité de gestion des changements, point de passage obligé et unique de toute demande de changement ; – systématisation des analyses d’impact, avant toute modification de l’application. 5.2.7. Un processus cyclique interviews

Réunions Remueméninges

demandes de modification validation

Recueil

validation

“filtres” - des objectifs - du contexte - de l’existant

Relectures, reformulation

Exigences spécifiées

Analyse Spécification

Figure 5.1. Vision imagée du processus de développement des exigences


71

Le processus de définition des exigences est cyclique, itératif. Le schéma ci-dessus résume l’enchaînement des activités qui viennent d’être décrites. 5.3. De la difficulté d’exprimer les besoins Le cahier des charges doit décrire les exigences, c’est-à-dire ce que l’on attend du système à venir. Quel que soit le modèle de cahier des charges utilisé, on y indique généralement : – le quoi : ce que doit apporter le système ; – le pourquoi : les motivations à l’origine de la demande ; – le quand : les délais de livraison ; – le qui : quels seront les futurs utilisateurs, qui est le donneur d’ordres ; – le comment : quelles sont les contraintes liées au produit, à son utilisation, ou éventuellement à sa construction. En d’autres termes, on doit décrire, avec plus ou moins de précision, le service attendu de la part du système ou du fournisseur et l’usage qui sera fait du produit. On peut y ajouter des contraintes d’usage, et même des contraintes techniques, mais on ne doit pas y indiquer de solution. La différence entre la description d’une exigence et la description d’une solution, déjà très subtile pour des produits manufacturés, devient un vrai casse-tête dans le monde du logiciel. Un exemple provenant du design industriel illustrera ce propos. Le maître d’ouvrage est un distributeur de produits pour fumeurs. Il constate que les briquets qu’il propose sont trop chers et trop encombrants et passe un appel d’offres pour diversifier son catalogue.

72


Voici trois formulations différentes des exigences, suivies des réponses qu’ils sont susceptibles de déclencher : – si l’exigence est « un briquet fiable, peu encombrant et peu coûteux », la solution proposée sera immanquablement un briquet, éventuellement jetable ; – si l’exigence est « un dispositif de faible encombrement, fiable et peu coûteux permettant de faire du feu », la solution proposée peut être un briquet ou une boite d’allumettes. L’exigence ne formule pas de solution (d’où deux réponses très différentes) mais une fonction (faire du feu) et deux contraintes (fiable et peu coûteux) ; – si l’exigence est « un dispositif de faible encombrement, fiable et peu coûteux permettant d’allumer une cigarette », la solution proposée peut être un briquet, une boite d’allumettes ou un allume-cigare d’automobile. L’exigence ne formule pas de solution (d’où trois réponses très différentes) mais une fonction (allumer une cigarette) et deux contraintes (fiable et peu coûteux). La première formulation induit une solution et bride l’imagination du fournisseur. Un briquet n’était pas la seule manière possible de satisfaire la clientèle. Pour cette raison, le mot « briquet » ne devait pas apparaître dans le cahier des charges. Remarquons que le vrai besoin n’était pas de faire du feu, mais d’allumer les cigarettes. En ce sens, la solution « allumecigare » était une bonne solution. Si le distributeur avait précisé que le produit devait être vendable en magasin, aucun fournisseur n’aurait proposé d’allume-cigare… à moins qu’un fabriquant astucieux et imaginatif ne propose un allume-cigare à piles qui tient dans la poche.


73

Le demandeur aurait pu ajouter qu’il a besoin d’un dispositif « autonome ». Le terme est ambigu, et la réponse aurait pu être aussi bien un allume-cigare (pas besoin de carburant tant que l’automobile fonctionne) qu’un briquet (on peut le garder en poche). Ce simple exemple peut être déroulé à l’infini, ce qui serait hors de propos dans cet ouvrage. Mais il permet de mettre en lumière plusieurs points : – il est très difficile, et pourtant nécessaire, d’exprimer les exigences sans exprimer de solution a priori ; – une même exigence fonctionnelle peut donner lieu à des solutions très différentes, suivant les exigences non fonctionnelles qui l’accompagnent ; – l’expression de l’exigence fonctionnelle peut être relativement aisée à formuler, alors que l’expression des exigences non fonctionnelles demande beaucoup de soin dans sa formulation (que signifient « fiable » et « peu coûteux » ?) ; – sans exprimer de solution, il est souvent nécessaire d’exprimer des contraintes d’environnement de la solution ou des contraintes d’interface (l’objet doit tenir dans une poche, dans la main, ou être l’accessoire d’une automobile). Nous avons pris jusqu’ici un exemple dans le monde de l’industrie manufacturière. Qu’en est-il du logiciel ? Les choses sont à la fois plus simples, car le matériau à notre disposition, le logiciel1, est homogène et unique. Mais ce matériau est invisible, inodore et impalpable. De ce fait, les contraintes non fonctionnelles sont difficiles à exprimer. Pire encore, du fait de cette immatérialité, aucune contrainte ne va d’elle-même. Dans le cas du briquet, la plupart des fabricants auront compris que le dispositif en question ne devrait pas s’enflammer spontanément 1. Le « logiciau », serait-on tenté de dire, par analogie au matériau. En réalité, le « matériau » dont il est question est de l’information à l’état pur.

74


dans la poche de l’utilisateur (même si, en toute rigueur, le cahier des charges devrait exprimer cette contrainte), ni tomber en panne après deux allumages, ni blesser celui qui le manipule. Mais la fiabilité, la sécurité, la maintenabilité et l’utilisabilité du logiciel sont des contraintes invisibles, donc mal maîtrisées. Sans contraintes fortes, les développements informatiques peuvent donner naissance à des produits monstrueux. D’où la nécessiter d’exprimer précisément les contraintes non fonctionnelles et, chose plus ardue encore, de s’assurer de leur suivi tout au long du projet. 5.4. L’intervention de recueil des besoins Le recueil des besoins et de spécification des exigences peut et doit être considéré comme un projet à part entière. A ce titre, il est utile d’établir un plan, préalablement à l’intervention de recueil. Ce plan précisera : – les objectifs de l’intervention : étude exploratoire, étude détaillée, le cas échéant, recherche d’un type d’exigences particulier (par exemple, exigences fonctionnelles seules, ou exigences d’interface) ; – les techniques de recueil : interviews, réunions, brainstorming, étude de produits concurrents, étude d’une application existante… – les méthodes et outils qui seront utilisés (par exemple, diagrammes de classe, diagrammes de cas d’utilisation) ; – les livrables attendus : cahier des charges et niveau de détail attendu, document de cadrage ou tout autre document ; – le planning de l’intervention ; – les risques pressentis. D’autre part, il est de l’intérêt de tous qu’une lettre de mission soit établie et diffusée aux personnes intéressées.


75

5.5. Typologie des exigences 5.5.1. Pourquoi classer les exigences par catégories ? Il peut sembler futile de vouloir classer les besoins par catégories ou par types. Ne doit-on pas se contenter de les recueillir et de les consigner dans un cahier des charges ? Or, ce sont justement là les deux raisons qui rendent indispensable la classification : – d’une part, si l’on ne veut pas que le cahier des charges ressemble à un ingérable inventaire à la Prévert, il est nécessaire de le structurer autant que possible ; une manière de faire consiste à créer un chapitre ou sous-chapitre par catégorie de besoins ; – d’autre part, recueillir des exigences, c’est avant tout poser (ou se poser) les bonnes questions au bon moment. Et les questions à poser pour apporter de la précision au besoin exprimé dépendent du type de besoin. 5.5.2. Les catégories d’exigences Une manière de classer les exigences est la typologie « qui, quoi, quand, pourquoi, comment, où… ». Elle est intéressante sur le plan théorique. Le pourquoi correspond aux objectifs, le quoi aux fonctions, le comment aux contraintes non fonctionnelles, etc. Mais elle est difficile à manier, car assez abstraite. Une liste analogue sert souvent de pense-bête pour la gestion de projet : produit et tâches (quoi), responsabilités et ressources (qui), moyens (comment), localisation (où), délais (quand), coûts (combien). Mais pour le recueil et la structuration des exigences, l’intérêt pratique d’une telle liste est limité. La réponse à une question en pourquoi peut très bien tomber dans la catégorie quoi ou comment, et vice versa.

76


Une structuration beaucoup plus pragmatique est donnée par Karl Wiegers [WIE 03]. Elle consiste à classer les exigences client dans l’une des neuf catégories suivantes : – les exigences de gestion (business requirements) ; elles concernent les avantages, bénéfices, intérêts stratégiques ou tactiques : augmentation du chiffre d’affaires, économies, gains ; – les scénarios et cas d’utilisation ; ils correspondent à des besoins opérationnels des utilisateurs : avoir la possibilité de saisir, d’imprimer, de gérer une information ; – les règles de gestion : le logiciel doit être conforme à une loi, un règlement, une directive ou une procédure ; – les exigences fonctionnelles : exigences de comportement du système ; – les attributs de qualité, également appelés exigences non fonctionnelles : ce sont des caractéristiques exigées du système : fiabilité, maintenabilité, portabilité, ergonomie ; elles sont trop souvent négligées et passées sous silence ; – les exigences d’interfaces externes, qu’il s’agisse de l’interface utilisateur, de l’interface avec le matériel ou un autre logiciel ; – les contraintes apportent des restrictions au système ; il s’agit souvent de contraintes liées au matériel (volumes traités, plateforme) ; si trop de contraintes apparaissent lors du recueil des besoins, cela peut être un frein à la recherche de la solution adéquate : il est utile de connaître les motivations de celui qui les formules ; – les définitions de données, relatives au format des données (par exemple, la forme d’un numéro de sécurité sociale ou d’un numéro de série) ; – les suggestions de solutions, formulées comme des exigences ; souvent, un utilisateur a une idée préconçue de la solution à mettre en œuvre ; lors du recueil et de l’analyse des exigences, il est important de les faire expliciter, puis de rechercher les motivations de celui qui les suggère.


77

Une information qui ne tomberait pas dans une de ces neuf catégories peut avoir de l’intérêt, mais ne concerne par le produit et son usage. C’est en particulier le cas des informations sur les coûts, les délais, les besoins en formation, les contraintes administratives. Ces informations peuvent éventuellement avoir leur place dans un cahier des charges, mais dans un chapitre à part, distinct des exigences produit2. 5.6. Les diverses techniques de recueil et d’analyse Dans le domaine de l’ingénierie des exigences, il n’y a pas de vérité absolue. Plusieurs techniques existent pour recueillir, formuler, négocier les exigences, et ces techniques peuvent s’utiliser seules, ou se conjuguer, en fonction du domaine d’application, des typologies d’utilisateurs, de la spécificité de l’application ou du produit à développer. Certaines de ces techniques sont de grands classiques, d’autres sont innovantes, et quelques-unes d’entre-elles nous viennent du monde de l’industrie manufacturière. L’ingénierie informatique gagnera beaucoup à s’inspirer de ce qui se fait dans l’industrie. Certaines techniques font appel à un formalisme très strict. D’autres, au contraire, ont été inventées pour faire travailler l’imagination. C’est la combinaison de ces techniques qui fait leur efficacité. Nous allons ici passer en revue celles qui nous semblent les plus importantes. 5.6.1. Le questionnaire Un questionnaire permet de recueillir rapidement les avis de plusieurs personnes sur un certain nombre de points. Il est utile 2. Dans l’administration, cette séparation est souvent obtenue par la distinction entre le CCTP (cahier des clauses techniques particulières) du CCAP (cahier des clauses administratives particulières).

78


pour obtenir des données factuelles et des opinions sur des points précis. L’élaboration d’un questionnaire est une tâche importante, qui doit être menée avec beaucoup de soin. L’opération n’est rentable que lorsqu’il s’agit d’interroger un grand nombre de personnes. Cependant, dans certains domaines précis, des questionnaires préétablis existent. En l’absence de questionnaire préétabli, les points suivants doivent être clarifiés préalablement à la rédaction du questionnaire proprement dit : – quel est l’objectif du questionnaire ? que veut-on savoir précisément ? – comment ce renseignement peut-il être fourni ? – quel est le degré de précision à atteindre ? – combien de questions doit-on poser pour avoir les informations voulues ? – combien de questions est-il réaliste de poser ? – comment les réponses seront-elles exploitées ? Les questions peuvent être fermées (cases à cocher) ce qui en facilite l’analyse. Il est donc intéressant, dans un questionnaire, d’avoir un maximum de questions fermées. Cependant, la formulation de questions fermées est un art difficile : elles doivent être énoncées très clairement, être spécifiques, être neutres (ne pas induire la réponse) et être formulées de telle sorte que, dans la majorité des cas, la réponse ait un sens pour celui qui répond (un grand nombre de « ne sais pas » ôte tout intérêt à l’exercice). Des questions ouvertes peuvent également être proposées, mais cela suppose que les personnes interrogées savent formuler les réponses avec précision. Dans la pratique, les questions sont souvent semi-ouvertes (cases à cocher, avec une case « autre »).


79

Pour les questions fermées, la méthode la plus fréquemment utilisée est l’échelle de Likert. Les catégories de réponses, sur une échelle de quatre à sept niveaux, sont formulées de manière à ce que leur signification soit la même (ou très proche) pour un groupe de personnes interrogées. Le tableau suivant donne quelques exemples d’échelles de Likert à cinq niveaux.

Fréquence

Jamais

Rarement

Parfois

Souvent

Toujours

Intensité

Aucun

Faible

Moyen

Assez fort

Fort

Vérité

Faux

Plutôt faux

Parfois vrai

Assez vrai

Vrai

Accord

Pas du tout d’accord

Plutôt pas d’accord

Ne sais pas

Plutôt d’accord

Tout à fait d’accord

Tableau 5.2. Echelles de Likert

Pour résumer, le questionnaire est un moyen utile d’obtenir des opinions ou des données d’un grand nombre de personnes. Cependant, il n’encourage pas l’émergence d’idées nouvelles. Sur ce point, l’interview, les groupes de travail, et surtout, le remue-méninges sont bien préférables. 5.6.2. L’interview L’interview est la technique la plus courante et la plus directe pour découvrir les besoins. Malgré sa simplicité apparente, la technique d’interview est un art difficile demandant une certaine expérience et un réel savoir-faire. La première étape consiste à définir l’objectif de l’entretien : le thème et les questions dont on cherche à obtenir des informations ou des donnés. L’étape suivante consiste à rechercher les personnes les plus aptes à apporter des réponses précises aux questions que

80


l’on a définies, ou à apporter une opinion ou un point de vue pertinent. Bien entendu, des questions différentes pourront être posées selon le profil de l’interviewé (maître d’ouvrage, utilisateur expert, utilisateur débutant, profils d’utilisateurs particuliers, par métier). Les résultats de l’analyse des parties prenantes effectuée en amont se révèlent ici d’un intérêt primordial. Tous les types d’entretien sont envisageables : contact direct, appel téléphonique et/ou échange de courrier électronique), en fonction du temps alloué, de la distance géographique et de l’objectif à atteindre. L’entretien peut être structuré (nombre de questions et contenu fixés à l’avance ; non structuré (l’ordre des questions n’est pas prédéterminé, et une grande initiative est laissée à l’interviewé), avec toutes les possibilités intermédiaires. Les entretiens structurés sont plus rapides et plus efficaces si l’on cherche des réponses à des questions précises, mais laissent moins de place à l’émergence des idées nouvelles. L’entretien peut comporter divers types de questions : fermées (l’interviewé doit choisir entre plusieurs réponses proposées) ou ouvertes (les réponses sont libres). Les premières questions, neutres et ouvertes, doivent encourager la personne interviewée à décrire le besoin sans influencer l’interlocuteur, sans induire de solution a priori. Les réponses aux questions posées dépendent de l’environnement et du métier de la personne interviewée. C’est la raison pour laquelle il est indispensable, avant de poser les questions de recueil de besoins proprement dites, de bien connaître l’interlocuteur, d’où les questions préliminaires (qui ne sont pas des questions de pure politesse, bien qu’elles servent aussi à détendre l’atmosphère). C’est à ce moment que l’étape précédente d’analyse des parties prenantes révèlera toute son utilité.


81

Les interviews seront préparées et conduites méthodiquement, en ayant à l’esprit que l’objectif est de faire évoluer le système : en préalable, on rappellera le contexte et les objectifs, et en fin d’interview on recueillera les suggestions de la personne interviewée. Une fois les interviews terminées, les réponses sont comparées, confrontées, croisées, mettant en lumière des besoins complémentaires, contradictoires, ainsi que les éventuelles incohérences entre prenantes se révèlera utile : un même besoin aura une signification différente selon le rôle de la personne qui l’a formulé. 5.6.3. Les groupes de travail Un groupe de travail est un ensemble de personnes se réunissant pour travailler sur une question précise : dans le cas présent, exprimer des besoins pour un logiciel à venir. La durée et la fréquence des réunions sont très variables. Le choix des participants, l’organisation matérielle (horaires, logistique, salle) et l’expérience de l’animateur du groupe sont des facteurs-clés de la réussite. Un groupe de travail peut être très efficace. Il permet de gagner du temps (tant en délai qu’en charge de travail). Mais il pose aussi des difficultés supplémentaires, car ici, chacun s’exprimant au grand jour, les contradictions, les incohérences, les rapports de force et les conflits entre participants peuvent être sousjacents ou flagrants, et l’animateur doit savoir les gérer. Une session de travail, qu’elle dure deux heures ou trois jours, doit être animée avec souplesse et cadrée avec rigueur. Le facilitateur doit énoncer les règles du jeu et s’assurer qu’elles sont connues de tous les participants : horaires, pauses, droit de parole, assiduité et ponctualité, participation active.

82


Une difficulté lors de ces sessions de travail est d’obtenir le bon niveau de détail dans la formulation des besoins. Certains contributeurs ont tendance à s’enfoncer dans les détails, d’autres à en rester à des généralités. Sans devenir censeur, l’animateur doit de temps en temps recadrer le débat. Les participants peuvent aussi apporter des idées et suggestions non directement utiles, hors sujet, mais néanmoins intéressantes. Il faudra les « mettre au frigo » pour une utilisation ultérieure éventuelle. Il est important de garder en tête l’objectif, formulé lors de la phase précédente. Enfin, la taille d’un groupe de travail est un facteur important. Il doit être suffisamment petit pour être gérable, et suffisamment grand pour fournir l’expertise et les idées nécessaires. Une demi douzaine de participants est l’idéal. 5.6.4. L’observation sur le terrain Observer les utilisateurs sur leur lieu de travail est un moyen efficace de connaître leurs besoins, parfois même une étape nécessaire. L’observation sur le terrain peut prendre plusieurs formes, en fonction du type d’application et de l’environnement. Cela peut aller de l’interview ou du groupe de travail sur place jusqu’à l’observation directe des utilisateurs en situation. Examiner la manière dont les utilisateurs se servent d’un logiciel déjà en place est souvent un excellent moyen de connaître les besoins d’une nouvelle application. Les utilisateurs s’expriment spontanément à propos de leur outil de travail, parlent de ce qui fonctionne bien et de ce qui ne marche pas, suggèrent des améliorations. Informations précieuses pour qui sait écouter et observer.


83

5.6.5. L’analyse de la concurrence Analyser la concurrence peut être un bon moyen de découvrir ses propres besoins. L’analyse de la concurrence peut prendre deux formes : – une entreprise ou une administration souhaite développer une application spécifique en interne : elle examine les logiciels du marché qui répondent à peu près aux mêmes besoins que le sien, ou les logiciels spécifiques de ses concurrents ; – un éditeur de logiciels analyse les produits logiciels fournis par ses concurrents, afin de s’en inspirer. Dans les deux cas, cet examen peut être très profitable. Il ne s’agit pas de plagier ou de singer le concurrent, mais au contraire d’examiner le produit avec un œil critique pour savoir : – à quels besoins répond le produit ; – comment ses besoins ont été satisfaits ; – quelles erreurs ont été faites dans cette mise en œuvre ; – comment éviter de répéter les erreurs du concurrent. 5.6.6. Le remue-méninges (brainstorming) Le remue-méninges (mot français pour brainstorming, littéralement « tempête dans le cerveau ») est une méthode permettant de faire jaillir des idées nouvelles. C’est une méthode créative, permettant de sortir des schémas de pensée classique. Pour conduire un brainstorming, un animateur est nécessaire. Dans notre cas, l’animateur sera le plus souvent le conseiller de la maîtrise d’ouvrage ou designer logiciel. Son rôle est de réunir et de mettre par écrit les idées qui émergent, et par la suite de les interpréter, de les reformuler, de les réutiliser.

84


La première étape consiste à formuler précisément la question à résoudre, de manière à ce que tous les participants aient les mêmes informations sur l’objectif à atteindre. Lors d’une session de brainstorming, chaque participant exprime de manière brève et spontanée toute solution au problème qui lui vient à l’esprit. A ce stade, les autres participants s’interdisent tout jugement sur les idées qui surgissent, et même toute demande de précision. En revanche (et c’est là ce qui fait la force de la technique) il est permis de rebondir sur l’idée d’un autre pour formuler une idée nouvelle. L’animateur note chaque idée sur une fiche ou une note autocollante. La session dure quinze à vingt minutes. Après cette phase créative, les demandes de précision et les discussions sont admises. Les idées sont classées. Les idées recueillies peuvent être exploitées de diverses manières, en particulier sous forme de diagramme d’affinités. 5.6.7. Les diagrammes d’affinités Le diagramme d’affinités est un outil permettant d’organiser des idées (dans le cas nous concernant, des besoins) en les regroupant. C’est un outil faisant appel à la pensée créative et à l’intuition. Il permet de travailler en groupe pour partager des idées, et de faire ressortir des idées directrices, clarifier les idées. Il peut faire suite à une séance de brainstorming. Le déroulement de l’exercice est le suivant : – le thème à traiter est énoncé par l’animateur du groupe ; – chaque participant reçoit des fiches ou des notes autocollantes ; – chaque participant écrit ses idées sur une fiche ; – les fiches sont étalées sur une table, ou collées sur un mur ;


85

– les personnes regroupent les idées par thèmes, en déplaçant les fiches ; – une fiche de titre est créée pour chaque thème ; – plusieurs thèmes peuvent être regroupés à leur tour. Gestion des élèves

Gestion des salles

Identité de l’élève

Fournitures

Suivi des notes

Inscriptions

Mobilier

Relevé de notes

Absences

Suivi médical

Contact parents

Nettoyage

Gestion des professeurs

Accès sécurisé

Figure 5.2. Diagramme d’affinités

Les règles sont simples et souples : le regroupement se fait selon l’intuition, et non selon la logique ; on n’a pas à justifier le regroupement sur un thème ; les groupes peuvent eux-mêmes être regroupés. Les participants doivent travailler silencieusement. Une fiche peut être déplacée plusieurs fois. Si deux participants ne sont pas d’accord sur le groupe d’appartenance d’une fiche, la fiche peut être dupliquée. La constitution du diagramme d’affinités peut se faire : – soit suite à un brainstorming : lors du brainstorming les idées sont exprimées sur des fiches, puis structurées selon un diagramme d’affinités ;

86


– soit directement : l’animateur énonce le thème de réflexion, et les participants, munis chacun de fiches autocollantes, expriment leurs besoins sans se concerter. 5.6.8. Le modèle de Kano Le principe du modèle de Kano est de grouper les caractéristiques d’un produit en fonction du degré de satisfaction qu’elles apportent aux utilisateurs. Et plus précisément, de chercher le rapport entre le degré de réalisation d’une caractéristique et le degré de satisfaction du client. Satisfaction utilisateur

Exigences de base

Les « plus »

Exigence réalisée

Exigence non réalisée

Indispensables

Insatisfaction utilisateur Figure 5.3. Le modèle de Kano

Chaque caractéristique du produit est alors rangée dans une catégorie : – indispensable (must have) : son absence crée de l’insatisfaction chez le client, mais leur présence n’apporte pas de satisfaction


87

outre mesure ; elles est souvent considérée comme évidente, donc passée sous silence lors d’une interview ; – exigence de base (more is better) : le niveau de satisfaction est proportionnel à la présence ou à la performance de la caractéristique ou de la fonction ; ce sont ces exigences qui émergent les premières lors d’une interview ou d’une enquête ; – un « plus » (delighter) : son absence ne crée pas de frustration particulière, mais sa présence apporte une satisfaction supplémentaire ; généralement, ces exigences n’émergent pas lors d’interviews ; ce sont les techniques de créativité qui permettent de les faire surgir. Le principe de la mise en œuvre consiste à demander au futur client utilisateur comment il réagirait si ce besoin était comblé et si le besoin n’était pas comblé, et de lui proposer, pour chaque question, quatre réponses possibles : « j’aime », « c’est normal de l’avoir », « je suis indifférent » et « je n’aime pas ». Les résultats sont consignés dans une matrice à quatre lignes et quatre colonnes, correspondant à ces quatre réponses aux deux questions. Ils permettent de déterminer, pour chaque besoin exprimé, s’il est indispensable, de base, ou constitue un « plus ». 5.6.9. Les matrices de priorité Les matrices de priorité sont des outils de négociation. Elles permettent de trouver un compromis entre différents besoins, et entre les manières de les satisfaire, en fonction de critères. Ces critères peuvent être le « poids » des différents interlocuteurs, l’importance d’un besoin, le coût, la charge ou le délai de développement, le bénéfice escompté, le risque estimé. Différents types de matrices de priorités existent et peuvent être mis en œuvre. Le modèle le plus simple établit une somme pondérée entre les différents besoins exprimés. Le modèle le

88


plus élaboré est apporté par une méthode rigoureuse et codifiée appelée QFD (pour quality function deployment), originaire du monde industriel. Cette méthode permet d’établir un lien entre les besoins et les fonctions, en déterminant les préférences des utilisateurs et les priorités entre ces préférences, et en les traduisant en exigences sur le produit. Elle fait appel à une série de matrices et de graphiques, utilisés tant pour le recueil que pour l’analyse des besoins. Mais les matrices sont aussi un outil de réflexion à usage collectif, stimulant la créativité au même titre que le remueméninges. Ce n’est pas tant le résultat qui compte, que le processus itératif et collaboratif permettant d’y arriver. 5.6.10. Les cas d’utilisation et les scénarios Les cas d’utilisation (use cases) sont un des meilleurs moyens de décrire les besoins des utilisateurs. L’idée est de décrire les interactions entre l’utilisateur et le système, avec la particularité de centrer la description sur l’utilisateur, et non sur le système. La description peut être de haut niveau, donnant une vision globale, ou être plus concrète et détaillée. UML et le processus unifié (UP, unified process) ont popularisé les diagrammes de cas d’utilisation (use case diagrams), mais cette représentation n’est pas la seule, ni la mieux adaptée à tous les cas. La description d’un cas d’utilisation peut très bien être textuelle. Dans le cas d’une description textuelle, celle-ci peut être réduite à une description simple (un ou plusieurs paragraphes) ou se présenter sous forme de fiche descriptive complète : acteurs, description du cas d’utilisation, conditions d’entrée, conditions de sortie, étapes du comportement normal, du comportement en cas d’erreur, etc.


89

Les cas d’utilisation peuvent être spécifiés lors de sessions de recueil de besoins réunissant la maîtrise d’ouvrage, des experts métier, un consultant et éventuellement un architecte ou un chef de projet. La difficulté des cas d’utilisation est de rester simple et centré sur le métier. On a tendance à décrire un trop grand nombre de cas d’utilisation, trop complexes, trop détaillés. S’ils ne sont pas compris des utilisateurs eux-mêmes, cela doit constituer un signal d’alarme. L’avantage des cas d’utilisation est de décrire les besoins avec la perspective de l’utilisateur. Ils doivent être « traduits » en exigences fonctionnelles qui, elles, mettent le système au centre de la description. 5.6.11. La modélisation des données, des traitements et des processus Modéliser les données, les traitements, les flux, les processus de l’entreprise est une pratique courante et indispensable. La littérature sur le sujet remplirait une bibliothèque entière. Nous ne nous y attarderons pas. Remarquons simplement que la modélisation peut avoir deux objectifs : modéliser les besoins, ou modéliser le système lui-même, existant ou à venir. Lors du recueil, de l’analyse et de la spécification des exigences, les trois approches sont utilisées : – modélisation du système existant (modèle de données, de traitements, de processus) dans le but de connaître le contexte (phase d’analyse de l’existant) ; – modélisation des besoins (diagramme de contexte, ce cas d’utilisations...) dans le but d’exprimer les exigences ; – modélisation du système futur (données, traitements, processus, flux) dans un but de validation des exigences.

90


5.6.12. Maquettes et prototypes Comme la modélisation, les maquettes et prototypes sont de bons outils de validation des exigences. Ils permettent aux différentes parties prenantes de réagir, de confronter leurs idées et d’en exprimer de nouvelles. Une maquette apporte une « vision » de l’application à venir, mais n’a pas d’existence réelle. Il peut s’agir d’un simple dessin sur un papier ou sur un tableau. Au contraire, un prototype est censé être extensible jusqu’à devenir une véritable application. Un prototype peut être « horizontal », par exemple en présentant uniquement l’interface graphique d’une application, ou « vertical », en mettant en œuvre une seule fonction dans sa totalité (interface utilisateur, comportement). Contrairement à la maquette, qui est jetable, un prototype est réutilisable. Le développement d’un prototype ne fait pas à proprement parler partie de la phase de définition des besoins. Il opère une « incursion » utile dans les phases suivantes. Le danger d’un prototype est de donner l’impression à certains utilisateurs que le développement est « presque fini », alors qu’il ne vient que de commencer. 5.6.13. Mixage des techniques, précautions à prendre Parmi les techniques exposées, il n’y en a aucune qui soit meilleure que les autres. Chacune a son utilité en fonction du métier du client, du profil des interlocuteurs, et du niveau de maturation dans l’élaboration des exigences. Le consultant chargé de les mettre en œuvre dispose de toute une palette d’outils, toute une gamme de méthodes sur laquelle il peut jouer. En règle générale, il utilisera d’abord les méthodes créatives, permettant de cerner globalement le besoin, et « descendra » progressivement vers les méthodes plus rigoureuses.


envies souhaits Besoins vagues, implicites, sous-entendus voeux pieux prototypes réunions

brainstorming maquettes interviews modèles

matrices formalisation Spécification des exigences

Figure 5.4. Des besoins aux exigences, de la créativité à la précision

91

CHAPITRE 6

Sept critères d’ergonomie

6.1. Qu’est-ce que l’ergonomie ? L’ergonomie est l’étude des situations de travail et des relations entre l’être humain et un système. Elle concerne ce qu’il est convenu d’appeler l’interface homme-machine (IHM) ou l’interface personne-système (IPS). Son objectif est d’améliorer le confort, voire le plaisir, de l’utilisateur et par voie de conséquence l’efficacité dans le travail et dans l’utilisation d’un produit (en l’occurrence, un logiciel). Cette démarche a été pratiquée de tout temps de manière empirique. Mais c’est à partir de la Seconde Guerre mondiale, avec la complexité croissante des produits, que l’ergonomie s’est développée en tant que discipline scientifique. D’abord mise en œuvre dans le secteur militaire, elle a progressivement touché tous les secteurs de l’industrie. Les pays anglo-saxons et scandinaves ont été des précurseurs. Dans l’industrie du logiciel, la première grande avancée significative a été obtenue dans les années 1970, sous l’influence des recherches effectuées au centre de recherches de Xerox à

94


Palo Alto, en Californie. Première grande avancée, et peut-être la plus importante, car les éditeurs de logiciel se sont trop souvent par la suite contentés, dans le meilleur des cas, de copier les innovations des concurrents, et dans le pire, de singer les concurrents en ne conservant, de l’ergonomie, que la façade. Des options telles que le choix dans un menu, l’environnement multifenêtré, l’utilisation des dispositifs de pointage (souris, écran tactile) sont actuellement totalement banalisés sur tous les systèmes d’exploitation, ainsi que sur la plupart des applications. Il n’y a eu, cependant, que très peu de réelles innovations de la part des éditeurs de logiciel. Rendons grâces cependant aux travaux théoriques et méthodologiques accomplis dans le domaine de l’ergonomie du logiciel, en particulier les travaux de SCAPIN, qui ont débouché sur l’énoncé de règles d’ergonomie, et qui se retrouvent dans la norme AFNOR sur l’ergonomie du logiciel. 6.2. Ergonomie : la qualité vue de l’utilisateur Un logiciel ergonomique est très liée à ce que l’on appelle la qualité de fonctionnement (en anglais, quality in use). Celle-ci se définit par quatre critères : – l’efficacité, capacité du logiciel à permettre aux utilisateurs d’atteindre leurs objectifs avec exactitude et exhaustivité ; – la productivité, de optimiser le temps et l’effort à l’utilisateur ; – la sécurité (ou innocuité), capacité du produit logiciel à limiter les risques sur la santé, les activités ou l’environnement des utilisateurs, en particulier suite à une défaillance1 ;

1. Le mot innocuité, (au sens anglais de safety, par opposition à security) est ici plus approprié que sécurité.


95

– la satisfaction, qui correspond à une attitude positive de l’utilisateur lors de l’interaction avec le produit. L’ergonomie aura pour conséquence la facilité d’utilisation du produit, ou utilisabilité (en anglais, usability). Un produit facile à utiliser présentera les cinq caractéristiques suivantes2 : – il est facile à comprendre ; – il est facile à apprendre ; – il est facile à utiliser au quotidien ; – il est attirant pour l’utilisateur ; – il respecte les normes, conventions, guides de style relatifs l’ergonomie. 6.3. Les sept règles d’ergonomie La norme AFNOR Z-67 133-1 définit l’ergonomie du logiciel par sept critères : – la compatibilité ; – le guidage ; – l’homogénéité ; – la souplesse ; – le contrôle explicite ; – la gestion des erreurs ; – la concision. Ces sept critères sont très utiles, non seulement pour définir l’ergonomie, mais aussi pour construire des applications et des systèmes conviviaux.

2. Les cinq points cités ci-dessous correspondent aux cinq sous-caractéristiques de la facilité d’utilisation selon la norme ISO 9126.

96


6.3.1. Compatibilité La compatibilité est la capacité à s’intégrer dans l’activité des utilisateurs. Elle concerne l’accord pouvant exister entre les caractéristiques professionnelles et psychologiques de l’utilisateur (mémoire, perceptions, habitudes, etc.) et l’organisation du dialogue entre l’utilisateur et l’application. La compatibilité implique que le logiciel soit étudié pour s’adapter aux besoins de ses utilisateurs, et en particulier au métier de chaque catégorie d’utilisateur. Il doit intégrer non seulement les procédures, mais aussi la psychologie et la physiologie de l’utilisateur ; par exemple : l’utilisation de la souris est exclue pour les utilisateurs faisant de la saisie de masse, alors qu’elle est nécessaire pour les utilisateurs faisant des sélection de quelques articles parmi des dizaines. Ceci nécessite une analyse de la tâche des utilisateurs bien avant la phase de réalisation du logiciel. Sur les applications spécifiques, lorsque la logique du métier de l’utilisateur n’est pas analysée avec suffisamment de finesse, la compatibilité est souvent médiocre. En conséquence, le temps d’apprentissage sera souvent beaucoup plus long que prévu. En outre, l’obligation, pour l’utilisateur, de s’adapter au symbolisme ou au langage du logiciel génère beaucoup de stress. 6.3.2. Guidage Le guidage est l’ensemble des moyens mis en œuvre pour conseiller, orienter, informer et conduire l’utilisateur lors de ses interactions avec l’ordinateur.


97

On distingue : – le guidage explicite, qui se traduit par l’aide en ligne, les messages d’erreur, d’avertissement ou d’information ; – le guidage implicite, qui concerne les formats de saisie des informations, la disposition des informations sur l’écran, etc. La notion de guidage est liée à celle de navigabilité. Le terme est aisément compréhensible pour les applications de type intranet, mais ne se limite pas à ce type d’application. Quel que soit le logiciel, l’utilisateur doit savoir à tout moment où il se trouve (dans son parcours de l’application), où en est le déroulement d’une tâche, ce qu’il doit faire pour changer d’activité avec le moins d’effort et de charge mentale, comment il peut sortir de la tâche et de l’application, et comment revenir à la tâche précédente. La plupart de ces caractéristiques sont déjà sous-jacentes sur les navigateurs web, mais elles sont nécessaires pour tout type d’application. Cependant, lors de la réécriture d’applications anciennes, les développeurs sont tentés par deux solutions de facilité, tout aussi fâcheuses : reprendre à l’identique la logique de l’ancienne application (très souvent, un enchaînement d’écrans suivant une logique arborescente), ou laisser l’utilisateur naviguer sans lui permettre de se situer dans l’application, sans lui fournir une « carte du terrain ». A l’inverse, lorsque le besoin de guidage est pris en compte en amont, une logique hypertexte peut apporter énormément de confort à l’utilisateur. 6.3.3. Homogénéité L’homogénéité est la capacité d’un système à conserver une logique d’usage constante. Elle se réfère à la façon avec laquelle des choix d’objets de l’interface sont conservés pour des

98


contextes identiques, et des objets différents pour des contextes différents. L’homogénéité n’est pas seulement de surface. Elle s’applique aussi bien à la localisation d’un objet sur l’écran, à son format et sa présentation, mais aussi à la syntaxe et la dénomination. Les écrans de saisie et la logique des actions doivent être analogues dans toute l’application, et même, si possible, d’une application à l’autre. De cette manière, les applications sont faciles à apprendre, l’effort de mémoire est réduit. Cette caractéristique ne peut pas être ajoutée après coup. Elle doit être pensée globalement, et donc préparée en amont, lors de la conception, ou mieux, lors de la définition des exigences. Par ailleurs, avec une telle démarche, le coût de la mise en œuvre de l’ergonomie est bien moindre. Faute de moyens pour mener une étude approfondie des besoins d’un ensemble spécifique d’utilisateurs, la meilleure façon de mettre en œuvre l’homogénéité dans une application est de disposer d’une charte d’ergonomie. Autre conséquence de cette démarche : la mise en œuvre de règles de « bonne ergonomie » et d’esthétique des applications. Le mieux serait évidemment d’obtenir une homogénéité interapplications. Ceci peut être obtenu grâce à une charte d’ergonomie commune à toute une catégorie d’applications. Remarquons que de nombreux outils de développement (les générateurs d’application) permettent la mise en œuvre automatique (au moins partiellement) des recommandations d’une charte. Une homogénéité entre applications, outre ses avantages ergonomiques, renforce également l’image qu’une entreprise envoie aux utilisateurs.


99

6.3.4. Souplesse La souplesse est la capacité de l’interface à s’adapter aux différentes exigences de la tâche, aux diverses stratégies, aux habitudes et niveaux de connaissances des différents utilisateurs. Contrairement à la compatibilité, qui revient à adapter d’avance le logiciel aux différents profils utilisateurs, la souplesse permet à un logiciel de s’adapter à ses habitudes, ainsi qu’à son expérience, son niveau d’expertise, par exemple en fournissant plusieurs manières d’obtenir le même résultat : raccourcis clavier pour les utilisateurs experts, menus pour les débutants, possibilité de chaîner plusieurs commandes (macrocommandes) pour automatiser des tâches répétitives. Les outils bureautiques actuels, produits grand public, sont souvent très souples : une même commande peut être obtenue par un click sur une icône, par un choix dans menu, ou par un raccourci au clavier. Les applications spécifiques, en revanche, manquent souvent de souplesse en raison même de leur caractère spécifique : elles sont conçues pour un métier, après étude des besoins des différents utilisateurs. La souplesse, c’est aussi l’aptitude d’un logiciel à être paramétré par l’utilisateur. Dans ce cas, elle peut être antagoniste avec l’homogénéité : si tout paramétrage est possible, alors tous les postes seront différents. De plus, elle peut apporter une et complexité superflue (certains paramétrages ne seront jamais utilisés). Sur ce point, un compromis doit être fait. La souplesse sied mieux aux logiciels sur étagère, pour lesquels le paramétrage est nécessaire qu’aux logiciels spécifiques, qui doivent être bien adaptés à une population précisément définie.

100


6.3.5. Contrôle explicite Le contrôle explicite est l’ensemble des moyens du dialogue qui permettent à l’utilisateur de maîtriser le lancement et le déroulement des opérations exécutées par le système informatique. Il est lié à la maîtrise qu’a l’utilisateur sur l’interface ou le logiciel, et également aux informations que le système fournit à l’utilisateur sur les actions qu’il entreprend. En d’autres termes : – c’est à l’utilisateur de contrôler le déroulement du logiciel et non l’inverse ; – le logiciel doit réagir de manière prévisible. Le contrôle explicite est très important pour l’utilisateur, car il lui donne de l’autonomie et une sensation de contrôle sur l’application, et par conséquent facilite l’appropriation de l’outil par l’utilisateur. La sensation d’être contrôlé et manipulé par le logiciel génère du stress et provoque des réactions de rejet. La règle du contrôle explicite est trop souvent négligée : phrases incohérentes, actions opaques à l’utilisateur, actions imprévues dans le comportement de l’application. 6.3.6. Gestion des erreurs La gestion des erreurs rassemble tous les moyens permettant d’une part d’éviter ou de réduire les erreurs, et d’autre part de les corriger lorsqu’elles surviennent. Le logiciel doit protéger l’utilisateur contre les erreurs : – possibilité d’annuler une action (touche undo) ;


101

– demande de confirmation des actions dont les effets sont irréversibles ; – messages d’avertissement. Une bonne gestion des erreurs diminue le stress et donne confiance à l’utilisateur. Savoir qu’une action peut être annulée permet de se concentrer sur l’important. La mise en œuvre de ces mécanismes n’est pas toujours aisée. Ici, un guide de conception d’applications ergonomiques, à l’usage des équipes de développement, peut être fort utile. 6.3.7. Concision La concision est l’ensemble des moyens qui, pour l’utilisateur, contribuent à la réduction de ses activités de perception et de mémorisation et concourent à l’augmentation de l’efficacité du dialogue. La concision accélère le travail de l’utilisateur. Cependant, sa vraie valeur réside dans la diminution de la charge mentale et, par voie de conséquence, de la fatigue et du stress. Minimiser le nombre de menus et de clics n’optimise pas seulement le temps, mais aussi la disponibilité de l’utilisateur. Le principe de concision est souvent mis en œuvre, du moins en surface : cases à cocher, icônes et boutons sont largement utilisés dans les applications actuelles. Cependant, leur utilisation systématique ne garantit pas à elle seule la concision. Nombreuses sont aujourd’hui les applications manquant de concision, qui noient l’utilisateur sous des détails en lui offrant beaucoup plus de possibilités que celles réellement utiles à son travail. Les environnements de développement actuels donnent

102


trop de possibilités aux développeurs. Encore une raison pour avoir une charte d’ergonomie et la faire appliquer. 6.4. L’application des principes d’ergonomie à la construction du logiciel Quand faut-il faire appel à un ergonome ? Cela dépend de : – la taille du projet ; – de la criticité du produit à développer ; – de la complexité des interactions homme-système. Sur un projet complexe et critique (dans le domaine militaire, spatial, nucléaire) l’intervention d’un ergonome est presque toujours requise. Sur un petit projet à faible criticité, il est nécessaire et suffisant d’appliquer intelligemment les règles d’ergonomie. Dans une grande entreprise où de nombreux logiciels sont développés, il est utile de développer deux documents : – d’une part, une charte d’ergonomie ; décrivant ce qui est à faire et à ne pas faire ; – d’autre part, un guide de conception, à l’usage des concepteurs et développeurs. Ici comme ailleurs, nous préconisons la mise en application des principes du design logiciel : simplicité et clarté, démarche participative dans la recherche de solutions, vision globale. Mais avant tout, et plus que partout ailleurs, communication avec l’utilisateur pour connaître ses véritables besoin, traduction de ces besoins en exigences claires et précises, et suivi de la mise en application de ces exigences. Parmi les divers moyens de valider que les besoins des utilisateurs ont été bien compris, bien spécifiés, bien interprétés


103

et mis en œuvre, les maquettes et les prototypes constituent des outils privilégiés. Souvent, des maquettes très simples, des dessins d’écran sur papier, suffisent. Maquettes et prototypes permettent, par itérations successives, de faire entrevoir l’application aux utilisateurs, de les faire réagir et de recueillir de nouveaux besoins. Seul l’utilisateur pourra dire si ses habitudes de travail sont respectées. De plus, une maquette permet de contrôler, au moyen de check-lists, si tous les critères d’ergonomie sont respectés.

CHAPITRE 7

Le cahier des charges : élaboration

7.1. L’utilité du cahier des charges Comme nous l’avons vu dans les chapitres précédents, le cahier des charges n’est pas l’unique moyen de présenter l’expression des exigences. Mais il demeure, au moins en France, le moyen privilégié, utilisé dans de nombreux cas, en particulier par les administrations et les grandes entreprises. La première version du cahier des charges, élaborée avec le plus grand soin, doit constituer une référence (une baseline), un point de départ sur lequel on va construire. C’est à ce document de référence que la maîtrise d’œuvre devra se tenir et qui constitue le cadre contractuel. Et cela même si, (et surtout si) le développement se fait « en interne ». Bien entendu, il faut savoir gérer (tant bien que mal) les évolutions des exigences, et se préparer à cela. Les évolutions devront être notées, consignées dans une nouvelle version, qui deviendra à son tour la nouvelle référence. Mais pour éviter ce que l’on appelle les « spécifications rampantes » (les exigences

106


qui évoluent sans pouvoir être gérées), le cahier des charges constitue un bon outil. Lorsque la maîtrise d’œuvre est immature, qu’elle sait mal gérer les évolutions des spécifications, alors le cahier des charges devient primordial. C’est le seul outil opérationnel permettant au client de piloter efficacement son fournisseur. 7.2. Producteurs et consommateurs des exigences Les exigences, qu’elles soient présentées sous forme de cahier des charges ou sous une autre forme, sont un élément central de la construction du logiciel. Un grand nombre de personnes vont devoir le lire et l’appliquer, partiellement ou dans sa totalité. Voici une liste non exhaustive des interlocuteurs qui devront s’y pencher : – le client, maître d’ouvrage ou donneur d’ordres (dans le cas d’une application spécifique) ou le département marketing (dans le cas d’un logiciel mis sur le marché) qui vont se référer au cahier des charges ; le document peut être contractuel ou non, mais il constitue, en tout état de cause, une référence ; – les sous-traitants, prestataires et autres fournisseurs, qu’ils soient internes ou externes à l’entreprise ou à l’organisation qui a élaboré le cahier des charges ; – les juristes : ceux du fournisseur comme ceux du client ; – l’architecte, le concepteur, et l’équipe de développement, qui vont devoir mettre en œuvre chacune des exigences ; – le chef de projet, qui doit planifier, estimer ou faire estimer les charges, déterminer et négocier les délais de réalisation en fonction des exigences ; – l’équipe de test, qui va développer un cahier de tests en fonction du cahier d’exigences ;


107

– l’équipe de maintenance, qui devra gérer les évolutions et les non-conformités ; – l’équipe de support qui, avant l’équipe de maintenance, va affronter le client ou l’utilisateur, et vérifier s’il s’agit bien d’une non-conformité, ou au contraire d’une demande d’évolution, en se référent aux exigences ; – l’équipe de documentation, pour documenter le produit et vérifier l’exhaustivité de cette documentation ; – le formateur, qui va appuyer, en particulier, sur le document des exigences pour construire son support de formation. 7.3. Centrer le projet autour du cahier des charges Il est possible de structurer le pilotage des phases amont d’un projet de développement autour de la création et de la tenue à jour du cahier des charges, qui devient ainsi le fil directeur du projet. Cette démarche présente les avantages suivants : – simplicité et efficacité. La démarche repose sur un document central, véritable outil de communication entre les acteurs du projet ; – structuration des idées et des activités. Le document respecte un sommaire qui couvre les différents aspects du projet. Ce sommaire constitue un guide pour le recueil et l’analyse des besoins, la définition fonctionnelle et les orientations de solution. Il permet de contrôler la couverture et la progression de tous les aspects, au fur et à mesure de l’avancement du projet ; – optimisation des travaux de pilotage. Au cours des premières phases du projet, on peut enrichir le cahier des charges de façon continue, ce qui réduit l’effort de rédaction et de validation. Le document change de version au cours du projet, en passant d’un état exploratoire à un état provisoire, puis de référence.

108


Le cahier des charges permet ainsi la construction de la qualité : – le contrôle de la qualité du cahier des charges pour ainsi dire en temps réel ; – les priorités précisément déterminées, maîtrise d’ouvrage et maîtrise d’œuvre disposant d’un vocabulaire commun et non ambigu ; – le dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre est plus fluide, le modèle de cahier des charges, puis les versions successives de celui-ci servant de support à ce dialogue. 7.4. Présentation de la démarche La démarche d’élaboration du cahier des charges, exposée ici, peut faire appel à plusieurs techniques de recueil, d’analyse, ou de négociation des exigences (avant d’être transmises, elles doivent être négociées en interne, chez le client). Nous avons décrit plusieurs de ces techniques au chapitre 5. Nous ne décrirons ici que l’enchaînement des techniques nécessaires à l’élaboration d’un cahier des charges.

Lancement

Analyse de l’existant

Construction des scenarios fonctionnels

Rédaction du CdC

Plan de l’étude

Insatisfactions, dysfonctionnements

Choix du scenario

Cahier des Charges

Définition de l’objectif

Proposition d’amélioration

Révision de l’organisation

Validation du CdC

Principes de fonctionnement

Axesd’ Axes évolution d’évolution

Principesd’ Principes d’organisation organisation

Cahier des Charges validé

Figure 7.1. Synoptique de la démarche


109

Ce synoptique montre l’enchaînement des étapes nécessaires à l’élaboration d’un cahier des charges, en indiquant les sorties de chacune d’elles. 7.5. Lancer le projet d’élaboration du cahier des charges Première étape : définir les rôles des différents acteurs impliqués dans l’élaboration d’un cahier des charges : – qui prend les décisions (lancement, suivi, validation) ? – qui pilote la réalisation du cahier des charges ? – qui assure le travail quotidien (animation, collecte, rédaction) ? – qui participe à son élaboration : représentants des utilisateurs, maître d’ouvrage, experts… ? – qui est sollicité pour fournir ses conseils (expertise du domaine, faisabilité des solutions informatiques) ? 7.5.1. Constituer l’équipe de préparation du cahier des charges La décision de lancer un cahier des charges est prise au niveau hiérarchique responsable du domaine de gestion. Une lettre de mission indique au chef de projet les moyens accordés (disponibilité, délais, autorité). Pour les projets importants, le chef de projet du cahier des charges est assisté des correspondants des domaines fonctionnels. Il fait intervenir des experts des différents domaines impactés, et recourt, éventuellement, aux conseils d’experts informatiques pour s’assurer de l’existence et du coût des solutions informatiques.

110


7.5.2. Prévoir, suivre et contrôler l’étude Cette étape consiste à structurer les tâches nécessaires à la création du cahier des charges, à mettre en place un processus continu de validation, et à effectuer une planification prévisionnelle. 7.5.3. Choisir les moyens Cette étape consiste : – d’une part à informer, et si nécessaire former les membres de l’équipe d’élaboration du cahier des charges, soit sur le plan technique, méthodologique (techniques de modélisation) ou « métier » (approfondissement des règles de gestion) ; – d’autre part à mettre en place l’infrastructure du projet de rédaction du cahier des charges : locaux, communications, outils bureautiques, et si nécessaire assistance externe. 7.6. Spécifier l’objectif On reprendra ici les résultats de la phase « objectifs » en les structurant et en les résumant si nécessaire. 7.6.1. Définir les finalités de l’application Qu’attend-on de la réponse au cahier des charges ? L’automatisation d’un processus ? Une aide à la décision ? Une aide aux opérations ? La gestion des connaissances ? Il est important que les finalités du système à venir soient définies et spécifiées par écrit. D’autre part, la nature de la ressource à gérer doit être identifiée : quels produits (matières, finances, informations) ; par quelles modalités d’échanges (commandes, livraisons, facturations,


111

règlements) ; quels tiers émetteurs et destinataires (clients, fournisseurs, unités internes). Enfin, les acteurs concernés et les changements attendus doivent être également spécifiés : qui est concerné, et quelle sera son évolution. Pour ces deux derniers points, les techniques d’analyse des parties prenantes seront fort utiles. 7.6.2. Déterminer les limites et les interfaces de l’application Les limites s’expriment en termes de données (données permanentes et mouvements de données), et de traitements. Toutes les interfaces avec le monde extérieur (interface utilisateur, interfaces avec le système d’exploitation, avec les autres applications) doivent être définies, sans entrer dans les détails. 7.6.3. Indiquer les contraintes On distingue, d’une part les contraintes liées au respect de l’environnement : – conservation, partielle ou totale, de l’organisation existante ; – conservation de matériels informatiques installés ; – adaptation des personnes au changement ; – cadre budgétaire du fonctionnement de la future solution ; – investissements, dépenses d’exploitation et de maintenance. Et d’autre part, les contraintes liées aux propriétés non fonctionnelles de l’application : – performance (temps de réponse, volumes) ; – sécurité (sûreté de fonctionnement, protection) ; – aptitude à l’évolution et à la maintenance.

112


7.6.4. Déterminer les domaines fonctionnels Ce découpage s’effectue selon les recommandations du schéma directeur, de la stratégie de l’organisation, ou selon la structure fonctionnelle du service. Insistons encore une fois sur le fait qu’il ne s’agit pas d’un découpage technique. Il ne s’agit pas de découper a priori l’application en composants, mais de déterminer les grandes fonctions et de les regrouper par domaines fonctionnels. 7.7. Analyser l’existant Lors de cette phase sont analysées et structurées les informations nécessaires provenant de la collecte des informations : documents existants, rapports d’enquêtes, questionnaires établis par un enquêteur... Pour analyser et représenter l’existant, il est important, dans un premier lieu, de définir la maille de l’étude, c’est-à-dire le niveau de détail des informations, qui doit être homogène sur toute l’étude. On représente sous une forme conventionnelle les différents aspects du système. Par exemple : statique (modélisation des données, diagrammes de classes), dynamique (schéma d’organisation), transformation (modélisation des traitements). 7.7.1. Recueillir les informations Les interviews sont évidemment le moyen le plus classique de recueil de l’information. Les personnes à interviewer sont choisies selon leur niveau de représentativité, leur niveau hiérarchique ou leur degré d’adhésion au changement. Il est important d’interviewer, non seulement ceux qui sont « moteurs », mais également les « suiveurs » et les « résistants ».


113

Toutes les autres techniques de recueil d’information peuvent être utilisées, en fonction du type d’application à construire, de l’existant, de la sociologie de l’organisation dans laquelle on travaille. Les visites sur site avec démonstration de l’application existante, ainsi que la lecture des documents (schéma directeur, procédures, documentation de l’application existante) sont des moyens simples et efficaces, souvent utilisés. Selon les circonstances, d’autres techniques, comme le brainstorming, les réunions de travail conjointes entre fournisseur et client, peuvent être efficaces. 7.7.2. Analyser et quantifier les informations La description du système actuel s’effectue selon plusieurs vues. Pour un problème donné, il faut décrire les vues associées à l’évolution envisagée : – vue de l’organisation : organigramme des fonctions ; qui fait quoi ? quand et où ? flux des informations échangées ; définition des procédures ; quantification des ressources ; – vue des fonctions : liste des activités ; règles de gestion ; modélisation conceptuelle, organisationnelle, logique et physique des traitements ; – vue des données : recensement des données du système ; données primaires ; – données secondaires calculées à partir des données primaires ; modélisation conceptuelle, organisationnelle et, logique des données ; – vue technique : fichiers des données existantes ; description des traitements conversationnels et automatiques ; ressources matérielles et logicielles.

114


7.7.3. Modéliser le système actuel Pour permettre une communication sans ambiguïté sous une forme compacte, le système peut être modélisé sous forme graphique : – diagramme de processus, diagramme fonctionnel (flux entre les acteurs), modèle conceptuel de traitements... – diagramme de classes, modèle conceptuel de données, dictionnaire de données. 7.8. Proposer des améliorations Le recueil des conclusions des interviews permet de classer les principaux reproches exprimés vis-à-vis de la solution actuelle (on trouvera une liste non limitative dans le guide de rédaction). L’analyse de ce recueil permet de suggérer des améliorations quantitatives et qualitatives. 7.8.1. Remédier aux dysfonctionnements On identifiera, dans chaque domaine : – les principes ou méthodes à remettre en cause ; – les facteurs de qualité administrative à revoir ; – les insuffisances en termes d’informations. Les objectifs, issus de ces critiques, seront retenus et portés dans le cahier des charges. 7.8.2. Fixer les objectifs d’évolution On définira les perspectives d’évolution de l’environnement : – principes et méthodes de gestion ; – principes et méthodes d’organisation ;


115

– nouveaux besoins ; – croissance des volumes ; – modernisation des systèmes informatiques. On hiérarchisera et formalisera ces objectifs, en s’assurant de leur bonne compréhension, et en les faisant valider. 7.8.3. En déduire les caractéristiques du système cible Cela consiste à dresser une liste des fonctions à assurer. Dans un premier temps, chaque fonction peut être définie par une simple phrase : un verbe à l’infinitif et un complément. Par exemple : – gérer les inscriptions des élèves ; – gérer les emplois du temps ; – gérer la répartition des élèves dans les classes ; – gérer les notes des élèves. Comme on le voit, il ne s’agit pas d’entrer dans les détails, et encore moins de décomposer le système en fonctions au sens informatique du terme. 7.9. Réviser l’organisation Pour être efficace, une évolution du système d’information doit s’accompagner d’une évolution parallèle de l’organisation. L’expérience montre que cette nécessaire évolution organisationnelle est la règle et non l’exception. Même avec un logiciel spécifique « sur mesures ». Il faut proposer une structure organisationnelle et motiver le personnel pour s’assurer de son adhésion au changement : – standardisation des procédures ;

116


– révision des formulaires ; – intégration des contraintes réglementaires. 7.9.1. Identifier les conditions du changement L’introduction d’un nouveau système ne va produire les changements escomptés que si l’organisation est préparée pour accueillir ce système. Pour cela il est nécessaire : – de formuler des hypothèses de structure d’organisation ; – de déterminer les profils des acteurs (compétences et comportement) ; – de s’assurer de la cohérence avec les règlements externes et internes. 7.9.2. Choisir les conditions de réalisation Il s’agit ici de définir les moyens de développement de la solution. Qui va la développer ? La direction des systèmes d’information ? Un sous-traitant ? La réponse à ces questions ne relève pas nécessairement du cahier des charges, qui définit les exigences, et non la solution. Ces questions doivent néanmoins être posées, car elles déterminent les conditions de l’appel d’offres, ou de toute procédure équivalente. 7.9.3. Construire le scénario 7.9.3.1. Découper en groupes de fonctions Il s’agit ici de regrouper les fonctions par domaines fonctionnels et de décrire l’enchaînement des fonctions dans un domaine de gestion. La difficulté est de décrire les fonctions du point de vue


117

de l’utilisateur ou du maître d’ouvrage, sans tomber dans la technique. L’exercice est plus difficile qu’il n’y paraît. 7.9.3.2. Intégrer les caractéristiques de chaque fonction Pour chaque fonction, il va falloir : – exprimer la finalité ; – indiquer les éléments d’entrée (données, déclencheurs) ; – formaliser les règles de gestion (contrôles, périodicité, interdictions) ; – définir l’organisation des traitements ; – donner les éléments de sortie (liste des résultats) ; – présenter les contraintes techniques. 7.9.3.3. Intégrer les caractéristiques non fonctionnelles Les caractéristiques non fonctionnelles peuvent être : – liées à une fonction particulière ; par exemple, temps de réponse d’une fonction donnée ; – liées à un groupe de fonctions ; – générales à l’application ; c’est le cas des règles d’utilisabilité (ergonomie). L’étude et l’intégration dans un cahier des charges des caractéristiques non fonctionnelles est un exercice beaucoup plus difficile qu’il n’y paraît. Pour la structuration des caractéristiques non fonctionnelles, on pourra utiliser la norme ISO 9126 sur la qualité du logiciel [CON 01]. Il s’agit là d’une bonne base, pouvant être adaptée aux contraintes propres de l’entreprise. 7.9.3.4. Faire le bilan prévisionnel Cette opération évalue les enjeux économiques en comparant : – les gains attendus par le nouveau système ;

118


– les bénéfices directs, par rapport à la solution antérieure ; – les bénéfices relatifs, par des gains de productivité ; – les bénéfices induits, par les conséquences sur les autres activités ; … aux coûts entraînés par sa mise en œuvre : développement, exploitation, maintenance. Il est intéressant de signaler les avantages qualitatifs attendus tels que l’amélioration de l’image de marque, l’acquisition de savoir-faire, etc., si possible en les quantifiant. 7.9.3.5. Choisir le meilleur scénario Après avoir comparé les conséquences de plusieurs hypothèses, on détermine le scénario qui sera soumis au fournisseur, selon les critères suivants : – amélioration du service rendu ; – simplification de l’organisation ; – maîtrise des technologies envisagées ; – protection des facteurs humains ; – respect des contraintes financières. 7.9.4. Structurer et rédiger le cahier des charges Il s’agit maintenant de regrouper les éléments recueillis et élaborés pendant le projet, de vérifier leur complétude et leur cohérence, de les mettre en forme selon le plan type choisi, en observant les recommandations générales. Le chapitre suivant est entièrement consacré à la structuration et à la rédaction du cahier des charges et donne des exemples de plans de cahiers des charges.


119

7.9.5. Valider le cahier des charges Avant de transmettre le cahier des charges aux fournisseurs potentiels, le chef de projet du cahier des charges réunit l’ensemble des acteurs afin de valider le document. L’outil de base pour la validation est très simple : une revue du document basée sur une check-list. La section suivante de ce chapitre donne une liste non exhaustive de défauts qui devraient être éliminés de tout cahier des charges, et qui peut être utilisée pour constituer une checklist. Cette check-list sera d’autant plus efficace qu’elle sera connue et utilisée, non à l’issue de la rédaction, mais tout au long de la constitution du document. Le cahier des charges doit être considéré comme un produit, dont la qualité doit être contrôlée tout au long du projet. Bien entendu, le cahier des charges sera à son tour « validé » par la maîtrise d’œuvre sous forme de réponse, qui peut prendre des formes très diverses : dossier d’architecture, spécifications fonctionnelles générales, maquette, voire prototype. Mais laisser à la maîtrise d’œuvre l’initiative de sa validation, sans s’occuper de la qualité du cahier des charges en tant que « produit livré » serait fort imprudent. 7.10. Les défauts fréquents sur un cahier des charges Un bon cahier des charges ne doit contenir que les indications nécessaires et suffisantes, sous une forme claire et précise. On constate cependant que des défauts bien identifiés apparaissent fréquemment.

120


7.10.1. La description technique On ne le répètera jamais assez, la description de la solution technique, en lieu et place de la description de l’exigence fonctionnelle, est un grave défaut pour un cahier des charges. 7.10.2. Les contradictions Plusieurs définitions incompatibles d’une même caractéristique dans différents paragraphes du cahier des charges, des exigences incompatibles entre elles, les cas de contradictions ne manquent pas. 7.10.3. Les ambiguïtés Un style de rédaction ambigu est un style qui permet plusieurs interprétations possibles. C’est en particulier le cas de la « langue de bois » : chacun comprend ce qu’il veut bien comprendre. Les ambiguïtés apparaissent lorsque la personne chargée de recueillir les besoins n’est pas sûre d’avoir compris, et fait du flou, ou lorsque l’on veut faire plaisir à tout le monde. Laisser une ambiguïté dans le cahier des charges, c’est laisser le maître d’œuvre prendre des décisions à la place du maître d’ouvrage, avec des conséquences qui peuvent être importantes sur les coûts, les délais et la qualité du logiciel. Bien entendu, un maître d’œuvre averti relèvera les ambiguïtés et demandera des éclaircissements. Mais un calcul de probabilités permet de voir que si, par exemple, une ambiguïté a neuf chances sur dix d’être levée, il suffit qu’un texte en cumule sept pour que celui-ci ait une « chance » sur deux de comporter une ambiguïté résiduelle après relecture. Une telle ambiguïté peut coûter fort cher.


121

7.10.4. Le bruit Un cahier des charges doit être conclusif : rien à ajouter, rien à retrancher. Tout élément du texte n’apportant aucune information sur le problème à résoudre constitue un élément de bruit. 7.10.5. Le silence Des éléments de l’énoncé du problème à résoudre sont passés sous silence, sans que l’on sache s’ils sont laissés à l’initiative du fournisseur ou simplement oubliés. Rappelons pas un principe fondamental de la qualité : ce qui est évident pour les uns ne l’est pas pour les autres. Les silences sont fréquents dans les cahiers des charges, lorsque le demandeur suppose que les fournisseurs ont tous le même niveau d’information que lui. 7.10.6. La sur-spécification On ne doit spécifier que ce qui est spécifique. Mais où s’arrête la spécificité ? De peur de ne pas être compris du lecteur, les rédacteurs ont tendance à ajouter des détails dans lesquels le lecteur risque de se perdre. Comme toujours, l’art du rédacteur consiste à se mettre à la place de celui qui relira. Pour éviter de sur-spécifier, il est important de structurer le document selon une approche descendante et, dans le cas de rédacteurs multiples, de bien découper le travail d’élaboration. Dans cette perspective, un bon modèle de cahier des charges constitue une aide précieuse. 7.10.7. Les références en avant Les références en avant (considérer comme acquises les caractéristiques qui n’ont pas encore été définies et qui seront

122


décrites plus loin dans le texte) rendent le texte difficile à comprendre et à traiter. 7.10.8. Le vœu pieux Le vœu pieux caractéristique : une exigence non fonctionnelles dépourvue de critère d’appréciation. Ecrire que l’application doit être « fiable » ou « ergonomique » n’a aucun sens dans un cahier des charges. Rappelons que toute exigence doit être testable. La fiabilité peut être spécifiée par le temps total d’indisponibilité (annuelle, mensuelle, journalière, etc.). Pour spécifier le caractère ergonomique d’une application, on peut imposer le respect d’un guide de style, d’une charte graphique, ou de règles d’ergonomie particulières. 7.11. Conseils pratiques et précautions à prendre 7.11.1. Prise en compte de l’état de l’art Spécifier un produit, c’est définir avec précision ses caractéristiques. Pour éviter des descriptions trop lourdes, il est conseillé de ne décrire que les caractéristiques particulières. Pour les caractéristiques générales, l’usage veut qu’on s’en remette à l’état de l’art. D’une manière générale, on ne spécifie que ce qui est spécifique. Par exemple, lorsque le client exige une documentation technique, le cahier des charges définit ses caractéristiques particulières : plan, volume, thèmes à aborder, niveau de détail. Mais le cahier des charges ne spécifie pas les caractéristiques générales d’une documentation technique, qui relèvent de l’état de l’art (document rédigé en langue française, dans un style correct, en utilisant un vocabulaire compréhensible, sans fautes d’orthographe).


123

Cependant, la perception de l’état de l’art peut être très différente selon les interlocuteurs. Ceci est d’autant plus vrai que les méthodes et les techniques évoluent rapidement, ce qui est encore le cas pour le logiciel. Pour éviter toute incompréhension, il sera nécessaire de s’assurer que le client et le fournisseur ont bien la même appréciation de l’état de l’art. 7.11.2. Doit-on tenir compte des technologies ? En principe, le cahier des charges doit être rédigé exclusivement en termes fonctionnels. Mais peut-on rédiger un cahier des charges en faisant abstraction ou en ignorant les techniques qui seront utilisées ? L’expérience montre qu’il n’est pas souhaitable de rédiger un tel document sans avoir une idée de la technologie qui sera utilisée pour la réalisation du produit. L’ignorance des possibilités, des limites et des coûts des différentes technologies, risque d’engager la solution vers l’emploi de technologies inadaptées. En cas de doute sur la faisabilité d’une solution, il est recommandé de faire appel, au cours de l’élaboration du cahier des charges, à des experts, et éventuellement à des techniques de prototypage.

CHAPITRE 8

Le cahier des charges : guide de rédaction

8.1. Présentation de ce chapitre Nous supposons, à ce point, que les exigences ont été (ou sont en train d’être) recueillies, triées et analysées selon les règles de l’art. Ce qui va nous occuper dans le présent chapitre est le contenu du cahier des charges, et la manière de le structurer. Ce chapitre présente la norme AFNOR X50-151 (cahier des charges fonctionnel), ainsi que d’autres normes de document permettant de structurer les exigences. Il apporte des recommandations pour son application. Rappelons cependant que le cahier des charges est une manière, parmi d’autres, de représenter les exigences. Si nous y consacrons tant de place, c’est qu’elle est le vecteur et la principale trace de l’échange entre un demandeur et un fournisseur. Les exigences peuvent, par exemple, être stockées dans un outil de gestion des exigences. Cela ne changera rien aux principes de rédaction.

126


8.2. La norme X50-151 L’AFNOR a mis en place la norme X50-151 (cahier des charges fonctionnel). Comparativement à d’autres modèles de cahiers des charges, ce qui le caractérise est son ouverture à la négociation : les priorités entre fonctions ou contraintes doivent être exprimées, et une flexibilité des niveaux de priorité est explicitement prévue, permettant au demandeur (futur client) d’indiquer dans quelle mesure une exigence est négociable, et au soumissionnaire (futur fournisseur) de proposer des variantes. CAHIER DES CHARGES 1. Présentation du problème 1.1. Le produit et son marché 1.2. Contexte du projet, les objectifs 2. Enoncé fonctionnel du besoin 2.1. Cycle d’utilisation du produit et identification de son environnement 2.2. Enoncé des fonctions de service et des contraintes Fonctions de service attendues Contraintes Ordonner les fonctions de service Classement ou notation des fonctions 2.3. Caractérisation des fonctions de service et des contraintes Critères d’appréciation Niveaux des critères d’appréciation Flexibilité des niveaux : classe de flexibilité, limites d’acceptation, taux d’échange 3. Appel à variantes 4. Cadre de réponse Tableau 8.1. Plan de cahier des charges, modèle AFNOR X50-151


127

Le tableau 8.1 donne le plan d’un cahier des charges selon la norme AFNOR X50-151. La norme AFNOR X50-151 est un bon exemple de modèle de cahier des charges. De plus, c’est la seule norme française de modèle de cahier des charges. Cependant, toute entreprise a intérêt à avoir son propre modèle, adapté à son métier et à sa situation. Aucun modèle préétabli n’est adapté à toutes les situations. 8.3. Autres modes de présentation du cahier des charges Volere (www.volere.co.uk) a défini un plan de spécification des exigences un peu différent. Nous le présentons dans le tableau 8.2 avec sa traduction en français par l’auteur du présent ouvrage. Le plan de cahier des charges que nous proposons de commenter est présenté dans le tableau 8.3 est une variante de la norme X50-151. Il a été utilisé avec succès sur plusieurs projets d’informatique de gestion. 8.4. Guide de rédaction du cahier des charges Nous présentons ici un guide pour la rédaction du cahier des charges, proche de la norme X50-151, avec quelques modifications. Si une entreprise ou une organisation en a la liberté et les moyens, cette structure peut être modifiée, afin de mettre au point un modèle plus adapté à son métier, à ses contraintes organisationnelles, ou à ses processus. Cependant, l’expérience montre que, sur les projets de développement d’applications de gestion, la plupart des rubriques contenues dans ce modèle sont utiles dans presque tous les cas, éventuellement après de légères adaptations.

128


Les spécifications des exigences selon VOLERE (http://www.volere.co.uk/) PROJECT DRIVERS 1. The Purpose of the Project 2. Client, Customer and other Stakeholders 3. Users of the Product PROJECT CONSTRAINTS 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements NON-FUNCTIONAL REQUIREMENTS 10. Look and Feel Requirements 11. Usability and Humanity Requirements 12. Performance Requirements 13. Operational Requirements 14. Maintainability & Support Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements PROJECT ISSUES 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions

MOTIVATIONS DU PROJET 1. Objet du projet 2. Clients et autres parties prenantes 3. Les utilisateurs du produit CONTRAINTES DU PROJET 4. Contraintes obligatoires 5. Conventions de noms et définitions 6. Faits et hypothèses déterminants EXIGENCES FONCTIONNELLES 7. Périmètre de l’œuvre 8. Périmètre de l’ouvrage 9. Exigences sur les fonctions et données EXIGENCES NON FONCTIONNELLES 10. Exigences d’interface utilisateur 11. Exigences d’utilisabilité 12. Exigences de performance 13. Exigences opérationnelles 14. Exigences de maintenabilité et support 15. Exigences de sécurité 16. Exigences culturelles et politiques 17. Exigences légales QUESTIONS SUR LE PROJET 18. Questions ouvertes 19. Solutions sur étagère 20. Problèmes nouveaux 21. Tâches 22. Finalisation 23. Risques 24. Coûts 25. Documentation utilisateur et formation 26. Questions mises en attente 27. Idées de solutions

Tableau 8.2. Plan de cahier des charges, modèle proposé par Volere


129

Modèle de cahier des charges Introduction : Présentation du cahier des charges Première partie : Contexte et objectifs Deuxième partie : Analyse de l’existant et axes d’évolution Troisième partie : Expression des exigences Exigences fonctionnelles du système Exigences non fonctionnelles Quatrième partie : Contraintes Services d’accompagnement Environnement technique de la solution Environnement humain et organisationnel Cinquième partie : Projet de réalisation, facteurs de risque, incertitudes Projet de réalisation Facteurs de risque, incertitudes, complexités Sixième partie : Critères d’appréciation Conditions de recette Flexibilité des niveaux Appel à des variantes Cadre de réponse Septième partie : Annexes Tableau 8.3. Plan de cahier des charges, un exemple proposé par l’auteur

8.4.1. Introduction : présentation du cahier des charges Cette partie apporte au fournisseur des indications sur le métier, les contraintes, le contexte du client, et des indications sur le projet, éventuellement des projets connexes. Le paragraphe intitulé Objet du cahier des charges retrace en quelques phrases l’origine et les raisons de la demande et résume les attentes du client vis-à-vis du fournisseur : – urgence de la demande (délai de réponse souhaité, dates importantes) ;

130


– interlocuteurs éventuels (qui peut apporter quelle information) ; – type de réponse attendue ; – type d’engagement (avis, faisabilité, réalisation) ; – éléments de la structure de coûts (réponse au forfait, calcul du coût) ; – délais d’intervention (calendrier des jalons) ; – niveau de détail attendu de la part du fournisseur. 8.4.2. Première partie : contexte et objectifs Le paragraphe contexte indique la nature des activités professionnelles du client, en particulier celles qui seront impactées par la mise en œuvre du logiciel. Il donne des informations sur les motivations à l’origine de la demande : orientation du schéma directeur, décisions importantes, développement de nouvelles activités, évolutions actuelles et à venir de l’organisation du client, dysfonctionnements du système d’information. Le troisième paragraphe, description générale du projet, est le plus important pour le fournisseur. Il circonscrit le périmètre : quels sont les fonctions attendues, quels sont les résultats attendus par le système, les données traitées, qui seront les futurs utilisateurs. Ce paragraphe indique également quelles sont les prestations attendues du fournisseur : fourniture du logiciel, bien sûr, mais sous quelle forme, et avec quel accompagnement : – étude préalable ou détaillée ; – développement ; – possibilité d’intégration de composants ou de produits externes ; – qualification ; – mise en œuvre de la solution ;


131

– conduite du changement : information des utilisateurs, formation ; – installation, mise en exploitation sur site pilote ; – déploiement. Ce paragraphe indique aussi ce qui est exclu de la demande. Ceci évite bien des ambiguïtés. On peut y inclure un dernier paragraphe, responsables du cahier des charges, qui désigne les acteurs impliqués dans le cahier des charges (rédacteur, destinataire de la proposition attendue en retour, personne à contacter pour plus d’informations). 8.4.3. Deuxième partie : analyse de l’existant et axes d’évolution Cette partie du cahier des charges présente un panorama de l’état actuel du système. Elle est très utile au fournisseur car elle constitue la carte actuelle du terrain à modifier. Comme nous l’avons indiqué, sans analyse de l’existant, il est impossible de se projeter dans l’avenir. Le paragraphe cadre organisationnel fournit l’organigramme des services concernés par le système et situe les unités opérationnelles et fonctionnelles impliquées par le fonctionnement du système. Il est utile de fournir un diagramme présentant le circuit des informations entre ces unités (diagramme de flux). La description des fonctions dresse la liste exhaustive des fonctions, en leur état actuel. On peut y inclure un modèle conceptuel des traitements, un modèle des processus, une vision organisationnelle (postes de travail, nature des traitements, types de traitements) ainsi que la solution technique actuelle : procédures, matériels et logiciels de base, logiciels applicatifs, progiciels.

132


La partie description des données peut inclure le modèle conceptuel des données, un extrait du dictionnaire des données, les données concernées par la demande d’évolution, au niveau conceptuel (entités, relations, cardinalités, principaux attributs), logique ou physique (tables, liens, volumes). Le paragraphe bilan de la situation actuelle doit exposer, aussi objectivement que possible, les principaux axes d’amélioration nécessaires au système actuel : – fonctions inadaptées, manquantes, inutilisables ; – difficulté d’utilisation ; – manque d’efficacité administrative : circuits trop complexes, documents inutiles, règles de gestion obsolètes, moyens inadéquats ; – manque d’efficacité technique : temps de réponse trop longs ; – faible fiabilité ; – support aux utilisateurs insuffisant, faible efficacité de la maintenance. Mentionner, par sous-système ou domaine : – les principes ou les méthodes à remettre en cause ; – les facteurs de qualité administrative à revoir ; – les informations à préciser. Dans ce bilan de la situation actuelle, il est important de faire le tour de la question et citer les différents aspects : – ce qui est à conserver, voire à amplifier ; – ce qui est à supprimer ou à remplacer ; – ce qui est à modifier. Enfin, dans le dernier paragraphe, axes d’évolution, on pourra évoquer, sans les détailler, les différentes solutions


133

fonctionnelles qui ont été envisagées pour résoudre les problèmes. On pourra y présenter brièvement les scénarios étudiés et indiquer les raisons de choix du scénario retenu. Toute amélioration fonctionnelle implique une adaptation de l’organisation. On peut indiquer dans ce même paragraphe les mesures envisagées pour conduire le changement et pour faciliter l’appropriation du nouveau système par les utilisateurs. 8.4.4. Troisième partie : expression des exigences Après avoir décrit l’état actuel du système, on précise ici les caractéristiques de l’état souhaité pour le futur système. Cette partie constitue le plus souvent le cœur du cahier des charges. 8.4.4.1. Exigences fonctionnelles du système Cette partie est très délicate à élaborer. On doit y décrire les fonctions du système. Mais il ne s’agit pas de fonctions au sens informatique du terme. La tentation est grande, surtout si l’on vient d’un milieu technique, de découper le système en soussystèmes selon un plan technique, comme le ferait un architecte du logiciel, et d’empiéter sur les phases suivantes de la construction du système. Tomber dans ce travers, c’est courir le risque de présenter, non pas les besoins, mais la solution. Chaque fonction du système futur pourra être décrite par : – les résultats à produire (par exemple : états, écrans, messages) ; – les données en entrée (à saisir, ou déjà présentes dans des bases de données) ; – ce que l’on attend de la fonction : sa description ; – des contraintes particulières à la fonction. Dans le cas d’un cahier des charges détaillé, ou pour certaines fonctions que l’on veut détailler, les résultats à produire peuvent être décrits sous forme d’états de sortie, de messages, d’écrans

134


ou de fenêtres, les données nécessaires par leur description (pouvant aller jusqu’à la description physique) et la description de la fonction par un algorithme permettant de passer des données primaires aux résultats. De plus, les fonctions pourront être regroupées en groupes fonctionnels. Attention cependant à ne pas tomber dans le piège de la décomposition fonctionnelle de la solution, et d’empiéter sur le travail de l’architecte, avec les risques déjà évoqués : induire chez le fournisseur une solution a priori. On peut indiquer le niveau d’exigence, ou priorité, de la fonction : une fonction principale est une fonction indispensable que le fournisseur devra impérativement réaliser en priorité ; une fonction complémentaire pourra faire l’objet de développements optionnels ultérieurs. 8.4.4.2. Exigences non fonctionnelles La description des exigences non fonctionnelles est un point fondamental, souvent négligé. Nous préconisons la structuration de ces contraintes selon la norme ISO/CEI 91261 : – capacité fonctionnelle ; – fiabilité ; – facilité d’utilisation ; – rendement ; – maintenabilité ; – portabilité. Chaque exigence non fonctionnelle devra être vérifiable et testable par le demandeur. Chaque facteur de qualité sera caractérisé par des critères, et une métrique sera affectée à chaque critère. Par exemple le facteur de qualité « fiabilité » 1. Voir Le logiciel à valeur ajoutée, du même auteur, aux éditions Hermès [CON 01].


135

peut être caractérisé par plusieurs critères dont le temps moyen entre deux pannes (MTBF, ou mean time between failures). Le temps de réponse fait l’objet d’une métrique : du type : « Pour les transactions x, y et z (les plus fréquentes) le temps de réponse devra être inférieur à 2 secondes dans 95 % des cas ». Si nécessaire, d’autres exigences non fonctionnelles, n’entrant pas directement dans le cadre de la norme ISO 9126, et qui n’ont pas trouvé de place dans les paragraphes précédents, peuvent être ajoutées ici. 8.4.5. Quatrième partie : Contraintes 8.4.5.1. Services d’accompagnement Ce paragraphe peut être utilisé pour indiquer les prestations complémentaires attendues du fournisseur, en dehors de la fourniture principale qui fait l’objet de la demande : – conduite de changement : information et sensibilisation des utilisateurs, formation, assistance ; – mise en œuvre du nouveau système : installation, site pilote, déploiement ; – fonctionnement : exploitation, maintenance corrective ou évolutive. 8.4.5.2. Environnement technique de la solution Ce paragraphe peut être utilisé pour indiquer les caractéristiques techniques de l’environnement de fonctionnement de la solution : – infrastructure matérielle et logicielle, plates-formes et logiciels standard (existants, en cours d’acquisition ou à acquérir) ; – relations avec d’autres systèmes ; – interfaces existantes ou à développer.

136


8.4.5.3. Environnement humain et organisationnel Ce paragraphe peut être utilisé pour indiquer les conditions que devra respecter le nouveau système pour s’intégrer dans son environnement de fonctionnement : – conservation de matériels informatiques et des logiciels standard installés ; – conservation partielle ou totale de l’organisation existante, adaptation des personnes au changement ; – respect des normes et des standards ; – interopérabilité avec les autres systèmes en fonctionnement. Il est également important d’indiquer au fournisseur le degré de liberté qui lui est laissé. 8.4.6. Cinquième partie : projet de réalisation, facteurs de risque, incertitudes Cette partie du cahier des charges sort du cadre des exigences sur le produit et comporte trois aspects concernant le projet : – elle indique par avance au fournisseur quels sont les risques, et les difficultés auxquelles celui-ci devra s’attendre ; – elle impose ou propose au fournisseur une démarche a priori, des jalons, des délais ; – elle demande implicitement au fournisseur de rassurer le client, en lui demandant de se prononcer sur ces éléments et de donner au client une visibilité sur l’avancement des travaux. 8.4.6.1. Projet de réalisation Ce paragraphe peut être utilisé pour indiquer les conditions particulières de la réalisation : – délais souhaités ; – enveloppe budgétaire ;


137

– environnement technique de réalisation ; – outils à utiliser (matériels et logiciels) ; – normes et standards de réalisation ; – participation de membres de l’équipe du client aux travaux ; – documentation liée au projet (planification, plan d’assurance qualité, etc.). 8.4.6.2. Facteurs de risque, incertitudes, complexités Afin de mieux prévenir les difficultés, le paragraphe facteurs de risques permet de recenser les facteurs d’incertitude et de complexité spécifiques du projet et susceptibles de générer des risques. La connaissance de ces facteurs permet la recherche de solutions adaptées. Les facteurs d’incertitude caractérisent les imprécisions relatives à l’énoncé du problème. Exemples de facteurs d’incertitude : adhésion des utilisateurs ; stabilité de l’environnement ; formalisation du processus ; importance des changements organisationnels ; qualité des spécifications. Les facteurs de complexité caractérisent les difficultés particulières du projet : nombre et hétérogénéité des acteurs, taille du domaine applicatif, nombre de sites, complexité des processus, complexité des données, innovations technologiques. Le paragraphe démarche de réalisation découpe le projet en lots et en livrables (par exemple : spécifications, construction, validation, formation, exploitation). La connaissance des facteurs d’incertitude et de complexité permet ici au fournisseur d’adapter sa réponse aux caractéristiques de chaque lot. Le client peut préciser la démarche de livraison attendue (livraison en une fois, incrémentale, par lots, par évolutions successives).

138


Les jalons sont les points de décision du projet, visibles du client et du fournisseur. Ils permettent au client de suivre l’évolution de la réalisation du produit. Chaque point de décision marque une échéance de livraison d’un constituant du produit ou d’un lot de constituants. Le cahier des charges indique les jalons importants : ce qui est à livrer et quels seront les critères d’acceptation. 8.4.7. Sixième partie : critères d’appréciation 8.4.7.1. Conditions de recette On peut préciser ici les clauses principales du protocole de recette de la solution et indiquer les conditions d’acceptation des différents sous-systèmes et des services associés. 8.4.7.2. Flexibilité des niveaux Les exigences formulées par le client dans le cahier des charges n’ont pas toutes la même importance ou la même urgence. Pour permettre au fournisseur d’optimiser sa solution (apporter le maximum de satisfaction au coût le plus faible), il est nécessaire d’indiquer la priorité de ces exigences : – la classe de flexibilité (niveau de flexibilité de chaque exigence : nulle, faible, bonne, forte) indique dans quelle limite une contrainte est négociable ; – la limite d’acceptation définit, pour chacune des caractéristiques fondamentales du produit, une valeur minimale de la mesure du critère d’appréciation. En deçà de cette valeur, le besoin sera déclaré insatisfait ; – le taux d’échange indique les compensations fixées a priori au cas où certains critères d’acceptation, jugés essentiels par le demandeur, ne seraient pas satisfaits (par exemple, les pénalités de retard, dans le cas où le fournisseur ne respecterait pas ses délais de livraison).


139

8.4.7.3. Appel à des variantes Il permet de stimuler la créativité du fournisseur ; le client peut solliciter des propositions d’amélioration : fonctionnelles (création, modification ou suppression de fonctions) ; non fonctionnelles (performances, ergonomie). Les variantes peuvent être soit des suppléments, soit des alternatives au scénario préconisé. 8.4.7.4. Cadre de réponse Le cadre de réponse est utilisé dans l’appel d’offres à plusieurs fournisseurs, ainsi que pour les appels à des variantes. Ce cadre comporte une grille d’évaluation des différentes solutions proposées en chiffrant les caractéristiques les plus sensibles. Le cahier des charges peut indiquer les barèmes de notation et la pondération affectée à chaque caractéristique. 8.4.8. Septième partie : annexes Un glossaire permettra d’éviter toute confusion, de définir tous les termes qui risqueraient d’être interprétés par le fournisseur dans un sens différent de celui que voulait leur donner le rédacteur : termes techniques spécifiques à l’activité du domaine ou méconnus, néologismes, sigles et abréviations, synonymes. Un paragraphe Documents justificatifs de la demande peut être utile pour annexer au cahier des charges une copie des documents ou pour donner les références à d’autres documents.

CHAPITRE 9

Validation et diagnostics

9.1. Validation des exigences 9.1.1. Une opération cyclique et continue La validation est, pour ainsi dire, la « dernière étape » de la phase de définition des exigences, après le recueil, l’analyse, et la spécification. L’expression est à prendre avec précaution, l’ingénierie des exigences étant un processus cyclique ; parler d’étape finale peut donc créer une confusion. En plus de faire partie d’un processus cyclique, la validation pourrait (et devrait) être une opération quasiment continue : les exigences peuvent être validées à différents niveaux, à différents stades de leur élaboration. Ainsi, la relecture d’un cahier des charges dans sa totalité par un comité formellement désigné est clairement perçue comme une étape de validation. Mais des opérations plus ponctuelles, comme des relectures partielles ou même des validations de comptes-rendus de réunions le sont aussi.

142


9.1.2. Les critères de passage En réalité, il importe peu de faire de la validation une étape formelle. L’important est qu’un certain nombre de critères soient remplis avant que le cahier des charges (ou tout document, ou tout ensemble structuré d’informations qui tient lieu de cahier d’exigences) ne soit « lâché » au maître d’œuvre, à l’architecte ou au concepteur de l’application. Les critères sont les suivants : – les exigences elles-mêmes sont valides, c’est-à-dire complètes, cohérentes, non ambiguës ; – les exigences de différents niveaux sont cohérentes entre elles. Par exemple, les exigences fonctionnelles sont cohérentes avec les règles de gestion ; dans le cas idéal, il devrait être possible de démontrer la traçabilité à toutes les étapes, par exemple, depuis les objectifs définis en amont jusqu’aux exigences fonctionnelles détaillées, ou depuis les interviews des utilisateurs jusqu’aux exigences détaillées concernant l’ergonomie ; – le cahier des charges doit constituer un tout cohérent ; il doit décrire un système1 ; – le cahier des charges doit être « assimilable » par toutes les parties prenantes ; plus précisément, il doit être exploitable par ceux qui vont prendre le relais de l’équipe des exigences : architectes, concepteurs, et équipe de test ; – et, cela va sans dire, mais est plus difficile à faire, le cahier des charges est le reflet le plus exact possible des besoins du client. Ces cinq critères induisent des contraintes fortes sur les exigences. En particulier, le dernier critère implique que l’élaboration d’un cahier des charges est le plus souvent un travail d’équipe et requiert, avant tout, un effort de 1. Le terme de système est à prendre ici, non dans son sens restreint de système informatique, mais au sens large d’ensemble coordonné formant un tout.


143

communication. Il faut, non seulement « se mettre à la place du client » (l’expression est d’une grande banalité) mais aussi se mettre à la place du fournisseur (moins banal, mais tout aussi nécessaire)2. 9.1.3. Valider à tous les niveaux Ce qui est valable à grande échelle, au niveau du cycle de vie du logiciel, est également valable à plus petite échelle, au niveau de la phase d’exigences. A savoir que, plus les erreurs, incohérences, ambiguïtés et silences seront découverts tôt pendant la phase d’exigences, et plus leur correction sera facile, efficace, et économique. 9.2. Les différentes méthodes de validation 9.2.1. Les inspections et revues Les inspections et revues sont des moyens extrêmement efficaces d’augmenter la qualité d’un document ou d’un produit. Différentes variantes existent (revue par les pairs, inspections...) mais le principe est à peu près le même : – l’auteur envoie le document aux différents participants à l’inspection, avec une date de réunion, et éventuellement des consignes particulières ; le document est accompagné d’un formulaire de remarques ; – les participants étudient le document et consignent leurs remarques dans le formulaire prévu à cet effet ; – les participants se réunissent pour discuter le document qui fait l’objet de l’inspection ; certains participants jouent un rôle 2. Cependant, si l’on considère le cahier des charges comme un « produit » qu’il faudra « vendre » à l’équipe de développement, c’est bien, encore et toujours, à la place du client qu’il faudra se mettre.

144


particulier : l’auteur bien sûr, mais aussi le modérateur et le secrétaire, qui peuvent être différents de l’auteur, ainsi qu’un testeur, un concepteur, et le chef de projet ; – suite à la réunion, l’auteur tient compte des remarques et modifie le document ; – le document modifié est envoyé aux participants. Le processus de revue ou d’inspection peut lui-même être itératif, à plusieurs passages. Si le document revu n’est pas satisfaisant

après modification, il repart pour une nouvelle tournée d’inspection. Bien que la technique des inspections et des revues ait démontré son efficacité, sa mise en œuvre se heurte souvent à des résistances. C’est un investissement à long terme – dont on ne voit pas l’effet immédiat –, et qui est consommateur de temps et d’efforts, qui demande un travail d’organisation. De plus, passer en revue un document de volume important est une tâche fastidieuse. Des moyens existent néanmoins pour ce faciliter la tâche : – procéder à des validations partielles plutôt que de passer en revue un document dans sa totalité ; – faire valider les différentes parties du document par des équipes différentes ; – consentir à ne passer en revue que les parties les plus critiques ; – alléger le processus de revue pour les parties de moindre importance. La pratique régulière des revues et inspections de documents doit entrer dans la culture de l’entreprise, et cela ne se fait pas en un jour. En tout état de cause, mieux vaut faire des revues


145

partielles avec un protocole allégé, que de ne pas en faire du tout. 9.2.2. La création des scénarios et cas de tests En élaborant les scénarios de tests et cas de tests, les incohérences, incomplétudes et ambiguïtés des exigences sont mises en lumière. Le meilleur moment pour mettre au point les tests est donc pendant (et non après) la phase des exigences. Comme toutes les autres techniques de validation, l’élaboration des tests peut se faire à tout moment. Le cahier des charges et le cahier des tests sont le miroir l’un de l’autre. Et un utilisateur ou un maître d’ouvrage sera doublement réactif à la lecture de ces deux documents. A la lecture du cahier des charges, l’utilisateur vérifie que ce qui est écrit est compatible avec ce qu’il a exprimé. A la lecture d’un scénario de test, l’utilisateur aura à réagir non seulement au scénario normal (ce qui se passe lorsque tout va bien) mais également au scénario exceptionnel (comment le système réagit dans les cas anormaux), et, dans tous les cas de figure, ce miroir va apporter une image inversée du besoin : « vos besoins seront-ils satisfaits si le système réagit de cette manière à ce test ? ». Le simple fait de se servir du cahier des charges pour développer des scénarios et des cas de test va forcer sa lecture en profondeur et apporter un feed-back qui ne peut-être que productif. Remarquons que toutes les exigences doivent être testées, y compris, cela va sans dire, les exigences non fonctionnelles. Ecrire des tests d’utilisabilité ou de fiabilité n’est pas une chose évidente, mais cela va aider à mieux réfléchir sur la construction du produit (et est de toute façon nécessaire).

146


Mieux encore, on peut demander aux représentants des utilisateurs de participer non seulement à la campagne de test d’acceptabilité du logiciel, mais également à l’écriture des scénarios de test. La question-clé à poser aux utilisateurs est « comment saurez-vous que le logiciel aura atteint ses objectifs ? ». 9.2.3. Les autres méthodes de validation Nous avons déjà évoqué le maquettage et le prototypage. Maquettes et prototypes sont d’excellents moyens d’évaluer les exigences « en continu », c’est-à-dire en faisant participer les utilisateurs et développeurs. Quelques précisions s’imposent cependant. Tout d’abord, tester un prototype revient à tester de front les exigences et une partie de ce que deviendra le produit. Cela permet de corriger les écarts entre ce que le client avait imaginé ce que les concepteurs ont compris. La participation des utilisateurs permet également de mettre à jour les écarts entre ce que demandait le client et le véritable besoin des utilisateurs. Mais cela ne garantit pas, loin s’en faut, la satisfaction des utilisateurs. En effet : – la carte n’est pas le territoire, et un prototype (a fortiori, une maquette) n’est pas un produit ; – un prototype permet de recueillir le feed-back « à chaud » de l’utilisateur, pas sa satisfaction à long terme ; – l’utilisateur a son mot à dire, nous avons insisté sur ce point ; mais l’utilisateur n’est pas un ergonome : attrayant et agréable (sensations toute subjectives) ne sont pas synonymes de productif et efficace. Pour faire une analogie, le confort de conduite n’est pas un gage de sécurité sur la route.


147

9.3. Audits et diagnostics de logiciel Les différentes techniques de validation font partie du processus de développement des exigences. Mais, dans certains cas, une vision extérieure peut s’avérer utile, à différents stades du développement du produit. Il est alors utile de mettre en œuvre des techniques comme le diagnostic ou l’audit, de projet ou de produit. Un œil extérieur, un regard neutre, un certain recul par rapport au projet, peuvent avoir des effets salutaires, tant préventifs que curatifs, sur le déroulement du projet et la qualité du produit. 9.3.1. Pourquoi un diagnostic ? Rappelons les rôles respectifs du fournisseur et du client d’un logiciel : le fournisseur est le maître d’œuvre. Comme son nom l’indique, il est responsable de l’œuvre, du travail effectué. Le client est le maître de l’ouvrage, c’est-à-dire du produit fini. En d’autres termes : – le fournisseur doit maîtriser le processus ; – le client doit maîtriser le produit. Tant que le projet en est à la phase d’exigences, le produit intermédiaire (le cahier des charges) est entre les mains du maître d’ouvrage. Mais comment maîtriser le produit en cours de construction, qui est entre les mains des équipes de développement ? C’est l’« effet tunnel », bien connu sur les projets de développement de logiciel. En cours de développement, les développeurs sont comme au fond d’une mine, une lampe sur le front, et ne voient qu’une petite zone droit devant eux. Le client, lui, est dans le noir absolu. Et ce ne sont pas les réunions hebdomadaires entre fournisseur et client qui vont apporter beaucoup de lumière. Les prototypes sont un moyen d’apporter un certain éclairage, mais

148


cet éclairage est très partiel. Un prototype peut être biaisé et, tout compte fait, n’engage que celui qui l’examine. Reste un moyen efficace d’apporter un peu de lumière dans le tunnel : l’audit, effectué par une personne ou une équipe indépendante (à la fois du fournisseur et du client). La palette des possibilités est très large. L’audit peut être : – très technique (analyse du code source), ou comportemental (examen du produit), ou basé sur des interviews, ou sur la documentation existante ; – centré sur le produit uniquement, ou sur le produit et le projet ; – sur le produit en cours de développement, en fin de développement, ou en exploitation ; – centré sur quelques caractéristiques (par exemple l’utilisabilité, la sécurité...), ou essentiellement fonctionnel, ou plus global. Audits et diagnostics sont des opérations relativement coûteuses, car un expert indépendant (donc extérieur et non impliqué dans le projet) doit se plonger pour la première fois dans un environnement organisationnel et technique inconnu. Cependant, c’est cette même indépendance qui apporte le recul et la neutralité nécessaires à un éclairage nouveau. Pour une application, l’auditeur va énumérer les points à améliorer, proposer des pistes nouvelles. Un expert indépendant va aussi « calibrer » le produit en le comparant à l’état de l’art et aux meilleures pratiques de la profession. Quant à l’audit de projet, il va permettre de prévenir l’échec. Dans de nombreux cas, il permettra de rattraper certaines erreurs et rassurera la maîtrise d’ouvrage. Mieux vaut prévenir que guérir. L’opération est donc utile, tant pour la maîtrise d’ouvrage que pour la maîtrise d’œuvre.


149

Une organisation peut aussi demander un diagnostic flash, qui est un passage en revue rapide du logiciel, de son développement ou de son utilisation. Ce type de diagnostic permet, en un temps limité (deux à cinq jours), de déterminer dans quelles directions il serait utile d’approfondir, si cela s’avère nécessaire. Pour plus d’information sur l’audit informatique, le lecteur pourra utilement se rapporter aux ouvrages existants, en particulier [THO 00]. Dans les paragraphes suivants, nous aborderons exclusivement le diagnostic d’application, dans ses grandes lignes. 9.3.2. Le déroulement d’un diagnostic d’application Une démarche structurée permet de mener un diagnostic avec efficacité. Il comporte cinq étapes : – le lancement : lors d’un entretien ou une réunion le consultant et son client vont définir les objectifs de la mission, sélectionner les fonctions et/ou les caractéristiques non fonctionnelles à examiner en priorité, identifier les documents à analyser et les personnes à interviewer, et se mettre d’accord sur le plan du rapport de diagnostic ; – la préparation : les consultants préparent les questionnaires et les check-lists, à partir de documents types, en fonction des objectifs définis, et collectent les documents nécessaires ; – l’analyse : les consultants analysent l’application et la manière dont elle est utilisée. Diverses actions sont menées, en fonction des objectifs et des besoins du client. Le directeur de mission peut faire appel à des experts métier (connaissant le domaine d’application) ou à des experts techniques (en particulier, pour l’analyse du code source d’une application) ;

150


– la synthèse : les données et informations collectées sont consolidées et les informations sont vérifiées pour éliminer les « zones d’ombre ». Cette étape aboutit à un rapport préliminaire ; – la conclusion : le directeur de mission présente le rapport préliminaire à son client, qui peut réagir sur des points de détail et sur la forme ; le rapport définitif est ensuite rédigé. Comme pour toute forme d’audit, mais particulièrement pour les audits d’application, l’efficacité de la mission est conditionnée par le savoir-faire et le niveau d’expertise des consultants, mais également par l’utilisation d’un certain nombre d’outils : – questionnaires standards, qui seront souvent par la suite adaptés au contexte du client, mais qui constituent une bonne base de départ ; par exemple, une série de questions peut être utilisée pour chaque caractéristique de qualité ; – plan de rapport de diagnostic ; – check-lists d’examen de l’application par caractéristique de qualité (pour les exigences non fonctionnelles) par groupes de fonctions (pour les exigences fonctionnelles) ou techniques (qualité du code source) ; – enfin, on utilise souvent une base de connaissances permettant de confronter le cas examiné à des cas analogues ; cette base est enrichie à la fin de chaque mission de diagnostic. 9.4. Mesure de l’utilisabilité : le questionnaire SUMI Le questionnaire SUMI (abréviation de Software Usability Measurement Inventory) est une méthode relativement simple et peu onéreuse d’évaluation de l’ergonomie (ou, plus précisément, de l’utilisabilité) d’un logiciel. Il permet, soit la comparaison de plusieurs logiciels analogues (étude comparative), soit un diagnostic en vue de l’amélioration.


151

L’outil se compose d’un questionnaire standard comportant 50 questions fermées. L’élaboration du questionnaire a été construit avec beaucoup de soin, et a été calibré sur un grand nombre de projets très différents, ce qui a nécessité des investissements importants. Mais sa mise en œuvre est très simple : pour chaque question, la personne qui remplit le questionnaire doit simplement cocher une case parmi « d’accord », « pas d’accord » et « ne sais pas ». Les questions sont très simples, du type « je recommanderais ce logiciel à mes collègues » ou « il répond trop lentement ». Il doit être rempli par un échantillon d’une cinquantaine d’utilisateurs au minimum. Le questionnaire est vendu avec un outil de dépouillement automatique. Cet outil analyse les réponses au questionnaire, et fournit cinq indicateurs : – efficacité : capacité à atteindre les objectifs ; – affect : adéquation aux réponses émotionnelles des utilisateurs ; – utilité (helpfulness) : dans quelle mesure le logiciel soutient l’utilisateur ; – contrôle : dans quelle mesure l’utilisateur contrôle le logiciel (correspond au « contrôle explicite » de la norme AFNOR Z-67 133-1 sur l’ergonomie du logiciel) ; – facilité d’apprentissage. Les réponses fournies par l’outil d’analyse automatique sont fournies par rapport à un référentiel de 2000 applications analysées, ce qui le rend très fiable. Parmi ses inconvénients : il nécessite la participation d’un assez grand nombre d’utilisateurs d’une population homogène, les réponses apportées sont peu détaillées, et il ne peut être mis en œuvre qu’après le déploiement du logiciel.

152


Cependant, le questionnaire SUMI est relativement simple à mettre en œuvre, et peut constituer une première approche orientant, si nécessaire, vers un diagnostic plus approfondi. C’est par ailleurs un des rares moyens efficaces de mesurer la qualité de fonctionnement (quality in use).

CHAPITRE 10

La gestion et le suivi des exigences

10.1. Pourquoi les exigences doivent être gérées ? 10.1.1. Une activité nécessaire L’ingénierie des exigences, qui fait l’objet de cet ouvrage, comporte deux facettes : – d’une part, le développement des exigences, dont il a été question jusqu’ici ; – d’autre part, la gestion des exigences, qui concerne plus précisément la gestion de leurs changements hors de la phase d’exigences proprement dite, et à laquelle ce chapitre est consacré. Une fois les besoins recueillis, analysés, et négociés entre les parties prenantes, ils sont finalement spécifiés sous forme d’exigences. Ces exigences sont transmises à l’équipe d’architectes et de concepteurs. Le logiciel passe ainsi de la phase de définition des exigences à la phase de conception.

154


En fait, des changements dans les exigences peuvent survenir tout au long du cycle de vie du logiciel : conception, réalisation, intégration ; ou de maintenance. 10.1.2. Risques induits par des changements incontrôlés Si le changement en lui-même est inévitable, le changement incontrôlé induit un certain nombre de risques sur le projet et le produit : – des utilisateurs différents (ou représentants des utilisateurs) peuvent faire des demandes sans se concerter, ce qui aboutit à des exigences incohérentes ; – la maîtrise d’ouvrage, qui ne connaît pas le coût d’une exigence, peut demander une modification en apparence légère, alors que l’impact sur le produit sera en réalité très important ; – du fait que la demande initiale est souvent peu formalisée, il y a un risque de « spécifications rampantes », avec des conséquences sur les délais, les charges, et la qualité du produit ; – un autre risque concerne le circuit de décision. Certaines modifications sont discutées entre la maîtrise d’ouvrage et le chef de projet, ou directement avec les développeurs, sans vraiment connaître l’impact des changements sur le produit final. 10.1.3. La nécessité de gérer Cette gestion du changement est essentielle, sans quoi les efforts de recueil, d’analyse, et de structuration des exigences qui ont été fournis en amont seront vite perdus. En effet : – il est nécessaire d’évaluer l’impact d’une exigence sur les exigences existantes, et l’impact de sa mise en œuvre sur le produit développé ou en cours de développement ;


155

– les exigences doivent être gérées selon des priorités, à négocier. En effet, l’importance, l’urgence et la difficulté de réalisation ne sont pas du tout les mêmes lorsqu’elles sont estimées par le demandeur (qui n’a qu’une vision partielle et partiale de la situation) ou par les développeurs (qui, eux aussi, ne voient qu’un aspect des contraintes) ; – comme les exigences, les modifications des exigences devraient, dans l’idéal, faire l’objet d’un consensus ; – les modifications doivent être suivies, et les plannings mis à jour ; – les changements et leur impact doivent être enregistrés, et les documents (cahier des charges, spécifications, documentation du produit) doivent être mis à jour. 10.1.4. Organisation La gestion des changements des exigences est à la frontière entre plusieurs domaines de processus : la gestion des exigences, la gestion de la configuration du logiciel, la gestion de projet et, d’une manière générale, l’ingénierie du logiciel. En effet, tout changement dans les exigences aura un impact sur la configuration du logiciel, c’est-à-dire sur la manière dont les différentes parties du produit sont agencées entre elles, et sur la façon dont les versions successives du logiciel sont liées aux versions de chacun de ses composants. Un changement dans les exigences aura aussi un impact sur les coûts et les délais de livraison des différentes versions. L’étude de ces disciplines (la gestion de configuration et la gestion de projet) dépasse le cadre de cet ouvrage. Nous n’en aborderons ici que les aspects en relation directe avec l’évolution des exigences.

156


10.2. Comment les exigences doivent être gérées 10.2.1. Le processus La gestion des changements sur les exigences est un processus rigoureux, illustré par la figure 10.1.

Demande de changement

Enregistrement

Analyse d’impact

décision de modifier

Ordre de modification

Modification

Clôture

approbation

Figure 10.1. Le processus de gestion des changements

Chaque demande de changement est enregistrée, puis examinée par une commission de contrôle des changements (change control board), qui, en fonction de la nature, de l’urgence, et de l’importance du changement à apporter, la transmettra à un


157

expert (concepteur, développeur, souvent plusieurs personnes) qui va analyser l’impact de la modification. Suite à cette analyse, la commission de contrôle des changements peut, soit rejeter la demande, soit décider de demander une ou plusieurs modifications. Cette modification peut être planifiée pour la version en cours de développement, ou pour une version ultérieure. Lorsque toutes les modifications relatives à une demande de changement ont été effectuées et approuvées, la demande est close. 10.2.2. La commission de contrôle des changements Afin que les changements soient gérés, et non subis, il est nécessaire de mettre en place une commission de contrôle des changements (en anglais, CCB, change control board). Cette commission est un passage obligé de toute demande de modification des exigences. Toute demande de changement, même minime, devra passer par elle, après avoir été dûment formalisée. C’est cette commission qui décide, en fonction des impacts sur les coûts et les délais, des modalités de prise en compte d’un changement dans les exigences. En général, on met en place une commission par projet, présidée par le chef de projet maîtrise d’œuvre ; mais l’organisation de la commission dépend de la taille de l’organisation et du nombre de projets en cours. La commission est formée au minimum d’un représentant de la maîtrise d’œuvre et d’un représentant de la maîtrise d’ouvrage, ainsi que d’un expert et d’un gestionnaire de configuration.

158


Elle se réunit à dates fixes, ou en tant cas de besoin pour : – passer en revue les demandes de changement ; – déléguer l’analyse d’impact ; – revoir les priorités des demandes, suite à l’analyse d’impact ; – décider, en fonction des impacts sur les coûts et les délais, des modalités de prise en compte d’un changement dans les exigences ; – ordonner et suivre la mise en œuvre du changement ; – en cas de difficulté, remonter le problème au plus haut niveau de décision. 10.2.3. L’analyse d’impact L’analyse d’impact peut être effectuée par un ou plusieurs experts (assistant maîtrise d’ouvrage, développeur, testeur) mais elle est sous la responsabilité d’une seule personne, nommément désignée. Elle se concrétise par un rapport (en général, une simple fiche). Le tableau 10.1 est un exemple de rapport d’analyse d’impact. 10.3. Les activités de gestion des exigences 10.3.1. La gestion des attributs des exigences Afin de pouvoir être gérée, chaque exigence doit comporter un certain nombre d’attributs : – la date de création ; – le numéro de version ; – les contributeurs : demandeur (source) ; auteur (qui l’a formalisée) ; – le statut (provisoire, mise en œuvre, supprimée, ajournée) ; – la priorité ;


159

– la stabilité (ou, au contraire, la « volatilité », ce qui revient au même) ; – le lien avec le produit : version(s) du logiciel et composant(s) du produit où l’exigence est mise en œuvre.

Rapport d’analyse d’impact Numéro de demande de changement Intitulé de la demande de changement Description précise de l’exigence

Pris en charge par :

Risques encourus si le changement est mis en œuvre

Risques encourus si le changement n’est pas mis en œuvre

Estimation du coût du changement (jours*hommes)

Estimation de l’effort perdu (coût de la suppression d’une fonction déjà existante + coût d’un développement qui sera abandonné.)

Impact sur le planning global du projet

Impact du changement sur les charges totales

Le :

Impact sur la qualité finale des livrables (performances, maintenabilité...) Autres exigences impactées Tâches affectées si le changement est mis en œuvre Problèmes d’intégration estimés Liste des documents qui seront touchés par une modification Liste des modules de code qui seront touchés par une modification Liste de tous les autres éléments qui seront touchés par une modification Tableau 10.1. Fiche de rapport d’analyse d’impact

160


C’est ce dernier point, le lien entre exigence (et versions des exigences) et produit (et versions du produit), qui est au croisement de deux disciplines d’importance : la gestion des exigences et la gestion de configuration du logiciel. 10.3.2. L’évolution des demandes de changement La figure 10.2 présente le diagramme d’états des demandes de changement et ordres de modification. Demande enregistrée

Demande évaluée

Décision prise

Changements effectués

Modif. demandée

Modif. demandée

Modif. demandée

Modif. effectuée

Modif. effectuée

Modif. effectuée

Modif. approuvée

Modif. approuvée

Modif. approuvée

Demande close

Figure 10.2. Demande de changement et changements effectifs

Pour des raisons techniques, une demande de changement pourra donner lieu à plusieurs ordres de modification (par exemple, si une demande impacte plusieurs programmes).


161

Toute demande de changement va passer par des états successifs : – proposée : la demande est enregistrée selon un modèle préétabli, soit sur une fiche, soit au moyen d’un outil de gestion des changements ; – approuvée : la commission a approuvé la demande : elle a donné un ou plusieurs ordres de modification ; – modifiée : toutes les modifications correspondant à la demande ont été prises en compte ; – vérifiée : les tests correspondant à la demande de changement ont été effectués ; – supprimée ou rejetée : la demande peut avoir été supprimée par le demandeur ou rejetée (avec justification) par la commission. 10.4. De la rentabilité des opérations de gestion Dans ce chapitre, nous avons survolé le processus de gestion des changements sur les exigences. La complexité des opérations à mener, le nombre de fiches à remplir et la nécessité de mettre en place des commissions peut laisser croire que ces opérations vont être consommatrices de temps et ralentir les activités des développeurs et des consultants. En réalité, ces activités de gestion, sans doute peu enthousiasmantes et un tant soit peu « bureaucratiques », nécessitent surtout un changement culturel. Les commissions et les processus devront être aussi légers que possible, adaptés à la taille des projets et au type de produit développé, mais devront être incontournables. Le respect de ces procédures est nécessaire pour préserver une grande partie de l’effort qui a été fait en amont, à savoir le recueil, l’analyse, et la spécification des exigences. La cohérence des exigences est à ce prix.

162


Mais cet effort de gestion est également nécessaire aux autres activités de développement de logiciel, en particulier : – évaluation plus précise les charges du projet (le reste à faire) ; – meilleure utilisation des ressources disponibles (développeurs, testeurs) ; – connaissance précise du contenu d’une version livrée ; – documentation à jour.

CHAPITRE 11

Quelques conseils techniques

11.1. Considérer la définition des exigences comme un vrai projet A ce stade, le lecteur sera convaincu que recueillir, analyser, négocier et spécifier les besoins est un vrai métier. Ces activités font appel à des compétences spécifiques. Cependant, même les entreprises et organisations qui disposent d’une maîtrise d’ouvrage « professionnelle » ne considèrent pas toujours ces activités comme formant un projet à part entière. Lorsqu’elles font appel à un consultant externe (souvent, un assistant à la maîtrise d’ouvrage expérimenté) elles doivent nécessairement définir sa mission avec précision, ce qui est fort utile. Mais lorsque tout est fait en interne, le cahier des charges est souvent expédié à la hâte, sans consulter tous les acteurs impliqués, sans gestion des priorités, sans analyse précise de l’existant. Ainsi, on a vu partir chez des intégrateurs des cahiers des charges de quelques pages pour un appel d’offres de plusieurs

164


millions d’euros. Cela n’a pas aidé les soumissionnaires à bien préciser leur offre, ni facilité le dépouillement des réponses. Pour les « petits » projets, la définition des besoins passe parfois totalement sous silence. Sous prétexte qu’il s’agit d’un projet de taille a priori modeste, on ne prend pas le soin d’élaborer un cahier des charges dans les règles de l’art. Or, tant que l’on n’a pas précisément défini les objectifs, on ne connaît pas la taille du projet. C’est ainsi que l’on voit de « petits » projets prendre de l’ampleur sans définition préalable des objectifs, des besoins et des priorités (phénomène de « spécifications rampantes »). La meilleure parade à ces dérives est un processus bien défini pour l’ingénierie des exigences, et des documents types, facilement utilisables ou adaptables aux différents types de projets et produits logiciels. 11.2. Gérer par les objectifs Nous avons consacré un chapitre à cette phase importante, qui conditionne toutes les autres. Cependant, la définition des objectifs n’est pas une opération figée dans le temps. Les objectifs peuvent être périodiquement revus. Cette révision des objectifs peut avoir deux origines : – une origine externe au produit : par exemple, une modification de la réglementation ; dans ce cas, une modification des objectifs aura un impact sur les exigences ; – une origine interne au produit : par exemple, une difficulté particulière à respecter une exigence, ou un changement dans la technologie ; cela peut amener à redéfinir les objectifs initiaux.


165

D’une manière générale, gérer par les objectifs signifie garder à l’esprit (et sur le papier) les objectifs initiaux, et conserver le lien entre les objectifs et les exigences. 11.3. Choisir le bon modèle de cahier des charges Dans cet ouvrage, nous avons donné plusieurs exemples de cahier des charges. En effet, aucun modèle de cahier des charges n’est meilleur dans l’absolu. Les besoins, les contraintes et les priorités sont très différents d’un métier à l’autre. Un cahier des charges pour une application bancaire n’aura pas la même structure qu’un cahier des charges d’un logiciel embarqué. Prendre le temps de choisir un modèle de cahier des charges et de l’adapter est un investissement très rentable. Pour une entreprise qui développe ses propres applications, c’est aussi un exercice permettant d’aligner l’élaboration du cahier des charges sur la stratégie de l’entreprise : par exemple, quelle que soit l’application considérée, le chapitre sur la sécurité ou la fiabilité sera renforcé si la sécurité ou la fiabilité des applicatifs est une préoccupation majeure ; ce type d’exigence non fonctionnelle aura une importance particulière, et le plan de cahier des charges contiendra des paragraphes adaptés au cas particulier de l’entreprise. Le fait d’avoir mené une réflexion, recherché ces particularités, et de les avoir inscrites dans le plan du cahier des charges aura permis aux équipes de travailler sur un sujet commun transversal, et facilitera le travail ultérieur des équipes de conception et de réalisation. Par la suite, ceux qui seront en charge de la spécification des exigences essaieront de s’y conformer dans toute la mesure du possible. Ils apporteront leur feed-back si nécessaire, de manière à modifier le modèle si cela s’avère utile.

166


11.4. Utiliser les outils avec discernement Les méthodes et les outils de gestion des exigences peuvent rendre de précieux services. Différents types d’outils de gestion des exigences sont sur le marché. Il est important de choisir l’outil qui correspond le mieux aux méthodes de travail de l’entreprise ou de l’organisation, au budget, et aussi à l’effort que l’on est prêt à consacrer pour se l’approprier. On peut distinguer deux types d’outils utilisables au stade de la définition des exigences, et pour la gestion des exigences en cours de projet : – les outils d’analyse et de conception, utilisables pendant la phase de recueil, d’analyse et de spécification des exigences. Ces outils permettent de tracer, par exemple, des diagrammes de flux, des modèles de données et de traitement, ou des diagrammes de processus métier ; – les outils de spécification et de gestion des exigences : ce sont des systèmes de gestion de bases de données spécialisés permettant de stocker des exigences à différents niveaux, et d’assurer la traçabilité entre les exigences ; leur interface utilisateur peut rappeler celle d’un tableur ou d’un traitement de texte. Lorsqu’un processus rigoureux est en place, l’outil permet de faire mieux, plus vite et plus facilement ce que l’on sait déjà faire avec un bloc de papier et des marqueurs de couleur, ou avec un traitement de texte standard. Cependant, croire que l’acquisition et la mise en œuvre d’un outil permettront d’améliorer le processus de définition des exigences, ou les exigences en sortie, est une illusion. Cette illusion est vraie quel que soit le type d’outil1, mais avec les outils de

1. [CON 98] Yves CONSTANTINIDIS, outils de construction du logiciel, Hermès.


167

spécification ou de gestion des exigences, cela est particulièrement le cas. 11.5. Utiliser de multiples techniques et formalismes Dans le domaine de l’ingénierie des exigences, il n’y a pas de voie toute tracée, ni pour chercher l’information, ni pour la représenter. En ce qui concerne le recueil, la méthode la plus utilisée est l’interview des représentants des utilisateurs. C’est une pratique de base, presque incontournable pour les applications de gestion. Mais rien n’interdit d’expérimenter d’autres techniques de recueil à l’occasion d’un projet, afin d’en apprécier l’efficacité. Le remue-méninges (brainstorming) est une technique relativement aisée à mettre en œuvre et peut apporter des résultats intéressants. De nombreuses entreprises mettent en œuvre des maquettes ou des prototypes, mais on oublie parfois que le maquettage peut faire appel à des outils très simples : une feuille de papier, ou un tableau blanc, et des feutres de couleurs, ou une simulation d’enchaînement d’« écrans » représentés sur le papier. Des outils de ce type peuvent être expérimentés avec un coût très faible pour le projet. Pour ce qui est de la spécification, certains experts ne jurent que par les cas d’utilisations (les use cases) et optent pour une représentation graphique de ceux-ci. D’autres se servent des cas d’utilisation, sous une forme uniquement textuelle, et n’utilisent les schémas qu’avec parcimonie. Certains modélisent les processus métier sous forme graphique, alors que d’autres ne font des schémas que pour représenter les modèles de données.

168


Là aussi, il est utile d’expérimenter de nouvelles techniques qui viendront enrichir la palette du consultant ou du maître d’ouvrage. 11.6. Maquetter et prototyper juste ce qu’il faut Comme nous l’avons indiqué, maquettes et prototypes sont d’excellents moyens de valider les exigences et, par feed-back, d’en obtenir de nouvelles. Ils permettent de réduire les risques et les incertitudes. Mais les opérations de maquettage et de prototypage ont un coût. Pour investir intelligemment, il faut y investir juste assez. Pour les maquettes, les outils les plus frustes sont souvent les plus efficaces. Une grande feuille de papier et des marqueurs de couleurs permettent d’imaginer l’application sans perdre de temps à fignoler. Utiliser des outils complexes et soigner les détails risquent de donner aux utilisateurs de faux espoirs en leur faisant croire que l’application est presque finie. Un maquettage et un prototypage « fin » ne sont pas toujours indispensables. Quant aux prototypes verticaux, ils doivent se limiter aux fonctions ou aux propriétés à démontrer ou à valider : sécurité, fiabilité, interopérabilité, etc. Affiner un prototype sur une exigence ou un aspect particulier du produit peut conduire à négliger les autres aspects ou exigences. Pour éviter les dérives, le meilleur moyen est de planifier rigoureusement et de suivre toutes les activités de prototypage.

CHAPITRE 12

Aspects managériaux et facteurs humains

12.1. Savoir quels sont les acteurs Parmi les acteurs d’un projet, le plus important est celui qu’il est convenu d’appeler « le client ». Cette dénomination est trompeuse, car le client n’est pas une personne unique, ni même une entité organisationnelle unique. Le client est celui qui : – demande un produit ou une prestation ; – paie ou finance le produit ou la prestation ; – fait un choix de solution ou de produit, sélectionne un fournisseur ; – spécifie les besoins ; – utilise le produit logiciel ; – utilise les résultats produits par le logiciel. D’une manière générale, le client est celui qui est susceptible de retirer un bénéfice de l’utilisation du produit. De la même façon,

170


le « fournisseur » du produit est celui qui conçoit, développe ou commercialise, et qui tire un bénéfice de la réalisation du produit. Au chapitre 4, nous avons décrit une étape importante du processus, à savoir l’analyse des parties prenantes. En réalité, les rapports de force et conflits d’intérêt entre les différents acteurs sont trop complexes pour tenir sur une page de tableur. Connaître les parties prenantes est un effort continu, et la compréhension des différents acteurs doit s’affiner tout au long du projet, grâce à une écoute continue des besoins exprimés, mais aussi, et surtout, des non-dits. 12.2. Ne pas croire que le client a toujours raison Formulé de cette manière, cela peut paraître choquant, mais c’est un fait indiscutable : le client n’a pas toujours raison. Si le client avait toujours raison, il formulerait d’emblée des exigences non ambiguës et cohérentes. C’est rarement le cas. Tout d’abord parce que le client n’est pas un individu, mais une organisation : différents points de vue s’affrontent, et les besoins sont très différents d’un individu à l’autre. Ensuite par ce que, même chez un individu unique, les désirs, les besoins et les envies sont rarement gérés par objectifs et par priorités décroissantes. Le rôle du consultant est souvent un rôle d’animateur, de médiateur et de négociateur. Sans entrer dans les détails de l’art d’animer un groupe de travail, rappelons qu’en cas de divergence d’opinion, celui qui a raison n’est : – ni celui qui a parlé le dernier ; – ni celui qui parle plus fort que les autres ; – ni celui qui a réussi à manipuler les autres pour imposer son point de vue ;


171

– ni la majorité contre la minorité ; – ni le plus ancien dans le grade le plus élevé. La meilleure manière d’obtenir un consensus sur les exigences est d’avoir obtenu au préalable un consensus sur les objectifs. C’est aussi un des seuls moyens, pour un consultant, d’éviter de se faire prendre au piège de l’ambiguïté et de la contradiction. Sur le plan opérationnel, la recherche de consensus et la négociation peuvent être inscrites dans le processus. La connaissance est partagée entre le client et le fournisseur : le client connaît bien le problème ; le fournisseur est responsable de la solution. Lorsque le client demande une modification dans les exigences déjà exprimées et spécifiées (souvent en cours de mise en œuvre), la première chose à faire est d’analyser l’impact de cette demande de changement. Certaines demandes dont la mise en œuvre paraît a priori très simple demanderont en réalité un effort beaucoup plus important que celui initialement prévu. D’autre part, une modification en apparence minime peut avoir des effets importants sur l’architecture du produit. Une série de petites modifications « anodines » peuvent fragiliser le produit, le rendre moins maintenable. Faire de l’analyse d’impact un passage obligé est une pratique qui améliorera sensiblement l’efficacité de l’organisation de développement, et son professionnalisme. Sans ce passage obligé, les modifications dépendront essentiellement de la bonne volonté et du caractère des développeurs : les conciliants qui disent oui à tout, et les réfractaires qui disent non par principe. Ces deux positions extrêmes sont également préjudiciables. Les besoins évoluent, les contraintes et les règles de gestion changent, et de nouvelles idées germent. Avant de répondre oui ou non, il est nécessaire d’analyser l’impact du changement.

172


12.3. Gérer les priorités dynamiquement et chercher le consensus Les nouvelles exigences, et les changements aux exigences, peuvent arriver à tout moment : pendant le recueil des besoins, lors de sa formalisation, pendant le développement ou après la mise en production. Nous avons indiqué l’importance de l’analyse d’impact sur la bonne gestion du projet et la qualité du produit. L’analyse d’impact servira également à déterminer la priorité d’une nouvelle exigence ou d’un changement d’exigence. Gérer les priorités permettra de ranger toute nouvelle demande en trois grandes catégories : – celles qui ne seront pas mises en œuvre, pour des raisons à justifier ; – celles qui seront mises en œuvre pour la prochaine version du produit ; – celles qui seront prises en compte ultérieurement, sur une version ultérieure. Négocier ou renégocier les priorités des exigences au fil de l’eau est un travail indispensable. Assigner des priorités permet de sortir du piège manichéen du client « qui a toujours raison » et du client « qui nous empoisonne la vie avec des nouvelles demandes imprévues ». Spécifier un processus avec un circuit des demandes de changement bien identifié permettra de dépassionner le débat. La réponse du développeur ou du chef de projet ne sera jamais un oui ou un non à chaud, mais « votre demande a été enregistrée et sera étudiée dans les quarante-huit heures » ce qui est tout de même beaucoup plus professionnel.


173

12.4. Connaître le coût et la valeur de chaque exigence Comme nous l’avons vu, déterminer les priorités entre exigences revient à les classer en fonction de leur coût estimé et du bénéfice escompté. Il est donc important de connaître, et de faire connaître, le coût de chaque exigence. Il est également important de chercher à connaître sa valeur, de manière à être capable de prendre les bonnes décisions le moment venu. L’exercice est beaucoup plus difficile qu’il n’y paraît à première vue. Pour les exigences fonctionnelles, une estimation peut être faite par la méthode des points de fonction, ou par une méthode plus grossière (ainsi, en fonction du nombre d’écrans, d’états de sortie, etc., on peut calculer le coût de développement). Pour les exigences non fonctionnelles, les choses sont moins évidentes. Comment chiffrer, par exemple, une exigence de fiabilité ? Entre une application disponible 360 jours par an, et la même application disponible 364 jours, quelle est la différence réelle de coût de développement et d’exploitation ? On peut se poser la même question pour toutes les exigences non fonctionnelles : quel est le coût de l’ergonomie, et quels en sont les bénéfices ? Quel est le prix à payer pour rendre une application portable, et que va apporter cette caractéristique supplémentaire ? Les entreprises possédant de véritables indicateurs sur le sujet, et donc capables de mener l’exercice jusqu’au bout, sont encore bien rares. Cependant, l’important n’est pas d’obtenir des résultats précis, mais de faire l’exercice chaque fois qu’une exigence émerge. De se poser la question : est-ce que le bénéfice apporté sera à la hauteur du prix payé ? Se poser la question et consigner par écrit l’état de la réflexion est un pas important vers une utilisation plus rationnelle des budgets et des ressources.

174


12.5. Gérer la qualité, par la qualité et avec la qualité du produit On constate que de nombreux documents de spécifications d’exigences (cahier des charges, ou document équivalent) accordent une place majeure à la description des fonctions du système, au détriment des exigences non fonctionnelles. Or, il est essentiel, non seulement de les spécifier rigoureusement, mais d’intégrer l’aspect « qualité du produit logiciel » dès la phase de définition des objectifs. Ces contraintes non fonctionnelles devront être suivies, tracées et développées tout au long du processus de spécification des exigences. Si, lors de la phase d’objectifs, on déclare que l’application à venir sera « sécurisée » ou « à haute disponibilité », ou « ergonomique », ces exigences seront déclinées et précisées au niveau du cahier des charges. Certaines d’entre elles donneront lieu, à un point du processus, à des exigences fonctionnelles. Par exemple, si la sécurité de l’application est un objectif stratégique, il est fort probable que la déclinaison de cet objectif dans le cahier des charges se traduise par des fonctions spécifiques à la sécurité (fonctions d’accès, fonction de contrôle, de supervision). Mais, même dans les cas où une exigence non fonctionnelle ne constitue pas un objectif majeur, il est utile de « visualiser » le produit à venir sous ses aspects non fonctionnels. 12.6. Alterner rigueur et imagination Le secret de l’ingénierie des exigences est peut-être là. Certaines techniques font appel à l’intuition et à l’imagination. Les formaliser outre mesure leur ferait perdre de leur efficacité. C’est le cas du brainstorming, basé sur la créativité des


175

intervenants. D’autres techniques, comme la modélisation des données, exigent un formalisme rigoureux. Toutes ces techniques ont leur utilité à un moment de la phase d’exigences, variable selon le type de produit développé, les acteurs et le contexte de l’entreprise. Généralement, on commence par des techniques créatives, pour formaliser progressivement. Mais même là, il ne s’agit en aucun cas d’une règle générale. Certaines techniques plus complexes, comme QFD, allient créativité et rigueur. C’est le savoir-faire et l’expérience de « l’ingénieur des besoins » ou du consultant qui permettra de choisir la meilleure technique. 12.7. Choisir un représentant des utilisateurs dynamique et volontaire Choisir la bonne personne (et le plus souvent, les bonnes personnes) pour représenter les utilisateurs est crucial. Pour les projets d’une certaine importance et les produits utilisés par de nombreux utilisateurs, on sélectionnera au moins un utilisateur par profil. Il est important de choisir de véritables utilisateurs, et non pas une personne censée les représenter, mais qui ne sera pas effectivement opérationnelle avec le produit. Les critères de choix des représentants des utilisateurs sont nombreux, et il faudra toujours faire des compromis. Voici quelques suggestions de profils d’utilisateurs :

176


– métier : gestionnaire, médecin, personnel médical non médecin ; – fonctions utilisées : consultation, recherche, mise à jour ; – expérience dans le domaine : profil « débutant » et profil « expert » ; – fréquence effective d’utilisation : utilisateur quotidien ou occasionnel ; – droits d’accès au système : utilisateur ordinaire, administrateur. Lorsque l’on recherche un volontaire pour représenter les utilisateurs, ce sont souvent des managers qui sont désignés ou qui se portent volontaires. Ce n’est pas le meilleur choix. Chaque fois que cela est possible, le représentant des utilisateurs doit être choisi aussi bas que possible dans la hiérarchie. Si l’application doit être utilisée par une secrétaire ou par un manutentionnaire, ce n’est pas leur patron qui pourra exprimer leurs besoins à leur place. 12.8. Garder en permanence le contact avec les utilisateurs On n’insistera jamais assez sur la nécessité d’impliquer autant que possible les utilisateurs. Le contact entre futurs utilisateurs et développeurs devra être aussi direct, permanent, rapproché et multiple que possible : – le contact sera direct : les représentants des utilisateurs devront être véritablement représentatifs, opérationnels ; ils pourront communiquer avec les développeurs ; – le contact sera permanent : on voit trop souvent les représentants des utilisateurs apparaître au lancement du projet, à quelques rares comités de pilotage, et lors de la recette ; les représentants seront présents lors des réunions de


177

travail entre maîtrise d’ouvrage et maîtrise d’œuvre, et leur avis devra être sollicité chaque fois que nécessaire ; – rapproché : si l’utilisateur est en province, il faudra se déplacer de temps en temps ; lors des réunions de travail, si les déplacements sont difficiles, on utilisera autant que faire ce peut la téléconférence ou la vidéoconférence ; on tiendra les utilisateurs périodiquement informés par courrier électronique de l’avancement du projet ; – multiple : en phase de recueil des besoins, on rendra visite à des utilisateurs de profils différents ; plus on recueillera d’avis différents, plus on résoudra les conflits en amont, et plus on aura d’utilisateurs satisfaits lors de la réception du produit. 12.9. Informer et faire participer toutes les parties prenantes Faire participer les utilisateurs est indispensable, mais il ne faut pas en oublier pour autant les autres parties prenantes. Par exemple, la direction générale, le marketing ou les équipes de test. La difficulté est ici de s’exprimer dans un langage compréhensible par tous et de donner à chacun les informations dont il a besoin. Par exemple, l’équipe de test à besoin de connaître le plus tôt possible le calendrier des livraisons et le contenu de chaque version du produit, de manière à préparer les tests le plus tôt possible (les tests pouvant nécessiter de réserver des matériels rares et chers, par exemple, ou de mobiliser de nombreuses personnes). De plus, les équipes de test ont besoin d’être informées rapidement des changements sur les exigences, pour les mêmes raisons que précédemment.

178


Des outils de gestion des changements peuvent être très utiles sur ce point. Mais l’outil le plus perfectionné ne remplacera jamais totalement la communication de personne à personne. 12.10. Perdre du temps pour en gagner L’ingénierie des exigences est un investissement extrêmement rentable. Pour s’en convaincre, il suffit de se rappeler qu’une erreur de spécification d’exigences coûte en moyenne : – deux fois plus cher à corriger lorsqu’elle est détectée en phase de conception ; – environ trois fois plus cher à corriger pendant la phase de réalisation ; – presque vingt fois plus cher à corriger en phase de tests ; – plus de cent fois plus cher à corriger sur un logiciel en exploitation. Le coût d’une erreur croît exponentiellement en fonction de la phase du projet pendant laquelle elle est détectée. Des centaines d’articles, de conférences et de présentations ont été faites sur l’utilité de détecter les erreurs au plus tôt. Comme cette expression de « détection d’erreurs » est un peu rebutante, tant pour les managers que pour les techniciens, nous lui préférons une image moins rigoureuse mais plus dynamique, celle de l’investissement et du retour sur investissement. Elle est illustrée par la figure 12.1. Il est difficile de convaincre une direction d’investir sensiblement plus que d’habitude dans le recueil des besoins, l’élaboration du cahier des charges, et la gestion des exigences en cours de projet. Il s’agit pourtant d’un des meilleurs investissements qui soient.


Objectifs + exigences

179

Conception, réalisation et tests

Objectifs + exigences

Conception, réalisation et tests

Coût (ou délai) Figure 12.1. Investir dans le développement des exigences

CHAPITRE 13

Trois études de cas

13.1. Une histoire de communication Dans quelle mesure le respect des bonnes pratiques en matière d’exigences contribue-t-il à la réussite d’un projet ? Voici trois cas réels, exposés ici sans complaisance. Aucun des trois n’est un ratage complet, ni une parfaite réussite. En apparence, ces projets ont peu de points communs. Pourtant, en les examinant de près, et en analysant les causes profondes des échecs, apparaît une image en filigrane : celle de la communication entre client et fournisseur, dont la nature coopérative ou conflictuelle est déterminante à la réussite ou à l’échec d’un projet. 13.2. Cas numéro 1 : le RAD perverti Le RAD (rapid application development) est une technique permettant de développer beaucoup plus vite que les méthodes traditionnelles. Le concept, introduit par James Martin au début des années 1990, a été très à la mode dans la décennie qui a suivi, et a été repris par toutes les méthodes dites agiles. Plus vite, moins cher, et mieux.

182


Cette rapidité repose sur quatre principes : – les outils, qui doivent être puissants et adaptés ; – les méthodes, où certaines procédures « bureaucratiques » doivent être automatisées ou allégées ; – les personnes, qui doivent avoir reçu toute la formation nécessaire à l’utilisation de ces méthodes et outils ; – le style de management, qui repose plus sur une coopération étroite entre fournisseur et client que sur les rapports de force. Le cas que nous allons décrire ci-dessous est exemplaire, par l’enchaînement des erreurs de pilotage et de conduite de projet, par l’application irraisonnée, inadaptée, de concepts à la mode, et surtout par une très faible communication entre maîtrise d’ouvrage et maîtrise d’œuvre, alors que la communication constitue justement un des facteurs-clés de la réussite. Le maître d’ouvrage est un bureau d’une administration française, chargé d’octroyer et de gérer des prêts. Il n’a pas l’expérience du pilotage de projet, n’a pas de connaissances techniques et ne fait pas appel à un consultant (assistant à la maîtrise d’ouvrage) pour l’aider dans ces choix et suivre les travaux. Il est donc à la merci des bonnes et des mauvaises décisions de la maîtrise d’œuvre. Le maître d’œuvre est la direction informatique de la même administration. Les équipes de développement ont une longue expérience du développement Cobol sur grand système, autant dire à mille lieux des techniques et outils de développement rapide. Cependant, attiré par les sirènes du RAD, le directeur informatique fait le choix d’un outil de développement rapide client-serveur orienté objet, très à la mode à l’époque. Il a fait un premier pas dans la « modernité », mais néglige tout le reste : la mise en place de nouvelles méthodes, la formation des


183

personnes, le changement de style de management. Avoir des outils de développement rapide ne suffit pas. Encore faut-il avoir formé les équipes de développement au maniement de ces outils, et surtout, aux méthodes dont ces outils ne sont que le support1. C’est dans ces conditions à hauts risques que le bureau des prêts fait appel à la direction informatique pour le développement d’une application de gestion des prêts. Mais deux erreurs majeures vont mener le projet à l’échec : une croyance totalement erronée concernant les méthodes et les outils de développement rapide, et un mépris vis-à-vis des besoins des utilisateurs. Les outils RAD permettent en effet de mener de front la conception (le design, au sens anglais du terme) et la programmation. Le même outil est utilisé par l’architecte et par les programmeurs. De plus, les possibilités de prototypage rapide offertes par l’outil permettent au client de réagir directement au vu d’un prototype pour mieux préciser ses besoins. Les exigences peuvent donc être définies de manière itérative, par feed-backs successifs. Cependant, définir les exigences par petits morceaux ne signifie absolument pas qu’il est possible de ne pas les définir du tout. L’attitude du directeur informatique se résume ainsi : « nous connaissons vos besoins, nous avons des outils de développement rapide, nous allons faire du RAD, vous aurez votre application en trois semaines ». Il traite l’utilisateur par le mépris, alors même que la méthode préconise une communication forte entre développeurs et utilisateurs. Plus grave encore est l’interprétation erronée de l’expression développement rapide et de ce qu’elle sous-entend : moins de bureaucratie dans les relations entre maîtrise d’œuvre et maîtrise 1. James Martin, l’initiateur du RAD, parle de SWAT (skilled with advanced tools : expérimentés et armés d’outils avancés).

184


d’ouvrage. En effet, l’absence quasi totale de « paperasse » doit être compensée de deux façons : d’une part, le dialogue entre client et fournisseur, qui doit être permanent (avec des sessions de travail communes, longues et répétées), et d’autre part, les décisions prises en commun, qui, plutôt que d’êtres consignées sur le papier, doivent être immédiatement intégrées dans l’outil. Or, ce fut loin d’être le cas dans cette administration. Le dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre était superficiel, informel, emprunt de suspicion et de mépris réciproque ; autant dire absent. De plus, l’architecte connaît très mal le domaine d’application, à savoir la gestion des prêts. Les programmeurs, eux, sont des praticiens expérimentés, mais peu habitués à prendre du recul, à examiner les exigences fonctionnelles et non fonctionnelles, à communiquer avec le maître d’ouvrage et les futurs utilisateurs. Ce sont avant tout des techniciens, formés à la vieille école où l’informaticien était roi, et imposait sa solution au client. Ils ont utilisé l’outil de développement de manière purement technique, sans tirer profit de la méthodologie sous-jacente. Tout le contraire du RAD. De cette attitude découlent toutes les autres erreurs. Par exemple, le manque de soin apporté aux aspects ergonomiques. Utiliser des outils « modernes » n’est en aucun cas une garantie d’obtenir une application « ergonomique ». Cette fausse idée continue de faire des ravages. Si les outils se révèlent de précieux alliés, en apportant de la souplesse, en aucun cas ils ne « font » l’application. Et plus ils sont puissants, plus les dégâts risquent d’être grands. En l’absence d’un ergonome attitré, il est nécessaire d’avoir à disposition (et d’appliquer) des règles d’ergonomie et un guide de conception. Cela n’a pas été le cas. Résultat : l’application


185

était beaucoup plus difficile à utiliser que les précédentes, développées sur gros systèmes. Le design et l’ergonomie de l’application ne peuvent que résulter d’une connaissance du métier des utilisateurs et/ou d’une étude approfondie de leur comportement. En l’absence de cahier des charges, (qui pourrait certes être réduit dans le cas de développement « rapide », mais non inexistant), les vrais besoins des utilisateurs n’ont pas pu être pris en compte. Voici la fin de l’histoire : l’application a effectivement vu le jour. Elle n’a été pleinement opérationnelle que trois ans plus tard (à comparer aux « trois semaines » initialement annoncées2). Les utilisateurs se plaignaient fréquemment d’un manque de fiabilité. Les fiches d’anomalie s’entassaient sur le bureau du chef de projet, dépassé par les événements. Les « rustines » venues réparer les conséquences de besoins mal compris ont fragilisé l’application, devenue de plus en plus difficilement maintenable. Les exigences « évolutives » furent considérées comme un luxe et jamais prises en compte. Un audit, à la demande de la maîtrise d’ouvrage, a conclu qu’il serait plus économique de développer l’application à nouveau (ou d’opter pour un progiciel) plutôt que de s’acharner à la maintenir. Plusieurs enseignements peuvent être tirés de cette analyse : – tout d’abord, la définition des exigences est une étape incontournable, dans tous les cas de figure. Dans le cas d’un développement itératif, le cahier des charges sera certes plus léger. Probablement, il n’aura pas la forme d’un cahier des charges classique. Les exigences seront recueillies quasiment en continu, mais elles devront être effectivement consignées, négociées et validées ;

2. Ce rapport de 1 à 50 entre une première estimation faite à la légère et le délai réel semble excessif, mais n’est pas exceptionnel sur un projet de développement.

186


– d’autre part, le dialogue entre client et fournisseur doit être d’autant plus fluide que le développement est de type itératif et les exigences recueillies au fil de l’eau. Plus le développement se veut rapide, et plus le contact doit être direct entre ceux qui conçoivent et développent et ceux qui vont utiliser ; – enfin, ce type de développement nécessite un suivi de projet rigoureux, et surtout une grande maturité de la maîtrise d’ouvrage, qui doit être capable de participer effectivement au suivi du projet. 13.3. Cas numéro 2 : la lourdeur qui tue Le client est une grande entreprise nationale. Le fournisseur est un consortium composé d’une grande SSII et d’une start-up avant la lettre, spécialisée dans des logiciels de pointe. La SSII a des méthodes rigoureuses mais tous les ingénieurs n’ont pas reçu la formation nécessaire. Le client a aussi ses méthodes, lourdes, rigides, peut être même un peu dépassées. Quant à la start-up, elle n’a aucune méthode, ni pour la conception, ni pour la gestion de projet. Tous les salariés, du directeur général à l’ingénieur débutant, sont de brillants développeurs se comportant en « héros ». Trois cultures différentes vont alors s’affronter. Les dissensions commencent dès la réception du cahier des charges. Voici une liste épaisse d’exigences (plusieurs centaines de page), présentées avec rigueur selon un formalisme très précis. La SSII, qui justifie sa présence par l’existence et la mise en œuvre de méthodes rigoureuses, va respecter ce formalisme à l’extrême. Quant à la start-up, elle va jouer au « bon élève » en respectant le formalisme à la lettre, mais sans en comprendre l’esprit.


187

La rigueur n’exclut pas l’imagination. Mais l’application rigide de méthodes mal maîtrisées inhibe l’imagination. Voilà que la start-up perd son atout. Son attitude de bon élève (sur la forme seulement, car sur le terrain les personnes travaillent en mode réactif comme avant) la conduit à formuler des exigences produit qui ne sont qu’une paraphrase du cahier des charges initial. Ces spécifications d’exigences au niveau détaillé du produit occupent plusieurs volumes, mais elles ne présentent que peu d’intérêt pratique. Ce manque d’imagination sur le contenu, allié à un respect servile de la forme, s’est fait ressentir à tous les niveaux. Par exemple, la personne chargée des facteurs humains, c’est-à-dire de l’ergonomie, a mis toute son énergie à respecter à la lettre les documents types. Mais une véritable étude ergonomique n’a jamais été faite. Elle n’aurait pourtant coûté qu’une fraction du coût du projet. La rigueur dans la conduite d’un projet est une bonne chose, mais cela n’implique pas d’enfermer les développeurs dans un cadre rigide et leur interdire toute expression de leur imagination. Après plus de six mois de conception et plus d’un an de développement, la lassitude a gagné les plus enthousiastes d’entre eux. Certes, la maîtrise d’ouvrage était satisfaite pendant les premières étapes. Sur la forme, toutes les procédures étaient respectées, et les spécifications détaillées étaient conformes aux exigences. Toujours sur la forme, les programmeurs respectaient les spécifications détaillées. Et les exigences spécifiées correspondaient assez précisément au besoin de l’utilisateur. Sur la chaîne entre les besoins et le produit, tous les maillons semblaient solides. Du moins en apparence. Pourtant, l’application finale a donné lieu à un rejet immédiat de la part des utilisateurs. Alors, que s’était-il passé ? Où était la

188


faille ? Une analyse plus fine du déroulement du projet a apporté un éclairage intéressant. Tout d’abord, les utilisateurs ont été effectivement consultés, comme la méthodologie en vigueur l’exigeait. Leurs besoins ont été effectivement consignés dans un cahier des charges, dûment validé. Mais une fois passée l’étape de recueil des besoins, les utilisateurs du « terrain » n’ont reçu aucune information, et n’ont évidemment pas pu donner leur feed-back. L’ensemble des utilisateurs de cette application nationale était représenté par une seule personne, très rarement invitée à regarder le produit en cours de développement. Lorsque l’avis de cette personne a été sollicité, que les développeurs ont eu l’occasion de discuter avec elle, la prise en compte de son feed-back ne s’est faite que par l’initiative de quelques développeurs de bonne volonté. Chassez le naturel, il revient au galop. Les « développeurs fous » de la start-up, qui n’avaient pas eu l’occasion de mettre leur imagination au service du client (on leur avait interdit toute initiative lors des spécifications), se sont mis à faire de la créativité là où justement il était nuisible d’en faire : on a vu apparaître de beaux écrans de toutes les couleurs, des icônes de formes diverses et variées, des fonctions « clandestines », jamais demandées par la maîtrise d’ouvrage. De belles initiatives individuelles, contribuant à la laideur et à l’inutilité de l’ensemble… et à la dérive des délais. Le produit a fini par être livré au client, mais le projet a duré deux fois la durée initialement estimée, et a coûté deux fois et demi le budget prévu. L’insatisfaction et la frustration a été ressentie chez le client, le maître d’œuvre, la start-up sous-traitante. Peu d’utilisateurs


189

finals ont véritablement travaillé sur le produit, qui a été rapidement abandonné. En d’autres termes, le fiasco a été total. On peut tirer plusieurs conclusions de cette affaire : – rigueur et imagination ne sont pas exclusives ; au contraire. C’est en fixant un cadre rigoureux que l’imagination pourra être mise au service d’un client ; une fois que les règles sont claires pour tous et acceptées par tous, la créativité est source de productivité ; mais dans le cas de règles incomprises, respectées uniquement pour la forme, la créativité sera une source de désordre ; – les exigences doivent être traitées non seulement en phase dite « d’exigences » mais tout au long de la conception et de la réalisation ; les pratiques et procédures de conception et de réalisation doivent permettre la prise en compte de nouveaux besoins ; – l’utilisateur doit être présent tout au long du projet ; si l’on nomme quelques représentants des utilisateurs, surtout dans le cadre de grands projets, ils doivent venir du terrain, et être effectivement représentatifs ; et ils doivent avoir le pouvoir d’intervenir chaque fois que nécessaire pour changer les exigences. 13.4. Cas numéro 3 : la simplicité gagnante Ce projet avait l’air « mal parti ». Mais, même lorsqu’il arrive apparemment trop tard, un bon cahier des charges peut avoir un effet très positif sur un projet. Le maître d’ouvrage est une grande administration. Le maître d’œuvre est la direction des systèmes d’information de cette même administration, chargé de développer une application de gestion.

190


C’est une application très spécifique. Il n’y a pas d’« expert métier » extérieur, comme il peut y en avoir un sur une application bancaire, par exemple. Quelques centaines d’utilisateurs, répartis sur tout le territoire national, utilisent déjà l’application existante, qui doit être remplacée. Cette application est gérée localement, et peu de données sont échangées avec l’administration centrale parisienne, par transfert de fichiers. La maîtrise d’ouvrage, basée à Paris, prévoit des évolutions ambitieuses. La nouvelle application sera hébergée sur un site central, et accessible aux administrations locales au moyen d’échanges sécurisés. Les données des différentes administrations locales pourront être remontées et utilisées à des fins statistiques, après avoir été « anonymisées » selon les règles. Comme c’est souvent le cas, l’objectif initial pourrait être formulé comme suit : « La nouvelle application remplacera l’ancienne. Elle sera fonctionnellement identique à la précédente, mais comportera les fonctionnalités suivantes, en particulier des traitements statistiques… ». C’est là le premier piège dans lequel tombent souvent ceux qui doivent formuler des objectifs et des exigences de haut niveau. On prétend vouloir faire « comme avant, avec des améliorations », que l’on appelle « isofonctionnel amélioré ». Il s’agit là d’un piège car : – les technologies évoluant, et les besoins aussi, on ne fait jamais « comme avant » ; les nouvelles technologies offrent des possibilités qui excitent l’imagination de ceux qui doivent formuler des exigences ; – l’existant est rarement décrit ; si l’on veut faire « comme avant », encore faut-il savoir de quoi l’existant est fait ; en l’absence de cahier des charges de l’application à réécrire, ce


191

sont les développeurs qui devront faire des hypothèses ; et l’imagination des développeurs correspond rarement aux besoins des utilisateurs. La maîtrise d’ouvrage a donc commencé à rédiger un cahier des charges pour la nouvelle application. L’élaboration de ce document avançait difficilement car, si la maîtrise d’ouvrage connaissait bien son métier et ses besoins, cela était loin d’être suffisant pour structurer un cahier des charges dans les règles de l’art. Lasse d’attendre, la maîtrise d’œuvre harcelait la maîtrise d’ouvrage, qui a commencé à lui communiquer le cahier des charges par morceaux et sous une forme non définitive. Les concepteurs et développeurs interprétaient ces spécifications comme ils pouvaient, et le logiciel était développé ou maquetté par morceaux, de manière souvent « imaginative » (c’est-à-dire interprétée sans connaissance du besoin de l’utilisateur) ; tous les mois ces différentes personnes se rencontraient pour faire le point. Vue la manière de procéder, ces réunions (qui par ailleurs duraient plusieurs heures) ressemblaient parfois à des parties de pugilat. Une chose a cependant sauvé ce projet : la communication entre maîtrise d’œuvre et maîtrise d’ouvrage n’a jamais été coupée. Les rapports étaient tendus, certes. Conflictuels, même. Mais sur un projet comme dans une famille, il vaut mieux se disputer de temps en temps que de cesser de se parler. C’est là que maîtrise d’ouvrage et maîtrise d’œuvre ce sont mis d’accord sur un point : ils ne s’en sortiraient pas tout seuls. Mieux valait faire appel à un conseil à la maîtrise d’ouvrage.

192


Comme il n’existait pas d’expert métier dans le domaine (hormis le personnel de cette même administration), la personne retenue devait avoir deux qualités : savoir écouter les besoins, et savoir élaborer un cahier des charges. Après un recueil des besoins des utilisateurs dans les règles (interviews des utilisateurs en province, examen de l’application existante, lecture de la documentation, validation par les utilisateurs), un nouveau cahier des charges a été élaboré, en réutilisant le cahier des charges existant. Celui-ci n’était certes pas parfait (il péchait par un manque d’homogénéité, un mélange de détails techniques et de règles métier, et un manque de structure d’ensemble), mais il décrivait la plupart des cas d’utilisation. Sur ce projet complexe, le « secret » consistait à faire au plus simple, sans faire simpliste. Les besoins, très différents pour chaque catégorie d’utilisateurs, poussaient les développeurs à complexifier inutilement l’application. Ils ont été structurés et priorisés. Les règles de gestion étaient moins nombreuses qu’il ne semblait au départ. Les règles d’ergonomie de base ont été clairement formulées dans le cahier des charges, et illustrées sous forme de dessins d’écran, à titre d’exemple. Quelques mois plus tard, le projet était remis sur les rails. Le temps initialement prévu n’a pas été rattrapé, mais les dérives ont été stoppées et le projet a abouti. Quelle morale peut-on tirer de cette histoire ? – en premier lieu, que l’ingénierie des exigences est avant tout une ingénierie de la communication, et non une discipline purement technique ;


193

– ensuite, qu’il est nécessaire de prendre du recul : connaître les détails du métier est utile, à condition de ne pas perdre de vue le tableau d’ensemble ; – enfin, que dans les cas d’urgence, il faut simplifier : quelques bonnes règles bien comprises et bien appliquées valent mieux que des principes rigides et des procédures inapplicables.

CHAPITRE 14

Un nouveau métier : le designer de logiciel

14.1. Rigueur et innovation La qualité du logiciel a deux faces. L’une, austère, est celle de la stricte conformité aux attentes minimales des utilisateurs et aux normes en vigueur. L’autre, rayonnante, est liée au caractère innovant du logiciel. L’une est mesurée par le « coût de la non qualité », l’autre par les bénéfices induits par un produit attrayant, confortable, agréable. Un « bon » logiciel possède aussi ces deux faces. Il concilie rigueur et créativité. Mais un bon logiciel est une chose rare. La plupart des logiciels n’apportent que très peu d’innovations par rapport aux logiciels concurrents, qu’ils se contentent le plus souvent de copier, voire même de singer. Et trop de logiciels sont encore loin de satisfaire les exigences minimales des utilisateurs, qu’il s’agisse de fonctionnalité, de fiabilité ou de performances techniques.

196


Peut-on améliorer sensiblement la qualité du logiciel sur ces deux faces à la fois ? Améliorer les processus de développement est certes nécessaire, mais ne joue que sur la face « conformiste » de la qualité. A l’inverse, innover sans gérer l’évolution des exigences, sans respecter les normes, aboutit aux échecs que l’on sait. Que faut-il changer pour arriver à des logiciels véritablement satisfaisants et innovants ? Comme on le verra plus loin, l’industrie manufacturière, plus ancienne que l’industrie du logiciel, pourra nous donner des pistes intéressantes. Mais auparavant, examinons de plus près les constituants de la qualité du logiciel. 14.2. La construction de la qualité Pour obtenir un produit à haute valeur ajoutée, il est nécessaire de travailler sur toutes les caractéristiques à la fois, en cherchant un équilibre, en arbitrant entre les priorités, en tenant compte des contraintes de délai et de coût. Il ne s’agit pas tant de « faire bien du premier coup » comme on le dit souvent, que de « faire bien » sur les différents paramètres1, en fonction des objectifs à atteindre et de priorités fixées en amont du développement. Pour y arriver, plusieurs conditions doivent être réunies : – la qualité d’un produit logiciel doit être pensée en amont, dès la phase de définition des besoins ;

1. En particulier, les six directions de la qualité (fonctionnalité, fiabilité utilisabilité, maintenabilité, efficience, portabilité. Voir norme ISO/CEI 9126 et ISO 25000).


197

– elle doit être obtenue par construction ; le produit final doit être « visualisé » dès le départ (et non simplement décrit sur le plan fonctionnel) ; cela n’empêchera pas, au contraire, de modifier cette vision en cours de développement si de nouvelles idées surgissent ; – la construction de la qualité est une démarche continue, obtenue en maintenant la pression des exigences de qualité tout au long du cycle de vie du logiciel ; – c’est une démarche créative. Elle est spécifique au produit à développer. La construction de la qualité ne peut donc être entièrement formalisée ; – c’est une démarche participative, à laquelle doivent travailler tous les acteurs du projet (maître d’ouvrage, maître d’œuvre, architecte, etc.) ; – la qualité perçue, qui correspond en grande partie à la qualité en fonctionnement, dépend largement des exigences implicites des utilisateurs et doit également être pensée très en amont. En résumé, pour être de qualité, le produit logiciel doit être pensé de manière globale, en intégrant à la fois les aspects structurels (architecture) et les aspects comportementaux (ergonomie), la vision externe et la vision interne. Autrement dit, l’architecte, l’ergonome, le qualiticien, l’expert métier, et le marketing doivent pouvoir partager une vision commune et dialoguer de manière fluide. Le lien entre qualité du processus et qualité du produit ne peut exister qu’à ces conditions. Ainsi, le modèle ISO de la qualité du produit pourrait être revu et enrichi pour tenir compte de ces facteurs (figure 14.1).

198


Sensibilisation et formation des développeurs

Qualité du processus

Choix architecturaux

qualité interne

Application de l’ergonomie

qualité externe

qualité de fonctionnement

Satisfaction de l’utilisateur

Figure 14.1. De la qualité du processus à celle du produit : le modèle ISO 9126 revu

14.3. Le besoin d’un designer Actuellement, cette vision globale de la qualité est souvent insuffisante, voire absente. Les développeurs sont insuffisamment sensibles à l’ergonomie du logiciel, les ergonomes ne voient pas les contraintes techniques, et les qualiticiens ne sont pas en contact avec l’utilisateur. La conséquence de cette absence de vision globale se reflète dans beaucoup de logiciels, qu’il s’agisse de produits sur étagère ou d’applications spécifiques. La démarche habituelle consiste à partir d’un cahier des charges purement fonctionnel, auquel on annexe des contraintes techniques, et dans le meilleur des cas une charte d’ergonomie. Qui pense, qui visualise le logiciel à venir ? Le concepteur a trop souvent une vision technicienne du produit, le représentant des utilisateurs à souvent du mal à affirmer son point de vue. La maîtrise d’ouvrage (ou le marketing, dans le cas d’un produit sur étagère) manque souvent d’outils pour exprimer son point de vue. Le dialogue s’établit difficilement.


199

Alors, trop souvent, on se contente de copier les produits du concurrent, ou de réécrire l’application précédente sans imagination plutôt que d’innover. Le produit final est un produit banal. Même s’il arrive en temps voulu, même s’il respecte formellement les exigences exprimées (ce qui est encore trop rarement le cas) il lui manquera justement la qualité de fonctionnement qui en fera un outil puissant, facile, sûr et agréable à utiliser. Inversement, on trouve sur le marché des produits innovants, originaux, mais qui manquent manifestement de sérieux : peu fiables, peu performants, et ne respectant pas les règles élémentaires de l’ergonomie. Comment concilier la qualité-rigueur avec la qualité-innovation ? Ce qui s’est opéré dans l’industrie manufacturière peut nous apporter des idées nouvelles. Pour sortir de la médiocrité habituelle, pour véritablement innover, tout en continuant à industrialiser l’élaboration du produit logiciel, nous devons mettre à jour un nouveau métier : le designer de produit logiciel. Un hybride entre l’architecte, l’ergonome, et le qualiticien. C’est un généraliste, qui établit et maintient le dialogue entre les différents acteurs, aux profils et aux vécus fort différents. Il allie intuition et expérience pour innover et formuler des solutions concrètes. C’est bien d’un designer que l’on a besoin. Non pas au sens de « concepteur d’application », mais au sens actuellement utilisé dans l’industrie manufacturière. Une personne possédant une double compétence, mais surtout une personne alliant deux qualités : rigueur et créativité.

200


14.4. Un homme de terrain, une vision stratégique Les designers de produit logiciel n’existent-t-ils pas déjà ? Dans une grande mesure, oui. On les trouve souvent sous l’appellation « assistant à la maîtrise d’ouvrage », « chef de produit », ou « consultant ». Il ne s’agit pas d’un métier en tant que tel, mais d’un ensemble de compétences acquises sur le terrain, assorties du recul nécessaire à une compréhension des objectifs. Le designer doit connaître les méthodes de développement, les nouvelles technologies, avoir un certain sens esthétique et des expériences variées dans le logiciel, mais quelques bonnes notions d’ergonomie sont également utiles. Il travaille, avec intuition et créativité, sur la qualité perçue, ce qui est bien plus qu’un ensemble de règles et de contrôles. Il imagine des solutions qui sortent des sentiers battus. 14.4.1. Avoir une vision globale L’ergonomie concerne le dialogue entre l’homme et le produit logiciel. Mais ce dialogue ne se limite pas à ce qu’il est convenu d’appeler « l’interface graphique ». Le dialogue touche au comportement du logiciel, et au-delà, à son architecture. Inversement, les choix initiaux des technologies à mettre en œuvre prennent en compte les contraintes de sécurité et de fiabilité, mais rarement l’impact sur l’utilisateur final. Cet impact est visible lorsque l’offre technologique est en phase de transition et que l’offre en nouvelles technologies est foisonnante. Un architecte « pur » a peu de chances de détecter les impacts de ce choix sur l’utilisabilité du produit final.


201

Un designer n’est pas nécessairement un architecte, mais il sait dialoguer avec les architectes, comprendre leurs préoccupations en termes de performances ou de sécurité, et éventuellement influer sur leur choix. Il a suffisamment de background technique pour influer sur les choix faits par les équipes de développement et leurs parler d’utilisabilité. Ceci nécessite une vision globale, à la fois de la structure et du comportement. 14.4.2. Naviguer dans la zone d’ombre Faire du design, c’est être capable de travailler sur toutes les phases amont, à commencer par la phase d’objectifs où se joue l’avenir du produit, mais aussi dans la « zone d’ombre » entre exigences et conception. Dans cette zone de flou viennent se cristalliser les non-dits, les conflits, la différence de langage et de culture entre informaticiens et gens du métier.

Retrait

Objectifs et concepts

Exigences

Exploitation et maintenance

Zone d’ombre Installation et déploiement

Conception

Tests et qualification

Réalisation

Figure 14.2. La zone d’ombre

202


14.4.3. Viser l’efficacité, percevoir l’esthétique, travailler sur l’élégance Le succès d’une application, comme le succès commercial d’un produit sur étagère, est lié à l’esthétique de ce produit. De plus, l’esthétique est elle-même un indicateur de la qualité. C’est une caractéristique difficilement formalisable, mais chacun de nous a vu des logiciels beaux, agréables à utiliser, et d’autres qui ne le sont pas. Le plaisir de l’utilisateur (et la productivité qui en résulte) n’est pas qu’une question de look. Il dépend aussi de la fonctionnalité, de la fiabilité, de l’architecture, et de la cohérence de l’ensemble de ces caractéristiques. Trop souvent, les logiciels actuels ne souffrent pas tant d’insuffisances que d’excès : trop de fonctions, trop de fenêtres, trop de boutons, de clics, de cases à cocher. Il en résulte des produits lourds, coûteux, peu maintenables et stressants pour l’utilisateur. Une des actions du designer est de simplifier, d’alléger, de limiter à l’utile. Il devrait être le garant d’un logiciel à la fois beau, efficace et économe. En d’autres termes, d’un logiciel élégant. 14.5. Quel avenir pour le designer ? Verra-t-on un jour le métier de designer logiciel (quel que soit le terme employé) enseigné à l’université ? On peut l’espérer. En attendant, on peut déjà esquisser quelques idées pour améliorer la qualité globale des logiciels : – les consultants intervenant en assistance à maîtrise d’ouvrage devraient lire quelques bons ouvrages sur l’ergonomie du logiciel, et les appliquer chaque fois que nécessaire ; – les maîtrises d’ouvrages des entreprises et administrations qui font appel à un consultant devraient s’assurer que ce dernier n’est ni un pur technicien, ni un pur expert métier, mais qu’il a


203

le souci de la qualité globale du produit : performances, qualité formelle et qualité perçue ; – les écoles d’informatique devraient inclure l’enseignement des notions élémentaires d’ergonomie du logiciel parmi les matières obligatoires.

CONCLUSION

L’objectif de ce livre était de proposer une démarche globale d’ingénierie des besoins, et d’apporter aux maîtres d’ouvrage, aux consultants et aux concepteurs de logiciel un éclairage sur les méthodes et les techniques qui peuvent être mises en œuvre dans le cadre de tout projet de développement de logiciel, du plus modeste au plus ambitieux. Cet ouvrage a été conçu comme un guide généraliste, à grandes mailles, et non comme un traité de l’ingénierie des exigences. Les lecteurs qui souhaitent approfondir certains sujets se reporteront utilement à la bibliographie en annexe, qui propose une petite sélection parmi les dizaines de bons ouvrages sur les différentes activités de l’ingénierie des besoins. Remarquons que la littérature en langue anglaise sur le sujet est foisonnante alors que les quelques ouvrages en français sont généralement plus techniques. Sur un projet de développement, l’application des techniques décrites ici peut apporter des gains substantiels sur les coûts, les délais ou la qualité du produit. Bien sûr, il reste un long chemin à parcourir pour mettre en œuvre les diverses techniques sur le terrain et en recueillir les fruits. Mais l’ingénierie des exigences

206


n’est pas monolithique. Les différentes techniques peuvent être introduites progressivement, adaptées au contexte et aux contraintes de l’organisation. Le gain est souvent très important, même avec un investissement modeste. En parcourant cet ouvrage, le lecteur a sans doute perçu un fil rouge : c’est la notion de design logiciel. Il ne s’agit pas tant d’une technique que d’une attitude visant l’amélioration du logiciel grâce à un dialogue entre les différentes parties prenantes, une synergie entre disciplines, et une vision globale du logiciel en tant que produit. Les éléments contenus dans ce concept de design logiciel n’ont rien de nouveau. C’est leur assemblage qui est nouveau. Certaines idées sont d’ailleurs puisées dans les pratiques de l’industrie manufacturière, qui a beaucoup à apporter à l’industrie du logiciel. L’ingénierie des besoins est une discipline dont l’importance va très probablement s’accroître considérablement dans l’avenir. Et ce, pour deux raisons convergentes : parce qu’elle constitue un énorme gisement de qualité et de productivité encore largement inexploré, et parce que le centre de gravité des activités de développement est en train de se déplacer vers les phases amont du cycle de vie. Le métier de « développeur », au sens large du terme, évolue en ce sens. Et la sous-traitance en off shore ne freinera pas cette tendance, bien au contraire. La qualité du produit dépendra plus que jamais de la pertinence de l’analyse et de la formalisation des besoins.

GLOSSAIRE

B, C Besoin : nécessité ou désir éprouvé par un utilisateur (AFNOR X50-150). Cahier des charges : document par lequel le demandeur exprime son besoin (ou celui qu’il est chargé de traduire), en termes de fonctions de service et de contraintes. Pour chacune d’elles, sont définis des critères d’appréciation et leurs niveaux. Chacun de ces niveaux doit être assorti d’une flexibilité (AFNOR X50-150). Client : le client (ou maître d’ouvrage) sera le propriétaire de l’objet du cahier des charges. Il est responsable de la définition des exigences, du financement, et de l’approbation de la solution. Contrainte : limitation à la liberté de choix du concepteur réalisateur du produit (AFNOR X50-150). Critère d’appréciation : caractère retenu pour apprécier la manière dont une fonction est remplie ou une contrainte respectée (AFNOR X50-150).

208


D Demande : expression, encore subjective et partielle, de la perception d’un besoin, à un instant donné. Domaine fonctionnel : ensemble d’activités concourant à une finalité de l’organisme.

cohérentes

E Ergonomie : discipline scientifique qui vise la compréhension fondamentale des interactions entre les êtres humains et les autres composantes d’un système, et la mise en œuvre dans la conception de théories, de principes, de méthodes et de données pertinentes, afin d’améliorer le bien-être des hommes et l’efficacité globale des systèmes (Association Internationale d’Ergonomie). Exigence : description formelle d’un objectif. L’appréciation de la satisfaction d’une exigence peut être mesurée. Etat de l’art : ensemble des règles respectées implicitement par les professionnels d’une activité. F Fonction : actions d’un produit, ou de l’un de ses constituants, exprimées exclusivement en termes de finalités (AFNOR X50150). Fonction de service : action attendue d’un produit (ou réalisée par lui) pour répondre à un élément du besoin d’un utilisateur donné (AFNOR X50-150).

Glossaire

209

Fournisseur : le fournisseur (ou maître d’œuvre) s’engage sur les conditions qu’il accepte : échéancier des livraisons, maîtrise des coûts, satisfaction des exigences. M, P Maquette : objet destiné à aider un client à spécifier ses demandes. Produit : ce qui est (ou qui sera) fourni à un utilisateur pour répondre à un besoin. Le produit peut être un objet, un fluide, une prestation de service, un processus industriel ou administratif (procédé, logiciel, procédure, etc.), ou toute combinaison de ceux-ci (AFNOR X50-150). Prototype : objet destiné à vérifier la faisabilité d’une solution sous un aspect particulier : conceptuel, organisationnel ou technique. Un prototype enchaîne des parties réelles (celles dont on veut montrer la faisabilité) et des parties fictives (en général, celles qui correspondent à des fonctions dont la réalisation ne semble poser aucun problème). Q Qualité : ensemble des propriétés et caractéristiques d’un produit, ou service, qui lui confère l’aptitude à satisfaire des besoins, exprimés ou implicites. La maîtrise d’ouvrage et l’utilisateur s’intéressent principalement à la qualité du produit, alors que la maîtrise d’œuvre s’intéresse à la qualité du processus. La qualité du processus contribue à la qualité du produit.

210


S Solution : ensemble coordonné de moyens matériels, logiciels, humains, organisés pour satisfaire un ensemble d’exigences. Spécification : traduction d’exigences en éléments techniques. Système : ensemble cohérent d’éléments matériels et logiciels en interaction dynamique, destiné à assurer une finalité préalablement définie. U UML (Unified Modeling Language) : langage standard, très largement diffusé, de représentation de l’information (données, traitements), principalement sous forme de diagrammes. Il ne s’agit pas d’une méthode. UP (Unified Process) ou PU (Processus unifié) : méthode de prise en charge complète du cycle de vie du logiciel, depuis les besoins jusqu’au produit. Elle s’appuie sur UML. Utilisateur : personne ou entité pour qui le produit a été conçu, qui exploite au moins une des fonctions du produit (AFNOR X50-150).

BIBLIOGRAPHIE

[BOE 88] BOEHM B.W., PAPACCIO P.N., « Understanding and Controlling Software Costs », IEEE Transactions on Software Engineering, vol. 14, n° 10, p. 1462-1477, octobre 1988. [CAZ 97] CAZAUBON C., GRAMACCIA G., MASSARD G., Management de projet technique, Ellipses, Paris, 1997. [COC 01] COCKBURN A., Rédiger des cas d’utilisation efficaces, Eyrolles, Paris, 2001. [CON 98] CONSTANTINIDIS Y., Outils de construction du logiciel, Hermès, Paris, 1998. [CON 01] CONSTANTINIDIS Y., Le logiciel à valeur ajoutée, la perspective de l’utilisateur, Hermès, Paris, 2001. [LAU 02] LAUESEN S., Software Requirements – Styles and Techniques, Addison Wesley, Addison-Wesley, Harlow, 2002. [NOG 05] NOGIER J.F., Ergonomie du logiciel et design Web : Le manuel des interfaces utilisateur, Dunod, Paris, 2005. [MID 05] MIDDLETON P., SUTTON J., Lean software strategies, Productivity press, New York, 2005. [THO 00] THORIN M., L’audit informatique, Hermès, Paris, 2000. [WIE 03] WIEGERS K., Software requirements, Microsoft Press, Washington, 2003.

SITES WEB UTILES

Les sites web sur l’ingénierie des besoins ne manquent pas. En voici une petite liste, par ordre alphabétique. ADELI, l’Association pour la maîtrise des systèmes d’information, a un site riche en documents téléchargeables : http://www.adeli.org Toutes les normes citées sont disponibles sur le site Internet de l’AFNOR : http://www.afnor.fr Le site de Donald Firesmith et du Open Process Framework n’est pas dédié à l’ingénierie des exigences, mais on y trouvera des informations utiles : http://www.donald-firesmith.com Karl E. Wiegers, un expert du domaine, apporte des recommandations et des modèles de documents (en anglais) : http://www.processimpact.com Volere, un site dédié à l’ingénierie des besoins, riche en ressources et en documents, dont un modèle très complet de cahier de spécifications d’exigences :

214


http://www.volere.co.uk Use it, le site de Jakob Nielsen, sur l’utilisabilité (en anglais) : http://www.useit.com Enfin, le site web de l’auteur de cet ouvrage est : http://www.yves-constantinidis.com

COLLECTION MANAGEMENT

ET INFORMATIQUE

sous la direction de Nicolas Manson

Alain Amghar – Conduite opérationnelle des projets, 2004 Alain Berdugo – Guide du management des SI, 2001 Alain Berdugo – Le maître d’ouvrage du SI, 1997, 2005 Alain Berdugo et Pierre Aliphat – Systèmes informatiques de l'entreprise, 1997 Gilles Blanchard et André Vincent– La fonction achat en informatique et télécoms, 1999 Jean-Christophe Bonne et Aldo Maddaloni – Convaincre pour urbaniser le SI, 2004 Christophe Brasseur – Data Management, 2005 Jean-Pierre Briffaut – Processus d'entreprise pour la gestion, 2004 Stéphane Calé – La gestion de projets de télécoms, 2005 Alphonse Carlier – Management de la qualité pour la maîtrise des SI, 2006 Didier Caron – Méthodes objet, 1997 Jean-Pierre Corniou – La société de la connaissance, 2002 Denis Debaecker – PLM — La gestion collaborative du cycle de vie des produits, 2004 Bernard Debauche et Patrick Mégard – BPM, Business Process Management, 2004 Alain Desroches et al. – Dictionnaire d’analyse et de gestion des risques, 2006 Alain Desroches et al. – La gestion des risques, 2003 Tru Dô-Khac – Externalisation des télécoms d’entreprise, 2005 Luc Dorrer – Hommes et projets informatiques, 2004 Philippe Fenoulière – Vers une informatique ouverte, 2004 Philippe Fenoulière – La qualité de l’informatisation, 1996 Franck Franchin et Rodolphe Monnet – Le business de la cybercriminalité, 2005

II

Collections sous la direction de Nicolas Manson

Jean-François Gautier et Alan Fustec – Informatique de compétition, 1997 Thierry Harlé et Florent Skrabacz – Clés pour la sécurité des SI, 2004 Pierre Jaquet – Les réseaux et l’informatique d'entreprise, 2003 Gérard Jean – Urbanisation du business et des SI, 2000 Didier Joliot – Management des SI, 2003 Didier Joliot – Performances des SI, 2003 Henri Kloetzer – La maîtrise d'ouvrage des projets informatiques, 2002 Pierre Kraus – Prévision et maîtrise des performances d’un système informatique, 2005 Pierre Laigle – Dictionnaire de l’infogérance, 2000 Jean-Luc Lapon – La direction informatique et le pilotage de l’entreprise, 1999 Bernard Le Roux et Joseph Paumier – La gouvernance de l’évolution du SI, 2006 Bernard Le Roux et al. – Urbanisation et modernisation du SI, 2004 Jean-Noël Lhuillier – Le management de l’information, 2005 Henry Ly – L’audit technique informatique, 2005 Pierre Maret – Ingénierie des savoir-faire, 1997 Jean-Pierre Meinadier – Le métier d'intégration de systèmes, 2002 Dominique Moisand – CRM, gestion de la relation client, 2002 Jacques Moulinec et al.– Management des opérations informatiques et ITIL, 2006 Pascal Muckenhirn – Le SI décisionnel, 2003 Gilbert Nzeka – La protection des sites informatiques face au hacking, 2005 Jean-Louis Peaucelle – Informatique rentable et mesure des gains, 1997 Dany Provost – An 2000, la transition réussie, 1998 Didier Quan – L’impossible conduite du projet de SI, 2006

Collections sous la direction de Nicolas Manson

Luc Rubiello – Techniques innovantes en informatique, 1997 Alain Rugy (de) – Management et gestion du parc micro, 1998 Jacques Sassoon – Urbanisation des SI — épuisé, 1998 Pascal Silvestre – Le développement des SI, 1996 Marcel Soberman – Développement rapide d'applications, 1996 Sys-com – La bascule du SI vers l’euro – 2ème édition, 2000 Philippe Tassin – Systèmes d'information et management de crise, 2005 Marc Thorin – L’audit informatique, 2000 Zouheir Trabelsi et Henri Ly – La sécurité sur internet, 2005 Jean-Pierre Vickoff – Estimation et architecture des développements Agiles, 2005 Jean-Pierre Vickoff – Systèmes d'information et processus Agiles, 2003

III

COLLECTION ETUDES

ET

LOGICIELS INFORMATIQUES


Alain Amghar et Frédéric Sitbon – Microsoft Office Project 2003, 2004 Yves Constantinidis – Le logiciel à valeur ajoutée, 2001 Yves Constantinidis – Outils de construction du logiciel, 1998 Erol Giraudy et al. – Le portail Microsoft Sharepoint, 2004 Guy Lapassat – Architecture fonctionnelle des logiciels, 2003 Guy Lapassat – Urbanisme informatique et architectures applicatives, 2003 Jean-Pierre Meinadier – Ingénierie et intégration des systèmes, 1998 Michel Priem – Trafic et performances des réseaux multi-services, 2004 Jacques Printz et Bernard Mesdon – Ecosystème des projets informatiques, 2006 Jacques Printz et al. – Coûts et durée des projets informatiques, 2001 Jacques Printz – Productivité des programmeurs, 2001 Jacques Printz – Puissance et limites des sytèmes informatisés, 1998 Yvon Rastetter – Le logiciel libre dans les entreprises, 2002 Marcel Soberman – Les grilles informatiques, 2003 Sys-com – Stratégie de test e-business, 2001 Spyros Xanthakis et al. – Le test des logiciels, 2000

COLLECTION NOUVELLES

TECHNOLOGIES INFORMATIQUES


Jean-Louis Bénard – Les portails d'entreprise, 2002 Jérôme Besancenot et al. – Les systèmes transactionnels, 1997 Christian Bonjean – Helpdesk, 1999 Jean-Pierre Briffaut – Systèmes d’information en gestion industrielle, 2000 Jean-François Goglin – La cohabitation électronique, 2005 Jean-François Goglin – La construction d'un datawarehouse – 2ème édition, 2001 Jean-François Goglin – Le Datawarehouse, pivot de la relation client, 2001 Jean-François Goglin et Philippe Usclade – Du client-serveur au web-serveur, 1999 Marc Langlois et al. – XML dans les échanges électroniques, 2004 Bernard Manouvrier – EAI, Intégration des applications d'entreprise, 2001 Norbert Paquel et Olivier Bezaut – XML et développement des EDI, 2002 Yvon Rastetter – La fusion de la téléphonie dans l’internet, 2005 René-Charles Tisseyre – Knowledge Management, 1999

COLLECTION SYNTHÈSES INFORMATIQUES CNAM sous la direction de Nicolas Manson

Florent Bastianello – L’informatique, mémoire de l’entreprise, 1996 Jean-André Biancolin – Temps réel, 1995 Bruno Dardonville – Architecture de Windows NT, 1996 Hervé Guitter – La compression des images numériques, 1995 Renaud Hilleret – Stockage des données distribuées, 1996 Jean-Marc Lê – Les systèmes de télécoms mobiles, 1998 Lionel Mallordy – Répartition d’objets dans les bases de données, 1995 Christophe Pasquier – L'approche objet, 1995 Catherine Pérou – La dépense informatique en France, 1996 Ricardo Ruiz – Systèmes de gestion de bases de données orientés objet, 1997 Laurent Schneider – Logiciels serveurs et outils d’administration pour le web, 1997 Philippe Vetter – Calcul coopérant par passage de messages, 1995 Bernard Weiss – ATM, 1995 Bernard Zignin – Les techniques du multithread, 1996

Définition des besoins pour le logiciel

Science des matériaux pour le nucléaire

Science des matériaux pour le nucléaire

Pitie pour le mal

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Une biologie pour le développement

Javascript pour le Web 2.0

Le Casino pour les Nuls

Nouveau regard sur le cancer - Pour une révolution des traitements

Le travail des enfants : Quelles politiques pour quels résultats ?

Dans le Chablais : Des balades pour petits et grands

Le Mac pour les filles

Mathématiques pour le calcul formel

Prières à Dieu pour demander le bon usage des maladies

Laissées pour mortes - Le lynchage des femmes de Hassi Messaoud

Des échelles pour prendre soin

Développez des applications pour l'iPhone

Pour des pratiques pedagogiques revitalisees

Des formations pour quels emplois ?

Economie du logiciel libre

Produire du Logiciel Libre

Visa pour le PCEM 1 : biologie

Le Bac Français 2009 pour les nuls

Le management des seniors : Les dernieres mesures pour l'emploi des seniors

Pour une revolution fiscale : Un impot sur le revenu pour le XXIe siecle

Définition des besoins pour le logiciel

Science des matériaux pour le nucléaire

Science des matériaux pour le nucléaire

Pitie pour le mal

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Meurtres pour tuer le temps

Une biologie pour le développement

Javascript pour le Web 2.0

Le Casino pour les Nuls

Nouveau regard sur le cancer - Pour une révolution des traitements

Le travail des enfants : Quelles politiques pour quels résultats ?

Dans le Chablais : Des balades pour petits et grands

Le Mac pour les filles

Mathématiques pour le calcul formel

Prières à Dieu pour demander le bon usage des maladies

Laissées pour mortes - Le lynchage des femmes de Hassi Messaoud

Des échelles pour prendre soin

Développez des applications pour l'iPhone

Pour des pratiques pedagogiques revitalisees

Des formations pour quels emplois ?

Economie du logiciel libre

Produire du Logiciel Libre

Visa pour le PCEM 1 : biologie

Le Bac Français 2009 pour les nuls

Le management des seniors : Les dernieres mesures pour l'emploi des seniors

Pour une revolution fiscale : Un impot sur le revenu pour le XXIe siecle

Recommend Documents