1

Projektijuhtimine tarkvaraarenduses

Teema 5:Tarkvaraprojektide üld- ja eriküsimused

Peeter Normak

2

15. novembri tunnikava

1.  Kodutöö2.  Tarkvaraprojektide spetsiifika3.  Tarkvaraprojektide üldküsimused:

•  esialgne kavandamine, •  personalivajadus, •  maksumuse hindamine, •  koostöö juhtkonnaga

4.  Tarkvaraprotsessi juhtimise aspektid (muudatuste ja riskide haldamine, kvaliteedikindlustus, arhitektuur, reliis)

5.  Tarkvaraprotsessi alane kogemus.6.  Tarkvaraarenduse mudelid ja metoodikad (koskmudel, iteratiivne

mudel, XP, CMM-SW, CMMI, NASA metoodika, SPICE)

3

Kodutöö

4

Kodutöö

1.  Loe läbi konverentsi “Õppiv organisatsioon – Saksa kogemus, Eesti võimalused” analüüsidokument (leongukonspekt, lisa 7) ning leia vastused järgmistele küsimustele:a)  Millised suurimad probleemid (need on märgitud sümboliga “-”), millega

oleks konverentsi ettevalmistamisel pidanud arvestama (nimeta 3)?b)  Milline olid suurim positiivne kogemus, mida kindlasti arvestate kui ise

konverentsi korraldate (nimeta 3).c)  Mida teeksite teistmoodi?

2.  Sõnasta dokumendi “Projektiaruanne-Idlab-2009-2012.doc” kolm suurimat puudust (adekvaatsus, korrektsus, loetav, strukt, maht).

5

Tarkvaraprojektide spetsiifika

6

Kaasaegse majanduse ja ühiskonna arengusuundumused

Majandusetegevuse struktuur ja sisu muutumine:

1.  Teenuste osakaal võrreldes tootmisega pidevalt kasvab (1970 – 1:1; 2010 – 3:1; http://www.worldbank.org/depweb/beyond/beyondco/beg_09.pdf)Eesti (2011): teenusd – 61%, tööstus – 28,5%, põllumajandus – 3,5%IBM: 1995…2005 – 28% ! 55%.

2.  Teenuste oluliseks vahenduskeskkonnaks on kujunenud Internet.

3.  Teenused arvestavad järjest enam iga kliendi individuaalseid vajadusi (mass customization, co-creation).

7

IKT kui kõiki valdkondi läbiv valdkond

1.  Ettevõtete-organisatsioonide toimimismudelite muutumine:•  tekivad ettevõtete ökosüsteemid (koostoimivad võrgustikud/

klastrid),•  majandusruum globaliseerub,•  järjest enam protsesse standardiseeritakse ja automatiseeritakse.

Arengusuundumuste realiseerumisel on oluline roll IKT vahenditel: •  tootlikkuse kasvust ligikaudu 50% tuleneb IKT vahendite

rakendamisest.•  Euroopa digitaalse ühisruumi realiseerumisel hinnatakse SKT

aastaseks kokkuhoiuks ligikaudu 415 miljardit eurot.

Määravaks on töötajate e-oskused (e-skills).

8

Tarkvaraprojektide spetsiifika – kõrge ebaõnnestumise määr

Edukad Probleemsed Ebaõnnestunud1994 16 53 311996 27 33 401998 26 46 282000 28 49 232004 29 53 182006 35 46 192009 32 44 24

2012-koskm 14 57 292012-paindl 42 49 9

Standish Group analüüsid (andmed on protsentides):

9

Diskussioon

Millised on tarkvarale esitatavad üldnõuded, mis teeb tarkvaraprojektide täitmise keeruliseks ja põhjustab

nende ebaõnnestumise suhteliselt suure määra?

10

Tarkvarale esitatavad üldnõuded

Tarkvara peaks: •  üldjuhul toimima erinevatel platvormidel ja erineva riistvara korral, •  olema muu tarkvaraga koostoimevõimeline, •  vastama laia (ja reeglina mittehomogeense!) kasutajaskonna

vajadustele, •  olema kergesti kohandatav spetsiifilistele vajadustele vastavaks

(näiteks seadusandlusele, asutuse regulatsioonidele või kasutatavate tehnoloogiatele/metoodikatele)

Tarkvaraprojekti spetsiifika tuleneb tulemile – väljatöötatvale tarkvarale – esitatavatest üldnõuetest

11

Üldnõuetest tulenevad erinõuded tarkvarale

Tarkvara peab:

•  olema kooskõlas asjakohaste standarditega,

•  olema visuaalselt (graafiline disain) ja loogiliselt (kasutatavus) optimeeritud, kooskõlaline kasutajate käitumismustritega,

•  olema kergesti laiendatav,

•  toetama rakendusvaldkonna põhiprotsesse,

•  olema võimeline adekvaatselt reageerima tahtlikele (näiteks ründed) ja tahtmatutele (näiteks voolukatkestus) häiretele.

12

Tarkvaraprojekti spetsiifika - süsteemsusTarkvaraprojektide arendamisel muutusid teatud ühtsed alused ja sellest tulenev süsteemsus eriti kriitiliseks seoses lokaalsete ja globaalsete arvutivõrkude massilise kasutuselevõtuga 1980-ndatel ja 1990-ndatel aastatel.

Tegevussuunad: 1.  Arendusprotsessi süstemaatiline analüüs ning arendusmetoodikate ja –

vahendite loomine, aga samuti tarkvaratehnika meetodite arendamine. 2.  IKT-alaste standardite ja spetsifikatsioonide loomine. 3.  Erinevate raamistike (näiteks SWEBOK) ja küpsusmudelite (näiteks CMM-

SW) loomine . 4.  Õppekava-alaste soovituste väljatöötamine. 5.  IKT-pädevuste alaste sertifikaatide ja sertfitseerimisasutuste massiline

loomine. 6.  IKT (projekti)juhtimise professionaliseerumine.

13

Näide – Euroopa poliitikaid

1.  DIGITALEUROPE’s Vision 2020 (http://www.digitaleurope.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=157&PortalId=0&TabId=353).

2.  Digital Agenda for Europe (https://ec.europa.eu/digital-agenda/en/digital-agenda-europe-2020-strategy).

3.  A Digital Single Market Strategy for Europe (http://ec.europa.eu/priorities/digital-single-market/docs/dsm-communication_en.pdf).

4.  Future-proofing eGovernment for a Digital Single Market.

5.  Opening up Education: Innovative teaching for all through new Technologies and Open Educational Resources (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52013DC0654&from=EN).

14

Tarkvaraprojektide edu kriitilised faktorid

Fundamentaalne: optimeerida (minimeerida) tarkvara ümbertegemise osakaal.

Selleks on oluline, et projekti tegevused oleksid kavandatud äärmiselt läbimõeldult (eriti projekti algfaasis, mil võetakse vastu kõige kaalukamad otsused). Esimese 10% indikaator.

Tarkvaraprojektide teised edu olulisimad mõjurid: •  skoop (tarkvaranõuded) •  ressursid Näide: Dippler

NB! Natuke rohkem protsessijuhtimist projekti algfaasis hoiab projekti lõppfaasis kokku võrratult rohkem aega vigade paranduselt; probleemid tuleb lahendada koheselt peale nende tekkimist.

15

Tarkvaraprojekti kriitilised edufaktorid

Tarkvaraprojekti kriitilised edufaktorid tulenevad tarkvarale esitatavatest üld- ja erinõuetest (vt ka konspekti lisa 6).

Kriitilisi edufaktoreid: 1.  Kasutajate kaasamine kogu projekti jooksul. 2.  Muudatuste efektiivne juhtimine. 3.  Kvaliteedikindlustus ja probleemitundlikkus. NB! Vigade parandamist

mitte edasi lükata. 4.  Komponentide õigeaegne integreerimine. 5.  Ajagraafiku vajadustele vastav korrigeerimine. 6.  Sobiva arendusprotsessi mudeli määratlemine/kujundamine ja

järgimine. 7.  Juhtkonna toe tagamine.

16

Tarkvaraprojekti kavandamine

17

Kolm põhiküsimust (arendaja vaade)

Projekti planeerimise kulud on üldjuhul 5-10% projekti maksumusest.

Enne projektikonkursil osalemise otsustamist tuleb saada selgus järgmistes küsimustes:

•  Võidame projektikonkursi, kuna … (võimaldab rõhuda tugevustele),

•  Kui me kaotame, siis selle põhjuseks on … (võimaldab elimineerida võimalike kaotuste põhjuseid),

•  Taotlemise kolm põhilist riski on … (võimaldab vähendada riske).

18

Diskussioon

Milliseid aspekte tuleks eelkõige arvestada projektikonkursil osalemise otsustamisel?

19

Projektikonkursil osaluse otsustamine (Smith, 2001)

1.  Nõuete selgus ja konkreetsus. 2.  Kooskõlalisus taotleja strateegiaga. 3.  Varasemad koostöösuhted tellijaga. 4.  Moodulite olemasolu, mis sobivad taotluses kasutamiseks. 5.  Taotluse koostamiseks ja täitmiseks vajalike oskustega täitjate olemasolu. 6.  Kõrgetasemelise/võitva taotluse koostamiseks vajaliku ajaressursi

olemasolu. 7.  Tellija maksevõime ja valmisolek adekvaatse hinna tasumiseks. 8.  Konkurentide arvust ning nende kvaliteedist tulenev võidu tõenäosus. 9.  Konkurentidest positiivse eristumise määr. 10.  Võime pakkuda konkurentidest odavamaid lahendusi. 11.  Võimalused tellijaga tema nõudeid, prioriteete, võimalusi, hindamise

põhimõtteid ja taotleja võimalikke lahendusi arutada.

20

Tarkvaraprojektide üldküsimused

21

Tarkvaraprotsessi faasid

Lihtsaim üldine arendusmudel: ADDIE (Analyse, Design, Development, Implementation, Evaluation).

Tarkvaraarenduse puhul: nõuded, disain, kodeerimine, testimine, juurutamine.

SWEBOK Guide (The Guide to the SoftWare Egineering Body Of Knowledge): 15 teadmusvaldkonda (knowledge areas) + alavaldkonnad (topics).

Näiteks nõuete põhifaasi alafaasid (kokku on 7 nõuete-alast teemat): 1)  nõuete määratlemine, 2)  nõuete analüüs,

3)  nõuete spetsifitseerimine, 4)  nõuete hindamine (validation).

22

Tarkvaraprojekti esialgne kavandamine

Tarkvaraprojekti esialgse kavandamise tulem: tarkvaraarenduskava.

See peaks sisaldama järgmist:

•  projekti visiooni määratlemine

•  põhiotsustaja määratlemine •  projekti eesmärkide määratlemine

•  riskihaldus •  efektiivsete personalikasutuse strateegiate kujundamine

•  ajaarvestus

•  ....

23

Tarkvaraprojekti kestvuse määramatus

Projekti tegevuste konkretiseerimisel tuleks kohandada ka ajakava.

Projekti kestvuse hinnangu määramatuse kordajad (NASA SEL): c 1/c

Nõuete väljatöötamise järel 2,0 0,5 Nõuete analüüsi järel 1,75 0,57 Esialgse disaini järel 1,4 0,71 Detailse disaini järel 1,25 0,80 Kodeerimise järel 1,1 0,91 Testimise järel 1.05 0,95

24

Personalivajadus

25

Personalivajadus ja personalijuhtimine

Personalivajadus sõltub kasutatavast arendusmudelist; üldjuhul nõuab nõuete analüüs rohkem aega ja kõrgemat kvalifikatsiooni, mistõttu mõned töömahu hindamise mudelid jätavad selle hoopis kõrvale.

Brooksi reegel (inimkuude jaotus): 1/3 kavandamisele, 1/6 kodeerimisele, 1/4 üksuse testimisele, 1/4 integreerimisele. Brooksi seadus: “adding manpower to a late software project makes it later”.

Arendaja vahetus on väga kulukas ⇒ personali säilitamine ja professionaalne kasv on projektijuhi oluline kvaliteedinäitaja.

Probleem: teadmiste, oskuste ja kasutatavate praktikate mittevastavus. Näide: Gunnar Piho magistritöö.

26

Projekti mehitamine – rollid

Erinevad arendusmudelid määratlevad erinevad rollid.

Näide (Belbini rollimudel, http://www.belbin.com/about/belbin-team-roles/; võrdle loengukonspektist Thomsetti mudeliga): •  koordinaaror •  vormistaja •  ideede generaator •  järelevaataja-hindaja •  juurutaja •  meeskonnatöö tugi •  varustaja •  spetsialist •  lõpuleviija.

27

Soovitused personalivajaduse arvestamiseks

1.  Kavandada tööjõud 75% ulatuses.

2.  Pigem investeerida kogenud eksperti kui värvata “odav” algaja ja loota tema koolitamisse ja arengusse (tootlus 10x, kiirus 5x).

3.  Projektimeeskonna kooskõla on olulisem kui individuaalsed teadmi-sed/oskused; projektimeeskonna sagedaim etteheide projektijuhile.

4.  Isiksuslikud omadused on olulisemad kui teadmised/oskused: esimesed on raskemini kujundatavad kui teised (Roger Woolfe, 10:6).

5.  Projektijuht peab olema vaba projektimeeskonna kujundamisel; selles ei tohi avaldada survet.

6.  Projektimeeskonna kujundamisel peab jälgima, et muus kontekstis kujunenud rollid ei pärsiks projektis olulisi rollivahekordi. N: Victoria ülikooli üliõpilasprojektid.

28

Nõuete väljatöötamine

29

Nõuete väljatöötamine - olulisus

Tarkvaranõuded: väljatöötatava tarkvara kirjeldus (see võib sisaldada ka kasutuslugusid, mis kirjeldavad kasutajate suhtlust loodava tarkvaraga).

Nõuded jagatakse funktsionaalseteks (konkreetsete funktsioonide kirjeldus) ja mittefunktsionaalseteks (näiteks skaleeritavus/jõudlus, taastusaeg, kasutatavus, koostoimevõime jmt).

Standish Group: Nõuete kvaliteet on IT-projektide õnnestumise olulisuselt 3. kohal olev tingimus, nõuete mittetäielikkus ebaõnnestumise 3. kohal olev põhjus.

30

Nõuete väljatöötamine ja analüüs – probleemid

1.  Liiga üldine/ebamäärane ülesandepüstitus. Võtted: seonduvate protsesside määrat-lemine ning nendest lähtuvalt nõuete konkretiseerimine, kasutuslugude koostamine.

2.  Kaasatavate kasutajate määratlemine. Kõik olulisemad profiilid (personad) peavad olema esindatud. N: õppetööle registreerumine.

3.  Kasutajatega ühtse keele leidmine. Võtted: koolitused, seminarid.

4.  Kasutajate poolt oma vajaduste teadvustamine. Võtted: intervjuud, kasutuslugude ja persona-de koostamine.

5.  Efektiivse kasutatavuse (usability) tagamine. Võtted: ühtne stiilijuhis (sh arusaadavad ikoonid), prototüübid, kasutusjuhend.

6.  Nõuete muutumine projekti täitmise jooksul. Võtted: paindlike arendusmetoodikate kasutamine, muudatuste juhtimise tagamine.

31

Nõuete väljatöötamine - soovitused

Standard:

ISO/IEC/IEEE 29148:2011: Systems and software engineering -- Life cycle processes --Requirements engineering

Fundamentaalne: kasutajate kaasamine.

Soovitused: http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements

32

Kvaliteedi, riskide ja muudatuste haldus

33

Kvaliteedikindlustus

Toote kvaliteediprobleemid ulatuvad kaugele peale projekti lõppu ! kvaliteet on olulisem kui projekti lõpptähtajast kinnipidamine.

Mõned olulised aspektid:1.  Lõpptestimise peavad läbi viima arenduses mitteosalenud

inimesed.2.  Kehtib Pareto reegel (80:20). Probleemsed moodulid tuleb

lokaliseerida ja parandada võimalikult varakult.3.  Tarkvara tarnimisküpsuse otsustamine (näiteks vealeidmise ajalise

jaotuse või valemi N*M/L kasutamisega).4.  Veaparanduse protseduurid peavad olema sätestatud.

34

Riskihalduse aspekte

Riskihaldus on sisuliselt optimeerimisülesande lahendamine; üldjuhul on optimaalne 5-10%.

Soovitav on koostada põhiliste riskide tabel: riski kirjeldus, riski suuruse hinnang, riski vähendamise teed, riski realiseerumisel võimalikud tagajärjed, vastutajad,

Standard: ISO/IEC 27005:2011  Information technology — Security techniques — Information security risk management.

Raamistik (näide): Risk IT – A Risk Management Framework by Information Technology Governance Institute (ITGI).

Analüüs (näide): http://www.isaca.org/SiteCollectionDocuments/2015-risk-reward-survey/2015-it-risk-reward-barometer-report.pdf

35

Muudatuste haldamine/juhtimine

Projektiplaan vajab pidevat kohandamist/täpsustamist. Muudatuste sisseviimine peab käima kindla protseduuri järgi; näiteks:

1.  Muudatuste kavandajad peavad koostama vastava kirjaliku Muudatusettepaneku, kus on kavandatav muudatus ning selle läbi saavutatavad tulemused kirjeldatud,

2.  Juhtrühm saadab Muudatusettepaneku arvamuse saamiseks muudatusest puudutatud osapooltele,

3.  Esitatavates arvamustes hinnatakse nii muudatuste sisseviimise kulusid kui ka selle läbi saavutatavat kasu,

4.  Arvamuste alusel võtab juhtrühm vastu asjakohase otsuse ja teavitab sellest asjakohaseid osapooli.

NB! Muudatuste haldamisele/juhtimisele tuleb allutada ka kõik teised projekti täitmisel olulised dokumendid (riskid, stiilijuhis, väljastuse kontroll-loetelu jne).

36

Muudatuste haldamine

Arvestatavad faktorid, näiteks: 1.  Kuidas mõjutab muudatus projekti ajakava, kvaliteeti ja ressursijao-

tust (näiteks kas suurendab eriti hõivatud inimeste töökoormust); 2.  Kas muudatuse tegemist on otstarbekas edasi lükata; 3.  Millised on muudatuse sisseviimisega kaasnevad riskid jne.

Hästi korraldatud muudatuste haldus vähendab ebaõnnestumise riske, kuna:

1.  Otsused on läbi räägitud, rohkem aktsepteeritud ja paremini põhjendatud,

2.  Projekti käik on paremini dokumenteeritud, 3.  Osapooled on üksteise tööst paremini informeeritud, misläbi

saavutatakse parem koostöö.

37

Koostöö juhtkonnaga

38

Koostöö juhtkonnaga – vajadus

Standish Group: Koostöö juhtkonnaga on IT-projektide õnnestumise olulisuselt 2. kohal olev tingimus, vähene koostöö ebaõnnestumise 4. kohal olev põhjus.

Koostööks on oluline juhtide 1) informeerimine ja 2) kaasatus (juhid peavad projekti pidama “omaks”, mitte “võõraks”).

Hea koostöö nimel peaks vältima järgmiseid olukordi: 1) Juhtide kahtlused projekti adekvaatse kavandamise (eelkõige selleks

kuluva aja) suhtes. Selle vältimiseks peaks projekti olulised aspektid olema põhjalikult ja veenvalt põhjendatud ning juhtidega läbi räägitud.

2) Juhtide poolt vähesest informeeritusest tulenevalt projekti täitmist pärssivad tegevused (kokkulepped kolmandate osapooltega, oluliste ressursside kavandamine muude projektide peale jmt).

39

Koostöö eesmärk – vajadusel abi saamine

1.  Mingi algatuse läbiviimiseks.

2.  Ootamatute oluliste probleemide lahendamiseks.

3.  Teistest projektidest või tegevustest sisendi saamiseks.

4.  Teiste institutsioonidega/huvirühmadega koostöö käivitamiseks.

5.  Uute projektiga seonduvatesse algatustesse kaasamiseks.

6.  Mingite oluliste protsesside kiirendamiseks (altpoolt tulevate algatuste juurutamine on reeglina aeganõudvam kui ülaltpoolt lähtuvate).

40

Näide juhtkonna meetmetest – “alkoholitest”

“Alkoholitest” projekti kavandamise ja täitmise kvaliteedi üle otsustamiseks: oluliste küsimuste (ootamatu) esitamine projektijuhile ja projektimeeskonna liikmetele.

Testi eesmärk: veenduda, et projekti täitjad on projektist, selle täitmisest ja enda rollist põhjalikult aru saanud.

Testi edukaks läbimiseks vajalik projektijuhi ennetav tegevus: endale võimalike küsimuste esitamine, neile vastuste leidmine (vajadusel koostöös projektimeeskonna teiste liikmetega) ning vastuste projektimeeskonnas läbiarutamine.

41

Diskussioon

Millist abi olete juhtkonnalt saanud enda projektide kavandamisel ja täitmisel?

42

Tarkvaraprojekti maksumuse hindamine

43

Tarkvaraprojekti maksumuse/töömahu hindamise üldvalem

Töömaht = KoodimahtProtsess × Meeskond × Vahendid × Kvaliteet •  Koodimaht: funktsioonide või koodiridade arv (ühikuks 1000

koodirida).•  Protsess: Inimtöö efektiivsus, mittevajaliku töö osakaal jmt.•  Meeskond: töö vastavus oskustele, motivatsioon, meeskonnatöö, …•  Vahendid: arendusvahendid ja –tehnikad•  Kvaliteet: sobivate mõõdikute kasutamine, vastastikku toetamine, …

NB! See valem ei hõlma nõuete väljatöötamise faasi.

44

Tarkvara väljastamine (reliis)

45

Tarkvara väljastamine – põhitegevused

Tarkvara väljastamiseks vajalikud tingimused/tegevused:1.  Vigade jaotus on saavutanud vastuvõetava taseme.2.  Kõik kriitilised vead on leitud ja parandatud.3.  Kontrollnimekirja täitmine.4.  Projektijärgse veaparanduse/täienduste tegemise protseduuride

kokkuleppimine.5.  Ajaloo-dokumendi täiendamine.Näide. Release Management on Data Warehouses (Ronald Konings,

http://www.konings.biz/thesis/Release%20Management%20%20Master%20Thesis%20v10.pdf).

Probleem: beeta-testimine.

46

Tarkvara väljastamine – soovitused

1.  Forrester Research (2011): •  Paranda väljastamiseelseid protsesse (paljude väljastamisega

seonduvate probleemide põhjused tulenevad eelnevast tegevusest)

•  Laienda reliisihalduse läbilaskevõimet (kasuta paralleelseid ja intelligentseid testimisprotsesse);

•  Optimiseeri reliisiprootsessi (kasuta virtualiseerimist, tihenda reliisitsükleid);

•  Arenda tarkvara viisil, mis võimaldab kiireid muudatusi.•  Loo ühiskasutuses olev reliisiportaal (et osapooled oleksid

informeeritud).

2.  Gartner (2013): tarkvara väljastamise protsessid on puudulikud või isegi sisuliselt puuduvad 95% IT-organisatsioonides.

47

Tarkvaraprotsess – üldised kogemused

48

Soovitused – Tarkvaraprotsessi alane kogemus

1.  Tutvusta tarkvaratoodet tarbijaile võimalikult vara. Ükskõik kuidas ka ei püüa nõuete formuleerimise faasis tarbija vajadusi tundma õppida, efektiivseim viis selleks on anda talle toode ja lasta tal sellega tööd teha.

2.  Kasuta sobivat protsessimudelit. Iga projekt peab valima protsessi, mis on sellele projektile sobivaim antud organisatsioonikultuuri, riskivalmiduse, nõuete selguse, rakendusvaldkonna jne korral.

3.  Minimeeri intellektuaalset distantsi (arendusprotsessi osapoolte vahel). Tarkvara struktuur peab olema võimalikult lähedane reaalse maailma struktuuridele; see on tinginud objekt-orienteeritud tehnikate, komponent-tehnoloogiate ja visuaalse modelleerimise kasutuselevõtu.

4.  Enne programmi kiiremaks tegemist tee see korrektseks. Palju lihtsam on teha töötav programm lihtsamaks kui teha kiire programm korrektseks, st ei tasu algse kodeerimise juures programmi optimiseerimise üle väga muretseda.

49

Soovitused – Tarkvaraprotsessi alane kogemus

5.  Hea juhtimine on olulisem kui hea tehnoloogia. Halba juhtimist ei kompenseeri hea tehnoloogia ja küllaldased ressursid, küll aga hea juhtimine kompenseerib halba tehnoloogiat ja väheseid ressursse. Vähe sellest, hea juht tõmbab häid inimesi, saavutab nende vajaliku pädevuse ja kujundab hea meeskonna.

6.  Saa aru ja järgi tarbija prioriteete. Tarbija lepib sellega, et 90% funktsionaalsusest hilineb, kui ainult kõige olulisem 10% valmiks tähtajaliselt.

7.  Disaini muutmisvalmina. Muutusi peab võimaldama nii arhitektuur, komponendid kui ka kasutatavad spetsifikat-sioonitehnikad. Seejuures muutmine ei tohi oluliselt kaasa tuua keerukuse kasvu.

8.  Tarkvaraarenduse käigus loodav peab enamuses olema isedokumenteeruv. Disain ilma dokumenteerimata ei ole disain, neid peab looma paralleelselt (sageli kohatav ütlus “Disain on lõpetatud, tuleb see vaid veel dokumenteerida” viitab protsessi nõrkusele).

50

Diskussioon

Kirjeldage enda head ja halba (tarkvara)projektide alast kogemust.

51

Tarkvaraarenduse mudelid ja metoodikad

52

Klassikaline mudel koskmudel (kaskaadmudel, the waterfall model)

53

Koskmudel ja kahefaasiline mudel

Nõuded Disain Kodeerimine Testimine Juurutamine

Kahefaasilise mudeli eelised: •  Annab firmale võimaluse projekti katkestamiseks kui tehtud on alles

suhteliselt väikesed kulutused. •  Võimaldab summaarselt kavandada projekti adekvaatsemalt kui

ühefaasilise mudeli korral. •  Sunnib projektijuhti pöörama suurt tähelepanu projekti kavandamisele.

54

Koskmudel - majandusnäitajad

1.  Tarkvara väljastamise järgne vea parandus maksab ligikaudu kaks suurusjärku rohkem kui see viga oleks parandatud varases disaini faasis.

2.  Vaid ligikaudu 15% tarkvaarenduse töökulust läheb programmeerimisele.

3.  Koodilugemisega on võimalik leida ja parandada vaid 60% vigadest.

4.  Arendusprotsessis on üldkehtiv Pareto reegel (80% tegevusest kulub 20% nõuetele; 80% kulutustest 20%-le komponentidele; 80% vigu on 20% komponentides; 80% tulemusest saavutatakse 20% inimeste poolt jne).

55

Mitmeetapiline (iteratiivne) mudel

Mudeli üldkuju: •  Arenduse 1. faas (nõuded ja arhitektuur)‏ •  Etapp 1: detailne disain, kodeerimine, testimine ja väljastamine •  Etapp 2: detailne disain, kodeerimine, testimine ja väljastamine •  … •  Etapp n: detailne disain, kodeerimine, testimine ja väljastamine •  Tarkvara lõplik väljastamine

56

Diskussioon

Loetleda mitmeetapilise mudeli eelised

57

Mitmeetapilise mudeli eelised

1.  Tarkvara varane kasutuselevõtt. 2.  Riskid on vähendatud. 3.  Probleemid ilmnevad varakult. 4.  Väheneb vahearuannete kirjutamise aeg (töötav tarkvara on parem

kui mistahes muud tüüpi aruanne). 5.  Suureneb valikute arv funktsionaalsuse osas. 6.  Suureneb planeerimise adekvaatsus (etapijärgne tagasiside!) ‏7.  Tarkvaraprotsessi parem paindlikkus, efektiivsus ja süsteemsus

(muudatusi arutatakse iga etapi järel). 8.  Vigade töötlus on efektiivsem (vigade lokaliseerimine kergem). 9.  Töö jaguneb ühtlasemalt (näiteks saavad testijad tööle asuda juba

esimese mooduli valmimisel).

58

Paindlikud arendusmetoodikad

59

Paindlikud arendusmetoodikad – üldised põhimõtted

1990-ndate aastate keskel töötati üheaegselt välja mitmeid metoodikaid, mille ühiseks tunnuseks on paindlikkus.

Levinuimad – XP (ekstreemprogrammeerimine) ja SCRUM

Tuntuim on Kent Beck, Manifesto for Agile Software Development (1996) loomise algataja.

Võtmesõnad: kommunikatsioon, lihtsus, tagasiside, respekt ja tarmukus.

XP rollid: arendaja, klient/kasutaja, jäljekütt (tracker), treener; testija, konsultant, suur juht.

Scrum rollid: toote omanik (otsustaja ja vastutaja), SCRUM-meister (meeskonnale tingimuste looja), meeskonnaliige.

Muud terminid: väle, agiilne metoodika.

60

Paindlikud arendusmetoodikad – spetsiifika

Paindlike arendusmetoodikate eduka rakendamise eeldused: •  distsipliin, •  kõrge mitmekülgne kvalifikatsioon, •  väikesed arendusmeeskonnad, •  nõuete muutmise võimalikkus ka projekti hilises faasis (erinevalt

näiteks koskmudeli rakendamisest), •  inimtööjõu võimalikult efektiivne kasutamine.

Vt ka Wikipedia artiklit “Agile software development – https://en.wikipedia.org/wiki/Agile_software_development

61

Paindlike arendusmetoodikate põhijooned

1.  Lähtub soovilugudest (stories, realiseerimine keskmiselt 2 nädalat).

2.  Arendajate rollide ja ülesannete vahetumine projekti täitmisel.

3.  Igahommikused (püstijala-)koosolekud.

4.  Aluseks minimaalsuse põhimõte (lisa uus funktsionaalsus vaid selge vajaduse korral).

5.  Tihe ja pidev koostöö tarbijaga.

6.  Kokkulepitud reeglid, spetsifikatsioonid, standardid.

7.  Paarisprogrammeerimine.

8.  Ei ületunnitööle!

Vaata http://www.extremeprogramming.org/rules.html

62

Paindlike arendusmetoodikate riske

1.  Fookus arendamisele ei tähenda dokumentatsiooni täielikku puudumist.

2.  Kõik meeskonnaliikmed ei suuda kõiki vajalikke ülesandeid vajaliku kvaliteediga täita.

3.  Toote omanik ei suuda kõiki äripoole (sh huvipoolte) vajadusi piisavalt hästi esindada.

4.  Projektijuhi puudumine võib põhjustada ebapiisavat töö koordineeritust ja fokuseeritust (iseorganiseerivates meeskondades ei ole kedagi, kes jagaks ülesandeid).

5.  Eelnevalt fikseeritud sprindi kestvused võivad pärssida kvaliteeti kui täidetav ülesanne osutub liiga keerukaks/mahukaks või tegevused (näiteks testimine) ei ole piisavalt efektiivseid.

63

Paindlikkuse põhimõtete kombineerimine teiste arendusmetoodikatega (Scrum ja PRINCE2 näitel)

Põhimõte: “Implementing lean is also a lean process, an iterative process of change, learn and adapt”.

Scrum on väljastuspõhine (protsessid on paindlikud), PRINCE2 * (PRojects IN Controlled Environments) on protsessipõhine.

Põhiprotsessid: 1.  projekti algatamise otsustamine (ainuke projektiväline protsess) 2.  projekti algatamine3.  projekti juhtimine4.  etappide määratlemine 5.  etapi täitmise juhtimine6.  toote tarnimise haldamine " Scrum7.  projekti lõpetamine.

* http://www.projectsmart.co.uk/docs/prince2-introduction-ps.pdf

64

PRINCE2 + Scrum sünergiavõimalusi

PRINCE2 lisaväärtus Scrum nõrkustele:•  Projekti juhtrühm (board) suudab huvirühmi paremini ja ulatuslikumalt

esindada kui üksikisik (Scrumi tooteomanik – Product Owner). Näiteks toote tarnimine ei ole Scrumi protsess.

•  Projektijuhil on meeskonnaliikmete juhtimisel suurem pädevus kui Scrum-meistril.

•  Riskihaldus on PRINCE2 üks protsess, Scrum puhul võib Scrum-meistri puuduliku pädevuse tõttu tekkida probleeme.

Scrum lisaväärtus PRINCE2 nõrkustele:•  Projekti tulemi üldsõnaline kirjeldus, mis täpsustub projekti käigus.•  Uuele etapile ülemineku sujuvuse tagamine ilma et selleks oleks juhtrühmalt

aktsept saadud.•  Lessons learned koostada ja arutada läbi iga etapi lõpus (mitte üksnes

projekti lõpus).

65

Soovitused arendusmetoodika valikul

1.  Olulisem sellest, milline metoodika valida, on see, et valitud metoodikat hästi vallatakse. Kriitiliste ning kõrge riskiastmega projektide puhul peaks uue metoodika kasutuselevõttu põhjalikult kaaluma (st üldjuhul peaks seda vältima või juurutama samm-sammult).

2.  Uue metoodika juurutamisel tuleks õppida teiste kogemustest (näiteks kaasates/palgates seda valdavaid spetsialiste).

3.  Mistahes metoodika valikul peab seda kohandama asutuse organisatsioonikultuuriga ning projektirühma harjumuste ja oskustega; valitud (kohandatud) metoodika peab saama aktsepteeritud kogu projektirühma poolt.

4.  Kasutatavat metoodikat peab arvestama ka arendus- ja muude vahendite valikul. Soovitatav on kasutada kolmeastmelist jaotust: kohustuslik, soovitatav, lubatav.

66

Tarkvaraprotsessi küpsusmudelid

67

Tarkvaraprotsessi küpsusmudel CMM-SW

Raamistik institutsiooni tarkvaraarenduse-alase küpsuse hindamiseks. 5 taset: kaootiline, stabiilne, edenev, mõõdetav, optimeeritud (jaotus

väga ebaühtlane!). Igal tasemel on oma võtmeprotsessid, nõuded ja kontrollküsimused.

2003. aastal Eesti analüüs (laekus 69 ankeeti): mitte ükski ettevõte ei vastanud täielikult taseme 2 nõuetele.

Ettepanek (Gunnar Piho): vaadelda taseme 2 järgmiseid alatasemeid: •  CMM2-nõuded (heatasemeline nõuete haldamine)‏ •  CMM2- plaanid (CMM2-nõuded+tegevused on planeeritud ja ressurssidega

adekvaatselt kaetud)‏ •  CMM2-tulemused (CMM2-plaanid+toimib tegevuste/tulemuste monitooring

ning mingil määral ka kvaliteedisüsteem).

68

CMM-SW – 2. taseme küsimused projekti kavandamisest

1.  Kas projekti kavandamiseks ja jälgimiseks on olemas dokumenteeritud (mahu, maksumuse, ajakulu jne) hinnangud?

2.  Kas on fikseeritud kavandatavad tegevused ja täitjate ülesanded? 3.  Kas kõik rühmad ja üksiktäitjad aktsepteerivad neile pandud

kohustusi? 4.  Kas projekt järgib organisatsiooni kirjalikku tarkvara arendamise

poliitikat? 5.  Kas projekti kavandamiseks on eraldatud adekvaatsed ressursid? 6.  Kas kasutatakse meetmeid, mis võimaldavad määratleda projekti

kavandamise seisu (näit. vahekokkuvõtted)? 7.  Kas projekti juht annab regulaarseid ülevaateid projekti

kavandamise tegevustest?

69

Diskussioon

Millised on CMM-SW (ja üldiselt küpsusmudelite) võimalikud puudused?

70

Capability Maturity Model Integration – CMMI

Eesmärk: täiustada organisatsiooni toodete ja teenuste arenduse (CMMI-DEV) ja sisseostu (CMM-ACQ) ning teenuste osutamisega (CMM-SVC) seonduvaid protsesse. Tugineb nn protsessimudelitele, millede valik sõltub konkreetsetest tingimustest.

Protsessipiirkonnad: 1)  projektijuhtimine (6 põhiprotsessi) 2)  protsessijuhtimine (5 põhiprotsessi) 3)  tugiprotsessid (6 põhiprotsessi). Küpsustasemed 1 … 5. Mudeli komponendid jagunevad kolme kategooria vahel: •  Nõutavad (required, organisatsiooni üld- ja üksikud eesmärgid), •  Eeldatavad (expected, eesmärkide saavutamiseks juurutatavad praktikad) •  Informatiivsed (informative, materjalid, mis võimaldavad eesmärkide ja

praktikate paremat mõistmist).

71

Näide: CMMI – protsessid arenduse jaoks1.  Project Planning (2)2.  Requirements Management (2)3.  Quantitative Project Management (4)4.  Risk Management (3)5.  Integrated Project Management (3)6.  Project Monitoring and Control (2)7.  Organizational Process Definition (3)8.  Organizational Process Focus (3)9.  Organizational Performance Management (5)10.  Organizational Process Performance (4)11.  Organizational Training (3)12.  Causal Analysis and Resolution (5)13.  Configuration Management (2)14.  Decision Analysis and Resolution (3)15.  Measurement and Analysis (2)16.  Process and Product Quality Assurance (2)17.  Supplier Agreement Management (2)

Lisaks 3. tasemel: Product Integration, Requirements Development, Technical Solution, Validation, Verification.

72

CMMI protsesside küpsustasemedTase 1 (algtase, initial): protsessid on kaootilised, halvasti juhitud ja probleeme mitte

ärahoidvad, vaid neile reageerivad.

Tase 2 (hallatud, managed): sooritatud protsessid, mis on kavandatud ja läbi viidud kooskõlas esialgselt kavandatud plaanile. On loodud ja toimivad protsesside kavandamise ja läbiviimise (ning nende dokumenteerimise) põhimõtted.

Tase 3 (defineeritud, defined): hallatud protsessid, mis on kavandatud ja läbi viidud organisatsiooni standardprotsessidele tuginevalt: protsessid on kirjeldatud ja saadud kogemust kasutatakse edaspidise töö kavandamisel ja täitmisel.

Tase 4 (kvantitatiivselt hallatud, quantitatively managed): defineeritud protsessid, mida on võimalik kirjeldada kvantitatiivsete (mõõdetavate) tunnuste abil. Põhierinevus tasemel 3 olevatest protsessidest seisneb selles, et kvantitatiivselt hallatud protsesside tulemit on võimalik sisendparameetrite alusel ette ennustada.

Tase 5 (optimeeritud, optimising): kvantitatiivselt hallatud protsessid, mida täiustatakse vastavalt konkreetselt antud momendi tingimustele ja ärieesmärkidele. Täiustuste läbi saavutatava efekti suurust mõõdetakse.

73

NASA Software Process Improvement (SPI)‏

NASA tarkvara parendamise metoodika on iteratiivne ja suhteline (momendi tasemest lähtuv).

Arusaamine (understanding): eesmärkide ja nende saavutamiseks võimalike protsesside, mudelite, seoste ja indikaatorite määratlemine (st eesmärgiks on vajalikest protsessidest aru saada).

Hindamine (assessing): eesmärkide täpsustamine, erinevate meetodite ja vahendite rakendamisest tuleneva mõju hindamine (st eesmärgiks on suurima mõjuga meetodite ja vahendite väljaselgitamine).

Pakendamine (packaging): ennast õigustanud meetodite ja vahendite üldkasutatavaks muutmine.

74

NASA SPI versus CMM-SW

NASA SPI ja CMM-SW olulisemad erinevused:

1) kontseptsiooni osas: NASA – alt-üles, CMM – ülalt alla;

2) eesmärkide osas: NASA – konkreetsest vajadusest lähtuv, CMM – üldine protsessi kvaliteet;

3) hindamise alus: NASA – suhteline (momendi tase), CMM – absoluutne;

4) skaala: NASA – pidev, CMM - 5-astmeline.

NASA SPI mitmed põhimõtted on realiseeritud CMMI-s.

75

Tarkvaraprotsessi hindamine

76

Tarkvaraprotsessi hindamise metoodika SPICE

Tarkvaraprotsessi hindamise metoodika (Software Process Improvement and Capability dEtermination): erinevate aspektide hindamine 0...5 skaalal.

Metoodika põhijooned: •  Võimaldab eneseanalüüsi läbiviimist. •  Arvestab hinnatavate protsesside konteksti •  Arvestab hinnatavate protsesside eesmärkidega •  On rakendatav eritüübiliste ja erineva suurusega

organisatsioonide puhul.

Aluseks standardile ISO/IEC 15504 “Information technology – Software process assessment”.

77

SPICE struktuur (algselt)1.  Sissejuhatus ja põhimõisted. 2.  Protsessihalduse mudel. Määratleb tarkvaraarenduse

põhitegevused, järjestatuna protsessi keerukuse kasvamise järgi. 3.  Protsesside hindamine. Lisaks hindamise raamistiku (st mida

hinnata) määratlemisele annab ka hindamise alused (st kuidas määrata taset).

4.  Hindamise läbiviimise juhis. 5.  Hindamise instrumentide ja vahendite loomine ja valik. 6.  Hindajate kvalifikatsioon ja koolitus. 7.  Juhis rakendamiseks protsessi parandamisel. 8.  Juhis rakendamiseks protsesside võimekuse määramisel. 9.  Sõnastik, mis sisaldab kõiki SPICE dokumentides kasutatud

spetsiifilisi mõisteid.

78

Standardi ISO/IEC 15504 “Information technology – Software process assessment” osad

1: Concepts and vocabulary (ISO/IEC 15504-1:2004)2: Performing an assessment (ISO/IEC 15504-2:2003)3: Guidance on performing an assessment (ISO/IEC 15504-3:2004)4: Guidance on use for process improvement and process capability

determination (ISO/IEC 15504-4:2004)5: An exemplar Process Assessment Model (ISO/IEC 15504-5:2012)6: An exemplar system life cycle process assessment model (ISO/IEC

15504-6:2008)7: Assessment of organisational maturity (ISO/IEC 15504-7:2008)8: An exemplary process assessment model for IT service

management (ISO/IEC 15504-8:2012)9: Target process profiles (ISO/IEC 15504-9:2011)

79

Üliõpilastelt teemad täiendavaks arutamiseks

80

Üliõpilastelt teemad täiendavaks arutamiseks I

1.  Mis on tarkvaraprojektide suurimad ebaõnnestumise põhjused? TV-projektide edukus ja ebaõnnestumine sõltub paljudest faktoritest, sh näiteks ka kestvusest: 6 kuud – 56%, 18 kuud – 15%.

2.  Kuidas hinnata personalivajadust? Kas on ostetud sisse mujalt?

3.  Milliseid probleeme võivad põhjustada vead personalivalikul?

4.  Kuivõrd tuleks muudatusi juhtida ja seda dokumenteerida?

5.  Kuidas riskihaldus ja muudatuste juhtimine omavahel seotud on (s.t kas heatasemeline muudatuste juhtimine tagab ka madalad riskid)?

81

Üliõpilastelt teemad täiendavaks arutamiseks II

6.  Kas tarkvaraarendajate töö välismaal võiks kvaliteeti tõsta?

7.  Konsolideeritud IT-üksused (RMIT, SMIT jmt) esindavad tarkvara tellimisel pigem arendaja kui tellija huve.

8.  Kuidas kaardistada erinevate kasutajarühmade vajadused?

9.  Kuidas on tagatakse valminud tarkvara ülalhoiuteenus?

82

Järgmisse tundi arutamiseks

1.  Kas projektikonkursid on alati otstarbekad?

2.  Avatud kontori probleem.

3.  Näiteid kõrge riskitasemega projektidest.

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

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

83

Kodutöö nr 5 (töö õppematerjaliga)

1.  Loe läbi projektijuhtimise loengukonspekti alajaotused 3.14-3.16 ning 8.5-8.17.

2.  Sõnasta loetu kohta kokku kolm küsimust või probleemi, mida võiks järgmises tunnis diskuteerida või käsitleda põhjalikumalt.

3.  Saada punkti 2 all kirjapandu hiljemalt 26.nov. aadressile pnormak@tlu.ee.

4.  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?

84

Kodutöö 55.  Veebiallikate põhjal leia IKT-alaseid müüte.

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

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

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

9.  (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.

85

Järgmine loengPühapäev, 29. novembril kell 14:00

Teemad:•  Diskussioonid kodutööde teemadel•  Projektitaotluste retsenseerimine

•  Eksamitööde koostamisest ja esitlemisest•  Reflektsioon ainekursusest

86

E-oskuste (e-skills) arendamine

EL poliitika (“Technology for innovation/ICT industries and e-business”): http://ec.europa.eu/enterprise/ict/policy/ict-skills.htmNB! EK ettevõtluse ja tööstuse peadirektoraat!Thessaloniki resolutsioon (2006):1.  Euroopa Liidu globaalse konkurentsivõime tagamiseks on ülitähtis

(“crucial”) rakendada pikaajaline töötajate e-oskuste arendamise tegevuskava.

2.  Avalik ja erasektor peavad tegema ühiseid jõupingutusi, kujundamaks e-oskuste arendamisel välja põhikoolituse, kutse- ja kõrghariduse ning professionaalse tegevuse ühtne süsteem.

3.  Ettevõtted ja poliitikakujundajad peavad süstemaatiliselt propageerima professionaalsuse ja IKT rolli tööviljakuse, tööhõive ja tööperspektiivide suurendamisel.

E

87

E-oskuste arendamise põhisuunadE-oskuste tegevuskava (Euroopa Komisjoni teatis 7.9.2007 “E-skills for

the 21st century: fostering competitiveness, growth and jobs”) võtmekomponendid (läbiv põhimõte – heade praktikate levitamine):

1.  Avaliku ja erasektori koostöö ja ühisalgatused (“Multi-stakeholder partnership”): õppekavade kohandamine, välisspetside värbamine, …

2.  Investeerida (nii avaliku kui erasektori poolt) e-oskuste arendamisse, töötada välja e-oskuste raamistikud, mis seoks formaalse ja mitteformaalse hariduse ja sertifitseerimise ühtsesse süsteemi.

3.  Propageerida e-oskuste ja IKT elukutsete kaudu avanevaid karjäärivõimalusi (eelkõige õpilaste, vanemate ja õpetajate seas).

4.  Töötada välja ja realiseerida e-kaasatuse (e-Inclusion) programm (sh VKE jaoks). N: 30.11-2.12.2008 ministrite konverents Viinis.

5.  Elupideva õppe kontseptsioonist lähtuvalt töötada välja ettevõtete töötajatele suunatud e-kursuseid.

88

Eesti – IKT kõrgharidust toetavad institutsioonid

Tallinna (www.tlu.ee) ja Tartu (www.ut.ee) ülikoolid ning Tallinna Tehnikaülikool (www.ttu.ee), Eesti IT Kolledž (www.itcollege.ee).

Eesti Hariduse Infotehnoloogia Sihtasutus (www.hitsa.ee/en/) – toetab IKT rakendamist ja innovatsiooni (kõrg)koolides.

Archimedese SA (http://archimedes.ee/en/foundation/) – vahendab rahvusvahelisi ja kodumaiseid teadus- ja haridusprogramme.

Eesti riiklik IKT programm – toetab IKT-alaseid T&A-projekte.Eesti Info- ja Telekommunikatsiooni Ettevõtete Liit (www.itl.ee, ülikoold

on assotsieerunud liikmed) – toetab koostööd ettevõtetega ning populariseerib IT-elukutseid.

Eesti Arengufond – koostab arenguvisioone (http://www.arengufond.ee/en/).

89

Õppekava-alaste soovitustega seonduvaid näiteid

•  Association for Computing Machinery (ACM) and IEEE-Computer Society: http://www.acm.org/education/curricula-recommendations

•  The European Centre for the Development of Vocational Training (CEDEFOP): www.cedefop.europa.eu/files/2204_en.pdf

•  European Quality Assurance Network for Informatics Education (EQANIE): http://www.eqanie.eu/pages/quality-label/framework-standards-criteria.php

•  Eesti kutsestandardid: http://www.kutsekoda.ee/et/kutseregister/kutsestandardid/ (Valdkond: IT, TELEKOMMUNIKATSIOON ja ELEKTROONIKA; Kutseala: Tarkvaarendus)

90

Küpsusmudelitega seonduvad probleemid

1.  Dokumentide – mitte tegelike protsesside – analüüsil põhinevad.

2.  Fikseeritud näitajatel põhinevad, konkreetseid eripärasid mittearvestavad.

3.  Väikestele ettevõtetele mittesobivad (2005. aasta analüüsi põhjal oli tase 5 2,6% kuni 25 töötajaga ettevõtetel ja 62,8% ettevõtetel töötajate arvuga vahemikus 1001-2000).

4.  Arvestavad protsesside olemasolu (mida teha), mitte nende teostamise viisi (kuidas teha).

5.  Käsitleb vaid hinnatavat valdkonda, lahus ettevõtte muust tegevusest.

91 Source: http://www.prince2-ug.be/The-Process-Model

92

Konsolideeritud IT-asutuste rollist

“Tellija-äripool kipub vahel nii arvama ja see arvamine tuleneb ehk sellest, et projektid lähevad algselt planeeritust kallimaks, kuna tellija soovid ja vajadused muutuvad, esialgsed püstitused on ebatäpsed vms. IT projektijuht, kes seisab tellija ja arenduspartneri vahel,  peab suutma ühest küljest kaitsta maksimaalselt tellija huve (ja ka raha) ning teisalt säilitama head suhted arendajaga. Tellijale tuleb alatihti selgitada, et kui muutuvad vajadused (reeglina suurenevad ja ülesande keerukus kasvab), siis muutub ka projekti hind kallimaks ning samas arendaja käest tuleb soovitud muudatused võimalikult soodsatel tingimustel välja kaubelda (IT projektijuht esindab siiski tellijat). Ja siit võib tellijal üsna lihtsalt tekkida ettekujutus, et IT projektijuht ei ole nagu tellija „paadis“ vaid „sõbrustab“ liigselt arendajaga.” “IT projektijuht on ikka tellija esindaja. Kindlasti on ka üksikuid erandeid aga sellised inimesed vahetavad varem või hiljem töökohta ning liituvad arendaja tiimiga. “