Rubriques

Décider comment exécuter l'enchaînement d'activités Haut de la page

Les décisions suivantes doivent être prises concernant l'enchaînement d'activités de la discipline Implémentation :

  • Décider comment exécuter l'enchaînement d'activités en examinant Implémentation : Enchaînement d'activités. Etudier le diagramme avec ses conditions de garde et les conseils et principes ci-dessous. Décider des détails sur l'enchaînement d'activités à exécuter et dans quel ordre. 
  • Décider quelles parties des détails de l'enchaînement d'activités Implémentation exécuter. Ce qui suit sont certaines parties qui peuvent être introduites relativement indépendamment les unes des autres.

Partie de l'enchaînement d'activités

Commentaires

Intégration et gestion de la version Le rôle Intégrateur et l'Activité : Planifier l'Intégration système avec l'Artefact : Plan de construction et d'intégration sont généralement introduits tôt dans le projet. Les autres activités en rapport avec l'intégration, comme Activité : Planifier l'Intégration du sous-système, Activité : Intégrer le sous-système, et Activité : Intégrer le système sont introduits juste à temps au début de l'intégration. 
Composants d'implémentation Les rôles Implémenteur et Réviseur de code, et leurs activités et artefacts, sont introduits au début de l'implémentation, dans chaque itération.

  • Décider quand, pendant le cycle de vie du projet, introduire chaque partie de l'enchaînement d'activités. Vous pouvez souvent attendre jusqu'à la phase d'Elaboration avant d'introduire la discipline Implémentation.  Toute élaboration de prototype qui intervient dans la phase de Création est généralement exploratoire et n'est pas réalisée aussi rigoureusement (en ce qui concerne les artefacts et les révisions par exemple) que requis par l'enchaînement d'activités Implémentation complet pendant l'élaboration et la construction.

Documentez les décisions dans le cadre du processus spécifique au projet.

Décider comment utiliser les artefacts Haut de la page

Décidez quels sont artefacts à utiliser et comment les utiliser. Le tableau ci-dessous décrit les artefacts que vous devez avoir et ceux utilisés dans certains cas. Pour des informations plus détaillées sur comment personnaliser chaque artefact, et une présentation des avantages et inconvénients de cet artefact spécifique, lisez la section intitulée "Personnalisation" pour chaque artefact.

Pour chaque artefact, décidez comment il sera utilisé : Nécessaire, Recommandé, Utile ou Inutile.

Artefact Objet

Personnalisation (Facultative, Recommandée)

Modèle d'implémentation

(Sous-système d'implémentation, Elément d'implémentation)

Le modèle d'implémentation est le code source, les exécutables, et tous les autres artefacts nécessaires pour construire et gérer le système dans l'environnement d'exécution.

Une implémentation se compose des éléments d'implémentation, qui comprennent le code (source, binaires et exécutables), et les fichiers contenant l'information (par exemple, un fichier de démarrage ou un fichier LisezMoi).

Un sous-système d'implémentation est un ensemble d'éléments d'implémentation et d'autres sous-systèmes d'implémentation, et il sert à structurer le modèle d'implémentation en le divisant en plus petites parties.

Tous les projets logiciels ont un modèle d'implémentation avec des éléments d'implémentation comprenant comme minimum certains codes sources et exécutables.

Certains projets incluront également des sous-systèmes, des bibliothèques et des modèles visuels.

Les sous-systèmes sont utiles lorsqu'il y a beaucoup d'éléments d'implémentation à organiser.

Plan de construction d'intégration Définit l'ordre dans lequel les composants doivent être implémentés, quelles versions créer lors de l'intégration du système et comment elles doivent être évaluées.

Facultative.

Recommandée si vous devez planifier l'intégration. A omettre uniquement lorsque l'intégration est commune.


Personnaliser chaque artefact selon les besoins du projet. La personnalisation est traitée dans la section personnalisation de la page de description des artefacts

Décider de la couverture du test unitaire Haut de la page

Décidez de l'étendue du test unitaire à réaliser et du niveau de couverture du code, avec une  échelle allant de informel à 100% du code couvert.

Le niveau de couverture du test unitaire est souvent déterminé par les besoins de l'intégration et des testeurs de système, à qui le code a été remis. Le travail des testeurs de système dépend de la qualité du code. Si le code présente trop d'anomalies, les testeurs d'intégration et de système renverront trop souvent le code aux implémenteurs. Cela est le signe d'un processus de développement médiocre et la solution peut nécessiter plus de travail des implémenteurs tout au long des tests unitaires.

Bien sûr, vous ne pouvez pas espérer avoir un code sans aucune anomalie. Cependant, vous devez trouver un "bon" équilibre entre le test unitaire et la qualité.

Le niveau de la couverture du test unitaire peut également varie d'une phase à l'autre. Même les projets pour lesquels la sécurité est essentielle qui nécessitent une couverture de 100% du code pendant la construction et la transition ne requièrent généralement pas cela pendant l'élaboration car beaucoup de classes ne sont que partiellement implémentées à cette étape.

Décider comment réviser le code Haut de la page

Décidez dans quelle mesure le code doit être révisé. 

Les avantages des révisions de code sont :

  • Renforcer et encourage un style de code commun pour le projet. La révision du code constitue une façon efficace d'inciter les membres du projet à suivre les recommandations de programmation. Pour assurer cela, il est plus important de réviser les résultats de tous les auteurs et implémenteurs que de réviser tous les fichiers de code source.
  • Pour trouver des erreurs que les tests automatisés ne trouvent pas. Les révisions de code décèlent des erreurs non rencontrées dans les tests.
  • Pour partager les connaissances entre les personnes et transférer celles-ci des plus expérimentés aux novices.

Les inconvénients des révisions de code sont :

  • Elles demandent du temps et des ressources.
  • Elles peuvent être inefficaces si elles ne sont pas réalisées correctement. Il y a un risque la révision du code soit fait "juste par obligation" et ne soit pas faite en tant que complément efficace des tests automatisés.

Pour plus d'informations sur la révision du code, voir également Activité : Révision de code.

La révision du code ajoute une valeur significative au projet. Tous les projets qui commencent pour mesurer les niveaux de bogues et les problèmes de maintenance liés aux révisions de code affirment avoir gagné en performance grâce aux révisions. Toutefois, dans de nombreuses organisations, il est difficile de les faire "décoller" pour différentes raisons :

  • Un nombre insuffisant de données est collecté pour vérifier si la révision du code fonctionne réellement.
  • Trop de données collectées.
  • Les implémenteurs sur-protègent leur code.
  • Les révisions s'empêtrent dans les formalités.
  • Administrer les révisions demande trop d'efforts.

Gardez ce qui suit à l'esprit pour réaliser pour faire la meilleure utilisation possible des révisions de code :

  • Collecter les données adéquates uniquement.
  • Mesurer la performance des révisions et en afficher les résultats.
  • Utiliser les révisions avec "parcimonie".


RUP (Rational Unified Process)   2003.06.15