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

Transkriptio

1 Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu LAATUKÄSIKIRJA LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: Tekijä: Niko Tolvanen Kommentit: Hyväksyi: Katariina Ylinen, Maaret Pyhäjärvi

2 VERSIOHISTORIA Versio Päivämäärä Muutokset Muuttaja Alustava versio yhtenä dokumenttina. Aiemmin koostunut useista dokumenteista. Niko Tolvanen Katselmointikorjaukset tehty Niko Tolvanen Asiakaskatselmoinnin korjaukset tehty Niko Tolvanen

3 1. JOHDANTO MÄÄRITELMÄT, TERMIT JA LYHENTEET TAUSTAA HUOMIOITAVAA VASTUUT JA TOTEUTTAMINEN 8 2. PROJEKTINHALLINTAAN LIITTYVÄT KÄYTÄNNÖT YLEISTÄ JÄSENKOHTAINEN VASTUUNJAKO PROJEKTIPÄÄLLIKKÖ KATARIINA YLINEN LAATUPÄÄLLIKKÖ NIKO TOLVANEN JÄRJESTELMÄARKKITEHTI KIMMO KUJALA KÄYTTÖLIITTYMÄSUUNNITTELIJA MINNA REINO OHJELMOIJA EERO JYSKE OHJELMOIJA MAARET PYHÄJÄRVI OHJELMOIJA ANTTI SILLANPÄÄ OHJELMOIJAT KOLLEKTIIVISESTI JÄRJESTELMÄARKKITEHDIN JOHDOLLA MITTARIT KÄYTETTÄVÄT MITTARIT Projektinhallinta Tuotteen laatu Prosessien laatu RISKIENHALLINTAPROSESSI RISKILUETTELON LUOMINEN RISKIEN ARVOTTAMINEN JA ASETTAMINEN VAKAVUUSJÄRJESTYKSEEN TAVAT VARAUTUA RISKEIHIN RISKIENHALLINNAN RAJOITUKSISTA ASIAKASKOMMUNIKAATIO KÄYTÄNTÖ ASIAKASRAPORTOINTI SOVITTU KÄYTÄNTÖ TUNTIRAPORTOINTI SOVITTU KÄYTÄNTÖ TUNTIRAPORTOINNIN TYÖLAJIT KOKOUSKÄYTÄNNÖT KÄYTÄNNÖT Ennen kokousta Kokouksen alkaessa Kokouksen aikana Kokouksen jälkeen KATSELMOINNIT DOKUMENTTIEN KATSELMOINTI KOODIN KATSELMOINTI VASTUUT DOKUMENTTIEN JULKAISEMINEN FTP-PALVELIMEN KÄYTTÖ TUOTTEENHALLINTAAN LIITTYVÄT KÄYTÄNNÖT ASIAKKAAN VAATIMUSTEN KÄSITTELEMINEN 26

4 3.2 MUUTOSTENHALLINTA ASIAKKAAN EHDOTTAMA MUUTOS RYHMÄN SISÄLLÄ EHDOTETUT MUUTOKSET BUGIN JA MUUTOKSEN ERO VERSIONHALLINTA DOKUMENTTIEN VERSIOINTI TUOTTEEN VERSIONHALLINTA LÄHDEKOODITIEDOSTOJEN MALLIPOHJA VERSIONHALLINNAN TYÖKALUT TUOTANTOPROSESSIIN LIITTYVÄT KÄYTÄNNÖT KOODAUSKÄYTÄNNÖT YLEISTÄ KOMMENTOINTI NIMEYSKÄYTÄNNÖT: MUUTTUJAT, METODIT, VAKIOT JA LUOKAT SULUT JA SISENNYKSET KÄYTETTÄVÄT TYÖKALUT OHJELMOINTI JA LÄHDEKOODIN KÄÄNTÄMINEN TOTEUTUSYMPÄRISTÖ WEB-SIVUJEN LUOMINEN DOKUMENTTIEN KIRJOITTAMINEN AIKATAULUN LUOMINEN AIKATAULUN SEURANTA JA TUNTIRAPORTOINTI VIRHERAPORTOINTI ASIAKASRAPORTOINTI VERSIONHALLINTA TESTAUS YMPÄRISTÖN JA JÄRJESTELMÄN ASENNUSOHJE OHJELMISTON LOKALISOITAVUUS LOKALISOITAVUUDEN VAATIMUKSET LOKALISOITAVUUS TÄSSÄ PROJEKTISSA VARMUUSKOPIOINTIKÄYTÄNTÖ VIRHERAPORTOINTI BENCHMARKING BENCHMARKINGIN TAUSTAA BENCHMARKING LIKE-PROJEKTISSA KÄYTTÖLIITTYMÄN SUUNNITTELU NAVIGAATIOKARTTA PAPERIPROTO KÄYTTÖLIITTYMÄN TOTEUTUS I-VAIHE KÄYTTÖLIITTYMÄN TOTEUTUS II -VAIHE KÄYTTÖOHJE KÄYTTÖLIITTYMÄN KÄYTETTÄVYYSTESTAUS TESTAUSSUUNNITELMA KÄYTETTÄVYYSTESTIT HENKILÖSTÖÖN LIITTYVÄT KÄYTÄNNÖT HENKILÖSTÖN KEHITTÄMINEN ASIAKASKOULUTUS ASIAKKAALLE ANNETTAVA KOULUTUS 43

5 Prosessikoulutus Koulutus virheiden raportointiin Hyväksyntätestauksen suorittaminen Järjestelmäkoulutus 44

6 1. JOHDANTO Tämä dokumentti on LiKe-järjestelmän laatuprosessin yleinen kuvaus, joka sisältää projektissa noudatettavien käytäntöjen ja toimintatapojen kuvaukset. Dokumentti on tarkoitettu n sisäiseen käyttöön, asiakkaalle ja kurssin henkilökunnalle. 1.1 MÄÄRITELMÄT, TERMIT JA LYHENTEET LiKe-projektissa ja tässä dokumentissa käytetyt määritelmät, termit ja lyhenteet on selitetty alla taulukossa 1. Taulukko 1. Projektissa käytettävät termit ja niiden selitykset Prosessi, jossa asiakas tarkastelee palautuksia ja esittää mahdolliset Asiakaskatselmointi parannusehdotukset ryhmälle. Asiakasosa Järjestelmän käyttäjän koneella sijaitseva osa ASP Active Server Pages. Teknologia, jolla voidaan luoda logiikkaa sisältäviä www-sivuja. Buildi Järjestelmän testaukseen julkaistava versio. Järjestelmän viimeinen luotava buildi on sen julkaistava versio. BVT Build Verification Test, tarkistus joka tehdään ohjelmiston jokaiselle versioehdotelmalle ennen kuin siitä tulee versio. C++ Oliopohjainen ohjelmointikieli. Client/server Asiakas-palvelin. Sovellus tai järjestelmä, jossa asiakas käyttää paikalliselta koneelta asiakasohjelmaa ottaakseen yhteyden palvelinkoneeseen. EN Englannin kielen kaksikirjaiminen standardilyhenne 1

7 EJB Enterprise Java Beans. Java-kielellä toteutettuja ohjelmakomponentteja FI Suomen kielen kaksikirjaiminen standardilyhenne HTML Hypertext Markup Language. Web-sivustojen sivunkuvauskieli IIS Microsoft Internet Information Server. Microsoftin web-palvelinsovellus. Java Oliopohjainen ohjelmointikieli. JavaScript Esim. JSP-sivuilla käytetty komentosarjakieli. Johto Yrityksen tai yksikön, jonka kehittämistoimia koordinoidaan, ylin johto, joka asettaa tavoitteita kehittämiselle ja haluaa yleisellä tasolla pystyä seuraamaan koko yrityksen kehittämisprojektien tilannetta ja saavutettuja hyötyjä. Johto pohtii uusien kehittämishankkeiden käynnistämisen tarpeellisuutta ja tarpeellisuuden todetessaan asettaa suunnittelijan tai sallii jonkun yrityksen työntekijän ottaa itselleen suunnittelijan roolin hankkeessa. JSP Java Server Pages. ASP:tä vastaava teknologia, jossa käytetään toteutukseen Javaa. Yksilöt, jotka ovat saaneet vastuulleen kehittämisen tukijärjestelmän hallinnoinnin. Pitävät huolta että kaikilla on tarvittavat oikeudet tehokkaan tiedonjaon mahdollistamiseksi. Tarkkailevat järjestelmän Järjestelmänvalvoja käyttöä antaen näin arvioita järjestelmän käytöstä saadusta hyödystä. Voivat teknisesti rajata ja suunnata järjestelmän käyttöä sekä käyttöoikeuksien että järjestelmästä tarjottavan dokumentaation suhteen. Kehittäjän karttakirja Nykyinen tapa tarjota kehittämistoiminnan tukemiseen materiaalia. Käyttöliittymä paikallisella levyllä säilytettäviin dokumentteihin; 2

8 karttakirja Vaiheittaisen kehittämisen ohjeistus; TAI-tutkimuslaitoksen luoma liiketoiminnan kehittämisen tukijärjestelmä. Kehittämiskonsultti Organisaation ulkopuolinen ihminen, joka tukee tyypillisesti sisäistä kehittämisprojektia. Asettaa vaatimuksia järjestelmän tarjoamalle tietoaineistolle, sillä kehittämiskonsultin roolista ja tehdyistä salassapitosopimuksista riippuen on mahdollista, että kaikkea sisäistä tietoaineistoa ei kehittämiskonsultille haluta näyttää. Voi toimia suunnittelijan, osallistujan tai toteuttajan roolissa projektissa. KePRO TAI-tutkimuslaitoksen Kookos-projektia edeltänyt kehittämistoimintaa käsitellyt tutkimusprojekti. Knowledge Storage TAI-tutkimuslaitoksen luoma käyttäjäkeskeisen tuotekehityksen tietotukeen liittyvä sovellus. Kookos TAI-tutkimuslaitoksen projekti, jonka työhön ohjelmatyöryhmän LiKe-projekti kuuluu. Käyttäjäsovellus LiKe-järjestelmään mahdollisesti toteutettava lisäosa, jonka avulla erilaiset tiedostot voidaan avata suoraan niiden käsittelyyn määritetyssä sovelluksessa. LiKe Ohjelmatyöryhmän projekti, jonka tavoitteena on tässä suunnitelmassa kuvatun projektin läpivieminen; käytetään myös synonyyminä tehtävälle järjestelmälle. Liiketoiminnan kehityksen tukiprojekti. Toteuttavan palvelun työnimi. Metadata/Metatieto Järjestelmän tietoaineistoon (projektit, käyttäjät, dokumentit) liitettävä lisätieto, jonka perusteella aineistoa voidaan hakea ja lajitella. Osallistuja Kehittämisprojektin osallinen, joka ei itse varsinaisesti tee työtä kehityksen eteen, mutta jonka muutosvastarinnan voittaminen on kriittistä projektin onnistumismahdollisuuksien kannalta. Tarvitsee järjestelmästä informaatiota itseään koskevista asioista voidakseen 3

9 suhtautua niihin järkevästi ja voidakseen halutessaan vaikuttaa tietopohjalta tuleviin muutoksiin. Palvelinosa LiKe-järjestelmän palvelimella sijaitsevien toiminnallisuuksien joukko. Peruskarttakirja Kehittäjän karttakirjan perustietoaineistopaketti, joka kattaa liiketoiminnan kehittämisen kaikki vaiheet. Peruskarttakirjan materiaali on TAI:n tuottamaa ja sen kehittämisestä vastaa TAI:n Kookos-projekti. Materiaali, jonka pohjalta LiKe-järjestelmän projektien tietoaineisto luodaan. Projekti Tietokokonaisuus kehittämistoiminnassa. TAI:n Kookos-projektissa uskotaan, että jatkuvakin kehittäminen on onnistumisen takaamiseksi syytä organisoida projektimuotoon eli sille on määrättävä alku- ja loppupäivä ja siihen tulee soveltaa projektin arviointitapoja. Järjestelmässä materiaali jaetaan projekteihin ja kokonaisuuksia hallitaan projekteina, mutta järjestelmän projektin käyttäminen eri tarkoituksiin on mahdollista. Voidaan esim. luoda projekti kullekin liiketoimintayksikölle, joka on luonteeltaan jatkuva eikä projektimuotoinen. Mikäli järjestelmässä halutaan säilyttää materiaalia, joka ei tarvitse omaa projektiaan, on mahdollista luoda koontiprojekti, johon kerätä useampiakin vastaavia materiaaleja. Projekti on abstraktio dokumenteista, joihin oikeudet määritellään ryhmänä. Mikäli käyttäjällä on oikeuksia projektin johonkin dokumenttiin, on samat oikeudet muihinkin kyseisen projektin dokumentteihin. Jos dokumenttitasolla halutaan rajata oikeuksia, dokumentit tulee jakaa kahteen järjestelmän projektiin, vaikkakin niitä voidaan hyvin ajatella yhtenä projektina, joka jakaantuu esim. sisäiseen ja yleiseen tietoon. Prosessi Toimintojen sarja, jolla päästään jostain lähtötilasta johonkin tavoitetilaan. 4

10 RTT Release To Testing, prosessi jonka kautta järjestelmän versio siirtyy kehityksestä testaukseen. Sisäinen aikaraja Projektiryhmän sisäinen aikaraja esim. dokumenttien kirjoittamiselle, joka on viikkoa aikaisempi kuin kurssin asettama aikaraja. Palautukset lähetetään asiakkaalle tähän aikarajaan mennessä. Sisäinen katselmointi Projektiryhmän sisäinen katselmointi, joka tapahtuu ennen sisäistä aikarajaa (eli dokumenttien lähettämistä asiakkaalle). Sovellusohjelma Ohjelma, jolla järjestelmään tallennettu dokumentti on luotu ja jota käytetään dokumentin tarkastelemiseen ja muokkaamiseen. SQL Structured Query Language. Relaatiotietokantojen tukeman kyselykieli. Suunnittelija Kehittämisprojektin suunnittelija, joka käynnistää kehittämisprojektin ja on mukana asettamassa sen tavoitteita ja tapoja päästä tavoitteisiin. Ei välttämättä ole mukana jokapäiväisessä kehittämistyössä vaan asettaa tavoitteita ja suuntaviivoja ylhäältä Toteuttaja Kehittämisprojektin projektipäällikkö tai muu aktiivinen yksilö, joka tuottaa ja käyttää materiaalia kehittämisprojektiin liittyen mahdollisesti suunnittelijan asettamien suuntaviivojen mukaisesti. Toteuttaja ei siis voi vaikuttaa kehittämishankkeen tavoitteisiin, vaan hän saa ne suunnittelijalta. UNC Universal Naming Convention, normaali tapa ilmaista Windowspolkunimiä (\\koneen_nimi\resurssin_nimi\kansion_nimi\alikansioiden nimet\tiedosto.tunniste) UML Unified Modeling Language, standardoitu kuvauskieli. URL Uniform Resource Locator. Standarditapa ilmaista tiedostojen sijainteja siten, että myös tiedonsiirtoprotokolla mainitaan (esim. 5

11 on URL-osoite). USDP Unified Software Development Process, iteratiivinen ja inkrementaalinen ohjelmistokehityksen menetelmä, joka pohjautuu käyttötapauksiin. Web-pohjainen käyttöliittymä LiKe-järjestelmän käyttäjälle näkyvä osa, joka koostuu HTMLsivuista. Use case Tapa mallintaa vaatimuksia kuvaamalla oikeita käyttötapauksia. 1.2 TAUSTAA Tässä dokumentissa määritetään projektissa käytettävä lähestymistapa laadukkaan lopputuloksen takaamiseksi. Tähän määrittämiseen on ryhdytty kahdesta syystä: 1. Laatu ei synny projektiin itsestään, joten strukturoidun prosessin käyttäminen on järkevää. 2. Laatuprosessin soveltaminen (joka viime kädessä takaa onnistuneen lopputuloksen) ei ole mahdollista, ellei prosessia ole määritetty heti projektin alkaessa ja sovellettu läpi projektin. Laatu lähtee käytettävistä menetelmistä, ja se sisältää laadunvarmistuksen (sekä lopputuloksen oikeellisuuden tarkistamisen vaatimuksien suhteen että sen, että vaatimukset ovat oikeat). Ilman suunnittelua ja oikeita menettelytapoja laadukkaaseen lopputulokseen pääseminen ei ole kovinkaan todennäköistä. Laadun määritelmä tässä projektissa lähtee asiakkaan kokemasta laadusta: asiakastyytyväisyys on koko laatujärjestelmän tärkein tavoite. Laatujärjestelmän ensimmäinen tavoite on luoda mahdollisuus varmistaa tämä laatu, seurata sen saavuttamista ja tarvittaessa määrittää tapoja korjata tehtyjä virheitä asiakastyytyväisyyden saavuttamiseksi. Laatuprosessin tärkeimmät menetelmät ovat prosessien tarkan määrittämisen lisäksi eri vaiheissa tapahtuvat katselmoinnit ja muut laadunvarmistukseen liittyvät toimet (kuten 6

12 järjestelmän huolellinen testaaminen). Näissä katselmoinnissa myös asiakkaalla on oma roolinsa: asiakkaalle annetaan mahdollisuus esittää tuotteeseen ja dokumentointiin liittyvissä asioissa oma näkemyksensä samalla tavalla kuin kenellä tahansa ryhmän jäsenellä. Luonnollisesti ryhmä suorittaa oman laadunvarmistuksensa (esimerkiksi katselmoinnit) ennen asiakkaan mukaantuloa. Laatuprosessi ei vaikuta pelkästään syntyvään lopputuotteeseen vaan myös aikatauluun, jonka puitteissa tuote on mahdollista toteuttaa. ssä uskotaan, että huolellisella suunnittelulla ja laadukkailla prosesseilla voidaan myös säästää aikaa, sillä asian tekeminen kerralla oikein vie yleensä vähemmän aikaa kuin virheiden jatkuva korjaaminen. Lisäksi virheiden jatkuva korjaaminen synnyttää todennäköisesti uusia virheitä, joten tehdyt virheet saattavat kumuloitua lopulta hallitsemattomiksi Huomioitavaa Laatuprosessia määriteltäessä on pyritty ottamaan projektin luonne huomioon ja välttämään laadun tuottamiseen liian ylimääräisen työn luomista nk. lopputuloksia tuottavan työn lisäksi. Uskomme, että jonkinlainen panostus laadun tekemiseen on kuitenkin kannattavaa. Etukäteissuunnittelulla voimme koittaa vaikuttaa arvioiden realistisuuteen ja välttää tilanteen, jossa järjestelmä on arvioitu valmiiksi mutta sen laadun hiomiseen on käytettävä vielä huomattava määrä aikaa. Projektiryhmän jäsenet tiedostavat, että asioiden uudelleen keksiminen on ylimääräistä työtä. Niinpä laadun luomisen perusprosesseihin kuuluu benchmarking. LiKe-projektin asiakkaana toimii TAI Tutkimuslaitoksen Kookos-projekti, jonka ydinosaamisalue on liiketoiminnan kehittäminen ja siihen liittyvät prosessit ja liiketoiminnan kehittämisprojektien läpivienti. Asiakkaalla ei ole kokemusta järjestelmänkehittämistyöstä, joten asiakkaalle erilainen visualisointi on erittäin tärkeää. Tätä tarvetta pyrkii täyttämään käyttötapaus- ja käyttöliittymälähtöisellä suunnittelulla. Käyttöliittymätestaus alkaa heti projektin alussa ja asiakkaan kanssa käydään läpi keskustellen paperiprototyyppien useiden versioiden avulla eri toiminnallisuuksien toteutusta, hakien tarvittavaa sitoutumista työn alla olevaan asiaan. 7

13 1.3 VASTUUT JA TOTEUTTAMINEN Ensisijainen vastuu laatuprosessin toteuttamisesta on projektin laatuvastaavalla. Tämä yksin ei kuitenkaan riitä, vaan jokaisen on otettava vastuu oman työnsä laadusta, noudatettava yhteisesti sovittuja prosesseja ja käytäntöjä sekä mietittävä joka asiaa tehdessään sitä, kuinka asia kannattaa tehdä, jotta se palvelisi parhaiten projektin tavoitteita. Laatuvastaava valvoo ja tukee prosessien käyttöä tarpeen mukaan järjestämällä projektiryhmälle ja asiakkaalle koulutusta odotetuista toimintatavoista. 2. PROJEKTINHALLINTAAN LIITTYVÄT KÄYTÄNNÖT 2.1 YLEISTÄ Lähtökohtaisesti kukin projektiryhmän jäsen on vastuussa omasta osa-alueestaan. Vastuu ssä tarkoittaa sitä, että kyseinen ihminen raportoi vastaamistaan osaalueista viikkopalavereissa ja vastaa siitä, että ne etenevät, viime kädessä tekemällä itse. Projektipäällikkö vastaa lisäksi koko projektin onnistumisesta. Ryhmän jäsenten vastuualueet on lueteltu alla. 2.2 JÄSENKOHTAINEN VASTUUNJAKO Projektipäällikkö Katariina Ylinen Projektin kokonaisvastuu Työnjako, projektin suunnittelu ja raportointi asiakkaalle Aikataulun seuranta Katselmointiprosessi Muutostenhallinnan johtaminen/koordinointi Hyväksymistestaussuunnitelman teko asiakkaan kanssa Asiakkaan mukanaolo järjestelmäarkkitehtuurin suunnittelussa 8

14 Päättökriteerien määrittäminen Koulutukset asiakkaalle Vaatimusten ymmärtäminen samoin asiakkaan ja ryhmän välillä Mittarien seuranta Ohjelmoija Maaret Pyhäjärven varahenkilö Laatupäällikkö Niko Tolvanen Ongelmanratkaisu- ja riskienhallintasuunnitelma Laatu- ja yleissuunnitelma Mittarit, niiden luonti ja käyttöperiaatteet Testauksen suunnittelu, koordinointi ja seuranta; testitapausten suunnittelu, testauksen toteutus ja automatisointi yhdessä ohjelmoijien kanssa; sekä testauksen arviointi Päävastuu dokumenttien laadusta ja koostamisesta eri henkilöiden kirjoittamista osista Opponointi Projektipäällikkö Katariina Ylisen varahenkilö Järjestelmäarkkitehti Kimmo Kujala Kokoonpanon hallinta: versionhallintajärjestelmän luominen, ohjeistukset, ylläpito Build-prosessin hallinta, RTT Järjestelmäarkkitehtuurin päävastuu ja vastuu yhteensovittamisesta Koodausvastuiden jakaminen, seuranta toteutumiselle ja laajuudelle Testaukseen kelvollisten komponenttien valinta/bvt:t Ohjelmoinnin kokonaisvastuu 9

15 Ohjelmoija Antti Sillanpään varahenkilö Käyttöliittymäsuunnittelija Minna Reino Vaatimusmäärittelyn kirjoitusvastuu yhdessä Eero Jyskeen kanssa Käyttöliittymäsuunnittelu ja prototyypit Yhteistyö käyttöliittymätutkimukseen liittyen asiakkaan kanssa Käyttöohjeet (järjestelmän kanssa integroidut ja erilliset käyttöoppaat) Koulutusmateriaali Graafinen suunnittelu Käyttöliittymätestaus Laatuvastaava Niko Tolvasen varahenkilö Ohjelmoija Eero Jyske Vaatimusmäärittelyn kirjoitusvastuu yhdessä Minna Reinon kanssa Järjestelmäarkkitehti Kimmo Kujalan varahenkilö Ohjelmoija Maaret Pyhäjärvi Käytettävien työkalujen valinta ja dokumentointi Projektiryhmän WWW-sivujen ylläpito Dokumenttien palauttaminen ja julkaisu Käyttöliittymäsuunnittelija Minna Reinon varahenkilö Ohjelmoija Antti Sillanpää Ohjelmoija Eero Jyskeen varahenkilö Ohjelmoijat kollektiivisesti järjestelmäarkkitehdin johdolla Osavastuut järjestelmäarkkitehtuurista 10

16 Yksikkötestaus Testauksen toteutus ja automatisointi yhdessä laatupäällikön kanssa Osavastuut moduulien toteutuksesta ja testauksesta Osavastuut testi- ja virheraporttien kirjoittamisesta. 2.3 MITTARIT Projektissa käytettävät mittarit voidaan jakaa Rationalin USDP-prosessin ohjeistuksen (RUP) mukaisesti kahteen pääluokkaan: tietoa lisäävät mittarit ja muutosta mittaavat mittarit. Koska kyseessä on verraten lyhyt projekti, jossa tuotteesta tehdään vain yksi versio, mittarien pääpaino on ensimmäisessä kategoriassa. Kullekin mittarille määritetään projektin edetessä tavoitearvot. Tavoitearvoja ei kannata määrittää ennen teknisen toteutuksen tarkempaa suunnittelua, joten nämä arvot määritetään Toteutus 2 -vaiheen alussa Käytettävät mittarit Mittarit voidaan jakaa edelleen niiden mittaaman asian suhteen kolmeen luokkaan. Tässä projektissa käytetyt luokat on lueteltu alla. 1. Projektinhallinta/edistyminen 2. Tuotteen laatu/tekniset asiat 3. Prosessien laatu Nämä luokat jaetaan edelleen aliluokkiin; alla kunkin luokan mittareita käsitellään erikseen. Alla oleva mittarivalikoima on alustava; mittareita luodaan lisää ohjelmiston teknisen toteutuksen tarkentuessa ja projektin edetessä ryhmän saadessa tarkempaa tietoa erilaisten mittarien tarpeesta. 11

17 Projektinhallinta Mittari Syy Toteutus Aikataulun perusteella mitattava edistyminen Kunkin tehtävän kohdalla arvioidaan prosentteina osuus, Saadaan selville, kuinka suuri joka siitä on jo tehty suhteessa osa työstä on tehty/tekemättä; käytettyyn tuntimäärään. voidaan arvioida tulevien Työkaluina käytetään kurssin tehtävien toteuttamisen tarjoamia työkaluja (Microsoft mahdollisuuksia. Project ja Tiranatuntiraportointijärjestelmä).. Käytettyjen tuntien määrä Käytännössä käytetään kurssin Tiedetään, kuinka monta tuntiraportointijärjestelmää. tuntia projektiin on kulunut ja Tämän mittarin seuranta pystytään suhteuttamaan tapahtuu yhdessä edellä tähän toteutettavia asioita. mainitun mittarin kanssa Tuotteen laatu Mittari Syy Toteutus Raportoitujen yksilöllisten virheiden määrä suhteessa ohjelmiston kokoon. Saadaan selville, kuinka hyvin ohjelmisto täyttää vaatimuksensa ja kuinka suuri määrä virheitä sen toteutuksessa on tapahtunut. Ohjelmistossa havaitut virheet kirjataan Buranajärjestelmään, jossa niiden määrää seurataan. Ohjelmiston koko mitataan varsinaisten koodirivien määrällä (pl. kommenttirivit ja tyhjät rivit). Koodin kommentointi Saadaan selville, kuinka havainnollista ohjelmiston Kommenttirivien osuus kaikista lähdekoodiriveistä. 12

18 lähdekoodi on ulkopuolisille. Tämä määrää käytännössä ohjelmiston jatkokehittämisen helppouden. Testauksen kattavuus suhteessa tuotteen kokoon koodiriveinä/muihin kattavuusmittareihin Saadaan selville, kuinka suuren osan ohjelmiston eri toiminnoista testaus kattaa. Käytetään testauksen yhteydessä automaattista kattavuuden mittaamiseen tarkoitettua työkalua. Ohjelmiston käytön opittavuus Saadaan selville, kuinka hyvin ohjelmiston käytettävyystavoite on täyttynyt. Aika, joka uudelta käyttäjältä kuluu järjestelmän käytön opettelemiseen. Tämä mittaaminen tapahtuu kahdessa osassa: ensin noin projektin puolivälissä ja toiseen kertaan projektin lopussa. Vaatimusten täyttyminen Saadaan selville, kuinka hyvin ohjelmisto ratkaisee asiakkaan ongelman. Lasketaan, kuinka monta prosenttia asiakkaan eri prioriteettiluokkien vaatimuksista täyttyy. Lisäksi ohjelmiston teknisiä ominaisuuksia verrataan vaatimuksiin korrelaatiomatriisin avulla. Ohjelmiston koko Lasketaan ohjelmiston Saadaan selville, kuinka laaja lähdekoodirivien määrä (pl. ohjelmisto on. kommenttirivit ja tyhjät rivit). 13

19 Prosessien laatu Mittari Syy Toteutus Projektinhallintaan käytetyt tunnit suhteessa todellisiin työtunteihin. Saadaan selville, kuinka suuri osa ajasta käytetään työhön, joka ei tuota asiakkaalle lisäarvoa. Tuntiraporttien perusteella lasketaan projektinhallintatyölajiin kulunut aika suhteessa projektiin käytettyyn kokonaistuntimäärään. Dokumenttien asiakaskatselmuksissa esille tuotujen virheiden määrä. Saadaan selville, kuinka suuria muutoksia asiakas haluaa ryhmän tuotoksiin ja kuinka hyvin ryhmä on onnistunut itsenäisesti asiakkaan vaatimusten täyttämisessä dokumenttien osalta. Seurataan muutospyyntöjen määrää asiakaskatselmointipöytäkirjojen perusteella. Vaatimusten muuttuminen Saadaan selville, kuinka hyvin ohjelmiston määritetyt vaatimukset vastaavat asiakkaan todellisia tarpeita. Mitataan muuttuneiden vaatimusten suhde kaikkiin vaatimuksiin niiden prioriteettiluokan mukaan. Ohjelmistossa olevien virheiden korjaamiseen kuluva aika. Saadaan selville, kuinka tehokkaasti virheet korjataan ja toisaalta myös se, kuinka yksiselitteisesti testaus on ne raportoinut. Mitataan aika, joka kuluu virheen avaamisesta sen sulkemiseen. Uudelleen avattujen virheraporttien määrä. Saadaan selville, kuinka paljon aikaa käytetään virheiden turhaan Mitataan, kuinka suuri osuus virheraporteista voidaan sulkea, kun ne on kerran merkitty 14

20 korjaamiseen ja tarkentamiseen. Lisäksi voidaan seurata testauksen luomien virheraporttien laatua. korjatuiksi. 2.4 RISKIENHALLINTAPROSESSI Projektin riskienhallinta noudattaa kolmivaiheista prosessia: Ensin luodaan riskiluettelo, joka sisältää kaikki projektia uhkaavat kuviteltavissa olevat riskit. Toisena vaiheena riskit asetetaan vakavuusjärjestykseen, ja viimeisenä vaiheena suunnitellaan tapoja hallita aiemmissa vaiheissa määritettyjä riskejä. Riskienhallinta on jatkuva prosessi, joten riskiluetteloa ja arvioita täydennetään projektin kuluessa uuden tiedon tullessa esille. Seuraavassa kutakin vaihetta käsitellään erikseen Riskiluettelon luominen Koko ryhmä osallistuu riskiluettelon luomiseen, koska tämä on paras tapa varmistua siitä, että mahdollisimman suuri osa riskeistä tulee otetuksi huomioon. Tässä vaiheessa riskien vakavuuteen ei oteta kantaa, joten kaikkein vähäpätöisimmätkin riskit on tarkoitus ottaa mukaan luetteloon. Lähteinä käytetään olemassa olevaa materiaalia aiheesta sekä ryhmän jäsenten henkilökohtaisia käsityksiä Riskien arvottaminen ja asettaminen vakavuusjärjestykseen Kun riskiluettelo on luotu, riskit asetetaan vakavuusjärjestykseen perinteisellä vakavuus = todennäköisyys * odotettu vaikutus -menetelmällä. Tämä ei kuitenkaan tapahdu pelkästään määräämällä kullekin riskille mielivaltaisia arvoja, vaan sekä todennäköisyyden että odotetun vaikutuksen määrittämiseen käytetään suhteellista asteikkoa. Todennäköisyyden tapauksessa jo pelkän tapahtumatodennäköisyyden määrittäminen riittää suhteellisen asteikon luomiseen, sillä tapahtuma, jonka todennäköisyys on 0,5 on kaksi kertaa niin todennäköinen kuin tapahtuma, jonka todennäköisyys on 0,25. Vaikka edellä esitetty argumentti nojautuukin osittain käsitykseen todennäköisyydestä tapahtumien 15

21 esiintymisen yleisyytenä pitkällä aikavälillä eikä siten välttämättä sovellu tähän tarkoitukseen, on todennäköisyyksien suora määrittäminen vähintään yhtä hyvä tapa arvioida tapahtuman todennäköisyyttä kuin muut vastaavat menetelmät, joissa esim. annetaan tapahtumille todennäköisyyden kaltaisia arvoja mielivaltaisella asteikolla. Vaikutuksen arviointi pohjautuu Simple MultiAttribute Rating Technique (SMART) - menetelmään, jossa ominaisuuksia (tässä tapauksessa riskien vaikutuksia) arvioidaan suhteessa vähiten merkitykselliseen ominaisuuteen. Tässä menetelmä toimii siten, että vähiten merkitykselliselle riskille annetaan vaikutusarvoksi 10, ja muille annetaan pisteitä suhteessa tähän. Näin ollen esimerkiksi tapahtuma, jonka vaikutus olisi kaksi kertaa suurempi kuin vähiten merkityksellisen tapahtuman, saa 20 pistettä. Näin saadut pisteet skaalataan välille Skaalaaminen tapahtuu ratkaisemalla tarvittavat skaalauskertoimet a ja b yhtälöparista <suurin haluttu arvo> = a + b * <suurin arvioijan esittämä arvo> ja <pienin haluttu arvo> = a + b * <pienin arvioijan esittämä arvo>. Ryhmän kukin jäsen tekee molemmat yllä olevat arviot, ja näin saaduista tuloksista lasketaan keskiarvo. Lopuksi arvioiden keskiarvot kerrotaan keskenään, jolloin saadaan riskien kokonaisvaikutuksen asteikko, jossa arvot ovat välillä Tavat varautua riskeihin Riskeihin varaudutaan projektissa neljällä eri tavalla: 1. Kehitetään tapoja, joilla riskit voidaan eliminoida. 2. Kehitetään tapoja, joilla riskien toteutuminen voidaan estää. 3. Kehitetään tapoja, joilla riskien vaikutus voidaan rajoittaa sen jälkeen, kun ne ovat toteutuneet. 4. Kehitetään kullekin riskille toipumissuunnitelma, joka määrää toiminnan riskin toteutuessa. Näistä kaksi ensimmäistä tapaa ovat proaktiivisia, eli niissä pyritään pääsemään riskeistä eroon toimimalla ennen niiden toteutumista, ja projektin riskienhallinnan painopiste on näissä. Parhaassa tapauksessa kahta viimeistä tapaa ei jouduta koskaan käyttämään, mutta realistisesti ajateltuna tällaiset tavat on luonnollisesti määritettävä. 16

22 2.4.4 Riskienhallinnan rajoituksista Riskienhallintaan on luonnollisesti kehitetty useita hienostuneempia menetelmiä kuin yllä kuvattu, mutta tässä projektissa sellaisten käyttäminen ei ole järkevää. Tähän on kaksi syytä: projektista ei (toivottavasti) aiheudu vaaraa ihmishengille (eli riskit ovat toteutuessaankin verrattain pieniä) ja menetelmien luotettavuudesta ei ole varmuutta. Olisi mahdollista esimerkiksi käyttää jonkinlaista Monte Carlo -simulointia riskien analysoimiseen, mutta nämä menetelmät perustuvat satunnaislukujen tuottamiseen sopivasta jakaumasta. Ja tämä jakauma on arvioijan itse määritettävissä, joten ei ole kovinkaan varmaa, että projektin riskit noudattavat todellisuudessa simuloinnissa käytettyä jakaumaa. Näin ollen tämän tyyppisten menetelmien käyttäminen ei itse asiassa lisää riskianalyysin luotettavuutta yhtään enempää kuin kahden mielivaltaisen luvun kertominen keskenään lisää niiden luotettavuutta ja informaatioarvoa. Tällä tavalla, kuten kaikilla muillakin tavoilla, riskianalyysi on vain niin hyvä kuin arvioijien arviot. Ainoa tapa parantaa riskianalyysia on parantaa arvioijien arvioita, mikä tapahtuu vain kokemuksen kautta. Käytettävällä menetelmällä ei ole mitään tekemistä tämän kanssa. Lisäksi on muistettava, että riskianalyysiin ei pidä luottaa sokeasti, sillä mikäli riskianalyysi olisi täysin luotettava ja ennustaisi tulevaisuutta täsmälleen, mitään riskejä ei olisi. Riskien analysoinnin ohjeen pohjana on käytetty useita lähteitä ja koottu niistä riittävä kompromissi. Päätimme olla käyttämättä kolmipisteanalyysiä, joka aiheuttaisi turhaa ylimääräistä työtä tuomatta suhteessa riittävää lisäarvoa tietoisuudellemme riskeistä. Totesimme myös että erilaisten riskilistojen epäformaali käyttäminen riskien listaamisen pohjana on riittävä. Valitsimme riskien vaikutusten arvottamiseen SMARTin voidaksemme saada koko ryhmän osallistumaan riskien arvottamiseen. Tiedostetut riskit ovat jo osin torjuttuja. 2.5 ASIAKASKOMMUNIKAATIO Jotta asiakkaalta saatu palaute ja asiakkaalle eskaloitavat asiat tulisivat säännönmukaisesti koko ryhmän tietoon, asiakaskommunikaation käytännöt on sovittu projektiryhmän sisällä. 17

23 2.5.1 Käytäntö Asiakkaan yhteyshenkilö on Suvi Toivanen ja hänen varahenkilönään Marko Korpi- Filppula. Asiakaskommunikaatiosta projektiryhmässä vastaa ryhmän projektipäällikkö Katariina Ylinen. Ryhmän asiakaskontaktien tulee mennä mielellään Katariinan kautta, mutta vähintäänkin jokaisesta asiakkaalle menevästä sähköpostista tulisi laittaa Katariinalle kopio kokonaisuuden hallitsemiseksi. Asiakkaan kanssa pidettävistä palavereista kirjoitetaan aina pöytäkirjat ja ne hyväksytetään asiakkaalla. Suunnittelupalavereista, joissa Katariina ei ole läsnä, toimitetaan heti kokouksen jälkeen Katariinalle yhteenveto. Asiakaskommunikaation yksinkertaistamiseksi ja vastuiden selkiyttämiseksi ryhmä ei ole yhteydessä TAI:n asiakkaisiin. 2.6 ASIAKASRAPORTOINTI Asiakastyytyväisyyden kannalta on erityisen tärkeää, että asiakas tietää missä projektissa mennään. Kurssin puolesta annetut aikarajat ovat kohtuullisen harvakseltaan ja projektin tilan tunteminen on asiakkaalle tärkeää. Projektilla on merkityksensä asiakkaan oman projektin etenemisen suhteen ja näin ollen edistymistä halutaan seurata ja tukea joka vaiheessa Sovittu käytäntö Projektipäällikkö toimittaa asiakkaalle viikkoraportin maanantaisin klo mennessä sähköpostilla. Raportin laatimisessa käytetään ryhmän raporttipohjaa. Raportissa vedetään yhteen tehdyt asiat, sekä seuraavaksi tehtävät asiat ja raportoidaan mahdolliset ongelmat. Asiakasraportit tehdään joka maanantai, riippumatta siitä onko kurssille ko. viikolla palautettava raportti. Raportit kerätään ryhmän Web-sivuille viikoittaisen etenemisen dokumentaatioksi. 18

24 2.7 TUNTIRAPORTOINTI Tuntiraportointi ja sen oikeellisuus on mittareidemme perusta. Tunnit on merkittävä Tiranaan, josta niiden yhteenvetoja voi tarkastella ViCA-visualisointityökalun avulla Sovittu käytäntö Kukin projektiryhmän jäsen raportoi tunnit Tiranaan viikon välein. Tuntien on oltava ajan tasalla viimeistään päivää ennen kurssin palautusaikarajaa, jotta projektipäällikkö pystyy tekemään tarpeelliset yhteenvedot. Asiakkaalla on tunnus ViCAan ja heidän projektinhallinnallinen kiinnostuksensa saa heidät tunnustaan myös käyttämään. Näin ollen on oleellista, että asiakaskin voi aina raportoinnin yhteydessä maanantaisin puoliltapäivin tarkastella ajantasaisia tietoja. Tunnit Tiranaan päivitetään samaan aikaan, kun lähetetään projektipäällikölle kuvaus toimistaan kuluneen viikon aikana. Projektipäällikkö tarkastaa tiedot ja laatii niiden pohjalta asiakkaalle viikkoraportin Tuntiraportoinnin työlajit Tuntiraportoinnin työlajit ja niiden sisällöt on määritetty Ohjelmatyö-kurssin kotisivuilla. 2.8 KOKOUSKÄYTÄNNÖT Kokouksilla on tapana, myös tässä projektissa, venyä pitkiksi ja osin niissä käsitellään asiaa, joka ei koske kaikkia paikallaolijoita. Jotta kokonaisuutena asiat saataisiin tehtyä, tietyistä käytännöistä kokouksien suhteen on sovittu. Erityisen tärkeänä kokouskäytännöissä on pöytäkirjan laatiminen, jonka avulla kokoukseen pääsemättömät sekä sisäisten palaverien suhteen asiakas, voi pysyä ajan tasalla projektin tilanteesta. Asiakaspalaverien pöytäkirjat ilmaisevat yhteisesti sovittuja asioita ja toimivat päätettyjen asioiden dokumentaationa. 19

25 2.8.1 Käytännöt Ennen kokousta projektipäällikkö/alueen vastuullinen kutsuu kokouksen kaksi päivää ennen kokousta ja valitsee sopivan kokouspaikan projektipäällikkö/vastuullinen kerää asioita agendaan, ryhmän jäsenet toimittavat tiedon käsiteltävistä asioista omalta kannaltaan projektipäällikölle/vastuulliselle sähköpostitse vähintään päivää ennen kokousta. päivää ennen kokousta projektipäällikkö/vastuullinen lähettää kokouksen agendan ja muun mahdollisen materiaalin agendasta tulee käydä ilmi kokouksen tarkoitus, kenen tulee osallistua ja päätökset, jotka on tehtävä. ilmoitetaan projektipäällikölle/vastuulliselle etukäteen tiedetyistä esteistä Kokouksen alkaessa saavutaan ajoissa nimetään kokoukselle sihteeri joka tekee pöytäkirjan; vuoro on kiertävä sovitaan käsiteltävistä asioista ja kokouksen aikataulusta tarkastetaan edellisen kokouksen pöytäkirja Kokouksen aikana käsitellään asia kerrallaan pysytään asiassa annetaan kaikille tilaisuus kommentoida jos kokous ei etene, huomautetaan asiasta puheenjohtajalle vedetään yhteen kaikki keskustelut 20

26 kirjataan päätökset ja tehtävät asiat pöytäkirjaan; tehtävien asioiden suhteen on määriteltävä vastuullinen ja määrä-aika Kokouksen jälkeen kokouksen sihteeri laatii pöytäkirjan ja toimittaa sen kokouksen osanottajille luettavaksi sähköpostilla kolmen arkipäivän kuluessa kokouksesta. Web-vastaava lisää pöytäkirjan Web-sivulle, josta asiakas voi sen halutessaan lukea 2.9 KATSELMOINNIT Projektissa tuotettava materiaali katselmoidaan. Tuotettava materiaali voidaan jakaa kahteen osaan, dokumentaatioon ja koodiin ja näille molemmille on oma katselmointiprosessinsa. Dokumentaation katselmoinnilla pyritään löytämään ja korjaamaan virheet ja epäjohdonmukaisuudet sekä lisäksi hakemaan sekä ryhmän että asiakkaan sitoutumista projektin tuotokseen. Koodin katselmoinnilla pyritään löytämään koodissa olevat virheet jo ennen testausta sekä saamaan aikaan ryhmän sisäistä oppimista ja kokemuksien vaihtoa Dokumenttien katselmointi Kaikki projektin palautettava materiaali katselmoidaan. Katselmointi jakaantuu kahteen vaiheeseen. Ennen sisäistä aikarajaa, joka kussakin vaiheessa on viikkoa ennen varsinaista palautusta, ryhmä suorittaa sisäiset katselmoinnit. Sisäisen deadlinen jälkeisellä viikolla ennen varsinaista palautusta suoritetaan asiakaskatselmointi. Asiakaskatselmoinnista kirjoitetaan katselmointipöytäkirja, joka julkaistaan Web-sivuilla. Projektipäällikkö nimittää asiakaskatselmoinnille pöytäkirjan kirjoittajan. Asiakaskatselmoinnin päävastaava on aina projektipäällikkö. Sisäisen katselmoinnin suorittaa kunkin dokumentin vastuullisen varahenkilö yhdessä projektiryhmän yhden muun jäsenen kanssa. Sisäisen katselmoinnin muistiinpanot jäävät projektiryhmän sisäiseksi materiaaliksi. Mikäli varahenkilö on estynyt katselmoimasta, hän sopii projektipäällikön kanssa itselleen sijaisen tilaisuuteen. 21

27 2.9.2 Koodin katselmointi Koodin katselmointiin osallistuvat järjestelmäarkkitehti sekä ohjelmoijat. Kunkin tekemä koodi katselmoidaan moduulitestauksen jälkeen. Katselmointi suoritetaan yhden ryhmäläisen toimesta, katselmoija nimetään katselmointiajankohdan (eli koodin valmistumisen ja moduulitestaamisen ajankohdan) selvittyä Vastuut Sisäisten katselmointien vastuut jakautuvat seuraavasti: Dokumentti Pääkirjoittaja Katselmoijat PS: projektisuunnitelma Katariina Niko, Maaret PS: aikataulu Katariina Niko, Maaret PS: laatukäsikirja Niko Minna, Maaret PS: vaatimusmäärittely Kimmo Eero, Antti T1: päivitetty projektisuunnitelma Katariina Niko, Maaret T1: päivitetty aikataulu Katariina Niko, Maaret T1: päivitetty vaatimusmäärittely Eero Katariina, Niko T1: Toiminnallinen määrittely Maaret Antti, Katariina T1: Tekninen määrittely Kimmo Maaret, Eero, Antti T1: Testaussuunnitelma Niko Katariina, Eero T1: Käyttöliittymän testaussuunnitelma Minna Maaret, Niko T1: Laatukäsikirja Niko Minna, Maaret T1: Edistymisraportti Katariina Niko, Maaret 22

28 T2: päivitetty projektisuunnitelma Katariina Niko T2: päivitetty aikataulu Katariina Niko T2: päivitetty vaatimusmäärittely Eero Antti T2: päivitetty toiminnallinen määrittely Kimmo Eero T2: päivitetty tekninen määrittely Kimmo Eero T2: päivitetty testaussuunnitelma Niko Minna T2: Testitapausluettelo Niko Minna T2: Päivitetty käyttöliittymän testaussuunnitelma Niko Minna T2: Testausraportti Niko Minna T2: Käyttöohje Minna Maaret T2: Edistymisraportti Katariina Niko T3: päivitetty projektisuunnitelma Katariina Niko T3: päivitetty aikataulu Katariina Niko T3: päivitetty vaatimusmäärittely Eero Antti T3: päivitetty toiminnallinen määrittely Kimmo Eero T3: päivitetty tekninen määrittely Kimmo Eero T3: päivitetty testaussuunnitelma Niko Minna T3: Testitapausluettelo Niko Minna T3: Päivitetty käyttöliittymän testaussuunnitelma Niko Minna 23

29 T3: Testausraportti Niko Minna T3: Päivitetty käyttöohje Minna Maaret T3: Edistymisraportti Katariina Niko T4: päivitetty projektisuunnitelma Katariina Niko T4: päivitetty aikataulu Katariina Niko T4: päivitetty vaatimusmäärittely Eero Antti T4: päivitetty toiminnallinen määrittely Kimmo Eero T4: päivitetty tekninen määrittely Kimmo Eero T4: päivitetty testaussuunnitelma Niko Minna T4: Päivitetty testitapausluettelo Niko Minna T4: Päivitetty käyttöliittymän testaussuunnitelma Niko Minna T4: Testausraportti Niko Minna T4: Käyttöohje Minna Maaret T4: Edistymisraportti Katariina Niko LU: päivitetty projektisuunnitelma Katariina Niko LU: päivitetty aikataulu Katariina Niko LU: päivitetty vaatimusmäärittely Eero Antti LU: päivitetty toiminnallinen määrittely Kimmo Eero LU: päivitetty tekninen määrittely Kimmo Eero 24

30 LU: päivitetty testaussuunnitelma Niko Minna LU: Päivitetty testitapausluettelo Niko Minna LU: Päivitetty käyttöliittymän testaussuunnitelma Niko Minna LU: Testausraportti Niko Minna LU: Käyttöohje Minna Maaret LU: Edistymisraportti Katariina Niko LU: Opponenttiryhmän testausraportti Niko Minna LU: Loppuraportti Katariina Niko 2.10 DOKUMENTTIEN JULKAISEMINEN Kaikkien projektin dokumenttien julkaiseminen tapahtuu niiden palautuksen yhteydessä. Ennen julkaisemista projektiryhmän tuottama materiaali säilytetään salasanallisella Websivulla. Projektin laatuvastaava tarkistaa (katselmointien jälkeen) jokaisen julkaistavan dokumentin ennen sen julkaisemista. Tämän tarkistuksen jälkeen dokumentit lähetetään Web-sivujen ylläpitäjälle julkaisemista varten. Palautusten kohdalla projektin Web-sivujen ylläpitäjä hoitaa palautuksen käytännön järjestelyt, koska hän on se henkilö, joka on dokumentit ryhmän Web-sivuille laittanut. Dokumenttien katselmoinnista on erillinen ohje FTP-PALVELIMEN KÄYTTÖ Jotta projektissa tuotettavat dokumentit ovat koko ajan kaikkien saatavissa ja niitä ei tarvitse lähettää edestakaisin asiakkaan ja projektiryhmän jäsenten välillä, projektille on 25

31 perustettu TAI:n tiloihin FTP-palvelin, jossa dokumentteja säilytetään. Palvelimeen on pääsy sekä projektiryhmän jäsenillä että asiakkaalla. Dokumentteja säilytetään palvelimella palautusten mukaisissa kansioissa. Jotta palvelimella on aina viimeisin versio kustakin dokumentista, kaikki projektiryhmän jäsenet tallentavat dokumenttinsa uusimmat versiot palvelimelle kunkin päivän päätteeksi. FTP-palvelinta käytetään projektissa varsinaisen versionhallintajärjestelmän rinnalla sellaisissa tilanteissa, kun dokumentti tai muu tiedosto on vain tarkoitus esim. siirtää paikasta toiseen tai ihmiseltä toiselle ilman, että tiedoston on oltava tässä tilanteessa versionhallinnan piirissä. 3. TUOTTEENHALLINTAAN LIITTYVÄT KÄYTÄNNÖT 3.1 ASIAKKAAN VAATIMUSTEN KÄSITTELEMINEN Vaiheittain: 1. Asiakas luo luettelon, joka sisältää kaikki mahdolliset vaatimukset, joita he järjestelmälle asettavat. 2. Asiakas asettaa eri ominaisuudet tärkeysjärjestykseen. Tässä on useita vaihtoehtoja: suora tärkeysjärjestys, suhteellinen pisteasteikko tai jonkinlainen kategoriajako. Jotta ominaisuuksien listaaminen ja tärkeysjärjestykseen asettaminen ei muodostu itsetarkoitukseksi, tässä projektissa paras vaihtoehto on kategoriajako neljään osaan: 1. Ominaisuudet, joiden toteuttamatta jättäminen merkitsee projektin epäonnistumista (välttämättömät ominaisuudet) 2. Ominaisuudet, joiden toteuttamatta jättäminen alentaa järjestelmän arvoa huomattavasti (tarvittavat ominaisuudet) 3. Ominaisuudet, joiden toteuttaminen toisi lisäarvoa mutta jotka eivät ole välttämättömiä (toivottavat ominaisuudet) 26

32 4. Ominaisuudet, joiden toteuttamisesta luovutaan heti (toteuttamatta jätettävät ominaisuudet) 3. Ohjelmatyöryhmä luo luettelon järjestelmän ominaisuuksista, jotka tähtäävät asiakkaan määrittämien vaatimuksien täyttämiseen. 4. Asiakkaan vaatimusluettelo ja ryhmän ominaisuusluettelo yhdistetään luomalla korrelaatiomatriisi, josta käy ilmi kunkin vaatimuksen ja ominaisuuden yhteys viisiportaista asteikkoa käyttäen: 1. Voimakas positiivinen korrelaatio (++) 2. Heikko positiivinen korrelaatio (+) 3. Ei korrelaatiota (0) 4. Heikko negatiivinen korrelaatio (-) 5. Voimakas negatiivinen korrelaatio (--) Esimerkki tällaisesta matriisista on alla kuvassa 1. Vaatimukset asetetaan tärkeysjärjestykseen (saman kategorian vaatimukset mielivaltaiseen järjestykseen). Kuva 1. Esimerkki korrelaatiomatriisista 5. Kun korrelaatiomatriisi on luotu, katsotaan, jääkö yksikään muun kuin kategorian 4 ominaisuus toteuttamatta (tai heikosti toteutetuksi) määritettyjen ominaisuuksien perusteella. Jos näin on, ominaisuuksia on määritettävä lisää. Mikäli kaikki määritetyt ominaisuudet mahdollistavat kaikkien vaatimusten täyttämisen ja ominaisuusluettelossa on ominaisuuksia, jotka eivät palvele minkään vaatimuksen täyttämistä, tällaiset ominaisuudet karsitaan pois. 27

33 3.2 MUUTOSTENHALLINTA Tämä muutostenhallintaprosessi koskee kaikkia sellaisia tilanteita, joissa halutaan tehdä muutoksia joko järjestelmään, sen vaatimusmäärittelyyn tai sen käyttötapauskuvaukseen. Muutosten käsittely jaetaan kahteen luokkaan ehdottajan perusteella: asiakkaalta tuleviin muutoksiin sekä ryhmän sisältä tuleviin muutoksiin. Tätä prosessia tullaan vielä tarkentamaan toteutus 2- vaiheen aikana asiakkaan kanssa Asiakkaan ehdottama muutos Jos asiakkaalla on muutosehdotus järjestelmän toiminnallisuuteen, aikatauluun tai vaatimuksiin liittyen, hän toimittaa muutospyynnön kirjallisena projektipäällikölle. Muutospyynnön tulee sisältää perustelut sille, miksi muutosta halutaan sekä prioriteetti eli mitä muita jo kirjattuja vaatimuksia tärkeämmäksi muutos koetaan. Projektipäällikkö selvittää viikon kuluessa muutosehdotuksen vastaanottamisesta seuraavat asiat: 1. Muutoksen toteuttamisen teknisen mahdollisuuden, eli pystytäänkö muutosta toteuttamaan 2. Muutoksen aikataulullisen vaikutuksen sekä vaikutukset muihin vaatimuksiin 3. Muutoksen vaikutuksen käyttöliittymään ja konsultoi käyttöliittymäsuunnittelijaa käytettävyysvaikutuksista Selvitystyön jälkeen projektipäällikkö tekee päätöksen muutoksen toteuttamisesta ryhmän palautteen perusteella ja raportoi tämän asiakkaalle Ryhmän sisällä ehdotetut muutokset Jos muutosehdotus tulee projektiryhmän sisältä, on muutoksen ehdottaja itse vastuussa edellä mainitun selonteon tekemisestä muutoksen vaikutuksista projektiin. Jos muutoksesta epäillään aiheutuvan muutoksia asiakkaalle luvattuihin ominaisuuksiin, käyttöliittymään, aikatauluun tai työmääriin, seuraavaa prosessia tulee noudattaa. Jos muutos taas aiheuttaa muutoksia ainoastaan ryhmän sisäisiin suunnitelmiin tai resursointiin, muutoksesta voidaan neuvotella projektipäällikön kanssa suullisesti. 28

34 Kun muutospyyntö on laadittu, se toimitetaan kirjallisena projektipäällikölle. Muutospyynnön tulee sisältää perustelut sille, miksi muutosta halutaan sekä sen mahdolliset vaikutukset järjestelmäarkkitehtuuriin ja aikatauluun. Projektipäällikkö selvittää viikon kuluessa muutosehdotuksen vastaanottamisesta seuraavat asiat: 1. Muutoksen vaikutukset muiden työhön 2. Muutoksen vaikutuksen asiakasvaatimuksiin. Selvitystyön jälkeen projektipäällikkö esittää muutosehdotuksen kirjallisena asiakkaalle, jonka kanssa neuvotellaan ja päätetään muutoksen toteuttamisesta Bugin ja muutoksen ero Muutokset ovat asioita, jotka tehdään toisin kuin on määrittelyissä kirjallisesti asiakkaan kanssa yhteisymmärryksessä sovittu. Mikäli asia halutaan tehdä toisin kuin on dokumentoitu, asia käsitellään muutoksena ja sen kerrannaisvaikutukset selvitetään ennen toteutusta. Mikäli kyseessä on ohjelmiston virhe eli ohjelmisto toimii vastoin kirjallisesti sovittuja määrittelyjään, virhe korjataan. Virheiden hallinnoinnissa apuna käytetään Tiranaa ja virheraportointiohjetta. 3.3 VERSIONHALLINTA Versionhallinta on projektissa ensiarvoisen tärkeää, jotta vältetään turhaa työtä ja kaikilla on koko ajan sama käsitys projektin edistymisestä. Tässä dokumentissa versionhallintaa käsitellään kahdessa osassa: asiakirjojen hallinta ja varsinaisen ohjelmiston osien versionhallinta Dokumenttien versiointi Dokumentit versioidaan seuraavan käytännön mukaan. Kunkin dokumentin versioinnista vastaa sen pääkirjoittaja. 29

35 Versio Dokumentin tila 0.X Ensimmäiset sisäiset versiot ennen sisäisen katselmoinnin korjauksia. 1.0/X.0 Sisäisen katselmoinnin korjaukset tehty; asiakaskatselmointiin menevä versio. 1.1/X.1 Asiakaskatselmoinnin korjaukset tehty; kurssin henkilökunnalle palautettava versio. Y.X (Y > 1, X > 1) Sisäisiä versioita; asiakaskatselmointiin ja palautuksiin menevät versiot taas Y+1.0 ja Y Tuotteen versionhallinta Tuotteen versionhallinnassa versioitaviin asioihin kuuluvat yksittäiset tiedostot (lähdekooditiedostot, käännetyt (binaari)tiedostot, dokumentit, TAI:n luomaan järjestelmän tietosisältöön kuluvat tiedostot ja muut tiedostot), kokonaiset buildit, sisäiset buildit sekä palautukset kurssin henkilökunnalle/asiakkaalle/opponenttiryhmälle. Versionhallinta perustuu keskitettyyn yhdellä palvelimella sijaitsevaan järjestelmään, johon on mahdollista muodostaa myös etäyhteys. Versionhallintapalvelimen ylläpidosta vastaa järjestelmäarkkitehti. Versionhallintaan käytettävä palvelin sijaitsee Tik-talon luokassa A218. Projektiryhmän kunkin jäsenen vastuulla on käsittelemiensä tiedostojen siirtäminen versionhallintapalvelimelle kunkin työpäivän päätteeksi. Kun tiedostoja otetaan käsiteltäväksi versionhallinnasta ja palautetaan käsittelyn jälkeen palvelimeen, kustakin tiedostosta/tapahtumasta kirjoitetaan järjestelmään kommentti, joka kattaa vähintään seuraavat asiat (palvelimen automaattisesti tuottamien päivämäärä- ja käyttäjätietojen lisäksi): tehtyjen muutosten lyhyt kuvaus (tarvittaessa viite laajempaan kuvaukseen), muutosten tekemisen syy sekä kuvaus tiedoston valmiusasteesta muille käyttäjille (esim. voiko jonkin moduulin lähdekoodia käyttää hyväkseen käännettäessä jotakin toista siihen liittyvää moduulia). 30

36 Versiomuutoksista ei tiedoteta ryhmän jäsenille erikseen; mikäli joku on kiinnostunut jonkin tietyn tiedoston tilasta, hän voi tarkastella tätä versionhallintajärjestelmän kautta (esim. onko tiedosto muokattavana ja jos on, kenellä). Poikkeuksen tähän muodostavat kurssille ja asiakkaalle palautettavat dokumentit, jotka ovat koko ajan saatavilla ryhmän Web-sivuilla. Dokumenttien näkyville asettamisesta vastaa ryhmän Web-sivujen ylläpitäjä Lähdekooditiedostojen mallipohja Kaikissa lähdekooditiedostoissa on tiedoston alussa tunnistetiedot, josta näkyvät seuraavat tiedot: tiedoston kirjoittaja, moduulin nimi, lyhyt kuvaus tiedoston sisällöstä, mahdolliset riippuvuudet muista moduuleista tms. sekä tiedoston versiohistoria. Tätä mallipohjaa käytetään oletusarvoisesti kutakin uutta lähdekooditiedostoa luotaessa. Javaa kirjoitettaessa kommentit muotoillaan siten, että niitä voi käyttää dokumentointiin JavaDoc-työkalun avulla Versionhallinnan työkalut Versionhallintaan käytetään Microsoft Visual Source Safea. Etäyhteyttä varten käytetään SourceOffSite-ohjelmaa. 4. TUOTANTOPROSESSIIN LIITTYVÄT KÄYTÄNNÖT 4.1 KOODAUSKÄYTÄNNÖT Yleistä Ryhmämme on määritellyt käytettävät ohjelmointikäytännöt olemassa olevien yleisten suositusten pohjalta ja muokannut niistä itselleen sopivan yhdistelmän. Lähteinä on käytetty sekä Sunin yleistä suositusta ( sekä professori Arto Wiklan kursseilleen laatimaa ohjeistoa ( 31

37 Molemmat ohjeistot koskevat Java- ohjelmointia mutta niitä voidaan pitkälti soveltaa myös muissa ohjelmointikielissä. Koska käytössämme on Sunin luokkakirjastot ja täten niiden lähdekoodi on nähtävillä yhdessä omamme kanssa, on järkevää käyttää samoja käytäntöjä niin sisennyksissä kuin nimeämiskäytännöissäkin. Nämä käytännöt ovat luonnollisesti samat kuin yllä mainitut Sunin suositukset. Moduulien, luokkien ja komponenttien nimet alkavat aina isolla kirjaimella, kuten luokkien nimet yleensäkin. Nimen ollessa moniosainen kaikki sanat alkavat isolla kirjaimella. Rajapintojen nimeämisessä noudatetaan samoja sääntöjä kuin luokissa yleensä, mutta nimen alkuun lisätään "I". Metodien ja muuttujien, kuten metodien parametrien nimet alkavat pienellä alkukirjaimella, mutta moniosaisissa nimissä ensimmäistä seuraavat sanat alkavat isolla alkukirjaimella. Metodien nimet on pyritty pitämään yhdenmukaisina. Aina, kun jokin arvo asetetaan, liitetään metodin nimen alkuun 'set'. Vastaavasti jonkin arvoa haettaessa liitetään metodin alkuun 'get'. Uutta luodessa käytetään alkuliitettä 'new' ja vanhaa poistettaessa 'remove', paitsi tietokantaliittymässä, joka noudattaa SQL-kielelle tyypillistä nimeämistä. Java-teknologian mukaisesti luokilla ei ole erillisiä otsikkotiedostoja, mutta moduulin julkisivuluokka (facade) nimetään moduulin mukaan Kommentointi Perinteinen JavaDoc-kommentointitapa on hyväksi todettu ja sen selkeys katsottiin toimivan myös LiKe-järjestelmän kommentoinnissa. Kommentit ovat siis muotoa: /** * Teksti */ Kommenttien teksti kirjoitetaan englanniksi, jotta järjestelmä olisi mahdollisimman helposti lokalisoitavissa. Tämä kuuluu myös asiakkaan vaatimuksiin Nimeämiskäytännöt: Muuttujat, metodit, vakiot ja luokat Nimeämiskäytäntöihin vaikutti siis paljolti Sunin luokkakirjastoissaan käyttämät menetelmät. Luokkien nimet kirjoitetaan isolla alkukirjaimella, metodien ja muuttujien nimet pienillä. Jos metodin tai luokan nimi koostuu useammasta kuin yhdestä sanasta, 32