Décidez quels produits utiliser et comment les utiliser. En plus d'identifier les produits à utiliser, il
est également important de personnaliser chaque produit afin qu'il soit adapté aux besoins du projet.
Le tableau ci-dessous précise les produits d'implémentation qui sont recommandés et ceux qui sont considérés comme
facultatifs (qui peuvent être utilisés uniquement dans certains cas). Pour des questions relatives à la
personnalisation, voir la section s'y rapportant dans la page de description du produit.
Produit
|
Objet
|
Personnalisation (facultatif, recommandé)
|
Modèle d'implémentation
(Sous-système d'implémentation, Elément d'implémentation)
|
Le modèle d'implémentation correspond à du code source, des programmes exécutables et tous les
autres produits requis pour construire et gérer le système dans l'environnement d'exécution.
Une implémentation est composée d'éléments d'implémentation incluant du code (source, fichiers
binaires et programmes exécutables), ainsi que des fichiers contenant des informations (par
exemple, un fichier de démarrage ou Lisez-moi).
Un sous-système d'implémentation est une collection d'éléments d'implémentation et d'autres
sous-systèmes d'implémentation ; il sert à structurer le modèle d'implémentation en le divisant en
parties plus petites.
|
Tous les projets logiciels possèdent un modèle d'implémentation avec des éléments d'implémentation,
dont du code source et des programmes exécutables au minimum.
Certains projets incluent aussi des sous-systèmes, des bibliothèques et des modèles visuels.
Les sous-systèmes s'avèrent utiles pour organiser un nombre important d'éléments d'implémentation.
|
Plan de construction et intégration
|
Définit l'ordre dans lequel les composants doivent être implémentés, quelles constructions doivent être
créées lors de l'intégration au système, ainsi que leur mode d'évaluation.
|
Facultatif.
Recommandé si vous devez planifier l'intégration. Omettez-la uniquement lorsque l'intégration est
simple.
|
Déterminez l'étendue du test unitaire et le niveau de couverture du code, avec une échelle allant du niveau
informel à 100 %. Cette échelle est décrite dans le plan de
test.
Le niveau de couverture du test unitaire dépend souvent des besoins des testeurs d'intégration et de système auxquels
le code a été remis. Les testeurs du système sont dépendants de la qualité du code avec lequel ils travaillent. Si le
code comporte trop d'erreurs, les testeurs du système et de l'intégration le renvoient trop souvent aux implémenteurs.
Tel est le signe d'un processus de développement mal géré ; en guise de solution, demandez éventuellement aux
implémenteurs de réaliser des tests plus poussés.
Vous ne pouvez évidemment pas espérer que le code du test unitaire ne comporte aucune erreur. Il vous faut toutefois
trouver un bon compromis entre le test unitaire et la qualité.
Le niveau de couverture du test unitaire peut également varier d'une phase à l'autre. Même un projet pour lequel la
sécurité est cruciale et demandant une couverture de 100 % lors de la construction et de la transition, ne requiert pas
forcément cette même couverture pendant l'élaboration, sachant que de nombreuses classes sont seulement implémentées en
partie à ce stade.
Décidez dans quelle mesure le code doit être révisé.
Les avantages d'une revue du code sont :
-
Renforcer et stimuler un style de codage commun pour le projet. La revue du code est parfaite pour que les membres
du projet suivent les recommandations de programmation. Pour ce faire, il est plus important de réviser les
résultats provenant de tous les auteurs et implémenteurs que l'ensemble des fichiers du code source.
-
Rechercher les erreurs que les tests automatisés n'ont pas détectées. Les revues de code relèvent des erreurs non
identifiées au cours du test.
-
Permettre le partage de connaissances entre individus et les transférer des personnes les plus expérimentées à
celles qui le sont moins.
Les inconvénients d'une revue de code sont :
-
Elle prend du temps et demande des ressources.
-
Si elle n'est pas correctement effectuée, elle peut s'avérer inefficace. La revue du code risque alors d'être
réalisée uniquement par obligation, et non comme complément pratique au test automatisé.
Pour plus d'informations sur la revue du code, voir aussi Tâche : Réviser le
code.
La revue du code offre une importante valeur ajoutée au projet. Tous les projets qui commencent par mesurer les niveaux
des bogues et des problèmes de maintenance liés aux revues du code gagnent en efficacité grâce à ces revues. Il est
toutefois difficile de les lancer dans de nombreuses organisations pour diverses raisons :
-
Les données collectées sont insuffisantes pour vérifier si la revue du code fonctionne vraiment.
-
Trop de données sont collectées.
-
Les implémenteurs sont très réticents quant à la modification de leur code.
-
Les revues se retrouvent noyées dans des formalités.
-
La gestion des revues demande trop d'efforts.
Gardez ce qui suit à l'esprit pour exploiter au mieux les revues du code :
-
Collectez uniquement les données appropriées.
-
Mesurez les performances des revues et diffusez le résultat.
-
Utilisez les revues de façon "simple".
Pour en savoir plus sur les niveaux de revue, voir Instruction :
niveaux de revue.
|