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é.

Article de référence de Winston Royce

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Article de référence de Winston Royce

Ähnlich wie Article de référence de Winston Royce (20)

Mehr von Fabrice Aimetti

Mehr von Fabrice Aimetti (20)

Article de référence de Winston Royce