deployment package – software requirements …profs.etsmtl.ca/claporte/vse/trousses/trousse...

Trousse de déploiementConstruction et test unitaire

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) Outellou, Mohamed., École de technologie supérieure (ÉTS), (Canada)

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

Historique des versions

© Mohamed Outellou

Trousse de déploiement - Mise en œuvre du logiciel – Profil basique / 28Version 0.2

Date(jj-mm-aaaa) Version Auteur Modification

22-12-2012 0.1 Mohamed Outellou

Section 4 et 5

28-02-2013 0.2 Elie Joseph Révision 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 projet

© Prénom Nom


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

1.1 But de ce document................................................................................................................41.2 Pourquoi l’activité de contsruction et des test unitaires est importante ?...............................4

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

3. Liens avec la norme ISO/IEC 29110.............................................................74. Description des processus, activités, tâches, étapes, rôles et produits.........85. Gabarits et outils....................................................................................13

5.1 Gabarits................................................................................................................................135.2 Outils..................................................................................................................................... 15

6. Exemple de la mise en œuvre de tâches...................................................177. Listes de vérification...............................................................................218. Matrices de couverture............................................................................23

8.1 Matrice de couverture de l'ISO 9001.....................................................................................238.2 Matrice de couverture de l’ISO/IEC 12207.............................................................................248.3 Matrice de couverture du modèle CMMI pour le développement...........................................24

9. Références..............................................................................................2610. Formulaire d’évaluation de la trousse.....................................................27

© Prénom Nom


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 construction et les tests unitaires sont-ils importants ?

L’activité de construction et des tests unitaires conduit à la rédaction du code source et à la vérification de chacun de ses modules.Elle constitue, en effet, l’activité principale du processus de développement d’un logiciel comme le précise les raisons suivantes :

La construction est la seule activité dont la réalisation est obligatoire : Les projets réels négligent souvent les spécifications et la conception pour se limiter à la construction. [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]

Le code source est souvent la seule description exacte du logiciel : Dans beaucoup de projets, la seule documentation mise à jour est le code. [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]

80% du cout de développement est consommé par l’identification et la correction des défauts par les programmeurs. [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]

Le tableau qui suit montre la variation du coût de correction d’une erreur en fonction des phases de détection et d’injection dans le processus de développement.

© Prénom Nom

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


Phase d’injection

Phase de détectionExigences Architecture Construction Tests

systèmesPost-Release

Exigences 1 3 5-10 10 10-100Architecture --- 1 10 15 25-100Construction --- --- 1 10 10-25

On peut remarquer que le coût de correction croît avec le temps de détection d’une erreur, par exemple, un défaut introduit à la phase de construction mais détecté à la phase des tests systèmes coûte dix(10) fois plus à corriger qu’en phase de construction [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng].

© Prénom Nom


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écifiquesCas de test : Documentation spécifiant les entrées, les résultats attendus et un ensemble de conditions d’exécution pour un item de test. [IEEE 829-1998]Composant : Ensemble de services fonctionnels dans le logiciel, qui, une fois mis en œuvre, représente un ensemble bien défini de fonctions et se distingue par un nom unique. [ISO / IEC 29881:2008]Couverture de code: Mesure utilisée au niveau des tests logiciels. Elle décrit le degré auquel le code source d'un programme a été testé. [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]Défaut : Un problème, s’il n’est pas corrigé, pourrait occasionner dans l’application une faillite ou des résultats incorrects. [ISO/IEC 24765].Item de test : Item ou composant logiciel qui pourrait être soumis à des tests. [IEEE 829-1998]Tests unitaires : Tests de routines ou de modules par le développeur ou un testeur indépendant en dehors du reste du programme. [ISO / IEC 24765]Traçabilité: Degré auquel une relation peut être établie entre deux ou plusieurs produits du processus de développement, en particulier les produits ayant une relation prédécesseur-successeur ou maître-subordonné à un autre. [IEEE 1233-1998]

© Prénom Nom


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]

© Prénom Nom


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

Le 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 2 — Diagramme du processus de la mise en œuvre du logicieldu profil basique [ISO/IEC 29110]

4.1. Les tâches de l’activité SI.4 Construction du logicielL’activité de construction et des tests unitaires du logiciel vise à développer le code, les tests unitaires et les données du logiciel à partir de la conception logicielle. Cette activité permet d’obtenir :

- La revue, par les membres de l’équipe de travail, du Plan de projet pour assigner les tâches.

- L’examen, par les membres de l’équipe de travail, de la Conception du logiciel afin de définir la séquence de la Construction du logiciel.

- Des Composants logiciels codés et des tests unitaires exécutés. - La traçabilité entre les Composants logiciels développés et la Conception du logiciel.

© Prénom Nom


But : Vise à développer le code et les données du logiciel à partir de la Conception du logiciel.

© Prénom Nom


Justification : La construction logicielle et les tests unitaires constituent une activité essentielle, car elle en résulte le produit qui sera commercialisé.

Rôles : Chef technique (TL)Programmeur (PR)

Artefacts : Plan de projetComposants logicielsListe des cas et procédures de testModèle des tests unitairesMatrice de traçabilité

Étapes : Étape 1. Assigner les tâches aux programmeurs Étape 2. Développer ou modifier les composants logicielsÉtape 3. Concevoir et mettre à jour les cas de tests ainsi que les tests unitaires associésÉtape 4. Corriger les défauts logicielsÉtape 5. Mettre à jour les enregistrements de traçabilité.Étape 6. Incorporer les composants logiciels à la configuration du logiciel.

Description des étapes :

Étape 1. Assigner les tâches aux programmeurs- Consulter les enregistrements de traçabilité et la documentation

de la conception logicielle afin de récupérer les détails des composants à développer.

- Sélectionner la stratégie de la séquence d’intégration : Elle peut être :

Ascendante : Intégrer les composants en partant de ceux qui sont au plus bas niveau.

Descendante : Intégrer les composants en partant de ceux qui sont au plus haut niveau.

Etc.- Consulter l’échéancier du projet - Assigner la réalisation des composants interdépendants à une

seule personne si possible selon ses préférences et expériences.

Étape 2. Développer ou modifier les composants logiciels.- Identifier les fonctionnalités offertes par chaque composant qui

sont disponibles dans les librairies de développement.- Décrire la logique de chaque composant en utilisant un algorithme

pseudocode ou toute autre technique permettant de le faire.- Coder les composants suivant les standards.- Vérifier chaque composant développé en utilisant une technique

appropriée (revue de code, etc.) afin d’améliorer, si nécessaire, la qualité de son code (compréhensibilité, lisibilité, etc.)

Étape 3. Concevoir et mettre à jour les cas de test ainsi que les tests unitaires associés.

- Définir ou mettre à jour les cas de test pour chaque composant. - Vérifier que les cas de test sont conformes aux exigences du

© Prénom Nom


composant- Développer ou mettre à jour les tests unitaires inhérents à

chaque cas de test- vérifier les tests unitaires afin de s’assurer qu’ils sont conformes

aux cas de tests- Exécuter les tests unitaires- Analyser les résultats de l’exécution des tests unitaires et corriger

les éventuels défauts.

Étape 4. Corriger les défauts logiciels- Confirmer le défaut : Vérifier que le défaut provienne du code de

l’application. Dans le cas contraire, il faut vérifier le code du test et le corriger si nécessaire.

- Localiser le défaut dans le code de l’application.- Corriger le défaut.- Vérifier si le correctif appliqué fonctionne en exécutant à nouveau

les tests unitaires appropriés.

Étape 5. Mettre à jour les enregistrements de traçabilité.Les enregistrements doivent être mis à jour en intégrant les informations suivantes :

- L’identification des cas de test.- L’identification des composants logiciels développés- Les dates de vérification (date à laquelle que le composant a

satisfait aux tests qui lui ont été soumis)

Étape 6. Incorporer les composants logiciels à la configuration du logiciel.Une fois le composant logiciel passe tous les cas de test et qu’il ne présente aucun défaut, il est incorporé dans la configuration du logiciel. La configuration du logiciel peut être réalisée efficacement à l’aide d’un logiciel de gestion de version.

© Prénom Nom


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étencesChef technique

CT Fortes connaissances et expériences techniques tant qu’au niveau de la technologie que les concepts d’architecture logiciel. Connaissance de la logique d’affaire du client.

Programmeur PR Connaissance de la technologie utilisée.

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

Comporte la liste des actions/réactions possibles de l’application. Un cas de test peut comprendre : - Identifiant - Description- É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- 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.

Composants logiciels Un ensemble d’unités de codes liées L'état possible est : tests unitaires réussis

© Prénom Nom


Un élément constitutif d'un logiciel qui devrait être testable et interchangeable. Le but ultime c’est de pouvoir réutiliser le composant dans des logiciels tiers sans la nécessité de grandes modifications.

Configuration du logiciel

Un ensemble de produits logiciels uniques et cohérents dont :- Spécification des exigences - LogicielRemarque: peut aussi inclure les caractéristiques additionnelles suivantes - Conception du logiciel - Enregistrement de la traçabilité - Composants logiciels - 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 : prêt à être livrée et acceptée.

Enregistrement de la traçabilité

Documente les liens entre les exigences énoncées dans la Spécification des exigences, les éléments de Conception du logiciel, les composants logiciels développés, les Cas et procédures de test. Il peut comprendre:

- Détermination des exigences qui doivent être retracées

- Mise en correspondance en aval et en amont des exigences par rapport aux Composants logiciels, aux Cas et aux procédures de test.

Les états possibles sont: vérifié, établi à titre de référence et mis à jour.

Modèle des tests unitaires

Ensemble de routines écrites dans un langage de programmation spécifique afin de tester les cas de test.

© Prénom Nom


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.

5.1.1 Gabarit de construction d’une classe java

Ce gabarit est tiré de [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]/****************************************************************************** Copyright (c) 20XX [Organization Name], Inc. All rights reserved.****************************************************************************** Version Number - $Revision$ Last Updated - $Date$ Updated By - $Author$

Summary of module purpose

Low-level design, physical design discussions, build dependencies, assumptions, implementation issues, notes, etc.

/***************************************************************************** Package and import statements*/

package com.mycompany.mypackage;import com.somepackage;

/***************************************************************************** Use these dividers to split the module into logical groups. *//***************************************************************************** Class Definitions*//*============================================================================ Summary of class goal ............................................................................ Description of class============================================================================*/public class JavaClass extends SuperClass implements SomeInterface {

© Prénom Nom


/*-------------------------------------------------------------------- Constructors ................................................................... Description of constructors --------------------------------------------------------------------*/ // Constructor 1 summary public JavaClass( ) {

} /*==================================================================== Public Member Functions */ /*-------------------------------------------------------------------- Summary of member function .................................................................... Description of function Describe function's exceptions and return values --------------------------------------------------------------------*/ public RETURN_TYPE SomeMethod( PARAM1_TYPE param1, // Description of param1 PARAM2_TYPE param2 // Description of param2 ) throws SomeException {

} /*==================================================================== Private Member Functions */ /*==================================================================== Protected Data Members */ protected boolean aBooleanValue;

/*==================================================================== Private Data Members */ private int anIntValue; }/*****************************************************************************/

5.1.2 Gabarit de test unitaire

Ce gabarit est tiré de http://www.cdrummond.qc.ca/cegep/informat/Professeurs/diane/Cours/420-DM2/420-DM2.html

Classe à tester Méthode à tester

© Prénom Nom


Classe de test Les tests sur cette méthode

1-2-3-

Date du test % de couverture du test

5.1.3 Gabarit de cas de test

Ce gabarit est tiré de [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng]Identifiant Description Entrants Résutats

attendus

5.1.4 Modèle de suivi des tests(Voire le fichier Outil_test_unitaire.xlsm) ce modèle a été traduit et adapté à partir du site [http://qastuff.wordpress.com/2012/01/12/simple-excel-dashboard-to-monitor-your-test-progress/ ]

5.2 OutilsLes outils proposés sont disponibles à titre de logiciels libres sur internet.

5.2.1 Bugzilla

Bugzilla est un logiciel libre de système de suivi de problèmes avec interface web, développé et utilisé par l'organisation Mozilla. Il permet le suivi de défauts ou des demandes de changement sous la forme de billets. [http://www.bugzilla.org/]

5.2.2 Outils de gestion de versions

o Subversion (SVN)o Concurrent Version System (CVS)o GITo Perforceo Microsoft Visual Source Safe (VSS)

5.2.3 Outils de traçabilité

o Objectifs:

© Prénom Nom

http://www.bugzilla.org/

http://qastuff.wordpress.com/2012/01/12/simple-excel-dashboard-to-monitor-your-test-progress/

http://qastuff.wordpress.com/2012/01/12/simple-excel-dashboard-to-monitor-your-test-progress/


Maintenir le lien entre chaque source d’une exigence et les activités réalisées durant le cycle de vie du projet

S’assurer que toutes les exigences sont développées. Faciliter l’analyse d’impact d’une demande de changement.

o Gabarit :Ce gabarit est tiré de [ISO/IEC 29110-5-1-2-DepPackage-Design-Eng].

© Prénom Nom


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

6.1 Exemple d’implémentation d’un objet

Spécification

On désire développer une calculatrice supportant les quatre opérations entières suivantes : Addition Soustraction Multiplication Division

Implémentation

/****************************************************************************** Copyright (c) 20XX [Organization Name], Inc. All rights reserved.****************************************************************************** Version Number - 0.1 Last Updated - 2013-03-02 Updated By - E.J.

Cette classe implémente les fonctionnalités qu’offre l’objet calculatrice./***************************************************************************** ============================================================================*/public class Calculatrice {

/*==================================================================== Public Member Functions */ /*-------------------------------------------------------------------- Summary of member function ....................................................................

© Prénom Nom

La conception est la suivante :Calculatrice

Sum (Entier A, Entier B) : EntierSubstract (Entier A, Entier B) : EntierProduct (Entier A, Entier B) : EntierDivide (Entier A, Entier B) : Entier


Cette fonction retourne la somme de deux entiers --------------------------------------------------------------------*/ public int Sum( a int, b int ) { return a + b; }

/*-------------------------------------------------------------------- Summary of member function .................................................................... Cette fonction retourne la différence entre deux entiers --------------------------------------------------------------------*/ public int Substract( a int, b int ) { return a - b; }

/*-------------------------------------------------------------------- Summary of member function .................................................................... Cette fonction retourne le produit de deux entiers --------------------------------------------------------------------*/ public int Product( a int, b int ) { return a * b; } /*-------------------------------------------------------------------- Summary of member function .................................................................... Cette fonction retourne la partie entière du quotient entre deux entiers lorsque le diviseur est plus grand que 0 --------------------------------------------------------------------*/ public int Divide( a int, b int )

© Prénom Nom


{ If (b != 0) { return a / b; } else { return 0; } }

}/*****************************************************************************/

6.2 Exemple de cas de test

Identifiant Description Entrants Résutats attendus

TC1 Teste la méthode Divide de la classe Calculatrice lorsque le diviseur est différent de 0.

A = 8 et B = 2 4

TC2 Teste la méthode Divide de la classe Calculatrice lorsque le diviseur est égal à de 0.

A = 8 et B = 0 0

6.3 Exemple de test unitaire

Classe à tester Méthode à tester

Calculatrice Divide

Classe de test Les tests sur cette méthode

TestCalculatrice1- Test lorsque le diviseur est différent de 02-Test lorsque le diviseur est égal à 0

Date du test % de couverture du test2013-03-01 100%

Implémentation de la méthode qui teste la méthode Divide

public void testDivide(){

© Prénom Nom


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

7.1 Développer ou modifier les composants

DC 1 CompréhensibilitéLa conception détaillée et la contribution des composants sont comprises

DC 2 RéutilisabilitéLes fonctionnalités disponibles dans les librairies standards sont utilisées

DC 3 Algorithme La logique des composants est définie

DC 4 Conformité Le code source est conforme au standard de constructionDC 5 Vérification Les composants sont vérifiés

7.2 Concevoir et mettre à jour les cas de tests ainsi que les tests unitaires.CT 1 Critères de succès Les critères de succès sont définis

CT 2 Complétude Les cas de test sont conçusCT 3 Développement Les tests unitaires sont développés

CT 4 Exécution Les tests unitaires sont exécutésCT 5 Analyse Les résultats sont analysés

7.3 Revue de codeCR1 Complet Tous les composants sont codésCR2 Logique Le flux du programme est cohérent par rapport à la conception.CR3 Boucles Les boucles sont initialisées et se terminent correctement.CR4 Appels Les appels de fonction correspondent à la définition du format et

du type de la fonction.CR5 Déclarations Chaque variable ou paramètre:

- a une seule déclaration- est utilisée en tenant compte de sa portée- s’écrit correctement partout où il est utilisé

CR6 Initialisation Chaque variable est initialiséeCR7 Limites L’utilisation des variables, tableaux et index ne provoquent pas de

dépassement.CR8 Booléen Les conditions booléennes sont correctes.CR9 Format Le format et l’orthographe des instructions sont corrects.CR10 Pointeurs L’utilisation des pointeurs est correcteCR11 Entrées-Sorties Le format des entrées et sorties est correctCR12 Orthographe L’orthographe des variables, paramètres, fonctions, ou procédures

est conforme au standard.CR13 Commentaires Les commentaires sont explicites et sont conformes au standardCR14 Calcul Les opérations arithmétiques et les équations sont conformes aux

algorithmes© Prénom Nom


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

Construction logicielle et tests unitaires - Étape 1 P

7.3.1 Planifier la conception et le développement du produit.

Aucune planification concernant la conception du produit


7.3.2 Identifier les entrants de la conception et du développement.

Aucune identification pour les entrants de a conception

Construction logicielle et tests unitaires - Étape 2, 3, 5 P

7.3.3 Générer la conception et les sorties du développement

Aucune production de conception


7.3.4 Effectuer des revues de conception et de développement.

Pas de revue de conception


7.3.5 Effectuer des vérifications de conception et de développement.

Pas de vérification au niveau de la conception

A7.3.6 Valider la conception et le développement

Aucune tache formelle de validation

Architecture et conception détaillée - Étape 2, 3, 4, 5 P

7.3.7 Gérer les changements au niveau de la conception et du développement.

Aucune gestion de changement au niveau de la conception.

© Prénom Nom


8.2 Matrice de couverture de l’ISO/IEC 12207


Tâches de l'ISO/IEC 12207 Commentaires

Construction logicielle et tests unitaires - Étape 1 C

6.3.1.3.3 Initialisation du projetSection - 6.3.1.3.3.3

Construction logicielle et tests unitaires - Étape 2, 3 C

7.1.5.3.1 Construction logicielle Section - 7.1.5.3.1.1

Construction logicielle et tests unitaires - Étape 2, 3, 4 C




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


Objectifs / Pratiques du

modèle CMMI V1.3Commentaires

Construction logicielle et tests unitaires - Étape 1 C

(TS)SG 3 Implémenter la conception du produitGP 2.8 Le processus de surveillance et de contrôle.


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

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.

© Prénom Nom



(REQM)SG 1 Gérer les exigencesSP 1.4 Maintenir une traçabilité bidirectionnelle des exigences.

Maintenir uniquement la traçabilité des composants développés

© Prénom Nom


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.

© Prénom Nom

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 – Construction et test unitaire – 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]

© Prénom Nom

mailto:[email protected]

deployment package – software requirements …profs.etsmtl.ca/claporte/vse/trousses/trousse...

Documents