Pakkanen * * * Sovellustuotannon menetelmäpilotti Toimintalähtöinen vaatimusmäärittely PlugIT-seminaari B-työpaja __________________________________________________________ Annamari Riekkinen ja Kirsi Karvinen PlugIT Kuopion yliopisto / Tietotekniikkakeskus /HIS-tutkimusyksikkö

Sisältö Case Pakkanen: toiminnan teoriaan perustuvan työtoiminnan mallin soveltaminen palvelutoimintaa tukevan sovelluksen (sovellusosan) vaatimusmäärittelyssä. Pakkasen lyhyt esittely: pilottikohde, tausta, tehtävät, vaiheistus. Perustelut toimintalähtöiselle vaatimusmäärittelylle (lähtökohta ja tavoitteet) Vaatimusmäärittely Pakkasen 1. vaiheessa vaiheittain Vaatimusmäärittely Pakkasen 2. vaiheessa vaiheittain Vaatimusmäärittelyn tulosten hyödyntäminen sovelluskehitysprosessissa Vaatimusmäärittely keskeisten tuotosten näkökulmasta Arviointia menetelmästä Miten tästä eteenpäin (tänään ja loppuprojektin aikana)

Pilottikohteen esittely 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ä. Toiminta: käyttäjätunnusten hallinta (mikä on osa palvelinkoneiden hallintaa, mikä puolestaan on osa Tietotekniikkakeskuksen tietopalvelutarjontaa jne.) Kohde: Olemassa oleva, Tietotekniikkakeskuksessa kehitetty käyttäjätunnusten ja sähköpostialiasten ylläpitoon tarkoitettu sovellus – Pakka (muutama käyttäjä, Fileman ja Delphi-FixÍT-tekniikat).

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ä.  tehtävä arvioida kuinka kattavia johtopäätöksiä voidaan tehdä eri tekniikoista ja menetelmistä (päätöksenteon tuki).  tehtävä koota kokemusten pohjalta kevyet toimintatavat, jossa eri tehtäväkokonaisuudet tukevat toisiaan prosessissa.

Vaikutteet ja näkökulmat menetelmäkehityksessä 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

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

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

Pakkanen: toimintalähtöinen vaatimusmäärittely

Lähtökohtia vaatimusmäärittelylle Komponenttipohjaisen sovellustuotannon keskeinen periaate: toimintaprosesseista tunnistetaan sovelluksen komponentit (mm. Cheesman&Daniels, Kähkipuro, Mykkänen). Näkemys siitä, että on melko mahdotonta saada aikaan toimintaa tukeva sovellus, jos toimintaa ei ymmärrä. Toimintakokonaisuuden kuvaamiseen perustuva toimintalähtöinen menetelmäkehitys oli alkanut kotihoitotiimissä  asiantuntemus lähellä. Käytettävissä oli toiminnan kokoamiseen ja jäsentämiseen tarkoitettu työtoiminnan malli sekä sen rakennettava noudattava haastattelulomake.

Tavoitteet vaatimusmäärittelylle Tavoitteena ymmärtää toimintaa, jota sovellus tukee. Miten tämä onnistuu? Kehitystiimin täytyy muodostaa käsitys toiminnasta kokonaisuutena. tunnistaa mahdolliset vaatimukset ja kehittämiskohteet toiminnan tasolla (organisaationäkökulma). tunnistaa ja ymmärtää käyttäjän käyttötavoitteet sovellustasolla (käyttäjänäkökulma). Nykyinen sovellus auttaa ymmärtämään, miten tällä hetkellä toimitaan. Komponenttien ja arkkitehtuurin määrittelyyn oli valittu menetelmä, jonka kannalta keskeisiä vaatimusmäärittelyssä tuotettavia dokumentteja ovat käsitemalli – kuvaustapa UML-luokkakaavio käyttötapaukset – kuvaustapa UML-käyttötapauskuvaus.

Toimintalähtöinen vaatimusmäärittely – case Pakkanen Miten vaatimusmäärittelyprosessissa saadaan tuotettua käyttötapauskuvaus (toimintalähtöisesti)? Miten vaatimusmäärittelyprosessissa saadaan tuotettua käsitemalli sovelluksen kohdealueen keskeisimmistä käsitteistä? Toimintalähtöinen vaatimusmäärittelymenetelmä Pakkasessa: Jäsentämis-, kuvaamis- ja ajatusmalli (väline): työtoiminnan malli Tiedonhankinnan menetelmät: nykyinen sovellus, teemahaastattelut, käyttäjän havainnointi, läpikäynnit, ”ei-formaalit” kommunikointikeinot: keskustelut, sähköposti jne. Analysointivälineet: nykyisen sovelluksen tekninen dokumentaatio (ja itse sovellus), eri tasolla kuvatut prosessikaaviot, toimintatarinat, ym. Tulokset: (tavoitepohjaiset) käyttötapauskuvaukset, käsite- tai tietomalli, tuotettavan sovelluksen sanallinen kuvaus ja työtoiminnan malli tavoitetilanteessa.

Miten vaatimusmäärittely eteni 1. vaiheessa Tehtävät: Työtoiminnan mallin käyttöönotto Tunnistettujen käsitteiden kokoaminen työtoiminnan malliin Nykyiseen sovellukseen tutustuminen Sovelluksen ja siihen liittyvän dokumentaation läpikäynti Teemahaastattelut Haastatteluihin valmistautuminen Haastattelut (2 kpl) Haastatteluiden purku Tulosten ja kuvausten kokoaminen kuvaus sovelluksesta käsitemalli käyttötapaus  vaatimusmäärittelydokumentti ja käyttöliittymänäytöt

Miten vaatimusmäärittely eteni 2 Miten vaatimusmäärittely eteni 2. vaiheessa (kokoaminen osittain vielä kesken) Pakkanen Toimintaprosessien määrittely organisaatiotasolla Teemahaastattelut Nykyisen sovelluksen käyttötavan selvittäminen (käytettävyysnäkökulman mukaantulo vaatimusten määrittelyprosessiin) Asiantuntijaläpikäynti, käyttäjän havainnointi Tulosten kokoaminen ja dokumenttien päivittäminen käyttötapaukset käyttötarinoina (san. kuvaus+ kaavio) käytettävyysanalyysi sanallisen kuvauksen ja käsitemallin päivitys työtoiminnan mallin päivitys (toiminto-, tieto-, ja käyttäjäryhmäanalyysi)

Vaatimusmäärittelyn tulokset sovellusprosessille Toimintakokonaisuuden kuvaus (työtoiminnan malli): Kartta (muistilista) toimintaan liittyvistä tekijöistä, jota sovellusprosessin eri toimijat voivat hyödyntää työssään. Sovelluksen kuvaus: kaikille (tarkoitus, ympäristö, toiminnot, käyttäjäryhmät, keskeisimmät säännöt). Käyttötarinat: käyttöliittymän suunnitteluun, komponenttien ja sovelluksen arkkitehtuurin suunnitteluun, sovelluksen koostamiseen? testitapausten suunnitteluun, käyttöohjeen laadintaan… Käsitemalli: komponenttien ja sovelluksen arkkitehtuurin suunnitteluun sekä sovelluksen tietosisällön suunnitteluun. Käyttöliittymän käytettävyysanalyysi: käyttöliittymäsuunnittelu

Vaatimusmäärittely Käyttötapausten osalta Pakkanen Käyttötapausten osalta Vaatimusmäärittelyn keskeinen tulos koko sovelluskehitysprosessin kannalta Käyttötapauskuvauksista tavoitepohjaisiin käyttötapauksiin

Vaatimusmäärittely UML- Käyttötapauskuvaus Käyttötapauskuvauksen laadinta Pakkasen 1.iteraatiossa: käyttäjän ja sovelluksen välinen vuorovaikutus

Käyttötapauskuvaus Nykyisestä Pakka-sovelluksesta toiminnot (luettelo toiminnoista ja niiden ryhmittely). Toteutettavaksi valittiin käyttötapaus ”Käyttäjätunnuksen luonti”. Pääasiassa nykyistä sovellusta tutkimalla kuvaukseen sisällytettiin toiminnot: 1. tunnista käyttäjä – 2. luo henkilökohtainen käyttäjätunnus – 3. liitä tunnus palvelinkoneeseen (palvelinkone, käyttäjäryhmä ja palvelinkoneen numeerinen käyttäjätunnus). Käyttäjältä varmistettiin käyttötapauksen ”oikeellisuus”.

Käyttötapauskuvaus Notaatio: UML-käyttötapauskuvaus 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. Varaa asiakkaalle käyttäjätunnus ja tallenna hyväksytty käyttäjätunnus. Liitä käyttäjätunnus palvelinkoneeseen. Lisää asiakkaalle palvelinkonekohtaiset käyttäjäryhmät ja tallenna tiedot. Poikkeustapaukset ja laajennukset: Järjestelmä ei löydä asiakkaan henkilötietoja… Asiakkaalla on jo olemassa oleva käyttäjätunnus… Järjestelmään on jo tallennettu pääkäyttäjän syöttämät tiedot… Pääkäyttäjä on unohtanut syöttää jonkin pakollisen (tähdellä * merkityn) tiedon…

Käyttötapauskuvaus Käyttötapauskuvaukseen liitettiin vaatimuksia nykyisen sovelluksen ominaisuuksien perusteella, mm: Hakukriteerit asiakkaan valintaan henkilötiedostosta: pelkkä sukunimi tai sukunimi ja etunimi tai syntymäaika tai osa jostakin em. hakukriteeristä Asiakkaan käyttäjätunnus joko generoidaan kaavan perusteella tai lisätään järjestelmään käsin Asiakkaan käyttäjätunnus voidaan liittää useaan palvelinkoneeseen Asiakkaan käyttäjätunnukseen voidaan liittää useita käyttäjäryhmiä samassa palvelinkoneessa.  komponentti- ja arkkitehtuurivaiheeseen.

Käyttötapauskuvauksen arviointi Käyttäjän ja sovelluksen välinen vuorovaikutus: nykyisen sovelluksen toiminnot saadaan siirrettyä nopeasti uuteen sovellukseen (hyvien suunnittelu-ratkaisujen uudelleenkäyttö). Mutta… ei ole toimintalähtöinen lähestymistapa kehittämiskohteita ei ehkä huomata riittävän laajasti. Tarkastelussa yksi taso ylöspäin: ajatellaan käyttäjätunnuksen luonti käyttäjän tavoitteellisena työtehtävänä.

Toimintalähtöinen vaatimusmäärittely Pakkanen Toimintatarinoista käyttötarinoihin Käyttötapauskuvausten laadinta Pakkasen 2.iteraatiossa: käyttäjän toiminta tavoitteellisen tehtävän suorittamisessa (käyttäjä(ryhmä)näkökulma)

Toimintatarinoista käyttötarinoihin Pakkanen Toimintatarina: vapaamuotoinen kertomus, joka kuvaa käyttäjän nykyisen toiminnan (toimintatavat) yhden tavoitteellisen tehtävän suorittamiseksi. Käyttötarina: vapaamuotoinen kertomus, joka kuvaa käyttäjän tulevan toiminnan (toimintatavat) yhden tavoitteellisen tehtävän suorittamiseksi. Sovellus on osana toimintaa (nykyinen ja kehitettävä). Aikaperspektiivi tarkastelussa: nykyinen toiminta – kehittämiskohteet –tavoitetoiminta.

Toimintatarinoista… Pakkanen Nykyiseen sovellukseen tutustuminen asiantuntijaläpikäynnein: käyttöliittymän vapaamuotoinen arviointi (toiminnot, käytettävyys). käyttöliittymän arviointi erilaisia heuristiikkoja hyväksikäyttäen (tarkistuslistoja yleisistä suunnitteluperiaatteista). Kehitystiimissä oli muodostunut käsitys toiminnasta, joten toimintatarinoita laadittiin toimintatarinakuvauksia käyttötapauskaavionotaatiolla. Varsinainen tiedonhankinta toteutettiin havainnoimalla käyttäjän toimintaa työympäristössään: kaksi tavoitteellista tehtävää: tunnuksen perustaminen ja muuttaminen (peruste: tehtävän tiheys ja toimintojen kattavuus) opettaja-oppilas –menetelmä; havainnoinnin kohdistuminen käytettävyyteen, toiminnan etenemiseen.

… käyttötarinoihin Havainnointitilaisuuden jälkeen kehitystiimissä Pakkanen Havainnointitilaisuuden jälkeen kehitystiimissä arvioitiin tilaisuuden onnistuminen analysoitiin havainnoinnin tuloksia. Aivoriihen ja muistinpanojen pohjalta molemmat tehtävät (tunnuksen perustaminen ja muuttaminen) kirjoitettiin auki toimintatarinoiksi, joihin liitettiin myös kehittämisideat. Toimintatarinoista johdettiin käyttötarinat siten, että kehittämisideat sisällytettiin kuvauksiin. Käytettävyyteen liittyvät havainnot lisättiin (käyttöliittymän) käytettävyysanalyysiin.

Arviointi Käyttäjä(ryhmä)näkökulma: käyttäjätunnuksen perustaminen Käyttäjän toiminta tehtävän suorittamisessa: Sanalliset kertomukset voivat mennä (liian) tarkalle tasolle olla työläitä työstää ja hankala lukea  kuvataan toiminta esim. prosessikaaviona tai yhdistelmänä. Nykyinen toiminta  kehittämiskohteet: tarkastuksissa sovelluksia, luetteloita tavoite: tiedot näkyviin sovelluksessa tietojen täydennys lomakkeeseen tavoite: tietojen tulostus sovelluksesta Tavoitetoiminta: kehittämiskohteet sisällytettynä kuvauksiin.

Tavoitepohjaiset käyttötapaukset Tarvitaan malli käyttötapausten kuvaamiseen vrt. työtoiminnan malli toiminnan ja toimintakokonaisuuden kuvaamiseen. Työtoiminnan mallin ja käyttötapauskuvauksen yhteys kuvaustaso, prosessikaavio (symbolit). Ensimmäinen ajatus tavoitepohjaisen käyttötapauksen malliksi: Tavoite: Toimija: Tilatiedot: - tietoa tiedosta - toiminnan sääntöjä - vaiheet ym.

Toimintalähtöinen vaatimusmäärittely Käyttäjänäkökulma Organisaationäkökulma Toimintaprosessikuvaukset Tapahtumat ja toiminnat, joilla on vaikutusta tarkasteltavana olevaan toimintaan (organisaationäkökulma).

Toimintaprosessit Organisaationäkökulma: toimintoja ja tapahtumia, joilla on vaikutusta tarkasteltavana olevaan toimintaan ja joihin tavallisesti osallistuu useita toimijoita. Toimintakokonaisuutta selvitettäessä haastatteluiden purkamisen yhteydessä toiminnasta löytyi tarkennettavia asioita, mm: ongelmia tietojen ajantasaisuudessa (kaikki tiedot eivät tule sovelluksen käyttäjille). otettu vasta käyttöön kokonaan uusi toimintaprosessi: uusien opiskelijoiden käyttäjätunnusten perustaminen. Syitä ja vaikutuksia haluttiin selvittää tarkemmin: miksi tiedot eivät ole ajan tasalla? onko uudessa toimintaprosessissa vaikutuksia järjestelmään? (menetelmäkehityksen näkökulma)

Toimintaprosessit Haastatteluiden analysoinnin pohjalta tutkittavaksi valittiin kolme (3) tapahtumaa ja yksi prosessi: 1. henkilö poistuu yliopistosta; 2. henkilö vaihtaa laitosta; 3. henkilö muuttaa nimeä uusien opiskelijoiden käyttäjätunnusten luonti. Tiedonhankinnan menetelmänä edelleen haastattelut (4 kpl) haastatteluiden purku prosessikaavioihin. Prosessikuvausten analysoinnin pohjalta ryhmittely toiminnan kehittämiseen, esim. syyt tiedonkulun ongelmiin  rajattiin pois Pakkasen tehtävistä, mutta on tunnistettu syyt, joiden pohjalta ratkaisujen miettiminen on helpompaa. sovelluksen vastuihin, esim. toiminta: “uusien opiskelijoiden tunnusten lisäys” on toteutettu sovellusten välisten liittymien avulla –> ei tarvita uusia käyttötapauksia uudistettavaan sovellukseen, mutta liittymät on huomioitava.  voitiin päättää toteutettavan sovelluksen rajat (toiminnallisuus = toteutettavat käyttötapaukset).

Arviointi Prosessikuvausten analysoinnin pohjalta vaikutuksia : toimintatapojen kehittäminen, esim. työnjako, tehtävien ohjeistus jne. käyttäjän toimintaan järjestelmien yhteistoimintaan välineisiin sekä kommunikoinnin ja yhteistoiminnan keinoihin kohdistuvat kehittämistoimet, esim. lomakkeet: sisältö, muoto;

Vaatimusmäärittely Käsitemalli Toiminnan käsitteet

Vaatimusmäärittely Käsitemallin kokoaminen ja täydentäminen samalla kun työtoiminnan mallia täydennetään: käsitemallinnuksen voi aloittaa analysoimalla nykyisen sovelluksen tietokantakuvausta (tai nykyistä sovellusta). jäljitettävyys: sovelluksen käsitteet – työtoiminnan mallin käsitteet käsitteitä täsmentävää tietoa löytyy prosessikuvauksista sekä toiminta- ja käyttötarinoista ( myöh. tavoitepohjaisista käyttötapauksista).

Menetelmän arviointia Jäsentämis- ja ajatusmalli: Yleiskuvan hahmottaminen käyttäjätunnusten hallinnasta toimintana. Tarkastelun kohdentaminen: Prosessit: työtehtävät, toimintaprosessit. Arkkitehtuuri (liittymät muihin järjestelmiin)  kehittämiskohteita, vaatimusten tarkennusta, tukee paremmin toimintaa. Sovelluksen kuvaus voidaan sijoittaa malliin. Kuvaamismalli: Eri tasot ja näkökulmat. Kuvaamistapojen yhtenäisyys ja havainnollisuus esim. prosessikuvaus: jäljitettävyys, symbolit.

Menetelmän arviointi Muita näkökulmia: Nykyisen sovelluksen tutkiminen on ollut tärkeä väline ymmärryksen muodostamisessa, mutta voi myös rajoittaa uusia ratkaisuja. Sudenkuoppa: toiminnan mallintaminen karkaa vähemmän tärkeille poluille: tarkastelutason ja ”määrän” oikea valinta tärkeää. Menetelmiä on mahdollisuus soveltaa eri tasolla riippuen siitä, kuinka hyvin toimintaa tunnetaan ennestään vai tunnetaanko juuri ollenkaan. Keskeisiä menestystekijöitä: Mahdollisuus kommunikoida käyttäjän ja vastuuhenkilön kanssa avoimesti. Sovellusprojektissa eri asiantuntijat (mm. vaatimukset, tekniikka, käyttöliittymä) osallistuvat vaatimusmäärittelyssä erilaisiin läpikäynteihin  ymmärryksen muodostuminen koko kehitystiimille.

Miten tästä eteenpäin – kevään aikana Vaatimusmäärittelyn tuotosdokumentaation hiominen: Kehitteillä ajatus tavoitepohjaisista käyttötapauksista: keskeinen dokumentti jatkoprosessin eri osapuolille (ainakin käyttöliittymän suunnittelijalle, sovellusarkkitehdille ja komponenttisuunnittelijalle, sovelluksen koostajalle, testauksen suunnittelijalle ja käyttöoppaan laatijalle). Käyttötapauskuvaukset ja käsitemalli edelleen sovelluskehitysprosessin jatkon kannalta keskeiset dokumenttityypit. Käytettyjen toimintatapojen analysointi sekä menetelmän arviointi suhteessa koko sovelluskehitysprosessiin. Menetelmäkuvaus: ”Keittokirjaresepti” menetelmän soveltamisesta ohjelmistokehitysprojektissa. Kuvaus menetelmäsalkkuun.

Miten tästä eteenpäin – iltapäivän aikana D - pajassa jatketaan sovelluksen suunnittelulla ja toteutuksella seuraavasti: Yhteenveto (kokonaiskuva) Pakkasessa läpikäydystä prosessista. Käyttöliittymäsuunnitteluprosessin läpikäynti + kl.demo. Sovelletun komponentti- ja arkkitehtuurisuunnittelumenetelmän läpikäynti. Palveluarkkitehtuurin siirto toteutustekniikoihin sekä tekniset ratkaisut demosovellusta läpikäymällä. Arviointi (tulosten yleistettävyys ym.) ja johtopäätökset.

Esimerkki: Toimintakokonaisuus työtoiminnan mallissa Kollektiivinen toimija: tahot, jotka tarvitsevat ajantasalla olevia tietoja (tietoisesti tai tietämättään) tai vastaavat niistä. Yhteistyötahot, yhteistoiminnan ja kommunikoinnin keinot: keinot ja välineet ajantasaisten tietojen varmistamiseen, tunnusten hallintaan liittyvät säännöt. Toimijat: sovelluksen käyttäjät  käyttäjäryhmät (oikeudet). Välineet: lomakkeet, järjestelmät jne. joita tarvitaan tietojen hallinnoinnissa. Tehtävät, prosessit: lisäys, muutos, poisto  prosessit, joissa näitä tehdään. Kohde: käyttäjätunnustiedot. Tavoite: ajantasaiset tiedot  esim. asiakkaalla on palvelut käytössä.

Esimerkki: Työtoiminnan mallin ja prosessikaavion yhteys Organisaationäkökulmaesimerkki: Henkilö tarvitsee käyttäjätunnuksen Toimijat: asiakas, tallentaja ja laitos Kommunikoinnin ja yhteistoiminnan keinot: lomake, henk.koht kanssakäyminen, posti Välineet: sovellukset (Pakka ja Otto), palvelinkone(et), kopiokone, käyttölupahakemus, kynä Prosessi: käyttäjätunnuksen luonti Kohde ja tavoite: saada henkilölle ajantasainen käyttäjätunnus, jonka avulla hän saa palvelut käyttöönsä.

Esimerkki: Työtoiminnan mallin ja toimintatarinakuvauksen yhteys Käyttäjä(ryhmä)näkökulma: käyttäjätunnuksen perustaminen Toimija Välineet Prosessi Kohde ja tavoite

Esimerkki: Työtoiminnan mallista UML-käsitemalliin Tiedonkäsittelyn näkökulma (helpottaa tietoanalyysiä): mistä käsitteistä tietoa tallennetaan mistä tieto saadaan ja mihin sitä tarvitaan Voidaan toteuttaa myös niin, että käsitemalliin otetaan tässä vaiheessa mukaan kaikki käsitteet  analysoidaan myöhemmin. UML-luokkakaavio: käsitteet ja niiden väliset suhteet

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

Kiitos! Pakkanen