Tiivistelmä: Sovellusprojektissa tietotekniikan opiskelijoista koostuva kolmen tai neljän hengen ryhmä määrittelee, suunnittelee, toteuttaa, testaa ja dokumentoi tilaajalle ohjelmistosovelluksen ohjaajien valvonnassa. Ohjeessa annetaan neuvoja Jyväskylän yliopiston tietotekniikan laitoksella toteutettavien Sovellusprojektien menestykselliseen suorittamiseen. Ohjeen avulla projektin jäsenet pystyvät hallitsemaan projektin eri vaiheita ja laatimaan projektiin liittyviä dokumentteja.
Parempilaatuiset
pdf-
ja
ps-
muotoiset ohjetiedostot ovat saatavissa.
Avainsanat: Sovellusprojekti, ohjelmistoprojekti,
opiskelijaprojekti, projektityö, ryhmätyö, vaatimusmäärittely,
suunnittelu, ohjelmointi, testaus, dokumentointi,
projektipalaverit, projektin päättäminen.
Sovellusprojektien opiskelijoiden suositellaan käyvän ohje
läpi projektin alussa ja lopussa, ennen projektikokoontumisia
sekä erityisesti projektien dokumentteja laatiessaan!
Sovellusprojekti antaa tietotekniikan opiskelijoille käsityksen ja kokemusta työelämän ohjelmistoprojektien läpiviennistä, työtavoista ja ryhmätyöstä. Projektissa toteutetaan kurssien harjoitustöitä huomattavasti laajempi ohjelmointisovellus yritykselle, valtion tai kunnan organisaatiolle tai Jyväskylän yliopiston jollekin laitokselle. Projektiorganisaatio koostuu opiskelijoiden muodostamasta projektiryhmästä, toimeksiantajan eli tilaajan edustajista sekä asettajan eli tietotekniikan laitoksen edustajina toimivista vastaavasta ohjaajasta ja teknisestä ohjaajasta.
Projektiohje on suunnattu Jyväskylän yliopiston tietotekniikan laitoksella toteutettavien Sovellusprojektien jäsenille. Ohje on muotoutunut aiempien opiskelijaprojektien yhteydessä havaittujen ongelmien sekä hyvien ja huonojen kokemusten pohjalta. ''Kantapään kautta oppiminen'' on yleisesti hyväksytty tapa, mutta projektiryhmien ei silti kannattane käydä läpi kaikkia aiempien projektien kokemia karikkoja.
Ohje neuvoo projektin eri vaiheissa toteutettavien dokumenttien ja raporttien sisällön suunnittelussa. Ohjeessa kuvataan myös sovelluksen suunnittelua ja toteutusta, projektin kokoontumisia ja arvostelukäytäntöä sekä projektin aloittamisessa ja päättämisessä huomioitavia asioita. Sovelluksen toteutuksen lisäksi arvostelussa kiinnitetään huomiota projektin läpivientiin ja ryhmän toimintaan.
Luvut on pyritty kokoamaan kuhunkin Sovellusprojektin vaiheeseen, kokoontumiseen tai dokumenttiin liittyviksi asiakokonaisuuksiksi. Lukuja ei ole kuitenkaan kirjoitettu täysin erillisiksi itsenäisiksi osioiksi. Erityisesti luvuissa 3 ja 4 käsitellään toisiinsa liittyviä asioita. Jos siis kaipaat neuvoja tiettyyn projektin vaiheeseen tai dokumenttiin, kannattaa kyseisen luvun lisäksi tutustua myös muihin asiaa käsitteleviin lukuihin.
Luku 2 käsittelee lyhyesti erilaisten dokumenttien kirjoittamista. Luvussa 3 annetaan yleisiä ohjeita projektin läpiviemiseen ja sovelluksen ohjelmoimiseen.
Luvussa 4 käsitellään projektin tuloksia ja niiden sisällöllisiä vaatimuksia. Kyseisessä luvussa kuvataan projektin suunnitteludokumenttien ja raporttien sisältöä, käyttöohjetta ja ohjelmalistauksia sekä ajankäytön raportointia.
Luvussa 5 käsitellään projektiryhmien kokoontumisia ja niistä laadittavia pöytäkirjoja. Projektien arvosteluperusteita ja projektien päättämiseen liittyviä asioita esitellään luvussa 6.
Sovellusprojektien vastaavat ohjaajat kiinnittävät raporttien sisällön lisäksi huomioita myös niiden kieliasuun ja rakenteeseen. Selkeä ja sujuva esitystapa auttaa ja nopeuttaa dokumenttien tietosisällön tulkitsemista. Samalla projektin jäsenet saavat kokemusta teknisten dokumenttien ja tieteellisten tutkielmien laatimisesta ja vaatimuksista.
Sovellusprojektien yhteydessä kirjoitettavat dokumentit tulisi pääasiallisesti suunnata henkilöille, joiden tietämys aiheesta, sovelluksen toteutuksesta ja työkaluista on hieman vähäisempää kuin projektin jäsenten, ohjaajien ja toimeksiantajan edustajien. Dokumenttia ei siis tulisi kirjoittaa tavalla, joka olettaa lukijan olevan jo aiemmin tutustuneen kyseiseen aihealueeseen, projektiin tai sovellukseen.
Luvussa annetaan muutamia olennaisia neuvoja Sovellusprojekteihin liittyvien dokumenttien kirjoittamiseen. Kattavampi ohje opinnäytetöiden kirjoittamiseen [Santanen, 2000] on saatavilla tietotekniikan laitoksen WWW-sivuilta HTML-, pdf- ja ps-muodossa.
Word-tekstinkäsittelyohjelman käyttöön liittyviä vinkkejä löytyy mm. Petri Heinosen laatimista ohjeista [Heinonen, 2001] ja [Heinonen, 2002]. Lisäksi tietotekniikan laitoksen pro gradu -tutkielmien ohjeiden WWW-sivun kautta on saatavilla tutkielmien Word- ja LATEX-pohjat, joita voi halutessaan hyödyntää myös Sovellusprojektien dokumenttien yhteydessä.
Sovellusprojektin dokumentit tulee kirjoittaa jollakin tekstinkäsittelyohjelmalla. Kirjoittamisessa tulee pyrkiä mahdollisimman sujuvaan tyyliin ottamalla huomioon esimerkiksi luvun lopussa ja kirjoitusohjeessa [Santanen, 2000] käsiteltävät aiempien projektien dokumentoinnissa havaitut kirjoitus- ja muotoiluvirheet.
Projektidokumenttien kansisivulla tulee mainita
Useita raportteja läpikäyvä arvostaa lyhyttä tiivistelmää tekstin alussa, jolloin hän saa nopeasti käsityksen sen sisällöstä. Näin hänen kiinnostuksensa raporttiin saattaa herätä ja hän perehtyy siihen tarkemmin sen sijaan, että heittäisi sen suoraan kierrätyslaatikkoon. Tiivistelmän jälkeen kokenut lukija saattaa vielä käydä läpi johdannon dokumentin alusta ja yhteenvedon sen lopusta, joten niidenkin kirjoittamiseen tulee nähdä vaivaa. Dokumentin tulee sisältää sisällysluettelo.
Jokaisen luvun alussa olevan ''johdantokappaleen'' avulla lukija johdatetaan luvussa käsiteltäviin asioihin. Älä missään nimessä kirjoita luvun ja alaluvun otsikoita allekkain ilman niiden väliin sijoitettua sidoskappaletta!
Teksti ei saa koostua ainoastaan esiintulleita asioita sisältävistä listoista, joten ranskalaisten viivojen liiallista käyttöä tulee välttää. Toisinaan listojen käyttö sen sijaan selkeyttää ja tukee tekstiä. Listojen, kuvien ja taulukoiden yhteydessä tulee käyttää ''sidostekstiä'', jolla lukija johdatetaan niissä käsiteltävään asiaan.
Sivut ja luvut tulee numeroida. Myös sisällysluettelon tulee sisältää luku- ja sivunumeroinnin. Kuvat ja taulukot tulee myös numeroida, jolloin niihin viittaaminen on helpompaa. Lukuihin, kuviin ja taulukoihin tulee viitata tekstin yhteydessä niiden numeroilla. Kuva- ja taulukkotekstit tulee keskittää sivusuunnassa ja ne tulee kirjoittaa normaalia tekstiä kapeammiksi.
Liian pitkiä lauserakenteita ja kappaleita tulee välttää, sillä ne hankaloittavat asian ymmärtämistä. Englanninkielisten termien käyttöä tulee välttää, jos vastaava suomenkielinen termi löytyy. Monesti kannattaa englanninkielinen vastine laittaa kursivoituna sulkuihin suomenkielisen termin perään.
Tärkeiden sanojen ja lauseiden esiintuomisessa kannattaa käyttää normaalitekstistä eroavaa kirjasinta, kuten vahvennusta. Kursivointia käytetään pääasiassa suorissa lainauksissa, termien englannin- tai suomenkielisten vastineitten osoittamiseen sekä käyttöliittymien tekstien yhteydessä. Tekstin seassa olevat ohjelmakoodit, käskyt, parametrit, syötteet ja tulosteet tulee kirjoittaa tasavälisellä mahdollisimman paljon ohjelmakoodia muistuttavalla kirjasimella. Mahdolliset matemaattiset kaavat kannattaa myös kirjoittaa erottuvalla ''matemaattisella'' kirjasintyylillä.
Sovellusprojektit poikkeavat aiheiltaan, aihealueiltaan ja työkaluiltaan huomattavasti toisistaan. Eroistaan huolimatta projektien vaiheet sekä sovellusten ohjelmoinnissa ja testauksessa huomioitavat asiat ovat pääosin samat.
Sovellusprojektin laajuus on 10-15 opintopistettä (viidestä kahdeksaan opintoviikkoa) vastaten 267-400 työtuntia kutakin ryhmän jäsentä kohti. Lisäksi projektiin liittyvät koulutukset ja perehdytykset on koottu kolmen opintopisteen (kahden opintoviikon) laajuiseksi oheiskurssiksi Sovellusprojektin hallintaa, viestintää ja työkaluja. Kunkin projektin jäsenen tulee kirjata ajankäyttöraportissaan kyseiseen kurssiin kuuluviksi koulutukset, väliesittelyt ja niiden valmistelun sekä dokumenttien rakenteen ja kirjoitusasun muokkaukseen kuuluneet työt.
Projektin toteutusaikaa on noin 13-16 viikkoa, joten jokaisen projektin jäsenen tulee varata viikottain vähintään 20-30 tuntia projektityöhön. Aiempien projektien yhteydessä on havaittu projektin vastaavan työmäärältään vähintään kahta luentokurssia. Projektin vaatima työmäärä on ehdottomasti otettava huomioon kyseisen lukukauden opintosuunnitelmaa laadittaessa.
Sovellusprojektin työmäärää ei pystytä kunnolla arvioimaan projektin alussa, joten työhön tulee varata riittävästi aikaa heti alusta lähtien. Tällä tavoin pystytään vähentämään projektin lopun kiireitä sekä välttämään projektin viivästyminen. Työmäärän arvioinnin hankaluus johtuu pääosin eroista aiheissa sekä jäsenten, ohjaajien ja tilaajan edustajien tiedoissa ja taidoissa. Lisäksi tilaajan toiveiden ja tarpeiden jäsentymättömyys saattaa vaatia arvioitua enemmän panostusta vaatimusten määrittelyyn.
Sovellusprojektien loppuesittely järjestetään syyslukukausina joulukuun puolessa välissä ja kevätlukukausina toukokuun puolessa välissä. Kehitettävä sovellus voi viivästyä ennakoimattomien ongelmien vuoksi. Tästä johtuen sovellus tulee suunnitella valmistuvan vähintään kaksi viikkoa ennen loppuesittelyä. Välttämättä projektien dokumentointi ei ole kokonaan valmis ja hyväksytty loppuesittelyyn mennessä, joten projektille tulee varata ''pelivaraa'' vähintään pari viikkoa loppuesittelyn jälkeenkin. Projektin mahdollinen viivästyminen tulee ehdottomasti ottaa huomioon mm. työtehtävistä sopiessaan ja lomamatkoja varatessaan.
Kaikkien projektiryhmän jäsenten tulee osallistua ohjelmistoprojektin eri vaiheisiin ja työtehtäviin, joita ovat määrittely, suunnittelu, ohjelmointi ja testaus sekä niihin sisältyvä dokumentointi. Tällä tavoin ryhmän kaikki jäsenet saavat riittävän kuvan ohjelmistoprosessista kokonaisuutena. Projektin jäsenten työtehtävien tai vastuualueiden liiallisen korostunut jako saattaa laskea arvosanaa. Toisaalta kaikkia tehtäviä ei tule suorittaa yhdessä, vaan tehtävien jako on olennainen osa projektia.
Projektiryhmän tulee valita keskuudestaan projektipäällikkö. Tehtävää voidaan tarvittaessa kierrättää projektin jäsenten kesken, mutta tällöin tehtävän opiskeluun ja siirtämiseen tulee varata riittävästi aikaa. Projektipäällikön olennaisimmat tehtävät ovat projektin tehtävien jakaminen ja hallinta, projektin ja sovelluksen tilan säännöllinen määrittely sekä tiedottaminen projektiryhmälle ja -organisaatiolle. Projektipäällikön tehtävä tuo vastuun ohessa valtaa, joka tulee näkyä päällikön ja ryhmän jäsenten toimintatavoissa.
Projektityö aloitetaan aiheeseen ja sen taustoihin sekä ohjelmointityökaluihin tutustumisella. Projektiryhmä laatii ensimmäisen 3-6 viikon aikana vaatimusmäärittelyn sekä projekti- ja sovellussuunnitelman aiheesta saadun materiaalin sekä projektipalavereissa toteutetun aiheen tarkennuksen ja rajauksen pohjalta.
Huolellisesta suunnittelusta ja ohjelmien asteittaisesta tarkentamisesta on havaittu olevan runsaasti hyötyä aiempien projektien yhteydessä. Aiempien projektien jäsenet ovat projektinsa jälkeen painottaneet määrittelyn ja suunnittelun tärkeyttä erityisesti virheiden ja ongelmien välttämisessä. Suunnitteluvaiheessa väärällä tavalla ''säästetty'' työmäärä kuluu moninkertaisesti projektin lopussa heikkojen ratkaisujen ja virheiden jäljittämiseen ja korjaamiseen.
Suunnittelu helpottaa ja nopeuttaa huomattavasti Sovellusprojektien kaltaisten laajojen ja monimutkaisten sovellusten toteuttamista ja hallitsemista. Suunnitteludokumenttien avulla projektiryhmä, ohjaajat ja toimeksiantajan edustajat pystyvät seuraamaan työnsä edistymistä ja pitämään mielessä projektin tavoitteet. Niiden laatimisen kautta projektiryhmä joutuu tutustumaan aihealueeseen ja käytettäviin työkaluihin.
Suunnitteludokumentit edesauttavat projektiryhmän sekä ohjaajien ja tilaajan edustajien välille muodostuvan yhteisen kielen kehittymistä. Niiden avulla voidaan havaita projektiryhmän, ohjaajien ja tilaajan edustajien erilaisia ja virheellisiä käsityksiä jo projektin alkuvaiheissa, jolloin niihin voidaan puuttua riittävän ajoissa.
Vaatimusmäärittelyn ja sovellussuunnitelman voidaan katsoa olevan projektiryhmän, ohjaajien ja toimeksiantajan välinen sopimus toteutettavasta sovelluksesta. Huolellisen määrittelyn ja suunnittelun avulla voidaan säästää runsaasti aikaa ja resursseja projektin myöhemmissä vaiheissa. Suunnittelun kautta saadaan tavoitteita vastaava ja laadukas sovellus. Lisäksi hyvin laadittujen suunnitteludokumenttien pohjalta projektin ja sovelluksen loppuraportointi on suoraviivaista, sillä monesti se voidaan toteuttaa pienin muokkauksin ja suunnitteludokumentteja täydentämällä.
On kuitenkin huomattava, että toteutettu sovellus ja toteutunut projekti eivät koskaan täysin vastaa suunniteltua. Ensimmäisten (kuten myöhempienkin uutta tekniikkaa soveltavien) ohjelmistoprojektien yhteydessä väistämättä projektin jäsenet eivät pysty huomioimaan kaikkia oleellisia asioita. Projektin jäsenten tulee siis asennoitua mahdollisiin muutoksiin projektin kuluessa. Projekti- ja sovellussuunnitelman laatiminen kannattaa toteuttaa rohkeasti, sillä ne joka tapauksessa antavat tukevan perustan projektityölle ja sovelluksen toteuttamiselle. Muutoksista suunnitteludokumentteihin voidaan tarvittaessa sopia projektipalavereissa, kunhan sovitut muutokset tulevat yksityiskohtaisesti dokumentoitua esimerkiksi palaveripöytäkirjoihin.
Määrittelyyn ja suunnitteluun liittyviä tehtäviä voi jakaa ryhmän jäsenten kesken. Olennaista on tällöin se, että kaikki projektiorganisaatioon kuuluvat ovat tietoisia kunkin ryhmän jäsenen suunnitelmista. Suunnittelun aikana yhden ryhmän jäsenistä tulisi mielellään tutustua ohjelmointityökaluihin etenkin, jos ne ovat jäsenille uusia. Tämä nopeuttaa projektin siirtymistä suunnittelusta toteutukseen.
Käytännön ongelmat ilmenevät yleensä vasta sovellusta ohjelmoitaessa. Siksi tähän vaiheeseen tulee varata vähintään yhdeksän viikkoa. Tärkeää on koko ajan pitää mielessä, mitä ohjelman on alunperin haluttu tekevän. Ajoittainen suunnitelman ja siihen tehtyjen muutosten läpikäynti auttaa tavoitteiden mielessäpitämistä.
Erityisesti tulee muistaa dokumentoida ja kommentoida ohjelmaosiot jo niitä ohjelmoitaessa. Tällöin suunniteltu ohjelmaosion toiminta muistuu myöhemmin nopeasti mieleen, sillä yleensä ohjelmoija unohtaa vaativan toteutusratkaisun muutamassa päivässä. Ohjelmakoodit ja -kommentit tulee kirjoittaa englanniksi.
Huomio kaikki hakkerit! Käsittämättömän monimutkainen tai ''jippomainen'' ohjelmakoodi ei tarkoita sitä, että projekti on onnistunut ja erinomainen. Yleensä tällöin on kyse täysin päinvastaisesta. Projektiryhmän toteuttamaa lähdekoodia tullaan nimittäin todennäköisesti jatkokehittämään. Lähdekoodi tulee laatia siten, että se on kääntäjäohjelman lisäksi kenen tahansa ohjelmoijan helposti tulkittavissa. Koodin selkeä rakenne ja kommentointi ovat siten oleellinen osa ohjelmointia.
Absoluuttisia polkumäärityksiä ei missään nimessä tule jättää ohjelmakoodiin. Sovelluksen alustusparametrit kannattaa lukea ja tallentaa erilliseen tiedostoon. Tällöin ne ovat helpommin muokattavissa sekä ohjelmallisesti että käyttäjän toimesta, eikä lähdekoodia tarvitse kääntää kyseisten parametrien arvoja muutettaessa. Kyseisiä alustustiedostoon sisällytettäviä arvoja ovat mm. ikkunoiden koot ja paikat, datatiedostojen oletushakemistot sekä parametrien oletusarvot.
Lähdekooditiedostoista tulee ottaa varmuuskopioita riittävän usein. Tällä tavoin voidaan välttää päivien tai jopa viikkojen työn menetys virheen tai kovalevyn rikkoutumisen vuoksi, josta on kokemusta parista aiemmasta projektista. Varmuuskopio kannattaa sijoittaa fyysisestikin jonnekin muualle kuin sovelluksen kehityskoneelle. Erityisesti yrityksille toteutettavien projektien yhteydessä on kuitenkin huomattava, että salassapitosopimus edellyttää lähdekoodi- ja dokumenttitiedostojen huolellista käsittelyä. Projekteissa toivotaan myös käytettävän CVS-versionhallintajärjestelmää lähdekoodien ja dokumenttien versioiden hallintaan.
Projektiryhmän ei kannata taistella ohjelmointiin tai johonkin muuhun liittyvän ongelman kanssa päiväkausia. Tietoa ongelmien ratkaisemiseen kannattaa etsiä projekteille hankituista kirjoista ja verkosta löytyvistä dokumenteista. Lisäksi teknisen ohjaajan, vastaavan ohjaajan ja tilaajan edustajien puoleen kannattaa rohkeasti kääntyä. Tarvittaessa ohjaajat etsivät neuvojiksi ulkopuolisia ongelma-alueen asiantuntijoita.
Tekninen ohjaaja neuvoo ohjelmointikieleen, ohjelmankehitystyökaluun, tekniikoihin ja toisinaan myös aihealueeseen liittyvissä ratkaisuissa ja ongelmatilanteissa. Hän valvoo pääasiallisesti lähdekoodin laatua ja kommentoinnin tasoa, joten lähdekoodista tulee pyytää palautetta tekniseltä ohjaajalta erityisesti sovelluksen toteutuksen alku- ja loppuvaiheissa.
Vastaava ohjaaja valvoo projektin suorittamista määritellyssä aikataulussa sekä tulosten valmistumista ja laatua kokonaisuutena. Hän siis ohjaa toiminnallaan projektin sujuvaa läpivientiä kohti laadukkaita ja vaatimuksia vastaavia tuloksia. Hän puuttuu myös sovelluksen käytettävyyteen testaamalla sen käyttöliittymää. Vastaava ohjaaja antaa myös palautetta dokumenttien sisällöstä, rakenteesta ja kieliasusta. Tällä pyritään ohjaamaan projektin jäseniä sujuvaan tekniseen dokumentointiin sekä tukemaan myöhempien teknisten dokumenttien ja tutkielmien laatimista.
Vastaavalta ohjaajalta voi pyytää projektin käyttöön projektikansion ja sen välilehdet, CD-taskut kansioon, CD-aihioita sekä muita projektin tarvitsemia toimistotarvikkeita. Myös projekteissa tarvittavien kirjojen, ohjelmien ja laitteiden hankkimista voi ehdottaa vastaavalle ohjaajalle.
Tilaajan edustajat tuntevat yleensä aihealueen parhaiten projektiorganisaation jäsenistä. Tästä johtuen projektin sisällöllinen ohjaus tapahtuu suurelta osin tilaajan toimesta. Tilaajan edustajat pystyvät yleensä mm. parhaiten priorisoimaan sovellukseen toteutettavat ominaisuudet sekä määrittämään käyttöliittymään sisällytettävät tiedot ja toiminnot. Joissakin projekteissa tilaajan edustajat osallistuvat myös ohjelmointikielen ja -työkalun käytön ohjaamiseen.
ATK-tuki vastaa pääosin projektin käyttöön asetettujen mikrojen käyttöjärjestelmien ja ohjelmien asennuksesta ja ylläpidosta sekä verkon ja laitteiden toiminnasta. Pyynnöt ohjelmien asennuksen osalta ja virheilmoitukset tulee suunnata ATK-tuen lisäksi kaikille projektiorganisaation jäsenille. Tällöin myös organisaatio on tietoinen asennuksista ja ongelmista.
Kukin ohjelmalohko on pyrittävä testaamaan erillisenä (ns. yksikkö- eli moduulitestaus) välittömästi valmistuttuaan, mikäli se vain on mahdollista. Kokemus on osoittanut, että tämä säästää runsaasti projektin jäsenten kokonaistyöaikaa sekä vähentää virheenjäljittämistä ohjelmalohkoja yhdistettäessä ja sovellusta kokonaisuutena testattaessa.
Pitää kuitenkin muistaa, että yhdistettäessä ohjelmaosioita lopulliseksi kokonaisuudeksi, ne vaikuttavat toistensa toimintaan. Ohjelmistojenkin osalta siis pätee se, että kokonaisuus on enemmän kuin osiensa summa. Tämän vuoksi koko ohjelmapaketti tulee saattaa ns. integraatiotestausvaiheeseen (eli vaiheeseen, jossa ohjelman luullaan toimivan ''täydellisesti'') hyvissä ajoin (vähintään kolme viikkoa) ennen loppuesittelyä.
Sovellusta tulee mahdollisuuksien mukaan testata eri käyttöjärjestelmissä, mikro- ja ohjelmistokokoonpanoissa sekä erityisesti käyttöympäristössä, johon ohjelmankehitystyökalua ei ole asennettu. Testauksessa tulee myös huomioida mm. käyttöjärjestelmään liittyvien asetusten (kuten kirjasinkoot, desimaalierotin ja päivämäärät) vaikutus ohjelman toimintaan ja käyttöliittymään.
Projektien avotilaan on sovellusten testausta varten sijoitettu heikkotehoiset Windows- ja Linux-testimikrot. Ne sisältävät mm. useita versioita eri WWW-selaimista, eikä niihin ole asennettu ohjelmankehitysympäristöjä lainkaan.
Kokemus on valitettavasti osoittanut, että viimeistään projektin loppuesittelyssä sitä ennen virheettömästi toiminut (vähän testattu) ohjelma kaatuu! Hallittu testaus ja sen dokumentointi ovatkin siten oleellinen osa sovelluksen toteuttamista.
Lähdekoodeissa ja raporteissa tulee selkeästi erotella projektiryhmän (ja haluttaessa yksittäisen projektin jäsenen) toteuttamat osat muualta saaduista ja muokatuista osista. Kunkin lähdekooditiedoston tai jopa yksittäisen aliohjelman alussa tulee mainita tekijöiden nimet kera vuosilukujen, jotta tekijänoikeudet tulevat mahdollisimman selkeästi esille.
Yrityksille toteutettavissa Sovellusprojekteissa oikeuksien siirrosta sovitaan projektin alussa laadittavalla projektisopimuksella (malli [Santanen, 2006b]). Tilaajan vaatimuksesta voidaan joutua laatimaan salassapitoa varten vaitiolosopimus (malli [Santanen, 2006a]).
Jos projektiryhmä hyödyntää työssään olemassaolevaa lähdekoodia (esim. avoimen lähdekoodin komponentteja, kurssien luentomateriaalia tai harjoitusten esimerkkikoodeja), sen tekijä(t) on aina mainittava kyseisen lähdekooditiedoston alussa. Kyseiseltä tekijältä tulee pyytää (mielellään kirjallinen) lupa koodin käyttöön, ettei työssään rikkoisi hänen tekijänoikeuksiaan. Lisäksi ulkoisten lähdekoodien ja komponenttien käytölle tulee aina saada tilaajan ja ohjaajien hyväksyntä.
Joissain tapauksissa tekijä on joko lähdekoodissa tai erillisessä tiedostossa maininnut koodin hyödyntämisen ehdoista. Epäselvissä tapauksissa kannattaa kysyä neuvoa vastaavalta ohjaajalta.
Olennainen osa ohjelmistoprojektia on projektin sekä siinä toteutettavan sovelluksen ja tulosten dokumentointi. Dokumentointia tulee tehdä koko ajan projektin edetessä, eikä sitä saa lykätä viimeiselle viikolle.
Dokumentteihin, sovellukseen ja lähdekoodeihin tulee liittää versionumerointi tai päiväys. Niissä on monesti myös muutoshistoria sisältäen muokkaajan nimen lisäksi lyhyet kuvaukset tehdyistä muutoksista ja lisäyksistä versioiden välillä. Ensimmäinen tilaajan edustajien ja ohjaajien hyväksymä versio on numeroltaan 1.0, joten sitä aiempien versioiden numerointi on muotoa 0.x.
Dokumentointi tukee projektin kuluessa sen etenemisen ja tavoitteiden seurantaa. Projektin lopussa viimeisteltävien raporttien kautta sovelluksen käyttö ja toteutusratkaisut sekä projektin kokemukset siirretään tulevien kehittäjien tietoon. Lisäksi dokumentointi toimii projektin edetessä vaatimusten ja toteutusratkaisujen kartoituksen tukivälineenä sekä alustavana tehtävälistana. Ryhmän jäsenten tulee siis tutustua laatimiinsa dokumentteihin säännöllisesti, jotta projektin tavoitteet ja tila ovat tiedossa.
Sovellusprojektissa julkisiksi sovitut dokumentit, ohjelmat ja materiaali kootaan projektikansioon, jonka projektin loputtua vastaava ohjaaja sijoittaa julkisesti nähtäville tietotekniikan laitoksen yleisiin tiloihin. Lisäksi erityisesti yritykselle toteutettavan projektin yhteydessä tilaaja saattaa vaatia toteutettavaksi muitakin dokumentteja, jotka yleensä jäävät pelkästään tilaajan haltuun.
Tilaajan ja ohjaajien hyväksyttyä projektin yksittäiset tulokset projektiryhmältä kuluu vähintään kaksi viikkoa projektikansion kokoamiseen ja sille hyväksynnän saamiseen tilaajan edustajilta ja ohjaajilta. Tämä johtuu käsittelyn vaatimasta ajasta ja muista töistä, joten jäsenten tulee huomioida kyseinen ajantarve.
Dokumentointiin kuuluvat sekä paperille tulostettuina että CD:lle tallennettuina kaikki projektiryhmän tulokset, joita ovat
Kaikki projektikansion osat tulee toimittaa laitokselle kahtena CD:nä. Kunkin levyn sisältö tulee kuvata CD:llä esimerkiksi readme- tai lueminut-tiedostossa. Tiedostot tulee sijoittaa yhteenkuuluviin kokonaisuuksiin hakemistoihin jaettuina. Tietotekniikan laitokselle toteutettavan projektin yhteydessä lähdekoodit ja dokumentit voidaan tallentaa lisäksi projektin hakemistoon laitoksen koneelle (lisätietoa ATK-tuelta).
On kuitenkin huomattava salassapitosopimusten sitovuus erityisesti maksullisten Sovellusprojektien yhteydessä. Tällöin tilaajan vaatimuksia on kuultava ja sovittava laitokselle jäävän kansion sisällöstä sekä dokumenttien että ohjelmakoodin ja ajokelpoisen ohjelman osalta. Yrityksille toteutettavien Sovellusprojektien yhteydessä projektiryhmä laatii ensimmäisen kuukauden aikana projekti- ja vaitiolosopimuksen, joiden mallit löytyvät WWW-dokumenteista [Santanen, 2006b] ja [Santanen, 2006a].
Edellisten projektien kansioita on nähtävillä projektisolun avotilassa sijaitsevissa kirjahyllyissä. Kansioihin tutustuminen on erittäin suositeltavaa etenkin projektin alussa ja kunkin dokumentin kirjoittamisen yhteydessä. Kansioiden kanteen on merkitty kyseisen projektin arvosana. Lisäksi kansiot sisältävät toimeksiantajan edustajan ja vastaavan ohjaajan lausunnot projekteista sekä mahdolliset projektin jäsenten itsearvioinnit.
Projektikansioita ei toivota lainattavan, jotta ne olisivat koko ajan kaikkien kuluvan lukukauden Sovellusprojektien käytössä. Lyhytaikaisen lainauksen yhteydessä tulee lainaajan ja kansion nimet sekä lainapäivämäärä kirjoittaa kansiohyllyn päädyssä olevaan listaan. Kansiota palautettaessa tulee kyseiseen listaan kirjata palautuspäivämäärä.
Sovellusprojekti suoritetaan kiinteän aikataulun mukaan. Ohjelmointi aloitetaan vasta määrittelyn ja suunnittelun jälkeen. Projekti aloitetaan vaatimusmäärittelyllä sekä projekti- ja sovellussuunnitelmilla, joiden tekemiseen tulee varata aikaa 3-6 viikkoa aiheesta riippuen.
Projektisuunnitelma keskittyy projektin organisaation, ympäristön ja resurssien kuvaamiseen sekä käytänteiden ja läpiviennin suunnitteluun. Joidenkin projektien yhteydessä toteutetaan sovellussuunnitelman sijaan tilaajan mallien mukaiset sovelluksen määrittely- ja suunnitteludokumentit. Joka tapauksessa projektin ja sovelluksen toteutuksen suunnitelmat on laadittava erillisinä dokumenteina, jotta niiden toteutumista voidaan myös seurata ja hallita toisistaan erillään.
Projektisuunnitelmassa tarkasti määritellään mm. seuraavat asiat:
Vaatimusmäärittely kuvaa, mitä toteutetaan projektissa. Se sisältää yleensä seuraavat sovellukseen liittyvät asiat:
Yleensä kehitettävän sovelluksen taustalla olevien prosessien vaiheiden selvittämisen kautta löytyvät olennaisimmat vaatimukset ja rajoitteet. Taustojen ja kokonaisuuden kuvaaminen auttaa ymmärtämään asiayhteyksiä, joihin vaatimukset liittyvät. Vaatimusten priorisoinnin kautta projektin puitteissa toteutettava sovelluksen versio tulee sisältämään tilaajan ja loppukäyttäjien kannalta vähintään kaikkein olennaisimmat tiedot ja toiminnot.
Sovellussuunnitelma kuvaa, miten määritellyt vaatimukset toteutetaan. Sen tulee sisältää ainakin seuraavat asiat:
Projektissa voidaan laatia myös erillinen testaussuunnitelma sisältäen testausympäristöt ja läpikäytävät testitapaukset. Testaussuunnitelman avulla saadaan testauksesta hallittu, järjestelmällinen ja toistettava. Yleisesti testauksen osalta tulisi ensin kuvata testattavan järjestelmän kokoonpano (laitteet, ohjelmistot ja niiden versiot), jotta testausympäristö voidaan pystyttää uudelleen samassa kokoonpanossa. Tämän jälkeen tulee määritellä testitapaukset, joissa kuvataan vaiheet kera läpikäytävien tietojen ja toimintojen.
Testaussuunnitelmassa saattaa olla järkevä myös kuvata mm. sovelluksen tukemat eri syöttö- ja tulostusformaatit, käyttöliittymissä vältettävien virheiden ennakointia sekä erilaisten erikoistapausten käsittelyä. Lisäksi tulee mainita, mistä tarvittava testidata saadaan tai miten se luodaan. Erityisesti tulee huomioida, että ohjelmaosiot tulee testata ensin erillään, jonka jälkeen ne testataan yhdistettynä osaksi isompaa kokonaisuutta. Testaus- tai projektisuunnitelmassa tulee lisäksi mainita, ketkä minkäkin testaustehtävän suorittavat.
Tilaajan vaatimuksesta sovellukselle toteutetaan joissakin projekteissa muitakin määrittely- ja suunnitteludokumentteja, joiden sisältö on vähintään yksityiskohdiltaan tilaajakohtainen. Luokkamäärittelyssä esitellään sovelluksen sisältämien komponenttien luokkarakenne luokkakaavioiden avulla. Tietokantasuunnitelmassa kuvataan tietokannan taulut sekä niiden kentät ja suhteet. Se voi olla oma dokumenttinsa tai se voi muodostaa luokkamäärittelyn kanssa arkkitehtuurisuunnitelman. Käyttöliittymämäärittelyssä kuvataan käyttöliittymän yleiset toiminnot, näyttöjen sisällöt kuvina sekä näyttöjen suhteet näyttökartan avulla.
Projektin lopussa tulee raportoida sekä projektin että sovelluksen toteutuma. Nämä osiot on järkevä jakaa vähintään kahdeksi dokumentiksi. Jotkut tilaajat vaativat oman dokumenttipohjansa käyttöä sovelluksen ominaisuuksien, toiminnan ja rakenteen raportointiin. Kyseisissä raporteissa tulee esittää selkeästi toteuma ja tehdyt muutokset suunnitteludokumentteihin verrattuna. Jos suunnitteludokumentit on järkevästi laadittu, niitä vastaavat raportit voidaan laatia suoraan suunnitelmien pohjalta.
Projektiraportin tulee sisältää ainakin seuraavat tiedot:
Sovellusraportissa tulee käsitellä ainakin seuraavia asioita:
Sovelluksen rakenteen ja ''sisäisen'' toiminnan kuvaamisen yhteydessä suositellaan kuvien käyttöä, jolloin kyseiset asiat ovat kokonaisuutena paremmin lukijan hahmotettavissa. Ohjelman yksityiskohtien kuvaaminen on sen sijaan yleensä järkevämpää sijoittaa ohjelmakoodiin kommentteina. Joillekin ohjelmointikielille löytyy myös lähdekoodin ja sen sisältämien kommenttien perusteella luokkadokumentit muodostavia ohjelmia (kuten Javadoc).
Selkeä käyttöohje ottaa huomioon eri käyttäjäryhmät, joille ohjelma on suunnattu. Älä unohda esimerkkejä sekä varoituksia tilanteista, joissa ohjelma saattaa toimia epäloogisesti tai kaatua. Vaikka käyttöohje on lähinnä tarkoitettu sovelluksen käyttäjille, tulee projektikansioon sisällyttää ohjeet myös sovelluksen ylläpitäjiä ja jatkokehittäjiä varten.
Dokumentteihin tulee sisällyttää asennusohje tai asennusohjelma sekä käännösohje (esim. makefile). Ohjelmat tulee kääntää maksimivaroituksilla ja kaikki jäljelle jäävät varoitukset on kuvattava dokumentissa. Tällöin kyseistä ohjelmaa myöhemmin kääntävä henkilö on tietoinen odotettavista varoituksista ainakin mainitussa sovelluskehitysympäristön versiossa.
Ohjelmalistaukset kommentteineen liitetään projektikansioon kaksipuolisesti paperille tulostettuina ja CD:llä. Varmistakaa viimeistään ennen listausten tulostamista, etteivät koodirivinne pituudet ylitä paperinleveyttä.
Ohjelmalistauksen sivut tulee olla numeroituna ja tiedoston nimi kunkin sivun yläreunassa. Kunkin lähdekooditiedoston alkuun tulee sijoittaa sisällysluettelo (aliohjelmista), tekijöiden nimet, päiväys ja mahdollisesti myös versionumero.
Monesti lähdekooditiedoston alussa on lisäksi järkevää listata oleellisimmat tehdyt lisäykset ja muutokset. Tällöin virheiden jäljittäminen toimivaan ohjelmaan tehtyjen muutosten ja lisäysten jälkeen on helpompaa, koska virheet todennäköisesti löytyvät viimeksimuokatuista kohdista. Lisäksi kunkin ohjelmatiedoston alkuun tulee tällä tavoin tallennettua ohjelmaosion kehityshistoriaa.
Kukin projektin jäsen pitää kirjaa projektiin käyttämästään ajasta. Päivittäisten työtuntien ja tuntimäärien lisäksi tulee kuvata tehtyjä töitä. Lisäksi senhetkinen yhteenlaskettu tuntimäärä tulee olla nähtävissä. Koulutuksiin, väliesittelyihin sekä dokumenttien rakenteen ja kirjoitusasun muokkaukseen käytetyt työtunnit tulee kirjata oheiskurssille. Muut työtunnit kirjataan projektille.
Tehtyjä töitä toivotaan kuvattavan useammalla sanalla siten, että työkohteet ja kohdatut ongelmat tulevat selkeästi esiin. Tällä tavoin projektin eteneminen ja mahdolliset ongelmat tulee kirjattua ns. organisaatiomuistin kertymistä varten. Työt tulee luokitella, jolloin projektin lopussa on helpompi havaita kokonaistyömäärän jakautuminen mm. määrittelyyn, suunnitteluun, ohjelmointiin, dokumentointiin, testaukseen ja projektihallintaan sekä tutustumiseen, kokouksiin, esityksiin, luentoihin ja perehdytyksiin.
Ajankäyttöraportti on esitettävä ilman erillistä pyyntöä ohjaajille ja tilaajan edustajille kunkin projektipalaverin alussa. Sitä voi käyttää muistilistana sisältäen tietoa suoritetuista ja suorittamattomista tehtävistä. Tosin tähän tarkoitukseen kannattanee käyttää mieluummin BugZillaa tai jotain muuta virheiden ja/tai tehtävien hallintaan toteutettua sovellusta.
Sovellusprojektit kokoontuvat viikottaisten ryhmäkohtaisten palaverien lisäksi aloitusluennolle, ohjelmistotuotantoa, käyttöliittymää ja tekijänoikeuksia käsitteleville luennoille, mahdollisiin perehdytystilaisuuksiin sekä kolmeen esittelytilaisuuteen.
Projektin jäsenet tapaavat ohjaajat ja tilaajan edustajat säännöllisesti vähintään kerran viikossa järjestettävässä projektipalaverissa. Ohjaajat ja tilaajan edustajat tarkastavat ja hyväksyvät edellisen palaverin pöytäkirjan ja ryhmän jäsenten ajankäyttöraportit seuraavassa palaverissa, joten projektiryhmän tulee esittää ne ilman erillistä pyyntöä heti palaverin alussa.
Ryhmästä vähintään yhden opiskelijan tulee toimia sihteerinä kirjaten palaverissa käsitellyt asiat ja tehdyt päätökset. Näiden muistiinpanojen perusteella ryhmän tulee laatia palaveripöytäkirja, josta jäsenet, ohjaajat ja tilaajan edustajat saavat nopeasti käsityksen edellisessä palaverissa käsitellyistä ja sovituista asioista. Palaveripöytäkirjat tulee laatia huolellisesti ja kattavasti, sillä mahdollisissa ristiriitatilanteissa sovitut asiat tulee pystyä tarkistamaan pöytäkirjasta.
Palavereissa yleisesti käsitellyt asiat ovat seuraavat:
Asioiden hahmotteleminen paperille tai valkotaululle voi olla hyvä tapa saada aivot askaroimaan tehtävän tai pulman parissa. Etenkin siitä on hyötyä työn etenemistä mahdollisesti haittaavien ongelmien ja oleellisten kysymysten keksimisessä. Mieleen nousevat ns. tyhmät kysymykset kannattaa aina esittää, sillä epäselviksi jääneet asiat saattavat johtaa projektia väärään suuntaan ja viivästyttää sitä aivan turhaan. Kysymyksiin saa yleensä välittömästi vastauksen tilaajan edustajilta tai ohjaajilta.
Jotta palaveri sujuisi nopeasti ja tärkeimmät käsiteltävät asiat olisivat jo palaverin alussa kaikkien osallistujien tiedossa, projektiryhmän tulee laatia palaverille esityslista. Siinä tulisi mielellään olla osoitteet tai linkit palaverissa käsiteltäviin dokumentteihin, ohjelmaosioihin ja materiaaleihin. Esityslista kannattaa lähettää sähköpostitse kaikille projektiorganisaation jäsenille ja muillekin kyseiseen palaveriin osallistuville vähintään vuorokautta ennen palaveria.
Käsiteltävät asiat kannattaa esityslistassa järjestää siten, että ensin käsitellään projektiin liittyvät asiat, sovelluksen vaatimukset ja rajaukset sekä viimeiseksi sovelluksen toteutustekniset yksityiskohdat. Jos palaverissa ei tulla käsittelemään tilaajaa koskevia asioita, asiasta tulee mainita esityslistassa, jolloin he voivat halutessaan jäädä pois palaverista. Kaikki tilaajien edustajat eivät nimittäin halua, ehdi tai pysty puuttumaan sovelluksen toteutusratkaisuihin, jolloin he ovat kiitollisia mahdollisuudesta käyttää kyseinen aika muihin tehtäviinsä.
Käsitellyt asiat ja tehdyt päätökset kirjataan siis pöytäkirjoihin. Pöytäkirja tulee loogisesti jakaa useammaksi sopivan lyhyeksi kohdaksi, jolloin kohtien otsikoiden perusteella saa nopeasti tiivistetyn käsityksen palaverissa käsitellyistä asioista. Pöytäkirjojen kohdat kannattaa jakaa melko lyhyiksi tekstikappaleiksi, jolloin niissä käsitelty asia on helpommin hahmotettavissa. Jos jokin kohta tuntuu liian pitkältä, sen voi tarvittaessa jakaa loogisiin alakohtiin.
Tehdyt päätökset tulee selkeästi korostaa käsitellyistä asioista. Kaikkiin kohtiin ei välttämättä päätöstä liity, sillä monesta asiasta palavereissa vain keskustellaan tai tiedotetaan ilman selkeää päätöstä. Päätöksiä kannattaa korostaa esimerkiksi sijoittamalla ne kunkin kohdan loppuun kera Päätökset-sanan. Jos pöytäkirjaan on liitetty liite, jossain pöytäkirjan kohdassa tulisi viitata kyseiseen liitteeseen.
Kullekin palaveriin osallistuneelle sovitut tehtävät tulee kirjata listana pöytäkirjan loppuun omaksi kohdakseen. Myös tilaajan edustajien sekä vastaavan ja teknisten ohjaajien tehtävät tulee kirjata esille. Em. tehtävien sijoituksella ne tulevat kaikille palaveriin osallistuneille selkeämmin esille ja niiden suoritus voidaan nopeasti tarkistaa kunkin palaverin aluksi. Tehtäviä on nimittäin huomattavasti hankalampi löytää yksittäisistä kohdista.
Kirjattaviin asioihin kuuluvat aina myös paikallaolijat, puheenjohtaja, sihteeri (pöytäkirjan laatija), paikka ja aika sekä seuraavan palaverin paikka ja aika (katso luvun 5.1 lista). Pöytäkirjoihin voi erilliseen kohtaan liittää niitä kirjoitettaessa mieleentulevia kysymyksiä, jolloin ne ovat valmiina seuraavaa palaveria varten.
Palaveripöytäkirja on helpointa kirjoittaa heti palaverin jälkeen, jolloin käsitellyt asiat ovat hyvin vielä mielessä. Palaveripöytäkirjat kannattaa lähettää projektin sähköpostilistan kautta kaikille projektiorganisaation jäsenille ja muille palaveriin osallistuneille välittömästi niiden valmistuttua. Tällöin tilaajan edustajat ja ohjaajat voivat tarkastaa kirjatut asiat ja päätökset tuoreeltaan. Lisäksi he pääsevät ennakolta valmistelemaan vastauksia mahdollisiin pöytäkirjassa esitettyihin kysymyksiin. Pöytäkirjaa ei mielellään tulisi toimittaa liitetiedostona, vaan ASCII-muodossa osana sähköpostia tai ilmoittamalla sen URL-osoitteen. Kaikilla ei nimittäin ole välttämättä tarvittavaa tiedostomuotoa tukevaa ohjelmaa tai tiedoston avaaminen vaatii ylimääräisiä toimenpiteitä.
Kokoukset ja palaverit lienevät suurelle osalle projektin jäsenistä uusi kokemus ja lisäksi niissä tulee yleensä runsaasti uutta asiaa. Lienee siis syytä mainita muutama huomioitava asia.
Projektin alussa tulee sille keksiä akronyymi eli lyhyt ja ytimekäs nimi. Akronyymin mukainen sähköpostilista luodaan projektiryhmän, ohjaajien ja toimeksiantajan edustajien väliseen tiedotukseen. Projektin tiedotusvastuu siirtyy ensimmäisen projektipalaverin yhteydessä opiskelijaryhmälle.
Ryhmän jäsenten kannattaa laatia ensimmäiset palaveripöytäkirjat yhdessä, sillä kaikille projektin jäsenille on todennäköisesti pienen tietotulvan alta jäänyt mieleen eri asioita. Kaikkien projektipalaveriin osallistuvien nimet, työnimikkeet ja yhteystiedot tulee kirjata pöytäkirjaan. Jos jonkun henkilön nimi ei tule esille tai unohtuu, sitä tulee kysyä.
Ensimmäisessä palaverissa tilaajat kuvaavat aiheen lisäksi yleensä myös kyseisen projektin aihealuetta ja taustoja sekä aiheeseen liittyviä käyttäjien ja järjestelmien prosesseja. Samoja taustoja vaaditaan esiteltävän myös projektisuunnitelmassa. Jos taustat on jo kirjattu pöytäkirjoihin, ne on helppo siirtää osaksi suunnitteludokumentteja.
Muita huomioitavia asioita ensimmäisissä palavereissa (ja siten myös pöytäkirjoissa) ovat tilaajien, ohjaajien ja ryhmän jäsenten käyttämät ''uudet'' termit. Epäselviksi jääneiden termien merkitys tulee selvittää viimeistään seuraavassa palaverissa. Ne tulee kirjata pöytäkirjaan sekä projektisuunnitelmaan.
Ensimmäisissä projektipalavereissä sovellukselle asetettavien vaatimusten lisäksi monesti kuvataan muitakin mahdollisia sovellukseen toivottavia ominaisuuksia. Tällöin tilaajan, mutta toisinaan myös ohjaajien ja ryhmän jäsenten, puolelta voi sadella ideoita runsaasti, joten niistä joudutaan rajaamaan projektiin sisällytettävät asiat. Projektin tehtävät tuleekin (ainakin alustavasti) selkeästi sopia kunkin palaverin lopussa sekä kirjata tarkasti pöytäkirjaan sovitut mukaanliitettävät ja ulkopuolelle rajattavat sovelluksen ominaisuudet ja projektin tehtävät.
Ensimmäisessä projektipalaverissa käsitellään yleensä ainakin seuraavat asiat:
Viimeisissä projektipalavereissa käsitellään projektin päättämiseen ja mahdolliseen jatkokehittämiseen liittyviä asioita. Vähintään kuukautta ennen projektin oletettua päättymistä projektiryhmän tulee alkaa esittelemään valmistuneiden, keskenolevien ja aloittamattomien tehtävien tilanne. Tällöin projektin tilaajan edustajat ja ohjaajat pystyvät tarvittaessa rajaamaan vaatimuksia toteutettavan sovelluksen, dokumenttien ja muiden tulosten osalta.
Oleellisia viimeisissä palavereissa käsiteltäviä asioita ovat mm. seuraavat:
Projektiryhmät kokoontuvat loppuesittelyn lisäksi kahteen yhteiseen väliesittelyyn. Esittelytilaisuuksissa kullakin ryhmällä on noin 15 minuuttia aikaa kuvata aihettaan ja sovellustaan. Esittelymateriaali tulee etukäteen hyväksyttää tilaajan edustajilla erityisesti salaisten projektien tapauksessa.
Väliesittelyissä projektin jäsenet arvioivat muiden ryhmien esitystä, aiheita, sovellusten käyttöliittymiä sekä jonkin verran myös ohjelmien toteutusta. Esittelyistä tulee laatia pöytäkirjat lähinnä oman ryhmän esityksen sisällön, sujumisen ja kysymysten sekä saadun suullisen ja kirjallisen palautteen pohjalta.
Ensimmäisessä esittelyssä verrataan laadittuja suunnitelmia ja arvioidaan niiden toteuttamismahdollisuuksia. Ensimmäisessä esittelyssä pyritään keskustelun kautta saamaan uusia ideoita ryhmille. Ryhmälle saattaa syntyä ideoita mm. tavoista kehittää omaa työtään.
Toinen esittely on pari viikkoa ennen loppuesittelyä, jolloin sovelluksiin voidaan vielä tehdä pieniä korjauksia ja muutoksia. Toisessa esittelytilaisuudessa muiden projektien jäsenten on melko helppo kommentoida ainakin sovellusten käyttöliittymiä.
Projektiryhmän jäsenet perustelevat ja kuvaavat työtään esittelyissä, joten he joutuvat tarkastelemaan toimintaansa muilta näkökannoilta. Perustelut ja kuvaukset vaikuttavat myös projektin dokumentointiin, sillä ryhmä joutuu esittelemään aihetta sekä muokkaamaan sanottavansa mahdollisimman yksinkertaiseen ja ymmärrettävään muotoon.
Keskustelun ja perustelemisen voidaan katsoa olevan taitoja, joita yliopisto-opiskelun tulisi kannustaa ja parantaa. Molempien väliesittelyjen kautta esiintyminen yleisölle tulee ryhmän jäsenille tutummaksi, jolloin loppuesittely ja muutkin myöhemmät esitelmät sujunevat rutiinilla luontevammin. Esittelyissä huomioitavia asioita on käsitelty enemmän luvussa 5.6.
Sovellusprojektin loppuesittely on tärkeä osa projektin onnistumista. Se on projektin mainostilaisuus, jossa yleisönä on muiden projektiryhmien, tilaajien edustajien ja ohjaajien lisäksi mm. laitoksen henkilökuntaa ja opiskelijoita.
Loppuesittelyyn kuuluvat
Kullekin projektille varataan korkeintaan 20 minuuttia aikaa projektinsa esittelyyn, jottei yleisö pitkästyisi usean projektin esittelyssä. Tämän lisäksi yleisöllä on kymmenisen minuuttia aikaa esittää kysymyksiä ja kommentteja. Kyseiset 20 minuuttia kuluvat yllättävän nopeasti, joten esitys tulee suunnitella ja harjoitella etukäteen. Älkää missään tapauksessa ylittäkö teille varattua aikaa, sillä tuolloin myöhemmin esiteltävien ryhmien aiheille jää vastaavasti vähemmän aikaa.
Loppuesittelyssä tulee kiinnittää huomiota ainakin seuraaviin seikkoihin:
Sovellusprojekti voidaan katsoa hyväksytyksi ja päättyneeksi, kun ohjaajat ja tilaajan edustajat ovat hyväksyneet sekä toteutetun sovelluksen että dokumentit. Käytännössä projektin jäsenet voivat katsoa projektin päättyneeksi saadessaan arvosanat.
Vastaavien ohjaajien arvostelussaan huomioimat asiat on esitetty muistilistana osoitteesta http://www.mit.jyu.fi/palvelut/sovellusprojektit/ohjaajat/projektiarviointi.pdf löytyvästä pdf-dokumentista. Tiivistäen Sovellusprojektin arvosteluun vaikuttavat
Ainoana arvosteluperusteena ei siis ole pelkästään sovelluksen toteutus (kuten kurssien harjoitustöissä), vaan arvostelijat kiinnittävät erityistä huomiota projektin läpivientiin ja valmistumiseen suunnitellussa aikataulussa sekä ryhmän toimintaan! Sovellusprojektin arvostelee sen vastaava ohjaaja, mutta hän ottaa arvostelussaan huomioon tilaajan edustajien ja teknisten ohjaajien mielipiteet.
Sovellusprojekteissa käytetään seuraavia karkeita arvostelutasoja (asteikko 1-5):
1-taso Sovellus toimii ja toteuttaa asetetut tavoitteet "rimaa hipoen". Dokumentointi ja loppuesittely ovat tyydyttäviä. Projektin läpiviennissä on ollut huomautettavaa. Tiedonkulussa ryhmän sisällä tai ulospäin tilaajalle ja ohjaajille on ollut puutteita. Projektin valmistuminen on viivästynyt. 3-taso Sovellus toimii hyvin sekä työ on dokumentoitu ja esitelty selkeästi. "On siis tehty kaikki, mitä on käsketty, muttei sen enempää". Projektin läpiviennissä ei ole ollut huomautettavaa. Tiedonkulussa ryhmän sisällä sekä ulospäin tilaajalle ja ohjaajille ei ole ollut huomauttamista. Projekti on valmistunut likimain ajallaan. 5-taso Edellisen kohdan lisäksi mukana on omia innovaatioita, asenne työhön on innostunut tyyliin "vaikeudet on tehty voitettaviksi" sekä lopputulos ylittää tavoitteet. Projekti on läpiviety hallitusti ja ryhmätyö on sujunut hyvin. Tiedonkulku ryhmän sisällä sekä ulospäin tilaajalle ja ohjaajille on toiminut erinomaisesti. Projekti on valmistunut sovitussa aikataulussa.
Projektille annetaan ryhmäkohtainen arvosana, joka kuvaa ryhmän toimintaa, projektin läpivientiä ja tuloksia kokonaisuutena. Tämän lisäksi kullekin projektin jäsenelle annetaan henkilökohtainen arvosana, joka kuvaa ryhmäkohtaisen arvosanan lisäksi kyseisen projektin jäsenen henkilökohtaista panosta projektiin. Panoksella ei tarkoiteta pelkästään projektin eteen tehtyjä työtunteja, vaan myös kyseisen henkilön aktiivista osallistumista projektiin, tehtävien vaativuutta ja oppimiskykyä projektin aikana. Opintosuoritusrekisteriin merkitään projektin jäsenen henkilökohtainen arvosana.
Sovellusprojekteiksi ehdotettujen aiheiden vaativuutta ja työmäärää on etukäteen hankala arvioida johtuen aihealueiden ja työkalujen runsaasta kirjosta sekä projektin jäsenten, ohjaajien ja tilaajan edustajien kokemustaustojen eroavaisuuksista. Tästä johtuen Sovellusprojektien laajuuden arvioinnissa on käytössä 10-15 opintopisteen vaihteluväli (5-8 opintoviikkoa). On huomattava, etteivät tehdyt työtunnit suoraan määritä annettavia opintoviikkoja, vaan niitä tarkastellaan mm. työn vaativuuteen rinnastettuina. Kunkin projektiryhmän sisällä kaikki saavat saman opintopistemäärän ''laiskimman'' jäsenen työn mukaan.
Sovellusprojektin tilaajan edustaja ja vastaava ohjaaja laativat projektista lausunnot, jotka liitetään projektikansioon. Lisäksi tilaajan edustaja tai vastaava ohjaaja kirjoittaa pyynnöstä projektin jäsenille projektitodistukset.
Kunkin ryhmän jäsenen tulee toimittaa viimeistään lopullisen dokumentoinnin palautuksen yhteydessä vastaavalle ohjaajalle projektistaan ns. itsearviointi. Siihen tulee liittää oma arvio (1-5) koko projektin ansaitsemasta arvosanasta sekä omasta arvosanastaan. Myös lyhyet perustelut arvosanoille ovat toivottavia. Tätä kautta ryhmän jäsenet joutuvat arvioimaan omaa työtään, kuten yleisesti nykyisin työelämässäkin joutuu tekemään.
Projektin jäsenten toivotaan antavan kyseisessä (tai erillisessä) arvioinnissa arvosanat perusteluineen myös vastaavan ohjaajan, teknisten ohjaajien, tilaajan edustajien ja ATK-tuen toiminnalle. Lisäksi projektien luennoista ja perehdyttämistilaisuuksista toivotaan palautetta viimeistään itsearvioinnissa.
Itsearviointiin tulee kirjata myös tieto siitä, saako itsearvioinnin liittää projektikansioon vai ei. Jos kyseinen maininta uupuu, vastaava ohjaaja tulkitsee sen luvaksi sijoittaa itsearviointi projektikansioon julkisesti nähtäville.
Vastaava ohjaaja avaa projektin jäsenten toimittamat itsearvionnit vasta, kun hän on antanut arvosanat projektille ja sen jäsenille. Kyseisellä kaksinkertaisella arvioinnilla vastaava ohjaaja pystyy paremmin arvioimaan arvostelunsa oikeellisuutta ja oikeudenmukaisuutta.
Sovellusprojektien päättyessä on yleensä melkoisesti muistettavaa ja lisäksi kiire ansaitulle lomalle. Seuraavan muistilistan avulla oleellisimmat projektin päättämiseen liittyvät käytännön työt tullee hoidettua:
Sovellusprojektin päätyttyäkin projektin jäsenille voidaan katsoa jäävän vastuuta toteutetusta sovelluksesta. Mitään automaattista sitoutuneisuutta sovelluksen ylläpitoon tai jatkokehitykseen ei tietenkään vaadita.
Käytännössä Sovellusprojektien yhteydessä ei yleensä ehditä testata toteutettua sovellusta kovinkaan kattavasti. Tällöin mahdollinen jatkokehitys voidaan toteuttaa muiden opintojaksojen tai/ja palkallisen työn puitteissa. Projekteilla on siis ollut hyvä (tai huono) tapa jatkua jossain muodossa myös projektin jälkeen, mutta tällöin projektin jäsenten sitoutuneisuudesta jatkokehitykseen sovitaan aina erikseen.
Jotta projektien jäsenet tuntisivat projektin todella olevan mennyttä elämää, järjestetään pari kuukautta projektien päättymisen jälkeen projektien päättötilaisuus. Kyseisessä saunaillassa voidaan hyvän ruuan ja juoman kera tarkastella taaksejäänyttä aikaa. Tällöin projektien jäsenten saattaa olla helpompaa antaa projektia, tilaajaa, ohjaajia ja ATK-tukea koskevaa omakohtaista kritiikkiä, kiitoksia ja kehitysideoita.
Ohjeessa annetaan neuvoja Jyväskylän yliopiston tietotekniikan laitoksella järjestettävien Sovellusprojektien menestykselliseen läpiviemiseen. Ohjeet kattavat projektin eri vaiheiden ja kokoontumisten kuvauksien lisäksi neuvoja sovelluksen toteuttamiseen sekä erilaisten projektiin liittyvien dokumenttien sisältöjen vaatimusten esittelyn. Ohjeiden laadinnassa on huomioitu aiemmista projekteista saatuja kokemuksia.
Sovellusprojekteihin liittyvistä asioista voi kysyä lisätietoa projektien vastaavilta ohjaajilta. Kritiikki, kiitokset ja kommentit sekä positiiviset ja negatiiviset kokemukset otetaan mielellään vastaan, jolloin niitä voidaan hyödyntää projektien kehittämisessä.
Sovellusprojektien aihe-ehdotuksia voi esittää vastaaville ohjaajille milloin tahansa. Syyslukukaudeksi ehdotettavien aiheiden tulee kuitenkin olla heidän tiedossaan elokuun loppuun mennessä ja kevätlukukaudeksi ehdotettavien vuoden loppuun mennessä. Projektit alkavat syksyn osalta syyskuun puolessa välissä ja keväällä helmikuun alussa.
Lopuksi haluan kiittää Kaisa Miettistä ja Marko Mäkelää vuoden 1995 projektiohjeesta, josta tämä ohje on vuosien varrella jalostunut. Lisäksi Tapani Tarvainen, Kari Kärkkäinen ja Vesa Korhonen ansaitsevat kiitokset erinomaisista ohjetta kehittäneistä lisäyksistä.
Haikala Ilkka ja Märijärvi Jukka, ''Ohjelmistotuotanto'', Suomen ATK-kustannus, 2000.
Heinonen Petri, ''Lyhyt kirjoittamisopas teknisestä näkökulmasta'', saatavilla HTML-muodossa <URL: http://appro.mit.jyu.fi/doc/kirjoitusopas/>, Jyväskylän yliopisto, Tietotekniikan laitos, 23.2.2001.
Heinonen Petri, ''Tekstinkäsittely'', saatavilla HTML-muodossa <URL: http://appro.mit.jyu.fi/doc/tekstinkasittely/>, Jyväskylän yliopisto, Tietotekniikan laitos, 5.2.2002.
Hirvonen Esko, Tekijänoikeus, Sähkö ja tele, 68 (1995), sivut 20-23.
Järvinen Pekka, ''Onnistu esimiehenä'', WSOY, 2001.
Karlsson Åke ja Marttala Anders, ''Projektikirja - Onnistuneen projektin toteuttaminen'', Kauppakaari, 2001.
Korpela Jukka, ''Tekijänoikeus: vastauksia usein esitettyihin kysymyksiin'', saatavilla WWW-muodossa <URL: http://www.cs.tut.fi/~jkorpela/tekoik/tekoik.html>, Tampereen teknillinen yliopisto, Tietotekniikan osasto, 8.11.2002.
Paakki Jukka, ''Ohjelmistotekniikka'', kurssimoniste, Jyväskylän yliopisto, tietojenkäsittelytieteiden laitos, 1996.
Pressman Roger S., ''Software Engineering: A Practitioner's Approach'', McGraw-Hill, 2001.
Ruuska Kai, ''Projekti hallintaan'', Suomen ATK-kustannus, Jyväskylä, 1999.
Saarinen Mikael, ''Tunne älysi - älyä tuntevasi : opas oman ja työyhteisön tunneälyn kehittämiseen'', WSOY, 2001,
Santanen Jukka-Pekka, ''Ohjelmistotuotanto ja projektityö'', luentomateriaali, Jyväskylän yliopisto, tietotekniikan laitos, 1997.
Santanen Jukka-Pekka, ''Opinnäytteiden kirjoittaminen, lyhyt oppimäärä'', saatavilla WWW-muodossa <URL: http://www.mit.jyu.fi/santanen/info/kirjoittamisesta.html>, Jyväskylän yliopisto, tietotekniikan laitos, 23.8.2000.
Santanen Jukka-Pekka, ''Vaitiolosopimusmalli'', saatavilla HTML-muodossa <URL: http://www.mit.jyu.fi/palvelut/sovellusprojektit/vaitiolo.html>, Jyväskylän yliopisto, tietotekniikan laitos, 3.2.2006.
Santanen Jukka-Pekka, ''Projektisopimusmalli'', saatavilla HTML-muodossa <URL: http://www.mit.jyu.fi/palvelut/sovellusprojektit/sopimus.html>, Jyväskylän yliopisto, tietotekniikan laitos, 16.3.2006.
Sommerville Ian, ''Software Engineering'', 6th Edition, Addison-Wesley, 2000.
Tekijänoikeuksia ja aineettomia oikeuksia käsittelevää materiaalia löytyy myös URL-osoitteen http://www.mit.jyu.fi/santanen/ohjeita.html#oikeudet kautta.