Assurance qualité logicielle

La norme IEEE 730 décrit le contenu nécessaire dans un plan d'AQL pour un logiciel.

Celui-ci doit contenir un préambule qui clarifie l'intention et la portée du processus, donne les définitions et les abréviations utilisés dans le document et inclut les documents de références nécessaire au processus. Ce préambule sera suivi d'un survol du plan d'AQL qui détaille son organisation, le niveau de criticité du logiciel, les outils, techniques et méthodologies utilisées dans le processus d'AQL, les ressources employées, les normes, pratiques et conventions utilisées et les calendriers pertinents.

Ensuite, le document doit détailler les activités et tâches du cycle de vie de l'AQL en décrivant le rôle de l'assurance du produit et du processus et en décrivant les activités et tâches du système de management de la qualité et certaines tâches additionnelles. Il doit ensuite inclure les processus et politiques additionnelles en jeu dans le processus: processus de revue de contrat et de mesure de la qualité, politiques de test, politique de dérogation et de déviation et politique d'itération des tâches. Enfin, il doit aussi spécifier quels sont les paramètres des enregistrements et des rapports d'AQL.

Bien que le plan qualité soit de la responsabilité du chef de projet logiciel, le spécialiste qualité peut lui venir en aide en lui proposant un gabarit normalisé qui pourra l'aider dans le travail de rédaction du plan. Un plan d'AQL décrivant les activités qualité qui seront faites pour un projet ou une modification à un logiciel doit être développé, documenté et maintenu à jour tout au long du travail.

Un corpus de connaissances vise à corriger les concepts essentiels d’une profession afin de normaliser sa pratique. Il contient les connaissances en AQL que tout développeur, mainteneur et ingénieur logiciel devraient avoir acquis au cours de sa formation. L’ISO 15939 [2] (aussi nommée le guide SWEBOK) a pour objectif de promouvoir non seulement une vision cohérente du génie logiciel dans le monde entier, mais aussi de fournir une base commune de connaissances pour l’élaboration de programmes de formation et de certification en génie logiciel. Nous^[Qui ?] observons que le domaine du logiciel souffre encore d’un certain nombre de problèmes qui ont été résolus dans les autres domaines du génie: faible qualité, absence de garantie, dépassements des coûts et faible utilisation de normes.

En introduction, l’ISO 15939 présente les considérations de qualité qui surpassent les processus individuels du cycle de vie d’un projet logiciel. On y précise que la qualité doit être un souci omniprésent pour l’ingénieur logiciel, et conséquemment il est important de toujours la considérer dans tous les autres domaines de connaissances présentés dans le guide^{[réf. souhaitée]}, par exemple : les exigences, la conception, la maintenance, etc. Au chapitre onze du guide SWEBOK, on y décrit les connaissances généralement acceptées qui permettent de définir, d’instaurer et de mesurer la qualité d’un logiciel.

Ces connaissances sont réparties en trois grandes catégories: 1) les fondements de la qualité logicielle; 2) les processus de gestion de la qualité logicielle 3) les considérations pratiques. Les sections qui suivent en font la synthèse et précisent dans quels chapitres, de nos deux premiers ouvrages, ces connaissances ont été traitées d'une façon détaillée. On voudra bien s’y référer afin de s’assurer que l’on maîtrise tous les concepts de la mise en œuvre d’un plan d’assurance qualité logicielle.

Comment peut-on résumer la notion de qualité d’un logiciel, et pourquoi est-il si important que ce sujet soit dominant dans le guide du corpus de connaissances en génie logiciel? Au cours des années, les auteurs et les organismes ont défini le terme «qualité» de manières différentes. Pour Phillip Crosby, c'était «se conformer aux exigences des utilisateurs». Pour Watts Humphrey, c’était «une adéquation parfaite entre le logiciel et son utilisation visée», alors que l’entreprise IBM proposait l’expression «la qualité telle qu'elle est définie par la clientèle» : une perspective qui vise l'entière satisfaction de sa clientèle. Les critères du programme d’excellence en qualité, le Malcolm Baldrige, programme qui est destiné aux organisations américaines emploie aussi une expression de la qualité semblable : «la qualité exigée par le client», et cette perspective inclut la satisfaction du client en considérant comme importante la qualité d’un service ou d’un produit. La qualité du logiciel a aussi sa définition propre que l’on peut retrouver dans la norme internationale ISO 9001: « le degré auquel un ensemble de caractéristiques remplit les exigences ». Toutes ces définitions sont générales. Dans certains cas, le contexte requiert que la qualité logicielle soit modélisée et compilée dans le dossier des exigences du logiciel. Plusieurs modèles de la qualité logicielle ont été proposés au cours des ans afin de décrire les exigences qualité d’un logiciel.

Il est important pour le spécialiste du logiciel de spécifier les exigences qualité, les communiquer et s’assurer que tous les intervenants approuvent ces exigences au tout début d’un projet ou d’une modification d’un logiciel. Le spécialiste en assurance qualité logicielle a pour mission de former et d’appuyer le personnel du développement, de la maintenance et des infrastructures afin qu’ils appliquent concrètement ces concepts au cours de leur travail quotidien. C’est à l’étape de l’élucidation des exigences d’un projet logiciel que les exigences qualité doivent être identifiées, documentées, numérotées, hiérarchisées et approuvées. Il est important de souligner ici que ces exigences ont une incidence sur les processus, techniques et outils de mesures d’assurance qualité logicielle qui devront être mise en place pour évaluer la qualité du logiciel livré à la clientèle. Cette approche permet de démontrer, à la clientèle, que ces exigences ont été prises en compte et validées, par des tests, avant l’acceptation finale du logiciel.

L'importance de la culture et l'éthique du génie logiciel: On s'attend, à cette étape ci, à ce que les spécialistes du logiciel prennent un engagement en ce qui a trait à la qualité du logiciel en tant qu'élément essentiel de leurs activités quotidiennes. L'éthique doit jouer un rôle significatif. En effet, une culture et des attitudes qui font la promotion de l’éthique influencent irrémédiablement la qualité du logiciel. La Computer Society de l’IEEE et l’ACM proposent un code d'éthique accompagné de pratiques professionnelles adaptées spécifiquement pour l’ingénieur logiciel. Ce code d’éthique vise à aider à renforcer les attitudes liées à la qualité et à l'indépendance au moment de la réalisation d’un logiciel. Afin de bien comprendre comment il faut résister aux pressions des patrons et de la clientèle, nous présentons un modèle de négociation (utilisant cinq perspectives d’un projet logiciel : l’échéance, le coût, la fonctionnalité, le personnel et la qualité) qui peut vous aider à mieux gérer les attentes de vos clients et de vos patrons.

La valeur et le coût de la qualité : Le concept de la qualité n'est pas aussi simple qu'il peut y paraître. Avant d’aller de l’avant en ce qui a trait à la mise en œuvre du coût de la qualité au sein de votre organisme il est important de comprendre les différentes cultures et modèles d’affaires de l’industrie du logiciel (par exemple: la différence des pratiques logicielles utilisées dans les domaines : nucléaire, aéronautique, bancaire et dans bien d’autres). Selon le domaine d’affaires, et les enjeux de qualité spécifiques, il y a toutes sortes de caractéristiques qualité qui sont attendues par la clientèle. Ces nuances contextuelles doivent être maîtrisées par le spécialiste en l’assurance qualité logicielle afin de guider les équipes de projet. Il pourra alors en discuter avec les intervenants et déterminer leurs impacts potentiels. Dans certains cas, les caractéristiques de qualité peuvent être exigées dans un contrat, ou peuvent être exigées à un plus ou moins fort degré. Quoi qu’il en soit, des compromis doivent être établis entre ces différentes exigences qualité. Bien sûr, la qualité a un coût. Pour aider les gestionnaires à mieux comprendre le coût de qualité d’un logiciel, il est possible de le calculer en effectuant la somme des coûts selon les quatre perspectives suivantes: 1) le coût de prévention des défauts, 2) le coût de l’évaluation de la qualité, 3) le coût d'échec interne du logiciel, 4) le coût d'échec externe d’un logiciel. Le spécialiste d’assurance qualité logicielle pourra donc bien présenter ces enjeux à l’organisme en question et l’aider à comprendre le retour sur les capitaux investis.

Le chapitre de l'AQL du SWEBOK traite aussi de l’importance de définir tôt les exigences qualité dans le projet de développement d’un logiciel. On sait, par expérience, que lors de la planification d’un nouveau projet logiciel, l’équipe de projet vise à créer un logiciel qui offre une valeur ajoutée pour l’organisme, et cette valeur est souvent quantifiée en termes de coûts et de bénéfices. Le client fixe un certain coût maximum, en échange duquel il s'attend à ce que les objectifs établis soient rencontrés par le projet. Dans cette démarche, le client aura une certaine assurance quant à la qualité du logiciel. Il est fréquent que les clients n’établissent pas clairement les objectifs qualité, et conséquemment qu’il comprenne les implications en efforts et en coûts. Pour assurer cette condition, le spécialiste du logiciel doit se poser la question suivante: «Ai-je une spécification claire des exigences qualité suivi d’une explication claire de ce qui est optionnel et essentiel pour assurer le succès de ce projet?»

Comme la réponse à cette question se trouve souvent quelque part dans un intervalle flou, et c’est souvent le cas, il faut alors s’assurer que le client soit impliqué dans le processus d’élucidation des exigences qualité et qu’il soit raisonnablement informé des options, coûts et avantages/inconvénients. Les modèles et caractéristiques de la qualité: Les modèles et caractéristiques de la qualité logicielle, présentés dans le guide SWEBOK, sont divisés en deux perspectives différentes : 1) les modèles de la qualité des produits logiciels et 2) les modèles de maturité et de pratiques logicielles exemplaires. La terminologie qui permet décrire les nombreuses caractéristiques qualité d’un logiciel ont évolué au cours des années. Au cours des années 80, divers auteurs suggèrent différents modèles de caractéristiques et d’attributs qualité du logiciel. C’est à ce moment que l’ISO a décidé de normaliser ce domaine et a tranché en normalisant trois perspectives qualité d’un produit logiciel : la qualité interne, la qualité externe, et la qualité en service. Ces informations ont été publiées dans le modèle qualité des produits logiciels de la norme ISO 9126 et ISO 25000. Le modèle est accompagné d’un ensemble de guides qui permettent sa mise en œuvre. L’ingénieur logiciel doit être en mesure de bien comprendre les concepts et la terminologie des caractéristiques qualités du logiciel préconisées par l'ISO et d’être en mesure de les mettre en pratique dans ses projets.

Le modèle qualité proposé par l’ISO 9126 et l’ISO 25000 précise la signification du terme produit logiciel qui inclut tous les livrables produits à la sortie d’un processus logiciel. Conséquemment, tous les produits intermédiaires réalisés pendant un projet logiciel sont visés par le modèle qualité. Voici quelques exemples de produits logiciels: des spécifications d’exigences pour le système dans son ensemble, des spécifications logicielles, un document d’architecture ou de conception, le code source, la documentation, les cas de tests, les rapports produits par des tâches d'analyse de qualité. Tandis que la plupart des activités d’assurance qualité logicielle sont décrites en termes d'évaluation du logiciel final et du système sur lequel il opère, les pratiques exemplaires en génie logiciel exigent que ces produits logiciels (aussi nommés produits intermédiaires du logiciel) puissent être évalués pour leur qualité.

La gestion de la qualité du logiciel et la qualité de l’ingénierie des processus d’ingénierie ont un impact direct sur la qualité du produit logiciel lorsqu’il est livré. En somme, ce qui se passe pendant le développement du logiciel peut nuire grandement la qualité du logiciel lui-même et compromettre les coûts pour le maintenir et l’opérer tout au long de sa vie utile. Les modèles de maturité et de processus exemplaires servent à évaluer la maturité des processus TI de votre organisme.

Le découpage, entre processus et produit, n’étant pas clairement compris par tous les intervenants de l’industrie du logiciel, on retrouvera des normes et guides qui abordent les deux aspects sans les différencier clairement. Les documents spécifiques au logiciel sont: l’ISO 9001 accompagnés du guide pour son application au logiciel présentée dans l’ISO 90003. Ces deux références permettent de comprendre les activités nécessaires pour obtenir une certification ISO 9001 du système qualité du logiciel. La certification aide à maintenir un certain niveau de professionnalisme et de qualité dans toutes les activités impliquant le logiciel[3].

Le spécialiste en assurance qualité logicielle doit maîtriser ces connaissances et savoir comment les appliquer pratiquement dans des projets d’acquisition, de développement, dans les activités de maintenance et aussi dans la gestion des infrastructures TI. Outre cette norme, il y a aussi un certain nombre de référentiels qui proposent des pratiques exemplaires en technologie de l’information et qui aident à guider les activités d’amélioration. Il y a deux référentiels principaux qui proposent l’évaluation de la qualité des processus de développement de logiciel : le CMMI pour le développement et la norme ISO 15504. Ce modèle d’amélioration est de plus en plus utilisé. Au début de l’apparition de ce modèle, il y avait certaines discussions, à savoir si un spécialiste logiciel devait opter pour l’utilisation de ISO 9001 ou du CMMI. Ces discussions ont été largement débattues, conséquemment, la conclusion la plus fréquente reconnaît que les deux sont complémentaires et qu'obtenir la certification ISO 9001 peut aider considérablement dans l’atteinte des niveaux de maturité plus élevés proposés par le CMMI. Dans le cas des mainteneurs, le référentiel d’amélioration de la maintenance du logiciel, le S3m (www.s3m.ca), présente les pratiques exemplaires pour améliorer les processus spécifiques à la maintenance du logiciel. Finalement, les différents guides ITIL ainsi que la norme ISO/CEI 20000 s’adresse aux processus de gestion des services et infrastructures des technologies de l’information. Finalement, le référentiel CobIT, qui est proposé par les auditeurs internes, est très utilisé pour favoriser l’implantation des contrôles internes requis par la loi Sarbanes-Oxley.

L'amélioration de la qualité : La qualité des produits logiciels peut être améliorée par un processus itératif d'amélioration continue qui exige le management, le contrôle, la coordination et les boucles de rétroaction: 1) les processus du cycle de vie du logiciel, 2) le processus de la détection, de la correction et de la prévention des erreurs/défauts, 3) le processus d'amélioration de la qualité. La théorie et les concepts de l'amélioration de la qualité, comme la mise en œuvre de la qualité par la prévention et la détection des erreurs, l’amélioration continue, et la focalisation sur les besoins du client, sont tous applicables au domaine du logiciel.

Les grandes approches de la qualité, comme le Lean, la roue de Deming, Kaizen, Six Sigma, le management de la qualité totale (TQM) et le Plan-Do-Check-Act PDCA, sont des approches qui peuvent être utilisées pour atteindre les objectifs de qualité. Ces approches peuvent conjointement utiliser les normes et les pratiques exemplaires telles que: l’ISO 9001, le CobiT, ITIL/ISO 20000, le CMMI/ISO/CEI 15504 et le référentiel d’amélioration de la maintenance du logiciel, le S3M.

Pour que l’amélioration du logiciel soit possible, il faut que les gestionnaires et la direction apportent leur soutien aux évaluations des processus et aux produits existants pour identifier l’état actuel des pratiques de l’organisme. On devra, dans certains cas, retenir les services d’un gestionnaire de changement pour aider l’organisme à changer sa culture et ses habitudes. Un programme d'amélioration pourra aussi être développé, identifiant des actions détaillées et des projets d'amélioration à mettre en œuvre. L'appui des gestionnaires implique que chaque projet d'amélioration ait assez de ressources pour atteindre le but visé.

La gestion de la qualité logicielle s'applique dans toutes les perspectives des processus, des produits et des ressources TI. Elle définit les processus, les propriétaires de processus, les exigences pour la réalisation de ces processus, les mesures de processus et des sorties, ainsi que les canaux de rétroaction.

Les processus de gestion de la qualité du logiciel se composent de nombreuses activités. Certaines peuvent être utilisées pour trouver des défauts, alors que d'autres, comme les analyses causales, indiquent où il pourrait être avantageux d’analyser plus en profondeur pour prévenir des défauts. Bien sûr, il est plus avantageux de prévenir que de guérir. La planification de la qualité d’un logiciel implique donc :

• de définir les exigences et spécifications en termes de caractéristiques particulières de qualité d’un logiciel ;
• de planifier les processus et activités de qualité qui seront nécessaires pour s’assurer de rencontrer ces exigences autant en prévenant qu’en cherchant à trouver et éliminer le plus grand nombre de défauts tout en respectant l’enveloppe budgétaire et le calendrier.

La gestion de la qualité logicielle est définie dans la norme ISO 12207 [ISO 08a]. Cette norme précise la portée de la gestion de la qualité du logiciel et décrit les processus suivants:

• l’assurance qualité logicielle (AQL) ;
• la vérification et validation (V&V) ;
• la revue et d’audit ;
• la résolution des problèmes.

Ces processus favorisent la culture qualité et permettent également la mise en place d’activités de prévention de défauts. Les processus d’assurance qualité logicielle (AQL) offrent la possibilité d’assurer une meilleure qualité du logiciel dans la mise en place d’un projet de développement, de maintenance ou d'un projet de changement dans les infrastructures TI. Ils fournissent également, comme sous-produits, des informations synthétisées pour la prise de décision, y compris une indication de la qualité des processus logiciels de l’organisme. Les processus d’AQL permettent aussi de donner une indication concernant l’état réel de l’avancement des travaux (par exemple, les plans de management, le développement, la gestion de configuration, l'analyse d’impact). Ils visent à évaluer si les produits intermédiaires et finaux répondent à leurs exigences initiales spécifiées. Les résultats des activités d’AQL peuvent être synthétisées dans des tableaux de bord (technique qui permet de présenter des mesures clés de la performance d’un projet logiciel) pour la prise de décision et l’identification d’actions correctives. Le gestionnaire de l’AQL doit s'assurer que les résultats de ces rapports qualités sont vérifiés et pertinents.

Les processus d’AQL sont étroitement liés aux activités de cycle de vie du logiciel; ils peuvent se superposer et parfois être inclus dans une activité du cycle de vie. Parfois, ils peuvent sembler réactifs parce qu'ils s’adressent à l’identification de défauts sur les processus tels qu’ils sont mis en pratique et les produits tels qu’ils sont développés. Afin qu’ils soient proactifs, les processus d’AQL doivent aussi être identifiés au tout début de l'étape de planification initiale de projet de développement ou de maintenance. Il a été démontré qu’en étant proactif, on pourra atteindre les caractéristiques de qualité et le degré de qualité, envisagés à moindres coûts.

L'assurance qualité logicielle : Les processus d’assurance qualité logicielle (AQL) visent à fournir une plus grande assurance que les produits et que les processus du logiciel répondent aux exigences. C’est en planifiant, en mettant en place et en exécutant un ensemble d'activités pour établir un niveau adéquat de confiance, que l’on démontre que la qualité a été incorporée dans un logiciel. L’AQL vise donc à s’assurer que la qualité est une préoccupation constante dans tout développement, maintenance, et travaux d’infrastructure/d’opération du logiciel. Afin d’y arriver, l’AQL s’assure de l'exécution d'une variété d'activités qualité, à chaque étape du cycle de vie du logiciel, qui visent l’identification rapide de défauts afin de les éliminer le plus tôt possible. Le rôle de l’AQL, en ce qui concerne ses processus, est de s'assurer que les processus d’AQL prévus sont appropriés, puis mis en application selon les plans prévus, et que des processus appropriés de mesure de la qualité sont en place. En ce qui a trait à un projet de développement ou d’une maintenance du logiciel, le plan qualité définit les moyens qui seront employés pour s'assurer que le logiciel développé répondra aux attentes et aux exigences des utilisateurs (c.-à-d. sera de la plus haute qualité possible à l’intérieur des contraintes de budget et de calendrier établi). Pour y arriver, il faut d'abord vérifier qu’une cible qualité est clairement établie, communiquée et comprise par tous les intervenants. La norme IEEE 730 propose un plan qualité de référence utile pour l’ingénieur logiciel.

La taille et la complexité du plan qualité varient selon chaque cas. Il sera plus rigoureux pour de grands projets et pour des logiciels critiques. Il peut comporter quelques pages et, dans d’autres cas, des centaines de pages sur plus d’un document. Pour des raisons pratiques d’enseignement, nous allons décrire le plan qualité le plus complexe et on pourra ajuster le contenu selon les besoins spécifiques d'un projet.

Dans un plan d’assurance qualité logicielle, les activités et les tâches spécifiques à la qualité sont présentées, accompagnées de leurs coûts et exigences en ressources, avec leurs objectifs globaux de gestion suivie d’un échéancier. Le plan qualité inclus le plan de gestion de configuration de logiciel. Le plan qualité logicielle identifie aussi les documents, les normes, les pratiques, et les conventions régissant le projet et la manière dont ils seront vérifiés et surveillés pour en assurer l'adéquation et la conformité. Ce plan identifie également les mesures, techniques, statistiques, les procédures pour l’identification des problèmes, les corrections, les ressources telles que les outils, les techniques et les méthodologies, la sécurité pour les médias physiques, la formation, les rapports qualité et la documentation. En outre, le plan d’assurance qualité logicielle comprend les activités de l’assurance qualité logicielle, telles que: la livraison, par un fournisseur externe de l'installation et du service après la livraison du logiciel. Il peut également contenir les critères d'acceptation, aussi bien que le format et la fréquence des rapports et activités de gestion.

La vérification et la validation : « La V&V du logiciel est une approche disciplinée pour évaluer les produits de logiciel tout au long du cycle de vie de produit. Tel que défini dans la norme IEEE 1059, un effort de V&V a pour objectif de s'assurer que la qualité planifiée dans le logiciel est mise en œuvre et que le logiciel répond aux exigences fonctionnelles et non fonctionnelles des utilisateurs ».

La V&V a pour objectif la mesure directe de la qualité du logiciel, entre autres des techniques d'essais ou de tests, des analyses et des revues qui trouvent des défauts, de sorte qu'ils peuvent être corrigés. Ces techniques évaluent également les produits intermédiaires, effectués tout au long du projet, par exemple : les documents d’exigences, la conception, et les plans de tests. Enfin, la vérification et la validation indépendante (V&VI) effectue les tâches de V&V, mais sans être sous le contrôle de l’organisme qui développe ou maintient un logiciel. L'organisme qui développe du logiciel doit avoir mis en place des processus logiciels, de l'assurance qualité logicielle et des pratiques de V&V.

Les activités de vérification déterminent si les produits d'une activité donnée de développement ou de la maintenance répondent à l'exigence initiale énoncée pour cette activité, et les activités de validation déterminent si le logiciel final accomplit son but prévu en répondant aux exigences et aux attentes des utilisateurs. Le processus de vérification et le processus de validation doivent être planifiés tôt dans la phase du développement ou de la maintenance d’un logiciel. Voici quelques exemples de tâches de V&V :

• analyse de situation critique ;
• analyse d’allocation d’exigences logicielle / utilisateur / matériel ;
• analyse de traçabilité ;
• analyse de sécurité ;
• analyse de risques ;
• test de logiciel.

Les tests sont une des techniques de V&V les plus utilisées. Le but de la planification des tests et de la planification V&V est de s'assurer que chaque ressource, rôle et responsabilité sont clairement assignés. Les plans de test et de V&V documentent et décrivent les diverses ressources, leurs rôles et leurs activités qualité, incluant les techniques et les outils à employer. Une compréhension des différents buts de chaque activité de V&V aidera au moment de la planification des ressources. Les normes IEEE 1012 et IEEE 1059 décrivent le contenu typique d’un plan de tests et d’un plan de V&V. Ces plans visent également les aspects de gestion, de communication, de politiques, et de procédures de V&V et de leurs interactions, impliquant des exigences de production de rapports de défauts et de documentation du projet.

Les revues et les audits : La prévention des défauts est une activité essentielle de l’AQL. On doit y consacrer un effort croissant pour améliorer la qualité du logiciel. Les processus de revue et d'audit sont décrits dans la norme ISO/CEI 12207.

Les détails des différents quatre types de revues et de l’audit sont décrits dans la norme IEEE 1028:

• La revue de gestion ;
• La revue technique ;
• La revue de type inspection ;
• La revue de type ‘walk-through’ ;
• L’audit.

D’autres processus du logiciel ont une grande incidence sur la qualité du logiciel :

• la gestion des configurations ;
• la gestion du risque.

La gestion des configurations du logiciel joue un rôle important pour réaliser la qualité du logiciel. Elle permet une saine gestion des versions et de la documentation des logiciels.

La gestion du risque joue également un rôle important pour s’assurer qu’un logiciel est de qualité. Incorporer de façon disciplinée les techniques d'analyse et de gestion des risques dans les processus de cycle de vie du logiciel peut augmenter le potentiel de production d’un produit de qualité.

L’ingénieur logiciel doit aussi avoir des connaissances pratiques en ce qui a trait à l’utilisation des principes de la qualité et des techniques courantes dans le domaine concerné. Cette section évalue les connaissances nécessaires pour vérifier si la qualité visée pourra être atteinte.

Les exigences de l’application de la qualité : Des facteurs influencent la planification, la gestion et le choix des activités et des techniques d’AQL lors du démarrage d’un projet de développement, de maintenance et d’opération, incluant :

• le domaine du système dans lequel le logiciel opérera (sûreté-critique, sécurité-critique, mission-critique, affaires-critique, environnement-critique) ;
• les exigences de système et de logiciel ;
• les composants (internes), commerciaux (externes) ou standard à employer dans le système ;
• les normes spécifiques de génie logiciel applicables à l’interne et imposées par le domaine concerné ;
• les outils logiciels et méthodes à employer pour le développement et la maintenance ainsi que l'évaluation et l'amélioration de la qualité ;
• le budget, le personnel, l'organisation du projet, les plans et l'établissement de l’échéancier de tous les processus ;
• les utilisateurs et l'utilisation prévus du système ;
• le niveau d'intégrité du système ;
• la taille de l’organisation ;
• la répartition géographique des équipes de développement ;
• la diversité culturelle.

L’information acquise en étudiant chaque facteur indique comment les processus du système de management de la qualité (SMQ) doivent être organisés et documentés. Cette information indique aussi quelles ressources seront nécessaires et les limites qui seront imposées dans la réalisation du projet.

Dans les cas où l'échec du système pourrait avoir des conséquences extrêmement graves, la fiabilité globale (matériel, logiciel, et humain) est une exigence de qualité (exigence non fonctionnelle) principale au-delà de la fonctionnalité requise par les utilisateurs. La fiabilité du logiciel inclut des caractéristiques telles que : la tolérance aux fautes, la sûreté, la sécurité et « l’utilisabilité ». La fiabilité est décrite en détail dans la norme ISO 25000 accompagnée de ses guides d’information.

Étant donné que le développeur ou l’ingénieur logiciel pourra avoir des préoccupations plus générales qui englobent le système (matériel, logiciel d’exploitation, télécommunications), le futur corpus de connaissances de l’ingénierie des systèmes (system engineering) s’assurera que ceux-ci doivent être très fiables (« confiance élevée » ou « systèmes de très haute intégrité »). Cette terminologie qui est utilisée couramment pour les systèmes mécaniques et électriques traditionnels (qui peuvent ne pas inclure de logiciel) a été adaptée pour traiter des menaces ou des catastrophes imprévisibles, des risques, de l'intégrité du système. L’ingénieur logiciel qui travaille dans un domaine critique devra vérifier que ses connaissances sont adéquates afin de faire face à des requis de qualité provenant de l’ingénierie des systèmes.

Le niveau d'intégrité d’un logiciel est basé sur les conséquences possibles de l'échec du logiciel et de la probabilité de cet échec. Pour le logiciel dans lequel la sûreté ou la sécurité est importante, des techniques telles que l'analyse de risques pour la sûreté ou l'analyse de menaces pour la sécurité peuvent être employées pour développer une activité de planification qui identifierait où se trouvent les points sensibles potentiels. L'historique des échecs de logiciels semblables peut également aider en identifiant quelles techniques seront les plus utiles pour détecter des défauts et en évaluer la qualité. On propose alors des niveaux d'intégrité pour le logiciel (par exemple la gradation d'intégrité) selon la norme IEEE 1012 pour le système critique.

La caractérisation des défauts : Caractériser ces défauts favorise la compréhension du produit, facilite des corrections au processus logiciel ou au produit et informe le gestionnaire de projet et le client du statut du processus ou du produit. Il y a plusieurs taxonomies de défauts qui existent et sont utilisées en industrie. La caractérisation des défauts est présentée selon la norme IEEE 1044 qui est également utilisée pour décrire comment documenter les anomalies identifiées lors de l’élaboration des audits et des revues.

En dépistant ces défauts, l’ingénieur logiciel est intéressé non seulement par le nombre de défauts, mais aussi par leurs types. L'information seule, sans une certaine classification, n'est pas vraiment utile pour identifier les causes fondamentales des défauts puisqu’il faut que des types spécifiques de problèmes soient regroupés afin de faire une analyse et une synthèse des problématiques. Il est donc nécessaire d’établir une taxonomie de défauts qui soit significative à votre organisation. Cela signifie que l’on doit être en mesure d’associer un défaut en précisant son endroit probable d’apparition dans le cycle de vie du logiciel.

Les activités d’AQL visent à découvrir les défauts à toutes les étapes du développement, de la maintenance et des opérations du logiciel. Il est nécessaire que l’ingénieur logiciel définisse clairement la terminologie en utilisant une norme reconnue comme la norme ISO/CEI 24765. Selon la norme ISO/CEI 24765:

• une erreur : « une action humaine qui produit un résultat incorrect » ;
• un défaut : « une étape, un processus, ou une définition incorrecte de données dans un programme machine » ;
• un échec (ou défaillance) : « le résultat observable d'un défaut ».

Voici l’interprétation correcte de ces termes : des échecs observés pendant les tests proviennent de défauts du logiciel qui sont dus à une erreur pendant le processus de développement. Des modèles de fiabilité peuvent être établis à partir des données d'échecs rassemblées pendant les tests du logiciel, ou pendant son opération et peuvent être employés ainsi pour prévoir de futurs échecs et pour aider aux décisions concernant l’effort de test.

Une action probable résultante des résultats d’activités d’AQL est de corriger les défauts du produit examiné. D'autres actions permettent l'accomplissement de la pleine valeur des résultats des activités d’AQL. Ces actions incluent l’analyse et la synthèse des tests et l'utilisation des techniques de mesure pour améliorer le produit et le processus, de même que pour dépister tôt les défauts et les éliminer.

Les données historiques concernant les défaillances et les défauts trouvés pendant l'exécution des différentes techniques d’AQL peuvent être perdues à moins qu'elles ne soient enregistrées. En utilisant quelques techniques de qualité (par exemple, les revues, les audits, et les inspections), le secrétaire est présent pour rédiger un compte rendu des enjeux et des décisions. Quand des outils automatisés sont utilisés, les extrants de l’outil peuvent fournir les informations en ce qui a trait aux défauts soulevés.

Les techniques de gestion de la qualité du logiciel : Les techniques de gestion de la qualité peuvent être classées par catégorie. Le SWEBOK présente les catégories suivantes : statique, manuelle, analytique, dynamique.

Les techniques statiques (Analyse statique de programmes) impliquent l'examen de la documentation et du logiciel du projet ainsi que d'autres informations sur les produits du logiciel, sans les exécuter. Ces techniques peuvent inclure des activités individuelles ou des activités analytiques conduites par des individus, avec ou sans l'aide d’outils automatisés. La mise en place de techniques individuelles, y compris des revues et des audits, peut varier d'une réunion formelle à une réunion informelle (ou même à une activité personnelle effectuée seule à son bureau). Une préparation, avant l’exécution de la technique individuelle, peut être nécessaire. Certaines informations additionnelles, autres que les documents directement examinés, peuvent inclure, par exemple, des listes de contrôle ainsi que des résultats des tests. Ces activités de revues et d’audits ont déjà été présentées.

Un ingénieur logiciel doit généralement appliquer des techniques analytiques dans l’exécution de son travail. Des exemples de ces techniques incluent : l'analyse de complexité, l'analyse de flux de contrôle et l'analyse algorithmique. Chaque type de technique analytique a un but spécifique. Bien que ces techniques ne soient pas applicables à chaque projet, il est important de les connaître et de savoir à quel moment elles peuvent contribuer à la qualité. Par exemple, l’analyse de complexité est utile pour déterminer la qualité d'une conception logicielle lorsqu’il y a des lenteurs lors de l'exécution d’un logiciel. Les résultats d'une analyse de complexité peuvent également être employés pour développer des cas de tests. Dans le cas d’un logiciel qui exécute une grande quantité d'algorithmes complexes, l'analyse algorithmique est utile, particulièrement pour vérifier qu’un algorithme est incorrect et pourrait causer une défaillance catastrophique. Il y a un grand nombre de techniques analytiques disponibles à l’ingénieur logiciel. La liste et les références présentées au SWEBOK permettent le choix judicieux d'une technique pertinente et offre des références complémentaires. D’autres types de techniques analytiques, plus formelles, sont aussi connus sous le nom de méthodes formelles. Elles sont employées pour vérifier des exigences et des conceptions de logiciel embarqué. Dans le domaine de l’aérospatiale, une preuve d'exactitude est souvent employée dans la vérification des parties critiques des systèmes embarqués, tels que des exigences spécifiques de sécurité et de sûreté.

Plusieurs types de techniques, Analyse dynamique de programmes peuvent aussi être utilisées lors du développement, de la maintenance et de l’opération d’un logiciel. De manière générale, ce sont des techniques utilisées lors de tests, de simulations, de vérification de modèles et d'exécution symbolique. Elles sont dynamiques car elles requièrent l’exécution du code source du logiciel. La lecture de code est considérée une technique statique d’AQL, mais les ingénieurs logiciels expérimentés peuvent mentalement exécuter le code tout en le lisant. En ce sens, la lecture de code peut également se qualifier comme technique dynamique d’AQL. Les individus, selon le rôle qu’ils jouent dans l'organisation, peuvent considérer et appliquer ces techniques différemment.

La mesure de la qualité du logiciel : Les modèles de la qualité du produit logiciel incluent des mesures qui ont pour objectif de déterminer le degré atteint pour chaque caractéristique de qualité. Si elles sont choisies correctement, les mesures peuvent soutenir la qualité de logiciel (entre autres les aspects des processus de cycle de vie de logiciel). Elles peuvent aider dans le processus décisionnel de management; elles peuvent trouver des secteurs problématiques et des goulots d'étranglement dans le processus de logiciel; elles peuvent aussi aider les ingénieurs logiciels à évaluer la qualité de leur travail et enfin elles offrent la possibilité d’améliorer de la qualité du processus à plus long terme.

En tenant compte de la sophistication croissante du logiciel, les questions de la qualité vont au-delà d’un simple fonctionnement du logiciel; elles imposent la vérification des objectifs mesurables de qualité. Il y a quelques thèmes plus précis pour lesquels la mesure soutient directement le système de gestion de la qualité. Cela inclut l'aide qu’il faut apporter pour décider quand l'essai pourra cesser. Les modèles de fiabilité et les étalonnages (benchmarking), employant les défauts et les données d'échec, sont alors utiles.

Le projet logiciel se préoccupe des coûts associés au processus de système de gestion de la qualité alors que les modèles génériques de coûts de la qualité permettent de résoudre ce problème. Ces modèles sont conçus afin d’estimer, tôt dans le projet, l’effort nécessaire pour trouver des défauts. Les données historiques de l’organisme offrent alors la possibilité d’estimer les coûts envisagés.

Finalement, les rapports du système de gestion de la qualité fournissent des informations valables non seulement sur ces processus, mais aussi sur la façon dont tous les processus de cycle de vie de logiciel peuvent être améliorés. De toute évidence, les mesures pour atteindre les caractéristiques de qualité visées peuvent être utiles par elles-mêmes (par exemple; le nombre ou la proportion d’exigences défectueuses), les mathématiques et les techniques graphiques peuvent également être appliquées pour favoriser l'interprétation des mesures. Ces techniques peuvent être regroupées dans les catégories suivantes :

• les statistiques (par exemple: analyse de Pareto, diagrammes, graphique de dispersions, distribution normale) ;
• les tests statistiques (par exemple : test binomial, test du chi carré) ;
• l’analyse de tendance (trends analysis) ;
• le modèle prévisionnel (par exemple : modèles de fiabilité).

Les techniques statistiques et les tests fournissent souvent une vision instantanée des secteurs plus délicats sur lesquels il faudrait se concentrer. Les diagrammes et les graphiques résultants sont des aides de visualisation que les décideurs peuvent employer pour focaliser des ressources, là où elles semblent les plus nécessaires. Les résultats de l'analyse de tendance peuvent indiquer : qu'un échéancier n'a pas été respecté au moment des essais, ou que certaines classes de défauts deviennent plus importantes à moins que des actions correctives soient prises. Les modèles de prédiction aident à la planification des essais et à la prédiction des défauts.

L’analyse des défauts consiste à compter les occurrences des défauts et ensuite à appliquer des techniques statistiques afin de mieux comprendre quels types de défauts se produisent le plus fréquemment. Ces techniques sont utiles afin d’identifier des tendances, et de vérifier à quel point les techniques de détection de défauts fonctionnent et à quel point les processus du développement et de la maintenance introduisent des défauts. La mesure de couverture des tests peut permettre d’estimer l'effort restant des tests, et de prévoir les défauts résiduels.

À partir de ces techniques de mesure, des profils de défauts peuvent alors être développés. Lors de la réalisation du prochain projet logiciel, au sein de cette organisation, ces profils peuvent être employés pour guider les processus d’AQL, c’est-à-dire qu’ils permettent de déployer les efforts, là où les défauts sont le plus susceptibles de se produire. De la même manière, l’étalonnage (benchmarks) peut aussi contribuer à déterminer quand un logiciel est prêt pour sa livraison.