Les critères de qualité sont des indicateurs numériques mesurables, sous la forme d'une fonction cible, caractérisant le degré avec lequel un objet remplit sa fonction. En général, les critères de qualité doivent refléter « l'utilité » généralisée pour la société, l'objet analysé et l'efficacité de la technologie de conception. Les logiciels se caractérisent principalement par la complexité et la durée de création, ainsi que par la qualité obtenue des programmes lors de l'utilisation de technologies appropriées.

L'analyse des critères de qualité du programme de cycle de vie PS constitue la base pour évaluer l'efficacité de la technologie de conception. Dans le processus d'élaboration des spécifications techniques du logiciel, les indicateurs dominants sont identifiés, l'importance relative de chacun d'eux est établie et une fonction généralisée de la qualité requise d'un logiciel particulier est construite, en plus des coûts et de la durée acceptables de développement logiciel que la technologie correspondante devrait fournir sont établies.

Au fur et à mesure qu'un ensemble de programmes est créé, une fois le débogage et les tests terminés, la valeur réelle obtenue de chacun des indicateurs et les fonctions de qualité généralisées de l'ensemble du complexe sont clarifiées. Les indicateurs de qualité peuvent également être affinés en cours d’exploitation.

Les développeurs de logiciels s'efforcent d'identifier et de définir un critère unique d'efficacité des programmes :

1. Numériquement et sous la forme la plus générale caractériser le degré auquel le système remplit sa fonction cible principale.

2. Laisser identifier et évaluer le degré d'influence de divers facteurs et paramètres sur l'efficacité du système, y compris divers types de coûts pour sa mise en œuvre.

3. Être simple et ont une faible variance, c'est-à-dire peu dépendre de facteurs aléatoires et incontrôlables.

La capacité à mettre en œuvre un système répondant à certains critères de qualité dépend naturellement de la mise à disposition de ressources et de moyens techniques assurant les fonctions de base. Le coût élevé des systèmes complexes et les longs délais de conception et de fabrication posent un problème particulièrement aigu d'estimation des coûts auxquels telle ou telle efficacité est atteinte. Il est particulièrement difficile dans les complexes logiciels contenant des centaines de modules d'assurer la meilleure utilisation des ressources du complexe, du point de vue du principal critère d'efficacité, tout en maintenant un certain nombre d'indicateurs de qualité privés dans des limites acceptables.

Les modes d'utilisation nombreux et complexes des programmes nécessitent leur grande stabilité, tant par rapport aux erreurs de saisie des informations que par rapport aux pannes internes de l'ordinateur exécutant le programme. Pour assurer une telle stabilité, les programmes complexes contiennent généralement des opérations de contrôle de différents types et disposent de modules spéciaux d'adaptation et d'auto-organisation pour modifier la structure du programme. Et dans certains cas, l'ensemble du système contrôle lors des redémarrages, des pannes et des pannes partielles.

Les commandes et les données incluses dans les modules du programme n'ont pas une fiabilité absolue d'exécution correcte. Par conséquent, il est nécessaire d'utiliser du matériel et des logiciels spéciaux pour améliorer la fiabilité de l'exécution du programme afin d'obtenir des résultats et des actions de contrôle corrects.

Les indicateurs de qualité peuvent également être affinés pendant l'exploitation, ce qui donne lieu à une perspective à long terme de mesure objective et d'amélioration de la qualité du programme.

1. Critères fonctionnels les qualités reflètent les principales spécificités de l'application et le degré de conformité du PS avec sa destination. Pour les programmes de contrôle, ils comprennent des indicateurs de précision des données de sortie, des plages de paramètres, 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 sources, la fiabilité des résultats, la variété des fonctions, etc. Les critères fonctionnels sont très différents et correspondent à la diversité des finalités, des fonctions et des domaines d'application du logiciel. Ce sont les plus importants pour chaque système (la liste des documents sources est spécifique).

2. Critère de design les qualités des PS sont plus ou moins invariantes par rapport à leur objectif et à leurs fonctions principales. Ceux-ci incluent la complexité des programmes, la fiabilité du fonctionnement, les ressources utilisées, l'exactitude des programmes, etc. Certains critères de conception peuvent être importants du point de vue de la finalité fonctionnelle directe, déterminée par le logiciel (fiabilité).

La division des critères en deux groupes est arbitraire et vise à mettre en évidence les critères les plus courants pour tous les types de logiciels et les moins dépendants de leur objectif fonctionnel principal.

Une attention particulière doit être portée aux indicateurs temporaires du cycle de vie des programmes :

1. durée de conception

2. durée de fonctionnement de la prochaine version

3. durée de chaque modification

Durée et modification la réalisation de ce travail peut dans certains cas être un critère plus important que l'intensité du travail. Dans certains cas, la durée totale de fonctionnement effectif est critère dominant Qualité PS. Pour chacune des évolutions, il convient de procéder à un classement (rangs) de critères et de facteurs aux étapes du cycle de vie du PS.

Logiciel (logiciel) Il existe actuellement des centaines de milliers de programmes conçus pour traiter une grande variété d'informations à des fins diverses. En fonction des tâches exécutées par un logiciel particulier, tous les logiciels peuvent être divisés en plusieurs groupes :

1. Logiciel système (ou programmes système) - conçu pour le fonctionnement et la maintenance d'un PC, la gestion et l'organisation du processus informatique lors de la résolution de tout problème spécifique sur un PC, etc. Le logiciel système est une partie obligatoire du logiciel, il comprend

Systèmes d'exploitation

Shells du système d’exploitation.

Programmes utilitaires

2. Logiciel d'application (ou progiciels d'application) – conçu pour résoudre une certaine classe de problèmes, c'est-à-dire Il s'agit de programmes utilisés comme outil de création de documents dans les activités quotidiennes. Ou des programmes avec lesquels l'utilisateur résout ses problèmes d'information sans recourir à la programmation. Ceux-ci inclus.

Chaque PS doit remplir certaines fonctions, c'est-à-dire faire ce qui est prévu. Un bon PS doit également posséder un certain nombre de propriétés qui lui permettent d'être utilisé avec succès sur une longue période, c'est-à-dire avoir une certaine qualité. La qualité d'un logiciel est l'ensemble de ses fonctionnalités et caractéristiques qui affectent sa capacité à satisfaire les besoins spécifiés des utilisateurs. Cela ne signifie pas que les différents PS doivent avoir le même ensemble de propriétés dans toute la mesure du possible. Ceci est entravé par le fait qu'augmenter la qualité du logiciel pour l'une de ces propriétés ne peut souvent être obtenu qu'au prix d'une modification du coût, du calendrier d'achèvement du développement et d'une réduction de la qualité de ce logiciel pour ses autres propriétés. La qualité du PS est satisfaisante lorsqu'il possède les propriétés spécifiées de manière à garantir son bon usage.

L'ensemble des propriétés du PS, qui constituent la qualité du PS satisfaisante pour l'utilisateur, dépend des conditions et de la nature du fonctionnement de ce PS, c'est-à-dire de la position à partir de laquelle la qualité de ce PS doit être considérée. Par conséquent, lors de la description de la qualité du PS, les critères de sélection des propriétés requises du PS doivent tout d'abord être fixés. Actuellement, les critères de qualité du PS sont considérés comme :

Fonctionnalité,

fiabilité,

facilité d'utilisation,

efficacité,

accompagnement,

mobilité.

La fonctionnalité est la capacité d'un système logiciel à exécuter un ensemble de fonctions qui satisfont les besoins spécifiés ou implicites de l'utilisateur. L'ensemble des fonctions spécifiées est défini dans la description externe du logiciel.

La fiabilité a été discutée en détail dans la première leçon.

La facilité d'utilisation est la caractéristique du logiciel qui permet de minimiser les efforts de l'utilisateur pour préparer les données initiales, appliquer le logiciel et évaluer les résultats obtenus, ainsi que susciter les émotions positives d'un utilisateur spécifique ou implicite.

L'efficacité est le rapport entre le niveau de services fournis par le PS à l'utilisateur dans des conditions données et le volume de ressources utilisées.

La maintenabilité est la caractéristique d'un système logiciel qui permet de minimiser les efforts pour apporter des modifications, éliminer les erreurs et le modifier en fonction des besoins changeants des utilisateurs.

La mobilité est la capacité d'un système logiciel à être transféré d'un environnement (environnement) à un autre, notamment d'un ordinateur à un autre.

La fonctionnalité et la fiabilité sont des critères obligatoires pour la qualité des logiciels, et garantir la fiabilité sera un fil conducteur à toutes les étapes et processus de développement logiciel. Les critères restants sont utilisés en fonction des besoins des utilisateurs conformément aux exigences du logiciel - leur fourniture sera discutée dans les sections appropriées du cours.

2. Assurer la fiabilité est la principale motivation du développement de logiciels

Considérons maintenant les principes généraux visant à garantir la fiabilité du PS, qui, comme nous l'avons déjà souligné, est le principal motif du développement du PS, qui donne une couleur spécifique à tous les processus technologiques de développement du PS. Quatre approches pour garantir la fiabilité sont connues en technologie :

prévention des erreurs ;

auto-détection des erreurs ;

autocorrection des erreurs;

garantir la tolérance aux erreurs.

L’objectif de l’approche de prévention des erreurs est d’éviter les erreurs dans les produits finis, dans notre cas, dans les logiciels. La réflexion menée sur la nature des erreurs dans le développement des logiciels permet de se concentrer sur les problématiques suivantes pour atteindre cet objectif :

lutter contre la complexité ;

assurer l'exactitude de la traduction ;

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 logiciel, c'est-à-dire avec la technologie de programmation. Et bien que, comme nous l'avons déjà noté, il soit impossible de garantir l'absence d'erreurs dans le PS, dans le cadre de cette approche il est possible d'atteindre un niveau acceptable de fiabilité du PS.

Les trois autres approches sont liées à l'organisation des produits technologiques eux-mêmes, dans notre cas, les programmes. Ils prennent en compte la possibilité d'erreurs dans les programmes. L'auto-détection d'une erreur dans un programme signifie que le programme contient un moyen de détecter une panne lors de son exécution. L'autocorrection d'une erreur dans un programme signifie non seulement détecter une panne lors de son exécution, mais aussi corriger les conséquences de cette panne, pour laquelle le programme doit disposer des moyens appropriés. Assurer la résistance aux erreurs du programme signifie que le programme contient des outils qui permettent de localiser la zone d'influence d'une panne de programme, ou de réduire ses conséquences désagréables, et parfois de prévenir les conséquences catastrophiques d'une panne. Cependant, ces approches sont utilisées très rarement (peut-être que la tolérance aux erreurs est utilisée relativement plus souvent). Cela est dû, d'une part, au fait que de nombreuses méthodes simples utilisées en technologie dans le cadre de ces approches ne sont pas applicables en programmation, par exemple la duplication de blocs et de dispositifs individuels (l'exécution de deux copies du même programme entraînera toujours le même effet - vrai ou faux). Et, deuxièmement, l'ajout d'outils supplémentaires au programme entraîne sa complication (parfois importante), qui interfère dans une certaine mesure avec les méthodes de prévention des erreurs.

La qualité du logiciel (logiciel) est déterminée sur la base de l'étude des fonctionnalités externes et internes du produit. La qualité externe est déterminée par la manière dont elle fonctionne en temps réel et par sa 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 davantage sur le fonctionnement du logiciel au niveau externe, dont la qualité ne peut être maintenue que si le spécialiste a écrit un bon code de programme.

Qualité du logiciel

Actuellement, deux approches importantes 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 aux exigences du client entre dans la catégorie des défauts. Une équipe de conception qui ne comprend pas pleinement les exigences du client commettra des erreurs de conception.

Dans la gestion des défauts, les catégories de défauts sont déterminées en fonction de leur gravité. Le nombre de problèmes logiciels est comptabilisé et des mesures sont prises en fonction de la gravité établie. Des cartes de contrôle peuvent être créées pour mesurer les capacités du processus de développement.

La qualité des logiciels s'est considérablement améliorée au cours des deux dernières décennies. Cela s'explique notamment par le fait que les entreprises utilisent de nouvelles technologies telles que le développement orienté objet et les outils CASE. De plus, on peut observer l’importance croissante de la mise en œuvre de pratiques de gestion dans la production.

La gestion de la qualité des logiciels est divisée en trois domaines principaux :

1. Garantie. Développement des fondements des activités organisationnelles et des normes de qualité des logiciels.
2. Planification. Sélection de standards appropriés et adaptation à un projet logiciel spécifique.
3. Contrôle. Définir des processus qui garantissent que le développement de logiciels répond aux normes de qualité.

Politique d'organisation SQA

La politique qualité logicielle de l'organisation doit répondre aux exigences suivantes :

• Respect des buts et objectifs de l'organisation.
• Engagement envers les concepts généraux d’assurance qualité.
• Engagement envers les normes de qualité adoptées par l’organisation.
• Engagement à allouer des ressources adéquates.
• Engagement envers l’amélioration continue de la qualité et de la productivité de l’organisation.

Pour garantir que toutes les exigences de la norme sont respectées, les entreprises nomment un responsable qualité. Responsabilités de cet employé :

• Responsable de la préparation du programme annuel d'activités et du budget de la SQA.
• Organisation de l'élaboration des plans de développement du système SQA.
• Contrôle global de la mise en œuvre du programme annuel des activités régulières et des projets de développement planifiés.
• Déterminer si le programme d'activités correspond aux caractéristiques et à l'étendue des services de sous-traitance et des achats de logiciels prévus pour l'année à venir.
• Présentation et plaidoyer des problématiques SQA auprès de la direction générale.
• Examiner les propositions préparées par la SQA pour le programme annuel des événements, en vérifiant le potentiel de la proposition pour atteindre ses objectifs.

Concepts de haut niveau

Les caractéristiques qualitatives sont des concepts de haut niveau qui reflètent des aspects importants et ne sont pas directement évalués pour la qualité du logiciel. Le plan devrait plutôt identifier des indicateurs pertinents qui peuvent être utilisés pour déterminer une ou plusieurs caractéristiques.

Par exemple, lors de l'évaluation d'un analyseur XML, vous pouvez utiliser la suite de tests de conformité XML du W3C. Il comprend des tests conçus pour satisfaire tous les domaines de contrôle, ainsi que les recommandations du W3C Extensible Markup Language (XML), avec un accent particulier sur les exigences de traitement des erreurs dans l'exactitude ou la validité des documents XML. Ainsi, le pourcentage de cas de test réussis est utilisé comme métrique pour évaluer les caractéristiques suivantes de l'analyseur XML en question :

• Point de vue de l'utilisateur.
• 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 la gamme complète des fonctions nécessaires pour l’usage auquel elles sont destinées ?
• Le logiciel fonctionne-t-il de manière fiable pour produire les résultats souhaités lorsqu’il est utilisé correctement ?
• Le programme fonctionne-t-il de manière sûre et fiable en cas de saisie incorrecte ?
• Le produit logiciel est-il facile à utiliser ?
• Le logiciel fonctionne-t-il rapidement ou semble-t-il inutilement lent ?
• Le programme fonctionne-t-il bien avec un autre produit utilisé par l'utilisateur ?

Considérant que les enjeux de qualité sont importants pour l’utilisateur, l’équipe informatique chargée du déploiement et de la maintenance du logiciel peut être confrontée à d’autres problèmes :

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

Les ressources de mauvaise qualité sont celles qui nécessitent plus de mémoire et de puissance de traitement que nécessaire.

L'ISO fournit à ce modèle deux nouvelles catégories de niveau supérieur liées à l'assurance technologique de la qualité des logiciels.

Exigences produit ISO 9126

ISO 9126 est une norme internationale pour l'évaluation des logiciels. Il est divisé en quatre parties, couvrant les thèmes suivants :

• Indicateurs externes.
• Indicateurs internes.
• Modèle de qualité.
• Indicateurs de qualité des logiciels.

La première partie de l'ISO 9126 est une extension de la norme précédente réalisée par McCall (1977), Boehm (1978) et FURPS en définissant un ensemble de caractéristiques de qualité.

• Fonctionnalité.
• Fiabilité.
• Convivialité.
• Maintenabilité.
• Portabilité.

Fonctionnalité du produit

La fonctionnalité est l’objectif principal de tout produit ou service. Plus un produit est utilisé, plus il devient difficile de déterminer sa fonctionnalité. Le logiciel peut avoir une liste de ce qui est disponible.

Certaines caractéristiques logicielles répertoriées (par exemple, la convivialité) ne sont présentes que dans une certaine mesure, c'est-à-dire qu'elles ne sont pas simplement « activées » ou « désactivées ». Beaucoup de gens confondent la fonctionnalité globale d’un processus et celle d’un produit logiciel. Cela est souvent dû au fait que les diagrammes de flux de données (DFD) et autres outils de modélisation peuvent refléter la fonctionnalité d'un processus en tant qu'ensemble de données transformées en données sortantes.

L'ISO 9126-1 et d'autres modèles de qualité ne permettent pas de mesurer les coûts ou les avantages globaux d'un processus, mais examinent uniquement le composant logiciel. La relation entre les fonctionnalités logicielles au sein d'un processus métier global sort du domaine d'application de l'ISO 9126.

Les capacités d'attribut suivantes caractérisent l'utilité du logiciel dans un environnement donné. Chacun d'eux ne peut être mesuré que si les programmes système correspondants sont disponibles.

Une fois qu'un système logiciel est opérationnel, la caractéristique de fiabilité détermine sa capacité à maintenir la fourniture de ses services dans des conditions spécifiées pendant des périodes de temps spécifiées. Un aspect de cette caractéristique est la tolérance aux pannes. Par exemple, si le réseau tombe en panne pendant 20 secondes, le système devrait pouvoir récupérer et continuer à fonctionner.

La capacité d’apprendre à utiliser un système (capacité d’apprentissage) est l’une des principales caractéristiques de l’utilisabilité.

L'efficacité est liée aux ressources système utilisées pour fournir les fonctionnalités requises. L'espace disque, la mémoire et le réseau sont de bons indicateurs d'efficacité. Comme pour un certain nombre d’autres critères, ils se chevauchent. Par exemple, la convivialité d’un système affecte ses performances.

La capacité à identifier et à corriger un bug dans un composant logiciel est ce à quoi fait référence la caractéristique de maintenabilité. Ses indicateurs sont influencés par la lisibilité ou la complexité du code, ainsi que par la modularité. C'est ce qui permet d'identifier la cause du problème afin de pouvoir l'éliminer.

Caractéristiques de maintenabilité :

• Analysabilité - identifie la cause première de l'échec.
• Variabilité - définit l'effort déployé pour modifier le code afin d'éliminer un bug.
• Stabilité - démontre la stabilité du fonctionnement du système lorsque des modifications y sont apportées.
• Testabilité - détermine l'effort nécessaire pour tester le système.
• La portabilité est la capacité d'un système à s'adapter aux changements de son environnement.
• Adaptabilité - La facilité avec laquelle le système s'adapte aux modifications apportées aux spécifications.
• Vitesse d'installation - avec quelle facilité le système peut être installé.
• Remplaçabilité – Facilité avec laquelle un composant du système peut être remplacé.
• Coût de la qualité du logiciel. Elle est très importante. Lorsqu'un développeur décide de tester son produit, il va en réalité consacrer du temps, de l'argent et des efforts à le tester.
• Adéquation - détermine si les fonctions du logiciel répondent aux exigences.
• Précision - établit la mise en œuvre correcte des fonctions.
• Interopérabilité - interagir avec d'autres composants du système.
• Conformité du logiciel aux lois et recommandations nécessaires.
• Assurer la qualité et la sécurité des logiciels et du traitement des transactions de données.
• La fiabilité est la capacité d'un logiciel à fonctionner dans des conditions spécifiées pendant une période de temps spécifiée.
• Maturité - fréquence des pannes logicielles.
• La récupérabilité est l’idée de la capacité d’un système à revenir pleinement opérationnel après une panne.

La portabilité fait référence à la capacité d'un logiciel à s'adapter aux changements de son environnement ou à ses exigences. Les techniques de conception et de mise en œuvre orientées objet peuvent contribuer à déterminer dans quelle mesure ces caractéristiques de qualité logicielle sont présentes dans un système donné.

Coût des processus d'analyse

Le coût de la qualité est calculé en analysant les coûts de conformité et de non-conformité. Le prix du premier indicateur est lié à :

1. Coûts de prévention. Il s’agit du montant dépensé pour garantir que toutes les méthodes sont correctement suivies. Cela comprend les équipes de formation, les revues de code et toute autre activité liée à l’assurance qualité.
2. Frais d’évaluation. Il s'agit du montant d'argent dépensé pour planifier toutes les tâches de test, puis pour les exécuter, comme le développement de cas de test.
3. Coûts de non-conformité. Il s’agit de coûts résultant de défaillances internes et externes.

Les échecs internes sont des coûts qui surviennent lorsque les scénarios de test sont exécutés en interne pour la première fois, avec certains échecs. Des coûts surviennent lorsqu'un programmeur doit corriger tous les défauts identifiés dans sa pièce lors de tests unitaires ou de composants.

Les pannes externes sont des coûts qui surviennent lorsqu'un défaut est installé par le client plutôt que par le testeur. Ces coûts sont bien supérieurs à ceux qui apparaissent en interne. Cela est particulièrement vrai si un problème logiciel s’intensifie.

Analyse de processus disciplinée

Il s'agit d'une évaluation de processus qui implique l'identification et la caractérisation des pratiques actuelles, l'identification des forces et des faiblesses, ainsi que la capacité à contrôler ou à éviter les causes importantes de la mauvaise qualité d'un produit. Les audits de programme peuvent être de trois types :

1. Amour propre. Réalisé au sein du propre personnel de l’organisation.
2. Évaluation par un tiers.
3. Évaluation par un tiers.

L'audit des processus logiciels est effectué dans un environnement ouvert et partagé dans le but d'améliorer les performances des processus et d'utiliser des programmes d'assurance qualité des logiciels. Les résultats d'un tel audit sont confidentiels pour l'organisation.

Concernant la collecte des données, quatre méthodes sont utilisées :

1. Liste de contrôle de maturité standard.
2. Entretiens individuels et collectifs.
3. Revues de documents.

Dans le Dictionnaire explicatif de l'informatique V.I. Perchikov et V.M. Savinkov, le concept de normalisation est défini comme l'adoption d'un accord sur la spécification, la production et l'utilisation du matériel informatique et des logiciels ; établissement et application de standards, normes, règles, etc.

Les normes sont d'une grande importance : elles offrent aux développeurs de logiciels la possibilité d'utiliser des données et des programmes d'autres développeurs et d'exporter/importer des données.

De telles normes régissent l'interaction entre les différents programmes. Pour cela, des normes d'interface interprogrammes sont conçues, par exemple OLE (Object Linking and Embedding - liaison et incorporation d'objets). Sans ces normes, les produits logiciels seraient « fermés » les uns aux autres.

Les normes jouent un rôle de plus en plus important dans le développement de l'industrie des technologies de l'information. Plus de 250 sous-comités au sein d'organismes de normalisation formels travaillent sur les normes des technologies de l'information. Plus de 1 000 normes ont déjà été adoptées par ces organisations ou sont en cours d'élaboration. Le processus de normalisation des technologies de l'information est loin d'être terminé (oui, à notre avis, il est peu probable qu'il soit jamais achevé, car le domaine des technologies de l'information se développe constamment de manière dynamique).

Toutes les sociétés de développement doivent garantir un niveau de qualité acceptable pour les logiciels qu’elles produisent. À ces fins, des normes de qualité logicielle ou des sections distinctes des normes de développement logiciel consacrées aux exigences de qualité logicielle sont prévues.

Du point de vue de l'utilisateur, toute la diversité des logiciels doit être gérée de manière uniforme. Il doit y avoir une navigation uniforme - un mouvement dans le programme, des contrôles logiciels uniformes et une réaction uniforme du logiciel aux actions de l'utilisateur. À cette fin, des normes ont été développées pour l'interface utilisateur - GUI (Graphical User Interface). Tout cela est réglementé par les normes en vigueur dans le domaine informatique.

La nécessité de normaliser le développement de logiciels est mieux décrite dans l'introduction à la norme ISO/IEC 12207 : "Les logiciels font partie intégrante des technologies de l'information et des systèmes traditionnels tels que les transports, l'armée, la médecine et les finances. Il existe de nombreuses normes, procédures, méthodes, outils outils et types d'environnements d'exploitation pour le développement et la gestion de logiciels. Cette diversité crée des difficultés dans la conception et la gestion de logiciels, en particulier lors de la combinaison de produits et de services logiciels. La stratégie de développement logiciel nécessite de passer de cette diversité à un ordre commun qui permettra aux praticiens du logiciel, "parlez le même langage" lors du développement et de la gestion de logiciels. La présente Norme internationale fournit un tel cadre commun.

Essayons de mettre de l'ordre dans la variété des normes en vigueur dans le domaine informatique et de les classer (Fig. 1.3).

Comme vous pouvez le constater, la partie supérieure de la classification ressemble aux types de normes indiqués ci-dessus. Cependant, il y a aussi quelques particularités ici. Cela s'applique principalement aux normes « de jure » et « de facto ». Définissons immédiatement ces concepts.

Une norme de facto est un terme désignant le produit d'un fournisseur qui a conquis une part de marché importante et que d'autres fournisseurs cherchent à imiter, copier ou utiliser pour conquérir leur part de marché.

L’une des principales raisons de l’importance d’un programme de normalisation moderne est la prise de conscience du danger d’une utilisation abusive des normes « de facto ». Dans les années 1960 et 1970, la création de standards de fait a placé les utilisateurs à la merci des industriels lorsqu'ils utilisaient des outils de base en informatique et en télécommunications. Un aspect important du travail de normalisation actuel consiste à surmonter cette dépendance grâce à la promotion d'interfaces standard. Pendant longtemps, ces standards ont été SQL (Structured Query Language) et le langage de création de diagrammes de D. Ross SADT (Structured Analysis and Design Technique). Une norme de jure est créée par un organisme de normalisation formellement reconnu. Il est élaboré en suivant les règles du consensus à travers un processus de discussion ouverte auquel chacun a la possibilité de participer. Aucun groupe ne peut agir de manière indépendante pour créer 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 que les fournisseurs ne peuvent pas ou ne veulent pas accepter : cette norme échouera également. Les normes de jure ne peuvent être modifiées sans passer par un processus d’approbation sous le contrôle de l’organisation qui élabore les normes. Les normes OSI (Open Systems Interconnection reference model), Ethernet, POSIX, SQL et la plupart des normes de langage en sont des exemples. A titre d'exemple de transition d'un standard « de facto » vers un standard « de jure », considérons l'histoire du développement et de la standardisation du langage SQL.

Les travaux sur la création du langage SQL ont commencé dans les années 70 du siècle dernier dans les laboratoires de recherche d'IBM. Il est aujourd'hui devenu l'un des standards majeurs dans le domaine des systèmes d'information et a fourni le langage technologique de base pour toute une génération de SGBD basés sur le modèle relationnel. Bien qu'il ait été mis en œuvre commercialement au début des années 1980 pour un petit groupe de produits logiciels seulement, SQL a indéniablement été accepté avec l'adoption des normes ANSI et 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 le langage.

Riz. 1.3. Système de classification des normes des technologies de l'information

Les origines de SQL doivent être attribuées à la naissance du modèle de données relationnelles (décrit dans l'article d'E.F. Codd). Comme aucun langage de type SQL n'est apparu au cours des années suivantes dans les projets de recherche initiés par IBM après la publication d'E.F. Codd, une importance particulière a été accordée à la nécessité de créer des langages d'interface pour le SGBD en cours de création afin de tester les capacités du modèle relationnel. L'histoire du développement du langage SQL est illustrée dans la Fig. 1.4.

Dans les laboratoires de recherche d'IBM au début des années 70 du 20e siècle, parallèlement aux travaux sur le futur langage SQL, d'autres projets se développaient pour créer et mettre en œuvre expérimentalement des langages relationnels. Le plus célèbre d'entre eux est probablement le langage relationnel Query-By-Example (QBE), créé à peu près en même temps que SEQUEL (une première version de SQL) par M. Zloof du laboratoire IBM de Yorktown Heights. Ce langage est actuellement utilisé dans de nombreux produits logiciels commerciaux avec SQL.

En 1974, Donald D. Chamberlin du laboratoire de recherche IBM de San Jose a proposé des spécifications pour un langage relationnel appelé SEQUEL (Structured English QUEry Language). Une version révisée de ce langage (SEQUEL/2) a été développée en 1976-1977 et a acquis son nom définitif - SQL (Structured Query Language).

Même avant que les produits commerciaux IBM n'entrent sur le marché des logiciels au début des années 1980, Relation Software Inc. (maintenant appelé Oracle Corporation) a annoncé la sortie d'un SGBD relationnel basé sur le langage SQL. Ce système, suite à son évolution, est devenu l'un des systèmes commerciaux dominants et s'appelle ORACLE.

Le produit ORACLE avec son langage SQL a été concurrencé dans le domaine des ordinateurs centraux et des mini-ordinateurs par les produits de plusieurs autres développeurs, notamment le SGBD Ingres avec le langage QUEL de Relation Technology Inc., ainsi que le produit Rdb/VMS. avec le langage RDML de Digital Equipment Corporation.

L'une des raisons du succès de SQL a été la formation du comité HZN2 de l'American National Standards Institute (ANSI), créé pour développer des normes de langage de base de données. Un représentant d'IBM a suggéré d'utiliser les résultats des travaux antérieurs d'IBM sur SEQUEL/2 comme spécifications préliminaires pour un langage relationnel, et les développeurs du standard ont commencé à travailler. Le document, intitulé « SQL », était en grande partie un traité sur les différentes formes de SQL utilisées dans les produits logiciels commerciaux.

L'Organisation internationale de normalisation (ISO), par l'intermédiaire du comité technique TC97 (maintenant appelé ISO/IEC JTC1), a également travaillé à la création d'une norme pour les langages de bases de données relationnelles. Au milieu des années 1980, l'ANSI et l'ISO ont approuvé les normes SQL (ANSI en 1986 et ISO au début de 1987).

Le premier standard SQL, en raison de la manière dont il a été développé, était très incomplet en termes de fonctionnalités du système de base de données, et de nombreux fournisseurs ont continué à ajouter un large éventail d'extensions au standard dans leurs produits logiciels. En 1989, une version révisée de la norme SQL a été adoptée, qui différait de la norme de 1986 principalement par sa capacité à prendre en charge l'intégrité référentielle.

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

Ajoutant à la confusion, les travaux sur SQL2 ont chevauché les travaux sur SQL3, une nouvelle version du standard SQL encore en cours de développement. Les travaux sur SQL3 ont commencé en 1990 en parallèle avec SQL2, principalement comme « réservoir de rechange » pour des fonctionnalités qui n'étaient pas destinées à être incluses dans SQL2 pour une raison ou une autre. SQL3 inclut des extensions de langage orienté objet, ainsi que des fonctionnalités relationnelles supplémentaires introuvables dans SQL2.

Illustrons sur la Fig. 1.5 processus basé sur le temps pour développer diverses normes SQL.

Il convient de noter que dans le domaine des technologies de l’information, il existe deux approches historiques principales en matière d’élaboration de normes. La première est lorsqu’un problème se profile : la nécessité d’une norme. Dans ce cas, un groupe d'experts se réunit dans une section des technologies de l'information et discute des solutions locales inventées par des éditeurs de logiciels individuels et des organisations scientifiques, analyse ces solutions et développe une norme intégrée unique qui inclut les meilleures idées et développements.

Mais le marché vit selon des lois légèrement différentes. La première approche est inerte, le problème a déjà mûri, il doit être résolu et on ne sait pas quand les experts rassembleront et élaboreront la norme nécessaire. Deuxièmement, les sociétés de développement de logiciels développent chacune leur propre solution, et la solution la plus populaire et la plus répandue en termes de fréquence d'utilisation acquiert le statut de standard (pas nécessairement légalement). Ainsi, SQL est devenu le langage standard pour accéder aux bases de données, appelé « de facto », bien que plus tard le statut de la norme ait été légalement garanti.

L’inconvénient de cette approche est que ce n’est pas la solution commerciale la plus solide, mais la plus répandue qui devient la norme.

Un autre exemple de l'émergence d'un standard est l'émergence du désormais populaire UML - Unified Modeling Language. Des développements majeurs dans les méthodes d’analyse et de conception orientées objet sont apparus entre 1988 et 1992. En 1994, un grand nombre de dirigeants informels de développeurs en exercice (environ une douzaine et demie) faisaient la promotion de leurs méthodologies. Toutes leurs méthodes étaient similaires, mais les différences entre elles concernaient souvent des détails mineurs. Une conversation sur la normalisation se préparait. L'équipe d'OMG a tenté de résoudre le problème de la normalisation, mais a reçu une lettre ouverte de protestation de la part de tous les auteurs. En 1996, trois experts de premier plan dans le domaine de l'analyse et de la conception orientées objet, James Rumbaugh, Grady Booch et Ivar Jacobson, se sont associés et la méthode unifiée version 0.8 est née en 1996. "Trois amis" ont travaillé sur leur méthode. , qui s'appelait Unified Modeling Language. En janvier 1997, diverses organisations ont présenté leurs propositions de standardisation des méthodes, prévoyant principalement la possibilité d'échanger des informations entre différents modèles. En conséquence, il n’existe désormais qu’une seule proposition : la norme UML.

Le concept de « qualité logicielle ».

Les méthodes d'ingénierie en programmation sont basées sur l'idée d'améliorer la qualité des logiciels, pour la mise en œuvre de quelles méthodes de détermination des exigences de qualité des logiciels, d'approches de sélection et d'amélioration de modèles pour l'analyse métrique des indicateurs de qualité des logiciels et de méthodes de mesure quantitative des indicateurs de qualité à les étapes du cycle de vie du logiciel ont été formées.

Qualité du logiciel- il s'agit d'un ensemble de propriétés qui déterminent l'utilité d'un produit (programme) pour les utilisateurs conformément à l'objectif fonctionnel et aux exigences. Dans le même temps, les exigences peuvent être interprétées de manière assez large, ce qui donne lieu à un certain nombre de définitions indépendantes de la notion de « qualité ». La définition la plus couramment utilisée est la norme ISO 9001, selon laquelle la qualité est « le degré dans lequel les caractéristiques inhérentes répondent aux exigences ». La qualité logicielle est une notion relative qui n’a de sens que lorsqu’elle prend en compte les conditions réelles d’utilisation des logiciels. Par conséquent, les exigences en matière de qualité des logiciels sont définies en fonction des conditions et du domaine d'application spécifique du logiciel.

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

Premier niveau correspond à la définition de caractéristiques (indicateurs) de qualité logicielle, dont chacune reflète un point de vue distinct de l'utilisateur sur la qualité. Selon les normes GOST R ISO/IEC 9126-93, GOST R ISO/IEC 12119-2000, GOST 28195-89, le modèle qualité comprend six caractéristiques, ou six indicateurs de qualité principaux, que nous listons par ordre d'importance pour la plupart. utilisateurs:

• Fonctionnalité;
• fiabilité fonctionnelle;
• facilité d'utilisation;
• efficacité;
• accompagnement;
• portabilité.

Deuxième niveau. Ce niveau correspond à des attributs pour chaque caractéristique de qualité, qui détaillent différents aspects d'une caractéristique particulière. Un ensemble d'attributs de caractéristiques de qualité est utilisé dans l'évaluation de la qualité.

Considérons les 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 à exécuter les fonctions prévues dans un environnement donné conformément aux exigences spécifiées. Sous fonction fait référence à une certaine séquence ordonnée d'actions pour satisfaire les propriétés du consommateur. Il y a des fonctions ciblé (basique) Et auxiliaire.

Les attributs de fonctionnalité incluent :

• sécurité- un attribut qui montre la capacité du logiciel à empêcher tout accès non autorisé (accidentel ou intentionnel) aux programmes et aux données ;
• interopérabilité- un attribut qui montre la capacité de ce logiciel à interagir avec des systèmes et environnements particuliers (systèmes d'exploitation, réseaux informatiques) ;
• exhaustivité fonctionnelle- un attribut qui montre l'adéquation des fonctions de base pour résoudre des problèmes conformément à l'objectif de ce logiciel.

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

• infaillibilité- un attribut qui détermine la capacité du logiciel à fonctionner sans erreurs ;
• droite- un attribut qui montre la mesure de l'obtention de résultats corrects ;
• contrôlabilité- un attribut qui caractérise l'exhaustivité et l'efficacité de la détection des erreurs dans les résultats intermédiaires et de sortie
• tolérance aux erreurs- un attribut qui caractérise la capacité du logiciel à exécuter correctement des fonctions dans des conditions anormales (panne matérielle, erreurs dans les données et les interfaces, etc.) ;
• fiabilité- un attribut qui caractérise la capacité du logiciel à ne pas provoquer de défaillances fonctionnelles du système d'information ;
• aptitude à la restauration- un attribut qui caractérise la capacité du programme à éliminer une erreur logicielle et à redémarrer pour réexécuter et restaurer les données en cas de panne fonctionnelle ;
• préparation- un attribut qui montre la capacité d'un programme à effectuer avec précision la transformation requise sur une requête arbitraire.

La convivialité est caractérisée par une variété d'attributs qui indiquent les conditions nécessaires et appropriées pour l'utilisation du logiciel par un groupe donné d'utilisateurs afin d'obtenir des résultats appropriés. La norme définit la convivialité comme un ensemble spécifique d'attributs d'un produit logiciel qui caractérisent son ergonomie.

Riz. 3.1.

Les attributs d'utilisabilité incluent :

• compréhensibilité- un attribut qui détermine l'effort consacré à la reconnaissance des concepts logiques et des conditions d'utilisation du logiciel ;
• étudiabilité(facilité d'apprentissage) - un attribut qui définit les efforts des utilisateurs visant à déterminer l'applicabilité du logiciel grâce à l'utilisation de contrôles opérationnels, de diagnostics, ainsi que de procédures, de règles et de documentation ;
• efficacité- un attribut qui montre la réaction du système lors de l'exécution d'opérations et du contrôle opérationnel.

L'efficacité est un ensemble d'attributs qui déterminent la relation entre les niveaux d'exécution du logiciel, l'utilisation des ressources (installations, équipements, matériaux - papier pour un périphérique d'impression, etc.) et les services fournis par le personnel de maintenance régulier, etc.

Les attributs de performances du logiciel incluent :

• réactivité- un attribut qui montre le temps de réponse, le traitement et l'exécution des fonctions ;
• efficacité des ressources- un attribut indiquant la quantité et la durée des ressources utilisées lors de l'exécution des fonctions logicielles ;
• cohérence- un attribut qui montre la conformité d'une caractéristique donnée aux normes, règles et réglementations spécifiées.

La maintenabilité est un ensemble de propriétés qui caractérisent les efforts qui doivent être déployés pour effectuer des modifications, y compris des ajustements, des améliorations et des adaptations d'un logiciel lorsque l'environnement, les exigences ou les spécifications fonctionnelles changent.

La maintenabilité comprend les attributs suivants :

• analysabilité- un attribut définissant l'effort nécessaire pour diagnostiquer les pannes ou identifier les pièces qui seront modifiées ;
• la stabilité- un attribut indiquant la constance de la structure et le risque de sa modification ;
• testabilité- un attribut indiquant l'effort lors de la validation et de la vérification pour détecter la non-conformité aux exigences, ainsi que la nécessité de modification et de certification du logiciel ;
• changeabilité- un attribut qui détermine la possibilité de supprimer les erreurs dans le logiciel ou d'apporter des modifications pour les éliminer, ainsi que d'introduire de nouvelles fonctionnalités dans le logiciel ou l'environnement d'exploitation.

La portabilité est un ensemble d'indicateurs qui indiquent la capacité d'un logiciel à s'adapter au travail dans les nouvelles conditions de l'environnement d'exécution. L'environnement peut être organisationnel, matériel et logiciel. Ainsi, le transfert d'un logiciel vers un nouvel environnement d'exécution peut être associé à un ensemble d'actions visant à assurer son fonctionnement dans un environnement différent de celui dans lequel il a été créé, compte tenu des nouvelles capacités logicielles, organisationnelles et techniques.

La portabilité inclut les attributs suivants :

• adaptabilité- un attribut qui détermine l'effort consacré à l'adaptation à différents environnements ;
• personnalisation(facilité d'installation) - un attribut qui détermine l'effort requis pour exécuter ce logiciel dans un environnement spécial ;
• coexistence- un attribut qui détermine la possibilité d'utiliser un logiciel spécial dans l'environnement du système d'exploitation ;
• remplaçabilité- un attribut qui caractérise la capacité à transférer un logiciel d'un environnement outil à un autre avec l'installation ou l'adaptation nécessaire du logiciel.

Troisième niveau conçu pour mesurer la qualité à l'aide métrique, dont chacun est défini comme une combinaison d’une méthode de mesure des attributs et d’une échelle pour mesurer les valeurs des attributs. Pour évaluer les attributs de qualité aux étapes du cycle de vie (lors de la visualisation de la documentation, des programmes et des résultats des tests de programmes), des métriques avec un poids d'évaluation donné sont utilisées pour niveler les résultats d'une analyse métrique des attributs globaux d'un indicateur spécifique et de la qualité comme un ensemble. L'attribut qualité est déterminé à l'aide d'une ou plusieurs techniques d'évaluation aux étapes du cycle de vie et au stade final du développement du logiciel.

Quatrième niveau est un élément métrique évaluatif (poids) utilisé pour évaluer la valeur quantitative ou qualitative d'un attribut distinct d'un indicateur de qualité logicielle. En fonction de l'objectif, des caractéristiques et des conditions du support logiciel, les caractéristiques de 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 de développement du système, ou les priorités correspondantes de la norme de classe de logiciel à laquelle appartient ce logiciel sont utilisées.