2.aprill 2009 Ivo Mägi, Kaarel Kuddu, Hillar Petersen, Rein Raudjärv · 2009-04-02 · Tagasiside -projektiplaan Plaanid olid märgatavalt paranenud. Mõni tundusid isegi reaalne

Tarkvara projekt

2.aprill 2009

Ivo Mägi, Kaarel Kuddu, Hillar Petersen, Rein Raudjärv

Seminari kava� II iteratsiooni tagasivaade

� Punktiseis

� III iteratsiooni tulemite nõuded� Kasutajajuhend

� Projekti Wiki

2.04.2009 Ivo Mägi, Webmedia AS 2

� Projekti kokkuvõte

� Süsteem ise :)

� Lähtekood*

� Süsteemitestid*

� Ühiktestid*

� Iteratsiooni kokkuvõte*

� Mõnda huvitavat

II.ITERATSIOONI TAGASISIDE


Meeskonna juhtimisest

� Kaks juhti kasutasid ära klauslit mis lubasid meeskonnaliikme enne 2.iteratsiooni lõppu meeskonnast välja arvatavälja arvata

� Mida nad sellega saavutasid?


Trahvidest / muust

� Üks rühm esitas tulemi hilinemisega

� Viis rühma ei ole tulemit SVNis märgendanud

� TRACi ei kasutata (trahve otseselt � TRACi ei kasutata (trahve otseselt selle eest ei määratud, kaotati punkte iteratsiooni plaanist ning süsteemitestidest)


Release / snapshot� Release peab sisaldama installijuhendit, SQL skripte ja rakenduse

faile, mida ei pea enam kompileerima. Enne rakenduse paigaldamist/käivitamist peab vajadusel saama määrata andmebaasiga ühendumise parameetreid jms. Kui rakendusel on eraldi seadistamisliides, siis võib seadistamine toimuda ka pealse paigaldamist (sisuliselt on see paigaldamise osa). Ebanormaalne on aga rakenduse seadistamine muutes rakenduse faile, mille on aga rakenduse seadistamine muutes rakenduse faile, mille Tomcat on lahti pakkinud vms. Kui andmebaasi paigaldamine või seadistamine pole triviaalne, siis on ka selle kohta vaja juhendit.

� Snapshot peab sisaldama vajalikke faile rakenduse uuesti kokku ehitamiseks. Kõik vajalikud teegid peaksid olema kaasas või peaks olema neile koos versiooninumbriga viidatud. Automaatsed testid peaksid olema ehitusskriptist käivitatavad

� Tulemitele kehtivate nõuete halva esitamise tõttu võis installijuhend nõuda ka rakenduse kokku ehitamist.


Tagasiside - projektiplaan

� Plaanid olid märgatavalt paranenud. Mõni tundusid isegi reaalne ☺

� Konkreetse ülesandega peab olema seotud ka keegi konkreetne isik.

� Kui arendaja teeb töö ära, siis tuleb seda ka testida� Kui arendaja teeb töö ära, siis tuleb seda ka testida

� Kui klient annab tagasisidet, siis pärast seda tuleb teha ka täiendusi ja parandusi

� Millal ja mis tingimustel liigub töö järgmisesse faasi (analüüs –> arendus -> testimine)

� III on viimane arendusiteratsioon, miks on juurutus planeeritud vaid mõnel üksikul rühmal?


Tagasiside - iteratsiooni planeerimine

� Seosed ülesannete vahel olid välja toodud ja tundusid ka mõistlikud.

� Kui puudub konkreetne timeline, siis ei taga aga ikkagi miski, et nt arendus saab valmis piisavalt varakult, et jääks aega testimisekspiisavalt varakult, et jääks aega testimiseks

� Töid ei ole planeeritud trac-i, planeerimine ja tööde jaotus on heal juhul doki tasemel


Tagasiside - iteratsiooni kokkuvõte

� Probleemid olid ausalt välja toodud ja töömahtude aruanded dokumenteeritud.

� Järeldustes tahaks näha rohkem isikulisust ja seda, et mida konkreetselt tehakse selle jaoks, et probleem ei korduks. et probleem ei korduks.


Tagasiside - nõuete dokument

� I iteratsiooniga võrreldes märgatav paranemine. Enamikul kõik kasutuslood välja toodud ja piisava detailsusega.

� Mittefunktsionaalsed nõuded võtsid punkte maha kuna ei olnud detailselt ja projektiga maha kuna ei olnud detailselt ja projektiga seotult välja toodud.

� Nõuded prioritiseerimata (ka mittefunktsionaalsed nõuded).


Tagasiside- ainemudel

� Ainemudeli mõttest on aru saadud ja see ka kirja pandud.

� Seos implementatsiooniga 50/50 –süsteemsed objektid või andmemudel süsteemsed objektid või andmemudel vs. Koodi või andmebaasiga seostamata andmete kirjeldus


Tagasiside- prototüüp

� Kõigil peale ühe oli prototüübitud UI-d

� Paaril rühmal oli reaalselt kasutatav rakendus.rakendus.

� Ülejäänutel oli kas ainult JPG, või veebivormid ilma kujunduseta ja vigased või polnud prototüübitud olulist funktsionaalsust


Tagasiside- süsteemitestid

� Tracis tööd testija käest läbi pole käinud, s.t testimist arendusprotsessis reaalselt ei kasutatakasutata

� Mõnel juhul koostatud ülevaatlik dokk, kus on kirjas läbitud testid, see on ka parem kui mitte midagi


Tagasiside-installatsioonijuhend

� Kui rakenduse saab kerge vaevaga tööle, siis 1 punkt.

� Kui rakendust tööle ei saa, siis 0 punktipunkti

� Viis rühma punkte ei saanud ...


Tagasiside - ehitusskriptid

� Kui snapshot, release ja test töötavad, siis 1 punkt.

� Vastasel juhul 0 punkti.

� Kuus rühma punkte ei saanud ...


Tagasiside- kood

� Kui kujundus, autoriseerimine ning sisuline kasutuslugu realiseeritud, siis 3 punkti.

� Kui rakendus läks tööle, kuid sisulist funktsionaalsust polnud realiseeritud või seda polnud võimalik testida, siis sai 1 punkti. polnud võimalik testida, siis sai 1 punkti. Pretensioonina võib esitada testandmed, mille korral rakendus annab mittetriviaalse vastuse.

� Kui rakendust tööle ei saanud, siis 1 punkt (mitte 0 punkti).


Tagasiside- automaatsed testid

� Kui sisuline kasutuslugu testitud ning ehitusskriptist käivitatav, siis 2 punkti.

� Kui testid pole ehitusskriptist � Kui testid pole ehitusskriptist käivitatavad, siis 1-1,5 punkti.

� Kui testid on ainult triviaalsed, siis 1 punkt.


Punktiseis (teor. maksimum 45pt)

25,00

30,00

35,00

Punktid


0,00

5,00

10,00

15,00

20,00

AV EL1 EL2 MK NU1 NU2 PP1 PP2 PP3 SI1 SI2 SK1 SK2 ST

Punktid

Protestide esitamine

� Proteste saate esitada tagasiside põhjal. Tagasiside saavad kõik tänase päeva jooksul kirjalikult

� Protesti esitamise aeg on hiljemalt � Protesti esitamise aeg on hiljemalt järgmisel teisipäeval kell 08:00

� Protest on mingi konkreetse tulemi kohta

� Protest peab olema põhjendatud


PRESENTATSIOONI NÕUDED


Projekti presentatsioon

� Aine lõpus tehtavat projekti presentatsiooni käsitleme kui ülevaadet aines ülevaadet aines tehtust

� Praegune presentatsioon valmistage ette nn. “elevator pitch” stiilis


Presentatsiooni eesmärk

� Veenda riskikapitalisti kolme minutiga oma idee headuses� Mida su toode või teenus teeb?

� Milline on sinu sihtturg / kes on sinu � Milline on sinu sihtturg / kes on sinu klient?

� Kuidas sa oma ideega raha teed?

� Kes on ettevõtte omanikud?

� Kes on sinu konkurendid?

� Mis on sinu konkurentsieelis?


Presentatsiooni eesmärk

� Miks seda riskikapitalisti / ingelinvestorit veenda vaja on?

� Lihtne – teil on oma idee realiseerimise ajaks vorsti alla realiseerimise ajaks vorsti alla leivaraha saada


Presentatsioon: infrastruktuur

� Ei mingeid slaide

� Ei mingeid joonistusi tahvlile

� Teil on kasutada ainult tekst ja kehakeelkehakeel


III ITERATSIOONI TULEMITE NÕUDED


Projekti Wiki� Info kliendi kohta

� Info projekti kohta

� Projekti liikmete nimekiri ja liikmete rollid

� Projektijuhi kontaktandmed

� Juhendid (kood, dokumentatsioon, testid, ...)

� Viited� Kõikide iteratsioonide tulemid (snapshot+release)

� Koodi dokumentatsioon (javadoc, …)

� SVN

� Trac

� Kõik valminud dokumendid

� Kui on näha et Wikit on kasutatud ka rühmasiseseks suhtluseks siis võib saada lisapunkte.


Lõppkasutaja juhend

� Peab olema süsteemi integreeritud

� Peab sisaldama kogu infot mis süsteemi kasutamiseks vajalik on� Peab saama süsteemist “suure pildi”� Peab saama süsteemist “suure pildi”

� Peab andma ebastandardsete ja/võikeeruliste tegevuste sooritamiseks detailset abi

� Kontekstitundlikkus annab lisapunkte


Valmis süsteem

� Mis on oluline?� Tarkvara peab tegema seda mida kasutaja tegelikult vajab

� Tarkvara peab vastama oma spetsifikatsioonile� Hinnataksegi kaheti� Hinnataksegi kaheti

� Valideerimine� Kas tellijale on valminud lahendus kasulik?

� Verifitseerimine� Nõuded vs valmis süsteem

� Kõige olulisem tulem: kolmandik punktidest� Valideerimise punktid tulevad peamiselt kliendilt, küsitluse kaudu


Lähtekood*

� Eelmises tarnes andis 2/3 punktidest fakt et peamist kasutuslugu implementeeriv kood oli olemas ja töötastöötas

� Lõplik kood peab olema� Struktureeritud

� Dokumenteeritud

� Hallatav

� Kvaliteetne

� Peab olema arvestatud tagasisidet


Ühik/kasutajaliidese testid*

� Testidega peab olema kaetud vähemalt põhifunktsionaalsus

� Peavad olema kooskõlas testimisplaanis ettenähtuga testimisplaanis ettenähtuga (coverage %, muud nõuded)

� Arvestatud peab olema hindaja tagasisidega


Süsteemitestid*

� Kehtib sama mis eelmise iteratsiooni kohta

� Arvestatud peab olema tagasisidega


Boonused

“Kõik on võrdsed, kuid mõned on võrdsemad kui teised”

G. Orwell


Boonused

� Igas distsipliinis parimaks osutunud meeskonnas saavad selle distsipliini alla kuuluva(te)s rolli(de)s olnud inimesed lisapunkte� Parim: +5

� Teine koht: +3

� Kolmas koht: +1

� Rollid� Juhtimine

� Analüüs

� Arendus

� Q/A


Boonused: näide� Meeskond X kogub maksimaalsed võimalikud punktid järgmiste tulemite eest� Arhitektuuridokument

� Installatsioonijuhend

� Lähtekood

� Ehitusskriptid� Ehitusskriptid

� Automaatsed testid

� Verifitseerimine

� Meeskonnas on esindatud arhitekt ning arendaja

� Meeskonnale antakse arendusega seotud rollide vahel jagamiseks kolm boonuspunkti, seega nii arhitekti kui arendaja rollis olnud tudengid saavad 2,5 lisapunkti


Eriloengud

� 23.aprillil külalislektor Margus Uudam (Ambient Sound Investments)� Kuidas kaasata riskikapitali

� 7.mail külalislektor Anton Litvinenko� 7.mail külalislektor Anton Litvinenko(Programeter)� Ettevaatust – ta kontrollib teie tööpanust


Tähtaeg: 9.aprill

� “Elevator pitch”


Tähtaeg: 4.mai 2009

� III iteratsiooni tulemite hindamine toimub selleks kuupäevaks esitatud tulemi põhjal

� Valideerimine ja verifitseerimine


� Valideerimine ja verifitseerimine toimub selleks kuupäevaks esitatud tulemi põhjal

� Projekti lõplikuks demonstratsiooniks võite süsteemi edasi arendada

Tähtaeg: 14.mai

� Projekti presentatsioon

� Projekti kokkuvõte

� Allkirjastatud üleandmise-vastuvõtmise aktvastuvõtmise akt


Documents

2.aprill 2009 Ivo Mägi, Kaarel Kuddu, Hillar Petersen, Rein Raudjärv · 2009-04-02 · Tagasiside -projektiplaan Plaanid olid märgatavalt paranenud. Mõni tundusid isegi reaalne