1

Projektijuhtimine tarkvaraarenduses

Teema 6:Ainekursuse lõputeemad

Peeter Normak

2

Kava

1.  Kodutöö analüüs

2.  Projektitaotlustele soovituste koostamine

3.  Projektitaotluste retsenseerimine

4.  Üliõpilaste tõstatatud täiendavad küsimused

5.  Eksamitööde koostamine ja esitlemine.

6.  Reflektsioon ainekursusele.

3

Kodutöö

4

Kodutöö

1.  Veebiallikate põhjal leia IKT-alaseid müüte.

2.  Sõnasta kolm tarkusetera, mida õppisite artiklist “Why Software Fails” (http://spectrum.ieee.org/computing/software/why-software-fails/).

3.  Sõnasta kolm tarkusetera, mida õppisite NASA SEL kogemusest (http://www.cs.umd.edu/~basili/publications/proceedings/P94.pdf)?

4.  Sõnasta individuaalse tarkvaraprotsessi PSP (Personal Software Process) põhiseisukohad.

5

Kodutöö

5.  Loe läbi loengukonspekti alajaotuses 8.8 (lk 139) esitatud ülesannetes viidatud Mark C. Paulk koostatud CMM ja XP ning ISO9001 vahekorda käsitlevad artiklid. Mida nendest õppisid?

6.  (Kandus üle) Loe läbi Project risk management peatükk raamatust “Head First PMP” (https://sitimukaromah4.files.wordpress.com/2010/03/head-first-pmp.pdf, lk 507-566) ja sõnasta kolm leitud suurimat tarkusetera, mida oma projektis peaks arvestama.

6

Projektitaotlustele soovituste kirjutamine

7

Projektide soovitused Eesmärk: saada autoriteetselt isikult seisukoht projekti kavandatava

tulemi vajalikkuse kohta (projekti tulemi kasutaja seisukohalt).

Soovitajate valiku soovituslikud põhimõtted:!  oma ala tunnustatud isik!  vältida huvide konflikti (projekti täitva institutsiooni juht on aktsepteeritud)‏!  otsustajate poolt arvestatav isik.

Soovituse sisu saab üldjuhul projektimeeskonnale teada. N: KN Cambridge

Mõnikord on soovitused vormikohased ja/või peavad käsitlema muuhulgas mingeid kindlaid apekte (näiteks andma hinnangu taotleja pädevusele).

Probleem: soovitused kipuvad olema formaalsed ja ei täida täiel määral oma eesmärki. N: TH

8

Soovitused (soovituste koostamine)

Soovitus peaks:!  olema tekstiliselt konkreetne ja asjalik (st mitte liiga

üldsõnaline)‏,!  sisaldama olulist teavet ja olema põhjendatud (st mitte

olema formaalne)‏,!  kirjeldama projekti tulemi võimalikke rakendusvõimalusi.

9

Projektitaotluste retsenseerimine

10

Projektide retsenseerimine

Eesmärk: saada hinnang projekti otstarbekuse kohta (tellija seisukohalt, arvestades antud täitjat).

Retsensioonid on otsustajale abivahend, neid võib arvestada või ka mitte arvestada.

Otsustaja peab olema objektiivne ning võimeline hindama retsensiooni adekvaatsust.

Näited:1.  Poliitiline otsus: LEARNMIX.2.  Otsustuskogu mõne liikme huvid: keeletehnoloogia riiklik programm.3.  Ebakompetentne retsensent: õppetegevuse uurimisel ülikoolis

uuritavatelt loa küsimine.

11

Retsensioonid – hinnatavad aspektid

1.  Vastavus tellija prioriteetidele ja tema poolt sätestatud formaalsetele nõuetele.

2.  Projekti tegevuste ja kasutatavate vahendite/metoodikate asjakohasus/otstarbekus. Näide: diskussioon Pärnus

3.  Projekti ajakava reaalsus.

4.  Projektile ressursside – sh eelarve ja täitjate – kavandamise adekvaatsus (NB! Retsensent peab ka kõik viited ja arvutused üle kontrollima).

5.  Projektiga kaasnevad võimalikud ohud/riskid/negatiivsed tagajärjed. N: haridusosakud.

NB! Konkreetsed sõnastused on tellija poolt sageli ette antud.

12

Retsenseerimine (projektijuhi aspekt)

1. Projekti vajaduse põhjendamisel ära ole antud vallas seni teiste poolt saavutatu/tehtu suhtes liiga kriitiline. N: SF artikkel – Anh.

2. Arvesta sellega, et retsensendid on üldjuhul oma ala tippeksperdid ja suurte kogemustega (st mitte bluffida).

3. Arvesta mittepädeva retsensendi võimalusega – teksti arusaadavus ja “sõnade suhupanemine”.

4. Kasuta (näiteks asutusesisest) eelretsenseerimist.

13

Retsenseerimine (retsensendi aspekt)

1.  Ole projekti retsenseerimisel pigem heasoovlik ja konstruktiivne kui kahtlustav ja virisev.

2.  Panusta retsensiooni, kuna retsensiooni kvaliteet on retsensendi imago kujundmise oluline instrument.

3.  Arvesta retsensendi isiku avalikuks tulemise võimalusega.

14

Diskussioon

Millised on soovitamise ja retsenseerimise põhilised erinevused?

15

Üliõpilaste tõstatatud küsimused

16

Eelnevatest õppustest

1.  Kas PR-kulutused võib lisada kulutuste sekka?

2.  Kuidas käituda force majore olukorras (näiteks sisseostetud teenuse täitmine venib)?

3.  Kas projektikonkursid on alati otstarbekad?

4.  Avatud kontori probleem.

5.  Näiteid kõrge riskitasemega projektidest.

6.  Mille poolest erineb teineteisest lühi- ja pikaajalise projekti kavandamine?

7.  Eesti Projektijuhtimise Assotsiatsioon (EPMA; www.epma.ee) tutvustus. Lisaks võib vaadata ka www.projektijuhtimine.ee

17

Eelnevatest õppustest II

8.  Kuidas kaetakse projekti planeerimise kulud (mis ei ole abikõlbulikud)?

9.  Kuidas otsustatakse oodatava tulemuse mõõdikud?

10.  Kuidas edendada Eestis sponsorluse kultuuri?

11.  Kuidas kavandada tööjõu kasutamist, kui projektitaotluste rahastamine on ebakindel?

12.  Kuidas veenduda partneri harjumustes ja suhtumises projekti kui eelnev koostöö puudub.

13.  Miks LeMill , IVA, VIKO ei olnud jätkuvalt edukad? Mis on põhilised probleemid, mida saaks Dippleri puhul vältida?

14.  Näiteid, millised projektid on kõrge riskitasemega.

18

Tänaseks õppuseks

1.  Kas on otstarbeks rakendada CMMI ka väikeste projektide peal või on väikeste projektide tulemuslikkus ja küpsus lihtsamini hinnatav?

2.  Kas tarkvara arhitektuuri ja disaini alal teevad tarkvaraarendajad ka koostööd kunsti erialade inimestega, kes pakuks lisaks süsteemile ka visuaalset toetust (graafiline disain jne)

3.  Millist tarkvaraarendusprotsessi kasutatakse Eestis kõige tihedamini?

4.  Mis põhjustel Eesti tarkvarafirmad ei ole kasutanud enda hindamisel CMM raamistikku ega saavutanud isegi 2. taset?

5.  Millisel tasemel on üleüldse Eesti tarkvarafirmad võrreldes Euroopaga, muu maailmaga?

19

Tänaseks õppuseks II

1.  Projektimeeskond küll ei saa (ei tohiks saada) teada, kes on retsensent, kuid kas nad näevad ise ka retsensiooni ja saavad võimalusel seda kaitsta, kui hindajal peaks tekkima mõningaid kahtlusi näiteks ajagraafiku või inimressursi täituvuse koha pealt.

2.  Kas tarkvara kvaliteedi hindamise ja vigade otsimisega peaks tegelema keegi, kes ei ole projektiga seotud või mõni meeskonna liige (kes võib-olla oma töö vigu enam tähele ei pane)?

3.  Kas TLÜl on häid näiteid erinevate tarkvaraprotsessi metoodikate ja mudelite kasutamise kohta?

4.  Kas tarkvaraprotsessi hindamismeetodeid on võimalik muudetud kujul rakendada ka teistes valdkondades?

20

Diskussioon

Projekti kavandamisel ja täitmisel siiani esinenud olulisemad probleemid

21

Eksamitööde koostamine ja esitlemine

22

Kuupäevad

1.  13. dets – lõputööde esitlemine:•  Projektiplaan•  Projekti täitmise aruanne

2.  18. dets – lõputöö (projektiplaan ja projekti täitmise aruanne) ja reflektsioon saata aadressile peeter.normak@tlu.ee

23

Eksamitöö üldnõuded

1.  Projektiplaanil peab olema lisa, milles on kirjeldatud eraldi iga üliõpilase roll selle koostamisel. Üliõpilaste roll tuleb esitada detailsusega, mis võimaldaks nende eristavat hindamist (suurepärane, väga hea, hea, rahuldav, mitterahuldav).

2.  Nii projektiplaan kui ka projekti täitmise aruanne peaksid täitma akadeemiliste tekstidele esitatavaid üldisi kvaliteedinõudeid: olema korrektse ning selge keelekasutuse, hea vormistuse ja struktuuriga, ei tohiks sisaldada mitteasjakohast teksti jne (vt ka slaidi “Lõpparuande kvaliteediindikaatorid” esitluses “4-projektijuhtimise tugitegevused.ppt”).

24

Projektiplaan – struktuur ja sisu

1.  Struktuuris lähtuda esitluses “2-Projektijuhtimine-kavandamine.pdf” toodud näitest (“Näide – projektiplaani struktuur”) ja võimalike täiendvate aspektide näidisloendist (“Projektiplaan – täiendavad aspektid”).

2.  Ülalmainitud näidetes esitatud struktuuri ei ole ilmtingimata vaja järgida, vaid arvestada konkreetse projekti vajadusi ja iseärasusi.

3.  Eelarve on kohustuslik isegi juhul kui reaalselt mingeid kulutusi ei tehtud. Eelarve peab tuginema vastavate ressursikulude (töömaht, seadmete amortisatsioon, eksperditasud jmt) hinnangule.

4.  Kui projektiplaani mingi osa on ebaproportsionaalselt suur, võib selle (või selle mingi tervikliku osa) vormistada eraldi lisana.

25

Projekti täitmise aruanne - struktuur

1.  Lähtuda esitluse “4-projektijuhtimise tugitegevused.ppt” slaidil “Lõpparuande struktuur (näide)” olevast näitest. Olenevalt projektist, võib projekti täitmise aruande struktuur näites olevast erineda.

2.  Näites olevad lehekülgede arvud on indikatiivsed, st projekti täitmise aruande vastavad osad võivad olla nendest erineva mahuga.

3.  Kui projekti täitmise aruande mingi osa on ebaproportsionaalselt suur, võib selle (või selle mingi tervikliku osa) vormistada eraldi lisana.

26

Projekti täitmise aruanne - sisu

1.  Projekti täitmise aruande oluliseks osaks on hinnangud, mis peaksid tuginema projekti täitmisel saadud kogemuse analüüsile, nagu näiteks:

•  Rakendatud meetodite ja vahendite (sh projektisiseste suhtlemisvahendite) otstarbekus,

•  Olulisemad projekti täitmisel esinenud probleemid, nende tekkimise põhjused ja kasutatud lahendusviisid ning saadud kogemusest tulenevad järeldused,

•  Projekti täitmise kõrvalekalded projektiplaanis kavandatust, selle põhjuste selgitus.

2.  Projekti täitmise aruanne peaks olema arusaadav ka projektis mitteosalenud inimestele ning selle põhjal peab olema võimalik adekvaatselt hinnata projekti edukust.

27

Reflektsioon ainekursusele

28

Reflektsiooni struktuur1.  Ainekursuse ülesehitus:

•  Üldise projektijuhtimise ja IT-projektide juhtimise vahekord,•  Õppejõu esitluste ja üliõpilaste esinemiste vahekord.•  Kodutööde maht (arvestuslikult igaks õppuseks keskmiselt 14 tundi).•  Eksamitöö ja estluse koostamise maht (arvestuslikult kokku 50 tundi).

2.  Ainekursuse sisu:•  Milliseid teemasid oleks võinud käsitleda põhjalikumalt?•  Milliseid teemasid oleks võinud vähem käsitleda?•  Milliseid teemasid oleks võinud teistmoodi käsitleda ja kuidas?•  Ettepanekud näidete käsitlemise osas.

3.  Õppetöö korraldus:•  Diskussioonide maht oleks võinud olla suurem/väiksem/oli paras.•  Ettepanekud õppetöö paremaks korraldamiseks.

29

Esitluse struktuur

1.  Kestvus – 30 minutit:•  Projektiplaan – 10 minutit•  Projekti täitmise aruanne – 10 minutit•  Diskussioon ja hindamine – 10 minutit

2.  Esitlused toimuvad üliõpilaste arvutitelt.

3.  Esitlusel peab sõna võtma iga üliõpilane.

4.  Esitlusel arvestada ka hindamiskriteeriume (vt järgmine slaid).

5.  Hinnang on 10-punktilisel skaalal.

30

Esitluste hindamiskriteeriumid

1.  Projekti eesmärk – aktuaalsus, SMART-nõuete täidetus ...

2.  Projektiplaan – struktuuri asjakohasus ja loogilisus, riskikäsitlus, …

3.  Projekti täitmine – tööjaotus ja -korraldus, esinenud probleemide lahendamine, projekti tulemuslikkus, ...

4.  Esitlus – arusaadavus, huvitavus, visuaalne tase, ...

5.  Diskussioon – küsimuste arv, vastuste ammendavus, ...

6.  Lisaväärtus kuulajale – saadud uue teadmise maht, rakendatavus enda tegevustes, ...

31

Hindekriteeriumid

10 (väljapaistev): perfektne projekt ja selle täitmise aruanne, probleeme pole, erakordselt aktuaalne ja huvitav teema

8 (väga hea): üksikud pisiprobleemid, riskid minimaalsed, teema aktuaalne ja huvitav

6 (rahuldav): üksikud pisipuudused, riskid mõõdukad, teema osaliselt aktuaalne

4 (puudulik): üksikud puudused, projekti eesmärgi saavutatus problemaatiline, esitlus suurte puudujääkidega

2 (äärmiselt nõrk): projektil ja selle täitmise aruandel on suured puudused, projekti eesmärki ei saavutatud, teema ei pakkunud mingit huvi

1 (perspektiivitu): projekt on mittevajalik

32

Järgmine tundPühapäev, 13.detsembril kell 14:00

Teema:Eksamitööde esitlused

33

IKT müüdid

Näide kasutajakogemusest (34 müüti): http://uxmyths.com/

1.  Tarkvaraarendus on programmeerimine. Selle modifikatsioonid:•  tarkvara arendamiseks piisab programmeerimisoskustest),•  koodi valmimisel on 95% projektist täidetud.2.  Tarkvaraprojekti mahu universaalseks mõõdikuks on summaarne

inimkuude arv.3.  Suured arendusmeeskonnad tagavad parema tulemuslikkuse.4.  Head arendusvahendid tagavad kvaliteedi paranemise (“The very

best technology never has as much impact as girlfriend trouble”).5.  Mooduli korduvkasutus vähendab kulutusi.6.  Eakad tarkvaraarendajad on vähem paindlikud ja õppimisvõimelised.7.  Klient teab mida ta soovib.

34

NASA lessons learned (examples)

Lesson 1: Data collection requires a rigorous process and professional staff.

Lesson 8: Having a shared commitment over research and development is vital for success.

Lesson 9: There is a symbiotic relationship between research and practice in software engineering and both activities gain from the interaction.

Lesson 10. Close proximity of researcher to developer aids both.

Lesson 13: It is difficult to make an engineering organization aware of the importance of software engineering to their mission.

35

PSP põhimõtted

1.  Iga arendaja võimekus on individuaalne; enda tegevuse kavandamisel tuleb põhineda enda tegevust kirjeldavatel andmetel.

2.  Tegevus peab põhinema selgelt määratletud ja mõõdetavatel protsessidel.

3.  Iga arendaja peab tundma personaalset vastutust arendatava tarkvara kvaliteedi suhtes.

4.  Tarkvaravead tuleb avastada ja eemaldada võimalikult vara.

5.  Põhitähelepanu tuleb pöörata vigade ennetamisele, mitte nende leidmisele ja parandamisele.

6.  Ülesande õige lahendamine on alati kõige kiirem (ja odavam).

36

Personal Software Process1),2) struktuur

Eesmärk: üksikisiku tarkvara arendamise võimekuse arendamine (kes üldjuhul töötab tarkvaraarendusmeeskonnas).

CMM-SW põhimõtete rakendamine üksikisikule. 3 (sisuliselt 6) taset:

1 (PSP0, PSP0.1): mõõtmisvõimekus (tarkvara maht, ajakulu, vigade arv, ...); analüüsivõimekus (kuidas saadud andmete alusel enda tegevust parandada).

2 (PSP1, PSP1.1): hindamisvõimekus (tarkvara maht, ajakulu, ...); kavandamisvõimekus (andmete ja hinnangute alusel tegevuste ja ajakava koostamine).

3 (PSP2, PSP2.1): silumisvõimekus (vigade avastamine ja eemaldamine); üldistamisvõimekus (üldise protsessimudeli loomine).

1) http://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13751.pdf2) PSP Body of Knowledge vt, http://resources.sei.cmu.edu/asset_files/SpecialReport/

2009_003_001_15029.pdf

.

37

DTI tarkvaraarenduse alane kogemus

1.  Kasutame paindlikku metoodikat (Scrum-sarnane).

2.  Põhiliselt teeme prototüüpe ja väikesemahulisi tarkvaraprojekte.

3.  Suhteliselt väikese püsikoosseisuga arendusmeeskond: analüütik, vanemprogrammeerija, programmeerija (2,0). Iga konkreetse projekti puhul kaasatakse täiendavaid inimesi.

4.  Projektihalduskeskkond – trac (http://trac.edgewall.org). DTI kasutusäide http://trac.htk.tlu.ee/iva2). Teisi näiteid vt aadressidelt

http://htk.tlu.ee/htk/research-and-development/software-products/

http://htk.tlu.ee/htk/research-and-development/projects/

38 Seminar 18. november 2015

39

Uurimisteemad

1.  Õppijate eestikeelsete kirjatekstide automaatne töötlemine ning standardse eestkeelega võedlemine.

2.  Leksikaalsete, morfoloogiliste ja morfo-süntaktiliste muutumispiiride määratlemine.

3.  Keelekasutuse keerukuse ning keeletaseme inikaatorite määramine.

4.  Teise keele järgmise keeletaseme saavutamise võimalikud teed.

5.  Keeletasemete keeletehnoloogiline modelleerimine.

6.  Eestikeelsete kirjatekstide koostamise metoodika.

40

Planned: development of EIC 2.0

1.  Self-learning and text analysing platform: statistics, similarities, groupings, word ordering, faulty text recognition, patterns finding.

2.  Connections to learning environments and speller.

3.  Training materials and exercises preparation and analyse.

4.  Language level analyse, metadata guessing.

5.  Interoperability with other language resources.

Additionally: Further development of software applications that are currently on prototype level – Robust Lemmatizer, Word Order Finder and Cluster Catcher – and integrating them into an interoperable web service for determining and testing the linguistic profile of the language proficiency level, as well for instructing the independent users.