Présentation de la maintenance logicielle

La maintenance logicielle fait désormais partie du SDLC largement acceptée. Il représente toutes les modifications et mises à jour effectuées après la livraison du produit logiciel. Il y a un certain nombre de raisons pour lesquelles des modifications sont nécessaires, certaines d'entre elles sont brièvement mentionnées ci-dessous:

Market Conditions - Les politiques, qui changent au fil du temps, telles que la fiscalité et les contraintes nouvellement introduites comme la façon de tenir la comptabilité, peuvent nécessiter des modifications.
Client Requirements - Au fil du temps, le client peut demander de nouvelles fonctionnalités ou fonctions dans le logiciel.
Host Modifications - Si l'un des matériels et / ou plates-formes (tels que le système d'exploitation) de l'hôte cible change, des modifications logicielles sont nécessaires pour conserver l'adaptabilité.
Organization Changes - S'il y a un changement au niveau de l'entreprise du côté du client, comme la réduction de la force de l'organisation, l'acquisition d'une autre entreprise, l'organisation s'aventurant dans une nouvelle entreprise, il peut se produire un besoin de modifier le logiciel d'origine.

Types de maintenance

Au cours de la durée de vie d'un logiciel, le type de maintenance peut varier en fonction de sa nature. Il peut s'agir simplement de tâches de maintenance de routine comme un bogue découvert par un utilisateur ou d'un événement important en soi en fonction de la taille ou de la nature de la maintenance. Voici quelques types de maintenance en fonction de leurs caractéristiques:

Corrective Maintenance - Cela inclut les modifications et les mises à jour effectuées afin de corriger ou de résoudre les problèmes, qui sont soit découverts par l'utilisateur, soit conclus par des rapports d'erreur de l'utilisateur.
Adaptive Maintenance - Cela comprend les modifications et les mises à jour appliquées pour maintenir le produit logiciel à jour et à l'écoute du monde en constante évolution de la technologie et de l'environnement commercial.
Perfective Maintenance- Cela comprend les modifications et les mises à jour effectuées afin de garder le logiciel utilisable sur une longue période de temps. Il comprend de nouvelles fonctionnalités, de nouvelles exigences des utilisateurs pour affiner le logiciel et améliorer sa fiabilité et ses performances.
Preventive Maintenance- Cela inclut les modifications et les mises à jour pour éviter de futurs problèmes du logiciel. Il vise à répondre aux problèmes, qui ne sont pas significatifs pour le moment, mais peuvent causer de graves problèmes à l'avenir.

Coût d'entretien

Les rapports suggèrent que le coût de la maintenance est élevé. Une étude sur l'estimation de la maintenance logicielle a révélé que le coût de la maintenance peut atteindre 67% du coût du cycle complet du processus logiciel.

En moyenne, le coût de la maintenance logicielle est supérieur à 50% de toutes les phases du SDLC. Il existe divers facteurs qui déclenchent des coûts de maintenance élevés, tels que:

Facteurs du monde réel affectant les coûts de maintenance

L'âge standard de tout logiciel est considéré comme allant de 10 à 15 ans.
Les logiciels plus anciens, qui étaient censés fonctionner sur des machines lentes avec moins de mémoire et de capacité de stockage, ne peuvent pas résister aux nouveaux logiciels améliorés sur du matériel moderne.
À mesure que la technologie progresse, il devient coûteux de maintenir les anciens logiciels.
La plupart des ingénieurs de maintenance sont débutants et utilisent une méthode d'essai et d'erreur pour résoudre le problème.
Souvent, les modifications apportées peuvent facilement nuire à la structure d'origine du logiciel, ce qui rend difficile toute modification ultérieure.
Les changements sont souvent laissés sans documentation, ce qui peut entraîner davantage de conflits à l'avenir.

Facteurs de fin de logiciel affectant le coût de maintenance

Structure du programme logiciel
Langage de programmation
Dépendance à l'environnement extérieur
Fiabilité et disponibilité du personnel

Activités de maintenance

IEEE fournit un cadre pour les activités de processus de maintenance séquentielle. Il peut être utilisé de manière itérative et peut être étendu afin que des éléments et des processus personnalisés puissent être inclus.

Ces activités vont de pair avec chacune des phases suivantes:

Identification & Tracing- Il s'agit d'activités relatives à l'identification des besoins de modification ou de maintenance. Il est généré par l'utilisateur ou le système peut lui-même signaler via des journaux ou des messages d'erreur. Ici, le type de maintenance est également classé.
Analysis- La modification est analysée pour son impact sur le système, y compris les implications sur la sûreté et la sécurité. Si l'impact probable est grave, une solution alternative est recherchée. Un ensemble de modifications requises est ensuite matérialisé en spécifications d'exigences. Le coût de modification / maintenance est analysé et l'estimation est conclue.
Design- Les nouveaux modules, qui doivent être remplacés ou modifiés, sont conçus en fonction des spécifications d'exigence définies à l'étape précédente. Les cas de test sont créés pour la validation et la vérification.
Implementation - Les nouveaux modules sont codés à l'aide d'une conception structurée créée lors de l'étape de conception. Chaque programmeur doit faire des tests unitaires en parallèle.
System Testing- Les tests d'intégration sont effectués parmi les modules nouvellement créés. Des tests d'intégration sont également effectués entre les nouveaux modules et le système. Enfin, le système est testé dans son ensemble, suivant des procédures de tests régressifs.
Acceptance Testing- Après avoir testé le système en interne, son acceptation est testée avec l'aide des utilisateurs. Si, dans cet état, l'utilisateur se plaint de certains problèmes qu'il est résolu ou qu'il doit résoudre lors de la prochaine itération.
Delivery- Après le test d'acceptation, le système est déployé dans toute l'organisation soit par un petit package de mise à jour, soit par une nouvelle installation du système. Le test final a lieu à la fin du client après la livraison du logiciel.

Une installation de formation est fournie si nécessaire, en plus de la copie papier du manuel d'utilisation.
Maintenance management- La gestion de la configuration est une partie essentielle de la maintenance du système. Il est accompagné d'outils de contrôle de version pour contrôler les versions, les semi-versions ou la gestion des correctifs.

Réingénierie logicielle

Lorsque nous avons besoin de mettre à jour le logiciel pour le maintenir sur le marché actuel, sans affecter sa fonctionnalité, cela s'appelle la réingénierie logicielle. Il s'agit d'un processus approfondi où la conception du logiciel est modifiée et les programmes sont réécrits.

Les logiciels hérités ne peuvent pas continuer à s'accorder avec les dernières technologies disponibles sur le marché. Comme le matériel devient obsolète, la mise à jour du logiciel devient un casse-tête. Même si le logiciel vieillit avec le temps, ses fonctionnalités ne le sont pas.

Par exemple, au départ, Unix a été développé en langage d'assemblage. Lorsque le langage C est né, Unix a été repensé en C, car travailler en langage d'assemblage était difficile.

En dehors de cela, les programmeurs remarquent parfois que peu de parties du logiciel nécessitent plus de maintenance que d'autres et ont également besoin d'une réingénierie.

Processus de réingénierie

Decidequoi restructurer. S'agit-il d'un logiciel entier ou d'une partie de celui-ci?
Perform Reverse Engineering, afin d'obtenir les spécifications des logiciels existants.
Restructure Programsi nécessaire. Par exemple, changer des programmes orientés fonction en programmes orientés objet.
Re-structure data comme demandé.
Apply Forward engineering concepts afin d'obtenir un logiciel repensé.

Il y a peu de termes importants utilisés dans la réingénierie logicielle

Ingénierie inverse

Il s'agit d'un processus pour atteindre la spécification du système en analysant et en comprenant le système existant. Ce processus peut être vu comme un modèle SDLC inversé, c'est-à-dire que nous essayons d'obtenir un niveau d'abstraction plus élevé en analysant des niveaux d'abstraction inférieurs.

Un système existant est une conception précédemment mise en œuvre, dont nous ne savons rien. Les concepteurs font ensuite de la rétro-ingénierie en examinant le code et en essayant d'obtenir la conception. Avec la conception en main, ils essaient de conclure les spécifications. Ainsi, aller à l'envers du code à la spécification du système.

Restructuration du programme

C'est un processus pour restructurer et reconstruire le logiciel existant. Il s'agit de réorganiser le code source, soit dans le même langage de programmation, soit d'un langage de programmation à un autre. La restructuration peut avoir soit une restructuration du code source et une restructuration des données, soit les deux.

La restructuration n'a pas d'impact sur la fonctionnalité du logiciel mais améliore la fiabilité et la maintenabilité. Les composants du programme, qui provoquent des erreurs très fréquemment, peuvent être modifiés ou mis à jour avec une restructuration.

La fiabilité des logiciels sur une plate-forme matérielle obsolète peut être supprimée via une restructuration.

Ingénierie avancée

L'ingénierie avancée est un processus d'obtention du logiciel souhaité à partir des spécifications en main qui ont été réduites au moyen de l'ingénierie inverse. Cela suppose qu'il y avait déjà du génie logiciel dans le passé.

L'ingénierie avancée est identique au processus d'ingénierie logicielle avec une seule différence - elle est toujours réalisée après l'ingénierie inverse.

Réutilisabilité des composants

Un composant fait partie du code de programme logiciel, qui exécute une tâche indépendante dans le système. Il peut s'agir d'un petit module ou d'un sous-système lui-même.

Exemple

Les procédures de connexion utilisées sur le Web peuvent être considérées comme des composants, le système d'impression dans le logiciel peut être considéré comme un composant du logiciel.

Les composants ont une haute cohésion de fonctionnalité et un taux de couplage plus faible, c'est-à-dire qu'ils fonctionnent indépendamment et peuvent effectuer des tâches sans dépendre d'autres modules.

En POO, les objets conçus sont très spécifiques à leur préoccupation et ont moins de chances d'être utilisés dans d'autres logiciels.

Dans la programmation modulaire, les modules sont codés pour effectuer des tâches spécifiques qui peuvent être utilisées dans de nombreux autres programmes logiciels.

Il existe une toute nouvelle verticale, basée sur la réutilisation de composants logiciels, connue sous le nom de Génie logiciel basé sur les composants (CBSE).

La réutilisation peut être effectuée à différents niveaux

Application level - Lorsqu'une application entière est utilisée comme sous-système d'un nouveau logiciel.
Component level - Où le sous-système d'une application est utilisé.
Modules level - Où les modules fonctionnels sont réutilisés.

Les composants logiciels fournissent des interfaces qui peuvent être utilisées pour établir la communication entre différents composants.

Processus de réutilisation

Deux types de méthode peuvent être adoptés: soit en conservant les mêmes exigences et en ajustant les composants, soit en conservant les mêmes composants et en modifiant les exigences.

Requirement Specification - Les exigences fonctionnelles et non fonctionnelles sont spécifiées, auxquelles un logiciel doit se conformer, à l'aide du système existant, des entrées de l'utilisateur ou des deux.
Design- Il s'agit également d'une étape de processus SDLC standard, où les exigences sont définies en termes de langage logiciel. L'architecture de base du système dans son ensemble et de ses sous-systèmes est créée.
Specify Components - En étudiant la conception du logiciel, les concepteurs séparent l'ensemble du système en composants ou sous-systèmes plus petits. Une conception logicielle complète se transforme en une collection d'un vaste ensemble de composants travaillant ensemble.
Search Suitable Components - Le référentiel de composants logiciels est référencé par les concepteurs pour rechercher le composant correspondant, sur la base des fonctionnalités et des exigences logicielles prévues.
Incorporate Components - Tous les composants correspondants sont emballés ensemble pour les façonner en tant que logiciel complet.