Guide de transition du développement logiciel à la maintenance | ITBE

La transition d’une équipe de développement logiciel à une équipe de maintenance est souvent tenue pour acquise. Les organisations se concentrent tellement sur l’achèvement d’un projet qu’elles oublient qu’il y a des tâches de gestion et de maintenance requises après la mise en œuvre.

Présentation du cycle de vie du développement logiciel (SDLC)

Le SDLC est une méthodologie avec des processus clairement définis qui prennent en charge la création et la mise à niveau d’applications logicielles.

Le SDLC moderne contient sept étapes :

1. Planification: C’est là que les idées fusent et que l’excitation commence. Les équipes définissent les problèmes, réfléchissent à des solutions et commencent à réfléchir à leurs objectifs de développement.
2. Recueil et analyse des besoins : Dans la deuxième étape, les équipes définissent les exigences et déterminent les détails spécifiques du nouveau développement. Il est important de prendre en compte les besoins des utilisateurs finaux, l’intégration avec les systèmes existants et auxiliaires, et les fonctionnalités indispensables par rapport aux fonctionnalités intéressantes.
3. Conception et prototypage : À l’aide d’outils tels que des diagrammes de processus et des prototypes, les équipes de développement travaillent à créer les types de plans qui lanceront et alimenteront la phase de développement.
4. Développement: Dans cette phase, le code est écrit et l’application logicielle prend forme.
5. Essai: Cette phase implique des activités telles que la recherche de bogues, la recherche de défauts et l’apprentissage des lacunes.
6. Implémentation et intégration : Souvent considérées comme la phase finale du SDLC, la mise en œuvre et l’intégration impliquent un certain nombre de tâches qui ont lieu lorsqu’une application logicielle nouvelle ou mise à jour passe à un environnement de production en direct. De plus, des plans de formation des utilisateurs sont exécutés et le matériel est installé.
7. Opérations et maintenance: Une fois qu’une application logicielle est passée en production, les opérations et la maintenance continues commencent. Cela implique de s’assurer que les utilisateurs finaux sont bien pris en charge ainsi que d’identifier le besoin de correctifs et de mises à jour, ce qui peut être un catalyseur qui redémarre le SDLC.

A lire aussi : Étapes pour effectuer un test d’utilisabilité du logiciel

Quatre types de maintenance logicielle

Correctif

La maintenance logicielle corrective est le processus qui maintient une application opérationnelle. Les corrections sont le plus souvent identifiées par les utilisateurs finaux et concernent la conception, la logique ou le code.

Adaptatif

Les modifications apportées à votre environnement peuvent avoir un impact sur les applications logicielles qui y sont exécutées. Cela peut être lié à des mises à jour matérielles, à des mises à jour du système d’exploitation ou à des modifications de l’infrastructure. Les changements environnementaux peuvent également inclure des changements de fournisseur, des connexions à des systèmes auxiliaires nouveaux ou existants, ou même des politiques liées à la sécurité ou à la conformité de l’industrie.

Perfectif

Les modifications de maintenance logicielle parfaites sont généralement évolutives. Lorsque les utilisateurs finaux se mettent au travail avec une application logicielle, ils commencent à créer des listes de souhaits avec de nouvelles fonctionnalités. Dans certains cas, la suppression des fonctionnalités inutiles ou redondantes est également une fonction de maintenance logicielle parfaite.

Préventif

La maintenance logicielle préventive s’apparente à un pansement technique. Cela implique des modifications plus petites et incrémentielles nécessaires pour adapter les applications logicielles, afin qu’elles puissent fonctionner plus longtemps.

A lire aussi : Utilisation de diagrammes de couloirs de natation pour améliorer le développement de logiciels

Meilleures pratiques : transférer un projet des équipes de développement aux équipes de maintenance

Transférer un projet d’une équipe de développement à une équipe de maintenance peut être complexe et difficile, quelle que soit sa taille. Heureusement, il existe quelques bonnes pratiques à suivre pour toutes les transitions.

Identifier les chefs d’équipe

Les responsables de l’équipe de projet, qui peuvent inclure des responsables du développement, des analystes commerciaux et d’autres parties prenantes, doivent être identifiés et maintenus en contact avec les responsables de l’équipe de maintenance. Savoir à qui s’adresser pour prendre des décisions et des conseils peut aider à atténuer les risques et à assurer une transition en douceur.

Les chefs d’équipe doivent discuter si la nouvelle application logicielle aura un impact ou modifiera les SLA existants (contrats de niveau de service).

Budget pour la transition

N’oubliez pas d’inclure la transition du développement à la maintenance dans le budget de votre projet. Ce processus ne doit pas être précipité ou une réflexion après coup. Assurez-vous que les parties prenantes comprennent l’importance d’un plan de soutien approprié.

Ce budget peut également inclure la nécessité d’ajouter du personnel de soutien supplémentaire qui sera nécessaire après la mise en œuvre.

Commencer de bonne heure

Évitez l’approche drop-and-run pour faire passer les projets du développement à la maintenance. Permettez aux équipes de maintenance de suivre les équipes de développement bien avant que les choses ne soient terminées, incluez les équipes de maintenance dans les réunions et la correspondance pertinente, et informez tout le monde des décisions importantes.

En incluant les membres de l’équipe de maintenance dès le début, les équipes de développement auront également la possibilité de mieux comprendre l’état actuel de l’architecture existante et des applications logicielles actuellement utilisées par une organisation.

Communication

N’oubliez pas que l’équipe de maintenance peut ne pas comprendre pourquoi les décisions ont été prises, les priorités ont été définies ou comment les besoins ont été identifiés. En communiquant ces types de détails, les équipes de maintenance peuvent mieux prendre en charge l’application logicielle et faire preuve d’empathie et d’appropriation lorsqu’elles doivent répondre aux futures questions des utilisateurs finaux.

Documentation

La documentation est une partie essentielle du processus de support. Les professionnels de la technologie qualifiés apprennent à deviner les détails qui doivent être documentés pour aider à guider les tâches de support plus tard. Pensez aux utilisateurs finaux qui peuvent rechercher des justifications pour la manière dont les fonctionnalités ont été implémentées, et considérez les raisons pour lesquelles les décisions ont été prises.

Un avantage secondaire d’une documentation complète se fera sentir avec les futurs efforts de développement. Ne présumez pas que les mises à jour ou les corrections de bogues seront toujours effectuées par les mêmes développeurs.

Éléments de documentation à inclure :

• Aperçu
• Références
• Hypothèses
• Contacts
• Accords et licences
• Diagrammes et prototypes avec listes et résumés fonctionnels et de fonctionnalités
• Détails de la configuration, tels que la structure des répertoires et les fonctions d’administration
• Détails opérationnels tels que le démarrage, l’arrêt, la sauvegarde, la restauration et l’archivage
• Détails de sécurité

Le transfert de connaissances

La documentation seule ne suffit pas, bien qu’elle fasse partie du processus de transfert des connaissances. L’astuce consiste à comprendre et à respecter les rôles de chacun dans chaque équipe, sachant que chacun possède une expertise en la matière qui peut ne pas être connue de l’autre.

Encouragez les questions et les conversations continues. Il peut y avoir des choses auxquelles les autres n’ont pas pensé ou des systèmes tiers qui peuvent sans le savoir avoir un impact ou être impactés par une implémentation proposée.

Les deux équipes sont importantes

Aucune équipe n’est inférieure à. Avoir du respect pour le travail effectué par chaque équipe aidera à voir la valeur du service que chacun fournit.

Chevauchement

Dans la mesure du possible, assurez-vous que le processus de transition inclut du temps dans le calendrier pour un petit chevauchement. Au fur et à mesure que les demandes d’assistance commencent à filtrer, il peut être utile de disposer d’une ressource à laquelle l’équipe de maintenance peut faire appel pour obtenir des conseils et de l’aide.

Cela dit, assurez-vous que la période de temps pour ce service est clairement définie et communiquée. Avoir une ligne claire tracée contribue au sentiment d’appartenance et permet aux deux équipes d’avancer correctement.

Apprenez de chaque transition

Même si chaque projet de développement logiciel est différent, avec une portée et une complexité variables, le processus de transition peut être standardisé et appris. Les équipes de maintenance doivent organiser des réunions post-implémentation et de transition pour discuter des leçons apprises et consolider les meilleures pratiques.

Documentez les questions que vous auriez aimé poser et les délais que vous auriez aimé concevoir différemment, et apportez ces connaissances et cette expérience à la prochaine transition.

Lire ensuite : Comment choisir une méthodologie de développement logiciel : 6 approches