Tutustutaan harjoitustyön aiheeseen Otupk viikolla 39 Luennot Spesifiointi UML-intro Viikkoharjoitukset Tutustutaan harjoitustyön aiheeseen Harjoitustyön asiakasvaatimusten selvittely Harjoitustyö harjoitustyöryhmät Idlessä viimeistään 25.9. pikakertaus 12.9.2009

Speksaamisesta (luku 3) Speksaamisesta yleisesti Hyvän speksin ominaisuuksia Määrittelyvaihe Asiakasvaatimusten selvittäminen Välineet, menetelmät Speksin kirjoittamisesta 12.9.2009

Asiakasvaatimuksista tuotteeseen asiakasvaatimukset Määrittely Suunnittelu& toteutus ohjelmistovaatimukset 12.9.2009

Asiakasvaatimus...tekninen vaatimus mukset Asiakasvaatimus – tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja. Ominaisuus, feature – jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle. Ohjelman toiminto – yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti... Tekniset vaatimukset – miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus, ... Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä. ohjelmis- tovaati- mukset 12.9.2009

Ohjelmistojen tuottaminen = speksien tuottamista? 12.9.2009

Speksattavat asiat (kuva 3.2) Spesifikaatio N Spesifikaatio N+1 reunaehdot ja reunaehdot ja rajoitteet rajoitteet ei-toiminnalliset ei-toiminnalliset vaatimukset vaatimukset spesifiointi vaatimukset toiminnalliset toiminnalliset vaatimukset vaatimukset Verifiointi esimerkiksi tarkastamalla 12.9.2009

Kaikki mahdolliset ratkaisut Rajoite 1 Rajoite 2 Rajoitteiden rooli Kaikki mahdolliset ratkaisut 12.9.2009

Hyvän speksin/vaatimuksen ominaisuuksia täydellisyys: kaikki tarpeellinen, ei mitään turhaa tarkkuus virheettömyys ymmärrettävyys testattavuus: miten voidaan "mitata", onko vaatimus täytetty jäljitettävyys: mistä vaatimus on peräisin, miten tärkeä se on sama asia vain yhdessä paikassa (ei redundanssia) (?) 12.9.2009

Esimerkkejä Järjestelmän käytettävissä on 64k-tavun muisti. Luokalla voi siis olla vain yksi luokanvalvoja? Jos kuukauden toteutunut myynti alittaa tavoitteet, tulostetaan raportti, ellei toteutuneen myynnin ja tavoitteen ero ole vähemmän kuin puolet edellisen kuukauden tavoitteen ja toteutuneen myynnin erosta, tai toteutunut myynti alittaa tavoitteen alle 5%. Varaston kiertonopeus kasvaa. Ilmoituksen on oltava kuvaruudulla 300ms kuluessa hälytyksen tapahtumisesta. Suihkumoottoreita ei saa kytkeä “pakille” ellei kone ole kentällä. Suihkumoottoreita ei saa kytkeä “pakille” ellei nokkapyörä pyöri tai nopeus ole nolla. 12.9.2009

Määrittelyvaihe (kuva 3.8) Ideat, Määrittelyprosessi lähtökohdat, rajoitteet, reunaehdot Ohjelmistovaatimukset Ongelman Toteutettavan ymmärtäminen, järjestelmän vaatimusten spesifiointi kartoitus Asiakasvaatimukset korjattavaa Toiminnallinen määrittely, alustava käyttöohje, toteutusprojektin Tarkastus projektisuunnitelma, testaussuunnitelma OK Asiakasvaatimukset muuntuvat ohjelmistovaatimuksiksi Arkkitehtuuri- suunnittelu 12.9.2009

Miten asiakasvaatimukset saa selville Toimialan tuntemusta ei korvaa mikään. Tee luettelo sidosryhmistä (stakeholder). Mieti, mitä odotuksia/toiveita/pelkoja jne... kullakin sidosryhmällä on. Keskustele käyttäjien kanssa heidän työpaikallaan. Suunnittele vierailut etukäteen huolellisesti. Tekeydy hieman tyhmemmäksi kuin luulet olevasi. Esitä varmistavia kysymyksiä: tarkoitat siis, että… Käytä esitystapoja, joita asiakas ymmärtää. Analysoi ja dokumentoi vierailun anti, tee yhteenveto. Yritä löytää alkuperäinen ongelma: miksi jokin asia pitää tehdä, voisiko sen jostain syystä jättää kokonaan tekemättä. yritä erottaa oleellinen pinttyneistä toimintatavoista Prototyypit. Käyttäjäkeskeinen suunnittelu (User Centered Desing) 12.9.2009

Mitä vaatimuksesta kirjataan (esimerkki) Luontipäivämäärä Tekijä Asiakas, vaatimuksen alkuperä Tyyppi (lisäys, muutos, korjaus) Vaatimuksen kuvaus Suhde muihin vaatimuksiin Tarpeellisuus (välttämätön, suotava, ekstra) Varmuus: ei muutu, saattaa muuttua, muuttuu todennäköisesti 12.9.2009

Menetelmät, välineet SA/RT, OMT, XP, RUP... Kuvaustekniikat: luokkakaaviot, tilakaaviot, tapahtumasekvenssikaaviot… Menetelmä = kuvaustekniikat + ohjeistus SA/RT, OMT, XP, RUP... "Dokumenttivetoisessa" työskentelyssä ei yleensä ole suurta väliä, mikä "menetelmä" tuottaa dokumentit. Ketterät menetelmät Vaatimukset määritellään tavallisesti hyvin yleisellä tasolla (XP: käyttäjätarina, user story, Scrum: product backlog). Uusia järjestelmäversioita syntyy usein, ja ne tavallaan toimivat järjestelmän speksinä. Ketteriin menetelmiin liittyy yleensä automatisoitu testaus. Hyvin dokumentoituja testitapauksia voidaan pitää eräänlaisina spekseinä (Test Driven Development, TDD). Välineet: upper case: mallinnus & dokumentointivälineitä lower case: sovellusten tuottaminen 12.9.2009

Speksin kirjoittamisesta Ohjelmistojen tekeminen on speksien tekemistä. Kirjoita asiakkaan näkökulmasta. Yhdellä dokumentilla voi olla erilaisia asiakkaita (asiakkaan tietohallintopäällikkö, pääkäyttäjä, käyttäjä…). Etene yleiskuvauksesta yksityiskohtiin. Käytä selkeää yksinkertaista kieltä, ei ”maalailua” tai huumoria. Havainnollista esimerkeillä. Vältä tarpeetonta toistoa (say it once and just once). Ei moniselitteisyyksiä ja ristiriitaisuuksia. Vaatimuksien toteutumisen on oltava kiistatta todettavissa. Dokumentoi myös syyt, miksi näin tehdään. Ole realisti: dokumentit vanhenevat nopeasti, eikä kaikkea kannata/ehdi ylläpitää. Käytä liitteitä: Täydelliset syntaksikuvaukset (esim. BNF, XML Schema) yms. raskaat speksit. Automaattisesti generoitavissa olevat osat (esim. rajapintakuvaukset). Usein muuttuvat osat. Ylläpitovaiheessa tarpeettomiksi käyvät osat (esim. yksityiskohtaiset käyttöliittymäkuvaukset). 12.9.2009