News information : Les implications de la maintenance logicielle sur les coûts et les logiciels

abstrait Le dictionnaire définit la maintenance comme «le travail de garder quelque chose en ordre». Cependant, cette définition ne s'applique pas nécessairement aux logiciels. La maintenance logicielle est différente de la maintenance matérielle car le logiciel n'est pas physiquement fatigué mais devient souvent moins utile avec l'âge. Le logiciel est généralement distribué avec des défauts non détectés. Par conséquent, la maintenance logicielle est: "Le processus de modification d'un logiciel d'exploitation existant en laissant intactes ses fonctions principales." La maintenance dépasse généralement cinquante pour cent du coût du cycle de vie des systèmes. Bien que la maintenance logicielle puisse être considérée comme un niveau d'activité d'effort, il existe des conséquences sur la qualité, la fonctionnalité, la fiabilité, le coût et le calendrier qui peuvent être atténuées grâce à l'utilisation de techniques d'évaluation paramétrique.

1. INTRODUCTION L'un des plus grands défis auxquels sont confrontés les ingénieurs logiciels est la gestion du contrôle des changements. Il a été estimé que les coûts de contrôle du changement peuvent se situer entre 40% et 70% des coûts du cycle de vie. Les ingénieurs logiciels espèrent que de nouveaux langages et le nouveau processus réduiront considérablement ces nombres; mais cela n'a pas été vrai. Fondamentalement, cela est dû au fait que le logiciel est toujours livré avec un nombre important de défauts. Capers Jones estime qu'il y a environ 5 erreurs de points de fonction créées pendant le développement. Watts Humphrey a constaté que "… même les ingénieurs logiciels expérimentés injectent normalement 100 défauts ou plus pour KSLOC. Capers Jones dit:" Une série d'études de densité de défauts logiciels varie de 49,5 à 94,5 erreurs pour mille lignes de code. "Le but de cet article est d'abord de passer en revue les bases de la maintenance logicielle et de présenter des approches alternatives à l'évaluation de la maintenance logicielle. dans le coût de développement et les coûts de maintenance qui en résultent.

2. APPROBATION DU PROGRAMME Les activités de maintenance comprennent tous les travaux effectués après l'expédition et doivent être distinguées des modifications de blocs, qui représentent un effort de conception et de développement important et remplacent un progiciel précédemment publié. Ces activités de maintenance peuvent être assez variées, et cela aide à identifier exactement quelles activités postnatales seront incluses dans une évaluation de l'effort de maintenance. Les activités de maintenance, une fois définies, peuvent être évaluées sous un tout autre angle que lorsqu'elles sont simplement appelées «maintenance». La maintenance logicielle est différente de la maintenance matérielle car le logiciel n'est pas physiquement épuisant, mais le logiciel devient souvent moins utile avec l'âge et peut être livré avec des défauts non détectés. Outre les défaillances non détectées, il est courant qu'un certain nombre de défauts connus passent de l'organisation de développement à l'équipe de maintenance. L'évaluation précise de l'effort requis pour maintenir un logiciel distribué est facilitée en décomposant l'effort global en différentes activités qui composent l'ensemble du processus.

3. P APPLICATION DES MÉDIAS DE MASSE La maintenance est un processus compliqué et structuré. Dans son manuel, Evaluating Software Intensive Systems, Richard Stuzke décrit le processus typique de maintenance logicielle. De toute évidence, le processus va au-delà de la simple écriture de nouveau code.

La liste suivante peut être utilisée pour explorer le réalisme et la précision des exigences de maintenance.

o Quels logiciels seront maintenus?

o Combien de temps le système devra-t-il être maintenu?

o Évaluez-vous l'ensemble du problème de maintenance ou simplement une maintenance supplémentaire?

o Quel niveau de maintenance est requis?

o Est-ce que ce qu'on appelle réellement la maintenance est un nouveau projet de développement?

o Qui fera la maintenance? Sera-t-il fabriqué de manière organique par le développeur d'origine? Y aura-t-il une équipe spéciale? Y aura-t-il une organisation distincte?

o Les mainteneurs utiliseront-ils les mêmes outils utilisés pendant le développement? Des outils propriétaires sont-ils nécessaires pour la maintenance?

o Combien y a-t-il d'étagères commerciales sur étagère (COTS)? Les interfaces sont-elles étroites?

o Certains des développements suivants peuvent être déguisés en maintenance. Cela entraînera une augmentation des chiffres de maintenance ou entraînera des défaillances si la maintenance de base est supprimée. Ces questions vous aideront à demander si la maintenance est représentée honnêtement.

o L'activité est-elle vraiment une amélioration progressive?

o Des extraits sains du code d'origine ont-ils été réévalués ou modifiés?

o Du personnel supplémentaire sera-t-il mis en place pour effectuer la mise à jour?

o Le calendrier des efforts de maintenance est-il régulier et assez plat, ou contient-il des restes de personnel qui ressemblent à de nouveaux développements?

4. SCIENCES SANITAIRES Bien que des contrôles sanitaires devraient être exigés année après année, ils ne devraient pas viser le développement général. La raison en est que les activités de maintenance peuvent avoir lieu indéfiniment, rendant les règles du cycle de vie inutiles. À titre d'exemple, considérons Grady (p. 17):

Nous consacrons environ 2 à 3 fois plus d'efforts à la maintenance et aux mises à niveau des logiciels qu'à la création de nouveaux logiciels.

Cette observation et des observations similaires s'appliquent à un niveau organisationnel et supérieur, mais pas à un projet spécifique. Tout groupe de développement à un étage sera inclus sur les bords longs de bon nombre de leurs projets soumis, nécessitant toujours une attention non définie. Voici quelques vérifications mentales rapides:

o Un responsable peut gérer environ 10 000 lignes par an.

o L'effort global du cycle de vie est généralement de 40% de développement et 60% de maintenance.

o Les coûts de maintenance représentent en moyenne un sixième des coûts de développement annuels.

o Les systèmes efficaces sont généralement maintenus pendant 10 à 20 ans.

Enfin, comme dans le développement, la quantité de code nouveau par rapport à modifié fait une différence. La taille effective, c'est-à-dire l'effort équivalent si tous les travaux étaient du nouveau code, reste la principale contribution à l'estimation des coûts de développement et de maintenance.

5. PARTIE Q DEMANDES ALTERNATIVES Toutes les techniques d'évaluation de logiciels devraient être capables de modéliser la théorie du monde réel et les résultats possibles. Le scénario réel est qu'au fil du temps, les changements qui se chevauchent au fil des changements rendent le logiciel de plus en plus difficile à maintenir et donc moins utile. Les techniques d'évaluation de l'effort de maintenance vont du simple niveau de la méthode d'effort, en passant par des analyses plus réfléchies et des modifications des pratiques de développement, à l'utilisation de modèles paramétriques afin d'utiliser les données historiques aux besoins du projet. suivant.

5.1 Niveau d'effort Comme c'est parfois le cas dans l'environnement de développement, la maintenance logicielle peut être modélisée comme un niveau d'activité d'effort. Compte tenu de la catégorie des activités de réparation et de la grande variance qu'elles montrent, cette approche présente clairement des inconvénients. Dans cette approche, un niveau d'effort de maintenance logicielle est basé sur la taille et le type.

5.2 Niveau de tentative plus Stuzke a proposé que la maintenance logicielle commence par le niveau d'effort de base (le nombre minimum de personnes nécessaires pour avoir une compétence de base, puis que le personnel de base soit modifié en évaluant trois facteurs supplémentaires: la gestion de la configuration, l'assurance qualité et la gestion). Son processus a traité certains des facteurs supplémentaires qui affectent la maintenance des logiciels.

5.3 Facteur de changement de maintenance L'estimation des coûts des logiciels avec COCOMO II (Boehm 2000) propose une méthodologie trompeuse simple mais aussi très utile pour déterminer la maintenance annuelle. La maintenance est l'un des choix de menu dans la barre de menus. Chez COCOMO II, la maintenance implique le processus de modification d'un logiciel opérationnel existant en laissant intactes ses fonctions principales. Ce processus exclut:

o Refonte et redéveloppement majeur (plus de 50% de nouveau code) d'un nouveau logiciel qui remplit essentiellement les mêmes fonctions.

o Conception et développement d'un progiciel d'intervention significatif (plus de 20% des instructions source contenant le produit existant) qui nécessite relativement peu de confiance sur le produit existant.

o Opérations du système de traitement des données, saisie des données et modification des valeurs dans la base de données.

Les calculs de maintenance sont fortement basés sur le facteur de changement de maintenance (MCF) et le facteur d'ajustement de maintenance (MAF). MCF est similaire au trafic de changement annuel dans COCOMO81, sauf que des périodes de maintenance autres qu'un an peuvent être utilisées. La formule d'évaluation de l'effort de maintenance s'avère être la même que le modèle de développement de l'architecture COCOMO II.

Comme indiqué précédemment, les trois moteurs des coûts de maintenance diffèrent du développement. Ces inducteurs de coûts sont la fiabilité des logiciels, les pratiques de programmation modernes et le calendrier. COCOMO II suppose que l'investissement accru dans la fiabilité des logiciels et l'utilisation de pratiques de programmation modernes lors du développement de logiciels ont un fort effet positif sur la phase de maintenance.

Effort de maintenance annuel = (Trafic de changement annuel) * (Effort de développement de logiciel d'origine)

Le montant de l'effort de développement logiciel fait référence à l'effort total (mois-personnes ou autre unité de mesure) dépensé tout au long du développement, même s'il s'agit d'un projet pluriannuel.

Le trafic de changement de multiplicateur annuel est la proportion du nombre total de logiciels à modifier au cours de l'année. Ceci est relativement facile à obtenir des évaluations techniques. Les développeurs continuent souvent de modifier les listes ou ont un sentiment de changement proportionnel qui est nécessaire avant même que le développement ne soit terminé.

5.4 Gestion des coûts de maintenance des logiciels avec les techniques de développement et les décisions de gestion pendant le développement

En matière de maintenance, "un sou dépensé est une livre économisée". Les meilleures pratiques de développement (même si elles sont plus chères) peuvent réduire considérablement les efforts de maintenance et le coût global du cycle de vie. Plus les efforts de développement sont importants, moins ils sont nécessaires à la maintenance. Par exemple, le coût et le calendrier de développement de logiciels peuvent être considérablement affectés (réduits) en augmentant le nombre de défauts soumis. Cette réduction des coûts et des délais est plus que compensée par une augmentation des coûts de maintenance. La discussion suivante est un exemple de la façon dont une décision de gestion peut affecter / réduire considérablement les coûts de maintenance logicielle.

Lloyd Huff et George Novak de Lockheed Martin Aeronautics dans leur article "Lockheed Martin Aeronautics Performance Based Software for F-35 Lightning II" proposent une série de décisions de développement et de gestion conçues pour impacter et réduire les coûts de maintenance des logiciels. Ils proposent un processus en huit étapes pour évaluer et contrôler la maintenance des logiciels. Les étapes proposées sont les suivantes:

1. Viser le commun

2. Appliquer les pratiques d'ingénierie industrielle aux logiciels

3. S'engager

4. Adoptez une approche holistique de la durabilité

5. Développement de systèmes et de logiciels hautement sécurisés

6. Gérer les logiciels standard

7. Planifiez l'inattendu

8. Analyser et affiner l'analyse de rentabilisation pour le support logiciel (utiliser les estimations des coûts de maintenance paramétrique du logiciel)

5.5 Une évaluation paramétrique de la maintenance logicielle

Les modèles paramétriques comme SEER for Software permettent de modéliser la maintenance de deux manières:

Évaluez la maintenance dans le cadre du coût total du cycle de vie. Le choix des bons paramètres de catégorie de maintenance comprendra une évaluation de l'effort de maintenance avec l'évaluation du développement du programme logiciel individuel. Certains rapports et graphiques montrent des expériences dans le développement des efforts de maintenance. Cette méthode est mieux utilisée pour estimer les coûts du cycle de vie de chaque programme logiciel individuel.

Évaluer la maintenance comme une activité distincte. En utilisant les bons paramètres pour la maintenance logicielle, vous pouvez modéliser les efforts de maintenance comme une activité distincte. Cette méthode vous permettra d'ajuster votre cote de maintenance en ajustant les paramètres. La taille de la maintenance doit être la même que la taille du développement, mais doit être entrée comme tout le code préexistant. Cette méthode peut également être utile pour séparer les coûts totaux de maintenance du projet des coûts de développement du projet.

Une bonne évaluation paramétrique pour la maintenance comprend un large éventail d'informations. Les informations essentielles pour effectuer une évaluation de maintenance logicielle sont la taille ou la quantité de logiciels à maintenir, la qualité de ces logiciels, la qualité et la disponibilité de la documentation, et le type ou la quantité de maintenance à effectuer. De nombreuses organisations n’estiment pas les coûts de maintenance; ils ont juste un budget pour la maintenance des logiciels. Dans ce cas, un modèle paramétrique doit être utilisé pour calculer la quantité de maintenance qui peut réellement être effectuée avec le budget donné.

L'évaluation et la planification de la maintenance sont des activités essentielles si le logiciel doit fonctionner correctement tout au long de sa durée de vie prévue. Même avec un budget limité, un plan peut être fait pour utiliser les ressources disponibles de la manière la plus efficace et productive. En regardant le diagramme ci-dessus, vous pouvez voir que non seulement les nombreuses entrées affectent la maintenance, mais que certains résultats clés fournissent les informations nécessaires pour planifier un effort de maintenance réussi.

6. Conclusion Les conclusions de cet article sont les suivantes:

o La maintenance logicielle peut être modélisée à l'aide d'une méthode simple comme le niveau d'effort du personnel, mais cette technique présente des inconvénients.

o Les coûts de maintenance des logiciels peuvent être considérablement affectés par les décisions de gestion au cours du processus de développement.

o La maintenance logicielle peut être estimée avec précision à l'aide de processus paramétriques.

o La maintenance logicielle est mieux modélisée lorsque les décisions de développement et de gestion sont associées à des techniques d'estimation des coûts paramétriques.

RÉFÉRENCES (1) Concepts et pratiques de maintenance logicielle (2e édition) par Penny Grubb et Armstrong Takang, World Scientific, 2005.

(2) Évaluation des systèmes logiciels intensifs; Richard Stuzke, 2005, Addison-Wesley.

(3) Lloyd Huff, George Novak; Lockheed Martin Aeronautics; Support logiciel Lockheed Martin Aeronautics basé sur les performances du F-35 Lightning II.

(4) G. Edward Bryan, «CP-6: Mesures de qualité et de productivité dans le cycle de vie de 15 ans d'un système d'exploitation», Journal of Quality Management 2, 129-144, juin 1993.

(5) Taille du logiciel, évaluation et gestion des risques; Daniel D. Galorath, Michael W. Evans, 2006, Auerbach Publications.