DEVELOPPEMENT LOGICIEL INTRODUCTION AUX METHODES DE SUPERVISION SDLC Partie 1

#processusdedeveloppementproduit #formation # gestiondeprojet

INTRODUCTION

Qu’il soit destiné à répondre aux besoins de votre propre entreprise ou à ceux d’une autre, développer un logiciel est une aventure palpitante qu’il vaut mieux maîtriser, compte tenu des ressources humaines, techniques, temps... investies et les risques encourus en cas d’échec.

Les méthodes SDLC (Software Development Life Cycle), ont toutes pour ambition de définir un cadre permettant de gérer de façon optimal le cycle de vie complet du développement d’un logiciel. L’objectif est double: aboutir à un produit de qualité pour les utilisateurs et optimiser les ressources consommées pour le créer.

Au cours du temps, la famille des SDLC c’est enrichie de nombreux membres: Méthode Agile, en cascade, itérative, DevOps, Spirale, en V, Big Bang… Pour mieux comprendre cette drôle de tribu, revenons, dans cette première partie, sur les fondamentaux du cycle de vie d’un développement logiciel…

CYCLE DE VIE D’UN DEVELOPPEMENT LOGICIEL

Développer un logiciel ou le faire évoluer est un investissement en compétences, équipements, temps, argent, etc. Donc lorsqu’on décide de le faire, pour son entreprise ou celles des autres, c’est parce qu’on en espère un retour sur investissement.

L’approche SDLC guide les différents métiers impliqués: marketing, développement, qualité, design, support, management, documentation... Etape par étape, la méthode permet de progresser sur le chemin qui mène de l’idée initiale jusqu’au logiciel en fonctionnement.

En créant un guide, mais aussi un vocabulaire et des procédures communes, c’est un outil qui rassemble. Son but est de limiter les défauts, oublis, retards... qui peuvent entraver tout processus de développement et ceci quelque soit l’ampleur du projet. Le SDLC Veille à ce que toutes les parties prenantes donnent leur avis et collaborent, dès les premières phases du projet.

C’est quoi un cycle de vie d’un développement logiciel?

On peut le résumer à une histoire en 7 phases:

1. Phase POURQUOI FAIRE? Cette première étape consiste à collecter les exigences auxquelles le futur logiciel devra apporter une réponse de qualité. Les anglo-saxons la nomment souvent ‘Requirements and Analysis’
2. Phase QUOI? Elle permet de passer du rêve à la réalité. Elle transforme le cahier initial des charges en un document de spécifications. C’est à dire la bible du projet du futur logiciel. Pour les anglo-saxons, cette phase est souvent nommée ‘Defining’ ou encore ‘specifications’
3. La phase COMMENT? Permet de concevoir l’architecture générale et détaillée du futur logiciel. Cette phase de conception permet de structurer l’ensemble, prévoir les échanges et les formats entre les composantes, etc. En anglais ‘Design’ ou encore ‘software architecture’.
4. La phase DEVELOPPEMENTConsiste à traduit le résultat de la phase de conception en un logiciel programmé avec le ou les langages de programmation choisis. En anglais ‘Development’ ou encore ‘implementation’.
5. La phase VALIDATION Intégrer les différentes parties du code et s’assurer que le produit réponds aux objectifs de qualité, performances, fonctionnalités… fixées et ceci, grâce à une batterie de tests préparés par l’équipe qualité, voici l’objectif de cette étape. ‘Testing and integration’ pour nos amis anglo-saxon.
6. La phase de DEPLOIEMENT Correspond à l’étape de déploiement sur le terrain et la prise en main par les utilisateurs. ‘Deployment’ en anglais.
7. La phase de MAINTENANCE Au cours de l’exploitation d’un logiciel, des dysfonctionnements vont faire surface. Transmis à l’équipe de support, ils vont être catalogués et analysés pour en découvrir la source. En fonction du niveau de criticité, le problème est résolut et un patch correctif appliqué immédiatement ou bien inclus dans une future mise à jour.

1. Phase POURQUOI FAIRE?

Avant de se lancer à travailler sur un projet de développement logiciel, il est impératif de prendre le temps de comprendre ce que l’utilisateur final veut faire et comment. Cela revient donc à faire la liste exhaustive des fonctionnalités du futur outil. Mais aussi la manière de le faire. A cela, il faut rajouter toutes les contraintes devant être respectées.

Il faut aussi penser à étudier les logiciels déjà existants ou annoncés dans un proche avenir.

Le volet financier ne doit pas non plus être négligé. Si on souhaite commercialiser le futur logiciel alors une étude financière rigoureuse s’impose: prix de vente, date idéale de mise sur le marché, canaux de promotion comme de distribution, packaging, volume des ventes envisageable, durée de vie…

L’objectif est d’offrir un panorama, le plus exhaustif possible, du futur produit ou évolution du produit et son environnement, grâce à un travail en amont mené par l’équipe marketing. Ce travail s’appuie sur des études autour du marché ciblé, d’une veille concurrentielle, la consultation d’un panel d’utilisateurs, de vendeurs, programmeurs, techniciens... les opportunités technologiques ou législatifs à venir, etc.

La première phase consiste donc à coucher sur le papier, le profil du produit idéal pour satisfaire les utilisateurs et permettre à l’entreprise de se développer. A l’issue de ce brainstorming, un cahier des charges doit émerger. Il peut être utiliser pour poursuivre le projet en interne ou lancer une consultation auprès de fournisseurs.

Il est important de garder à l’esprit que cette première phase peut aussi être la dernière. En effet, si cette réflexion aboutit à la conclusion qu’il existe déjà un logiciel répondant à tout ou à une large partie des exigences identifiées ou que le coût ou les bénéfices espérés ne sont pas en adéquation avec l’investissement, alors il peut s’avérer raisonnable d’arrêter l’aventure…

2. Phase QUOI?

La seconde phase consiste à passer du rêve à la réalité et transformer le cahier des charges en document des spécifications. Grâce à un travail poussé pour parfaitement délimiter le champs des exigences, les analystes vont réaliser une étude de faisabilité passant au crible toutes les facettes du projet en termes de technicité, d'exploitation, d'économie, de législation, de calendrier, de coût, de risques etc..

Ce document a pour but de servir de référence pour garder les équipes impliquées dans le développement et l’exploitation, mais aussi les utilisateurs et les décideurs... sur la même longueur d'onde.

La communication et la collaboration sont les clés de la réussite de cette phase stratégique. Un travail de synthèse doit aboutir à la rédaction de plusieurs documents clés: le document des spécifications mais aussi un premier jet du planning et du budget nécessaire.

A la lumière de ces documents, les instances décisionnaires doivent pouvoir établir si les délais, coûts et spécifications sont en adéquation avec le cahier des charges et la stratégie de l’entreprise et ainsi passer à la phase suivante, ou bien si le projet doit être arrêté ou la phase prolongée pour un complément d’analyse.

3. Phase COMMENT?

La phase suivante va permettre à l‘équipe de planifier la meilleure façon de créer le logiciel. L'objectif est d'optimiser le processus de création en fonction du coût, de la vitesse, du temps, des ressources disponibles et autres facteurs, tout en respectant les exigences des utilisateurs finaux.

À cette étape, l'équipe doit affiner les estimation de coût, planning, ressources et efforts pour mener à bien le projet. Cette phase implique également l'identification des risques et les moyens de les minimiser. La partie de l’équipe impliquée dans la future phase de validation et celle de support, doivent être étroitement associées. De cette façon, l'équipe peut déterminer la meilleure façon de produire le logiciel avec le moins de risques, de dépenses et de temps.

Un document d’architecture générale permet de préparer la phase suivante de développement. Il couche sur papier et dans les esprits, un descriptif des infrastructures logicielle et système, des interface(s) utilisateur(s), des bases de données, modules optionnels ou futurs...... flux de données circulant entres les composants… Il permet de s’assurer que tous les éléments fonctionnels et non fonctionnels seront couverts. En prenant le temps de créer une architecture évolutive, on peut aussi poser les jalons d’extension ou de personnalisation futurs.

Un document d’architecture détaillée complémentaire permet de coucher les détails de la conception interne des composants et des données entrantes et sortantes.

Ces documents ont aussi pour vocation d’identifier d’éventuels oublis pouvant entraîner des modifications coûteuses.

4. Phase DEVELOPPEMENT

A ce stade, l’équipe développe et assemble des composants en fonction des décisions prises lors des phases précédentes. Des choix correctifs peuvent être apportés en cas de problèmes ou de risques ayant échappés à la vigilance de l’équipe projet.

La rédaction d’un plan de Validation doit permettre d’imaginer les tester à appliquer au futur logiciel et ses composants, fin de s’assurer qu’ils répondent en tout point au document de Spécifications.

5. Phase de VALIDATION

La batterie de tests, imaginée dans le plan de validation, est appliquée afin de garantir la qualité, les performances, les fonctionnalités… attendues.

En cas d’identification d’erreurs, dysfonctionnements, contres-performances… des modifications correctives sont appliquées. Dans certain cas, une campagne de distribution de bêta-versions peut compléter cette phase de validation.

6. Phase de DEPLOIEMENT

Après avoir testé le logiciel et résolu les problèmes, il est prêt à être déployé dans l'environnement de production. Dans le cas d’un logiciel destinée à un client particulier, ce déploiement s’accompagne d’une recette avant acceptation par l’entreprise cliente. Durant cette phase, des actions de formation, à destination des utilisateurs finaux, peuvent être menées.

7. Phase de MAINTENANCE

Malgré tous les tests de validation pratiqués en amont, le fonctionnement du logiciel va s’accompagner d’incidents. Le rôle de la maintenance est de recenser ces dysfonctionnements, identifier le niveau de criticité et l’origine de chaque problème pour ensuite s’assurer qu’ils soient corrigés. On appelle cela de la maintenance corrective.

Lorsque des améliorations ou de nouvelles fonctionnalités sont nécessaires, se pose la question de l’ampleur des modifications demandées. Lorsqu’elles sont conséquentes, elles peuvent aboutir au lancement d’un nouveau cycle SDLC.

CONCLUSION

L’utilisation d’un SDLC est souvent perçu comme un carcan, lors de son déploiement. Cela oblige chaque personne impliquée à modifier ses habitudes et donc perçu comme une perte de temps et de repaires. Un management totalement impliqué et moteur est donc une condition nécessaire à une mise en œuvre réussie. En retour, le déploiement d’un SDLC apporte une valeur ajoutée à un projet de développement logiciel :

• Optimisation Le travail commun réalisé sur les ressources (humaines, techniques ou financières et le planning) nécessaires au futur logiciel permet une évaluation, optimisation et une gestion du projet plus efficace. Cela peut se traduire par un ROI plus rapide.
• Lisibilité Le SDLS permet au management de superviser et de suivre plus facilement l'évolution du développement.
• Coordination et anticipationSi chacun maîtrise le déroulé du cycle de vie, il sait ce qu'il faut prévoir et comment s’y préparer.
• FédérationLe SDLC permet de briser les barrières entre équipes – Il bâtit un pont entre les métiers, en instaurant une culture, un vocabulaire, des procédures communes et la nécessitée d’une communication et d’une coopération
• Transparence En offrant une meilleure vision et compréhension des responsabilités et des tâches de chacun, le SDLC est un outil contribuant à une meilleur participation et implication de chacun

A SUIVRE...

Dans la seconde partie de cet article, nous survolerons les principales méthodes mettant en œuvre les bases du SDLS.

Je suis Formatrice et consultante. Si vous souhaitez faire appel à mon expérience pour former vos collaborateurs ou vos étudiants, contacter moi pour en parler - 06 63 07 67 19