Projektin arvostelusta
Tällä sivulla pyritään kirjoittamaan auki joitakin arvosteluperusteita, joita assistentit käyttävät tutustuessaan työhösi. Voit käyttää näitä ohjeita pohtiessasi onko omassa työssäsi kenties jotakin jota voit halutessasi vielä parannella.
Loppuesittelystä
Valmiin työn esittelytilaisuudessa selvitetään, mitä ohjelma tekee ja ei tee. Esittelytilaisuuden aluksi opiskelija kääntää ohjelmansa, jonka jälkeen joko opiskelija esittelee tai assari itse kokeilee ohjelman ominaisuuksia. Assari voi esittää kysymyksiä ohjelman toteutuksesta ja pyrkiä löytämään mahdollisia puutteita toiminnallisuudessa. Assari ja opiskelija käyvät myös ohjelmadokumentin nopeasti läpi.
Projektin arvostelu
Arvostelun kohteet
Projektityön loppuarvostelu perustuu seuraaviin lähteisiin:
- dokumentti
- ohjelmakoodi
- projektisuunnitelma
- esittelytilaisuus
Kaksi ensimmäistä ovat on näistä tärkeimmät.
Arvosteluperusteet
Helpon projektityön oletusarvosana on kaksi, keskivaikean kolme ja vaativamman neljä. Arvosana annetaan haarukassa [ 0 - (oletusarvosana + 1) ], mutta tämänkin maksimin voi perustellusti joskus ylittää. Oletusarvosana annetaan, kun työ täyttää pääpiirteissään tehtävänannon vaatimukset, eikä siinä ole kovin lukuisia puutteita, mutta ei erityisiä ansioitakaan. Arvosanaa voidaan nostaa tai laskea seuraavien kriteerien perusteella. Mikäli työssa on selvästi enemmän hyviä ominaisuuksia kuin huonoja, nostetaan arvosanaa yhdellä pisteellä. Vastaavasti, jos työssä on selvästi enemmän huonoja ominaisuuksia kuin hyviä, tai jokin osa-alue on erittäin heikko, lasketaan arvosanaa yhdellä (tai pahemmissa tapauksissa useammallakin pisteellä).
Huom: Näitä kriteereitä painotetaan projektiaiheesta riippuvassa järjestyksessä (esim. tietyissä aiheissa hyvä käyttöliittymä on keskeisen tärkeä ja toisissa taas hyvin valitut, tehokkaat tietorakenteet). Tarkoitus on että painotukset ovat samat kaikille saman aiheen valinneille opiskelijoille.
| Kriteeri | Hyvä, jos... | Huono, jos... |
|---|---|---|
| Dokumentin yleislaatu Dokumenttia ja koodia tulisi mielellään katsella yhdessä. Tämän vuoksi dokumentille ja koodille ei voi määritellä projektissa erillisiä painoja. | Dokumentti on kirjoitettu selkeästi ja siinä on esitetty vaaditut asiat perusteellisesti. Lukijalle syntyy selkeä kuva siitä, mitä ohjelma tekee ja miten, ja pelkästään dokumenttiin tutustuminen riittää ohjelman ymmärtämiseen. Ohjelman käyttämät algoritmit (matematiikka, tekoäly tms.) on selostettu ensin ideatasolla, ennen kuin myöhemmissä luvuissa puututaan siihen, miten ne toteutetaan ohjelmaksi. Ohjelman rakenteen kuvaamisessa on käytetty selkeyttäviä kaavioita. Ote dokumentointiin on "ammattimaisen laadukas". | Dokumentti on suurpiirteinen tai suorastaan puutteellinen. Erityisesti ohjelman toimintaperiaatteita ja rakennetta ei ole selvitetty riittävästi. Algoritmien ja toteutuksen välistä eroa ei ole ymmärretty. Kieliasussa on selviä puutteita. |
| Ratkaisujen perustelut | Dokumentti perustelee tehdyt ratkaisut niin algoritmien ja tietorakenteiden kuin ohjelmaan toteutettujen ominaisuuksien kohdalla hyvin, tarkastellen myös vaihtoehtoja, joihin ei päädytty. Perustelut ovat "myyviä": lukija tulee vakuuttuneeksi niiden hyvyydestä (lähinnä siis kuitenkin perustelujen laadun eikä kosiskelevan sanahelinän voimasta). | Perusteet ovat hataria, eikä vaihtoehtoja ole pohdittu. Projektisuunnitelmassa esitettyjä asioita on muutettu ilman mainintaa ja perustelua. |
| Koodin yleislaatu | Koodi on kirjoitettu selkeästi, erinomaisella tyylillä, ja sitä on helppo lukea. Kommentteja on käytetty koodissa riittävästi ja hyvin. Perusohjelmointitekniikka on kiitettävää, eli muuttujia, vakioita, metodeita yms. käytetään asiantuntevasti. Ohjelmassa on käytetty apumetodeita, yksityisiäkin, tehtävien pilkkomiseen, kun siitä on hyötyä. Jne. Jne. | Koodi on vaikeaselkoista, eikä noudata johdonmukaista, hyvää tyyliä. Koodissa on toisteisuutta, eli samaa tai samantapaista koodinpätkää toistetaan joko peräkkäin tai eri puolilla ohjelmaa, kun olisi tullut käyttää metodia, muuttujaa ja/tai silmukkaa. Muuttujia on käytetty holtittomasti. Koodi on kenties selvästi kyhätty harjoitusten/esimerkkien perusteella ilman todellista ymmärrystä siitä mitä ollaan tekemässä. Käytetään "maagisia lukuja" eikä vakioita. Metodit ovat suuria, App-luokkaan tms. on tungettu liikaa tavaraa. Jne. Jne. |
| Ohjelman rakenne | Ohjelman osakokonaisuudet on valittu hyvin ja ne muodostavat selkeitä, itsenäisiä, keskenään hyvin määriteltyjen rajapintojen kautta kommunikoivia komponentteja. Erilaisia toteutusvaihtoehtoja on helposti otettavissa käyttöön myöhemmin, ja laajennettavuusmahdollisuudet ovat hyvät. Algoritmit, tietorakenteet, käyttöliittymä (jne.) on eroteltu toisistaan. Tietoabstraktion idea on ymmärretty ja sitä on sovellettu. Perintää ja piirreluokkia on käytetty osaavasti. Jne. Näiden asioiden osaamisesta voi saa usein reilusti plussaa. | Ohjelman rakenne on kelvoton, luokkia ja olioita on käytetty osaamattomasti. Luokat eivät muodosta järkevästi jaettuja ohjelmamoduuleita. Ohjelman muokattavuus ja laajennettavuus ovat heikkoja. Jonkinlainen pyrkimys - vaikka sitten valinnat olisivatkin hieman huonoja - olioiden käyttöön kapseloinnin toteuttamiseksi tulisi kuitenkin olla havaittavissa, ja luokkien toteutuksen ja ulkoisten rajapintojen välinen ero olisi ymmärrettävä. Julkisia ja yksityisiä muuttujia/metodeja on osattava käyttää järkevästi, ja näkyvyydet on eksplisiittisesti määriteltävä. Oletusarvoiselle näkyvyydelle (julkinen) määritellyt muuttujat eivät siis kelpaa, ellei näkyvyyden käyttö ole jotenkin perusteltavissa. (erityisesti var-muuttujat) Samoin liiallisten kenttien käyttöä on osattava välttää - kaikenmoisen sekalaisen tavaran (jonka voisi hyvin määritellä metodien sisäisiksi apumuuttujiksi) sijoittaminen kentiksi voi näkyä arvosanassa. |
|
Projektisuunnitelmassa on pohdittu asioita ansiokkaasti ja huolellisesti. Tehdyt ratkaisut on perusteltu hyvin. | Suunnitelman sisältö on puutteellinen tai pohdinta pinnallista ("valitsin tämän menettelyn koska se on hyvä"). |
| Toteutusvalinnat | Valitut algoritmit ja tietorakenteet ovat tarkoitukseen sopivia ja suhteellisen tehokkaita. Dynaamisten tietorakenteiden käyttö on myös plussaa (ellei sitä erikseen tehtävässä vaadittu). Ohjelman toteutuksessa on käytetty jotain edistynyttä ohjelmoinnillista piirrettä (jota ei vaadittu tehtävänannossa), esim. ohjelmasäikeitä. | Tietorakenteet ja/tai algoritmit ovat epäkäytännöllisiä tai tehottomia. Tämä huomioidaan miinuksena ensisijaisesti vain vaativammissa töissä, ellei helpon työn toteutus nimenomaan vaadi tehokkuutta tai tehty valinta ole poikkeuksellisen huono. |
| Testaus | Yksikkötestausta on tänä vuonna harjoiteltu siinä määrin että jokaisen opiskelijan pitäisi pystyä testaamaan ainakin joitakin osia ohjelmasta. Koko ohjelmaa ei yksikkötesteillä tarvitse kattaa vaan ehkä muutama keskeinen osanen. Testien pitää kuitenkin olla järkeviä jotta ne otettaisiin positiivisesti huomioon arvostelussa. Jotkin aiheet voivat olla vaikeita testata, mutta kaikista löytynee jokin osa jolla esitellä taitojaan. Järjestelmätestauksesta riittää dokumentissa kuvaus siitä kuinka ohjelmaa opn testattu käyttöliittymän kautta ja millaisella testillä voi vakuuttua siitä että ohjelma toimii oikein. | Koska testaus oli pyydetty kuvaamaan suunnitelman molemmissa osissa, lähes täysin puuttuva tai heikko testaus lasketaan miinukseksi ylemmän tason töissä. Helpoissakin töissä tulee olla jonkin ominaisuuden jonkintasoista testausta. |
| Aiheen vaikeus | Projektiaihe on vaikea verrattuna muihin saman kategorian aiheisiin. | Projektiaihe on helppo verrattuna muihin saman kategorian aiheisiin. |
| Toiminnallisuus | Ohjelmaan on toteutettu tehtävänannon minimivaatimusten lisäksi mielekkäitä ja luovia lisäominaisuuksia tai perustoimintojen laatua on parannettu. Lisäominaisuuksista palkitaan vain jos projektityö on muuten hyvä - ei jos niiden tekemisen kustannuksella kärsii ohjelman muu laatu. | Ohjelman toimintovalikoimassa tai toimintojen laadussa esiintyy pieniä puutteita tehtävänantoon nähden. (Mikäli puutteet ovat suuria, työ hylätään tai annetaan bumerangi.) |
| Käyttöliittymä käyttöliittymäsuunnitelua ei opeteta kurssilla, joten käyttöliittymää ei saa arvostelussa painottaa liikaa. | Ohjelman käyttöliittymä on helposti ymmärrettävä ja luonnollinen. Ellei kyseessä ole luonnostaan hyvin monimutkainen ohjelma, ei käyttäjä tarvitse mitään erillistä opasta tai opastusta ohjelmaa käyttääkseen. Ohjelma neuvoo käyttäjää ajettaessa. | Ohjelman käyttö on vaikeasti ymmärrettävää tai turhan monimutkaista. Ohjelman käyttämiseksi täytyy esim. tietää mitä arvoja/tekstejä sille täytyy missäkin tilanteessa syöttää, ilman että näitä selostetaan ohjelman ajon aikana. Käyttäjä joutuu tekemään jotakin monimutkaista saavuttaakseen päämääränsä. Käyttöliittymän opasteet/merkinnät/kuvakkeet ovat harhaanjohtavia, eli käyttäjä saattaa helposti päätyä tekemään jotain muuta kuin mitä tarkoitti. |
| 3 parasta ja 3 heikointa kohtaa Näiden kohtien tarkoitus on varmistaa etteivät hienoimmat tekemäsi kohdat jää vahingossa assarilta huomaamatta ja vastaavasti että olet itse tietoinen mitkä osat eivät ole niin hyviä kuin olisit halunnut. (siis toimivat mutta eivät kokonaan puutu tai ole pahasti rikki) | Assarin arvostellessa ohjelmaa hän katsoo aina esiinnostamasi 3 parasta kohtaa kun pohtii eri arvostelukohtien plussia. | Assarin arvostellessa ohjelmaa ja pohtiessaan sen heikkouksia, hän katsoo mitä kohtia opiskelija itse pitää ohjelman heikkouksina. Tunnetuista heikkouksista ei sakoteta yhtä raskaasti kuin tiedostamattomista, jollei kyseessä ole ohjelman keskeisin logiikka. |
| Dokumentti : Tunnetut puutteet "Rehellisyys palkitaan" - tämä ei ole sama asia kuin yllämainittu heikko kohta, vaan todellinen puute. | Tunnetusta puutteesta (mahdollisesti korjausehdotuksineen) ei sakoteta yhtä raskaasti kuin puutteesta jonka assistentti löytää työtä tutkiessaan. | |
| Virhetilanteet | Ohjelma selviytyy erilaisista ajon aikana syntyvistä erikoistapauksista, kuten virheellisistä syötteistä, kaatumatta, ja reagoi niihin jollain mielekkäällä tavalla. Tämä luetaan plussaksi lähinnä helpoissa töissä. | Ohjelma kaatuu "satunnaisesti" tai tietyllä syötteellä. Tämä luetaan miinukseksi erityisesti keskivaikeissa ja vaativissa töissä, joissa tällaisia tilanteita ei saisi päästä syntymään. |
Työ hylätään tai sille annetaan bumerangi, mikäli sille pätee jokin seuraavista:
- Ohjelma ei tee sitä mitä tehtävänanto vaatii. Pienet puutteet voidaan hyväksyä, mutta suurista seuraa bumerangi tai hylkääminen.
- Dokumentissa ei ole esitetty vaadittuja asioita. Tässäkin pienet puutteet hyväksytään. Työtä ei yleensä hylätä, mikäli jotakin asiaa on aidosti yritetty selittää dokumentissa (esim. perustella jotakin tehtyä toteutusvalintaa), mutta selitys on hyvin huono (tämä tietysti kuitenkin vaikuttaa arvosanaan). Erityisesti jos ohjelman rakennetta kuvaava dokumentin luku on täysin kelvoton, määrätään työ korjattavaksi ja palautettavaksi "bumerangina".
- Ohjelmakoodi on niin sotkuista, ettei sitä ole mahdollista järkevällä vaivannäöllä tarkastaa.
- Dokumentti on niin epäselvä, ettei sitä ole mahdollista järkevällä vaivannäöllä lukea.
- Ohjelmakoodi on toteutettu kelvottomalla tavalla,
- Työ havaitaan prujatuksi - tämä johtaa aina jatkotoimenpiteisiin.
- On merkittävällä tavalla toimittu jotenkin muuten vastoin annettuja ohjeita.
Nämä suuret puutteet pyritään havaitsemaan jo esittelytilaisuudessa. Hylätyn työn tekijälle saa antaa hieman (muutama päivä) lisäaikaa parannella projektiaan.