4.2. Le document de conception#
Objectifs
Votre objectif est d’être capable de rédiger un document de conception rudimentaire pour la réalisation du projet d’IPI. Bien sûr pour mettre en œuvre ces éléments méthodologiques, vous devez vous appuyer sur les éléments techniques du cours : Types Abstraits de Données, boucle de simulation, …
Le document de conception se base sur le cahier des charges. Il décrit la conception du logiciel à réaliser. Il sera utilisé:
Avant le codage:
pour la définition et le choix des principes généraux adoptés pour le projet
pour la description et la structuration du code à réaliser
pour la planification du travail
Pendant le codage, le document de conception est un document de référence pour:
coder sans se poser de question d’ordre général
déboguer
vérifier l’avancement du projet (codage+tests)
travailler à plusieurs
Si on accepte l’idée que la majeure partie du temps de codage d’un projet de développement informatique est consacrée aux phases de tests et de débogage, on comprend la nécessité de prendre au sérieux cette phase de conception. Il existe plusieurs façons de rédiger un document de conception, pour le projet d’IPI il vous est proposé de mettre en œuvre un plan en 5 parties. Bien sûr, comme pour le cahier des charges, vous aborderez dans la suite de votre parcours ENIB des méthodes plus élaborées pour réaliser cette étape.
Chacune des parties de ce document est rédigée simultanément. En effet, il est important d’opérer de nombreux allers et retours pour s’assurer de la cohérence du contenu du document. Les types doivent exactement correspondre au contenu des modules, etc…
- Plan du document:
Rappel du CdC
Principes des solutions techniques
Analyse
Description des fonctions
Calendrier et suivi de développement
4.2.1. 0. Page de garde#
- La page de garde doit reprendre les éléments adoptés lors du cahier des charges:
Mettre un titre, le logo de l’ENIB et une illustration.
Utiliser un cartouche normalisé pour tous les documents du projet : type du document, nom du projet, commentaire, auteur, version, date.
4.2.2. 1. Rappel du cahier des charges#
Il s’agit de reprendre les conclusions de l’analyse du besoin réalisée dans le cahier des charges : fonctionnalités et livrables à implémenter. Ces éléments serviront de point de départ pour la conception.
4.2.3. 2. Principes de solutions techniques#
Cette partie est informelle. Vous pourrez y expliquer les principes que vous avez retenus pour réaliser votre projet. Certains principes sont imposés, comme par exemple la mise en œuvre des types abstraits de données ou d’une boucle de simulation. Par ailleurs vous pouvez vous appuyer sur le cours pour préciser certains choix, par exemple si vous adoptez un des mécanismes de gestion des collisions présenté en cours ou si vous mettez en œuvre un graphe, un arbre, une machine à état, etc…
4.2.4. 3. Analyse#
L’objet de cette partie est d’identifier les types abstraits qui structureront le code. Cette analyse est essentielle car une mauvaise organisation du code peut engendrer une explosion du temps de développement. Pour cela, vous vous appuierez sur une Analyse noms-verbes des fonctionnalités.
4.2.4.1. Analyse noms verbes#
L’analyse nom verbe consiste à extraire d’un texte les noms et les verbes utilisés. Ainsi à partir de la liste de noms on pourra raisonner sur les données à modéliser dans le logiciel. En organisant et regroupant ces données, il est possible de définir une première version des types abstraits pour votre projet. Tous les noms ne se traduisent pas nécessairement par une donnée et la liste des noms ne recouvre pas l’ensemble des données à représenter, mais cette analyse fournit un point de départ pour la réflexion. De la même manière, la liste des verbes se traduit en général par une liste de fonctions à répartir dans les différents modules.
4.2.4.2. Type de données#
Il s’agit de définir précisément les types abstraits de données tels que proposés dans l’objectif 4 de l’enibook.
4.2.4.3. Dépendance des modules#
Il s’agit de représenter le graphe de dépendance entre les modules tel que cela a été décrit dans l’objectif 4. Évidemment, on associera un module à chaque type abstrait de données.
4.2.4.4. Analyse descendante#
On représente les différents arbres d’appels décrivant l’ensemble des fonctions à coder. Un arbre d’appel principal décrit Arbres d’appel des fonctions
4.2.5. 4. Description des fonctions#
Spécifications des fonctions par module
4.2.6. 5. Calendrier et suivi du développement#
Cette partie sera utilisée pendant le développement pour indiquer ce qui a été codé et testé. Si on travaille en binôme, il est possible d’indiquer qui a codé cette fonction. On peut également y consigner certains commentaires permettant d’améliorer le suivi ou anticiper des problèmes à venir.