Pakkanen * * * Sovellustuotannon menetelmäpilotti Pakkanen pähkinäkuoressa PlugIT-seminaari 29.-30.3.04 __________________________________________________________ Annamari Riekkinen ja Kirsi Karvinen PlugIT Kuopion yliopisto / Tietotekniikkakeskus /HIS-tutkimusyksikkö

Sisältö Komponenttilähestymistapa käsitteenä: yhteyksien hallinta rajapintatasolla, arkkitehtuuri ja prosessiajattelu. Pakkasen taustaa: tarve menetelmäpilotille ja pilottikohteen esittely. Pakkasen keskeisimmät näkökulmat lyhyesti Pakkanen iteratiivinen prosessi: 2 päävaihetta Taustamateriaalia: Käsitteitä, teoreettinen tausta

Komponentti- ja palvelupohjaisuus Sovellus jäsennetään joukkona komponentteja, jotka tarjoavat käyttäjilleen palveluja  suunnittelunäkökulma Jokainen komponentti rakentuu joukosta yhteistyötä tekeviä olioita (sisäisen toteutuksen ei kuitenkaan tarvitse olla oliopohjainen!)  toteutusnäkökulma

Arkkitehtuuri keskeisessä roolissa Toiminnan jakaminen itsenäisiin osiin  uudelleenkäytettävyys  korvattavuus (ylläpito)

Komponenttipohjainen ohjelmistotuotanto Ohjelmistotuotannon kaikki vaiheet perustuvat komponentteihin toimintalähtöinen vaatimusmäärittely: vaatimukset toimintaprosesseja tarkastelemalla  toiminnan kannalta keskeisten komponenttien tunnistaminen. sovelluksen ja sovellusarkkitehtuurin suunnittelu. komponenttien toteutus (hankinta) ja sovelluksen koostaminen. sovelluksen testaus. sovelluksen käyttöönotto (tekninen: sovelluksen hajautus). komponenttien (ohjelmisto-osien ja palveluiden) itsenäinen jakelu.  tekniikat (J2EE,.NET, web, tietokannat, jne.)  prosessi ja menetelmät, jotka tukevat komponentti- ja palvelulähestymistapaa.

Prosessiajattelu Ohjelmistoja tuotetaan prosessissa, jossa on erilaisia vaiheita (tai tasoja). Vaiheisiin sisältyy erilaisia tehtäviä ja tehtäväkokonaisuuksia, joilla on erilaisia keskinäisiä riippuvuuksia. Prosessi on iteratiivinen ja samoin eri vaiheet ovat iteratiivisia. Miten tehtäväkokonaisuudet tukevat toisiaan kokonaisprosessissa?

Tausta ja tarve menetelmäpilotille Miksi menetelmäpilotti? Terveydenhuollon ohjelmistojen toimittajien tarve ottaa käyttöön uudempia tekniikoita. Myös yliopistossa on edessä tilanne, jossa valitaan tekniikat ja välineet tulevaisuuden sovelluskehitystarpeisiin  tarjoaa pilottiympäristön. Lähtökohdaksi on valittu komponentti- ja palvelulähestymistavan mukaiset tekniikat. Tekniikoiden lisäksi tarvitaan tietoa siitä, millainen prosessi ja millaiset menetelmät tukevat valitun lähestymistavan mukaista sovelluskehitystä.

Pilottikohteen esittely Tietotekniikkakeskuksessa kehitetty Pakka-sovellus, jonka avulla ylläpidetään Tiken hallinnoimien palvelinkoneiden käyttäjätunnuksia. Pilotoinnissa tarkastelussa keskeisimpien toimintojen osalta. Nykyisellä sovelluksella muutama käyttäjä. Fileman ja Delphi-FixÍT-tekniikoihin perustuva työpöytäsovellus. Pakan tarkoitus: helpottaa palvelinkoneiden käyttäjätunnusten hallintaa ja käyttäjän elämää, esimerkiksi: mahdollistaa yksikäsitteisen käyttäjätunnuksen voimassaoloaika, tunnuksen varaus sulkemisen jälkeen ym.

Pakkasen tehtävät Tehtävämääritelmä: sovellusosan uusiminen palvelupohjaiseen komponenttiarkkitehtuuriin käyttämällä teollisuusstandardeihin pohjautuvia tekniikoita sekä PlugIT-projektissa tutkittuja tai kehitettyjä menetelmiä niin, että menetelmäpilotissa saadut tulokset ovat ohjelmistoyritysten hyödynnettävissä. Tehtävä on selvittää, kuinka kattavia johtopäätöksiä organisaatiossa voidaan tehdä sovellusosan toteutuksen pohjalta valittaessa uusia tekniikoita sovelluskehitystä varten – päätöksenteon tuki. Tehtävä on koota kokemusten pohjalta kevyet toimintatavat, jossa eri tehtäväkokonaisuudet tukevat toisiaan prosessissa.

Pakkanen keskeisten näkökulmien valossa

Vaikutteet ja näkökulmat Käytettävyys Laadunvarmistus (Turvallisuus) (Ohjausprosessi) Komponentti- ja palvelulähestymistavan vaatimukset Prosessiajattelun tuki: eri tehtäväkokonaisuuksien keskinäiset riippuvuudet ja vaiheistus Käytettävyys ja laadunvarmistus (turvallisuus ja ohjausprosessi) Prosessi, joka tukee komponentti- ja palvelupohjaista lähestymistapaa s.e. laadunvarmistus ja käytettävyys huomioidaan koko prosessin ajan (turvallisuus ja ohjaus).  Menetelmäkehitys on iteratiivinen prosessi

Iteratiivinen menetelmäkehitys Perusprosessimallin valinta: vaatimusmäärittely komponettien ja arkkitehtuurin määrittely komponenttien hankinta (toteutus) sovelluksen kokoaminen testaus (käyttöönotto ja ylläpito) Menetelmien valinta: toimintalähtöinen vaatimusmäärittely: työtoiminnan malli menetelmä komponenttien ja arkkitehtuurin määrittelyyn (näkökulmia määrittelyjen sijoittamiseksi toteutustekniikoihin) tavoitteet ja vaatimukset teknisille ratkaisuille

Pakkasen toteutus 1. vaiheessa Iteraatio: Prosessi vaatimusmäärittelystä toteutukseen yhden käyttötapauksen osalta. Valittujen menetelmien (vaatimusmäärittely ja komponenttien määrittely) käyttöönotto ja opiskelu käytännön soveltamisen myötä. Tekniikoiden valinta ja teknisten ratkaisujen kokeilut yhden käyttötapauksen osalta. arviointi

Iteratiivinen menetelmäkehitys Havaitut ongelmat: Käyttöliittymäsuunnittelun tuki puuttui. (Formaali tarkastusmenettely raskas laadunvarmistuksessa).  Painopiste käytettävyyden huomiointiin prosessissa. Menetelmäkehitys: käytettävyysnäkökulma mukaan vaatimusmäärittelyvaiheen alusta alkaen toimintalähtöinen vaatimusmäärittely: toimintaprosessit komponenttien ja arkkitehtuurin määrittelymenetelmän validointia teknisten ratkaisujen arviointia laadunvarmistukseen läpikäynnit ja katselmoinnit

Pakkasen toteutus 2. vaiheessa How to DoIT Pakkanen Prosessin täydennys käytettävyys- (käyttöliittymän suunnittelu) ja laadunvarmistusnäkökulmilla. Tehtävä: Demosovelluksen toteuttaminen  kokemusten paketointi menetelmäsalkkuun.

Pakkasen tulokset (Turvallisuus) (Ohjausprosessi) Käytettävyys Laadunvarmistus (Turvallisuus) (Ohjausprosessi) Dokumentoitu demosovellus Pakkanen Menetelmäkuvaukset menetelmäsalkkuun: toimintalähtöinen vaatimusmäärittely käyttöliittymän suunnnittelu komponenttien ja sovelluksen arkkitehtuurin määrittely komponenttien ja käyttöliittymän toteutus ja sovelluksen koostaminen laadunvarmistus Arviointia: vaatimuksia ja tavoitteita tekniikoiden ja välineiden valintaan saatujen tulosten yleistettävyys

Pakkanen - tavoitteita Koota kokemukset erilaisista menetelmistä siten, että ne tukevat prosessiajattelua: toimintalähtöinen vaatimusmäärittely sovelluksen palveluarkkitehturin luonti komponenttien määrittely ja dokumentointi käyttöliittymä- ja tietokantasuunnittelu komponenttien toteuttaminen valituilla tekniikoilla sovelluksen koostaminen ja testaus (komponenttien että komponenttipohjaisten sovellusten käyttöönotto ja ylläpito) käytettävyys- ja laadunvarmistusnäkökulman huomiointi koko prosessissa. Selvittää millaisia asioita ja näkökulmia pitäisi ottaa huomioon tekniikkavalintoja tehdessä (projekti/organisaatiokohtisesti).

Pakkanen - tavoitteita Koota kokemuksia sovelluksen toteuttamisesta komponenttipohjaisen lähestymistavan periaatteiden mukaan eri tekniikoilla ja välineillä. määrittelyjen sijoittaminen toteutustekniikoihin, esim. palveluarkkitehtuurin sijoittaminen J2EE ja .NET –arkkitehtuureihin. komponenttien rakentaminen, sovelluksen koostaminen ja ulkopuolisen palvelun käyttöönotto sovelluksessa. ratkaisut komponenttivarastoksi? eri tekniikoiden perusfilosofia ja periaatteet, minkälaisiin tilanteisiin soveltuvat? tekniikoiden ja välineiden käyttöönotto? Migraatiokokeilut: Fileman-kannasta relaatiokantaan: tietokantarakenteen ja tietojen siirto: mitä voidaan/kannattaa automatisoida ja mitä on tehtävä käsityönä. Pilottiprojektin rooli päätöksenteon tukena (saavutettujen tulosten soveltaminen todellisuudessa).

Pakkanen: teoreettinen tausta, käsitteitä

Käsitteitä Sovellustuotantoprosessin päävaiheet: määrittely, suunnittelu, toteutus, testaus ja käyttöönotto (sekä ylläpito). Prosessimallit: Vesiputousmalli: prosessissa vaiheet seuraavat toisiaan peräkkäin niin, että koko sovelluksen osalta edellinen vaihe tehdään loppuun ennen seuraavaan vaiheeseen siirtymistä.  Ohjelman toimintalogiikka ja tietosisällön käyttötavat konkretisoituvat projektin lopussa. Soveltuvuus työtehtäviin voidaan varmistaa vasta kuin sovellus on kokonaan valmis. Inkrementaalinen (ja iteratiivinen) lähestymistapa: ohjelmistoa kootaan osissa siten, että aluksi suunnitellaan ja koodataan pieni osa toiminnallisuutta, joka testataan. Seuraavaksi suunnitellaan lisää toimintoja, jotka toteutetaan ja testataan.  Muutoksiin varaudutaan koko ohjelmiston kehitysprojektin ajan (uskomus, että vaatimuksia ei voida saada riittävän hyvin selville projektin alussa).

Komponenttipohjaisen sovellustuotannon näkökulmia Toimintaprosessit sovellustuotannon lähtökohtana: määritellään sovelluksen rajat ja tavoitteet (käyttötapaukset) ts. määritellään mitä toimintaprosesseja sovellus tukee ja miten. Palveluarkkitehtuuri: sovellus määritellään joukkona komponentteja, jotka tarjoavat toisilleen palveluja rajapintojensa (eli liittymiensä) kautta. Komponenttivarasto: uudelleenkäyttö. Dokumentointi tärkeää: käyttömahdollisuudet, käyttörajoitukset, versiointi. Komponenttien hankinta: löydettävyys, panostuksen uudelleenkäyttöön täytyy olla (huomattavasti) pienempi kuin sen tekeminen (uudelleen). Komponenttiteknologiat (mm. J2EE/.NET). Komponenttien toteutus, sovelluksen koostaminen ja suoritusympäristö.

Komponenttipohjaisen sovellustuotannon näkökulmia Sovelluskehityksessä kaksi erillistä prosessia: sovellusten koostaminen komponenteista (löytäminen, yhdistäminen ja mukauttaminen) yksittäisten komponenttien toteuttaminen (määrittelyjen pohjalta) Sovellustuotannon vaiheita vaatimusmäärittely (keräys, kokoaminen ja analysointi, kuvaus) sovelluksen määrittely ja suunnittelu (komponentit ja niiden rajapinnat, palveluarkkitehtuuri, käyttöliittymä, tietovarasto) komponenttien hankinta (toteutus, osto, teetto, ulkopuolisen palvelun käyttöönotto, oman olemassa olevan palvelun käyttöönotto jne.) sovelluksen koostaminen (komponenttien yhdistäminen ja mukauttaminen) sovelluksen testaus sovelluksen jakelu ja käyttöönotto sovelluksen ylläpito

Cheesman&Daniels: komponenttipohjainen sovellustuotantoprosessi Pakkasessa sovellettu perusprosessi

Cheesman&Daniels sovellustuotantoprosessi Perustuu Rational Unified Process l. RUP-malliin. Periaate ylläpidon näkökulma: painottaa komponenttien välisten riippuvuuksien hallintaa  toteutus voidaan vaihtaa ilman, että se vaikuttaa liittymän olemassa olevien käyttäjien tapaan kutsua palveluja . Painopiste on arkkitehtuurissa, jossa komponenttien väliset riippuvuudet ja yhteydet määritellään rajapintatasolla. Mallinnustekniikka UML, johon on tehty joitakin laajennoksia (määrittelynäkökulma). Ei huomioi riittävästi käyttöliittymän suunnittelua. Lisäksi tarvitaan (ainakin) laadunvarmistus-, turvallisuus- ja ohjausnäkökulma. Pakkasessa pääpaino on ollut käytettävyys- ja laadunvarmistusnäkökulmissa, mutta turvallisuus- ja ohjausnäkökulmia ei ole käyty läpi yhtä systemaattisesti.

GUIDe prosessimalli Käyttäjien työnkulut selvitetään vaatimusmäärittelyvaiheessa pääasiassa kenttätutkimusten avulla (vrt. toimintalähtöinen vaatimusmäärittely). Tärkeimmistä työtehtävistä ja tavoitteista johdetaan käyttöliittymäkuvaus, joka testataan. Testattu (ja hyväksytty) kuvaus siirtyy toteutuksen suunnitteluun.

GUIDe prosessimalli Projektimalli perustuu käyttäjien työtehtäviä kuvaaviin tavoitepohjaisiin käyttötapauksiin (goal-based use cases) ja käyttöliittymäsuunnitteluun (goal-derived design). Käyttöliittymä suunnitellaan heti projektin alussa vaatimukseksi toteutukselle. Tavoitteena testata käyttöliittymäratkaisuja ja ohjelmiston soveltuvuutta työtehtäviin varhaisessa vaiheessa, jolloin muutosten tekeminen on helpompaa ja nopeampaa ( edullisempaa). Käyttöliittymäkuvaus konkretisoi vaatimusmäärittelyä. Vaatimukset voidaan saada selville riittävän täsmällisesti jo projektin alkuvaiheessa.

Cheesman&Daniels + GUIDe Menetelmäpilotoinnin taustalla on malli komponenttipohjaisesta sovellustuotantoprosessista, josta voi karkeasti erottaa erilaisia vaiheita. Nyt, eli Halla-vaiheessa, ollaan siinä tilanteessa, että yhden käyttötapauksen näkökulmasta on tehty vaatimusmärittelyt, komponentti- ja arkkitehtuurimäärittelyt, käyttöliittymäproto, tietokantaratkaisut ja tietysti valittu toteutustekniikat ja rakennettu kehitysympäristö. Ensimmäiset määrittelyt ovat nyt toteutettavana. Vaikka näkökulma on ollut yhdessä käyttötapauksessa, tuotoksia on samalla syntynyt paljon koko sovellusta varten, esim. vaatimuksia, komponentteja, tietokantarakenne, käyttöliittymäsuunnittelua (Tätä ei ? Mallissa korostetaan uudelleenkäytön lisäksi komponenttien välisten riippuvuuksien hallintaa, mikä toteutuu komponentin vaihdettavuuden ja korvattavuuden kautta. Ylläpidon kannalta korvattavuus tarkoittaa sitä, että tarjotun liittymän toteutus voidaan vaihtaa vaikuttamatta siihen, miten samaa liittymää aiemmin käyttäneet ohjelmistot suorittavat liittymän kutsumisen. Siten mallissa painopiste on arkkitehtuurissa, jossa komponenttien väliset riippuvuudet ja yhteydet määritellään rajapintatasolla ) Eri vaiheisiin sisältyy paljon erilaisia tehtäviä, joita voidaan hoitaa monella tavalla: joko ad hoc:ina ilman ihmeempää suunnittelua, tai sitten siltä pohjalta miten aina ennekin on tehty tai sitten voidaan soveltaa joitakin tutkittuja menetelmiä, joiden kehittäjät jostain kumman syystä uskoo, että niitä kun noudatatte, saatte aikaan asiakkaiden ylistämiä tuotteita nopeasti, helposti ja ennen kaikkea tuottavasti. Pakkasessa on siis valittu tämä jälkimmäinen vaihtoehto, ja sovellettavana on paljon erilaisia menetelmiä, ja mistä tuntuu puuttuvan, niin tilataan. Menetemiä: vaatimusmäärittely: V1 Kotihoitotiimi, jossa kehitetään kevyttä vaatimusmäärittelymenetelmää komponenttien määrittely: Cheesman&Daniels – yksinkertainen prosessi komponenttipohjaisen sovelluksen määrittelyyn suunnitteluun, tekniikkaan ja toteutukseen liittyvät asiat – FixIT-DoIT-osaprojekti: teknisten ratkaisujen arviointi tekninen suunnittelu (mäppäys toteutustekniikoihin, tietokantaratkaisut, jne.) käyttöliittymäsuunnittelu arkkitehtuurisuunnittelu laadunvarmistus: tarkastus- ja testausmenetelmä Teho-osaprojektista dokumentointi: FixIT-DoIT projektinhallinta: FixIT-DoIT Käyttöliittymäsuunnittelun vaikutus prosessiin – käytettävyysnäkökulma (vihreä)

V-prosessimalli Asiakkaat Testitapausten suoritus, testauksen toteutus Testausryhmä Testitapausten suoritus, testauksen toteutus Testauksen ja testitapausten suunnittelu Kehittäjät Yksittäiset kehittäjät Testauksen tasot

V-prosessimalli Laadunvarmistuksen näkökulmat: todennus (verifiointi): arviointi, että tuote tehdään oikein kelpuutus (validointi): arviointi, että tehdään oikea tuote testaus: ohjelmiston suoritus edellisten kohtien todentamiseksi. Sovelluksen testaus huomioidaan projektissa alusta asti. Testaus perustuu määrittelyihin l. testaussunnitelma ja testitapaukset laaditaan etukäteen ennen toteutusta. määrittelyjen katselmointi ja testaus Virheitä löytyy aikaisessa vaiheessa, jolloin niiden korjaaminen on helpompaa ja edullisempaa. V-mallin idea sopii hyvin komponenttien ja komponenttipohjaisen sovelluksen testausprosessiksi. Tavoite: estää virheiden pääsy tuotteeseen sekä varmistaa, että ohjelmistos täyttää sille asetetut vaatimukset = laadunvarmistus.

Cheesman&Daniels + GUIDe + V-malli Testauksen vaikutus prosessiin (lila)

Sovelluskehitysprosessi Käytettävyys Laadunvarmistus (Turvallisuus) (Ohjausprosessi) Vaiheet eli portaat: (Sovelluksen ylläpito) (Sovelluksen käyttöönotto) Sovelluksen testaus Sovelluksen koostaminen Komponenttien toteutus (osa hankintaprosessia) Määrittely ja suunnittelu Käyttöliittymäsuunnittelu Toimintalähtöinen vaatimusmäärittely

Laadunvarmistus Pakkasessa: Testaus ja tarkastus Testaus huomioitu koko prosessissa. Sovellettavien menetelmien tuki testitapausten määrittelyssä ja testauksen toteutuksessa: tuotokset tukevat testausprosessia. Tarkastuksessa kokeiltu formaalia tarkastusmenettelyä: löytyy virheet tekijät joutuvat miettimään perusteluja tarkemmin rajoittuu dokumentteihin (tosin voisi olla sovellettavissa myös muihin tuotoksiin) menettelyyn osallistujien on hyvä tietää perusasiat tarkastuksen kohteesta (esim. komponenttimäärittely) valmistautuminen vie aikaa  Tarkastukset toteutettu erilaisin läpikäynnein, esimerkiksi: dokumenteille kommentointia ja katselmointeja käyttöliittymänäyttöjen läpikäynti käyttäjän kanssa.

Turvallisuus Erilaisia näkökulmia: Tietosuoja, esim. sovelluksen ja tietojen käyttöoikeudet sisäänkirjautumismekanismit tietojen luokittelu ja suojaus Tietojen virheettömyys eheys (oikellisuus, ristiriidattomuus = sallittu tila) syöttötietojen oikeellisuuden tarkistus Sovelluksen oikea toiminta sovelluslogiikka Sovelluksen turvallinen toiminta toipuminen virhetilanteista (esim. sähkökatkot, levyrikot) Tiedonsiirto salausmekanismit Valvonta lokit

Ohjausprosessi Toimintatavat, jotka sovitaan yhteisesti organisaatiotasolla, ei tarvitse luoda uudelleen jokaisessa projektissa. Projektin hallinta: esim. suunnittelu, toteutus, seuranta, riskienhallinta, resurssien hallinta. Tuotteen ja tuotosten hallinta: Konfiguraation ja muutosten hallinta: esim. ryhmätyöntuki ja versiointi sekä tuotteen että erilaisten projektin aikana tuotettavien artefaktien osalta. Vaatimustenhallinta Dokumentointi ja dokumenttien hallinta Komponenttien hankinta- ja hallintaprosessi Uudelleenkäytön tasot jne.  osittain päällekkäisiä ja toisiinsa lomittuvia asioita (lisää kaiteita tikapuihin).

Lisätietoa Pakkasessa syntyvää materiaalia on osapuolten saatavana: Yhteyshenkilöille – tuotokset - menetelmät – sovellustuotannon ja integraation yleiset menetelmät – esimerkit Http://www.uku.fi/plugit/yhteys/pakkanen Kirsi Karvinen: Kirsi.Karvinen@uku.fi Annamari Riekkinen: Annamari.Riekkinen@uku.fi Lähteet: Cheesman John; Daniels John. UML Components: A Simple Process for Specifying Component-Based Software. Szyperski (toim.) Component Software Series. 1.painos. Addison-Wesley, Boston, 2001. Laakso,Sari. Hyvän käyttöliittymän varmistaminen GUIDe-projektimallilla. Helsingin yliopisto, tietojenkäsitetlytieteen laitos. Saatavana: <URL: http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe-suomeksi.html>,viitattu 24.3.2004.

Kiitos! Pakkanen