JUHA LÄHTEENMÄKI TERVEYDENHUOLLON SELAINKÄYTTÖISTEN TIETOJÄRJESTELMIEN ARKKITEHTUURISUUNNITTELU DIPLOMITYÖ

Koko: px
Aloita esitys sivulta:

Download "JUHA LÄHTEENMÄKI TERVEYDENHUOLLON SELAINKÄYTTÖISTEN TIETOJÄRJESTELMIEN ARKKITEHTUURISUUNNITTELU DIPLOMITYÖ"

Transkriptio

1 TAMPEREEN TEKNILLINEN KORKEAKOULU SÄHKÖTEKNIIKAN KOULUTUSOHJELMA JUHA LÄHTEENMÄKI TERVEYDENHUOLLON SELAINKÄYTTÖISTEN TIETOJÄRJESTELMIEN ARKKITEHTUURISUUNNITTELU DIPLOMITYÖ AIHE HYVÄKSYTTY SÄHKÖTEKNIIKAN OSASTONEUVOSTON KOKOUKSESSA TARKASTAJA: LEHTORI JUHA NOUSIAINEN

2 Alkusanat ALKUSANAT Tämä diplomityö on tehty TTKK:n Porin Tietotekniikan yksikössä (TTKK/Tietotekniikka Pori), jossa olen määräaikaisena tutkijana osallistunut ToolsOnLine-projektissa tehtyyn ohjelmiston suunnittelu- ja toteutustyöhön. Pääasiallisena tutkimuskohteena diplomityössäni ovat olleet arkkitehtuurisuunnittelu, arkkitehtuuriratkaisut ja niihin liittyvät tekniikat erityisesti terveydenhuollon ohjelmistokehitystä ja tarpeita silmälläpitäen. Ennen kaikkea haluan kiittää työni tarkastajaa lehtori Juha Nousiaista Ragnar Granit instituutista TTKK:lta hyvistä neuvoista ja kommenteista, jotka ovat auttaneet työn kehittämisessä ja kirjoituksessa monien ongelmatilanteiden yli. Samoin haluan osoittaa erityisen suuret kiitokset professori Pekka Loulalle Porin Tietotekniikan yksiköstä TTKK:lta asiantuntevasta avusta ja myötävaikutuksesta työn suhteen. Lisäksi kiitän kaikkia ToolsOnLine -projektiin osallistuneita henkilöitä, erityisesti projektipäällikkö Mika Huotaria sekä ohjelmistosuunnittelija Risto Suvantoa PhysioTools:sta. Samoin kiitokset TTKK/Tietotekniikka Porin, FD System:n sekä PhysioTools:n koko muulle henkilökunnalle. Yhdessä olette positiivisella suhtautumisellanne ja asiantuntemuksellanne olleet mukana myötävaikuttamassa työn syntymiseen ja siinä tarvittavan tietopääoman keräämiseen. Lopuksi vielä suuret kiitokset kotiväelle kannustuksesta ja kärsivällisyydestä kirjoitus- ja tutkimustyön aikana. Porissa , Juha Lähteenmäki 2

3 Sisällysluettelo SISÄLLYSLUETTELO TIIVISTELMÄ...4 ABSTRACT...5 MERKINNÄT JA LYHENTEET JOHDANTO ARKKITEHTUURISUUNNITTELU TERVEYDENHUOLLON OHJELMISTOKEHITYKSEN OSANA Ohjelmistokehityksen osa-alueet ja vaiheistaminen Arkkitehtuurisuunnittelun tavoitteet ja merkitys ohjelmistokehitykselle Terveydenhuollon tietojärjestelmien erityispiirteet arkkitehtuurisuunnittelun kannalta ARKKITEHTUURIN OSITTAMINEN JA ARKKITEHTUURIRATKAISUT Arkkitehtuurin jako suunnittelun näkökulmasta Asiakas-palvelin-mallin mukaiset sovellusarkkitehtuuri-ratkaisut Komponenttiarkkitehtuuriratkaisut SELAINKÄYTTÖISTEN JÄRJESTELMIEN TEKNOLOGIAT Selainarkkitehtuuri WWW-palvelin ja palvelinteknologiat Yhteyskäytännöt ja Web-sovellusten tilanhallinta Asiakasteknologiat Tietoturvan huomioiminen selainsovelluksissa ARKKITEHTUURISUUNNITTELUN VAIHEET Hajoita ja hallitse -menetelmä Teknisten arkkitehtuuriratkaisujen valinta Esimerkki projektina ToolsOnLine Vaiheistetun arkkitehtuurisuunnittelun ongelmia YHTEENVETO...87 LÄHDELUETTELO

4 Tiivistelmä TIIVISTELMÄ TAMPEREEN TEKNILLINEN KORKEAKOULU (TTKK) Sähkötekniikan osasto, Ragnar Granit instituutti Lähteenmäki Juha, Terveydenhuollon selainkäyttöisten tietojärjestelmien arkkitehtuurisuunnittelu. Diplomityö, 94s Tarkastaja: Juha Nousiainen Joulukuu 2001 Avainsanat: terveydenhuolto, tietojärjestelmä, ohjelmistot, arkkitehtuurisuunnittelu, selain, selaintekniikat. Tietojärjestelmien kehitystyö elää parhaillaan murroskauttaan. Monipuoliset oliolähtöiset teknologiat ja laajat selaimella käytettävät palvelinkeskeiset järjestelmät tarjoavat merkittäviä hyötynäkökohtia verrattuna perinteisiin työasemalähtöisiin sovelluksiin. Uusien teknologioiden ja ratkaisumallien tulo luo kuitenkin myös aivan uusia haasteita ohjelmien kehitykselle. Entistä laajemmat ja monipuolisemmat järjestelmät vaativat myös entistä huolellisempaa ja kokonaisvaltaisempaa rakenteen sekä teknisten ratkaisujen miettimistä eli arkkitehtuurisuunnittelua. Tämän työn tarkoituksena oli kuvata arkkitehtuurisuunnittelua ja selainkäyttöisten järjestelmien teknologioita sovitettuna Suomen terveydenhuollon tarpeisiin. Suunnitteluprosessin avuksi kehitettiin myös yleiskäyttöinen arkkitehtuurisuunnittelun vaiheistusmalli, jota olisi helppo soveltaa työn taustalla olevan ToolsOnline-projektin ja useimpien muidenkin terveydenhuollon tietojärjestelmien arkkitehtuurisuunnittelun yhteydessä. Kehitetyn mallin mukaisesti arkkitehtuurisuunnittelu jaetaan viiteen erilliseen osavaiheeseen. Kukin osavaihe muodostaa järjestelmän arkkitehtuurista oman erillisen kuvauksensa, jota seuraava vaihe yleensä tarkentaa pureutumalla lähemmin yksityiskohtiin. Näin suunnittelun edetessä toisaalta pilkotaan järjestelmää pienempiin palasiin ja toisaalta luodaan pohjaa tarkemmalle suunnittelulle eli ohjataan seuraavien suunnitteluvaiheiden kulkua. Tästä syystä kehitetty malli nimettiinkin hajoita ja hallitse -menetelmäksi. Kokemukset hajoita ja hallitse -menetelmän mukaisesta arkkitehtuurisuunnittelusta olivat ToolsOnLine:n myötä pääosin positiivisia. Vaikka ongelmiakin tuli esille, malliin perustuva ja kontrolloitu arkkitehtuurisuunnittelu oli kuitenkin huomattavasti helpompaa ja nopeampaa kuin perinteinen ad hoc -tyyppinen arkkitehtuurisuunnittelu. 4

5 Abstract ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Ragnar Granit Institute Lähteenmäki, Juha: Development of browser based healthcare information system architectures Masters Thesis, 94p. Advisor: Juha Nousiainen December 2001 Keywords: healthcare, information system, software, architecture development, browser, browser-based software technologies. The development of information systems is currently under a rapid change. Versatile object-oriented technologies and browser-based Thin-Client systems offer many advantages over traditional workstation dependent Fat-Client solutions. However they also require more broadly-based structure and technique analysis i.e. more carefully done software architectural design. The purpose of this study was to describe the design cycle of browserbased software architecture and the architectural solutions, adapted for Finnish healthcare needs. To make the architectural design easier a generic phase model was also developed. The goal was that the model would be easy to apply especially to healthcare software development. According to the developed model the architectural design cycle was divided into five separate phases. Each of these phases usually generates its own separate description of the architecture as a whole, which is then further specified in detail in the next phase. In this way each phase divides system into smaller pieces but also controls the next phase by creating base for it. For this reason the model was named as hajoita ja hallitse (divide and control). Hajoita ja hallitse -phase model and the selected technical solution were applied and tested to one typical healthcare specific software project, ToolsOnLine. The results were mainly positive. Even though there were some restrictions and lacks in the developed model, the model-based and controllable software architectural design was easier and faster than the traditional ad hoc design. 5

6 Merkinnät ja lyhenteet MERKINNÄT JA LYHENTEET ADO ADO.NET API ASCX ASP ASPX ja ASP.NET CDA CGI CLR COM ja COM+ CORBA CSS ActiveX Data Objects Uusin.NET:n mukainen versio ADO:sta Aplication Interface.NET:n userkontrollin tiedostotunniste Active Server Pages Uusin.NET arkkitehtuurin mukainen versio ASP:sta Clinical Document Architecture Common Gateway Interface Common Language Runtime Component Object Model Common Object Request Broker Architecture Cascading Style Sheets C# Uusi.NET:n tarjoama ohjelmointikieli (Csharp) DCOM DDCF DICOM DLL DOM EAI EJB EXE Distributed-COM Distributed Document Component Facility Digital Imaging and Communications in Medicine Dynamic Link Library Document Object Model Enterprise Application Integration Enterprise JavaBeans Executable file (suoritettavan tiedoston tunniste) 6

7 Merkinnät ja lyhenteet HL7 Health Level 7 HOST HTML HTTP HTTPS IDL IE IIOP IIS IP ISAPI ISO JDBC JDK JIT MOM MS MSIL MTS OLE OLEDB tai OLE-DB OMA OMG Isäntä sovellus HyperText Markup Language HyperText Transfer Protocol HTTP over Secure Sockets Layer Interface Definition Language Microsoft Internet Explorer WWW-selain Internet Inter-ORB Protocol Internet Information Server Internet Protocol Internet Server API International Organization of Standardization Java Database Connectivity Java Development Kit Just-In-Time Compiler Message Oriented Middleware Microsoft Microsoft Intermediate Language Microsoft Transaction Monitor Object Linking and Embedding Microsoftin universaalia tietovarastojen (DB = Data- Base) käsittelyä varten kehittämä tekniikka Object Management Architecture Object Management Group 7

8 Merkinnät ja lyhenteet OOD ORB PC PDA PDF PVX RPC SOAP SQL TCP/IP TON TTKK UI UML URL VB.NET VPN VS.NET WWW = Web XML.NET Object Oriented Design Object Request Broker Personal Computer Personal Digital Assistant Portable Document Format ProVIREX Remote Procedure Call Single Object Access Protocol Structured Query Language Transmission Control Protocol/Internet Protocol ToolsOnLine (ToolsOnLine projekti ja järjestelmä) Tampereen teknillinen korkeakoulu User Interface Unified Modelling Language Uniform Resource Locator Uusin.NET:n mukainen Visual Basic:n versio (VB7) Virtual Private Network Microsoftin sovelluskehittimen (Visual Studio) uusin versio. World Wide Web Extensible Markup Language Microsoftin uusi sovelluskehysarkkitehtuuri 8

9 Johdanto 1. JOHDANTO Suomalaisen sosiaaliturva ja terveydenhuolto perustuvat pohjoismaiseen hyvinvointiajatteluun [1], jonka ensisijaisena periaatteena on tarjota kansalaisille tasapuolisesti mahdollisimman korkealaatuisia terveydenhuoltopalveluita. Viimeisen vuosikymmenen aikana tämän periaatteen noudattamiselle on kuitenkin tullut uusia haasteita (ks. kuva 1.1). Toisaalta suurten ikäluokkien vanheneminen ja tätä kautta lisääntynyt terveydenhuoltopalvelujen käyttö, toisaalta potilaiden oman aktiivisuuden ja kiinnostuksen lisääntyminen hoitotapahtumaansa kohtaan [2], on kasannut koko terveydenhuollon sektorille muutospaineita. Myös viime lamavuosien seurauksena tehdyt laajat budjettileikkaukset ovat pakottaneet terveydenhuoltoa kehittymään kustannustehokkaampaan suuntaan, eikä perinteinen työvoiman lisäys ole muutenkaan perusteltavissa, onhan terveydenhuolto Suomessa jo ennestään yksi työvoimavaltaisimmista aloista [3]. Kuva 1.1 Suomen terveydenhuollon haasteet lähitulevaisuudessa Ratkaisua uusille vaatimuksille onkin haettu entistä pontevammin tietoteknologian hyödyntämisestä. [24] Sosiaali- ja terveysministeriö asetti työryhmän, jonka tehtävänä oli laatia sosiaali- ja terveysministeriön hallinnonalan tietohallinnon toimintastrategia siten, että uuden tietotekniikan avulla parannetaan sosiaaliturvan saatavuutta, laatua ja tehokkuutta. [1]. Tämän 9

10 Johdanto tietoteknologian hyödyntämisstrategian keskeisiä linjauksia tietojärjestelmien kannalta ovat mm. [1] Kohti tietoyhteiskuntaa kaikille Tietosuojan ja tietoturvan kehittäminen Tietojärjestelmien integraation ja yhteensopivuuden parantaminen Yhdistävänä tekijänä linjauksissa on tietoverkkojen tehokas hyödyntäminen. Internetin käytön räjähdysmäinen laajeneminen ja selainkäyttöiset globaalit järjestelmät ovatkin viimeisten viiden vuoden aikana luoneet uusia valtavia mahdollisuuksia myös terveydenhuollon tietojärjestelmien kehitystyölle. Samalla ohjelmistojen huolellisen etukäteissuunnittelun merkitys on kuitenkin kasvanut. Mutkikkaammat ja avoimet järjestelmät vaativat toteutusta varten paloittelua useampiin osakokonaisuuksiin ja edelleen näiden välisten liityntä- sekä toteutustekniikoiden miettimistä [4]. Tätä prosessia sanotaan tietojärjestelmien arkkitehtuurisuunnitteluksi [5]. Se hahmottaa ohjelmiston rakennuspalikat (komponentit, moduulit jne.) ja tekniikat, joilla nuo palaset liitetään yhteen toimivaksi järjestelmäksi. Hyvin suunniteltu ja oikein valittu arkkitehtuuri näkyy myös järjestelmän valmistuttua helpon ylläpidon, pitkän elinkaaren ja jatkokehityksen mutkattomuuden kautta. Perustellusti voidaankin sanoa, että arkkitehtuurisuunnittelu on ohjelmistokehityksen tärkeimpiä, mutta samalla vaikeimpia osa-alueita, jolla on merkittävä vaikutus koko järjestelmän tulevaisuudelle. Tämän työn tavoitteena oli kartoittaa terveydenhuollon selainkäyttöisten tietojärjestelmien tekniikoita, arkkitehtuuriratkaisuja ja ennen kaikkea arkkitehtuurisuunnittelua kokonaisvaltaisena prosessina. Arkkitehtuurisuunnittelun avuksi pyrittiin myös kehittämään yksinkertainen vaiheistusmalli, joka selkiyttäisi kuvaa suunnitteluprosessin kulusta. Edellä mainittuihin tavoitteisiin liittyi tärkeänä osana aihepiirin tarkastelu terveydenhuollon ja nimenomaan Suomen terveydenhuollon tietojärjestelmäkehityksen kannalta. Tämä näkyy mm. kehitetyn vaiheistusmallin vaiheiden, terveydenhuollon sovellusalueen tarpeiden ja erityispiirteiden kuvauksen yhteydessä. Toisaalta tekniikoiden esittelyssä terveydenhuollon sovellusalue pyrittiin huomioimaan paitsi alueen erityisratkaisujen kautta, myös käsittelemällä ensisijassa vain sellaisia tekniikoita, jotka parhaiten soveltuvat juuri Suomen terveydenhuollon tietojärjestelmätarpeisiin. Työn tavoitteiden taustalla on terveydenhuollon tutkimus- ja tietojärjestelmähanke ToolsOnLine eli TON, jossa kirjoittaja on ollut mukana TTKK:n Porin Tietotekniikkaosaston tutkijana sovellusarkkitehtuurin- 10

11 Johdanto ja teknisten ratkaisujen suunnittelussa. Työn aihepiirit on pyritty valitsemaan juuri siten, että niitä voitaisiin hyödyntää mahdollisimman paljon TON:n yhteydessä tehtävässä arkkitehtuurisuunnittelutyössä. Erityisen keskeinen osuus TON:lla on ollut kehitetyn vaiheistusmallin koostamisessa, jossa yhtenä tavoitteena oli juuri mallin soveltuminen ainakin tärkeimmiltä osiltaan TON:n käyttöön. Vastaavasti TON on puolestaan tarjonnut arvokasta kokemusta kehitetyn mallin soveltamisesta ja toiminut työssä tavallaan esimerkkiprojektina, joka on tuonut myös käytännön syvyyttä muuten melko teoreettiselle selvitykselle. Työn sisältö Luvussa 2 on esitelty arkkitehtuurisuunnittelu ja sen nivoutuminen ohjelmistokehityksen osaksi. Samalla on myös tarkasteltu mitä erityispiirteitä terveydenhuollon tietojärjestelmiin ja terveydenhuollon ohjelmistokehitykseen liittyy arkkitehtuurisuunnittelun kannalta. Luvussa 3 on paneuduttu arkkitehtuuriratkaisuihin ja arkkitehtuurin osittamiseen. Tässä yhteydessä on käsitelty mm. asiakas-palvelinmalliin liittyvät sovellusarkkitehtuuriratkaisut, middleware ja komponenttiarkkitehtuurit sekä -teknologiat. Luku 4 on omistettu selainkäyttöisten järjestelmien teknologioiden läpikäynnille. Tekniikoista esitellään mm. tavallisimmat selainkäyttöisten järjestelmien palvelin- ja asiakasteknologiat, tilanhallinnan menetelmät sekä asiakkaan ja palvelimen väliset yhteyskäytännöt. Myös selainkäyttöisten järjestelmien kannalta tärkeää tietoturvaa on käsitelty olennaisimmilta osiltaan. Luvussa 5 kuvataan varsinainen arkkitehtuurisuunnitteluprosessi ja sen vaiheet. Tätä silmälläpitäen selvitetään ensin arkkitehtuurisuunnittelua varten työssä kehitetty vaiheistusmalli (hajoita ja hallitse) ja käydään läpi tekniikoiden valintaprosessia ja valinnan perusteita. Tämän jälkeen esitellään ToolsOnLine:n liittynyttä arkkitehtuurisuunnitelmaa esimerkkinä vaiheistusmallin soveltamisesta. Lopuksi luvussa 5 käsitellään vielä arkkitehtuurisuunnitteluun liittyviä ongelmia ja niiden mahdollisia ratkaisumalleja. 11

12 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana 2. ARKKITEHTUURISUUNNITTELU TERVEYDENHUOLLON OHJELMISTOKEHITYKSEN OSANA Ohjelmiston tie kehitysideasta käyttäjälle on usein mutkikas ja pitkä. Monenlaisia vaiheita tarvitaan jo ennen kuin itse ohjelmaa voidaan edes varsinaisesti alkaa pystyttämään. Toisaalta kehitystyö jatkuu yleensä vielä pitkään senkin jälkeen, kun käyttäjälle on toimitettu periaatteessa valmis ohjelma. Jokainen tietokonetta vähänkin käyttänyt lienee tutustunut erilaisiin service pack tyyppisiin päivityksiin, jotka ovat osa tätä ohjelmien valmistumisen jälkeistä kehitystyötä. Yhdessä ohjelmiston rakennuksen eri vaiheita sanotaan ohjelmistokehitykseksi. Tässä luvussa on tarkoitus käsitellä miten arkkitehtuurisuunnittelu liittyy osaksi ohjelmistokehitystä ja mitä erityispiirteitä terveydenhuollon tietojärjestelmiin ja niiden arkkitehtuurisuunnitteluun liittyy. 2.1 Ohjelmistokehityksen osa-alueet ja vaiheistaminen Ohjelmistokehitykseen kuuluu olennaisena osana vaiheistaminen ja vaiheiden yhdistäminen järkeväksi kokonaisuudeksi jonkin vaiheistusmallin kautta. Kuvassa 2.1 on esitettynä ohjelmistokehityksen tärkeimpiä vaiheita vesiputousmalli-tyyppisenä vaiheistuksena: Määrittely Määrittelyvaiheessa (josta voidaan omaksi vaiheekseen vielä erottaa esitutkimus) pyritään luomaan selkeä kuva siitä, mitä toteutettavalta järjestelmältä halutaan. Vaiheen alkuosalle ovatkin tyypillisiä erilaiset käytettävyysselvitykset [18], joiden avulla selvitetään asiakkaan mielestä tärkeitä kehitysnäkökohtia nykyisestä tai muista vastaavista järjestelmistä. Määrittelyvaiheen olennaisin osa on kuitenkin muuntaa asiakkaiden esittämät, usein ristiriitaiset, epämääräiset ja laajat toivomukset eli asiakasvaatimukset ohjelmiston kannalta täsmällisiksi ja järkeviksi toiminnallisuuden kuvauksiksi. [17] [19] [20] Paitsi suoranaisten asiakasvaatimusten priorisointia ja muokkausta määrittelyvaiheeseen liittyy myös paljon muuta selvitys- ja tutkimustyötä kuten järjestelmään liittyvien lakien, asetusten ja standardien selvitys [22][21]. Tämä on olennaista nimenomaan terveydenhuollon ohjelmistoille, joiden toiminta saattaa joissain tilanteissa olla tarkastikin viranomaisten säätelemää [23]. Oliopohjaisessa ohjelmistokehityksessä on tärkeää myös analysoida järjestelmän tietosisältöä ja luokkarakennetta alustavasti jo määrittelyvaiheessa [28], jotta arkkitehtuu- 12

13 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana risuunnittelussa alkuun pääseminen olisi helpompaa ja toteutuksen kannalta ongelmalliset vaatimukset saataisiin karsittua heti projektin alkumetreillä. Kuva 2.1 Ohjelmistokehityksen vaiheet ja kussakin vaiheessa mahdollisesti syntyviä dokumentteja. Vaiheita kuvaavien laatikoiden osittainen päällekkäisyys kuvaa tilannetta käytännön projekteissa. Joskus saatetaan myös joutua palaamaan projektin vaiheissa taaksepäin esim., jos vaatimukset muuttuvat suunnittelun aikana. Suunnittelu Määrittelyvaiheen luonnolliseksi jatkeeksi liittyy yleensä suunnitteluvaihe. Kun määrittely kertoo, miten järjestelmän pitäisi toimia, niin suunnittelu kertoo, millä tavalla tuo toiminnallisuus ja järjestelmä yleensäkin pitäisi toteuttaa [17]. Tavoitteena on päästä mahdollisimman yksinkertaiseen, ymmärrettävään mutta kuitenkin toimivaan ratkaisuun. Suunnittelun tärkeänä osana on arkkitehtuurisuunnittelu, jonka ympärille koko muu suunnittelu ja järjestelmä yleensä rakentuvat. Arkkitehtuurisuunnittelua tarkastelemme yksityiskohtaisesti myöhemmin tässä työssä. 13

14 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Ohjelmiston arkkitehtuurin miettimisen lisäksi suunnitteluun liittyy järjestelmän yksityiskohtaiset moduulien ja niiden rajapintojen kuvaukset (moduulisuunnittelu). Kustakin moduulista ja komponentista kuvataan riittävän tarkasti sen tarjoamat palvelut, niihin liittyvä toiminnallisuus, poikkeukset sekä muu virhetilanteiden hallinta [28]. Suunnittelun tuloksena syntyy ainakin tekninen määrittely (suunnittelu-dokumentti), johon toisinaan liitetään arkkitehtuurisuunnitelman lisäksi moduulikuvausdokumentit. Komponenttiperustaisessa ohjelmistokehityksessä sen sijaan kunkin komponentin tarjoamat palvelut ja rajapintaluokat kuvaava dokumentti on yleensä omana erillisenä dokumenttinaan. Näin mahdollistetaan se, että komponentin dokumentaatiota voidaan tulevaisuudessa käyttää myös erillään muusta projektin dokumentaatiosta. Toteutus Varsinainen toteutusvaihe alkaa suunnittelun jälkeen. Jo suunnitteluvaiheessa saattaa kuitenkin olla hyödyllistä protoilla joidenkin teknisten ratkaisujen toimivuutta varsinkin, jos sovellettavana on uusia tai tekijöille tuntemattomia tekniikoita. Samalla saadaan suunnitteludokumenttiin arvokkaita esimerkkejä, jotka kertovat yleensä toteutusvaiheessa enemmän kuin tarkkakin sanallinen kuvaus. Toisaalta näitä syntyneitä protoiluversioita ei tulisi käyttää sellaisenaan varsinaisessa toteutusprojektissa, koska niiden rakennetta ei ole loppuun asti tehokkuuden tai muidenkaan teknisten seikkojen osalta mietitty [29]. Toteutusvaiheen onnistumisen edellytyksenä on yleensä huolellisesti ja oikein tehty (arkkitehtuuri)suunnittelu. Järkevä moduuli / komponentti -jako mahdollistaa toteutuksen hajautuksen sopiviin ja toisistaan riippumattomiin palasiin. Toisaalta suunnittelun yhteydessä oikein valitut tekniset ratkaisut helpottavat huomattavasti koodaustyötä ja valmiiden palikoiden yhteensovitusta. Testaus Testausvaihe kuuluu oikeastaan osittain jo toteutusvaiheen yhteyteen. Sen ensisijaisena tarkoituksena on löytää mahdollisimman suuri osa toteutusvaiheessa tehdyistä virheistä [30]. Kukin ohjelmoija testaa oman moduulinsa jo ennen sen virallista valmistumista yleensä itse rakentamallaan testipenkillä. Tätä vaihetta sanotaan moduulitestaukseksi [17]. Lisäksi testaukseen kuuluvat yhteentoimivuutta testaava integrointitestaus ja koko järjestelmälle lopussa suoritettava järjestelmätestaus. 14

15 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Ylläpito Järjestelmätestauksen jälkeen ohjelmisto on periaatteessa valmis markkinoille. Tulee kuitenkin muistaa, että ohjelmiston kehitys ei yleensä koskaan lopu markkinoille tuloon. Tästä alkaa uusien versioiden kehittäminen, mutta myös usein uuvuttava ylläpitovaihe [17][31], joka on erityisen tärkeä terveydenhuollon tietojärjestelmille ominaisilla pienillä markkinoilla. Myös ylläpitovaiheeseen voi vaikuttaa hyvin tehdyllä suunnittelulla ja hyvin suunniteltu arkkitehtuuri näkyy erityisesti sekä ylläpitovaiheen että jatkokehityksen helppoutena ja pidentää huomattavasti järjestelmän elinkaarta. 2.2 Arkkitehtuurisuunnittelun tavoitteet ja merkitys ohjelmistokehitykselle Sovellusten koko ajan mutkistuessa ohjelmistokehityksen painopiste on vähitellen siirtymässä perinteisestä toteutuksesta eli koodauksesta suunnitteluun [24]. Myös teknisten ratkaisujen monipuolistuminen ja mutkistuminen on lisännyt erityisesti arkkitehtuurisuunnittelun tarpeellisuutta. Aiemmin ohjelmistoyrityksillä saattoi olla vain yksi hallitseva arkkitehtuuriratkaisu jota käytettiin kaikissa sovelluksissa [32]. Nykyisin varteenotettavia ratkaisuja yksinkertaisellekin sovellukselle on vähintään muutamia, joista sopivan löytäminen saattaa edellyttää hyvin perusteellista tietämystä sekä järjestelmän toiminnasta että sovellusympäristöstä ja tietenkin itse ratkaisuista. Valituilla arkkitehtuuriratkaisuilla on myös kauaskantoisia vaikutuksia koko ohjelmistoyrityksen liiketoimintastrategiaan. Kuva 2.2 Arkkitehtuurisuunnittelu osana ohjelmistokehitystä ja suunnittelua. Arkkitehtuurisuunnitteluvaiheessa tunnistetaan järjestelmän perusosat (esim. moduulit ja niiden palvelut), jotka sitten moduulisuunnittelun yhteydessä tarkemmin spesifioidaan. Arkkitehtuurisuunnittelu on siis keskeinen osa ohjelmistokehitystä. Suunnittelun osana se muodostaa järjestelmän teknisen määrittelyn rungon, jota moduulisuunnittelu sitten täydentää lisäämällä tähän run- 15

16 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana koon pienemmät yksityiskohdat arkkitehtuurisuunnitelman sanelemien periaatteiden mukaisesti (ks. kuva 2.2). Tästä lähtökohdasta voidaankin todeta, että arkkitehtuurisuunnitelma tarjoaa ratkaisut, joiden avulla määrittelyn sekavasta toimintojoukosta saadaan järkevä kokonaisuus eli toimiva ja luotettava järjestelmä. Siten se ei enää olekaan pelkästään yksi irrallinen ohjelmistosuunnittelun osa-alue vaan koko ohjelmistokehitysprosessin perusta. Arkkitehtuurisuunnittelun tavoitteet Ohjelmistokehityksen perustavoitteena on yleensä käyttäjää mahdollisimman hyvin palveleva järjestelmä, mahdollisimman vähällä vaivalla (= kustannuksia säästäen) ja yksinkertaisesti. Tähän pyritään mm. laadukkaan arkkitehtuurisuunnittelun kautta. Laadukkaasta arkkitehtuurisuunnitelmasta ja arkkitehtuurista voidaan yleensä erottaa seuraavia tunnusmerkkejä: vaatimusten mukaisuus (oikeellisuus) [42], selkeys, yksinkertaisuus ja systemaattisuus [34], tehokkuus ja hajautettavuus (skaalautuvuus), osittuvuus [28] ja joustavuus [35] Yksi laadukkaan arkkitehtuurin peruslähtökohtia on sen kyky täyttää vaatimukset eli vaatimusten mukaisuus. Vaikka mitään ehdotonta ja oikeaa ratkaisumallia ei olekaan, tulee järjestelmän vaatimukset huomioida tarkoin arkkitehtuuriratkaisun valinnassa. Vaatimusten kannalta riittämätön ratkaisumalli johtaa yleensä joko projektin keskeytymiseen tai vähintään ohjelmiston arkkitehtuurin rapautumiseen, kun ohjelmoinnissa ja moduulisuunnittelussa joudutaan kiertämään arkkitehtuurin puutteita erilaisilla vippaskonsteilla. Toisaalta vaatimuksiin nähden liian raskaan arkkitehtuurimallin käyttö kuluttaa turhaan resursseja ja lisää kustannuksia, eikä sen tuloksena syntyvä järjestelmäkään yleensä toimi parhaalla mahdollisella hyötysuhteella. Vaatimusten mukaisuuskaan ei kuitenkaan vielä ole riittävä tae arkkitehtuurisuunnittelun laadukkuudelle. Itse asiassa hyvästäkään arkkitehtuurisuunnitelmasta ei ole mitään hyötyä, jos kukaan muu ei sitä suunnittelijan lisäksi ymmärrä. Turha mutkikkuus on aina pahasta ja epäjohdonmukainen tai muuten epäyhtenevä ratkaisu ylläpidon painajainen. Tästä syystä arkkitehtuurisuunnittelun tulisikin olla niin yksinkertainen ja selkeä kuin muita perusperiaatteita romuttamatta on mahdollista. Yhtenevä ratkaisutapa tekee myös suunnitelmasta helposti noudatettavan [34] ja keventää näin suunnittelijankin taakkaa, kun joka kohtaa ei tarvitse selittää toteutusporukalle erikseen. 16

17 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Hajautettavuus ja tehokkuus esitetään usein arkkitehtuurisuunnittelun ensimmäisinä tavoitteina. Viime aikoina niiden merkitys onkin huomattavasti kasvanut, kun laajat verkkopalvelut ja tietojärjestelmät ovat yleistyneet voimakkaasti Internetin vanavedessä. Erityisesti selainkäyttöisissä järjestelmissä on lisäksi tärkeää suhteellisen suureenkin resurssien vaihteluun sopeutuminen eli skaalautuvuus. Tässä tulee puhtaan tehon tarpeen lisäksi tärkeäksi myös resurssien hajautuksen mukauttaminen kuormituksen mukaan, eli jousto siten, että järjestelmä toimii aina mahdollisimman hyvällä hyötysuhteella. Itse asiassa skaalautuvuus kuuluukin yhtenä osatekijänä tässä listatun joustavuuskäsitteen alle, johon käyttäjämääräjoustavuuden lisäksi voidaan lukea myös joustavuus muutosten, virheiden ja käyttöympäristön suhteen. Olipa ohjelma suunniteltu ja toteutettu miten hyvin tahansa, kaikkien laadukkuusvaatimusten noudattaminen täydellisesti on mahdotonta. Arkkitehtuurin laadukkuuden arvioinnin suhteen on myös eri järjestelmien välillä painotuseroja. Esim. potilaan turvallisuuden kannalta kriittisissä reaaliaikajärjestelmissä virhekäsittely on huomioitava aivan eri tasolla kuin vaikkapa perinteisen potilas-kertomusjärjestelmän arkkitehtuurissa. Silti kaikki arkkitehtuurin laadukkuuteen vaikuttavat seikat tulisi ottaa huomioon vähintään pikaisen pohdinnan kautta jokaisessa ohjelmistoprojektissa. Näin taattaisiin järjestelmälle sekä sen arkkitehtuurille pitkä ja huoleton elinikä ja vältyttäisiin tulevaisuudessa ikäviltä yllätyksiltä, joita huolimattomasti tehdyt arkkitehtuuriratkaisut saattavat poikia vielä vuosienkin käytön jälkeen. 2.3 Terveydenhuollon tietojärjestelmien erityispiirteet arkkitehtuurisuunnittelun kannalta Jotta arkkitehtuurisuunnittelu voisi parhaiten vastata sille asetettuihin tavoitteisiin, tulee myös kehitettävän tietojärjestelmän sovellusalue ja sen arkkitehtoniset tarpeet huomioida riittävästi suunnittelun eri vaiheissa. Käytännössä tämä tarkoittaa usein sovellusaluespesifisten arkkitehtuurivaatimuksen selvittämistä ja suunnittelufilosofian sovittamista näiden vaatimusten mukaiseksi. Tässä auttaa ennen kaikkea tietojärjestelmän sovelluskohteiden tuntemus ja sen sovellusaluekohtaisten erityispiirteiden tunnistaminen. Tässä alakohdassa onkin tarkemmin käsitelty, miksi ja mihin tietojärjestelmiä tarvitaan terveydenhuollossa. Lisäksi on pyritty tuomaan esille joitakin terveydenhuollon tietojärjestelmiin liittyviä erityispiirteitä ja erityisratkaisuja ennen kaikkea arkkitehtuurisuunnittelun kannalta. 17

18 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Tietojärjestelmien sovellusalueet terveydenhuollossa Terveydenhuollon tietojärjestelmällä tarkoitetaan kaikkia terveydenhuollon sektorin toimintaan liittyviä tietojärjestelmiä, kattaen julkisen ja yksityisen terveydenhuollon, itsenäisen ammatinharjoittajan sekä tarpeelliselta osin viranomaistoiminnan [3]. Järjestelmien käyttötarkoitus vaihtelee paljon. Toisaalta tarvitaan pelkästään tiettyyn tarkoitukseen suunnattuja erikoissairaanhoidon järjestelmiä ja toisaalta hyvin laajoja ja muidenkin sovellusalojen käytössä olevia taloushallinnon ja ajankäytön järjestelmiä. Seuraavassa on lueteltu joitakin tyypillisimpiä tietojärjestelmien käyttökohteita terveydenhuollossa [3]: potilas/sairaskertomustietojen hallinta ja varastointi (potilaskertomusjärjestelmät) ajanvaraus (esim. potilaskäyntien ajanvarausjärjestelmät) laskutus ja hallinto (esim. potilaskäyntien laskutus- ja budjetointi- järjestelmät) tilastointi (esim. potilaskäyntien syyn tilastointia tekevät järjestelmät) varastonvalvonta (varastonhallinnan ja -valvonnan järjestelmät esim. liikuntarajoitteisille lainattavien välineiden lainojen hallinta) laboratorio (esim. kliinisen kemian laboratoriojärjestelmät) apteekit (esim. apteekkien lääkevaraston hallintajärjestelmät) hammashuolto (hammashuollon järjestelmät) tieteellinen tutkimus (lääketieteellisessä tutkimuksessa apuna käytetyt, yleensä hyvin spesifiset järjestelmät) erikoissairaanhoito (esim. radiologian järjestelmät) vuodeosasto (esim. vuodeosaston hoitopaikkojen tilannetta seuraavat järjestelmät) avohoito (avohoidon järjestelmät) tehostetun hoidon potilasvalvonta (esim. teho-osaston monitorointijärjestelmät) potilaan yksilöllisen hoito-ohjelman suunnittelu (esim. fysioterapian hoito-ohjejärjestelmät) hoito/tutkimuslaitteet (esim. EKG-monitorointi ja röntgenlaitteiden järjestelmät) elektroniset sanakirjat ja muut hakuteokset (esim. lääkärin CD, elektroninen Pharmaca Fennica jne.) konsultaatio [10] [11] (esim. etäkonsultaation järjestelmät) päätöksenteon tukijärjestelmät (esim. diagnostiset tai hoidonohjausjärjestelmät) Lisäksi tarvitaan tietojenkäsittelyyn luonnollisesti tavallisia toimistoohjelmia (Office-paketti jne.) sekä erilaisia johtamisen järjestelmiä 18

19 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana [3]. Näitä ei kuitenkaan voida pitää varsinaisesti terveydenhuollon tietojärjestelminä. Esimerkkinä Pegasos-terveyskeskusjärjestelmä Pegasos-terveyskeskusjärjestelmä on Novo-konsernin tuottama laaja, lähinnä terveyskeskuksille tai pienehköille sairaaloille suunnattu ohjelmistoperhe, jonka keskeisin osa on Pegasos-terveyskertomus. Pegasoksen ensimmäiset versiot asennettiin keväällä 1992 [12] ja siitä pitäen järjestelmä on ollut erityisen suosittu etenkin pienissä ja keskisuurissa terveyskeskuksissa. Kuva 2.3 Pegasos-terveyskertomusjärjestelmän keskeisimpiä osia [13] Pegasoksen rungon muodostavat yleensä Windows NT -palvelimelle tallennettu järjestelmän tietokanta ja Windows-käyttöjärjestelmällä varustetut työasemat, joihin kuhunkin on asennettu Pegasostyöasemaohjelmisto [13]. Tietokantaa päivitetään reaaliaikaisesti, joten tiedot pysyvät palvelimella aina ajan tasalla. Tämä helpottaa järjestelmän tietojenhallintaa ja varmuuskopiointia, mutta asettaa toisaalta tietoverkolle suurempia kapasiteettivaatimuksia. 19

20 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Nykyisten tietojärjestelmien yleisen kehityssuuntauksen mukaisesti Pegasoskin on rakenteeltaan modulaarinen eli koostuu helposti lisättävistä ja päivitettävistä palasista (ks. kuva 2.3), jotka mahdollistavat järjestelmän sovittamisen hyvin erilaisten ja erikokoisten terveydenhuollon organisaatioiden tarpeisiin. Terveyskeskusjärjestelmille ominaisen filosofian mukaisesti pyritään samassa paketissa tarjoamaan kaikki terveyskeskukselle tarpeellinen, mikä helpottaa ennen kaikkea pienten organisaatioiden ATK-henkilöstön ylläpitotaakkaa ja poistaa osajärjestelmien välisen kommunikoinnin ongelmia. Terveydenhuollon tietojärjestelmien arkkitehtuurien kehitys ja erityispiirteet Tietokoneet ja tietojärjestelmät tulivat Suomenkin sairaaloihin jo 1960-luvulla [24][7]. Ensimmäiset järjestelmät perustuivat suuriin keskuskoneisiin, joissa käytettiin lähinnä tilastoinnin ja taloushallinnon sovelluksia. Käyttäjät olivat pääosin ATK-alan ammattilaisia [24] eivätkä terveydenhuollon henkilöstöä. Alkuaikojen tietojärjestelmille oli myös tyypillistä, että ne olivat arkkitehtuuriltaan laitteistosidonnaisia (ks. kuva 2.4) ja yleensä järjestelmät joko toimitettiin laitteistojen mukana tai ohjelmoitiin itse laitteistospesifisellä kielellä tai murteella luvun loppupuoli ja 1980-luvun alku olivat minitietokoneiden tulemisen aikaa. Samalla laitteistot myös halpenivat huomattavasti ja monet sairaalat saivat omat tietojärjestelmänsä näihin aikoihin. Tyypillinen sairaalan tietojärjestelmä 1980-luvun alussa oli tilaustyönä tai julkisena projektina toteutettu, näyttöpäätteeltä käytettävä palvelinkeskeinen ja merkkipohjainen järjestelmä, jossa oli suljettu ja räätälöity arkkitehtuuri. Tällaisia olivat esim. terveyskeskuksien tarpeisiin suunnattu FINSTAR ja 1980-luvun puolivälissä käyttöön otettu MUSTI [8][7]. Myös erilaisia teho- ja leikkaussaleille suunnattuja monitorointijärjestelmiä alkoi ilmestyä entistä enemmän [8] luku merkitsi tietojärjestelmille suurta ulkoasun muutosta. Käyttöliittymiä muutettiin kiireesti graafiseksi [24] uuden ja nopeasti yleistyneen Windows-käyttöjärjestelmän myötä. Kehitysfilosofiaan kuului varsinkin perusterveydenhuollon suurempien järjestelmien alueella organisaatiokohtaisesti räätälöitävät ns. paketti-järjestelmät (esim. Pegasos [12], Sinuhe [25], MedTrak [15]). Ideana oli, että valmistaja tarjosi valmiin ja yhteisen sovelluskehikon eli järjestelmän rungon, jota kukin organisaatio sitten täydensi tarvitsemillaan osapaketeilla 20

21 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana 1971 Ensimmäiset varsinaiset terveydenhuollon tietojärjestelmät. Laitteistosidonnainen arkkitehtuuri. Suuret keskuskoneet 1981 Päätelaite Päätelaite Suljetut merkkipohjaiset järjestelmät 1991 Tulostin PC PC Unix-palvelimet ja graafisen käyttöliittymän tarjoavat Windows-työasemat 2001 PDA-laite Kannettava Linux, Windows NT tai 2000 Server Linkkitorni Skannerit yms. PC Windows 2000 tai Windows 98 Tulostin Selainkäyttöiset järjestelmät, monipuoliset verkot Kuva 2.4 Tietojärjestelmien 30 -vuotinen kehityshistoria terveydenhuollossa 21

22 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana (räätälöitävyys). Arkkitehtuuriltaan järjestelmät perustuivat yleensä Fat-Client-ratkaisuun, jonka pohjana oli TCP/IP-verkko, Unixpalvelin ja Windows-käyttöjärjestelmällä varustetut työasemat. Eri järjestelmien välinen kommunikointi oli edelleen hankalaa, mikä lisäsi organisaatioiden järjestelmä- ja toimittajasidonnaisuutta [9] luvun puolivälissä useimmat Suomen terveyskeskuksetkin siirtyivät ATK-aikaan, sairaaloiden pysyessä edelleen entisissä merkkipohjaisissa järjestelmissään [2]. Avoimuus [9], järjestelmien välisen kommunikoinnin helpottaminen ja selainkäyttöliittymät ovat nykyisiä tietojärjestelmäkehitystrendejä myös terveydenhuollossa. Kaksitasoisista Fat-Client-arkkitehtuureista ollaan vähitellen siirtymässä Thin-Client-monitasoarkkitehtuureihin. Erityisesti Web-sovellukset ja niihin liittyen hajautetut oliotekniikat ovat lisänneet suosiotaan. Myös langattomiin tekniikoihin perustuvat järjestelmät ovat tulossa arkipäiväisiksi erityisesti monitorointijärjestelmien puolella. Toimintaympäristön muutokset ja alan kehittämiseen kohdistuneet haasteet ovat osaltaan jouduttaneet tietojärjestelmien käyttöönottoa pienemmissäkin terveydenhuollon yksiköissä. Toisaalta arkkitehtuuriltaan avoimemmat ja helpommin hajautettavissa olevat järjestelmät ovat laajentaneet ja edelleen laajentamassa huimasti perinteisiä tietojärjestelmien sovellusmahdollisuuksia. Perustarve järjestelmien käytölle terveydenhuollon toimijoiden tiedonhallinnan apulaisina on kuitenkin säilynyt samana koko niiden kehityshistorian ajan. Näin arkkitehtuurisuunnittelunkaan olennaisimmat lähtökohdat eivät ole teknisten arkkitehtuuriratkaisujen ja -mallien vaihtumisesta huolimatta muuttuneet kovin paljon 30 vuoden aikana. Terveydenhuollon tietojärjestelmien erityisteknologiat Vaikka terveydenhuollon tietojärjestelmät eivät juuri eroa muista tietojärjestelmistä, niiden arkkitehtuurisuunnitteluun liittyy joitakin erikoisratkaisuja sekä tekniikoita, jotka arkkitehtuurisuunnittelijan on hyvä vähintään tunnistaa niistä puhuttaessa. Yleensä nämä ratkaisut ovat nimenomaan tietojärjestelmien väliseen kommunikaatioon liittyviä standardeja joista tässä esitellään lyhyesti kaksi keskeisintä: HL7 ja DICOM. HL7 ja DICOM HL7 eli Health Level 7 on terveydenhuollon tietojärjestelmien väliseen peruskommunikaatioon tarkoitettu standardi. Se on suunnattu erityisesti sairaaloiden tietojärjestelmien keskinäiseen viestintään, mutta 22

23 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana sopii yleisyytensä vuoksi myös muihin terveydenhuollon alueen tietojärjestelmätarpeisiin. HL7:n perustana ovat sen määrittelemät ja standardoimat erilaiset tekstipohjaiset viestityypit ja niiden rakenne esim. CDA (Clinical Document Architecture) (ks. kuva 2.5). Näin sitä tukevat järjestelmät voivat kommunikoida keskenään yhteisen rajapinnan kautta. HL7:n kehityksestä vastaa HL7 Standards Committee Yhdysvalloissa. Suomessa kehitystä ja soveltamista puolestaan koordinoi HL7 yhdistys, joka toimii nykyisellään VTT:n alaisuudessa. Kuva 2.5 Esimerkki HL7:n määrittelemän CDA-muotoisen sanoman rakenteesta. Sanomassa on ensin ns. otsikko-osa, joka yksilöi ja luokittelee dokumentin ja sisältää tarpeellista tietoa dokumentin varsinaisesta sisällöstä. Otsikko-osan jälkeen seuraa sisäkkäisistä osioista koostuva runko-osa, jossa itse sanoma kulkee [75]. HL7 ei tekstipohjaisena juurikaan sovi kuvainformaation välitykseen. Kuvainformaation siirtäminen on kuitenkin yksi tärkeimmistä tietojärjestelmien kommunikaatiotarpeista terveydenhuollossa ja erityisesti sairaalaympäristössä. Tätä tarkoitusta varten onkin kehitetty oma standardinsa DICOM eli Digital Imaging and Communications in Medicine, joka juuriltaan on HL7:kin vanhempi ja käytännössä myös suositumpi. DICOM on itse asiassa hyvin samankaltainen kuin HL7. Erona kuitenkin on, että sovellusalueena onkin nyt lääketieteellinen kuvantaminen ja välitettävänä datana binäärimuotoista kuvadataa. DICOM toimii HL7:n tapaan tässä vain välikätenä määritellen kielen ja kehykset [26] siirrettäville kuville ja niihin liittyvälle datalle. Tämä toteutetaan mm. spesifioimalla oma yleisluontoinen tiedostoformaatti (Vrt. HL7:n CDA), joka koostuu paitsi kuva-alkioista myös kuvaan liittyvästä yleisestä informaatiosta (meta-data eli DICOM Header) (ks. kuva 2.6). 23

24 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Kuva 2.6 Esimerkki DICOM-tiedoston rakenteesta. Kuten HL7:n määrittelemässä CDA:ssakin myös DICOM:ssa on ns. header- eli otsikko-osa, joka luokittelee ja yksilöi kuvan sekä sisältää informaatiota kuvan sisällöstä ja potilaasta [26]. Standardien tulevaisuudennäkymiä Terveydenhuollon tietojärjestelmien standardointityö on viimevuosina edelleen lisännyt merkitystään. Mm. HL7:sta ja DICOM:sta saadut positiiviset kokemukset ovat osaltaan auttaneet standardien kehitystyötä eteenpäin. Entistä enemmän on kuitenkin pyritty siirtymään yleisempään suuntaan eli hyödynnetään terveydenhuollossakin jo olemassa olevia ratkaisuja ja tyydytään mieluummin vain esittämään sovellusaluekohtaisia implementointi-ohjeita. Näin vältetään turhaa työtä. Tämän seurauksena mm. XML-pohjaiset ratkaisut kuten esimerkiksi SOAP tulevat olemaan vahvoilla tulevaisuuden standardeja suunniteltaessa. Standardointityö ei kuitenkaan tapahdu silmänräpäyksessä, vaan laahaa aina jonkin verran tekniikkamuotien perässä. Toisaalta tämä on hyväkin asia. Näin käyttöön tulevat aina taatusti koetellut ja turvalliset ratkaisut. Vaikka haavekuvien keskenään täysin yhteensopivista ja kommunikoivista tietojärjestelmistä ollaan vielä kaukana, jo nyt saadut positii- 24

25 Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana viset kokemukset ovat osoitus siitä, että standardoinnin avulla voidaan helpottaa paljon tietojärjestelmien välistä yhteydenpitoa. Tämän valossa voidaankin todeta, että tulevaisuudessa järjestelmien lähes täydellinen yhteensopivuus voi muuttua unelmasta todellisuudeksi. Yksi asia kuitenkin on miltei varma, jos näin tulee käymään, se tapahtuu tietysti entistä parempien standardien avulla. 25

26 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut 3. ARKKITEHTUURIN OSITTAMINEN JA ARKKITEHTUURIRATKAISUT Arkkitehtuurisuunnittelun onnistumisen tärkeimpiä edellytyksiä on hahmottaa ja erotella järjestelmän arkkitehtuurista sen keskeiset osakokonaisuudet ja valita sitten kuhunkin osaan siihen parhaiten sopivat arkkitehtuuriratkaisut. Tätä silmälläpitäen onkin järkevää yleensä jo ennen varsinaisen suunnittelun aloittamista tutustua siihen mitä osia arkkitehtuuriin kuuluu ja minkälaisia arkkitehtuuriratkaisuja kuhunkin osaan on tarjolla. 3.1 Arkkitehtuurin jako suunnittelun näkökulmasta Tietojärjestelmän arkkitehtuuri on laaja ja monipuolinen kokonaisuus. Tästä syystä myös arkkitehtuurin osittaminen voidaan tehdä monella eri tavalla. Kuvassa 3.1 on lähestytty arkkitehtuurin jakoa suunnittelun näkökulmasta. Tietojärjestelmän arkkitehtuuri Sovellusarkkitehtuuri Komponentti- ja olioarkkitehtuuri Tietovarastoarkkitehtuuri Laitteisto- ja verkkoarkkitehtuuri Kuva 3.1 Tietojärjestelmän arkkitehtuurin jakautuminen osa-alueisiin 26

27 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut On huomattava, että arkkitehtuurin osa-alueiden nimitykset ja tehtävänjako vaihtelevat runsaasti eri lähteissä. Taulukossa 3.1 on listattuna kunkin elementin merkitys sen mukaisesti kuin sitä on käytetty tässä dokumentissa. Taulukko 3.1 Arkkitehtuurin osa-alueiden tehtävät. Osa-alue: Sovellusarkkitehtuuri Komponentti- ja olioarkkitehtuuri Kuvaus Kuvaa ne tekniset mallit ja periaatteet, joiden avulla järjestelmä jaetaan sopiviin kokonaisuuksiin karkeimmalla tasolla. Monet arkkitehtuuriratkaisumallit ovat sovellusarkkitehtuuritason malleja. Joissain lähteissä esim. [33] käytetään tässä kuvatun sovellusarkkitehtuurien merkityksessä myös järjestelmäarkkitehtuurinimitystä Määrittelee järjestelmän komponentti/luokkatason rakenteen sekä kuvaa järjestelmän komponenttitason osittamisessa käytettävät ja/tai komponenttien välisen yhteyskäytännön tekniikat. Tietovarastoarkkitehtuuri Kuvaa järjestelmän käyttämän tietovaraston rakenteen (esim. tietokannan taulut, kentät ja relaatiot). Lisäksi tietovarastoarkkitehtuuriin liittyy monesti tietovaraston hajautuksen ja yhteyskäytännön ym. tietokantatekniikoiden kuvaus. Laitteisto- ja verkkoarkkitehtuuri Spesifioi järjestelmän toimintaympäristön, siihen kuuluvat verkko- ja laitteistokokoonpanot sekä näiden välisen yhteistoiminnan. Yllä esitellyistä arkkitehtuurin osa-alueista lähinnä sovellus- sekä komponentti- ja olioarkkitehtuuri kuuluvat varsinaisen ohjelmistoarkkitehtuurisuunnittelun piiriin. Silti on muistettava, että arkkitehtuurisuunnitelma on aina pyrittävä saamaan mahdollisimman yhtenäiseksi kokonaisuudeksi, joten myöskään tietovarastoja tai laitteisto/verkkoratkaisuja ei saisi unohtaa ohjelmistoarkkitehtuurisuunnittelun yhteydessä. 27

28 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut 3.2 Asiakas-palvelin-mallin mukaiset sovellusarkkitehtuuriratkaisut Useimmat selain-sovellukset perustuvat nykyisin ns. asiakas-palvelin (Client-Server) -arkkitehtuurimalliin [36]. Asiakas-palvelin-malli on nimensä mukaisesti asiakas- ja palvelinkoneen välinen yhteydenpitomalli. Yksinkertaisimmillaan sen mukainen järjestelmä toimii siten, että asiakas(järjestelmä) (client) lähettää sopivan tiedonsiirtoprotokollan (esim. HTTP) välityksellä palvelupyynnön toiselle järjestelmälle (palvelin eli server), johon tämä sitten pyynnön tulkittuaan vastaa (ks. kuva 3.2). Vastaukseen voi liittyä esim. tietokantahaku, jonka tulokset palautetaan kysyjälle. Asiakas-palvelin-mallia noudattavaan järjestelmään liittyy siis kolme perustekijää: asiakasjärjestelmä, joka pyytää palvelua, palvelinjärjestelmä, joka vastaa palvelupyyntöön pyynnön edellyttämällä tavalla, sekä yhteyskäytäntö, joka määrää, miten tieto siirtyy asiakkaan ja palvelimen välillä. Oleellista on, että asiakas ja palvelin voivat sijaita millä tahansa laitteistoalustalla ja missä tahansa paikassa, jossa tiedon välitykseen käytettävän protokollan mukainen yhteys eli yhteyskäytäntö on mahdollinen [33]. Myöskään järjestelmän roolin (asiakas vai palvelin) ei tarvitse olla mallin mukaisissa järjestelmissä välttämättä pysyvä, vaan palvelin voi yhtä hyvin itse toimia asiakkaana, vaikkapa kysyessään jotain saamansa palvelupyynnön toteuttamisessa tarvittavaa palvelua edelleen toiselta palvelimelta. Yhteyskäytäntö (esim. HTTP) Palvelupyyntö Palvelin Vastaus Asiakas Kuva 3.2 Asiakas-palvelin-mallin periaate. 28

29 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Sovellusarkkitehtuurin tasot eli kerrokset Selainkäyttöisten, pääosin verkossa toimivien järjestelmien arkkitehtuurin tärkeimpinä vaatimuksina voidaan pitää hyvää hajautettavuutta ja osittuvuutta. Useimmat arkkitehtuuriratkaisumallit keskittyvätkin juuri järkevästi hajautettavissa sekä ositettavissa olevan järjestelmän aikaansaamiseen. Lähtökohtana on sovelluksen jako kuormituksen ja toiminnallisuuden suhteen optimaalisiin mutta toisaalta mahdollisimman itsenäisiin osiin, joita sovellusarkkitehtuuriratkaisujen yhteydessä usein kutsutaan tasoiksi tai kerroksiksi (tiers). Kunkin tason komponentit käyttävät vain alemman tai saman tason tarjoamia komponentteja, mikä helpottaa järjestelmän riippuvuussuhteiden hallintaa. Seuraavassa on lueteltu sovellusarkkitehtuurin perustasot. Käyttöliittymä- eli esitystapataso hoitaa tietojen esittämisen käyttäjäystävällisessä muodossa (käyttöliittymä) ja toisinaan myös syötteiden tarkistuksen. Esitystapakerroksen tehtävät ovatkin pääosin käyttäjäkeskeisiä, minkä takia sen tarjoamia palveluja kutsutaan usein käyttäjäpalveluiksi (User Services). Sovelluslogiikkataso toimii tavallaan järjestelmän aivoina. Siinä hoidetaan varsinainen tietojen käsittely ja muokkaus [38]. Tietovarastotason tehtävänä on suorittaa pyydetyt tietokantakyselyt ja välittää tulokset edelleen käsiteltäväksi ylemmälle sovelluslogiikkakerrokselle. Nämä tasot voidaan tietysti hajauttaa eri tavalla, niitä voidaan yhdistellä tai jakaa edelleen pienempiin osiin [33]. Tässä esiteltävät sovellusarkkitehtuurimallit eroavatkin juuri kerrosjakonsa suhteen. Arkkitehtuuriratkaisujen jako tasojen sijainnin suhteen Sovellusarkkitehtuuritasojen sijainnin perusteella arkkitehtuuriratkaisut jaetaan kahteen pääryhmään. Jos järjestelmän toiminnallisuuden kannalta tärkeimmät kerrokset eli sovelluslogiikka ja tietovarasto sijaitsevat kokonaan palvelimella puhutaan Thin-Client-ratkaisusta. Jos taas vähintään sovelluslogiikka on edes osittain sijoitettu asiakasjärjestelmään, on kyseessä Fat-Client-ratkaisu. Taulukossa 3.2 on vertailtu näiden ratkaisujen hyviä ja huonoja puolia. 29

30 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Taulukko 3.2 Thin-Client ja Fat-Client-ratkaisujen vertailua. Hyvät puolet on merkitty +:lla ja huonot -:lla. Thin-Client Fat-Client Sovelluslogiikka ja tietovarasto ovat kokonaan palvelimella. Käyttöliittymä on kuitenkin useimmiten asiakaspäässä. Vähintään osa sovelluslogiikasta käyttöliittymän lisäksi on asiakaspäässä. + Järjestelmä helppo ylläpitää ja päivittää. + Ei riipu asiakasjärjestelmästä. Toiminnallisuuden integrointi käyttöliittymään hieman vaikeampaa. + Ei kuormita palvelinta yhtä paljon kuin Thin-Client-ratkaisu. + Kehitystyökaluja hyvin saatavilla. Riippuvainen käyttäjän järjestelmästä. Järjestelmän päivitykset ja ylläpito hankalaa Vaatii asennuksen myös jokaisen asiakkaan koneelle. Kuormittaa tietoverkkoa [33]. Selainkäyttöisissä järjestelmissä Thin-Client-ratkaisut ovat yleensä paremmin perusteltavissa kuin ns. rikkaan käyttöliittymän Fat-Clientmalli. Selain itsessään ei rajoitettuine skriptikielineen sovi mutkikkaan sovelluslogiikan alustaksi. Toisaalta laajojen erillisten komponenttien ja ohjelmistojen asentaminen asiakaskoneelle vie pohjan koko selaimen käytön mielekkyydeltä. Fat-Client-ratkaisujakin tarvitaan mutta selainkäyttöisiin sovelluksiin ne eivät vielä nykyisellään hyvin sovi. Myös palvelimen kuormituksen tasaamiseen on olemassa suositeltavampia keinoja monitasoarkkitehtuurien ja niihin liittyvien hajautusteknologioiden myötä. Arkkitehtuuriratkaisut jaoteltuina tasojen lukumäärän suhteen Paitsi arkkitehtuuritasojen sijainnin mukaan arkkitehtuuriratkaisut voidaan jakaa myös tasojen lukumäärän perusteella. Yleensä nämä ratkaisumallit ovat yksitaso-, kaksitaso- ja monitasoarkkitehtuuri (ks. kuva 3.3 ja taulukko 3.3). Yksitasoarkkitehtuurissa sovelluksen kaikki tasot (tietovarasto, sovelluslogiikka ja käyttöliittymä) ovat yhdessä ja yhdellä palvelimella siis yhdellä laitteistoalustalla. Tämän ratkaisumallin mukaista tapaa edustaa mm. järjestelmien etäkäyttö ns. pääteohjelmien avulla [33]. 30

31 Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Vaikka yksitasoarkkitehtuuri on toteutuksen kannalta yksinkertainen, ei sitä huonon ylläpidettävyyden ja hajautettavuuden takia voi suositella edes kaikkein yksinkertaisimpiin sovelluksiin. Kun arkkitehtuurin kaikki tasot ovat yhdessä, myös osittuvuus kärsii ja yksitasoarkkitehtuuri sopii näin heikosti nykyisiin laajoihin selainkäyttöisiin sovelluksiin. Yksitasoarkkitehtuurista seuraava kehitysaskel on luonnollisesti kaksitasoarkkitehtuuri. Siinä tietokannan käsittely on eriytetty omaksi erilliseksi arkkitehtuurin kerrokseksi, mikä helpottaa tietokantariippumattoman koodin kirjoittamista. Yksitasoarkkitehtuuriin nähden kaksitasoarkkitehtuuri on myös paremmin hajautettavissa, koska tietokanta ja sen käsittely ovat irrallisina siirrettävissä erilliselle palvelimelle [6]. Kaksitasoarkkitehtuurin ongelmana on kuitenkin edelleen sovelluslogiikan ja käyttöliittymätason liittyminen kiinteästi toisiinsa. Tämä vaikeuttaa sovelluksen päivittämistä ja muutakin ylläpitoa. Esimerkiksi käyttöliittymää on hankala muokata tai päivittää erikseen, koska muutoksesta saattaa samalla seurata sovelluslogiikan toimimattomuus [39]. Myös sovelluksen kunnollinen hajauttaminen on hankalaa. Tästä syystä kaksitasoarkkitehtuuria käyttävät järjestelmät ovatkin perinteisesti olleet rikkaan käyttöliittymän Fat-Client-ratkaisuilla toteutettuja järjestelmiä, jotka vaativat monimutkaista syötteiden sekä käyttöliittymän hallintaa asiakaspäässä, eivätkä hyödynnä palvelinta muuten kuin yhteisen tietokantansa ja sen käsittelyn osalta. Esitystapa Esitystapa Esitystapa Sovelluslogiikka Sovelluslogiikka Sovelluslogiikka Kannanhallinta Kannanhallinta Kannanhallinta Yksitasoarkkitehtuuri Kaksitasoarkkitehtuuri Monitasoarkkitehtuuri Kuva 3.3 Yksi-, kaksi- ja kolmetasoisen sovellusarkkitehtuurin rakenne. Monitasoarkkitehtuurin mukainen järjestelmä on loogisten osien erottelun vuoksi joustavampi kuin yksi- tai kaksitasoiset ratkaisut. 31

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Visual Basic -sovelluskehitin Juha Vitikka

Visual Basic -sovelluskehitin Juha Vitikka Visual Basic -sovelluskehitin Helsinki 30.10.2000 Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Visual Basic sovelluskehitin Seminaari: Ohjelmistotuotantovälineet Tietojenkäsittelytieteen

Lisätiedot

WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa

WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa WWW ja tietokannat WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa tekstiä, kuvia, hyperlinkkejä Staattiset sivut kirjoitettu kerran, muuttaminen käsin ongelmana pysyminen ajantasalla Ylläpito hankalaa,

Lisätiedot

DIPLOMITYÖ ARI KORHONEN

DIPLOMITYÖ ARI KORHONEN DIPLOMITYÖ ARI KORHONEN TEKNILLINEN KORKEAKOULU Diplomityö Tietotekniikan osasto 20.5.1997 Ari Korhonen WORLD WIDE WEB (WWW) TIETORAKENTEIDEN JA ALGORITMIEN TIETOKONEAVUSTEISESSA OPETUKSESSA Työn valvoja

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

W3C-teknologiat ja yhteensopivuus

W3C-teknologiat ja yhteensopivuus W3C-teknologiat ja yhteensopivuus Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: W3C asettaa

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 12.12.2016 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

Yhteenveto. Ymmärrä kokonaisuus

Yhteenveto. Ymmärrä kokonaisuus Mikko Jokela Yhteenveto Poista tiedon monistaminen Järjestele hallittaviin kokonaisuuksiin Mahdollista informaation kulku Luo tiedolle saavutettavuus Käännä oikealle kielelle Ymmärrä kokonaisuus Yritykset

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA, Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat

Lisätiedot

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

Lisätiedot

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( )

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( ) PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma (1.5.2002-31.8.2004) Ydin-osaprojekti: potilastietojen toiminnallisen hallinnan näkökulma Yhteisten ydinkomponenttien määrittely" Ydin-osaprojektin rooli

Lisätiedot

Uutta Remote Support Platform 3.0 -versiossa

Uutta Remote Support Platform 3.0 -versiossa Uutta Remote Support Platform for SAP Business One Asiakirjaversio: 1.0 2012-10-08 Kaikki maat Typografiset merkintätavat Kirjasintyyli Esimerkki Näytöstä lainatut sanat tai merkit. Näitä ovat kenttien

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

XML johdanto, uusimmat standardit ja kehitys

XML johdanto, uusimmat standardit ja kehitys johdanto, uusimmat standardit ja kehitys Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: on W3C:n suosittama

Lisätiedot

HELIA 1 (19) Outi Virkki Käyttöliittymät ja ohjelman suunnittelu

HELIA 1 (19) Outi Virkki Käyttöliittymät ja ohjelman suunnittelu HELIA 1 (19) Luento 10 Sovelluksen hajauttamisesta 2 Mitä kaikkea voi hajauttaa / keskittää? 2 Miksi hajauttaa / keskittää? 2 Hajautuksen edellytys: modulaarisuus 3 Hajautuksen mahdollisia toteutustapoja

Lisätiedot

Tiedostojen jakaminen turvallisesti

Tiedostojen jakaminen turvallisesti Tiedostojen jakaminen turvallisesti Taustaa Tiedostojen jakaminen sähköisesti (File Sharing) on ollut joissakin organisaatioissa ongelmallista hallita. Jaettaviksi halutut viestit ovat liitetiedostoineen

Lisätiedot

99.5.2003 1 (4) ADAPTERITOTEUTUS PIRKANMAAN SAIRAANHOITOPIIRIN JÄRJESTELMIIN (AHO JA TAMLAB)

99.5.2003 1 (4) ADAPTERITOTEUTUS PIRKANMAAN SAIRAANHOITOPIIRIN JÄRJESTELMIIN (AHO JA TAMLAB) 99.5.2003 1 (4) ADAPTERITOTEUTUS PIRKANMAAN SAIRAANHOITOPIIRIN JÄRJESTELMIIN (AHO JA TAMLAB) TAUSTA Pirkanmaan sairaanhoitopiiri hyväksyttiin aluetietojärjestelmän (ATJ) kokeilulain piiriin v. 2001. Pirkanmaan

Lisätiedot

Standardit osana käyttäjäkeskeistä suunnittelua

Standardit osana käyttäjäkeskeistä suunnittelua Standardit osana käyttäjäkeskeistä suunnittelua 20.4.2006 Mikä on standardi? sovittu tapa tehdä jokin asia saatetaan tarkoittaa asian määrittelevää normatiivista asiakirjaa varmistetaan esim. Euroopassa

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

L models. Käyttöohje. Ryhmä Rajoitteiset

L models. Käyttöohje. Ryhmä Rajoitteiset Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Käyttöohje Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

HL7 Clinical Document Architecture. Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki

HL7 Clinical Document Architecture. Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki HL7 Clinical Document Architecture Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki Clinical Document Architecture (CDA) HL7 järjestön standardi Ensimmäinen julkaisu 2000 ja toinen 2005 Kliinisen

Lisätiedot

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan ITSM Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan Olli Saranen Senior Consultant Avoset Oy 31.8.2016 Esittely Mukana suomalaisten pankkijärjestelmien kehittämisessä ja ylläpitotyössä

Lisätiedot

RANTALA SARI: Sairaanhoitajan eettisten ohjeiden tunnettavuus ja niiden käyttö hoitotyön tukena sisätautien vuodeosastolla

RANTALA SARI: Sairaanhoitajan eettisten ohjeiden tunnettavuus ja niiden käyttö hoitotyön tukena sisätautien vuodeosastolla TURUN YLIOPISTO Hoitotieteen laitos RANTALA SARI: Sairaanhoitajan eettisten ohjeiden tunnettavuus ja niiden käyttö hoitotyön tukena sisätautien vuodeosastolla Pro gradu -tutkielma, 34 sivua, 10 liitesivua

Lisätiedot

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Oracle10 g Web Services Sisältö Service Oriented Architecture (SOA) Web Services Service Oriented Architecture Service Oriented

Lisätiedot

Hajautettujen järjestelmien rakentaminen - Jini. Ohjelmistotuotantovälineet-seminaarin esitelmä

Hajautettujen järjestelmien rakentaminen - Jini. Ohjelmistotuotantovälineet-seminaarin esitelmä Hajautettujen järjestelmien rakentaminen - Jini Ohjelmistotuotantovälineet-seminaarin esitelmä Anu K. Leponiemi (anu@lepo.net) Helsingin yliopisto Tietojenkäsittelytieteen laitos Helsinki 2000 SISÄLLYSLUETTELO

Lisätiedot

Aditro Tikon ostolaskujen käsittely versio SP1

Aditro Tikon ostolaskujen käsittely versio SP1 Toukokuu 2012 1 (8) Aditro versio 6.1.2 SP1 Päivitysohje Toukokuu 2012 2 (8) Sisällysluettelo 1. Tehtävät ennen versiopäivitystä... 3 1.1. Ohjelmistomuutosten luku... 3 1.2. Application Pool Identity...

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA Tarjouspyyntö Liite 5.3: Järjestelmän ylläpidettävyden arviointi 1 / 5 VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 22.4.15 3.01 Poistettu kotihoito

Lisätiedot

Integraatiotekniikan valinta - tie onnistumiseen.

Integraatiotekniikan valinta - tie onnistumiseen. Integraatiotekniikan valinta - tie onnistumiseen markus.andersson@commit.fi http://www.commit.fi 1 Agenda Järjestelmäintegroinnin nykytila Menestystekijät Teknologiatekijät Tekijöistä onnistunut projekti

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 582101 - Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 1 Ohjelmistotuotannon työkaluuista Projektinhallintatyökalut (ei käsitellä tällä kurssilla) CASE- ja mallinnustyökalut (esim. Poseidon)

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous 12.6.2015 Pasi Oksanen 1 Tavoite ja lähtökohdat Tavoitteena aikaansaada Varsinais-Suomen

Lisätiedot

6 XML-työkalut 1. 6 XML-työkalut

6 XML-työkalut 1. 6 XML-työkalut 6 XML-työkalut 1 6 XML-työkalut XML:n periaatteiden tutustumisen jälkeen on helpompi tutustua XML-dokumenttien käsittelyyn ja katseluun suunniteltuja työkaiuja. XML:n yleistymisen pahin pullonkaula on

Lisätiedot

NELJÄ HELPPOA TAPAA TEHDÄ TYÖNTEKIJÖIDEN TYÖSTÄ JOUSTAVAMPAA

NELJÄ HELPPOA TAPAA TEHDÄ TYÖNTEKIJÖIDEN TYÖSTÄ JOUSTAVAMPAA NELJÄ HELPPOA TAPAA TEHDÄ TYÖNTEKIJÖIDEN TYÖSTÄ JOUSTAVAMPAA Vie yrityksesi pidemmälle Olitpa yrityksesi nykyisestä suorituskyvystä mitä mieltä tahansa, jokainen yritysorganisaatio pystyy parantamaan tuottavuuttaan

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

W3C ja Web-teknologiat

W3C ja Web-teknologiat W3C ja Web-teknologiat Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), W3C Suomen toimisto World Wide Web Consortium (W3C) W3C kehittää yhteensopivia teknologioita

Lisätiedot

Järjestelmäintegrointi osana sovellusten rakentamista

Järjestelmäintegrointi osana sovellusten rakentamista 05 96 09:33 MEDICI DATA OY NT=358 81 3155650 5.02 Järjestelmäintegrointi osana sovellusten rakentamista Antero Ensio Medici Data Oy MediciData Oy aese9605.ppt 24.5.1998 7:51 sivu 1 24 05 96 09:34 MEDICI

Lisätiedot

Tulevaisuuden Internet. Sasu Tarkoma

Tulevaisuuden Internet. Sasu Tarkoma Tulevaisuuden Internet Sasu Tarkoma Johdanto Tietoliikennettä voidaan pitää viime vuosisadan läpimurtoteknologiana Internet-teknologiat tarjoavat yhteisen protokollan ja toimintatavan kommunikointiin Internet

Lisätiedot

IT Service Desk palvelun käyttöönotto palvelukeskuksissa

IT Service Desk palvelun käyttöönotto palvelukeskuksissa IT Service Desk palvelun käyttöönotto palvelukeskuksissa ValtioExpo 7.5.2009 Antti Karjalainen, Johtaja Hankkeen taustaa Tavoitteena yhden talous- ja henkilöstöhallinnon palvelukeskuksen perustaminen vuonna

Lisätiedot

REST an idealistic model or a realistic solution?

REST an idealistic model or a realistic solution? REST an idealistic model or a realistic solution? 17.10.2006 Jari Aarniala jari.aarniala@cs.helsinki.fi Johdanto Representational State Transfer, eli REST Arkkitehtuurinen tyyli hajautetuille (hypermedia)järjestelmille

Lisätiedot

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Terveyden

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

Yhteensopiva ja stabiili. Käsitteellistää suunnittelun. Parempi kuin koskaan aiemmin. Yksityiskohtien tarkka kuvaus. Saumaton kommunikaatio

Yhteensopiva ja stabiili. Käsitteellistää suunnittelun. Parempi kuin koskaan aiemmin. Yksityiskohtien tarkka kuvaus. Saumaton kommunikaatio ZWCAD 2012 ESITTELY Yhteensopiva ja stabiili Parempi kuin koskaan aiemmin Käsitteellistää suunnittelun Yksityiskohtien tarkka kuvaus Saumaton kommunikaatio ZWCAD -ohjelmointi Yhteensopiva ja stabiili Ylivertainen

Lisätiedot

Heikki Helin Metatiedot ja tiedostomuodot

Heikki Helin Metatiedot ja tiedostomuodot Heikki Helin 6.5.2013 Metatiedot ja tiedostomuodot KDK:n metatiedot ja tiedostomuodot KDK:n tekniset määritykset ja niiden väliset suhteet Aineistojen valmistelu ja paketointi on hyödyntäville organisaatioille

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

Ohjelmistoarkkitehtuurit. Syksy 2010 Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin

Lisätiedot

Haka-käyttäjien kokoontuminen Arto Tuomi CSC Tieteen tietotekniikan keskus

Haka-käyttäjien kokoontuminen Arto Tuomi CSC Tieteen tietotekniikan keskus Hakan teknisiä kuulumisia Haka-käyttäjien kokoontuminen 20.1.2009 Arto Tuomi CSC Tieteen tietotekniikan keskus SAML2 siirtymä 1.12.2008 Uudet Hakaan rekisteröitävät palvelut (SP) tukevat SAML 2.0 -tekniikkaa

Lisätiedot

10 Nykyaikainen WWW-arkkitehtuuri

10 Nykyaikainen WWW-arkkitehtuuri 10 Nykyaikainen WWW-arkkitehtuuri è è è 10 Nykyaikainen WWW-arkkitehtuuri WWW on ylivoimaisesti suosituin hypertekstijärjestelmä. Käydään seuraavaksi läpi nykyaikaisen WWW-arkkitehtuurin perusteet. Vuonna

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Projektin tavoitteet

Projektin tavoitteet VBE II, vaihe 1: 2005-2006 Data yrityksistä ja rakennushankkeista TUT Tekniset ratkaisut RAK (VRLab)+ARK iroom validointi Työpajat Seminaarit Esitelmät Osallistuvat yritykset VTT Käyttöönotto- ja hyötymallit,

Lisätiedot

Julkaisun laji Opinnäytetyö. Sivumäärä 43

Julkaisun laji Opinnäytetyö. Sivumäärä 43 OPINNÄYTETYÖN KUVAILULEHTI Tekijä(t) SUKUNIMI, Etunimi ISOVIITA, Ilari LEHTONEN, Joni PELTOKANGAS, Johanna Työn nimi Julkaisun laji Opinnäytetyö Sivumäärä 43 Luottamuksellisuus ( ) saakka Päivämäärä 12.08.2010

Lisätiedot

A Service-Oriented Architecture (SOA) View of IHE Profiles

A Service-Oriented Architecture (SOA) View of IHE Profiles A Service-Oriented Architecture (SOA) View of IHE Profiles HL7 IHE meeting 20.8.2009 Timo Itälä SoberIT, TKK Juha Mykkänen, KuY 2 SoberIT IHE ja SOA (palveluarkkitehtuuri) SOA (service-oriented architecture)

Lisätiedot

BaRE Käyttövalmis vaatimusmäärittelymenetelmä

BaRE Käyttövalmis vaatimusmäärittelymenetelmä BaRE Käyttövalmis vaatimusmäärittelymenetelmä Uolevi Nikula, Tietotekniikan osasto, LTKK, Uolevi.Nikula@lut.fi 13.11.2002 un/tsoft 1 Esityksen sisältö Jatko-opinnot Lisensiaatintutkimus BaRE menetelmä

Lisätiedot

Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen

Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen Yrjö Koivusalo tietohallintapäällikkö Varsinais-Suomen sairaanhoitopiiri Kansallinen vs. alueellinen arkkitehtuuri Onko yhteensovittaminen

Lisätiedot

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä $$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin

Lisätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö Case - HelpDesk Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot

Laajuus 5 op Luennot: 12 x 2t Harjoitukset: 7 viikkoharjoitusta harjoitusten tekemiseen saatavissa apua 2 ryhmää / harjoitus

Laajuus 5 op Luennot: 12 x 2t Harjoitukset: 7 viikkoharjoitusta harjoitusten tekemiseen saatavissa apua 2 ryhmää / harjoitus Laajuus 5 op Luennot: 12 x 2t 11.3.2014 29.4.2014 Harjoitukset: 7 viikkoharjoitusta harjoitusten tekemiseen saatavissa apua 2 ryhmää / harjoitus Lähiopetuksen jäkeen harjoitustyö ja tentti Aulikki Hyrskykari

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes SUOMEN KUNTAUITTO Sosiaali- ja terveysyksikkö TERVEYDENHUOLLON 27. ATK- PAIVAT 4. - 5.6.2001 Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes cncydcnhuollon

Lisätiedot

Käytettävyys verkko-opetuksessa Jussi Mantere

Käytettävyys verkko-opetuksessa Jussi Mantere Käytettävyys verkko-opetuksessa 21.8.2002 Jussi Mantere Mitä käytettävyys on? Learnability (opittavuus) Efficiency (tehokkuus) Memorability (muistettavuus) Errors prevented (virheiden tekeminen estetty)

Lisätiedot

Turvallinen etäkäyttö Aaltoyliopistossa

Turvallinen etäkäyttö Aaltoyliopistossa Turvallinen etäkäyttö Aaltoyliopistossa Diplomityöseminaari Ville Pursiainen Aalto-yliopiston tietotekniikkapalvelut Valvoja: Prof Patric Östergård, Ohjaajat: DI Jari Kotomäki, DI Tommi Saranpää 7.10.2016

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

Pilottipalvelun esittely johtopäätökset

Pilottipalvelun esittely johtopäätökset 1 Pilottipalvelun esittely johtopäätökset Paikkatiedot palveluväylässä -loppuseminaari Paikkatietoverkoston kevätseminaari 18.5.2016 Pekka Latvala, Jari Reini Pilottipalvelu Pilottipalvelun lähtöasetelmana

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

Avoin lähdekoodi hankinnoissa Juha Yrjölä

Avoin lähdekoodi hankinnoissa Juha Yrjölä Avoin lähdekoodi hankinnoissa 9.6.2016 Juha Yrjölä Mitä on avoin lähdekoodi? 1. Lähdekoodi tulee jakaa ohjelmiston mukana tai antaa saataville joko ilmaiseksi tai korkeintaan luovuttamiskulujen hinnalla.

Lisätiedot

Tietotekniikan Sovellusprojektit

Tietotekniikan Sovellusprojektit Tietotekniikan Sovellusprojektit Jukka-Pekka Santanen Tietotekniikan laitos 16.2.2010 Tavoitteena taitoja ja kokemusta projektimuotoisesta työtavasta ja ryhmätyöstä, projektin hallinnasta ja johtamisesta,

Lisätiedot

Langattomien verkkojen tietosuojapalvelut

Langattomien verkkojen tietosuojapalvelut Langattomien verkkojen tietosuojapalvelut Sisältö Työn tausta & tavoitteet Käytetty metodiikka Työn lähtökohdat IEEE 802.11 verkkojen tietoturva Keskeiset tulokset Demonstraatiojärjestelmä Oman työn osuus

Lisätiedot

TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ

TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ Liite TS2.4 Migraatiovaatimukset 1/10 VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 12.3.15 3.0 Tarjouspyynnön liitteeksi Hanketoimisto 2/10 SISÄLLYS

Lisätiedot

vakuutuslaitosten ja TAMLAn välillä

vakuutuslaitosten ja TAMLAn välillä Asioiden välittämien työeläkealan toimijoiden ja TELKin sekä vakuutuslaitosten ja TAMLAn välillä Työeläkealan XML-käytäntöjen soveltaminen Taustaa, tämän dokumentin tarkoitus Asioiden välittäminen tapahtuu

Lisätiedot

ALUETIETOJÄRJESTELMÄN KÄYTTÖKOKEMUKSET SATAKUNNASSA

ALUETIETOJÄRJESTELMÄN KÄYTTÖKOKEMUKSET SATAKUNNASSA ALUETIETOJÄRJESTELMÄN KÄYTTÖKOKEMUKSET SATAKUNNASSA Terttu Luojukoski Salpahankkeen projektipäällikkö Satakunnan sairaanhoitopiiri Salpahanke www.salpahanke.fi terttu.luojukoski@satshp.fi 044 707 7665

Lisätiedot

Trust Gamer Kit PCI TRUST GAMER KIT PCI. Pika-asennusohje. Versio 1.0

Trust Gamer Kit PCI TRUST GAMER KIT PCI. Pika-asennusohje. Versio 1.0 TRUST GAMER KIT PCI Pika-asennusohje Versio 1.0 1 1. Johdanto Tämä käyttöohje on tarkoitettu Trust Gamer Kit PCI -tuotteen käyttäjille. Tuotteen asentamisessa tarvitaan jonkin verran kokemusta tietokoneista.

Lisätiedot

Internet Protocol version 6. IPv6

Internet Protocol version 6. IPv6 Internet Protocol version 6 IPv6 IPv6 Osoiteavaruus 32-bittisestä 128-bittiseksi Otsikkokentässä vähemmän kenttiä Lisäominaisuuksien määritteleminen mahdollista Pakettien salaus ja autentikointi mahdollista

Lisätiedot

Kurssin hallinta -työväline

Kurssin hallinta -työväline Kurssin hallinta -työväline Kurssin hallinta -työvälineellä muokataan kursseja A&Ooppimisympäristöalustalla Kurssi koostuu - ohjelmasta (linkit työkaluihin& muihin resursseihin), - materiaaleista, - keskusteluryhmästä,

Lisätiedot

Cover letter and responses to reviewers

Cover letter and responses to reviewers Cover letter and responses to reviewers David E. Laaksonen, MD, PhD, MPH Department of Medicine Kuopio University Hospital Kuopio, Finland Luennon sisältö Peer review Vinkit vastineiden kirjoittamista

Lisätiedot

TULEVAISUUDEN KRIITTINEN VIESTINTÄ, TURVALLISUUS JA IHMISKESKEISET PALVELUT

TULEVAISUUDEN KRIITTINEN VIESTINTÄ, TURVALLISUUS JA IHMISKESKEISET PALVELUT TULEVAISUUDEN KRIITTINEN VIESTINTÄ, TURVALLISUUS JA IHMISKESKEISET PALVELUT Heli Ruokamo, KT Varadekaani, Professori, Kasvatustieteiden tiedekunta Johtaja, Mediapedagogiikkakeskus Lapin yliopisto Sairaalakirjastopäivät,

Lisätiedot

Kuntien Kansalliseen palveluarkkitehtuuriin liittyminen. Kunta-KaPA

Kuntien Kansalliseen palveluarkkitehtuuriin liittyminen. Kunta-KaPA Kuntien Kansalliseen palveluarkkitehtuuriin liittyminen Kunta-KaPA JUHTA 14.10.2015 Kunta-KaPA Kuntaliittoon on perustettu projektitoimisto, jonka tehtävänä on tukea ja edesauttaa Kansallisen Palveluarkkitehtuurin

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

Lisätiedot

Sisältö Tervetuloa Linuxin käyttäjäksi Olet tässä

Sisältö Tervetuloa Linuxin käyttäjäksi Olet tässä Sisältö 1 Tervetuloa Linuxin käyttäjäksi 1 1.1 Ympäristöasiaa...................................... 2 1.2 Juurta jaksaen...................................... 5 1.3 Lopetus..........................................

Lisätiedot

OTM-HANKKEEN SIDOSRYHMÄSEMINAARI

OTM-HANKKEEN SIDOSRYHMÄSEMINAARI OTM-HANKKEEN SIDOSRYHMÄSEMINAARI 27.4.2016 Päivän ohjelma 12:00 Avaus / Pekka Äikäs 12:30 Johdon katsaus / Kati Kettunen 12:45 Funidata Oy / Jorma Hänninen ja Mika Peura 13:45 Kahvi 14:15 Aallon käyttöönottoprojekti

Lisätiedot

Paikkatiedon kehittämisohjelma

Paikkatiedon kehittämisohjelma Paikkatiedon kehittämisohjelma 2011-2014 Toimeenpanon toteutumisen tilannekatsaus, siht. Outi Hermans Tiivistelmä Strategiset päämäärät Missio: Kaupungin tehtävänä on palvella kuntalaisiaan ja alueellaan

Lisätiedot

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy Käytännön haasteita ja ratkaisuja integraation toteutuksessa Jukka Jääheimo Teknologiajohtaja Solita Oy 13.03.2008 Sisältö 2 Alustus Integraation haasteet Integraatioarkkitehtuuri Hyvän integraatioarkkitehtuurin

Lisätiedot

Sisällönhallinnan menetelmiä

Sisällönhallinnan menetelmiä Sisällönhallinnan menetelmiä Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Suomalaisen lainsäädäntötyön tiedonhallinta: suuntana semanttinen web RASKE2-projektin loppuseminaari Eduskunnassa

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

Vapaat ohjelmat matkalla

Vapaat ohjelmat matkalla Vapaat ohjelmat matkalla Arto Teräs Finnish Linux User Group FLUG ry Teemailta Helsinki, 24.5.2010 Kalvo 1(14) Tietotekniikka (loma)matkalla Eihän lomalla tarvitse koskea tietokoneisiin.

Lisätiedot

SMART BUSINESS ARCHITECTURE

SMART BUSINESS ARCHITECTURE SMART BUSINESS ARCHITECTURE RAJATTOMAN VERKON ALUSTA Mihail Papazoglou, järjestelmäasiantuntija Agenda Markkinatrendit Miksi Smart Business Architecture? LAN Security Yhteenveto 2010 Cisco Systems, Inc.

Lisätiedot

.NET ajoympäristö. Juha Järvensivu 2007

.NET ajoympäristö. Juha Järvensivu 2007 .NET ajoympäristö Juha Järvensivu juha.jarvensivu@tut.fi 2007 Käännösprosessi C# lähdekoodi C# kääntäjä CILtavukoodi JITkäännös Ajettava natiivikoodi Kehitysympäristössä ohjelmoijan toimesta Ajonaikana.NET

Lisätiedot

OSI ja Protokollapino

OSI ja Protokollapino TCP/IP OSI ja Protokollapino OSI: Open Systems Interconnection OSI Malli TCP/IP hierarkia Protokollat 7 Sovelluskerros 6 Esitystapakerros Sovellus 5 Istuntokerros 4 Kuljetuskerros 3 Verkkokerros Linkkikerros

Lisätiedot

IPv6 käyttöönoton mahdollistajat operaattorin näkemys

IPv6 käyttöönoton mahdollistajat operaattorin näkemys IPv6 käyttöönoton mahdollistajat operaattorin näkemys Jyrki Soini TeliaSonera 1 IPv6 toimi nyt IPv4 osoitteet loppumassa hyvää vauhtia keskusvarasto (IANA) jakoi viimeiset osoitelohkot 3.2.2011 RIPE arvioi

Lisätiedot

arvioinnin kohde

arvioinnin kohde KEMIA 9-lk Merkitys, arvot ja asenteet T2 Oppilas tunnistaa omaa kemian osaamistaan, asettaa tavoitteita omalle työskentelylleen sekä työskentelee pitkäjänteisesti T3 Oppilas ymmärtää kemian osaamisen

Lisätiedot

Sairastuneiden ja omaisten kanssa keskusteleminen

Sairastuneiden ja omaisten kanssa keskusteleminen Infosheet 38 Sairastuneiden ja omaisten kanssa keskusteleminen Ymmärrettävä tieto Antamalla ihmisille tilaisuuden esittää kysymyksensä voit räätälöidä heidän tarpeisiinsa sopivaa tietoa. Jokaiseen keskusteluun

Lisätiedot

JULKISEN HALLINNON SÄHKÖISEN ASIOINNIN VIITEARKKITEHTUURI. Kuntaliitto Hannu Ojala Neuvotteleva virkamies/julkict

JULKISEN HALLINNON SÄHKÖISEN ASIOINNIN VIITEARKKITEHTUURI. Kuntaliitto Hannu Ojala Neuvotteleva virkamies/julkict JULKISEN HALLINNON SÄHKÖISEN ASIOINNIN VIITEARKKITEHTUURI Kuntaliitto 02.10.2012 Hannu Ojala Neuvotteleva virkamies/julkict Lähtökohdat Laaditaan kokonaisarkkitehtuuri tietylle sektorille, joka menee läpi

Lisätiedot