Loppuraportti Kuopio

Koko: px
Aloita esitys sivulta:

Download "Loppuraportti Kuopio"

Transkriptio

1 Loppuraportti Kuopio

2 Kuopio, Loppuraportti, Versiohistoria: Versio Pvm Laatija Muutokset Ossi Jokinen Valmis katselmoitu versio palautukseen. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 2

3 SISÄLLYSLUETTELO 1. PROJEKTIN TAVOITTEET PROJEKTIN ETENEMINEN PS-VAIHE T1-VAIHE T2-VAIHE T3-VAIHE LU-VAIHE LOPPUTULOKSET MITÄ TEHTÄISIIN TOISIN? TAVOITTEIDEN TOTEUTUMINEN JATKOKEHITYSNÄKYMÄT TYÖMENETELMÄT JA TYÖKALUT TUNTIRAPORTOINTI RISKIENHALLINTA VAATIMUSMUUTOSTEN HALLINTA VERSIONHALLINTA CVS 1.11 OHJELMISTON AVULLA MONIKERROSARKKITEHTUURI RASITUSTESTAUS KOODIKATSELMOINNIT JÄLKILASKELMAT TYÖMÄÄRÄ AIKATAULUT OHJELMISTOVIRHEET OHJELMISTON KOKO OPPIMINEN KURSSIPALAUTE...25 Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 3

4 TAULUKOT: Taulukko 1 Työmäärä henkilöittäin projektissa Taulukko 2 Työn jakautuminen työtyypeittäin KUVAT: Kuva 1 Virheraportit osakokonaisuuksittain suhteutettuna niiden kokoon Kuva 2 Virheiden luokittelu vakavuusasteittain osakokonaisuuksissa Kuva 3 Virheraporttien tila Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 4

5 1. PROJEKTIN TAVOITTEET Projektin tavoitteet muodostettiin projektiryhmän ja asiakkaan tavoitteiden pohjalta. Projektiryhmän tavoitteiksi projektisuunnitelmaan kirjattiin. 1) Ohjelmistotuotantoprosessin ja ohjelmistotuotannon menetelmien ymmärryksen kasvattaminen. 2) Mahdollisimman suuren asiakastyytyväisyyden tuottavan tuotteen tekeminen ennalta kiinnitetyllä aikataululla ja työmäärällä. Tämän mahdollistamiseksi ryhmä priorisoi asiakkaan kanssa vaatimukset ja toteuttaa niitä niin paljon kuin kiinnitetyllä työmäärällä ja aikataululla kykenee. Näin varmistetaan resurssien kohdentaminen asiakkaan kannalta optimaalisiin kohteisiin. 3) Kurssin laajuuden ja aikataulun puitteissa pysyminen. Kiinnitetään työmäärät ja aikataulu. Ei ylimääräistä työtä. 4) Kurssin suorittaminen erinomaisella arvosanalla. Asiakkaan tavoitteet priorisoitiin niiden hallitsemiseksi, sillä perinteisesti asiakas haluaa aina huippuhyvän järjestelmän huippunopeasti ja huippuhalvalla. Asiakkaan tavoitteiksi projektisuunnitelmaan kirjattiin. 1) Kolmen projektissa tuotettavan osakokonaisuuden (henkilöt, asiakkaat ja projektit) valmiiksi saattaminen. 2) Valmiiden olemassa olevien moduulien liittäminen / liittämismahdollisuuden varmistaminen 3) Suunnittelussa otetaan huomioon myös sellaiset toiminnallisuudet, joita ei tämän projektin aikana liitetä järjestelmään (esimerkiksi sopimukset -osakokonaisuus ja tietämysalueet -osakokonaisuus). 4) Kaikki nykyiset tiedot siirretään uuteen intraan oikein. 5) Modulaarisuus, kolmikerrosmalli, projektissa tuotettuja moduuleja voidaan hyödyntää asiakkaan tulevissa projekteissa sekä tuotekehityksessä. 6) Ohjelmistotuotantoprosessin, laatujärjestelmän dokumentaation, työtapojen ja menetelmien kehittäminen. 7) Aikataulussa pysyminen. 8) Käytettävyys. 9) Järjestelmän toteutuksessa käytetään Innofactorin olemassa olevaa Intrakäyttöliittymää. 10) Kehitetään mahdollisuuksien mukaan jo olemassa olevia moduuleja. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 5

6 Projektin tavoitteet muodostettiin yhteenvetona kahden edellisen kappaleen tavoitteista. Projektin tavoitteeksi määritettiin niin asiakkaan kuin projektiryhmän tavoitteiden mahdollisimman hyvä huomiointi. Tähän todettiin päästävän hoitamalla projekti mahdollisimman hyvin kurssin vaatimusten mukaan. Projektisuunnitelmaan kirjattiin: "Projektin tavoite onkin projektin toteuttaminen suunnitellun laajuisena suunnitellussa aikataulussa siihen kiinnitetyillä resursseilla käyttäen kurssin puolesta määritettyjä ohjelmistotuotannon menetelmiä." 2. PROJEKTIN ETENEMINEN Projekti päätettiin toteuttaa iteratiivisesti ja inkrementaalisesti kurssin vaatimusten mukaisen USDP-ohjelmistoprosessimallin mukaan. Toteutukselle oli kiinnitetty jo kurssin puolesta viisi vaihetta, joiden aikataulut oli määritetty jo valmiiksi. 2.1 PS-vaihe Projektin suunnitteluvaiheen tarkoituksena oli suunnitella projekti. Projektin suunnitteluun liittyy organisointi, tavoitteiden tarkentaminen, riskien analysointi, käytettävien teknologioiden ja työmenetelmien valinta, tukitoimintojen (dokumentointi, tuotteenhallinta, laadunvarmistus) suunnittelu, sekä projektin osittaminen ja osien aikatauluttaminen. Kaikki em. tehtävät myös saatiin tehtyä ja dokumentoitua. Projekti tosin käynnistyi hieman nihkeästi PS-vaiheen tuntien kertyessä lähinnä vaiheen puolivälin ja lopun välillä. Tämä ei aiheuttanut ongelmia, sillä projektin suunnitteluvaiheen työ kohdistui lähinnä projekti- ja laatupäällikölle sekä asiakasvastaavalle. Vaiheen jälkeen projektin roolit ja vastuut oli päätetty, projektin vaatimusmäärittely tehty, projektin riskienhallinta käynnistetty, käytettävät teknologiat ja osa työmenetelmistä valittu, tukitoiminnot suunniteltu projektin laatukäsikirjan muodossa ja projekti ositettu sekä aikataulutettu. Kaikki tämä oli dokumentoitu seuraaviin dokumentteihin. Projektisuunnitelma MS Project muotoinen projektisuunnitelma Vaatimusmäärittely Laatukäsikirja Tässä vaiheessa projekti ei ajautunut ongelmiin. Kaikki suunniteltu saatiin tehtyä ja vieläpä ali budjetin. Vaiheeseen kului tunteja 238 sille budjetoidusta 280 tunnista. Tarkempaa tietoa voi tarkistella PS-vaiheen edistymisraportista. 2.2 T1-vaihe Toteutus oli suunniteltu jaettavaksi kolmeen vaiheeseen, joiden jokaisen sisällä tehdään iteraatio. Iteraatiossa järjestelmän toteutettavat osat (inkrementit) määritellään (vaatimusmäärittely ja toiminnallinen määrittely), suunnitellaan (tekninen määrittely), Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 6

7 koodataan ja testataan. Toteutus oli siis suunniteltu tehtäväksi iteratiivisesti ja inkrementaalisesti siten, että kokonaisuus aluksi hahmotellaan korkeammalla abstraktiotasolla, luodaan järjestelmän baseline arkkitehtuuri, ja sen jälkeen ryhdytään tekemään suunniteltuja inkrementtejä. T1-vaihe alkoi määrittelyllä. Määrittelyssä oli tarkoitus selvittää ja kuvata toteutettavaan järjestelmään liittyvät toiminnot, tiedot ja niiden väliset riippuvuudet. Nämä kirjattiin toiminnalliseen määrittelyyn tarkentaen vaatimusmäärittelyn vaatimuksia järjestelmän toiminnoiksi. Määrittelyn jälkeen tehtiin järjestelmän suunnittelu korkealta abstraktiotasolta lähtien arkkitehtuurisuunnittelun kautta Henkilöt -osakonaisuuteen, dokumentoiden ne tekniseen suunnitelmaan. Suunnittelun jälkeen voitiinkin ryhtyä tekemään järjestelmän runkoa ja sille ensimmäiseksi asetettavaa Henkilöt -osakokonaisuus inkrementtiä. Samalla testausvastaava oli jo saanut testaussuunnitelman valmiiksi. Lisäksi alustava käyttöliittymäsuunnittelu saatiin tehtyä. Projektipäällikkö oli puolestaan päivittänyt projektisuunnitelmat ja laatukäsikirjan jo vaiheen alkupuolella. Demo saatiin Henkilöt -osakokonaisuuden osalta valmiiksi projektikatselmukseen. Valitettavasti sitä ei ehditty testata testaussuunnitelman mukaisesti ja sille tehtiin pienimuotoinen adhoc-testaus. Projekti saavutti siis vaiheelle asetetut tavoitteet Henkilöt -osakokonaisuuden testausta lukuun ottamatta. Osakokonaisuudelle olisi tarvinnut suunnitella testitapaukset, ajaa ne, korjata mahdolliset virheet ja tehdä regressiotestaus. Kaikki tuo olisi vaatinut arviolta noin 30 tunnin lisätyön. Budjetissa olisi ollut sille varaa helposti sillä budjetoidusta 300 tunnista käytettiin vain 241 tuntia. Ongelmana oli saada projektihenkilöstöltä myös ne budjetoidut tunnit. Niitä ei saatu käyttöön kuten oli suunniteltu ja Henkilöt -osakokonaisuuden valmistuminen viivästyi niin myöhäiseksi, että testausta ei ehditty tekemään ennen katselmusta. Henkilöt - osakokonaisuuden testaus päätettiinkin siirtää seuraavan vaiheen alkuun. Tarkempaa tietoa aiheesta löytyy T1-vaiheen edistymisraportista. Projektihenkilöstöllä oli siis havaittavissa tämän projektin lisäksi myös muita projekteja joita he saattoivat priorisoida yli tämän projektin. Tämä ongelma tiedostettiin ja keinoja sen ehkäisemiseksi tulevassa vaiheessa pohdittiin yhdessä asiakkaan kanssa. Mitään muuta asian eteen ei kuitenkaan pystytty tekemään kuin päätös seurata henkilöjen muita kiireitä tarkemmin ja siten pyrkiä ennakoimaan mahdollista priorisointia tämän projektin suhteen. Sillä eihän ketään voida pakottaa tällaiseen projektiin, ja kaikki olivat mukana vapaaehtoisesti - toisilla oli enemmän muita kiireitä kuin toisilla. Suhtautuminen kouluun oli jäsenten keskuudessa myös erilaista - toiset panostivat huomattavasti enemmän - toisille riittäisi vähempikin. Olisi siis selvää, että tämä ongelma kulkisi mukana läpi projektin. Asian tiedostaminen, tilanteen seuraaminen, huomioon ottaminen ja ennakointi sekä henkilöstön motivointi muodostuivat tekijöiksi joilla tätä ongelmaa pyrittäisiin hallitsemaan ja sen vaikutukset minimoimaan. 2.3 T2-vaihe T2-vaiheessa järjestelmään oli tarkoitus tehdä Asiakkaat -osakokonaisuus inkrementti. Ennen sitä täytyi kuitenkin tehdä edellisen vaiheen testaus, joka ei sinänsä aiheuttanut aikataulullisia ongelmia, koska testaus voitiin tehdä yhtä aikaa Asiakkaat - osakokonaisuuden suunnittelun kanssa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 7

8 Henkilöt -osakokonaisuudelle suunniteltiin testitapaukset, ajettiin ne, korjattiin löydetyt virheet ja tehtiin regressiotestaus. Tämä sujui ongelmitta aikataulun ja budjetin mukaan. Tehty testaustyö dokumentoitiin testauksen vaatimiin standardidokumentteihin. Testitapausluettelo Henkilöt osakokonaisuus Testiloki Henkilöt osakokonaisuus Testiraportti Henkilöt osakokonaisuus Asiakkaat -osakokonaisuuden suunnittelutyö aloitettiin tarkentamalla toiminnallista määrittelyä. Sitten tarkennettiin teknistä määrittelyä, koodattiin ja testattiin. Kaikki sujui muuten oikein hyvin, mutta aivan kaikkea testausta ei taaskaan saatu tehtyä ennen katselmointia ja osakokonaisuuden demoamista. Tällä kertaa Asiakkaat - osakokonaisuuden testitapaukset kuitenkin saatiin suunniteltua ja testattuakin lukuun ottamatta matalimman prioriteetin testitapauksia. Matalimman prioriteetin testitapausten ajo, niistä mahdollisesti löytyvien virheiden korjaus ja lopullinen regressiotestaus jäivät siis seuraavan vaiheen alkuun. Vaiheeseen oli budjetoitu tunteja 320 joista käytettiin 298. Tekemättä jäänyt testausosuus olisi vaatinut arviolta 10 tuntia työtä, joten budjetoitujen resurssien ylitarve ei taaskaan ollut ongelma, vaan jo edellisessä vaiheessa havaittu resurssien saatavuusongelma. Ongelmaa oli saatu kuitenkin käsiteltyä edellisessä vaiheessa päätettyjen toimenpiteiden avulla siten, projekti oli varsin hyvin hallinnassa ja edellisen vaiheen myöhästymistä oli tässä vaiheessa saatu kiinni - ongelman kanssa oli siis totuttu elämään. Toiseksi ongelmaksi voisi todeta budjetoitujen tuntien mahdollisesti liian suuren alittamisen (ainakin mentorin mielestä). T1-vaiheeseen projektipäällikkö laittoi kaikkiin suunniteltuihin tehtäviin sisään 20% varauksen (Contingency), sillä projektin alkuvaiheessa suunniteltujen tehtävien kestojen todellisesta toteutumisesta ei ollut vielä suurimman projektiryhmän osan osalta mitään kokemusta. Suurta varausta ei kuitenkaan jouduttu käyttämään ja työt saatiin tehtyä alittamalla arviot reilusti. T2- vaiheeseen mentäessä varausta voitiin siis pienentää, ja vaiheen tehtäviin ladattiinkin normaalimpi 10% varaus. Tämäkin osoittautui sopivaksi ja vaiheen tehtävät saatiin tehtyä käyttämällä osa varauksesta. 10% varaus katsottiin sopivaksi eikä sitä lähdetty enää T3-vaiheeseen alentamaan. Kolmessa vaiheessa saavutetut budjettisäästöt arvioitiin ja projektin kokonaisbudjettiarviota uskallettiin tiputtaa 1400 tunnista 1250 tuntiin vaarantamatta seuraavien vaiheiden onnistumista. Tarkempaa tietoa aiheesta löytyy T2-vaiheen edistymisraportista. Koska budjetissa tuntui olevan hieman löysää, päätettiin asiakkaan kanssa, että myös Kalenterimoduuli tultaisiin integroimaan järjestelmään tämän projektin puitteissa yli projektin alkuperäisten suunnitelmien. 2.4 T3-vaihe T3-vaiheessa järjestelmään oli tarkoitus tehdä Projektit -osakokonaisuus inkrementti sekä Kalenterimoduulin integrointi. Ennen sitä täytyi kuitenkin tehdä edellisen vaiheen Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 8

9 kesken jäänyt testaus loppuun, joka ei sinänsä aiheuttanut aikataulullisia ongelmia, koska testaus voitiin tehdä yhtä aikaa Projektit -osakokonaisuuden suunnittelun kanssa. Asiakkaat -osakokonaisuuden matalimman prioriteetin testitapausten ajo, niistä löytyneiden virheiden korjaus ja lopullinen regressiotestaus saatiin tehtyä ongelmitta suunnitelmien mukaan. Projektit -osakokonaisuuden suunnittelutyö aloitettiin tarkentamalla toiminnallista määrittelyä. Sitten tarkennettiin teknistä määrittelyä, koodattiin ja testattiin. Lisäksi Kalenterimoduulia muokattiin ja se integroitiin järjestelmään. Kaikki sujui muuten oikein hyvin, mutta aivan kaikkea testausta ei taaskaan saatu tehtyä ennen katselmointia ja osakokonaisuuden demoamista. Tällä kertaa Projektit - osakokonaisuuden testitapaukset saatiin suunniteltua sekä testattua lukuun ottamatta matalimman prioriteetin testitapauksia. Lisäksi Kalenterimoduulin tarkempi integraatiotestaus jäi tekemättä (vain adhoc-testaus saatiin tehtyä ennen katselmusta). Projektit -osakokonaisuuden matalimman prioriteetin testitapausten suunnittelu, ajo, niistä mahdollisesti löytyvien virheiden korjaus, lopullinen regressiotestaus ja Kalenterimoduulin integraatiotestaus jäivät siis seuraavan vaiheen alkuun. Vaiheeseen oli budjetoitu tunteja 315 joista käytettiin 275. Tekemättä jäänyt testausosuus olisi vaatinut arviolta 40 tuntia työtä, joten budjetoitujen resurssien ylitarve ei taaskaan ollut ongelma, vaan jo edellisessä vaiheessa havaittu resurssien saatavuusongelma. Ongelmaa oli käsitelty aikaisemmin päätettyjen toimenpiteiden avulla siten, projekti oli edelleen hyvin hallinnassa. 10% varaus tuli tällä kertaa tarpeeseen, sillä tehtäviin budjetoidut tunnit myös käytettiin. 2.5 LU-vaihe LU-vaiheessa oli tarkoituksena tehdä ensin edellisessä vaiheessa tekemättä jäänyt testaus kuntoon. Testausvastaava hoiti tämän kuntoon erittäin mallikkaasti pääsiäislomalla, jolloin projekti ei muuten edennyt mihinkään. LU-vaihe oli alunperin suunniteltu aloitettavaksi pääsiäisen jälkeen, joten vaiheen alkuperäisiin tehtäviin voitiin ryhtyä alkuperäisessä aikataulussa heti loman jälkeen. Luovutusvaiheen tehtävänä oli viimeistellä toteutettava järjestelmä sellaiseen kuntoon, että se voidaan luovuttaa asiakkaalle sekä projektin päättäminen. Tähän sisältyi muun muassa avoimien virheiden korjaus tai dokumentointi, rasitustestaus, hyväksymistestaus, opponenttitestaus, dokumentaation viimeistely, loppuraportti ja loppudemonstraation valmistelu ja pitäminen. Kaikki sujui oikein hyvin ja kaikki em. tehtävät saatiin tehtyä ongelmitta. Vaiheeseen oli budjetoitu 240 tuntia joista käytettiin 197. Alitus oli siis reilu, mutta ei mikään yllätys, sillä näin lyhyessä vaiheessa olisi vaikea kuvitella ylittävänsä 200 tuntia. Koska resursseja oli niin niitä myös budjetoitiin vaiheen tehtäville reilusti. Suurempi tuntimäärä toimii myös eräänlaisena motivaattorina aloittaa tehtävä riittävän varhain. Nyt onnistuttiinkin ottamaan läpi projektin vaivannut lievä testauksen myöhästely kiinni. Näin pitikin, sillä muuten projekti olisi myöhästynyt (mikä on tämän kaltaiselle kouluprojektille hyvin hankalaa). Projektin riskit saatiin siis tämän vaiheen osalta hallittua ja projekti saatiin päätettyä onnistuneesti. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 9

10 3. LOPPUTULOKSET Projektissa piti suunnitella koko tulevan järjestelmän arkkitehtuuri korkealla tasolla sekä tuottaa järjestelmä Henkilöt-, Asiakkaat- ja Projektit -osakokonaisuuden osalta valmiiksi. Näin myös tehtiin. Lisäksi järjestelmään liitettiin asiakkaalta saatu Kalenterimoduuli. Kalenterimoduuli ei suinkaan ollut suoraan liitettävissä vaan sitä jouduttiin muokkaamaan. Lisäksi liittämiseen liittyi olennaisena osana integrointitestaus. Kalenterimoduuli päätettiin ottaa mukaan projektiin T2-vaiheen alussa yhdessä asiakkaan kanssa kun näytti siltä, että myös siitä selvittäisiin projektin puitteissa. Näin myös kävi. Teknisessä mielessä projekti tuotti kaiken suunnitellun ja enemmän. Toteutuksessa ei jouduttu ongelmiin ja työn onnistumisen aste projektiryhmän mielestä on erittäin korkea. 3.1 Mitä tehtäisiin toisin? Projektilla oli oikeastaan vain yksi suurempi ongelma (budjetoitujen resurssien todellinen saatavuus, esitelty edellisessä kappaleessa) joka kulki mukana läpi projektin. Tämä ongelma hallittiin mallikkaasti eikä sen annettu vaikuttaa projekti lopputuloksiin. Ongelma syntyi samalla kun projektiryhmä muodostettiin. Mikäli ongelma olisi haluttu vieläkin tehokkaampaan hallintaan, ei olisi voitu tehdä muuta toisin kuin muodostaa projektiryhmän enemmän samankaltaisista henkilöistä. Se ei kuitenkaan ole aina realistista eikä sille nähdä mitään tarvetta, sillä parempi on totutella tekemään projekteja realistisesti hyvin erityyppisistä ihmisistä koostuvien ryhmien kanssa. Toiminnallinen määrittely jätettiin kokonaan pois projektin puolivälissä sillä sen ei koettu tarjoavan juurikaan hyötyjä aikaa kuluttavan ylläpitämisen vastineeksi. Jos projekti tehtäisiin uudelleen toiminnallisen määrittelyn tarve kyseenalaistettaisiin vieläkin voimakkaammin. Nytkin se kyseenalaistettiin, mutta kuitenkin tehtiin, sillä kurssin vaatimuksissa määriteltiin niin. Laatupalkinnon voittaminen olisi vaatinut suurempaa panostusta dokumentointiin ja kurssin henkilökunnan miellyttämiseen. Olisi siis ollut syytä valita projektissa toteutettavaksi ohjelmistoksi huomattavasti yksinkertaisempi järjestelmä, sillä monimutkaisen järjestelmän toteutusta ei arvostettu samassa suhteessa kuin siihen tarvitsee käyttää resursseja. Monimutkaisuuteen tehdyt panostukset olisi kannattanut siirtää dokumentointiin ja tarkempaan menetelmäraportointiin sekä muihin kurssin henkilökuntaa miellyttäviin seikkoihin. Näin asiakkaan tyydyttäminen ja laatupalkinnon saavuttaminen olivat valitettavasti hieman ristiriidassa. 3.2 Tavoitteiden toteutuminen Projektiryhmän ja asiakkaan tavoitteista johdetut projektin tavoitteet esiteltiin kappaleessa 1. Tässä käydään jokainen mainittu tavoite läpi ja analysoidaan sen toteutumista. Projektiryhmän tavoitteet 1) Ohjelmistotuotantoprosessin ja ohjelmistotuotannon menetelmien ymmärryksen kasvattaminen saavutettiin todella korkealla tasolla kaikkien projektiryhmän Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 10

11 jäsenten kohdalla. Kohtuullisen suuren, oikean ohjelmistoprojektin läpivienti ammattitaitoisen kurssihenkilökunnan määrittämällä tavalla toi todella paljon kokemusta ja käytännön tietämystä ohjelmistotuotannosta ja sen menetelmistä. 2) Mahdollisimman suuren asiakastyytyväisyyden tuottavan tuotteen tekeminen ennalta kiinnitetyllä aikataululla ja työmäärällä onnistui mainiosti. Alunperin kiinnitettyä työmäärä alitettiin. Kolmen henkilön osalta työmäärä hiukan ylittyi, muttei häiritsevissä määrin. Kaikki suunniteltu saatiin tehtyä ja enemmän. Tuote toimii ja asiakas on tyytyväinen. 3) Kurssin laajuuden ja aikataulun puitteissa pysyminen onnistui mainiosti. Työmäärät ja aikataulu kiinnitettiin, eikä ylimääräistä työtä tehty kuin hieman kolmen henkilön osalta. 4) Kurssin suorittaminen erinomaisella arvosanalla näyttää näillä näkyvin onnistuvan. Asiakkaan tavoitteet 1) Kolmen projektissa tuotettavan osakokonaisuuden (henkilöt, asiakkaat ja projektit) valmiiksi saattaminen onnistui mainiosti. 2) Valmiiden olemassa olevien moduulien liittäminen / liittämismahdollisuuden varmistaminen onnistui mainiosti: liittämismahdollisuudet otettiin huomioon jo järjestelmän suunnittelussa ja Kalenterimoduuli liitettiin järjestelmään. 3) Suunnittelussa otettiin huomioon myös sellaiset toiminnallisuudet, joita ei tämän projektin aikana liitetä järjestelmään (esimerkiksi sopimukset -osakokonaisuus ja tietämysalueet -osakokonaisuus). 4) Nykyisiä tietoja vanhasta intrasta ei siirretty tämän projektin puitteissa uuteen intraan. Siirtäminen on kuitenkin huomioitu järjestelmän suunnittelussa ja sen tulisi onnistua helposti. 5) Modulaarisuus, kolmikerrosmalli, projektissa tuotettuja moduuleja voidaan hyödyntää asiakkaan tulevissa projekteissa sekä tuotekehityksessä: aiheesta luotiin projektiin yksi sen seitsemästä menetelmästä. Menetelmän käyttö onnistui kiitettävästi. 6) Ohjelmistotuotantoprosessin, laatujärjestelmän dokumentaation, työtapojen ja menetelmien kehittäminen onnistui erinomaisesti: projektille luotiin oma laatukäsikirja johon toimintatavat kirjattiin. Dokumentointi tehtiin kurssin henkilökunnan ammattitaitoisten dokumenttipohjien pohjalta. Seitsemää ohjelmistotuotannon menetelmää kokeiltiin käytännössä siten, että niistä myös erikseen raportoitiin. Asiakas sai mainittavia hyötyjä kaikesta tästä oman toimintansa kehittämiseen. 7) Aikataulussa pysyminen onnistui hyvin ja järjestelmä saatiin valmiiksi kuten pitikin. Matkan varrella tapahtui pientä lipsumista aikatauluista, mutta ne saatiin kiinni eikä ne vaikuttaneet koko projektin aikatauluun. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 11

12 8) Käytettävyys varmistettiin yhdessä asiakkaan kanssa tehdyllä käyttöliittymäsuunnitelmalla. Asiakkaalla oli aiheesta paljon kokemusta ja asiakkaan esittämää käyttöliittymämallia oli arvioitu ja kehitetty jopa TKK:n käytettävyyslaboratoriossa. 9) Järjestelmän toteutuksessa käytetään Innofactorin olemassa olevaa Intrakäyttöliittymää. Tämä liittyy edelliseen kohtaan. Asiakas saneli hyvin pitkälle käyttöliittymämallin jota käytettiin. 10) Kehitetään mahdollisuuksien mukaan jo olemassa olevia moduuleja. Tämä onnistui Kalenterimoduulin osalta mainiosti, sillä sitä kehitettiin merkittävästi ennen sen integrointia järjestelmään. Projektin tavoitteet Projektin tavoitteet syntyivät yhteenvetona edellisistä. Kuten kahdesta edellisestä kappaleesta käy ilmi, projekti saavutti tavoitteensa hämmästyttävän hyvin. Karsintaa asiakkaankaan priorisoiduista vaatimuksista ei jouduttu tekemään. Tätä edesauttoi vaatimusmuutosvaiheessa suoritettu yhteinen pohtiminen projektin tavoitteista ja laajuudesta, joka saatiin pitkän prosessin jälkeen iteroitua kohdalleen. Projektiryhmäläisten käsitys tehdyn työn onnistumisen asteesta on siis erittäin korkea. 3.3 Jatkokehitysnäkymät Järjestelmää ei rakennettu tämän projektin puitteissa valmiiksi. Korkealla arkkitehtuuritasolla se kuitenkin suunniteltiin hyvin paljon laajemmaksi. Järjestelmään on suunniteltu toteutettavaksi seuraavat osakokonaisuudet. Tuotteet (product), Innofactor Oy:n tuotteet/palvelut ja niiden tiedot. Tiedotus ja dokumentointi (communication & documents), Innofactor Oy:n dokumentointi ja tiedotus, joka liittyy liiketoimintaprosesseihin. Talous (invoicable invoice), laskutus yms. Sopimukset (legal stuff), tarjoukset, sopimukset, tilaukset ja tilausvahvistukset. Seuraavien osakokonaisuuksien tekemiseksi on perustettava uusi projekti, joka tulee karkeasti arvioituna olemaan tämän projektin laajuinen. Tämän projektin pohjalta järjestelmän kehittämistä on mukava jatkaa. 4. TYÖMENETELMÄT JA TYÖKALUT Tässä kappaleessa on esitetty yhteenveto käytetyistä työmenetelmistä ja työkaluista ja arviointi niiden sopivuudesta omaan projektiin. 4.1 Tuntiraportointi Projektissa tuntiraportointia tehtiin MS-Projectilla tehtyjen tehtävien tasolla päivittäin. Projekti oli ositettu varsin pieniin tehtäviin (<5 htp) mikä on tehokkaan Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 12

13 tuntienseurannan kannalta välttämätöntä. Tunnit raportoitiin kurssin tarjoaman Tiranaohjelmiston avulla. Käytännössä tunnit kirjattiin tehtävätasolla järjestelmään aina työpäivän päätteeksi. Tehtäviin oli kirjattava aina tehtyjen tuntien lisäksi arvio tehtävän jäljellä olevasta kestosta. Järjestelmään syötetyn datan avulla projektipäällikkö pystyi seuraamaan projektin tilaa lähes reaaliaikaisesti internetyhteyden takaa. Järjestelmästä kävi selkeästi ilmi mitä oli tehty, miten paljon aikaa oli kulunut ja miten paljon sitä vielä arviolta kuluisi. Tällaisin tiedon avulla nähdään välittömästi, mikäli ongelmia on tulossa ja voidaan ryhtyä toimenpiteisiin. Käytännössä projektin ohjaaminen Tiranan avulla oli helppoa ja miellyttävää. Aikaa säästyi valtavasti, kun aina ei tarvinnut pitää palavereita tietääkseen missä mennään. Kun ongelmia oli näkyvissä, ryhdyttiin välittömästi toimenpiteisiin jotta ongelmat saataisiin estettyä. Tämä onnistuikin varsin tehokkaasti. Jotta tuntien seuraamisesta ja raportoinnista olisi hyötyä, on projektin tehtävät suunniteltava huolella ja riittävän pieniksi. Näin myös tehtiin ja menetelmästä saatiin paljon irti. Mikäli projektia ei olisi ositettu huolella, olisi menetelmän hyödyt olleet varmasti paljon pienemmät. Aina on hyvä saada yksi motivaattori lisää projektin huolelliseen osittamiseen! Menetelmä soveltui projektiin todella mainiosti. Ilman tuntiraportointia projekti olisi hyvinkin voinut ajautua ongelmiin. Joka tapauksessa menetelmä tehosti projektityötä. Lisäksi sen avulla saatiin kerättyä elintärkeää dataa projektin eri osien ja tehtävien kestoista, joita voidaan käyttää hyväksi arvioitaessa vastaavien projektin tehtävien kestoja. 4.2 Riskienhallinta Projektin riskienhallintaprosessi suunniteltiin projektin alussa dokumentoiden se laatukäsikirjaan. Käytännössä prosessi toimi siten, että projektissa pidettiin säännöllisesti riskienhallintakokouksia, joissa projektin riskit identifioitiin indikaattoreineen, seurauksineen ja hallintakeinoineen. Jokaiselle riskille määritettiin vastuuhenkilö, joka oli vastuussa riskin hallitsemisesta ja ja poistamisesta. Jokaisessa kokouksessa käytiin läpi vanhat riskit tehtyine toimenpiteineen ja tutkittiin oliko vanhoja riskejä saatu poistettua. Lisäksi arvioitiin oliko projektille ilmaantunut uusia riskejä, joita sitten käsiteltiin vastaavalla tavalla. Menetelmän suurimmat hyödyt olivat siinä, että projektiryhmä ja asiakas saatiin kiinnittämään huomiota riskeihin, sisäistämään sen että niitä esiintyy ja keskittymään niiden ehkäisemiseen. Asiakkaan sitouttaminen riskienhallintaan aiheuttaa positiivisen psykologisen reaktion: asiakas ei syytä niistä pelkästään toimittajaa vaan ymmärtää myös itse olevansa osavastuussa. Tämä pätee myös koko projektiryhmään. Yhteinen sitoutuminen asiaan aikaansaa yhdessä tekemisen fiiliksen, joka keskittyy ongelmien ratkaisemiseen eikä niistä purnaamiseen. Riskien hallintaan liittyy myös vaatimustenhallinnasta tuttuja positiivisia ilmiöitä, joiden mukaan asiakas ymmärtää paremmin ettei kaikkea voi vaatia, ja sen että kaikella on hintansa. Tällöin asiakaskin Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 13

14 ymmärtää paremmin tekemiensä vaatimusten hinnan ja osaa tehdä ratkaisunsa paremmin perustein. Menetelmä soveltui projektiin mielestämme hyvin ja tarjosi varmasti hyötyjä sopivasti suhteessa suhteellisen pieniin panoksiin, jotka siihen laitettiin. Raskaampaan tilastoaineistoa, faktoreita ja todennäköisyyksiä apuna käyttävään riskienhallintaprosessiin emme tunteneet kaipuuta. Uskoaksemme sellainen olisi ollut turhan raskas tällaiseen projektiin. Hyvästä ja kattavasta tilastoaineistosta olisi em. kertoimia kyllä mukava laskeskella, mutta ne eivät välttämättä tarjoaisi vastinetta vaatimiinsa panoksiin. Mielestämme menetelmä tässä laajuudessaan olikin varsin onnistunut ja soveltui hyvin projektiin. 4.3 Vaatimusmuutosten hallinta T1-T2 Vaiheet Kuopio-projektin vaatimusmuutosten hallintaan tarkoitettu menetelmä otettiin käyttöön T2-vaiheen alussa. Tammikuun alussa pidettiin asiakkaan kanssa palaveri, jossa hän esitteli muutosehdotuksensa ja näiden prioriteetit. Tähän kokoukseen osallistui asiakkaan lisäksi projektiryhmän jäseniä. Kokouksen päämääränä oli kerätä talteen asiakkaan muutosehdotukset ottamatta niihin tässä vaiheessa vielä mitenkään kantaa. Kokouksen jälkeen pidettiin projektiryhmän sisäinen palaveri, jossa käytiin jokainen muutosehdotus yksityiskohtaisesti läpi. Tämä tapahtui siten, että ensimmäiseksi muutosehdotus esitettiin, sitten jokainen sai mahdollisuuden kommentoida sitä, ja lopuksi siitä kirjattiin päätösehdotus. Ennen päätöksen tekoa tutkittiin mm. sen vaikutuksia projektin aikatauluun, toteuttamisen mahdollisuutta tekniseltä kannalta, vaikutuksia käyttöliittymään jne. Jokaisesta muutosehdotuksesta tehtiin päätösehdotus. Nämä ehdotuksen hyväksytettiin asiakkaalla ja sen jälkeen dokumentteihin tehtiin tarvittavat muutokset. Yllä kuvattu prosessi todettiin hyväksi varsinkin sen takia, että siinä ei tarvitse antaa välitöntä vastausta asiakkaalle jonkin muutoksen vaikutuksista muuhun projektiin eikä sen teknisestä toteuttamisesta. Välittömien vastausten antaminen muutosehdotuksiin jo tämän kokoluokan projekteissa on erittäin riskialtista. Tämä menettely on myös asiakkaan edun mukaista, koska hän saa tarkempaa tietoa sen vaikutuksista esim. projektin aikatauluun. Tämän menetelmän soveltamisesta oli jo tässä vaiheessa konkreettista hyötyä: Eräs asiakkaan ehdottama vaatimusmuutos käsitteli tietyn osakokonaisuuden prioriteetin nostamista siten, että se olisi mahdollista ottaa käyttöön aikaisemmin. Tämä muutos vaikutti aluksi yksinkertaiselta, tehdään se vain ennen muita osioita. Tarkemman tutkimisen jälkeen havaittiin kuitenkin, että tämän osakokonaisuuden järkevä käyttö osana järjestelmää vaatii muiden osakokonaisuuksien tekemisen ensin. Ilman muutosprosessia tämä asia olisi huomattu luultavasti liian myöhään. Prosessin avulla saatiin muutoksista tehtyä tarkat aika- ja resurssiarviot. Tämä helpotti huomattavasti projektin jatkon suunnittelua. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 14

15 Prosessista löydettiin myös parannettavaa. Tässä vaiheessa vaatimusmuutosehdotusten käsittely on hoidettu kerran vaiheen alussa. Nyt todettiin kuitenkin, että näitä kokouksia tulisi jatkossa pitää useammin. Päädyttiin siihen tulokseen, että vaatimusmuutospalaveri pidetään aina, kun asiakas tai projektiryhmä näkee sen tarpeelliseksi. T3-vaiheen alkuun on jo tulossa seuraava muutospalaveri ja luultavasti ennen vaiheen loppua pidetään vielä toinen palaveri. Tämä siksi, että mahdolliset vaatimusmuutokset ja niiden vaatima työ saadaan sisällytettyä vaiheen projektisuunnitelmaan. T3 vaihe Tämän vaiheen aikana ei oikeastaan tullut uusia käyttökokemuksia menetelmästä. Menetelmän käyttö on jo tullut rutiininomaiseksi ja on osoittautunut erittäin käteväksi. Myös asiakas on tyytyväinen menetelmään, koska sen avulla hän pysyy paremmin tietoisena muutosten aiheuttamista muutoksista projektin etenemiseen. Vaatimusmuutospalaverissa tuli muutamia uusia vaatimusmuutoksia, mutta ne olivat suurimmaksi osaksi kosmeettisia muutoksia. Yksi muutos. joka päätettiin toteuttaa seuraavassa vaiheessa, tosin on otettava huomioon vaiheen aikataulua suunniteltaessa. Tämän vaiheen lopussa oli tarkoitus pitää vaatimusmuutospalaveri, mutta siihen ei tullut tarvetta. LU vaihe Viimeisessä vaiheessa ei enää ollut tarkoitus ottaa käsittelyyn suurempia vaatimusmuutospyyntöjä. Pieniin, ulkoasua yms. koskeviin vaatimusmuutoksiin oli kuitenkin projektisuunnitelmassa varauduttu. Vaiheen alkupuolella asiakkaan kanssa pidetyssä vaatimusmuutospalaverissa ei kuitenkaan tullut esille uusia vaatimusmuutoksia. Tämä johtuu luultavasti mm. siitä, että asiakkaalla on aikomuksena kehittää tässä projektissa syntynyttä tuotetta jatkossakin. Tästä johtuu ainakin se, että käytettävyyteen ja ulkoasuun liittyviä vaatimusmuutoksia ei tullut. Toisessa vaatimusmuutospalaverissa käytiin läpi kaikki projektin aikana tulleet vaatimusmuutokset ja tarkistettiin toteutuneet muutokset. Tämän jälkeen vaatimusmuutosprosessi hyväksyttiin päättyneeksi. Vaatimusmuutosten puuttumisesta johtuen tehdyt tunnit jäivät vaatimusmuutosprosessin osalta alle suunnitellun. Yhteenveto menetelmästä Projektiryhmä koki tämän menetelmän varsin käyttökelpoiseksi. Vaatimusmuutosprosessin raskaudesta huolimatta menetelmä toimi käytännössä varsin hyvin. Vaatimusmuutoksia tuli yhteensä 14, joista toteutettiin 7. Vaatimusmuutosprosessia kevensi tietenkin myös muutosehdotusten pieni lukumäärä, joka puolestaan kertoo vaatimusmäärittelyn onnistumisesta. Vaatimusmuutosprosessin ehdottomasti parasta antia oli se, että sen avulla voitiin jokainen asiakkaalta tullut muutosehdotus ensin dokumentoida, sitten miettiä sen toteutusmahdollisuuksia rauhassa ja vasta viimeiseksi ottaa sen toteuttamiseen kantaa. Asiakas taas oli muutosprosessista sitä mieltä, että se lisäsi hänen vaikutusmahdollisuuksiaan projektin etenemiseen. Eli tässä tapauksessa molemmat voittivat. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 15

16 Lopuksi voidaan vielä todeta, että ei olisi mikään ihme, jos joku kokenut projektipäällikkö kuvaisi vaatimusmuutosprosessin toimivuutta projektin onnistumisen kannalta erittäin kriittiseksi asiaksi. 4.4 Versionhallinta CVS 1.11 ohjelmiston avulla Kuopio projektissa käytettävistä menetelmistä yksi oli versionhallintaohjelmisto CVS. Menetelmä sai projektitiimiltä erittäin lämpimän vastaanoton jo heti projektin alkuvaiheessa johtuen CVS:n tiedetyistä hyödyistä ja käytettävyydestä. Nyt projektin päättyessä jää CVS:tä yhtä positiivinen kuva kuin alussa oletettiin. Tulevaisuudessa ei tulla varmastikaan tekemään yhtään ohjelmistoprojektia ilman versionhallintajärjestelmää. Projektin viimeisessä vaiheessa saatiin CVS:n asentaminenkin erittäin helpoksi, kun käyttäjien tunnistaminen tehtiin Windowsin käyttäjätietojen perusteella. Alussa kaikki salasanat ja yhteydet piti muodostaa käsin ohjelmistoa asennettaessa. Yleensäkin CVS:n perustoimintojen opettamiseen uudelle käyttäjälle ei vie puolta tuntia enempää aikaa. Tietysti mitä enemmän CVS:n toimintoja opiskelee sitä suurempi hyöty siitä saadaan irti. Projektin osalta ei CVS:tä tarvinnut opetella kuin perustoiminnot, mutta jo pelkästään mielenkiinnosta mietittiin projektin aikana mitä kaikkea hyödyllistä CVS:tä voisi saada irti. Oli puhetta mm. saman tuotteen spesifioimista eri asiakkaille CVS:n avulla niin ettei tarvitsisi tehdä kahta eri ohjelmistoa. Projektin edetessä ja uusien monimutkaisempien ohjelmistokokonaisuuksien tuotantovaiheessa CVS:stä oli suuri hyöty kun enemmän kuin yksi henkilö oli ohjelmoinnissa mukana. CVS säästi paljon aikaa kun jokainen ohjelmoija pystyi keskittymään omaan työhönsä 100-prosenttisesti häiritsemättä muita. Mahdolliset konfliktitilanteet CVS ilmoitti selkeästi ja järjestelmä ilmoitti kenen tekemien muutoksien kanssa konflikti oli tullut. Tällöin on helppo ratkaista miten päällekkäisyydet hoidetaan. CVS:n julkaisutoimintoja käytettiin projektissa hyväksi aina ennen testauskierroksia ja katselmuksia. Kun tuotetta ruvettiin testaamaan, otettiin CVS:stä testausversio ulos ja korjausten jälkeen merkittiin tämä versio katselmointiversioksi. Tuo kyseinen testattu ja toimiva versio otettiin ulos katselmointia varten, jolloin toimintavarmuus oli taattu huolimatta mahdollisista lisäyksistä ohjelmistoon. Kaiken kaikkiaan CVS sopii Kuopion kaltaisiin ohjelmistoprojekteihin erittäin hyvin. Ohjelmoinnissa on varmasti useita henkilöitä mukana, jolloin jonkinlainen päällekkäisyyksien hoitaminen on pakollista ja CVS antaa siihen oivat puitteet. Toinen aspekti on tuotteen myyminen eri asiakkaille joilla on hieman eri tarpeet toiminnoille ja ulkoasulle. Tässäkin CVS on apuna ohjelmoinnin keskittämisessä yhteen ohjelmoitavaan kokonaisuuteen. CVS:n julkaisutoiminnot auttavat myös eri versioiden testaamisessa ja asentamisessa asiakkaalle. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 16

17 4.5 Monikerrosarkkitehtuuri Kuopio projektissa oli tarkoitus käyttää monikerrosarkkitehtuuria, jotta järjestelmästä saataisiin modulaarinen ja skaalautuva, ja jotta se olisi helppo integroida muihin järjestelmiin. Monikerrossovellusten tekoon on vasta viime aikoina alkanut tulla kunnon sovellus kehittimiä, joista uusimpana projektissa käytetty Microsoftin.Net Framework. Vaatimukset Jotta järjestelmä olisi aidosti monikerrosarkkitehtuurin mukainen, tulisi siinä olla ainakin selkeät data-, toiminta- ja käyttöliittymäkerrokset. Näiden lisäksi voidaan tehdä myös muita kerroksia mikäli niille ilmenee tarvetta ja mahdollisuuksia niiden toteuttamiseen. Kukin kerros tulisi olla erillinen kokonaisuus, johon pystytään tarvittaessa tekemään helposti oma rajapinta, ja se voidaan siirtää eri palvelimelle tai arkkitehtuurille. Toteutus Tietokanta ja sen käyttö eli data ja datayhteyskerros ovat melko selkeästi erillään ja mahdollistavat eri tietokanta-arkkitehtuurin helpon liittämisen järjestelmään. Käyttöliittymä ja käyttöliittymän toiminallisuutta ei ole eroteltu. Tätä ei välttämättä kolmikerrosmallin mukaisessa arkkitehtuurissa tarvita, mutta ohjelmiston tuotteistamisen ja ulkoasun tai käyttöliittymän helpon muunneltavuuden kannalta tämä olisi varsin perusteltua ja järkevää. Toiminnallinen kerros on varsin paljon liitettynä käyttöliittymään. Käyttöliittymässä oleva data on kuitenkin erillään datakerroksesta, jolloin sen käyttämiseen ei tarvitse liikkua toiminnallisen kerroksen läpi ja nämä kerrokset on mahdollista jatkossa jakaa erilleen. Tässä projektissa ei tälle kuitenkaan ole tarvetta. Yhteenveto ja jatkosuunnitelmat Monikerrosarkkitehtuurin toteutus on järjestelmässä varsin hyvällä alulla. Data ja datayhteyskerros ovat valmiiksi omina lohkoinaan, joten niihin on hyvin helposti tarvittaessa luotava rajapinnat niiden erottamiseksi omiksi tasoikseen. Käyttöliittymä ja toimintalogiikka kerrosten erottaminen täysin omiksi kerroksikseen vaatisi jonkin verran työtä, mutta siihen ei nykyisellä arkkitehtuurilla ole tarvetta. Pääpainona on datakerroksen eriyttäminen, jotta saadaan tuki eri tietokanta-arkkitehtuureille. Menetelmä sopi projektiin mainiosti ja mahdollisti usean asiakasvaatimuksen täyttämisen. Esimerkiksi Kalenterimoduulin integrointi järjestelmään ja tulevaisuudessa tehtävien osakokonaisuuksien liittämiseen valmistautuminen onnistuivat menetelmän avulla hyvin. Järjestelmä saatiin menetelmän avulla rakennettua asiakkaan toiveitten mukaan modulaariseksi siten, että järjestelmän moduuleja olisi jatkossa mahdollista käyttää myös muissa järjestelmissä ja kehittää edelleen. Käyttökokemukset ovat olleet siis positiivisia. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 17

18 Menetelmän toteuttamiseen jäi vielä hieman parantamisen varaa, ja seuraavassa projektissa tämä onnistuukin projektiryhmän jäseniltä entistä paremmin. Näin ollen voidaan menetelmän tarjonneen ryhmäläisille myös arvokkaita oppimiskokemuksia. 4.6 Rasitustestaus Microsoft CenterTest.NET on Kuopio-projektissa kokeiltu testauksen apumenetelmä. Ennen projektia se oli projektiryhmälle aidosti uusi, mutta projektin aikana kaksi ryhmän jäsentä tutustui siihen huolellisesti. Projektissa CenterTestin ominaisuuksista käytettiin mahdollisuutta sivustojen rasitustesteihin, joita CenterTestiin voi ohjelmoida http-pyyntökohtaisesti. Muita CenterTestin ominaisuuksia ei resurssipuutteen vuoksi kokeiltu. Rasitustestaus suunniteltiin T2-vaiheessa. Suunnitelmia tarkennettiin ja rasitustestaus toteutettiin LU-vaiheessa. Yhteenlaskettu työmäärä kaikilta projektiryhmän jäseniltä koko projektin ajalta rasitustestaukseen liittyen on noin 30 tuntia. Rasitustestauksen kokeilu söi siis resursseja varsin minimaalisesti. Rasitustestauksesta saatujen tulosten laatu, määrä ja luotettavuus ei ollut huipputasoa. Ongelmiksi muodostuivat resurssien vähyys ja muista käynnissä olleista projekteista aiheutuneet virhetekijät. Näitä virhetekijöitä ja rasitustestauksen tuloksia on analysoitu erillisessä rasitustestausraportissa. 4.7 Koodikatselmoinnit Kuopio-projektissa kokeiltiin koodikatselmointeja. Menetelmä oli kaikille ryhmän jäsenille aidosti uusi. Koodikatselmoinnit toteutettiin jokaisen moduulin toteuttamisen jälkeen ennen kyseiseen moduuliin liittyvää moduulitestausta. Koodikatselmointiin osallistuneiden henkilöiden lukumäärää ja kokoonpanoa vaihdeltiin sekä kokeilumielessä että etenkin projektin loppuvaiheessa tarkoituksena tasata eri henkilöiden työkuormitusta. Yhden moduulin katselmointiin osallistui yhdestä neljään henkilöä. Koodikatselmointien tarkoitus oli löytää koodista eroavaisuuksia tehtyihin suunnitelmiin, sekä löytää piilevät ei-perustelluista implisiittisistä oletuksista aiheutuvat virheet. Ensimmäinen tavoite pystyttiin toteuttamaan varsin hyvin ensimmäisessä vaiheessa Henkilöt -osakokonaisuuden yhteydessä. Seuraavissa vaiheissa tämä onnistui vain kohtuullisesti sillä suunnitelmien taso oli tässä mielessä laskenut jonkin verran. Tällöin katselmoijien löytämät eroavaisuudet suunnitelmiin käsiteltiin lähinnä keskusteluina siitä, miten asiat pitäisi toteuttaa. Tästä opittiin, miten huonot suunnitelmat myöhemmin vaikeuttavat muita ohjelmistotuotantoprosessin toimintoja. Miltei aina löydetyt puutteet olivat ohjelmoijien tiedossa ennen koodikatselmointeja. Tällöin katselmointi ei suoranaisesti tuota uutta tietoa ohjelmiston tilasta. Koettiin kuitenkin erittäin hyödylliseksi saada harkittu, keskusteltu ja puhtaaksikirjoitettu luettelo koodista löydetyistä puutteista. Tällaisen luettelon pohjalta asioiden korjaaminen ei ole yksittäisten ohjelmoijien muistin varassa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 18

19 Kaiken kaikkiaan koodikatselmointeihin osallistuneet henkilöt kokivat koodikatselmoinnin hyödyllisiksi. Asiakas on suunnittelemassa koodikatselmointien käyttöönottoa tulevissa muissa projekteissaan. 5. JÄLKILASKELMAT 5.1 Työmäärä Jälkilaskelmat ja vertailu suunnitelmiin ja selitykset poikkeamille (työmäärä, kustannukset, aikataulut, ohjelmistovirheiden määrä, ohjelmiston koko). Projektille budjetoitiin projektin alussa resursseja 1400 tuntia eli 200 tuntia / henkilö. Budjetointi tehtiin kurssin laajuuden perusteella ja projektin koko suhteutettiin siihen. PS-vaiheessa projekti käynnistettiin organisoitiin ja suunniteltiin sekä luotiin sille toimintatavat. Vaiheen budjetti tehtiin sen alussa hyvin heppoisin perustein aiempien ohjelmatöiden PS-vaiheiden tuntimäärien perusteella, sillä parempaa tietoa vaiheen tulevasta kestosta ei ollut saatavilla. Vaiheeseen arvioitiin keskimäärin kuluneen noin 280 tuntia, joka myös budjetoitiin vaiheelle. Vaihe kuitenkin päätökseen 238 tunnissa eli budjetti alitettiin reilusti. Karkeat arviot seuraavien vaiheiden budjeteille olivat saman datan perusteella T1: 300, T2: 320, T3:320, LU 180. T1-vaihe suunniteltiin tarkasti PS-vaiheessa ja tuohon budjetoituun 300 tuntiin päästiin projektin ositettujen tehtävien arvioinnin kautta. Projektipäällikkö käytti 20% varausta (Contingency) tehtävissä. Vaihe toteutui 241 tunnilla ja tekemättä jäi noin 30 tunnin työ. Budjetointi oli siis lähelle oikeaa ja 20% varaus oli turhan suuri. Tekemättä tehnyt työ päätettiin siirtää T2-vaiheeseen. T2-vaiheelle budjetoitiin 320 tuntia tarkemman tehtäviin osittamisen jälkeen käyttäen tällä kertaa 10% varausta tehtävissä, kun viimeksi oltiin osuttu niin lähelle oikeassa arviossa ilman varausta. Vaihe toteutettiin 298 tunnissa ja 10 tunnin työ jäi tekemättä. Varauksesta tuli suuri osa hyvään käyttöön. Projektipäällikkö päätti säilyttää 10% varauksen jatkossakin projektin onnistumisen turvaamiseksi. Projektin arvioitua kokonaisbudjettia pudotettiin yhdessä asiakkaan kanssa 1250 tuntiin saavutettujen budjettisäästöjen vuoksi. Samalla projektiin otettiin mukaan myös Kalenterimoduulin integroinnin verran lisätyötä. Vaiheessa tekemättä jääneet tehtävät siirrettiin T3- vaiheeseen. T3-vaiheelle budjetoitiin 315 tuntia tarkemman tehtäviin osittamisen jälkeen käyttäen edelleen 10% varausta tehtävissä. Vaihe toteutettiin 275 tunnissa ja 40 tunnin työ jäi tekemättä. Varaus oli siis tällä kertaa tarpeen. Tekemättä jäänyt työ päätettiin siirtää seuraavaan vaiheeseen. Koska projekti oli ajautunut vaikeuksiin ja myöhästynyt hieman jatkuvasti päätettiin ylimääräinen työ tehdä pääsiäislomalla ennen seuraavan vaiheen alkua. LU-vaihetta siis hieman pidennettiin ja sille budjetoitiin 200 tuntia tarkemman tehtäviin osittamisen jälkeen käyttäen edelleen 10% varausta tehtävissä. Lisäksi päälle lisättiin 40 tuntia ylimääräisiä käyttämättömiä projektille allokoituja resursseja motivoimaan projektiryhmäläisiä ottamaan vaihe vakavasti ja aloittamaan suuren työmäärän tähden Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 19

20 kerrankin ajoissa. Tämä toimi ja LU-vaihe saatiin päätökseen 197 tunnilla eikä mitään jäänyt tekemättä. Projektiin käytettiin kokonaisuudessaan yhteensä 1249 tuntia, joka on hämmästyttävän lähellä T2-vaiheessa tarkennettua budjettia. Projektiin tehty työ henkilöittäin on esitetty seuraavassa taulukossa. Taulukko 1 Työmäärä henkilöittäin projektissa Wesa Aapro Ossi Jokinen Rami Laiho Mikko Lampi Matti Peltomäki Lasse Tolvanen Matias Ärje Yhteens ä PS ,5 8 18, T T T LU Yhteens ä , , Projektissa tehty työ jakautui työtyypeittäin seuraavan taulukon mukaisesti. Taulukko 2 Työn jakautuminen työtyypeittäin Työtyyppi Tunnit ATK ylläpito 5 Dokumentointi 388,5 Kokoukset 160 Luennot 30 Ohjelmointi 231 Opiskelu 13 Projektin hallinta 94,5 Suunnittelu 145 Tunnit Dokumentointi Kokoukset Luennot Tunnit Ohjelmointi Opiskelu Projektin hallinta Työtyypit Suunnittelu Testaus Tunnit Testaus 182 Dokumentointia tehtiin lähes 400 tuntia, mikä on vastaaviin tämän kokoisiin projekteihin nähden ylimitoitettua. Tämä johtui kurssin vaatimuksista. Käytännössä toimintatavat on dokumentoitu yleensä jo projektiin lähdettäessä ja projekti dokumentoidaan valmiille raporttipohjille. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 20

21 5.2 Aikataulut Muuten palkkien voidaan kuvitella antavan suuntaviivoja käytännön työmääräarviointiin vastaavan tyyppisissä projekteissa. Tosin ATK-ylläpito, luennot ja opiskelu kannattanee jättää tällöin huomioimatta. Projektin vaiheistus ja aikataulu oli määritetty jo valmiiksi kurssin puolesta ja projekti suunniteltiin sen mukaan. Projektin kokonaisaikataulu piti, mutta sen toteutusvaiheissa ei saatu aina tehtyä kaikkea suunniteltua. Yleensä tekemättä jäi osa testauksesta. Tämä on selitetty tarkemmin kappaleessa 2 Projektin eteneminen. Projekti kulki siis läpi toteutusvaiheidensa lievästi myöhässä. Tämä otettiin kiinni LU-vaiheen alussa käyttäen pääsiäislomapäiviä projektiin. Sen jälkeen ei enää ollutkaan aikataulullisia ongelmia ja projekti saatiin päätökseen ajallaan. 5.3 Ohjelmistovirheet Projektissa suunniteltiin testaussuunnitelman määrittämän testausstrategian mukaan yhteensä noin 500 testitapausta. Testitapaukset löysivät virheitä osakokonaisuuksista seuraavan kuvan mukaan. Kuva 1 Virheraportit osakokonaisuuksittain suhteutettuna niiden kokoon Kokoonsa nähden tehdyt osakokonaisuudet olivat varsin tasalaatuisia. Projektit - osakokonaisuus sisälsi suhteellisesti hieman enemmän virheitä. Tämä ei ollut yllätys, sillä se on toteutetuista osakokonaisuuksista monimutkaisin. Kalenteri ei sisältynyt virheitä vastaavasti, sillä se oli testattu asiakkaan toimesta jo aikaisemmin ja tässä tehtiin vain integrointitestaus. Löydettyjen virheiden vakavuusasteet on esitetty seuraavassa kuvassa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 21

22 Kuva 2 Virheiden luokittelu vakavuusasteittain osakokonaisuuksissa Kuvasta nähdään, että kriittisiä tai vakavia virheitä ei löydytty kovin runsaasti normaalien virheiden ottaessa suurimman roolin. Projektit -osakokonaisuuden virheet ovat suhteessa hieman vakavampia. Tämä johtuu sen korkeimmasta vaikeustasosta. Kalenterin vähät virheet ovat varsin normaalisti jakautuneet. Lähes kaikki virheet hyväksyttiin ja niiden vuoksi ryhdyttiin toimenpiteisiin. Tämä on esitetty seuraavassa kuvassa. Kuva 3 Virheraporttien tila Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 22

23 5.4 Ohjelmiston koko T1-vaiheessa toteutettiin järjestelmän runko ja Henkilöt -osakokonaisuus. Vaiheen jälkeen koodirivejä oli T2-vaiheessa toteutettiin Asiakkaat -osakokonaisuus ja ohjelmiston koko oli vaiheen toteutuksen jälkeen 3400 riviä. T3-vaiheen toteutuksen jälkeen ohjelmiston ollessa lopullisen kokoinen on ohjelmiston kooksi muodostui 4650 (+2500 kalenterimoduuli) riviä koodia. Vauhti oli siis varsinaisen ohjelmiston kehityksen osalta ollut varsin tasaista noin 1500 riviä/vaihe. Kalenterimoduulia lisäksi muokattiin ja se integroitiin järjestelmään. Kaikkea 2500 riviä ei kuitenkaan koodattu tässä projektissa vaan pohja työlle saatiin asiakkaalta. 6. OPPIMINEN Tässä kappaleessa esitellään kunkin projektinryhmän henkilön mielipiteet tärkeimmistä projektin aikana opituista asioista. Ossi: Toimin projektin projektipäällikkönä sekä laatupäällikkönä. Projekti oli jo varsin mukavan kokoinen 7 hengen tiimillään. Projektissa päästiinkin jo todellisen projektinhallinnan makuun, ja joitain projektihallinnan raskaampiakin menetelmiä alkoi olla asianmukaista käyttää (näin oli tosin määrätty jo kurssinkin puolesta). Opin projektin aikana todella paljon siitä miten ohjelmistoprojekteja pitäisi johtaa ja ohjata menestykseen määrittelemällä toimintatapoja ja prosesseja ja välttäen edessä olevia karikoita. Tiimin henkilödynamiikka ja ihmisten motivointi tarjosivat suuria haasteita. Asioiden tekeminen käytännössä tarjoaa huomattavasti suurempia oppimiskokemuksia kuin tiedonhankinta luennoilta tai kirjoista. Projektissa onnistuttiin mielestäni varsin hyvin. Työelämässä suoraan hyödynnettävää kokemusta kertyi hyvin runsaasti. Laadunohjaus on huomattavasti yksittäistä projektia laajempi asia. Sen tärkeimpiä tavoitteita on organisaation tietotaidon kasvattaminen, joka tapahtuu opitun keräämisessä mahdollisimman hyödynnettävässä muodossa sekä organisaation toiminnan kehittäminen jatkuvasti paremmaksi kerätyn tietotaidon avulla. Projektiorganisaatioissa projektit ovat erittäin oleellinen osa toimintaa missä oppimista tapahtuu, ja kertynyt tietotaito täytyisi valjastaa organisaation kehittämistä palvelevaan muotoon. Tässäpä haaste! Hyvin määritetyt selkeät prosessit ja toimittavat sekä dokumentointi ja datan keruu standardimuodossa ovat ehdoton edellytys toimivalle laadunohjaukselle. Projektissa kerättiin dataa ja käytettiin useita määriteltyjä menetelmiä ja toimintatapoja. Opin paljon siitä, millaisiksi toimintatavat ja datan keruu sekä raportointi tulisi tämä projektin tyyppisiä projekteja toteuttavassa organisaatiossa tehdä. Tässähän vallitsee paikoin vahvakin trade-off projektille sopiva byrokratian taso vs. organisaation toiminnan kehittämisen kannalta sopiva byrokratian taso. Syntyy optimointitehtävä, jota osaan optimoida huomattavasti paremmin kuin ennen projektia. Mikko: Kurssin aikana oppimistani asioista jäi päällimmäisenä mieleen kaksi menetelmää, testaus ja vaatimusmuutokset. Testaus ei ollut menetelmänä aivan uusi, Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 23

PS-vaiheen edistymisraportti Kuopio

PS-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ätiedot

Kuopio Testausraportti Kalenterimoduulin integraatio

Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio, testausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 22.4.2002 Matti Peltomäki Ensimmäinen versio 0.9 22.4.2002 Matti

Lisätiedot

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-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ätiedot

LOPPURAPORTTI Paperikonekilta Versio 1.0

LOPPURAPORTTI 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ätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin 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ätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston 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ätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Kä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ätiedot

T Projektikatselmus

T 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ätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA 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ätiedot

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

Verkkopokerijä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ätiedot

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T 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ätiedot

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T-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ätiedot

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka 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ätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Kä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ätiedot

Toteutusvaihe T2 Edistymisraportti

Toteutusvaihe 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ätiedot

Convergence of messaging

Convergence 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ätiedot

EDISTYMISRAPORTTI - T4 Virtuaaliyhteisöjen muodostaminen Versio 1.0

EDISTYMISRAPORTTI - T4 Virtuaaliyhteisöjen muodostaminen Versio 1.0 EDISTYMISRAPORTTI - T4 Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 2 1. PROJEKTIN TILA 3 2. SUORITETUT TEHTÄVÄT 5 Projektisuunnitelma 5 Testaussuunnitelma

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

Projektisuunnitelma Kuopio

Projektisuunnitelma Kuopio Projektisuunnitelma Kuopio Kuopio, Projektisuunnitelma, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 13.10.2001 Ossi Jokinen 0.2 25.10.2001 Ossi Jokinen Sisäisen katselmoinnin korjaukset.

Lisätiedot

EDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0

EDISTYMISRAPORTTI - 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ätiedot

EDISTYMISRAPORTTI - T1 Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 1)

EDISTYMISRAPORTTI - T1 Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 1) EDISTYMISRAPORTTI - T1 Edited by Checked by Approved by Antti Tuomaala i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 2. SUORITETUT TEHTÄVÄT 4 Projektisuunnitelma Vaatimusmäärittely Virhe.

Lisätiedot

Projektityö

Projektityö 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ätiedot

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

T 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ätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. 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ätiedot

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausdokumentti. 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ätiedot

T Testiraportti - järjestelmätestaus

T 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ätiedot

Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

Projektiryhmä 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ätiedot

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Projektisuunnitelma. 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ätiedot

T Loppukatselmus

T 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ätiedot

Project group Tete Work-time Attendance Software

Project 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ätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

SOVELLUSPROJEKTIN ARVIOINTILOMAKE SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa

Lisätiedot

AS Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma

AS 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ätiedot

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

Good 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ätiedot

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti

SALAKIRJOITUKSEN 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ätiedot

T Testiraportti - integraatiotestaus

T 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ätiedot

MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver Hannu Hirsi 2018

MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver Hannu Hirsi 2018 MS Project 2016 perusteet projektiarkkitehdeille ja -insinööreille ver. 7.2 Hannu Hirsi 2018 1 Yleistä : 1. Yksi käytetyimmistä projektien hallintaohjelmista on Microsoft Project, joka on tehokas ja joustava

Lisätiedot

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu

Lisätiedot

Tik-76.612 Ohjelmistoprojektien Hallinta

Tik-76.612 Ohjelmistoprojektien Hallinta Tik-76.612 Ohjelmistoprojektien Hallinta Tervetuloa kurssille! 2 Kurssin yleisinfo Kurssin tausta Katsaus luentoihin Aloitusluennon agenda Luennoitsijoiden esittely Harjoitustyön läpikäynti Muut käytännön

Lisätiedot

Orientaatio ICT-alaan. Projekti

Orientaatio ICT-alaan. Projekti Orientaatio ICT-alaan Projekti Projekti Ajallisesti rajoitettu, kertaluonteinen tehtävä määrätyt resurssit sekä oma (linjaorganisaatiosta poikkeava) organisaatio Toteutus tapahtuu suunnitelmallisesti ennalta

Lisätiedot

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä.

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toiminnallisen määrittelyn tarina Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toimitusjohtajan pulma Tässä on toimitusjohtaja Roope, jonka tavoitteena on pyörittää Rengasmaster Oy:tä

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Harjoitus 3 Case Face Wash. Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja

Harjoitus 3 Case Face Wash. Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja Harjoitus 3 Case Face Wash Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja Tunnistettuja ongelmia Katastrofaaliset ongelmat Kommunikointi Projektisuunnitelman puuttuminen Projektia ei aikataulutettu

Lisätiedot

A4.1 Projektityö, 5 ov.

A4.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ätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS 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ätiedot

Project-TOP QUALITY GATE

Project-TOP QUALITY GATE Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä

Lisätiedot

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti

Lisätiedot

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter

Lisätiedot

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

SEPA 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ätiedot

Projektin palikat hallintaan! Tehokkaan projektinhallinnan opas. Idea Suunnittelu Käynnistäminen Toteutus Tulos

Projektin palikat hallintaan! Tehokkaan projektinhallinnan opas. Idea Suunnittelu Käynnistäminen Toteutus Tulos Projektin palikat hallintaan! Tehokkaan projektinhallinnan opas Idea Suunnittelu Käynnistäminen Toteutus Tulos 1 Tehokas projektinhallinta on avain tuloksellisuuteen Projektinhallinta on taitolaji. Siinä

Lisätiedot

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa.

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työ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ätiedot

Toteutusvaihe T3 Digi-tv: Edistymisraportti

Toteutusvaihe 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ätiedot

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D

VERSIONHALLINTA. 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ätiedot

COTOOL dokumentaatio Riskiloki

COTOOL dokumentaatio Riskiloki Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria...........................................................................

Lisätiedot

0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

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ätiedot

Data Sailors - COTOOL dokumentaatio Riskiloki

Data Sailors - COTOOL dokumentaatio Riskiloki Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................

Lisätiedot

PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009

PROJEKTIN 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ätiedot

Vastuu- ja tehtäväalueet sekä tiedonvälitys OSCu-kursseilla

Vastuu- 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ätiedot

Projektisuunnitelma Nero-ryhmä

Projektisuunnitelma Nero-ryhmä Projektisuunnitelma Nero-ryhmä Kuusela Johannes Muukkonen Jyrki Sjöblom Teemu Sundberg Ville Suominen Osma Tuohenmaa Timi Ohjelmistotuotantoprojekti Helsinki 9.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen

Lisätiedot

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T 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ätiedot

Projektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma

Projektiryhmä 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ätiedot

Tik-76.612 Harjoitustyö

Tik-76.612 Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyö Tehdään 2-3 hengen ryhmissä Koostuu etapeista joiden aikana simuloidaan ohjelmistoprojektin läpivientiä On nivottu osaksi kurssin luentoja On pakollinen 2 Harjoitustyön

Lisätiedot

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE 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ätiedot

Tik Harjoitustyö

Tik Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyön uusi aikataulu Ti 12.3 Kurssin aloitus Harjoitustyön läpikäynti To 14.3 Ti 19.3 Projektin synty Projektisuunnitelma Ryhmien muodostuminen To 21.3 Ti 26.3 To 4.4 Ti

Lisätiedot

Project group Tete Work-time Attendance Software

Project 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ätiedot

Työn ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework

Työ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ätiedot

Internet-pohjainen ryhmätyöympäristö

Internet-pohjainen ryhmätyöympäristö Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6

Lisätiedot

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x

Lisätiedot

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen

Lisätiedot

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-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ätiedot

Mökkivarausjärjestelm

Mökkivarausjärjestelm Mökkivarausjärjestelmä Mökkivarausjärjestelm Projektin loppuraportti R1VP Loppuraportti 2(8) Versiohistoria Versio Päivä Laatija(t) Hyväksyjä Voimassaoloaika 1 25.5.2018 Heini Saastamoinen Ville Heiskanen

Lisätiedot

TIETOJENKÄSITTELYTIETEIDEN LAITOS

TIETOJENKÄ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ätiedot

KArkisto2-hanke - kokemuksia earkiston pilotoinnista Kuopiossa ja InterSystemsin Ensemblestä KanTa-liityntäpisteenä

KArkisto2-hanke - kokemuksia earkiston pilotoinnista Kuopiossa ja InterSystemsin Ensemblestä KanTa-liityntäpisteenä KArkisto2-hanke - kokemuksia earkiston pilotoinnista Kuopiossa ja InterSystemsin Ensemblestä KanTa-liityntäpisteenä 7.5.2013 Mauri Kaatrasalo Heikki Koivulehto Julkaisuhistoria Versio Päivä Laatija(t)

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

File [Otsikko] 2014-02-26 40212. Projektisuunnitelma. SPT2014 Selvitysprojekti projektihallinnan työkaluista

File [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ätiedot

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset

Lisätiedot

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna

Mittaaminen 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ätiedot

Kurssin tavoitteista uennot. 4.1 Projektityö, 5 ov. Esitietovaatimukset

Kurssin 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ätiedot

Yhteenvetodokumentti. PLAYOFF Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki. Päivi Pääkkö, ohjaaja

Yhteenvetodokumentti. PLAYOFF Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki. Päivi Pääkkö, ohjaaja Yhteenvetodokumentti Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki Päivi Pääkkö, ohjaaja Helsinki, 13. joulukuuta 2007 Ohjelmistotuotantoprojekti yritysviestinnän oppimateriaalin

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 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ätiedot

Määrittely- ja suunnittelumenetelmät

Mää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ätiedot

TYÖOHJEET VR-HYVINKÄÄ

TYÖOHJEET VR-HYVINKÄÄ TEEMU JAUHIAINEN, JONI NORDSTRÖM TYÖOHJEET VR-HYVINKÄÄ Metropolia Ammattikorkeakoulu KONE- JA TUOTANTOTEKNIIKKA Projektisuunnitelma 19.3.2014 Sisällys Lyhenteet 1 Johdanto 1 2 Projektin tavoitteet 1 3

Lisätiedot

COTOOL dokumentaatio Testausdokumentit

COTOOL dokumentaatio Testausdokumentit Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................

Lisätiedot

Projektisuunnitelma Viulu

Projektisuunnitelma Viulu Projektisuunnitelma Viulu Kuusela Johannes Sjöblom Teemu Suominen Osma Ohjelmistotuotantoprojekti Helsinki 23.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Versiohistoria Päivämäärä Versio

Lisätiedot

T Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki

T Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki T-76.612 Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki Osa 1 - Ongelmat McConnellin (1996) luokittelun mukaisesti: Ihmiset Prosessi Tuote Teknologia Osa

Lisätiedot

Projektin suunnittelu

Projektin 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ätiedot

T Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005

T 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ätiedot

Projektisuunnitelma Kuopio

Projektisuunnitelma Kuopio Projektisuunnitelma Kuopio Kuopio, Projektisuunnitelma, 12.2.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 13.10.2001 Ossi Jokinen 0.2 25.10.2001 Ossi Jokinen Sisäisen katselmoinnin korjaukset.

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmä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ätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Ohjelmistotuotteen hallinnasta

Ohjelmistotuotteen 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ätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant

Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant Keravan kaupungin tietotekniikan palvelukeskus Henkilöstö: noin 30 hlö Asiakkaat: Järvenpään, Keravan ja Mäntsälän kunnat Työasemia: noin

Lisätiedot

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA PROJEKTITOIMINNAN ONGELMIA Kaikkea mahdollista nimitetään projekteiksi Projekti annetaan henkilöille muiden töiden ohella Ei osata käyttää

Lisätiedot