Tutustutaan harjoitustyön aiheeseen

Esitys aiheesta: "Tutustutaan harjoitustyön aiheeseen"— Esityksen transkriptio:

1 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

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

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

4 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

5 Ohjelmistojen tuottaminen = speksien tuottamista?

6 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

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

8 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) (?)

9 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.

10 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

11 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 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

13 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

14 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).