Projektisuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
|
|
- Simo Salminen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Projektisuunnitelma CoSCA-simulaattorin jatkokehitysprojekti
2 Muutoshistoria Versio Pvm Tekijä Kuvaus Elina Kontro Ensimmäinen mallipohjaan täytetty versio, englanninkielinen Elina Kontro Laura Lehtola Dokumentointi kielen vaihto, rakenteen muuttamista, sisältöä budjetti, termejä Asiakkaan tavoitteet, riskienhallintasuunnitelma ja riskiloki. Kirjoitusvirheiden korjausta Kari Ylihärsilä Ohjelmointikäytännöt ja työkalut, ideoiden lisäystä Elina Kontro Laura Lehtola Elina Kontro Kari Ylihärsilä Elina Kontro Templaten vaihto, sisällön päivitystä, PP-iteraatio suunnitelman tietojen siirtäminen tähän dokumenttiin ja päivittäminen Terminologiaa, vaatimustenhallinta, alustava budjetti, katselmointikäytännöt. Aikatauluja, termejä, korjauksia Tarkka kuvaus työkaluista, versionumerot ja linkit työkaluihin. Yleisiä parannuksia. Merkitsin avoimia kohtia TODO merkinnöillä. Työmääräarvioita, palaverikäytäntöjen & budjetin päivitys, kehittäjä -> suunnittelija Kari Ylihärsilä Parannuksia, lisätty rakennekaavio, tekstin selvennystä Elina Kontro Elina Kontro SEPA päivitystä Elina Kontro Laura Lehtola Oppimistavoitteita, SEPA aiheet, kokouskäytäntöjen päivitys, virheiden korjausta SEPA päivitystä, oppimistavoitteiden päivitystä, työmääräarvio PP iteraatioon päivitetty, johdanto, tuntiraportointia tarkennettu, pienryhmät lisätty, korjauksia Käyttäjä- ja asiakasnäkökulman varmistaminen, vaatimusten hallinnan uusi versio, kirjoitusvirheiden korjausta ja muotoilua. 1
3 Sisällysluettelo 1 Johdanto Projektin tarkoitus ja laajuus Terminologia ja määritykset Järjestelmä ja ympäristö 3 2 Osapuolet ja henkilöstö Projektiryhmä Muut osapuolet 5 3 Tavoitteet ja lopetuskriteerit Asiakkaan tavoitteet Projektiryhmän tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytyskriteerit Projektin lopetuskriteerit 9 4 Resurssit ja budjetti Henkilöt Materiaalihankinnat Budjetti 10 5 Työkäytännöt ja työkalut Käytännöt Iteratiivinen kehitys Iteraation suunnittelu Dokumentointi Riskienhallinta Tuntiraportointi Ohjelmakoodin koon raportointi Kommunikointi ja palaverikäytännöt Pienryhmät Katselmointikäytännöt Iteraatiodemot Vikojen seuranta Versionhallinta Koodauskäytäntö Vertaistestaus Vaatimusten määrittely ja hallinta Laadunvarmistussuunnitelma Projektitason asiat Iteraatiotason asiat Työkalut Kehityslaitteisto Ohjelmistot Kehitystyökalut 21 1
4 5.4 Standardit SEPA -työt Coding Camp Käytettävyystestit Staattiset menetelmät 24 6 Vaiheistus Projektin suunnittelu (PP) Toteutusiteraatio 1 (I1) Toteutusiteraatio 2 (I2) 31 7 Riskiloki 32 8 Lähdeluettelo 35 2
5 1 Johdanto Tämä dokumentti on -projektiryhmän projektisuunnitelma Teknillisen Korkeakoulun kurssilla T Ohjelmistoprojekti I. Dokumenttia päivitetään koko projektin ajan. 1.1 Projektin tarkoitus ja laajuus Tehdastuotannon päivittäisenä haasteena on tehdä nopeasti päätöksiä tilausten aikataulutuksesta. Tällaisia päätöksiä ovat esimerkiksi koska toimitetaan, kenelle ja milloin tuotantoresurssit ovat käytettävissä. Päätösprosessi on yritykselle tärkeä, kuitenkin vain harvat yritykset käyttävät hyväkseen oman toimitusketjun hallitaan alan tutkijoiden kehittämiä satoja eri sääntöjä, jotka auttavat parempaan tilausten hallitsemiseen ja aikataulutukseen. Helsingin Kauppakorkeakoulussa (HKKK) kehitetyn CoSCA (Coordination of Supply Chain Activities) simulaattorin avulla on ollut tarkoitus mallintaa tilaus-toimitusketjun päätöksiä ja hajautettua tuotannonohjausta. Tällä hetkellä simulaattorilla on ollut yksi käyttäjä eikä siihen näin ollen ole kehitetty graafista käyttöliittymää. Asiakkaan keskeisenä tavoitteena on päästä hyödyntämään simulaattoria tuotannon suunnittelun ja ohjauksen sekä toimitusketjun hallinnan opetuksessa. Lisäksi asiakas haluaisi tarjota yritysmaailmassa työskenteleville käytännönihmisille mahdollisuuden ymmärtää kokeilun kautta, miten erilaisten päätössääntöjen käyttäminen vaikuttaa tilaus-toimitusprosessin ennustettavuuteen ja tehokkuuteen. Tässä ohjelmistokehitysprojektissa on tarkoitus toteuttaa olemassa olevaan CoSCA -simulaattoriin helposti opittava ja miellyttävä käyttöliittymä, jonka avulla oppijat pystyvät kokeilemaan, miten erityyppisten päätössääntöjen käyttäminen erilaisissa tilanteissa vaikuttaa töiden läpimenoon liittyviin tunnuslukuihin. Projektin alussa tullaan kartoittamaan myös muiden lisätoiminnallisuuksien tarvetta ja toteutusmahdollisuuksia tässä projektissa. Tämän ohjelmistokehitysprojektin toteuttaa - projektiryhmä T Ohjelmistoprojekti I-kurssin harjoitustyönä. Projektiryhmässä on 7 henkilöä, joista kaikilla on kiinteä 150 tunnin työmäärä käytettävissä projektiin. Osa ryhmän jäsenistä suorittaa projektin ohessa parityönä työmäärältään 20h/henkilö olevan T Ohjelmistotuotannon erikoiskurssin projektia tukevasta aiheesta ja panostavat projektiin 20h/henkilö lisää. Projektin aikataulu on kiinteä alkaen ja loppuen , sisältäen joululoman
6 1.2 Terminologia ja määritykset Seuraavassa taulukossa 1 on kuvattu tässä dokumentissa ja projektissa käytettäviä termejä ja lyhenteitä. Taulukko 1. Projektissa käytettäviä lyhenteitä ja terminologiaa Termi tai lyhyenne Kuvaus CoSCA Coordination of Supply Chain Activities CoSCA järjestelmä Tässä projektissa kehitettävä järjestelmä, joka käsittää sekä jo kehitetyn simulaattorin, että siihen kehitettävän käyttöliittymän. CosCA simulaattori HKKK:ssa kehitetty CoSCA simulaattori, jossa ei toistaiseksi ole varsinaista käyttöliittymää. HKKK Helsingin Kauppakorkeakoulu I1 1. Toteutusiteraatio (Implementation 1) I2 2. Toteutusiteraatio (Implementation 2) LOC Lines of Code Koodirivien määrä Management ryhmä Projektin johtoryhmä, johon kuuluvat projektipäällikkö (Elina), vaatimusmäärittelijä (Laura) sekä pääsuunnittelija(kari). NCLOC Lines of code without comments and blank lines Koodirivien määrä, poislukien kommenttirivit ja tyhjät rivit PP Projektisuunnittelu iteraatio Projektiryhmä Projektin toteuttava ryhmä (management ryhmä + suunnittelijat), jossa on seitsemän jäsentä. SEPA Software Engineering Practice Assignment, erillinen projektin ohessa pääasiassa parityönä toteutettava työ Suunnittelijat Projektin 4 jäsentä (Santeri, Samuel, Aleksi ja Vesa), joiden päävastuulla on järjestelmän tekninen suunnittelu, ohjelmointi ja testaus. TKK Teknillinen korkeakoulu XML Extensible Markup Language, tiedosto formaatti 2
7 1.3 Järjestelmä ja ympäristö Tämän projektin keskeisin tavoite on toteuttaa olemassa olevaan CoSCA-simulaattoriin graafinen käyttöliittymä. Olemassa oleva CoSCA -simulaattori on toteutettu Javalla, käyttäen open source työkaluja. Järjestelmää kehitetään ja testataan Windows-ympäristössä. Järjestelmän simulaatioajo kestää tyypillisesti (opetuskäytössä) muutaman sekunnin, haastavassa tapauksessa (tutkimuskäytössä) noin tunnin. Simulaattoria varten ei tarvita erillistä erikoisalustaa. Kuva 1. Simulaattorin rakennekaavio. Tällä hetkellä simulaattori lukee asetuksensa XML -tiedostosta ja palauttaa tuloksensa tekstimuodossa, joka voidaan jatkokäsitellä esim. Excel-taulukossa. Tarkempaa tietoa CoSCA-Tekninen Määrittely dokumentissa. Järjestelmä toimii seuraavanlaisessa esimerkkikokoonpanossa: Pentium 4 (2,6 Ghz), 512Mb muistia. 3
8 2 Osapuolet ja henkilöstö Kuvassa 2 on esitetty projektin osapuolet. Asiakas Katariina Kemppainen Tekninen ohjaaja Lauri Svan Käyttäjät Projektiryhmä Projektipäällikkö Elina Kontro Vaatimustenhallinta Pääsuunnittelija Laura Lehtola Kari Ylihärsilä Suunnittelijat Aleksi Airola Vesa Haukkavaara Samuel Korpi Santeri Saarinen Mentor Kari Suhonen Kuva 2. Projektin osapuolet 2.1 Projektiryhmä Projektiryhmän vastuulla on selvittää asiakkaan vaatimukset ja toteuttaa niiden mukainen käyttöliittymä ja toiminnallisuus CoSCA-simulaattoriin. Taulukossa 2 on esitetty projektiryhmän jäsenten roolit yleisellä tasolla sekä heidän yhteystietonsa. Taulukko 2. -projektiryhmä ja yhteystiedot Rooli Nimi Puhelinnumero Sähköpostiosoite Projektipäällikkö Elina Kontro elina.kontro(at)pp.inet.fi Mentoryhteyshenkilö Vaatimustenhallinta, Laura Lehtola laura.lehtola(at)hut.fi Asiakasyhteyshenkilö Pääsuunnittelija Kari Ylihärsilä kylihars(at)cc.hut.fi Tekninenyhteyshenkilö Suunnittelija Aleksi Airola aleksi.airola(at)tkk.fi Suunnittelija Vesa Haukkavaara vthaukka(at)cc.hut.fi Suunnittelija Samuel Korpi sjkorpi(at)cc.hut.fi Suunnittelija Santeri Saarinen santeri.saarinen(at)hut.fi 4
9 2.2 Muut osapuolet Projektin muut osapuolet ovat asiakas ja T Ohjelmistoprojekti 1 -kurssin henkilökunta. Asiakas-osapuoli voidaan jaotella itse asiakkaaseen, tekniseen ohjaajaan sekä ohjelmiston tuleviin käyttäjiin. Projektin asiakas ja yhteyshenkilö on Katariina Kemppainen Helsingin Kauppakorkeakoulusta. Asiakkaan vastuulla on esittää tavoitteet ja vaatimukset projektille prioriteettijärjestyksessä sekä hyväksyä toteutettu järjestelmä. Tekninen ohjaaja Lauri Svan on toteuttanut CoSCA simulaatorin nykyisen version ja hän on käytettävissä olemassa olevan toteutuksen teknisten ratkaisujen opastamisessa, sekä tulevan toiminnallisuuden suunnittelussa tekniseltä kannalta. Ohjelmiston käyttäjää projektissa edustaa joukko Helsingin Kauppakorkeakoulun opiskelijoita. Asiakaan vastuulla on auttaa etsimään vähintään kolme opiskelijaa, jotka tulevat olemaan käytettävissä projektin aikana (max. 5h/hlö). Käyttäjiltä pyritään kartoittamaan simulaattorin käyttöön liittyviä tarpeita ja lisäksi käyttäjät osallistuvat projektin puitteissa järjestettäviin käytettävyystesteihin. Mentor Kari Suhonen edustaa kurssin henkilökuntaan, auttaa projektiryhmää projektissa erityisesti kurssin suorittamiseen liittyvissä kysymyksissä sekä arvostelee palautukset. Taulukko 3. Muiden osapuolien yhteystietoja Rooli Nimi Puhelinnumero Sähköpostiosoite Asiakas Katariina Kemppainen katariina.kemppainen(at)hkkk.fi Tekninen ohjaaja Lauri Svan lauri.svan(at)hut.fi Käyttäjä N.N. Käyttäjä N.N. Käyttäjä N.N. Mentor Kari Suhonen kari.suhonen(at)hut.fi 5
10 3 Tavoitteet ja lopetuskriteerit Seuraavissa kappaleissa kuvataan projektiryhmän ja asiakkaan asettamia tavoitteita projektille sekä projektin keskeytys ja lopetuskriteerit 3.1 Asiakkaan tavoitteet Taulukko 3 listaa asiakkaan tärkeimmät tavoitteet ja niiden hyväksyntäkriteerit prioriteettijärjestyksessä. Taulukko 4: Asiakkaan tärkeimmät tavoitteet Tavoite 1. Kyetä käyttämään järjestelmää opetuksen apuvälineenä HKKK:n tilaus-toimitus kurssilla sekä yritysyhteistyössä 1.1 Havainnollistaa tilaus-toimitus -aihealueen pääkäsitteitä ja niiden välisiä suhteita 1.2 Havainnollistaa graafisesti päätössääntöjen ominaisuuksia ja kyvykkyyttä erilaisissa tilanteissa 1.3 Tarjota opiskelijoille mahdollisuus pelata toisiaan vastaan tilaus-toimitus päätösvalintojen tekemisessä 1.4 Tarjota opiskelijoille mahdollisuus itse kokeilla käytettyjen päätössääntöjen vaikutusta läpimenoaikoihin erilaisilla koeasetelmilla 1.5 Tarjota opiskelijalle mahdollisuus tarkastella simulaatioajon vaiheita graafisesti 2. Käyttää olemassa olevan CoSCA simulaattorin tärkeimpiä toiminnallisuuksia graafisen käyttöliittymän avulla 3. Järjestelmän jatkokehitettävyys 4. Erilaiset käyttäjäryhmät kykenevät helposti saamaan ja asentamaan ohjelman itselleen 5. Lisätä asiakkaan omaa ymmärrystä siitä, miten tilaus-toimitus -aihealueen asioita pitäisi opettaa Hyväksyntäkriteeri Kohtien toteutuminen Järjestelmällä kykenee helposti luomaan erilaisia testitilanteita (= systeemeitä) Käyttöliittymän avulla kykenee ajamaan läpi erilaisia testitilanteita, joiden tulokset järjestelmä esittää opiskelijan ymmärtämässä muodossa. Käyttöliittymä ilmoittaa tilanteen valittujen muuttujien suhteen valittuna ajanhetkenä. Järjestelmä on niin helppokäyttöinen ja intuitiivinen, että käyttäjän ei tarvitse olla aihealueen asiantuntija. Käyttöliittymässä on mahdollisuus tarkastella ajon tilannetta tärkeimpien muuttujien suhteen tietyissä ajonaikaisissa pisteissä. Tutkija voi itse käyttää itselleen tärkeimmiksi nimeämiään simulaattorin ominaisuuksia nykyistä toimintatapaa helpommin. Koodi on modulaarista ja kommentoitu projektissa päätetyn käytännön mukaisesti. Järjestelmä on paketoitu ja siinä on käyttö- ja asennusohjeet. Järjestelmän voi kätevästi asentaa Windows XP käyttöjärjestelmään. Asiakas pystyy nimeämään vähintään kaksi oivallustaan siitä, miten aihealueen vaikeimmat asiat selitetään aihealuetta tuntemattomille yliopistoopiskelijoille. 6
11 3.2 Projektiryhmän tavoitteet Projektiryhmän tavoitteet ja kriteerit, joilla nämä tavoitteet todetaan saavutetuiksi on listattuna taulukossa 5. Taulukko 5: Projektiryhmän yhteiset tavoitteet Tavoite Hyväksyntäkriteeri 1. Kurssin läpäiseminen Ryhmä saa kurssista hyväksytyn arvosanan 2. Saada aikaan asiakkaan tarpeita vastaava tuote 3. Saada käytännön kokemusta ohjelmistotuotteen toteuttamisesta iteratiivisesti ja inkrementaalisesti 4. Henkilökohtaiset oppimistavoitteet saavutetaan Asiakas on tyytyväinen toteutettuun ja toimitettuun ohjelmistoon, ja kokee sen täyttävän sille asetetut vaatimukset. Projektin jälkeen jokainen ryhmän jäsen kokee tietävänsä enemmän ko. ohjelmistokehitysmenetelmästä kuin ennen projektin alkua ja pystyy mainitsemaan jonkin menetelmästä käytännön kautta oppimansa asian. Jokainen ryhmän jäsen kokee saavuttaneensa itselleen asettamansa oppimistavoitteet (luku 3.3) 5. Kurssista saadaan arvosana 5 Ryhmän lopullinen arvosana kurssista on 5 6. Saada onnistuneesta projektista maininta ansioluetteloihin 7. Oppia uusia ohjelmistotuotannon tekniikoita 8. Sujuva kommunikaatio asiakkaan kanssa 9. Projektiryhmän toimiva kommunikointi ja ryhmätyöskentely Projektiryhmä saa työstään positiivisen arvion sekä asiakkaalta että järjestävältä kurssilta ja voi tätä tunnustusta hyödyntää tulevissa työnhakutilanteissaan. Kukin projektiryhmän jäsen pystyy listaamaan 3 ohjelmistotuotannon tekniikkaa tai työkalua, joista kokee tietävänsä enemmän kuin ennen projektin alkua. Asiakas kokee saaneensa riittävästi tietoa projektin etenemisestä koko projektin ajan ja voineensa vaikuttaa siihen, mitä ominaisuuksia järjestelmään toteutetaan. Sovitut tehtävät hoidetaan sovittuihin päivämääriin mennessä ja työmäärä jakaantuu tasaisesti ryhmän kesken. Ryhmänjäsenet kokevat pysyvänsä riittävällä tarkkuudella ajan tasalla muiden ryhmäläisten tekemisistä. 10. Tavoitteet on asetettu oikein suhteessa käytettäviin resursseihin Projektin tavoitteet saavutetaan ylittämättä kurssin asettamaa työpanosta (150 h tai 190h/ henkilö). 7
12 3.3 Henkilökohtaiset oppimistavoitteet Taulukossa 6 on lueteltu jokaisen ryhmän jäsenen henkilökohtaiset oppimistavoitteet. Taulukko 6: Henkilökohtaiset oppimistavoitteet Ryhmän jäsen Rooli Henkilökohtainen oppimistavoite Santeri Saarinen Samuel Korpi Vesa Haukkavaara Aleksi Airola Kari Ylihärsilä Laura Lehtola Elina Kontro Suunnittelija Saada käytännön kokemusta tämän suuruusluokan (7 henkeä, 6kk) ohjelmistoprojektista. Projektissa haluaisin erityisesti saada kokemusta projektin laadunhallinnasta, dokumentoinnista, sekä projektin etenemisen seuraamisesta sille asetettujen vaatimusten näkökulmasta. Suunnittelija Suunnittelija Suunnittelija Pääsuunnittelija Vaatimusmäärittelijä Projektipäällikkö Oppia paremmin hyödyntämään tarjolla olevia ohjelmistokehitystyökaluja (erityisesti Eclipse) erilaisissa ohjelmistokehitysprojekteissa. Kehittää olemassa olevia ryhmätyöskentelytaitojaan. Tärkein tavoitteeni on oppia käyttöliittymä- ja käytettävyyssuunnittelun perusteet sekä käytettävyystestauksen asioita. Toinen tavoitteeni on syventää osaamistani oliopohjaisen järjestelmän suunnittelutavoissa. Lisäksi toivon projektin suorittamisen välillisesti tukevan tuotantotalouden opintojani. Odotan pääseväni soveltamaan opittuja asioita siinä laajuudessa, että se valmistaa työelämää varten. Olen perehtynyt jonkin verran käytettävyyteen ja on aika päästä kokeilemaan omia siipiään. Konkreettisina oppimistavoitteina on tutustuminen tarkemmin vaatimustenmäärittelyyn ja - hallintaan sekä Eclipse kehitysympäristön ja sen plug-inien kokonaisvaltaisempi hallitseminen. Opettelen, miten 7-henkisen projektiryhmän toimintaa pyöritetään niin, että projekti kantaa hedelmää. Opin tuntemaan ohjelmistoprojekteja niin, että voisin muun koulutuksen avulla madollisesti konsultoida alalla. Opin ihmisten johtamisesta ja ohjelmistoarkkitehtuurin suunnittelusta niin, että selvästi koen olevani valmis näihin myös työtehtävissä. Saada käytännön kokemusta käyttäjälähtöisestä vaatimusmäärittelytyöstä tiiviissä yhteistyössä asiakkaan kanssa, sekä oppia lisää asiakkaan odotuksien hallitsemisesta ja asettamisesta oikealle tasolle. Oppia lisää menestyksellisestä toimimisesta asiaorientoituneen asiakkaan ja teknisesti orientoituneiden kehittäjien välillä. Saada kokemusta ohjelmistokehitysprojektin vetämisestä Käytettävyys-näkökulman soveltaminen käytännön projektissa 8
13 3.4 Projektin keskeytyskriteerit Projekti keskeytetään projektiryhmän yhteisellä päätöksellä, mikäli kaksi tai useampi projektiryhmän jäsen jättää projektin kesken tai mikäli asiakas lopettaa yhteistyön projektiryhmän kanssa. 3.5 Projektin lopetuskriteerit Projekti loppuu, kun jokin seuraavista kriteereistä täyttyy: Kurssi päättyy aikataulunsa mukaisesti Asetettuja tavoitteita vastaava tuote on toimitettu asiakkaalle, ja asiakas on sen hyväksynyt Asiakas hyväksyy projektin päättyneeksi muista syistä 9
14 4 Resurssit ja budjetti Seuraavassa kuvataan projektin suunnitellut resurssit ja budjetti. 4.1 Henkilöt Projektin työmääräarviot vaiheittain kullekin henkilölle on esitetty taulukossa 7. Työmääräarvioita päivitetään, kun todelliset työmäärät selviävät ja myöhempien vaiheiden suunnittelu tarkentuu. Koko projektissa yksittäisen henkilö työmäärä kokonaisuudessaan on joko 150h tai 190h. Laajempi työmäärä pitää sisällään SEPA-työn. Taulukko 7: Projektin työmääräarviot vaiheittain Elina Laura Kari Aleksi Vesa Samuel Santeri Kontro Lehtola Ylihärsilä Airola Haukkavaara Korpi Saarinen Yhteensä PP I I Yhteensä Materiaalihankinnat Työn tekeminen ei edellytä erityisiä ohjelmisto- tai laitteistohankintoja. Projektissa tullaan käyttämään omia sekä SoberIT -laboratorion laitteistoja, sekä ohjelmistoja jotka ovat joko open source tuotteita tai käytettävissä SoberIT -laboratorion tai TKK:n ATK-keskuksen puolesta. 4.3 Budjetti Taulukossa 8 on esitetty projektin teoreettinen budjetti, jonka tarkoituksena on havinnollistaa mitä tämän kokoinen projektin todellisuudessa voisi maksaa. Projektiryhmän työstä ei todellisuudessa laskuteta, joten se ei aiheuta kuluja asiakkaalle. 10
15 Taulukko 8: Projektin arvioitu budjetti Kustannuserä Työmääräarvio Palkkio/h Kustannukset Asiakkaan SoberIT:lle maksama summa Asiakkaan projektiin käyttämä aika 100 h Projektiryhmän työ h Kustannukset yhteensä Työkäytännöt ja työkalut Tässä kappaleessa kuvataan projektissa käytettävät työkäytännöt sekä työkalut. Osa käytännöistä on pakollisia kurssin puolesta ja osa on erikseen valittu helpottamaan projektin kulkua. 5.1 Käytännöt Seuraavissa kappaleissa on kuvattu projektissa noudatettavat käytännöt. Lisäksi luvussa 5.2 on listattu SEPA - käytännöt, joita projektissa käytetään Iteratiivinen kehitys Projektissa tuotettava ohjelmisto toteutetaan käyttäen iteratiivista ja inkrementaalista kehitysmallia. Projekti koostuu kolmesta iteraatiosta, joita ovat projektin suunnittelu (PP), toteutusiteraatio 1 (I1) sekä toteutusiteraatio 2 (I2). Vaiheiden tavoitteet, tehtävät ja aikataulut on kuvattu tarkemmin kappaleessa 6 Vaiheistus. I1-iteraatiossa pyritään toteuttamaan asiakkaan vaatimusten mukaiset keskeisimmät ominaisuudet siten, että iteraation lopussa pidettävässä iteraatiodemossa esitetään testattu ja toimiva sovellus. I2-iteraatiossa sovellukseen lisätään toiminnallisuutta iteraation alussa tehtävän suunnitelman mukaisesti. Toteutusiteraatiot voidaan vielä sisäisesti jakaa seuraaviin päävaiheisiin: suunnittelu, toteutus, testaus ja iteraatio demo. Tarkemmin iteraatioiden sisäinen vaiheistus aikatauluineen on kuvattu kappaleissa 6.2 Toteutusiteraatio 1 ja 6.3 Toteutusiteraatio Iteraation suunnittelu Iteraation tarkempi suunnittelu tehdään ko. iteraation alussa. I1 ja I2 iteraatioiden suunnittelu tehdään yhdessä asiakkaan kanssa edellisen vaiheen iteraatiodemon jälkeen. Iteraation suunnittelupalaverissa projektiryhmä esittää alustavan ehdotuksen tulevalle iteraatiolla työmääräarvioineen. Asiakas voi esittää muutoksia ja asiakas 11
16 on vastuussa iteraatioon valittujen vaatimusten asettamisesta toteutusjärjestykseen. Asiakaspalaverin jälkeen, iteraation ensimmäisen viikon aikana suunnitelmaa ja työmääräarvioita tarkennetaan. Suunnittelijat osallistuvat suunnitelman tekemiseen ja työmäärien arviointiin I1 ja I2-iteraatioiden osalta. Iteraation suunnitelmat päivitetään tämän dokumentin lukuun 6. Vaiheistus. Ennen virallista aikataulun mukaista palautusta lähetetään suunnitelma asiakkaalle katselmoitavaksi Dokumentointi Projektissa tuotettava dokumentaatio palautetaan viimeistään sille määriteltynä palautuspäivänä sekä asiakkaalle että mentorille. Dokumentit lähetetään asianosaisille sähköpostitse PDF-formaatissa. Lisäksi dokumentit julkaistaan projektiryhmän kotisivulla. Projektissa käytettävä dokumentointikieli on suomi, paitsi teknisen spesifikaation, käyttäjän käsikirjan sekä koodin kommentoinnin osalta, jotka tulee tehdä englannin kielellä. Projektissa tuotettava dokumentaatio, vastuuhenkilöt ja dokumenttien palautuspäivämäärät on koostettu taulukkoon 9. Mikäli dokumentti katselmoidaan, on katselmoinnit myös merkitty. Taulukkoa päivitetään projektin edetessä kunkin vaiheen osalta. Taulukko 9. Dokumentit ja niiden vastuuhenkilöt Päävastuu Katselmointi pvm Katselmointi ryhmä Palautus pvm PP Projektisuunnitteluvaiheen Elina Kontro suunnitelma Projektisuunnitelma Elina Kontro Asiakas, Projektiryhmä Vaatimusmäärittely Laura Lehtola Asiakas, Projektiryhmä Tilannekatsausraportti Elina Kontro Managementtiimi Kehitystyöohjeistus Kari Ylihärsilä SEPA: Käyttäjätestit Elina Kontro SEPA: Coding Camp Kari Ylihärsilä I1 Projektisuunnitelma Laatusuunnitelma Tekninen määrittely Testaus Vaatimusmäärittely Tilannekatsausraportti SEPA päiväkirjat I2 Projektisuunnitelma Elina Kontro Kari Ylihärsilä Laura Lehtola Elina Kontro Elina Kontro 12
17 Laatusuunnitelma Tekninen määrittely Testaus Vaatimusmäärittely Vertaisryhmän testiraportti Vertaisryhmän Käyttäjän käsikirja Loppuraportti Tilannekatsausraportti SEPA päiväkirjat Kari Ylihärsilä Laura Lehtola Elina Kontro Elina Kontro Riskienhallinta Projektin riskienhallintaan käytetään kevennettyä ja modifioitua versiota Jyrki Kontion kehittämästä Riskit menetelmästä. Projektiin liittyvät keskeisimmät riskit pyritään tunnistamaan heti projektin alussa ja lisäksi yksittäisiin iteraatioihin liittyvät riskit tunnistetaan jokaisen iteraation aloituspalaverissa. Yleisimpien riskien osalta niiden tilaa monitoroidaan kerran kunkin iteraation aikana sen puolivälissä olevassa viikkopalaverissa. Mikäli jonkin riskin realisoitumisesta havaitaan merkkejä, analysoidaan sitä tarkemmin ja se otetaan erityistarkkailun alle. Riskilokia päivitetään kunkin seurantapalaverin yhteydessä. Projektin riskienhallintakäytäntö koostuu seuraavista askeleista: Uhkien tunnistaminen Uhkien syiden tunnistaminen Uhkien todennäköisyyden arviointi Uhkien vaikutusten arviointi Riskejä vähentävien toimien käyttäminen Riskitilanteen seuranta Tunnistetut uhat kootaan riskilokiin (Luku 7). Lokiin merkitään erikseen myös se, mikäli riski liittyy johonkin tiettyyn projektin vaiheeseen Tuntiraportointi Työtuntien raportointiin käytetään Excelillä tehtyä taulukkoa. Kullakin ryhmän jäsennellä on oma Excel - tiedosto, johon tunnit raportoidaan ja johon jokainen huolehtii omien tuntiensa raportoinnista. Tiedostossa on oma sivunsa jokaiselle iteraatiolle. Tiedostoja säilytetään ryhmän TikiWiki sivuilla. 13
18 Tunnit tulee raportoida päivittäin, mieluiten heti suoritetun tehtävän jälkeen. Jokaisen viikon maanantaina klo 12:00 tulee edellisen viikon tuntien olla ajan tasalla. Tämän jälkeen projektipäällikkö koostaa yhteenvedon raportoiduista tunneista ja kooste julkaistaan tiistaina projektiryhmän www-sivuilla. Tuntiraportointikoosteen perusteella tarkistetaan, onko tarvetta tehdä muutoksia esim. iteraation työmääräarvoihin, työtehtävien jakamiseen tai suunniteltuun toteutustoiminnallisuuteen Ohjelmakoodin koon raportointi Ohjelmakoodin koosta pidetään kirjaa koodirivien määrän perusteella (LOC ja NCLOC), sekä ohjelman arkkitehtuurikaavion avulla. Arkkitehtuurikaavio auttaa ymmärtämään ohjelman kompleksisuutta koodirivien määrää paremmin, ja antaa kokonaiskuvan ohjelman rakenteesta. Koodirivien määrä sen sijaan on kaaviota paremmin mitattavissa oleva, muihin projekteihin suhteuttamiskelpoinen elementti Kommunikointi ja palaverikäytännöt Kaikkiin ennalta sovittuihin palavereihin tulee olla agenda, joka toimitetaan osallistujille etukäteen. Palaverin alussa agenda käydään läpi ja tehdään tarvittaessa muutoksia. Viikkopalavereiden yhteydessä erillistä agendaa ei tarvitse lähettää, sillä palaverin agenda sovitaan aina edellisessä palaverissa. Kaikista palavereista tehdään pöytäkirjat, joihin kirjataan tärkeimmät päätökset. Pöytäkirjat tallennetaan TikiWikiin ryhmän kotisivuilla niille varattuun paikaan. Projektiryhmän sisäinen kommunikointi Projektinsuunnitteluiteraation aikana management -ryhmä kokoontuu viikkopalavereihin, jossa käydään läpi suunnittelua, tarkistetaan kunkin tehtävien eteneminen ja sovitaan seuraavat toimenpiteet. Tämän vaiheen aikana suunnittelijat pidetään ajan tasalla tärkeimmistä päätöksistä ja tapahtumista lähettämällä vähintään kerran viikossa tiedotuksia sähköpostitse. Suunnittelijoille järjestetään myös projektin käynnistyspalaveri PPiteraation aikana. I1- ja I2 iteraatioissa noudatetaan myös viikkopalaverikäytäntöä, jokaisena tiistaina seuraavanlaisella aikataululla: 9-10 Management-ryhmän palaveri Koko projektiryhmä Suunnittelijat Poikkeukset aikatauluun sovitaan aina erikseen. Viikkopalavereiden lisäksi voidaan järjestää erityisestä tarpeesta myös muita palavereita (kts. Esim. luku Pienryhmät). 14
19 Palaverien lisäksi ryhmän sisäiseen kommunikointiin käytetään sähköpostia ja kiireellisiä asioita sovitaan myös puhelimitse. Dokumentaation tallentamiseen ja jakamiseen ryhmän sisällä käytetään TikiWikiä. Lisäksi tutkitaan mahdollisuutta käyttää TikiWikiä keskustelufoorumina. Kommunkointi projektiryhmän ulkopuolelle Asiakkaan, teknisen ohjaajan ja mentorin kanssa kommunikoidaan sähköpostitse sekä tarvittaessa järjestetään yhteisiä palavereita. Mentorin kanssa palavereita järjestetään vähintään yksi jokaisessa iteraatiossa. Asiakkaalle, tekniselle ohjaalle ja mentorille tarjotaan pääsy projektissa tuotettavaan materiaalin, kuten esim. vaatimusmäärittely, projektisuunnitelma ja yhteisten palaverien pöytäkirjat. Ko. dokumentit jaetaan joko TikiWikin tai erillisten www-sivujen kautta. Projektin vastuuhenkilö asiakkaan suuntaan on Laura Lehtola. Hänen tehtävänsä on sopia asiakkaan kanssa tarvittavista tapaamisista ja toimista, sekä monitoroida asiakkaan tyytyväisyyttä ja pitää huolta siitä, että projekti on asiakkaan näkökulmasta menossa oikeaan suuntaan. Projektin vastuuhenkilö mentorin suuntaan on Elina Kontro Pienryhmät PP-iteraation loppupuolella projektiryhmä jaetaan kolmeen ns. pienryhmään. Pienryhmätoiminnan tarkoituksena ottaa suunnittelijat mukaan suunnittelutehtäviin PP-iteraation aikana ja tämän avulla myös tehostetaan I1- iteraation käynnistymistä. Nyt sovitut pienryhmät ovat toiminnassa vähintään I1-iteraation alussa, mutta tarvittaessa vastuualueestaan riippuen myös I2-iteraation aikana. Ryhmät raportoivat edistymisestään viikkopalavereissa. Taulukkossa 10 on lueteltu sovitut pienryhmät ja niiden kokoonpanot. Ryhmien tuotosten aikataulut noudattavat projektin aikatauluja. Taulukko 10. Pienryhmät Pienryhmän vastuualue Tuotos Vaiheet Ryhmän jäsenet Arkkitehtuurin suunnittelu Käyttöliittymäprototyyppi Laadunvarmistussuunnittelu Arkkitehtuurisuunnitelma Ns. Paperiprototyyppi järjestelmän käyttöliittymästä Laatusuunnitelma (Testaussuunnitelma) I1 I1 I1,I2 Kari Ylihärsilä Samuel Korpi Vesa Haukkavaara Laura Lehtola Aleksi Airola Elina Kontro Santeri Saarinen Kari Ylihärsilä Elina Kontro Myöhemmin ryhmien kokoonpanoja voidaan muuttaa ja tarvittaessa voidaan sopia kokoaan uusia pienryhmiä. 15
20 5.1.9 Katselmointikäytännöt Projektin sisäinen katselmointiprosessi on viisivaiheinen ja se on esitetty seuraavassa numeroidussa listassa. 1) Jokaiselle projektissa tuotettavalle dokumentille määritellään vastuuhenkilö ja katselmointiryhmä. (Termillä dokumentti tarkoitetaan myös iteratiivisesti kehitettävän dokumentin uutta toimitettavaa versiota.) 2) Dokumentille määritellään palautuspäivämäärä sekä katselmointiajankohta. 3) Tuotettavan dokumentin vastuuhenkilö on velvollinen toimittamaan dokumentin katselmoitavaksi katselmointiryhmän jäsenille vuorokautta ennen katselmointiajankohtaa. 4) Katselmointiryhmän tehtävänä on katselmoida dokumentti seuraavista näkökulmista: Pienet puutteet, suuret puutteet, virheet, heränneet kysymykset. 5) Dokumentin vastuuhenkilö määrittää katselmointitilaisuudessa, miten ongelmat korjataan siten, että saadaan palautettua hyvä versio dokumentista. Osa dokumenteista katselmoidaan asiakkaan kanssa. Riippuen dokumentista katselmointi on joko kevyt tai perusteellinen. Kevyessä katselmoinnissa asiakkaan kanssa sovitaan päivä, jolloin hän saa sähköpostitse dokumentin itselleen Word-muodossa ja päivä, jolloin hän palauttaa sen kommentoituna takaisin sähköpostitse. Perusteellisessa katselmoinnissa asiakkaan kanssa sovitaan päivä, jolloin hän saa sähköpostitse dokumentin itselleen ja päivä, jolloin kokoonnutaan fyysisesti samaan paikkaan (asian kannalta olennaisimmat edustajat projektiryhmästä + asiakas) kuulemaan asiakkaan kommentit ja sopimaan asioista, jotka asiakkaan mielestä ovat dokumentissa epätarkasti tai vaatii muuten korjaamista Iteraatiodemot Iteraatiodemo toteutetaan kurssin ohjeistuksen mukaisesti. Projektipäällikkö valmistelee kalvoesitysmuotoon tilannekatsausraportin ennen iteraatiodemoa niin, että se voidaan katselmoida demoa edeltävässä viikkopalaverissa. Ohjelmiston toiminnallisuuden demonstroinnista I1 ja I2 iteraatiodemoissa vastaa pääsuunnittelija. Iteraatio demossa esitettävän sovelluksen version tulee olla, esitysmateriaalin tavoin, läpikäytävissä demoa edeltävässä viikkopalaverissa. Iteraatiodemon päivämäärät on asetettu kurssin puolesta ja iteraatiodemot pidetään Innopoli2:ssa SoberITtiloissa. Tarkemmat kellonajat ehdotetaan myös kurssin puolesta ja ovat nähtävissä kurssin kotisivuilla. Asiakasyhteyshenkilö varmistaa ajan sopimisen asiakkaalle ja tekniselle ohjaajalle. 16
21 PP iteraation demo pidetään klo 13 ja I1-demo Projektipäällikön vastuulla on, että katselmointitilaisuudessa pysytään aikataulussa ja kaikki olennaiset asiat saadaan esitettyä Vikojen seuranta Vikojen seurantaan käytetään julkisesti saatavilla olevaa Bugzilla-työkalua ( Yksityiskohtainen ohje Bugzillan käytöstä tehdään I1 iteraation alussa tehtävään erilliseen työkaluohje-dokumenttiin Versionhallinta Projektin versionhallintatyökaluna käytetään CVS-versionhallintajärjestelmää. Repositorio sijaitsee ryhmän yhteisen työhakemiston alle ATK-keskuksella ja järjestelmään kytkeydytään suoraan Eclipsen kautta. Ennen omien tuotosten laittamista ajetaan aina cvs update. Vain kääntyvää ja toimivaa ohjelmakoodia saa päivittää repositorioon. Lisäksi koodin tulee olla kommentoitua ennen laittamista repositorioon. Versionhallinnan käyttämisestä tehdään tarkempi kuvaus I1 iteraation alussa kirjoitettavassa erilliseen työkaluohjeessa Koodauskäytäntö Ohjelmointi tehdään Javalla. Javan koodauskäytäntöinä käytetään Sunin määrittelemää Javakoodauskonventiota ( josta tehdään lyhyt yhteenveto-ohje työkaluohjeisiin. Monen suunnittelijan projektissa koodin selvä kommentointi (kriteerinä: ymmärtävätkö muut?) nousee tärkeään asemaan, tämä on myös vaatimus jatkokehtitettävyyden helpottamiseksi. Tästä syystä koodin tulee olla kommentoitua ennen CVS:n laittamista. Ei-itsestäänselvien metodien ja kenttien lisäksi kommentoidaan ratkaisun vieressä myös ongelmissa käytettyjä ratkaisutapoja. Lisäksi ohjelmakoodin kommentteihin upotetaan viestejä, ehdotuksia ja kysymyksiä toisillemme TODO-ja FIXME tagien tapaan. Tähän käytetään KYS: -tageja paikallistamaan kysymykseen relevanttia koodia. KYS: -tagin perään voidaan kirjoittaa henkilön nimi, kenelle kysymys on osoitettu ja kysymyksen perään oma nimi, jotta kysymyksen saaja voi halutessaan vastata suoraan kysyjälle. Tagin ja kysymyksen vastaanottajan nimen väliin laitetaan kaksoispiste, mutta ei välilyöntiä. Tämä sen takia, että kehittäjien on helppo etsiä vakiomuotoisella tavalla koodista itselleen osoitettuja kysymyksiä. Esimerkkejä: o o //KYS:Samuel Miten luokkien tyyppihierarkia tarkistetaan? Kari //TODO:Kari Koko puurakenteen läpikäynti. -Kari 17
22 Vertaistestaus Vertaistestaus tehdään kurssin ohjeiden mukaisesti I2 iteraatiossa ja siitä laaditaan tarkempi suunnitelma ko. iteraation alussa Vaatimusten määrittely ja hallinta Vaatimusmäärittely on silta asiakkaan ja projektiryhmän välissä. Siksi vaatimusten määrittelyyn ja hallintaan kiinnitetään erityistä huomiota projektin aikana ja sitä pyritetään tekemään mahdollisimman paljon yhteistyössä asiakkaan kanssa Hankinta Projektin asiakas- ja käyttäjätarpeet hankitaan iteratiivisesti. Tarpeiden kartoitus aloitetaan asiakkaan korkeantason tavoitteiden ja projektin tärkeimpien käyttäjäryhmien selvittämisestä ja priorisoinnista. Näiden perusteella tehdään käyttäjätutkimus simulaattorin toistaiseksi ainoalla käyttäjällä, joka on myös tämän projektin asiakas. Käyttäjätutkimuksessa seurataan simulaattorin käyttöä sen todellisessa käyttöympäristössä, sekä pyydetään käyttäjää mm. kuvailemaan tekemiään toimia ja toiminnan vaiheita sanallisesti käyttäjän termistön selvittämiseksi. Edellisten aktiviteettien tulosten pohjalta tehdään vaatimusmäärittelyn ensimmäinen versio sekä käyttöliittymäprototyyppi, josta haetaan palautetta asiakkaalta ja jota testataan tärkeimmällä käyttäjäryhmällä, opiskelijakäyttäjillä Analysointi ja priorisointi Hankittuja vaatimuksia analysoidaan kolmesta näkökulmasta, joiden perusteella niille annetaan toteutusprioriteetti (= vaihe). Näkökulmia ovat: tärkeys asiakkaalle, kiireys arkkitehtuurin kannalta toteutuskustannukset Tärkeyttä asiakkaalle arvioidaan neliportaisella asteikolla (1-4), joista kaikista ylimpään luokkaan asiakas saa asettaa korkeintaan 20% vaatimuksista. Kiireyttä arkkitehtuurin kannalta ja toteutuskustannuksia arvioidaan kolmiportaisella asteikolla. Nämä arviot tekee projektiryhmä. Toteutuskustannusten arvioinnissa otetaan huomioon kaikki vaatimuksen eteen tehtävä työn määrittelystä testaukseen ja käyttöohjeiden kirjoittamiseen. Jokaisen iteraation alussa valitaan arvioitujen näkökulmien perusteella yhdessä asiakkaan kanssa vaatimukset, jotka iteraation aikana tullaan toteuttamaan. Asiakkaan on asetettava vaatimukset asetetaan kolmeen prioriteettiluokkaan siten, että korkeimpaan prioriteettiluokkaan asiakas saa asettaa ainoastaan 20% vaatimuksista, ja toisiksi korkeimpaan 50%. Alimman luokan prioriteetteja suhteessa toisiinsa tarkennetaan iteraation aikana asiakaspalaverissa mikäli tarpeellista. 18
23 Toteutusiteraatioiden aikainen vaatimustenhallinta Iteraation alussa toteutettaviksi valittuja käyttötapauksia tarkennetaan yksityiskohtaisiksi käyttötapauksiksi. Kaikentyyppisten vaatimusten tilaa monitoroidaan koko projektin ajan. Mahdolliset tilat vaatimukselle on esitetty taulukossa 11. Taulukko 11: Tila Ehdotettu Hyväksytty iteraation x Toteutettu Testattu Toimitettu Hylätty Kuvaus Vaatimus on esitetty ja jossakin määrin analysoitu ohjelmiston kannalta olennaiseksi, mutta ei vielä hyväksytty mihinkään toteutusiteraatioon. Vaatimus on sovittu toteutettavaksi iteraatiossa x. Vaatimus on toteutettu, mutta sitä ei vielä ole testattu. Vaatimus on testattu ja projektiryhmän näkökulmasta valmis. Vaatimus on toteutettu asiakkaalle, joka sen on hyväksynyt. Vaatimus on hylätty Asiakas- ja käyttäjänäkökulman varmistaminen projektin aikana Asiakkaan ja käyttäjän äänen kuulumiseksi ja säilymiseksi koko projektin ajan kiinnitetään erityistä huomiota. Keskeistä tämän asian varmistamiseen on tiivis yhteistyö asiakkaan kanssa koko projektin kanssa. Lisäksi tämä varmistetaan iteraatiokohtaisilla toimenpiteillä, joista keskeisimmät on lyhyesti lueteltu seuraavassa. Project planning iteraatio Kevyt käyttäjätutkimus, jossa selvitettiin simulaattorin toistaiseksi ainoan käyttäjän kanssa aidossa käyttötilanteessa, mitkä ovat käytön perussekvenssit ja kuinka paljon erilaisia toimintoja käytetään Tiivis yhteistyö asiakkaan kanssa tärkeimpien käyttäjäryhmien ja heidän keskeisten tarpeidensa selvittämiseksi Asiakkaan osallistuminen vaatimusmäärittelyyn iteratiivisesti (raakaversioiden komentointi + puhelinkeskustelut) Toteutusiteraatio 1 Käyttöliittymäprototyypin kehittäminen palautteen saamiseksi. Prototyyppi tehdään quick and dirty tyylisesti Eclipsen käyttöliittymätyökalulla siten, että se ei ole kiinni nykyisen simulaattorin koodissa. Käyttöliittymäprototyypin testaus. Testihenkilöinä 2 opiskelijakäyttäjää ja asiakas. 19
24 Pyritään siihen, että lähes jokainen suunnittelija osallistuu vähintään yhteen käyttäjätestiin, jotta he näkevät oikean käyttäjän ja saavat tuntumaa siitä, mikä on hyvää ja mikä ei. Iteraation lopussa käyttäjätestit simulaattorin senhetkisellä versiolla (3 opiskelijakäyttäjää). Toteutusiteraatio 2 On-line helpin rakentaminen Käyttöohjeen kirjoittaminen 5.2 Laadunvarmistussuunnitelma Päivitetään I1-iteraation alussa! Projektitason asiat Iteraatiotason asiat 5.3 Työkalut Projektissa käytetään seuraavia työkaluja Kehityslaitteisto Projektissa tuotettavan ohjelmiston kehittämiseen ei tarvita mitään erikoislaitteistoa. Tavallinen kotitietokone (teholuokkaa P4 2,6 Ghz, 512Mb muistia) riittää hyvin. Ohjelman kehitys tapahtuu sekä ryhmän jäsenten omilla tietokoneilla, että SoberIT:n tietokoneilla. Kaikki käytettävät työkalut ovat joko open source -tuotteita tai ne on saatavilla TKK ATK-keskuksen tai SoberITlaboratorin puolelta. Borlandin Together Architectia, tarjotaan käyttöön projektin ajaksi kurssin puolesta Ohjelmistot Eclipse 3.1 Kehitysympäristö: Tulee Together Architectin mukana. Lisätietoa: Borland Together Architect: Ladataan kurssin kotisivuilta Työkalut -osiosta. Sun Java Java 2 Platform Standard Edition 5.0 Development Kit (JDK) (JDK 5.0 Update 5 Paketti) 20
25 CVS Versionhallintatyökalu: Sisältyy Eclipseen Apukirjastot: Nämä tulevat ohjelmakoodin mukana. o Groovy-skriptauskieli: Groovy 1.0 JSR-03 tai uudempi (esim. groovy-1.0-jsr-03.zip osoitteesta o COLT-matematiikkakirjasto: Colt (esim. colt zip osoitteesta o Commons Beanutils-apukirjasto: Beanutils (esim. commons-beanutils zip osoitteesta o Commons Logging-apukirjasto: Logging (esim. commons-logging zip osoitteesta o Commons Digester-apukirjasto: Digester (esim. commons-digester-1.7.zip osoitteesta Bugzilla 2.20: Ohjelmaprojektin toteuttamiseen käytetään Javaa, kehitysympäristönä Eclipse 3.1. Borlandin Together Architectia käytetään ohjelmistoarkkitehtuurin suunnittelussa. Lisäksi käytetään, joitakin seuraavista Eclipsen lisäpalikkana saatavista graafisista käyttöliittymäeditoreista käyttöliittymän toteuttamisessa: Eclipse Visual Editor Project SWT Designer v Jigloo SWT/Swing GUI Builder for Eclipse and WebSphere Kehitystyökalut Versionhallinta Versionhallintaan ja ohjelmakoodin säilyttämiseen käytämme CVS-versionhallintajärjestelmää. Repositorio asennetaan TKK:lle ryhmän yhteiseen kansioon. Tähän kansioon on kaikilla ryhmäläisillä luku-, suoritus- ja kirjoitusoikeudet. Tiedostot haetaan ja tallennetaan Eclipsen kautta repositorioon. Uusia tiedostoja luotaessa ryhmäläisten on muistettava erikseen jakaa oikeudet koko ryhmälle näihin tiedostoihin. Vain toimivaa ohjelmakoodia saa laittaa repositorioon. CVS:stä ja sen käytöstä tehdään yksityiskohtainen ohjeet I1-iteraation alussa kirjoitettavassa erillisessä työkaluohjeessa. Projektiryhmää varten on luotu ATK-keskuksen UNIX-järjestelmään a-teamdc niminen ryhmä, johon kuuluvat kaikki projektiryhmän jäsenet. Ohjelmointi Java-kehitysympäristönä käytetään Eclipse 3.1:htä, Javasta versiota 5.0. Lisäksi käytetään jotakin yllämainituista Eclipsen lisäpalikoista käyttöliittymän toteuttamisessa. Luokkakaaviot 21
26 Borlandin Together Architect-työkalua käytetään luokkakaavioiden piirtämisessä ja ohjelmistoarkkitehtuurin suunnittelussa. Käännös Ohjelma käännetän suoraan Eclipsestä. Jos myöhemmin on tarkoituksenmukaista, otetaan myös ant - käännöstyökaluksi monimutkaisempiin asioita, kuten ohjelman paketointia varten. Vikaraportointi Vikaraportointiin käytetään Bugzilla-työkalua. Kommunikointi Ryhmän sisäiseen kommunikointiin käytetään Wiki-ympäristöä. Wikiin laitetaan asioita kuten dokumenttien uusia versioita muutoslogeineen, henkilökohtaiset aikataulut (matkat, tentit, menot) yms. Nopeaan yleiseen asioista tiedottamiseen käytetään sähköpostia. Asiakkaalle ja mentorille suunnattu tieto kootaan omiin osioihin Wikissä. Sähköpostin otsikoissa käytetään [] tagia tunnistamaan projektin sisäiset viestit. Projektiryhmällä on yhteistä palaveriaikaa tiistaisin klo Tämä jakautuu ensin tunnin manageripalaveriin, sitten kaikkien yhteiseen osioon ja lopuksi kehittäjien omaan osioon. Tuntiseuranta Tuntiseurantaan käytetään Excelillä tehtyä taulukkoa. Tarkemmat ohjeet tuntiseurannasta on kuvattu kohdassa tuntiraportointi. 5.4 Standardit Projektissa käytetään Sunin Java-ohjelmointikonventioita, joka on lyhyesti määritelty ryhmän työkalu-ohjeessa. Linkki koko dokumenttiin löytyy täältä: Käyttöliittymäsuunnittelussa pyritään noudattamaan Nielsenin kymmentä käytettävyysheuristiikkaa, jotka ovat: Simple and natural dialogue, Speak user s language, Minimize user memory load, Consistency, Feedback, Clearly marked exits, Shortcuts, Good error messages, Prevent errors ja Help and documentation. 5.5 SEPA -työt Osa projektiryhmän jäsenistä suorittaa projektin ohessa T Ohjelmistotuotannin erikoiskurssia, jossa perehdytään johonkin ohjelmistonkehityskäytäntöön ja sovelletaan sitä tähän ohjelmistoprojektiin. Aiheen voi 22
27 valita joko kurssin ehdottamista vaihtoehdoista tai omasta aiheesta, joka on kuitenkin hyväksytettävä mentorilla. Työ toteutetaan tekemällä ns. SEPA päiväkirja, jonka työmäärä on noin 20h/henkilö sekä tekemällä 20h/henkilö lisätyötä ohjelmistokehitysprojektiin. Projektiryhmän SEPA-työt tehdään työpareina ja oheisessa taulukossa 12 on listattu ryhmän SEPA aiheet. Aiheista ensimmäinen on ns. oma aihe, muut kaksi kurssin puolesta ehdotettuja aiheita. Aiheet on valittu niin, että niiden on katsottu olevan hyödyllisiä projektin kannalta. Seuraavissa luvuissa on lyhyt kuvaus valituista aiheista. Tarkemmat kuvaukset ja valintaperusteet kuvataan kunkin aiheen erillisessä dokumentissa, SEPA päiväkirjassa. Taulukko 12: SEPAt Käytäntö Vastuuhenkilö Vaiheet Coding Camp Käyttettävyystestit Kari Ylihärsilä Samuel Korpi Elina Kontro Vesa Haukkavaara I1 ja I2 I1 ja I2 Staatiset menetemät Santeri Saarinen I1 ja I Coding Camp Kyseessä on käytäntö, jossa vähintään kerran kussakin iteraatiossa järjestetään kokonainen etukäteen suunniteltu työpäivä, jolloin kaikki ryhmämme jäsenet tekevät töitä projektin eteen yhdessä, samassa paikassa ja samaan aikaan. Tutkimme eri näkökulmista keskitetyn työskentelytavan tuottavuutta verrattuna hajautettuun työhön, jossa useimmat ryhmän jäsenet tekevät asioita eri paikoissa eri aikaan. Hajautetun työn etuja ovat keskittyminen tehtävään sekä ajan tehokas käyttäminen siltä osin, kun tekijälle on oma tehtävä täysin selvä. Keskitetyn työn etuja taas ovat tehokas tiedon siirtyminen kokemusten kautta sekä parempi ongelmanratkaisu, kun kaikkien taitoja saadaan hyödynnettyä samaan aikaan. Tutkimme "Coding Camp" käytännön tuottavuutta ainakin seuraavista näkökulmista: Ryhmän tuottavuus työtunteihin nähden, tuotetun koodin / tuotosten laatu (virheettömyys), tiedon siirtyminen ryhmän sisällä sekä työskentelytapojen nautittavuus Käytettävyystestit Käytettävyystestien tavoitteena on testata ja parantaa kehitteillä olevan tuotteen käytettävyyttä. Tuotetta kehitettäesssä pyritään kiinnittämään erityistä huomiota tuotteen tulevien käyttäjien näkökulmaan. Koska tässä ohjelmistokehitysprojektissa tavoitteena on toteutetaan olemassa olevaan CoSCA-simulaattoriin helppokäyttöinen ja opittava käyttöliittymä, joka mahdollistaa simulaattorin hyödyntämisen mm. HKKK:ssa 23
28 opetuksen apuvälineenä, on luontevaa ottaa käytettävyystestit yhdeksi projektissa käytettäväksi menetelmäksi, jolla pyritään varmistamaan tämän tavoitteen saavuttaminen. Käyttäjäryhmä, johon testauksessa keskitytään ovat HKKK:n opiskeljat, joita käytettävyystestauksen osallistuu vähintään kolme henkilöä Staattiset menetelmät Staattisella analysoinnilla tarkoitetaan sellaista esim. lähdekoodin analysointia, jossa koodia ei ajeta. Koodikatselmointi on yksi staattinen ohjelmistonanalysointi menetelmä. Menetelmän avulla voidaan mitata, analysoida ja parantaa ohjelmiston suunnittelua sekä löytää virheitä. Työssä tullaan käyttämään jotakin staattista analysointimenetelmää mittaamaan ja parantamaan ohjelmiston laatua sekä vähentämään ohjelmistossa olevien virheiden määrää. 24
29 6 Vaiheistus Projekti on jaettu kolmeen iteraatioon. Seuraavissa kappaleissa kuvataan iteraatioiden päätavoitteet, tuotokset, tehtävät ja työmääräarviot. Lisäksi esitettään aikataulut ja tärkeimmät päivämäärät. Iteraatiot ja niiden aloitussekä lopetuspäivämäärät on asetettu kurssin puolesta. Kuvassa x. On kuvattu projektin vaiheet ja aikataulu ylätasolla. Tähdellä merkityt kuvastavat keskeisimpiä niistä tapahtumista, joissa asiakkaan osallistuminen on välttämätöntä. Kunkin vaiheen tarkempi aikataulutus kerrotaan ko. vaiheen kohdalla PP I Joululoma I Iteraatio demo Välidemo Kuva 3. Projektin vaiheet ja aikataulutus 25
30 6.1 Projektin suunnittelu (PP) Projektisuunnitteluiteraation tavoitteena on saattaa projektisuunnitelma riittävän kattavaksi, jotta siinä määriteltävät asiat edistävät seuraavan vaiheen käynnistymistä. Keskeisenä tavoitteena on ymmärtää asiakkaan tavoitteet sekä niiden prioriteetit tälle projektille ja siinä tuotettavalle sovellukselle. Tässä iteraatiossa tulee huolehtia siitä, että asiakas ymmärtää käytettävissämme olevan resurssien määrän sekä tämän merkityksen tavoitteisensa toteuttamismahdollisuuksiin. Käytännöntoimenpiteinä tässä iteraatiossa valitaan projektissa käytettävät menetelmät ja työkalut sekä tehdään tarvittavat käyttöönotto toimenpiteet. Vaikka kehittäjien pääasiallinen työ alkaa, kurssin ohjeiden mukaisesti, ensimmäisessä toteutusiteraatiossa, pyritään kehittäjiä valmentamaan, yhdessä management tiimin kanssa, projektiin jo tässä vaiheessa. PP-iteraation tuotokset ovat: Projektisuunnitelma Vaatimusmäärittelydokumentti Projektiryhmässä käytettävien työkalujen käyttö-ohje (ryhmän sisäiseen käyttöön) Ensimmäiset versiot SEPA päiväkirjoista Tarkemmin ko. dokumenttien vastuut ja aikataulutus on kohdassa Dokumentointi. PP-iteraatiossa tavoitteet pyritään saavuttamaan taulukossa 13 listatuilla tehtävillä. Samassa taulukossa on myös työmääräarviot kustakin tehtävästä. Työmäärä arvioita päivitetään tarvittaessa. Projektinsuunnittelu iteraation aikataulutus on taulukossa
31 Taulukko 13. PP-iteraation tehtävät, vastuut ja työmääräarviot Elina Laura Kari Aleksi Santeri Vesa Samuel Yhteensä 88,0 80,0 78,0 23,0 23,0 22,0 23,0 337,0 Projektinhallinta 49,0 28,0 30,0 5,0 5,0 5,0 5,0 127,0 Rekrytointi 2,0 1,0 1,0 4,0 Projektin status raportointi 5,0 5,0 Iteraatiodemo 1,0 1,0 1,0 3,0 Projektisuunnittelua 15,0 5,0 5,0 25,0 Projektisuunnitelman kirjoittaminen 10,0 7,0 5,0 22,0 Kick off palaverit 9,0 9,0 9,0 3,0 3,0 3,0 3,0 39,0 Viikkopalaverit 2,0 2,0 2,0 2,0 8,0 Asiakaspalaverit 2,0 2,0 2,0 6,0 Mentorpalaverit 3,0 3,0 3,0 9,0 Projektiryhmän kommunikointi 2,0 4,0 6,0 Ohjelmistonsuunnittelu 11,0 34,0 9,0 4,0 0,0 3,0 3,0 64,0 Käyttäjätutkimus 2,0 2,0 Vaatimustenselvittäminen 1,0 12,0 0,0 13,0 Vaatimusmäärittelydokumentti 12,0 1,0 13,0 Käyttöliittymä proto 10,0 8,0 4,0 22,0 Arkkitehtuurisuunnittelu 8,0 3,0 3,0 14,0 Laadunvarmistus 10,0 1,0 6,0 0,0 3,0 0,0 0,0 20,0 Laatusuunnitelma 6,0 1,0 3,0 10,0 Laatusuunniteman dokumentointi 2,0 1,0 3,0 Testassuunnitelma 2,0 2,0 Dokumenttikatselmoinnit 2,0 1,0 2,0 5,0 Työkalujen käyttöönotto ja ohjeistu 4,0 4,0 15,0 1,0 2,0 1,0 2,0 29,0 Projektihallinnan työkalut 2,0 1,0 3,0 Kehitystyökalujen valinta 3,0 3,0 Työkalujen käyttöönotto 1,0 4,0 5,0 1,0 2,0 1,0 2,0 16,0 Ohjeistus 1,0 6,0 7,0 Opiskelu 12,0 13,0 16,0 13,0 13,0 13,0 13,0 93,0 Luennot 6,0 6,0 9,0 9,0 9,0 9,0 9,0 57,0 Aihealueeseen perehtyminen 4,0 5,0 5,0 2,0 2,0 2,0 2,0 22,0 Simulaattoriin perehtyminen 2,0 2,0 2,0 2,0 2,0 2,0 2,0 14,0 Muu dokumenointi 2,0 0,0 2,0 0,0 0,0 0,0 0,0 4,0 SEPA päiväkirjat 2,0 2,0 4,0 Taulukko 14. PP-iteraation aikataulutus PP Iteraatio Vko Kehittäjien rekrytointi alkaa Vko Management ryhmän kick-off palaveri Projektiryhmä kasassa, rekrytointi päättyy, ryhmän ilmoittautuminen Projektin käynnistyspalaveri asiakkaan kanssa Vko PP-iteraatiosuunnitelman palautus Vaatimustenmäärittel alkaa 27
0.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ätiedotProjektisuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
Projektisuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 27.9.2005 Elina Kontro Ensimmäinen mallipohjaan täytetty versio, englanninkielinen 0.2 5.10.2005
LisätiedotProjektisuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
Projektisuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 27.9.2005 Elina Kontro Ensimmäinen mallipohjaan täytetty versio, englanninkielinen 0.2 5.10.2005
LisätiedotI1 Iteraatiosuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
I1 Iteraatiosuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Sisällysluettelo 1 Johdanto 2 1.1 Tavoitteet 3 1.2 Tuotokset 4 1.3 Tehtävät ja työmääräarviot 6 1.4 Vaiheistus ja aikataulutus 9
LisätiedotI2 -Iteraatiosuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
I2 -Iteraatiosuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Sisällysluettelo 1 Johdanto 2 1.1 Tavoitteet 3 1.2 Tuotokset 4 1.3 Tehtävät ja työmääräarviot 6 1.4 Vaiheistus ja aikataulutus 8
LisätiedotT Iteraatio Demo TeamDC I1 - Iteraatio
T-76.4115 Iteraatio Demo TeamDC I1 - Iteraatio 7.12.2005 Agenda I1 Iteraatio demo 7.12.2005 T-76.4115 76.4115 Iteration demo Projektin tilannekatsaus (10 min) Projektin esittely tarvittaessa Yleiskuva
LisätiedotT Projektisuunnitelma
T-76.115 Projektisuunnitelma Team Tubeless Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 3.10.2005 Kekkonen Ensimmäinen mallipohjaan täytetty versio 0.2 11.10.2005 Kekkonen Projektisuunnitelman täydennystä
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ätiedotT Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2)
T-76.4110 Ohjelmistoprojekti I 25.2.2006 T-76.4115 Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2) Versio Päiväys Muokkaaja Kuvaus 2.0 25.2.2006 Markus Kattilamäki Päivämäärien tarkennus, viimeistely
LisätiedotT 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ä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ä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ä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ä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ä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ätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
LisätiedotT Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005
T-121.110 Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005 Kurssin tavoitteet Muodostaa näkemys käyttäjäkeskeisestä tuotesuunnittelusta Kasvattaa ymmärrystä prosessin vaiheista Tutustua käyttäjäkeskeisen
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ä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ätiedotProjektin suunnittelu
Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten
LisätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(6) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja (projektisuunnitelman
LisätiedotTietotekniikan Sovellusprojektit
Tietotekniikan Sovellusprojektit Jukka-Pekka Santanen Tietotekniikan laitos 16.2.2010 Tavoitteena taitoja ja kokemusta projektimuotoisesta työtavasta ja ryhmätyöstä, projektin hallinnasta ja johtamisesta,
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ä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ätiedotS11-09 Control System for an. Autonomous Household Robot Platform
S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on
Lisä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ätiedot22.10.2006 PROJEKTISUUNNITELMA
PROJEKTISUUNNITELMA PROJEKTISUUNNITELMA 2 (30) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 22.9.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 22.9.2006 Aleksi Airola Lisäyksiä riskilogiin ja resursseihin
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ätiedotWCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma
TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,
LisätiedotProjektisuunnitelma. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Projektisuunnitelma Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 1.0 19.10.2007 Johannes Suanto Esitetty Iteraatiodemossa,
LisätiedotProjektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
Lisä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ä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ätiedotLoppuraportti. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
Loppuraportti CoSCA-simulaattorin jatkokehitysprojekti TeamDC Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 4.1.2006 Elina Kontro Raportin runko 0.2 30.1.2006 Elina Kontro Runkoa täydennetty, johdantoon
LisätiedotHarjoitustyö Case - HelpDesk
Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.
LisätiedotProjektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena
LisätiedotIIZT4020 Projektitoiminta
IIZT4020 Projektitoiminta Jouni Huotari S2010 http://student.labranet.jamk.fi/~huojo/opetus/iizt4020/ Tutustumiskierros Kuka minä olen miksi minä opetan projektitoimintaa Keitä te olette mitä te haluatte
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ätiedotRyhmä (11) Numeropankki
Tampereen teknillinen yliopisto Tietotekniikan laitos TIE-13100 Tietotekniikan projektityö Ryhmä (11) Numeropankki Projektisuunnitelma Tommi Blomster Jari Laaksonen Petri Tahvanainen Eemil Väisänen (vastaa
LisätiedotVastuu- ja tehtäväalueet sekä tiedonvälitys OSCu-kursseilla
Vastuu- ja tehtäväalueet sekä tiedonvälitys OSCu-kursseilla Johdanto... 2 1. Opetushenkilökunnan tehtävät... 2 1.1. Kurssin vastuuopettaja... 2 1.2. Kurssimestarit ja assistentit... 3 1.2.1. Vastuuyliopiston
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ätiedotProjektin suunnittelu. Pienryhmäopetus - 71A00300
Projektin suunnittelu Pienryhmäopetus - 71A00300 Projektikanvaasi Mikä on projektikanvaasi? Visuaalinen työkalu projektitiimille, joka helpottaa projektin suunnittelussa ja projektin tavoitteiden kommunikaatiossa
LisätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
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ätiedotOpetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen
Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen Toiminnallinen määrittely: Työsuunnitelma TYÖSUUNNITELMAN TIEDOT Versio 0.1 Laatija Ulla Angervo Laatimispäivämäärä Hyväksyjä Hyväksymispäivämäärä
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ätiedotMatematiikan oppifoorumi Projektisuunnitelma
Matematiikan oppifoorumi Projektisuunnitelma Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen Ohjaaja Jukka Eskola Asiakas Mikko Mäkelä Ohjelmistotuotantoprojekti 29.10.1999
Lisätiedotpikaperusteet 3.3. versio
pikaperusteet 3.3. versio IT-palvelut / Hannele Rajaniemi www.jyu.fi/itp/moodle-ohjeet moodle-support@jyu.fi materiaalin koonnut: Hannele Rajaniemi Alustava sisältö Rakennat omaa Moodle kurssiasi, jossa
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ätiedotCOTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria...........................................................................
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ätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
LisätiedotOhjelmistojen mallintaminen, kurssikoe esimerkkivastauksia
Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.
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ä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ätiedotIT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS
20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien
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ätiedotOhjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
LisätiedotValtioneuvoston kanslia VAIN VIRKAKÄYTTÖÖN Hallinto- ja palveluosasto/hallintoyksikkö Terja Ketola PTJ2008-työsuunnitelma 1 (5)
Terja Ketola PTJ2008-työsuunnitelma 1 (5) AIKATAULU JA TEHTÄVÄT / PTJ2008 VALMIS MENOSSA MYÖHÄSSÄ ALOITTAMATTA ALUSTAVA AJANKOHTA EI PIDETTY / TEHTY 1 Määrittelyn läpikäynti PTi, TKe, IHa, TRö 34 23.8.2007
LisätiedotSuvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014
Tietokanta Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia ja linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat
LisätiedotTIETOJENKÄSITTELYTIETEIDEN LAITOS
TIETOJENKÄSITTELYTIETEIDEN LAITOS PROJEKTITOIMINNAN PERUSTEET TENTTI 28.4.2001 Tonja Molin-Juustila Kustakin tehtävästä max 6 pistettä. Vastaukset arvostellaan 0,5 pisteen tarkkuudella. Oikeat vastaukset
LisätiedotOheisessa liitteessä on määritelty lyhyesti, millaiset kehittämistoimet hankerekisteriin laitetaan, ja mitä rekisterikenttiin on tarkoitus kirjata.
09.12.2015 1 (5) n käyttöönotto Satakunnan sairaanhoitopiirissä Satakunnan sairaanhoitopiirissä tehdään paljon hyvää kehittämistyötä eri vastuualueilla ja yksiköissä. Laajan kehittämistyön näkyväksi tekemisen
LisätiedotProjektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena on luoda valmis sekvenssiohjelma säätötekniikan
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)
581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun
LisätiedotAS Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma Syksy 2009 A09 05 OSGi IRC Bot For Coffee Maker
AS 0.3200 Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma Syksy 2009 A09 05 OSGi IRC Bot For Coffee Maker Henri Nieminen Juha Sironen Palautettu: 21.9.2009 Nieminen, Sironen Sisällysluettelo
LisätiedotKanTa. ereseptin käyttöönoton valtakunnallinen
OHJE KanTa ereseptin käyttöönoton valtakunnallinen seurantaohje OHJE: Tämä Ohjeistuksen nimi on KanTa ereseptin käyttöönoton valtakunnallinen seurantaohje. Sen sitovuusaste on ohje, jonka Kässärin ylläpitoryhmä
LisätiedotDigi-tv vastaanottimella toteutetut interaktiiviset sovellukset
Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,
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ä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ätiedotFile [Otsikko] 2014-02-26 40212. Projektisuunnitelma. SPT2014 Selvitysprojekti projektihallinnan työkaluista
apj2014 Projektisuunnitelma 1 (6) Projektisuunnitelma SPT2014 Selvitysprojekti projektihallinnan työkaluista Versio 1.0 Muutoshistoria umero Pvm Selitys Tekijä(t) 0.1 12.2.2014 Projektisuunnitelmaluonnos
LisätiedotENG-A1002 ARTS-ENG-Projekti. B-kori
ENG-A1002 ARTS-ENG-Projekti B-kori 11.4.2017 Innovatiivinen kuljetin B-korissa pyritään löytämään: uusi tai paranneltu tuotekonsepti kappaletavaroiden tai materiaalien käsittelyyn, siirtelyyn tai kuljetukseen.
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
LisätiedotJHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja
JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä
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ä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ä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ä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ätiedotSOVELLUSALUEEN KUVAUS
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu SOVELLUSALUEEN KUVAUS LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 12.12.2000
LisätiedotKieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä
Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Omistaja Tyyppi Tiedoston nimi Turvaluokitus Kohderyhmä Turvaluokituskäytäntö --- SE/Pekka Järveläinen Projektisuunnitelma projektisuunnitelma_kielihallinto.doc
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ätiedotProjektin suunnittelu A71A00300
Projektin suunnittelu A71A00300 Projektisuunnitelma 1. Projektitiimi 2. Projektin tausta 3. Projektin tavoitteet 4. Tiimin roolit 5. Sisäinen viestintä 6. Riskianalyysi 7. Aikataulutus Projektisuunnitelman
LisätiedotProjektisuunnitelma. Projektin tavoitteet
Projektisuunnitelma Projektin tavoitteet Projektin tarkoituksena on tunnistaa erilaisia esineitä Kinect-kameran avulla. Kinect-kamera on kytkettynä tietokoneeseen, johon projektissa tehdään tunnistuksen
LisätiedotMäärittely- ja suunnittelumenetelmät
Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka
LisätiedotProjektin suunnittelu A71A00300
Projektin suunnittelu A71A00300 PESTLE-malli Poliittinen - mitä poliittisia riskejä projektiin voi liittyä? (verotus, hallinto ) Ekonominen - mitä taloudellisia riskejä projektiin liittyy? (työvoiman saatavuus,
LisätiedotAS Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma
AS-0.3200 Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma PiccSIM - TrueTime integrointi Henri Öhman 31.1.2012 1. Projektityön tavoite PiccSIM on Aalto-yliopistolla kehitetty simulointiympäristö,
LisätiedotHeuristisen arvioinnin muistilista - lyhyt versio
Alla oleva kymmenkohtainen muistilista on sovellettu Jakob Nielsenin heuristisen arvioinnin muistilistasta (Nielsen, 1994), hyödyntäen Keith Instonen wwwpalveluiden arviointiin muokattua samaista listaa
LisätiedotCS-C2130 / CS-C2140 / CS-E4910 Software Project 1 / 2 / 3 ja Accenture Luento
CS-C2130 / CS-C2140 / CS-E4910 Software Project 1 / 2 / 3 ja Accenture 2016-2017 Luento 14.9.2016 Accenture yleisesti Maailmanlaajuisesti: henkilömäärä: ~ 375 000 toimistoja yli 200 kaupungissa, 120 maassa
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ätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Versionhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(7) Muutoshistoria Version Date Author Description 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja 0.20 19.10.2003
LisätiedotPROJEKTIN DOKUMENTOINTI JOUNI HUOTARI
PROJEKTIN DOKUMENTOINTI JOUNI HUOTARI 9.9.2009 MIKSI DOKUMENTOINTI ON TÄRKEÄÄ? Muistetaan, mitä on sovittu Muut voivat helpommin kommentoida esim. projektisuunnitelmaa Helpottaa uusien henkilöiden mukaantulemista
Lisätiedotehops Henkilökohtainen opintosuunnitelma
ehops Henkilökohtainen opintosuunnitelma Hopsin tekeminen WebOodin ehops-toiminnolla KTK-tutkinto Mikä on ehops? ehops on WebOodin toiminto, jolla voit laatia sähköisen henkilökohtaisen opintosuunnitelman
LisätiedotLaatukäsikirja - mikä se on ja miten sellainen laaditaan?
Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka
LisätiedotInternet-pohjaisen oppimisympäristön laadinta
Internet-pohjaisen oppimisympäristön laadinta Kevät 2013 5op joni.karvinen@uta.fi jari.laitinen@uta.fi IPOPPLA 2013 Järjestetty viimeksi keväällä 2011 Kurssin kotisivut: http://www.uta.fi/sis/tie/ipoppla/index.html
LisätiedotTIEA4 Projektityö, 5-10 op.,
TIEA4 Projektityö, 5-10 op., 2012-13 Luennot Kurssin esitietovaatimukset ja tavoitteet Kurssin sisällöstä Suoritustavoista ja -vaatimuksista, arvostelu Yleisiä ohjeita Kurssin luennoitsija ja projektien
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ätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
Lisä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ätiedotKurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan?
Kurssin sisältö Johdatus ohjelmistotekniikkaan 2 0 0 8 Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Mitä työkaluja ohjelmistoja kehitettäessä käytetään ja miten? Historiaa
Lisätiedot