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

Ébauche

Trousse de déploiement Implémentation logicielle

Profil d’entrée

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, expresse 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 que les Très Petites Organisations pourraient trouver utiles.

Auteurs G. Hernandez École de technologie supérieure (ÉTS), (Canada) W. Gonzalez - École de technologie supérieure (ÉTS), (Canada)

ÉditeurDate de création 09/08/2010Dernière mise à jour 1/12/2010Statut ÉbaucheVersion 0.1

© G. Hernandez, W. Gonzalez

Trousse de déploiement- Implémentation logicielle – Profil d’entrée / 41Version 0.2

Historique des versions

Date Version Auteur Modification09/08/2010 0.1 G. Hernandez

W. GonzalezTraduction de la version anglaise

1/12/2010 0.2 W. Gonzalez Mise à jour

Abréviations/acronymes

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

l’implémentation d’un groupe de pratiques, dans un contexte sélectionné, dans une Très Petite Organisation.

TPO Très Petit organisme – une entreprise, une organisation, un département ou un projet conformé d’au plus 25 personnes.

IL Implémentation logicielleISO Organisation internationale de normalisation/International Organization for

StandardizationIEC/CEI International Electrotechnical Commission/Commission Electrotechnique

InternationaleTR Technical ReportWBS Work Breakdown StructureSDP Structure de découpage du projet



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

But de ce document......................................................................................................................4Pourquoi l’implémentation logicielle est-elle importante ?............................................................4

Définitions....................................................................................................6Termes génériques (en ordre alphabétique).................................................................................6Termes spécifiques (en ordre alphabétique).................................................................................6

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

4.1. Les activités du processus d’implémentation logicielle (IL)....................................................94.1.1. Activité: IL.1 L'initiation de l’implémentation logicielle...................................................104.1.2. Activité: IL.2 L'analyse des exigences logicielles............................................................114.1.3. Activité: IL.3 L'identification des composants logiciels...................................................134.1.4. Activité: IL.4 La construction logicielle............................................................................154.1.5 Activité: IL.5 L'intégration logicielle et les tests...............................................................184.1.6. Activité: IL.6 La livraison du produit final........................................................................21

4.2 Description des rôles.............................................................................................................234.3. Description des produits......................................................................................................244.4. Description des artefacts.....................................................................................................28

5. Gabarits et outils....................................................................................305.1. Modèle pour l’initiation de l’implémentation logicielle.........................................................305.2. Modèle pour l’analyse des exigences logicielles...................................................................305.3 Modèle pour l’identification des composants logiciels...........................................................315.4 Modèle pour la construction logicielle...................................................................................315.5 Modèle de spécifications des tests........................................................................................325.6 Modèle pour la livraison du produit final...............................................................................34

6. Exemple du cycle de vie de l’implémentation logicielle..............................37Exemple du cycle de vie de l’implémentation logicielle...........................................................37

7. Listes de vérification...............................................................................387.1 Liste de vérification pour l’analyse d’exigences logicielles....................................................387.2 Liste de vérification pour l’identification de composants logiciels.........................................387.3 Liste de vérification pour la construction du logiciel..............................................................387.4 Liste de vérification pour l’intégration logicielle et les tests..................................................397.5 Liste de vérification pour la livraison du produit final............................................................40

8. Références..............................................................................................419. Formulaire d’évaluation...........................................................................42



1. Description TechniqueBut de ce documentCette trousse de déploiement (TD) supporte le profil d’entrée (Entry) tel que défini dans le document ISO/IEC TR 29110 Partie 5-1-1, Management and Engineering Guide [ISO/IEC29110]. Le profil d’entrée 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 de profil générique est composé de 4 profils: entrée (Entry), de base (Basic), intermédiaire (Intermediate) et avancé (Advanced). Le groupe des profils génériques n'implique pas un domaine spécifique d'application. Le profil d’entrée est destiné aux TPO qui travaillent sur de petits projets (par exemple, un projet dont l’effort est d’un maximum de six personnes-mois) et pour les TPO en démarrage (start-up). Ce profil fournit une base pour une migration vers les processus du profil de base (Basic).

Une trousse de déploiement est un groupe 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 intrants, les extrants, les rôles, les gabarits, les 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 pour é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.

Une fois publié par l'ISO, le document ISO/IEC TR 29110-5-1-1 sera disponible sans frais sur le site de l'ISO suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

Pourquoi l’implémentation logicielle est-elle importante ?

L’implémentation c’est l'exécution ou l’exécution d'un plan, d’une méthode pour faire quelque chose. Dans un contexte des technologies de l'information, l’implémentation englobe tous les processus impliqués dans l'obtention d’un nouveau logiciel ou d’un matériel informatique opérant correctement dans son environnement, y compris l'installation, la configuration, la mise en exploitation, le test et l’exécution des changements nécessaires.L'importance d'avoir ce processus se base dans l'analyse systématique et la façon d'effectuer les tâches. Chaque activité a pour but d’atteindre des objectifs stipulés dans la charte de travail et dont le but ultime est de réaliser le produit final avec tous les attributs exigés par le client avec un haut niveau de qualité.

L'importance des activités d’implémentation logicielle est décrite comme suit: © G. Hernandez, W. Gonzalez

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


L'activité d’initiation de l’implémentation logicielle permet de s’assurer que tous les membres de l’équipe de travail ont bien compris le plan du projet et se sont engagés à le respecter. Cette activité s’assure aussi que l’environnement nécessaire pour accomplir le travail est disponible.

L'activité d’analyse des exigences logicielles est importante pour bien définir la portée du projet et identifier les fonctionnalités clés du système avec le client pour éviter des problèmes comme des fonctionnalités oubliées ou des exigences mal comprises.

L'activité d’identification des composants Logiciels est une phase clé dans un projet logiciel. Une architecture inadéquatement dessinée est une recette pour l’échec. Le client ne réalisera pas le paiement si la conception ne correspond pas à ses exigences.

L’activité de construction logicielle est une phase clé pour les programmeurs qui produiront des composants sous une approche systématique, cette approche peut être utilisée aussi pour construire des composants complexes.

L'activité d’intégration logicielle et les tests permettent d'exécuter de différents types de tests et d’identifier les erreurs qui doivent être corrigées par l'équipe de développement logicielle.

L’activité de livraison du produit final comprend différentes tâches, il ne devrait pas y avoir de surprise, ni aucun retard pour obtenir l'acceptation du produit à livrer. Autrement, le client ne réalisera pas les paiements au TPO.



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éfini les termes utilisés dans cette trousse de déploiement, c'est-à-dire, les termes spécifiques.

Termes génériques (en ordre alphabétique)Activité: ensemble de tâches liées. [ISO/IEC 12207].Artefact: produit tangible résultant d’un processus de développement des logiciels. (c.à.d. les cas d’utilisation, plan du projet, document des exigences).Étape: Dans une trousse de déploiement, une tâche est décomposée en séquence d’étapes.Processus: ensemble d’activités corrélées ou en interaction, qui transforme éléments d’entrée en éléments de sorite. [ISO/IEC 12207].Produit: ensemble d’information ou un livrable qui peut être produit (non-obligatoire) par une ou plusieurs tâches. (c.à.d. le document de dessin, le code source). Rôle: une fonction définie à être exécutée par un membre de l’équipe du projet. Tel que testeur, inspecteur, codeur. [ISO/IEC 24765]Sous-Tâche: Si une tâche est complexe, elle est devisée en sous-tâches.Tâche: action requise, recommandée ou permise destinée à contribuer l’accomplissement d’un ou plusieurs résultats d’un processus. [ISO/IEC 12207].

Termes spécifiques (en ordre alphabétique)Accord: La définition des termes et des conditions sous lesquelles une relation travail sera conduite. [ISO/IEC 12207]Analyse des exigences: Le processus d’étudier les besoins de l’utilisateur final pour parvenir à la définition d’un système, un matériel logiciel, ou des exigences logicielles. [ISO/IEC 24765]Composant: ensemble de services fonctionnels dans le logiciel, qu’en étant implémenté, représente un ensemble bien défini de fonctionnalités et est distinguable par un nom unique. [ISO/IEC 24765]Défaut: Un problème qui, n’étant pas corrigé, pourrait occasionner dans l’application une faillite ou des résultats incorrects. [ISO/IEC 24765].Document des exigences: Un document contenant une combinaison de recommandations, des exigences ou des règlements à être rencontrés par un progiciel. [ISO/IEC 24765]Environnement d’Implémentation : Le matériel, le logiciel et des protocoles nécessaires pour effectuer l’implémentation.Exigences Non-Fonctionnelles: Une exigence logicielle décrit comment le logiciel fonctionnera. ISO/IEC 24765, Vocabulaire en Génie Logiciel et des Systèmes. Syn. des contraintes de conception, l'exigence non-fonctionnelle. Voir aussi : exigence fonctionnelle. NOTEZ Par exemple, des exigences de performance logicielles, des exigences d'interface externes logicielles, des contraintes de dessin logicielles et des attributs de qualité logiciels. Les exigences non-fonctionnelles sont parfois difficiles de tester, donc ils sont d'habitude évalués subjectivement. [ISO/IEC24765]



État de disposition d’utilisation (Release): Une version particulière d'un élément de configuration qui est rendu disponible pour un but spécifique (par exemple, la disponibilité d’utilisation des tests). [ISO/IEC 12207]Exigence: 1. Une déclaration qui identifie ce qu'un produit ou un processus doivent accomplir pour produire le comportement exigé et/ou des résultats. IEEE 1220-2005 Norme IEEE pour l'Application et la Gestion du Processus d'Ingénierie de Systèmes. 3.1.16. 2. Une exigence logicielle ou d’un système qui spécifie une fonction qu'un système ou un composant d’un système/logiciel doit être capable d'exécuter. ISO/IEC 24765, Vocabulaire en Génie Logiciel et des Systèmes. 3. Une exigence qui spécifie une fonction qu'un système ou un composant de système doit pouvoir réaliser. [ISO/IEC 24765]Environnement des tests logiciels: L’environnement de tests logiciels qui satisfait les exigences d’exécution des tests et dans lequel les changements doivent être contrôlés pour permettre la régression si nécessaire. [Deployment Package - Software Testing - Basic Profile]Livraison: mis en opération d'un système ou d'un composant pour un client ou un utilisateur final. [ISO/IEC 24765]Produit: le résultat d’un processus. [ISO/IEC 12207]Référentiel (baseline): une spécification ou un produit qui a été formellement révisé et convenu, celui-ci sert ensuite de base pour un nouveau développement et peut être changé seulement par des procédures de contrôle de changement formelles. [ISO/IEC 12207] Structure de découpage du projet (SDP) (Work Breakdown Structure, WBS) : Décomposition hiérarchique, axée sur les livrables, du travail que l'équipe du projet doit exécuter pour atteindre les objectifs du projet et produire les livrables voulus. La SDP organise et définit le contenu total du projet (PMBOK).



3. Liens avec l’ISO/IEC 29110

Cette trousse de déploiement présente les activités liées à la gestion de projets du rapport technique ISO/IEC 29110 Partie 5-1-1 pour les très petits organismes (TPO) - le Groupe des profils génériques : profil d’entrée [ISO/IEC 29110].Le guide présente les processus de gestion de projets et d’implémentation logicielle lesquels intègrent des pratiques basées sur la sélection d'ISO/IEC 12207-systèmes et génie logiciel – Le processus du cycle de vie logiciel: 2008 et ISO/IEC 15289 systèmes et génie logiciel - le Processus de cycle de vie Logiciel - les lignes directrices pour le contenu du cycle de vie logiciel traitent des produits de l'information (documentation) :2006 éléments des normes.Le but du processus de gestion de projets est d'établir et effectuer d'une façon systématique les tâches du projet d’implémentation logicielle, qui permet maintenir les objectifs du projet dans la qualité attendue, le temps et le coût.Le but du processus d’implémentation logicielle est l'exécution systématique de l'analyse, la conception, la construction, l'intégration et les tests pour des produits logiciels nouveaux ou modifiés selon les exigences indiquées. Une autre trousse de déploiement décrit le processus de gestion de projets.Les deux processus sont en interaction (voir Figure 1).

Implémentation du logiciel

Énoncé des travaux

Configuration du logiciel

Gestion de projet

Figure 1 — Guide de processus du profil d’entrée(L’implémentation logicielle est présentée à la section 4)



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 d’implémentation logicielle et montre les produits de travail les plus importants.

Figure 2 — Diagramme du processus d’implémentation logicielle du profil d’entrée (ISO/IEC 29110)

4.1. Les activités du processus d’implémentation logicielle (IL)

Le but du processus d’implémentation logicielle est l'exécution systématique de l'analyse, la © G. Hernandez, W. Gonzalez

L’initiation de l’implémentation

logicielle

L’analyse des exigences

logicielles

L’identification des composants

logiciels

La construction logicielle

L’intégration logicielle et les

tests

La livraison du produit final

Plan de projet

Dépôt d’information

du projet

Rapport des tests


Spécification des exigences

logicielles

Identification des composants

logiciels

Composants du logiciels

Logiciel

Cas de tests et procédures de

tests


conception, la construction, l'intégration et les tests des activités des nouveaux produits logiciels ou modifiés selon les exigences indiquées.

Le processus d’implémentation logicielle est composé des activités suivantes:

· IL.1 L'initiation de l’implémentation logicielle· IL.2 L'analyse des exigences logicielles· IL.3 L'identification des composants logiciels· IL.4 La construction logicielle· IL.5 L'intégration logicielle et les tests· IL.6 La livraison du produit final

4.1.1. Activité: IL.1 L'initiation de l’implémentation logicielleL'activité d'initiation de l’implémentation logicielle assure que le plan de projet établi pendant la planification du projet est présentée à l'équipe de travail afin d’obtenir leur engagement. Cette activité fournit:

- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de tâches.- Un environnement d’implémentation logicielle.

Liste de tâches Produits d’entrée Produits de sortie

Rôle

IL.1.1 Révision du plan de projet avec les membres de l'équipe afin d'arriver à une compréhension commune et obtenir leur engagement pour le projet.

Plan de projet Plan de projet [révisé]

CPET

IL.1.2 Définir ou mettre à jour l'environnement de l'implantation.

Plan de projet ET

L'initiation de l’implémentation logicielle

Objectifs: Comprendre le plan du projet par les membres de l'équipe de travail et identifier et mettre en place les éléments de l'environnement de l’implémentation logicielle.

Justification: Cela permet de préparer l’équipe de travail pour les activités et acquérir et installer les outils nécessaires pour accomplir le travail.

Rôles: Chef de Project Équipe de travail

Artefacts: Plan du projetÉtapes: Étape 1: Révision du plan de projet avec les membres de l'équipe.

Étape 2: Mettre en place l’environnement d’implémentation.Description des Étape 1: Révision du plan de projet avec les membres de l'équipe.



tapes: Le chef de projet devrait organiser une rencontre avec tous les participants ou l'équipe de travail pour assurer la pleine compréhension du projet et ses objectifs. Le chef de projet devrait être sûr que chaque membre de l'équipe a été convoqué à la rencontre.À la fin de la réunion, le chef de projet devrait vérifier que toute l'équipe de travail comprend et accepte leur engagement au projet.Étape 2: Mettre en place l’environnement d’implémentation.Pendant cette étape, les conditions de l'environnement sur lequel l’implémentation sera exécutée, l'empressement et la disponibilité des composants et les données qui seront utilisées pour cette exécution sont préparées. L'objectif est de définir un environnement contrôlé et indépendant pour l’implémentation.

4.1.2. Activité: IL.2 L'analyse des exigences logicielles

Cette activité analyse les exigences du client, déjà convenues, et établit les exigences logicielles validées du projet. L'activité fournit :

- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de tâches.- L’élicitation, l’analyse et la spécification des exigences du client. - L’accord des exigences du client.- La vérification et validation des exigences logicielles.

Liste de tâches Produits d’entrée

Produits de sortie

Rôle

IL.2.1 Assigner les tâches aux membres de l’équipe de travail en accord à leurs rôles en se basant sur le plan du projet.

Plan du projet CP

ETIL.2.2 Documenter ou mettre à jour les spécifications des exigences.-Identifier et consulter les sources d'information (clients, utilisateurs, systèmes antérieurs, documents, etc.) afin de trouver d’autres exigences.- Vérifier la pertinence et la testabilité des spécifications d'exigences et sa cohérence avec la description du produit.Collecter et analyser les exigences identifiées afin de déterminer la portée et la faisabilité.-Générer ou mettre à jour les spécifications des exigences logicielles (SRS).

Plan de projet [description du produit]

Spécifications des exigences

ET

CL

IL.2.4 Valider et obtenir l'approbation des spécifications d'exigences.Valider que les spécifications d'exigences satisfassent les besoins et les attentes du client comme convenu, y compris l’interface de

Spécifications des exigences

Spécifications des exigences (validées)

CL




Produits de sortie

Rôle

l’utilisateur.

Analyse des exigences logicielles

Objectifs: L'objectif de cette activité est de définir clairement la portée du projet et identifier les exigences clés du système.

Justification: Il est important de définir clairement la portée du projet (des frontières) et identifier les fonctionnalités clés du système avec le client pour éviter des problèmes comme des fonctionnalités clés oubliées ou les exigences mal comprises.

Rôles: Équipe de travailClient

Artefacts: Document d’exigences logiciellesÉtapes: Étape 1 : Collecter l’information sur le domaine d'application (par

exemple les finances, médical)Étape 2 : Identifier la portée du projetÉtape 3 : Identifier et capturer les exigencesÉtape 4 : Structurer et prioriser les exigences

Description des étapes:

Étape 1. Collecter l’information sur le domaine d'applicationPendant cette étape, l’analyste capture les concepts clés du domaine d'affaires du client. Le client aide l'analyste en le donnant toutes les informations (la documentation existante ou l'explication) qui facilitera cette compréhension.Des concepts clés sont inscrits dans une section du glossaire dans le document d’ébauche du document de spécification des exigences logicielles.

Étape 2. Identifier la portée du projetL'analyste logiciel, aidé par la personne étant responsable des aspects contractuels du projet (le directeur commercial) identifie clairement les fonctionnalités principales qui sont incluses dans la portée du projet.Conseil: l'Identification des fonctionnalités qui sont HORS de la portée est aussi de valeur pour clarifier les différences de compréhension avec vos clients.

Étape 3. Identifier et capturer les exigencesEntendant les concepts clés liés au domaine d'affaires du client,



l'analyste peut commencer l'identification d'exigences. Aucune des situations dans des projets informatiques n'est identique. Dans quelques cas, la plupart des exigences sont déjà identifiées dans un document (l'appel d'offres dans le cas des projets évalués à prix fixe). Cependant, dans la plupart des cas, des exigences clés sont juste (oralement) mentionnées par le client.L'analyste doit identifier et inscrire les exigences clés du système à être construit. Pendant cette étape, l’analyste ne devrait pas commencer à détailler des exigences identifiées. Le but principal est de gagner une vue complète des pré-requis techniques.

Étape 4. Structurer et prioriser les exigences:En utilisant des exigences identifiées dans l'étape précédente, l'analyste doit organiser et structurer les exigences identifiées en conséquence (par exemple, par des processus commerciaux ou par des fonctions de système).Les priorités doivent être identifiées par le client pour des fonctionnalités de clé de système. Les priorités peuvent être définies comme suit :

· 'Haute' - une fonctionnalité qui devra être implémentée.· 'Moyenne' - une fonctionnalité qui devrait être

implémentée.· 'Basse' - une fonctionnalité qui pourrait être implémentée.

Le produit sortant de cette étape est une liste d'exigences qui sont organisées dans le document des exigences.

4.1.3. Activité: IL.3 L'identification des composants logiciels

L'activité d'identification de composants logiciels transforme les exigences logicielles à l'architecture des composants logiciels du système. L'activité fournit :

- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de tâches.- Identifier, documenter ou mettre à jour les composants logiciels.

Liste de tâches Produits d’entrée Produits de sortie RôleIL.3.1 Assigner les tâches aux membres de l’équipe de travail en accord à leurs rôles en se basant sur le plan du projet.

Plan du projet ETCP

IL.3.2 Comprendre les spécifications des exigences.

Spécifications d'exigences

ET

IL.3.3 Documenter ou mettre à jour la conception du logiciel.-Analyser les spécifications d'exigences

Spécifications d'exigences

Composants du logiciel [Identifiés]

ET



Liste de tâches Produits d’entrée Produits de sortie Rôleafin de générer la conception de l'architecture, ses dispositions dans le sous-système et les composants du logiciel définissant les interfaces internes et externes. -Fournir en détail les composants du logiciel et ses interfaces afin de permettre la conception de manière apparente.

L'identification des composants logiciels

Objectifs: Identifier les composants logiciels qui répondront aux exigences demandées par le client, qui seront évalués avant la sortie à production et vérifier que toutes les exigences sont accomplies.

Justification: L'identification de composants logicielle est une activité clé d'un projet logiciel. Une architecture inadéquatement dessinée est une recette pour l’échec. Le client ne finalisera pas le paiement si le dessin ne répond pas à ses exigences.

Rôles: Équipe de travail

Artefacts:Spécifications d'exigencesConfiguration du logiciel

Produits: Diagramme UML ou BPMN Étapes: Étape 1 : Comprendre les spécifications d'exigences

Étape 2 : Documenter ou mettre à jour les composants logicielsDescription des étapes:

Étape 1. Comprendre les spécifications d'exigences logicielles o Examinez chacune des exigences et assurez-vous qu'elles soient

comprises et groupées : - Exigences Fonctionnelles dans les groupes logiques.- Exigences Non-fonctionnelles groupées.

o Vérifiez les groupes et si les exigences ont été comprises.o Si nécessaire, mettez à jour le document des spécifications

d’exigences logicielles pour ajouter les clarifications nécessaires.o Gardez la documentation mise à jour dans le dépôt d’information

du projet. Étape 2. Documenter ou mettre à jour les composants logiciels

o Analysez les spécifications d'exigences pour produire les composants, arrangez-les dans des sous-systèmes et des composants des interfaces internes et externes.

o Décrivez en détail l'apparence et le comportement de l'interface, basés sur la spécification d'exigences d’une façon que les ressources pour son implémentation puissent être



prévues. o Fournissez le détail de Composants et leurs interfaces pour

permettre visualiser sa construction de façon facile.

4.1.4. Activité: IL.4 La construction logicielle

L'activité de construction Logicielle développe le code logiciel et les données des composants logiciels identifiés dans l’IL.3. L'activité fournit :

- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de tâches.

- Comprendre les composants logiciels identifiés.- Les cas des tests et les procédures des tests pour l’intégration des unités développées.- Composants logiciels codés et tests d'unité appliqués.

Liste de tâches Produits d’entrée Produits de sortie RôleIL. 4.1 Assigner les tâches aux membres de l’équipe de travail en accord à leurs rôles en se basant sur le plan du projet.

Plan du projet CPET

IL.4.2 Comprendre la conception du logiciel.

Identification des composants du logiciel

ET

IL.4.3 Réaliser ou mettre à jour les composants du logiciel.


Composants du logiciel ET

IL. 4.4 Établir ou mettre à jour des scénarios de test et des procédures de tests pour l'intégration des unités basées sur les spécifications d'exigences et l'identification des composantes logicielles.Le client fournit des données de test, si nécessaire.

Spécifications d'exigences (validées)


Cas de tests et procédures de tests

ET

IL.4.5 Tester les composants du logiciel.


Composants du logiciel [testés] ET



Liste de tâches Produits d’entrée Produits de sortie RôleCorriger les défauts trouvés jusqu'à ce que les tests unitaires soient testés avec succès

Composants du logiciel

Construction logicielle

Objectifs: Développer les composants du logiciel identifiés.Justification: Certains programmeurs font confiance à ses connaissances pour

développer des produits logiciels sans une approche systématique, cependant, certains d'entre eux peuvent le trouver utile pour construire des composants complexes. Il y a plusieurs approches pour produire des composants. Ici on utilise l'approche de pseudocode qui est un des plus répandus et acceptés.

Rôles: Équipe de travailArtefacts: Composants du logicielÉtapes: Étape 1 : Dessiner les composants

Étape 2 : Codifier les composants Étape 3 : Vérifier les composants


Étape 1. Dessiner les composants a) Vérifier la contribution des composants.

Comprendre la contribution que les composants fournissent au produit final.

b) Définissez le problème à résoudre par les composants. Établir le problème que le composant résoudra en décriant les détails pour faciliter son développement. Si l’information n’est pas suffisante, le programmeur devrait la compléter avec le soutien de l’analyste.

c) Recherchez des fonctionnalités disponibles dans des bibliothèques standards.Découvrez si les fonctionnalités des composants pourraient être déjà disponibles dans les bibliothèques du langage de programmation, la plateforme ou les outils que vous utiliserez.

d) Écrivez le pseudocode. Commencez par écrire le pseudocode de façon générale et après, continuez vers quelque chose plus spécifique. La partie la plus générale d'un Composant est un commentaire d'en-tête, en décrivant ce que l'on suppose que le composant fait. Écrivez d'abord, une déclaration concise du but du Composant, par la suite, décomposez les déclarations dans plusieurs déclarations de niveaux



plus bas, en visant toujours la perfection. Après la création de la tendance du Composant en incluant le traitement d'erreur et la gestion de toutes les choses qui pourraient mal tourner dans le composant, comme : la saisie de mauvaises valeurs, des valeurs invalides retournées d'autres routines, etcetera.

e) Conceviez les données des composants. Définissez les types de données clés

f) Vérifiez le pseudocode. Passez revue au pseudocode, si vous n'êtes pas très confiant de lui, expliquez-le à quelqu'un d'autre (pourrait être l’Analyste), cette explication aidera à clarifier vos idées et peut améliorer le pseudocode.

Étape 2. Codifier les composants

a) Écrivez la déclaration du composant. Convertissez la déclaration en-tête originale en des commentaires de langage de programmation.

b) Convertissez le pseudocode en commentaires de haut niveau.

c) Remplissez le code au-dessous de chaque commentaire Remplissez le code au-dessous de chaque ligne de commentaire de pseudocode. Chaque commentaire de pseudocode décrit un bloc ou un paragraphe de code.

d) Vérifiez si le code devrait inclure de nouveaux composants. Dans quelques cas, vous aurez beaucoup de code au-dessous d'une des lignes initiales de pseudocode. Dans ce cas, vous devriez considérer de créer un sous-composant.

Étape 3. Vérifiez le composant

Cette étape consiste à une revue de code exécuté par le programmeur, une compilation et un débogage.

a) Faites une revue du code

- Vérifiez le programme contre les exigences identifiées pour assurer que toutes les fonctions de programme exigées sont implémentées.

- Suivez la liste de contrôle de la revue du code fournie dans la section 7, trouvez les défauts dans le programme.

- Dans la revue, marquez les défauts sur le code source. - Après la revue du code, corrigez tous les défauts.- Après l'achèvement des corrections, produisez une liste du

programme source pour le programme corrigé.- Passez en revue toutes les corrections pour assurer qu'ils soient



corrects.- Corrigez n'importe quels défauts restants.

b) Compiler le codeLaissez que l’ordinateur vérifie sur des variables non déclarées, des conflits de noms, etcetera. Vous pouvez l'avoir fait avant la revue du Code aussi.

c) Passez à travers du code avec le débogueur Une fois que la routine compile, exécutez le programme débogueur et passez par chaque ligne de code. Assurez-vous que chaque ligne exécute comme vous vous y attendez. Vous pouvez le faire après les tests d'unité en vous concentrant dans la découverte de la source d'un défaut.

4.1.5 Activité: IL.5 L'intégration logicielle et les tests

L'intégration logicielle et les tests assurent que les composants logiciels intégrés satisfont les exigences logicielles. L'activité fournit :

- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de tâches.

- Compréhension des cas de tests, les procédures de tests et l’environnement d’intégration.

- Les composants logiciels intégrés, défauts corrigés et résultats documentés.


Produits de sortie Rôle


Plan du projet CPET

IL.5.2 Comprendre les cas de tests et les procédures de tests. Préparer ou mettre à jour l’environnement d’intégration.


ET

IL.5.3 Intégrer le logiciel en utilisant les composants du logiciel et mettre à jour les cas de tests et les procédures de tests pour test d’intégration.

Composants de logiciel Cas de tests et procédures de tests

Logiciel Cas de tests et procédures de tests (mis à jour)

ET

IL.5.4 Exécuter les tests pour l'intégration et documenter les résultats

LogicielCas de tests et procédures de

Logiciel [testé]Rapport de test

ET



dans un rapport de test. testsIL.5.5 Corriger les défauts trouvés jusqu'à que le test soit testé avec succès.

Logiciel [testé] Rapport de testCas de tests et procédures de tests

Logiciel [corrigé]

Rapport de test [défauts éliminés]

ET

IL.5.6 Incorporer le rapport de tests et le logiciel à la configuration du logiciel.

Logiciel [testé]Spécifications d'exigences

Configuration du logiciel- Logiciel- Spécifications

d'exigences

ET

Intégration logicielle et les tests

Objectifs: Identifier la stabilité du produit logiciel par les résultats obtenus, en exposant le produit aux tests.

Justification: Permet d'exécuter les différents types de tests et identifier les défauts qui doivent être corrigés par l'équipe de développement logicielle. Les différents types de tests sont exécutés au fur et à mesure du développement.

Rôles: Client Équipe de travail

Artefacts: Rapport de tests

Étapes:

Étape 1: Préparez l'environnement de tests du logiciel Étape 2: Exécutez des itérations de testÉtape 3: Exécutez des tests de régression Étape 4: Complétez la procédure de testsÉtape 5: Documentez les résultats dans le Rapport de tests


Étape 1: Préparez l'environnement de tests du logiciel Pendant cette étape, les conditions de l'environnement sur lequel les tests seront exécutés; l'empressement et la disponibilité de composants (corrigés) à être évalués et les données qui seront utilisées pour cette exécution sont préparés. L'objectif est de définir un environnement contrôlé et indépendant pour les tests. La préparation de l'environnement de test inclut : Les spécifications de la configuration de machine, le système d'exploitation, le navigateur et la configuration de TCP/IP quand il s'applique; les spécifications logicielles du système, le moteur de base de données et le moteur de support des tests.Quant au test des données, quand l'application est complètement nouvelle, les tests sont exécutés dans l'ordre nécessaire, charger manuellement les données initiales;



autrement, les données d'un client déjà en exécution, c'est-à-dire, des données de production seront réutilisées.

Étape 2: Exécutez des itérations de tests Avant l'exécution, il est nécessaire de garantir que l'analyste assigné comprenne les tests.Une itération de test correspond à l'exécution de tests. L’itération de test est faite une fois que l'équipe de développement a exécuté les tests d'unité. Selon la stabilité de l’application, l'analyste peut décider, dans chaque itération, exécuter toutes les exigences de test identifiées ou juste un sous-ensemble représentatif. Le but est d’accomplir une relation de bénéfice efficace entre l'effort investi dans l'exécution et le nombre des défauts ou problèmes trouvés.

Par l'exécution de tests, l'analyste trouve des écarts aux résultats attendus, catalogués comme des « défauts » du produit. Les défauts du produit identifiés sont caractérisés et enregistrés dans le suivi de test et le rapport de contrôle qui peut être aussi un outil de raffinement.Pour la classification des défauts, les définitions suivantes peuvent être prises en considération :Bloqueurs: Ce type de défaut arrête une opération du programme/composant en faisant rapporter les résultats qui empêchent l'opération continue. Fonctionnel : Cela arrive quand un programme est exécuté et ses résultats ne correspondent pas aux résultats attendus.Présentation : Relié à la présentation de produit. Celle-ci doit s'adapter aux normes définies et les règles grammaticales et orthographiques de la langue dans laquelle le programme est montré.

Étape 3: Exécutez des tests de régression L'objectif est de s'assurer que le nouveau code ou celui modifié (pour fournir une solution aux défauts identifiés pendant les tests) accomplit avec les exigences indiquées et que le code non-modifié n'a pas été affecté par l'activité de maintenance.Les tests de régression commencent leur exécution aussitôt que le groupe technique livre la solution des défauts ou ajoute des nouvelles caractéristiques au logiciel et qui sont appliquées dans le test l'environnement contrôlé. Pour réaliser une procédure efficace, il est possible de combiner le test de régression avec une itération de test.Étape 4: Complétez la procédure de tests Une fois les itérations prédéfinies de tests ont été achevées et les défauts identifiés ont été résolus, une analyse pour démontrer qu'il y a une tendance continue de diminuer le nombre des défauts est effectué. La fermeture de la procédure de tests est



faite en élaborant un rapport de fermeture, qui décrit la procédure exécutée et montre les conclusions avec des recommandations correspondantes pour l'amélioration du produit et les processus. Ces recommandations font partie des leçons apprises qui sont la base de la TPO. L'équipe de développement décide de sortir le produit logiciel à production, selon les résultats obtenus dans les tests.

Étape 5: Documentez les résultats dans le Rapport de tests L'analyste ou le programmeur doivent préparer un rapport de test pour chaque itération de test effectuée comme minimum. Le rapport doit contenir la condition actuelle du produit. Le rapport doit être passé en revue par tous les membres de l'équipe du projet et ils doivent établir des engagements pour la nouvelle itération de test.

4.1.6. Activité: IL.6 La livraison du produit final

L'activité de livraison de produit fournit au client le produit logiciel intégré. L'activité fournit :- La révision du plan de projet de l'équipe de travail pour déterminer l’assignation de

tâches.- Livraison du produit logiciel et de la documentation applicable conformément au

Plan de Projet.


Produits de sortie Rôle


Plan du projet ETCP

IL.6.2 Comprendre la configuration du logiciel.


ET

IL.6.6 Effectuer la livraison selon les instructions de livraison.

Plan de Projet,


Configuration du logiciel [livré]

ET

Livraison du produit final

Objectifs: Conduire les activités de livraison en cours tel que, à la fin du projet, chaque élément à fournir est disponible et satisfait les critères d'acceptation définis dans les instructions de livraison.

Justification: En conduisant les activités en cours, il ne devrait y avoir aucune © G. Hernandez, W. Gonzalez


surprise, aucun retard pour obtenir l'acceptation d'éléments à fournir. Autrement, le client ne finalisera pas les paiements au TPO.

Rôles: Équipe de travail

Produits: Configuration du logicielRegistre d’acceptation

Artefacts: Plan du ProjetInstructions de livraison approuvéesRegistre d’acceptation

Étapes: Étape 1 : Comprendre la configuration du logiciel.Étape 2 : Effectuer la livraison selon les instructions de livraison.


Étape 1. Comprendre la configuration du logiciel. Obtenez, du plan de projet, les conditions de livraison.

Construisent/Obtiennent la ligne des bases de produit- L'équipe de travail prépare les éléments à fournir. - L'équipe de travail établit les bases pour la

configuration de produit incluant l'environnement, le manuel approprié, la documentation importante et le produit configuré.

Étape 2. Effectuer la livraison selon les instructions de livraison. Vérifiez que chaque composant logiciel satisfait les critères d'acceptation.

Mettez à jour le Formulaire Registre d'acceptation Planifiez une rencontre avec le client Obtenez l'approbation du client dans le Formulaire

Registre d'acceptation - Le client signera le Formulaire.- Donnez une copie du Formulaire Registre

d'acceptation au client Stockez le Formulaire d'acceptation dans le dépôt

d’information du projet.

4.2 Description des rôlesCelle-ci est une liste alphabétique des rôles, ses abréviations et la description des compétences suggérées. Cette liste est montrée comme une table à quatre colonnes pour le but de présentation seulement.

Rôle Abréviation



1. Client CL Connaissance des processus de l’organisation et habileté à exprimer les exigences du produit.Le client (représentant) doit avoir l’autorité d’approuver les exigences et leurs changements. Le client inclut les représentants d’utilisateurs afin d’assurer que l’environnement opérationnel soit bien dirigé.Connaissances et expérience dans le domaine de l’application.

2. Chef de Projet

CP Capacité de leadership avec l’expérience à la prise de décisions, planification, gestion de personnel, délégation et supervision, finances et développement des logiciels.

3. Équipe de Travail

ÉT Connaissances et expérience en accord à leurs rôles dans le projet.

4.3. Description des produits

Celle-ci est une liste alphabétique des produits d’entrée, de sortie et internes des processus, leurs descriptions, les états possibles et la source du produit. La source peut être un autre processus ou une entité externe au projet, comme le client. Cette liste est montrée comme une table à quatre colonnes pour le but de présentation seulement. Les articles de produit dans les tables suivantes sont basés sur les Éléments de l'information d’ISO/IEC 15289 avec quelques exceptions.

Nom Description Source1. Lettre

d’acceptationDocuments d'acceptation du client des produits livrables du projet. Il peut avoir les caractéristiques suivantes:

- Compte rendu de la réception de la livraison- Date de réception- Identification des produits livrés- Compte rendu de la vérification du client des

livrables selon l'accord du client.- Identification des questions à résoudre (si c'est

approprié)- Signature du client

Gestion de Projet

2. Demande de changement

Identifie un problème du logiciel ou de la documentation, ou une amélioration désirée, et les demandes de modifications. Il peut avoir les caractéristiques suivantes:

- Identification du but du changement- Identification de l’état de la demande (nouvelle,

acceptée, rejetée)

Implémentation logicielleClientGestion de Projet



Nom Description Source- Identification du renseignement du demandeur- Système affecté (s)- Impact au fonctionnement du système existant

(s)- Impact à la documentation associée- Criticité de la demande et date nécessaire.

Les statuts applicables sont : en cours, acceptée.3. Enregistremen

t de réunionsEnregistre les accords établis avec le client et/ou l’équipe de travail. Il peut avoir les caractéristiques suivantes:

- But de la réunion- Les participants- Date et endroit- Références de la dernière minute- Identification des questions posées- Toutes les questions à résoudre- Accords- Prochaine réunion (si c'est approprié)

Le statut applicable est : mis à jour

Gestion de Projet

4. Compte-rendu de l’état du projet.

Enregistre l'état du projet contre le plan de projet.

Il peut avoir les caractéristiques suivantes :· État des tâches actuelles par rapport aux tâches planifiées· État des résultats actuels par rapport aux buts et objectifs établis· État de l'affectation actuelle des ressources par rapport aux ressources prévues· État du coût actuel par rapport au budget estimé· État du temps actuel par rapport au calendrier prévu· État des risques actuels par rapport à euxprécédemment identifiés Enregistre tous les écarts par rapport à des tâches planifiées et des raisons. Le statut applicable est : évalué

Gestion de Projet

5. Plan de Projet Il présente la façon dans laquelle les processus et les activités du projet seront exécutés pour assurer l’accomplissement réussi du projet. Il inclut les éléments suivants qui peuvent avoir des caractéristiques comme suit:

- Description du produit o Buto Exigences générales du client

- Description de la portée avec ce qui est inclus et ce qui n'est pas.

- Livrables : Liste des produits à livrer au client- Les tâches, y compris des revues avec le client et

Gestion de Projet



Nom Description Sourcel’équipe de travail pour assurer la qualité des produits. Les tâches peuvent être représentées comme une structure de découpage du projet (Work Breakdown Structure (WBS)).

- Relation et dépendance des tâches.- Durée estimée des tâches- Ressources (humains, matériaux, normes,

équipement et outils) et le calendrier d’utilisation des ressources.

- Identification du rôle et des responsabilités de l’équipe de travail.

- Calendrier des tâches du projet avec le début prévu et la date d'accomplissement de chaque tâche.

- Estimation de l’effort et du coût- Identification de la configuration logicielle

o Dépôt du Projeto Liste d'articles avec l'information de la

version correspondante

Le statut applicable est: accepté6. Dépôt

d’information du projet

Récipient électronique pour stocker des produits et livrés du projet. Il peut avoir les caractéristiques suivantes :

- Stocke des produits de travail de projet- Stocke des produits livrables libérés- Stocke les mesures du projet- Capacité de stockage et de récupération- Capacité de passer en revue (à parcourir) le

contenu- Liste de contenu avec la description des attributs- Partage et transfert des produits de travail entre

l'équipe de travail- Contrôles d'accès efficaces - Maintenir la description des produits de travail- Récupération des versions d'archivage des

produits de travail- Capacité de rapporter le statut des produits de

travail- Des changements aux produits de travail sont

suivis par des Requêtes de Changement

Le statut applicable est: mis à jour.

Gestion de Projet

7. Spécifications des exigences

Identification des exigences du logiciel. Il peut avoir les caractéristiques suivantes :

- Introduction - description générale du logiciel et de son utilisation dans la portée des affaires du client ;

- Description des exigences:o Fonctionnalité - les besoins établis pour

être satisfaits par le logiciel quand ils sont utilisés dans des conditions spécifiques. La

Implémentation logicielle



Nom Description Sourcefonctionnalité doit être proportionnée, précise et sûre.

o Interface utilisateur - définition des caractéristiques de l'interface utilisateur qui permettent de comprendre et de maitriser facilement le logiciel afin que l'utilisateur soit en mesure de s'acquitter ses tâches avec efficacité.

o Interfaces externes - définition des interfaces avec d'autres logiciels ou matériels;

Chaque exigence est identifiée, unique et vérifiable ou peut être évaluée.Les statuts applicables sont: vérifiées et validées

8. Logiciel Produit logiciel (code source et code exécutable) pour le client, constitué par une collection de Composants logiciels intégrés.

Le statut applicable est : testé


9. Composants logiciels

Un ensemble d'unités de code liéesLe statut applicable est : testé.


10. Configuration du logiciel

Un ensemble unique et cohérent de produits logiciel comprenant :

- Spécification des exigences - Logiciel

Les statuts applicables sont : livré et accepté.


11. Identification des composants logiciels

Informations textuelles et graphiques de la structure logicielle. Cette structure peut inclure les parties suivantes :Décrit la structure Logicielle complète :- Identifie les composants logiciels exigés- Identifie la relation entre des composants logiciels


12. Énoncé de travaux

Description du travail à faire par rapport au développement logiciel. Il peut inclure:

- Description du produit o Buto Exigences générales du client

- Description de la portée - ce qui est inclus et ce qui n'est pas

- Liste des produits livrables à fournir au client

Le statut applicable est : vérifié

Client

13. Cas de tests et procédures de tests

Les éléments nécessaires pour tester le code. Les cas de tests peuvent inclure :

- Identification du scénario de test- Éléments du test




Nom Description Source- Spécifications d’entrée- Spécifications de sortie- Besoins environnementaux- Exigences procédurales spéciales- Dépendances d'interface

Les procédures de test peuvent inclure :- Identification de : nom du test, la description de test et la

date d'achèvement.- Identification des événements de mise en oeuvre

potentielle.- Identification de la personne qui a achevé la procédure de

test- Identification des pré-requis- Identification des étapes de procédure incluant le

nombre d'étapes, l'action exigée par le testeur et les résultats attendus.

14. Rapport de Tests

Il documente l'exécution des tests et peut inclure:- Résumé de chaque défaut- Identification de testeur qui a trouvé chaque

défaut- Identification de la (les) fonction (s) affectée(s)

par chaque défaut- Identification de la date de détection de chaque

défaut- Identification de la date à laquelle chaque défaut

a été résolu- Identification de la personne qui a résolu chaque

défaut


4.4. Description des artefacts

Artefacts Définition

Lettre d’acceptation Document qui établit l’acceptation du client des livrables établis dans le projet.

Description du Projet Description de haut niveau du projet, il inclut: La portée , les objectifs et les livrables majeurs.

Plan de Projet Une déclaration de comment et quand les objectifs d'un projet doivent être réalisés, en montrant les produits majeurs, les jalons, les activités et les ressources exigées pour le projet.

Document d’exigences logicielles

Le document dans lequel on centralise toutes les exigences identifiées.



Logiciel

Un ensemble cohérent des produits logiciels qui incluent : Spécification d'Exigences Composants Logiciels Logiciel (unité, produit, article) Test et Rapports des Incidents Manuel d’Opération Manuel de l'utilisateur

Composant Logiciel Un ensemble d’unités de code. Les états applicables sont: unité testée, corrigée et de base.

Configuration du logiciel Ensemble de produits logiciels lequel doit inclure :- Spécification d'exigences- Architecture du logiciel- Composants logiciels- Logiciel - Rapport de tests - Guide d’opération du produit - Guide de l’utilisateur- Documentation de la maintenance

Rapport de Tests Noter les résultats de l’exécution de tests dans un environnement spécifique.

Diagrammes UML Ces diagrammes faciliteront la représentation graphique de la conception du logiciel en utilisant Unified Modelling Language. UML peut fournir une façon facile et standard d'exprimer les données, des processus ou l'architecture.



5. Gabarits et outils

Les modèles des gabarits fournis ici sont des exemples, ils devraient être personnalisés pour votre projet.

5.1. Modèle pour l’initiation de l’implémentation logicielle

Gabarit de la table de 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 de message 6. La date, l’endroit et l’heure 7. D'autres informations (ex. repas inclus)

Gabarit d’une liste de contrôle d’assistance aux réunionsNo. Nom du membre de

l’équipe de travailRôle Assistance

Oui Non Signature

Commentaires

5.2. Modèle pour l’analyse des exigences logicielles

Table d’exigences logicielles Pour être utilisé dans une feuille d'Excel structurée, par exemple :

ID Exigence Description PrioritéHaute Moyenne Basse

Chacune des exigences peut être définie en format de table. La structure de la table pourrait être: Projet <Identification dans le Projet >

Date <La date de la dernière modification>Exigence <Identification, Texte de l’exigence>Description < Description détaillé de l’exigence>Justification <Pour quoi est-elle importante>



Priorité <Niveau de priorité de l’exigence>Dépendance <Rapport avec d’autres exigences>Comment <Remarques additionnelles>

5.3 Modèle pour l’identification des composants logiciels

Sites d’internet qui donnent des modèles de diagrammes standards.

Modèle SourceUML http://www.uml.org

BPMN http://www.bpmn.org

Pour être utilisé dans une feuille d'Excel structurée, par exemple : Gabarit de la table de matières de l’identification des composants

Identification du projet (Nom et date) 1. Composant 1.

1.1. Identification1.2. Description1.3. Sous-composants 1.4. Exigences

2. Composant 2.2.1. Identification2.2. Description2.3. Sous-composant 2.4. Exigence

3. …

5.4 Modèle pour la construction logicielle

Sites d’internet qui donnent des modèles standards pour le codage.

Modèle SourceGabarit du standard de codage

http://www.construx.com

Gabarit du code source C / C++


Gabarit du code source Java



http://www.construx.com/



http://www.bpmn.org/

http://www.uml.org/


Standard du codage Java

http://www.ontko.com/java/java_coding_standards.html

Gabarit du code source Visual Basic


Gabarit du code source XML


Sites d’internet qui donnent des modèles de spécifications d’interface d’utilisateur

Modèle SourceUser Interface Spécification

http://www.hcirn.com/tutor/docs/uitempl.php

5.5 Modèle de spécifications des tests

Pour être utilisé dans une feuille d'Excel structurée, par exemple : Type d'application Mode d'opération Sujet Groupe visé Types de média à être utilisés

Machine clienteCaractéristiques du système

logiciel (software) VersionSystème d'exploitation Navigateur Exigences du navigateur Protocole de communication

Caractéristiques du système

hardware CapacitéProcesseur Disque fixe Mémoire RAM Résolution d'écran Multimédia Applicable seulement en Multimédia Vitesse CD ROM


http://www.hcirn.com/tutor/docs/uitempl.php



http://www.ontko.com/java/java_coding_standards.html


Carte Vidéo Carte de Son Accélérateur 3D

Caractéristiques du système hardware additionnées par le

client CapacitéImprimante Numérisateur

Machine clienteCaractéristiques du système

logiciel du serveur Web (software) VersionSystème d'exploitation Serveur Web Langage de programmation Exigences du langage

Caractéristiques du système logiciel du serveur des données

(software) VersionSystème d'exploitation Base de données

Caractéristiques du système

hardware du serveur WebCapacit

éProcesseur Disque fixe Mémoire RAM

Gabarit de la table de matières du Rapport de Tests 1. Objective du test ………………….2. Résultats des tests ………………..

a. Exigence vérifiée ou échoué ………………..3. Commentaires et recommandations ………………..

a. Échecs critiques ………………..b. Échecs sérieux ………………..c. Échecs mineurs ………………..

4. Intégration de Composants a. Registre des testsb. Documentation des Testsc. Fiches techniques des testsd. Analyse et conclusions ………………..

5. Fichier des données initiales ………………..6. Conclusions ………….…….



5.6 Modèle pour la livraison du produit final

Formulaire d’instructions de livraison

Formulaire d’instructions de livraison

Identification du projet ou nom du client ______________________

Préparé par (Nom Initial): __________________________

Date (aaaa-mm-jj): _________________

Identification des livrables (par exemple: hardware, software, documentation etc.):

Exigences de livraison:

Séquence de tâches à être exécutées:

Versions applicables:

Critères d’acceptation :

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

(aaaa-mm-jj)

1

2

3

Composants logiciels Information de version

Procédures de récupération et sauvegarde:

Approuvé by:

______________________ _______________________________ Chef de projet Client ou personne représentante de la compagnie



Date (aaaa-mm-jj):_________________

Formulaire du registre d’acceptation

Formulaire du registre 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

5Signatures d’Acceptation:

Composants logiciels

Information de versions

Date d’acceptation

du client

Signature du client

Signatures:

__________________ ________________________________ Chef de project Client ou personne représentante de la compagnie



Date (aaaa-mm-jj):_________________

Outils

Cette section donne des informations sur les sources des outils qui pourraient aider à supporter certaines des activités du processus de l’implémentation logicielle.

Intégration logicielle et tests Pour assurer la gestion des défauts du produit, il est nécessaire d’implémenter un système, de préférence un système Web, qui permet de faire un suivi des problèmes et défauts identifiés d'un produit et les demandes associées à eux.

Comme des caractéristiques clés, ce système doit permettre : Identification automatique d’incidents Attachement de documents Produire des notifications automatiques via courrier électronique Maîtriser les changements Produire des requêtes simples et interactives Classification d’incidents par : Type, Cause, Sévérité.

Il existe plusieurs outils de tests “open source” sur Internet, voici un site web qui offre quelques-uns :

http://www.opensourcetesting.org/functional.php

Livraison du produit final Outils de Contrôle de Version comme CVS (Concurrent Versions System) ou SVN

(version management). Dépôts disponibles en Source libre : par exemple Google Doc. Outils de gestion de Configuration.


http://www.opensourcetesting.org/functional.php


6. Exemple du cycle de vie de l’implémentation logicielle

Avertissement: Cette section fournit quelques représentations graphiques des exemples du cycle de vie de développement des logiciels. Ces exemples sont fournis pour aider le lecteur à l’implémentation de son propre cycle de vie de développement logiciel en l’adaptant au contexte de son projet informatique et ses contraintes.

Exemple du cycle de vie de l’implémentation logicielle

Celui-ci est un exemple qui utilise le pochoir SPEM de Microsoft Visio (http:// www.pa.icar.cnr.it/cossentino/FIPAmeth/docs/SPEM.vss) pour produire ce diagramme.

Figure 3 Exemple du cycle de vie de l’implémentation logicielle



7. Listes de vérification

7.1 Liste de vérification pour l’analyse d’exigences logicielles

Cette liste pour les exigences logicielles est basée sur [Constr07]

RS 1 Testable Toutes les exigences sont vérifiables (objectivement)RS 2 Complet Est-ce que toutes les exigences sont complètes? RS 3 Correct Les exigences doivent être correctes (par exemple, exprimer

exactement les exigences du client)RS 4 Unique Les exigences doivent être établies seulement une fois.RS 5 Simple Les exigences doivent être détaillées de façon élémentaireRS 6 Scope Toutes les exigences font parties de la portéeRS 7 Haut Niveau Les exigences doivent être établies en termes des besoins

finaux, sans concevoir les moyens (solutions) RS 8 Sans équivoque Les exigences doivent être formulées en termes qui ne

peuvent être interprétées que dans un seul sens.

7.2 Liste de vérification pour l’identification de composants logiciels

RS 1 Testable Tous les composants sont vérifiables (objectivement)RS 2 Complet Est-ce que tous les composants sont complets? RS 3 Correct Les composants doivent être corrects (par exemple,

exprimer exactement les exigences du client)RS 4 Unique Les composants doivent être établis seulement une fois.RS 5 Simple Les composants doivent être détaillés de façon élémentaireRS 6 Lié (linked) Les composants sont liés aux sous-composants RS 7 Associé Les composants doivent être associés à d’autres

composants.RS 8 Sans équivoque Doit être énoncés dans des termes qui ne peuvent être

interprétés que dans un sens seulement.

7.3 Liste de vérification pour la construction du logiciel



Liste de vérification de révision du codeNote: Cette liste de vérification peut être adaptée au langage de programmation que vous utilisez.

Matière DescriptionComplète - Vérifier que toutes les fonctions dans la conception ont été

codées et que toutes les fonctions nécessaires et des procédures ont été implémentées.

Logique - Vérifier que le flux de programme, les procédures et la logique de fonctionnement sont cohérents la conception détaillée.

Boucles - Faire une simulation manuelle de toutes les boucles et les procédures récursives qui n'ont pas été simulées dans la revue détaillée du dessin ou l'inspection.

- Assurer que chaque boucle est correctement amorcée et terminée.

- Vérifier que chaque boucle exécute le nombre de fois correct.Appels - Vérifier chaque fonction et l'appel de procédure pour assurer qu'il

corresponde exactement à la définition des formats et des types.Déclarations Vérifiez que chaque variable et paramètre :

- Ont exactement une déclaration.- Sont seulement utilisé dans sa portée déclarée.- Sont orthographié correctement partout où ils sont utilisés.

Initialisation Vérifier que chaque variable est initialisée.Limites - Vérifier toutes les variables, les tableaux et les index pour assurer

que leur utilisation n'excède pas les limites déclarées.Début-Fin - Vérifier toutes les paires de début-fin ou leurs équivalents, y

compris les cas où ifs emboîtés pourraient être mal interprétés.Booléen - Vérifier les conditions booléennes.Format - Vérifier le format d'instruction, l'orthographe et la ponctuation de

chaque ligne de programme.Indicateurs - Vérifier que tous les indicateurs sont correctement utilisés.Input-output - Vérifier tous les formats input-output.Orthographe - Vérifier que chaque variable, paramètre et index est

correctement orthographiéCommentaires

- Assurer que les commentaires sont précis et selon la norme.

7.4 Liste de vérification pour l’intégration logicielle et les tests

Cette information provient du site de la société Construx:http://www.construx.com/Page.aspx?nid=208

7.5 Liste de vérification pour la livraison du produit final.


http://www.construx.com/Page.aspx?nid=208


Critères d’acceptation caractéristiques d’une TPO Les médias sont étiquetés correctement, montrant un nom de produit, la date de sortie et

le numéro de version correct. L'étiquetage du Produit, y compris l'emplacement de livraison et le personnel

d'acceptation de produit (si applicable), a été établi auparavant. Le produit logiciel du dépôt d’information du projet est conforme aux instructions de

livraison. Le logiciel à être livré est la dernière version du logiciel qui se trouve au dépôt

d’information du projet. Le document de description de version a été inspecté. Le document de description de version est inclus avec les médias de soutien. Tous les tests ont été exécutés avec succès. Toutes les erreurs ont été corrigées. Toute la documentation a été mise à jour. Le manuel de l'utilisateur a été inspecté. Le Manuel de l'Utilisateur est inclus avec les médias de soutien. Tous les sujets dans les instructions de Livraison approuvées ont été couverts. Le Formulaire de registre d'acceptation a été mise à jour et prêt pour la signature. Les informations nécessaires pour la livraison (par exemple. L'adresse, le nom du client)

ont été vérifiées avant la livraison. Votre client a été informé quand une livraison sera exécutée. Le client vous a informé que ses préparatifs de la livraison ont été complétés.

Critères d’acceptation caractéristiques du client Vérifier que les composants logiciels livrés contemplent les Instructions de Livraison

approuvées. Vérifier que les composants logiciels livrés accomplissent les exigences initiales. Vérifier que la documentation attendue, les rapports de test, l’information de dessin et

conception et le matériel de formation ont été livrés. Vérifier que les composants logiciels livrés opèrent dans son environnement destiné (tant

technique qu'organisationnel) et sont acceptables pour les utilisateurs. Vérifier que le formulaire d’acceptation a été révisé et signé.



8. Références

Nom Référence[MCC 04] Steve McConnell, Code Complete, Second Edition, Redmond, Wa.:

Microsoft Press, 2004.[IEEE 1012-2004] IEEE 1012-2004 IEEE Standard for Software Verification and

Validation[ISO/IEC 12207] ISO/IEC 12207:2008 Systems and software engineering – Software

life cycle processes.[ISO/IEC 15289] ISO/IEC 15289:2006 Systems and software engineering - Content

of systems and software life cycle process information products (Documentation)

[ISO/IEC 29110-5-1-1] ISO/IEC TR 29110-5-1-1:2010, Software Engineering—Lifecycle Profiles for Very Small Entities (VSEs) – Part 5-1-1: Management and Engineering Guide –Generic Profile Group: Entry ProfileCe document sera disponible gratuitement sur le suite suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

[ISO/IEC 24765] ISO/IEC 24765:2011 Systems and software engineering vocabulary.Une version électronique de ce document est disponible à: http://pascal.computer.org/sev_display/index.action

[IEEE 1233-1998] IEEE 1233-1998 Guide for Developing System Requirements Specifications.


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

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

http://shop.ieee.org/ieeestore/

http://shop.ieee.org/ieeestore/


9. Formulaire d’évaluation

Trousse de déploiement - Implémentation Logicielle – Profil d’entrée V 0.2Vos commentaires nous permettront d'améliorer cette trousse de déploiement; vos suggestions sont 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 : _________________________________________

Remplissez le formulaire et envoyez-le au courriel: [email protected]


mailto:[email protected]