LépésJelenlegi helyzetMegoldás
01
Prototípus
A prototípus működik, de hiányoznak a követelmények, a kockázatkezelési dokumentáció és a felülvizsgálathoz szükséges, elfogadható tesztek.
→JavulásÁtvizsgáljuk a prototípust, és meghatározzuk, mely részeit lehet megtartani. A már működő kódot így nem kell újra megírni.
02
Szabályozási eljárás és tervezés
A szabályozási eljárásról még nem született döntés, a befektetők pedig fejlesztési tervet kérnek.
→JavulásElőször elkészítjük a fejlesztési tervet, és meghatározzuk a szoftverbiztonsági osztályt. Erre a két dokumentumra építjük a többi dokumentációt.
03
Specifikáció és kockázatkezelés
A csapatnak még nincs tapasztalata a követelmények meghatározásában, a szoftverarchitektúra tervezésében és az ISO 14971 szerinti kockázatelemzésben.
→JavulásA követelményeket és a kockázatelemzést még a kódolás előtt elkészítjük. Ezek alapján tervezzük meg a szoftvert és a teszteket. A dokumentációból így nyomon követhető az eszköz fejlesztése.
04
Fejlesztés és verifikáció
A csapatban nincsenek szoftvermérnökök, felvételük pedig tovább tartana, mint amennyit a rendelkezésre álló finanszírozás megenged.
→JavulásCsapatunk a szerződés aláírását követő két-három héten belül munkába áll. Az elkészült kódhoz teszteket is készítünk.
05
Benyújtás
A threat model (az eszköz elleni lehetséges támadások módszeres elemzése) és az SBOM (a buildben szereplő összes szoftverkomponens jegyzéke) csak a hatósági benyújtásra készül el, amikor az architektúra már végleges.
→JavulásA threat modeling eredményeit már a szoftverarchitektúra első változatába beépítjük. Így a kiberbiztonsági dokumentáció is időben elkészül.
06
Release és forgalomba hozatal utáni időszak
Az első release után a dokumentáció már nem követi a forráskód változásait.
→JavulásMinden release szabályozott változáskezelési folyamaton megy keresztül, így a dokumentáció követi a forráskód változásait. Azt is megvizsgáljuk, szükséges-e a módosítás miatt új 510(k) benyújtása vagy a bejelentett szervezet értesítése.