Processus de développement logiciel

De nombreux passages de ce très long article ne sont pas sourcés (notamment, mais pas uniquement, dans la section « Histoire »), ou sourcé uniquement avec des sources en anglais. Ceci confère à cette page un certain caractère d'essai personnel, avec par exemple le recours à ce qui semble être des « traductions inédites » (« Formez-vous », « Façonner »...).
De ce fait, cet article semble constituer en partie un travail inédit ou des déclarations non vérifiées (octobre 2023).

Vous pouvez aider en ajoutant des références ou en supprimant le contenu inédit. Voir la page de discussion pour plus de détails.

En génie logiciel, un processus de développement logiciel est un cadre de planification et de gestion du développement de logiciels. Il implique généralement la division du travail de développement logiciel en étapes ou sous-processus plus petits, qui peuvent être réalisés de manière parallèle ou séquentielle, dans le but d'améliorer la conception et/ou la gestion des produits. Ce processus est également connu sous le nom de cycle de vie de développement logiciel (SDLC, pour Software Development Life Cycle). La méthode peut comprendre la définition préalable de livrables et d'artefacts spécifiques qui sont créés et complétés par une équipe de projet pour développer ou maintenir une application^[1].

La plupart des processus de développement modernes peuvent être décrits de manière générale comme agiles. D'autres méthodes comprennent le développement en cascade, le prototypage, le développement itératif et incrémental, le développement en spirale, le développement rapide d'applications et la programmation extrême.

Un "modèle" de cycle de vie est parfois considéré comme un terme plus général désignant une catégorie de méthodes, tandis qu'un "processus" de développement logiciel est un terme plus spécifique désignant un processus particulier choisi par une organisation donnée. Par exemple, il existe de nombreux processus de développement de logiciels spécifiques qui correspondent au modèle de cycle de vie en spirale. Ce domaine est souvent considéré comme un sous-ensemble du cycle de vie du développement des systèmes.

Le cadre méthodologique de développement logiciel (également connu sous le nom de SDM) n'a fait son apparition qu'à partir des années 1960. Selon Elliott (2004), le cycle de vie du développement des systèmes (SDLC) peut être considéré comme le cadre méthodologique formalisé le plus ancien pour la construction de systèmes d'information. L'idée principale du SDLC était "d'aborder le développement des systèmes d'information de manière délibérée, structurée et méthodique, en exigeant que chaque étape du cycle de vie, de la conception initiale à la livraison du système final, soit réalisée de manière stricte et séquentielle"^[2] dans le contexte du cadre mis en place. L'objectif principal de ce cadre méthodologique dans les années 1960 était "de développer des systèmes entreprise fonctionnels à grande échelle à l'époque des conglomérats commerciaux de grande envergure. Les activités liées aux systèmes d'information étaient centrées sur des tâches intensives de traitement de données et de calculs numériques"^[2].

Collecte et analyse des exigences : La première étape du processus de développement de logiciels sur mesure consiste à comprendre les besoins et les objectifs du client. Cette étape implique généralement d'engager des discussions approfondies et de mener des entretiens avec les parties prenantes afin d'identifier les fonctionnalités souhaitées et la portée globale du logiciel. L'équipe de développement collabore étroitement avec le client pour analyser les systèmes et les flux de travail existants, déterminer la faisabilité technique et définir les étapes du projet.

Planification et conception : une fois les exigences comprises, l'équipe de développement de logiciels personnalisés établit un plan de projet complet. Ce plan décrit la feuille de route du développement, y compris les délais, l'allocation des ressources et les livrables. L'architecture et la conception du logiciel sont également établies au cours de cette phase. Les aspects de conception de l'interface utilisateur (UI) et de l'expérience utilisateur (UX) sont pris en compte pour assurer convivialité, intuitivité et attrait visuel du logiciel.

Développement : une fois la planification et la conception mises en place, l'équipe de développement entame le processus de codage. Cette étape implique l'écriture, le test et le débogage du code du logiciel. Les méthodes agiles, telles que Scrum ou Kanban, sont fréquemment employées pour favoriser la flexibilité, la collaboration et le développement itératif. Une communication régulière entre l'équipe de développement et le client assure la transparence et permet des retours et des ajustements rapides.

Tests et assurance qualité : afin d'assurer la fiabilité, les performances et la sécurité du logiciel, des processus rigoureux de tests et d'assurance qualité (AQ) sont mis en œuvre. Diverses techniques de test, notamment les tests unitaires, les tests d'intégration, les tests système et les tests d'acceptation des utilisateurs, sont utilisées pour détecter et corriger tout problème ou bug. Les activités d'assurance qualité visent à valider le logiciel par rapport aux exigences prédéfinies, garantissant ainsi son bon fonctionnement.

Déploiement et mise en œuvre : une fois que le logiciel a passé avec succès la phase de test, il est prêt pour le déploiement et la mise en œuvre. L'équipe de développement assiste le client dans la configuration de l'environnement logiciel, la migration des données si nécessaire et la mise en place du système. Une formation des utilisateurs ainsi qu'une documentation sont également fournies pour garantir une transition en douceur et permettre aux utilisateurs de tirer le meilleur parti du logiciel.

Maintenance et support : une fois le logiciel déployé, la maintenance et le support continus deviennent essentiels pour résoudre les problèmes, améliorer les performances et intégrer les améliorations futures. Des mises à jour régulières, des corrections de bugs et des correctifs de sécurité sont publiés pour maintenir le logiciel à jour et sécurisé. Cette phase implique également de fournir un support technique aux utilisateurs finaux et de répondre à leurs questions ou préoccupations. Les méthodes, processus et cadres varient en fonction des étapes prescriptives spécifiques qui peuvent être utilisées directement par une organisation dans son travail quotidien, aux cadres flexibles qu'une organisation utilise pour générer un ensemble personnalisé d'étapes adaptées aux besoins d'un projet ou d'un groupe de projets. Dans certains cas, un organisme de « sponsor » ou de « maintenance » distribue un ensemble officiel de documents décrivant le processus. Des exemples spécifiques incluent :

années 1970

• Programmation structurée depuis 1969
• Cap Gemini SDM, originaire de PANDATA, la première traduction anglaise a été publiée en 1974. SDM signifie Méthode de développement de système

années 1980

• Méthode d'analyse et de conception de systèmes structurés (SSADM) à partir de 1980
• Analyse des besoins en informations/méthodologie des systèmes logiciels

années 1990

• La programmation orientée objet (POO) s'est développée au début des années 1960 et est devenue une approche de programmation dominante au milieu des années 1990.
• Développement rapide d'applications (RAD), depuis 1991
• Méthode de développement de systèmes dynamiques (DSDM), depuis 1994
• Scrum, depuis 1995
• Processus logiciel d'équipe, depuis 1998
• Rational Unified Process (RUP), maintenu par IBM depuis 1998
• Programmation extrême, depuis 1999

années 2000

• Agile Unified Process (AUP) maintenu depuis 2005 par Scott Ambler
• La livraison agile disciplinée (DAD) remplace l'AUP

années 2010

• Cadre agile à l'échelle (SAFe)
• Scrum à grande échelle (LeSS)
• DevOps

Il est important de noter qu'à partir de DSDM en 1994, toutes les méthodes de la liste ci-dessus, à l'exception de RUP, sont des méthodes agiles. Cependant, de nombreuses organisations, en particulier les gouvernements, continuent d'utiliser des processus pré-agiles, souvent en cascade ou similaires. Le processus de développement logiciel et la qualité du logiciel sont étroitement liés, et des facettes et des effets inattendus ont été observés dans la pratique. Cela souligne le fait que malgré les avantages des méthodes agiles en matière de flexibilité, de collaboration et de réactivité aux changements, de nombreuses organisations ont du mal à passer de méthodes traditionnelles à des approches agiles en raison

^[3]

Parmi ceux-ci, un autre processus de développement de logiciels a été mis en place en open source. L'adoption de ces bonnes pratiques connues et des processus établis dans l'enceinte d'une entreprise est appelée source interne.

Le développement logiciel agile fait référence à un ensemble de cadres de développement logiciel basés sur un développement itératif, où les exigences et les solutions évoluent grâce à la collaboration entre des équipes interfonctionnelles auto-organisées. Le terme a été inventé en 2001 lors de la formulation du Manifeste Agile.

Le développement logiciel agile repose sur le développement itératif en tant que base, mais il adopte une approche plus légère et plus centrée sur les personnes que les méthodes traditionnelles. Les processus agiles intègrent essentiellement l'itération et le retour d'information continu pour affiner et livrer progressivement un système logiciel.

Le modèle Agile comprend également les processus de développement logiciel suivants ^[4]:

• Méthode de développement de systèmes dynamiques (DSDM)
• Kanban
• Mêlée
• Cristal
• Arrière
• Développement de logiciels Lean

Intégration continue consiste à fusionner toutes les copies de travail des développeurs sur une ligne principale partagée plusieurs fois par jour^[5]. Grady Booch a été le premier à nommer et proposer l'intégration continue dans sa méthode en 1991^[6], bien qu'il ne préconisait pas l'intégration plusieurs fois par jour. La programmation extrême (XP) a adopté le concept de l'intégration continue et préconise l'intégration plus d'une fois par jour, allant même jusqu'à des dizaines de fois par jour.

Le développement rapide d'applications (RAD) est une méthode de développement logiciel qui privilégie le développement itératif et la construction rapide de prototypes au lieu d'une planification initiale extensive. La "planification" d'un logiciel développé avec RAD est étroitement liée à l'écriture du logiciel lui-même. L'absence de planification préalable approfondie permet généralement de développer des logiciels beaucoup plus rapidement et facilite la modification des exigences. Cette approche agile est particulièrement adaptée aux projets où les besoins évoluent fréquemment et où il est essentiel de livrer des fonctionnalités rapidement.

Le processus de développement rapide commence par la création de modèles de données préliminaires et de modèles de processus métier à l'aide de techniques structurées. Dans l'étape suivante, les exigences sont validées à travers des prototypages, permettant éventuellement de peaufiner les modèles de données et de processus. Ces étapes sont répétées de manière itérative, et à terme, elles aboutissent à "une déclaration combinée d'exigences commerciales et de conception technique à utiliser pour la construction de nouveaux systèmes". Cette approche itérative et collaborative favorise l'ajustement continu des besoins et de la conception en fonction des retours obtenus, ce qui conduit à un développement plus rapide et plus adapté aux besoins du projet.

Le modèle en cascade est une approche de développement séquentiel, dans laquelle le développement est considéré comme s'écoulant régulièrement vers le bas (comme une cascade) à travers plusieurs phases, généralement :

• Analyse des besoins aboutissant à une spécification des exigences logicielles
• Conception de logiciels
• Mise en œuvre
• Essai
• Intégration, s'il existe plusieurs sous-systèmes
• Déploiement (ou Installation )
• Entretien

La première description formelle de la méthode en cascade est souvent attribuée à un article publié par Winston W. Royce en 1970^[7], bien que Royce n'ait pas utilisé le terme cascade dans cet article. Royce a présenté ce modèle comme un exemple de modèle défectueux et non fonctionnel, soulignant les limitations et les risques inhérents à une approche strictement séquentielle du développement logiciel. Malgré cela, le modèle en cascade a été adopté par de nombreuses organisations et est devenu l'une des premières approches formelles de développement logiciel^[8].

En 1988, Barry Boehm a présenté un modèle de développement de systèmes logiciels appelé le modèle en spirale, qui fusionne des éléments essentiels du modèle en cascade avec des méthodes de prototypage rapide. L'objectif était de réunir les avantages des approches descendantes et ascendantes. Une caractéristique distincte de cette approche était sa mise en lumière d'un aspect clé que d'autres méthodes avaient tendance à négliger : l'analyse itérative délibérée des risques, particulièrement adaptée aux systèmes complexes à grande échelle.

Les principes de base sont ^[1]:

• L'accent est mis sur l'évaluation des risques et sur la minimisation des risques du projet en divisant un projet en segments plus petits et en facilitant les changements pendant le processus de développement, ainsi qu'en offrant la possibilité d'évaluer les risques et d'envisager la poursuite du projet tout au long du cycle de vie.
• "Chaque cycle implique une progression à travers la même séquence d'étapes, pour chaque partie du produit et pour chacun de ses niveaux d'élaboration, depuis un document global de concept de fonctionnement jusqu'au codage de chaque programme individuel." ^[9]
• Chaque voyage autour de la spirale traverse quatre quadrants de base : (1) déterminer les objectifs, les alternatives et les contraintes de l'itération, et (2) évaluer les alternatives ; Identifier et résoudre les risques ; (3) développer et vérifier les livrables de l'itération ; et (4) planifier la prochaine itération^[10].
• Commencez chaque cycle par une identification des parties prenantes et de leurs « conditions gagnantes », et terminez chaque cycle par un examen et un engagement^[11].

En 2018, Basecamp a introduit Shape Up, une approche de développement logiciel qui se distingue par sa volonté de résoudre le problème des projets interminables et dépourvus de clarté. Conçue principalement pour les équipes distantes, Shape Up repose sur un ensemble de principes et de techniques internes élaborés par Basecamp. Contrairement aux méthodes telles que Waterfall, Agile ou Scrum, Shape Up se distingue par l'absence totale d'estimations, de suivi de la vitesse, de backlogs ou de sprints. Ces concepts sont remplacés par des notions telles que l'appétit, les paris et les cycles. Il est à noter que, depuis 2022, d'autres organisations notables, telles que UserVoice et Block, ont également adopté Shape Up^[12],[13].

Basecamp a déterminé par des itérations successives que la durée optimale pour un cycle est de 6 semaines. Cette période de 6 semaines s'est avérée être un équilibre idéal, étant suffisamment longue pour permettre le développement d'une fonctionnalité substantielle, tout en étant suffisamment courte pour susciter un sentiment d'urgence.

Le façonnage est le processus préliminaire de préparation du travail avant sa remise aux concepteurs et aux ingénieurs. Le travail façonné consiste à définir les éléments principaux de l'interface utilisateur de la solution, à identifier les principaux défis à relever, et à établir des limites claires pour la portée du projet. Il doit rester à un niveau d'approximation, laissant les détails plus fins à résoudre aux constructeurs (c'est-à-dire les concepteurs et les ingénieurs), afin de leur permettre d'exercer leur créativité et de prendre des décisions éclairées.

Ce travail façonné est généralement documenté sous la forme d'un pitch, en utilisant une solution de documentation en ligne qui facilite les commentaires^[14]. Cela permet aux membres de l'équipe de contribuer des informations techniques de manière asynchrone. Ces commentaires revêtent une grande importance pour repérer d'éventuelles surprises ou difficultés cachées qui pourraient potentiellement perturber le déroulement du projet.

Avant le démarrage de chaque cycle, les parties prenantes se réunissent lors d'une session de paris, au cours de laquelle les pitchs sont soigneusement évalués. À l'issue de cette séance, une décision est prise pour chaque pitch : soit il est sélectionné pour être réalisé, soit il est abandonné^[15].

La méthode par laquelle Shape Up alloue le temps pour un projet est radicalement différente des autres méthodes. Dans le cadre de Shape Up, le processus commence en définissant un "appétit" (par exemple, une période de 6 semaines) et s'achève en concevant une solution qui peut être développée et livrée dans cette contrainte de temps. L'appétit devient ainsi une échéance stricte à laquelle les constructeurs du projet doivent se conformer, ce qui incite à la concentration et à la gestion efficace du temps^[16].

Shape Up est un système à double piste où les façonneurs et les constructeurs travaillent en parallèle. Le travail façonné au cours du cycle actuel peut être transmis aux concepteurs et aux ingénieurs pour être construit lors d'un cycle ultérieur. Cela permet une approche fluide de la gestion des projets, avec un flux continu de travail qui se déplace de la phase de conception à la phase de construction.

En raison des incertitudes techniques inhérentes à la construction, les avancées sont suivies grâce à un graphique particulier qui illustre la métaphore de la "colline", communément appelé le "graphique de la colline". La phase ascendante du graphique représente la période pendant laquelle les constructeurs sont encore en train de perfectionner leur approche, tandis que la phase descendante signifie que les inconnues techniques ont été résolues. Dans ce système, les constructeurs sont encouragés à communiquer activement et de manière asynchrone leurs progrès en utilisant un graphique interactif en ligne, généralement sur des plateformes telles que Basecamp ou Jira. Cette approche déplace l'attention des simples statuts (terminés ou non terminés) vers la résolution des problèmes inconnus ou déjà résolus. En somme, l'utilisation d'un graphique de la colline remplace le processus traditionnel de reporting des statuts linéaires, que l'on retrouve dans les méthodes comme la mêlée (Scrum) ou le Kanban^[17],[18].

Une variété de ces cadres ont évolué au fil des années, chacun avec ses propres forces et faiblesses reconnues. Un cadre méthodologique de développement logiciel n’est pas nécessairement adapté à tous les projets. Chacun des cadres méthodologiques disponibles est le mieux adapté à des types spécifiques de projets, en fonction de diverses considérations techniques, organisationnelles, de projet et d'équipe^[1].

Une équipe de développement particulière peut également convenir des détails de l'environnement du programme, tels que environnement de développement intégré utilisé, un ou plusieurs paradigmes de programmation dominants, des règles de style de programmation ou le choix de bibliothèques de logiciels ou de cadres logiciels spécifiques. Ces détails ne sont généralement pas imposés par le choix du modèle ou de la méthodologie générale.

• Cycle de vie du développement des systèmes
• Génie logiciel assisté par ordinateur (certains de ces outils prennent en charge des méthodes spécifiques)
• Liste des philosophies de développement logiciel
• Aperçu du génie logiciel
• S'ouvrir
• Gestion de projet logiciel
• Développement de logiciels
• Estimation de l'effort de développement logiciel
• Cycle de vie des versions logicielles
• Conception descendante et ascendante#Informatique

• Sélection d'une approche de développement sur cms.hhs.gov.
• Gerhard Fischer, « La technologie logicielle du 21e siècle : de la réutilisation de logiciels à la conception collaborative de logiciels », 2001

• Portail du logiciel