Projekti: eAssari Moodle-ympäristössä PÖYTÄKIRJA 5.10.2006 AIKA 5.10.2006 klo 12:15 PAIKKA Tietojenkäsittelytieteen laitos (Exactum) Gustaf Hällströmin katu 2b, Helsinki Sali A318 OSALLISTUJAT Järviniitty Juho Karkulahti Ossi (puheenjohtaja) Katainen Riku Tverin Teemu Vainio Ville-Pekka (sihteeri) Halko Antti (ohjaaja) Laine Harri (asiakas) POISSA Ei poissaolijoita Asialista 1.Kokouksen avaus Puheenjohtaja avasi kokouksen klo 12:18 2.Yleistä katselmoinnista Karkulahti kertoo lyhyesti katselmoinnin pitotavasta. Hänen ehdotuksestaan sovitaan, että käytetään virheiden vakavuusasteikkona seuraavaa: a: kohta korjataan b: kohta tehdään uudestaan c: katselmointi hylätään Vakavuudet jäivät tosin myöhemmin määrittelemättä yksittäisille virheille. 3.Vaatimusmäärittelyn katselmointi Alle on merkitty kaikki puutteet luvuittain (sisällössä, tyylissä ja oikeinkirjoituksessa) vaikka kokouksessa ne käsiteltiinkin jossain määrin erikseen. Koko dokumenttia koskevat muutokset: Halko pyytää käyttämään passiivimuotoa "me"-ilmaisun sijaan. Koskee myös muita dokumentin osia. Halko pyytää käyttämään tyyliä "question engine:n", mutta Vainio on kysynyt asiaa mm. avoimen lähdekoodin ohjelmistojen kääntäjien #lokalisointi-irc-kanavalla, jossa oltiin vahvasti "enginen" muodon kannalla, kuten dokumentissa on. Kaksoispiste tulee heidän mukaansa vain lyhenteiden jälkeen. 1. Johdanto Passiivi 2 Sanasto: eAssari-käsitteeseen lisättävä maininta mahdollisuudesta määritellä uusia tehtävätyyppejä ilman tietokantarakenteen muutoksia. Viimeinen lause aloitettava isolla alkukirjaimella ("Vastaus"). 2.1 Question enginen terminologia: Laine huomauttaa että Moodlessa on käytössä huonot Question enginen termit, hänen mukaansa answer-rakennetta voidaan käyttää muunkin tiedon kuin vastauksen käsittelyyn ja sen avulla voidaan mahdollisesti toteuttaa projektin ajatus tietokantarakenteen muokkaamattomuudesta. Oikea muoto "tehtävätyyppiliitännäiset", väliviiva pois. Oikea muoto "arvostelusäännöt", yhdyssana. Oikea muoto "tulisi tallettaa ... tietokantatauluihinsa", ei "-tauluissansa". 3 Sidosryhmät Laine pyytää, että opettajan rooli jaetaan kahtia siten että tehtävätyyppien tekijä ja tehtävien tekijä ovat eri aktoreita. Hän ehdottaa tehtävätyyppien tekijän nimeksi laatijaa ja tehtävien tekijän nimeksi opettajaa. 4 Ohjelmiston arkkitehtuuri Toisessa kappaleessa vaihdettava yo. pyynnön perusteella opettaja laatijaksi. 4.1.2 Tehtävän analysoija Laine huomauttaa, että ratkaisuyritystä käytetään arvostelussa, mutta sitä ei välttämättä suoraan verrata oikeaan vastaukseen kaikissa kysymystyypeissä. Kohta vaatii siis uudelleenmuotoilun. 4.1.3 Tehtävän esittäjä Oikea muoto "...sisältää funktiot, jotka", lisätään pilkku. 5.1 Opettajan käyttötapaukset Passiivi 5.1.1 Tehtävän lisääminen Tapahtumien kulussa ei pitäisi puhua käyttöliittymäelementeistä, "valikostaan" pois. 5.1.2 ja 5.1.3 Laine pyytää kirjaamaan dokumenttiin tilanteen, jossa muokataan tai poistetaan tehtävä johon joku on jo vastannut. Mahdollisesti myös jonkinlainen kuvaus siitä, mitä tässä tapauksessa tehdään. 5.1.4 Tehtävien selailu Halko pyytää poistamaan tästä kohdasta valintamahdollisuuden uuden tehtävän lisäämiseen, koska se ei liity jonkin tehtävän tietojen näyttämiseen. 5.1.5 Uuden tehtävätyypin lisääminen Tämä siirrettävä laatijan käyttötapaukseksi. Laine huomauttaa että yleensä tehtävätyyppiä aletaan ohjelmoimaan sen jälkeen kun tietokannan data on määritelty. Hän myös kysyy miten tehtävätyyppiä voi testata. Joko tehtävätyyppi pitää asentaa testausta varten tai sitten on oltava jonkinlainen testialusta. Koko koodia ei voida vaatia kerralla, se on muutettava käyttötapauksesta. Tapahtumien kulku on väärä, kantaan laitettava data on määriteltävä ensin, joko koodia analysoimalla tai erillisestä tiedostosta. Dokumenttiin voitaisiin kirjata nämä vaihtoehdot. Myös tietokannan rakenteesta on syytä kirjata jotain, kuten siitäkin, luetellaanko pelkästään datan nimi vai myös tietotyyppi ja mahdollista muuta tietoa datasta. Dokumenttiin lisättävä käyttötapauksiksi myös tehtävätyypin muokkaaminen ja poistaminen. 5.2.1 Tehtävien selailu Ennakkoehto: opiskelijan on oltava kirjautuneena järjestelmään ja kyseiselle kurssille. Laine sanoo, että selailu ei ole oikein sopiva nimi tälle käyttötapaukselle, koska tehtävään on aina mahdollisuus myös vastata samalla ja aina katsottavaa tehtävää ei voi edes itse valita. Aina kun tehtävää katsotaan ensimmäisen kerran, tehdään arvottavien osien arvonta, joka säilyy jatkossa. Laine sanoo ettei tarvitse toteuttaa sitä että tehtäviin vastaamisen voisi jättää kesken ja jatkaa myöhemmin, vaan voidaan olettaa että kaikkiin tehtäviin vastataan kerralla. 5.2.2 Tehtävään vastaaminen Ennakkoehto: oikeus tehtävään 6 Ohjelmiston vaatimukset Passiivi, "oppilas" vaihdetaan "opiskelijaksi" koko luvussa 6.1.2 Opiskelija voi pyytää uudelleenarvontaa, mutta tämä mahdollisuus on oltava tehtäväkohtaisesti estettävissä (vaatimus ei välttämätön). 6.1.5 Javascript-tuki Laine pyytää prioriteettia korotettavan ykköseksi, yleensäkin vaatimuksena dynaamiset tehtävät. Halko suosittelee tyypin muuttamista ei-toiminnalliseksi. 6.1.6 Avustustoiminnot Oikea muoto "...näiden ohjeiden näyttämistä", ei näyttäminen. 6.1.9 Geneerinen tehtävätyyppi Passiivi. eAssari-viittaus pois kokonaan. 6.1.10 Tehtävätyyppikohtainen tyyppimäärittely Oikea muoto "tehtävätyyppiin", ei tehtävään. 6.2 Käyttöympäristövaatimukset Laine pyytää, että järjestelmä noudattaa SQL-standardia, jotta kantaa on helppo vaihtaa. Oikea muoto "eMo-järjestelmä", ei -ohjelmisto Oikea muoto (luultavasti) "Mozilla Firefox - ja Internet Explorer -selaimilla", yhdysviivat. 6.3 Käyttäjävaatimukset Nyt puhutaan opettajista, mutta vaihdettava rooli sopvissa kohdin laatijaksi. 6.3.1 Uuden tehtävätyypin lisäys Vain lopun yläluokka-asia itse vaatimusta, muu kuuluu johdantoon. 6.3.3 Selkeä käyttöliittymä lisäykselle Vaihdetaan prioriteetti ykköseksi. Oikea muoto "hakemistopuusta", yhdyssana 6.3.6 Eri käyttäjäryhmät Hyödynnetään Moodlen ryhmiä, ei tehdä omia. Tehtävätyypin liittämiseen luotava jokin erityisoikeus 6.3.7 Halko haluaa, että "kurssien omiin tarpeisiin" -kohta poistetaan. 6.3.8 Käyttöohje Vastaamisohjeet jätetään tehtävän tekijän asiaksi. Tyypin tekijä antakoon myös joitain ohjeita. Opettajan ei ole tarpeen antaa ohjeita yksittäiseen tehtävään, sen sijaan yleinen kuvaus voi olla. 6.3.9 Tehtävään vastaaminen Varauduttava tehtäviin, joissa useampi kuin yksi vastauskenttä. Mietittävä miten sellaiset tallennetaan. Laine kertoo, että eAssarissa vastaukset pakataan yhdeksi kentäksi ja puretaan jälleen näytettäessä. Hänen mielestään lomakkeiden ominaisuuksista ei kannata sallia aivan kaikkia (esim. tiedostojen uploadaus). 6.4 Kurssilla toteutettava tehtävätyyppi Passiivi. 7.1 Käyttöönotto Halko pyytää, että aikataulu ja hyväksyttäminen laitetaan projektisuunnitelmaan, ei tänne. 7.2.1 Siirtäminen uuteen ympäristöön Passiivi. 7.2.3 Selainmuutoksey "Dramaattisesti" poistetaan. Tuotetaan samanlaista HTML:ää kuten Moodlekin. c) Korjausten toteuttaminen Uutta katselmusta ei järjestetä, korjattu versio lähetetään asiakkaalle, joka hyväksyy dokumentin. Katainen tekee korjaukset. 4. Suunnittelun edistyminen Suunnittelua tullaan edistämään, Laine tahtoo olla mukana myös siinä. Muut paitsi Katainen alkavat tehdä suunnittelutyötä. 5. Muita esille tulleita asioita Ei muuta. 6. Seuraavasta kokouksesta sopiminen Ajankohta: MA 9.10.2006 kello 16-18 Paikka: ? Puheenjohtaja: Ville-Pekka Vainio Sihteeri: Juho Järviniitty 7. Kokouksen päätös Puheenjohtaja päätti kokouksen klo 14.02