Lois de Lehman et Maintenance Logicielle : Optimisation et Réingénierie

Lois de l'Évolution des Systèmes Logiciels (Lois de Lehman)

Évolution Inéluctable

Évolution inéluctable : La loi stipule d'abord que le maintien de ce système est un processus inévitable. Comme les changements de l'environnement système, de nouveaux besoins apparaissent et le système doit être modifié. Lorsque le système modifié est à nouveau introduit dans l'environnement, des changements environnementaux surviennent encore, et donc le cycle de l'évolution recommence.

Dégradation de la Structure

Dégradation de la structure : La loi stipule que chaque fois que le système est modifié, sa structure est dégradée. La seule façon d'éviter cela est d'investir dans l'entretien préventif, dans lequel des heures sont employées à l'amélioration de la structure du logiciel sans ajouter de nouvelles fonctionnalités. Évidemment, cela entraînerait des coûts supplémentaires au-delà de ceux nécessaires pour appliquer les modifications dans le système.

Dynamique du Système

Dynamique : Troisième loi de Lehman. Elle suggère que les grands systèmes ont leur propre dynamique définie à un stade précoce du processus de développement. Cela détermine les tendances difficiles à maintenir le système et limite le nombre de changements possibles. Lehman et Belady suggèrent que cette loi est une conséquence de facteurs structurels qui influencent et limitent les changements du système, ainsi que des facteurs organisationnels qui affectent l'évolution du système.

Types de Maintenance Logicielle

Entretien : corrective, évolutive, adaptative (concernant le personnel, les contrats, la capacité, la maturité).

Maintenance Corrective

Entretien pour réparer les défauts logiciels (maintenance corrective) : La correction d'une erreur de codage est habituellement peu coûteuse ; les erreurs de conception sont plus coûteuses et peuvent nécessiter de repenser le système existant.

Maintenance Adaptative

Entretien d'adapter le logiciel à un environnement d'exploitation différent (maintenance adaptative) : Ce type d'entretien est nécessaire lorsque certains aspects de l'environnement du système, tels que le matériel, la plateforme du système d'exploitation ou d'autres logiciels de support, changent. Le système d'application doit être modifié pour faire face à ces changements environnementaux.

Maintenance Évolutive

Entretien d'ajouter des fonctionnalités au système ou de le modifier (maintenance évolutive) : Ce type d'entretien est requis lorsque les exigences du système changent en réponse à des changements organisationnels ou commerciaux. L'ampleur des changements requis pour le logiciel est beaucoup plus élevée que dans les autres types de maintenance.

Prévisions des Demandes de Changement et Maintenance

Les gestionnaires détestent les surprises, surtout si elles entraînent des coûts élevés inattendus.

Facteurs Liés aux Prévisions

Les prévisions sont liées à :

• Si un changement de système doit être accepté, cela dépend, dans une certaine mesure, de la facilité d'entretien des composants du système affectés par ce changement.
• L'implémentation d'un changement de structure du système tend à le dégrader, réduisant ainsi sa facilité d'entretien.
• Les coûts de maintenance dépendent du nombre de changements, et les coûts pour mettre en œuvre les changements dépendent de la maintenabilité des composants du système.

Prédire le nombre de demandes de changement d'un système nécessite une compréhension de la relation entre le système et son environnement extérieur. Pour cela, il faut évaluer :

Facteurs d'Évaluation

• Le nombre et la complexité des interfaces du système. Plus le nombre d'interfaces et leur complexité sont élevés, plus les exigences sont susceptibles de changer.
• Le nombre d'exigences du système intrinsèquement instables. Les conditions qui reflètent les politiques et procédures organisationnelles sont probablement plus volatiles que les exigences fondées sur des caractéristiques stables du domaine.
• Processus d'affaires dans lequel le système est utilisé. À mesure que les processus de l'entreprise évoluent, ils génèrent des demandes de changement. Plus le processus d'affaires utilise le système, plus les demandes de changement surviennent.

Métriques de Processus pour Évaluer la Facilité d'Entretien

Exemples de métriques de processus qui peuvent être utilisées pour évaluer la facilité d'entretien sont :

• Nombre de demandes de maintenance corrective. Une augmentation du nombre de rapports d'erreurs peut indiquer que plus d'erreurs sont introduites dans le programme qu'elles ne sont réparées pendant le processus de maintenance. Cela peut indiquer un déclin de la maintenabilité.
• Temps moyen nécessaire et souhaité pour l'analyse des impacts. Cela reflète le nombre de composants touchés par la demande de modification. Si ce temps augmente, de plus en plus de composants sont affectés et la maintenabilité diminue.
• Temps moyen de mise en œuvre d'une demande de modification. Ceci n'est pas égal à la durée de l'analyse des impacts, bien qu'il y ait une corrélation. C'est le temps nécessaire pour réellement changer le système et sa documentation après l'évaluation des composants affectés. Une augmentation du temps nécessaire pour mettre en œuvre un changement indique une baisse de la maintenabilité.
• Nombre de demandes de changement en attente. Une augmentation de ce nombre au fil du temps peut indiquer un déclin de la maintenabilité.

Changements Urgents

Les demandes de changements sont souvent liées à des problèmes de système qui doivent être abordés d'urgence. Ces changements urgents peuvent survenir pour trois raisons :

1. Il y avait un défaut grave du système qui doit être réparé pour permettre un fonctionnement normal continu.
2. Effets des changements inattendus dans l'environnement du système d'exploitation qui interrompent le fonctionnement normal.
3. Changements imprévus survenus dans l'entreprise utilisant le système, comme une urgence causée par de nouveaux concurrents ou l'introduction de nouvelles législations.

Réingénierie Logicielle : Risques et Coûts

Réingénierie (risque, coût) $\Rightarrow$ Évolution du code, modularisation, évolution du modèle de données.

La mise en œuvre de la réingénierie d'un système logiciel présente deux principaux avantages par rapport aux approches plus radicales d'évolution du système :

• Risque réduit. Il y a un risque élevé dans le réaménagement d'un logiciel critique pour l'entreprise. Des erreurs peuvent être commises dans les spécifications du système ou il peut y avoir des problèmes de développement. Les retards dans l'introduction du nouveau logiciel peuvent signifier la perte de l'entreprise et entraîner des coûts supplémentaires.
• Réduction des coûts. Le coût de la réingénierie est nettement inférieur au coût de développement de nouveaux logiciels.

Activités du Processus de Réingénierie

Les activités de ce processus de réingénierie sont :

• Conversion du code source. Le programme est converti d'un langage de programmation ancien à une version plus moderne du même langage ou à un langage différent.
• Reverse-Engineering. Le programme est analysé et les informations sont extraites. Cela aide à documenter son organisation et sa fonctionnalité.
• Amélioration de la structure du programme. La structure de contrôle du programme est analysée et modifiée pour faciliter la lecture et la compréhension.
• Modularisation du programme. Les parties liées du programme sont regroupées et, le cas échéant, les redondances sont supprimées. Dans certains cas, cette étape peut impliquer des transformations d'architecture où un système centralisé, prévu pour un seul ordinateur, est modifié pour fonctionner sur une plateforme distribuée.
• Réingénierie des données. Les données traitées sont modifiées pour refléter les changements du programme.

Facteurs Influençant les Coûts de Réingénierie

Indépendamment de l'ampleur de la réingénierie, les principaux facteurs qui influencent les coûts de celle-ci sont :

• La qualité du logiciel à faire réingénier. Une baisse de la qualité du logiciel et de sa documentation associée (le cas échéant) augmente le coût de la réingénierie.
• Les outils disponibles pour soutenir la réingénierie. Il n'y a généralement pas de réduction de coûts significative pour la restructuration d'un système logiciel, sauf si des outils CASE sont utilisés pour automatiser la plupart des changements.
• Conversion étendue des données. Si la réingénierie nécessite la conversion de grands volumes de données, le processus augmentera le coût de manière significative.
• La disponibilité de personnel qualifié. Si le personnel chargé de la maintenance du système doit être impliqué dans le processus de réingénierie, les coûts augmenteront car les ingénieurs système responsables de la réingénierie doivent consacrer beaucoup de temps à la compréhension du système.

Le principal inconvénient de la réingénierie logicielle est qu'il existe des limites pratiques à la mesure dans laquelle un système peut être amélioré.

Stratégies pour les Anciens Systèmes

Les anciens systèmes : Nouveau système, « gel », maintenance corrective, évolution, fiabilité.

Les organisations disposant d'un budget limité pour entretenir et moderniser leurs systèmes existants doivent décider comment obtenir le meilleur retour sur leur investissement. Il existe quatre options stratégiques :

• Jeter le système complètement. Cette option doit être choisie lorsque le système ne contribue plus efficacement aux processus d'affaires.
• Laisser le système inchangé et continuer avec un entretien régulier. Cette option doit être choisie lorsque le système est toujours nécessaire, mais très stable, et que les utilisateurs du système ont relativement peu de demandes de changement.
• Réingénierie du système afin d'améliorer sa maintenabilité. Cette option doit être choisie lorsque la qualité du système a été dégradée par des changements réguliers et lorsque ces modifications sont toujours nécessaires.
• Remplacer tout ou partie du système par un nouveau système. Cette option doit être choisie lorsque d'autres facteurs, tels que le nouveau matériel, rendent impossible la poursuite des activités de l'ancien système ou lorsque les systèmes commerciaux permettent de développer un nouveau système à un coût raisonnable.

Classification des Systèmes par Qualité et Valeur Marchande

Agrégats du système :

• Faible qualité, faible valeur marchande. L'entretien de ces systèmes en opération sera coûteux et le taux de rendement pour l'entreprise sera assez faible. Ces systèmes doivent être mis au rebut.
• Faible qualité, valeur marchande élevée. Ces systèmes contribuent de manière significative à l'entreprise et ne peuvent être écartés. Cependant, une faible qualité signifie qu'il est coûteux de les maintenir. Ces systèmes doivent subir une réingénierie pour améliorer leur qualité ou être remplacés si un système commercial approprié est disponible.
• Haute qualité, faible valeur marchande. Ce sont des systèmes qui ne contribuent pas à l'entreprise, mais dont l'entretien n'est pas cher. Il ne vaut pas la peine de les remplacer, donc l'entretien normal peut continuer à condition qu'aucun changement coûteux de matériel ne soit nécessaire et que le système reste opérationnel. Si des changements coûteux sont nécessaires, les systèmes doivent être mis au rebut.
• Haute qualité, haute valeur marchande. Ces systèmes doivent être maintenus en activité, et leur qualité signifie qu'il ne faut pas investir dans la conversion ou le remplacement. Le remplacement normal doit être procédé.

Évaluation de la Valeur Marchande

Pour évaluer la valeur marchande d'un système, vous devez identifier les acteurs du système que sont les utilisateurs finaux et leurs gestionnaires, et formuler une série de questions sur le système. Il y a quatre questions fondamentales qui devraient être abordées.

• Utilisation du système. Si les systèmes sont utilisés occasionnellement ou pour un petit nombre de personnes, ils peuvent avoir une faible valeur marchande. Un système hérité peut avoir été développé pour répondre à un besoin métier qui a changé ou qui peut désormais être atteint plus efficacement par d'autres moyens.
• Processus de marché de soutien. Lorsqu'un système est mis en place, les processus peuvent être conçus pour exploiter ce système de marché. Cependant, des changements dans ces processus peuvent être impossibles car l'ancien système ne peut pas être adapté. Par conséquent, un système peut avoir une faible valeur marchande car il empêche l'introduction de nouveaux processus.
• La fiabilité du système. La fiabilité du système n'est pas seulement un problème technique, mais aussi un problème d'entreprise. Si un système n'est pas fiable et que les problèmes affectent directement les clients ou exigent que les gens soient détournés de leurs tâches pour résoudre ces problèmes, le système a une faible valeur marchande.
• Les sorties du système. La question fondamentale ici est l'importance des sorties du système pour le bon fonctionnement de l'entreprise. Si l'entreprise dépend de ces sorties, le système a une valeur marchande élevée. D'autre part, si ces sorties peuvent être facilement générées d'une autre manière ou si le système génère des sorties rarement utilisées, sa valeur de marché peut être faible.

Évaluation de la Qualité Technique

Pour évaluer la qualité technique d'un système d'application, vous devez évaluer plusieurs facteurs principalement liés à la fiabilité du système, la difficulté de maintenance du système et la documentation du système. Vous pouvez également recueillir des données quantitatives qui permettront de juger la qualité du système. Exemples de données quantitatives qui peuvent être collectées sont les suivantes :

• Le nombre de demandes de changement dans le système. Les variations tendent à corrompre la structure du système et à rendre les changements futurs plus difficiles. Plus cette valeur est élevée, plus la qualité du système est faible (Note : Il semble y avoir une contradiction ici avec la phrase précédente ; en général, un nombre élevé de changements indique une instabilité ou une mauvaise qualité initiale, rendant les changements plus difficiles).
• Le nombre d'interfaces utilisateur. Ceci est un facteur important dans les systèmes basés sur des formulaires ; chaque formulaire peut être considéré comme une interface distincte avec l'utilisateur. Plus il y a d'interfaces, plus la probabilité d'incohérences et de redondances est élevée.
• Le volume de données utilisées par le système. Plus le volume de données (nombre de fichiers, taille de la base de données, etc.) est important, plus le système sera complexe.

Bien que ces données soient souvent utiles, leur collecte peut être très coûteuse et donc peu pratique. En outre, il n'existe pas de valeurs absolues à utiliser. L'âge et la taille du système doivent être pris en compte dans les jugements de qualité basés sur ces mesures.