Chapitre 2 Développement des systèmes interactifs critiques : approches et moyens
1 Approches, processus et recommandations pour le développement de systèmes interactifs
1.3 Approches, processus et recommandations pour le développement de systèmes critiques
développement de systèmes critiques
Le développement de systèmes critiques requiert des étapes particulières supplémentaires afin d’assurer les propriétés de sûreté et fiabilité. Par rapport aux approches et processus génériques présentés dans la section 1.1, des étapes détaillées de vérification, validation et certification sont nécessaires (Storey, 1996).
1.3.1 DO 178 B
Le processus de développement définit dans le standard DO-178B (European Organisation for Civil Aviation Equipment, 1992) est présenté en Figure 25.
Figure 25. Processus de développement DO-178B
Ce processus est composé de quatre phases :
- La phase d’analyse des exigences (« SW Requirements process ») qui produit les exigences logicielles de haut niveau (HLR)
- La phase de design (« SW Design process ») qui produit les exigences logicielles de bas niveau (LLR) ainsi que l’architecture du logiciel à partir des exigences de haut niveau(HLR) - La phase de codage (« SW Coding process ») qui produit le code source et le code de
l’application
- La phase d’intégration (Integration Process) qui produit le code exécutable et lie le logiciel au système intégré.
Les exigences logicielles de haut niveau (HLR) sont produites directement par l'analyse des exigences du système et l'architecture du système. Ils comportent des spécifications d'exigences fonctionnelles et opérationnelles, les contraintes de mémoire, interfaces matérielles et logicielles, les détections de panne et les exigences de sécurité. Les HLR sont ensuite développées au cours du processus de conception de logiciels, produisant ainsi l'architecture logicielle et les exigences de bas niveau (LLR). Il s'agit notamment des descriptions des entrées / sorties, les données et les flux de contrôle, la limitation des ressources, la planification et des mécanismes de communication, ainsi que des composants logiciels.
Grâce au processus de codage, les exigences bas-niveau sont mises en œuvre sous forme de code source. Le code source est compilé et lié par le processus d'intégration en un code exécutable lié à l'environnement cible. À toutes les étapes, la traçabilité est requise: entre les exigences du système et HLR, HLR et LLR, entre LLR et le code, et aussi entre les essais et les exigences.
De plus, le standard DO-178B fournit des lignes directives pour les processus de vérification du logiciel, de gestion de la configuration du logiciel et d’assurance qualité du logiciel.
1.3.2 ESA PSS-05
Le processus de développement PSS-05 (European Space Agency, 1994), nommée « Software Engineering Standard », est utilisé pour différents projets de l’ESA (European Space Agency). Ce standard propose des lignes directives pour le développement et la maintenance d’applications logicielles.
Figure 26. Processus de développement ESA PSS-05
Le processus de développement issu de la norme PSS-05 (European Space Agency, 1994) (présenté en Figure 25) de l’ESA (European Space Agency) est composé de six phases :
- La définition des exigences utilisateurs (UR) : La phase UR est la «phase de définition du problème» du logiciel. Le champ d'application du système et les besoins des utilisateurs doivent être précisées. Cela peut être réalisé via des interviews ou enquêtes, ou par la création de prototypes. Les besoins spécifiques des utilisateurs doivent être identifiés et consignés dans le document des besoins des utilisateurs (URD).
- La définition des exigences logicielles (SR) : La phase de SR est la phase d'«analyse» du logiciel. Une partie essentielle de l'activité d'analyse est la construction d'un «modèle» décrivant ce que le logiciel doit faire, et non pas «comment» le faire. La construction de prototypes permet de clarifier les exigences logicielles. Le livrable principal de cette phase est le document sur les exigences du logiciel (SRD).
- La conception de l’architecture (AD) : Le but de la phase d’AD est de définir la structure du logiciel. Le modèle construit dans la phase de SR est le point de départ. Ce modèle est transformé dans la conception architecturale en affectant des fonctions aux composants logiciels et en définissant le contrôle et les flux de données entre eux. Cette phase peut comporter plusieurs itérations de conception. Les parties complexes ou critiques doivent être identifiées dans cette conception.
- La conception détaillée et la production (DD) : Le but de la phase de DD est de détailler la conception du logiciel, le coder, le documenter et de le tester. Le document de conception détaillée (DDD) et le Software User Manual (SUM) sont produits en même temps que le code et les tests. Initialement, le DDD et SUM contiennent les sections correspondant aux plus hauts niveaux du système. Au fur et à mesure de la conception, les sous-sections
relatives à des niveaux inférieurs sont ajoutées. À la fin de la phase, les documents sont complétés et, avec le code, constituent les éléments livrables de cette phase.
- Le transfert (TR) : Le but de cette phase est d'établir que le logiciel répond aux exigences fixées dans l'URD. Cela se fait par l'installation du logiciel et des essais d'acceptation. Lorsque le logiciel a été démontré capable de fournir les capacités requises, le logiciel peut être accepté provisoirement et la phase d'opérations peut commencer.
- La phase d’opérations et maintenance (OM) : Une fois le logiciel mis en service, il doit être soigneusement contrôlé afin de vérifier s’il satisfait à toutes les exigences définies dans l'URD. Lorsque le logiciel a passé tous les tests d'acceptation, il peut être finalement validé. L'historique du projet de document (PHD) résume les informations importantes de gestion accumulées au cours du projet.
Après acceptation définitive, le logiciel peut être modifié pour corriger les erreurs détectées lors des étapes antérieures ou parce que de nouvelles exigences se posent.
1.3.3 Spécificité des systèmes critiques : la certification
Les responsables de la conception et du développement d’un système critique doivent démontrer que le système est suffisamment sûr pour que les autorités de certification émettent l’autorisation de mise en circulation du système.
Storey (Storey, 1996) indique trois aspects techniques importants pour accéder aux phases de certification :
- La démonstration que les risques majeurs ont été identifiés et pris en compte. - La preuve que le système est conforme aux standards en vigueur.
- L’argumentation montrant que le système est sûr et qu’il le restera au cours de son cycle de vie.
Les étapes-clés des approches de développement des systèmes critiques fournissant un support pour les phases de certification sont : la vérification, la validation et le test.
La vérification sert à montrer que les ressources produites par une phase du cycle de développement sont conformes aux exigences soumises en entrée de cette phase du cycle.
La validation sert à montrer que les exigences émises au début du cycle de vie du cycle de développement sont appropriées et cohérent avec les besoins du client et/ou de l’utilisateur.
Le test est une manière de vérifier et valider tout ou partie du système (les revues de spécifications et de code sont d’autres manières). Dans le cas d’un système interactif, il est impossible de couvrir toutes les possibilités de combinaisons d’interactions avec le test. Ainsi, la modélisation formelle est une activité de plus en plus utilisée et faisant l’objet de nombreuses recherches (Miller, Tribble, Whalen, & Heimdal, 2006).