Biologistes, un projet bio-informatique ? Formuler un bon cahier des charges est une des premières étapes vers la réussite !

👉 Biologistes, un projet bio-informatique ? Formuler un bon cahier des charges est une des premières étapes vers la réussite ! (3/3)

Si vous aviez manqué les débuts, je vous conseille d’aller jeter un œil à la première partie de nos articles où nous vous introduisions les bonnes pratiques pour la rédaction du CDC et la manière dont vous deviez penser les fonctionnalités : https://infobioco.com/biologiste-formuler-un-cahier-des-charges-partie1/

Nous avons dans un deuxième temps discuter la manière dont vous deviez appréhendez votre base de données à travers cet article :  https://infobioco.com/biologistes-un-projet-bio-informatique-formuler-un-bon-cahier-des-charges-est-une-des-premieres-etapes-vers-la-reussite-2-3/

Nous allons désormais rentrer dans la dernière partie. Vous allez réfléchir aux fonctionnement de votre application d’un point de vue utilisateur, des relations qu’il va y avoir entre les différentes pages de l’application et les éléments de design importants pour offrir la meilleure expérience utilisateur.

Les Pages de l’Application

Une fois le schéma de la base de données réalisé et la liste des fonctions établie, il ne reste plus qu’à déterminer l’architecture de l’application. Pour ce faire, IBC cherche à savoir quelles seront les différentes pages de l’application, le lien entre ces dernières et les fonctions présentes dans chacune d’elles.

Pour chaque page de l’application, une description du design fonctionnel est essentielle. Le design fonctionnel concerne l’emplacement des boutons, des champs de formulaire, le nombre de champ par ligne, les liens entre les pages … Prenez le temps de bien réfléchir à ces éléments de design fonctionnel. En effet, la manière dont vont être organisés les différentes pages de l’application et les lien qu’il peut y avoir entre elles vont avoir un impact sur l’expérience utilisateur.

Une meilleure expérience utilisateur signifiera nécessairement que les utilisateurs de l’application en utiliseront plus facilement le plein potentiel.

Sur cette partie, n’hésitez pas à en discuter avec les futurs utilisateurs de l’application, qui pourront vous faire des retours pertinents sur l’organisation des pages de votre application.

Enfin, pour avoir un aspect visuel agréable il est recommandé de décrire le design esthétique de l’application. Pour chaque élément décrire sa taille, sa couleur, la taille de la police … Ce design esthétique est le dernier point à mettre en place. La majorité des designs étant sobres sans challenge de développement, le design esthétique est le seul point dont une description précise en amont du début du projet n’est pas obligatoire.

En conclusion, comment un prestataire en bio-informatique exploite le CDC ?

IBC s’appuie sur le CDC de ses clients pour estimer les ressources nécessaires à la réalisation du projet. De ce fait, plus chaque point du CDC est décrit de façon précise plus l’estimation du coût de revient pour le commanditaire le sera. Pour cette raison, l’établissement d’un CDC est un travail à ne pas négliger.

Il nous semblait donc intéressant de vous décrire notre mode de fonctionnement avec un CDC. Ainsi vous aurez les éléments utiles à sa mise en place. Nous comprenons que ce travail n’est pas forcément facile à réaliser sans expérience et de ce fait nous proposons à nos clients un accompagnement préalable au développement dédié à la mise en place de ce CDC.

Si vous avez des projets bio-info, n’hésitez pas à nous contacter par mail : contact@infobioco.com

Retrouvez plus d’informations sur IBC sur notre site internet : www.infobioco.com

Biologistes, un projet bio-informatique ? Formuler un bon cahier des charges est une des premières étapes vers la réussite ! (2/3)

Si vous aviez manqué la première partie, elle est disponible ici : https://infobioco.com/biologiste-formuler-un-cahier-des-charges-partie1/

Nous nous étions attardés sur les principaux éléments à prendre en compte dans la rédaction de ce dernier, avec notamment un focus sur la partie des fonctionnalités. Nous allons dans cette deuxième partie attaquer la base de données !

La base de données

Prévoir l’organisation de la base de données est l’étape incontournable lors de la lecture d’un CDC. Réussir à établir cette base de données permet d’optimiser le développement futur. En effet, prévoir la base de données en amont évite de nombreuses modifications ou adaptations de cette dernière lors du développement, la mise en place de scripts de migrations …, qui peuvent également demander des modifications de fonctionnalités existantes.

De plus, une base de données établie clairement aide grandement à la compréhension du fonctionnement de l’application, nous permettant, dans notre accompagnement/développement, de proposer les solutions toujours les plus adaptées.

L’établissement de la base de données se fait régulièrement à partir des différentes fonctions présentes dans l’application.

Afin de prévoir son organisation, IBC cherche dans un premier temps à obtenir la liste de l’ensemble des données de l’application et leur description. La manière la plus optimisée de décrire les données de l’application est de les présenter sous forme d’entités et de leurs attributs. Une entité correspond à une table de la base de données. Chaque table correspond à un tableau en deux dimensions dans lequel les lignes sont des enregistrements et les colonnes des attributs.

Ex : Dans une application avec connexion, l’utilisateur est une entité (table « utilisateur »). Cependant un utilisateur possède plusieurs informations (attributs) comme un login, un mot de passe, un nom, un prénom, une entreprise, une adresse mail et un numéro de téléphone.

Pour optimiser le développement de l’application avant même de commencer à coder, IBC cherche ensuite, pour chaque attribut, à déterminer les informations suivantes :

· Type de données (chaine de caractère, nombre, nombre à virgule…)

· La longueur maximum de l’attribut (dans le cas d’un nombre à virgule, préciser le nombre de chiffre avant et après la virgule)

· Est-il obligatoire ou facultatif ?

· Description de l’attribut si besoin

Ces informations sont directement corrélées au fonctionnement de l’application. Par exemple, savoir qu’un attribut est obligatoire pour une entité nous permet de savoir qu’à la création de cette entité lors de l’utilisation de l’application, il sera obligatoire pour l’utilisateur de remplir cette information pour valider le formulaire.

Ex : Inscription d’un utilisateur : Nous savons qu’un utilisateur a besoin d’un login et d’un mot de passe pour se connecter à l’application (= attributs obligatoires pour l’entité utilisateur). De ce fait, lors de l’inscription, à minima, ces deux informations seront obligatoires.

Dans un second temps, IBC cherche à comprendre quels sont les liens éventuels entre les tables de la base de données. Dans l’exemple un « utilisateur » fait partie d’une entreprise mais d’autres utilisateurs font également partie de la même entreprise. Cela signifie que dans la base de données en plus de la table utilisateur il existe une table entreprise et ces deux tables sont liées. Enfin, il faut préciser le type d’association. Un utilisateur doit faire partie d’une seule entreprise et à l’inverse une entreprise regroupe aucun, un ou plusieurs utilisateurs. De manière concrète, dans notre exemple nous dirons qu’un « utilisateur » fait partie d’une seule « entreprise » et une « entreprise » regroupe un à plusieurs « utilisateurs ».

Avec cet ensemble d’informations, il nous est possible de créer un schéma de la base de données relationnel.

Ex :

Les Id sont des attributs uniques nommées clé primaire présents dans chaque table et attribués automatiquement. Ici l’attribut « Entreprise » de la table utilisateur est ce que l’on appel une clé externe. Il correspondra à un Id_entreprise et permettra de faire le lien entre les deux tables.

Optimiser les relations entre les tables permet d’une part de créer une base de données la moins lourde possible (une information est présente une seule fois dans une seule table) et d’autre part, lors du développement de l’application, de créer des requêtes de récupération et d’envoi de données vers la base de données les moins lourdes possibles optimisant ainsi la vitesse d’exécution.

Après vous avoir donné certaines des clés pour bien appréhender votre base de données dans la rédaction d’un cahier des charges, nous étudierons les pages de votre application dans notre prochain article. Le design et les fonctions qu’elles doivent comporter permettront aux utilisateurs de l’application/logiciel d’en utiliser tout le potentiel ! Stay tuned !