T-76.115 Projektikatselmointi

1. T-76.115 Projektikatselmointi Alpha-Team Toteutus 1 (I1)2.12.2004

2. Projektin tilanne (10min) iteraation tavoitteiden saavuttaminen projektin metriikat Iteraation tulokset (25 min) Tekninen määrittely Järjestelmän demo Sovelletut käytännöt (5 min) Keskustelua ja kysymyksiä (5 min) Agenda

3. Projektin yleiskuva • Projektin tarkoituksena on toteuttaa Test World Oy:lle NOHEVA-järjestelmä projektien- ja resurssienhallintaan • Toteutus: selain (JSP), Tomcat -palvelin (Java), MySQL -tietokanta

4. Projektin tila • 55 % tunneista käytetty • Projektin kokonaistavoitteet: ei vielä täytetty yhtään • Kaikki rajoitteet täytetty • Vaatimusten toteutuminen

5. Iteraation tavoitteiden tila • Tavoite 1: suunnitella järjestelmän perusarkkitehtuuri • Ok, kuvattu teknisessä määrittelyssä • Tavoite 2: toteuttaa järkevän kokonaisuuden muodostava osa järjestelmästä • Ok, asiakasprojektit ja resurssivaraukset toimivat • Alkuperäisestä suunnitelmasta karsittiin resurssien hallinnointi ja testausprojektien luonti/hallinnointi • Tavoite 3: toimittaa ensimmäinen versio järjestelmästä koekäyttöön asiakkaalle • Ok, toimitetaan 2.12 suunnitellusti • Tavoite 4: testata järjestelmä suunnitellusti toteutettujen toiminnallisuuksien osalta • Ei ok, muodollista hyväksymistestausta ei tehty • Suunnitellusti järjestelmätestausta 3 kierrosta ja heuristinen arviointi • Tavoite 5: täyttää järjestelmälle asetetut laatutavoitteet • Ok, päätettiin jättää 4 minor virhettä (ja hienosäätöä voi aina keksiä)

6. Iteraation tuotosten tila • Toteutetut käyttötapaukset: • Suunnitelma: UC1-6 ja UC15-20 • Toteutunut: UC1-2,4,6,18-20,25 sekä osin UC14 (salasanan vaihto) ja uusi käyttötapaus UC21 (poista varaus) • Pois jäi resurssien hallinnointi ja testiprojektit, toteutetut osat viimeisteltyjä • Syyt: 5 pv hukattiin arkkitehtuurin puutteeseen, Javalla aloitus hidasta, • Toisaalta: opittiin paljon, loppuiteraatiossa nopeaa • Toteutetut arkkitehtuuriosat: • Tietokantamalli (ok) • Valmis, mutta saattaa tulla muutoksia testiprojektien dataan liittyen • Tietoturvaratkaisu (ok) • Salattu yhteys, salasanat kryptattu, palvelin suojattu • Dokumentit: • päivitetty projektisuunnitelma ja vaatimusmäärittelydokumentti (ok) • tekninen määrittely (ok, puuttuu tietoturvan kuvaus) • Testitapaukset (ok, mutta testitapaukset vain Smoke-test –paketissa) • testiloki ja –raportti (ok) • edistymisraportti (ok) • päivitetyt SEPA päiväkirjat (suunnitelmat ja kokemukset lisätty, ok) • käyttöohje toteutettujen toiminnallisuuksien osalta (ok) • Kokousmuistiot ja käyttöliittymän prototyyppi web-sivuilla (ok)

7. Tehtävien toteutuminen Toteutuneet tunnit I1-vaiheessa tehtävittäin • Aikaa kului arvioitua enemmän • Tehtävät ok, arviot toteutuksen osalta ylittyivät paljon • Toisaalta mentor ja asiakas viestittivät että tunteja kannatta tässä vaiheessa käyttää (vrt. säästää FD-vaiheeseen) • Yli arvion: • Tietokannan toteutus • Arvio hihasta (ei kokemusta aiemmin) • Yhteyden kanssa odottamattomia ongelmia • Toteutus • Kokemattomat kehittäjät, arvioiden tekijöillä kokemusta tekniikasta • Hukattiin 5 päivää puutteelliseen arkkitehtuuriin • Toteutustekniikkaan tutustuminen • Vaati paljon itsenäistä työtä • Alle arvion: • Testaukseen arvioitua vähemmän aikaa (koska toimintoja arviota vähemmän ja ei hyväksymistestausta) • Tapaamisia suunniteltua vähemmän, koska työ pääosin samassa tilassa (vähemmän tarvetta)

8. Työtunnit henkilöittäin – iteraatio Toteutuneet tunnit I1-vaiheessa henkilöittäin • Ylityksen syynä • Päätettiin käyttää enemmän aikaa • Toteutuksen arviot huonoja, tarkentuvat kun tiedetään tekijöiden nopeus • Jaakolla ja Markolla ylitys oli arvattavissa • Olli, Markon työkiireiden ja sairastumisen takia joutui panostamaan enemmän toteutukseen kuin suunniteltu • Miika, testausta tehtiin vähemmän kuin suunniteltu • Huom. SEPA tunnit ei taulukossa (ei projektin tunteja, erilliset 10 h)

9. Työtunnit henkilöittäin - projekti Toteutuneet tunnit I1-vaiheessa Suunnitelma iteraation alussa • Syy eroihin: toteutus ja FD-vaiheen pienennys • 55 % projektin ajasta käytetty • I1 iteraatiossa 33 % tunneista (tiukka rytmi) • Huom. SEPA tunnit ei taulukoissa Viimeisin suunnitelma

10. Laatumetriikat • Löydettyjen vikojen määrä testipakettia kohden:vain yksi testipaketti (ei järkevä mittari tässä tilanteessa) • Virheettömästi suoritettujen testitapausten määrä suhteessa suoritettuihin testitapauksiin kierroksittain • 1.kierros: 3/9 (33%) • 2.kierros: 7/13 (54%) • 3.kierros: 11/13 (85%)

11. Laadun arviointi • Järjestelmä testattiin huolellisesti • Dokumentteja ei katselmoitu tässä iteraatiossa Selite Kattavuus: 0 = ei mitään 1 = katsottu läpi 2 = katsottu tarkasti läpi 3 = testattu Laatu: J = hyvä K = epävarma L = huono

12. Ohjelmiston koko (koodirivejä) • Koodin teko keskittyi demoa edeltäneelle ajalle (kuten oli tarkoitus) • Loppuvaiheessa viimeistelyä • Eniten koodia tekivät Jaakko, Olli ja Marko (>20% per hlö)Riku, Otto, Atte vähemmän (~10% per hlö) • Alla oleva kuva kertoo rivien määrän muutoksen I1:n aikana(mukana kaikki tuotteeseen (ei dokumenttien) tiedostot, myös tyhjät rivit)

13. Muutokset projektiin • Havaittiin puutteita käyttötapausten määrittelyssä • Varausten poisto (oli vain lisäys) • I1:ssä toteuttamatta jääneet toiminnallisuudet siirtyvät I2:een • UC4,6 (testausprojektit) • UC15-17 (resurssien hallinta)

14. Riskit • Top10 lista, jossa hallintatoimenpiteet ja vastuuhenkilöt • Palvelimeen liittyvä riski poistettu • korvattu toteutustekniikkaan liittyvällä riskillä • 2 riskiä toteutui I1:ssä • Ryhmän jäsenen sairastuminen (Marko – arkkitehti) • Toteutustekniikan outoudesta ongelmia • Pidettiin koulutusta • Mutta mallitoteutus ja ohjeet puutteellisia=> Hukattiin puoli viikkoa • Havaittiin ongelma ja korjattiin ”väärin” tehty koodi

15. Iteraation tulokset • Laadunvarmistusdokumentit • Tekninen määrittely • Järjestelmän demo • Sisäänkirjautuminen • Varaustilanne • Uuden asiakasprojektin luonti • Asiakasprojektin tietojen katsominen/hallinnointi • Resurssivarausten teko/poisto • Käyttöohje

16. Tekninen määrittely • Järjestelmän yleiskuvaus • Kerrosmallinen rakenne • Vuonohjaus järjestelmätasolla • Kehityskäytännöt • Käyttöliittymä • JSP-sivujen toiminta • Vuonohjaus JSP-sivuille ja –sivuilta • Tagien käyttö sivujen rakentamisessa • Toiminnallisuuskerros • Servletit • Tagit • Tietokantakerros • DAO-malli • Dataentiteetit • Puuttuvat osiot • Kuvaus järjestelmätason turvallisuusratkaisuista • Tarkempi kuvaus servletien turvakäytännöistä • Yksityiskohtaiset tagikuvaukset

17. Järjestelmän demo • Järjestelmän demo • Sisäänkirjautuminen • Varaustilanne • Uuden asiakasprojektin luonti • Asiakasprojektin tietojen katsominen/hallinnointi • Resurssivarausten teko/poisto • Sääennuste, käyttöohje • Uloskirjautuminen

18. Kokemukset I1-vaiheen käytännöistä (1/2) • Iteratiivinen kehitys • Sisäiset tarkistuspisteet havaittiin tärkeiksi • Viimeinen viikko viimeistelyä erittäin hyödyllinen • Iteraation suunnittelu • Laadunvarmistussuunnitelma teetti töitä • Tuntiraportointi • Selkemmät tehtävät kuin aiemmin, ohjeet wikissä • Trapolin tehtävät pilkottiin pienemmiksi, seuranta wikissä • Raportointi ajantasalla, ei ongelmia • Dokumentointi • Käyttöohjetta ja teknistä määrittelyä tehtiin rinnan toteutuksen kanssa • Projektikatselmoinnit • Huolellinen valmistautuminen tekee tilaisuudesta sujuvan • Vaatimustenhallinta • Havaittiin muutama uusi vaatimus • seuranta järjestelmään navigaatiokartan avulla • Versionhallinta • cvs siirrettiin asiakkaan palvelimelle, sen jälkeen toiminut hyvin • Iteraation alussa rikki olevaa koodia -> rangaistusuhka esti toistumisen • Riskienhallinta • Riskienhallinta toimi kuten aiemmin

19. Kokemukset I1-vaiheen käytännöistä (2/2) • Prototyyppi • Toimi erinomaisesti käyttöliittymän määrityksenä • Helpotti kommunikointia ryhmän sisällä • I1:ssä lisättiin resurssien hallinnointi, mutta sitä ei toteutettu • Kommunikointi • Toimi paremmin kuin PP-vaiheessa • Tikiwiki ja irc aktiivisessa käytössä • Paljon työtä samassa tilassa ohjelmatyöluokassa -> nopea kommunikointi • Kokouskäytännöt (SEPA) • Kokoukset edelleen ilman ongelmia, tarkemmat kokemukset sepassa • Automatisoitu yksikkötestaus (SEPA) • Toimi tietokantaluokkien osalta hyvin • Muuten käytettiin vähemmän kuin oli tarkoitus • korjataan I2:ssa, syy DAOFactory ei rajapinta -> vaikea tehdä testejä • Heuristinen arviointi (SEPA) • Hyödyllinen, ongelmat löytyivät ennen toteutuksen aloittamista • Kaikkia arvioinnin hyötyjä ei saatu irti, koska toteutettavia ominaisuuksia karsittiin I1:ssä • Suunnittelumallit (SEPA) • Sovellettiin erityisesti tietokantakerroksen suunnittelussa • Bisneslogiikkakerroksessa toteutus aloitettiin ennen suunnittelua -> aluksi ongelmia • Koodauskäytäntö (Java) • Eclipse käytännössä pakottaa oikean tyylin • Väliaikaisesti esiintyi vakioita koodin seassa eikä yhteen paikkaan kerättynä • Vikojen seuranta (Bugzilla) • Järjestelmätestauksessa löydetyt viat ja niiden korjaukset bugzillassa • Bugzillaa käytetään myös koekäytön aikana

20. Kiitos ! • Kysymyksiä? • Kommentteja?