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