T Ohjelmistokehitysprojekti I - Loppuraportti
|
|
- Karoliina Hämäläinen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 T Ohjelmistokehitysprojekti I - Loppuraportti Versio Päiväys Muokkaaja Kuvaus 1.0 Markus Kattilamäki Kuvaajat lisätty, viimeistely Markus Kattilamäki Projektin haasteellisuus lisätty Markus Kattilamäki Kokemuksia työkaluista Markus Kattilamäki Dokumentti luotu
2 1 Johdanto 3 2 Projektin eteneminen Projektin suunnittelu (PP) Implementaatio Implementaatio Yhteenveto 8 3 Tavoitteiden täyttyminen 10 4 Loppuanalyysi Työtunnit Ohjelmiston koko Projektin haasteellisuus Vertaistestaus 16 5 Työmenetelmät ja työkalut Työmenetelmät Työkalut 19 6 Opetuksellinen arvo Markus Kattilamäki Kirsi Rönkkö Tuukka Laakso Antti Kettunen Mikko Halttunen Mikko Närjänen Antti Poikela Markku Huttunen 26 7 Kurssipalaute 26 8 Jatkokehitys Spring Quartz Linjan tarkastus Aktiiviset laitteet Releet hälytinkeskuksessa Viestien välitys Tietokanta GSM, sähköposti Komentorivikäyttöliittymä Web-käyttöliittymä Muuta 29 2
3 1 Johdanto T Ohjelmistoprojekti I Projektin oli tarkoitus toimia kurssin T Ohjelmistokehitysprojekti I harjoitustyönä. Tarkoituksena oli toteuttaa laaja ohjelmistoprojekti kahdeksan hengen ryhmässä, toteuttaen ohjelmistoprojektiin liittyviä erilaisia rooleja ja hyväksi havaittuja menetelmiä. Projekti oli tarkoitus toteuttaa ajanjaksolla Kokonaisuudessaan projektin laajuudeksi oli määrätty kiinteästi 1500 tuntia. Projektin asiakkaana toimi Indagon Oy, jonka ehdottama projektin aihe oli. Tavoitteena oli toteuttaa valvottu liittymä. Tämä dokumentti toimii projektin loppuraporttina, kooten projektissa opitut asiat ja pohtien mikä onnistui ja missä olisi ollut parantamisen varaa. Kuva 1: Tilanne ennen projektia Nykyisessä tilanteessaan julkisten ja suurien rakennusten paloturvallisuudelle ja sen valvonnalle on asetettu määräyksiä jotka eivät nykytilanteessa toteudu lähinnä hälytinkanavan luotettavuuden osalta. Järjestelmä vastaa tähän tarpeeseen ja tuo kaivattua luotettavuutta tarjoamalla valvotun liittymän VIRVE-verkossa. Seuraavassa kuvassa on kuvattu tilanne ennen projektin mahdollistamaa ratkaisua. Kuva 2: Tilanne projektin jälkeen 3
4 Projektin lopputuotteen on tarkoitus toimia prototyyppinä yllä kuvatusta järjestelmästä ja tarjota tietoa mahdollisen järjestelmän luotettavuudesta jatkokehitystä varten. Jatkokehitettävän tuotteen tavoitetilassa hälyttimiä valvotaan Valpas-järjestelmällä VIRVEverkon yli. Järjestelmä tarjoaa käyttäjälleen myös kattavat seurantavälineet ja työkalut järjestelmän hallintaan. Lopputuotteella saadaan valvontalinjan luotettavuus nostettua viranomaisten määräämälle tasolle. Tästä dokumentista puuttuvat kaikki projektin laadullisten asioiden analyysi ja pohdinta. Erillisenä dokumenttinaan on luotu laadunvarmistuksen loppuraportti joka kattaa mm. vertaistestauksen ja laatumetriikat. 4
5 2 Projektin eteneminen T Ohjelmistoprojekti I Projekti oli jaettu kolmeen iteraatioon: Projektin suunnittelu, Implementaatio 1 sekä Implementaatio 2. Projektin suunnitteluvaiheen tarkoituksena oli suunnitella tulevaa työtä sekä valmistella seuraavat toteutusvaiheet. Ensimmäisen toteutusvaiheen tavoitteena oli rakentaa ohjelmiston tärkein toiminnallisuus. Implementaatio 2 tärkeimpänä tavoitteena oli kehittää www-selaimella käytettävä käyttöliittymä. Seuraavassa kappaleessa seurataan projektin etenemistä. 2.1 Projektin suunnittelu (PP) Projektin suunnittelu alkoi käytännössä ryhmän muodostamisella. Ryhmä saatiin kasaan tuttujen välityksellä ja roolijako onnistui varsin hyvin. Koska koko ryhmä oli kasassa jo ensimmäiseltä luennolta, saimme varsin hyvin onnistuneen startin kurssille ja projektille. Ongelmia tuotti kuitenkin aiheenvalinta, jossa emme olleet tarpeeksi aggressiivisia ja valmistautuneita hakemaan kurssin tarjoamia miellyttäviä aiheita. Uskoisin että asiakkaan ryhmän valinnassa vaikutti eniten juuri esityö joka meidän ryhmän osalta jäi melko kevyeksi. Toisaalta myös kurssi olisi voinut painottaa hieman enemmän aiheen valintaa. Koska emme saaneet itseämme miellyttävää aihetta, ryhmämme jäsen ehdotti työnantajansa aluillaan olevaa aihetta. Nopealla aikataululla kurssin listaukseen tuotu projektiaihe oli kuitenkin paras ratkaisu motivaation kannalta, koska kaikki halusivat pysyä erossa aiheista jotka liittyivät mobiililaitteisiin. Itse suunnitteluvaihe toteutettiin pääasiassa johtoryhmän toimesta. Tämä johtui osakseen myös kurssin suosituksesta. Tuntien osalta projektin suunnitteluvaiheessa jäätiin tavoitteesta yhteensä 37 tuntia. Suurimpana virhearviona pidettäköön suunnitteluun varattua aikaa. Toisaalta olisi ollut loppuprojektin suhteen parempi että suunnitteluun varatut tunnit olisivat tulleet käytettyä. Myös kehittäjiä olisi voinut sitouttaa enemmän tuotteen suunnitteluun alkuvaiheessa. Työskentelytahtia jouduttiin myös kirimään vaiheen loppua kohden. Tässä vaiheessa ryhmän työskentely haki vielä muotojaan. Suunnitteluvaihe oli muutenkin tutustumista ryhmään, aiheeseen ja asiakkaaseen. Vaihe oli varsin dokumenttipainotteinen ja varsin vaativa, koska loppujärjestelmän hahmottamisessa oli vaikeuksia. 5
6 Kuva 3: Projektin suunnitteluun käytetyt tunnit osa-alueittain Projektin suunnitteluvaihe oli myös tärkeä johtoryhmän toiminnan muodostumiselle. Vaiheen tuotokset olivat pääasiassa dokumentteja, tärkeimpinä projektisuunnitelma ja vaatimusmäärittelydokumentti. Näiden muodostamisessa työtaakkaa olisi ollut hyvä hajauttaa useiden ihmisten kesken, jotta niihin olisi yhden henkilön näkemyksen sijasta saatu useampaa näkökulmaa. Toisaalta dokumenttien työstäminen tässä vaiheessa vaikutti dokumentoinnilta dokumentoinnin ja kurssin vaateiden takia. Arkkitehtuurin suunnittelu oli myös vaiheen oleellinen tuotos. Jälkeenpäin tarkasteltaessa arkkitehtuuri oli melko kattava ja onnistunut mutta olisi kaivannut osakseen vielä syvempää panostusta. 2.2 Implementaatio 1 Implementaatio 1 alussa projekti saatiin vauhtiin täydellä teholla. Oleellista projektin aloittamiselle oli saada kaikki kehittäjät aktiivisiksi ja tietoisiksi projektin vaateista. Vaiheen alussa pidimme vapaamuotoisemman kick-offin jossa projektin toimintaa ja tavoitteita käytiin läpi. Kick-off toimi hyvänä aloituksena projektille. Iteraatiolle oli varattu varsin runsaasti tehtävää jokaiselle ryhmän jäsenelle ja varsinkin loppupuolella vaiheen raskaus rupesi näkymään työssä. Myös tehdyt työtunnit raahasivat suunnitellusta perässä ja niiden kiinni ottaminen kävi työstä. Osaltaan tähän oli vaikuttamassa seurannan lievä puutteellisuus. Toteutuksen ja suunnittelun välinen ero saatiin kuitenkin kirittyä kiinni ennen iteraation loppua. Myös joulun mahdollistama tauko tuli jokaiselle projektin jäsenelle tarpeeseen. 6
7 Kuva 4: Implementaatio 1 toteutuneet ja suunnitellut tunnit osa-alueittan Työmäärän arviointi oli kehittynyt edellisestä vaiheesta. Toteutuneet työt vastasivat suunniteltuja osa-alueittain erityisen hyvin. Henkilömäärän lisääntyessä ja uudehkon aiheen vaikutuksesta etenkin kommunikoinnin merkitys korostui. Toisaalta tärkeimmän toiminnallisuuden kehittäminen vei aikaa kunnolliselta laadunvarmistukselta. Etenkin sovittujen yksikkötestien kirjoittamisessa kehittäjillä oli hankaluuksia. Täten testaus jäi viime tippaan. Myöskään laadunvarmistusprosessin tehokas toteuttaminen ei onnistunut. Johtoryhmän osalta jakso meni suurelta osin projektin vetämistä opetellessa. 2.3 Implementaatio 2 Projektin viimeisen vaiheen tarkoitus oli valmistaa järjestelmälle web-käyttöliittymä, jatkaa toteutetun toiminnallisuuden laadunvarmistusta sekä mahdollistaa järjestelmän luotettavuudesta statiikkaa. Uuden toiminnallisuuden rakentaminen oli mahdollista näiden suoritteiden jälkeen, kuitenkin ennen lopputuotoksen vertaistestaukseen toimittamista. Tavoitteenamme iteraation suorittamisessa oli parantaa osaltaan myös projektin johtamista ja seurantaa. Tässä onnistuttiin uuden tuntiseurannan myötä sekä jakamalla viikkokohtaiset tehtävät tarkemmin henkilöille edelliseen vaiheeseen verrattuna. Projektin viimeiselle vaiheelle oli varattu melko lyhyt ajankohta vuoden alusta. Onnistuimme saamaan kaikki loman jälkeen projektin pariin varsin hyvin. Työskentely oli myös toimivampaa ja kommunikaatio pelasi paremmin projektin edellisiin vaiheisiin verrattuna. Jos projektia tultaisiin tästä vielä jatkamaan, voisi myös tavoitteiden asettelua nostaa. 7
8 Suurimpina ongelmina koettiin kokonaistuntien riittämättömyys henkilöittäin sekä kokonaisuudessaan. Tiettyjen järjestelmän osien avainhenkilöiden tunnit kuluivat liian nopeasti ja tehtäviä jouduttiin uudelleen resursoimaan. Ennen vertaistestausvaihetta toiminnallisuuden ollessa valmis, huomattiin että Valpas ei toimi. Tämän seurauksena pelättiin että projekti epäonnistuu. Tämä johti osaltaan myös syyttelyyn. Kuva 5: Implementaatio 1 toteutuneet ja suunnitellut tunnit osa-alueittan 2.4 Yhteenveto Projekti saatiin suoritettua kohtuullisen hyvin aikataulussa sekä laatutavoitteissa. Aikataulun suhteen jouduimme kuitenkin kirimään toteutusvaiheiden puolivälin jälkeen. Toisaalta ensimmäistä projektia suoritettaessa työarviot olivat todella hyviä. Jälkeenpäin katsottuna työskentelyä olisi voinut tehostaa. Tälläkin asetelmalla tehokkuus oli kuitenkin projektin onnistuneen suorituksen tasolla. Projektin loppuvaiheessa ilmeni haastavia suorituskyvyllisiä ja aikataulullisia ongelmia. Suorituskyvyllisiin ongelmiin syynä oli tarpeellisen testaustason puutteellisuus sekä joululoman aiheuttamat kommunikaatio-ongelmat tällä saralla. Tämän johdosta jouduimme hieman tinkimään suunnitelluista työtehtävistä. Toisten tehtävien laajemmalla tutustumisella ja toteuttamalla järjestelmää vähemmän hajautetusti, kriittisten ja yksilöriippuvaisten resurssien määrää olisi saatu pienennettyä. Projekti lähti todella vaivalloisesti käyntiin. Alussa kului runsaasti turhaa aikaa aiheen metsästämiseen. Motivaatio olisi ollut todella surkea lähteä jämäaiheita tekemään, mutta onneksi saimme aiheen "suhteilla". Tämän seurauksena oli se ongelma, että asiakas ei 8
9 ollut ehtinyt valmistella aihetta kovinkaan paljon. Tästä taas seurasi, että koko suunnitteluiteraatio meni aiheen speksaamiseen eikä niinkään sen suunnitteluun. Kun pohja oli näinkin varma, implementaatio 1 kului kalenteriaikaa ihmettelyyn ja varsinaisiin hommiin päästiin aika myöhään. Tästä syntyi paljon paineita kaikille projektiryhmän jäsenille ja aikataulu saatiin hätäisesti kirittyä iteraation loppuun mennessä toteutuksen osalta, testaus jäi todella vähäiseksi. Testauksen suuremmat ongelmat olivat kuitenkin projektiryhmästä riippumattomia, tästä lisää myöhemmin. Toinen iteraatio puolestaan on maistunut hyvin monelle pelkältä pakkopullalta. Suurimpana syynä tähän on ollut tunnit. "Oikeissa" projekteissa oltaisiin hyvinkin tyytyväisiä siihen että budjetti pystytään alittamaan, kurssin tapauksessa taas pitää pyrkiä mahdollisimman lähelle nollaa. Tästä taas seuraa se, että mielekästä tekemistä ei ole aina ollut. Kaikista suurimpia ongelmia projektin etenemiselle ovat kuitenkin antaneet ulkoiset tekijät. EPA oli täysi murheenkryyni koko ensimmäisen iteraation ajan, pidän ihmeenä sitä, että saimme ensimmäisen kehitysiteraation demossa ylipäätään demottua järjestelmäämme. Iso osa testauksen urakasta meni hukkaan, kun EPAssa oli ongelmia. Toisessa iteraatiossa testauksen ongelmana puolestaan oli, että tarvittavaa laitteistoa eli puhelimia ei saatu tarpeeksi ajoissa. Tämän puutteen johdosta pitkäaikaista testausta ei pystytty ajoissa suorittamaan ja tietenkin kun se vihdoin saatiin tehtyä, havaittiin Valppaassa suuria ongelmia vakaudessa - kaksi viikkoa ennen projektin loppua. 9
10 3 Tavoitteiden täyttyminen T Ohjelmistoprojekti I Seuraava kappale tarkastelee projektin tuloksia sille asetettuja tavoitteita vastaan projektiryhmän, asiakkaan ja vertaistestausryhmän näkökulmasta. Päällimmäinen tavoite projektille opiskelijoiden opintojen kannalta oli kurssin suoritus hyvällä arvosanalla. Tähän tavoitteeseen tullaan pääsemään. Jokaiselle on varmasti jäänyt tekemisestä myös oppia ohjelmistoprojektissa toimimisesta. Tämä dokumentti kerää yhteen myös kaikkien kokemukset. Projekti saatiin myös tavoitteiden ja laajuuden mukaisesti päätökseen ilman vakavia ongelmia. Projekti toimitetaan asiakkaalle ja heidän kommenttiensa mukaan projektia tullaan kehittämään kohti lopullista tuotetta. Taulukko 1: Projektiryhmän asettamat tavoitteet projektille ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus vähintään arvosanalla 4 R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen R5 Projektin loppuun saattaminen Oppimiskokemusten kerääminen projektin jälkeen, oppimisen toteaminen Projektin tyydyttävä suoritus Asiakas päättää projektin perusteella jatkokehittää tuotetta Kurssin laajuuden täyttäminen ja suoritusmerkinnän saaminen Taulukko 2: Asiakkaan projektille asettamat tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen ja sen soveltuminen jatkokehitykseen. A2 Tetra-verkon käytettävyyden lisäselvitys A3 Kaupallistamisen selvittäminen A4 Aihealueesta oppiminen ja tietämyksen laajentaminen asiakkaan taholta A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Teknisen neuvojan tavoitteena lopputyön tekeminen aiheesta Prototyypin toimivuus ja skaalautuvuus sekä Tetra-verkon soveltuvuus käyttötarkoitukseen. Prototyypin toimivuus ja sopivuus sekä kaupalliset näkymät. Projekti tuo organisaatioon uutta osaamista ja tietoa aihealueesta. Asiakkaan prosessien kehittyminen ja menetelmien oppiminen. Projekti auttaa ja mahdollistaa lisätietoa aiheesta. Projektin hyödyllisyyden arvio lopussa teknisen neuvojan toimesta. 10
11 Asiakkaan vaatimukset projektille muuttuivat hieman projektin kuluessa. Viimeisessä vaiheessa asiakkaan pääasiallinen vaatimus oli saada järjestelmän luotettavuudesta kattavaa tietoa. Kuten alussa asia nousi esille, osa asiakkaan vaatimuksista on melko vaikea verifioida näin projektin lopussa. Asiakkaalta ei saatu annettuun määräaikaan mennessä kunnollisia kommentteja omista tavoitteidensa täyttymisestä. Loppudemossa asiakas arvioi projektia kokonaisuutena ja silloin on mahdollista saada asiakkaan tavoitteiden täyttymisestä lisätietoa. Pääasiassa asiakkaan tavoitteet voidaan katsoa täytetyksi. 11
12 4 Loppuanalyysi T Ohjelmistoprojekti I Seuraavassa kappaleessa on käyty läpi projekti numeerisesti. Kappaleessa esitetään työtuntien kehittyminen, laatumetriikoita sekä ohjelmiston koon kehitystä. 4.1 Työtunnit Kuva 6: Henkilöiden työn jakautuminen osa-alueittain 12
13 Kuva 7: Tuntikehitys henkilöittäin Kuva 8: Ensimmäisen vaiheen tuntikehitys 13
14 Kuva 9: Toisen vaiheen tuntikehitys 14
15 Kuva 10: Viimeisen vaiheen tuntikehitys (I2) Kuva 11: Tuntien jakautuminen osa-alueittain 4.2 Ohjelmiston koko Taulukko 3: Ohjelmiston koodirivien määrä 4.3 Projektin haasteellisuus Projektin aihe oli mielestämme keskihaastava. Rakensimme järjestelmän alusta alkaen toisin kuin osa muista projekteista. Myös sovellusalue oli ympäristönä haastava. Onnistuimme kuitenkin hyvin vastaamaan aihealueen haasteisiin ja toteuttamaan haluttu 15
16 toiminnallisuus ja sille asetetut vaatimukset. Projektin suurimmat haasteet voitaisiin jakaa kahteen osa-alueeseen: Asiakkaan toiminta loi ongelmia: Asiakkaan edustaja vaihtui kesken projektia joka osaltaan loi epävarmuutta projektin epävarman aloituksen lisäksi. Asiakkaan yhteyshenkilön vaihtuminen toi osaltaan lisätyötä ja nollasi siihen mennessä rakennetun asiakaskontaktin. Myös teknisen asiantuntijan työsuhteen lopettaminen vaikeutti resurssien (testipuhelimien ja muun materiaalin) saamista. Asiakkaan taholta löysä asenne kommunikaatiota kohtaan vaikutti kriittisten päätösten tekemisen nopeuteen ja projektin etenemiseen. Tämä tuli esille vastaamattomuutena sähköposteihin ja kyselyihin ongelmista. Asiakkaan paremmalla sitoutumisella projektiin, olisimme päässeet etenemään projektissa nopeammin ja ilman turhaa vaivaa. Projektista riippumattomat ongelmat: Projektin vaikuttamattomissa olevista asioista johtuen jouduimme tekemään kompromisseja sekä uudelleen aikatauluttamaan ja resursoimaan projektin työtä. Eritoten kolmannesta osapuolesta riippuva Edustapalvelin (EPA) aiheutti päänvaivaa. Se ei valmistunut aikataulussa ja aiheutti muitakin ongelmia. Projektin kehittäminen meistä riippumatonta alati muuttuvaa järjestelmää vasten oli haasteellista. Mm. projektin testaus viivästyi osittain EPA:n epästabiiliuden takia. Tietoturvatason takia projektiryhmä ei saanut missään vaiheessa suoraa yhteyttä EPA:n missään vaiheessa. Sitä ei myöskään päästy itse testaamaan missään vaiheessa. 4.4 Vertaistestaus Mikko Halttusen mukaan: Vertaistestausta suoritettiin kahden hengen voimin toiselle ryhmälle käyttämällä exploratory testing menetelmää. Testattavan ohjelman tehnyt ryhmä oli valmistellut 5 erilaista testi tapausta, joiden mukaan tuli testata. Itselleni kokemus tämän tyylisestä testaamisesta oli melkoisen uusi. Olen muutamia kertoja aikaisemmin testannut samalla tavalla, vaikkakaan silloin ei ole tullut käytettyä Session-Based Test Management:ia. Tästä syystä vertaistestaus oli erittäin valaiseva kokemus ja herätti ajatuksia testaamisesta perinteisesti määriteltyjen testitapauksien sekä exploratory testingin avulla. Tämän lisäksi oli erittäin mielenkiintoista nähdä, minkälaisen systeemin toinen ryhmä oli onnistunut kasaamaan samassa ajassa kuin oma ryhmäni. Molemmille testaajille määritelty 5 tuntia testaamista oli kohtuullisen paljon toisen ryhmän ohjelmaan käytettynä. Vertaisryhmän ohjelmasta ei tullut mukana dokumentaatiota siitä miten sen olisi pitänyt esimerkiksi laskea tuloksia, vaan testitapauksissa luki, että ei ole väliä sillä, mitä tuloksia ohjelma antaa. Jos ei tiedä kunnolla mitä ohjelma tekee tai tulisi tehdä, on virheiden ja ongelmakohtien löytäminen melkoisen hankalaa ja tuskaista. Asiaa ei myöskään auttanut se, että jokaisessa testissä fokuksena oli pyrkiä toimimaan kuin laitteen loppukäyttäjä, mikä taas ei kertonut minulle testaajana yhtään mitään. Loppukäyttäjä voi tehdä mitä tahansa, etenkin kun ohjelmaa tulevat käyttämään opiskelijat. Nämä molemmat yhdistettynä voisin sanoa, että vaikka ohjelmasta löytyikin ongelmakohtia, olisi niitä varmasti löytynyt enemmän jos olisi oikeasti ymmärtänyt mitä tekee. Tästä johtuen en pystynyt testaamaan järjestelmää kuin yhden tai kaksi tapausta päivässä. 16
17 Vaikka lähdin erittäin tehokkaasti tutkimaan ohjelmaa ja yritin panostaa siihen, että testaus olisi mahdollisimman hyödyllinen vertaisryhmälle, oli viimeisten testien tekeminen hampaat irvessä vääntämistä. Tämän myös huomannee löytyneiden bugien määrästä. Ensimmäisessä testissä löytyi puolet kaikkien sessioiden ongelmista, toisessa sessiossa jäljellä olevista puolet jne.. Suuri osa käytetystä ajasta meni myös miettimiseen, että onko tavattu ongelma bugi vai olisiko se mahdollisesti tarkoitus toimia kyseisellä tavalla. Vertaisryhmä sai varmasti runsaasti uusia bugeja, mutta uskon, että ne bugit, jotka löysin, olisi vertaisryhmä löytynyt myös käymällä yksinkertaisesti läpi ohjelman toiminnallisuuden kohta kohdalta. Tähän tuskin olisi mennyt puoliakaan siitä ajasta mitä itse kulutin ohjelman opetteluun ja turhaan säätämiseen. Uskon, että testaus olisi ollut tehokkaampaa, jos se olisi suoritettu useammassa osassa projektin eri vaiheissa. Esimerkiksi toisen iteraation alussa sekä lopussa. Tällöin ryhmä olisi päässyt korjaamaan bugeja heti toisen iteraation alussa, sekä itse olisin päässyt tutustumaan ohjelmaan aikaisemmassa vaiheessa, jolloin toisen vaiheen testaus olisi sujunut vielä paremmin. 17
18 5 Työmenetelmät ja työkalut Seuraavassa kappaleessa on käyty läpi kurssin vaatimat työmenetelmät ja työkalut sekä kokemukset niiden käytöstä ja sopivuus projektiin. 5.1 Työmenetelmät Iteratiivinen kehitys Projekti oli hajautettu kolmeen vaiheeseen ts. iteraatioon. Kaksi varsinaista toteutusiteraatiosta oli varsin vähän todelliseen iteratiiviseen kehittämiseen. Todellista hyötyä sillä olisi saatu n. kuukauden mittaisista useammasta jaksosta. Toisaalta Nykyisen iteraatiot jaksottivat varsin hyvin projektin kulkua Iteraatioiden suunnittelu Ennen jokaista iteraatiota tehtävät ja kokonaisuudet suunniteltiin ja resursoitiin. Suunnittelun tuloksena jokaisesta vaiheesta valmistui iteraatiosuunnitelma. Iteraatiosuunnitelma sisältämien asioiden kommunikointiin olisi voinut kiinnittää ensimmäisessä vaiheessa enemmän huomiota ja varmistaa että kaikki lukisivat ja ymmärtäisivät sen. Tässä parannettiin huomattavasti viimeiseen iteraatioon mentäessä Dokumentointi Emme saaneet käytettyä dokumentaatiota kommunikoimaan projektiin liittyviä tietoja tehokkaasti kaikille osapuolille johtuen sen paljoudesta ja ryhmän viitsimättömyydestä. Dokumentaation lukemiselle ja ajantasaistamiselle olisi voinut varata enemmän aikaa ja seurata sen toteutumista. Välillä kurssin vaatimien dokumentaatioiden luomisen tarkoitus oli ennemminkin dokumentaatio itse Riskienhallinta Riskien hallinnalle suunniteltiin projektin alussa prosessi jossa niitä seurataan viikoittain johtoryhmän viikkopalaverissa. Riskien viikoittainen perusteellinen läpikäynti vaikutti hieman turhalta, joten sykliä päätettiin hieman pidentää. Riskejä päivitettiin sitä mukaan kun johtoryhmän palaverissa asioita nousi esille. Harva kriittinen riski pääsi toteutumaan. Vältimme myös suuret työn tekemistä ja jatkamista estävät riskit Tuntiraportointi Tuntiraportointi oli oleellisin mittari projektin seurannan ja työn edistymisen kannalta. Tuntiseurantaan erikoistuneen järjestelmän puuttuessa seurantaan käytettiin pääasiassa Wikiä sekä Exel-taulukkoa. Itse seurantaprosessin alkuvaiheen ongelmat saatiin ratkaistua projektin edetessä ja seurantaprosessia kehitettyä. Toteutuneet tunnit raportoitiin Wikissä viikoittain. Myös tunturaportointiin ja sen suunnitteluun olisi voinut varata enemmän aikaa varsinkin projektin alkuvaiheissa. 18
19 5.1.6 Ohjelmiston koon raportointi T Ohjelmistoprojekti I Projektissa ohjelmiston koon raportointi jäi melko huteraksi. Ohjelmiston kokoa ei juuri julkaistu kuin iteraatiodemossa. Kokoa olisi ollut hyvä seurata viikoittain ja julkaista se Wikissä. Seurannan puute johtui käytännössä että sille ei ollut varattu aikaa eikä varsinaista vastuuhenkilöä Kommunikaatio Kommunikaatio osoittautui projektin onnistumisen kannalta oleelliseksi. Vaikka olimme miettineet kommunikaatioprosesseja, olisi niiden toimintaan saattamiseen voitu panostaa vielä enemmän. Puhelu, tekstiviesti, IRC, sähköposti, Wiki ja palaverit olivat ensisijaisia kommunikaatiokanavia. Ylivoimaisesti suosituimmaksi kommunikaatiokanavaksi osoittautui IRC, Iteraatiodemot Iteraatiodemot olivat hyvä keino kommunikoida projektin tilaa ja tuotoksia asiakkaalle sekä mentorille. Toisaalta kurssin antama valmis kalvopohja rajasi ja ohjasi demoa tiettyyn suuntaan. Demon vaatimukset olivat myös melko hämäriä. Paransimme demojemme ulosantia projektin edetessä ja eritoten I1 jälkeinen demo oli varsin onnistunut. Muita demoja vaivasi turha rikkonaisuus sekä epäoleelliset asiat. Demojen tarkoitus olisi ilmeisesti ollut myydä tuotetta, kaunistella tuloksia ja projektia. Tarkastelimme kuitenkin tuotoksiamme objektiivisesti joka mielestäni johti huonompiin arvosanoihin. Kurssin järjestelyssä painotetaan virheiden myöntämiseen projektin aikana oppimistarkoituksessa mutta arvosana perustuu osittain juuri epäonnistumisiin sekä dokumentaation oikeellisuuteen Vaatimusten hallinta Vaatimusten hallinta jäi projektin edetessä hieman oman onnensa nojaan johtuen resurssien puutteesta ja väärästä allokoinnista. Osittain vaatimusten hallinta kaatui kurssin vaatimaan mahdottoman pitkään dokumenttiin jota oli vaikea pitää päivitettynä asiakkaan nopeastikin muuttuvien vaatimusten suhteen. Pyrimme kuitenkin pääasiassa tarkistamaan huolellisemmin vaatimukset jokaisen iteraation alussa, jotta tiesimme minne mennä Vertaistestaus Vertaistestauksen suorittamiseen käytettiin melko vähän resursseja (n. 10 h). Tavoitteenamme oli arvioida lähinnä asennus- ja käyttöohjetta sekä toiminnallisuutta pääosin. Järjestelmää tuntemattomien henkilöiden edut saatiin käytettyä juuri tämän kaltaisessa tehtävässä. Toisaalta samantasoisen testauksen suorittaminen itsenäisesti olisi voinut tuoda tehokkaampaa laadunvarmistusta itse järjestelmän toiminnallisuuteen. 5.2 Työkalut CVS Käytimme projektissa ohjelmiston versionhallintaan CVS:ää. Ilman kunnollista versionhallintaa tämän kokoinen projekti ei olisi pysynyt hallinnassa. Työkalun käytössä 19
20 ongelmana oli että versiomme ei ollut täysin yhteensopiva käyttämämme Eclipsen version kanssa. Välillä ajantasaisesta versiosta jouduttiin keskustelemaan ja kyselemään ennen toimenpiteitä. Välillä projektin alussa sopimamme versionhallinnan käytännöt myös rakoilivat. Paremmalla työkalulla versionhallinta olisi onnistunut helpommin. CVS:n tilalle ehdotettaisiin esim. SVN:n käyttöä (Subversion, kilpaileva versionhallintasysteemi) MoinMoinWiki Projektin Wiki toimi varsin onnistuneesti apuna projektin kommunikaatiossa. Wikin vahvuuksia oli helppokäyttöisyys sekä saavutettavuus. Dokumentteja kehitettiin sen kautta, jolloin saimme dokumentteihin kaikkien näkemyksen koottua. Toisaalta dokumenttien kokoaminen Wikissä oli haastavaa. Tehtävien ja tuntien hallintaan olisi voitu käyttää tehokkaampaa työkalua. Wikin rakenteeseen olisi tullut kiinnittää enemmän huomiota ja sille olisi pitänyt varata aikaa ja henkilö ylläpitämään sitä. Nyt osa tärkeästäkin tiedosta hukkui usean otsikon alle. Wikin lukemista olisi pitänyt painottaa myös enemmän kehittäjien keskuudessa Bugzilla Käytimme bugiraportointiin Bugzillaa. Sen toiminnallisuus vastasi tarpeitamme kohtuullisesti. Sen käyttämisessä oli projektin aikana joitain ongelmia, kuten bugien kriittisyyden väärät merkinnät ja ääkkös-ongelmat. Työkalua oli välillä vaikea hahmottaa ja raportoinnin kannalta se ei välttämättä ollut kovinkaan järkevä työkalu. Työkalulta olisi myös toivottu samalla tehtävien hallintaa JUnit Kehittäjät tuppasivat välillä unohtamaan yksikkötestien tekemisen ja JUnitin käyttämisen. Heidän mielestään työkalu toi projektiin lisää turhaa säätöä ja overheadia. Kaikkia testejä oli vaikea saada toimimaan Apache ant:lla ajettuna vaikka kehittäjät olivat testeistään varmoja. Kehittäjistä yksikkötestausten tekeminen olisi voitu jättää vain kriittisille osille jos projektia ei toteuteta testivetoisella kehityksellä (Test Driven Development). Toisaalta yksikkötesteillä ja työkalulla saatiin tietoa laadusta ja testien tekeminen auttoi kehittäjiä myös koodin suunnittelussa. Testien ansiosta löydettiin bugeja ja testit auttoivat hahmottamaan jos jotain meni muutoksissa rikki Cobertura Coberturaa käytettiin ilmaisemaan yksikkötestien kattavuutta. Työkalu vaati ryhmän mielestä turhaa säätöä. Työkalun nähtiin ilmaisevan tärkeitä mittareita, mutta koska JUnit:n kanssa oli paljon ongelmia, raporttien luominen oli haasteellista. Kritiikkiä nousi myös esille työkalun kertoessa testien kattavuudesta, mutta ei mitään niiden laadusta Quartz Käytimme projektissamme Quartz-nimistä skeduloijaa. Quartz toimi osaltaa projektin selkärankana. Koska projektiryhmällä ei ollut aikaisempaa kokemusta työkalusta, ongelmista oli vaikea välttyä. Toisaalta myöskään oman skeduloijan tyhjästä kirjoittaminen ei olisi onnistunut. 20
21 5.2.7 IRC T Ohjelmistoprojekti I Projektin kommunikaatiota hoidettiin varsin tehokkaasti IRC:n kautta. Perustimme useamman kanava kattamaan projektin eri ryhmien tarpeet. IRC:n puolidokumentoiva kommunikaatio oli hyvä. Täten ihmiset pysyivät kärryllä lukemalla käytyjä keskusteluja. IRC helpotti tiedonkulkua ja mahdollisti asioiden kertomisen laajalle joukolle yhtä aikaa. IRC oli kommunikaatiovälineenä oleellinen osa projektia. Kaikkea keskustelua oli kuitenkin hankala seurata jälkeenpäin, jos se ei koskenut itseä Eclipse Käytimme projektin kehityksessä Eclipse kehitysympäristöä (IDE). Se vastasi hyvin tarpeisiimme ja sai hyvää palautetta kehittäjiltä. Toimiva kehitystyökalu oli yksi onnistuneen projektin kulmakivistä. 21
22 6 Opetuksellinen arvo T Ohjelmistoprojekti I Seuraavaan kappaleeseen on kerätty projektin jokaisen jäsenen ennen projektia asettamat tavoitteet sekä seurattu niiden täyttymistä ja muuta opetuksellista arvoa. Osallistujat kertovat seuraavassa projektista. Taulukko 4: Projektin jäsenten oppimistavoitteet projektin alussa Jäsen Oppimistavoite Kattilamäki Saada kokemusta ohjelmistoprojektin vetämisestä ja oppia tehokkaita menetelmiä projektin läpiviemiseksi. Laajentaa näkemystä ohjelmistoprojektista ja sen eri vaiheista. Laakso Rönkkö Huttunen Poikela Närjänen Halttunen Kettunen Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita. Lisäksi tavoitteena on kehittyä testauksen saralla sekä oppia luottamaan enemmän muiden työhön ja keskittyä paremmin omaan. Uusien tekniikoiden oppiminen, kommunikointi laajemmassa projektissa sekä oman ajankäytön ja arvioinnin parempi hallitseminen Aiemman testauskokemuksen puuttuessa pääasiallisena tavoitteenani on oppia rooliin kuuluvat tehtävät ja käytännöt. Projektin koko tuo mukanaan haasteita, joten oppia projektin kulkuun vaikuttavista asioista, esimerkiksi tiimin sisäisestä kommunikoinnista ja asiakkaan kanssa toimimisesta. Ryhmätyötaitojen kehittäminen, laajemman projektin toimintaan tutustuminen, uusien työkalujen (Borland Together, JUnit, jne.) käytön oppiminen, ohjelmointitaitojen kehittäminen. Laajentaa tietoani ohjelmistoprojekteiden kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Yksikkötestauksen oppiminen ja käyttäminen. Oppia soveltamaan käytännössä uusia ohjelmiston tuottamisen käytäntöjä sekä oppia niiden käyttökelpoisuus erilaisissa tilanteissa. 6.1 Markus Kattilamäki Roolini projektipäällikkönä oli varsin haastava ja erilainen kuin ennalta saattoi odottaa. Opintojen kautta kerääntyneestä projektikokemuksesta ei ollut niin paljon apua kuin olisi osannut kuvitella. Suurimman haasteen projektin vetämiseen toi ehdottomasti sen hajautettu luonne. Tämän takia vuorovaikutus ja kommunikaatio keskittyivät pääosin sähköisiin kanaviin. Myös työn seuranta jäi lukujen tuijottelun asteelle, koska konkreettista ja jatkuvaa kontaktia kehittäjiin ei ollut. Projektin vetämistä olisi helpottanut jos olisi varannut itselleen myös pienen roolin tuotteen kehityksessä. Tavoitteiden mukaisesti projektipäällikön rooli tarjosi näköaloja projektin kaikkiin osa-alueisiin ja vaiheisiin. Kokemus projektin vetämisestä karttui ja hyödyllisimmäksi työkaluksi osoittautuivat vuorovaikutustaidot. 22
23 6.2 Kirsi Rönkkö T Ohjelmistoprojekti I Tavoitteeni oli oppia paremmin projektin vetämistä, laadunvarmistukseen liittyviä asioita ja delegointia. Tavoitteet ainakin jollakin tasolla myös saavutin. Ainoat puutteet tavoitteiden täyttymisessä koen vaatimustenhallinnan tasossa. Aihe on vaativa, työkalut vähissä ja loppupeleissä roolini projektin johtoryhmässä ehkä hivenen väärä kunnolliseen vaatimustenhallintaan. Projektin johtaminen tuntui ensimmäisen iteraation kohdalla hyvin kaoottiselta. Tieto ei tuntunut liikkuvan riittävästi, asioista oli vaikea tehdä konkreettisia ja projektin tilaa oli vaikea hahmottaa. Resurssien käytön hallinta ei myöskään tuntunut toimivan. Itse en ehkä myöskään tiennyt miten asiat oli aikataulutettu ja miten tai milloin tehtävät olisi tullut hoitaa. Tuntui, että asioihin kyettiin reagoimaan hyvin hitaasti. Asioita oli myös vaikea korjata "kesken" iteraation. Toinen iteraatio toimi mielestäni paremmin. Aikataulutus oli tehty viikkotasolle edellisestä iteraatiosta opittujen virheiden korjaamiseksi. Omalta osaltani asiaa auttoi myös huomattavasti se, että johtuen projektipäällikön tuntien vähyydestä, olin vahvasti mukana tehtävien ja aikataulun suunnittelussa. Se, ettei projektipäällikkö osallistunut tähän toi kuitenkin mukanaan ongelmia. Iteraation alussa tuntui, että projektipäällikkö oli tietyllä tavalla kadonnut projektista. Asia onneksi nostettiin molemmin puolin esille johtoryhmän kokouksessa ja tilanne parani. Koen oppineeni asioita johtamisesta. Havaitsin, että ilman kunnollista aikataulusuunnitelmaa ja sen päivittämistä, projektin seuranta on lähes mahdotonta. Opin myös, että hienot suunnitelmat eivät kovin helposti välity johtoryhmästä alemmille tasoille varsinkaan dokumenttien välityksellä. Lisäksi asioita pitää kerrata riittävän usein tai ne vain unohtuvat, kuten JUnit-testien teko joululoman jälkeen. Olen myös tajunnut miten suuri merkitys on kasvokkain kommunikoinnilla tai ylipäätään sillä, että on kanssakäymisessä muiden projektin tekijöiden kanssa. Projektiryhmän johtamista voi kyllä myös kohdaltamme parantaa. Vastuunjako eri asioiden välillä oli määritelty, samoin johtovastuut henkilöiden suhteen. Toisessa iteraatiossa testausta suorittivat käytännön syistä kehittäjät. Alussa tämä oli vaikeaa, koska kehittäjät kuuluivat pääarkkitehdin alaisuuteen, mutta testaukseen liittyvät asiat olivat vastuullani. Tällaisissa tilanteissa ei ollut selkeää pelisääntöä siitä kuka hoitaa ja mitä. Toinen roolien välinen ongelma oli laadunvarmistuksen ja testauksen välillä. Vaatimustenhallinta ja erilaiset muut asiat veivät aikaani niin paljon, että testitapausten miettimien jäi testaajan vastuulle. Tämän jälkeen testauksen hallinta oli hyvin haasteellista. Suosittelen lämpimästi, että laadunvarmistuksesta vastaava henkilö vastaa vain laadusta ja suunnittelee siihen liittyen testitapaukset. Testaajan tehtäväksi jäisi sitten enemmän itse testaaminen ja sen raportointi. Tällöin laadunvarmistukseen saataisiin helpommin myös seuranta johtoryhmään asti. Lisäksi vaatimustenhallinta sopii paremmin pääarkkitehdin toimenkuvaan. Tällöin on helpompi suorittaa vaatimusten tilan seurantaa samalla kun kerää tietoa siitä missä vaiheessa kehittäjät kulloinkin menevät. Huomaan myös, että omista taipumuksistaan on vaikea luopua. Toisessa iteraatiossa jouduin rankalla kädellä delegoimaan asioita muille, sillä omat tuntini olivat vähissä. Oli 23
24 vaikea luottaa siihen, että asiat saadaan aikaan myös vähemmällä omalla panostuksella. Toisaalta on myös vaikea saada muita sitoutumaan asioihin samalla tavalla kuin itse on. Asiakkaan puolelta oli myös vaikea havaita sitoutumista, vaikka tiedän, että tekemämme projekti oli tärkeä. Siitä huolimatta vastauksia maileihin ei aina kuulunut, projektiin vaikuttavista asioista ei ollut tietoa. Asia nostettiin jossain vaiheessa pöydälle, mutta loppujen lopuksi tilanne ei korjaantunut kuin hetkeksi. Yleisesti ryhmän toiminnasta sanoisin, että meitä vaivasi kokemattomuus. Johtoryhmä on lukenut ohjelmistoprojektien hallinasta jo aika paljon. Silti osa tärkeistä kursseista oli käymättä: vaatimustenhallinta, arkkitehtuuri, testaus. Osaa kursseista käytiin kyllä samaan aikaan, mutta projekti olisi varmasti hyötynyt siitä, että nämä kurssit olisivat olleet täysin suoritettuja ennen tämän kurssin alkamista. Väitän, että silloin ihmisillä olisi ollut enemmän näkemystä omiin tehtäviinsä. 6.3 Tuukka Laakso Kurssin alussa asetin itselleni kaksi tavoitetta: oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä. Kehittäjäryhmämme oli onneksi mukavan helposti johdettava, joten suuria ristiriitoja en joutunut selvittämään. Suurelta osaltaan tämä johtui tietenkin siitä, että ryhmä tunsi toisensa jo entuudestaan. Tästä huolimatta koen, että olen kurssin aikana saanut arvokasta kokemusta töiden jakamisesta taidoiltaan erilaisille kehittäjille ja kommunikaation osittaisesta hankaluudesta täysin hajautetussa projektityöskentelyssä. Varsinaisista arkkitehdin tehtävistä ei kovinkaan runsaasti kokemusta tullut, roolini kun muodostui enempi johtavaksi kehittäjäksi kuin varsinaiseksi arkkitehdiksi. Tämä siitä syystä, että jo projektin varhaisessa vaiheessa havaitsimme, että järjestelmä on todella monimutkainen yhden henkilön kovinkaan pitkälle suunniteltavaksi. Lisäksi projektin alussa ei kovinkaan pitkään suunnitteluvaiheeseen loppujen lopuksi ollut aikaa, vaan kehittäjät piti saada nopeasti töihin, jotta tunteja saatiin kulumaan. Joten arkkitehtuurilliseksi tehtäväksi minulle jäi lähinnä järjestelmän jakaminen osiin ja kehittäjien vastuiden jakaminen eri järjestelmän paloille. 6.4 Antti Kettunen Kurssista paistoi monessa kohtaa läpi "pääasia, että dokumentaatiot on kunnossa" - asenne, joka vaikeutti siihen vakavasti suhtautumista. Opetuksellisista tavoitteista täyttyi aika harva, tosin en niitä kovin tarkkaan kirjannut projektia aloitettaessa. Halusin kokeilla uusia menetelmiä ohjelmistotuotannossa, mutta nämä jäivät loppujenlopuksi aika harvaan. Mutta testauksen suorittamisesta tai varsinkin mahdollisista ongelmista testauksen suorittamisessa sain hyvää tietoa, emme ehkä pystyneet niitä täysin ratkomaan, mutta jatkossa luulisin osaavani ottaa paremmin huomioon tähän vaikuttavia tekijöitä. Yksikkötestien teko projektin laajuisesti tarjosi hyvää kokemusta ja tietoa missä niitä tarvitaan. Etenkin se, että testit vaikuttavat myös itse koodin rakenteeseen tuottaen selkeämpää ja testattavampaa koodia. Myös koodikatselmoinneista sain hyvän käytännön kuvan. Tärkeimpänä opetuksena ehkä se, että kommunikointi tiimin välillä on tärkeintä varsinkin tällaisessa täysin hajautetussa projektissa, jossa kukaan ei tunne koko järjestelmää täysin 24
25 ja ihmiset työskentelee eri aikoihin. Useamman ongelman olisin voinut välttää avaamalla suuni ajoissa. 6.5 Mikko Halttunen Oppimistavoitteeni oli laajentaa tietoa ohjelmistoprojektien kulusta ja päästä kokeilemaan sellaisessa mukana olemista. Lisäksi halusin erityisesti tutustua yksikkötestaamiseen. Projekti oli omien oppimistavoitteideni kannalta täysin onnistunut. Pääsin tutustumaan yksikkötestauksen saloihin oikein runsaasti ja projektiin osallistuminen valaisi hieman isommassa projektissa olemista ja toimimista erittäin paljon. Projektista on varmasti hyötyä tulevissa koitoksissa työelämässä. Mielenkiintoista tässäkin projektissa oli se, että vaikka aika ja aihe oli melkoisen rajoitettu, tuli selkeästi esille samoja elementtejä ja ongelmia mitä työelämässä on tullut vastaan, kuten kommunikaation ongelmat sekä aikataulun ja vaatimusten muutoksien takia. Muutokset aikatauluun ja vaatimuksiin sekä ongelmat kommunikaatiossa aiheuttivat myöhästymisiä ja kavensivat kehittäjille varattua aikaa projektin alussa. Tämän lisäksi, kun en itsekään alkanut tekemään töitä riittävällä tahdilla, jäi ensimmäinen osa ainakin omalta osaltani vajavaiseksi ja loppupäästä raskaaksi. Kevään osiossa ryhmällä ollut selkeämpi prosessi auttoi projektin ja oikean elämän aikataulujen yhdistämisessä 6.6 Mikko Närjänen Tavoitteinani tässä projektissa olivat ryhmätyötaitojeni kehittäminen, tämän kokoisen projektin toimintaan tutustuminen, uusiin tekniikoihin ja työkaluihin tutustuminen ja ohjelmointitaitojeni kehittäminen. Katson saavuttaneeni tavoitteeni ainakin osittain kaikilla näillä osa-alueilla. Antoisinta ja opettavaisinta tässä kurssissa on ollut projektin ja ryhmän toimintaan tutustuminen. Ymmärrän nyt paremmin tämän kokoluokan ohjelmistoprojektiin liittyviä haasteita erityisesti ryhmän sisäisen kommunikaation, kehittyvän ohjelmiston hahmottamisen ja hallinnan, sekä testauksen ja laadunvarmistuksen osalta. Näin jälkeenpäin ajatellen olisi ollut mielenkiintoista paneutua testauspuoleen vieläkin tarkemmin. Omien ryhmätyötaitojen kehittymistä on vaikea arvioida näin lyhyellä aikavälillä. Uskon kuitenkin tuntevani omat heikkouteni ja vahvuuteni paremmin kuin kurssin alkaessa. Ohjelmointitaitoni sekä Java-kielen tuntemukseni ovat kehittyneet projektin aikana. Tämä johtuu suurelta osin muista samaan aikaan käymistäni kursseista ja omasta harrastuneisuudestani. Jotkin asiat, esimerkiksi suunnittelumallit, ovat tulleet tutummiksi tämän kurssin kautta. Toisten ohjelmoijien koodiin tutustuminen erityisesti koodikatselmointien kautta ja palautteen saaminen omasta koodista on myös ollut hyödyllistä. Odotin ja toivoin, että olisin ehtinyt tutustua projektin aikana suurempaan määrään uusia tekniikoita ja työkaluja. Opin kuitenkin hyödyllisimmän ja yleiskäyttöisimmän yksittäisen uuden tekniikan, mitä tältä projektilta oli odotettavissa, eli yksikkötestauksen. 25
26 6.7 Antti Poikela T Ohjelmistoprojekti I Oppimistavoitteenani oli testaajan rooliin kuuluvat tehtävät ja käytännöt sekä oppia projektin kulkuun vaikuttavista seikoista tiimin sisällä sekä asiakkaan kanssa. Oppimistavoitteeni täytynee katsoa täyttyneiksi, opin testaajan rooliin kuuluvista tehtävistä ja jotain myös projektin kommunikaatiosta käytännössä, joskin asiakkaan kanssa kommunikointia seurasin lähinnä johtoryhmän toimien kautta. Projektin opetuksellinen arvo ja projektin vaatima työmäärä eivät mielestäni kuitenkaan olleet missään suhteessa. Suuri osa tehtävistä ei ollut motivoivia ja pääasiassa projekti tuntuikin vain yritykselle tehtävältä käytännössä ilmaiselta työltä. Puuttuva motivaatio johti aikatauluongelmiin, sillä tehtävien teko ei usein kerta kaikkiaan kiinnostanut riittävästi ennen lähestyvää deadlinea (projektiryhmän viikkodeadline ja päivän töille asetettu oma deadline, joka käytännössä tarkoitti aamua), jolloin päästiinkin tinkimään yöunista. Tehottomasta ajankäytöstä johtuen työmäärä tuntui moninkertaiselta todellisiin käytettyihin tunteihin nähden. En väitä, ettei projektissa olisi oppinut uusia asioita, mutta ei työmäärään nähden lainkaan riittävää määrää. 6.8 Markku Huttunen Yhtenä oppimistavoitteenani oli kommunikaation parantaminen varsinkin projekteissa, joissa on mukana monta henkeä. Kuten odotettua, kurssi osoitti sen faktan, että kommunikaatio asettaa todellisen haasteen kahdeksan hengen yhteistyölle. Loppujen lopuksi selvisimme mielestäni ilman suurempia ongelmia pitkälti moninaisten kommunikaatiotyökalujen ansioista. Irc ja kehittäjäpalaverit olivat mielestäni tärkeimmät kommunikaatiomenetelmät. Kurssi opetti ajoittain jopa kantapään kautta sen, että kommunikaatiota on syytä harrastaa paljon ja ettei ole tyhmiä kysymyksiä. Tavoitteenani kurssilla oli myös uusien tekniikoiden oppiminen. Uusina asioina projektissa pääsin tutustumaan Web Servicien aksessointiin ja web-käyttöliittymän tekemiseen. Lisäksi pääsin tutustumaan hieman Spring frameworkkiin, josta voi myös olla hyötyä jatkossa. Muilta osin ohjelmointityö ei varsinaisesti tuonut esille mitään uutta ja ihmeellistä. Kuitenkin kaikki uusi opittu asia on aina positiivista. Viimeinen oppimistavoitteeni, kehittyminen ajankäytön arvioinnissa osoittautui kaikista haastavimmaksi tavoitteeksi. Vaikka työtehtävien keston arviointi tuntuukin edelleen todella hankalalta, sain kuitenkin kurssin puitteessa siihen vähän harjoitusta. Sinällään tämän tavoitteen täyttyminen olisikin ollut epärealistinen tavoite, koska tämä oli ainoa TKK:lla käymäni kurssi jossa pidin kirjaa tunneistani ja koetin arvioida tehtävien kestoja. 7 Kurssipalaute Arvosanan kannalta olimme liiankin kilttejä tarjotessamme varsin läpinäkyvän rajapinna projektimme sisälle. Näin projektin lopuksi voisi todeta että emme myyneet projektiamme tarpeeksi asiakkaalle emmekä mentorille. Osan ongelmistamme ja toimintatavoista itsellä pitäessämme olisimme voineet yltää parempiin arvosanoihin. Tämä on hieman ristiriidassa Mentorin kannustaman avoimen kommunikaation kanssa. Asiakassuhde olisi voinut olla myös hieman erilainen jos olisimme toimineet tuntemattomalle asiakkaalle. 26
27 Asiakassuhde olisi voitu myös pitää enemmän alihankintana kuin talon sisällä tehtynä. Tällä olisi saavutettu tietty raja asiakkaan ja projektiryhmän välille. Kokonaisuudessaan kurssi on erittäin raskas ja vaatii opintoviikkoihin nähden huomattavan paljon työtä. 8 Jatkokehitys Seuraavassa on esitetty näkemyksiä järjestelmän jatkokehitysmahdollisuuksista. 8.1 Spring Valppaan selkäranka. Deklaratiiviset transaktiomääritykset Valppaan kannalta ehkä tärkein ominaisuus, joten sen käyttö lienee perusteltua jatkossakin. Lisäksi kokoonpanoa voidaan muutella kääntämättä koodia. 8.2 Quartz Tarkistusten skedulointi. Jatkossa kaikki ajastetut työt voidaan toteuttaa käyttäen Quartzia. 8.3 Linjan tarkastus Nykyinen toteutus lopettaa linjatarkisukset jos automaattinen laitetarkkailu otetaan pois päältä. Tarkoitus kuitenkin olisi, että niitä jatketaan edelleen. 8.4 Aktiiviset laitteet Valppaan laitetaulussa on tarvittavat kentät myös aktiivisten laitteiden tarkkailuun. Lähinnä tähän tarvitaan yhtä päivämäärä kenttää, jota päivitetään laitteen lähettäessä tietyn tyyppisen viestin, että se on kunnossa. Kyseeseen tulisi lastdeliverymessagetime, jota käytetään passiivisten laitteiden yhteydessä tallentamaan välitystietojen päivämäärä. Aktiivisille laitteille ei lähetetä ikinä viestejä, joten kenttää ei käytetä mihinkään. Yhtähyvin voitaisiin käyttää lastservicemessagetimeä, jota käytetään passiivisten laitteiden yhteydessä tallentamaan aika jolloin testiin saapui vastaus. Lisäksi aktiivisten laitteiden tarkkailuun olisi hyvä tehdä oma job, joka delegoi tarkistuksen jollekin aktiivisia laitteita käsittelevälle oliolle. Periaatteessa tähän voitaisiin käyttää nykyistä DeviceStatusCheckerjobia, joka delegoi tarkistuksen laitteen tyypistä riippuen oikealle käsittelijälle. 8.5 Releet hälytinkeskuksessa Valppaan passiivisten laitteiden tarkistukseen on liitetty nykyisellään komponentti, joka lähettää releiden nollausviestit kun tarkistus on suoritettu, joten releiden pitäisi Valppaan puolesta toimia. Käytännössä tarvittaisiin tarkempaa testausta aikaväleistä, joita voidaan käyttää ennenkuin seuraava testi aloitetaan. Valpas ei niihin juuri ota kantaa ja käyttäjä voi syöttää arvoja, joilla testauksen suorittamista ei voi erilaisista viiveistä johtuen tekemään. 8.6 Viestien välitys Valpas lähettää jokaisen viestin EPA:lle asynkronisesti yksitellen. EPA:n kannalta tehokkaampaa voisi olla, että viestejä puskuroitaisiin ja lähettäisiin vaikka 500 millisekunnin aikana kertyneet viestit kerralla. Tämä tosin vaikeuttaa virheiden logittamista 27
28 sillä logitus tehdään lähetyksestä tulevien poikkeusten perusteella. Toisaalta kyseinen informaatio tuskin enää kiinnostaa jatkossa. 8.7 Tietokanta Hibernate on edelleen hyvä ratkaisu Valppaan toteutuksessa. Tekemällä suora JDBC toteutus voitaisiin tietokannan saantia ehkä tehostaa, mutta tarvittaisiin kuitenkin cachet ja käsin tehdyt implementaatiot jo Hibernatessa mukana oleville ominaisuuksille. Jos saantia halutaan tehostaa lienee aluksi helponta muokata kannan skeemaa optimaalisemmaksi Hibernaten kannalta sekä laittaa lazy loading päälle. Ainut syy miksi se nyt on pois päältä on se, että Valpas on haluttu pitää riippumattomana Hibernatesta ja jos lazy loading on päällä niin Spring ei enää pysty muuntamaan Hibernaten poikkeuksia oman hierarkiansa mukaiseksi ja Valppaassa joudutaan ottamaan kiinni varsinaisia Hibernaten poikkeuksia. Lisäksi jatkossa olisi järkevää erottaa käyttöliittymissä näkyvät kentät omaan kantaolioonsa ja pitää Valppaan sisäisesti käyttämät kentät omassaan. Näin voitaisiin käyttää Hibernaten optimistic locking -suunnittelumallia käyttöliittymässä esitettävien tietojen kanssa ja välttyä näin vanhentuneen datan päivitykseltä jos laitteen tietoja muokataan rinnakkaisesti. Sisäkkäisillä kentillä optimistic locking -mallia ei haluta käyttää sillä se voi estää yhtäaikaisten transaktioiden kirjoitusoperaatiot. Valpas on suunniteltu niin, että samaa sisäistä kenttää ei voi kirjoittaa kuin yksi transaktio kerrallaan, joten yhtäaikainen kirjoitus ei ole ongelma. Mutta jos ne ovat samassa kantaoliossa niin optimistic-locking estää huonossa tapauksessa toisen transaktion kirjoituksen kokonaan vaikka ne eivät samaa kenttää kirjoittaisikaan. Lisäksi dynamic-update on ehdottomasti pidettävä päällä, ettei kenttiä, jotka eivät ole muuttuneet, päivitetä. 8.8 GSM, sähköposti Valppaaseen voidaan lisätä komponentteja, jotka saavat tietoa tarkistusten tilasta muttei varsinaisista vioista tai hälytyksistä toteuttamalla DeviceStatusListener-rajapinta. Rajapintaa tulisi laajentaa käsittämään myös varsinaiset vika- ja hälytysviestit ja välittää nuo tiedot tarkkailijalle ReceivedMessageHandler-luokasta. Huomautuksena viestejä vastaanottavan työn tulisi valmistua mahdollisimman nopeasti, joten ReceivedMessageHandlerin ei ehkä tulisi ajaa tarkkailijoiden metodeja suoraan samassa säikeessä. Sama pätee myös tarkistuksiin. Nykyinen DeviceStatusChecker-toteutus kutsuu tarkkailijan metodeja suoraan. 8.9 Komentorivikäyttöliittymä Nopea laajentaa testausta varten jos tehdään uusia ominaisuuksia. Voidaan lisäksi käyttää esim. skriptien ajoon syöttämällä käyttöliittymälle skripti tekstitiedostona. Esim. add device "plaa" "plaa" false (TEST_ALARM) remove device 1 remove device 2 remove device 3 remove device 4 exit 28
29 8.10 Web-käyttöliittymä T Ohjelmistoprojekti I JSTL:n ja EL-expressioiden käyttöä tulisi miettiä. Onko niistä mitään etua verrattuna skripletteihin? JSTL:llä asiat onnistuu kuitenkin astetta hankalammin kuin vastaavalla Java-koodilla ja ainut hyöty on lähinnä JSP:n xml-muoto. Paljoa selkeämpää se ei ole. Spring MVC on sopivan joustava eikä pakota mihinkään toteutusta mihinkään sopimattomaan muottiin. Tosin sen kehitys tuskin etenee enää isommin ja esim. JSF alkaa kypsymään teknologiana ja on standardi. Springin Web Flow voisí myös olla varteenotettava vaihtoehto sillä Valpas nojautuu muuten vahvasti Springiin. Tehdessä laajempaa web-sovellusta Valppaan päälle tulisi toteutusteknologiaa harkita sillä nykyinen toiminnallisuus on vielä suppeaa ja vaihto onnistuu järkevällä työmäärällä. Lisäksi tulisi miettiä miten laitteita hallitaan asiakaskohtaisesti. Valppaaseen voitaisiin rakentaa asiakkaiden hallintaan oma julkisivu ja taulut tarvittaville tiedoille, jolloin käyttöliittymä pysyisi edelleen aika ohuena. Kaikki transaktioita vaativat operaatiot olisi hyvä suorittaa Valppaassa ja tarjota käyttöliittymille RMI-rajapinnat julkisivuihin. Näiden yli kulkeva tieto on kuitenkin vähäistä. Toisaalta jos Valppaan suorituskyky halutaan maksimoida, voisi käyttäjienhallinta sijaita erillään Valppaasta Muuta Valppaan laajetessa J2EE:n tarjoamat palvelut voisivat myös tulla tarpeeseen, joten Valppaan refraktorointia ja ajoa sovelluspalvelimessa lienee myös syytä harkita. Spring, Quartz ja Hibernate eivät sulje tätä vaihtoehtoa pois vaan ovat suunniteltu integroitaviksi sovelluspalvelimiin. 29
T 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ä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ä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ä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ätiedotValppaan asennus- ja käyttöohje
Versio Päiväys Muokkaaja Kuvaus 0.9 16.2.2006 Tuukka Laakso Korjattu versio 0.1 Antti Kettunen Alustava versio Sisällysluettelo 1 Johdanto...2 2 Valppaan asennus...3 2.1 Valppaan kääntäminen...3 2.2 Valmiiksi
LisätiedotToteutusvaihe T3 Digi-tv: Edistymisraportti
Toteutusvaihe T3 Digi-tv: Edistymisraportti Sisällysluettelo 1. Projektin tila...3 Dtv: Work done per Person (current phase)...3 Dtv: Work done per Worktype (current phase)...3 2. Suoritetut tehtävät...4
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ä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ä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ä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ä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ätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
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ätiedotCT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)
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ätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
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ä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ätiedotA13-03 Kaksisuuntainen akkujen tasauskortti. Projektisuunnitelma. Automaatio- ja systeemitekniikan projektityöt AS-0.
A13-03 Kaksisuuntainen akkujen tasauskortti Projektisuunnitelma Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Syksy 2013 Arto Mikola Aku Kyyhkynen 25.9.2013 Sisällysluettelo Sisällysluettelo...
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ätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
Edistymisraportti v. T4 (Toteutus 4) Päivitetty 15.3.2001 klo 18:13 2 (8) Sisällys 1 PROJEKTIN TILA...3 2 SUORITETUT TEHTÄVÄT...6 3 KÄYTETYT MENETELMÄT...7 4 ONGELMAT...8 EDISTYMISRAPORTTI 2 3 (8) 1. Projektin
LisätiedotHajautettu Ohjelmistokehitys
Hajautettu Ohjelmistokehitys Maria Paasivaara Hajautuksen muotoja Yrityksen sisäinen hajautus Maan sisällä Maiden välillä, esim. offshore Yritysten välinen hajautus Alihankinta Lisenssointi Partnershipit
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ä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ä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ä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ätiedotSiimasta toteutettu keinolihas
AS 0.3200 Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma: Siimasta toteutettu keinolihas Laura Gröhn 224417 Mikko Kyllönen 221177 Lauri Liukko Sipi 84702A Susanna Porkka 225131 3.2.2015
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ä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ätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
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ä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ä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ä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ätiedotEDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0
EDISTYMISRAPORTTI - PS Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 2. SUORITETUT TEHTÄVÄT 3 Projektisuunnitelma 3 Vaatimusmäärittely
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ätiedotA4.1 Projektityö, 5 ov.
A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia
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ä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ätiedotHarjoitus 3 Case Face Wash. Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja
Harjoitus 3 Case Face Wash Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja Tunnistettuja ongelmia Katastrofaaliset ongelmat Kommunikointi Projektisuunnitelman puuttuminen Projektia ei aikataulutettu
LisätiedotWork Pilots Oy:n nopea kokeilu Helsingin kouluissa
Julkinen loppuraportti 20.2.2019 Work Pilots Oy:n nopea kokeilu Helsingin kouluissa Helsingin koulujen nopeiden kokeilujen ohjelma I, syyslukukausi 2018 Kokeilun tavoitteet Kokeilun tavoitteena oli toimivan
LisätiedotYksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }
Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.
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ä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ätiedotT-76.4115 Ohjelmistokehitysprojekti I Tekninen Määrittely
T-76.4110 Ohjelmistoprojekti I T-76.4115 Ohjelmistokehitysprojekti I Tekninen Määrittely Versio Päiväys Muokkaaja Kuvaus 0.9 30.11.2005 Tuukka Laakso Kommentoitava versio 1.0 4.12.2005 Tuukka Laakso Palautettava
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ätiedotT-76.4115 Ohjelmistokehitysprojekti I Projektisuunnitelma (PP)
T-76.4115 Ohjelmistokehitysprojekti I Projektisuunnitelma (PP) Versio Päiväys Muokkaaja Kuvaus 1.50 16.10.2005 Kattilamäki Kattilamäki Palautettava versio 1.00 02.10.2005 Rönkkö Rönkkö Lisätty muutosloki
LisätiedotUudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
Lisätiedot58160 Ohjelmoinnin harjoitustyö
58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista
LisätiedotLoppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio
1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...
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ä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ätiedotOnnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
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ätiedotProjektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen
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ä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ä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ä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ä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ätiedotVAPAAEHTOISTYÖN PORTFOLIO MAAHANMUUTTAJILLE
VAPAAEHTOISTYÖN PORTFOLIO MAAHANMUUTTAJILLE Vapaaehtoisen nimi: 1. Vapaaehtoistyö Päivämäärä ja kesto Organisaatio Tehtävät Tarvittavat taidot ja osaaminen 2. Muut koulutukset ja kurssit Päivämäärä Kurssin,
LisätiedotVerkossa opiskelu vaatii opiskelijalta paljon aktiivisuutta ja kykyä työskennellä itsenäisesti
Verkossa opiskelu vaatii opiskelijalta paljon aktiivisuutta ja kykyä työskennellä itsenäisesti Opiskelijoiden kokemuksia oppimisesta ITK 2010 seminaari; Hämeenlinna Soile Bergström Opintojakson esittely
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ätiedotLiite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu
Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu
LisätiedotLaaturaportti [iteraatio 2] Ryhmä 14
Laaturaportti [iteraatio 2] Ryhmä 14 Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva
Lisätiedottyössäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan. Ammattitaidon osoittamistavat
1(6) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Kehitysympäristön käyttö Tavoitteet: Opiskelija osaa määritellä, suunnitella ja toteuttaa ohjelmiston sekä dokumentoida ja testata valittua
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ätiedotWork Pilots Oy:n nopea kokeilu Helsingin kouluissa
Julkinen loppuraportti 20.2.2019 Work Pilots Oy:n nopea kokeilu Helsingin kouluissa Helsingin koulujen nopeiden kokeilujen ohjelma I, syyslukukausi 2018 Kokeilun tavoitteet Kokeilun tavoitteena oli toimivan
LisätiedotTestaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
LisätiedotOpiskelija osaa suunnitella ohjelmiston toteuttamisen, toteuttaa, testata ja dokumentoida ohjelmiston.
1(6) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ tuotantoversion toteuttaminen 30 osp Tavoitteet: Opiskelija osaa suunnitella toteuttamisen, toteuttaa, testata ja dokumentoida. Työssäoppimisen keskeinen
LisätiedotProject-TOP QUALITY GATE
Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä
LisätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotVersiohistoria: Versio Päivämäärä Kuvaus Tekijä Virallinen versio Janne Piippo
TIETOKANTA MERIKOTKIEN SEURANTAAN Yhteenvetodokumentti Versiohistoria: Versio Päivämäärä Kuvaus Tekijä 1.0 13.12.2007 Virallinen versio Janne Piippo HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
LisätiedotTest-Driven Development
Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole
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ätiedotFigure 1: Projektipäälliköt Juha-Pekka Honkavaara ja Juha Mattila
1 Käytettävyysryhmä 1.1 Yleistä Tämän vuoden käytettävyystiimi (Uteam) perustuu kahden viime vuoden pohjalle. Uteam oli toiminnassa ensimmäisen kerran siis lukuvuonna 2005-2006. Uteamin projektiryhmä koostui
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ätiedotNextMakers-kasvuyritysbarometri. Julkaistu Microsoft Fluxissa
NextMakers-kasvuyritysbarometri Julkaistu 9.2.2017 Microsoft Fluxissa NextMakers-kasvuyritysbarometri 1/2017 NextMakers-barometri käsittelee kasvuyrityksille kiinnostavia, ajankohtaisia aiheita. Ensimmäisen
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 / 8 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
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ätiedotHUOMAUTUS LUKIJALLE: Tässä on esitelty kaikkien aineiden palaute. Kysymyksestä 1. ilmenee mitä aineita oppilas on kurssilla lukenut.
Kurssipalaute HUOMAUTUS LUKIJALLE: Tässä on esitelty kaikkien aineiden palaute. Kysymyksestä 1. ilmenee mitä aineita oppilas on kurssilla lukenut. OPPILAS 1 Vastaa seuraaviin kysymyksiin asteikolla 1 5.
LisätiedotOPPIMISEN MONET MUODOT Työsuhteessa tapahtuva harjoittelu. Anniina Friman Bioanalyytikko, AMK, YAMK- opiskelija TuAMK
OPPIMISEN MONET MUODOT Työsuhteessa tapahtuva harjoittelu Anniina Friman Bioanalyytikko, AMK, YAMK- opiskelija TuAMK TAUSTA Kliininen harjoittelu olennainen osa Sairaanhoitajan (amk) tutkintoa. Tutkinnon
LisätiedotToteutusvaihe T2 Edistymisraportti
Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria
LisätiedotOhjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
LisätiedotTestauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
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ätiedotKurssin tavoitteista uennot. 4.1 Projektityö, 5 ov. Esitietovaatimukset
Kurssin tavoitteista uennot ma ls. 1097, klo 10-12. pe ls. DXI, klo 12-14. uennot ovat viikoilla 40-42. uentojen yhteydessä ei järjestetä erillisiä harjoituksia. Opinto-oppaasta: Opintojakson tavoitteena
LisätiedotOHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta
OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi
LisätiedotLego Mindstorms anturit
Lego Mindstorms anturit Metropolia Ammattikorkeakoulu Projektisuunnitelma Tomi Ilonen KA09 Tommi Nuotiomaa KA09 Matias Pitkänen KA09 20.1.2012 Insinöörityö Päivämäärä Sisällys 1 Projektin kuvaus 1 1.1
LisätiedotEhdottomasti suosittelisin! Täällä on kivat ja hyvät opet ja loistavat oppimismenetelmät!
OPPILAS 1 Ehdottomasti suosittelisin! Täällä on kivat ja hyvät opet ja loistavat oppimismenetelmät! Kurssi oli superhyvä, juuri sellainen mitä halusin, jopa parempi! Tietokoneohjelma oli loistava opiskeluapuri
LisätiedotARTS-ENG-projekti. Projektin lopettaminen
ARTS-ENG-projekti Projektin lopettaminen Jukka Paatero Aalto ENG 2017 J. Paatero 1 Luennon tavoite ja sisältö Tavoite: Sisältö: Ymmärtää miksi, milloin, ja miten projekti tulisi lopettaa Projektin lopettamisen
LisätiedotAsiakas ja tavoite. Tekninen toteutus
Asiakas ja tavoite Heikieli on vuonna 2015 perustettu yhden hengen asiantuntijayritys, joka tarjoaa käännös- ja oikolukupalveluita englannista ja saksasta suomeksi. Freelance-kääntäjiä on Suomessa paljon,
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ätiedotSEPA päiväkirja. Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen
SEPA päiväkirja Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen 1. Johdanto...3 2. Menetelmän käyttö...4 3. Kokemukset ja muutokset...5 1. Johdanto SEPAn aiheenamme meillä on suunnittelumallit
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
LisätiedotA13-03 Kaksisuuntainen akkujen tasauskortti. Väliaikaraportti. Automaatio- ja systeemitekniikan projektityöt AS Syksy 2013
A13-03 Kaksisuuntainen akkujen tasauskortti Väliaikaraportti Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Syksy 2013 Arto Mikola Aku Kyyhkynen 22.10.2013 Sisällysluettelo Sisällysluettelo...
LisätiedotGood 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ä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ätiedotKysymykset ja vastausvaihtoehdot
KAARI-TYÖHYVINVOINTIKYSELY 1 (8) Kysymykset ja vastausvaihtoehdot JOHTAMINEN TYÖYKSIKÖSSÄ Tässä osiossa arvioit lähiesimiehesi työskentelyä. Myös esimiehet arvioivat omaa lähiesimiestään. en enkä Minun
LisätiedotS14 09 Sisäpeltorobotti AS Automaatio ja systeemitekniikan projektityöt. Antti Kulpakko, Mikko Ikonen
S14 09 Sisäpeltorobotti AS 0.3200 Automaatio ja systeemitekniikan projektityöt Antti Kulpakko, Mikko Ikonen 1. Projektin tavoitteet Projektin tavoitteena on toteuttaa ohjelmisto sisäpeltorobottiin seuraavien
Lisätiedot