Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 2 – Les processus de la maintenance La vision traditionnelle du cycle

Chapitre 2 – Les processus de la maintenance La vision traditionnelle du cycle de vie du logiciel a desservie la maintenance en la décrivant uniquement comme une seule étape à la fin du cycle. Par conséquent, la maintenance des logiciels devrait avoir son propre modèle de cycle de vie. Trois caractéristiques communes des modèles CVML sont trouvées dans la littérature :  comprendre le code ;  la modification du code ; et  revalidation du code. D'autres modèles considèrent le développement de logiciels en tant que processus itératifs et basés sur l’idée de « changement mini-cycle » (change mini-cycle en anglais).  Modèles itératifs. Les modèles itératifs partagent l’idée qu’un ensemble complet de besoins relatifs à un système ne peuvent pas être complètement compris, ou les développeurs ne savent pas comment construire le système complet. Par conséquent, les systèmes sont construits en versions, dont chacune est un raffinement des exigences de la version précédente. Une construction est affinée en tenant compte de la rétroaction des utilisateurs.  changement mini-cycle. Ces modèles se composent de cinq grandes phases : demande de changement, analyser et planifier le changement, mettre en œuvre le changement, vérifier et valider, et le changement de la documentation. Dans ce modèle de processus, plusieurs activités importantes ont été identifiées, telles que la compréhension du programme, l'analyse d'impact, le refactoring, et la propagation du changement. Un autre type de modèle d'évolution du logiciel, appelé modèle de maintenance et d’évolution à étapes proposé par Rajlich et Bennett1. Son objectif principal est d'améliorer la compréhension de l’évolution des logiciels de longue durée de vie. Le modèle considère quatre étapes successives, distinctes de la durée de vie d'un logiciel : 1. Le développement initial. Lorsque la version initiale du système est produite, à ce stade l’architecture du système émerge et se stabilise rapidement. 2. L’Évolution. Après la stabilité initiale, il est facile d'effectuer des modifications simples au système. Des changements importants impliquent un coût plus élevé et un risque plus élevé. 3. L’Entretien. Les développeurs se concentrent principalement sur les tâches de maintenance, telles que la correction de bugs, alors que les modifications architecturales sont rarement effectuées. 4. Retrait. L'organisation décide de remplacer le système pour diverses raisons : (i) il est trop coûteux d’entretenir le système ou (ii) il existe une solution plus récente disponible. Passer d'un système existant difficile à maintenir à un système de solution moderne a ses propres défis impliquant la préparation et la migration des données. 1. Réingénierie (REENGINEERING) : La Réingénierie implique un cycle unique consistant à générer un nouveau système à partir d’un système existant. 1 V. T. Rajlich and K. H. Bennett. 2000. A staged model for the software life cycle.IEEE Computer, July, pp. 2–8 Reengineering= Reverse engineering + Δ + Forward engineering. Le premier élément "reverse engineering" est l'activité de la définition d'une représentation plus abstraite et plus facile à comprendre du système. Par exemple, si l’entrée du processus de reverse engineering est le code source du système, la sortie sera l'architecture du système. Le troisième élément " Forward engineering " est le processus traditionnel qui permet de passer d'une abstraction de haut niveau, à l’implémentation physique du système. Le deuxième élément représente les modifications effectuées au système d'origine. 2. LEGACY SYSTEMS Un « legacy system » est un ancien logiciel qui continue d'être utilisé parce qu’il répond toujours aux besoins des utilisateurs, en dépit de la disponibilité des technologies plus récentes ou de méthodes plus efficaces d'exécution de la tâche. Plus souvent, un Legacy system comprend des procédures ou une terminologie obsolète, et il est très difficile pour les nouveaux développeurs de comprendre le système. Pour gérer les Legasy systems, un certain nombre d'options sont disponibles.  Gel. Une organisation décide de ne pas effectuer d'autres travaux sur un Legacy system. Cela implique que soit les services du système ne sont plus nécessaires ou un nouveau système remplace complètement un système existant. Une organisation peut décider que le support du legacy system ne fait plus partie de sa spécialisation.  Effectuer la maintenance. Dans cette approche, l'organisation continue à maintenir le système pour une autre période de temps, malgré toutes les difficultés à le faire.  Abandonner et redévelopper. Dans cette approche, le logiciel est redéveloppé de nouveau à partir de zéro, en utilisant de nouvelles plates-formes matérielles et logicielles.  Encapsulation. Dans cette approche, un Legacy system est encapsulé par une nouvelle couche logicielle, cachant ainsi la complexité indésirable des données existantes, des programmes individuels, et des interfaces. L'ancien système exécute les calculs actuels, mais les utilisateurs interagissent avec le système de façon conviviale.  Migration. Dans cette approche, un Legacy system opérationnel est déplacé vers un nouveau matériel et / ou plate-forme logicielle, tout en conservant la fonctionnalité du Legacy system. 3. ANALYSE D’IMPACT L'analyse d'impact est la tâche d'identification des parties du logiciel qui peuvent potentiellement être affectés si un changement proposé au système est effectué. Le résultat de l'analyse d'impact peut être utilisé lors de la planification des changements, durant les changements, et le suivi des effets des changements afin de localiser les sources de nouvelles failles. Les techniques de l’analyse d'impact peuvent être classées en deux catégories comme suit :  Analyse de traçabilité. Dans cette approche, les artefacts de haut niveau, comme les besoins, la conception, le code, et les cas de tests liés à la fonction à modifier, sont identifiés. Un modèle d'associations entre artefacts, de telle sorte que chaque artefact soit lié aux autres artéfacts, est construit. Cela aide à localiser les parties correspondantes de la conception, du code et de cas de test qui doivent être maintenus.  Analyse de la dépendance. l'analyse de dépendance tente d'évaluer les effets d'une modification au niveau des dépendances sémantiques entre les entités de programme. Ceci est réalisé en identifiant les dépendances syntaxiques qui peuvent signaler la présence de telles dépendances sémantiques. Les deux techniques d'analyse d'impact basée sur les dépendances sont : l’analyse basée sur le graphe d’appel et l’analyse de graphe de dépendances. L’analyse des dépendances est aussi connue sous le nom de l'analyse du code source. 1.4 LE REFACTORING Le Refactoring consiste à effectuer des changements à la structure du système logiciel pour le rendre plus facile à comprendre et moins coûteux par rapport aux modifications ultérieures sans modifier le comportement du système. Le Refactoring est réalisé par la suppression du code dupliqué, la simplification du code, et le déplacement du code à une autre classe. Il peut être réalisé sans ajouter de nouvelles exigences au système existant. Dans les méthodologies logicielles agiles, tels que eXtreme Programming (XP), le refactoring est appliqué en continu pour : (i) stabiliser l'architecture du logiciel ; (Ii) rendre le code lisible; et (iii) rendre les tâches d'intégration de nouvelles fonctionnalités dans le système plus flexibles. Les techniques de refactoring mettent l'accent sur le développement d'une liste de refactoring de base, qui peuvent être combinés pour former un refactoring complexe. La liste originale des refactoring de base contenant des transformations sur le code orienté objet : (i) ajouter une classe, une méthode ou un attribut ; (ii) renommer une classe, une méthode ou un attribut ; (Iii) déplacer un attribut ou méthode de haut ou en bas de la hiérarchie ; (Iv) supprimer une classe, une méthode ou un attribut ; et (v) extraire des morceaux de code dans des méthodes distinctes. 1.5 COMPEHENSION DU PROGRAMME Le but de la compréhension du programme est de comprendre un système logiciel existant pour la planification, la conception, le codage, et les changements de test. T. A. Corbi 2 a constaté en 1989 que la compréhension du programme compte pour 50% de l’effort total dépensé tout au long du cycle de vie d'un système logiciel. Dans le domaine de la compréhension du programme, un modèle mental décrit la représentation mentale du programmeur sur le programme à comprendre. Une étape clé dans le développement de modèles mentaux est la génération des hypothèses ou des conjectures, et de vérifier leur validité. Les hypothèses sont un moyen pour le programmeur pour comprendre le code d'une manière progressive (incrémentale). Après une certaine compréhension du code, le programmeur fait une hypothèse et la vérifie par lecture de code. La vérification de l'hypothèse consiste soit à accepter l'hypothèse ou à son rejet. On peut appliquer plusieurs stratégies pour arriver à des hypothèses significatives, telles que bottom-up, top-down, ou des combinaisons des deux stratégies. Une stratégie bottom-up fonctionne en commençant par le code, alors qu'une stratégie descendante fonctionne en travaillant à partir d'un objectif de haut niveau. 1.6 Réutilisation de logiciel Le « software reuse » signifie l’utilisation du savoir logiciel existants ou des artefacts de logiciels existants lors du développement d'un nouveau système. Les parties réutilisables peuvent inclure des artefacts et le savoir logiciel. A noter que la réutilisation ne se limite pas à des fragments de code source. Capers Jones3 a identifié quatre grands types d'artefacts pour la réutilisation :  la réutilisation des données : Cela implique une normalisation du format de données. Les fonctions uploads/Management/ chapitre-2-bis-premier.pdf