Skip to content

miniprojekti

Jump to bottom Edit New page
Matti Luukkainen edited this page Apr 15, 2014 · 28 revisions

Ajankohtaista

Johdanto

  • Kurssin viikoilla 3-6 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 sivulta
    • jos “hyväksiluet” miniprojektin työkokemuksella, kerro asiasta välittömästi emailitse
  • Projekti tehdään noin 3-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 24.3. ja ti 25.3. luennolla tai tulemalla paikalle saliin C221:n torstaina 27.3. klo 13 tai perjantaina 28.3. klo 13
  • Ryhmä keksii itselleen nimen, luo Github-repositorion ja rekisteröi itsensä tänne
  • ryhmä varaa ajan asiakastapaamiselle täältä
  • asiakastapaamisia pidetään keskiviikkona, torstaina ja perjantaina
  • kun tulet asiakastapaamiseen, sinun tulee tuntea viikolla 2 käsitellyt termit User story, Product backlog ja Sprint backlog

Työn eteneminen

viikko 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
  • sprintin 1 arvosteluperusteet

viikko 4

  • ryhmät tapaavat asiakkaan (to ja pe)
  • asiakaspalaverin pohjalta ryhmä ajantasaistaa product backlogin ja sopii asiakkaan kanssa toisen sprintin tavoitteesta
  • ryhmä suunnittelee toisen sprintin ja työskentelee sen tavoitteiden saavuttamiseksi
  • 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 bibitex-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

  • ryhmät tapaavat asiakkaan (to ja pe)
  • asiakaspalaverin pohjalta ryhmä ajantasaistaa product backlogin ja sopii asiakkaan kanssa kolmanne sprintin tavoitteesta
  • ryhmä suunnittelee kolmannen sprintin ja työskentelee sen tavoitteiden saavuttamiseksi

viikko 6

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
    • 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), ja asiakkaalla on pääsy CI:n raportteihin
    • CI-palvelimena voi käyttää http://ohtu.jamo.io tai jotain muuta vastaavaa johon asiakkaalla on pääsy, jenkinsin lisäksi erityisesti Web-sovelluksille hyvä vaihtoehto on https://travis-ci.org/
    • ohjelmasta on oltava deployattuna koko ajan stabiili, tuore versio
    • jos kyseessä työpöytäsovellus, voidaan tämä hoitaa tekemällä standalone jar-tiedosto jenkins-sivulle
      ohje sopivan jar:in luomiseen tulee olemaan neljännen viikon laskareissa

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

  • esim. Google Docs -spreadsheetinä, mallia voi ottaa seuraavista:
  • Ryhmä lisää linkit backlogeihin, CI-palvelimelle ja sovelluksen toimivaan versioon (jos sovellus on verkossa) miniprojektin Github-repositorion readmeen

definition of done

  • User storyille on määriteltävä hyväksymäkriteerit, jotka dokumentoidaan easyB:n Storyjen skenaarioiksi
    • jokaista User storyä kohti siis pitää pääsääntöiseti olla oma easyB-story (esitellään viikolla 3)
    • easyB-raportit asiakkaan nähtäville, käytännössä tämä helponinta hoitaa jenkinsin avulla. ks. ohje esim täältä
  • 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ä)
    • sprintit 1 ja 2 max 3 pistettä ja sprintti 3 max 4 pistettä
    • ensisijainen arvostelukriteeti on ohjelmaan toteutettujen featureiden laatu, tasainen eteneminen ja prosessin seuraaminen (ks. edellinen luku)

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

Tarkemmat sprinteittäiset arvosteluperusteet täällä

Add a custom footer
Add a custom sidebar
Clone this wiki locally