Spécifications de développement

Les spécifications décrivent ce que les parties prenantes attendent du produit. Vous devez exprimer vos spécifications de manière à ce qu'elles puissent être facilement débattues avec les parties prenantes d'entreprise, en utilisant le vocabulaire et les concepts du domaine d'entreprise. Les spécifications ne doivent pas porter sur l'implémentation ou dépendre de celle-ci. Elles incluent non seulement les attentes des utilisateurs en termes de comportement et de qualité de service, mais également les contraintes réglementaires et les normes commerciales.

En créant des spécifications dans TFS, vous bénéficiez des avantages suivants :

• Vérifier que les spécifications ont été satisfaites en les liant à des cas de test.

• Surveiller la progression vers l'implémentation des spécifications en les liant à des éléments de travail de tâche.

• Structurer les spécifications en spécifications globales et plus détaillées pour pouvoir les gérer plus facilement et obtenir des rapports de progression qui récapitulent les informations.

• Modéliser les spécifications dans Visual Studio Ultimate, en liant les éléments de modèle aux spécifications dans Team Foundation Server.

Cette rubrique n'a pas pour vocation de reprendre toute la documentation qui traite déjà de la détermination des spécifications. Au lieu de cela, elle se concentre sur les aspects qui concernent directement l'utilisation des outils Visual Studio de façon conforme à CMMI. Pour plus d'informations sur CMMI, consultez Informations générales sur CMMI.

Les activités décrites dans cette rubrique, comme toutes les activités de développement, ne doivent pas être effectuées dans un ordre strict. Développez un modèle de domaine pendant que vous écrivez des scénarios, car une activité donnée vous aidera à en améliorer une autre. Développez les scénarios quand le moment de les coder approche. Implémentez les scénarios en tirant parti de l'expérience acquise dans l'écriture et l'application de code.

Quand développer des spécifications

TFS prend en charge le travail itératif, pratique particulièrement utile quand les premières itérations sont utilisées pour obtenir des commentaires d'utilisateurs potentiels et d'autres parties prenantes. Ces commentaires peuvent servir à améliorer les spécifications indiquées pour les futures itérations. Cela aboutit à un produit qui est beaucoup plus efficace dans son installation finale qu'un produit développé sur la même période sans évaluation de la part de l'utilisateur. Si votre projet est un composant parmi d'autres dans un programme plus vaste, une intégration rapide aux autres composants permet aux architectes du programme d'améliorer le produit global.

Cette flexibilité doit être évaluée par rapport à la nécessité de prendre des engagements fermes vis-à-vis de votre client ou de partenaires dans des projets parallèles.

Dans une certaine mesure, les spécifications sont donc développées et affinées tout au long du projet. Étant donné que les spécifications détaillées sont susceptibles de changer au cours du projet, les déterminer entièrement avant l'implémentation appropriée est susceptible d'entraîner un effort inutile.

• Dans l'itération 0, développez un ensemble de spécifications qui décrivent les principales fonctionnalités, avec juste assez de détails pour former un plan de produit. Le plan de produit assigne les spécifications aux itérations et indique quelle spécification sera effectuée à la fin de chaque itération. Créez un modèle de domaine des principaux concepts et activités, et définissez le vocabulaire qui sera utilisé pour ces concepts dans la discussion avec les utilisateurs et dans l'implémentation. Déterminez les spécifications générales qui affectent toutes les fonctionnalités, comme la sécurité et autres impératifs de qualité de service.

• À l'approche ou au début de chaque itération, développez les spécifications de ces fonctionnalités plus en détail. Déterminez les étapes que les utilisateurs suivront, en les définissant à l'aide de diagrammes d'activités ou de séquence. Définissez ce qui se passe dans des cas exceptionnels.

• Vérifiez aussi souvent que possible toutes les spécifications qui ont été implémentées. Les spécifications générales, telles que la sécurité, doivent être vérifiées avec des tests qui sont étendus pour chaque nouvelle fonctionnalité. Dans la mesure du possible, automatisez les tests, car les tests automatiques peuvent être exécutés en permanence.

Gestion des modifications à apporter aux spécifications

Les indications suivantes vous permettent d'effectuer un processus incrémentiel tout en le surveillant afin de satisfaire aux spécifications CMMI.

• Ne modifiez pas les spécifications définies pour une itération. Dans les rares cas d'un brusque changement des circonstances, vous devrez peut-être annuler une itération, examiner le plan de produit et démarrer une nouvelle itération.

• Recherchez les incertitudes pouvant affecter les spécifications. Essayez d'organiser le plan de manière à ce que l'expérience utilisateur des itérations antérieures génère des informations qui réduisent les incertitudes.

• Utilisez des éléments de travail de demande de modification pour enregistrer les demandes de modification d'un comportement qui a déjà été implémenté, à moins que l'amélioration demandée fasse déjà partie du plan. Liez chaque demande de modification aux éléments de travail Spécification appropriés.

• Révisez les demandes de modification quand vous révisez le produit avant chaque itération. Examinez l'impact de la demande sur les utilisateurs et les projets dépendants et estimez le coût des modifications dans votre code. Si une demande de modification est acceptée, mettez à jour la spécification.

• Mettez à jour les tests pour les rendre conformes à chaque modification de spécifications.

• Désignez une date limite (par exemple, après l'itération 2 ou 3) après laquelle les modifications de spécifications doivent faire l'objet d'une justification particulière. Si votre projet est destiné à un client payant, il s'agit de la date à laquelle celui-ci doit approuver un ensemble de base de spécifications et passer du paiement horaire à un prix fixe.

• Utilisez des éléments de travail Bogue pour enregistrer tout comportement implémenté qui ne respecte pas les spécifications explicites ou implicites. Dans la mesure du possible, créez un test qui aurait détecté le bogue.

Écrire un énoncé de vision

Discutez d'un énoncé de vision avec l'équipe et affichez-le sur le portail web du projet pour Team Foundation Server.

Un énoncé de vision est un bref résumé des avantages qu'apporte le produit. Quelles sont les opérations que les utilisateurs pourront faire et qu'ils ne pouvaient pas effectuer auparavant ? L'énoncé de vision clarifie la portée du produit.

Si le produit existe déjà, écrivez un énoncé de vision pour cette version. Quelles sont les opérations que les utilisateurs du produit pourront faire et qu'ils ne pouvaient pas effectuer auparavant ?

Écrire des scénarios

Travaillez avec votre client et autres parties prenantes pour créer des scénarios et entrez-les en tant qu'éléments de travail Spécification, en définissant le champ Type de spécification sur Scénario.

Un scénario ou cas d'usage est une narration qui décrit une séquence d'événements, indique comment un objectif spécifique est atteint et implique généralement une interaction entre des personnes ou des organisations et des ordinateurs.

Donnez-lui un titre descriptif qui le distingue clairement des autres quand il est affiché dans une liste. Assurez-vous que l'acteur principal ou les acteurs principaux sont indiqués et que leur objectif est clair. Par exemple, voici un bon titre :

Le client achète un repas.

Vous pouvez écrire un scénario des formes suivantes. Parfois, il peut être utile de recourir à plusieurs formes :

• Une ou deux phrases dans la description d'élément de travail :

  Un client commande un repas sur un site web et paie avec une carte de crédit. La commande est transmise à un restaurant, qui prépare et livre le repas.

• Des étapes numérotées dans la description d'élément de travail :

  Un client visite le site web et crée une commande pour un repas. Le site web redirige le client vers un site de paiement pour procéder au paiement. La commande est ajoutée à la liste de travail du restaurant. Le restaurant prépare et livre le repas.

• Plan conceptuel. Un plan conceptuel est essentiellement une bande dessinée qui raconte l'histoire. Vous pouvez le créer dans PowerPoint. Attachez le fichier du plan conceptuel à l'élément de travail Spécification, ou téléchargez-le sur le portail d'équipe et ajoutez un lien hypertexte à l'élément de travail.

  Un plan conceptuel est particulièrement utile pour montrer les interactions avec l'utilisateur. Mais pour un scénario d'entreprise, nous vous recommandons d'utiliser un style de croquis qui laisse clairement voir qu'il ne s'agit pas de la conception finale de l'interface utilisateur.

• Documents de spécification. Les documents de spécification vous permettent de fournir le niveau approprié de détails pour chaque spécification. Si vous décidez d'utiliser des documents, créez un document Word pour chaque spécification et joignez le document à l'élément de travail Spécification, ou téléchargez le fichier sur le portail d'équipe et ajoutez un lien hypertexte à l'élément de travail.

• Diagramme de séquence UML (Unified Markup Language). Un diagramme de séquence est particulièrement utile quand plusieurs parties interagissent. Par exemple, dans le cas de la commande du repas, le client, le site web DinnerNow, le système de paiement et le restaurant doivent interagir dans un ordre spécifique. Dessinez le diagramme de séquence dans un modèle UML, intégrez-le à Team Foundation Server, puis entrez un lien dans l'élément de travail Spécification. Pour plus d'informations, consultez Diagrammes de séquence UML : indications.

Scénarios spécifiques

Commencez par écrire des scénarios spécifiques, qui suivent un ensemble particulier d'acteurs dans un ordre spécifique. Par exemple, « Carlos commande une pizza et un pain à l'ail sur le site web DinnerNow. Le site web redirige Carlos vers le service de paiement de Woodgrove Bank. Fourth Coffee prépare la pizza et la livre. »

Les scénarios spécifiques vous aident à appréhender le système en cours d'utilisation et sont très utiles quand vous explorez une fonction pour la première fois.

Il peut également être utile de créer des personnages nommés qui décrivent les environnements et autres activités des personnes et des organisations. Carlos dort à la dure et utilise un café Internet ; Wendy habite dans une communauté murée ; Sanjay commande des repas pour sa femme à son travail ; Contoso gère une chaîne de plus de 2 000 restaurants dans le monde entier ; Fourth Coffee est dirigé par un couple qui effectue ses livraisons à bicyclette.

Des scénarios plus génériques faisant référence, par exemple, à « un client » ou à « un plat de menu » peuvent être plus commodes, mais sont moins susceptibles d'aboutir à la découverte de fonctionnalités utiles.

Niveaux de détail

Dans l'itération 0, écrivez quelques scénarios importants en détail, mais rédigez la plupart des scénarios sous forme générale. Quand une itération approche et qu'elle comprend un scénario particulier qui doit être implémenté entièrement ou partiellement, ajoutez plus de détails.

Quand vous envisagez un scénario pour la première fois, il peut être utile de décrire le contexte métier, y compris les aspects auxquels le produit ne prend pas part. Par exemple, décrivez le mode de livraison de DinnerNow : chaque restaurant organise-t-il ses propres livraisons ou DinnerNow gère-t-il un service de livraison ? Les réponses à ces questions fournissent un contexte utile à l'équipe de développement.

Les scénarios plus détaillés que vous développez au début d'une itération peuvent décrire les interactions de l'interface utilisateur, et les plans conceptuels peuvent indiquer la disposition de l'interface utilisateur.

Organisation des scénarios

Vous pouvez organiser les scénarios à l'aide des méthodes suivantes :

• Dessinez des diagrammes de cas d'usage qui affichent chaque scénario comme un cas d'usage. Cette méthode est recommandée, car elle facilite sensiblement la présentation et la discussion des scénarios. Pour plus d'informations, consultez Diagrammes de cas d'usage UML : indications.

  • Liez chaque cas d'usage à l'élément de travail qui définit le scénario. Pour plus d'informations, consultez Lier des éléments de modèle et des éléments de travail.

  • Établissez des relations d'extension pour indiquer qu'un scénario est une variante d'un autre. Par exemple, « Le client spécifie des adresses de livraison et de paiement distinctes » est une extension du cas d'usage de base « Le client passe une commande ». Les extensions sont particulièrement utiles pour séparer des scénarios qui seront implémentés dans une itération ultérieure.

  • Établissez des relations d'inclusion pour séparer une procédure telle que « Le client se connecte », qui est commune à plusieurs cas d'usage.

  • Établissez des relations de généralisation entre des scénarios généraux tels que « Le client paie » et des variantes spécifiques telles que « Le client paie par carte ».

• Créez des liens parent-enfant entre des éléments de travail de scénario. Vous pouvez afficher la hiérarchie dans Team Explorer. Pour plus d'informations, consultez Organiser les spécifications dans un plan de produit.

Modéliser le domaine d'entreprise

Créez un modèle UML qui décrit les activités et concepts principaux impliqués dans l'utilisation de votre produit. Utilisez les termes définis dans ce modèle en tant que « langage omniprésent », dans les scénarios, dans les discussions avec les parties prenantes, dans l'interface utilisateur et tous les manuels utilisateur, ainsi que dans le code lui-même.

De nombreuses spécifications ne sont pas indiquées explicitement par votre client, et comprendre les spécifications implicites suppose une connaissance du domaine d'entreprise, autrement dit, du contexte dans lequel le produit est appelé à fonctionner. Une partie de la collecte des spécifications dans un domaine peu connu consiste donc à acquérir des connaissances sur ce contexte. Une fois acquises, ces connaissances peuvent être utilisées dans plusieurs projets.

Enregistrez le modèle dans le contrôle de version.

Pour plus d'informations, consultez Modéliser les besoins des utilisateurs.

Modélisation des comportements

Dessinez des diagrammes d'activités pour résumer les scénarios. Utilisez des couloirs pour regrouper les actions exécutées par différents acteurs. Pour plus d'informations, consultez Diagrammes d'activités UML : instructions.

Bien qu'un scénario décrive habituellement une séquence spécifique d'événements, un diagramme d'activités affiche toutes les possibilités. Dessiner un diagramme d'activités peut vous amener à penser à d'autres séquences et à demander à vos clients ce qui doit se produire dans ces cas.

L'illustration suivante montre un exemple simple de diagramme d'activités.

Quand l'échange de messages est important, il peut être plus efficace d'utiliser un diagramme de séquence qui inclut une ligne de vie pour chaque acteur et un composant de produit principal.

Les diagrammes de cas d'usage vous permettent de résumer les différents flux d'activité pris en charge par votre produit. Chaque nœud du diagramme représente une série d'interactions entre les utilisateurs et l'application en vue d'atteindre un objectif utilisateur spécifique. Vous pouvez également traduire des séquences communes et des extensions facultatives en nœuds de cas d'usage distincts. Pour plus d'informations, consultez Diagrammes de cas d'usage UML : indications.

L'illustration suivante montre un exemple simple de diagramme de cas d'usage.

Modélisation des concepts

Dessinez des diagrammes de classes de domaine pour décrire les entités importantes et leurs relations qui sont mentionnées dans les scénarios. Par exemple, le modèle DinnerNow contient Restaurant, Menu, Commande, Plat de menu, etc. Pour plus d'informations, consultez Diagrammes de classes UML : indications.

Étiquetez les rôles (fins) des relations avec des noms et cardinalités.

Dans un diagramme de classes de domaine, vous ne joignez généralement pas les opérations aux classes. Dans le modèle de domaine, les diagrammes d'activités décrivent le comportement. L'affectation des responsabilités aux classes de programme fait partie du travail de développement.

L'illustration suivante montre un exemple simple de diagramme de classes.

Contraintes statiques

Ajoutez aux diagrammes de classes des contraintes qui régissent les attributs et les relations. Par exemple, les plats d'une commande doivent tous provenir du même restaurant. Ces types de règles sont importants pour la conception du produit.

Cohérence du modèle

Assurez-vous que le modèle et les scénarios sont cohérents. Une des utilisations les plus puissantes d'un modèle consiste à résoudre les ambiguïtés.

• Les descriptions de scénario utilisent les termes définis dans le modèle et sont cohérentes avec les relations que ce modèle spécifie. Si le modèle définit des plats de menu, les scénarios ne doivent pas faire référence à la même chose en tant que produits. Si le diagramme de classes indique qu'un plat de menu appartient à un seul menu, les scénarios ne doivent pas évoquer le partage d'un plat entre les menus.

• Chaque scénario décrit une série d'étapes autorisées par les diagrammes d'activités.

• Les scénarios ou activités décrivent comment chaque classe et chaque relation dans le diagramme de classes sont créées et détruites. Par exemple, quel est le scénario qui crée un plat de menu ? Quand une commande est-elle détruite ?

Développer des impératifs de qualité de service

Créez des éléments de travail qui spécifient les impératifs de qualité de service. Définissez le champ Type de spécification sur Qualité de service.

Les impératifs de qualité de service ou non fonctionnels incluent les performances, la facilité d'utilisation, la fiabilité, la disponibilité, l'intégrité des données, la sécurité, l'accessibilité des prix, la facilité de maintenance, l'évolutivité, la productibilité, la facilité de gestion, la conception et la finition.

Envisagez chacune de ces catégories pour chaque scénario.

Le titre de chaque impératif de qualité de service doit capturer sa définition en présentant un contexte, une action et une mesure. Par exemple, vous pouvez créer l'impératif suivant : « Pendant une recherche dans le catalogue, retourner les résultats en moins de trois secondes. »

En outre, il est utile de capturer plus de détails expliquant pourquoi l'impératif est nécessaire. Décrivez pourquoi le personnage accorde de l'importance à l'impératif et pourquoi ce niveau de service est nécessaire. Fournissez le contexte et une justification. Cette explication peut inclure des informations utiles sur la gestion des risques telles que des données d'une étude de marché, un groupe de discussion client ou une étude d'utilisabilité ; des rapports/tickets d'assistance ; ou des témoignages.

Liez l'impératif de qualité de service à tout scénario (élément de travail de spécification) affecté par la qualité de service. La liaison d'éléments de travail connexes permet aux utilisateurs de Team Foundation Server d'effectuer le suivi des spécifications dépendantes. Les requêtes et rapports peuvent indiquer dans quelle mesure les impératifs de qualité de service affectent les spécifications fonctionnelles capturées en tant que scénarios.

Relire les spécifications

Une fois les spécifications écrites ou mises à jour, les parties prenantes appropriées doivent les relire pour s'assurer qu'elles décrivent correctement toutes les interactions de l'utilisateur avec le produit. Les parties prenantes courantes peuvent inclure un expert, un analyste d'entreprise et un architecte de l'expérience utilisateur. Les parties prenantes relisent également les scénarios pour vérifier qu'ils peuvent être implémentés dans le projet sans être source de confusion ou engendrer des problèmes. Si des problèmes sont repérés, les scénarios doivent être corrigés afin qu'ils soient valides à la fin de cette activité.

Créez un élément de travail Révision pour effectuer le suivi de la révision. Cet élément constitue une preuve importante pour une évaluation SCAMPI (Standard CMMI Appraisal Method for Process Improvement) et peut fournir une bonne source d'informations pour l'analyse des causes fondamentales à l'avenir.

Relisez chaque scénario en veillant à ce qu'il présente les caractéristiques suivantes :

• L'écriture du scénario prend en considération la tâche que les utilisateurs doivent effectuer, ce qu'ils savent déjà et la façon dont ils envisagent d'interagir avec le produit.

• Le scénario présente un problème et n'est pas obscurci par les solutions proposées au problème.

• Toutes les interactions appropriées de l'utilisateur avec le produit sont identifiées.

• L'expert, l'analyste d'entreprise et l'architecte de l'expérience utilisateur examinent chaque scénario dans le contexte du projet pour confirmer que tous les scénarios peuvent être implémentés correctement. Si un scénario n'est pas valide, il est révisé afin qu'il soit valide.

• Le scénario peut être implémenté avec les techniques, outils et ressources disponibles et en fonction du budget et de la planification.

• Le scénario présente une interprétation unique qui est facilement compréhensible.

• Le scénario n'entre pas en conflit avec un autre scénario.

• Le scénario est testable.

Validation

Envisagez de déployer des versions bêta du produit dans son environnement d'exploitation avant sa version finale. Envisagez de mettre à jour les spécifications, en fonction des commentaires des parties prenantes recueillis à l'issue de ce déploiement.

La validation consiste à s'assurer que le produit remplit son rôle dans son environnement d'exploitation. Dans MSF for CMMI, la validation est effectuée en faisant une démonstration du logiciel fonctionnel aux parties prenantes à la fin de chaque itération du projet. La planification est organisée de telle sorte que les attentes qui sont remontées aux développeurs pendant les premières démonstrations peuvent être traitées dans le plan des itérations restantes.

Pour obtenir une véritable validation, le produit ne doit pas être exécuté uniquement dans un contexte de démonstration ou simulé. Dans la mesure du possible, il doit être testé dans des conditions réelles.

Inspection et modification des spécifications

Les spécifications du scénario et les impératifs de qualité de service, qui aboutissent à la plupart des tâches de développement, peuvent être inspectés à l'aide de la requête de spécifications du client. Si vous préférez afficher toutes les spécifications, vous pouvez écrire une requête qui retourne tous les éléments de travail du type d'élément de travail Spécification. Définissez les colonnes du résultat pour afficher le chemin de l'itération.

Votre équipe doit créer la plupart des spécifications dans les premières itérations du projet. De nouvelles spécifications sont ajoutées, tandis que d'autres sont ajustées sur la base des commentaires formulés à partir des premières versions.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources Web suivantes :

• A Practical Guide to Feature Driven Development, Stephen R. Palmer et Malcolm J. Felsing ; Prentice-Hall PTR, 2002.

• Streamlined Object Modeling: Patterns, Rules and Implementation, Jill Nicola, Mark Mayfield et Mike Abney ; Prentice Hall PTR, 2001.

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler ; Wiley, 2002.

• Domain Driven Design: Tackling Complexity in the Heart of Software, Eric Evans ; Addison Wesley Professional, 2003.

• Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean ; Addison Wesley Professional, 2002.