Marcel de VriesSupport info

Jack GreenfieldMicrosoft Corporation

Novembre 2006

S'applique à :Microsoft Visual Studio Team SystemMicrosoft SQL Server 2005 Reporting ServicesFabriques de logiciels

Résumé : Ce livre blanc explique comment les fabriques de logiciels et Microsoft Visual Studio Team System peuvent être conjointement utilisés afin d'améliorer la qualité, la prévisibilité et la productivité. À l'aide du magasin de données et des fonctionnalités de création de rapports de Microsoft Visual Studio Team System, le développeur des fabriques de logiciels peut déterminer avec fiabilité quels aspects du développement du produit doivent être améliorés et comment modifier la fabrique de logiciels pour les améliorer.

Ce livre blanc aboutit à la conclusion suivante : il est possible d'obtenir une qualité, une prévisibilité et une productivité plus élevées en utilisant une approche de fabrique de logiciels plutôt qu'un développement unique traditionnel. Ce sont les concepts et les méthodes de travail qui sont visés dans un public composé d'intégrateurs système et d'entreprises clientes qui mettent au point des logiciels personnalisés. (23 pages imprimées)

Measuring Success with Software Factories and Visual Studio Team System

Sur cette page

Introduction
Modification de la façon dont nous créons les logiciels
Mesure de la qualité et de la productivité
Application de Visual Studio Team System
Utilisation des structures de mesure (ISO 15939)
Assemblage
Conclusion
Références :

Introduction

À l'heure actuelle, il est difficile de créer un logiciel. Les systèmes deviennent, chaque jour, de plus en plus complexes et de plus en plus importants. Nous avons affaire à une technologie qui évolue rapidement et nous essayons d'être réactifs pour faire face aux exigences des entreprises clientes qui souhaitent que nous écrivions des logiciels améliorés et plus rapides. Est-il réellement possible d'être plus productif tout en produisant des logiciels de meilleure qualité ? Est-il possible de garantir une productivité plus élevée par le biais de la maintenance et des mises à jour, sans altérer la qualité ou réécrire le code en grande partie ? Il est parfois impossible de réécrire des systèmes avec des millions de lignes de code, en particulier si l'entreprise souhaite que les modifications soient effectuées rapidement. Dans ce livre blanc, nous allons vous expliquer comment être plus productif et comment produire de meilleurs logiciels en adoptant une approche de fabrique de logiciels pour développer vos logiciels.

Modification de la façon dont nous créons les logiciels

Pendant plusieurs dizaines d'années, l'industrie logicielle a créé des systèmes logiciels pour répondre aux besoins de ses clients. Pourtant, malgré toute cette expérience, la qualité et la productivité ne s'améliorent pas vite. Selon une enquête annuelle effectuée par le groupe Standish, nous atteignons à peu près le même niveau de productivité aujourd'hui qu'il y a 10 ans. Actuellement, 54 % des projets de développement de logiciels sont fournis à un prix excessif, 66 % sont jugés insatisfaisants par leurs clients et 90 % ne sont pas livrés dans les délais ! L'aspect le plus ennuyeux de l'enquête est toutefois que ces chiffres ne se sont pas améliorés beaucoup au cours des dix dernières années.

Mettez un groupe de développeurs ou de chefs de projets en confrontation et demandez-leur s'ils pensent aujourd'hui offrir une création de logiciels réussie. Ils commencent généralement par sourire, puis ils finissent par admettre qu'ils sont également victimes de ce type de résultats. Nous constatons avec tristesse que nous avons tendance à considérer que, parce que la création de logiciels est une démarche créative, nous sommes condamnés à accepter des projets de mauvaise qualité.

Comment un logiciel est-il créé aujourd'hui ?

Une productivité basse est souvent due au fait que nous ne disposons pas des bons impératifs ou au fait qu'il nous manque des impératifs. La productivité va se dégrader considérablement, pas uniquement si nous créons le mauvais système, mais également si le champ d'application du projet est évolutif, dépassant ainsi son volume initial de fonctionnalités. Nous trouvons également difficile d'obtenir le niveau de test adapté afin de garantir le niveau de qualité requis. La maintenance et les versions de mise à jour défectueuses sont souvent liées à l'incapacité de prévoir l'effet des modifications du code sur la qualité du produit. Comment garantir qu'une modification sur une partie du système ne va pas endommager une autre partie ?

La majorité de ces problèmes se posent parce que nous tirons peu de leçons des projets que nous avons effectués par le passé. Demandez aux équipes de développement si elles apprennent de leurs erreurs et vous serez impressionné de voir que peu d'entre elles mettent en pratique ce qu'elles ont appris et l'appliquent à leurs futurs projets. Rares sont les équipes qui réutilisent les solutions créées par le passé ou conservent une trace des points positifs et des points négatifs. Le transfert de compétences d'un projet à l'autre n'est donc pas suffisant ; les compétences restent dans les cerveaux des développeurs. Les leçons qui ont déjà pu être tirées le sont à nouveau par d'autres développeurs. Les développeurs ont du mal à abandonner des projets existants parce qu'ils les maîtrisent parfaitement. Il leur semble difficile de s'associer à de nouveaux projets parce que pratiquement rien n'est écrit.

Face aux nombreux projets qui ne peuvent être livrés dans les délais et dans le respect du budget, nous constatons que nous avons également un problème de prévisibilité. Demandez aux chefs de projets comment ils font leur programme et leur calendrier. Vous serez encore plus surpris de voir combien d'entre eux s'en tiennent aux vieilles habitudes et s'expriment ainsi : « Je demande un devis à mon meilleur programmateur pour savoir combien cette fonctionnalité coûtera, puis je multiplie le prix par deux ; mon programmateur est d'une nature optimiste. » Souvent, ce type de « budget » est ensuite revu à la baisse, pour offrir une offre compétitive, équilibrer les comptes ou satisfaire les attentes. Ces vieilles habitudes sont difficiles à combattre,

mais soyons honnête : les chefs de projets sont pratiquement obligés de se fier aux estimations des experts puisqu'ils ne disposent pas d'autres mesures fiables. Ce qu'il leur faut, c'est la capacité de comprendre les mesures des projets de développement de logiciels de façon fiable, par exemple dans un magasin de données. À partir de ces mesures, ils pourraient apprendre le mode de fonctionnement de leurs équipes de développement et utiliser ces compétences pour élaborer de meilleurs devis. L'utilisation des données historiques afin de s'adapter aux performances de l'organisation ou du projet améliore la précision du devis. Pourtant, la plupart des devis sont élaborés sans en tenir compte.

Il est difficile de contrôler les projets avec une mauvaise prévisibilité. Lorsque les chefs de projet prennent une décision, comment peuvent-ils savoir quelle répercussion cette dernière aura sur le calendrier et sur les coûts ? Vous ne pouvez tout simplement pas utiliser une mauvaise prévisibilité pour prévoir l'effet de la décision qui a été prise. Autant tirer au pistolet les yeux fermés et espérer toucher la cible !

C'est à cause de ces problèmes que nous produisons trop peu de logiciels en un laps de temps trop long. Nous offrons des logiciels dont la qualité et la prévisibilité sont mauvaises. Nous rencontrons des difficultés dans le contrôle du développement et il est difficile pour les praticiens de modifier des projets. Chaque heure supplémentaire non prévue dans le budget coûte de l'argent en plus et chaque défaut détecté lors des tests (ou, pire encore, lors de la production) coûte encore plus cher, comme toute mauvaise décision prise tout au long du processus. Il s'avère aujourd'hui très coûteux de créer des logiciels.

Utilisation de fabriques de logiciels

Pouvons-nous nous améliorer ? Oui. Nous pouvons créer un logiciel dans les délais, en respectant le budget et en offrant une qualité adaptée. Tout d'abord, il doit y avoir une prise de conscience dans l'organisation que l'approche actuelle de création de logiciels est nettement inefficace. Si vous n'avez pas conscience des problèmes existants, vous n'aurez aucune stimulation pour vous améliorer. Pour commencer à créer des systèmes logiciels avec prévisibilité, nous devons opérer un changement culturel. Nous devons aider les praticiens à savoir quoi faire, quand le faire, pourquoi le faire et comment le faire. Nous devons également automatiser davantage les tâches répétitives et/ou les aspects subalternes de leur travail. Ces objectifs peuvent être atteints en formalisant des aspects sélectionnés du processus de développement. Quels sont ces aspects ? Comment pouvons-nous les formaliser sans sacrifier la souplesse ?

Créativité et formalité

La solution est de formaliser les activités à grain fin qui créent et modifient les produits, plutôt que d'essayer de formaliser l'intégralité du processus de développement. Les workflows à gros grain peuvent ensuite évoluer pour s'adapter aux exigences du projet et aux circonstances, à condition que les invariants soient maintenus pour garantir que les résultats sont valides. Vous pouvez travailler simultanément sur l'écriture de plusieurs classes en passant, par exemple, de l'une à l'autre, si nécessaire, à condition que toutes les dépendances qui existent entre elles soient respectées lors de la compilation. Cette flexibilité préserve la souplesse et empêche de tourner autour d'une seule activité. Lorsque vous formalisez des activités à grain fin au lieu d'essayer de formaliser l'intégralité du processus de développement, vous gagnez en qualité, prévisibilité et en productivité, sans sacrifier la souplesse. Vous apprenez à différencier les cas où la formalité est nécessaire et ceux où elle ne l'est pas, ce qui vous permet de trouver le bon équilibre entre la souplesse et la formalité. En appliquant la formalité uniquement lorsque c'est nécessaire, vous permettez au processus de développement d'évoluer de façon très organique et ascendante à mesure que vous gagnez en expérience. Cette approche facilite également l'acquisition et le transfert des compétences entre les projets et les praticiens, comme nous le verrons par la suite.

La créativité est nécessaire pour résoudre les problèmes, mais pas pour effectuer les tâches répétitives et/ou les activités subalternes. C'est triste mais peut-être pas surprenant que la majeure partie du travail quotidien du développeur type se compose de tâches répétitives et/ou d'activités subalternes. La solution pour gagner en productivité et en prévisibilité sans sacrifier la souplesse est d'encourager et de soutenir la créativité lorsque c'est nécessaire et de formaliser lorsque cette dernière ne l'est pas. Plus nous formalisons à l'aide de modèles, pratiques et outils, plus nous exclurons les variations gratuites du processus. L'exclusion des variations gratuites facilite la mesure des projets de développement de logiciels, l'apprentissage que l'on peut en tirer et l'utilisation de ces mesures pour améliorer les futurs projets. La formalisation des tâches répétitives et/ou activités subalternes permet une créativité plus grande en réduisant le temps et l'énergie passés sur les activités qui ne nécessitent pas de créativité.

Fabriques de logiciels

Ce dont il s'agit est d'industrialiser le développement de logiciels ; d'appliquer des techniques qui ont fait leurs preuves depuis longtemps dans d'autres industries à notre propre industrie, dans l'espoir d'améliorer les choses pour nos clients et pour nous-mêmes. L'industrialisation est obtenue en créant des fabriques de logiciels qui rendent le développement de logiciels à la fois plus productif et plus prévisible.

Une fabrique de logiciels est un ensemble de processus et d'outils intégrés et d'autres ressources qui sont utilisés pour accélérer les tâches du cycle de vie pour un type spécifique de composant, d'application ou de système logiciels. L'accélération est obtenue en donnant aux praticiens des conseils qui les aident à savoir quoi faire, quand le faire, pourquoi le faire et comment le faire. Nous y parvenons en offrant des conseils sur le processus comprenant juste ce qu'il faut de formalisation du processus, des composants qui peuvent être rapidement montés et configurés, des supports qui peuvent être rapidement achevés et en proposant des outils spécialisés qui automatisent totalement ou partiellement les tâches répétitives et/ou les activités subalternes.

L'un des principaux objectifs que nous souhaitons atteindre grâce à la fabrique de logiciels est de tirer des leçons des solutions que nous avons créées par le passé pour les exigences et les problèmes le plus fréquemment rencontrés et d'appliquer le fruit de cet apprentissage aux futurs projets. Pour ce faire, nous devons trouver un moyen de décrire ces solutions réutilisables et de les organiser autour des zones d'intérêt ou de préoccupation où les problèmes où exigences qui s'y appliquent sont généralement rencontrés. Une telle organisation permet de réduire simultanément l'ensemble des problèmes ou exigences à traiter, ce qui facilite l'identification des solutions réutilisables pouvant être appliquées. Ces zones d'intérêt peuvent se situer à un niveau élevé d'abstraction, par exemple la définition des couches architecturales, ou à un faible niveau d'abstraction, par exemple la définition des signatures de méthode pour les classes C# ou interfaces.

Schémas et modèles

Les fabriques de logiciels utilisent la terminologie IEEE 1471, pratique recommandée pour la description architecturale des systèmes utilisant beaucoup de logiciels, qui désigne une zone d'intérêt sous le terme point de vue. Les points de vue peuvent être définis pour diverses raisons, par exemple la description des différentes parties d'un produit, à différents niveaux d'abstraction, à différentes phase du cycle de vie du développement du logiciel. Les points de vue s'imbriquent. Un point de vue couche d'accès aux données peut donc contenir un point de vue bibliothèque d'accès aux données, un point de vue conception logique de la base de données, un point de vue conception physique de la base de données et un point de vue sécurité des données.

Les produits qui sont élaborés ou consommés à partir d'un point de vue donnée constituent une vue. Une vue se définit par ses points de vue pratiquement de la même façon qu'un objet se définit par sa classe. Un produit peut être un fichier, une partie d'un fichier, plusieurs fichiers ou des parties de plusieurs fichiers. Dans un point de vue bibliothèque d'accès aux données, par exemple, un produit peut être un fichier contenant une classe d'accès aux données pour une table de base de données. Une vue définie par le point de vue bibliothèque d'accès aux données peut être un projet contenant un ensemble de classes d'accès aux données pour toutes les tables d'une base de données spécifique. Les points de vue peuvent se recouper ou être modulaires. Les produits d'un point de vue sécurité des données, par exemple, peuvent être des préambules aux méthodes d'insertion, de remplacement et de mise à jour des classes d'accès aux données.

Les points de vue ont tendance à favoriser la création des types de projets et des outils. Par exemple, un point de vue bibliothèque d'accès aux données peut mapper un type de projet bibliothèque de classes basé sur un modèle de projet ayant certaines propriétés et contenant des modèles d'élément ayant certaines propriétés pour les classes d'accès aux données. Lorsque nous créons des projets de ce type, nous créons des vues basées sur ce point de vue. Le contenu des vues sont les fichiers dans le dossier du projet. Ce sont les produits définis par le point de vue.

À des niveaux d'abstraction plus élevés, les points de vue ont tendance à favoriser le développement d'outils. Par exemple, un point de vue processus métier peut se manifester par un outil de modélisation du processus métier. L'outil expose des vues sur ce point de vue sous la forme de modèles qui sont les produits définis par le point de vue. Il prend également en charge les activités définies par le point de vue via les commandes du menu et d'autres manipulations, telles que le glisser-déposer de la boîte à outils vers le diagramme pour créer un nouveau type de message.

Pour chaque point de vue, nous avons besoin d'un nom et d'une description. Nous avons également besoin de connaître les produits élaborés ou consommés, les étapes associées à la création ou à la modification de ces produits et les ressources utilisées pour suivre ces étapes. En d'autres termes, un point de vue doit nous indiquer ce qu'il faut créer, comment le créer et ce qu'on peut utiliser pour le créer (des motifs, des outils, des modèles, etc.). Les points de vue sont les blocs constitutifs des fabriques de logiciels. Ils formalisent les activités à grain fin qui servent à créer et à modifier des produits.

Chaque fabrique de logiciels définit l'ensemble des points de vue interdépendants nécessaires à la création de ses produits. On appelle l'ensemble de ces points de vue interdépendants un schéma. Vous pouvez comparer un schéma de fabrique à un sommaire qui vous aide à découvrir comment la fabrique de logiciels est organisée, de façon à pouvoir utiliser les ressources qu'elle offre pour créer les produits qu'elle cible. Un schéma de fabrique n'est pas comme un schéma de base de données qui vous aide à découvrir comment la base de données est organisée, vous permettant de naviguer, d'effectuer des requêtes et de manipuler les données qu'elle contient. Au lieu de décrire l'organisation d'une base de données, il décrit l'organisation d'une fabrique de logiciels.

Pour vous donner un petit exemple de schéma, observons une fabrique qui crée des applications administratives pour les entreprises basées sur une architecture orientée service (SOA). Pour cette fabrique, vous pouvez définir les points de vue suivants :

• Applications frontales Décrit la création des applications Web ou Windows qui prennent en charge l'entrée des données sur le bureau de l'utilisateur. Cela indique à l'utilisateur comment créer des formulaires Web ou Windows à l'aide d'un concepteur de formulaires et les commandes de l'entrée des données à partir d'une bibliothèque que vous avez développée. Les activités de ce point de vue sont de créer des formulaires Web ou Windows. Les produits sont les formulaires. Les ressources sont le concepteur de formulaires et la bibliothèque des commandes de l'entrée des données.

• Processus services Décrit la création de services Web responsable de la gestion des processus métier. Les services Web sont toujours construits de la même façon, à partir d'un motif, et possèdent un contrat de service décrit par une interface C# utilisant des objets typés, générés à partir d'un schéma XSD. L'activité de ce point de vue est la création de services Web. Les services Web sont les produits. Les ressources sont le motif et l'objet typé générateur.

• Services de plate-forme Décrit la création de services Web qui ne sont pas responsables des données métier, mais uniquement des services génériques de tous les systèmes, tels que l'impression, les audits, l'autorisation, etc. Ce point de vue offre des services génériques pouvant être réutilisés et indique à l'utilisateur comment évaluer et personnaliser chaque service. Les activités de ce point de vue sont l'évaluation et la personnalisation des services. Les produits sont les services personnalisés. Les ressources sont les services génériques.

Le dernier élément de la nomenclature de la fabrique de logiciel qu'il faut comprendre est le modèle de fabrique qui est un package installable contenant les ressources fournies par la fabrique de logiciels. Pour utiliser une fabrique, un praticien doit installer le modèle de fabrique sur un poste de travail.

Les fabriques sont habituellement développées de bas en haut. Une fois que vous avez identifié une famille de produits cibles au moment de créer des systèmes, vous pouvez commencer à découvrir et à décrire les produits et les activités, à les organiser en points de vue, à développer les ressources pour prendre en charge les activités, à organiser les points de vue dans un schéma de fabrique et à rassembler les ressources dans un modèle de fabrique.

Configuration des fonctionnalités

L'une des solutions pour créer des fabriques efficaces est de définir des produits, des activités et des ressources qui peuvent être mis en application dans de nombreuses solutions différentes. Par exemple, le point de vue bibliothèque d'accès aux données peut offrir une bibliothèque qui vous permet d'accéder à la base de données SQL. Il se peut que vous n'utilisiez pas toujours le même SGBDR pour chaque projet et que votre bibliothèque doive par conséquent être adaptée à un autre SGBDR. Il se peut aussi que les produits utilisés avec la bibliothèque et les descriptions des activités effectuées avec la bibliothèque doivent être adaptées en conséquence. Plus un point de vue tolère de variabilité, plus vous disposez d'une grande flexibilité pour l'appliquer à de multiples solutions mais parallèlement, plus vous aurez de travail pour le configurer correctement. L'adaptation de la variabilité introduit de la complexité. Vous devez trouver le juste équilibre entre trop et trop peu de variabilité pour que votre fabrique de logiciels soit efficace. Plus la fabrique est générique, moins vous gagnez en productivité et en prévisibilité.

Une bonne façon de déterminer le degré de variabilité à adopter est d'analyser les fonctionnalités des solutions que vous prévoyez de créer. À l'aide d'une technique appelée analyse uniformité/variabilité, vous séparez les fonctionnalités communes (ou obligatoires) qui doivent apparaître de la même façon dans chaque solution des fonctionnalités variables (ou optionnelles) qui peuvent apparaître uniquement dans certaines solutions ou dont la forme diffère d'une solution à l'autre. La description de l'analyse uniformité/variabilité va bien au-delà de la portée de ce livre blanc. Il existe toutefois de nombreux livres et documents traitant de ce sujet pour les lecteurs que cela intéresse.

Dans la fabrique qui crée des applications administratives pour les entreprises basées sur le SOA, l'accès aux données constitue une fonctionnalité obligatoire (chaque solution offre un accès aux données) mais le Web Front End est une fonctionnalité optionnelle (certaines solutions auront des Web Front Ends et d'autres auront des Windows Front Ends, voire aucun front end).

Dans une fabrique, vous pouvez utiliser des modèles de fonctionnalités pour décrire les fonctionnalités pouvant apparaître dans un membre de la gamme de produits, pour séparer les fonctionnalités communes des variables et pour indiquer comment les fonctionnalités variables peuvent apparaître. (Les modèles de fonctionnalités sont décrits en détails par Czarnecki et Eisenecker. Pour plus d'informations, consultez la section qui s'y rapporte dans ce livre blanc.) Les modèles de fonctionnalités peuvent également définir la façon dont les décisions à propos des fonctionnalités variables ont une influence mutuelle, comme par exemple indiquer qu'une fonctionnalité variable en implique une autre ou qu'une fonctionnalité est incompatible avec une autre. Ces décisions sont prises pour une application donnée en configurant le modèle de fonctionnalités. La configuration est un processus simple qui implique de spécifier quelles fonctionnalités variables décrites par le modèle apparaîtront dans l'application et sous quelle forme chacune apparaîtra. L'illustration 1 représente un modèle de fonctionnalités simple correspondant à la fabrique décrite précédemment.

Illustration 1. Exemple de modèle de fonctionnalités

Si les modèles de fonctionnalités sont souvent utilisés pour les fonctionnalités visibles par l'utilisateur présentées comme des exigences, ils peuvent également être utilisés pour les fonctionnalités de conception, de mise en œuvre et de déploiement uniquement visibles par les développeurs. Certains scénarios puissants sont activés en reliant ces fonctionnalités de sorte que la configuration des fonctionnalités visibles par l'utilisateur configure les fonctionnalités visibles par le développeur. Par exemple, en reliant les fonctionnalités Front End visibles par l'utilisateur aux fonctionnalités de présentation de la solution visibles par le développeur peut permettre à la fabrique de générer une présentation de la solution par défaut basée sur le type de front end choisi par l'utilisateur.

La modélisation des fonctionnalités est juste l'un des nombreux mécanismes connus qui peut être utilisé pour décrire la variabilité. D'autres incluent des formulaires, des tableaux, des assistants, des concepteurs, des modèles, des motifs, des scripts et un code. Les mécanismes de variabilité peuvent être utilisés seuls et sous diverses combinaisons pour spécifier et mettre en œuvre les fonctionnalités variables dans une fabrique de logiciels.

Les clés du succès

Quels sont les facteurs clés permettant de réussir le passage à une approche de fabrique de logiciels ? Il vous faut les aptitudes suivantes :

• Trouver l'uniformité et les variabilités de vos produits.

• Mesurer les performances actuelles de votre processus de développement de produits en termes de productivité et de qualité.

• Définir et améliorer un processus qui prend efficacement en charge le développement de produits.

• Proposer un modèle transparent qui aide chacun à comprendre la productivité et la qualité obtenues et à utiliser le modèle transparent pour favoriser la transformation culturelle.

• Planifier plusieurs projets à la fois.

• Développer, de façon rapide et économique, des ressources réutilisables qui encapsulent les compétences et les rendent plus faciles à réutiliser, en particulier les outils personnalisés.

• Identifier les domaines spécifiques et les cibler à l'aide de processus et d'outils personnalisés au lieu d'essayer d'appliquer des outils et des processus généraux à tous les domaines.

Mesure de la qualité et de la productivité

Maintenant que nous en savons un peu plus sur les fabriques de logiciels, regardons de plus près la mesure de la qualité et de la productivité dans le contexte d'une fabrique de logiciels.

Il se trouve que le schéma de fabrique offre un mécanisme utile pour organiser les mesures. Comme chaque point de vue cible un aspect spécifique du processus de développement de logiciels, vous pouvez utiliser des points de vue pour définir les mesures ciblées de productivité et de qualité. À l'aide de ces mesures, vous pouvez collecter des données pour des aspects spécifiques du processus de développement de logiciels. En analysant les données, vous pouvez déterminer quels points de vue sont à améliorer, comment les améliorer et ce que vous pouvez gagner si vous les améliorez.

Pour mettre cette approche en œuvre, vous devez disposer d'un moyen pour exprimer la taille, le temps et le budget consacré au produit et la qualité du produit. Ces mesures peuvent servir à quantifier la prévisibilité, la productivité et la qualité pour chaque point de vue. Elles peuvent également être utilisées pour évaluer les produits finals élaborés par votre fabrique. En mesurant chaque point de vue, ainsi que les performances globales de la fabrique, vous pouvez déterminer comment chaque point de vue affecte les performances globales de la fabrique et, par conséquent, combien investir dans la prise en charge des activités d'un point de vue donné avec des ressources réutilisables. Vous pouvez, par exemple, fournir des conseils simples pour les points de vue qui n'altèrent pas outre mesure l'efficacité globale et des concepteurs sophistiqués de bibliothèque des logiciels définitifs (DSL) pour les points de vue qui l'altèrent.

Cette approche est similaire à la façon dont les organisations d'entreprises importantes optimisent leurs processus métier. Ils définissent les compétences, les processus et les outils nécessaires à l'élaboration de produits dans un but commercial spécifique. À partir de là, ils mesurent l'effort nécessaire pour accomplir le processus et analysent ensuite s'ils peuvent approuver. C'est ce qu'ils appellent le contrôle du processus métier mais c'est en gros ce que nous faisons lorsque nous optimisons une fabrique de logiciels. Il est évident que les mesures sont un facteur essentiel dans l'établissement d'une référence des performances actuelles de votre fabrique et dans l'identification des bons investissements à faire pour le développement de la fabrique de logiciels. Ce processus vous permet d'obtenir le meilleur retour sur investissement en termes de prévisibilité, de productivité et de qualité. Cela vous aide à comparer les résultats aux objectifs initialement prévus avant de commencer le développement de votre fabrique.

Utilisation des points de fonctions pour exprimer la taille du produit

L'un des aspects du développement de logiciels que nous souhaitons probablement améliorer est la productivité. Pour quantifier la productivité, vous avez besoin d'une mesure que vous pouvez utiliser pour exprimer la productivité en termes de volume de logiciels créé dans un laps de temps donné. Lorsque nous sommes capables de prévoir la taille du système et de mesurer la croissance en termes de taille de produit lors du développement, nous pouvons prévoir avec plus de précision le temps nécessaire à l'achèvement du projet et mesurer la productivité en termes d'heures passés par unité de taille de produit. En mesurant la croissance et la taille actuelles, nous pouvons identifier les différences entre les valeurs actuelles et celles qui ont été planifiées, puis commencer à analyser et à gérer les différences lorsqu'elles sont évidentes.

À ce stade, vous vous demandez peut-être comment il est possible de prédire la taille et la croissance du produit avec suffisamment de précision pour que ce type de mesure et d'analyse soit utile. Cela ne semble certes pas possible si nous développons des applications arbitraires projet par projet. En utilisant une fabrique de logiciels, nous disposons toutefois de deux avantages permettant d'améliorer la prévisibilité de manière significative. D'une part, nous développons un membre d'une famille de produits spécifique aux caractéristiques connues, et non une application arbitraire. Une fabrique nous permettant de décrire une famille de produits et ses fonctionnalités saillantes et, surtout, d'affiner cette description avec l'expérience acquise dans le cadre de plusieurs projets, nous en savons beaucoup plus sur une application développée à l'aide d'une fabrique que sur une application arbitraire. D'autre part, nous développons l'application en appliquant les instructions fournies par la fabrique. Nous effectuons donc de nombreuses tâches de développement d'une manière très similaire d'une application à une autre, en utilisant parfois les mêmes motifs, modèles, bibliothèques et outils. Lorsque nous normalisons certaines opérations, une fabrique tend à supprimer toute variation superflue du processus de développement, améliorant grandement les chances que la taille et la croissance du produit suivent un motif similaire d'une application à l'autre. Si nous utilisons une fabrique de logiciels, la mesure de ces valeurs et l'identification, l'analyse et la gestion des différences entre les valeurs planifiées et les valeurs réelles peuvent être extrêmement utiles.

De nombreuses méthodes d'estimation vous permettant de déterminer la taille de votre système existent déjà. Si vous désirez une mesure permettant d'exprimer taille et productivité, une quantification objective est alors nécessaire. Celle-ci peut être obtenue à l'aide d'une méthode normalisée. L'une de ces méthodes est la mesure de la taille fonctionnelle (Functional Size Measurement), telle que définie dans la norme ISO 24570. (La norme ISO/IEC 24570:2004 définit une méthode permettant de mesurer la taille fonctionnelle d'un logiciel, fournit des instructions quant à la manière de déterminer les composants de la taille fonctionnelle d'un logiciel, indique comment calculer la taille fonctionnelle selon la méthode en question et fournit des lignes directrices pour l'application de cette méthode.) Cette norme ISO utilise des points de fonction pour exprimer la taille du système logiciel sur la base de spécifications fonctionnelles. Ces points de fonction peuvent être considérés comme une « mesure approximative » permettant de déterminer la taille d'un système et d'estimer l'effort et le planning. Lors du développement, cette mesure peut être utilisée pour déterminer si le projet nécessite un surcroît ou une réduction de travail par rapport à d'autres projets similaires.

Les points de fonction permettent de définir la taille du système en termes de fonctionnalités métier. Ces fonctionnalités sont déterminées à partir des exigences initialement collectées et évaluées à l'aide de la spécification. Une analyse des points de fonction s'appuie sur les connaissances en matière de développement d'applications orientées base de données et peut être appliquée chaque fois que vous créez un système utilisant la manipulation de données dans une base de données. Les points de fonction sont calculés selon le nombre de tables estimées contenues dans l'application et le nombre de fonctions de manipulation de données, de récupération de données et de mise à jour de données. Vous pouvez, à partir de cela, calculer un nombre de points de fonction exprimant la taille du produit. Une fois la taille du produit estimée exprimée, vous pouvez déterminer le temps nécessaire pour implémenter un point de fonction, voire même utiliser des données historiques déjà disponibles afin de prédire le temps requis. Une fabrique de logiciels peut influencer le temps passé à implémenter un point de fonction (productivité), le nombre de défauts par point de fonction (qualité), ainsi que la prévisibilité de vos estimations.

En examinant de plus près la prévisibilité, nous avons vu comment une fabrique de logiciels permet de séparer les fonctionnalités communes à tous les membres d'une famille de produits des fonctionnalités variables présentes uniquement chez certains membres, ou ayant des tailles ou caractéristiques différentes pour certains membres. Au lieu de collecter à partir de rien les exigences pour un produit donné, nous pouvons donc supposer qu'il présente les fonctionnalités communes partagées par tous les membres de cette famille et nous concentrer uniquement sur la spécification de ses exigences uniques ou variables.

Pour en revenir à l'analyse des points de fonction dans le contexte d'une fabrique de logiciels, nous constatons qu'il est possible de commencer avec une taille de produit minimum fixe que nous aurons toujours car notre famille de produits contient certaines parties fixes. Cette taille de produit minimum fixe est une mesure des fonctionnalités communes de la famille de produits. Nous pouvons également définir des tailles calculables pour de nombreuses fonctionnalités variables qui pourraient, ou non, être ajoutées à notre profil produit de base. Ces informations nous permettent d'estimer le coût d'une certaine configuration de fonctionnalités. Cette information peut, à son tour, nous permettre de décider quelles fonctionnalités développer. En d'autres termes, l'analyse des points de fonction reposant sur la configuration de fonctionnalités nous permet de faire, dès le départ, des compromis informés en ce qui concerne le coût et la fonctionnalité.

Supposons, par exemple, que nous ayons appliqué l'analyse des points de fonction et déterminé que le système que nous nous apprêtons à développer a une taille estimée de 500 points de fonction. Dès le départ, nous pouvons déterminer que la création de ce système représentera 6 500 heures de travail. À partir de là, nous pouvons exprimer notre productivité en tant que 13 heures (h)/point de fonction (pf).

Si nous effectuons également un suivi des défauts constatés dans le produit lors du développement, des tests d'acceptation utilisateur et de la production, nous pouvons aussi exprimer ce nombre en tant que mesure de qualité. Supposons que nous constatons 500 bogues lors du développement, 50 lors des tests d'acceptation, puis 5 une fois la production commencée. Nous pouvons alors exprimer ceci comme présentant 1 défaut/pf lors du développement, 0,1 défaut/pf lors des tests d'acceptation et 0,01 défaut/pf lors de la production.

Supposons maintenant qu'un bon nombre de ces défauts peuvent être retracés jusqu'au point de vue des applications frontales. Nous en déduisons que ce point de vue contribue grandement au nombre global de défauts et pouvons alors porter notre attention sur les améliorations nécessaires dans ce point de vue. Ce type d'analyse nous permet de déterminer quels sont les points de vue à améliorer, ainsi que la manière de le faire, afin de réduire le nombre de défauts lors de l'utilisation suivante de la fabrique de logiciels. L'avantage de la quantification du nombre de défauts par rapport à une mesure telle que les points de fonction est que vous pouvez désormais définir des objectifs pour les améliorations à réaliser avec vos investissements. Je souhaite, par exemple, que le nombre de défauts/point de fonction baisse de 20 pour cent pour le point de vue des applications frontales. L'analyse des défauts et des points de fonction par point de vue nous offre un outil puissant pour l'amélioration du processus de développement de produit car il nous permet de déterminer à quel niveau se situent les goulets d’étranglement et, ainsi, où et comment investir afin d'optimiser les résultats.

Les mesures de base, expliquées ci-dessus, peuvent vous renseigner quant au projet suivant, voire quant au projet en cours, vous indiquer si un développement supplémentaire est nécessaire et si le développement concerne les points de vue pour lesquels vous avez collecté des mesures. Supposons, par exemple, qu'après avoir collecté les exigences et effectué l'analyse des points de fonction, vous savez que le nouveau système aura 750 points de fonction (pf). Vous pouvez maintenant prédire que l'implémentation de ces exigences devrait aboutir à 9 750 heures de travail environ et que vous devrez constater approximativement 75 bogues lors des tests d'acceptation utilisateur.

La précision de ces prédictions dépend largement du niveau des mesures que vous avez collectées et du degré de ressemblance entre les futurs projets de développement de système et ceux dont vous avez collecté les mesures. Chaque point de vue d'une fabrique de logiciels permet un certain niveau de variabilité dans le développement du système. Le niveau de variabilité détermine, à son tour, les types de ressources que le point de vue peut offrir à l'utilisateur de la fabrique de logiciels et, ainsi, le niveau de cohérence d'un projet à l'autre en ce qui concerne cet aspect du produit. La première version de votre fabrique de logiciels peut, par exemple, contenir uniquement quelques points de vue décrivant l'architecture du système et offrant uniquement des lignes directrices permettant aux développeurs d'étoffer l'implémentation. Les développeurs utilisant cette fabrique devront écrire à la main un code volumineux. Toutefois, après avoir créé plusieurs systèmes à l'aide de cette fabrique, vous constaterez peut-être que la construction de la partie interface utilisateur de ces systèmes a tendance à beaucoup varier car les développeurs individuels interprètent les lignes directrices de manières très différentes. Vous pourriez en conclure que le point de vue interface utilisateur présente une variabilité importante. Si votre fabrique contient de nombreux points de vue avec un haut niveau de variabilité, vos mesures et prédictions seront moins précises que dans le cas de points de vue à variabilité moindre.

À ce stade, nous pouvons nous demander si le niveau de variabilité d'un point de vue donné est vraiment nécessaire ou pas. S'il ne l'est pas, nous devrions pouvoir accroître la précision de nos mesures et prédictions en supprimant la variabilité excessive ou superflue. Examinons, par exemple, le point de vue interface utilisateur une nouvelle fois, cette fois-ci en fournissant un ensemble de composants de bibliothèque prenant en charge les lignes directrices, ainsi qu'un outil graphique qui configure les chemins de navigation utilisateur. En fournissant ces ressources, nous formalisons certains aspects du processus de développement de l'interface utilisateur qui étaient auparavant vaguement définis. Cette formalisation réduit le niveau de variabilité présent dans le point de vue interface utilisateur. Les systèmes développés à l'aide de cette fabrique feront preuve d'une uniformité accrue en ce qui concerne la construction de l'interface utilisateur, conduisant ainsi à des mesures et prédictions plus précises. La magnitude d'erreur des estimations décroissant parallèlement à la réduction du niveau de variabilité présent dans la fabrique, la prévisibilité peut être améliorée au fur et à mesure de l'évolution de la fabrique en supprimant la variabilité excessive ou superflue. En pratique, la productivité et la qualité tendent également à s'améliorer avec la prévisibilité, du fait que la réduction de la variabilité réduit le temps requis pour créer une fonctionnalité donnée ainsi que le nombre de défauts introduits lors de sa création. À ce stade, un bref avertissement est de rigueur. Selon le rasoir d'Occam, la variabilité devrait être réduite autant que possible, mais jamais au point de prolonger le projet ni d'accroître son coût en contraignant les développeurs outre mesure.

Lorsque vous commencez à utiliser les points de fonction, vous pouvez utiliser au départ des données historiques provenant d'organisations environnantes figurant dans la documentation disponible afin de faire vos premières estimations. Les données historiques sont utiles car elles prennent en compte les influences organisationnelles, à la fois reconnues et non reconnues. La même idée s'applique à l'utilisation de données historiques au sein de la fabrique de logiciels. Des projets individuels développés à l'aide d'une fabrique de logiciels auront beaucoup de points communs. Même si vous ne disposez pas de données historiques issues de projets antérieurs, vous pouvez collecter des données à partir du projet en cours et les utiliser comme base sur laquelle estimer le reste du projet. Votre objectif devrait être de passer le plus rapidement possible de données organisationnelles ou moyennes de l'industrie à des données de fabrique et de projet (McConnell, 2006).

Utilisation des mesures pour améliorer une fabrique

En créant une référence ou en étalonnant réellement les paramètres de productivité et de qualité quantifiés en heures par point de fonction et en défauts par point de fonction, vous pouvez analyser les données du projet et identifier les activités susceptibles de prendre beaucoup de temps ou les points de vue présentant de nombreux défauts. Une fois l'étalonnage effectué, vous pouvez commencer à modifier l'organisation de la fabrique et à l'améliorer de nombreuses manières, telles que les compétences qu'elle requiert, le processus qu'elle définit ou les ressources réutilisables qu'elle fournit. Il est primordial d'identifier les parties devant être améliorées afin que vos investissements soient fructueux. Cela devrait être toutefois relativement aisé, du fait que vous disposez d'un moyen de déterminer dans quelle mesure chaque point de vue contribue à la prévisibilité, la productivité et la qualité. Une fois les données initiales de référence en place, vous pouvez exécuter une boucle continue qui analyse les performances de chaque point de vue, utilise ces informations pour déterminer les améliorations requises, effectue ces dernières, puis répète le processus.

Vous pouvez utiliser ce cycle vertueux pour viser diverses mesures. Pour accroître la productivité, par exemple, vous pouvez identifier le point de vue le moins efficace en termes d'heures/point de fonction et améliorer celui-ci en fournissant des instructions ou une formation supplémentaires ou meilleures ; en améliorant les modèles utilisés pour la création des versions initiales des produits de travail ; en fournissant des outils spécialisés permettant d'automatiser la création et la modification des produits de travail et ainsi de suite. L'un des éléments clé de ce processus consiste à estimer le coût d'une amélioration donnée, en estimant le gain en productivité probable qui résulterait de cette amélioration et en évaluant si le résultat justifie l'investissement apporté. Une fois l'amélioration implémentée et incorporée dans la fabrique, vous pouvez mesurer si elle a rempli les objectifs définis en termes de réduction en heures/point de fonction. La figure 2 illustre ce processus.

Figure 2. Boucle d'itération pour le développement de la fabrique

Application de Visual Studio Team System

Maintenant que nous avons appris comment définir une fabrique et utiliser des mesures et une analyse pour l'affiner de manière itérative, examinons comment permettre à notre équipe de développement de produits d'utiliser la fabrique pour créer les produits de travail requis. Cette habilitation commence par un environnement de développement prenant en charge l'ensemble du cycle de vie du produit, de sa création à sa suspension, tel que Visual Studio Team System. L'utilisation de Team System est essentielle pour permettre à vos équipes de développement de produit de tirer parti de l'approche décrite précédemment.

Team System est constitué de plus ou moins deux parties. Les diverses versions Visual Studio Team (versions pour architectes, développeurs et testeurs) installées sur l’ordinateur de développement font partie de l'IDE de développement Visual Studio et proposent des outils destinés à des rôles spécifiques au sein de l'équipe de développement. La deuxième partie est le Team Foundation Server (TFS) qui héberge des aspects de cycle de vie essentiels de Team System, tels que le contrôle de version, le suivi des éléments de travail, Team Build, le portail d'équipe et le magasin de données qui contient des données relatives aux projets utilisant le TFS.

Implémentation d'une fabrique avec Team System

Team System ne comprend pas les fabriques de logiciels, à l'heure actuelle. Du fait que Team System est si configurable et extensible, nous pouvons toutefois le configurer manuellement de sorte à prendre en charge une fabrique de logiciels en mettant en correspondance plusieurs parties du schéma de la fabrique avec divers éléments de configuration ou points d'extension.

Souvenez-vous qu'une fabrique de logiciels contient un schéma décrivant son organisation. Comme nous l'avons vu, le schéma de la fabrique définit un ensemble de points de vue interdépendants et chaque point de vue décrit les produits de travail, les activités et les ressources associés pour les utilisateurs ayant un rôle spécifique. Ces informations permettent de configurer Team System afin de développer des applications.

Vous pouvez mettre un point de vue en correspondance avec un concept que Team System appelle zone dans une ou plusieurs itérations. Le rôle associé à un point de vue peut être mis en correspondance avec un ou plusieurs rôles de projet Team System. En pratique, plusieurs rôles de point de vue seront probablement mis en correspondance avec un seul rôle de projet Team System. Vous pouvez ajouter les activités définies par un point de vue en tant qu'éléments de travail dans ces zones lors de la création du projet et les affecter directement au rôle approprié. Vous pouvez également les documenter en personnalisant les procédures et créer des types d'éléments de travail personnalisés afin d'en faire le suivi et de les lier aux produits de travail. Certains produits de travail peuvent être décrits à l'aide de types d'éléments de travail personnalisés. Vous pouvez ajouter les ressources de contenu, tels que les instructions, les motifs et les modèles, aux bibliothèques de documents du portail du projet. Les ressources exécutables, tels que les outils et les bibliothèques de classes, peuvent être placées dans le système de contrôle de version. Nous pouvons ajouter des mesures au magasin de données de Team System afin de quantifier et d'améliorer les performances de la fabrique.

Les éléments essentiels à la configuration de Team System sont l'Assistant de création de projets et le modèle de processus. L'Assistant de création de projets est un outil permettant de créer des projets dans le TFS. Il utilise un fichier sélectionné par l'utilisateur appelé modèle de processus afin de configurer le serveur pour le projet. Ce modèle contient plusieurs sections, chacune décrivant la manière dont une partie spécifique du serveur sera configurée. Le modèle de processus permet, par exemple, de définir les types d'éléments de travail, de personnaliser le contrôle de version, de définir les zones et les itérations, de définir les rôles, d'affecter les droits appropriés à chaque rôle, de configurer le portail du projet et de définir bien d'autres choses afin de personnaliser l'environnement et le processus de développement.

Examinons comment utiliser l'Assistant de création de projets et le modèle de processus pour configurer Team System de sorte qu'il prenne en charge une fabrique de logiciels.

Définition des éléments de travail

Team System utilise des éléments de travail pour faire le suivi du travail à effectuer en vue de la création d'un produit donné. Les éléments de travail décrivent le travail requis et identifient la personne ou l'équipe responsable de ce travail à un moment donné. Ces éléments de travail peuvent être de types différents conçus pour décrire différentes sortes de travail. Un bogue peut, par exemple, être décrit par un élément de travail de type Défaut contenant des informations concernant la résolution d'un bogue, telles que la description de ce dernier, les étapes permettant de le reproduire, le temps estimé pour analyser ou résoudre le bogue, et ainsi de suite. Les types d'éléments de travail sont créés ou modifiés en changeant les définitions XML chargées sur le serveur et utilisées lors de la création du projet. Vous pouvez également les modifier une fois le projet configuré.

Certains types d'éléments de travail définis par MSF pour CMMI Process Improvement, tels que Bug and Requirement, décrivent des produits de travail. Un type d'élément de travail, Task, décrit les activités effectuées pour faire avancer un produit de travail d'un stade à un autre. Vous pouvez utiliser efficacement ces deux types dans une fabrique car ils correspondent de très près aux concepts utilisés pour définir la fabrique. Nous pouvons, en particulier, réserver des éléments de travail pour les produits de travail définis, et des tâches pour les activités associées. Ces éléments de travail permettent de collecter des informations relatives au temps passé sur chaque activité et de déterminer l'impact de cette activité sur la productivité de la fabrique.

L'un des problèmes que vous rencontrerez lors de la mise en correspondance est que les éléments de travail ne s'imbriquent actuellement pas. Cette incapacité à imbriquer les éléments de travail rend difficile la description des produits de travail de points de vue agrégés ou composites, tels que le point de vue de couche d'accès aux données (Data Access Layer) décrit plus haut. Vous constaterez également que de nombreux produits de travail ne sont pas explicitement décrits par des éléments de travail dans un projet d'équipe typique. Par exemple, au lieu de créer un élément de travail pour décrire une bibliothèque d'accès aux données, nous pourrions créer un élément de travail pour décrire la construction d'une bibliothèque d'accès aux données, puis lier l'élément de travail aux fichiers source de la bibliothèque dans le système de gestion des configurations. Un autre problème rencontré est que les tâches Team System ne contiennent pas les pré- et post-conditions telles que les activités d'une fabrique, si bien que les critères pour les inclure dans le cadre ou les en exclure ne sont pas documentés et les décisions de planification doivent être prises manuellement.

Définition des zones et itérations

Vous pouvez lier les éléments de travail à une zone du projet ainsi qu'à une itération. Les zones permettent de réserver le travail sur une partie spécifique d'intérêt de la solution lorsque vous souhaitez exécuter des rapports sur les données accumulées dans le magasin de données. Les zones de Team System correspondent étroitement au concept de points de vue d'une fabrique de logiciels, tous deux représentant des zones d'intérêt ou de préoccupation.

Lorsque vous enregistrez le travail effectué sur des zones d'intérêt spécifiques, vous pouvez déterminer quelles sont les zones comportant le plus grand nombre de bogues ou demandant le plus de travail. Lorsque vous mettez les zones d'intérêt du suivi des éléments de travail en correspondance avec les points de vue de la fabrique, vous pouvez utiliser ces mesures pour obtenir des mesures de productivité et de qualité pour des points de vue spécifiques.

Vous devez définir correctement les zones et les itérations au début du développement du produit afin de dériver les informations correctes des éléments de travail. Une fabrique simplifie cette tâche en définissant les points de vue d'intérêt pour le type de produit en cours de développement. Il vous suffit de définir une zone pour chaque point de vue afin de configurer correctement les zones. Vous devrez alors peut-être mettre les noms des points de vue en correspondance avec des noms de zones qui seront connus de votre équipe de développement, afin qu'elle puisse rapidement identifier la zone à laquelle appartient un élément de travail donné.

Un ensemble de points de vue courants qui tendent à apparaître dans de nombreuses fabriques constitue un excellent point de départ pour définir les points de vue d'une fabrique. De bons exemples de points de vue courants sont fournis dans le schéma de la fabrique de logiciels en collaboration avec les entreprises (reportez-vous à la section à la fin de ce livre blanc). Deux points de vue courants qui s'avèrent particulièrement utiles lors de la configuration de Team System sont celui de l'ingénierie de système (System Engineering) et de l'ingénierie de projet (Project Engineering). Vous devez créer dans la zone d'ingénierie de système une sous-arborescence contenant les points de vue architecturaux qui décrivent les parties saillantes de votre système. Cela vous permettra d'identifier quelles parties du système ont l'impact le plus significatif sur la productivité (temps passé) et la qualité (nombre de défauts). La zone d'ingénierie de projet est également intéressante car elle permet d'identifier des anomalies dans la manière dont les activités du projet ont été formalisées ; elle peut aussi vous aider à décider d'améliorer, ou non, la définition des processus à certains points. La figure 3 montre un exemple de zones et d'itérations qui reflète le schéma d'une fabrique créant une application administrative orientée service à plusieurs parties frontales.

Figure 3. Exemple de définition de zones reflétant les points de vue

Les zones que vous définissez pour le suivi des éléments de travail évolueront, de même que la fabrique. L'ensemble des points de vue qui constituent le schéma de la fabrique changeront au fur et à mesure que la fabrique évoluera, tout comme le feront l'ensemble des points de vue que vous souhaitez mesurer. L'arborescence des zones peut devenir très complexe si vous tentez d'incorporer chaque point de vue défini par la fabrique. Il est primordial de ne pas diviser l'arborescence en un trop grand nombre de niveaux différents. Gardez à l'esprit que cette arborescence doit rester très simple, afin que les membres de l'équipe puissent facilement identifier les zones auxquelles les éléments de travail doivent être liés. Plus l'arborescence est imbriquée, plus il sera difficile de trouver la zone correcte pour un élément de travail donné. Si le processus devient trop compliqué, les développeurs réserveront simplement des éléments de travail situés près de la racine de la hiérarchie, ce qui irait à l'encontre de la création d'une arborescence très imbriquée.

Définition des rôles

Les rôles créés dans Team System doivent refléter tous les rôles identifiés par les points de vue dans le schéma de la fabrique. Ces rôles ne doivent pas être parfaitement identiques à ceux identifiés par les points de vue, mais chaque rôle du projet doit être mis en correspondance avec un ou plusieurs rôles identifiés par les points de vue. Les rôles identifiés par les points de vue étant généralement plus détaillés que ceux définis pour un projet, un rôle de projet implémente généralement plusieurs rôles de point de vue connexes.

Configuration des fonctionnalités du produit

La modification de l'Assistant et du modèle de processus permet d'activer la configuration au delà de celle activée par l'Assistant par défaut et les modèles de processus fournis avec TFS. Vous pouvez, en fait, créer des pages d'assistant personnalisées qui permettront à l'utilisateur de configurer certaines des fonctionnalités variables définies par la fabrique. Pour en revenir à l'exemple précédent de bloc constitutif pour accès aux données configuré de sorte à utiliser différents produits de base de données, vous pouvez décider de demander à l'utilisateur quel produit de base de données utiliser, puis placer une version du bloc constitutif préconfiguré pour ce produit dans le contrôle de version comme point de départ du projet. Bien que les fabriques requièrent généralement une configuration tout au long du processus de développement, personnaliser l'Assistant de création de projets et le format du modèle de processus constitue un bon départ. La figure 4 montre comment le modèle de fonctionnalité illustré à la figure 3 peut être configuré à l'aide d'une page d'assistant personnalisée.

L'Assistant de création de projets est un excellent point d'extensibilité qui prend complètement en charge le concept de fabrique qui consiste à trouver des ressources présentant une certaine uniformité. Prenez ces ressources et développez-les séparément. Définissez le niveau de variabilité requis pour réutiliser la ressource et utilisez une page d'assistant pour interroger l'utilisateur quant à la configuration des variables requise pour le projet en question. L'Assistant peut alors effectuer la personnalisation en fonction des informations saisies, puis adapter la ressource aux besoins du projet. Bien que le concept d'uniformité et de variabilité dans les fabriques aille au-delà de la préconfiguration de ces ressources, il peut constituer le point de départ du processus de personnalisation. Une fois une ressource sélectionnée configurée, la fabrique peut également fournir un outil de configuration supplémentaire permettant de modifier les configurations sélectionnées après la préparation initiale du projet.

Dans une fabrique, vous utiliseriez les modèles de fonctionnalité précédemment illustrés pour décrire les fonctionnalités possibles que vous souhaitez utiliser, la manière selon laquelle certaines décisions concernant une fonctionnalité peuvent influencer d'autres fonctionnalités et la manière dont l'instance de la fabrique est créée. Comme vous avez pu le constater dans l'exemple de la figure 1, vous pouvez créer un modèle de fonctionnalité de sorte à ce qu'il ressemble à un ensemble de fonctionnalités pour une fabrique affectée au développement d'une application administrative utilisant un SOA.

La figure 4 illustre comment ce modèle peut être reflété dans une page d'assistant personnalisée permettant de préconfigurer la fabrique.

Figure 4. Page personnalisée de l'Assistant de création de projets (Cliquez sur l'image pour l'agrandir.)

Il existe au moins deux autres manières de prendre en charge la configuration dans le cadre de la préparation d'un projet d'équipe, outre l'utilisation de l'Assistant de création de projets. Vous pouvez personnaliser le référentiel de contrôle de version de sorte à anticiper des décisions importantes relatives à la configuration qui seront prises lors du développement de solutions, afin qu'il soit facile d'enregistrer l'état de la solution dans la gestion des configurations avant que ces décisions soient prises et de le restaurer ultérieurement en cas de changement de décision. Cette technique est appelée backtracking (retour en arrière). Vous pouvez également définir des types d'éléments de travail qui reflètent les décisions de configuration, puis ajouter des instances de ces types à la base de données de suivi des éléments de travail au fur et à mesure que les décisions sont prises, de sorte à refléter les résultats ainsi qu'à planifier le travail qui en résulte.

Personnalisation du portail du projet

Team System offre un portail de projet que l'équipe de développement peut utiliser pour partager des informations relatives au projet. Ce portail est également le point d'entrée des procédures pour un modèle de processus spécifique, ainsi que pour les ressources réutilisables, telles que les modèles et instructions. Les ressources réutilisables devant être téléchargées vers le portail sont fournies par le modèle de processus. Vous pouvez également modifier le contenu affiché sur le site Web des procédures. Vous devez effectuer cette personnalisation à l'aide d'un document InfoPath. Ce dernier est compilé de sorte à créer un nouveau site Web pouvant être incorporé au modèle de processus. Une fois le nouveau modèle de processus téléchargé, vous pouvez créer des projets d'équipe qui utilisent le site Web de procédures personnalisé.

Ajout de mesures au magasin de données

Le magasin de données de Team System effectue le suivi de toutes les informations relatives au développement de la solution. Une section du magasin de données contient des informations sur les éléments de travail, ce qui est particulièrement intéressant du point de vue de la fabrique, comme décrit précédemment. D'autres sections contiennent des informations relatives aux tests, aux compilations quotidiennes et autres fonctionnalités de Team System. Vous pouvez étendre le magasin de données de deux manières différentes pour la prise en charge des mesures.

Vous pouvez, d'une part, modifier les champs conservés dans le magasin de données pour un type d'éléments de travail spécifique en changeant la définition de ce type, soit en modifiant les champs qu'elle contient, soit en ajoutant les champs à de nouveaux faits ou dimensions dans le magasin de données. Si un champ est marqué dans la définition du type d'éléments de travail comme pouvant faire l'objet d'un rapport, il sera ajouté de manière dynamique au magasin de données. Bien entendu, si vous souhaitez afficher des rapports sur ces champs supplémentaires, vous devrez également créer des rapports pour ces données et les télécharger vers le serveur de rapports, afin de les rendre accessibles aux autres membres de l'équipe.

Vous pouvez, d'autre part, incorporer des données générées par des outils de personnalisation. Si la fabrique propose des outils de personnalisation qui génèrent des données et que vous souhaitez utiliser ces données dans le magasin de données, vous pouvez alors ajouter un adaptateur de magasin de données personnalisé au TFS, comme illustré sur la figure 5.

Figure 5. Architecture du magasin de données du Team Foundation Server (Cliquez sur l'image pour l'agrandir.)

Pour mesurer la taille de chaque solution en termes de nombre de lignes de code, par exemple, vous créeriez un outil personnalisé qui compte les lignes de code d'un fichier, ainsi qu'un adaptateur de magasin de données personnalisé. Vous ajouteriez également une étape à la compilation quotidienne qui exécuterait l'outil personnalisé sur les sources de la solution actuelle et placerait le résultat obtenu dans un fichier. L'adaptateur de magasin de données personnalisé récupèrerait alors les informations du fichier et établirait des appels au modèle d'objet de magasin de données fourni par Team System pour ajouter ces informations au magasin de données. Vous pouvez afficher les données personnalisées à l'aide de rapports personnalisés.

Utilisation des structures de mesure (ISO 15939)

Nous avons, jusqu'à présent, vu comment définir une fabrique, affiner une fabrique à l'aide de mesures et d'une analyse et configurer Team System de sorte à prendre en charge une fabrique. Avant de pouvoir rassembler toutes ces connaissances afin de créer et affiner des fabriques avec Team System, il nous reste un point à aborder : comment collecter les informations appropriées.

Nous avons besoin de définitions formelles des relations existant entre ce que nous mesurons et les informations requises pour affiner la fabrique. Ces définitions sont appelées structures de mesure. Les structures de mesure combinent des mesures de base, des mesures dérivées et des indicateurs. Une mesure de base capture des informations sur un attribut unique d'une entité logicielle quelconque à l'aide d'une méthode de mesure spécifiée et est fonctionnellement indépendante de toute autre mesure. Une mesure dérivée est définie comme une fonction d'un minimum de deux mesures de base et/ou dérivées et capture des informations sur plusieurs attributs. Un indicateur est une mesure fournissant une estimation ou évaluation en appliquant un modèle d'analyse à une ou plusieurs mesures de base et/ou dérivées afin de répondre aux besoins d'informations spécifiés. Les indicateurs constituent la base de l'analyse des mesures et de la prise de décisions. Une structure de mesure décrit le besoin d'informations, les entités et les attributs appropriés, les mesures de base et dérivées, les indicateurs et la procédure de collecte des données. Vous pouvez ajouter des règles, des modèles et des critères de décision supplémentaires aux mesures de base et dérivées ainsi qu'aux indicateurs. La figure 6 illustre l'architecture d'une structure de mesure (McGarry, 2002).

Figure 6. Architecture d'une structure de mesure (Cliquez sur l'image pour l'agrandir.)

Les termes clé relatifs aux mesures logicielles et aux méthodes de mesure ont été définis dans la norme ISO/IEC 15939 sur la base du vocabulaire international ISO en matière de métrologie. Les termes utilisés dans ce livre blanc sont dérivés de la norme ISO 15939 et de PSM (Practical Software Measurement).

Définition d'une structure de mesure

La procédure suivante permet de définir une structure de mesure que nous pouvons ajouter au magasin de données du TFS :

• Définition et classification des besoins en matière d'informations

  Afin de nous assurer que nous mesurons bien les informations requises, nous devons clairement comprendre nos besoins en matière d'informations et leur relation avec les informations mesurées. L'expérience montre que la plupart des besoins en matière d'informations dans le cadre du développement de logiciels peuvent être regroupés dans l'une des sept catégories définies par la norme ISO 15939 : planification et avancement, ressources et coût, taille du produit et stabilité, qualité du produit, performances des processus, efficacité de la technologie et satisfaction client. Un exemple de besoin d'informations dans la catégorie taille du produit et stabilité pourrait être, « Mesurer la taille d'un produit logiciel pour évaluer l'estimation budgétaire initiale ».

  Vous pouvez utiliser ces besoins d'informations pour mesurer les propriétés d'un point de vue spécifique dans une fabrique de logiciels. Vous devez les hiérarchiser afin d'assurer que le programme de mesure mette l'accent sur les besoins dont l'impact potentiel sur les objectifs définis est le plus élevé. Comme décrit plus haut, notre objectif principal consiste généralement à identifier les points de vue dont l'amélioration offrira le meilleur retour sur investissement. Ces points de vue pouvant être imbriqués, il nous est souvent possible de rattacher des mesures à des points de vue de niveau supérieur. Si nous avons, par exemple, un point de vue interface utilisateur contenant des points de vue développement de composants Web et autorisation de l'utilisateur, nous pouvons rattacher les mesures de satisfaction client issues de composants Web spécifiques au niveau de l'interface utilisateur.

• Définition des entités et attributs

  Un attribut mesurable est une propriété reconnaissable d'une entité logicielle. Les entités pertinentes au besoin d'informations (« Mesurer la taille d'un produit logiciel pour évaluer l'estimation budgétaire initiale », par exemple) pourraient être un plan ou un calendrier de développement et un ensemble de fichiers source de référence. Les attributs peuvent être des points de fonction devant être complétés chaque période, des lignes source de code et une table d'expressivité linguistique pour les langages de programmation utilisés.

• Définition des mesures de base et des mesures dérivées

  Les mesures de base sont fonctionnellement indépendantes de toute autre mesure et capturent des informations sur un attribut unique. La définition de la plage et/ou du type des valeurs pouvant être acceptées par une mesure de base permet de vérifier la qualité des données collectées. Notre exemple contient deux mesures de base : la taille estimée du produit logiciel et la taille réelle. La plage pour ces deux mesures de base ira de zéro à l'infini. Une mesure dérivée capture des informations sur plusieurs attributs. Ces termes sont illustrés sur la figure 7.

  

  Figure 7. Croissance de la taille du logiciel - mesures de base et dérivées (Cliquez sur l'image pour l'agrandir.)

• Définition des indicateurs

  Les indicateurs constituent la base de l'analyse des mesures et de la prise de décisions. Il s'agit de valeurs de mesure présentées aux utilisateurs. Afin d'utiliser correctement un indicateur, l'utilisateur doit comprendre la relation entre la mesure sur laquelle il est basé et les tendances qu'il révèle. La structure de mesure doit donc fournir les informations suivantes pour chaque indicateur :

  • Des instructions pour l'analyse des informations. Dans le cas de notre exemple, nous pourrions fournir les instructions d'analyse suivantes : « Une augmentation du taux de croissance de la taille du logiciel indique un risque accru de dépassement des budgets de coût et de planification ».

  • Des instructions pour la prise de décisions basées sur les informations. Dans le cas de notre exemple, nous pourrions fournir les instructions relatives à la prise de décisions suivantes : « Procédez à un examen quand le taux de croissance de la taille du logiciel a une variation supérieure à 20 pour cent ».

  • Une illustration permettant d'interpréter l'indicateur. Dans le cas de notre exemple, nous pourrions fournir une illustration telle que la figure 8 et la description suivante : « L'indicateur semble suggérer que le taux de production du projet est en avance sur le calendrier. Après analyse approfondie, il s'avère toutefois que la taille réelle d'un élément était plus grande que prévue, en raison d'exigences omises qui furent seulement identifiées lors des tests initiaux. Les allocations de ressources, les plannings, les budgets ainsi que les plannings et plans de tests sont affectés par cette croissance inattendue ».

  

  Figure 8. Indicateur de représentation graphique - croissance du logiciel planifiée et croissance réelle

  Définition de la procédure de collecte des données

  Maintenant que nous savons comment mettre en relation les mesures de base avec les besoins d'informations, nous devons définir la procédure de collecte des données. Celle-ci indique la fréquence de la collecte des données, l'individu responsable, la phase ou activité devant faire l'objet de la collecte de données, les règles de vérification et de validation, les outils utilisés pour la collecte et le référentiel pour les données collectées.

  Utilisation d'une structure de mesure

  Nous devons examiner les deux points importants suivants afin de pouvoir utiliser une structure de mesure avec succès : influence sur les indicateurs et prévention des mesures dysfonctionnelles.

  Influence sur les indicateurs

  Afin d'utiliser de manière optimale les indicateurs pour l'analyse des mesures, la prise de décisions et la modification des processus, vous devez être sûr que leurs utilisateurs savent ce qu'ils représentent, comment les interpréter et ce qui peut être modifié pour influencer les résultats. Dans le cas de notre exemple, l'utilisateur doit comprendre que pour faire en sorte que la taille en points de fonction réelle corresponde à la taille en points de fonction planifiée, nous devons produire plus de points de fonction dans le même laps de temps (c'est-à-dire que nous devons être plus productifs). L'utilisateur doit également comprendre comment accroître la productivité.

  Prévention des mesures dysfonctionnelles

  Les preneurs de décisions doivent également savoir comment prévenir les mesures dysfonctionnelles. L'objectif des mesures est d'améliorer les performances en apportant des changements, tels que l'exécution d'activités différentes, l'application de ressources différentes, etc. Il est important de s'assurer du bien-fondé de ces changements. Vous ne voulez pas que des utilisateurs apportent des changements contre-productifs afin d'aboutir à un résultat attendu pour une mesure quelconque. Dans le cas de notre exemple, la pression ressentie pour aboutir à la taille en points de fonction réelle pourrait être telle que les membres de l'équipe pourraient commencer à ajouter des lignes de code superflues à l'implémentation. L'identification et la description des risques sont deux éléments essentiels à la collecte optimale de mesures. Il est fortement recommandé de ne pas mesurer les individus. Plus un indicateur social quantitatif se voit donner de l'importance, plus il risque de falsifier et corrompre les processus qu'il est supposé améliorer.

Assemblage

Nous voilà enfin prêts à combiner tout ce que nous avons appris et à aborder la manière de définir et utiliser les structures de mesure afin d'améliorer une fabrique de logiciels prise en charge par Team System.

Ajout de structures de mesure au magasin de données

Comme décrit plus haut, chaque structure de mesure doit au moins définir les besoins d'informations, les entités et attributs, les mesures de base et dérivées, les indicateurs et la procédure de collecte des données. Pour mettre ces éléments en correspondance avec le magasin de données de Team System, nous devons déterminer comment obtenir les informations requises, soit en modifiant les définitions des types d'éléments de travail de sorte à ajouter des champs puis les marquer comme faits ou dimensions, soit en créant un outil personnalisé ainsi qu'un adaptateur de magasin de données personnalisé chargé de collecter les données générées par cet outil. Nous devons également déterminer comment afficher les indicateurs, généralement en créant des rapports Microsoft SQL Server 2005 Reporting Services personnalisés.

Amélioration itérative

Une fois la fabrique mise en correspondance avec Team System, vous pouvez alors commencer à utiliser le programme pour créer des solutions. Il guidera votre équipe dans la création de solutions et vous fournira des informations basées sur les structures de mesure que vous avez définies et implémentées. Vous pouvez alors commencer à analyser les mesures et à utiliser les indicateurs afin d'identifier les améliorations possibles. Ces informations vous permettent de décider quels points de vue peuvent être améliorés, quel sera le gain apporté par ces améliorations et combien investir dans ces dernières. Pour terminer, vous pouvez effectuer les améliorations choisies, généralement en ajoutant des instructions et en fournissant des ressources optimisées pour prendre en charge la création des produits de travail. Lorsque vous créez des solutions utilisant ces améliorations, vous pouvez réutiliser les mesures et indicateurs pour déterminer si les gains réalisés sont comparables aux gains attendus, puis adapter votre planification d'investissements en conséquence.

Conclusion

Ce livre blanc est né d'un désir de changer la manière largement inefficace dont les logiciels sont actuellement créés, c'est-à-dire avec un développement pour utilisation unique ou de type « un projet à la fois ». Nos clients voient combien il nous est difficile de livrer les projets à temps, sans dépassement de budget et avec les fonctionnalités attendues. Nous pouvons nous rendre service, et à l'industrie dans son ensemble, en capturant les connaissances issues de notre expérience et en les transférant vers d'autres projets à l'aide de la fabrique. Nous avons appris comment définir une fabrique et comment mesurer ses performances en termes de productivité et de qualité.

Nous pouvons décrire les performances de nos fabriques en quantifiant les tailles des produits créés, en mesurant le temps passé à leur création et en enregistrant le nombre de défauts trouvés. La mise en correspondance du schéma de la fabrique avec Team System est effectuée à l'aide des points de personnalisation et d'extensibilité de Team System. Nous pouvons configurer Team System en plaçant les ressources identifiées par le schéma de la fabrique dans le référentiel de contrôle de version ou le portail de fondation de l'équipe. Ce portail permet aussi de fournir des procédures pour les activités décrites dans le schéma de la fabrique. L'Assistant de création de projets nous permet d'organiser la configuration initiale de la fabrique ; nous pouvons alors utiliser la modélisation des fonctionnalités pour créer une mise en correspondance permettant de définir les formulaires à ajouter à l'Assistant. Une grande partie du projet initial est effectuée à l'aide des modèles de processus, modèles qui peuvent être modifiés afin de prendre en charge nos fabriques.

En définissant des structures de mesure et en les implémentant dans le magasin de données de Team System, nous pouvons collecter des mesures décrivant les performances de la fabrique en termes de productivité et de qualité. Ces mesures nous permettent, à terme, d'améliorer constamment nos fabriques et d'accroître non seulement notre productivité et notre niveau de qualité, mais également la prévisibilité en supprimant la variabilité excessive ou superflue.

L'implémentation des fabriques avec Visual Studio Team System a pour résultat final des projets plus performants et une satisfaction client accrue.

Références :

Austin, Robert D. Measuring and Managing Performance in Organizations. New York, NY : Dorset House Publishing Co., Inc., 1996.

Greenfield, Jack, and Keith Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianapolis, IN : Wiley Publishing, Inc., 2004.

McConnell, Steve. Software Estimation: Démystification de l'art. Redmond, WA : Microsoft Press, 2006.

McGarry, John, et al. Practical Software Measurement: Objective Information for Decision Makers. Boston, MA : Addison-Wesley Professional, 2002.

À propos des auteurs

Marcel de Vries est architecte informaticien chez Info Support aux Pays-Bas, ainsi que MVP pour Visual Studio Team System. Marcel est architecte en chef de la fabrique de logiciels Endeavour, conçue pour la création d'applications administratives pour entreprises orientées service utilisées par de nombreuses grandes entreprises clientes d'Info Support. Marcel intervient régulièrement dans le cadre d'événements locaux aux Pays-Bas, y compris Developer Days et Tech-Ed Europe. Il est également formateur à temps partiel au centre de connaissances d'Info Support. Vous pouvez consulter son blog à l'adresse http://blogs.infosupport.com/marcelv/.

Jack Greenfield est architecte spécialisé en infrastructures et outils d'entreprise chez Microsoft Corporation. Il fut auparavant architecte en chef (groupe de travail praticien///), chez Rational Software Corporation et fondateur et directeur technique de InLine Software Corporation. Chez NeXT Computer, il a développé l'infrastructure d'objets d'entreprise qui fait désormais partie des objets Web d'Apple Computer, Inc. Intervenant et auteur bien connu, il a co-écrit (avec Keith Short, Steve Cook et Stuart Kent) le livre à succès et primé Software Factories : Assembling Applications with Patterns, Models, Frameworks, and Tools. Jack a également contribué à UML, J2EE et spécifications OMG et JSP connexes. Il détient un B.S. (diplôme universitaire de premier cycle) en Physique, délivré par George Mason University.