Principes et conseils :
|
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. |
Documentez les décisions dans le cadre du processus spécifique au projet.
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) |
---|---|---|
|
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é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écidez dans quelle mesure le code doit être révisé.
Les avantages des révisions de code sont :
Les inconvénients des révisions de code sont :
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 :
Gardez ce qui suit à l'esprit pour réaliser pour faire la meilleure utilisation possible des révisions de code :
RUP (Rational Unified Process)
|