1 - Objet et domaine dapplication
L'élaboration d'un dossier d'étude technique débute lorsque la
conception a été validée par le comité de pilotage (dossier d'étude détaillée, plan
de conduite du changement, protocole de réception externe sur sites pilotes, s'il y a
lieu).
Les objectifs d'un dossier d'étude technique sont de :
- fournir une description complète et détaillée du logiciel dans l'environnement
technique cible de l'application : découpage en composants logiciels, structures des
fichiers, des bases de données, des interfaces
- s'assurer des performances prévisibles et de la sécurité de l'application
Ce guide méthodologique ne propose pas de plan type de dossier
d'étude technique. En effet, la structure d'un dossier d'étude technique est fortement
dépendante de l'environnement technique de l'application. Cependant, il est mis à
disposition une liste de contrôles permettant d'aider le(s) relecteur(s) à vérifier le
fond et la forme d'un dossier d'étude technique. Cette vérification a pour but de
détecter d'éventuelles non-conformités qui pourraient être préjudiciables dans la
suite du projet.
Le(s) relecteur(s) devra s'assurer :
- de la conformité du contenu par rapport à ce qui est attendu,
- de la complétude et de la cohérence du contenu,
- du respect des standards applicables au projet.
Ce guide est destiné aux personnes impliquées dans le processus de
vérification d'un dossier d'étude technique : chef de projet, membres de l'équipe
projet, personnes extérieures au projet sollicitées pour la vérification du document.
Ce document ne peut être exhaustif par rapport à la diversité des
organisations, des environnements et des spécificités des projets de la DSI. Chaque
projet peut compléter cette liste de manière à l'adapter à son contexte.
2 - Documents de référence
3 - Abréviations et terminologie
cf Glossaire " Conduite de projet Systèmes
dinformation "
4 - Principes délaboration
Le(s) relecteur(s) examine chacun des trois thèmes abordés dans la
liste ci dessous : Exhaustivité, Forme, Contenu.
Chaque non-conformité détectée par le relecteur est notée sur une
fiche de relecture (voir le guide méthodologique gestion
de la documentation ou directement le plan type d'une fiche de relecture
).
ET.1 |
Exhaustivité |
O/N |
ET.1-1 |
Existe-t-il un document détude
technique pour chaque nouveau module (ou traitement) ? |
|
ET.1-2 |
Existe-t-il un document détude
technique pour chaque module (ou traitement) qui a fait lobjet dune
évolution ? |
|
ET.1-3 |
Les documents à mettre à jour indiqués
dans la réponse au cahier des charges sont-ils tous présents ? |
|
ET.1-4 |
Existe-t-il une matrice de traçabilité
entre les documents d'étude détaillée et les documents d'étude technique ? |
|
ET.2 |
Forme |
O/N |
ET.2-1 |
La présentation du document est-elle
conforme à la présentation type dun document du projet ? en particulier,
vérifier : page de garde, entête, pied de page, dates du document, référence du
document, indices de version dapplication et de révision du document |
|
ET.2-2 |
Existe-t-il une table des mises à jour et
est-elle à jour ? |
|
ET.2-3 |
Existe-t-il un sommaire et est-il à
jour ? |
|
ET.2-4 |
Les mises à jour du document par rapport
à la révision précédente sont-elles indiquées par des marques de révision dans la
marge ? |
|
ET.2-5 |
N'y a-t-il aucune redondance entre les
spécifications de différents paragraphes ou chapitres (par exemple au niveau des
contrôles) ? |
|
ET.3 |
Contenu |
O/N |
ET.3-1 |
Les spécifications techniques
répondent-elles complètement, sans élément superflu, aux spécifications
fonctionnelles ? |
|
ET.3-2 |
L'architecture globale de l'application
est-elle décrite (répartition des données, des traitements) ? |
|
ET.3-3 |
La faisabilité de l'architecture est-elle
prouvée (technologie disponible, ressources raisonnables, coûts, délais) ? |
|
ET.3-4 |
Le choix de l'architecture retenue est-il
justifié ? |
|
ET.3-5 |
La prise en compte des contraintes
(sécurité, performance, intégrité...) est-elle explicitée ? |
|
ET.4 |
Au niveau des interfaces (autres
applications, périphériques) |
O/N |
ET.4-1 |
Les interfaces avec d'autres applications
ou des périphériques sont-elles décrites de manière complète, non ambiguë,
correcte ? |
|
ET.4-2 |
La structure des fichiers d'interface
est-elle décrite ? |
|
ET.4-3 |
Les protocoles d'échanges sont-ils
définis ? |
|
ET.5 |
Au niveau de l'architecture |
O/N |
ET.5-1 |
L'architecture interne de l'application
(décomposition en composants) est-elle décrite ? |
|
ET.5-2 |
Les interfaces entre les composants
sont-elles décrites ? |
|
ET.5-3 |
Les composants sont-ils identifiés en
respectant le critère de taille : nombre maximal de ligne de code par composant (voir
normes de développement du projet) ? |
|
ET.5-4 |
Les composants sont-ils identifiés en
respectant le critère de modularité : une seule fonctionnalité par composant, entrée
unique, sortie unique ? |
|
ET.5-5 |
Les composants sont-ils identifiés en
respectant le critère de cohérence maximale : cohérence fonctionnelle ou séquentielle
des traitements ? |
|
ET.5-6 |
Les composants sont-ils identifiés en
respectant le critère de couplage minimal : limitation des données globales et des
interfaces entre composants ? |
|
ET.5-7 |
Les données communes sont-elles
regroupées ? |
|
ET.5-8 |
N'y a-t-il pas de redondance dans les
traitements ? |
|
ET.5-9 |
Favorise-t-on la réutilisabilité des
composants ? |
|
ET.6 |
Au niveau d'un composant de
l'architecture |
O/N |
ET.6-1 |
La fonction de chaque composant fait-elle
référence aux spécifications fonctionnelles de l'application ? |
|
ET.6-2 |
Trouve-t-on pour chaque composant une
description des entrées, traitements et sorties ? |
|
ET.6-3 |
Les critères d'exécution des composants
sont-ils précisés ? |
|
ET.6-4 |
Les choix algorithmiques sont-ils
explicités ? |
|
ET.6-5 |
Les contrôles spécifiques du niveau
technique sont-ils clairement décrits ? |
|
ET.6-6 |
La complexité de chaque composant (nombre
de chemins possibles) est-elle minimale ? |
|
ET.6-7 |
Des procédures de reprise sont-elles
prévues pour les principales anomalies possibles ? |
|
|