{"id":11562,"date":"2022-09-01T11:23:05","date_gmt":"2022-09-01T08:23:05","guid":{"rendered":"https:\/\/atostek.com\/?p=11562"},"modified":"2022-09-13T09:44:26","modified_gmt":"2022-09-13T06:44:26","slug":"regops-laakinnallisen-ohjelmiston-kettera-kehitys","status":"publish","type":"post","link":"https:\/\/atostek.com\/regops-laakinnallisen-ohjelmiston-kettera-kehitys\/","title":{"rendered":"RegOps \u2013 l\u00e4\u00e4kinn\u00e4llisen ohjelmiston ketter\u00e4 kehitys"},"content":{"rendered":"

L\u00e4\u00e4kinn\u00e4llisen laitteen tai ohjelmiston kehitys on Euroopassa s\u00e4\u00e4delty\u00e4 EU 2017\/745 -regulaation eli MDR-asetuksen my\u00f6t\u00e4. Toisaalta regulaatio ei tuo kovinkaan paljoa lis\u00e4ty\u00f6t\u00e4 ohjelmistojen kehitykseen \u2013 verrattuna siihen, kuinka ohjelmistokehitys kuuluisi muutenkin tehd\u00e4. Kuinka regulaatiosta voidaan ottaa kaikki hy\u00f6ty irti niin, ettei se tunnu taakalta?<\/strong><\/p>\n

Helpoin tapa t\u00e4ytt\u00e4\u00e4 MDR-asetuksen (Medical Device Regulation) vaatimukset ohjelmistokehitykselle on hy\u00f6dynt\u00e4\u00e4 ISO 13485-, IEC 62304-, ISO 14971- ja IEC 62366-1 -standardeja. Tuotteesta ja k\u00e4ytt\u00f6tarkoituksesta riippuen saatetaan toki tarvita muitakin standardeja.<\/p>\n

Perinteinen vesiputousmalli<\/h2>\n

Kun standardeja sovelletaan toimintamalleiksi, saattaa syntyv\u00e4 prosessi lipsahtaa helposti perinteisen vesiputousmallin<\/strong> puolelle. Vesiputousmallissa m\u00e4\u00e4ritell\u00e4\u00e4n ensin l\u00e4\u00e4kinn\u00e4llisen laitteen k\u00e4ytt\u00f6tarkoitus ja vaatimukset. T\u00e4m\u00e4n j\u00e4lkeen suunnitellaan ja dokumentoidaan ohjelmiston arkkitehtuuri sek\u00e4 rajapinnat. Kun kaikki suunnitelmat on vihdoin saatu tehty\u00e4 ja katselmoitua, luovutetaan ohjelmisto toteutusvaiheeseen. T\u00e4ss\u00e4 vaiheessa p\u00e4\u00e4st\u00e4\u00e4n vihdoin kirjoittamaan koodi, kuten aiemmassa vaiheessa on suunniteltu.<\/p>\n

Ohjelmiston toteutuksen j\u00e4lkeen kirjoitetaan viel\u00e4 verifioivat testit. Puhdas testiraportti ja ohjelmisto vied\u00e4\u00e4n validointivaiheeseen kliinikoille. Lis\u00e4ksi k\u00e4ytett\u00e4vyydest\u00e4 on muistettava tehd\u00e4 k\u00e4ytett\u00e4vyystestit IEC 62366-1 -standardin mukaisesti sek\u00e4 mallintaa potilasturvallisuusriskit ISO 14971 -standardin mukaisesti.<\/p>\n

Vesiputous vai SCRUM?<\/h2>\n

Perinteisess\u00e4 vesiputousmallissa suunnittelu-, katselmointi-, toteutus-, verifiointi- ja validointivaiheet tehd\u00e4\u00e4n koko ohjelmistolle isoina askelina. Pahimmillaan ohjelmiston dokumentointi laaditaan vasta j\u00e4lkik\u00e4teen regulaation vaatimukset t\u00e4ytt\u00e4v\u00e4ksi. Lis\u00e4ksi l\u00e4\u00e4kinn\u00e4llisen ohjelmiston kehitystiimin j\u00e4senet ty\u00f6skentelev\u00e4t eriaikaisesti tai he joutuvat tekem\u00e4\u00e4n pitki\u00e4 aikoja teht\u00e4vi\u00e4 omien kompetenssialueidensa ulkopuolella. T\u00e4m\u00e4 sy\u00f6 tiimin tehokkuutta tai pahimmillaan aiheuttaa henkil\u00f6st\u00f6ss\u00e4 turhautumista \u2013 ainakin niiden ohjelmistosuunnittelijoiden n\u00e4k\u00f6kulmasta, jotka tykk\u00e4\u00e4v\u00e4t koodata.<\/p>\n

Ketter\u00e4 kehitys ratkaisee vesiputousmallin ongelmia ja ennen kaikkea nopeuttaa yksitt\u00e4isen muutoksen l\u00e4pimenoaikaa. Yksi yleisesti k\u00e4ytetty ketter\u00e4n kehityksen viitekehys on SCRUM<\/strong>, jossa kehitys etenee sykleitt\u00e4in sprinteiss\u00e4. Yksi sprintti kest\u00e4\u00e4 muutaman viikon ja aina sprintin ajaksi tiimi valitsee ty\u00f6jonosta teht\u00e4v\u00e4t ja tavoitteet.<\/p>\n

Sprintin p\u00e4\u00e4tteeksi ohjelmistosta muodostuu uusi iteraatio, tuotantokelpoinen uusi versio. Ohjelmistokehitt\u00e4j\u00e4n n\u00e4k\u00f6kulmasta sprintiss\u00e4 voi keskitty\u00e4 kehitt\u00e4miseen \u2013 projektikohtainen prosessi toki edellytt\u00e4\u00e4, ett\u00e4 suunnittelua, dokumentaatiota ja testaamista on teht\u00e4v\u00e4. Sprintin demossa on oltava tavoitteiden mukaista n\u00e4ytett\u00e4v\u00e4\u00e4 ja se rytmitt\u00e4\u00e4kin ohjelmistokehitt\u00e4j\u00e4n tekemist\u00e4 sopivasti.<\/p>\n

RegOps<\/h2>\n

Kun perinteiseen ohjelmistokehitykseen yhdistet\u00e4\u00e4n ohjelmistokehityksen ja testauksen lis\u00e4ksi tuotannon yll\u00e4pito, puhutaan DevOpsista<\/strong> (yhdistelm\u00e4 sanoista development<\/em> ja operations<\/em>). K\u00e4yt\u00e4nn\u00f6ss\u00e4 t\u00e4m\u00e4 tarkoittaa, ett\u00e4 kehitystiimin teht\u00e4v\u00e4ksi annetaan my\u00f6s tietoj\u00e4rjestelm\u00e4n yll\u00e4pito. DevOpsia voidaan hallita SCRUM-viitekehyksess\u00e4, kunhan ennakoimattomille yll\u00e4pitoteht\u00e4ville tehd\u00e4\u00e4n varaus kehitysteht\u00e4vien lomaan.<\/p>\n

L\u00e4\u00e4kinn\u00e4llisen ohjelmiston tapauksessa, kun mukaan lis\u00e4t\u00e4\u00e4n viel\u00e4 regulaatiovaatimusten t\u00e4ytt\u00e4minen, on RegOps<\/strong>-m\u00e4\u00e4ritelm\u00e4 valmis. RegOpsin mukaisesti tarvitaan siis vaatimusten m\u00e4\u00e4rittely\u00e4, suunnitelmien tekoa, potilasturvallisuusriskien kartoitusta sek\u00e4 n\u00e4iden kaikkien katselmointia. Ja pit\u00e4\u00e4h\u00e4n ohjelmisto my\u00f6s koodata, testata sek\u00e4 katselmoida toteutus. Voisiko t\u00e4m\u00e4n kaiken tehd\u00e4 ketter\u00e4sti vaikkapa SCRUM-viitekehyksess\u00e4?<\/p>\n

Scrummaten maaliin<\/h2>\n

L\u00e4\u00e4kinn\u00e4llisen ohjelmiston ketter\u00e4 kehitys voidaan rakentaa SCRUM-viitekehyksess\u00e4 katselmointien ymp\u00e4rille, kuten kuvassa 1. esitet\u00e4\u00e4n.<\/p>\n

Sprintin aloitus<\/h3>\n

Sprintti aloitetaan valitsemalla ty\u00f6jonosta sopiva m\u00e4\u00e4r\u00e4 teht\u00e4vi\u00e4 samalla hieman tarkentaen niit\u00e4. Atostekin projekteissa listan teht\u00e4v\u00e4t ovat yleens\u00e4 asiakkaan vaatimusten mukaisia l\u00e4\u00e4kinn\u00e4llisen laitteen ohjelmiston tuotekehitysteht\u00e4vi\u00e4, ja ne on nostettu sprinttiin yhdess\u00e4 asiakkaan tuoteomistajan kanssa. Ne ovat uusia ominaisuuksia tai muutoksia olemassa oleviin ominaisuuksiin. Toisaalta ne voivat olla my\u00f6s bugiraporttien selvittely\u00e4 ja sit\u00e4 kautta korjauksia koodiin.<\/p>\n

Joissain tapauksissa toteutamme Atostekilla korkean tason vaatimusten mukaisia teht\u00e4vi\u00e4, jotka on pilkottu pienemmiksi, jotta ne mahtuvat sprinttiin. Sprintin teht\u00e4v\u00e4t on tarkennettu sille tasolle, ett\u00e4 teht\u00e4v\u00e4n kuvauksesta selvi\u00e4\u00e4, mit\u00e4 tulee tehd\u00e4 ja mik\u00e4 on teht\u00e4v\u00e4n valmiuden m\u00e4\u00e4ritelm\u00e4.<\/p>\n

Katselmointien kautta toteutukseen<\/h3>\n

Keskell\u00e4 sprintti\u00e4 katselmoidaan ja hyv\u00e4ksyt\u00e4\u00e4n koko tiimin kanssa l\u00e4\u00e4kinn\u00e4llisen ohjelmiston p\u00e4ivitetyt vaatimukset, arkkitehtuurisuunnitelmat, yksikk\u00f6suunnitelmat, rajapintakuvaukset, riskitaulukot sek\u00e4 muut tarpeelliset suunnitelmat. T\u00e4ss\u00e4 suunnittelukatselmoinnissa jokainen tiimin j\u00e4sen p\u00e4\u00e4see esittelem\u00e4\u00e4n omat suunnitelmansa ja suunnittelukatselmoinnista tuotetaan virallinen katselmointip\u00f6yt\u00e4kirja ISO 13485 -standardin vaatimuksia t\u00e4ytt\u00e4m\u00e4\u00e4n.<\/p>\n

T\u00e4m\u00e4n j\u00e4lkeen hyvin suunnitellut ominaisuudet toteutetaan, testataan sek\u00e4 julkaistaan sis\u00e4isesti. Sprintin demo toimii julkaistun version toteutuskatselmointina.<\/p>\n

Riippuen sprintiss\u00e4 tehtyjen muutosten laajuudesta ja ennenkaikkea niihin liittyvist\u00e4 riskeist\u00e4, on ohjelmisto viel\u00e4 validoitava ja mahdollisesti hyv\u00e4ksytett\u00e4v\u00e4 ilmoitetulla laitoksella ennen tuotantoon julkaisua. V\u00e4h\u00e4isten muutosten tapauksessa ilmoitetulle laitokselle riitt\u00e4\u00e4 yleens\u00e4 pelkk\u00e4 ilmoitus. Sen j\u00e4lkeen uusi versio voidaan siirt\u00e4\u00e4 validaatiotarkastelun kautta tuotantoon.<\/p>\n

\"L\u00e4\u00e4kinn\u00e4llisen
Kuva 1. RegOps-prosessi<\/figcaption><\/figure>\n

Ent\u00e4 jos kaikki ei mene kuin Str\u00f6ms\u00f6ss\u00e4?<\/h3>\n

Aina kaikki ei kuitenkaan mene suunnitelmien mukaan. Jokin listan teht\u00e4v\u00e4 saattaa osoittautua ty\u00f6l\u00e4\u00e4mm\u00e4ksi kuin on ajateltu. Tai ehk\u00e4 joku tiimil\u00e4isist\u00e4 saa flunssan, eik\u00e4 kaikkea ehdit\u00e4 suunnittelemaan sprintin puoliv\u00e4lin suunnittelukatselmointiin menness\u00e4 valmiiksi. Osa suunnitelmista j\u00e4\u00e4 t\u00e4ll\u00f6in keskener\u00e4isyyden vuoksi katselmoimatta, eik\u00e4 niiden kanssa voida edet\u00e4 toteutusvaiheeseen.<\/p>\n

Toteutusteht\u00e4vien ja muiden teht\u00e4vien loppuessa voidaan sprinttiin nostaa ty\u00f6jonosta uusia ominaisuuksia suunniteltavaksi, jolloin tilanne tasapainottuu. Aina on my\u00f6s mahdollista pit\u00e4\u00e4 toinen suunnittelukatselmointi saman sprintin aikana, jos alkuper\u00e4inen haluttu ominaisuus on kriittinen sprintin tavoitteen kannalta.<\/p>\n

Moniosaajatiimi vai monipuoliset ty\u00f6teht\u00e4v\u00e4t?<\/h2>\n

Kuinka regulaatiosta sitten saadaan kaikki mahdollinen hy\u00f6ty irti? RegOps-menetelm\u00e4ll\u00e4 ohjelmistosuunnittelijoiden ty\u00f6nkuva monipuolistuu, ja yhden ominaisuuden voi antaa ty\u00f6ntekij\u00e4lle alusta loppuun asti viet\u00e4v\u00e4ksi. Halutun ominaisuuden perusteella h\u00e4n p\u00e4ivitt\u00e4\u00e4 vaatimusm\u00e4\u00e4rittelyn, arkkitehtuurisuunnitelman, rajapinnat ja tarvittaessa yksikk\u00f6suunnitelmat. Lis\u00e4ksi h\u00e4n esittelee ominaisuuden riskienhallintapalaverissa sek\u00e4 suunnitelmien katselmoinnissa.<\/p>\n

Uuden toteutettavan ominaisuuden mahdollisia vaikutuksia potilasturvallisuuteen pohditaan koko tiimin kesken. Toki projektip\u00e4\u00e4llikk\u00f6 ja\/tai laatup\u00e4\u00e4llikk\u00f6 tukevat ty\u00f6t\u00e4 pyydett\u00e4ess\u00e4. Kun suunnitelmat on hyv\u00e4ksytty, asia on kirkkaana mieless\u00e4 eik\u00e4 toteutuksessa mene kauaa.<\/p>\n

Ohjelmistosuunnittelija voi aloittaa automaattitestien kirjoittamisen ja hy\u00f6dynt\u00e4misen jo kehityksen aikana, t\u00e4ll\u00f6in kehitykseen saadaan testeist\u00e4 t\u00e4ysi hy\u00f6ty. Regulaatio ei olekaan en\u00e4\u00e4 taakka vaan teht\u00e4v\u00e4t ovat sit\u00e4 samaa, mit\u00e4 koulussakin jo opetettiin. Ja mik\u00e4 parasta \u2013 jokaisessa sprintiss\u00e4 p\u00e4\u00e4see suunnittelemaan, koodaamaan sek\u00e4 yll\u00e4pit\u00e4m\u00e4\u00e4n tuotantoj\u00e4rjestelm\u00e4\u00e4. Se on monelle atostekilaiselle asian ydin, parasta mit\u00e4 saa tehd\u00e4!<\/p>\n

Kun ohjelmistosuunnittelija osallistuu vaatimusten, suunnitelmien ja testien tekoon sek\u00e4 katselmointeihin ketter\u00e4n prosessin osana, h\u00e4n t\u00e4ytt\u00e4\u00e4 samalla niin l\u00e4\u00e4kinn\u00e4llisen ohjelmiston standardien vaatimukset kuin hy\u00f6dynt\u00e4\u00e4 my\u00f6s yliopisto-opintonsakin. Laadukkaasti tehdyst\u00e4 ty\u00f6st\u00e4 j\u00e4\u00e4 hyv\u00e4 mieli kaikille osapuolille!<\/p>\n

\n
\n
\n\t\t\"\"\n\t<\/div>\n
\n

Juho Lepp\u00e4m\u00e4ki<\/strong><\/p>\n

\t\tLaatup\u00e4\u00e4llikk\u00f6<\/em>
\n\t\tjuho.leppamaki@atostek.com<\/a>
\n\t\t+358 45 113 8883<\/p>\n

Juho Lepp\u00e4m\u00e4ki on Atostekin laatup\u00e4\u00e4llikk\u00f6. H\u00e4n on aloittanut Atostekissa kes\u00e4teekkarina kauan aikaa sitten ja ty\u00f6skennellyt l\u00e4\u00e4kinn\u00e4llisen laitteen ohjelmistokehitysprojektien ja terveydenhuollon ohjelmistojen parissa koko uransa. Nyky\u00e4\u00e4n h\u00e4n tekee laadunhallinnan lis\u00e4ksi ty\u00f6t\u00e4 my\u00f6s myyntiteht\u00e4vien parissa.<\/p>\n<\/p><\/div>\n

 <\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

L\u00e4\u00e4kinn\u00e4llisen laitteen tai ohjelmiston kehitys on Euroopassa s\u00e4\u00e4delty\u00e4 EU 2017\/745 -regulaation eli MDR-asetuksen my\u00f6t\u00e4. Toisaalta regulaatio ei tuo kovinkaan paljoa lis\u00e4ty\u00f6t\u00e4 ohjelmistojen kehitykseen \u2013 verrattuna siihen, kuinka ohjelmistokehitys kuuluisi muutenkin tehd\u00e4. Kuinka regulaatiosta voidaan ottaa kaikki hy\u00f6ty irti niin, ettei se tunnu taakalta? Helpoin tapa t\u00e4ytt\u00e4\u00e4 MDR-asetuksen (Medical Device Regulation) vaatimukset ohjelmistokehitykselle on hy\u00f6dynt\u00e4\u00e4 ISO…<\/p>\n","protected":false},"author":24,"featured_media":11575,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false},"categories":[104],"tags":[445,448,450,210,449,261,444,447,446],"_links":{"self":[{"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/posts\/11562"}],"collection":[{"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/comments?post=11562"}],"version-history":[{"count":24,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/posts\/11562\/revisions"}],"predecessor-version":[{"id":11786,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/posts\/11562\/revisions\/11786"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/media\/11575"}],"wp:attachment":[{"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/media?parent=11562"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/categories?post=11562"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atostek.com\/wp-json\/wp\/v2\/tags?post=11562"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}