Joku hauska otu-aiheinen kuva (no ei oo pakko olla hauska) OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

Transkriptio

1 OHJ-3010 Ohjelmistotuotannon perust eet, kesäkurssi 2012 Joku hauska otu-aiheinen kuva (no ei oo pakko olla hauska) OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

2 Päivän ohjelma - Mythical Man Month: keskustelua - Pieni projektineuvotteluharjoitus - Käyttötapaukset ja niihin liittyvä harjoitus - Seminaariaiheiden ja -aikojen varauslista jälleen tarjolla - Kotitehtävä: Case VR, MagicDraw OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

3 Mythical Man Month OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

4 Mythical Man Month Projektin aika-arvio ylittyy usein. - Arviointitekniikat ovat epätarkkoja ja huonoja. - Henkilötyökuukausi ei ole hyvä mitta projektin koolle. - Ohjelmoijien optimismi. - Testaukseen ei varata riittävästi aikaa. - Henkilöstön lisääminen myöhässä olevaan projektiin myöhästyttää sitä lisää. - Tutkimustuloksia ja tilastoja tulisi julkaista (Nykyään alan tutkimus on melko vilkasta...) - Jos aikataulua joudutaan muuttamaan, muutetaan sitä kerralla riittävästi. OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

5 Mythical Man Month Projektiin kuluva aika ei mene suhteessa sen kokoon. - Vain 50% työajasta käytetään oikeasti projektia eteenpäin vieviin asioihin. - Ohjelmoijen tuottavuus vaihtelee suuresti ohjelman monimutkaisuuden mukaan. - Korkeamman tason ohjelmointikielillä voidaan saavuttaa merkittävästi parempi tuottavuus. - Myöhästyminen johtuu pikkutekijöiden summasta. - Aikataulun pitäminen tarkasti määritettyjen välietappien kanssa on tärkeää. - Kannattaa laatia kriitisen polun kaavio. - Projektin johtajan rooli ja suhtautuminen alempiin johtajiin on tärkeää. - Kannattaa työskennellä koko ajan hieman etuajassa, kompensoiden väistämättömiä pieniä myöhästymisiä OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

6 Tehtävä 1: projekt ineuvot t eluharjoit us Jaettuna ovat tekemänne asiakasvaatimukset. Pohtikaa ryhmissä asiakkaan näkökulmasta esimerkiksi seuraavia asioita: - Miten voitte varmistua siitä, että saatte varmasti sitä mitä haluatte? Ominaisuudet, sovelluksen ulkoinen olemus, jne. - Minkälaisia seikkoja sopimuksessa tulisi ottaa huomioon? - Miten turvaatte oman asemanne? - Miten rahoitusasiat kannattaisi sopia? - Mitä sidosryhmiä projektiin liittyy? - Tuleeko mieleenne reunaehtoja tai rajoitteita? OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

7 Käyttötapaukset Kalvot: Ilkka Haikala 2009 OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

8 Dipparekist eri - Ohjelmistotekniikan laitoksella valmistuu noin 100 diplomityötä vuodessa - D-työn tekemiseen kuluu aikaa muutamista kuukausista useisiin vuosiin - D-töitä ohjaavat laitoksen professorit, kukin hieman toisista poikkeavalla tavalla - D-työstä ylläpidetään aina tiettyjä perustietoja, lisäksi ohjaajilla on henkilökohtaisia tapoja pitää muistiinpanoja - D-töiden etenemistä seurataan: diplomityön rajaus valmis, aihe hyväksytty tk-neuvostossa, x sivua kirjoitettu, työ tuotu tarkastettavaksi, työ hyväksytty, seminaariesitelmän pvm, jne.) - Järjestelmän pitää siis sisältää yhteinen tietovarasto, jossa on kaikkien diplomitöiden perustiedot ja toisaalta yksittäisen ohjaajan tietovaraston pitää olla henkilökohtaisiin tarpeisiin mukautettavissa (ja käytettävissä ilman verkkoyhteyttä?).

9 Käyttötapauskaavio, versio 1 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o kirjoita lausunto Pohja järjestelmän hahmottamiselle ja siitä keskustelemiselle

10 Käyt t öt apauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuisti o lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja

11 Toinen esimerkki KT-kaaviost a S a l i n v a r a u s j ä r j e s t e l m ä Varausten poistaminen Vastuu - henkilö Luentosalin varaaminen <<include>> <<include>> Perustietojen ylläpito ylläpitäjä <<include>> assistentti Harjoitussalin varaaminen <<include>> Käyttäjän identifiointi Salivuokran laskutus <<actor>> vuokrajärjestelmä

12 esimerkki Nimi: Luentosalin varaaminen, versio 1.0 / ijh Osallistujat: Vastuuhenkilö Tuloehdot: Vastuuhenkilö ja kurssi on syötetty järjestelmään (KT henkilötietojen ylläpito) Kuvaus: Vastuuhenkilö seuraa WWW-linkkiä, joka johtaa järjestelmän pääsivulle. Hän syöttää järjestelmään käyttäjätunnuksensa ja salasanansa (include: KT käyttäjän identifiointi). Käyttäjä pyytää järjestelmää näyttämään salin varaustilanteen haluamaltaan aikaväliltä. Hän saa eteensä salin lukujärjestysnäytön (ks. liite). Käyttäjä näkee näytöstä vapaat ajat sekä myös, mille kursseille sali on milloinkin varattu ja kuinka monelle viikolle. Käyttäjä tekee varauksen joltain vapaaksi havaitsemaltaan ajankohdalta. [Poikkeus: varaus ei onnistu]. Poikkeukset: Varaus ei onnistu: Varaustilanne on voinut muuttua sillä aikaa kun varaaja tekee varausta. Järjestelmä ilmoittaa tilanteesta käyttäjälle ja käyttäjä yrittää uudelleen. Lopputulos:Varaukset kurssin luentoajoiksi on tehty. Muut vaatimukset:päivittäin käsitellään kiireisimpänäkin aikana enintään n. 100 varausta. Vastausajan on oltava alle 1 sekuntia, lukujärjestysnäytön päivitys saa kestää 5 sekuntia.

13 Käyt t öt apauksen kuvaaminen UML ei standardoi mitenkään esitystapaa, eikä oikeastaan juuri muutakaan niihin liittyvää => paljon erilaisia tulkintoja Käyttötapauksen sisältö voidaan kuvata esimerkiksi: Käyttötapauksen nimi: Kuvaava nimi Osallistujat: Mitkä aktorit osallistuvat Tuloehdot: Mitkä ehdot ovat voimassa, kun käyttötapaus aloitetaan Kuvaus: Epäformaali, voidaan käyttää myös sekvenssikaavioita Poikkeukset: Poikkeustilanteet (mainitaan myös kuvauksessa) Lopputulos: Mitkä ehdot ovat voimassa, kun käyttötapaus lopetetaan Muut vaatimukset: käyttötapaukseen liittyvät ei-toiminnalliset vaatimukset

14 Käyttötapauskaavio: notaatio Aktori: käyttötapaukseen osallistuva käyttäjärooli Järjestelmä Käyttötapaus Käyttötapaus sisältää laajennuskohtia, joihin toinen käyttötapaus voidaan sijoittaa <<extend>> Käyttötapaus Käyttötapaus Aktori Käyttötapaus sisältää toisen osanaan <<include>> Käyttötapaus Käyttötapaus on erikoistapaus toisesta

15 Vältä käyttötapausten välisiä suht eita Accounting System Pay invoice Byer <<extend>> Pay overdraft fee Perform interaction Seller Älä käytä erikoistamista ja laajentamista ja sisällyttämistäkin vain säästeliäästi. 15

16 Käyttötapausten laatimisesta - Käyttötapauskaavio tukee käyttötapojen suhteiden kuvaamista, ei niiden sisällön kuvaamista. UML ei määrittele sisällön esitystapaa. - Käyttötapausten tulee olla ymmärrettävissä sekä asiakkaan että suunnittelijan kannalta. - Käyttötapauksen abstraktiotason on oltava sopiva (ei esim. yleensä käyttöliittymän yksityiskohtia). - Kaikkia käyttötilanteita/asiakasvaatimuksia ei voi/kannata antaa käyttötapauksina. - Käyttötapauksella tulee olla selkeä aloitustilanne ja lopetustilanne. - Käyttötapauksen "suuruudesta" päättäminen voi olla vaikeaa: Käyttötapauksen tulisi olla suhteellisen lyhyt (yhden sivun kuvaus). Käyttötapaus tuottaa käyttäjälle lisäarvoa (ei yleensä yksittäinen ohjelmiston toiminto, vaan kokonainen tuloksen tuottava ketju toimintoja). Käyttötapaus ei siis yleensä ole yksittäinen ohjelmalla suoritettava toiminto (ei siis esimerkiksi: tekstin kopiointi leikkuupöydälle).

17 Miksi käyt t öt apauksia? - Toimii apuna hahmotettaessa järjestelmää (yhteinen näkemys järjestelmästä) - Liittää asiakasvaatimukset järjestelmän toimintoihin - Mahdollistaa vaatimusten täsmentämisen - Rajaa järjestelmän ympäristöstään - Auttaa tunnistamaan kuka tai mikä käyttää järjestelmää - Määrittää järjestelmän korkean tason toiminnallisuuden - Auttaa jakamaan toiminnallisuuden osajärjestelmiin. - Määrittää järjestelmän perustermit - Apuna olioiden (keskeisten käsitteiden) tunnistamisessa - Voidaan käyttää ohjelmistokehityksen organisointiin (iteraatioiden suunnittelu) - Testauksen suunnittelu

18 Vaatimusten liittäminen toisiinsa KT:n avulla Asiakasvaatimukset Ohjelmistovaatimukset tekstin kopiointi maalaa kopioi KT kopioi teksti leikkaa tekstin siirtäminen siirrä kohdistin KT siirrä teksti liitä

19

20 Käyttäjätarina (user story) - Ketterissä menetelmissä yleisesti käytetty termi. - Muutamaan lauseeseen typistetty "käyttötapaus" - Tarinasta selviää: rooli (aktori) mitä tehdään ja mahdollisesti mitä lisäarvoa tekeminen tuottaa käyttäjälle (usein tämä on kuitenkin ilmeistä) Esimerkiksi: Kurssin vastuuhenkilönä pystyn tekemään kaikki yhden kurssin luentosalivaraukset yhdellä varausoperaatiolla (silloin kun luentoajat ovat koko kurssin ajan samoina viikonpäivinä samaan kellonaikaan).

21 Prepay Voucher -palvelu (Jyväkorpi 2001)

22 Harjoitellaanpa!

23 Tehtävä 2: Koulun kirjasto Asiakasvaatimuksia: Koululla on oma kirjasto, josta opiskelijat saavat lainata kirjoja. Opiskelijakortti toimii lainauskorttina. Lainaajalla voi olla korkeintaan 5 kirjaa kerrallaan lainassa. Kirjaa saa pitää lainassa korkeintaan yhden kuukauden. Kirjoja voi varata. Tehkää noin neljän hengen ryhmässä järjestelmästä: käyttötapauskaavio (aktorit, käyttötapaukset, yhteydet) yksi käyttötapaus (nimi, suorittajat, esiehdot, kuvaus, poikkeukset, lopputulos, muut vaatimukset)

24 Läpikäynti

25 Esimerkkivastaus: käyt t öt apauskaavio

26 Esimerkkivastaus: käyt t öt apaus Käyttötapaus: Lainaa kirjoja (versio 1.0 / ijh) Suorittaja(t): Asiakas Esiehdot: Kirjat ovat käsillä (lainaaja on hakenut itse, tai varattu kirja on otettu varaushyllystä). Kuvaus: Asiakas esittää opiskelijakorttinsa, josta saadaan opiskelijanumero. Järjestelmä tarkastaa, että asiakas ei ole syystä tai toisesta lainauskiellossa. Kirjat kirjataan asiakkaalle lainatuksi yksi kerrallaan [poikkeus 1: lainaajakohtainen yläraja ylittyy] [poikkeus 2: kirjan lainaus estyy kirjan varaustilanteen takia] Lopputulos: Kirjat on lainattu. Poikkeus 1: Järjestelmä ei anna lainata enempää kirjoja. Tämän tilanteen estämiseksi ennalta järjestelmä näyttää koko lainaustapahtuman ajan, kuinka monta kirjaa on vielä lainattavissa. Poikkeus 2: Kirjaan voi kohdistua yksi tai useampia varauksia. Ylimääräisiä kirjoja ei ole, kirjaa ei saa antaa lainaan. Muut vaatimukset: Lainaustapahtuman vasteajan on oltava alle 1 sekuntia.

27 MagicDraw-demo

28 Kotitehtävä: Case VR Luettavaksi jaetaan Suomen kuvalehdessä ilmestynyt artikkeli. OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012

29 Ensi viikolla - VR:n tapauksen käsittely - Luokkakaaviot - Esimerkki käyttöliittymäkuvien piirtelystä harjoitustyötä varten - Torstaina ei harjoituksia, vaan tarkoitus on valmistautua ryhmissä seuraavan viikon asiakastapaamisiin. OHJ-3010 Ohjelmistotuotannon perusteet, kesä 2012