Évolution du logiciel - Software evolution

Evolution du logiciel : Le logiciel est modifié pour s'adapter à l'évolution des besoins des clients et du marché. L'évolution du logiciel est importante parce que l'organisation a investi des sommes importantes dans son logiciel et dépend entièrement de ce logiciel, où l'évolution du logiciel est déclenchée par l'évolution des exigences de l'entreprise en signalant un défaut logiciel ou par des modifications apportées à un autre système dans un environnement de système logiciel (mise à jour le 5 janvier 2020)

Introduction générale

Fred Brooks , dans son livre clé The Mythical Man-Month , déclare que plus de 90 % des coûts d'un système typique surviennent dans la phase de maintenance, et que tout logiciel réussi sera inévitablement maintenu.

En fait, les méthodes agiles découlent d'activités de type maintenance dans et autour des technologies Web, où la majeure partie des capacités provient des cadres et des normes.

La maintenance logicielle corrige les bogues et les améliorations mineures et l'évolution du logiciel se concentrent sur l' adaptation et la migration .

Les technologies logicielles continueront à se développer. Ces changements nécessiteront la création et la justification de nouvelles lois et théories. Certains modèles nécessiteraient également des aspects supplémentaires lors de l'élaboration de futurs programmes. Les innovations et les améliorations augmentent les formes inattendues de développement de logiciels. Les problèmes de maintenance changeraient aussi probablement pour s'adapter à l'évolution du futur logiciel. Les processus logiciels évoluent eux-mêmes, après avoir subi des apprentissages et des améliorations, il s'agit toujours d'améliorer leur efficience et leur efficacité.

Concepts de base

Le besoin d'évolution du logiciel vient du fait que personne n'est capable de prédire a priori comment les besoins des utilisateurs évolueront . Autrement dit, les systèmes existants ne sont jamais complets et continuent d'évoluer. À mesure qu'ils évoluent, la complexité des systèmes augmentera à moins qu'une meilleure solution ne soit disponible pour résoudre ces problèmes. Les principaux objectifs de l'évolution du logiciel sont d'assurer la pertinence fonctionnelle, la fiabilité et la flexibilité du système. L'évolution du logiciel peut être entièrement manuelle (basée sur les modifications apportées par les ingénieurs logiciels), partiellement automatisée (par exemple à l'aide d'outils de refactoring) ou entièrement automatisée (avec configuration ou évolution autonome).

L'évolution des logiciels a été fortement impactée par Internet :

la croissance rapide du World Wide Web et des ressources Internet permet aux utilisateurs et aux ingénieurs de trouver plus facilement des informations connexes.

le développement open source où n'importe qui pouvait télécharger les codes sources et donc les modifier a permis une évolution rapide et parallèle (via des forks).

Types de maintenance logicielle

EB Swanson a initialement identifié les trois catégories de maintenance : corrective, adaptative et perfective. Quatre catégories de logiciels ont ensuite été cataloguées par Lientz et Swanson (1980). Celles-ci ont depuis été mises à jour et normalisées au niveau international dans la norme ISO/IEC 14764:2006 :

Maintenance corrective : Modification réactive d'un produit logiciel effectuée après livraison pour corriger les problèmes découverts ;
Maintenance adaptative : Modification d'un produit logiciel effectuée après livraison pour maintenir un produit logiciel utilisable dans un environnement modifié ou évolutif ;
Maintenance perfective : Modification d'un produit logiciel après livraison pour en améliorer les performances ou la maintenabilité ;
Maintenance préventive : Modification d'un produit logiciel après livraison pour détecter et corriger les défauts latents dans le produit logiciel avant qu'ils ne deviennent des défauts effectifs.

Tout ce qui précède a lieu lorsqu'il existe une exigence connue de changement.

Bien que ces catégories aient été complétées par de nombreux auteurs comme Warren et al. (1999) et Chapin (2001), la norme internationale ISO/IEC 14764:2006 a conservé les quatre catégories de base.

Plus récemment, la description de la maintenance et de l'évolution des logiciels a été effectuée à l'aide d'ontologies (Kitchenham et al. (1999), Deridder (2002), Vizcaíno (2003), Dias (2003) et Ruiz (2004)), qui enrichissent la description de les nombreuses activités d'évolution.

Modèle de scène

Les tendances et les pratiques actuelles sont projetées vers l'avant à l'aide d'un nouveau modèle d'évolution du logiciel appelé modèle par étapes. Le modèle par étapes a été introduit pour remplacer l'analyse conventionnelle qui est moins adaptée au développement de logiciels modernes et qui évolue rapidement en raison de ses difficultés à contribuer à l'évolution du logiciel. Il existe cinq étapes distinctes qui contribuent au modèle par étapes simple (développement initial, évolution, entretien, suppression progressive et fermeture).

Selon KHBennett et VT Rajlich, la contribution clé est de séparer la phase de « maintenance » en une phase d'évolution suivie d'une phase d'entretien et d'une phase de suppression. La première version du système logiciel qui manque de certaines fonctionnalités sera développée lors du développement initial ou également connue sous le nom de stade alpha. Cependant, l'architecture a déjà été possédée au cours de cette étape apportera pour les futurs changements ou amendements. La plupart des références à cette étape seront basées sur des scénarios ou des études de cas. La connaissance a été définie comme un autre résultat important du développement initial. Ces connaissances comprennent la connaissance du domaine d'application, des exigences des utilisateurs, des règles métier, des politiques, des solutions, des algorithmes, etc. La connaissance semble également être le facteur important pour la phase d'évolution ultérieure.
Une fois l'étape précédente terminée avec succès (et doit être terminée avec succès avant d'entrer dans l'étape suivante), l'étape suivante serait l'évolution. Les utilisateurs ont tendance à modifier leurs exigences et préfèrent voir des améliorations ou des changements. En raison de ce facteur, l'industrie du logiciel est confrontée aux défis d'un environnement de changements rapides. Par conséquent, l'objectif de l'évolution est d'adapter l'application aux besoins des utilisateurs et à l'environnement d'exploitation en constante évolution. Au cours de l'étape précédente, la première version de l'application créée peut contenir de nombreux défauts, et ces défauts seront corrigés au cours de l'étape d'évolution en fonction d'exigences plus spécifiées et précises en raison de l'étude de cas ou des scénarios.
Le logiciel évoluera continuellement jusqu'à ce qu'il ne soit plus évolutif, puis entrera dans la phase de maintenance (également appelée maturité logicielle). Au cours de cette étape, seuls des changements mineurs seront effectués.
L'étape suivante qui est l'élimination progressive, il n'y a plus d'entretien disponible pour ce logiciel particulier. Cependant, le logiciel est toujours en production.
Enfin, fermeture. L'utilisation du logiciel est déconnectée ou interrompue et les utilisateurs sont orientés vers un remplacement.

Les lois de Lehman sur l'évolution du logiciel

Le professeur Meir M. Lehman , qui a travaillé à l' Imperial College de Londres de 1972 à 2002, et ses collègues ont identifié un ensemble de comportements dans l'évolution des logiciels propriétaires. Ces comportements (ou observations) sont connus sous le nom de lois de Lehman, et il y en a huit :

(1974) "Continuer le changement" - un système de type E doit être continuellement adapté ou il devient progressivement moins satisfaisant
(1974) "Increasing Complexity" - à mesure qu'un système de type E évolue, sa complexité augmente à moins que des travaux ne soient effectués pour le maintenir ou le réduire
(1980) "Autorégulation" — Les processus d'évolution du système de type E s'autorégulent avec la distribution des mesures des produits et des processus proche de la normale
(1978) "Conservation de la stabilité organisationnelle ( taux de travail invariant )" - le taux d'activité global effectif moyen dans un système de type E en évolution est invariant au cours de la durée de vie du produit
(1978) "Conservation of Familiarity" — au fur et à mesure qu'un système de type E évolue, tous associés à celui-ci, les développeurs, le personnel de vente et les utilisateurs, par exemple, doivent maintenir la maîtrise de son contenu et de son comportement pour parvenir à 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.
(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 durée de vie
(1996) "Declining Quality" - la qualité d'un système de type E semblera décliner à moins qu'il ne soit rigoureusement maintenu et adapté aux changements de l'environnement opérationnel
(1996) "Système de rétroaction" (déclaré pour la première fois en 1974, formalisé en tant que loi de 1996) - Les processus d'évolution de type E constituent des systèmes de rétroaction multi-niveaux, multi-boucles et multi-agents et doivent être traités comme tels pour obtenir une amélioration significative par rapport à tout base

Il convient de mentionner que l'applicabilité de toutes ces lois pour tous les types de systèmes logiciels a été étudiée par plusieurs chercheurs. Par exemple, voir une présentation de Nanjangud C Narendra où il décrit une étude de cas d'un projet Agile d'entreprise à la lumière des lois de Lehman sur l'évolution des logiciels. Certaines observations empiriques issues de l'étude du développement de logiciels open source semblent remettre en cause certaines lois.

Les lois prédisent que le besoin de changement fonctionnel dans un système logiciel est inévitable, et non la conséquence d'une analyse incomplète ou incorrecte des exigences ou d'une mauvaise programmation. Ils déclarent qu'il y a des limites à ce qu'une équipe de développement logiciel peut réaliser en termes de mise en œuvre en toute sécurité des changements et des nouvelles fonctionnalités.

Des modèles de maturité spécifiques à l'évolution du logiciel ont été développés pour améliorer les processus et aider à assurer le rajeunissement continu du logiciel au fur et à mesure de son évolution itérative.

Le « processus global » qui est fait par les nombreuses parties prenantes (par exemple, les développeurs, les utilisateurs, leurs gestionnaires) a de nombreuses boucles de rétroaction. La vitesse d'évolution est fonction de la structure de la boucle de rétroaction et d'autres caractéristiques du système global. Les techniques de simulation de processus, telles que la dynamique du système, peuvent être utiles pour comprendre et gérer un tel processus global.

L'évolution du logiciel n'est probablement pas darwinienne , lamarckienne ou baldwinienne , mais un phénomène important en soi. Compte tenu de la dépendance croissante vis-à-vis des logiciels à tous les niveaux de la société et de l'économie, l'évolution réussie des logiciels devient de plus en plus critique. C'est un sujet de recherche important qui n'a pas reçu beaucoup d'attention.

L'évolution du logiciel, en raison de son chemin rapide par rapport à d'autres entités créées par l'homme, a été considérée par Lehman comme la "mouche des fruits" de l'étude de l'évolution des systèmes artificiels.

Voir également

Outils disponibles

apiwave – Évolution de l'API dans les projets Java GitHub .
LibVCS4j Une bibliothèque Java qui permet aux outils existants d'analyser l'évolution des systèmes logiciels en fournissant une API commune pour différents systèmes de contrôle de version et de suivi des problèmes.

Les références

Lectures complémentaires

Andrea Capiluppi, Jesus M.Gonzalez Barahona, Israel Herraiz, Gregorio Robles, Adaptation du "modèle mis en scène pour l'évolution du logiciel" au FLOSS
Mark C. Paulk, A History of the Capability Maturity Model Software

Languages

In other projects