Modulis T10B320 "Projektavimo valdymas"

1. Modulis T10B320 "Projektavimo valdymas" Vertinimas: • Egzaminas - 50% pažymio. • Laboratoriniai darbai - 50% pažymio. http://www.soften.ktu.lt/~kestas

2. Laboratoriniai darbai 1. darbas.Susipažinimas su Microsoft Project’u 2 darbas.Bakalaurinio darbo darbų planas (grafikas) 3. darbas.Darbų planas (grafikas) su kainomis 4. darbas.3-iame darbe sudaryto darbų plano optimizavimas (sutrumpinimas)

3. 1 lab. darbas turi būti apgintas iki kovo 12 d., 2 lab. darbas turi būti apgintas iki balandžio 2 d., 3 lab. darbas turi būti apgintas iki balandžio 30 d., 4 lab. darbas turi būti apgintas iki gegužės 21 d.. Už vėlavimą -2 balai, už didesnį nei 1 mėn. vėlavimą -4 balai.

4. Laboratoriniai darbai vyksta:trečiadieniais 8.00 - 14.00ketvirtadieniais 8.00 - 11.45 ir 14.15 – 15.45Visi darbai vyksta 206 SC aud.

5. Apžvelgiamos temos • Projekto planavimas; • Projekto darbų tvarkaraščio (grafiko)sudarymas; • Rizikos valdymas; • Žmonių valdymas; • Kokybės valdymas; • Kainos įvertinimas (apskaičiavimas)

6. Esminės veiklos • PĮ specifikavimas; • PĮ projektavimas; • PĮ kodavimas; • PĮ validavimas; • PĮ palaikymas (vystymas).

7. Proceso modeliai • Krioklio modelis •Aiškiai atskirtos proceso veiklos; • Evoliucinis kūrimas •Proceso veiklos persidengia; • Formalus sistemų kūrimas •Matematinis sistemos modelis formaliai transformuojamas į realizaciją; • Kūrimas pagrįstas pakartotiniu panaudojimu •Sistema yra sukomplektuojama iš jau egzistuojančių komponentų.

8. Krioklio modelis • Analizės etapas • Projektavimo etapas • Realizavimo etapas • Integracija ir sistemos testavimo etapas • Eksploatavimo ir palaikymo(vystymo) etapas

9. Programinės įrangos kokybės atributai • Naudingumas • Pasikliaunamumas (parengtumas, patikimumas, sauga ir apsauga) • Aiškumas ir palaikomumas • Efektyvumas

10. Sąnaudų pasiskirstymas • Įvairioje literatūroje sąnaudų pasiskirstymas tarp projektavimo/palaikymo yra pateikiamas kaip 40/60, 30/70 ir net 10/90 • Palaikymo sąnaudų tipinis pasiskirstymas maždaug toks: 60 (tobulinimas) / 20 (pritaikymas prie pakitusios aplinkos) / 20 (klaidų taisymas). • Projektavimo sąnaudų tipinis pasiskirstymas maždaug toks: 40 (analizė ir projektavimas) / 20 (kodavimas ir modulių testavimas) / 40 (integracija ir sisteminis bei priėmimo testavimas).

11. Jei priimame, kad bendros sąnaudos - 100%, o projektavimo/palaikymo santykis 40/60, tai gauname tokį bendrą sąnaudų pasiskirstymą: 16% - analizė ir projektavimas, 8% - realizacija, 16% - testavimas, 12% - adaptavimas, 36% - tobulinimas 12% - klaidų taisymas

12. Projektų dydžiai Nr. Kategorija Progr.skačius Trukmė Produkto dydis 1 Trivialus 1 1-4 sav. 500 KE 2 Mažas 1 1-6 mėn. 1-2 KKE 3 Vidutinis 2-5 1-2 metai 5-50 KKE 4 Didelis 5-20 2-3 metai 50-100 KKE 5 Labai didelis 100-1000 4-5 metai 1 MKE 6 Ypatingai didelis 2000-5000 5-10 metai 1-10 MKE

13. Pagal “Standish Group” duomenis 1995 metais JAV buvo išleisti 85 milijardai $ “canceled” projektams, tokių projektų procentualiai buvo 31%. 53% projektų viršijo biudžetą daugiau nei 50%. Tik 9% didelių projektų buvo baigti laiku ir pagal biudžetą, 16% -vidutinių ir 28% - mažų.

14. Skirtumai • Produktas yra nematerialus • Nėra aiškaus supratimo apie PĮ kūrimo procesą • Didelės PĮ sistemos dažnai yra unikalūs projektai • Lankstumas (Flexibility)

15. Projekto menedžeris yra asmuo, atsakingas už sėkmingą projekto įvykdymą. Projekto menedžeris vykdo projekto planavimą, vadovauja jam, organizuoja ir kontroliuoja projektą bei užtikrina, kad komunikaciniai ryšiai būtų aiškiai nustatyti ir naudojami

16. Menedžeris turi sugebėti atsakyti į šiuos klausimus: • Kokie projekto tikslai; • Kodėl buvo sugalvota realizuoti šį projektą; • Kada projektas turi būti baigtas; • Kaip turi būti atliktas darbas, t.y. projekto kokybė; • Kas turi atlikti darbą, t.y. kas subkontraktoriai.

17. Kas yra menedžerio kompetencijoje? • pasiūlymo rašymas, • projekto kainos įvertinimas, • projekto planavimas ir darbų grafiko sudarymas, • projekto kontrolė, • personalo parinkimas (atranka) ir įvertinimas, • ataskaitų rašymas ir pristatymai (presentations).

18. Produktyvumo vienetai -Apimtis/Laikas • Išeities kodo eilučių kiekis, parašytas per programuotojo mėnesį; • Funkcinių taškų kiekis, realizuotas per programuotojo mėnesį; • Objektinių taškų kiekis, realizuotas per programuotojo mėnesį (kai projektavime naudojamos 4 kartos kalbos); • Objektinių instrukcijų kiekis, parašytas per programuotojo mėnesį; • Dokumentacijospuslapių kiekis, parašytas per programuotojo mėnesį; • Testų kiekis, parašytas per programuotojo mėnesį.

19. Faktoriai, apsprendžiantys PĮ kokybę ir darbo produktyvumą • Individualūs sugebėjimai. Galima išskirti du sugebėjimų aspektus: bendrą kompetenciją ir individualias žinias atskiroje taikomojoje srityje.

20. Sackman eksperimentas 12 programuotojų, turinčių patyrymą toje srityje, kurios taikomąją programą reikėjo sukurti, parodė tokius rezultatus: • programos dydis 1:5; b)programos vykdymo laikas 1:13; c) kodavimo laikas 1:25; d) derinimo laikas 1:28. Palyginęs geriausią ir blogiausią produktyvumą, Sackman gavo santykį 1:16. Atmetus kraštutinius rezultatus buvo gautas produktyvumo santykis 1:5. Santykis (1:5) rodo, kad individualūs sugebėjimai yra labai reikšmingas faktorius.

21. 2. Bendravimas grupėje. • Jei grupėje yra n programuotojų, tai bendravimo ryšių skaičius yra lygus n*(n-1)/2 • Brooks dėsnis: “Papildomo programuotojų skaičiaus panaudojimas vėluojančiame projekte gali projektą dar užvėlinti” (Adding more programmers to a late project may make it later). • Priežastys: • Nauji žmonės turi susipažinti su sistema, o žmonės, kurie apmoko, kuria tą sistemą,t.y. tuo metu jie nedirba; • Išauga ryšių skaičius.

22. Pavyzdys. • Sistemą kuria 4 inžinieriai, kurių produktyvumas, kai dirba pavieniui – 6000 eil./metus. Grupė organizuota kaip tinklinė (demokratinė) struktūra, tad yra 6 ryšiai (4*3)/2=6. • Sakykme, kad vienas ryšys sumažina produktyvumą 600 eil./metus. Tad grupės produktyvumas 6000*4-600*6=20400 eil./metus. • Sakykime, kad projektą yra planuota atlikti per metus. Jis vėluoja, todėl į grupę ateina dar du žmonės. Ryšių skaičius išaugaiki 15 (6*5/2=15). • Vieno žmogaus produktyvumas per mėnesį- 6000/12=500 eil./mėn., vieno ryšio “kaina” per mėnesį – 50 eil./mėn. • Per likusius du mėnesius 6 žmonės suprogramuos 6*2*500 –15*2*50 = 4500 eilutes, o keturi žmonės 4*2*500 – 6*2*50 = 3400 eilutes. • Taigi, skirtumas +1100 eil., tuo tarpu, kai pavieniui tie žmonės būtų suprogramavę 2000 eilučių.

23. 3. Produkto sudėtingumas. Yra trys bendrai pripažinti produkto sudėtingumo lygiai: a)Taikomosios programos. Moksliniai skaičiavimai ir duomenų apdorojimas. Produktyvumas - 25-100 eilučių per dieną. b)Servisinės programos. Kompiliatoriai, asembleriai, ryšių redaktoriai. Produktyvumas -5-10 eilučių per dieną. c)Sisteminio (embedded, įdiegtos) lygio programos. Realaus laiko procesų kontrolė, operacinės sistemos, komunikacinės sitemos. Produktyvumas - 1 eilutė per dieną.

24. 4. Problemos supratimas. 5. Pasiruošimo lygis. Kokių įgūdžių dažniausiai trūksta pradedantiesiemsPĮ inžinieriams: a) Aiškiai išdėstyti mintis; b) Sudaryti PĮ reikalavimų ir projektavimo etapo specifikacijas; c) Dirbti taikomojoje srityje; d) Eksploatuoti (palaikyti) PĮ; e) Atlikti ekonominę analizę; f) Dirbti su projekto valdymo priemonėmis; g) Dirbti grupėse.

25. 6. Vadybiniai įgūdžiai. 7. Tinkamos notacijos. 8. Reikalaujamas patikimumas. 9. Reikalavimų stabilumas. 10. Technologijos lygis.

26. Žmogiškasis faktorius PĮ projektavime (Žmogiškų resursų vadyba) • Kad dirbti efektyviai, menedžeriai turi traktuoti savo personalą kaip asmenybes ir suprasti, kaip jos veikia vienas kitą. Geresnis psichologijos supratimas padeda menedžeriams suprasti žmogaus ribotumą ir nekelti savo personalui nerealizuojamų tikslų; • PĮ inžinieriaus produktyvumas yra svarbiausias faktorius, apibrėžiantis projekto kainą. Žmogiškojo faktoriaus supratimas gali padėti menedžeriams išskirti galimus produktyvumo padidinimo kelius. • Žmonės organizacijoje yra pats didžiausias turtas • Vadybininko uždaviniai pagrindinai yra orientuoti į žmones

27. Poreikių lygiai Savęs realizavimo Pagarbos Socialiniai Saugumo Fiziologiniai

28. Apatiniai lygiai atvaizduoja baziniusporeikius: • fiziologiniai – maistas, miegas, šiluma ir t.t. • saugumo – jaustis saugiai aplinkoje. • Motyvacijos būdai - pinigai. Tai aiški varomoji jėga, tačiau daugelis projekto narių dirba už pastovią algą

29. Viršutiniai lygiai yra labiau susieti su sąmone: • socialiniai – poreikis būti socialinės grupės atstovu; • Motyvacijos būdai - reikia suteikti bendradarbiams galymybę ir vietą realizuoti neformalaus bendravimo poreikius, užtikrinti komunikacijų kanalus, kaip telefonas ar paštas; • pagarbos – jaustis kitų gerbiamu; • Motyvacijos būdai – teigiami atsiliepimai, rodyti, kad jie yra vertinami organizacijoje, pav., viešai pripažinti jų atsiekimus, daugeliui žmonių yra malonu girdėti teigiamus atsiliepimus apie jų atliktą darbą, ypač, kai jie jaučiasi gerai jį atlikę. Aišku, žmonės turi taip pat jausti, kad jiems yra mokama alga, atitinkanti jų jų sugebėjimus ir patirtį;

30. savęs realizavimo poreikiai, susieti su asmeniniu vystymusi; • Motyvacijos būdai: • atsakomybė už savo darbą, užduočių, atitinkančių jų sugebėjimus priskyrimas; • kvalifikacijos kėlimas; • aiškūs tikslai, labai svarbu, kad kiekvienas projekto narys aiškiai žinotų, ką jis turi daryti, kodėl ir kada tai turi būti padaryta. Žmonės mėgsta turėti aiškius tikslus, Jūsų pareiga užtikrinti, kad projekto vykdymo metu tikslai nebūtų sujaukti. • pasitenkinimas darbu ir kūrybiškumas, niekas nemėgsta nuobodžių, pasikartojančių darbų. Menedžerio užduotis yra taip paskirstyti darbus, kad Jūsų bendradarbiai jaustų pasitenkinimą.

31. Motyvacija tai poreikų tenkinimas. Žiūrint iš PĮ menedžerio pozicijų svarbiausi ir sunkiausiai patenkinami yra socialiniai, pagarbos ir savęs realizavimo poreikiai.

32. Darbo grupės patalpų išplanavimas

33. Programuotojų grupės struktūros Tinklinė (demokratinė)

34. C A Programuotojų grupės struktūros Žvaigždinė

35. Šef-programuotojas Programuotojas-konsultantas (backup programmer) Bibliotekininkas Programuotojai Šef-programuotojų grupė (žvaigždinė struktūra)

36. Projekto lyderis Vyr. programuotojai Jaun. programuotojai Hierarchinė struktūra

37. Faktorius Paaiškinimas Patirtis taikomojoje srityje Projektuotojai turi suprasti taikomąją sritį Platformos patirtis Svarbu, kai programuojama žemame lygyje, kitu atveju tai ne kritinis faktorius Programavimo kalbos patirtis Svarbus faktorius tiktai trumpalaikiams projektams, kur nėra laiko naujos kalbos apmokymui Išsilavinimas Reikšmingas priimant jaunus darbuotojus, augant darbuotojų patirčiai jo reikšmė mažeja Gebėjimas bendrauti Svarbus faktorius, nes darbai vykdomi grupėse Prisitaikomumas Jei kandidatas turi įvairaus darbo patirtį, tai rodo jo sugebėjimą mokytis Požiūris į darbą Labai svarbus faktorius, tačiau jį labai sunku įvertinti Asmenybė Labai svarbus faktorius, tačiau jį labai sunku įvertinti Faktoriai, apsprendžiantys žmonių pasirinkimą

38. Projekto plano struktūra 1.Įvadas Trumpai aprašomi projekto tikslai ir apribojimai (biudžetas, laikas ir t.t), liečiantys projekto vadybą. 2.     Projekto organizavimas Aprašoma projektavimo grupės struktūra, grupėje dirbantys žmonės ir jų rolės grupėje. 3.     Rizikos analizė Aprašomos galimos projekto rizikos, jų pasirodymo tikimybės, siūlomos rizikų mažinimo strategijos. 4.     Aparatūrinės ir programinės įrangos resursų reikalavimai Aprašomi reikalinga projektui vykdyti aparatūrinė ir programinė įranga. Jei dalis tos įrangos turi būti perkama, nurodomas kainos įvertinimas ir tiekimo grafikas. 5.     Darbų struktūra Aprašomas projekto išskirstymas į atskiras veiklas (activities), nurodomi atskaitos taškai (milestones) ir pristatymai (deliverables), susiiję su kiekviena veikla. 6.     Projekto darbų tvarkaraštis Aprašomi ryšiai tarp darbų (veiklų), reikalingi resursai ir laikas veiklai atlikti 7.     Stebėjimo ir atsiskaitymo mechanizmai Aprašomi projekto stebėjimo mechanizmai ir vadybinės ataskatos, kuris turi būti sudarytos projekto vykdymo metu.

39. Plan Description Quality plan Describes the quality procedures and standards that will be used in a project. Validation plan Describes the approach, resources and schedule used for system validation. Configuration Describes the configuration management management plan procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan. Describes how the skills and experience of the project team members will be developed. Įvairių tipų projekto planai

40. Rizikos valdymas

41. Rizikos kategorijos·Projekto rizikos – įtakoja grafiką arba resursus;·Produkto rizikos – įtakoja kuriamos PĮ kokybę;·Verslo rizikos – įtakoja PĮ platinimą.

42. Rizika Rizikoskategorija Aprašymas Personalo kaita Projekto Patyręs personalas paliks projektą dar jį nebaigus Vadybininkų kaita Projekto Pasikeis projekto organizacinė struktūra Hardware unavailable Projekto Reikalinga projektui aparatūra nepristatyta pagal grafiką Reikalavimų pasikeitimas Projekto ir produkto Didesnis reikalavimų pakeitimų kiekis nei laukta Specifikacijų vėlinimas Projekto ir produkto Esminių reikalvimų specifikacijos vėluoja Blogai įvertintas sistemosdydis Projekto ir produkto Sistema yra didesnė nei laukta Menkas CASE įrankių našumas Projekto ir produkto CASE įrankiai yra prastesni nei laukta Technologijos pasikeitimas Verslo Pagrindinės technologijos, kurių pagrindu veikia sistema, pakeistosnaujomis. Produkto konkurencija Verslo Konkuruojantis produktas pasirodo rinkoje, kai sistema dar nebaigta Galimos rizikos

44. Rizikos identifikavimas Identifikavimo tikslas – nustatyti galimas projekto rizikas, remiasi “smegenų šturmo” metodu arba menedžerio patirtimi. Galimi rizikos tipai: Technologinė rizika. Pav., naudojama duomenų bazė apdoroja mažiau transakcijų per sekundę nei laukta, PĮ komponentai, kurie yra “reused”, yra su klaidomis. Žmonių rizika. Pav., neįmanoma įdarbinti reikiamų sugebėjimų žmones, pagrindiniai darbuotojai serga kritiniu laiku, negalimas reikalingas personalo apmokymas. Organizacinė rizika. Pav., pasikeičia už projektą atsakingas menedžeris, Organizacinės finansinės problemos priverčia mažinti projekto biudžetą Įrankių (tools) rizika. Pav., CASE įrankių pagalba sugeneruotas kodas yra neefektyvus, neįmanoma integruoti CASE įrankius. Reikalavimų rizika. Pav., reikalavimų pakeitimai iššaukia didelius architektūrinius pasikeitimus, užsakovai nesupranta (neįvertina) reikalavimų pasikeitimo poveikio. Įvertinimo rizika. Pav., per trumpas projekto realizavimo laikas, blogai įvertintas PĮ dydis, suplanuotas per mažas galimų defektų kiekis.

46. Rizikos planavimas Rizikos planavimo proceso metu yra nagrinėjama kiekviena identifikuota esminė (stebima) rizika ir nustatomos tų rizikų valdymo strategijos. Strategijos yra skirstomos į tris kategorijas: • Rizikos vengimo (Avoidance). Mažinama rizikos pasirodymo tikimybė. Pav., komponentai su klaidomis – pakeisti juos reikiamo patikimumo komponentais. • Rizikos mažinimo. Mažinama rizikos įtaka. Pav., darbuotojų ligos – perorganizuoti darbo grupę taip, kad užduotys daugiau persidengtų ir bendradarbiai geriau žinotų, ką kiekvienas daro. • Atsitiktinumų planavimo. Kai atsitinka blogiausia, Jūs esate tam pasirengę ir turite strategiją, kaip tada elgtis. Pav., organizacinės – finansinės problemos – parengti dokumentą, skirtą vyresniems vadybininkams, nurodant, kokią verslo požiūriu svarbią reikšmę visai organizacijai turi jūsų vykdomas projektas.

47. Rizikos tipas Galimi indikatoriai Technologinė Vėluojantis aparatūros ar palaikančios PĮ tiekimas, daug reports apie technologines problemas Žmonių Žema personalo moralė, blogi santykiai tarp grupės narių Organizacinė Organizacinės paskalos, mažai iniciatyvos iš vadovaujančio personalo Įrankių Grupės narių nenoras naudoti įrankius, nusiskundimai dėl CASE įrankių, dėl galingesnių kompiuterių reikalavimai Reikalavimų Daug prašymų pakeisti reikalavimus, užsakovų nusiskundimai Įvertinimo Nesiseka dirbti pagal tvarkaraštį, nesiseka taisyti defektus Rizikos stebėjimas

48. Programinės įrangos kainos apskaičiavimo metodai

49. Faktorius Aprašymas Rinkos išplėtimas Projektuojanti organizacija gali pasiūlyti žemą kainą tam, kad užimtų naują nišą PĮ rinkoje, kas gali atnešti didesnį pelną ateityje. Ar tam, kad įgijus patirties po to sėkmingai gaminti panašaus profilio produktus. Neaiškumai įvertinant kainą Dėl netikrumo įvertinant kainą, padidinamas pelno procentas. Kontrakto sąlygos Užsakovas gali leisti projektuotojui naudoti išeities kodą. Tuo atveju, kai šis kodas tinkamas “for reuse”, kaina gali būti sumažinama. Reikalavimų nepastovumas Matant, kad reikalavimai gali keistis, projektuojanti organizacija gali pasiūlyti žemesnę kainą tikslu gauti kontraktą. Gavus kontraktą, galima padidinti keičiamų reikalavimų kainą. Finansiniai sunkumai Galima sumažinti kainą, kad gauti kontraktą. Geriau jau mažesnis nei normaliai pelnas negu kontraktų nebuvimas ar dar blogiau – bankrotas. Bendru atveju – projekto kaina tai projekto išlaidos plius pelnas, tačiau apskaičiuojant projekto kainą reikia įvertinti žymiai daugiau faktorių. Kai kurie faktoriai, į kuriuos reikėtų atsižvelgti įvertinant projekto kainą, pateikti žemiau.

50. Metodas Aprašymas Įvertinimas pagal analogą Metodas naudojamas tada, kai organizacijoje jau buvo padaryti keli projektai iš tos pačios taikomosios srities. Naujo projekto kaina paskaičiuojama remiantis analogu. Ekspertų įvertinimas Kiekvienas ekspertas apskaičiuoja projekto kainą. Apskaičiuotos kainos yra palyginamos ir aptariamos. Įvertinimo procesas iteruoja, kol pasiekaimas bendras sutarimas apie projekto kainą. Pricing to win Kaina nustatoma pagal tai, kiek užsakovas gali moketi už produktą. Taigi, kaina priklauso nuo užsakovo biudžeto, o ne nuo projektuojamos sistemos funkcionalumo. Algoritminis kainos modeliavimas Modeliai sudaromi pagal ankstesnių projektų informaciją, remiantis PĮ metrikomis (dažniausiai dydžiu). Įvertinus šias metrikas, modelis modelis leidžia apskaičiuoti projekto sąnaudas. Kainos apskaičiavimo metodai