La méthode SMV : Spécification, Modélisation, Validation

1. Les objectifs

L’objectif principal de la méthode SMV est d’offrir aux parties prenantes un ensemble de méthodes et procédés pour réduire les risques techniques et fonctionnels d’un projet informatique et d’en améliorer l’assurance qualité. Elle met l’accent sur les exigences du client afin de :

• créer un modèle exécutable,
• créer des séquences de tests fonctionnels,
• offrir aux concepteurs des spécifications complètes, détaillées et éprouvées.

À la manière des développements agiles, la méthode SMV s’inscrit dans la V & V à chaque étape des cycles itératifs du développement logiciel en réalisant, à chaque itération, l’ensemble des trois objectifs défini ci-dessus et en répondant constamment aux deux questions :

• Les spécifications reflètent-t-elles exactement les besoins ?
• Le produit répond-il aux exigences des spécifications ?

Elle va, afin de réduire le coût de développement d’un projet informatique, identifier les erreurs et omissions possibles et réduire les risques dus aux différents écueils techniques et fonctionnels pour réduire le délai de mise sur le marché et optimiser le retour sur investissement des projets informatiques.

1.1. Pourquoi créer un modèle exécutable ?

La méthode SMV permet, uniquement à partir des exigences du client, de modéliser le système demandé en langage UML puis MDA afin d’en extraire un modèle exécutable. L’obtention de ce modèle identifiera l’ensemble des fonctions du système, et permettra ainsi d’identifier avant le commencement de la phase de développement les omissions et incohérences dans les exigences du client.

L’avantage principal est l’obtention d’un cahier des charges précis qui pourra être transmis ensuite aux réalisateurs. Un second avantage est que la création de ce modèle va répondre au premier V de la V & V, en vérifiant à chaque itération si les spécifications définissent à elles seules le système de manière complète. Elle répondra à chaque instant à la question : « Suis-je en train de réaliser le produit souhaité ? »

1.2. Pourquoi créer des séquences de tests fonctionnels ?

Les séquences de tests vont valider le système en cours de développement. En profitant du modèle exécutable, les séquences de test créées grâce aux modèles UML et aux spécifications UTP à partir des exigences, vont répondre au deuxième V de la V & V, en validant à chaque étape que le système en cours de développement répond exactement aux exigences. Ces séquences répondront à la question : « Suis-je en train de réaliser mon produit correctement ? ».

1.3. Pourquoi offrir des spécifications complètes, détaillées et éprouvées ?

Disposer de spécifications complètes, détaillées et éprouvées permet de poursuivre dans le cycle de développement à partir de faits précis et d’éviter les risques liés à l’imprécision du cahier des charges. La transformation des spécifications littérales en spécifications modélisées offre une interprétation exacte et sans ambigüité de la demande du client.

2. Une solution articulée autour de trois types de logiciels

Afin de modéliser et d’exécuter les opérations effectuées selon ces trois axes, la méthode SMV utilise trois types de logiciels. Le premier est l’environnement de développement Eclipse qui sert de base et de support pour toute la méthode SMV. Par dessus Eclipse viennent se greffer les deux autres outils principaux, les outils Xcarecrows développé par Cogenit et fournis sous licence libre et les outils Rational^® Software de IBM.

2.1. IBM Rational^® Software

• Rational^® Requisite Pro^™ permet, grâce à plusieurs matrices de traçabilité, de suivre les modifications à chaque étape de la gestion itérative des exigences.
• Rational^® Software Modeler^™ sert de modeleur UML pour réaliser, par exemple, les diagrammes de classes ou de cas d’utilisation.
• Rational^® Functional Tester^™ sert d’automate de test sur lequel appliquer de manière quasiment automatique les tests extraits des diagrammes de séquences pour les exécuter sur le modèle exécutable.

2.2. Xcarecrows

Xcarecrows 4 XML

Ce module complète Eclipse afin de prendre en charge les tâches requises par un éditeur XML. Il offre une interface graphique XML, un schéma XSD, un éditeur de feuilles de style XSL, un comparateur graphique d’arborescences XML, un vérificateur intégré de schémas XSD et un ensemble d’outils pour la transformation XSL.

Xcarecrows 4 MDA

Ce module fournit un ensemble d’outils pour modéliser et vérifier le comportement de tous types d’applications grâce à une approche hiérarchique par machine à états.

Xcarecrows 4 MDI

Ce module fournit une interface graphique pour modéliser les applications au langage UML et les exécuter en accord avec le processus MDA défini par l’OMG. Xcarecrows 4 MDI s’intègre parfaitement dans Rational® Software Modeler développé par IBM^®.

Xcarecrows 4 SSL édition MIDP

Il s’agit d’une bibliothèque Java autonome pour créer des connexions sécurisées SSL/TLS au-dessus des API CLDC 1.1 et MIDP 2.0.

Xcarecrows 4 UTP

Il s’agit d’un outil précurseur dans le domaine du test qui décrit explicitement l’architecture sur laquelle appliquer de manière automatique les tests fonctionnels qui valident le système développé.

Xcarecrows 4 Developers Edition

Ce module comprend, dans un seul paquetage, l’ensemble des outils Xcarecrows pour le développement de modèles MDA comme Xcarecrows4MDI et Xcarecrows4MDA, pour développement en UML des applications MDA, et Xcarecrows4XML, pour éditer des documents XML, des schémas XSD et des feuilles de style XSL.

3. Une démarche articulée autour de trois axes

La méthode SMV s’articule autour de trois axes : la gestion itérative des exigences, la gestion itérative des tests et la gestion itérative des modèles.

3.1. La gestion itérative des exigences

Il s’agit d’une méthode de développement de modèle qui crée trois types de modèles UML : le diagramme de cas d’utilisation, le diagramme de classe et le diagramme de séquences. La méthode de la gestion itérative des exigences consiste à utiliser les modèles UML pour décrire en langage informatique les besoins du client.

Figure 4 : Principe de la gestion itérative des exigences

Le diagramme de cas d’utilisation : La première étape de la méthode consiste à transformer l’expression des besoins en un diagramme de cas d’utilisation. Ce dernier découle d’une étape de recueil, d’analyse et d’organisation des besoins menée pour recenser les grandes fonctionnalités du système. Il constitue un langage d’interface entre le client et le concepteur.

Figure 5 : Diagramme de cas d’utilisation d’un site de E-commerce en cours de développement

Chaque ovale de ce diagramme reflète une fonction identifiée par le client. Il sert de fondement à la méthode SMV en ce sens qu’il traduit en modèle le besoin et qu’il permet la création du diagramme de classes qui représente la structure interne du système. Le diagramme de classes : Ce diagramme montre la structure interne de l’application. Plus les exigences du système sont complètes et moins les connaissances métiers seront nécessaires pour modéliser un diagramme de classes complet. Dans le meilleur des cas, on retrouve, avec une relation « un pour un », les fonctionnalités du diagramme de cas d’utilisation.

Figure 6 : Diagramme de classes d’un site de E-Commerce en cours de développement

Les diagrammes de séquences : Les diagrammes de séquences traduisent les exigences fonctionnelles en méthodes et actions ordonnées à appliquer au système. Ils décrivent exactement le cheminement nécessaire pour réaliser les objectifs souhaités par les parties prenantes.

Figure 7 : Exemple d’un diagramme de séquences de l’inscription d’un site de E-Commerce en cours de développement

Il peut y avoir un ou plusieurs diagrammes de séquences par fonction du système. Ils ont une double utilité :

• offrir aux concepteurs du système des exigences claires, complètes et détaillées,
• mais aussi offrir aux testeurs des séquences de test applicables sur toutes les plates-formes.

Cette succession de modèles UML offre aux concepteurs des exigences claires complètes et détaillées grâce aux diagrammes de séquences, mais aussi un diagramme de classes, qui sert de base à la gestion itérative des modèles, et le profil UTP, qui sert de base à la gestion itérative des tests.

Figure 8 : Schéma complet de la gestion itérative des exigences

L’utilité de Rational Requisite Pro dans la gestion itérative des exigences Le schéma de la figure 7 montre en détail l’utilisation de Rational Requisite Pro tout au long de l’enchaînement des étapes du déroulement de cette méthode.

Le but premier de Rational Requisite Pro est d’enregistrer les exigences du client et de tracer chaque modification des exigences. Mais Rational Requiste Pro sert aussi à tracer à chaque étape du développement les liens et leurs modifications à chaque changement et modification des modèles.

En liant chaque modèle UML à un attribut Rational Requisite Pro, nous créons quatre matrices de traçabilité qui suivent les changements à chaque étape de la gestion itérative des exigences. Cet utilisation de Rational Requisite Pro répond au premier impératif de la V & V, la vérification en assurant à chaque instant que l’activité est bien réalisée et est conforme à son plan de réalisation et qu’aucun défaut non géré n’est introduit à aucune étape de la gestion itérative des exigences.

Figure 9 : Schéma des liens de la matrice de traçabilité de la gestion itérative des exigences

3.2. La gestion itérative des tests

La dernière étape de la méthode SMV est la gestion itérative des tests. Après avoir traduit les exigences en diagramme de séquences, et avoir créé un modèle exécutable sur lequel vérifier la cohérence et l’exhaustivité du cahier des charges, il ne reste plus qu’à créer des séquences de test à partir des diagrammes de séquences et à les valider sur le modèle exécutable pour avoir un ensemble de séquences de test qui valideront le système réel à chaque itération afin de répondre au deuxième V de la V & V. Cette gestion itérative des tests permet d’avoir à chaque instant d’un développement itératif des tests prêts à être exécutés à la fois sur un modèle, mais aussi sur le système réel.

Le profil UTP : Comme expliqué dans le chapitre sur la gestion itérative des exigences, le profil UTP (UML Testing Profile) [1] permet aux testeurs et aux développeurs de communiquer avec le même langage. Il offre un ensemble de stéréotypes pour structurer les tests et leur appliquer simplement l’ensemble des paramètres qui entrent en jeu pour la validation d’un outil. La figure 8 représente l’ensemble des stéréotypes proposés par l’OMG.

Figure 10 : Ensemble des stéréotypes défini par l’OMG pour le profil UTP

Le schéma général de la gestion itérative des tests

Figure 11 : Principe de la gestion itérative des tests

La création des scripts de tests : À partir des diagrammes de séquences et de la transformation UTP, nous obtenons un ensemble de scripts de test exécutables avec un automate du type Rational Functional Tester. Ces tests générés directement à partir de l’expression des besoins vérifient à chaque instant les modifications par rapport à l’expression des besoins et valident le système final à chaque étape en vérifiant la conformité du système avec les besoins initiaux.

3.3. La gestion itérative des modèles

La gestion itérative des modèles utilise le diagramme de classes de la gestion itérative des exigences en association avec le paradigme MDA (Model-Driven Architecture) pour créer un modèle exécutable. La création de diagrammes d’objets et de diagrammes état-transition génère, grâce à Xcarecrows 4 MDA et Xcarecrows 4 MDI, un modèle exécutable de l’application. Ce modèle servira à valider les séquences de test et vérifier l’état du cahier des charges.

Le paradigme MDA, l’assurance d’un système validé : Dans la méthode SMV, le paradigme MDA est représenté par deux modèles UML, les diagrammes d’objets et les diagrammes état-transition. Les diagrammes d’objets représentent les instances des machines à états finis et les flux de données du système alors que les diagrammes état-transition représentent les transitions à l’intérieur du modèle.

Figure 12 : Exemple de diagramme d’objets pour le paradigme MDA d’un site de E-Commerce en cours de développement

Figure 13 : Exemple d’un diagramme état-transition d’un site de E- Commerce en cours de développement

Ce modèle, réalisé directement à partir des exigences du client, démontre le niveau de complétion des exigences et offre rapidement des informations sur la qualité des exigences fournies par les parties prenantes. De la même manière, il pourra valider le fonctionnement des séquences de test créées lors de la gestion itérative des tests qui devront être exécutés à la fois sur ce modèle et sur le modèle réel pour vérifier et valider la cohérence des développements à chaque étape du projet.

L’avantage du MDA dans la méthode SMV n’est pas de générer automatique du code pour remplacer le travail des concepteurs, mais d’obtenir un modèle simplifié du système à réaliser pour valider les tests de la gestion itérative des tests et vérifier la qualité des exigences fournies par le client.

Le schéma général de la gestion itérative des modèles

Figure 14 : Principe de la gestion itérative des modèles

4. Comment la méthode SMV réussit à réduire les risques techniques et fonctionnels des projets informatiques

SMV est une méthode d’assistance au développement logiciel. Elle réduit les risques inhérents à la création et à l’amélioration des systèmes d’information ; elle s’inscrit parfaitement dans la V & V, car elle intervient dans le processus technique du développement logiciel en créant un référentiel unique à partir des exigences du client pour disposer d’une base de vérification et de validation. Ce référentiel unique est le modèle exécutable créé lors du processus de gestion itérative des modèles. Réalisé uniquement à partir des exigences, il permet de :

• réduire les risques liés à une architecture défectueuse : Comme l’architecture est déjà modélisée et que certains tests issus des exigences ont été exécutés dessus, l’architecture fournie aux concepteurs est validée pour une réalisation plus robuste,
• mieux estimer la charge du projet : Disposer d’un modèle global permet de connaître les points susceptibles de créer des difficultés dans le projet. Disposer de ces connaissances sert à mieux répartir les actifs dans un projet pour optimiser son temps de réalisation,
• préciser le cahier des charges : En créant le modèle exécutable uniquement à partir du cahier des charges, les omissions et les contradictions dans le cahier des charges seront directement retranscrites dans le modèle. On a ainsi dès la phase de création du modèle un aperçu de la qualité du cahier des charges,
• mieux mesurer le calendrier nécessaire : Ceci revient à mieux estimer la charge du projet,
• réduire les risques liés aux changements de dernière minute : Appliquer les changements de dernière minute sur le modèle avant de les appliquer sur le projet réel permet de vérifier et de corriger les contradictions et les erreurs qui peuvent être engendrées par ces changements. Le fait de les appliquer sur le modèle de simulation transforme ces changements de dernière minute en nouveaux besoins.

La méthode SMV réduit les risques d’incompréhension dans les projets informatiques en créant des séquences d’actions directement à partir des exigences. Ces séquences d’actions, en liaison avec le référentiel unique créé sont la traduction des exigences littérales du client en exigences fonctionnelles qui permettent à la maîtrise d’ouvrage et à la maîtrise d’œuvre de parler le même langage.

Enfin, ces séquences d’actions, traduction direct des exigences clients, sont transformées grâce à l’utilisation du profil UTP en séquences de test pour valider le système toujours suivant le principe de la V & V, c’est-à-dire en vérifiant la conformité du système avec les exigences du client. L’utilisation du profil UTP pour transformer les exigences en séquences de test permet aux testeurs et aux développeurs de parler le même langage dans tout le cycle de vie du développement du logiciel. Ceci réduit les risques liés à la pénurie de testeurs compétents, mais surtout assure la conformité du projet aux exigences initiales. Bref, il en résulte l’assurance d’une validation correcte, car le besoin initial du client peut être tracé durant chaque étape de création de ces scripts de test.

Références :

1. Le profil UTP a été spécifié par l’OMG^® dans le document UML Testing Profile, Version 1.0 formal/05-07-07 en date de juillet 2005.

Cet article est disponible en téléchargement à l'adresse : http://www.cogenit.fr/index.php/ressources/livres-bleus/smv-methode-agile-assurance-qualite

Les écueils à éviter dans les projets informatiques

On peut différencier les écueils éventuels dans un projet informatique suivant deux catégories, les écueils techniques et les écueils fonctionnels. Les premiers sont le plus souvent dus aux problèmes internes à l’équipe de développement d’un projet informatique; ce sont, par exemple, de mauvaises méthodes de codage ou bien l’absence d’outils de gestion de versions. Les écueils fonctionnels se retrouvent dans les processus mêmes de l’outil à développer; ce sont, par exemple, les obstacles dans la relation entre la maîtrise d’ouvrage et la maîtrise d’œuvre.

1. Les écueils techniques d'un projet informatique

D’après un article de software-testing-zone.blogspot.com [1], neuf écueils techniques peuvent être identifiés dans un projet informatique :

• les problèmes de communication
• un calendrier irréaliste
• une mauvaise architecture
• de mauvaises méthodes de codage
• une absence de gestion de versions
• des outils externes bogués
• un manque de testeurs expérimentés
• des changements de dernière minute
• le facteur humain.

Évaluons chaque point de ces écueils pour identifier les différentes responsabilités. En considérant l’utilisation d’un schéma « maîtrise d’œuvre <=> maîtrise d’ouvrage » avec éventuellement une assistance à maîtrise d’ouvrage, nous pouvons ranger ces neuf écueils selon les trois catégories suivantes :

• La première est constituée des mauvaises méthodes de codage et de l’absence de gestion de versions. Elle est à imputer exclusivement à la maîtrise d’œuvre. Une maîtrise d’œuvre compétente doit toujours mettre en place un outil de gestion de versions et dispose le plus souvent de méthodes formalisées de codage.
• La deuxième est constituée des écueils à imputer à la maîtrise d’ouvrage. Ces derniers sont dus aux choix des décideurs du projet. Ce sont, par exemple, la mise en place d’un calendrier irréaliste, la mise à disposition d’outils bogués ou non qualifiés, ou des changements de dernière minute.
• La troisième catégorie est constituée des écueils à imputer à l’assistance à maîtrise d’ouvrage. Ce sont les difficultés dans la relation entre maîtrise d’œuvre et maîtrise d’ouvrage, comme le manque de personnes compétentes pour le test, la mauvaise communication interne dans le projet et une mauvaise définition de l’architecture.

Le facteur humain est un écueil qui peut entrer dans chacune des trois catégories, néanmoins, après avoir pris les précautions nécessaires, le facteur humain reste incompressible.

Figure 2 : Les écueils techniques des projets informatiques classés en quatre catégories

1.1. Comment réduire les risques associés aux écueils techniques ?

Les écueils imputables à la maîtrise d’œuvre.

Ce sont les mauvaises méthodes de codage et l’absence de gestion de versions. Dans ces deux cas, pour réduire les risques, on ne peut pas optimiser les méthodes, mais simplement expliquer l’utilité d’un outil de gestion de versions et les gains de productivité engendrés par la mise en place de méthodes de codage formalisées.

Les écueils imputables à la maîtrise d’ouvrage.

À part la mise à disposition d’outils externes bogués, les autres écueils sont gérables grâce à des études amont au développement. Dans cette catégorie, nous avons identifié la mise en place d’un calendrier irréaliste et les changements de dernière minute.

Le calendrier irréaliste

Il est difficile d’évaluer simplement, à partir du besoin client, la charge de travail à effectuer pour mener à bien un projet informatique. Comme le dit la Loi de Golub, un projet mal planifié prend trois fois plus de temps que prévu alors que le même projet, bien planifié, n’aurait pris que deux fois le temps prévu. Cette loi reflète d’une manière humoristique l’importance d’avoir une vision précise d’un projet afin de l’évaluer correctement. Une solution pour résoudre ce problème est de disposer d’un modèle qui retranscrirait les exigences principales d’un projet informatique avant de lancer la phase de développement.

Les changements de dernière minute

Ces changements entraînent du développement de dernière minute et augmentent le risque de défauts dans le système final. Ils génèrent le risque qui a le plus de probabilité d’occurrence. Ils peuvent engendrer des régressions dans le système et obliger la modification de code déjà écrit. Une méthode pour réduire le risque sur les changements de dernière minute est la mise en place de procédures agiles qui livrent des itérations courtes, validées à chaque étape et d’inclure les changements de dernière minute dans les livraisons suivantes. Mais qu’en est-il des changements en cours de projet qui rendent les premières exigences incohérentes ? Une solution serait, sur chaque itération, d’exécuter l’exigence sur un modèle déjà créé à partir des exigences précédentes.

Les écueils imputables à l’assistance à maîtrise d’ouvrage.

Ils sont au nombre de trois, les problèmes d’architecture, les problèmes de communication et le manque de testeurs compétents. Ces écueils sont assez faciles à éviter, car ils peuvent être étudiés et analysés en amont.

Les problèmes de communication interne au projet

Il est clair que, dans les projets informatiques, l’expression du besoin et le retour sur les possibilités techniques sont des processus à optimiser. Une solution est d’analyser les exigences en amont et de les rédiger dans un langage que la maîtrise d’œuvre peut comprendre. De même, modéliser simplement les exigences avant de commencer le développement refléterait à la fois l’état de complétion des exigences, mais aussi les incohérences possibles entre deux besoins.

Le manque de testeurs compétents

Le test représente une part importante dans le développement logiciel ; d’après www.basildev.com, il représenterait entre 20 et 50% [2] du coût d’un projet. Les testeurs occupent par conséquent une part substantielle dans le processus de développement logiciel. Sans préjuger de la qualité des testeurs, disposer de séquences de tests automatisées qui correspondent aux exigences du système avant la livraison d’une première version, serait un atout, mais aussi un outil qui accélérerait le cycle de développement logiciel en préparant la phase de test avant la phase de développement.

Une architecture médiocre

Les bonnes architectures découlent de bonnes connaissances du métier ; c’est là toute la difficulté de fournir à la maîtrise d’œuvre une architecture correcte. Une solution offerte par le langage UML est de modéliser le système uniquement à partir des exigences. En exécutant le modèle, on peut découvrir si l’architecture est complète et donc si les exigences sont complètes.

1.2. Quatre propositions pour réduire les risques d’un projet informatique

L’analyse des écueils techniques et de leurs solutions conduit à faire quatre propositions qui permettraient d’optimiser le couple risque-agilité :

• Modéliser le système uniquement à partir des exigences afin de vérifier l’exhaustivité du cahier des charges, mais aussi les incohérences entre deux besoins
• Transformer un besoin en exigence exécutable et le rédiger dans un langage clair et précis pour la maîtrise d’œuvre
• Exécuter chaque nouvelle exigence sur un modèle créé à partir des exigences précédentes
• Disposer de séquences de tests automatisées qui correspondent aux exigences du système avant la livraison d’une première version

2. Les écueils fonctionnels d'un projet informatique

Ces difficultés sont différentes de celles décrites au chapitre précédent dans le sens où elles sont présentes dans les fonctions de la gestion de projet a contrario des techniques à appliquer pour réaliser un projet. D’après Nathan Y. Hattab, consultant en systèmes d’informations et membre de l’AFAI [3], il y a cinq écueils fonctionnels [4] dans un projet informatique :

• l’inexpérience du chef de projet ou son incapacité à conduire un projet,
• l’imprécision du cahier des charges,
• le manque de maturité du client,
• le manque de maîtrise des processus de l’ingénierie du logiciel du prestataire,
• les mauvaises estimations de la charge du projet.

De la même manière que pour les écueils techniques, nous pouvons classer ces cinq écueils dans les trois catégories du chapitre précédent : la maîtrise d’ouvrage, l’assistance à la maîtrise d’ouvrage et la maîtrise d’œuvre.

Figure 3 : Les cinq écueils fonctionnels des projets informatiques classés en trois catégories

2.1. Comment réduire les risques associés aux écueils fonctionnels ?

Le manque de maturité du client, l’écueil principal de la maîtrise d’ouvrage : La maturité du client dépend du client lui-même, toutefois rien n’empêche de lui faire des propositions qui lui permettront de réduire les risques associés à son besoin. Si cette réduction de risques peut se faire à un coût abordable, l’erreur est de ne pas la prendre en considération.
L’estimation des charges du projet, un ensemble risqué à maîtriser par l’AMOA : Voilà un domaine qui peut être amélioré par l’analyse, en particulier, en associant imprécision du cahier des charges et estimation de la charge du projet. En informatique, le plus tôt on commence, le plus tard on finit. C’est un adage qui consiste à dire qu’il vaut mieux prendre le temps de l’analyse plutôt que de se lancer tête baissée dans le codage. En suivant ce raisonnement, passer du temps à modéliser simplement le système souhaité permettrait d’avoir un bon aperçu de la qualité du cahier des charges et, dans le même temps, faciliterait l’estimation de la charge du projet afin de mettre la maîtrise d’œuvre dans les meilleures conditions.
La gestion du projet et de ses outils, le travail de la maîtrise d’œuvre : De la même manière que pour les écueils techniques, il est difficile de gérer par une analyse externe les risques associés à la maîtrise d’œuvre. Par définition, cette gestion des risques se fait lors du choix de l’équipe de réalisation qui devra fournir les preuves de sa capacité à réaliser un projet informatique.

2.2. Modéliser, un moyen simple pour réduire les risques fonctionnels d’un projet informatique

Suivant les écueils identifiés par Nathan Y. Hattab, nous pouvons identifier deux points clés à suivre pour réduire les risques fonctionnels d’un projet informatique, préciser le cahier des charges et mieux estimer la charge d’un projet. La modélisation de l’outil est le garant de la communication entre les parties prenantes de l’ensemble du projet. Elle doit savoir transformer le langage littéral du besoin du client en un langage modélisé compréhensible par les réalisateurs.
En bref, modéliser le système uniquement à partir des exigences permet de vérifier l’exhaustivité du cahier des charges, mais aussi les incohérences entre deux spécifications. La modélisation servira aussi à :

• préciser le cahier des charges en testant en amont les spécifications du système,
• mieux estimer la charge du projet en ayant très tôt dans la phase de développement une architecture testée et validée,
• réduire les risques liés à l’inexpérience du chef de projet en lui offrant des spécifications détaillées, un modèle et un ensemble de test sur lesquels s’appuyer pour gérer son projet,
• augmenter la maturité du client en lui montrant que son choix d’analyse amont a permis d’améliorer la qualité de l’ensemble de son projet.

Références:

1. http://software-testing-zone.blogspot.com/2008/12/why-are-bugsdefects-in-software.html
2. www.BasilDev.com, Automatiser le test fonctionnel de logiciels embarqués temps réel
3. AFAI : Association Française de l’Audit et du conseil Informatique
4. http://www.afai.asso.fr/index.php?m=76

Cet article est disponible en téléchargement à l'adresse : http://www.cogenit.fr/index.php/ressources/livres-bleus/smv-methode-agile-assurance-qualite

Plus de complexité, mais plus d’assurance qualité aussi !

L’accroissement de la complexité des systèmes d’information entraîne inexorablement une augmentation de la probabilité d’occurrence d’erreurs dans les projets de développement informatique.

De la même manière la criticité des systèmes d’information augmentant, les erreurs non corrigées ou corrigées en retard peuvent coûter très cher aux personnes qui mettent en service l’outil développé. Ce constat est connu depuis bien longtemps, et aujourd’hui, nous disposons d’outils d’assurance qualité pour vérifier l’état du système développé à chaque étape de son développement.

La méthode SMV est une méthode de gestion de l’assurance qualité qui un peu à la manière de la V & V, va s’intégrer avec des outils et moyens éprouvés, dans le cycle de développement logiciel pour réduire, en amont, les risques fonctionnels et techniques présents dans tous les développements informatiques.

1. Vers un accroissement de la complexité des projets informatiques

1.1. L’innovation, un passage obligé pour la croissance des entreprises

Les entreprises sont vouées à innover. L’entreprise qui n’innove pas créera de moins en moins de valeur ajoutée et perdra progressivement sa compétitivité. Par contre, l’entreprise qui innove saura garder sa compétitivité, mais rencontrera fatalement d’autres problèmes, en particulier sur la maintenance et l’amélioration de ses outils. Comme le dit Pierre Bonnet [1] : « Le système d’information suit une courbe de complexité qui est indexée sur celle de l’innovation et du changement ». L’entreprise doit savoir garder le contrôle de ses développements et de ses outils informatiques. L’accroissement de la complexité entraîne inéluctablement celui du coût de développement des projets informatiques, mais aussi celui du coût dû aux tests et à la validation des systèmes finaux.

1.2. La dérive, un risque proportionnel à la taille d’un projet informatique

D’après le NIST (National Institute of Standards and Technology), 80% du coût de développement d’un projet informatique est consacré à l’identification et à la correction des erreurs. De la même manière, d’après Djenana Campara, Directeur technique de Klocwork, une erreur qui coûte un dollar à corriger par son programmeur coûtera cent dollars à corriger après intégration dans le système complet. Ainsi, en 2002, les erreurs auraient coûté à l’économie américaine 60 milliards de dollars [2], soit 0,57% du PIB américain.

Attendre les phases de tests pour commencer à corriger les erreurs d’un projet devient dangereux, particulièrement avec l’augmentation de la taille et de la complexité des projets informatiques. Le Standish Group ne fait pas non plus une analyse très optimiste de la réussite des projets informatiques ; en effet, dans son rapport intitulé « Extreme Chaos », il classe les projets informatiques en trois catégories :

• les projets réussis,
• les projets contestables, ceux qui ont été livrés en retard, qui étaient hors budget ou qui comportaient moins de fonctionnalités que celles demandées initialement,
• les projets ratés, ceux qui n’ont jamais été finis ou bien ont été achevés mais jamais utilisés.

Depuis 1994, le Standish Group tient des statistiques sur ces trois catégories. Sur la période 1994-2009 et pour les États-Unis, les taux relevés sont ceux du tableau 1 et de la figure 1 :

Figure 1 : Taux de réussite des projets informatiques de 1994 à 2006 d’après le Standish Group

Tableau 1 : Évolution du taux de réussite (en %) des projets informatiques de 1994 à 2009 selon le Standish Group [3]

	1994	1996	1998	2000	2002	2004	2006	2009
Réussis	16	27	26	28	34	29	35	32
Contestables	53	33	46	49	51	53	46	44
Abandonnés	31	40	28	23	15	18	19	24

La stagnation du taux de réussite des projets informatiques depuis 2000 autour de 31,6% et l’augmentation du taux d’échec depuis 2002 prouve que les projets sont encore trop souvent ratés ou abandonnés.
Ces trois constats, l’augmentation de la complexité des projets informatiques, l’augmentation exponentielle du coût de correction d’une erreur en fonction du moment de sa découverte et l’incapacité des équipes à mener un projet à bien jusqu’au bout, sont la preuve de la présence d’écueils et de difficultés majeures dans la réalisation de projets informatiques. Une solution déjà appliquée est la mise en place de procédures d’assurance qualité dans la gestion des projets informatiques. Mais est-ce suffisant au vu du seul coût de la correction d’une erreur ?

2. Vers une amélioration de l’assurance qualité des systèmes informatiques.

En 2007, les dépenses en matière de qualité des SI des grandes entreprises françaises ont représenté 535 millions d’Euros. De plus, 53% des entreprises françaises estiment que l’assurance qualité de leurs systèmes d’information aura un impact de plus en plus important sur leur résultat. Ces deux constats conduisent à penser qu’on en est plus à se demander combien coûte la mise en œuvre d’un système d’information, mais plutôt combien coûtera à l’entre- prise un système défaillant [4]. L’assurance qualité est un processus indispensable à associer au développement de l’entreprise.

2.1. Une définition de l’assurance qualité

L’assurance qualité c’est : « L’ensemble des actions préétablies et systématiques nécessaires pour donner la confiance appropriée en ce qu’un produit ou service satisfera aux exigences données relatives à la qualité ». C’est un ensemble de procédés à mettre en place à chaque étape d’un projet informatique qui permet de connaître, à tout instant et par chaque partie prenante, l’état du projet en cours et ses différentes étapes précédentes. Les procédés de l’assurance qualité répondent entre autres aux problématiques de la V & V (Vérification & Validation). Mais les outils de l’assurance qualité sont ils suffisants pour répondre aux problèmes croissants des SI dus à l’augmentation de la complexité et de la taille des projets informatiques ?
Les outils de l’assurance qualité sont, par exemple, les revues, les audits, les lectures croisées, les revues par les pairs, les revues techniques, les inspections qualité ou d’autres, mais ces outils, même si ils permettent d’identifier les erreurs et omissions liées au développement du SI, ne vont pas permettre d’identifier les erreurs suffisamment tôt pour qu’elles ne représentent pas un budget quatre fois supérieur à celui du reste du projet.
Pour résoudre ces erreurs en amont, là où elles sont moins les moins onéreuses à corriger, il faut mettre en place des méthodes dès les premiers instants du projet afin de simplifier chaque étape importante de la conduite d’un projet de système d’information.

2.2. La vérification et validation, un procédé technologique de l’assurance qualité

Lorsqu’elles sont appliquées à chaque étape d’un projet, la vérification et la validation répondent aux problématiques de la qualité en se situant à l’intérieur des cycles de développement itératif des projets.

• La vérification : Elle a pour but de montrer que l’activité a été bien faite, qu’elle a été conforme à son plan de réalisation et qu’elle n’a pas introduit de défaut dans le résultat. Pour réaliser ces trois objectifs, il faut disposer, à chaque étape, de tests prêts à être exécutés d’abord sur un modèle puis sur le système réel.
• La validation : Elle a pour but de montrer que l’activité s’est conformée à son objectif. Elle assure que le résultat de l’activité conduite répond au besoin pour lequel elle a été menée. Pour réaliser cet objectif, il faut disposer de tests décrits directement à partir des exigences pour les exécuter à chaque étape du projet et vérifier que le produit est conforme aux exigences.

L’avantage de la V & V est qu’elle s’intègre dans le cycle de vie du développement logiciel. Contrairement aux autres procédés de l’assurance qualité, elle propose des solutions qui impactent techniquement le processus de réalisation.


Références:

1. http://www.bestpractices-si.fr/index.php? option=com_content&task=view&id=423&It emid=73
2. NIST, US Dept. of Commerce, The Economic Impacts of Inadequate Infrastructure for Software Testing, mai 2002.
3. http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html
4. http://www.itrmanager.com/articles/70332/qualite-systeme-information.html

Cet article est disponible en téléchargement à l'adresse : http://www.cogenit.fr/index.php/ressources/livres-bleus/smv-methode-agile-assurance-qualite