You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Projektiryhmä

Aika 22.5.2015 klo 13.30 - 14.30
Paikka Liity Lync-kokoukseen 

Läsnä: 

Muistio

  1. Avaus
  2. Kehityksen tilannekatsaus
  3. Osien luominen ja arviointi - uuden toteutustavan vaikutukset

    Nykytilanne, eli painoarvoilla:

    -   Toteutus ABC-123 Matematiikka 1, 5op

    • osa1 luennot: 3  (= 3op)
    • osa2 harkat: 2  (= 2op)

    Eli tuossa painoarvot ovat käytännössä sama asia kuin opintopisteet, kunhan niitä jakaa opintopisteiden verran osien välillä.

    Ellei noita muokkaa käsin niin ne menevät kaikki painoarvolla 1 eli saman arvoiset, tilanne:

    -   Toteutus ABC-123 Matematiikka 1, 5op

    • osa1 luennot: 1  (= 2,5op)
    • osa2 harkat: 1 (= 2,5op)

    Jos lisätään uusi osa niin tilanne:

    -   Toteutus ABC-123 Matematiikka 1, 5op

    • osa1 luennot: 1  (= 1,67op)
    • osa2 harkat: 1 (= 1,67op)
    • osa3 seminaari: 1 (= 1,67op)

     

    ****

     

    Jos muutetaan että ovat opintopisteitä:

    Ensimmäinen tapaus sama, toisessa tapauksessa 1op + 1op eli ei jaettu kaikkia opintopisteitä. Ja jos on tehty esim ensin:

    -   Toteutus ABC-123 Matematiikka 1, 5op

    • osa1 luennot: 3op
    • osa2 harkat: 2op

    Ja sen jälkeen lisätään uusi osa:

    -   Toteutus ABC-123 Matematiikka 1, 5op

    • osa1 luennot: 3op
    • osa2 harkat: 2op
    • osa3 seminaari: ??

    Tässä tapauksessa joutuu käsin laittamaan jokaisen osan pisteet uusiksi. Ja jokaiselle opiskelijalle.

     

    ***

    Liisähuomio: osat eivät mitenkään liity toisiinsa kun ne on lisätty opiskelijoille (opiskelijan A "luennot" osa ei tiedä mitään opiskelijan B "luennot" osasta). Eli niitä ei tällä hetkellä voi massana muokata  tai poistaakaan (muuta kuin nimen perusteella mikä voi olla vähän riskaabelia?)

    Jos halutaan tukea tuollaisia toimenpiteitä niin osille pitäisi luotaessa tehdä joku sisäinen id jolla tunnistetaan että kaikilla opiskelijoilla sama osa kyseessä. Ja sitten jos tulee uusi opiskelija niin sille voidaan jotenkin jostain valikosta valita että mitä olemassa olevia osia lisätään (tai luodaanko ihan uusi).

    Uuden mallin toteuttaminen vaatii siis lisätyötä ja sillä on vaikutuksia kälin lisäksi tietysti myös raporttipuolelle. 

  4. Järjestelmän kieliversiot
    • Työskentelytavasta sopiminen ja vastuutus
  5. Hopsin migraation tilannekatsaus
  6. Korjausten hallinta

  7. Testi-ikkuna 6 - suunnitelma testauksen läpiviemiseksi
    • Korjauksiin allokoidaan yhteensä n. 10 htp tässä sprintissä; sillä ei ole mahdollista korjata kaikkia osoitettuja korjauskohteita
    • Pakin osalta saadaan korjattua merkittävä osa korjauskohteista
    • Ehdotus:
      • Pakin osalta laaja testaus, koska opiskelijatestaajia hyvin
      • Perusrekisterissä testattaisiin aiempaa suppeammin niitä ominaisuuksia, joihin korjaukset ehditään tehdä + uusia ominaisuuksia
      • Lisäksi staging-testausta jatkettaisiin (ei päästy vielä kunnolla liikenteeseen) eli migraation validointi saataisiin sitä myöden hyvään vaiheeseen
    • Mahdollista on toki testata laajasti myös Perusrekisteriä, mutta se tulee pitkätli tuottamaan samat tulokset niiden ominaisuuksien osalta kuin ennenkin, joihin ei ole korjauksia ehditty tehdä
  8. Muut asiat
  9. Päätös
  • No labels
You must log in to comment.