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

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot T-111.361 Hypermediadokumentin laatiminen -Ohjelmointi Peruskäsitys www-ohjelmoinnin kentästä Tekniikat interaktiivisuuden toteuttamiseen tekniikat tekniikat Tietokannat Juha Laitinen TKK/TML juha.laitinen@hut.fi

Lisätiedot

Verkottunut suunnittelu

Verkottunut suunnittelu Rintekno Oy / JMM / 10.1.2002 Verkottunut suunnittelu DOKUMENTTI- POHJAINEN Tarkastus ja hyväksyntä Automaattinen dokumenttien luonti MALLIPOHJAINEN 2D:SSÄ JA 3D:SSÄ Tarkastus ja hyväksyntä Virtuaaliset

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

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

Lisätiedot

HOJ J2EE & EJB & SOAP &...

HOJ J2EE & EJB & SOAP &... HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio

Lisätiedot

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj SUOMEN KUNTALIITTO Sosiaali- ja terveysyksikkö Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj ~ (operatiiviset-/tiedonjakelu-/si~llönhallinta~velluk~et)

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

TIETOKONEYLIASENTAJAN ERIKOISAMMATTITUTKINTO

TIETOKONEYLIASENTAJAN ERIKOISAMMATTITUTKINTO TIETOKONEYLIASENTAJAN ERIKOISAMMATTITUTKINTO TEHTÄVÄ 2: Symantec Endpoint Protection Manager, SEPM keskitetyn tietoturva hallintaohjelmiston asennus, sekä vaadittavien palveluiden/roolien käyttöönottaminen

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,

Lisätiedot

Tietojärjestelmäarkkitehtuurit

Tietojärjestelmäarkkitehtuurit Tietojärjestelmäarkkitehtuurit ITK130 Johdatus ohjelmistotekniikkaan Syksy 2003 Sami Kollanus 1 Aluksi Tietojärjestelmäarkkitehtuurit vs. ohjelmistoarkkitehtuurit Pohjana Tietojärjestelmäarkkitehtuurit

Lisätiedot

HSMT J2EE & EJB & SOAP &...

HSMT J2EE & EJB & SOAP &... HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Työpöytävirtualisointi

Työpöytävirtualisointi Työpöytävirtualisointi VMware View LIPO - SAMK Liiketoiminta ja kulttuuri Pori Liiketalouden, matkailun, tietojenkäsittelyn, viestinnän ja yrittäjyyden ja liiketoimintaosaamisen koulutusta. Käyttäjiä noin

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin TEKNILLINEN KORKEAKOULU / VAASAN YLIOPISTO Diplomityöesitelmä Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin Timo Ahola 2006 Web sovellus Web palvelut joiden avulla laite voidaan liittää

Lisätiedot

Terveydenhuollon Atk-päivät 2009

Terveydenhuollon Atk-päivät 2009 Terveydenhuollon Atk-päivät 2009 26. 27.5.2009, Jyväskylä Mika Kolhinoja Teknologiakonsultti Citrix CCA, Citrix CCEA, Citrix CCSP, Microsoft MCP, Microsoft MCSA, Microsoft MCSE, Microsoft MCTS, Microsoft

Lisätiedot

Vuorekseen liittyvä tutkimusja kehitysprojekti. Langaton Vuores. Kotikatupalvelin

Vuorekseen liittyvä tutkimusja kehitysprojekti. Langaton Vuores. Kotikatupalvelin Vuorekseen liittyvä tutkimusja kehitysprojekti Langaton Vuores Kotikatupalvelin Tutkimuksen tausta Langaton tietoliikenne on arkipäivää Personoidut päätelaitteet (taskutietokone, matkapuhelin, kannettava

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

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

Paikkatiedot ja Web-standardit

Paikkatiedot ja Web-standardit Paikkatiedot ja Web-standardit Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: World Wide

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

HTTP-välityspalvelimen käyttö tapahtumien keräämiseen

HTTP-välityspalvelimen käyttö tapahtumien keräämiseen HTTP-välityspalvelimen käyttö tapahtumien keräämiseen Tero Tähtinen Teknillinen korkeakoulu Tietoliikenneohjelmistojen ja multimedian laboratorio Diplomityöesitelmä 29.11.2004 1 Johdanto Diplomityössä

Lisätiedot

Ohje Hosted.fi SharePoint

Ohje Hosted.fi SharePoint Ohje Hosted.fi SharePoint Käyttöönotto 09.05.2011 Anvia Hosting Oy Urho Kekkosen katu 4-6 A 00100 Helsinki Puhelin 0207 7682 00 Fax 0207 7682 01 Y-tunnus 1666661-6 Kotipaikka: Helsinki www.anvia.fi Dokumentin

Lisätiedot

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 SISÄLLYS 1 JOHDANTO 3 2 WWW-PALVELIMEN TOIMINTA 4 3 OMINAISUUDET

Lisätiedot

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Terveydenhuollon 29. ATK-päivät Jyväskylä 25-27.5.2003 Verkostoitumisen

Lisätiedot

SAP. Lasse Metso 14.1.2011

SAP. Lasse Metso 14.1.2011 SAP Lasse Metso 14.1.2011 Toiminnanohjausjärjestelmä engl. Enterprise Resource Planning, ERP Integroitu tietojärjestelmä joka palvelee kaikkia yrityksen osastoja. Tuotantoyrityksistä liikkeelle lähtenyt

Lisätiedot

.NET 2006 ja sen jälkeen

.NET 2006 ja sen jälkeen .NET 2006 ja sen jälkeen Ahti Haukilehto FC Sovelto Oyj Microsoft Regional Director, Finland Superior tools, niin mitkä? Visual Studio Team System Team Foundation Server DSL Tools 2 Visual Studio Team

Lisätiedot

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000 Case TUHTI 17.12.2002 1 TietoEnator 2002 Projektin tunnuslukuja! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999! Otettu tuotantokäyttöön syksyllä 2001! Proof of Concept (5 henkilöä 4 kk) ->

Lisätiedot

Älykästä. kulunvalvontaa. toimii asiakkaan omassa tietoverkossa

Älykästä. kulunvalvontaa. toimii asiakkaan omassa tietoverkossa Älykästä kulunvalvontaa e Acces toimii asiakkaan omassa tietoverkossa Perinteisen kulunvalvonnan seitsemän pullonkaulaa eli miksi useat yritykset eivät ole hankkineet kulunvalvontajärjestelmää? 1. Koska

Lisätiedot

KODAK EIM & RIM VIParchive Ratkaisut

KODAK EIM & RIM VIParchive Ratkaisut ATK Päivät 2006 Mikkeli KODAK EIM & RIM VIParchive Ratkaisut 29.-30.5. 2006 Stefan Lindqvist HCIS Sales Specialist Health Care Information Systems Kodak Health Group 3/24/2013 1 Arkistoinnin haasteita

Lisätiedot

Liiketoimintajärjestelmien integrointi

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

Lisätiedot

WWW-ohjelmoinnin kokonaisuus. WWW-OHJELMOINTI 1 Merkkauskielet. Merkkauskielten idea. Merkkauskielet (markup languages) Merkkauskielten merkitys

WWW-ohjelmoinnin kokonaisuus. WWW-OHJELMOINTI 1 Merkkauskielet. Merkkauskielten idea. Merkkauskielet (markup languages) Merkkauskielten merkitys WWW-OHJELMOINTI 1 WWW-ohjelmoinnin kokonaisuus SGML, XML, HTML WWW-selaimen sovellusohjelmointi WWW-palvelimen sovellusohjelmointi Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 26.10.2000

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.4.0

Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.4.0 Toukokuu 2014 1 (11) Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.4.0 Päivitysohje Toukokuu 2014 2 (11) Sisällysluettelo 1. Tehtävät ennen versiopäivitystä... 3 1.1. Ohjelmistomuutosten luku...

Lisätiedot

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen Tietojärjestelmä tuotantoympäristössä Tausta ja tavoitteet Tausta Kurssilla on opiskeltu suunnittelemaan ja toteuttamaan tietokanta, joka on pieni perustuu selkeisiin vaatimuksiin on (yleensä) yhden samanaikaisen

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013 Virtualisointi Pertti Pennanen DOKUMENTTI 1 (5) SISÄLLYSLUETTELO Virtualisointi... 2 Virtualisointiohjelmia... 2 Virtualisointitapoja... 2 Verkkovirtualisointi... 2 Pertti Pennanen DOKUMENTTI 2 (5) Virtualisointi

Lisätiedot

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:

Lisätiedot

Tuotantokoneen langaton etädiagnostiikka

Tuotantokoneen langaton etädiagnostiikka Tuotantokoneen langaton etädiagnostiikka Esa Salminen esa@ac.tut.fi Jari Seppälä Puh. (03) 3115 2967, telefax (03) 3115 2340, jari.seppala@tut.fi Mikko Salmenperä Puh. (03) 3115 4203, telefax (03) 3115

Lisätiedot

Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.3.0

Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.3.0 Toukokuu 2013 1 (10) Tikon Ostolaskujenkäsittely/Web-myyntilaskutus versio 6.3.0 Päivitysohje Copyright Aditro 2013 Toukokuu 2013 2 (10) Sisällysluettelo 1. Tehtävät ennen versiopäivitystä... 3 1.1. Ohjelmistomuutosten

Lisätiedot

Tekninen suunnitelma - StatbeatMOBILE

Tekninen suunnitelma - StatbeatMOBILE Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in

Lisätiedot

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy Esityksen sisältö Mermit yrityksenä Perustiedot Toimintamalli Mermit työpaikkana ohjelmistoinsinöörille Esimerkkiprojekti

Lisätiedot

Mikä on internet, miten se toimii? Mauri Heinonen

Mikä on internet, miten se toimii? Mauri Heinonen Mikä on internet, miten se toimii? Mauri Heinonen Mikä on Internet? Verkkojen verkko Muodostettu liittämällä lukuisia aliverkkoja suuremmaksi verkoksi Sivustojen tekemiseen käytetään kuvauskielta HTML

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Työasemien hallinta Microsoft System Center Configuration Manager 2007. Jarno Mäki Head of Training Operations M.Eng, MCT, MCSE:Security, MCTS

Työasemien hallinta Microsoft System Center Configuration Manager 2007. Jarno Mäki Head of Training Operations M.Eng, MCT, MCSE:Security, MCTS Työasemien hallinta Microsoft System Center Configuration Jarno Mäki Head of Training Operations M.Eng, MCT, MCSE:Security, MCTS IT Education Center Agenda Yleistä työasemien hallinnasta Työasemien hallinta

Lisätiedot

GroupDesk Toiminnallinen määrittely

GroupDesk Toiminnallinen määrittely GroupDesk Toiminnallinen määrittely Tilanne: Paikallinen oppilaitos, kuvitteellinen WAMK, tarvitsee ryhmätyöhön soveltuvan sähköisen asioiden hallintajärjestelmän ja ryhmätyöohjelmiston, jonka ajatuksena

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Suomen avoimien tietojärjestelmien keskus COSS ry Avoimen ohjelmistoliiketoimintaverkoston ja -yhteistyön koordinoija Ilkka Lehtinen Matti Saastamoinen Avoimuus ja vapaus - Pieni tulipalo v. 1492 mahdollisti

Lisätiedot

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen

Lisätiedot

Web Service torilla tavataan!

Web Service torilla tavataan! Web Service torilla tavataan! Jari Putula Avarea Oy COPYRIGHT BY AVAREA 2009 1 Google Trends COPYRIGHT BY AVAREA 2009 2 1 1. Mahdollistajat 2. Web service? 3. KISS 4. Miksi? 5. Analogia 6. Ajax 7. Esimerkki

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Maiju Mykkänen (D6297@jamk.fi) Susanna Sällinen (E0941@jamk.fi)

Maiju Mykkänen (D6297@jamk.fi) Susanna Sällinen (E0941@jamk.fi) Maiju Mykkänen (D6297@jamk.fi) Susanna Sällinen (E0941@jamk.fi) Tietokannan hallinta-opintojakson selvitysraportti Huhtikuu 2010 Mediatekniikka ICT/Teknologia Tämän teosteoksen käyttöoikeutta koskee Creative

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

dyntäminen rakennusautomaatiossa Jussi Rantanen Myyntipää äällikkö Fidelix Oy

dyntäminen rakennusautomaatiossa Jussi Rantanen Myyntipää äällikkö Fidelix Oy Internet -tekniikan hyödynt dyntäminen rakennusautomaatiossa Jussi Rantanen Myyntipää äällikkö Fidelix Oy Internet rakennusautomaatiossa Mahdollisuus avoimempaan rakennusautomaation hankintaan ja käyttöön

Lisätiedot

Tulevaisuuden päätelaitteet

Tulevaisuuden päätelaitteet Tulevaisuuden päätelaitteet Kuka ne omistaa? Miten niitä hallitaan? Aki Antman Sulava Oy 2.11.2011 Agenda Alkusanat ja puhujan lyhyt esittely Erilaiset päätteet ja sähköinen työpöytä Kuka omistaa päätelaitteet?

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Aditro Tikon ostolaskujen käsittely versio 6.2.0

Aditro Tikon ostolaskujen käsittely versio 6.2.0 Lokakuu 2012 1 (9) Aditro versio 6.2.0 Päivitysohje Lokakuu 2012 2 (9) Sisällysluettelo 1. Tehtävät ennen versiopäivitystä... 3 1.1. Ohjelmistomuutosten luku... 3 1.2. Aditro Pankkipalvelut yhteensopiva

Lisätiedot

Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä

Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä PROJEKTIJOHTAMINEN OY RISTO PELIN 3 Sisällysluettelo ESIPUHE 7 OSA I PROJEKTIN HALLINTA PROJEKTITASOLLA 1 JOHDANTO 11 1.1 Projektiohjelmien

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

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

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit Esimerkki arkkitehtuurit Sivu 2/8 Sisällysluettelo 1. Johdanto... 3 1.1. Termejä... 3 2. Web hosting ilman kuormantasausta... 4 3. Web hosting kuormatasaus ja bastion... 5 3.1.... 5 3.2. Kuvaus... 5 4.

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

Aurinkoenergiajärjestelmien etäseurantajärjestelmä

Aurinkoenergiajärjestelmien etäseurantajärjestelmä Aurinkoenergiajärjestelmien etäseurantajärjestelmä Janne Raitaniemi (Bitec Oy) Saku Rantamäki (SAMK) Aurinkoenergiajärjestelmien luonne järjestelmien odotettu elinkaari on pitkä investoinnin kannattavuus

Lisätiedot

Directory Information Tree

Directory Information Tree IP-osoite / Host taulu, jossa neljä 8 bit lukua esim. 192.168.0.10/24, unix, linux, windows windows\system32\drivers\etc DNS (Domain Name System), muuttaa verkkotunnuksen IPosoitteeksi. X.500 perustuu

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,

Lisätiedot

Ylläpito-ohje. Matematiikan oppifoorumi. Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen. Ohjaaja.

Ylläpito-ohje. Matematiikan oppifoorumi. Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen. Ohjaaja. Matematiikan oppifoorumi Ylläpito-ohje Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen Ohjaaja Jukka Eskola Ohjelmistotuotantoprojekti 17.12.1999 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen

Lisätiedot

TIETOTEKNIIKAN KOULUTUSOHJELMA

TIETOTEKNIIKAN KOULUTUSOHJELMA TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,

Lisätiedot

Vain testaamalla voit voittaa! Markku Selin Kehitysjohtaja

Vain testaamalla voit voittaa! Markku Selin Kehitysjohtaja Vain testaamalla voit voittaa! Markku Selin Kehitysjohtaja Lyhyesti: Suomessa ja Baltiassa Liikevaihto 29,25 (noin 50) milj. Euroa Henkilöstöä Suomessa 46 (115) Juuret vuonna 1989 perustetussa Santa Monica

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

Tiistai 19.5, Sessio B o 09.00-09.45. Potilashallinnon tietojarjestelmat Suomessa KATKO: n tietojarjestelmakartoituksen tuloksia

Tiistai 19.5, Sessio B o 09.00-09.45. Potilashallinnon tietojarjestelmat Suomessa KATKO: n tietojarjestelmakartoituksen tuloksia Terveydenhuollon XVIII Atk-päivät 18-19.5.1992 Luentoesitelmät Tiistai 19.5, Sessio B o 09.00-09.45 Potilashallinnon tietojarjestelmat Suomessa KATKO: n tietojarjestelmakartoituksen tuloksia Juha Lång,

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

Testidatan generointi

Testidatan generointi Testidatan generointi Anu Ahonen Kevät 2008 Tämä työ on tehty Creative Commons -lisenssin alla Työn tarkasti 9.4.2008 Jouni Huotari (JAMK/IT) 1 SISÄLTÖ 1 TYÖN LÄHTÖKOHDAT JA TOTEUTUS...2 2 TESTIDATAN GENEROINTI

Lisätiedot

Verkkopalveluiden saavutettavuus

Verkkopalveluiden saavutettavuus Verkkopalveluiden saavutettavuus Puhuja: Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Paikka: Helsinki, Tieteiden talo, 24.3.2011 Johdanto Verkkopalvelun saavutettavuus

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

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

Tikon Ostolaskujenkäsittely versio 6.1.2 SP1

Tikon Ostolaskujenkäsittely versio 6.1.2 SP1 Toukokuu 2012 1 (14) Tikon Ostolaskujenkäsittely versio 6.1.2 SP1 Asennusohje Toukokuu 2012 2 (14) Sisällysluettelo 1. Vaatimukset palvelimelle... 3 1.1..NET Framework 4.0... 3 1.2. Palvelimen Internet

Lisätiedot

YTHS Raportointijärjestelmähankkeen

YTHS Raportointijärjestelmähankkeen 1 (11) YTHS Raportointijärjestelmähankkeen tarvemäärittely Periaatetason arkkitehtuurin ja ratkaisun kartoitus 2 (11) Sisällysluettelo 1. ALUSTUS... 3 2. JÄRJESTELMÄARKKITEHTUURI... 3 2.1. ETL PROSESSI...

Lisätiedot

Hyödynnä DPS- ja SA-setelit Azure hybridipilvi-palveluiden suunnittelussa ja testauksessa!

Hyödynnä DPS- ja SA-setelit Azure hybridipilvi-palveluiden suunnittelussa ja testauksessa! Hyödynnä DPS- ja SA-setelit Azure hybridipilvi-palveluiden suunnittelussa ja testauksessa! Onregon DPS-työpajat ovat Microsoft Enterprise Agreement asiakkaille sopivia työpajoja, joiden maksamiseen voi

Lisätiedot

Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä?

Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä? Se edullisempi tietokanta Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä? Rasmus Johansson rasmus.johansson@microsoft.com Ratkaisumyyntipäällikkö (Sovellusalusta) Microsoft Oy Miten

Lisätiedot

Forrester: tietohallinnon prioriteetit

Forrester: tietohallinnon prioriteetit Forrester: tietohallinnon prioriteetit Kustannusten hallinta Tuottavuuden kasvattaminen Turvallisuuden parantaminen Forrester: tietohallinnon prioriteetit Liiketoiminnan tärkeimmät tehtävät Kustannusten

Lisätiedot

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003 HELSINKI AREA TESTBED Martti Mäntylä, HIIT 12.3.2003 Pääkaupunkiseudun innovaatioympäristö Pääkaupunkiseudulla hyvät lähtökohdat uusien ICTyritysten syntymiseen Innovaatioympäristöä täytyy kehittää edelleen:

Lisätiedot

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?

Lisätiedot

VisualStudio Pikaopas, osa 1: WEB sivujen suunnittelu

VisualStudio Pikaopas, osa 1: WEB sivujen suunnittelu HAAGA HELIA/IltaTiko ICT2TD005: Ohjelmisto suunnittelutaito 1 VisualStudio Pikaopas, osa 1: WEB sivujen suunnittelu Tämä pikaopas opastaa käyttämään VisualStudion web sivujen suunnittelu ja toteutusominaisuuksia.

Lisätiedot

Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä:

Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä: Linux-harjoitus 6 Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä: http://www.mysql.com/, MySQL-tietokantaohjelman kotisivu. http://www.mysql.com/doc/en/index.html,

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2008

Ohjelmistoarkkitehtuurit. Syksy 2008 Ohjelmistoarkkitehtuurit Syksy 2008 Kai Koskimies 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto, Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto, Vaasan yliopisto, Tampereen teknillinen

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot