Pakkanen * * * S ovellustuotannon menetelmäpilotti Yhteenveto PlugIT-koulutustyöpaja 31.8.04 __________________________________________________________.

Esitys aiheesta: "Pakkanen * * * S ovellustuotannon menetelmäpilotti Yhteenveto PlugIT-koulutustyöpaja 31.8.04 __________________________________________________________."— Esityksen transkriptio:

1 Pakkanen * * * S ovellustuotannon menetelmäpilotti Yhteenveto PlugIT-koulutustyöpaja 31.8.04 __________________________________________________________ Annamari Riekkinen ja Kirsi Karvinen PlugIT Kuopion yliopisto / Tietotekniikkakeskus /HIS-tutkimusyksikkö

2 Esityksen sisältö Pakkanen: lähtökohdat ja projektin toteutus Keskeiset kokemukset ja tulokset Toimintalähtöisyys ja käyttöliittymäsuunnittelun rooli ohjelmistovaatimusten määrittelyssä Komponentti- ja arkkitehtuurimäärittely Suunnittelutulosten siirtäminen toteutukseen ja arviointia toteutuksen näkökulmasta (myös integrointiesimerkki) Testaus ja laadunvarmistus Yhteenveto

3 Lähtökohdat Nykyisiltä ohjelmistoilta ja ohjelmistokehitykseltä vaaditaan paremmin yhteen toimivia ja toimintaa kokonaisvaltaisemmin tukevia ratkaisuja. Hajautettujen järjestelmien kehittämiseen tarkoitetut komponentti- ja palvelupohjaiset tekniikat mahdollistavat tällaisten järjestelmien toteutuksen. Järjestelmien kehittämisen ja ylläpidon kannalta tarvitaan tietoa erilaisista komponentti- ja palvelupohjaiseen ohjelmistotuotantoon soveltuvista menetelmistä.  Komponenttipohjainen lähestymistapa  Teollisuusstandardeihin pohjautuvat tekniikat

4 Komponenttipohjainen lähestymistapa RUP:iin perustuva prosessimalli (C&D) Vaatimusmäärittely ActAD: toimintalähtöinen ajattelutapa Cheesman&Daniels: komponentti- ja arkkitehtuurimäärittelyä tukeva menetelmä Käyttöliittymäsuunnittelua painottava GUID-e projektimalli (toisessa vaiheessa) Komponentti- ja arkkitehtuurisuunnittelu Cheesman&Daniels: suoraviivainen, helposti käyttöönotettava ja ylläpitoa painottava menetelmä Testaus Ohjelmistotuotannon V-malli, jossa laadunvarmistus on huomioitu projektin alusta alkaen Toteutuksia J2EE/.NET –tekniikoilla Prosessin tuki, niin että valitut menetelmät tukevat siirtymistä vaiheesta toiseen.

5 Pilottikohde Yliopiston käyttäjätunnusten hallinnassa käytössä oleva Pakka-ohjelma, joka uusittiin tärkeimpien toimintojen osalta. Sopivan kokoinen erilaisten mentelmien kokeilemiseen.

6 Toteutus kahdessa osassa: 1 vaihe Opiskeltiin 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ä.

7 Toteutus kahdessa osassa: 2 vaihe Kohdealueen toiminnan syvällisempi tarkastelu käyttöliittymäsuunnittelun roolin korostumisen myötä. Komponenttimäärittelyä siten, 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ä toteutetuista komponenteista koostettiin sovellusosa käyttöliittymä- suunnittelun tuloksena saatujen näyttökuvien perusteella. Toisen vaiheen tavoitteena oli paketoida menetelmäkokemukset ohjelmistotoimittajien käyttöön.

8 Pakkanen: toimintalähtöinen vaatimusmäärittely ja käyttöliittymäsuunnittelu

9 Kokemuksia ja tuloksia Toiminnan tarkastelussa vaikeaa sopivan tason löytäminen liian suppea: ei nähdä kaikkia kehittämiskohteita liian laaja: tehdään turhaa työtä, mikä on kallista Tarkoituksenmukaisten dokumentointitapojen löytyminen työryhmän sisäisiin dokumentointikäytäntöihin ei kiinnitetty tarpeeksi huomiota Menestystekijöitä: mahdollisuus kommunikoida käyttäjän ja ylläpitäjän kanssa avoimesti sovellusprojektissa eri asiantuntijat (mm. vaatimukset, tekniikka, käyttöliittymä) osallistuvat vaatimusmäärittelyssä erilaisiin läpikäynteihin  ymmärryksen muodostuminen koko kehitystiimille.  vaatimukset tulevat määritellyksi oikein mahdollisimman aikaisessa vaiheessa.

10 Kokemuksia ja tuloksia Miksi toimintalähtöisyys? ymmärretään ohjelmiston todelliset vaatimukset mahdollisimman aikaisessa vaiheessa toiminnan ymmärtäminen on osaamisresurssi, jota voidaan hyödyntää myöhemminkin Käyttöliittymäsuunnittelu sijoitetaan ohjelmistoprojektin alkupäähän konkretisoi tuotettavan ohjelmiston projektin eri osapuolille suunnitelmaan on helpompi tehdä muutoksia kuin valmiiseen järjestelmään  säästyy aikaa ja kustannuksia Menetelmäluonnos ohjelmistovaatimusten toimintalähtöistä määrittelyä varten (tarkemmin: PlugIT selvityksiä ja raportteja 11)

11 Pakkanen: komponenttien ja ohjelmistoarkkitehtuurin määrittely

12 Käsitemalli Rajapintamäärittelyt Komponenttien määrittelyprosessi Käyttötapauskuvaus Komponentit ja arkkitehtuuri Vaatimusmäärittelyn syötteistä (käsitemalli ja käyttötapauskuvaukset) johdetaan arkkitehtuuri, komponentti- ja rajapintamäärittelyt.

13 Komponenttien ja arkkitehtuurin määrittely Prosessin periaate: Komponenttien tunnistus: rakenteellinen perusta komponenttiarkkitehtuuri komponentit ja rajapinnat liittymät muihin järjestelmiin ja ympäristöön Komponenttien vuorovaikutuksen määrittely: toiminnallisuus ja tiedot (logiikka) rajapintojen operaatiot määrittelyjen tarkennukset Komponenttien määrittely: dokumentointi komponenttiarkkitehtuurin viimeistely komponentti- ja rajapintamäärittelyiden viimeistely

14 Kokemukset ja tulokset Menetelmässä sovellettu UML-notaatio poikkeaa jonkin verran standardista UML:stä, mikä aiheutti väärinymmärrystä UML-asiantuntijoille.  käytettävä notaatio kaikkien tiedossa ja ymmärtämä Menetelmä on suoraviivainen, mutta kaiken kaikkiaan suunnitteluprosessi on inkrementaalista: määrittelyjä täsmennetään ottamalla huomioon erilaiset suunnittelunäkökulmat yksi kerrallaan. Käyttöliittymäsuunnitelman puuttuminen kokeilun 1.vaiheessa koettiin ongelmana: toiminnallisuuden määrittely oli hankalaa ilman konkreettista kuvaa siitä, kuinka ohjelmistoa käytetään.  helposti käytettävyys- ja sovelluslogiikkavirheitä

15 Kokemukset ja tulokset Käyttöliittymäsuunnitelman olemassa olo oikaisi ja nopeutti määrittelyprosessia jonkin verran.

16 Kokemukset ja tulokset Suunnittele tämän hetkistä tarvetta varten: Menetelmä tarjoaa arkkitehtuurimallin, joka perustuu kohdealueen ydintietoihin ja sallii muutokset suhteellisen vähällä vaivalla (rajapinta tai operaatiotaso).

17 Pakkanen: toteutus

18 Toteutus Tehtävänä oli sijoittaa suunnittelun tuloksena saatu komponenttiarkkitehtuuri toteutustekniikoihin: vaatimuksia toteutustekniikoille Cheesman&Danielsin teknisen suunnittelun näkökulmat Komponenttimäärittelystä saadut syötteet: 1. Arkkitehtuurikuvaus2. Komponenttien välinen vuorovaikutus 3. Rajapintamäärittelyt

19 Toteutettu arkkitehtuuri ja teknologiat SOAP/WSDL ASP.NET ( WebForms ) ICreateUser (Web Service)

20 Toteutuksessa käytetyt tekniikat = käyttöliittymä= toimintalogiikka

21 Kokemukset ja tulokset Suunnitteluarkkitehtuuri (tekniikkariippumaton): + järjestelmätaso tarjoaa eristekerroksen, mikä mahdollistaa molempien kerrosten (käyttöliittymä- ja toimintalogiikka) vaihdon + kerrosten komponenteilla ei ole keskinäisiä riippuvuuksia, mikä yksinkertaistaa komponenttien vaihdettavuutta. Vaihdettavuutta ja integroitavuutta kokeiltiin toteuttamalla Person-komponentti henkilötietojen hakuun tarkoitetun PlugIT- ydinrajapintamäärityksen mukaisesti. Palvelun käyttöönotto (eli liittyminen olemassa olevaan henkilö- tietojärjestelmään) oli helppoa.

22 Kokemukset ja tulokset Suunnitteluarkkitehtuuri (tekniikkariippumaton): - toteutusvälineiden näkökulmasta järjestelmäkerros on ylimääräinen kerros  lisää toteutuksen monimutkaisuutta (Menetelmän mukaan ei ole kuitenkaan pakko toteuttaa, ellei saavuteta hyötyjä). Tietokantarakenteen ja tietokannan sisältämien tietojen siirtämistä uuteen kantaan (eli migraatiota) testattiin toteutettavuusnäkökulmasta: onnistui valituilla välineillä, mutta edellytti rakenteen muuttumattomuutta ja sisälsi ylimääräisen vaiheen kahden teknologian yhteensopimattomuuden vuoksi.

23 Pakkanen: testaus

24 Kokemukset ja tulokset Kokeiltuja laadunvarmistustekniikoita: läpikäynnit tarkastusmenettely järjestelmä- ja hyväksymistestaus mustalaatikkona Testaukseen kiinnitettiin liian vähän huomiota (toteutuskokeilut eivät olleet riittäviä testauksen kannalta). Vähäisistä testauskokeiluista huolimatta testauksen suunnittelu alkoi jo vaatimusmäärittelyvaiheessa: korkean tason käyttötapauksista (käyttäjän työtehtävistä) johdettiin testitapaus, jossa simuloidaan käyttäjän todellista työtehtävää (tehtäväpolku). käyttöliittymänäyttöjen ja käyttäjän työtehtävien sanallisten kuvausten pohjalta suunniteltiin testitapaukset ohjelmiston oikeellisuuden päättelemiseksi. Määrittelydokumentoinnin puuteet huomattiin myös testauksen yhteydessä.

25 Kokemukset ja tulokset Läpikäynnit havaittiin hyväksi mentelmäksi virheiden havaitsemisessa. Läpikäyntejä voidaan tehdä erilaisille vaihetuotteille, kuten toimintaprosessikuvauksille, käyttöliittymäsuunnitelmalle, arkkitehtuurisuunnitelmalle, testitapauksille, ohjelmakoodille jne. Pienessa projektissa virallinen tarkastusmenettely koettiin hieman byrokraattiseksi, mutta se selkeytti dokumentointia. Kaiken kaikkiaan laadunvarmistus kokonaisuudessaan (katselmoinnit, läpikäynnit) ja testausprosessi kannattaa aloittaa heti vaatimusmäärittelyvaiheessa - vaiheessa tehtävä työ tukee myös testauksen suunnittelua.

26 Yhteenveto Hahmoteltiin polku vaatimusten määrittelystä arkkitehtuurisuunnittelun kautta toteutukseen niin, että ohjelmiston laadunvarmistus otetaan huomioon alusta asti  menetelmäkehitystyö jatkohankkeissa.

27 Lisää aiheesta PlugIT-hankkeen selvityksiä ja raportteja 13: Soveltamiskokemuksia ohjelmistotuotannon menetelmistä: vaatimusmäärittely, käyttöliittymäsuunnittelu, arkkitehtuurisuunnittelu, toteutus ja testaus PlugIT-hankkeen selvityksiä ja raportteja 11: Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä. Yhteystiedot: HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Annamari.Riekkinen@uku.fi

28 Kiitos!