Les critères de qualité sont des indicateurs numériques mesurés, comme une certaine fonction cible, caractérisant le degré d'exécution par objet de leur destination. En général, des critères de qualité devraient afficher une "utilité" généralisée pour la société analysée par l'objet, l'efficacité de la technologie de conception. Le PS se caractérise principalement par la complexité et la durée de la création, ainsi que la qualité des programmes réalisée lors de l'application de technologies pertinentes.

L'analyse du critère de qualité PS FE Programme est la base pour évaluer l'efficacité de la technologie de conception. Dans le processus de formation d'une tâche technique sur le PS, les indicateurs dominants sont détectés, l'importance relative de chacun d'entre eux est établie et la fonction généralisée de la qualité requise d'un PS particulier est en cours de construction et les coûts admissibles et la durée du développement d'outils logiciels pour assurer la technologie appropriée.

Comme le complexe de programme est créé, après avoir terminé le débogage et les tests, la valeur réelle obtenue de chacun des indicateurs et des fonctions de qualité généralisées de l'ensemble du complexe. Des indicateurs de qualité peuvent également être affinés pendant le fonctionnement.

Les développeurs de PS s'efforcent d'allouer et de définir un critère unique pour l'efficacité des programmes:

1. Numériquement Et sous la forme la plus générale caractériser Le degré d'exécution par le système de sa fonction cible principale.

2. Laisser Identifier et évaluer le degré d'influence sur l'efficacité d'un système de divers facteurs et paramètres, et comprenant le coût de divers types de mise en œuvre.

3. Êtresimple et avoir une petite dispersion, c'est-à-dire Miscelle dépendent des facteurs aléatoires incontrôlables.

La possibilité de mettre en œuvre un système qui satisfait à certains critères de qualité dépend naturellement de la fourniture de ressources et de moyens techniques qui effectuent les fonctions principales. Le coût élevé des systèmes complexes, des délais à long terme pour leur conception et leur fabrication, notamment la tâche d'évaluation des coûts au cours de laquelle une telle ou une autre efficacité est atteinte. Particulièrement difficiles dans les complexes contenant des centaines de modules, garantissent la meilleure utilisation des ressources complexes, du point de vue du critère d'efficacité principal, tout en maintenant un certain nombre d'indicateurs de qualité privée dans des limites acceptables.

Les nombreuses et complexes des moyens d'utiliser des programmes nécessitent leur stabilité élevée, à la fois en ce qui concerne les erreurs dans les informations de saisie et par rapport aux défaillances internes de l'ordinateur effectuant le programme. Pour assurer une telle stabilité, des programmes complexes contiennent généralement des opérations de contrôle de différents types et d'avoir des modules d'adaptation et d'auto-organisation spéciaux pour modifier la structure du programme. Et dans certains cas et dans tout le système de contrôle lors du redémarrage, des échecs et des échecs partiels.

Les commandes et les données incluses dans les modules logiciels n'ont pas la fiabilité absolue de l'exécution correcte. Par conséquent, vous devez appliquer des améliorations spécifiques matérielles et logicielles pour la fiabilité des programmes d'obtention des résultats appropriés et de contrôler les influences.

Les indicateurs de qualité peuvent également être affinés pendant le fonctionnement, entraînant une perspective à long terme de la mesure objective et d'améliorer la qualité des programmes.

1. Critères fonctionnels La qualité reflète les spécificités de base de l'application et le degré de conformité du PS à leur objectif. Pour les programmes de contrôle, ils incluent les indicateurs de précision des données de sortie, des plages de changement de paramètre, du temps de réaction, de l'adaptabilité aux influences externes, etc. Dans les systèmes de traitement de données, les indicateurs fonctionnels reflètent la nomenclature des données source, la précision des résultats, la variété des fonctions et l'autre. Les critères fonctionnels sont très différents et correspondent à une variété de cible, de fonctions et d'applications de PS. Ils sont les plus importants pour chaque système (une liste de documents sources - spécifiquement).

2. Critères constructifsla qualité du PS est plus ou moins invariante à leur objectif et aux fonctions de base. Celles-ci incluent la complexité des programmes, la fiabilité de l'opération, les ressources utilisées, l'exactitude du programme, etc. Certains critères constructifs peuvent être importants de la position de l'objectif fonctionnel direct défini par logiciel (fiabilité).

La séparation des critères en deux groupes est conditionnelle et poursuit l'objectif de la répartition des critères de la plus courante pour tous les types de PS et dans le plus petit degré de leurs fins fonctionnelles de base.

Les indicateurs temporaires des programmes LCC devraient être mis en évidence:

1. Durée de conception

2. la durée de l'opération de la prochaine version

3. Durée de chaque modification

Durée et modification Ces travaux dans certains cas peuvent constituer un critère plus important que l'intensité du travail. Dans certains cas, la durée totale du fonctionnement efficace est critère dominant PS de qualité. Pour chacun des développements, il est conseillé de mener du classement (rangs) des critères et des facteurs à la phase de la PS de la LCC.

Logiciel (softwa) À l'heure actuelle, il s'agit de centaines de milliers de programmes destinés à traiter les informations les plus diverses avec les objectifs les plus divers. Selon les tâches, un ou plusieurs logiciels peuvent être divisés par tous les logiciels en plusieurs groupes:

1. Logiciels système (ou programmes système) - est destiné à l'exploitation et à la maintenance de PC, de contrôle et d'organisation du processus informatique lors de la résolution de toute tâche particulière sur PC, etc. Systématique pour la partie obligatoire du logiciel se rapportent à elle

Systèmes d'exploitation

Systèmes d'exploitation Shell.

Programmes utilitaires

2. Logiciel appliqué (ou packages d'applications) - destiné à résoudre une classe de classe spécifique, c'est-à-dire Ce sont des programmes utilisés comme outil lors de la création de documents dans des activités quotidiennes. Ou un programme avec lequel l'utilisateur résout ses tâches d'information sans recourir à la programmation. Ceux-ci inclus.

Chaque PS devrait effectuer certaines fonctions, c'est-à-dire faire ce qui est conçu. Un bon PS doit avoir un autre nombre de propriétés qui lui permettent d'être utilisée avec succès pendant une longue période, c'est-à-dire Avoir une certaine qualité. La qualité du PS est une combinaison de ses caractéristiques et de ses caractéristiques qui affectent sa capacité à satisfaire les besoins donnés des utilisateurs. Cela ne signifie pas que différents PSS doivent avoir le même ensemble de propriétés dans leur plus haut degré possible. Cela est empêché par le fait que l'amélioration de la qualité du PS selon l'une de ces propriétés ne peut souvent être obtenue que par le coût de modification du coût, le moment de l'élaboration du développement et de la réduction de la qualité de ce PS sur sa autres propriétés. La qualité du PS est satisfaisante lorsqu'il a des propriétés spécifiées à une étendue pour assurer son utilisation réussie.

Une combinaison de propriétés PS qui forme une qualité de qualité satisfaisante dépend des conditions et de la nature du fonctionnement de ce PS, c'est-à-dire De la position avec laquelle la qualité de ce PS devrait être envisagée. Par conséquent, lorsque la qualité du PS devrait, tout d'abord, corriger les critères de sélection des propriétés requises du PS. Actuellement, les critères de qualité PS sont pris en compte:

fonctionnalité,

fiabilité,

facilité d'utilisation,

efficacité,

accompagnateur

mobilité.

La fonctionnalité est la capacité PS d'effectuer un ensemble de fonctions qui répondent aux besoins des utilisateurs spécifiés ou impliqués. L'ensemble de ces fonctions est déterminé dans la description externe du PS.

La fiabilité a été discutée en détail dans la première conférence.

La facilité d'utilisation est les caractéristiques de PS, qui vous permettent de minimiser l'utilisation des efforts de l'utilisateur pour préparer les données source, l'utilisation de PS et l'évaluation des résultats obtenus, ainsi que des émotions positives d'un utilisateur donné ou implicite. .

L'efficacité est le rapport entre le niveau des services fournis par le PS à l'utilisateur dans des conditions spécifiées, au volume des ressources utilisées.

L'accompagnement est les caractéristiques du PS, qui vous permettent de minimiser les efforts pour modifier les erreurs et sur sa modification conformément aux besoins changeants des utilisateurs.

La mobilité est la capacité du PS à être transférée d'un support (environnement) à un autre, en particulier, avec un ordinateur à l'autre.

La fonctionnalité et la fiabilité sont des critères de qualité PS obligatoires et veiller à ce que la fiabilité soit un fil rouge pour réussir toutes les étapes et les processus du développement du PS. Les critères restants sont utilisés en fonction des besoins des utilisateurs conformément aux exigences de la PS - leur disposition sera discutée dans des cours appropriés.

2. Assurer la fiabilité - le principal motif du développement logiciel

Nous considérons maintenant les principes généraux pour assurer la fiabilité du PS, qui, comme nous l'avons déjà souligné, est le principal motif pour le développement du PS, demandant à la couleur spécifique à tous les processus technologiques du développement du PS. La technique est connue quatre approches pour assurer la fiabilité:

erreur d'avertissement;

erreur d'exporation d'auto-exporation;

auto-adoption d'erreurs;

assurer la stabilité aux erreurs.

L'approche d'avertissement d'erreur est de prévenir les erreurs dans les produits finis, dans notre cas - en PS. L'examen de la nature des erreurs dans le développement du PS permet de réaliser cet objectif de concentrer l'attention sur les problèmes suivants:

combat avec la complexité;

assurer la précision du transfert;

surmonter la barrière entre l'utilisateur et le développeur;

assurer le contrôle des décisions prises.

Cette approche est associée à l'organisation des processus de développement PS, c'est-à-dire Avec la technologie de programmation. Et bien que, comme nous l'avons déjà noté, il est impossible de garantir le manque d'erreurs dans le PS, mais dans le cadre de cette approche, vous pouvez atteindre un niveau de fiabilité acceptable du PS.

Les trois approches restantes sont associées à l'organisation des produits eux-mêmes, dans nos programmes d'affaires. Ils tiennent compte de la possibilité d'erreurs dans les programmes. L'erreur d'auto-priorité dans le programme signifie que le programme contient les moyens de détecter la défaillance lors de son exécution. L'auto-adaptation de l'erreur dans le programme signifie non seulement la détection de l'échec dans le processus de son exécution, mais également corriger les effets de cette défaillance, pour lesquels le programme doit avoir des moyens appropriés. Fournir la durabilité du programme aux erreurs signifie que le programme contient des fonds pour localiser la zone d'influence de l'échec du programme ou réduire ses conséquences désagréables, et empêcher parfois les conséquences catastrophiques du refus. Cependant, ces approches sont utilisées très rarement (peuvent être relativement plus souvent utilisées pour assurer la stabilité des erreurs). Cela est dû, d'abord, de sorte que de nombreuses méthodes simples utilisées dans la technique de ces approches ne soient pas applicables dans la programmation, par exemple la duplication de blocs individuels et des dispositifs (l'exécution de deux copies du même programme conduira toujours au même effet. - correct ou incorrect). A, deuxièmement, ajouter des moyens supplémentaires à sa complication (parfois significatif), ce qui empêche dans une certaine mesure les méthodes d'avertissement dans une certaine mesure.

La qualité du logiciel (logiciel) est déterminée en fonction de l'étude des fonctionnalités externes et internes du produit. La qualité externe est déterminée par la manière dont cela fonctionne en temps réel, en termes de productivité pour les utilisateurs. La deuxième fonctionnalité se concentre sur les aspects internes, qui dépendent de la qualité du code écrit. L'utilisateur se concentre sur la manière dont il fonctionne au niveau externe, dont la qualité ne peut être prise en charge que si le spécialiste a écrit un bon code de programme.

Qualité logicielle

Actuellement, il existe deux approches importantes qui sont utilisées pour déterminer la qualité des logiciels:

1. Gestion des défauts.
2. Attribut de qualité.

Tout ce qui ne répond pas à l'exigence du client tombe dans la décharge des défauts. L'équipe de développeurs, qui n'est pas capable de comprendre pleinement les exigences du client, permettra d'erreurs de conception.

Dans la gestion des défauts, leur catégorie est déterminée sur la base de la gravité. Le nombre de problèmes de logiciels est calculé et que des mesures sont prises, en fonction de la gravité prescrite. Des diagrammes de contrôle peuvent être créés pour mesurer les possibilités du processus de développement.

La qualité du logiciel s'est considérablement améliorée au cours des deux dernières décennies. L'une des raisons à cet égard est que les entreprises utilisent de nouvelles technologies, telles que le développement orienté objet et les outils de cas. De plus, vous pouvez observer l'importance croissante de la mise en œuvre des méthodes de gestion de la production.

La gestion de la qualité est divisée en trois directions principales:

1. Garantie. Développement des bases des mesures organisationnelles et des normes de qualité logicielles.
2. Planification. Le choix des normes pertinentes et s'adapter à un projet logiciel spécifique.
3. Contrôler. Définition des processus qui garantissent que le développement du logiciel est conforme aux normes de qualité.

Politique d'organisation SQA

La politique de l'organisation en termes de qualité logicielle doit être conforme aux exigences suivantes:

• Conformité aux objectifs et objectifs de l'organisation.
• Engagement envers les concepts d'assurance qualité généraux.
• Engagement envers les normes de qualité adoptées par l'organisation.
• Obligation d'allouer des ressources adéquates.
• Le désir d'améliorer continuellement la qualité et la productivité de l'organisation.

Pour toutes les exigences de la norme, la société prescrive responsable de la qualité. Responsabilités de cet employé:

• Responsabilité de la préparation du programme annuel des événements et du budget SQA.
• Organisation de développement des plans de développement du système SQA.
• Contrôle général sur la mise en œuvre du programme annuel des événements réguliers et des projets de développement planifiés.
• Détermination de la conformité du programme de mesures et du volume des services du sous-traitant et de l'achat du logiciel prévu pour l'année prochaine.
• Présentation et promotion des problèmes de SQA pour l'orientation de la haute direction.
• Étudier des propositions préparées par le département SQA pour le programme annuel des événements, vérifiant le potentiel de la proposition de réaliser des objectifs.

Concepts de haut niveau

Les caractéristiques qualitatives sont des concepts de haut niveau qui reflètent des aspects importants et n'évaluent pas directement la qualité du logiciel. Au lieu de cela, le plan devrait définir les indicateurs correspondants pouvant être utilisés pour déterminer une ou plusieurs caractéristiques.

Par exemple, lors de l'estimation de l'analyseur de syntaxe XML, vous pouvez utiliser un ensemble de tests pour la conformité avec XML W3C. Il inclut des tests conçus pour répondre à toutes les directions de contrôle, ainsi que les recommandations de la langue de balisage extensible W3C (XML) avec un accent particulier sur les exigences de traitement des erreurs dans l'exactitude ou la précision des documents XML. Ainsi, le pourcentage de cas de test passés est utilisé comme une métrique pour évaluer les caractéristiques suivantes de l'analyseur XML à l'étude:

• Utilisateur de perspective.
• Fonctionnalité.
• Fiabilité et tolérance aux pannes.

Du point de vue de l'utilisateur, il existe plusieurs caractéristiques importantes qui répondent aux questions suivantes:

• Qui fournit une gamme complète de fonctions nécessaires pour rendez-vous?
• Est-ce qu'il fonctionne en toute sécurité pour les résultats nécessaires avec une utilisation appropriée?
• Le programme fonctionne-t-il de manière sûre et sécurisée en cas d'entrée incorrecte?
• Est-il facile d'utiliser un logiciel?
• Le logiciel fonctionne rapidement ou semble lent inutile?
• Est le programme avec un produit différent qui utilise l'utilisateur?

Considérant que les problèmes de qualité de l'utilisateur sont importants, le groupe informatique responsable du déploiement et de la maintenance de logiciels peut faire face à d'autres problèmes:

1. Protection contre les attaques malveillantes.
2. Qualité d'utilisation des ressources informatiques.

Les ressources de Nequance sont considérées comme celles qui nécessitent plus de puissance de mémoire et de calcul que nécessaire.

L'ISO fournit ce modèle avec deux nouvelles catégories de niveau supérieur associées au support technologique de la qualité logicielle.

EXIGENCES ISO 9126 pour le produit

ISO 9126 est une norme internationale d'estimation du logiciel. Il est divisé en quatre parties dans lesquelles les sujets suivants sont pris en compte:

• Indicateurs externes.
• Indicateurs internes.
• Modèle de qualité.
• Indicateurs de qualité logicielle.

La première partie de l'ISO 9126 est l'extension de la norme précédente faite par McCall (1977), Boehm (1978) et Furps dans la détermination de l'ensemble des caractéristiques de la qualité.

• Fonctionnalité.
• Fiabilité.
• Convivialité.
• La maintenabilité.
• Portabilité.

Fonctionnalité du produit

La fonctionnalité est l'objectif principal de tout produit ou service. Plus il est possible d'utiliser les marchandises, plus il devient difficile de déterminer sa fonctionnalité. Pour les logiciels, une liste de ce qui est disponible pour cela est indiquée.

Certaines caractéristiques énumérées du logiciel (par exemple, la commodité) ne sont présentes que dans une certaine mesure, non seulement "activée" ou "désactivée". Beaucoup de gens confondent la fonctionnalité globale du processus et du logiciel. Souvent, cela est dû au fait que les diagrammes de flux de données (DFD) et d'autres outils de modélisation peuvent refléter la fonctionnalité du processus en tant qu'ensemble de données converties dans les données.

ISO 9126-1 et d'autres modèles de qualité ne permettent pas de mesurer les coûts totaux ou le produit du processus et sont examinés uniquement par la composante logicielle. La relation entre les caractéristiques fonctionnelles du processus commercial général est au-delà du cadre de l'ISO 9126.

Les caractéristiques d'attribut suivantes caractérisent l'utilité des logiciels dans cet environnement. Chacun d'entre eux ne peut être mesuré que s'il existe des programmes système appropriés.

Dès que le système logiciel commence à fonctionner, la caractéristique de fiabilité détermine sa capacité à soutenir ses services dans certaines conditions pendant des périodes spécifiques. Un aspect de cette caractéristique est la tolérance aux pannes. Par exemple, si le réseau est désactivé dans les 20 secondes, le système doit pouvoir restaurer et continuer à fonctionner.

La capacité d'apprendre à utiliser le système (apprentissage) est l'une des principales caractéristiques de la convivialité.

L'efficacité est associée à des ressources système utilisées dans la fourniture de fonctionnalités nécessaires. La quantité d'espace disque, de mémoire et de réseau est une bonne efficacité. Comme dans le cas d'un certain nombre d'autres critères, il y a des coïncidences entre eux. Par exemple, la commodité d'utiliser le système affecte ses performances.

La possibilité d'identifier et de corriger l'erreur dans le composant logiciel est ce qui se réfère à la caractéristique de la maintenabilité. Ses indicateurs affectent la lisibilité ou la complexité du code, ainsi que la modularité. C'est ce qui contribue à identifier la cause de la faute pour l'éliminer.

Descriptions de la maintenabilité:

• Analyse - identifie la principale cause de refus.
• La variabilité - détermine les efforts qui sont attachés à la modification du code pour éliminer l'erreur.
• STABILITÉ - Démontre la stabilité du système de travail lorsque des modifications y sont apportées.
• Tests - détermine la quantité d'effort sur le test du système.
• Portabilité - La capacité du système à s'adapter aux changements dans son environnement.
• Adaptabilité - À quel point le système est facile à adapter aux modifications apportées à la spécification.
• Vitesse d'installation - quelle facilité le système peut être installé.
• La possibilité de remplacement est la facilité de remplacement du composant système.
• Logiciel de coût de qualité. Il est très important. Lorsque le développeur décide de tester son produit, il va réellement passer du temps, de l'argent et des efforts pour le vérifier.
• Fitness - détermine si des fonctions sont conformes aux exigences.
• Précision - établit l'exactitude de la mise en œuvre des fonctions.
• Compatibilité fonctionnelle - interagir avec d'autres composants du système.
• Conformité sur les lois et recommandations nécessaires.
• Assurer la qualité et la sécurité des transactions de logiciels et de traitement liées aux données.
• Fiabilité - la capacité de travailler sous certaines conditions pour une période de temps indiquée.
• Maturité - Fréquence des échecs.
• Restauration - une idée de la capacité du système à retourner au travail complet après échec.

La portabilité se réfère à la qualité de son adaptation à l'évolution de son environnement ou de ses exigences. Les méthodes de conception et de mise en œuvre orientées objet peuvent contribuer à la manière dont ces caractéristiques de qualité logicielle sont présentes dans ce système.

Le coût d'analyse des processus

Le coût de qualité est calculé en analysant les coûts de conformité et d'incohérence. Le prix du premier indicateur est associé à:

1. Dépenses sur la prévention. Ce montant consacré à la conformité correcte avec toutes les méthodes. Il inclut la formation aux commandes, les contrôles de code et toutes les autres actions associées à l'AQ.
2. Coûts d'évaluation. Il s'agit du montant de l'argent consacré à la planification de toutes les tâches de test, puis de leur exécution, par exemple pour développer des exemples de test.
3. Coûts pour incohérence. Ce sont les coûts qui se produisent en raison de défaillances internes et externes.

Les échecs nationaux sont les coûts qui apparaissent lorsque des exemples de test sont effectués pour la première fois au niveau interne, tandis que certains d'entre eux échouent. Les coûts surviennent lorsque le programmeur doit corriger tous les défauts identifiés dans son fragment lors des tests modulaires ou de composants.

Les défaillances externes sont les coûts qui se produisent lorsque le défaut est défini par le client et non un testeur. Ces coûts sont beaucoup plus grands que ceux qui apparaissent au niveau interne. Ceci est particulièrement vrai si l'échec du programme est amélioré.

Analyse de processus disciplinée

Cette évaluation du processeur comprend l'identification et les caractéristiques de la pratique actuelle, déterminant les forces et les faiblesses, ainsi que la capacité de contrôler ou d'éviter les causes essentielles de mauvaise qualité des marchandises. Les programmes d'audit peuvent être trois types:

1. Amour propre. Il est mené au sein du personnel de l'organisation.
2. Évaluation d'une organisation tierce partie.
3. Évaluation par une tierce partie.

L'audit du processus logiciel est effectué dans un environnement général ouvert afin d'améliorer ses indicateurs et d'utiliser des programmes d'assurance qualité logiciels. Les résultats d'un tel audit sont confidentiels pour l'organisation.

En ce qui concerne la collecte de données, quatre méthodes sont utilisées:

1. Liste standard des problèmes de maturité.
2. Entretiens individuels et de groupe.
3. Critiques des documents.

Dans le dictionnaire explicatif de l'informatique v.i. Pershikova et V.M. Savinkov Concept Normalisation est définie comme l'adoption d'un accord sur la spécification, la production et l'utilisation de matériel et de logiciels pour l'équipement informatique; Établissement et application de normes, normes, règles, etc.

Les normes sont d'une grande importance - elles offrent la possibilité d'utiliser les données et programmes et programmes d'autres développeurs, données d'exportation / importation.

Ces normes régissent l'interaction entre différents programmes. À cette fin, des normes d'interface interprogrammation, telles que des objets OLE (liaison d'objet et incorporation - reliant et incorporation d'objets). Sans ces normes, les produits logiciels seraient «fermés» les uns pour les autres.

Les normes occupent une place de plus en plus importante dans la direction du développement de l'industrie des technologies de l'information. Plus de 250 sous-comités des organisations de normalisation officielles travaillent sur les normes dans le domaine des technologies de l'information. Plus de 1000 normes ou déjà acceptées par ces organisations ou dans le processus de développement. Le processus de normalisation des technologies de l'information est loin d'être achevé (oui, à notre avis, il est peu probable que cela soit jamais achevé, puisque la région de la technologie de l'information se développe en permanence).

Tous les développeurs doivent fournir un niveau de qualité acceptable de logiciels émis (logiciels). À ces fins, des normes de qualité de la qualité des logiciels ou des sections individuelles des normes de développement de logiciels sont dédiées aux exigences de qualité logicielles.

Du point de vue de l'utilisateur, toutes les variétés de logiciels doivent être gérées uniformément. Il doit y avoir une navigation uniforme - en mouvement selon le programme, des contrôles uniformes pour le logiciel et une seule réponse logicielle aux actions de l'utilisateur. Cela a développé des normes pour l'interface utilisateur - GUI (interface utilisateur graphique). Tout cela est régi par des normes opérant dans le domaine des technologies de l'information.

La nécessité de standardiser le développement de logiciels est décrite la plus avec succès dans l'introduction à la norme ISO / CEI 12207: «Le logiciel fait partie intégrante des technologies de l'information et des systèmes traditionnels, tels que le transport, l'armée, la médecine et la finance. Il existe de nombreuses normes diverses, Procédures, méthodes, types instrumentaux et types de l'environnement d'exploitation pour le développement de logiciels et la gestion. Cette diversité crée des difficultés à concevoir et à gérer des logiciels, en particulier lors de la combinaison de produits logiciels et de programmes de services. La stratégie de développement logiciel nécessite une transition de cet ensemble à un ordre commun. Cela permettra aux spécialistes de pratiquer des logiciels "parler dans une langue" lors de l'élaboration et de la gestion de logiciels. Cette norme internationale fournit une procédure générale. "

Essayons de faire la commande dans la diversité des normes y opérant et les classer (Fig. 1.3).

Comme on peut le voir, la partie supérieure de la classification ressemble aux types de normes ci-dessus. Cependant, leurs caractéristiques apparaissent ici. Cela s'applique principalement aux normes "de yura" et "de facto". Déterminons immédiatement ces concepts.

La norme "de facto" est un terme désignant un produit d'un fournisseur qui a capturé une part de marché importante et que d'autres fournisseurs ont tendance à imiter, copier ou utiliser pour capturer leur part du marché.

L'une des principales raisons de l'importance du programme de normalisation moderne est la prise de conscience du risque d'abus de normes de facto. Dans les années 60 et 70 du XXe siècle, la création de normes de facto met les utilisateurs aux fabricants dépendants des fabricants lors de l'utilisation de la transformation des données fixes et des télécommunications. Un aspect important des travaux de normalisation d'aujourd'hui consiste à surmonter cette dépendance grâce à la promotion des interfaces standard. Pendant longtemps, de telles normes étaient SQL (langage de requête structuré) et la langue des diagrammes D. Ross Sadt (technique d'analyse structurée et de conception). La norme "De Yura" est créée par une organisation de normalisation officiellement reconnue. Il est développé par le respect des règles de consensus dans le processus de discussion ouvert dans lequel tout le monde a la chance de participer. Aucun groupe ne peut agir de manière indépendante, créant des normes pour l'industrie. Si un groupe de fournisseurs crée une norme qui ne prend pas en compte les exigences des utilisateurs, elle échouera. La même chose se produit si les utilisateurs créent une norme avec laquelle les fournisseurs ne peuvent pas ou ne seront pas d'accord - cette norme ne réussira pas. Les normes «de yura» ne peuvent pas être modifiées sans avoir passé le processus de coordination sous le contrôle de l'organisation élaborant des normes. Normes OSI (modèle de référence d'interconnexion des systèmes ouverts), Ethernet, POSIX, SQL et la plupart des normes de langues sont des exemples de ce type de normes. À titre d'exemple de la transition de la norme «de facto» dans la norme de Yura, examinez l'historique du développement et de la normalisation de la langue SQL.

Les travaux sur la création de la langue SQL ont été lancés dans les années 70 du siècle dernier dans les laboratoires de recherche IBM. Il est maintenant devenu l'une des normes principales dans le domaine des systèmes d'information et a fourni la technologie de base de la langue pour toute une génération de SGBD basée sur le modèle relationnel. Malgré le fait que c'était mis en œuvre commercialement au début des années 1980, uniquement pour un petit groupe de produits logiciels, SQL, reconnaissant sans aucun doute l'adoption de l'ANSI et de la norme ISO SQL-86. Plus tard, lors de la préparation de la norme SQL-89, un certain nombre de fonctionnalités supplémentaires ont été incluses dans la langue.

Figure. 1.3. Système de classification des normes de technologie de l'information

Les origines de SQL doivent être attribuées à la période de naissance du modèle de données relationnelles (décrites dans le code E.F.). Depuis au cours des prochaines années, aucune langue comme SQL n'a aucune langues, dans des projets de recherche initiés par IBM après la publication de l'article EF. Le code, la signification particulière de la nécessité de créer les langues d'interface créées par le SGBM pour tester les capacités du modèle relationnel a été attaquée. L'histoire du développement SQL illustre la Fig. 1.4.

Dans les laboratoires de recherche IBM, au début des années 70 du XXe siècle, d'autres projets sur la création et la réalisation expérimentale des langues relationnelles ont été développés simultanément avec des travaux sur la future langue SQL. Probablement, les plus célèbres d'entre eux sont créés par M. Zluf du laboratoire IBM de Yorktown-Heights à peu près au même moment avec Suite (version précoce de SQL) Query-par exemple relationnel (QBE). Cette langue est actuellement utilisée dans de nombreux logiciels commerciaux ainsi que SQL.

En 1974, Donald D. Chamberslin du Laboratoire de recherche IBM à San Jose a suggéré la spécification de la langue relationnelle appelée suite suite (langage de requête anglais structuré). La version révisée de cette langue (suite / 2) a été développée en 1976-1977 et a acquis son nom final - SQL (langue de requête structurée).

Même avant que les produits commerciaux IBM au début des années 80 du 20e siècle entrent sur le marché des logiciels, Relation Software Inc. (Maintenant appelé Oracle Corporation) a annoncé la publication d'un DBM relationnel basé sur SQL. Ce système à la suite de son évolution est devenu l'un des systèmes commerciaux dominants et s'appelle Oracle.

Le produit Oracle avec son langage SQL est confronté à la concurrence dans le domaine de l'ordinateur de taille moyenne et du mini-ordinateur des produits d'un certain nombre d'autres développeurs, en particulier de l'INGRS SGMS avec la Compagnie de langue de la Quel Language Company Relation Technology Inc., ainsi que de la RDB. / Produit VMS avec Société d'équipement numérique RDML.

L'une des raisons du succès de SQL était la formation de l'Institut national de normalisation américain, ANSI (Institut national de normalisation américain, un comité HZN2 créé pour élaborer des normes standard des langues de la base de données. Le représentant IBM a suggéré d'utiliser les résultats des travaux IBM précédemment effectués sur la suite / 2 comme spécifications préliminaires de la langue relationnelle et les développeurs standard ont commencé. Le document intitulé «SQL» était pour la plupart du traité sur divers formes SQL utilisés dans les produits logiciels commerciaux.

Organisation des normes internationales, ISO) dans le cadre du Comité technique TC97 (appelée maintenant en tant que ISO / IEC JTC1) a également mené des travaux pour créer une norme pour les langues de la base de données linguistiques. Au milieu des années 80, ANSI et ISO ont approuvé les normes SQL (ANSI-en 1986, une ISO - début 1987).

La première norme SQL en relation avec la méthode de son développement était très incomplète en termes de fonctionnalité des systèmes de base de données et de nombreux fournisseurs ont continué de mettre un grand nombre d'extensions à la norme dans leurs produits logiciels. En 1989, la version révisée de la norme SQL a été adoptée, qui était différente de la norme de 1986. Principalement précisément avec les capacités de soutien aux liens d'intégrité.

Cependant, avant 1989, l'ANSI et l'ISO ont commencé à travailler sur des extensions radicales SQL. Ce travail, initialement identifié comme "SQL2", a commencé en 1987 et ses résultats ont été cinq ans plus tard adoptés comme standard SQL-92.

Ajoute une confusion également le fait que les travaux sur SQL2 se chevauchent de travaux sur SQL3, la nouvelle version de la norme SQL, qui est encore en cours de développement. Les travaux sur SQL3 ont commencé en 1990 parallèlement à SQL2, principalement sur le «réservoir de réserve» pour les capacités qu'il a été supposée ne pas inclure pour une raison ou une autre dans SQL2. SQL3 comprend des extensions de langue orientées objet, ainsi que des fonctionnalités relationnelles supplémentaires qui n'ont pas trouvé d'espace dans SQL2.

Nous illustrons à la Fig. 1.5 En référence à l'axe de l'heure, le processus de développement de diverses normes SQL.

Il convient de noter que dans le domaine des technologies de l'information, il existe deux approches principales historiquement établies dans le développement des normes. Le premier - lorsque le problème est brassé, -ideas dans la norme. Dans ce cas, un groupe d'experts dans une partie de la technologie de l'information est collecté et discute des solutions locales inventées par des sociétés individuelles - les fabricants de logiciels et d'organisations scientifiques, effectuent une analyse de ces décisions et développe une norme intégrale unique qui inclut les meilleures idées et Développements.

Mais le marché vit dans quelques autres lois. La première approche a une inertie, le problème est déjà abandonné, il doit être résolu, et il est inconnu lorsque des experts rassembleront et développeront la norme nécessaire. Dans le deuxième cas, la société - Les développeurs de développement de chaque solution et la solution la plus populaire et la plus populaire du point de vue de la fréquence d'utilisation de la solution acquiert l'état de la norme (facultatif légalement). Ainsi, SQL est devenu la norme pour la référence aux bases de données, appelée "de facto", bien que le statut de la norme a été fixé légalement.

L'inconvénient de cette approche est que la norme ne devient pas la solution commerciale la plus forte, mais la plus massive.

À titre d'autre exemple, l'apparition de la norme peut être donnée à l'émergence de la langue de modélisation actuelle UML - unifiée. Les principaux développements sur les méthodes d'analyse et de conception orientés objet sont apparus entre 1988 et 1992. En 1994, il y avait un grand nombre de praticiens informels et de praticiens (à propos d'Aven une demi-douzaine), qui ont promu leurs méthodologies. Toutes leurs méthodes étaient similaires, tandis que souvent des différences entre eux se trouvaient dans des détails secondaires. Parler traité de la normalisation. Le commandement de OMG a tenté d'examiner le problème de la normalisation, mais en réponse à une lettre ouverte avec une protestation de tous les auteurs. En 1996, trois grands spécialistes de l'analyse orientée sur le terrain et de la conception de James Rumbo (James Rumbaugh), de Grade Buch (Ivar Jacobson), Ivan Jacobson étaient unis et une version unifiée de 0,8 version est née, en 1996 "Trois amis" travaillé sur leur propre méthode, qui s'appelait une langue de modélisation unifiée. En janvier 1997, diverses organisations ont présenté leurs propositions de normalisation des méthodes, offrant d'abord la possibilité d'échanger des informations entre différents modèles. En conséquence, il existe maintenant une seule offre - la norme UML.

Le concept de "logiciel de qualité".

La base des méthodes d'ingénierie dans la programmation est l'idée d'améliorer la qualité du logiciel, de la mise en œuvre de laquelle des méthodes de détermination de la qualité des exigences logicielles ont été formées, des approches du choix et de l'amélioration des modèles d'analyse métrique d'indicateurs de qualité des indicateurs de qualité, Les méthodes de mesure quantitative d'indicateurs de qualité aux étapes du cycle de vie logiciel.

De qualité - Il s'agit d'un ensemble de propriétés qui déterminent l'utilité du produit (programme) pour les utilisateurs conformément à l'objectif fonctionnel et aux exigences soumises. 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 de «qualité». 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". La qualité du logiciel est un concept relatif qui n'a aucun sens que lors de la prise en compte des conditions réelles de l'application logicielle. Par conséquent, les exigences de qualité logicielle sont définies conformément aux termes et conditions de la demande.

Modèles de qualitéavoir les quatre niveaux de présentation suivants.

Premier niveau Conforme à la définition des caractéristiques (indicateurs) de la qualité logicielle, chacune de ceux-ci reflète un point de vue distinct de l'utilisateur sur la qualité. Selon la norme GOST R ISO / CEI 9126-93, GOST R ISO / CEI 12119-2000, GOST 28195-89, le modèle de qualité comprend six caractéristiques, soit six indicateurs de qualité clés qui seront répertoriés dans l'ordre de leur importance pour La plupart des utilisateurs:

• Fonctionnalité;
• Fiabilité fonctionnelle;
• facilité d'utilisation;
• Efficacité;
• accompagnement;
• Portabilité.

Deuxième niveau. Ce niveau correspond aux attributs de chaque caractéristique de qualité qui détaille différents aspects d'une caractéristique spécifique. L'ensemble d'attributs de caractéristiques de qualité est utilisé lors de l'évaluation de la qualité.

Envisagez des ensembles d'attributs pour chacun des indicateurs de qualité répertoriés (Fig. 3.1).

La fonctionnalité est un ensemble de propriétés qui déterminent la capacité du logiciel d'exécuter les fonctions dans un environnement donné conformément aux exigences spécifiées. En dessous de une fonction Une certaine séquence ordonnée d'actions est comprise pour répondre aux propriétés des consommateurs. Les fonctions sont cible (maintenance) JE. auxiliaire.

Les attributs de fonctionnalité incluent:

• sécurité - un attribut qui montre la capacité d'empêcher l'accès non autorisé (aléatoire ou délibéré) aux programmes et aux données;
• interopérabilité - attribut qui montre la possibilité d'interaction de ce logiciel avec des systèmes spéciaux et des supports (systèmes d'exploitation, réseaux informatiques);
• fullness fonctionnelle - Attribut, qui montre la mesure de l'adéquation des fonctions de base pour résoudre des problèmes conformes aux fins de ce logiciel.

Fiabilité fonctionnelle. Les attributs de la fiabilité fonctionnelle du logiciel incluent:

• calme - attribut qui définit la capacité de fonctionner sans erreurs;
• droite - attribut qui montre la mesure de la réalisation des bons résultats;
• manette - Attribut qui caractérise l'exhaustivité et l'efficacité de la détection d'erreur dans les résultats intermédiaires et de sortie
• résistance aux erreurs - un attribut qui caractérise la capacité d'exécuter correctement des fonctions dans des conditions anormales (défaillance de dysfonctionnement, erreurs dans les données et les interfaces, etc.);
• faiblesse - attribut qui caractérise la capacité de ne pas provoquer de refus de fonctionnement du système d'information;
• aptitude à la récupération - un attribut qui caractérise la capacité du programme d'éliminer l'erreur de programme et à un redémarrage de ré-exécuter et de récupérer des données en cas d'échec fonctionnel;
• préparation - Attribut, qui montre la capacité d'un programme sur une application arbitraire à effectuer avec précision la transformation fournie.

La facilité d'utilisation est caractérisée par une pluralité d'attributs indiquant les conditions nécessaires et appropriées à utiliser conformément à la plage spécifiée d'utilisateurs pour obtenir les résultats pertinents. Dans la norme, la commodité d'utilisation est définie comme un ensemble spécifique d'attributs logiciels caractérisant son ergonomie.

Figure. 3.1.

Les attributs sont appliqués aux attributs:

• compréhensibilité - attribut qui détermine les efforts déployés sur la reconnaissance des concepts logiques et des conditions d'application du logiciel;
• appris (Facilité d'étude) - un attribut qui détermine les efforts des utilisateurs visant à déterminer l'applicabilité en utilisant le contrôle opérationnel, les diagnostics, ainsi que les procédures, les règles et la documentation;
• opérationnel - Attribut qui montre la réaction du système lors de l'exécution des opérations et du contrôle opérationnel.

Efficacité - Un ensemble d'attributs qui déterminent la relation des niveaux de mise en œuvre du logiciel, l'utilisation de ressources (fonds, équipements, matériel - papier pour le dispositif d'impression, etc.) et des services effectués par le personnel de service standard et d'autres.

Les attributs d'efficacité incluent:

• réactivité - attribut qui montre le temps de réponse, le traitement et l'exécution des fonctions;
• efficacité des ressources - attribut montrant le nombre et la durée des ressources utilisées lors de la réalisation de fonctions de logiciels;
• cohérence - Attribut, qui montre la conformité de cette caractéristique aux normes, règles et règlements spécifiés.

L'accompagnement est un ensemble de propriétés qui caractérisent les efforts qui devraient être censés effectuer des modifications comprenant l'ajustement, l'amélioration et l'adaptation des logiciels lors de la modification de l'environnement, des exigences ou des spécifications fonctionnelles.

L'accompagnement inclut les attributs suivants:

• analyseur- attribut définissant les efforts nécessaires pour diagnostiquer les défaillances ou les pièces d'identification qui seront modifiées;
• stabilité - attribut indiquant la constance de la structure et le risque de modification;
• essai -Trapist indiquant les efforts lors de la validation et de la vérification afin de détecter le non-respect des exigences, ainsi que de la nécessité de modifier les logiciels et la certification;
• changeabilité - Attribut qui détermine la possibilité de supprimer des erreurs dans des logiciels ou de modifier les modifications pour les éliminer, ainsi que l'introduction de nouvelles fonctionnalités dans des logiciels ou sur l'environnement de fonctionnement.

La portabilité est un ensemble d'indicateurs indiquant la capacité de s'adapter au travail dans les nouvelles conditions du temps d'exécution. Mercredi peut être organisationnel, matériel et logiciel. Par conséquent, le transfert de logiciels à un nouvel environnement de mise en œuvre peut être associé à un ensemble d'actions visant à assurer son fonctionnement dans un moyen autre que l'environnement dans lequel il a été créé, en tenant compte de nouveaux programmes, de fonctionnalités organisationnelles et techniques.

La portabilité comprend des attributs:

• adaptabilité - attribut qui détermine les efforts déployés sur l'adaptation à divers environnements;
• personnalisabilité (simplicité de l'installation) - un attribut qui définit les efforts nécessaires pour démarrer ce logiciel dans un environnement spécial;
• coexistence - attribut qui détermine la possibilité d'utiliser des logiciels spéciaux dans l'environnement du système actuel;
• remplacement - Attribut qui caractérise la possibilité de transférer des logiciels d'un environnement d'outil à un autre avec l'installation ou l'adaptation nécessaire du logiciel.

Troisième niveau Conçu pour mesurer la qualité avec métrique Chacun d'eux est défini comme une combinaison de la méthode d'attribut de mesure et de la balance de mesure des valeurs d'attribut. Pour estimer les attributs de qualité aux étapes du cycle de vie (lors de la visualisation des résultats de la documentation, des programmes et des tests de programme), des mesures sont utilisées avec un poids estimé donné au niveau des résultats de l'analyse métrique d'attributs totaux d'un indicateur et d'une qualité particuliers. un ensemble. L'attribut de qualité est déterminé à l'aide d'une ou de plusieurs méthodes d'évaluation aux étapes du cycle de vie et à la phase finale du développement logiciel.

Quatrième niveau - Il s'agit d'un élément métrique estimé (poids), utilisé pour estimer la valeur quantitative ou qualitative d'un attribut distinct de l'indicateur de qualité du logiciel. Selon les fins, les caractéristiques et les conditions de prise en charge des logiciels, les caractéristiques de la qualité les plus importantes et leurs attributs sont sélectionnés. Les attributs sélectionnés et leurs priorités sont reflétés dans les exigences relatives au développement de systèmes, ou de priorités appropriées de la catégorie de logiciels de classe auxquelles il est utilisé.