De la même manière que les êtres humains traversent différentes étapes au cours de leur vie, les produits logiciels suivent eux aussi différentes étapes. C’est ce que l’on appelle souvent le cycle de vie d’une version logicielle.
Des périodes précises sont associées aux différentes phases du cycle de vie, ou « étapes du développement », des applications, mais il peut être difficile de prévoir quand une phase se termine et qu’une autre commence. Chaque phase possède son propre ensemble distinct de tâches et d’exigences pour les différents services, il est donc important que les chefs de produit comprennent chaque phase afin de guider efficacement l’entreprise tout au long du cycle de vie d’une version logicielle.
Au fil de cet article, j’ajouterai des commentaires sur mon expérience de la vente et de l’intégration de BankerBox, une entreprise SaaS de technologie financière destinée aux banquiers d’investissement, dans SS&C Intralinks avec mon cofondateur, en les reliant aux différentes phases du SRLC.
Qu’est-ce que le cycle de vie d’une version logicielle (SRLC) ?
Le cycle de vie d’une version logicielle (SRLC) est un ensemble de jalons qui décrivent les différentes étapes du cycle de vie d’un logiciel ou de sa chronologie de publication successive, de sa conception jusqu’à sa version finale entièrement aboutie. La durée de ce cycle de vie varie en fonction de plusieurs facteurs, tels que le type de produit, son utilisation prévue, ainsi que les exigences de sécurité, de conformité et les normes générales du secteur.
Par exemple, les applications logicielles ont généralement un cycle de vie plus court que la plupart des autres produits, car de nouvelles fonctionnalités et améliorations sont fréquemment publiées selon une méthode Agile afin de répondre à l’évolution des demandes du marché et aux nouvelles tendances technologiques.
Il est similaire au cycle de vie du développement logiciel (SDLC), qui constitue une structure appliquée au développement des produits logiciels. La différence entre ces deux cycles de vie est que le SDLC décrit uniquement le processus de développement logiciel et la conception du logiciel, tandis que le cycle de vie d’une version décrit non seulement son développement, mais aussi son utilisabilité, ses tests et sa distribution.
Les versions logicielles doivent être soigneusement planifiées et testées, idéalement par une équipe de test, afin de s’assurer qu’elles ne causent pas plus de problèmes qu’elles n’en résolvent. Un cycle de vie de version logicielle établit un plan clair pour mener à bien le processus de publication grâce à une planification appropriée, aux tests et aux corrections de bogues.
Les entreprises devraient utiliser le cycle de vie d’une version logicielle pour anticiper quand et comment elles mettront à jour leur application web ou leurs applications au fil du temps. La mise en œuvre de bonnes pratiques de gestion des versions leur permet de maintenir un produit robuste qui répondra continuellement aux besoins de ses utilisateurs, aux fonctionnalités essentielles et aux normes du secteur (c’est également un aspect pour lequel l’IA dans la gestion des versions peut être utile). Cela leur permet de maintenir un produit robuste qui répondra continuellement aux besoins de ses utilisateurs, aux fonctionnalités essentielles et aux normes du secteur.
Les 6 étapes du cycle de vie d’une version logicielle
Il existe différentes étapes dans les cycles de vie des versions logicielles, qui peuvent être utilisées en fonction du type de système développé et des besoins de l’équipe de développement.
Les « étapes » marquent des jalons dans le développement d’un produit et permettent à l’équipe de développement ainsi qu’aux chefs de projet de suivre les progrès. Elles permettent également aux équipes de développement de suivre les tendances dans les applications et les applications web, et de vérifier que des améliorations sont apportées au fil des itérations. Il comprend généralement les six phases suivantes :
Have an account? Log In
1. Version pré-alpha
La première étape du cycle de vie d’une version logicielle est la pré-alpha. Cette étape du processus est entièrement axée sur le développement d’un produit plutôt que sur sa commercialisation et sa mise à disposition du public. Elle couvre toutes les actions réalisées au cours du développement initial, avant les tests. Les phases les plus courantes de la pré-alpha sont l’analyse, la conception, le développement et les tests unitaires.
Une grande partie de la version pré-alpha consiste à déterminer comment l’application logicielle doit évoluer afin de se préparer à des versions plus largement diffusées, comme la version alpha ou la version bêta. L’équipe de développement doit mettre en place des processus solides de test logiciel, d’utilisabilité et d’automatisation afin de garantir des transitions stables entre les différentes phases du cycle de vie d’une version logicielle.
Avec la solution SaaS que mon cofondateur et moi avons intégrée à SS&C Intralinks, nous avions déjà évalué et achevé la phase pré-alpha. Nous disposions d’une application fonctionnelle, dont l’architecture, la conception et la réalisation étaient terminées. Il est toutefois important de noter que la définition des étapes d’analyse, de conception, de développement et de tests unitaires dans une petite entreprise de logiciels peut absolument différer de la perspective d’une grande entreprise et du niveau de rigueur qu’elle applique à ces étapes.
4 phases pour lancer la version pré-alpha
Analyse : il s’agit de la phase initiale du cycle de vie d’une version logicielle, ou SRLC, qui consiste à étudier en détail le problème et les exigences d’un système. Elle comprend l’analyse des exigences des utilisateurs, des fonctionnalités essentielles, l’identification du domaine problématique, la préparation de rapports de faisabilité et la création d’un SRS (document de spécification des exigences logicielles).
Conception : à cette étape, les équipes de développement élaborent une solution au problème identifié lors de l’étape d’analyse. Cette étape comprend la rédaction d’un document de conception de haut niveau et de maquettes expliquant comment mettre en œuvre le produit logiciel. Le document de conception présente les étapes de base à suivre pour créer l’application web.
Si vous travaillez sur des mises en page ou des flux d’interface utilisateur, ces outils de prototypage de conception adaptative peuvent vous aider à tester rapidement vos idées avant de passer au développement. Le document de conception présente les étapes de base à suivre pour créer l’application web.
Développement : il s’agit de la phase de codage proprement dite, au cours de laquelle une équipe de développement transforme les spécifications des exigences en un véritable produit logiciel. Une fois le codage terminé, les développeurs effectuent des tests et corrigent les bogues le plus tôt possible.
Tests unitaires : ceux-ci sont réalisés par les développeurs avant la transmission de leur module à l’équipe de développement chargée de l’assurance qualité (assurance qualité) pour la suite du processus de test. Au cours de cette phase, les développeurs vérifient chaque ligne du code source afin de s’assurer que le code fonctionne correctement avant son intégration à l’ensemble de l’application.
2. Version alpha
Le stade alpha représente la première lettre de l’alphabet grec et constitue également un nom de code pour la phase de développement qui a lieu avant le lancement d’un produit. Les développeurs de logiciels utilisent le terme "alpha" ou “version alpha” pour désigner un logiciel qui se trouve dans sa première phase de test.
Les tests alpha sont effectués par des employés internes ou des développeurs au sein de l’organisation. Ce type de test est réalisé sur le site du développeur, mais pas sur celui du client. Les tests alpha sont menés après l’achèvement des tests du système et avant les tests bêta. Ils servent à détecter les bogues ou les défauts liés à l’ergonomie, aux fonctionnalités et à la cohérence.
Dans ce type de test, un groupe de personnes appelées « testeurs » effectue des opérations similaires à celles des utilisateurs finaux, puis signale les problèmes rencontrés. L’objectif principal des tests alpha est de s’assurer que tous les modules sont correctement intégrés et fonctionnent comme prévu.
Lorsque nous avons franchi l’étape alpha pour BankerBox, nous avons contacté des pairs travaillant dans les domaines des produits et des logiciels ainsi que, dans notre cas (la création d’une solution pour les banques), plusieurs banquiers d’affaires et contacts de la haute finance.
Un logiciel alpha dispose de toutes ses fonctionnalités, mais est susceptible de comporter des bogues. L’objectif des tests alpha est d’améliorer un produit en détectant les problèmes avant son passage aux tests bêta et en ajoutant les dernières modifications suggérées par les retours de la phase alpha.
3. Version bêta
Le stade bêta, nommé d’après la deuxième lettre de l’alphabet grec, est le nom de code utilisé pour indiquer qu’un produit logiciel est passé à sa deuxième phase de test et qu’il est prêt à être utilisé par des clients ou des consommateurs externes, souvent appelés « testeurs bêta ». Certaines organisations désignent cette phase comme la phase des « premiers utilisateurs ».
Une fois une version bêta publiée, elle fait généralement l’objet de tests plus approfondis que lors de sa phase alpha. Elle permet aux entreprises d’évaluer les performances de leur logiciel dans des conditions réelles.
Une fois que SS&C Intralinks a acquis BankerBox, nous avons rapidement créé plusieurs points d’intégration clés entre notre logiciel et les systèmes plus larges de l’entreprise (authentification, serveurs cloud, etc.). Nous avons ensuite présenté une démonstration et collaboré avec plusieurs clients de l’entreprise afin de les inviter à « tester en bêta » cette solution en direct dans le cadre d’une opération de fusion-acquisition.
C’était un excellent moyen pour nous d’obtenir des retours, de développer une relation avec les clients et d’identifier les domaines dans lesquels le logiciel devait évoluer afin de satisfaire aux exigences et au « niveau attendu » pour une version candidate (RC) ou une disponibilité générale (GA).
Dans ce type de test, les clients fournissent des retours précieux sur la capacité du produit ou de l’application à répondre à leurs attentes en matière de fonctionnalités, d’ergonomie, de performances, de fiabilité, d’évolutivité, etc. Les retours des utilisateurs finaux contribuent à améliorer l’expérience utilisateur et à corriger les problèmes opérationnels avant la mise en production du produit. Il existe deux types de phase bêta :
- Bêta ouverte : au cours de cette phase, toute personne souhaitant participer au processus de test bêta peut le faire. Cela peut aider les développeurs à identifier et à corriger rapidement et facilement les bogues de leur produit, car les retours de plusieurs utilisateurs peuvent mettre en évidence certains problèmes.
- Bêta fermée : au cours de cette phase, un marché cible précis comprend des groupes spécifiques de personnes qui jouent le rôle de testeurs. Le marché cible permet de concentrer les tests du logiciel sur des domaines problématiques spécifiques et de s’assurer que tout fonctionne selon les besoins des consommateurs ciblés.
4. Version candidate
Une version candidate (RC) est une version préliminaire du logiciel préparée en vue de sa version finale (au cours de la phase RC) destinée au public. On parle parfois de « disponibilité contrôlée ». Bien qu’elle puisse inclure toutes les fonctionnalités prévues et fonctionner comme attendu, elle reste susceptible d’être modifiée, parfois même de manière radicale, en fonction des retours reçus.
Les développeurs peuvent publier plusieurs versions candidates avant de commercialiser le produit final afin de s’assurer que le programme ne plante pas sous une forte charge, qu’il n’entraîne pas de fuite mémoire importante, etc.
5. Disponibilité générale
La disponibilité générale (GA) signifie qu’un produit ou un service a été rendu disponible à l’achat pour la plupart des clients (généralement à l’échelle mondiale), habituellement par l’intermédiaire de canaux commerciaux. En ingénierie logicielle, cette expression désigne généralement une application web ou une application disponible pour tous les utilisateurs prévus. Au cours de cette phase, toute mise à jour ou tout travail de développement supplémentaire sur le produit vise à améliorer ses fonctionnalités et ses performances afin de le rendre plus attrayant pour les clients.
Une fois que BankerBox, désormais « Marketing des offres » sous son nouveau nom de marque, a atteint la disponibilité générale, nous avons pu le déployer auprès de clients partout en Amérique du Nord et recueillir des commentaires précieux, des données d’utilisation, des informations sur la capacité d’évolution, etc., afin de valider l’adéquation produit-marché, avant de passer à la dernière phase du cycle de vie de la mise en production logicielle : la mise en production.
More Articles
6. Mise en production
Une version stable est une version d’un progiciel qui a été testée et vérifiée. Il s’agit de la version la plus récente (et parfois de la version finale) d’un programme, considérée comme sûre pour une utilisation publique. Ce type de version est également appelé version « stable ».
Lorsqu’un logiciel ou une application web entre dans cette phase, cela peut indiquer à l’organisation dans son ensemble et au marché le niveau de préparation atteint par votre produit. Chez SS&C Intralinks, en tant que responsable de l’organisation produit, j’ai associé les principales initiatives transversales à ces phases.
Au cours de la phase de mise en production, nous avons pu élaborer une stratégie d’offre, organiser des lancements complets auprès des équipes marketing et commerciales, ainsi que mettre en place le support nécessaire au sein du service client, de l’ingénierie de fiabilité des sites et d’autres départements pour assurer le succès du produit.
Selon la plupart des critères, il s’agit d’un produit complet, même s’il peut encore présenter quelques problèmes mineurs considérés comme acceptables. Dans certains cas, comme pour Linux, il existe deux types de versions stables : les versions LTS (support à long terme) et les versions stables régulières.
- Versions stables régulières - il s’agit du type de version le plus courant. Elles sont faciles à installer (lorsqu’il s’agit de logiciels pour systèmes d’exploitation) et, comme leur nom l’indique, elles sont stables. Si vous souhaitez tester un logiciel dans un environnement de production, c’est généralement ce type de version que vous utilisez. Les applications web désignent souvent les versions stables régulières par le terme versions « majeures ».
- Versions LTS (support à long terme) - elles sont spécialement conçues pour une utilisation à long terme dans des environnements de production. Ces versions ont une durée de maintenance plus longue que les versions stables standard (l’intervalle moyen entre les versions LTS est de trois ans). Cela signifie qu’elles ont été largement testées et sont considérées comme plus sécurisées que les versions stables.
Réflexions finales
Comprendre les différentes phases du cycle de vie de la mise en production logicielle d’un produit est un excellent moyen pour un responsable produit d’harmoniser les attentes et d’associer les activités transversales et liées aux clients aux différentes étapes du SRLC. Cela permet de segmenter clairement le produit par rapport à l’ensemble plus large des objectifs, stratégies et initiatives de l’entreprise.
Le fait d’utiliser ces étapes comme points de « déclenchement » m’a permis d’intégrer avec succès mon produit au sein d’une grande entreprise et de planifier les différentes actions afin d’assurer sa réussite sur le marché.
Une fois les étapes du SRLC terminées, le produit a traversé ses cycles de vente et de croissance, et l’organisation reçoit des signaux indiquant que le produit arrive en fin de parcours. Le cycle de vie de maintenance commence alors et comprend :
- la correction des bogues signalés par le client pendant la phase de déploiement,
- l’ajout de nouvelles fonctionnalités, ou
- la modification des fonctionnalités existantes à la demande du client, en fonction de l’évolution de ses besoins et des avancées technologiques.
Enfin, à un moment donné, tous les produits logiciels arrivent en fin de vie lorsqu’ils ne sont plus pris en charge par leurs développeurs.
Pour en savoir plus sur la gestion des produits et les bonnes pratiques de développement produit, n’oubliez pas de vous abonner ! À la prochaine.
Articles connexes :
- Les 6 étapes du cycle de vie du développement logiciel (SDLC)
- Comment rédiger des notes de version logicielle efficaces qui ravissent les utilisateurs
Liste connexe d’outils : Outils de gestion des mises en production logicielles
À découvrir également :
