Soveltamiskokemuksia ohjelmistotuotannon menetelmistä

Koko: px
Aloita esitys sivulta:

Download "Soveltamiskokemuksia ohjelmistotuotannon menetelmistä"

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3 STUDIES AND REPORTS OF THE PLUGIT PROJECT 3 Annamari Riekkinen, Kirsi Karvinen, Hannu Virkanen, Kirsi Reponen, Pauliina Ikävalko, Ritva Silvennoinen, Saara Savolainen, Jari Porrasmaa ja Pertti Laitinen Soveltamiskokemuksia ohjelmistotuotannon menetelmistä Vaatimusmäärittely, käyttöliittymäsuunnittelu, arkkitehtuurisuunnittelu, toteutus ja testaus KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Annamari Riekkinen Kirsi Karvinen Hannu Virkanen Pauliina Ikävalko Ritva Silvennoinen Saara Savolainen Jari Porrasmaa HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Kirsi Reponen Pertti Laitinen Shiftec-tutkimusyksikkö, Terveyshallinnon ja -talouden laitos Kuopion yliopisto Myynti: Tietotekniikkakeskus / Kanslia Kuopion yliopisto puh. (07) tike@uku.fi ISBN (koko teos) ISBN (osa 3) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Riekkinen, Annamari; Karvinen, Kirsi; Virkanen, Hannu; Reponen, Kirsi; Ikävalko, Pauliina; Silvennoinen, Ritva; Savolainen, Saara; Porrasmaa, Jari; Laitinen, Pertti. Soveltamiskokemuksia ohjelmistotuotannon menetelmistä: vaatimusmäärittely, käyttöliittymäsuunnittelu, arkkitehtuurisuunnittelu, toteutus ja testaus..painos. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 3) ISBN (PDF) Tiivistelmä Teknisten tietojärjestelmien ja ohjelmistojen rooli toiminnanohjausjärjestelminä kasvaa koko ajan. Nykyisiltä ohjelmistoilta ja ohjelmistokehitykseltä tämä edellyttää paremmin yhteen toimivia ja toimintaa kokonaisvaltaisemmin tukevia järjestelmiä. Hajautettujen järjestelmien kehittämiseen tarkoitetut komponentti- ja palvelupohjaiset tekniikat mahdollistavat tällaisten järjestelmien toteutuksen, mutta järjestelmien kehittämisen ja ylläpidon kannalta tarvitaan tietoa erilaisista komponentti- ja palvelupohjaiseen ohjelmistotuotantoon soveltuvista menetelmistä. Tässä raportissa on koottu menetelmäpilotti Pakkasessa saatuja kokemuksia erilaisten ohjelmistotuotannon menetelmien ja tekniikoiden soveltamisesta. Pakkasen menetelmäkokemukset liittyvät ohjelmiston vaatimusmäärittelyyn, käyttöliittymäsuunnitteluun, arkkitehtuurisuunnitteluun, komponenttien ja komponenttipohjaisen sovelluksen toteuttamiseen sekä testaukseen. Menetelmäkokeilut toteutettiin määrittelemällä ja suunnittelemalla uudestaan Kuopion yliopiston käyttäjätunnusten hallinnassa käytössä oleva Pakka-sovellus tärkeimpien toimintojen osalta. Raportissa esitettäviä soveltamiskokemuksia havainnollistetaan menetelmien soveltamisessa syntyneiden esimerkkien avulla. Yleinen kymmenluokittelu UDK: 68.3, 002 Asiasanat (YSA): systeemityö, tietojärjestelmät, ohjelmistotekniikka, ohjelmointiympäristö, tietokannat, tiedonhallinta, tiedonhallintajärjestelmät, ohjelmointi, oliokeskeisyys, tietoteollisuus, terveydenhuolto Medical Subject Headings (MeSH): software, information systems, information management, database management systems, health care sector, medical informatics, hospital information systems

4 4 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

5 Esipuhe Tämä raportti on tehty PlugIT-hankkeessa vuosina toteutetussa menetelmäprojekti Pakkasessa. Raportin tavoitteena on koota käytännön soveltamisen kautta saadut kokemukset erilaisista ohjelmistotuotannon menetelmistä ja tekniikoista. Raportti on tarkoitettu ohjelmistotoimittajille ja heidän asiakkailleen. Lisäksi tarkoitus on, että raporttia voidaan hyödyntää jatkotutkimuksissa. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Kiitämme erityisesti menetelmäkokeilun asiakasorganisaation edustajia Olavi Mannista ja Sirkka Eskelistä. Kiitämme myös kaikkia menetelmäkokeiluun osallistuneita projektin työntekijöitä sekä projektiin osallistuneiden yritysten ja sairaaloiden edustajia. Kuopiossa 30. elokuuta 2004 Tekijät SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 5

6 6 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

7 Sisällys JOHDANTO...9. PlugIT-projekti Pakkanen pähkinänkuoressa Raportin rakenne VAATIMUSMÄÄRITTELY ARKKITEHTUURI- JA KOMPONENTTISUUNNITTELUN NÄKÖKULMASTA Johdanto Pakkasen vaatimusmäärittelyn lähtökohdat Pakkasen vaatimusmäärittelyn eteneminen Kokemuksia vaatimusmäärittelyssä käytetyistä menetelmistä ja tekniikoista Johtopäätökset ja pohdinta KÄYTTÖLIITTYMÄSUUNNITTELU Suunnittelun lähtökohdat Pakkasen vaatimusmäärittelyn ja käyttöliittymäsuunnittelun eteneminen Johtopäätökset ARKKITEHTUURI- JA KOMPONENTTISUUNNITTELU Johdanto Lähtökohdat arkkitehtuuri- ja komponenttimäärittelyyn Pakkasen arkkitehtuuri- ja komponenttisuunnittelu Johtopäätökset TEKNINEN SUUNNITTELU JA TOTEUTUS Tekniselle ratkaisulle ja toteutukselle asetetut esiehdot ja vaatimukset Tekninen suunnittelu ja arkkitehtuuriratkaisu Teknologia- ja välinevalinnat Toteutus kerroksittain Arkkitehtuurin ja toteutuksen arviointi Toteutusten esittely Lisätietoja TESTAUKSEN SUUNNITTELU JA TOTEUTUS Johdanto Testausmenetelmä Testauksen toteutus Johtopäätökset...53 LÄHTEET...55 Liite : Sanasto Liite 2: Käyttäjätunnusten hallinta kuvattuna työtoiminnan mallissa Liite 3: Prosessikaavioesimerkki: Käyttäjätunnuksen luonti monitoimijaisena työprosessina Liite 4: Prosessikaavioesimerkki: Käyttäjätunnuksen luonti käyttäjän työtehtävänä Liite 5: Komponenttimäärittelymenetelmä Liite 6: Ohjelmistotuotannon V-malli SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 7

8 8 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

9 JOHDANTO. PlugIT-projekti PlugIT on vuosina toteutettu valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuottaa avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena on tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla (PlugIT 2004)..2 Pakkanen pähkinänkuoressa Pakkanen on PlugIT-hankkeessa projektina toteutettu menetelmäpilotti, jossa on kokeiltu hankkeessa kehitettyjä ja tutkittuja komponenttipohjaiseen ohjelmistotuotantoon soveltuvia menetelmiä. Komponentti- ja palvelupohjaista lähestymistapaa käsitellään muun muassa lähteissä (Cheesman ja Daniels 200; Mykkänen ym. 2004b; Karvinen ym. 2004; Mykkänen 2000; Kähkipuro 2000; Katehakis 2000). Menetelmäkokeilujen taustalla oli näkemys siitä, että nykyiset hajautettujen järjestelmien kehittämiseen tarkoitetut komponentti- ja web-teknologiat tarjoavat runsaasti mahdollisuuksia toimintaa tehostavien tietojärjestelmäratkaisujen toteuttamiseksi, mutta koko ohjelmistotuotantoprosessin kannalta tekniikoita tukevista menetelmistä on suhteellisen vähän tietoa. Siksi Pakkasessa lähtökohtana olivat komponentti- ja palvelupohjaiset tekniikat, joiden hyödyntämiseksi etsittiin komponenttipohjaiseen ohjelmistotuotantoon soveltuvia menetelmiä. Menetelmäkokeilujen perustaksi valittiin Cheesmanin ja Danielsin (200) esittelemä, Rational Unified Process eli RUP-malliin perustuva, komponenttipohjaisen ohjelmistotuotannon prosessimalli (kuva.). Prosessin eri vaiheisiin valittiin sovellettavaksi PlugIT-hankkeessa tutkittuja ja/tai kehitettyjä menetelmiä. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 9

10 Käyttötapaukset Vaatimusmäärittely Olemassa olevat komponentit, sovellukset, mallit ym. Käsitemalli Tekniset rajoitukset Komponentit Määrittely Suunnittelu Hankinta Toteutus Kokoaminen Sovellukset Komponenttimäärittelyt ja arkkitehtuurit Testaus Testatut sovellukset Ylläpito Käyttöönotto Kuva.. Komponenttipohjainen ohjelmistotuotantoprosessi (Cheesmanin ja Danielsin prosessia mukaillen Mykkänen 2002) Ohjelmistotuotantoprosessi etenee niin, että aluksi vaatimusmäärittelyvaiheessa määritellään ja kuvataan tuotettavan ohjelmiston vaatimukset. Määrittelyvaiheessa vaatimuksista johdetaan ohjelmistokomponenteista koostuva palveluarkkitehtuuri ja määritellään komponenttien rajapinnat. Seuraavaksi hankitaan sopivat komponentit ostamalla, ottamalla käyttöön olemassa olevia komponentteja ja/tai toteuttamalla ne itse. Kokoamisvaiheessa ohjelmisto koostetaan komponenteista, minkä jälkeen suoritetaan koko ohjelmiston testaus. Huolellisen testauksen jälkeen komponenttiohjelmisto voidaan asentaa ja ottaa käyttöön suoritusympäristössään. Ohjelmistoa päivitetään vaihtamalla komponentteja uusiin versioihin tai kokonaan uusiin komponentteihin. Pakkasessa menetelmäkokeilut toteutettiin uusimalla Kuopion yliopiston käyttäjätunnusten hallintaan tarkoitettu Pakka-sovellus tärkeimpien toimintojen osalta. Projekti toteutettiin kahdessa vaiheessa (kuva.2). Käsitemalli Käyttöliittymäsuunnittelu Vaatimusmäärittely Käyttötapaukset Luo käyttäjätunnus Vaatimusmäärittely Arviointi Määrittely Suunnittelu Hankinta Toteutus Kokoaminen Komponenttien ja sovellusarkkitehtuurin määrittely Tekniikkavalinnat Määrittely Suunnittelu Toteutus Komponenttimäärittelyt ja arkkitehtuurit Testaus Sovellus Määrittelyjen sijoitus toteutustekniikoihin toteutus Data Testattu sovellus Kuva.2. Vasemmanpuoleinen kaavio esittää Pakkasen ensimmäisen vaiheen etenemisen yhden käyttötapauksen osalta. Oikealla oleva kaavio kuvaa menetelmäkokeilujen kattavuuden toisessa vaiheessa. 0 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

11 Menetelmäkokeilun ensimmäisessä vaiheessa opiskeltiin vaatimusmäärittelyyn ja komponenttimäärittelyyn valittuja menetelmiä määrittelemällä, suunnittelemalla ja toteuttamalla yksi nykyisen Pakka-järjestelmän käyttötapaus: käyttäjätunnuksen luonti. Ensimmäisen vaiheen tavoitteena oli päästä suhteellisen nopeasti toteutuskokeiluihin ja arvioida siltä pohjalta tarkemmin kuinka kattavia johtopäätöksiä tekniikoiden soveltuvuudesta voidaan tehdä. Toisessa vaiheessa keskityttiin kohdealueen toiminnan syvällisempään tarkasteluun käyttöliittymäsuunnittelun roolin korostumisen myötä. Myös komponenttimäärittelyä tehtiin niin, että käyttöliittymäsuunnitelma oli siinä apuna. Laadunvarmistusta mietittiin koko ohjelmistotuotantoprosessin osalta, mutta erityisesti kiinnitettiin huomiota ohjelmiston järjestelmä- ja hyväksymistestauksen suunnitteluun. Toteutuskokeiluja jatkettiin niin, että ensimmäisessä vaiheessa toteutetuista komponenteista sekä toisessa vaiheessa käyttöliittymäsuunnittelun tuloksena saaduista näyttökuvista koostettiin sovellusosa. Toisen vaiheen tavoitteena oli koota menetelmäkokeiluissa saadut kokemukset ohjelmistotoimittajien käyttöön. Kuvassa.3 on havainnollistettu kokemusten pohjalta syntynyt tulos ohjelmistotuotantoprosessin näkökulmasta.. Vaatimusmäärittely ja käyttöliittymäsuunnittelu Käyttötapaukset Käyttöliittymäsuunnitelma Testaussuunnitelma (hyväksymis- ja järjestelmätestaus) Tietomalli (käsitemalli) Olemassa olevat komponentit, sovellukset, mallit ym. Tekniset rajoitukset Komponentit Määrittely Suunnittelu Hankinta Toteutus Kokoaminen Komponenttimäärittelyt ja arkkitehtuurit Testaus Sovellukset Testatut sovellukset Ylläpito Käyttöönotto Kuva.3. Komponenttipohjainen ohjelmistotuotantoprosessi, jota on täydennetty Pakkasen menetelmäkokeilujen tuloksilla. Prosessinäkökulmasta Pakkasessa on siis hahmoteltu polku vaatimusten määrittelystä arkkitehtuurisuunnittelun kautta toteutukseen niin, että ohjelmiston laadunvarmistus otetaan huomioon alusta asti. Prosessia ei kuitenkaan ole testattu todellisessa ohjelmistokehitysprojektissa, joten tässä esitetty malli tarjoaa yhden lähtökohdan menetelmäkehitystyölle uusissa hankkeissa. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ

12 .3 Raportin rakenne Raportti on koottu artikkelikokoelman muotoon siten, että sen rakenne noudattaa prosessin vaiheita (kuva.4). Jokaisessa luvussa esitellään käytetyt menetelmät, kuvataan pääpiirteittäin tehtävien eteneminen ja käsitellään soveltamisen myötä saatuja kokemuksia. Raportin johdannossa esitellään lyhyesti menetelmäpilotti Pakkanen. Toinen luku käsittelee toteutettua vaatimusmäärittelyä, jossa toimintalähtöisyys on keskeisessä asemassa. Käyttöliittymäsuunnittelu esitetään luvussa kolme ja luvussa neljä käydään läpi sovellettu arkkitehtuuri- ja komponenttisuunnittelumenetelmä. Viides luku sisältää kokemuksia sekä komponenttien toteutuksesta että sovelluksen koostamisesta. Kuudennessa luvussa käsitellään laadunvarmistusta pääasiassa järjestelmä- ja hyväksymistestauksen osalta. Johdanto LUKU 2 Vaatimusmäärittely LUKU 3 Käyttöliittymäsuunnittelu LUKU 4 Arkkitehtuuri- ja komponenttimäärittely LUKU 5 Komponenttien toteutus LUKU 5 Ohjelmiston kokoaminen LUKU 6 Testaus Ylläpito Käyttöönotto Kuva.4. Raportin rakenne ohjelmistotuotantoprosessissa. 2 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

13 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN 2 VAATIMUSMÄÄRITTELY ARKKITEHTUU- RI- JA KOMPONENTTISUUNNITTELUN NÄKÖKULMASTA 2. Johdanto Luvussa kuvataan pääpiirteittäin menetelmäpilotti Pakkasen vaatimusmäärittelyn lähtökohdat, vaatimusmäärittelyssä sovelletut menetelmät ja vaatimusmäärittelyn eteneminen. Lopuksi esitetään keskeisimmät soveltamiskokemukset vaatimusmäärittelyn osalta. 2.. Mitä vaatimusmäärittely on? Rossin ja Schomanin (977) mukaan vaatimusmäärittely nähdään huolellisena arviointina niistä tarpeista, joita tietojärjestelmän tulee täyttää (van Lamsweerde 2000, 5). Tarpeet voivat olla nykyhetken tai tulevaisuuden tilanteita organisaation sisäisessä tai ulkoisessa toiminnassa. Vaatimusmäärittely kertoo myös, miten järjestelmä rakennetaan. Pohjonen (2002, 28) sen sijaan näkee vaatimusmäärittelyvaiheen tuotoksen dokumenttina, jossa esitetyt vaatimukset määrittelevät eri sidosryhmien tarpeet järjestelmän suhteen, mutta eivät ota kantaa siihen, minkälainen tekninen toteutus nämä tarpeet käytännössä täyttää. Vaatimusmäärittely ei ole vain yksi vaihe ohjelmistotuotantoprosessissa, vaan se jatkuu koko ohjelmiston elinkaaren ajan esimerkiksi päivitysten yhteydessä Vaatimusmäärittelystä yleensä Ohjelmistokehityksessä vaatimusmäärittelyn tehtävä on taata, että tuotettava ohjelmisto toteuttaa oikeat toiminnot ja sisältää oikeat tiedot. Toimintoihin ja tietosisältöön kohdistuvien vaatimusten lisäksi ohjelmistolle asetetaan tavallisesti muitakin vaatimuksia, kuten tehokkuuteen, luotettavuuteen, siirrettävyyteen, yhteistoiminnallisuuteen, turvallisuuteen ja käytettävyyteen liittyviä ominaisuuksia, joiden toteutettavuus sekä keskinäiset riippuvuudet täytyy osata ottaa huomioon vaatimusmäärittelyssä. Ohjelmistotuotteen kehittämisessä tärkeä on ymmärtää se, että tuotettava ohjelmisto on osa kohdealueen toimintaa tavallisesti väline toiminnan suunnittelussa ja valvonnassa, yhteistoiminnan koordinoinnissa ja yksittäisten työtehtävien suorittamisessa. Jotta sovelluksesta olisi todella hyötyä, sen tulee mukautua luontevasti toimintakokonaisuuteen, johon se on tarkoitettu. Myös sovelluksen käytön tulee olla mahdollisimman vaivatonta, jotta siitä olisi käyttäjälle hyötyä työtehtävien suorittamisessa. Usein vaatimusmäärittelyssä ongelmana on oikeiden vaatimusten löytäminen ja vaatimusten muuttuminen samankin tuotekehitysprojektin aikana. PlugIT-hankkeessa toteutetun ohjelmistotuotannon nykytila- ja tarvekartoitusselvityksen mukaan sovellusten käyttäjät osallistuvat jonkin verran vaatimusmäärittelyyn, mutta siitä huolimatta vaatimusmäärittelyn ongelmana pidetään sitä, että asiakas ei ymmärrä vaatimusmäärittelyn tarpeellisuutta. Tämän lisäksi suurimpia ongelmia ovat vaikeus löytää yhteinen kieli asiakkaan ja tuotteen toimittajan välillä sekä se, että eri asiakkailla on erilaiset toimintatavat. (Porali ym. 2004) Edellä esitetyt ongelmat viittaavat siihen, että toimittajan on vaikea ymmärtää asiakkaan toimialaa ja päinvastoin. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 3

14 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN 2.2 Pakkasen vaatimusmäärittelyn lähtökohdat Lähtökohtana Pakkasen vaatimusmäärittelyssä oli komponenttipohjaisen ohjelmistotuotannon näkemys siitä, että kohdealueen toimintaprosesseista tunnistetaan uudelleenkäytettävät ohjelmistokomponentit (Cheesman ja Daniels 200; Mykkänen 2000; Kähkipuro 2000). Toinen lähtökohta oli se, että toimintalähtöisen vaatimusmäärittelyn kehittämistä oli tehty PlugIT-hankkeessa (esimerkiksi Toivanen ym. 2003; Laitinen ym. 2003; Häkkinen 2003), joten vaatimusmäärittelijöiden käytössä oli asiantuntemuksen lisäksi välineet toiminnan kartoittamiseen, analysointiin ja kuvaamiseen. Kolmas merkittävä lähtökohta oli se, että komponentti- ja arkkitehtuurisuunnitteluun oli valittu sovellettavaksi menetelmä (Cheesman ja Daniels 200), jota varten ohjelmiston vaatimukset keskeiset käsitteet sisältävä käsitemalli sekä toiminnallisuuden kuvaavat käyttötapauskuvaukset tuli kuvata tietyllä notaatiolla (ks. luku 2.2.2). Menetelmänäkökulmasta vaatimusmäärittelyn tehtävänä oli selvittää se, miten arkkitehtuurija komponenttisuunnittelua varten tarvittavat vaatimusmäärittelyn tuotokset käsitemalli ja käyttötapauskuvaukset saadaan aikaan toimintalähtöisesti. Vaatimusmäärittelyssä sovelletut menetelmät on kuvattu lyhyesti seuraavissa luvuissa 2.2. ja Pakkasen toisen vaiheen aikana käyttöliittymäsuunnittelun rooli vaatimusmäärittelyssä kasvoi merkittävästi, joten käyttöliittymäsuunnittelu on esitelty kokonaan omassa luvussa Toimintalähtöinen vaatimusmäärittely Toimintalähtöisessä vaatimusmäärittelyssä pyritään työtoiminnan ja tietojärjestelmien rinnakkaiseen kehittämiseen. Menetelmän lähtökohtana on se, että toimintakokonaisuus kuvataan ja jäsennetään toiminnan teoriaan perustuvan työtoiminnan mallin avulla (Toivanen ym. 2004). Toiminnan teoriaan perustuva malli työtoiminnasta tarkoittaa kokonaisuutta, jossa joukko ihmisiä työskentelee järjestäytyneellä tavalla jonkin yhteisen kohteen parissa tuottaakseen jonkin yhteisen lopputuloksen (Korpela 999). Toiminnan teoria mahdollistaa erilaisten toimintaketjujen, toimintojen organisaatioon sijoittumisen sekä yhden toimintakokonaisuuden yksityiskohtaisen tarkastelun. Sen avulla voidaan muodostaa kokonaiskuva kohdealueesta ja toisaalta eri osa-alueita voidaan tarkastella yksityiskohtaisemmin useasta näkökulmasta. Toiminnan teoriaan perustuva malli työtoiminnasta ja palveluista kuvaa myös tietotekniikan roolin toiminnassa. Lisäksi malli tarjoaa muistilistan asioista, joita on tarpeen selvittää. (Toivanen ym. 2003) Vaatimusmäärittelyssä ensimmäinen tehtävä on muodostaa kokonaiskuva tarkasteltavana olevan toiminnan nykytilanteesta. Tämä tehdään kuvaamalla ja jäsentämällä toimintakokonaisuus työtoiminnan mallin mukaisiin elementteihin. Tämän jälkeen nykytilan selvityksessä voidaan syventyä haluttuun kohteeseen esimerkiksi haastattelemalla kohdealueen asiantuntijoita ja muita toimijoita. Haastatteluteemojen suunnittelussa hyödynnetään työtoiminnan mallin rakennetta, jolloin tulokset on helpompi yhdistää malliin. Haastattelujen pohjalta muodostetaan nykytilan kokonaiskuvaus, jota voidaan tarkentaa ja täsmentää erilaisten kenttätutkimuksen ja tiedonhankinnan menetelmien avulla, esimerkiksi ryhmähaastatteluissa, havainnoimalla, kyselyillä jne. Kohdealueen analysoimisessa kuvaus toimii kohdealueen asiantuntijoiden ja määrittelijöiden yhteisenä kielenä ja keskustelun herättäjänä. Nykytilaa analysoimalla tunnistetaan kehittämistarpeet, joiden perusteella luodaan kuvaus tavoitetilasta. Tavoitetilan perusteella päätetään, tarvitaanko muutoksia toimintaan vai tietojärjestelmiin vai molempiin. Kehittämistyötä jatketaan tilanteen mukaan toiminnan ja/tai tietojärjestelmän kehittämisen näkökulmasta. (Laitinen ym. 2003, 36; Toivanen ym. 2003; Häkkinen 2003.) 4 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

15 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Toimintalähtöistä vaatimusmäärittelyä esitellään kattavasti PlugIT-hankkeen selvityksessä nro : Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä (Toivanen ym. 2004) Cheesman & Danielsin vaatimusmäärittelymenetelmä Menetelmän lähtökohtana on kohdealueen toiminnan ymmärtäminen toimintaprosessien mallintamisen avulla. Menetelmäkuvauksessa keskitytään pääsiassa siihen, miten toimintaprosessikuvauksista saadaan aikaan komponenttien ja komponenttiarkkitehtuurin määrittelyä varten tarvittavat syötteet. Komponenttisuunnittelun näkökulmasta kohdealueen tiedot kuvataan käsitemallissa ja sovelluksen toiminnallisuus käyttötapauskuvauksina. Käyttötapauksia voidaan täydentää tietoihin ja erilaisiin sovelluksen ominaisuuksiin liittyvillä vaatimuksilla, kuten suoritusaika tai turvallisuus. Molemmat tuotokset kuvataan soveltamalla Unified Modeling Language (UML)-notaatiota (Fowler 999). Käsitemallin kuvaamisessa sovelletun luokkakaavionotaation osalta tulee kuitenkin huomioida se, että käsitemalli on ohjelmistosta riippumaton malli (Cheesman ja Daniels 200). Menetelmän kehittäjät korostavat sitä, että pitkän ja kaiken kattavan vaatimusten määrittelyn asemesta käyttötapauksia pitäisi pystyä tuottamaan nopeasti komponenttisuunnittelua varten. Kuitenkin he muistuttavat, että ennen kuin sovellusta voidaan ryhtyä suunnittelemaan ja komponentteja määrittelemään, sovelluksen tarkoitus ja tehtävät on oltava selvillä. Käsitemallin ja käyttötapausten johtamista prosessikuvauksista käsitellään perusteellisemmin lähdeteoksessa (Cheesman ja Daniels 200). Menetelmässä ei kuitenkaan kuvata sitä, miten toimintaprosesseja selvitetään tai kuinka vaikutukset toimintatapoihin otetaan huomioon sovelluskehityksessä. Siksi sovelluksen vaatimusmäärittelyn kannalta toimintalähtöinen vaatimusmäärittely täydentää Cheesmanin ja Danielsin menetelmää. 2.3 Pakkasen vaatimusmäärittelyn eteneminen Tässä luvussa kuvataan lyhyesti vaatimusmäärittelyn eteneminen Pakkasessa. Vaatimusmäärittely toteutettiin kahdessa vaiheessa samoin kuin koko menetelmäkokeilukin (ks. luku.2). Ensimmäisessä vaiheessa tavoitteena oli päästä nopeasti toteutuskokeiluihin yhden käyttötapauksen osalta (käyttäjätunnuksen luonti). Siksi vaatimusmäärittelyssä käyttötapaus määriteltiin käymällä läpi tehtävässä tarvittavat toiminnot nykyisen ohjelmiston pääkäyttäjän kanssa. Toimintaan liittyvät käsitteet löydettiin pääasiassa tutkimalla nykyisen ohjelmiston tietokantakuvausta. Käyttötapauksessa tarvittavat konkreettiset tiedot selvitettiin käyttäjätunnuksen hakemisessa käytettävästä lomakkeesta sekä tutkimalla nykyistä Pakka-ohjelmistoa. Ensimmäisen vaiheen aikana toimintakokonaisuus kartoitettiin alkutietojen ja teemahaastatteluiden avulla toimintalähtöisen lähestymistavan mukaisesti. Haastatteluissa käytettiin haastattelulomaketta, jossa haastatteluteemat noudattavat työtoiminnan mallin rakennetta (Toivanen ym. 2004, 8). Näin haastatteluiden tulokset saatiin purettua suoraan työtoiminnan mallin mukaisiin elementteihin (esimerkki liitteessä 2). Toisessa vaiheessa toiminnan tarkastelua syvennettiin perehtymällä tarkemmin muutamaan keskeiseen monen toimijan toimintaprosessiin. Yhdestä prosessista saatiin käyttöön asiakasorganisaatiossa laadittu prosessikaavio, mutta muuten toimintaprosessit selvitettiin haastattelemalla toimintaprosessien eri toimijoita (yhteensä 4 kpl). Selvitettävien monitoimijaisten toimintaprosessien valintaperusteena oli tarve saada selville syyt tiedonkulun ongelmiin, joiden seurauksena nykyisen ohjelmiston kaikki tiedot eivät olleet ajan tasalla. Lisäksi nykyisen ohjelmiston käyttöönoton jälkeen toiminnassa oli otettu käyttöön myös kokonaan uusi toimintatapa, jonka todelliset vaikutukset ohjelmistoon haluttiin selvittää. Haastattelukysymysten laadinnassa hyödynnettiin samoja työtoiminnan malliin perustuvia haastatteluteemoja kuin toimintakokonaisuuden selvittämisessäkin. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 5

16 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Haastatteluiden tulokset mallinnettiin prosessikaavioina: aluksi toimintaprosessinäkökulmasta, mutta mallinnuksessa otettiin huomioon myös työprosessinäkökulma, koska haastattelut tukivat työprosessinäkökulmaa (esimerkki liitteessä 3). Toisessa vaiheessa käytettävyysnäkökulma tuli vahvemmin mukaan vaatimusmäärittelyyn. Tämän seurauksena käyttäjän ja ohjelmiston välisen vuorovaikutuksen sijaan työtehtäviä tarkasteltiin kokonaisvaltaisemmin tavoitteellisina tehtävinä. Selvitettäväksi valittiin kaksi työtehtävää sillä perusteella, että toinen edusti usein toistuvaa tehtävää ja toinen sisälsi kattavasti nykyisen ohjelmiston toimintoja. Työtehtävien selvittäminen toteutettiin havainnoimalla pääkäyttäjän työtä tämän oikeassa työympäristössä. Havainnoinnissa käytettiin mestari-oppipoika -menettelyä (esimerkiksi Kuutti 2003). Havainnointitilaisuuden jälkeen määrittelyryhmä analysoi tuloksia alustavasti, minkä jälkeen tehtävät mallinnettiin prosessikaavioina ja sanallisina kuvauksina (esimerkki liitteessä 4). Työprosessien ja -tehtävien analysoinnissa keskeinen tarkastelutapa oli toimintojen suoraviivaistaminen tuotettavan ohjelmiston avulla. Analysoinnin pohjalta määritettiin uudessa ohjelmistossa toteuttavat toiminnot. Toiminnot määritettiin nimeämällä ne käyttötapauksina. Ohjelmistossa ylläpidettävät käsitteet (käyttäjätunnus, käyttäjäryhmä ja palvelinkone) oli sovittu asiakkaan kanssa jo ensimmäisen vaatimusmäärittelyvaiheen aikana, mutta näihin käsitteisiin liittyviä tietoja oli tarpeen määrittää täsmällisemmin. Ohjelmiston todellinen tietosisältö tarkentui kuitenkin varsinaisesti vasta käyttöliittymäsuunnittelun yhteydessä, jossa toiminnan analysoinnin tuloksena syntyneet kehittämisideat konkretisoitiin asiakkaalle käyttöliittymäsuunnitelman avulla. Käyttöliittymäsuunnitelma toimi myös yhtenä ohjelmiston vaatimusmäärittelydokumenttina ohjelmistokehitysprojektin seuraavissa tehtävissä: arkkitehtuuri- ja komponenttisuunnittelussa sekä ohjelmiston testauksen suunnittelussa. 2.4 Kokemuksia vaatimusmäärittelyssä käytetyistä menetelmistä ja tekniikoista Kokemuksia on dokumentoitu kolmesta näkökulmasta: ) Miten toimintalähtöisyyttä tukevat menetelmät soveltuivat ohjelmistovaatimusten selvittämiseen? 2) Miten onnistuttiin toiminnan analysoinnin pohjalta kuvaamaan ohjelmistovaatimuksia? 3) Mikä on olemassa olevan ohjelmiston rooli uudistettavan järjestelmän määrittelyssä? 2.4. Toimintalähtöisyys Kokonaiskuvan muodostaminen Pakkasessa toimintakokonaisuuden (käyttäjätunnusten hallinta) selvittämisessä käytettyjen teemahaastatteluiden avulla toiminta osatekijöineen saatiin jäsennettyä ja kuvattua työtoiminnan malliin. Vaatimusmäärittelijöiden mielestä teemahaastattelulomake toimi hyvin käyttäjätunnusten hallinnan kokonaisuuden hahmottamisessa eli siinä, millaisessa toiminnassa ohjelmistoa nykyään käytetään. Vaikka alkuperäinen teemahaastattelulomake on suunniteltu koko toiminnan toimintalähtöistä kartoitusta varten, se soveltuu hyvin myös toiminnan kartoittamiseen ohjelmiston vaatimusmäärittelyn näkökulmasta. Ohjelmiston vaatimusmäärittelyn näkökulma tarkoittaa tässä sitä, että haastattelukysymyksiä mietittiin myös nykyisen ohjelmiston tehtävien kannalta. Lisäksi haastatteluissa selvitettiin varsinaisen järjestelmän toimintaa ja sen kehittämistarpeita. Ensimmäisenä ei kuitenkaan kannata ryhtyä selvittämään nykyisen ohjelmiston kehittämistarpeita, jos vaatimusmäärittelijät eivät ennestään tunne hyvin kohdealueen toimintaa. Määrittelijöiden pitäisi ensin saada itse muodostaa käsitys ja ymmärrys nykyisestä toiminnasta ja siihen liittyvistä ongelmista. Tästä on se hyöty, että ongelmien ratkaisukeinoja on helpompi ryhtyä selvittämään tarkoituksenmukaisilla keinoilla. Jos ohjelmiston määrittelijöille esitetään varhaisessa vaiheessa 6 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

17 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN runsaasti erilaisia kehittämisideoita, he tarvitsevat enemmän aikaa kokonaisuuden ymmärtämiseen. Sen lisäksi, että heidän on ymmärrettävä nykyinen tilanne ongelmineen, heidän on mietittävä kaikkien annettujen kehittämisideoiden vaikutukset tulevaan toimintaan ja päätettävä vasta tämän jälkeen, minkä tyyppisiä kehittämistarpeita todella tarvitaan. Toisaalta määrittelijät voivat kirjata nykyisen ohjelmiston kehittämisideat suoraan vaatimuksiksi tuotettavalle sovellukselle, mutta tästä voi seurata se, että valmis ohjelmisto ei olekaan asiakkaan toiveiden mukainen. Eli jos todellisia toiminnan asettamia vaatimuksia ei ymmärretä, niitä on vaikea ottaa huomioon sovelluksessa. Toinen tärkeä hyöty ohjelmistokehityksen näkökulmasta on se, että tavoitetilan kuvaus ei tulisi annettuna, vaan että nykyiseen toimintaan liittyvien ongelmien ratkaisukeinoja voisivat pohtia eri asiantuntijat omista näkökulmistaan. Esimerkiksi kohdealueen asiantuntijat ovat asiantuntijoita sovellukseen vaikuttavien, mutta toimintaan ja toimintatapoihin liittyvien kehittämisideoiden pohdinnassa. Sen sijaan ohjelmiston käyttöliittymän kehittämiseen tai teknisiin ratkaisuihin liittyvissä tilanteissa tarvitaan erilaista osaamista Tarkastelun syventäminen Pakkasessa eri toimijoiden haastattelut osoittautuivat toimivaksi tiedonhankinnan välineeksi myös keskeisimpien monitoimijaisten toimintaprosessien määrittelyssä. Toisaalta, jos asiakasorganisaatiosta on saatavana laatukäsikirja tai muuta tarkoitusta varten dokumentoituja prosessikuvauksia, niitä kannattaa hyödyntää ensisijaisesti. Prosessien mallinnuksessa ja analysoinnissa prosessikaaviot auttavat kokonaiskuvan ymmärtämisessä, kehittämiskohteiden havaitsemisessa ja ratkaisuvaihtoehtojen hahmottamisessa. Prosessikaavioita käytettiin myös mallinnettaessa käyttäjän keskeiset työtehtävät, joihin perehdyttiin havainnoimalla käyttäjän työtä hänen aidossa työympäristössään oikeiden työtehtävien avulla. Havainnoinnin avulla toiminnasta syntyi paljon syvällisempi ymmärrys kuin mihin haastatteluiden tai tehtävien läpikäyntien avulla oli päästy. Tehtävien läpikäynti tarkoittaa tässä sitä, että työtehtäviä selvitetään käyttäjän kanssa käymällä läpi tehtävään kuuluvia yksittäisiä toimintoja nykyisen ohjelmiston avulla. Läpikäynneistä puuttuu aitoon työtilanteeseen liittyviä tekijöitä, kuten keskeytykset, kommunikointitavat ja välineiden todellinen käyttö. Harvoin tällaisia asioita osataan ottaa huomioon muuten kuin tekemällä työtä oikeasti. Vaatimusmäärittelijät havaitsivat, että käyttäjän työtä havainnoimalla, kuvaamalla ja analysoimalla yksittäisiä työtehtäviäkin on mahdollista suoraviivaistaa huomattavasti. Esimerkkinä tehtäväkokoisuus, jossa asiakkaan nimen muutoksen yhteydessä muutettiin myös käyttäjätunnus. Kaiken kaikkiaan ilman keskeytyksiä tehtävän suorittaminen nykytilanteessa kesti noin 20 minuuttia. Uudessa sovelluksessa suoraviivaistamisen ja käyttöliittymäsuunnittelun ansiosta sama tehtävä olisi mahdollista suorittaa muutamassa minuutissa. Työprosessien määrittely, mallintaminen ja tarkastaminen voi olla varsinkin ensimmäisellä kerralla melko työläs työvaihe, johon kannattaa varata aikaa. Kokemuksen myötä ne kuitenkin syntyvät helpommin. Prosessikuvauksia ei myöskään tarvitse tehdä aina uudestaan, vaan kerran luotuja kuvauksia voidaan käyttää uudestaan usealla eri tavalla. Nykyään ohjelmiston vaatimusmäärittely on toistuva prosessi, jossa ohjelmiston elinkaaren aikana vaatimuksia määritellään aina, kun aletaan kehittää uutta ohjelmistoversiota. Siksi prosessikuvauksille on käyttöä tulevissakin määrittelytehtävissä. Lisäksi prosessikuvaukset ovat hyödyllisiä ohjelmiston ylläpidon kannalta, koska niiden avulla voidaan muun muassa arvioida erilaisen muutosten vaikutuksia toimintaan ja päinvastoin. Kolmanneksi, prosessikuvauksia voidaan käyttää apuna perehdytettäessä uusia työntekijöitä kohdealueen toimintaan. Neljäs hyötynäkökulma on se, että ne toimivat tietolähteinä ja tarkastuslistoina ohjelmistotuotannon eri työvaiheissa toimiville henkilöille. Prosessikaaviot ovat myös hyvä kommunikoinnin väline ohjelmistokehitysprojektin eri osapuolien välillä. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 7

18 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Vaatimusten dokumentoinnista Käyttötapausten tunnistaminen työprosesseja tutkimalla Työprosessien mallintamisessa käytetty UML-aktiviteettikaavioon (Cheesman ja Daniels 200) perustuva, mutta PlugIT-hankkeessa edelleen kehitetty prosessikaavionotaatio (Korpela ym. 2004) sopii hyvin prosessien kuvaamiseen. Notaation avulla toimintakuvaukset voidaan yhdistää toisiinsa (kuva 2.). Opiskelijarekisteri Käyttöoikeuksien hallinta Os.sihteeri Opinto hallinto hlökunta Toiminta: käyttäjätunnusten hallinta loma ke Pääkäyttäjä, asiakas Osastosihteeri posti Tallentaja loma ke Pakka palvelin Käyttäjätunnuksen luonti Henk.koht. kommunikointi Oikea tieto Monitoimijainen työprosessi: käyttäjätunnuksen luonti Asiakas Täytä rooli loma ke Opiskelijarekisteri Varmenna Osastosihteeri opiskelija Hyväksy Tallentaja Käyttäjätunnus ok ei kyllä prosessi jatkuu Yhden toimijan työtehtävä: luo käyttäjätunnus vastaanota Tarkasta, onko tunnusta ei rooli Tallentaja loma ke kyllä henkilökunta Pakka Varmenna prosessi jatkuu Opiskelijarekisteri Opiskelijakortti opiskelija Kuva 2.. Jäljitettävyys eri tasoisten toiminnan kuvausten välillä. Vasemmalla olevasta toimintakokonaisuuden kuvauksesta on tunnistettu toimintaprosessi käyttäjätunnusten luonti. Keskimmäisessä kaaviossa prosessi on kuvattu tarkemmin monen toimijan prosessina. Oikean puoleinen kaavio tarkentaa käyttäjätunnuksen luonnin tallentajan työprosessina. Pakkasessa prosessikaavioiden avulla havainnollistettiin tuotettavan ohjelmiston avulla tapahtuvia työtehtäviä. Tältä pohjalta pystyttiin nimeämään ja osittain myös kuvaamaan ohjelmiston tehtävät eritasoisina käyttötapauksina. Sen sijaan prosessien sanallisessa kuvaamisessa ongelma oli se, että kuvaamisessa mentiin hyvin tarkalle tasolle muun muassa sen osalta, kuinka käyttäjä käyttää/tulisi käyttämään tuotettavaa ohjelmistoa. Sen takia paitsi että sanallisten kuvausten tuottaminen oli työlästä, myös niiden lukeminen oli hankalaa. Toinen ongelma tavoitetilaa kuvaavissa sanallisissa kertomuksissa oli se, että ne perustuivat liikaa nykyisen sovelluksen toimintaan, joten ne eivät palvelleet uuden ohjelmiston suunnittelua tarkoituksenmukaisella tavalla. Ongelmien ratkaisemiseksi työryhmässä mietittiin, että nykyisen ja tulevan toiminnan kuvaamisessa prosessikaaviot lyhyine sanallisine selityksineen voisivat olla tarkoituksenmukaisempi mallinnuskeino. Toiseksi, tulevien tehtävien mallintamisessa varsinaista käyttäjän ja sovelluksen välistä vuorovaikutusta ei kuvattaisi ollenkaan, vaan se jäisi pääasiassa käyttöliittymäsuunnittelijan tehtäväksi. Toiminnan tarkastelussa riittäisi siis se, että tunnistetaan ohjelmiston avulla suoritettavat tehtävät, mutta käyttöliittymäsuunnittelun tehtävä olisi määrittää asiakkaan kanssa yhdessä se, kuinka tehtävät suoritetaan ohjelmiston avulla. Käyttöliittymäsuunnittelun tuloksena syntyvä käyttöliittymäsuunnitelma toimisi puolestaan syötteenä käyttötapausten kuvaamiseen UML-notaatiolla. 8 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

19 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Esimerkki: Käyttäjätunnuksen luonti UML-notaation mukaisena käyttötapauskuvauksena. Tietoihin ja sovelluksen ominaisuuksiin liittyviä vaatimuksia dokumentoitiin käyttötapauksittain. Toiminto: käyttäjätunnuksen perustaminen Toimija: järjestelmän pääkäyttäjä Edellytys: pääkäyttäjä on kirjautunut järjestelmään Tavoite: asiakkaan käyttäjätunnus ja siihen liittyvät tiedot on tallennettu järjestelmään Pääskenaario:. Valitse järjestelmästä asiakas, jolle käyttäjätunnus luodaan. Järjestelmä tunnistaa annetun hakukriteerin perusteella asiakkaan yksiselitteisesti tai tarjoaa löydetyistä vaihtoehdoista listan, josta käyttäjä valitsee oikean asiakkaan. 2. Varaa asiakkaalle käyttäjätunnus ja tallenna hyväksytty käyttäjätunnus. 3. Liitä käyttäjätunnus palvelinkoneeseen. 4. Lisää asiakkaalle palvelinkonekohtaiset käyttäjäryhmät ja tallenna tiedot. Poikkeustapaukset ja laajennokset:. Järjestelmä ei löydä asiakkaan henkilötietoja: Suorita käyttötapaus Asiakastietojen lisäys ja jatka kohdasta 2. Muutoin: virhe. 2. Asiakkaalla on jo olemassa oleva käyttäjätunnus: Käyttötapaus päättyy. 3. Järjestelmässä ei ole palvelinkoneen tietoja: Suorita käyttötapaus Palvelinkoneen tietojen lisäys ja jatka kohdasta Asiakkaan käyttäjätunnukseen liitetään samalla kertaa enemmän kuin yksi palvelinkone: Vaiheen 4 jälkeen palaa takaisin vaiheeseen Järjestelmässä ei ole sopivaa käyttäjäryhmää: Suorita käyttötapaus Käyttäjäryhmän lisäys ja jatka kohdasta 4. Tallennukseen liittyvät yhteiset poikkeukset: 5. Järjestelmään on jo tallennettu pääkäyttäjän syöttämät tiedot Virhe: duplikaattien tallennus on estettävä 5.2 Pääkäyttäjä on unohtanut syöttää jonkin pakollisen (tähdellä * merkityn) tiedon Virhe: pakolliset tiedot on syötettävä Toimintoon liittyvät vaatimukset (vaatimuspohja lähteestä Mykkänen ym. 2004a) : Tunniste Kuvaus Prioriteetti Riippuvuudet (liittymät muihin vaatimuksiin) kl (Käyttäjätunnuksen lisäys) Hakukriteerit asiakkaan valintaan henkilötiedostosta: pelkkä sukunimi tai sukunimi ja etunimi tai nimen osa Käyttäjätietojen hakukriteerit Tyyppi Olemassa oleva järjestelmä Historia Toteutus: versio, vaatimus kirjattu Alkuperäinen lähde Pakka-järjestelmä jne. Käyttötapaukseen liittyvät muut vaatimukset on kirjattu samaan tapaan. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 9

20 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Käsitteiden mallinnus Pakkasessa käsitemalli luotiin vaatimusmäärittelyn alkaessa nykyisen ohjelmiston tietokantakuvauksen pohjalta ja sitä täsmennettiin vähitellen toiminnan tarkastelun yhteydessä. Erityisesti käsitteiden määrittelyn kannalta tärkeää oli se, että määrittelijät pystyivät kommunikoimaan sovelluksen ylläpitäjän ja pääkäyttäjän kanssa aina tarvittaessa. Näin epäselvät käsitteet ja asiat saatiin selvitettyä mahdollisimman nopeasti ja samalla niiden oikeellisuus tuli tarkastettua. Käsitemalli kasvaa helposti ja sisältää paljon informaatiota, joten iteratiivisen lähestymistavan avulla virheet on helpompi havaita ajoissa. Työryhmän mielestä UML-luokkakaavio sopii käsitemallinnukseen, vaikka UML-notaatiota pidetään enemmän sovelluksen teknisen suunnittelun välineenä. Kaaviossa käsitteet esitetään luokkina ja käsitteiden väliset suhteet assosiaatioina ja koosteina. Käsitteiden välisiin suhteisiin voidaan liittää myös lukumääräsuhde (kardinaalisuus), joka ilmaisee suhteeseen osallistuvien käsitteiden lukumäärän. Käsitteisiin liittyvä tieto kuvataan luokkien attribuutteina, joihin voidaan myös lisätä erikseen lukumäärätietoa. Lisäksi erilaisia käsitteisiin ja tietoihin liittyviä rajoituksia ja sääntöjä voidaan kuvata rajoite-symbolin avulla. Esimerkki: Käsitemallinnus UML-luokkakaaviona. Käsitemalli: käyttäjätunnusten hallintaan liittyviä käsitteitä ja niiden välisiä suhteita Käsitemalli Atk-keskus Käyttöoikeuksien myöntäjä Yliopisto..n n * Organisaatio -tiedekunta..* * Käyttöoikeusperuste -opiskelija -palvelusuhde 0.. -name Person 0.. Laitos Henkilö -tunnus Staff -department Student -right_to_ study -training_program Staff (ext.) -department 0.. Henkilökunta Opiskelija -opinto-oikeus Muu henkilöstö Client * Pakka-järjestelmän käyttäjä n 0.. Käyttäjätunnus n 0..(n)..* Sähköpostialias 0..(n) Sähköposti 0....n Asiakas n Hyväksytty käyttölupahakemus n..n Palvelinkone 0....n n..n..n..n Käyttäjäryhmä..n Käyttöoikeus Tietojärjestelmä..n..n..n In the present system there is a function for generating a username Username -username : String {String: 6-8 bytes }..* Account application form Server..* *..* -name : Integer -type (unix, other) -mailserver : Boolean * Server username -username : Integer..* *..*..*..* Usergroup -name : String..* Pakka-tietojärjestelmä n..n Tietojärjestelmän käyttäjätunnus 0..n Käytöstä poistettu sähköpostialias 0..n Käytöstä poistettu palvelinkoneen käyttäjätunnus Palvelinkoneen käyttäjätunnus 0....n Salasana..n Salasana Kuva 2.2. Vasemman puoleinen käsitemalli sisältää kaikki käyttäjätunnusten hallinnasta tunnistetut käsitteet. Oikeanpuoleisessa käsitemallissa kuvataan ainoastaan tuotettavan ohjelmiston kannalta keskeiset käsitteet. 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

21 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Kun notaatio on rajoitettu muutamiin keskeisiin symboleihin, niiden merkitys on helppo selittää myös kohdealueen asiantuntijoille. On kuitenkin syytä korostaa, että sovelluksen tietosisältömäärittelynä käsitemalli ei yksin riitä, vaan tarkempi tietosisältömäärittely syntyy esimerkiksi käyttöliittymäsuunnittelun aikana. Cheesmanin ja Danielsin menetelmässä tietosisältö määritellään vasta komponenttisuunnittelun yhteydessä määriteltäessä komponenttien välistä vuorovaikutusta, mutta komponenttisuunnittelussa saatujen kokemusten pohjalta tämä lähestymistapa osoittautui ongelmalliseksi (ks. esimerkiksi luku Komponenttien vuorovaikutuksen määrittely). Vaikka käsitemallinnus liittyy tiedon analysointiin, sitä ei voi erottaa toiminnan analysoinnista. Toiminnan ymmärtäminen perustuu juuri käsitteiden merkityksen ja käsitteiden välisten suhteiden ymmärtämiseen. Pakkasessakin havaittiin yhteys toimintakokonaisuuden kuvaavan työtoiminnan mallin ja käsitemallinnuksen välillä. Työtoiminnan mallissa kohdealueen käsitteet ryhmitellään merkityksen mukaan elementteihin. Käsitemallin avulla havainnollistetaan miten työtoiminnan malliin ryhmitellyt käsitteet liittyvät toisiinsa (kuva 2.3). -name - Person Rules, instructions, checklists Client: - student - staff - external staff 0.. Staff -department Student -right_to_ study -training_program 0.. Client Staff (ext.) -department 0.. Information related to a client s username Account application form..*..*..*..* Username -username : String Account application form *..* Usergroup -name : String Servers In the present system there is a function for generating a username {String: 6-8 bytes } Server *..* -name : Integer -type (unix, other) -mailserver : Boolean..*..* * Server username -username : Integer Kuva 2.3. Työtoiminnan mallin käsitteet (vasemman puoleiset symbolit) kuvattuna käsitemallissa (oikean puoleinen kaavio). SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 2

22 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Nykyisen ohjelmiston rooli Pakkasessa teemahaastattelujen ja käyttäjän työn havainnoinnin lisäksi keskeinen keino tiedonhankinnassa ja toiminnan ymmärtämisessä oli nykyisen ohjelmiston ja erilaisten dokumenttien, kuten käyttölupahakemuksen, ohjeiden ja sovelluksen teknisen dokumentin, tutkiminen. Sovelluksen ja dokumentaation tutkimisen tarkoitus oli käsityksen muodostaminen nykyisen järjestelmän tehtävistä, ympäristöstä, toiminnoista ja tiedoista. Projektin alkuvaiheessa määrittelyryhmä keskittyi sovelluksen ja sen teknisen dokumentaation läpikäyntiin, joiden avulla selvitettiin sovelluksen sisältämiä toimintoja ja tietoja: mitä sovelluksella tehdään ja miten. Myös liittymät toisiin sovelluksiin ja ympäristöön saatiin hyvin selville. Lisäksi tarkastelun avulla löydettiin erilaisia suunnitteluratkaisuja, joita voitaisiin mahdollisesti hyödyntää uutta sovellusta määriteltäessä. Alkuvaiheessa sovelluksen tutkimisesta oli hyötyä myös erilaisten selvitettävien ja tarkennettavien asioiden huomaamisessa. Erityisesti sovelluksen tarkastelu auttoi siinä, että toimintaan liittyviä käsitteitä ja käsitteiden välisiä yhteyksiä saatiin määriteltyä kattavasti ja melko nopeasti jo määrittelyn varhaisessa vaiheessa. Vaikka sovelluksen ja dokumentaation tutkiminen auttoi ymmärtämään nykyisen järjestelmän käyttöä toimintojen ja tietosisällön osalta, käyttäjän varsinaisista työtehtävistä ei niiden pohjalta saanut riittävää käsitystä. Siksi käyttötapaustenkin määrittelyssä kommunikointi kohdetoiminnan asiantuntijoiden kanssa, josta erityisesti käyttäjän todellisten työtehtävien havainnointi, koettiin tiedonhankinnassa ja tiedon oikeellisuuden varmistamisessa tärkeimpänä keinona. Sen sijaan toiminnan ymmärryksen syventämisessä nykyisen sovelluksen tarkastelulla oli keskeinen rooli. Sen avulla toimintoja pääsi kokeilemaan ja havainnollistamaan. Koska sovellus oli koko projektin ajan työryhmän käytettävissä, sen ääreen oli helppo palata. Nykyisen ohjelmiston tarkastelussa on kuitenkin omat ongelmansa. Esimerkkinä käyttötapausten määrittäminen Pakkasen ensimmäisessä ja toisessa vaiheessa: Keskeisin ero määrittelyjen toteutuksessa oli siinä, että ensimmäisessä vaiheessa selvitettiin ja kuvattiin vain se, kuinka käyttäjä käyttää nykyistä sovellusta käyttäjätunnuksen luonnissa. Käyttäjän tavoitteellisena työtehtävänä tunnuksen luontia tarkasteltiin vasta toisessa vaiheessa. Ensimmäisen vaiheen toteutuksen etuna voidaan pitää sitä, että näin nykyisen sovelluksen toiminnallisuus saadaan siirrettyä nopeasti uuteen sovellukseen ja lisäksi hyvät suunnitteluratkaisut saadaan käytettyä uudelleen vähällä vaivalla. Ensimmäisessä vaiheessa käytetty toimintatapa ei kuitenkaan ole toimintalähtöinen lähestymistapa, koska siinä ei välttämättä huomata toimintatapoihin ja ohjelmistoon liittyviä kehittämiskohteita riittävän laajasti. Pahimmassa tapauksessa nykyisen sovelluksen käytettävyyteen liittyvät ongelmat ja sovelluslogiikan epäjohdonmukaisuudet siirtyvät myös uudistettavaan ohjelmistoon. 2.5 Johtopäätökset ja pohdinta Komponenttipohjaisen sovelluskehityksen lähtökohdasta sekä arkkitehtuurisuunnittelun näkökulmasta Pakkasessa tehtyyn vaatimusmäärittelyyn valittiin alun perin sovellettavaksi kaksi toisiaan täydentävää menetelmää: PlugIT-projektissa kehitetty toimintalähtöisen vaatimusmäärittelyn menetelmä sekä Cheesmanin ja Danielsin esittelemä ohjelmistokomponenttien määrittelyä tukeva menetelmä. Valitut menetelmät täydensivät toisiaan siten, että toimintalähtöinen lähestymistapa tarjosi menetelmiä ja välineitä kohdetoiminnan tietojen keräämistä, jäsentämistä ja kuvaamista varten. Cheesmanin ja Danielsin menetelmä tarjosi mallin siitä, miten toimintaprosesseja tarkastelemalla johdetaan ja dokumentoidaan sovellusvaatimukset arkkitehtuuri- ja komponenttisuunnittelun näkökulmasta. 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

23 ANNAMARI RIEKKINEN, KIRSI REPONEN JA PERTTI LAITINEN Toimintalähtöisen vaatimusmäärittelyn lähtökohta on toiminnan ja tietojärjestelmien rinnakkainen kehittäminen. Parhaiten tämä onnistuu käyttämällä toimintalähtöisen vaatimusmäärittelyn menetelmiä ja tekniikoita, joita ovat muun muassa toiminnan jäsentämiseen ja kuvaamiseen tarkoitettu työtoiminnan malli, kenttätutkimusmenetelmät (esimerkiksi teemahaastattelut, havainnointi), työprosessien analysointi ja käyttötapauskuvaukset. Vaatimusmäärittelijöiden kohdealueen asiantuntemuksesta, alkutietojen kattavuudesta ja ohjelmistokehitysprojektin tavoitteista riippuu se, kuinka syvälle toiminnan tarkastelussa on tarpeen mennä. Työryhmän mielestä ohjelmiston vaatimusmäärittelyn kannalta toimintaprosessien tarkastelu monitoimijaisesta näkökulmasta tai yksittäisen käyttäjän tehtäväkulkuina on tarpeen silloin, kun toiminta on vaatimusmäärittelijöille tuntematon tai kun voidaan olettaa, että nykyistä toimintaa tai toimintatapoja voidaan suoraviivaistaa automatisoimalla tehtäviä joko siirtämällä niitä tuotettavan ohjelmiston tehtäväksi tai parantamalla järjestelmien välistä yhteentoimivuutta. Lisäksi toimintatapoja voidaan kehittää niin, että muutetaan manuaalisia tehtäviä suoritettavaksi sovelluksen avulla ja/tai kehitetään tehtävien suorittamisessa tarvittavia kommunikointikeinoja tai välineitä (esimerkiksi lomakkeet ja ohjeet). Pakkasessa toimintalähtöisen ajattelutavan ansiosta sovelluksen vaatimusten määrittelyssä päästiin parempaan lopputulokseen todellisten vaatimusten ymmärtämisessä. Nykyisen sovelluksen tutkiminen sekä tiedonhankinnassa sovelletut menetelmät työtoiminnan mallin rakennetta noudattava teemahaastattelu ja käyttäjän työn havainnointi muodostivat toisiaan täydentävän kokonaisuuden tiedon keräämisessä ja toiminnan ymmärtämisessä. Tärkeää oli kuitenkin se, että määrittelijöillä oli mahdollisuus kommunikoida nykyisen sovelluksen ylläpitäjän ja pääkäyttäjän, eli kohdetoiminnan asiantuntijoiden kanssa avoimesti ja epävirallisesti aina tarvittaessa. Toinen keskeinen menestystekijä toiminnan ja sitä kautta vaatimusten ymmärtämiselle oli se, että sovellusprojektissa eri osa-alueiden asiantuntijat, kuten arkkitehtuurisuunnittelija, tekniset asiantuntijat ja testauksen suunnittelija, osallistuivat vaatimusmäärittelyyn alusta asti. Eri toimijoiden osallistumisen myötä yhteisymmärrys tuotettavasta sovelluksesta löytyy helpommin ja nopeammin. Vaikeinta toiminnan määrittelyssä ja kuvaamisessa oli tarkoituksenmukaisten tarkastelutasojen ja näkökulmien päättäminen. Varsinkin toimintalähtöisten menetelmien ja ajattelutavan käyttöönottovaiheessa on olemassa vaara, että toiminnan mallintaminen karkaa vähemmän tärkeille poluille. Tärkeintä ei ole se, että kaikki asiat pyritään ymmärtämään mahdollisimman yksityiskohtaisesti. Tärkeintä on se, että sovelluksen todelliset vaatimukset ymmärretään riittävän hyvin ymmärtämällä toimintaa, jonka osana sovellus tulee olemaan. Työryhmä kuitenkin uskoo, että kokemuksen myötä toimintalähtöisyys sovelluksen vaatimusmäärittelyssä maksaa itsensä takaisin ajanja rahansäästönä. Toimintalähtöisyys myös lisää asiakastyytyväisyyttä. Pakkasen vaatimusmäärittelyssä ja käyttöliittymäsuunnittelussa saatujen kokemusten perusteella on koottu menetelmäluonnos ohjelmiston toimintalähtöistä vaatimusmäärittelyä varten. Menetelmä tarjoaa yhden esimerkin siitä, kuinka toiminnan analysoinnin pohjalta määritellään ja kuvataan konkreettiset ohjelmistovaatimukset. Toisin sanoen menetelmässä edetään systemaattisesti toiminnan analysoinnista todellisten ohjelmistovaatimusten tunnistamiseen ja kuvaamiseen niin, että tulokset on hyödynnettävissä ohjelmiston suunnittelutehtävissä. Menetelmäluonnos on kuvattu tarkemmin lähteessä (Toivanen ym. 2004). SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 23

24 PAULIINA IKÄVALKO JA RITVA SILVENNOINEN 3 KÄYTTÖLIITTYMÄSUUNNITTELU 3. Suunnittelun lähtökohdat Monissa nykyisin käytössä olevissa ohjelmistotuotannon prosessimalleissa (esim. vesiputous- tai evoluutiomalli) käyttöliittymäkehitystä ei ole huomioitu. Siksi näiden mallien pohjalta suunnitelluissa järjestelmissä on paitsi tehottomia käyttöliittymäratkaisuja, myös puutteita sekä tietosisällössä että soveltumisessa tarkoitettuihin työtehtäviin. (Laakso 2003.) Perinteisesti käyttöliittymä on syntynyt toteutusvaiheessa jonkunlaisena koodauksen sivutuloksena. Valitettavan usein käyttöliittymäsuunnittelulle ei ole varattu riittävästi aikaa eikä henkilöresursseja ja käytettävyys- ja käyttöliittymäsuunnittelijat tulevat projektiin liian myöhään. Myöskään käyttöliittymäsuunnittelun menetelmiä ja työvaiheita ei ole useinkaan otettu projektisuunnitelmassa huomioon. Menetelmäkokeilu Pakkasessakaan käyttöliittymäsuunnittelun roolia ei oltu määritelty riittävällä tavalla. Pakkasessa lähtökohtana oli määritellä, suunnitella ja toteuttaa uusittava sovellus useassa iteraatiokierroksessa. Määrittely- ja suunnittelutyö aloitettiin yhdestä käyttötapauksesta ja tarkoituksena oli laajentaa sovellusta käyttötapaus kerrallaan. Pian kuitenkin huomattiin, että on hyvin vaikea määritellä vain yhtä käyttötapausta ja luonnostella käyttöliittymän prototyyppiä sitä varten. 3.. Ohjelmistotuotteen käyttöliittymä Tuotteen ominaisuudet on monesti mielekästä jakaa kahteen tasoon: toiminnallisuuteen ja käyttöliittymään. Erilaisten niin sanottujen älykkäiden tuotteiden (kaukosäädin, matkapuhelin, tietokone jne.) toiminnallisuuden ja käyttöliittymän erottaminen toisistaan on suhteellisen helppoa. Esimerkiksi matkapuhelimen toiminnallisia ominaisuuksia ovat puheluiden soittaminen ja niihin vastaaminen, tekstiviestien lähettäminen ja vastaanottaminen jne. Matkapuhelimen käyttöliittymä taas koostuu itse puhelinlaitteesta, sen muodosta, näytön ja painikkeiden sijoittelusta, koosta ja väristä ja puhelimen erilaisista käyttömahdollisuuksista. Sama toiminnallisuus voidaan toteuttaa monien erilaisten käyttöliittymien avulla. (Mäntylä 200, 30 3.) Toiminnallisuuden ja käyttöliittymän käsitteellisestä erottamisesta huolimatta niitä ei käytännössä voida suunnitella erillään toisistaan. Ei voida ajatella tuotetta tai järjestelmää, jossa olisi pelkkä toiminnallisuus ilman käyttöliittymää. Valmiissa tuotteessa on aina käyttöliittymä, on se sitten harkiten suunniteltu tai syntynyt koodauksen sivutuotteena ilman mitään varsinaista suunnittelemista. Tämän käyttöliittymän perusteella käyttäjä muodostaa käsityksensä tuotteen toiminnallisuudesta ja käyttöliittymän avulla hän tuotetta myös käyttää. Erilaisten hallinta- ja näyttölaitteiden lisäksi käyttöliittymään kuuluvat myös kaikki ne tavat, joilla tuote kertoo käyttötarkoituksestaan ja -mahdollisuuksistaan. Käyttöliittymä voidaan määritellä tuotteen viesteistä ja käytännöllisistä osatuotteista koostuvaksi kokonaisuudeksi. Siten esimerkiksi käyttöohjekirja ja tuotepakkaus ovat osa käyttöliittymää. (Vuori ym. 998, 5 9.) Liiketoiminnan näkökulmasta ajateltuna hyvä käyttöliittymä ja tuote on sellainen, jonka asiakkaat haluavat ja voivat ostaa ja joka tekee heidät tyytyväisiksi. Asiakaslähtöisessäkin tuotekehitystoiminnassa on ajateltava myös valmistajan näkökulmaa, ettei tuotteesta tule asiakkaalle liian kallis tai yritykselle liian tappiollinen. Vaikka käyttöliittymän tärkein hyödyntäjä onkin sen loppukäyttäjä, on suunnittelussa otettava huomioon myös kaikkien muiden sen kanssa tekemisiin joutuvi- 24 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

25 PAULIINA IKÄVALKO JA RITVA SILVENNOINEN en tarpeet. Erilaisia tuotteen käyttäjiä voivat olla valmistajan ja loppukäyttäjän lisäksi markkinointiyhtiö, maahantuoja, jälleenmyyjä, kouluttajat, huoltohenkilökunta, ostajat jne. Hyvä käyttöliittymä voi olla erilainen esimerkiksi ostopäällikön tai atk-tukihenkilön näkökulmasta tarkasteltuna. (Vuori ym. 998, 6 9.) 3..2 Käyttöliittymäsuunnittelun GUIDe-projektimalli Jos ohjelmistotuotteen halutaan todella soveltuvan tarkoitettujen työtehtävien tekemiseen, on käyttöliittymä suunniteltava niin varhaisessa vaiheessa ohjelmistotuotantoprosessia, että suunniteltuja ratkaisuja voidaan vielä helposti muuttaa. Tätä varten on kehitetty GUIDe-malli (Goals User Interface Design Implementation), jossa käyttöliittymä suunnitellaan osana vaatimusmäärittelyvaihetta. GUIDe-mallin käyttämisen edellytyksenä on, että ohjelmistotuotannossa on mukana tavoitepohjaisten käyttötapausten selvittämisen ja käyttöliittymäsuunnittelun osaamista. Tavoitepohjaiset käyttötapaukset laaditaan selvittämällä käyttäjien työnkulut kenttätutkimuksen menetelmin, joita ovat muun muassa haastattelut ja työn havainnointi. Seuraavaksi suunnitellaan käyttöliittymä ja laaditaan siitä käyttöliittymäkuvaus, jossa näytetään kuvasarjojen avulla vaihe vaiheelta, kuinka käyttäjä saa tehtävänsä tehdyksi. Suunniteltava käyttöliittymäkuvaus konkretisoi tulevan järjestelmän sekä asiakkaille että toteuttajille. Kuvauksen perusteella käyttöliittymä voidaan testata (mm. käyttäjätestillä) valmiin järjestelmän tapaan jo ennen sen toteuttamista. Muutosten tekeminen on helppoa ja nopeaa, kun korjaukset voidaan tehdä suunnitelmaan valmiin järjestelmän sijaan. Kun käyttöliittymäkuvaus on testattu ja hyväksytty, voidaan siirtyä toteutuksen suunnitteluun, jossa käyttöliittymäkuvausta käytetään yhtenä suunnittelun lähtökohtana. Jos käyttöliittymään joudutaan toteutuksen aikana tekemään muutoksia (esimerkiksi jokin ratkaisu on liian työläs toteuttaa valituilla välineillä), toteutuksen suunnittelija tai ohjelmoija kuvaa ongelman käyttöliittymäsuunnittelijalle, joka suunnittelee uuden ratkaisun. Tämä työnjako varmistaa, etteivät ohjelmoijat joudu oman työnsä ohella tekemään käyttöliittymäsuunnittelua, josta heillä ei välttämättä ole kokemusta. (Laakso 2003.) 3.2 Pakkasen vaatimusmäärittelyn ja käyttöliittymäsuunnittelun eteneminen 3.2. Vanhan järjestelmän läpikäynti ja havainnointi Vaatimusmäärittelyn aikana tutustuttiin uusittavaan Pakka-järjestelmään asiantuntijaläpikäynnin ja havainnoinnin avulla. Läpikäynnissä sovellettiin osia Mediastudion tutkimuksessa Web-palveluiden käytettävyys ja tuotanto esitellyistä menetelmistä; ominaisuuksien katsastus ja moniarvoinen läpikävely (Mielonen ja Hintikka 998). Muutama työryhmän jäsen tunsi järjestelmää ennestään ja he esittelivät sitä muille. Jokainen käyttöliittymän lomake analysoitiin yhdessä ja sen perusteella luonnosteltiin käytettävyysanalyysin ensimmäinen versio, jossa osoitettiin vanhan käyttöliittymän vahvuudet ja ongelmat. Havainnoinnissa sovellettiin mm. Kuutin esittelemää mestari-oppipoika -asetelmaa (Kuutti 2003); mestarina oli Pakka-järjestelmän pääkäyttäjä ja oppipoikana yksi suunnitteluryhmän jäsen. Läpikäyntiä ja havainnointia pidettiin hyödyllisinä ja niistä oli myöhemmin apua käyttöliittymän suunnittelussa. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 25

26 PAULIINA IKÄVALKO JA RITVA SILVENNOINEN Saatujen tulosten dokumentointi Dokumentoinnissa suunniteltiin sovellettavan mm. Käyttöliittymien kehittämisen työkalupakissa (Vuori ja Kivistö-Rahnasto 2000) esiteltyjä malleja, joita muokattiin paremmin omaan käyttöön sopiviksi. Dokumenttien kirjoittaminen jäi kuitenkin suurimmaksi osaksi kesken eikä tuloksia juurikaan analysoitu Käyttöliittymäprototyypin suunnittelu Käyttöliittymäsuunnittelija ei ollut mukana projektissa sen alusta saakka ja joutui siksi suunnittelemaan prototyypin muiden kirjoittamien dokumenttien perusteella, jolloin puutteet korostuivat. Monet käyttöliittymäsuunnittelun kannalta oleelliset tiedot (kuten valittavissa olevien mahdollisuuksien lukumäärä ja laatu) puuttuivat. Lisäksi dokumenteissa oli ristiriitaisuuksia ja jopa suoranaisia virheitä. Toisaalta, koska dokumentit perustuivat nykyisen järjestelmän toimintaan, ne antoivat varsin vahvan mallin uuden järjestelmän käyttöliittymästä. Tästä mallista irrottautuminen oli hankalaa. Tulimme siihen tulokseen, että käyttöliittymäsuunnittelua edeltävän selvitystyön pitäisi palvella nimenomaan käyttöliittymäsuunnittelua. Kun käyttöliittymäkuvaus on valmis ja testattu, voidaan teknisessä suunnittelussa ja toteutuksessa tarvittavat vaatimusmäärittelydokumentit kirjoittaa sen perusteella. Dokumentoinnin puutteita paikkasi se, että käyttötapauksia pohdittiin koko työryhmän kesken yhteispalavereissa. Käyttöliittymäsuunnittelu aloitettiin luonnostelemalla perusrakennetta kynällä ja paperilla. Paperin ja kynän avulla työskentely oli kuitenkin hidasta ja luonnostelu siirrettiin tietokoneella tehtäväksi. (Kuva 3..) Vasemmalla yksi ensimmäisistä käyttöliittymäluonnoksista, jossa esitetään jo käyttöliittymän perusvuorovaikutuksen elementtejä ja käyttöliittymän yleisnäkymä. Alhaalla muutama kuva tunnuksen vaihtamista koskevasta käyttöliittymäkuvauksesta. Kyseisessä tapauksessa käyttäjän sukunimi on muuttunut. Tunnus halutaan saada vastaamaan uutta sukunimeä. Vanha tunnus on iivirtan, koska käyttäjän aikaisempi sukunimi on ollut Virtanen. Alhaalla vasemmalla käyttäjä on jo avannut järjestelmän ja hakenut oikean henkilön. Hän painaa muokkaa -nappia. Keskellä alhaalla näkyy järjestelmän nimitietojen perusteella generoima uusi tunnus. Käyttäjä voisi joko muokata tunnusta tai hyväksyä järjestelmän ehdottaman tunnuksen. Käyttäjä hyväksyy järjestelmän generoiman tunnuksen painamalla varaa tunnus nappia. Oikealla alhaalla esitetään järjestelmän antama vahvistus onnistuneesta tunnuksen vaihtamisesta. Kuva 3.. Esimerkkejä käyttöliittymäprototyypin suunnittelusta. 26 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

27 PAULIINA IKÄVALKO JA RITVA SILVENNOINEN Prototyypin testaaminen Käyttöliittymän ensimmäistä prototyyppiä testattiin niin, että jokainen suunniteltu näyttökuva tulostettiin paperille ja käyttäjä käytti niitä ikään kuin todellista järjestelmää (Kuutti 2003, ). Käyttäjälle annettiin kaksi testitehtävää, jotka hän teki paperinäyttöjen avulla. Koska kysymyksessä oli ohjelma, jonka käyttäjät todellisuudessa koulutetaan tehtävään, järjestettiin vastaava koulutus myös testitilanteessa. Käyttäjää pyydettiin kirjoittamaan käsin näyttökuviin ne asiat, jotka hän kirjoittaisi todelliseen järjestelmään ja merkitsemään ne painikkeet, joita hän painaisi. Testitehtävään oli annettu kaikki tiedot, joita suunnittelijaryhmä oletti käyttäjän tarvitsevan (mm. kuvitteellisen asiakkaan täyttämä lomake). Kun käyttäjä valitsi jonkun paperiprototyypin painikkeen, hänelle annettiin toimintoa vastaava näyttökuva. Suurin osa ongelmista oli löydetty jo suunnittelijaryhmän sisäisissä käyttöliittymäkatselmuksissa, mutta jonkun verran korjattavaa löytyi vielä testitilanteessakin. Testin yhteydessä kommentoitavaksi ehtivät myös luonnokset käyttöliittymän visuaalisesta ulkoasusta, mutta ne olisi voitu esitellä myös jossain toisessa tilanteessa Käyttöliittymän visuaalisen ilmeen suunnittelu Käyttöliittymän visuaalisen ilmeen suunnittelun lähtökohtana oli suunniteltavan ohjelmistotuotteen rooli käyttäjätunnusten hallinnan apuvälineenä. Tyylilajiltaan tämä käyttöliittymä oli asiallinen toimistosovellus ja sen piti mielellään myös visualisoida taustalla olevaa tietokantaa jollain tavoin. Suunnittelu eteni perinteisen graafisen suunnittelun tapaan kokonaisuudesta yksityiskohtiin, värien ja sommitteluluonnosten kautta typografisten yksityiskohtien hiomiseen. Visuaalisesta ilmeestä tehtiin kolme erilaista luonnosta, joista asiakas valitsi yhden toteutettavaksi (kuva 3.2). Kuva 3.2. Yksityiskohtia käyttöliittymän visuaalisen ilmeen luonnoksista. 3.3 Johtopäätökset Käyttöliittymäsuunnittelun sijoittaminen ohjelmistotuotantoprosessin määrittelyvaiheeseen muuttaa projektin selvästi alkupainotteisemmaksi ja se pitää ottaa aikataulutuksessa huomioon. Varsinaiseen koodaustyöhön päästään myöhemmin, kuin mihin on ehkä totuttu, vaikka koko projektin tarvitsema aika pysyisikin samana. Projektiryhmän kokoonpano ja vastuunjako on suunniteltava huolellisesti. Aikataulut on tehtävä riittävän väljiksi, jotta paine aloittaa koodaaminen ennen käyttöliittymäsuunnitelman testaamista ei kävisi liian suureksi. Käyttöliittymäsuunnittelu auttaa yksinkertaistamaan tuotetta ja sitä kautta pienentää valmistuskustannuksia. Tekesin ohjelmapäällikkö Arto Ruokonen on laskenut, että muotoilijoiden osallistuminen tuotekehitykseen projektin alusta lähtien tarjoaa 5-0 prosentin kustannussäästöt tuotteen valmistuksessa (Juutilainen 2004). Tässä projektissa saatujen kokemusten perusteella on luonnosteltu käyttöliittymäsuunnittelun huomioiva vaatimusmäärittelymenetelmä, joka esitellään julkaisussa Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä (Toivanen ym. 2004). SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 27

28 ANNAMARI RIEKKINEN JA KIRSI KARVINEN 4 ARKKITEHTUURI- JA KOMPONENTTI- SUUNNITTELU 4. Johdanto Luvussa kuvataan menetelmäpilotti Pakkasen kokemukset arkkitehtuuri- ja komponenttisuunnittelussa sovelletusta menetelmästä. Alkuperäinen menetelmäkuvaus UML:n soveltamista myöten käydään läpi lähteessä (Cheesman ja Daniels 200). Suomennettuna menetelmäkuvaus esitetään pääpiirteittäin liitteessä 5. Tässä luvussa pääpaino on asioissa, jotka on tehty eri tavalla kuin alkuperäisessä menetelmässä. Keskeiset kokemukset kootaan johtopäätöksinä. 4.. Komponenttien ja arkkitehtuurin määrittely Palvelupohjainen komponenttilähestymistavan mukainen suunnittelu yhdistää tieto- ja toimintopohjaisen suunnittelun. Komponenttipohjaisessa suunnittelussa järjestelmä jäsennetään joukkona komponentteja, jotka tarjoavat käyttäjilleen palveluja. Suunnittelunäkökulmasta tämä tarkoittaa komponenttien ja komponenttiarkkitehtuurin määrittelyä. Arkkitehtuurinäkökulmasta ydinkomponentit edustavat kohdealueen keskeistä tietoa, johon arkkitehtuuri perustuu. Mutta palvelupohjainen arkkitehtuurista saadaan vasta, kun nämä tiedot ovat saatavissa ja hyödynnettävissä niin, että ne tukevat toimintaa. 4.2 Lähtökohdat arkkitehtuuri- ja komponenttimäärittelyyn 4.2. Cheesman & Danielsin menetelmä Cheesmanin ja Danielsin esittämä menetelmä valittiin komponenttien määrittelyyn sen vuoksi, että se vaikutti suoraviivaiselta ja tuntui olevan helposti käyttöönotettavissa. Toinen, tärkeämpi näkökulma oli se, että menetelmä painottaa komponenttien ja komponenttipohjaisten sovellusten ylläpitoa. Kolmas valintaperuste oli se, että menetelmä sisältyy komponenttipohjaisen ohjelmistotuotannon prosessimalliin, joka puolestaan perustuu Rational Unified Process eli RUP malliin. RUP-malli edustaa inkrementaalista ohjelmistotuotannon lähestymistapaa. Menetelmän lähtökohta on palvelupohjaisen komponenttilähestymistavan mukainen näkemys, jossa uudelleenkäytön lisäksi painotetaan komponenttien välisten riippuvuuksien hallintaa. Komponenttien väliset riippuvuudet määritellään rajapintatasolla, mikä tarkoittaa ylläpidon kannalta sitä, että tarjotun liittymän toteuttava komponentti voidaan vaihtaa vaikuttamatta siihen, miten samaa liittymää aiemmin käyttäneet ohjelmistot suorittavat liittymän kutsumisen. Komponenttien ja arkkitehtuurin määrittelyprosessi jakautuu kolmeen vaiheeseen:. komponenttien tunnistus, 2. komponenttien vuorovaikutuksen määrittely ja 3. komponenttien määrittely. 28 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

29 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Kukin vaihe sisältää erilaisia toimintoja. Menetelmän idea lyhyesti on se, että prosessin aikana vaatimusmäärittelystä saaduista syötteistä, käsitemallista ja käyttötapauskuvauksista, johdetaan rajapintojen, komponenttien ja komponenttiarkkitehtuurin määrittelyt (kuva 4.). Ensimmäisessä vaiheessa luodaan sovelluksen rakenteellinen perusta, jota täsmennetään toisessa vaiheessa määrittelemällä sovelluksen toiminnallisuus. Kolmannessa vaiheessa keskitytään komponentti- ja rajapintamääritysten dokumentointiin ja viimeistelyyn. Käsitemalli Käyttötapauskuvaukset Olemassa olevat rajapinnat (ulkoiset liittymät) Olemassa olevat komponentit ym. Luo toiminnan tietomalli Komponenttien tunnistusvaihe Tunnista toimintalogiikkatason rajapinnat Luo alustavat määrittelyt ja arkkitehtuuri Tunnista järjestelmärajapinnat ja operaatiot Arkkitehtuuri, arkkitehtuurimallit Toimintalogiikkarajapinnat: vastuukaavio Komponenttien vuorovaikutuksen määrittely Tunnista toimintalogiikkarajapintojen operaatiot Komponenttimäärittelyt ja Järjestelmärajapinnat arkkitehtuuri Muokkaa rajapintoja ja operaatioita Muokkaa määrittelyjä ja arkkitehtuuria Rajapinnat Komponenttimäärittelyt ja arkkitehtuuri Luo rajapintojen tietomallit Komponenttien määrittely Määrittele operaatioiden esija jälkiehdot Määrittele rajapintojen väliset rajoitukset Rajapintamäärittelyt Komponenttimäärittelyt ja arkkitehtuuri Kuva 4.. Komponenttien ja komponenttiarkkitehtuurien määrittely (Cheesman ja Daniels 200). Mallinnuksessa käytetään pääasiassa UML-notaatiota (Unified Modeling Language), joka on mallintamiskieli ja kuvaustapa oliosuuntautuneessa ohjelmistotuotannossa. Vaikka komponenttitoteutusten ei tarvitse perustua oliopohjaisiin ohjelmointikieliin, tarjoaa UML kuvaustekniikkana runsaasti valmiita käsitteitä ja piirteitä komponenttien määrittelyyn. Nykyinen UML-standardi ei kuitenkaan tue kaikkia haluttuja piirteitä, esimerkiksi UML-notaation komponenttikäsitteet on määritelty ennemminkin toteutuksen ja jakelun näkökulmasta kuin komponenttien määrittelyn näkökulmasta. Siksi alkuperäisessä menetelmässä määritellään joitakin laajennoksia käytettyyn UMLnotaatioon (versio.4). Menetelmässä käytettävät keskeisimmät UML-kaaviot ja kuvaukset ovat luokkakaavio, käyttötapauskuvaus ja vuorovaikutuskaavio. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 29

30 ANNAMARI RIEKKINEN JA KIRSI KARVINEN 4.3 Pakkasen arkkitehtuuri- ja komponenttisuunnittelu Pakkasessa komponenttisuunnittelua tehtiin kahdessa vaiheessa. Ensimmäisessä vaiheessa suunnittelu toteutettiin yhden käyttötapauksen osalta (käyttäjätunnuksen luonti) ja suunnittelussa edettiin alkuperäisen menetelmän mukaisesti. Toisessa vaiheessa käytettävissä oli sekä ensimmäisen vaiheen kokemukset että toimintalähtöisen vaatimusmäärittelyn ja käyttöliittymäsuunnittelun tulokset, joiden vaikutukset kuvataan tässä tarkemmin Komponenttien tunnistusvaihe Toimintalogiikkataso Pakkasessa ohjelmiston komponentit tunnistettiin yhden käyttötapauksen perusteella. Toimintalogiikkarajapintojen (business interface) tunnistaminen ja toimintalogiikkakomponenttien (business component) määrittely eteni suoraviivaisesti menetelmän mukaisesti niin, että vaatimusmäärittelyvaiheessa kootusta käsitemallista (concept model) johdettiin toiminnan tietomalli (type model). Tietomallista puolestaan johdettiin rajapintojen vastuukaavio (responsibility diagram), joka havainnollistaa kunkin rajapinnan kautta haettavat ja tallennettavat tiedot. Jokaiselle toimintalogiikkarajapinnalle luotiin oma komponenttimäärittely. Kuvien 4.2, 4.3 ja 4.4 avulla havainnollistetaan prosessi, jossa käsitemallista saadaan aikaan komponenttimäärittelyt. Concept model Type model In the present system there is a function for generating a username 0.. Staff -department Username 0.. -username : String {String: 6-8 bytes } 0....* -name Person Student -right_to_ study -training_program 0.. Client..* Account application form Server *..* -name : Integer -type (unix, other) -mailserver : Boolean * Server username -username : Integer 0....* *..*..* Staff (ext.) -department 0....* 0.. Usergroup -name : String..* Person register Usermanagement system {Username is formed on the basis of the existing function } 0..* AssociatedServer (server username) -serveruid : Integer -created : Date -closedfrom : Date -uid: userid -sid:serverid 0..* Server -name : String -description : String -unix : Boolean -mailserver : Boolean -deactivatedfrom : Date -sid: serverid Person -pid:personid -name : String -prevlastname : String -organization : String -right_to_study : String -training_program : String -valid : Date User -username : String[6..8] -closedfrom : Date -uid: userid -pid: personid..* ServerUsergroup 0..* -sid: serverid -ugid: usergroupid {Person data must be in person register before creation of username } 0..* AssociatedUsergroup -uid: userid -ugid: usergroupid 0..* Usergroup -name : String -ugid: usergroupid Kuva 4.2. Käyttäjätunnusten hallinnan käsitemallista (vasemmalla) johdetaan ohjelmiston tietomalli (oikealla) normalisoimalla käsitemallia ja kuvaamalla erilaisia suunnittelupäätöksiä, esimerkiksi liittymät toisiin järjestelmiin. Esimerkissä on tehty suunnittelupäätös, että käyttäjätunnusten hallintajärjestelmässä ei ylläpidetä henkilön perustietoja, vaan sovelluksessa hyödynnetään organisaatiossa olemassa olevaa henkilötietojärjestelmää. 30 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

31 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Type model Username management system: The responsibility diagram Person register Usermanagement system {Username is formed on the basis of the existing function } 0..* AssociatedServer (server username) -serveruid : Integer -created : Date -closedfrom : Date -uid: userid -sid:serverid 0..* Server -name : String -description : String -unix : Boolean -mailserver : Boolean -deactivatedfrom : Date -sid: serverid Person -pid:personid -name : String -prevlastname : String -organization : String -right_to_study : String -training_program : String -valid : Date User -username : String[6..8] -closedfrom : Date -uid: userid -pid: personid..* 0..* -sid: serverid -ugid: usergroupid ServerUsergroup {Person data must be in person register before creation of username } 0..* AssociatedUsergroup -uid: userid -ugid: usergroupid 0..* Usergroup -name : String -ugid: usergroupid Pakkanen: username management system 0..* «type» Associated server (server username) -Unix Uid : Integer -Valid Until : Date -DeactivatedFrom : Date -Description : String -Created : Date -sid: serverid -uid: userid -usid: userserverid 0..* «core type» Server -Name : String -Description : String -Type (unix, muu) -Mailserver : Boolean -Deactivated from : Date -sid : ServerID 0..* * «core type» User -User name : String -User type : Boolean -Description : String -uid:userid -pid:personid -closedfrom : Date -forpublicdir : Boolean «type» Associated user group -Primary user group : Boolean -asugid:assserverusergroupid -usid: userserverid -sugid: serverusergroupid * «interface» IUserManagement 0..* «type» Server's user group -Unix GId: int -Unix UidRange : String -sid: serverid -ugid: usergroupid -sugid:serverusergroupid * «core type» User group -Name : String -Description : String -oid: organizationid -ugid : usergroupid 0..* «interface» IServerManagement 0..* «interface» IUsergroupManagement «interface» IPerson Existing person register «core type» Person -lastname : String -firstname : String -prevlastname : String -birthdate : Date -identitynum : String -righttostudy : String -trainingprogram : String -validuntil : Date -pid : PersonID * «type» Person's organization -pid : PersonID -organization : OrganizationID * «core type» Organization -name : String -oid : OrganizationID Kuva 4.3. Tietomallista (vasemmalla) johdetaan toimintalogiikkarajapintojen vastuukaavio (oikealla). Vastuukaaviossa käytetty notaatio poikkeaa alkuperäisestä UML-notaatiosta, mikä Pakkasessa aiheutti väärinymmärrystä UML-asiantuntijoille. Vastuukaaviossa kompositionuoli ilmaisee toimintalogiikkarajapintojen vastuut tietokantaoperaatioista siten, että kukin rajapinta vastaa niiden tietojen hausta ja tallentamisesta, jotka siirtyvät sille kompositionuolen salmiakkipään osoittamalla tavalla. Esimerkiksi rajapinta IUser- Management vastaa käsitteiden User, Associated server ja Associated user group tietojen hausta ja tallennuksesta. Navigointinuolella kuvataan puolestaan vastuuta kahden eri rajapinnan kautta hallinnoitavien tietojen välisen viittauksen ylläpidosta. Esimerkiksi käsitetyyppi Associated Server ylläpitää viittausta palvelinkoneeseen, johon käyttäjälle on luotu käyttöoikeus. Komponenttimäärittelyt Rajapintamäärittelyt «comp spec» UserManager IUserManagement «interface» IUserManagement «comp spec» ServerManager IServerManagement «interface» IServerManagement «comp spec» UserGroupManager IUserGroupManagement «interface» IUsergroupManagemen «comp spec» Person Manager IPerson «interface» IPerson Kuva 4.4. Toimintalogiikkarajapinnoille luodaan omat komponenttimäärittelyt. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 3

32 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Järjestelmätaso Järjestelmärajapintojen (system interface) nimeäminen käyttötapausten perusteella todettiin hyväksi lähtökohdaksi järjestelmätason rajapintojen ja operaatioiden tunnistamiselle. Ensimmäisessä vaiheessa operaatioita tunnistettiin käyttötapauksen askeleista, mutta komponenttisuunnittelun toisessa vaiheessa suunnitteluryhmällä oli käytettävissään käyttöliittymäsuunnitelma, josta järjestelmätason operaatioita oli helppo löytää. Lisäksi järjestelmätason rajapintaoperaatioiden parametrit ja paluuarvot voitiin määrittää operaatioiden tunnistamisen yhteydessä (kuva 4.5) Alkuperäisessä menetelmässä operaatiossa välitettävä tieto päätellään vasta tarkasteltaessa komponenttien välistä vuorovaikutusta. If else Hakukriteerejä: nimi, syntymäaika, käyttäjätunnus tarkennettava If else Hakuoperaation palauttamaa: sukunimi, etunimet, henkilötunnus, mahdollinen käyttäjätunnus If else Operaatioita Kuva 4.5. Esimerkki käyttöliittymäsuunnitelmaan sisältyvästä henkilön käyttäjätietojen hausta. Suunnitelmassa näyttöjen avulla kuvataan käyttäjän työtehtävän eteneminen. Näin järjestelmätason operaatioita ja operaatioissa välitettävää tietoa voidaan määrittää käyttöliittymäsuunnitelman avulla. Arkkitehtuuri Ensimmäisessä vaiheessa alustava komponenttiarkkitehtuuri muodostettiin miettimällä kuinka komponentit kommunikoivat keskenään (kuva 4.6). Lopuksi arkkitehtuurimäärittely sijoitettiin nelikerroksiseen viitearkkitehtuuriin (kuva 4.7). Kuva 4.6. Pakkasen alustava komponenttiarkkitehtuuri, jossa UsernameManagementSystem -komponentti sijaitsee arkkitehtuurissa järjestelmäkerroksessa ja muut komponentit toimintalogiikkakerroksessa. 32 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

33 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Käyttäjätunnusten hallintajärjestelmä: ohjelmistoarkkitehtuuri Käyttöliittymä (User interface) Dialogikerros (Dialog layer) Username creator GUI «dialog comp» CreateUser Järjestelmäkerros (System layer) «comp spec» UsernameManagementSystem ICreateUser «uses» Toimintalogiikkakerros (Business layer) Person register «comp spec» Person Manager IPerson «uses» «uses» «uses» «comp spec» UserGroupManager IUserGroupManagement «comp spec» UserManager IUserManagement «comp spec» ServerManager IServerManagement Tietokanta (Database) Kuva 4.7. Pakkasen alustava arkkitehtuurimäärittely sijoitettuna viitearkkitehtuuriin Komponenttien vuorovaikutuksen määrittely Komponenttien vuorovaikutuksen tutkimisessa ensimmäinen tehtävä oli tunnistaa toimintalogiikkarajapintojen operaatiot. Cheesman ja Daniels käyttävät vuorovaikutuksen tutkimisessa ja kuvaamisessa UML-vuorovaikutuskaavioita (esimerkki: liite 5, luku 2.). Pakkasessa vuorovaikutuskaavioiden käyttö mallinnuksessa koettiin hitaaksi ja hankalaksi tavaksi, koska pikkutarkalla tasolla tapahtuvan tarkastelun takia kokonaisuus hävisi helposti. Siksi komponenttien välistä vuorovaikutusta ryhdyttiin tutkimaan käyttötapaus kerrallaan UMLsekvenssikaavion avulla (kuva 4.8). Sekvenssikaavioon kuvattiin kaikki yhdessä käyttötapauksessa tarvittavat rajapinnat. Ensimmäisessä vaiheessa operaatioiden parametreja määriteltiin vastuukaavion (kuvassa 4.3) ja olemassa olevan järjestelmän perusteella. Tämä tapa tuntui kuitenkin melko työläältä, koska tarkoitus oli joka tapauksessa määritellä toiminnallisuutta uudistettavaan vuorovaikutteiseen ohjelmistoon. Nykyisen ohjelmiston käyttäjienkin oli vaikea nähdä kaikkia tarvitsemiaan tietoja ilman konkreettisia näyttökuvia. Siksi toisessa vaiheessa suunnittelun avuksi saadut käyttöliittymänäytöt osoittautuivat tärkeäksi välineeksi operaatioiden määrittelyssä (esimerkki kuvassa 4.5). SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 33

34 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Dialogitaso Järjestelmätaso Toimintalogiikkataso «interface» ICreateUser +finduser() +getpersonuserdetails() +generateusername() +setuserdetails() +getserverdetails() +...() CreateUser (dialog) UserManagementSystem PersonManager UserManager :findpersonusersbypersondata (match).:findpersonsbypersondata(match) return (PersonDetails[]).2:findPersonUsersByPid(personID[]) return (UserDetails[]) return(personuser[]) «interface» ICreateUser Henkilön tiedot yhdistetään käyttäjätunnuksiin. +finduser() +getpersonuserdetails() +generateusername() +setuserdetails() +getserverdetails() +...() 2: getpersonuserdetails(pid) jne. Kuva 4.8. Dialogitasolta kutsutaan järjestelmätason operaatioita kronologisessa järjestyksessä. Operaatiot käydään läpi yksitellen, ja kunkin operaation osalta määritellään, miten sen suoritus jakautuu toimintalogiikkarajapinnoille. Esimerkki kuvaa vuorovaikutuksen tutkimisen henkilön tunnistamisessa. Ensimmäisen käyttötapauksen osalta toimintalogiikkatason rajapintaoperaatiot tunnistettiin kuvaamalla järjestelmäoperaatioiden tarkoitus. Esimerkkinä operaatiokuvaus finduser(): Operaation tarkoitus on tarjota järjestelmän käyttäjälle lista henkilöistä, joista käyttäjä voi valita. Sen sijaan, että operaatio näyttäisi kaikki järjestelmään tallennetut henkilöt, käyttäjän on annettava hakuarvona merkkijono, joka ainakin osittain vastaa henkilön nimeä tai syntymäaikaa. Järjestelmä palauttaa vain niiden henkilöiden tiedot, jotka sopivat annettuun hakuarvoon. Tarkastellaan edellä esitettyä kuvausta yksityiskohtaisemmin. Kohdat yksi ja kaksi käsittelevät järjestelmärajapintaoperaation määrittelyä. Kohdat kolme ja neljä selittävät toimintalogiikkarajapintojen tunnistuksen.. Käyttäjän on annettava hakuarvona merkkijono, joka ainakin osittain vastaa henkilön nimeä tai syntymäaikaa. Tämän perusteella saatiin operaatiosijoitus, jonka hakuparametrina välitetään merkkijono: findpersonuserbypersondata (in match:string). 2. Operaation tarkoitus on tarjota järjestelmän käyttäjälle lista henkilöistä, joista käyttäjä voi valita. Järjestelmä palauttaa vain niiden henkilöiden tiedot, jotka sopivat annettuun hakuarvoon. Tästä voitiin päätellä, että operaatio palauttaa listan joka sisältää henkilökäyttäjän tietoja: findpersonuserbypersondata (in match:string):personuser[]. Pakkasessa tehdyn suunnittelupäätöksen mukaisesti henkilö- ja käyttäjätietoja ylläpidetään eri järjestelmissä, joten seuraavaksi oli mietittävä, miten tietojen haku jakautuu toimintalogiikkarajapinnoille: 34 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

35 ANNAMARI RIEKKINEN JA KIRSI KARVINEN 3. Henkilötietojen haku henkilötiedoista hakuparametrin perusteella ja osajoukon palautus tuntui loogiselta vaihtoehdolta. Tämän perusteella tunnistettiin ensimmäinen toimintalogiikkatason rajapinta: findpersonsbypersondata(in match:string):persondetails[]. 4. Seuraavaksi edellisessä operaatiossa palautetuille henkilöille haetaan mahdolliset käyttäjätiedot, josta syntyi seuraava operaatiosijoitus: findpersonusersbypid(in personid[]): UserDetails[]. 5. Lopuksi tiedot yhdistetään järjestelmäkomponentissa ja palautetaan dialogitasolle. Järjestelmätason operaation haku- ja palautusparametrien perusteella saatiin määriteltyä myös toimintalogiikkatason operaatioiden parametrien sisällöt. Samalla tavalla käytiin läpi käyttötapauksen jokainen operaatio ja tuloksena saatiin käyttötapauksen operaatiot kuvaava yhtenäinen sekvenssikaavio sekä tarkennetut rajapintamäärittelyt operaatioiden ja operaatioparametreina välitettävien rakenteisten tietotyyppien osalta. Rajapinnat on esitetty kuvassa 4.9 ja tietyypit kuvassa 4.0. Järjestelmätaso «System interface» ICreateUser {documentation = An interface for creating a new personal username} +findpersonusersbypersondata(in match : String) : PersonUser[]{sequential,documentation = match: lastname (or part of it) lastname,firstname (or part of them) birthdate (or part of it) any combination of these } +generateusername(in lname : String, in fname : String) : String{sequential} +checkusername(in username : String) : Boolean{sequential} +setuserdetails(in ud : UserDetails) : Integer{sequential} +getservers() : ServerDetails[]{sequential} +getserverusergroups(in serverid : Integer) : ServerUsergroup[]{sequential} +generateunixuid(in serverid : Integer, in uidrange : String) : Integer{sequential} +setassociateduserdetails(in aud : AssociatedUserDetails) : Integer{sequential} +setassociatedusergroups(in asug : assserverusergroup[]) : integer[]{sequential} Toimintalogiikkataso «Business interface» IPersonManagement +findpersonsbypersondata(in match : String) : PersonDetails[] «Business interface» IUsergroupManagement +getserverusergroups(in sid : ServerID) : ServerUsergroup[] «Business interface» IServerManagement +getservers() : ServerDetails[] «Business interface» IUserManagement +findpersonusersbypid(in pids : PersonID[]) : UserDetails[] +generateusername(in lname : String, in fname : String) : String +checkusername(in username : String) : Boolean +getusername(in pid : PersonID) : String +setuserdetails(in ud : UserDetails) : Integer +generateunixuid(in sid : ServerID, in uidrange) : Integer +setassociatedserver(in aud : AssociatedUserDetails) : Integer +setassociatedusergroups(in asug : assserverusergroup[]) : integer[] Kuva 4.9. Rajapintamäärittelyt käyttötapauksen käyttäjätunnuksen luonti osalta. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 35

36 ANNAMARI RIEKKINEN JA KIRSI KARVINEN «datatype» PersonUser +lastname : String +firstname : String +birthdate : Date +prevlastname : String +identitynum : String +pid : PersonID +username : String +uid : UserID «datatype» PersonDetails {documentation = The data of one person} +lastname : String +firstname : String +prevlastname : String +birthdate : Date +identitynum : String +organization : String +righttostydy : String +train_program : String +validuntil : Date +pid : PersonID «datatype» UserDetails {documentation = The data of one user} +username : String +personalusername : Boolean = true +closedfrom : Date +uid : UserID +pid : PersonID Rakenteiset tietotyypit {documentation = «datatype» ServerDetails {documentation = The data of one server} +name : String +type : String +mailserver : Boolean +description : String +deactivatedfrom : Date +sid : ServerID +serverusergroups : ServerUsergroup[] «datatype» ServerUsergroup {documentation = The data of an association of usergroup and server} +serverusergroupid : Integer +uidrange : String +sid : ServerID +ugid : UsergroupID +sugid : ServerUsergroupID } «datatype» AssociatedUserDetails {documentation = The data of associated servers and their usergroups} +uid : UserID +servername : String +servertype : String +mailserver : Boolean +sid : ServerID +unixuid : Integer +validuntil : Date +created : Date +deactivatedfrom : Date +notforpublicdir : Boolean +audid : AssUserdetailsID +usergroups : assserverusergroup[] «datatype» assserverusergroup {documentation = The data of associated server's usergroups of one user} +primaryusergroup : Boolean +asugid : AssServerUsergroupID +audid : AssUserdetailsID +sugid : ServerUsergroupID Kuva 4.0. Operaatioissa parametreina välitettävät rakenteiset tietotyypit. Toisessa vaiheessa kun käyttötapauksia oli enemmän, ensin tutkittiin voidaanko toiminnallisuus toteuttaa jo määriteltyjen operaatioiden avulla ja mitä muutoksia tai tarkennuksia olemassa oleviin määrittelyihin mahdollisesti tarvittaisiin. Tämä tapa nopeutti huomattavasti operaatioiden määrittelyä. Lopuksi järjestelmätason operaatioita normalisoitiin niin, että operaatiot ryhmiteltiin eri käyttöoikeuksien perusteella rajapintoihin. Pakkasessa kaikki rajapinnat päätettiin tässä vaiheessa kuitenkin toteuttaa samassa komponentissa, mutta ohjelmistoa laajennettaessa myös toteutuksia voidaan vaihtaa. Esimerkki edellä esitetystä arkkitehtuurista on kuvassa 4.. Käyttäjätunnusten hallintajärjestelmä: ohjelmistoarkkitehtuuri (versio 2) Käyttöliittymä (User interface) Dialogikerros (Dialog layer) Username creator GUI «dialog comp» Username Järjestelmäkerros (System layer) Toimintalogiikkakerros (Business layer) Person register «comp spec» Person Manager «comp spec» UsernameManagementSystem {documentation = a component specification } «uses» IPerson «uses» «uses» «uses» IFindUser IGetUserData ISetUserData IUsernameUtilities IGetServerData «comp spec» UserGroupManager IUserGroupManagement «comp spec» UserManager IUserManagement «comp spec» ServerManager IServerManagement Tietokanta (Database) Kuva 4.. Pakkasen arkkitehtuuri viitearkkitehtuurissa. 36 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

37 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Komponenttien määrittely Tässä vaiheessa menetelmän mukaisesti määrittelyjä täydennettiin muun muassa miettimällä esi- ja jälkiehtoja. Lopuksi komponenttisuunnittelun tuloksena syntyneet rajapintamääritykset, vuorovaikutuskaaviot (sekvenssikaaviot) ja komponenttiarkkitehtuuri toimitettiin komponenttien ja sovelluksen toteuttajille. Kuhunkin rajapintamäärittelyyn sisältyi varsinainen rajapinta operaatiomäärittelyineen, kuvaus rajapinnan kautta haettavasta ja tallennettavasta tiedosta (rajapinnan tietomalli) sekä operaatioiden parametreina ja paluuarvoina välittämät rakenteiset tietotyypit. 4.4 Johtopäätökset Kaiken kaikkiaan arkkitehtuurin johtaminen ja komponenttien tunnistaminen menetelmän mukaan on suoraviivaista. Määrittelyitä täsmennetään siten, että erilaiset suunnittelunäkökulmat otetaan määrittelyssä huomioon yksi kerrallaan. Käyttötapauskohtaisesti etenevä komponenttien määrittelytapa on siis inkrementaalista suunnittelua. Pienten sovellusten osalta työtä ei kuitenkaan tarvitse jakaa erillisiin suunnitteluinkrementteihin, mutta laajojen hajautettujen järjestelmien osalta loogisen toimintokokonaisuuden muodostavat tehtävät voidaan hyvin erotella omiksi suunnitteluinkrementeikseen. Cheesman ja Daniels esittävät, että komponenttipohjaisessa ohjelmistotuotantoprosessissa käyttöliittymä suunnitellaan ja toteutetaan ohjelmiston koostamisen yhteydessä. Työryhmä on kuitenkin eri mieltä tästä asiasta tapauksissa, joissa ohjelmistokehityksen tavoitteena on tuottaa ohjelmistotuote, jolla on käyttöliittymä. Pakkasessa käyttöliittymäsuunnitelman puuttuminen koettiin ongelmana jo ensimmäisen iteraatiokierroksen komponenttisuunnittelussa, jossa määrittelyä tehtiin yhden käyttötapauksen näkökulmasta. Toiminnallisuuden määrittely (eli komponenttien välisen vuorovaikutuksen määrittely) oli vaikeaa ilman tarkkaa kuvausta siitä, kuinka sovellusta käytetään. Erityisesti operaatioissa välitettävän tiedon määrittely oli hankalaa ilman konkreettista kuvaa siitä, mitä tietoja tarvitaan. Alkuperäisen menetelmän mukaan komponenttien toiminnallisuuden määrittely on nimenomaan komponenttisuunnittelijoiden tehtävä. Kokemuksen perusteella voi kuitenkin sanoa, että jos toimitaan yksinomaan näin, päädytään todennäköisesti erilaisiin käytettävyysongelmiin ja sovelluslogiikkavirheisiin valmiissa ohjelmistossa (ks. luku 3.). Käyttöliittymäsuunnitelman avulla voidaan konkretisoida paitsi toiminnallisia vaatimuksia, myös varsinaiseen tietosisältöön liittyviä vaatimuksia. Kun käyttöliittymäsuunnittelu toisessa vaiheessa oli suunnittelijoiden käytettävissä, myös määrittelyprosessi helpottui ja nopeutui tältä osin. Kuvassa 4.2 alkuperäiseen komponenttien määrittelyprosessiin on lisätty Pakkasessa tehtyjen muutosten vaikutukset. Uudelleenkäytön näkökulmasta käyttöliittymäsuunnitelman käyttö komponenttien suunnittelussa voi johtaa siihen, että määrittelyt palvelevat yksinomaan ohjelmistoa, jonka perusteella komponentit on määritelty. Määrittelyissä hyvä suunnitteluperiaate on kuitenkin se, että suunnitellaan tämän hetkistä tarvetta varten, eikä yritetä liikaa ennustaa tulevia tarpeita. Joka tapauksessa toiminta muuttuu nopeammin kuin tieto. Siksi tarvitaan arkkitehtuuri ja arkkitehtuurimalli, joka perustuu ydintietoihin, mutta sallii toiminnan muutosten aiheuttamat muutokset ohjelmistossa suhteellisen vähällä vaivalla. Sovelletussa menetelmässä tämä on otettu huomioon määrittämällä komponenttien välinen vuorovaikutus rajapintatasolla. Esimerkiksi olemassa olevaan komponenttimäärittelyyn voidaan lisätä kokonaan uusi toiminnallisuus määrittämällä se omaan rajapintaansa. Näin entiset liittymät pysyvät voimassa, eikä uusi toiminnallisuus vaikuta olemassa oleviin kutsutapoihin. Siksi kutsuvassa ohjelmassa tai komponentissa ei tarvita muutoksia, ellei uutta toiminnallisuutta tarvita/haluta ottaa käyttöön. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 37

38 ANNAMARI RIEKKINEN JA KIRSI KARVINEN Tietomalli Komponenttien tunnistusvaihe Olemassa olevat rajapinnat (ulkoiset liittymät) Tunnista toimintalogiikkatason rajapinnat Luo alustavat määrittelyt ja arkkitehtuuri Tunnista järjestelmärajapinnat ja operaatiot. Huomioi parametrit. (Luo rajapintojen tietomallit) (Käyttötapauskuvaukset) Arkkitehtuurimallit Toimintalogiikkarajapinnat: vastuukaavio Komponenttimäärittelyt ja arkkitehtuuri Komponenttien vuorovaikutuksen määrittely Olemassa olevat komponentit ja komponenttiarkkitehtuuri Järjestelmärajapinnat Käyttöliittymäsuunnitelma (Käyttöliittymäsuunnitelma) Tunnista toimintalogiikkarajapintojen operaatiot ja muokkaa määrittelyjä. (Luo rajapintojen tietomallit) Muokkaa määrittelyjä ja arkkitehtuuria Rajapinnat Komponenttimäärittelyt ja arkkitehtuuri Komponenttien määrittely Määrittele operaatioiden esi- ja jälkiehdot Määrittele rajapintojen väliset rajoitukset Rajapintamäärittelyt Komponenttimäärittelyt ja arkkitehtuuri Kuva 4.2. Käyttöliittymäsuunnitelman olemassa olo suoraviivaistaa komponenttien määrittelyä. Määrittelyjen sijoittaminen organisaation omaan arkkitehtuuriin voi näyttää hyvin erilaiselta kuin mitä se on menetelmässä esitetyssä viitearkkitehtuurissa (kuvat 4.7. ja 4..). Tavallisesti olemassa oleva arkkitehtuuri ja valittu toteutustekniikka asettavat omat rajoituksensa todelliselle toteutusarkkitehtuurille. Siksi nämä asiat tulee ottaa huomioon jo niin varhaisessa vaiheessa kuin mahdollista. Pakkasessa kokeiluluonteen vuoksi suunnitteluperiaatteissa ja kuvauksissa on kuitenkin hyödynnetty alkuperäistä menetelmää ja sen mukaista viitearkkitehtuuria. Pakkasen osalta määrittelyarkkitehtuurin sijoittaminen toteutusarkkitehtuuriin ja viitearkkitehtuurin arviointi kuvataan tarkemmin luvussa 5: Tekninen suunnittelu ja toteutus. Kannattaa pitää mielessä seikka, että suunnitteluvaiheen tulokset ovat vasta määrittelyjä. Niitä joudutaan todennäköisesti tarkentamaan vielä seuraavassa vaiheessa, kun suunnittelun tulokset sijoitetaan toteutusarkkitehtuuriin ja toteutustekniikoihin ja sitä kautta siirrytään varsinaiseen toteutukseen. Siten tämän vaiheen tehtävissä ei kannata yrittää miettiä täydellisiä ratkaisuja paperilla, vaan samoin kuin vaatimuksia täsmennetään käyttöliittymäprotojen avulla, myös suunnittelupäätöksiä voidaan testata teknisten protojen avulla. 38 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

39 HANNU VIRKANEN, KIRSI KARVINEN, SAARA SAVOLAINEN JA JARI PORRASMAA 5 TEKNINEN SUUNNITTELU JA TOTEUTUS 5. Tekniselle ratkaisulle ja toteutukselle asetetut esiehdot ja vaatimukset Pakkasen toteutukseen sekä tekniikka- ja välinevalintoihin vaikuttivat seuraavat vaatimukset ja esiehdot, jotka koottiin projektin teknisten ratkaisujen työryhmässä: ) Sovellukseen tehdään web-käyttöliittymä. Web-käyttöliittymän valinnan perusteluina esitettiin esimerkiksi kyseisellä teknologialla toteutettujen sovellusten helppoa jaeltavuutta, ylläpidettävyyttä ja käyttäjän toimintaympäristöissä valmiina olevan infrastruktuurin (selain) hyödyntämismahdollisuuksia. 2) Järjestelmään toteutetaan standardit rajapinnat eri kerrosten välille, mitä kautta sovelluksen integrointi muihin järjestelmiin mahdollistuu ja myös yksinkertaistuu. Standardin mukaisilla rajapinnoilla saavutetaan myös toteutusten vaihdettavuus eri kerroksien osalta, esimerkiksi käyttöliittymän puolesta sovellus kyetään toteuttamaan web-teknologioiden lisäksi myös asiakaspään ympäristössä pyörivänä työpöytäsovelluksena. 3) Toteutuksessa hyödynnetään komponenttiteknologioiden ja palveluarkkitehtuurin tarjoamia etuja. Sovellus suunnitellaan monitasoarkkitehtuuriin ja koostetaan uudelleenkäytettävistä komponenteista ja palveluista, joita voidaan hyödyntää myös muissa sovelluksissa. 4) Valittujen teknologioiden tulee tukea PlugIT-rajapintamäärittelytyössä käyttöönotettuja teknologioita. Kerrosten väliset rajapinnat tulee olla mahdollista toteuttaa Web Services teknologioilla (web-palvelu). Tavoitteena on samalla hankkia lisää tietoa teknologian hyödyntämis- ja soveltamismahdollisuuksista todellisissa ympäristöissä. 5) Migraatio: olemassa olevan järjestelmän tietosisältö on oltava siirrettävissä uuteen tietokantaratkaisuun. 6) Mahdollisuuksia välinevalinnoiksi ja teknologioiksi eri kerroksiin olivat teknologiat ja sovelluskehitysvälineet, jotka ovat jo käytössä sovelluksen tulevassa toimintaympäristössä ja organisaatiossa. Uusia vaihtoehtoja tarjosivat PlugIT-hankkeessa mukana olevien infratoimittajien tarjoamat ratkaisut niin J2EE- (Oracle, BEA) kuin Windows- (Microsoft) ympäristöihin. 5.2 Tekninen suunnittelu ja arkkitehtuuriratkaisu Teknisen arkkitehtuurin suunnittelussa lähtökohtana olivat edellä esitetyt vaatimukset (luku 5.), Cheesmanin ja Danielsin (200) menetelmän mukaisen komponenttisuunnittelun tuottama komponenttiarkkitehtuuri (kuva 4.7) sekä menetelmän sisältämät teknisen suunnittelun näkökulmat (liite 5, luku 4). Pakkanen-projektin komponenttisuunnittelu on esitelty luvussa 4 ja menetelmä liitteessä 5. Lisäksi teknisen arkkitehtuurin suunnittelussa on huomioitu Bosch:in arkkitehtuurisuunnittelumenetelmä (Bosch 999). SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 39

40 HANNU VIRKANEN, KIRSI KARVINEN, SAARA SAVOLAINEN JA JARI PORRASMAA 5.3 Teknologia- ja välinevalinnat Projektissa tehtiin kaksi kokeilutoteutusta, joihin valitut ja käytetyt teknologiat ja välineet löytyvät alla olevasta kuvasta 5.. Molemmissa toteutuksissa sovelluspalvelinosuus toteutettiin Java/J2EEteknologioilla. Ensimmäisen toteutuksen web-käyttöliittymä toteutettiin MS.NET tekniikoilla ja välineillä. Toisen kokeilutoteutuksen käyttöliittymä puolestaan JavaBean/JSP-tekniikoilla. Teknologioita on kuvattu tarkemmin lähteessä (Mykkänen ym. 2004b). Välinevalintoja varten on koottu kriteerejä ja valintaperusteita lähteessä (Karvinen ym. 2004). Kuva 5.. Pakkasen toteutuksessa käytetyt välineet. Kuvassa merkityt käyttöliittymävälineet koskevat ensimmäistä toteutusta. Kuva mukailtu lähteestä (Mortensen ym. 2003). Alla olevassa taulukossa on esitetty yhteenvetona Pakkasen toteutuksen kehitys- ja tuotantoympäristön välinevalinnat. Tietokanta sovellus-/web-palvelimet Taulukko 5.. Pakkasen toteutuksen välinevalinnat. Oracle 9i R2 Oracle 9iAS, Microsoft IIS 5. (development environment) Kehitysympäristöt Oracle JDeveloper 9i/0g, (system / business logic layer) Microsoft Visual Studio.NET 2003 (dialog layer) 40 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

41 HANNU VIRKANEN, KIRSI KARVINEN, SAARA SAVOLAINEN JA JARI PORRASMAA 5.4 Toteutus kerroksittain 5.4. Käyttöliittymäkerros (Dialog Layer) Käyttöliittymän yhdeksi toteutustekniikaksi (. vaiheen suunnitteludokumenttien mukaiseen toteutukseen) valikoitui Microsoftin ASP.NET Web Forms, jonka toteutusväline on Visual Studio.NET 2003-sovelluskehitysympäristö. Käyttöliittymän toteutus tehtiin myös, 2. vaiheen suunnittelun mukaisena, JSP (Java Server Pages) -tekniikalla. Alkuperäisissä suunnitelmissa tarkoituksena oli toteuttaa käyttöliittymä J2EE -ympäristössä välineillä ja teknologioilla, jotka tukisivat MVC (Model-View-Controller) mallia, kuten Struts tai JavaServer Faces. MVC-suunnittelumallin soveltaminen parantaa esimerkiksi web-sovelluksen kohdalla koodin luettavuutta ja ylläpidettävyyttä. Esitys (View) eli HTML-koodi erotetaan toimintalogiikasta (Model), joka on taas erotettu tapahtumien hallinnasta (Controller). Toteutuksen aikana törmättiin kuitenkin ongelmiin Java-puolen käyttöliittymäteknologioiden käyttöönoton kanssa. Syinä olivat lähinnä teknologioiden edeltävä, puutteellinen tuntemus, kiireellinen pilotointiaikataulu ja välineiden tuolloin tarjoama vähäinen tuki valitulle teknologialle (Struts). Ratkaisuna päädyttiin hyödyntämään arkkitehtuurisuunnittelun ja tehtyjen suunnittelupäätösten tarjoamia mahdollisuuksia. Käyttöliittymän toiminnallisten ominaisuuksien toteutuksessa voitiin ottaa käyttöön mitkä tahansa välineet, jotka tukivat standardien mukaisesti Web Services cross platform -teknologiaa. Valittua teknologiaa käytetään tiedonvälityksessä käyttöliittymälogiikka- ja sovelluslogiikka kerrosten välillä (ks. kuva 5.2). Lisätietoja aiheesta ja vertailusta näiden vaihtoehtojen välillä esimerkiksi lähteessä (Mortensen ym. 2003). MVC-ohjelmointimallia on hyödynnetty ASP.NET Web Forms teknologiassa. Toteuttajan ei tarvitse itse huolehtia eri osa-alueiden erottamisesta toisistaan tai osien toiminnallisuuden yhteensovittamisesta. Toteutuksen pohjana on käytetty Visual Studio.NETin valmista ASP.NET Web Application -projektimallia, joka luo valmiiksi tarvittavien lähdekooditiedostojen pohjat: websovelluksen esitykselle HTML-lomake, toimintalogiikalle (codebehind-osio esim. C#-koodi) ja tapahtumien käsittelystä huolehtii sovelluskehitysympäristö. Web-sovelluksen ohjelmointi tässä ympäristössä vastaa samaa tapahtumapohjaista ohjelmointimallia, mikä on käytössä perinteisemmässä työpöytäsovellusten toteutuksessa. Web Forms sovellusten ajoalustana toimii sovelluskehittäjällä tyypillisesti Windowsin (mm. WinXP ja Win2000) mukana tuleva rajattu versio Microsoftin IIS (Internet Information Services) web-palvelimesta. Sovellus on siirrettävissä ja otettavissa käyttöön oikeassa ajoympäristössä eli tuotantopalvelimella. Toisen vaiheen suunnittelun mukaisena, JSP (Java Server Pages) -tekniikalla toteutetun käyttöliittymän JSP-sivujen pohjana olivat käyttöliittymäsuunnittelijan Dreamweaver -ohjelmistolla tekemät html-sivut. Tämän lisäksi oli tehtävä Java-papu (JavaBean-toteutus), jonka avulla saatiin EJB-komponenttien metoditoteutukset JSP-sivun käyttöön. Java-papuun koodattiin tarvittavat sovelluslogiikkatason metodien kutsut ja muokattiin tulokset sellaiseen muotoon että ne voitiin esittää JSP-sivuilla. Tässä toteutuksessa ei siis käytetty web-palveluita vaan suoraan EJB-papujen operaatioita. Dreamweaverilla toteutetut käyttöliittymäsuunnitelman näytöt oli hyvä lähtökohta käyttöliittymän toteuttamiseen. Html-sivut saatiin helposti käyttöön JDeveloperissa. Toteutustapa soveltuu yksinkertaiseen pieneen demoon, mutta on laajemmassa sovelluksessa työläs Sovelluslogiikkakerros (Business/System Layer) Toteutetun arkkitehtuurin liiketoiminta- ja järjestelmäkerrosten, jotka muodostavat yhdessä järjestelmän sovelluslogiikkakerroksen eli sovelluksen palvelinpään toiminnallisuuden, toteutukseen oli SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 4

42 HANNU VIRKANEN, KIRSI KARVINEN, SAARA SAVOLAINEN JA JARI PORRASMAA valittavissa samat kaksi päävaihtoehtoa kuin muihinkin kerroksiin monitasoarkkitehtuurin mukaisissa sovelluskehitysmalleissa; joko.net tai J2EE -teknologiat. Teknologioista päädyttiin valitsemaan J2EE (Java 2 Platform, Enterprise Edition) - ympäristö, joka on hajautettujen, komponenttipohjaisten monikerroksisten järjestelmien toteuttamiseen tarkoitettu Java-kieleen perustuva arkkitehtuuri. Ympäristö mahdollistaa ja tukee uudelleenkäytettävien komponenttien toteuttamista ja käyttöä toteutuksissa ja tarjoaa eri komponenttityypeille valmiit palvelut säiliöiden (container) muodossa. Säiliö toimii rajapintana komponentin ja alemman tason järjestelmäriippuvien palveluiden välillä. J2EE ympäristön todettiin tukevan ominaisuuksillaan käytetyllä suunnittelumenetelmällä saadun arkkitehtuurin toteutusta. Kuva 5.2. Komponenttiarkkitehtuuri sijoitettuna ensimmäisen vaiheen toteutusteknologioihin. 42 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

43 HANNU VIRKANEN, KIRSI KARVINEN, SAARA SAVOLAINEN JA JARI PORRASMAA EJB on J2EE-ympäristön hajautettu (palvelinpään) komponenttimalli. EJB-komponentin ajonaikainen ympäristö sovelluspalvelimessa on EJB-säiliö (EJB-container). EJB -papuja on kolmenlaisia: sessiopapuja, yksilöpapuja ja viestiohjautuvia papuja., joista toteutuksen komponenttimalliksi valittiin sessiopapu (session bean). Sessiopapu voi muodostaa tietokantayhteyden ja suorittaa tietokantaoperaatioita esim. JDBC -tietokantarajapinnan kautta. Sessiopapu voidaan toteuttaa joko tilallisena tai tilattomana. Sessiopavun valinnassa sovelluslogiikkakerroksen toteutuksen komponenttimalliksi oli yhtenä vaikuttavana tekijänä nimenomaan tilattoman sessiopavun tarjoamat mahdollisuudet päästä tarjoamaan komponentin palveluja myös standardin mukaisena webpalveluna (SOAP/WSDL), komponentin toiminnallisuuden ollessa itsessään lähellä tilattomia webpalveluita. Tämä mahdollisuus on useimmissa sovelluskehittimissä otettu huomioon tarjoamalla välineet palveluiden generointiin suoraan tilattomasta sessiopavusta. Kyseistä ominaisuutta päädyttiin myös hyödyntämään ensimmäisen toteutuksen yhteydessä (kts. luku 5.4.: Käyttöliittymäkerros). Sovelluslogiikkakomponenttien toteutuksessa käytetty sovelluskehitysympäristö on Oraclen JDeveloper (toteutuksen aikana versiot 9i ja 0g), johon on integroitu myös palvelinkomponenttien ajamista ja toteuttamista helpottamaan Oracle 9iAS sovelluspalvelin ja web-palvelin, jotka vastaavat Oraclen tarjoamia tuotteita oikeiksi tuotantoympäristöiksi. Toteutettujen ratkaisujen siirtäminen toteutusympäristöstä niiden varsinaiseen ajoympäristöön tuotantopalvelimelle on tuettu sovelluskehitysympäristössä. Palvelinpään komponenttien toteutus aloitettiin mallintamalla suunnittelun tuloksena saatu komponenttiarkkitehtuuri sovelluskehittimen mallinnustyökalulla (JDeveloper Class Modeler, kts. kuva 5.3). Mallinnettujen komponenttien toiminnallisuus toteutettiin välineen valmiiksi komponenttityypin toteutukselle generoimiin Java-pohjatiedostoihin. Kuva 5.3. Sovelluslogiikkakerros ensimmäisessä vaiheessa mallinnettuna JDeveloper Class Modeler -välineellä. SOVELTAMISKOKEMUKSIA OHJELMISTOTUOTANNON MENETELMISTÄ 43

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Juha Mykkänen, Irmeli Minkkinen, Assi Pöyölä, Annamari Riekkinen Kuopion yliopisto

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

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

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

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

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

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

Lisätiedot

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

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

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

Lisätiedot

Pakkanen * * * Sovellustuotannon menetelmäpilotti

Pakkanen * * * Sovellustuotannon menetelmäpilotti , mallit ym. Pakkanen * * * Sovellustuotannon menetelmäpilotti Pakkanen pähkinäkuoressa PlugIT-seminaari 29.-30.3.04 Annamari Riekkinen ja Kirsi Karvinen PlugIT Kuopion yliopisto / Tietotekniikkakeskus

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

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

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

Työpaja B. How to analyze your IT needs. Vaatimusmäärittelyn menetelmät (how to analyze. Toimintalähtöinen menetelmä. rajapintojen tunnistamisessa

Työpaja B. How to analyze your IT needs. Vaatimusmäärittelyn menetelmät (how to analyze. Toimintalähtöinen menetelmä. rajapintojen tunnistamisessa Työpaja B How to analyze your IT needs Vaatimusmäärittelyn menetelmät (how to analyze your IT needs): Toimintalähtöinen menetelmä Kotihoito - palveluverkoston tiedon tarpeiden selvittämisessä Neuvola -

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

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio Muutos PlugIT-tutkimusyhteistyösopimukseen, sivu 1/29 Muutos Tutkimusyhteistyösopimukseen PlugIT: Terveydenhuollon sovellusintegraatio 1. Projektiosapuolet: 1.1 Tutkimusosapuolet KUOPION YLIOPISTO, projektin

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

Yhteentoimivuusalusta: Miten saadaan ihmiset ja koneet ymmärtämään toisiaan paremmin?

Yhteentoimivuusalusta: Miten saadaan ihmiset ja koneet ymmärtämään toisiaan paremmin? Yhteentoimivuusalusta: Miten saadaan ihmiset ja koneet ymmärtämään toisiaan paremmin? Avoin verkkoalusta ihmisen ja koneen ymmärtämien tietomääritysten tekemiseen Riitta Alkula 20.3.2019 Esityksen sisältö

Lisätiedot

Ohjelmistotekniikka - Luento 2

Ohjelmistotekniikka - Luento 2 Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit

Lisätiedot

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu HELIA 1 (11) Luento 4 Käytettävyyden tuottaminen... 2 Käytettävyys ja systeemityöprosessi... 3 Määrittely... 3 Suunnittelu... 3 Toteutus ja testaus... 3 Seuranta... 3 Kriittiset tekijät käytettävyyden

Lisätiedot

Ohjelmistotekniikan menetelmät, kesä 2008

Ohjelmistotekniikan menetelmät, kesä 2008 582101 - Ohjelmistotekniikan menetelmät, kesä 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

Lisätiedot

Maestro Lappeenranta Mannerheiminkatu Lappeenranta. Maestro Helsinki Huopalahdentie Helsinki

Maestro Lappeenranta Mannerheiminkatu Lappeenranta. Maestro Helsinki Huopalahdentie Helsinki 1 Uusi asiakasyrityksen käyttäjätunnus MaestroNG-järjestelmään 1 Yleistä... 2 2 Perusta käyttäjäryhmät... 2 3 Lisää käyttäjäryhmille oikeudet... 3 Oikeus sivustoon... 3 Oikeus firmaan... 4 Oikeudet sovelluksiin...

Lisätiedot

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento

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

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

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

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

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

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

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

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

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

Lisätiedot

UCOT-Sovellusprojekti. Testausraportti

UCOT-Sovellusprojekti. Testausraportti UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä

Lisätiedot

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 582101 - Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 1 Lähestymistapoja Kokonaisvaltainen lähestymistapa (top-down) etsitään kerralla koko kohdealuetta kuvaavaa mallia hankalaa, jos kohdealue

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2009 582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

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

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

Ohjelmistotekniikan menetelmät, kevät 2008

Ohjelmistotekniikan menetelmät, kevät 2008 582101 - Ohjelmistotekniikan menetelmät, kevät 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

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

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

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan

Lisätiedot

Käyttäjäkeskeinen suunnittelu

Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan

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

Ohjelmistojen mallintaminen kertausta Harri Laine 1

Ohjelmistojen mallintaminen kertausta Harri Laine 1 kertausta 5.12.2008 Harri Laine 1 Ohjelmiston elinkaari, elinkaarimallit Yleinen puitemalli (reference model) - abstrakti kokonaiskuva ei etenemiskontrollia, ei yksityiskohtia Ohjelmistoprosessimallit

Lisätiedot

Määrittelyvaihe. Projektinhallinta

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

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2010

Ohjelmistojen mallintaminen, kesä 2010 582104 Ohjelmistojen mallintaminen, kesä 2010 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä

Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11 STUDIES AND REPORTS OF THE PLUGIT PROJECT 11 Marika Toivanen, Heidi Häkkinen, Irmeli Minkkinen, Annamari Riekkinen, Pauliina Ikävalko, Päivi Röppänen Toimintalähtöisyys

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet

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

Lisätiedot

Opistojohtaminen muutoksessa hanke. Kansanopiston kehittämissuunnitelma. Tiivistelmä kehittämissuunnitelman laatimisen tukiaineistoista

Opistojohtaminen muutoksessa hanke. Kansanopiston kehittämissuunnitelma. Tiivistelmä kehittämissuunnitelman laatimisen tukiaineistoista Opistojohtaminen muutoksessa hanke Kansanopiston kehittämissuunnitelma Tiivistelmä kehittämissuunnitelman laatimisen tukiaineistoista Opistojohtaminen muutoksessa hankkeessa ryhmä kansanopistoja laati

Lisätiedot

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen

Lisätiedot

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1 Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa 14.11.2008 Harri Laine 1 Oliot ohjelmiston mallinnuksessa käyttötapaus käyttää Käyttämämme oliokeskeinen perusmalli ohjelmistojen

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Yhteentoimiva.suomi.fi - palvelukokonaisuuden ja työkalujen esittely

Yhteentoimiva.suomi.fi - palvelukokonaisuuden ja työkalujen esittely Yhteentoimiva.suomi.fi - palvelukokonaisuuden ja työkalujen esittely Petri Tenhunen 6.3.2019 Esityksen sisältö Lyhyt oppimäärä Yhteentoimivuus ja semanttinen yhteentoimivuus Yhteentoimivuusalusta Sanastot-työkalu

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

Kurssin aihepiiri: ohjelmistotuotannon alkeita

Kurssin aihepiiri: ohjelmistotuotannon alkeita Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Tuotemallipohjaisen toimintaprosessin mallintaminen

Tuotemallipohjaisen toimintaprosessin mallintaminen Tuotemallipohjaisen toimintaprosessin mallintaminen Miksi? Miten? Mitä? Mitä sitten? Kari Karstila Eurostepsys Oy kari.karstila@eurostep.com www.eurostep.com Pro IT-seminaari, 2004-01 01-1919 PROSESSIMALLINTAMISEN

Lisätiedot

Tietohallinto Projektipäällikkö Matti Sairanen. Fujitsu Myyntijohtaja Markku Örn

Tietohallinto Projektipäällikkö Matti Sairanen. Fujitsu Myyntijohtaja Markku Örn Tietohallinto Projektipäällikkö Matti Sairanen Fujitsu Myyntijohtaja Markku Örn Sähköinen asiakirjahallinta Sähköinen työpöytä Dokumenttienhallinta (kuvatut käsittelyprosessit) Asiahallinta Sähköinen arkisto

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

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

Sairaalarakennusten ja toimintojen kehittämien Lean-ajattelun avulla

Sairaalarakennusten ja toimintojen kehittämien Lean-ajattelun avulla Sairaalarakennusten ja toimintojen kehittämien Lean-ajattelun avulla TeLean-hanke 1.8.2014-31.10.2017 Jori Reijula Dosentti,TkT Johtava asiantuntija Granlund Consulting Hankkeen lähtökohdat SOTE-uudistus:

Lisätiedot

A4.1 Projektityö, 5 ov.

A4.1 Projektityö, 5 ov. A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia

Lisätiedot

UMTK- SUUNNITTELUPROJEKTIN ESITTELY (UMTK = MML:N UUSI MAASTOTIETOJEN TUOTANTOJÄRJESTELMÄ)

UMTK- SUUNNITTELUPROJEKTIN ESITTELY (UMTK = MML:N UUSI MAASTOTIETOJEN TUOTANTOJÄRJESTELMÄ) UMTK- SUUNNITTELUPROJEKTIN ESITTELY (UMTK = MML:N UUSI MAASTOTIETOJEN TUOTANTOJÄRJESTELMÄ) Kai Koistinen 1 TAUSTAA 2 KMTK Kansallinen maastotietokanta kokoaa yhteen peruspaikkatiedot, joita ovat Rakennukset

Lisätiedot

SilvaToiminta Versio 1.0. SilvaToiminta. Pikaohje Versio Oy Silvadata Ab Pikaohje 1

SilvaToiminta Versio 1.0. SilvaToiminta. Pikaohje Versio Oy Silvadata Ab Pikaohje 1 SilvaToiminta Pikaohje Versio 1.0 12.12.2014 Oy Silvadata Ab 10.12.2014 Pikaohje 1 SISÄLLYS 1 SILVATOIMINTA... 3 2 OHJELMISTON KÄYTTÖTARKOITUS... 4 2.1 Osiot... 4 2.1.1 Asiakkaat... 4 2.1.2 Viestit...

Lisätiedot

Projektityö

Projektityö Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:

Lisätiedot

Haaga-Helia / TIKO-05 1 (12) Tietokannan suunnittelu ja Toteutus Outi Virkki

Haaga-Helia / TIKO-05 1 (12) Tietokannan suunnittelu ja Toteutus Outi Virkki Haaga-Helia / TIKO-05 1 (12) Tietotarpeet Tietotarpeiden määrittely... 2 Tietotarveanalyysi... 3 Lähtökohtana tietojenkäsittelytehtävät... 3 Määrittelyn sisältö... 4 Vaiheistus... 5 Tietolähteet... 5 Lähestymistapa...

Lisätiedot

Sosiaalihuollon toimintaprosessien mallinnus. Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä

Sosiaalihuollon toimintaprosessien mallinnus. Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä Sosiaalihuollon toimintaprosessien mallinnus Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä Sisältö Taustaa Tavoite Lähtökohta Tuotokset Prosessien kuvaaminen esimerkkinä lasten päivähoito

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Opinajan käytön aloittaminen koulussa/oppilaitoksessa

Opinajan käytön aloittaminen koulussa/oppilaitoksessa Opinajan käytön aloittaminen koulussa/oppilaitoksessa Yleistä Opinaika löytyy osoitteesta: http://www.opinaika.fi Jokainen oppilas ja opettaja tarvitsevat oman käyttäjätunnuksen ja siihen liittyvän salasanan

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

arvioinnin kohde

arvioinnin kohde KEMIA 9-lk Merkitys, arvot ja asenteet T2 Oppilas tunnistaa omaa kemian osaamistaan, asettaa tavoitteita omalle työskentelylleen sekä työskentelee pitkäjänteisesti T3 Oppilas ymmärtää kemian osaamisen

Lisätiedot

Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita?

Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita? #finnayhdessä Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita? Riitta Peltonen, johtava käytettävyyssuunnittelija, Finnan 5-vuotisseminaari,

Lisätiedot

UML- mallinnus: Tilakaavio

UML- mallinnus: Tilakaavio UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista

Lisätiedot

Liittymät Euroclear Finlandin järjestelmiin, tietoliikenne ja osapuolen järjestelmät Toimitusjohtajan päätös

Liittymät Euroclear Finlandin järjestelmiin, tietoliikenne ja osapuolen järjestelmät Toimitusjohtajan päätös Liittymät Euroclear Finlandin järjestelmiin, tietoliikenne ja osapuolen järjestelmät Toimitusjohtajan päätös Tilinhoitajille Selvitysosapuolille Liikkeeseenlaskijan asiamiehille Sääntöviite: 1.5.9, 5)

Lisätiedot

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari

Lisätiedot

SOLEA-tulosseminaari Päätössanat

SOLEA-tulosseminaari Päätössanat SOLEA-tulosseminaari Päätössanat Espoo, 25.11.2011 Juha Mykkänen, Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos, HIS-yksikkö Kari Hiekkanen, Aalto-yliopiston Teknillinen korkeakoulu, SoberIT-laboratorio

Lisätiedot

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

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

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

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

Strategia prosessista käytäntöön!

Strategia prosessista käytäntöön! Strategia prosessista käytäntöön! Kuntayhtymän johtaja, sairaanhoitopiirin johtaja, TtM Maire Ahopelto, Kainuun sote Hyve-johtamisen kartta hanke Loppuseminaari 29.9.2014 Kainuun osahankkeen tavoitteet

Lisätiedot

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Omistaja Tyyppi Tiedoston nimi Turvaluokitus Kohderyhmä Turvaluokituskäytäntö --- SE/Pekka Järveläinen Projektisuunnitelma projektisuunnitelma_kielihallinto.doc

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

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

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

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

Kansallinen ASPAtietojärjestelmä

Kansallinen ASPAtietojärjestelmä Kansallinen ASPAtietojärjestelmä Taustoitus Järjestäjien tarve yhteiselle asiakaspalautteen keräämisen järjestelmälle nousi esiin kevään selvityksessä Asiakaspalautetieto on myös osa kansallista sote-tietopohjaa

Lisätiedot

XBRL-raportointi julkishallinnolle. Tietojärjestelmätoimittajainfo Kuntatieto-ohjelmasta Seppo Harju

XBRL-raportointi julkishallinnolle. Tietojärjestelmätoimittajainfo Kuntatieto-ohjelmasta Seppo Harju XBRL-raportointi julkishallinnolle Tietojärjestelmätoimittajainfo Kuntatieto-ohjelmasta 25.4.2017 Seppo Harju Fujitsu maailmalla ja suomessa Maailman suurimpia ict-palveluiden tarjoajia, markkinajohtaja

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

Sosiaalihuollon asiakastietomallin hallinta

Sosiaalihuollon asiakastietomallin hallinta Sosiaalihuollon asiakastietomallin hallinta Jarmo Kärki & Erja Ailio 24.6.2014 Asiakastietomallin hallinta / Kärki & Ailio 1 Esityksen sisältö Millainen ylläpidon ja kehittämisen rakenne on sosiaalihuollon

Lisätiedot

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty

Lisätiedot

Elisa Toimisto 365. Pääkäyttäjän pikaopas

Elisa Toimisto 365. Pääkäyttäjän pikaopas Elisa Toimisto 365 Pääkäyttäjän pikaopas Päivitetty 10/2016 Tämän pikaoppaan avulla pääset alkuun Elisa Toimisto 365 -palvelun käyttöönotossa. Lisää ohjeita löydät osoitteesta http://www.elisa.fi/toimisto365-ohjeet/

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

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

Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä

Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti Tiivistelmä Huhtikuu 2007 1 1 Hankkeen tausta ja tarpeet EU:n ympäristösäätely

Lisätiedot

Keskustelusivusto. Suunnitteludokumentti

Keskustelusivusto. Suunnitteludokumentti Keskustelusivusto Suunnitteludokumentti Tietokantasovellus, Syksy 2007, Ryhmä 1 Tuomas Puikkonen tpuikkon@cs.helsinki.fi Tietojenkäsittelytieteen laitos Helsingin Yliopisto Sisältö Keskustelusivusto...1

Lisätiedot

Sosiaalihuollon valtakunnallisten tjpalveluiden

Sosiaalihuollon valtakunnallisten tjpalveluiden Sosiaalihuollon valtakunnallisten tjpalveluiden ratkaisuarkkitehtuuri Tilannekatsaus 13.3.2015 Arkkitehtuuriryhmä Ratku projektissa: määritellään sosiaalihuollon valtakunnallisten tietojärjestelmäpalelujen

Lisätiedot

Tietokantojen suunnittelu, relaatiokantojen perusteita

Tietokantojen suunnittelu, relaatiokantojen perusteita Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

Integrated Management System. www.ims.fi, Ossi Ritola

Integrated Management System. www.ims.fi, Ossi Ritola Integrated Management System www.ims.fi, Ossi Ritola Mitä prosessien tunnistaminen on? Löydämme ja ryhmittelemme organisaation toistettavat työnkulut optimaalisimmalla tavalla organisaation tulevaisuuden

Lisätiedot

Maestro Lappeenranta Mannerheiminkatu Lappeenranta. Maestro Helsinki Huopalahdentie Helsinki

Maestro Lappeenranta Mannerheiminkatu Lappeenranta. Maestro Helsinki Huopalahdentie Helsinki 1 Uusi asiakasyrityksen käyttäjätunnus MaestroNG-järjestelmään 1 Yleistä... 2 2 Perusta käyttäjäryhmät... 2 3 Lisää käyttäjäryhmille oikeudet... 3 Oikeus sivustoon... 3 Oikeus firmaan... 4 Oikeudet sovelluksiin...

Lisätiedot