© Your Copyright
L’objectif de ce chapitre être d’être capable de rédiger un document de conception rudimentaire pour la réalisation du projet de IPI.
Le document de conception se base sur le cahier des charges il décrit la conception du logiciel à réaliser. Il sera utilisé:
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ébuogage, 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 oeuvre 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...
Il s’agit de reprendre les conclusions de l’analyse du besoin réalisée dans le cahiers des charges : fonctionnalaités et livrable à implémenter. Ces éléments serviront de point de départ pour la conception.
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 oeuvre 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 mecanismes de gestion des collisions présenté en cours ou si vous mettez en oeuvre une graphe, un arbre, un machine à état, etc...
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.
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.
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.
Il s’agit de représenter le graphe de dépendence entre les modules tel que cela a été décrit dans l’objectif 4. Evidemment, on assosiera un module à chaque type abstrait de données.
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
Spécifications des fonctions par module
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.