Pakkanen * * * S ovellustuotannon menetelmäpilotti

1. 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ö

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

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

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

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

6. 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?

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

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

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

10. Pakkanen keskeisten näkökulmien valossa

11. (Turvallisuus) (Ohjausprosessi) Käytettävyys Laadunvarmistus Vaikutteet ja näkökulmat • 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

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

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

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

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

16. (Turvallisuus) (Ohjausprosessi) Käytettävyys Laadunvarmistus Pakkasen tulokset • 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

17. 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).

18. 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).

19. Pakkanen: teoreettinen tausta, käsitteitä

20. 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).

21. 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ö.

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

23. Cheesman&Daniels: komponenttipohjainen sovellustuotantoprosessi Pakkasessa sovellettu perusprosessi

24. Cheesman&Danielssovellustuotantoprosessi • 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.

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

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

27. Cheesman&Daniels + GUIDe • Käyttöliittymäsuunnittelun vaikutus prosessiin – käytettävyysnäkökulma (vihreä)

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

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

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

31. (Turvallisuus) (Ohjausprosessi) Käytettävyys Laadunvarmistus Sovelluskehitysprosessi 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

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

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

34. 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).

35. Lisätietoa Pakkasessa syntyvää materiaalia on osapuoltensaatavana: • 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.

36. Kiitos! Pakkanen