Cycle de vie d'un logiciel
Le cycle de vie d'un logiciel désigne l'ensemble des étapes de développement d'un logiciel, du début de son développement jusqu'à la fin de vie. Ces étapes incluent également les potentielles mises à jour du logiciel, une fois une version publiée (à des fins de perfectionnement ou de correction de bugs encore présents dans le logiciel)
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Histoire modifier
L'utilisation de la terminologie de test alpha / bêta a commencé chez IBM[1]. Durant les années 1950 (et probablement plus tôt), des personnes impliquées chez IBM utilisaient des terminologies similaires : le test A pour la vérification d'un nouveau produit finalisé, effectuée juste avant l'annonce de la sortie ; le test B pour la vérification finale avant de confirmer la fabrication du produit ; le test C pour l'ultime test (après le B) avant la sortie du produit dans le marché. Un peu plus tard chez IBM, la terminologie de test alpha a commencé à être utilisée pour désigner le test effectué avant l'annonce publique, et test bêta une fois que le produit était prêt à sortir.
Stades de développement modifier
Pré-alpha modifier
La terminologie pré-alpha fait référence aux étapes du développement du produit logiciel et précédant les tests formels, comme l'analyse des exigences, la conception du logiciel, le développement et les tests unitaires. Dans le développement open source, il existe plusieurs types de versions pré-alpha.
Alpha modifier
La phase alpha du cycle de vie du logiciel est souvent la phase dans laquelle on commence les tests logiciels (alpha étant la première lettre de l'alphabet grec, utilisée comme chiffre 1). Dans cette phase, les développeurs testent généralement le logiciel en utilisant des techniques de boîte blanche. Une validation supplémentaire est ensuite effectuée par une autre équipe de test, en utilisant des techniques de boîte noire ou de boîte grise. Au sein d'une équipe, la version qui précède le test en boîte noire est communément appelée version alpha.
Bêta modifier
La bêta, nommée d'après la deuxième lettre de l'alphabet grec, est la phase de développement logiciel suivant l'alpha. La phase bêta commence généralement lorsque le logiciel est assez complet, mais susceptible de contenir un certain nombre de bugs. Les bugs des logiciels en phase bêta impactent souvent la vitesse ou la performance du logiciel, et peuvent provoquer des plantages ou des pertes de données. L'objectif des tests bêta est de réduire l'impact des bugs sur l'expérience utilisateur, en incorporant souvent des tests d'utilisabilité. Le processus de livraison d'une version bêta aux utilisateurs est appelé publication bêta et c'est généralement la première fois que le logiciel est disponible en dehors de l'organisation qui l'a développé. Les versions bêta du logiciel peuvent être publiques ou privées, selon la clientèle ciblée. La version bêta est souvent utilisée pour les démonstrations au sein d'une organisation, mais aussi pour attirer des clients potentiels.
Le rôle des bêta-testeurs est de signaler activement les problèmes de la version bêta d'un logiciel. Ce sont généralement des clients ou des représentants de clients travaillant au sein de l'équipe. Les bêta-testeurs ont tendance à proposer leurs services gratuitement.
Les utilisateurs de l'application sur ordinateur sont habitués à la phase bêta, les nouvelles versions d'un logiciel étant parfois annoncées comme tel, afin de réduire les attentes des utilisateurs quant à leur fiabilité[2].
Version stable modifier
Également appelée version de production, la version stable est la dernière version qui a passé toutes les vérifications et tests. Les bugs restants sont considérés comme acceptables et n'affectent généralement pas l'expérience utilisateur. La version stable est mise en production. Dans certains domaines (par exemple dans les distributions Linux), on trouve deux types de versions stables : les versions normales (ou stables) et les versions de support à long terme (LTS) qui sont maintenues pendant une plus longue durée.
Publication modifier
Le logiciel est dit en « version stable » lorsqu'il est considéré suffisamment fiable pour être publié et distribué.
Support modifier
Pendant leur durée de vie prise en charge, les logiciels sont parfois soumis à des versions de service, des correctifs ou des service packs, parfois également appelés «versions intermédiaires» ou «versions de maintenance» (MR). Par exemple, Microsoft a publié trois principaux Service Packs pour les éditions 32 bits de Windows XP et deux Service Packs pour les éditions 64 bits. Ces versions de service contiennent un ensemble de mises à jour, de correctifs et d'améliorations, fournis sous la forme d'un paquet installable unique. Ils peuvent également implémenter de nouvelles fonctionnalités. Certains logiciels sont publiés dans l'attente d'une assistance régulière. Les types de logiciels qui impliquent généralement un support prolongé incluent les antivirus et les jeux en ligne massivement multijoueurs.
Fin de vie modifier
Lorsque le logiciel n'est plus vendu ni pris en charge, le produit est arrivé en « fin de vie ». Bien qu'il soit alors considéré comme officiellement obsolète, la fidélité de ses utilisateurs pourrait continuer d'exister pendant un certain temps, même longtemps après que la plate-forme sur laquelle il est censé fonctionner soit devenue obsolète (exemples d'Atari ST et de ZX Spectrum) .
Après la date de fin de vie du logiciel, le développeur ou l'équipe de développeurs ne publient généralement plus aucune nouvelle fonctionnalité ou amélioration, ne corrigent pas les bugs ou vulnérabilités existantes (qu'elles soient connus avant cette date ou non), et ne fournissent plus aucune assistance pour le produit. Le développeur a ensuite le choix de divulguer le code source, afin que le logiciel puisse être toujours maintenu par des bénévoles.
Voir également modifier
- Gestion des mises en production
- Rolling release
- Application lifecycle management (processus de gestion du cycle de vie)
- Version d'un logiciel
- Lois de Lehman sur l'évolution des logiciels
Notes et références modifier
- (en-US) Brad Day, « How IBM and Google Shaped the Term Beta » (consulté le )
- « Why Google kept Gmail in "beta" for so many years. », sur Slate,
Liens externes modifier
- Stephen Manes, « Taking A Gamble With Word Vision », PC Communications Corp., vol. 3, no 6, , p. 211–221 (ISSN 0745-2500, lire en ligne [archive du ], consulté le )
Bibliographie modifier
- Livraison continue: versions logicielles fiables grâce à l'automatisation de la construction, des tests et du déploiement par Jez Humble, David Farley; (ISBN 0-321-60191-2)
