Ohjelmistotuotantoprojekti            PÖYTÄKIRJA  29.10.2004
s. 2004 
ryhmä 1: AssariXP


AIKA    29.10.2004 kello 12.15.

PAIKKA  Tietojenkäsittelytieteen laitos, luokka A319, 
        Gustav Hällströmink. 2 b, 00014 Helsinki

LÄSNÄ   Asiakas Harri Laine, ohjaaja Sini Ruohomaa sekä Mikko Hakila,  Maruan Khoury, 
        Ilkka Manner, Pirjo Tervonen, Kirsi Ylänne ja Tuija Åkerblom.

1       ASIAKKAAN PUHEENVUORO
        Asiakas Harri Laine kertoi, että palautelomakkeeseen voisi laittaa kohdan:
        hyvin vähän työtä, muuten lomake on hyvä. Hän voi lisätä logoja.
        QTI-muunnos on siis mahdollinen. Siitä tehdään malliksi muunnos
        esimerkiksi valintatehtävistä. 
        Edellisen ryhmän versiossa tehtävien oleva vastauksista annettava palaute ei ole
        toimiva. Tehtävissä, joissa vain yksi vaihtoehto on oikea, pitäisi olla erilainen
        palaute kuin niissä tehtävissä, joissa moni vaihtoehto voi olla oikea.
        Muunnoksia tehdään nyt olemassa olevaan rakenteeseen. Rakenne on joustava,
        attribuuttien nimiä voidaan muuttaa.
	
        Log In:  Main-servletti perii annetun kirjastoluokan. Luokassa on määritelty
        automaattisesti, että jos ei ole olemassa sessiota, niin se luo session. Se siirtää
        kontrollin log-in -luokalle ja tekee talletuksen. Käytetään GET-parametria. Harri
        Laine toimittaa luokan koodit viikonloppuna tai maanantaina. 

2       SUUNNITTELUDOKUMENTTIIN TULEVIEN ASIOIDEN TARKASTELUA
        Sekvenssikaavioihin tulee metodin nimet ja parametrit.
        Mikko kirjoittaa MAIN-servletistä oman luvun ja navigoinnista
        oman palikan. DatabaseAccesille tulee oma luku,
        samoin tietokannan esittelylle. Sen jälkeen tulee Main-servletin kuvaus.
        Navigointi tulee Main-servletin kuvaukseen. Syötteen validointi ryhmän ja    
        pakkauksen tekemisen apuväline, mainitaan, että ne käyttävät tätä luokkaa.
        Mainitaan yleiskuvassa, että kaikki kuuluvat pakkauksen alle.

        Edeltäjäprojektin tietokanta, josta tehtiin tälle ryhmälle kopio, on assarixp.
        Lisätään uusi tekstikenttä tietokantaan palautteen tietoihin: improvetext
        (parannusehdotuks, varchar (2000)).
	
        Palautekomponentti tulee omana sivunaan näkymään. Mikko tekee palautteeseen  luokan, 
	joka generoi metodit. Siinä servise on prosess request.
	
        Dokumenttiin riittää sellainen käyttöliittymäkuva, jossa kaikkia mahdollisia
        operaatioita voi tehdä. Käyttöliittymäkuvat laitetaan suunnitteludokumenttiin liitteeksi,
	samoin QTI-selvitys.
        Liitteessäkin voi olla sekä tekstiä että kuvia.
        Luokista tehdään luokkakaaviot. 
        Mietittiin, että onko ajateltu, että miten onnistuu se, että kaksi tekee yhtä aikaa jotain 
	systeemille.

                       
3       FTR:N PÄIVÄMÄÄRÄ JA CHECKLIST
        Formal Technical Review on tiistaina 9. marraskuuta kello 12.15 luokassa A319.
        Sini kertoo ajankohdan Juha Tainalle.
        FTR kestää kestää noin puolitoista tuntia.
	
        Tilaisuudessa tehdyt huomautukset suunnittelusta luokitellaan. Huomautus voi olla: 
	1. Lisäysehdotus, 
	   tai
	2. Puute, 
	   tai
	3. Vakava puute
        Puutteet lasketaan, montako kommenttia on kussakin luvussa.
        Jokaisen suunnitteludokumentin luvun esittely on vain pari sanaa, ei monta minuuttia.

        Checklist Formal Technical Review -tilaisuuteen: 
	1.  Toteutuvatko vaatimukset.
        2.  Onko metodit kuvattu, sekä onko kerrottu niiden parametrit, palaute, 
	    mistä metodeja kutsutaan, mitä metodit tekevät.
        3.  Onko tietokanta muutokset kuvattu, tarkkuudella, että mitä jokainen sarake tekee.
        4   Ovatko käyttöliittymäkuvat olemassa ja voiko niillä tehdä sen, mitä vaatimusdokumentissa
	    oli määritelty.
        5.  Onko olemassa virheenkäsittelyn kuvaus, josta näkee, että mikä asia missäkin 
	    luokassa voi mennä vikaan. Jokaiseen komponenttiin pitää olla aliluku: mahdolliset 
	    virhetilanteet.
        6.  Onko dokumentin yhtenäinen siten, että eri kirjoittajien tekstit ovat samanlaisia.
        7.  Onko jokaiselle luokalle olemassa keino ohjelmoida se (ja ajatus siitä,
            miten se tehdään)
        8.  Onko komponenttien luokat on kuvattu.
        9.  Onko tarvittava integraatiotestaus suunniteltu.
        10. Onko dokumentti selkeä.
        11. Tekstistä viitataanko tekstistä oikein kuviin.
        12. Miten riskit on otettu huomioon? Riski: Jos tarvitsee hajottaa joku metodi osiin.
                                      
             
4        KOKOUKSEN PÄÄTÖS
         Kokous päättyi kello 11.50

Helsingissä, 29.10.2004
sihteeri Pirjo Tervonen