Projektityö 14.9.2012 Ryhmässä työskentely Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Riskit ja riskien hallinta Eettiset ohjeet Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: timo.t.poranen@uta.fi, työhuone: B1023) Kurssin kotisivut: https://projectwiki.cs.uta.fi/ 1
Ryhmän kehitysvaiheet Tutkijoiden mukaan: Ryhmien kehitysvaiheet tulevat esiin kaikissa ryhmissä, teoreettiset mallit kuitenkin yleistyksiä. Tuckman (1965) ja Tuckman and Jensen (1977) Ryhmän muodostumisvaihe (Forming) Ryhmän kuohuntavaihe (Storming) Ryhmän vakiintumisvaihe (Norming) Kypsän toiminnan vaihe (Performing) Ryhmän lopetusvaihe (Adjourning) http://www.cs.uta.fi/reports/dsarja/d-2007-12.pdf Ryhmän ohjaajalla on keskeinen rooli erityisesti projektin alussa. Kun ryhmän yhteiset toimintatavat ja tavoitteet ovat kaikille selviä, alkaa ryhmä toimia enemmän itseohjautuvasti. 2
Hyvän ryhmähengen luominen Luokka jaetaa kahteen osaan (etuosa, takaosa). Muodostakaa eri osissa 2-3 hengen ryhmiä. Etuosa: miten yksittäinen ryhmän jäsen (myös projektipäällikkö) voi edesauttaa hyvän ryhmähengen syntymistä? Takaosa: miten yksittäinen ryhmän jäsen (myös projektipäällikkö) voi pilata / estää hyvän ryhmähengen syntymisen? Kirjoittakaa havaintonne paperille. Aikaa on käytössä 10 minuuttia. Ei nimiä papereihin. Yhteenveto julkaistaan kurssin kotisivulla! Voitte kirjoittakaa myös englanniksi. 3
Kuinka ratkaista ongelmia? Kts. esim. Polya, G. How to solve it. Yleinen tapa ratkaista erilaisia ongelmia: Onko olemassa mitään ongelmaa? Määrittele ongelma täsmällisesti Suunnittele ongelman ratkaisu Toteuta ongelman ratkaisu Testaa, oliko ratkaisu oikea Ylläpidä toteutettua ratkaisua 4
Vesiputousmalli ohjelmistokehityksessä Sovelletaan yleistä ongelmanratkaisutapaa, Royce, W. (1970). Esitutkimus (Miksi ohjelma tulisi tehdä, onko se mahdollista/järkevää tehdä?) Vaatimusten määrittely (Miten ohjelman tulisi toimia?) Suunnittelu (suunnitellaan järjestelmä siten, että se täyttää vaatimukset) Toteutus (toteutetaan suunniteltu ratkaisu) Testaus (testataan, vastaako toteutus vaatimuksia) Ylläpito (ylläpidetään ohjelmistoa toiminnassa) Testausta yleensä jo toteutusvaiheessa. Saako palata takaisin edelliseen vaiheeseen? 5
Projektisuunnitelma Projektisuunnitelman tarkoituksena on kuvata, miten määritellyillä resursseilla päästään tietyn aikataulun puitteissa haluttuun lopputulokseen. Projektisuunnitelmassa kuvataan mm. projektiin liittyviä riskejä, tukitoimintoja, toteutusvälineitä, henkilöstö, tehtävät, aikataulu,... Projektin aikana projektisuunnitelma on projektin seurannan apuväline: sen avulla huomataan poikkeamat aikataulussa ja resurssien käytössä. Pystytään reagoimaan poikkeamiin välittömästi. Projektisuunnitelma elää koko projektin ajan. Sitä pitää päivittää. 6
Työn osittaminen Ohjelmistoprojektin suunnittelun ja toteuttamisen kannalta keskeisin tehtävä on projektin hierarkkinen osittaminen erillisiin osatehtäviin. Work Breakdown Structure. WBS tarjoaa seuraavat edut: Kertoo kaikki merkittävät työtehtävät. Mahdollistaa tehtävien jakamisen projektin jäsenille. Mahdollistaa aikataulutuksen, kustannusarviot ja projektin valvonnan. Ositustapoja: komponentit, toiminnot, projektin vaiheet, maantiede,... Tuotteen perusteella osittaminen ei mukaudu arkkitehtuurimuunnoksiin, joten ositus on usein parempi tehdä vaiheiden perusteella. 7
Lisää työnosituksesta Alimman tason tehtävät ovat yhdelle henkilölle osoitettavissa olevia selkeästi rajattuja työkokonaisuuksia. Työtehtäviin liittyy alkamisajankohta, päättymisajankohta, tekijät, käytettävä työpanos ja vaihetuotteet. Työtehtävä on valmis, kun sen vaihetuote on hyväksytty projektisuunnitelman määrittelemällä tavalla. Mitä pienempiin osiin tehtävien jaossa päästään, sitä luotettavampi työmääräarvio yleensä on. Pienet tehtävät mahdollistavat tehokkaan seurannan, sillä aikataulusta poikkeamat havaitaan nopeasti. Liian pienet tehtävät aiheuttavat kuitenkin byrokratiaa. WBS:n tarkkuus on kompromissi ohjattavuuden ja ohjauksen vaatiman työmäärän välillä. 8
Työn osituksen ongelmia Käytännössä kaikkia projektin tehtäviä ei voida tietää etukäteen. Yllättäviä tehtäviä saattaa olla esim. 20% projektin kaikista tehtävistä. Projektisuunnitelmaan on jätettävä riittävästi pelivaraa ennakoimattomien tehtävien ja yllätyksien varalle. Aikataulutusta varten on määritettävä tehtävien keskinäiset riippuvuudet (tehtävä x suoritettava ennen tehtävää y). Kriittisten tehtävien tunnistaminen ja projektin seuraamisen apuvälineet: erilaiset kaaviot (Gant, toimintokaavio), kalenteri, projektinhallintaohjelmistot,... 9
Projektisuunnitelma Projektisuunnitelma pohjautuu IEEE 1058 standardiin Dokumenttipohja: https://projectwiki.cs.uta.fi/wiki/project_plan. Tarkastuksen deadline 12.10. Palautus 5 päivää etukäteen kaikille asianosaisille. On tärkeää selittää, mitä kehitysmallia sovelletaan, kuinka sitä sovelletaan ja miksi kyseinen kehitysmalli valittiin mukaan. Työn ositus, vaihetuotteet, aikataulutus, vastuut,... 10
Riskeistä Riskien havaitseminen. Riskien analysointi. Riskeihin varautuminen (riskien hallinta). Riskien seuranta. Riskikategoriat Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Tony Moynihan, Coping with IS/IT risk management Somerville, Software Engineering Hughes and Cotterell, Software project Management 11
Riski Project Management Body of Knowledge defines risk as an uncertain event or condition that, if it occurs, has a positive or negative effect on a project s objectives 12
Research: risks in students SW projects Ahtee, T. and Poranen, T.: Risks in students software projects, 2009. http://www.cs.uta.fi/~tp/pub/ta-tp-cseet2009-final.pdf Software project education is an important part of software engineering studies in all universities. A well written final report gives an overview how the project went and what students have learned from the project. In this paper we analyze risks in 76 final reports from students software projects from academic years 2006-7 and 2007-8. The projects were done in two Finnish universities. We recognized that four major risks are tools and skills to use the tools (61% of projects), technological problems (53%), scheduling problems (61working or studying too many other courses during the project (45%). We also give guidelines to teachers and project managers to take into account the special nature of student projects. 13
RISK NAME PROJ. % Communication problems 24 32% Requirements 24 32% Illness and social problems 26 34% Tools and skills 46 61% Quitting team members 14 18% Process problems 15 20% Motivation level low 27 36% Technology problems 40 53% Documentation problems 9 12% Scheduling problems 47 61% Working and studying during project 34 45% Client related problems 18 24% Third-party components 15 20% Group work related problems 14 18% 14
Riskit ja niiden hallinta -taulukko Kuvaus 1 Kovalevy rikkoutuu Ääni, hyvin epävarma havaita etukäteen etukäteen Vakavuus Matala Vakava Varmuuskopiointi, uuden kovalevyn hankkiminen : : : : : : : 7 Aikataulutus ongelmat Korkea Liian pienet työtunnit, projekti on myöhässä. Havaittavuus kohtuullinenvarma. Keskimääräinen tai vakava Tunniste Ennusmerkki, havaittavuus Todennäköisyys Ennaltaehkäisy ja torjuminen toipuminen Palauta varmuuskopio Hyvä suunnittelu, työskentelyä enemmän Työskentele enemmän, vähennä vaatimuksia 15
Tavallisimpia syitä ongelmille Työmääräarvio virheellinen. Vaatimusmäärittelyt puutteellisia. Muutosvastarinta. Liian suuri projekti. Asiakkaan/toimittajan kokemattomuus. Suunnittelematon käyttöönotto. Henkilöstövaihtuvuus. Huono projektipäällikkö. Ongelmat työvälineissä tai laitteissa. 16
Riskienhallintaprosessi Riskien tunnistaminen. Projekti-, tuote- ja liiketoimintariskit tunnistetaan. Riskien analysointi. Arvioidaan riskien todennäköisyydet ja vaikutukset. Riskeihin varautuminen (riskien hallinta). Välttämisen tai vaikutuksen minimoinnin suunnittelua. Riskien seuranta. Riskien jatkuvaa arviointia ja lieventämissuunnitelmia (sitä mukaa, kun tietoa riskeistä tulee esille). 17
Riskienhallintaprosessi Iteratiivinen prosessi, joka jatkuu läpi projektin. Riskien tunnistaminen Riskien analysointi Riskien hallinta Riskien seuranta Riski lista Priorisoitu riskilista Riskien välttämisen ja vaikutusten mini mointisuunnitelmat Riskien arviointi 18
Riskien tunnistaminen Aivoriihi. Tekijöiden tai projektipäällikön kokemukset. Listoja apuna. Riskityyppejä. Riskejä suoraan. 19
Riskityyppejä Teknologiariskit. Ihmisiin liittyvät riskit. Organisatoriset riskit. Asiakkaaseen liittyvät riskit. Työkaluihin liittyvät riskit. Vaatimuksiin liittyvät riskit. Arviointiriskit (estimointi-). Riippuen tarkkuustasosta, listaa voi supistaa tai laajentaa. Kunkin kohdalla: mitä yksittäisiä riskejä löytyy omasta projektista. 20
Riskien analysointi Kunkin löydetyn riskin kohdalla arvioidaan riskin todennäköisyys (1-5) hyvin matala, matala, keskimääräinen, korkea, hyvin korkea. vakavuus (1-5) merkityksetön, siedettävä, keskimäärinen, vakava, katastrofi. havaittavuus (millä varmuudella riskin voi havaita) hyvin epävarma, alhainen, kohtuullinen, korkea, lähes varma Tulokset kootaan riskitaulukkoon. Taulukko järjestetään usein todennäköisyys*vakavuus arvon perusteella. Lopuksi päätetään, mitkä ovat projektin kannalta tärkeimmät seurattavat riskit (esimerkiksi 10 20 kpl). 21
Tietotekniikan liiton etiikan ohje Etiikka on filosofian osa-alue, joka tutkii oikeaa ja väärää, oikeudenmukaisuutta ja velvollisuutta ja muita näihin liittyviä käsitteitä. Ohjelmistoalalla on runsaasti eettisiä haasteita / ongelmia: tekijänoikeudet, luonnonsuojelu, tietosuoja, uuden teknologian tuomat mahdollisuudet,... Tärkeää on tunnistaa projektin asianosaiset (muut ryhmän jäsenet, yritys/oppilaitos, asiakas, yhteiskunta) ja pohtia erilaisten tekojen vaikutusta eri henkilöihin ja ryhmiin. Omien tekojen vaikutusten tiedostaminen. http://www.ttlry.fi/etiikan-ohjeet-v3 Tutustu myös: http://www.cs.helsinki.fi/docs/d-2007-1.pdf (sivut 13-22). 22