Ohjelmistoarkkitehtuurit Harjoitustyö 2014 1. Johdanto Harjoitustyössä suunnitellaan sairauksien ennustamiseen käytettävä ohjelmistokokonaisuus. Jokainen ryhmä suunnittelee arkkitehtuurin ja lisäksi jokaisella ryhmällä on yhteistyöryhmä, joka suorittaa arkkitehtuurin arvioinnin. Ryhmät toimivat itsenäisesti, mutta kommunikoivat tarpeen vaatiessa keskenään arviointiin liittyvissä asioissa. Harjoitustyössä suunnitellaan ohjelmistoarkkitehtuuri riittävän tarkalla tasolla. Eli toisin sanoen: Dokumentoikaa mielestänne oleellisimmat asiat ohjelmistosta. Perustelkaa miksi valitsitte juuri ne kohdat, jotka valitsitte. Huomatkaa, että dokumentin rakenne on yksi arvosteluperuste. Älkää kopioiko suoraan vanhaa harjoitustyödokumentin pohjaa, vaan miettikää mitkä ovat olennaiset suunnitteluratkaisut ja miksi olette valinneet ne. Asiakaspään ja palvelimen/palvelimien rajapinnat tulee suunnitella sillä tasolla, että voisitte tarjota niiden toteutuksen alihankkijalle (tai kuvitella koodaavanne itsenäisesti kyseisen osan ohjelmasta) Suunnittelun lisäksi harjoitustyön tavoitteena on tutustua arkkitehtuurien arviointiin käytännössä. Arviointiin käytetään ATAM- ja DCAR-menetelmiä, siten että ryhmä tulee arvioiduksi ATAM:lla ja arvioivat DCAR:lla tai toisinpäin. Näin kukin ryhmä ja heidän yhteistyöryhmänsä näkevät molemmat menetelmät käytännössä. Tarkoitus on, että arviointisessiossa arvioidaan mahdollisimman valmis arkkitehtuuri, mutta toisaalta arvioinnin jälkeen arkkitehtuuria on vielä mahdollista parantaa ATAM/DCAR-sessiossa löytyneiden riskien ja puutteiden perusteella. Tätä voikin ajatella iteratiivisena prosessina parhaan mahdollisen lopputuloksen saamiseksi. Kurssin puolelta tulee muutamia tarkennuksia/lisävaatimuksia järjestelmälle ennen arkkitehtuurien arviointeja. Näitä kannattaa hyödyntää ATAM-arviointien skenaarioita mietittäessä. 2. Aikataulua ja työvaiheita Olkaa yhteydessä yhteistyöryhmäänne (TTY:llä ryhmien tiedot löytyvät IDLE:stä) jo harjoitustyön alkuvaiheessa. Jos kommunikoinnin kanssa on ongelmia, ottakaa yhteyttä omaan assariinne. 1
Harjoitustyön tekeminen koostuu kahdesta päävaiheesta: 2.1. Suunnittelu 1. Välipalautus 2. Arvioitavan version palautus 3. Korjatun arkkitehtuurisuunnitelman palautus assarille + miten ATAM/DCAR -löydöksiin on reagoitu 2.2. Arkkitehtuurin arviointi 1. Arviointitilaisuuteen valmistautuminen, arkkitehtuuriesityksen valmistelu jne. 2. Varsinainen arviointitilaisuus, jossa molemmat ryhmät ovat läsnä 3. Arviointiraportin palautus assarille ja yhteistyöryhmälle 2.3. Aikataulu Välipalautusversion ja välipalautuksen ajanvarauksen deadline 19.02.2014 19.2.-26.3.2014 harjoitustyön välipalautukset Arviointitilaisuudessa esiteltävän materiaalin (=kalvot, arkkitehtuuridokumentaatio) palauttaminen 23.3. mennessä ja arviointitilaisuuden ajanvarauksen deadline 20.03.2014 24.3.-4.4.2014 Arviointisessiot 21.4. Arviointidokumenttien palautus (myös yhteistyöryhmälle) 8.5. Arkkitehtuuriarvioinnin perusteella muunnellun/kommentoidun suunnitteludokumentin palautus (katso myös kohta 6.2) Annetut päivämäärät ovat viimeisiä mahdollisia päiviä, palautuksen saa ja kannattaa tehdä ennen viimeistä päivää. 2.4. Arviointitilaisuuteen valmistautuminen Tee menetelmän esittelykalvot (kts. kalvopohjat kurssin kotisivuilta). Tutustu menetelmän eri vaiheisiin mitä tehdään missäkin vaiheessa. Varmista, että ryhmälläsi on käytettävissä tietokone arviointitilaisuudessa. Jos ryhmällä ei ole kannettavaa tietokonetta, niin kysy assarilta ETUKÄTEEN lainaläppäriä. Varmista myös läppärin toiminta videotykillä, esim. Applen VGA-adapteri, läppärin laturi jne. on mukana. Tarvittavat dokumenttipohjat tulee ottaa mukaan läppärillä ja niiden käyttöön on syytä tutustua etukäteen, jotta tilaisuus sujuu mahdollisimman sujuvasti, eikä aika kulu tietoteknisten ongelmien selvittelyyn. Sopikaa arvioinnin suorittavan ryhmän roolitus ennen tilaisuutta: kuka on kirjuri, kuka puheenjohtaja, kyseenalaistaja, prosessin tarkkailija, jne. Arvioitava ryhmä sopii kuka edustaa business näkemystä ja kuka esittää pääarkkitehtia. Lisäksi DCAR menetelmässä tulee edellä mainittujen roolien lisäksi valita forcejen kerääjä. 2
DCAR:ssa arviointiryhmän on hyvä varautua siihen, että arkkitehtuurin tehnyt ryhmä saattaa tarvita läppäriä lainaksi. Tässä on hyvä myös neuvotella arvioitavan ryhmän kanssa, josko he voisivat ottaa myös omia tietokoneitaan mukaan. 2.5. Arviointitilaisuus Arviointitilaisuus etenee menetelmän vaiheiden mukaisesti. Tutustukaa niihin etukäteen. Molemmissa tilaisuus alkaa menetelmän lyhyellä esittelyllä. Tämän esityksen pitää arvioiva ryhmä Seuraavaksi molemmissa menetelmissä on business- ja arkkitehtuuriesitykset. Harjoitustyössä nämä esitykset on yhdistetty yhdeksi esitykseksi, joka sisältävät molemmat asiat. Tämän esityksen pitää arkkitehtuurin suunnitellut ryhmä. Seuraavat vaiheet riippuvat menetelmästä: ATAM ATAMissa arvioiva ryhmä johtaa tilaisuutta ja kyselee tärkeät laatuominaisuudet. Tämän hoitaa puheenjohtaja, kirjuri kirjaa tiedot ylös. Puheenjohtaja johtaa myös skenaarioiden keräämistä laatupuuhun, esimerkiksi joko kyselemällä tai käyttämällä jotain ideointimenetelmää. Skenaariot priorisoidaan H/M/L asteikolla. Arkkitehti päättää skenaarion vaikeuden arkkitehtuurin kannalta. Domain /business -asiantuntija tärkeyden liiketoiminnan kannalta (arvioitavasta ryhmästä). Analyysivaiheessa kyseenalaistaja koittaa tuomita arkkitehtuurin vääränä ja arkkitehti puolustautuu (arvioinnin perusperiaate: arkkitehti on syyllinen kunnes toisin todistaa ). tämä keskustelu pitää kuitenkin käydä skenaarion tarjoamassa kontekstissa kuitenkin, jotta kirjuri pystyy kirjaamaan huomiot ylös. DCAR DCARssa esitysten aikana kaikki arvioijat keräävät päätöksiä ja forceja (huom. esim. Google Docs voi helpottaa näiden keräämistä). Yksi henkilö yhdistää listat (tarvittaessa). Tämä forcejen kerääjä ottaa listan itselleen täydennettäväksi arvioinnin myöhemmissä vaiheissa. Päätökset priorisoidaan kaksivaiheisesti. Ensin jokainen arkkitehtuurin tehneen ryhmän jäsen valitsee n. 5 päätöstä seuraavalle kierrokselle. Toisella kierroksella jokaisella arkkitehtiryhmän jäsenellä on käytössä 100 pistettä, jotka hän voi jakaa haluamallaan tavalla toiselle kierrokselle mukaan otetuille päätöksille. Pisteitä annetaan yleensä päätöksille, jotka vaikuttavat epäilyttäviltä tai vaativat arviointia osallistujan mielestä. Muistakaa, että arviointiryhmä on paikalla auttamassa teitä tekemään parempaa harjoitustyötä! Jokainen arkkitehtiryhmän jäsen dokumentoi noin 2-3 päätöstä käyttäen dokumenttipohjaa. Kirjuri kerää päätökset ja niitä ruvetaan käymään lävitse priorisointijärjestyksessä. Dokumentoija esittelee päätöksen läsnäolijoille. Analyysi vaiheessa arviointiryhmä esittää kysymyksiä ja yrittää löytää heikkouksia päätöksestä. Alussa kerättyjä forceja käytetään kysymysten esittämiseen. Esim. Sanoitte, että suorituskyky on tärkeää. Eikös tämä päätös heikennä sitä, koska. 3
Kirjuri täydentää päätösten kuvaukset sitä mukaan kun analyysiä käydään lävitse. Päätöksen plussat ja miinukset, päätöksen kuvaus, mahdolliset esille tulevat vaihtoehtoiset ratkaisut, jne. Lopuksi arkkitehtuuriryhmä ilmaisee mielipiteensä päätöksen kelvollisuudesta peukkuäänestyksellä. Kirjuri kirjaa äänestystuloksen ylös. Assarin rooli: valvoa tilaisuutta :). Tarvittaessa neuvoa ja kyseenalaistaa, mutta ei kuitenkaan olla puheenjohtaja. 2.6. Arviointitilaisuuden arvosteluperusteet Tilaisuus etenee arviointiryhmän puheenjohtajan toimesta (ei assarin toimesta) Kyseenalaistaminen: Arviointiryhmä oikeasti kyseenalaistaa ratkaisuja, eikä vain hyväksy, että hyvältä näyttää. Tarkoitus on auttaa arvioitavaa ryhmää löytämään ongelmia. Arkkitehtuuriryhmän valmius vastata kysymyksiin ja perustella päätöksiään. Hiljaisuus ei ole tapa vastata. Tilaisuuteen valmistautuminen: esitykset kunnossa, läppärit mukana, kaikki ajoissa paikalla, jne. Koko ryhmä osallistuu arviointiin eikä homma ole yhden jäsenen sankaritekojen varassa. 2.7. Yleiset vaatimukset Käyttäkää vapaavalintaista pohjaa, mutta dokumentista on löydyttävä sisällysluettelo, jonkinlaisia kappale/lukujako ja sivunumerot. Saatte itse päättää dokumenttinne sisällön. Esimerkkejä arkkitehtuuridokumenteista (tai dokumenttipohjista) on esitetty kurssin aikana. Tarkistakaa, että sivunumerointi löytyy ja toimii. Kiinnittäkää erityistä huomioita kuviin ja kaavioihin sekä siihen, että ne on tekstissä selitetty. Dokumentoikaa järjestelmän tärkeimmät rajapinnat riittävän yksityiskohtaisesti. Ennakoikaa ja sopikaa yhteistyöryhmän kanssa arviointiajasta riittävän ajoissa - parhaat ajat menevät ensimmäisenä. 3. Harjoitustyöaihe: DeathPredictor 2.0 Harjoitustyön aiheena on erilaisten sairauksien ennustamisen, diagnosoinnin ja hoidon apuna käytettävä työkalu. Lääkärit sun muut asiantuntijat voivat käyttää työkalua päätöksenteon apuna sairauksien hoidossa ja ennustamisessa. Erilaisten näytteiden, testien ja kuvien avulla sairauksia voidaan ennustella jo ennen kuin niiden todelliset oireet ilmaantuvat tai sairaus näkyy selkeästi yksittäisissä testeissä. Taustatarinana olette pistäneet (työ)kaveriporukalla pystyyn yrityksen. Tällä hetkellä teiltä löytyy suoraan paikalliselta koneelta ajettava Windows.NET-ympäristöön toteutettu lääketieteellisten analyysien tarkastelu- ja tietojensyöttöohjelmisto. Teillä on jo kohtuullisen kattava kirjasto testitapauksia, joten perustiedot riittävän luotettavaan ennustamiseen ja diagnosointiin löytyvät valmiina. Tällä hetkellä kaikki data on lokaalisti sovelluksessa, ei erillisessä tietokannassa. Porukastanne löytyy eteviä signaalin- ja kuvankäsittelyn erikoisosaajia, jotka ovat kovia vääntämään skriptejä ja Matlab-tyyppistä koodia. Pääosa analysointityökaluista on toteutettu omina palikoinaan, joita ajetaan omina erillisinä skripteinä/ohjelmakomponentteina (toteutukset esim. c-kielellä tai 4
MatLab-koodina). Näitä käynnistellään ohjelmasta pala kerrallaan ohjaten suoritusta komponentilta toiselle. KUVA 1: JÄRJESTELMÄN PERUSRAKENNE Joukko enkelisijoittajia ja Tekes ovat vakuuttuneet tuotteestanne ja analyysipuolen laskennat on testattu toimiviksi. Tavoitteenanne on tuotteistaa ohjelmanne (DeathPredictor) ja eriyttää tietojen käsittely ja analysointi omiksi erillisiksi osiksi. Liiketoimintaideana on myydä palvelua sairaaloille/hoitolaitoksille ja laskuttaa näitä esimerkiksi ohjemistolisenssi-, kuukausi-, käyttäjä-, analyysi- tai resurssipohjaisesti. Lisähyötynä jokainen käyttökerta kerryttää teille lisää uusia tietoja. Myöhemmin tätä laajaa kirjastoa tiedoista voidaan käyttää laajemmin hyväksi uusien tauti- tai hoitoennusteiden lisäämisessä (tai vaikka kokonaan uusien asiakasryhmien muodossa). Havainnekuva ohjelman perusrakenteesta on esitetty kuvassa 1. Sairaalan päässä on oma erillinen ohjelmistonsa, jolla potilaiden tietoja voi käsitellä ja syöttää sekä tarkastella tuloksia. Tiedot lähetetään teidän palvelimelle (anonymisoituna) ja laskennat ja analyysi suoritetaan palvelimilla. Kun tulokset ovat valmiita, niitä voi tarkastella ja vertailla esimerkiksi samankaltaisia tuloksia saaneiden ryhmään. Potilastiedot sisältävät esimerkiksi aivo-, sisäelin- jne. kuvia ja erilaisten testien tuloksia. Testit voivat olla esimerkiksi geenitestejä, psykologisten kokeiden tuloksia (kuten muistitestit) tai konkreettisempia, kuten veritestien löydökset (biomarkerit). Potilaan tiedot paketoidaan yhteen ja lähetetään analysoitavaksi palvelimelle, jossa laskentatehoa vaativat analyysit, kuten kuva-analyysi, suoritetaan. Kun laskenta on valmis, pääteohjelma sairaalan päässä saa ilmoituksen ja tulostiedot tarjotaan käyttäjälle. Lisäksi käyttäjä voi vertailla (anonymisoituun) löytyvään tietoon (tietojoukon tapauksessa keskiarvot, hajonnat jne.) Esimerkkejä suoritettavasta vertailuista on esimerkiksi samat perinnölliset piirteet, ikä, samankaltaiset testitulokset jne. 5
4. Vaatimuksia Ohjelmalle on asetettu seuraavia perusvaatimuksia: Kuva-analyysi ei saa hidastaa valmiiksi laskettujen tietojen hakua Kaikki tieto liikkuu verkossa salattuna, tieto tallennetaan palvelimille salattuna Laskutusta varten mahdollisuus seurata ohjelman käyttöä (esim. pyydetyt analyysit) Käyttäjien hallinta, oikeuksien määrittely ja rajaaminen, käytön seuranta. Pääsy tietoihin sairaalakohtaisesti, mahdollisuus eri palvelutasoihin (tarkemmat analyysit, enemmän vertailutietoa jne.) Palvelimille talletettu tieto on anonymisoitu. Sairaalan päässä sairaalan omien potilaiden tietojen tarkastelu onnistuu myös normaalisti (ei-anonyyminä tietona). Mahdollisuus vaihtaa pääteohjelmia ja tarjota eri näkymiä/oikeuksia kerättyyn tietoon. Järjestelmän tulee olla helposti mukautettavissa uudelle mittaustiedolle. Erityisesti tietomalli on olennainen. (käyttöliittymä ja mukautuvuus?) Personoitavuus, käyttöliittymä personoitavissa asiakaskohtaisesti (käyttäjätyyppi, sairaala ) Mahdollisuus liittää järjestelmä sairaalan/asiakkaan tietojärjestelmiin (tiedon siirto/kopionti) 4.1 Uusia vaatimuksia Firman markkinointipäällikkö ja teknologialiideri ovat touhuilleet ahkerasti ja ilmi on tullut seuraavia asioita, joihin pitäisi kiinnittää erityistä huomioita: Sairaalat ovat tallennelleet kuvia jne. omiin järjestelmiinsä ja meidän järjestelmän pitäisi pystyä kommunikoimaan niiden kanssa. Termit kuten PACS ja DICOM ovat tulleet aina esiin näistä jutellessa. Eli meidän järjestelmän pitäisi pystyä hakemaan tietoja sairaalan PACSista ja lähetellä se sitten eteenpäin anonymisoituna jne. analyysiä varten. o Pentti visioi, että tällä liitynnällä voisi imaista yöaikaan isommankin kasan kuvia meidän palvelimelle, jos vaan sairaalan ja potilaiden kanssa on sopparit kunnossa. (muitakin kuin meidän palvelulla erikseen analysoitavia kuvia) PatientKeeper niminen firma haluaisi tehdä ipad-version käyttöliittymästä, siis meidän oman dedikoidun käyttöliittymän ja/tai weppikäyttöliittymän rinnalle. Miten tämä onnistuisi? Järjestelmä haluttaisiin toimittaa ameriikan markkinoille, vaaditaan 37bittistä Caesarsalausta josta löytyy vielä valmis NSA-aukko. Esimerkiksi HTTP-sisältö tai IPSEC-tyylisesti tietoliikenteen salaaminen tällä. o koko tietokannan (osan) salaaminen tiettyjä asiakkaita varten asiakkaiden omalla salaustekniikalla (esim. 37-bittinen Caeasar-salaus), käytetään asiakkaan omaa salausteknologiaa Lainsäädäntö ja käyttäjien seuranta, audit/seurantalogit jne. Salkkareista jne. tuttu Ninja- Lotta on raskaana ja potilastietoja on vuotanut Seiskalle jo ennen kuin Ninja-Lotta on ehtinyt asioista itse kertoa. Syyllinen on löydyttävä. Muun muassa Kälviän reumaparantola ja Turun kauppatieteellinen sairaala haluavat käyttää autentikointiin omia käyttäjätietojaan. Heillä on tarjolla oma autentikointipalvelimensa. (Esimerkki sovellusmallista: Shibbotleth ja Moodle, IDLE:n autentikointi jne.) Skaalautuvuus ja luonnon ystävät: Yleisesti isoon sairaalaan toimitus, pyyntöjen määrä vaihtelee vuorokauden eri aikoina. Päivällä paljon, yöllä ei uusia pyyntöjä. Yliopistollinen Luonto- ja homeopatian keskussairaala vaatii, että laskentapalvelimia/tehoa pitää skaalata fyysisesti, haluavat, että laitteita sammutetaan ja käynnistellään tarpeen mukaan. Skaalautuvuus ja priorisointi: mm. Jorvin potilassairaala haluaa, analyysien priorisointia: osa pyynnöistä halutaan analysoitavaksi heti, osassa riittää että tulokset ovat valmiina 6
seuraavana päivänä. Kiireelliset pyynnöt (VIP-asiakkaat, kriittisyys): arvio valmistumisajasta (esim. valmis 10min kuluttua) Videokuvan analysointi: porukkanne signaalinkäpistelijäguru on kehitellyt uusia algoritmeja esimerkiksi suolitähystysten, ultraäänipätkien jne. analysointiin. Näitä olisi hyvä saada mukaan järjestelmään, jotta mukaan saadaan paljon uusia tauteja, joiden analysoinnin apuna ohjelmistoa voidaan käyttää (lisää massia). Jotain vinkkejä tietosuojavaatimuksiin on tarjolla esim. luentosessiolla 6.2. ja 27.2. (katso materiaali). Järjestelmän asiakkaat (sairaalat jne.) hoitavat potilaan tietojen luovuttamiseen liittyvien suostumukset ja muun perusbyrokratian. Teidän hommaksi jää tietoturvapuoli järjestelmän puolella. 5. Vaatimuksia palautuksille Välipalautus Seuraavat asiat pitää dokumentoida välipalautukseen palautettavassa dokumentissa: Arkkitehtuuridokumentin yleinen rakenne (sisällysluettelo) Yleinen kuvaus järjestelmästä ja sen tärkeimmistä vaatimuksista Korkean tason arkkitehtuuri (4+1 näkymät) keskeiset suunnittelumallit, arkkitehtuurityylit Arviointidokumentti Päivitetty versio dokumentaatiosta välinäytössä saadun palautteen ja omien mietintöjen perusteella palautetaan arvioinnin suorittavalle ryhmälle sekä omalle assarille. Lopullinen palautus Päivitetty versio dokumentista, jossa on huomioitu sekä välinäytön palaute että arviointitilaisuudessa esiin tulleita asioita. Kertokaa mitä muutoksia arvioinnin perusteella tehtiin dokumenttiin/arkkitehtuuriin (tai jos muutoksia ei tehty, miten arviointiin reagoitiin). ATAMarvioinnissa löytyneiden riskien vakavuus ja kuvaus on löydyttävä dokumentista. DCAR-arvioinnin tapauksessa taasen kerrotaan löytyneiden riskien aiheuttaman korjaustarpeen vaikeus. ATAM / DCAR -arviointidokumentti ATAM/DCAR-tilaisuudessa tuotettu ja sitä varten tehty materiaali (esitykset jne.) ATAM/DCAR-raportti liitteineen (tilaisuudessa tuotettu tavara). 7
Alustavia arviointiperusteita Arvostelussa kiinnitetään huomiota seuraaviin asioihin: Järjestelmän arkkitehtuuri, arkkitehtuurityylit, suunnittelumallit jne. Ratkaisujen perustelut Laajennettavuus, muokattavuus, ylläpidettävyys Dokumentaation yleinen laatu Arviointidokumentaatio, arviointitilaisuudessa toiminta (irccaamista yms ja nenänkaivuuta vs. kaikki mukana, homma etenee) Harjoitustyö arvostellaan seuraavasti: Välipalautus 0-2 pistettä Suunnittelu 0-8 pistettä (sisältäen arviointitilaisuuteen toimitetun dokumentin sekä lopullisen arviointiin reagoinnin sisältävän dokumentin) ATAM/DCAR arviointitilaisuus ja arviointidokumentti 0-5 pistettä 8