Proffa ilmoittautumisen profiloija Projektisuunnitelma Leila Juusola Ilari Moilanen Jyrki Salonen Olli Sinerma Hanna Sirola Helsinki 2.2.2005 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
HELSINGIN YLIOPISTO Matemaattis-luonnontieteellinen tiedekunta Tietojenkäsittelytieteen laitos Tekijät: Leila Juusola Ilari Moilanen Jyrki Salonen Olli Sinerma Hanna Sirola Työn nimi: Proffa ilmoittautumisen profiloija Oppiaine: Tietojenkäsittelytiede Työn laji: Projektisuunnitelma Aika: 2.2.2005 Sivumäärä: 8 sivua Tiivistelmä: Tämä dokumentti on Proffa-projektin projektisuunnitelma. Proffa-projektin tarkoituksena on luoda web-työkalu, joka helpottaa opiskelijoiden jakamista ryhmiin Tietojenkäsittelytieteen laitoksen kursseilla. Projektisuunnitelmasta selviävät projektin osanottajat ja heidän vastuualueensa, projektin aikataulu ja mahdolliset riskit. Uusin versio tästä projektisuunnitelmasta on saatavilla Proffa-ryhmän kotisivuilla osoitteessa http://www.cs.helsinki.fi/group/proffa. Versiohistoria Versio Päiväys Tehdyt muutokset 1.0 2.2.2005 1.1 8.2.2005 1 Johdanto: tarkennuksia, 3.3 Resurssit ja tekniikka: lisätty yksi riski, 6 Projektin aikataulu: tarkennuksia Avainsanat: Proffa, profilointiohjelma
Sisältö 1 Johdanto... 1 2 Projektiorganisaatio... 1 3 Riskianalyysi... 2 3.1 Ajanhallinta... 2 3.2 Henkilöstö... 2 3.3 Resurssit ja tekniikka... 3 3.4 Projektin toteutus... 4 4 Ohjelmisto... 5 4.1 Järjestelmän yleiskuvaus... 5 4.2 Laitteisto- ja ohjelmistovaatimukset... 5 4.3 Arvio projektin koosta... 6 5 Työn ositus... 6 6 Projektin aikataulu... 7 7 Seuranta- ja raportointitavat... 8
1 1 Johdanto Ilmoittautumisen profiloija eli Proffa-projektin tavoitteena on toteuttaa opettajien avuksi järjestelmä, joka auttaa ryhmäjaon muodostamisessa Helsingin yliopiston tietojenkäsittelytieteen laitoksen kursseilla. Joillain kursseilla opiskelijat jaetaan pienryhmiin ilmoittautumisen yhteydessä annettujen taustatietojen ja ryhmätoiveiden mukaan. Tavoitteena ryhmäjaossa on toisaalta muodostaa mahdollisimman homogeenisia, tasakokoisia ja/tai täysiä ryhmiä, ja toisaalta täyttää opiskelijoiden esittämiä toiveita niin paljon kuin mahdollista. Järjestelmää tarvitaan ensisijaisesti kolmella kurssilla: Ohjelmistotuotantoprojekti, Tieteellinen kirjoittaminen ja Opettajatuutorointi. Näillä kursseilla on keskenään erilaiset sisällölliset ja hallinnolliset vaatimukset. Järjestelmä toteutetaan web-työkaluna. Ilmoittautumisajan päätyttyä työkalu hakee tiedot ilmoittautumisjärjestelmästä, tarkistaa opiskelijoiden esitiedot ja ryhmittelee opiskelijat vastuuhenkilön määrittelemien kriteerien ja prioriteettien perusteella. Ryhmittelyn jälkeenkin vastuuhenkilöllä on mahdollisuus muuttaa ryhmien koostumusta. Lopputuloksena järjestelmä tuottaa verkkosivun, jossa ryhmäjako on näkyvissä. Ryhmäjako sisältää ryhmän tunnuksen sekä ohjaajan ja opiskelijoiden nimet. Tiedot ovat siirrettävissä muihin järjestelmiin. 2 Projektiorganisaatio Pirjo Moen, asiakas pirjo.moen@cs.helsinki.fi Pekka Simola, ryhmän ohjaaja pekka.simola@cs.helsinki.fi Olli Sinerma, projektipäällikkö olli.sinerma@welho.com - erityisosaaminen: PHP, XML, ASP, Java, MySQL - käyttöliittymäsuunnittelu - digitaalisen median tekniikat Jyrki Salonen, koodausvastaava jsalonen@iki.fi - erityisosaaminen: Java, PHP, HTML+CSS - tietokannat laitoksen kurssien laajuudessa - käyttöliittymäsuunnittelu Ilari Moilanen, testausvastaava imoilane@cc.helsinki.fi - erityisosaaminen: Java, Javascript, Postgresql, XML - testaaminen - digitaalisen median tekniikat Leila Juusola, dokumentointivastaava leilajuusola@suomi24.fi - erityisosaaminen: Java, PHP, MySQL, XML
2 Hanna Sirola, web-vastaava hsirola@cs.helsinki.fi - erityisosaaminen: Java ja Java Servletit - käyttöliittymäsuunnittelu 3 Riskianalyysi Proffa-ohjelmistotuotantoprojektia toteutettaessa on olemassa tiettyjä riskejä, jotka tulisi ottaa huomioon vahinkojen välttämiseksi. Riskejä, niiden todennäköisyyksiä ja vakavuuksia on lueteltu alla. Myös ratkaisuja ja ennaltaehkäisykeinoja on esitetty. Tässä projektissa budjettia koskevia tai muita taloudellisia riskejä ei ole. Todennäköisyydet ja vaikutukset on arvioitu asteikolla 1-5 (tn = todennäköisyys, v = vaikutus). 3.1 Ajanhallinta * Myöhästyminen aikataulusta (tn 3, v 4) Myöhästymisen riskiä voidaan pienentää seuraamalla tasaisin väliajoin ja tarpeeksi tiheään projektin pysymistä aikataulussa. Näin myöhästymiset huomataan ajoissa, ja niihin voidaan puuttua ennen kuin projekti ehtii kärsiä merkittävästi. Jos merkittävää myöhästymistä ehtii kuitenkin tapahtua, on paikallaan neuvottelu asiakkaan kanssa mahdollisesta uudesta toimituspäivästä ja/tai joidenkin toimintojen karsimisesta aikataulussa pysymiseksi. * Huono tai tehoton ajankäyttö (tn 2, v 3) Ajankäyttöä voidaan tehostaa jakamalla tehtävät mahdollisimman tarkkaan oikeille henkilöille sen mukaan, mitä kukin osaa parhaiten. Näin aikaa ei kulu turhaan opetteluun. Ajankäyttöä valvotaan projektin aikana tuntilistojen avulla, mikä osaltaan auttaa työntekijöitä havaitsemaan suhteettoman ajankulutuksen. 3.2 Henkilöstö * Työntekijän sairastuminen (tn 4, v 1) Työntekijän lyhytaikainen sairastuminen ei vaikuta kovinkaan paljon projektiin pitkällä tähtäimellä, mutta voi lykätä käsillä olevaa määräaikaa. Sairauksia ei voi ehkäistä ennalta, ja henkilön sairastuessa hänen tehtävänsä joko lykkääntyy tai jaetaan muiden tekijöiden kesken.
3 * Työntekijä sairastuu pitkäaikaisesti tai useita työntekijöitä sairastuu (tn 1, v 4) On epätodennäköistä, että projektin jäsenistä kukaan sairastuisi vakavasti tai että useita sairastumisia tapahtuisi päällekkäin, mutta jos niin tapahtuu, se vaikuttaa projektiin suuresti. Mitä kriittisemmässä vaiheessa tämä tapahtuu, sitä pahemmat ovat seuraukset projektille. Jos henkilö/henkilöt ei/eivät ole käytettävissä, jaetaan työtehtävät uudelleen jäljelle jääneiden kesken mahdollisimman mielekkäällä tavalla, ja projekti aikataulutetaan uudelleen (ks. myöhästyminen). * Työntekijä keskeyttää projektin (tn 1, v 4) On epätodennäköistä, että projektin jäsenistä kukaan lähtisi kesken projektin, mutta jos niin tapahtuu, se vaikuttaa projektiin suuresti. Mitä kriittisemmässä vaiheessa tämä tapahtuu, sitä pahemmat ovat seuraukset projektille. Jos henkilö lähtee, jaetaan työtehtävät uudelleen jäljelle jääneiden kesken mahdollisimman mielekkäällä tavalla, ja projekti aikataulutetaan uudelleen (ks. myöhästyminen). * Ryhmän huono organisaatio (tn 1, v 3) Jos työtehtävät on jaettu epämääräisesti ja päällekkäisesti, eikä kukaan ryhmän jäsen ole selvillä muiden vastuualueista tai projektin yleisistä asioista, on tuloksena yleinen sekasorto. Tällöin tarvitaan projektipäällikköä, joka kykenee pitämään ryhmän koossa ja jakamaan selkeästi vastuuta projektista työntekijöiden kesken. Projektissa on tärkeää, että yksi henkilö hallitsee kokonaisuutta ja toimii keskushenkilönä ryhmän välillä. * Joku ryhmän jäsenistä kärsii motivaationgelmista (tn 4, v 2) Työntekijä voi kokea projektin tarpeettomaksi tai tekevänsä epämielekästä työtä, mikä heijastuu hänen työsuoritukseensa. Tällaisessa tapauksessa kurinpalautus ja/tai motivaationkohotus muiden ryhmäläisten taholta voi auttaa eksyneen lampaan takaisin oikealle tielle. * Jollekin ryhmän jäsenelle ei löydy osaamista vastaavia tehtäviä jossain projektin osavaiheessa (tn 2, v 2) Jos työntekijällä ei ole tarpeeksi tietotaitoa selvitä kaikista projektin eri osavaiheista, voi käydä niin, että jossain vaiheessa hänelle ei löydy sellaista työtä, jota hän osaisi. Ratkaisuna voidaan lisätä työntekijän vastuuta sellaisissa osavaiheissa, jotka tämä hallitsee paremmin. 3.3 Resurssit ja tekniikka * Kehitysympäristö osoittautuu puutteelliseksi (tn 2, v 4) Jos kehitysympäristöstä ei ole aikaisempaa kokemusta toteutettavan kaltaisen ohjelmiston tekemisessä, voi olla, että kesken projektin huomataan kehitysympäristö tai -työkalut riittämättömiksi toteuttamaan asiakkaan vaatimuksia. Tämä puute tulisi huomata suhteellisen aikaisin, jotta ympäristöä tai työkaluja pystyttäisiin vielä vaihtamaan. Kehitystyökaluihin perehtyminen etukäteen ehkäisee pahimmat puutteet.
4 * Järjestelmän liittäminen ulkoisiin järjestelmiin epäonnistuu (tn 1,5, v 4) Esimerkiksi tietokannasta saatavat syötteet voivat olla niin satunnaisia ja erilaisia, ettei tuotettu ohjelmisto pysty käsittelemään niitä. Tällöin voidaan rajoittaa järjestelmän toimintaa pienempään alueeseen, ja/tai neuvotella asiakkaan kanssa uusista priorisoinneista. * Tietokanta saadaan käyttöön merkittävästi myöhässä (tn 1,5, v 3) Tietokantayhteyshenkilöillä saattaa kestää liian kauan pystyttää tietokantaympäristö projektille. Nykyinen aika-arvio on muutamien päivien luokkaa (lähtien perjantaista 4.2.2005), mutta unohdusten tai muiden kiireiden takia ympäristö saattaa myöhästyä projektin kehittelyvaiheen alusta merkittävästi. Ehkäisy- ja toipumistoimenpiteet ovat samat: yhteydenpito ympäristön pystyttäjän kanssa unohduksien estämiseksi ja mahdollisen myöhästymisen jälkeen toimenpiteiden jouduttamiseksi. 3.4 Projektin toteutus * Väärinkäsitykset asiakkaan kanssa (tn 2, v 4) Asiakkaan kanssa neuvoteltaessa saattaa syntyä väärinkäsityksiä toteutettavasta ohjelmistosta tai siihen liittyvistä asioista, kuten toimintaympäristöstä tai toteutustavasta. Tämä on sitä haitallisempaa, mitä suurempi väärinkäsitys on kyseessä ja mitä myöhemmin se huomataan ja oikaistaan. Pahimmassa tapauksessa koko ohjelmisto tai sen osia on toteutettava uudestaan. Tämän estämiseksi kaikki toteutukseen liittyvat asiat tulisi määritellä mahdollisimman tarkasti heti alusta alkaen, ja mielellään kirjallisessa muodossa, jotta määritelmään voidaan palata myöhemmin. Jos väärinkäsitys tapahtuu, pitää asiakkaan kanssa neuvotella mahdollisimman pian jatkotoimenpiteistä; toteutetaanko aloitetulla tavalla vai tehdäänkö uudelleen alusta. * Asiakas ei tiedä, mitä haluaa (tn 2, v 2) Joskus asiakkaan on vaikea kertoa tarkalleen, millainen ohjelmisto on toteutettava ja mitä kaikkea sen tulee sisältää. Tämä voi johtaa työajan käyttämiseen siihen, että toteutetaan turhaan toimintoja, joita asiakas ei halua tuotteeseen. Päättämättömyyttä vältetään helpoiten sillä, että annetaan asiakkaalle vaihtoehtoja ja malleja, joista saadaan vähintään suuntaa asiakkaan haluamalle tuotteelle. Prototyypin rakentaminen ja asiakkaalle demoaminen on hyvä keino saada asiakkaan tarpeita selville. * Projektiryhmän kokemattomuudesta johtuvat virheet (tn 4, v 1-2) On melko todennäköistä, että projektissa syntyy virheitä, jotka johtuvat siitä, että kukaan projektiryhmän jäsenistä ei ole tehnyt vastaavaa työtä aikaisemmin. Virheistä aiheutuva haitta on hallittavissa noudattamalla projektisuunnitelmaa.
5 4 Ohjelmisto 4.1 Järjestelmän yleiskuvaus Järjestelmä koostuu profilointiohjelmasta ja käyttöliittymästä. Profilointiohjelmasta on yhteys ilmoittautumis- ja Desmond-järjestelmiin sekä tietokantaan. 4.2 Laitteisto- ja ohjelmistovaatimukset Profilointiohjelma Profilointiohjelma käyttää omiin operaatioihinsa MySQL- tai PostgreSQL-tietokantaa. Tarvitsemansa tiedot ohjelma saa laitoksen ilmoittautumisjärjestelmästä (ilmoittautujien vastaukset kysymyksiin yms. tiedot) ja esitietovaatimuksiin liittyvät tiedot saadaan laitoksen Desmond-järjestelmästä. Profilointiohjelma toteutetaan käyttäen PHP-kieltä, joka tulostaa tiedot ja käyttöliittymän HTML:nä. Käyttöliittymä Profilointiohjelman käyttöliittymä toteutetaan HTML:llä, jota käyttäjä käyttää Internet-selaimella. Selaimeksi soveltuu joko Internet Explorer tai Mozilla.
6 Laitteistovaatimukset Verkkopalvelin, joka pyörittää PHP+MySQL-yhdistelmää. Yhteys laitoksen ilmoittautumis- ja Desmond-järjestelmään. Kehitysympäristö Kehitysympäristönä toimii kunkin käyttäjän koneella toimiva Apache+PHP+MySql -yhdistelmä tai joidenkin kohdalla laitoksen tietokantapalvelin SSH-yhteyden avulla. Ohjelmiston koodi yms. kiinteästi järjestelmään liittyvä materiaali säilytetään CVS-versionhallinnassa. CVS-repository sijaitsee hakemistossa /group/home/proffa/cvsroot. 4.3 Arvio projektin koosta Aikaisempien ohjelmistotuotantoprojektien perusteella voi karkeasti arvioida, että viiden hengen ryhmä tuottaa kurssin aikana enimmillään 4000 koodiriviä. 5 Työn ositus Tarkistuspisteet on asetettu muutamaa päivää ennen kyseisen vaiheen työn palautusta, jotta dokumenttia voidaan tarkastella kokonaisuutena palaverissa koko ryhmän voimin. T0: 28.1. Projektin aloitus ja vastuualueiden jako T1: 2.2. Projektisuunnitelman palautus T2: 8.2. Lisävaatimusten keräys T3: 11.2. Powerpoint-proton palautus E1: 15.2. Tarkistuspiste I T4: 16.2. Vaatimusdokumentin palautus T5: 18.2. Suunnittelun työnjako E2: 1.3. Tarkistuspiste II T6: 2.3. Suunnitteludokumentin palautus T7: 4.3. Toteutuksen työnjako E3: 15.3. Tarkistuspiste III E4: 1.4. Tarkistuspiste IV T8: 4.4. Käyttöohjeen ensimmäinen versio valmiina T9: 5.4. Testauspalaveri I T10: 12.4. Testauspalaveri II
7 T11: 15.4. Loppuraportin palautus T12: 20.4. Käyttöohjeen palautus E5: 22.4. Tarkistuspiste V T13: 26.4. Työn palautus T14: 26.4. Loppuraportin palautus 6 Projektin aikataulu Projektin aloitus 28.1. Projektisuunnitelma 28.1.-2.2., 6 päivää 2.2. Projektisuunnitelman palautus Vaatimusmäärittelyä 3.2. - 17.2., 15 päivää 8.2. Vaatimusten esittely ja lisävaatimusten määrittely asiakkaan kanssa, proton palautetilaisuus 11.2. Työnajakopalaveri 15.2. Tarkistuspiste I, ohjelmistovaatimukset määritelty. Kaikki tarvittava materiaali suunnitelmadokumenttia varten valmiina (tiedot siitä, millaiset ovat tarvittavien tietokantojen rakenteet yms.) 16.2.Vaatimusdokumentin palautus 18.2. Vaatimusdokumentin läpikäynti (technical review), asiakas paikalla Suunnittelua 18.2.-3.3., 14 päivää 18.2. Työnjakopalaveri 1.3. Tarkistuspiste II, suunnitteludokumentti valmiina ja esittely asiakkaalle ennen palautusta 2.3. Suunnitteludokumentin palautus 4.3. Suunnitteludokumentin läpikäynti (formal technical review)
8 Toteutus, osa 1, 4.3.-24.3., 20 päivää 4.3. Työnjakopalaveri 15.3. Tarkistuspiste III, proto valmiina asiakkaalle esiteltäväksi 24.3. Pääsiäisloman takia siirretään palaveri perjantailta torstaille 25.3. - 28.3. Pääsiäisloma Toteutus osa 2, 29.3.-5.4., 7 päivää 1.4. Tarkistuspiste IV, ohjelmasta on olemassa stabiili ja toimiva versio, joka voidaan esitellä asiakkaalle 1.4.-8.4., ennen toista testauspalaveria 4.4. Ensimmäinen versio käyttöohjeesta valmiina Testausta, korjailua ja loppuraportin teko 5.4.-14.4., 10 päivää 5.4. Testauspalaveri I 12.4. Testauspalaveri II, jossa asiakas mahdollisesti mukana 15.4. Testausraportin palautus Viimeisten dokumenttien valmistelu 15.4-26.4, 11 päivää 19.4. Käyttöohjeen viimeistely ja loppuraportin aloitus 20.4. Käyttöohjeen palautus 22.4. Tarkistuspiste V, loppuraportin viimeistely 26.4. Loppuraportin ja työn palautus 27.4 Työn lopullinen deadline, demopäivä 7 Seuranta- ja raportointitavat Projektin viikoittaisissa seurantakokouksissa tarkistetaan projektin eteneminen vertaamalla sitä projektisuunnitelmaan. Kokouksissa pidetään pöytäkirjaa. Tarkastuksissa tarkistetaan systemaattisesti jonkin ohjelmistotuotteen tai sitä kuvaavan dokumentin laatu. Tarkastuksia pidetään projektin aikana useita jonkin ohjelmistotuotteen tai dokumentin valmistuttua. Projektissa laaditaan ainakin seuraavat dokumentit: projektisuunnitelma, vaatimusdokumentti, suunnitteludokumentti, testaussuunnitelma, käyttöohje, testausyhteenveto ja loppuraportti. Dokumentit liitetään projektin päättyessä loppuraporttiin. Lisäksi projektiryhmän jäsenet pitävät kirjaa työtunneistaan, joiden perusteella laaditaan työtuntilistat. Projektiryhmä pitää jatkuvasti ajan tasalla dokumenttiarkistoa. Kaikki dokumentit ohjelmakoodia lukuunottamatta kootaan projektimappiin. Osa dokumenteista on saatavilla myös Proffa-ryhmän kotisivuilla osoitteessa http://www.cs.helsinki.fi/group/proffa.