Le logiciel (prononciation anglaise : /ˈsɔftˌwɛr/), le logiciel ou le support logiciel est le système formel d’un système informatique, comprenant l’ensemble des composants logiques nécessaires qui permettent d’effectuer des tâches spécifiques, par opposition aux composants physiques que l’on appelle le matériel. L’interaction entre le logiciel et le matériel rend un ordinateur (ou un autre dispositif) opérationnel, c’est-à-dire que le logiciel envoie des instructions que le matériel exécute, rendant son fonctionnement possible.
Les composants logiques comprennent, entre autres, les applications informatiques, telles que le traitement de texte, qui permet à l’utilisateur d’effectuer toutes les tâches relatives à l’édition de texte ; les logiciels dits de système, tels que le système d’exploitation, qui permettent essentiellement au reste des programmes de fonctionner correctement, facilitant également l’interaction entre les composants physiques et le reste des applications, et fournissant une interface avec l’utilisateur.
La grande majorité des logiciels sont écrits dans des langages de programmation de haut niveau, plus faciles et plus efficaces à utiliser pour les programmeurs, car ils sont plus proches du langage naturel que du langage machine. Les langages de haut niveau sont traduits en langage machine à l’aide d’un compilateur ou d’un interpréteur, ou d’une combinaison des deux. Les logiciels peuvent également être écrits en langage d’assemblage, qui est de bas niveau et présente une forte correspondance avec les instructions du langage machine ; il est traduit en langage machine à l’aide d’un assembleur.
L’anglicisme software est le plus répandu pour désigner ce concept, notamment dans le jargon technique, tandis que le synonyme « logicial », dérivé du terme français logiciel, est surtout utilisé dans les pays et régions d’influence française.
Étymologie
Software (AFI : ) est un mot anglais qui, en espagnol, n’a pas de traduction adaptée au contexte, raison pour laquelle il est souvent utilisé sans traduction et a été accepté par l’Académie royale espagnole (RAE). Bien qu’il ne s’agisse pas strictement de la même chose, il est souvent remplacé par des expressions telles que programmes (informatiques), applications (informatiques) ou logiciels.
Le logiciel est ce que l’on appelle un produit dans le génie logiciel.
Le terme « logiciel » est une calque lexicale du terme français logiciel, néologisme formé en 1969 à partir des mots logique et matériel comme traduction de la Délégation à l’informatique chargée du Plan Calcul.
Définition du logiciel
Il existe plusieurs définitions similaires acceptées pour les logiciels, mais la plus formelle est probablement la suivante :
Selon cette définition, le concept de logiciel va au-delà des programmes informatiques dans leurs différents états : code source, binaire ou exécutable ; leur documentation, les données à traiter et même les informations sur l’utilisateur font également partie du logiciel : c’est-à-dire qu’il englobe tout ce qui est intangible, tout ce qui est lié au « non-physique ».
Le terme « logiciel » a été utilisé pour la première fois dans ce sens par John W. Tukey en 1957. En génie logiciel et en informatique, le logiciel est l’ensemble des informations traitées par les systèmes informatiques : programmes et données.
Le concept de lecture de différentes séquences d’instructions (programme) à partir de la mémoire d’un appareil pour contrôler les calculs a été introduit par Charles Babbage dans le cadre de sa machine différentielle. La théorie qui constitue la base de la plupart des logiciels modernes a été proposée par Alan Turing dans son essai de 1936, « Computable Numbers », avec une application au problème de la décision.
Classification des logiciels
Bien que cette distinction soit quelque peu arbitraire et parfois déroutante, les logiciels peuvent être classés en trois types à des fins pratiques.
Processus de création des logiciels
Un « processus » est défini comme l’ensemble ordonné des étapes à suivre pour parvenir à une solution à un problème ou pour obtenir un produit, dans ce cas particulier, pour réaliser un produit logiciel qui résout un problème spécifique.
Le processus de création d’un logiciel peut être très complexe, en fonction de sa taille, de ses caractéristiques et de sa criticité. Par exemple, la création d’un système d’exploitation est une tâche qui nécessite un projet, une gestion, de nombreuses ressources et une équipe disciplinée. À l’autre extrême, s’il s’agit d’un programme simple (par exemple, la résolution d’une équation du second degré), il peut facilement être réalisé par un seul programmeur (même un amateur). Ainsi, ils sont généralement divisés en trois catégories en fonction de leur taille (lignes de code) ou de leur coût : « petit », « moyen » et « grand ». Il existe plusieurs méthodologies pour l’estimer, l’une des plus populaires étant le système COCOMO qui fournit des méthodes et un logiciel (programme) qui calcule et fournit une approximation de tous les coûts de production d’un « projet logiciel » (ratio homme-heure, coût monétaire, nombre de lignes de source en fonction du langage utilisé, etc.)
En ce qui concerne les grands projets, il est nécessaire d’effectuer des tâches complexes, à la fois techniques et managériales, une gestion rigoureuse et diverses analyses (entre autres), dont la complexité a conduit au développement d’une ingénierie spécifique pour en assurer l’étude et la réalisation : il s’agit de l’ingénierie logicielle.
Dans le cas des projets de taille moyenne, de petites équipes (voire un analyste-programmeur expérimenté seul) peuvent mener à bien cette tâche. Cependant, toujours dans les cas moyens et grands (et parfois aussi dans certains cas petits, en fonction de leur complexité), certaines étapes nécessaires à la construction du logiciel doivent être suivies. Ces étapes, bien qu’elles doivent exister, sont flexibles dans la manière dont elles sont appliquées, selon la méthodologie ou le processus de développement choisi et utilisé par l’équipe de développement ou par l’analyste-programmeur isolé (s’il y en a un).
Les « processus de développement de logiciels » ont des règles préétablies et doivent être appliqués lors de la création de logiciels de moyenne et grande taille, faute de quoi le projet échouera très probablement ou finira par ne pas atteindre les objectifs prévus, avec toute une série de défaillances inacceptables (des échecs, en somme). Parmi ces « processus », il existe des variantes agiles ou légères (par exemple XP), lourdes et lentes (par exemple RUP), ainsi que des variantes intermédiaires. Ils sont généralement appliqués en fonction du type et de la taille du logiciel à développer, à la discrétion du chef (s’il y en a un) de l’équipe de développement. Certains de ces processus sont l’eXtreme Programming (XP), le Rational Unified Process (RUP), le Feature Driven Development (FDD), etc.
Quel que soit le « processus » utilisé et appliqué au développement de logiciels (RUP, FDD, XP, etc.), et presque indépendamment de celui-ci, un « modèle de cycle de vie » doit toujours être appliqué.
On estime que, sur le nombre total de grands projets de logiciels entrepris, 28 % échouent, 46 % subissent des modifications importantes qui retardent le projet et 26 % sont pleinement réussis.
Lorsqu’un projet échoue, c’est rarement en raison de défaillances techniques ; la principale cause d’échecs et de défaillances est l’absence d’application d’une bonne méthodologie ou d’un bon processus de développement. Depuis quelques décennies, une tendance forte consiste à améliorer les méthodologies ou les processus de développement, ou à en créer de nouveaux et à sensibiliser les professionnels de l’informatique à leur bonne utilisation. Normalement, les spécialistes de l’étude et du développement de ces domaines (méthodologies) et des domaines connexes (tels que les modèles et même la gestion de projet) sont des ingénieurs en logiciel, c’est leur orientation. Les spécialistes de tout autre domaine du développement de logiciels (analyste, programmeur, informaticien, ingénieur informatique, ingénieur système, etc.) appliquent normalement leurs connaissances spécialisées, mais en utilisant des modèles, des paradigmes et des processus déjà élaborés.
Il est courant, pour le développement de logiciels de taille moyenne, que les équipes humaines impliquées appliquent des « méthodologies propriétaires », généralement un hybride des processus susmentionnés et parfois leurs propres critères.
Le processus de développement peut comporter des tâches nombreuses et variées, allant de l’administratif au technique, en passant par la gestion et l’administration. Mais, presque rigoureusement, certaines étapes minimales sont toujours respectées ; elles peuvent être résumées comme suit :
Les étapes ci-dessus peuvent varier légèrement dans leur dénomination, être plus globales ou, au contraire, être plus raffinées, par exemple indiquer comme une seule phase (à des fins documentaires et interprétatives) « analyse et conception » ; ou indiquer comme « mise en œuvre » ce que l’on appelle « codification » ; mais, à proprement parler, elles existent toutes et comprennent fondamentalement les mêmes tâches spécifiques.
De plus amples détails sur chacune de ces étapes sont donnés dans la section 4 de cet article.
Pour chacune des phases ou étapes énumérées au point précédent, il existe des sous-étapes (ou tâches).
Le modèle de processus ou de cycle de vie utilisé pour le développement définit l’ordre des tâches ou des activités impliquées, ainsi que la coordination entre elles, leur lien et leur retour d’information. Parmi les plus connus, on peut citer : le modèle en cascade ou séquentiel, le modèle en spirale, le modèle itératif incrémental. Parmi les modèles susmentionnés, il existe à leur tour des variantes ou des alternatives, plus ou moins attrayantes en fonction de l’application requise et de ses exigences.
Le dernier modèle, bien que plus communément appelé modèle en cascade, est également appelé « modèle classique », « modèle traditionnel » ou « modèle séquentiel linéaire ».
Le modèle en cascade pur est « difficilement utilisable tel quel », car il impliquerait une connaissance préalable et absolue des exigences, la non-volatilité des exigences (ou la rigidité) et des étapes ultérieures sans erreur ; cela ne pourrait s’appliquer qu’à des systèmes peu nombreux et de petite taille à développer. Dans ces conditions, le passage d’une étape à l’autre des étapes susmentionnées serait sans retour, par exemple de la conception au codage impliquerait une conception exacte sans erreur et sans modification ou évolution probable : « codez ce qui est conçu sans erreur, il n’y aura pas de variantes futures du tout ». C’est une utopie, car intrinsèquement « le logiciel est évolutif par nature », modifiable et difficilement exempt d’erreurs, à la fois pendant son développement et pendant sa vie opérationnelle.
Tout changement au cours de l’exécution de l’une des étapes de ce modèle séquentiel pourrait impliquer de recommencer tout le cycle depuis le début, ce qui entraînerait des coûts élevés en termes de temps et de développement. La figure 2 présente un schéma possible du modèle en question.
Toutefois, le modèle de la cascade, dans certaines de ses variantes, est actuellement l’un des modèles les plus utilisés, en raison de son efficacité et de sa simplicité, principalement dans les logiciels de petite taille et de taille moyenne ; mais il n’est jamais (ou très rarement) utilisé dans sa « forme pure », comme indiqué plus haut. Au lieu de cela, il y a toujours une certaine rétroaction entre les étapes, qui n’est pas complètement prévisible ou rigide ; cela offre des opportunités pour le développement de produits logiciels dans lesquels il y a certaines incertitudes, des changements ou des évolutions au cours du cycle de vie. Ainsi, par exemple, une fois que les exigences ont été capturées et spécifiées (première étape), le système peut être conçu, mais au cours de cette dernière phase, il est très probable que des ajustements devront être apportés aux exigences (même s’ils sont minimes), soit en raison de défauts détectés, d’ambiguïtés ou parce que les exigences elles-mêmes ont changé ou évolué ; il est donc nécessaire de revenir à la première étape ou à l’étape précédente, de procéder aux réajustements pertinents, puis de poursuivre à nouveau la conception ; ce dernier point est connu sous le nom de retour d’information. Le modèle de cascade normal est donc l’application du même modèle avec ses étapes de retour d’information sous une forme ou une autre, permettant de revenir d’une étape à l’étape précédente (et même de pouvoir passer à plusieurs étapes précédentes) si nécessaire.
On obtient ainsi le « modèle de cascade de rétroaction », qui peut être schématisé comme illustré à la figure 3.
Ce qui précède est, en gros, la forme et l’utilisation de ce modèle, l’un des plus utilisés et des plus populaires. Le modèle de la cascade de rétroaction est très attrayant, voire idéal, si le projet est très rigide (peu de changements, planification non évolutive), si les exigences sont très claires et si elles sont correctement spécifiées.
Il existe d’autres variantes similaires au modèle : raffinement des étapes (plus d’étapes, des étapes plus petites et plus spécifiques) ou même moins d’étapes que celles indiquées, bien que dans ce cas, l’étape manquante se trouve à l’intérieur d’une autre étape. L’ordre des étapes indiqué au point précédent est logique et approprié, mais il convient de noter, comme indiqué ci-dessus, qu’il y aura normalement un retour en arrière.
Le modèle linéaire ou en cascade est le paradigme le plus ancien et le plus largement utilisé, mais les critiques dont il a fait l’objet (voir inconvénients) ont jeté un doute sur son efficacité. Néanmoins, il occupe une place très importante dans le génie logiciel et continue d’être le plus utilisé ; il est toujours préférable à une approche aléatoire.
Inconvénients du modèle en cascade.
Les logiciels évoluent avec le temps et les exigences des utilisateurs et du produit changent souvent au fur et à mesure que le produit est développé. Les délais de commercialisation et la concurrence font qu’il n’est pas possible d’attendre la mise sur le marché d’un produit absolument complet ; il est donc conseillé d’introduire une version fonctionnelle limitée sous une forme ou une autre afin d’atténuer les pressions concurrentielles.
Dans ces situations ou dans des situations similaires, les développeurs ont besoin de modèles de progrès conçus pour s’adapter à une évolution temporelle ou progressive, où les exigences fondamentales sont connues à l’avance, même si elles ne sont pas bien définies à un niveau détaillé.
Le modèle en cascade et le modèle de rétroaction en cascade ne tiennent pas vraiment compte de la nature évolutive du logiciel, qui est considéré comme statique, avec des exigences bien connues et définies dès le départ.
Les modèles évolutifs sont des modèles itératifs, permettant le développement de versions de plus en plus complètes et complexes, jusqu’à ce que l’objectif final souhaité soit atteint ; ils peuvent même évoluer davantage pendant la phase d’exploitation.
Les modèles « incrémental itératif » et « en spirale » (entre autres) sont deux des modèles évolutifs les plus connus et les plus utilisés.
En termes généraux, il est possible de distinguer, dans la figure 4, les étapes générales suivies dans le processus de développement d’un produit logiciel. Dans le modèle de cycle de vie choisi, ces étapes sont clairement identifiées. La description du système est essentielle pour spécifier et construire les différentes étapes jusqu’au produit global et final. Les activités simultanées (spécification, développement et validation) résument le développement détaillé des incréments, qui sera effectué ultérieurement.
Le diagramme de la figure 4 illustre de manière très schématique le fonctionnement d’un cycle itératif incrémentiel, qui permet la livraison de versions partielles au fur et à mesure de la construction du produit final, c’est-à-dire lorsque chaque incrément défini atteint sa phase d’exploitation et de maintenance. Chaque version publiée intègre les fonctionnalités et les exigences qui ont été analysées comme nécessaires dans les incréments précédents.
Le modèle incrémental est un modèle de type évolutif qui repose sur plusieurs cycles en cascade à rétroaction, appliqués de manière répétée, avec une philosophie itérative.
La figure 5 montre un affinement du diagramme précédent, selon un schéma temporel, pour obtenir finalement le schéma du modèle de cycle de vie itératif incrémentiel, avec ses activités génériques associées. Ici, nous pouvons clairement voir chaque cycle en cascade qui est appliqué pour obtenir un incrément ; ces derniers sont intégrés pour obtenir le produit final complet. Chaque incrément est un cycle de cascade feedforward, même si, pour des raisons de simplicité, il est représenté comme purement séquentiel dans la figure 5.
On peut observer que certaines activités de développement (pour chaque étape) sont menées en parallèle ou simultanément. Par exemple, dans la figure, alors que la conception détaillée de la première étape est en cours, l’analyse de la deuxième étape est déjà en cours. La figure 5 n’est que schématique, un incrément ne commencera pas nécessairement pendant la phase de conception de l’incrément précédent, il peut être plus tardif (voire plus précoce), à n’importe quel moment de l’étape précédente. Chaque étape se termine par l’activité « exploitation et maintenance » (indiquée par « exploitation » dans la figure), qui correspond à la livraison du produit partiel au client. La date de début de chaque étape dépend de plusieurs facteurs : le type de système, l’indépendance ou la dépendance entre les étapes (deux étapes totalement indépendantes peuvent facilement être lancées en même temps si le personnel disponible est suffisant), la capacité et le nombre de professionnels impliqués dans le développement, etc.
Selon ce modèle, les logiciels sont livrés « en parties fonctionnelles plus petites, mais réutilisables », appelées incréments. En général, chaque incrément s’appuie sur ce qui a déjà été livré.
Comme le montre la figure 5, les séquences en cascade sont appliquées de manière échelonnée au fur et à mesure de l’avancement du calendrier. Chaque séquence linéaire ou en cascade produit un incrément et souvent le premier incrément est un système de base, avec de nombreuses fonctions supplémentaires (connues ou inconnues) non livrées.
Le client utilise initialement ce système de base et, dans l’intervalle, les résultats de son utilisation et de son évaluation peuvent alimenter le plan de développement de l’incrément (ou de la version) suivant(e). En outre, d’autres facteurs tels que l’établissement de priorités (l’urgence plus ou moins grande de la nécessité de chaque incrément particulier) et la dépendance entre les incréments (ou l’indépendance) contribuent également à ce plan.
Après chaque intégration, un produit plus fonctionnel que le précédent est livré. Le processus est répété jusqu’à ce que le logiciel final soit achevé.
Étant itératif, le modèle incrémental permet de livrer à chaque étape un produit partiel mais pleinement opérationnel, et non une partie qui sert à affiner les exigences (comme c’est le cas dans le modèle de prototypage).
L’approche progressive est très utile lorsque le personnel chargé du développement est peu nombreux ; elle l’est également lorsqu’il n’y a pas de délai disponible pour le projet, de sorte que des versions incomplètes sont livrées, mais fournissent à l’utilisateur des fonctionnalités de base (et croissantes). C’est également un modèle utile pour les versions d’évaluation.
Remarque : il peut être envisagé et utile, à tout moment ou à chaque étape, d’incorporer temporairement le paradigme de l’ICN comme complément, afin de disposer d’un mélange de modèles qui améliorent le schéma et le développement d’ensemble.
Exemple :
Comme mentionné, le modèle itératif incrémental est un modèle de type évolutif, c’est-à-dire où des changements probables dans les exigences sont autorisés et attendus pendant la durée du développement ; une certaine marge est autorisée pour que le logiciel puisse évoluer. Applicable lorsque les exigences sont assez bien connues mais pas complètement statiques et définies, ce qui est indispensable pour utiliser un modèle de chute d’eau.
Ce modèle est conseillé pour le développement de logiciels dont on observe, au stade initial de l’analyse, qu’ils ont des domaines bien définis à couvrir, avec une indépendance suffisante pour être développés par étapes successives. Ces domaines à couvrir ont tendance à avoir des degrés d’urgence différents, de sorte qu’ils doivent être classés par ordre de priorité lors d’une analyse préalable, c’est-à-dire qu’il faut définir lequel sera le premier, le second, etc. Les priorités fonctionnelles peuvent ne pas exister du côté du client, mais le développeur doit les fixer de toute façon et avec certains critères, car c’est sur la base de ces priorités que les différents incréments seront développés et livrés.
Le fait qu’il y ait des incréments fonctionnels du logiciel conduit immédiatement à penser à un schéma de développement modulaire, et ce modèle facilite donc un tel paradigme de conception.
En bref, un modèle incrémental permet d’envisager un développement modulaire, avec des livraisons partielles du produit logiciel appelées « incréments » du système, qui sont choisies en fonction de priorités prédéfinies d’une manière ou d’une autre. Le modèle permet une mise en œuvre avec des raffinements successifs (extension ou amélioration). À chaque incrément, de nouvelles fonctionnalités sont ajoutées, de nouvelles exigences sont couvertes ou la version précédemment mise en œuvre du produit logiciel est améliorée.
Ce modèle offre une certaine souplesse pour intégrer les modifications apportées par l’utilisateur aux exigences au cours du développement. Une modification des exigences proposée et approuvée peut être analysée et mise en œuvre en tant que nouvel incrément ou, éventuellement, il peut s’agir d’une amélioration d’un incrément déjà planifié. Toutefois, si le client modifie ses exigences et que cela affecte les incréments précédents déjà réalisés (détection/incorporation tardive), la faisabilité doit être évaluée et un accord doit être conclu avec le client, car cela peut avoir un impact important sur les coûts.
Le choix de ce modèle permet des livraisons fonctionnelles précoces au client (ce qui est bénéfique à la fois pour le client et pour l’équipe de développement). La priorité est donnée aux livraisons des modules ou des incréments pour lesquels il existe un besoin opérationnel, par exemple pour le préchargement d’informations, qui est indispensable pour les incréments suivants.
Le modèle itératif incrémental ne vous oblige pas à spécifier précisément et en détail tout ce que le système doit faire (et comment) avant qu’il ne soit construit (comme dans le cas de la cascade, avec des exigences gelées). Cela n’est fait qu’au cours de l’étape de développement. Cela rend le processus plus gérable et réduit l’impact sur les coûts. En effet, si les exigences sont modifiées ou refaites, seule une partie du système est affectée. Bien que, logiquement, cette situation soit aggravée si elle se produit à un stade avancé, c’est-à-dire dans les derniers incréments. En bref, le modèle facilite l’intégration de nouvelles exigences au cours du développement.
Avec un paradigme incrémental, le temps de développement initial est réduit, car une fonctionnalité partielle est mise en œuvre. Il a également un impact avantageux sur le client, à savoir la livraison anticipée des parties opérationnelles du logiciel.
Le modèle offre tous les avantages du modèle en cascade, en réduisant ses inconvénients uniquement à la portée de chaque incrément.
Le modèle incrémental n’est pas recommandé pour les systèmes en temps réel, à haute sécurité, à traitement distribué ou à haut risque.
Le modèle en spirale a été proposé pour la première fois par Barry Boehm. Il s’agit d’un modèle évolutif qui combine la nature itérative du modèle CCM avec les aspects contrôlés et systématiques du modèle Waterfall. Il permet un développement rapide de versions incrémentielles. Dans le modèle en spirale, le logiciel est construit en une série de versions incrémentielles. Dans les premières itérations, la version incrémentale peut être un modèle papier ou un prototype. Au cours des itérations suivantes, des versions de plus en plus complètes du système conçu sont produites.
Le modèle est divisé en un certain nombre d’activités cadres, appelées « régions de tâches ». En général, il y a entre trois et six régions de tâches (il existe des variantes du modèle). La figure 6 montre le schéma d’un modèle en spirale avec six régions. Il s’agit ici d’une variante du modèle original de Boehm, présenté dans son traité de 1988 ; un traité plus récent a été publié en 1998.
Les régions définies dans le modèle de la figure sont les suivantes :
Les activités énoncées pour le cadre sont générales et s’appliquent à tout projet, qu’il soit grand, moyen ou petit, complexe ou non. Les régions définissant ces activités constituent un « ensemble de tâches » du travail : cet ensemble de tâches doit être adapté aux caractéristiques du projet particulier à entreprendre. Il convient de noter que les éléments énumérés aux points 1 à 6 sont des ensembles de tâches, dont certaines dépendent généralement du projet ou du développement lui-même.
Les petits projets nécessitent un faible nombre de tâches et un faible niveau de formalité. Dans les projets plus importants ou critiques, chaque région de tâches contient des tâches dont le niveau de formalité est plus élevé. Dans tous les cas, des activités de protection (par exemple, la gestion de la configuration du logiciel, l’assurance qualité, etc.
Au début du cycle, ou processus évolutif, l’équipe d’ingénieurs fait le tour de la spirale (métaphoriquement parlant) en partant du centre (marqué par ๑ dans la figure 6) et dans la direction indiquée ; la première boucle de la spirale peut produire le développement d’une spécification de produit ; les étapes suivantes pourraient générer un prototype et des versions du logiciel de plus en plus sophistiquées.
Chaque étape dans la région de planification entraîne des ajustements au plan du projet ; le coût et le calendrier sont renvoyés en fonction de l’évaluation du client. Le chef de projet doit ajuster le nombre d’itérations nécessaires pour achever le développement.
Le modèle en spirale peut être adapté et appliqué tout au long du cycle de vie du logiciel (dans le modèle classique, ou en cascade, le processus se termine à la livraison du logiciel).
On peut avoir une autre vision du modèle en examinant l' »axe des points d’entrée du projet ». Chacun des petits cercles (๏) fixés le long de l’axe représente les points de départ des différents projets (liés) ; à savoir :
Lorsque la spirale est caractérisée de cette manière, elle est opérationnelle jusqu’à ce que le logiciel soit retiré, elle peut éventuellement être inactive (le processus), mais lorsqu’un changement se produit, le processus redémarre au point d’entrée approprié (par exemple, lors de l' »amélioration du produit »).
Le modèle en spirale offre une approche réaliste, qui évolue comme un logiciel ; il est très bien adapté aux développements à grande échelle.
Le modèle en spirale utilise le CCM pour réduire les risques et permet de l’appliquer à n’importe quel stade de l’évolution. Il conserve l’approche classique (en cascade) mais intègre un cadre itératif qui reflète mieux la réalité.
Ce modèle exige la prise en compte des risques techniques à tous les stades du projet ; correctement appliqué, il devrait permettre de les réduire avant qu’ils ne deviennent un véritable problème.
Le modèle évolutif, comme la spirale, est particulièrement adapté au développement de systèmes d’exploitation (complexes), ainsi qu’aux systèmes critiques ou à haut risque (par exemple, les navigateurs et les contrôleurs aéronautiques) et à tous ceux pour lesquels une gestion rigoureuse du projet et de ses risques, qu’ils soient techniques ou de gestion, est nécessaire.
Inconvénients importants :
Ce modèle n’a pas été utilisé autant que le Waterfall (incrémental) ou le MCP, de sorte que son efficacité n’est pas bien mesurée ; il s’agit d’un paradigme relativement nouveau et difficile à mettre en œuvre et à contrôler.
Une variante intéressante du modèle en spirale vu précédemment (figure 6) est le « modèle en spirale gagnant-gagnant » (Barry Boehm). Le modèle en spirale précédent (classique) suggère de communiquer avec le client pour définir les exigences, en lui demandant simplement ce dont il a besoin et en lui fournissant les informations nécessaires à la poursuite du projet ; mais il s’agit là d’un contexte idéal qui se produit rarement. Normalement, le client et le développeur entrent en négociation, négociant le coût par rapport à la fonctionnalité, la performance, la qualité, etc.
« L’élicitation des exigences nécessite donc une négociation, qui est fructueuse lorsque les deux parties sont gagnantes.
Les meilleures négociations sont forcées pour obtenir « Win & Win », c’est-à-dire que le client gagne en obtenant le produit qui le satisfait, et le développeur gagne également en obtenant un budget et une date de livraison réalistes. De toute évidence, ce modèle exige de solides compétences en matière de négociation.
Le modèle gagnant-gagnant définit un ensemble d’activités de négociation au début de chaque étape de la spirale ; les activités suivantes sont définies :
* Manager : client choisi ayant un intérêt direct dans le produit, qui peut être récompensé par l’organisation en cas de succès ou critiqué en cas d’échec.
Le modèle Win & Win met l’accent sur la négociation initiale, il introduit également trois jalons dans le processus appelés « points de fixation », qui aident à établir l’exhaustivité d’un cycle en spirale et fournissent des jalons de décision avant de poursuivre le projet de développement de logiciel.
Au début d’un développement (et non d’un projet), c’est la première phase qui est réalisée et, selon le modèle de processus adopté, elle peut être presque terminée pour passer à l’étape suivante (cas du modèle Waterfall à rétroaction) ou elle peut être partiellement réalisée puis reprise (cas du modèle itératif incrémental ou d’autres modèles de nature évolutive).
En termes simples et fondamentaux, au cours de cette phase, les caractéristiques fonctionnelles et non fonctionnelles que le futur programme ou système à développer doit remplir sont acquises, rassemblées et spécifiées.
La qualité des caractéristiques du système ou du programme à développer, ainsi que son environnement, ses paramètres non fonctionnels et son architecture, dépendent largement de la manière dont cette étape est réalisée. Il s’agit probablement de la phase la plus importante et l’une des plus difficiles à réaliser avec certitude, car elle ne peut être automatisée, n’est pas très technique et dépend largement des compétences et de l’expérience de l’analyste qui l’exécute.
Elle implique fortement l’utilisateur ou le client du système, elle comporte donc des nuances très subjectives et il est difficile de modéliser avec certitude ou d’appliquer une technique qui soit « la plus proche de l’adéquation » (en fait, il n’existe pas de technique « strictement adéquate »). Bien que diverses méthodologies aient été conçues, y compris des logiciels de soutien, pour capturer, éliciter et enregistrer les exigences, il n’existe pas de méthode infaillible ou absolument fiable, et de bons critères et beaucoup de bon sens doivent être appliqués conjointement par le ou les analystes chargés de la tâche ; il est également essentiel de parvenir à une communication et à une compréhension fluides et adéquates avec l’utilisateur final ou le client du système.
L’artefact le plus important résultant de cette étape est ce que l’on appelle la spécification des exigences logicielles ou simplement le document ERS.
Comme nous l’avons mentionné, la capacité de l’analyste à interagir avec le client est essentielle ; en général, le client a un objectif ou un problème général à résoudre, il ne connaît pas du tout le domaine (informatique), ni son jargon, il ne sait même pas précisément ce que le produit logiciel doit faire (quelles fonctions et combien), et encore moins comment il doit fonctionner. Dans d’autres cas, moins fréquents, le client « pense » savoir précisément ce que le logiciel est censé faire et n’y parvient généralement que très partiellement, mais son obstination entrave la tâche d’élicitation. L’analyste doit avoir la capacité de traiter ce type de problème, ce qui inclut les relations humaines ; il doit savoir se mettre au niveau de l’utilisateur pour permettre une communication et une compréhension adéquates.
Rares sont les situations où le client sait avec certitude et même de manière exhaustive ce qu’il attend de son futur système ; c’est le cas le plus facile pour l’analyste.
Les tâches de capture, d’élicitation, de modélisation et d’enregistrement des exigences, en plus d’être extrêmement importantes, peuvent être difficiles à réaliser avec précision et prendre du temps par rapport au processus de développement global ; le processus et les méthodologies pour réaliser cet ensemble d’activités sont normalement supposés faire partie de l’ingénierie logicielle, mais compte tenu de la complexité susmentionnée, on parle maintenant d’ingénierie des exigences, bien qu’elle n’existe pas encore formellement.
Il existe dans le monde entier des groupes d’étude et de recherche qui se consacrent exclusivement à l’élaboration de modèles, de techniques et de processus permettant de capturer, d’analyser et d’enregistrer correctement les exigences. Ces groupes sont ceux qui parlent normalement d’ingénierie des exigences, c’est-à-dire qu’ils la considèrent comme un domaine ou une discipline, mais pas comme un diplôme universitaire en soi.
Certaines exigences ne nécessitent pas la présence du client pour être saisies ou analysées ; dans certains cas, l’analyste peut les proposer lui-même ou même adopter unilatéralement les décisions qu’il juge appropriées (tant pour les exigences fonctionnelles que non fonctionnelles). Pour citer quelques exemples probables : certaines exigences relatives à l’architecture du système, des exigences non fonctionnelles telles que celles relatives aux performances, au niveau de support des erreurs opérationnelles, aux plates-formes de développement, aux relations internes ou aux liens entre les informations (entre les enregistrements ou les tables de données) à stocker dans le cas de bases de données ou de banques de données, etc. Certaines exigences fonctionnelles telles que les options secondaires ou de soutien nécessaires pour améliorer ou faciliter l’opérabilité, etc.
L’obtention de spécifications auprès du client (ou d’autres parties prenantes) est un processus humain hautement interactif et itératif ; normalement, au fur et à mesure que l’information est saisie, elle est analysée et renvoyée au client, affinée, polie et corrigée si nécessaire, quelle que soit la méthode d’ERS utilisée. L’analyste doit toujours apprendre à connaître le sujet et le problème à résoudre, le maîtriser, dans une certaine mesure, jusqu’à ce que le futur système à développer le couvre. Pour cette raison, l’analyste doit avoir une grande capacité à comprendre des problèmes provenant de domaines ou de disciplines de travail très divers (qui ne sont pas spécifiquement les siens) ; par exemple, si le système à développer est destiné à gérer les informations d’une compagnie d’assurance et de ses succursales éloignées, l’analyste doit comprendre comment la compagnie fonctionne et gère ses informations, à partir de niveaux très bas et même jusqu’aux niveaux de la direction. Compte tenu de la grande diversité des domaines à couvrir, les analystes sont souvent assistés par des spécialistes, c’est-à-dire des personnes qui ont une connaissance approfondie du domaine pour lequel le logiciel sera développé ; il est évident qu’une seule personne (l’analyste) ne peut pas couvrir un si grand nombre de domaines de connaissance. Dans les grandes entreprises de développement de produits logiciels, il est courant d’avoir des analystes spécialisés dans certains domaines de travail.
Au contraire, ce n’est pas le problème du client, c’est-à-dire que le client n’a pas besoin de savoir quoi que ce soit sur les logiciels, la conception ou d’autres choses connexes ; il doit seulement fournir des objectifs, des données et des informations (de sa propre main ou à partir de ses dossiers, équipements, employés, etc.) à l’analyste, et guidé par lui, de sorte que, dans un premier temps, il puisse définir l' »univers du discours », et avec un travail supplémentaire, il peut créer le document ERS approprié.
La pression exercée sur les développeurs de systèmes informatiques pour qu’ils comprennent et répondent aux besoins des clients/utilisateurs est bien connue. Plus le contexte du problème est complexe, plus il est difficile d’y parvenir, ce qui oblige parfois les développeurs à devenir des quasi-experts dans les domaines qu’ils analysent.
Lorsque ce n’est pas le cas, il est très probable que l’on obtienne un ensemble d’exigences erronées ou incomplètes et, par conséquent, un produit logiciel fortement désapprouvé par les clients/utilisateurs et dont les coûts de réingénierie et de maintenance sont très élevés. Tout ce qui n’est pas détecté ou mal compris au stade initial aura un impact négatif important sur les exigences, propageant ce courant dégradant tout au long du processus de développement et augmentant ses inconvénients au fur et à mesure qu’il est détecté (Bell et Thayer 1976) (Davis 1993).
Étant donné que la capture, l’élicitation et la spécification des exigences constituent une partie cruciale du processus de développement de logiciels, car la réalisation des objectifs finaux dépend de cette étape, des modèles et diverses méthodologies de travail ont été élaborés à cette fin. Des modèles et diverses méthodologies de travail ont été conçus à cette fin. Il existe également des outils logiciels qui soutiennent les tâches relatives effectuées par l’ingénieur en charge des exigences.
La norme IEEE 830-1998 fournit une normalisation des « pratiques recommandées pour la spécification des exigences logicielles ».
Lorsque les exigences sont obtenues, elles sont généralement analysées et le résultat de cette analyse, avec ou sans le client, est consigné dans un document, connu sous le nom de ERS ou Software Requirements Specification, dont la structure peut être définie par diverses normes, telles que CMMI.
La première étape de la collecte d’informations consiste à connaître et à définir correctement ce que l’on appelle l' »univers de discours » du problème, qui est défini et compris comme suit :
Univers du discours (UdD) : c’est le contexte général dans lequel le logiciel sera développé et fonctionnera. L’univers de discours comprend toutes les sources d’information et toutes les personnes liées au logiciel. Ces personnes sont également appelées acteurs de cet univers. L’UdD est la réalité circonscrite par l’ensemble des objectifs définis par ceux qui ont demandé le logiciel.
L’extraction et l’analyse des informations dans cet univers permettent d’obtenir toutes les spécifications et tous les types d’exigences nécessaires pour le futur produit logiciel.
L’objectif de l’ingénierie des exigences (EI) est de systématiser le processus de définition des exigences, en permettant l’élicitation, la modélisation et l’analyse du problème, en générant un engagement entre les ingénieurs des exigences et les clients/utilisateurs, puisque tous deux participent à la génération et à la définition des exigences du système. La RI fournit un ensemble de méthodes, de techniques et d’outils qui aident les ingénieurs chargés des exigences (analystes) à obtenir des exigences aussi sûres, précises, complètes et opportunes que possible, ce qui est fondamentalement possible :
Bien qu’il existe différents moyens, modèles et méthodologies pour obtenir, définir et documenter les exigences, on ne peut pas dire que l’un d’entre eux soit meilleur ou pire que l’autre, ils ont généralement beaucoup en commun et servent tous le même objectif. Cependant, ce que l’on peut dire sans aucun doute, c’est qu’il est essentiel d’utiliser l’un d’entre eux pour documenter les spécifications du futur produit logiciel. Par exemple, un groupe de recherche argentin propose et étudie depuis plusieurs années l’utilisation du LEL (Extended Language Lexicon) et des scénarios comme méthodologie ; voici l’une des nombreuses références et bibliographies à ce sujet. Une autre façon, plus orthodoxe, de capturer et de documenter les exigences peut être trouvée en détail, par exemple, dans le travail de l’Université de Séville sur la « Méthodologie pour l’analyse des exigences des systèmes logiciels ».
La figure 7 présente un schéma plus ou moins rigoureux, bien que non détaillé, des étapes et des tâches à suivre pour capturer, analyser et spécifier les exigences logicielles. Elle montre également quel artefact ou document est obtenu à chaque étape du processus. Le diagramme n’explicite pas la méthodologie ou le modèle à utiliser, il décrit simplement les tâches qui doivent être accomplies, d’une manière ou d’une autre.
Voici une liste possible, générale et ordonnée, des tâches recommandées pour obtenir la définition de ce qui doit être fait, des produits à obtenir et des techniques à utiliser pendant l’activité d’élicitation des exigences, dans la phase de spécification des exigences du logiciel :
Quelques principes de base à garder à l’esprit :
Deux formes d’exigences peuvent être identifiées :
Il s’agit de la même chose, mais avec un niveau de détail différent.
Exemple d’exigence de l’utilisateur : le système doit accorder des prêts. Exemple d’exigence du système : fonction de prêt : entrée du code partenaire, du code d’émission ; sortie : date de retour ; etc.
Il existe trois types d’exigences système :
Les exigences fonctionnelles décrivent :
Les exigences non fonctionnelles sont des contraintes sur les services ou les fonctions fournis par le système (par exemple, les quotas de temps, le processus de développement, la performance, etc.)
Les exigences du domaine sont dérivées du domaine d’application et reflètent les caractéristiques de ce domaine.
Elles peuvent être fonctionnelles ou non fonctionnelles.
Par exemple, le système de bibliothèque de l’université doit pouvoir exporter des données en utilisant le langage d’intercommunication des bibliothèques espagnoles (LIBE).
Par exemple, le système de bibliothèque ne sera pas en mesure d’accéder aux bibliothèques dont le matériel est censuré.
En génie logiciel, la conception est une phase du cycle de vie du logiciel. Elle est basée sur la spécification des besoins produite par l’analyse des besoins (phase d’analyse), la conception définit la manière dont ces besoins seront satisfaits, la structure qui doit être donnée au système logiciel afin qu’il devienne une réalité.
La conception reste une phase distincte de la programmation ou du codage, ce dernier correspondant à la traduction dans un langage de programmation donné des prémisses adoptées dans la conception.
Les distinctions entre les activités mentionnées jusqu’à présent ne sont pas toujours aussi claires qu’on le souhaiterait dans les théories classiques du génie logiciel. La conception, en particulier, peut décrire le fonctionnement interne d’un système à différents niveaux de détail, chacun d’entre eux étant placé dans une position intermédiaire entre l’analyse et le codage.
L' »architecture de conception » est généralement comprise comme une conception de « très haut niveau », qui définit uniquement la structure du système en termes de modules logiciels qui le composent et de relations macroscopiques entre eux. À ce niveau de conception appartiennent des formulations telles que client-serveur ou « trois niveaux », ou, plus généralement, les décisions relatives à l’utilisation de l’architecture matérielle spéciale à utiliser, le système d’exploitation, le SGBD, les protocoles de réseau, etc.
Un niveau de détail intermédiaire peut définir la décomposition du système en modules, mais cette fois avec une référence plus ou moins explicite au mode de décomposition offert par le langage de programmation particulier avec lequel le développement doit être mis en œuvre, par exemple dans une conception utilisant la technologie des objets, le projet pourrait décrire le système en termes de classes et de leurs interrelations.
La conception détaillée, enfin, est une description du système très proche du codage (par exemple, en décrivant non seulement les classes de manière abstraite, mais aussi leurs attributs et leurs méthodes avec leurs types).
En raison de la nature « intangible » des logiciels et en fonction des outils utilisés dans le processus, la frontière entre la conception et le codage peut également être pratiquement impossible à identifier. Par exemple, certains outils CASE sont capables de générer du code à partir de diagrammes UML, qui décrivent graphiquement la structure d’un système logiciel.
Au cours de cette étape, les tâches communément appelées programmation sont effectuées, ce qui consiste essentiellement à transposer tout ce qui a été conçu dans la phase précédente en code source dans le langage de programmation choisi. Cette tâche est effectuée par le programmeur, en suivant complètement les lignes directrices imposées dans la conception et en prenant toujours en considération les exigences fonctionnelles et non fonctionnelles (ERS) spécifiées lors de la première étape.
Il est courant de penser que l’étape de programmation ou de codage (certains parlent d’implémentation) est l’étape qui occupe la plus grande partie du travail de développement du logiciel ; cependant, cela peut être relatif (et généralement applicable aux petits systèmes) car les étapes précédentes sont cruciales, critiques et peuvent prendre beaucoup plus de temps. Des estimations de 30% du temps total de programmation sont souvent faites, mais ce chiffre n’est pas cohérent car il dépend largement des caractéristiques du système, de sa criticité et du langage de programmation choisi. Plus le niveau du langage est bas, plus le temps de programmation nécessaire est long, ainsi par exemple il faudra plus de temps pour coder un algorithme en langage d’assemblage que le même algorithme programmé en langage C.
Pendant la programmation de l’application, du système ou du logiciel en général, des tâches de débogage sont également effectuées, c’est-à-dire le travail consistant à libérer le code des erreurs qui peuvent être trouvées dans cette phase (sémantique, syntaxe et logique). Il y a une sorte de chevauchement avec la phase suivante, puisque pour déboguer la logique, il est nécessaire d’effectuer des tests unitaires, généralement avec des données de test ; bien sûr, toutes les erreurs ne seront pas trouvées uniquement dans la phase de programmation, il y en aura d’autres qui seront trouvées au cours des phases ultérieures. L’apparition d’une erreur fonctionnelle (mauvaise réponse aux exigences) peut éventuellement conduire à un retour à la phase de conception avant de poursuivre le codage.
Pendant la phase de programmation, le code peut adopter différents états, en fonction de la manière de travailler et du langage choisi, notamment :
Parmi les différents tests effectués sur le logiciel, on peut principalement distinguer :
Les tests sont généralement effectués sur ce que l’on appelle des données de test, c’est-à-dire un ensemble sélectionné de données typiques auxquelles le système, les modules ou les blocs de code peuvent être soumis. Sont également choisies : Les données qui imposent des conditions limites au logiciel afin de tester sa tolérance et sa robustesse ; les données d’utilité pour les mesures de performance ; les données qui provoquent des conditions éventuelles ou particulières qui sont inhabituelles et auxquelles le logiciel ne sera normalement pas soumis mais qui peuvent se produire ; etc. Les « données d’essai » ne sont pas nécessairement fictives ou « créées », mais leur probabilité d’occurrence est généralement faible.
En général, il existe une phase finale et complète de test du logiciel, appelée test bêta, au cours de laquelle le système installé dans des conditions normales de fonctionnement et de travail est testé de manière approfondie afin de détecter les erreurs, les instabilités, les réponses erronées, etc. qui ont passé les contrôles précédents. Ces tests sont normalement effectués par du personnel approprié, engagé ou spécialement affecté à cet effet. Les bogues détectés sont transmis aux développeurs pour qu’ils les déboguent. Dans le cas du développement de logiciels « à la demande », c’est l’utilisateur final (le client) qui effectue le test bêta, après avoir convenu d’une période de test avec le développeur.
L’installation d’un logiciel est le processus par lequel les programmes développés sont correctement transférés vers l’ordinateur cible, initialisés et, éventuellement, configurés, dans le but d’être utilisés par l’utilisateur final. Il s’agit de l’étape finale du développement du logiciel. Après cela, le produit entrera dans la phase d’exploitation et de production pour laquelle il a été conçu.
L’installation, en fonction du système développé, peut consister en une simple copie sur le disque dur cible (cas actuellement rares) ; ou, plus couramment, avec une complexité intermédiaire dans laquelle les différents fichiers composant le logiciel (exécutables, bibliothèques, données propres, etc.) sont décompressés et copiés à des emplacements spécifiques préétablis sur le disque ; des liens sont même créés avec d’autres produits, en plus du système d’exploitation lui-même. Dans ce dernier cas, il s’agit généralement d’un processus assez automatique qui est créé et guidé par des outils logiciels spécifiques (emballage et distribution, installateurs).
Pour les produits plus complexes, la deuxième solution est utilisée, mais elle est exécutée ou guidée par des spécialistes ; elle peut même nécessiter une installation sur plusieurs ordinateurs différents (installation distribuée).
En outre, pour les logiciels moyennement et très complexes, un processus de configuration et de test est généralement nécessaire, au cours duquel les paramètres de fonctionnement appropriés sont attribués et l’opérabilité fonctionnelle du produit est testée.
Dans les produits de grande diffusion, les installations complètes, si elles sont relativement simples, sont généralement effectuées par les utilisateurs finaux eux-mêmes (comme les systèmes d’exploitation, les progiciels de bureautique, les utilitaires, etc. Dans le cas de produits spécifiquement conçus ou « personnalisés », l’installation est normalement réservée aux spécialistes impliqués dans le développement du logiciel en question.
Une fois que le logiciel a été installé avec succès, il passe à la phase de production (opérabilité), au cours de laquelle il remplit les fonctions pour lesquelles il a été développé, c’est-à-dire qu’il est finalement utilisé par le ou les utilisateurs finaux, produisant les résultats escomptés.
La maintenance du logiciel est le processus de contrôle, d’amélioration et d’optimisation du logiciel déjà développé et installé, qui comprend également le débogage des bogues et des défauts qui peuvent avoir échappé à la phase de contrôle et de test bêta.
Cette phase est la dernière phase (avant l’itération, selon le modèle utilisé) qui s’applique au cycle de vie du développement logiciel. La phase de maintenance est la phase qui intervient après que le logiciel est opérationnel et en production.
Une bonne conception et une bonne documentation du développement dépendront de la façon dont se déroulera la phase de maintenance, tant en termes de temps que de coût monétaire. Les modifications apportées à un logiciel qui a été développé avec une documentation inadéquate ou médiocre et une mauvaise conception peuvent être aussi coûteuses, voire plus coûteuses, que le développement du logiciel à partir de zéro. Il est donc primordial de respecter correctement toutes les tâches de la phase de développement et de conserver une documentation adéquate et complète.
La phase de maintenance est généralement la plus longue de tout le cycle de vie. Cette phase implique également des mises à jour et des évolutions du logiciel ; elle n’implique pas nécessairement que le système était bogué. Un ou plusieurs changements dans le logiciel, par exemple adaptatif ou évolutif, peuvent même conduire à une révision et à une adaptation d’une partie des premières phases du développement initial, modifiant toutes les autres, en fonction de la profondeur des changements.
Le modèle courant de la cascade est particulièrement coûteux à maintenir, car sa rigidité signifie que tout changement entraîne un retour à la phase initiale et des perturbations majeures dans les autres phases du cycle de vie.
Au cours de la période de maintenance, il est fréquent que de nouvelles révisions et versions du produit voient le jour, le rendant plus raffiné, plus fonctionnel, plus performant, etc. Plusieurs aspects peuvent être modifiés pour apporter des changements souhaitables et évolutifs, des adaptations ou des extensions et des améliorations.
Plusieurs aspects peuvent être modifiés afin d’apporter des changements souhaitables et évolutifs, des adaptations ou des extensions et des améliorations :
Nature évolutive du logiciel
Le logiciel est le sous-produit du processus de développement, selon le génie logiciel. Ce produit est intrinsèquement évolutif au cours de son cycle de vie : en général, il évolue en générant des versions de plus en plus complètes, complexes, améliorées, optimisées sous certains aspects, adaptées à de nouvelles plates-formes (qu’il s’agisse de matériel ou de systèmes d’exploitation), etc.
Lorsqu’un système cesse d’évoluer, il finit par atteindre la fin de son cycle de vie, devient obsolète et sera inévitablement, tôt ou tard, remplacé par un nouveau produit.
Les logiciels évoluent simplement parce qu’ils doivent s’adapter aux changements de l’environnement, qu’ils soient fonctionnels (exigences de l’utilisateur), opérationnels, de plate-forme ou d’architecture matérielle.
La dynamique de l’évolution des logiciels est l’étude des changements de systèmes. La principale contribution dans ce domaine a été apportée par Meir M. Lehman et Belady, à partir des années 1970 et 1980. Leurs travaux se sont poursuivis dans les années 1990, avec Lehman et d’autres chercheurs qui se sont intéressés au retour d’information dans les processus d’évolution (Lehman, 1996 ; Lehman et al., 1998 ; Lehman et al., 2001). À partir de ces études, ils ont proposé un ensemble de lois (connues sous le nom de lois de Lehman) concernant les changements dans les systèmes. Ces lois (en fait des hypothèses) sont invariantes et largement applicables.
Lehman et Belady ont analysé la croissance et l’évolution de plusieurs grands systèmes logiciels et en ont déduit, selon leurs mesures, les huit lois suivantes :