Projektisuunnitelma

PSP-HUT

Sisällysluettelo

Sanasto

1 Johdanto

1.1 Tavoite

2. PSP-HUT projektin tavoite on suorittaa TKK:n Tik-76.115 kurssi suunnitelmallisesti ja hallitusti läpi.

1.2 Tehtävä

Tehtävä on hyvin läheisessä yhteydessä TAI tutkimuslaitoksen LUCOS-projektin kanssa ja projekti käyttää Lucoksessa kehitettyjä työkaluja.

1.3 Sidosryhmät

1.3.1 Asiakas ja ohjaajat

1.3.2 Projekti ryhmä

1.4 Oikeudet työhön

2. Projektin vaiheiden tavoitteet ja aikataulu

2.1 Projektin suunnittelu (PS)

Projektin suunnitteluvaihe loppuu 13.10.1999, jolloin palautamme projektisuunnitelman (tämä dokumentti) sekä vaatimusmäärittelyn. Molemmat dokumentit ovat käyneet ennen palautusta sekä ryhmän että asiakkaan kommentoitavina. Varsinainen katselmus järjestetään kurssilla tämän vaiheen takarajan jälkeen.

Tämän vaiheen tulokset verifioidaan sekä projektiryhmän sisäisellä kommentointi- ja katselmointikierroksella, että asiakkaan ja kurssin järjestämissä katselmointitilaisuuksissa.

2.2 Määrittely (MÄ)

Tämän vaiheen suorittamisesta syntyy valittua arkkitehtuuria kuvaavia kaavioita. Näistä kaavioista käy ilmi ohjelmiston luokkahierarkia, tietokantarakenne, toiminnallinen ympäristö, tietovuo, ohjelmiston sisäiset prosessit ja modulijako. Vaatimusmäärittelyssä esitettyjen toimintojen tarkempi kuvaus on esitettynä tapahtuma kuvauksena, toiminnot kuvataan use caseinä, jotka sisältää seuraavat tiedot:

Nimi:
Alkuehto:
Tapahtumaketju(kaaviona):
Poikkeustenkäsittely:
Lopetusehto:

Määrittelyvaiheessa luodaan myös projektin ohjelmointi- ja dokumentointiopas.

Vaihe päättyy toiminnallisen määrittelyn palautukseen 3.11.1999

Vaiheen tulokset validioidaan katselmoimalla systeemiarkkitehtuuria kuvaavia kaavioita sekä katselmoimalla toiminnallista määrittelyä kurssin järjestämässä katselmointitilaisuudessa ja ryhmän sisäisessä katselmuksessa.

2.3 Suunnittelu (SU)

Tärkein tehtävä tässä vaiheessa on määritellä modulien rajapinnat ja modulien sisäinen toiminta kaaviona ja muodostaa luokkakaavion koko ohjelmistosta. Tietoliikennettä varten tulee tässä vaiheessa myös määritellä käytettävä XML pohjainen kuvauskieli. Ohjelmistosta tehdään ensimmäinen alpha-proto toteuttamaan järjestelmän perusarkkitehtuuria. Tässä vaiheessa asetetaan myös ominaisuuksien toteutusjärjestys ja -aikataulu, jonka pohjalta lähdemme toteuttamaan järjestelmää.

Alpha-proton sisältösuunnitelma

• Järjestelmäarkkitehtuurin demo
• Jokainen moduli on paikallaan ja toteuttaa toiminnot, jotka vaaditaan siihen, että:
• "Check Mate" lähettää on-line kyselyn tietokantaan asti
• "Check Mate" lähettää start nappulan painalluksen, joka tallentuu tietokantaan
• Www-selaimella näytetään tiedon siirtyminen tietokantaan
• Käyttöliittymän perusidea

• Interaction kaavio
• Tekninen määrittely
• Tarkka modulitason arkkitehtuurikuvaus
• Rajapinnat moduleille
• Käytettävä XML DTD
• Testaussuunnitelma
• Testitapaukset moduleille
• Järjestelmän osien lähdekoodinen luurankomalli

Vaiheen tulokset verifioidaan katselmoimalla vaihetuotteet sekä ryhmän sisäisessä katselmoinnissa, että kurssin järjestämässä katselmoinnissa.

2.4 Prototyyppi 1 (P1)

Toteutuksessa käytetään inkrementaalimenetelmää, jossa toiminnallisuudet lisätään yksitellen prioriteetilistan ja modulien välisten riippuvuuksien määräämässä järjestyksessä. Tässä vaiheessa päätämme myös seuraavassa vaiheessa toteutettavat uudet ominaisuudet sekä parannettavat P1 vaiheen ominaisuudet. Toteutuksen jälkeen ratkaisut dokumentoidaan ja testataan, josta saadaan jokaiselle modulille testiraportti. Modulin suunnittelija kirjoittaa käyttöohjeen loppukäyttäjälle, ylläpitäjälle ja jatkokehittäjälle kirjoitettaan jokaisen modulin jälkeen. Modulin suunnittelija suunnittelee ja toteuttaa myös jokaiseen modulin testitapaukset.

Vaihe päättyy testiraportin palautukseen 16.2.2000 ja proton demoon 21.2.2000

Vaiheen tulokset validioidaan suorittamalla modulien testausta sekä suorittamalla tarkasteluja ryhmän sisällä sekä suorittamalla ensimmäinen perustoiminnallisuudet sisältävä demo. Vaihetuotteille järjestetään ennen vaiheen loppua vielä ryhmän sisäinen katselmointi sekä vaiheen jälkeen kurssin järjestämä katselmointi

2.5 Prototyyppi 2 (P2)

Vaiheen aikana tulee suorittaa integrointi ja järjestelmätason testausta ja korjata mahdolliset viat. Muuten toiminta tulee olemaan samantyyppistä kuin P1:ssä.

Vaihe päättyy testiraportin palautukseen 22.3.2000 ja proton demoon 27.3.2000

Vaiheen tulokset varmistetaan tiiviillä priorisointikeskustelulla asiakkaan kanssa sekä toteutuksen testauksella että tarkastelulla.

2.6 Luovutus (LU)

Vaiheen aikana viimeistellään dokumentaatio, varmistetaan järjestelmätestauksella toiminnallisuudet, poistetaan tilapäistiedostot ja data sekä paketoidaan ohjelmisto. Järjestelmästä kirjoitetaan asennusohje sekä verrataan tehtyä ohjelmistoa vaatimuksiin.

Vaihe päättyy loppuraporttiin 19.4.2000 sekä loppudemonstraatioon 2.5.2000

2.7 Jälkihoito

3 Tehtävät ja resurssit

3.1 Koko projekti

Projektin henkilökunta on käytettävissä koko projektin keston ajan pääsääntöisesti iltaisin. Poikkeuksena joulukuu, jolloin alkukuukaudesta koulun tenttikausi vähentää mahdollisuuksia tehdä projektia, sekä joululoman aika.

3.2 Tarkennetut vaihekohtaiset tehtäväsuunnitelmat

3.2.1 Projektin suunnittelu

3.2.2 Määrittely

3.2.3 Suunnittelu

3.2.4 Prototyyppi 1

3.2.5 Prototyyppi 2

3.2.6 Luovutus

3.3 Kustannusarvio

4 Työmenetelmät

4.1 Työkalut ja laitteistot

• Ohjelmiston kehityksen keskuksena toimii asiakkaan tiloihin hankittava PC-laitteisto. Erillisten komponenttien kehitykseen käytetään myös projektiryhmän omia laitteita.
• WWW-palvelimella sijaitseva toiminnallisuus toteutetaan WWW-palvelinohjelmiston asettamien rajoitusten mukaan joko

Java-servlettejä tai JSP:tä Java 1.2. ympäristössä, sekä mahdollisesti jotain scriptikieltä (esim. Perl)
• Lähdekoodin editointiin käytetään Emacsia tai muuta vastaavaa tekstieditoria
• Käyttöliittymän suunnitteluun käytetään Visual J++ ja tai asiakkaan tarjoamaa muuta visuaalista kehitysympäristöä.
• Selainkäyttöliittymän suunnitteluun ja projektin dokumentaation tuottamiseen kaytetään jotain joko ilmaista tai asiakkaalta saatavaa WYSIWYG-html editoria.
• Versionhallintaan käytetään CVS-järjestelmää.
• Projektiin ja toteutettavaan järjestelmään liittyvien olio- rakenne- tietokanta- ja muiden vastaavien kaavioiden laatimiseen käytetään Rational Rose -ohjelmistoa, mikäli asiakas sen pystyy tarjoamaan. Muussa tapauksessa käytetään saatavilla olevia ilmaisia työkaluja.
• Projektin resurssien ja ajankäytön hallintaan ja seurantaan käytetään MS Project -ohjelmaa

4.2 Testaus

4.3 Dokumentointimenetelmät

Dokumenttien laadun tarkkailu toteutetaan katselmuksilla/tarkastuksilla. Laaduntarkkailu- ja tarkastusmenettelyt on kuvattu tarkemmin tämän dokumentin luvussa 5.

Kaikki projektin dokumentaatio toimitetaan html-muodossa. Dokumentit varastoidaan TKK:n atk-keskuksen koneille kurssin suosittelemaan hakemistohierarkiaan. Projektin dokumentaation pääsivu löytyy osoitteesta http://www.hut.fi/~llauren/76115/. Dokumenttiarkistoon varastoidaan myös kaikki varsinaisen projektidokumentaation, ohjelmiston määrittelyjen ja suunnitelmien lisäksi tuotettu dokumentaatio, kuten kokousten esityslista ja pöytäkirjat, työkaluihin ja menetelmiin liittyvät ohjeet, linkkilistat ja muu satunnainen informaatio. Dokumentit tallennetaan määriteltyihin paikkoihin ja kaikilla projektiryhmäläisillä tulee olla luku- ja kirjoitusoikeudet dokumentteihin. Lisäksi tulee huolehtia, että kaikki dokumentit ovat nähtävissä www-selaimella myös atk-keskuksen ulkopuolelta.

Tuotetun ohjelmakoodin dokumentoinnissa ja kommentoinnissa noudatetaan Java-kielellä toteutettujen moduulien osalta JavaDoc Style Guide:n mukaista kommentointityyliä. Ohjelmakoodin dokumentaatio tuotetaan sitten JavaDoc työkalulla html-muotoon ja varastoidaan CVS versionhallintajärjestelmään..

Muiden kuin Java-kielellä toteutettujen moduulien kommentoinnissa noudatetaan soveltuvin osin edellä mainitun tyylioppaan ohjeita, sekä määrittelyvaiheessa luotavaan tyylioppaaseen.

4.4 Projektityön menetelmät

4.4.1 Palaverikäytännöt

Kokouksen alussa palaverin vastuuhenkilö käy vielä tarkasti läpi asiat, jotka siinä palaverissa tulee käydä läpi ja mitä päätöksiä ja lopputuloksia siitä palaverista odotetaan. Palaverin vastuuhenkilö kirjaa tärkeimmät päätökset ja lähettää ne koko projektiryhmälle sähköpostiviestinä sekä tallentaa ne projektiryhmän www-sivuille arkistoon. Palaveria suunniteltaessa varmistetaan tietokoneen läsnä olo, jotta päätökset voidaan kirjoittaa suoraan sähköiseen muotoon sekä käsiteltävään asiaan tarvittavien dokumenttien löytyminen tietokoneelta.

Pitää kerran viikossa palaverin, joka ajoittuu määrittelyvaiheessa ke 16-> joko kurssin luennon jälkeen tai suoraan jos luentoa ei ole.

4.4.2 Työajan ja virheiden raportointi

Virheiden raportointiin käytämme kurssin raportointityökalua. Testaajan tulee lähettää myös modulin vastuulliselle tieto virheen löytämisestä. Virheistä tulee tiedottaa myös tätä modulia käyttävien modulien vastuullisille, jotta he voivat testata uudestaan toiminnot korjauksen jälkeen.

4.4.3 Sisäinen tiedonkulku

4.4.4 Dokumenttien hallinta

4.5 Riskien hallinta

Ensin projektiryhmä tutustuu riskienhallintaan ja käytettävään riskienhallintamenetelmään kahdella luennolla: 8.10. ja 15.10. Varsinainen riskienhallinta tapahtuu käyttäen Riskit menetelmää (The Riskit Method for Software Risk Management, version 1.00, CS-TR-3782, 1997. Computer Science Technical Reports. University of Maryland. College Park, MD.).

Riskienhallintasessioita pidetään projektin aikataulua myötäillen siten, että ensimmäinen pidetään projektisuunnittelu -vaiheen päätyttyä, toinen määrittelyvaiheen jälkeen, kolmas suunnitteluvaiheen ja vastaavasti neljäs ja viides prototyyppi 1- ja prototyyppi 2-vaiheiden jälkeen. Tätä aikataulua myötäillen projektin riskit raportoidaan erillisellä vaiheiden mukaan täydennettävällä riskienhallintaraportilla. Tässä dokumentissa ylläpidetään päivitettyä yhteenvetoa tärkeimmistä riskeistä ja kontrolloivista toimenpiteistä.

Yleisenä periaatteena on, että perinteisen paperinmakuisen riskien listaamisen sijasta pyritään siihen, että tämän projektin riskienhallinta keskittyy aktiiviseen ja suunnitelmalliseen toimintaan riskitason alentamiseksi. Hallittu ja suunnitelmallinen Riskit menetelmän käyttö ja koko projektiryhmän osallistuminen jatkuvaan riskienhallintaprosessiin antaa tälle erinomaiset mahdollisuudet.

4.5.1 Tärkeimmät riskit

4.5.2 Kontrolloivat toimenpiteet

Riski 1:

Suunnitellaan työnjako, tehtävät ja työmäärät huolellisesti, ajoissa ja otetaan huomioon projektiryhmäläisten todellinen käytettävissä oleva aika.

Riski 2:

Pidetään vaatimukset realistisina ja rajataan vaatimuksia tiukasti. Pidetään asiakas ajan tasalla suunnitelluista ominaisuuksista ja vaadittavista työmääristä. Priorisoidaan vaatimukset ja rajataan jo 1. prototyyppivaiheen jälkeen lopullinen toteutettava toiminnallisuus.

Pidetään huolta, että toteutetaan ominaisuudet määrittelyjen mukaisesti ja prioriteettijärjestyksessä, eikä aleta toteutusvaiheessa lisäämään toiminnallisuuteen pieniäkään määrittelemättömiä toimintoja tai ominaisuuksia.

Riski 3:

Evaluoidaan työkaluja ennen valintaa ja pyritään valitsemaan sellaisia työkaluja, jotka tunnetaan ja tiedetään hyviksi ja tehokkaiksi.

Riski 4:

Opiskellaan PSP:tä. Otetaan PSP käyttöön projektin toteuttamisvaiheessa.

Riski 5:

Pidetään ryhmähenkeä kohottavia tilaisuuksia. Huolehditaan, että ryhmän sisäinen kommunikaatio toimii.

Riski 6:

Järjestetään versionhallinta kuntoon ja säilytetään koodia ja dokumentaatiota TKK:n ATK-Keskuksen varmistetuilla levyillä.

4.6 Jäsenten roolit ja tehtäväjako

• Tehtävät lyhyitä n. 10-15h/henk
• Ryhmätehtävissä aina yksi nimetty vastuullinen
• Tehtävän tavoite tulee asettaa selvästi
• Tehtävälle asetettaan aikaraja

4.7 Lähdeluettelo

 SEI:n PSP www-sivut.

5 Ohjaussuunnitelma

5.1. Laadunvarmistus

Työn suunnittelu etenee vaihekohtaisesti siten, että kunkin työvaiheen aluksi projektisuunnitelmaa tarkennetaan aktiviteettien ja resurssoinnin osalta. Projektisuunnittelusta vastaa ensisijaisesti projektipäällikkö, mutta jokainen projekti ryhmän jäsen vastaa siitä, että suunnitelma on sellainen, että siihen itse pystyy henkilökohtaisesti sitoutumaan. Lisäksi sovitaan ja määritetään prosessit ja menetelmät vaiheen läpiviemiseksi. Suunnitteluun liittyy myös kuhunkin vaiheeseen liittyvien katselmointien ja testauksen yksityiskohtainen suunnittelu. Laatupäällikön tehtävänä on osallistua suunnitteluun aktiivisesti ja sitä kautta varmistaa, että suunnitelma on realistinen ja sovitut työmenetelmät ovat riittäviä toivotun laadun varmistamiseksi. Ensisijaisesti työmenetelmien valinnassa pyritään varmistamaan, että ne tukevat parhaalla mahdollisella tavalla vaatimusmäärittelyssä esitettyjen laatukriteerien (lisää linkki) toteutumista.

Projektipäällikkö seuraa aktiivisesti visualisointityökalun avulla ja suoralla kommunikoinnilla projektiryhmän kanssa, että työ etenee aikataulussaan. Korjaavat toimenpiteet aloitetaan välittömästi, jos tarvetta ilmenee. Projektin laatupäällikön vastuulla on seurata ja varmistaa, että suunniteltuja prosesseja ja menetelmiä toteutetaan projektin jokaisen työvaiheen osalta, ja tarvittaessa sopia korjaavat toimenpiteet projektipäällikön ja muun projektiryhmän kanssa. Koska elämme muuttuvassa ympäristössä, suunnitelmista saatetaan joutua poikkeamaan. Kaikki poikkeamat suunnitellusta dokumentoidaan, perustellaan ja seuraukset analysoidaan.

5.2. Muutostenhallinta

5.3. Katselmukset