3.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 de IPI. Bien sûr pour mettre en œuvre ces éléments méthodologique, vous devez 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 majeur partie du temps de codage d’un projet de développement informatique est consacrée au phases de tests et de débogage, on comprends 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 de 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
3.2.1. 0. Page de garde#
- La page de garde doit reprend 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.
3.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 cahiers des charges : fonctionnalités et livrable à implémenter. Ces éléments serviront de point de départ pour la conception.
3.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 une graphe, un arbre, un machine à état, etc…
3.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.
3.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 abstaits pour votre projet. Tous les noms ne se traduisent pas nécessairement par une données et la liste des noms ne recouvre pas l’ensemble des données à représenter, mais cette analyse fourni un point de départ pour la réflexion. De la même manière, la liste des verbes se traduit en générale par une liste de fonction à répartir dans les différents module.
3.2.4.2. Type de données#
Il s’agit de définir précisément les types abstrait de données tel que proposé dans l’objectif 4 de l’enibook.
3.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.
3.2.4.4. Analyse descendante#
On représente les différents arbre d’appels décrivant l’ensemble des fonctions à coder. Un arbre d’appel principal décrit Arbres d’appel des fonctions
3.2.5. 4. Description des fonctions#
Spécifications des fonctions par module
3.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 coder cette fonction. On peut également y consigner certain commentaires permettant d’améliorer le suivi ou anticiper des problèmes à venir.