109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
U ovoj lekciji ćemo obrađivati:
Iterativni proces planiranja je nastao na osnovu informacija iz željenog opsega i zahteva, ali i utvrđivanjem njegove izvodljivosti. U ovom trenutku, procesi razvojnog ciklusa softvera se procenjuju i onaj najprikladniji (s obzirom na prirodu tog projekta, stepena uvedenih novina, njegove funkcionalne i tehničke složenosti, kvaliteta zahteva, itd…) se bira.
Tamo gde je to relevantno, projekat se planira u obliku hijerarhijske dekompozicije zadataka. Pripadajuća rešenja svakog zadatka se kategorišu u pogledu kvaliteta i drugih atributa u skladu sa zahtevima, njihove detaljne razrade, rasporeda i procene troškova koji se očekuju. Resursi se zatim dodeljuju postavljenim zadacima i to na takav način da se optimizuje produktivnost osoblja (na individualnom, timskom i organizacionom nivou), da se minimizuje potrošnja opreme i materijala i postigne kvalitetan rad u skladu sa rasporedom. Sprovodi se i detaljna analiza rizika projekta, diskutuje se i prihvata sugestija od strane svih zainteresovanih učesnika. Sveobuhvatan proces upravljanja kvalitetom softvera (eng. Software Quality Management) se utvrđuje kao deo procesa planiranja u obliku procedura i odgovornosti za osiguranje kvaliteta softvera, verifikacije i validacije, recenzije i revizije. S obzirom na to da je u pitanju iterativan proces, bitno je da se jasno usaglase i dogovore procesi i odgovornost za aktivni plan upravljanja, preglede i reviziju.
Izbor odgovarajućeg modela razvojnog ciklusa softvera (na primer, spiralni, evolutivni prototip) te adaptacija i implementacija odgovarajućih procesa životnog ciklusa softvera izvršavaju se s obzirom na određeni opseg i zahteve projekta. Takođe se biraju i relevantne metode i alati. Na projektnom nivou, odgovarajuće metode i alati se koriste za dekompoziciju projekta u zadatke, sa odgovarajućim ulazima, izlazima i uslovima kompletiranja. To sa druge strane, utiče na raspored i organizacionu strukturu projekta na višem nivou.
U ovom delu proizvodi svakog zadatka (na primer, arhitekturalni dizajn, inspekcijski izveštaji) su specifikovani i karakterizovani. Procenjuju se mogućnosti za ponovnu upotrebu softverskih komponenti iz ranijeg razvoja ili iskorišćenje gotovih softverskih proizvoda. Korišćenje “trećih” strana i nabavljenih softvera se takođe planira istovremeno sa izborom partnera (dobavljača).
Temeljnom analizom zadataka, ulaza i izlaza, određuje se očekivani raspon rada potrebnog za svaki zadatak. Ustanovljava se zavisnost zadataka i identifikuju se potencijalna “uska grla” uz pomoć pogodnih metoda (na primer, analiza kritične putanje). Uska grla se rešavaju tamo gde je moguće, a postavlja se i očekivani raspored zakazanih zadataka sa početkom izvršenja, vremenom trajanja i vremenom završetka. Zahtevani resursi (osoblje, alati) se prevode na procene troškova. Ovo je izrazito iterativni proces aktivnosti koje se moraju dogovoriti u cilju postizanja konsenzusa između svih zainteresovanih strana.
Oprema, objekti i osoblje se pridružuju rasporedu poslova odnosno zadataka, uključujući i raspodelu odgovornosti za završetak datih zadataka. Ova aktivnost je ograničena dostupnošću resursa i njihovog optimalnog korišćenja pod takvim okolnostima kao i pitanjima koja se odnose na osoblje (na primer, produktivnost pojedinaca i timova, timske dinamike, organizacione i timske strukture).
Upravljanje rizikom uključuje identifikaciju i analizu rizika (šta može poći pogrešno, kako i zašto, koje su moguće posledice), kritičnu procenu rizika (koji su najznačajniji rizici u pogledu izloženosti, šta možemo učiniti pod takvim uticajima), ublažavanje rizika i planiranje nepredviđenih situacija (formulisanje strategija za rešavanje rizika). Metode procene rizika treba koristiti kako bi se istakli i procenili rizici. Politika napuštanja projekta bi takođe trebalo da bude određena u ovom trenutku kroz dogovor sa ostalim zainteresovanim stranama – Stakeholder-ima. Jedinstveni aspekt softverskog rizika, kao što je sklonost softverskih inženjera da dodaju neželjene funkcionalnosti, mora uticati na upravljanje rizikom.
Kvalitet se definiše u smislu prikladnih atributa specifičnog projekata i bilo kojih povezanih proizvoda, u oba smisla, kvantitativnom i kvalitativnom. Ove karakteristike kvaliteta treba da budu utvrđene u detaljnoj specifikaciji softverskih zahteva. Ova oblast se više obrađuje na kursu „Softverski zahtevi“.
Pragovi za pridržavanje kvaliteta su postavljeni za svaki indikator odgovarajućeg očekivanja zainteresovanih strana za taj softver. Postupci u vezi sa tekućim procesom osiguranja kvaliteta, kroz celi proces i za proizvode, verifikaciju i validaciju, su takođe navedeni u ovoj fazi (na primer, tehničke revizije i inspekcije).
Kako će se projekat organizovati i kako će se taj plan sprovoditi, takođe mora biti isplanirano. Izveštavanje, nadgledanje i kontrola projekta mora biti u skladu sa odabranim procesom softverskog inženjerstva, realnim stanjem datog projekta i mora se odraziti na različite artefakte koji će se koristiti za upravljanje. Međutim, u okruženju gde je promena stvar očekivanja, a ne iznenađenja, veoma je bitno da su sami planovi usmereni. To dalje zahteva da pridržavanje planova bude sistemski usmeravano, nagledano, pregledano, izveštavano i gde je to moguće, ispravljano. Planovi, povezani sa drugim procesima upravljanja (na primer, dokumentovanje, upravljanje softverskom konfiguracijom, rešavanje problema) takođe imaju potrebu za kordiniranjem na isti način.
Planovi se potom implementiraju i procesi uključeni u plan se realizuju. Stoga, fokus je na pridržavanju usvojenog plana, sa očekivanjem da će to voditi do uspešnog zadovoljavanja zahteva zainteresovanih strana i kompletiranja ciljeva projekta. Osnove realizacije su tekuće menadžment aktivnosti vrednovanja, praćenja, kontrolisanja i izveštavanja.
U ovom trenutku razvoja projekt je inicijalizovan i projektne aktivnosti se izvode prema rasporedu. U ovom procesu, resursi se koriste (ljudski rad, finansije i dr.) i kreiraju se proizvodi (arhitekturalni dizajn, test slučajevi i dr).
U sklopu aktivnosti praćenje ugovora sa dobavljačima radi se pripremanje i izvršavanje ugovora sa dobavljačima, praćenje performansi i prihvatanje proizvoda dobavljača i njihovo ugrađivanje gde je to prikladno.
Proces vrednovanja i merenja se sprovodi uporedo sa razvojem softverskog projekta osiguravajući da su prikupljeni relevantni i korisni podaci. Ova tema će opširnije biti obrađena u nastavku kursa.
Pridržavanje raznih planova ocenjuje se kontinualno u unapred definisanim razmacima. Izlazi i uslovi za završetak svakog zadatka se analiziraju. Isporučeni proizvodi se ocenjuju u smislu njihovih zahtevanih karakteristika (na primer, putem recenzije i revizije). Uloženi napor, pridržavanje rasporeda i trenutni troškovi se istražuju, a korišćenje resursa se ispituje. Rizik projekta se proverava i evaluiraju se zahtevi kvaliteta.
Mereni podaci se modeliraju i analiziraju. Redovno se radi analiza varijacija zasnovana na odstupanju stvarnih od očekivanih rezultata i vrednosti. Ovo može biti u formi prekoračenja predračuna, kliznosti rasporeda i rokova i slično. Vrši se identifikacija i analiza kvaliteta i druga merenja podataka (na primer, analiza gustine defekata). Izloženost riziku i leveridž se ponovo izračunavaju kao i stablo odlučivanja, razne simulacije... Te aktivnosti omogućuju otkrivanje problema i identifikaciju izuzetaka na temelju prekoračenih pragova. Izlazi su predmet izveštaja po potrebi, a sigurno tamo gde su prihvatljivi pragovi nadmašeni.
Izlazi iz aktivnosti praćenja procesa pružaju osnovu na kojoj se donose odluke o akcijama. Promene u projektu mogu biti napravljene gde je prikladno i tamo gde se uticaj i pripadajući rizik modeluju i upravljaju. Ovo može imati formu korektivnih akcija (npr. ponovno testiranje pojedinih komponenata), može uključivati pripajanje izdataka tako da se izbegavaju slična pojavljivanja (npr. odluka da se koristi prototip radi asistencije u validaciji softverskih zahteva) ili može da zahteva reviziju različitih planova i ostalih projektnih dokumenata (npr. specifikacija zahteva) radi prilagođavanja neočekivanim promenama i njihovim implikacijama.
U nekim instancama, to može voditi čak i do napuštanja projekta. U svim slučajevima, kontrola promena i procedure upravljanja softevrskom konfiguracijom su blisko vezane, sve odluke su dokumentovane i prosleđene svim relevantnim stranama, planovi se pregledaju i revidiraju gde je potrebno, a relevantni podaci se snimaju u centralnoj datoteci.
U specifikovanim i dogovorenim periodima, pravi se izveštaji pridržavanja plana, svim zainteresovanim stranama, unutar, ali i izvan kompanije (klijentima, korisnicima). Izveštaji ovakve prirode treba da se fokusiraju na sveobuhvatno pridržavanje plana, za razliku od detaljnijih izveštaja zahtevanih periodično unutar razvojnog tima.
Reference:
Copyright © LINK group. Sva prava zadržana.
office@link.co.rs, +381.11.7856 140, +381.11.7856 100
Cara Dušana 34, 11080 Zemun, Beograd, Srbija
Powered by LINK CMS.