Ohjelmistotekniikka: Luento 4 Jouni Lappalainen

Transkriptio

1 Ohjelmistotekniikka: Luento 4 Jouni Lappalainen Luku 4: Käytäntöä ohjaavat periaatteet (kevyt esittely) kommunikoinnin, projektisuunnittelun, mallintamisen, rakentamisen ja toimituksen periaatteet Luku 5: Vaatimusten ymmärtäminen vaatimusmäärittelytekniikat alkutoimet, tavoitteiden selvitys, tarkempi määrittely, neuvottelu ja validointi toiminnalliset ja ei-toiminnalliset vaatimukset käyttötapausten käyttö Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 1

2 Soveltuvat lait ja pohdiskelun aiheita 1. Sovellusalueen perinpohjainen tunteminen on hyvän suunnittelun edellytys (no 5, Curtis 1988) 2. Puutteet vaatimusmäärittelyissä ovat suurin syy häiriöihin ohjelmistoprojekteissa / no 1, Glass Virheet ovat yleisimpiä vaatimusmäärittely- ja suunnitteluvaiheissa ja niiden korjaus on sitä kalliimpaa mitä myöhemmin ne havaitaan /no 2, Boehm 1975 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 2

3 Soveltuvat lait ja pohdiskelun aiheita Mikä on olennaista pienten yritysten vaatimusten hallinnalle Aranda et al. mukaan (katso oheinen paperi)? Aranda et al. esittelevät seitsemän pienen yrityksen vaatimusten hallintaa. Esittele kolme erilaista tapaa vaatimusten hallinnalle. Mitä esitutkimus (feasibility study) tarkoittaa vaatimusmäärittelyjen yhteydessä? Wiegers esittelee kymmenen ansaa, jotka tulisi välttää vaatimusmäärittelyprosessissa. Aranda, S. M. Easterbrook, and G. Wilson, Requirements in the wild: How small companies do it, Requirements Engineering Conference (RE'07) Wiegers K., 10 Requirements Traps to Avoid Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 3

4 Luku 4: Käytäntöä ohjaavat periaatteet Mitä eri vaiheissa selvitetään? Yleisestä ohjelmistotuotantoon How to solve it Polya 1945 Ymmärrä ongelma kommunikointi ja analyysi Suunnittele ratkaisu mallintaminen ja ohjelmistosuunnittelu Toteuta suunnitelma koodin generointi Testaa toteutusta testaus ja laadunvarmistus keitä sidosryhmät ovat? voidaanko ongelma osittaa? voidaanko ongelma esittää graafisesti? onko ongelma tuttu, onko ennen ratkaistu samanlaista? voidaanko osaongelmat määritellä? voidaanko esittää suunnittelutason kuvaus? vastaako koodi suunnitelmaa? onko katselmoitu? onko komponentit testattu testisuunnitelmien mukaisesti vastaako ohjelmisto asetettuja toiveita (vaatimuksia) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 4

5 Ydinperiaatteet - prosessia ohjaavat (voidaan soveltaa kaikkiin prosessimalleihin ja vaiheisiin) 1. Ole ketterä 2. Kiinnitä huomio laatuun joka vaiheessa 3. Ole valmis soveltamaan 4. Muodosta tehokas tiimi 5. Tue kommunikointia ja koordinointia 6. Hallitse muutos 7. Arvio riski 8. Tee kuvauksia & koodia (work products), jotka hyödyttävät muita Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 5

6 Ydinperiaatteet käytänteitä ohjaavat (toimitetaan ajoissa, korkea laatu, toteuttaa sidosryhmän tarpeet) 1. Hajota ja hallitse 2. Ymmärrä abstraktioiden käyttö 3. Pyri yhdenmukaisuuteen 4. Kiinnitä huomio tiedonsiirtoon 5. Rakenna modulaarinen ohjelmisto 6. Etsi sopivia suunnittelumalleja (patterns) 7. Tutki ongelmaa useasta näkökulmasta 8. Muista, että joku ylläpitää ohjelmistoa Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 6

7 Kommunikointi tapahtuu sidosryhmän (stakeholders) jäsenten välillä Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) 1. kuuntele 2. valmistaudu 3. kokous täytyy junailla (facilitate) 4. face to face kommunikointi on parasta 5. pidä kirjaa palaverista 6. pyri konsensukseen 7. pidä keskustelu oikeilla raiteilla 8. piirrä kuva, jos sanat ei riitä 9. jos jonkin aiheen käsittely ei etene, siirry seuraavaan 10. neuvottelu etenee, kun molemmat voittavat Sidosryhmä koostuu henkilöistä, jotka hyötyvät suorasti tai epäsuorasti kehitettävästä järjestelmästä (asiakkaat, käyttäjät, kehittäjät) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 7

8 Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) 1. ymmärrä projektin laajuus 2. ota asiakas mukaan suunnitteluun 3. huomaa, että suunnittelu on iteratiivista 4. perusta arviosi tietoosi (hyvillä tiedoilla hyviä ennusteita) 5. arvioi myös riskit 6. ole realistinen 7. säädä karkeisuus tarpeen mukaan 8. määrittele laadunvarmistus 9. kuvaa myös se, miten otat muutokset huomioon 10. seuraa suunnitelman toteutumista ja sovita sitä tarpeen mukaan Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 8

9 Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) Nämä 10 kohtaa esittävät mallintamisperiaatteita, jotka on sovitettu ketteriin menetelmiin Ambler & Jeffries Tavoitteena on rakentaa ohjelmisto, ei tuottaa malleja 2. Tee ainoastaan sellaisia kuvauksia, joita tarvitaan 3. Pyri yksinkertaisimpaan malliin, joka kuvaa ongelman 4. Tee malleja, joita voidaan muuttaa 5. Jokaisella mallilla pitää olla selvä tarkoitus 6. Käytä sovellukselle sopivaa mallintamistekniikkaa 7. Tee hyödyllisiä malleja, mutta älä välttämättä täydellisiä 8. Tärkeintä mallille on edistää ohjelmiston rakentamista, vältä dogmaattisuutta syntaksin (esitystavan) suhteen 9. Jos olet kokenut suunnittelija, luota vaistoosi 10. Hanki palautetta mahdollisimman aikaisessa vaiheessa Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 9

10 Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) Vaatimusten mallintamisen periaatteet 1. sovelluksen tietovirrat tulee ymmärtää tiedon kulku järjestelmään, järjestelmästä ulospäin ja sisäiset tietovarastot 2. ohjelmiston toiminnot tulee määritellä 3. ohjelmiston käyttäytyminen tulee kuvata 4. suuret kokonaisuudet ositetaan pienemmiksi 5. vain olennaiset asiat käyttäjän näkökulmasta - ei toteutusta Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 10

11 Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) Suunnittelun mallintamisen periaatteet 1. jäljitettävissä analyysimalliin 2. huomio järjestelmän arkkitehtuuriin, tietosuunnitteluun, rajapintoihin ja käyttöliittymään 3. komponenttien suunnittelussa huomio koheesioon (vain yksi toiminto) ja löysään kytkentään 4. mallit helposti ymmärrettäviä 5. iteratiivinen suunnittelu Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 11

12 Prosessikehikon aktiviteetit kommunikointi projektisuuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) koodaus valmisteluperiaatteet ymmärrä ongelma ja suunnitteluperiaatteet valitse sopiva kieli ja ympäristö tee yksikkötestit valmiiksi koodausperiaatteet noudata rakenteellisen ohjelmoinnin / valitun toteutuskielen periaatteita valitse sopivat tietorakenteet tee ohjelmasta helposti ymmärrettävä (logiikka, nimet, käytännöt, sisennykset) validointiperiaatteet katselmoi tarvittaessa, aja testit, refaktoroi testaus testit tulee voida jäljittää asiakkaan vaatimuksiin testitapaukset tehdään ennakkoon sääntö edetään in the small -> in the large täydellinen testaus ei ole mahdollista Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 12

13 Prosessikehikon aktiviteetit kommunikointi projektisuuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (jakelu, tuki, palaute) (deployment) 1. asiakkaan odotukset täytyy hallita kommunikoinnissa asiakkaan suuntaan täytyy olla varovainen, ettei asiakas saa liian ruusuista kuvaa 2. täydellinen toimituspakkaus täytyy koota ja testata 3. toimituksen tuki (help desk) täytyy järjestää ennen toimitusta 4. sopiva harjoittelumateriaali täytyy valmistaa loppukäyttäjälle 5. virheellistä ohjelmistoa ei saa toimittaa ei toimitusta lupauksin korjataan seuraavaan versioon Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 13

14 Luku 5: Vaatimusten ymmärtäminen Vaatimusmäärittelytekniikat Alkutoimet (inception) perusymmärrys ongelmaan sidosryhmät Tavoitteiden selvitys (elicitation) ongelmia voivat aiheuttaa rajaus, mitä järjestelmään kuuluu ymmärtäminen, asiakkaat eivät tiedä mitä haluavat muuttuvuus, vaatimukset muuttuvat ajan kuluessa Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 14

15 Vaatimusmäärittelytekniikat (jatkuu) Kehittäminen (elaboration) skenaarioista analyysiluokkiin Neuvottelu (negotiation) vaatimukset voivat olla ristiriitaisia resurssit eivät riitä kaikkien vaatimusten toteuttamiseen Määrittely (specification) voidaan käyttää esim. Wiegersin lomakepohjaa (template) Validointi (validation) katselmoidaan ja pyritään löytämään puuttuvat osat, ristiriitaiset vaatimukset ja epäyhdenmukaisuudet Vaatimusten hallinta tarvitaan tukea vaatimusten ja niiden muutosten hallintaan Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 15

16 1. vaihe: Alkutoimet (inception) Sidosryhmän tunnistaminen Eri näkökulmien tunnistaminen Pyrkimys yhteisymmärrykseen Ensimmäiset kysymykset Asiakkaalta ja sidosryhmältä kuka maksaa, käyttää, mitä hyötyä tuotteen liiketoimintavaatimukset Selvitetään ongelma ja asiakkaan näkemys ratkaisusta miten kuvataan hyvä tulos, johon päästään onnistuneella ratkaisulla mitä ongelmia ratkaisuun voi liittyä missä liiketoimintaympäristössä ratkaisua käytetään onko suorituskykyyn liittyviä tarpeita tai rajoituksia Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 16

17 2. vaihe: Tavoitteiden selvitys (elicitation) Yhteistyössä tehty vaatimusten keräys Kokouksissa mukana ohjelmistosuunnittelijat ja sidosryhmät, kokouksella vetäjä (facilitator) ja riittävän formaali asialista QFD (Quality Function Deployment) Skenaariot Selvityksen tulokset Mitä tarvitaan Lista asiakkaista, käyttäjistä ja sidosryhmästä Kuvaus teknisestä ympäristöstä Lista vaatimuksista niihin liittyvistä rajoituksista Joukko käyttöskenaarioita Mahdolliset prototyypit Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 17

18 Ymmärretään tarve Ymmärretään tuote Tekniset vaatimukset Vaatimusten selvittäminen (elicitation) Asiakkaan tavoitteet Toiminnalliset vaatimukset Toiminnan kuvaus Laatutavoitteet Skenaariot Skenaariot Skenaariot Skenaariot Liiketoiminta- Liiketoimintasäännöt Liiketoimintasäännöt säännöt Rajoitukset Ei-toiminnalliset vaatimukset Järjestelmän Järjestelmän tai ohjelmiston Järjestelmän tai määrittely ohjelmiston tai määrittely ohjelmiston määrittely väärinkäyttötapaukset esim. tehokkuus, luotettavuusja turvallisuusvaatimukset Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 18

19 Miten järjestelmä liittyy yrityksen muuhun liiketoimintaan? Mitä palveluja järjestelmä tarjoaa, missä olosuhteissa sen täytyy toimia? Esittävät järjestelmän toiminnot, palvelut ja rajoitukset tarkasti (mitä toteutetaan). Liiketoimintavaatimukset Käyttäjävaatimukset Järjestelmävaatimukset Yrityksen johto Asiakaspäälliköt Sopimusneuvottelijat Peruskäyttäjät Asiakaspäälliköt Sopimusneuvottelijat Järjestelmäarkkitehdit Peruskäyttäjät Järjestelmäarkkitehdit Ohjelmistosuunnittelijat Vaatimusmäärittelytyypit ja niiden lukijat (sidosryhmä) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 19

20 Järjestelmävaatimusten määrittely Vaatimusten määrittely & mallintaminen (organisaation, käyttäytymisen ja tiedon mallintaminen, ei-toiminnalliset vaatimukset) Vaatimusten selvittäminen (elicitation) Käyttäjävaatimusten määrittely Järjestelmävaatimusten selvittäminen Liiketoimintavaatimusten määrittely Esitutkimus (feasibility study) Protoilu Sopiiko järjestelmä hyvin yrityksen tavoitteisiin? Voidaanko järjestelmä toteuttaa käytössä olevalla tekniikalla? Voidaanko järjestelmä integroida käytössä oleviin? Käyttäjävaatimusten selvittäminen Katselmointi Järjestelmävaatimukset dokumentti Vaatimusten validointi (vastaako todella sidosryhmän tarpeita) Vaatimustekniikat, Sommerville 2004 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 20

21 Ei-toiminnalliset vaatimukset Tuotevaatimukset Yrityskohtaiset vaatimukset Ulkopuoliset vaatimukset Tehokkuusvaatimukset Luotettavuusvaatimukset Siirrettävyysvaatimukset Yhteistoiminnallisuusvaatimukset Eettiset vaatimukset Käytettävyysvaatimukset Toimitusvaatimukset Toteutusvaatimukset Standardivaatimukset Laillisuusvaatimukset Suorituskykyvaatimukset Tilavaatimukset Yksityisyysvaatimukset Turvallisuusvaatimukset Sommerville 2004 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 21

22 Esim: erityistä luotettavuutta vaativalle ohjelmistolle voidaan määritellä Luotettavuus (dependability) Palveluaste, saatavuus (availability) Luotettavuus, käyttövarmuus (reliability) Turvallisuus (safety) Varmuus (security) järjestelmän palvelut ovat käytettävissä tarvittaessa järjestelmä palvelee ennalta määrätyllä tavalla järjestelmä ei aiheuta vaaraa järjestelmä kestää hyökkäykset (confidentiality, integrity, availability) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 22

23 3. vaihe: Kehittäminen (elaboration) Käyttötapausten kehittäminen Vaatimusten kuvaaminen Skenaarioilla Luokkakaaviolla Käyttäytymiskaavioilla Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 23

24 Mitä käyttötapauksesta selviää? Ketä ovat ensisijaiset ja toissijaiset toimijat? Mitkä ovat toimijoiden tavoitteet? Mitä esiehtoja täytyy olla voimassa, ennenkuin kertomus voi alkaa? Mitkä ovat tärkeimmät toimijan suorittamat tehtävät? Mitä poikkeuksia tulisi huomioida kertomuksen yhteydessä? Mitä vaihtoehtoja on toimijan ja järjestelmän vuorovaikutukselle? Mitä järjestelmän tietoa toimija tarvitsee, tuottaa tai muuttaa? Tuleeko toimijan informoida järjestelmää ulkoisen ympäristön muutoksista? Toivooko toimija tulevansa informoiduksi odottamattomista muutoksista? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 24

25 Esimerkki: VirtualShowRoom Autonvalmistaja haluaa web-pohjaisen autojen myyntijärjestelmän (VirtualShowRoom, VSR). Tätä ohjelmistoa tarjotaan käyttöön kaikille asiakkaille maailmanlaajuisesti. Auton ostosta kiinnostunut asiakas voi sen avulla määritellä haluamansa auton ominaisuudet (malli, tyyppi, väri, lisävarusteet, jne.). Järjestelmän avulla asiakas saa tiedot valmistajan automerkeistä ja tyypeistä ja hintalaskelman ja toimitusajan räätälöidylle autolle. Järjestelmä antaa asiakkaalle myös listan paikallismyyjistä, joista asiakas voi valita sopivan. Kun asiakas on tehnyt ostopäätöksen, hän voi vahvistaa tilauksen, valita sopivan maksutavan ja maksaa tilauksen. Paikallismyyjät voivat selata saapuneita tilauksia ja tarkentaa niitä puuttuvilta osin. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 25

26 Käyttötapauskaavio (use case diagram) VirtualShowRoom Konfiguraation valinta Laajennuskohta: Hinnan laskenta Asiakas <<extend>> Hinnan laskenta Myyjä Tilauksen vahvistus Tilauksen selaus <<include>> Tilauksen maksu Pankki Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 26

27 Skenaario: VirtualShowRoom Skenaario: Harrin autovalinta Harri voitti pokerissa huomattavan summan rahaa ja päätti vaihtaa autoa. Hän on jo pitkään ollut ranskalaisten autojen ystävä ja aikoo pysyä edelleen. Merkkiä hän ei ole vielä päättänyt. Harri etsii webistä Citroenin myyjää ja ohjautuu VirtualShowRoomin sivuille. Katseltuaan tarjolla olevia automalleja, hänen vaihtoehdoiksi rajautuvat C4 ja C5 mallit. Koska Harri ajaa paljon pitkiä matkoja, hän valitsee dieselversion. Lisävarusteista Harri valitsee tässä vaiheessa navigaattorin, kattoikkunan ja vetokoukun. Värivaihtoehtoina ovat punainen, sininen ja harmaa. Koska Harri ei ole vielä jutellut vaimonsa kanssa auton väristä, hän haluaa tallettaa nämä vaihtoehdot myöhempää tilauksen tarkennusta varten. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 27

28 Käyttötapauskaavio (use case diagram) VirtualShowRoom Konfiguraation valinta Laajennuskohdat: Hinnan laskenta Tilauksen talletus <<extend>> Asiakas <<extend>> Hinnan laskenta Tilauksen talletus Tietokanta Myyjä Tilauksen vahvistus <<include>> Tilauksen maksu Pankki Tilauksen selaus Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 28

29 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 29

30 Käyttötapaus Konfiguraation valinta Toimijat Asiakas Kuvaus Määritellä autolle halutut ominaisuudet Esiehdot Internet ja selain ovat käytettävissä Herätin/liipasin Asiakas innostuu auton hankkimisesta Normaali skenaario 1) Asiakas kirjautuu järjestelmään 2) Selaa vaihtoehtoja 3) Valitsee haluamansa mallin, tyypin ja lisävarusteet Laajennuskohdat Hinnan laskenta, Tilauksen talletus Poikkeukset Kirjautumisen ongelmista täytyy huolehtia Prioriteetti Tärkeä, toteutetaan ensimmäisessä vaiheessa Käyttötiheys Tuhansia samanaikaisia käyttäjiä Muita huomioita Kuinka nopeasti kirjautuminen tulee suorittaa? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 30

31 Konfiguraation valinta & Hinnan laskenta Toiminnalliset vaatimukset (käyttäjän määrittelemät, UR-0X (tai KV-0X)) UR-01: Käyttäjä voi valita automallin mallilistasta. UR-02: Valitulle mallille saatavissa olevat lisävarusteet esitetään. Käyttäjä voi valita haluamansa lisävarusteet listasta. UR-03: Valitun konfiguraation kokonaishinta päivitetään ja näytetään jokaisen valinnan jälkeen. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 31

32 Ei-toiminnalliset vaatimukset (Sommerville) Tuotevaatimukset (laatuvaatimukset, QR-0X (tai LV-0X)) Käytettävyys QR-01: malli- ja lisävarustelista on selkeä, valinnan teko helppoa QR-02: kokonaishinnan päivitys vie aikaa < 0.5 sek Tehokkuus QR-03: yhtäaikaisia käyttäjiä , vasteaika < 1 sek Luotettavuus QR-04: elpyminen häiriöstä varmistettu QR-05: palveluaste korkea, järjestelmä pois käytöstä korkeintaan 1 min/vrk QR-06: asiakastiedot vain myyjien saatavilla Siirrettävyys QR-07: varmistettava siirrettävyys Linux versioiden välillä QR-08: tietokanta ODBC rajapinnan taakse Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 32

33 4. vaihe: Neuvottelu Win-Win tilanne paras kaikki voittavat (negotiation) Sidosryhmät tyytyväisiä, kun saavat järjestelmän tai tuotteen, joka toteuttaa suurimman osan asetetuista tavoitteista Kehitystiimi tyytyväinen, kun voi kehittää järjestelmää tai tuotetta realistisen ja varman budjetin ja deadlinen mukaan lisää vaatimusmäärittelyihin liittyviä papereita Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 33

34 5. vaihe: Vaatimusten katselmointi (validation) Katselmoinnin tarkistuslista Ovatko vaatimukset yhdenmukaisia koko järjestelmän tavoitteisiin nähden? Ovatko vaatimukset sopivalla abstraktiotasolla? Ovatko vaatimukset todella välttämättömiä, vai tarjoavatko ne lisäominaisuuksia? Ovatko vaatimukset selviä ja ymmärrettäviä? Löytyykö jokaiselle vaatimukselle sen asettaja? Ovatko vaatimukset ristiriitaisia? Ovatko vaatimukset testattavissa, kun toteutettu? Kuvaako vaatimusta esittävä malli riittävästi rakennettavaa järjestelmää (tieto, operaatio, käyttäytyminen)? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 34

35 SAFEHOME järjestelmä SAFEHOME off away stay 01 away stay max test bypass alarm instant check bypass fire not ready instant code chime ready armed power * 0 # valvontamoduuli Aloita valvonta Manuaalinen ohjaus panic Talon omistaja Ohjaus Internetin kautta Kuittaukset hälytyksiin Tunnistimet Järjestelmän hankkineella talon omistajalla on mahdollisuus ohjata järjestelmää joko manuaalisesti ohjauspaneelin tai tietokoneen avulla Internetin yli. Tunnistimet tuottavat järjestelmään hälytyksiä ja vikailmoituksia. Omistaja kuittaa hälytykset ja ratkaisee vikatilanteet. Järjestelmävastaavan vastuulla on tarvittaessa konfiguroida tunnistimien toiminta. Järjestelmävastaava Vikatilanteen ratkaisu Tunnistimien ja niiden ohjauksen konfigurointi Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 35

36 SAFEHOME off away stay 01 away stay max test bypass alarm instant check bypass fire not ready instant code chime ready armed power * 0 # panic Ohjauspaneeli ilmaisee toimijalle järjestelmän tilan: - not ready ilmoitus tarkoittaa, että huoneiston jokin ovi tai ikkuna on auki toimija käyttää näppäimistöä antaakseen nelinumeroisen salasanan -jos salasana on väärä, järjestelmä ilmoittaa piippaamalla, jos oikea, odottaa jatkotoimia toimija asettaa järjestelmän käyttöön stay (talon ulkopuolen tunnistimet) tai away (kaikki tunnistimet) näppäimillä Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 36

37 Käyttötapaus: AloitaValvonta Toimijat: Talon omistaja Kuvaus: Asettaa järjestelmä valvomaan tunnistimia Esiehdot: Järjestelmä Herätin/liipasin: Talon omistaja päättää asettaa järjestelmän päälle Skenaario: (1)Talon omistaja antaa salasanan ja valitsee stay tai away toiminnan. (2) Järjestelmä ilmaisee kahdella piippauksella stay valinnan ja kolmella piippauksella away valinnan. (3)Tämän jälkeen omistaja havaitsee ohjauspaneelista punaisen valon palavan, eli järjestelmän olevan päällä. Poikkeukset: Ohjauspaneelissa not ready, omistaja tarkastaa kaikki tunnistimet ja sulkee ovet & ikkunat tarvittaessa. Salasana on väärä, omistaja näppäilee uuden salasanan Prioriteetti: Tärkeä, toteutetaan ensimmäisessä vaiheessa Käyttötiheys: Monta kertaa päivässä Muita huomioita: Pitäisikö ohjauspaneelin esittää muitakin viestejä? Kuinka nopeasti salasana tulee antaa? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 37

38 Luento 3: lait ja pohdiskeluaiheet Sovellusalueen perinpohjainen tunteminen on hyvän suunnittelun edellytys (no 5, Curtis 1988) suunnitteluprosessissa tarvitaan sekä sovellusalueen että tietojenkäsittelyn tietämystä Puutteet vaatimusmäärittelyissä ovat suurin syy häiriöihin ohjelmistoprojekteissa / no 1, Glass 1998 esimerkkejä: Denverin lentokentän laukkujen kuljetusjärjestelmä ei kysytty lentoyhtiöiden tarpeita - lopputuloksena kolme erillistä järjestelmää Floridan osavaltion sosiaaliavustusjärjestelmä vaatimuksena oli hajautettu järjestelmä, mutta lähdettiin rakentamaan käyttämällä uudelleen useita miljoonia koodirivejä olemassa olevasta keskitetystä järjestelmästä Virheet ovat yleisimpiä vaatimusmäärittely- ja suunnitteluvaiheissa ja niiden korjaus on sitä kalliimpaa mitä myöhemmin ne havaitaan /no 2, Boehm 1975 on tärkeää paikallistaa virheen syntypaikka väitetään, että prosenttia kaikista projektin aikana havaituista virheistä syntyy vaatimusmäärittely- ja suunnitteluvaiheissa Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 38

39 $ $ $ $ $ $8.000 $6.000 $7.136 $4.000 $2.000 $139 $455 $977 Vaatimusm. Suunnittelu Koodaus Testaus Ylläpito Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 39