Projet

Projet

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.

Construire son analytique

La gestion analytique

La gestion analytique est aujourd’hui devenue un élément incontournable afin de piloter l’activité d’une entreprise.

Auparavant, les entreprises se contentaient souvent de démultiplier les comptes au sein de leur plan comptable afin de réaliser une gestion pseudo-analytique. Cela avait pour effet de disposer d’un plan composé d’une multitude de comptes et pouvait générer les problèmes suivants :

  • suivi analytique long et fastidieux par regroupement des totaux de comptes,
  • suivi de la balance des comptes complexe.

Actuellement, il est acquis que la comptabilité analytique doit être séparée de la comptabilité générale, de par la création d’axes analytiques, composés de centres analytiques. Ainsi, lors de la saisie des mouvements, pour chaque compte général utilisé en analytique, un ou plusieurs centres analytiques sont renseignés, de manière manuelle ou automatique, selon les paramétrages effectués.

Les comptes généraux utilisés en analytique sont généralement les comptes de charges et produits. En effet, une analyse sur l’ensemble de ces comptes permet de faire ressortir des résultats selon les critères souhaités (service, affaire, etc.).

Afin de définir au mieux l’analytique à mettre en place au sein d’une entreprise, il est nécessaire de se projeter sur les résultats escomptés. En effet, il est préférable de réaliser en premier lieu une maquette des états souhaités. Cela permet de :

  • visualiser au mieux les différents axes de restitution envisagés,
  • effectuer le tri parmi ces axes analytiques, afin de conserver les axes les plus pertinents,
  • regrouper les critères analytiques qui peuvent être associés, en tenant compte des contraintes des applications de gestion existantes. Par exemple, dans le cas où un axe analytique serait composé de 2 critères (département/service), il convient de s’assurer que les éditions dans les différentes applications de gestion de l’entreprise sont en mesure d’effectuer des regroupements et sous-totaux suivant l’un ou l’autre de ces critères.

Cela permet d’éviter l’erreur classique consistant à vouloir gérer trop d’axes analytiques (par exemple, par service, par projet, par zone géographique, etc.). Cela rend la saisie des mouvements très lourde et, de plus, ces informations ne s’avèrent pas toutes utiles pour l’entreprise.

L’imputation

Une fois que les axes analytiques ont été déterminés, il s’agit de s’assurer que la saisie des centres analytiques au sein des différentes applications de gestion soit possible dans tous les cas de figure. Par exemple, pour certains comptes de charges, il n’est pas toujours possible d’imputer directement une facture d’électricité sur un centre analytique donné. Il est alors  nécessaire d’effectuer une répartition suivant divers critères pré déterminés, ce qui peut s’avérer complexe. Dans ce cas, il est parfois préférable de gérer certains axes analytiques uniquement sur des comptes de ventes.

Il s’agit également de s’assurer que l’analytique choisie soit compatible avec toutes les applications de gestion concernées (paie, gestion commerciale, comptabilité immobilisations). Dans ce cas, une étude doit être réalisée dans le but d’une harmonisation de l’analytique au sein de celles-ci. Cette étude doit notamment aborder le sujet de la codification, qui doit tenir compte des contraintes relatives à chaque application.

En termes de codification analytique, il convient d’ajouter qu’elle doit faire l’objet d’une analyse approfondie. Celle-ci permet de déterminer notamment le nombre de caractères requis pour chaque critère d’analyse au sein d’un axe analytique (par exemple : 3 caractères pour le département et 2 caractères pour le service).

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.

Le design d’interface d’AMJ-groupe

Qu’est-ce que le design d’interface selon AMJ ?

Depuis une quinzaine d’années chez AMJ, nous avons décidé d’ajouter une branche de design d’interface à nos projets, concernant les applications de gestion ou les applications Web.

Cette spécialité est, à l’époque, souvent méconnue et incomprise. Il est parfois difficile de convaincre de la nécessité de ce métier, malheureusement couteux en temps et donc en argent.

Aujourd’hui la notion de design d’interface a fait son chemin et a su se gagner de nombreux partisans en démontrant ses nombreux avantages et sa réelle utilité en terme d’efficacité des interfaces.

Le design d’interface est un vaste assemblage de compétences, qui s’adapte tant à des besoins spécifiques que génériques, à des profils d’utilisateurs multiples ou encore à des applications de tous types.
Ces compétences peuvent être variées d’un designer à l’autre et dépendent ainsi de son parcours professionnel et personnel.

En règle général, chez AMJ, on admet que les champs d’application du design d’interface sont :

  • l’ergonomie d’une application,
  • les besoins fonctionnels,
  • l’accessibilité au plus grand nombre d’utilisateurs,
  • l’organisation des informations,
  • l’enchaînement des écrans,
  • la charte graphique.

Méthodes agiles : la démarche

Sommaire

  1. Méthodes agiles : les enjeux
  2. Méthodes agiles : la démarche
  3. Méthodes agiles : techniques de mise en œuvre
  4. Méthodes agiles : les principales méthodes agiles
  5. Méthodes agiles : les clefs du succès

Valeurs fondatrices

Les méthodes agiles reposent toutes sur des valeurs qui ont été énoncées dans le Manifeste Agile, un texte écrit et signé par 17 experts reconnus pour leurs apports respectifs aux méthodes de développement d’applications informatiques :

  • Priorité des personnes et des interactions sur les procédures et les outils.
    Une équipe soudée et communicante apporte plus que n’importe quelle procédure ou outil.
  • Priorité d’applications opérationnelles sur une documentation exhaustive.
    L’objectif vital est le bon fonctionnement de l’application. La documentation, bien qu’utile, n’est pas un but en soi.
  • Priorité de la collaboration avec le client sur la négociation de contrat.
    Passé l’accord initial, le client doit avant tout être impliqué dans le développement.
  • Priorité de l’acceptation du changement sur la planification.
    Il est nécessaire d’avoir de la flexibilité dans le planning pour être capable d’absorber les évolutions nécessaires.

Ces 4 valeurs sont à mettre en regard des pratiques fréquemment rencontrées lors de la mise en place de méthodes traditionnelles : priorité aux processus et outils, importance de la documentation, respect du contrat à la lettre, planification rigide.

Les méthodes agiles se caractérisent par les éléments suivants :

  • Délivrer rapidement et très fréquemment des versions opérationnelles, pour favoriser un feed-back client permanent
  • Accueillir favorablement le changement
  • Assurer une coopération forte entre client et développeurs
  • Garder un haut niveau de motivation
  • Le fonctionnement de l’application est le premier indicateur du projet
  • Garder un rythme soutenable
  • Viser l’excellence technique et la simplicité
  • Se remettre en cause régulièrement
Retour en haut