Article de référence de Winston Royce

Traduit par Fabrice Aimetti le 5 avril 2010

GESTION DU DÉVELOPPEMENT DE GROS SYSTEMES LOGICIELS

Dr. Winston W. Royce

INTRODUCTION

Je vais donner ici mon opinion sur la gestion des gros développements logiciels. J'ai occupé divers postes au cours des neuf dernières années, principalement autour du développement de modules logiciels pour la planification des missions des engins spatiaux, la conduite et l'analyse après vol. J'ai connu différents degrés de succès concernant le fait d'obtenir un logiciel opérationnel en respectant les délais et les coûts. J'ai été fortement influencé par mes expériences et je vais donc vous présenter ici quelques-unes de mes conclusions personnelles.

DÉVELOPPEMENT DE PROGRAMMES INFORMATIQUES

Il y a deux étapes essentielles communes à tous les développements de programmes sur ordinateur, indépendamment de leur taille ou de leur complexité. Il y a d'abord une étape d'analyse, suivie par une seconde étape de codage comme le montre la Figure 1. Ce principe de mise en oeuvre simplissime représente en fait ce qui est exclusivement nécessaire si l'effort est suffisamment petit et si le produit final doit être utilisé par ceux qui l'ont élaboré – comme c'est généralement le cas pour les programmes informatiques à usage interne. C'est aussi le genre d'effort de développement pour lesquels la plupart des clients sont heureux de payer, puisque les deux étapes impliquent véritablement un travail créatif qui contribue directement à l'utilité du produit final. Cependant, la mise en oeuvre de systèmes logiciels plus gros basée uniquement sur ces étapes est vouée à l'échec. De nombreuses étapes de développement supplémentaires sont nécessaires, aucune ne contribuant plus directement à l'obtention du produit final que l'analyse et le codage, et toutes faisant grimper le coût des développements. Le client préfèrerait généralement ne pas payer pour ces étapes supplémentaires, et les développeurs préfèreraient ne pas les mettre en œuvre. Le rôle premier du management est de vendre ces concepts aux deux groupes et ensuite d'en garantir le respect par les développeurs.

Figure 1 – Etapes d'implémentation pour produire un petit programme à usage interne

Une approche plus conséquente pour le développement de logiciels est illustrée par la Figure 2. Les étapes d'analyse et de codage sont encore présentes, mais elles sont précédées par deux niveaux différents d'analyse des besoins, sont séparées par une étape de conception et suivie d'une étape de test. Ces étapes supplémentaires sont traitées séparément de l'analyse et du codage car elles sont exécutées d'une manière très différente. Elles doivent être planifiées et réparties différemment pour une utilisation optimale des ressources.

La figure 3 illustre la relation itérative entre les phases successives de développement. L'ordre des étapes est basé sur le principe suivant : on progresse à chaque étape, la conception est de plus en plus détaillée, on peut itérer avec l'étape précédente et suivante, mais rarement avec des étapes plus éloignées. Le mérite de tout cela est qu'au fur et à mesure de la conception, le processus de gestion des changements reste dans des

Copyright © 1970 by The Institute of Electrical and Electronics Engineers 1/13


limites gérables. À tout moment de l'avancement dans le processus de conception qui succède à l'analyse des besoins, il existe une base ferme sur laquelle s'appuyer voire revenir en cas de difficultés imprévues. Nous disposons donc d'une stratégie de position de repli efficace qui tend à maximiser et préserver le travail fourni en amont.

Figure 2 – Etapes d'implémentation pour produire un gros programme à livrer à un client.

Je crois à ce concept, mais la mise en oeuvre décrite ci-dessus est risquée et peut entraîner l'échec. Le problème est illustré à la Figure 4. La phase de test qui intervient à la fin du cycle de développement constitue la premier événement pour lequel le temps machine, le stockage, les entrées-sorties, etc., sont expérimentées et plus seulement analysées. Ces sujets ne sont pas précisément analysables. Ce ne sont pas des solutions à des équations aux dérivées partielles de la physique mathématique par exemple. Pourtant, si ces sujets ne parviennent pas à satisfaire les différentes contraintes externes, alors cela conduira invariablement à une reconception majeure. Un simple patch ou correction d'un code isolé ne réglera pas ce genre de difficultés. Les changements de conception nécessaires sont susceptibles d'être si perturbateurs que les exigences logicielles, sur lequelles la conception est fondée et qui justifie tout le reste, seront transgressées. Soit les exigences doivent être modifiées, soit un changement significatif dans la conception est nécessaire. En effet le processus de développement reprend au début et l'on peut s'attendre à 100% de dépassement en délai et/ou coût.

On peut remarquer que les phases d'analyse et de codage ont été sautées dans la Figure 4. Bien entendu, on ne peut pas produire un logiciel sans ces étapes, mais en général ces phases sont gérées avec une relative facilité et ont peu d'impact sur les exigences, la conception et les tests. D'expérience, il y a des départements entiers consacrés à l'analyse de la mécanique céleste, la détermination du comportement des engins spatiaux, l'optimisation mathématique de la charge utile et ainsi de suite, mais lorsque ces départements ont terminé leur difficile et complexe travail, le programme résultant n'implique que quelques lignes de code arithmétique. Si lors de ce difficile et complexe travail, les analystes ont fait une erreur, la correction prend toujours la forme d'un changement mineur dans le code sans perturbations sur les autres développements.



Je pense que l'approche illustrée est fondamentalement viable. La suite de cette présentation comprend cinq caractéristiques supplémentaires qui doivent être ajoutées à cette approche basique pour éliminer la plupart des risques de développement.

Figure 3 – Heureusement, l'interaction itérative entre les différentes phases se limite aux étapes connexes.



Figure 4 – Malheureusement pour le process illustré, les itérations de conception ne se limite jamais aux étapes connexes.



ÉTAPE 1 : LA CONCEPTION DU PROGRAMME AVANT TOUT

La première étape vers une solution est illustrée dans la Figure 5. Une phase préliminaire de conception du programme a été insérée entre la phase d'expression des besoins logiciels et la phase d'analyse. Cette démarche peut être critiquée car le concepteur du programme est forcé de concevoir à partir des exigences sans aucune analyse pré-existante. Par conséquent, sa conception préliminaire peut être mauvaise, ce qui n'aurait pas été forcément le cas s'il avait attendu que l'analyse soit complète. Cette critique est compréhensible mais pas pertinente. Par cette démarche, le concepteur du programme garantit que le logiciel n'échouera pas en raison de problèmes de stockage, de temps machine ou de flux de données. Au fil de l'analyse, le concepteur du programme doit imposer à l'analyste ces contraintes opérationnelles de telle manière que ce dernier soit sensibilisé aux conséquences. Quand l'analyste exige à juste titre davantage de ressources pour mettre en œuvre ses équations, celles-ci doivent être retirées des ressources de ses collègues analystes. De cette façon, tous les analystes et tous les concepteurs de programme contribueront à un processus de conception sérieux, ce qui aboutira à la bonne répartition des temps machine et des ressources de stockage. Si le total des ressources à allouer est insuffisant ou si la conception préliminaire opérationnelle est mauvaise, le problème sera détecté beaucoup plus tôt et l'on pourra itérer une nouvelle fois sur les étapes d'exigences et de conception préliminaire avant que ne démarre la conception finale, le codage et les tests.

Comment cette démarche est-elle mise en œuvre ? Les étapes suivantes sont nécessaires :

1) Lancez le processus de conception avec des concepteurs, et non des analystes ou des programmeurs.

2) Concevez, définissez et préparez les différents traitements des données, même au risque de se tromper. Concevez la base de données, définissez les traitements sur la base de données, allouez le temps machine, définissez les interfaces avec le système d'exploitation, décrivez le traitement des entrées/sorties et définissez les procédures d'exploitation préliminaires.

3) Écrivez un document de synthèse qui soit compréhensible, instructif et à jour. Chaque intervenant doit avoir une compréhension élémentaire du système. Au moins une personne doit avoir une compréhension profonde du système, qui provient en partie d'avoir eu à écrire le document de synthèse.



Figure 5 – Etape 1 : Garantir qu'une conception préliminaire du programme soit effectuée avant le début de l'analyse.



ÉTAPE 2 : DOCUMENTEZ LA CONCEPTION

A ce stade, il convient de soulever la question "quelle quantité de documentation fournir ?" Mon opinion est "beaucoup" ; en tout cas certainement plus que ce que serait prêt à faire par eux-mêmes la plupart des programmeurs, analystes ou concepteurs de programmes. La première règle de gestion du développement logiciel est la documentation systématique des exigences.

Parfois, je suis appelé à examiner les progrès des efforts déployés sur la conception d'autres logiciels. Mon premier réflexe est d'enquêter sur l'état de la documentation. Si la documentation fait gravement défaut, ma première recommandation est simple : remplacer le chef de projet, cesser toutes les activités non liées à la documentation, documenter jusqu'à un niveau acceptable. La gestion des logiciels est tout simplement impossible sans un très haut degré de documentation. Je me permet de vous fournir les estimations suivantes à titre de comparaison. Pour fournir un périphérique matériel de 5 millions de dollar, je m'attends à ce qu'une spécification de 30 pages soit rédigée pour offrir des détails adéquats pour contrôler la fourniture. Afin de fournir un logiciel de 5 millions de dollars, j'estime que l'on doit rédiger une spécification de 1500 pages afin de parvenir à un niveau de contrôle comparable.

Pourquoi autant documenter ?

1) Chaque concepteur doit communiquer avec les concepteurs d'interface, avec son management et éventuellement avec le client. Un enregistrement oral est trop immatériel pour permettre une décision de management ou d'interface. Une description écrite acceptable oblige le concepteur à prendre une position sans équivoque et fournit des preuves tangibles de complétude. Elle empêche le concepteur de se cacher derrière le syndrome du "J'ai terminé à 90%" mois après mois.

2) Pendant la phase de développement logiciel, la documentation est la spécification et est la conception. Jusqu'à ce que le codage commence, ces trois termes (documentation, spécification, conception) désigne la même chose. Si la documentation est mauvaise, la conception est mauvaise. Si la documentation n'existe pas encore alors il n'y a pas encore de conception, seulement des gens qui pensent et qui parlent de conception, ce qui a bien sûr une certaine valeur mais pas beaucoup.

3) La valeur monétaire réelle d'une bonne documentation se mesure en aval du processus de développement au cours de la phase de test et continue à travers la reconception. La valeur de la documentation peut être décrite à l'aide de trois situations concrètes, tangibles auquel chaque program manager fait face :

a) Au cours de la phase de tests, avec une bonne documentation, le manager peut se concentrer sur les erreurs du programme. Sans une bonne documentation, toute erreur, petite ou grande, doit être analysée par un seul homme, qui a probablement commis l'erreur, puisqu'il est le seul homme qui comprenne le domaine d'application du programme.

b) Au cours de la phase opérationnelle, avec une bonne documentation, le manager peut utiliser du personnel exploitant pour faire fonctionner le programme et faire un travail de meilleure qualité et moins cher. Sans une bonne documentation, le logiciel va être exploité par ceux qui l'ont construit. En général, ces personnes sont relativement désintéressés par l'exploitation et ne vont pas réaliser un travail aussi efficace que le personnel exploitant. Il convient de relever à cet égard que, dans une situation d'exploitation, s'il y a un problème, le logiciel est toujours blâmé en premier. Afin soit d'innocenter le logiciel soit de trouver le responsable, la documentation du logiciel doit être claire.

c) À la suite de la première mise en exploitation, lorsque des améliorations du système sont prévues, une bonne documentation permet une reconception, une mise à jour et une



modernisation efficaces. Si la documentation n'existe pas, l'ensemble du cadre d'exploitation existant du logiciel doit être généralement jeté, même pour des changements relativement modestes.

La figure 6 montre un plan de documentation qui renvoie aux étapes précédemment montrées. On notera que six documents sont produits, et au moment de la livraison du produit final, les Documents n°1, n°3, n°4, n°5 et n ° 6 sont mis à jour.

Figure 6 – Etape 2 : Garantir que la documentation est à jour et complète – au minimum 6 documents différents sont nécessaires.



ÉTAPE 3 : FAITES LE DEUX FOIS

Après la documentation, le deuxième critère le plus important pour la réussite traite du caractère innovant du produit. Si le programme en question est développé pour la première fois, arrangez-vous pour que la version finalement livrée au client pour un déploiement opérationnel soit en fait la deuxième si tant est que la conception et la mise en exploitation soient critiques. La Figure 7 illustre comment cela pourrait être réalisée au moyen d'une simulation. Notez que c'est tout simplement l'ensemble du processus en miniature, sur une échelle de temps relativement petite par rapport à l'effort global. La nature de cet effort peut varier considérablement en fonction principalement des délais et de la criticité des problèmes à modéliser. Si l'effort va durer 30 mois, alors le développement d'un pilote pourrait être prévue sur 10 mois. Avec ce calendrier, des vérifications formelles, des procédures de documentation, etc., peuvent être utilisées. Si, toutefois, l'effort global était réduit à 12 mois, alors le pilote pourrait peut-être réduit à trois mois, afin de disposer d'un retour d'expérience suffisant suite au développement des fonctionnalités principales. Dans ce cas, le personnel impliqué doit faire preuve d'un grand niveau de multi-compétence. Ils doivent être très expérimenté en analyse, codage et conception de programme. Ils doivent rapidement détecter les points durs dans la conception, modéliser les alternatives, écarter les aspects simples de la conception qui ne sont pas dignes d'être étudiés à ce stade, et enfin obtenir un programme sans erreur. Dans les deux cas, ce qui est important c'est qu'avec une simulation, les questions de temps machine, stockage, etc. qui restent par ailleurs des questions de jugement, peuvent maintenant être étudiées avec précision. Sans cette simulation, le chef de projet est soumis au jugement humain. Avec la simulation, il peut au moins effectuer des tests expérimentaux sur certaines hypothèses clés et évaluer ce qui reste du domaine du jugement humain qui dans le domaine de la conception de programmes informatiques (comme l'estimation du poids brut au décollage, des coûts, ou des charges) est systématiquement trop optimiste.

Figure 7 – Etape 3 : Essayez de réaliser le travail deux fois – le premier résultat fournit une simulation au plus tôt du produit final.



ÉTAPE 4 : PLANIFIEZ, CONTROLEZ ET SUPERVISEZ LES TESTS

Sans le moindre doute, le plus grand utilisateur de ressources du projet est la phase de test, qu'il s'agisse de main-d'œuvre, de temps machine ou de management. C'est la phase qui présente le plus grand risque en termes financier et calendaire. Elle se produit en fin de calendrier au moment où les possibilités de retour arrière sont le moins envisageables, voire pas du tout.

Les trois recommandations précédentes :• concevoir le programme avant de commencer l'analyse et le codage,• le documenter complètement,• et élaborer un pilote,

visent toutes à découvrir et résoudre les problèmes avant d'entrer dans la phase de test. Cependant, même après avoir fait cela, il y a toujours une phase de test et il y a encore des choses importantes à faire. La Figure 8 liste certains points supplémentaires à tester. Lors de la planification des tests, je vous suggère de prendre en considération les points suivants :

1) De nombreuses parties du processus de test seront mieux traitées par des spécialistes des test qui n'ont pas nécessairement contribuer à la conception originale. Si on fait valoir que seul le concepteur peut effectuer un test en profondeur, car lui seul comprend le périmètre à tester, c'est le signe que la documentation produite est insuffisante. Grâce à une bonne documentation, il est possible d'utiliser des spécialistes en matière d'assurance qualité logicielle qui, à mon avis, feront un meilleur travail de tests que le concepteur.

2) La plupart des erreurs sont si évidentes qu'elles peuvent être facilement repérées par une inspection visuelle. Chaque bout d'analyse et chaque bout de code peut être soumis à la simple analyse visuelle d'une autre personne qui n'a pas participé à l'analyse d'origine, ni au codage mais qui détectera facilement des choses comme un signe moins qui manque, un coefficient deux qui manque, des sauts à de fausses adresses, etc, et qui sont de la revue d'analyse et de code. N'utilisez pas l'ordinateur pour détecter ce genre de chose - c'est trop cher.

3) Testez tous les chemins logiques du programme au moins une fois avec une sorte de contrôleur numérique. Si j'étais un client, je n'accepterai pas la livraison tant que cette procédure n'a pas été réalisée et validée. Cette étape lèvera la majorité des erreurs de codage. Bien que cette procédure de test semble simple, pour un gros et complexe programme, c'est relativement difficile de couvrir tous les chemins logiques avec des valeurs valides en entrée. En fait, il y en a même qui diront que c'est presque impossible. Malgré tout, je persiste dans ma recommandation que tous les chemins logiques doivent être soumis à, au minimum, un contrôle.

4) Une fois que les erreurs simples (qui représentent la majorité et qui masquent les grosses erreurs) ont été supprimées, il est temps de se tourner vers la vérification finale du logiciel. Au moment approprié au cours du développement et dans les mains de la bonne personne, l'ordinateur lui-même est le meilleur dispositif pour mener la vérification finale. Les décisions clés sont les suivantes: quel est le bon moment et quelle est la personne apte à réaliser la vérification finale ?

ÉTAPE 5 : IMPLIQUER LE CLIENT

Pour certaines raisons, ce que va réaliser un logiciel est sujet à un grande interprétation, même après accord préalable. Il est important d'impliquer le client de manière formelle de telle façon qu'il se soit engagé préalablement sur certains points avant la livraison finale. Donner totale liberté au contractant entre la définition des besoins et l'exploitation favorise l'apparition des problèmes. La Figure 9 indique trois points suivant la définition des besoins où l'intuition, le jugement et l'engagement du client peuvent soutenir l'effort de développement.



RÉSUMÉ

La Figure 10 résume les cinq étapes que je pense nécessaire pour transformer un processus de développement à risque en un processus qui fournira le produit désiré. Je tiens à souligner que chaque point proposé implique des coûts supplémentaires. Si le processus relativement simple, sans les cinq points de complexité décrits ici, fonctionne avec succès, alors bien sûr l'argent n'est pas bien dépensé. Toutefois, d'après mon expérience, la méthode simple n'a jamais marché sur de gros projets de développement logiciel et au final les coûts excédentaires dépassent de très loin ceux nécessaires pour financer le processus en cinq étapes.

Figure 8 – Etape 4 : Planifiez, contrôlez et supervisez les tests.



Figure 9 – Etape 5 : Impliquez le client – cette implication doit-être formelle, en profondeur et continue.



Figure 10 – Résumé.


Engineering

Article de référence de Winston Royce