Millaista määrittelijän työ on käytännössä? Pitääkö olla osaamista varsinaisesta koodaamisesta? Tiedän kyllä mitä määrittelyvaihe ohjelmistoprojektissa sinänsä on, mutta se käytäntö?
Kyselläänkö palaverissa asiakkaalta että "ja mitäs sen ohjelman vielä pitäisi tehdä" , kirjoitetaan se johonkin janakaavioon ja sanotaan koodarille että tällainen tarvittaisiin?
Kyselläänkö palaverissa asiakkaalta että "ja mitäs sen ohjelman vielä pitäisi tehdä" , kirjoitetaan se johonkin janakaavioon ja sanotaan koodarille että tällainen tarvittaisiin?
Vastaukset 6
Vanhimmat
niin, unohda koko juttu.
"Pitääkö olla osaamista varsinaisesta koodaamisesta?"
Noh, opettelitko ensin kirjoittamaan ja lukemaan ja sitten vasta aakkoset?
Jos firmassa on asiat terveellä pohjalla niin määrittelijöillä on vuosien koodaus- ja tuotekokeus. Vaihtoehtoisesti erinomainen tuotetuntemus voi antaa edellytykset ilman koodauskokemusta...
Asiat eivät varmaan ole kovin hyvällä tolalla kaikissa firmoissa, jolloi määrittelemään päästetään ihmisiä joilla ei ole kunnollista toimiala, tuotekokemusta tai koodin kannalta mitään käsitystä asioista. Siitä ei ole kuin suunta alaspäin.
Eipä välttämättä tarvitse olla koodarin kokemusta joskaan siitä ei yleensä ole haittakaan.
Määrittelijälle tärkeätä on hahmottaaa ongelma ja löytää siihen ratkaisu ja se tärkein, tuottaa vaatimusmäärittely ratkaisusta.
Tuon perusteella SW- arkkitehdit häkkäävät kasaan SW arkkitehtuurin ja pistävät SW-suunnittelijat suunnittelemaan yksittäisten prosessien toteutuksen. Jotkut sitten vielä koodaavat tuon mutta se on käytännössä vähiten merkitsevä osa kokonaisuutta. Koko SW-puoli voidaan helposti hankkia ulkoa. Yleensä pidetään määrittelytyötä firman tärkeimpänä teknisenä kompetenssina koska siinä kiteytyy asiakkaan problematiikan ydinasiat.
Isoimmat tekniset virheetkin saa tietysti aikaan määrittelytyössä ja pienimmät koodauksessa.
Suosittelen omasta kokemuksesta määrittelytyötä.
Kiitos havainnollisesta vastauksesta! Jotenkin en kyllä vieläkään täysin ymmärrä miten määrittelijät saavat päivänsä kulumaan. Tarkoitan sitä, että eikö ne "asiakkaan ongelmat" ole yleensä suhteellisen simppeleitä, jos ei mennä detaljitasolle? Ja heti jos mennään, tulee eteen se että pitää tietää koodauksen tekniikat.
Jos asiakas osaa itse hyvin kuvata mitä haluaa, mitäs määrittelijä sitten tekee? Toimii kirjurina vai?
Usein määrittelyn ensivaiheena on use casejen työstäminen ja seuraavana vaatimusten kirjaaminen noiden pohjalta.
Esmerkiksi : Nelikkötaskulaskin
UC: Käyttäjä syöttää haluamansa numeerisen arvon ilman yksikköä näppäimillä. Tämän jälkeen hän syöttää halutun aritmeettisen operaation. Seuraavaksi hän syöttää operaatioon liittyvän toisen numeerisen arvon. Viimeiseksi käyttäjä painaa tiettyä painiketta käynnistääkseen laskentaprosessin. Tämän prosessin lopputuloksena näyttöön ilmaantuu aritmeettisen laskutoimituksen lopputulos.
Simppeliä eikö totta mutta avoimeksi jää mm.
1. miten numeerinen tieto syötetään sisään
2. mitä näytössä tapahtuu numeerisen syötön yhteydessä
3. onko numeerisill arvoilla jokin enimmäisarvo tai pituus
4. miten aritmeettinen operaatio valitaan
5. näytetäänkö ko. operaatio näytössä vai kuittaako laite sen jollain muulla tavoin
6. miten laskenta prosessi käynnistetään
7. missä muodossa numeeriset arvot syötetään (dec, hex, kanada :-)
8. missä muodossa numerot näytetään
9. miten toimitaan jos käyttäjä yrittää syöttää liian pitkää numeerista arvoa ja mitä tällöin näytetään
10. pitääkö laskentaprosessin arvoalueen ylitystä jotenkin tarkkailla
11. miten näytetään jos laskenna lopputulos on yli laksentaprosessin arvoalueen
jne..
Kun olet vastannut noihin kysymyksiin olet jo pitkällä määrittelyssä ja emmekä ole vielä lähelläkään pohtimassa toteutaanko tuo digitaalisella prosessorilla, analogisesti ja mekaanisesti. Se onnistuu muuten kaikilla tavoilla.
Tässä juuri tulee määrittelyn hienous. Se on oma maailmansa. Toiminnallisuutta kuvattaessa ei esitetä miten se tehdään, eikä sitä millä HW tai softa alsutalla se tullaan toteuttamaan.
Tietysti Hw- ja softa-alusta tulee myös määritellä vastaavalla tarkkuudella. Parhaiten sekin sujuu vaatimusten kautta, eli listataan ensin tarpeet. Niissäkään ei lähdetä liikkeelle cpusta muistista, vaan suorituskyvystä.
12. millä nopeudella numeerisia arvoja pitää voida syöttää (näppäilyvauhti)
12. millä vasteajalla näytön pitää seurata näppäilyjä
13. mikä on laskentaprosessin tavoite laskenta-aika
Viikon kun purkaa nelikkolaskimen toimintaa, toiminnalisuutta, kotelontia, käyttöliittymää (näyttä, näppäimet tms. syöttimet, näytön esitystavat) ym.. alkaa vaatimusspeksi noin yksinkertaiselle vemputtimelle olla nipussa.
Tämän tavan hienous piilee siinä, että asiakkaan kanssa päästään keskutelemaan kaikesta toiminnasta ilman, että aletaan puhua biteista ja strukteista.
Tällainen speksi on myös osa lopullista tuotteen tai sen osan tilaussopimusta. Muuten ei kumpikaan osapuoli voi olla varma mitä ollaan tilattu ja luvattu.
Softa arkkitehdit ym. speksaajat alkavat sitten tuon jälkeen kirjoittaa auki mitä toiminnallisuuksia tuon toteuttamiseen tarvitaan. Se taas on oma maailmansa ja siinä hyödynnetään usein samanlaista vaatimusmäärittelyä jotta saadaan tarkempi kuva siitä mitä minkäkin softafunktion pitää tehdä ja jotta rajapinnat näiden välillä voidaan suunnitella toteuttamaan kommunikointiin liittyvät vaatimukset.
Kun homma etenee, testaajat sitten verifoivat laitteen/softan toiminnan vaatimusmäärittelyä vasten. Jokainen poikkeavuus raportoivaan vikailmoituksella.
jne...
Itseasiassa puhdas softasuunnitteluja ja koodaminen edustaa n. 10-20% koko työmäärästä.
Testaaminenkin on erivaiheineen reilusti isompi kakku.
Eikös vaatimusmäärittelyä jo nykyään opeteta oppilaitoksissa?
Sehän on kaikkein tärkein taito softatyössä.
Oliko tämä täysin uutta asiaa vai tyrmäsikö muuten vain?