PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen

Koko: px
Aloita esitys sivulta:

Download "PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen"

Transkriptio

1 PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen LUONNOS Johtoryhmälle

2 2 Sisällys 1 Johdanto Integrointiprosessi Määrittelydokumentit Integrointivaatimukset Toiminnallinen liittymämäärittely Tekninen liittymämäärittely Liittymän toteutuksen kuvaus Määrittelyjen hyväksyminen ja julkistaminen...11 Muutoshistoria: Ensimmäinen koottu ja kommentoitu luonnos, Juha Mykkänen, Juha Rannanheimo, Tomi Tikkanen / PlugIT Lisäkommenttien perusteella korjattu luonnos, Juha Mykkänen / PlugIT Työpajaseminaarin ja muiden kommenttien perusteella korjattu luonnos, Juha Mykkänen, Juha Rannanheimo, Tomi Tikkanen / PlugIT Ohjaajien kommenttien perusteella korjattu luonnos johtoryhmälle, Juha Mykkänen / PlugIT 2

3 3 1 Johdanto Tässä dokumentissa käsiteltäviä aiheita ovat integroinnin määrittelyprosessi sekä PlugIT-projektissa tuotettavien määrittelydokumenttien tuottaminen, julkaisu ja hyväksyminen. Tämä dokumentti kuvaa: 1. Mitä dokumentteja määrittelytyössä tuotetaan, 2. Miten dokumentit tuotetaan (ja miten projekti tukee niiden tuottamista), 3. Kuinka tehdyt määritykset hyväksytään ja levitetään. Tämän dokumentin lähteinä on käytetty soveltuvin osin integrointi- ja sovelluskehitysprosessia koskevaa kirjallisuutta sekä kehitetty uutta sovellusintegraation teoriaa, joita tässä pyritään soveltamaan käytäntöön ja keventämään käytännönläheisemmäksi projektin käyttöön soveltuvaksi menetelmäksi, joka ei vaadi erikoistuneiden välineiden käyttöä. Käytettyjä lähteitä ovat mm. Rational Unified Process RUP, OMG:n Model Driven Architecture MDA, ISO:n RM-ODP-malli, OMG:n standardointiprosessi, Integrating Healthcare Enterprise (IHE) -määritykset sekä projektin ja ulkopuolisten tutkijoiden tieteelliset artikkelit ja kirjat (dokumentin lopussa on viitteitä taustamateriaaliin). Tärkeä perusta dokumentille ovat myös eri yritysten ja terveydenhuollon organisaatioiden kanssa käydyt keskustelut. Myös projektissa jo tehdyn integroinnin toteutustyön dokumentaatiota sekä eri yritysten luovuttamia integraatiodokumentteja on käytetty pohjana. Dokumenttia ylläpidetään ja kehitetään edelleen ja siihen toivotaan kommentteja. Dokumentissa kuvattujen käytäntöjen arvioinnin tuloksia pyritään keräämään dokumentin käyttäjiltä. Uusin versio dokumentista on saatavilla projektin osapuolille sisäisten web-sivujen kautta. Kommentteja ja mielipiteitä voi lähettää esim. osoitteisiin Myös projektin sähköpostilistoilla voi keskustella dokumenttia koskevista asioista. 2 Integrointiprosessi Integrointiprosessi kuvaa kuinka määrittelydokumentit tuotetaan sekä yleisesti (integrointimenetelmä) että erityisesti PlugIT-projektissa (projektikohtaiset käytännöt). Määrittelydokumenttien sisältöä käsitellään tarkemmin luvussa 3. PlugIT-projektin integrointiprosessin tavoitteita: Määrittelyissä pyritään "kolmikantayhteistyöhön": projektihenkilöt, th. organisaatiot ja yritys tai useita yrityksiä työstää määrittelyitä. Eri osapuolten näkökulmat yritetään aktiivisesti saada mukaan määrittelyihin. Määrittelyjen tuottamisen "keveys": on oltava helppoa saattaa prosessi alkuun ja tuottaa tuloksia. Eri vaiheissa voidaan "haarautua" tarkempaan määrittelyyn tai toteutukseen jollain osa-alueella. 3

4 4 Prosessiin on voitava tuoda "valmiiksi" yrityksissä tai terveydenhuollon organisaatioissa tehtyjä yhteentoimivuuden määrittelyitä (bottom-up) tai tuottaa toimintaprosessilähtöisen mallintamisen kautta uusia määrityksiä (topdown) tunnistettuihin integraatiotarpeisiin. Molemmissa määrittelyjen tuottamistavoissa pyritään yleistämään tuotettavia määrityksiä siten, että tuotokset ovat yleiskäyttöisiä, eivät tuotekohtaisia tai vain yhden yksikön toimintaprosessiin sidottuja. Tuotettavat määritykset ovat yleisten ja tilanteeseen soveltuvien standardien mukaisia sekä projektin sisällä eri integrointitarpeissa toisiaan tukevia. Sairaala tai muu th. organisaatio -substanssiosaaminen -pilotointikohde -käytetyt tekniikat -laatuvaatimukset PlugIT Prosessin kehittäminen -luettelo integraatiotarpeista -ohjeet määrittelyjen tekemiseen -sisältömäärittelyt määrittelydokumenteille -esimerkkejä määrittelyistä eri tyyppisiin integrointitilanteisiin -malliratkaisuja -toteutusvälineitä Projektisuunnitelma Ohjelmistoyritys Integraatiotarve Vaatimusmäärittely määrittelytyö -valmiita määrittelyitä -pilotointi -olemassa olevat tekniikat -oma laatu- ja tuotantoprosessi 1. INTEGRAATIO- VAATIMUKSET -tehdyn työn dokumentointi -arviointi -prosessin kehittäminen -yleistäminen -menetelmän validointi Liittymän määrittely Pilotointi määrittelytyö määrittely- ja toteutustyö 2. TOIMINNALLINEN LIITTYMÄ- MÄÄRITTELY 3. TEKNINEN LIITTYMÄ- MÄÄRITTELY 4. LIITTYMÄN TOTEUTUKSEN KUVAUS -tulokset Hyväksyntä -soveltaminen Kuva 1. Integraatiomäärittelyjen tuottaminen ja pilotointi PlugIT-projektissa. Tavoitteena on, että tämä osa (tai pikemminkin erillinen integrointiopas) kehittyy, kasvaa ja elää projektin edetessä. Projektissa tuotetaan eri vaiheisiin tarkalla tasolla ohjeita ja menettelytapoja, kuinka eri dokumentit sekä toteutukset valituilla tekniikoilla saadaan aikaan yhteistyössä eri osapuolten kanssa. Määrittelyjen tekemisen tarkka prosessi riippuu aina mukana olevien yritysten toiminta- ja laatukäytännöistä ja yksittäisten henkilöiden osaamisesta ja henkilökohtaisista preferensseistä, joten tämän dokumentin tässä osassa pyritään kuvaamaan vain yleiset pelisäännöt, joilla PlugIT-projektissa pyritään avointen liittymien määrittelyihin ja toteutuksiin. 4

5 5 Liittymän määrittely on yksi osa koko integrointiprosessia. Projektin osapuolet tuovat esiin integrointitarpeita, joiden perusteella päätetään mille tarpeille projektissa lähdetään määrittelyjä ja toteutuksia tekemään. Valituista integraatiotarpeista tuotetaan luvussa 3 kuvattavia dokumentteja, ja määrittelytyön jälkeen voidaan siirtyä liittymien toteutukseen. Vaiheet: Määrittelytyön aihe tulee joltakin projektin osapuolelta (sairaala/yritys), ja tiettyyn integrointitarpeeseen liittyvien osapuolten tunnistaminen ja mukanaolo on tavoitteena prosessin alusta lähtien. PlugIT-projektissa on tuotettu tärkeimpien tunnistettujen integrointitarpeiden luettelo. Valitaan koollekutsuja / vetäjä (projektista) ja alustavat osallistujat kirjataan. Kultakin osallistuvalta osapuolelta on yksi vastuuhenkilö mukana ("oikeat henkilöt mukaan"). Aihe ja alustava rajaus sekä mukana olevat osapuolet ilmoitetaan PlugITyhteys -listalla ja web-sivuilla. Muut osapuolet voivat ilmoittaa vetäjälle kiinnostuksensa tai osallistumishalunsa tehtävään määrittelyyn. Määrittely- (ja toteutus-, käyttöönotto-, testaus-) työstä tehdään projektisuunnitelma, joka on saatavilla projektin osapuolille o Projektisuunnitelman muoto määritellään tapauskohtaisesti, mutta sen tulisi sisältää suunnitelma rajauksesta, resursoinnista ja aikataulusta sekä tarvittaessa kuvaus muiden hankkeiden hyödynnettävistä tai niille tarjottavista tuotoksista. Määrittelyssä tuotetaan dokumentteja (luonnos), jotka sisältävät "Määrittelydokumentit" -luvun mukaiset asiat. Ensin voidaan tuottaa Integrointivaatimukset ja sitten muita dokumentteja, tai useita määrittelydokumentteja voidaan tuottaa kerralla. Jos osapuolia on useita, ne voivat tuottaa omia tai yhteisiä luonnoksia. Osapuolten yhteiset luonnokset ovat etusijalla. Projektin osapuolen aikaisemmin tekemä määrittely voidaan tuoda prosessiin luonnoksena. Määrittelyjen tuottamisessa voidaan seurata määriteltyä integrointiprosessia (Mykkänen, Porrasmaa ja Korpela, 2002): o Toiminnan ja sen kehittämisen vaatimukset otetaan huomioon. o Olemassa olevat järjestelmät otetaan huomioon toiminnallisuuden, arkkitehtuurin ja jo käytettyjen tekniikoiden osalta. o Toiminnalliset ja tekniset standardit otetaan huomioon. o Uusien tekniikoiden ja välineiden mahdollisuudet otetaan huomioon 5

6 6 -integrointivaatimukset -sovellusarkkitehtuuri -olemassaolevien sovellusten toiminnallisuus -sovellusten alusta 1. Kohdealueen analysointi 2.Sovellusarkkitehtuurin tunnistaminen 3. Olemassaolevien sovellusten tekniikoiden tunnistaminen 1. INTEGRAATIO- VAATIMUKSET standardit -toiminnalliset integrointipisteet -integrointipisteet kohdearkkitehtuurissa -semanttiset vaatimukset 4. Toiminnallisten liittymien tunnistaminen -teknologiariippumattomat liittymät 5. Liittymätekniikoiden valinta -olemassaoleva tekninen infrastruktuuri -tekniset standardit -uudet metodit, työkalut and teknologiat -uusi sovellusinfrastruktuuri -integrointiteknologiat 2. TOIMINNALLINEN LIITTYMÄ- MÄÄRITTELY 6. Liittymien määrittely 3. TEKNINEN LIITTYMÄ- MÄÄRITTELY -tekniset liittymät 7. Käytettävien teknologioiden valinta Kuva 2. Integrointimäärittelyjen tekeminen (liittymän määrittely). Määrittelyjen tuottamista tukemaan tarvitaan PlugIT-projektista: Selville saatujen integrointitarpeiden alustava luettelo Integration guidelines: ohjeet määrittelyjen tekemiseen Sisältömäärittelyn ohjeet eri määrittelydokumenteille (tavoitteena saada samoista dokumenteista tehtyjen toteutusten variaatiot määriteltyjen asioiden suhteen mahdollisimman pieniksi tai vähintäänkin dokumentoiduiksi) Määrittelydokumenttien tarkistuslista, näin dokumenttini on sellainen kuin pitääkin Esimerkkejä eri määrittelydokumenteista eri tyyppisiin integrointitilanteisiin, eri tekniikoille jne. Kartoitusta eri standardien kattamista alueista Jo tehtyjen ja käytettyjen määritysten varasto (ei samoja osia useilla tavoilla) Tietoa käytettävissä olevista kansallisista tai kv. luokituksista Koulutusta esim. puolivuotisseminaarien yhteydessä Vähitellen malliratkaisuja ja toteutusvälineitä ohjeineen (mahdollisimman paljon jo valmiiksi saatavilla olevia). Tukea tehtyjen määrittelyjen arviointiin ja tarkastukseen. Tukea eri osapuolten valmiiden määrittelyjen yleistämiseen prosessia varten. Tukea määrittelydokumenttien katselmointiin Tukea sovellusten määrittelyjen mukaisuuden testaamiseen 3 Määrittelydokumentit Tavoitteet: Määrittelyissä pyritään konkreettiselle tasolle: määrittelyn mukainen järjestelmien välinen liittymä pyritään toteuttamaan saatavilla olevien ohjelmistotuotteiden liittymäksi. 6

7 7 Yhteentoimivuuden toteuttamiseksi riittävän kattavien asioiden dokumentointi, mutta vain tarpeellinen määrä, jotta määritykset ovat suhteellisen kevyesti toteutettavissa. (tarkoituksenmukaisuus) Helppo liikkeellelähtö, asteittainen tarkennus teknistä toteutusta kohti Selkeiden mallien tarjoaminen määrittelydokumenteille Toteutuskohtaisten asioiden erottaminen liittymään liittyvistä asioista, vain tarpeellisten toteutuskohtaisten yksityiskohtien paljastaminen. Osapuolten omien laatuvaatimusten ja -järjestelmien huomiointi Tuotettavat määrittelydokumentit: 1. Integrointivaatimukset 2. Toiminnallinen liittymämäärittely 3. Tekninen liittymämäärittely 4. Liittymän toteutuksen kuvaus Tässä luvussa kuvataan määrittelydokumentteja, jotka ovat projektin pysyväluonteisia tuotoksia. Seuraavassa käsitellään kunkin määrittelydokumentin sisältöä tarkemmin. Näiden dokumenttien lisäksi voidaan tuottaa muita dokumentteja, esim. projektisuunnitelmia määrittelyjen toteutusta varten. Yleisiä dokumentointitapoja määrittelydokumenteissa: Järjestelmistä puhutaan yleisnimillä, ei erisnimillä, mutta esimerkkeinä käytetään nimeltä mainittuja järjestelmiä. Esimerkki: Patologian järjestelmä (esim. Qpati), potilashallinnon ydinjärjestelmä (esim. Musti). Dokumenteissa esitetään perustelut tehdyille valinnoille. Dokumenteissa kuvataan minimitaso ja kuvataan mitä ominaisuuksia minimitason (ja tarvittaessa muiden edistyneempien tai laajempien tasojen) mukainen järjestelmä toteuttaa. Määrittelydokumenttien uusissa versioissa on mahdollista tuottaa edistyneempiä tasoja olemassa oleviin määrityksiin. Dokumenteissa näkyvät dokumentin tuottamiseen osallistuneet tahot. Dokumentissa on versionumero. Viittaukset ylemmän tason dokumentteihin tehdään dokumentin nimen ja versionumeron (luonnoksissa voidaan käyttää päivämäärää versionumeron lisäksi) avulla. Integraatioprosessin eri vaiheissa syntyvät määrittelydokumentit voidaan PlugIT-projektissa hyväksyä (ks. luku 4). Ne voidaan myös tuoda julkisesti (muidenkin kuin projektin osapuolten) saataville johtoryhmän päätöksellä projektin aikana. Dokumentit ja kommentoitavaksi tuodut luonnokset ovat kaikkien projektin osapuolten saatavilla projektin web-sivujen kautta. 3.1 Integrointivaatimukset Integrointivaatimukset on pohjadokumentti, johon perustuvat myöhemmin tuotettavat dokumentit. Vaatimusdokumentti voi kattaa laajankin alueen vaatimuksia, josta valitaan tarvittaessa pienempi osa-alue kerrallaan jatkomäärittelyjä ja toteutusta varten. Integrointivaatimukset-dokumentti tehdään loppukäyttäjien ja integroinnin suunnittelijoiden ja toteuttajien yhteiseksi tavoitemäärittelyksi, joka on huomioitava 7

8 8 kirjoitettaessa (esim. välttämällä teknisiä yksityiskohtia ja määrittelemällä mahdollisesti sekaannusta aiheuttavat terveydenhuollon käsitteet). Tietyssä integrointitilanteessa voidaan pysähtyä jo vaatimusten kartoituksen jälkeen, jos toteutukseen tai jatkosuunnitteluun ei löydy toteuttajaa tai priorisoidaan toisten vaatimusten toteutus ensisijaiseksi (ks. Integrointiprosessi). Dokumentissa määritellään keskeisten määrittelyssä käytettyjen käsitteiden merkitys, ja mukana olevista järjestelmistä tai niiden osista käytettävät yleisnimet. Mihin toiminnan tarpeeseen pyritään vastaamaan o Toiminnan tai prosessien kehittäminen o Järjestelmissä jo oleva toiminnallisuus Mitkä järjestelmät osallistuvat / voivat osallistua Mitä standardeja halutaan ottaa huomioon / hyödyntää Esim. käyttötapaus- tai aktiviteettikaavioita käyttötilanteesta, eri järjestelmien toiminnallisuudesta ja toimintaprosesseista Avoimuus-, siirrettävyys- ja ylläpidettävyysvaatimukset Suorituskyky-, turvallisuus-, ja muut laatuvaatimukset o nämä vaatimukset tulisi esittää siten, että toteutuksessa ja sen kuvauksessa voidaan niihin realistisesti vastata Tarvittaessa aikatauluvaatimukset Tarvittaessa riippuvuudet muista hankkeista, varautuminen muiden hankkeiden tuotosten hyödyntämiseen ja tuotosten tarjoaminen muille hankkeille 3.2 Toiminnallinen liittymämäärittely Toiminnallinen liittymämäärittely -dokumentteja voi olla useita yhtä integrointivaatimukset-dokumenttia kohti, jos vaatimusdokumentissa on laaja kokonaisuus. Toiminnallinen liittymämäärittely viittaa yhteen integrointivaatimukset-dokumenttiin. Toiminnallisessa määrittelydokumentissa keskitytään toiminnalliseen (käyttäjän tai kokonaisoptimoinnin) näkökulmaan, mutta myös olemassa olevien sovellusten toiminnallisuus ja niissä käytetyt arkkitehtuuriratkaisut saavat näkyä jonkin verran toiminnallisessa määrittelyssä. Pyrkimys on kuitenkin siihen, että eri tekniikoilla ja arkkitehtuureilla toteutetut sovellukset voivat noudattaa samaa toiminnallista liittymämäärittelyä. Toiminnallinen liittymämäärittely on integrointivaatimusten tavoin integroinnin tilaajien (myös loppukäyttäjien) sekä suunnittelijoiden ja toteuttajien yhteinen kommunikointiväline. Vaikka siinä kuvataan integroinnissa käytettävää tietosisältöä ja operaatioita, tulee kuvauksen olla ymmärrettävää myös ei-teknisille osallistujille. Toiminnallinen liittymämäärittely pyrkii vastaamaan yhteen selkeästi rajattuun integrointitarpeeseen Kuinka integraatio näkyy järjestelmän loppukäyttäjälle 8

9 9 o Esim. pitääkö/voivatko ratkaisut sisältää ohjelmointirajapinnan lisäksi käyttöliittymän Millainen yhteistoiminnallisuus on kyseessä o sovellusten välinen koordinointi o tiedonsiirto tai ohjelmistopalvelun kutsu työasemalla o tiedonsiirto tai ohjelmistopalvelun kutsu verkon yli o käyttöliittymän kutsuminen työasemalla o web-käyttöliittymän kutsuminen Onko ratkaisujen oltava verkon kautta käytettävissä Voiko ratkaisussa sallia/vaatia esim. että eri järjestelmät on asennettu samalle työasemalle Katettujen tieto- tai toimintokokonaisuuksien nimet Sovellusten vastuut eri tieto- ja toimintokokonaisuuksista o Sisältääkö toteutus esim. myös kaiken sisäisen datansa vai tarjoaako vain rajapinnan muualla olevaan dataan Voidaan käyttää Esim. UML:n aktiviteetti- ja sekvenssikaavioita integrointitilanteen vuorovaikutuksesta Viittauksia toiminnallisiin standardeihin ja valmiisiin määrityksiin o HL7-viestisisältö, EPR-sisältömääritykset, OMG-standardit/vastaavat, jne. Koodistojen käyttö, mitä asiaan liittyviä koodistoja ja niiden versioita on saatavilla / käytetty o esim. Laboratoriotutkimusnimikkeistö, ICD-luokitukset, ISO, JHS (esim. Kuntalistaus), toimittajakohtaiset koodistot, SNOMED, LOINC, kans. th. projektin luokitukset Nojautuminen aikaisempaan työhon (PlugITin jo tehdyt määritykset, muiden projektiosapuolten tarjoamat valmiit määritykset) o Tarvittavat ja saatavilla olevat lisäpalvelut (turvallisuus ym.) palvelut Vaihtoehtoisia integrointitapoja: o koordinaattorin käyttö - esim. CCOW o API-rajapinnan kautta tiedonsiirto paluuarvo sisältää käytettävää tietoa joko siten, että nojaudutaan siihen että palvelu on aina saatavilla (esim. kutsuva järjestelmä ei itse sisällä tietoa), tai voidaan sallia samojen tietojen kopiointi osallistuviin järjestelmiin o API-rajapinnan kautta käyttöliittymän kutsuminen suoritetaan toisen järjestelmän "ulokkeella" jokin toimenpide, paluuarvo sisältää tietoa suoritetun toimenpiteen onnistumisesta o yhteisen tietovaraston käyttö - tiedot ovat vain yhdessä paikassa, esim. kertomusarkiston liittymä o (luotetun sovelluksen käyttö turvallisuusintegroinnissa) o (sanomapohjainen HL7/XML-liittymä) - ei PlugIT-projektin kohteena Halutut suorituskyky- ja muut laatuominaisuudet voidaan dokumentoida jo tässä vaiheessa. 9

10 Tekninen liittymämäärittely Tekninen liittymämäärittely -dokumentteja voi olla useita yhtä toiminnallista liittymämäärittelyä kohti, jos samoja toiminnallisia liittymiä halutaan toteuttaa eri tekniikoilla. Jokainen tekninen liittymämäärittely viittaa yhteen toiminnallinen liittymämäärittely -dokumenttiin. Valmis tekninen liittymämäärittely toimii suunnitteludokumenttina ja teknisenä sopimuksena integroinnin toteuttajille (sekä palvelun toteuttaja että hyödyntäjä) toteutettavan liittymän suhteen. Se kuvaa myös tilaajan teknisille asiantuntijoille käytettävät integrointitekniikat ja tekniset ratkaisut. Eri teknisissä liittymämäärittelyissä pyritään käyttämään pohjana ja toteutuksessa mahdollisimman paljon samoja teknisiä osia ja esim. samoja XML-merkkauksia ja HL7-määrittelyjä Sovellusten tekniset vastuut Valitut liittymätekniikat, tekniset standardit PlugIT-projektissa syntyy mallitapauksia sekä ohjeita tyypillisistä teknisistä toteutuksista (voi avustaa liittymien määrittelyssä ja toteutuksessa). Kolme perusliittymätapaa tullut ilmi tähän mennessä (ks. myös PlugITprojektin selvitys tekniikkaperheistä, jossa asiaa käsitellään tarkemmin): o työasematason komponenttirajapinta sisältää aina API-liittymän (tai vastaavan web-mekanismin) voi sisältää käyttöliittymän, ei sisällä välttämättä on kuvattava myös mekanismi, jolla palvelun käyttäjä saa selville onko tietty palvelu ja sen versio saatavilla Käytettävissä olevia teknisiä vaihtoehtoja: Windows dll (Dynamic Link Library) JavaBeans websivu-tekniikat (JSP, ASP, cgi jne.) COM/ActiveX-komponentti o työpöytäintegraation rajapinta standardiin perustuva rajapinta, jonka mukaiset sovellukset voivat noudattaa koordinaattorikomponentin ohjaamaa yhteistoimintaa Windows- tai web-pohjaisissa järjestelmissä. CCOW Context Manager muu työpöytäintegraation määritys o palvelinintegraation rajapinta verkon yli hajautetusti kutsuttava palvelu, joka toteutetaan hajautetulla tekniikalla web services EJB CORBA COM websivu-tekniikat (JSP, ASP, cgi, esim. xml-sivu) sisältää aina API-liittymän ei sisällä käyttöliittymää loppukäyttäjälle Valittujen liittymätekniikoiden vaatima LIITTYMÄN tekninen infrastruktuuri Valittua tekniikka käyttäen API-dokumentaatio 10

11 11 Jokaisen operaation, tietoelementin, merkkauksen ja paluuarvon merkitys ja muoto (esim. Etunimi Sukunimi), tarvittaessa myös maksimipituus tai toiminta jos arvo on tyhjä Virheilmoitukset ja virhetilanteiden hallinta, esim. jos palvelu ei olekaan käytettävissä, toteutetun version selville saanti Mahdollinen eri operaatioiden kutsujärjestys 2.4 Liittymän toteutuksen kuvaus Toteutuksen kuvauksia voi olla useita yhtä teknistä määrittelyä kohti, esim. jokaiselle tuotteelle joka toteuttaa palvelun. Toteutuksen kuvaus viittaa yhteen tekninen liittymämäärittely -dokumenttiin ja on toteutus- tai tuotekohtainen. Toteutuksen kuvaus on tarkoitettu helpottamaan tietyn teknisen liittymän toteuttavien tuotteiden arviointia, käyttöönottoa, asennusta ja ylläpitoa. PlugIT-projektissa voidaan todeta toteutuksen kuvaus-dokumentin olevan toteutuksen dokumentoinnin vaatimusten mukainen, muuten muoto ja sisältö ovat vapaasti toteuttajan päätettävissä. Toteutuksista tulee kuitenkin dokumentoida tässä luetellut asiat. Ei sisällä tarkkaa toteutuksen kuvausta, vaan yhteentoimivuuteen ja asentamiseen liittyvät asiat tarkalla tasolla toteutetussa ratkaisussa TOTEUTUKSEN vaatima tekninen infrastruktuuri (esim. RPC Brokerpalvelin, sovellus X asennettuna työasemalle, käyttöjärjestelmäriippuvuudet, asennetut päivityspaketit eri ympäristöissä) Tuote- tai komponenttikohtainen konfigurointi o esim. palvelun kutsuosoitteen välittäminen toteutukselle, käytettävän dll-tiedoston nimen välittäminen, käyttöliittymän mukauttaminen ulkoisten parametrien avulla, tarjottavat lisäpalvelut Toteutuksen siirrettävyys eri ympäristöihin, jakelumekanismit Toteutuksen rajoitteet (esim. maksimipituudet tietokentille tai elementeille, jollei niitä ole määritelty ylemmän tason dokumenteissa) Suositeltavaa on, että toteutuksen kuvaus sisältää esimerkkitapauksia tarjotun ratkaisun käytöstä, ohjeita ratkaisun käytön (esim. tarjottua palvelua käyttävän osan) toteuttamiseen jne. Dokumentti kuvaa suorituskyky- ja muiden laatuvaatimusten toteutuminen, jos ne on dokumentoitu edellisissä vaiheissa. Dokumentti kuvaa lisäykset muissa määrittelydokumenteissa tehtyihin määrittelyihin, esim. toteutuksen verkkoliikenteen salauksessa käytetyn ratkaisun, jota ei ole määritelty liittymän teknisessä kuvauksessa. Toteuttajan tukipalvelut, yhteystiedot. 4 Määrittelyjen hyväksyminen ja julkistaminen Tavoitteita: määrittelyjen ja liittymien avoimuus, mutta tuotteiden sisäisten yksityiskohtien ja kilpailuetujen suojelu 11

12 12 riittävä keveys yksittäiseen projektiin riittävä formaalius, jotta työtä voidaan jatkaa projektin jälkeen esim. sopivassa standardointiorganisaatiossa julkistusleima" - takuu avoimuudesta hyväksyntäleima" - takuu projektin osapuolten sitoutumisesta Projektissa tehdään toteutuksia ja tarkennetaan määrityksiä etupäässä tehtyjen luonnosten perusteella, eli esim. avoimia rajapintoja tuotteisiin voi syntyä ilman yllä olevien leimojen käyttöä. Hyväksymis- ja julkistamisprosesseja käynnistetään suhteellisen harvoin (esim. puolivuosittain), tai kun on tarpeen tehdä virallisempaa hyväksyntää. Määrittelydokumentit voivat käydä läpi seuraavat vaiheet, tai vain jotkin niistä: LUONNOS laitetaan projektin jäsenten saataville kommentointia varten, ja kommentointia varten asetetaan takaraja o kommentoida voi esim. sähköpostin avulla, ja kuka tahansa projektin osapuoli voi kommentoida Saatujen kommenttien perusteella voidaan tehdä korjauksia luonnokseen, ja luonnosten perusteella tuotetaan tarkempia jatkodokumentteja ja toteutuksia, ilman että odotetaan luonnosten projektin laajuista hyväksyntää (ks. seur.). Integrointivaatimukset sekä Toiminnallinen ja Tekninen liittymämäärittely -dokumenteista hyväksymistä varten tehty luonnos tuodaan projektin osapuolten saataville (www-sivuille) ja hyväksymistä ja kommentointia varten asetetaan takaraja. Projekti ilmoittaa kaikille osapuolille hyväksymisäänestyksestä. Takarajaan mennessä osapuolten edustajat voivat ilmoittaa kannattavansa luonnoksen hyväksymistä, äänestää tyhjää tai ilmoittaa etteivät kannata luonnoksen hyväksymistä. Luonnoksesta tulee HYVÄKSYTTY määrittely, jos takarajaan mennessä ei ole tullut kielteisiä ilmoituksia ja on tullut hyväksyttyjä ilmoituksia. Jos jokin osapuoli ei ilmoita takarajaan mennessä myönteistä tai kielteistä kantaa hyväksymiseen, on osapuoli äänestänyt tyhjää. Jos samasta aiheesta on useita luonnoksia, pyritään luonnokset sulauttamaan yhteen ennen hyväksyntää (tai tuottamaan esim. samasta toiminnallisesta liittymämäärittelystä eri tekniikoille teknisiä liittymämäärittelyitä). Eri luonnosten priorisoinnissa pyritään vastaamaan ensisijaisesti käyttäjätarpeisiin. Jos hyväksymisäänestyksessä oleva dokumentti ei ole relevantti projektin osapuolen kannalta (esim. tekninen määrittely tekniikalla, jota osapuoli ei käytä tai aio käyttää), on suositeltavaa äänestää tyhjää (esim. jättämällä äänestämättä ko. dokumentin suhteen). Toteutuksen kuvaus-dokumentteja ei hyväksytä erikseen, vaan riittää että ne ovat saatavilla projektin kautta ja asetettujen dokumenttikriteerien mukaisia. Hyväksymisäänestystä ei käynnistetä jokaisen hyväksyttäväksi tarkoitetun luonnoksen valmistuessa, vaan esim. määräajoin (1-2 kertaa vuodessa tai jos on erityinen syy käynnistää äänestys), ja samassa äänestyksessä pyritään hyväksymään useita tehtyjä luonnoksia. Hyväksytyssä määrittelyssä on lukkoon lyöty versionumero. Siitä poistetaan sana "Luonnos". Määrittelystä tulee JULKINEN, kun projektin johtoryhmä on hyväksynyt määrityksen julkaisemisen vapaasti saataville. o Projektisopimuksen mukaan johtoryhmä hyväksyy yksimielisesti 12

13 13 Tuotteet: Määrittelystä tulee TOTEUTETTU, kun määrityksen mukainen liittymä löytyy ainakin yhdestä käyttöympäristöön asennetusta tuotteesta, tuotteen toimittaja on ilmoittanut käyttöönotosta ja toteutuksen kuvaus on saatavilla. Tuotteesta tulee MÄÄRITTELYÄ NOUDATTAVA, jos voidaan varmistua siitä, että se toimii määrittelydokumenttien mukaisesti ja yhdessä muiden määritystä noudattavien tuotteiden kanssa o määrittelyjen mukaisuuden testausta voidaan kehittää PlugITprojektissa Luonnoksista, hyväksytyistä, julkisista tai toteutetuista määrityksistä voidaan tehdä uusien versioiden luonnoksia. Uusien versioiden dokumentoinnissa on kuvattava onko versio taaksepäin yhteensopiva, muutokset ja laajennukset edellisiin versioihin jne. PlugIT-projektin sisäisillä web-sivuilla ovat kaikki projektissa tehdyt määrittelydokumentit, projektisuunnitelmat ja niiden kommentoitavaksi tarkoitetut luonnokset. Eri dokumenteista näkyy selvästi onko se luonnos, hyväksytty tai julkistettu. Määritysten yhteydessä näkyy, mitkä tuotteet ovat toteutettu tai määrittelyä noudattava-tilassa. Julkiset määrittelydokumentit laitetaan projektin julkisille web-sivuille saataville Projektin johtoryhmä voi päättää kenelle tehty (sekä kesken oleva) työ siirretään projektin jälkeen. Taustamateriaalia: OMG Model Driven Architecture MDA: ftp://ftp.omg.org/pub/docs/ab/ pdf ISO RM-ODP: ftp://ftp.dstc.edu.au/pub/dstc/arch/rm-odp/pdfdocs/part1.pdf Rational Unified Process: OMG Standardization process: Mykkänen J, Porrasmaa J, Korpela M: A process for specifying integration for multi-tier applications in healthcare. In: Surján G, Engelbrecht R, McNair P, eds. MIE Proceedings of the 17th International Congress of the European Federation of Medical Informatics. [Budapest], [25-29 August 2002], p Amsterdam: IOS, Saatavilla projektin sisäiseen käyttöön PlugIT-projektin yhteyshenkilöiden web-sivuilta: Component and Service Technology families. PlugIT-projektin selvitys. Luku 8.3: Selecting technologies for integration. Luonnos saatavilla projektin sisäiseen käyttöön PlugIT-projektin yhteyshenkilöiden web-sivuilta: 13

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

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

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

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

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

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7 Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe

Lisätiedot

Kuntasektorin yhteineset viitearkkitehtuurit Tiedon- ja asianhallinta Johtamisjärjestelmä

Kuntasektorin yhteineset viitearkkitehtuurit Tiedon- ja asianhallinta Johtamisjärjestelmä Kuntasektorin yhteineset viitearkkitehtuurit Tiedon- ja asianhallinta Johtamisjärjestelmä Kurttu-seminaari 2013 18.4.2013 Helsinki Heini Holopainen, Sari Valli Sisältö Tiedon- ja asianhallinnan viitearkkitehtuuri

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

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi

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

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

TeliaSonera Identity and Access Management

TeliaSonera Identity and Access Management TeliaSonera Identity and Access Management 22.10.2009 EMC Forum Juha Arjoranta 1 TeliaSonera Identity and Access Management Alustus käyttövaltuushallintaan IAM kokonaisratkaisun elementit Nykytilaa ja

Lisätiedot

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Vaatimusluettelo versio 0.17 Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Yleiset vaatimukset 1 Koodistopalvelujärjestelmä on selainkäyttöinen 2 Käyttöliittymän tulee

Lisätiedot

Avoimen rajapinnan hallinta (Tilaajan hallitsema rajapinta)

Avoimen rajapinnan hallinta (Tilaajan hallitsema rajapinta) 18.2.2016 Avoimen rajapinnan hallinta (Tilaajan hallitsema rajapinta) - tausta ja tarpeen kuvaus - Rajapinnan elinkaaren hallinta ja siihen liittyvä dokumentaatio (VALMIS 1.4) Versionhallinta: Versio Pvm

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS 20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien

Lisätiedot

Tik Projektiryhmä: TeamAhma. Projektin HAYABUSA opponointi. Opponointisuunnitelma

Tik Projektiryhmä: TeamAhma.  Projektin HAYABUSA opponointi. Opponointisuunnitelma TeamAhma Projektin HAYABUSA opponointi Opponointisuunnitelma Päivitetty 25.3.2001 klo 12:08 Projektin HAYABUSA opponointi Mikko Viljainen 2 (5) Sisällys 1. JOHDANTO...3 2. YMPÄRISTÖ...3 3. HENKILÖSTÖ...4

Lisätiedot

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015 Kuntien integraatioalusta Hannes Rauhala 3.11.2015 Johdantoa asiaan Espoon kaupunki on toiminut edelläkävijänä kansallisen palveluväylän (Xroad) käyttöönotossa. Asiasta järjestettiin Espoossa ja Lahdessa

Lisätiedot

Arkkitehtuurikuvausten kohteet ja kuvaustavat

Arkkitehtuurikuvausten kohteet ja kuvaustavat Arkkitehtuurikuvausten kohteet ja kuvaustavat - tulokset SOLEA 2011 25.11.2011 Espoo Hannu Virkanen + Juha Mykkänen Sisältö Tehdyn tutkimuksen esittely: Johdanto ja alustus asetetut tavoitteet Menetelmät

Lisätiedot

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä Avoimen ohjelmistotuotteen hallinta julkisella sektorilla Jukka Kääriäinen (jukka.kaariainen@vtt.fi) VTT Oy 19.5.2015, Oskari-verkostopäivä Esityksen sisältö Mitä on tuotteenhallinta? Mikä on avoimen tuotteenhallintamalli?

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

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

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys

Lisätiedot

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen So far Toimeksianto: Opiskelun ja opetuksen tuen ja hallinnon viitearkkitehtuuri Tietoarkkitehtuurin osuuteen liittyen Synergiaryhmä 4.12.2014 linjannut,

Lisätiedot

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat

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

TAPAS - puheenvuoro - TAPAS-päätösseminaari Tommi Oikarinen, VM / JulkICT

TAPAS - puheenvuoro - TAPAS-päätösseminaari Tommi Oikarinen, VM / JulkICT TAPAS - puheenvuoro - TAPAS-päätösseminaari 28.10.2011 Tommi Oikarinen, VM / JulkICT Projektin ensisijaisena tavoitteena on yhteisesti suunnitella ja arvioida alueellisen ja paikallisen tason tietojärjestelmäarkkitehtuurin

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

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

käyttötapaukset mod. testaus

käyttötapaukset mod. testaus käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)

Lisätiedot

Avoimen lähdekoodin ohjelmistot julkisessa hallinnossa

Avoimen lähdekoodin ohjelmistot julkisessa hallinnossa Avoimen lähdekoodin ohjelmistot julkisessa hallinnossa Ohjelmistotuotteen hallinta ja hallinnointi 22.4.2015 Mikael Vakkari, neuvotteleva virkamies. VM Strategisten linjausten perusteemat Avoimuus Hallinto,

Lisätiedot

Kansallinen organisoituminen - ohjausmalli. Anne Kallio

Kansallinen organisoituminen - ohjausmalli. Anne Kallio Kansallinen organisoituminen - KanTa-työnjako ja ohjausmalli Anne Kallio kehittämispäällikkö i äällikkö Sosiaali- ja terveydenhuollon sähköiset tiedonhallintahankkeet KanTa-palvelut eresepti earkisto ekatselu

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

ehops-palvelu Oppijan verkkopalvelut kesäseminaari Katri Lahikainen Opintopolku.fi

ehops-palvelu Oppijan verkkopalvelut kesäseminaari Katri Lahikainen Opintopolku.fi ehops-palvelu Oppijan verkkopalvelut kesäseminaari 5.6.2014 Katri Lahikainen ehops-palvelun vaatimusmäärittely Vaatimusmäärittely on työstetty työpajatyöskentelynä kevään aikana konsulttiyhtiö Cerionin,

Lisätiedot

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Käyttöönoton Roll-Out Planning suunnittelu- & Preparation ja valmistelu Design Tiedon- Data Conversion muunnos- prosessien Processes suunnittelu Toimipisteiden

Lisätiedot

Raitiotieallianssin riskienhallintamenettelyt

Raitiotieallianssin riskienhallintamenettelyt Riskienhallintamenettelyt 1 (7) Raitiotieallianssin riskienhallintamenettelyt Riskienhallintamenettelyt 2 (7) SISÄLTÖ 1 PERIAATTEET JA TAVOITTEET... 3 2 ORGANISOINTI JA VASTUUT... 4 3 RISKIENHALLINTAPROSESSI...

Lisätiedot

Sosiaalihuollon asiakasasiakirjojen standardointi

Sosiaalihuollon asiakasasiakirjojen standardointi Sosiaalihuollon asiakasasiakirjojen standardointi Tikesos-hanke Kuopion yliopisto Jari Savolainen Materiaali jakelua varten. (*) Merkinnällä varustettuja dioja ei ajanpuutteen vuoksi välttämättä käsitellä

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

Käyttötapausanalyysi ja testaus tsoft Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten

Lisätiedot

suomi.fi Suomi.fi-palveluväylä

suomi.fi Suomi.fi-palveluväylä Suomi.fi-palveluväylä Julkishallinto, valtion ja kuntien yhtiöt 11.9.2015 Versio 1.0 JPV031 Esityksen sisältö 1. Suomi.fi-palvelukokonaisuus 2. Palvelulupauksemme 3. Mitä palvelu tarjoaa? 4. Miten? 5.

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

Paikkatiedon kypsyysmalli, case Espoo ja Turku. Aalto-yliopisto Insinööritieteiden korkeakoulu

Paikkatiedon kypsyysmalli, case Espoo ja Turku. Aalto-yliopisto Insinööritieteiden korkeakoulu Paikkatiedon kypsyysmalli, case Espoo ja Turku Aalto-yliopisto Insinööritieteiden korkeakoulu seminaari 12.5.2011 Esityksen sisältö Mitä organisaation paikkatietokypsyys tarkoittaa? Miksi paikkatietokypsyyden

Lisätiedot

JHS Esiselvitys tietojärjestelmähankintaa varten

JHS Esiselvitys tietojärjestelmähankintaa varten JHS Esiselvitys tietojärjestelmähankintaa varten Hankesuunnitelma v.0.3 1/12 SISÄLLYSLUETTELO 1 HANKKEEN LÄHTÖKOHDAT 4 1.1 Hankkeen perustamisen tausta 4 1.2 Hankkeen tavoitteet 4 1.3 Hankkeen sidosryhmät

Lisätiedot

Valppaan asennus- ja käyttöohje

Valppaan asennus- ja käyttöohje Versio Päiväys Muokkaaja Kuvaus 0.9 16.2.2006 Tuukka Laakso Korjattu versio 0.1 Antti Kettunen Alustava versio Sisällysluettelo 1 Johdanto...2 2 Valppaan asennus...3 2.1 Valppaan kääntäminen...3 2.2 Valmiiksi

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista...

Lisätiedot

Perustietovarantojen rajapintaratkaisun sidosryhmät - yhteenveto PERA-määrittely Liite 2

Perustietovarantojen rajapintaratkaisun sidosryhmät - yhteenveto PERA-määrittely Liite 2 Perustietovarantojen rajapintaratkaisun sidosryhmät - yhteenveto PERA-määrittely Liite 2 Päiväys: 31.5.2011 versio 0.9 Sidosryhmä Kuvaus Sidosryhmän rooli Sidosryhmän tehtävät ja vastuut Tietojen luovuttaja

Lisätiedot

VÄLI- JA LOPPURAPORTOINTI

VÄLI- JA LOPPURAPORTOINTI Tuija Nikkari 2012 VÄLI- JA LOPPURAPORTOINTI Raportointikoulutus 23.8.12 Raportoinnin tarkoitus Raportoinnin tehtävänä on tuottaa tietoa projektin etenemisestä ja tuloksista rahoittajalle, yhteistyökumppaneille

Lisätiedot

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

Arkkitehtuuri käytäntöön

Arkkitehtuuri käytäntöön Arkkitehtuuri käytäntöön Terveydenhuollon ATK-päivät 24.5.2011 Mikko Huovila Erikoissuunnittelija Itä-Suomen sosiaalialan osaamiskeskus Väliraportti Tikesos-toimeenpanosta (4/2011) Kuvaa julkisen hallinnon

Lisätiedot

Kansallisen palveluväylän viitearkkitehtuuri

Kansallisen palveluväylän viitearkkitehtuuri viitearkkitehtuuri Yhteenveto 6.7.2015 Versio: 0.9 viitearkkitehtuurin yhteenveto 24.4.2015 2 (9) 1. Kansallisen palveluväylän tavoitteet Kansallisen palveluväylän käyttöönotto perustuu Työ- ja elinkeinoministeriön

Lisätiedot

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin

Lisätiedot

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen Vastausten ja tulosten luotettavuus Vastaukset 241 vastausta noin 10 %:n vastausprosentti tyypillinen Kansainväliset IT:n hallinnan hyvät käytännöt. Luotettavuusnäkökohdat Kokemukset ja soveltamisesimerkit

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

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

Kokonaisarkkitehtuuri julkisessa hallinnossa 2016

Kokonaisarkkitehtuuri julkisessa hallinnossa 2016 Kokonaisarkkitehtuuri julkisessa hallinnossa 2016 14.12.2016 Jari Kallela JUHTA JulkICT Sisältö Yhteentoimivuuden haaste Kokonaisarkkitehtuurikyvykkyyden edistyminen Uudistuva sisältö Tietohallintolaki

Lisätiedot

UKJ-suunnittelun etenemisestä

UKJ-suunnittelun etenemisestä UKJ-suunnittelun etenemisestä Asiantuntijaseminaari 12.9.2013 Ari Ahlqvist Mitä pitikään tehdä? 1. Uuden järjestelmän laaja kuvaus, vaatimusmäärittely Pohjana kokonaisarkkitehtuurimalli Toiminnallisuuden

Lisätiedot

Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus

Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus Pilottiehdotuksen osapuolet: CSC Tieteen tietotekniikan keskus Oy Verohallinto Yhteyshenkilö: Suvi Remes suvi.remes@csc.fi

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

Kokonaisarkkitehtuuri sosiaali- ja terveydenhuollossa

Kokonaisarkkitehtuuri sosiaali- ja terveydenhuollossa Kokonaisarkkitehtuuri sosiaali- ja terveydenhuollossa SADe-ohjelman sosiaali- ja terveysalan palvelukokonaisuuden kevätseminaari 23.4. 2013 Mikko Huovila THL / Oper 23.4.2013 Mikko Huovila THL / Oper 1

Lisätiedot

Julkishallinnon perustietovarantojen rajapinnat (PERA) -työryhmä. Tietovarantojen yhteinen rajapintaratkaisu. Toimeenpanosuunnitelma

Julkishallinnon perustietovarantojen rajapinnat (PERA) -työryhmä. Tietovarantojen yhteinen rajapintaratkaisu. Toimeenpanosuunnitelma PERA-määrittely Julkisen hallinnon ICT-toiminto 31.5.2011 VM125:06/2007 Julkishallinnon perustietovarantojen rajapinnat (PERA) -työryhmä Tietovarantojen yhteinen rajapintaratkaisu Toimeenpanosuunnitelma

Lisätiedot

Tampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki

Tampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki Tampereen kaupungin paikkatietostrategia 2013 2015 Tampereen kaupunki 28.3.2013 TAMPERE Tampereen kaupungin paikkatietostrategia 1 PAIKKATIETO JA PAIKKATIETOINFRASTRUKTUURI KÄSITTEENÄ Paikkatiedolla tarkoitetaan

Lisätiedot

JHS-järjestelmä ja avoimet teknologiat. Tommi Karttaavi

JHS-järjestelmä ja avoimet teknologiat. Tommi Karttaavi JHS-järjestelmä ja avoimet teknologiat Tommi Karttaavi 13.5.2008 JHS-järjestelmä (historiaa) Valtioneuvoston päätös valtionhallinnon sisäisistä standardeista 7.9.1977 Valtiovarainministeriö vahvisti valtionhallinnon

Lisätiedot

Avoimen rajapinnan elinkaari (Tilaajan hallitsema rajapinta) - tausta ja tarpeen kuvaus -elinkaaren hallinta ja siihen liittyvä dokumentaatio

Avoimen rajapinnan elinkaari (Tilaajan hallitsema rajapinta) - tausta ja tarpeen kuvaus -elinkaaren hallinta ja siihen liittyvä dokumentaatio 16.10.2015 Avoimen rajapinnan elinkaari (Tilaajan hallitsema rajapinta) - tausta ja tarpeen kuvaus -elinkaaren hallinta ja siihen liittyvä dokumentaatio (VALMIS 1.0) Versionhallinta: Versio Pvm Tila (Luonnos

Lisätiedot

Liite 2. Alustava projektisuunnitelma. JulkICTLab tehtävien toimeenpanosta CSC - Tieteen tietotekniikan keskus Oy:n ja Valtiovarainministeriön välillä

Liite 2. Alustava projektisuunnitelma. JulkICTLab tehtävien toimeenpanosta CSC - Tieteen tietotekniikan keskus Oy:n ja Valtiovarainministeriön välillä Liite 2. Alustava projektisuunnitelma JulkICTLab tehtävien toimeenpanosta CSC - Tieteen tietotekniikan keskus Oy:n ja Valtiovarainministeriön välillä 16.10.2013 Versio: 0.4 Laatija: Kirsi Pispa 1 Sisältö

Lisätiedot

Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla

Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla lopullinen versio esityksestä löytyy osoitteesta: http://www.centek.fi/serapi/mater/thatk05.pdf Terveydenhuollon atk-päivät, Helsinki,

Lisätiedot

AVOIN DATA AVAIN UUTEEN Seminaarin avaus Kansleri Ilkka Niiniluoto Helsingin yliopisto

AVOIN DATA AVAIN UUTEEN Seminaarin avaus Kansleri Ilkka Niiniluoto Helsingin yliopisto AVOIN DATA AVAIN UUTEEN Seminaarin avaus 1.11.11 Kansleri Ilkka Niiniluoto Helsingin yliopisto TIETEELLINEN TIETO tieteellinen tieto on julkista tieteen itseäänkorjaavuus ja edistyvyys tieto syntyy tutkimuksen

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Suvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014

Suvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014 Tietokanta Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia ja linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat

Lisätiedot

Ajankohtaista Ilmoitin.fi:stä

Ajankohtaista Ilmoitin.fi:stä Ajankohtaista Ilmoitin.fi:stä Verohallinnon ohjelmistotalotapaaminen 13.5.2016 Markus Virolainen Tieto, Tietokarhu Oy markus.virolainen@tieto.com Kolme asiaa 1. Ilmoitin.fi ja kansallinen palveluarkkitehtuuriohjelma

Lisätiedot

Liite A Määritelmät 1 (6)

Liite A Määritelmät 1 (6) 1 (6) Liite A Määritelmät 2.3 Uusi versio 2.4 Versio joulukuun neuvotteluja varten 2.6 Tarjoajille 29.1.2015 lähetetty versio 2.7 Helmikuun 2015 neuvotteluissa käsitelty versio 2.81 Tarjoajille 18.2.2015

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

Yhteenveto. IHE ja Yhteentoimivuus käytännössä , Helsinki f. Juha Mykkänen, tutkijatohtori Kuopion yliopisto, HIS-tutkimusyksikkö

Yhteenveto. IHE ja Yhteentoimivuus käytännössä , Helsinki f. Juha Mykkänen, tutkijatohtori Kuopion yliopisto, HIS-tutkimusyksikkö 1 Yhteenveto IHE ja Yhteentoimivuus käytännössä 14.11.2008, Helsinki www.ihe.net Juha Mykkänen, tutkijatohtori Kuopion yliopisto, HIS-tutkimusyksikkö IHE ja Suomi - tähän mennessä useiden vuosien ajan

Lisätiedot

Projektisopimus. 1. Sopimuksen osapuolet. 2. Määrittelyt. 2.1 Johtoryhmä. 2.2 Suunnitteludokumentit

Projektisopimus. 1. Sopimuksen osapuolet. 2. Määrittelyt. 2.1 Johtoryhmä. 2.2 Suunnitteludokumentit Projektisopimus 1. Sopimuksen osapuolet Projektin toimeksiantaja (jäljempänä Tilaaja) on Jyväskylän yliopiston alaisista organisaatiosta koostuva ryhmä, johon kuuluvat: Virtuaaliyliopisto ja Hallinnon

Lisätiedot

Opinnäytetyön prosessikuvaus

Opinnäytetyön prosessikuvaus OPTISEN MITTAUSTEKNIIKAN LABORATORIO Opinnäytetyön prosessikuvaus Raportti, PAL hanke, TP 2.2 Versio: 13.8.08, tekniikan johtoryhmän hyväksymä. Harri Pikkarainen, Jani Sipola, Kemi-Tornion amk, tekniikka

Lisätiedot

Sosiaalihuollon asiakirjastandardi kehittyy. Konstantin Hyppönen Erikoissuunnittelija Tietojenkäsittelytieteen laitos Kuopion yliopisto

Sosiaalihuollon asiakirjastandardi kehittyy. Konstantin Hyppönen Erikoissuunnittelija Tietojenkäsittelytieteen laitos Kuopion yliopisto Sosiaalihuollon asiakirjastandardi kehittyy Konstantin Hyppönen Erikoissuunnittelija Tietojenkäsittelytieteen laitos Kuopion yliopisto 1 Esityksen sisältö Asiakirjastandardin lähtökohdat Suunnitteluperiaatteet

Lisätiedot

Avoimuus ja julkisen hallinnon tietohallinto. Yhteentoimivuutta avoimesti -seminaari Tommi Oikarinen, VM / JulkICT

Avoimuus ja julkisen hallinnon tietohallinto. Yhteentoimivuutta avoimesti -seminaari Tommi Oikarinen, VM / JulkICT Avoimuus ja julkisen hallinnon tietohallinto Yhteentoimivuutta avoimesti -seminaari 2.12.2011 Tommi Oikarinen, VM / JulkICT Yhteentoimivuus ja avoimuus Seminaarin aihe pakottaa määrittämään termit yhteentoimivuus

Lisätiedot

- miten saadaan tieto järkevästi ja vakioidusti siirtymään tietovarantojen ja palvelujen välillä

- miten saadaan tieto järkevästi ja vakioidusti siirtymään tietovarantojen ja palvelujen välillä 1 - miten saadaan tieto järkevästi ja vakioidusti siirtymään tietovarantojen ja palvelujen välillä 2 - Eri tekniikoiden integraatio on helppoa semanttinen yhteentoimivuus, eli sopiminen yhteisistä tietosisällöistä

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

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

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

Lisätiedot

JHS-jaoston toiminta ja tavoitteet. JUHTA:n syysseminaari Kuntatalolla

JHS-jaoston toiminta ja tavoitteet. JUHTA:n syysseminaari Kuntatalolla JHS-jaoston toiminta ja tavoitteet JUHTA:n syysseminaari Kuntatalolla 19.9.2013 Toiminnan tavoitteiden ja painopisteiden määrittely Keinot JHS Tavoite Mitä ja minkälaisia suosituksia tavoitteiden toteutumisen

Lisätiedot

SOPIMUS [SOVELLUSHANKINNASTA]

SOPIMUS [SOVELLUSHANKINNASTA] Julkisen hallinnon IT- hankintojen sopimusehdot (JIT 2007) 1 ----------------------------------------------------------------------------------------------------------------------------------- [JHS 166

Lisätiedot

Suomi.fi-palveluväylä

Suomi.fi-palveluväylä Suomi.fi-palveluväylä 18.11.2016 Versio: 3.0, JPVO122 Esityksen sisältö 1. Suomi.fi-palvelukokonaisuus 2. Palvelulupauksemme 3. Mitä palvelu tarjoaa? 4. Palveluväylän kokonaisuus 5. Vyöhykkeet ja väyläratkaisut

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Toiminnallinen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Versio Päiväys Tekijä Kuvaus 0.01 7.11.01 Pekka Koskinen Alustava sisällysluettelo 0.1 12.11.01 Pekka

Lisätiedot

Projektisuunnitelma Viulu

Projektisuunnitelma Viulu Projektisuunnitelma Viulu Kuusela Johannes Sjöblom Teemu Suominen Osma Ohjelmistotuotantoprojekti Helsinki 23.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Versiohistoria Päivämäärä Versio

Lisätiedot

Opetus- ja koulutusyhteistyöhön liittyvä korkeakoulujen tietojärjestelmien yhteentoimivuuden kehittäminen ja arkkitehtuurityö

Opetus- ja koulutusyhteistyöhön liittyvä korkeakoulujen tietojärjestelmien yhteentoimivuuden kehittäminen ja arkkitehtuurityö Opetus- ja koulutusyhteistyöhön liittyvä korkeakoulujen tietojärjestelmien yhteentoimivuuden kehittäminen ja arkkitehtuurityö 2016-2018 30.8.2016 Ilmari Hyvönen Taustaa Digitalisaation vaikutukset korkeakoulutukseen

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Sote-palveluhakemisto-projekti. Projektiryhmän kokous

Sote-palveluhakemisto-projekti. Projektiryhmän kokous Sote-palveluhakemisto-projekti Projektiryhmän kokous 11.1.2017 Asialista 1.10.2017 1. Kokouksen avaus 2. Ajankohtaiskatsaus projektin etenemiseen Osaprojekti 1 Osaprojekti 2 3. Road map Mitä on tehty Missä

Lisätiedot

Riippumattomat arviointilaitokset

Riippumattomat arviointilaitokset Riippumattomat arviointilaitokset CSM Riskienhallinta -asetuksen mukainen riippumaton arviointi Komission asetus (352/2009/EY) yhteisestä turvallisuusmenetelmästä, CSM riskienhallinta-asetus, vaatii rautatiejärjestelmässä

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

Tuomiorekisterin ratkaisuhaun kehittäminen

Tuomiorekisterin ratkaisuhaun kehittäminen 25.5.2012 Sivu 1 Muutoshistoria Versio Päiväys Tekijä Kuvaus 0.1 15.2.2012 NMu Luonnos korjattujen ratkaisujen tietojen välittämisen muutoksesta 0.2 12.3.2012 NMu Lisätty uusia metatietokenttiä 0.3 25.5.2012

Lisätiedot

Toivakan kunnan teknologia-arkkitehtuuri

Toivakan kunnan teknologia-arkkitehtuuri Toivakan kunnan teknologiaarkkitehtuuri Iikka Virtanen, Teemu Uusitalo & Vesa Kakriainen Toivakan kunnan teknologia-arkkitehtuuri Johdanto Nykytilan kartoitus Tavoitetilan kuvaus 6.7.1 Teknologiapalvelut

Lisätiedot

Kiekun käyttöönottomenetelmä

Kiekun käyttöönottomenetelmä Kieku-info: Kiekun käyttöönottomenetelmä Opetushallituksen monitoimitila 16.12.2013 Kieku-info 16.12.2013, Tarja Heikkilä Esiteltävät asiat Mikä on käyttöönottomenetelmä? Miksi sitä pitää kehittää? Miten

Lisätiedot

Kuutoskaupunkien suositukset avoimista rajapinnoista

Kuutoskaupunkien suositukset avoimista rajapinnoista Kuutoskaupunkien suositukset avoimista rajapinnoista Versio 1.0.1, 26.4.2016 Sisältö Yleistä... 3 Visio: Kaupunkien palvelukehitys rajapinnat edellä... 5 Yhteiset tavoitteet... 6 Avoimuus käytössä ja kehityksessä...

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Vaatimusmäärittely Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Versio Päiväys Tekijä Kuvaus 0.1 12.10.01 Pekka Koskinen Ensimmäinen luonnos 0.2 17.10.01 Pekka Koskinen Lisätty vaatimuksia

Lisätiedot

JHS129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen. JHS-jaosto

JHS129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen. JHS-jaosto JHS129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen JHS-jaosto 23.05.2014 Sisältö Käsitteet ja tavoitteet Työskentelyprosessi Suositusluonnoksen esittely 2 Käsitteet ja tavoitteet 3 Verkkopalvelu

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

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

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

Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun

Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun Salon seudun suunnittelumalli yhdistää toiminnallisen kyläsuunnittelun ja maankäytön suunnittelun Toiminnallinen kyläsuunnitelma edustaa kyläläisten

Lisätiedot