Määritysten tarkentaminen
| Id | Kysymys | Kysymyksen esittäjä | Vastaus | Vastauksen antaja | Kommentit | Asia ratkaistu ( x ) |
|---|---|---|---|---|---|---|
| 1 | Käyttäjätarinat
Mikä on näiden summana oleva toiminnallinen kokonaisuus? Mitä jälkimmäisen ”selailulla” on ajateltu? Onko kyseessä opinto-oppaan selailu, vai haetaanko tässä mahdollisuutta katsoa tarkentavia tietoja eri hakutuloksista ja kenties vertailla niitä vastaavalla tavalla kuin vaihtoehtoisten opintojen vertailussa?
--- Tarkentavat kysymykset 22.9.2014 / LS Asia 1: haun toteuttaminen: koulutushaku http://opendata.metropolia.fi/koulutushaku/ vai kevyempi ratkaisu?
Asia 2: vapaasti valittavien opintojen kohdentaminen käyttöliittymässä oikeaan kohtaan hopsia
Asia 3: vapaasti valittavien opintojen sijoittaminen rakenteessa oikeaan paikkaan
--- Tarjontakorin käsitettä tulee edelleen selkeyttää, samoin käydä yhdessä läpi ops-terminologia muutoinkin, ettei synny väärinymmärryksiä
| Lauri Stigell | Käyttäjätarinassa EH018 on näkemykseni mukaan kyse tilanteesta, jossa opiskelija selaa vapaavalintaisten opintojen "tarjontakorissa" tarjolla olevia opintoja ja mahdollisesti valitsee niistä itselleen sopivia opintoja.Tarjontakorit on luotu siten, että niissä tarjotaan opiskelijalle (=opiskelijan ryhmälle) sopivia/mahdollisia vapaavalintaisia opintoja. Päivitys 18.9.2014: Termiä "tarjontakori" ei tarvitse tuoda opiskelijapuolelle käyttöliittymään, mutta esimerkiksi avoimen amkin puolella halutaan, että valinnat tehdään juurikin tarjontakorin sisältämistä opinnoista eli rajatusta joukosta. --- Huom! Määrityksiä tarkennetaan tämän keskustelun pohjalta sprintin 6 lopussa järjestettävässä tilaisuudessa. Samassa aikaikkunassa on tavoitteena tehdä linjaus, pohjataanko haku koulutushakuun/opintotarjontaan vai tehdäänkö luonnostellun suppeamman haun mukaisesti, vai kenties molemmat vaihtoehdot. / LS 23.9.2014
| TE
TE
| ||
| 2 | Käyttäjätarina
Ymmärrän speksin niin, että hops on luonnos/työstö/suunnitelma-tilassa niin pitkään, kunnes ohjaaja on sen hyväksynyt. Tällöin hyväksyminen tuottaa aikaleimatun, ajatellaan vaikkapa pdf-muotoisen, dokumentin, joka tallentuu esim. Pakin sopimukset-osioon. Olenko ymmärtänyt oikein? Haluatteko, että opiskelija voi jatkaa virallisen hopsin työstämistä tämän jälkeen vapaasti, jolloin hyväksytty on aina se pdf-muotoinen dokumentti ja hops-työkalussa näkyvä hops on aina ”luonnos”, mikäli siihen on tehty yksikin muutos hyväksymisen jälkeen? | Lauri Stigell | Minulla on toiminnosta sama käsitys. | TE | Huom. Toteutus tehtäneen siten, että kaikki hyväksytyt (vanhatkin) versiot palvelussa tarkasteltavissa. | x |
| 3 | Milestoneen 2 (speksin versio 0.5) hopsin versionti on priorisoitu prioriteetilla 1. Käyttötapaukset, joissa versiointia käytetään (EH044 ja EH048), on priorisoitu prioriteetilla 3. Osaisitteko valaista, mikä tämän priorisoinnin takana on? | Lauri Stigell | Luultavammin kyse on priorisointiin putkahtaneesta virheestä. | TE | x | |
| 4 | Speksin versio 0.5:ssa opiskelija haluaa pyytää ohjaajaa hyväksymään hopsin. Kuitenkin mahdolliset työkalut, joilla opiskelija hyväksyntää pyytäisi, tulevat suunnitelmassa vastaan vasta speksin versioissa 1.0 (viestit/ilmoitukset-toiminnallisuus) ja 1.1 (merkinnän tekeminen - opiskelija). Ohjaajapuolella toisaalta merkinnän tekeminen on mukana jo versioissa 1.0 (EH051 ja EH052), mutta käytännössä toiminnallisuutta tarvitaan siis jo tuossa hyväksymisessä (versio 0.5) Ehdottaisin, että tarkennetaan toteutusjärjestystä uusien, perusrekisterin kanssa yhteisten, milestonejen suhteen siten, että tarvittavat pohjatyöt tulee tehtyä varmasti oikeassa järjestyksessä. Samalla ehdottaisin, että projektinhallinnallisista ja viestinnällisistä syistä jättäisimme Pakissa kokonaan pois nuo kilpailutusvaiheen versionumerot ja siirryttäisiin käyttämään ainoastaan termejä milestone 1…4 + v. 1.0 (valmis tuote). | Lauri Stigell | Toteutusjärjestystä ja versionumerointia koskeva ehdotus saa kannatusta minulta. | TE | Huom. Pakki-projektiin lisätty alkuperäisestä kysymyksestä versio 5 versioiden 4 ja 1.0 (valmis tuote) väliin | x |
| 5 | Tarve käydä tarkentava keskustelu käyttäjätarinoiden viesti-/merkintätoiminnallisuuksista ja näiden hyödyntämisestä hopsin hyväksymisprosessissa / roolien välisessä kommunikaatiossa. • tarkennuksia: o Mikä on yhteydenotto o Mikä on viesti o Mikä on kommentti o Mikä on merkintä
| Lauri Stigell | Yksinkertaistaisin asiaa seuraavasti: kun merkintä on liitetty esimerkiksi opintoon ja siihen ei ole liitetty muita toimijoita kuin merkinnän tekijä, voidaan puhua merkinnästä (voidaan tägätä esimerkiksi ilmoitukseksi tai hälytykseksi). Kun merkintään lisätään muita toimijoita, vaikkapa opettajia tai ohjaajia, merkinnän kautta voidaan viestiä, kommentoida tai luodan yhteydenottoja. Toteutus voisi käytännössä olla samantapaionen kuin jo toteutettussa sopimuspankkipalvelussa Pakin puolella. | TE | x | |
| 6 | EH005 Voidaanko toteuttaa siten, että opsin tieto luetaan hopsin pohjaksi - ei siis dumpata koko opsia hopsiin. (Lopputulema sama, mutta toteutuksena yksinkertaisempi) | Lauri Stigell | ok | TE | x | |
| 7 | Tuleeko opiskelijan voida selata muiden kuin omien opiskeluoikeuksiensa opseja rakenteisessa muodossa vai riittääkö listamuoto (vrt. vapaasti valittavien opintojen haku)? Riittääkö muiden kuin omien opsien tarkasteluun rakenteisessa muodossa sähköinen opinto-opas? | Lauri Stigell | Mielestäni listamuoto riittää jos sähköinen (muitahan ei ole enää tarjolla!) opinto-opas on vielä tarvittaessa helposti avattavissa tarkasteltavan opinnon suhteen kohdasta, josta opsin rakenne selviää.. | TE | x | |
| 8 | Pakki-migraatio - mitä tietosisältöjä käsittää? | Lauri Stigell | Kirjataan tänne: Migraatio Winhasta Pakkiin; sovittu, että Metropolia ja TAMK toimittavat tiedot vk 37 testiympäristöihin | Yhteinen palaveri järjestetty, jossa sovittu sisällöt ja vastuut | x | |
| 9 | Aikajanan toteutus - dynaaminen vai staattinen? | Lauri Stigell | Alustavasti keskusteltu 8.8., jolloin todettiin, että sitovasti ei kannata vielä tässä vaiheessa naulata toteutustapaa. Tarkennetaan myöhemmin, kun projektissa edetään sinne saakka | |||
| 10 | Kun ohjaaja hyväksyy opiskelijan hopsia ja painaa “Hyväksy hops”, haluatteko että järjestelmä kysyy “oletko varma”, vai annetaanko suoraan ilmoitus “Hops hyväksytty”? Onko tässä kyse sellaisesta asiasta, joka hyvä varmistaa ns. tuplana? | Lauri Stigell | Pitää varmistaa | TE ja VP | x | |
| 11 | Käyttäjätarinat EH040 ja EH045: ovatko tarpeellisia rooleista ja käyttöoikeuksista alustavasti käytyjen keskustelujen valossa (geneeriset ohjausroolit)? | Lauri Stigell | EH045, tuleeko tilanteista joissa opiskelijalle tulisi antaa mahdollisuus rajat näkyvyyttä vain rajatuille ohjaajille/opettajille? | TE | Tästä on varmastikin hyvä keskustella vielä lisää (LS) | |
| 12 | Mitä termiä tulisi käyttöliittymässä käyttää, kun ohjaaja lähtee antamaan palautetta opiskelijalle hopsin jatkotyöstöön?
| Lauri Stigell | "Kommentoi hopsia" | TE | x | |
| 13 | Mitä tehdään vertailussa oleville opinnoille, kun valinta tehdään modaalissa? Poistetaanko ne vertailukorista vai jätetäänkö sinne? Ensimmäisessä versiossa jätetään, mutta voidaan helposti muuttaa, jos toisin halutaan. | Lauri Stigell | ||||
| 14 | Käyttäjätarinat
Peppiin ei kirjata tällä hetkellä systemaattisesti suuntautumisvaihtoehtoa. Tämä tieto tulisi tallentaa, jotta pakkiin pystytään lukemaan suuntautumisen valitsemisen jälkeen oikea data. Toimittaja ehdottaa, että asiakas merkitsee tiedon systemaattisesti pepin opintopolkupalveluun, ei yksikköpalveluun. | Lauri Stigell | Lisätään pepin opintopolkuun perusrekisterin suuntautumisvaihtoehtokoodisto. Käyttötapauksessa opiskeluoikeudella on joko kaikki suuntautumisvaihtoehdot tai ei yhtään. Tällöin hän voi verrata eri suuntautumisvaihtoehtoja. Mietitään toteuttaessa, kummin kannattaa tehdä. Opiskelijalle näytetään kaikki vaihtoehdot, kunnes hän on valinnan tehnyt. Sen jälkeen vain ao. suvan mukainen. | |||