Project group Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: etenemisraportti
|
|
- Otto Elstelä
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Pariohjelmointi Mika Lindroos
2 T Software project 2(6) Muutosloki Versio Pvm Tekijä Kuvaus Mika Lindroos Ensimmäinen versio I1-vaiheesta Mika Lindroos Päivitetty versio I2-vaiheesta
3 T Software project 3(6) 1. Arvionti I1-vaiheesta Käytimme pariohjelmointia I1-vaiheen alussa suunnitelman mukaan järjestelmällisesti, mutta vaiheen loppupuolella käytännön rajoitteiden takia jouduimme hieman poikkeamaan pariohjelmoinnin käytöstä. Suurin käytännön ongelma oli ilman muuta asiakkaan lupaaman testipalvelimen toimimattomuus, joka aiheutti sen, että kaikki kehitystyö oli käytännössä tehtävä ryhmäläisten omilla kotikoneilla tai muuta kautta hankitun palvelimen kautta. Kaikilla ei kuitenkaan ollut mahdollista pystyttää omaa palvelinta etäkäytettäväksi, joten pariohjelmoidessa oli mentävä jomman kumman kotikoneelle ohjelmoimaan. Toinen pariohjelmoinnin käyttöä rajoittanut tekijä oli tämän vaiheen tiukka aikataulu, joka aiheutti ongelmia yhteisen ajan löytämiseksi parin jäsenten välillä. Näistä syistä johtuen pariohjelmointia ei käytetty suunnitellussa määrin, eikä saatuja tuloksia voida vielä missään nimessä pitää täysin totuudenmukaisina tai kattavina. I1-vaiheen alussa tuli myös esille muutamia rajoitteita pariohjelmoinnin suhteen. Tiiviin aikataulun vuoksi pariohjelmointi-kertoja joutui sopimaan varsin aikaisessa vaiheessa ja niinpä ainakin yhdelle parille kävi niin, että toteutusympäristö ei ollut vielä täydessä toimintakunnossa ohjelmointia aloitettaessa. Näin ollen parilta kului ylimääräistä aikaa ympäristön ongelmien selvittelyyn, mikä luonnollisesti näkyy pariohjelmoinnin tehokkuuden kärsimisessä; yhden ohjelmoijan sijasta kaksi ohjelmoijaa istui ratkomassa teknisiä ongelmia pahimmillaan saamatta mitään merkittävää edistystä aikaan. Pariohjelmointi antoi I1-vaiheen aikana kuitenkin viitteitä myös tarjoamistaan hyödyistä. Kun teknisten ongelmien aiheuttamat harmit oli selvitetty, päästiin varsinaiseen pariohjelmointiin käsiksi ja tuottamaan varsinaista ohjelmakoodia. Näiden ohjelmointikertojen aikana tuli erityisesti pariohjelmoinnin oppimisvaikutus hyvin esille käytettäessä kokenut-kokematon ohjelmoijapareja. Näin ollen pariohjelmointia ei ole syytä tuomita vielä I1-vaiheen tulosten perusteella vaan sen käyttöä jatketaan mahdollisuuksien mukaan seuraavissa vaiheissa. I2-vaiheessa oleva joululoma aiheuttaa omat haasteensa pariohjelmoinnin käytölle, mutta vastaavasti testipalvelimen saaminen käyttöön jossain vaiheessa helpottaa osaltaan työskentelytilaongelmaa. 1.1 Metriikat I1-vaiheesta Taulukko 1. Pariohjelmoinnin käyttö ja järjestelmätestauksessa löydetyt bugit käyttötapauksittain (I1) Use case Pariohjelmoinnin Yksinohjelmoinnin Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial) UC 1.1 Log in % 2 (0/0/0/2/0) UC 1.2 Log out UC 2.1 Report hours for a work category (0/0/0/1/0) % 9 (0/0/2/7/0) UC 3.1 View % 2 (0/0/0/2/0)
4 T Software project 4(6) reported hours UC 4.1 Add user UC 4.4 View user list UC 5.1 Add work category % 3 (0/0/0/3/0) (0/0/0/0/1) (0/0/0/1/1) Johtopäätöksiä I1-vaiheen metriikoista Ylläolevassa taulukossa esitetyt luvut eivät ole täysin vedenpitäviä, koska teknisten ongelmien ratkomiseen käytettyä aikaa on osittain kirjattu käyttötapausten toteutuksen alle. Lisäksi Log out-käyttötapauksen tunteja ei ole kirjattu ollenkaan kyseisen käyttötapauksen alle, vaikka kyseinen toiminnallisuus onkin toteutettu. Näiden tuntien voidaan olettaa olevan muiden käyttötapausten alla olevien tuntien yhteydessä. Kaksi viimeistä käyttötapausta toteutettiin alkuperäisen suunnitelman lisäksi, joten niille ei ollut Trapolissa omaa Task-kenttäänsä. Näihin käytettyjen tuntien sijainnista ei ole tarkkaa tietoa. Vielä yksi huomioitava seikka luvuista on se, että pariohjelmointia on käytetty pääsääntöisesti käyttötapausten ensimmäistä versiota tehtäessä kun taas havaittujen ongelmien paikkaukset on tehty pääsääntöisesti ohjelmoimalla yksin. I1-vaiheen tulosten pohjalta on turha tehdä kovinkaan pitkälle meneviä johtopäätöksiä. Eräs silmiinpistävä asia luvuista voidaan kuitenkin havaita. Ainoat havaitut minor-luokitusta vakavammat viat ja lukumäärältään suurin vikamäärä havaittiin kokonaistyömäärältään suurimmassa käyttötapauksessa UC 2.1. Tässä käyttötapauksessa myös pariohjelmoinnin käyttösuhde oli matalampi kuin kahdessa muussa käyttötapauksessa UC 1.1 ja UC 4.1. Vastaesimerkkinä voidaan kuitenkin esittää käyttötapaus UC 3.1, jossa saatiin hyviä tuloksia täysin ilman pariohjelmointia. Kuten sanottu on näistä tuloksista kuitenkin liian aikaista tehdä vedenpitäviä johtopäätöksiä ja pariohjelmointi näyttänee todelliset ominaisuutensa vasta tulevissa vaiheissa. 2. Arvionti I2-vaiheesta I2-vaihetta voidaan pitää varsin menestyksekkäänä pariohjelmoinnin näkökulmasta. Asiakkaan lupaama testipalvelin saatiin vihdoin käyttöön iteraation alkupuolella ja tämä helpotti olennaisesti pariohjelmoinnin käyttöä, koska parit pystyivät työskentelemään myös koululta käsin. Iteraation alkuun sijoittunut joululoma aiheutti sen, että iteraation alussa työskentely oli varsin yksilöpainotteista ja jokainen teki töitä lähinnä silloin kuin itsellä oli lomalla sopivasti aikaa. Tästä syystä suurin osa iteraation työmäärästä sijoittui kaikenkaikkiaan muutamalle tammikuun viikolle. Joululoman jälkeen tammikuun alusta alkanut työskentely sisälsi runsaasti varsinaista ohjelmiston toteutusta, toisin kuin vielä I1-vaiheessa, jossa oli melko paljon myös muuta vaadittua tehtävää. I2-vaiheessa toteutetaan merkittävä osa ohjelmiston toiminnallisuudesta ja niinpä tämä iteraatio on ehkä paras tilaisuus eri ohjelmointimenetelmien väliseen vertailuun. Tämän iteraation kuluessa käytettiin runsaasti sekä pari- että yksinohjelmointia, joten sikälikin tulosten pitäisi antaa jonkinlaista osviittaa eri menetelmien hyödyistä ja haitoista. Havaittavaa on, että suurin osa ohjelmoinnista oli edelleen yksinohjelmointia, mutta pariohjelmoinnin määrää voidaan pitää suhteellisen hyvänä kun otetaan huomioon, että joululoma vei lähes puolet iteraatiosta. Aivan kaikki ryhmäläiset, eivät kuitenkaan vieläkään omaa riittävästi kokemusta
5 T Software project 5(6) molemmista menetelmistä ja siksi päätin tehdä kyselyn pariohjelmointikokemuksista vasta seuraavan iteraation lopussa. Näin ollen tämän iteraation tulokset keskittyvät edelleen lähinnä pariohjelmoinnin teknisiin vaikutuksiin lopputulokseen, eikä esim. oppimisvaikutusta pystytä mittaamaan mitenkään objektiivisesti. Omalta osaltani voin kuitenkin sanoa jo sen verran, että pariohjelmointi näytti todelliset kyntensä tässä iteraatiossa kun päästiin eroon sitä haitanneista teknisistä ongelmista. Tein I1-vaiheessa melko vähän varsinaista ohjelmointityötä ja jos olisin joutunut tutustumaan yksin järjestelmään olisi siihen kulunut hyvin merkittävä määrä tehokasta työaikaa. Nyt pääsin sen sijaan tutuksi järjestelmän kanssa parini opastuksella ja sain runsaasti onnistumisen iloa saadessani toteutettua toiminnallisuutta järjestelmään. Iteraation loppupuolella olin oppinut järjestelmästä jo niin paljon, että kykenin itsenäisestikin toteuttamaan lisää toiminnallisuutta ja sikäli pariohjelmoinnin voidaan katsoa auttaneen merkittävästi oppimistavoitteiden saavuttamisessa. Hieman samansuuntaisia kokemuksia olen kuullut myös muiden kanssa keskustellessani, mutta näistä enemmän sitten ensi iteraation jälkeen virallisten kyselytulosten muodossa. Vielä viimeinen tämän iteraation työskentelystä huomioitava seikka, on muuttunut tilastointitapa toteutetun toiminnallisuuden osalta. Iteraatiossa toteutettavan toiminnallisuuden määrä oli sen verran suuri, että use case-pohjainen tilastointi ei olisi ollut enää järkevää. Niinpä ryhmä siirtyi tuntikirjanpidossa toiminnallisten kokonaisuuksien mukaiseen kirjaukseen ja tätä samaa kirjaustapaa käytän myös omassa raportissani. Tästä saavutetaan myös se hyöty, että järjestelmämme rakenteesta johtuen löydetyt bugit on huomattavasti helpompi ja luotettavampi kohdistaa toiminnallisuusalueisiin, eikä suoraan yksittäisiin käyttötapauksiin (tosin testiraportissa bugit on kohdistettu käyttötapauksiin tarkemman fokuksen saamiseksi). Näin ollen seuraavassa luvussa esitetyt pari-/yksinohjelmoinnin työmäärät ja löydetyt bugit ovat entistä tarkempia ja vertailukelpoisempia keskenään. 2.1 Metriikat I2-vaiheesta Taulukko 2. Pariohjelmoinnin käyttö ja järjestelmätestauksessa löydetyt bugit toiminnallisuusalueittain (I2) Toiminnallisu usalue Pariohjelmoinnin Yksinohjelmoinnin Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial) Check in related % 2 (0/0/0/0/2) Framework - 1,5 0 % 0 (0/0/0/0/0) User related Work category related Work time item related 24,5 28,5 46 % 6 (0/0/1/4/1) 27 41,5 39 % 6 (0/0/4/2/0) 9 63,5 12 % 5 (0/0/4/1/0)
6 T Software project 6(6) Johtopäätöksiä I2-vaiheen metriikoista Ylläolevan taulukon sisältämissä luvuissa on jonkin verran tulkinnanvaraisuutta, koska osa ohjelmoijista näytti kirjanneen myös bugien korjaukset tiettyjen toiminnallisuusalueiden alle kun taas osa oli kirjannut ne erikseen suunnittelemattoman ohjelmoinnin alle. Siitä johtuen osa taulukon sisältämistä työtunneista saattaa olla jo bugikorjauksia varsinaisen kehitystyön sijasta ja siten saattaa olla vaikuttanut toiminnallisuusalueen kokonaistyömäärään suurentavasti. Näiden tapausten seulominen käsin kaikkien tuntikirjausten joukosta olisi kuitenkin ollut Trapolin nykyiset ominaisuudet huomioon ottaen niin työlästä, että käytännön pakosta ne hyväksytään tulosta epätarkentavina tekijöinä. Toinen huomioitava seikka tämän iteraation tuloksissa on huomattavasti suuremmat kokonaistyömäärät kuin I1-iteraatiossa. Tästä johtuen myös löydettyjen bugien määrät ovat luonnollisesti suurempia, koska on vain luonnollista, että suurempia kokonaisuuksia tehtäessä ohjelmoijat tekevät myös enemmän virheitä. Lisäksi testaajina toimi jonkin verran eri henkilöt kuin I1-iteraatiossa ja tämä näyttäisi osaltaan vaikuttaneen erityisesti bugien vakavuusasteen tulkintoihin. Tämän iteraation testaajat tulkitsivat vakavuusasteita jonkin verran kevyemmin kuin I1-iteraation testaajat ja niinpä vakavammiksi luokiteltuja bugeja on enemmän kuin I1-iteraatiossa. Tämäkään tulkintaero ei ole kuitenkaan mikään ongelma, kunhan sen vain muistaa huomioida tuloksia analysoidessaan. Suuremmista työmääristä huolimatta ei tässäkään iteraatiossa saatu selkeää ja täysin objektiivista näyttöä pariohjelmoinnin eduista suhteessa yksinohjelmointiin. Framework-toiminnallisuudesta ei saada mitään järkevää tulosta, koska työmäärä oli ainoastaan 1,5 tuntia ja myös kokonaan yksin ohjelmoitu Check intoiminnallisuus on huono vertailukohta varsin yksinkertaisen rakenteensa takia. Niinpä keskeisimmäksi mittareiksi nousevat kolme suurinta toiminnallisuusaluetta, jotka sisältävät työtä n tuntia ja pariohjelmoinnin käyttöaste oli prosenttia. Bugeja analysoitaessa huomataan kuitenkin, että jokaiseen niistä on tullut lähes sama määrä bugeja ja myös bugien vakavuusasteet ovat hyvin lähellä toisiaan. Näin ollen ei voida millään tasolla sanoa pariohjelmointia sen paremmaksi tai huonommaksi kuin yksinohjelmointi. Eräs näkökohta on toki siinä, että pariohjelmoinnissa kuluu kahdelta ohjelmoijalta sama työmäärä kuin muuten menisi vain yhdeltä, mutta tätä ei voida objektiivisesti mitata käytössä olevien tietojen avulla. Näyttäisikin siltä, että tällainen yhden ryhmän sisäinen ja vain yhden projektin (vieläpä suhteellisen pieni projekti) mittainen tutkimus pariohjelmoinnin hyödyistä ei tuottaisi mitään tieteellisesti hyväksyttävää todistusaineistoa. Tutkin vielä I3-iteraation aikana, jos silloin tulisi ilmi jotain yllättäviä tuloksia. Tässä vaiheessa näyttää kuitenkin siltä, että parhainta tietoa pariohjelmoinnin hyödyllisyydestä saataisiin ensi iteraation lopussa tehtävän kyselytutkimuksen avulla. Vaikka kyseessä onkin ryhmäläisten subjektiiviset mielipiteet, antaa tämä varmasti osviittaa siitä kuinka hyödylliseksi pariohjelmointi koetaan ja ennen kaikkea tällä hetkellä pariohjelmoinnin keskeisimmältä edulta vaikuttavasta oppimishyödystä.
Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti
Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Pariohjelmointi Mika Lindroos T-76.115 Software Project/Tietojenkäsittelyopin ohjelmatyö 2(12) Muutosloki Versio
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ä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ä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ä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ätiedotProject group Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Staattiset menetelmät Jaakko Nyrölä T-76.115 Software project 2(8) Muutosloki Versio Pvm Tekijä Kuvaus 1.0
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ä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ä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ätiedotMittaaminen projektipäällikön ja prosessinkehittäjän työkaluna
Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Finesse-seminaari 22.03.00 Matias Vierimaa 1 Mittauksen lähtökohdat Mittauksen tulee palvella sekä organisaatiota että projekteja Organisaatiotasolla
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ätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Heuristiset arviointimenetelmät Marc Josefsson T-76.115 Software project 2(12) Muutosloki Versio Pvm Tekijä
LisätiedotSpecifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki
Specifying user requirements for corporate intranet with user centered design methods Espoo 29.9.2016 Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Sisältö Työn tausta Ongelman asettelu Metodiikka Kehitysprojekti
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ä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ätiedotPariohjelmointi. Ryhmä Rajoitteiset
Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija Lmodels Pariohjelmointi Tuomas Luttinen Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
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ä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 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ä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ä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ätiedotT Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. 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ä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ätiedotohjelman arkkitehtuurista.
1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä
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ä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ä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ätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
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ä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-76.115 Testiraportti TR-3. ETL-työkalu
T-76.115 Testiraportti TR-3 ETL-työkalu ExtraTerrestriaLs Versio Päivämäärä Tekijä Kuvaus 1.0 14.03.05 Risto Kunnas Ensimmäinen versio 1.1 15.03.05 Risto Kunnas Korjauksia Sivu 1 / 14 Sisällysluettelo
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ä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ä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ä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ätiedotVBE II Tulosseminaari Teknologian valmiusaste. Virtuaalirakentamisen Laboratorio Jiri Hietanen
VBE II Tulosseminaari Teknologian valmiusaste 1 2 Sisältö Tietomalleihin perustuva järjestelmä Järjestelmän osien valmiusaste Rakennuksen tietomallien tuottaminen Rakennuksen tietomalleihin perustuvat
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ätiedotKäyttötapausanalyysi ja testaus tsoft
Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten
LisätiedotJulkaisuarkistojen käyttötilastot: Mitä tilastoidaan ja miksi?
Julkaisuarkistojen käyttötilastot: Mitä tilastoidaan ja miksi? DSpace-käyttäjäryhmän tilastoseminaari Kansalliskirjaston auditoria, 3.11.2009 Jyrki Ilva (jyrki.ilva@helsinki.fi) Miksi verkkopalveluiden
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ätiedotProjektiryhmä Tete:n riskienhallintaryhmä. Kokemuksia riskienhallintakäytännöistä
Projektiryhmä Tete:n riskienhallintaryhmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(8) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 11.01.2004 Mika Lindroos Ensimmäinen versio dokumentista riskienhallintasuunnitelman
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2
AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7 Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004
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ätiedotT Software Project Group: Tetrastone Subject: RosettaNET. Personal Software Engineering Assignment: Tetrastone
Personal Software Engineering Assignment: Tetrastone Name of the group (Tetrastone) tetrastone@soberit.hut.fi Subject: PSEA 4.4.2004 Document history Version Date Author Description 1.0 1.4.2004 Henry
Lisätiedot4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T
SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen
LisätiedotTyön ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework
Työn ositusmalleista Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Walker Royce, Software Project Management, A Unified Framework 1 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata:
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ä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ätiedotstatbeatmobile PROJECT REVIEW iteration 1
statbeatmobile PROJECT REVIEW iteration 1 agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,
LisätiedotReilun Pelin työkalupakki: Kiireen vähentäminen
Reilun Pelin työkalupakki: Kiireen vähentäminen Tavoitteet Tämän toimintamallin avulla opit määrittelemään kiireen. Työyhteisösi oppii tunnistamaan toistuvan, kuormittavan kiireen sekä etsimään sen syitä
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Käytettävyystestaus Pauli Aho T-76.115 Software project 2(9) Muutosloki Versio Pvm Tekijä Kuvaus 1.0 29.1.2004
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ä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ä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ä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ätiedotITSEOHJAUTUVAN ORGANISAATION MUUTOS. Juha Riippi, Vincit Oy
ITSEOHJAUTUVAN ORGANISAATION MUUTOS Twitter: @JuhaRiippi Juha Riippi, Vincit Oy Linkedin: fi.linkedin.com/in/juhariippi MINUSTA Töissä Vincitillä vuodesta 2009. Monta eri roolihattua: Koodari Project Lead
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ätiedotCOTOOL dokumentaatio SEPA: Refaktorointi
Table of Contents Refaktorointi................................................................................ 1 1 Tehtävänanto.............................................................................
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ätiedotT SEPA - päiväkirja: Design Patterns. ETL työkalu
T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty
LisätiedotJohdanto 1. Projektille esiteltävä versio. Kokemukset ja muutokset 3. Projektille esiteltävä versio. Iteraatio 2., suunnitelma
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ätiedotT-76.115 Testiraportti TR-2. ETL-työkalu
T-76.115 Testiraportti TR-2 ETL-työkalu ExtraTerrestriaLs Versio Päivämäärä Tekijä Kuvaus 1.0 07.02.05 Risto Kunnas Ensimmäinen versio 1.1 08.02.05 Risto Kunnas Lisätty liitteet Sivu 1 / 11 Sisällysluettelo
LisätiedotLASKUAUTOMAATIORATKAISUIDEN VERSIOPÄIVITYS ICT-STRATEGIA LIIKETOIMINNAN KEHITYKSEN YTIMESSÄ 2011 KERKKO KÄMÄRÄINEN
LASKUAUTOMAATIORATKAISUIDEN VERSIOPÄIVITYS ICT-STRATEGIA LIIKETOIMINNAN KEHITYKSEN YTIMESSÄ SISÄLTÖ 01 Ramboll yleisesittely 02 ICT-strategia 03 Valmistautuminen päivitykseen 04 Versiopäivityksen hyödyt
LisätiedotKokonaisvaltainen mittaaminen ohjelmistokehityksen tukena
Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida
LisätiedotTestaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
LisätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
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ä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ätiedotSALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti
Järjestelmäprojekti 1 projektisuunnitelma ICT4TN007-2 SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Versio 0.1 Tekijät Keijo Nykänen Tarkastanut Hyväksynyt HAAGA-HELIA
LisätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
LisätiedotTestauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg
Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Symbio lyhyesti Innovatiivinen tuotekehitys- ja testauskumppani Juuret Suomessa, perustettu 1997 Laadukkaat ohjelmistotoimitukset
LisätiedotVisma EasyCruit Versiotiedote. Versio Suomi
Visma EasyCruit Versiotiedote Versio 06.2019 - Suomi Sisältö Sisältö 2 Tervetuloa tutustumaan version uusimpiin ominaisuuksiin 3 Tämän version toiminnot 3 Uusi hakijahallinta 3 Videohakemuskysymykset 6
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ä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ätiedotOhjelmistojen mallintaminen, syksy 2011, laskuharjoitus 2
Ohjelmistojen mallintaminen, syksy 2011, laskuharjoitus 2 Viikon 2 laskareita ei pidetä mikrosaleissa, käytössä ovat opetusohjelmaan merkatut salit. Tämän viikon tehtävistä 1-6 tehdään etukäteen kotona.
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ä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ätiedotOhjelmistojen mallintaminen, mallinnustekniikat käytännössä
582104 Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä 1 Sisältö Oliomenetelmien taustaa Kirjastojärjestelmän käyttötapaukset Kirjastojärjestelmän luokkamalli 2 Oliosuuntautunut suunnittelumenetelmä
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ätiedotFENG OFFICE -PROJEKTINHALLINTATYÖKALU
1(5) FENG OFFICE -PROJEKTINHALLINTATYÖKALU Verkkoprojektissa tarkoituksenmukaisen projektinhallintatyökalun käyttö vähentää viestintään kuluvaa työaikaa merkittävästi, kun projektin osapuolilla on reaaliaikainen
LisätiedotOhjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
LisätiedotJakopalkat. Virve Heikkinen ja Timo Ojala. Valtion talous- ja henkilöstöhallinnon palvelukeskus
Virve Heikkinen ja Timo Ojala Valtion talous- ja henkilöstöhallinnon palvelukeskus www.palkeet.fi Tuntikohdistustyyppi (M, L, S, U ja kohdistamaton) Sopimukselle on mahdollista valita tuntikohdistustyyppi:
Lisätiedotkäyttötapaukset mod. testaus
käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)
LisätiedotPaperiteollisuuden perustutkinto
Paperiteollisuuden perustutkinto Ammatti-osaamisen näyttö erikoispäällystys ja laminointi opintokokonaisuudesta Kuva: Janne Hietanummi: Valkeakosken ammattiopisto Taustaa Ammattiosaamisen näyttö suoritettiin
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ätiedotAutoCAD-natiiviobjektin toteutus
AutoCAD-natiiviobjektin toteutus Kontiotuote OY Maailman toiseksi suurin hirsitalotoimittaja Aloittanut toimintansa 70-luvulla Liikevaihto vuonna 2003-37,355 Milj. euroa josta vientiä 7,376 Milj. euroa
LisätiedotTestausraportti. Dokumentti: Testausraportti_FD.doc Päiväys: Projekti: AgileElephant
AgilElephant FD Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Sivu 1 / 8 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 7.3.2005 Ensimmäinen
LisätiedotRobotiikan hyödyntäminen taloushallinnossa
Robotiikan hyödyntäminen taloushallinnossa Eini Leväslampi Prosessisuunnittelija Talouspalvelukeskus Vantaan kaupunki Sami Säisä Tietohallinnon konsultti/rpa Tietohallinto Vantaan kaupunki Ohjelmistorobotiikkaa
LisätiedotPoPSTer-hankkeen arviointikysely. Kooste tuloksista
PoPSTer-hankkeen arviointikysely Kooste tuloksista 13.2.2018 PoPSTer-hankkeen arviointikysely Vastausprosentti Kysely toteutettiin 10. 15.1.2018 Se lähetettiin 370 hankkeessa mukana olleelle henkilölle,
LisätiedotKäytettävyyslaatumallin rakentaminen verkkosivustolle
Käytettävyyslaatumallin rakentaminen verkkosivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -tutkielma Timo Laapotti 9.6.2005 Esityksen sisältö Kirjoittajan
LisätiedotS09 04 Kohteiden tunnistaminen 3D datasta
AS 0.3200 Automaatio ja systeemitekniikan projektityöt S09 04 Kohteiden tunnistaminen 3D datasta Loppuraportti 22.5.2009 Akseli Korhonen 1. Projektin esittely Projektin tavoitteena oli algoritmin kehittäminen
LisätiedotArkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2
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ätiedotTOIMINNALLINEN MÄÄRITTELY MS
TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa
LisätiedotKuntoutuksen ja koulun yhteistyö. Tarja Keltto/Vamlas 2017
Kuntoutuksen ja koulun yhteistyö Tarja Keltto/Vamlas 2017 Webropol kysely kuntoutuksen ammattilaisille Avoinna 14.- 30.11.2016 ja sitä jatkettiin tammikuun 2017 ajan Vastauksia yhteensä 181 N Prosentti
LisätiedotPROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009
PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009 POHDINTAA Mitä asioita projektissa seurataan? Kuka vastaa ohjauksesta? Millä tavoin projektia seurataan ja ohjataan? Mitä asioita ohjaukseen kuuluu?
LisätiedotPikaopas. Mobiilituntikirjausten hyödyntäminen palkanmaksussa
Pikaopas Mobiilituntikirjausten hyödyntäminen palkanmaksussa Miten hyödyntää mobiilituntikirjauksia palkanmaksussa? Tässä oppaassa käydään läpi hyväksi havaittuja käytäntöjä sähköisen työajanseurannan
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ä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ätiedot