Toiminta-arkkitehtuuri

Järjestelmän eri osa-alueisiin liittyvät toiminnot kuvataan käyttäjätarinoiden avulla. Käyttäjätarina on yksi selkeä toiminnallinen vaatimus, mitä järjestelmän on tuettava. Käytännössä käyttäjätarina kuvaa yksittäisen toiminnallisuuden käyttäjän näkökulmasta.

Käyttäjätarina: Palauttavana virkailijana haluan palauttaa kappaleen sen tunnisteen avulla käyttäen tunnisteen lukemiseen tarkoitettua laitetta.

Käyttäjätarinoiden tarkoitus:

  1. Vaatimusmäärittelijän kannalta tarina paljastaa asiakkaan jonkin tarpeen (miksi tullaan tekemään?)
  2. Ohjelmoijan kannalta tarina erottaa kokonaisuudesta priorisoidun osion, jota voidaan toteuttaa ja testata erillisenä (mitä tehdään seuraavaksi?)
  3. Asiakkaan kannalta tarina poimii kokonaisuudesta osion, jonka toiminnallisuutta asiakas osaa testata ja arvioida (onko tehty oikein?)

Käyttäjätarinat ryhmitellään teemoittaan eli samaan toimintoon liittyvät käyttäjätarinat ryhmitellään saman kokonaisuuden alle. Kokonaisuuden yhteyteen kirjataan siihen liittyvät esiehdot sekä sekä lyhyt kuvaus tyypillisen käyttötapauksen kulusta. Lisäksi listataan mahdolliset poikkeustilanteet. Sopivia kokonaisuuksia ovat esimerkiksi fyysisen aineiston lainaus, fyysisen aineiston palautus ja asiakkaan tunnistaminen. Jokaisen kokonaisuuden yhteydessä pidetään lisäksi kirjaa kokonaisuuden versio-historiasta, johon kirjataan tiedot kokonaisuuteen kohdistuneista katselmuksista sekä niiden hyväksymisestä/hylkäämisestä.

Yksittäiset käyttäjätarinat pyritään pitämään lyhyinä. Niistä tulee käydä ilmi kuka tekee (aktori), mitä tehdään ja mitä lisäarvoa se tuottaa aktorille, jos se ei muuten ole ilmeistä. Järjestelmällä on useita eri käyttäjäryhmiä, joten tarinoista tulee käydä ilmi aktorin rooli. Mahdollisisa rooleja ovat esimerkiksi asiakas, itsepalveluasiakas, palauttava virkailija, lainaava virkailija, virkailija ja kirjaston IT-vastaava. Eri rooleihin liittyvät käyttäjätarinat ryhmitellään omien otsikoidensa alle. Jokaisen käyttäjätarinan yhteyteen kirjataan lisäksi yksi tai useampia testejä, joiden tarkoituksena on kuvata kuinka käyttäjätarinan toteutuminen voidaan todentaa valmiissa järjestelmässä. Testejä ei kuitenkaan kirjoiteta ennen käyttäjätarinoiden hyväksymistä.

Käyttäjätarina: Palauttavana virkailijana haluan palauttaa kappaleen sen tunnisteen avulla käyttäen tunnisteen lukemiseen tarkoitettua laitetta.

Testit:

  • järjestelmä tunnistaa kappaleen viivakoodilla, joka sisältää kappaleen tunnisteen
  • virkailija voi lukea viivakoodin viivakoodinlukijalla
  • järjestelmä tunnistaa kappaleen RFID -tunnisteella, joka sisältää kappaleen tunnisteen

Katselmointiprosessin kulku:

  1. Katselmointiin osallistuvat ovat tutustuneet katselmoitavaan aineistoon ja kirjanneet kommenttinsa. Jos näin ei ole, katselmointi siirretään myöhempään ajankohtaan.
  2. Katselmoitavan kokonaisuuden määrittelijä toimii kommenttien kirjaajana, eikä saa osallistua keskusteluun.
  3. Aluksi kerätään kokonaisuutta koskevat kommentit.
  4. Yksi osallistujista lukee ääneen tarinan kerrallaan, minkä jälkeen muut ilmoittavat siihen liittyvät kommenttinsa.
  5. Lopuksi määrittelijä voi pyytää kokonaisuuden hyväksymistä tai sovitaan uusi katselmointiaika.
  6. Jos määrittelijän hyväksymispyyntöön ei vielä suostuta, neuvotellaan jatkotoimenpiteistä yhdessä.

Käyttäjätarinat katselmoidaan ensin projektiryhmän ja niiden työstämiseen mahdollisesti osallistuneiden Kansalliskirjaston asiantuntijoiden kesken. Katselmointi suoritetaan aina siten, että samaan kokonaisuuteen liittyvät käyttäjätarinat katselmoidaan yhdellä kertaa. Kun tarinat ovat läpäisseet projektiryhmän katselmoinnin, esitellään ne kirjastokentän asiantuntijoista koostuville asiantuntijaryhmille, jotka voivat esittää lisäys-, korjaus- ja muutosehdotuksia. Kokonaisuus katsotaan hyväksytyksi asiantuntijaryhmän suorittaman hyväksytyn katselmoinnin jälkeen. Tämän jälkeen käyttäjätarinoihin lisätään testit yhteistyössä asiantuntijaryhmän kanssa.

Jatkotoimenpiteen katselmoidulle kokonaisuudelle:

  1. Vaatimusmäärittelijä siirtyy hiomaan tarinoita yhdessä asiakkaiden/asiantuntijoiden kanssa
  2. Tarinoihin lisätään hyväksymistestit, jotka toteutuksen riittää läpäistä
  3. Tarinoiden hyväksymistestit katselmoidaan ja hyväksytetään
  4. Tarinoihin lisätään niiden kannalta keskeiset laatuvaatimukset huomioineen
  5. Tarinat riskianalysoidaan ja analyysit liitetään tarinoihin
  6. Asiakas priorisoi tarinat ja hyväksyy kokonaisuuden määritellyksi
  7. Määrittelyjä modifioidaan tarpeen mukaan muun määrittelytyön (arkkitehtuurirajapinnat ja tietokannat) edetessä

Käyttäjätarinoiden teko toteutetaan esimerkkipohjaa käyttäen. Tarinoissa käytetyt termit ja käsitteet lisätään järjestelmän sanastoon.

  • No labels