Laatukäsikirja Kuopio

Transkriptio

1 Laatukäsikirja Kuopio

2 Kuopio, laatukäsikirja, Versiohistoria: Versio Pvm Laatija Muutokset Ossi Jokinen Valmis katselmoitavaksi Ossi Jokinen Sisäisen katselmoinnin korjaukset tehty Ossi Jokinen Asiakaskatselmoinnin korjaukset tehty Ossi Jokinen Lisätty projektin lopputuotteen tuotannon ohjeet ja käytännöt. Menetelmistä löytyy CVS version ja muutoksen hallinta sekä koodikatselmoinnit Ossi Jokinen Kappale tuntiraportointia muutettu. Kappale koodin katselmointikäytäntöä muutettu Ossi Jokinen Lisätty kappaleeseen 5.3 viitteet koodausohjeeseen Ossi Jokinen Lopullinen versio T1-vaiheen palautukseen Ossi Jokinen Kappaleen 5.3 päivitys Lasse Tolvanen Kappaleen päivitys Ossi Jokinen Katselmoinnin korjaukset T3 palautukseen. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 2

3 SISÄLLYSLUETTELO 1. JOHDANTO TERMIT LAATU LAADUN MITTARIT PROJEKTIN TOIMINTATAVAT PROJEKTIN HALLINNOLLISET TOIMINTATAVAT JA -OHJEET Projektin yhteydenpito Projektin työmäärän ja ajankäytön seuranta Asiakasraportointi ja -kommunikaatio Kokous- ja palaverikäytännöt Katselmointikäytäntö Dokumenttien julkaisukäytännöt PROJEKTIN TUOTTEEN HALLINTA Asiakkaan vaatimusten hallinta Versionhallinta Muutoksen hallinta PROJEKTIN LOPPUTUOTTEEN TUOTANNON OHJEET JA KÄYTÄNNÖT Käytettävät kehitystyökalut Käytettävä suunnitteluperiaate, kolmikerrosmalli, N-tier application architecture Koodausohjeet, Coding Guidelines Versionhallinnan ja konfiguraation hallinnan ohje Koodin katselmointi/tarkastus käytäntö PROJEKTIN RISKIENHALLINTAPROSESSI RISKIEN TUNNISTAMINEN RISKIEN MONITOROINTI RISKIEN VASTATOIMET RISKIEN UUDELLEENARVIOINTI LÄHTEET LIITTEET Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 3

4 TAULUKOT Taulukko 1 Dokumentissa esiintyvät termit...6 Taulukko 2 Laadun mittarit...8 Taulukko 3 Tuntiraportoinnin työlajit...12 KUVAT Kuva 1 A typical N-Tier Model...20 Kuva 2 Projektin riskienhallintaprosessi...28 Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 4

5 1. JOHDANTO 2. TERMIT 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ä. 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. Tässä dokumentissa määritetään mitä laatu tarkoittaa tässä projektissa sekä lopputuotteen että prosessin osalta. Lisäksi esitetään laadun kriteerit ja niiden mittarit sekä lukuisia toimintaohjeita ja -tapoja, joilla pyritään varmistamaan projektin laatu. Laatuprosessi ei vaikuta pelkästään syntyvään lopputuotteeseen vaan myös aikatauluun, jonka puitteissa tuote on mahdollista toteuttaa. Kuopio-projektiryhmä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. Tätä laatukäsikirjaa tehdessä on pyritty ottamaan huomioon projektin luonne ja varottu synnyttämästä ylimääräistä työtä, joka ei ole panostuksen arvoista. Projektin koko, aikataulu ja resurssit ovat tiedossa tätä dokumenttia laadittaessa. Niiden pohjalta syntyy arvio oikeasta panostusten suhteesta laadun tuottamiseen. Pelkkiä dokumenttejahan projektissa ei voida lähteä tekemään vaan toiminnan on tähdättävä lopputuotteen mahdollisimman tehokkaaseen ja laadukkaaseen tuottamiseen. Tehokkaaseen toimintaan on siis pyrittävä, jotta kaikki se mitä tässä projektissa on tarkoitus toteuttaa pystytään toteuttamaan. Projektiryhmän jäsenet tiedostavat, että asioiden uudelleen keksiminen on ylimääräistä työtä. Niinpä laadun luomisen perusprosesseihin kuuluu benchmarking. Laatujärjestelmän toteuttamisvastuu on ensisijaisesti kaikilla Kuopio-projektin osapuolilla ja kokonaisuus on jaettu siten, että Ossi Jokinen vastaa projektin prosessin laadusta ja Rami Laiho projektin lopputuotteen laadusta teknisessä mielessä. Laatukäsikirjaan on myös dokumentoitu projektin riskienhallintaprosessi, joka on oma osansa projektin laadun varmistamista. Seuraavassa taulukossa on esitetty dokumentissa esiintyvä terminologia. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 5

6 Taulukko 1 Dokumentissa esiintyvät termit Asiakaskatselmoin ti Benchmarking Prosessi, jossa asiakas tarkastelee palautuksia ja esittää mahdolliset parannusehdotukset ryhmälle. Benchmarking on käytäntö, jossa organisaatio tai yksilö pyrkii parantamaan omaa toimintaansa oppimalla muiden organisaatioiden tai yksilöiden toiminnasta. Benchmarking voi kohdistua mihin tahansa toimintaan, mutta yleensä sitä käytetään jonkin prosessin parantamiseen. Vertailun kohteena oleva organisaatio ei välttämättä toimi samalla alalla kuin vertaajan oma organisaatio. Benchmarking ei ole suoraa toisten hyvien ideoiden kopioimista. Se on kuitenkin toisten keksimien ideoiden hyödyntämistä ja sen tosiasian tunnustamista, että koulutyönä tehtävässä projektissa tuskin keksimme prosessien puolelta mitään uutta ja ihmeellistä, joten olemassa oleviin asioihin vertaaminen on vähintäänkin järkevää. Client/server, serveri CVS Kehitysympäristö Mentor Milestone Projekti Prosessi Asiakas-palvelin. Sovellus tai järjestelmä, jossa asiakas käyttää paikalliselta koneelta asiakasohjelmaa ottaakseen yhteyden palvelinkoneeseen. Versionhallintaan käytettävä ilmainen ohjelmisto. Palvelinkoneympäristö, jossa varsinainen koodaus tapahtuu. Kurssin puolesta projektille määrätty henkilö, joka valvoo projektin kulkua ja neuvoo matkalla tulevissa ongelmissa. Virstanpylväs, etappi. Projektin etenemisen virstanpylväs, jossa arvioidaan tarkemmin projektin tilaa ja jossa projektilla on selkeä tavoitetila. Ainutlaatuinen toisiinsa kytkeytyvien toimintojen ja tapahtumien joukko, joilla on selkeä tavoite ja tarkoitus sekä määrätty käytettävissä oleva aika ja budjetti. Toimintojen sarja, jolla päästään jostain lähtötilasta johonkin tavoitetilaan. Sisäinen aikaraja Projektiryhmän sisäinen aikaraja esim. dokumenttien kirjoittamiselle, joka on noin viikkoa aikaisempi kuin kurssin asettama aikaraja. Palautukset lähetetään asiakkaalle heti tämän aikarajan jälkeen. Sisäinen katselmointi Projektiryhmän sisäinen katselmointi, joka tapahtuu ennen sisäistä aikarajaa (eli dokumenttien lähettämistä asiakkaalle). Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 6

7 Tirana Kurssilla ja tässä projektissa käytettävä tuntiraportointijärjestelmä. USDP Unified Software Development Process, iteratiivinen ja inkrementaalinen ohjelmistokehityksen menetelmä, joka pohjautuu käyttötapauksiin. ViCa Word2000 Kuopio Projektiryhmä Lopputuote Asiakas Ohjaaja Mentor Innofactor Oy Visualization Client Application. Kurssin ja tämän projektin työkalu projektin etenemisen visualisoinnissa. Microsoftin Office tuoteperheen tekstinkäsittelyohjelman uusin versio. Toteutettavan ohjelmistoprojektin nimi. Tarkoittaa projektin toteuttavaa ryhmää opiskelijoita. Tarkoittaa projektin lopputulosta, tuotetta, jonka projektiryhmä tekee projektin aikana. Se henkilö tai taho, jolle projektiryhmä projektin loppuessa luovuttaa projektin lopputuotteen. Asiakkaalla voidaan viitata joko henkilöön (Tik kurssin rooli "asiakas") tai yleisesti asiakkaana toimivan yrityksen edustajaan. Asiakkaan puolesta järjestetty henkilö, joka ohjaa projektia asiakkaan haluamaan suuntaan ja tuo asiakkaan toiveita ja tietotaitoa mukaan projektiin. Tässä projektissa sama henkilö kuin asiakas. Kurssin puolesta projektille määrätty henkilö, joka valvoo projektin kulkua ja neuvoo matkalla tulevissa ongelmissa. Asiakkaan työllistävä yritys, jolle projekti tehdään. 3. LAATU Johdannossa todettiin asiakastyytyväisyyden olevan tärkein laadun mittari. Asiakastyytyväisyys = Laatu japanilaisen laatugurun, Ishikawan määritelmän mukaan. Tätä määritelmään on kuitenkin syytä hieman tarkentaa. Wesselius on todennut laadun koostuvan kolmesta komponentista, Laatu = objektiivisesti- + subjektiivisesti- + arvioimattomissa oleva komponentti [1]. Objektiivinen laadun komponentti: täyttääkö tuote kaikki vaatimusmäärittelyssä kuvatut vaatimukset? Vaatimuksia ovat esimerkiksi toiminnalliset vaatimukset, aikatauluvaatimukset, budjettivaatimukset, jne. Tämän komponentin täyttymistä voidaan helpoiten mitata vertaamalla lopputuotetta ja projektin kulkua projektin alussa määritettyihin vaatimuksiin. Subjektiivinen laadun komponentti: kuinka hyvin tuote kykenee täyttämään asiakkaan odotukset? Vaatimusmäärittely ei ole koskaan täydellinen. Tässä laadun komponentissa arvioidaan miltä tuote "tuntuu" asiakkaan mielestä. Tämän komponentin täyttymisessä Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 7

8 nähdään kuinka hyvin odotukset oli saatu kirjattua määrittelyiksi. Asiakkaan "tunne" tuotteesta ja projektista on hyvin subjektiivista. Tähän tuntoon vaikuttaa nähtävissä olevien seikkojen lisäksi aina psykologiset aspektit, sillä asiakas on vain ihminen. Esimerkiksi hyvä asiakaspalvelu ja henkilökemia asiakkaan kanssa aiheuttaa reaktion, jossa asiakas on altis vähättelemään syntyneitä puutteita ja korostamaan hyviä puolia. Tämä pätee vastaavasti myös toisin päin. Komponenttia voidaan mitata projektin lopuksi tiedustelemalla asiakkaan tuntoja. Arvioimaton laadun komponentti: kuinka hyvin tuotetta kyetään muuttamaan asiakkaan tulevien, tuntemattomien tarpeiden mukaisiksi? Asiakas ei edes tiedä kaikkia tarpeitaan, ja uusia tarpeita syntyy varmasti tulevaisuudessa. Tämän laadun komponentin täyttymistä ei tiedetä heti projektin päätyttyä. Tulevaisuus näyttää miten laadukas projekti oli tässä mielessä. Projektin tavoitteena on olla laadukas kaikkiin sidosryhmiinsä nähden. Tämän vuoksi asiakastyytyväisyyden lisäksi on huomioitava myös projektiryhmän tavoitteiden täyttyminen. Projektin tavoitteet on esitelty projektin projektisuunnitelmassa. Projektin tavoitteet on yhdistetty asiakkaan ja projektiryhmän tavoitteista. Näiden tavoitteiden täyttyminen edellä kuvattujen kaikkien laadun komponenttien kannalta tuottaa tämän projektin lopullisen laadun. 4. LAADUN MITTARIT Seuraavassa taulukossa on esitetty projektin laadun mittareita: Taulukko 2 Laadun mittarit Mittari Syy Toteutus Projektinhallintaan ja muihin hallinnollisiin toimenpiteisiin käytettyjen tuntien määrän suhde tuotantoon käytettyihin tunteihin. Hallinnolliset toimet kuuluvat osana projektiin ja niitä tulee olla tietty määrä projektista. Jos hallinnollisia toimia on vähän, niin projektinhallinta on tulkittava liian kevyeksi ja jos toimia on paljon, niin projektinhallinta on liian raskasta ja tehokkuus kärsii. Etsitään sopivia lähtökohtia vertailuarvoiksi yhdessä asiakkaan kanssa. Seurataan tunteja kurssin tarjoamalla Tiranajärjestelmällä. Kerätään havaintoja ensimmäisestä toteutusvaiheesta ja muodostetaan hypoteesi suhteesta oman kokemustiedon ja kirjallisuustiedon perusteella toista toteutusvaihetta varten. Kurssille palautettavien dokumenttien sisäisissä katselmoinneissa ilmi tulleiden virheiden ja puutteiden lukumäärä. Katselmointien tulisi prosessin toimiessa olla lähinnä muodollisia tilanteita, joissa varmistuksena tarkastetaan viimeisen kerran palautettavat dokumentit. Jos virheitä tai erimielisyyksiä syntyy, tämä Katselmustilanteessa lasketaan kuinka monta ongelmaa ja korjausta vaativaa tilannetta havaittiin. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 8

9 Mittari Syy Toteutus voi johtua esim. tulevista aikatauluongelmista, motivaatio-ongelmista, sisäisistä erimielisyyksistä, jne. Projektiin budjetoitujen työtuntien toteutuminen. Mikäli työtunteja kuluu liikaa, ei projektiryhmän jäsenet ole tyytyväisiä. Budjetointi on tehty kurssin vaatimusten pohjalta, ja projektiryhmän jäsenet eivät niitä halua ylittää. Tämä kertoo myös siitä miten hyvin vaatimusten priorisointi ja mahdollinen karsinta on onnistunut. Seurataan eri vaiheille kertyneiden tuntien määrää verrattuna vaiheelle budjetoituihin työtunteihin. Arvioidaan järjestelmän tilaa ja työtarvetta ja tehdään tarvittaessa karsintaa vaatimusten prioriteettien mukaan. Tuntien seuranta tapahtuu Tiranan kautta. Projektin edistymisastetta ja tarvittavia työtunteja arvioidaan projektiryhmän toimesta. Kurssin vaiheiden arvosanat ja koko kurssin arvosana. Projektiryhmän jäsenille on tärkeää kurssin vaatimusten täyttäminen ja hyvä arvosana kurssista. Arvosteluperusteet ovat kurssin henkilökunnan näkemys projektin laadukkuudesta. Verrataan saatuja arvosteluja tavoitearvoihin, jotka määrittyvät tavoiteltavan kokonaisarvosanan 5 perusteella. Aikatauluun perustuva edistymisen mittaaminen vs. arvioitu valmiusaste vs. suunniteltu valmiusaste projektin eri vaiheissa. Projektilla on kurssin asettamien vaatimusten mukaan useita milestone-kohtia aikataulussa. Jokaista vaihetta varten laaditaan ohjeen mukainen suunnitelma ko. vaiheen tavoitteista ja arvio valmiusasteesta. Jokaisen vaiheen lopussa tarkastellaan, saavutettiinko asetetut tavoitteet ja onko projektin valmiusaste todella suunnitelman mukainen. Lisäksi verrataan tehtyä työmäärää valmiusasteeseen. Kirjataan tehdyt tunnit Tirana - järjestelmään. Laaditaan tavoite joka vaiheelle. Tarkastellaan yhteistyössä asiakkaan kanssa, että saavutettiinko vaiheen tavoite. Arvioidaan koko projektin valmiusastetta joka vaiheen lopussa mahdollisimman puhtaalta pohjalta, ts. pyritään arvioivia henkilöitä vaihtamalla saamaan mahdollisimman realistinen arvio. Mitataan 'earned value' ja 'budgeted value' mittareilla projektin edistymistä suhteessa tehtyyn työhön ViCa - Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 9

10 Mittari Syy Toteutus järjestelmän avulla. Projektin tavoitteen tai lopputuotteen muutosvaatimusten lukumäärä. Projektin onnistumiselle on tärkeää, että projektin määrittely on onnistunut hyvin ja kaikki sidosryhmät ovat yksimielisiä projektin tavoitteesta. Jos muutoksia tulee paljon, on projektin määrittelyvaihe epäonnistunut. Etsitään referenssejä, kuinka paljon vaatimukset ja tavoitteet yleensä muuttuvat. Pyritään löytämään yhteistyössä asiakkaan kanssa jokin järkevä mittausarvo. Kirjataan ylös kaikki muutosvaatimukset ja verrataan mittausarvoon. Poikkeamat laatukäsikirjan mukaisista toimintatavoista. Ohjelmistosta löydettyjen virheiden määrä. Ohjelmistossa olevien virheiden korjaamiseen kuluva aika. Uudelleen avattujen virheraporttien määrä. Laatukäsikirja määrittelee lukuisia toimintatapoja, joiden tarkoitus on varmistaa, että projekti toteutetaan oikeaoppisesti. Jos poikkeuksia tulee paljon, voi määritelty toimintapa olla väärä tai huono ja sitä on korjattava. Kaikki löydetyt virheet raportoidaan. Mikäli virheitä on paljon suhteessa ohjelmiston kokoon on syytä huolestua. Tavoitteena on tehdä mahdollisimman vähän virheitä ja löytää tehdyt virheet mahdollisimman aikaisin, sillä se johtaa kustannustehokkuuteen ja mahdollisimman laadukkaaseen ohjelmistoon, sillä virheiden korjaaminen "rapauttaa" ohjelmiston koodia. Saadaan selville, kuinka tehokkaasti virheet korjataan ja toisaalta myös se, kuinka yksiselitteisesti testaus on ne raportoinut. Saadaan selville, kuinka paljon aikaa käytetään virheiden turhaan korjaamiseen ja Kokousmuistioissa pidetään kirjaa tapahtuneista poikkeamista ja esiin tulleista ongelmista. Prosessin laadusta vastaava tarkkailee lukumäärän kehitystä. Jos poikkeamisia tulee paljon, asiasta neuvotellaan ja tehdään tarvittavat muutokset. Etsitään sopivia lähtökohtia vertailuarvoiksi yhdessä asiakkaan kanssa. Verrataan löydettyjen virheiden määrää huomioiden ohjelmiston koko vertailuarvoihin. Mikäli luku näyttää liian korkealta mietitään mistä moinen huolimattomuus johtuu ja miten siitä päästään eroon. Mitataan aika, joka kuluu virheen avaamisesta sen sulkemiseen. Mitataan, kuinka suuri osuus virheraporteista voidaan sulkea, kun ne on kerran merkitty Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 10

11 Mittari Syy Toteutus tarkentamiseen. Lisäksi voidaan korjatuiksi. seurata testauksen luomien virheraporttien laatua. Koodin kommentointi Testauksen kattavuus suhteessa tuotteen kokoon koodiriveinä. Saadaan selville, kuinka havainnollista ohjelmiston lähdekoodi on ulkopuolisille. Tämä määrää käytännössä ohjelmiston jatkokehittämisen helppouden. Saadaan selville, kuinka suuren osan ohjelmiston eri toiminnoista testaus kattaa. Kommenttirivien osuus kaikista lähdekoodiriveistä. Käytetään testauksen yhteydessä automaattista kattavuuden mittaamiseen tarkoitettua työkalua. 5. PROJEKTIN TOIMINTATAVAT Tässä kappaleessa esitellään projektin toimintatapoja projektin eri osa-alueille. Projektinhallinnalliset käytännöt sekä tuotteen hallintaan liittyvät käytännöt on laadittu kirjallisuuden, Innofactorin laatujärjestelmän ja edellisten vuosien menestyksekkäitten ohjelmatyöprojektien dokumentaation pohjalta Kuopio-projektiin soveltaen. Projektin lopputuotteen tuotannon ohjeet laaditaan ensikokemusten ja kirjallisuuden perusteella ensimmäisen toteutusvaiheen aikana. 5.1 Projektin hallinnolliset toimintatavat ja -ohjeet Tässä kappaleessa esitetään projektin hallintaan liittyvät käytännöt Projektin yhteydenpito Ilman eri sopimusta jokaisen työviikon maanantaina järjestetään Innopolissa Innofactor Oy:n tiloissa klo projektin viikkopalaveri, johon osallistuu koko projektiryhmä ja pyydettäessä/halutessaan asiakkaan edustaja. Jos osallistuja on estynyt tai myöhästyy, siitä tulee ilmoittaa siten, että se kenelle ilmoitetaan estymisestä tai myöhästymisestä osallistuu viikkopalaveriin. Viikkopalaveria voidaan tarpeen vaatiessa siirtää tai niitä voidaan järjestää useampia. Viikkopalaverissa käsitellään seuraavan viikon tehtäviä ja keskustellaan projektin tilanteesta. Projektilla on sähköpostilista jonka kautta kommunikoidaan sähköpostitse kaikki projektia ja projektiryhmän jäseniä koskevat asiat. Projektipäällikkö lähettää projektin mentorille säännöllisesti raportin projektin edistymisestä. Käytännössä tämä edistymisraportti on projektin viikkokokouksesta tehty pöytäkirja. Myös asiakkaalle lähetetään projektin viikkokokouksen pöytäkirja mikäli hän ei ole ollut paikalla projektin viikkokokouksessa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 11

12 5.1.2 Projektin työmäärän ja ajankäytön seuranta Tuntiraportointi ja sen oikeellisuus on mittareidemme perusta. Tunnit on merkittävä Tiranaan, josta niiden yhteenvetoja voi tarkastella ViCA-visualisointityökalun avulla. Siksi jokainen projektiryhmän jäsen on velvollinen seuraamaan omaa ajankäyttöään projektissa Tiranassa olevien tehtävien tarkkuudella. Tunteja syötetään Tiranaan seuraavien periaatteiden mukaan. Tunnit syötetään Tiranaan päivittäin. (Mikäli tämä ei jostain syystä onnistu täytyy tunnit syöttää viimeistään seuraavana päivänä). Koko ryhmää koskevat, yleensä varsin pitkään kestävät tehtävät kuten luennot ja asiakastapaamiset merkitään siten, että Tiranasta selvitetään alunperin tehtävälle arvioitu tuntimäärä sekä yhteensä tehtävään käytetty aika. Näiden lukujen erotusta voidaan pitää karkeasti ottaen tehtävän edelleen vaatimana aikana. Jos esimerkiksi luentoihin on arvioitu kuluvan 105 tuntia ja Tiranan mukaan luennoilla on käyty 80 tunnin edestä, jäljellä olevaksi aika-arvioksi asetetaan 25 tuntia. Tätä arviota voidaan luonnollisesti tarkentaa tehtävän lähestyessä loppuaan. Lyhyempien tehtävien, joihin liittyy kuitenkin enemmän kuin yksi ryhmäläinen, edelleen vaatima aika merkitään yksinkertaisesti arvioimalla. Arviot vaihtelevat luonnollisesti varsin paljon henkilöstä riippuen, mutta edellisen tehtävää suorittaneen henkilön antama arvio on useimmissa tapauksissa riittävän pätevä mittari ellei uudella arvioijalla ole asiasta parempaa tietämystä. Pelkästään yhden henkilön vastuulla olevien tehtävien jäljellä olevan keston arvioiminen on luonnollisesti tapauksena triviaali koska tehtävän suorittaja pystyy tällaisessa tilanteessa parhaiten arvioimaan tehtävän suoritukseen vielä kuluvaa aikaa. Nämä periaatteet varmistavat, että projektipäälliköllä on käytettävissä juuri päivitetty informaatio projektin tilasta. Jos Tiranaan tarvitaan uusia tehtäviä, niin tästä tulee tehdä ilmoitus Ossille. Projektin viikkopalaverissa käydään läpi jokaisen henkilön vastuulla olevien tehtävien valmiusaste ja Ossi seuraa tehtävien valmistumista. Tuntiraportoinnin työlajit ja niiden sisällöt on määritetty Ohjelmatyö-kurssin kotisivuilla seuraavalla tavalla: "Luokittelun avulla voidaan työtunnit jakaa lajeihin ja seurata ajankäyttöä yksittäisiä tehtäviä korkeammalla tasolla. Jotta seuranta olisi luotettavaa, on ryhmän sisällä ja eri ryhmien kesken noudatettava samaa luokittelua ja tulkittava sitä samalla tavalla. Seuraavaan taulukkoon on koottu mahdollisimman kattava lista tehtävistä, mitä kukin kurssilla käytettävä työlaji sisältää. Taulukko 3 Tuntiraportoinnin työlajit Koodi Työlaji Selite A ATK-ylläpito Kaikenlainen laitteiden ja ohjelmistojen asennus ja viritys omaa projektia varten. WWW-sivuston ylläpito. Varmuuskopiointi. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 12

13 Koodi Työlaji Selite D Dokumentointi Ohjelmistoa koskevien raporttien kirjoittaminen, tarkastaminen, katselmointi, revisiointi, muunnokset ja palautukset. Käyttöohjeet ja muu koulutusmateriaali, myös on-line muotoinen. K Kokoukset Kurssin aikatauluun kuuluvat katselmukset ja demot. Ryhmän omat ja asiakaskokoukset, jos ne eivät selkeästi kuulu muuhun luokkaan (esim. ryhmätyönä tehtävä suunnittelu). Kokouksille kannattaa siis etukäteen sopia tarkoitus. L Luennot Ohjelmatyökurssin kaikille yhteiset luennot. O Ohjelmointi Ohjelmien kirjoittaminen, kääntäminen, linkkaaminen jne., sekä ohjelmoijan osalta suoritettava moduulitestaus. Ohjelmankehitysympäristöstä riippuen voi sisältää myös esimerkiksi valmiiden komponenttien uudelleenkäyttöä sekä käyttöliittymäkomponenttien sijoittelua, konfigurointia, koodin generointia jne. Tähän työlajiin kuuluvat myös ohjelmoinnin tukitehtävät, kuten työtä helpottavien skriptien kirjoittaminen sekä ohjelmiston konfiguraationhallinta. P Projektin hallinta Lähinnä projektipäällikön tehtävät: projektin suunnittelu, prosessin määrittely, projektin ohjaus, tuntiraportointi. Hallinnollisten dokumenttien kirjoittaminen ja revisointi: projektisuunnitelma, edistymisraportti, loppuraportti, omien projektikokousten pöytäkirjat. S Suunnittelu Määrittelydokumenttien (vaatimusmäärittely, toiminnallinen määrittely, tekninen määrittely) sisältöön liittyvät asiat. CASEtyökaluilla tehtävät kaaviot, käyttöliittymän määrittelyt ja rajapintakuvaukset. Arkkitehtuurimäärittelyt, moduulirajapinnat, moduulien kuvaukset. T Testaus Testauksen suunnittelu ja tekeminen (integraatio- ja järjestelmätestaus). Virheiden raportointi. U Opiskelu Projektiin liittyvien uusien asioiden (esim. työkalut, algoritmit, työn aihepiiri yleensä) opiskelu yksilöllisesti tai ryhmätyönä. Asiakkaan järjestämä, projektiin liittyvä koulutus. On selvää, että eri lajien kesken voi tulla rajanveto-ongelmia. Esimerkiksi suunnittelupalaverissa voidaan tehdä sekä suunnittelua, dokumentointia, että kokoustelua. Oleellista on, että kaikki tärkeä tulee raportoitua, samoja tunteja ei raportoida useaan kertaan, ja raportointi on johdonmukaista." Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 13

14 5.1.3 Asiakasraportointi ja -kommunikaatio 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ää. Asiakasraportoinnissa ja -kommunikoinnissa otetaan huomioon seuraavat asiat: Jokaisen projektin päävaiheen alussa asiakkaalle toimitetaan kirjallisena kuvaus ko. vaiheen tavoitteesta. Kuvauksesta tulee ilmetä mielekkäällä tarkkuudella mitä tässä projektin vaiheessa aiotaan tehdä. Kuvaus kirjataan projektisuunnitelman edellisen vaiheen palautettavaan versioon (tämä on syytä tehdä myös kurssin vaatimusten takia). Pääasiallisina kommunikointikanavina asiakkaan suuntaan toimivat Ossi ja Mikko, mutta kommunikointia ei ole suljettu. Ryhmän asiakaskontaktien tulee mennä mielellään Ossin kautta, mutta vähintäänkin jokaisesta asiakkaalle menevästä sähköpostista tulisi laittaa Ossille kopio kokonaisuuden hallitsemiseksi. Mikäli asiakkaan kanssa on kommunikoitu jollain muulla tavalla ja sovittu jotain merkittävää, täytyy tästä tiedottaa Ossia sähköpostitse. Asiakkaalle tulee välittömästi ilmoittaa projektia uhkaavista ongelmista. Erillistä viikkoraporttia asiakkaalle ei tarvita, sillä viikon tapahtumat käsitellään viikkopalaverissa. Mikäli asiakas ei osallistu viikkopalaveriin, lähetetään asiakkaalle kokouksen pöytäkirja, joka toimii viikkoraporttina (vastaavasti kuin mentorille), sähköpostitse Kokous- ja palaverikä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. Jokaisesta asiakaspalaverista sekä merkittävistä ryhmäpalavereista tehdään kokouspöytäkirja käyttäen pöytäkirjapohjaa. Kaikista ryhmäpalavereista ei tarvitse tehdä kokouspöytäkirjaa, mikäli palaverit käsittelevät ainoastaan rutiiniasioita. Tällaisia kokouksia ovat esimerkiksi projektiryhmän viikkopalaverit, joiden agendassa ei ole muuta kuin rutiiniasioita. Päätös kokouspöytäkirjan tarpeesta syntyy lopullisesti kyseisessä kokouksessa. Lähtökohtana kaikille kokouksille on kuitenkin aina seuraava toimintamalli: Käytännöt ennen kokousta: Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 14

15 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 kokoukseen osallistuville. 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ä. Käytännöt kokouksen alkaessa: Saavutaan ajoissa. Nimetään kokoukselle sihteeri joka tekee pöytäkirjan. Sovitaan käsiteltävistä asioista ja kokouksen aikataulusta. Tarkastetaan edellisen kokouksen pöytäkirja. Käytännöt kokouksessa: Käsitellään asia kerrallaan. Pysytään asiassa. Annetaan kaikille tilaisuus kommentoida. Jos kokous ei etene, huomautetaan asiasta puheenjohtajalle. Vedetään yhteen kaikki keskustelut. 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. Käytännöt kokouksen jälkeen: Kokouksen sihteeri laatii pöytäkirjan ja toimittaa sen kokouksen osanottajille luettavaksi sähköpostilla kolmen arkipäivän kuluessa kokouksesta Katselmointikäytäntö Kaikki projektissa tuotettava materiaali katselmoidaan. Tuotettava materiaali voidaan jakaa kahteen osaan, dokumentaatioon ja koodiin. Näille molemmille on oma katselmointiprosessinsa. Dokumentaation katselmoinnilla pyritään löytämään ja korjaamaan virheet ja epäjohdonmukaisuudet ja hakemaan sekä ryhmän että asiakkaan Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 15

16 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 noin 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. Projektipäällikkö nimittää asiakaskatselmoinnille pöytäkirjan kirjoittajan. Asiakaskatselmoinnin päävastaava on aina projektipäällikkö. Sisäisen katselmoinnin suorittaa kunkin dokumentin vastuullinen ja 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. Katselmointi toteutetaan siten, että katselmoitavan dokumentin editointi on välittömästi mahdollista (kannettava tietokone, tietokoneluokassa, jne.). Katselmoinnissa on läsnä vähintään kaksi henkilöä, katselmoitavan dokumentin vastuuhenkilö ja katselmoija. Katselmoitavan dokumentin vastuuhenkilö esittelee dokumentin ja katselmoija tarkastaa sen sekä esittää tarvittavia kysymyksiä. Jos löytyy virheitä tai puutteita, dokumentin vastuuhenkilö pyrkii korjaamaan ne välittömästi. Kun dokumentin katselmointi on valmis, katselmoija hyväksyy dokumentin. Katselmoija kirjaa ylös virheiden ja puutteiden lukumäärän. Virheiden ja puutteiden lukumäärä sekä katselmoidun dokumentin nimi toimitetaan Ossille. Koodin katselmointi: Koodin katselmointiin osallistuvat järjestelmäarkkitehti sekä ohjelmoijat. Kunkin tekemä koodi katselmoidaan ennen varsinaista moduulitestausta. Katselmointi suoritetaan yhden ryhmäläisen toimesta, katselmoija nimetään katselmointiajankohdan (eli koodin valmistumisen ja moduulitestaamisen ajankohdan) selvittyä. Vastuut: Sisäisten katselmointien vastuut on esitetty projektisuunnitelmassa. Asiakaskatselmointien päävastuu on projektipäälliköllä Dokumenttien julkaisukäytännöt Jokaisella kurssille palautettavalla dokumentilla tulee olla vastuuhenkilö, joka vastaa dokumentin valmistumisesta ajallaan, kirjoitustyön jakamisesta, dokumentin versioista ja sen julkaisemisesta. Kaikki projektin dokumentit julkaistaan PDF-muotoisina, ja ne ovat luettavissa kurssin sekä projektin kotisivujen kautta. Kaikki dokumentit suojataan salasanalla, joka on vain projektipäällikön tiedossa ja niiden osien kopiointi ja tulostus Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 16

17 estetään. Lisäksi dokumenttien metatietoihin liitetään asiakkaan vaatima legal notice, jossa kielletään dokumentin käyttö missään muodossa kurssin ulkopuolella. Dokumenttien säilyttäminen Innofactorin laitteistojen ulkopuolella muutoin kuin kurssin vaatimassa laajuudessa on kielletty. Kurssille palautettavat dokumentit julkaistaan palautuspäivänä ennen palautuksen takarajaa. 5.2 Projektin tuotteen hallinta Projektin tuotteeksi luetaan tuotettavan järjestelmän lisäksi tuotettava dokumentaatio. Projekti noudattaa pääpiirteissään USDP ohjelmistoprosessimallia, jonka mukaan projekti tuote syntyy muutaman iteraation kautta. Jokaisen iteraation jälkeen syntyy lopputuotos, joka toimii pohjana seuraavalle iteraatiolle Asiakkaan vaatimusten hallinta Seuraavassa asiakkaan vaatimusten hallinta on esitetty 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. 3. Ohjelmatyöryhmä luo vaatimusmäärittelyn järjestelmän ominaisuuksista, jotka tähtäävät asiakkaan määrittämien vaatimuksien täyttämiseen ja priorisoi ne. 4. Asiakas hyväksyy vaatimusmäärittelyn, missä asiakkaan vaatimukset on puettu järjestelmän ominaisuuksien muotoon ja priorisoitu. Muutokset vaatimuksiin tehdään muutostestenhallintamenettelyn (kappale 5.2.3) määrittämällä tavalla 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: dokumenttien hallinta ja varsinaisen ohjelmiston osien versionhallinta. Dokumenttien versiointi: Dokumentit tehdään Word2000 muodossa. Niitä säilytetään asiakkaan serverillä hakemistossa Innoshare/Customer Process/CU145/. Kaikilla projektiryhmän jäsenillä on oikeus em. hakemistoon. Dokumentit versioidaan ja numeroidaan Innofactor Oy:n versiointi ja numerointikäytännön mukaisesti, joka on jokaiselle projektiryhmän jäsenelle tuttu. Tuotteen versionhallinta: Tuotetta tuotetaan asiakkaan kehitysympäristössä asiakkaan kehitysympäristön vaatimusten mukaan. Versionhallinnassa käytetään CVS-ohjelmistoa, joka pitää huolen Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 17

18 tuotteen versioinnista mahdollistaen usean ohjelmoijan yhtäaikaisen kehitystyön ja keräten tietoa tehdyistä muutoksista Muutoksen hallinta 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. Asiakkaan ehdottama muutos: Jos asiakkaalla on muutosehdotus järjestelmän toiminnallisuuteen, aikatauluun tai vaatimuksiin liittyen, hän toimittaa muutospyynnön 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: Muutoksen toteuttamisen teknisen mahdollisuuden, eli pystytäänkö muutosta toteuttamaan. Muutoksen aikataulullisen vaikutuksen sekä vaikutukset muihin vaatimuksiin. 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. 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: Muutoksen vaikutukset muiden työhön. Muutoksen vaikutuksen asiakasvaatimuksiin. Selvitystyön jälkeen projektipäällikkö esittää muutosehdotuksen asiakkaalle, jonka kanssa neuvotellaan ja päätetään muutoksen toteuttamisesta. Bugin ja muutoksen ero: Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 18

19 Muutokset ovat asioita, jotka tehdään toisin kuin on vaatimusmäärittelyssä 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. 5.3 Projektin lopputuotteen tuotannon ohjeet ja käytännöt Tässä kappaleessa esitetään projektin tuotannon ohjeet ja käytännöt. Osa kappaleesta on kirjoitettu englanniksi. Esimerkiksi koodausohjeita on aivan turhaa ja jopa typerää kirjaittaa suomeksi, sillä koodauskielenä on luonnollisesti englanti ja suomenkieliset ohjeet eivät teettäisi muuta kuin lisävaivaa ja mahdollisia väärinkäsityksiä Käytettävät kehitystyökalut Ohjelmointi suoritetaan Microsoft Visual Studio.Net kehitystyökalulla. Kanta- ja luokkarakenteiden suunnittelussa ja luonnissa käytetään Microsoft Visio 2002 ohjelmaa. Ohjelmointia voidaan suorittaa myös EditPlus-ohjelmalla. Tietokannan muokkaamisessa ja hallinnassa käytetään Microsoft SQL Server 2000 Enterprise Manager ohjelmaa Käytettävä suunnitteluperiaate, kolmikerrosmalli, N-tier application architecture N-tier application architecture provides a model for developers to create a flexible and reusable application. By breaking up an application into tiers, developers only have to modify or add a specific layer, rather than have to rewrite the entire application over, if they decide to change technologies or scale up. A typical N-tier model is shown in following figure. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 19

20 Kuva 1 A typical N-Tier Model Data-tier Business-Tier In the term "N-tier," "N" implies any number -- like 2-tier, or 4-tier; basically, any number of distinct tiers used in your architecture. A basic n-tier system can have only 2 tiers, but a real scalable system has three or more tiers. These three basic tiers are data, business and presentation tiers. Basically this tier has the database with queries and storage optimization. It can also be simple structured plain text file like Comma separated values (CSV) or Extensible Markup Language (XML). There could be an application without this tier, but on the Age of Information almost every system has data that needs to be stored. Data tier is only intended to deal with the storage and retrieval of information. It doesn't care how to manipulate or deliver this data. No business logic should be placed in this tier. Data access can also be a separate tier, but usually it interacts so intensively with data tier that it can be included into data tier. It is merely a reusable interface to the database. Data Access tier has generic methods to interface with data. For example opening the connection to database or saving specified object. Business tier has all objects and rules. It's the brains of the application. It doesn t know anything about Hyper Text Markup Language (HTML) or Structured Query Language (SQL) and hasn't any code to access database or the like. Those tasks are assigned to Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 20

21 each corresponding layer above or below it. Business tier handles data manipulation and transformation into information Presentation Tier This layer provides an interface for the end user into application, like HTML pages or windows form, which is located on client's machine. This layer should not access directly the Data Access Tier. It works with results/output of the Business tier to handle the transformation into something usable and readable by the end user. Presentation logic tier consists to elements Graphical User Interface (GUI) and Presentation logic It's a good idea to split these two in different tiers. That way all the visual elements of GUI are in separate blocks and the look and fell of application is easily altered and there's no worry about messing the presentation logic. This is the grand idea in 3-tier architecture, but it's sometimes very difficult to keep all the tiers distinct and separate, specially with Business Tier and Presentation Tier. The application interfaces may have many expectations for data manipulated by the Business Tier. This is why many applications have GUI's that interface directly with Data access, or Business layer is not kept separated from the two other layers. But by doing these we lose all benefits of n-tier architecture. The whole point is to allow to plug each layer in and out without too many hassles and without limiting the technology used at each tier. This makes the application very scalable and modular Koodausohjeet, Coding Guidelines In order to craft efficient, robust and reusable code which is not dependent of the original writer, certain conventions have to be used. This applies also to the documentation resulting from the coding, which should be easy to maintain and consistent throughout the organization. This chapter contains two levels of standards: rules and guidelines. The Rules must be followed. The Guidelines are ways of coding deemed good by the people co-coding, auditing or reviewing the code and their usage is encouraged strongly. These guidelines are primarily written for the C# programming language. However, they can be easily adjusted into other similar languages such as Java or Object Pascal General Conventions Numbers as Opposed to Constants Ordinal constant values within the source code should always be avoided unless an extremely good reason to incorporate the constant is available. The literal number and string constants should be placed into static constants. for(i=0;i<31;i++) // bad static int DaysInJanuary=31; for(i=0;i<daysinjanuary;i++) // better Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 21

22 Grammar Although most modern language grammars allow writing of extremely space-efficient code, the code produced in such a style will often be volatile, hard to contemplate and prone to errors and bugs. while(thing.dothis(for(i=0;i<thing.dothenextthing();thing.count=i++))); Usage of Parentheses In Boolean expressions, parentheses should always be used. The priority of expression terms varies in different programming languages and a similar expression could produce a different result. if(a && b c && d) // bad if((a&& b) (c && d)) // better Style Conventions function public void Function(int Value1) { // actual code here } or public void Function(int Value1) { // actual code here } if there are a lot of parameters, place them as follows: public void Function(int Value1, int Value2, int Value3, int Value4, int Value5, int Value6, int Value7, int Value8, int Value9) { // actual code here } if/else if(something) { Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 22

23 // code } else { // more code } or if(something) { // code } else { // more code } while while(something) { // code } or while(something) { // code } switch switch(something) { case a : // code break; case b : // code (will follow to default) default : // code break; } or switch(something) { case a : // code break; case b : // code (will follow to default) default : // code break; } try/catch/finally try { // code } catch (ExceptionClass e) { // code Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 23

24 or } try { // code } catch (Exception e) { // code } Code Blocks As seen in previous examples, starting braces may be optionally at the end of the statement line or on the next line. Both of these styles are widespread. The ending brace must be on a line of it s own aligned with the statement line. The code between should be indented by two spaces. When you have decided which starting brace layout style you use, be true to it. When editing another persons code, use the original style. Other Style Conventions Line width is not limited. Everyone should use word wrap in their editors. Tabulator should be set to two spaces. Tab character is not allowed as it may result in incomprehensible and messy output when copied or pasted into different programs, browsers for example. The text editor should be configured to automatically expand tabulators Naming Conventions Case The case conventions of the programming language should be respected. SomeClass.SomeMethod(); // in C# and Delphi, but someclass.somemethod(); // in Java Local variables may be excluded from standardization. Classes and Namespaces All the namespaces within a project should have a prefix of three to five letters. If the classes of a certain namespace are for general usage, the prefix is not necessary. Classes do not need prefixes. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 24

25 Methods and Members Variables Methods and members of classes should have names which are so long that deduction of their function can be done. Variables should also have long enough names. Local variables operable in small scope such as those used in a loop counter may be exempted from this rule Versionhallinnan ja konfiguraation hallinnan ohje Yleistä CVS Concurrent Versioning System- on versionhallintaohjelmisto jota käytetään Kuopio projektin ohjelmistokehityksen apuvälineenä. Ohjelmisto mahdollistaa useiden ohjelmistokehittäjien yhtäaikaisen työskentelyn samojen tiedostojen parissa. Ohjelmistoa käytettäsessä ei haittaa vaikka eri ohjelmoijilla on keskeneräisiä tai toimimattomia versioita ohjelmistosta, sillä jokaisella on oma kehitysympäristönsä. Ohjelmisto mahdollistaa myös saman tiedoston useiden eri kehitysversioiden helpon hallinnan. Mikäli muutoksia on tehty samaan tiedostoon, ohjelma osaa hallita konfliktitilanteet. Eri versioita voidaan vertailla keskenään ja tarvittaessa palauttaa mikä tahansa olemassa oleva versio. Ohjelmaa käytetään hyväksi myös testauksessa. CVS:ään laitetaan muistiin kulloinkin testauksessa käytettävä versio, jolloin palaaminen myöhemmin saman version testaukseen on helppoa. Tarvittavat ohjelmistot Jokainen Kuopio-projektin jäsen tarvitsee Wincvs-ohjelmiston ja käyttöoikeudet Innofactorin cvs-repositoryyn. Jos jollakin projektiryhmän jäsenistä ei ole edellä mainittuja asioita, ohjeet asennukseen löytyvät Innosharen Kuopioprojektihakemistosta. Cvs:n käyttöohjeet löytyvät samasta osoitteesta asennusohjeiden kanssa. Cvs versionhallinta Kuopio-projektissa Kuopio-projektin repository sijaitsee osoitteessa :ext:tunnus@hinnuleus.venenum.com:/var/lib/cvs/kuopio, missä tunnus käyttäjätunnus. Jokaisella käyttäjällä on oma kehityspuunsa, jota hän muokkaa. Kehityspuu voi sijaita joko kehityspalvelimella tai käyttäjän omalla työasemalla. Vaatimuksena kyseisellä koneella on tarvittavat palvelin- ja kehitysohjelmistot. Aina kun repositoryyn siiretään jotain, on varmistettava muutosten toimivuus tai vähintään se, että koodi on käännettävissä. Repositorysta tulisi aina olla mahdollista hakea toimiva versio. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 25

26 Kaikkien muutosten repositoryyn viemisen yhteydessä tulee tehdä järkevä lokimerkintä tehdyistä muutoksista. Oman kehityspuun päivittäminen ennen töiden aloittamista on suositeltavaa. web.config.template on pohja, josta jokainen käyttäjä muokkaa omalle kehityspuulle sopivan version. web.config.dev on kehityspalvelimen versio ja web.config.final on julkaistavan järjestelmän konfiguraatiotiedosto. Tehtäessä merkittäviä muutoksia joihinkin osakokonaisuuksiin tulee sen hetkinen projektiversio merkitä siten, että versio on myöhemmin tunnistettavissa ja palautettavissa kokonaisuudessaan. Tämä pätee varsinkin eri testiversiohin(beta 1, Beta 2, jne.). Kehitys- ja julkaisupalvelimella olevia versioita ei päivitetä ilman Rami Laihon hyväksyntää. Tieokannasta pidetään Cvs-respositoryssä ajankohtainen kantakuvaus, joka päivitetään aina kun tietokantaan on tehty muutoksia. Muutokset kirjataan myös tekstitiedostoon SQL-kielellä helpottaakseen päivitystä muihin tietokantoihin. Vastaavat tiedostot reposytoryssä on DBMuutokset.sql ja DBMuutokset.txt. Cvs-repositoryn toiminnasta vastaa Mikko Lampi. Kaikissa cvsongelmatilanteissa otetaan yhteyttä häneen Koodin katselmointi/tarkastus käytäntö Jokaisen tuotetun modulin koodi katselmoidaan modulitestauksen valmistuttua eli kun modulin testaus on päätetty lopettaa testaussuunnitelmassa esitettyjen lopetuskriteereiden mukaisesti. Jokaisen modulin katselmointiin osallistuu koodin tuottaneen ohjelmoijan lisäksi yhdestä kahteen muuta ryhmän jäsentä. Mikäli mahdollista, järjestelmäarkkitehti osallistuu kaikkiin koodikatselmuksiin. Kun modulitestaus on lopetettu, tapahtuu koodikatselmointi seuraavasti: projektiryhmän kokouksessa sovitaan katselmointiryhmä katselmointiryhmä tutustuu koodiin etukäteen; muutoksia ei tehdä; katselmointiryhmän harkinnan mukaan koodi voidaan tulostaa paperille katselmointiryhmä sopii tapaamisen, jossa koodin tuottanut ohjelmoija esittelee tuotoksensa lyhyesti; muu ryhmä voi esittää kysymyksiä ohjelmoija kirjoittaa saamansa palautteen kirjallisesti ylös. Palautteeseen kirjataan löydetyt poikkeamat koodin kommentointi- ja muoto-ohjeesta sekä mahdolliset löydetyt piilevät virheet katselmointiryhmä päättää, pidetäänkö korjausten jälkeen uusintakatselmointi Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 26

27 Katselmointisession jälkeen ohjelmoija korjaa koodin löydettyjen virheiden ja poikkeamien osalta. Mikäli mahdollisia virhelähteitä löytyy, tehdään koodiin toiminnallisia muutoksia. Näille muutoksille suunnitellaan ja toteutetaan kevyt testaus. Koodin katselmoinnissa kiinnitetään erityinen huomio seuraaviin ominaisuuksiin: koodi on selkeää; katselmoijien tulee saada selville kohtuullisela vaivalla koodia lukemalla ohjelman toiminta koodissa ei ole poikkeamia kommentointi- ja muoto-ohjeesta koodissa ei ole epämääräisiä teknisia ratkaisuja; nk. purkkapatentteja tai selkeitä toiminnallisia virheitä Uusintakatselmointi tulee kyseeseen lähinnä, jos koodista löytyy toiminnalisia virheitä, jotka päätetään korjata, mutta myös jos poikkeamat kommentointi- ja muoto-ohjeesta ovat huomattavat. Turhia uusintakatselmointeja pyritään välttämään jo ennestään tiukan aikataulun ja resurssipulan vuoksi. 6. PROJEKTIN RISKIENHALLINTAPROSESSI Projektissa pyritään riskienhallinnan avulla pienentämään tulevien ongelmatilanteiden vaikutusta projektiin. Tunnistamalla mahdollisimman paljon mahdollisia projektin aikana eteen tulevia ongelmia etukäteen, voidaan jo valmiiksi sopia miten erilaisia ongelmia kohdatessa toimitaan ja projektin eteneminen ei ole vaarassa. Seuraavat kappaleet esittelevät projektissa käytettävää riskienhallintaprosessia, joka on sovelluttu käyttäen lähteitä [1], [2], [3]. Projektin riskienhallintaprosessi on pääpiirteissään kuvattu seuraavassa kuvassa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 27

28 Kuva 2 Projektin riskienhallintaprosessi 6.1 Riskien tunnistaminen Ensimmäinen riskientunnistusvaihe toteutettiin osana projektin suunnittelua ja se on dokumentoitu projektisuunnitelmassa. Projektin edetessä riskien tunnistus tapahtuu jokaisen projektin päävaiheen alussa kootusti Ossi Jokisen vetämänä. Jos joku projektiryhmän jäsen tai asiakas katsoo olevan tarvetta päivittää riskienhallintasuunnitelmaa, se tapahtuu viikkopalaverissa. Uusia riskejä tunnistettaessa tulee määrittää riskille nimi, riskin toteutumisen indikaattorit, riskin hallintakeinoja joita voidaan toteuttaa riskin toteutumisen estämiseksi, riskin toteutumisen seuraukset ja vakavuus projektille asteikolla 1-5 (5 erittäin vakava, 1 ei merkittävä) sekä pitää kirjaa toteutetuista riskiä ehkäisevistä vastatoimenpiteistä, jos ne katsotaan tarpeellisiksi. Riskit ja tunnistusvaiheessa kerätty tieto kootaan projektin projektisuunnitelmassa esitettyyn riskitaulukkoon, jota päivitetään edellisen kappaleen mukaisesti. 6.2 Riskien monitorointi Riskien monitorointi eli indikaattorien seuraaminen ja toteutumismahdollisuuden arviointi on jokaisen projektiryhmän jäsenen ja asiakkaan vastuulla. Jos joku projektin osapuolista katsoo, että jokin riski saattaa toteutua hyvin suurella todennäköisyydellä, niin hänen tulee ottaa riski keskustelun aiheeksi viikkopalaverissa. Kuopio2002, vain kurssin T arvostelun vaatimaan käyttöön Sivu 28