581260-4 Ohjelmistotuotantoprojekti:
projektityöohje

0. Yleistä

Vaikka eri ryhmien konkreettiset aiheet ovatkin erilaiset, on kaikissa ohjelmistoprojekteissa paljon yhteistä: Projektityöhön, tuotantoprosessiin ja dokumentointiin liittyvät ongelmat, tehtävät ja vakiintuneet käytännöt ovat useimmiten varsin yleisiä soveltuen siten minkä tahansa ohjelmistoprojektin pohjaksi. Tässä ohjeessa annetaan yleiset toimintaperiaatteet, joita tulee soveltaen noudattaa laitoksen kaikissa ohjelmistotuotantoprojekteissa. Ohje on vain suppea tiivistelmä ohjelmistotuotannon joistakin hyvistä periaatteista, joita kaikkia tulee tietenkin noudattaa jokaisessa projektiryhmässä. Tarkempaa tietoa tästä vakiintuneesta "kansanperinteestä" löytyy kurssin Ohjelmistotuotanto (cl, 4 ov) materiaalista, joka perustuu mm. seuraaviin lähteisiin:

• Ilkka Haikala, Jukka Märijärvi: Ohjelmistotuotanto, 3. painos. Suomen Atk-kustannus, 1997.
• Roger S. Pressman: Software Engineering - A Practitioner's Approach, 3rd ed. McGraw-Hill, 1992.
• Ian Sommerville: Software Engineering, 4th ed. Addison-Wesley, 1992.
• Heikki Stenlund: Projektijohtamisen perusteet. Edita, 1996.
• Kai Koskimies: Pieni oliokirja. Suomen Atk-kustannus, 1997.
• Ohjelmistotuotannon luentomateriaali. Mappi huoneessa A 412.

1. Projektin aloittaminen

1. Eri henkilöiden roolit projektissa. Jokaisella työllä on ns. valvoja, joka projektin kannalta on asiakkaan roolissa: hän on tilannut projektiryhmältä jonkin tuotteen. Ryhmän on pyrittävä toteuttamaan asiakkaan toiveet parhaan kykynsä mukaan, ja epäselvissä tilanteissa ("ei tiedetä, mitä asiakas haluaa") on käännyttävä asiakkaan puoleen. Mikäli tuotteesta tehdään aluksi prototyyppi (esimerkiksi käyttöliittymästä), on se esitettävä asiakkaalle oikean suunnan varmistamiseksi. Ryhmän ohjaaja puolestaan on lähinnä (a) asiakkaan edustaja, (b) tekninen asiantuntija ja (c) laadun varmistaja. Ohjaaja siis avustaa kaikin tavoin projektiryhmää hallinnollisissa, ohjelmistoteknisissä ja aiheeseen liittyvissä ongelmissa, mutta hän ei osallistu varsinaiseen tuottavaan työhön.
2. Työskentelykäytännöt. Projektityöhön liittyy kolmentyyppisiä kokouksia. Mikäli yhteiseen kokoukseen ei kulu koko sille varattua 3-4 tuntia, ei ole tietenkään järkevää istua loppuaikaa toimettomana. Aika on käytettävä hyödyllisesti projektin edistämiseen, vaikkapa tausta-aineistoon tutustumiseen tai ohjelmointiin. Ohjaaja on käytettävissä koko varatun ajan, mikä ei kuitenkaan tarkoita sitä, että ryhmän olisi oltava koko ajan koolla samassa huoneessa.

   (a) Suunnittelu- ja ideointipalavereissa suunnitellaan ryhmän yhteistyönä tuotteen jotakin osaa, sen valmistamista tai dokumentointia niin pitkälle, että tehtävä voidaan antaa joillekin ryhmän jäsenille suoritettavaksi. Palaveriin voi liittyä myös käsiteltävään aiheeseen liittyviä esitelmiä tai tehtyjen esiselvitysten raportointia. Tällaiset epämuodolliset palaverit saattavat kestää hyvinkin kauan, jopa koko ryhmän yhteisen kokoontumisajan.

   (b) Seurantakokouksissa tarkistetaan projektin eteneminen vertaamalla sitä projektisuunnitelmaan. Kokouksella on ennalta sovittu esityslista, ja siinä pidetään pöytäkirjaa (malli: liite B). Kokouksilla on puheenjohtaja ja sihteeri. Puheenjohtajan tarkastamat ja allekirjoittamat pöytäkirjat jaetaan kaikille ryhmän jäsenille ja ohjaajalle, ja ne käydään läpi aina seuraavassa seurantakokouksessa. Yleensä projektipäällikkö toimii puheenjohtajana ja sihteerin tehtävä on kiertävä, mutta ryhmässä voidaan sopia muunkinlaisesta käytännöstä. Seurantakokoukset ovat lyhyitä ja ytimekkäitä (enintään 1 tunti). Peukalosääntö: ellei jokin asia selviä 5 minuutissa, tarkempi selvitys annetaan jonkun tehtäväksi. Seurantakokouksia pidetään säännöllisesti, vähintään joka toinen viikko.

   (c) Tarkastuksissa (inspection) tarkistetaan systemaattisella tavalla jonkin ohjelmistotuotteen tai sitä kuvaavan dokumentin laatu. Osanottajat perehtyvät kohteeseen tarkasti ennen tarkastustilaisuutta. (Huom! Siis kaikki osanottajat perehtyvät.) Tarkastustilaisuuteen nimetään etukäteen puheenjohtaja (ryhmän ohjaaja), sihteeri, asiantuntija (tarkastettavan tuotteen tekijä) ja alustaja (eri henkilö kuin asiantuntija). Ryhmä käy alustajan ohjaamana läpi tarkastettavan tuotteen etsien siitä mahdollisia virheitä, jotka sihteeri kirjaa tarkastuspöytäkirjaan (malli: liite J). Asiantuntija selittää mahdolliset tekniset yksityiskohdat, joista muu tarkastusryhmä ei saa selvää. Tarkastaminen on keskittynyttä työskentelyä, jonka kestoksi suositellaan 1-2 tuntia. Löydettyjä virheitä ei korjata tarkastustilaisuudessa, vaan tarkastetun tuotteen tekijä tekee tarvittavat korjaukset sen jälkeen ja hyväksyttää korjauksensa puheenjohtajalla (so. ryhmän ohjaajalla).

3. Kommunikointitavat. Projektin läpivienti vaatii jokaiselta ryhmän jäseneltä enemmän työaikaa kuin siihen muodollisesti varatut 6-8 tuntia viikossa. Ryhmän on sovittava, millä tavoin kommunikointi hoidetaan yhteisten tapaamisten ulkopuolella. Kommunikointiin liittyvät myös pöytäkirjojen yms. jakelu sekä projektimateriaalin säilytys. Sähköpostilista on eräs käyttökelpoinen projektin sisäinen kommunikointikanava. Erityisen tärkeää on sopia siitä, miten poissaoloista ja myöhästymisistä ilmoitetaan muulle ryhmälle ja ohjaajalle.
4. Projektipäällikkyys. Jokaisessa projektissa on projektipäällikkö, joka pääasiassa vastaa projektin etenemisestä yhteisesti suunnitellussa ja sovitussa aikataulussa. Projektipäällikkö toimii myös linkkinä asiakkaan ja tuottajan välillä, joten yhteydenpito asiakkaaseen kanavoidaan projektipäällikön kautta. Projektipäällikkö päättää ryhmän sisäisestä tehtävänjaosta, huolehtii projektin tarvitsemien resurssien hankkimisesta ja organisoi mahdollisesti puuttuvan tiedon hankkimisen. Koska projektipäällikkö on myös projektiryhmän jäsen, hänet valitaan opiskelijajäsenten joukosta. Näin ollen ohjaaja ei ole projektipäällikkö. [Ohjaaja kuitenkin avustaa projektipäällikköä em. tehtävien hoitamisessa.] Projektipäällikkyys voi olla kiinteästi samalla henkilöllä koko projektin ajan, tai tehtävä voi kiertää ryhmän sisällä sen sopivaksi katsomalla tavalla.

Projektisuunnitelma annetaan asiakkaille ja laitoksen ohjelmistotuotantoprojektien vastuuhenkilölle hyväksyttäväksi. Projektin arvioinnin helpottamiseksi liitetään projektin loppuraporttiin (malli: liite I) kopio sekä ensimmäisestä hyväksytystä että viimeisestä päivitetystä projektisuunnitelmaversiosta. Huomattakoon, että projektisuunnitelman laatii projektiryhmä (projektipäällikön johtamana) eikä ohjaaja. Koska kuitenkin ohjaajalla on alussa paras näkemys tehtävän sisällöstä ja vaativuudesta, on projektiryhmän varmistettava ohjaajalta erityisesti suunnitellun aikataulun realistisuus.

2. Projektin suorittaminen

Projektin suorittamisen aikana syntyvät tyypillisesti seuraavat tekniset dokumentit:

1. Vaatimus(määrittely)dokumentissa kuvataan ohjelmiston pääpiirteet ja tärkeimmät toiminnot jollakin sopivalla esitystavalla. Dokumentti toimii sopimuksena asiakkaan ja projektiryhmän välillä, joten siihen on kirjattava nimenomaan asiakasta kiinnostavat asiat. Yleinen malli: liite D. Erään tuotteen vaatimusdokumentti löytyy laitoksen mikroverkosta osoitteesta q:\hytky\tvmaar.doc (MS Word) tai q:\hytky\tvmaar.ps (Postscript).
2. Suunnitteludokumentissa kuvataan ohjelmiston tekninen arkkitehtuuri eli sen pääkomponentit ja niiden välinen vuorovaikutus jollakin sopivalla esitystavalla. Yleinen malli: liite E. Erään tuotteen suunnitteludokumentti löytyy laitoksen mikroverkosta osoitteesta q:\hytky\tvsuun.doc (MS Word) tai q:\hytky\tvsuun.ps (Postscript).
3. Toteutusdokumentissa kuvataan suunnitelman mukaiset toteutusratkaisut ja -välineet. Dokumentti sisältää myös kuvauksen ohjelmiston testauksesta. Yleinen malli: liite F.
4. Käyttöohje kirjoitetaan asiakasta tai muuta projektiryhmän ulkopuolista käyttäjää varten. Yleinen malli: liite G.
5. Ylläpito-ohje mahdollistaa ohjelmiston jatkokehittämisen tai muun ylläpidon. Dokumentti tuotetaan yleensä vain niissä projekteissa, joille voidaan odottaa jatkoa myöhemmissä ohjelmistotuotantoprojekteissa. Yleinen malli: liite H.

Jokaisessa projektissa on läpivietävä vähintään yksi muodollinen tekninen tarkastus, jossa jostakin projektin keskeisestä dokumentista etsitään ryhmätyönä systemaattisesti virheitä. Sopivin tarkastuksen kohde on suunnitteludokumentti: projektiryhmä varmistaa suunnittelun tärkeimpien osien laadun ennen siirtymistään toteutusvaiheeseen. Myös esim. vaatimusdokumentin tai ohjelmakoodin voi tarkastaa; vaatimustarkastuksessa on asiakkaan oltava paikalla. Tarkastus on projektin keskeinen etappi, joten se sijoitetaan projektisuunnitelmaan. Huomattakoon, että vähintään ryhmä itse ja ohjaaja tarkistavat tietenkin (ehkä teknistä tarkastusta epämuodollisemmin) kaikki projektissa syntyvät dokumentit.

Jokainen ryhmän jäsen pitää kirjaa päivittäisestä työskentelystään projektin hyväksi. Työpäiväkirjoihin kirjataan, kuinka paljon mihinkin tehtävään on aikaa käytetty. Henkilökohtaiset työpäiväkirjat ja niiden projektikohtainen yhteenveto liitetään loppuraporttiin (malli: liite I).

Huoneessa A411 olevat koneet on tarkoitettu ensisijaisesti ohjelmistotuotantoprojektien käyttöön.

3. Projektin päättäminen

1. Projektin jälkiarviointi, ns. post mortem -analyysi. Tämän suorittaa projektiryhmä keskenään etsien vastausta mm. seuraaviin kysymyksiin: mikä meni pieleen (suhteessa alussa tehtyyn suunnitelmaan tai haluttuun lopputulokseen), miksi meni pieleen, mikä onnistui hienosti, miksi onnistui hienosti, mitä ryhmä tekisi toisin seuraavassa projektissaan, mitä on opittu? Yhteenveto analyysistä liitetään projektin loppuraporttiin.
2. Projektin loppuraportin laatiminen. Siihen kootaan yhteenveto aikaansaannoksista, kokemuksista ja tehdyn työn määrästä. Malli: liite I.
3. Mahdollinen tulosten esittelytilaisuus järjestetään syyslukukaudella joulukuun ja kevätlukukaudella toukokuun puolivälissä. Tilaisuudessa jokainen projektiryhmä esittelee noin puolen tunnin ajan omaa tuotettaan demonstroimalla sen toimintaa. Tilaisuus on tarkoitettu laitoksen henkilökunnalle, muille projektiryhmille ja tulevien ohjelmistotuotantoprojektien opiskelijoille, joten omaa esiintymistä on syytä harjoitella etukäteen.
4. Keväisin järjestetään laitospäivä, johon saatetaan pyytää esittelyä muutamasta parhaiten onnistuneesta edellisen syksyn ja kevään ohjelmistotuotantoprojektista.
5. Jokaiselle projektiryhmälle järjestetään palautetilaisuus (syksyn projekteille tammikuussa ja kevään projekteille kesäkuussa), jossa ohjaaja, ohjelmistotuotantoprojektien vastuuhenkilö ja asiakkaat arvioivat projektin onnistumista ja perustelevat siitä annettua arvosanaa.

4. Laitoksen ulkopuoliset projektit

5. Arvosteluperiaatteet

• tuotteen laatu
• dokumenttien taso
• projektisuunnitelman toteutuminen (aikataulussa pysyminen)
• ryhmätyötaidot

6. Yhteenveto tuotettavista dokumenteista ja aikataulusta

Tarkempia dokumentointiohjeita löytyy alan oppikirjoista sekä erilaisista standardeista. Ellei projektiryhmä tiedä, kuinka sen tulisi tuotteensa tai toimintansa dokumentoida, on siis syytä antaa joidenkin ryhmän jäsenten tehtäväksi etsiä kirjallisuudesta sopivia malleja ja suodattaa niistä ehdotus omalle projektille! Lyhyen ohjelmistoelinkaaren (esim. vain määrittely ja suunnittelu) kattavissa projekteissa laaditaan tietysti vain ko. elinkaarelle relevantit dokumentit. Projektiryhmien on pidettävä sopiva tasapaino dokumentoinnin ja konstruktiivisen työn välillä; liiallinen dokumenttien hiominen ei ole tarkoituksenmukaista, mikäli sillä vaarannetaan ohjelmiston saaminen valmiiksi.

Jokaisen projektin aikana päivitetyn dokumentin alkuun on syytä liittää sen versiohistoria (malli: liite A).

Projektiryhmä pitää jatkuvasti ajan tasalla kattavaa dokumenttiarkistoa. Kaikki dokumentit jätetään paperimuodossa ohjaajalle sekä tarvittaessa myös ohjelmistotuotantoprojektien vastuuhenkilölle ja asiakkaille tarkastettaviksi. Yleensä vastuuhenkilö ja asiakkaat haluavat luettavakseen ainakin projektisuunnitelman, vaatimusdokumentin ja loppuraportin sekä asiakas lisäksi käyttöohjeen. Mikäli lukijat haluavat, on dokumentit annettava heille myös sopivassa elektronisessa muodossa.

Jokainen projektiryhmä määrittelee oman aikataulunsa ohjelmistontuottamisprosessilleen ja siihen liittyvälle dokumentoinnille. Projektisuunnitelma on syytä tehdä nopeasti, kahden ensimmäisen viikon aikana. Dokumentit sijoittuvat projektin päävaiheita välittömästi seuraaviin etappeihin (milestone), joten niiden valmistumisaikataulu kiinnitetään heti projektisuunnitelmassa. Ohjaajien tulee tarkistaa, että suunniteltu dokumentointiaikataulu on järkevä ja että sitä todella noudatetaan.

Projektiryhmien työ käynnistyy normaaliin tapaan lukukauden alussa, ja niiden varsinaiset kokoukset päättyvät samaan aikaan kuin laitoksen muukin opetus, eli syksyllä noin 10.12 ja keväällä noin 10.5. Tämä on myös takaraja itse ohjelmiston valmistumiselle, jotta sitä voitaisiin demonstroida yhteisessä esittelytilaisuudessa. Viimeisiä dokumentteja voivat projektiryhmät hioa vielä senkin jälkeen, mikäli ryhmä on ohjaajan ja asiakkaan kanssa niin sopinut. Kaikki projektit on kuitenkin lopullisesti päätettävä syksyisin viimeistään 31.12 ja keväisin viimeistään 31.5.

Aikaisemmissa ohjelmistotuotantoprojekteissa on tuotettu lukuisia korkeatasoisia ohjelmistodokumentteja. Parhaasta päästä on seuraava, johon tutustumalla nykyiset projektiryhmät voivat saada vahvistusta hypoteesille: laadukas dokumentointi ei ole mahdotonta eikä aina edes välttämätön paha.

Timo Harjunen, Jussi Ollikainen, Martti Söderlund, Katri Turunen, Antti Viljamaa, Jukka Viljamaa: Oliokielten toteutus - selain. Raportti C-1995-33, Helsingin yliopisto, tietojenkäsittelytieteen laitos, 1995.

Liitteet: dokumenttimallit

Liite A. Dokumentin versiohistoria

 ====================================================================
|  Versio  |      Tekijä       |   Päiväys   |     Muutetut osat     |
 ====================================================================
|   0.1    |    Aina Ahkera    |  1.10.1997  |     Luku 2.3          |
 --------------------------------------------------------------------
|   0.2    |    Matti Mainio   | 24.10.1997  |     Luvut 2.1 ja 3.3  |
 --------------------------------------------------------------------
|   ...    |        ...        |     ...     |         ...           |
 --------------------------------------------------------------------
|   1.5    |    Jussi Juonio   | 20.12.1997  |     Liitteet A ja B   |
 --------------------------------------------------------------------

Liite B. Seurantakokouksen pöytäkirja

1. Edellisen kokouksen pöytäkirjan tarkastaminen
2. Projektin tilannekatsaus
   • projektin aikataulutilanne
   • mahdolliset poikkeamat aikataulusta
3. Henkilökohtaiset tilannekatsaukset
   • missä vaiheessa kukin on menossa?
   • viime kokouksen jälkeen tehdyn työn tiivistelmä
   • työajan käyttö
   • mahdolliset yksilökohtaiset ongelmat
   • uudet ideat ja aloitteet
4. Toimenpiteet
   • selvitystä vaativat ongelmat: kuka selvittää?
   • lisäresurssien hankinta: kuka hoitaa?
   • muutosten tekeminen projektisuunnitelmaan: miten jakelu hoidetaan?
   • työnjako: kuka tekee mitä tästä eteenpäin?
5. Seuraavan kokouksen ajankohta
6. Kokouksen päättäminen

Liite C. Projektisuunnitelma

1. Tausta
   • kuka on asiakas?
   • mihin ongelmaan tuote on suunnattu?
   • mahdollinen erikoissanasto ja käytetyt lyhenteet
   • mahdollinen lähdeluettelo
2. Tavoitteet ja rajaukset
   • mitä on tarkoitus tuottaa?
   • tehtävien priorisointi
   • miten asiakas hyväksyy lopputuloksen?
   • dokumenttien kieli (suomi tai englanti)
3. Ympäristö
   • laite- ja ohjelmistoympäristö (esim. käyttöjärjestelmä)
   • tekninen yleisarkkitehtuuri (keskitetty, hajautettu, asiakas-palvelin, ...)
   • käyttäjäprofiilit (aloittelija, asiantuntija, satunnainen, ...)
4. Organisaatio
   • projektiryhmä ja sen mahdollinen sisäinen tehtävänjako
   • projektipäällikkö
   • muut mahdolliset vastuuhenkilöt
   • ohjaaja
5. Toimintasuunnitelma
   • työn ositus: osatehtävät, niiden kesto ja keskinäiset riippuvuudet
   • aikataulu (Gantt-kaavio, toimintoverkko)
   • kriittinen polku
   • työnjako osatehtävittäin / henkilö
   • tärkeimmät tarkistuspisteet (sidottu tuotettaviin dokumentteihin), ml. tarkastustilaisuus
   • kokouspäivämäärät, erityisesti seurantakokoukset
   • mahdollisen prototyypin katsastusajankohta
6. Menetelmät ja standardit
   • käytettävät ohjelmistomenetelmät (oliot, formaali tapa, tarkastusmenettely, ...)
   • käytettävät menetelmä-, ohjelmointi- tai dokumentointistandardit
   • sovellettavat tyylioppaat (nimeämiskäytännöt, kommentointityyli ja -kieli, komponenttien koko, ...)
   • käytettävät työkalut
   • mahdollinen tuotteenhallinta (versiot, konfiguraatiot)

Liite D. Vaatimusdokumentti

1. Johdanto

1.1. Tuotteen tausta ja tarkoitus

1.2. Mahdollinen erikoissanasto ja käytetyt lyhenteet

1.3. Yleiskatsaus dokumenttiin

[Mikäli tuotettava ohjelmisto perustuu johonkin olemassaolevaan järjestelmään, niin:

2. Kuvaus perusjärjestelmästä + viitteet sen dokumentaatioon]

2. Yleiskuvaus

2.1. Yleinen toiminta ("mitä järjestelmän pitäisi tehdä?")

2.2. Tuotteen pääasiallinen toimintaympäristö

2.3. Tuotteen käyttäjäkunta

2.4. Katsaus muihin vastaaviin järjestelmiin

3. Tietokuvaus

3.1. Tietosisältö

3.2. Tietokantamalli

3.3. Kapasiteetti- ja saantiaikavaatimukset

4. Toimintokuvaus (esim. OMT-menetelmällä tai jollakin vähemmän teknisellä menetelmällä)

4.1. Järjestelmän arkkitehtuuri

• toiminnalliset pääkomponentit
• pääkomponenttien väliset suhteet ja rajapinnat
• yleisimmät käyttötapaukset

4.2. Komponentti 1

• yleiskuvaus
• syötteet
• toiminta eli tiedon käsittely
• tulosteet

4.3. - 4.x. Komponentti 2 - Komponentti n

5. Järjestelmän ulkoiset liittymät

• sekä järjestelmän käyttämät että sitä käyttävät muut järjestelmät

5.1. Käyttöliittymä

• mahdollisen prototyypin kuvaus
• kuvaus tyypillisistä käyttöskenaarioista
• kuvia hahmotellusta käyttöliittymästä (prototyypistä saatuina tai piirrettyinä)

5.2. Laitteistoliittymät

5.3. Ohjelmistoliittymät

5.4. Tietoliikenneliittymät

5.5. Alustustiedot

6. Muut ominaisuudet

6.1. Suorituskyky

6.2. Käytettävyys, virheistä toipuminen, turvallisuus, suojaukset, varmistuskopiointi

6.3. Ylläpidettävyys (ohjelmointityyliohjeet yms.)

7. Testaus

• kuinka kattavasti on testattava?
• millaisella aineistolla on testattava?

8. Rajoitteet suunnittelulle ja toteutukselle

8.1. Noudatettavat standardit

8.2. Laitteistorajoitteet

8.3. Ohjelmistorajoitteet (ohjelmointikielet, käyttöjärjestelmät, käyttöliittymät,...)

Lähdeluettelo

Liitteet:

• kaavioissa käytettyjen symbolien kuvaus
• syötteiden rakenne
• tulosteiden rakenne
• formaalit spesifiointikaavat

Liite E. Suunnitteludokumentti

Liite F. Toteutusdokumentti

1. Johdanto

1.1. Tuotteen tausta ja tarkoitus

1.2. Mahdollinen erikoissanasto ja käytetyt lyhenteet

1.3. Yleiskatsaus dokumenttiin

2. Vaatimusmäärittely, suunnittelu ja niihin tehdyt muutokset

• viite vaatimusdokumenttiin
• viite suunnitteludokumenttiin
• luettelo projektin aikana muuttuneista dokumenttien luvuista

2.1. Rajaukset

2.2. Täydennykset

3. Toteutusratkaisut

3.1. Ratkaisun "filosofia" ja toteutuksen toimintaperiaate

3.2. Käytetyt ohjelmointimenetelmät

3.3. Käytetyt ohjelmointikielet

3.4. Käytetyt (luokka)kirjastot, sovelluskehittimet ja sovelluskehykset

3.5. Muut käytetyt aputyökalut

3.6. Toteutuskokemuksia

• ongelmia kielten tai työkalujen kanssa

3.7. Versionhallinta

• missä hakemistoissa ja tiedostoissa mitkäkin moduulit

4. Moduulitestaus (yksikkötestaus)

4.1. Moduulin 1 testaus

• testausperiaate (yleensä "white box")
• käytetty testiaineisto
• havaitut ja korjatut virheet
• arvio testauksen kattavuudesta

4.2. - 4.x. Moduulin 2 testaus - Moduulin n testaus

5. Järjestelmätestaus (validointitestaus)

• testausperiaate (yleensä "black box")
• käytetty testiaineisto (yleensä perustuen arvoalueen jakamiseen ekvivalenssiluokiksi)
• havaitut ja korjatut virheet
• arvio testauksen kattavuudesta

6. Suorituskykyanalyysi

• tilastoja ajan- ja tilankäytöstä erilaisissa testiajoissa

7. Jatkokehitys

7.1. Toteuttamatta jääneet piirteet

• miksi jäivät?

7.2. Hyödylliset lisäpiirteet

• vaatimus- ja suunnitteludokumenteissa mainittujen lisäksi

Lähdeluettelo

Liitteet:

• koodausohje jatkokehittäjille
• moduulien lähdekoodi
• kirjastoluokkien tai -komponenttien otsikkotiedot
• käytetyt kääntäjien optioasetukset
• testiaineisto (testitapaukset, saadut tulokset, testilokit)

Liite G. Käyttöohje

Otsikkosivu

• tuotteen nimi
• versio ja päiväys
• tuottajaorganisaatio ja projektiryhmä

1. Johdanto tuotteeseen

1.1. Tuotteen käyttötarkoitus

1.2. Oletettu käyttäjäprofiili ja käyttötapa

1.3. Käyttöympäristö (laitteisto, käyttöjärjestelmä, apukirjastot, ...)

1.4. Viitteet muihin käytössä mahdollisesti tarvittaviin dokumentteihin

1.5. Ohjeessa käytetyt kaaviot, symbolit ja lyhenteet

2. Yleiset rajoitteet

• kuka saa käyttää?
• tekniset rajoitteet (syötteen maksimikoko, tarvittava muistin määrä, ...)

3. Takuut ja sitoumukset

• mistä tuote on saatavissa?
• kuka ylläpitää (korjaa virheet)?
• mistä saa käytön opstusta?

4. Tuotteen käyttö

4.1. Ohjelman käytössä tarvittava apumateriaali

4.2. Alustavat toimenpiteet (viite asennusohjeeseen, luku 7) ja ohjelmiston käynnistys

4.3. Pikaopas

• lyhyt yhteenveto tyypillisimmistä käyttömuodoista ja toimintosarjoista

4.4. Ohjeet toimintojen suorittamiseksi

• kuvia käyttöliittymästä
• toimenpidevalinnat (komennot) ja niiden toiminta
• syötteiden kuvaus (muoto ja merkitys)
• tulosten kuvaus (muoto ja merkitys)
• esimerkkejä käyttötilanteista

4.5. Käytettävissä olevat optiot

4.6. Toimintojen peruutusmahdollisuudet

4.7. Suorituksen tilan tallettaminen ja uudelleenkäynnistys

5. Virheilmoitukset

• lista ohjelmiston tuottamista virheilmoituksista ja varoituksista
• virheiden syy
• kuinka toimia kussakin virhetilanteessa?

6. Toiminnalliset erot erilaisissa käyttöympäristöissä (laitteisto, käyttöjärjestelmä, ikkunointijärjestelmä, ...)

• komennot ja niihin liittyvät toiminnot
• käyttöliittymän ulkoasu

7. Asennusohje

• asennuskomennot tai automaattiset työkalut
• asennusongelmat ja niiden ratkominen (sopimaton laitteisto, käyttöjärjestelmä tms.)

Lähdeluettelo

Sanasto

Hakemisto

Liitteet:

• teknisiä kuvauksia
• komentokielen syntaksi

Liite H. Ylläpito-ohje

1. Johdanto

1.1. Tuotteen identifiointi (tuotenimi, versio, ...)

1.2. Erikoissanasto, lyhenteet

1.3. Ohjeessa käytetyt kaaviot ja symbolit

2. Toiminnallinen yleiskuvaus

2.1. Tuotteen tarkoitus ja tavoitteet

2.2. Yleisarkkitehtuuri (pääkomponentit)

2.3. Looginen tieto(kanta)ratkaisu

2.4. Käyttöliittymän kuvaus

2.5. Liittymät muihin järjestelmiin

3. Toimintaympäristö

3.1. Laitteisto ja prosessori

3.2. Käyttöjärjestelmä

3.3. Ohjelmointikielet ja niiden kääntäjät tai tulkit (versioineen)

3.4. Muut käytetyt/vaadittavat CASE-työkalut

4. Toteutuksen kuvaus

• viite vaatimus-, suunnittelu- ja toteutusdokumenttiin

4.1. Perustelut suunnittelu- ja toteutusratkaisuille

4.2. Päämoduulien kuvaus (tai viite esim. suunnitteludokumenttiin)

4.3. Moduulirajapintojen kuvaus (tai viite esim. suunnitteludokumenttiin)

5. Ylläpidossa tarvittavat tukiohjelmat

5.1. Testaustyökalut

5.2. Ylläpitotyökalut

5.3. Sovelluskehittimet, sovelluskehykset ja (luokka)kirjastot

5.4. Metriikkatyökalut

5.5. Dokumentointityökalut

6. Noudatettavat standardit

• koodausstandardit
• muuttujien yms. nimeämiskäytännöt
• modularisointikäytännöt (suositeltu koko, parametrien ja liitäntöjen käyttö, ...)
• kielletyt ohjelmarakenteet
• kommentointityyli ja -kieli

7. Ylläpito-ohjeita

• miten ohjelmistoon tehdään muutoksia?
• miten moduuli korvataan toisella vastaavalla?
• miten vaihdetaan laskenta-algoritmeja?
• mitä dokumentteja pitää päivittää?
• miten paikallistetaan virheitä?
• mitkä osat eivät toimineet aiemmissa versioissa?

Lähdeluettelo

• luettelo teknisistä dokumenteista

Liitteet:

• lähdekooditiedostot (tai viite säilytyspaikkaan)
• viite dokumentaation säilytyspaikkaan

Liite I. Projektin loppuraportti

1. Johdanto

1.1. Tausta

• asiakkaat
• ongelma, jota tuotteen avulla ratkotaan

1.2. Raportissa käytettävät käsitteet ja termit

2. Yleiskuvaus ohjelmistosta

2.1. Tehtävä

2.2. Toimintaympäristö

2.3. Rajoitukset

3. Projektiorganisaatio

• ryhmän jäsenet
• ohjaaja
• projektipäällikkö
• muut erikoisroolit

4. Projektin eteneminen

4.1. Ensimmäinen hyväksytty versio projektisuunnitelmasta

4.2. Viimeinen versio projektisuunnitelmasta

4.3. Viitteet tuotettuihin dokumentteihin

5. Projektin hallinta

5.1. Kokouspöytäkirjat

5.2. Tarkastuspöytäkirjat

5.3. Työmäärät vaiheittain

• yhteenvedot projektitasolla ja henkilötasolla

6. Jälkianalyysikokouksen (post mortem) yhteenveto

• mikä meni pieleen ja miksi?
• mikä onnistui hyvin?
• mitä olisi pitänyt tehdä toisin?
• mitä opittiin?

Liitteet:

• henkilökohtaiset työpäiväkirjat
• viikkoraportit

Liite J1. Tarkastuspöytäkirja:

löydettyjen virheiden lista

Katso esim. kurssin Ohjelmistotuotanto luentomappi, A412.

Liite J2. Tarkastuspöytäkirja:

löydettyjen virheiden yhteenveto

Katso esim. kurssin Ohjelmistotuotanto luentomappi, A412.