ISO 25000

ISO 25000

Comment décrire un besoin ou comment rédiger un cahier des charges ?

Le cahier des charges

Fondations3

Bien entendu, les utilisateurs peuvent exprimer leurs besoins comme ils le souhaitent. Cependant le document qui servira de référence en la matière correspondra au cahier des charges.

La phase de rédaction du cahier des charges correspond en quelques sortes à la phase dans laquelle sont posées les fondations du projet.

Les phases qui suivent le cahier des charges visent à construire le projet à partir des éléments qui ont été définis dans le cahier des charges. Le contenu du cahier des charges est en ce sens tout particulièrement important.

En effet, l’expérience montre que plus les erreurs produites dans le cahier des charges sont détectées tardivement dans les phases qui suivent, plus leur correction à un coût élevé.

Il est clair que dans la construction d’un pont ou d’un immeuble, il coûte très cher de corriger un défaut dans les fondations lorsque les ouvriers sont en train de faire les finitions ou la toiture.

L’expérience montre également que les descriptions de fonctions souffrent facilement de très nombreux maux lorsqu’elles ne sont pas écrites de façon professionnelle et structurée comme par exemple :

  • manque de clarté,
  • ambiguïtés,
  • absence de traçabilité,
  • manque de cohérence,
  • oublis,
  • etc..

Le cahier des charges se doit également d’être précis. Lorsqu’il existe des imprécisions qui subsistent à l’issue du cahier des charges et des spécifications (ce qui arrive parfois), cela se transforme souvent en source de litige.

La maîtrise d’ouvrage aura tendance à dire « C’était évident ». L’expérience montre cependant que rien n’est évident.

Exemple :

Dans un projet de base documentaire, nous avions demandé un moteur de recherche avancée qui selon le cahier des charges devait permettre des recherches sur mot clés.

Dans la première livraison, le moteur permettait des recherches sur mots clés à condition de tous les saisir dans l’ordre où ils avaient été saisis lors du dépôt du document dans la base. Inutile de préciser que c’était inutilisable.

Dans la seconde livraison, il n’était possible de saisir qu’un seul mot clé dans la zone de mots clés du moteur de recherche avancée. Cette version était déjà mieux mais plutôt très limitée pour un moteur de recherche dit « avancé ».

Enfin, la troisième version fut la bonne.

Le bon équilibre

Bien entendu, le cahier des charges ne doit pas tout préciser. Il ne faut pas non plus tomber dans le syndrome de l’excès de précisions qui risque d’être trop consommateur de temps et de budget. En effet, dans les projets, la hiérarchie attend des résultats concrets et de façon « rapide ». Passer trop de temps sur la phase de cahier des charges agace souvent assez vite les managers, ce qui peut conduire dans certains cas à l’abandon du projet avec pertes et fracas.

La rédaction d’un cahier des charges repose de plus sur un savoir faire qui couvre plusieurs domaines :

  • savoir cadrer le besoin (objectifs, périmètre,…),
  • savoir le recueillir,
  • savoir le comprendre,
  • savoir trouver le bon niveau de détail,
  • savoir le formaliser.

Qualité

Enfin, étant donné que le cahier des charges va devoir servir de référence (lors de la phase de recette) pour vérifier si les besoins ont bien été pris en compte et si la qualité est assurée, il doit prendre en compte les grands critères de qualité des logiciels décrits dans la norme ISO 9126 (maintenant intégrée dans la famille des normes ISO 25000).

Autant dire que les risques de défauts dans les fondations des projets sont nombreux si le cahier des charges ne tient pas compte des éléments qui précèdent. Dans la pratique, il est considéré que 80% des problèmes rencontrés dans les applications trouvent leur origine dans la phase de rédaction du cahier des charges (ITIL).

De plus, tous les référentiels de qualité s’accordent pour dire que la qualité se forge le plus en amont possible des projets.

Bien entendu, pour permettre de produire un cahier des charges de qualité qui soit en mesure de servir de fondations aux projets, AMJ a produit un référentiel méthodologique complet qui détaille chacun de ces aspects. De la même façon qu’il existe des techniques pour construire les fondations d’une maison, il existe aussi des techniques pour élaborer les fondations d’un projet.

Conseil en informatique et systèmes d’information

Le conseil en organisation et systèmes d’information fait partie des toutes premières activités de AMJ GROUPE depuis la création de la société en 1986.

Aujourd’hui, nous assistons nos clients aussi bien dans leurs choix stratégiques en matière d’organisation et de systèmes d’information que dans la formalisation de leurs besoins, soit en maîtrise d’ouvrage soit en maîtrise d’œuvre.

Nous sommes principalement reconnus pour nos compétences dans le domaine de l’assistance à maitrise d’ouvrage et en particulier pour ce qui est des études d’opportunités, rédactions de cahiers des charges, assistance au pilotage de projets et recette. Domaines sur lesquels notre capitalisation depuis 20 ans nous apporte un réel savoir-faire que nous vous ferons partager. Nos méthodes d’intervention adaptées au contexte de nos clients et l’approche pragmatique de nos consultants expérimentés nous permettent de vous assurer le succès de nos missions. Par ailleurs, notre indépendance vis-à-vis de tout fournisseur de matériels et logiciels nous permet de vous garantir la totale objectivité de nos travaux et recommandations..

De façon plus ponctuelle, nous intervenons également dans d’autres domaines tels que la sécuritél’audit, les sélections de progiciels ainsi que les schémas directeurs et la rationalisation des systèmes d’information,

Nos prestations en matière de sécurité sont principalement tournées vers la rédaction de procédures, les PCA/ PRA ainsi que les cellules de crises et analyses de risques.

Enfin, nous intervenons dans le domaine de l’intégration de progiciels de façon générale mais avec des compétences plus spécifiques sur la gamme des produits SAGE.

Notre savoir faire est basé sur notre expérience mais pour chacun de ses domaines d’application respectifs il tient bien entendu aussi compte de l’état de l’art en la matière comme par exemple ITIL, l’IEEE 830, SWEBOK, COBIT,…. Les démarches éléborées par AMJ-groupe au fil de son expérience restent avant tout pratiques, opérationnelles et adaptables.

Nos clients sont essentiellement des grands comptes du secteur privé et public avec quelques PME.

Notre indépendance vis à vis des constructeurs et des éditeurs de logiciels ainsi que notre connaissance des organisations, renforcées par notre approche globale des architectures, nous permet d’orienter vos choix vers une meilleure intégration de vos objectifs d’entreprise. Ceci vous permettra de mieux rentabiliser et optimiser vos investissements informatiques, ce qui reste notre préoccupation première.

Les clefs pour réussir sa recette

Les principaux facteurs de réussite d’une recette

Procedure2

L’objectif de cet article n’est pas bien entendu de lister toutes les clés pour réussir une opération de recette mais de donner un aperçu des principaux facteurs de réussite.

La recette se prépare dès la rédaction du cahier des charges. Bien entendu, le cahier de recette n’est pas à rédiger lors de la phase de rédaction du cahier des charges mais les futurs travaux de recette doivent être pensés et intégrés dans la rédaction du cahier des charges.

Pour mémoire, le cahier des charges est un recueil d’exigences qui ne sont pas uniquement fonctionnelles. Bien évidemment les exigences fonctionnelles doivent être décrites avec suffisamment de précision pour pouvoir être ensuite évaluées sans ambigüités.

Ce n’est pas la même chose d’écrire :

  • l’outil devra permettre d’effectuer des recherches avancées

         et

  • l’outil devra permettre d’effectuer des recherches avancées : il permettra de saisir plusieurs mots dans la zone de recherche. La recherche par défaut sera une recherche de type ET. Il sera possible d’exclure certains mots à l’aide du signe « moins » . Les critères additionnels de filtrage seront les suivants : titre du document, nom de la dernière personne ayant modifié, mots clés,…Pour ce qui est des recherches dans la zone de mots clés, il sera possible de saisir un ou plusieurs mots clés,…

Il ne sera possible de recetter que ce qui sera décrit de façon suffisamment claire et non ambigüe. En d’autres termes, les besoins exprimés dans le cahier des charges doivent être décrits avec l’idée qu’ils devront pouvoir être mesurés.

A ce sujet, on voit souvent dans les cahiers des charges : « l’outil devra être simple et convivial ». Comment recetter ces éléments s’ils ne sont pas décrits de façon mesurable ?

Bloquant ou pas bloquant ?

Voici généralement un sujet de discussion interminable pendant les recettes. Ainsi, avant d’engager les recettes, il convient donc de s’accorder préalablement entre maîtrise d’œuvre et maîtrise d’ouvrage sur ce qu’est une anomalie bloquante et une anomalie non bloquante. De la même façon, il conviendra de définir ce que sont des anomalies mineures, majeures, ainsi que le nombre de niveaux de classification des anomalies.

Il existe également une communication à organiser autour du cahier de recette. En effet, sauf demande expresse, le cahier de recette n’a pas vocation à être exhaustif. Les limites du cahier de recette devront donc être clairement annoncées dès le départ. S’il a été décidé de moins tester certains domaines, il faudra l’indiquer. Si certaines parties sont à exclure, cela devra également être indiqué.

Pendant la recette, il conviendra d’être très prudent sur les éventuelles corrections qui pourraient être faites au cours d’une session de recette. Ce type d’opération est à proscrire, néanmoins, lorsque des anomalies bloquantes sont rencontrées en cours de recette et que les délais sont tendus, la pression pour apporter un correctif en cours de recette est parfois très forte. Bien évidemment cela est susceptible d’engendrer des régressions qui ne seront pas forcément détectées.

Si ce type de corrections en cours de recette doit malgré tout se produire, chacun doit être parfaitement informé des impacts potentiels.

Ces quelques exemples ont pour but de rappeler que la réussite d’une recette relève d’une démarche et de règles bien précises.

Assistance à maîtrise d’ouvrage

Assistance à maîtrise d'ouvrage

Vous avez besoin d’assistance dans la mise en place de vos systèmes d’information ? Le pôle consulting d’AMJ GROUPE vous propose une assistance à maîtrise d’ouvrage (AMOA).

La raison d’être de cette activité est d’assister la Maîtrise d’ouvrage face à la Maîtrise d’œuvre dans les domaines suivants :

Les différentes prestations d’assistance à maîtrise d’ouvrage (AMOA)

A ce titre, AMJ GROUPE assure les entretiens et réunions de groupes de travail nécessaires pour permettre de recueillir les besoins. A l’issue de chaque entretien/ réunion, un compte rendu est rédigé. Il est ensuite soumis à la validation des participants et contribue à l’élaboration du recueil des besoins. A partir de l’analyse de ces éléments et des divers documents récupérés AMJ GROUPE, assure la rédaction du cahier des charges.

Les divers documents sont rédigés dans le respect de la charte de rédaction d’AMJ GROUPE. Par ailleurs les tâches sont exécutées conformément à la démarche d’assistance à maîtrise d’ouvrage d’AMJ GROUPE.

Une fois validé, ce document sert notamment de base à l’élaboration des cas de test qui seront utilisés lors de la recette. AMJ GROUPE rédige ainsi le cahier de recette et peut ensuite effectuer tout ou partie de l’exécution des cas de recette.

Si besoin, AMJ GROUPE peut prendre en charge la rédaction de la documentation utilisateurs. A ce stade et compte tenu de la connaissance fonctionnelle d’AMJ GROUPE, nous prenons généralement aussi en charge les formations des utilisateurs.

En parallèle, AMJ GROUPE peut également assurer le suivi et pilotage de l’ensemble du projet pour le compte de la maîtrise d’ouvrage.

Enfin, AMJ GROUPE peut assurer la communication et la conduite du changement auprès des utilisateurs concernés.

Nous pouvons cibler notre intervention sur un domaine particulier comme par exemple la rédaction de cahier des charges ou de cahiers de recette. Nous pouvons également couvrir l’ensemble des travaux de type assistance à maitrise d’ouvrage : du recueil des besoins à la recette en incluant une participation au pilotage de vos projets.

Enjeux des recettes

Tampon2

L’activité de recette est une activité particulièrement sensible dans un projet car son objectif est de définir le niveau de  qualité des produits livrés par rapport à un seuil d’acceptation défini dans un cahier des charges. En effet, pour mesurer, il faut un objet à mesurer (le logiciel développé), un outil de mesure (le cahier de recettes) et une référence pour la mesure (le cahier des charges).

Bien entendu, ce cahier des charges aura notamment intégré les critères de qualité de la norme ISO qui permettent d’évaluer la qualité des logiciels.

La recette consiste à apporter en quelques sortes une certification de la qualité. Comme toute activité d’évaluation, elle doit reposer sur une méthodologie éprouvée et être exécutée avec une très grande rigueur.

Les principaux risques

Les principaux risques liés au fait de ne pas formaliser les tests de recette sont les suivants :

  • passer l’essentiel du temps à tester des cas qui ne seront qu’exceptionnellement exécutés par les utilisateurs alors que les cas métiers les plus fréquents seront peu ou pas testés. Parfois, le désir de vouloir trouver les anomalies conduit à tester des séries de cas particuliers/ exceptionnels au détriment des cas d’utilisation usuels des utilisateurs. On récupère alors une application qui traite très bien les 20% de cas les plus rares alors qu’elle plante sur les 80% de cas les plus couramment utilisés.
  • mal répartir les cas de test et oublier des domaines importants. La formalisation des tests permet de s’assurer que tous les domaines du cahier des charges sont bien couverts.
  • être dans l’incapacité d’expliquer aux équipes de développement les conditions dans lesquelles les dysfonctionnements constatés sont apparus. Il est essentiel pour les développeurs de connaître les caractéristiques précises de survenance des anomalies. Une recette bien formalisée permet de tracer ces éléments dans des fiches dédiées ce qui représente un gain de temps considérable dans le diagnostic de l’origine du problème.
  • refaire plusieurs fois les mêmes cas de recette au sein d’une même session de recette. En effet, lorsque les cas ne sont pas écrits et si la recette dure ne serait ce que quelques heures, il est fort possible que les mêmes cas soient exécutés plusieurs fois. En effet, la personne en charge de la recette ne saura plus forcément si tel ou tel cas précis a été exécuté ou non. Cela a un double inconvénient : perte de temps au détriment d’autres cas qui ne seront probablement pas exécutés.

Dans l’idéal, pour ne pas négliger les phases de recette, qui se trouvent souvent sur le chemin critique, il faut les anticiper suffisamment à l’avance et donc les planifier dès le début du projet. Dans la pratique, il est possible de commencer à préparer la recette dès la fin de la phase de cahier des charges.

Attention toutefois, des arbitrages fonctionnels et des précisions sont apportés lors des phases d’analyse et de conception. Ces éléments ont souvent des impacts sur le descriptif des tests à réaliser. Pour ce qui est du cahier de recette, il est donc préférable d’effectuer l’essentiel de la rédaction pendant la phase de développement.

Par contre les travaux d’organisation de la recette seront à effectuer en amont du développement.

Retour en haut