Implémentation des tâches de développement

Une tâche de développement est une petite section de travail de développement qui découle d'une spécification. L'implémentation d'une tâche de développement implique l'ajout des nouvelles fonctionnalités appropriées au logiciel. Une fois que vous avez effectué une tâche de développement, vous devez lui appliquer des tests unitaires, la réviser, analyser son code et l'intégrer dans la base de code existante.

Dans cette rubrique

Estimation

Documents de conception

Révision du design

Tests unitaires

Analyse du code

Processus de révision du code

Refactorisation

Intégration des modifications

Estimation

L'estimation du coût des tâches de développement permet de contrôler la portée des fonctionnalités et de planifier le travail de développement. Des estimations de coût doivent être faites pour toutes les tâches de développement et tous les problèmes doivent être résolus avant la réunion de planification des itérations. Si le coût total des tâches de développement est supérieur à ce qui est possible pour une itération, une tâche doit être différée ou réassignée. Une fois une tâche de développement choisie, il revient au développeur d'évaluer son coût.

Créez un élément de travail Tâche pour chaque tâche de développement choisie et liez-le à la spécification à partir de laquelle il a été créé. Cette opération s'effectue à partir de l'onglet Implémentation de l'élément de travail Tâche ou Spécification. Basez vos estimations sur le temps requis pour effectuer des tâches similaires et veillez à factoriser le coût de l'écriture des tests unitaires. Pour chaque tâche, entrez l'estimation dans le champ Estimation d'origine de l'élément de travail Tâche.

Le formulaire des éléments de travail Tâche stocke des données dans les champs et onglets présentés dans l'illustration suivante :

Une fois les tâches créées et estimées, utilisez la requête Répartition du travail pour afficher la répartition de toutes vos spécifications et tâches. Pour plus d'informations, consultez Requêtes partagées (CMMI).

Documents de conception

Vos documents de conception doivent contenir suffisamment d'informations pour indiquer à un développeur comment écrire le code permettant d'implémenter la spécification dans le produit.

Les documents de conception peuvent être une collection de spécifications, d'éléments de travail Spécification et d'autres documents, selon votre processus d'équipe.

Vous pouvez utiliser des modèles de conception, une conception orientée objet, des modèles structurels, des langages de modélisation, des modèles de relations d'entités et d'autres techniques dans les indications relatives à la conception déterminée pour votre équipe. Il est également recommandé de documenter le raisonnement lié aux décisions clés prises. Par exemple, en cas d'effet significatif sur le coût, la planification ou les performances techniques, documentez la raison des décisions impliquant ces effets et incluez ces informations dans votre conception.

Une fois que vous avez créé les documents de conception nécessaires, stockez-les en un emplacement où les membres de votre équipe peuvent les partager. Pour plus d'informations, consultez Gérer des documents et des bibliothèques de documents.

Révision du design

La révision du design permet de s'assurer que la conception nouvelle ou modifiée est techniquement exacte, complète, testable et de grande qualité, et qu'elle implémente correctement la spécification. Les révisions de design constituent une méthode clé pour garantir la qualité dès le début par l'identification des problèmes avant qu'ils n'apparaissent dans le code. Elles fournissent également un éclairage supplémentaire sur la conception de la part d'autres développeurs.

Le développeur chargé de créer la conception doit organiser la révision de design en identifiant les réviseurs, en planifiant la révision et en distribuant la conception à tous les réviseurs.

Toutes les parties prenantes impliquées ou affectées par la conception doivent participer à la révision. En général, cela inclut le chef de projet, le développeur sénior et le testeur de la zone de conception. Tous les développeurs figurant dans la même équipe que le développeur dont le code est révisé doivent également participer à la révision.

Planifiez la réunion de révision et distribuez les documents de conception assez tôt pour que chaque réviseur ait le temps de les lire. Planifiez la durée de la réunion de révision en fonction du nombre de détails techniques à réviser.

Vérifier la qualité

Vérifiez que la conception est testable. Génère-t-elle du code qui ne peut pas être vérifié ou validé de façon raisonnable ? Si oui, vous ne pouvez pas garantir la qualité du code, et la conception doit être retravaillée. Recherchez dans les documents de conception les problèmes qui entraîneront des erreurs de code. Recherchez des descriptions d'interface incorrectes, des erreurs de conception ou des confusions de noms. Comparez les documents de conception à des critères existants, tels que des normes d'interface opérateur, des normes de sécurité, des contraintes de production, des tolérances de conception ou des normes de pièces. Créez des éléments de travail Bogue qui décrivent les éventuels défauts trouvés dans les documents de conception et assignez-les au développeur responsable.

Créer un élément de travail Révision pour la conception

Un élément de travail Révision est créé pour documenter les résultats de la révision de conception. L'équipe de révision doit décider des étapes suivantes pour la conception, qui dépendent du niveau de modifications nécessaire. Si aucune modification n'est nécessaire, affectez à l'état de l'élément de travail la valeur Fermé, indiquez Accepté (tel quel) pour la raison, et notez que le codage peut commencer. Si de petites modifications sont nécessaires, affectez à l'état de l'élément de travail la valeur Résolu et indiquez Accepté avec des modifications mineures pour la raison. Cela indique que le codage peut démarrer une fois les petites modifications implémentées dans la conception. Si d'importantes modifications sont requises, affectez à l'état de l'élément de travail la valeur Résolu et indiquez Accepté avec des modifications majeures pour la raison. La conception doit être retravaillée et une autre révision de design doit être effectuée avant que le codage de la conception ne puisse démarrer.

Tests unitaires

Les tests unitaires vérifient l'implémentation correcte d'une unité de code. La rédaction et l'exécution de tests unitaires identifient les bogues avant le début des tests et, par conséquent, aident à réduire le coût du contrôle qualité. Les développeurs doivent écrire des tests unitaires pour tout code impliqué dans l'implémentation d'une tâche de développement ou d'une résolution de bogue. Pour plus d'informations, consultez Vérification du code à l'aide de tests unitaires.

Analyse du code

L'analyse du code vérifie le code par rapport à un ensemble de règles qui permettent l'application d'indications de développement. L'objectif de l'analyse du code est ne pas avoir de violations ou d'avertissements. L'analyse du code peut parcourir votre code à la recherche de plus de 200 problèmes potentiels liés aux conventions d'affectation des noms, à la conception de bibliothèques, à la localisation, à la sécurité et aux performances.

Si vous effectuez l'analyse du code rapidement au cours du cycle de développement, vous pouvez limiter progressivement les violations et les avertissements.

Toutefois, si vous exécutez l'analyse du code sur du code existant qui n'a pas encore été contrôlé, vous pouvez rencontrer de nombreuses violations de règles. Dans ce cas, vous pouvez créer un ensemble de base de règles critiques que le code doit respecter, puis développer l'ensemble de règles une fois les problèmes les plus critiques résolus. De cette façon, une équipe peut mettre en œuvre de nouvelles fonctionnalités à mesure qu'elle améliore sa base de code existante.

Pour plus d’informations, consultez Analyse de la qualité des applications à l'aide des outils d'analyse du code et Amélioration de la qualité du code avec les stratégies d'archivage de projet d'équipe.

Processus de révision du code

Le développeur sénior doit organiser la révision du code en identifiant les réviseurs, en planifiant la révision du code et en envoyant le code à réviser à tous les réviseurs. Pour préparer la révision du code, effectuez les étapes suivantes :

1. Créez un élément de travail Révision pour effectuer le suivi des décisions prises lors de la révision. Si aucune modification n'est nécessaire, affectez à l'état de l'élément de travail la valeur Fermé, indiquez Accepté (tel quel) pour la raison, et notez que le codage peut commencer. Si de petites modifications sont nécessaires, affectez à l'état de l'élément de travail la valeur Résolu et indiquez Accepté avec des modifications mineures pour la raison, ce qui indique que le codage peut démarrer une fois les petites modifications implémentées dans la conception. Si d'importantes modifications sont requises, affectez à l'état de l'élément de travail la valeur Résolu et indiquez Accepté avec des modifications majeures pour la raison. La conception doit être retravaillée et une autre révision de design doit être effectuée avant que le codage de la conception ne puisse démarrer.

2. Déterminez qui doit participer à la révision du code. En général, au moins le développeur sénior et l'architecte chargé de la zone de code doivent participer à la révision.

3. Planifiez une réunion de révision avec les réviseurs et accordez à chaque réviseur assez de temps pour lire et comprendre le code avant la réunion. Planifiez la durée de la réunion de révision en fonction de la quantité de code à réviser.

Révision du code

Une révision du code permet de vérifier que le code nouveau ou modifié atteint un seuil de qualité établi avant son intégration dans la build quotidienne. Les considérations de qualité sont les normes de codage, la conformité à l'architecture et à la conception, les performances, la lisibilité et la sécurité. Les révisions du code fournissent également un éclairage supplémentaire de la part d'autres développeurs à propos de la façon dont le code doit être écrit.

Vérifier la pertinence du code	Le code révisé est pertinent pour la tâche pour laquelle il a été écrit. Aucune modification de code n'est autorisée si elle ne concerne pas les fonctionnalités implémentées ou corrigées.
Vérifier l'extensibilité	Le code est rédigé de façon à pouvoir être étendu, si tel est son but, ou réutilisé dans d'autres zones du système. Les constantes de chaîne utilisées dans le code sont correctement placées dans des ressources qui peuvent être internationalisées.
Vérifier la complexité du code minimal	Le code répété peut être simplifié dans des fonctions communes. Les fonctionnalités similaires sont placées dans une procédure ou fonction commune.
Vérifier la complexité algorithmique	Le nombre de chemins d'exécution du code révisé est limité.
Vérifier la sécurité du code	Le code est vérifié dans le cadre de la protection des ressources, des niveaux de privilège et de l'utilisation des données aux points d'entrée.

Refactoriser le code

Le code est refactorisé après qu'une révision du code a déterminé que des modifications doivent être apportées à la qualité de code, aux performances ou à l'architecture.

Lisez les notes de l'élément de travail de révision du code pour déterminer comment vous devez refactoriser le code.

Appliquez la refactorisation de façon incrémentielle, une modification à la fois. Changez le code et toutes les références à la zone modifiée si nécessaire.

Exécutez des tests unitaires afin que la zone reste sémantiquement équivalente après la refactorisation. Corrigez tous les tests unitaires qui ne fonctionnent pas. Effectuez l'analyse du code et résolvez tous les avertissements. Exécutez à nouveau des tests unitaires si des modifications de code sont effectuées suite à l'analyse du code.

Intégration des modifications

La dernière étape consiste à intégrer les modifications en les archivant dans le contrôle de version. Pour que le code puisse être archivé, tous les tests requis par votre processus doivent avoir été effectués. Pour plus d'informations sur la vérification du code avant son archivage, consultez Amélioration de la qualité du code avec les stratégies d'archivage de projet d'équipe.

Si l'élément de travail associé aux modifications est un scénario ou un impératif de qualité de service dont vous n'êtes pas le propriétaire, indiquez au propriétaire que les modifications ont été effectuées. Affectez à l'élément de travail Tâche la valeur Résolu et assignez-le à l'un des testeurs qui ont créé les cas de test de l'élément de travail.

Si l'élément de travail associé aux modifications est un bogue, affectez à l'élément de travail Bogue la valeur Résolu et assignez-le à la personne à l'origine de sa création.