Projektityö 28.9.2012 Katselmoinnit ja tarkastukset Ohjelmistojen kehitysmalleista Vaatimusten hallinta Testaus Toteutuksen suunnittelu Projektin lopetus Kurssin luennoitsija Timo Poranen (email: timo.t.poranen@uta.fi, työhuone: B1023) 1
Katselmoinnit ja tarkastukset https: //projectwiki.cs.uta.fi/wiki/reviews_and_inspections https: //projectwiki.cs.uta.fi/wiki/project_plan_inspection https: //projectwiki.cs.uta.fi/wiki/review_meeting_agenda 2
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 voivat olla erittäin monimutkaisia. 3
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. 4
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. 5
Ketteristä kehitysmalleista Kurssilla saa käyttää kaikkia yleisesti tunnettuja ohjelmistojen kehitysmalleja. http://fi.wikipedia.org/wiki/ketter%c3%a4_ ohjelmistokehitys Scrum Basics (or Scrum Master in under 10 minutes): http://www.youtube.com/watch?v=vmgmpme_phg http://fi.wikipedia.org/wiki/scrum Tarkastukset ja katselmoinnit kurssilla: Tarkastus projektisuunnitelmalle, katselmoinnit kolmelle iteraatiolle (jokainen esittelee mitä on tehnyt, demo ja yleensä seuraavan iteraation suunnitelmien läpikäynti). Yhteensä iteraatioiden katselmointeja projektilla voi olla 5-9. 6
Agile Manifesto - periaatteet http://users.jyu.fi/~vesal/kurssit/ohjelmointi2010/ materiaali/agile.html 1. Tärkeintä on täyttää asiakkaan vaatimukset julkaisemalla jatkuvasti ja aikaisin uusia hyödyllisiä versioita ohjelmistosta. 2. Hyväksytään ja otetaan vastaan muuttuvat vaatimukset, jopa kehityksen loppuvaiheessa. Ketterät menetelmät valjastavat muutoksen asiakkaan kilpailueduksi. 3. Luovutetaan toimivia versioita kehitettävästä ohjelmistosta säännöllisesti, mielellään lyhyin väliajoin muutamasta viikosta muutamaan kuukauteen. 4. Liiketoiminnan ammattilaisten ja kehittäjien täytyy työskennellä päivittäin yhdessä koko projektin ajan. 7
5. Rakennetaan projektit motivoituneiden yksilöiden ympärille ja annetaan heille ympäristö ja tuki jota he tarvitsevat, sekä luotetaan, että he saavat työn tehtyä. 6. Kaikkein tehokkain tapa välittää tietoa kehitystiimille ja kehitystiimissä, on kasvokkain tapahtuva keskustelu. 7. Toimiva ohjelmisto on ensisijainen edistymisen mitta. 8. Ketterät menetelmät suosivat kestävää kehitystä. Rahoittajien, kehittäjien ja käyttäjien tulisi kyetä pitämään jatkuvasti yllä tasainen työtahti. 9. Jatkuva huomion kiinnittäminen tekniseen laatuun, sekä hyvään rakenteeseen ja suunnitteluun, lisää ketteryyttä. 10. Yksinkertaisuus - taito maksimoida työn määrä, jota ei tarvitse tehdä - on olennaista. 8
11. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat nousevat itseorganisoituvista tiimeistä. 12. Tasaisin väliajoin tiimi miettii miten voisi tulla entistä tuottavammaksi, ja sitten säätää ja muokkaa toimintaansa sen mukaisesti. 9
Vaatimusten määrittely - motivointia Vaatimusten määrittelyssä kuvataan miten ohjelman tulee toimia (käyttäjän näkökulmasta). Vaatimuksissa tapahtuneet virheet ovat 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. 10
Kurssin liittyvää Kurssin virallinen dokumenttipohja on https://projectwiki. cs.uta.fi/wiki/requirements_specification. Ketterissä projekteissa järjestelmän yleiset vaatimukset, käyttötapaukset ja mahdolliset tarkentavat vaatimukset dokumentoidaan usein suoraan projektin wikiin sekä projektinhallintasovelluksen tehtävien (issue) kuvauksiin. Käykää vaatimuksia läpi asiakkaanne kanssa järjestelmällisesti koko projektin ajan. Katselmoinnit. Vaatimusten määrittelyssä on otettava huomioon käyttöliittymäasiat (tai erillinen käyttöliittymädokumentti) ja käyttötapaukset (UML:n käyttötapauskaavio). Järjestelmän tarvitsemat tiedot ja tietokannat pitää kuvata täsmällisesti (UML:n luokkakaavio). 11
Hyvien vaatimusten ominaisuuksia https: //projectwiki.cs.uta.fi/wiki/requirements_management 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 right understanding of the system and to start 12
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
7. Modifiable (Muokattavuus/muutettavuus): The structure of the SRS allows the integration of changes in an easy, consistent and complete way. 8. Traceable (seurattavuus/jäljitettävyys): It should be possible to reference the requirement in an easy way (possible to identify the origin of a requirement). 9. Feasibility (toteutettavuus): The requirements can be implemented with the available technology, human resources, budget and schedule. 14
15
Testauksen perusteita ja tavoitteita Testaus tarkoittaa suunnitelmallista prosessia, jossa käytetään ohjelmaa tai sen osaa ja tavoitteena on löytää virhe. Ohjelmissa arvioidaan yleensä olevan ohjelmoinnin jälkeen yksi virhe muutamaa kymmentä ohjelmariviä kohden. Testaus näyttää, että ohjelmiston toiminnot toimivat määrittelyjen mukaan ja että tehokkuusvaatimukset saavutetaan. Testitapaukset pitäisi olla mahdollista jäljittää asiakkaan vaatimuksiin (joko suoraan tai epäsuoraan). Testaussuunnitelmaan taulukko, joka osoittaa testitapausten kattavuuden verrattuna vaatimusten määrittelyyn. Osa testitapauksista testaa myös niitä asioita, mitä ohjelma EI SAA tehdä. 16
Testaus ja projektin vaiheet Testitapauksia voi alkaa kirjata ylös testaussuunnitelmaan (projektin wikiin) samalla, kun vaatimuksia kerätään tai hyväksytään projektin toimesta toteutettavaksi. Toteutetut toiminnot testataan heti niiden valmistuttua. Ohjeita testaukseen voi myös kirjata projektinhallintasovellukseen joko toteutukseen liittyvän tehtävän (issue) yhteyteen tai sitten tehdä testeistä omia tehtäviä. Tulosten raportointi vapaamuotoisesti. Testauksen yleisperiaatteet kuvataan projektisuunnitelmassa. 17
Esimerkki Käyttötapaus: koululainen osallistuu Majava-kilpailuun. Ennen kilpailuviikkoa koulun opettaja on rekisteröinyt koulunsa kilpailujärjestelmään ja saanut kilpailutunnukset eri ikäryhmille. Kilpailu suoritetaan opettajan valvonnan alaisena koulussa. Koululainen valitsee järjestelmän etusivulta kilpailemaan -linkin, ja syöttää avautuvalle sivulle seuraavat tiedot: Etunimet, Sukunimi, Sukupuoli, Luokka, Tunnus (saa opettajalta). Tiedot syötettyään koululainen valitsee Jatka, minkä jälkeen hän voi tarkistaa omat tietonsa. Hän näkee myös oman opettajansa nimen. Koululainen voi palata muuttamaan tietojaan tai sitten aloittaa kilpailemisen siinä kategoriassa, mihin hänen syöttämänsä kilpailuavain hänet liittää. 18
Esimerkki - Mitä pitää muistaa testata? Raja-arvot (luokka-aste, tunnus,...) Täsmääkö kilpailuavain ja luokka-aste? Antaako järjestelmä järkevät virheilmoitukset puuttuvista/virheellisistä tiedoista? Pääseekö tietoja muuttamaan? Virheelliset syötteet (väärä kilpailutunnus, virheelliset nimet,...)? Voiko samalla nimellä, luokka-asteella ja kilpailutunnuksella kirjautua useampi kilpailija? Montako samanaikaista kilpailusuoritusta järjestelmä kestää? 19
Yksinkertaistettu näkemys ohjelmiston toteutuksen suunnittelusta Määrittely Tuote asiakkaan kannalta Arkkitehtuurisuunnittelu Jako moduuleiksi, rajapintojen määrittely Moduulisuunnittelu 110 1 0 00 00 00 111 00 00 11 00 11 11 0 0 1 1 Moduulien suunnittelu ja toteutus Järjestelmää ositetaan kunnes jokainen osa on riittävän pieni kuvattavaksi ohjelmistotason välineillä. 20
Suunnittelun eteneminen Suunnittelun eteneminen on luonteeltaan iteratiivista ja hierarkkista. Eri vaihtoehtoja on kokeiltava ja ositusta mietittävä, kunnes lopputulos on tyydyttävä. Kärsivällisyys arkkitehtuurisuunnittelussa palkitaan toteutusvaiheessa ja ylläpidon yhteydessä. Suunnitteluun liittyviä tehtäviä ovat mm. seuraavat: 1. Mietitään ratkaisun yleiset periatteet. 2. Suunnitellaan moduulirakenne: Monet moduuleista toteuttavat jonkin sovellusalueen abstraktion, joka on löydettävissä suoraan määrittelystä. Tekninen toteutus tuo mukanaan lisäksi ohjelmistomaailman abstraktioita. 3. Määritellään mitä tietoa moduulit sisältävät. 21
4. Suunnitellaan moduulien rajapinnat: funktiot ja niiden parametrit, poikkeukset, funktioiden sivuvaikutukset, tehdyt oletukset, ei-toiminnalliset vaatimukset (esim. suoritusaika) jne. 5. Määritellään moduulien näkyvyys: mitä muita moduuleja moduuli tarvitsee toiminnassaan. 6. Testataan ratkaisuja tutkimalla, millaisia kutsusekvenssejä ohjelman toiminnot aiheuttavat moduulien välillä. 7. Suunnitellaan moduulien sisäinen toteutus. 8. Varmistetaan kriittisimpien toteutusratkaisujen toimivuus esimerkiksi prototyypillä. 9. Suunnittelun dokumentointi. 22
Toteutussuunnitelman sisältö TTY:n pohja: www.cs.tut.fi/~projekti/dokumentit/test-sisalto.txt. 1. Johdanto 2. Järjestelmän yleiskuvaus 3. Arkkitehtuurin kuvaus (arkkitehtuuri yleisellä tasolla) 4. Moduuli (luokka /prosessi / yksikkö / pakkaus) kuvaukset 5. Valmisosat ja erityiset tekniset ratkaisut 6. Hylätyt ratkaisuvaihtoehdot 7. Jatkokehitysajatukset 8. Vielä avoimet asiat Mahdolliset liitteet: käyttöliittymän täsmällinen määrittely, virhekoodit, virheilmoitukset, koodaustyyliohje, tiedostojen nimet ja tarkoitus,... 23
Toteutussuunnitelman sisällöstä Suunnitelman tulee vähintään kaksi UML-kaaviota: arkkitehtuurin kuvaava komponenttikaavio (esittää järjestelmän fyysisten koodimoduulien väliset suhteet) tai pakettikaavio (kuvaa luokkien muodostamat ryhmät, itseasiassa luokkakaavio, jossa luokat voivat koostua luokista) ja luokkakaavio järjestelmän kaikista luokista. Tarvittaessa myös: Toteutuskaavio (esittää järjestelmän ohjelmisto- ja laitteistokomponenttien väliset suhteet). Varmista, että jokainen vaatimusmäärittelyn vaatimus toteutetaan. Varmista, että vähintään jokainen rajapintafunktio kuvataan suunnitelmassa tarkasti. Olihan tietokanta jo määritelty? Sekvenssikaavioita? 24
Loppuraportti Loppuraportti kuvaa projektin johtamisen (hallinnon) ja projektin tekemän työn. Kertoo mitä kokemuksia projektista on saatu. Kuvaa projektin heikkoudet ja vahvuudet. Antaa näkökulmia muille, lukijoina usein (saman firman) projektipäälliköitä, yrityksen muut työntekijät, asiakkaan edustaja, yrityksen johto, kurssin luennoitsija... Antaa myös muille projekteille käsityksen siitä, mitä on tehty. Ryhmä tekee yhdessä. https://projectwiki.cs.uta.fi/wiki/final_report 25
Loppukertomus (1/2) Jokainen projekti kirjoittaa 4-10 sivun kertomuksen projektistaan ja liittää kuvaukseen mukaan tärkeimmät tilastot (mm. tuntitaulukko, lista tehdyistä dokumenteista ja koodirivien lukumäärästä). Kertomuksessa esitellään: Projektiorganisaatio, asiakas, projektin aihe. Kuinka projekti eteni, kokemuksia Kohdattuja ongelmia ja mukavia asioita. Projektin hallinta (kuinka käytönnössä toimittiin) Käytetyt työvälineet, työmenetelmät Valokuvia projektiryhmästä, näyttökuvia tuotteesta, muita omia juttuja. 26
Loppukertomus 2/2 Kaikkien projektien raportit julkaistaan verkossa yksikön raporttisarjassa. Salaisissa projekteissa - keskustelkaa asioista toimeksiantajanne kanssa, mitä saatte julkaista. Kertomus toimitetaan luennoitsijalle helmikuun lopussa. Jokaisella ryhmällä pitää olla henkilö, jolta voi tarvittaessa kysyä ja tarkistaa asioita palautuksen jälkeen. Raportti jäädytetään huhtikuussa ja tämän jälkeen se saa ISBN-numeron. https://projectwiki.cs.uta.fi/wiki/project_story. 27
Projekti CD ja viimeinen henkilökohtainen raportti Kun projekti on valmis, niin jokainen projekti tekee oman projekti CD:n. CD annetaan (ainakin) luennoitsijalle ja toimeksiantajalle. CD sisältää projektinne kaikki dokumentit ja ohjelmakoodit. Muistilista mitä levyltä pitäisi löytyä: https://projectwiki.cs.uta.fi/wiki/project_cd. CD:ssä pitää olla README.txt tiedosto, jossa lukee mitä CD sisältää ja mitä missäkin hakemistossa on. Mainitkaa myös tekijänoikeus / salattavuus asiat. Lopuksi voikin sitten palauttaa henkilökohtaisen raportin Moodleen. 28
Ryhmien palautekeskustelut Kun ryhmä on palauttanut projekti CD:nsä ja jokainen ryhmän jäsen on palauttanut viimeisen raporttinsa, voi ryhmä varata ajan (pakolliseen) palautekeskusteluun. Tilaisuudessa käydään läpi projektin kulkua ja loppuraportti ohjaajan kanssa. Tarkoituksena on lopettaa projekti hallitusti. Tilaisuudessa voi esitellä ohjelmistotuotetta, mikäli esim. loppuesityksessä ei kaikki oleellinen ole tullut esille. Tilaisuuteen kuluu aikaa noin 30 minuuttia. Ryhmät varaavat ajan samoin kuin katselmoinneissa. 29