PlugIT- menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen PlugIT loppuseminaari 31.8.2004, Kuopio Juha Mykkänen Kuopion.

Esitys aiheesta: "PlugIT- menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen PlugIT loppuseminaari 31.8.2004, Kuopio Juha Mykkänen Kuopion."— Esityksen transkriptio:

1 PlugIT- menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen PlugIT loppuseminaari 31.8.2004, Kuopio Juha Mykkänen Kuopion yliopisto, HIS-tutkimusyksikkö

2 Koulutustyöpaja 2 PlugIT-menetelmätulokset terveydenhuollon organisaatioille ja sovellusten tuottajille 8:30-9 Ilmoittautuminen ja aamukahvi 9-10 Avaus, Sovellusintegraation vaiheet ja avoin integraatio 10-11 Tietojärjestelmä- ja integrointitarpeiden kartoitus 11-12 Tarpeista ohjelmisto- ja integrointivaatimuksiin 12-13 Lounas (omakustanteinen) 13-14.15 Integrointimäärittelyt ja niiden hyödyntäminen (kahvitauko) 14-15 Testaus ja PlugIT-leimausmenettely 15-16 Kokemukset menetelmäpilotista, jatkotyö

3 Iltapäivän tavoitteet vaatimuksista ratkaisuiksi: –tekniikkariippumattomat (sisällölliset ja periaateratkaisut) –tekniset ratkaisut ja rajapinnat –toteutukset ja toteutuskohtaiset seikat testaus ja leimaaminen –testaus ja testaustulokset, käyttöönotto- ja integrointitestaus, PlugIT-leima kokemuksia ohjelmistotuotannon menetelmäpilotista jatkotyö, keskustelu

4 Esitykseen liittyvää materiaalia Terveydenhuollon sovellusintegraatioratkaisujen määrittely –integrointiprosessi –tavoitteiden ja vaatimusten määrittely (käsiteltiin aamupäivällä) –tekniikkariippumaton määrittely –tekninen määrittely –toteutuskohtaisten seikkojen kuvaus –esimerkkejä Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus –toteutusten tekeminen (toinen työpaja) –määritysten mukaisuudesta varmistuminen (myöhemmin iltapäivällä) Component and service technology families –integrointitekniikat, erityisesti palvelupohjainen integraatio Ohjelmistotuotannon välineselvitys: näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen –kehitysvälineet, integrointivälineet, palvelimet jne. Standardien arviointi ja valinta

5 Integrointimenetelmän taustat Model-Driven Architecture (MDA): vaiheittainen tarkentaminen yleisestä mallista tarkkaan tekniseen ratkaisuun HL7 (Message) Development Framework: viitemallien käyttö, tietomallinnus, viestimäärittelyt Integrating Healthcare Enterprise: useita järjestelmiä kattavien työnkulkujen määrittelyt, käytännön testaus ISO RM-ODP ja 7-tasoinen yhteentoimivuusmalli: ratkaisujen kattavuus, eri näkökulmien riittävä huomiointi Hajautetut sovellukset, viitearkkitehtuuri Integrointimallit (tieto, palvelu, prosessi, käyttäjä), rajapinnat, sovittimet, avoimet tekniikat tuettava sekä paikallisista tarpeista tai valmiista ratkaisuista lähteviä ratkaisuja (bottom-up) että standardien käyttöönottoa ja soveltamista (top-down)

6 Yleiskuva Määrittelyn ja toteutusten hallinta Vaatimushankinta + dokumentointi Avoimen integrointiratkaisun määrittely Toteutus, pilotointi

7 Järjestelmäintegraatioprojektin vaiheet Tarvelähtöisyys Tavoittehakuisuus Monenvälisyys ”Oman toimen ohella” tekeminen PlugIT:issa –avoin määrittely –paikallinen tai tuotekohtainen toteutus [Saranummi, Tolppanen: Järjestelmäintegraatio-projektin vaiheet, 2003.]

8 Määrittelytyön lähtökohdat tunnistetut (ja priorisoidut) integrointikohteet (=tarpeet) kerätyt integrointivaatimukset (=tarkennetut tarpeet)!!! projektin osapuolten sovellukset –niiden nykyinen toiminnallisuus –niissä käytetyt tekniikat ja arkkitehtuurit standardit –sisällölliset ja toiminnalliset määritykset + viitemallit –käytettävissä olevat tekniikat (sovelluksissa käytetyt ja uudet) yleisiä toiminta- ja dokumentointitapoja –käytetään vain niitä dokumentteja/osioita mitä tarvitaan –perustelut valinnoille –minimitaso ja lisätasot –versionumero, pvm, tuottamiseen osallistuneet (vakiotiedot)

9 Määrittelyn eteneminen [Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3):173-182.] Vaatimukset + toiminnan kehittäminen Osallistuvien sovellusten ratkaisut Toimialan standardit ja viitemallit Tekniset standardit, työkalut Vaiheittainen tarkennus, mallit ja ohjeistus eri vaiheisiin, tavoitteena ratkaisun kattavuus ja tarkkuus, mutta selkeä, helppokäyttöinen ja toistuva menettely --SOVELTUU SEKÄ AVOIMEEN ETTÄ TAPAUSKOHTAISEEN INTEGROINTIIN

10 Top-down ja bottom-up Top-down –standardit –toimintaprosessien mallinnus –tarkentaminen, erikoistaminen –vaatimukset -> tekniikkariippumattomat -> tekniset määrittelyt -> toteutus Bottom-up –valmiit tuotteet ja ratkaisut –valmiiden ratkaisujen hankkiminen ja tutkiminen -> toteutukset, tekniset määrittelyt? –yleistäminen -> tekniikkariippumattomat, vaatimukset Molemmat tavat prosessissa mukana (esim. standardit + olemassaolevat järjestelmät määrittelyn lähtökohtina)

11 Uudelleenkäytettävät tuotokset Integrointivaatimukset –kuvata integroinnin tarkoitus ja tavoitteet riittävällä tasolla integroinnin tarkempaa määrittelyä ja toteutusta varten –yksiselitteisiä –tuotoksia verrataan ja arvioidaan suhteessa vaatimuksiin –osa (tai kaikki) vaatimuksista tarkennetaan.. Tekniikkariippumaton määrittely (ratkaisun periaatteet ja sisältö) –vastaa selkeästi rajattuun integrointitarpeeseen –ratkaisun sisältö ja perusperiaatteet (tiedot, toiminnot, osapuolet, vastuut, roolit, integrointimalli) –ei sido ratkaisua yksittäiseen tekniikkaan (voidaan soveltaa monilla tekniikoilla) Tekninen määrittely (rajapinta) –rajapinnan toteuttamista varten tietyllä valitulla rajapintatekniikalla, tarkka määritys –samasta teknisestä määrittelystä toteutetut rajapinnat eri tuotteissa toimivat yhdessä –mahdollistaa edelleen eri toteutustekniikat järjestelmissä Lisäksi tarpeen kuvata yhdenmukaisesti tietyt toteutuskohtaiset asiat

12 Tuotosten jaon tarkoitus Avoimet dokumentit tarkentuvat vaatimuksista kohti toteutusta, ”taaksepäin varmistus”: –samoihin vaatimuksiin voi(si) vastata useilla (tekniikkariippumattomilla) määrittelyillä (esim. eri integrointimalleilla) –samat tekniikkariippumattomat voi tarkentaa useilla integrointitekniikoilla toteutettaviksi (mallitason yhteensopivuus) –samat tekniset määrittelyt voi toteuttaa (siinä määritellyillä tekniikoilla) useisiin tuotteisiin Toteutuskohtaiset tai yhteen pilottiin tai määrittelyprojektiin kuuluvat asiat eivät kuulu avoimiin määritysdokumentteihin –erillään projekti- ja pilotointisuunnitelmat, taustatietoihin kuuluvat järjestelmäkuvaukset (nykytilakuvaukset) jne. PlugIT-rajapintojen TAVOITE

13 Avoimet määrittelytuotokset Integrointivaatimusmäärittelyt -käyty läpi aamupäivällä

14 Avoimet määrittelytuotokset Tekniikkariippumattomat liittymämäärittelyt

15 Mikä on tekniikkariippumaton liittymämäärittely + tavoite integrointiratkaisun kuvaus –osapuolet, yhteistoiminnan perusmalli, työnkulut –tietosisältö, toiminnot (elementit, operaatiot) –siten, että rajapinnat voidaan tarkentaa eri tekniikoilla –malli integrointiratkaisusta (~MDA PIM, IHE integration profile) (viimeistään) tällä tasolla päätetään, minkä tyyppistä integrointia tehdään Kenelle? –1. tilaajille, toimittajille ja integraattorille ratkaisun sisällön ja perusperiaatteiden määrittely (+ pohja tekniselle työstämiselle), –2. hyväksyminen, standardointi viitemalli-tasolla

16

17 Tekniikkariippumaton määrittely: tuottaminen 1.Tarkempaan määrittelyyn otettavien integrointivaatimusten rajaus ja integrointimallin valinta. 2.Määrittelyssä hyödynnettävien standardien ja muiden ulkoisten määritysten valinta. 3.Integrointitilanteessa mukana olevien sovellusten toimintojen ja tietosisällön ja niissä käytetyn arkkitehtuurin kartoittaminen integrointia varten. 4.Integroinnissa käytettävien toiminnallisten osien (sovellusroolien, komponenttien) nimeäminen tai tarkentaminen 5.Valittujen vaatimusten tarkentaminen ja kohdistaminen nimettyihin osiin. 6.Integrointitavan ja integroinnin perusratkaisuperiaatteen valinta. 7.Integrointipisteen määrittely sovellusten arkkitehtuurissa ja eri osien vastuiden määrittely, tai eri vaihtoehtojen tunnistaminen 8.Sovellusten välisen vuorovaikutuksen määrittely. 9.Sovellusten välisten liittymien sisällön määrittely tekniikkariippumattomalla tasolla. 10. Minimitason määrittely. 11. Tarkennetut vaatimukset teknisille liittymämäärittelyille ja toteutuksille.

18 Kuinka perusratkaisu määritellään sopivin integrointimalli? –tietopohjainen – usein löysä kytkentä järjestelmien välillä, tiedon ajantasaisuuden varmistukset –palvelupohjainen – päällekkäisyyden vähentäminen (tietojen syöttö, ylläpito, kehitystyö), –prosessipohjainen määrittely – monenvälisyys, –käyttäjän tukeminen ohjelmointirajapinta, viesti-integraatio, yhteinen tietovarasto, koordinaattori, käyttöliittymä? keskitetty vai hajautettu ratkaisu? (vastuiden kannalta) kahdenvälinen vai monenvälinen ratkaisu? (point-to-point vai usean sovelluksen välinen) tiukka vai löysä kytkentä? (viittaus tai tiedonsiirto, tietotyypit) hajautettu vai paikallinen rajapinta? (yhden vai monen käyttäjän) synkroninen vai asynkroninen ratkaisu? standardien tarjoamat integrointitavat?

19 Integrointiratkaisujen luokitteluja EAI – sovellusintegraatio, yleensä saman organisaation sisällä, tiukka kytkentä, ohjelmointirajapinnat, RPC B2B – kumppani-integraatio, organisaatioiden välinen, löysä kytkentä, viestit ja dokumentit, viestijonot ja -alustat B2C – asiakasintegraatio, käyttöliittymät, itsepalvelut declarative – tiedon kuvaaminen (viestin lähettäjä ja vastaanottaja) imperative – toiminnon käynnistäminen tai suorittaminen (palvelun pyytäjä ja tarjoaja) interrogative – tiedustelu (kysyjä ja vastaaja)

20 Integrointipiste sovellusarkkitehtuurissa esimerkeissä web-pohjainen laboratoriopyyntöjen teko-sovellus (System 1) käyttää hajautettua yleistä palvelua organisaatioyksiköiden listaamiseen. Tämä palvelu (System 2) taas on toteutettu kapseloimalla perinnejärjestelmän käyttöliittymä (System 3). Esimerkissä 2 integrointiratkaisua: web-pohjainen laboratoriopyyntöjen teko- sovellus (System 1) käyttää hajautettua yleistä palvelua organisaatioyksiköiden listaamiseen. Tämä palvelu (System 2) on toteutettu kapseloimalla perinnejärjestelmän käyttöliittymä (System 3).

21 Sisältö – tekniikkariippumaton määrittely 1 Johdanto – dokumentin tarkoitus jne. 2 Dokumentissa käytetyt tietotekniset ja terveydenhuollon käsitteet 3 Rajaus – mihin vaatimuksiin vastataan, mikä on määriteltyjen liittymien käyttötarkoitus 4 Käytössä olevien järjestelmien toiminnallisuus rajaukseen liittyen –tarvittaessa erilliseen nykytila-dokumenttiin 5 Käytössä olevien järjestelmien arkkitehtuurit ja tekniikat rajaukseen liittyen –tarvittaessa erilliseen nykytila-dokumenttiin 5.1 Järjestelmän A arkkitehtuuri ja tekniikat 5.2 Järjestelmän B arkkitehtuuri ja tekniikat 5.3 Muiden vastaavien järjestelmien vaikutukset (yleistettävyys) 6 Hyödynnettävien standardien ja määritysten hyväksikäyttö 7 Yhteistoiminnallisuuden arkkitehtuuri 7.1 Sovellusosien yleiset nimet ja kuvaukset 7.2 Integrointipisteet sovellusten arkkitehtuureissa 7.3 Käsitemalli, johon integrointi perustuu, esim. luokkakaavio (tarvittaessa)

22 Sisältö – tekniikkariippumaton määrittely.. 8 Katetut tieto- ja toimintokokonaisuudet 8.1 Yhteistoiminnallisuuden kuvaus (kuva kutsuista, suhteista, järjestyksestä..) 8.2 Toimintojen nimet ja kuvaukset 8.3 Tietoelementtien nimet ja kuvaukset 8.4 Sovellusten vastuut tieto- ja toimintokokonaisuuksista 8.5 Virhetilanteet 8.6 Minimitaso ja lisätasot 9 Vaatimukset teknisille liittymille ja toteutuksille osiltä osin kuin ovat tarkentuneet tai on tullut uusia integrointivaatimusten jälkeen 9.1 Toiminnalliset ominaisuudet 9.2 Ei-toiminnalliset ominaisuudet 9.3 Avoimuus, siirrettävyys ja ylläpidettävyys 9.4 Suorituskyky ja käytettävyys 9.5 Tietoturva ja virhetilanteet 10 Määrittelyjen mukaisuuden toteaminen

23 Avoimet määrittelytuotokset Tekniset määrittelyt

24 Mikä on tekninen liittymämäärittely + tavoite integrointiratkaisun kuvaus siten, että eri sovelluksiin voidaan toteuttaa sama tekninen (ja toiminnallinen/sisällöllinen) ratkaisu tarkka, lopullinen integrointimäärittely ”tämän mukaan toteutetut toimivat yhdessä” täydentää valituilla liittymätekniikoilla tekniikkariippumatonta määrittelyä –sama liittymätekniikka käytössä osallistuvissa sovelluksissa (avoimia tekniikoita esim. XML, IDL, WSDL, SOAP) – sovellukset voidaan silti toteuttaa eri tekniikoilla (Java, MS.NET, M, xx) osien tekniset vastuut EI sisäisen tai tuotekohtaisen toteutuksen asioita vaan ulospäin näkyvät tekniset liittymät Kenelle? –1. integroinnin (esim. sovelluksiin sovittimien) toteuttajalle, tekniselle asiantuntijalle –2. hyväksyminen, tarkka tekninen standardointi

25

26 Tekniset määrittelyt: tuottaminen 1.Toiminnallisista määrittelyistä tai valmiista toteutuksista teknisiksi määrittelyiksi tuotettavien asioiden valinta. 2.Valittaviin tekniikoihin kohdistuvien vaatimusten tarkentaminen 3.Sovelluksissa käytettyjen mahdollisten integroinnissa käytettävien tekniikoiden kartoitus. 4.Käyttökelpoisten uusien tekniikoiden ja teknisten standardien kartoitus 5.Aikaisemmissa projekteissa tehtyjen ratkaisujen hyödyntämistavasta päättäminen. 6.Soveltuvien integrointitekniikoiden valinta ja perustelut 7.Yhteentoimivuuden perusarkkitehtuurin tarkentaminen valittujen tekniikoiden mukaisesti 8.Teknisten osien nimeäminen, esim. ”pyyntöpalvelun toteuttava DLL-kirjasto”, ”koodistopalvelun toteutus” 9.Osien teknisten vastuiden määrittely 10.Kutsuttavien operaatioiden ja tietosisällön määrittely valituilla tekniikoilla 11.Minimitason määrittely (tarvittaessa) 12.Osien vuorovaikutuksen kuvaaminen (tarvittaessa) 13.Toteutuskohtaiseksi jätettävien seikkojen määrittely ja dokumentointi, vaatimukset toteutuksille ja niiden dokumentaatiolle 14.Kokeilut (proof-of-concept) ja tarkentaminen, viittaukset toteutettuihin esimerkkeihin tai referenssitoteutukseen

27 Tekniset määrittelyt - sisältö 1 Johdanto – dokumentin tarkoitus jne. 2 Rajaus – mihin vaatimuksiin ja toiminnallisiin määrittelyihin liittyy 3 Tekniikoihin kohdistuvat vaatimukset 4 Käytössä olevien järjestelmien hyödynnettävissä olevat tekniikat, perusteluiksi valituille tekniikoille 4.1 Järjestelmän A tekniikat ja välineet 4.2 Järjestelmän B tekniikat ja välineet 4.3 Muiden järjestelmien vaikutukset, yleistys 5 Hyödynnettävissä olevat tekniset standardit ja määritykset (tarvittaessa) 6 Valitut tekniikat, luettelo ja perustelut valinnoille 7 Integroinnin arkkitehtuuri valitulla tekniikalla: tekniset sovellusosat ja niiden vastuut, liittymät, tietoliikenne 8 Operaatioiden ja tietosisällön tekniset määrittelyt 8.1 Kaavio osien vuorovaikutuksesta, kutsusuhteista ja järjestyksistä jne. 8.2 Operaatiokuvaukset valitulla tekniikalla (operation signatures) 8.3 Tietokuvaukset valitulla tekniikalla (operaatioiden parametreista tai muuten siirrettävästä tiedosta, voi olla myös yhdistettynä operaatiokuvauksiin) 8.4 Virhetilanteet ja virhekoodit, toiminta virhetilanteissa 8.5 Minimitaso ja lisätasot 9 Toteutuskohtaiseksi jätettävät asiat: konfigurointi, siirrettävyys, mahd. liikenteen salaus jne. 10 Vaatimukset järjestelmille: palvelun tarjoava järjestelmä, palvelua käyttävä järjestelmä, alustavaatimukset, käytettävät välinevaatimukset 11 Määrittelyjen mukaisuuden toteaminen, esim. lista tarkastettavia piirteitä 12 Esimerkkejä (tarvittaessa esim. palvelimen ja asiakkaan toteutuksesta), osoitteet referenssitoteutuksiin jne.

28 Integrointitekniikoiden valinta Mikä on valittu integrointimalli ja –tapa? Miten hyödynnetään jo käytössä olevia tekniikoita ja infraa? Mitä uusia tekniikoita halutaan / on otettavissa käyttöön? Onko ulkoisissa määrityksissä joita halutaan käyttää teknisiä asioita? Halutaanko erottaa tietosisältö ja toiminnallisuus? –voi valita myös useita integrointitekniikoita – tiedon merkkaus, operaatioiden määrittely, tietoliikenne… –tai määritellään rajapinta, jonka kautta käsitellään erikseen viitattuja sisältöjä (PlugIT-potilasrajapinta, PlugIT-koodistorajapinta) Synkroninen / asynkroninen? Ratkaisun avoimuusvaatimukset? Tekniikoiden levinneisyydet ja kehitysnäkymät?

29 1. Komponenttipohjainen integrointi (useamman sovelluksenkäyttämä komponentti, esim. potilaan tunnistus), nykytila 2,22 Tavoitetaso 3,75 2. Väyläpohjainen integrointi (esim. CORBA broker), nykytila 1,25 Tavoitetaso 1,86 3. Viestipohjainen integrointi (esim. HL7 –sanomarajapinta), nykytila 2,50Tavoitetaso 2,86 4. XML-pohjainen integrointi, nykytila 2,44 Tavoitetaso 3,86 5. Tiedon välitys yhteisen tietoalueen tai tietokannan kautta, nykytila 2,89 Tavoitetaso 2,71 6. Web service –tekniikka, nykytila 1,25 Tavoitetaso 3,00 7. Tietoverkon yli tapahtuva integrointi ja palvelujen käyttö, nykytila 1,80 Tavoitetaso 3,14 8. Samaan koneeseen asennettujen sovellusten välinen integrointi, nykytila 2,80 Tavoitetaso 2,71 9. Toisen sovelluksen käyttöliittymän kutsuminen, nykytila 1,89 Tavoitetaso 2,29 10. Käyttöliittymän tarjoaminen toiselle sovellukselle, nykytila 1,90 Tavoitetaso 2,14 11. Määräajoin eräsiirtona tapahtuvat tiedonsiirrot, nykytila 3,20 Tavoitetaso 2,86 12. Ulkoiseen standardimäärittelyyn (esim. HL7) perustuva integroinnin toteutus, nykytila 2,70Tavoitetaso 3,14 13. Kahden väliseen sopimiseen perustuva integroinnin toteutus, nykytila 2,60 Tavoitetaso 2,29 14. Taustarekisterien ja koodistojen käyttö API kautta, nykytila 2,00 Tavoitetaso 2,50

30

31 Liittymien määrittely eri tekniikoilla Yhdessä ratkaisussa käytetään usein monia tekniikoita Dokumentoidaan eri tekniikoilla eri tavoin, esim. (palvelupohjainen integraatio) –palvelun löytäminen –operaatioiden määrittely –tietosisällön (parametrien, paluuarvojen) määrittely –tietoliikenne tai tiedon välitys –salaus tai muut turvallisuustekniikat –alustavaatimukset –tarvittavat välineet

32 MethodIsCodeValid Interface Codeset KäyttötarkoitusKoodiarvon olemassaolon tarkistaminen tietyssä koodistossa, sovelluksen kentässä olevan koodin oikeellisuuden varmistaminen ParamtermSystem-elementti, jonka id-attribuutissa koodiston tunniste version-attribuutissa tarvittaessa koodiston version tarkenne term-elementti, jonka id-attribuutissa validoitava koodiarvo Responsevalue-elementti, jonka arvona 0 (ei validi koodiarvo) tai 1 (validi koodiarvo) KuvausKäytetään, jos halutaan varmistua siitä, löytyykö koodiarvo koodistosta tai sen versiosta PakollisuusPakollinen perustasolla ”base”. LisätietojaKs. myös Code-rajapinnat (koodin voimassaolo ja paikallisuus) PoikkeuksetGeneralFailure, NotImplemented, MissingParameter, UnknownCodeSystem VaatimuksetK2.9 Kutsu esim. Codeset IsCodeValid

33 Määritysten hyödyntäminen, toteutukset + toteutuksen kuvaus

34 Rajapinnan toteutustilanteet Tuoteominaisuuksien suunnittelu, ”yleinen” –pyrkimys yleiskäyttöisyyteen, toistettavuuteen –standardit, ”pilkuntarkkuus”, sertifiointi –”meillä on tämän standardin mukaan tehty rajapinta, jos noudatatte samaa standardia integrointi on nopeaa” –konfiguroitavuus eri ympäristöihin, eri käyttötapoihin Tilauksesta tehtävä, ”kahdenvälinen” –aikataulupaineet, uudet tarpeet –tunnetaan paikalliset erityisvaatimukset –johtaa oikein tehtynä ”yleinen”-tilaan, tuoteominaisuudeksi tunnistetaan, mitkä ratkaisut ja vaatimukset ovat ”paikallisia”

35 Avoimen määrityksen hyödyntäminen 1 Sovelluksen vaatimukset ja määrityksessä kuvattu ratkaisu –integrointitilanne tai integrointitarve sovelluksen (asiakkaan) kannalta, mihin vaatimuksiin integrointimääritys vastaa, mikä määritysversio onko määrityksessä tasoja, vaaditaanko lisäpiirteitä Sisällöllinen & tekniikkariippumaton tarkastelu –missä roolissa sovellus on, onko toiminnot ja tiedot joita määrityksessä käsitellään, sovelluksen työnkulut, mikä sovelluksen osa liitetään, onko varauduttava siihen että ratkaisua ei käytetä jossain tilanteessa Liittymätekniikan sovitus sovellukseen –onko jo käytetty liittymätekniikoita, niitä tukevat välineet ympäristöön, valmiit kirjastot ja sovittimet tai itse toteuttaminen Toteutus ja testaus –määrityksessä toteutuskohtaiseksi jätetyt asiat, yleiset vaatimukset –valmiin kirjaston tai adapterin liittäminen sovellukseen, liittymätekniikoita tukevilla välineillä toteutus sovellukseen tai ”matalan tason koodauksella” alusta loppuun –dokumentointi, toteutuksen kuvaus, testaus ennen käyttöönottoa, testipalvelut, sertifiointi –kokemusten ja lisätarpeiden kerääminen myöhempiä integrointitarpeita varten –palaute määritysten tekijöille

36 Avoimen määrityksen hyödyntäminen 2 Paikallinen sovitus –kallista, jos toistuvaa ja työlästä –pyrkimys kohti toisiaan täydentäviä standardeja, ”integration profiles” –aina jotain paikallisesti sovitettavaa, voidaan varautua konfigurointimekanismeilla tuotteessa –”vastapuolelta varmistukset” toteutuksen kuvaus – toteutuskohtaisuuksien vastaavuus onko vastapuolella sertifikaatit tai testausraportit standardin mukaisuudesta –tuoteominaisuuksien lisäksi? paikallisten vaatimusten huomiointi, ”standardin venytys”, erotetaan avoimesta ratkaisusta poikkeamat määrittelystä, joudutaan sopimaan kaikkien osapuolten kanssa Käyttöönotto, ylläpito –testaus lopullisessa käyttöympäristössä –käyttöönotto, ohjeistus, vastuutus, koulutus –uusien versioiden, toimivuus edellisen version ratkaisujen kanssa (regressiotestaus) –rajapintojen versiot, päivitysten ajoitukset, useiden versioiden tukeminen?

37 Mitä ovat Toteutuksen kuvaukset + tavoite Toteutuksen kuvaus –dokumenttiin –tuotekohtainen dokumentti, osa sen dokumentaatiota esitystapa ”vapaa mutta pakollinen” ”kuinka tämä sovellus/komponentti asennetaan ja integroidaan, kun siinä on määrittelyn X mukainen tekninen liittymä” alustavaatimukset, saatavilla olevien muiden ohjelmistojen tai rajapintojen tuki kuinka se mukautetaan suoritusympäristöön kuinka toteutus vastaa esitettyihin vaatimuksiin onko toteutuskohtaisia lisäpiirteitä tai poikkeamia avoimiin määrittelyihin Ei (nimestä huolimatta) ole ohje, kuinka toteutus tehdään –sitä varten erillisiä soveltamisoppaita, esimerkkejä Kenelle? –1. sovelluksen käyttöönottajalle ja asentajalle (ohje) –2. asiakkaalle (tällainen ”standardi-integraatio” kuuluu tuotteeseen), näin on ratkaistu tässä toteutuksessa toteutuskohtaiset asiat, lisäpiirteet ym.

38 Toteutuksen kuvaus – sisältö esim. 1 Johdanto 2 Rajaus –mitkä vaatimukset, toiminnalliset määrittelyt, mitkä tekniset liittymämäärittelyt-toteutus 3 Suhteet määriteltyihin vaatimuksiin ja yleisiin liittymiin 3.1 Miten toteutus vastaa integrointivaatimukset-dokumentin vaatimuksiin ”määrittelyjen mukaisuuden toteaminen” kohtiin vastaaminen 3.2 Miten toteutus vastaa toteutuskohtaisiksi jätettyihin vaatimuksiin (suorituskyky- laatuvaatimusten, toteutuskohtaiset seikat) 3.3 Minimitaso ja lisätasot 3.4 Toteutuskohtaiset lisäykset ja laajennukset teknisiin määrittelyihin 3.5 Toteutuskohtaiset poikkeamat ja rajoitteet teknisistä määrittelyistä 4 Toteutuksen asettamat vaatimukset tekniselle ympäristölle käyttöjärjestelmäriippuvuudet, vaaditut päivityspaketit ja kirjastojen versiot, tarvittavat palvelimet, versiot, lisenssit, siirrettävyys, jakelumekanismit 5 Toteutuksen käyttöönotto 5.1 Toteutuksen asennus (tarvittaessa, jos ei sovelluksen asennuksen yhteydessä) 5.2 Integroinnin toteutuksen asetusten tekeminen ja konfigurointi esim. palvelun kutsuosoite, dll-tiedoston nimen välitys, ulkoiset parametrit 5.3 Ylläpito, uudet versiot 6 Esimerkkejä toteutetun ratkaisun käytöstä (suositellaan), 7 Toteuttajan tukipalvelut, yhteystiedot.

39 Välinevalinnat Tuettava valittuja integrointitekniikoita ja haluttua suoritus- ja kehitysympäristöä (+ oppimiskynnys + halutut ominaisuudet + elinkaari…) mallinnus, toiminnanohjaus, komponenttitoteutus, sovittimet, liittymästandardit, integrointialustat, ohjelmointikielet, middleware (etäohjelmakutsu, viestijono, TP monitor, oliosanomavälitin, tietokanta), XML (Ainakin osin) eri välineet eri integrointitapoihin ja -malleihin Erityispiirteitä integrointivälineissä –Useita eri lähteitä hyödyntävälle tai eri protokollia käyttävä viestinvälitykselle (http, viestijonotuotteet ja -standardit, sähköposti, ftp, tiedostot, tietokantaliittymät, olio- ja palveluprotokollat kuten SOAP, IIOP ja COM) –Mahdollisuus välittää tietoa kahdenvälisesti tai monenvälisesti –Tiedon muodon muunnokset, esim. ohjelmointikielen tietotyypeistä määritellyn XML- rakenteen elementeiksi tai IDL-liittymän attribuuteiksi ja tietotyypeiksi (ja päinvastoin), dokumenttien muunto rakennemäärittelystä toiseen –Tiedon ja metatiedon vastaavuuksien määrittely osallistuvissa järjestelmissä ja määrittelyn pohjalta tapahtuvat konversiot, erityisesti ulkoisesta (standardi ‑ ) määrittelystä automaattisesti generoitavat sovellusosat –Tuki tai sovittimet useille suoritusalustoille ja ohjelmointikielille tai sovelluskehittimille –Tuki useille sisällöllisille standardeille, kuten HL7, SWIFT, EDI jne. –Mahdollisuus lisätä ulkopuolisten osapuolten tekemiä sovittimia –Tuotteeseen integroidut toimintaprosessien hallinta- ja työnkulun ohjausominaisuudet [Ohjelmistotuotannon välineselvitys – näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen]

40 Yhteenveto, keskustelu

41 Erityyppiset ratkaisut Avoin koodistorajapintaPatologian pyyntö- komponentti VaatimuksetYleiset käyttö- ja ylläpitotarpeet Paikalliset tarpeet (patologia-gastro) TekniikkariippumatonMallit standardeista korostuneet Vaatimustenhankinta osapuolilta TekninenHajautetut ydinpalvelut (http + XML) Paikallinen kirjasto (DLL, XML), komponentti ToteutuksetReferenssitoteutus, alueellinen / organisaation toteutus Tuotetoteutus IntegrointimalliPalvelupohjainenTieto- ja palvelupohjainen (+käyttöliittymä) PäähyödytUudelleenkäyttö, vähent. päällekkäisyys, keskitetyt palvelut + tiedot Nopea toteutus, sovellusmuutosten pieni määrä, prosessihyödyt Muuta erityistäStandardien suora käyttö ei mahdollista, vaatii sovelluksilta mukautumista Ei standardia, tarkka ratkaisu erikoistilanteeseen

42 Kokemuksia monenvälisestä integroinnista 9 tiimiä, 14 integrointikohdetta, eri tyyppisiä tarpeita Integroinnin määrittely ja toteutus –Integrointialueen tuntemus välttämätöntä ratkaisun määrittelyssä –Kiireellisimmät integrointitarpeet mukaan ensimmäiseen iteraatioon (määrittelystä toteutukseen), uudet versiot –Määrittely ja toteutus järkevää erottaa omiksi “projekteikseen”, varsinkin avoimissa määrittelyissä (toteutushyödyt, kilpailuetujen suojelu) –Uusien ratkaisujen ja tekniikoiden vähittäinen sisäänajo, migraatio sovelluksille ja asiakkaille, referenssitoteutukset Standardit ja tuotekohtaiset seikat –Standardeilla, tekniikoilla ja välineillä vaikutuksia monille eri tasoille, mutta eri osapuolilla ei resursseja arvioida kaikkia vaikutuksia –Top-down: Toimialakohtaisten standardien tulisi perustua yleisiin avoimiin standardeihin –Bottom-up: Ratkaisujen sitominen/kerääminen olemassa olevista sovelluksista, yleistäminen avoimeksi (suunnittelukäytännöt, harmonisointi, standardointiprosessi) –Ratkaisujen arviointi ja sertifiointi tarpeen, ulkoinen taho –Joustavuus (heterogeenisyys) avoimilla tekniikoilla ja tiedon erottamisella toiminnallisuudesta Monenväliset integrointiprojektit –Osallistujilla “eri aloilta” erilaiset taidot, erilainen kieli –Johdon sitoutuminen – vaatimukset, resurssit, aikataulu –Neutraali moderaattori määrittelyssä, “konsultti” toteutuksessa –Toteutus/tilaajakohtaiset seikat (jakelu, ylläpito, omistajuus) erilleen avoimista määrityksistä [Mykkänen, Porrasmaa, Korpela, Häkkinen, Toivanen, Tuomainen, Häyrinen, Rannanheimo. Integration Models in Health Information Systems: Experiences from the PlugIT project. Medinfo 2004].

43 Integroinnin määrittely –sovelletaan eri tavoin erilaisissa integrointitilanteissa –taustaselvitys- ja analyysitarve vaihtelee  ”älä jumiudu taustoihin” (analysis paralysis) –määritykset ja standardit validoidaan toteutuksilla  palaute määrityksiin, versiointi –määrittelypohja käytettävissä myös integrointiratkaisujen arviointiin Määritysten hyödyntäminen –integraation toteutuksissa tuotteisiin, sovittimien rakentamisessa –tarjouspyynnöissä Seuraavaksi –testaus, määrittelyjen mukaisuus –soveltamiskokemuksia ohjelmistotuotannon menetelmistä

44

45 Yleistäminen (avoimessa määrittelyssä) järjestelmistä yleisnimet, ”actors” nykyjärjestelmien ja nykytilan kuvaus erillään avoimista määrittelyistä tiedot ja toiminnot tarvittaessa määriteltynä erikseen avoimien määrittelydokumenttien tasot (ks. ”Tuotosten jaon tarkoitus”) varsinkin ”tekniset määrittelyt” tasolla avoimien tai paljon käytettyjen tekniikoiden valinta määrittelyjen kommentointi monelta osapuolelta, hyväksyminen, standardointi