Developpement Process « Coding party !! » Tony Carnal Altran.

Présentation au sujet: "Developpement Process « Coding party !! » Tony Carnal Altran."— Transcription de la présentation:

1 Developpement Process « Coding party !! » Tony Carnal Altran

2 Comment ca se passe ? Discussion initiale -> Ecoute du besoin Accord Allocation du budget Etude du besoin Design Code et test Executable final Documentation Audit Final Accepté !!!

3 Developement Process But  Développer les exigences du systèmes aux DAL demandés  Développer l’architecture logiciel  Produire le code source  Intégrer les composants et produire un exécutable

4 Developement Process Production  High level et Low level requirement data  Software Requirement Specification SRS  Software Design Document SDD  Description de l’architecture logiciel  Code source  Code objet exécutable

5 Y a quoi dedans ? Besoin et spec Code et Production D’executable Intégration Sur Cible

6 Objectifs DO-178B

7 Les types d’exigences Besoins Système : Besoins applicables au système (Système : collection de composants soft et hard organisés pour accomplir une suite de fonctions) Besoins de haut niveau (High level requirements) HLR : Besoins logiciel développé à partir de l’analyse des besoins systèmes, sécurité et de l'architecture système Besoins de bas niveau (Low level requirements) LLR : Besoins logiciel dérivés des HLR, des besoins dérivés et des contraintes de design permettent de développer le code source sans plus d’informations Besoins dérivés : Besoins additionnels qui résultent directement de processus de développement logiciel qui ne sont pas directement traçable au HLR Tracabilité : La preuve d’une association entre 2 éléments

8 Attention !!! Toute exigence doit être testable !!

9 Niveaux de besoins HLR LLR Code REQ 001. REQ 002. if () then else …

10 Activités des exigences logiciels Identifier les HLR qui traitent des besoins Systèmes  Identifier les besoins fonctionnels et d’interface du système (comportement opérationnel attendu et les E/S)  Identifier les besoins systèmes de prévention des erreurs (watch dog, partitionnement …)  Identifier tout les besoins non fonctionnels Performance Portabilité, maintenance …  Identifier tout les besoins de haut niveau dérivés

11 Activité de design logiciel Tracer les LLR vers les HLR Identifier tout les besoins dérivés de bas niveau Etablir l’architecture logiciel  Séparer le logiciel en composants  Identifier les flots de données et de contrôle Etablir l’allocation des LLR dans les composants Etablir l’allocation de temps processeur pour les taches Définir le détail des algorithmes utilisées et des structures

12 HLR ??? LLR ??? HLRs  Exprime ce que le logiciel doit faire  Une HLR peut contenir plusieurs exigences  On met les HLR dans la SRS LLRs  Exprime comment les composants du logiciel vont faire leur travail  Une LLR permet d’écrire du code source  On met les LLR dans le SDD

13 CSCI/ CSC/CSU CSCI : Computer Software Component Interface  Ensemble de logiciels traité comme une seule entité dans le processus de gestion de conf CSC : Computer Software Component  Une partie fonctionnellement ou logiquement distincte du CSCI CSU : Computer Software Unit  Elément spécifié d’un CSC testable ou compilable Module  Unité minimale du programme

14 CSCI/ CSC/CSU CSU CSC CSCI

15 Traceabilité ? CSC/CSU Code Traceabilité Systems Requirements Traceabilité HLR LLR

16 Attention !! Tracabilité du Bas vers le Haut (Code source vers HLR) Tracabilité du Haut vers le Bas (HLR vers Source La Tracabilité dans les 2 sens est très importante !!!

17 La traceabilité est un objectif essentiel pourquoi ? Sécurité  La sécurité est une propriété du système  La tracabilité assure que les exigences du système sont implémenté dans le code source Pas d’exigences non remplit Pas d’exigences en plus Impact sur l’analyse  D’une grande aide pour identifier l’origine des problèmes

18 Besoins dérivés 2 objectifs  Les HLRs et les LLRs dérivées sont fournis au niveau du processus de gestion de sécurité système Importance de ces objectifs ?  L’analyse de sécurité est réalisé au niveau du système. Le processus de sécurité système doit connaître tous les besoins dérivés pour en analyser les impacts au niveau de la sécurité.

19 Différents type de code Code objet exécutable :  Représentation bas niveau directement utilisable par la cible Code exécutable chargeable :  Code exécutable que l’on peut télécharger sur une cible ou que l’on peut charger dans de la PROM (programmation Read Only Memory) Code Objet : code intermédiaire Code source : Code haut niveau compréhensible par l’homme

20 Activité de codage logiciel Implémente les besoins de Bas Niveau (LLR) et l’architecture choisie dans le code source  Code dans le langage choisi chaque procédure  Code conforme au standards de programmation Les LLRs sont directement implémentés dans le code source. Si ça n’est pas le cas il faut surement la modifier ou alors c’est une HLR. Une LLR représente environ 20-25 lignes (surtout en DAL A)

21 Activité du processus d’integration Intégration : Activité de combiner les composants de code But  Générer le code objet, le code source, linker et loader les données Compiler chaque module  En utilisant le bon compilo et la bonne version  En utilisant les bons options Linker les code objets et construire en exe loadable  Loader l’executable sur la cible pour faire l’intégration Soft/Hard

22 Quel est le risque principale de la DO ici ? NE PAS SUIVRE LES RECOMMENDATIONS DE TRACEABILITE