Projektiryhmän kokous ke 25.5
Muistiinpanot: Marja

Käsiteltiin projektisuunnitelmaa.

Seuraavista asioista keskusteltiin ja päätetttin muutoksia:

Johdanto
-Lisätään maininta siitä, mikä BASSIST on.
-Kappaleiden kuvauksien asettelu muutetaan taulukkomaisemmaksi.

Kommunikaatio
-Lisätään tieto vakituisista tapaamisajoista.

Riskit
-Loss of project data: tn muutetaan low:ksi
-Lisätään riski: laitoksella oleviin tiedostoihin ei päästä käsiksi 
laitoksen tietokonevian tms. vuoksi.
-Keskusteltiin siitä, mitä tarkoittaa "optimistinen aikataulu" ja 
"pessimistinen aikataulu". Näkemykset erosivat toisistaan täydellisesti, 
joten päätettiin muuttaa sanamuoto.
-Keskusteltiin sanamuodosta de-scope, päätettiin muuttaa se havainnollisemmaksi.
-Delay: minimointikohtaan lisätään: työskennellään enemmän
-Harder than expected: minimointikohtaan lisätään: ongelman käsittely ryhmässä
-Incompatibility: Poistetaan maininta lähdekoodeista, ja lisätään sen tilalle 
maininta rajapinnoista, koska yhteensopimattomuus johtuu rajapinnoista 
eikä lähdekoodista.

Aikataulu
-Ari oli yhdistänyt kirjoittamansa luvun "Työn ositus" tähän lukuun. 
 Keskusteltiin tästä jaosta.
-Muutetaan examined -> reviewed termistön yhtenäistämiseksi.
-Keskusteltiin, pitäisikö kokoarviointi laittaa omaksi luvukseen. 
 Näkemykset erosivat. Mitään päätöstä ei taidettu saada aikaan.
-GANTT-kaavio päätettiin sijoittaa omalle sivulleen dokumentin 
 loppuun sivuttaisuunnassa, jotta se saataisiin riittävän isona. Loman 
 kohdalle kaavioon päätettiin lisätä aukko ja palkit muuttaa paksummiksi.
-Keskusteltiin, mitä FP-analyysiin tulee.

Raportointi
-Tuntikuvaukset muuttuvat ja lisäksi päätettiin lisätä 
 maininta mittausjärjestelmästä ja sen käytöstä.
-Dokumentissa sanotaan, että raportti palautettaisiin maanantaina. 
 Korjataan se tiistaiksi.
-Lisätään viitteet Coding Style-kappaleeseen.
	-Viitteet päätettiin tehdä suoraan LateX:illa, 
         käyttämättä dokumenttipohjan valmista "viiteominaisuutta", 
	 koska sen toiminnasta ei saatu selvyyttä.
	-Päätettiin, että Anni laittaa tämän dokumentin viitteet 
	 viitelukuun, koska tämä luku on ainoa, josta viitteitä tulee.

Laadunvalvonta
-Muutetaan testauksen kuvaus Tainan ohjeistuksen mukaiseksi:
	-Vaatimusmäärittelyn aikana suunnitellaan järjestelmätestit.
	-Suunnitelun aikana suunnitellaan yksikkö- ja integrointitestit.
	-Toteutusvaiheessa suortetaan yksikkö- ja integrointitestit.
	-Testausvaiheessa suoritetaan järjestelmätestit.

Päätettiin, että projektisuunnitelma on valmis torstai-iltana, 
jolloin kaikki ehtivät lukea sen perjantaiaamuna ennen tarkastusta.


Sitten keskusteltiin vaatimusmäärittelystä.

-Keskusteltiin siitä, pitäisikö vaatimusdokumentin pohjana 
 käyttää ohtu-kurssin kalvoissa esitettyä vai IEEE:n pohjaa.
-Päätettiin luokitella vaatimukset prioriteetin mukaan IEEE:n 
 asteikolla Essential - Conditional - Optional. (Huom! Riskiluvussa 
 mainittu Primary täytyy muuttaa Essentialiksi vaatimuksista puhuttaessa.)
-Keskusteltiin vaatimusten poimimisesta aikaisemmista 
 asiakastapaamisten muistiinpanoista.
-Päätettiin, että Anni kirjoittaa vaatimusmäärittelyn 
 pohjan LateXilla.

Keskusteltiin ohjelmasta ja seuraavasta asiakastapaamisesta

-Työn rajaus pitäisi saada selville.
-Asiakkaalle voisi tarjota suppean määrän erilaisia 
 mahdollisia vaihtoehtoja ohjelmiston arkkitehtuurin suhteen. Esim. 
 tehdään yksittäisiä ratkaisuja ongelmiin eikä lainkaan generaattoria / 
 tehdään ohjelma, joka ratkaisee monet eri tapaukset "suoraan" eikä 
 generoi mitään / tehdään generaattori ... päätettiin miettiä näitä 
 perjantaina.
-Missä määrin komponenttiajattelua otetaan mukaan.
-Oli epäselvyyttä siitä, oliko asiakas tarkoittanut, että malleja on vain 
 pari, vai että aineistoja on pari ja niihin liittyviä malleja voi olla 
 useampia. Ja missä määrin malleihin pitää pystyä lisäämään muuttujia ts. 
 mitkä asiat voi pitää vakioina.
-Asiakkaalle päätettiin esittää kysymyksiä erityisesti seuraavista: 1) 
 Malli ts. mitä muuttujia tulee, mitä pitää pystyä lisäämään 2) Syötteet 
 ja niiden muoto 3) Käytettävä algoritmi 4) Tulosteet ja niiden muoto

Keskusteltiin kehitysstragiasta

-Jonkinlainen konsensus lienee siitä, että ensin mietitään ongelmien (ts. 
 malli + data) yksittäisiä ratkaisuja