A szoftverfejlesztés folyamata
Így készítünk új release-t egy egészségügyi alkalmazáshoz az MDR szerint
LépésJelenlegJavaslatunk
01
Követelmények
Az alkalmazás rendeltetését az alkalmazásáruházban megjelenő leírás és a marketingállítások határozzák meg. Írásos specifikáció nincs.
→JavaslatunkA követelményeket specifikációban rögzítjük, és gondoskodunk arról, hogy a kódban és a tesztekben is visszakövethetők legyenek.
02
Tervezés
Az alkalmazás, a backend és a dashboard architektúráját csak a fejlesztők ismerik.
→JavaslatunkDokumentáljuk az architektúrát és a SOUP-listát, majd minden release-nél frissítjük őket.
03
Megvalósítás
A nyílt forráskódú könyvtárak és SDK-k dokumentáció nélkül kerülnek be a buildbe.
→JavaslatunkAz új könyvtárakat és SDK-kat már akkor felvesszük a SOUP-listába, amikor bekerülnek a buildbe.
04
Verifikáció
A kockázatelemzés és a tesztprotokollok csak a kód elkészülte után készülnek el, ha egyáltalán elkészülnek.
→JavaslatunkA release előtt teszteljük, mi történik, ha hibás érték jelenik meg, szinkronizálás közben adat vész el, vagy egy rekord rossz beteghez kerül.
05
Release
A kiadott verzió nem kapcsolható egyértelműen ahhoz a verzióhoz, amelyet a bejelentett szervezet vagy az FDA felülvizsgált.
→JavaslatunkA CI pipeline létrehozza a release-ek nyilvántartását, így minden élesített verzió visszakövethető a felülvizsgálatig.
06
Támogatás éles üzemben
Az összeomlásokról, a panaszokról és az AI-funkció modellváltozásairól szóló információk különböző helyekre érkeznek.
→JavaslatunkAz anomáliákat és a panaszokat közös listán tartjuk nyilván, a modell minden módosítását pedig változáskezelésnek vetjük alá.
07
Változtatások
A változáskezelés, a kockázatértékelés és a tesztelés dokumentálása lassítja a heti release-eket.
→JavaslatunkA változáskezelést beépítjük a pipeline-ba, így az apphoz továbbra is hetente jelenhet meg új release.