Loppuraportti Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma
|
|
- Ville-Veikko Salonen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Loppuraportti Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys Tuomo Mäkelä Pohja luotu Tuomo Mäkelä Kuvailtu käytäntöjä Tuomo Mäkelä, Jani Eränen Valmis
2 Sisältö: 1 JOHDANTO Projektin eteneminen 3 2 TULOSTEN ARVIOINTI Tavoitteiden toteutuminen Arvio järjestelmän tilasta Puutteet resurssien käytössä Järjestelmän tila ja kehitettävyys Tunnetut bugit ja toteuttamatta jääneet toiminnot Jatkokehitysideat Haasteet projektissa Laajuuden rajaaminen Ohjelmointikielten osaaminen 7 3 MITTARIT Resurssien käyttö Laatumetriikat Ohjelmiston koko 13 4 KÄYTÄNNÖT JA TYÖKALUT Käytännöt Iteraatiosuunnittelu Dokumentointi Riskien hallinta Tuntikirjaus Viestintä Vikojen seuranta Vertaistestaus Versionhallinta Koodauskäytäntö Heuristinen arviointi Refactoring Pariohjelmointi Automatisoitu järjestelmätestaus 17 5 OPETUKSELLINEN ARVO Henkilökohtainen oppiminen 18 6 KURSSIPALAUTE 21 2
3 1 Johdanto Tämä on loppuraportti projektista, jossa Suomen Sulkapalloliitolle tehtiin kilpailutoiminnan rekisteriohjelma. Projekti toteutettiin TKK:n kurssilla T /5115 Ohjelmistokehitysprojekti kahdeksan hengen projektiryhmässä. Projektissa luotiin Suomen Sulkapalloliitolle uusi kilpailutoiminnan rekisteriohjelma, jonka tavoitteena on korvata vanha käytössä oleva järjestelmä. Järjestelmän tehtävänä on ylläpitää tietoja sulkapallon kilpailutoiminnasta. Tämä edellyttää pelaajien, seurojen, kilpailujen ja tulosten hallintaa. Tulosten pohjalta järjestelmä pystyy ylläpitämään myös sulkapallon ranking listoja. 1.1 Projektin eteneminen Projekti kesti viisi kuukautta lokakuun alusta 2006 helmikuun loppuun Projekti vietiin läpi kolmessa iteraatiossa: Projektin suunnitteluiteraatiossa ja kahdessa toteutusiteraatiossa. Projektin suunnitteluiteraatiossa luotiin käytäntöjä tulevalle toiminnalle. Asiakkaan kanssa käytiin keskusteluita tulevan järjestelmän vaatimuksista. Vaatimusten pohjalta järjestelmästä luotiin prototyyppi, jonka avulla testattiin ohjelmointiympäristöä, otettiin kehittäjät sisään järjestelmän kehittämiseen ja testattiin tulevan järjestelmän rakennetta. Ensimmäisen toteutusiteraation alussa oli ongelmia käyttöliittymän suunnittelun kanssa, mikä hieman hidasti kehitystyötä. Iteraation aikataulu oli varsin tiivis. Kun tietokanta ja käyttöliittymä oli saatu vahvistettua, päästiin varsinaiseen kehitystyöhön. Kehitystyö vei enemmän aikaa kuin suunniteltiin ja iteraation laajuutta jouduttiin rajaamaan. Silti järjestelmää ei ehditty testaamaan yhtä hyvin kuin suunnitelmana oli. Toisessa toteutusiteraatiossa toteutettiin ensin ensimmäisessä toteutusiteraatiossa toteuttamatta jääneet toiminnallisuudet ja keskeisimmät toiminnallisuudet, jotka oli jätetty toiseen toteutusiteraatioon. Tämän jälkeen keskityttiin enemmän järjestelmän virheiden korjaukseen. Kaikki toiminnallisuudet saatiin hyvään kuntoon lukuun ottamatta nelinpelitulosten syöttämistä puukaavioon ja ranking kaavojen luomista muille kuin yleisille luokille. 3
4 2 Tulosten arviointi 2.1 Tavoitteiden toteutuminen Projektin tavoitteet asetettiin projektin alussa yhdessä asiakkaan kanssa. Niiden toteutumiskriteerit on määritelty pääosin siten, että asiakas arvioi tavoitteiden toteutumisen. Järjestelmä palautetaan asiakkaalle samaan aikaan kuin muut dokumentit, joten asiakkaan arvioita liiketoimintatavoitteiden toteutumisesta emme ole saaneet. Seuraavassa on kuitenkin arvioitu sanallisesti, miten itse koemme tavoitteiden toteutuneen. Taulukko 1. Liiketoimintatavoitteet ja niiden toteutuminen Asiakkaan liiketoimintatavoitteet Toteutumiskriteeri 1. Tavoitteena on korvata vanha järjestelmä. Toteutuu, jos uusi järjestelmä otetaan käyttöön Suomen Sulkapalloliitossa. Koska nelinpelitulosten tallentaminen jäi järjestelmästä toteuttamatta, järjestelmään jäi puute, joka vaatii jatkokehitystä ennen kuin järjestelmä voidaan ottaa käyttöön Suomen Sulkapalloliitossa. 2. Tavoitteena on parantaa yhteensopivuutta seuroissa käytettävien ohjelmien ja liiton kilpailutoiminnan rekisteriohjelman kanssa. Asiakas arvioi projektin lopussa, onko yhteensopivuus seuroissa käytettävien ohjelmien ja liiton kilpailutoiminnan rekisteriohjelman kanssa riittävä. Järjestelmään on mahdollisuus syöttää BTP kilpailunhallintaohjelman tulostiedostoja. 3. Tavoitteena on vähentää Sulkapalloliiton Asiakas ja projektiryhmä arvioivat, onko työmäärää tarjoamalla seuroille kilpailutietojen tallentaminen mahdollisuutta tallentaa kilpailutietoja. mahdollistettu vaatimuksiin kirjatulla tavalla. Seurojen on mahdollista hallita tietoja järjestelmän kautta. Järjestelmään ei kuitenkaan pysty syöttämään nelinpelin tuloksia, mikä tekee kilpailujen tulosten hallinnan puutteelliseksi. 4. Tavoitteena on helpottaa pelaajaluetteloiden ja ranking tietojen tuottamisesta. Asiakas arvioi projektin lopussa, onko tavoite toteutunut. Järjestelmä osaa tuottaa erilaisia pelaajaluetteloita. Ranking tietojen tuottaminen on mahdollista yleisten luokkien osalta, mutta juniori ja eliittisarjojen osalta rankingtietojen tuottamista ei ole toteutettu. 5. Tavoitteena on parantaa helppokäyttöisyyttä. Asiakas arvioi projektin lopussa, onko tuote helppokäyttöinen. Järjestelmään pyrittiin luomaan intuitiivisesti toimiva käyttöliittymä. Käytettävyyttä varmistettiin heuristisin analyysein. Varsinaisia käyttäjätestejä ei kuitenkaan toteutettu asiakkaan tekemää pikaista testausta lukuun ottamatta. Järjestelmä on siinä määrin monimutkainen, että käytettävyyttä on varmasti mahdollista parantaa, kunhan todelliset käyttäjät pääsevät tositoimiin järjestelmän pariin 6. Tavoitteena on uuden järjestelmän päivitettävyys ja ylläpidettävyys tulevien sääntömuutosten varalta. Asiakas ja projektiryhmä arvioivat, onko sääntöjen päivitettävyys ja ylläpidettävyys toteutettu vaatimuksiin kirjatulla tavalla. Järjestelmän kautta voidaan muokata rankingin laskentakaavoja tulevien sääntömuutosten varalta. 7. Tavoitteena on historiatietojen helppo Asiakas arvioi projektin lopussa, onko hallinta, saatavuus ja varmistus. tavoite toteutunut. Järjestelmässä on mahdollista muokata historiatietoja ja järjestelmän ollessa webpohjainen, ne ovat helposti saatavilla 4
5 8. Tavoitteena on toteuttaa seuroille tarjottava kilpailuunilmoittautumisjärjestelmä. Toteutuu, jos ilmoittautumisjärjestelmä on sisällytetty uuteen järjestelmään. Järjestelmään on toteutettu seuroille mahdollisuus ilmoittautua pelaajia kilpailuihin Arvio järjestelmän tilasta Järjestelmän puutteet ovat, että nelinpelitulosten syöttö puukaavioon jäi toteuttamatta ja rankingpisteitä ei ole mahdollista laskea kuin yleisten luokkien osalta. Kaksinpelitulosten syöttäminen on kuitenkin toteutettu ja nelinpelitulosten syöttäminen on sama asia mukailtuna. Pohja jatkokehitykselle on siis olemassa. Nelinpelitulosten syöttämisen poisjääminen johtui ensisijaisesti suunnitteluvirheestä, koska tehtävän jakaminen unohtui iteraatiosuunnittelussa. Kun puute huomattiin iteraation edetessä, tehtävä jaettiin eteenpäin, mutta aikaa tehtävän tekemiseen ei kuitenkaan löytynyt. Projektin lopussa luovuimme tehtävästä, koska riittävää aikaa järjestelmän testaamiseen ei ollut sen varalta, ettei toiminto olisi toiminut kunnolla tai se olisi aiheuttanut ongelmia järjestelmän muihin osiin. Ranking sääntöjen osalta laskukaavat yleisille luokille on tehty. Eliitti ja junioriluokkien osalta ranking säännöt noudattelevat kuitenkin yleisten luokkien periaatteita, joten suurin työ tämän kohdan osalta on jo tehty. Ranking sääntöjen jääminen kesken johtui ensinnäkin siitä, että rankingsääntöjen vaatimukset kirjattiin projektin alussa puutteellisesti, eikä niiden vaatima työmäärä ollut täsmälleen tiedossa. Yllätyksenä tuli, että ranking sääntöjä tulisi tehdä useampia erilaisia. Toiseksi ranking sääntöjen tekeminen jäi kesken muiden aikatauluongelmien takia. Tehtävä oli kuitenkin niin monimutkainen luonteeltaan, ettei sen tekemistä ollut järkevää siirrellä. Kaikki muut toiminnot saatiin toteutettua ja järjestelmä on niiltä osin valmis. Muussa järjestelmässä ei myöskään ole tunnettuja bugeja. Järjestelmää on testattu runsaasti. Ryhmän arvion järjestelmän laadusta on hyvä. Koska emme ole palauttaneet järjestelmää asiakkaalle, emme ole saaneet heidän arviotaan järjestelmän laadusta. Vertaistestauksesta saatu palaute tukee sitä, että järjestelmä on toiminnallisuuksien osalta hyvässä kunnossa. Vertaistestauksessa löydetyt virheet olivat jo aiemmin tunnettuja, jotka myöhemmin korjattiin, tai käytettävyyteen liittyviä parannusehdotuksia. Lisäksi osa palautteesta oli sellaista, että parannusehdotuksia annettiin kohtiin, jotka oli asiakkaan kanssa sovittu toteutettavaksi toteutetulla tavalla Puutteet resurssien käytössä Käytimme projektissa tunteja 1401 suunnitellun 1520 sijaan. Eniten tuntien kertymistä olisi helpottanut, jos kehittäjille olisi saanut enemmän tunteja projektin suunnitteluiteraatiossa. Suunnitteluiteraation töitä oli kuitenkin vaikea jakaa siten, että kaikille olisi kertynyt töitä. Toiseksi projektin tuntien hallinnassa ongelmia aiheutti se, että osa projektiryhmästä teki projektin ohella täyttä työviikkoa. Tämä aiheutti suuria haasteita projektin tuntien hallinnan lisäksi myös useamman projektiryhmän jäsenen henkilökohtaiselle ajanhallinnalle. Lisäksi projektin kannalta ongelmaksi muodostui, etteivät johtoryhmän jäsenet pystyneet allokoimaan tunteja projektiin juuri silloin, kun se olisi ollut projektin kannalta järkevää. Tunteja kyllä kokonaisuutena pystyttiin laittamaan projektiin riittävästi, mutta välillä saattoi tulla ajanjaksoja, jolloin tuntien irrottaminen oli vaikeampaa. Tämä aiheutti toisinaan sitä, ettei kehittäjille pystytty jakamaan uusia tehtäviä, koska 5
6 se olisi vaatinut alkuun työtä johtoryhmältä. Tämä ongelma olisi ollut ehkäistävissä sillä, että ajankäytön ja tehtävien suunnittelu niin projektin kuin henkilökohtaisen elämän tasollakin olisi ollut parempaa. Tavoitteenamme projektissa oli aloittaa työt heti uudenvuoden jälkeen, koska jo ensimmäisen toteutusiteraation jälkeen huomasimme, että tuntien saaminen täyteen tulisi olemaan haastavaa. Projektissa oli kuitenkin useampia avoinna olevia kysymyksiä, joiden ratkaisemiseksi olisimme tarvinneet palaveria asiakkaan kanssa. Asiakas kuitenkin sattui olemaan juuri joulukuun lopussa ja tammikuun alussa kiireinen ja toivomamme palaveri ennen joulun pyhiä siirtyi lopulta kolme viikkoa edemmäs tammikuun toiselle viikolle. Tämä hidasti projektin etenemistä merkittävästi. Ryhmässämme oli kaksi tuotantotalouden opiskelijaa, projektipäällikkö Tuomo Mäkelä ja Janne Mäkelä. Kumpikaan heistä ei osallistunut varsinaiseen ohjelmointityöhön, koska ohjelmointitaidot eivät olleet lähtökohtaisesti sillä tasolla, että tämä olisi ollut tehokasta. Tämä kuitenkin aiheutti etenkin Jannen kohdalla ongelman löytää sopivia tehtäviä. Sikäli kun projektin tunneista vain kolmasosa oli ohjelmointia, olisi tämä ongelma ollut väistettävissä roolien jakamisella projektin alkuvaiheessa. 2.2 Järjestelmän tila ja kehitettävyys Tunnetut bugit ja toteuttamatta jääneet toiminnot Järjestelmässä on yksi bugi, nelinpelitulosten syöttäminen. Käytännössä tämä on kuitenkin toteutumatta jäänyt toiminto. Ranking sääntöjen toteuttaminen eliitti ja junioriluokkien osalta jäi tekemättä. Ranking säännöt ehdittiin toteuttaa vain yleisten luokkien osalta Jatkokehitysideat BTP tiedoston syöttäminen on varsin keskeinen osa järjestelmää. Tämä kohta toimii, mutta sen helppokäyttöisyyttä on mahdollista parantaa entisestään. Nykyisellään BTP tiedoston syöttäminen järjestelmään vaatii käyttäjältä tarkkaavaisuutta. Järjestelmän käytettävyyttä on varmasti mahdollista parantaa monessa suhteessa. Eräs selvimmistä kehityskohteista on tulosten syöttäminen puukaavioon. Jos sarjassa on paljon pelaajia, puukaavio kasvaa varsin suureksi, mikä vaikeuttaa puukaavion hahmottamista ja näin ollen tulosten syöttämistä. 2.3 Haasteet projektissa Laajuuden rajaaminen Projekti oli sikäli ongelmallinen, että siten laajuutta oli vaikea rajata. Asiakkaan antamista vaatimuksista oli suurin osa toteutettava, jotta järjestelmä oli toimiva. Järjestelmän palaset, pelaajat, seurat, kilpailut ja tulokset, linkittyivät toisiinsa siten, että yhden kokonaisuuden puuttuminen olisi vaikeuttanut muidenkin järjestelmän osien toimintaa. Kokonaisuudessaan projektin laajuus oli sopiva, mutta ensimmäisessä toteutusiteraatiossa tämä aiheutti ongelmia, kun toimivan järjestelmän toteuttaminen vaati erittäin runsaan toiminnallisuuden toteuttamista. 6
7 2.3.2 Ohjelmointikielten osaaminen Ohjelmointi tapahtui PHP:lla, Smartylla ja MySQL:lla. Kaikki ohjelmointiin osallistuneet kehittäjät osasivat entuudestaan PHP:ta, mutta osa ohjelmoijista joutui vahvistamaan taitojaan, jotta saivat ohjelmointitaitona riittäväksi projektin vaatimuksiin. Ongelmia aiheutti myös melko monimutkainen arkkitehtuurinen rakenne, jollaisen parissa työskenteleminen oli osalle kehittäjistä entuudestaan vierasta. Smarty puolestaan oli suurimmalle osalle kehittäjistä entuudestaan vieras ja tätä jouduttiin opiskelemaan. Kokonaisuutena verrattaessa vastaavien komponenttien kehitystyöhön kulunutta aikaa ensimmäisen ja toisen toteutusiteraation aikana, havaitaan, että kehitykseen käytetty aika oli toisessa toteutusiteraatiossa alhaisempi. Tämä antaa viitteitä siitä, että kehittäjät kehittyivät ensimmäisen toteutusiteraation aikana ohjelmoijina suhteessa järjestelmäämme. Täsmällisiä indikaattoreita tästä on vaikea antaa, koska ohjelmointitehtävät eivät ole identtisiä ja toisaalta ohjelmiston rivien määrän avullakaan ei luotettavaa vertailua pysty tekemään, koska toisessa toteutusiteraatiossa virheiden korjaukseen käytetty aika oli huomattavasti suurempi. 7
8 3 Mittarit 3.1 Resurssien käyttö Seuraavassa esitetyt tuntien käytön luvut ovat arvioita, koska numerot tuntikirjauksesta oli käytännön syistä pakko ottaa ennen kuin kaikkea projektin työtä oli vielä tehty. Kuitenkin käytännössä arviot ovat varsin tarkkoja ja käsittävät lähinnä vain viimeisen viikonlopun ja palautusviikon työtunteja. Projektiin oli jokaiselle projektiryhmän jäsenelle laskettu työpanokseksi 190 tuntia, kun jokainen projektiryhmän jäsen teki myös SEPA:n. Kokonaisuudessaan projektiryhmällä oli tunteja käytettävissä 1520 ja niitä lopulta käytettiin Vajausta budjetoiduista tunneista jäi 119 tuntia eli 7,8 %. Projektiryhmän jäsenille kertyneet tunnit on esitetty taulukossa 2 ja kaaviossa 1. Taulukko 2. Käytetyt tunnit kehittäjittäin PP I1 I2 yht Jani Eränen Tatu Frisk Timo Hassinen Henri Kostia Janne Mäkelä Tuomo Mäkelä Petri Palmila Olavi Stenroos yhteensä Tuntien jakautuminen kehittäjittäin tuntia I2 I1 PP Jani Eränen Tatu Frisk Timo Hassinen Henri Kostia Janne Mäkelä Tuomo Mäkelä Petri Palmila Olavi Stenroos Kaavio 1. Tuntien jakautuminen kehittäjille eri iteraatioissa 8
9 Tuntien kertyminen viikoittain on esitetty kaaviossa 2. Tunteja kertyi melko tasaisesti, paitsi vuodenvaihteessa tuli projektiin selvä tauko ja toisaalta projektin lopussa saatiin tehtyä viikoilla enemmän tunteja. Kuitenkin joka viikko olisi pitänyt pystyä lähelle 80 tuntia. Tuntien kertymä viikoittain tuntia viikko 0 Tunnit viikoittain Tuntien kertymä Kaavio 2. Tuntien kertyminen viikoittain Projektin tuntien kertymä työtavoittain on esitetty kaaviossa 3 ja 4. Lukemat lienevät varsin tyypillisiä kurssilla käydylle ohjelmistoprojektille. Toisaalta tehtävien jaotteleminen eri kategorioihin ei ole aina kovin täsmällistä, kun löytyy tehtäviä, jotka pystyy perustellusti laittamaan useampaan kategoriaan. 9
10 300 Tuntien jakautuminen tehtävittäin iteraatioissa tuntia Opiskelu Viestintä Projektin hallinta Laadunvarmistus Ohjelmointi Suunnittelu Infra SEPA PP I1 I2 Kaavio 3. Tuntien kertyminen tehtävittäin eri iteraatioissa Tuntien jakautuminen tehtävittäin 4 % 3 % 9 % 5 % 18 % Opiskelu Viestintä Projektin hallinta Laadunvarmistus 10 % Ohjelmointi Suunnittelu 34 % Infra 17 % SEPA Kaavio 4. Tuntien jakautuminen tehtävittäin 10
11 3.2 Laatumetriikat Laadun mittarina on sovittu käytettävän virhettä per 1000 koodiriviä eli virheitä / KLOC, ja I2 lopussa tehdyn testitapaus testauksen mukaan tilanne on 1 virhe / LOC ~ 0 virhettä / KLOC. Koko elinkaaren aikana löydettyjen virheiden määrä on 45 / LOC ~ 2,41 virhettä / KLOC. Kaaviossa 5 on esitetty virheiden kokonaismäärä suhteessa tuhanteen riviin koodia. Total Defects per KLOC 3,00 2,50 2,00 1,50 Total Defects per KLOC 1,00 0,50 0, Kaavio 5. Löydettyjen virheiden määrä suhteessa tuhanteen riviin ohjelmakoodia Taulukossa 3 on esitetty tämän hetkinen virhetilanne. Kurssin aikataulujen puitteissa pyrittiin korjaamaan kaikki Blocker, Critical ja Major luokan virheet mutta yksi vakava Major luokan virhe vielä jäi toteutukseen. Kyseinen virhe liittyy nelinpelitulosten syöttöön. Toiminto ei ole valmis, joten se on kirjattu virheenä virhetietokantaan. Taulukko 3. Löydetyt virheet tyypeittäin Blocker Critical Major Minor Trivial Yhteensä Löydetty Iteraatiossa 1 Löydetty Iteraatiossa Löydetty yhteensä Avoinna
12 Taulukossa 4 on esitetty käsitykset eri järjestelmän osien laadusta. Taulukko 4. Järjestelmän eri toiminnallisuuksien laadun tila (1=huono, 2=tyydyttävä, 3=hyvä) Järjestelmän osa Laatu Kommentit laadusta Luottamus Kommentit Luottamuksesta Kilpailukalenteri 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Kilpailut 3 Toiminnon toteutus on valmis,nelinpelin tulosten syöttöä lukuunottamatta, ja löydetyt virheet on korjattu. Pelaajat 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Seurat 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Käyttäjät 3 Toiminnon toteutus on valmis ja löydetyt virheet on korjattu. Ranking säännöt 2 Toiminnon toteutus on valmis. Toimintoa ei ole testattu tarpeeksi. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 3 Uusia virheitä ei ole löytynyt. 2 Ranking säännöt ovat erittäin monimutkaiset ja tämä osa alue tarvitsee vielä lisää testausta. 12
13 3.3 Ohjelmiston koko Ohjelmiston kokoa mitataan lähdekoodin rivien määrällä. Lähdekoodin rivien määrä oli projektin lopussa riviä. Ohjelmiston koon kehitys on esitetty kaaviossa 6. SLOC SLOC SLOC Date Kaavio 6. Järjestelmän lähdekoodin koko 13
14 4 Käytännöt ja työkalut 4.1 Käytännöt Seuraavassa esitellään projektissa sovellettavat käytännöt Iteraatiosuunnittelu Iteraatiosuunnittelusta vastasi johtoryhmä projektipäällikön johdolla. Johtoryhmä hahmotteli iteraation tehtäviä ja asiakkaan kanssa käydyn palaverin jälkeen löi lukkoon iteraatioon tulevat tehtävät ja iteraation aikataulun. Tehtäville annettiin täsmälliset aika arviot, toteutusajat ja tehtävät määrättiin kehittäjille Dokumentointi Dokumentoinnissa käytettiin hyväksi kurssin antamia rakennepohjia. Ne dokumentit, joille valmista pohjaa ei ollut annettu, toteutettiin samojen periaatteiden mukaan, jotta dokumentit olivat yhdenmukaisia yleiseltä rakenteeltaan Riskien hallinta Riskien hallinnassa käytettiin Deplhi metodia. Riskien kartoitus tehtiin kaksi kertaa projektin kuluessa, molemmissa iteraatioiden vaihteissa. Riskien kartoitus toimi siten, että jokainen projektiryhmän jäsen ja asiakas arvioivat asteikolla yhdestä viiteen riskien toteutumisen todennäköisyyttä ja niiden vaikuttavuutta. Luvut kerrottiin yhteen ja kaikkien antamista luvuista laskettiin keskiarvo, joka kuvasti projektin riskiä. Riskikartoituksen tekeminen auttoi oivaltamaan projektin mahdollisia riskejä ja projektin edetessä ne oli helppo pitää mielessä ja miettiä, mitä ongelmia saattaisi ilmetä. Erityisen mielenkiintoinen riskikartoitus oli toisella kerralla, jolloin oli nähtävissä, miten eri riskit olivat kehittyneet Tuntikirjaus Tuntikirjauksessa käytettiin Journyx ohjelmaa. Tuntien kirjaamisen kannalta Journyx toimi siten, että siinä valittiin pudotusvalikoista projekti, sitten tehtävä yksitasoisesta listasta. Tämän jälkeen voitiin viikon sisällä syöttää seuraaviin sarakkeisiin tuntimääriä eri viikon päivien kohdalle. Tehtäviä pystyi myös kommentoimaan. Hallinnan puolelta tuntikirjaukseen piti ensin luoda tehtävät. Raportteja pystyi järjestelmästä ottamaan monenlaisia, mutta aika arvioita tehtäville ei pystynyt asettamaan. Käytännössä tuntikirjauksen raportointi toteutettiin siten, että tuntikirjauksesta tunnit siirrettiin käsin Exceltaulukkoon, jossa tehtävien suunnittelu oli toteutettuna. Tuntikirjauksen selkeyttämiseksi emme siirtäneet kaikkia tehtäviä Journyxiin, vaan joitain tehtäviä yhdisteltiin, jotta tehtävien määrä pysyi inhimillisenä. Käytännössä tämä toimi hyvin aina, kun oli tiedossa, mikä henkilön tehtävä oli ollut edellisellä viikolla tai henkilö oli kirjoittanut kommenttisarakkeeseen, mihin käytännössä oli tunteja käyttänyt. Käytännössä kommenttisaraketta olisi voinut käyttää useammin täsmentämään tehtyjä tehtäviä, mutta kokonaisuutena tuntikirjaus toimi hyvin. 14
15 4.1.5 Viestintä Projektimme viestintä projektiryhmän sisällä toteutettiin pääosin sähköpostin ja Skypen avulla. Varsinkin Skype viestintävälineenä toimi hyvin. Ainoa ongelma Skypen käytössä oli, että kaikki projektiryhmän jäsenet eivät olleet erityisen aktiivisesti Skypessä ja kaikkien jäsenten tavoittaminen varsinkin silloin kun se olisi ollut asiaa, oli Skypellä huonoa. Skype soveltuu projektin viestintävälineeksi erityisen hyvin silloin, kun projektiryhmän jäsenten tavoitettavuus sen kautta on hyvä. Käytännössä paljon projektiryhmän sisäistä viestintää toteutettiin sähköpostin avulla. Varsinkin tiedotusluontoiset asiat, jotka eivät vaatineet keskustelua, hoidettiin usein sähköpostin kautta. Sähköpostin etuna on, että asiat voi viestiä kaikille silloin kun itsellä on parhaiten aikaa ja vastapuoli taas voi lukea sähköpostin silloin kun hän itse ehtii koneelle. Kuitenkin toisinaan asioissa, jotka vaativat keskustelua tai sopimista ja sähköposti osoitti heikkoutensa, kun vastauksen saamiseen tulee aina viivettä. Ehkä jonkinlainen käytäntö siitä, että sähköpostiviestit kuitattaisiin luetuiksi, vaikka niihin ei heti ehdittäisi vastatakaan, olisi ollut paikallaan. Ryhmän sisäisiä palavereita pidettiin erittäin vähän. Viestinnässä olisi varmasti ollut parannettavaa. Toisinaan ehkä ongelma saattoi tuntua olevan tiedonkulussa, vaikka todellisuudessa se saattoi ollakin siinä, että projektin johtoryhmällä ollut aikaa miettiä asioita, eikä mitään tiedotettavaa. Viestintä usein kulkee käsi kädessä projektin yleisen hallinnan kanssa. Silloin kun projekti sujuu hyvin, niin asioista tiedottaminenkin on helppoa, kun voidaan edetä suunnitelman mukaisesti. Ehkä joissain tilanteissa olisi pitänyt herkemmin tarttua puhelimeen, jotta asiat olisi saanut selvitettyä heti. Projektiryhmän sisäiset palaverit olisivat varmasti helpottaneet viestintää ja luoneet parempaa rytmiä palaveriin. Käytännössä kuitenkin, kun useampi projektiryhmän jäsen oli töissä, olisi palavereiden pitäminen mihinkään järkevään aikaan ollut hankalaa. Toisaalta palaverit olisivat syöneet ehkä tarpeettomasti tunteja. Varsinkin jos huomioi sen, että projektiryhmän jäsenet olisivat saattaneet joutua tulemaan ainoastaan palaverin takia pitkän matkan takaa Otaniemeen. Asiakkaan suuntaan viestintää toteutettiin pääosin sähköpostin välityksellä. Aika ajoin ongelmaksi muodostui, että asiakas vastasi sähköposteihin varsin pitkällä viiveellä, mikä jossain kohdin hidasti tai muokkasi projektin etenemistä. Ehkä etenkin asiakkaan suuntaan olisi ollut hyvä sopia käytännöstä, joissa sähköpostit kuitattaisiin luetuiksi, vaikka niihin ei heti ehdittäisikään vastata. Monet asiakkaalta kysytyt kysymykset olivat luonteeltaan sellaisia, että vastauksen antaminen niihin vaati pientä mietintää, joten puhelimen käyttö ei olisi tehostanut viestintää. Asiakkaan kanssa pidettiin myös palavereita. Palaverit kuitenkin rajoittuivat pääosin kurssin puolelta olleisiin sääntömääräisiin tapaamisiin. Kurssille ja Mentorille viestittiin pääosin viikkoraportoinnin kautta. Kokonaisuutena ei täysin selvinnyt, ketkä kaikki ja kuinka aktiivisesti viikkoraportointia lukivat, olihan se kaikille avoimena netissä ja lukukerrat olivat yleensä suurempia kuin kaksi tai kolme. Viikkoraportointi käsitti sanallisen selvityksen projektin etenemisestä, yksityiskohtaisen taulukon tuntikirjauksesta ja käyrät, jotka kuvasivat tuntien käyttöä. Mentorilta tuntikirjauksesta saatu palaute oli positiivista, joten ilmeisesti tämä viestintä täytti sille asetetut vaatimukset Vikojen seuranta 15
16 Vikojen seurantaa tehtiin Bugzillan avulla. Kaikki virheet, jotka löydettiin testauksessa, kirjattiin Bugzillaan, ellei virhettä kyetty korjaamaan saman tien. Virheiden korjausta ohjattiin kehittäjille myös Bugzillan kautta Vertaistestaus Vertaistestaus toteutettiin ristiin Vitamin B ryhmän kanssa. Vertaisryhmän aiheena oli ASSEMBLY Party Management System. Testaus järjestettiin Maarin talolla siten, että neljän tunnin aikana simuloitiin assemblypartyt pienoiskoossa. Lisäksi kaksi Vitamin B projektiryhmän jäsentä teki SEPA:n käytettävyystutkimuksesta, joka toteutettiin vertaisryhmän avulla fake partyn aikana. Testaussessio vedettään läpi sunnuntai iltapäivän aikana Maarin talolla ja siihen osallistuu sekä Vitamin B projektiryhmä että heidän asiakkaansa edustajia. Good Minton järjestelmän testaus toteutettiin skenaariopohjaisten ohjeistusten avulla virtuaalipalvelinta vasten. Järjestimme testausryhmälle julkisessa verkossa olevan palvelimen, jossa oli sen hetkinen vakaa versio Good Minton järjestelmästä. Testaajille toimitettiin Test Session chartterit sekä hieman taustatietoja järjestelmästä. Testaajia pyydettiin käymään läpi neljä erilaista skenaariota. Skenaarioissa keskityttiin järjestelmän peruskäyttöön ja sen yleisimpiin toimintoihin. Testaajat testasivat järjestelmän ja palauttivat testilokit suorittamistaan testeistä. Järjestelmästä löytyi yksi uusi virhe ja muutamia testaajien virheiksi luokittelemia toimintoja, jotka olivat kaikki asiakkaan kanssa sovittuja toimintatapoja. Vertaistestauksesta tuli esille muutamia käytettävyyteen liittyviä asioita. Yleisesti ottaen vertaistestausryhmän mielestä järjestelmä tuntui olevan hyvässä kunnossa ja löydökset olivat enemmänkin käytettävyyteen liittyviä kohtia, jotka parantaisivat ohjelman laatua Versionhallinta Projektin versionhallinta asennettiin ATK keskukselle, josta se oli kaikkien projektiryhmän jäsenten tavoitettavissa. Versionhallintaan lisättävä koodin oli määrä olla kommentoitua ja toimivaa. Versionhallinnan käytössä ei sinänsä ollut ongelmia, mutta muutaman kerran, kun versionhallintaan lisättiin koodia tai sitä korjailtiin, vioittui muun järjestelmän toiminta. Nämä ongelmat kuitenkin saatiin korjattua aina suhteellisen nopeasti Koodauskäytäntö Ohjeet koodauskäytännöstä ja projektissa tuotetun koodin tyylistä toteutettiin mallitiedostona, johon oli kirjattuna ohjeet ohjelmakoodin ulkoasusta ja kommentointikäytännöstä Heuristinen arviointi Teimme SEPAn heuristisesta analyysistä. Analyysi tehtiin projektin aikana kaksi kertaa kummankin iteraation aikana. Heuristinen menetelmä osoittautui hyväksi tavaksi selvittää käyttöliittymässä olevia parannettavia asioita. Heuristinen analyysi kannattaa ehdottomasti jatkossakin säilyttää yhtenä mahdollisena SEPA aiheena. Varsikin projektit, joissa on painoarvoa käyttöliittymässä voivat kokea heuristisen analyysin erittäin hyödylliseksi Refactoring 16
17 Koodin uudelleen järjestely eli refactoring toteutettiin projektissa SEPA aiheena. Koodin uudelleenjärjestely tarkoittaa kirjoitetun koodin muokkaamista paremmin ja helpommin luettavaksi. Tämän toteuttamiseksi muokataan komponentin sisäistä rakennetta. Komponentin ulkoista toiminnallisuutta ei muuteta. Projektissa käytiin läpi käyttöliittymän koodi. Siihen tehtiin kirjan Refactoring: Improving the Design of Existing Code (Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts) opastamana muutoksia, samalla testaten joka vaiheessa että uusia bugeja ei ilmaantunut. Koodin muutoksia tehtiin ensin kahden hengen SEPA ryhmässä, mutta tämän perusteella huomattiin, että on nopeampaa ja tehokkaampaa jakaa työt puoliksi ja tehdä muutokset yksitellen. Koodin uudelleenjärjestäminen sopi kohtalaisesti PHP kielellä tuotetun koodin parantamiseen; useimmat uudelleenjärjestämiset liittyvät luokkiin, joita ei vielä PHP 4:ssa ole toteutettu parhaalla mahdollisella tavalla. Uudelleenjärjestäminen sopii parhaiten oliopohjaiseen koodiin. Oliopohjainen koodi on toki itsessään jo luettavampaa kuin funktionaalinen Pariohjelmointi SEPA aiheemme oli pariohjelmointi, jolla tarkoitetaan sitä, että kaksi kehittäjää työskentelee yhden tehtävän kimpussa yhdellä tietokoneella. Pariohjelmointia käytettiin projektissa toteutusvaiheiden 1 ja 2 aikana silloin, kun SEPA:n tehneille laadunvarmistusryhmän jäsenille jaettiin myös ohjelmointitehtäviä. Pariohjelmointi oli projektissa erittäin käyttökelpoinen tekniikka ja sen käyttöä tulisi harkita aina ohjelmistoprojekteissa. Pariohjelmointi vähensi virheiden määrää koodissa sekä nopeutti tehtävistä suoriutumista. Toisaalta intensiivinen työtapa aiheutti erimielisyyksiä joidenkin pariohjelmointisessioiden aikana, mutta ongelmista selvittiin. Ongelmista selviäminen nosti meidän kohdalla myös yhteishenkeä. Pariohjelmoinnista oli hyötyä myös ajankäytönhallinnassa, koska pariohjelmointitilaisuus oli etukäteen sovittu, joten tuntien käyttöä pystyy paremmin arvioimaan etukäteen Automatisoitu järjestelmätestaus Projektin toisessa iteraatiossa otettiin käyttöön automaattiseen järjestelmätestaukseen soveltuva TestGen4Web tallennus /toisto ohjelma. Ohjelman avulla varmistettiin, että järjestelmään tehdyt virheenkorjaukset ja muutokset eivät rikkoneet ohjelman muita osia. Ongelmallisinta järjestelmätestauksessa oli sopivan ohjelman löytäminen, mutta projektissa käytetty ohjelma toimi varsin hyvin. Järjestelmätestauksesta oli runsaasti hyötyä etenkin, kun projekti oli suhteellisen suuri ja ryhmämme toimi hajallaan. Järjestelmätestaus helpotti ja nopeutti muutosten aiheuttamien virheiden löytymistä. Automatisoitu järjestelmätestaus oli ohjelmistokehitysprojektissa erittäin hyödyllistä. 17
18 5 Opetuksellinen arvo 5.1 Henkilökohtainen oppiminen Henkilökohtainen oppiminen kurssilla on esitetty taulukossa 5. Taulukossa on esitetty myös kurssin alussa asetetut henkilökohtaiset tavoitteet, joihin vertaamalla voi arvioida kurssilla oppimista. Taulukko 5. Henkilökohtainen oppiminen kurssilla Henkilökohtaiset tavoitteet Jani Eränen Tavoitteenani on saada kehitettyä kommunikaatiotaitojani hajautetun projektiryhmän sisällä sekä asiakkaan kanssa. Toivon voivani omaksua ja soveltaa tuotekehitysprosessia pienessä ja hajautetussa tuotekehitysryhmässä. Toivon löytäväni uusia toimintatapoja ja oppivani paremmin kontrolloimaan omaa ajankäyttöäni. Lisäksi toivon onnistuvani luomaan uusia kontakteja työelämää ajatellen. Tatu Frisk Toivon saavani hyödyllistä kokemusta SEmenetelmien soveltamisesta ja tällaisen projektin kulusta yleensä. Pyrin osaltani vaikuttamaan siihen, että projektin tuloksena syntyy asiakkaalle hyödyllinen tuote työmäärän pysyessä kurssin raamien puitteissa. Timo Hassinen Toivon oppivani kurssin aikana soveltamaan Ohjelmistotuotannon perusteet kurssilla oppimiani asioita. Erityisesti haluan oppia, miten laadunvarmistus käytännössä toimii. Mitä on opittu Tärkein oppimani asia kurssilla on delegointi. Johtoasemassa olevan henkilön on jaettava tehtäviä sillä itse ei pysty tekemään kaikkea. Toinen asia on delegoitujen tehtävien suuri seurannan tarve varsinkin tämän tyyppisessä hajautetussa projektissa. Ryhmä oli suhteellisen suuri, 8 henkeä, ja aikataulujen vuoksi kehitystyö toteutettiin kullekin sopivana ajankohtana. Tämän vuoksi esimerkiski testaustaskien ja virhekorjausten seuranta oli työlästä. Lisäksi oma päivätyö haittasi selvästi kurssin suorittamista. Uusia toiminta tapoja löytyi ainakin nettikäyttöisten ryhmätyöohjelmien muodossa. Keskitetty tuntikirjaus oli erittäin kätevä ja hyvä väline. Vaatimusten ja testien hallintaan olisin vielä kaivannut jotain helpompaa työkalua kuin Word ja Excel. Sain paljon hyödyllistä kokemusta SEmenetelmien soveltamisesta ja käsitystä tämän kokoluokan projektin kulusta. Ongelmia aiheutti ajankäyttö toisessa toteutusiteraatiossa, kun koulun kurssien ohessa tein täyttä työviikkoa. Kurssin alussa asetin itselleni tavoitteeksi, että kurssin aikana opin soveltamaan Ohjelmistotuotannon perusteet kurssilla oppimiani asioita ja opin, miten laadunvarmistus käytännössä toimii. Nämä tavoitteet olen mielestäni saavuttanut, sillä olen soveltanut esimerkiksi Ohjelmistotuotannon perusteet kurssilla opittua pariohjelmointia projektin aikana SEPA:ssa sekä laatinut järjestelmän vaatimuksia testaavia testitapauksia. Lisäksi olen oppinut, että suuri projektiryhmä kannattaa jakaa pienryhmiin, joiden sisällä tehtäviä on helpompi jakaa. Henri Kostia 18
19 Tavoitteenani on kehittyä ohjelmistokehittäjänä jokaisella osa alueella. Toivon, että projekti antaa hyvän esimerkin projektiryhmän toiminnasta, jota voi mahdollisesti hyödyntää työelämässä. Kurssin päätavoite oli projektin tekeminen ryhmissä, tässä onnistuttiin mielestäni melko hyvin. Työkuorman jakautuminen epäilytti heti kurssin alussa: tasaisesti hiukan reilut 10 tuntia viikossa ei kuulostanut mahdolliselta. Joillakin viikoilla kurssin työmäärä oli lähes olematon ja seuraavana viikkona saattoikin olla jo todella kiireistä. Omiin tavoitteisiin nähden kurssi sujui hyvin. Kurssin määräajat ja tavoitteet oli ilmoitettu selkeästi ja ajoissa, jonka ansiosta kurssin suorittaminen sujui vaivattomasti. Tuntikirjausjärjestelmän, versionhallinnan ja bugzillan käytön oppiminen projektin aikana kuuluu kurssin parhaimpaan antiin. Janne Mäkelä Toivon oppivani ohjelmistoprojektin käytännön toteuttamisen vaiheista. Tuomo Mäkelä Tavoitteenani on projektin kuluessa oppia ymmärtämään ohjelmistoprojektin elinkaarta. Toivon saavani kokemusta ohjelmistoprojektin hallinnasta ja projektin johtamisesta. Lisäksi toivon projektin kuluessa kehittyväni ihmisten johtamisessa. Tavoitteenani on osaltaan vaikuttaa siihen, että projekti etenee onnistuneesti läpi ja projektin lopputuotteena saatavasta ohjelmistosta olisi aidosti hyötyä asiakkaalle. Opin millainen on onnistuneesti läpi viety ohjelmistoprojekti. Opin myös eri ohjelmistoprojekteissa käytettävistä työvälineistä ja kommunikaatiotavoista. Jälkikäteen ajateltuna olisin voinut ottaa aktiivisemman otteen projektin johtamisesta, mutta toisaalta omat heikkouteni projektialueen asiantuntemuksessa pakottivat delegoimaan myös johtamistoimintaa. Jälkikäteen ajateltuna olisi monessa tilanteessa toimia toisin, kenties tehokkaammin, mutta kun ajattelen tietämystäni päätöksen hetkillä, ymmärrän tekemäni valintani hyvin. Ehkä tämänkaltainen ajattelu todistaa, että kurssi on opettanut paljon niin projektin johtamisesta kuin ohjelmistoprojektin läpiviemisestä. Tulevien projektijohtajien toimintaa helpottaa varmasti suuresti, että heillä on jo kokemusta kurssilta kehittäjän roolista. Petri Palmila 19
20 Odotan kurssin antavan selkeän kokonaiskuvan ohjelmistokehitysprojektista. Omalta osaltani tulen keskittymään kehittäjän tehtäviin ja tavoitteena on suoriutua kurssista hyvin. Selviytyminen kurssista tulee vaatimaan hyvää ajankäytönhallintaa. Ohjelmistoprojektikurssi oli erityisen opettavainen. Kurssin jälkeen voi sanoa, ettei näitä kokemuksia ja oppeja kovin helposti unohda, siten kuin normaaleilla kirjoihin pohjautuvissa kursseissa on yleensä tapana. Ohjelmistotuotantokurssin aiheet on nyt paljon helpompi sisäistää, kun on itse ollut mukana ohjelmistotuotantoprojektissa. Kurssin yhtenä tavoitteenani oli ajankäytönhallinta projektin aikana. Suoriuduin siitä muutamaa viikkoa lukuunottamatta hyvin. Kurssi vaati hyvin paljon aikaa. Yllätys oli se, miten aikaa kului pelkästään työkalujen ja ohjelmointiympäristön konfigurointiin. Mikäli kurssi olisi tapahtunut työelämässä, niin työkalut ja ympäristö olisivat vaatineet mielestäni huomattavasti vähemmän aikaa. Usein juuri kahden eri tietokoneen käyttö aiheutti päänvaivaa. Ainoa oikea ratkaisu olisi ollut valita vain yksi kone, mutta päivätyötä tekevänä se ei ollut mahdollista. Olavi Stenroos Tavoitteenani on oppia toimimaan oikeassa ohjelmistoprojektiympäristössä ja oppia paremmin käytännössä käytettäviä teknologioita sekä vähän vuorovaikutusta asiakkaan kanssa. Kurssilla oppi jotain siitä, miten työt tämän kokoluokan projektissa jakautuvat. Tästä oli hyötyä varsinkin siinä mielessä, että kokemusta vastaavista projekteista ei vielä työelämän puolelta ole. Tältä osin kurssi vastasi siis ihan hyvin odotuksia. Asiakkaan kanssa toimimisesta ei tullut paljon kokemuksia. Tekniseltä kantilta kurssin aikana PHPohjelmoinnin rutiini parantui, vaikka varsinaisia uusia asioita ei tullutkaan vastaan. 20
21 6 Kurssipalaute Kahdeksan hengen ryhmä on ohjelmistoprojektiin melko suuri. Alun perinhän ryhmämme koko oli seitsemän henkeä, mutta ryhmien jo muodostuttua ryhmäämme kyseli mukaan vielä yksi henkilö, jonka otimme ryhmään. Kahdeksan hengen ryhmällä tehtävien järkevä jakaminen oli varmasti vaikeampaa kuin seitsemän hengen ryhmänä toimittaessa. Kurssiuudistus sellaiseksi, että johtoryhmän jäsenet ovat jo kerran käyneet kurssin, helpottaa varmasti paljon johtoryhmän jäsenten päänvaivaa, kun parempi käsitys kurssista kokonaisuutena on jo olemassa. Toisaalta, vaikka kurssi onkin erittäin hyödyllinen, on se myös erittäin työläs. Kurssin käyminen kahteen kertaan on toisaalta varmasti myös erittäin kuluttavaa muun opiskelun kannalta. Toinen toteutusiteraatio oli kohtuullisen lyhyt kestollisesti, jolloin viikoittainen työmäärä kasvoi melko suureksi. 21
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
LisätiedotVaatimusmäärittely Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma
Vaatimusmäärittely Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 10 05 Jani Eränen Alustava 0.2 2006 10 06 Jani Eränen Asiakirjapohja
LisätiedotGood Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi
Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotVERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
Lisätiedotdokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant
AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision
LisätiedotT 76.5158 SEPA päiväkirja
T 76.5158 SEPA päiväkirja Pariohjelmointi Timo Hassinen, 60255H & Petri Palmila 60111S Versio Pvm Tekijä Kuvaus 1.0 2.12.2006 Hassinen Ensimmäinen versio 1.1 9.12.2006 Palmila Toinen versio 1.2 10.12.2006
LisätiedotVersio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio
Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista
Lisätiedot0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005
LisätiedotVerkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008
Verkkopokerijärjestelmä Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008 Projektiryhmä Samuli Aalto-Setälä Jukka Kekälainen Jarno Kyykkä Mika Mielonen Mårten Smeds Otto Waltari Ohjaaja
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä
LisätiedotProjektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma
Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys 0.1 2006 10 04 Tuomo Mäkelä Pohja luotu 0.2 2006 10 06 Tuomo Mäkelä Kirjoitettu tekstiä
LisätiedotProjektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma
Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys 0.1 2006 10 04 Tuomo Mäkelä Pohja luotu 0.2 2006 10 06 Tuomo Mäkelä Kirjoitettu tekstiä
LisätiedotProjektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma
Projektisuunnitelma Good Minton Sulkapalloliiton kilpailutoiminnan rekisteriohjelma Versio Päivämäärä Tekijä Selitys 0.1 2006 10 04 Tuomo Mäkelä Pohja luotu 0.2 2006 10 06 Tuomo Mäkelä Kirjoitettu tekstiä
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan
LisätiedotLAATURAPORTTI Iteraatio 1
LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja
LisätiedotLOPPURAPORTTI Paperikonekilta Versio 1.0
Loppuraportti LITA/TIKO/PAPERIKONEKILTA 1 (14) 18.5.2009 LOPPURAPORTTI Paperikonekilta Versio 1.0 Tekijät: Jaakko Karhunen Jani Hyvönen TIKO, IT-Dynamo 5.kerros Osoite: Tietojenkäsittelyn koulutusohjelma
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotConvergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
LisätiedotInternet-pohjainen ryhmätyöympäristö
Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6
LisätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
LisätiedotOhjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotGood Minton Vaatimusmäärittely Sulkapalloliiton Kilpailujärjestelmä
Good Minton Vaatimusmäärittely Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 10 05 Jani Eränen Alustava 0.2 2006 10 06 Jani Eränen Asiakirjapohja muokattu
LisätiedotKuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
LisätiedotTIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
LisätiedotT Testiraportti - järjestelmätestaus
T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria
LisätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
LisätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
LisätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Software project 2(5) Muutosloki
LisätiedotTarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen
Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit
LisätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
LisätiedotT 76.115 Tietojenkäsittelyopin ohjelmatyö Hirviöryhmä loppukatselmointi. Hirviö. Projektikatselmointi
Hirviö Projektikatselmointi Mikä Hirviö on? Hajautettu muistikirja Professoreille Muistiinpanoja keskusteluista opiskelijan kanssa Diplomitöiden ja jatko opintojen seuranta Raportointi Opetushenkilökunnalle
LisätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
LisätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotProjektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti
Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(8)
LisätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Versionhallinta BitKeeper-työkalun avulla Tuomas Heino Muutosloki Versio Pvm Tekijä Kuvaus 1.0 01.12.2003
LisätiedotTestaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
LisätiedotYhteenvetodokumentti. Boa Open Access. Helsinki 5.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Yhteenvetodokumentti Boa Open Access Helsinki 5.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotMäärittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli
LisätiedotYlläpitodokumentti Mooan
Ylläpitodokumentti Mooan Helsinki 16.08.06 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op/6ov) Projektiryhmä Heikki Aitakangas
LisätiedotT Loppukatselmus
T-76.115 Loppukatselmus REILU 16.3.2005 Agenda Johdanto (5min) Tuotteen esittely (10 min) Käyttötarkoitus Vaatimukset Ohjelmiston rakenne Demosovellus Projektin arviointi (15 min) Iteraatiot Tavoitteiden
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3
T-76.115 Tietojenkäsittelyopin ohjelmatyö Testiraportti, vaihe LU Sisältö Tästä dokumentista ilmenee LU-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 14.4.2003
LisätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
LisätiedotProjektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
LisätiedotOleelliset vaikeudet OT:ssa 1/2
Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
LisätiedotProCountorin asiakastyytyväisyyskysely 2009
Sivu 1(9) ProCountorin asiakastyytyväisyyskysely 2009 Asiakkaat tyytyväisiä palveluun ProCountorin vuosittaiseen asiakastyytyväisyyskyselyyn vastasi tänä vuonna ennätykselliset 561 vastaajaa (179 vastaajaa
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
Lisätiedot1Blogin arvostelu. Blogin tarkoitus. Arvostelun filosofia. Blogin sisältö. Blogin kieli ja tyyli. Viikkotehtävät. Blogin viikoittainen sisältö
1Blogin arvostelu Blogin tarkoitus Blogin pitäminen on tapa välittää tietoa ryhmän päätöksentekoprosessista ulkopuolisille tahoille. Samalla se toimii ryhmän sisäisenä resurssina ja tapana pitää kirjaa
LisätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
LisätiedotTestausraportti. Dokumentti: Testausraportti_I2.doc Päiväys: Projekti : AgileElephant
AgilElephant I2 Tekijä: Heikki Salminen Omistaja: ElectricSeven Aihe: Sivu 1 / 8 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 7.2.2004
LisätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
LisätiedotPS-vaiheen edistymisraportti Kuopio
PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun
LisätiedotAlkukartoitus Opiskeluvalmiudet
Alkukartoitus Opiskeluvalmiudet Päivämäärä.. Oppilaitos.. Nimi.. Tehtävä 1 Millainen kielenoppija sinä olet? Merkitse rastilla (x) lauseet, jotka kertovat sinun tyylistäsi oppia ja käyttää kieltä. 1. Muistan
LisätiedotYliopistonlehtori Marja Raekallio Helsingin yliopisto Eläinlääketieteellinen tiedekunta Kliinisen hevos- ja pieneläinlääketieteen osasto
Yliopistonlehtori Marja Raekallio Helsingin yliopisto Eläinlääketieteellinen tiedekunta Kliinisen hevos- ja pieneläinlääketieteen osasto Näyttöön perustuvan eläinlääketieteen verkkokurssi sekä perustutkintoa
LisätiedotT-76.5158 SEPA päiväkirja
T-76.5158 SEPA päiväkirja Ryhmä 14 Automatisoitu yksikkötestaus Mikko Luukkonen, 60549T Lauri Helkkula, 62820H Matti Eerola, 60686A Versiohistoria Versio Pvm Tekijä(t) Kuvaus 0.3 25.11.2007 Luukkonen,
LisätiedotSEPA päiväkirja. Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I
SEPA päiväkirja Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T-76.4110 Ohjelmistoprojekti I Sisällysluettelo Sisällysluettelo...2 1. Johdanto...3 2.
LisätiedotFour Ferries Oy:n nopea kokeilu Helsingin kouluissa Helsingin koulujen nopeiden kokeilujen ohjelma II, kevätlukukausi 2019
Julkinen loppuraportti 30.07.2019 Four Ferries Oy:n nopea kokeilu Helsingin kouluissa Helsingin koulujen nopeiden kokeilujen ohjelma II, kevätlukukausi 2019 Kokeilun tavoitteet Four Ferries Checker on
LisätiedotGood Minton Vaatimusmäärittely Sulkapalloliiton Kilpailujärjestelmä
Good Minton Vaatimusmäärittely Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 10 05 Jani Eränen Alustava 0.2 2006 10 06 Jani Eränen Asiakirjapohja muokattu
LisätiedotHirviö Vertaistestausraportti
Hirviö Vertaistestausraportti Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. maaliskuuta 2005 1 Sisältö 1 Johdanto 3 2 Testauksen kattavuus 3 2.1
LisätiedotMökkivarausjärjestelm
Mökkivarausjärjestelmä Mökkivarausjärjestelm Projektin loppuraportti R1VP Loppuraportti 2(8) Versiohistoria Versio Päivä Laatija(t) Hyväksyjä Voimassaoloaika 1 25.5.2018 Heini Saastamoinen Ville Heiskanen
LisätiedotS11-09 Control System for an. Autonomous Household Robot Platform
S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on
LisätiedotTESTIRAPORTTI - XMLREADER LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - XMLREADER LUOKKA i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
LisätiedotKuopio Testausraportti Kalenterimoduulin integraatio
Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio, testausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 22.4.2002 Matti Peltomäki Ensimmäinen versio 0.9 22.4.2002 Matti
LisätiedotMatopeli C#:lla. Aram Abdulla Hassan. Ammattiopisto Tavastia. Opinnäytetyö
Matopeli C#:lla Aram Abdulla Hassan Ammattiopisto Tavastia Opinnäytetyö Syksy 2014 1 Sisällysluettelo 1. Johdanto... 3 2. Projektin aihe: Matopeli C#:lla... 3 3. Projektissa käytetyt menetelmät ja työkalut
LisätiedotMINNO Metropolia 2014 - Loppukatselmus. Kotisatama Järjestelmät 14.11.2014
MINNO Metropolia 2014 - Loppukatselmus Kotisatama Järjestelmät 14.11.2014 Mikä MINNO on? Innovaatioprojekti, joka sisältyy jokaisen Metropolian opiskelijan opetussuunnitelmaan. Opinnot toteutetaan usein
LisätiedotTämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:
Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus
LisätiedotT Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2)
T-76.4110 Ohjelmistoprojekti I 25.2.2006 T-76.4115 Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2) Versio Päiväys Muokkaaja Kuvaus 2.0 25.2.2006 Markus Kattilamäki Päivämäärien tarkennus, viimeistely
LisätiedotT SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B
T-76.5158 SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 5.12.2006 Tuomas Tolvanen Ensimmäinen
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
LisätiedotIkivihreä kirjasto loppuraportti määrittelyprojektille
loppuraportti määrittelyprojektille Mikkelin Ammattikorkeakoulu Oy Sähkö ja informaatiotekniikan laitos Versiomuutokset 29.1.2014 viimeisin tilanne tietokantakonversiosta Mirja Loponen 7.2.2014 tarkennettu
LisätiedotKurssin hallinta -työväline
Kurssin hallinta -työväline Kurssin hallinta -työvälineellä muokataan kursseja A&Ooppimisympäristöalustalla Kurssi koostuu - ohjelmasta (linkit työkaluihin& muihin resursseihin), - materiaaleista, - keskusteluryhmästä,
Lisätiedot"Miten IT infra-projekti onnistuu ja miten epäonnistuu" Timo Häkkinen TTY PDF versio josta on poistettu 1 kuva ja yhden sivun tekstit
"Miten IT infra-projekti onnistuu ja miten epäonnistuu" Timo Häkkinen TTY 7.6.2017 PDF versio josta on poistettu 1 kuva ja yhden sivun tekstit Esityksen rakenne ja esittäjän taustat Seuraavassa esityksessä
LisätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti ICT-ajankohtaisseminaari 15.4.2009 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt
LisätiedotT harjoitustyö, kevät 2012
T-110.4100 harjoitustyö, kevät 2012 Kurssiassistentit T-110.4100@tkk.fi Tietotekniikan laitos Perustieteiden korkeakoulu Aalto-yliopisto 31.1.2012 Yleistä Kurssin osasuoritteita ovat kaksi osatenttiä,
LisätiedotTestaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
LisätiedotFile [Otsikko] 2014-02-26 40212. Projektisuunnitelma. SPT2014 Selvitysprojekti projektihallinnan työkaluista
apj2014 Projektisuunnitelma 1 (6) Projektisuunnitelma SPT2014 Selvitysprojekti projektihallinnan työkaluista Versio 1.0 Muutoshistoria umero Pvm Selitys Tekijä(t) 0.1 12.2.2014 Projektisuunnitelmaluonnos
LisätiedotT Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki
T-76.612 Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki Osa 1 - Ongelmat McConnellin (1996) luokittelun mukaisesti: Ihmiset Prosessi Tuote Teknologia Osa
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I2-iteraatio 11.2.2004 Agenda Projektin tilanne (10 min) Tavoitteiden toteutuminen Iteraation tunnusluvut Käytetyt työskentelymenetelmät (5min) Iteraation
LisätiedotYhteenvetodokumentti. PLAYOFF Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki. Päivi Pääkkö, ohjaaja
Yhteenvetodokumentti Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki Päivi Pääkkö, ohjaaja Helsinki, 13. joulukuuta 2007 Ohjelmistotuotantoprojekti yritysviestinnän oppimateriaalin
LisätiedotMielekkäät työtehtävät houkuttelevat harjoittelijoita!
Mielekkäät työtehtävät houkuttelevat harjoittelijoita! Vuoden 2013 aikana 359 Turun yliopiston opiskelijaa suoritti yliopiston rahallisesti tukeman harjoittelun. Sekä harjoittelun suorittaneilta opiskelijoilta
LisätiedotTITANIC TEMPPU, vaan ei karille
TITANIC TEMPPU, vaan ei karille Mikko Mäkelä Tuomo Rintamäki 17/10/10 Helsinki Metropolia University of Applied Sciences 1 Metropolia- ammattikorkeakoulusta Suomen suurin ammattikorkeakoulu, joka aloitti
LisätiedotLaadunvarmistusdokumentti
Laadunvarmistusdokumentti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.10 07.11.2005 Rönkkö Kirsi Erotettu omaksi dokumentikseen Sisällysluettelo 1. Koko projektissa...2 1.1. Tavoitteet...2
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I2-iteraatio 11.2.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) Työskentelymenetelmistä
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotWebOodin käyttöliittymän kehitys
WebOodin käyttöliittymän kehitys Laura Vuorinen 22.2.2008 Kehittämisosasto / Opiskelijarekisteri Taustatietoa Oodista 13 yliopiston yhteinen tietojärjestelmä opiskelijoiden perustiedot, suoritukset ja
LisätiedotPROJEKTIN LOPPURAPORTTI
LOPPURAPORTTI 27.2.2006 1/8 TEAM TUBELESS RENGASTESTIEN MITTAUSTULOSTEN KÄSITTELY - NOHEVA II PROJEKTIN LOPPURAPORTTI SISÄLLYS 1 Johdanto...2 2 Projektin eteneminen...2 2.1 Suunnitteluvaihe 27.9.-20.10.2005...2
LisätiedotMenetelmäraportti Ohjelmakoodin tarkastaminen
Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5
Lisätiedot