EDISTYMISRAPORTTI - T2 Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen
i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 1.1. Yleistä 2 1.2. Resurssit 2 1.3. Laatu 4 2. SUORITETUT TEHTÄVÄT 6 2.1.1. Projektisuunnitelma 6 2.1.2. Dokumenttienhallintasuunnitelma 6 2.1.3. Testaussuunnitelma 6 2.1.4. Testiraportit 6 2.1.5. Toiminnallinen määrittely 6 2.1.6. Tekninen määrittely 7 2.1.7. Tekninen dokumentointi (API) 7 2.1.8. Käyttöliittymä demo 7 3. ONGELMAT 8
1(8) Dokumentin versiot Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 Antti Tuomaala 8.12.2000 Alkuperäinen versio 1.1 Antti Tuomaala 11.12.2000 Täydennetty versio 1.2 Harri Kauhanen 11.12.2000 Tarkennettu laatuosiota, lisätty pari puuttuvaa dokumenttia ja kommentit päälle. Harri Kauhanen
2(8) 1. Projektin tila 1.1. Yleistä Projektin T2- vaiheessa päästiin jo toteuttamaan käytännössä tulevan systeemin runkoa. Suunnittelussa oltiin edetty jo T1- vaiheessa niin pitkälle, että systeemin rakenne oli jo melko hyvin selvillä, joten moduulien rakentelu voitiin aloittaa. Alkuperäisen suunnitelman mukaan myös tietokannan piti olla integroituna systeemiin, mutta tätä ei kuitenkaan pystytty toteuttamaan. Tällä hetkellä on rakennettu demoamismielessä ns. kovakoodattu tietokanta. Kaikki vaadittavat dokumentit saatiin tuotetuiksi (enemmän kappaleessa 2). Käytännön asioissa edellisessä vaiheessa eniten ongelmia tuotti tuntiraportointi. Vaikka erilaisia pakotteita asetettiin tuntikirjanpitoon, tämä ei vain edelleenkään luonnistunut aivan toivotulla tavalla, mutta ehdottomasti paremmin kuin T1- vaiheessa. Edelleen kokoukset ovat menneet hyvin ja asia sisällössä on pysytty erittäin hyvin. Myöhästelyt kokouksista ovat pikemminkin sääntö kuin poikkeus. Käytännössä, jokainen kokous alkaa 5 10 minuuttia myöhässä.. Myöhästymisistä on toisaalta aina ilmoitettu erikseen. 1.2. Resurssit Seuraavissa taulukoissa on esitetty toteutuneet ja suunnitellut tunnit. Ylimääräiset tunnit näkyvät erotus valikossa ei-negatiivisina. Task Name Suunniteltu Toteutunut Erotus ID 41 TOTEUTUS 2 (T2) 250 252 2 42 T2: Opinnot 37 17-20 130 T2: OP: Java 13 16 3 131 T2: OP: Testaus 4 1-3 43 T2: OP: Pattern Recognition 20 0-20 44 T2: Ryhmäpalaverit 38 31,5-6,5 45 T2: Asiakaspalaverit 20 5-15 46 T2: Toiminnallinen määrittely 10 6-4 47 T2: TOIM.MÄÄR: Toiminallisen määrittelyn dokumentin 10 6-4 tarkennus 49 T2: JÄRJ.SUUN: Teknisen määrittelyn dokumentin tarkennus 15 5-10 50 T2: Koodaus 72 114 42 126 T2: KOOD: Tietokannat 10 13 3 125 T2: KOOD: Portaali ja ylläpito käyttöliittymä 20 75 55 51 T2: KOOD: AMOK 42 26-16 52 T2: Testaus 33 25-8 53 T2: TEST: Testaussuunnitelman kirjoittaminen 10 12 2 123 T2: TEST: Systeemin testaaminen 15 8-7 54 T2: TEST: Testausraportin kirjoittaminen 8 5-2
3(8) Task Name Suunniteltu Toteutunut Erotus ID 122 T2: Projektin hallinta, tiedotus, kokouspöytäkirjat yms. 5 3-2 55 T2: BURANA-raporttien toteutus 0 0 0 128 T2: Vanh: Projektisuunnitelman päivitys 2 2 2 57 T2: Seuraavan vaiheen tarkka suunnittelu 5 7 2 58 T2: Edistymisraportin kirjoittaminen 2 2 0 59 T2: Katselmuksen valmistelu 6 4,5-1,5 60 T2: Katselmus 5 n.5 0 Kuten taulukosta voidaan todeta, niin kokonaistuntimäärän suunnitellut tunnit ovat onnistuneet erittäin hyvin, T1- vaiheeseen verrattuna oikeastaan loistavasti. Tähän vaiheeseen oli suunniteltu käytettäväksi kaikista vaiheista eniten tunteja eli 250 tuntia. Tämänkin asian huomioon ottaen tuntiarviointi meni erittäin hyvin. Ikävä kyllä ainoastaan kokonaistuntimäärän arviointi meni hyvin. Erilaiselle yksityisille tehtäville suunnitellut tunnit vaihtelivat melkoisesti. Suurin heitto, oli systeemiin toteuttamiseen eli koodaamiseen varattua aika. Tässä tehtiin 42 ylimääräistä tuntia, eikä tietokantaa saatu siltikään valmiiksi, joka oli ollut tämän vaiheen tarkoituksena. Se miksi koodaamiseen sujui näinkin paljon aikaa oli, että tässä vaiheessa eräät projekti ryhmän henkilöt tutustuivat vapaaehtoisesti uuteen tekniikkaan, jota jouduttiin opettelemaan mm. yritys erehdys periaatteella. Itse VYM koneen algoritmien suunnitteluun varattiin aikaa, mutta nämä tunnit jäivät kokonaan käyttämättä. VYM koneen tarkempi rakenne voidaan suunnitella tarkemmin seuraavassa vaiheessa. Testaamiseen suunniteltiin 33 tuntia, mutta käytettiin 25 eli 8 tuntia olisi vielä voitu allokoida testaamiselle. Koska tietokantaa ei saatu integroiduksi systeemiin, yksinkertaistui testaus pelkäksi moduulitestaukseksi. Tulevissa vaiheissa testattavaa tulee varmasti enemmän. Työn jakaantuminen henkilöittäin: Nimi Suunniteltu Toteutunut Erotus Antti Tuomaala 37 79,5 +42,5 Harri Kauhanen 50 65,5 +15,5 Juha Parhankangas 35 60 +25 Niko Stenberg 69 42,5-26,5 Tuomo Marttila 53 17-36 Työ jakaantui henkilöittäin epätasaisesti, kukaan ei oikeastaan päässyt lähellekään suunniteltuja tuntimääriä. Eniten tunteja oli suunniteltu Nikolle ja Tuomolle. Molempien tuntimäärien heitot liittyvät tavallaan toisiinsa. Tuomon henkilökohtaisten kiireitten takia tietokantaa ei pystytty rakentamaan, joka toisaalta vähensi myös Nikolle suunniteltua systeemin testaamista. Tässä toteutui projektisuunnitelmassa kartoitettuja riskejä. Riski ajan käytön ongelmat toteutui selkeästi. Ehkäisevissä toimenpiteissä määriteltiin, että projekti tulee ottaa tietyllä vakavuudella ja työesteistä tulee ilmoittaa hyvissä ajoin projektipäällikölle. Ensimmäiseen ei voi oikeastaan vaikuttaa, mutta jälkimmäisellä olisi voitu hyvin allokoida esimerkiksi Tuomon resursseja Nikolla. Tämä oli selkeä
4(8) ennakkotoimenpiteen tekemättä jättäminen, jota tullaan painottamaan seuraavissa vaiheissa. Tämä riski liittyy oleellisesti myös riskiin työmäärä jakaantuu vain tietyille henkilöille. Sen mukaan projektipäällikön tulisi järjestää apuvoimia henkilöille, jonka työmäärä kasvaa liian suureksi. Tätä ei pystytty tekemään, koska ennakko ilmoituksia työtaakoista ei tullut, ne yksinkertaisesti vain huomattiin. 1.3. Laatu Laatukatselmuksien teko oli tällä kertaa hieman laaduton. Osin tästä voi syyttää laatuvastaavan ja muunkin ryhmän kiireitä vaiheen loppupuolella. Toisaalta se voisi olla vain osoitus siitä, että tuotantoprosessi ei ole riittävän laadukas (toisaalta taasen aikataulut ovat epätodellisen tiukat kurssin luonteesta johtuen). Seuraavat ongelmat kuitenkin todettiin: Osa-alue Todetut ongelmat Korjausehdotukset Dokumentointi Sisällöllisesti dokumentointi on kohtuullisen Word ohjeistusta hyvää. Asiat löytyvät suuri- piirtein sieltä mistä niiden voisi olettaa löytyvän ja tyhjä paskan jauhaminen on vähäistä. Korjattavaa: Dokumenttien tarkennus Teknisen dokumentoinnin jotkut kappaleet liiankin lyhyitä. Ainakaan satunnaiselle lukijalle ei sisältö avaudu. Toiminnallisen määrittelyn tapaukset eivät ole aina yksiselitteisiä toiminta normaalitapauksessa on esitetty, mutta toimintaa virhetilanteissa ei aina esitetä. Word:n ominaisuuksia on käytetty paikoin huonosti. Esim. muotoilua on yritetty tehdä tabulaattorein, jolloin teksti helposti menee sekaisin. Kenttäkoodeja tai wordin ristiviittauksia ei ole osattu aina käyttää.
5(8) Osa-alue Todetut ongelmat Korjausehdotukset Lähdekoodi Vaiheen alkuvaiheessa sovittuja koodikatselmuksia ei tehty siinä laajuudes- lisää ohjeistusta koodikatselmuksille sovitaan sa kuin suunniteltiin. Osa pareista katselmoi pikaisesti koodia ja laatuvas- päivämäärät T3 vaiheessa taava teki yleiskatsauksen. Tärkeämpää osaa koodikatselmusta eli loogista toimintaa ei ole katselmoitu. Seuraavat asiat ovat tähän verrattuna vähempiarvoisia, mutta näilläkin on merkitystä lopullista laatua arvioitaessa. Seuraavia asioita voidaan todeta: package, luokkien ja metodien nimeämiset OK. Muuttujien nimeämisessä oltu hieman laiskempia, mutta yleensä ei tarvitse arvailla nimien merkitystä. sisennyksissä ei ole aina käytetty neljää välilyöntiä, vaan usein myös tabulaattoria JavaDoc kommentointi puuttuu jostain kokonaan, vaikka luokan rakennus pitäisi aloittaa enemminkin juuri dokumentoinnilla kuin itse koodin kirjoittamisella (osa suunnittelua). @version tag pitäisi olla versionhallinnan $id$, ei itse keksitty (tätä ei ole ohjeistettu!!!) metodien järjestys ei aina mene suositellun public, protected, private mukaan Suunnittelu Pieniä ongelmia havaittu suunnittelun ja toteutuksen välillä. Esimerkiksi suhde XML DTD kanta sisäiset tietorakenteet eivät ole olleet täysin yhteneväisiä. Esimeriksi sisäisiin UI luokkiin toteutettiin ominaisuuksia, joita DTD ei määrittele. Kannan ja sisäisten tietorakenteiden nimeäminen on jo yhtenäistetty. Suunnittelua on joiltakin osin laiminlyöty ja on lähdetty toteuttamaan joitakin luokkia ilman suunnittelua. Yksinkertaisissa tapauksissa tämä voi olla perusteltuakin, mutta kokonaisuuden kannalta tämä voi kostautua, jos liian isoja kokonaisuuksia lähdetään näin toteuttamaan. toteutuksessa pitäydyttävä tarkemmin suunnitelmissa, dokumentteja ei ole tehty vain palautuksia varten, vaan työkaluiksi jatkoa varten suunnitteluun suhteessa lisää aikaa
6(8) 2. Suoritetut tehtävät T2 vaiheessa projektiryhmä sai valmiiksi seuraavat dokumentit 2.1.1. Projektisuunnitelma http://hazard.iki.fi/vym/palautukset/t2/projektisuunnitelma.pdf Projektisuunnitelmaan lisättiin tärkeimpänä asiana lyhyt esittelyteksti helpottamaan dokumentin yleiskuvaa. Seuraavan vaiheen tunnit tarkennettiin tarkoiksi ja erilliset tehtävät määrättiin MS project tiedostoon. 2.1.2. Dokumenttienhallintasuunnitelma http://hazard.iki.fi/vym/palautukset/t2/dokumenttienhallintasuunnitelma.pdf Ennen kuin päästiin koodaamaan, niin sovittiin koodaukseen liittyvistä käytännöistä ja tarkennettiin käytettäviä työkaluja. Dokumenttienhallintasuunnitelmaan lisättiin uusi luku, joka käsittelee ohjelmointikäytäntöjä ja sen osa-alueita: työkalut versionhallinnan käytännöt lähdekoodin käytännöt 2.1.3. Testaussuunnitelma http://hazard.iki.fi/vym/palautukset/t2/testaussuunnitelma.pdf Muodostuvan tuotteen yleinen testaussuunnitelma. Sen tarkoitus on toimia runkona ja viitteenä testiprosessin eri vaiheita toteutettaessa. Dokumentissa esitellään testauksen yleiset käytännöt ja menetelmät. 2.1.4. Testiraportit http://hazard.iki.fi/vym/palautukset/t2/testiraportti_vym.pdf http://hazard.iki.fi/vym/palautukset/t2/testiraportti_amok.pdf http://hazard.iki.fi/vym/palautukset/t2/testiraportti_xml_reader.pdf Oheiset kolme moduulia testattiin. 2.1.5. Toiminnallinen määrittely http://hazard.iki.fi/vym/palautukset/t2/toiminallinenmaarittely.pdf Toiminallista määrittelyä tarkennettiin hieman. Tietokannan pikku virheet korjattiin ja tietokannan nimeämistä yhtenäistettiin muun projektin kanssa (esim. charasteristic feature).
7(8) 2.1.6. Tekninen määrittely http://hazard.iki.fi/vym/palautukset/t2/tekninenmaarittely.pdf Tekniseen määrittelyyn lisättiin luokkakaavioita. Luokkien omaa dokumentaatiota vähennettiin, koska samat asiat on esitelty tarkemmin online versiona (mukana palautuksessa). Kokonaan uusi luku on XML tietorakenteet, niiden lyhyt esittely ja DTD kuvaukset. 2.1.7. Tekninen dokumentointi (API) http://hazard.iki.fi/vym/palautukset/t2/api/ Luokat dokumentoidaan suoraan lähdekoodiin JavaDoc-merkinnöin ja niistä tehdään on-line dokumentointi automaattisesti. 2.1.8. Käyttöliittymä demo http://hazard.iki.fi:8080/portal/etusivu.jsp http://hazard.iki.fi/vym/palautukset/t2/navigointikartat.pdf Edellisessä vaiheessa rakennettu demoportaali muutettiin dynaamiseksi. Portaalia ei tulla dokumentoimaan niin tarkasti, kun järjestelmän corea. Luonnosmainen navigointikartta ja luokkadokumentointi on kuitenkin mukana tässä palautuksessa. Demoportaalin ensimmäinen versio pyörii netissä yllä annetussa osoitteessa (käyttäjätunnukset ovat: ana, hazard, juhis, tuomo ja niko, salasanoja ei tarkisteta). Toiminnallisuuteen joutuu vielä suhtautumaan varauksella, sillä portaali itsessään sisältää joitakin puutteita ja toisaalta se käyttää stubi-tasoista VYM:iä hyväkseen (joka palauttaa siis tietoja hard-koodattuna eikä kannasta saatikka älykkäästä konetta).
8(8) 3. Ongelmat Projektissamme tässä vaiheessa ilmenneitä ongelmia ja mahdollisia ratkaisuehdotuksia Tuntiraportoinnin kanssa edelleen ongelmia. Osa ryhmästä tekee jo sovitun suunnitelman mukaisesti. Nyt pitäisi vain kaikki saada mukaan. Sakkoja nostetaan! Omista työesteistä ei ilmoiteta rehellisesti projektipäällikölle, vaan luvataan hoitaa asioita, joita ei kuitenkaan hoideta. Ilmoitus projektipäällikölle viikoittaisesta aikataulusta Tehdään luvatut tehtävät. Ei lupailla turhaan.