Documenter les exigences logicielles : catalogue de critères et analyse de la valeur d'utilité

Pourquoi les exigences documentées déterminent les coûts, les délais et les risques

La qualité des logiciels agit sur quatre dimensions : coûts, délais, risques et pérennité. Une mauvaise qualité se traduit par des efforts élevés de maintenance et de réparation. Pour l'année 2022, le Consortium for Information & Software Quality a chiffré le coût d'une mauvaise qualité logicielle aux États-Unis à plus de 2,41 billions de dollars américains.

Le moment où une erreur est détectée est décisif. Les erreurs identifiées et corrigées tôt dans le processus de développement entraînent beaucoup moins d'efforts que celles qui n'apparaissent qu'en phase d'exploitation. Chaque point d'exigence pris en compte dès la phase de planification d'un projet logiciel préserve manifestement le budget logiciel. Cela évite des pertes de temps considérables dues à des adaptations coûteuses et complexes.

Les exigences documentées influencent des facteurs qui ne deviennent visibles qu'en phase d'exploitation. Il s'agit notamment d'une fiabilité accrue des applications, entraînant moins de temps d'arrêt, de coûts réduits sur le cycle de vie ainsi que de risques financiers et sécuritaires moindres, allant jusqu'à la protection contre les cyberattaques et les fuites de données. La maintenabilité s'améliore également : les adaptations et extensions sont plus efficaces, ce qui soutient l'agilité des projets.

S'y ajoutent un time-to-market plus rapide et la possibilité de faire évoluer le logiciel sans devoir revoir toute son architecture. Ceux qui ne précisent les exigences qu'lors de la réception paient ces effets plus tard sous forme de retravail, d'efforts de test supplémentaires et de reports de délais.

ISO/CEI 25010 comme catalogue de critères : huit caractéristiques de qualité pour un langage commun

La norme internationale ISO/CEI 25010 définit un modèle de qualité complet pour les systèmes et les logiciels. Elle offre une approche standardisée permettant aux entreprises d'évaluer et d'améliorer efficacement et de manière cohérente la qualité de leurs produits logiciels. L'évaluation se base sur le modèle de qualité du produit articulé autour de huit points : adéquation fonctionnelle, sécurité, maintenabilité, performance, compatibilité, flexibilité, utilisabilité et fiabilité.

La norme constitue un cadre et non un catalogue d'exigences. Elle fournit la terminologie permettant aux développeurs, testeurs, managers et autres parties prenantes de définir et d'évaluer systématiquement les exigences de qualité des logiciels. Un langage et une compréhension communs rendent enfin la qualité logicielle systématiquement évaluable.

Ce n'est pas la norme qui détermine quelle déclinaison d'une caractéristique est contraignante pour un produit concret, mais bien le projet. L'utilité du modèle réside dans le fait que toutes les parties impliquées comprennent la même chose derrière les termes « maintenabilité » ou « performance ».

Pour la pratique, il vaut la peine de consulter la version en vigueur : la SQS base ses audits sur l'ISO/CEI 25010:2023. Les anciennes présentations de la norme mentionnent parfois d'autres dénominations telles que fonctionnalité, fiabilité, facilité d'utilisation, efficacité, maintenabilité et portabilité. La structure actuelle du modèle de qualité du produit fait autorité pour le catalogue de critères et la certification.

Comparaison des caractéristiques de qualité de l'ISO/CEI 25010:2023 avec leurs déclinaisons pratiques

De la caractéristique à l'exigence vérifiable

Une caractéristique ne devient une exigence que si elle est formulée de manière mesurable. Lors d'un atelier, des experts de sieber&partners ont montré, sur la base de deux bases de code internes, comment la qualité peut être mesurée objectivement. Ils ont transmis des connaissances pratiques sur les normes ISO et les outils qui transforment les impressions subjectives en métriques mesurables – des métriques qui doivent être interprétées de manière professionnelle.

Pour la documentation, cela signifie : pour chaque caractéristique, on consigne ce qui est mesuré, la méthode de collecte utilisée et la valeur considérée comme atteinte.

Les indicateurs clés ne sont pas une fin en soi. Ils servent à évaluer un état et à procéder ensuite à des améliorations, et non à prouver que du travail a été effectué. Celui qui intègre une métrique dans le catalogue devrait également documenter quelle décision en dépend : si une version est livrée, si une refonte de l'architecture est nécessaire ou si un fournisseur satisfait à l'exigence. Les valeurs de mesure sans ce lien génèrent des efforts, mais aucun effet de pilotage ; elles deviennent obsolètes dès que le produit évolue.

Analyse de la valeur d'utilité : pondérer les exigences et rendre les variantes comparables

L'analyse de la valeur d'utilité traduit le catalogue de critères en une évaluation et permet de rendre les variantes de solution comparables. On commence par définir les critères – généralement les huit caractéristiques de qualité ou les exigences spécifiques au projet qui en découlent. Ensuite, on attribue des poids qui expriment, les uns par rapport aux autres, l'importance d'une caractéristique pour le projet.

Chaque variante est évaluée selon chaque critère sur une échelle prédéfinie, appliquée uniformément pour tous. Les valeurs pondérées de chaque variante sont additionnées pour établir un classement.

Le classement est un outil d'argumentation, pas un automate de décision. Une différence de points résultant uniquement d'une pondération fixée doit être justifiée et sa sensibilité doit être testée : l'ordre change-t-il si un poids est augmenté ou diminué ?

Le résultat et les hypothèses doivent figurer ensemble dans la documentation, afin qu'il reste compréhensible ultérieurement pourquoi une variante a été choisie. La pertinence des poids dépend du produit : pour les systèmes critiques pour la sécurité, la sécurité et la fiabilité pèsent plus lourd que la flexibilité ; pour une application grand public avec des cycles courts, cela peut être l'inverse. Ainsi, l'évaluation s'articule directement avec les huit caractéristiques de qualité – elles constituent la liste de critères d'où proviennent les poids.

Classement des caractéristiques de qualité selon le type de projet

Une documentation réellement utilisée par le développement, les tests et la direction

La documentation des exigences s'adresse à trois groupes de lecteurs ayant des questions différentes. Le développement veut savoir ce qui doit être construit ; les tests veulent savoir comment la conformité sera démontrée ; la direction veut évaluer les efforts, les risques et la capacité à être reçu.

Une exigence sert ces trois groupes si elle contient un identifiant unique, son origine ou le donneur d'ordre, une condition de réception vérifiable et le lien avec la caractéristique de qualité. Les tests et les protocoles de réception renvoient au même identifiant, de sorte qu'il est visible d'un coup d'œil quelle exigence a été testée avec quoi.

Les exigences évoluent durant le projet. Une entrée de modification avec date, justification et impact sur les efforts, les délais et les cas de test maintient le catalogue à jour et rend explicables les écarts ultérieurs. Le versionning et l'existence d'un seul statut valide empêchent que le développement et les tests partent d'hypothèses différentes. Ainsi, la documentation reste utile au-delà de la réception – comme base pour le développement ultérieur, l'analyse d'erreurs et la prochaine évaluation.

Éléments d'une documentation des exigences exploitable

Audit externe et certification en Suisse

Une évaluation indépendante suit un processus fixe : l'analyse, soit l'évaluation du logiciel basée sur les critères de l'ISO/CEI 25010:2023 ; des recommandations d'optimisation avec identification et correction des faiblesses en matière de fonctionnalité, de sécurité, de maintenabilité, de performance, de compatibilité, de flexibilité, d'utilisabilité et de fiabilité ; et enfin la délivrance du certificat après succès de l'audit.

Le certificat est attribué dans les niveaux Bronze, Argent ou Or et est valable deux ans. Grâce à une recertification continue, les projets agiles peuvent être maintenus au niveau de qualité requis.

Le certificat est délivré par l'Association suisse pour les systèmes de qualité et de management (SQS). Elle certifie des systèmes de management depuis 1983 et compte, selon ses propres indications, environ 7000 clients parmi ses prestataires. La SQS propose des audits et certifications basés sur l'ISO/CEI 25010 en collaboration avec Dr. Pascal Sieber & Partners AG ; le groupe cible est constitué des entreprises de développement logiciel.

Comme effet, elle cite l'établissement de la confiance par la preuve d'un haut standard de qualité, un avantage concurrentiel grâce à une qualité logicielle auditée, une augmentation de l'efficacité par la minimisation des erreurs et des efforts de maintenance, la sensibilisation de l'équipe et la pérennité. Après l'audit, des mesures pour le respect futur et, ponctuellement, pour l'augmentation de la qualité logicielle peuvent être déduites systématiquement des résultats.

Déroulement d'une certification externe selon l'ISO/CEI 25010:2023 en Suisse

Conclusion : les exigences de qualité comme tâche de direction

Un catalogue de critères bien tenu et une analyse de la valeur d'utilité rigoureuse agissent simultanément à plusieurs niveaux : une qualité logicielle auditée instaure la confiance vis-à-vis des clients et crée un avantage concurrentiel ; une gestion structurée de la qualité réduit les efforts liés aux erreurs et à la maintenance ; les compétences acquises alimentent les futurs projets. Un logiciel facilement maintenable peut être développé sans devoir revoir toute sa structure, et la recertification tous les deux ans maintient ce niveau même dans les projets agiles.

Cela devient une tâche de direction parce que les poids, les conditions de réception et la gestion des écarts ne peuvent pas être décidés uniquement par le développement : ils pilotent les efforts, les délais et les risques de l'ensemble du projet. Celui qui tient le catalogue, documente l'évaluation et réalise périodiquement l'audit externe peut justifier ses décisions au lieu de les défendre.