Lois de Lehman sur l'évolution des logiciels

En génie logiciel, les lois de l'évolution des logiciels font référence à une série de lois que Manny Lehman (en) et László Bélády ont formulées à partir de 1974 concernant l'évolution des logiciels^[1]^,^[2]. Ces lois décrivent un équilibre entre, d'une part, les forces qui conduisent à de nouveaux développements, et d'autre part, celles qui ralentissent leur progression. Au cours des dernières décennies, les lois ont été révisées et étendues à plusieurs reprises^[3].

Contexte

En remarquant que la plupart des logiciels sont sujets à des changements au cours de leur existence, les auteurs ont entrepris de déterminer à quelles lois ces changements obéiront typiquement, ou devront obéir pour que ces logiciels puissent survivre.

Dans son article de 1980^[1], Lehman précisait l'application de ces lois en distinguant trois catégories de logiciels :

un programme de type S est écrit en fonction d'une spécification exacte de ce que ce programme peut faire ;
un programme de type P est écrit pour implémenter certaines procédures qui déterminent complètement ce que le programme peut faire (l'exemple mentionné est un programme pour jouer aux échecs)
un programme de type E est écrit pour réaliser une activité du monde réel ; la façon dont il doit se comporter est étroitement liée à l'environnement dans lequel il s'exécute, et un tel programme doit s'adapter aux différentes exigences et circonstances dans cet environnement.

Ces lois ne doivent être appliquées qu'à cette dernière catégorie de systèmes.

Les lois

Au total, huit lois ont été formulées :

(1974) « Changement continu » : un système de type E doit être continuellement adapté, ou il devient progressivement moins satisfaisant^[4].
(1974) « Complexité croissante » : à mesure qu'un système de type E évolue, sa complexité augmente, à moins que des travaux ne soient réalisés pour la maintenir ou la réduire^[4].
(1974) « Auto-régulation » : les processus d'évolution des systèmes de type E s'autorégulent avec une distribution de produits et des mesures de processus proches de la normale^[4].
(1978) « Conservation de la Stabilité Organisationnelle (taux de travail invariant) » : le taux d'activité global efficace moyen dans un système de type E en évolution est invariant sur la durée de vie du produit^[4].
(1978) « Conservation de la familiarité » : à mesure qu'un système de type E évolue, toutes les personnes qui y sont associées - les développeurs, les commerciaux et les utilisateurs, par exemple - doivent maintenir la maîtrise de son contenu et son comportement pour obtenir une évolution satisfaisante. Une croissance excessive diminue cette maîtrise. Par conséquent, la croissance incrémentale moyenne reste invariante à mesure que le système évolue^[4].
(1991) « Croissance continue » : le contenu fonctionnel d'un système de type E doit être continuellement augmenté pour maintenir la satisfaction des utilisateurs tout au long de sa vie.
(1996) « Qualité décroissante » : la qualité d'un système de type E apparaîtra comme décroissante, à moins qu'il ne soit rigoureusement maintenu et adapté aux changements de son environnement de fonctionnement^[5].
(1996) « Système de Rétroaction » (énoncé pour la première fois en 1974, formalisé par la loi de 1996) : les processus d'évolution de type E constituent des systèmes de rétroaction à plusieurs niveaux, à plusieurs boucles et à plusieurs agents ; et ils doivent être traités comme tels pour obtenir des améliorations significatives par rapport à toute base raisonnable.

Références

(en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Lehman's laws of software evolution » (voir la liste des auteurs).

↑ ^{a et b} Meir M. Lehman, « Programs, Life Cycles, and Laws of Software Evolution », Proc. IEEE, vol. 68, n^o 9,‎ 1980, p. 1060–1076 (DOI 10.1109/proc.1980.11805)
↑ M. M. Lehman, J. F. Ramil, P. D. Wernick, D. E. Perry et W. M. Turski « Metrics and laws of software evolution—the nineties view » (1997) (DOI 10.1109/METRIC.1997.637156, lire en ligne)
— « (ibid.) », dans Proc. 4th International Software Metrics Symposium (METRICS '97), p. 20–32
↑ Israel Herraiz, Daniel Rodriguez, Gregorio Robles et Jesus M. Gonzalez-Barahona, « The evolution of the laws of software evolution », ACM Computing Surveys, vol. 46, n^o 2,‎ 2013, p. 1–28 (ISSN 0360-0300, DOI 10.1145/2543581.2543595)
↑ ^{a b c d et e} M. M. Lehman, « On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle », Journal of Systems and Software, vol. 1,‎ 1980, p. 213-221 (DOI 10.1016/0164-1212(79)90022-0)
↑ Liguo Yu and Alok Mishra (2013) An Empirical Study of Lehman’s Law on Software Quality Evolution in International Journal of Software and Informatics, 11/2013; 7(3):469-481.

Portail de l’informatique

[laws1-1] {a et b} Meir M. Lehman, « Programs, Life Cycles, and Laws of Software Evolution », Proc. IEEE, vol. 68, n^o 9,‎ 1980, p. 1060–1076 (DOI 10.1109/proc.1980.11805)

[softwarelaws-2] M. M. Lehman, J. F. Ramil, P. D. Wernick, D. E. Perry et W. M. Turski « Metrics and laws of software evolution—the nineties view » (1997) (DOI 10.1109/METRIC.1997.637156, lire en ligne)
— « (ibid.) », dans Proc. 4th International Software Metrics Symposium (METRICS '97), p. 20–32

[HerraizRodriguez2013-3] Israel Herraiz, Daniel Rodriguez, Gregorio Robles et Jesus M. Gonzalez-Barahona, « The evolution of the laws of software evolution », ACM Computing Surveys, vol. 46, n^o 2,‎ 2013, p. 1–28 (ISSN 0360-0300, DOI 10.1145/2543581.2543595)

[laws1-5-4] {a b c d et e} M. M. Lehman, « On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle », Journal of Systems and Software, vol. 1,‎ 1980, p. 213-221 (DOI 10.1016/0164-1212(79)90022-0)

[5] Liguo Yu and Alok Mishra (2013) An Empirical Study of Lehman’s Law on Software Quality Evolution in International Journal of Software and Informatics, 11/2013; 7(3):469-481.

[1]

[2]

[3]

[4]

[5]