Projektityö 24.9.2010 Ohjelmistojen kehitysmalleista Vaatimusten määrittely ja kerääminen Lähteinä (vaatimusten määrittely): Haikala ja Märijärvi, Ohjelmistotuotanto, Talentum, 2005. Luvut 3, 4, 5, 6-10 (lukuja erilaisista kaavioista). Sommerville, I.: Software Engineering 7, luvut 6 ja 7. Kotonya, G. and Sommerville, I.: Requirements engineering. Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) 1
Miksi ohjelmistojen kehitys on vaikeaa? Ohjelmistotuotteet eivät ole fyysisesti kosketeltavissa. Työn etenemisen seuraaminen on haastavaa. Kehitysprosessit voivat vaihdella organisaatioittain ja kehitysympäristön mukaan. Työkalut muuttuvat. Yleensä tehdään jotain uutta. Ohjelmistotuotteet ovat erittäin monimutkaisia 2
Ohjelmistojen kehitysmallit - Miksi? Yleisesti tunnetun ja hyväksi koetun kehitysmallin käyttämisen hyötyjä ovat mm.: Tekee prosessista läpinäkyvän ja helpottaa tehtävien tunnistamisessa. Osittaa projektin hallittaviin osakokonaisuuksiin. Helpottaa projektin talouden seurantaa. Helpottaa riskien hallintaa ja poistaa epävarmuutta. Mahdollistaa projektin etenemisen seurannan. Mahdollistaa systemaattisen tavan ratkaista ongelmia. Antaa yhteisen sanaston. 3
Vesiputousmallin haasteita Soveltuu projekteihin, joissa on selkeät vaatimukset ja arkkitehtuuri ei ole monimutkainen. Usein on vaikeaa määrittää kaikkia vaatimuksia projektin alkuvaiheessa. Vesiputousmalli sopeutuu huonosti muutoksiin. Toteutusvaihe on vasta projektin loppupuolella, joten kestää pitkän aikaa, ennen kuin asiakas ja projektiryhmä näkee edes osittain toimivan version lopputuotteesta. Muutosten tekeminen on vaikeaa. Tarkastukset, katselmoinnit ja prototyypit pienentävät väärän tuotteen tekemisen riskiä. Pakolliset tarkastukset kurssilla: projektisuunnitelma, vaatimusten määrittely, testaus- ja toteutussuunnitelma. 4
Kehitysmallit - Inkrementaalinen I Esitutkimus vaatimusten määrittely for each increment: analysointi ja suunnittelu toteutus ja integrointi testaus (virheiden korjaus) end; ylläpito. Kun vaatimusten määrittely on valmis, toteutus voidaan jakaa inkrementteihin. Jokainen inkrementti suunnitellaan (inkrementin sisältö, toteutus, yksikkötestaus, integrointi, testaus) erikseen. Yleensä aloitetaan tärkeimmistä / riskialttiimmista järjestelmän osista. Koko järjestelmän toteutusta ei ole tarvetta suunnitella kerralla. Asiakas (ja käytettävyysryhmä) voivat antaa palautetta jokaisen inkrementin jälkeen. 5
Kehitysmallit - Inkrementaalinen II Väärän arkkitehtuurin valinnan riski on olemassa, mutta riski havaitaan nopeammin kuin vesiputousmallissa. Inkrementtejä voidaan joskus toteuttaa rinnakkaisesti. Inkrementtien pituus: 2-4 viikkoa (tällä kurssilla). Tarkastukset ja katselmoinnit kurssilla: Projektisuunnitelma ja Vaatimusten määrittely. Katselmoinnit kahdelle inkrementille (toteutuksen demoaminen, seuraavan inkrementin suunnitelmien läpikäynti). Yhteensä projektissa voi (tällä kurssilla) olla inkrementtejä noin 4-7. Toteutus- ja testaussuunnitelmat voidaan kirjoittaa / jakaa inkrementeittäin. 6
Ketteristä kehitysmalleista Kurssilla saa käyttää kaikkia yleisesti tunnettuja ohjelmistojen kehitysmalleja. Agile vs. Waterfall: A tale of two teams: http://www.youtube.com/watch?v=gddo3ob-4zy Scrum Basics: http://www.youtube.com/watch?v=vmgmpme_phg http://fi.wikipedia.org/wiki/scrum Tarkastukset ja katselmoinnit kurssilla: Tarkastus projektisuunnitelmalle, katselmoinnit kolmelle iteraatiolle (demo ja yleensä seuraavan iteraation suunnitelmien läpikäynti). Yhteensä iteraatioiden katselmointeja projektilla voi olla 5-9. 7
Vaatimusten määrittely - motivointia Vaatimuksissa tapahtuneet virheet huomattavasti kalliimpia korjata kuin toteutusvaiheessa tehdyt virheet. Mikäli vaatimusten etsinnässä ja esittämisessä epäonnistuu, voi tehdä yhden projektitoiminnan perusvirheen: antaa ratkaisun väärään ongelmaan. Ei kiistoja vääristä ja puuttuvista ominaisuuksista. Testauksen suunnittelu on helpompaa: voidaan käyttää esim. käyttötapauksia testauksen lähtökohtana. Muistutus: Kaikki vaatimukset on muistettava myös testata toteutuksen aikana tai sen jälkeen! 8
Kurssin liittyvää 1/2 Vaatimusten määrittelyssä kuvataan miten ohjelman tulee toimia (käyttäjän näkökulmasta). Kurssin virallinen dokumenttipohja on https://projectwiki. cs.uta.fi/wiki/requirements_specification. Käykää vaatimustenmäärittelyä läpi asiakkaanne kanssa sitä mukaan kun se valmistuu, näin saatte palautetta jo kirjoitustyön aikana. WF: Vaatimusten määrittely pitää tarkastaa loka-marraskuun vaihteessa. WF: Asiakkaan pitää hyväksyä koko vaatimustenmäärittely, joten asiakas pitää saada mukaan tarkastukseen! 9
Kurssin liittyvää 2/2 Vaatimusten määrittelyssä on otettava huomioon käyttöliittymäasiat (esim. erillinen käyttöliittymädokumentti) ja käyttötapaukset (UML:n käyttötapauskaavio). Vaatimusten selkeä numerointi ja ryhmittely auttaa jatkossa. Kaikki käyttötapaukset esitetään täsmällisesti Järjestelmän tarvitsemat tiedot ja tietokannat pitää kuvata täsmällisesti (UML:n luokkakaavio). Järjestelmän toimintaa käyttäjän näkökulmasta voi kuvata sekvenssikaavioilla (UML). Projektin lopussa vaatimusmäärittelyn on vastattava toteutusta. Jokainen vaatimus testataan. 10
Vaatimukset iteratiivisissa projekteissa Myös iteratiivisesti/ketterästi etenevät projektit ylläpitävät vaatimuksia (esim. tulostuskelpoinen wiki-dokumentti). Vaatimusten hallinta tehdään pääsääntöisesti käytetyn kehitysmallin suositusten mukaisesti. Vaatimustenmäärittelyn kirjoittaminen tapahtuu iteraatioittain. Katselmoinnit järjestetään iteraatioittain demon ja muun dokumentaation kanssa. Usein on järkevää kirjata koko järjestelmää koskevat vaatimukset jo alussa vaatimustenmäärittelyyn. Jatkossa jokaiseen iteraatioon liittyy siis vaatimusten määrittelyn luku tai oma vaatimustenmäärittely-dokumentti. Iteraation lopussa toteutetut vaatimukset testataan (verrataan kyseisen iteraation vaatimuksiin). 11
Hyvien vaatimusten ominaisuuksia Source: https: //projectwiki.cs.uta.fi/wiki/requirements_management written by Zheying Zhang. 1. Correctness (oikeellisuus): The requirements have to reflect the expected behavior of the users and customers. They have to be consistent with the business objective or the project scope. 2. Comprehensibility (käsitettävyys/ymmärrettävyys): The requirements are understood by all stakeholders. (a) Unambiguity (yksiselitteisyys): The requirements should be read in exactly one way by different people. (Clarify confusing terms in a glossary) (b) Right level of detail (riittävän yksityiskohtainen): The information given in the requirements is suitable to gain the 12
right understanding of the system and to start implementation. 3. Completeness (täydellisyys/eheys): All important elements that are relevant to fulfill the different client s tasks should be specified. 4. Consistency (yhtenäisyys): The stated requirements should be consistent with all other requirements, and other important constraints such as hardware restrictions, budget restrictions, etc. 5. Priority (tärkeysjärjestys): Each requirement is specified with its importance and/or its stability. 6. Verifiable (varmistettavuus, especially apply to NFR): There exists a process for a machine or a human to check whether the requirement is fulfilled or not. (NFR is specified in a measurable way) 13
14