Editorial
Traduit par : Stéphane FAURE
Cet article est la traduction d'une étude, déjà ancienne,
publiée en novembre 1982 par :
- Walter J. Doherty, du Centre de Recherches Watson d'IBM,
- Ahrvind J. Thadhani, de la Division Produits d'IBM.
Mais les conclusions de cette étude sont assez générales pour être encore valables,
voire même d'une actualité aiguÙ dès lors que
l'apparence des applications semble prévaloir sur toutes les autres considérations fonctionnelles,
y compris les performances.
L'article original peut être consulté sur Internet à l'adresse :
http://www.s390.ibm.com/canada/evrrt
Quand un utilisateur peut se servir d'une application interactive sans qu'aucun des deux
n'ait à attendre l'autre :
- la productivité augmente,
- le coût du travail effectué sur le système informatique diminue sensiblement,
- l'utilisateur est davantage satisfait de son travail,
- et la qualité de ce dernier en est améliorée.
Peu de systèmes informatiques sont configurés pour de tels temps de
réponse interactifs (3).
Peu de responsables informatique connaissent l'impact et les enjeux de telles configurations.
En fait, une légende perdure qui voudrait qu'un temps de réponse
relativement élevé (c'est-à-dire mauvais), de l'ordre de deux secondes, soit
acceptable à cause du délai de réflexion nécessaire entre deux saisies. Mais les études
sur l'impact du temps de réponse indiquent que cette vieille théorie
n'est pas née de l'observation des faits qui montrent que la productivité augmente
proportionnellement plus vite que le temps de réponse ne diminue.
Une transaction (voir la Figure 1)
consiste en la saisie d'une commande sur un terminal
jusqu'à la réponse du système.
C'est l'unité de mesure fondamentale pour les applications interactives.
Elle peut être décomposée en deux intervalles de temps distincts :
- le temps de réponse de l'utilisateur,
- le temps de réponse du système.
Le temps de réponse de l'utilisateur est le délai entre la dernière réponse
du système et la saisie d'une nouvelle requête.
Le temps de réponse du système (symbolisé par TdRS dans la suite de cet
article) est le délai entre la saisie d'une requête et son exécution complète
par la machine.
Il se divise lui-même entre :
- temps de calcul (utilisation du processeur),
- temps de transfert (acheminement par le réseau des demandes et des résultats),
- et temps de présentation pour les applications Client/Serveur (délai de
calcul de l'affichage sur la station de travail).
Figure 1. Décomposition d'une transaction
Quand les systèmes interactifs commencèrent à se banaliser, des psychologues
défendirent l'opinion qu'une attente de deux secondes était le maximum que
devrait avoir à supporter un utilisateur.
Pour les développeurs et les architectes de systèmes,
ce délai devint un objectif à atteindre... et, à
cette époque, ce n'était pas chose aisée,
Le paradygme voulant que l'utilisateur
utilise le TdRS pour réfléchir en était conforté, sous-tendant le raisonnement
implicite que l'utilisateur réfléchit aussi vite qu'il le peut, indépendamment
de son environnement.
Les systèmes actuels, abondamment pourvus en MIPS, Gigs et Mbits, peuvent
fournir à des milliers d'utilisateurs des temps de réponse inférieurs aux
deux secondes "fatidiques", mais les mêmes enjeux persistent...
WJ Doherty (IBM) et RP Kelisky (IBM) écrivaient en 1979 :
"... chaque seconde
perdue à cause du TdRS entraîne une dégradation proportionnelle du
temps de réponse de l'utilisateur. Ce phénomène semble lié à une baisse
de l'attention de l'individu. Le modèle traditionnel d'une personne
réfléchissant après chaque réponse du système semble être invalide. Par
contre, les gens semblent agir comme s'ils avaient à l'esprit une séquence
d'actions, un buffer mental à court terme. L'augmentation du TdRS
semblerait casser les processus de pensée et pourrait obliger à repenser
la séquence d'actions restant à accomplir".
Dans un article inspiré des travaux de Doherty, AJ Thadhani (IBM) suggéra
que le nombre de transactions par heure, accomplies par un programmeur,
augmente sensiblement quand le temps de réponse diminue sous les deux
secondes et très fortement dès qu'il passe sous la seconde.
Thadhani remarqua (Figure 2)
que, soumis à un TdRS de 3 secondes un programmeur effectue
180 transactions à l'heure, alors que pour un TdRS diminué à 0,3 seconde
ce nombre passe à 371.
Autrement dit, une baisse du TdRS de 2,7 secondes
entraîne une économie de 10,3 secondes par transaction (voir la Figure 3).
Figure 2. Nombre de transactions suivant le TdRS
Figure 3. Nombre de transactions suivant le TdRS
Les bénéfices potentiels générés par des TdRS améliorés se déclinent
en économies substantielles,
une meilleure productivité personnelle,
un raccourcissement de la durée des projets,
et une meilleure qualité de travail.
Economiser quelques secondes d'une personne semble d'un intérêt minime,
mais ces secondes peuvent s'accumuler jusqu'à représenter rapidement
beaucoup d'argent... assez pour justifier la mise en place
d'un système plus performant.
Ces bénéfices cachés
ont été mis en lumière à l'Institut National de la Santé des USA (NIH).
En 1979 (hé, oui), le système du NIH était con\u pour supporter 300
utilisateurs (pour des activités de traitement de texte, programmation,
calcul et soumission de travaux à distance), dont 80% des transactions
étaient traitées en moins d'une demi-seconde.
Dans ces conditions, le système donnait
toute satisfaction ; mais l'accroissement de la charge mena\a le
maintient de ce niveau de service (Figure 4).
Le nombre d'utilisateurs simultanés
augmenta à près de 400, et les prédictions étaient de 500
dans les 18 mois suivants...
Avec 390 utilisateurs, le TdRS s'était
écroulé à 4 secondes et le temps nécessaire pour effectuer une tàche était
passé de 32 à 48 minutes (Figure 5).
Pour résoudre ce problème, le responsable
informatique du NIH proposa une mise à niveau du processeur.
Il avait observé que la détérioration de la disponibilité du
système entraînait,
chaque mois, un surplus de 22 500
heures de présence au terminal des
utilisateurs... pour effectuer le même travail,
Le surcoût total a été estimé à 900 000 dollars par mois, soit quinze fois
le prix d'achat d'un processeur fournissant des TdRS sous la seconde.
Figure 4. Nombre de sessions suivant le TdRS
Figure 5. Durée moyenne d'une tàche en fonction du TdRS
L'amélioration de la productivité individuelle est sûrement l'aspect le
plus sensible affecté par le TdRS.
Après la publication de l'étude de Thadhani, de nombreux projets au sein d'IBM
tentèrent de confirmer ces travaux en déterminant plus précisément
l'impact réel de TdRS inférieurs à la seconde.
Un de ces projets concernait la Division des Produits Systèmes.
Parmi d'autres produits interactifs, les laboratoires de cette division
fournissaient à leurs ingénieurs des assistants graphiques, afin de les aider
dans la conception des puces, cartes et autres composants électroniques.
Ces ingénieurs utilisaient ainsi des écrans graphiques spécialement
étudiés pour les taux de transaction élevés que demande la manipulation d'images.
Les études de cette division portèrent sur 75 sessions de travail de
15 ingénieurs effectuant diverses tàches de conception. L'échantillon de
données recueilli confirma l'existence de la courbe de Thadhani.
Mais les résultats (Figure 6)
mirent plus en évidence,
d'une part, que tous les utilisateurs
bénéficiaient de l'amélioration de TdRS,
d'autre part, qu'un ingénieur,
considéré comme moyennement expérimenté, travaillant avec un système
répondant en moins d'une seconde, était alors aussi productif qu'un ingénieur
expert travaillant avec un TdRS médiocre.
De même, un débutant rattrapait un ingénieur "standard", alors que la
productivité d'un expert était largement améliorée.
La Division des Produits Systèmes mit alors en place une série de tests
supplémentaires, pour déterminer l'impact du temps de réponse sur la durée d'une tàche.
Pour ces mesures, une tàche de conception de circuit intégré fut confiée à un groupe
d'ingénieurs. Il leur fut demandé de l'effectuer dans des conditions
pour lesquelles le TdRS était une variable primordiale. Les tests effectués,
on fit la corrélation entre la durée totale d'exécution du travail par
chaque ingénieur et le TdRS qui lui avait été affecté.
Figure 6. Nombre de transactions suivant le TdRS
Tous les résultats, provenant de quatre laboratoires, montraient des différences
significatives sur le temps passé à l'achèvement de cette tàche (voir la Figure 7).
Dans un laboratoire, la durée de conception diminua de 4,5 minutes pour chaque
dixième de seconde gagné sur le temps de réponse. Le temps de dessin d'une
carte passa de 92 à 66 minutes ; une amélioration de 20% obtenue en faisant
passer le TdRS de 6 à 0,25 secondes.
Dans un autre laboratoire, la durée da la tàche fut réduite de 3,6 minutes pour chaque
dixième de seconde gagné sur le TdRS, soit un temps de conception passant de 36 à 23,5 minutes.
De même, on constata une amélioration de 35% de la productivité en diminuant le TdRS de
0,6 à 0,25 seconde.
Figure 7. Durée totale d'une tàche en fonction du TdRS
L'encadrement de l'équipe de développement d'IBM Portsmouth (Angleterre)
pris connaissance des potentialités dévoilées par les travaux de Doherty et
Thadhani. Dans leurs propres tests, ils fournirent à chaque programmeur un
nouveau projet avec des TdRS sous la seconde, puis on mesura la
productivité de chaque programmeur et groupe de programmeurs.
Des techniques existaient déjà depuis plusieurs années quant à l'estimation de la durée
et des ressources nécessaires à l'accomplissement d'un projet. Ainsi,
toute déviation vis-à-vis des estimations pouvait être considérée comme
une variation significative et validait la comparaison entre groupes de
travail. Les estimations reposaient sur une unité appelée "point de
fonction", basée sur la taille et la complexité des développements.
La plus grande partie des terminaux étaient desservis par un réseau assez lent.
Pour le test, les terminaux furent raccordés à un réseau local à haut débit.
Ce changement faisait chuter le TdRS de 2,3 à 0,84 secondes.
Au vu du nombre de points de fonctions attendus pour le développement,
la durée de finalisation du projet avait été estimée à 30,8 mois/homme,
répartis sur 19 semaines... En fait, il fut achevé en 15 semaines
et ne demanda que 18,7 mois/homme, soit 39 % de moins que prévu,
La productivité de l'équipe testée fut aussi comparée avec celle qui
avait été mesurée sur un projet similaire, six mois plus tôt.
Avec un système répondant en moins d'une seconde, un programmeur écrivait 14,4
points de fonction par mois, soit 58% de plus que les 9,1 points de fonction
produits lors du précédent projet.
Gràce à une meilleure qualité de service que celle à laquelle
ils étaient accoutumés, les programmeurs explorèrent un plus grand nombre
de solutions possibles, qu'ils n'auraient normalement pas examinées, et
augmentèrent l'étendue de leur travail sur écran.
La qualité du programme fut comparée à la lumière des statistiques existantes.
Un taux de seulement trois problèmes par centaine de points de fonction fut constaté,
à comparer aux 6,9 problèmes par centaine de points de fonction du projet précédent.
Les études décrites jusqu'ici, dans cet article, concernent des scientifiques, des ingénieurs
et des programmeurs.
Un test portant sur des tàches administratives
indique que les mêmes bénéfices peuvent être attendus, si l'on augmente la
réactivité des applications d'accès à des bases de données.
Au laboratoire
IBM de Poughkeepsie, un groupe de personnes est chargé de prévoir le
nombre de pièces à produire, en s'appuyant sur une application exploitant
une base de données. Son travail comprend la maintenance de cette base,
le référencement des pièces et la saisie des durées de production... soit
une série de tàches similaires à celles de tout prévisonnaire de production
dans beaucoup d'entreprises.
Cinq de ces personnes firent l'object de mesures pendant une demi-journée, durant laquelle
elles bénéficièrent d'un TdRS sous la seconde alors qu'il était
habituellement supérieur ou égal à 5 secondes.
La productivité moyenne, qui était de 99 transactions à l'heure,
passa à 336 transactions à l'heure, soit une augmentation de 339%...,
L'amélioration du TdRS ne diminue pas la demande de puissance informatique ;
elle compresse la durée des tàches.
Il en ressort que : plus il y a de tàches pouvant
être effectuées durant une journée de travail, plus grande est
la charge de traitement (interactif et batch) à laquelle
l'ordinateur doit pouvoir faire face, si l'on veut
éviter de perdre les gains générés par un meilleur TdRS.
Un exemple permet d'illustrer cet effet.
Considérons que la saisie, la compilation
et la mise au point d'un programme nécessitent 100 millions d'instructions.
De plus, supposons que ces tàches sont effectuées par un programmeur en une
journée de travail divisée successivement en de l'activité sur terminal suivie par
des compilations durant deux heures.
Pour augmenter la productivité du
programmeur, il faut abaisser le TdRS interactif sous la seconde et
ramener le temps de compilation à une heure. Le programme pourra alors être
écrit en 4 heures, l'exécution du million d'instructions ne prenant plus
qu'une demi-journée.
Les données récoltées au NIH et au laboratoire de Portsmouth viennent à l'appui
cette conclusion.
Au NIH, chaque "session de travail" comprenait en
moyenne 90 transactions et deux soumissions de batch.
Ceci ne fut aucunement modifié par les conditions de l'étude, même si la durée de
la session était diminuée en rapport de la baisse du TdRS.
A Portsmouth, la "charge processeur" nécessaire pour écrire un point de fonction a été
relativement constante, mais la "consommation processeur" des programmeurs favorisés
augmenta parce qu'ils produisaient plus de lignes en une journée.
Ainsi, pour bénéficier complètement des améliorations de productivité
induites par la baisse du TdRS, le système informatique doit être
préparé à améliorer tous ses niveaux de service.
Ceci peut être accompli :
- en utilisant un système plus puissant,
- ou en distribuant une part des
travaux interactifs à des systèmes plus proches de l'utilisateur.
Pour mettre en évidence les bénéfices d'une chute du TdRS, nous pouvons
les illustrer par un exemple basé sur les résultats publiés par Thadhani.
L'utilisateur moyen effectue 180 transactions à l'heure quand il est
soumis à des temps de réponse de 3 secondes.
Pour simplifier, on supposera qu'une tàche nécessite 180 transactions ; huit de ces tàches
occupent donc une journée de travail. On suppose, de plus, que l'heure de travail de cet
employé revient à 200 Francs (NDLR - Valeur francisée et actualisée par rapport au document
original...).
En faisant varier le TdRS à partir des données recueillies par Thadani, on arrive au tableau
suivant :
Table 16. Gains apportés par la diminution du TdRS.
TdRS
en secondes
| Transactions
par heure
| Tàches
par minute
| Minutes en moins par tàche
| Minutes en moins par jour
|
| 3.0
| 180
| 60.0
| -
| -
|
| 2.0
| 208
| 51.9
| 8.1
| 64.8
|
| 1.0
| 252
| 42.9
| 17.1
| 136.8
|
| 0.6
| 279
| 37.7
| 22.3
| 178.4
|
| 0.3
| 371
| 29.1
| 30.9
| 247.2
|
A mesure que le TdRS s'améliore, le temps nécessaire pour effectuer une tàche
passe de 60 à 29,1 minutes ; le temps économisé dans une journée atteint donc
247,2 minutes, ce qui, pour un mois de 21 jours, équivaut à 17 300 Francs.
Le nombre d'utilisateurs simultanés sur le système varie d'une
entreprise à l'autre, tout comme les potentialités d'améliorations.
Toutefois, dans tous les cas de l'exemple étudié ici, l'intérêt financier
n'est pas négligeable, allant de 860 KF/mois (10 MF/an) pour un système
desservant 50 personnes à 5,2 MF/mois (62 MF/an) pour 300 utilisateurs
simultanés.
Des temps de réponse rapides, idéalement inférieurs à la seconde et dans un
environnement informatique adéquat, offrent des améliorations
significatives de la productivité de ceux qui en bénéficient.
IBM et d'autres
entreprises ont pu le vérifier et ont démontré que cela diminuait le
coût des tàches effectuées sur informatique.
Bien sûr, chaque organisation peut mettre en place ses propres procédures de mesure,
mais, comme cet article l'a illustré, les enjeux peuvent être importants.
|
Cet article montre bien que la productivité n'est pas uniquement liée à
l'interface utilisateur.
De nos jours, les projets de revamping peuvent
oublier l'aspect primordial d'une application qui est son temps de réponse.
Temps de réponse qui dépend, non seulement du système d'hébergement et du
réseau de communications, mais aussi de l'architecture applicative ainsi que
de l'ergonomie de l'interface utilisateur (ce qui prenait 2 écrans en application classique se
transforme en 10 écrans en HTML, ).
La finalité d'une application n'est pas seulement d'ordre esthétique. Elle
s'inscrit généralement dans un contexte économique.
.
|
Footnotes:
(3)
Cette assertion de 1982 n'est sans doute plus valable aujourd'hui... quoique,
[ Top of Page | Previous Page | Next Page | Table of Contents ]