Les bonnes pratiques de l'architecture logicielle

Jamais vous ne vous lanceriez dans un projet sans un plan solide, et il en va de même pour la conception d’une architecture logicielle des systèmes informatiques. En renforçant l’efficacité de ce processus, vous pourrez tenir compte de toutes vos exigences de manière appropriée et offrir aux parties prenantes la possibilité de contribuer.

Appuyez-vous sur des visuels techniques et un processus de planification minutieux pour définir l’architecture et la conception de votre logiciel avant de vous lancer dans la réalisation d’un prototype.

Définition d’une architecture logicielle?

Dans le monde de la programmation, l’architecture logicielle vise à concevoir des applications simples, sûres et adaptables, en établissant le design général d’un logiciel. Les détails peuvent être ajoutés ultérieurement, ce qui permet aux équipes d’esquisser une vue d’ensemble et de commencer à préparer un prototype.

En suivant les conseils et les bonnes pratiques de l'architecture logicielle, les développeurs peuvent réfléchir avec soin aux caractéristiques de leur programme et déterminer comment planifier son architecture.

Comment concevoir une architecture logicielle en 5 étapes

1. Appréhender clairement les exigences

Chaque projet que vous entreprenez comporte des exigences fonctionnelles et non fonctionnelles. Ces critères orientent l’architecture de votre logiciel et vous permettent d’obtenir un produit final conforme aux attentes de vos parties prenantes.

Sans une compréhension claire de ces exigences dès le début, votre équipe risque de s’égarer, de privilégier des besoins inopportuns au détriment d’autres, ou de mobiliser un nombre insuffisant de ressources internes.

Utilisez des visuels pour obtenir une meilleure compréhension. Suivez les étapes ci-dessous pour définir vos exigences à l’aide d’un éditeur de diagrammes intelligents tel que Lucidchart :

• Commencer par une vue d’ensemble : esquissez d’abord vos exigences selon une « vue d’en haut ». La cartographie mentale est un outil efficace pour y parvenir.

• Cartographier vos exigences fonctionnelles : vous pouvez utiliser des verbes pour vous aider à regrouper les noms ensemble. Par exemple, des verbes tels que « afficher » et « modifier » peuvent relier « compte » ou « profil » entre eux dans une carte mentale des domaines fonctionnels.

• Tenir compte des exigences non fonctionnelles : lorsque vous travaillez sur votre carte mentale, notez également vos exigences non fonctionnelles pour y revenir ultérieurement. Une exigence telle que « performance » est essentielle, mais elle est probablement trop vague pour être placée sur la carte mentale.

Vos exigences doivent être utilisées pour définir le périmètre de votre travail et planifier votre projet.

2. Réfléchir à chaque composant

Soyons réalistes : compte tenu de l’influence considérable que vos exigences fonctionnelles exercent sur votre projet, il est possible qu’elles suffisent à déterminer vos options en matière de conception et de technologie.

Sans trop vous avancer en anticipant la mise en œuvre, vous devrez identifier les exigences qui représentent un défi important pour votre conception ou votre plan de projet. Certaines d’entre elles peuvent s’avérer impossibles dans certains scénarios.

• Commencer par un « monde parfait » : à quoi ressemblerait votre conception si vous pouviez la créer à la perfection ?

• Examiner et documenter les implications de vos exigences : commencez par une ébauche avec votre équipe et perfectionnez-la progressivement. Tout d’abord, vous devez examiner ce que vos exigences impliquent pour votre conception, en identifiant par exemple les différents éléments de la liste de souhaits de vos parties prenantes qui peuvent se contredire ou entrer en conflit avec d’autres exigences fonctionnelles et non fonctionnelles.

• Attendre et concevoir l’architecture finale ultérieurement : selon toute vraisemblance, votre plan d’architecture évoluera tout au long de ce processus ; ne vous attendez donc pas à ce que le premier jet corresponde au résultat final.

3. Diviser votre architecture en tranches

Naturellement, votre projet d’architecture entre dans une phase de planification au cours de laquelle vous décidez de la manière dont vous allez le réaliser. Diviser votre architecture en tranches peut vous aider à élaborer votre plan de manière à apporter de la valeur aux utilisateurs et à prévoir efficacement l’utilisation des ressources de développement.

Il peut être utile de se représenter la découpe d’un gâteau. La plupart des gens coupent un gâteau verticalement, en traversant chaque étage. Imaginons qu’une tranche complète comporte un glaçage, une garniture et deux ou trois couches de génoise à l’intérieur. Cette tranche verticale comprend un peu de tout. Mais les gâteaux peuvent aussi être tranchés horizontalement, en séparant les différentes couches.

De même, si chaque tranche est une story utilisée pour planifier votre architecture logicielle, celles-ci comporteront des couches : en coupant le gâteau verticalement, on crée des stories centrées sur des fonctionnalités individuelles, tandis qu’en coupant horizontalement, ce sont les composants individuels qui apparaissent. Vous devrez aborder votre projet à la fois de manière horizontale et verticale.

La méthode agile se concentre sur les tranches verticales, ce qui permet à votre équipe de livrer rapidement de la valeur. Cette approche permet aux clients d’être rapidement informés de l’évolution du produit et à l’équipe de développement de recevoir un retour d’information sur chacune des couches qui sous-tendent une fonctionnalité. Une tranche verticale de votre architecture logicielle pour un site de commerce électronique pourrait être le processus de paiement.

Dans votre tranche de gâteau verticale « paiement », vous pouvez voir la couche de données qui stocke les informations relatives au paiement, l’API de la couche intermédiaire et l’interface utilisateur de la couche supérieure à destination des acheteurs. Les tranches verticales vous permettent de déterminer quelles fonctionnalités livrer et de choisir les éléments itératifs.

En modélisant les couches impliquées dans votre projet d’architecture logicielle, vous pouvez visualiser l’ensemble du projet et la façon dont chaque couche influence les autres. Lors de la planification, prenez des tranches du gâteau agile et représentez les liens qui les unissent.

4. Créer un prototype

Créez systématiquement un prototype. Les prototypes vous permettent d’échouer aussi vite que possible, en vous fournissant un retour d’information rapide et en vous aidant à découvrir votre preuve de concept. Il s’agit d’une étape importante de la validation de votre travail et de la vérification de la pertinence et la rigueur de vos hypothèses.

Lorsque vous créez votre prototype, rappelez-vous que les premières itérations ne seront jamais parfaites et qu’aucune itération finale ne le sera non plus. L’un des avantages du prototypage est qu’il ne se présente pas comme un produit fini et que la plupart des gens abordent instinctivement ce processus en s’attendant à trouver au moins quelques imperfections.

Profitez de cette phase de prototypage. Elle ne remplace pas les tests, mais constitue une composante essentielle de ceux que vous devrez effectuer.

• Conserver un historique de révision minutieux : il est évident que si vous ne documentez pas les enseignements tirés de votre prototypage, vous risquez de répéter vos erreurs. Consignez toutes les décisions que vous prenez en matière de conception et les modifications que vous apportez en cours de route.

• Créer une source unique de vérité : pour éviter que des modifications successives et des versions divergentes ne viennent perturber votre progression, mettez en place un système de contrôle des révisions efficace, reposant sur une source de documentation unique.

• Modéliser vos prototypes : vous pouvez utiliser des diagrammes pour vous aider à gérer les modifications apportées à vos prototypes et à visualiser les différences entre chaque version.

5. Identifier et quantifier les exigences non fonctionnelles

En plus des exigences fonctionnelles, vous devrez prendre en compte les exigences non fonctionnelles. Ces exigences sont aussi essentielles pour votre conception que vos exigences fonctionnelles, car elles définissent les caractéristiques du système.

Les exigences non fonctionnelles sont souvent des exigences de qualité générales et applicables à l’ensemble du projet, mais pas toujours. Il se peut que votre système ait des exigences non fonctionnelles qui soient spécifiques à une partie seulement de votre architecture logicielle. Par conséquent, vous devez vous préparer à faire contribuer les parties prenantes sur ce sujet. Par exemple, une tranche verticale du projet peut intéresser l’équipe du service clientèle en particulier, et cette dernière peut avoir ses propres attentes concernant ces exigences non fonctionnelles.

Mais il ne suffit pas de déclarer que vous voulez des performances, de la portabilité ou de l’évolutivité. Les exigences non fonctionnelles doivent également être quantifiées. Aucun projet ne peut présenter des performances absolument parfaites : les « performances » doivent être spécifiées et limitées afin de répondre à d’autres exigences.

Étant donné que vos exigences non fonctionnelles jouent un rôle dans l’élaboration de votre conception, vous devez impérativement les définir. Voici d’autres exigences à prendre en compte :

• Performances : les performances de l’ensemble de votre système, ainsi que des tranches ou couches individuelles.

• Évolutivité : le potentiel actuel et futur d’évolution de votre système en fonction de vos besoins.

• Portabilité : la portabilité de vos données ainsi que la portabilité potentielle des composants de votre système, si applicable ou nécessaire.

• Extensibilité : prise en compte de la croissance future de votre système et de votre entreprise, de la capacité d’adaptation de ce dernier et des efforts nécessaires pour y parvenir.

• Conformité : un facteur essentiel supplémentaire, qui a un impact considérable sur la conception globale de votre projet.

Modéliser vos exigences non fonctionnelles peut aider votre équipe à comprendre comment vous les quantifiez tout en plaçant chaque exigence spécifique dans son contexte. Bien que vous n’ayez pas à vous soucier de tout optimiser pour l’instant, vous devez également envisager les efforts et les ressources qui pourraient être nécessaires pour mieux répondre à ces exigences non fonctionnelles ultérieurement.

Bonnes pratiques de l’architecture logicielle

Lorsque vous entreprendrez votre projet de conception, ces bonnes pratiques vous aideront à appliquer les principes les plus efficaces.

Visualiser votre conception

En utilisant des visuels pour accompagner son travail de conception et de mise en œuvre, votre équipe pourra appréhender la vision d’ensemble qui sous-tend votre projet. Les schémas d'architecture logicielle sont un excellent moyen de visualiser les processus et les différents aspects de vos choix de conception.

Éviter les motifs

Conservez une vue d’ensemble de votre processus de conception sans recourir à des motifs comme point de départ. Au lieu d’utiliser des motifs, privilégiez une vision globale des composants à un niveau très élémentaire afin de réduire le risque d’aller trop loin.

Le premier jet n’est que la première itération

Avec votre première conception, vous obtenez une meilleure idée des défis et des obstacles techniques auxquels vous serez confronté lors du développement de votre architecture. Ne vous attendez pas à ce que votre premier modèle soit plus qu’un prototype !

Rassurez-vous : votre projet d’architecture va se développer, et vous pourrez au fil du temps en préciser les détails.

Attention aux dérives du projet

Même s’il peut paraître tentant d’ouvrir le périmètre, cette dérive se fait au détriment de vos autres exigences et peut monopoliser des ressources essentielles. Pour enrayer ce phénomène, établissez un plan de projet qui tienne compte de vos exigences et entretenez-vous avec les parties prenantes concernant les limites des exigences non fonctionnelles. Il est important d’éviter que des attentes non satisfaites aient un impact négatif sur votre projet.

Garder les limites et les interfaces à l’esprit

Lorsque vous planifiez votre conception, tenez compte des interfaces entre les composants et des limites de votre système. Précisez la répartition des responsabilités de manière à pouvoir vous référer facilement à ces informations lorsque vous travaillez sur vos prototypes et vos prochaines itérations.

Améliorez votre architecture logicielle dès maintenant

La conception d’une architecture logicielle est plus efficace lorsque vous disposez d’un plan, que les parties prenantes y contribuent et que vous adoptez la meilleure approche pour définir les exigences du projet. Ne lésinez pas sur cette planification préliminaire, et vos efforts seront récompensés par un projet plus harmonieux.