Ohjelmistotekniikka: Luento 3 Jouni Lappalainen

Transkriptio

1 Ohjelmistotekniikka: Luento 3 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ö 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

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. Esittele näistä viisi. 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 3

4 Luku 4: Käytäntöä ohjaavat periaatteet Mitä eri vaiheissa selvitetään? Yleisestä ohjelmistotuotantoon Ymmärrä ongelma How to solve it Polya 1945 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) 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 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 6

7 Kommunikointi tapahtuu sidosryhmän (stakeholders) jäsenten välillä Prosessikehikon aktiviteetit kommunikointi projektisuunnittelu mallintaminen rakentaminen toimitus, käyttöön vieminen (deployment) 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) 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 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 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 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 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 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 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 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 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 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 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 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 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 18 Jouni Lappalainen & Ilkka Tervonen

19 Miten järjestelmä liittyy yrityksen muuhun liiketoimintaan? Liiketoimintavaatimukset Yrityksen johto Asiakaspäälliköt Sopimusneuvottelijat Mitä palveluja järjestelmä tarjoaa, missä olosuhteissa sen täytyy toimia? Esittävät järjestelmän toiminnot, palvelut ja rajoitukset tarkasti (mitä toteutetaan). Käyttäjävaatimukset Järjestelmävaatimukset 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ä) 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) Järjestelmävaatimusten selvittäminen Käyttäjävaatimusten selvittäminen Käyttäjävaatimusten määrittely Järjestelmävaatimukset dokumentti Liiketoimintavaatimusten määrittely Esitutkimus (feasibility study) Protoilu Katselmointi Sopiiko järjestelmä hyvin yrityksen tavoitteisiin? Voidaanko järjestelmä toteuttaa käytössä olevalla tekniikalla? Voidaanko järjestelmä integroida käytössä oleviin? Vaatimusten validointi (vastaako todella sidosryhmän tarpeita) Vaatimustekniikat, Sommerville

21 Ei-toiminnalliset vaatimukset Tuotevaatimukset Yrityskohtaiset vaatimukset Ulkopuoliset vaatimukset Käytettävyysvaatimukset Tehokkuusvaatimukset Suorituskykyvaatimukset Luotettavuusvaatimukset Tilavaatimukset Toimitusvaatimukset Siirrettävyysvaatimukset Toteutusvaatimukset Yhteistoiminnallisuusvaatimukset Standardivaatimukset Yksityisyysvaatimukset Eettiset vaatimukset Laillisuusvaatimukset Turvallisuusvaatimukset Sommerville

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

23 3. vaihe: Kehittäminen (elaboration) Käyttötapausten kehittäminen Vaatimusten kuvaaminen Skenaarioilla Luokkakaaviolla Käyttäytymiskaavioilla 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? 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. 25

26 Käyttötapauskaavio (use case diagram) VirtualShowRoom Konfiguraation valinta Laajennuskohta: Hinnan laskenta Asiakas <<extend>> Myyjä Hinnan laskenta Tilauksen vahvistus Tilauksen selaus <<include>> Tilauksen maksu Pankki 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. 27

28 Käyttötapauskaavio (use case diagram) VirtualShowRoom Konfiguraation valinta Laajennuskohdat: Hinnan laskenta Tilauksen talletus <<extend>> Asiakas Myyjä <<extend>> Hinnan laskenta Tilauksen vahvistus Tilauksen selaus <<include>> Tilauksen talletus Tilauksen maksu Tietokanta Pankki 28

29 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? 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. 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 32

33 4. vaihe: Neuvottelu (negotiation) Win-Win tilanne paras kaikki voittavat 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 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) 34

35 SAFEHOME järjestelmä SAFEHOME 01 alarm check fire away stay instant bypass not ready armed power off away stay max test bypass instant code chime ready * 0 # valvontamoduuli Aloita valvonta Manuaalinen ohjaus panic 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. Talon omistaja Järjestelmävastaava Ohjaus Internetin kautta Kuittaukset hälytyksiin Vikatilanteen ratkaisu Tunnistimien ja niiden ohjauksen konfigurointi Tunnistimet Jouni Lappalainen & Ilkka Tervonen 35

36 SAFEHOME off away stay alarm check fire away stay instant bypass not ready armed power max test bypass instant code chime * 0 # ohjauspaneli 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ä ready panic 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? 37

38 Luento 3: lait ja pohdiskeluaiheet 1. Sovellusalueen perinpohjainen tunteminen on hyvän suunnittelun edellytys (no 5, Curtis 1988) suunnitteluprosessissa tarvitaan sekä sovellusalueen että tietojenkäsittelyn tietämystä 2. 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ä 3. 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 38

39 $ $ $ $ $ $8.000 $6.000 $4.000 $2.000 $7.136 $139 $455 $977 Vaatimusm. Suunnittelu Koodaus Testaus Ylläpito 39

40 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. Esittele näistä viisi. 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 40