Voilà… Nous y sommes.
Notre analyse est terminée (ou presque), nous avons maintenant une idée très précise de ce que sera demain l’application que nous allons développer.
Il ne nous reste plus qu’à formaliser tout cela dans notre cahier des charges technique.
Je vous propose, au fil des sections qui suivent, d’écrire votre cahier des charges technique en suivant mes conseils. Je vous proposerai ensuite ma propre version de ce cahier des charges afin que vous puissiez le comparer avec votre travail et comprendre les différences.
Deux approches
Il n’y a pas de bonne ou mauvaise démarche pour présenter un cahier des charges. Il en existe presque autant qu’il existe de chefs de projet. 😃
Globalement, il y a deux approches :
créer un seul document pour l’ensemble de votre projet ;
créer un cahier des charges technique pour chacune des briques de votre projet, le tout chapeauté par un document de synthèse montrant la vue globale du projet.
Quelle que soit votre approche, vous pouvez :
soit partir du cahier des charges fonctionnel et l’amender de vos considérations techniques ;
soit partir d’un document vierge et le structurer de façon logique.
Là encore, il n’y a pas de bonne ou de mauvaise structure, l’essentiel étant que toutes les contraintes imposées par votre cahier des charges fonctionnel et votre étude de l’existant soient reprises dans l’un ou l’autre des chapitres du cahier des charges technique.
Gardons juste à l’esprit que ce document sera LE document de référence pour la MOE, c’est-à-dire l’ensemble des équipes qui seront en charge de développer, d’installer et de tester les composants de votre projet. C’est donc sans aucun doute le document le plus important de votre projet.
Pour la suite, j’ai choisi la deuxième approche (un document par brique) et nous nous concentrerons sur la brique “Extraction des devis” pour l’exemple.
Voici par exemple ma copie de travail du cahier des charges fonctionnel, que vous pouvez télécharger au format doc ou au format odt.
Construisons ce cahier des charges technique !
Gestion documentaire
Malgré la grande qualité de votre analyse, il est fort probable que votre CCT soit amené à vivre. Il sera relu et corrigé par de nombreuses personnes (architectes, développeurs, experts techniques, etc.).
Il est donc important de pouvoir l’identifier clairement par un en-tête, de tracer son évolution dans un cartouche de versioning et d’identifier les acteurs intervenant sur ce document.
Exemple d’en-tête :
La page de garde contient a minima :
Le nom du projet
Le type de document et sa version
La date de la version
Le nom du rédacteur responsable
Sa société
Exemple de cartouche de versioning :
Ce cartouche contient a minima :
Le numéro de version
La date de version
Un résumé des évolutions apportées
Le nom du rédacteur
Le nom du correcteur
Le statut de la version
Exemple de liste de diffusion
Cette liste contient a minima :
Les nom et prénom de chaque acteur
Leur rôle dans l’entreprise
Leur rôle relatif au document
Rappel du contexte et des objectifs
Basée sur le contexte général du projet, cette section est reformulée pour s’adapter à la partie traitée.
Les objectifs sont également repris de notre cahier des charges fonctionnel et sont amendés par le fruit de notre analyse. Nous préciserons, par exemple, la nécessité d’initier une connexion avec le serveur de base de données de l’application de suivi des flux afin d’alimenter la table “Transaction” que nous avons définie lors de la définition de la base de données de notre solution.
L’architecture technique
Ce chapitre de votre cahier des charges technique s’appuie essentiellement sur le DAT et sur les règles d’architecture de l’entreprise. Nous y trouverons a minima :
les frameworks de développement à utiliser ;
les middlewares entrant en jeu.
Et, pour chaque environnement technique (développement, intégration, tests, production, etc.) :
Le schéma d’architecture de la couche technique
La liste des composants avec :
La localisation
La zone réseau
Le système d’exploitation et sa version
Les capacités de performances (UC, mémoire)
Les capacités de stockage (disques, NAS, SAN, etc.)
Les paramètres système particuliers
L’adressage IP et le nom DNS
Les éventuels certificats
Les middlewares installés, leur version, les paramètres particuliers
Les ports d’écoute
Le statut (existant, à upgrader, à construire)
Le MPD et la couche de persistance
Notre cahier des charges fonctionnel précise :
La date d’extraction est mise à jour pour chaque enregistrement extrait.
Le programme réalisé initiera une connexion à la base de données de l’application de suivi des flux afin d’initier une transaction.
Nous allons donc devoir modifier la structure de la base Access du logiciel MonBonDevis que nous avons trouvée dans le dossier support afin d’y ajouter la date d’extraction et le numéro de transaction dans la table Devis.
Nous présenterons donc dans notre cahier des charges technique :
le MPD cible de MonBonDevis ;
la nature des modifications à y apporter ;
le MPD cible de l’application de suivi des flux ;
le mode de connexion à ces deux bases de données.
La description des flux réseau
Il s’agit ici de décrire avec précision l’ensemble des flux réseau entrant en jeu dans votre projet en vous appuyant sur l’architecture technique définie. Cette description vous permettra de demander l’ouverture des ports nécessaires à votre application sur chacun des firewalls traversés.
Serveur source (celui qui initie une connexion réseau)
Serveur cible
Les protocoles utilisés
Les ports d’écoute
Le sens d’ouverture des ports nécessaires (simple ou bidirectionnel)
La décomposition technique des fonctionnalités
C’est dans cette partie que nous allons décortiquer le logiciel à développer et fournir aux développeurs le plus de précisions techniques possible.
Nous trouverons généralement dans cette partie :
Une introduction :
Le nom technique du programme (dvf.exe, par exemple)
Les modes d’exécution (batch, interactif) ainsi que la méthode de lancement
Les paramètres en entrée et en sortie
Les fichiers en entrée, leur format et leur chemin
Les fichiers en sortie, leur format et leur chemin
Description des fichiers en entrée
Description des fichiers en sortie
Un organigramme général
Éventuellement des organigrammes détaillés
Les algorithmes de chaque traitement
En résumé
Chose promise, chose due. 😃 Voici ma version du cahier des charges technique de l’extraction des devis, que vous pouvez télécharger au format doc ou au format odt.
Alors ? Est-il si différent du vôtre ?
Probablement et c’est normal. Car, encore une fois, personne ne réfléchit de la même façon, les résultats sont donc variables. L’essentiel est que ce document puisse être partagé et remplir sa mission : guider les équipes techniques dans la réalisation de votre projet.
Avant de passer à la partie suivante, présentez votre travail à votre directeur technique !
