Gabarit de Conception

Le but de ce « milestone » est d’évaluer votre compréhension de la conception.

On s’attend à ce que vous ayez codé la plupart de votre système et que le code soit conforme à la conception.

Ce document consiste d’un plan détaillé de ce que vous allez construire et d’un horaire détaillé des tâches qu’il vous reste à faire pour finir la mise en œuvre. Le document devrait servir de lien entre les besoins commerciaux et les détails techniques de la mise en œuvre. Évitez de décrire dans ce rapport les éléments qui sont mieux décrits dans le code source. Ce document devrait être une carte de navigation des détails du code source, soulignant les décisions et mécanismes essentiels et critiques. Gardez les détails pour le code source. En fait, lorsque vous devriez mentionner des détails de bas niveau dans ce document, c’est mieux de vous servir de citations et d’exemples tirés du code source pour les clarifier.

Architecture

L’architecture du système devrait être décrite à l’aide d’un diagramme de paquet simple qui identifie toutes les composantes ou modules majeurs de votre système et les dépendances qui les relient.

Vous devriez fournir une définition claire de l’objectif et de la fonctionnalité de chaque module ou composante. Cette catégorie inclut tout tiers ou composante commerciale. Par exemple, si vous vous servez de Microsoft ou de Java, vous devriez indiquer quels progiciels, classes et méthodes que vous projetez utiliser et pourquoi.

Vous devriez définir l’API pour chaque module clairement et explicitement. Faites semblant qu’il existe un programmeur qui ne sait rien au sujet du fonctionnement interne de votre module (et il n’a aucun désir d’en savoir plus). Il veut simplement savoir comment se servir de votre module. En conséquence, vous avez besoin de lui dire quelles classes ou méthodes peuvent être appelées et comment elles devraient être appelées. Il est acceptable et encouragé que vous définissez votre API en copiant les titres du code source (en incluant les commentaires) pour les classes ‘publiques’ dans votre API. Ceci devrait inclure les signatures de méthode pour toutes les méthodes publiques de ces classes.

Conception

La conception de votre système devrait être expliquée à l’aide de diagrammes (préférablement UML). Habituellement, une combinaison de diagrammes de classe et d’interaction est utilisée. On ne s’attend pas à ce que vous documentez et créez un diagramme pour chaque classe dans votre système. Illustrez ce qui est important pour comprendre la conception du système. Montrez uniquement les relations, les méthodes et les attributs importants. Gardez les détails pour votre code source.

Votre conception devrait illustrer comment votre système répondra aux besoins fonctionnels les plus importants. Ceci est fait à l’aide de diagrammes d’interaction des classes principaux pour les scénarios les plus importants reliés à vos cas d’utilisation. Le but n’est PAS de créer un diagramme pour chaque étape ou appel de méthode dans votre système. Plutôt, le but est de démontrer la façon dont les différentes composantes et niveaux de votre système distribuent et coordonnent le comportement désiré. Seulement les classes ou appels de méthodes critiques devraient être mentionnés. En plus des diagrammes d’interaction, vous devriez avoir quelques diagrammes de classe clés (Vue des classes participantes) qui illustrent la relation entre les classes clés et les points les plus importants de ces relations.

Les mécanismes clés (tels que la gestion d’erreurs et la persistance) devraient également être documentés à l’aide de diagrammes d’interaction et de classes participantes. Un exemple seulement de chaque mécanisme clé doit être documenté. Ceci servira d’un gabarit que suivront les développeurs tout au travers du système.

Les algorithmes et les besoins non-fonctionnels principaux qui sont cruciaux au bon fonctionnement de votre système devraient également être décrits dans le contexte de l’architecture et de la conception globale du système.

Si vous avez une interface utilisateur, vous pourrez avoir un diagramme de classe démontrant les différentes formes ou pages et les dépendances qui les relient.

Si vous avez une base de données, vous devriez avoir un diagramme de rapport entre entités ou un diagramme de classe, et un schéma de base de données (avec des commentaires).

Système Alpha

Des copies d’écran pour illustrer le progrès actuel de votre système devraient être insérées dans votre rapport de statut pour cette itération.

Plan du projet

Maintenant que vous avez complètement décrit l’architecture et la conception du système, vous devriez avoir un plan de projet complet qui énumère toutes les tâches qu’il vous reste à faire pour votre projet (et la personne qui les fera). Idéalement, la charge de travail serait séparée de façon à ce qu’aucune tâche ne prenne plus d’une semaine à compléter.

Page d’assurance qualité

Incluez un rapport d’essai (de une à deux pages en longueur) qui reflète le statut actuel de votre système Alpha. Le rapport devrait inclure une brève description de la version testée. Indiquez clairement quelle version s’est faite testée (date et numéro de construction) ainsi que les besoins que cette version devait adresser par rapport aux cas d’utilisation et aux besoins non-fonctionnels. Par la suite, passez en revue les tests utilisés pour vérifier votre système. Pour chaque test, vous pouvez indiquer si il a été mis en œuvre (Pouvez-vous faire fonctionner l’essai?) et si le système a passé le test. Vous devriez également résumer le statut des bogues. Combien en avez-vous trouvés? Quelle est leur sévérité? À quel point avez-vous réussi à les trouver et à les réparer?

Page de documentation

Mettre à jour au besoin les algorithmes, schémas de la base de données, et formats.

Pages acteurs et cas d'utilisation, démonstration du système, d’environnement de développement

Mettre à jour au besoin.

Risques, Plan du projet

Mettre à jour au besoin (issues, boards, pages …).