T-76.115 Projektisuunnitelma 06.02.2002 Confuse 1
Tila Versio: 3.03 Tila: Katselmoitu Jakelu: Julkinen Luotu: 02.10.2001 Tuomo Koskenvaara Muutettu viimeksi: 12.02.2002 Tuomo Koskenvaara Versiohistoria Versio Pvm Tekijä Kuvaus 1.0 25.10.2001 Koskenvaara Tuomo Sisäisesti hyväksytty versio 1.1 26.10.2001 Koskenvaara Tuomo Korjattu asiakaspalaverissä esille tulleita virheitä 1.2 29.10.2001 Koskenvaara Tuomo Oikoluettu ohjelmallisesti 1.21 7.11.2001 Haapakoski Antti Vaatimusviittaukset asiakkaan top-10 -tavoitteisiin 1.22 7.11.2001 Haapakoski Antti Muutettu taulukkojen leveyttä pdf:ää varten 1.23 10.11.2001 Koskenvaara Tuomo Tarkennettu menetelmiä, lisätty kohta Projektin teoreettiset kustannukset ja koulutussuunnitelma, kappaleet 4, 9 ja 13 1.24 12.11.2001 Kujala Petri Lisätty menetelmiin linkki riskienhallinnassa käytetystä delfoi-menetelmästä kertovaan dokumenttiin, kappale 9. 1.25 13.11.2001 Koskenvaara Tuomo Korjattu taulukoiden otsikointia ja numerointia. Päivitetty koulutussuunnitelmaa kappale 13. 1.26 19.11.2001 Koskenvaara Tuomo Korjattu koulutussuunnitelmaa ja menetelmiä kappaleissa 9 ja 13. 1.27 24.11.2001 Koskenvaara Tuomo Päivtetty T1-vaiheen resurssien jakoa kappaleessa 10. 1.3 28.11.2001 Koskenvaara Tuomo Lisätty vaatimustentäyttymisaikatauluja kappaleessa 10. 2.0 03.12.2001 Koskenvaara Tuomo Korjattu kirjoitusvirheitä ja toimimattomia sisäisiä linkkejä. Lisätty ulkoisia linkkejä. 2.01 08.12.2001 Kujala Petri Riskienhallinan päivitys. 2.1 11.01.2002 Koskenvaara Tuomo Muutoksia projektipäällikkö muutosten takia kappaleessa 5 ja 8. Päivityksiä lukuun 8. 2.02 27.01.2002 Koskenvaara Tuomo Tuntisuunnitelmien päivittämistä ja päivityksiä menetelmien tekijöihin (Mikko tekee Arin menetelmän lopun). Kappaleet 9 ja 10. 3.0 05.02.2002 Koskenvaara Tuomo Versio katselmointeja varten. 3.01 05.02.2002 Kujala Petri Riskienhallinan päivitys. 3.02 06.02.2002 Koskenvaara Tuomo Katselmoinnissa ilmitulleiden virheiden korjailua. 3.03 12.02.2002 Koskenvaara Tuomo Katselmoinnissa ilmitulleiden virheiden korjailua. Kappale 8. 2
Sisältö 1 Johdanto 5 1.1 Projektin tarkoitus ja kattavuus..................................... 5 1.2 Tuote ja ympäristö........................................... 5 1.3 Arkkitehtuuri.............................................. 6 1.4 Oikeudet työn tuloksiin......................................... 7 1.5 Yleiskatsaus dokumenttiin....................................... 7 2 Termit ja määritelmät 7 3 Asiakkaan nykyinen ratkaisu 9 4 Projektin toteutusperusteet 9 5 Projektin organisaatio 10 5.1 Projektiryhmä.............................................. 10 5.2 Sidosryhmät............................................... 12 6 Projektin tavoitteet ja päättäminen 12 6.1 Projektiryhmän tavoitteet........................................ 12 6.2 Asiakkaan tavoitteet........................................... 12 6.3 Projektin tavoitteet........................................... 12 6.4 Projektin keskeyttämiskriteerit..................................... 13 6.5 Projektin päättämiskriteerit....................................... 13 7 Mittarit 14 7.1 Raportointi............................................... 14 7.2 Mittareiden keräys ja visualisointi................................... 14 7.3 Käytettävät mittarit........................................... 14 7.3.1 Työmäärien toteutuminen................................... 14 7.3.2 Aikataulun toteutuminen.................................... 14 7.3.3 Vaatimusten täyttyminen.................................... 14 7.3.4 Ohjelmiston koko........................................ 15 7.3.5 Löydettyjen ja korjattujen virheiden määrät.......................... 15 7.3.6 Sisäisesti löydettyjen virheiden osuus............................. 15 7.3.7 Virheiden korjausaika..................................... 15 7.3.8 Virheiden määrä koodiriviä kohti............................... 15 8 Projektin resurssit 15 9 Projektissa käytettävät menetelmät ja työkalut 16 10 Projektin ositus, vaiheistus ja resursointi 18 10.1 Projektin suunnittelu.......................................... 19 10.2 Toteutus 1................................................ 21 10.3 Toteutus 2................................................ 23 10.4 Toteutus 3................................................ 25 10.5 Luovutus................................................ 27 11 Laatusuunnitelma 28 12 Riskienhallintasuunnitelma 28 12.1 PS-vaiheen tulokset........................................... 28 12.2 T1-vaiheen tulokset........................................... 28 12.3 T2-vaiheen tulokset........................................... 29 12.4 T3-vaiheen tulokset........................................... 29 12.5 LU-vaiheen tulokset........................................... 29 3
13 Koulutussuunnitelma 29 14 Asennussuunnitelma 30 15 Käyttöönottosuunnitelma 30 16 Lähteet 30 17 Liitteet 30 4
1 Johdanto Tämä asiakirja on T-76.115 Tietojenkäsittelyopin ohjelmatyö- kurssin suorittavan ryhmän Confuse projektisuunnitelma. Nykyään monissa ohjelmistojärjestelmissä on tuhansia erilaisia konfiguraatioita. Jotkut niistä toimivat, toiset eivät. Yhteen tällaiseen konfiguraatioon voi liittyä monia komponentteja ja se saattaa olla hyvinkin monimutkainen. Toimivan konfiguraation löytäminen voi olla hyvinkin vaikeaa. Tämän projektin tarkoituksena on kehittää Teknillisen korkeakoulun SoberIT (Software Business and Engineering Institute) SARCOUS tutkimus projektiin liittyvä yksinkertainen konfigurointiympäristö mobiilipäätelaitteille. SARCOUS tutkii tuoteperheiden ja niiden osien dynaamista ja staattista konfiguraatiota. 1.1 Projektin tarkoitus ja kattavuus Projektissa tutkitaan mahdollisuutta siirtää konfigurointilogiikkaa pois ohjelmien asennusohjelmistoista, jotta mahdolliset konfiguraatio-ongelmat saataisiin selville jo ennen ohjelman asentamisen yrittämistä. Tämä säästää sekä aikaa, tilaa että mobiilipäätelaitteiden kanssa tällä hetkellä sekä kallista, että rajoitettua tiedonsiirtokapasiteettia. Järjestelmä on tarkoitus toteuttaa Tommi Syrjäsen tekemän päättelykonelogiikan avulla. Vaikka aihe-esittelyssä puhuttiinkin mobiililaitteista, on projektissa tarkoitus toteuttaa järjestelmä vain ipaq:ssa toimivalle Familiar Linuxlle. Toteutuksessa pyritään modulaarisuuden avulla helppoon portattavuuteen. Porttaaminen muihin alustoihin ei kuitenkaan kuulu tämän projektin piiriin. 1.2 Tuote ja ympäristö Linux Familiar Linux Compaq ipaq Desktop PC Kuva 1: Järjestelmän ympäristö koostuu PC palvelimeen liitetystä PDA:sta Projektin tarkoituksena on tuottaa ohjelmistojärjestelmä, joka toimii yksinkertaisena konfigurointiympäristönä mobiililaitteille. Projektin mobiililaitteena on Compaq:n valmistama ipaq- kämmenmikro. Palvelinpuolen ohjelmisto toteutetaan Linux-käyttöjärjestelmän päälle. Tiedonsiirrossa käytetään TCP/IP:tä. 5
<<binääri>> Pakettitiedosto Linux PC Lajittelija Configurator logic <<tekstitiedosto>> KL valintamäärittelyt <<tekstitiedosto>> Konfiguraatiomalli Päättelykone Valitsin GUI <<XML file>> Konfiguraation pakettilista Asentaja PDA Asentaja Kuva 2: Suunnitellun systeemiarkkitehtuurin UML komponentti diagrammi 1.3 Arkkitehtuuri Ohjelmisto pyritään pitämään mahdollisimman modulaarisena. Se koostuu kolmesta projektin aikana syntyvästä osasta ja jo toteutetusta päättelykoneesta. Kolmesta osasta yksi on lajittelija, joka tallentaa saamiensa ohjelmistopakettien tiedot päättelykonelogiikan ymmärtämään muotoon ja samalla tekee valitsija osiolle sopivan alustustiedoston. Valitsijaosio toimii käyttäjän käyttöliittymänä konfiguraattorille. Sillä tehdyt valinnat lähetetään päättelykoneelle tarkistettavaksi ja päättelykoneen hyväksymän konfiguraation voi tämän jälkeen asentaa asentajaosiolla päätelaitteeseen. Asentajaosio on jaettu palvelimen ja päätelaitteen kesken. 6
1.4 Oikeudet työn tuloksiin Alla esitetään allekirjoitettu sopimus kokonaisuudessaan. SOPIMUS OIKEUKSIEN LUOVUTTAMISESTA 1. Sopimusosapuolet Teknillinen korkeakoulu / Software Business and Engineering Institute (TKK) sekä TKK:n syksyn 2001 kurssin T-76.115 Tietojenkäsittelyopin ohjelmatyöryhmän "Confuse"jäsenet: Koskenvaara Tuomo, Haapaniemi Ari, Haapakoski Antti, Kujala Petri, Myyry Jani, Martsola Mikko ja Vainionpää Jussi. 2. Sopimuksen kohde Tämä sopimus koskee TKK:n SoberIT- laitoksen Sarcous- projektiin kehitettävää ohjelmistokonfiguroinnin järjestelmää sekä yhteistyöprojektin tulosaineistoa. Tulosaineistolla tarkoitetaan kaikkea opiskelijaryhmän jäsenten tämän sopimuksen kohteena olevassa hankkeessa luomaa tai muulla tavoin tuottamaa aineistoa tai tietoa, kuten kirjallisia tai taiteellisia teoksia, keksintöjä, tietokoneohjelmia mukaan lukien tietokoneohjelman lähdekoodi, taloudellista, teknistä tai muunlaista tietotaitoa, näitä kuvaavia dokumentteja ja raportteja, tietokantoja sekä kaikkia edellä mainittuun aineistoon liittyviä immateriaalioikeuksia kuten patentteja, patenttioikeuksia ja tekijänoikeuksista riippumatta siitä, missä muodossa kyseiset aineistot, tieto ja oikeudet ovat tai miten ne ilmenevät. Tulosaineistoksi ei katsota sellaista aineistoa, tietoa tai oikeutta, jonka TKK mahdollisesti antaa hankkeessa käytettäväksi. Järjestelmän toteutuksesta vastaa kurssin T-76.115 ohjelmatyöryhmä Confuse. 3. Oikeuksien jakautuminen Omistusoikeudet ja immateriaalioikeudet Tulosaineistoon kuuluvat ilman eri korvausta välittömästi niiden syntymisen ja keksimisen jälkeen TKK:lle seuraavin rajauksin: TKK:lla sekä kullakin opiskelijaryhmän jäsenellä on oikeus hyödyntää ohjelmatyössä syntyvää Tulosaineistoa ilman vastapuolen lupaa vapaasti haluamallaan tavalla mukaan lukien Tulosaineiston muunteleminen, kääntäminen, laajentaminen, parantaminen, myyminen, vuokraaminen, jakeleminen ja julkistaminen. TKK:lla ja kullakin opiskelijaryhmän jäsenellä on oikeus luovuttaa Tulosaineistoon kuuluvaan teokseen kohdistuvat oikeutensa kolmannelle osapuolelle. 4. Sopimuksen voimaantulo Sopimus tulee voimaan, kun osapuolet ovat sen allekirjoittaneet mutta koskee takautuvasti projektin Tulosaineistoa koko projektin ajalta (18.09.2001) lähtien. Sopimusta on tehty 8 samasanaista kappaletta, yksi kullekin allekirjoittajalle. 1.5 Yleiskatsaus dokumenttiin Dokumentin ensimmäinen kappale on johdantoa projektiin. Toisessa kappaleessa on termien määrittelyjä. Kolmannessa kappaleessa esitellään projektin organisaatio ja neljännessä kappaleessa projektin toteutusperiaatteet. Viidennessä kappaleessa esitellään projektin organisaatio ja kuudennessa tavoitteet ja päättäminen. Seitsemännessä kappaleessa tuodaan esille projektin resurssit, kahdeksannessa menetelmät ja työkalut, yhdeksännessä osittaminen. Kymmenennessä kappaleessa käsitellään projektiin kuuluvia standardeja. 11. kappaleessa esitetään riskienhallintasuunnitelma jonka jälkeen 12. kappaleessa on koulutussuunnitelma ja viimeisessä kappaleessa käyttöönottosuunnitelma. 2 Termit ja määritelmät BLUETOOTH Bootloader Burana CCCC CF-card configuration configurator deb Debian GNU/Linux A Technology that implements small range radio link between computers, celluler phones, PDAs etc. Teknologia joka toteuttaa radioyhteyden tietokoneiden, matkapuhelimien, taskutietokoneiden yms. välille lyhyillä matkoilla. Program that boots computer. Tietokoneen käynnistävä ohjelma. Bug Report And Nag Application. Bugiraportointi ja versionhallintajärjestelmä. C and C++ Code Counter, A free software tool for measurement of source code related metrics by Tim Littlefair. Ilmainen koodirivien laskentaohjelma. Compact Flash Card, Memory card for handhelds, mp3 players and digital cameras. Muistikortti kämmentietokoneille, mp3 soittimille ja digitaalikameroille A set of components or packages forming a system. In this context a list of packages to be installed in the PDA. Systeemin muodostava joukko komponentteja tai paketteja. Tässä yhteydessä lista paketeista, jotka asennetaan PDA:han. A program that helps the user to make a valid configuration and possibly use that configuration. Ohjelma, joka helpottaa kelvollisen konfiguraation luomisessa. extension for Debian Linux packages. Debian Linuxin pakettien tarkenne. Free UNIX like operating system. Vapaa UNIX-tyyppinen käyttöjärjestelmä. 7
Delphi method A method for combining several estimations. Menetelmä useiden arvioiden yhdistämiseksi. Ethernet Typical method of implementation for local LANs. Tyypillinen paikallisverkon toteutustapa. Ethernet frame Packet that is directed trough ethernet network. This packet can carry for example IP packets. Ethernet-verkossa kuljetettava paketti. Tämä paketti voi kuljettaa esim. IP paketteja. Familiar Linux Linux distribution for handheld computers using StrongArm 110 Processor. Kämmentietokoneelle tarkoitettu Linux-jakelu. firewall Limits accessibility between local and public network. Rajoittaa liikennettä paikallisen ja julkisen verkon välillä. Flash Non-volatile Random Access Memory. Haihtumaton luku ja kirjoitusoperaatiot salliva muisti. Gb Gigabit. Gigabitti GB Gigatavu. Gigatavu GPRS General Packet Radio System. A new nonvoice value added service that allows information to be sent and received across a mobile telephone network. Uusi palvelu datan siirtoon matkapuhelinverkossa. HUT See TKK. IP Internet Protocol. A connectionless network level protocol layer of the TCP/IP. Yhteydetön TCP/IP:n verkkokerros. ipaq A handheld pen operated computer by Compaq. Compaqin tekemä kynäohjattu taskutietokone. ipkg Itsy Package Management System. A lightweight configuration system for Familiar Linux. Kevyt konfiguraationhallintasysteemi Familiar Linuxille. ISO 8601 International Standard for numeric representations of date and time. Kansainvälinen standardi päiväyksen esittämiseen numeerisessa muodossa. Java Object-oriented programming language. Olio-ohjelmointikieli. JSP JavaServer Pages, technology for creating WWW-pages. Teknologia www-sivujen rakentamiseen. LAN Local Area Network, infrastructure of physical connections between computers. Allows data transfers. Tiedonsiirron mahdollistava infrastruktuuri tietokoneiden välillä. lparse Front end for smodels. Esiprosessori smodelssiin. Mb Megabit. Megabitti. MB Megabyte. Megatavu. NFS Network File System, Filesystem that allows the use of remote harddisks. Tiedostojärjestelmä joka sallii kovalevyjen etäkäytön. package One component of a configuration. Package can be for example a file containing some program or library. Konfiguraation osa, joka voi sisältää esim. ohjelman tai kirjaston. PC Personal Computer, a desktop computer with x86 compatible processor. Tavallinen x86- yhteensopiva pöytäkone. PC-Card See PCMCIA. PCMCIA Personal Computer Memory Card International Association, An accessory bus used in laptops and handhelds. Salkku- ja kämmenmikrojen yleinen oheislaiteliitäntä. PDA Personal Digital Assistant, A mobile, handheld computer with software like calendar, contacts, calculator and more. Kannettava tietokone, jossa on ohjelmia kuten kalenteri, yhteystiedot, laskin yms. Perl Powerful high-level interpretable programming language. Korkeantason tulkattava ohjelmointikieli. porting Modifying the code to work in some other environment. Porttaaminen, koodin muokkaaminen toisessa ympäristössä toimivaksi. PPP Point to Point Protocol, Protocol for serial lines. Protokolla sarjayhteyksille. Processor An integrated chip that makes arithmetic and memory operations. Integroitu piiri, joka suorittaa aritmeettisia- ja muistioperaatioita. RAM Random Access Memory, usually volatile. Luku- ja kirjoitusoperaatiot salliva muisti, ei pysyvä. 8
Redhat Linux Free UNIX like operating system. Vapaa UNIX-tyyppinen käyttöjärjestelmä. RL Rule based Language. A language for representing configuration knowledge. Kieli konfiguraatiotiedon esittämiseen. ROM Read Only Memory. Vain luettavissa oleva muisti. RPM Extension for RedHat Linux packages. RedHat Linuxin pakettien tarkenne. SoberIT Software Business and Engineering Institute (in HUT). Ohjelmistoliiketoiminnan ja - tuotannon instituutti (TKK:lla). SSH Secure Shell, Secure replacement for Telnet. Turvallinen Telnetin korvike. SCP Secure CoPy, Secure replacement for FTP. Turvallinen FTPn korvike. SSHD Secure Shell Daemon, SSH Server. SSH-palvelin. SSL Secure Sockets Layer, security protocol that provides communications privacy over the Internet. Protokolla, joka turvaa datan luottamuksellisuuden siirrettäessä Internetin yli. smodels An implementation of the stable model semantics for logic programs. Logiikkaohjelmatulkki joka etsii syötteelle vakaan mallin. TCP/IP Transmission Control Protocol, a connection-oriented internet protocol. Yhteydellinen internetprotokolla. Tirana Work raporting system. Tuntiraportointijärjestelmä. TKK Helsinki University of Technology, Teknillinen Korkeakoulu. UMTS Universal Mobile Telecommunications System, Third-generation (3G) mobile communications system. Kolmannen sukupolven matkapuhelinjärjestelmä. USB Universal Serial Bus, Serial interface that is used in computers and accessories. Sarjaväylä jota käytetään tietokoneissa ja oheislaitteissa. USDP Unified Software Development Process, Generic context for a software project. Ohjelmistoprosessin yleinen viitekehys. UML Unified Modeling Language, a standard for visualization and specification of a software system. Standardi ohjelmiston visualisointiin ja määrittelyyn. ViCa Visualization Client Application. Visualisointi ohjelma. WinCE Windows CE, Microsoft s operating system for handhelds. Microsoftin käyttöjärjestelmä käsimikroille. Wireless Ethernet 802.11b Wireless Ethernet, See WLAN. WLAN Wireless Local Area Network. Computer network that uses radio waves to transmit data. Langaton verkko tietokoneiden välillä. WWW World Wide Web. Maailmanlaajuinen tietoliikenneverkko. XML Extensible Markup Language. A markup language for documents containing structured information. Kieli rakenteisten dokumenttien kirjoittamiseen. xmodem A file transfer protocol for serial connections. Tiedostonsiirtoprotokolla sarjayhteyksille. X environment Graphical window system for UNIX. Graafinen ikkunajärjestelmä UNIXille. 3 Asiakkaan nykyinen ratkaisu Asiakas ei ole löytänyt aikaisempaa vastaavaa ratkaisua ja on tutkimusmielessä kiinnostunut toteuttamaan sellaisen. Toisaalta nykyisenä ratkaisuna voidaan pitää ohjelmien asennuksen hallintatyökaluja, esimerkiksi: deb, rpm ja Microsoft Windowsin ohjelmien asennus. TKK:lla on aikaisemmissa projekteissa tehty vastaavan tyylinen sovellus Debian linux jakelun paketointijärjestelmän päälle. 4 Projektin toteutusperusteet Projekti on osa SARCOUS tutkimus projektia ja samalla asiakkaan opintoja. Lisäksi vastaavaa tuotetta ei ole löytynyt ja tuotteen toteutuksen onnistuessa se voisi helpottaa käyttäjien siirtymistä kämmenmikrojen käyttöön. Asiakkaan kannalta suurin haitta on opiskelijatyövoiman käyttö verrattuna työntekijöihin, jotka voisivat panostaa projektiin kokopäiväisesti ja sopia tapaamisensa pienemmin kompromissein ja lyhyemmällä varoitusajalla. Asiakas on toki ottanut tämän huomioon valitessaan projektin toteutustavan. Projektiryhmän kokemattomuus saattaa myös aiheuttaa yllättäviä ongelmia jossain vaiheessa projektia. Osa näistä saattaa onneksi olla tuttuja asiakkaalle 9
asiakkaan omista projekteista. Myöhempi ylläpito saattaa aiheuttaa ongelmia, koska projektiryhmällä ei ole mitään velvoitteita projektia kohtaan projektin päättymisen jälkeen. Tätä ongelmaa yritetään välttää hyvällä laadulla. Projektin rahalliset kustannukset voidaan määritellä laskennallisesti. Tässä dokumentissa tällä määrityksellä ei ole kuin teoreettista painoarvoa, mutta on kaikille osapuolille hyväksi nähdä paljonko tällaisen projektin oletettavat kustannukset tulisivat olemaan. Työtuntien määrää arvioitaessa otetaan oletukseksi 5 opintoviikkoon laskettavat 200 tuntia jokaista opiskelijaa kohti. Näin saamme projektiryhmän kokonaistunti määräksi 1400 tuntia. Laskutettava työ Arvioitu työmäärä 1 400 h Laskutushinta 500 mk/h 700 000 mk Taulukko 1: Asiakkaalta laskutettavat työtunnit. Asiakas vastaa projektin kannalta aiheellisista laitteistohankinnoista. Pääosa näistä menee palvelimen, kämmenmikron ja niihin tarvittavien lisälaitteiden hankintaan. Lisäksi asiakkaan on käytettävä omaa aikaansa ja mahdollisesti muutamaa ulkopuolista avustajaa. Ohjelmistoja ei tarvitse kurssia varten hankkia, koska koko kehitystyö tullaan tekemään Linux ympäristössä ja tarvittavat muut ohjelmat saadaan tarvittaessa käyttöön TKK:n puolesta. Näistäkin hinnoista voidaan tehdä teoreettinen laskelma asiakkaan kannalta. Oletetaan, että kaikki laitteen joudutaan hankkimaan ulkopuolelta. Välineet Palvelin ipaq Lisäkorttipaikka Verkkokortti 5 000 mk 3 000 mk 1 000 mk 1 000 mk Sisäinen työ Arvioitu työmäärä 100 h Laskutushinta 170 mk/h 17 000 mk Yhteensä 27 000 mk Taulukko 2: Asiakkaalle koituvat omat kustannukset. Näin voidaan olettaa, että asiakkaalle tästä projektista koituisi noin 750 000 mk lasku, josta ulkoisen työn osuus olisi 700 000 mk. Hinnoittelu on kuitenkin hyvin karkeaa, koska hyvin harvoin voidaan kaikesta työstä laskuttaa samaa hintaa. Yksi vaihtoehto olisi tietenkin tehdä projekti urakkapalkalla, mutta tällöin tulee usein hätiköityjä ratkaisuja. Projektin kate muodostuisi tuolla tuntihinnalla kohtuullisen hyväksi projektiryhmän kannalta, mutta tähän hintaan olisikin jo saatava sisällytettyä tietty riski ja sanktio mahdollisist viivästymisistä tai muista projektiin kohdistuvista ongelmista. 5 Projektin organisaatio Tässä kappaleessa esitellään projektin organisaatio. Ensin esitellään projektiryhmän jäsenet, jonka jälkeen asiakas, ohjaaja ja mentor. 5.1 Projektiryhmä Projektiryhmän www-sivu löytyy osoitteesta http://confuse.hut.fi. Ryhmään voi ottaa yhteyttä joko henkilökohtaisesta esittelystä löytyvien tietojen avulla tai lähettämällä sähköpostia ryhmän sähköpostilistalle op@un.tky.hut.fi 10
Rooli: Nimi: E-mail: Kiinnostus- ja osaamisalueet: Opiskelu- ja työkokemus: Rooli: Nimi: E-mail: Kiinnostus- ja osaamisalueet: Opiskelu- ja työkokemus: Rooli: Nimi: E-mail: Kiinnostus- ja osaamisalueet: Opiskelu- ja työkokemus: Projektipäälikkö (1.2002 eteenpäin) ja käyttöliittymävastaava Haapaniemi Ari ajhaapan@cc.hut.fi Viidennen vuosikurssin sähköosaston opiskelija. Pääaineena Tietoliikenneohjelmistot, sivuaineena Digitaalinen- vuorovaikutteinen media. Työskennellyt noin 3 vuotta FRENDS Technology Oy:ssä, ohjelmistosuunnittelijana. Projektipäällikkön apulainen ja projektipäälikkö (1.2002 asti) Koskenvaara Tuomo tlkosken@cc.hut.fi Kiinnostunut kokeilemaan projektin vetämistä valvotuissa olosuhteissa. Hieman aiempaa kokemusta pienten projektien vetämisestä. Kokeillut lähes kaikkia projektin osa-alueita käytännön työelämässä. TKK:n sähköosastolla viidettä vuotta pääaineenaan ohjelmistojärjestelmät ja sivuaineenaan tietoliikenneohjelmistot. Alalta työkokemusta n. 4 vuotta (Sonera, TietoEnator). CERNissä tekemässä diplomityötään tammikuusta 2002 eteenpäin ja suorittaa kurssia sieltä käsin. Testivastaava Myyry Jani jpmyyry@cc.hut.fi unix, perl, www, E-mail, (postscript). Viidennen vuosikurssin tietotekniikan opiskelija. Pääaineena Tietoliikenneohjelmistot. Yli 2 vuotta työkokemusta alalta (TKK atk-keskus), josta puolet unix-ylläpidossa ja palveluiden kehitystyössä. Rooli: Ohjelmoija I Nimi: Martsola Mikko Puhelin: +358 40 823 4131 E-mail: Mikko.Martsola@hut.fi www: www.martsola.com Kiinnostus- ja osaamisalueet: Perl, Java, Linux, SQL, Elektroniikka Opiskelu- ja työkokemus: Neljännen vuosikurssin sähkötekniikan opiskelija. Pääaineena tietoliikenneohjelmistot ja sivuaineena vuorovaikutteinen digitaalinen media. Töissä Soneralla keväästä 2000 alkaen IPv6 testauksessa ja sittemmin wgate tuotteen (Soneran WLAN internet palvelu) tuotteistamisessa. Rooli: Ohjelmistosuunnittelija I Nimi: Haapakoski Antti Puhelin: +358 40 527 7753 E-mail: Antti.Haapakoski@hut.fi Kiinnostus- ja osaamisalueet: C++, Java, Linux, XML, EPOC Opiskelu- ja työkokemus: Neljännen vuosikurssin tietotekniikan opiskelija. Pääaineena ohjelmistojärjestelmät ja sivuaineena informaatiotekniikka. Kaksi kesää Celtius Oy:ssä ohjelmistosuunnittelijana. Lisäksi omia projekteja mm Suomen Keltaiset sivut Oy:lle. Rooli: Nimi: E-mail: Kiinnostus- ja osaamisalueet: Opiskelu- ja työkokemus: Ohjelmistosuunnittelija II Kujala Petri paxa@iki.fi UML, Riskianalyysit Viidennen vuosikurssin sähkötekniikan opiskelilja. Siirtyi pitkän Sonera uran jälkeen TietoEnatorille viime kesänä. 11
Rooli: Nimi: E-mail: Kiinnostus- ja osaamisalueet: Opiskelu- ja työkokemus: Ohjelmoija II Vainionpää Jussi jjvainio@cc.hut.fi C++, Java, Linux, IP, VoIP Neljännen vuosikurssin tietotekniikan opiskelija. Pääaineena ohjelmistojärjestelmät ja sivuaineena informaatiotekniikka. Työskennellyt yhden kesän VTT Automaation kaukokartoitusryhmässä, työskennellyt Sonera Oyj:llä keväästä 2001 lähtien. Lisäksi omia projekteja mm. MPS Management Consulting:lle. 5.2 Sidosryhmät Projektin asiakas: Nimi: TKK / SoberIT (Software Business and Engineering Institute) Edustaja: Katariina Ylinen E-mail: katariina.ylinen@hut.fi Projektin ohjaaja: Nimi: Tomi Männistö E-mail: tomi.mannisto@hut.fi Projektin mentor: Nimi: Timo Ratilainen Päättelykonelogiikan toteuttaja: Nimi: Tommi Syrjänen Toimenkuva: Antaa informaatiota toteuttamansa päättelykoneen integroinnista tuotteeseen 6 Projektin tavoitteet ja päättäminen 6.1 Projektiryhmän tavoitteet Projektiryhmän päätavoitteena on kurssin suorittaminen. Samalla on tarkoitus kerätä kokemusta projektityöskentelystä. Ryhmä aikoo kokeilla kurssilla ja elämässä muuallakin oppimiaan taitoja tämän projektin avulla. Kurssin aikana kokeiluun suhtauduttaneen kuitenkin hieman ystävällisemmin kuin työelämässä. Mikäli ylimääräisten menetelmien kokeileminen alkaa aiheuttaa ongelmia projektin normaalille etenemiselle ovat ne ensimmäisten karsittavien listalla. Kokemuksen karttumista ei kuitenkaan voitane välttää missään tilanteessa. Päätavoitteesta ei luovuta kuin yhteisellä päätöksellä kappaleessa 6.4 asetetuin ehdoin, jolloin luovutaan myös muista tavoitteista. 6.2 Asiakkaan tavoitteet Asiakas haluaa saada modulaarisen mobiililaitteiden konfigurointiympäristön. Projektiryhmän toteuttama projekti on vain osa SARCOUS projektia. Ensisijaisena tarkoituksena lienee todeta onko tällaista järjestelmää edes mahdollista toteuttaa kämmenmikrojen mittakaavassa ja toisaalta kuinka paljon siitä voidaan sisällyttää suoraan kämmenmikroon sen rajallisen kapasiteetin takia. Toinen asiakasta kiinnostava asia on järjestelmän toimivuus huonommankin siirtoyhteyden kanssa. Asiakas haluaa saada kaiken teknisen dokumentaation englanninkielisenä, sen sijaan muu kurssiin kuuluva dokumentaatio voidaan halutessa toteuttaa joko suomen- tai englanninkielisenä. Varsinaisista työtavoista asiakkaalla ei ole toivomuksia. Asiakkaan kymmenen tärkeintä tavoitetta tuotettavan järjestelmän ja osittain projektin suhteen on lueteltu taulukossa 3. Tarkempi kuvaus asiakkaan vaatimuksista löytyy vaatimusdokumentista. Mittarit vaatimuksille tulee vaatimusdokumentin kautta. 6.3 Projektin tavoitteet Projektin tavoitteena on toteuttaa SARCOUS projektin osana toteutettava rajattu mobiililaitteen konfigurointiympäristö. Samalla projektin jäsenet suorittavat kurssin T-76.115 Tietojenkäsittelyopin ohjelmatyö. Kurssiin liittyvä 12
No Katso Kuvaus Verifiointi 1. UR-27 Graafinen käyttöliittymä, jolla PDA:n konfiguraatiota muutetaan valitsemalla paketteja Pakettien valinta/poisto onnistuu hiiren kursoria käyttäen. listasta. 2. UR-07, UR-11-13 Järjestelmä hallitsee konfiguraation oikeellisuutta ja valintojen yhteensopivuutta. Kaikki asennetun konfiguraation ohjelmat toimivat PDA:ssa. 3. UR-02 Järjestelmä käyttää Tommi Syrjäsen lo- Järjestelmä kutsuu päättelykonetta ja käyt- 4. UR-05, UR-14, UR-21 5. UR-06, UR-16 giikkapäättelykonetta. Järjestelmä osaa asentaa PDA:han paketteja. Järjestelmällä voi poistaa PDA:n paketteja. 6. UR-08 Järjestelmä osaa lukea Familiar Linuxin ipkg -muotoisia paketteja. 7. UR-23 Järjestelmän osat ovat modulaarisia ja löyhästi kytkettyjä. 8. UR-19, Järjestelmä muistaa PDA:n konfiguraation. UR-20 9. UR-22 Lähdekoodi on hyvin englanniksi kommentoituna. 10. Tämä kappale (6.2) Järjestelmän tekninen dokumentaatio on englanninkielinen. tää sen antamia tuloksia. PDA:han ilmestyy haluttu ohjelma. PDA:sta poistuu valittu ohjelma. Kyseinen paketti ilmestyy konfiguraattorin käyttöliittymään. Ohjaajan mielipide asiasta kyllä/ei. Verrataan käyttöliittymän näyttämää ja PDA:n todellista konfiguraatiota. Tarkistetaan että lähdekooditiedostojen, luokkien ja metodien alussa on kommentit. Tarkastetaan kaikki tekninen dokumentaatio. Taulukko 3: Asiakkaan kymmenen tärkeintä tavoitetta. UR-xx:t ovat vaatimusten koodeja vaatimusmäärittelyssä. dokumentaatio tehdään aikataulussa. 6.4 Projektin keskeyttämiskriteerit Keskeyttämisellä tarkoitetaan koko projektin keskeyttämistä kaikkien osapuolien kannalta. Projektin keskeyttämisestä voidaan päättää, jos paikalla on vähintään 5 projektiryhmän jäsentä, asiakas ja ohjaaja tai heidän edustajansa. Projektiryhmän jäsenen kuolemantapaus tai vakava sairastumisen vähentää paikalla olevien jäsenten määrää vastaavasti. Keskeyttämistä harkitaan jos: 1) Osoittautuu teknisesti mahdottomaksi toteuttaa asiakkaan pakolliseksi vaatimia ominaisuuksia määräajan ja resursoitujen työmäärien puitteissa, eikä asiakkaan kanssa päästä yhteisymmärrykseen tilanteen korjaamiseksi. 2) Enemmän kuin yksi projektiryhmän jäsenistä joutuu lopettamaan kurssin pakottavan syyn takia. 3) Projektiin varatut resurssit on ylitetty 20% (käytetty yli 1540 h) ennen kuin projektiryhmän arvion mukaan projektin valmiusaste on yli 50%. Päätös on tehtävä projektiryhmän, asiakkaan ja ohjaajan yksimielisellä päätöksellä. 6.5 Projektin päättämiskriteerit Projekti päätetään erillisellä päättöpalaverilla. Siihen osallistuu projektipäällikkö, ohjaaja ja asiakas tai hänen edustajansa. Projektin lopputulos käydään läpi ja tarkistetaan, että se täyttää sille osoitetut vaatimukset. Vasta täytettyään vaatimusmäärittelyssä esitetyt kriteerit projekti voidaan päättää hyväksytysti. Projekti päätetään (tai keskeytetään) viimeistään 26.4.2002. 13
7 Mittarit Tuotantoprosessin toimivuuden ja tuotteen laadun arvioinnin apuna hyödynnetään mittareita. Mittareiden tarkoitus on tuoda esille mahdollisimman objektiivista ja luotettavaa informaatiota tuotantoprosessista sekä tuotteista. Tätä tietoa käytetään ongelmien, kuten aikataulun pettämisen tai tuotteen huonon toimivuuden, havaitsemiseen, korjausten kohdistamiseen ja myöhemmin korjaustoimenpiteiden onnistumisen varmistamiseen. Projektin määräaikaisen luonteen vuoksi esimerkiksi vikaantumisväliä ei pidetty hyödyllisenä mittarina, koska ajanjakso, jonka aikana tuote on käytössä ja tarpeeksi valmis, jää niin lyhyeksi, ettei luotettavaa mittausdataa ehdi kertyä tarpeeksi. 7.1 Raportointi Käytettävien mittareiden tulisi kertoa projektin tilasta lyhyellä latenssilla, jotta suunnitelman muuttaminen ja resurssienkäytön korjaukset olisivat vielä mahdollisia ja käytäntöönpantavissa. Tämän toteuttaminen vaatii paitsi oikeanlaisia mittareita, niin myös mittareiden päivittämistä tarpeeksi tiheään. Mittariaineiston päivittämistiheys on määritelty erikseen jokaiselle mittarille ottaen huomioon datan keräyksen helppous ja se, kuinka nopeista muutoksista mittarin voi kertoa mitään hyödyllistä. Suuremman tiheyden edellyttäminen johtaisi todennäköisesti projektin luonteeseen nähden liialliseen byrokratiaan, jolloin raportoinnin kiertäminen vain vahingoittaisi mittareiden luotettavuutta. 7.2 Mittareiden keräys ja visualisointi Mittareiden keräykseen ja tarkasteluun pyritään käyttämään mahdollisimman pitkälti kurssin tarjoamia apuvälineitä: Tirana, Burana ja ViCA. Jos kurssin järjestelmät osoittautuvat jonkin oman mittarin kannalta epätyydyttäviksi, käytetään muita järjestelyjä, joista esimerkkinä Excel. 7.3 Käytettävät mittarit Kurssin edellyttämiä mittareita luonnollisesti käytetään. Käytettävien mittareiden kirjo saattaa muuttua projektin aikana, kun huomataan jokin mittari tarpeettomaksi, epäluotettavaksi tai epätaloudelliseksi. Toisaalta projektin aikana saattaa ilmetä sellaisia mittareita, joiden hyödyllisyyttä ei ole vielä osattu aavistaa. Lisäksi ainakin testauksessa käytetään kyseiseen osa-alueeseen liittyviä mittareita, jotka esitellään testaussuunnitelmassa. 7.3.1 Työmäärien toteutuminen Päivitystiheys: Vaiheiden lopussa Laskentatapa: Käytetyt tunnit jaetaan projektisuunnitelmassa määritellyillä tuntimäärillä ja tulos ilmaistaan prosentteina. Mittari lasketaan jokaiselle ryhmän jäsenelle sekä koko projektille. Kukin ryhmän jäsen syöttää käyttämänsä tunnit eriteltyinä Tiranaan, ja toteutuneita tunteja verrataan suunniteltuun ajankäyttöön. 7.3.2 Aikataulun toteutuminen Päivitystiheys: Vaiheiden lopussa Laskentatapa: Osa-alueiden vastuuhenkilöt arvioivat kuinka suuri osa heidän vastuullaan olevista osatehtävistä on tehty. Arvioita verrataan suunniteltuun aikatauluun. 7.3.3 Vaatimusten täyttyminen Päivitystiheys: Vaiheiden lopussa Laskentatapa: Lasketaan jokaiselle vaatimusten prioriteettitasolle kuinka monta kyseisellä prioriteettitasolla olevaa vaatimusta on 1. aloittamatta, 2. kesken, 3. toteutettu. Saadaan yleiskuva projektin edistymisestä sekä nähdään, että toteuttamisessa on otettu prioriteetit huomioon. 14
7.3.4 Ohjelmiston koko Päivitystiheys: Koodausvaiheessa kerran kahdessa viikossa Laskentatapa: Ohjelmiston kokoa mitataan moduuleittain koodiriveissä, joihin ei lasketa kommentteja mukaan. Mittari lasketaan cccc -ohjelmalla. Moduuleiden kokojen muutoksista voidaan saada kuva eri osa-alueiden edistymisestä. 7.3.5 Löydettyjen ja korjattujen virheiden määrät Päivitystiheys: Kerran kahdessa viikossa Laskentatapa: Virhemäärät saadaan virheidenhallintajärjestelmästä. Löydetyt virheet syötetään Burana-virheidenhallintajärjestelmään, johon niiden tila myös korjattaessa päivitetään. 7.3.6 Sisäisesti löydettyjen virheiden osuus Päivitystiheys: Kuukausittain Laskentatapa: Virheidenhallintajärjestelmästä saaduista virhemääristä lasketaan sisäisesti löydettyjen virheiden prosenttiosuus kaikista virheistä. Verrataan ryhmän omassa testauksessa ja katselmoinnissa löytyneiden virheiden määrää asiakkaan löytämien virheiden määrään tarkoituksena arvioida oman testauksen riittävyyttä. 7.3.7 Virheiden korjausaika Päivitystiheys: Kuukausittain Laskentatapa: Virheen korjausaika on virheen kirjausajan ja korjatuksi merkitsemisen välinen aika. Lasketaan korjausaikojen keskiarvo sekä keskimääräinen korjausaika. 7.3.8 Virheiden määrä koodiriviä kohti Päivitystiheys: Kuukausittain Laskentatapa: Kirjattujen virheiden määrä jaettuna koodirivien määrällä. Lasketaan jokaiselle moduulille sekä koko projektille. Mittarin avulla voidaan vertailla erikokoisten moduulien laadukkuutta. 8 Projektin resurssit Projektin käytetyimpinä resursseina ovat projektiryhmän jäsenet. Lisäksi tässä luvussa mainitaan toteutuksen kannalta tärkeät henkilöt ja laitteistot. Antti Ari Jani Jussi Mikko Petri Tuomo Yhteensä PS 45 20 40 50 20 40 64 279 T1 50 50 30 40 50 40 34 294 T2 40 60 45 45 60 55 34 339 T3 35 45 55 40 45 40 34 294 LU 30 20 30 20 20 20 34 194 Yhteensä 200 200 200 200 200 200 200 1400 Taulukko 4: Käytettävissä olevat resurssit Seuraavassa taulussa on projektissa toteutunut tuntimäärä. Tätä taulukkoa päivitetään aina osion loputtua, jotta voidaan tehdä vertailua suunnitellun ja toteutuneen välillä. Lisäksi projektissa käytetään hyväksi asiakkaan, ohjaajan, mentorin ja Tomi Syrjäsen aikaa. Mahdolliset erityisaikataulut näiden resurssien käytölle määritellään myöhemmin. Laitteistona käytetään Compaq ipaq H3600-sarjan laitetta. Sen lisävarusteena on verkkokortti (LAN) ja myöhemmin ehkä myös langaton verkkokortti (WLAN). Lisäksi projektissa käytetään palvelinta. Molemmat laitteistot toimittaa asiakas. 15
Antti Ari Jani Jussi Mikko Petri Tuomo Yhteensä PS 50 21 30 41 24 21 74 261 T1 29 44 37 35 29 52 30 256 T2 26,5 31 25 8,5 26 4,5 23 144 T3 0 0 0 0 0 0 0 0 LU 0 0 0 0 0 0 0 0 Yhteensä 106 96 92 85 79 77 127 661 Taulukko 5: Käytetyt resurssit 9 Projektissa käytettävät menetelmät ja työkalut Projektissa pyritään toimimaan USDP (Jacobson, Booch ja Rumbauch 1999) mukaan. Keskeisiksi käsitteiksi tällöin muodostuvat inkrementaalisuus ja iteratiivisuus, toteutuksessa pyritään käyttämään UML- ja use-case -mallinnusta. Projektinhallinnassa pyritään huomaamaan mahdolliset riskitekjät ennalta ja varautumaan niihin. Vaatimustenhallinnan tarkoituksena on kartoittaa asiakkaan ja arkkitehtuurin vaatimukset. Ohjelmiston suunnittelussa käytetään USDP menetelmiä. Ohjelmoinnissa pyritään selkeään ja helposti tarkastettavaan modulaariseen koodiin. Tuotteenhallinnassa ja dokumentoinnissa käytetään versionhallintaa ja ennalta määritettyä rakennetta. Testauksesta luodaan suunnitelmat ja raportit. Tiedotus projektille ja sen sidosryhmille järjestetään pääosin sähköpostin avulla, ryhmän sisäinen tiedotus saattaa käyttää muitakin menetelmiä. Palavereissa annetaan ajatusten lentää. Projektinhallinta Projektinhallinta menetelmät on valittu osittain kurssin puolesta, kuten tuntisurantajärjestelmät ja niiden tekemiseen käytettävät ohjelmistot. Mittarit valitaan viikkopalaverissa tarjokkaiden joukosta. Riskianalyysin tekoon käytetään Delfoi-menetelmää (menetelmää tutkii Petri Kujala PS-vaiheen aikana). Projektin työtuntien suunnitteluun käytetyt ohjelmistot: MS-Project ja MS-Exel Projektin etenemiseen suunnitelmien mukaan käytetään: Tuntiraportointia, mittareita, projektipalavereja ja viikkoraportointia (projektinryhmä raportoi projektipäällikölle, joka kokoaa aineiston ja lähettää yhteenvedon asiakkaalle ja mentorille. Riskienhallintaan on tehty riskienhallinta suunnitelma, jonka kokoamisessa käytettiin delfoii-menetelmää. Vaatimustenhallinta Vaatimustenhallinnan menetelmänä käytetään asiakkaan haastattelua ja muiden saman tuoteperheen analysointia. Varsinaisia vastaavia tuotteita ei markkinoilla ole, mutta yhdistelemällä markkinoilla olevia tuotteita saadaa kuva asiakkaan toivomasta järjestelmästä. Myöhempään vaatimusten jäljittämiseen ja vaatimusmuutosten hallintaan käytetään jäljitetävyysmatriisia, (menetelmää tutkii Jussi Vainionpää T2 vaiheen aikana). Vaatimukset kerättiin haastattelemalla asiakasta ja analysoimalla muita saman tuoteperheen tuotteita. Vaatimusten myöhempään jäljittämiseen ja vaatimusmuutosten hallintaan käytetään jäljitettävyysmatriisia. Suunnittelu Ohjelmiston suunnittelussa käytetään hyväksi UML ja use-case-menetelmiä (Antti Haapakoski tutkii UML menetelmää T1 vaiheessa) Määrittely- ja suunnittelumenetelminä käytettään kurssin toiveiden mukaan UML:ää, Rational Rose-ohjelmistoa ja use caseja 16
Ohjelmointi Ohjemloinnissa käytetään siistiä ja selkeää ohjelmointityyliä. Syntaksi ja kommentointi riippuu käytettävästä ohjelmointikielestä. Koodin selkeyttä ja mahdollisia loogisia virheitä pyritään karsimaan katselmoinneilla ja testaamisella. Ohjelmointityylissä pyritään kuitenkin mahdollisimman samanlaiseen ohjelmointi- ja dokumentointityyliin jonka esikuvana on toimii java (Tätä menetelmää tutkii Mikko Martsola T3 vaiheessa) java ohjelmointi standardit erilaisia scriptikieliä (esim. perl, sh) muita ohjelmoitikieliä Tuotteenhallinta Tuotteenhallinnassa määrävässä asemassa tulee olemaan CVS versionhallinta (menetelmää tutkii Tuomo Koskenvaara PS-vaiheessa). Nimeämiskäytäntö tulee ajankohtaiseksi kun ohjelmaa aletaan ohjelmoida. Sen on katettava hakemistoista aina muuttujiin asti, jotta vältytään mahdollisilta nimeämisongelmilta. Viheiden ja ideoiden hallintaan on kurssin puolelta annettu käytettäväksi Burana-ohjelmisto, joten se käyttäminen näissä asioissa lienee suositeltua. Testaus nimeämiskäytännöt (tiedostot, hakemistot, versiot yms.) versionhallintaan käytetään CVS-ohjelmistoa. muutosten (ideoiden ja bugiraporttien) kerääminen, käsittely ja talletus (burana ja ilmoitustaulu?) Testauksesta tehdään erillinen suunnitelma, jota kehitetään rinnan ohjelman kehityksen kanssa. Testien suunnitelmat, tulokset ja niistä tehdyt raportit säilytetään ainakin kurssin loppuun asti. Testauksessa käytetään V-mallia (Menetelmää tutkii Jani Myyry T3 vaiheessa). järjestelmällinen testitapausten suunnittelu kattavuutta V-malli Työtavat modulitestaus katselmoinnit, tarkastukset käytettävyystestit (testien automatisointi) Projektia tehdään viidessä eri vaiheessa, seitsemän opiskelijan voinmin. Alku vaiheessa palavereja pyritään pitämään noin kerran kahdessa viikossa. Pienemmällä porukalla voidaan kokoontua tarvittaessa useamminkin. Asiakasta tavataan tarpeen mukaan ja heitä informoidaan kahden viikon välein lähetettävällä viikkoraportilla. Saman raportin saa myös kurssin puolelta järjestetty ohjaaja (mentor). Mentoria tavataan kurssin järjestämän aikataulun mukaisesti 5 kertaa kurssin aikana. Mentor auttaa kuitenkin pääasiassa sähköpostin avulla, koska harvemmin ongelmat odottavat tuota tapaamista. Jokaiseen palaveriin asialista laaditaan. Ryhmän ulkopuolisten osallistuessa palavereihin, heille lähetetään asialista muutamaa päivää etukäteen. Projektiryhmän sisäisissä palavereissa tätä käytäntöä pyritään toteuttamaan mahdollisuuksien mukaan. Jokaisesta palaverista kirjoitetaan pöytäkirja, joita ei pääasiassa julkaista. Palavereissa sovittujen töiden tekeminen on jokaisen oma asia, kunhan työ on tehty aikarajaan mennessä. Osiosta vastuussa olevalla henkilöllä on vastuu osion valmistumisesta. Tämä ei tarkoita, että hänen olisi tehtävä koko osio itse, vaan jokaisen osion vastaavan on jaettava osionsa pienempii osiin, joita he voivat jakaa muille ryhmän jäsenille tehtäväksi. palaverit työnjako vastuunjako 17
Tiedonkulku projektin osapuolien välillä Tiedonkulku jäsenten, asiakkaan, ohjaajan ja mentorin välillä on elintärkeää tämän projektin aikana. Tiedonkulkuun puututtiin projektiryhmän puolelta heti kurssin alussa. Ryhmä järjesti itselleen sähköpostilistan jo ennen kurssin virallista alkua. Sähköpostilista on osoittautunut kaikkein tärkeimmäksi yhteydenpitokanavaksi. Henkilökohtaista posti voidaan myös käyttää henkilöiden välillä. Jokaisesta tällaisesta postista on lähetettävä kopio myös projektipäällikölle. Ryhmän jäsenille on jaettu tarpeelliset yhteystiedot, jotta toisen jäsenen kiinnisaaminen, tiukan paikan tullen, ei ole vain sähköpostin varassa. Asiakasta, ohjaajaa ja mentoria pidetään ajantastalla kahden viikon välein lähetettävillä viikkoraporteilla. yhteydenpito (sähköpostilistat, sähköinen ilmoitustaulu, henkilökohtainen sähköposti, puhelin, face2face) dokumenttien jakaminen (sähköposti, www) tilanneraportointi (myös asiakkaalle ja mentorille) (sähköpostitse, projektipäällikkö tai dokumentointivastaava kokoaa) Dokumentointi Dokumentoinnissa käytetään ryhmän kesken sovittua LaTeX formaattia. Dokumentit tallennetaan tässä muodossa CVS-versionhallintajärjestelmään (menetelmää tutkii Tuomo Koskenvaara PS vaiheessa). Dokumentit muutetaan scripteillä jakeluformaatteihin (pdf ja html) ennen palautusta. Dokumentit katselmoidaan ennen julkaisua. yhdenmukainen dokumentointikäytäntö versionhallintaan käytetään CVS-ohjelmistoa. yhdenmukainen dokumentointiformaatti LaTeX dokumenttien tarkastukset (Katselmoinnit) 10 Projektin ositus, vaiheistus ja resursointi Tässä luvussa esitellään projektin päävaiheet sisältöineen ja vaiheiden kriittiset päivämäärät. Luvussa esitellään myös asiat jotka projektin johtoryhmä haluaa tarkistaa projektikatselmuksessa pystyäkseen arvioimaan projektin etenemistä kyseisessä vaiheessa. Vastuunjako projektin sisällä: Koskenvaara Tuomo (Projektipäällikkö 15.1.2002 asti) - Projektin kokonaisvastuu 15.1.2002 asti - Työnjako, suunnittelu, raportointi (Haapaniemi Arin kanssa) - Aikataulutus (Haapaniemi Arin kanssa) - Mittarien seuranta (Haapaniemi Arin kanssa) - Avustaa muita apua tarvitsevia - Petri Kujalan varamies Kujala Petri (Ohjelmistosuunnittelija II) - Riskienhallintasuunnitelma - Kokoonpanovastuu, vastaa osien yhteensovittamisesta - Tekninen määrittely Jussi Vainionpään kanssa - Avustaa kaikissa ohjelmiston suunnitteluun tarvittavissa asioissa - Antti Haapakosken varamies Haapaniemi Ari (käyttöliittymävastaava ja projektipäälikkö 16.1.2002 lähtien) - Projektin kokonaisvastuu 16.1.2002 lähtien. - Työnjako, suunnittelu, raportointi (Koskenvaara Tuomon kanssa) - Aikataulutus (Koskenvaara Tuomon kanssa) - Mittarien seuranta (Koskenvaara Tuomon kanssa) - Konfiguraattorin ohjelmoinnin päävastuu - Käyttöliittymäsuunnittelu 18
- Mikko Martsolan varamies Haapakoski Antti (Ohjelmistosuunnittelija I) - Dokumenttien hallinta/tarkastaminen - Vaatimusmäärittely - Lajittelija-osion ohjelmointivastuu - Tuomo Koskenvaaran varamies Martsola Mikko (Ohjelmoija I) - Asennusohjelmiston ohjelmoinnin päävastuu - Laitteistovaatimukset - Ari Haapaniemen varamies Myyry Jani (Testi- ja päättelykoneintegrointi-vastaava) - Päättelykoneintegrointi - Testisuunnitelma ja toteuttaminen - Projektin www-sivujen ylläpito - Jussi Vainionpään varamies Vainionpää Jussi (Ohjelmoija II) - Tekninen määrittely Petri Kujalan kanssa - Mittarit, niiden valinta ja käyttöperiaatteet - Jani Myyryn varamies Seuraavan vaiheen tarkat tehtävät suunnitellaan viimeistään edellisen vaiheen lopussa, kun seuraavan vaiheen tavoitteet ja lopputulokset on tarkennettu. 10.1 Projektin suunnittelu Projektin suunnitteluvaiheen päätehtävät ovat projektisuunnitelman laatiminen ja vaatimuksien määrittely. Tässä vaiheessa tuotettavat dokumentit ovat: Projektisuunnitelma Aikataulu Vaatimusmäärittely Edistymisraportti. Dokumentit valmiita sisäiseen katselmointiin: 24.10.2001 24:00 Sisäinen katselmointi: 25.10.2001 Sisäinen aikaraja: 26.10.2001 Asiakaskatselmointi: 29.-30.10.2001 Viimeistellyt, palautettavat dokumentit: 30.10.2001 projektipäälliköllä Kurssin virallinen aikaraja: 30.10.2001 Resursointi on suurimpien kokonaisuuksien osalta jaettu taulukon 10.1 mukaisesti. 19
Tehtävä Osatehtävä Tekijä arv. h Projektisuunnitelma Päävastuu, kirjoitus Koskenvaara Tuomo 30 Oikeudet järjestelmään Koskenvaara Tuomo ja asiakkaan 1 edustaja Asiakasvaatimukset Haapakoski Antti 3 Asiakasvaatimukset Vainionpää Jussi 3,5 Vaatimusmäärittely Päävastuu, kirjoittaminen Haapakoski Antti 8 Käyttötapaukset Kujala Petri & Vainionpää Jussi 6 Suunnittelupalaverit Haapaniemi Ari, Haapakoski Antti, 30 Myyry Jani, Mikko Martsola, Kujala Petri, Vainionpää Jussi Käyttöliittymä Haapaniemi Ari 3 Avustava kirjoittaja Kujala Petri 4 Dokumenttipohjat Laatiminen esimerkkipohjista Haapakoski Antti 2 Palaverit, muut kuin Osallistuminen Kaikki, osanotto riippuvainen palaverin 50 suunnittelu- luonteesta Pöytäkirjojen kirjoitus Kaikki vuorollaan 5 Asialistojen kirjoittaminen Koskenvaara Tuomo, suunnittelupalaverit Haapakoski Antti / Kujala Petri 2 Opiskelu + wwwsivuston Teknologiat, kirjallisuus, kurssit, Kaikki 37 teko tekeminen Kurssin luennot Kaikki vapaavalintaisesti 37 Raportointi Kokonaisvastuu: edistymis- ja viikkoraportit Koskenvaara Tuomo 2 Henkilökohtainen tuntiraportointi Kaikki 5 Tiranaan Katselmoinnit Päävastuu järjestämisestä ja prosessista Myyry Jani 2 Osallistuminen Kaikki vuorollaan 38 Aikataulu Laatija Koskenvaara Tuomo 4 Muut 6,5 Yhteensä 279 Taulukko 6: PS-Vaiheen tehtävät 20
10.2 Toteutus 1 Toteutus 1 -vaiheessa tehdään ensimmäinen versio toiminnallisesta- ja teknisestä määrittelystä. Näitä varten tutkitaan vaihtoehtoisia toteutustapoja, joista valitaan toimivimmat. Kun ohjelmiston rakenne on saatu määritettyä tehdään sen perusteella testaussuunnitelma. Myös ensimmäinen versio käyttöliittymästä esitellään paperiprototyypin muodossa. Vaiheen puolivälin jälkeen pidetään palaveri, jossa päätetään MUST-prioriteetilla olevien vaatimusten aikaraja. Samalla voidaan keskustella tarkemmin Usefull-prioriteetillä olevien vaatimusten toteuttamisesta. Näitä tietoja voidaan tarkentaa myöhemmissä palavereissa tarpeen mukaan. Tuotettavat dokumentit: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Toiminnallinen määrittely Tekninen määrittely Testaussuunnitelma Edistymisraportti Käyttöliittymän demo Täytetyt asiakasvaatimukset 10.12.2001 mennessä: UR-1 UR-3 UR-9 Dokumentit valmiita sisäiseen katselmointiin: 28.11.2001 24:00 Sisäiset katselmoinnit: 30.11.2001 Asiakaskatselmointi: 5.12.-10.12.2001 Viimeistellyt, palautettavat dokumentit: 10.12.2001 projektipäälliköllä Kurssin virallinen aikaraja: 11.12.2001 Resursointi hoidetaan taulukon 10.2 mukaisesti. 21
Tehtävä Osatehtävä Tekijä arv. h Projektisuunnitelma Kirjoittaja Koskenvaara Tuomo 8 ja aikataulu, päivitys Vaatimusmäärittely, Kirjoittaja Haapakoski Antti 2 päivitys Toiminnallinen määrittely Päävastuu Kujala Petri 8 Osioiden laatiminen omista komponenteistpaniemi Myyry Jani, Martsola Mikko, Haa- 12 Ari, Haapakoski Antti Järjestelmän suunnittelu Kujala Petri, Vainionpää Jussi 8 Tekninen määrittely Päävastuu Vainionpää Jussi 8 Osioiden laatiminen omista komponenteistpaniemi Myyry Jani, Martsola Mikko, Haa- 20 Ari, Haapakoski Antti Testaussuunnitelma Päävastuu Myyry Jani 3 Osavastuu omien komponenttien Myyry Jani, Martsola Mikko, Haapaniemi 8 osalta Ari, Haapakoski Antti Käyttöliittymä Haapaniemi Ari 2 Testaaminen Kujala Petri, Vainionpää Jussi 4 Ohjelmointi Päävastuu Kujala Petri 3 Päättelykone rajapinta Myyry Jani 5 Lajittelijaosio Haapakoski Antti 8 Asentajaosio Martsola Mikko 8 Valitsinosio Haapaniemi Ari, Vainionpää Jussi 16 Teknologian testaus Kujala Petri, Martsola Mikko, Vainionpää 19,5 Jussi Käyttöliittymä Paperiprototyyppi Haapaniemi Ari, Martsola Mikko 10 Palaverit Osallistuminen Kaikki, osanotto riippuvainen palaverin 39,5 luonteesta Pöytäkirjojen kirjoitus Kaikki vuorollaan 4 Asialistojen kirjoittaminen Koskenvaara Tuomo, muutoin erikseen 1 määrätty puheenjohtaja. Opiskelu Teknologiat Tekniset henkilöt 21 Kurssin luennot Kaikki vapaavalintaisesti 0 Raportointi Kokonaisvastuu: edistymis- ja viikkoraportit Haapaniemi Ari, Koskenvaara Tuomo 6 Henkilökohtainen tuntiraportointi Kaikki 4 Tiranaan Katselmoinnit Päävastuu järjestämisestä ja prosessista Martsola Mikko 2 Osallistuminen Kaikki vuorollaan 39 WWW-sivusto Sivuston ylläpito Haapakoski Antti, Myyry Jani 5 Muut 37,5 Yhteensä 294 Taulukko 7: T1-Vaiheen tehtävät 22
10.3 Toteutus 2 Tässä vaiheessa toteutetaan ohjelmiston perustoiminnallisuus valmiiksi ja aloitetaan systeemitestaaminen. Käyttöliittymässä toteutetaan myös perustoiminnallisuus. Käyttöliittymä perustuu aiemmin tehtyyn paperiprototyyppiin ja sen testeistä saatuihin kommentteihin. Vaiheen aikana pidetään palaveri (viikkolla 3) vaatimusmäärittelyssä priorisoitujen vaatimusten toteutusaikataulun tarkentamiseksi. Samalla käsitellään useful- ja NiceToHave-prioriteetillä olevia vaatimuksia. Tuotettavat dokumentit: Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Tarkennettu toiminnallinen määrittely Tarkennettu tekninen määrittely Tarkennettu testaussuunnitelma Testausraportti Edistymisraportti Täytetyt asiakasvaatimukset 13.1.2002 mennessä: UR-4 UR-5 UR-6 UR-27 6.2.2002 mennessä: UR-8 UR-14 UR-17 UR-19 UR-20 UR-21 Dokumentit valmiita sisäiseen katselmointiin: 1.2.2002 24:00 Sisäiset katselmoinnit: 4.2.2002 Sisäinen aikaraja: 5.2.2002 Asiakaskatselmointi: 6.2.-10.2.2002 Viimeistellyt, palautettavat dokumentit: 11.2.2002 projektipäälliköllä Kurssin virallinen aikaraja: 12.2.2002 Resursointi hoidetaan taulukon 10.3 mukaisesti. 23