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

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003 Tässä työsuunnitelmassa on esitetty vain tutkimussuunnitelman mukaisten tärkeimpien tuotosten aikaansaamiseksi

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

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa

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

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

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

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

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

Sopimus Asiakas- ja potilastietojärjestelmästä. Liite N: Kielivaatimukset

Sopimus Asiakas- ja potilastietojärjestelmästä. Liite N: Kielivaatimukset Sopimus Asiakas- ja potilastietojärjestelmästä Liite N: Kielivaatimukset VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 12.3.15 3.0 Tarjouspyynnön liitteeksi 2 (6) SISÄLLYSLUETTELO 1 JOHDANTO... 4 2 JÄRJESTELMÄN

Lisätiedot

PALVELUKUVAUS järjestelmän nimi versio x.x

PALVELUKUVAUS järjestelmän nimi versio x.x JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Liite 4 Palvelukuvaus -pohja Versio: 1.0 Julkaistu: 11.9.2009 Voimassaoloaika: Toistaiseksi PALVELUKUVAUS järjestelmän nimi versio

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

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

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

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

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

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet

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

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

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

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

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

PILETTI. Tekninen vaatimusmäärittely. v. 0.2

PILETTI. Tekninen vaatimusmäärittely. v. 0.2 PILETTI Tekninen vaatimusmäärittely v. 0.2 2 Sisällysluettelo 1. Yleiskuvaus... 3 2. Taustajärjestelmä... 4 3. Palvelupisteiden sovellus... 4 4. Korttisovellus ja turvaratkaisu... 4 5. Rajapinnat... 5

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

Ajanvarauksen avoimet rajapinnat

Ajanvarauksen avoimet rajapinnat SerAPI hanke Ajanvarauksen avoimet rajapinnat alueellisen ajanvarauspalvelun ja web ajanvarauksen toteuttamiseen Ajanvarausrajapinnat kohteet Tarkoitettu erityisesti alueellisten ajanvarauspalvelujen tai

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

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus OTM-HANKE Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus Taustaa Aalto-yliopisto, Helsingin yliopiston ja Tampereen yliopiston yhteishanke opintohallinnon tietojärjestelmien modernisoinniksi

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

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

Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa

Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3 STUDIES AND REPORTS OF THE PLUGIT PROJECT 3 Juha Mykkänen, Kristiina Häyrinen, Saara Savolainen, Jari Porrasmaa Standardien arviointi ja valinta terveydenhuollon

Lisätiedot

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavat ja eivät tuota Tulokset riippuvat niistä tekijöistä, jotka projektia perustettaessa on määritelty ja miten

Lisätiedot

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

Lisätiedot

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Laajuus Jatkuva laajeneminen sekä maantieteellisesti että sisällön kannalta: Yhdestä

Lisätiedot

Opetushallitus. Asiantuntijapalvelut Oppijan palvelukokonaisuuden. Projektisuunnitelma

Opetushallitus. Asiantuntijapalvelut Oppijan palvelukokonaisuuden. Projektisuunnitelma Opetushallitus Asiantuntijapalvelut Oppijan palvelukokonaisuuden hops-palvelun vaatimusmäärittelyn tueksi Projektisuunnitelma Päivitetty 12.2.2014 Sisällysluettelo 1 Projektin yleiskuvaus... 3 1.1 Projektin

Lisätiedot

Käyttöohje. Versiohistoria: 1.0 7.5.2003 1. versio Mari 1.1 9.5.2003 Kommenttien perusteella korjattu versio

Käyttöohje. Versiohistoria: 1.0 7.5.2003 1. versio Mari 1.1 9.5.2003 Kommenttien perusteella korjattu versio Otus- projektinhallintatyökalu Käyttöohje Versiohistoria: 1.0 7.5.2003 1. versio Mari 1.1 9.5.2003 Kommenttien perusteella korjattu versio Mari Tampere 9. toukokuuta 2003 Kimmo Airamaa, Andreas Asuja,

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

AVOIN LÄHDEKOODI JA SEN MERKITYS LIIKETOIMINNASSA

AVOIN LÄHDEKOODI JA SEN MERKITYS LIIKETOIMINNASSA DIMENTEQ OY SALORANKATU 5-7 24240 SALO FINLAND WWW.DIMENTEQ.FI AVOIN LÄHDEKOODI JA SEN MERKITYS LIIKETOIMINNASSA SKOL ja FLIC, 29.10.2015 Teemu Virtanen, Dimenteq Oy DIMENTEQ OY Tietotekniikan palveluyritys,

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

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

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut

Lisätiedot

Tilannekatsaus 4.11.2013. Opintopolku.fi

Tilannekatsaus 4.11.2013. Opintopolku.fi Tilannekatsaus 4.11.2013 tilannekatsaus 4.11.2013 Muuntotyön tilanne AT/EAT muunnossa olleet aineistot toimitettu Opetushallitukselle. Muunnettuja tutkintoja 114, 13 tutkintoa jäänyt muuntamatta niihin

Lisätiedot

SUOMEN KUNTALIITTO RY

SUOMEN KUNTALIITTO RY Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...

Lisätiedot

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt. Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta?

Lisätiedot

Kysymykset ja vastaukset:

Kysymykset ja vastaukset: Kysymykset ja vastaukset: Kysymys 1 Voidaanko JYSE2009 Palvelut sopimusehtoja täydentää JIT2007 sopimusehdoin (Yleiset sopimusehdot, JIT2007 sovellukset, JIT2007 Palvelut)? Vastaus 1 Hankinnassa noudatetaan

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

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

Kuntasektorin kokonaisarkkitehtuuri

Kuntasektorin kokonaisarkkitehtuuri Kuntasektorin kokonaisarkkitehtuuri Yhteiskäyttöisten komponenttien kehitys ja hallinta Kurttu 18.4.2013 Ohjelmistokomponenttien uudelleenkäyttö Kustannussäästöjä» Kehityskustannukset» Lisenssikustannukset

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Arkkitehtuurikehyksen

Lisätiedot

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.

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

11.10.2013 Tekijän nimi

11.10.2013 Tekijän nimi 11.10.2013 Tekijän nimi Arkkitehtuuri kehittämisen välineenä Kokonaisarkkitehtuuri hallitun muutoksen avaimena Etelä-Savon maakuntaliitto 10.10.2013 Markku Nenonen Tutkijayliopettaja Mikkelin ammattikorkeakoulu

Lisätiedot

Arkkitehtuuri muutosagenttina

Arkkitehtuuri muutosagenttina Arkkitehtuuri muutosagenttina Smarter Processes, Development & Integration Hannu Salminen CTO OP-Pohjola 2013 IBM Corporation Taustaa Nykyinen IT-arkkitehtuuri ja liiketoimintatarpeet eivät kohtaa OP-Pohjolan

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

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

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

1. kysymys: Tarjous annetaan tarjouspyynnön liitteenä olevilla kahdella lomakkeella. Voihan samassa tarjouksessa olla useampi hoitopaikka?

1. kysymys: Tarjous annetaan tarjouspyynnön liitteenä olevilla kahdella lomakkeella. Voihan samassa tarjouksessa olla useampi hoitopaikka? HUOM! TARJOUSPYYNTÖÄ ON KORJATTU 28.11.2012. Lisätieto 28.11.2012 Hammaslääkäripalvelut TRE: 7514//02.07.01/2012 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa huomioon tarjousta

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

Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille

Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille TraFin ulkoinen integraatio Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille Ohje 26.2.2014 Versio 1.1, Hyväksytty Luottamuksellinen Vastuutaho Trafi MUUTOSHISTORIA Versio Päiväys

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

Alueellisia kokemuksia elektronisen kertomuksen käytöstä

Alueellisia kokemuksia elektronisen kertomuksen käytöstä TERVEYDENHUOLLON 25. ATK-PAIVAT Kuopio, Hotelli Scandic 31.5-1.6.1999 erityisasiantuntija Anita Kokkola Suomen Kuntaliitto Elektroninen kertomus - Valtakunnallinen kertomusmaarittelytyö Alueellisia kokemuksia

Lisätiedot

Yhteentoimivuutta kokonaisarkkitehtuurilla

Yhteentoimivuutta kokonaisarkkitehtuurilla Yhteentoimivuutta kokonaisarkkitehtuurilla Terveydenhuollon atk-päivät 20.5.2014 Juha Rannanheimo Ratkaisupäällikkö, sosiaali- ja terveydenhuollon ratkaisut Esityksen sisältö Kehittämisvaatimukset sosiaali-

Lisätiedot

Veronumero.fi Tarkastaja rajapinta

Veronumero.fi Tarkastaja rajapinta Suomen Tilaajavastuu Oy Veronumero.fi Tarkastaja rajapinta Rajapintakuvaus veronumeroiden tarkastamiseen ja henkilötietojen noutamiseen Suomen Tilaajavastuu Oy Muutoshistoria Päivämäärä Tekijä Muutos 11.2.2013

Lisätiedot

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

Kirjastoverkkopalvelut-TOSU 2012 Kärki- ja kehittämishankkeet. Kristiina Hormia-Poutanen Sektorikokous 17.1.2012

Kirjastoverkkopalvelut-TOSU 2012 Kärki- ja kehittämishankkeet. Kristiina Hormia-Poutanen Sektorikokous 17.1.2012 Kirjastoverkkopalvelut-TOSU 2012 Kärki- ja kehittämishankkeet Kristiina Hormia-Poutanen Sektorikokous 17.1.2012 KDK-Asiakasliittymä Konsortion toiminnan kehittäminen OS-ohjelmistoratkaisujen kartoitus,

Lisätiedot

SIJAISET.FI KÄYTTÖOHJE TAKSI YRITYKSILLE. 1. Palveluun rekisteröityminen... 2. 2. Palveluun kirjautuminen... 2. 3. Etusivu... 2

SIJAISET.FI KÄYTTÖOHJE TAKSI YRITYKSILLE. 1. Palveluun rekisteröityminen... 2. 2. Palveluun kirjautuminen... 2. 3. Etusivu... 2 SIJAISET.FI KÄYTTÖOHJEET TAKSIAUTOILIJAT SISÄLLYS 1. Palveluun rekisteröityminen... 2 2. Palveluun kirjautuminen... 2 3. Etusivu... 2 4. Autojen lisääminen... 3 5. Kuljettajaryhmät ja niiden perustaminen...

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

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

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

Projektin tilannekatsaus

Projektin tilannekatsaus Kuntasektorin yhteinen KA Asianhallinnan viitearkkitehtuuri Projektin tilannekatsaus Heini Holopainen Kuntien Tiera Oy heini.holopainen@tiera.fi Sisältö» Taustaa Mitä tarkoitetaan viitearkkitehtuurilla

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

Yhteentoimivuutta edistävien työkalujen kehittäminen

Yhteentoimivuutta edistävien työkalujen kehittäminen Yhteentoimivuutta edistävien työkalujen kehittäminen Semantiikkaa organisaatioiden välisen tiedonvaihdon helpottamiseksi Mikael af Hällström, Verohallinto Esityksen sisältö Taustatekijöitä (OKM:n hallinnonala,

Lisätiedot

Sosiaalihuollon valtakunnallisten tjpalveluiden. I-vaihe

Sosiaalihuollon valtakunnallisten tjpalveluiden. I-vaihe Sosiaalihuollon valtakunnallisten tjpalveluiden käyttöönotto I-vaihe Tueksi pilottihankkeen suunnitteluun 4.9.2015 THL/OPER-yksikkö 1 Käyttöönoton vaiheistus I vaihe: PDF- tallennus ja tiedon saatavuus

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

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

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

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

Finnaa arkistoille. Aki Lassila Arkistot 26.11.2012

Finnaa arkistoille. Aki Lassila Arkistot 26.11.2012 Finnaa arkistoille Aki Lassila Arkistot 26.11.2012 Finnan arkkitehtuuri Asiakasliittymä rakentuu useista moduleista, jotka on integroitu toisiinsa; uusia moduleita voidaan integroida järjestelmään tarpeen

Lisätiedot

@Tampereen Testauspäivät (2012-06)

@Tampereen Testauspäivät (2012-06) @Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä

Lisätiedot

Auditointi. Teemupekka Virtanen 14.5.2010

Auditointi. Teemupekka Virtanen 14.5.2010 Auditointi Teemupekka Virtanen 14.5.2010 Lähtökohta Kaikki KANTAan liittyneet organisaatiot jakavat saman tietomassan Keskinäinen luottamus Yhteiset toimintaperiaatteet Yhteinen turvataso Minä uskallan

Lisätiedot

Julkishallinnon tunnistuksen ohjauspalvelun kehityshanke mitä PoC-vaihe on opettanut? 16.12.2014 Manne Miettinen, Henri Mikkonen ja Arto Tuomi

Julkishallinnon tunnistuksen ohjauspalvelun kehityshanke mitä PoC-vaihe on opettanut? 16.12.2014 Manne Miettinen, Henri Mikkonen ja Arto Tuomi Julkishallinnon tunnistuksen ohjauspalvelun kehityshanke mitä PoC-vaihe on opettanut? 16.12.2014 Manne Miettinen, Henri Mikkonen ja Arto Tuomi PoC arkkitehtuuri Asiointipalvelu Elisa MSSP VTJ Mobile Login

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

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty

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

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

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä Liite 5 Arkkitehtuuriperiaatteiden kuvaus Versio: 1.1 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Arkkitehtuuriperiaatteet...

Lisätiedot

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008 Meeri Nieminen Asiakkaan vaihtoehdot Asiakkaan vaihtoehdot EMCS-järjestelmän käyttöön XML-sanomarajapinta oman järjestelmän

Lisätiedot

Hankesuunnitelma. Novus-Hanke. Novus-Hanke. YYL:n tietojärjestelmien kokonaisuudistus HANKESUUNNITELMA. www.prh.fi LIITE 1

Hankesuunnitelma. Novus-Hanke. Novus-Hanke. YYL:n tietojärjestelmien kokonaisuudistus HANKESUUNNITELMA. www.prh.fi LIITE 1 Hankesuunnitelma YYL:n tietojärjestelmien kokonaisuudistus HANKESUUNNITELMA Hankesuunnitelma - Sisältö Tausta Hankkeen tavoitteet, hyödyt, riskit ja laadunvarmistus Arkkitehtuurit Kustannukset Organisaatio

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

Lisätiedot

ZENworks Application Virtualization 11

ZENworks Application Virtualization 11 ZENworks Application Virtualization 11 ZENworks / perinteinen asennus ZENworks virtualisointi Ei erillistä asennusta Ei vaadita erilisiä oikeuksia Oletusasetukset mukana Eri versiot samanaikaisesti Sama

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit

Lisätiedot

lineitä oppimisen tueksi

lineitä oppimisen tueksi Moodlen välineitv lineitä oppimisen tueksi Ennakkotehtävä Sinulle: 1. Mieti valmiiksi aihe, josta alat laatia verkkokurssia tai kurssin osaa. Verkko tutuksi -kurssilla on tavoitteena suunnitella joko kokonainen

Lisätiedot

Työajan seuranta. ValueFramen käyttäjäpäivät 30.11.2010 Matti Immonen, ValueFrame Oy. Suuntaa menestykseen

Työajan seuranta. ValueFramen käyttäjäpäivät 30.11.2010 Matti Immonen, ValueFrame Oy. Suuntaa menestykseen Työajan seuranta ValueFramen käyttäjäpäivät 30.11.2010 Matti Immonen, ValueFrame Oy Esityksen sisältö 1 2 3 Yleisesti työajan seurannasta ValueFramessa Keskeisiä parametrejä työajan seurantaa varten Työajan

Lisätiedot

Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO

Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO SUOMEN KUNTAUITTO Sosiaali - ja terveysyksikkö TERVEYDENHUOLLON 27. ATK-PAIVAT 4. - 5.6.2001 Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuksen päivät Terveydenhuollon komponentt

Lisätiedot

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

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

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Raahen kaupunki Projektiohjeet luonnos 30.11.2004

Raahen kaupunki Projektiohjeet luonnos 30.11.2004 Raahen kaupunki Projektiohjeet luonnos 30.11.2004 Vastine Kari Pietilän SDP:n valtuustoryhmän aloitteeseen Raahen kaupungin projektiohjeista (KV 25.2.2004) Pertti Malkki (FT, YTM) Kehittämiskonsultti pertti.malkki@yritystaito.fi

Lisätiedot

Kansalliskirjaston ATThankkeet

Kansalliskirjaston ATThankkeet Kansalliskirjaston ATThankkeet Esa-Pekka Keskitalo Asiantuntijaseminaari 28.4.2015 Avoin tiede tarkoittaa avoimien toimintamallien käyttämistä tieteellisessä tutkimuksessa. Keskeinen tavoite on tutkimustulosten,

Lisätiedot

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti 1 KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI Kehitysvammaliitto / Hyvät käytännöt -projekti 2 Tuotetaan käytännöstä tietoa yhdessä Käytännön kuvaamisen tarkoituksena on

Lisätiedot