Projekto valdymas l Programins rangos toliau P projekt

Projekto valdymas l Programinės įrangos ( toliau - PĮ ) projektų organizavimas, planavimas ir darbų grafiko sudarymas. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 1

Įžanga l (Tikslai, temos, valdymo poreikis, išskirtinumas) ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 2

Paskaitos tikslai l l Supažindinti su PĮ projekto valdymu ir aprašyti jo būdingas charakteristikas Aptarti projekto planavimą ir planavimo procesą Parodyti, kaip grafinis darbų grafiko atvaizdavimas yra naudojamas projekto valdyme Aptarti rizikos sąvoką ir rizikos valdymo procesą ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 3

Apžvelgiamos temos l l Valdymo veikla Projekto planavimas Projekto darbų tvarkaraščio sudarymas Rizikos valdymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 4

PĮ projekto valdymas l l Susijęs su veikla, užtikrinančia, jog PĮ pristatoma laiku ir pagal tvarkaraštį bei išpildomi organizacijų PĮ kūrimo ir tiekimo reikalavimai Projekto valdymas yra reikalingas todėl, kad PĮ kūrimas visada priklauso nuo biudžeto ir darbų grafiko apribojimų, kurie nustatomi PĮ kūrimo organizacijų ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 5

PĮ projektų valdymo išskirtinumas l l l Produktas yra neapčiuopiamas Produktas yra unikaliai lankstus PĮ inžinerija kol kas nepripažįstama kaip inžinerijos disciplina su tuo pačiu statusu kaip mechanikos, elektros ir kita inžinerija PĮ kūrimo procesas yra nestandartizuotas Daugelis PĮ projektų yra vienkartiniai, t. y. skirti tik tam kartui ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 6

Apžvelgiamos temos l l Valdymo veikla (veiklos išvardinimas (6 veiklos), bendrybės, apribojimai) Projekto planavimas Projekto darbų tvarkaraščio sudarymas Rizikos valdymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 7

Valdymo veikla l l l Pasiūlymų rašymas Projekto planavimas ir darbų tvarkaraščio sudarymas Projekto išlaidų nustatymas Projekto stebėjimas ir peržiūros Personalo atranka ir įvertinimas Ataskaitų rašymas ir pristatymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 8

Valdymo bendrybės l l l PĮ projektų valdymas nėra išskirtinis Dauguma inžinerijos projekto valdymo metodų yra taip pat taikomi PĮ projekto valdymui Techniškai sudėtingos inžinerinės sistemos susiduria su tomis pačiomis problemomis kaip ir PĮ sistemos ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 9

Apribojimai l Neįmanoma pasirinkti idealius žmones projekto darbams • • • l Projekto biudžetas gali neleisti išlaikyti brangiai apmokamą personalą Gali nebūti darbuotojų su reikiama patirtimi Organizacija gali pageidauti gerinti darbuotojų įgūdžius šiuo PĮ projektu Vadybininkai privalo dirbti prie šių apribojimų ypač kai dabar trūksta patyrusių informacinių technologijų specialistų ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 10

Apžvelgiamos temos l l Valdymo veikla Projekto planavimas (kas būdinga projekto planavimui, planų tipai, planavimo procesas, plano struktūra, veiklos žingsnių organizavimas, atskaitos taškai) l l Projekto darbų tvarkaraščio sudarymas Rizikos valdymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 11

Projekto planavimas l l l Tikriausiai tai daugiausia laiko reikalaujanti projekto valdymo veikla Tai tęstinė veikla nuo pradinės koncepcijos iki sistemos pateikimo. Planai privalo reguliariai būti atnaujinami, kai tik tampa prieinama nauja informacija Įvairūs skirtingų tipų planai gali būti sudaromi, kad palaikyti pagrindinį PĮ projekto planą, kuris susijęs su darbų tvarkaraščiu ir biudžetu ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 12

Įvairių tipų projekto planai Kokybės Atestavimo Pakeitimų valdymo Priežiūros Kvalifikacijos kėlimo ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 13

Projekto planavimo procesas Nustatyti projekto apribojimus; Įvykdyti pradinį projekto parametrų įvertinimą; Apibrėžti projekto esminius atskaitos taškus ir pristatymus; kol projektas nėra pabaigtas ciklas Sudaryti projekto grafiką; Pradėti darbą, atsižvelgiant į grafiką; Palaukti ( kurį laiką ); Peržvelgti projekto eigą; Patikrinti projekto parametrų apskaičiavimus; Atnaujinti projekto darbų grafiką; Pakartotinai aptarti apribojimus ir pristatymus; jeigu ( iškyla problemos ) tuomet Pradėti techninę apžvalgą ir galimus pakeitimus; jeigu pabaiga ciklo pabaiga ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 14

Projekto plano struktūra l l l l Įvadas Projekto organizavimas Rizikos analizė Aparatūrinės ir programinės įrangos resursų reikalavimai Darbų nutraukimas Projekto darbų tvarkaraštis Stebėjimo ir atsiskaitymo mechanizmai ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 15

Veiklos žingsnių organizavimas l l Projekto veiklos žingsniai turi būti organizuoti taip, kad pateiktų apčiuopiamus rezultatus, leidžiančius įvertinti progresą Atskaitos taškas ( milestone) yra proceso veiklos žingsnio pabaiga Pateiktys (Deliverables) yra vartotojui pateikiami projekto rezultatai Krioklio procesas leidžia tiesiai nustatyti progreso atskaitos taškus ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 16

Atskaitos taškai reikalavimų inžinerijos procese Veiklos žingsniai Deliverables Pateiktys ©Ian Sommerville 2010 Atskaitos taškai Software Engineering, 8 th edition. Slide 17

Apžvelgiamos temos l l l Valdymo veikla Projekto planavimas Projekto darbų tvarkaraščio sudarymas (Projekto darbų tvarkaraščio sudarymo veiksmai, procesas, problemos, grafinis vaizdavimas, užduočių trukmės ir priklausomybės, darbų tinklinis grafikas, kalendorinės diagramos, darbuotojų paskirstymas) l Rizikos valdymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 18

Projekto darbų tvarkaraščio sudarymas l l Padalinti projektą į užduotis ir apskaičiuoti laiką ir resursus, reikalingus užbaigti kiekvienai užduočiai Organizuoti lygiagretų užduočių vykdymą, kad optimaliai panaudoti darbo jėgą Minimizuoti užduočių priklausomybes tam, kad išvengti uždelsimų, atsiradusių vienai užduočiai laukiant kitos pabaigos Priklauso nuo projekto vadybininkų intuicijos ir patirties ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 19

Projekto darbų tvarkaraščio sudarymo procesas Nustatyti veiklos žingsnius Nustatyti veiklos žingsnių priklausomybes Apskaičiuoti Paskirstyti veiklos žingsnių žmonėms resursus veiklos žingsniams Veiklos žingsnių ir projekto dalių aptarimai PĮ reikalavimai ©Ian Sommerville 2010 Sukurti projekto diagramas Software Engineering, 8 th edition. Slide 20

Darbų tvarkaraščio sudarymo problemos l l Problemų sudėtingumo ir tuo pačiu sprendinio gavimo kaštų apskaičiavimas yra labai sunkus Produktyvumas nėra proporcingas skaičiui žmonių, dirbančių su šia užduotimi Žmonių papildymas vėluojančiam projekte dar labiau suvėlina projektą dėl pridėtinių sąnaudų komunikavimui Atsitinka nenumatyti įvykiai. Planuojant reikia visada atsižvelgti į tokius atsitiktinumus ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 21

Kalendorinės diagramos ir darbų tinklinis grafikas l l Grafiniai žymėjimai naudojami pavaizduoti projekto darbų tvarkaraščiui Parodo projekto suskirstymą į užduotis. Užduotys neturi būti per mažos. Jos turi užimti apie vieną-dvi savaites laiko Tinklinis grafikas parodo užduočių priklausomybes ir kritinius kelius Kalendorinės diagramos rodo darbų tvarkaraštį kalendorinio laiko atžvilgiu ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 22

Užduočių trukmės ir priklausomybės ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 23

Darbų tinklinis grafikas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 24

Kalendorinės diagramos ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 25

Darbuotojų paskirstymas ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 26

Apžvelgiamos temos l l Valdymo veikla Projekto planavimas Projekto darbų tvarkaraščio sudarymas Rizikos valdymas (programinės įrangos rizika, jos valdymo procesas, rizikos tipai, rizikos analizė , rizikos tikimybės, rizikos planavimas, rizikos valdymo strategijos, rizikos stebėjimas, rizikos požymiai) ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 27

Rizikos valdymas l l Rizikos valdymas – tai rizikos nustatymas ir kūrimas planų, kurie minimizuotų rizikos poveikį projektui. Rizika – tai tikimybė, kad atsiras kažkokios nepalankios aplinkybės. • • • Projekto rizika įtakoja tvarkaraštį arba resursus. Produkto rizika įtakoja kokybę arba programinės įrangos kūrimo našumą. Verslo rizika įtakoja organizavimo kūrimą arba programinės įrangos tiekimą. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 28

Programinės įrangos rizika Rizika Personalo tekamumas Vadovavimo pasikeitimas Aparatūros Neprieinamumas Reikalavimų Pasikeitimas Specifikacijų Vėlinimas Dydžio Neįvertinimas CASE įrankių Mažas našumas Technologijų Pasikeitimas Produkto Konkurencija ©Ian Sommerville 2010 Rizikos tipas Projektas projektas Projektas ir produktas Produktas Verslas Aprašymas Patyręs personalas paliks projektą prieš jo pat jo pabaigą. Organizacinio vadovo pasikeitimas, kurio kitokie prioritetai. Laiku nepristatyta reikalinga aparatūra. Pasikeičia daug reikalavimų. Esminių interfeisų charakteristikos negaunamos laiku. Buvo neteisingai įvertintas sistemos dydis. Projekte naudojami CASE įrankiai nėra tokie našūs kaip buvo tikėtasi. Pagrindinės technologijos, kurių pagrindu veikia sistema, pakeistos naujomis. Konkuruojantis produktas pasirodo rinkoje, kai sistema yra beveik baigta. Software Engineering, 8 th edition. Slide 29

Rizikos valdymo procesas l Rizikos nustatymas • l Rizikos analizė • l Tikimybės ir rizikų pasekmių įvertinimas. Rizikos planavimas • l Nustatyti projekto, produkto ar verslo riziką. Kuriami planai kaip išvengti ar minimizuoti rizikos poveikį. Rizikos stebėjimas • Rizikos stebėjimas proceso eigoje ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 30

Rizikos valdymo procesas Galimos rizikos sąrašas ©Ian Sommerville 2010 Rizikos sąrašas su prioritetais Rizikos išvengimo ir galimų atsitiktinumų planas Software Engineering, 8 th edition. Rizikos įvertinimas Slide 31

Rizikos analizė l l l Įvertinama tikimybė ir kiekvienos rizikos svarba. Tikimybė gali būti labai žema, vidutinė, didelė ar labai didelė. Rizikos poveikis gali būti katastrofiškas, rimtas, leistinas ar nereikšmingas. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 32

Rizika Tikimybė Poveikis Organizacinės finansinės problemos priverčia Maža Katastrofiškas mažinti projekto biudžetą. Naujokų įtraukimas neįmanomas, nesvarbu, Didelė Katastrofiškas kad jie turi reikalaujamus įgūdžius. Personalo vadovas serga , tuo metu kai jis labai Vidutinė Rimtas reikalingas. Naudojamuose programinės įrangos Vidutinė Rimtas komponentuose atsirado defektų, kurie įtakoja jų funkcionalumą. Pasikeičia reikalavimai, todėl reikia pakeisti Vidutinė Rimta pagrindinį projektą. Organizavimas perskirstomas taip, kad Didelė Rimtas pasikeičia vadovas atsakingas už projektą. Sistemos duomenų bazių naudojimasis Vidutinė Rimtas gali trukti ilgiau nei buvo tikėtasi. Neįvertinamas programinės įrangos kūrimui Didelė Rimtas reikalingas laikas. CASE įrankių neįmanoma integruoti. Didelė Leistinas Vartotojams sunku suprasti įtrauktus Vidutinė Leistinas reikalavimų pakeitimus. Reikalaujamas personalo apmokymas neįmanomas. Vidutinė Leistinas Neįvertinamas defektų taisymui reikalingas laikas. Vidutinė Leistinas Neįvertinamas programinės įrangos dydis. Didelė Leistinas Kodas, sugeneruotas naudojant CASE įrankius, tampa Vidutinė Nereikšmingas neefektyvus. Rizikos tikimybės ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 33

Rizikos planavimas l l Apsvarstoma kiekviena rizika ir sukuriama strategija kaip išvengti tos rizikos. Vengimo strategija • l Sumažinama tikimybė, kad rizika išaugs. Minimizavimo strategija. • l Sumažinama rizikos įtaka projektui ar produktui. Nenumatytų aplinkybių planavimas • Nenumatytų aplinkybių planavimas yra planas kaip kovoti su rizika, kuri netikėtai atsiranda. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 34

Rizikos valdymo strategijos Rizika Organizacinės finansinės Problemos Reikalavimų problemos Strategija Parengiamas trumpas dokumentas vyriausiam vadovui, kuris parodo kokią svarbią įtaka projektas duos verslui. Įspėti vartotoją apie potencialius sunkumus ir vėlinimo galimybę, ištirti komponentų pirkimą. Personalo susirgimas Perskirstyti komandą taip, kad kiekvienas komandos narys suprastų kitų darbą ir prireikus galėtų kurį nors pakeisti. Defektuoti komponentai Pakeisti defektuotus komponentus į kitus, kurių žinomas patikimumas. Reikalavimų pasikeitimas Numatyti, kokiu keliu būtų galima išvesti informaciją apie pasikeitusių reikalavimų įtaką, maksimizuoti informacijos slėpimą projekte. Organizaciniai pertvarkymai Parengiamas trumpas dokumentas vyriausiam vadovui, kuris parodo kokią svarbią įtaka projektas duos verslui. Duomenų bazių našumas Apsvarstyti našesnių duomenų bazių pirkimo galimybę. Neįvertintas projektavimo Apsvarstyti komponentų pirkimą, apsvarstyti Laikas programų generatoriaus naudojimą. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 35

Rizikos stebėjimas l l l Reguliariai vertinti kiekvieną nustatytą riziką, norint numatyti didėja ji ar mažėja. Taip pat vertinti pasikeitusios rizikos poveikį. Darbų eigos aptarimuose vadovas turėtų aptarti kiekvieną svarbią riziką ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 36

Rizikos požymiai Rizikos tipas Technologinės Žmonių Organizacinės Įrankių Reikalavimų Įvertinimų ©Ian Sommerville 2010 Potencialūs požymiai Aparatūros pristatymo ar programinės įtakos tiekimo vėlinimas, daug technologijų problemų. Žema personalo moralė, blogi santykiai tarp komandos narių. Organizacinės paskalos, vyriausiojo vadovo veiksmų sėkmė. Komandos narių nenoras naudoti įrankius, nusiskundimai dėl CASE įrankių, didesnės galios darbo stočių “nulūžimai”. Daugelis reikalavimų keičiasi, vartotojų nusiskundimai. Nesiseka dirbti pagal tvarkaraštį, nesiseka taisyti defektus. Software Engineering, 8 th edition. Slide 37

Esminiai akcentai l l Geras projekto vadovavimas yra pagrindinis faktorius projekto sėkmei. Nevizualios ( nematomos) programinės įrangos dalys kelia problemas valdymui. Vadovai turi skirtingas pareigas, tačiau jų svarbiausia veikla turėtų būti planavimas, įvertinimas ir darbų tvarkaraščių sudarymas. Planavimas ir įvertinimas yra iteracinis procesas, kuris tęsiasi visą projekto eigą. ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 38

Esminiai akcentai l l l Projekto atsiskaitymo taškai yra prognozuojama būsena, kai formalios darbų eigos ataskaitos yra pristatomos vadovui. Rizika gali būti projekto rizika, produkto rizika ar verslo rizika. Rizikos valdymas apima nustatymą rizikų, kurios gali įtakoti projektą; planavimą, norint garantuoti, kad šios rizikos neišsivystytų į grėsmingus pavojus ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 39

Esminių aspektų raktiniai žodžiai l (gero vadovavimo įtaka, nevizualumas, vadovo pareigos, planavimas ir įvertinimas, atskaitos taškai, rizikos tipai, valdymas) ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 40

Klausimas 4. 1 l Ką apima valdymo veikla? ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 41

Klausimas 4. 2 l Kas atliekama projekto planavimo metu? ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 42

Klausimas 4. 3 l Kodėl svarbus rizikos valdymas? ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 43

Klausimas 4. 4 l Ką atspindi kalendorinės diagramos ir tinklinis darbų grafikas? ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 44

Klausimas 4. 5 l Koks programinės įrangos projektų valdymo išskirtinumas? ©Ian Sommerville 2010 Software Engineering, 8 th edition. Slide 45