T-76.115 Projektikatselmus

1. T-76.115 Projektikatselmus fifty-sixty Iteraatio 11.12.2004

2. Projektin tilanne (15min) I1-vaiheen tavoitteiden saavuttaminen Palautettavien dokumenttien tila Toteutuneet tehtävät Työtunnit henkilöittäin Muut mittarit Muutokset projektiin Riskit Iteraatiovaiheen tulokset (20 min) Palautettavat dokumentit Tekninen määrittely Testidokumentaatio Päivitetyt dokumentit Projektisuunnitelma Vaatimusmäärittely SEPA-päiväkirjat Muut dokumentit Käyttöliittymähahmotelmat Käyttöliittymähahmotelmien heuristinen testaus Toteutetut järjestelmät www-palvelu (tärkeimmät käyttötapaukset toteutettu) Mobiilikäyttöliittymä (tärkeimmät käyttötapaukset toteutettu) Käytetyt työmenetelmät (5 min) Kysymyksiä (5 min) Agenda

3. Projektin esittely • Prediction League -projekti on osa Helsinki Institute for Information Technologyn (HIIT) Mobile Content Communities (MC2) tutkimusprojektia, jossa tutkitaan mobiilipelejä ja niihin liittyviä ilmiöitä. • Ideana on yhdistää veikkaaminen, siihen liittyvä sosiaalinen kanssakäynti ja mobiliteetti. • Tavoitteena on rakentaa veikkausliigajärjestelmä, jonka avulla yhteisöt voivat pystyttää omia veikkausliigojaan haluamistaan kohteista ja seurata niiden etenemistä www-selaimen avulla ja soveltuvin osin myös mobiilisti. Internet

4. Suunnitteluvaiheen tavoitteiden saavuttaminen • Veikkauspalvelimen pystyttäminen (OK) • Palvelu pystytetty varapalvelimelle. • www-käyttöliittymän rakentaminen (OK) • rekisteröityminen/profiilin luominen/profiilin muokkaaminen • sisään/uloskirjautuminen • pääliigawizard • veikkauskohteen lisääminen pääliigaan • pääliigan veikkauskohteiden selaaminen ja veikkaaminen • veikkausten tulosten katsominen • Puhelinkäyttöliittymän rakentaminen (OK) • yhteysprofiilin rakentaminen • sisään/uloskirjautuminen • pääliigan veikkauskohteiden selaaminen ja veikkaaminen • veikkausten tulosten katsominen • Teknisen määrittelyn laatiminen (ainakin yleinen arkkitehtuuri) (OK) • Yleinen arkkitehtuuri laadittu, tarkennetaan vielä projektin edetessä. • Järjestelmällisen testauksen aloittaminen (OK) • www-puoli testattu neljässä eri ympäristössä: Mozilla (Win+Linux), IE (Win), Opera (Win) • Mobiilipuoli testattu Nokia 6600 –puhelimella. • Testiraportin laatiminen (OK) • Laadittu testien perusteella. • Laatusuunnitelman laatiminen (OK) • Päivitetty projektisuunnitelmaan. • Käyttöliittymähahmotelmien heuristinen testaaminen (OK) • Toteutettiin kolmen henkilän ryhmässä. • Henkilökohtaisten harjoituspäiväkirjojen (SEPA) täydentäminen (OK) • Kaikista aiheista harjoituksen suunnitteluosuus kirjoitettu. • SEPA-aiheiden hyödyntäminen (refactoring, static methods, meeting practices) (OK) • Tapaamiskäytännöt otettiin käyttöön jo suunnitteluvaiheessa. Jatkuu läpi projektin. • www-puolella refaktorointi aloitettu. • Staattisten menetelmien soveltaminen aloitettu mobiilipuolen Java-koodiin.

5. Palautettavien dokumenttien tila • Iteraatiosuunnitelma • OK. Palautettu 9.11.2004 • Tekninen määrittely • OK. Yleinen arkkitehtuuri ja kaavioita. • Mobiilikäyttöliittymän osalta tarkennetaan pikapuoliin. • Testi-caset • OK. Testimatriisi tehty ja testit suoritettu. • Testiraportti ja –loki • OK. Testiraportti ja –loki kirjoitettu. • Projektisuunnitelma (päivitetty) • OK. Kulutettujen työtuntien osalta päivitetty. • Laatusuunnitelma päivitetty • Iteraation 1 –suunnitelma lisätty. • Riskilokia päivitetty. • Muutamia muitakin kappaleita päivitetty (mm. rooleja tarkennettu) • Vaatimusmäärittely (päivitetty) • OK. • Henkilökohtaiset harjoituspäiväkirjat (SEPAt) • OK. Kaikista aiheista tehty luku 2, eli harjoitussuunnitelma • Refactoring ja static method -aiheita myös sovellettu • Hallinnolliset dokumentit • Agendat ja muistiot tapaamisista löytyvät projektiryhmän kotisivulta

6. Toteutuneet tehtävät • Tapaamisiin kului paljon suunniteltua vähemmän työtunteja (~ 20 h) • Kaikki ryhmästä eivät päässeet aina paikalle esim. yllättävien työesteiden takia • Kaikkia ei aina tarvittu (esim. asiakaskatselmoinnit) • Tehokkaat tapaamiset • Käyttötapausten ohjelmoinnin kohdalla heilahteluja tasaisesti molempiin suuntiin • Työtuntien tarkka arviointi mahdotonta etukäteen • Kokonaisuudessaan ohjelmointityön arviointi osui kuitenkin aika lähelle • SEPA-päiväkirjoihin kulutettiin aikaa suunniteltua vähemmän (~ 7 h) • Laadunvalvontaan ja dokumentointiin kulutettiin suunniteltua vähemmän aikaa • mm. dokumenttien laatuarvioinnit (~ 7 h) • heuristinen testaus sujui odotettua nopeammin ja tehtiin suunniteltua pienemmällä porukalla

7. Työtunnit henkilöittäin Suunnitelma I1-vaiheen alussa I1-vaiheen toteutuneet tunnit • Ohjelmointiryhmällä (sinisellä) toteutuneet työtunnit lähellä suunniteltua. • Hienoinen ylitys selittyy sillä, että ohjelmointiryhmä teki osittain jo seuraavankin vaiheen kohtia. • Testaus- & laaturyhmällä (vihreällä) toteutuneita tunteja suunniteltua vähemmän • Poissaoloja tapaamisista (mm. työkiireet) • Dokumenttien kirjoittamiseen kului aikaa suunniteltua vähemmän • Viimeisimmät I1-vaiheen tunnit eivät ehtineet mukaan tähän dokumenttiin • Jatkossa • Perustoiminnot on rakennettu, joten ohjelmointitehtäviä on helpompi jakaa • Ryhmässä jaetaan hommia myös joulukuulle, jolloin työt eivät kasaannu Viimeisin suunnitelma

8. Suunnitellut vs. toteutuneet työtunnit • Oikealla puolella suunnitellut tunnit, vasemmalla puolella toteutuneet tunnit • Keltaisella projektipäällikkö, vihreällä laatu- & testausryhmä ja sinisellä ohjelmointiryhmä • Ohjelmointiryhmällä (sinisellä) toteutuneet työtunnit lähellä suunniteltua. • Hienoinen ylitys selittyy sillä, että ohjelmointiryhmä teki osittain jo seuraavankin vaiheen kohtia. • Testaus- & laaturyhmällä (vihreällä) toteutuneita tunteja suunniteltua vähemmän • Poissaoloja tapaamisista (mm. työkiireet) • Dokumenttien kirjoittamiseen kului aikaa suunniteltua vähemmän • Viimeisimmät I1-vaiheen tunnit eivät ehtineet mukaan tähän dokumenttiin • Jatkossa • Perustoiminnot on rakennettu, joten ohjelmointitehtäviä on helpompi jakaa • Osa ryhmästä jakaa hommia myös joulukuulle, jolloin työt eivät kasaannu

9. Työtunnit henkilöittäin

10. Laatumittarit Bugimittarit • www-käyttöliittymä testattiin neljässä eri ympäristössä, mobiili yhdessä • Bugiraportointiin käytetään Bugzillaa • Estäviä ja kriittisiä bugeja ei löydetty järjestelmätestauksessa • www-käyttöliittymästä löydettiin kolme suurta bugia, joista kaksi on jo korjattu: • Pääliigaa luodessa ei tapahtunut mitään • Pääliigan tuhoamisen jälkeen sen luominen ei onnistunut uudelleen virheettömästi • Mobiilikäyttöliittymässä kaikki testit menivät toistaiseksi virheettömästi läpi • Java-koodeja analysoitiin staattisesti myös Jlint ja CCCC-ohjelmilla. (osa SEPA-harjoitusta) • Jlint havaitsi synkronointiongelmia, mitkä eivät tulleet testien avulla esille • Ote CCCC:n raportista oheisessa kuvassa: • PHP ja HTML-koodit toteutettiin pariohjelmoinnilla

11. Laadun arviointi • Testattiin lähinnä toteutettujen käyttötapausten perustoiminnallisuutta ja testit laadittiin siltä pohjalta. • Testien suorittaminen hyvin suoraviivaista ja nopeaa, aikaa kului yhteensä arviolta 12,5 h • Syötevirheiden käsittely monilta osin vielä toteuttamatta, joten niistä ei vielä erityisemmin huomautettu. • Iteraation tavoitteisiin nähden laatu hyvää. Selitykset Kattavuus: 0 = ei mitään 1 = katsottu pikaisesti 2 = kaikki toiminnot tarkastettu 3 = testattu Laatu: J = hyvä K = ei varmuutta L = huono

12. Ohjelmakoodin pituus (LOC) (suluissa koodin määrä ennen refaktorointia) • www-käyttöliittymä • Koodeja tutkittiin refaktoroinnin yhteydessä. Erillistä työkalua ei käytetty ohjelmakoodin laskemiseen vaan laskettiin käsin • 33 tiedostoa • 4038 riviä koodia, joista n. puolet HTML-koodia ja puolet PHP-koodia. • 463 riviä kommentteja • refaktoroinnin jälkeen koodin määrä putosi 3644 riviin (n. -10%) ja kommenttien määrä kasvoi 1020 riviin (n. +120%) • Mobiili käyttöliittymä • Java-koodeja tutkittiin CCCC-työkalulla, yksityiskohtaisempaa tietoa SEPA-dokumentissa (Static methods, Jeremias Raime ja Ari Kuvaja) • Moduuleja 39 • 1942 riviä Java-koodia (ilman kommentteja) • 337 riviä kommentteja • Huomioita • Koodaus on ollut tehokasta • Trapolin mukaan 113h oli kulutettu ohjelmointiin  ~57 riviä koodia/h (ennen refaktorointia) • Jos huomioidaan pariohjelmointi www-käyttöliittymää koodatessa, nopeus kasvaa raa’alla arviolla n. kolmasosan eli n. 85 riviä/h

13. Muutokset projektiin • Veikkausjärjestelmä rakennettiin toistaiseksi testipalvelimelle, koska asiakkaalta (HIIT) ei olla saatu palvelinta. • Ryhmä päätti jakaa joitakin sopivia tehtäviä myös joulukuulle, jolloin I2-vaiheeseen jää paljon enemmän aikaa. • Ryhmän jäsenet kaikki työelämässä -> helpottaa I2-vaiheen kuormaa • I2-vaihe suunnitellaan yhdessä asiakkaan kanssa ja joulukuun aikana toteutettavista asioista sovitaan etukäteen.

14. Riskit • Riskilokissa on edelleen 23 suunnitteluvaiheessa havaittua riskiä, jotka pidetään ajan tasalla. • Tapaamisten yhteydessä kerrataan oleellisimpien riskien tila. Uusista mahdollisista riskitekijöistä keskustellaan, jos/kun niitä kohdataan. • Ajankohtaisia riskejä I1-iteraation jälkeen mm.: • Asiakas ei toimita palvelinta • Palvelimessa ei ole kunnollista varmuuskopiointia • Asiakkaan mielikuvat/mielipiteet toteutettavasta järjestelmästä poikkeavat ryhmän mielipiteistä • Työtunnit eivät jakaudu tasaisesti ryhmän jäsenien kesken • Näille riskeille hallinta: • Nykyisestä varapalvelimesta joudutaan luopumaan vuoden loppuun mennessä. Ryhmä asentaa oman palvelimen kotikoneelleen projektin ajaksi • Muokatut tiedostot pidetään aina ajan tasalla kahdessa eri paikassa (eri koneilla, eri rakennuksissa) • Kokonaiskuvaa on hahmoteltu jo alussa mm. skenaarioiden avulla ja käyttöliittymähahmotelmia on rakennettu • Tehtäviä jaetaan monipuolisesti. Ohjelmointitehtäviä kaikille.

15. I1-vaiheen tulokset • Palautettavat dokumentit • Tekninen määrittely • Testidokumentaatio • Päivitetyt dokumentit • Projektisuunnitelma (Erit. laadunvarmistussuunnitelma) • Vaatimusmäärittely • SEPA-päiväkirjat • Muut dokumentit • Käyttöliittymähahmotelmat • Käyttöliittymähahmotelmien heuristisen testausten tulos • Toteutetut järjestelmät • www-palvelu (tärkeimmät käyttötapaukset toteutettu) • Mobiili käyttöliittymä (tärkeimmät käyttötapaukset toteutettu)

16. Tekninen määrittely • Yleinen arkkitehtuuri kirjoitettu. Dokumenttia päivitetään projektin edetessä • Järjestelmän tekniset vaatimukset esitelty • Apache, PHP, MySQL • www-selain • J2ME/MIDP2.0 • GPRS/GSM-data tai vastaava • Kaavio käsitteiden välisistä suhteista ja riippuvuuksista (ks. kuva) • Yksityiskohtainen kuvaus moduuleista • Moduuleiden välisistä suhteista kaavio • Tietokanta-arkkitehtuurin kuvaus • Yksityiskohtainen ER-kaavio tietokannasta • Mobiilikäyttöliittymän rajapinnan kuvaus • Mobiilipuolen osalta tarkennetaan I2-vaiheen alussa Käsitekaavio

17. Testidokumentaatio • Testi-caset täydennettyinä testimatriisissa (Excel-tiedosto) • Testiraportti kirjoitettu testien pohjalta • Lokiin listattu 11 löydettyä bugia, jotka syötetty myös Bugzillaan

18. Päivitetty projektisuunnitelma • Laadunvarmistussuunnitelmaan päivityksiä • I1-vaiheessa testataan lähinnä toteutettujen käyttötapauksien perustoimintaa. • Kriittisiä ja merkittäviä virheitä ei saa olla vaiheen lopussa. • Testitapaukset on jaettu neljään eri ryhmään: • www-rekisteröityminen (käyttötapaukset K10-12) • Liigan hallinta (käyttötapaukset K20, K22, K26-27) • Näkymän hallinta (käyttötapaus K30) • Mobiililiittymä (käyttötapaukset K40-44) • Kriittisten virheiden korjaamisen jälkeen testit suoritetaan aina uudestaan, kunnes virheitä ei enää löydy (tai aika loppuu). • Korjaamisesta vastaa virhevastaava • Riskilogi päivitetty (mm. kriittisyys, lisätoimenpiteet) • Työtuntitaulukko päivitetty • Projektiryhmän jäsenten roolit kirjoitettu auki selkeämmin

19. Päivitetty vaatimusmäärittely • Vaatimusmäärittelyyn tehtiin muutoksia suunnittelun järjestelmään nähden. • Muutostarpeet tulivat ilmi: • käyttöliittymähahmotelmien tarkastelussa • heuristisissa testeissä • testauksessa • järjestelmän läpikäynnissä asiakkaan kanssa • Tehdyt muutokset: • Käsitteet päivitetty englanniksi • Yhteysprofiilin käyttötapaus ja vaatimus lisätty • Käyttäjäryhmät päivitetty englanniksi • Lisätty käsitteet sarja ja joukkue • Päivitetty käsitteet sarja ja joukkue kuvaukseen • Päivityksiä käyttötapauksiin wizard ja liigapohjan osalta (yhdistetty) • Käyttötapausten tilat ja testaukset päivitetty

20. SEPA-päiväkirjat • Käytössä: • Refaktorointi (Heikki Salomäki & Mikko Nurmi) • Staattiset metodit (Ari Kuvaja & Jeremias Raime) • Tapaamiskäytännöt (Heikki Suhonen) • Otetaan mukaan seuraavassa iteraatiossa: • Käyttäjätestaus (Anttoni Halme & Atte Järvinen)

21. Käyttöliittymähahmotelmat • Tehtiin kaikista iteraatiossa toteutettavista käyttötapauksista • rekisteröityminen/profiilin luominen/profiilin muokkaaminen • sisään/uloskirjautuminen • pääliigawizard • veikkauskohteen lisääminen pääliigaan • pääliigan veikkauskohteiden selaaminen ja veikkaaminen • veikkausten tulosten katsominen

22. Käyttöliittymähahmotelmien heuristinen testaus

23. Toteutetut järjestelmät • www-palvelu (tärkeimmät käyttötapaukset toteutettu) • Mobiilikäyttöliittymä (tärkeimmät käyttötapaukset toteutettu) • [ERILLINEN DEMO]

24. Käytetyt työmenetelmät Oleelliset käytetyt työmenetelmät: • Iteratiivinen kehitys • ”Mopo pysyy käsissä”, kun ei tarvitse miettiä liikaa asioita kerralla • Iteraation suunnittelu • + Huolellinen suunnittelu erittäin hyödyllistä erityisesti ajankäytön kannalta. • + Sisäisten deadline-aikojen asettaminen ja katselmoinnit auttavat eri vaiheiden valmistumisessa • Tuntiraportointi • - Järjestelmän huolellinen käyttäminen vie todella paljon aikaa • + Tuntiraportit ovat iteraatioiden suunnittelun kannalta hyödyllisiä • - Onko jopa haittaa enemmän kuin hyötyä?! • Dokumentointi (dokumenttipohjat ryhmän sivuilla netissä) • + Yhdenmukaisia dokumentteja on huomattavasti helpompaa lukea • Riskienhallinta • Uusia riskejä ilmennyt vähän • Suurin riski tällä hetkellä palvelimen kohtalo • Tapaamiskäytäntö ja yhteydenpito (tapaamiskäytännöt SEPA-harjoituksesta, yhteydenpitoon sähköposti) • + Tapaamiset ovat olleet tehokkaita, osin töiden ansiosta • - Työelämä häiritsee läsnäoloja • Yllättäviä työmenoja ja kiireitä tulee aina • Työmenot kuitenkin ymmärrettävästi etusijalla ja tapaamisista on välillä myöhästyttävä tai skipattava ne kokonaan • Virheraportointi (Bugzilla) • + Järjestelmä on helppokäyttöinen • + Ei ongelmia tähän asti (ehkä siksi, että ei myöskään kriittisiä virheitä..) • TikiWiki • Aivan liian hankala ja buginen järjestelmä • Sähköpostin käyttö tehokkaampaa, koska kaikki ovat yleensä sen tavoitettavissa työpaikoillaan. • Ohjelmointikäytännöt (noudatetaan Java, PHP ja HTML-kielien yleisiä käytäntöjä) • + Koodia on huomattavasti helpompi korjata. • - Kommentoinnissa kirittävää • Heuristiset menetelmät • + Www-puolen käyttöliittymähahmotelmien analysointi Nielsenin heuristiikoilla säästi työtä

25. The End- Kysymyksiä?