Projektiryhmä Tete:n riskienhallintaryhmä. Kokemuksia riskienhallintakäytännöistä
|
|
- Maria Aho
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Projektiryhmä Tete:n riskienhallintaryhmä
2 T Tietojenkäsittelyopin ohjelmatyö/ 2(8) Muutoshistoria Versio PVM Tekijä Kuvaus Mika Lindroos Ensimmäinen versio dokumentista riskienhallintasuunnitelman pohjalta Mika Lindroos Toinen versio dokumentista I2-vaiheen kokemusten perusteella Mika Lindroos Kolmas versio dokumentista I3-vaiheen kokemusten perusteella.
3 T Tietojenkäsittelyopin ohjelmatyö/ 3(8) Sisällysluettelo Muutoshistoria... 2 Sisällysluettelo Johdanto Riskienhallintakäytännöt Kokemuksia riskienhallinnasta I1-vaihe I2-vaihe I3-vaihe... 7 Viitteet... 8 Liitteet... 8
4 T Tietojenkäsittelyopin ohjelmatyö/ 4(8) 1 Johdanto Tämä dokumentti on kirjoitettu kurssia T Ohjelmistotuotannon erikoiskurssi: Riskienhallinta varten. Tässä dokumentissa kuvataan T Tietojenkäsittelyopin ohjelmatyö-kurssin projektiryhmä Teten projektin aikana käytettyjä riskienhallintakäytäntöjä ja kokemuksia niiden käytöstä. Projektin riskienhallinnan tarkoituksena on tunnistaa ja ennen kaikkea varautua projektin aikana mahdollisesti ilmeneviin ongelmiin. Tunnistamalla mahdolliset ongelmat eli riskit hyvissä ajoin on niihin mahdollista myös varautua hyvissä ajoin. Tällöin ongelmat voidaan mahdollisesti välttää kokonaan tai ainakin niiden vaikutusta voidaan pienentää. Varautumalla riskeihin jo ennakkoon vältytään toivon mukaan siltä, että kaikki aika menisi havaittuihin ongelmiin reagoimisessa, eikä varsinaisessa tavoitteellisessa kehitystyössä. 2 Riskienhallintakäytännöt Riskienhallinnasta yleisellä tasolla projektissa vastaa Mika Lindroos yhdessä muun riskienhallintaryhmän kanssa. Tähän ryhmään kuuluvat lisäksi Niilo Fredrikson, Tuomas Heino ja Marc Josefsson. Lisäksi yksittäisille havaituille riskeille on nimetty vastuuhenkilöt siten, että jokaisesta riskistä vastaa henkilö, jonka vastuualueeseen riski kuuluu. Riskienhallinnassa sovelletaan Riskit-menetelmää riskien identifioinnissa ja Riskit Paretoluokittelumenetelmää[1] niiden priorisoinnissa. Riskejä hallitaan riskienhallintaryhmän toimesta erillisissä kokouksissa. Näitä kokouksia pyritään järjestämään säännöllisesti kerran kuukaudessa (vastaa keskimäärin yhtä kertaa iteraatiota kohden). Tarpeen vaatiessa myös kuka tahansa muu ryhmäläinen, ryhmän asiakas tai ryhmän mentor voivat kutsua riskienhallintaryhmän koolle. Kokouksissa käydään läpi projektin ja seurannassa olevien riskien tila. Lisäksi käydään läpi onko tullut esiin uusia riskejä tai uusia tekijöitä, jotka vaikuttaisivat vanhoihin jo seurannassa oleviin riskeihin. Riskienhallinnalla pyritään seuraamaan projektin suorittamisen kannalta merkittäviä riskejä. Riskien hallinnassa mukana olevat riskit on valittu siten, että niiden todennäköisyys tai kriittisyys on merkittävä. Hyvin epätodennäköiset tai merkityksettömät riskit on jätetty kokonaan systemaattisen tarkkailun ulkopuolelle, koska näihin varautuminen voisi viedä huomattavan määrän resursseja verrattuna saavutettavaan hyötyyn. Ensimmäisessä vaiheessa on keskityttiin tunnistamaan mahdollisimman suuri määrä projektiin liittyviä riskejä. Riskienhallintaryhmä kokoontui ensimmäisen toteutusvaiheen (I1) aikana analysoimaan tunnistettuja riskejä ja luokitteli ne prioriteetin mukaan. Tunnistettujen riskien osalta käytiin myös läpi ovatko ne jo jollain tasolla toteutuneet ja riskiryhmän ennuste siitä, mihin suuntaan riskin prioriteetti on kehittymässä tulevaisuudessa. Prioriteetin kehittymiseen suuntaan tai toiseen vaikutti sekä riskin todennäköisyyden että riskin realisoitumisesta aiheutuvan vahingon muuttuminen ajan kuluessa. I2-vaiheen aikana riskienhallintaryhmä kokoontui jälleen käymään läpi projektin läpivientiin liittyviä riskejä. Riskejä identifioitaessa käytettiin hyödyksi projektin aiemmissa vaiheissa tunnistettujen riskien listaa yhdistettynä lisääntyneeseen kokemukseen projektin kokonaisedistymisestä. Tämä lähestymistapa osoittautui erittäin toimivaksi ja ryhmä kykeni sekä identifioimaan uusia riskejä että toteamaan joitakin vanhoja riskejä epärelevanteiksi tässä vaiheessa projektia. Tarkempaa analyysia riskienhallinan tuloksista seuraavassa kappaleessa. I3-vaiheen lopussa riskiryhmä toimi riskienhallintatoimenpiteiden suhteen lähes identtisesti I2-vaiheeseen verrattuna. Hyväksi havaittua menetelemää riskien identifioinnista ja seurannasta vanhojen riskien pohjalta
5 T Tietojenkäsittelyopin ohjelmatyö/ 5(8) hyödynettin myös tässä vaiheessa. Merkittävin havainto oli se, että tässä vaiheessa projektia suuria muutoksia itse projektiin ei enää tullut ja tämä puolestaa auttoi merkittävästi myös riskienhallinnasta. On huomattavasti helpompi käsitellä projektin riskejä suhteellisen staattisessa ympäristössä kuin nopeasti muuttuvien vaatimusten ja muiden tekijöiden keskellä. Suurempia yllätyksiä ei tullut koko iteraation aikana, mutta tästä taas tarkemmin seuraavassa kappaleessa. Seuraava vaihe eli toimitusvaihe (DE) on samalla myös koko projektin viimeinen vaihe ja siten luonteeltaan varsin erilainen aiempiin vaiheisiin verrattuna. Sen lopussa ei ole enää niinkään merkittävää tunnistaa projektin uusia riskejä, koska koko projekti periaatteessa päättyy iteraation loppuun. Sen sijaan on hyvä käydä koko projektin aikana identifioidut riskit läpi ja tarkastella niiden kehitystä. Näiden avulla voidaan mahdollisesti parantaa kyseisten riskien hallintamenetelmiä tulevia projekteja varten ja toivottavasti välttää tässä projektissa toteutuneet riskit kokonaan vastaisuudessa. Mikäli toimitusvaiheen aikana kuitenkin ilmenee jotain yllättävää, voidaan riskienhallintaryhmä toki edelleen kutsua kokoon tarvittaessa. 3 Kokemuksia riskienhallinnasta 3.1 I1-vaihe Ryhmän tähänastiset kokemukset riskienhallinnasta ovat melko positiivisia, vaikka toki joitakin ongelmiakin on esiintynyt. Riskienhallinta on paikoitellen toiminut erittäin hyvin ja merkittäviä ongelmia on onnistuttu välttämään, mutta myös parannettavaa on löydetty kurssin aikana. Yksi suurimmista toistaiseksi ilmenneistä ongelmista olisi voitu todennäköisesti välttää tehokkaampien riskienhallintamenetelmien käytöllä. Tämä kyseinen ongelma esiintyi kuitenkin aivan kurssin alkupäässä ja riskienhallintakaan ei ollut kunnolla käynnistynyt, joten liian suurena epäonnistumisena tätäkään ei voi pitää. Tiivistettynä ongelma piti sisällään kehitysympäristön pystyttämiseen kuluneen arvioitua suuremman työmäärän, joka olisi ollut mahdollista välttää tarkemmalla ohjeistuksella ja huolellisemmalla ryhmän sisäisellä viestinnällä. Tämä ongelma käytiin jälkikäteen läpi ja parannettiin toimintatapoja ohjeistuksen osalta myöhempiä tilanteita varten. Tämän jälkeen ohjeistus onkin toiminut huomattavasti paremmin ja vastaavia ongelmia ei ole kohdattu. Yhtenä merkittävä riskienhallinan osana voidaankin pitää toteutuneiden ongelmien tiedostamista ja niiden toistumisen ehkäisemistä tulevaisuudessa. Yhtenä riskienhallinan suurimmista menestyksistä toistaiseksi voidaan taas pitää testipalvelimen toimitukseen liittyneiden ongelmien käsittelyä. Lyhyenä yhteenvetona ongelmana oli asiakkaan lupaaman testipalvelimen toimituksen myöhästyminen sekä teknisten että logististen ongelmien takia. Tähän oltiin kuitenkin varauduttu riskienhallinan toimesta pystyttämällä jokaisen ryhmäläisen kotikoneelle täydellinen kehitysympäristö, jota voitiin käyttää myös testaustarkoituksiin. Tämän ansiosta ryhmä pystyi varsin tehokkaaseen työskentelyyn myös testipalvelimen viivästymisen aikana ja olisi hätätilassa kyennyt viemään jopa koko projektin läpi ilman kyseistä testipalvelinta. Nyt testipalvelin on kuitenkin täydessä toimintakunnossa ja siten riskienhallinnan voidaan todeta onnistuneen loistavasti kyseisen riskin käsittelyssä. Kaiken lisäksi ryhmäläisillä on ympäristöt kotikoneillaan edelleen käytössä, mikäli myöhemmässä vaiheessa testipalvelin aiheuttaisi vielä lisää ongelmia. Yhteenvetona ryhmän tähänastisista kokemuksista voisi todeta, että riskienhallinta on sopivassa mittakaavassa tehtynä hyödyllistä ja merkittävä osa projektin onnistumista. On tärkeää kiinnittää huomiota siihen, että käytettävät riskienhallintamentelmät ovat suhteessa projektin tarpeisiin. Ryhmämme projektissa ei ole kannattavaa käyttää kaikkein raskaimpia menetelmiä, koska kyseessä ei ole turvallisuuskriittinen järjestelmä ainakaan ihmishenkien tasolla. Käytössä olevat Riskit-menetelmät[1] ovat osoittautuneet varsin toimiviksi ja sopivaksi kompromissiksi mentelmän ilmaisuvoiman ja helppokäyttöisyyden suhteen. Riskien identifioinnissa brainstorming-tilaisuudet ovat osoittautuneet hyväksi menetelmäksi lukuisien ideoiden saamiseksi, mutta muutenkin olemme todenneet riskienhallinnan olevan tehokkaimmillaan ryhmässä. Erityisesti riskien vakavuuksien määrittämisessä tarvitaan useampi näkökulma, koska riskin merkitys saattaa vaihdella hyvinkin runsaasti riippuen siitä katsotaanko sitä esim. asiakkaan vai ryhmän näkökulmasta. Tässä
6 T Tietojenkäsittelyopin ohjelmatyö/ 6(8) priorisoinnissa käytetty Riskit Pareto menetelmä on mielestämme erittäin kätevä, koska se on riittävän helppokäyttöinen riskienhallintaryhmän käytettäväksi aktiivisesti ja lisäksi niin selkeä, että sen avulla voidaan kommunikoida myös asiakkaan suuntaan. Kaiken kaikkiaan luottamuksemme riskienhallintaa kohtaan on varsin hyvä tällä hetkellä, mutta jatkamme sen toimivuuden tarkkailua aktiivisesti ja teemme tarvittavia korjauksia projektin edetessä. 3.2 I2-vaihe I2-vaiheessa riskienhallinnassa jatkettiin samojen mentelmien käyttöä kuin aiemminkin ja niistä ei ole juurikaan uutta sanottavaa verrattuna edelliseen kappaleeseen. Riskien identifioinnissa käytettiin jonkin verran hyödyksi jo olemassa olevaa riskilistaa mm. uusien riskien identifioinnissa. Lisäksi vanhoja riskejä läpikäytäessä todettiin osan niistä muuttuneen projektin edetessä epärelevanteiksi ja osan olevan relevantteja vasta myöhemmässä vaiheessa projektia. Tämä vanhoihin riskeihin pohjautuva menetelmä vaikutti ainakin ensimmäisten kokemusten perusteella varsin hyvältä ratkaisulta ja tätä tultaneen käyttämään myös tulevissa vaiheissa. Seuraavaksi hieman tarkempaa läpikäyntiä riskien kehittymisestä I2-vaiheen aikana. Riskienhallinan helpottamiseksi käytiin identifioidut riskit huolella läpi epärelevanttien riskien löytämiseksi joukosta. Tällaisiksi riskeiksi luokittelimme seuraavat riskit: kehitysympäristön pystyttäminen kaikille viivästyy tai epäonnistuu Tässä vaiheessa projektia kehitysympäristö on jokaisella ryhmäläisellä käytössä ja lisäksi yhteinen testipalvelin on saatu toimintakuntoon. Näin ollen kyseinen riski ei ole enää ajankohtainen. testipalvelimen toimituksessa tulee ongelmia Testipalvelin on saatu täyteen toimintakuntoon ja ongelmia ei ole esiintynyt sen käytössäkään. Näin ollen testipalvelin voidaan katsoa toimitetuksi ja kyseinen riski on menettänyt merkityksensä. Mentorin aikatauluvaatimukset eivät sovi yhteen projektiyhmän kanssa Tässä vaiheessa projektia mentor-tapaamisten merkitys on muuttunut melko pieneksi ja näinollen jokaisen ryhmäläisen ei ole välttämätöntä päästä tapaamisiin, mikäli esteitä esiintyy. Lisäksi mentorin kanssa on löydetty yhteiset ajat hyvin helposti projektin aikaisemmissakin vaiheissa, joten tämän riskin käytännön merkitys oli muuttunut olemattoman pieneksi. Epärelevanttien riskien lisäksi totesimme muutaman riskin olevan ajankohtaisia vasta projektin myöhäisemmissä vaiheissa. Nämä riskit ovat: esiintyy yhteensopivuusongelmia kehitys- ja tuotantoympäristöjen välillä Vielä I3-iteraatiossa emme ole tekemisissä varsinaisen tuotantoympäristön kanssa, joten ainoat mahdolliset riskienhallintatoimenpiteet ovat yleistä yhteensopivuuden varmistamista koodi- ja järjestelmätasoilla. On mahdollista, että varsinaista tuotantoympäristöä ei saada käyttöön koko projektin aikana tai aikaisintaan toimitusvaiheen aikana. Tällöin riski on mahdollista ottaa uudelleen mukaan aktiivisempaan käsittelyyn. asiakkaan kanssa tulee sopimusoikeudellisia ongelmia Ryhmällä ei ole ollut ongelmia asiakkaan kanssa ja projektin ollessa jo tässä vaiheessa on asiakkaan vetäytyminen erittäin epätodennäköistä. Lisäksi kurssi olisi mahdollista viedä läpi tästä eteenpäin jo ilman asiakasta, joten tällä hetkellä sopimusongelmat eivät ole ajankohtaisia. On kuitenkin mahdollista, että projektin tuotosten oikeuksista syntyy epäselvyyttä projektin lopussa, joten siitä syystä tämä riski on syytä ottaa uudelleen lähempään tarkkailuun projektin loppupuolella. Riskienhallinan menestykseen I2-vaiheen aikana voidaan olla varsin tyytyväisiä. Useita potentiaalisia ongelmia, mutta tehokkailla riskienhallintatoimilla näistä aiheutuneet käytännön haitat onnistuttiin minimoimaan. Usean eri riskin osittaisesta toteutumisesta (mm. projektin jäsenen lyhytaikainen sairastuminen, joululoman aiheuttama ryhmän jäsenillä liian vähän aikaa käytettävissä kun tarvitaan ja tunteja ei ehditä tiukan kalenteriaikataulun takia käyttää) huolimatta projektin I2-vaihetta voidaan pitää aikaansaannosten valossa onnistuneena ja pysyneen budjetissa erittäin hyvin. Erityisen tehokkaana
7 T Tietojenkäsittelyopin ohjelmatyö/ 7(8) menetelmänä kyseisten aikatauluongelmien hallinnassa oli projektipäällikön käymät kehityskeskustelut kyseisten ryhmäläisten kanssa, joiden avulla onnistuttiin sovittamaan yhteen projektin tavoitteet ryhmäläisten aikataulujen kanssa suhteellisen onnistuneesti. Suurimpana havaittuna riskienhallinnan menestyksenä I2:ssa oli kuitenkin koulutuksen onnistuminen aikaisempien iteraatioiden aikana. Ryhmä käytti kohtuullisen suuren määrän työtunteja melko kattavan koulutuksen järjestämiseen ja tämä osoittautui kannattavaksi ratkaisuksi I2:sen aikana. Tämä koulutus yhdistettynä pariohjelmoinnin käyttöön projektin alkuvaiheessa tarjosi kokemattomammillekin ryhmän jäsenille erinomaisen keinon tutustua käytettäviin teknologioihin ja helpon sisäänpääsyn järjestelmän kehittämiseen. Näin ollen I2-vaiheessa useimmat ryhmäläiset kykenivät itsenäiseen järjestelmän kehittämiseen ja tätä voidaan pitää erittäin hyvänä suorituksena, ottaen huomioon käytettävien teknologioiden suurehkon määrän ja niiden tuntemattomuuden ryhmäläisten keskuudessa projektin alkaessa. 3.3 I3-vaihe I3-vaiheessa jatkettiin samojen riskienhallintamenetelmien käyttöä kuin projektin aikaisemmassakin vaiheessa. I2-vaiheessa hyväksi havaittu riskien identifiointi ja niiden seuranta olemassaolevien risien pohjalta jatkui I3-vaiheen aikana, eikä sen käytössä havaittu ongelmia tässäkään vaiheessa. I3-vaiheen aikana ei enää tunnistettu merkittäviä uusia riskejä, mutta muutaman vanhan riskin merkityksen todettiin jälleen muuttuneen. Näistä tarkemmin seuraavaksi. I3-vaiheen aikana merkittävät muutokset riskien tilassa: työasemien/työkalujen käyttö tuottaa ongelmia Tässä vaiheessa projektia käytetyt työkalut ovat jo niin tuttuja kaikille ryhmäläisille (tai ainakin omaan vastuualueeseen liittyviltä osiltaan), että tämän riskin todennäköisyys ja siten prioriteetti vähenivät entisestään. sähköpostiongelmat haittaavat viestintää Ryhmä käytti tiiviiden aikataulujen johdosta aiempaa enemmän puhelinta viestintään. Lisäksi sähköpostit ovat enimmäkseen toimineet hyvin viime aikoina. Ainoastaan asiakkaan suuntaan on ollut sähköpostiongelmia. Tästä syystä riskin todennäköisyyttä pienennettiin vähän. järjestelmän käyttö hankaloituu mahdollisten tietoliikenneongelmien ilmentyessä Tämä riski lisättiin uutena seurantaan, koska erityisesti iteraation lopussa tapahtuvassa demossa tämän merkitys voi olla varsin suuri. Mikäli demossa ilmenee tietoliikenneongelmia, voi tämä antaa täysin väärän kuvan itse ohjelman suorituskyvystä. Tämä riski on merkittävä ennenkaikkea viimeisessä iteraatiossa, koska palautusiteraation loppudemon tarkoituksena on esitellä käytännössä koko projektin lopputuloksena syntynyt ohjelmisto. ryhmän jäsenillä on liian vähän aikaa käytettävissä projektiin silloin kun tarvitaan Tämän riskin vahinkoa ja siten prioriteettia pienennettiin hieman. Tämä johtuu lähinnä siitä, että projektin ollessa jo näin pitkällä, ei yksittäisen ryhmäläisen panos enää ole yhtä kriittinen kuin aiemmin. Suurin osa ryhmäläisistä on jo käyttänyt merkittävän osan kokonaistyömäärästään ja siten loppuosan käyttämättä jääminen ei olisi kuin muutaman tunnin menettäminen projektin kokonaistyömäärästä. vaatimukset muuttuvat merkittävästi projektin aikana Tämän riskin todennäköisyyttä pienennettiin, koska asiakas tuntuu hyvin ymmärtäneen projektin olevan loppusuoralla ja siten keskitytään lähinnä nykyisten ominaisuuksien hiomiseen, eikä enää uusien vaatimusten toteuttamiseen. ryhmäläisten osaaminen ole ei riittävän korkealla tasolla kaikkien käytettävien tekniikoiden ja työkalujen osalta, ryhmän jäsenten erilainen kokemustausta ja osaaminen voi aiheuttaa ongelmia Tämän riskin todennäköisyyttä ja sen myötä myös prioriteettia pienennettiin, koska ryhmäläiset ovat perehtyneet projektin edetessä käytettäviin tekniikoihin, eivätkä ne siten ole enää uusia ja tuntemattomia kuten projektin alkupuolella. Toki vaikeammissa asioissa edelleen kaivataan kokeneempien ohjeistusta, mutta perusominaisuudet ovat jo lähes kaikilla hallussa.
8 T Tietojenkäsittelyopin ohjelmatyö/ 8(8) projektipäällikkö joudutaan vaihtamaan projektin aikana Tämän riskin vahinkoa ja prioriteettia pienennettiin. Myös projektipäällikkö on tässä vaiheessa projektia käyttänyt suurimman osan työmäärästään ja jäljellä olevan työn voisi tarvittaessa hoitaa myös joku muu ryhmäläinen. On kuitenkin huomioitava, että asiakas on tottunut kommunikoimaan projektipäällikön kanssa ja siten projektipäällikön vaihtuminen toki hankaloittaisi ryhmän toimintaa jonkin verran. I3-vaiheessa riskienhallinnan voidaan katsoa onnistuneen myös varsin hyvin. Tästä ehkä parhaimpana todisteena se, että riskienhallinnasta ei ole juurikaan uutta kerrottavaa enää tässä vaiheessa. Se toimi suhteellisen näkymättömissä, mutta ilmeisen tehokkaasti, sillä projektiin ei tullut odottamattomia muutoksia. Tarkemmin sanottuna projektiin ei itse asiassa tullut ylipäätänsä suurempia muutoksia. Tätä voidaan pitää hyvän projektin- ja riskienhallinnan merkkinä, sillä tietyssä määrin olisi syytä olla huolissaan, jos projektiin tulisi kovin merkittäviä muutoksia vain pari viikkoa ennen sen päättymistä. Jos joitain merkittävimpiä riskienhallintamenetelmiä kuitenkin halutaan huomioida niin esille nousevat lähes samat asiat kuin I2- vaiheessakin. Aikatauluongelmien välttämiseksi projektipäällikkö selvitti henkilökohtaisesti loppuprojektin työmäärien jakautumista sellaisten ryhmäläisten kanssa, joilla on vielä merkittävä osa työtunneista käyttämättä. Asiakkaan tyytyväisyyden takaamiseksi puolestaan järjestettiin asiakkaan organisaatiossa tapahtuvaa järjestelmän testausta, jota jatketaan myös projektin viimeisen vaiheen aikana. Lisäksi tässä iteraatiossa oli jälleen jonkin verran sähköpostiongelmia asiakkaan suuntaan, mutta tästä selvittiin projektipäällikön hoitaessa yhteydet asiakkaaseen tarvittaessa puhelimen välityksellä. Sen sijaan ryhmäläisten osaamistasosta ei enää tässä vaiheessa olla kovinkaan huolissaan kun suurin osa toiminnallisuutta on jo saatu toteutettua ja jäljellä on enää vain viimeinen hiominen. Viitteet [1] Risk Management T luentokalvot, s.14, Jyrki Kontio, viitattu , Liitteet
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ä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ätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Software project 2(5) Muutosloki
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Versionhallinta BitKeeper-työkalun avulla Tuomas Heino Muutosloki Versio Pvm Tekijä Kuvaus 1.0 01.12.2003
LisätiedotDigi-tv vastaanottimella toteutetut interaktiiviset sovellukset. Riskienhallinta DTV projektissa
Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Riskienhallinta DTV projektissa Riskienhallinta DTV projektissa Sivu 1/8 Sisällysluettelo 1. Riskienhallinta DTV projektissa...3 1.1. Projektin
LisätiedotPS-vaiheen edistymisraportti Kuopio
PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun
LisätiedotRaitiotieallianssin riskienhallintamenettelyt
Riskienhallintamenettelyt 1 (7) Raitiotieallianssin riskienhallintamenettelyt Riskienhallintamenettelyt 2 (7) SISÄLTÖ 1 PERIAATTEET JA TAVOITTEET... 3 2 ORGANISOINTI JA VASTUUT... 4 3 RISKIENHALLINTAPROSESSI...
LisätiedotMenetelmäraportti Riskienhallinta
Menetelmäraportti Riskienhallinta Sisällysluettelo 1. Johdanto...3 1.1. Lähteet ja viitteet...3 2. Dtv projektin Riskienhallintasuunnitelma...4 2.1. Projektin kuvaus...4 2.2. Riskienhallinnan tavoitteet...4
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ä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ä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ätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
Edistymisraportti v. T4 (Toteutus 4) Päivitetty 15.3.2001 klo 18:13 2 (8) Sisällys 1 PROJEKTIN TILA...3 2 SUORITETUT TEHTÄVÄT...6 3 KÄYTETYT MENETELMÄT...7 4 ONGELMAT...8 EDISTYMISRAPORTTI 2 3 (8) 1. Projektin
Lisä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ätiedotProject group Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: etenemisraportti
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Pariohjelmointi Mika Lindroos T-76.115 Software project 2(6) Muutosloki Versio Pvm Tekijä Kuvaus 1.0 28.11.2003
LisätiedotT Tietojenkäsittelyopin ohjelmatyö
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Dokumentissa on kuvattu Keimo-projektin riskienhallintasuunnitelma ja kulloinkin tunnistetut riskit. Dokumenttia päivitetään jokaiseen palautukseen. Päivämäärä
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotHELSINGIN KAUPUNKI TOIMINTAOHJE 1/7 LIIKENNELIIKELAITOS Yhteiset Palvelut / Turvallisuuspalvelut K. Kalmari / Y. Judström 18.9.
1/7 Avainsanat: riskienhallinta, vaarojen tunnistaminen, riskien estimointi, vaararekisteri HKL:n metro ja raitiotieliikenteen riskienhallinnan toimintaohje 1 Riskienhallinta Helsingin kaupungin liikenneliikelaitoksessa.
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ä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ätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
Lisä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ätiedotIPT-työpaja # Kysely kehitys- ja toteutusvaiheissa oleville hankkeille
IPT-työpaja #7 15-16.3 Kysely kehitys- ja toteutusvaiheissa oleville hankkeille Kyselytutkimus Tilaajan / käyttäjien edustajat 5 vastaajaa, joista: 5 APR:n jäsentä 2 projektipäällikköä 7 vastaajaa, joista:
LisätiedotT Tietojenkäsittelyopin ohjelmatyö
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Dokumentissa on kuvattu Keimo-projektin riskienhallintasuunnitelma ja kulloinkin tunnistetut riskit. Dokumenttia päivitetään jokaiseen palautukseen. Päivämäärä
Lisätiedot0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005
Lisä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ätiedotA13-03 Kaksisuuntainen akkujen tasauskortti. Projektisuunnitelma. Automaatio- ja systeemitekniikan projektityöt AS-0.
A13-03 Kaksisuuntainen akkujen tasauskortti Projektisuunnitelma Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Syksy 2013 Arto Mikola Aku Kyyhkynen 25.9.2013 Sisällysluettelo Sisällysluettelo...
LisätiedotTik-76.612 Ohjelmistotuoteliiketoiminta
Tik-76.612 Ohjelmistotuoteliiketoiminta Luennot ja projekti synty suunnittelu käynnistys ohjaus päätös operointi Ti 12.3 To 14.3 Ti 19.3 To 21.3 Ti 26.3 To 4.4 Ti 9.4 To 11.4 Ti 16.4 Ti 18.4 To 23.4 Kurssin
LisätiedotToteutusvaihe T2 Edistymisraportti
Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria
LisätiedotT 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ä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ätiedotTYÖ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ätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
LisätiedotCOTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria...........................................................................
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ätiedotVersionhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä Versionhallintasuunnitelma Muutoshistoria Version Date Author Description 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja 0.20 19.10.2003 Tuomas Heino 0.21
LisätiedotHarjoitus 3 Case Face Wash. Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja
Harjoitus 3 Case Face Wash Raine Mäki, Laura Takkinen, Marika Östman, Otto Kataja Tunnistettuja ongelmia Katastrofaaliset ongelmat Kommunikointi Projektisuunnitelman puuttuminen Projektia ei aikataulutettu
Lisä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ä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ätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan
LisätiedotHaastattelu. Lista kysymyksistä joita voit käyttää keskustelun tukena:
Haastattelu Lista kysymyksistä joita voit käyttää keskustelun tukena: Mitä haluaisit että asiakas sanoo sinulle kun hän lähtee tästä yhteisöstä/muuttaa pois kotoa? Mitä toivot että asiakas kertoo sinusta
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ätiedotCase Tampere3: PMO:n rooli organisaatioiden yhdistyessä
Case Tampere3: PMO:n rooli organisaatioiden yhdistyessä Kirsi Vikström, Erikoissuunnittelija, Tietohallinto, ICT-tuotanto ja kehityspalvelut Projektipäällikkö, Tampere3 PMOn käynnistäjä Tampereen Ammattikorkeakoulu
LisätiedotFigure 1: Projektipäälliköt Juha-Pekka Honkavaara ja Juha Mattila
1 Käytettävyysryhmä 1.1 Yleistä Tämän vuoden käytettävyystiimi (Uteam) perustuu kahden viime vuoden pohjalle. Uteam oli toiminnassa ensimmäisen kerran siis lukuvuonna 2005-2006. Uteamin projektiryhmä koostui
LisätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
Lisä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ätiedotElectric power steering
AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Electric power steering Ohjausmoottorin jäähdytys ja ylikuumenemisen esto Projektisuunnitelma 19.9.2014 Työn ohjaaja: Ville Matikainen Tekijät: Samppa
LisätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: 26.10.2004 Projekti : AgileElephant Versio: V0.9
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 6 Dokumentti Historia Revisio Historia Revision päiväys: 26.10.2004
LisätiedotInternet-pohjainen ryhmätyöympäristö
Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6
LisätiedotKuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
LisätiedotS14 09 Sisäpeltorobotti AS Automaatio ja systeemitekniikan projektityöt. Antti Kulpakko, Mikko Ikonen
S14 09 Sisäpeltorobotti AS 0.3200 Automaatio ja systeemitekniikan projektityöt Antti Kulpakko, Mikko Ikonen 1. Projektin tavoitteet Projektin tavoitteena on toteuttaa ohjelmisto sisäpeltorobottiin seuraavien
LisätiedotKYSELY MUISTIHÄIRIÖPOTILAAN LÄHEISELLE
KYSELY MUISTIHÄIRIÖPOTILAAN LÄHEISELLE Suomen Alzheimer-tutkimusseura ja muistitutkimusyksiköiden asiantuntijaryhmä Kustantaja: Novartis Oy otilaan ja omaisen huolellinen haastattelu on tärkeä osa muistihäiriöpotilaan
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ätiedotYhteenvetodokumentti. Boa Open Access. Helsinki 5.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Yhteenvetodokumentti Boa Open Access Helsinki 5.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotImage size: 7,94 cm x 25,4 cm. SKTY:N SYYSPÄIVÄT 21.10.2014, Lahti RISKIENHALLINTA. Eeva Rantanen Ramboll CM Oy
Image size: 7,94 cm x 25,4 cm SKTY:N SYYSPÄIVÄT 21.10.2014, Lahti RISKIENHALLINTA Eeva Rantanen Ramboll CM Oy RISKIENHALLINNASTA KRIISINHALLINTAAN Lähde: Varautuminen ja jatkuvuudenhallinta kunnassa. 2012
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ätiedotProjektisuunnitelma. Laitteiston ja kalusteiden hankinta, versio WEB MAGIA OY Laatija Oula Kangas
Projektisuunnitelma Laitteiston ja kalusteiden hankinta, versio 0.2 11.8. 2017 WEB MAGIA OY Laatija Oula Kangas Tämä dokumentti on luotu malliksi Tredun opiskelijoiden käyttöön Web Magia Oy Projektisuunnitelma
LisätiedotHaastattelurunko työpaikoille
Kallionpää P, Immonen J, Välimaa N, Herse F, Leskelä R-L. Työkyvyn hallinta, seuranta ja varhainen tuki. Tutkimus sairausvakuutuslain vuoden 2011 muutoksen vaikutuksista työpaikkojen toimintaan. Työpapereita
LisätiedotGumenius Sebastian, Miettinen Mika Moottoripyörän käynnistysalusta
Gumenius Sebastian, Miettinen Mika Moottoripyörän käynnistysalusta Metropolia Ammattikorkeakoulu Kone- ja tuotantotekniikka Projektisuunnitelma 23..204 Sisällys Lyhenteet Johdanto 2 Projektin tavoitteet
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ätiedotHajautettu Ohjelmistokehitys
Hajautettu Ohjelmistokehitys Maria Paasivaara Hajautuksen muotoja Yrityksen sisäinen hajautus Maan sisällä Maiden välillä, esim. offshore Yritysten välinen hajautus Alihankinta Lisenssointi Partnershipit
LisätiedotTutkimushankkeiden riskienhallinta
Tutkimushankkeiden riskienhallinta Tutkimuksen tuki, yrittäjyys ja innovaatiot Jyväskylän yliopisto Kirsi Murtosaari Parityö Tutkimushankkeet: Kuvatkaa hankkeiden haasteita suunnittelu- ja toteutus- tai
LisätiedotSuorituskyky- ja riskiperusteinen toimintamalli Liikenteen turvallisuusvirastossa
Suorituskyky- ja riskiperusteinen toimintamalli Liikenteen turvallisuusvirastossa 17.9.2015 Vastuullinen liikenne. Rohkeasti yhdessä. Suorituskyky- ja riskiperusteisen toimintamallin tavoitteet Uusi viranomaisuus,
LisätiedotTietojärjestelmän kehittäminen syksy 2003
Tietojärjestelmän kehittäminen syksy 2003 Ryhmä C2 Väliraportti 2-24.10. Päivi Laiterla Tomas Windahl Toni Nikkanen Antti Lehto 1 Sisällysluettelo Rich Picture...4 Käsitemalli...5 P-tason
LisätiedotJunien peruuntumistodennäköisyyksien hyödyntäminen veturinkuljettajien työvuoroluetteloiden suunnittelussa Väliraportti
MS-E2177 Operaatiotutkimuksen projektityöseminaari Junien peruuntumistodennäköisyyksien hyödyntäminen veturinkuljettajien työvuoroluetteloiden suunnittelussa Väliraportti 19.4.2017 Tapio Hautamäki, 345312
LisätiedotProCoach -kehitysohjelmat
ProCoach -kehitysohjelmat Työkalu kilpailukykyisen liiketoiminnan rakentamiseen Toimintaympäristö muuttuu jatkuvasti ja se näkyy yritysten asiakkailleen tarjoamien palvelujen määrän ja saatavuuden paranemisena,
LisätiedotTietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa
Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000
LisätiedotTestauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
LisätiedotESITUTKIMUS. Polku Versio 0.1. Projektiryhmä
ESITUTKIMUS Polku Versio 0.1 Projektiryhmä Janne Pihlajaniemi janne.pihlajaniemi@iki.fi Antti Jämsén antti.jamsen@uta.fi Maria Hartikainen maria.hartikainen@uta.fi Pekka Kallioniemi pekka.kallioniemi@uta.fi
LisätiedotTotuus IdM-projekteista
Totuus IdM-projekteista Kyselytutkimuksen tulosten julkistustilaisuus 4.10.2011 Hannu Kasanen, Secproof Identiteetinhallinnan huono maine IAM, nuo kolme suurta kirjainta, tarkoittavat käyttäjätietojen-
LisätiedotRahastosalkun faktorimallin rakentaminen
Teknillinen korkeakoulu Mat 2.177 Operaatiotutkimuksen projektityöseminaari Kevät 2007 Evli Pankki Oyj Väliraportti 28.3.2007 Kristian Nikinmaa Markus Ehrnrooth Matti Ollila Richard Nordström Ville Niskanen
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ätiedotAloite Onko asioiden esittämistapa riittävän selkeä ja kieleltään ymmärrettävä?
Aloite 08.02.2017 1 (3) VVC VM036:00/2015 Lausunto luonnoksesta valtion riskienhallintopolitiikkamalliksi Yleistä Onko aineistokokonaisuus, jossa on riskienhallinnan järjestämistä koskevia ohjeita,
Lisätiedot3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista?
3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien
LisätiedotKOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1
KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1 TYÖRYHMÄN NIMI: SUUNTA Laajasalon tiimi (Itäinen perhekeskus, Helsinki) pvm: jolloin täytetty työryhmän kanssa KEHITTÄMISTEHTÄVÄN NIMI 1) Asiakassuunnitelman
LisätiedotT Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (9)
T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (9) T-76.115 Riskienhallintadokumentti ExtraTerrestriaLs Versio Pvm Tekijä Kuvaus 0.1 Mika Suvanto Alustava versio 0.9.10.2004 Mika Suvanto
LisätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
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ätiedotAQAP:n SOVELTAMINEN. Ohjelmistoalan yrityksessä. Timo Salo Manager, Operational Excellence
AQAP:n SOVELTAMINEN Ohjelmistoalan yrityksessä Timo Salo Manager, Operational Excellence timo.salo@combitech.fi Combitech Oy Combitech Oy on Saab konserniin kuuluvan Combitech Ab:n tytäryhtiö Henkilömäärä
LisätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on jatkuvasti ajan tasalla pidettävä dokumentti johon luetellaan tiedostetut ongelmat ja niiden käsittelytilanne. Päivämäärä 8.2.2003 Projektiryhmä
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ätiedotGoogle AdWords. mainonta tehokäyttöön
Google AdWords mainonta tehokäyttöön Opi tekemään hakukonemainontaa kuin ammattilaiset. Opas antaa sinulle vinkkejä, kuinka vältät sudenkuopat ja säästät mainoseurojasi sekä kuinka tavoitat asiakkaasi
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
LisätiedotOhje riskien arvioinnin työkalun käyttämiseksi
Riskien arvioinnin työkalu ohjelmapalveluiden tuottajille Ohje riskien arvioinnin työkalun käyttämiseksi Tämä riskien arvioinnin työkalu on tarkoitettu matkailualan ohjelmapalveluja tarjoaville yrityksille.
LisätiedotKeskiössä asiakas palvelumuotoilu vapaassa sivistystyössä
Keskiössä asiakas palvelumuotoilu vapaassa sivistystyössä Valtakunnalliset vapaan sivistystyön päivät / Keskustelufoorumi FT, palvelumuotoilun kouluttaja Marjo Kamila Palvelumuotoilu on A. Asenne! B. Prosessi,
LisätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö. Projektin loppuraportti. Tietokonegrafiikka-algoritmien visualisointi. Projektin loppuraportti
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä dokumentti sisältää kuvauksen projektin viimeisen, eli viidennen vaiheen etenemisestä, suoritetuista tehtävistä ja kohdatuista ongelmista. Lisäksi
LisätiedotProffa ilmoittautumisen profiloija
Proffa ilmoittautumisen profiloija Projektisuunnitelma Leila Juusola Ilari Moilanen Jyrki Salonen Olli Sinerma Hanna Sirola Helsinki 2.2.2005 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN
LisätiedotKunnallisen toiminnan periaatteet, määritelty ja toimitaanko niiden mukaisesti? 3 strategialähtöiset
Laukaan kunta/ tekninen osasto e Ei sovellettavissa 2016 1 Välttävästi 2 Tyydyttävästi 3 Hyvin Sisäisen valvonnan ja riskienhallinnan arviointimalli 4 Erinomaisesti Johtamistapa ja valvontakulttuuri Arvio
LisätiedotUudenmaan maakunnan toiminnan ja hallinnon käynnistämisen riskiarvio Tiivistelmä
Uudenmaan maakunnan toiminnan ja hallinnon käynnistämisen riskiarvio Tiivistelmä 21.8.2017 Tausta Projektin tavoitteena oli kartoittaa Uudenmaan maakunnan toiminnan käynnistämiseen liittyvät riskit valituilla
LisätiedotSatunnaisalgoritmit. Topi Paavilainen. Laskennan teorian opintopiiri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Satunnaisalgoritmit Topi Paavilainen Laskennan teorian opintopiiri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Helsinki, 23. helmikuuta 2014 1 Johdanto Satunnaisalgoritmit ovat algoritmeja, joiden
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ätiedotSALON SEUDUN KOULUTUSKUNTAYHTYMÄN SISÄISEN VALVONNAN JA RISKIENHALLINNAN PERUSTEET
SALON SEUDUN KOULUTUSKUNTAYHTYMÄN SISÄISEN VALVONNAN JA RISKIENHALLINNAN PERUSTEET Hall. 01.04.2014 Valt. 29.04.2014 1 Voimaantulo 01.07.2014 1 Lainsäädännöllinen perusta ja soveltamisala Kuntalain 13
LisätiedotHuippuyksiköiden taloudelliset vastuut ja velvollisuudet
Huippuyksiköiden taloudelliset vastuut ja velvollisuudet Huippuyksikköseminaari 14.12.2011 Sisäinen tarkastaja Seija Henttinen Sisäinen valvonta tarkoittaa TOIMINTAPROSESSEIHIN SISÄÄN VIETYJÄ RAKENTEITA,
LisätiedotGood Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
LisätiedotMat Operaatiotutkimuksen projektityöseminaari Viestiverkon toimintaluotettavuuden arviointi Väliraportti
Mat 2.177 Operaatiotutkimuksen projektityöseminaari Viestiverkon toimintaluotettavuuden arviointi Väliraportti 31.3.2006 Kohdeorganisaatio: Yhteyshenkilö: Ryhmä: Puolustusvoimien Teknillinen Tutkimuslaitos
LisätiedotTurvallisuuden kehittämishanke Hakarinteen peruskoulussa
Turvallisuuden kehittämishanke Hakarinteen peruskoulussa Anis, Daniel Piirainen, Ilkka 2011 Leppävaara 2 Laurea-ammattikorkeakoulu Leppävaara Johdanto opinnäytetyöhön ja yhteenveto Anis, Daniel. Piirainen,
LisätiedotToimitusketjun riskienhallinta konsernissa
Oy Lappeenrannan teknillinen yliopisto..0 Toimitusketjun riskienhallinta konsernissa Tapani Toppi, Espoo www.marsh.fi Mistä mielenkiintoa toimitusketjun riskienhallintaan? Hyvät syyt työn tekemiseen Sopiva
LisätiedotMiten tehdä onnistunut projektisuunnitelma 10 vinkkiä
Miten tehdä onnistunut projektisuunnitelma 10 vinkkiä Consultor Finland Oy Aluksi Suunnitelmien tekeminen on meille jokaiselle arkipäivää. Suunnitelmiin voi kuulua ostoksille menoa, illallista ja television
Lisätiedot