Activité :
|
Objet
|
|
Rôle : Implémenteur | |
Fréquence : Lors de chaque itération (à l'exception éventuellement des itérations de création, lorsqu'aucun prototype n'est requis) | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : |
Détails de l'enchaînement d'activités : |
Avant de commencer une activité d'implémentation, l'implémenteur doit clarifier sa portée, conformément aux spécifications des affectations de tâches et des plans d'itération. Une tâche d'implémentation peut avoir pour but d'accomplir une fonction spécifique (comme par exemple l'implémentation d'une réalisation de cas d'utilisation ou la correction d'une anomalie) qui implique l'implémentation de plusieurs éléments de conception contribuant à cette fonction. Sinon, une tâche d'implémentation peut être concentrée sur un élément de conception particulier, comme par exemple un sous-système de conception ou un classe de conception, en l'implémentant dans la limite fixée pour l'itération courante.
Cette activité aboutit à la création ou à la mise à jour d'un ou de plusieurs fichiers (éléments d'implémentation). Dans le cadre de la préparation de l'implémentation, l'implémenteur doit s'assurer que son environnement de développement est correctement configuré, de sorte que les versions d'éléments appropriées soient disponibles. Cela doit s'appliquer aux éléments à mettre à jour et aux différents éléments nécessaires à la compilation et aux tests d'unités. L'implémenteur doit connaître et suivre la configuration du projet et les procédures de gestion des changements. Ces procédures décrivent la manière de contrôler et d'éditer les changements, et de les distribuer pour intégration.
Avant d'implémenter une classe, regardez s'il est possible de réutiliser ou d'adapter du code existant. La compréhension de la manière dont l'implémentation s'intègre dans l'architecture et la conception du reste du système peut aider l'implémenteur à identifier les opportunités de réutilisation. Cela permettra également d'assurer l'adéquation de l'implémentation au reste du système.
Nous vous recommandons de réaliser une implémentation incrémentielle en compilant, en associant et en exécutant des tests de régression plusieurs fois par jour. Il est important de savoir que l'ensemble des opérations, des attributs et des associations publics ne sont pas définis pendant la conception.
Lorsque vous gérez des anomalies, vérifiez que vous avez bien corrigé le problème et non le symptôme. Vous devez vous attacher à corriger le problème sous-jacent dans le code. Vous devez réaliser les modifications une par une, car la correction d'erreurs peut engendrer elle-même des erreurs. L'implémentation des corrections doit se faire de manière incrémentielle afin de localiser facilement l'origine d'éventuelles erreurs nouvelles.
L'implémenteur doit connaître et suivre toutes les instructions d'implémentation spécifiques aux projets, y compris les recommandations de programmation applicables aux langages de programmation spécifiques.
Il existe diverses techniques de transformation de la conception en implémentation. Exemples :
Dans tous les cas, cependant, certaines abstractions de conception sont détaillées pour devenir l'implémentation, soit en mode manuel soit par l'intermédiaire de l'application de certaines transformations automatisées.
Comme cela est décrit dans l'étape précédente, la transformation de la conception en implémentation peut aboutir à différents niveaux de finalisation de l'implémentation. Cela peut être une implémentation complète et acceptable. Habituellement, un effort substantiel est néanmoins nécessaire pour terminer l'implémentation. Par exemple :
Il s'agit de vérifier si l'implémentation remplit son objectif. En plus des tests (décrits dans les autres activités), il est souvent utile de réaliser certaines vérifications supplémentaires :
Au fur et à mesure de l'implémentation et du test des conceptions, des erreurs affectant la conception sont inévitablement découvertes. Si l'abstraction de conception est maintenue dans le cadre d'une maintenance future ou pour des raisons contractuelles ou liées à la communication, alors cette conception doit être mise à jour.
Pour cela, la méthode utilisée dépend du processus de gestion de la configuration et des changements applicable au projet. En règle générale, si la modification requise est peu importante, et si la même personne est chargée de la conception et de l'implémentation de la classe, il n'est pas nécessaire d'élaborer une demande de changement formelle. Cette personne peut apporter la modification requise dans la conception.
Si la modification requise a une forte répercussion, comme par exemple la modification d'une opération publique, alors il pourrait s'avérer nécessaire de soumettre une demande de changement formelle.
RUP (Rational Unified Process)
|