REFERENTIEL NORMATIF du CNES

Transcription

1 REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure Annexe Technique à la MP RNC-CNES-Q APPROBATION Président du CDN ; date et nom :

2

3 Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS CLES : Analyse Conception Objet UML HOOD RESUME : Ce document présente des règles et recommandations pour la démarche d analyse du logiciel orientée objet. SITUATION DU DOCUMENT : Ce document est une annexe technique au document RNC-CNES-Q "Démarche de Développement Objet pour les logiciels" qui fait partie de la collection des Méthodes et Procédures associées au Référentiel Normatif du CNES (ECSS et MPM). Ce document est affilié à l'assurance Produit des Logiciels. NOMBRE DE PAGES : 24 Progiciels utilisés / version : Word 97 SERVICE GESTIONNAIRE : Toulouse (DTS/AQ) LANGUE : Française Délégation à l'assurance de la Qualité du Centre Spatial de AUTEUR(S) : DATE : 07/10/00 Jean-Charles POUPLARD / Jean-Alain VERON / Isabelle ZENONE RELECTURE / CONTROLE : Pour ACCORD : Le Président du Comité Technique de Normalisation : CNES 2000 Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisation collective (article 41-2 de la loi n du 11 Mars 1957).

4 Page i.2 PAGES DES MODIFICATIONS VERSION DATE PAGES MODIFIEES OBSERVATIONS 1 07/10/00 Document initial Document élaboré avec le support de MMS (C. Pinaud, M.A. Gandrieau) et Virtualité Réelle (T. Leydier)

5 Page i.3 SOMMAIRE 1. INTRODUCTION OBJET PHASE DE SPÉCIFICATION DU BESOIN Documents de sortie de la phase Spécification Technique du Besoin du Logiciel (STBL) PHASE DE SPÉCIFICATION DU LOGICIEL Documents de sortie de la phase Spécification Technique du Logiciel (STL) Dossier de Justification plan standard de dossier de spécification du logiciel compatible avec UML PHASE DE CONCEPTION PRÉLIMINAIRE Documents de sortie de la phase Dossier de Conception Préliminaire (DCP) Dossier de Justification plan standard de dossier de Conception préliminaire compatible avec UML PHASE DE CONCEPTION DÉTAILLÉE Documents de sortie de la phase Dossier de Conception Détaillée (DCD) Dossier de Justification plan standard de dossier de Conception Détaillée compatible avec UML PHASE DE RÉALISATION Documents de sortie de la phase Dossier de Justification PHASE DE VALIDATION Documents de sortie de la phase Spécification Technique du Logiciel (STL) Dossier de Justification... 17

6

7 Page 1 1. INTRODUCTION Ce document «ANNEXE D : Documentation» est une annexe technique au document RNC-CNES- Q «Démarche de Développement Objet pour les logiciels». 2. OBJET L objectif de cette annexe est de détailler les règles et recommandations applicables pour ce qui concerne la documentation produite au cours du développement, en terme de contenu et de structuration. Il fait partie du référentiel documentaire DDO (Démarche de développement du logiciel orienté objet). Des règles générales sur les principes de documentation sont fournies dans l annexe C dans la section consacrées au processus de documentation. Comme pour l'ensemble du document, ces règles sont issues d'une adaptation et d'une spécialisation des référentiels existants dues à l'impact de l'introduction de l'objet. Elles sont basées sur les standards de documentation décrits dans la norme ECSS-E-40 dont elles appliquent la philosophie générale même si elles s'en différencient sur certains points de détail. Cette annexe contient donc, pour chaque phase du cycle en V standard décrite dans le document chapeau DDO : - le rappel de la liste des dossiers de documentation produits ou mis à jour au cours de la phase, - pour chaque dossier type, la définition des éléments qui doivent être fournis avec leurs caractéristiques et des indications sur leur organisation, indépendamment de la structure réelle avec laquelle ils seront présentés. Un dossier peut être en effet constitué d'un seul ou de plusieurs documents, selon les contraintes du projet (en particulier les exigences qualité du client et la taille du projet). La description se concentre sur les parties issues des activités du processus de développement qui sont directement concernées par l'introduction de la démarche objet. Les autres parties sont rappelées mais non détaillées. Les chapitres introductifs usuels pour tout document (par exemple objet, documents de référence et applicables, organisation, etc.) ne sont pas mentionnés. - un exemple de plan standard plus détaillé pour UML.

8 Page 2 3. PHASE DE SPÉCIFICATION DU BESOIN 3.1 DOCUMENTS DE SORTIE DE LA PHASE Le(s) document(s) constituant la Spécification Technique du Besoin du Logiciel (STBL). 3.2 SPECIFICATION TECHNIQUE DU BESOIN DU LOGICIEL (STBL) La STBL produite pendant cette phase doit contenir les éléments suivants : Eléments constitutifs Contenu Présentation générale introduction aux objectifs généraux et contraintes majeures du système présentation des objectifs de la phase Résultats de l'analyse des besoins (dans le cas où l on mène une véritable analyse objet en phase de spécification du besoin) modèle objet métier - diagramme de contexte - diagrammes indépendants dictionnaires du métier Spécification des exigences client liste des exigences textuelles définissant: - les exigences fonctionnelles - les exigences opérationnelles - les exigences de performance - les exigences de sécurité et de fiabilité - les exigences de développement : qualité, standards, méthodes et outils, qualification contraintes de conception et de réalisation, contraintes et marges des budgets techniques Les exigences sont fournies : - avec leurs propriétés : référence, type, attributs pour la qualification - sous forme soit textuelle, soit tabulaire - classées par type et en cohérence avec le découpage de l'analyse (cas d'utilisation et décomposition logique) identification des parties critiques et analyses des risques techniques Spécification des interfaces externes liste des exigences textuelles définissant: - les interfaces logiciel / matériel - les interfaces externes de niveau système définition des données d'interface définition des exigences liées à l'intégration de niveau système Par défaut, il est recommandé d'organiser les documents de la STBL de la manière suivante :

9 Page 3 - un document contenant les résultats de l'analyse des besoins et la spécification des exigences client. Cela permet en effet de regrouper la partie descriptive (le modèle d'analyse des besoins) et la partie exigences de référence, et ainsi de pouvoir gérer des liens de traçabilité interne entre les deux. - un document pour la description des interfaces externes. Remarque : le niveau de détail de la description des exigences client dépend des projets. Plus les exigences seront précises et complètes à l'issue de cette phase, moins il y aura de travail de consolidation dans la phase suivante.

10 Page 4 4. PHASE DE SPÉCIFICATION DU LOGICIEL 4.1 DOCUMENTS DE SORTIE DE LA PHASE Le plan de développement logiciel, Le Plan Général de Essais, Le(s) document(s) constituant la Spécification Technique du Logiciel (STL), Le(s) document(s) constituant le Dossier de Justification. 4.2 SPECIFICATION TECHNIQUE DU LOGICIEL (STL) La STL produite pendant cette phase doit contenir les éléments suivants : Eléments constitutifs Contenu Présentation générale introduction aux objectifs généraux et contraintes majeures du système présentation des objectifs de la phase Résultats de l'analyse objet diagrammes commentés, dans l'ordre : - diagramme de contexte - acteurs et cas d'utilisations internes - décomposition logique en catégories - modèle objet métier éventuel - modèle de l application, hiérarchisé suivant la décomposition logique - scénarios structurés selon les cas d'utilisation, diagrammes de collaboration ou de séquence, diagrammes dynamiques selon les besoins dictionnaires Spécification des exigences (dans le cas où ces liste des exigences textuelles définissant : exigences n ont pas été décrites dans le STBL, - les exigences fonctionnelles ou avec un point de vue «fournisseur») - les exigences opérationnelles - les exigences de performance - les exigences de sécurité et de fiabilité - les exigences de développement: qualité, standards, méthodes et outils, qualification contraintes de conception et de réalisation, contraintes et marges des budgets techniques Les exigences sont fournies : - avec leurs propriétés: référence, type, attributs pour la qualification - sous forme soit textuelle, soit tabulaire - classées par type et en cohérence avec le découpage de l'analyse objet (cas d'utilisation et décomposition logique) identification des parties critiques et analyses des risques techniques

11 Page 5 Spécification des interfaces (ICD) liste des exigences textuelles définissant les interfaces externes du logiciel définition des données d'interface selon un format prédéfini (sous forme tabulaire par exemple) conception préliminaire des interfaces externes haut niveau Version préliminaire du manuel d opération non détaillé (non spécifique à l objet) Version préliminaire du manuel de maintenance non détaillé (non spécifique à l objet) Par défaut, il est recommandé d'organiser les documents de la STL de la manière suivante : - un document contenant les résultats de l'analyse et la spécification des exigences. Cela permet en effet de regrouper la partie descriptive (le modèle logique d'analyse) et la partie exigences de référence, et ainsi de pouvoir gérer des liens de traçabilité interne entre les deux. En fonction de la taille et de l'environnement du projet, plusieurs localisations sont possibles pour le modèle logique d'analyse : - dans le corps du document avant la partie exigences : à privilégier par défaut, - à la fin du document en annexe: à privilégier pour un gros projet ou /et si les clients ne sont pas familiarisés avec la méthode de modélisation mais sont intéressés par le fait de les consulter en complément des exigences, - dans un document annexe séparé: à privilégier pour un très gros projet ou /et si les clients ne souhaitent pas avoir accès aux modèles mais seulement aux exigences. - un document pour la spécification des interfaces, - un document par manuel (opération et maintenance). Remarque : le contenu de la STL est de même nature que celui de la STBL pour ce qui concerne la spécification des exigences, même si le niveau de détail est supérieur. Il s agit d un point de vue «fournisseur» en réponse aux besoins exprimés initialement par les «clients» dans la STBL.

12 Page DOSSIER DE JUSTIFICATION Le Dossier de Justification doit contenir les éléments suivants : Eléments constitutifs Contenu Justification des choix liés à l'analyse choix de modélisation non évidents : pour l'ensemble du modèle, un sous-ensemble (par exemple une catégorie), un diagramme particulier, ou une partie de diagramme choix de réutilisation Matrices de traçabilité exigences spécifiées de la STL / besoins initiaux Version préliminaire du plan des essais de validation non détaillé (non spécifique de l objet, à part l exploitation des scénarios pour produire une partie des cas de tests) Ossature du dossier de qualification non détaillé (non spécifique à l objet) De manière générale, dans cette présentation des produits documentaires tous les éléments qui doivent être fournis en terme de justification des choix ont été identifiés comme faisant partie du dossier de justification, conformément aux principes de la norme ECSS-E-40. Néanmoins, en terme d'organisation des documents réels, il peut être préférable de répartir les différents éléments avec les autres composants de la documentation pour une phase donnée. Selon ce principe : - la justification des choix d'analyse peut se trouver sous la forme de rubriques "justification des choix" associées aux sections concernées dans la présentation du modèle d'analyse de la STL, - les matrices de traçabilité peuvent être fournies en annexe de la STL.

13 Page PLAN STANDARD DE DOSSIER DE SPECIFICATION DU LOGICIEL COMPATIBLE AVEC UML 1 1. INTRODUCTION 1.1. Présentation du document, de son organisation 1.2. Terminologie, Définitions, Acronymes et Abréviations 1.3. Documents applicables 1.4. Documents de référence 2. DESCRIPTION GENERALE 2.1.Définition du projet description du contexte projet (diagramme de contexte projet) identification des acteurs au niveau du système complet identification des frontières du projet 2.2 Configuration Projet définition de la filière éventuelle liens avec le projet père, les projets fils et frères identifiés étude de la diversité et résultats propres au projet description du contexte multi-projet 2.3. Contraintes générales normes à respecter considérations environnementales 2.4. Considération méthodologiques Description de la méthode de spécification et d analyse utilisée Modalités d utilisation d UML pour la spécification : conventions, limites, etc. Autres spécificités : sentinelles de traçabilité, identification formelle des items de spécification 2.5. Points essentiels Identification de points fondamentaux pour le projet : fondamentaux car stratégiques pour le client ou l utilisateur fondamentaux car associés à des exigences très fortes en terme de performances fondamentaux car novateurs sur le plan de l utilisation des technologies fondamentaux car ils sont supposés critiques du point de vue de la réalisation L identification de ces points doit organiser le développement (maquetage ou prototypage par exemple) 2.6. Liens avec d autres systèmes Définition des interfaces avec les autres systèmes matériels et logiciels identifiés Diagramme de déploiement (très haut niveau) Description des composants réutilisé (très haut niveau) 2.7. Sous-systèmes description et identification des sous-systèmes 2.8. Dictionnaire de données 1 Le respect de ce plan n est pas obligatoire : il est fourni à titre illustratif afin de montrer comment intégrer l utilisation de la modélisation UML dans la documentation.

14 Page 8 3. CAS D UTILISATION 3.X SOUS SYSTEME X 3.X.1 CAS D UTILISATION POUR LE SOUS SYSTEME X Détail des acteurs pour le sous-système X Hiérarchie des cas d utilisation pour le sous-système X Diagrammes des cas, ou diagramme de collaboration à haut niveau Identification des paquetages de cas 3.X.1.Y Paquetage de cas Y du sous système X Description générale du paquetage 3.X.1.Y.C Cas C du Paquetage Y du sous système X Diagramme de cas Description textuelle du cas Diagrammes complémentaires : - diagrammes de séquences de haut niveau (digramme de suivi des événements) pour illustrer des scénarios particuliers - diagrammes d objets participants 3.X.2 DESCRIPTION DES OBJETS POUR LE SOUS SYSTEME X Description de haut niveau des objets et des classes identifiés (sous forme de table) Diagrammes de classes ou d objet de haut niveau (vue logique UML)

15 Page 9 3. AUTRES EXIGENCES Décrites de façon informelle 3.1. Exigences de Performance 3.2. Exigences d Interface 3.3. Exigences qualité Documentation exigée Sûreté de Fonctionnement : Fiabilité, Disponibilité, Sécurité Maintenabilité : Evolutivité, Portabilité Réutilisabilité 3.4. Exigences en termes de vérification Vérifications unitaires Critères de Recette 3.5. Autres exigences opérationnelles 4. TRAÇABILITE EXIGENCES DE BESOIN VERS EXIGENCES LOGICIELLES

16 Page PHASE DE CONCEPTION PRÉLIMINAIRE 5.1 DOCUMENTS DE SORTIE DE LA PHASE Le(s) document(s) constituant le Dossier de Conception Préliminaire (DCP) Le(s) document(s) constituant la mise à jour du Dossier de Justification 5.2 DOSSIER DE CONCEPTION PRELIMINAIRE (DCP) Le Dossier de Conception Préliminaire (DCP) doit contenir les éléments suivants: Eléments constitutifs Contenu Présentation générale introduction aux objectifs généraux et contraintes majeures du système présentation des objectifs de la phase Résultats de la conception de l architecture logique Diagrammes commentés définissant l organisation statique : - diagrammes de décomposition statique en «catégories» - diagrammes de classes définissant l interface de chaque catégorie (classes d interface) Diagrammes commentés définissant le comportement dynamique par catégorie - diagrammes de collaboration ou de séquence entre les classes d interface - diagrammes à états des classes de contrôle Diagrammes commentés définissant l organisation dynamique - diagrammes de décomposition en tâches Définition des interfaces : graphique et textuelle : - spécification des opérations publiques des classes d interface - diagrammes globaux de flots de données - diagrammes globaux de flots d événements Résultats de la conception de l architecture physique Dictionnaires diagrammes commentés : - diagrammes de composants et de déploiement avec UML, ou équivalent avec les autres méthodes Par défaut, il est recommandé d'organiser les différentes parties du DCP de la manière suivante : - un document principal contenant les différentes composantes de l architecture logique et physique, - les dictionnaires en annexe. Deux alternatives sont possibles pour l organisation de la description de l architecture logique :

17 Page 11 - une partie statique, pour l ensemble des catégories, puis une partie dynamique, pour l ensemble des catégories - pour chaque catégorie, la partie statique et la partie dynamique. 5.3 DOSSIER DE JUSTIFICATION Le Dossier de Justification mis à jour doit contenir les éléments supplémentaires suivants: Eléments constitutifs Contenu Justification des choix d'architecture choix de modélisation non évidents concernant la définition de l architecture logique ou physique : pour l'ensemble du modèle, un sous-ensemble (par exemple une catégorie), un diagramme particulier, ou une partie de diagramme justification des restrictions ou exceptions des règles qualité d utilisation de l objet trace des solutions écartées non évidentes choix de réutilisation Matrices de traçabilité Composants et éléments de l'architecture / exigences de la STL Bilans techniques et résultats d'analyse non détaillé (non spécifique à l objet) Version préliminaire du plan de tests d'intégration non détaillé (non spécifique à l objet, à part l exploitation des scénarios pour produire une partie des cas de tests)

18 Page PLAN STANDARD DE DOSSIER DE CONCEPTION PRELIMINAIRE COMPATIBLE AVEC UML 2 1. INTRODUCTION 1.1. Présentation du document, de son organisation 1.2. Terminologie, Définitions, Acronymes et Abréviations 1.3. Documents applicables 1.4. Documents de référence 2. DESCRIPTION GENERALE 2.1.Définition du projet description du contexte projet (diagramme de contexte projet) identification des acteurs au niveau du système complet identification des frontières du projet 2.2 Configuration Projet définition de la filière éventuelle liens avec le projet père, les projets fils et frères identifiés étude de la diversité et résultats propres au projet description du contexte multi-projet 2.3. Contraintes générales normes à respecter considérations environnementales 2.4. Considération méthodologiques Description de la méthode de conception utilisée Modalités d utilisation d UML pour la conception : conventions, limites, etc Points essentiels Identification de points fondamentaux pour le projet : fondamentaux car stratégiques pour le client ou l utilisateur fondamentaux car associées à des exigences très fortes en terme de performances fondamentaux car novateurs sur le plan de l utilisation des technologies fondamentaux car ils sont supposés critiques du point de vue de la réalisation L identification de ces points doit organiser le développement (maquetage ou prototypage par exemple) 2.6. Liens avec d autres systèmes Définition des interfaces avec les autres systèmes matériels et logiciels identifiés 2.7. Principaux choix d implémentation Architecture matérielle / logicielle Diagramme de déploiement Décomposition en tâches et fils (threads) de haut niveau Réutilisation Description des composants réutilisé et justification Référence des schémas employés Allocation des ressources 2 Le respect de ce plan n est pas obligatoire : il est fourni à titre illustratif afin de montrer comment intégrer l utilisation de la modélisation UML dans la documentation.

19 Page 13 Ressources Matérielles (complément du déploiement) : Mémoire, Processeurs, Disques Ressources Logicielles : interruptions, timers, registres 2.7. Sous-systèmes description et identification des sous-systèmes 2.8. Dictionnaire de données 3. ARCHITECTURE 3.X SOUS SYSTEME X 3.X.1 ARCHITECTURE POUR LE SOUS SYSTEME X Vue générale du sous-système Diagramme de classe du sous-systèmes 3.X.1.Y Paquetage Y du sous système X 3.X.1.Y.1 Diagrammes de classes Diagrammes de classes 3.X.1.Y.2 Définition des classes Description Textuelle des classes 3.X.1.Y.3 Définition des Opérations Description Textuelle des opérations 3.X.1.Y.4 Justification des choix Autres descriptions textuelles 3.X.1.Y.5 Autres Diagrammes Diagrammes Etats Transitions, Diagrammes d activité 3.X.2 DECOMPOSITION EN TACHES POUR LE SOUS SYSTEME X 3.X.1. Introduction Vue générale 3.X.2. Détail Détail de chaque tâche ou fils 3.X.3. Mapping Liens entre tâches, opérations et classes 4. TRAÇABILITE EXIGENCES LOGICIELLES VERS CONCEPTION

20 Page PHASE DE CONCEPTION DÉTAILLÉE 6.1 DOCUMENTS DE SORTIE DE LA PHASE Le(s) documents constituant le Dossier de Conception Détaillée (DCD). Le(s) document(s) constituant la mise à jour du Dossier de Justification. 6.2 DOSSIER DE CONCEPTION DETAILLEE (DCD) Le Dossier de Conception Détaillée (DCD) doit contenir les éléments suivants : Eléments constitutifs Contenu Présentation générale introduction aux objectifs généraux et contraintes majeures du système présentation des objectifs de la phase Résultats de la conception objet Diagrammes commentés, par raffinement des diagrammes de conception préliminaire 6.3 DOSSIER DE JUSTIFICATION - diagrammes de classes complets - autres diagrammes dynamiques, fonctionnels ou autres à titre d informations complémentaires Dictionnaires Le Dossier de Justification mis à jour doit contenir les éléments supplémentaires suivants : Eléments constitutifs Contenu Justification des choix de conception choix de modélisation non évidents concernant les solutions d implémentation : pour un diagramme particulier, ou une partie de diagramme justification des restrictions ou exceptions des règles qualité d utilisation de l objet trace des solutions écartées non évidentes choix de réutilisation Matrices de traçabilité Eléments de conception détaillée / composants de l'architecture Versions mises à jour des plans d'essais de non détaillé validation Plans de tests unitaires et d'intégration non détaillé (non spécifique de l objet à part l exploitation des scénarios)

21 Page PLAN STANDARD DE DOSSIER DE CONCEPTION DETAILLEE COMPATIBLE AVEC UML 3 Le dossier de conception détaillée reprend l architecture du dossier de conception préliminaire. 1. INTRODUCTION Idem dossier de conception préliminaire 2. DESCRIPTION GENERALE 2.1.Définition du projet Idem dossier de conception préliminaire 2.2 Configuration Projet Idem dossier de conception préliminaire 2.3. Contraintes générales Idem dossier de conception préliminaire 2.4. Considération méthodologiques Idem dossier de conception préliminaire 2.5. Points essentiels Idem dossier de conception préliminaire 2.6. Liens avec d autres systèmes Idem dossier de conception préliminaire 2.7. Principaux choix d implémentation Architecture matérielle / logicielle Diagramme de déploiement complété Décomposition en tâches et fils (threads) complète Réutilisation Idem dossier de conception préliminaire Allocation des ressources Précisions complémentaires concernant les ressources matérielles et logicielles utilisées 2.7. Sous-systèmes Idem dossier de conception préliminaire 2.8. Dictionnaire de données Dictionnaire complété 3 Le respect de ce plan n est pas obligatoire : il est fourni à titre illustratif afin de montrer comment intégrer l utilisation de la modélisation UML dans la documentation.

22 Page ARCHITECTURE 3.X SOUS SYSTEME X 3.X.1 ARCHITECTURE POUR LE SOUS SYSTEME X Vue générale du sous-système Diagramme de classe du sous-systèmes 3.X.1.Y Paquetage Y du sous système X 3.X.1.Y.1 Diagrammes de classes Repris du dossier de conception préliminaire et éventuellement complété 3.X.1.Y.2 Définition des classes Repris du dossier de conception préliminaire et éventuellement complété 3.X.1.Y.3 Définition des Opérations Description textuelle et précise des opérations avec paramètres, mode de passage, pré et post conditions, etc. 3.X.1.Y.4 Définition des Attributs Description textuelle et précise des attributs 3.X.1.Y.5 Justification des choix Repris du dossier de conception préliminaire et éventuellement complété 3.X.1.Y.6 Autres Diagrammes Repris du dossier de conception préliminaire et éventuellement complété par des diagrammes complémentaires ou plus précis 3.X.2 DECOMPOSITION EN TACHES POUR LE SOUS SYSTEME X 3.X.1. Introduction Repris du dossier de conception préliminaire et éventuellement complété 3.X.2. Détail Détail précis de chaque tâche ou fils avec attributs associés : priorité, type de tâche, principes d activation, chronogrammes éventuels 3.X.3. Mapping Repris du dossier de conception préliminaire et éventuellement complété 4. TRAÇABILITE EXIGENCES LOGICIELLES VERS CONCEPTION Idem dossier de conception préliminaire

23 Page PHASE DE RÉALISATION 7.1 DOCUMENTS DE SORTIE DE LA PHASE Le(s) document(s) constituant la mise à jour du Dossier de Justification, Les versions mises à jour des manuels utilisateurs. 7.2 DOSSIER DE JUSTIFICATION Le Dossier de Justification mis à jour doit contenir les éléments supplémentaires suivants : Eléments constitutifs Contenu Matrices de traçabilité Modules de code / éléments de conception détaillée Versions mises à jour des plans d'essais de non détaillé (non spécifique de l objet) validation Plans de tests unitaires et d'intégration non détaillé (non spécifique de l objet) Résultats des tests unitaires non détaillé (non spécifique de l objet) Résultats des tests d'intégration non détaillé (non spécifique de l objet) 8. PHASE DE VALIDATION 8.1 DOCUMENTS DE SORTIE DE LA PHASE Le(s) document(s) incluant la mise à jour de la Spécification Technique du Logiciel Le(s) document(s) constituant la mise à jour du Dossier de Justification 8.2 SPECIFICATION TECHNIQUE DU LOGICIEL (STL) La Spécification Technique du Logiciel (STL) mise à jour doit contenir les éléments supplémentaires suivants : Eléments constitutifs Manuels d'opération et de maintenance validé Contenu non détaillé (non spécifique de l objet) 8.3 DOSSIER DE JUSTIFICATION Le Dossier de Justification mis à jour doit contenir les éléments supplémentaires suivants : Eléments constitutifs Contenu Matrices de traçabilité Essais de validation / exigences de la STL Résultats des tests de validation non détaillé (non spécifique de l objet)

24 REFERENTIEL NORMATIF REALISE PAR : Centre Spatial de Toulouse Délégation à l'assurance de la Qualité 18 Avenue Edouard Belin TOULOUSE CEDEX 4 Tél : Fax : CENTRE NATIONAL D'ETUDES SPATIALES Siège social : 2 pl. Maurice Quentin Paris cedex 01 / Tel. (33) / Fax : RCS Paris B / Siret : / Code APE 731Z