Deployment Package – Software Requirements …profs.etsmtl.ca/claporte/VSE/Trousses/Trousse...

Trousse de déploiementVérification et validation

Profil basique

Remarque:Ce document est la propriété intellectuelle de l’organisation des auteurs. Cependant, l’information de ce document peut être utilisée de manière libre. La distribution du document complet ou des parties individuelles est autorisée pour l’utilisation non commerciale pourvue que la notification suivante légale soit mentionnée :

© École de technologie supérieure

L’utilisation commerciale de ce document est strictement interdite. Ce document est distribué afin d’augmenter l’échange d’information technique et scientifique. Ce matériel est fourni «tel quel». L'auteur n’offre aucune garantie d'aucune sorte, explicite ou implicite, quant à toute question, y compris, mais sans s'y limiter, à la garantie de performance, à l'usage ou de qualité marchande, l'exclusivité, ou les résultats obtenus par l'utilisation du matériel. Les processus décrits dans cette trousse de déploiement ne visent pas à empêcher ou à décourager l’utilisation de processus additionnels dont les très petits organismes pourraient trouver utiles.

Auteur(s) Bertrand, Guy, École de technologie supérieure (ÉTS), (Canada)

Éditeur C. Y. LAPORTE – École de technologie supérieure (ÉTS), (Canada)Date de création 12 décembre 2012Dernière mise à jour 16 mars 2013Statut ÉbaucheVersion 0.2

Historique des versions

© Guy Bertrand

Trousse de déploiement – Vérification et validation – Profil basique / 36Version 0.2

Date(jj-mm-aaaa) Version Auteur Modification

12-12-2012 0.1 Guy Bertrand création16-03-2013 0.2 Elie Joseph Revue et mise à jour du document27-04-2013 0.2 Elie Joseph Mise à jour du document

Abréviations/acronymes

Abré./Acro. DéfinitionsTD Trousse de déploiement – Un ensemble d’artefacts développés pour faciliter

l’implémentation dans un très petit organisme, un ensemble de pratiques provenant d’un cadre de référence sélectionné.

TPO Très petit organisme – une entreprise, une organisation, un département ou un projet de 25 personnes ou moins.

SI Processus de mise en œuvre du logicielISO Organisation internationale de normalisationIEC/CEI International Electrotechnical Commission/Commission Electrotechnique

InternationaleTR Technical ReportPM Processus de gestion de projetV & V Vérification et Validation

© Guy Bertrand


Table des matières1. Description Technique...............................................................................4

1.1 But de ce document................................................................................................................41.2 Pourquoi la vérification et la validation sont importantes ?.....................................................4

2. Définitions................................................................................................62.1 Termes génériques.................................................................................................................62.2 Termes spécifiques.................................................................................................................6

3. Liens avec la norme ISO/IEC 29110.............................................................84. Description des processus, activités, tâches, étapes, rôles et produits.........9

4.1. Les tâches des activités dans le processus de PM..................................................................94.2 Les tâches des activités dans le processus de SI..................................................................12

5. Gabarits et outils....................................................................................265.1 Gabarits................................................................................................................................265.2 Outils..................................................................................................................................... 28

6. Exemple de la mise en œuvre de tâches...................................................297. Listes de vérification...............................................................................308. Matrices de couverture............................................................................31

8.1 Matrice de couverture de l'ISO 9001.....................................................................................318.2 Matrice de couverture de l’ISO/IEC 12207.............................................................................328.3 Matrice de couverture du modèle CMMI pour le développement...........................................33

9. Références..............................................................................................3510. Formulaire d’évaluation de la trousse.....................................................36

© Guy Bertrand


1. Description Technique1.1 But de ce documentCette trousse de déploiement (TD) soutient le profil basique tel que définit dans le document ISO/IEC TR 29110-5-1-2:2011-Guide de gestion et d'ingénierie: Groupe de profil générique: Profil basique [ISO/IEC 29110]. Le profil basique est un profil du groupe des profils génériques. Le groupe des profils génériques est applicable aux très petits organismes (TPO) qui ne développent pas des logiciels critiques. Le groupe des profils génériques est composé de 4 profils : entrée (Entry), basique (Basic), intermédiaire (Intermediate) et avancé (Advanced). Le groupe des profils génériques n'implique pas un domaine spécifique d'applications. Le profil basique est destiné aux TPO qui développent un seul projet à la fois.

Une trousse de déploiement est un ensemble d’artefacts qui facilitent l’implémentation d’un ensemble de pratiques dans un TPO. Une TD n’est pas un modèle de référence de processus (c.-à-d. qu’elle n’est pas prescriptive). Les éléments d’une TD sont : la description du processus, les activités, les tâches, les étapes, les rôles et les produits, les gabarits, les listes de vérification (check-lists), les exemples et les outils.

Le contenu de ce document n’est pas normatif, ce document est informatif.

Ce document est destiné à être utilisé par un TPO afin d’établir des processus pour mettre en œuvre une approche de développement ou une méthodologie, par exemple, agile, évolutive, itérative, développement dirigé par les tests, etc. sur la base des besoins de l'organisme ou du projet d'un TPO.

Le document ISO/IEC TR 29110-5-1-2:2011 est disponible sans frais sur le site de l'ISO suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

1.2 Pourquoi la vérification et la validation sont importantes ?La vérification et la validation logicielle constituent une activité qui consiste à fournir l’assurance qu’un système logiciel fonctionnera conformément à un ensemble d’exigences ou de spécifications. Elle s’inscrit dans le cycle de vie du développement logiciel et permet de réduire les écarts entre les spécifications et le produit logiciel. En effet, cette activité minimise le nombre de défauts ainsi que leur coût de correction en les détectant au plus tôt après leur introduction dans le cycle de vie du logiciel car, plus le défaut est introduit en amont, plus son impact est grand et sa correction coûteuse. L’activité de vérification et de validation peut être utilisée pour appuyer les objectifs liés à l’assurance de la qualité du logiciel, à la gestion de projet et à la gestion de la configuration. Ces objectifs sont valides durant tout le cycle de vie du logiciel, du début du cycle de développement et pendant toute la période de maintenance/vie du logiciel.Les tâches inhérentes à l’activité de vérification et de validation incluent :

évaluations confirmation de la conformité inspection du code source revues tests audit autres

© Guy Bertrand

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html


Spécifiquement, l’objectif de la vérification est de confirmer que chaque logiciel ou sous-ensemble, service, processus ou projet satisfasse aux exigences spécifiées.L’objectif de la validation est de confirmer que le produit logiciel satisfasse aux besoins du client.

© Guy Bertrand


2. Définitions

Dans cette section, le lecteur trouvera deux groupes de définitions. Le premier groupe définit les termes utilisés dans toutes les trousses de déploiement, c'est-à-dire, les termes génériques. Le deuxième groupe définit les termes utilisés dans cette trousse de déploiement, c'est-à-dire, les termes spécifiques. Ces termes sont énumérés en ordre alphabétique.

2.1 Termes génériques Activité : ensemble de tâches liées. [ISO/IEC 12207].Artefact : Une information qui n'est pas décrite dans l'ISO/CEI TR 29110-5 mais qui peut aider un TPO pendant l'exécution d'un projet. (p. ex. un cas d’utilisation).Étape : Dans une trousse de déploiement, une tâche/sous-tâche est décomposée en une suite d’étapes.Processus : Un ensemble d’activités corrélées ou en interaction, qui transforme des éléments d’entrée en éléments de sorite. [ISO/IEC 12207].Produit : Un ensemble d’information ou un livrable qui peut être produit (de manière non obligatoire) par une ou plusieurs tâches. (p. ex. le document de conception, le code source). Rôle : Une fonction définie, destinée à être exécutée par un membre de l’équipe du projet. Par exemple testeur, inspecteur, codeur. [ISO/IEC 24765]Sous-Tâche: Lorsqu’une tâche est complexe, elle est divisée en sous-tâches.Tâche: Une action requise, recommandée ou permise destinée à contribuer à l’accomplissement d’un ou plusieurs résultats d’un processus. [ISO/IEC 12207].

2.2 Termes spécifiques

Audit: un examen indépendant d'un produit logiciel, d’un processus logiciel, ou d’un ensemble de processus logiciels effectué par une tierce partie pour évaluer le respect des spécifications, des normes, des accords contractuels ou d'autres critères [IEEE 1028]. NOTE-Un audit devrait se traduire par une indication claire de savoir si les critères de vérification ont été respectés.

Correction: action visant à éliminer une non-conformité détectée [ISO 29110].

Client: organisation ou personne qui reçoit un produit [ISO 9000].

Inspection: un examen visuel d'un produit logiciel pour détecter et identifier les anomalies logicielles, y compris les erreurs et les écarts par rapport aux normes et spécifications [IEEE 1028].

Cycle de vie: l'évolution d'un système, produit, service, projet ou autre entité d'origine humaine de la conception à la retraite [ISO/IEC 12207:2008 and ISO/IEC 15288:2008].

© Guy Bertrand


Revue de direction: Une évaluation systématique d'un logiciel ou d'un processus effectuée par ou pour le compte de la direction afin de surveiller les progrès, de déterminer le statut des plans et des échéanciers, de confirmer les exigences et leur affectation système, ou d’évalue l'efficacité des méthodes de gestion utilisées [IEEE 1028].

Rapport: décrire les résultats des activités telles que des enquêtes, des évaluations et des tests [ISO / IEC 15289]

Revue: un processus ou une réunion au cours duquel un produit logiciel, un ensemble de produits logiciels, ou un processus logiciel est présenté au personnel du projet, aux gestionnaires, aux utilisateurs, aux clients, aux représentants des usagers, aux auditeurs ou à toute autre partie intéressée afin d’être examiné, commenté ou approuvé [IEEE 1028].

Revue technique: une évaluation systématique d'un produit logiciel par une équipe qualifiée afin d’examiner la pertinence du logiciel pour son utilisation prévue et d’identifier les écarts par rapport aux spécifications et aux normes [IEEE 1028].

Validation: confirmation grâce à l'apport de preuves tangibles que les exigences pour une utilisation spécifique prévue ou leurs applications ont été remplies [ISO 9000:2005].

Vérification: confirmation grâce à l'apport de preuves tangibles que les exigences spécifiées ont été respectées [ISO 9000:2005]

© Guy Bertrand


3. Liens avec la norme ISO/IEC 29110

Cette trousse de déploiement présente les activités liées au rapport technique ISO/IEC 29110-5-1-2 pour les très petits organismes (TPO) - groupe de profils génériques : profil basique [ISO/IEC 29110].

Le rapport technique, le Guide de gestion et d’ingénierie, fournit un processus de gestion de projet et un processus de mise en œuvre du logiciel. Ces processus intègrent des pratiques basées sur la sélection de processus de la norme ISO/IEC 12207:2008 Ingénierie des systèmes et du logiciel - Processus du cycle de vie du logiciel et de produits de documentation du standard ISO/IEC 15289:2011 Ingénierie des systèmes et du logiciel - Contenu des systèmes et produits d'information du processus de cycle de vie du logiciel (documentation).

Le but du processus de gestion de projet est d’établir et de réaliser, systématiquement, les tâches inhérentes au projet de déploiement du logiciel, lesquelles permettent d’assurer la conformité avec les Objectifs du projet en matière de qualité, de durée et de budget.

Le but du processus de mise en œuvre du logiciel consiste à assurer la performance systématique des activités d'analyse, de conception, de développement, d'intégration et de tests de produits logiciels, nouveaux ou modifiés, selon les exigences établies.

Ces processus sont interdépendants (voir la figure 1).

Figure 1 — Processus directeurs du profil basique [ISO 29110-5-1-2]

© Guy Bertrand


4. Description des processus, activités, tâches, étapes, rôles et produits

4.1. Les tâches des activités dans le processus de PMLe diagramme suivant montre le flux d'information entre les activités du processus gestion de projet et montre les produits de travail les plus importants.

Figure 2 — Diagramme du processus de gestion de projet du profil basique [ISO/IEC 29110]

© Guy Bertrand


But : PM 1.13 Obtenir l’approbation du Plan de Projet

Justification : Une vérification du plan de projet par le chef technique et le gestionnaire de projet permet de s’assurer que les éléments constituants du plan sont viables et cohérents

Rôles : PM – gestionnaire de projetTL – chef technique

Artefacts : Entrée : - Plan de projet

Sortie : - Résultats de la vérification- Plan de projet [vérifié]

Étapes : Étape 1. Vérifier le documentÉtape 2. Documenter les résultatsÉtape 3. corriger le planÉtape 4. Obtenir approbation du PM

Description des étapes :

Étape 1. Vérifier le documentS’assurer que tous les éléments du « Plan de projet » sont viables et cohérentsÉtape 2. Documenter les résultatsDocumenter les résultats dans « Résultats de la vérification »Étape 3. Corriger le planCorriger le « plan de projet » si nécessaireÉtape 4. Obtenir approbation du PMObtenir l’approbation du PM du « plan de projet [vérifié] »

But : PM 1.14 Réviser et accepter le Plan de projet

Justification : Il est important d’avoir l’approbation du client pour le « plan de projet » avant de débuter le projet car il permet d’établir une base commune de connaissance du projet entre le client et l’équipe de réalisation afin d’éviter des surprises et du changement continu au niveau des exigences. En d’autres termes, cette tâche met en place un « référentiel » pour le projet et aide à établir un engagement de la part du client envers le projet.

Rôles : PM – gestionnaire de projetCUS – client

Artefacts : Entrée : - Plan de projet [vérifié]

Sortie : - compte rendu de réunion- plan de projet [accepté]

Étapes : Étape 1. Examiner et accepter le « plan de projet [vérifié]»Étape 2. Écrire le compte rendu


Étape 1. Examiner et accepter le « plan de projet »Le client examine et accepte le « Plan de projet [vérifié] » en s’assurant que les éléments qui y sont énoncés correspondent à ceux de l’énoncé

© Guy Bertrand


des travaux.Étape 2. Documenter les résultatsÉcrire le « compte rendu de la réunion »

© Guy Bertrand


4.2 Les tâches des activités dans le processus de SILe diagramme suivant montre le flux d'information entre les activités du processus de mise en œuvre du logiciel et montre les produits de travail les plus importants.

Figure 3 — Diagramme du processus de la mise en œuvre du logiciel du profil basique [ISO/IEC 29110]

SI.1 Initiation du processus de SI

But : SI 1.1 Réviser le plan de travail

Justification : Lorsque le plan de projet a été approuvé par le client, il est important de bien communiquer les objectifs, attentes et rôles aux membres de

© Guy Bertrand


l’équipe. Ceci aide à obtenir leurs engagements envers le projet.

Rôles : PM – gestionnaire de projetTL – chef techniqueWT – équipe de travail

Artefacts : Entrée : - Plan de projetSortie : - Plan de projet [révisé]

Étapes : Étape 1. Réviser le plan de travailÉtape 2. Atteindre une compréhension communeÉtape 3. Obtenir l’engagement de l’équipe


Étape 1. Réviser le plan de travailRéviser le « Plan de projet » en vigueur avec les membres de l’équipe de travail. Corriger si nécessaire le « plan de projet [révisé] »Étape 2. Atteindre une compréhension communeArriver à une compréhension commune du projetÉtape 3. Obtenir l’engagement de l’équipeObtenir l’engagement de l’équipe pour la réalisation du projet

SI.2 Analyse des exigences du logiciel

But : SI 2.3 Vérifier la « spécification des exigences »

Justification : Une vérification de la spécification des exigences permet de s’assurer que les exigences sont exactes, non-ambiguës, complètes, testables et cohérentes par rapport à la description du produit logiciel. Ceci aidera à réduire le nombre de demandes de changement.

Rôles : AN - analysteTL – chef technique

Artefacts :Entrée :

- Spécification des exigences- Plan de projet- Description du produit

Sortie : - Résultats de la vérification- Spécification des exigences [vérifiée]- Demande de changement [initiée]

Étapes : Étape 1. Vérifier les exigencesÉtape 2. Documenter dans les « Résultats de la vérification »Étape 3. Si nécessaire initier une « Demande de changement »Étape 4. Approbation d’un analyste


Étape 1. Vérifier les exigencesVérifier l’exactitude, la testabilité de la « Spécification des exigences » ainsi que sa cohérence avec la « Description du produit ». De plus, vérifier les exigences afin de s’assurer qu’elles soient complètes, sans ambiguïté et ne se contredisent pas.

© Guy Bertrand


Étape 2. Documenter les résultats de la vérificationLes résultats sont documentés dans les « Résultats de la vérification » et des corrections sont apportées jusqu’à ce que le document soit approuvé par un AN.Étape 3. Si nécessaire initier une « Demande de changement »Si des changements importants sont requis, initier une « Demande de changement »Étape 4. Approbation d’un analysteObtenir l’approbation d’un AN.

But : SI 2.4 Valider la « Spécification des exigences » et en obtenir l’approbation

Justification : Il est important d’avoir l’approbation de la Spécification des exigences par le client car elle permet de s’assurer que sa compréhension du produit qui sera développé est similaire à celle de l’équipe de réalisation.

Rôles : AN – analysteCUS – client

Artefacts : Entrée : - Spécification des exigences [vérifier]

Sortie : - Résultats de la validation- Spécification des exigences [validée]

Étapes : Étape 1. Valider la « Spécification des exigences »Étape 2. Documenter dans les « Résultats de la validation »Étape 3. Corriger si nécessaire la « Spécification des exigences »Étape 4. Obtenir l’approbation du client


Étape 1. Valider la « Spécification des exigences »Valider la Spécification des exigences afin de s'assurer qu'elle réponde aux besoins et aux attentes établis, dont la convivialité de l’interface utilisateur.Étape 2. Documenter dans les « Résultats de la validation »Les résultats sont documentés dans les Résultats de la validationÉtape 3. Corriger si nécessaire la « Spécification des exigences »Des corrections sont apportées jusqu’à ce que le document soit approuvéÉtape 4. Obtenir l’approbation du clientFaire approuver le document de « Spécification des exigences » par le client.

But : SI 2.6 Vérifier et faire approuver la Documentation de l’utilisateur du logiciel

© Guy Bertrand


(Facultatif)Justification : L’exactitude de la documentation de l’utilisateur améliore la qualité

du produit logiciel, et aide l’usager à acquérir une certaine autosuffisance. Ceci peut permettre une réduction des coûts de formation et de support.

Rôles : AN – analysteTL – chef technique

Artefacts : Entrée : - Documentation de l’utilisateur du logiciel [préliminaire]- Spécification des exigences

Sortie :

- Résultats de la vérification - *Documentation de l’utilisateur du logiciel [préliminaire, vérifiée] - Demande de changement [initiée]

Étapes : Étape 1. Vérifier la « Documentation de l’utilisateur »Étape 2. Documenter dans les « Résultats de la vérification »Étape 3. Corriger si nécessaire la « Documentation de l’utilisateur »Étape 4. Obtenir l’approbation de l’analyste


Étape 1. Vérifier la « Documentation de l’utilisateur »Vérifier la cohérence de la *Documentation de l’utilisateur du logiciel avec la « Spécification des exigences »Étape 2. Documenter les résultatsDocumenter les résultats dans les « Résultats de la vérification »Étape 3. Corriger si nécessaire la « Documentation de l’utilisateur »Si nécessaire, corriger la « Documentation de l’utilisateur ». Si des changements importants sont requis, initier une « Demande de changement » Étape 4. Obtenir l’approbationFaire approuver le document par un AN*(Facultatif)

SI.3 Architecture et conception détaillée du logiciel

But : SI.3.4 Vérifier la Conception du logiciel et en obtenir l'approbation.

Justification : Une vérification de la Conception du logiciel permet de s’assurer qu’elle est cohérente par rapport aux exigences. Ceci aidera à réduire le nombre de demandes de changement et à augmenter la qualité du logiciel.

Rôles : AN – analysteDES – concepteur

Artefacts :Entrée :

- Conception du logiciel - Enregistrement de la traçabilité - Spécification des exigences [validée, établie à titre de

© Guy Bertrand


référence]

Sortie :

- Résultats de la vérification - Conception du logiciel [vérifiée] - Enregistrement de la traçabilité [vérifié] - Demande de changement [initiée]

Étapes : Étape 1. Vérifier la « Conception du logiciel »Étape 2. Vérifier la traçabilité entre les exigences et la conceptionÉtape 3. Documenter dans les « Résultats de la vérification »Étape 4. Corriger la conception si nécessaireÉtape 5. Obtenir l’approbation du concepteur


Étape 1. Vérifier la « Conception du logiciel »Vérifier l'exactitude de la documentation de la « Conception du logiciel », sa faisabilité et sa cohérence avec la « Spécification des exigences » Étape 2. Vérifier la traçabilité entre les exigences et la conceptionS’assurer que « l’Enregistrement de la traçabilité » contient les liens adéquats entre les exigences et les éléments de la « Conception du logiciel »Étape 3. Documenter dans les « Résultats de la vérification »Les résultats sont documentés dans les « Résultats de la vérification ».Étape 4. Corriger la conception si nécessaireDes corrections sont apportées à la documentation de la « Conception du logiciel » si nécessaire. Si des changements importants sont requis, une « Demande de changement » doit être initiée.Étape 5. Obtenir l’approbation du concepteurFaire approuver le document par le concepteur.

But : SI.3.6 Vérifier les Cas et les procédures de test et en obtenir l’approbation

Justification : Une vérification des cas et des procédures de test permet de s’assurer qu’ils sont cohérents par rapport aux exigences et à la conception. Ceci aidera à réduire le nombre de demandes de changement et à augmenter la qualité du logiciel

Rôles : AN – analysteDES – concepteur

Artefacts :

Entrée :

- Cas et procédures de test - Spécification des exigences [validée, établie à titre de référence] - Conception du logiciel [vérifiée, établie à titre de référence]

Sortie : - Résultats de la vérification © Guy Bertrand


- Cas et procédures de test [vérifiés]Étapes : Étape 1. Vérifier la cohérence entre les documents

Étape 2. Documenter dans les « Résultats de la vérification »Étape 3. Corriger si nécessaireÉtape 4. Obtenir l’approbation de l’AN


Étape 1. Vérifier la cohérence entre les documentsVérifier la cohérence entre la « Spécification des exigences », la « Conception du logiciel » et les « Cas et procédures de test »Étape 2. Documenter les résultatsDocumenter les résultats dans les « Résultats de la vérification »Étape 3. Corriger si nécessaireCorriger si nécessaire les « Cas et procédures de test ».Étape 4. Obtenir l’approbation de l’ANFaire approuver les « Cas et procédures de test » par l’analyste.

SI.4 Construction du logiciel

But : SI.4.4 et 4.5 Vérifier les composants logiciels en appliquant les tests unitaires

Facultatif (voir les tâche SI.4.4 et SI.4.5) Justification : Cette tâche permet de s’assurer les fonctionnalités clés identifiées

dans la spécification des exigences sont implémentées conformément à la conception logicielle.

Rôles : PR - programmeurArtefacts :

Entrée : - Conception logicielle - Composants logiciels- Cas de test et les procédures de test

Sortie : - Composants logiciels [soumis aux tests unitaires]Étapes : Étape 1. Identifier les composants logiciels

Étape 2. Appliquer les tests unitairesÉtape 3. Corriger si nécessaire


Étape 1. Identifier les composants logiciels Identifier les unités de code et de données à tester. Étape 2. Appliquer les tests unitairesVérifier que les composants fonctionnent comme prévu en utilisant les tests unitaires.Étape 3. Corriger si nécessaireDes corrections sont apportées jusqu'à ce que les tests unitaires soient accomplis avec succès.

© Guy Bertrand


SI.5 Intégration et tests du logiciel

But : SI.5.4 et 5.5 Vérifier que les composants logiciels s’intègrent conformément aux exigences logicielles

Facultatif (voir les tâche SI.5.4 et SI.5.5) Justification : Cette tâche permet de s’assurer que les composants logiciels sont

intégrés en respectant les critères spécifiés et que les écarts sont documentés.

Rôles : PR – programmeurCUS – client

Artefacts :

Entrée :

- Logiciel - Cas de test et les procédures de test- Enregistrement de la traçabilité [mis à jour, établi à titre de référence]

Sortie : - Logiciel [soumis aux tests, corrigé]- Rapport de test [défauts corrigés]

Étapes : Étape 1. Identifier les composants logiciels intégrésÉtape 2. Réaliser les tests d’intégrationÉtape 3. Documenter les résultatsÉtape 4. Corriger si nécessaire


Étape 1. Identifier les composants logiciels intégrés Identifier les unités de code intégrées ainsi que les données à tester. Étape 2. Réaliser les tests d’intégrationRéaliser les cas de test conformément aux procédures.Étape 3. Documenter les résultatsDocumenter les résultats dans un rapport.Étape 4. Corriger si nécessaireDes corrections sont apportées jusqu'à ce que les cas tests soient réalisés avec succès.

But : SI.5.8 Réviser et faire approuver le *Guide d’opération du produit

Facultatif (voir la tâche SI.5.7) Justification : Cette tâche peut augmenter la qualité du documentRôles : DES – concepteur

PR - programmeurArtefacts : Entrée : - Guide d’opération du produit

- Logiciel [soumis aux tests]

Sortie : - Résultats de la vérification - Guide d’opération du produit [vérifié]

© Guy Bertrand


Étapes : Étape 1. Vérifier la cohérence du *Guide d’opérationÉtape 2. Documenter les résultatsÉtape 3. Corriger si nécessaireÉtape 4. Obtenir l’approbation du DES


Étape 1. Vérifier la cohérence du *Guide d’opérationVérifier la cohérence du « *Guide d’opération du produit » avec le Logiciel. Étape 2. Documenter les résultatsLes résultats sont documentés dans les « Résultats de la vérification »Étape 3. Corriger si nécessaireDes corrections sont apportées si nécessaireÉtape 4. Obtenir approbation du DESFaire approuver le « *Guide d’opération du produit » du DES*(Facultatif)

But : SI.5.10 Vérifier et obtenir l’approbation pour la Documentation de l’utilisateur du logiciel

* s’il y a lieu (voir la tâche SI.5.9). *(Facultatif)Justification : L’exactitude de la documentation de l’utilisateur améliore la qualité

du produit logiciel, et aide l’usager à acquérir une certaine autosuffisance. Ceci peut permettre une réduction des coûts de formation et de support.

Rôles : AN – AnalysteCUS - client

Artefacts : Entrée : - *Documentation de l’utilisateur du logiciel - Logiciel [soumis aux tests]

Sortie : - Résultats de la vérification - *Documentation de l’utilisateur du logiciel [vérifiée]

Étapes : Étape 1. Vérifier la documentation de l’utilisateurÉtape 2. Documenter les résultatsÉtape 3. Corriger si nécessaireÉtape 4. Obtenir l’approbation du CUS


Étape 1. Vérifier cohérenceVérifier la cohérence de la « *Documentation de l’utilisateur du logiciel » avec le logiciel développé.Étape 2. Documenter les résultats Documenter les résultats dans les « Résultats de la vérification »Étape 3. Corriger si nécessaireCorriger si nécessaire la documentation de l’utilisateur.Étape 4. Obtenir l’approbation du CUSFaire approuver la documentation de l’utilisateur par le client.

© Guy Bertrand


*(Facultatif)

SI.6 Livraison du produit

But : SI.6.4 Vérifier la Documentation de la maintenance et la faire approuver.

Justification : Cette tâche améliore la qualité du document et est nécessaire pour réduire les coûts de maintenance du logiciel.

Rôles : DES – concepteurTL – chef technique

Artefacts : Entrée : - Documentation de la maintenance - Configuration du logiciel

Sortie : - Résultats de la vérification - Documentation de la maintenance [vérifiée]

Étapes : Étape 1. Vérifier la cohérenceÉtape 2. Documenter les résultatsÉtape 3. Corriger si nécessaireÉtape 4. Obtenir l’approbation du TL


Étape 1. Vérifier la cohérenceVérifier la cohérence de la « Documentation de la maintenance » par rapport à la « Configuration du logiciel ».Étape 2. Documenter les résultatsLes résultats sont documentés dans les « Résultats de la vérification »Étape 3. Corriger si nécessaireCorriger la documentation de la maintenance si nécessaireÉtape 4. Obtenir l’approbation du TLFaire approuver la documentation de la maintenance par le chef technique.

4.2 Description des rôlesCette section donne une liste des rôles, des abréviations et de la description des compétences souhaitées.

Rôle Abréviation CompétencesAnalyste AN Expérience et connaissances en sollicitation

(explicitation), en spécification et en analyse d'exigences. Connaissance en conception d’interfaces utilisateurs et des critères ergonomiques. Connaissance des techniques de revue. Connaissance des techniques d’édition. Expérience en développement et en maintenance de

© Guy Bertrand


Rôle Abréviation Compétenceslogiciel.

Chef technique

TL Connaissance du domaine du logiciel et expérience connexe.

Client CUS Connaissance des processus du client et aptitude à expliquer les exigences du client. Le client (ou son représentant) doit avoir le pouvoir d’approuver les exigences et les changements à apporter. Le terme « client » comprend les personnes qui représentent les utilisateurs pour veiller à ce que l'environnement d’opération soit mis à l’étude. Connaissance du domaine du logiciel et expérience connexe.

Concepteur DES Connaissance des Composants logiciels et de la conception de l’architecture et expérience connexe. Connaissance des techniques de révision. Expérience en planification et en réalisation de tests d’intégration et connaissances connexes. Connaissance des techniques d’édition. Expérience en développement et en maintenance de logiciel.

Programmeur PR Connaissance et/ou expérience en programmation, en intégration et en tests unitaires. Connaissance des techniques de revue. Connaissance des techniques d’édition. Expérience en développement et en maintenance de logiciel.

4.3. Description des artefacts Cette section donne une liste alphabétique des artefacts (c.-à-d. des documents papier ou électroniques) nécessaires à la réalisation des tâches décrites ci-dessus. Ce sont les intrants, les extrants et les documents produits pendant l’exécution des tâches mais qui ne seront pas diffusés à l’extérieur du projet (p.ex. Registre des corrections).

Nom de l'artefact Description

Cas et procédures de test

Éléments nécessaires pour le test du code. Un cas de test peut comprendre: - Détermination du cas de test - Éléments du cas de test - Spécifications d’entrée - Spécifications de sortie - Besoins en matière d’environnement - Exigences spéciales en matière de procédure

© Guy Bertrand


- Dépendances de l’interface Les procédures de test peuvent comprendre : - Détermination du nom du test, description et date d’achèvement - Détermination des problèmes potentiels en matière de mise en œuvre - Détermination du nom de la personne qui a réalisé la procédure de test - Détermination des préalables (pré-requis) - Détermination des étapes de la procédure dont le numéro de l’étape, la mesure à être prise par le responsable du test et les résultats attendus Les états possibles sont: vérifiés et établis à titre de référence.

Conception du logiciel

Un ensemble de produits logiciels uniques et cohérents dont: - Spécification des exigences - Conception du logiciel - Enregistrement de la traçabilité - Composants logiciels - Logiciel - Cas et procédures de test - Rapport de test - Guide d’opération du produit - Documentation de l’utilisateur du logiciel - Documentation de la maintenance Les états possibles sont: livrée et acceptée.

Documentation de la maintenance

Décrit la Configuration du logiciel ainsi que l’environnement utilisé pour le développement et les tests (compilateurs, outils de conception, construction et tests). Elle peut être dotée des caractéristiques suivantes: - Liste de tous les éléments de Configuration du logiciel développés pendant la mise en œuvre, ou des références à ces éléments. - Environnement utilisé pour le développement et les tests (compilateurs, outils de conception, de construction et tests).

Les documents sont rédigés de façon à ce que le personnel de maintenance puisse les comprendre. Les états possibles sont: vérifiée et établie à titre de référence.

Documentation de l’utilisateur du logiciel

Décrit la façon d’utiliser le Logiciel en fonction de l’interface utilisateur. Elle peut être dotée des caractéristiques suivantes: - Procédures destinées aux utilisateurs pour la réalisation de Tâches précisées en utilisant le Logiciel - Procédures d’installation et de désinstallation - Courte description de l’utilisation prévue du Logiciel (les concepts de fonctionnement) - Ressources fournies et requises

© Guy Bertrand


- Environnement d’opération nécessaire - Accès à un service d'assistance, où communiquer les problèmes - Procédures pour accéder au logiciel et en sortir - Listes et explication des commandes logicielles et des messages transmis à l’utilisateur par le système - En fonction du risque identifié, des avertissements, des mises en garde, et des notes accompagnées de mesures correctives pertinentes - Procédures de diagnostic de panne et de correction d’erreurs.

Les documents sont rédigés de façon que les utilisateurs les comprennent. Les états possibles sont: préliminaire, vérifiée et établie à titre de référence.

Enregistrement de la traçabilité


Guide d’opération du produit


Rapport de test

Documente les tests, il peut comprendre :- Un résumé de chaque défaut- Le cas de test- La sévérité de chaque défaut- Le nom du testeur ayant trouvé le défaut- La date de résolution de chaque défaut- Etc.

© Guy Bertrand


L’état possible est : référentiel

Résultats de la validation

Documentent l’exécution des activités de validation, ce qui peut comprendre: - Participants - Date - Lieu - Durée- Liste de validation - Éléments de validation réussis - Éléments de validation échoués - Éléments de validation en attente - Défauts repérés au cours de la validation

Résultats de la vérification

Servent à documenter l’exécution des activités de vérification, ce qui peut comprendre: - Participants - Date - Lieu - Durée - Liste de vérification - Éléments de vérification réussis - Éléments de vérification échoués - Éléments de vérification en attente - Défauts repérés au cours de la vérification

Spécification des exigences

Détermine les exigences logicielles. Elle peut être dotée des caractéristiques suivantes: - Introduction: une description générale du Logiciel et de son utilisation dans le cadre de la portée des activités d’affaires du client; - Description des exigences: - Fonctionnalité: les besoins établis qui doivent être satisfaits par le Logiciel lorsque ce dernier est utilisé dans des conditions particulières. La fonctionnalité doit être appropriée, précise et sûre. - Interface utilisateur: définition des caractéristiques d’interface qui permettent de comprendre et de maîtriser le logiciel afin que l’utilisateur s’acquitte efficacement de ses tâches, dont la description du modèle de l’interface - Interfaces externes: définition des interfaces avec d’autres logiciels ou matériels. - Fiabilité: spécification du mode d’exécution du logiciel en ce qui a trait à la maturité, à la résilience et à la récupération - Efficience: indication du niveau d’exécution du logiciel en ce qui concerne le temps et l’utilisation des Ressources - Maintenabilité: description des éléments facilitant la compréhension et l’exécution des modifications à venir à apporter au Logiciel - Portabilité: description des caractéristiques du logiciel qui permettent de

© Guy Bertrand


le transférer d’un emplacement à un autre - Limites/contraintes en matière de conception et de construction: les exigences imposées par le client - Interopérabilité: possibilité, pour deux systèmes ou Composants logiciels ou plus, de transférer des renseignements entre eux et de les utiliser - Possibilité de réutilisation: caractéristique de tout produit/sous-produit ou d’une de leurs parties, qui permet à plusieurs utilisateurs de s’en servir comme produit final, dans le développement de leur logiciel ou pour exécuter d’autres produits logiciels - Légales ou normatives: des exigences imposées par des lois, par des règlements, etc. Chaque exigence est déterminée et unique, elle peut être vérifiée ou évaluée. Les états possibles sont: vérifiée, validée et établie à titre de référence (référentiel).

© Guy Bertrand


5. Gabarits et outils

Cette section décrit les gabarits et outils qui facilitent la mise en œuvre du contenu de cette trousse.

5.1 GabaritsLes gabarits fournis ici sont des exemples, ils devraient être personnalisés à votre projet.Il existe plusieurs artéfacts qui sont créés hors du contexte de la vérification et validation. Les gabarits pour ces documents se retrouvent dans d’autres trousses de déploiement de ce profil.

5.1.1 Gabarit pour le plan de vérification et de validation du logiciel

PLAN DE VÉRIFICATION ET DE VALIDATION DU LOGICIELAdapté du standard IEEE 1012 et [1]Table des matières

1. But2. Documents référencés3. Définitions4. V&V : Vue globale

a. Organisationb. Planification maîtressec. Sommaire des ressourcesd. Responsabilitése. Outils, techniques et méthodologies

5. Cycle de vie de V&Va. Gestion de la vérification et validationb. Vérification et validation de la phase de conceptsc. Vérification et validation de la phase d'analyse des besoinsd. Vérification et validation de la phase de conceptione. Vérification et validation de la phase d'implémentationf. Vérification et validation de la phase de test g. Vérification et validation de la phase d'installation h. Vérification et validation de la phase de maintenance

6. Rapport de V&V du logiciel a. Rapports requis b. Rapports optionnels

7. Procédures administratives a. Rapports d'anomalies et leur résolution b. Politique d'itération de tâche c. Politique de déviationd. Standards, pratiques et conventions

[1]Bélanger, S., Brosseau, Y., Hatier, N., Proulx, C., & Tremblay, F. (2001, 06 06). Plan de vérification et de validation du logiciel. Consulté le 12 12, 2012, sur www.sourceforge.net: http://dedalus.sourceforge.net/documents/pvvl.pdf

© Guy Bertrand


5.1.2 Gabarit de la table des matières d’une notification de réunion

1. Nom de la réunion (incluant le nom de projet) 2. Priorité de la réunion3. Destinataires 4. Objectif de la réunion 5. Contenu du message 6. La date, l’endroit et l’heure 7. D'autres informations (ex. repas inclus)

5.1.3 Gabarit d’une liste de contrôle d’assistance aux réunions

No. Nom du membre de l’équipe de travail

Rôle AssistanceOui Non

Signature

Commentaires

5.1.4 Exemple de formulaire d’acceptation

Formulaire d’acceptation Identification du projet : Préparé par (nom initial) : Date (aaaa-mm-jj) : Critères d’acceptation :

Critères d’acceptation Date où le critère a été satisfait

(aaaa-mm-jj)

1

2

3

4

5

© Guy Bertrand


Signatures d’acceptation :

Composants logiciels

Information de versions

Date d’acceptation du

client

Signature du client

Signatures :

__________________ ________________________________Responsable « client » / responsable de l’approbation

Date (aaaa-mm-jj) :_________________

5.2 Outils

Cette trousse ne nécessite pas d’outils particuliers, sauf pour l’utilisation d’un logiciel de traitement de texte (ex : MS Word) et d’un logiciel de tableur (ex : MS Excel).

© Guy Bertrand


6. Exemple de la mise en œuvre de tâches

Plan de vérification logicielle – Exemple [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]

http://dogbert.mse.cs.cmu.edu/mse2005/projects/Pandora/public_html/index.html

Plan de vérification logicielle – Exemple [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]

http://www.cs.mu.oz.au/341/2008/Tutorials/svvp.pdf

© Guy Bertrand

http://www.cs.mu.oz.au/341/2008/Tutorials/svvp.pdf




7. Listes de vérification

Cette section présente des listes de vérification afin d'aider à la mise en œuvre des tâches de cette trousse.

7.1 Vérification et validation du plan de projetPM 1 Le plan de projet est vérifié et approuvé par le gestionnaire de projetPM 2 Le plan de projet est révisé et approuvé par le client

7.2 Vérification et validation des autres artefacts du projetSI 1 Le plan de projet est communiqué à l’équipe par le gestionnaire de projet et le

chef technique. L’équipe est engagéeSI 2 La spécification des exigences est vérifiée et approuvée par l’analysteSI 3 La spécification des exigences est validée et approuvée par le clientSI 4 La documentation de l’utilisateur est vérifiée et approuvée par l’analysteSI 5 La Conception du logiciel est vérifiée et approuvée par le concepteurSI 6 Les Cas et Procédures de test sont vérifiés et approuvés par l’analysteSI 7 Le Guide d’opération est approuvé par le concepteurSI 8 La Documentation de l’utilisateur du logiciel est approuvée par le concepteurSI 9 La Documentation de la maintenance est approuvée par le chef techniqueSI 10 Les composants logiciels sont testésSI 11 Les composants logiciels sont intégrés en respectant les critères spécifiés

© Guy Bertrand


8. Matrices de couverture

Cette annexe démontre la traçabilité de cette trousse de déploiement avec des standards de l'ISO et avec le CMMI® pour le développement, version 1.3. Pour chacun des éléments, sa couverture est indiquée selon la convention suivante:

o Couverture complète = C o Couverture partielle = Po Aucune couverture = A

8.1 Matrice de couverture de l'ISO 9001

Titre de la tâche et étape1 CouvertureC/P/A

Clause de l'ISO 9001 Commentaires

SI 2.4 Valider la Spécification des exigences et en obtenir l’approbation

C7.2.2 Revue des exigences relatives au produit

SI.3.4 Vérifier la Conception du logiciel et en obtenir l'approbation.SI.3.6 Vérifier les Cas et les procédures de test et en obtenir l’approbationSI.4.4 et 4.5 Vérifier les composants logiciels en appliquant les tests unitaires

P

7.3.4 Effectuer des revues de conception et de développement.7.3.5 Effectuer des vérifications de conception et de développement.7.3.6 Valider la conception et le développement

Aucune tache formelle de validation

SI.5.4 et 5.5 Vérifier que les composants logiciels s’intègrent conformément aux exigences logicielles

C

4.2.4.1 : Preuve de conformité à exigences a) Résultats documentés de testb) Rapports de problème

7.3.7 : Contrôle de design et changements de développement

La réécriture de nouveau cas de test n’est pas mentionnée

SI.5.8 Réviser et faire approuver le Guide d’opération du produit

C7.3.1.1: Design et planification de développement

SI.5.10 Vérifier et obtenir l’approbation pour la Documentation de l’utilisateur du logiciel

C7.3.3: réalisation suite à la conception et au développement.

© Guy Bertrand


8.2 Matrice de couverture de l’ISO/IEC 12207


Tâches de l'ISO/IEC 12207 Commentaires

SI 2.3 Vérifier la Spécification des exigences et en obtenir l’approbation SI 2.4 Valider la Spécification des exigences et en obtenir l’approbation

P

7.1.2 Processus d'analyse des exigences du logiciel

7.1.2.3 Activités et tâches

Aucune mention concernant l’évaluation de la faisabilité.

SI.3.4 Vérifier la Conception du logiciel et en obtenir l'approbation

SI.3.6 Vérifier les Cas et les procédures de test et en obtenir l’approbation

P

7.1.3 Processus de conception et de L’architecture logicielle Section - 7.1.3.3.1.17.1.3 Processus de conception et de L’architecture logicielle Section - 7.1.3.3.1.67.1.3 Processus de conception et de L’architecture logicielle Section - 7.1.3.3.1.77.1.4 Processus de conception et de L’architecture logicielle Section - 7.1.4.3.1.47.1.4 Processus de conception et de L’architecture logicielle Section - 7.1.4.3.1.77.1.4 Processus de conception et de L’architecture logicielle Section - 7.1.4.3.1.8

Aucune évaluation de la faisabilité d’exploitation et d’entretien.

© Guy Bertrand


SI.4.4 et 4.5 Vérifier les composants logiciels en appliquant les tests unitaires

C

7.1.5.3.1 Construction logicielle Section - 7.1.5.3.1.17.1.5.3.1 Construction logicielle Section - 7.1.5.3.1.27.1.5.3.1 Construction logicielle Section - 7.1.5.3.1.5


P

6.4.5.3.2.16.4.5.3.2.26.4.6.3.1.26.4.9.3.1.37.1.5.3.1.26.4.5.3.2.1 – note6.4.6.3.1.4

L’analyse des différences entre les résultats n’est pas mentionnée.

La réécriture de nouveau cas de test n’est pas clairement mentionnée.


C6.4.8.3.16.4.10.3.2.56.4.10.3.3.2


C 6.4.10.3.3.2

8.3 Matrice de couverture du modèle CMMI pour le développement


Objectifs / Pratiques du

modèle CMMI V1.3Commentaires

SI 2.3 Vérifier la spécification des exigences et en obtenir l’approbation

C Vérification SG 1 et SG 3

SI 2.4 Valider la Spécification des exigences et en obtenir l’approbation

C Développement des exigences SP 3.5

1SM CMM Integration est une marque de service de Carnegie Mellon University.® Capability Maturity Model, CMMI est enregistré U.S. Patent and Trademark Office par Carnegie

Mellon University. Ceci est le titre de la tâche de la section 4 de cette trousse.

© Guy Bertrand


SI.3.4 Vérifier la Conception du logiciel et en obtenir l'approbation. P

TS (SG 2) SP2.1 Conception du produit ou des composants du produit Développer une conception pour le produit ou une conception du produit

Aucune spécification spécifique n’est incluse dans le paquetage de déploiement.

SI.4.4 et 4.5 Vérifier les composants logiciels en appliquant les tests unitaires

C

TS)SG 3 Implémenter la conception du produitSP 3.1 Implémenter la conception.


P

PPQA) SG2-SP2.1,(PPQA) SG2-SP2.2 : Documentation de l’évaluation

(PPQA) SG2-SP2.1 : Correction suite à l’évaluation

L’analyse des différences entre les résultats n’est pas mentionnée.

La réécriture de nouveau cas de test n’est pas clairement mentionnée.


C(SAM) SG2- SP 2.2 : Établir un dossier technique


C (SAM) SP 2.2: Acceptation du produit

© Guy Bertrand


9. Références

Nom Référence[ISO/IEC 29110-5-1-2] ISO/IEC TR 29110-5-1-2:2011, Ingénierie du logiciel - Profils de

cycle de vie pour très petits organismes (TPO) - Partie 5-1-2: Guide de gestion et d'ingénierie: Groupe de profil générique: Profil basique.Ce document est disponible gratuitement sur le site suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

[ISO/IEC 12207] ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes.

[ISO/IEC 15289] ISO/IEC 15289:2011 Systems and software engineering - Content of systems and software life cycle process information products (Documentation)

[ISO/IEC/IEEE 24765] ISO/IEC/IEEE 24765:2010 Systems and software engineering vocabulary.Une version électronique du vocabulaire est disponible à: http://pascal.computer.org/sev_display/index.action

[CMMI] Software Engineering Institute, CMMI pour le Développement, Version 1.3, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2010.

[ISO 9001] ISO 9001, Systèmes de management de la qualité — Exigences, Organisation internationale de normalisation, Genève, 2008.

[IEEE std 1028-2008] IEEE Standard for Software Reviews and Audits

[IEEE std 610.12-1990] IEEE Standard Glossary of Software Engineering Terminology

© Guy Bertrand

http://pascal.computer.org/sev_display/index.action

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html


10. Formulaire d’évaluation de la trousse

Trousse de déploiement – Vérification et validation – Profil basique Version 0.2Vos commentaires nous permettront d'améliorer cette trousse de déploiement; vos suggestions sont les bienvenues.

1. Est-ce que le contenu de cette trousse de déploiement vous satisfait? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

2. Par rapport à la SÉQUENCE dans laquelle les sujets sont discutés, vous êtes ? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

3. Par rapport à l’APPARENCE/FORMAT de cette trousse de déploiement, vous êtes? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

4. Considérez-vous que cette trousse contient des sujets inutiles? (décrivez-les S.V.P.)

5. Considérez-vous que cette trousse manque de sujets importants? (décrivez-les S.V.P.)

Sujet proposé : Justification du nouveau sujet:

6. Considérez-vous que cette trousse a des erreurs? S’il vous plaît indiquez:

Description de l’erreur: Position de l’erreur dans le document (section #, figure #, table #) :

7. Avez-vous d’autres informations ou commentaires?

8. Est-ce que vous recommanderez cette trousse de déploiement à un collègue d’une autre TPO?

Certainement Probablement Peut-être Probablement non Certainement non

Optionnel Nom: courriel : _________________________________________

Complétez ce formulaire et envoyez-le à l’adresse suivante: [email protected]

© Guy Bertrand

mailto:[email protected]

Deployment Package – Software Requirements …profs.etsmtl.ca/claporte/VSE/Trousses/Trousse...

Documents

Transcript of Deployment Package – Software Requirements …profs.etsmtl.ca/claporte/VSE/Trousses/Trousse...