Fichier de rejeu Close

Indication Close

A propos de... Close

Commentaire Close

Téléchargements

Crédits

© Your Copyright

Aide

Conception

Objectif :

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 en IPI

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ébugger
    • vériéer 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é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...

Plan du document:
  1. Rappel du CdC
  2. Principes des solutions techniques
  3. Analyse
  4. Description des fonctions
  5. Calendrier et suivi de développement

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.

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 : fonctionnalaités et livrable à implémenter. Ces éléments serviront de point de départ pour la conception.

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 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...

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.

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.

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.

Dépendance des modules

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.

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

4. Description des fonctions

Spécifications des fonctions par module

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.

Exemple