De l’anarchie à l’optimisation

Original: http://www.stevemcconnell.com/articles/art02.htm

Développement de logiciels, juillet 1993

Sur les projets de petits logiciels, qualité des programmes dépend largement des compétences d’un ou deux programmeurs qui construisent le programme. Sur moyenne et grande envergure, la qualité est également fortement affectée par le processus de développement dans lequel les compétences des programmeurs travaillent. Cet article explore une approche à l’amélioration de la qualité du logiciel et la productivité grâce à des améliorations dans le processus de développement.
Le modèle de maturité de processus SEI
Le Software Engineering Institute (SEI) a été fondée par le ministère de la défense d’étudier le développement de logiciels et de diffuser des informations sur les pratiques de développement efficace. Partie de la Charte du SEI est d’essayer de nouvelles techniques et voir comment ils s’intensifier entre les paramètres de recherche en projets concrets. Quand une technique fonctionne, le SEI il décrit afin que pratiquent les programmeurs peut mettre à profit.
Le SEI a étudié est le processus de développement. Il a identifié cinq niveaux de maturité de processus de logiciel, dont chacun représente une augmentation de puissante en favorisant le développement par le niveau en dessous. Voici une description informelle des niveaux :
Niveau 1 anarchie. Programmeurs font ce qu’ils pensent individuellement est meilleur et espèrent que leur travail se réuniront à la fin du projet. Coût, calendrier et la qualité sont généralement imprévisible et incontrôlable. Une organisation de niveau 1 fonctionne sans planification formelle ou de pratiques de programmation. Projets sont en proie à de mauvais changement de contrôle, et les outils ne sont pas intégrés dans le processus. Haute direction ne comprend pas des questions ou des problèmes de programmation. Le terme officiel du SEI pour ce niveau est « initial ».
Folklore de niveau 2. A ce niveau, programmeurs dans une organisation assez connaissent le développement de certains types de systèmes, qu’ils croient qu’ils ont mis au point un processus de développement de logiciel efficace. Ils ont appris à dresser des plans, ils rencontrent leurs estimations et leur mythologie entreprise incarne officieusement leur sagesse accumulée. La force d’une organisation à ce niveau dépend de son expérience répétée avec des projets similaires, et il a tendance à s’essouffler face aux nouveaux outils et de méthodes, de nouveaux types de logiciels ou de grands changements organisationnels. Savoir organisationnel à ce niveau est contenue uniquement dans l’esprit des programmeurs individuels, et quand un programmeur quitte une organisation, fait la connaissance. Le terme officiel du SEI pour ce niveau est « reproductible ».
Niveau 3 normes. A ce niveau, la mythologie corporative est inscrit dans un ensemble de normes. Bien que le processus est répétable à ce stade et ne dépend plus des individus pour sa conservation, personne n’a recueilli des données pour mesurer son efficacité ou de le comparer avec d’autres processus. Le fait que le processus a été formalisé ne signifie pas nécessairement que le processus fonctionne, donc les programmeurs débattent de la valeur des logiciels-processus et processus de mesure en général, et qu’ils argumenter sur les processus et traitent des mesures à utiliser. Le terme officiel du SEI pour ce niveau est « défini ».
Mesure de niveau 4. Au niveau de la mesure, le processus standard est mesuré et dures données sont collectées afin d’évaluer l’efficacité du processus. La collecte de données dures élimine les arguments qui caractérisent le niveau 3–les données dures peuvent être utilisées pour juger du bien-fondé de procédés concurrents objectivement. Le terme officiel du SEI pour le niveau 4 est « géré ».
Optimisation du niveau 5. Dans les bas niveaux de maturité des processus, une organisation met l’accent sur la répétabilité et de mesures principalement afin d’améliorer la qualité des produits. Il peut mesurer le nombre de défauts par mille lignes de code afin qu’il pouvait savoir à quel point son code a été. Niveau optimisation, une organisation se concentre sur la répétabilité et de la mesure afin qu’il peut améliorer son processus de développement. Il mesurerait le nombre de défauts par mille lignes de code afin qu’il pourrait évaluer comment le processus fonctionne. Il a la capacité de varier son processus, mesurer les résultats de la variation et établir la variation comme un nouveau standard lorsque la variation se traduit par une amélioration des processus. Il a en place des outils qui collectent automatiquement les données, qu’il faut analyser le processus et l’améliorer. Le terme officiel du SEI pour ce niveau est « optimisation ».
Avantages d’améliorer votre maturité de processus
Votre organisation peut profiter des avantages substantiels, tangibles en améliorant ses processus et de passer du niveau 1 à un niveau plus élevé. Lockheed a entrepris un programme pour améliorer son processus de développement de logiciel, il y a plusieurs années, et il a maintenant atteint niveau 3. Voici ses résultats d’un projet de 500 000 ligne typique :
Niveau SEI
Coût de développement ($million)
Développement du temps (mois)
Qualité des produits (défauts / KLOC)
Productivité (LOC/heure)
Productivité ($/ LOC)

1

33

40

9

1

66

2

15

32

3

3

30

3

7

25

1

5

14

4*

3

19

0.3

8

6

5*

1

16

0.1

12

2

* Résultats projetés
Source: « une stratégie pour Software Process Improvement » (Pietrasanta, 1991 a).
Dans les cinq ans nécessaires pour passer du niveau 1 au niveau 3, Lockheed a amélioré sa productivité d’un facteur 5 et a réduit son taux de défectuosité par un facteur de près de 10. Au niveau 5, il aura amélioré sa productivité d’un facteur de 12 et a réduit son taux de défectuosité par un facteur de près de 100. Les chiffres de Lockheed pour niveaux 4 et 5 sont des projections, mais ils sont comparables aux chiffres réels déclarés pour un groupe d’IBM qui est responsable pour le code navette spatiale en vol et qui a été évalué au niveau 5 (Pietrasanta, 1991 b). Résultats semblables à de Lockheed ont été signalés par Motorola, Xerox et d’autres sociétés (Myers, 1992). Hughes Aircraft signale qu’une seule fois, investissement de 400 000 $ dans l’amélioration des processus pour un effectif de 500 personnes est maintenant payante au tarif de $ 2 millions par an (Humphrey, Snyder et Willis 1991).
En plus des améliorations de la qualité et la productivité, certains fournisseurs de logiciels ont amélioré leurs processus afin de démontrer leur engagement envers la qualité. Gouvernement et acheteurs privés commencent à demander pour cote de maturité SEI du fournisseur dans le cadre de leurs processus d’achat du produit. Parce que les niveaux de maturité sont corrélés avec les niveaux de qualité du produit et parce que la qualité des logiciels packagés varie grandement, sociétés peuvent bientôt refuser d’acheter des produits auprès de fournisseurs qui n’ont pas atteint un niveau élevé de maturité.
Enquête de maturité de processus existants des organisations
Compte tenu des avantages assez importantes de le faire, vous attendez la plupart des organisations de s’efforcer de niveau 5. Dans le discours à la Conférence de qualité de logiciel du Nord-Ouest du Pacifique à la fin de 1991, Alfred Pietrasanta a rapporté les chiffres suivants pour le nombre d’organisations à chaque niveau de maturité :

Niveau SEI

Organisations à ce niveau

1

85%

2

14%

3-5

1%

Source: « mise en œuvre de génie logiciel dans IBM » (Pietrasanta, 1991 b).
À partir de la fin de 1991, qu’environ un pour cent de toutes les organisations accomplissaient au mieux que le niveau 2. Une des raisons sont que la qualité et les processus de productivité sont des questions moins techniques qu’ils sont ceux d’organisation. Pour obtenir des avantages majeurs, l’ensemble de l’organisation doit comprendre l’importance du processus de développement et consacrée à améliorer cette dernière.
Si vous voulez améliorer la maturité des processus de votre entreprise, vous devez envisager trois facteurs qui distinguent les organisations de niveau inférieur de ceux aux niveaux supérieurs. Les trois sections suivantes esquisser trois de ces facteurs : répétabilité (méthodologie), mesurabilité (métrique) et la rétroaction (optimisation).
Méthodologie
Normalisant formellement le processus de développement est la clé à l’amélioration du niveau 2 au niveau 3. Vous pouvez normaliser dans deux manières différentes. La plupart des organisations codifient le processus qui est déjà utilisé par leurs meilleurs programmeurs. Autres organisations s’efforcent d’imposer une méthodologie de l’emporte-pièce comme “des méthodes structurées” ou “méthodes object-oriented”, mais des rapports anecdotiques suggèrent qu’imposer un processus entièrement nouvel est moins efficace que commençant par un.
Les programmeurs qui ne sont pas familiers avec les avantages d’utiliser une méthodologie formelle parfois y résister. Une méthodologie limite l’éventail complet de la créativité d’un programmeur et souvent ajoute frais généraux pour le processus de développement. Si la seule chose un programmeur sait est qu’une méthodologie est en même temps limiter et inefficace, personne ne devrait être surpris que le programmeur se plaint à ce sujet. Mais dans un contexte plus large, la rigidité et la surcharge due à un processus défini ont valeur. Programmeurs devraient être amenés à comprendre que la valeur afin qu’ils peuvent envisager son bénéfice avant ils se plaignent de ses restrictions.
Le processus décisionnel répétable aussi jette les bases pour la mesure qui est nécessaire aux niveaux supérieurs. Lorsque vous mesurez des processus avec des écarts importants, vous ne savez jamais quels facteurs sont responsables pour les différences dans la qualité et la productivité. Lorsqu’un processus reproductible par l’utilisation d’une méthode standard, vous pouvez être raisonnablement sûr que des différences mesurées proviennent le facteur que vous varié, pas d’autres facteurs qui ne sont pas sous votre contrôle.
Métriques
Officiellement votre processus de mesure est la clé pour passer de niveau 3 au niveau 4. Le terme « métrique » s’entend de toute mesure concernant le développement de logiciels. Nombre de lignes de code, des défauts, les défauts par mille lignes de code, nombre de variables globales, heures pour terminer un projet–Voici toute la métrique appelée comme tous les autres aspects mesurables du processus logiciel.
Voici trois raisons solides pour mesurer votre processus :
1. Vous pouvez mesurer une partie quelconque du processus logiciel d’une manière qui est supérieure à elle mesure ne pas du tout. La mesure n’est peut-être pas parfaitement précise ; Il peut être difficile à faire ; Il peut avoir besoin d’être affiné au fil du temps ; mais toute mesure vous donne une poignée sur votre processus que vous n’avez pas sans elle.
Pour les données à utiliser dans un scientifique expérimenter, il doit être quantifié. Pouvez-vous imaginer un scientifique de la FDA recommande une interdiction sur un nouveau produit alimentaire parce qu’un groupe de rats blancs « a juste semblé plus malade après avoir mangé il? » Non, vous insistez pour qu’ils fournissent une raison comme « Rats ayant mangeaient la nourriture nouvelle étaient malades 3,7 fois plus que rat qui n’a pas. » Afin d’évaluer les méthodes de développement logiciel, vous devez également mesurer eux. Déclarations comme « cette nouvelle méthode semble plus productive » ne sont pas assez bonnes.
2. Ce qui est mesuré, s’accomplit. Lorsque vous mesurez un aspect de votre processus de développement, vous êtes implicitement dire aux gens qu’ils doivent travailler pour améliorer cet aspect, et les gens répondront à des objectifs que vous définissez pour eux.
3. D‘argumenter contre la métrique est de prétendre qu’il est préférable de ne pas savoir ce qui se passe réellement sur votre projet. Lorsque vous mesurez un aspect d’un projet, vous savez quelque chose que vous ne saviez pas avant. Vous pouvez voir si l’aspect vous mesurez devient plus gros ou plus petits ou reste la même. La mesure vous donne une fenêtre dans cet aspect de votre projet. La fenêtre peut être petit et couvert jusqu’à ce que vous pouvez affiner vos mesures, mais c’est mieux que pas de fenêtre du tout.
Vous pouvez mesurer pratiquement n’importe quel aspect du processus de développement logiciel. Voici quelques mesures qu’autres praticiens ont trouvé utiles :
Mesures utiles
Taille
Total des lignes de code écrit
Lignes de commentaires total
Déclarations totales
Totales lignes vides
Productivité
Nombre d’heures de travail consacré au projet
Nombre d’heures de travail consacrées à chaque routine
Nombre de fois que chaque routine est modifié
Repérage de défaut
Gravité de chaque défaut
Emplacement de chaque défaut
Voie dans laquelle chaque défaut est corrigé
Personne responsable de chaque défaut
Nombre de lignes affectées par la correction des défauts
Nombre d’heures de travail passé à corriger chaque défaut
Temps requis pour trouver un défaut
Quantité de temps nécessaire pour résoudre un problème
Nombre de tentatives faites pour corriger chaque irrégularité
Nombre de nouvelles erreurs résultant de la correction de chaque défaut
Maintenabilité
Nombre de paramètres transmis à chaque routine
Nombre de routines appelé par chaque routine
Nombre de routines qui appellent chaque routine
Nombre de points de décision dans chaque routine
Complexité de flux de contrôle de chaque routine
Lignes de code dans chaque routine
Lignes de commentaires dans chaque routine
Nombre de déclarations de données dans chaque routine
Nombre de Goto dans chaque routine
Nombre d’entrées/sorties des déclarations pour chaque routine
Qualité globale
Nombre total de défauts
Nombre de défauts de chaque routine
Défauts moyennes par mille lignes de code
Mean time between failures
Nombre d’erreurs détectées au compilateur
Vous pouvez recueillir la plupart de ces mesures avec les outils logiciels qui existent actuellement. À cette époque, la plupart des mesures ne sont pas utile pour faire des distinctions subtiles entre les programmes, les modules ou routines (Shepperd et Ince, 1989). Ils sont utiles surtout pour identifier des routines qui sont des « cas particuliers »–des métriques anormales dans une routine qui sont un signe d’avertissement que vous devriez réexaminer la routine, recherchant la qualité exceptionnellement faible.
Ne commencez pas par la collecte de données sur toutes les mesures possibles. Vous allez vous enterrer dans données si complexes et peu fiables, que vous ne serez pas en mesure de comprendre ce que tout cela signifie. Commencez avec un simple ensemble de paramètres tels que le nombre de défauts, de mois de travail, de dollars et de lignes de code. Normaliser les mesures dans l’ensemble de vos projets et ensuite affiner et leur ajouter comme vous gagnez plus de perspicacité dans ce que vous devez mesurer.
S’assurer que la raison pour laquelle que vous êtes collecte de données est bien définie. Un aspect de mesure peut être dangereux si cette seule mesure ne fait pas partie d’un ensemble soigneusement construit des mesures. Si vous mesurez uniquement les lignes de code, vous pourriez trouver tout à coup aux programmeurs de créer des programmes avec beaucoup de défauts. L’effort supplémentaire qui va dans les parties du processus qui se mesure en sort les pièces que vous n’avez pas. Une bonne approche consiste à fixer des objectifs, déterminer les questions que vous devez poser les objectifs et choisissez vos mesures basées sur ce que vous devez savoir pour répondre aux questions. Un examen de la collecte de données au laboratoire de génie logiciel de la NASA a conclu que la principale leçon apprise en 15 ans que vous devez définir les objectifs de la mesure avant de vous mesurer (Valett et McGarry, 1989).
Optimisation
Tel que mentionné précédemment, les principales caractéristiques du modèle de maturité organisationnelle SEI à son plus haut niveau sont répétabilité, mesurabilité et contrôlé des variations et commentaires. Dans un sens, ceci est un exemple de la méthode scientifique. Avant que vous pouvez faire confiance les résultats d’une expérience, il doit être reproductible. Vous devez mesurer les résultats afin de savoir quels sont les résultats. Quand l’expérience est mesurée et reproductible, alors vous pouvez modifier certains paramètres et observer les effets. Parce que le processus est répétable, vous savez que toutes les différences que vous mesurez proviennent de la variation qui vous a présenté. Processus logiciels fonctionnent de la même façon.
Supposons que vous vouliez évaluer l’effet de l’utilisation des inspections plutôt que des procédures pas à pas. Vous avez utilisé systématiquement les procédures pas à pas et a recueilli des données sur le taux de détection des erreurs et l’effort requis pour chaque erreur trouvée. Si vous utilisez un processus reproductible mesuré, lorsque vous substituez les inspections pour les procédures pas à pas vous pouvez être raisonnablement certain que toutes les différences mesurées sont attribuables à l’usage des inspections plutôt que des procédures pas à pas. Si vous mesurez une amélioration de 20 % dans la détection des erreurs et une réduction de 50 pour cent dans l’effort par erreur trouvée, vous pouvez nourrir ce résultat dans le procédé et changement de procédures pas à pas aux inspections. C’est la façon dans laquelle optimise l’organisation de niveau 5–qu’il utilise constamment données recueillies afin d’améliorer son processus.
Résumé
Sur tous, mais les projets de logiciels plus petits, le processus de développement, que vous utilisez substantiellement détermine la qualité de vos programmes. Modèle de maturité de processus du SEI vous donne une approche bien définie d’améliorer votre processus de logiciel. Le modèle SEI a produit des améliorations spectaculaires de la qualité et la productivité pour les entreprises qui ont essayé, et il semble certain de devenir important pour plus d’entreprises à l’avenir.
Autres lectures
Humphrey, S. Watts, gestion du processus logiciel (Managing the Software Process). Reading, Massachusetts, Addison-Wesley, 1989. Humphrey est responsable cinq niveaux du SEI de maturité organisationnelle. Cet ouvrage s’articule selon les niveaux de maturité des processus et des détails les étapes nécessaires pour passer chaque niveau à l’autre. Il donne des définitions beaucoup plus rigoureuses et complètes des niveaux de maturité des processus que j’ai fournis ici.
Pouillon, Mark C., et coll. « Capability Maturity Model pour les logiciels, »  (“Capability Maturity Model for Software,”) SEI-91-TR-24. Disponible à partir de recherche accès, Inc., 3400 Forbes Avenue–Suite 302, Pittsburgh, PA 15213, au 1-800-685-6510. Il s’agit du livre blanc SEI officiel qui établit le modèle de maturité du processus décrit dans cet article.
Humphrey, Watts S., Terry R. Snyder et Ronald R. Willis, 1991. « Software Process Improvement chez Hughes Aircraft, » (“Software Process Improvement at Hughes Aircraft,”) IEEE Software, vol. 8, no 4 (juillet 1991), pp. 11-23. Cette étude de cas fascinante d’amélioration des processus logiciels comprend une discussion franche de Hughes a rencontré des problèmes en essayant d’améliorer ses processus et une liste utile de 11 leçons apprises dans ses efforts d’amélioration.
Grady, Robert B. et Deborah L. Caswell. Logiciel Metrics : Fonder une entreprise large programme (Software Metrics: Establishing a Company – Wide Program), Englewood Cliffs, NJ: Prentice Hall, 1987. Grady et Caswell décrivent leur expérience dans l’établissement d’un programme de logiciel-metrics chez Hewlett-Packard et dire comment vous pouvez établir un dans votre organisation.
Jones, Capers. Mesurage du logiciel appliquée (Applied Software Measurement). New York : McGraw-Hill, 1991. Jones est un chef de file dans l’Etendue de logiciel. Son livre fournit la théorie définitive et la pratique actuelle des techniques de mesure et décrit des problèmes avec les paramètres traditionnels. Il dispose d’un programme complet pour la collecte des « points de fonction Etendue, » la métrique qui remplacera probablement des lignes de code comme la mesure standard de la taille du programme. Jones a recueilli et analysé une énorme quantité de données de qualité et de productivité, et ce livre distille les résultats en un seul endroit.
Autres références
Myers, Ware, 1992. « Bons logiciels pratiques rembourser–ou font? » (“Good Software Practices Pay Off–Or Do They?”) IEEE Software, mars 1992, pp. 96-97.
Pietrasanta, Alfred M., 1991 a. “Une stratégie pour l’amélioration des processus logiciels,” (“A Strategy for Software Process Improvement,”) neuvième annuel du Nord-Ouest Pacifique logiciel qualité Conférence, 7 et 8 octobre 1991, Oregon Convention Center, Portland, Oregon.
Pietrasanta, Alfred M., 1991 b. « Mise en œuvre de génie logiciel dans IBM » (“Implementing Software Engineering in IBM”) (discours), Ninth Annual Pacific Northwest logiciel Quality Conference, 7-8 octobre 1991, Oregon Convention Center, Portland, Oregon.
Shepperd, M. et d. Ince, 1989. « Métriques, analyse de la valeur aberrante et le processus de conception de logiciels, » (“Metrics, Outlier Analysis and the Software Design Process,”) Information et la technologie logicielle, vol. 31, no 2 (mars 1989), pp. 91-98.
Valett, J. et F. E. McGarry, 1989. « Un résumé des expériences de mesure de logiciel dans le laboratoire de génie logiciel, » (“A Summary of Software Measurement Experiences in the Software Engineering Laboratory,”) Journal of Systems and Software, 9 (2), 137-148.
A propos de l’auteur

Steve McConnell est un consultant indépendant de développement de logiciels dans la région de Puget Sound et l’auteur du Code complet: A Practical Handbook de logiciel la Construction publié par Microsoft Press en mai 1993.
Écrivez-moi à [email protected].