Chez IBC, proposant un service sur mesure pour les biologistes, nous nous référons au CDC (=Cahier des Charges) de nos clients pour déterminer la technologie, la méthode de développement, le temps nécessaire …

Nous souhaitons ici vous présenter la méthodologie utilisée par IBC et plus généralement par un informaticien pour établir une stratégie de développement à partir d’un CDC.

👉 A la réception d’un CDC, notre attention est portée sur trois points :

· La base de données

· La description des fonctionnalités

· Les pages de l’application

Dans un projet, il est nécessaire de savoir ce que l’application permettra de faire. Pour cela il est important d’avoir un listing exhaustif des fonctionnalités ainsi que leur description.

Ex : voir que l’application contient une fonctionnalité de connexion implique que l’utilisateur a un compte donc qu’il existe une fonctionnalité d’inscription. Peut être que vous souhaitez que votre application soit dédiée uniquement à certains utilisateurs dans ce cas il est important que l’administrateur valide le compte créé avant que ce dernier soit accessible. Si l’administrateur doit valider un compte, il est peut-être nécessaire que ce dernier reçoive un mail automatique lui indiquant qu’un utilisateur a fait une demande de compte…

Pour le développeur, il est essentiel de savoir, pour chaque type d’utilisateur, ce qu’il doit être en capacité de faire à travers l’outil et ce que l’outil doit lui donner comme réponse. Avant de démarrer le développement, l’analyse d’une fonctionnalité passe par l’établissement de cas d’utilisation (use cases).

Un use case permet de décrire ce que va faire l’outil en réponse à une demande de l’utilisateur. Un use case concerne une fonctionnalité dans un scénario précis et peut se présenter de la manière suivante :

· Etant donné que (une situation de départ)

· Et (des précisions)

· Quand (une action)

· Et (des précisions)

· Et …

· Alors (une conséquence ou situation d’arrivée)

Ex : Fonctionnalité : Authentification

Scénario : Tentative d’authentification avec un compte valide

· Etant donné que je dispose d’un compte utilisateur

· Quand j’accède à la page d’authentification

· Et que je saisie mon identifiant dans le champ « Login »

· Et que je saisie mon mot de passe dans le champ « Password »

· Et que je clique sur le bouton « Connexion » du formulaire

· Alors je suis authentifié sur le site

· Et je suis redirigé vers la page d’accueil de mon compte

Dans l’exemple ci-dessus, un scénario est décrit. Cependant pour chaque fonctionnalité il est possible d’avoir plusieurs scénarii possibles. Dans l’exemple le scénario est une tentative d’authentification avec un compte valide mais il existe également un scénario de tentative de connexion avec un compte non valide où l’utilisateur rentre un mauvais login ou mot de passe. L’objectif est donc pour chaque fonctionnalité d’avoir l’ensemble des scenarii.

Chez IBC, nous utilisons la méthode de Test Driven Development (TDD). Cela signifie qu’en premier lieu, pour une fonctionnalité, nous codons des tests. Obtenir l’ensemble de ces scenarii permet à notre équipe de coder les tests correspondants qui nous assurent, tout au long du développement de l’application, de toujours avoir un fonctionnement respectant les spécificités de notre client et de ne jamais altérer l’existant (on parle également de test de non-régression).

Nous verrons dans un second article comment prévoir l’organisation de sa base de données afin de fluidifier le développement de votre application ou logiciel ! Stay tuned !