Digitv-synkro Loppuraportti

Digitv-synkro Loppuraportti

Sisällysluettelo 1. Johdanto...3 1.1. Projektin eteneminen...3 1.2. Lopputulokset...5 1.2.1. Lopputulosten arviointi...5 1.2.2. Jatkokehitysajatuksia...5 1.2.3. Jälkiviisautta...5 1.3. Työmenetelmät ja työkalut...6 1.4. Jälkilaskelmat...7 1.4.1. Projektin työmäärä...7 1.4.2. Kustannukset...7 1.4.3. Ohjelmiston koko...7 1.4.4. Havaittujen bugien määrä...7 1.4.5. Työlajien määrät...8 1.4.6. Projektiryhmän työmäärät...8 1.4.7. Suunnitellun työn suhden suunnittelemattomaan...9 1.5. Oppiminen...9 1.5.1. Pekka, dokumentointi...10 1.5.2. Mika, ohjelmoija, käyttöliittymäsuunnittelu...10 1.5.3. Ville, ohjelmointi, testaus...10 1.5.4. Oskari, riskienhallinta, ohjelmoija...10 1.5.5. Riku, ohjelmoija...10 1.5.6. Tuomas, ohjelmoija...11 1.5.7. Tapio, projektipäällikkö...11 1.6. Kurssipalaute...11 Versio- ja muutoshistoria Versio Päiväys Tekijä Kuvaus 0.1 19.4.02 Tapio Nissilä Ensimmäinen luonnos 1.0 23.4.2002 Tapio Nissilä Sisältö, rakenne Tallennettu: 23.4.2002 12:49 Tulostettu: 23.4.2002 12:58 Loppuraportti 2

1. Johdanto Projekti oli luonteeltaan tutkimusprojekti. Tavoitteena oli löytää menetelmä jonka avulla on mahdollista synkronoida digi-tv kuvasignaalin sisältö sekä digi-boksissa suoritettavat sovellukset. Projektin tavoitteena oli suunnitella ja toteuttaa ohjelmistotuote, jonka avulla olisi mahdollista tuottaa synkronoituja sovelluksia. Projektisuunnitelmassa projektin tavoite kiteytettiin yhdeksi lauseeksi, (mission statement) seuraavasti: Projektin tavoitteena on suunnitella ja toteuttaa ohjelmisto jonka avulla on mahdollista tuottaa digi-tv ympäristöön kuvasignaalin kanssa synkronoituja sovelluksia. Käytännössä tämän tavoitteen saavuttaminen edellytti tutustumista digi-tv tekniikkaan, standardeihin sekä käytännön kokemuksiin lähetysjärjestelmistä. Asiakkaamme Digita Oy antoi resursseja ja aikaa projektin käyttöön, joten kiitos hyvään lopputulokseen pääsystä kuuluu suurelta osalta myös heille. 1.1. Projektin eteneminen Projekti onnistutiin toteuttamaan hyvin pitkälle suunnitelman mukaisesti. Syynä tähän oli erityisesti hyvä ja kokenut projektityhmä ja luonnollisesti syntyneet vastuujaot, sekä Digitan panostus projektiin. Asiakaskommunikaatio sujui hyvin ja Digita antoi tavoitteen määrittelyn jälkeen ryhmälle hyvin vapaat kädet työn tekoa varten. Tämä antoi ryhmälle vapautta, mutta myös vastuuta. Suurimpana ongelmana koko projektin ajan oli synkronoinnin toteutustavan epäselvyys. Mahdollisia tekniikoita synkronoinnin toteuttamiseksi oli muutama, mutta kaikki nämä olivat vain heikosti tunnettuja. Näin ollen projekti eteni osittain tutkimuksen ja kokeilun merkeissä. Projektin suunnittelu vaiheessa asiakaskommunikaatio oli vilkasta. Asiakas esitteli ongelmaa ja tavoitettaan ryhmälle, ja ryhmä suunnittelu projektia tämän tavoitteen mukaisesti. Hahmoteltiin projektiorganisaatio sekä vastuualueet ryhmäläisiälle. Tehtiin esitutkimusta aihe-alueesta. T1 -vaiheessa aloitettiin sekä koko järjestelmän arkkitehtuurin suunnittelu että koordinaattieditorin käyttöliittymän suunnittelu. T2 vaiheessa järjestelmän arkkitehtuurista oli muutama potentiaalinen ratkaisuvaihto, ja näiden kelpoisuutta testattiin. T2 vaihe oli vahvasti demoilu Loppuraportti 3

ja tutkimuspainotteinen. Käyttöliittymäsuunnittelu saatiin päätökseen ja käyttöliittymän tekninen toteutus aloitettiin. Tässä vaiheessa ei ollut testausympäristöä saatavilla. Automaattisen hahmontunnistuksen käyttäminen koordinaattitietojen tuottamisessa oli tutkimuskohteena. Tähän ei kuitenkaan löytynyt valmista tai edes käyttökelpoista ratkaisua, ja oman ratkaisun kehittäminen tämän projektin puitteissa osoittautui liian suuritöiseksi. Automaattisesta hahmontunnistuksesta päätettiin luopua tämän projektin osalta. Huomattava muutos projektissa syntyi T3 vaiheessa järjestelmän arkkitehtuuriin ja komponentteihin. Projektissa kehitetyn editori käytti itsenäistä ohjelmistokomponenttia MPEG-kuvasignaalin purkamiseen. Ryhmä kehitti T1- ja T2- vaiheiden ajan omaa C++ kielellä tehtyä MPEG2- dekooderia (jonka tehtävänä on purkaa ja esittää MPEG2 dekoodattua digitv kuvasignaalia editori sovelluksessa), mutta tästä luovuttiin T3 vaiheessa kun löydettiin teknisesti parempi ratkaisu. Java Media Framework mahdollisti MPEG2 dekoodauksen, jolloin saavutimme täysin java kielisen toteutuksen. Edut uudesta totetuksesta ovat kiistattomat, haittana oli luonnollisesti vanhan komponentin kehitykseen kulunut aika ja panos. Testaus päästiin aloittamaan T3 vaiheessa. Muita oleellisia muutoksia projektisuunnitelmaan tai tekniseen toteutukseen ei projektin kuluessa tullut. Yhtenä mainitsemisen arvioisena ongelmana on myös digi-tv:n nuori ikä, ja sitä kautta päätelaitteiden puute. Ryhmämme pääsi demoamaan oikeaa, markkinoilla myytävää laitteistoa vasta projektin loppuvaiheessa. Tästä ei aiheutunut mitään takaiskuja projektin tavoitteille, mutta päinvastoin voidaan ajatella, että mikäli testaus olisi voitu aloittaa aiemmin, olisi lopputulos saattanut ehtiä kypsymään pitempään. Projekti kulki suunnitelman mukaisesti ja asiakas pysyi tyytyväisenä koko projektin ajan. Projektiteknisesti kaikkien henkilöiden työmäärää ei saatu skaalattua aivan samankokoisiksi, mutta tässäkin onnistuttiin kokonaisuutena hyvin. Työmäärien pakottaminen samankokoisiksi olisi johtanut huonompaan lopputulokseen, nyt jokaisella oli mahdollisuus kontribuoida projektiin omaa osaamistaan suhteellisen vapaasti. Tämä näkyi mm. hienoina yksilösuorituksina tiukoissa paikoissa. Edistymisraporteista löytyy tarkemmat kuvaukset yksittäisten vaiheiden etenemisestä. Editymisraportit palautukset liitteenä. Loppuraportti 4

1.2. Lopputulokset Yhteenvetona projektin arvioinnissa voidaan sanoa, että asiakkaan top 10 vaatimuslista pystyttiin toteuttamaan ja asiakas on tyytyväinen. Testausaikataulun suhteen emme päässeet projektin aikataulussa tavoitteisiin, mutta suurin osa testauksesta saatiin suoritettua suunnitelman mukaisesti. 1.2.1. Lopputulosten arviointi Lopputuloksia analysoitaessa huomataan, että järjestelmä kokonaisuudessaan saatiin valmiiksi vasta projektin lopussa. Editori ohjelmisto saavutti lopullisen muotonsa jo hieman aiemmin, mutta kokonaisuutta mukaan lukien MHP sovellus sekä koordinaattitiedon lähettäminen tuotantojärjestelmien kautta ei onnistunut ajoissa. Syynä toimivan tuotanto- tai testausympäristön puute. Näin ollen emme pääseet testaamaan synkronointia niin laajasti kuin kaupallisessa tuotekehityksessä olisi ollut tarpeellista. Tämä ei estänyt asiakkaan top 10 tavoitteiden saavuttamista, mutta rajasi mahdollisuuden kehittää ohjelmiston käytettävyyttä ja tukea päivittäiselle työn teolle. Syynä tähän oli dig-tv markkinoiden nuori ikä (mikä oli myös syynä projektille!), joten tähän asiaan emme voineet vaikuttaa projektiryhmässä sen enempää kuin Digitallakaan. 1.2.2. Jatkokehitysajatuksia Asiakkaan top 10 vaatimuksista kaikki saavutettiin. Automaattinen hahmontunnistus osoittautui liian suureksi tehtäväksi tämän projektin piirissä, joten se jätettiin jatkokehityssuunnitelmiin. Automaattisen hahmontunnistuksen käyttö kuvaobjektien merkinnässä olisi seuraava looginen askel kehitettäessä sovellusta eteenpäin. Toinen oleellinen jatkokehityssuunta on editorin liittäminen osaksi jotakin toista, saman aihe-alueen editointityökalua. Näin tuotteen loppukäyttäjä saisi suuremman kokonaisuuden käyttöönsä, pelkällä editorilla on mahdollisuus toteuttaa synkronointi teknisesti, mutta se ei avusta sovelluskehityksessä. Näiden asioiden yhdistäminen nähdään hyvin tärkeänä kehityssuuntana. 1.2.3. Jälkiviisautta Pohdittessa (kurssin vaatimuksesta) mitä tekisimme toisin mikäli voisimme, ei oleellisia korjauksia tule mieleen. Paljon parannettavaa varmasti on monilla työskentelyn alueilla, mutta mitään yksittäisiä asioita jotka oleellisesti tehtiin väärin tai jotka toisin tehtynä tuottaisivat erilaisen lopputuloksen ei ole mahdollista nostaa esille. Loppuraportti 5

Yleisiä asioita kuten viestintää ja vastuunjakoa projektiryhmän sisällä voisi aina terävöittää ja parantaa, mutta näissä ei tehty mitään virheitä, joten oleellisia korjauksia ei tarvita. 1.3. Työmenetelmät ja työkalut Projektissa käytettiin seuraavia työkaluja ja menetelmiä: - Tirana tuntiseurantaan ja raportointiin - Burana bugien raportointiin ja korjauksen seurantaan - CVS lähdekoodin hallintaan - PHPNuke portaalijärjestelmä projektiryhmän viestintään ja dokumenttien hallintaan - Java ohjelmointikieli - Java Media Framework MPEG-2 signaalin dekoodaamiseen - UML mallinnus- ja määrittelytekniikka Kaikki työkalut valittiin koska jokaisesta katsottiin olevan hyötyä. Näin ollen näiden arviointi erikseen on hieman tuottamatonta. Voidaan kuitenkin sanoa, että CVS:n käyttö lähdekoodin hallintaan toimii hienosti, yhtäainen muokkaaminen ja versionhallinta toimivat hyvin ja ovat tämän kaltaisessa projektissa välttämättömiä. Tirana oli kuten mikä tahansa tuntiraportointijärjestelmä, se ei sinällään sisältänyt mitään erityisominaisuuksia, vaan toimi hyvin ja luotettavasti työtuntien raportoinnissa. PHPNuke portaalijärjestelmää ylläpidettiin projektiryhmän sisäistä kommunikaatiota ja dokumenttien hallintaa varten. Järjestelmä toimi hyvin, tärkein käytetty toiminto oli keskusteluforum, joka mahdollisti myös liitetiedostojen lisäämisen viesteihin. Ainoa puute oli käyttöoikeudet uutisten julkaisuun, kuka tahansa ei saanut vapaasti julkaista uutisia järjestelmän etusivulle, tästä ominaisuudesta olisi ollut projektissa hyötyä. Tarkemmin tästä aiheesta menetelmäraportissa. UML mallinnuksesta (Unified Modelling Language) käytimme Use Case sekä Sequence Diagram tekniikoita. Nämä toimivat hyvin ja olivat erittäin hyödyllisiä. Lisäksi olisimme saattaneet hyötyä tarkemmasta mallinnuksesta varsinkin editorin sisäisen rakenteen osalta. Use Case ja Sequence Diagram eivät ota kantaa tekniseen rakenteeseen, joten tältä osin mallinnusta olisi voinut hieman laajentaa suunnitteluvaiheessa. UML mallinnuksesta tarkemmin menetelmäraportissa. Loppuraportti 6

Lisäksi projektissa käytettiin muutamia valittuja ohjelmistotuotannon menetelmiä joista jokaisesta on tehty erillinen kirjallinen raportti. Nämä raportit on palautettu luovutuksen yhteydessä. 1.4. Jälkilaskelmat 1.4.1. Projektin työmäärä Projektiin käytettiin loppujen lopuksi työtunteja 1128.50. Alkuperäinen suunnitelma oli 1200, joten tuntiarvio piti erittäin hyvin. Kaikki tehtävät saatiin projektiryhmän toimesta suoritettua, joten mitään ei jäänyt tekemättä siitä huolimatta, että tuntibudjetti alitettiin. Sama asia kuvaajana: Kuvasta nähdään, että suunnitelma oli hieman suurempi kuin toteutunut työmäärä. 1.4.2. Kustannukset Kustannuksia ei projektissa varsinaisesti ollut. Asiakas maksaa projektiryhmän jäsenille kiinteän korvauksen josta tarkemmin projektisuunnitelmassa. Tämä lisäksi muita, projektille kohdistettaviaa kustannuksia on asiakkaan tekemä työ (arviolta 50 tuntia) sekä internetsivuston ylläpito projektiryhmän kommunikaatiota varten. 1.4.3. Ohjelmiston koko Ohjelmiston koko on riveinä laskettuna seuraava: Editori 2803 riviä koodia 536 riviä kommentteja MHP sovellus 94 riviä koodia 83 riviä kommentteja Siirtoprotokolla 3172 riviä koodia 1657 riviä kommentteja 1.4.4. Havaittujen bugien määrä Havaittuja bugeja on raportoitu 13 kappaletta. Suurin osa näistä on korjattu, vakavuusasteelta nämä ovat olleet laidasta laitaan. Avoimia bugeja on tällä hetkellä raportoitu Tiranaan kuusi kappaletta, näitä työstetään parhaillaan. Muutama näistä on puuttuva ominaisuus jota ei ole vielä implementoitu. Loppuraportti 7

1.4.5. Työlajien määrät Projektissa tehtyjen työlajien määrät on esitetty seuraavassa kuvassa. Tästä nähdään, että ohjelmoinnin määrä on huomattavan suuri, 350 tuntia. Seuraavana tulee kokoukset, 230 tuntia. Suunnittelutyön määrä on n. 150 tuntia. Tästä voidaan vetää johtopäätös, että suunnittelua olisi pitänyt tuoda hieman vahvemmin esille, ohjelmistoprojekteissa on usein nyrkkisääntönä suunnittelu ja ohjelmointi yhtä suurilla osuuksilla. Tätä eroa voidaan selittää projektin tutkimusluonteella, sekä tuntien kirjaamiskäytännöllä. Selkeää ero suunnittelun ja toteutuksen välille ei aina tehty. Projektijohtoon käytetty aika on suunnilleen sitä mitä tämän kaltaisessa projektissa voi odottaa, luokkaa 10 % kaikista työtunneista. Sama tieto numeroina: ATK ylläpito/comp. maintenance 9.00 Dokumentointi/documentation 145.00 Kokoukset/meetings 231.50 Luennot/lectures 22.00 Ohjelmointi/programming 352.00 Opiskelu/studying 61.50 Proj.hallinta/proj. management 99.00 Suunnittelu/design 143.00 Testaus/testing 65.50 1.4.6. Projektiryhmän työmäärät Työmäärien jakautuminen eri henkilöiden välillä pyrittiin pitämään mahdolisimman pienenä. Tässä onnistuttiin suhteellisen hyvin, suurin Loppuraportti 8

tuntimäärä on Mikalla, 220 tuntia ja pienin Villellä, 135 tuntia. Työmäärien eroja ei ollut mahdollista pitää pienenmpinä järjen rajoissa, syynä selkeät vastuujaot. Mika vastasi sekä käyttöliittymän suunnittelusta että editorin teknisestä toteuksesta, joten hänelle kertyi työtunteja paljon jokaisessa projektivaiheessa. Tuomaksen pieni tuntimäärä selittyy sillä, että hänen vastuualueella ollutta C++ komponenttia ei loppujen lopuksi toteutettukaan kokonaan, vaan se korvattiin valmiilla ratkaisulla. Näin Tuomas jäi ilman töitä hetkeksi aikaa, eikä kokonaisuuden kannalta ollut järkevää työllistää häntä väkisin. 1.4.7. Suunnitellun työn suhden suunnittelemattomaan Seuraavassa kuvassa on suunnittellun työn suhde suunnittelemattomaan. Tästä nähdään, että suunnittelematonta työtä tehtiin vain 15,5 työtuntia, eli n. 1 % kaikista työtunneista. 1.5. Oppiminen Tässä kappaleessa käydään läpi oppimista projektin kuluessa. Tämä on esitetty ryhmäläisittäin. Loppuraportti 9

1.5.1. Pekka, dokumentointi Käyttöohjeen kirjoittaminen oli kokonaisuuden hahmottamisen kannalta palkitsevaa. Oli kovin helppoa jättää itselleni itsestään selviä asioita huomiotta. UML mallinnus, erityisesti Sequence Diagram, oli mielestäni erittäin toimiva tekniikka. Kurssilla saatu kokemus toivottavasti auttaa minua tulevassa työpaikassani. 1.5.2. Mika, ohjelmoija, käyttöliittymäsuunnittelu Käyttöliittymäsuunnittelu ja testaus olivat minun vastuullani projektissa. Teoreettinen tietämys oli aiemmilla kursseilla hankittua, mutta käytännön kokeilu kurssin muodossa antoi minulle paljon. Erityisesti vaatimusten hallinta osoittautui haastavammaksi kuin olisin odottanut. 1.5.3. Ville, ohjelmointi, testaus Minulla mielenkiintoisin oppi oli vaatimusten hallinta. Testauksen osalta minulle antoisaa oli testitapausten suunnittelu ja tässä ilmenevät yhteydessä linkitykset järjestelmän vaatimusten hallintaan ja dokumentointiin. Huomasin, että koko projektista kuluu useita kymmeniä prosentteja työmäärästä mallinnukseen, määrittelyyn, testaukseen ja dokumentointiin. Vaikka tämä asia olikin teoriassa tuttu, oli se silti käytännössä yllätys. 1.5.4. Oskari, riskienhallinta, ohjelmoija Riskienhallinta ohjelmistoprojektissa on aina haastaavaa. Useat projektit jättävät riskit huomiotta. Minulle oli yllätys kuinka paljon aikaa riskien arviointiin ja seurantaan todellisuudessa menee. Toinen oppimani asia oli toiminta ja erityisesti viestintä tämän kokoisen projektiryhmän kanssa. Olen työssäni tottunut toimimaan pienemmissä ryhmissä, ja tällöin viestintä on hyvin erilaista. Tässä projektissa kaikki eivät voi olla tietoisia toistensa tekemisistä koko ajan. 1.5.5. Riku, ohjelmoija Minulle järjestelmän arkkitehtuurisuunnittelu oli projektin mielenkiintoisin osa. Vastasin sekä arkkitehtuurista että editorin tiettyjen osien teknisestä toteuksesta, joten tehtävääni kuului sekä suurista kokonaisuuksista huolehtiminen että pienten yksityiskohtien hanskaaminen. Delegointi muun ryhmän kanssa oli suurin oppini, kuten Tuomas, myös minä olen toiminut useissa samoja tekniikoita käyttäneessä projektissa. Loppuraportti 10

1.5.6. Tuomas, ohjelmoija Projekti ei antanut minulle kovinkaan paljon uutta sillä olen työskennellyt jo aika paljon vastaanvanlaisten kehitysprojektien parissa. Suurin saamani oppi olikin mielenkiintoinen kokemus digitv-maailmasta. 1.5.7. Tapio, projektipäällikkö Projektinsuunnittelu oli tässä projektissa hyvin haastavaa. Koska projekti oli luonteentaan tutkimus- ja kehitysprojekti, eikä lopputulosta tiedetty etukäteen, ei projektisuunnitelman tekokaan ollut helppoa. Onnistuimme kuitenkin tässä budjetin näkökulmasta erittäin hyvin tekemällä suunnittelutyön ryhmissä ja ottamalla koko projektiryhmän mukaan projektin suunnitteluun. Asiakaskommunikaatio oli tässä projektissa yllättävän helppoa ja vei odotettua vähemmän aikaa. 1.6. Kurssipalaute Kokonaisuutena kurssi oli hyvä ja mielenkiintoinen. Vasta oikeassa projektityössä on mahdollista ymmärtää ohjelmistotuotannon problematiikkaa ja saada näkemystä asioihin. Palautteena ryhmämme näki aikataulun, yhden projektivaiheen palautus osui tenttikaudelle, mikä näkyi suoraan ko. vaiheessa pienentyneenä tuntimääränä koska ryhmäläisten tuli lukea muihin tentteihin. Muuten kurssin järjestelyissä ei ole kommentoitavaa. Mentorimme oli innostava ja toi oleellisia projektiteknisiä asioita ryhmämme tietoisuuteen projektin edetessä. Cemo oli myös joustava aikataulujen suhteen, joten yhteistyömme sujui saumattomasti. Loppuraportti 11