Critère de qualité donné à un programme dont l’évolution, la mise à jour, la mise à niveau (ou la réparation) est prise en compte dès sa conception. Chaque modification se trouve être réalisable sans entraîner un surcroît d’analyses relatives aux autres critères de qualité. Exemple :
Ce critère est très souvent une contrainte importante en phase de développement. Ne pas prévoir à l’avance que certaines extensions du programme seront nécessaires, peut
entraîner une refonte complète du programme ou des structures de données, et par conséquent, une perte de temps et un surcoût financier considérable pour le projet.
Critère de qualité donné à un programme qui a une incidence importante sur la
maintenance de celui-ci. Aussi, un programme modulaire est un problème bien posé, analysé intégralement, et par conséquent complètement décomposé. A ce stade, l’étude des optimisations algorithmiques envisageables devient aisée, qu’elles soient imposées ou non.
Exemple :
La réalisation de programmes complexes nécessite le partage du projet et l’attribution des tâches bien définies à chacune des équipes de développeurs. Chacun prend en compte une part de l’étude en fonction des spécificités (compétences, langages, contraintes de
développement, …) : groupe « moteur de jeu », groupe « stratégie de jeu », groupe « gestion de la base de données », …
Sécurité
Critère de qualité donné à un programme qui a une incidence importante sur la
maintenance de celui-ci. Aussi, un programme modulaire est un problème bien posé, analysé intégralement, et par conséquent complètement décomposé. A ce stade, l’étude des optimisations algorithmiques envisageables devient aisée, qu’elles soient imposées ou non.
Exemple :
La réalisation de programmes complexes nécessite le partage du projet et l’attribution des tâches bien définies à chacune des équipes de développeurs. Chacun prend en compte une part de l’étude en fonction des spécificités (compétences, langages, contraintes de
développement, …) : groupe « moteur de jeu », groupe « stratégie de jeu », groupe « gestion de la base de données », …
Sûreté
ou sûreté (de fonctionnement) :
Les termes « Sécurité » et « Sûreté » sont souvent employés l’un pour l’autre. Il est important de revenir sur une définition permettant leur distinction.
Le sens donné à la sûreté est celui de la « sûreté de fonctionnement ». Le programme réalisé ne doit pas entraver le fonctionnement d’autres programmes, du système d'exploitation ou de tout autre système lié d’une manière ou d’une autre (matériel ou logiciel).
Ce critère est complémentaire au critère de « validité » présenté précédemment. Aussi, il ne doit pas être omis le fait qu’un dysfonctionnement du monde environnant, directement causé par le programme étudié, peut avoir en retour une incidence sur lui-même.
L’arrêt d'un processus tiers ou de son processus « fils » peut causer des pertes
irréversibles. Une mauvaise gestion des allocations de la mémoire, « fuite », entraîne, à terme, une saturation des ressources.
Immunité
Critère de qualité complémentaire à la définition donnée pour la sécurité d’un programme. Le sens donné à l’immunité est celui de la « prévention ». Le programmeur doit faire appel à des techniques et des concepts, qui permettent de garantir une meilleure insensibilité du programme réalisé par rapport à son environnement (voire, par rapport à lui-même).
Exemple :
La gestion non contrôlée des allocations de la mémoire, écrite systématiquement de façon dynamique, reste un moyen plus risqué qu'une réservation statique (lorsque le cadre de développement l’autorise).
Lisibilité
Critère de qualité donné à un programme dont les choix relatifs à la structure générale du programme, la structuration algorithme, les identificateurs, les techniques et les concepts, … sont précisés de façon suffisamment explicite, sont argumentés, commentés, mis à jour, …
Par ailleurs, ce critère de qualité, perçu comme une contrainte inutile, a pour effet de faciliter grandement la rédaction des documents du projet et des notices associées (à destination des utilisateurs, des développeurs en charge de la maintenance, …).
Exemple :
Le choix des identificateurs facilite la compréhension de l’ensemble (par son concepteur et par autrui : le professeur, par exemple ;-). Les concepts employés, les raisons d’un choix d’une structure plutôt qu’une autre, le domaine associé à des variables, … doivent
apparaître dans les programmes afin de faciliter les relectures, la maintenance, mais aussi la correction des erreurs !
Optimalité
Optimalité mono ou multi objectif :
Critère de qualité, systématique ou imposé, donné à un programme dont le niveau d’exigence en termes de « performance », est évalué. Cela correspond à une contrainte imposante en phase de développement.
Le programme concerné doit atteindre un objectif de recherche de l’optimal : soit en terme de « processus » (réduction de la durée relative à la résolution du problème), soit en terme de « mémoire » (réduction de la capacité utilisée par le programme).
Il est très difficile de traiter les deux objectifs conjointement (l’un ayant une incidence sur l’autre et inversement). Par conséquent, le cahier des charges doit stipuler clairement, en fonction du contexte, la priorité donnée à chacun d’eux.
Exemple :
L’efficacité de la recherche d’un élément dans une structure de données, dépend de la structure choisie. Si la structure s’enrichie d’un système d’indexation, afin d’accélérer la recherche, dans ce cas, c’est la taille de la structure qui augmente.
ATTENTION ! Ne pas confondre Optimisation du code et Réduction de la taille de l'algorithme !
Simplicité
Le choix de la simplicité est certainement un des plus grands gages de qualité.
Exemple :
Parmi les différentes solutions admissibles pour résoudre un problème quelconque, celle qui reste la plus simple permet souvent d’atteindre le but (la validité) assez rapidement.