-
Notifications
You must be signed in to change notification settings - Fork 4
Algoritmin toiminta ja kehityssuunnittelua
Versio 13.4.2022
Luodaan sattumanvarainen ryhmäjako, jossa ryhmät mahdollisimman lähellä tavoitekokoa
Suoritetaan ryhmäjaon pisteiden lasku
Toisto 20 * ilmoittautuneiden määrä
Tehdään uusi ryhmäjako vaihtamalla kahden opiskelijan paikkaa sattumanvaraisesti
Suoritetaan ryhmäjaon pisteiden lasku uudelle ryhmäjaolle
Pidetään ryhmäjako, jolla paremmat pisteet
Tulostetaan console.log lopullisen ryhmäjaon pisteet
Palautetaan ryhmäjako
Käydään läpi ryhmä kerrallaan
Käydään läpi ryhmän sisällä kaikki mahdolliset opiskelijaparit
Opiskelijaparin aikataulupisteiden laskenta:
Toistetaan läpi ensimmäisen opiskelijan työajat
Muokataan työajoista tuntikohtaiset
Toistetaan läpi toisen opiskelijan työajat
Muokataan työajoista tuntikohtaiset
Lasketaan läpikäynnin aikana yhteiset tunnit ensimmäisen opiskelijan kanssa.
Palautetaan yhteinen tuntimäärä jaettuna vähemmän tunteja valinneen tunneilla (0-1 pistettä)
Opiskelijaparin kysymyspisteiden laskenta:
Jos jommalla kummalla ei yhtään vastausta palautetaan nolla pistettä
Kysymyksestä saa yhden pisteen jos on löytyy yksi yhteinen vastaus muuten nolla
Palautetaan opiskelijaparin kysymyspisteet (0 tai 1 pistettä per kysymys)
Palautetaan opiskelijaparin pisteet (tuntipisteet ja kysymyspisteet yhteensä)
Palautetaan ryhmän yhteenlasketut pisteet (parien pisteet yhteensä)
Palautetaan ryhmäjaon pisteet (ryhmien pisteet yhteensä)
Huomioita:
- Aikataulupisteiden evaluaattori näyttää monimutkaiselta koska algoritmi käsittelee aikataulut tunneittain vaikka aikataulut ovat tietokannassa niin, että peräkkäisten tuntien rykelmä on aina yhtenä tietueena.
- Repositoriosta löytyvä Pythonilla koodattu algoritmi on nykyistä edeltävä versio, eikä siis käytössä.
Versio 16.3.2022
- Luodaan ensimmäinen ryhmäjako (sattumanvaraisesti?)
- Vaihe 1: Tarkistetaan päteekö valitut pakolliset kriteerit
- Jos ei päde ryhmäjako hylätään ja tehdään uusi
- Vaihe 2: Pisteytetään ryhmäjako valittujen optimointikriteerien avulla.
- Jos ryhmäjako on parempi kuin tähän mennessä tunnetut uusi jako asetetaan kärkipaikalle
- Käydään mahdolliset ryhmäjaot läpi riittävän tehokkaalla menetelmällä, että 100 ilmoittautuneille löytyy hyvä ryhmäjako kohtuullisessa ajassa.
Pakollisia kriteerejä voisi olla, että ryhmän jäsenillä on yksi yhteinen ohjelmointikieli ja että ehdotettu aloitustilaisuus sopii kaikille ryhmän jäsenille.
Voisi pitää riittävänä, että yhden kysymyksen kohdalla voidaan valita 1kpl yhteisiä vastauksia pakolliseksi kriteeriksi. Ohjaajan käyttöliittymässä tämä voisi olla ruksi. Mahdollisesti on erikoistapauksia, jossa halutaan vaatia vähintään kaksi yhteistä vastausta. Käyttöliittymässä tämä olisi numero. Tämä on ehkä vähemmän intuitiivinen, ja on vaikea keksiä oikeasti tilannetta, missä yksi yhteinen vastaus per kysymys ei riittäisi pakollisena kriteerinä.
Ryhmän vähimmäiskoko ja enimmäiskoko voisi myös olla pakollinen kriteeri. Vaihtoehtoisesti valitaan kuten tällä hetkellä ihannekoko, josta sallitaan plusmiinus yksi.
Kun pakollisten kriteerien täyttäviä ryhmäjakoja on enemmän kuin yksi voidaan näiden keskuudesta valita paras optimointikriteerien avulla. Normaalisti tämä on aikatauluun merkittyjen työtuntien optimointia ryhmän kesken.
Aluksi voisi pitää riittävänä, että optimoinnissa käytetään ainoastaan aikataulua. Lisäksi voisi optimoida pakollisiksi kriteerien ulkopuolelle jätettyjen vastausten perusteella, sekä pakollisiksi kriteereiksi valittujen kysymysten ylijäävien vastausten perusteella.
Opettajan käyttöliittymää laajennetaan niin, että ryhmäjakoa laatiessaan voi valita pakolliset kriteerit ja optimointikriteerit. Jos optimointikriteerejä on useita voisi niiden väliset painotukset tehdä säädettäviksi.
Sovellus raportoi opettajalle algoritmin toiminnasta ja saavutetusta ryhmäjaosta kertovia hyödyllisiä tietoa. Mahdollisuus siirtää opiskelijoita manuaalisesti ryhmien välillä säilytetään.
Ryhmiinjakoalgoritmi suunnitellaan toteutettavaksi omana erillisenä palveluna (omassa docker kontissa pyöritettäväksi?). Vanha algoritmi pysyy käytössä niin kauan kuin on tarve.
Uuden algoritmin MVP on tilanne, kun se on parempi kuin vanha algoritmi
- Kokonaisuus, onko ok?
- Pakolliset kriteerit: valittavissa pakolliseksi yksi yhteinen vastaus per kysymys vai löytyykö käyttötilanteita, jossa halutaan enemmän kuin yksi?
- Optimointikriteerit: Mitä parametreja käytetään ja mikä on totetuttamisen tärkeysjärjestys? Aikataulujen mukaan optimointi tärkein?
- Toteutustapa ja tuotantoon vienti. Oma docker kontti vai osa nykyistä palvelua?
Päivitetty 13.4.2022
Algoritmia ei ehditty päivittää suunnitelman mukaiseksi projektin aikana. Muutoksen valmisteluna algoritmi on eriytetty omaan palveluun, omaan docker-konttiin. Palvelu käynnistyy kehitysympäristössä mutta se ei vielä ole toiminnassa, eikä sille ole tehty polkua staging- tai tuotantoympäristöön.