←
Processus d'génie logiciel

9.2 Processus d'génie logiciel

Objectifs d'apprentissage

À la fin de cette section, vous serez capable de :

  • Décrire les phases d'un processus de développement logiciel et leurs objectifs
  • Étudier les modèles de processus logiciels traditionnels prescriptifs et agiles populaires
  • Suggérer un processus logiciel efficace

Imaginez une recette pour construire un logiciel. Il existe différentes façons de préparer le même plat, mais la plupart des recettes suivent une structure de base avec des étapes comme la collecte des ingrédients, leur préparation, la cuisson et le service. Les processus d'génie logiciel sont similaires. Ils fournissent une approche structurée pour créer des applications logicielles. Divers modèles de processus d'génie logiciel sont généralement utilisés pour soutenir le cycle de vie du développement logiciel (SDLC). Après des années de recherche et d'affinements, les chercheurs et praticiens en génie logiciel ont convergé vers la définition d'un modèle de processus d'génie logiciel générique, ou cadriciel de processus, qui peut être utilisé comme un modèle. Ce cadriciel de processus comprend un ensemble d'éléments de processus (par exemple, activités cadre, actions d'génie logiciel, ensembles de tâches, produits de travail, assurance qualité et mécanismes de contrôle des changements) qui peuvent différer pour chaque modèle de processus et pour chaque projet.

Modèles de processus traditionnels

Une catégorie courante de modèles de processus est connue sous le nom de modèle de processus traditionnel (traditional process model). Ce cadriciel de processus, comme vous l'avez appris plus tôt dans le chapitre, englobe quatre activités cadre (c'est-à-dire génériques) qui sont également connues sous le nom de phases : initialisation, élaboration, construction et déploiement :

  • L'initialisation couvre les activités de planification où vous définissez les objectifs du projet et identifiez la portée globale.
  • L'élaboration implique l'analyse des exigences et la conception d'un modèle d'architecture détaillé pour le logiciel.
  • La construction est l'étape où le codage a lieu ! Le logiciel est construit sur la base de la conception créée précédemment.
  • Le déploiement est l'activité qui se concentre sur la publication du logiciel sous une forme utilisable et sa mise à disposition des utilisateurs finaux.

Ces activités cadre (génériques) ou phases sont applicables quel que soit le modèle de processus d'génie logiciel spécifique choisi pour un projet et peuvent être élaborées différemment selon l'organisation, le domaine problématique et le projet en cours de développement. Il existe également des activités cadres qui sont importantes mais tangentielles aux activités cadre. Pour revenir à l'analogie de la recette, si les activités cadre génériques représentent la cuisine, alors vous pouvez considérer ces activités comme les choses que vous feriez en parallèle de votre cuisine, comme vous assurer d'avoir les bonnes casseroles et poêles ou garder votre cuisine propre. Comme vous l'apprendrez plus tard dans le chapitre, dans le développement logiciel, ces activités sont connues sous le nom d'activités cadres, et elles incluent :

  • la formation et la communication (par exemple, la préparation et la production de produits de travail)
  • la gestion et la planification des risques (par exemple, le suivi et le contrôle des projets logiciels)
  • la gestion de la configuration
  • la gestion de la qualité (par exemple, les revues techniques, les estimations, les métriques/mesures, les tests)
  • la gestion de l'architecture (par exemple, la gestion de la réutilisabilité)
  • la gestion de la sécurité (security)

Diverses actions de génie logiciel (software engineering) sont généralement effectuées dans le cadre des activités cadre génériques et des activités cadres. Par exemple, la phase d'initialisation peut nécessiter des actions d'ingénierie des exigences telles que la définition et la gestion des exigences ; la phase d'élaboration peut impliquer des actions de conception de haut niveau et de conception détaillée. Chaque type d'action d'génie logiciel correspond à un processus qui peut être représenté comme un flux de travail ou un ensemble de tâches, et chaque tâche aboutit à des produits de travail qui sont soumis à des mécanismes spécifiques d'assurance qualité et de contrôle des changements. Fondamentalement, un ensemble de tâches (ou flux de travail) englobe toutes les tâches nécessaires pour accomplir une action d'génie logiciel spécifique au sein d'une activité cadre. Les ensembles de tâches varient en fonction des caractéristiques d'un projet, et les activités au sein d'un modèle de processus donné se chevauchent généralement au lieu d'être exécutées indépendamment.

Les modèles de processus logiciels qui adhèrent au cadre générique mentionné précédemment sont parfois appelés méthodologies SDLC. En général, les modèles de processus d'génie logiciel sont structurés de cette manière pour faciliter le développement efficace de logiciels de qualité, réduire les risques d'échec, augmenter la prévisibilité et capturer les bonnes pratiques en développement logiciel. Le cadre logiciel fournit un modèle qui permet aux ingénieurs logiciels d'adapter leur modèle de processus en fonction des projets spécifiques sur lesquels ils travaillent. Les activités cadre (génériques) mentionnées précédemment sont applicables à tous les projets et à tous les domaines d'application, et elles constituent un modèle pour chaque modèle de processus. Les actions/méthodes des modèles de processus réels peuvent, cependant, utiliser diverses approches. De plus, des outils d'génie logiciel peuvent être utilisés pour (semi-)automatiser les diverses méthodes qui exécutent les activités.

Les activités impliquées dans le développement de logiciels peuvent varier selon l'organisation et le type de logiciel développé. Il n'y a pas de méthode unique pour créer une solution logicielle, mais l'expérience nous dit généralement ce qui fonctionne bien et ce qui fonctionne mal dans un contexte donné. Par conséquent, les cadres de processus sont élaborés différemment selon les quatre P – problème, projet, personnes et produit – qu'ils abordent.

Dans le passé, cela a conduit à l'utilisation de divers modèles de processus prescriptifs (prescriptive process model) traditionnels tels que les processus en cascade, de prototypage, en spirale et unifiés rationnels. Un modèle de processus prescriptif préconise une approche ordonnée de l'génie logiciel qui implique de suivre un ensemble prescrit d'activités de manière continue. Ces modèles de processus traditionnels fournissent une approche structurée du développement logiciel et peuvent aider à atteindre les objectifs suivants :

  • Améliorer l'efficacité : En suivant un plan clair, les équipes peuvent travailler plus efficacement et éviter les reprises.
  • Réduire les risques : L'identification et la résolution des problèmes potentiels dès le début peuvent aider à prévenir les échecs de projet.
  • Augmenter la prévisibilité : Un processus structuré peut aider à estimer les délais et les coûts plus précisément.
  • Capturer les bonnes pratiques : Les modèles traditionnels intègrent souvent des méthodes éprouvées pour le développement logiciel.

Cependant, de nos jours, les modèles de processus prescriptifs traditionnels sont perçus par certains comme "dépassés" (c'est-à-dire lourds, des machines bureaucratiques produisant des documents). Notez que prescriptif signifie simplement que le modèle de processus identifie un ensemble d'éléments de processus (par exemple, activités cadre, actions d'génie logiciel, tâches, produits de travail, assurance qualité et mécanismes de contrôle des changements) pour chaque projet. Les modèles traditionnels sont généralement critiqués pour être trop rigides et inflexibles. Ils peuvent ne pas convenir à tous les projets, en particulier ceux dont les exigences changent rapidement.

En général, les différents modèles de processus peuvent avoir des caractéristiques communes entre eux, et il peut y avoir un certain chevauchement entre les activités menées au sein de chaque processus donné. Dans la section suivante, nous explorerons une approche alternative appelée développement logiciel agile.

Modèles de processus agiles

Le Manifeste Agile (Agile Manifesto) expose la philosophie Agile et souligne le fait que les processus d'génie logiciel ne devraient pas être contraints d'être continus. Il préconise qu'il est acceptable de sauter et d'accélérer les activités cadre pour livrer une solution de projet plus rapidement et, par conséquent, il est acceptable que le processus logiciel soit considéré comme un ensemble discret d'activités significatives pour réduire le coût du changement. Dans ce contexte, l'agilité fait référence à la capacité de créer et de réagir au changement afin de tirer profit d'un environnement commercial turbulent. Les partisans des modèles de processus agiles se demandent si les modèles de processus prescriptifs qui s'efforcent d'adopter une approche structurée et ordonnée de l'génie logiciel sont appropriés pour un monde qui prospère sur le changement. En général, les processus agiles ont des cycles de produit très courts et sollicitent constamment les retours des clients pour concentrer le développement sur leurs besoins actuels. Les processus logiciels agiles promettent de fortes améliorations de productivité, une qualité logicielle accrue, une satisfaction client plus élevée et une réduction du roulement des développeurs. Les techniques de développement agile permettent aux équipes de surmonter les pressions liées au délai de mise sur le marché et aux exigences volatiles. Cependant, remplacer les modèles de processus traditionnels par quelque chose de moins structuré peut rendre difficile la coordination et la cohérence du travail logiciel.

En général, la simple existence d'un processus logiciel, qu'il soit fortement prescriptif ou agile, ne garantit pas que le logiciel sera livré à temps, qu'il répondra aux besoins du client ou qu'il présentera des caractéristiques de qualité à long terme. Tout le monde veut un processus capable de réagir au changement ; les seuls débats portent sur la manière d'en concevoir un et sur le niveau de discipline à intégrer dans de tels modèles de processus.

L'agilité exige que les clients et les développeurs agissent en tant que collaborateurs au sein des équipes de développement. L'objectif devrait être de construire des produits logiciels qui peuvent être rapidement adaptés pour répondre aux exigences d'un marché en évolution rapide. Ceci est généralement réalisé par le développement incrémentiel de prototypes opérationnels qui sont améliorés au fil du temps. En conséquence, l'génie logiciel agile est une façon de travailler qui tire parti du développement itératif, de la livraison incrémentielle et de la réévaluation continue des produits. Elle est basée sur une idée claire du concept du produit et de son marché. Elle se concentre également sur les fonctionnalités à forte valeur ajoutée en premier et sur la production de résultats tangibles et fonctionnels après chaque itération. Les principes d'agilité sont résumés comme suit :

  • Assurer la satisfaction du client en livrant le logiciel aux clients le plus rapidement possible.
  • Accepter le fait que les exigences peuvent changer et travailler en conséquence.
  • Livrer le logiciel de manière incrémentielle aux parties prenantes aussi souvent que possible (par exemple, chaque semaine plutôt que chaque mois comme c'est le cas avec les modèles de processus traditionnels) et utiliser leurs retours pour améliorer les incréments suivants.
  • Minimiser la création de documentation à ce qui est absolument nécessaire et pertinent.
  • Constituer une équipe agile qui inclut des participants motivés et faciliter des réunions fréquentes entre les membres de l'équipe pour améliorer la communication et le partage d'informations.
  • Créer des processus d'équipe qui encouragent l'excellence technique, une bonne conception et la simplicité tout en évitant le travail inutile.
  • Se concentrer sur l'objectif principal de livrer un logiciel qui répond aux besoins du client.
  • S'assurer que le travail d'équipe n'est pas accablant afin que les membres de l'équipe puissent être efficaces sur une longue période.
  • Considérer le fait que les équipes agiles doivent devenir auto-organisées afin d'atteindre l'objectif principal de développer des solutions bien conçues et implémentées pour répondre aux besoins des clients.
  • Inculquer une culture d'équipe qui exige que tous les membres de l'équipe travaillent ensemble avec un seul objectif en tête, qui est d'assurer la satisfaction du client.

La philosophie Agile est séduisante, mais elle doit être tempérée par les exigences des systèmes réels dans le monde réel. En général, les modèles de processus agiles ne conviennent pas aux projets de grande envergure, à haut risque ou critiques. Il existe un spectre d'agilité qu'il convient de considérer pour répondre à ces exigences, comme illustré à la Figure 9.4.

Graphique du spectre de l'agilité allant du processus fixe, moins de collaboration, livraison rigide, en passant par le modèle en cascade, l'agile hybride et les équipes agiles, jusqu'au processus flexible, plus de collaboration, livraison incrémentielle.
Figure 9.4 Le spectre de l'agilité représente les modèles de processus prescriptifs traditionnels tels que le modèle en cascade d'un côté, et les processus agiles de l'autre. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Lorsqu'un écosystème de développement logiciel agile (ASDE) (Agile Software Development Ecosystem (ASDE)), qui englobe toute la catégorie des cadres et méthodes SDLC agiles, est comparé aux méthodologies SDLC traditionnelles (prescriptives), l'ASDE met l'accent sur la difficulté de prédire les besoins futurs. Ainsi, les approches agiles évitent de créer des plans à long terme et des processus fixes afin que les développeurs puissent plutôt collaborer avec les clients et s'adapter à leurs besoins actuels.

Beaucoup d'idées liées à l'approche Agile méritent d'être considérées quel que soit le modèle de processus adopté par une équipe. Les processus agiles gèrent les changements imprévisibles qui ont lieu pendant les projets de développement logiciel. L'accent des processus agiles est mis sur la livraison d'incréments logiciels dans des délais relativement courts et sur l'utilisation des retours sur ces incréments pour orienter le développement. Il y a des compromis lors de la sélection d'un écosystème de développement logiciel agile (ASDE). Bien que les ASDE identifient correctement le produit comme le résultat le plus important d'un projet, il peut être difficile d'adapter des cycles de produit rapides pour développer des applications logicielles à l'échelle de l'entreprise. En général, les compromis sont importants pour que les choses fonctionnent. En particulier, les problèmes potentiels causés par des équipes dysfonctionnelles peuvent être importants. L'impact des aspects humains de l'adaptation du modèle de processus doit être pris en compte, et tous les facteurs humains et la dynamique de groupe des équipes agiles, y compris la collaboration et les équipes auto-organisées, sont des améliorations importantes par rapport aux approches traditionnelles et sont utilisés à plusieurs reprises lorsque le développement agile est effectué.

En conclusion, un processus logiciel, quelle que soit sa centralité, doit simplement adhérer à un ensemble de critères de modèle de processus logiciel essentiels pour assurer une ingénierie réussie des solutions logicielles. À cette fin, il est nécessaire d'évaluer les processus et leurs activités connexes en utilisant des mesures numériques réelles ou en appliquant des métriques dans le cadre des méthodes d'analyse utilisées pour surveiller la performance (performance) des modèles de processus logiciels.

Activités cadre du processus logiciel

Une bonne partie du rôle d'un ingénieur logiciel se déroule au sein des diverses activités cadre d'un SDLC. À ce titre, il est essentiel pour un ingénieur logiciel de comprendre les éléments clés de chacune des diverses activités cadre utilisées pour créer des solutions logicielles. Comme vous vous en souvenez peut-être, ces activités cadre ou phases ont été introduites précédemment comme l'initialisation, l'élaboration, la construction et le déploiement. Ces activités fournissent une approche structurée pour créer des solutions logicielles. En comprenant ces activités cadre et les tâches impliquées dans chaque phase, vous serez bien équipé pour contribuer efficacement au processus d'génie logiciel.

Activité cadre d'initialisation

Une condition préalable essentielle à la création d'une solution est de savoir ce qui doit être développé. Il est facile de dire que l'on veut ajouter des fonctionnalités d'automatisation à une automobile, mais qu'est-ce que cela signifie réellement ? Quelles sont les attentes spécifiques et comment se rapportent-elles à la solution qui doit être créée ? Pour créer une solution, il faut comprendre ce que la solution est censée faire.

La phase d'initialisation (inception phase) d'un projet se concentre sur la collecte et l'affinage (c'est-à-dire la définition) ainsi que la gestion des exigences fonctionnelles et non fonctionnelles (nonfunctional requirement), ce qui est également connu sous le nom d'ingénierie des exigences. En substance, la phase d'initialisation couvre l'activité de planification qui jette les bases d'un projet. Ici, vous définirez les objectifs du projet, identifierez la portée globale du logiciel (les fonctionnalités qu'il aura) et réaliserez des études de faisabilité pour évaluer si le projet est réaliste et réalisable. À titre d'exemple, imaginez que vous construisez une application de recettes. Dans cette phase, vous décideriez des fonctionnalités que l'application devrait avoir (comme la recherche de recettes ou la création de listes de courses) et estimeriez le temps et les ressources nécessaires pour la développer.

La définition des exigences doit impliquer les parties prenantes car elles savent mieux que quiconque ce que le système logiciel devrait faire. La définition des exigences implique l'obtention des exigences des parties prenantes et l'analyse/décomposition des exigences stratégiques jusqu'à ce que vous puissiez identifier des exigences tactiques et actionnables. Celles-ci formeront la base de la création du modèle d'analyse. Ce processus de définition est effectué soit avec un cas d'utilisation (use case), qui décrit comment le système logiciel est censé être utilisé par les utilisateurs pour atteindre un objectif ou une exigence, soit comme un récit utilisateur (user story), qui est une explication générique destinée à l'utilisateur pour lui dire comment une fonctionnalité logicielle fonctionne. La gestion des exigences concerne la gestion des changements d'exigences et l'identification de l'effet de ces changements sur l'ensemble existant d'exigences conçues.

Bien que les actions d'génie logiciel et les ensembles de tâches liés à l'élaboration des exigences puissent paraître simples à première vue, il s'agit en fait de l'une des parties les plus délicates du SDLC. Cela est dû à un écart qui existe toujours entre la façon dont les parties prenantes et les analystes commerciaux comprennent les exigences par rapport à la façon dont elles sont perçues par les ingénieurs logiciels. Cela est particulièrement vrai lorsque vous développez une solution logicielle pour un groupe d'experts particulier qui utilise sa propre terminologie ; souvent, ceux qui exécutent un processus tiennent pour acquis certaines des actions qu'ils effectuent.

La phase d'initialisation aboutit à une spécification du système à développer. Cette spécification est généralement incomplète et/ou anormale et est typiquement affinée dans le cadre des phases de processus ultérieures (ou de leurs itérations). En conséquence, il existe une distinction floue entre la spécification des exigences, la conception et la construction.

Les actions d'génie logiciel et les ensembles de tâches réels utilisés dans la phase d'initialisation impliquent de comprendre le contexte de la solution et de recueillir, décomposer et suivre les exigences de manière collaborative pour aider à élaborer un modèle d'analyse préliminaire. Une fois le modèle d'analyse préliminaire créé, les exigences peuvent ensuite être négociées et validées avec les parties prenantes via une session JAD (Joint Application Design) en personne, une approche qui implique de réunir les parties prenantes et les développeurs, ou par l'utilisation d'outils de modélisation collaborative des exigences qui permettent la modélisation basée sur des scénarios. Après cela, une modélisation détaillée des exigences a lieu.

La définition agile des exigences tente d'accélérer la collecte et l'analyse/décomposition des exigences. Les lignes directrices qu'elle utilise pour accélérer ce processus incluent :

  1. Utiliser des modèles simples tels que des croquis rapides et des récits utilisateurs pour permettre à toutes les parties prenantes de participer.
  2. Adopter la terminologie de l'utilisateur, du client ou du groupe d'experts et éviter le jargon technique autant que possible.
  3. Obtenir une vue d'ensemble du projet avant de se perdre dans les détails.
  4. Affiner les exigences tout au long du projet et permettre des ajouts et des révisions à tout moment.
  5. Implémenter les récits utilisateurs les plus importants en premier et seulement une fois que leurs exigences sont entièrement spécifiées.
  6. Mettre l'ensemble actuel des exigences à la disposition de toutes les parties prenantes afin que chacun puisse participer à la sélection des fonctionnalités à ajouter lors du prochain cycle de développement.

Divers outils peuvent être utilisés pour soutenir les actions d'génie logiciel et les ensembles de tâches qui se rapportent à la phase d'initialisation (par exemple, ReqView3).

Modélisation des exigences

L'action d'génie logiciel qui fait partie de la phase d'initialisation et se concentre sur l'analyse/décomposition des exigences logicielles est appelée modélisation des exigences (requirements modeling). L'objectif de cette action est de répondre à la question « Que fera le système ? » L'accent est purement conceptuel, et les détails d'implémentation ne sont pas pris en compte. Le but principal de cette analyse est de comprendre les exigences à un niveau qui permet de concevoir et d'implémenter un système logiciel qui répond aux besoins du client.

Dans le cadre de la modélisation des exigences, comme dans la modélisation des cas d'utilisation métier, vous créez généralement un modèle de domaine qui capture les concepts majeurs du domaine problématique et les associations entre eux. Par exemple, dans le domaine des aides à la conduite pour une solution automobile, il pourrait y avoir des classes conceptuelles/d'analyse telles que AdaptiveCruiseControl, Car, BlindSpotDetection et Blinker et des attributs de classe attribués aux classes comme suit :

  • AdaptiveCruiseControl a les attributs state (on/off) et desiredSpeed (la vitesse demandée).
  • Car a l'attribut speed (la vitesse actuelle).
  • BlindSpotDetection a l'attribut state (on/off).
  • Blinker a l'attribut state (on/off).

Figure 9.5 illustre un diagramme de classes d'un modèle de domaine partiel. Ce diagramme est spécifié à l'aide du langage de modélisation unifié (UML) (Unified Modeling Language (UML)). L'UML est souvent utilisé pour la modélisation dans les projets car ses représentations visuelles offrent des moyens clairs et compacts de communication entre les développeurs. Dans les diagrammes de classes UML comme celui-ci, les nombres aux associations sont des multiplicités, et les flèches spécifient la direction dans laquelle vous êtes censé lire l'association. Par exemple, BlindSpotDetection surveille Car.

Illustration d'un diagramme de classes d'un modèle de domaine partiel utilisant le langage de modélisation unifié pour AdaptiveCruiseControl.
Figure 9.5 Un diagramme de classes UML, dans ce cas d'un modèle de domaine partiel, est utilisé comme outil de communication entre les développeurs. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les associations sont des liens qui méritent d'être stockés dans le système. Par exemple, une association entre AdaptiveCruiseControl et Car est requise car lorsque le régulateur de vitesse adaptatif est actif, la classe conceptuelle AdaptiveCruiseControl a besoin d'accéder à la voiture. Les nombres aux associations sont des multiplicités, et ils indiquent qu'il y a exactement une voiture associée à chaque AdaptiveCruiseControl et qu'il y a exactement un AdaptiveCruiseControl associé à chaque voiture. Les associations peuvent avoir des noms, ce qui facilite la lecture et la compréhension du modèle d'analyse.

La notation UML peut être appliquée pour fournir différentes perspectives comme suit :

  • Perspective conceptuelle : Les diagrammes décrivent des concepts ou des choses du monde réel.
  • Perspective de spécification (logicielle) : Les diagrammes décrivent des composants logiciels.
  • Perspective d'implémentation (logicielle) : Les diagrammes décrivent des composants logiciels dans une technologie particulière, telle que Java ou .NET.

Nous utilisons généralement toutes les perspectives tout au long du cycle de vie du développement logiciel : la perspective conceptuelle pour capturer les exigences, la perspective de spécification pour décrire la conception et la perspective d'implémentation pour clarifier les détails d'implémentation.

Lors de l'analyse des exigences, vous pouvez créer des sorties/produits de travail spécifiques (également appelés artefacts), tels que des cas d'utilisation, des scénarios et le modèle de domaine. Les cas d'utilisation peuvent être capturés en texte brut ou via un diagramme de cas d'utilisation UML. Un diagramme de cas d'utilisation se compose d'un acteur, qui représente les utilisateurs du système, et des cas d'utilisation que cet utilisateur est censé utiliser. Dans la Figure 9.6, l'acteur est un conducteur qui pourrait chercher à activer le régulateur de vitesse. Chaque cas d'utilisation est ensuite décrit en détail à l'aide d'un ou plusieurs scénarios. Un scénario (scenario) est une instance spécifique de flux opérationnel au sein d'un cas d'utilisation qui se concentre sur la compréhension d'une action spécifique. Les scénarios sont écrits soit en texte brut, soit comme une séquence d'étapes décrivant une instance de scénario spécifique au sein d'un cas d'utilisation (c'est-à-dire le scénario principal décrivant l'ensemble d'étapes le plus productif par rapport aux scénarios alternatifs qui capturent un comportement inattendu).

Illustration d'un conducteur et de trois cas d'utilisation : Démarrer le régulateur de vitesse adaptatif, Modifier le régulateur de vitesse adaptatif et Arrêter le régulateur de vitesse adaptatif.
Figure 9.6 Dans ce diagramme de cas d'utilisation UML illustrant un acteur appelé « Conducteur », les trois cas d'utilisation pourraient être regroupés et catégorisés comme système de contrôle de voiture. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Dans le cadre de la modélisation des exigences, les diagrammes UML sont dessinés chaque fois qu'ils apportent de la valeur pour aider à fournir une perspective conceptuelle de ce que la solution est censée accomplir. Ils ne sont généralement pas tenus d'être complets ou parfaits. L'utilisation de l'UML de cette manière est généralement appelée « UML comme esquisse », et elle implique des diagrammes informels et incomplets. Au lieu de dessiner des diagrammes UML, il est possible de les spécifier via des scripts pour automatiser la création de diagrammes, ce qui peut faire gagner un temps précieux. Comme mentionné, l'objectif principal de l'analyse/décomposition des exigences dans la phase d'initialisation est de comprendre le problème, tandis que l'objectif principal de la phase d'élaboration, qui vient ensuite et implique la conception logicielle, est de clarifier ce que nous devons implémenter.

Activité cadre d'élaboration

La phase d'élaboration (elaboration phase) analyse davantage les exigences pour produire des modèles de conception du système à développer. Dans cette phase, vous approfondissez les spécificités du logiciel. Les exigences sont affinées en détail, une conception détaillée est créée qui décrit l'architecture du logiciel, et les risques potentiels associés au projet sont identifiés et évalués. Les modèles de conception sont définis initialement à un niveau élevé pour représenter les diverses facettes de l'architecture de la solution en cours de développement à un niveau de portée donné. La portée pourrait être celle d'une entreprise entière, d'un portefeuille de solutions envisagées par une unité commerciale, ou d'une solution spécifique développée par une unité commerciale dans le cadre d'un projet donné. Les facettes architecturales sont généralement basées sur des domaines architecturaux spécifiés dans les cadres d'architecture courants. Par exemple, The Open Group Architecture Framework (TOGAF) divise les représentations d'architecture de haut niveau en quatre domaines : architecture métier, architecture d'application, architecture de données/informations/connaissances/sagesse, et architecture d'infrastructure. Divers langages de modélisation de haut niveau et outils associés peuvent être utilisés pour faciliter la création de modèles d'architecture de haut niveau (par exemple, Archimate Certified Tools de TOGAF4). La gestion des architectures d'entreprise et de solution est décrite plus en détail dans le Chapitre 10 Gestion des architectures d'entreprise et de solution de ce livre.

Un modèle de conception détaillée peut ensuite être dérivé du modèle d'architecture de haut niveau, et il est généralement représenté en utilisant une combinaison de langages de modélisation de bas niveau (par exemple, BPMN, UML, SysML). À ce niveau de conception, une solution conceptuelle qui répond aux exigences est créée et cherche à répondre à la question « Comment le système répondra-t-il aux exigences ? » La solution conceptuelle tire parti des entrées collectées dans la phase d'initialisation pour concevoir un produit logiciel. Cette information est généralement organisée en deux types de conception : logique et physique.

La conception logique ignore tout aspect physique. Par exemple, un système de régulateur de vitesse doit suivre la vitesse maximale sélectionnée et si le système de régulateur de vitesse est activé ou désactivé. Cette information est recueillie dans le cadre de la conception logique et doit être capturée via un diagramme qui identifie également les relations correspondantes. Ce type d'information est souvent capturé comme un ensemble d'entités (ou d'acteurs) qui permettent le regroupement d'informations descriptives et d'attributs.

Une représentation graphique de la méthode pour implémenter efficacement ce qui a été déterminé dans la conception logique d'une solution logicielle est une conception physique (physical design). Elle inclut la définition de l'origine et de la destination des informations au sein du système planifié. Elle inclut la définition de la manière dont les informations sont obtenues, traitées et/ou présentées. Par exemple, la conception physique pour activer ou désactiver le système de régulateur de vitesse dans une automobile peut inclure l'utilisation de commandes mises à la disposition du conducteur sur le volant pour activer ou désactiver le régulateur. Il pourrait également y avoir des commandes via l'appui sur la pédale de frein pour désactiver le système.

Le travail sur les conceptions logiques et physiques est généralement effectué d'abord comme une action d'génie logiciel de conception de haut niveau, suivie d'une action d'génie logiciel de conception détaillée. L'objectif de l'action d'génie logiciel de conception de haut niveau (HLD) (high-level design (HLD)) est de fournir une description générale de la conception globale du système, et peut inclure des informations sur les aspects généraux d'un système, y compris son architecture, ses données, ses systèmes, ses services et ses plateformes, ainsi que les relations entre les différents modules et composants. Son objectif est de convertir les exigences en une représentation de haut niveau de la solution qui pourra ensuite être affinée dans le cadre de la conception détaillée.

L'objectif de l'action d'génie logiciel de conception détaillée (DLD) (detail-level design (DLD)) est de détailler ou d'étendre la HLD. Dans le cadre de la DLD, chaque élément d'un système est fourni avec des spécifications détaillées, et la logique de chaque composant au sein de chaque module d'une solution système est déterminée. La DLD est ensuite utilisée pour implémenter la solution réelle dans le cadre de la phase de construction du processus logiciel.

Voici quelques-unes des différences entre HLD et DLD :

  • La HLD donne des descriptions de haut niveau de la fonctionnalité, tandis que la DLD donne des détails de la logique fonctionnelle au sein de chaque composant d'un système.
  • La HLD est créée en premier, la DLD étant créée comme une extension de la HLD.
  • La HLD est basée sur les exigences de la solution logicielle, tandis que la DLD est basée sur l'extension de la HLD. La DLD doit cependant toujours s'aligner sur les exigences.
  • La HLD fournit des éléments tels que la conception des données et des informations, tandis que la DLD fournit les informations nécessaires pour créer la spécification de programmation réelle et le plan de test pour l'utilisation des données.
  • Un architecte de solution est généralement impliqué dans la HLD. Les programmeurs et les concepteurs sont généralement impliqués dans la DLD.
Produit de travail d'architecture logicielle

Le produit de travail d'architecture logicielle agit comme un plan de la solution en cours de développement. Imaginez que vous construisez une maison. Avant le début de la construction, vous créeriez un plan qui décrirait la structure globale, les composants majeurs (fondations, murs, toit) et la façon dont ils s'assemblent. Ce plan est similaire à une architecture logicielle. Dans le développement logiciel, une architecture logicielle (software architecture) fournit une vue d'ensemble de haut niveau d'un système logiciel. Elle décrit les principaux composants du système, leurs interrelations et la façon dont ils fonctionnent ensemble. Cette représentation de haut niveau aide les développeurs à comprendre la conception globale avant de se plonger dans les détails.

Une solution est généralement représentée à différents niveaux d'abstraction. La conception logicielle implique l'utilisation d'architectures logicielles pour représenter des solutions à un niveau d'abstraction élevé. Une architecture logicielle constitue une vue relativement petite et intellectuellement compréhensible de la façon dont une solution est structurée et de la façon dont ses composants fonctionnent ensemble. L'objectif de la modélisation de l'architecture logicielle est de permettre à l'ingénieur logiciel de visualiser et d'évaluer le système dans son ensemble avant de passer à la conception des composants. Cette étape permet à l'ingénieur logiciel de :

  • s'assurer que le modèle de conception englobe les diverses exigences de la solution
  • permettre d'examiner diverses alternatives de conception dès le début pour faciliter l'adoption du meilleur modèle possible
  • limiter le risque de construire un logiciel qui ne répond pas aux exigences

Lorsque vous examinez un plan, vous pouvez voir les éléments majeurs d'un bâtiment et leurs relations entre eux. Lorsque vous examinez un système logiciel à un niveau d'abstraction élevé, tel que le niveau extrêmement élevé montré dans la Figure 9.7 d'un navigateur web, vous pouvez voir ses principaux composants et les connexions principales entre eux. Par exemple, à un niveau élevé, un navigateur web se connecte à un serveur web via des requêtes HTTP, et le serveur web interagit avec une base de données relationnelle via des requêtes SQL pour créer une page web HTML qui est rendue dynamiquement et renvoyée au navigateur web pour affichage.

Graphique montrant une connexion en boucle d'un navigateur web, vers HTTP, vers un serveur web, vers SQL, vers une base de données, vers un serveur web, et de retour vers le navigateur web.
Figure 9.7 L'architecture logicielle affiche les principaux composants d'un système (dans ce cas, navigateur web, serveur web et base de données) et les connexions (requêtes HTTP et requêtes SQL) à un niveau d'abstraction élevé. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'architecture logicielle est une partie importante de la création d'une solution logicielle, et elle doit toujours être conçue par un ingénieur logiciel expérimenté, car les changements dans l'architecture logicielle ont généralement des effets drastiques sur l'implémentation de la solution, tels que la construction de solutions qui ne répondent pas aux exigences non fonctionnelles (nonfunctional requirement).

Lors de la conception d'une architecture logicielle, vous pouvez tirer parti de divers types de motifs (pattern) logiciels qui facilitent la réutilisation de solutions préexistantes. Deux exemples de tels motifs sont un style architectural et un motif architectural ou patron de conception (design pattern). Un style architectural est une transformation imposée à la conception d'un système entier. L'intention est d'établir une structure pour tous les composants du système. Les motifs architecturaux ou de conception imposent également une transformation à la conception d'une architecture, mais ils diffèrent d'un style car ils opèrent à un niveau d'abstraction inférieur. Les motifs peuvent être utilisés conjointement avec un style architectural qui façonne la structure globale d'un système.

Une architecture logicielle est l'un des produits de travail qui résultent de l'action d'génie logiciel HLD. Les architectures logicielles sont des produits de travail importants car elles fournissent des représentations de haut niveau des solutions qui facilitent la communication entre toutes les parties prenantes. Elles mettent également en évidence les décisions de conception précoces qui ont un impact profond sur tous les travaux d'génie logiciel qui suivent.

En ce qui concerne les processus logiciels agiles, l'objectif de la création de produits de travail d'architecture logicielle dans le cadre de l'action d'génie logiciel HLD est d'éviter les reprises. Dans ce cas, les récits utilisateurs sont exploités pour créer et faire évoluer un modèle architectural (parfois appelé « squelette fonctionnel ») avant de construire le logiciel. L'utilisation de processus logiciels agiles rend parfois difficile la gestion de la conception architecturale, en particulier lorsque l'équipe développe de grands systèmes à partir de zéro plutôt que d'ajouter de petits services au coup par coup à un système existant. Les approches agiles se concentrent généralement sur de petits incréments pour lesquels il peut être difficile de produire une architecture englobante qui pourra accueillir des incréments ultérieurs qui n'ont pas encore été complètement définis. Cela peut conduire à devoir refactoriser l'architecture, ce qui pourrait être très coûteux, car cela peut nécessiter de modifier une grande partie du code déjà développé. Par conséquent, il est recommandé aux équipes d'examiner attentivement la conception architecturale lorsqu'elles entreprennent de grands projets qui ne s'appuient pas sur une architecture déjà définie et solide. Cela soulève la question de savoir si la conception préalable détaillée (BDUF) (big design up front (BDUF)) est la méthode préférée dans ce cas. C'est aussi la raison pour laquelle les équipes agiles devraient inclure des ingénieurs logiciels ayant une solide expérience en architecture (idéalement, en architecture d'entreprise), qui peuvent prévoir le type de conceptions nécessaires pour éviter des efforts de refactorisation (refactoring) coûteux à l'avenir.

Les modèles de processus agiles Scrum (Scrum) et Kanban Agile (Kanban Agile), comme vous l'apprendrez plus tard dans le chapitre, permettent aux architectes logiciels d'ajouter des récits utilisateurs au storyboard évolutif et de travailler avec le propriétaire du produit pour prioriser leurs récits architecturaux en unités de travail appelées sprints. Les projets agiles bien gérés incluent la livraison de la documentation d'architecture logicielle pendant chaque sprint. Une fois le sprint terminé, l'architecte examine le prototype fonctionnel pour en vérifier la qualité avant que l'équipe ne le présente aux parties prenantes lors d'une revue de sprint formelle.

Comme mentionné précédemment, l'objectif de l'action d'génie logiciel HLD est de fournir une description générale de la conception globale du système. Elle peut inclure des informations sur les aspects généraux d'un système, y compris son architecture, ses données, ses systèmes, ses services et ses plateformes, ainsi que les relations entre les différents modules et composants. Son objectif est atteint en convertissant les exigences en une solution de haut niveau qui peut ensuite être affinée dans le cadre de l'action d'génie logiciel de conception de bas niveau (LLD).

Conception logicielle

L'abstraction et l'affinage des exigences en une spécification qui peut être utilisée pour aider à créer une solution logicielle est appelée conception logicielle (software design). La conception logicielle est un ensemble de tâches de génie logiciel (software engineering) qui fait partie de l'action d'génie logiciel DLD. L'objectif de l'action d'génie logiciel DLD est de détailler ou d'étendre les produits de travail HLD. Dans le cadre de l'action d'génie logiciel DLD, chaque élément d'un système est fourni avec des spécifications détaillées, et la logique de chaque composant au sein de chaque module d'une solution est déterminée.

La conception logicielle nécessite généralement des compétences en résolution de problèmes ainsi que la capacité de conceptualiser le cadrage et de le définir en une spécification fonctionnelle qui peut être utilisée pour créer une solution logicielle. Contrairement à l'action d'génie logiciel HLD, l'ensemble de tâches de conception logicielle LLD concerne tous les détails d'implémentation. Dans les approches agiles, nous reportons généralement de nombreuses décisions de conception jusqu'au moment de l'implémentation et ne concevons à l'avance que les parties délicates ou qui doivent être résolues d'une manière inhabituelle.

Les principaux concepts qui guident la conception logicielle sont :

  • Abstraction : représentation de haut niveau de composants tels que les données (ou objets de données) et les procédures (la séquence d'instructions qui ont généralement une fonction spécifique et limitée)
  • Architecture : structure ou organisation globale des composants logiciels, modes d'interaction des composants et structure des données utilisées par les composants ; l'génie logiciel basée sur les composants (CBSE) peut être considérée comme un ensemble de tâches dans le cadre de l'action d'génie logiciel DLD pour assembler des solutions basées sur la réutilisation de composants préexistants
  • Patrons de conception : une structure de conception qui résout un problème de conception bien défini dans un contexte spécifique ; la conception basée sur les patrons peut être considérée comme un ensemble de tâches dans le cadre de l'action d'génie logiciel DLD pour assembler des solutions à l'aide de patrons d'implémentation et de cadriciels
  • Séparation des préoccupations : une technique basée sur l'idée que tout problème complexe peut être traité plus facilement s'il est subdivisé en morceaux
  • Modularité : compartimentalisation des données et des fonctions
  • Masquage de l'information : interfaces contrôlées qui définissent et appliquent l'accès aux détails procéduraux des composants et à toute structure de données locale utilisée par le composant
  • Indépendance fonctionnelle : composants à objectif unique (forte cohésion) avec une aversion pour l'interaction excessive avec d'autres composants (faible couplage)
  • Raffinement par étapes : élaboration incrémentielle des détails pour toutes les abstractions
  • Refactorisation : une technique de réorganisation qui simplifie la conception sans modifier la fonctionnalité
  • Classes de conception : fournissent des détails de conception qui permettront d'implémenter les classes d'analyse

Les produits de travail générés dans le cadre de l'action d'génie logiciel DLD sont utilisés pour construire la solution réelle. Il existe de nombreux autres ensembles de tâches qui pourraient être considérés dans le cadre de la DLD, y compris le prototypage, la conception de l'expérience utilisateur et de l'interface utilisateur, et des ensembles de tâches de conception spécifiques pour les solutions web, mobiles, sociales et de jeux.

Réflexion

Poser les bonnes questions

En 1998, le Mars Climate Orbiter a été lancé vers Mars pour étudier son climat. Malheureusement, l'atterrisseur n'a jamais pu accomplir sa tâche. La sonde a fini par être détruite par l'atmosphère martienne en raison d'une erreur dans les calculs mathématiques. Cependant, le problème ne résidait pas dans les calculs mais dans le système de numération utilisé pour les mesures de distance. Le logiciel de la sonde utilisait le système métrique, mais l'équipe de la Terre qui a envoyé les données à la sonde a envoyé ses valeurs en unités impériales. Le résultat fut une sonde détruite.

S'agissait-il d'une erreur de conception ? Qu'aurait-on pu faire pour éviter une erreur telle que l'utilisation d'un mauvais système de mesure ?

Activité cadre de construction

Dans le cadre de la phase de construction (construction phase) ou activité cadre, les documents de conception résultant de l'action d'génie logiciel DLD de l'activité cadre d'élaboration sont utilisés pour écrire le code source correspondant dans un langage de programmation ainsi que pour créer tous les actifs de support tels que les images de conteneurs déployables, les bases de données et les contrôles. C'est là que la magie du codage opère ! Les développeurs travaillent à construire le logiciel sur la base de la conception créée précédemment. Cette phase implique l'écriture de code, le test des composants individuels et la correction des défauts/bogues (bug).

Le code source peut également être généré automatiquement à partir des produits de travail de conception à l'aide d'outils d'ingénierie aller-retour, bien que ce type de fonctionnalité soit encore limité aujourd'hui. La méthodologie de développement de l'ingénierie dirigée par les modèles, compatible avec les méthodes agiles, souligne l'importance des spécifications formelles et exécutables des modèles d'objets et la capacité à vérifier l'exactitude et l'exhaustivité de la solution en exécutant les modèles. Cela est généralement rendu possible en utilisant des outils et des cadres d'ingénierie de conception aller-retour qui permettent la spécification de modèles à l'aide de notations de modélisation standard et la création de logiciels évolutifs à partir de ces modèles (par exemple, jBPM5).

Le résultat de la phase de construction est une solution complète et fonctionnelle qui est basée sur les produits de travail de conception et répond aux attentes définies dans la phase d'initialisation. Il convient de noter que le codage est une excroissance mécaniste de la conception procédurale, et des erreurs peuvent être introduites lorsque les produits de travail de conception DLD sont traduits dans un langage de programmation. Cela est particulièrement vrai si le langage de programmation ne prend pas directement en charge les structures de données et de contrôle représentées dans la conception. Les revues de code sont conçues pour éviter cela.

Le domaine du DevOps, une vaste collection de pratiques de développement et d'opérations, a introduit de nouveaux processus et infrastructures pour automatiser de nombreuses actions d'génie logiciel qui font partie de la phase de construction. Lorsque ces méthodologies ont été appliquées ensemble, les méthodologies agiles et l'automatisation de DevOps ont augmenté la vitesse, la robustesse et l'extensibilité (scalability) avec lesquelles les logiciels peuvent être construits.

Les ingénieurs logiciels utilisent de nombreux outils pour implémenter des solutions. Ceux-ci incluent des éditeurs de code tels qu'Atom, des environnements de développement intégrés (IDE) tels que VSCode ou Visual Studio, des systèmes de gestion de versions (version control system) tels que Git, des outils de débogage, des outils de test, et bien plus encore.

Tests unitaires, d'intégration et système

Les tests unitaires, d'intégration et système (system testing) visent à garantir et à vérifier que le système logiciel fonctionne comme prévu. Ils impliquent généralement des activités visant à découvrir les erreurs commises par inadvertance pendant les phases d'élaboration et de construction. Les revues de code et les tests unitaires, d'intégration et système sont généralement effectués dans le cadre de la phase de construction par les développeurs logiciels responsables de l'écriture du code source. Le processus par lequel le code source écrit par un développeur est inspecté manuellement par un autre développeur est appelé revue de code (code review). Ceci est particulièrement utile lorsque l'équipe logicielle est composée de développeurs ayant des niveaux d'expérience différents.

Il convient de noter que si les SDLC incluent souvent des ensembles de tâches de test au sein de phases spécifiques, le test est une activité qui devrait se dérouler de manière répétée tout au long du processus logiciel, indépendamment de la phase réelle (ou de son itération) en cours d'exécution.

Activité cadre de déploiement

Le déploiement est la phase qui rend le logiciel disponible aux utilisateurs. Enfin, le logiciel est livré aux utilisateurs ! Cette phase implique la livraison du logiciel à son public cible (par exemple, le lancement d'une application mobile sur un magasin d'applications) et la fourniture d'un support continu pour résoudre les bogues ou les problèmes qui surviennent après le déploiement. Dans le passé, le déploiement (deployment) signifiait souvent l'installation du logiciel sur l'ordinateur d'un client. Aujourd'hui, le logiciel (software) est plus susceptible d'être installé sur des ordinateurs spéciaux ou des systèmes en ligne puissants appelés serveurs cloud. Lors du déploiement de logiciels, une certaine configuration peut être nécessaire, en particulier pour les applications complexes. DevOps utilise l'automatisation pour rendre le déploiement plus rapide et plus fiable. Les logiciels modernes sont souvent mis à jour fréquemment à l'aide d'outils et de techniques spéciales. Comme indiqué, le déploiement, surtout s'il s'agit d'une tâche non triviale qui ne devrait pas être effectuée par le client, implique généralement la configuration de la solution logicielle. Dans un processus de configuration typique, la solution logicielle est conteneurisée (containerized), ou empaquetée de manière à pouvoir fonctionner facilement sur différents systèmes informatiques, puis déployée via un système, appelé clusters Kubernetes, qui gère automatiquement l'extensibilité et la disponibilité (availability).

Le domaine du DevOps a introduit des processus et des infrastructures supplémentaires pour automatiser de nombreuses actions d'génie logiciel qui font partie de la phase de déploiement. Ensemble, les méthodologies agiles et l'automatisation de DevOps ont augmenté la vitesse, la robustesse et l'extensibilité avec lesquelles les logiciels peuvent être déployés aujourd'hui. Il convient de noter que les techniques de déploiement des applications modernes ont considérablement évolué grâce à l'automatisation de DevOps. Les mises à jour logicielles sont déployées fréquemment aujourd'hui à l'aide de techniques et d'outils d'intégration et de déploiement continus (CI/CD).

Maintenance

La plupart des logiciels déployés devront éventuellement être mis à jour pour ajouter de nouvelles exigences ou corriger des problèmes qui pourraient survenir. Le processus de mise à jour d'un logiciel après son déploiement est appelé maintenance (maintenance). Comme mentionné précédemment, la maintenance est une action d'génie logiciel qui fait partie de la phase de déploiement du processus logiciel. Le coût de la maintenance peut dépasser celui du développement, surtout si le logiciel reste utilisé pendant une longue période.

Vous pouvez considérer le processus de création de logiciels comme analogue à celui de la construction d'une nouvelle voiture. La maintenance du logiciel est comme la maintenance de la voiture pendant que vous l'utilisez. Pour rendre l'analogie plus précise, bien que le logiciel ne s'use pas comme le matériel d'une voiture, sa maintenance implique des mises à jour pour corriger les bogues et l'ajout de nouvelles fonctionnalités à mesure que les exigences changent. La construction d'une nouvelle voiture peut prendre plusieurs semaines, mais l'entretien de la voiture durera probablement beaucoup plus longtemps car la voiture peut être utilisée pendant des années. Quant aux dépenses, la construction d'une nouvelle voiture coûtera un montant important, mais les coûts liés à sa maintenance dépasseront facilement le prix de la voiture neuve. Bien sûr, lorsque les coûts d'entretien d'une voiture deviennent trop élevés, il y a toujours l'option d'acheter une nouvelle voiture, tout comme il y a l'option de construire un nouveau produit logiciel si la maintenance du logiciel hérité (legacy software) devient trop élevée.

Dans les modèles de processus agiles, une grande partie de la maintenance ne se limite pas à l'ajout de nouvelles fonctionnalités. Au lieu de cela, elle implique souvent ce qui suit :

  • utiliser des sprints Scrum pour planifier le travail et répondre aux besoins des clients sans submerger les développeurs
  • donner la priorité aux demandes urgentes des clients et permettre les interruptions correspondantes des sprints de maintenance planifiés pour répondre à ces demandes urgentes
  • permettre aux membres de l'équipe de prioriser le traitement des demandes des clients et de coordonner leur traitement dans le cadre du processus de maintenance
  • combiner l'utilisation de réunions et de documentation écrite pour minimiser la durée et la fréquence des réunions et les maintenir ciblées
  • s'appuyer sur des cas d'utilisation informels lors de la communication avec les parties prenantes pour compléter les documentations existantes et maintenir une communication simple
  • exiger que les développeurs vérifient le travail des autres ; en particulier, les développeurs expérimentés devraient examiner le travail produit par les développeurs juniors, tels que les corrections de défauts ou le code ajouté pour prendre en charge de nouvelles fonctionnalités, pour les aider à développer leurs connaissances

Activités transversales/cadres

En plus des activités cadre de processus principales, à savoir l'initialisation, l'élaboration, la construction et le déploiement, de nombreuses activités peuvent avoir lieu à tout moment pendant la création d'une solution et tout au long du processus logiciel – en d'autres termes, elles traversent le processus. Pour comprendre l'importance de ces activités, considérons cette analogie. En plus de terminer les étapes principales de la construction d'une maison (par exemple, la construction des fondations, des murs, du toit), il y a d'autres activités importantes qui se déroulent tout au long du projet (par exemple, le choix des couleurs de peinture murale). Celles-ci sont comme le parapluie que vous utiliseriez un jour de pluie – elles soutiennent l'ensemble du processus mais ne font pas partie des étapes de construction principales elles-mêmes. Dans le développement logiciel, une activité transversale (crosscutting activity), ou une activité transversale (umbrella activity), est une activité qui traverse l'ensemble du processus de développement logiciel mais ne fait pas partie des étapes de construction principales elles-mêmes. Elles peuvent inclure la communication et la formation, la gestion et la planification des risques, la gestion du contenu de la configuration logicielle, la gestion de la qualité, la gestion de l'architecture et l'ingénierie de la sécurité (security) logicielle.

Communication et formation

Établir la communication implique de planifier des réunions régulières entre les développeurs et les clients et également de rencontrer les développeurs pour les former aux nouvelles technologies. Il est nécessaire de communiquer avec les parties prenantes et les clients à divers moments du processus de développement logiciel. Par exemple, la collecte des exigences du projet pendant la phase d'initialisation implique une communication et une coordination entre les chefs de projet et les parties prenantes. Les notes de version servent d'autre forme de communication, et elles sont écrites pour les utilisateurs du logiciel afin de les informer des fonctionnalités incluses dans une nouvelle version. Plus généralement, l'état d'un projet doit être communiqué à la direction à intervalles réguliers pour s'assurer que les jalons satisfaisants sont atteints conformément au plan.

Une communication régulière a également lieu au sein des équipes de développement logiciel. Par exemple, les revues de conception encouragent la communication pour aider à finaliser les conceptions. Les revues de code se concentrent sur la communication des changements du système et sur la manière de résoudre les problèmes et d'améliorer le code. Les stand-ups quotidiens dans les processus logiciels agiles concernent une communication verbale concise.

Les membres de l'équipe d'génie logiciel doivent suivre une formation régulière pour acquérir ou maintenir certaines compétences. Pour soutenir cela, les équipes de développement logiciel mettent généralement en place des méthodologies et des cadres de transformation du changement organisationnel (par exemple, le processus Prosci en 3 phases) pour gérer leur capacité à mener à bien des projets compte tenu de la nature changeante de l'génie logiciel.

Gestion et planification des risques

La gestion et la planification des risques se concentrent sur l'identification des risques potentiels, tels que les retards de projet, et sur l'élaboration d'un plan pour y faire face. Le développement logiciel est une activité complexe qui implique de nombreuses personnes travaillant sur une longue période, et il s'avère que tous les projets ne réussissent pas. Certains projets sont retardés, certains dépassent le budget et certains ne sont jamais terminés. Le pourcentage élevé de projets infructueux crée un besoin de gestion et d'atténuation des risques. La minimisation des risques est généralement la tâche principale d'un gestionnaire, mais les ingénieurs logiciels peuvent également assumer des tâches de gestion. Par exemple, pour aider les gestionnaires, ils peuvent fournir des mises à jour qui permettent aux gestionnaires d'affiner leurs évaluations des risques. Idéalement, ces mises à jour aborderaient les différentes composantes du risque, notamment :

  • Risque de performance : considère si le produit ne conviendra pas à l'usage prévu
  • Risque de coût : détermine si les contraintes budgétaires peuvent être maintenues
  • Risque de support : évalue la facilité de maintenance et de mise à jour du produit une fois terminé
  • Risque de calendrier : considère si le projet respectera les délais prévus

La projection des risques tente d'associer à chaque risque la probabilité de son occurrence et les conséquences des problèmes qui en résultent si un risque devait se produire. L'un des modèles de processus logiciel que vous découvrirez plus en détail plus tard dans ce chapitre est appelé le Processus Unifié. Dans ce processus, les risques sont atténués en sélectionnant les exigences risquées pour les premières itérations. Par exemple, un cas d'utilisation qui nécessite une nouvelle technologie est généralement considéré comme risqué, ainsi qu'un cas d'utilisation qui suppose une intégration avec du code hérité. Nous sélectionnons de tels cas d'utilisation pour une itération précoce car si leur implémentation échoue, il est préférable d'échouer au début du projet plutôt qu'à la fin.

À mesure que le projet progresse, les gestionnaires se concentrent sur la minimisation des risques à travers les quatre P : les personnes impliquées, le produit en développement, le processus suivi et le travail de projet en cours. Bien que les processus logiciels agiles et traditionnels utilisent des approches différentes, les objectifs de chacun sont les mêmes : contrôler les risques en fournissant aux personnes un produit bien défini et des processus clairs à suivre. Ces objectifs permettent aux ingénieurs logiciels d'estimer le travail requis et de suivre le produit tout au long du développement. Les gestionnaires comparent le produit terminé à ces estimations et utilisent ces résultats pour apporter les ajustements nécessaires.

La technologie au quotidien

Livrer des systèmes viables

Le développement de logiciels se concentre souvent sur trois domaines : la désirabilité, la capacité et la viabilité. En d'autres termes, l'accent est mis sur ce qui est voulu, ce qui est possible et ce qui se vendra ou aidera une entreprise à fonctionner. Pour réussir, un produit logiciel doit offrir quelque chose que les gens veulent et qui a de la valeur. Il doit également être possible d'implémenter le produit.

Dans les années 1980, le premier logiciel de réalité virtuelle a été lancé. La RV était quelque chose que beaucoup de gens voulaient et y voyaient une valeur ; cependant, la technologie n'était pas capable de fournir un système viable. Ce n'est qu'aujourd'hui que les capacités logicielles et matérielles peuvent prendre en charge la RV à un niveau qui permet de livrer des produits pour lesquels les gens sont prêts à payer.

Quels sont les autres domaines technologiques qui sont viables aujourd'hui et qui ne l'étaient pas il y a dix ans ? Quelles sont les technologies logicielles qui ne sont pas viables aujourd'hui et qui pourraient l'être dans les dix prochaines années ?

Gestion de la configuration et du contenu logiciel

La gestion de la configuration logicielle (SCM) est une activité transversale qui aide à signaler, identifier et contrôler les changements apportés aux éléments en développement géré. Ces éléments sont appelés éléments de configuration logicielle (SCI). La SCM analyse également l'implémentation des changements et fournit des mécanismes pour publier et déployer les changements. Une façon de renforcer l'importance de la gestion de la configuration sans client réel est de modifier les exigences du projet quelque temps après le début de l'implémentation du projet.

La SCM se concentre généralement sur quatre domaines principaux :

  • Identification de la configuration : l'identification de tous les composants d'un projet, y compris les fichiers, documents, fichiers de code source, structures de répertoires, et plus encore.
  • Contrôles des changements de configuration : le contrôle de l'accès aux éléments d'un projet et le suivi des changements effectués.
  • Comptabilité de l'état de la configuration : le suivi de qui a effectué un changement, quand il l'a effectué et pourquoi il a été effectué.
  • Audit de configuration : le suivi de l'état d'un projet et, plus important encore, le suivi et la confirmation que ce qui est créé correspond à ce qui est requis.

De nombreuses équipes agiles utilisent l'intégration continue pour s'assurer qu'elles disposent toujours de prototypes viables prêts à être testés et étendus. Les avantages de l'intégration continue sont les suivants :

  • implique des retours fréquents pour notifier rapidement les développeurs lorsque les tests d'intégration échouent afin qu'ils puissent résoudre les problèmes le plus rapidement possible, surtout si le nombre de corrections requises est faible
  • améliore la qualité en étant capable de traiter rapidement les changements de produit ; en conséquence, les utilisateurs peuvent avoir confiance que le produit répond à leurs besoins
  • réduit les risques en évitant de longs délais entre le moment où le logiciel est développé et son intégration dans le produit ; cela garantit que les défaillances de conception peuvent être détectées et corrigées tôt
  • implique des rapports à jour pour s'assurer que le logiciel est correctement configuré pour se conformer, par exemple, aux dernières métriques d'analyse de code
  • garantit que l'intégration rationalisée est utilisée comme technologie de support clé dans les organisations qui utilisent des modèles de processus logiciels agiles
  • capture les défauts le plus tôt possible dans le processus d'génie logiciel, ce qui limite le coût du développement logiciel

Divers outils peuvent être utilisés pour soutenir la SCM, y compris des outils de gestion d'audit (par exemple, ZenHub), des outils de gestion/automatisation de la configuration (par exemple, Ansible, Vagrant), des outils d'intégration continue (par exemple, Jenkins, Travis CI), des outils de suivi des dépendances et de gestion des changements (par exemple, Basecamp, Jira), des outils de gestion de code source (par exemple, GitHub), et ainsi de suite.

La gestion de contenu comprend des sous-systèmes de collecte, de gestion et de publication. Le sous-système de collecte facilite la création et l'acquisition de nouveau contenu. Il permet également aux humains de se rapporter au contenu et le combine en unités qui peuvent être affichées plus efficacement côté client. Le sous-système de gestion fournit un référentiel pour les capacités de stockage de contenu, y compris la base de données de contenu (c'est-à-dire la structure d'information utilisée pour organiser tous les objets de contenu), les capacités de la base de données (par exemple, des fonctions pour rechercher des objets de contenu, stocker et récupérer des objets, et gérer la structure des fichiers de contenu), et les fonctions de gestion de la configuration (par exemple, prend en charge l'identification des objets de contenu, le contrôle de version, la gestion des changements, l'audit des changements et le reporting). Le sous-système de publication extrait le contenu du référentiel, le convertit en une forme publiable et le formate afin qu'il puisse être affiché dans un navigateur web (par exemple, Chrome, Safari). Le sous-système de publication utilise une série de modèles pour chaque type, y compris des éléments statiques (par exemple, texte, graphiques, médias et scripts qui ne nécessitent aucun traitement ultérieur sont transmis directement côté client), des services de publication (c'est-à-dire des appels de fonction à des services de récupération et de formatage spécifiques qui personnalisent le contenu, effectuent la conversion des données et construisent des liens de navigation appropriés), et des services externes qui donnent accès à l'infrastructure d'information d'entreprise externe, telle que les données d'entreprise ou les applications « back-office ».

Gestion de la qualité logicielle

Alors que les tests valident que les choses fonctionnent comme prévu et qu'il n'y a pas d'erreurs ou de problèmes, la gestion de la qualité logicielle (SQM) (Software Quality Management (SQM)) se concentre sur le développement et la gestion de la qualité de la solution en cours de développement. Les tâches au sein de la SQM impliquent la planification de la qualité et le contrôle de la qualité. Elles incluent, sans s'y limiter, des activités telles que :

  • confirmer que les exigences sont correctes, complètes et cohérentes
  • vérifier que tous les éléments de conception sont conformes aux exigences et sont de haute qualité
  • confirmer que le code source suit les normes de codage et est écrit de manière à être maintenable à l'avenir
  • s'assurer que les tests vérifient tous les éléments d'une solution
  • implémenter un plan de gestion des changements

L'ingénierie de logiciels de qualité suppose une compréhension approfondie des exigences de la solution et la capacité de concevoir des produits de travail conformes à ces exigences. Ces activités doivent s'appuyer sur l'utilisation des bonnes pratiques de génie logiciel (software engineering) et doivent être soutenues par une gestion de projet adéquate.

Les revues d'évaluation (par exemple, évaluations d'ingénierie système, évaluations de planification de projet logiciel, évaluations de modèles d'analyse, évaluations de modèles de conception, évaluations de code source, évaluations de tests logiciels et évaluations de maintenance) sont un mécanisme important d'assurance qualité. L'assurance qualité logicielle (SQA) fait partie d'un large éventail d'activités de gestion de la qualité logicielle qui se concentrent sur les techniques permettant d'atteindre et/ou d'assurer des logiciels de haute qualité.

Gestion de l'architecture

Pour reprendre l'analogie selon laquelle l'architecture logicielle est comme le plan d'une maison, la gestion de l'architecture logicielle peut alors être comparée à l'amélioration du plan au fur et à mesure que vous l'utilisez pour construire la maison. Autrement dit, la création du plan (architecture) n'était que la première étape. Dans le développement logiciel, la gestion de l'architecture (architecture management) implique de suivre le plan et de s'assurer qu'il reste à jour au fur et à mesure que le logiciel est construit. Cela permet d'éviter des problèmes ultérieurs. Alors que la HLD est une action d'génie logiciel qui a lieu dans la phase d'élaboration du processus logiciel, l'activité cadre de gestion de l'architecture englobe un ensemble de techniques de gestion et d'affinements architecturaux qui peuvent aider à améliorer la conception architecturale pendant son développement.

Les efforts de gestion de l'architecture peuvent être effectués à tout moment du cycle de vie du logiciel, ce qui explique pourquoi la gestion de l'architecture est une bonne activité cadre ; elle maintient les connaissances nécessaires pour qualifier la « bonté » des solutions du point de vue de la conception, et elle est traitée séparément de l'activité cadre de gestion de la qualité.

Il existe des outils spéciaux qui peuvent aider à la gestion de l'architecture. Similaire à l'utilisation de logiciels pour dessiner le plan d'une maison, ces outils peuvent aider à stocker et à organiser les informations d'architecture et à faciliter leur compréhension par tous ceux qui travaillent sur le projet. Des exemples de tels outils incluent les outils de gestion d'artefacts/packages (par exemple, Docker Hub6, JFrog Artifactory7) et les catalogues de motifs.

Ingénierie de la sécurité logicielle

L'ingénierie de la sécurité (security) logicielle se concentre sur la protection des actifs logiciels contre les menaces. Les menaces exploitent généralement les vulnérabilités logicielles pour compromettre la confidentialité et l'intégrité des données. Les menaces peuvent également compromettre la disponibilité (availability) des systèmes logiciels en perturbant l'accès aux services système et aux données associées.

Les architectures logicielles doivent être conçues pour répondre aux exigences de sécurité et éliminer les vulnérabilités qui peuvent conduire à des exploits. Diverses techniques de conception peuvent être utilisées par les ingénieurs logiciels pour faire face à la possibilité et aux effets des attaques afin de minimiser les pertes et les coûts associés. À titre d'exemple, le modèle de processus SQUARE de Microsoft fournit un moyen d'obtenir, de catégoriser et de hiérarchiser l'ingénierie des exigences de sécurité pour les systèmes à forte intensité logicielle.

Faire face aux menaces de cybersécurité s'avère difficile pour les entreprises de nos jours en raison d'un manque de ressources formées et d'une demande accrue de conformité en matière de sécurité. Les approches traditionnelles de la sécurité ne sont plus viables pour garantir que les organisations peuvent continuer à fonctionner et à développer des solutions compétitives. C'est pourquoi de nombreuses entreprises combinent des modèles de processus logiciels traditionnels ou des modèles de processus agiles avec des approches modernes, telles que DevSecOps, pour gérer l'ingénierie de la sécurité logicielle. L'utilisation de DevSecOps nécessite l'adoption de nouveaux processus et outils ainsi que la formation du personnel. L'approche DevSecOps automatise le support de la sécurité tout au long du SDLC, ce qui réduit le temps et les coûts de développement et facilite l'intégration des équipes de sécurité et de développement.

Quelques exemples d'outils de sécurité DevOps sont Aqua Security et HashiCorp Vault, et des exemples d'outils DevSecOps sont SonarQube et XebiaLabs.

Modèles de processus logiciels populaires

Les activités cadre (ou phases) qui ont été présentées dans le cadre du processus cadre sont des phases générales qui sont appliquées dans les modèles de processus logiciels/SDLC. Les types d'actions d'génie logiciel qui sont appliquées à chaque phase dépendent du modèle de développement logiciel utilisé pour le projet en cours.

Il existe une multitude de modèles SDLC. Ces modèles ont évolué au fil du temps et offrent diverses approches pour créer des solutions logicielles. Certains SDLC plus traditionnels sont prescriptifs en termes d'actions d'génie logiciel qui doivent être menées, tandis que d'autres sont agiles. L'agilité, comme vous le savez maintenant, a trait à la capacité de sauter certaines actions d'génie logiciel ou de rendre certains livrables facultatifs afin de respecter les délais et de livrer un produit de qualité dans les contraintes budgétaires. Comme vous vous en souvenez peut-être de la Figure 9.4, il existe un spectre d'agilité entre les modèles de processus logiciels. Par nature, les SDLC sont incrémentiels car il est toujours possible de considérer un sous-ensemble d'exigences pour une version donnée. En fait, il y a généralement autant d'incréments que de sous-ensembles d'exigences. Pour s'adapter aux changements d'exigences et éventuellement aux nouvelles exigences au sein d'un incrément, les SDLC peuvent impliquer des itérations qui permettent d'ajouter et de replanifier les incréments de manière continue. Cet ajout et cette replanification peuvent introduire des retards car, généralement, le calendrier initial ne peut pas être modifié.

En bref, les SDLC peuvent être rendus agiles, incrémentiels et itératifs. Historiquement, les modèles traditionnels étaient incrémentiels mais non itératifs ou agiles. Le modèle de processus unifié (UP) a été le premier modèle traditionnel à introduire l'itération et il était assez prescriptif et, par conséquent, non agile, en termes de livrables attendus. Les modèles de processus logiciels agiles sont toujours incrémentiels et itératifs. Cela dit, il n'est pas judicieux d'utiliser un modèle logiciel agile si les exigences sont connues et ne devraient pas changer pendant l'incrément. Dans ce cas, l'utilisation de solutions prêtes à l'emploi peut, avec l'aide de certaines fonctionnalités collaboratives trouvées dans les lignes directrices des processus agiles définies dans les ASDE/SDLC agiles, produire de meilleurs résultats. Les modèles de processus logiciels traditionnels suivent un plan étape par étape, semblable à la construction d'une maison selon un plan. Ils sont bons pour les projets avec des exigences claires qui ne changent pas beaucoup. Bien que certaines organisations définissent le modèle de développement logiciel que leurs ingénieurs logiciels sont censés utiliser, il est presque toujours préférable pour les équipes de choisir ou d'adapter un modèle de processus logiciel afin qu'il s'aligne sur le projet en cours.

Certains des modèles de processus logiciels populaires incluent :

  • Modèle en cascade
  • Modèle en V
  • Modèle incrémentiel
  • Modèle de prototypage
  • Modèle en spirale
  • Modèle de processus unifié (UP)
  • Modèles de processus agiles

Modèle en cascade

Principalement utilisé aux débuts de l'génie logiciel, le modèle en cascade (waterfall model) est un modèle de processus logiciel prescriptif continu dans lequel les phases « s'écoulent » les unes dans les autres comme l'eau s'écoule du haut d'une cascade vers le bas. Dans le modèle en cascade, les exigences sont d'abord recueillies et analysées, puis un système logiciel complet est conçu, le système est implémenté, puis des tests finaux sont effectués avant que le système ne soit finalement déployé. Malheureusement, le modèle en cascade traditionnel ne faisait pas de distinction entre les phases et les actions d'génie logiciel, et, par conséquent, les étapes qu'il utilise correspondent à des actions d'génie logiciel ou des ensembles de tâches spécifiques avec des noms personnalisés qui devraient être menés dans une séquence prescrite. Notre cadre de processus générique peut toujours être utilisé pour représenter le processus en cascade, mais les activités cadre devraient être ignorées et des actions d'génie logiciel ou des ensembles de tâches spécifiques qui correspondent aux noms des phases en cascade devraient être utilisés. Par exemple, certains des ensembles de tâches de test de l'action d'génie logiciel SQA de l'activité cadre de gestion de la qualité pourraient être regroupés pour constituer la phase de test en cascade.

Dans le modèle en cascade, les actions d'génie logiciel ou les ensembles de tâches sont exécutés dans un ordre strict, comme le montre la Figure 9.8, et chacun d'eux a une sortie requise sous forme d'artefacts, tels qu'un document, un diagramme ou du code. Ce processus logiciel n'est pas agile, il n'est donc pas possible de sauter une étape ou de laisser tomber un livrable. Par exemple, la sortie de l'analyse des exigences est un document qui décrit toutes les exigences du système. Comme ce processus n'est pas itératif, il n'est pas possible de revenir à une étape précédente pour modifier cette sortie. Par exemple, si le document de conception final contient une erreur, il ne pourrait pas être révisé pendant l'étape d'implémentation – l'étape suivante serait le test. Notez, cependant, que rien n'empêche le modèle en cascade d'être utilisé de manière incrémentielle. Le concept de développement incrémentiel n'était simplement pas compris lorsque le modèle en cascade a été utilisé pour la première fois.

Diagramme en cascade : Exigences, Conception, Implémentation, Test, Déploiement.
Figure 9.8 Dans le modèle en cascade, une étape du processus de développement logiciel « s'écoule » dans une autre, et chacune est tenue de produire une sortie sous forme de document, de diagramme ou de code. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les principaux avantages du modèle en cascade incluent :

  • Il est facile à comprendre et à utiliser.
  • Les étapes et les actions d'génie logiciel ou les ensembles de tâches correspondants sont menés séquentiellement.
  • Les artefacts sont bien documentés.

Bien que le modèle en cascade présente certains avantages, ils sont souvent contrebalancés par ses inconvénients :

  • Il ne peut pas facilement s'adapter aux changements d'exigences. S'il y a un changement d'exigences, il est nécessaire de revenir à la première étape du modèle de processus et de mettre à jour tous les artefacts qui ont été précédemment complétés.
  • Aucun produit logiciel n'est fourni avant la fin du cycle de vie. Parce que le logiciel n'est pas disponible avant la fin de l'étape d'implémentation/construction, il n'est pas possible de demander l'avis du client pendant le processus.
  • Il produit de nombreux artefacts, qui ne sont pas toujours nécessaires ; par conséquent, beaucoup de temps peut être consacré à la création d'artefacts inutiles.

Malgré ces inconvénients, la méthode en cascade est utile dans les situations où les exigences ne changent pas et où l'interaction avec les utilisateurs d'un système est limitée ou inexistante pendant un projet.

Le modèle en V

Le modèle en V (V-model) pour le développement logiciel est également connu sous le nom de modèle de vérification (verification) et de validation (validation). Le modèle en V est similaire au modèle en cascade en ce sens qu'il s'agit d'un modèle prescriptif continu qui inclut des étapes initiales de création de système de base, commençant par la collecte des exigences, la conception du système et son codage. Chaque étape est prescriptive et menée séquentiellement. Ce qui différencie le modèle, c'est que chaque étape du modèle en V est associée à une étape/phase de test de vérification ou de validation, comme le montre la Figure 9.9. Ce test est planifié en coordination avec chacune des étapes/phases de conception et d'implémentation.

Comme le modèle en cascade, le modèle en V est considéré comme facile à comprendre et à utiliser car il suit un flux spécifique en ce qui concerne les étapes/phases, et chaque étape/phase n'est complétée qu'une seule fois. De plus, il convient mieux aux projets plus petits où les exigences sont faciles à comprendre et peu susceptibles de changer après le début du projet. L'avantage du modèle en V par rapport à la méthode en cascade est que les tests de vérification et de validation sont mieux intégrés dans le processus global.

Le modèle en V présente cependant plusieurs inconvénients, notamment :

  • Il n'est pas adapté aux projets plus grands, plus longs ou aux projets qui peuvent impliquer des exigences changeantes.
  • Un produit logiciel utilisable ne sera pas disponible avant la fin du cycle de vie du développement logiciel.
  • Une fois les tests commencés, il devient plus difficile d'apporter des modifications à la conception.
Modèle en V – Vérification (Analyse des exigences, Analyse du système, Conception de l'architecture, Conception des modules), Codage, Validation (Test unitaire, Test d'intégration, Test système, Test d'acceptation). La validation est montrée de toutes les étapes de validation vers les étapes de vérification.
Figure 9.9 Le modèle en V est similaire au modèle en cascade en ce sens qu'il s'agit également d'un modèle de processus logiciel prescriptif continu. Malgré leurs différences visuelles, dans les deux modèles, chaque étape est menée séquentiellement. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Modèle incrémentiel

Dans le modèle incrémentiel (incremental model), le processus logiciel est divisé en modules. Chaque module se concentre sur un ensemble plus petit d'exigences basé sur un plan d'affaires global. Ces ensembles d'exigences plus petits sont ensuite utilisés pour concevoir, implémenter et tester cette partie de la solution logicielle, comme le montre la Figure 9.10. Une fois tous les modules terminés, la solution logicielle est déployée auprès des utilisateurs. Notez que les incréments dans ce cas sont différents des itérations. Il est supposé que chaque incrément se concentre sur un petit sous-ensemble d'exigences, et il n'est pas possible de s'adapter aux changements possibles des exigences. Les projets sont généralement divisés en un certain nombre d'incréments destinés à couvrir les besoins des clients sur une période de temps qui leur est acceptable, tandis que chaque incrément est rendu gérable par l'équipe de développement.

Illustration du modèle incrémentiel avec les exigences globales divisées en différents incréments (chacun composé d'exigences, de conception, d'implémentation, de test, de déploiement) et aboutissant à un déploiement global.
Figure 9.10 Dans le modèle incrémentiel, le processus logiciel est divisé en incréments ou modules, et chaque module se concentre sur un ensemble plus petit d'exigences basé sur un plan d'affaires global. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le modèle incrémentiel est le mieux adapté lorsque les exigences sont clairement énoncées au début du projet et que le produit doit être livré rapidement. Comme les incréments sont petits, les tests peuvent être effectués et les retours des utilisateurs peuvent être obtenus à chaque incrément. Cela signifie qu'il y a des opportunités d'identifier et de corriger les erreurs ou les problèmes du produit plus tôt que dans les méthodes en cascade ou en V. Une fois l'étape des exigences globales terminée, chaque incrément peut se concentrer sur sa livraison spécifique. Cela permet de réduire les coûts, surtout s'il y a un changement dans les exigences. De plus, un grand avantage du modèle incrémentiel est qu'il est facile de savoir ce qui a été accompli et ce qui reste à faire.

Modèle de prototypage

Le modèle de prototypage (prototyping model) exige la création rapide d'une maquette ou d'une démonstration du produit final attendu qui fait ce que le produit final est censé faire afin de pouvoir montrer aux utilisateurs finaux à quoi le système pourrait ressembler et comment il pourrait fonctionner. Parce que les utilisateurs peuvent voir à quoi le produit pourrait ressembler et les bases de son fonctionnement, ils sont mieux placés pour fournir des retours qui peuvent être incorporés dans la démonstration, puis intégrés au produit final. Le modèle de prototypage est également connu sous le nom de modèle RAD (Rapid Application Development) car il se concentre sur la création rapide d'une démonstration fonctionnelle.

Ce modèle utilise toujours les étapes de collecte des exigences, de conception, d'implémentation et de test ; cependant, elles sont toutes effectuées rapidement pour construire le prototype. L'accent est mis sur l'amélioration du prototype pour arriver à ce qui est nécessaire pour construire la solution logicielle finale.

Comme le montre la Figure 9.11, le modèle de prototypage peut être utilisé pour construire une maquette que l'utilisateur peut approuver, puis la maquette peut être utilisée comme entrée pour le processus standard de conception, d'implémentation, de test et de déploiement du produit réel.

Modèle de prototypage : Recueillir les exigences, Conception rapide (Implémenter le prototype, Revue du prototype par l'utilisateur, Modifications demandées, Mettre à jour les exigences avec les retours de l'utilisateur), Accepté, Concevoir le produit final, Implémenter/coder le produit final, Tester le produit final, Déployer le produit final.
Figure 9.11 Un modèle de prototypage se concentre sur la création rapide d'une maquette ou d'une démonstration du produit final qui peut être partagée avec les utilisateurs pour obtenir leurs retours. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le modèle de prototypage présente quelques inconvénients. Comme il implique l'utilisateur dès le début, le processus de test et d'intégration des retours peut devenir chronophage. De plus, bien que le prototype puisse sembler fonctionner, il manquera généralement la pleine fonctionnalité interne, qui doit encore être construite même après que l'utilisateur ait vu ce qui semble être un système fonctionnel. Cela peut nécessiter des efforts supplémentaires pour gérer les attentes concernant le produit final.

Modèle en spirale

Le modèle en spirale (spiral model) est une combinaison du modèle en cascade avec une approche de modèle itératif et une focalisation sur la réduction des risques au sein d'un projet. Comme pour le modèle en cascade, le modèle en spirale commence par la collecte des exigences, sauf qu'il commence par un petit ensemble d'exigences, puis parcourt la planification, la conception, l'implémentation et les tests pour ces exigences. Une fois l'ensemble initial d'exigences traité, le processus revient au début, où des exigences supplémentaires sont appliquées au projet, puis il continue à cycler, comme illustré à la Figure 9.12, jusqu'à ce que la solution logicielle soit prête pour le déploiement. Ce modèle diffère de la méthode en cascade en ce qu'il inclut une analyse des risques dans l'étape de planification. Les risques associés au projet sont également évalués lors de la revue et des tests du système.

Illustration du modèle en spirale : 1. Déterminer les objectifs du produit et identifier les options de solution. 2. Évaluer, identifier et résoudre les risques. 3. Développer et tester l'itération actuelle du produit. 4. Planifier la prochaine itération du produit.
Figure 9.12 Le modèle en spirale privilégie l'analyse des risques en combinant des éléments de la méthode en cascade avec une approche itérative. Chaque spirale aborde un petit ensemble d'exigences, mais parcourt les étapes de planification, de conception, d'implémentation et de test pour ces exigences. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le modèle en spirale est souvent utilisé pour les projets de grande envergure ou lorsque des livraisons fréquentes sont attendues. Il est également utilisé lorsque les risques sont considérés comme élevés pour un projet et doivent être surveillés de près. Ces risques peuvent inclure les coûts, des exigences peu claires, des exigences complexes ou des exigences susceptibles de changer. L'avantage est qu'en raison de la nature itérative et en spirale du modèle, des modifications peuvent être ajoutées plus tard dans le projet. De plus, le modèle permet une meilleure estimation des coûts pour les itérations individuelles car un nombre limité d'exigences est traité à chaque spirale. Comme chaque itération permet au système de se construire sur lui-même, il y a aussi l'avantage de pouvoir s'adapter aux retours des utilisateurs et aux exigences changeantes.

Le modèle en spirale a ses inconvénients. Comme l'accent est mis sur les risques, il exige une expertise en gestion des risques. De plus, les itérations n'ajoutent pas seulement de nouvelles fonctionnalités, mais peuvent s'appuyer sur des fonctionnalités existantes, ce qui peut entraîner des coûts supplémentaires. S'il est appliqué à des projets plus petits, le coût peut l'emporter sur les avantages de certaines des autres approches. Comme il y a plusieurs itérations composées de plusieurs étapes/phases, il est également important de suivre les processus plus strictement que dans le cas d'autres modèles, et de conserver une bonne documentation pour savoir ce qui a été fait et ce qui est attendu.

Modèle de processus unifié

Dans le modèle de processus unifié (UP) (Unified Process (UP) model), le développement d'un système logiciel est divisé en quatre phases principales (initialisation, élaboration, construction et transition), chacune impliquant de multiples itérations qui incluent les processus de développement logiciel standard, comme le montre la Figure 9.13. Comme l'activité cadre/phase de notre cadre de processus générique, le modèle UP différencie les phases des actions d'génie logiciel. Le modèle UP repose toujours sur un processus prescriptif continu, mais il prend en charge le développement itératif incrémentiel. Le modèle UP utilise le mot discipline ou processus pour désigner l'action d'génie logiciel définie dans notre cadre de processus. Les noms des phases sont presque les mêmes que les noms des phases de notre cadre de processus, bien que la phase de transition soit équivalente au déploiement dans notre cadre de processus.

Diagramme du Processus Unifié listant l'Initialisation, l'Élaboration, la Construction et la Transition avec des itérations pour : le développement du cas d'affaires, le recueil des exigences, la conception de la solution, l'implémentation, le test et le déploiement.
Figure 9.13 Le modèle de processus unifié est très similaire au cadre de processus générique car il inclut des phases sous forme de processus (ou disciplines). Il comporte également des itérations, et la taille relative de la zone colorée pour une discipline donnée indique la quantité de discipline exécutée dans chaque itération. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Chaque phase ou processus du modèle de processus unifié a son propre objectif. Dans la phase d'initialisation, l'objectif est d'obtenir l'adhésion des utilisateurs à la solution présentée, de documenter les exigences et de créer un plan initial pour le projet. La phase d'élaboration se concentre sur la conception de la solution et la consolidation du plan de projet. La phase de construction se concentre sur l'implémentation et le test du logiciel. Enfin, la phase de transition se concentre sur le déploiement de la solution. Comme dans d'autres modèles de processus traditionnels et contrairement aux modèles agiles, chaque phase du modèle UP aboutit à un ensemble de livrables. Dans la phase d'initialisation, cela peut inclure des documents tels qu'un énoncé de portée, une évaluation initiale des risques ou un plan de projet préliminaire ; dans la phase d'élaboration, un plan de développement logiciel, un cas d'affaires révisé ou une base d'architecture exécutable ; dans la phase de construction, des plans d'itération individuels, un document de description de version ou une documentation utilisateur ; et dans la phase de transition, la version finale du produit et l'analyse des leçons apprises, entre autres.

Notez que le temps passé dans chaque discipline change au fil du temps, de sorte qu'à mesure que le projet évolue, moins de temps est consacré aux exigences et à la conception, et plus de temps est consacré aux tests et au déploiement. L'attente est que le modèle ajuste l'étendue des actions d'génie logiciel de manière continue en fonction de ce qui est nécessaire pour développer la solution logicielle à un moment donné.

L'attente lors de l'utilisation du modèle UP est que le logiciel sera livré tôt et régulièrement tout au long du processus. De plus, le modèle permet aux utilisateurs de voir ce qui arrive et de fournir des retours, ce qui, à son tour, permet d'adapter le logiciel à tout besoin changeant. Cela nécessite une communication ouverte tout au long du processus et de maintenir les utilisateurs comme participants actifs au projet. Une autre pratique avec ce modèle est de se concentrer sur la réutilisation du code existant ainsi que sur l'utilisation de la modélisation et d'autres outils. Des outils tels que l'UML sont presque toujours utilisés dans le cadre de l'UP. De plus, l'UP réduit les risques grâce à la nature itérative du développement. Comme les itérations sont limitées dans le temps, il y a un meilleur contrôle du processus global. Cela aide à rendre les risques plus faciles à gérer.

L'inconvénient est que les phases sont combinées avec les disciplines et délimitées dans un ensemble d'itérations, ce qui peut rendre le modèle complexe à suivre. Pour être efficace, les disciplines doivent être gérées et la communication doit être claire. Cela nécessite généralement une bonne gestion du processus.

Il convient de noter que l'UP a été le premier modèle à distinguer les phases des disciplines, ce qui a permis d'introduire des itérations et de les intégrer aux incréments. Bien que le développement incrémentiel ait existé auparavant, la séparation des phases des disciplines a rendu nouvellement possible de planifier l'itération dans le cadre d'un incrément de projet et ainsi de créer des solutions plus efficacement, car les actions de processus logiciel n'étaient plus associées à une activité cadre/phase spécifique. Au cours de chaque itération, une fonctionnalité partielle pouvait être créée, et les résultats pouvaient être intégrés au reste du système.

Modèles de processus agiles

Plusieurs modèles de processus logiciels populaires utilisés aujourd'hui s'alignent sur les lignes directrices agiles. Bien que les phases utilisées dans les modèles de processus agiles soient similaires à celles d'autres modèles, la différence est que certaines disciplines dans diverses phases peuvent se chevaucher. Par exemple, dans le modèle de processus agile, toutes les exigences n'ont pas besoin d'être définies dans la phase d'initialisation avant de commencer les disciplines de conception ou de codage dans les phases d'élaboration et de construction. De nouvelles exigences ou des changements d'exigences peuvent être pris en compte dans les phases ultérieures. De plus, une approche incrémentielle et itérative est appliquée, de sorte qu'il n'est pas nécessaire de traiter toutes les fonctionnalités d'un incrément en une seule fois. Il convient de noter que le modèle incrémentiel présenté précédemment peut être agile pour une raison similaire. Les avantages des modèles de processus agiles sont qu'ils sont flexibles (c'est-à-dire qu'ils permettent des changements en cours de route) et qu'ils mettent l'accent sur la collaboration. Ils permettent également une amélioration continue, ce qui est avantageux si les exigences sont susceptibles de changer ou si les besoins sont susceptibles d'évoluer. Les inconvénients sont que les modèles agiles peuvent être difficiles à adapter à grande échelle.

Principes agiles

Les principes agiles ont été formulés dans le Manifeste Agile qui était une réponse au nombre insatisfaisant de projets retardés, dépassant leur budget et ne répondant pas aux attentes des clients. L'agilité fait référence à la capacité de créer et de réagir au changement afin de tirer profit d'un environnement commercial turbulent. Certains principes agiles sont les suivants :

  • Satisfaire le client par la livraison précoce et continue de logiciels.
  • Accueillir les exigences changeantes, même tard dans le développement.
  • Livrer des logiciels fonctionnels fréquemment, par exemple toutes les deux semaines.
  • Le moyen de communication le plus efficace au sein d'une équipe de développement est le face-à-face (via des outils de collaboration).
  • Un logiciel fonctionnel est la principale mesure de progression.
  • Maintenir un rythme de travail durable.
  • Une attention continue à l'excellence technique et à une bonne conception améliore l'agilité.
  • La simplicité – l'art de maximiser la quantité de travail non effectué – est essentielle.
  • Les meilleures architectures, exigences et conceptions émergent des équipes auto-organisées.

Les approches qui complètent le développement logiciel agile sont Scrum, DevOps et Site Reliability Engineering.

Scrum

Scrum (Scrum) est un type de modèle de développement logiciel agile. L'unité fondamentale de Scrum est une équipe Scrum, qui compte généralement dix personnes ou moins. Elle se compose d'un Scrum master, d'un product owner et de plusieurs développeurs.

Le Scrum master est responsable de la gestion de Scrum et d'aider chacun à comprendre sa théorie et sa pratique. Le product owner est responsable de la gestion du backlog produit, qui comprend les objectifs du produit et les éléments du backlog produit. L'objectif du produit décrit les fonctionnalités futures souhaitées du produit, et l'élément du backlog produit définit ce qui doit être ajouté au produit.

Le produit est développé par itérations appelées sprint (sprint), qui est un événement de durée fixe, généralement d'une à quatre semaines. Chaque sprint commence par la planification du sprint, au cours de laquelle l'équipe sélectionne les objectifs du produit et les éléments du backlog produit qui seront implémentés dans ce sprint. Les objectifs du produit et les éléments du backlog produit sélectionnés sont déplacés vers le backlog de sprint, qui est un plan pour le sprint en cours. Pendant le sprint, les développeurs ont un scrum quotidien, qui est un événement de 15 minutes pour les développeurs, qui se tient chaque jour à la même heure et au même endroit. Pendant le scrum quotidien, les développeurs inspectent la progression et, si nécessaire, ils adaptent les objectifs du sprint. À la fin du sprint, il y a une revue de sprint, au cours de laquelle l'équipe Scrum et les parties prenantes examinent une démonstration de ce qui a été réalisé dans le cadre de l'incrément de sprint, et l'équipe Scrum reçoit des retours. Après cela, lors de la rétrospective de sprint, l'équipe Scrum discute de ce qui a bien fonctionné et de ce qui a mal fonctionné en termes de processus pendant le dernier sprint pour produire l'incrément de produit et propose des changements pour augmenter l'efficacité. La Figure 9.14 représente le processus Scrum.

Cadriciel Scrum : Backlog produit, vers Affinement du backlog, vers Planification du sprint, vers Backlog de sprint, vers Équipe Scrum (Sprint/Scrum quotidien), vers Incrément, vers Revue de sprint, retour vers Rétrospective de sprint/Backlog produit, ou Backlog produit.
Figure 9.14 Le cadre Scrum est organisé autour de sprints, des événements de flux de travail qui impliquent une planification intensive, une collaboration quotidienne, une revue et une rétrospection. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les avantages du cadre Scrum incluent une meilleure qualité du produit, un délai de mise sur le marché réduit, une satisfaction client accrue et une collaboration renforcée au sein de l'équipe de développement. Les inconvénients sont que l'approche nécessite une formation ; elle ne convient pas aux grandes équipes ; et elle exige des réunions quotidiennes.

DevOps

Un modèle DevOps (DevOps model) combine les pratiques de développement logiciel et d'opérations. Il utilise un cycle de vie de développement court et une livraison continue pour obtenir des produits logiciels de haute qualité. Dans un modèle DevOps, les équipes de développement et d'opérations sont fusionnées en une seule équipe, et les ingénieurs logiciels participent à toutes les parties du cycle de vie du logiciel. Comme le montre la Figure 9.15, ce cycle de vie comprend la planification (conception), le développement, les tests, le déploiement et les opérations dans un cycle continu.

Graphique de la Figure 8 : la boucle de gauche est DEV (Planification/conception, Code, Construction, Test) ; la boucle de droite est Ops (Déploiement, Opération, Surveillance, Rétroaction).
Figure 9.15 DevOps est un modèle de processus logiciel agile qui combine les pratiques de développement logiciel et d'opérations de telle sorte que les ingénieurs logiciels participent à toutes les parties du cycle de vie du logiciel. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Étant donné que le modèle DevOps met l'accent sur le développement et les opérations, il y a moins de risques d'erreurs ou de vulnérabilités dans un produit logiciel publié. Cette union du développement et des opérations peut également conduire à des livraisons ou des expéditions de produits plus rapides. Grâce à la collaboration, on observe généralement une efficacité améliorée, une livraison plus rapide et une optimisation des processus.

Le modèle de processus DevOps peut rencontrer des difficultés avec les systèmes complexes ainsi qu'avec les systèmes hérités. Le modèle DevOps exige un travail d'équipe et une collaboration solides, sinon il risque d'échouer. De plus, il exige que les membres de l'équipe possèdent l'expertise adéquate pour satisfaire les attentes du projet, y compris la capacité à réaliser une intégration et un développement continus.

Ingénierie de la fiabilité des sites

L'ingénierie de la fiabilité des sites (SRE) est une approche qui se concentre sur l'atteinte de niveaux de fiabilité appropriés lors du développement de solutions. La SRE a été créée pour relever la complexité des défis générés lorsque les solutions logicielles deviennent plus grandes. Il est important de s'assurer que le logiciel répond aux besoins de l'entreprise tout en fonctionnant de manière fiable. La capacité à monter en charge doit être équilibrée avec la complexité d'une solution tout en maintenant la fiabilité au sein d'un système. À bien des égards, c'est un objectif similaire à celui de DevOps.

Trois éléments clés de la SRE sont la fiabilité, la pertinence et la durabilité. Un système doit être fiable pour répondre aux besoins du client. Le niveau de fiabilité doit être approprié. Plus précisément, certains systèmes n'ont pas besoin d'une fiabilité de 100 % 100 % du temps. Par exemple, une fonctionnalité telle que le régulateur de vitesse n'a besoin d'être fiable que lorsqu'elle est utilisée. De plus, la plupart des fonctionnalités de régulateur de vitesse n'ont pas besoin de maintenir une vitesse exacte, mais peuvent plutôt avoir une différence de quelques miles ou kilomètres lorsque la voiture monte ou descend des collines et être acceptables. En ce qui concerne la durabilité, un système doit être durable et maintenable par des personnes.

Comme indiqué précédemment, la SRE est similaire à DevOps en ce sens que les deux rapprochent l'génie logiciel et les opérations logicielles. Cependant, DevOps a tendance à se concentrer sur la solution produit, ou le « quoi », tandis que la SRE se concentre davantage sur le « comment » (c'est-à-dire comment la solution sera réalisée de manière fiable et durable). Les deux se concentrent sur la création d'opportunités de collaboration au sein d'une organisation pour livrer des solutions qui réussiront pour le client. Le Tableau 9.1 indique les domaines où la SRE et DevOps diffèrent.

SRE DevOps
Objectif principal de la fiabilité d'une solution Objectif principal du développement et de la livraison efficaces d'une solution
Accent mis sur la régulation de l'informatique avec des mesures spécifiques telles que le respect des indicateurs de niveau de service (SLI) et des objectifs de niveau de service (SLO) Accent mis sur l'intégration continue (CI) et le développement continu (CD)
Priorise l'expérience utilisateur en garantissant que les services fonctionnent de manière fiable et respectent les SLO Travaille à utiliser des idées larges et ne spécifie pas comment les opérations des services sont exécutées
Destiné à être un rôle plus qu'un cadre, bien qu'il puisse être exercé par des personnes extérieures au rôle spécifique Bien qu'il puisse être un rôle, il est destiné à être une philosophie adoptée par toute une équipe
Travaille à agir rapidement pour réduire le coût de l'échec Travaille à mettre en œuvre des changements progressifs pour réduire les chances d'échec
Travaille à avoir des attentes spécifiques sur ce qui est acceptable concernant les échecs ou les problèmes avec les nouvelles versions Accepte l'échec comme une opportunité d'apprentissage et priorise la récupération rapide et l'amélioration continue.
Utilise des outils d'automatisation et de surveillance pour standardiser les processus et réduire l'effort manuel Travaille à réduire l'isolement organisationnel en collaborant plus étroitement, mais ne va pas nécessairement au même niveau d'utilisation d'outils et de techniques similaires
Tableau 9.1 Comparaison de la SRE et de DevOps

Modèle de processus suggéré

Quel est le meilleur modèle de processus ? Il n'y a pas de meilleur modèle de processus, et aucun modèle de processus ne fonctionnera pour chaque projet ou groupe de personnes. Chaque modèle a des avantages et des inconvénients à considérer.

L'approche recommandée est d'utiliser le modèle qui peut être le mieux adapté au projet actuel et aux compétences des membres de l'équipe. De nombreuses organisations ont déjà pris cette décision et auront leurs propres directives internes sur le modèle à utiliser. Quoi qu'il en soit, il est souvent important de considérer l'amélioration des processus logiciels (software process improvement), qui est le processus de transformation de l'approche existante du développement logiciel en quelque chose de plus ciblé, plus reproductible, plus fiable (en termes de qualité du produit produit et de rapidité de livraison) et plus rentable. Comme le montre la Figure 9.16, l'amélioration des processus logiciels implique généralement quatre étapes.

Processus logiciel : de la Planification des améliorations, à l'Implémentation des améliorations, à l'Évaluation de l'amélioration, à l'Évaluation de la situation actuelle et retour à la Planification des améliorations.
Figure 9.16 L'amélioration des processus logiciels peut être utilisée pour transformer tout modèle de processus logiciel choisi en un modèle plus ciblé, reproductible, fiable et rentable. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Pleins feux sur l'industrie

Appliquer le bon processus

La sélection et l'application appropriées d'un processus d'génie logiciel sont importantes dans toutes les industries aujourd'hui, car ces processus contribuent à assurer le succès des solutions logicielles développées. L'génie logiciel offre de nombreuses opportunités d'amélioration à de nombreuses industries. Par exemple, la Bourse de New York (NYSE) a conçu son logiciel pour offrir des capacités de négociation d'actions à quiconque, n'importe où, afin qu'ils puissent négocier presque à tout moment. Comme vous pouvez l'imaginer, le logiciel de la NYSE est complexe, et tout problème logiciel rencontré pendant les heures de négociation peut générer des pertes financières ou causer des dommages à la réputation. Ce sont quelques-unes des considérations qui ont dû entrer en ligne de compte dans la décision concernant le processus d'génie logiciel à utiliser pour réaliser cette mise à niveau.

Parmi tous les processus que vous avez appris jusqu'à présent, lequel (ou lesquels) pensez-vous être le mieux adapté à un projet impliquant le développement d'une solution logicielle pour le secteur des marchés mondiaux ? Réfléchissez aux ramifications possibles des retards de développement logiciel lors de la résolution d'un problème logiciel sur un parquet de négociation. Imaginez qu'un défaut logiciel entraîne l'affichage incorrect des prix des actions pendant les heures de pointe. Comment cela pourrait-il impacter le marché et les investisseurs ?