Partager via

Développement de spécifications

  • Article

Les spécifications décrivent ce que les parties prenantes attendent du produit. Vous devez les exprimer de façon à ce qu'il soit facile d'en discuter avec les parties prenantes métier, en utilisant le vocabulaire et les concepts du domaine d'entreprise. Les spécifications ne doivent pas porter sur l'implémentation, ni en dépendre. Elles n'incluent pas uniquement les attentes en matière de comportement et de qualité de service des utilisateurs, mais également les contraintes réglementaires et les normes commerciales.

En enregistrant des spécifications dans Visual Studio Team Foundation Server à l'aide de l'élément de travail Spécification, vous bénéficiez des avantages suivants :

  • Vous vérifiez que les spécifications ont été satisfaites en les liant à des cas de test.

  • Vous surveillez la progression de l'implémentation des spécifications en les liant à des éléments de travail Tâche.

  • Vous structurez les spécifications dans des spécifications globales et plus détaillées afin de pouvoir les gérer plus facilement et afin que les rapports de progression puissent récapituler les informations.

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

Cette rubrique n'a pas pour objectif de reproduire l'ensemble de la documentation disponible sur la détermination de spécifications. Elle se concentre plutôt sur les aspects importants de l'utilisation des outils Visual Studio de façon conforme à CMMI. Pour plus d'informations concernant 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 nécessairement respecter l'ordre indiqué. Développez un modèle de domaine pendant que vous écrivez des scénarios car la première activité vous aidera à améliorer l'autre. Développez les scénarios lorsque le moment de leur codage approche. Utilisez du code qui a été écrit et appliqué aux scénarios qui doivent encore être implémentés.

Dans cette rubrique

Quand développer des spécifications

Écrire un énoncé de vision

Écrire des scénarios

Modéliser le domaine d'entreprise

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

Réviser les spécifications

Validation

Inspection et modification des spécifications

Quand développer des spécifications

Team Foundation Server prend en charge le fonctionnement itératif, ce qui est très utile lorsque les premières itérations sont utilisées pour obtenir des commentaires de la part d'utilisateurs potentiels et d'autres parties prenantes. Ces commentaires peuvent servir à améliorer les spécifications qui ont été énoncées pour de futures itérations. L'on aboutit alors à un produit qui est beaucoup plus efficace dans son installation finale qu'un produit développé sur la même période sans évaluation d'utilisateur. Si votre projet est un composant parmi d'autres au sein d'un plus grand programme, 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 au besoin de donner des engagements fermes à votre client ou à des partenaires dans le cadre de projets parallèles.

Dans une certaine mesure, par conséquent, les spécifications sont 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, le fait de les déterminer entièrement avant l'implémentation appropriée risque de constituer un effort inutile.

  • Pour 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. Ce 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 à la fois pour les discussions avec les utilisateurs et pour l'implémentation. Déterminez des spécifications générales qui affectent toutes les fonctionnalités, telles que la sécurité et d'autres impératifs de qualité de service.

  • Au début, ou près du début, de chaque itération, développez les spécifications de ces fonctionnalités de façon plus détaillée. 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 peut se produire dans certains cas exceptionnels.

  • Vérifiez aussi souvent que possible toutes les spécifications implémentées. Les spécifications générales, telles que la sécurité, doivent être vérifiées avec des tests étendus pour chaque nouvelle fonctionnalité. Si possible, automatisez ces tests car les tests automatiques peuvent être exécutés de façon continue.

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. En cas de brusque changement de situation, ce qui arrive rarement, vous aurez peut-être à annuler une itération, réviser le plan de produit et démarrer une nouvelle itération.

  • Recherchez les incertitudes liées aux spécifications. Essayez d'organiser le plan afin que l'expérience utilisateur des itérations antérieures génère des informations permettant de réduire les incertitudes.

  • Utilisez des éléments de travail 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 ne fasse déjà partie du plan. Liez chaque demande de modification aux éléments de travail Spécification appropriés. Pour plus d'informations, consultez Demande de modification (CMMI).

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

  • Mettez les tests à jour afin de les conformer à chaque changement de spécification.

  • Désignez une date limite (par exemple, après l'itération 2 ou 3) après laquelle les modifications à apporter aux spécifications doivent faire l'objet d'une justification plus poussée. Si votre projet est lié à un client payant, il s'agit de la date à laquelle ce client doit approuver un ensemble de base de spécifications et passer du paiement horaire à un tarif forfaitaire.

  • Utilisez les éléments de travail Bogue pour enregistrer tout comportement implémenté non conforme aux spécifications explicites ou implicites. Pour des questions pratiques, créez un nouveau test qui aurait détecté le bogue en question.

É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 court résumé de l'avantage fourni par le produit. Qu'est-ce que les utilisateurs seront en mesure de faire qu'ils ne pouvaient pas faire 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. Qu'est-ce que les utilisateurs du produit seront en mesure de faire qu'ils ne pouvaient pas faire auparavant ?

Écrire des scénarios

Travaillez avec votre client et les autres parties prenantes à la création de scénarios, et entrez-les en tant qu'éléments de travail Spécification, le champ Type de spécification ayant la valeur 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.

Attribuez-lui un titre descriptif qui le distingue clairement des autres en cas d'affichage dans une liste. Assurez-vous que le ou les principaux acteurs sont mentionnés et que leur objectif est clair. Par exemple, le titre suivant constituerait un bon titre :

Le client achète un repas.

Vous pouvez écrire un scénario de différentes façons. Il est parfois utile de combiner plusieurs façons de procéder :

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

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

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

    1. Un client visite le site Web et crée une commande de repas.

    2. Le site Web redirige le client vers un site de paiement pour réaliser le paiement.

    3. La commande est ajoutée à la liste de travail du restaurant.

    4. Le restaurant prépare et livre le repas.

  • Storyboard. Un storyboard est pour l'essentiel une bande de dessin animé qui raconte une histoire. Vous pouvez le créer dans PowerPoint. Joignez le fichier de storyboard à l'élément de travail Spécification ou téléchargez-le vers le portail de l'équipe et ajoutez un lien hypertexte vers l'élément de travail.

    Les storyboards sont particulièrement utiles pour montrer les interactions des utilisateurs. Cependant, pour un scénario d'application professionnelle, il est recommandé d'utiliser un style de croquis qui indique clairement 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 vers le portail de l'équipe et ajoutez un lien hypertexte vers l'élément de travail.

  • Diagramme de séquence de langage de balisage unifié (UML). Les diagrammes de séquence sont particulièrement utiles lorsque plusieurs parties interagissent. Par exemple, la commande du repas nécessite que le client, le site Web DinnerNow, le système de paiement et le restaurant interagissent dans un ordre spécifique. Tracez le diagramme de séquence dans un modèle UML, vérifiez-le dans Team Foundation Server et 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 du 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 à envisager le système en cours d'utilisation et sont très utiles lorsque vous utilisez une fonctionnalité pour la première fois.

Il peut également être utile de créer des personas nommées qui décrivent les arrière-plans et autres activités des personnes et organisations. Carlos dort à la dure et utilise un café Internet ; Wendy habite dans une résidence protégée ; Sanjay commande des repas pour sa femme à son travail ; Contoso dirige une chaîne internationale de 2 000 restaurants ; Fourth Coffee est dirigé par un couple qui effectue ses livraisons par bicyclette.

Des scénarios plus génériques écrits du point de vue d'« un client », d'« un élément de menu », etc, peuvent être plus pratiques mais moins susceptibles d'aboutir à la découverte de fonctionnalités utiles.

Niveaux de détails

Dans l'itération 0, écrivez certains scénarios importants de façon détaillée, mais rédigez la plupart d'entre eux sous la forme d'un simple plan. Lorsqu'une itération approche dans laquelle un scénario spécifique doit être implémenté entièrement ou en partie, ajoutez plus de détails.

Lorsque 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 non concernés par le produit. Par exemple, décrivez la méthode de livraison de DinnerNow : est-ce que chaque restaurant organise ses propres livraisons ou DinnerNow dirige-t-il un service de livraison ? Les réponses à de telles questions fournissent un contexte utile pour 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 storyboards peuvent indiquer la disposition de l'interface utilisateur.

Organisation des scénarios

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

  • Tracez des diagrammes de cas d'usage qui affichent chaque scénario sous la forme d'un cas d'usage. Cette méthode est recommandée car elle facilite 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 Comment : lier des éléments de travail à des éléments de modèle.

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

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

    • Tracez 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 les « Le client paie par carte ».

  • Créez des liens parent-enfant entre les éléments de travail Scénario dans Team Foundation Server. Vous pouvez afficher la hiérarchie dans Team Explorer. Pour plus d'informations, consultez Organisation des 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 la compréhension des spécifications implicites dépend de la bonne compréhension du domaine d'entreprise, autrement dit, du contexte dans lequel le produit fonctionnera. Une partie du travail de rassemblement des spécifications au sein d'un domaine peu connu consiste donc à prendre connaissance de ce contexte. Une fois ces connaissances établies, elles peuvent être utilisées dans plusieurs projets.

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

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

Modélisation des comportements

Tracez des diagrammes d'activités pour résumer les scénarios. Utilisez des couloirs d'activités 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. Le fait de tracer un diagramme d'activités peut vous amener à penser à d'autres séquences et à demander à vos clients ce qui doit se passer dans ce cas.

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

Activité avec trois actions et une boucle.

Lorsque 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 composant de produit principal.

Les diagrammes de cas d'usage vous permettent de résumer les différents flux d'activités que votre produit prend en charge. Chaque nœud du diagramme représente une série d'interactions entre les utilisateurs et l'application dans la poursuite d'un objectif utilisateur spécifique. Vous pouvez également factoriser des séquences communes et des extensions facultatives dans des nœuds de cas d'usage séparés. 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.

Cas d'usage pour les actions précédentes

Modélisation de concepts

Tracez des diagrammes de classes de domaine pour décrire les entités importantes et leurs relations indiquées dans les scénarios. Par exemple, le modèle DinnerNow contient Restaurant, Menu, Commande, Élément 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 d'opérations aux classes. Dans le modèle de domaine, les diagrammes d'activités décrivent le comportement. L'assignation de responsabilités à des classes de programme fait partie du travail de développement.

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

Règle dans le commentaire associé à la classe Order.

Contraintes statiques

Ajoutez aux diagrammes de classes des contraintes qui gouvernent les attributs et relations. Par exemple, les éléments 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. L'un des principaux objectifs d'un modèle est de résoudre des ambiguïtés.

  • Les descriptions de scénario utilisent les termes qui sont définis dans le modèle et sont cohérentes avec les relations qu'il définit. Si le modèle définit des éléments de menu, les scénarios ne doivent pas y faire référence en tant que produits. Si le diagramme de classes indique qu'un élément de menu appartient à un seul menu, les scénarios ne doivent pas parler de partage de cet élément entre des 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 relation du diagramme de classes est créée et détruite. Par exemple, quel scénario crée un élément de menu ? Quand est-ce qu'une commande est détruite ?

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

Créez des éléments de travail qui spécifient des impératifs de qualité de service. Affectez au champ Type de spécification la valeur Qualité de Service.

Les impératifs de qualité de service et spécifications non fonctionnelles incluent les performances, la convivialité, la fiabilité, la disponibilité, l'intégrité des données, la sécurité, l'accessibilité, la facilité de service et l'extensibilité, la livrabilité, la facilité de maintenance, la conception, ainsi que l'adéquation et la finition.

Considérez 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 la spécification suivante : « Pendant une recherche de catalogue, retourner les résultats de la recherche en moins de trois secondes ».

En outre, il est utile de capturer plus de détails qui expliquent pourquoi l'impératif est nécessaire. Décrivez pourquoi la persona accorde de l'importance à l'impératif et pourquoi ce niveau de service est requis. Fournissez un contexte et une justification. Cette explication peut inclure des informations de gestion des risques utiles telles que les données d'une étude de marché, d'un groupe de clientèle ou d'une étude de facilité d'utilisation, des rapports/tickets du support technique ou d'autres preuves anecdotiques.

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

Réviser les spécifications

Lorsque les spécifications sont écrites ou mises à jour, elles doivent être examinées par les parties prenantes appropriées qui vérifient qu'elles décrivent correctement toutes les interactions des utilisateurs avec le produit. Une partie prenante peut être un expert technique, un analyste d'entreprise ou un architecte expérience utilisateur. Les scénarios sont également examinés pour vérifier qu'ils peuvent être implémentés dans le projet sans confusion, ni problèmes. Si des problèmes sont repérés, les scénarios doivent être modifiés de façon à être valides à la conclusion 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 (méthode d'évaluation CMMI standard pour l'amélioration des processus) et peut représenter une bonne source d'informations pour l'analyse de la cause première dans le futur.

Recherchez les caractéristiques suivantes dans chaque scénario :

  • Le scénario est écrit dans le contexte des tâches que les utilisateurs doivent exécuter, de ce qu'ils savent déjà et de la façon dont ils s'attendent à interagir avec le produit.

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

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

  • L'expert technique, l'analyste d'entreprise et l'architecte expérience utilisateur révisent chaque scénario dans le contexte du projet de façon à confirmer que tous les scénarios peuvent être implémentés. Si un scénario n'est pas valide, il est modifié afin de le devenir.

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

  • Le scénario présente une interprétation unique, facilement comprise.

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

  • Le scénario peut être testé.

Validation

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

La validation implique de s'assurer que le produit fonctionne conformément aux prévisions dans son environnement d'exploitation. Dans MSF for CMMI, la validation consiste en la démonstration du logiciel fonctionnel aux parties prenantes à la fin de chaque itération du projet. La planification est organisée de façon à ce que les inquiétudes transmises aux développeurs lors des premières démonstrations puissent être traitées dans le cadre du plan pour les itérations restantes.

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

Inspection et modification des spécifications

Les impératifs de qualité de service et les spécifications de scénario, qui mènent à 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 de type Spécification. Définissez les colonnes du résultat de façon à afficher le chemin des itérations. Pour plus d'informations, consultez Requêtes d'équipe (CMMI).

En plus de visualiser la requête directement dans Team Explorer ou Team Web Access, vous pouvez l'ouvrir dans Office Excel ou Office Project. Ces outils sont mieux adaptés pour la modification et l'ajout d'éléments de travail sous forme de lot. Pour plus d'informations, consultez Utilisation de Microsoft Excel et Microsoft Project avec une connexion à Team Foundation Server et Réalisation d'une planification verticale en utilisant une liste d'arborescence d'éléments de travail (dans Excel).

Votre équipe doit créer la plupart des spécifications au cours des premières itérations du projet. Les nouvelles spécifications sont ajoutées et d'autres sont ajustées à mesure que des commentaires sont transmis suite aux premières versions.

Ressources supplémentaires

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