#seminaarikannu

Ensimmäisenä Heikki Vesalainen Ixonoksesta kertoo vaatimusmäärittelystä ja vaatimusten hallinnasta.

Määritellään termejä. Yleisö huuteli asiaan liittyviä sanoja.

Vaatimusmäärittely:
Sopimus siitä, mitä tullaan tekemään, millainen järjestelmän tulisi olla.

Vaatimusten hallinta:
- Tunnetaan vaatimukset
- Luokitellaan vaatimukset (prioriteetti, tärkeys asiakkaalle; riskialttius, onnistumisen todennäköisyys; volatiliteetti, onko vaatimus väliaikainen (esim. ylimenokausi) vai pysyvä)
- Muutosten määrä ja toteutuksen vaihe

Muutoshallinta: vaatimukset muuttuvat spontaanisti, mutta kuka tahansa ei vie muutoksia vaatimustenhallintaan.

Laajuuden hallinta: mikä on "meidän tontillamme" ja mikä ei.

Vaatimusmäärittelyn "akseleita ja asteita". Mistä riippuu vaatimusmäärittely?

uusi softa <-> versio
systeemityömalli
koko
arkkitehtuuri
sopimustyyppi
kriittisyys
elinkaari
tuotteistuksen aste (myytävä vs. asiakaskohtainen)
sidosryhmien määrä/koko
softa vai integraatio
pyritäänkö kehittämään uutta liiketoimintaa
kuluttaja/yritystuote

(edit: yleisön huutelemia, esitelmöijän koostamia)

Vaatimusmäärittelyn teoriat riippuvat tekijän lähtökohdista.

Määritysprosessi
- sovellettava projektityypin mukaan
- nuolia ristiin rastiin

Visio
- ideat, lähtökohdat, reunaehdot

->
Määritysprosessi
-> ongelman ymmärtäminen, reunaehtojen kartoitus
-> ratkaisumallin määrittely
-> tietojärjestelmien vaatimusmäärittely

->
Määritys
-> ongelmakuvaus, ympäristö, reunaehdot
-> toimintaprosessit ja käyttötavat
-> toiminnalliset ja ei-toiminnalliset vaatimukset

Hyvä määritys, väittämiä

Sisällöltään
- testattava
- ymmärrettävä
- tarkka, yksiselitteinen
- oikea/virheetön
- kattava
- realistinen, ristiriidaton, toteutettavissa oleva
- jäljitettävissä
- kuvaa toiminnan, ei toteutusta

Muodoltaan
- helppo ylläpitää ja muokata
- helposti haettava ja ryhmiteltävä

(edit: powerpoint-slidesta kops)

Määrittely on joskus vaikeaa

• Määrittely voi vaatia toimintatapojen muuttamista, eritoten mikäli fyysinen toteutus -> ohjelma
• Kommunikointi
  
  • erilaisia osallistujia
  • itselle asiat ilmiselviä, termit eivät selviä kaikille
  • kysyminen vaatii osaamista ja rohkeutta
  - ristiriidat voivat jäädä piiloon

(ping @eholmila, listan muotoilu toimii hassusti vikassa kommentissa)

@mandrl Kiitokset rapoilusta. Heikki Vesalainen on nyt myös Qaikussa nimimerkillä @salainen.

hei mitä ootte mieltä cucumber-tyyppisestä määrittelystä?

@Ile, mulla olis näitä vielä pari, mutta en tiedä kannattaako niitä tänne postata. Joistakin oli kalvot tulossa saitille?

@mandrl Laita vaan kaikki, mitä sulta löytyy. Tykkään itse kompaktista Qaiku-koosteesta josta löytyy sitten enemmän matskua kalvoilla...

PS. Laitoin SOK:n esityksen jo tänne

oliko kenelläkään kokemusta cucumberista tai onko vastaavaa systeemiä muille ohjelmointikielille?

@pe3 BDD ja ATDD on kivoja akronyymejä ja sinänsä niille on paikka maailmassa. Valitettavasti niitä pitää tehdä alusta asti ja on hyvin vaikeaa lähteä rakentamaan laatua jälkikäteen. Noita työkaluja löytyy myös ainakin Pythonille ja olisko ollut C#:lle kans joku.

Ootappa tovi niin mää kaivan vähän lähteitäni.

Eli Cottleston Pie on joskus kirjoittanut aiheesta aika kivan katsauksen.

Tosin tuossa nyt puhutaan myös osittain keyword-driven testingistä, joka ei ole tekniikkana mitenkään uusi ja google näyttäis osaavan niillä sanoilla auttaa tiedon lähteille.

musta toi on vaan aika hieno idis, että kirjoitetaan speksiä määrämuotoisesti englanniksi ja siitä saadaan suoraan automatisoituja testejä - mikä ei tietenkään tarkoita, että kaikki testaaminen oli siinä. lähinä ajattelutapa ja prosessi viehättää. ja että ehkä saadaan testit laajemminkin ymmärrettävään muotoon. en oo itte vielä kokeillut. mutta tarkoitus on.

@pe3 Oikeastaan voit katsoa mitä mä olen keräillyt mun deliin TDD:stä ja BDD:stä. Noissa sivutaan vähän sitä A:ta ja K:ta kanssa. Lisäksi alan kuhiseva buzzword on toki Robot Framework joka on tehty maaaaaailman parhaassa Reaktorissa.

@pe3 Sä kun olet tuommonen kauempaa lähestyvän tyyppinen niin suosittelen kokeilemaan esimerkiksi nosea ja sitten vasta pyspeciä, jolloin sotket samalla reissulla vähän omia ympyröitäsi.

Onko kukaan koskaan miettinyt, miksi Data-Driven Testingistä ole koskaan syntynyt hypetettyä akronyymiä DDT? ;)

@ferrix Olen nähnyt vakuuttavan demon Robot Frameworkista. Se herätti myös muutaman ajatuksen, mitä sen ympärille voisi rakentaa, jotta se tukisi kehitystyön arkea.

Tekisi mieli käynnistellä avoin kehittämisprojekti sen ympärille, jos kiinnostusta löytyy. Speksattaisiin yhdessä, miten se kannattaa ottaa käyttöön, minkälaisia konffeja kannattaa rakentaa, minkälaista oheissoftaa/skriptejä se voisi tarvita -- Ja sitten tehdään ja jaetaan kokemuksia.

@ferrix: kiitti vinkeistä - kattelin robbot slidejä. se tosiaan näyttää mielenkiintoiselta. samantapainen (taulukkomuotoon) ei-ohjelmoijaluettavien automaattitestien kirjoittaminen mahdollista kuin cucumberissa, jos oikein tulkitsen.

robotin testaaminen kiinnostaa, mutta musta tuskin olis hirveesti apua. voisikohan sitä kokeilla suomen datakatalogi ohjelmatyön puitteissa, jos se toteutuu?