T-76.115 Projektin katsaus

1. T-76.115 Projektin katsaus OtaShop2 Toteutus 313.3.2004

2. Projektin tila (15 min) vaiheen tavoitteiden saavuttaminen projektin edistymisen mittarit Käytetyt työmenetelmät (5 min) mitä vaiheen aikana on tehty ja tapahtunut Demo (15 min) Seuraavan vaiheen suunnitelmat (5 min) Esityksen sisältö ja aikataulu

3. Suunniteltujen tavoitteiden toteutuminen • Järjestelmää pyritään testaamaan ja havaintojen perusteella toteutetaan uusia ominaisuuksia sekä korjataan virheitä. Tarkoituksena on mahdollisimman nopeassa rytmissä kirjata puutteet bugzillaan, priorisoida ne sekä jakaa kehittäjille korjattaviksi. • Onnistunut hyvin, havaittu 75 ja korjattu 52 bugia • Järjestelmän antaminen testikäyttöön • Järjestelmä ollut testattavissa verkosta 18.2 alkaen.Ohjelmaa on demottu 18.2 kaukopalvelun esimiehen kanssa ja jätetty tämän jälkeen testattavaksi • Vertaistestauksen tekeminen • Tehty • Vikojen ja puutteiden korjaaminen testikäytön perusteella • Korjattu 75 bugia tai parannuskohdetta • Tarvittavien raporttien toteuttaminen (käyttötapaus 8) • Erilaisten hakujen suorittaminen on mahdollista ylläpitoliittymän toimintojen avulla. Ei ole tullut tarvetta toteuttaa erillisiä raportteja.

4. Suunniteltujen dokumenttien tilanne • Käyttöohje • Valmis • Projektisuunnitelma • Päivitetty • Vaatimusmäärittelydokumentti • Päivitetty • Tekninen dokumentti • Päivitetty • Testitapaukset • Valmis • Testiraportti • Valmis • Testaussuunnitelma • päivitetty • Edistymisraportti • Valmis • Riskienhallintadokumentti • Päivitetty • Vertaistestausdokumentit • Valmis

5. Tehtävien toteutuminen • Havaintoja ja perusteluja • Käyttöönoton suunnittelua ei tehty, koska käyttöönotto ei tule tapahtumaan kurssin aikana eikä ole varmuutta mihin järjestelmä asennetaan • Koulutusta ei myöskään suunniteltu, koska käyttöönoton ajankohdasta ei ole tietoa

6. Toteutuneet tunnit henkilöittäin

7. Laadun tunnusluvut Virheiden määrä • Vaiheen aikana on löydetty varsin paljon bugeja tai parannuskohteita. Vaiheen loppua kohden vähäisten ja nimellisten bugien osuus kasvoi selvästi, mikä osoittaa järjestelmän laadun parantuvan jatkuvasti.

8. Avointen ja korjattujen bugien lukumäärät

9. Bugien ryhmittely

10. Laadun arviointi • I3 vaiheessa ei enää arvioida erikseen kunkin moduulin laatua. Testaaminen on ollut pääasiassa järjestelmätestausta, jossa on keskitytty koko järjestelmän toimintaan • Laatua arvioitaessa kannattaa tutkia järjestelmän kauppa- ja ylläpito-osioita erikseen. Jo I2:n lopussa totesimme kauppaosion olevan laadultaan riittävässä kunnossa. Osion laatua on edelleen saatu parannettua tehostetulla syötteentarkastuksella (input validation). • Ylläpito-osio on I3:n aikana siirtynyt ison askeleen eteenpäin. Kuitenkin on todettavissa, että suurin osa auki olevista 23:stä bugista liittyy tämän osion toteutukseen. Kriittisiä bugeja ei kuitenkaan enää ole korjaamatta ja voidaan todeta, että osio saadaan laadultaan riittävään kuntoon viimeisen vaiheen aikana.

11. Ohjelmiston koko (LOC) • * jsp-tiedostoista ja testiluokissa on laskettu kaikki rivit, myös tyhjät ja kommentit • Ohjelmointiin käytetty n. 121 tuntia -> koodia syntynyt noin 8 riviä tunnissa • Uusia ominaisuuksia ei juurikaan toteutettu, vaan kyse oli lähinnä refaktoroinnista tai toiminnallisuuksien muuttamisesta Java-pakettien, testiluokkien ja jsp-tiedostojen rivimäärät (pelkät koodirivit/kommenttirivit)

12. Muutokset projektiin • Lisenssisyistä johtuen pyritään vaihtamaan tietokanta Oraclesta Postgre SQL:ään. • Käyttöönotto ei tule tapahtumaan kurssin aikana, eikä myöskään käyttäjien koulutusta järjestetä tämän takia. • Ohjelmisto toimitetaan asiakkaalle asennettuna testikoneeseen, sekä tämän lisäksi paketoituna rompulla.

13. Riskit • Riskienhallintaa on käsitelty projektisuunnitelman kappaleessa 7 ja erillisessä riskienhallintataulukossa • Tällä hetkellä näyttää siltä, että seuraavat riskit ovat toteutumassa: • Valittua teknologiaa ei voidakaan käyttää esim. lisenssisyistä • Tietokantana ei voida tuotannossa käyttää Oraclea • Riski on ollut alusta asti tiedossa ja ohjelma on tehty kantariippumattomaksi. Viimeisen vaiheen aikana pyritään vaihtamaan kannaksi PostgreSQL • ATK-keskus ei suostukaan asentamaan ohjelmistoa TKK:lle • Käyttöönotto ei tule onnistumaan kurssin aikataulujen puitteissa. • Järjestelmän mukana toimitetaan asiakkaalle selkeä asennusohje, sekä pyritään toimittamaan asiakkaalle toimiva järjestelmä asennettuna johonkin tietokoneeseen (ei tuotantokäyttöön). • Seuraavassa vaiheessa erityisesti seuraavia riskejä pitää tarkkailla • Testikäyttäjiltä ei saada riittävästi palautetta • Kaikkia kriittisiä virheitä ei ehditä korjata • Projektille budjetoitu aika ei riitä työn loppuun saattamiseen.

14. Työtavat • Karri Karanko esittelee kokemuksia testausmenetelmien käytöstä.

15. Vaiheen tulokset • Antti Kärkkäinen esittää demon järjestelmän toiminnasta

16. Seuraavan vaiheen suunnitelma • Tavoitteet • Järjestelmää testataan ja korjataan virheitä. Tarkoituksena on mahdollisimman nopeassa rytmissä kirjata puutteet bugzillaan, priorisoida ne sekä jakaa kehittäjille korjattaviksi. • Tietokannan vaihtaminen Oraclesta PostgreSQl:ään • Dokumenttien viimeistely • Asennusohjeen tekeminen ja ohjelmiston paketointi • Testilaitteiston toimittaminen asiakkaalle • Koko projektin analysointi ja loppuraportin laatiminen • Toteutettavat järjestelmän osat: • Koko järjestelmä • Dokumentit: • Kaikki projektin aikana tehdyt dokumentit + loppuraportti • Tavoitteiden priorisointi • Jos tietokannan vaihtamisesta tulee ongelmia, ei sitä tehdä • Testilaitteiston toimittaminen asiakkaalle ei ole välttämätöntä, jos ohjelmistopaketti on mahdollista ottaa käyttöön asennusohjeiden yms. dokumenttien perusteella • Tärkeimmät riskit ja epävarmuustekijät • Jos tietokannan vaihdossa tulee vaikeuksia, sitä ei ehditä tekemään • Järjestelmän testauksessa voi nousta esille ennen havaitsemattomia ongelmia/vikoja

17. Seuraavan vaiheen suunnitelma