Unificirani proces– ovo je generalizirani okvir procesa stvaranja softvera koji se može specijaliziran za širok raspon softverskih sustava. Unificirani proces koristi jedinstveni jezik za modeliranje za razvoj modela softverskog sustava.

počnite napadati glavne rizike, provodite to kontinuirano, inače će rizici napasti vas.

osigurati ispunjenje zahtjeva kupaca: dokumentirati zahtjeve na način koji kupac može razumjeti i strogo se pridržavati tih zahtjeva tijekom projektiranja i implementacije

usredotočite se na program koji vam je pri ruci: trčanje softver polaganje testova bolje od sveobuhvatne dokumentacije

prilagoditi se promjenama od samog početka projekta: moderne aplikacije dovoljno su složene da specifične zahtjeve možemo dobiti na samom početku razvoja. Stoga je potrebno projektirati arhitekturu softvera na takav način da bude podložna promjenama.

postaviti temelje izvršne arhitekture što je prije moguće. Izvršna arhitektura - ključni slučajevi korištenja. Ključni VI je funkcionalnost sustava bez koje softver nema smisla. Ključ. VI čine 7-10% svih opcija

izgraditi sustav od komponenti. Aplikacije koje se temelje na komponentama izrađuju se brže, fleksibilnije su u smislu promjena i relativno su jeftine.

raditi kao 1 tim

neka kvaliteta bude način života, a ne naknadna misao

6 Životni ciklus objedinjenog procesa. Ciljevi svake faze.

Objedinjeni proces se ciklički ponavlja. Ovaj niz iteracija Unificiranog procesa predstavlja životni ciklus sustava. Svaki ciklus završava isporukom izdanja proizvoda kupcima.

Svaki ciklus sastoji se od četiri faze - analiza zahtjeva i planiranje, dizajn, izgradnja i implementacija. Svaka faza, kao što je objašnjeno u nastavku, dalje je podijeljena na iteracije.

Tijekom faze analize i planiranja zahtjevi dobra ideja pretvara u koncept za gotov proizvod i izrađuje se poslovni plan za razvoj tog proizvoda. Konkretno, u ovoj fazi treba odgovoriti na sljedeća pitanja:

Što bi sustav prvo trebao učiniti za svoje primarne korisnike?

Kako bi trebala izgledati arhitektura sustava?

Kakav je plan i koliko će koštati razvoj proizvoda?

U ovoj fazi izrađuje se probna verzija arhitekture. Obično je to nacrt koji sadrži najvažnije podsustave. Tijekom ove faze identificiraju se i utvrđuju prioriteti najvažniji rizici, detaljno se planira faza projektiranja i okvirno procjenjuje cjelokupni projekt.

Tijekom faze projektiranja većina slučajeva korištenja je detaljno opisana i razvijena je arhitektura sustava.

Na kraju faze projektiranja, voditelj projekta bavi se aktivnostima planiranja i izračunavanjem resursa potrebnih za dovršetak projekta. Ključno pitanje u ovom trenutku bit će: jesu li slučajevi upotrebe, arhitektura i dizajn dovoljno zreli i jesu li rizici pod dovoljnom kontrolom da opravdaju ugovornu obvezu dovršetka razvojnog rada?

Tijekom faze izgradnje nastaje proizvod - na kostur (arhitekturu) dodaju se mišići (završeni programi). Tijekom ove faze osnovna razina arhitekture prerasta u potpuni zreli sustav. Koncepti se razvijaju u proizvod spreman za predaju korisnicima. Tijekom faze povećava se količina potrebnih resursa. Na kraju ove faze, proizvod uključuje sve slučajeve upotrebe koje su se uprava i kupac dogovorili uključiti u trenutno izdanje. Istina, mogu sadržavati pogreške. Većina nedostataka će se otkriti i ispraviti tijekom faze implementacije. Ključno pitanje na kraju faze je: Zadovoljava li proizvod zahtjeve korisnika do te mjere da se nekim kupcima može isporučiti unaprijed?

Faza implementacije pokriva razdoblje tijekom kojeg proizvod postoji kao beta izdanje ili beta verzija. Mali broj kvalificiranih korisnika koji rade s beta izdanjem proizvoda izvješćuju o greškama i nedostacima. Programeri zatim ispravljaju sve pogreške koje pronađu i ugrađuju neka od predloženih poboljšanja u glavno izdanje koje je spremno za široku distribuciju. Faza implementacije uključuje aktivnosti kao što su izrada kopija, obuka zaposlenika kupaca, organiziranje telefonske podrške i ispravljanje nedostataka otkrivenih nakon isporuke.

Racionalni objedinjeni proces (RUP)- metodologija izrade softver, stvoreno od Rational Softver.

Principi: Rano prepoznavanje i kontinuirano (do kraja projekta) otklanjanje glavnih rizika. Koncentracija na ispunjavanje zahtjeva korisnika za izvršni program (analiza i izgradnja modela presedana (use case)). Očekujte promjene u zahtjevima, dizajnerskim odlukama i implementaciji tijekom procesa razvoja. Komponentna arhitektura implementirana i testirana u ranoj fazi projekta. Kontinuirano osiguranje kvalitete u svim fazama razvoja projekta (proizvoda).

Rad na projektu u uskom timu u kojem arhitekti imaju ključnu ulogu.

RUP koristi iterativni razvojni model. Na kraju svake iteracije (idealno u trajanju od 2 do 6 tjedana), projektni tim treba postići ciljeve planirane za ovu iteraciju, izraditi ili doraditi artefakte dizajna i dobiti srednju, ali funkcionalnu verziju konačnog proizvoda.

Kompletan životni ciklus razvoja proizvoda sastoji se od četiri faze, od kojih svaka uključuje jednu ili više iteracija: početnu fazu, fazu pojašnjenja, dizajna i implementacije.

Ekstremno programiranje (XP)

Ekstremno programiranje(Extreme Programming, XP) - jedna od fleksibilnih metodologija razvoja softvera

12 osnovnih tehnika ekstremno programiranje (prema prvom izdanju knjige Ekstremno programiranje objašnjeno) može se kombinirati u četiri skupine:

Kratki ciklus Povratne informacije: (Razvoj vođen testom, Igra planiranja, Kupac je uvijek tu, Programiranje u paru

Kontinuirani, a ne serijski proces: Kontinuirana integracija, refaktoriranje, česta mala izdanja

Razumijevanje koje dijele svi: Jednostavnost, metafora sustava, kolektivno vlasništvo nad kodom ili odabranim uzorcima dizajna, standard kodiranja

Socijalna sigurnost programera: 40 sati radni tjedan

Programiranje u paru uključuje sav kod koji stvaraju parovi programera koji rade na istom računalu. Kolektivno vlasništvo znači da je svaki član tima odgovoran za sav izvorni kod. "Kupac" u XP-u nije onaj koji plaća račune, već onaj koji stvarno koristi sustav.

Standardi dokumentacije

Standardi osiguravaju kompatibilnost između projekata. Standardi poboljšavaju razumijevanje među inženjerima. Inženjeri bi standarde trebali doživljavati kao nešto što im je korisno, a ne kao skup prepreka. Jasni i mjerljivi ciljevi koji zahtijevaju discipliniran i dokumentiran pristup obično su dobar motivator za programere

SVVP- Plan određuje kako i kojim redoslijedom treba testirati faze projekta. Verifikacija je proces provjere je li aplikacija ispravno izgrađena. Validacija potvrđuje da je traženi proizvod sastavljen.

SQAP- Plan kontrole kvalitete softvera

SCMP- Plan upravljanja softverski projekt

SRS- Specifikacija softverskih zahtjeva

SDD- Projektna dokumentacija softvera

STD- Dokumentacija o testiranju softvera

Dosljednost i cjelovitost dokumentacije.

Upravljanje dokumentima zahtijeva značajne organizacijske vještine. Pisanje dobre i fleksibilne dokumentacije slično je pisanju dobrog i fleksibilnog koda.

Upravljanje dokumentima znači njihovo održavanje potpunost I dosljednost a također uključuje konfiguracijski menadžment.

Potpunost – dostupnost skupa dokumentacije koja pokriva proces razvoja i održavanja.

Dosljednost znači da skup dokumenata ne sadrži unutarnje proturječnosti. Problem je u tome što kada je ovaj skup velik, prilično je teško izbjeći pojavu međusobno isključivih izjava u njemu.

Konfiguracijska podrška – to je koordinacija različitih verzija i dijelova dokumentacije i programskog koda.

RUP je primjer tzv "težak" proces, detaljno opisano i sugerira podršku za stvarni razvoj izvornog koda softvera s velikim brojem pomoćnih radnji. Primjeri takvih aktivnosti su izrada planova, tehničke zadatke, brojni modeli dizajna, projektna dokumentacija itd. Glavni cilj ovog procesa je odvojiti uspješne prakse razvoja i održavanja softvera od određenih ljudi koji ih znaju primijeniti. Brojne akcije podrške daju nadu da će to biti moguće uspješno rješenje poslove izgradnje i podrške složenim sustavima uz pomoć postojećih radnika, koji nisu nužno superprofesionalci.

Da bi se to postiglo, provodi se hijerarhijski detaljan opis radnji poduzetih u određenoj situaciji, korak po korak, tako da se obični radnik može naučiti postupati na sličan način. Tijekom projekta stvaraju se mnogi međudokumenti koji programerima omogućuju da zadatke s kojima se suočavaju sekvencijalno raščlane na jednostavnije. Isti ti dokumenti služe za provjeru ispravnosti odluka donesenih u svakom koraku, kao i za praćenje cjelokupnog napretka rada i pojašnjenje procjena resursa potrebnih za postizanje željenih rezultata.

Ekstremno programiranje, naprotiv, predstavlja tzv "žive" (agilne) razvojne metode, također zvan "svjetlo" procesima. Naglašavaju korištenje dobrih programera umjesto dobrih razvojnih procesa. Žive metode izbjegavaju obvezivanje na jasne nacrte kako bi se omogućila veća fleksibilnost od projekta do projekta, a također obeshrabruju razvoj dodatnih dokumenata koji izravno ne doprinose gotovom, radnom programu.

Racionalni objedinjeni proces

RUP je dosta složen, detaljan iterativni model životnog ciklusa OD .

Povijesno gledano, RUP je razvoj modela razvojnog procesa koji je Ericsson usvojio 70-ih i 80-ih godina 20. stoljeća. Ovaj model je kreirao Ivar Jacobson, koji je kasnije, 1987. godine, osnovao vlastitu tvrtku Objectory AB posebno za razvoj tehnološki proces razvoj softvera kao zasebnog proizvoda koji bi se mogao prenijeti na druge organizacije. Nakon što je Objectory spojen s Rationalom 1995., Jacobsonov razvoj integriran je s radom Roycea (Walker Royce, sin autora "klasičnih" kaskadni model), Kruchten (Philippe Kruchten) i Booch (Grady Booch), kao i uz paralelni razvoj univerzalni jezik za modeliranje (Unified Modeling Language, UML).

RUP se temelji na tri ključne ideje:

Cijeli tijek rada vođen je konačnim ciljevima projekta, izraženim u obrascu slučajevi upotrebe- scenarije interakcije rezultirajućeg softverskog sustava s korisnicima ili drugim sustavima, tijekom kojih korisnici dobivaju rezultate i usluge koje su im značajne. Razvoj počinje identifikacijom slučajeva korištenja iu svakom se koraku kontrolira stupanj bliskosti njihovoj implementaciji.

• Glavna odluka donesena tijekom projekta je arhitektura rezultirajući softverski sustav. Arhitektura utvrđuje skup komponenti od kojih će se softver graditi, odgovornosti svake komponente (tj. podzadatke koje rješava unutar okvira ukupnih zadataka sustava), jasno definira sučelja preko kojih mogu komunicirati, kao kao i kako komponente međusobno djeluju.

  Arhitektura je i osnova za dobivanje kvalitetnog softvera i osnova za planiranje rada i procjenu projekta u smislu vremena i resursa potrebnih za postizanje određenih rezultata. Dolazi u obliku seta grafički modeli u UML jeziku.

• Osnova procesa razvoja je planirani I vođene iteracije, čiji se opseg (funkcionalnost implementirana unutar iteracije i skup komponenti) određuje na temelju arhitekture.

Unificirani proces(UP) je generalizirano okvir proces koji se može specijalizirati za širok raspon softverskih sustava, različita područja primjene, razine vještina i veličine projekata.

Unificirani proces orijentiran na komponente. To znači da je kreirani programski sustav izgrađen na bazi softvera komponente, povezani dobro definiranim sučeljima.

Specifični aspekti UP-a leže u njegove tri karakteristike:

● vođen slučajevima korištenja;

● arhitektonski je orijentiran;

● je iterativan i inkrementalan .

Životni ciklus objedinjenog procesa

Životni ciklus UP-a podijeljen je na cikluse, od kojih svaki kulminira isporukom izdanja proizvoda. Svaki razvojni ciklus sastoji se od četiri faze - analiza zahtjeva i planiranje, dizajn, izgradnja, implementacija. Svaka faza je podijeljena na ponavljanja.

UP uključuje osam radnih procesa: pet glavnih- definiranje zahtjeva, analiza, dizajn, implementacija, testiranje i tri pomoćna (za podršku glavnim) - upravljanje konfiguracijom i promjenama zahtjeva, upravljanje projektima, upravljanje okolinom.

Da biste definirali strukturu tijeka rada, prvo morate odrediti što vrste izvođača sudjelovati u procesu. Zatim odredio artefakti, koje svaka vrsta radnika mora izraditi tijekom određenog tijeka rada.

18. XP je proces.

Ekstremno programiranje(engleski: Extreme Programming, XP) jedna je od fleksibilnih metodologija razvoja softvera. Autori metodologije su Kent Beck, Ward Cunningham, Martin Fowler i drugi.

Dvanaest osnovnih tehnika ekstremnog programiranja (prema prvom izdanju knjige Ekstremno programiranje objašnjeno) može se kombinirati u četiri skupine:

1. Kratki povratni ciklus (fina povratna informacija)

a. Testom vođen razvoj

b. Igra planiranja

c. Kupac je uvijek u blizini (cijeli tim, kupac na licu mjesta)

d. Programiranje u parovima

2. Kontinuirani, a ne serijski proces

a. Kontinuirana integracija

b. Refactoring (Poboljšanje dizajna, Refactor)

c. Česta mala izdanja

3. Razumijevanje koje dijele svi

a. Jednostavnost (jednostavan dizajn)

b. Komunikacija

c. Poštovanje

d. Kolektivno vlasništvo koda ili odabranih uzoraka dizajna (kolektivno vlasništvo uzoraka)

e. Standard kodiranja ili konvencije kodiranja

4. Dobrobit programera:

a. 40-satni radni tjedan (održivi tempo, četrdesetosatni radni tjedan)

U XP-u je proces podijeljen u vrlo male korake u usporedbi s planiranim procesima. To rezultira time da su prvi koraci potrebni danima ili tjednima umjesto mjesecima ili čak godinama za svaki korak u modelu vodopada. Prvo se pišu automatizirani testovi koji opisuju razvojne ciljeve. Zatim dolazi kodiranje koje završava u trenutku kada svi testovi prođu i programeri ne mogu smisliti nove testove. Dizajn rade isti ljudi koji pišu kod. (samo je posljednji korak - povezivanje dizajna i koda - zajednički svim agilnim procesima). Nedovršeni, ali funkcionalni sustav prikazuje se uskom krugu korisnika (najčešće su to sami programeri). U ovoj točki počinju pisati testove za sljedeći najvažniji dio sustava.

19. ICONIX je proces.

ICONIX je razvio Doug Rosenberg u ICONIX softver Proces ICONIX temelji se na slučaju upotrebe, ali nema mnogo svojih nedostataka. Ovaj proces također koristi jezik za modeliranje UML, ali koristi se samo osnovna notacija iz UML-a - to je 20% jezika. Proces ICONIX temelji se na četiri glavna koraka razvoja softvera temeljena na slučaju upotrebe:

● modeliranje domene;

● modeliranje presedana;

● analiza prikladnosti zahtjeva (provjera ispunjenja svih funkcionalnih zahtjeva);

● konstrukcija dijagrama sekvenci.

Glavne faze procesa su sljedeće:

● Analiza zahtjeva

● Idejni projekt

● Dizajn

● Implementacija

Proces se temelji na izgradnji minimalnog broja modela koji odražavaju budući sustav. U fazi analize kreiraju se modeli slučajeva korištenja, model korisničkog sučelja i model entiteta domene. Tijekom faze preliminarnog projektiranja izrađuje se dijagram robusnosti. Model presedana i model entiteta domene također se nadopunjuju. Tijekom faze detaljnog projektiranja kreira se sekvencijski dijagram (SequenceDiagram) i kreira se dijagram klasa. Tijekom faze implementacije kreira se izvorni kod. Također možete izraditi dijagram postavljanja i dijagram komponenti. svaka faza kulminira prekretnicom pregleda gdje se o generiranim dijagramima treba raspravljati s kolegama.

20. SCRUM je proces.

Scrum je skup načela na kojima je izgrađen razvojni proces, dopuštajući strogo fiksna kratka vremenska razdoblja ( sprintevi od 2 do 4 tjedna) pružaju krajnjem korisniku radni softver s novim značajkama koje imaju najveći prioritet. Mogućnosti softvera za implementaciju u sljedećem sprintu određuju se na početku sprinta u fazi planiranja i ne mogu se mijenjati tijekom cijelog njegovog trajanja. Istodobno, strogo fiksno kratko trajanje sprinta daje razvojnom procesu predvidljivost i fleksibilnost.

Glavne glumačke uloge u Scrumu: ScrumMaster- onaj koji vodi Ološ okuplja i osigurava poštivanje svih načela Ološ(uloga ne podrazumijeva ništa osim ispravnog ponašanja Ološ-ah, radije se odnosi na voditelja projekta Vlasnik proizvoda a ne bi trebalo biti ScrumMaster);Vlasnik proizvoda (Vlasnik proizvoda) - osoba koja zastupa interese krajnjih korisnika i drugih strana zainteresiranih za proizvod; i međufunkcionalni Tim (Scrum tim), koji se sastoji od programera i testera, arhitekata, analitičara itd. (s idealnom veličinom tima od 7±2 osobe). Tim je jedini potpuno uključeni sudionik u razvoju, te je odgovoran za rezultat kao jedinstvena cjelina. Nitko osim tima ne može ometati razvojni proces tijekom sprinta.

Tijekom svakog sprinta stvara se funkcionalni rast softvera. Skup značajki koje se isporučuju u svakom sprintu dolazi iz faze tzv zaostatak proizvoda(dokumentacija radnih zahtjeva) koji ima najveći prioritet u pogledu razine radnih zahtjeva koji se moraju izvršiti. Molbe za posao ( zaostale stavke), određen u cijelosti vijeće za planiranje sprinta (sastanak za planiranje sprinta), premještaju se u fazu sprinta. Tijekom ovog sastanka, Product Owner priopćava zadatke koje je potrebno izvršiti. Tim zatim određuje koliko od onoga što žele postići kako bi dovršili potrebne dijelove tijekom sljedećeg sprinta. Tijekom sprinta tim ispunjava određeni fiksni popis zadataka (tzv. sprinterski zaostatak). U tom razdoblju nitko nema pravo mijenjati popis uvjeta za posao, što treba shvatiti kao zahtjeve za zamrzavanje ( zahtjevi) tijekom sprinta.

Artefakti

Zaostatak proizvoda je dokument koji sadrži popis funkcionalnih zahtjeva poredanih po važnosti. Zaostatak proizvoda popis je onoga što treba isporučiti. Stavke na ovom popisu nazivaju se "priče" ( korisnička priča) ili elementi zaostataka ( zaostale stavke). Zaostatak proizvoda otvoren je za uređivanje svim sudionicima u Scrum procesu.

Uvod

Rational Unified Process (RUP) jedna je od spiralnih metodologija razvoja softvera. Metodologiju podržava Rational Software, a proizvod se ažurira otprilike dva puta godišnje. Kao modelni jezik u zajednička baza znanja, koristi se Unified Modeling Language (UML).

Iterativni razvoj softvera u RUP-u uključuje podjelu projekta na nekoliko malih projekata koji se provode uzastopno, a svaka razvojna iteracija jasno je definirana skupom ciljeva koji se moraju postići na kraju iteracije. Konačna iteracija pretpostavlja da se skup ciljeva iteracije mora točno podudarati sa skupom ciljeva koje je specificirao kupac proizvoda, odnosno moraju biti ispunjeni svi zahtjevi.

RUP je dosta dobro formaliziran, a najveća pozornost posvećena je početnim fazama razvoja projekta – analizi i modeliranju. Stoga je ova metodologija usmjerena na smanjenje komercijalnih rizika (ublažavanje rizika) otkrivanjem pogrešaka u ranim fazama razvoja. Tehnički rizici procjenjuju se i utvrđuju prioriteti rano u razvojnom ciklusu, a zatim se revidiraju tijekom vremena i kako se projekt razvija kroz sljedeće iteracije. Ovisno o prioritetima tih rizika pojavljuju se novi ciljevi. Izdanja verzija distribuiraju se na takav način da se prvo rješavaju rizici s najvećim prioritetom.

Proces uključuje evoluciju modela; iteracija razvojnog ciklusa jedinstveno odgovara specifičnoj verziji softverskog modela. Svaka iteracija (workflow) sadrži elemente upravljanja životnim ciklusom softvera: analizu i dizajn (modeliranje), implementaciju, integraciju, testiranje, implementaciju. U tom smislu, RUP je implementacija spiralnog modela, iako se često prikazuje kao tablični grafikon. U nastavku predstavljamo glavne komponente procesa.

Za uspješan proces Razvoj zahtijeva tri komponente (slika 1): proces, notaciju i skup pomoćnih programa. Proces opisuje što radimo, kojim redoslijedom i na koji način; zapis je sredstvo komunikacije; skup uslužnih programa pomaže automatizirati i upravljati procesom.

Riža. 1. Trokut uspjeha

RUP sadrži sve tri komponente. Prvo, pogledajmo funkcije notacije koje rade sljedeće:

Provodi "lijepljenje" procesa u jednu cjelinu;

Jezično je sredstvo za donošenje odluka koje nisu očite iz izvornog koda;

Pruža semantiku za predstavljanje važnih strateških i taktičkih odluka;

Nudi obrazac dovoljan za promišljanje, a zatim i donošenje odluka i sredstva za automatizaciju procesa kako bi se manipuliralo formaliziranim podacima.

Zapravo, notacija pokriva razvoj softvera, od analize do implementacije proizvoda. Notacija u slučaju RUP–UML je formalno jezično sredstvo za opisivanje procesa (UML će biti raspravljen u nastavku). Zatim ćemo razmotriti strukturu procesa, a također ćemo dati skup pomoćnih programa koji se koriste u procesu upravljanja razvojem projekta prema RUP-u.

RUP struktura

UP pruža strukturirani pristup iterativnom razvoju softvera, dijeleći proces na četiri prekretnice tijekom vremena: početak, razrada, izgradnja i prijelaz. Nažalost, ne postoji ustaljena terminologija na ruskom jeziku, pa ćemo ubuduće koristiti engleske termine, popraćene njihovim prijevodom na ruski. Na sl. Slika 2 je naširoko korišten prikaz RUP faza. Ciljevi svake od ovih faza su:

Početno razumijevanje onoga što stvaramo. Faza prikupljanja informacija i analize zahtjeva, definiranje imidža projekta u cjelini;

Razrada razumijevanje kako ga stvaramo. Analiza zahtjeva i faza projektiranja sustava, planiranje potrebnih aktivnosti i resursa, specifikacija funkcija i značajki dizajna;

Izrada konstrukcije beta verzije proizvoda. Glavna faza razvoja i kodiranja, izgradnja proizvoda kao uzlazni niz iteracija (verzije koda);

Prijelazna izrada konačne verzije proizvoda. Faza uvođenja proizvoda, isporuka proizvoda određenom korisniku.

Riža. 2. RUP faze

To su faze upravljanja evolucijom proizvoda – iteracije životnog ciklusa. RUP podrazumijeva približavanje konačnom cilju, ali za razliku od klasičnog ISO standarda (waterfall metodologija), gdje je tranzicija završna faza, svaka se faza može ponoviti nekoliko puta, odražavajući promjene u zahtjevima kupca za proizvodom.

RUP metodologija temelji se na devet glavnih tokova rada, koji su elementi iteracije životnog ciklusa softvera:

Poslovno modeliranje (poslovna analiza) - uključuje analizu zahtjeva u zadanoj iteraciji životnog ciklusa, određivanje željenih parametara sustava i potreba korisnika;

Formalizacija zahtjeva za sliku sustava. Uključuje prikupljanje i upravljanje zahtjevima, prevođenje zahtjeva u funkcionalne specifikacije. Ovdje počinje analiza presedana i konstrukcija slučajeva korištenja (user stories) formalnog mapiranja korisničkih zahtjeva u UML-u. Rezultat su dokumenti na razini upravljanja;

Analiza i dizajn (analiza i modeliranje) – uključuje prevođenje prikupljenih zahtjeva u formalizirani programski model. Rezultat je opis sustava u fazi implementacije ( tehnički projekt) dokumenti su na razini programera sustava. Jezik formalizacije je Unified Modeling Language (UML), o kojem će biti riječi u nastavku. U procesu iterativnog razvoja, proizvod ovog određenog toka - projektni model - će se razvijati. Sve promjene u RUP-u izravno su povezane s modelima, a alati za automatizaciju i prilično fleksibilan jezik za modeliranje omogućuju vam da upravljate ovim procesom manje-više bezbolno u smislu vremena i resursa. To se odnosi na činjenicu da rezultat razvoja nije model, već izvršni kod, pa kupac obično ne voli plaćati modeliranje, jer modeli nisu proizvod koji mu treba);

Implementacija (implementacija, kodiranje) - uključuje zapravo pisanje koda. Elementi koda u RUP-u već se kreiraju tijekom faze analize i dizajna, budući da alat za implementaciju UML-a - Rational Rose - omogućuje kreiranje elemenata koda u nekoliko programskih jezika. Metodologija - objektno orijentirano programiranje;

Test uključuje testiranje proizvoda u određenoj iteraciji. Vrijedno je posebno napomenuti da regresijsko testiranje (testiranje povrata, ispitivanje „nepropadanja“ proizvoda) u ovom slučaju treba sadržavati sve trenutne testove iz prethodne iteracije i testove prihvatljivosti iz prethodne prijelazne faze;

Implementacija (implementacija) uključuje instalaciju proizvoda kod kupca, obuku osoblja, pokretanje sustava plus prijemna ispitivanja, pripremu standarda za pakiranje i distribuciju proizvoda, prijenos materijala u odjel prodaje (radnje su opcionalne ovisno o specifičnostima proizvoda ).

Gore navedeni elementi nisu novi u smislu životnog ciklusa razvoja softvera, budući da se pojavljuju u gotovo svakoj metodologiji - možda s izuzetkom XP-a (gdje su ipak predstavljeni u vrlo originalnom obliku). Značajka implementacije RUP-a je vremenski naglasak, naime, u kojim će iteracijama određene niti dominirati, kao i prisutnost univerzalnog jezika i skupa uslužnih programa koji omogućuju opisivanje procesa razvoja. Kao što vidimo na Sl. 2, u početnim fazama evolucije proizvoda, glavna se pozornost posvećuje formalizaciji projekta (analiza, modeliranje), čiji je cilj smanjenje komercijalnih rizika i smanjenje troškova pogrešaka u dizajnu. Kada je slika koliko-toliko jasna, kreće se u sam razvoj, testiranje i na kraju implementaciju proizvoda.

Preliminarni interni to su zapravo dokumenti koje izdaje tehničko vijeće za upravitelje poduzeća. Glavni cilj početnih faza je sklapanje ugovora ili pisma namjere. Daljnje iteracije su stvarni početak rada razvojnog tima, koji ima vremena i resursa za izgradnju formalnih modela. UML u ovom slučaju ima alate koji vam omogućuju mapiranje modela na elemente koda. Na primjer, stablo objekata prikazuje se izravno, varijacije ovise o snazi ​​implementacije programskog jezika koji su odabrali programeri, kao io podudarnosti pogleda G. Butcha i programera ovog jezika na objektni model . Isto vrijedi i za metode.

Sada pogledajmo elemente koji se odnose na podršku proizvoda - temeljne potporne tijekove rada:

Upravljanje konfiguracijom (upravljanje konfiguracijom i promjenama) moćan je sloj administrativnih radnji usmjerenih na upravljanje verzijama proizvoda, što uključuje kontrolu izvornog koda (model, izvršni moduli, testovi, dokumentacija), kontrolu verzije proizvoda, korporativne standarde za razvoj koda i dokumentaciju, praćenje promjena i grešaka (bug tracking); usko povezan s testiranjem i korisničkom podrškom;

Upravljanje (upravljanje projektom) - uključuje skup administrativnih radnji za upravljanje projektom u skladu s RUP ideologijom, koriste se alati za upravljanje projektom (pogledajte dolje popis Rational proizvoda);

Okoliš uključuje stvaranje i održavanje alati za analizu, dizajn, razvoj, testiranje (i softvera i hardvera).

Iterativni razvoj;

Upravljanje zahtjevima;

Korištenje modularnih arhitektura;

Vizualno modeliranje;

Provjera kvalitete;

Pratite promjene.

Prakse nisu izravno dio RUP procesa, ali se visoko preporučuju. Neke prakse izravno proizlaze iz ideologije RUP-a. Stoga je iterativni razvoj ugrađen u strukturu RUP-a, budući da je ovaj proces jedna od implementacija “spirale”. Upravljanje zahtjevima u RUP-u pojavljuje se u najranijim fazama analize. U teoriji, modularna arhitektura omogućuje ponovnu upotrebu koda, čineći sustav fleksibilnijim. Zbog činjenice da je UML objektni jezik, moguće je zanemariti modularnost, ali... to je donekle teško. Vizualno modeliranje omogućuje vam da se učinkovito nosite s rastućom složenošću sustava. Osim toga, modeli su sredstva komunikacije između programera, ali za to programeri moraju govoriti UML, što zahtijeva određenu obuku. Vizualno modeliranje često se provodi pomoću alata Rational Rose, koji vam omogućuje dobivanje skupa vrlo korisnih dokumenata za upravitelje, administratore sustava, programere, testere i generiranje elemenata koda. Ovaj alat nije jedina implementacija UML-a - dostupne su i komercijalne alternative (na primjer, Microsoft Visio) i besplatne. Treba napomenuti da UML dijalekti implementirani u alate za modeliranje nisu uvijek isti: Rational dijalekt ima neke velike razlike, opisane u dokumentaciji iu knjigama o UML-u.

Proizvodi koji podržavaju RUP

Sljedeći su najpoznatiji proizvodi koji podržavaju Rational Unified Process:

Alat za vizualno modeliranje Rational Rose CASE informacijski sustavi, koji ima mogućnost generiranja elemenata koda. Posebno izdanje proizvoda Rational Rose RealTime omogućuje vam da dobijete izvršni modul kao izlaz;

Alat za upravljanje zahtjevima Rational Requisite Pro koji vam omogućuje stvaranje, strukturiranje, određivanje prioriteta, praćenje i kontrolu promjena zahtjeva koje se pojavljuju u bilo kojoj fazi razvoja komponenti aplikacije;

Rational ClearQuest proizvod za upravljanje promjenama i praćenje nedostataka u projektu (bug tracking), usko integriran s alatima za testiranje i upravljanje zahtjevima i pruža jedinstveno okruženje za međusobno povezivanje svih pogrešaka i dokumenata;

Rational SoDA proizvod za automatsko generiranje projektne dokumentacije, što vam omogućuje da postavite korporativni standard za interne dokumente. Također je moguće uskladiti dokumentaciju s postojećim standardima (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - alati za testiranje i otklanjanje pogrešaka:

Rational Purify je vrlo moćan alat za pronalaženje grešaka u vremenu izvođenja za programere aplikacija i komponenti koji programiraju u C/C++,

Rational Visual Quantify alat za mjerenje performansi za programiranje programera aplikacija i komponenti u C/C++, Visual Basicu i Javi; pomaže identificirati i ukloniti uska grla u performansama softvera,

Rational Visual PureCoverage - automatski identificira područja koda koja se ne testiraju;

Rational ClearCase je proizvod za upravljanje konfiguracijom softvera (Rational's Software Configuration Management, SCM), koji omogućuje kontrolu verzija svih projektnih dokumenata. Uz njegovu pomoć možete podržati nekoliko verzija projekata istovremeno, brzo se prebacujući između njih. Rational Requisite Pro podržava ažuriranja i prati promjene u zahtjevima za razvojni tim;

SQA TeamTest alat za automatizaciju testiranja;

Rational TestManager sustav za upravljanje testiranjem koji okuplja sve alate, artefakte, skripte i podatke koji se odnose na testiranje;

Rational Robot alat za kreiranje, modificiranje i automatsko pokretanje testova;

SiteLoad, SiteCheck alati za testiranje web-mjesta na performanse i prisutnost neispravnih veza;

Rational PerformanceStudio - mjeri i predviđa karakteristike performansi sustava.

Artefakti i uloge

Sastavni dio RUP-a su artefakti, presedani i uloge. Artefakti su neki od proizvoda projekta koji se generiraju ili koriste u projektu tijekom rada na konačnom proizvodu. Slučajevi upotrebe su nizovi radnji koje izvodi sustav kako bi se dobio vidljivi rezultat. Zapravo, svaki rezultat rada pojedinca ili grupe je artefakt, bilo da se radi o dokumentu analize, elementu modela, kodnoj datoteci, testnoj skripti, opisu greške itd. Za stvaranje jedne ili druge vrste artefakata odgovorni su određeni stručnjaci. Dakle, RUP jasno definira odgovornosti svakog člana razvojnog tima u jednoj ili drugoj fazi, odnosno kada i tko treba stvoriti ovaj ili onaj artefakt. Cjelokupni proces razvoja softverskog sustava u RUP-u se promatra kao proces stvaranja artefakata - od dokumenata inicijalne analize do izvršnih modula, korisničkih priručnika itd. Ispod je skup artefakata (modela, dokumenata itd.) za svaki od tokova.

Poslovno modeliranje

Određivanje modela poslovnih procesa poslovnih zahtjeva za sustav koji se razvija;

Model strukture poduzeća - artefakt za razvoj funkcionalnog modela sustava;

Modeli dokumenata, poslovnih subjekata, modeli scenarija poslovnih funkcija, modeli stanja poslovnih subjekata - za projektiranje korisničkog sučelja, sustava baza podataka; predstavljaju opis statičkih i dinamičkih stanja sustava s različitih gledišta;

Artefakt modela poslovnih pravila koristi se za modeliranje pravila u softveru.

Artefakti dokumenata koje koriste RequisitePro, SoDA, programi za obradu teksta, Microsoftov projekt:

Procjena organizacije kupca, poslovne strukture;

Rječnik pojmova iz predmetnog područja;

Skup poslovnih pravila;

Komercijalna ponuda;

Specifikacije poslovne funkcije;

Plan rada u fazi poslovnog modeliranja;

Zahtjevi za promjenama.

Zahtjevi

Modeli artefakata koje koristi Rational Rose:

Funkcijski model sustava;

Model scenarija funkcioniranja sustava;

Model korisničkog sučelja;

Model korisničkih scenarija sustava;

Model izlaznih obrazaca;

Model pravila sustava.

Plan upravljanja zahtjevima;

Rječnik sistemskih pojmova;

Specifikacija za programski sustav;

Specifikacija za funkcije sustava;

Pravila sustava;

Upiti dionika;

Plan rada u fazi utvrđivanja zahtjeva sustava;

Zahtjevi za promjenama.

Analiza i dizajn

Modeli artefakata koje koristi Rational Rose:

Logički model podataka;

Fizički model podataka;

Model specifikacija komponenti sustava;

Scenariji interakcije između klasa koje implementiraju komponente sustava.

Artefakti dokumenata koje koriste RequisitePro, SoDA, programi za obradu teksta, MS Project:

Arhitektura softvera;

Specifikacije softverskih komponenti;

Plan rada u fazi analize i projektiranja;

Zahtjevi za promjenama.

Provedba

Modeli artefakata koje koristi Rational Rose:

Model primjene komponente.

Artefakti-kod koji koristi Rational Rose, alati za programiranje, programi za obradu teksta:

Elementi za generiranje koda potječu iz Rational Rose;

Stvarni kod aplikacije;

Dokumentacija.

Artefakti dokumenata koje koriste RequisitePro, SoDA, programi za obradu teksta, MS Project:

Plan izrade aplikacije;

Plan rada u fazi implementacije.

Test

Modeli artefakata koje koristi Rational Rose:

Model testnog slučaja;

Funkcionalni model ispitnog programa;

Model specifikacije komponente testnog programa;

Scenariji interakcije klasa koje ostvaruju interakciju komponenti testnog programa.

Opis testnih slučajeva;

Plan testiranja;

Plan rada za fazu testiranja;

Zahtjevi za promjenama.

Implementacija testiranja Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Raspoređivanje

Modeli artefakata koje koristi Rational Rose:

Opis modela postavljanja postavljanja komponenti u čvorovima obrade.

Artefakti dokumenata koje koristi SoDA, programi za obradu teksta, MS Project:

Obrazovni materijali;

Instalacijski dokumenti;

Opis verzija sustava;

Plan implementacije.

Sljedeći članak u ovoj seriji bit će posvećen Unified Modeling Language (UML).