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-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

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

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

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

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

TOIMINNALLINEN MÄÄRITTELY MS

TOIMINNALLINEN MÄÄRITTELY MS TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa

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

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

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

Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland

Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland 1 Sisältö Skaalautuva pilvipalvelu Käyttövaltuushallinnan käyttöönotto palveluna

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

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

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

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

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

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

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

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

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

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

VIRTA-PROJEKTI Tilanneraportti

VIRTA-PROJEKTI Tilanneraportti RAkenteellisen KEhittämisen Tukena TIetohallinto Korkeakoulujen ja opetus- ja kulttuuriministeriön yhteinen tietohallintohanke, jota CSC koordinoi VIRTA-PROJEKTI Tilanneraportti 20.8.2012, Paula Merikko

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

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

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

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

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

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

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

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

- Korkeakoulutuksen ja tutkimuksen (linkitetty) tietomalli

- Korkeakoulutuksen ja tutkimuksen (linkitetty) tietomalli 1 2 3 4 - Korkeakoulutuksen ja tutkimuksen (linkitetty) tietomalli 5 - kokonaisuus tunnetaan myös nimellä semanttisen yhteentoimivuuden viitekehys - Yhteentoimivuutta tukeva (tieto)arkkitehtuuri kokoaa

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

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

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

Julkisen hallinnon kokonaisarkkitehtuuri

Julkisen hallinnon kokonaisarkkitehtuuri Kokonaisarkkitehtuurin välineet 0.9 Päiväys 15.3.2016 15.3.2016 2 (6) Tiivistelmä Dokumenttiin on listattu keskitetysti hankitut ja koko julkisen hallinnon käyttöön tarkoitetut kokonaisarkkitehtuurin kuvausvälineet.

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

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

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

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

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

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

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

<> Palvelukuvaus versio x.x

<<PALVELUN NIMI>> Palvelukuvaus versio x.x JHS XXX ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Liite 5 Palvelukuvaus pohja Palvelukuvaus versio x.x 1/5 Sisällysluettelo 1 Johdanto...3 2 Termit ja lyhenteet...3

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

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

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

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

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

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

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

Julkisen hallinnon yhteinen kokonaisarkkitehtuuri

Julkisen hallinnon yhteinen kokonaisarkkitehtuuri Julkisen hallinnon yhteinen kokonaisarkkitehtuuri Yhteisten palvelujen kartta Määrittely 0.91 Päiväys 6.5.2017 Tiivistelmä 6.5.2017 2 (8) Yhteentoimivuutta syntyy myös erityisesti yhteisiä palveluja kehittämällä

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

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

Smart Tampere Avoin Määrittely Petri Nykänen Smart Tampere liiketoimintakehitys Tampereen kaupunkiseudun elinkeino- ja kehitysyhtiö TREDEA

Smart Tampere Avoin Määrittely Petri Nykänen Smart Tampere liiketoimintakehitys Tampereen kaupunkiseudun elinkeino- ja kehitysyhtiö TREDEA Smart Tampere Avoin Määrittely Petri Nykänen Smart Tampere liiketoimintakehitys Tampereen kaupunkiseudun elinkeino- ja kehitysyhtiö TREDEA SRV/Studio Libeskind Hanke Hanke Hankeaihio Idea, Tavoite Ideoita

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

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

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

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

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

KONSEPTIMÄÄRITYS YHTEINEN KEITTÖ HANKKEESSA OLEVIEN VIIDEN PILOTIN POHJALTA (YK-konseptimääritys)

KONSEPTIMÄÄRITYS YHTEINEN KEITTÖ HANKKEESSA OLEVIEN VIIDEN PILOTIN POHJALTA (YK-konseptimääritys) YHTEINEN KEITTIÖ HANKKEEN OSAPROJEKTI: KONSEPTIMÄÄRITYS YHTEINEN KEITTÖ HANKKEESSA OLEVIEN VIIDEN PILOTIN POHJALTA (YK-konseptimääritys) PROJEKTISUUNNITELMA 1. PROJEKTIN TAUSTATIEDOT... 3 2. YHTEINEN KEITTIÖ-HANKE

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

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

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

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

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

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

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

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

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

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

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

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

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

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