ТЕМА: RUP - Rational Unified Process

Ime i prezime studenta: Mentor:

, 2020

Sadržaj:
1. RUP - Rational Unified Process.......................................................................................2

1.1. Principi na kojima je zasnovan RUP................................................................................2

1.1.1. Iterativan razvoj........................................................................................................3

1.1.2. Upravljanje zahtjevima..............................................................................................4

1.1.3. Upotreba arhitekture zasnovane na komponentama..................................................5

1.1.4. Vizuelno modelovanje...............................................................................................5

1.1.5. Kontinuirana potvrda kvaliteta softvera.....................................................................6

1.1.6. Kontrola promjena softvera.......................................................................................7

1.1.7. Faza uvođenja...........................................................................................................8

2. Koraci u fazi uvođenja.....................................................................................................9

3. Faza elaboracije.............................................................................................................10

3.1. Koraci u fazi elaboracije.................................................................................................11

4. Faza konstrukcije...........................................................................................................12

4.1. Koraci u fazi konstrukcije..............................................................................................12

5. Faza Tranzicije..............................................................................................................13

5.1. Koraci u fazi tranzicije...................................................................................................15

6. Jedinstveni jezik za modelovanje UML (Unified Modeling Language)............................16

6.1. Šta je to UML?...............................................................................................................16

7. Literatura.......................................................................................................................18

1
 1. RUP - Rational Unified Process

Rational Unified Process (u nastavku RUP) predstavlja objektno orijentisani proces za

izradu softvera. Ovaj proces je zasnovan na pristupu baziranom na disciplinama, u okviru
kojih se vrši raspodela poslova i odgovornosti na članove razvojnog tima i ostale učesnike u
procesu razvoja softvera. Osnovna namena RUP-a jeste proizvodnja visoko kvalitetnog
softvera, kao krajnjeg rezultata projekta, koji zadovoljava potrebe kori-snika, a u okviru
planiranog budžeta i vremena.

RUP je framework (radni okvir) koji je moguće prilagođavati potrebama organizacije koja
ga usvaja. On sadrži skup dobro definisanih preporuka i uputstava za uspešan raz-voj
softverskog proizvoda. Upravo radi toga se kod navođenja definicije RUP-a izbe-gava izraz
metodologija, koji predstavlja znatno čvršći set pravila od navedenog izraza framework.
Međutim pojedinačnim podešavanjem RUP-a organizacija može da kreira svoj metodološki
okvir, a u okviru njega i čvrsta pravila izgrađena na osnovu datih pre-poruka i uputstava.

U izgradnji informacionog sistema, RUP preporučuje korišćenje raznih metoda i tehnika, ali
su svakako najdominantnije tehnike modelovanja korišćenjem Unified Mo-deling
Language-a (u nastavku UML) tj. jedinstvenog jezika za modelovanje. Za RUP se čak može
reći da predstavlja uputstvo za korišćenje UML-a.

RUP je inicijalno zamišljen za razvoj velikih projekata, ali je svoju primenu našao i u
srednjim i malim softverskim projektima. Softverski timovi, naročito veliki, znatno u-
napređuju svoju produktivnost korišćenjem RUP-a. RUP omogućuje svakom članu raz-
vojnog tima lak uvid u bazu znanja, zasnovanu na uputstvima, templejtima i uputstvima za
korišćenje alata, što predstavlja podršku u svim kritičnim razvojnim aktivnostima. To
doprinosi da svi članovi razvojnog tima, bez obzira na aktivnosti koje obavljaju, ko-riste
zajedničku metodologiju, jezik i pogled na to kako treba razvijati softverski proiz-vod.

2
 1.1. Principi na kojima je zasnovan RUP

Principi na kojima je zasnovan RUP, omogućuju razvoj kvalitetnih softverskih proiz-voda i

postavljanje metodoloških koraka kojima će se realizovati kompletne preporuke i uputstva
zasnovane na dole navedenim principima.

1.1.1. Iterativan razvoj

Klasični proces razvoja softvera se zasniva na modelu vodopada, koji je ranije opisan.
Alternativa modelu vodopada jeste iterativno-inkrementalni model razvoja softvera.
Korišćenjem ovoga modela dolazi se do relativno brze realizacije početne verzije sof-
tvera koja se razvija dodatnim iteracijama. Takođe, integrisanje i testiranje softvera se
obavlja češće, te se na taj način postiže smanjenje rizika. Što je razlika između trenutka
otkrivanja greške i trenutka nastanka greške veća, to je njeno otkrivanje i otklanjanje
teže i skuplje. Kao što se vidi na slici 1., iterativni proces se sastoji iz više sekvencijal-
nih procesa zasnovanih na modelu vodopada. Time je vremenska dimenzija izmeštena
u odnosu na sadržajnu dimenziju, pa je vreme između potencijalnog nastanka i otkri-
vanja grešaka značajno skraćeno.

Kao prednosti iterativnog razvoja mogu se navesti sledeće:

 Greške učinjene u razvoju se ranije identifikuju i na njih je moguće

uspešnije reagovati;

 Omogućava se korisnički feedback;

 Razvojni tim je primoran da se fokusira na ona pitanja koja su
najvažnija za projekat;

 Kontinuirano i iterativno testiranje pruža objektivan uvid u status razvoja;

3
  Nepravilnosti učinjene tokom analize zahteva, dizajna i
implementacije otkri-vaju se ranije;

 Tim za testiranje je uključen tokom celog životnog ciklusa projekta;

Slika 1.

1.1.2. Upravljanje zahtjevima

Prateći rezultate Standish grupe dolazi se do spoznaje, da je u 37% slučajeva razlog za

neuspeh projekata vezan za informacione zahteve. Nedostatak korisničkih zahteva
predstavlja razlog neuspeha projekata u 13% slučajeva, nepotpuni zahtevi i specifika-
cije u 12% slučajeva, a promena zahteva i specifikacija takođe u 12% slučajeva. Doda-
1
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

4
 jući navedenim podacima činjenicu, da su troškovi otklanjanja grešaka nastalih u obla-
sti zahteva izuzetno visoki, iako ih iterativan pristup značajno umanjuje, nameće se za-
ključak da se zahtevima ne posvećuje dovoljna pažnja, u procesu razvoja informacionih
sistema.

Informacioni zahtevi predstavljaju inpute za dizajn sistema, testiranje sistema, kao i

izradu korisničke dokumentacije. Greške u fazi analize zahteva su pogubne po uspeh
projekta razvoja. Da bi se gore navedeni procenti smanjili potrebno je posvetiti zna-
čajnu pažnju pronalaženju, organizovanju, dokumentovanju i upravljanju zahtevima.
RUP upravo to i radi kroz disciplinu zahteva čiji je cilj da opiše šta sistem treba da radi.
Taj opis treba da bude prihvaćen, kako od strane korisnika, tako i od strane razvojnih
inžinjera.

1.1.3. Upotreba arhitekture zasnovane na komponentama

Vizuelizacija, specifikacija, konstrukcija i dokumentovanje softverskog sistema zahteva da

sistem bude sagledan iz brojnih perspektiva. Svaki stejkholder (analitičari, integra-tori
sistema, testeri, projektni menadžeri, dizajneri, ...) donosi različitu sliku projekta, i svaki od
njih gleda sistem na različite načine, mnogo puta tokom života projekta. Arhi-tektura sistema
je možda najvažnija podela, koja se može koristiti da bi se upravljalo ovim različitim
gledištima i na taj način kontrolisao iterativni i inkrementalni razvoj sistema, tokom
njegovog životnog ciklusa.

Arhitektura je prevashodno bitna za razvojni tim koji realizuje projekat, ali indirektno utiče i
na zadovoljstvo krajnjeg korisnika. Arhitektura sistema obuhvata grupu značaj-nih odluka o:

5
  Organizaciji softverskog sistema
 Izboru gradivnih elemenata i njihovih interfejsa, od kojih je sistem sastavljen
 Ponašanju gradivnih elemenata, određenom upravo njihovom saradnjom
 Kompoziciji strukturalnih i bihevioralnih elemenata u veće rastuće podsi-steme
 Arhitektonskom stilu, koji objedinjuje gore navedene odluke u jednu cjelinu.

Razvoj baziran na komponentama (CBD - Component-Based Development) je značajan

pristup softverskoj arhitekturi jer omogućava ponovnu upotrebu, kao i specijalizaciju
komponenti. Pored sopstvene izgradnje komponenti za ponovnu upotrebu moguća je
upotreba komponenti i iz velikog broja komercijalno dostupnih izvora (Microsoft Com-
ponent Object Model - COM i Microsoft Foundation Classes - MFC, Common Object
Request Broker Architecture - CORBA, Enterprise JavaBeans - EJB samo su neke od ši-roko
podržanih platformi na kojima je arhitektura zasnovana na komponentama ostva-riva).

Kombinujući iterativan razvoj sa arhitekturom zasnovanom na komponentama svaki korak

proizvodi izvršnu arhitekturu sistema, koja je merljiva, pogodna za testiranje i vrednovanje u
odnosu na zahteve sistema. Na ovaj način se otvara mogućnost za kon-stantno napadanje
ključnih rizika projekta.

1.1.4. Vizuelno modelovanje

Model predstavlja pojednostavljenu sliku realnosti, koja kompletno opisuje sistem iz

pojedinačnih perspektiva. U softverskom inžinjeringu modeli se izgrađuju da bi se bolje
razumeo sistem koji se modeluje. Kod izrade velikih sistema modelovanje pomaže nji-
hovom razumevanju u potpunosti. Slobodno se može konstatovati da bi bez modelova-nja
automatizacija takvih sistema bila nemoguća.

Činjenica da jedna slika govori više nego hiljadu reči je poznata odavno. Međutim, ono što je
nedostajalo jeste standardizacija. UML kao jedinstveni jezik za modelovanje je prihvaćen od
strane vodećih svetskih IT kompanija i nametnut kao standard u softver-skoj industriji. On
služi za vizuelizaciju, specifikaciju, konstrukciju i dokumentaciju sistema koji se izgrađuje.
UML je omogućio svim članovima razvojnog tima da razgova-raju istim jezikom.

6
Standardizacija je dovela do toga da se UML izučava u školama i fakultetima širom sveta, pa
je time zamenjivost bilo kojeg člana razvojnog tima zna-čajno olakšana. RUP i UML
predstavljaju nerazdvojivu celinu.

Vizuelno modelovanje podiže kvalitet procesa razvoja softverskog proizvoda, što je lako
uočljivo preko sledećih karakteristika:

 Use Case-ovi i scenarija nedvosmisleno definišu ponašanje sistema,

 Dizajn je jasan i nedvosmislen,
 Nemodularne i nefleksibilne arhitekture su lako uočljive na nivou modela,
 Različite perspektive i različiti nivoi detaljnosti se mogu koristiti u različiti si-
tuacijama,

 Otklanjanje nekonzistentnosti na nivou dizajna, značajno olakšava implemen-taciju,

 Use Case model i dizajn model stvaraju jasne inpute za testiranje,
 Korišćenje UML-a nameće standardizaciju u softverskoj industriji.

1.1.5. Kontinuirana potvrda kvaliteta softvera

Kao što slika br. 2. ilustruje, softverski problemi su 100 do 1000 puta skuplji kada se
pronalaze i otklanjaju nakon uvođenja nego pre toga. Upravo zato, važno je kontinui-rano
proveravati kvalitet sistema sa posebnim akcentom na njegovu funkcionalnost, pouzdanost,
aplikativne performanse i sistemske performanse.

Proveravanje funkcionalnosti sistema uključuje kreiranje testova, za svaki ključni scenario

koji predstavlja neki aspekt željenog ponašanja sistema. Prilikom proveravanja
funkcionalnosti sistema potrebno je evidentirati svaki scenario koji nije zadovoljio zahteve i
pristupati njegovom osposobljavanju. Poštujući itearativan razvoj softvera tako je potrebno
pristupati i testiranju, testirajući svaku iteraciju.

7
 2

Slika 2.

Provera kvaliteta softvera pruža brojna rešenja ključnim uzrocima problema razvoja
softvera:

 Procena statusa razvojnog projekta se izrađuje objektivno, ne subjektivno, jer se

vrednuju rezultati testa
 Objektivno procenjivanje otkriva nekonzistentnosti u zahtevima, dizajnu i
implementaciji
 Testiranje i verifikacija su usmereni na oblasti najvišeg rizika, te se na taj način
uvećavaju kvalitet i efektivnost tih oblasti
 Greške se otkrivaju rano, radikalno snižavajući troškove njihovog ispravljanja

1.1.6. Kontrola promjena softvera

Ključni izazov prilikom razvoja softverskih sistema je usklađivanje rada razvojnih inžinjera,
organizovanih u razvojne timove koji zajedno rade na više iteracija stvarajući softverski
proizvod. Tokom razvoja novonastajući sistem se menja i razvija, a kontrola tih razvojnih
promena je nužna za sprečavanje haosa u procesu razvoja.

2
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

8
Usklađivanje aktivnosti, artifakta i uloga predstavlja ponovljivi workflow koji prati raz-voj
softvera kroz promene u procesu razvoja. Standardizacija workflow-a, sastavljenih od
aktivnosti, artifakta i uloga, u procesu razvoja omogućuje praćenje promena, rano otkrivanje
problema i brzo reagovanje u cilju njihovog otklanjanja.

RUP razvoj informacionih sistema postavlja između dve dimenzije, vremenske i sadr-žajne.
Vremenska dimenzija je podeljena u četiri faze: uvođenje, elaboracija, konstruk-cija i
tranzicija. Sadržajna dimenzija je podeljena u šest osnovnih i tri pomoćne disci-pline. U
osnovne spadaju disciplina poslovnog modelovanja, disciplina zahteva, disci-plina analize i
dizajna, disciplina implementacije, disciplina testiranja i disciplina ra-spoređivanja. Pomoćne
discipline su konfigurisanje i upravljanje promenama, uprav-ljanje projektom i okruženje.
Svaki element matrice RUP-a predstavlja kombinaciju e-lemenata statičke strukture RUP-a i
vremenskog rasporeda istih.

RUP je moguće posmatrati kroz dve dimenzije, kroz dinamičku u kojoj se proces opi-suje kroz
životni ciklus razvoja proizvoda i statičku u kojoj se opisuju aktivnosti i re-zultati aktivnosti
podeljeni na uloge.

Slika 3.

RUP razvojni proces predstavlja kroz ciklus od četiri faze. Kao krajnji proizvod ovog ciklusa
dobija se gotov softverski proizvod.

1.1.7. Faza uvođenja

Uvođenje predstavlja prvu fazu RUP-a. Krajnja svrha ove faze jeste stvaranje pretpo-stavki
za potpunu saradnju svih stejkholdera budućeg projekta, kao i presretanje i stav-ljanje pod

9
kontrolu većine rizika pre započinjanja razvojnih aktivnosti. U skladu sa na-vedenom
svrhom kao najznačajniji ciljevi se nameću:3

1. Definisanje, a ukoliko je moguće i demonstriranje najmanje jednog mogućeg

arhitekturalnog rešenja. Ovom aktivnošću se utvrđuje da li postoji odgovara-juća
arhitektura sistema kojom se mogu zadovoljiti tražene funkcionalnosti. Ukoliko se
uoči više arhitekturalnih solucija potrebno ih je sve predstaviti, a u kasnijim fazama
će se doneti odluka izbora optimalne arhitekture.
2. Identifikovanje troškova, utvrđivanje rasporeda izvršenja projekta. Ovo aktiv-nost
predstavlja poslovnu procenu razvoja i održavanja budućeg sistema. Na osnovu nje se
obezbeđuje odgovor na pitanje da li su projekat i rezultati pro-jekta održivi ili ne.
3. Uočavanja potencijalnih rizika, kako poslovnih tako i onih vezanih za zahteve
korisnika.
4. Priprema podrške i definisanje okruženja za razvoj projekta. Ova aktivnost
podrazumeva razradu procesa razvoja i određivanje alata koji će se koristiti.
Neophodno je da svi članovi razvojnog tima dele isti pogled na to kako će se softver
razvijati. U cilju toga se vrši razrada procesa razvoja i određuju se alati pomoću kojih
će se razvijati softverski proizvod.

U ključnoj tački faze Uvođenja, a nakon ispunjenja postvaljenih ciljeva, potrebno je znati
odgovore na sledeća pitanja:

 Da li je projekat izvodljiv?
 Da li je nivo rizika prihvatljiv?
 Da li je projekat finansijski isplativ?

Za dostizanje postavljenih ciljeva izvršavaju se aktivnosti od strane različitih uloga u

razvojnom projektu. Pri tome se koriste i kreiraju odgovarajući artifakti koji predstav-ljaju
konkretizaciju projektnih aktivnosti.

3
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

10
U prethodnom pasusu uvedeno je nekoliko novih pojmova koji će u kasnijem izlaganju biti
često upotrebljavani. To su sledeći pojmovi:

 Uloga– Uloga predstavlja centralni koncept u procesu. Ona defiše ponašanje i

odgovornost osobe ili grupe odnosno tima koji radi zajedno. Ponašanje pred-stavlja
aktivnost koje uloge izvršavaju, a svaka uloga je zadužena za određeni set aktivnosti.
 Artifakt – Artifakt je informacija koju modifikuje ili koristi neka aktivnost. Oni se
koriste kao inputi od strane uloga kako bi uloge mogle da izvrše neku aktiv-nost, a
takođe su i izlazni rezultat neke aktivnosti.
 Aktivnost – Aktivnost je deo procesa rada koju neka uloga izvršava. Aktivnosti se
odnose na kreiranje, modifikovanje artifakata kao što su modeli, klase i pla-novi.
Svaka aktivnost je sastavni deo jedne uloge.

Ovo su ključni pojmovi pri izvršavanju projektnih aktivnosti. U nastavku je prikazan

workflow Uvođenja faze po Rational Unified Process-u. Svaki od prikazanih koraka se
sprovodi od strane uloga u projektu, koje realizuju aktivnosti i pri tome koriste i grade
artifakte, te na takav način grade softverski projekat.

11
 2. Koraci u fazi uvođenja

Slika 4.

Koraci koji se sprovode u fazi uvođenja su:

1. Razumevanje novog projekta;

2. Priprema projektnog okruženja;
3. Procena poslovnog statusa;
4. Priprema okruženja za iteraciju;
5. Definisanje projektnih planova;
6. Nadgledanje i kontrola projekta;
7. Razvoj početne vizije;
8. Definisanje sistema;
9. Definisanje misije ocenjivanja;
10. Upravljanje obimom sistema;
11. Rad na arhitekturalnoj sintezi;
12. Razvoj problemskog modela;
13. Upravljanje iteracijama i
14. Planiranje naredne iteracije4

4
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

9
 3. Faza elaboracije

Faza Elaboracije predstavlja drugu fazu životnog ciklusa razvoja proizvoda po RUP-u.
Krajnja svrha faze Elaboracije jeste obezbeđivanje takve arhitekturalne osnove koja će
obezbediti stabilno i neometano sprovođenje aktivnosti u fazama Konstrukcije i Tran-
zicije. Na ovakav način se vrši značajna mitigacija rizika u tehničko tehnološkom do-
menu razvojnog projekta. Do stabilnosti arhitekture se dolazi kroz ocenjivanje jedne ili
više arhitekturalnih alternativa, uvažavajući pri tome ključne zahteve, čije zadovoljenje
zavisi od arhitekturalne osnove budućeg rešenja. Do postizanja krajnje svrhe faze Ela-
boracije se dolazi kroz dostizanje primarnih ciljeva:

 Obezbeđenje takve usklađenosti arhitekture, zahteva i planova koja će obez-bediti

mogućnost predviđanja troškova i rasporeda izvršenja aktivnosti do sa-mog završetka
projekta.
 Identifikovanje svih arhitekturalno značajnih rizika u projektu.
 Uspostavljanje osnovne arhitekture na osnovu analize svih arhitekturalno zna-čajnih scenarija
za izvršenje funkcionalnosti budućeg sistema.
 Izrada razvojnog prototipa sačinjenog od razvojnih komponenti, koje će biti upotrebljene
u procesu razvoja, a eventualno i u nekom kasnijem razvojnom procesu. Na takav način se
postiže ublažavanje rizika vezano za ponovnu upo-trebu komponenti, kao i za
demonstriranje izvodljivosti pred investitorima i/ili krajnjim korisnicima.
 Demonstriranje takve osnovne arhitekture koja će obezbediti zadovoljenje zahteva u
razumnom vremenskom roku i u okviru razumnog budžeta.

U ključnoj tački faze Elaboracije potrebno je postići sledeće:

 Dokument vizije i zahtevi treba da su čvrsto definisani.

 Arhitektura treba da je čvrsto definisana.
 Ključni pristupi koji će biti korišćeni u testiranju i ocenjivanju treba da su odo-breni.
 Kroz testiranje i ocenjivanje izvršnog prototipa potrebno je prikazati da su ključni rizici
identifikovani i da postoji značajna verovatnoća da će biti rešeni.
 Plan iteracija za fazu Konstrukcije treba da je detaljno razrađen da se sa sigur-nošću može
nastaviti proces razvoja.

10
  Saglasnost ključnih stejkholdera da je definisanu Viziju moguće postići ukoliko postojeći
planovi budu uspešno sprovedeni, posmatrano u kontekstu razvijene arhitekture.
 Stvarni utrošak resursa postavljen u odnos sa planiranim utroškom resursa treba da je
prihvatljiv.

3.1. Koraci u fazi elaboracije

Slika 5.5
Koraci koji se sprovode u fazi uvođenja su:

1. Priprema okruženja za iteraciju;

2. Izmena i zaključivanje projektnih planova;
3. Tekuće upravljanje i podrška;
4. Dorađivanje definicije sistema;
5. Definisanje predloga arhitekture;
6. Dorađivanje arhitekture;
7. Izrada komponenti;
8. Izrada materijala za podršku;
9. Integracija i testiranje i
10. Planiranje naredne iteracije

5
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

11
 4. Faza konstrukcije

Krajnja svrha faze Konstrukcije jeste dostizanje potpune razumljivosti zahteva i kom-
pletiranje razvoja sistema, poštujući unapred definisanu arhitekturu sistema. Faza
Konstrukcije se može posmatrati kao proizvodna faza u kojoj se na osnovu dobro raz-
rađenog modela (dobijenog kroz prethodne faze) izrađuje u potpunosti upotrebljiv
proizvod, koji će biti završen kroz faze Konstrukcije i Tranzicije.

 Ciljevi koje je potrebno ispuniti tokom ove faze su sledeći:

 Minimiziranje razvojnih troškova kroz optimizaciju resursa;
 Dostizanje paralelizma u radu razvojnih timova;
 Dostizanje odgovarajućeg kvaliteta proizvoda;
 Dostizanje upotrebljive verzije proizvoda, kroz izbacivanje i testiranje verzija;
 Iterativno i inkrementalno razvijanje proizvoda sve do dostizanja njegove spremnosti za
transfer u ruke korisnika;
 Prepoznavanje trenutka u kojem su i proizvod i korisnici spremni za isporuku.

4.1. Koraci u fazi konstrukcije

Slika 6.
Na slici 6. je prikazan workflow faze Konstrukcije. Koraci koje je potrebno realizovati uovoj fazi su
sledeći:

1. Priprema okruženja za iteraciju;

2. Izrada komponenti;

6
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

12
 3. Izrada materijala za podršku;
4. Tekuće održavanje i podrška;
5. Integracija i testiranje;
6. Planiranje naredne iteracije i
7. Generisanje paketa za raspoređivanje.

5. Faza Tranzicije

Glavni zadatak faze Tranzicije jeste da se softverski proizvod koji se razvija učini
dostupnim za korišćenje krajnjim korisnicima. Kroz fazu Tranzicije potrebno je spro-vesti
i testiranje proizvoda kao obaveznu aktivnost u pripremi za isporuku. Povratne informacije
koje se dobiju kroz takav vid testiranja mogu poslužiti za manje korekcije proizvoda. Na
kraju ove faze proizvod treba da je isporučen krajnjem korisniku, a pro-jekat treba da je u
potpunosti spreman za zatvaranje. U nekim slučajevima kada proiz-vod nije razvijen u
skladu sa zahtevima korisnika, a kada korekcije potrebne da se do-vede u željeno stanje
nisu male, neophodno je pokretanje novog životnog ciklusa za razvoj proizvoda (slika 7.).

Slika 7.

7
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

13
Faza Tranzicije može da bude vrlo jednostavna, najčešće kod projekata koji su se bavili
razvojem nove verzije postojećeg proizvoda, ili vrlo kompleksna, kod velikih i sigurno-sno
zahtevnih sistema. Međutim, postoje operativni ciljevi koji se moraju zadovoljiti u svakom od
navedenih slučajeva:

 Beta testiranje treba da potvrdi da je novi proizvod u skladu sa očekivanjima korisnika,

 Beta testiranje se treba sprovesti paralelno sa funkcionisanjem postojećeg proizvoda koji
će biti zamenjen,
 Potrebno je izvršiti konverziju operativne baze podataka,
 Potrebno je sprovesti trening korisnika i osoba koje će vršiti održavanje pro-izvoda,
 Potrebno je pripremiti marketinške, distributivne i prodajne aktivnosti,
 Potrebno je sprovesti aktivnosti za fino podešavanje proizvoda, poput popravke grešaka (bug
fixing) i unapređenja proizvoda u smislu podizanja performantnosti i upotrebljivosti,
 Neophodno je sprovesti procenu uočenih karakteristika proizvoda pri raspo-ređivanju u
odnosu na definisanu viziju proizvoda i kriterijume prihvatljivosti proizvoda,
 Korisnike je potrebno obučiti do te mere da mogu određene probleme samo-stalno
rešavati,
 Od korisnika je potrebno dobiti saglasnost da je proizvod raspoređen i spre-man za
upotrebu,
 Takođe, od korisnika je potrebno dobiti saglasnost da raspoređeni proizvod odgovara
kriterijumima u čijem postavljanju su oni učestvovali i koji su defini-sani kroz dokument
vizije.

Faza Tranzicije se, kao što je prikazano na slici 8., sprovodi u jednoj ili više iteracija. Kada se
sprovedu sve planirane iteracije stanje artifakta bi trebalo biti u skladu sa pla-niranim. Stanje u
ključnoj tački u ovoj fazi je najprepoznatljivije, jer svi artifakti treba da su kompletirani i
proizvod treba da je isporučen.

Slika 8.

8
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

14
 5.1. Koraci u fazi tranzicije

Slika 9.

U fazi tranzicije potrebno je realizovati sledeće korake:

1. Priprema okruženja za iteraciju;

2. Otklanjanje grešaka u komponentama ;
3. Planiranje raspoređivanja;
4. Izrada preostalih komponenti
5. Integracija i testiranje;
6. Tekuće održavanje i podrška;
7. Izrada preostalih materijala za podršku;
8. Upravljanje testom za utvrđivanje prihvatljivosti;
9. Beta testiranje;
10. Završna priprema proizvoda za isporuku;
11. Planiranje naredne iteracije i
12. Zaključivanje projekta.

9
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-
ukratko.pdf

15
 6. Jedinstveni jezik za modelovanje UML (Unified Modeling Language)

6.1. Šta je to UML?10

UML je jedna o najpoznatijih skraćenica u informatičkom svetu. Skraćenica potiče od englskog

termina Unified Modeling Language, što u prevodu znači jedinstveni jezik za modelovanje.
Najuopštenija definicija UML-a bi mogla biti sledeća. UML predstavlja je-dinstveni jezik za
vizuelizaciju, specifikaciju, konstrukciju i dokumentaciju softverskih sistema.

Jezik za modelovanje može biti bilo koji opis koji pomaže izgradnji sistema. Taj opis, govoreći o
softverskim proizvodima, može biti predstavljen pseudo kodom, dijagra-mima, slikama,
tekstualnim opisima, itd. Elementi kojima se vrši modelovanje čine no-taciju za modelovanje.
Ukoliko se kao elementi koriste grafički simboli jezik za mode-lovanje je grafičkog tipa, tj.
grafički jezik za modelovanje. UML poseduje grafičku nota-ciju, te se može kategorizovati kao
grafički jezik za modelovanje.

Grafički jezici poput UML-a koriste se već dugo u softverskoj industriji. Međutim ono što je
specifično za sve te grafičke jezike, preteče UML-a, jeste njihova neusaglašenost. Upravo ta
neusaglašenost je bila inicijalna kapsula koja je uticala na nastanak UML-a i koja pomaže da se
razumeju kvaliteti koje je UML doneo svojim nastankom softverskoj industriji.

UML je nastao kao posledica saradnje Grady Booch-a, Jamesa Rumbaugh-a i Ivar Jacob-son-a.
Svako od njih se bavio razvojem sopstvenih notacija, a njihovim ujedinjenjem, pod okriljem
kompanije „Rational Software“, nastao je UML. Popularan naziv za trojicu idejnih tvoraca UML
je „tri amigosa“. Danas kompanija „Rational Software“ posluje kao deo IBM-a.

UML danas predstavlja relativno otvoren standard, kontrolisan od strane Object Mana-gement
Group (u nastavku OMG), nezavisnog konzorcijuma kompanija koji upravlja standardima u
objektno orijentisanom razvoju. Najnovije specifikacije UML je moguće pronaći na sajtu OMG-
a, www.omg.org. Istorijski posmatrano UML je nastao ujedinjenjem sledećih pristupa:

 Object-Oriented Analysis and Design (OOAD), čiji je tvorac Grady Booch,

 Object-Oriented Software Engineering (OOSE), čiji je tvorac Ivar Jacobson,
 Object Modeling Technique (OMT), čiji je tvorac James Rumbaugh,

10
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

16
  Probrane objektno orijentisane tehnike, dodatne tehnike koje su se inicijalno našle u
UML-u.

Inicijativa za stvaranje UML-a je krenula još 1996. godine, kao pokušaj da se prevaziđe rat
objektnih notacija, te da se jedna notacija nametne kao standard. Kao kompanija za realizaciju
ovoga projekata nametnula se „Rational Software“ korporacija. To nije bilojednostavno, te je za
ovakav izbor bila potrebna saglasnost velikih softverskih giganata poput IBM-a ili Microsoft-a.
Zajednički interes je doneo prevagu, te „Rational Software“ korporacija ujedinjuje Boocha-a,
Jacobson-a i Rumbaugh-a, te izbacuje UML kao jedin-stveni jezik za modelovanje. U saradnji sa
OMG-om UML se 1997. godine nameće kao standard, a njegov munjevit razvoj dokazuje
opravdanost političkog delovanja na raz-voju UML-a. Trenutno aktuelna verzija UML-a je 2.0.

17
 7. Literatura

 Wikipedia11
 Rational Team, 200512
 IBM Developer – Rational - Library13

11
https://en.wikipedia.org/wiki/Rational_Unified_Process
12
http://www.ef.uns.ac.rs/predmeti/oas/procesi-razvoja-softvera/Beleske-sa-predavanja-RUP-UML-ukratko.pdf
13
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

18