Méthodologie Disciplines connexes

Qualité logicielle - Caractéristiques du logiciel (logiciel) comme degré de conformité aux exigences. Dans le même temps, les exigences peuvent être interprétées assez largement, ce qui génère un certain nombre de définitions indépendantes du concept. La définition de l'ISO 9001 est la plus souvent utilisée, selon laquelle la qualité est "le degré de conformité des exigences des caractéristiques".

Qualité du code source

La qualité du code peut être déterminée par divers critères. Certains d'entre eux ne comptent que du point de vue d'une personne. Par exemple, dans quelle mesure le texte du programme est absolument pas important pour un ordinateur, mais peut avoir une valeur grave pour l'accompagnement ultérieur. Bon nombre des normes de conception de code existantes définissant l'accord spécifique à l'accord et demandent à un certain nombre de règles améliorant la lisibilité du Code sont destinées à faciliter le soutien futur des logiciels, y compris le débogage et la mise à jour. Il existe d'autres critères définissant: "Eh bien" si le code est écrit, par exemple, tel que la structure - le degré de cloison logique dans un certain nombre de blocs contrôlés.

Code de lisibilité
Facilité de support, test, débogage, corrections d'erreur, modifications et portabilité
Faible complexité du code
Utilisation faible des ressources: heure de la mémoire et du processeur
Traitement correct des situations exceptionnelles
Petit nombre d'avertissements lors de la compilation et de la liaison

Méthodes d'amélioration de la qualité du code: refactoring.

Facteurs de qualité

Le facteur de qualité est une exigence non fonctionnelle pour le programme, qui n'est généralement pas décrite dans le contrat avec le client, mais, néanmoins, est une exigence souhaitable d'accroître la qualité du programme.

Certains des facteurs de qualité:

Comprendre le but du logiciel devrait être clair du programme lui-même et de la documentation. De complétude, toutes les parties nécessaires du programme doivent être présentées et entièrement mises en œuvre. Brefessness Pas d'excès d'informations en double. Les parties dupliquées du code doivent être converties en un appel procédure totale. La même chose s'applique à la documentation. La portabilité de la facilité dans l'adaptation du programme à un autre environnement: une autre architecture, plate-forme, système d'exploitation ou sa version. La cohérence dans tout le programme et la documentation devraient utiliser les mêmes accords, formats et désignations. L'accompagnement est de savoir comment il est difficile de modifier le programme pour répondre à de nouvelles exigences. Cette exigence indique également que le programme doit être bien documenté, pas trop confus et disposer d'une réserve pour l'utilisation de ressources (mémoire, processeur). La testabilité permet au programme d'effectuer la vérification des caractéristiques d'acceptation, est-elle soutenue par la possibilité de mesurer les performances. Facilité d'utilisation de la simplicité et de la facilité d'utilisation du programme. Cette exigence s'applique principalement à l'interface utilisateur. Fiabilité Pas d'échecs et de dysfonctionnements dans le travail des programmes, ainsi que la simplicité de la fixation des défauts et des erreurs: Efficacité de la structure Quelle que soit rationnellement, le programme fait référence aux ressources (mémoire, processeur) lors de l'exécution de ses tâches. sécurité

Du point de vue de l'utilisateur

En plus de la vue technique sur le logiciel de qualité, une évaluation de la qualité de la position de l'utilisateur est une évaluation de la qualité. Pour cet aspect de la qualité, le terme "convivialité" est parfois utilisé. Il est assez difficile d'obtenir une évaluation de la convivialité pour un logiciel donné. Les problèmes les plus importants affectant l'évaluation:

L'interface utilisateur est-elle intuitive?
Quelle est la facilité d'opération simple et fréquente?
Quelle est la facilité d'opérations complexes?
Est le programme de messages d'erreur compréhensibles?
Le programme se comporte-t-il toujours comme prévu?
Y a-t-il une documentation et à quel point c'est pleinement?
L'interface utilisateur est-elle auto-descriptive / auto-documentant?
Y a-t-il toujours des retards avec la réponse du programme sont acceptables?

voir également

Liens

Développement de logiciels
Célèbre Visages
Traiter
Concepts
les directions
Des modèles Développement
Autres modèles
Autre

Fondation Wikimedia. 2010.

Regardez ce qui est "logiciel de qualité" dans d'autres dictionnaires:

La capacité d'un produit logiciel à confirmer sa spécification, à condition que la spécification soit axée sur les caractéristiques que l'utilisateur souhaite recevoir. Voir aussi: Qualité logiciel Logiciels financiers ... ... Vocabulaire financier

Lorsque Grace Hopper a travaillé avec un ordinateur Harvard Mark II à l'Université Harvard, ses collègues ont découvert cette mole qui était coincée dans le relais et préservant ainsi les travaux de l'appareil, après quoi elle a noté avoir été "débogué" (débogage).. .. ... Wikipédia

Développement de logiciels Traitement des processus Analyse de processus Conception Document de programmation ... Wikipedia

Développement de logiciels (génie du logiciel anglais, développement de logiciels) Il s'agit d'une activité de genre (profession) et d'un processus visant à créer et à maintenir la santé, la qualité et la fiabilité des logiciels, en utilisant ... Wikipedia

- Crise de logiciel Le terme a une fois utilisé en informatique pour décrire les conséquences de la croissance rapide de la puissance de calcul des ordinateurs et de la complexité des problèmes pouvant être résolus avec leur aide. En substance, ceci ... ... Wikipedia

Le nouvel Airbus A 380 utilise beaucoup de logiciels pour créer une cabine moderne dans l'avion. La méthode de génie logiciel permettait de créer un logiciel de l'aéronef décrit par des millions de lignes ... Wikipedia

Capacité logicielle à travailler sur diverses plates-formes matérielles ou à exécuter divers systèmes d'exploitation. Synonymes: tolérance logicielle Voir aussi: Logiciel de qualité Systèmes ouverts ... ... Vocabulaire financier

Caractéristiques du produit logiciel, qui: vous permet de minimiser les efforts des utilisateurs pour préparer les données source, l'utilisation du logiciel et l'évaluation des résultats obtenus, et vous permettent également de causer des émotions positives ... ... Vocabulaire financier

Caractéristiques du produit logiciel permettant de minimiser les efforts pour y apporter des modifications: éliminer les erreurs; Ou pour modification conformément aux besoins changeants des utilisateurs. Voir aussi: Logiciel de qualité ... ... ... Vocabulaire financier

La capacité du produit logiciel à effectuer un ensemble de fonctions: définie dans sa description externe; et satisfaire aux utilisateurs spécifiés ou ayant des besoins impliqués. Synonymes: Interopérabilité du logiciel Voir aussi: Qualité ... ... ... Vocabulaire financier

Livres

Code parfait: Guide pratique du développement de logiciels, McConnell C .. Depuis plus de 10 ans, la première édition de ce livre a été considérée comme l'une des meilleures directives de programmation pratiques. Maintenant, ce livre est entièrement mis à jour avec les tendances et les technologies actuelles ...

La norme de qualité principale dans le domaine de l'ingénierie du logiciel est actuellement la norme ISO / IEK 9126. Il définit la nomenclature, les attributs et les métriques des exigences de qualité logicielle. Relativement récemment, cette norme est devenue l'un des facteurs déterminants lors de la modélisation de la qualité du logiciel et reste jusqu'à présent.

En plus de cela, un ensemble de normes ISO / IEK 14598 est libéré, qui régule les méthodes d'évaluation de ces caractéristiques. Dans l'agrégat, ils forment un modèle de qualité connu sous le nom de carré.

L'approche générale consiste à identifier d'abord un petit ensemble d'attributs de la qualité du plus haut niveau d'abstraction, puis dans la direction "Top Down" pour scinder ces attributs aux ensembles d'attributs subordonnés. La norme ISO / IEK 9126 est un exemple typique de cette approche.

Dans le cadre du modèle carré, les 6 caractéristiques de qualité de base suivantes sont attribuées:

1. Fonctionnalité (précision, cohérence, interopérabilité, sécurité, aptitude). Les exigences fonctionnelles constituent traditionnellement le principal sujet de spécifications, de modélisation, de mise en œuvre et de certification des logiciels. Ils sont formulés sous forme d'allégations dans la modalité impérative décrivant le comportement du système. L'utilisation de méthodes formelles vous permet d'amener le niveau d'écart du comportement réel du système à partir de zéro. Ceci est réalisé en exprimant les exigences fonctionnelles sous forme de propositions de calcul formel appropriée. La vérification est donc réduite à une preuve stricte.

2. Fiabilité (Durabilité, exhaustivité, répartition). Les indicateurs de performance caractérisent le comportement du système lors de la sortie des limites des valeurs standard des paramètres de fonctionnement dues à une défaillance entourée ou dans le système lui-même. En évaluant les attributs de fiabilité, les méthodes de théorie des probabilités et de statistiques mathématiques sont appliquées. Les exigences des exigences sont particulièrement importantes dans le développement de systèmes critiques pour assurer la sécurité de l'activité vitale. Bien que l'utilisation de méthodes formelles contribuait à une diminution du nombre d'erreurs internes (c'est-à-dire la croissance de l'achèvement du système), assurant la fiabilité dans son ensemble nécessite des approches spéciales qui tiennent compte des détails différents types Systèmes.

3. Commodité(Efficacité du développement, de l'ergonomie, de la compréhension). La conformité aux exigences du système est extrêmement difficile à évaluer. Les approches proposées comprennent les mesures du flux d'unités de réglementation (normos) dépensées par les utilisateurs à maîtriser le système, ainsi que de mener et d'analyser des évaluations d'experts, notamment en utilisant les méthodes de logique floues (logique floue). Dans le contexte de l'utilisation de méthodes formelles la meilleure solution L'orientation initiale du formalisme, qui peut principalement refléter la structure de la zone initiale selon précision. Par exemple, lors de la création de systèmes informatiques, le critère de l'adéquation du formalisme du point de vue de l'utilisateur futur consiste à soutenir une langue mathématique abstraite qui ne dépend pas des restrictions conceptuelles imposées par les technologies informatiques.

4. Efficacité(pour les ressources et dans le temps). Les attributs d'efficacité s'appliquent traditionnellement au nombre d'indicateurs quantitatifs les plus importants de la qualité des systèmes logiciels. Leurs valeurs sont soumises à la fixation de la documentation opérationnelle par logiciel et matériel. Il existe une boîte à outils très développée pour mesurer ces valeurs. Des méthodes ont également été développées pour prédire les valeurs intégrales des indicateurs d'efficacité du système en fonction des valeurs de ces indicateurs pour les composants du système lui-même et son environnement. Le choix des méthodes formelles pour garantir l'efficacité devrait être accordée à une attention particulière. Dans le même temps, il convient de garder à l'esprit que, bien qu'il existe une relation étroite entre la productivité et l'intensité des ressources, des approches pour assurer chacune de ces exigences dans l'affaire général ont une nature différente.

5. Accompagnement (analyse facile, variabilité, stabilité ). Les exigences des accompagnements visent principalement à minimiser les efforts visant à escorter et à améliorer le système dépensé par le personnel opérationnel. Pour leur évaluation, diverses méthodes de prévision des coûts pour la mise en œuvre des procédures de support standard sont utilisées. La valeur intégrale du soutien de systèmes à long terme peut nettement dépasser le coût de leur développement. L'accompagnement est sensiblement simplifié dans le cas où le développement a été effectué en utilisant des méthodes formelles, car elle est disponible dans un certain sens, un ensemble exhaustif de documentation technologique et de tests de vérification.

6. Tolérabilité (adaptabilité, cohérence avec normes et règles, flexibilité d'installation, remplacement ). La tolérance du système caractérise le degré de liberté lors du choix des composants de l'environnement systémique nécessaires à son fonctionnement. La valeur de la tolérabilité est entravée par l'incrément de principe, la dynamique de la liste options possibles Les environnements sont dus à des progrès rapides dans le domaine de celui-ci. Les systèmes développés en utilisant des méthodes formelles, en règle générale, diffèrent par des niveaux élevés de tolérance. En particulier, si un tel système ne prend pas en charge une plate-forme technologique cible, la création d'une mise en œuvre d'une "clone" de son modèle abstrait à l'aide de cibles de programmation nécessite des coûts de manière significative que de remplacer le système lui-même ou la plate-forme.

Le modèle de qualité créé en vertu de la présente norme est déterminé par les caractéristiques totales du produit. Les caractéristiques peuvent à leur tour être clarifiées en d'autres termes, divisées hiérarchiquement en préfabriquements de qualité. Par exemple, la caractéristique de l'accompagnement peut être représentée par de tels préfracteurs que la simplicité de l'analyse, de la variabilité, de la stabilité, vérifiée.

Et enfin, le niveau inférieur de la hiérarchie représente directement des attributs de logiciels pouvant être une description précise et une mesure. Les exigences de qualité peuvent être présentées comme des limitations sur le modèle de qualité. L'évaluation de la qualité du produit dans ce cas se produit conformément au schéma suivant. Au début, les attributs du logiciel sont évalués. Pour ce faire, la métrique est sélectionnée et l'échelle d'estimation est progressivement en fonction des degrés possibles de l'attribut des restrictions imposées. Pour chaque évaluation individuelle de l'attribut de gradation, la gradation est généralement choisie à nouveau et dépend des exigences de qualité imposées. L'ensemble des attributs «mesurés» sont des critères d'estimation des pré-caractéristiques et des caractéristiques, ainsi que le résultat de la qualité du produit.

Ticket 26 27.

Qualité logicielle - Caractéristiques du logiciel (logiciels) comme un degré de conformité aux exigences. Dans le même temps, les exigences peuvent être interprétées assez largement, ce qui génère un certain nombre de définitions indépendantes du concept. La définition de l'ISO 9001 est la plus souvent utilisée, selon laquelle la qualité est "le degré de conformité des exigences des caractéristiques".

Qualité du code source

Code de lisibilité

Facilité de support, test, débogage, corrections d'erreur, modifications et portabilité

Faible complexité du code

Utilisation faible des ressources: heure de la mémoire et du processeur

Traitement correct des situations exceptionnelles

Petit nombre d'avertissements lors de la compilation et de la liaison

Méthodes d'amélioration de la qualité du code: refactoring.

Facteurs de qualité

Certains des facteurs de qualité:

constabilité

La nomination de logiciels devrait être claire du programme lui-même et de la documentation.

Toutes les parties nécessaires du programme doivent être présentées et entièrement mises en œuvre.

brièveté

Pas d'excédent, des informations en double. Les parties en double du code doivent être converties en un défi de la procédure générale. La même chose s'applique à la documentation.

portable

Facile à adapter le programme à un autre environnement: une autre architecture, plate-forme, système d'exploitation ou sa version.

cohérence

Tous les mêmes accords, formats et notation doivent être utilisés dans tout le programme et dans la documentation.

accessibilité

Dans quelle mesure il est difficile de changer le programme pour répondre à de nouvelles exigences. Cette exigence indique également que le programme doit être bien documenté, pas trop confus et disposer d'une réserve pour l'utilisation de ressources (mémoire, processeur).

essai

Si le programme vous permet de vérifier les caractéristiques d'acceptation, est-il pris en charge si la possibilité de mesurer les performances est prise en charge.

facilité d'utilisation

Simplicité et facilité d'utilisation du programme. Cette exigence s'applique principalement à l'interface utilisateur.

fiabilité

manque d'échecs et d'échecs dans le travail des programmes, ainsi que la simplicité de la fixation des défauts et des erreurs:

structure

efficacité

Dans quelle mesure le programme fait référence à des ressources (mémoire, processeur) lors de l'exécution de ses tâches.

Sécurité

ISO 9126 (GOST R ISO / IEC 9126-93) - "Informatique. Évaluation logicielle. Caractéristiques de la qualité et des conseils sur leur utilisation. " ISO 9126 est une norme internationale qui définit les caractéristiques d'évaluation de la qualité logicielle (ci-après dénommée). Analogue russe de la norme GOST 28195. La norme est divisée en 4 parties décrivant les questions suivantes: un modèle de qualité; métriques de qualité externe; métriques de qualité interne; Métriques de qualité

Le modèle de qualité installé dans la première partie de la norme ISO 9126-1 classifie la qualité du logiciel dans 6 ensembles structurels de caractéristiques, qui sont à leur tour détaillés par des caractéristiques sous-caractéristiques (sous-produits), telles que:

Fonctionnalité - Ensemble d'attributs caractérisant, conformité à la fonctionnalité de l'ensemble de fonctionnalités requises par l'utilisateur. Détails avec les pré-exécutants suivants (Subchactercy):

Adéquation pour application

Exactitude (correcte, précision)

Capacité à interagir (en particulier réseau)

Sécurité

Fiabilité - un ensemble d'attributs liés à la capacité de maintenir son niveau de qualité du fonctionnement dans des conditions établies pendant une certaine période. Détails avec les pré-exécutants suivants (Subchactercy):

Niveau d'achèvement (manque d'erreurs)

Résistant aux défauts

Répartition

Disponibilité

Prêt

La praticité (applicabilité) est un ensemble d'attributs liés au volume des travaux requis pour l'exécution et l'évaluation individuelle de cette exécution par un cercle donné ou présumé d'utilisateurs. Détails avec les pré-exécutants suivants (Subchactercy):

Commodité

Usage facile

RAPPORT

Attractif

Efficacité - Un ensemble d'attributs liés au rapport entre le niveau de qualité du fonctionnement du logiciel et la quantité de ressources utilisées dans les conditions établies. Détails avec les pré-exécutants suivants (Subchactercy):

Efficacité temporaire

Ressources usagées

L'accompagnement est un ensemble d'attributs liés au volume de travail requis pour des modifications spécifiques (modifications). Détails avec les pré-exécutants suivants (Subchactercy):

Commodité pour analyse;

Changeabilité

Stabilité

Essai

La mobilité est un ensemble d'attributs liés à la capacité à être transférés d'un environnement à un autre. Détails dans les caractéristiques suivantes (SubCharactercy):

Adaptabilité

Simplicité de l'installation (installation)

Coexistence (conformité)

Remplacement

La présence n'est pas fournie dans la liste décrite ci-dessus, mais elle appartient à toutes les caractéristiques. Cette caractéristique devrait refléter l'absence de contradiction avec d'autres normes ou caractéristiques. Par exemple, la conformité de la fiabilité et de la pratique.

Chaque substitution de haute qualité (sous-artacideriste) (par exemple, l'adaptabilité) est par la suite divisée en attributs. L'attribut est l'essence qui peut être vérifiée ou mesurée dans le produit logiciel. Les attributs ne sont pas définis dans la norme en raison de leur diversité dans divers logiciels.

La norme a souligné le modèle de caractéristiques de qualité à utiliser. Les principales caractéristiques de la qualité du logiciel (ci-après PS) à utiliser sont recommandées:

Efficacité du système - "Application de la promotion du logiciel"

Productivité - "Performance Lors de la résolution des tâches principales du PS, réalisée avec des ressources en fait limitées dans un environnement externe spécifique"

Sécurité - "Fiabilité du fonctionnement d'un complexe de programmes et un risque possible de son utilisation pour les personnes, les entreprises et un environnement externe"

Satisfaire les exigences et les coûts des utilisateurs conformément aux objectifs de l'utilisation de PS

Les deuxième et troisième parties de la norme ISO 9126-2.3 sont consacrées à la formalisation des métriques externes et internes respectivement des caractéristiques de la qualité du complexe PS. Il contient le contenu et les recommandations générales sur l'utilisation des métriques et des interconnexions appropriées entre types métriques.

La quatrième partie de la norme ISO 9126-4 est destinée aux acheteurs, fournisseurs, développeurs, accompagnant, utilisateurs et gestionnaires de qualité PS. Il a répété le concept de trois types de métriques, ainsi que d'annoté les mesures recommandées des caractéristiques PS.

Il y a un peu plus d'un an, mon article sous le nom "Principes de gestion de la qualité du programme" a été publié dans le magazine "Open Systems". Version en ligne Disponible ici: http://www.osp.ru/os/2008/06/5344965/. Avant la publication, la version initiale de l'article a été fermement retravatée par les éditeurs, à la suite de laquelle sa taille a diminué en 2 fois et que le texte, y compris le nom, a également été très habité. Maintenant, j'ai décidé de publier la version mise à jour de l'auteur dans mon blog, rendant les petits ajouts là-bas. L'article n'est pas au format du blog, mais plutôt de la publication scientifique ou éducative, alors pardonnez-moi.

Le thème de la qualité du logiciel est souvent souvent mentionné dans la littérature et les articles russophones, mais sur la longueur du discours ou parler de tests de test est rare. L'objectif de cet article est de donner une compréhension holistique du problème de la qualité logicielle (logiciels) et des principes de base du logiciel de gestion de la qualité. L'article donne la définition du concept de qualité logicielle, décrit une approche qui simplifie la tâche de test de qualité est une brève vue d'ensemble des méthodes d'amélioration de la qualité bien connues.

I. Concept de qualité logicielle

Détermination de la qualité du logiciel
Selon GOST R ISO 9000-2001, la qualité est le "degré de conformité des caractéristiques des caractéristiques (produit)". " Ceci est une définition générale. S'il est littéralement transféré dans la zone de développement logiciel (logiciel), il peut ne pas être interprété correctement. Le fait est que le développement des exigences, en ce sens, comme ce terme est compris dans la zone de logiciels, il fait partie intégrante du processus de développement de ce logiciel. La qualité des exigences relatives au logiciel (PP) affecte directement la qualité de ce PP lui-même. En d'autres termes, si les conditions requises pour PP sont de mauvaise qualité, le produit lui-même développé par ces exigences sera également de mauvaise qualité, même en cas de conformité parfaite.

Si le mot "exigences" dans la détermination du GOST devrait être remplacé par les mots "objectifs de projet" (ici le projet fait référence au processus de développement d'un produit logiciel spécifique ou d'élargir les fonctionnalités du produit disponible), tout tombe en place . En outre, dans l'article, nous signifierons les éléments suivants sous la qualité de PP:

Je note que cette définition ne concerne pas le coût de la valeur. Les objectifs du projet sur le développement de PP sont principalement déterminés par des objectifs commerciaux et des restrictions existantes.

Critères de qualité PP
La qualité de PP est un concept complexe et multiforme. En général, la qualité est une sorte de fonction des variables suivantes:

Fonctionnalité (combien de PP est utile pour l'utilisateur);
Qualité interface utilisateur (Facilité d'utilisation, facilité d'apprentissage);
Fiabilité (aucun défaut en PP, résistance aux échecs);
Performance, consommation de ressources, exigences relatives à l'environnement extérieur;
Prise en charge de la qualité de l'information (documentation);
Accompagnement (qualité de l'architecture et du code, de la qualité interne);
+ Peut-être d'autres critères.

D'autres options pour la liste des critères de qualité peuvent être trouvées, par exemple, dans ,. La société développeuse détermine (doit définir) ses normes de qualité pour chaque critère pour chaque projet de programme. Lors de l'évaluation de la qualité, il est nécessaire de pouvoir quantifier chacun des critères.

L'influence des activités du cycle de vie sur la qualité de PP
Envisagez des activités typiques du cycle de vie du projet logiciel et de leur influence sur les critères de qualité énumérés ci-dessus. Le tableau ci-dessous le caractère * signifie que ce type d'activité (chaîne) affecte explicitement ce critère de qualité (colonne):

Le point principal sur lequel je voudrais faire attention à ici, les éléments suivants: sur la qualité du produit final, toutes les phases et les types d'activités du projet sont influencés sans exception - du plus ancien au plus récent. Ainsi, dans quelle mesure nous travaillons bien et qualitativement à chaque phase du projet (et non seulement, par exemple, dans la phase de test), cela dépend de la manière dont la haute qualité est mise au point sur le produit. Ou en d'autres termes, la qualité du processus de développement détermine la qualité du produit développé, c'est-à-dire La qualité du produit est indissociable de la qualité du processus et d'améliorer la qualité de la PP, il est nécessaire d'améliorer la qualité du processus de développement de ce PP.

Le concept généralisé de défaut
Il serait pratique d'introduire et d'utiliser un certain critère de qualité généralisée pour analyser la qualité au lieu de plusieurs critères dispersés. Un tel critère est le concept généralisé d'un défaut:

Ainsi, nous appelons un défaut de toute déviation de la norme de qualité pour l'un des critères ci-dessus. Par exemple, le manque de fonctionnalité ou de fonctionnalité excédentaire - un défaut. Interface inconfortable - défaut. Un code mal conçu ou sale, qui affectera négativement le défaut d'accompagnement. Performance inacceptable - Défaut. Le travail incorrect du programme ("sac", comportement erroné) est un cas particulier d'un défaut. Une erreur d'orthographe dans la documentation de l'utilisateur est également un défaut.

Les défauts peuvent être classés, par exemple, par les paramètres suivants:

Type de défaut (déterminé par la phase de développement ou d'activité sur laquelle elle a été soumise);

La criticité du défaut (en ce qui concerne sa présence en PP);

La priorité du défaut (quelle importance il est de le réparer);

La complexité du défaut (combien de temps pour le corriger);

Avoir un indicateur de qualité de référence généralisé similaire, il devient plus facile d'évaluer et d'analyser la qualité de la PP développée, ainsi que de la qualité de notre processus de développement. Vous pouvez assumer le nombre de défauts ou la somme de leurs poids (selon n'importe quel paramètre), vous pouvez évaluer la densité des défauts par unité de volume du produit, analyser quelles phases du processus sont les plus problématiques pour nous, etc. Maintenant, la lutte pour la qualité n'est rien que la lutte contre les défauts.

II. Gestion de la qualité du produit du programme

Approche traditionnelle de la qualité du logiciel
Entrer dans le concept généralisé d'un défaut, vous pouvez dessiner une planification décrivant une modification du nombre de défauts dans le projet au fil du temps (Fig. 1). Pour la simplicité, envisagez le modèle de parcs à eau du cycle de vie du projet. Avec une approche traditionnelle de la qualité de PP, où l'accent est mis sur les tests en profondeur, ce tableau peut ressembler à ceci.

Figure. 1. Modification du nombre de défauts dans le projet au fil du temps avec une approche traditionnelle de la gestion de la qualité et d'un cycle de vie de cascade.

Ici, la ligne rouge supérieure représente le nombre de défauts fabriqués à l'heure actuelle (il convient de préciser que cette ligne est imaginaire, car nous ne pourrons pas ne pas calculer avec précision le nombre total de défauts jusqu'à ce qu'ils ne trouvent tous). La ligne verte inférieure décrit le nombre de défauts trouvés et corrigés à l'heure actuelle (ici, nous supposons que les défauts sont corrigés presque immédiatement après avoir été trouvés). La différence entre la ligne rouge et verte à chaque instant affiche le nombre de défauts actuellement disponibles. Nous sommes le plus intéressés par la différence qui sera à la fin du projet. Ce que c'est moins, mieux que notre produit s'est avéré. Du point de vue de la qualité, le cycle de vie de ce chiffre est présenté comme une concurrence entre les processus de fabrication et de défauts corrigés.

Efficacité de la recherche d'un défaut
Considérez l'une des phases visant à rechercher et à corriger les défauts, tels que la phase de test du système. Au cours de cette phase, une certaine quantité de défauts trouvés D est détectée, dans le même temps, certains défauts restent non scrupules au moment de la résiliation de la phase D manquée (Fig. 2). Nombre total Les défauts qui ont traversé la phase seront égaux à D trouvé + d manqués.

Figure. 2. Modification du nombre de défauts pour une phase.

Appelons le ratio des défauts trouvés au nombre total, exprimé en pourcentage, l'efficacité de la recherche de défauts (% EPD):

% EPD = .

Pour chaque phase, au cours de laquelle les défauts sont fixes, avec un processus mûre et d'autres conditions égales, il convient de s'attendre à ce que cette valeur soit approximativement constante. Ce fait permet de quantifier le niveau de qualité (exprimé dans le nombre de défauts non dédiés) pour le projet en cours et pour des projets planifiés.

L'efficacité de la recherche de défaut peut être visualisée à la fois pour des phases et des activités individuelles et pour tout le cycle de vie de développement. Dans ce cas, l'efficacité des phases individuelles déterminent l'efficacité de l'ensemble du cycle de vie. Chaque phase de recherche de défauts peut être considérée comme une sorte de filtre qui contient une partie des défauts et tout le cycle de vie en tant que système de filtrage ,. Si, au début du cycle de vie, il existe de mauvais filtres qui manquent beaucoup de défauts, ces défauts s'accumulent et les filtrent bien, à la fin du cycle de vie (phase de test), nous aurons besoin d'un très bon filtre.

Le coût de la correction des défauts
Les défauts avec le temps non seulement ont tendance à s'accumuler sinon prendre des mesures précoces pour les éliminer. Mais aussi bien connu est le fait que plus le défaut vit dans le projet, il est plus coûteux de le réparer (c'est-à-dire plus laborieux) et la dépendance est souvent exponentielle. Pour un modèle de cascade du cycle de vie, cette dépendance est bien illustrée par le graphique suivant (Fig. 3).

Figure. 3. Modification du coût de la correction des défauts au fil du temps (cycle de vie de cascade).

Pour un modèle itératif du cycle de vie, la photo sera similaire (Fig. 4), seules les inscriptions changeront et l'échelle de l'axe Y pour différents types de défauts (par exemple, pour les défauts, les défauts de la balance et des conceptions sera plus grand que pour les défauts de codage).

Figure. 4. Changer le coût de la correction des défauts au fil du temps (cycle de vie itératif).

Approche globale de gestion de la qualité
Ainsi, il s'avère que, n'appuyant que sur un, même même très prudent, le problème de la qualité n'est pas résolu. Si vous ne prenez aucune mesure pour lutter contre les défauts jusqu'à l'étape de test, tant de défauts peuvent être accumulés au début des tests dans le projet qu'ils auront une tâche insupportable.

Par conséquent, des défauts doivent être recherchés et fixés constamment, tout au long du cycle de vie du projet, à partir des premières étapes et non seulement à la fin au stade des tests. À titre approximatif, à la fin du projet, au stade des tests, la recherche de défauts est déjà tardive: s'il y en a beaucoup d'entre eux accumulés, aucun test ne contribuera à transformer le produit de mauvaise qualité en haute qualité.

La deuxième approche qui peut et doit être appliquée en parallèle consiste à prévenir ou à prévenir les défauts ,.

Examinez comment le calendrier de la dépendance du nombre de défauts de temps à autre lors de l'application d'une approche globale de la gestion de la qualité (Fig. 5). L'utilisation de méthodes de recherche de défaut tout au long du cycle de vie du projet augmente la courbe des défauts trouvés. Et l'utilisation de méthodes de prévention des défauts réduit la courbe des défauts imaginés vers le bas. Ainsi, le nombre de défauts non solides sur l'ensemble du cycle de vie diminue et, par conséquent, le nombre de défauts non dédiés à la fin du projet diminue.

Figure. 5. Modification du nombre de défauts dans le projet au fil du temps avec une approche intégrée de la gestion de la qualité.

Méthodes de recherche de défauts
Les méthodes de recherche défectueuses peuvent être classées en fonction des fonctionnalités suivantes:

statique et dynamique;
manuel et automatisé.

Ainsi, 4 catégories de méthodes peuvent être distinguées:

Analyse manuelle des artefacts:
Vérification automatique statique:
Test automatisé:
Test manuel:

Chacune des méthodes énumérées a ses avantages et ses inconvénients. Certains types de défauts sont mieux capturés par certaines méthodes, d'autres. Par conséquent, la stratégie effective de recherche des défauts sera d'appliquer une combinaison de plusieurs méthodes hétérogènes. Chaque méthode de recherche, selon la qualité de sa qualité et appliquée dans des conditions spécifiques, aura son propre niveau d'efficacité, exprimé en pourcentage. Dans le livre de S. McConnell "Code parfait" Vous trouverez une table de valeurs d'efficacité de défection exemplaires de défection pour différentes méthodes (voir une copie de ce tableau ci-dessous). Notez que, selon ces données, le test a une efficacité de recherche relativement faible de défaut (25% à 40%) et afin de le rendre élevé, il est nécessaire d'augmenter le coût du processus de test à des moments (efficacité de test bêta avec le nombre des testeurs\u003e 1000 environ 75%).

Méthode de recherche	% EPD	Méthode de recherche	% EPD
Examen de conception informel (projet technique)	35%	Essai nouvelle fonction (composant)	30%
Inspections de conception formelles (projet technologique)	55%	Test d'intégration	35%
Vue d'ensemble du code informel (revue de code)	25%	Les tests de régression	25%
Inspection de code formelle	60%	Test du système	40%
Simulation et prototypage	65%	Tests bêta (<10 тестеров)	35%
Test de l'unité	30%	Test bêta (\u003e 1000 testeurs)	75%

Méthodes de prévention des défauts
Les méthodes susmentionnées de trouver des défauts ne seraient pas nécessaires si nous apprenions à développer généralement sans défauts. Il est difficilement possible de y parvenir, mais essayez de réduire le nombre de défauts altérés à essayer. Les méthodes de prévention des défauts comprennent les éléments suivants:

Prototypage - La création et le test du modèle bon marché du système développé afin de tester ses caractéristiques et d'identifier des hypothèses et des solutions incorrectes susceptibles d'entraîner de graves défauts (et modifications) lors du développement.

Utilisation de normes pour tous les types de produits produits pendant le développement logiciel (exigences, architecture, code, documentation diverses, etc.). Les normes strictes généralement acceptées vous permettent de minimiser les malentendus éventuels entre les personnes lorsque vous travaillez avec ces produits (lorsque le lecteur de produit n'a pas lu ce que j'avais à l'esprit le créateur du produit) et, par conséquent, empêchez l'apparition des défauts liés à cette .

L'utilisation de l'approche composante (ou modulaire). L'utilisation compétente d'une approche composante dans la construction de systèmes logiciels réduit sa complexité et, par conséquent, réduit l'espace des défauts possibles.

Utilisation de solutions et de composants éprouvés prouvés (propres ou achetés), dont nous sommes confiants. Plus nous devons développer de nouveaux, moins les erreurs que nous faisons.

Code Refactoring - apporter du code à la forme appropriée Il existe un bon moyen de prévenir les futurs défauts d'accompagnement, qui sont très semblables à apparaître lors de la modification des sections de code incompréhensibles et mal conçues.

Le développement préliminaire des cas de test (à l'étape de codage) vous permet de développer les exigences du système développées et il est préférable de le concevoir. Cas privé de cette approche - Développement axé sur les tests, dans lequel des tests modulaires sont démontés non après, mais avant le codage.

Analyse régulière des raisons de l'apparition des défauts les plus graves et de la recherche de moyens d'éliminer ces raisons. Cela peut se produire aux réunions périodiques de l'équipe des développeurs, ou il est possible d'effectuer une telle analyse pour chaque défaut grave découvert aux étapes de test du système ou après l'introduction. Le résultat d'une telle analyse devrait modifier le processus de développement visant à éliminer les causes des défauts ou, au moins contribuer à la détection antérieure de tels défauts.

Tes idées?

Il convient également de mentionner le facteur humain. Aucune méthode ne remplacera le professionnalisme et l'expérience des développeurs et des gestionnaires. De vrais professionnels expérimentés ont tendance à faire moins d'erreurs et à l'utilisation de leur expérience donne un bon terrain pour un développement de haute qualité. Si l'équipe se compose principalement de jeunes développeurs inexpérimentés, vous devriez alors envisager de mener une formation spéciale pour eux.

Gestion de la qualité avec cycle de vie d'itération
Considérez un cycle de vie itératif, par exemple, composé de 5 itérations, chacune pouvant être considérée comme un cycle de vie de cascade faible mais complet (Fig. 6).

Figure. 6. Modification du nombre de défauts dans le projet au fil du temps avec un cycle de vie itératif.

Supposons que l'efficacité de la recherche de défauts de chacun des cycles de cascade soit de 50%, et le même nombre de défauts sont introduits à chaque itération. Nous calculons en fonction de la formule EPD%, qui sera égale à l'efficacité de la recherche des défauts du cycle itératif constitué de cinq itérations consécutives. Après la 1ère itération, cette efficacité sera égale à 50%; Après 2ème - 62,5%; Après 30,8%; après le 4ème - 76,6%; Après la 5ème efficacité de la recherche de défauts, les 5 itérations seront de 80,6%.

Cet exemple est idéalisé et dans la vie réelle de l'efficacité de la recherche de défauts sur différentes itérations, il sera probablement différent. Cela est dû à l'hétérogénéité des activités sur différentes itérations. Mais dans tous les cas, le visage est des progrès explicites comme avant un simple cycle de vie de poisson de mer. Cet effet est expliqué très simple: à chaque itération ultérieure, nous trouvons des défauts non seulement de l'itération actuelle, mais également des défauts restants des itérations précédentes. En conséquence, l'efficacité globale de la recherche défectueuse augmente.

Ainsi, il s'avère qu'il est possible d'obtenir une amélioration de la qualité, non seulement l'introduction de méthodes supplémentaires pour la recherche rapide des défauts (tels que des inspections, des examens, etc.), mais également par la transition de la cascade au cycle de vie itératif du développement logiciel. Et théoriquement, plus les itérations, la meilleure qualité. Les tests sur les itérations initiales peuvent être considérés comme une recherche de défauts aux premiers stades du cycle de vie.

Le coût de la qualité est
Il peut sembler que l'utilisation de différentes méthodes d'amélioration de la qualité augmentera le coût du développement de logiciels. Cela peut être vrai à court terme (jusqu'à ce que le processus de consommation soit stabilisé) ou avec une utilisation analphabète de méthodes. À long terme, l'application intégrée des méthodes d'amélioration de la qualité n'augmente non seulement pas le coût du développement, mais il est peut-être nécessaire de le réduire. Voyons, au détriment de ce qui se passe.

Tout d'abord, comme mentionné ci-dessus, le défaut précédent a été trouvé, la correction moins chère la coûte. Par conséquent, l'application effective des méthodes de recherche précoce des défauts contribue à une diminution du coût du projet.

Deuxièmement, les méthodes de recherche de défauts, discutées ci-dessus, en plus de l'efficacité, également par la vitesse moyenne des défauts. Selon des données statistiques, par exemple, cet indicateur pour les méthodes de test est plus pire que dans les méthodes de recherche rapide des défauts. Cela signifie que passer du temps sur la recherche de défauts au début des phases, nous économisons plus de temps sur les tests à venir.

S. McConnell soutient que "l'amélioration de la qualité du système réduit le coût de son développement, car "L'élimination des défauts (étapes tardives) est en fait la mise en scène la plus coûteuse et la plus longue du développement du logiciel."

Processus de gestion de la qualité
Pour la gestion de la qualité ne suffit pas simple usage diverses méthodes de son augmentation. Il est nécessaire que leur application systématique consciente, ce qui ferait partie intégrante du processus de développement de logiciels axé sur la qualité.

Le contrôle de la qualité permanente de la qualité de la qualité développée par des métriques est nécessaire, ainsi que le contrôle de la qualité des sous-processus individuels constituant un processus de développement holistique.

Des méthodes qui fonctionnaient bien hier aujourd'hui peuvent être un temps de dépense vide. Chaque projet peut avoir sa propre spécificité, nécessitant un autre ensemble de méthodes d'amélioration de la qualité. Si vous ne contrôlez pas constamment l'efficacité des méthodes, alors au fil du temps, il peut se détériorer de manière significative.

La gestion de la qualité est également une recherche constante des méthodes d'amélioration du processus de développement afin de réduire le nombre de défauts altérés et d'accroître l'efficacité des méthodes de recherche de défaut.

Conclusion
Résumons la précédente. La qualité des logiciels est déterminée principalement par le processus de développement de ce logiciel. Seul un processus d'axe de la qualité stable mature est capable de créer des produits logiciels avec des niveaux de qualité contrôlée prévisibles. Un tel processus devrait s'appuyer sur les principes de base du logiciel de gestion de la qualité:

une recherche constante et une correction des défauts tout au long du cycle de vie de développement, à partir des premières étapes;

application systématique des méthodes de prévention des défauts;

contrôle de la qualité constant du PP développé et du processus de développement;

amélioration constante du processus de développement afin d'améliorer la qualité.

Littérature

1. Humphrey, Watts S., une discipline de génie logiciel, ISBN 0-201-54610-8. Copyright 1995 par Addison-Wesley.
2. Macconnell S., code parfait. Classe de maître / voie. de l'anglais -M .: Publishing and Trading House "Russian Edition"; SPB: Peter, 2005.
3. Humphrey, Watts S., Introduction au processus logiciel de l'équipe, ISBN 0-201-47719-X. Copyright 2005 par Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: Processus d'auto-amélioration pour les ingénieurs logiciels, ISBN 0-321-30549-3. Copyright 2005 Pearson Education, Inc.
5. Ambler S., Technologies flexibles: Programmation extrême et processus de développement unifié. Programmeur de bibliothèque. Par. de l'anglais -Sp .: Peter, 2005.
6. Roll P., brièvement F., le processus rationnel unifié est facile. Manuel de la RP pour les praticiens. Par. de l'anglais -M .: Kudice-image, 2004.
7. Torres R. J., Guide pratique sur la conception et le développement de l'interface utilisateur. Par avec l'anglais. -M .: Maison d'édition "Williams", 2002.
8. Bobrovsky S., ingénierie logicielle. Technologie Pentagone au service des programmeurs russes. -Sp .: Peter, 2003.
9. Hunt E., Thomas D., Pragmatics de programmeur. Le chemin de l'apprenti au maître. Par. de l'anglais -M.: Lori Publisher, 2004.
10. Fowler M., refactoring: Améliorer le code existant. Par. de l'anglais -Pb.: Symbol-plus, 2005.
11. Beck K., Programmation extrême. Par. de l'anglais -Sp .: Peter, 2002.
12. Beck K., Programmation extrême: développement au moyen de tests. Programmeur de bibliothèque. Par. de l'anglais -Sp .: Peter, 2003.
13. GOST R ISO 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Royce Walker, gestion du processus de création de logiciels. Par. de l'anglais -M.: Lori Publisher, 2007.
15. Tian, \u200b\u200bJeff, Génie de qualité logicielle, ISBN 0-471-71345-7. Copyright 2005 par la société informatique IEEE.

Qualité logicielle C'est un objet permanent de préoccupation pour l'ingénierie logicielle et est discuté dans de nombreux domaines de la connaissance.

Phil Crosby: La qualité est la conformité aux exigences de l'utilisateur.
Wats Hempoffrey: La qualité est la réalisation d'un grand niveau d'aptitude à utiliser.
IBM Société: Introduit par la phrase "la qualité gérée par les besoins du marché (qualité axée sur le marché).
Critère de Belfrian: "Qualité de qualité axée sur le client."
Système de gestion de la qualité ISO 9001: La qualité est le degré de conformité avec les caractéristiques des exigences.

Qualité acceptable - Il s'agit du degré de perfection souhaité du produit créé (services), capable de satisfaire les utilisateurs et de réaliser dans le cadre des restrictions de conception spécifiées.

Qualité dans les activités du projet:

Gestion des exigences ("attributs de qualité" en tant que catégorie d'exigences non fonctionnelles);
Tests (appelé. Travailler sur l'échec, ces métriques telles que le MTTF - temps moyenne à l'échec, c'est-à-dire la durée moyenne entre les défaillances du système détectées, etc.).

"Qualité acceptable" Vous pouvez comparer avec le niveau de service dans le contrat de niveau SLA-Service spécifié. C'est-à-dire que la qualité acceptable peut être considérée comme<количественно выраженный> Compromis entre le client et l'artiste interprète concernant les caractéristiques du produit créé par l'entrepreneur dans les intérêts<решения задач> Client, en tenant compte des autres restrictions de projet (en particulier, le coût, qui est souvent appelé «coût de la qualité» - «coût de la qualité»).

Figure "Zone de connaissances - Logiciel de qualité"

Figure "Modèle du système de gestion de la qualité"

Fondamentaux de qualité logicielle (fondamentaux de la qualité de logiciels)

Consentement réalisé en fonction des exigences de qualité (dans les exigences de qualité d'origine), sur un pied d'égalité avec des ingénieurs, quelle est la qualité<получаемого продукта>, exiger une discussion et une définition formelle de nombreux aspects de la qualité.

Les ingénieurs doivent comprendre la signification dans le concept de qualité, caractéristiques et qualité de la qualité par rapport au logiciel développé ou accompagné.

Une idée importante est que les exigences logicielles déterminent les caractéristiques requises de la qualité du logiciel et affectent également les méthodes d'évaluation quantitative et formulées pour évaluer ces caractéristiques.<соответствующие> Critères d'acceptation.

Culture et éthique de l'ingénierie logicielle (culture de l'ingénierie logicielle et éthique)

Les ingénieurs logiciels devraient percevoir la qualité du logiciel dans le cadre de leur<профессиональной> Culture.
Les aspects éthiques peuvent jouer un rôle important dans la qualité des logiciels, de la culture et des ingénieurs connexes.<к своей работе>. IEEE Computer Society et ACM ont mis au point le code d'éthique («Code moral» - code d'éthique) et pratique professionnelle basé sur huit principes qui aident les ingénieurs renforcer leur relation à la qualité et à l'indépendance.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов> Dans leur travail quotidien.

Signification et valeur de qualité (valeur et coûts de la qualité)

Le concept de "qualité", en fait n'est pas si évident et simplement comme il peut sembler à première vue. Pour tout produit d'ingénierie, il y a beaucoup de<интерпретаций> Qualité, en fonction du "système de coordonnées" spécifique. Beaucoup de ces points de vue doivent être discutés et déterminés au stade de l'élaboration d'exigences pour le produit logiciel. Les caractéristiques de la qualité peuvent être nécessaires à un degré, peuvent être absentes ou peuvent spécifier certaines exigences, tout cela peut être le résultat d'un certain compromis.

La qualité de la qualité (coût de la qualité) peut être différenciée sur:

coût d'avertissement<дефектов> Coût de prévention)
coûts d'évaluation (coût d'évaluation),
le coût des défaillances internes (coût d'échec interne),
le coût des défaillances externes (coût d'échec externe).

Projets d'alimentation de conduite C'est un désir de créer des logiciels avec une valeur spécifique. La valeur du logiciel peut être exprimée sous forme de valeur, et peut-être pas. Le client, généralement, a sa propre idée des investissements maximaux de coûts, dont le retour est attendu en cas d'objectifs principaux de la création de logiciels. Le client peut également avoir certaines attentes concernant les logiciels de qualité. Parfois, les clients ne pensent pas aux problèmes de qualité et aux coûts connexes. Les caractéristiques de qualité sont-elles purement décoratives ou, toutefois, fait-elle partie intégrante du logiciel? La réponse est probablement quelque part au milieu, comme cela se produit presque toujours dans de tels cas et fait l'objet de discussions sur le degré de participation du client dans le processus de prise de décision et une compréhension complète du client des coûts et des avantages associés à la réalisation de un ou un autre niveau de qualité. Dans le cas idéal, la plupart de ce type de solutions devraient être faites pour travailler avec les exigences, mais ces problèmes peuvent augmenter tout au long de l'ensemble du cycle de vie logiciel. Il n'y a pas d'autre<“стандартных”> Règles de la manière dont il est nécessaire de prendre de telles décisions. Cependant, les ingénieurs devraient pouvoir soumettre différentes alternatives et leurs coûts.

Modèles et caractéristiques de la qualité)

ISO / IEC définit des modèles de qualité logicielle à trois liés (ISO 9126-01 Génie logiciel - Qualité des produits, Partie 1: Modèle de qualité):

qualité interne
qualité externe I.
qualité pendant le fonctionnement, ainsi qu'un ensemble d'évaluation de la qualité logicielle appropriée (évaluation du logiciel ISO14598-98).

Qualité du processus logiciel (qualité du processus d'ingénierie logicielle)

Gestion de la qualité (gestion de logiciels) et processus d'ingénierie logicielle de qualité (qualité du processus d'ingénierie logicielle) Ils sont directement liés à la qualité du logiciel créé.

Il existe deux normes les plus importantes dans le domaine de la qualité du logiciel.

Tickit. - Il s'agit de la prise en compte du système de gestion de la qualité générale ISO 9001-00 dans la demande de programmes de programme.
Autre standard important - CMMIDiscuté dans le domaine de la connaissance du processus d'ingénierie du programme, fournit des recommandations pour améliorer le processus. Directement avec la gestion de la qualité, les zones de processus (zone de compétence) CMMI sont associées:
- fournir la qualité du processus et du produit et de l'assurance qualité du processus et de la qualité des produits, des processus "Support" CMMI),
- vérification (vérification, catégorie "ingénierie") et
- certification (validation, catégorie "ingénierie").

Dans le même temps, l'IMMI classe révision (examen) et audit (audit) Comme méthodes de vérification, mais pas en tant que processus indépendants.

Ces normes sont toujours considérées à la fois complémentaires et que la certification ISO 9001 contribue à la réalisation des niveaux de maturité supérieurs par le CMMI.

Qualité de qualité du produit logiciel

Tout d'abord, les ingénieurs devraient déterminer objectifs de création de logiciels. Dans ce contexte, il est particulièrement important de rappeler que les exigences du client sont primordiales et contiennent des exigences de qualité et non seulement fonctionnalités (exigences fonctionnelles). Ainsi, les ingénieurs sont responsables de l'extraction des exigences de qualité qui ne sont pas toujours représentées clairement, ainsi que la discussion sur leur importance et le degré de complexité de leur réalisation. Tous les processus associés à la qualité (par exemple, l'assemblage, la vérification et l'amélioration de la qualité) doivent être conçus pour être conçus pour répondre à ces exigences et porter la gravité des coûts supplémentaires (en tant que composant important du coût du logiciel).

Standard ISO 9126-01 (Ingénierie logicielle - Qualité du produit, Partie 1: Modèle de qualité) Détermine pour deux des trois modèles décrits dans celui-ci, caractéristiques connexes et «sous-caractéristiques» de la qualité, ainsi que des mesures, utiles pour évaluer la qualité des logiciels.

Comprendre le terme "produit" est élargi par l'inclusion de tous les artefacts créés à la sortie de tous les processus utilisés pour créer un produit logiciel fini. Des exemples du produit sont (mais ne sont pas limités à):

spécification complète configuration requise (Spécification des exigences du système)
spécification des exigences logicielles pour les composants logiciels système (spécification de configuration logicielle, SRS),
des modèles
documentation de test
rapports créés à la suite d'un travail d'analyse de la qualité.

Bien que, le plus souvent, la qualité de la qualité est utilisée par rapport au produit final et au comportement du système pendant le fonctionnement, la bonne pratique d'ingénierie consiste à garantir que la conformité des caractéristiques de la qualité spécifiées a été évaluée pour les résultats intermédiaires / produits du cycle de vie de tous. Processus d'ingénierie logicielle.

Amelioration de la qualite

La qualité du logiciel peut augmenter en raison du processus itératif d'amélioration continue. Cela nécessite un contrôle, une coordination et une rétroaction dans le processus de gestion de nombreux processus simultanément effectués:

processus de cycle de vie,
détection de processus, élimination et prévention des échecs / défauts et
processus d'amélioration de la qualité.

Ingénierie logicielle Théories et concepts applicables, amélioration de la qualité sous-jacente. Par exemple, la prévention et les diagnostics d'erreur anticipée, amélioration continue (amélioration continue) et attention aux exigences des clients (mise au point de la clientèle) constituant le principe de «bâtiment en qualité». Ces concepts sont basés sur le travail d'experts sur la qualité qui conviendrait à la conviction que la qualité du produit est directement liée à la qualité des processus utilisés pour la créer.

Approches telles que Tqm. (Gestion de la qualité totale - Gestion de la qualité universelle) et PDCA. (Plan, faire, vérifier, agir - planifier, action, chèque, réaction / ajustement), sont des outils pour atteindre des tâches de qualité. La prise en charge de la gestion aide à effectuer des processus, l'évaluation des produits et l'obtention de toutes les données nécessaires. En outre, le programme d'amélioration est généralement la cible et englobe les travaux de l'unité ou de l'organisation, dans son ensemble), il identifie en détail toutes les actions et projets à améliorer<отдельных аспектов деятельности> Dans le cadre d'une certaine période de temps, pour lequel de tels projets peuvent être mis en œuvre avec la solution réussie des tâches pertinentes. Dans le même temps, le soutien de la direction signifie que tous les projets d'amélioration ont des ressources suffisantes pour atteindre leurs objectifs. L'appui de la direction est étroitement lié à la mise en œuvre de l'interaction active dans l'équipe et devrait empêcher l'émergence de problèmes potentiels (et passifs et même opposés à la mise en œuvre du programme d'amélioration ou de projets individuels). La formation de groupes de travail, la prise en charge des gestionnaires de niveau moyen et des ressources allouées au niveau du projet - ces questions sont discutées dans le domaine de la connaissance "Processus de génie du logiciel".

Processus de gestion de la qualité logicielle (processus de qualité logicielle)

Gestion de la qualité logicielle (SQM, gestion de la qualité des logiciels) Il s'applique à tous les aspects des processus, des produits et des ressources. SQM définit les processus, les propriétaires de processus, ainsi que les exigences pour les processus, la mesure des processus et leurs résultats, ainsi que des canaux de retour d'information.

Les processus de gestion de la qualité contiennent de nombreuses actions. Certains d'entre eux vous permettent de trouver directement des défauts, tandis que d'autres aident à déterminer où il peut être important de mener des recherches plus détaillées, après quoi, encore une fois, le travail est effectué sur la détection directe des erreurs. De nombreuses actions peuvent également être conservées afin de réaliser à la fois d'autres objectifs.

La planification de la qualité logicielle comprend:

Détermination du produit souhaité en termes de caractéristiques de la qualité.
Processus de planification pour obtenir le produit souhaité.

Ces processus diffèrent des processus SQM, en tant que tels, ce qui, à son tour, vise à évaluer les caractéristiques de la qualité prévues et non sur la réelle mise en œuvre de ces plans. Les processus de gestion de la qualité doivent être adressés à des problèmes dans la manière dont le produit répondra aux besoins du client et des exigences des parties intéressées, de la valeur du client et des parties prenantes et la qualité nécessaire au respect des exigences logicielles formulées.

SQM peut être utilisé pour évaluer et les produits finis et intermédiaires. Certains processus spécialisés SQM sont définis dans la norme 12207:

Processus d'assurance qualité (processus d'assurance de la qualité);
Processus de vérification (procédure de vérification);
Processus de certification (processus de validation);
Processus d'analyse conjoint (processus d'examen conjoint);
Processus d'audit (processus d'audit).

Tous ces processus soutiennent le désir d'atteindre la qualité et, d'ailleurs, de trouver erreurs possibles. Cependant, ils diffèrent dans ce qui se concentre sur.

Les processus SQM sont constitués de tâches et de techniques, Conçu pour évaluer la mise en œuvre de la manière dont les plans de création de logiciels et la manière dont les produits intermédiaires et finaux sont conformes aux exigences spécifiées. Les résultats de ces tâches sont soumis en tant que rapports pour les gestionnaires avant que des actions correctives appropriées soient prises. Le contrôle des processus SQM repose sur la confiance que les données du rapport sont exactes.
Comme décrit dans ce domaine de connaissances, les processus SQM sont étroitement liés les uns aux autres. Ils peuvent se chevaucher et parfois même se combinent. Ils semblent de nature réactive, en raison du fait qu'ils considèrent les processus dans le contexte de la pratique acquise et les produits déjà produits. Toutefois, ils jouent un rôle majeur à la phase de planification, étant proactifs en tant que processus et procédures nécessaires pour obtenir des caractéristiques et des niveaux de qualité à la demande des parties intéressées.<проекта> Logiciel.

La gestion des risques peut également jouer un rôle important pour la libération de logiciels de haute qualité. Inclusion de "régulier" (comme permanente plutôt que périodique; dans l'analyse de risque initiale - disciplinée) et<соответствующих> Gestion des techniciens<рисками> Les processus de cycle de vie logiciel peuvent augmenter le potentiel de production de produits de haute qualité. Suite des informations détaillées La gestion des risques peut être trouvée dans le domaine de la connaissance "Gestion de l'ingénierie logicielle".

Confirmation de la qualité logicielle (assurance qualité logicielle, sqa)

Processus SQA Fournir une confirmation selon laquelle les produits logiciels et les processus de cycle de vie du projet répondent aux exigences spécifiées. Cette confirmation est effectuée sur la base de la planification (planification), de la définition<работ> (Encurrence) et exécution (exécution) action définie pour s'assurer que la qualité fait partie intégrante du logiciel.
Une telle vision implique une formulation claire et précise du problème, ainsi que de ce qui est défini et clairement prononcé aux exigences complètes et interprétées de manière appropriée.<программному> solutions. SQA atteignit l'assurance de la qualité dans le processus de développement et de maintenance en effectuant diverses actions à toutes les étapes.<жизненного цикла>Cela vous permet d'identifier toujours les problèmes au début des premiers stades, qui sont pratiquement inévitables dans une activité complexe.

Gestion des risques (gestion des risques) C'est un outil supplémentaire grave pour assurer la qualité du logiciel.

SQA, comme est formulé par Swebok, concentré sur les processus. Le rôle du SQA est de fournir une planification appropriée des processus, une nouvelle exécution des processus fondés sur un plan spécifié et la mise en œuvre des mesures nécessaires des processus avec la transmission des résultats de mesure aux parties prenantes (structures organisationnelles et personnes).

Plan SQA Définit les fonds à utiliser pour s'assurer que le produit développé spécifié par les exigences de l'utilisateur avec le niveau de qualité maximal est possible avec les restrictions de projet spécifiées.

Pour y parvenir, il est d'abord nécessaire que la qualité de la qualité soit clairement définie et comprise (ainsi qu'une interprétation unique, qui est une condition préalable à des exigences et aux exigences pertinentes). Ceci, nécessairement, devrait être reflété dans les plans de gestion respectifs<проектом>, développement et maintenance.

Des travaux spécifiques et des tâches d'assurance qualité sont structurées avec les détails des exigences de leurs coûts et de leurs ressources associées, des objectifs en termes de gestion et de l'horaire correspondant dans le contexte des objectifs spécifiés par les plans de gestion, le développement et la maintenance. Le plan SQA identifie des documents, des normes, des pratiques et des accords appliqués dans le contrôle du projet, ainsi que de la manière dont ces aspects seront vérifiés et surveillés pour assurer la suffisance et le respect du plan spécifié.
SQA-Plan identifie les métriques, les techniques statistiques, les procédures de formation de rapports sur les problèmes et la conduite des actions correctives, tels que des instruments, des techniques et des méthodologies, la sécurité des médias physiques, des formations, ainsi que des rapports et des documentations liés aux problèmes de la SQA.

En outre, les préoccupations du plan SQA et des travaux d'assurance qualité liés à d'autres types d'activités décrites dans<различных> Les plans de création de logiciels auxquels incluent les solutions logicielles d'approvisionnement, d'installation, de fabriquées et / ou de réplicables / réplicables / prêtes à l'emploi (commerce commerciales hors tension, COTS) requises pour ce projet logiciel. Le plan SQA peut contenir l'assurance de la qualité de l'acceptation et de la signification des logiciels et de la gestion.<и контролю над> Travaux.

Vérification (vérification) et certification (vérification et validation, V & V)

Vérification et certification du logiciel - une approche ordonnée dans l'évaluation des produits logiciels utilisés tout au long du cycle de vie. Les efforts déployés dans le cadre des travaux sur la vérification et la certification visent à fournir une qualité en tant que caractéristiques logicielles intégrales et exigences personnalisées.
Le V & V traite directement de la qualité du logiciel et utilise les techniques de test appropriées pour détecter certains défauts. V & V peut être utilisé pour les produits intermédiaires, cependant, en volume correspondant aux «étapes» intermédiaires.<соответствующих> Processus de cycle de vie.

Le processus V & V détermine dans quelle mesure le produit (résultat) de certains travaux sur le développement et la maintenance répond aux exigences formulées dans le cadre de ces travaux et le produit final satisfait aux objectifs et aux besoins de l'utilisateur spécifiés.

Vérification - tenter d'assurer un développement de produits approprié (le produit est construit de la bonne manière; généralement, pour intermédiaire, parfois, pour le produit final), dans la valeur que le produit obtenu dans le cadre de l'activité correspondante est conforme aux spécifications spécifiées dans le processus d'activités précédentes.
Certification - tenter d'assurer la création du bon produit (le bon produit est construit; typiquement, dans le contexte du produit final), en termes d'atteindre l'objectif.

Processus - Vérification et certification - Commencez aux premiers stades du développement et de la maintenance. Ils fournissent des recherches (examen) Capacité de produit clé comme dans le contexte des résultats précédents (produits intermédiaires) et de satisfaire les spécifications pertinentes. Le but de la planification V & V est de garantir des processus de vérification et de certification avec les ressources nécessaires, une nomination claire des rôles et des responsabilités. Le plan V & V obtenu Docommens et<детально> Décrit diverses ressources, rôles et actions, ainsi que des techniques et des outils utilisés.
Le plan concerne également des aspects de la gestion, des communications (interaction), des politiques et des procédures d'actions de vérification et de certification et leur interaction. En outre, il peut refléter des problèmes de formation de rapports sur les défauts et les exigences de documentation.

Évaluation (examen) et audit (examen et audits)

Cinq types de notations et d'audits:

Avis de gestion (Avis de gestion)
Évaluations techniques (examens techniques)
Inspections (inspections)
"PARTITIONS)
Audis (audits)

Avis de gestion (Avis de gestion)

La nomination des évaluations de la direction est de suivre le développement<проекта/продукта>, identifiant l'état des plans et des calendriers, de l'approbation des exigences et de la distribution des ressources, ou d'évaluer l'efficacité des approches de gestion utilisées pour atteindre les objectifs.

Les estimations de la direction Soutien à la prise de décision en matière de modification et d'exécution des actions correctives nécessaires au processus de mise en œuvre d'un projet de programme.

Les estimations de la direction déterminent l'adéquation des plans, des calendriers et des exigences, en même temps contrôlant leurs progrès ou leur incohérence. Ces estimations peuvent être effectuées sur le produit, enregistrées sous forme de rapports d'audit, de rapports de situation (développement), de V & V-Rapports, ainsi que de divers types de plans - gestion des risques de projet / gestion de projet, gestion de la configuration, sécurité<использования> Logiciel (sécurité), évaluations des risques, etc.

Évaluations techniques (examens techniques)

La nomination des évaluations techniques est une étude d'un produit logiciel pour déterminer son aptitude à être utilisé à des fins appropriées. L'objectif est d'identifier des divergences avec des spécifications et des normes approuvées. Pour assurer des évaluations techniques, il est nécessaire de distribuer les rôles suivants: la personne du décideur; Chef d'évaluation (dirigeant d'examen); Registraire (enregistreur); ainsi que le personnel technique soutenant (directement exécutant) des actions d'évaluation.

L'évaluation technique nécessite, sans faute, la présence des données d'entrée suivantes:

Formulations d'objectifs
Produit logiciel spécifique (estimé)
Un plan de projet spécifié (plan de gestion de projet)
Liste des problèmes (questions) associés au produit
Procédures d'évaluation technique

Équipe<технической оценки> Il suit la procédure d'évaluation spécifiée. Qualifié (du point de vue technique) Les personnes représentent une vue d'ensemble du produit (représentant l'équipe de développement). Étude<продукта> Il est tenu lors d'une et de plusieurs réunions (entre ceux qui représentent le produit et ceux qui évaluent l'évaluation). L'évaluation technique est terminée après la réalisation de toutes les actions prescrites pour la recherche sur les produits.

Inspections (inspections)

L'affectation d'inspections consiste à détecter et à identifier des anomalies dans le logiciel. Il existe deux différences graves dans les inspections des estimations (gestion et technique):

Les personnes engagées dans des postes de gestion (gestionnaires) par rapport à tous les membres de l'équipe d'inspection ne doivent pas participer à des inspections.
L'inspection devrait être effectuée sous la direction d'un oliaxé (indépendant du projet et de ses objectifs) du leader formé à l'inspection des techniques.

L'inspection du logiciel implique toujours les auteurs du produit intermédiaire ou final, contrairement aux estimations qui ne nécessitent pas cela obligatoire. Inspection (comme des unités organisationnelles temporaires - groupes, équipes) incluent leader, le registraire, le réviseur et plusieurs (de 2 à 5) inspecteurs. Les membres de l'équipe d'inspection peuvent se spécialiser dans divers domaines d'expertise (posséder divers domaines de compétence), par exemple la zone, les méthodes de conception, la langue, etc. À un moment donné (intervalle), le temps d'inspection est effectué par rapport à un petit fragment séparé du produit (dans la plupart des cas, axé sur des caractéristiques fonctionnelles ou autres distinctes; souvent, en poussant des règles d'entreprise individuelles, des exigences fonctionnelles ou une qualité Attributs, env. Auteur). Chaque membre de l'équipe devrait explorer le produit logiciel et les autres entrées à la réunion d'inspection, à appliquer, peut-être certaines techniques d'analyse dans de petits fragments ou produits de produit, en général, en considérant dans ce dernier cas, par exemple, des interfaces. Toute anomalie trouvée doit être documentée et les informations sont transmises au leader de l'inspection. En cours d'inspection, le leader gère la session<инспекции> et vérifie que tous<члены команды> préparé pour inspection.

L'outil général utilisé en inspection est la liste de contrôle (liste de contrôle) contenant des anomalies et des aspects.<программного продукта>Causé d'intérêt. La feuille résultante classe souvent des anomalies et est estimée à l'équipe du point de vue de son achèvement et de sa précision. La décision sur l'achèvement de l'inspection est effectuée conformément à un (tout) de trois critères:

Adoption<продукта> Avec le manque de petite nécessité
Adoption<продукта> avec vérification de fragments recyclés
Besoin de ré-inspecter

Les réunions d'inspection occupent, généralement, plusieurs heures, contrairement à l'évaluation technique et audit, maintien, dans la plupart des cas, plus de travail et, en conséquence, durables.

Courses (travaux)

Le but du battement est d'évaluer le produit logiciel. Le rythme peut être effectué afin de se familiariser (apprendre) au public avec un produit logiciel.

Les objectifs principaux du rang sont les suivants:

Rechercher Anomalia
Améliorer le produit
Discussion des moyens alternatifs de mettre en œuvre
Évaluation du respect des normes et des spécifications

Le classement est similaire à celui de l'inspection, cependant, est généralement effectué moins formellement. Fondamentalement, le battement est organisé par des ingénieurs pour les autres membres de l'équipe afin de recevoir une réponse de leur part à leur travail, comme l'un des éléments (techniques) de l'assurance de la qualité.

Vérifications (audits)

Nomination d'audit logiciel Il s'agit d'une évaluation indépendante des produits logiciels et des processus liés au respect des documents réglementaires applicables, des normes, des lignes directrices, des plans et des procédures.

L'audit est une activité officiellement organisée, dont les participants effectuent certains rôles, tels que l'auditeur principal (un autre auditeur), l'enregistreur (enregistreur) et l'initiateur (initiateur). L'audit est assisté par un représentant de l'organisation estimée / unité organisationnelle. À la suite de l'audit, les cas d'incohérences sont identifiés et un rapport requis par la commande<разработки> Pour adopter des actions correctives.

Le fait qu'il existe divers noms formels (et classifications) des estimations et d'audit, il est important de noter que ce type d'action peut être effectué pour presque tout produit à n'importe quel stade du processus de développement ou de maintenance.

Considérations pratiques (considérations pratiques)

Exigences de qualité logicielles (exigences de qualité logicielle)

Facteurs d'influence (facteurs d'influence)

La planification, la gestion et la sélection d'actions et de techniques de SQM affectent divers facteurs, notamment:

Portée du système dans lequel le logiciel fonctionnera (critique pour la sécurité<людей>), Critique pour les affaires, etc.)
Configuration système système et logiciels
Quels composants sont utilisés dans le système - commercial (externe) ou standard (interne)
Quelles normes d'ingénierie logicielle sont applicables dans un contexte donné
Quelles sont les méthodes et les outils logiciels utilisés pour le développement et la maintenance, ainsi que pour assurer la qualité et l'amélioration (produits et processus)
Budget, personnel, organisation des activités de projet, plans et annexes pour tous les processus
Qui est les utilisateurs cibles et quel est le but du système
Niveau d'intégrité du système

Les informations sur ces facteurs influent sur la manière dont les processus SQM seront organisés et documentés, que les travaux SQM seront sélectionnés (normalisés dans le cadre du projet, de l'équipe, de l'unité d'organisation, de l'organisation), quelles ressources sont nécessaires et quelles sont les restrictions imposées par rapport aux efforts. envoyé sur l'assurance qualité.

FIABILITÉ

Conseils - garantie<высокой> fiabilité, protection contre les échecs.
Dans les cas où la défaillance du système peut entraîner des conséquences extrêmement difficiles (ces systèmes sont parfois appelés des sources de langue anglaise "une confiance élevée" ou "système d'intégrité élevé", en russe, ils utilisent parfois le nom "Système de fiabilité élevé" "," L'accessibilité "et etc.), la garantie générale (cumulative) du système (comme combinaisons de matériel, de logiciels et d'humains) est la principale et la priorité requise, par rapport à la fonctionnalité principale<системы>.

FIABILITÉ Le logiciel comprend des caractéristiques telles que la tolérance à la faute, la sécurité de l'utilisation (sécurité de la sécurité dans le contexte de risque acceptable pour la santé, les entreprises, la propriété, etc.), la sécurité ou la sécurité des informations (sécurité - la protection des informations provenant d'opérations non autorisées, y compris l'accès à la lecture , ainsi que la garantie de la disponibilité d'informations aux utilisateurs autorisés, dans la quantité de droits qui leur sont donnés), ainsi que la commodité et une utilisation facile (convivialité). La fiabilité (fiabilité) est également un critère pouvant être déterminé en termes d'assuration.

Dans la discussion de cette question, une littérature approfondie sur les systèmes de fiabilité accrue joue un rôle important. Dans le même temps, la terminologie provenait du domaine des systèmes mécaniques et électriques traditionnels (y compris n'incluant pas le logiciel) et décrivant les concepts de danger, de risques, d'intégrité des systèmes, etc.

Niveaux d'intégrité des niveaux d'intégrité logicielle de logiciels

Niveau d'intégrité logicielle Déterminé sur la base des conséquences possibles de l'échec du logiciel et de la probabilité d'un tel échec. Lorsque divers aspects de la sécurité (la sécurité des applications et de l'information) sont importants, lors de l'élaboration de plans de travail pour l'identification des centres d'accidents possibles, des techniques d'analyse de danger peuvent être utilisées (dans le contexte de l'utilisation de l'utilisation, de la sécurité) et de l'analyse des menaces (dans la sécurité de l'information. , Sécurité). L'histoire des échecs de systèmes similaires peut également aider à identifier les techniques les plus utiles visant à détecter des échecs et<всесторонней> Évaluations de qualité logicielles.

Avec une prise en compte plus détaillée de l'intégrité du logiciel dans le contexte de projets spécifiques, il est nécessaire de porter une attention particulière (mettant en évidence les ressources pertinentes et la conduite des travaux nécessaires) non seulement des processus SQM (en particulier, formel, y compris la vérification et la certification). , mais aussi des aspects de la gestion de la direction (en termes d'intégrité des critères), la gestion des risques (y compris la planification des risques à la fois au stade de développement et au stade de l'exploitation et de la maintenance du système), la conception (qui, pour améliorer la garantie, implique nécessairement une analyse et vérification des solutions architecturales et technologiques, souvent à la création de projets pilotes, de stands de démonstration, etc.) et des tests (pour assurer une étude approfondie des caractéristiques comportementales du système, y compris avec le Emulation de l'environnement de travail / la configuration, dans laquelle le système doit être utilisé pendant le fonctionnement).

Caractérisation des défauts (caractérisation de défaute)

Les processus SQM fournissent des défauts. La description des caractéristiques des défauts joue le rôle principal dans la compréhension du produit, facilite la correction du processus ou du produit, et informe également les gestionnaires de projets et les clients de l'état (état) du processus ou du produit. Il existe de nombreuses taxonomies (classifications et méthodes de structuration) défauts (échecs). La caractéristique des défauts (anomalies) est également utilisée dans la vérification et les estimations lorsque le chef d'évaluation soumet souvent de discussions aux réunions appropriées une liste d'anomalies formées par des membres de l'équipe d'évaluation.

Contre le fond de l'évolution (et l'émergence de nouvelles) méthodes de conception et de langues, ainsi que de nouveaux technologies logicielles, de nouvelles classes de défauts apparaissent. Cela nécessite d'énormes efforts pour interpréter (et ajuster) les classes de défauts précédemment définies (échecs). Lors du suivi des défauts, l'ingénieur est intéressé non seulement par leur numéro, mais également. La répartition des défauts par types est particulièrement importante pour déterminer les éléments les plus faibles du système, du point de vue des technologies utilisées et des solutions architecturales, ce qui conduit à la nécessité d'une étude approfondie, la création de projets pilotes spécialisés, vérification supplémentaire Concepts (preuve de concept, POC - approche souvent appliquée lors de l'utilisation de nouvelles technologies), attirer des experts tiers, etc. En soi, des informations, sans classement, sont souvent inutiles de détecter les causes des défaillances, car pour déterminer les moyens de résoudre des problèmes, leur regroupement est nécessaire en fonction des types appropriés. La question est de déterminer une telle taxonomie des défauts, qui sera importante pour les ingénieurs et l'organisation dans son ensemble.

SQM fournit une collecte d'informations à toutes les étapes du développement et de la maintenance logicielles. Habituellement, lorsque nous disons "défaut", nous entendons "échec", conformément à la définition soumise ci-dessous. Cependant, diverses cultures et normes peuvent assumer différentes remplissages sémantiques de ces termes.

Les définitions partielles des concepts de ce type se ressemblent comme suit:

Erreur (erreur): "Différence ... entre le résultat correct et le résultat calculé<полученным с использованием программного обеспечения>”
Faute: "Étape incorrecte, processus ou définition de données dans un programme informatique"
Échec (échec): “<Некорректный> Le résultat obtenu à la suite du manque "
Erreur humaine / personnalisée (erreur): "L'action d'une personne qui a conduit à un résultat incorrect"

Lorsque vous discutez de ce sujet, sous défaut (défaut) signifie le résultat de l'échec du logiciel. Les modèles de fiabilité sont construits sur la base de données sur les défaillances recueillies dans le processus de test du logiciel ou de son utilisation. Ces modèles peuvent être utilisés pour prédire les défaillances futures et aider à prendre une décision sur les tests.

Selon les résultats de SQM-Work visant à détecter des défauts, des actions sont effectuées pour supprimer les défauts du produit étudié. Cependant, cela ne se limite pas à cela. Il existe d'autres actions possibles pour obtenir un retour complet sur les résultats de la mise en œuvre des œuvres SQM correspondantes. Parmi eux - Analyse et résumée (résumée)<по обнаруженным несоответствиям/дефектам>Utilisation d'un technicien d'évaluation quantitatif (obtention des métriques) pour améliorer le produit et le processus, suivi des défauts et les éliminer du système (avec contrôle de la direction et technique des actions correctives nécessaires). À son tour, la source d'informations pour améliorer le processus, en particulier, est le processus SQM.

Les données sur les incohérences et les défauts trouvés lors de la mise en œuvre des techniques de la qualité supérieure concernées doivent être fixées pour empêcher leur perte. Pour certaines techniques (par exemple, une évaluation technique, une vérification, une inspection), la présence du greffier (enregistreur) est obligatoire, elle est de fixer de telles informations à la différence sur les questions (y compris celles nécessitant une contrepartie supplémentaire) et des décisions prises. Dans les cas où des outils d'automatisation appropriés sont utilisés, ils peuvent également fournir les informations de sortie nécessaires sur les défauts (par exemple, des statistiques consolidées sur l'état des défauts, des artistes interprètes responsables, etc.). Les données défamicales peuvent être collectées et enregistrées sous forme de modifications des modifications (SCR, Demande de modification du logiciel) et peuvent, par la suite, entrées dans certains types de bases de données (par exemple, pour suivre les statistiques croisées / historiques pour une analyse plus poussée et une amélioration de Les processus), chaque manuel et mode automatiquement du moyen d'analyse approprié (un certain nombre de conceptions modernes et d'outils spécialisés peuvent analyser le code et les modèles en utilisant les métriques appropriées importantes pour assurer la qualité des produits et des processus). Les rapports de défaut sont envoyés au lien de gestion de l'unité d'organisation / organisation ou de la structure (pour l'adoption de décisions pertinentes concernant le projet, le produit, le processus, le personnel, le budget, etc.).

Techniques de gestion de la qualité du logiciel (techniques de gestion de la qualité logicielle)

Les techniques SQM peuvent être distribuées à plusieurs catégories:

statique
techniques nécessitant une utilisation intensive des ressources humaines
analytique
dynamique

Techniques statiques (techniques statiques)

Techniques statiques suggèrent<детальное> Étude (examen) de la documentation de projet, des logiciels et d'autres informations sur le produit logiciel sans son exécution. Ces techniciens peuvent inclure les autres considérés ci-dessous, des actions sur une évaluation «collective» ou une analyse «individuelle», quel que soit le degré d'utilisation des outils d'automatisation.

Techniques d'évaluation collective (techniques de personnes intensives)

La forme de ce type de technicien, y compris l'évaluation et l'audit, peut varier d'assemblées formelles aux réunions informelles ou à une discussion de produit, même sans accéder à son code. Habituellement, ce type de technologie implique une interaction à temps plein d'au moins deux, mais dans la plupart des cas, plus de spécialistes. Dans le même temps, ces réunions peuvent nécessiter une formation préliminaire (presque toujours en ce qui concerne la détermination du contenu des réunions, c'est-à-dire la liste des problèmes subis à la discussion). Pour les ressources utilisées dans de telles techniques, sur un pair avec les artefacts étudiés (produit, documentation, modèles, etc.), il peut exister différents types de listes de contrôle (liste de contrôle) et les résultats des techniques analytiques (décrites ci-dessous) et des travaux de test. Ces techniciens sont considérés, par exemple, dans la norme 12207 lors de la discussion de l'évaluation (examen) et de l'audit (audit).

Techniques analytiques (techniques analytiques)

Les moteurs logiciels appliquent généralement des techniques analytiques. Du point de vue des techniques agiles et des approches, les individus et les interactions suggèrent<непосредственное> Communication et interaction constante des membres de l'équipe.

Parfois, plusieurs ingénieurs utilisent la même technique, mais par rapport à différentes parties du produit. Certaines techniques sont basées sur les spécificités des outils instrumentaux, d'autres - suggèrent des travaux «manuels». Beaucoup peuvent aider à trouver des défauts directement, mais le plus souvent, ils sont utilisés pour soutenir d'autres techniques. Un certain nombre de techniciens comprennent également divers types d'expertise (évaluation) comme élément composite de l'analyse globale de la qualité. Exemples de telles techniques - Analyse de la complexité, analyse de la logique de contrôle (ou contrôle de l'analyse des flux de contrôle de contrôle) et analyse algorithmique (analyse algorithmique).

Chaque type d'analyse a une nomination spécifique et tous types ne sont applicables à aucun projet. Un exemple de technicien de support est une analyse de la complexité utile pour déterminer les fragments de conception d'un système qui ont une complexité trop élevée pour une mise en œuvre, un test ou une maintenance correcte. Le résultat de l'analyse de la complexité peut également être utilisé pour développer des scénarios de test (cas de test). Ces techniques permettant de trouver des défauts, comme une analyse de la logique de contrôle, peuvent également être utilisées dans d'autres cas. Pour les logiciels avec une vaste logique algorithmique, il est extrêmement important d'utiliser des techniques algorithmiques, en particulier dans les cas où l'algorithme incorrect (non sa mise en œuvre, à savoir logique, env. L'auteur) peut conduire à des résultats désastreux (par exemple, le logiciel Avionics, pour lequel Problèmes de sécurité Utilisation - La sécurité joue un rôle crucial).

D'autres types de techniques analytiques plus formels sont appelés méthodes formelles. Ils sont appliqués aux exigences et à la conception des tests (doivent être reconnus que parfois, dans la pratique réelle du développement de logiciels industriels). Vérification de la correction s'applique aux fragments de logiciels critiques (qui, en général, il est peu associé à des méthodes formelles - il s'agit d'un moyen naturel de réaliser une qualité acceptable lors de la minimisation des coûts). Le plus souvent, ils sont utilisés pour vérifier des parties particulièrement importantes des systèmes critiques, par exemple des exigences concomptives.<информационной> Sécurité et fiabilité.

Techniques dynamiques (techniques dynamiques)

Dans le processus de développement et de maintenance de logiciels, vous devez contacter différents types de techniques dynamiques. Fondamentalement, ce sont des techniques de test. Cependant, en tant que technicien dynamique, les techniques de simulation, la vérification des modèles et l'exécution "symbolique" (exécution symbolique supposent souvent l'utilisation de modules "pacificateurs" du point de vue de la logique réalisée, avec une entrée émulée et une sortie lors de la prise en compte. Le scénario général du comportement des systèmes multi-module; parfois dans ce terme est également compris par d'autres techniques, en fonction de la source primaire sélectionnée).

Voir le code (lu) est généralement considéré comme un équipement statique, mais un ingénieur expérimenté peut exécuter le code directement "dans le processus" de sa lecture (par exemple, en utilisant la boîte de dialogue de débogage étape par étape afin de familiariser ou d'évaluer le code de quelqu'un d'autre). Ainsi, cette technique pourrait bien être discutée et aussi dynamique. De telles divergences dans le technicien de classification montrent clairement que, en fonction du rôle d'une personne dans une organisation, cela peut prendre et appliquer les mêmes techniques de différentes manières.

En fonction de l'organisation<ведения> Projet, des travaux de test spécifiques peuvent être effectués lors du développement de systèmes logiciels dans les processus SQA et V & V. En raison du fait que le plan SQM est adressé à des problèmes de test, ce sujet comprend certains commentaires des tests.

Test (test)

Confirmation des processus<качества> décrit dans SQA et V & V<планах>Explorez et évaluez tout produit de sortie (y compris intermédiaire et final) associé à la spécification des exigences logicielles pour:

traçabilité (traçabilité),
cohérence (cohérence),
complétude / exhaustivité (complétude),
exactitude
et exécution directe<требований> PERFORMANCE.

Une telle confirmation couvre également les artefacts de week-end des processus de développement et de maintenance, la collecte, l'analyse et la quantification des résultats. L'activité SQA garantit une garantie que les types de tests correspondants (nécessaires dans le contexte spécifié du projet) sont planifiés, développés et mis en œuvre, et V & V - Développer des plans de test, des stratégies, des scénarios et des procédures<тестирования>.
Les problèmes de test sont discutés en détail dans le domaine des connaissances "tests". Deux types de tests suivent les tâches définies par SQA et V & V, car elles sont responsables de la qualité des données utilisées dans le projet:

Évaluation et test d'outils utilisés dans le projet
Test de la conformité (ou de l'évaluation des tests de test) Composants et produits COTS (COTS - Commercial de The-étagère, produit prêt à l'emploi) à utiliser dans le produit créé.

Parfois, les organisations de V & V indépendantes peuvent nécessiter la possibilité de surveiller le processus de test et, dans certains cas, assurer (ou, plus souvent, document de document / correction) réelle<тестов> Pour leur mise en œuvre conformément aux procédures spécifiées. D'autre part, un appel à V & V peut être fait pour évaluer et tester le test: suffisance de plans et de procédures, de conformité et de précision des résultats.

Un autre type de test, qui est effectué au début de la V & V-Organisation - Test d'une tierce partie (test de tiers). Une telle tierce partie elle-même n'est pas un développeur de produits et, en aucun cas, n'est pas liée au développeur du produit. En outre, la tierce partie est une source indépendante de l'évaluation, généralement accréditée pour la fourniture de pouvoirs pertinents (par exemple, un développeur d'organisation d'une norme, évalué par un expert indépendant et dont les actions sont confirmées par le créateur de la Standard). Le but de ce type de test est de vérifier le produit pour se conformer à un certain ensemble d'exigences (par exemple, pour la sécurité de l'information).

Évaluation quantitative de la qualité du logiciel (mesure de la qualité logicielle)

Les modèles de qualité du produit logiciel incluent souvent des mesures pour déterminer le niveau de chaque caractéristique de qualité inhérente dans le produit.

Si les caractéristiques de qualité sont sélectionnées correctement, ces mesures peuvent supporter la qualité (niveau de qualité) de nombreuses manières. Les métriques peuvent aider à gérer le processus de prise de décision. Les mesures peuvent contribuer à la recherche d'aspects problématiques et d'étranglement dans les processus. Les métriques sont un instrument permettant d'évaluer la qualité de leur travail par les ingénieurs eux-mêmes - à la fois aux fins définies par la SQA et en termes de processus d'amélioration à long terme<достигаемого> Qualité.
Avec une augmentation de la complexité interne, la sophistication des logiciels, des problèmes de qualité vont bien au-delà de la faction de fabrication de faits ou de logiciels. La question est définie - comment bien les objectifs estimés quantitativement sont atteints.

Il y a quelques autres sujets de discussion dont les métriques soutiennent directement les m². Ils comprennent une assistance pour prendre une décision sur le temps des tests. Dans ce contexte, des modèles utiles de fiabilité et de comparaison avec des échantillons sont présentés (références adoptées comme des exemples d'une certaine qualité de référence).

Le coût du processus SQM est l'un des<проблемных> Des questions qui émergent toujours dans le processus de prise de décision sur la manière dont le projet sera organisé (travail de projet). Souvent, les modèles de coûts généraux (génériques) sont utilisés en fonction de la définition du défaut qui est détectée et de la manière dont les efforts doivent être payés pour sa correction par rapport à la situation si le défaut a été trouvé à des étapes antérieures du cycle de vie. Les données du projet peuvent aider à obtenir un modèle de coût plus clair.

Enfin, le SQM rapportant lui-même a informations utiles Non seulement les processus eux-mêmes (impliquant leur état actuel, env. Auteur), mais aussi comment améliorer les processus du cycle de vie.

Bien que des estimations quantitatives (dans ce cas, nous parlons des résultats des évaluations et non du processus de mesure) Les caractéristiques de la qualité peuvent être utiles en elles-mêmes (par exemple, le nombre d'exigences non satisfaites et la proportion de ces exigences) peuvent<эффективно> Les techniques mathématiques et graphiques facilitant l'interprétation des valeurs métriques sont appliquées. Ces techniques sont très naturellement classées, par exemple, comme suit:

Basé sur des méthodes statistiques (par exemple, analyse Pareto, distribution normale, etc.)
Tests statistiques
Analyse des tendances
Prévision (par exemple, modèles de fiabilité)

Les techniques basées sur des méthodes statistiques et des tests statistiques fournissent souvent un "instantané" des domaines les plus problématiques du produit de programme à l'étude (et, par la manière, la même chose est souvent vrai pour les processus). Les graphiques et graphiques résultants aident visuellement les décideurs dans la détermination des aspects sur lesquels des ressources doivent être axées.<проекта>. Les résultats de l'analyse des tendances peuvent démontrer que l'horaire est violé, par exemple, lors du test; Ou que les échecs de certaines classes deviennent de plus en plus fréquents jusqu'à ce que des mesures correctives soient prises pendant le processus de développement. Les techniques de prédiction aident à la planification du temps de test et à prédire des échecs.

Caractéristiques de la qualité du logiciel

Mobilité (portabilité) - un ensemble d'attributs liés à la capacité des logiciels à transférer d'un environnement à un autre.
NOTE - L'environnement environnant peut inclure un environnement organisationnel, technique ou logiciel.

Fiabilité (fiabilité) - Un ensemble d'attributs liés à la capacité logicielle à maintenir votre niveau de qualité de fonctionnement dans les conditions définies pour la période définie.

Remarques:

Les logiciels usés ou vieillis ne se produisent pas. Les restrictions de fiabilité sont manifestées en raison des erreurs dans les exigences, le projet et la mise en œuvre. Les défaillances dues à ces erreurs dépendent de la méthode d'utilisation des logiciels et des versions logicielles précédemment sélectionnées.
Dans la définition de l'ISO 8402 "fiabilité" - "la capacité de l'élément d'exécuter la fonction requise". Dans cette norme, fonctionnelle. La capacité n'est qu'une des caractéristiques de la qualité du logiciel. Par conséquent, la définition de la fiabilité est étendue à «Sauvegarder son niveau de qualité de fonctionnement» au lieu de «exécuter la fonction requise».

Pratique (convivialité) - Un ensemble d'attributs liés au volume des travaux requis pour une utilisation et une évaluation individuelle de cette utilisation par une certaine ou prétendue gamme d'utilisateurs.

Remarques:

Les «utilisateurs» peuvent être interprétés comme des utilisateurs les plus directs de logiciels interactifs. Le cercle des utilisateurs peut inclure des opérateurs, des utilisateurs finaux et des utilisateurs indirects qui influencent ce logiciel ou qui dépendent de son utilisation. La praticité devrait être envisagée dans toute la diversité des conditions de fonctionnement par l'utilisateur qui peut affecter les logiciels, y compris la préparation d'utilisation et l'évaluation des résultats.
Pratique défini dans cette norme En tant que jeu spécifique d'attributs logiciels, diffère de la définition du point de vue de l'ergonomie, où d'autres caractéristiques, telles que l'efficacité et l'inefficacité, sont considérées.

Accessibilité (maintenabilité) - un ensemble d'attributs liés au volume de travail requis pour des modifications spécifiques (modifications).
Remarque - Le changement peut inclure des corrections, des améliorations ou de l'adaptation du logiciel aux modifications des conditions environnementales, des exigences et des conditions de fonctionnement.

Fonctionnalité (fonctionnalité) - un ensemble d'attributs liés à l'essence des fonctions et de leurs propriétés spécifiques. Les fonctions sont celles qui mettent en œuvre les besoins établis ou présumés.

Remarques:

Cet ensemble d'attributs est caractérisé par le fait que le logiciel effectue pour répondre aux besoins, tandis que d'autres ensembles sont principalement caractérisés lorsque et comment il est exécuté.
Cette caractéristique des besoins établis et présumés prend en compte une note pour déterminer la qualité.

Efficacité (efficacité) - Un ensemble d'attributs liés au rapport entre le niveau de qualité du fonctionnement du logiciel et la quantité de ressources utilisées dans les conditions établies.
Remarque - Les ressources peuvent inclure d'autres logiciels, moyens techniques, Matériaux (par exemple, papier d'impression, disques flexibles) et les services du personnel d'exploitation, d'accompagnement ou de service.

Qualité du logiciel

Qualité de qualité logicielle - L'ensemble du volume de fonctionnalités et de caractéristiques des logiciels, qui concerne sa capacité à répondre aux besoins établis ou présumés.

L'importance de chaque caractéristique de la qualité varie en fonction de la classe de logiciels. Par exemple, la fiabilité est la plus importante pour le logiciel de lutte contre les systèmes critiques de combat, l'efficacité est la plus importante pour le logiciel de logiciel critique en temps réel, et la praticité est la plus importante pour la boîte de dialogue de dialogue logiciel.

L'importance de chaque caractéristique de la qualité varie également en fonction des points de vue acceptés.

Présentation de l'utilisateur

Les utilisateurs présentent principalement des intérêts pour l'application de logiciels, de ses performances et de ses résultats d'utilisation. Les utilisateurs ont évalué le logiciel sans étudier ses aspects internes ni comment le logiciel a été créé.

L'utilisateur peut être intéressé par les questions suivantes:

Y a-t-il des fonctions dans des logiciels?
Comment logiciels de fiabilité?
Quelle est l'efficacité du logiciel?
Le logiciel est-il pratique pour une utilisation?
Quelle est la facilité le logiciel et l'autre environnement?

Présentation du développeur

Le processus de création nécessite que l'utilisateur et le développeur utilisent les mêmes caractéristiques de qualité logicielle, telles qu'elles appliquent pour établir des exigences et une acceptation. Lorsque des logiciels sont en cours de développement, les besoins prévus doivent être reflétés dans les exigences de qualité.

Étant donné que les développeurs sont responsables de la création de logiciels, ce qui devrait satisfaire aux exigences de la qualité, ils sont intéressés par des produits intermédiaires ainsi que des produits finis. Afin d'estimer la qualité des produits intermédiaires à chaque phase du cycle de développement, les développeurs doivent utiliser différentes métriques pour les mêmes caractéristiques, car les mêmes mesures ne sont pas applicables à toutes les phases du cycle de vie.

Par exemple, l'utilisateur comprend l'efficacité du temps de réponse, tandis que le développeur utilise les termes de la durée de l'itinéraire et du temps d'attente et du temps d'accès dans la spécification de conception. Les métriques utilisées pour l'interface de produit externe sont remplacées par des métriques appliquées à sa structure.

Représentation de la tête

La tête peut être plus intéressée par une qualité générale que dans une caractéristique de qualité spécifique, et pour cette raison, il faudra déterminer l'importance des valeurs reflétant les exigences commerciales pour les caractéristiques individuelles.
Le superviseur peut également exiger une comparaison de l'amélioration de la qualité avec des critères de manipulation, tels que le retard prévu ou le réservoir de coûts, car il souhaite optimiser la qualité dans un coût limité, des ressources de travail et une durée déterminée.

Évaluation de la qualité logicielle

La figure suivante reflète les étapes principales nécessaires à l'évaluation de la qualité du logiciel.

Figure "Modèle du processus d'évaluation"

Le processus d'évaluation comprend trois étapes: Établissement (définition) Exigences de qualité, préparation à la procédure d'évaluation et d'évaluation. Ce processus peut être utilisé dans toute phase de cycle de vie appropriée pour chaque composant des produits logiciels.
Le but de l'étape initiale est d'établir des exigences en termes de caractéristiques de la qualité. Les exigences expriment les besoins de l'environnement extérieur pour les produits logiciels à l'étude et doivent être définis avant le développement.
Le but de la deuxième étape est de préparer la base de l'estimation.
Le résultat du troisième est la conclusion de la qualité des produits logiciels. La qualité généralement généralisée est comparée à d'autres facteurs, tels que le temps et le coût. La décision finale de la gestion est faite sur la base du critère de la facilité de gestion. Le résultat est la décision du guide d'acceptation ou de rejet, ou sur la libération ou non des produits logiciels.

Processus de qualité du modèle

Le processus de développement devrait être construit de manière à assurer la possibilité de mesurer la qualité du produit. Les études sont présentées: plus la qualité du processus de développement est élevée, plus la qualité de la qualité logicielle est élevée dans ce processus. La qualité à chaque étape du projet augmente, premièrement, comme une conséquence directe de la maturité du processus, d'après l'utilisation d'un produit intermédiaire de la qualité supérieure produite à la phase précédente. Il souligne que la valeur de la deuxième cause d'augmentation de la qualité du processus de cycle de vie des processus matures s'avère beaucoup plus importante. Tout cela peut être représenté comme un modèle donné.

Figure "Modèle conceptuel de processus de développement de la qualité"

De là, débènes les conséquences suivantes:
La première: la qualité s'accumule dans le produit avec une production complexe cumulativement et, une contribution à la qualité réalisée au début des premiers stades, a un effet plus fort sur le produit final que chez les étapes ultérieures. Ceci est confirmé par toutes les pratiques de programmation, par exemple, on sait que les inconvénients de la conception des systèmes ne peuvent pas être compensés par une qualité de codage élevée.
Ainsi, pour gérer la qualité de la construction d'un système complexe, il est nécessaire de choisir les fabricants fondés sur la mesure du degré de maturité et de la transparence des processus de développement développés. La mesure de la qualité du processus de développement des entrepreneurs est une partie importante de la gestion de la qualité globale, plus importante que de mesurer la qualité du produit résultant produit lors des tests d'acceptation.
Deuxièmement: les tests et la mesure de la qualité doivent se produire à toutes les étapes du cycle de vie. L'extraction de données sur la qualité qui a été posée aux premiers stades peut être très coûteuse en l'absence de résultats complets.

Caractéristiques de la qualité

1 Applicabilité

2 idées sur la qualité du logiciel

2.1 Présentation de l'utilisateur
2.2 Présentation du développeur
2.3 Représentation de la tête

3.1 Établissement d'exigences de qualité

3.2 Préparation à l'évaluation

3.2.1 Sélection des métriques (indicateurs) de la qualité
3.2.2 Définition des niveaux de classement
3.2.3 Définition du critère d'évaluation

3.3 Procédure d'estimation

3.3.1 Mesure
3.3.2 Classement
3.3.3 Évaluation

1. Introduction

2 Définition des indicateurs de qualité complets

2.1 Fonctionnalité (fonctionnalité)

2.1.1 Fitness (aptitude)
2.1.2 Garnitude (précision)
2.1.3 Capacité d'interaction (interopérabilité)
2.1.4 Concenciager (conformité)
2.1.5 Sécurité (sécurité)

2.2 Fiabilité (fiabilité)

2.2.1 Stabilité (échéance)
2.2.2 Résistance aux erreurs (tolérance des pannes)
2.2.3 Recuissabilité (récupérabilité)

2.3 Pratique (convivialité)

2.3.1 Compréhensibilité (compréhensibilité)
2.3.2 Helabidité (acquisition)
2.3.3 Utilisation facile (opérabilité)

2.4 Efficacité (efficacité)

2.4.1 caractère du changement dans le temps (comportement temporel)
2.4.2 Caractère de changement de ressources (comportement des ressources)

2.5 Accessibilité (maintenabilité)

2.5.1 Analyseur (analysabilité)
2.5.2 Échantillance (changeabilité)
2.5.3 Stabilité (stabilité)
2.5.4 Testabilité (testabilité)

2.6 Mobilité (portabilité)

2.6.1 Adaptabilité (adaptabilité)
2.6.2 Déploiement facile (installabilité)
2.6.3 Conformité (conformité)
2.6.4 Interchangeabilité (remplaçable)

Remarques:

L'interchangeabilité est utilisée à la place de la compatibilité afin d'éviter toute confusion avec la capacité d'interagir.
L'interchangeabilité avec un moyen logiciel spécifique ne suppose pas que ce moyen est remplacé par les moyens programmatiques.
L'interchangeabilité peut inclure des attributs de simplicité et d'adaptabilité. Le concept a été introduit en tant que préfabriques distincts en raison de son importance.

Qualité du projet

La qualité inclut toutes les activités du projet garantissant la conformité du projet d'aller pour le bien à laquelle il a été pris. Par conséquent, la gestion de la qualité est applicable à la fois au projet et au produit du projet.
La qualité est critique, car elle a exprimé et enregistre les objectifs, les rend documentées (formalisées).
Par conséquent, la qualité est la composante essentielle de la gestion de la structure du projet.
Pour la qualité, tout est mesurable.

Gestion de la qualité du projet

Si la gestion de la qualité est concentrée dans une division de l'organisation, elle ne deviendra pas universelle. Le chef de projet peut déléguer des aspects de la gestion de la qualité. Le chef de projet conserve la responsabilité finale.

Principes de qualité (ISO 9000)

Orientation client
Responsabilité de la gestion
Implication des personnes
Approche de processus
Approche de gestion du système
Amélioration continue
Décision basée sur des faits
Relation mutuellement bénéfique avec les fournisseurs

Figure "Différences dans la compréhension de la gestion de la qualité dans ISO 9000 et PMBOK"

Gestion de la qualité du projet (PMI): Subgrocesses

Planification de la qualité
Assurance qualité
Contrôle de qualité

Planification de la qualité

L'une des étapes est la définition de laquelle les normes existantes concernent ce projet et comment les respecter. Le résultat de la planification de la qualité est une liste de normes de qualité qui s'appliquent au projet. La liste des recommandations est jointe, la manière dont les exigences de ces normes seront remplies.

Processus de planification de la qualité: entrées

Politique de qualité. Un document contenant les principes de la manière dont l'organisation définit la qualité mais ne contenant pas de chemins de qualité.
Contenu du projet (portée). Détermine que cela devrait être fait à la suite du projet et, par conséquent, de quoi suivre les processus de gestion de la qualité. Ce document est la sortie du processus de planification du contenu du projet.
Description du produit. Contient des détails techniques et d'autres aspects importants pouvant affecter la planification de la qualité.
Normes et ordonnances. Liste des normes et des règlements imputables à ce domaine ou à ce projet.
Autres documents.

Processus de planification de la qualité: outils et technologies

Analyse de roulement / coût. Liés à discuter de la valeur de qualité. Le but de cet outil comparait la valeur réelle de l'absence de qualité avec l'avantage de l'assurance de la qualité.
Comparaison. Utilisé pour générer des idées pour améliorer une comparaison avec d'autres projets. Le plus efficace lorsque la comparaison se produit avec le meilleur et non seulement avec d'autres projets internes.
Graphiques. Utilisé pour montrer comment différents éléments interagissent. Il existe de nombreux types de diagrammes, y compris un diagramme de causes et de conséquences.
Expériences de mise en scène. Utilisez les scripts "Quoi, si" pour déterminer quelles variables sont les plus influentes sur le résultat final du projet.
Coût de qualité.

Processus de planification de la qualité: sorties, résultats

Plan de gestion de la qualité. Décrit comment l'équipe de gestion de projet poursuivra des politiques de qualité. Doit affecter les domaines suivants:
Contrôle du design.
Contrôle de la documentation.
Contrôle de l'approvisionnement de matériaux.
Inspection.
Contrôle de test (test).
Contrôle sur le contrôle de contrôle et de mesure.
Mesures correctives.
Records de qualité.
Audits (plan et procédure)
Procédures documentées et instructions de travail. Décrit en détail les processus et comment mesurer la qualité du processus, des sous-processus et des actions individuelles effectuées.
Feuilles de contrôle. Listes de questions pour vérifier que rien n'est manqué.

Assurance qualité

Processus d'assurance qualité - Il s'agit de l'adoption de mesures systématiques prévues garantissant la mise en œuvre de tous les processus nécessaires pour garantir que le projet (produit, service) répond aux exigences de qualité.
L'assurance qualité est la principale sous-processus de gestion de la qualité. Cette activité est effectuée dans tout le projet.

Processus d'assurance qualité: entrées

Instructions de travail. Une autre façon de sortir du processus de planification de la qualité.
Résultats des mesures de contrôle de la qualité. Sortie du processus de contrôle de la qualité.

Processus d'assurance qualité: outils et techniques

Outils de planification de qualité et techniques. Ils comprennent l'analyse des bénéfices et des coûts, des comparaisons, des graphiques, de l'expérimentation et de l'évaluation de la valeur de qualité.

Audits de qualité

"Inspections" structurées, qui confirment "les leçons apprises". Les types d'audit de qualité sont:

interne externe,
système / produit / processus / organisations,
planifié / régulier,
spécial et compliqué.

Processus d'assurance qualité: sorties

Amelioration de la qualite. Comprend une réalisation d'actions pour accroître l'efficacité et la productivité du projet afin d'assurer des avantages supplémentaires aux propriétaires de projets.

Contrôle de qualité

Surveillance Résultats spécifiques afin de déterminer leur conformité aux normes de qualité adoptées et de déterminer les causes des causes causant des performances insatisfaisantes.

Processus de contrôle de la qualité: entrées

Résultats du travail. Les résultats apparaissent toujours dans le processus de coopération, d'exécution et de réaménagement du projet.
Plan de gestion de la qualité. Production de processus de planification de la qualité.
Instructions de travail. Production de processus de planification de la qualité.
Listes de contrôle.

Contrôle de la qualité: outils et techniques

Inspection. Inclure des activités telles que des mesures, des tests, des tests pour vous assurer que le résultat répond aux exigences.
Diagrammes de contrôle. Les diagrammes d'exécution définissent statistiquement les limites supérieure et inférieure réfléchie des deux côtés des valeurs de processus moyennes.
Graphiques: Ishika, Pareto.
Échantillon statistique.
Analyse de tendance.

« Le but d'utiliser des outils - Corrigez les résultats ou les modifications, affichez-les graphiquement et révéler et ajuster davantage les problèmes de manière appropriée. "

Processus de contrôle de la qualité: sorties

Amelioration de la qualite. Quittez le processus d'assurance qualité.
Faire des décisions. Les décisions sont prises en fonction de la question de savoir si un objet interactif est accepté ou rejeté.
Mesures correctives. L'action effectuée pour apporter conformément à l'objet inapproprié.
Listes de contrôle remplies.
Fixer le processus.

Les références

http://sorlik.blogspot.com, Sergey Orlik, 2004-2005
Genthene A. Manuel éducatif et méthodologique pour la discipline "Gestion du développement de la qualité" 2007, Saint-Pétersbourg

L'augmentation rapide de la complexité et de la taille des programmes modernes de programmes, tout en augmentant la responsabilité croissante des fonctions ayant fortement amélioré les exigences des clients et des utilisateurs à leur qualité et à leur sécurité. Les moyens testés d'assurer une efficacité élevée et une qualité du fonctionnement des programmes et des complexes logiciels sont des normes internationales développées avec la participation de représentants de sociétés de premier plan dans l'industrie.

Au fur et à mesure que l'application se développe et augmente la complexité des systèmes d'information, des domaines dans lesquels des erreurs ou une qualité insuffisante de programmes ou de données peuvent endommager, dépassant de manière significative l'effet positif de leur utilisation.

Dans de nombreux cas, des contrats et des plans préliminaires de création de logiciels et de bases de données complexes pour les systèmes d'information sont préparés et évalués non qualifiés, sur la base de soumissions informalisées de clients et de développeurs sur les caractéristiques et caractéristiques requises de la qualité des systèmes d'information. Des erreurs de système significatives pour déterminer les indicateurs de qualité requises, l'évaluation de la complexité, le coût et la durée de la création de logiciels - le phénomène est assez massif. De nombreux systèmes d'information ne sont pas en mesure de remplir les tâches fonctionnelles entièrement requises avec une qualité garantie, et elles ont longtemps et parfois mal à l'aise d'atteindre la qualité et la fiabilité nécessaires de l'opération, de dépenser de plus en plus de moyens et de temps. En conséquence, les systèmes d'information ne correspondent souvent pas au rendez-vous et aux exigences originales, déclarés et aux exigences de caractéristiques de la qualité, ne correspondent pas au budget graphique et de développement.

Dans les tâches techniques et les projets de systèmes d'information mis en œuvre, des informations sur les concepts et les valeurs de la qualité du logiciel ne suffisent pas, quelles sont les caractéristiques auxquelles ils sont décrits de la manière dont ils devraient être mesurés et comparés aux exigences énoncées dans le contrat, technique spécifications ou spécifications. De plus, certaines des caractéristiques sont souvent absentes dans les exigences logicielles, ce qui entraîne une comptabilité arbitraire ou une passe lors du test. Déclaration floue dans les documents des concepts et les valeurs requises des caractéristiques de la qualité du logiciel provoque des conflits entre les clients - les utilisateurs et les développeurs-fournisseurs en raison d'une interprétation différente des mêmes caractéristiques. À cet égard, la tâche stratégique du cycle de vie des systèmes d'information modernes était de garantir la qualité des logiciels et des bases de données.

Au cours des dernières années, de nombreuses normes internationales, réglementant les processus et les produits de cycle de vie du produit et des bases de données ont été créés. L'application de ces normes peut servir de base aux systèmes d'assurance de la qualité des logiciels, mais à l'adaptation, à l'adaptation ou à l'élimination des dispositions de normes relatives aux principales caractéristiques des technologies et des caractéristiques de ce type de produit. Dans le même temps, de nombreux clients ont besoin de respecter la technologie de la conception, de la production et de la qualité des produits avec des normes internationales modernes qui doivent être développées et utilisées pour assurer la compétitivité des produits sur le marché mondial.

Normalisation des caractéristiques de la qualité

L'un des problèmes les plus importants consistant à assurer la qualité des logiciels est de formaliser les caractéristiques de la qualité et la méthodologie de leur évaluation. Pour déterminer l'adéquation de la qualité de fonctionnement, la disponibilité des capacités techniques du logiciel pour interagir, améliorer et développer, il est nécessaire d'utiliser des normes dans le domaine de l'évaluation de leurs caractéristiques de qualité. La base de régulation de la qualité des indicateurs de logiciels était auparavant la norme internationale ISO 9126: 1991 (GOST R ISO / CEI 9126-93) "Technologie de l'information. Évaluation du logiciel. Caractéristiques de la qualité et orientation sur leur utilisation." Le dernier brouillon consistant en quatre parties de la norme ISO 9126-1--4 est achevé et formalisé pour remplacer un petit bureau de rédaction de 1991. Le projet comprend les parties suivantes sous la rubrique générale "Technologies de l'information - caractéristiques et métriques de qualité logicielle": "Partie 1. Spécifications et sous-classeurs" Partie 2. Métriques de qualité externe "" Partie 3. Métriques de qualité interne "" Partie 4. Métriques de qualité utilisées ".

En Russie, un groupe d'invités obsolètes est principalement utilisé en Russie dans le domaine de la fourniture du cycle de vie et de la qualité des complexes complexes, qui traînent derrière le niveau mondial pendant 5 à 10 ans.

La première partie de la norme - ISO 9126-1 - distribue les attributs de la qualité du logiciel à six caractéristiques utilisées dans les autres parties de la norme. Sur la base des principales possibilités de leur mesure, toutes les caractéristiques peuvent être combinées en trois groupes auxquelles différentes catégories de métriques sont applicables:

catégorie ou descriptive (nominale) métrique la plus adéquate des logiciels;
les métriques quantitatives sont applicables pour mesurer la fiabilité et l'efficacité des complexes complexes complexes;
les métriques de haute qualité sont les plus cohérentes avec la praticité, les accompagnations et la mobilité des logiciels.

En termes de norme ISO 9126-1, les définitions sont données avec des éclaircissements de ses autres parties pour chaque caractéristique du logiciel, ainsi que pour le sous-voyant de la qualité.

Au cours des dernières années, de nombreuses normes ISO ont été créées, la réglementation des processus et des produits de cycle de vie de produits et des bases de données pouvant servir de base aux systèmes d'assurance qualité du système.

La deuxième et la troisième partie de la norme - ISO 9126-2 et ISO 9126-3 sont consacrées à la formalisation des métriques respectivement externes et internes des caractéristiques de la qualité du logiciel complexe. Toutes les tables contiennent une réflexion unifiée, où le nom et le but de la métrique sont reflétés; méthode de son utilisation; Méthode de mesure, type d'échelle métrique; type de valeur mesurée; données source pour la mesure et la comparaison; Ainsi que les étapes du cycle de vie logiciel (par ISO 12207), à laquelle la métrique est applicable.

La quatrième partie de la norme est ISO 9126-4 - conçue pour les acheteurs, fournisseurs, développeurs, accompagnant, utilisateurs et gestionnaires de qualité. Il substitue et commente les indicateurs sélectionnés de la sphère (contexte) de l'utilisation de logiciels et de groupes de métriques sélectionnées pour les utilisateurs.

Sélection d'indicateurs de qualité

Les données source et la priorité la plus élevée lors du choix des indicateurs de qualité dans la plupart des cas sont l'affectation, les fonctions et l'adéquation fonctionnelle du logiciel correspondant. Une description assez complète et correcte de ces propriétés doit être la base de la détermination des valeurs de la plupart des autres caractéristiques et attributs de qualité. Les capacités fondamentales et techniques et la précision des valeurs d'attribut de mesure des caractéristiques de la qualité sont toujours limitées conformément à leur contenu. Cela détermine les gammes rationnelles des valeurs de chaque attribut qui peuvent être sélectionnées sur la base de bon sens, ainsi que en analysant les précédents dans les spécifications de projets réels.

Les processus de sélection et d'établissement de métriques et d'échelles pour décrire les caractéristiques de la qualité du logiciel peuvent être divisées en deux étapes:

le choix et la justification de l'ensemble des données source, reflétant les caractéristiques générales et les étapes du cycle de programme du logiciel et de ses consommateurs, chacun affecte certaines caractéristiques de la qualité du complexe de programme;
sélection, établissement et approbation de mesures spécifiques et d'écailles de mesure des caractéristiques et des attributs de qualité de projet pour leur évaluation ultérieure et la comparaison avec les exigences des spécifications dans le processus de qualification des tests de qualification ou de la certification à certaines étapes du cycle de vie logiciel.

À la première étape, la totalité de la nomenclature de base des caractéristiques, des sous-classeurs et des attributs, normalisées dans la norme ISO 9126, doit être prise comme base. Leurs descriptions sont souhaitables à pré-rationaliser les priorités, en tenant compte de la nomination et de la portée de l'application d'un logiciel spécifique. projet. Ensuite, il est nécessaire d'allouer et de se classer par les priorités de consommation, qui nécessitent certains indicateurs de la qualité du projet logiciel, en tenant compte de leur spécialisation et de leurs intérêts professionnels. La préparation des données source est complétée par l'attribution de la valeur de base, des indicateurs de priorité de qualité qui déterminent l'adéquation fonctionnelle du logiciel pour certains consommateurs.

À la deuxième étape, après avoir corrigé les données source, que le consommateur des estimations de la qualité devrait effectuer, les procédures de choix de la nomenclature et des métriques commencent par le classement des caractéristiques et des sous-classeurs pour un projet spécifique et leur consommateur. En outre, ces experts pour chacun des indicateurs sélectionnés doivent également établir une métrique et une échelle d'estimations des sous-classeurs et leurs attributs pour le projet et le consommateur des résultats de l'analyse. Pour les indicateurs présentés par des signes de haute qualité, il est conseillé de déterminer et de résoudre les spécifications des descriptions des conditions dans lesquelles il devrait être considéré que cette fonctionnalité mis en œuvre dans l'outil logiciel. Les valeurs sélectionnées des caractéristiques de la qualité et de leurs attributs doivent être testées par les développeurs à leur réalisation, en tenant compte des ressources disponibles d'un projet spécifique et sont ajustées si nécessaire.

Contrôle de qualité

La méthodologie et la normalisation de l'évaluation des caractéristiques de la qualité du logiciel prêt à l'emploi et de leurs composants (logiciel) à différentes étapes du cycle de vie sont la norme internationale ISO 14598, composée de six parties. Le régime général suivant pour évaluer les caractéristiques de la qualité des programmes est recommandé:

installation des exigences de source pour l'évaluation - Détermination des objectifs de test, identification du type de métrique de logiciel, affectation d'indicateurs adéquats et valeurs requises d'attributs de qualité;
sélection des métriques de qualité, de fixation et de niveaux de priorités métriques SubcrateRais et attributs, sélection de critères d'examen et de mesures;
planifier et concevoir le processus d'évaluation des caractéristiques et des attributs de qualité dans le cycle de vie du logiciel;
mesures de mesure, comparaison des résultats avec des critères et des exigences, une généralisation et une évaluation des résultats.

Pour chaque caractéristique de la qualité, il est recommandé de former des mesures et l'échelle de mesure avec l'attribution des valeurs requises, admissibles et insatisfaisantes. La mise en œuvre des processus d'évaluation doit être corrélée aux étapes du cycle de vie d'un projet logiciel spécifique conformément à la version appliquée et adaptée de l'ISO 12207.

Pertinence fonctionnelle - le plus incertain et objectivement difficile d'évaluer la sous-artacitée du logiciel. Les domaines d'application, la nomenclature et les fonctions des programmes de programmes couvrent une telle activité humaine, qui ne peut être isolée et uniforme un petit nombre d'attributs d'évaluation et de comparaison de ce sous-discratiriste dans divers complexes.

Évaluation de l'exactitude du logiciel Il consiste dans une détermination formelle du degré de conformité du complexe de programmes mis en œuvre aux exigences initiales du contrat, des spécifications techniques et des spécifications du logiciel et de ses composants. En vérifiant, le respect des exigences initiales de la combinaison complète des composants du complexe de programme, jusqu'à des modules et des descriptions de texte et des descriptions de données, doivent être déterminées.

Évaluation de la capacité d'interagir Il est de déterminer la qualité de la collaboration de composants logiciels et de bases de données avec d'autres systèmes d'application et composants sur diverses plates-formes informatiques, ainsi que l'interaction avec les utilisateurs dans le style, pratiques pour passer d'un système informatique à un autre avec des fonctions similaires.

Évaluation de la sécurité logicielle Comprend la détermination de l'exhaustivité de l'utilisation des méthodes disponibles et des moyens de protection du logiciel des menaces potentielles et obtenues lors de cette sécurité du système d'information. Le plus largement et en détail des objectifs méthodologiques et systémiques de la protection intégrée des systèmes d'information sont présentés dans trois parties des méthodes et moyens de la norme ISO 15408: 1999-1--3--3--3 de garantie de sécurité. Critères d'évaluation de la sécurité de informatique."

Évaluation de la fiabilité - Mesure des métriques quantitatives des attributs de sous-classeur utilisés: exhaustivité, résistance des défauts, répartition et disponibilité / disponibilité.

La nécessité de la mémoire et des ressources de performance L'ordinateur dans le processus de résolution de problèmes varie considérablement en fonction de la composition et du volume des données source. Pour déterminer correctement la largeur de bande de limitation du système d'information avec ce logiciel, vous devez mesurer les valeurs extrêmes et moyennes des durées des groupes fonctionnels de programmes et des itinéraires sur lesquels ils sont atteints. Si la pré-dans le processus de conception de la performance de l'ordinateur n'a pas été estimée, alors, plus probablement, vous aurez besoin d'un raffinement important ou même de remplacer l'ordinateur à un plus rapide.

Évaluation de la praticité Les fonds logiciels sont effectués par des experts et inclut la définition de la compréhensibilité, la facilité d'utilisation, l'exploration et l'attractivité du logiciel. Fondamentalement, il s'agit d'un score de haute qualité (et subjectif) en points, cependant, certains attributs peuvent être estimés à quantifier la complexité et la durée des opérations lors de l'utilisation du logiciel, ainsi que du volume de documentation nécessaire pour les étudier.

Accessibilité Il est possible d'évaluer la pleine et la précision de la documentation sur les états du logiciel et de ses composants, toutes les modifications estimées et apportées qui vous permettent de définir l'état actuel des versions de programme à tout moment et à l'historique de leur développement. Il devrait définir la stratégie, les normes, les procédures, l'allocation des ressources et les plans de création, de modification et d'application des documents pour les programmes et les données.

Évaluation de la mobilité - Définition qualitative d'experts en adaptabilité, facilité d'installation, compatibilité et substitutionnabilité des programmes exprimés en points. Vous pouvez quantifier cette caractéristique du logiciel et un ensemble de ses attributs (et appropriés) à évaluer dans les indicateurs économiques: le coût, la politique et la durée de la mise en œuvre des procédures de transfert vers d'autres plates-formes d'un certain ensemble de programmes et de données.

Système de gestion de la qualité

Le choix des caractéristiques et de l'évaluation de la qualité du logiciel n'est qu'une des tâches dans le domaine de l'assurance qualité des produits fabriquée par les entreprises - Développeurs de logiciels. Une solution globale à la qualité des logiciels pour logiciels assume l'évolution et la mise en œuvre d'un système de gestion de la qualité particulier. Dans la pratique mondiale, le système basé sur des normes internationales de la série ISO 9000, qui comprend une douzaine de documents excédentaires, y compris un logiciel d'assurance qualité régissant une norme (ISO 9000/3). Ces normes devraient servir de guidage pour les principaux spécialistes pour commander des entreprises.

Définitions des caractéristiques et de la qualité de la sous-clartiste (ISO 9126-1)

Fonctionnalité - la capacité du logiciel de résoudre des problèmes répondant aux besoins formulés des clients et des utilisateurs lors de l'application d'un complexe de programme dans des conditions spécifiées.

Pertinence fonctionnelle - Définir et des descriptions de sous-classeurs et de ses attributs qui déterminent le but, la nomenclature, les fonctions logicielles principales, nécessaires et suffisantes qui répondent aux spécifications techniques et aux spécifications des exigences du client ou des utilisateurs potentiels.

Exactitude (exactitude) - Possibilité logicielle d'assurer les résultats corrects ou acceptables pour l'utilisateur et les effets externes.

La capacité d'interagir - propriété de logiciels et de leurs composants à interagir avec un ou plusieurs composants de l'environnement interne et externe.

Sécurité - la capacité des composants logiciels à protéger les programmes et les informations de tout impact négatif.