Attention, ces classes A, B, C sont indépendantes des classes réglementaires Européennes I, IIa, IIb et III. La gestion du cycle de vie du logiciel appelle d’autres processus de la société, notamment :
Cette procédure décrit le processus autour du cycle de vie du logiciel (de) DM mis en place par la société. Le processus se décompose en 5 activités :
Cette procédure concerne :
ADR; C&D; CVL; DGR; DDM; E.L.; D.T.; IFU; N.C., PQP; SEMP; SUL; SOUP; U.L.
L’identification des risques dus au logiciel est effectuée en début de développement, elle est affinée au fil des spécifications.
Elle est mise à jour durant toute la vie du dispositif, en fonction des évolutions du contexte. Les risques identifiés sont enregistrés dans le document DOC.AGR. L’identification tient compte des causes potentielles suivantes :
Une classe de dangerosité est associée aux risques causés ou maitrisés par le logiciel :
Probabilité | Gravité | |||
---|---|---|---|---|
1 | 2 | 3 | 4 | |
1 | A | A | A | A |
2 | A | B | C | C |
3 | A | B | C | C |
4 | A | B | C | C |
Par défaut et avant analyse, le logiciel est traité comme étant de classe C.
Les risques causés par le logiciel ou maitrisés par le logiciel sont pris en compte pour évaluer la classe. La classe des E.L. est évaluée en fonction de la gravité et de l’acceptabilité des risques :
Deux cas se présentent pour déterminer la classe de sécurité logicielle :
Les risques auxquels le logiciel contribue sont pris en compte après mise en œuvre des mesures de réduction non logicielles, donc en fonction du risque résiduel. Les risques maitrisés par le logiciel sont pris en compte sur la base du risque initial (pas de réduction de la classe de sécurité via le logiciel, car le logiciel portant la mesure de maîtrise peut lui-même défaillir).
L’évaluation de la classe du logiciel est enregistrée dans le DOC.DGR, elle s’appuie sur les classes des éléments logiciels enregistrées dans DOC.ADR.
La classe de sécurité est attribuée à l’E.L. (ou système logiciel) de plus haut niveau. Les E.L. enfants héritent de la classe de sécurité de leur parent.
Il est possible d’avoir au sein d’un système logiciel des E.L. de classe de sécurité différentes.
Cela est possible au moyen d’une séparation architecturale entre les E.L. de classes différentes.
Le cas échéant, la séparation des E.L. parents/enfants de classes différentes est justifiée et expliquée dans le document SAL.CVL.
Durant le développement : il est autorisé d’appliquer la présente procédure en fonction de la classe de chaque E.L. ; ou d’appliquer systématiquement pour tous les E.L. les exigences de la classe la plus élevée.
Les séparations architecturales communément admises :
Les mesures de maitrise mises en œuvre par le logiciel (ex : nouvelle spécification en matière d’algorithme, de condition d’alarme, fonction de surveillance, …) sont enregistrées dans le document DOC.ADR, elles constituent de nouvelles entrées à la spécification du logiciel.
Ce contenu est réservé aux abonnés.