Exercices de génie logiciel-part01-Vue d'ensemble du génie logiciel et processus logiciel

Présentation du cours

Le cours "Génie logiciel" est le cours de base de la majeure en génie logiciel. Il s'agit d'un cours complet qui utilise des méthodes d'ingénierie pour guider le développement, la maintenance et la gestion de logiciels. Le contenu implique la théorie et la technologie liées à l'analyse, la conception, la mise en œuvre, maintenance et gestion de projet. , méthodes et outils CASE.

Programme d'examen

⚫Génie logiciel 重点掌握et 基本概念; 基本原理⚫Basé
sur les besoins actuels des éditeurs de logiciels chinois en matière de développement de logiciels, maîtriser et être capable de 运用génie logiciel, 基本原理pratique 软件开发技术et de base 管理技术;
⚫Discipline 了解du génie logiciel 知识结构.

⚫(1) Concepts de génie logiciel et éléments de base du génie logiciel
⚫(2) Processus logiciel
⚫(3) Exigences logicielles et spécifications des exigences logicielles
⚫(4) Spécifications système et conception logicielle
⚫(5) Tests logiciels
⚫(6) Génie logiciel Management⚫
(7) Qualité du logiciel, caractéristiques de qualité et assurance qualité du logiciel⚫
(8) Génie logiciel assisté par ordinateur Outils et environnement CASE

Concepts de génie logiciel et éléments de base du génie logiciel

modèle de cascade

Modèle de produit logiciel :

Modèle de processus logiciel :

Le modèle de processus logiciel est traditionnellement également appelé modèle de développement logiciel, qui est le cadre structurel de l'ensemble du processus, des activités et des tâches de développement logiciel. Les processus logiciels typiques incluent le modèle en cascade, le modèle incrémental, le modèle d'évolution (modèle prototype, modèle en spirale), le modèle de fontaine, le modèle de développement basé sur les composants et le modèle de méthode formelle, etc.

Modèle de projet logiciel :
Modèle de test logiciel :

Modèle V Modèle W Modèle X Modèle H Modèle Agile

Éléments de qualité du logiciel de support CMM

CMM estime que les éléments soutenant la qualité du logiciel comprennent trois aspects : processus, produit et personnel.
Produit, processus et personnes
Par exemple,
le processus exige que les développeurs développent des logiciels conformément au processus établi,
le produit exige que les développeurs produisent des produits conformes aux spécifications
et le personnel exige que les développeurs aient des compétences et une expérience suffisantes.
La combinaison organique de ces éléments peut assurer la haute qualité du logiciel.

La qualité du génie logiciel dépend principalement de trois facteurs : les méthodes, les outils et les processus, appelés les trois éléments du génie logiciel.
La méthode est une méthode technique pour effectuer diverses tâches de développement de logiciels et fournit une technologie "comment faire" pour le développement de logiciels.
Un outil est un environnement d'aide au génie logiciel automatique ou semi-automatique prévu pour l'application d'une méthode.
Le processus est le cadre d'une série de tâches qui doivent être accomplies afin d'obtenir un logiciel de haute qualité. Il spécifie les étapes de travail pour accomplir chaque tâche, comment combiner les méthodes d'ingénierie logicielle avec des outils logiciels et développer des logiciels de manière raisonnable et opportune. .

Une déclaration sur le modèle de développement incrémental

En intégrant les composants de base du modèle en cascade et les fonctionnalités itératives de la mise en œuvre du prototype, plusieurs versions disponibles peuvent être publiées et les fonctions de base sont souvent terminées en premier. Sur cette base, il y aura de nouvelles versions incrémentielles à chaque cycle d'itérations, et le les fonctions de base peuvent être obtenues.Entièrement testé. Insistez sur le fait que chaque incrément libère un produit opérationnel.
Variante du modèle en cascade, le modèle incrémental présente tous les avantages du modèle en cascade. De plus, il présente les avantages suivants :

Le coût et le temps requis pour la première version livrable sont faibles ; le risque pris pour développer un petit système représenté par un incrément est faible ;
parce que la première version est publiée rapidement, il y a moins de changements dans les besoins des utilisateurs ; Investissement quantitatif, c'est-à-dire au début du projet, vous ne pouvez investir que sur une ou deux tranches.

Le modèle incrémental présente les inconvénients suivants :

S'il n'y a pas de planification pour les exigences de changement de l'utilisateur, l'incrément initial peut entraîner l'instabilité de l'incrément suivant ;
si les exigences ne sont pas aussi stables et complètes que la pensée initiale, alors certains incréments peuvent devoir être redéveloppés et réédités ;
La gestion des complexités liées aux coûts, au calendrier et à la configuration peut dépasser les capacités de l'organisation.

La description incorrecte du modèle de processus logiciel donne l'impression qu'il devrait être B

La différence entre le modèle cascade et le modèle fontaine

Activités de génie logiciel :

Modèle en cascade : il stipule diverses activités d'ingénierie logicielle et leur séquence fixe de connexion descendante et mutuelle, tout comme une cascade d'eau tombant étape par étape. Étude de faisabilité, analyse des besoins, conception globale, conception détaillée, codage, système de test unitaire, acceptation des tests, fonctionnement et maintenance des tests,

modèle de fontaine : le modèle de fontaine est principalement utilisé pour décrire le processus de développement orienté objet, et le mot "fontaine" reflète le processus itératif et transparent de la fonction de développement orienté objet. L'itération signifie que les activités de développement dans le modèle doivent souvent être répétées plusieurs fois, chaque répétition ajoutant ou clarifiant certaines propriétés du système cible, mais ne modifiant pas substantiellement les résultats des travaux précédents. Implicite ininterrompu signifie qu'il n'y a pas de frontière claire entre les activités de développement (telles que l'analyse, la conception, la programmation), mais que chaque activité de développement est autorisée à se croiser et à se poursuivre de manière itérative.

Modèle de développement logiciel :

Tout d'abord, il existe plusieurs classifications principales des modèles de développement : modèle prototype, modèle structuré, modèle orienté objet, modèle de Jackson, etc. Ce sont des concepts de classification vagues sans normes de division claires.
Il est important de pouvoir faire la distinction entre le modèle prototype et le modèle structuré, car les deux sont complémentaires, et d'autres n'ont besoin que de saisir leurs spécificités, je ne rentrerai donc pas dans les détails ici.

Référence : https://blog.csdn.net/Biu_Destiny/article/details/116893974

Les processus de base du cycle de vie comprennent

Les activités pouvant être réalisées au cours du cycle de vie du logiciel sont divisées en

Il existe des processus de base 5,
des processus de support 9
et des processus organisationnels 7.
Chaque processus de cycle de vie est divisé en un groupe d'activités et chaque activité est ensuite divisée en un groupe de tâches.

Processus de base
Activités directement liées à la production
1. Processus d'acquisition : activités définies pour la demande, démarrage, appel d'offres, contrat, supervision des fournisseurs, acceptation, etc. ; 2. Processus d'approvisionnement
 : activités définies pour le fournisseur, démarrage , préparation Appel d'offres, signature du contrat, planification, exécution, livraison et achèvement
3. Processus de développement : activités définies pour le développeur : exigences, conception, codage, test, installation, acceptation 4.
Processus d'exploitation : défini pour l'opérateur Activités : test 5. Processus
de maintenance : activités définies pour la partie maintenance : analyse des problèmes et des modifications, mise en œuvre des modifications, revue/acceptation de la maintenance, migration, démantèlement du logiciel processus d'assistance
processus

d'organisation

À quel niveau de CMMI appartient la préparation du budget et de l'échéancier ?

La modification des budgets et des calendriers est une pratique dédiée du domaine de processus « Planification de projet » de niveau géré CMMI√

Définition des cinq niveaux de CMM

1) Niveau initial (initial) : Parfois, il y aura confusion dans le processus de développement logiciel, seuls quelques processus de travail sont strictement définis et le succès du développement dépend souvent de la sagesse et des efforts d'une certaine personne.
2) Niveau répétable (Répétable) : Le processus de gestion de projet de base a été établi. Concevez les fonctionnalités étape par étape, suivez les coûts et développez en fonction des calendriers du projet. Pour des projets similaires, les pièces qui ont été développées avec succès auparavant peuvent être réutilisées.
3) Niveau défini (défini) : les activités d'ingénierie et les activités de gestion du développement de logiciels sont documentées et normalisées, et elles sont intégrées dans le processus de développement standard d'une organisation. Le développement et la maintenance de tous les projets sont personnalisés sur la base de cette norme.
4) Niveau géré (géré) : le processus de développement logiciel et les détails des tests de qualité du produit sont bien résumés, et le produit et le processus de développement peuvent être décomposés et contrôlés quantitativement.
5) Niveau d'optimisation (Optimisation) : grâce à la mise en place d'un mécanisme de rétroaction quantitatif dans le processus de développement, de nouvelles idées sont constamment générées et de nouvelles technologies sont utilisées pour optimiser le processus de développement.

Reportez-vous aux éléments suivants dans cet article : Expansion 4.CMMI

Technologies non utilisées par RUP

Référence : Unified Software Development Process (RUP)
RUP est le processus de développement unifié de Rational Unified Process.Les technologies utilisées sont :

Le RUP itératif et incrémentiel basé sur des cas d'utilisation
est un cadre de processus logiciel basé sur des cas d'utilisation, centré sur l'architecture, itératif et incrémentiel qui fournit une fonctionnalité évolutive.

Les techniques non utilisées sont :

Développement piloté par les
tests Développement piloté par les tests, nom complet en anglais Le développement piloté par les tests, appelé TDD, est une nouvelle méthode de développement différente du processus de développement logiciel traditionnel. Cela nécessite d'écrire le code de test avant d'écrire le code d'une certaine fonction, puis d'écrire uniquement le code de la fonction qui fait passer le test et de promouvoir l'ensemble du développement à travers le test. Cela aide à écrire un code propre, utilisable et de haute qualité et accélère le processus de développement.

qu'est-ce qu'un logiciel

Le logiciel est l'objet de recherche du génie logiciel, et c'est aussi la forme du produit et l'existence objective du génie logiciel.
L'ingénierie est la science qui consiste à appliquer la théorie et la technologie à la pratique, dans le but de résoudre des problèmes pratiques de manière rentable.

Logiciel = programme + données + document

Programme : un ordinateur qui accepte une séquence d'instructions qui, lorsqu'elles sont exécutées, fournissent les fonctionnalités et les performances requises.
Données : une structure de données qui permet à un programme de manipuler les informations de manière appropriée.
Documentation : éléments graphiques décrivant le processus de développement, les méthodes et l'utilisation du programme.

Le logiciel a de la complexité, de la cohérence, de la variabilité et de l'invisibilité, etc.

Qu'est-ce que CMMI, et dans l'expression continue CMMI, en quels niveaux les niveaux de capacité sont-ils divisés ?

Le nom complet de CMMI est Capability Maturity Model Integration, c'est-à-dire Capability Maturity Model Integration. CMMI est la dernière version du modèle CMM.
Le nom complet de CMMI est Capability Maturity Model Integration. Il existe cinq niveaux de certification CMMI :
CMMI niveau 1, niveau achèvement ; CMMI niveau 2, niveau gestion ; CMMI niveau 3, niveau définition ; CMMI niveau 4, niveau gestion quantitative ; niveau CMMI 5, niveau d'optimisation.

Dans les modèles CMMI, pour prendre en charge l'utilisation de la représentation continue, tous les modèles CMMI reflètent les niveaux de capacité dans leur conception et leur contenu . Les quatre niveaux de capacité du CMMI sont désignés du niveau 0 au niveau 3, et chaque niveau est un niveau qui sert de base à l'amélioration continue des processus.

Niveau CMMI 0. Niveau incomplet Niveau
CMMI 1. Niveau exécuté Niveau
CMMI 2. Niveau géré Niveau
CMMI 3. Niveau défini Niveau
CMMI 4. Niveau gestion quantitative Niveau
CMMI 5. Niveau optimisation

Le CMMI basé sur l'expression continue a un total de 6 (0-5) niveaux de capacité, correspondant au niveau inachevé, au niveau exécuté, au niveau géré, au niveau défini, au niveau de gestion quantifié et au niveau optimisé. Chaque niveau de capacité correspond à un objectif général et à un ensemble de moyens généraux et spécifiques de mise en œuvre. Le niveau de capacité 0 signifie que le processus n'est pas exécuté, ce qui indique qu'un ou plusieurs objectifs spécifiques du domaine de processus n'ont pas été atteints ; le niveau de capacité 1 signifie que le processus produit des produits d'activité sortants identifiables en transformant des produits d'activité entrants identifiables, en se concentrant sur les objectifs du domaine de processus Achèvement des objectifs ; le niveau de capacité 2 fait référence à l'institutionnalisation du processus en tant que processus géré, ciblant la capacité d'une instance de processus unique ; le niveau de capacité 3 fait référence à l'institutionnalisation du processus en tant que processus défini, en se concentrant sur la normalisation et le déploiement du processus au niveau de l'organisation ; le niveau de capacité 4 fait référence à Le processus est institutionnalisé en tant que processus de gestion quantitatif ; le niveau de capacité 5 fait référence au processus en tant que processus optimisé institutionnalisé, indiquant que le processus est bien exécuté et continuellement amélioré .

Qu'est-ce qu'un logiciel open source, avec des exemples

Le soi-disant open source, "source" fait référence à son code source, open source signifie que l'auteur du logiciel fournit le code source à l'utilisateur gratuitement, et oblige l'utilisateur à suivre certaines spécifications open source. Par exemple, Linux est un logiciel open source

Concevoir 6 flux de travail d'ingénierie de base et 3 flux de travail de support de base dans chaque cycle d'itération de RUP, décrire les noms et les principaux objectifs des 6 flux de travail de base

Référence : Compréhension approfondie des 6 workflows de processus de base et des 3 workflows de support de base du modèle de développement bidimensionnel itératif.

modélisation métier modélisation métier : la modélisation métier décrit comment développer une vision pour une nouvelle organisation cible et, sur la base de cette vision, définir les rôles et les responsabilités du processus de l'organisation dans un modèle de cas d'utilisation métier et un modèle d'objet métier analyse des exigences exigences : objectifs du flux de travail des exigences Il
est une description de ce que le système devrait faire, et les développeurs et les utilisateurs ne sont pas parvenus à un consensus sur cette description. Pour atteindre cet objectif, la fonctionnalité et les contraintes des exigences sont extraites, organisées et documentées ; plus important encore, la définition et la portée du problème à résoudre par le système sont comprises.Définir les fonctions du système et l'interface utilisateur, le résultat principal de ce flux de travail est la spécification des exigences logicielles.
Analyse et conception Analyse et conception : le flux de travail d'analyse et de conception consiste à transformer les exigences en conception du futur système, à développer une structure robuste pour le système et à ajuster la conception pour faire correspondre le reste de l'environnement de mise en œuvre et optimiser ses performances. Les résultats de conception d'analyse sont un modèle de conception et un modèle d'analyse facultatif.
Implémentation : Le but de l'implémentation du workflow est de définir la structure organisationnelle du code sous forme de sous-systèmes hiérarchisés, d'implémenter des classes et des objets, de mener des tests unitaires sur les composants développés, et d'intégrer les composants d'un seul développeur pour en faire un exécutable système.Définir la structure organisationnelle du code, implémenter le code, les tests unitaires et l'intégration du système.
Test Test : après avoir terminé le développement de la capture des exigences, de l'analyse, de la conception, de la mise en œuvre et d'autres étapes, et obtenu le code source, il est nécessaire de commencer à rechercher d'éventuelles erreurs et défauts dans le produit logiciel.Vérifiez que toutes les exigences sont correctement mises en œuvre, en vous assurant que toutes les erreurs et tous les défauts sont détectés avant la publication.
Déploiement : Le but est de générer une version et de distribuer le logiciel aux utilisateurs finaux. Le flux de travail de déploiement décrit : l'empaquetage du logiciel, la production de produits autres que le logiciel lui-même, l'installation du logiciel et l'assistance aux utilisateurs.

Gestion de la configuration et des modifications : le workflow de gestion de la configuration et des modifications décrit comment contrôler un grand nombre d'artefacts dans un projet multi-membres. Les workflows de configuration et de modification fournissent des directives pour gérer plusieurs traversées dans un système en évolution, après plusieurs versions du processus logiciel. Workflow décrit comment développer en parallèle, le développement distribué et comment créer automatiquement des projets. Dans le même temps, il explique également la raison, l'heure et le personnel de la modification du produit pour conserver les enregistrements d'audit.

Gestion de projet : les objectifs comprennent la fourniture d'un cadre pour la gestion de projet et des directives pour la planification, la dotation en personnel et l'exécution.

Environnement : l'objectif du workflow d'environnement est de fournir un environnement de développement logiciel, y compris des processus et des outils, à une organisation de développement logiciel.

Les activités pouvant être effectuées dans le cycle de vie du logiciel sont divisées en 5 processus de base, quels sont les 5 processus de base et à quel côté du projet logiciel chaque processus de base est lié.

5 processus de base :

1. Processus d'acquisition : activités définies pour la demande, démarrage, appel d'offres, contrat, supervision du fournisseur, acceptation, etc. 2.
Processus d'approvisionnement : activités définies pour le fournisseur, démarrage, préparation des offres, signature des contrats, préparation des plans, Exécution, livraison et réalisation
3. Processus de développement : activités définies pour le développeur : exigences, conception, codage, tests, installation, réception
4. Processus d'exploitation : activités définies pour l'opérateur : exécution des tests, exploitation du système, support aux utilisateurs
5. Processus de maintenance : activités définies pour la partie maintenance : analyse des problèmes et des modifications, mise en œuvre des modifications, revue/acceptation de la maintenance, migration, démantèlement du logiciel

9 processus supports :

1. Processus de documentation
2. Processus de gestion de la configuration
3. Processus d'assurance qualité
4. Processus de vérification : processus permettant de déterminer si les produits logiciels satisfont aux exigences et aux conditions qui leur ont été imposées lors des activités précédentes.
Vérification du contrat, vérification des processus, vérification des exigences, vérification de la conception, vérification du codage, vérification de l'intégration, vérification des documents Ce processus comprend les tâches suivantes :

1. Préparer les exigences de test, les cas de test et les spécifications de test sélectionnés pour l'analyse des résultats de test
2. S'assurer que ces exigences de test, cas de test et spécifications de test reflètent les exigences spécifiques pour une utilisation particulière prévue
3. Les tests incluent la force, la limite et l'exception test d'entrée

6. Processus d'examen conjoint : évaluer l'état et les produits d'une activité d'un projet, examen de gestion de projet, examen technique
7. Processus d'examen : déterminer la conformité aux exigences, plans et contrats, selon le cas
8. Processus de résolution de problèmes
9. Processus d'utilisabilité

7 Processus organisationnels

1. Processus de gestion : les activités de base définies pour la gestion dans le processus du cycle de vie, y compris la gestion de projet
2. Processus d'infrastructure : les activités de base définies pour établir l'infrastructure du processus du cycle de vie
3. Processus d'amélioration
4. Processus de ressources humaines
5. Processus de gestion des actifs
6 Processus de gestion du programme de réutilisation : activités définies pour le directeur du programme de réutilisation de l'organisation, initiation, évaluation du domaine, évaluation de la réutilisation, planification, exécution et contrôle, examen et évaluation 7. Processus d'ingénierie du domaine : activités et tâches des ingénieurs du domaine, analyse du domaine, conception du
domaine , provisionnement d'actifs, maintenance d'actifs

développer

1. Décrivez brièvement les différences conceptuelles entre le processus logiciel, le cycle de vie du logiciel et le modèle de processus logiciel (modèle de cycle de vie du logiciel).

Processus logiciel : est l'activité impliquée dans une série de processus connexes dans le cycle de vie du logiciel. Un processus est un ensemble d'activités ; une activité est un ensemble de tâches ; une tâche est une opération qui transforme une entrée en une sortie.
Cycle de vie du logiciel : le processus d'un logiciel de sa naissance à sa mort. Il peut être divisé en trois cycles de définition, de développement et d'exploitation, comprenant les étapes d'analyse de faisabilité, de planification de projet, d'analyse de la demande, de conception de logiciels, de codage et de test, d'exploitation et de maintenance.
Modèle de processus logiciel : il s'agit d'une représentation abstraite d'un processus logiciel ; il exprime un processus d'un point de vue spécifique et utilise généralement des graphiques intuitifs pour représenter le processus complexe de développement logiciel. Le modèle de processus logiciel est principalement établi en fonction de divers facteurs tels que le type et l'échelle du logiciel, en particulier la méthode de développement logiciel et l'environnement de développement.

Différence :
le cycle de vie du logiciel est un processus, le corps principal est le logiciel ;
le processus logiciel est le processus depuis la naissance du logiciel et son cycle de vie, et c'est une série d'activités impliquées dans ce processus ; le
modèle de processus logiciel est le série d'activités (représentation abstraite d'un processus logiciel).

2. Le processus logiciel est-il le processus de développement logiciel ? Pourquoi?

Non. Le processus de développement logiciel n'est qu'une étape du processus logiciel. Le processus logiciel est divisé en trois catégories selon l'organisme principal qui entreprend le travail de développement logiciel : processus de base, processus de support et processus d'organisation. Le processus de base est divisé en processus d'acquisition. , processus d'approvisionnement et processus d'approvisionnement en fonction de différents sujets dans le processus.Processus, processus de développement, processus d'exploitation, processus de maintenance, de sorte que le processus de développement logiciel n'est qu'une partie du processus de développement logiciel.

3. Modèle de test logiciel

Référence : https://blog.csdn.net/WeirdoGiraffe/article/details/124883325
Comme le modèle de développement, les tests logiciels peuvent adopter différentes Le modèle de test implémente des activités de test pour guider l'organisation des activités de test logiciel.
Modèles courants dans l'industrie :

1. Modèle V
2. Modèle W (modèle double V)
3. Modèle X
4. Modèle H
5. Modèle Agile

Modèle V

Le modèle V est le modèle le plus connu de tous les modèles de test de logiciels. Il s'agit d'un modèle de test dérivé du modèle de R&D en cascade, comme le montre la figure.

Le processus du modèle en V est de haut en bas, de gauche à droite
① Les ingénieurs de test effectuent des tests unitaires sur les fonctions de code générées pendant le processus de programmation du personnel de R&D
② Les tests d'intégration sont effectués après la réussite des tests unitaires
③ Les tests système et l'acceptation sont effectués après la réussite des tests d'intégration test

Inconvénients du modèle V :

Les défauts au début du projet sont découverts plus tard

Modèle W

Le modèle W est développé sur la base du modèle V, et est généralement appelé le modèle double V. Dans le modèle V, lorsque les activités de R&D ne sont pas terminées et qu'il n'y a pas de sortie, les ingénieurs de test ne peuvent pas effectuer le travail de test, relativement parlant, les activités de test sont sérieusement en retard. Afin de pallier les lacunes du modèle V, le modèle W met en avant le concept d'activités de test parallèles et d'activités de R&D, et augmente les activités de vérification et de confirmation au cours de l'évolution du processus de production.

Le modèle W commence par les exigences de l'utilisateur. L'équipe R&D mène des activités telles que l'analyse des exigences, la conception des grandes lignes, la conception détaillée et le développement du codage en fonction des exigences de l'utilisateur. L'équipe de test effectue des tests d'acceptation, des tests système, des tests d'intégration et des tests unitaires basés sur la conception. sur les besoins des utilisateurs. Le travail de test est séparé des activités de R&D, permettant des opérations parallèles. Les activités de test s'accompagnent de l'ensemble du processus de R&D, et pas seulement après la sortie des résultats de R&D.
Le modèle W souligne que les activités de test incluent non seulement les codes sources logiciels produits par les activités de R&D, mais prennent également en compte divers documents, tels que les documents d'exigences, les documents de conception générale, les documents de conception détaillée, les codes, etc.
Le modèle W nécessite d'impliquer les activités de test dès le stade des besoins des utilisateurs, ce qui est propice à la détection des problèmes le plus tôt possible. Au cours du processus de mise en œuvre du modèle, des activités de validation et de vérification sont toujours réalisées.

Modèle X

L'arrière-plan du modèle X est également lié au modèle V. L'inconvénient du modèle V est que les activités de test sont en retard sur les activités de recherche et développement et que les activités de test ne peuvent pas être effectuées le plus tôt possible. Le modèle X, comme le modèle W, a été initialement proposé pour résoudre les lacunes du modèle V.
L'idée de base du modèle X a été proposée par Marick et améliorée par Robin F.Goldsmith. Le modèle X est illustré sur la figure.

Le côté gauche du modèle X indique des activités de codage et de test indépendantes pour des fragments de programme individuels n, en prenant cela comme le processus de base, une itération continue, et finalement en devenant des programmes exécutables grâce à des activités d'intégration, puis en testant ces programmes exécutables. Le produit fini qui réussit le test d'intégration peut être emballé et soumis au lien de test du système ou directement à l'utilisateur. Plusieurs courbes parallèles indiquent que des changements peuvent se produire dans diverses parties.
Le modèle X présente le concept de test exploratoire. Les tests exploratoires sont différents des méthodes de test conventionnelles. Il n'est pas nécessaire d'élaborer un plan ou une conception de test à l'avance. Les ingénieurs de test expérimentés peuvent trouver davantage d'erreurs logicielles en dehors du plan de test en fonction de leurs propres activités de réflexion et de leur compréhension de l'objet testé. Cependant, les tests exploratoires ne sont généralement utilisés qu'en complément d'autres méthodes de test.Parce qu'ils consomment plus de ressources de test et sont soumis à l'expérience des ingénieurs de test, ils ne peuvent pas être une méthode de test indépendante.

Modèle H

Le modèle H sépare les activités de test des autres processus de R & D. Les activités de test sont divisées en deux parties : la préparation des tests et l'exécution des tests, ce qui facilite la définition des activités de conception et d'exécution des tests, comme le montre la figure. Les activités de préparation des tests comprennent l'analyse des exigences de test, la planification des tests, la conception des tests, le codage des tests, la vérification des tests, etc. L'exécution des tests comprend l'exécution des tests, le rapport de test, l'analyse des résultats des tests, le test de régression de confirmation, etc.

Comme le modèle W, le modèle H révèle que l'activité de test logiciel doit être un processus de production logiciel indépendant tout au long du cycle de vie du logiciel. L'activité de test doit être préparée et exécutée le plus tôt possible. Les activités d'exécution des tests peuvent être réalisées sans être soumis à des activités de recherche et développement.

modèle de test agile

Mettre l'accent sur les tests du point de vue des clients ;
se concentrer sur les tests itératifs de nouvelles fonctionnalités, minimiser la phase de test
Tester le plus tôt possible, tester en continu et tester lorsque les conditions sont remplies Mettre l'accent sur
le retour d'information continu
Prévenir les défauts est plus important que les découvrir

Modèles évolutifs et modèles prototypes

Le modèle évolutif est également une méthode de développement de prototypage, légèrement différente du modèle de prototypage rapide.

Dans le modèle de prototypage rapide, le but du prototype est de connaître les besoins réels des utilisateurs, une fois que les besoins sont déficients, le prototype est jeté.
Le processus de développement du modèle évolutif est un processus graduel du modèle initial au produit logiciel final.

C'est-à-dire que le modèle de prototypage rapide est une méthode de prototypage « jetable », tandis que le modèle évolutif est une méthode de prototypage « graduel ».

4.CMMI

Référence : https://deepmind.t-salon.cc/article/6396
Une explication détaillée des 5 niveaux et des 22 domaines de processus du modèle de maturité des capacités CMMI, marquez et apprenez les
bases de l'ingénierie logicielle et recommandez
la relation entre CMM et Informations CMMI
Fanfeng CMMI-DEV (vue de développement)

Le nom complet de CMMI est Capability Maturity Model Integration, c'est-à-dire Capability Maturity Model Integration. CMMI est la dernière version du modèle CMM.
Le nom complet de CMMI est Capability Maturity Model Integration. Il existe 5 niveaux de certification CMMI :

Niveau CMMI1, niveau achèvement ; Niveau CMMI2, niveau gestion ; Niveau CMMI3, niveau définition ; Niveau CMMI4, niveau gestion quantitative ; Niveau CMMI5, niveau optimisation.

Dans CMMI, chaque modèle de sujet CMMI a deux représentations :

Représentation mise en scène et représentation continue.
Les modèles de représentations différentes ont des structures différentes. La notation continue met l'accent sur la capacité d'un seul domaine de processus, et l'amélioration des résultats de référence et de mesure est examinée du point de vue du domaine de processus. Le terme clé est "capacité", tandis que la notation par étapes met l'accent sur la maturité de l'organisation
. La perspective collective examine les stades de maturité des processus de l'ensemble de l'organisation, le terme clé étant « maturité ».

Domaine de processus CMMI

CMMI V1.3 a un total de 22 domaines de processus, domaine de processus (PA): décrit le problème d'un certain aspect qui devrait être concentré ou amélioré dans l'ensemble des activités d'amélioration de processus, fixe des objectifs pour chaque processus et pratique selon le buts. Chaque domaine de processus a des objectifs clairs (Objectif) et une pratique (Pratique), les objectifs et les pratiques comprennent :

GG (Generic Goals), le nom chinois est l'objectif général, correspondant à GP (Generic Practices), le nom chinois est la pratique générale, et il est appliqué à la dimension de capacité, il est donc applicable à tous les domaines de processus clés.

SG (Specific Goals), le nom chinois désigne des objectifs spécifiques, correspondant à SP (Specific Practices), le nom chinois désigne des pratiques spécifiques, appliquées à la dimension processus, et ne peut s'appliquer qu'à un domaine de processus clé spécifique.

Les niveaux CMMI, les domaines de processus, les objectifs et les pratiques sont liés comme suit :

Domaine de pratique CMMI

Le domaine de pratique est un concept important dans le cadre CMMI (Capability Maturity Model Integration), qui fait référence à un ensemble de pratiques standard réutilisables qui se sont avérées efficaces dans un domaine spécifique.
Les domaines de pratique autrefois appelés "domaines de processus", par exemple la gestion de la configuration, sont désormais appelés "domaines de pratique". Pour la version 2.0, il y a 25 domaines de pratique applicables. Comme pour les versions précédentes du modèle CMMI, les "Domaines de pratique" introduisent les exigences et les descriptions des activités clés qui définissent l'intention de la pratique.

Le domaine de pratique du CMMI est divisé en deux niveaux : domaine de pratique générale et domaine de pratique spécifique. Les domaines de pratique génériques comprennent la gestion de projet, l'ingénierie, le soutien des processus et des produits, et ces pratiques sont conçues pour soutenir l'amélioration des processus et la gestion de projet dans toute l'organisation. Les domaines de pratique spécifiques sont des pratiques spécifiques formulées en fonction de différents domaines d'activité et industries afin de mieux répondre à divers besoins particuliers.

Par exemple, pour le domaine du développement de logiciels, les domaines de pratique spécifiques du CMMI incluent la gestion des exigences, la gestion de la conception, la gestion des tests, etc. Ces pratiques peuvent aider les organisations de développement de logiciels à établir de meilleurs mécanismes de gestion des exigences, de conception et de gestion des tests, à améliorer la productivité du développement logiciel et à optimiser les processus de développement logiciel.

Résumer

Cette série de blogs est liée au génie logiciel. Cet article est la première partie de la vue d'ensemble du génie logiciel et des exercices de processus logiciel.