Skip to content

Miniprojekti

Jump to bottom
Juha-Pekka Moilanen edited this page May 14, 2017 · 23 revisions

Ajankohtaista

Johdanto

  • Kurssin viikoilla 3-7 tehdään miniprojekti
  • kurssin läpipääsy edellyttää hyväksyttyä osallistumista miniprojektiin
    • miniprojektiin osallistuminen ei ole välttämätöntä jos täytät työkokemuksen perusteella tapahtuvan Ohjelmistotuotantoprojektin hyväksiluvun edellyttävät kriteerit ks. kohta "Laaja suoritus" sivulta
    • jos "hyväksiluet" miniprojektin työkokemuksella, kerro asiasta välittömästi emailitse
  • Projekti tehdään noin 4-5 hengen ryhmissä
  • Projektissa ohjelmoidaan jonkin verran, pääpaino ei kuitenkaan ole ohjelmoinnissa vaan "prosessin" (tästä lisää myöhemmin) noudattamisessa
  • jokaisen ryhmän jäsenen on tarkoitus tehdä kunkin sprintin aikana töitä noin 4 tuntia projektin eteen
  • ryhmä tekee kussakin sprintissä sen minkä se sprinttiin varatussa ajassa pystyy tekemään, ei enempää eikä vähempää

Ryhmän muodostaminen

  • Ryhmä muodostetaan "spontaanisti", ma 27.3. ja ti 28.3. luennolla tai tulemalla paikalle ke 16.00 saliin C220, to klo 10.00 saliin C220 tai perjantaina klo 11.00 saliin C220
  • Ryhmä keksii itselleen nimen, luo Github-repositorion ja rekisteröi itsensä tänne
  • ryhmä varaa ajan ensimmäiselle asiakastapaamiselle täältä
  • asiakastapaamisia pidetään keskiviikkona, torstaina ja perjantaina
  • HUOM ensimmäisen viikon asiakastapaamiset alkavat tasalta, (ei siis normaaliin tapaan 15 yli) ja tilaisuuksiin ei voi tulla myöhässä
  • kun tulet asiakastapaamiseen, sinun tulee tuntea viikolla 2 käsitellyt termit User story, Product backlog ja Sprint backlog

Työn eteneminen

viikko 3 (27-31.3)

  • ryhmä muodostuu/muodostetaan
  • ryhmät tapaavat asiakkaan (ke-pe)
  • asiakaspalaverin pohjalta ryhmä tekee alustavan product backlogin ja sopii asiakkaan kanssa ensimmäisen sprintin tavoitteesta
  • ryhmä suunnittelee ensimmäisen sprintin ja aloittaa työskentelyn
    • sprintin suunnittelun tuloksena ryhmä tekee sprint backlogin
    • [Mitä pitää olla sprint backlogissa? (ohjeita välineen valitsemiseen)]
  • Muistilista tiimille sprinttiin 1: ks. arvosteluperusteet
  • ryhmät varaavat tapaamisen sprinttien 2-4 asiakastapaamisille

viikko 4 (3-7.4)

Asiakkaan toive sprinttiin 2

  • Toisen sprintin jälkeen tulee ohjelman kyetä tuottamaan bibtex-tiedosto, joka toimii yhteen osoitteessa https://github.com/mluukkai/ohtu2013/blob/master/ohtu-bibtex.zip?raw=true olevan latex-dokumentin kanssa
  • dokumentti "käännetään" suorittamalla komennot pdflatex paper; bibtex paper; pdflatex paper; pdflatex paper
  • tämän jälkeen tiedostossa paper.pdf tulisi kaikkien lähdeviitteiden toimia, eli tiedostosta ei saa löytyä yhtään [?]:tä
  • viitteiden merkkijonotunnisteiden (eli bibtex-itemin ylimmän rivin merkkijonon, mihin artikkelin tekstissä viitataan \cite:llä) ei tarvitse olla samat kuin artikkelissa käyteytyt, niiden tulee mielellään olla käyttelijän vapaasti määrittelemät tai oletusarvoisesti muodostetut
  • luodun bibtex-tiedoston nimen tulee olla valittavissa (esimerkkiprojektissa nimen tulee olla sigproc.bib, aina ei kuitenkaan ole näin)
  • huom: saatat joutua asentamaan fonttipaketin texlive-fonts-recommended, debianpohjaisissa linuxeissa (mm ubuntu) komennolla sudo apt-get install texlive-fonts-recommended

viikko 5 (10-12.4 ja 20-21.4)

  • Sprintin 2 demo ja sprintin 3 suunnittelu
  • Asiakastapaamisten aikataulu
  • HUOM keskiviikon ryhmillä 12.4. ja muilla vasta pääsiäisen jälkeen

viikko 6 (24-28.4)

viikko 7 (2-5.5)

Toteutettava ohjelmisto

  • Asiakkaan visio tuotteesta täällä
  • Vaatimukset sovitaan ja niitä tarkennetaan viikoittaisissa palavereissa

Tekniset ja prosessiin liittyvät vaatimukset

  • Ryhmä laatii yhdessä asiakkaan kanssa Product backlogin
    • Vaatimukset kirjataan backlogiin User story:inä
  • Sprintin suunnittelussa ryhmä sitoutuu toteuttamaan Backlogin kärjessä olevat User storyt
    • jokaisen ryhmäläisen "työaika" on 4 tuntia viikossa
      • työajan ylittävä sankarikoodaus ei ole suositeltavaa, se on jopa kiellettyä
    • ryhmä sitoutuu ainoastaan niihin User storyihin, jotka se kuvittelee kykenevänsä toteuttamaan sprintissä alla olevan Definition of Donen mukaan
  • ryhmä ylläpitää Sprint Backlogia
    • User storyt jaetaan sprintin suunnittelussa teknisen tason tehtäviksi
    • ryhmä tekee päivittäin jäljellä olevan työajan arviointia ja dokumentoi tämän Sprintin Burndown-käyränä
    • Koodi on talletettu GitHub:iin
  • Ryhmä toteuttaa jatkuvaa integraatiota (Continuous Integration)

Missä formaatissa product backlog ja sprint backlog pidetään?

Definition of done

  • User storyille on määriteltävä hyväksymäkriteerit, jotka dokumentoidaan Cucumberin featureiksi
  • Toteututun koodin testikattavuus tulee olla mielellään 100% (rivikattavuus)
  • Asiakas pääsee näkemään koko ajan koodin ja testien tilanteen CI-palvelimelta
  • Koodin ylläpidettävyyden tulee olla mahdollisimman hyvä
    • järkevä nimeäminen
    • järkevä/selkeä ja perusteltu arkkitehtuuri
    • hyvän oliosuunnittelun periaatteita (luennot 7 ja 8) tulee noudattaa

Työn arvostelu

  • Miniprojektista saa maksimissaan 10 kurssipistettä (muut laskarit 10 pistettä ja koe 20 pistettä)
  • sprinteistä 1, 2 on jaossa 2 kurssipistettä, sprintistä 3 ja 4 jaossa 2.5 kurssipistettä
  • ensisijainen arvostelukriteeti on ohjelmaan toteutettujen featureiden laatu, tasainen eteneminen ja prosessin seuraaminen (ks. edellinen luku)
  • ryhmän pisteiden lisäksi jaossa on henkilökohtaiseen suoritukseen perustuva piste, joka voi myös olla negatiivinen (ks tarkemmin täältä), eli passiivinen osallistuminen ryhmään ei tuo automaattisesti samoja pisteitä kuin aktiivisille ryhmäläisille

Täysiin pisteisiin kunkin viikon sprintissä vaaditaan kaikkien Tekniset ja prosessiin liittyvät vaatimukset-kohdassa mainittujen asioiden noudattamista

Tarkemmat sprinteittäiset arvosteluperusteet täällä

Clone this wiki locally