Procesi i unifikuar i zhvillimit të softuerit. Procesi i Unifikuar i Zhvillimit dhe Programimi Ekstrem

Në përputhje me GOST 34.601-90 "AS. Fazat e krijimit" përcakton fazat e mëposhtme të krijimit të një AIS, të cilat, nga ana tjetër, mund të ndahen në faza:

· Formimi i kërkesave për AIS;

· zhvillimi i konceptit AIS;

· detyrë teknike;

· projekti paraprak;

· projekt teknik;

· dokumentacionin e punës;

· vënia në punë.

Çdo fazë ka grupin e vet të dokumentacionit të projektimit dhe zbatimin e moduleve teknike dhe softuerike të sistemit. Praktika tregon se procesi i krijimit të një sistemi është përsëritës dhe në rritje. Autorët e UML e theksojnë këtë kur përcaktojnë konceptin Procesi i unifikuar i zhvillimit të softuerit dhe informacionit. Megjithëse në fazën e parë formohet një grup kërkesash për AS në tërësi, në fakt ai është gjithmonë i paplotë në fillim dhe qartësohet në fazat vijuese. kam për të bërë përsëritjet, pra, përsëritni hapat dhe fazat individuale, tërësisht ose pjesërisht. Për më tepër, një sistem real është shumëfunksional dhe kompleks, kështu që zakonisht ndahet në nënsisteme dhe grupe të veçanta detyrash, duke dalluar nënsistemet dhe detyrat e fazës së parë, të dytë, etj. Sistemi po krijohet në mënyrë incrementale, nëpërmjet rritjes graduale të funksionalitetit me zëvendësimin e zgjidhjeve të projektimit paraprak me ato më të zhvilluara që plotësojnë më mirë kërkesat e përdoruesve. Kjo zvogëlon rreziqet financiare dhe kursen kohën dhe konsumin e burimeve në fazat përfundimtare të krijimit.

Kur përdorni metodologjinë UML për të krijuar softuer AIS dhe mbështetje informacioni, propozohet të ndërtoni një grup modelesh të ndërlidhura që pasqyrojnë vetitë statike dhe dinamike të sistemit të ardhshëm:

· modeli i rastit të përdorimit;

· modeli i analizës;

· model dizajni;

· modeli i vendosjes;

· modeli i zbatimit;

· model testimi.

Përdor modelin e rastit përfshin diagramet e rasteve të përdorimit dhe skenarët përkatës, përshkruan kërkesat funksionale të sistemit dhe sjelljen e tij kur ndërvepron me përdoruesit.

Modeli i analizës përfshin diagrame të përgjithshme të klasës për zbatimin e rasteve të përdorimit të nivelit logjik, diagramet e sekuencave të lidhura dhe/ose diagramet e bashkëpunimit dhe është një skicë se si do të zbatohen rastet e përdorimit të nivelit logjik.

Modeli i projektimitështë një paraqitje e detajuar e zbatimit fizik të modelit të analizës dhe përfshin diagrame të paketës (nënsistemit), diagrame të detajuara të klasave, diagrame sekuencash dhe/ose diagrame bashkëpunimi, diagrame gjendjesh, diagrame aktiviteti me shkallë të ndryshme detajesh.

Modeli i vendosjes përfshin diagramet paraprake të vendosjes që përcaktojnë të gjitha konfigurimet e rrjetit në të cilat sistemi mund të funksionojë. Diagramet e vendosjes tregojnë nyjet e rrjetit, llojet e lidhjeve dhe shpërndarjen e klasave aktive të sistemit midis nyjeve.

Modeli i zbatimit përshkruan se si klasat e projektimit zbatohen si komponentë. Prandaj, ai përfshin diagramet e komponentëve, gjurmët e klasës (zbatimit), diagramet e detajuara të vendosjes dhe një përshkrim të arkitekturës së sistemit.

Modeli i testimit përmban një grup rastesh testimi, procedura testimi dhe përshkrime të komponentëve të testimit. Ai specifikon metodat për testimin e komponentëve të ekzekutueshëm të sistemit.

Le të krahasojmë proceset e ndërtimit të modeleve me fazat e standardizuara të krijimit të një AS. Modeli i rastit të përdorimit është ndërtuar në fazën e formimit të kërkesave për AS; modeli i analizës është në fazën e zhvillimit të konceptit AS. Në fazën e specifikimeve teknike dhe projektimit paraprak, ndërtohet një model projektimi. Ai rafinohet në fazën e projektimit teknik dhe plotësohet nga një model vendosjeje. Në fazën e dokumentacionit të punës, krijohen modelet e zbatimit dhe testimit. Së fundi, në fazën e vënies në punë, modeli i testimit rafinohet dhe bëhet model referimi gjatë funksionimit, i destinuar për kontrolle periodike të funksionimit të saktë dhe diagnostikimin e sistemit.

1.5 Përbërësit e gjuhës UML

UML Gjuha e Unifikuar e Modelimit(Unified Modeling Language) është një gjuhë modelimi vizual që përdoret për specifikimin, vizualizimin, konfigurimin dhe dokumentimin e sistemeve komplekse (përfshirë softuerin) duke përdorur teknologjinë e orientuar nga objekti.

Kur krijohet një AS në metodologjinë UML, përdoren parimet e analizës së sistemit strukturor të njohur nga metodologjitë Hein/Sarson dhe SADT:

· zhvillimi hap pas hapi nga lart-poshtë;

· teknika e diagramimit;

· hierarkia e përshkrimeve;

· formalizimi i rreptë i përshkrimit të zgjidhjeve të projektimit;

· zhvillimi fillestar i projektit në një nivel logjik pa detaje të zbatimit teknik;

· modelimi konceptual në aspektin e fushës lëndore që klienti të kuptojë dizajnin e sistemit;

· mbështetje teknologjike me mjete (sistemet CASE).

Një model i një sistemi kompleks në UML mund të studiohet për të marrë karakteristikat e vlerësuara të efikasitetit të proceseve në sistem.

Modelet për vendosjen, zbatimin dhe testimin e softuerit AS dhe mbështetjes së informacionit në UML mund të përdoren si një projekt aplikacioni me gjenerimin e mëvonshëm të automatizuar të kodit të aplikacionit në një nga mjediset e programimit të zgjedhur.

Një model mjaft i plotë i një sistemi kompleks duhet të pasqyrojë dy aspekte:

-statike(strukturore) - përbërja, struktura e përbërësve dhe marrëdhëniet e tyre;

-dinamike(sjelljes) – përshkrim i logjikës së proceseve që ndodhin në sistem ose që do të zbatohen.

Metoda kryesore e përfaqësimit të modeleve të miratuara në UML janë diagramet e pajisura me informacion tekstual, duke përfshirë shprehjet në gjuhën e integruar të kufizimit OCL, si dhe në gjuhët e programimit dhe pyetjes së informacionit të përdorura për zbatimin e sistemit.

Parimi bazë i modelimit: një sistem modelohet si një grup objektesh diskrete që ndërveprojnë me njëri-tjetrin në mënyrë të tillë që të plotësojnë kërkesat e përdoruesit.

Një model statik specifikon strukturën, llojet e objekteve dhe marrëdhëniet ndërmjet objekteve. Modeli dinamik përcakton sjelljen e objekteve me kalimin e kohës (historinë e objekteve) dhe ndërveprimin e tyre.

Në thelb, UML është një gjuhë modelimi diskrete, domethënë përmban konceptin e ngjarjeve diskrete dhe ndryshimeve të gjendjes. Proceset e vazhdueshme modelohen përafërsisht nga diskretizim.

Modeli ka dy aspekte: informacion semantik (semantikë) dhe paraqitje vizuale (shënim).

Përbërja e plotë e paraqitjeve të modelit në gjuhën UML është dhënë në Tabelën 1

Tabela 1 – Paraqitja e modeleve të sistemit në UML.

Modeli konceptual më i zakonshëm i një sistemi është diagrami i rastit të përdorimit; ai është pika fillestare për ndërtimin e diagrameve të tjera.

Të gjitha diagramet gjuhësore janë grafikë të një lloji të veçantë, që përmbajnë kulme (figura gjeometrike) të lidhura me skaje (harqe). Zakonisht shkalla e figurës dhe vendndodhja e kulmeve nuk janë veçanërisht të rëndësishme, megjithatë, në diagramin e sekuencës, boshti i kohës futet dhe atje është i rëndësishëm.

Lidhjet tregohen me vija të ndryshme në aeroplan, teksti shkruhet brenda figurave dhe disa simbole grafike mund të përshkruhen pranë kulmeve dhe lidhjeve. Shtesat UML lejojnë diagramet hapësinore.

Gjuha ka 4 lloje strukturash grafike:

· ikona (piktograme);

· simbolet grafike në një plan;

· shtigje (vija);

· rreshtat e tekstit.

1.6 Niveli konceptual. Përdor modelin e rastit

Në përgjithësi, procesi i projektimit të orientuar nga objekti ndodh në përputhje me parimet bazë të analizës së sistemeve strukturore: dizajni nga lart-poshtë me ndërtimin e një hierarkie diagramesh që gradualisht na lëvizin nga niveli në nivel: konceptual - logjik - fizik (zbatim)

Diagrami i nivelit të lartë konsiderohet të jetë ai i propozuar nga A. Jacobson në OOSE diagrami i rastit të përdorimit sistemet në tërësi. Është ky që është përfaqësimi fillestar konceptual i sistemit dhe është ndërtuar me qëllimin:

· të përcaktojë kufijtë e përgjithshëm dhe kontekstin e fushës lëndore të modeluar;

· të formulojë kërkesat e përgjithshme për sjelljen funksionale dhe ndërfaqen e sistemit;

· të përgatisë dokumentacionin fillestar për ndërveprimin midis zhvilluesve dhe klientëve - përdoruesve të sistemit.

Pikëpamja e modeles: përdorues i jashtëm i sistemit. Një diagram rasti i përdorimit përfshin aktorët, rastet e përdorimit dhe shoqatat.

Aktant(aktor, ent i jashtëm, aktor) - një përshkrim abstrakt i një klase të burimeve/marrësve të mesazheve që ndërveprojnë drejtpërdrejt me një sistem, nënsistem ose klasë. Ky është përshkrimi rolet luajtur nga përdoruesi (person ose sistem tjetër, nënsistem, klasë) gjatë ndërveprimit me sistemin. Në thelb, ky është një përgjithësim i kërkesave të ngjashme të informacionit për sistemin që kërkojnë një të caktuar shërbimi(shërbime).

Një aktant nuk duhet domosdoshmërisht të identifikohet me një individ ose pajisje specifike, megjithëse kjo ndonjëherë është e mundur në parim nëse ata i shërbejnë vetëm një roli. Më shpesh - fizikisht - këta janë njerëz dhe pajisje të ndryshme që hyjnë në sistem për të marrë të njëjtin shërbim. Në nivelin më të lartë, për shembull, aktantët mund të jenë një operator, një administrator sistemi, një administrator i bazës së të dhënave, një përdorues i rregullt ose një klasë pajisjesh.

Të gjithë aktantët e mundshëm shterojnë të gjitha mënyrat e mundshme të ndërveprimit të përdoruesit me sistemin (nënsistemin, klasën). Kur zbatohet një sistem, aktantët mishërohen në njerëz dhe objekte fizike. Një person ose objekt fizik, në varësi të mënyrës së ndërveprimit, mund të përfaqësojë disa aktantë (role të ndryshme). Për shembull, i njëjti person mund të jetë një operator dhe një administrator i bazës së të dhënave, një shitës dhe një blerës, etj.

Në shumë AS nuk ka aktorë të tjerë përveç njerëzve. Megjithatë, aktantët mund të jenë një sistem i jashtëm, një pajisje I/O ose një kohëmatës (zakonisht i gjetur në sistemet e integruara në kohë reale). Ndër vepruesit në rastin e përdorimit bie në sy një aktanti kryesor(aktor primar), i cili nis punën me sistemin. Pjesa tjetër janë dytësore, marrin pjesë edhe në rastin e përdorimit, duke marrë rezultate dhe duke futur disa të dhëna të ndërmjetme.

Në nivelet logjike dhe fizike, aktantët përfaqësohen nga klasa dhe objekte që janë shembuj të klasave. Është e mundur të ndërtohet një hierarki aktantësh me trashëgimi të të gjitha roleve dhe marrëdhënieve, atributeve dhe operacioneve që ka aktanti paraardhës. Një shembull i një aktanti fëmijë mund të përdoret gjithmonë në vendin e sistemit ku deklarohet përdorimi i aktantit paraardhës (parimi i zëvendësimit).

Një aktant mund të përfaqësohet në diagrame në dy mënyra:

3. Simboli i klasës (drejtkëndëshi) me tregues të brendshëm të stereotipit

4. Më shumë standard: "burrë" me një mbishkrim (simbol i një personi)

Aktanti është jashtë sistemit dhe struktura e tij e brendshme nuk është përcaktuar. Është burimi/marrësi i mesazheve.

Klienti

Rasti i përdorimit(precedent, rast përdorimi) - një përshkrim abstrakt i klasës së shërbimit (funksionet e shërbimit) që i jepet aktantit në përgjigje të kërkesave të tij.

Shërbimi mund të ofrohet nga sistemi në tërësi, një nënsistem ose një klasë. Kështu, një rast përdorimi nënkupton modelimin e një pjese të funksionalitetit ose sjelljes së një sistemi. Një rast përdorimi ka një emër dhe nënkupton një sekuencë të caktuar veprimesh të dukshme nga një burim/marrës i jashtëm (aktant). Mënyra e brendshme e zbatimit të opsionit fshihet dhe zbulohet në nivele më të ulëta detajesh. diagrami i bashkëpunimit. Si çdo klasë, një rast përdorimi ka atribute dhe operacione, zbatimi i të cilave ekspozohet në shtresën fizike.

Rasti i përdorimit përfshin të gjithë sekuencën e mesazheve që aktanti fillon dhe përfundon me sistemin (nënsistem, klasë). Prandaj, çdo shembull i zbatimit të rastit të përdorimit ka gjithmonë një fillim në kohë dhe një fund kur asnjë aktant nuk dërgon mesazhe për këtë opsion. Këtu përfshihen edhe mesazhet e gabimit, opsionet për kryerjen e funksionit të mirëmbajtjes me cilësime të ndryshme (alternativa).

Një shembull i rastit të përdorimit është ekzekutimi i një rasti përdorimi që fillon pas marrjes së parë të një mesazhi nga një shembull aktiv. Në përgjigje të një mesazhi të caktuar, rasti i përdorimit kryen një sekuencë specifike veprimesh, të tilla si dërgimi i një mesazhi në instanca të tjera të aktantit (jo vetëm iniciatorit). Nga ana tjetër, këta aktantë dërgojnë mesazhe në këtë rast përdorimi dhe ndërveprimi vazhdon derisa të mos merren më mesazhe të tilla. Kjo shënon fundin e rastit të përdorimit.

Tregohet marrëdhënia midis aktantit dhe rastit të përdorimit shoqata.

Diagrami përshkruan rastin e përdorimit në dy mënyra:

1) një elips, një emër është vendosur brenda

2) një drejtkëndësh - si çdo klasë

Klienti

Sensori

Midis aktantëve dhe rasteve të përdorimit, lidhja është lloji i vetëm i lidhjes. Për më tepër, ajo ka semantikë ndërrimi i komunikimeve, domethënë kalimi i mesazhit, për këtë arsye zakonisht nuk shënohet pasi konteksti është i qartë nga shënimi i aktantit dhe i rastit të përdorimit. Por ju mund ta shënoni atë, dhe gjithashtu të tregoni shumësinë e lidhjes:

Klient banke

Shumësia(shumëfishimi) karakterizon numrin e rasteve specifike të një klase që merr pjesë në një lidhje të caktuar (një klient mund të lëshojë një numër të pakufizuar kredish).

Në përgjithësi shoqataështë një marrëdhënie midis dy ose më shumë komponentëve të modelit. Meqenëse në shumicën e rasteve komponentët janë disa klasa objektesh, një shembull i asociimit është thjesht një listë e renditur e referencave për instanca specifike, ndoshta e pajisur me atribute (veti) shoqëruese.

Emri i shoqatës, nëse ka një të tillë, duhet të jetë unik. Formohet sipas kuptimit të marrëdhënieve ndërmjet klasave që janë pjesëmarrëse në shoqatë. Për shembull, "Punonjës punon në Departamenti”, “Menaxheri përfundon Kompjuter”, etj.

Shoqatat janë vetë klasa ( klasa e shoqatës, klasa e shoqatës), ajo ka edhe vetitë e klasës dhe të shoqatës. Instancat e kësaj klase janë lidhje që kanë jo vetëm lidhje me objekte, por edhe vlera atribute (veti).

Anëtarët e shoqatës quhen të saj polet. Të gjitha polet janë rolet e klasave të përfshira në lidhje, ato janë të dallueshme dhe mund të renditen në ndonjë listë të renditur. Në shumicën e rasteve, shoqatat janë binare (dy role në një lidhje me semantikë të caktuar), por mund të ketë gjithashtu n -ari. E njëjta klasë mund të veprojë në role të ndryshme, domethënë të jetë njëkohësisht në dy pole të shoqatës.

Shumësia e lidhjeve tregohet në pole.

Lidhjet mund të shfaqen dhe zhduken gjatë funksionimit të sistemit; kufizimet dhe kallëzuesit përkatës mund të specifikohen në polet e lidhjes.

Ndonjëherë lidhja ndryshon vetëm në një nga polet. Nëse një lidhje ka atribute, atëherë ato mund të ndryshohen nga operacionet, megjithatë, lidhjet me pjesëmarrësit e lidhjes nuk ndryshojnë.

Një shoqatë përshkruhet si një vijë e vazhdueshme që lidh kufijtë e 2 klasave nëse shoqata n-ary, pastaj vizatohet një romb (shenjë grumbullimi):

		Shumë shoqata - grumbullimi
	Shoqata binare

Rastet e përdorimit nuk shkëmbejnë mesazhe me njëri-tjetrin dhe mund të jenë vetëm në marrëdhënie (lidhje) zgjerimet(zgjat) përfshirjes(përfshijnë) dhe përgjithësime(përgjithësim).

NË në lidhje me zgjerimin rast përdorimi - klienti prezanton një sekuencë shtesë veprimesh, duke filluar nga një pikë në sekuencën kryesore, dhe mund të ketë disa "futje" të tilla. Të gjitha këto pika quhen pikat e zgjerimit.

Rational Unified Process (RUP) është një nga metodologjitë më të mira të zhvillimit të softuerit, e krijuar nga Rational Software. Bazuar në përvojën e shumë projekteve të suksesshme softuerike, Procesi i Unifikuar ju lejon të krijoni sisteme komplekse softuerike bazuar në metodat e zhvillimit industrial. Një nga shtyllat kryesore në të cilën mbështetet RUP është procesi i krijimit të modeleve duke përdorur gjuhën e unifikuar të modelimit (UML). Ky artikull ka të bëjë me përdorimin e diagrameve UML në rrjedhën e punës së zhvillimit të sistemeve të softuerit duke përdorur metodologjinë Rational Software.

Nuk është sekret që krijimi i softuerit është një proces kompleks, i cili nga njëra anë ka shumë të përbashkëta me krijimtarinë dhe nga ana tjetër, megjithëse është shumë fitimprurës, është gjithashtu një biznes me kosto të lartë. Konkurrenca e ashpër në treg i detyron zhvilluesit të kërkojnë metoda më efikase të punës. Mënyrat për të krijuar sisteme softuerike në kohë edhe më të shpejtë, me kosto më të ulët dhe me cilësi më të mirë. Kompleksiteti i programeve po rritet vazhdimisht. Deri kohët e fundit, produktet softuerike mund të krijoheshin në një kohë të parashikueshme nga individë ose, për shembull, në departamentin e IT të një ndërmarrje të automatizuar.

Në ditët e sotme, individëve që krijojnë programe në gjunjë u mbetet zona e shërbimeve të vogla dhe module të ndryshme shtesë për produkte softuerike "të rënda". E ardhmja i përket qasjes industriale të krijimit të softuerit. Në 1913, Henry Ford nisi linjën e parë të montimit të automobilave, dhe në vitet '90 një linjë e ngjashme montimi filloi të përdoret në fushën e teknologjive të IT. Zhvillimi i ekipit kërkon një qasje krejtësisht të ndryshme dhe një metodologji tjetër, e cila herët a vonë duhej të krijohej.

Rational Software Corporation (http://www.rational.com) ka lëshuar një bazë të strukturuar njohurish të quajtur Procesi i Unifikuar Racional (RUP), i cili është një grup rekomandimesh gjithëpërfshirëse për krijimin e pothuajse çdo produkti softuer. Duke thithur përvojën e zhvillimeve më të mira, RUP tregon në detaje se kur, kush dhe çfarë duhet bërë në projekt në mënyrë që të përfundojë me një sistem softuer në kohë, me një funksionalitet të caktuar dhe brenda buxhetit të caktuar.

Procesi i unifikuar mund të konsiderohet si shuma e aktiviteteve të ndryshme të kompanisë së zhvillimit të nevojshme për të përkthyer kërkesat e klientëve në një sistem softuerësh. Një sistem që do të ofronte "rezultate domethënëse" për përdoruesit dhe do të bënte pikërisht atë që ata presin nga sistemi. Prandaj, procesi kontrollohet nga rastet e përdorimit të sistemit, ose ndryshe - precedentë.

Për të zbatuar kërkesat e klientëve në kohë, Procesi i Unifikuar ndahet në faza që përbëhen nga përsëritje, prandaj procesi quhet edhe përsëritës dhe rritës. Çdo përsëritje kalon nëpër një cikël të punës bazë dhe i sjell zhvilluesit në qëllimin përfundimtar: krijimin e një sistemi softuerësh. Gjatë përsëritjeve, krijohen artefakte të ndërmjetme që kërkohen për përfundimin me sukses të projektit dhe një version i sistemit softuer që zbaton një grup të caktuar funksionesh, i cili rritet nga përsëritja në përsëritje. Fazat dhe rrjedhat kryesore të punës së procesit janë paraqitur në Fig. 1, kostot e përafërta të punës së punës sipas fazës janë dhënë gjithashtu atje.

oriz. 1 Fazat e RUP dhe rrjedhat e punës

Duhet të theksohet se në Fig. 1 tregon vetëm punën kryesore të Procesit të Unifikuar. Për shembull, aktivitetet e menaxhimit të aktiviteteve nuk shfaqen këtu për të shmangur rrëmujën e diagramit.

I gjithë zhvillimi i softuerit konsiderohet në RUP si një proces i krijimit të objekteve. Çdo rezultat i projektit, qofshin tekste burimore, module objektesh, dokumente të transferuara te përdoruesi, modele - këto janë nënklasa të të gjitha objekteve të projektit. Secili anëtar i ekipit të projektit krijon artefaktet e veta dhe është përgjegjës për to. Programuesi krijon programin, menaxheri krijon planin e projektit dhe analisti krijon modelet e sistemit. RUP ju lejon të përcaktoni se kur, nga kush dhe çfarë objekti duhet të krijohet, modifikohet ose përdoret.

Një nga klasat më interesante të objekteve të projektit janë modelet, të cilat lejojnë zhvilluesit të përcaktojnë, vizualizojnë, ndërtojnë dhe dokumentojnë objekte të sistemit softuer. Çdo model është një pamje e pavarur e sistemit që po zhvillohet dhe synon të përvijojë problemet dhe të propozojë zgjidhje. Vetëmjaftueshmëria e modeleve do të thotë që një analist ose zhvillues mund të marrë të gjithë informacionin që i nevojitet nga një model specifik pa iu drejtuar burimeve të tjera.

Modelet ju lejojnë të merrni parasysh sistemin e ardhshëm, objektet e tij dhe ndërveprimin e tyre edhe përpara se të investoni fonde të konsiderueshme në zhvillim; ato ju lejojnë ta shihni atë përmes syve të përdoruesve të ardhshëm nga jashtë dhe zhvilluesve nga brenda, madje edhe përpara linjës së parë të burimit. është krijuar kodi. Shumica e modeleve përfaqësohen nga diagramet UML; ju mund të lexoni më shumë rreth UML, për shembull, në.

Gjuha e Unifikuar e Modelimit u shfaq në fund të viteve '80 dhe në fillim të viteve '90, kryesisht falë përpjekjeve të "tre miqve" Gradi Bucha, Jim Rambo dhe Ivar Jacobson. Tani ajo është miratuar nga konsorciumi OMG si një gjuhë standarde modelimi që u ofron zhvilluesve një shënim të qartë që lejon modelet të shfaqen në elementë grafikë që përgjithësisht pranohen dhe kuptohen nga të gjithë në projekt.

Sidoqoftë, nuk duhet të harrojmë se gjuha e modelimit ofron vetëm një shënim - një mjet për përshkrimin dhe modelimin e një sistemi, dhe një proces i unifikuar përcakton metodologjinë për përdorimin e këtij mjeti, si dhe mjete të tjera mbështetëse të metodologjisë nga Rational. UML mund të përdoret pa një metodologji specifike sepse është i pavarur nga procesi, dhe pavarësisht se cili opsion procesi përdoret, mund të përdorni diagrame për të dokumentuar vendimet e marra gjatë zhvillimit dhe për të shfaqur modelet e krijuara.

Një sistem softuerësh është krijuar për të zgjidhur probleme specifike të përdoruesve, dhe jo për programuesit që të testojnë teknologji të reja dhe të fitojnë përvojë për menaxherin e projektit. Në përgjithësi, përdoruesit nuk i intereson nëse përdorni një qasje të orientuar nga objekti, UML, RUP ose krijoni një sistem duke përdorur metodën XP (programim ekstrem) në procesin e zhvillimit. Përdorimi i disa metodave, teknologjive dhe krijimi i strukturës së brendshme optimale të projektit mbetet në ndërgjegjen e zhvilluesve, të cilët marrin vendime bazuar në përvojën e mëparshme dhe preferencat e tyre. Sidoqoftë, përdoruesi nuk do t'ju falë për injorimin e kërkesave të tij. Edhe nëse një sistem softuerësh zhvillohet dhjetë herë duke përdorur metoda dhe teknologji më të fundit, nëse përdoruesi nuk merr atë që quhet "rezultat kuptimplotë" prej tij, projekti juaj softuer do të dështojë në mënyrë të tmerrshme.

Nga kjo rrjedh se aplikimi i pamenduar i UML, thjesht sepse është në modë, jo vetëm që nuk do të çojë zhvillimin drejt suksesit, por gjithashtu mund të shkaktojë pakënaqësi tek punonjësit që duhet të studiojnë një sasi të madhe literaturë shtesë dhe menaxherët e projektit kur rezulton se kostot e punës në projekt rriten dhe kthimet nuk po rriten. Ju duhet të kuptoni qartë se çfarë doni të merrni nga zbatimi i kësaj teknologjie dhe të ndiqni këtë qëllim. Përdorimi i UML kursen burimet e zhvillimit sepse ju lejon të merrni një ide të sistemit më shpejt sesa kur krijoni paraqitjet dhe prototipet, duke shpenzuar pakrahasueshëm më pak burime.

Diagramet e bëjnë më të lehtë për anëtarët e projektit të komunikojnë me njëri-tjetrin dhe, ajo që është veçanërisht e vlefshme, përfshijnë përdoruesit fundorë të sistemit në proces. Modelimi ju lejon të reduktoni rreziqet e projektit, pasi është gjithmonë më e lehtë për programuesit të bëjnë atë që është e qartë dhe e kuptueshme sesa të shkojnë në një rezultat të pasigurt. Krijimi i diagrameve është i ngjashëm me krijimin e një projekti në ndërtim - mund të bëni pa të, për shembull, kur ndërtoni një strehë në një vilë verore, megjithatë, sa më e madhe të jetë ndërtesa (në rastin tonë, një produkt softuer), aq më e vështirë është për të bërë dhe aq më i pasigurt rezultati përfundimtar.

Një herë kam dhënë një seminar mbi RUP në një kompani softuerësh që kishte qenë mjaft e suksesshme në treg për dhjetë vjet, por nuk përdorte fare modelim në rrjedhën e saj të punës, por bazohej në prototipe. Në sallë u mblodhën rreth njëzet programues të rinj dhe me përvojë, të cilët dëgjuan me vëmendje gjithçka që u thashë për RUP dhe UML. Dhe njëri prej tyre, duke parë tabelën e mbuluar me diagrame shembuj, tha: "Kjo është e gjitha interesante dhe ndoshta e mirë për projekte të tjera," tha ai, "por ne kemi punuar për një kohë të gjatë pa të gjitha këto, pasi jemi megjithatë ne ia dolëm pa UML, ndoshta thjesht nuk na nevojitet."

Kjo pyetje më bëri të mendoj se ndryshimi në proceset e biznesit që duhet të ndodhë në mënyrë të pashmangshme në një kompani të zhvillimit të softuerit kur zbaton RUP dhe UML mund të jetë po aq i vështirë sa zbatimi i një sistemi informacioni në një ndërmarrje industriale.Çdo zbatim është një thyerje e stereotipeve. Meqenëse kualifikimet e punonjësve në një kompani të zhvillimit të softuerit janë mjaft të larta, është më e vështirë për njerëz të tillë të braktisin pikëpamjet e tyre sesa për "të vdekshmit e thjeshtë", dhe vështirësitë dhe refuzimi që lindin mund të krahasohen me kalimin nga procedura në objekt. të menduarit të orientuar.

1.Përcaktimi i kërkesave

Një proces i unifikuar është një proces i drejtuar nga rastet e përdorimit që pasqyrojnë skenarët e ndërveprimit të përdoruesit. Në fakt, është pamja e përdoruesve për sistemin softuerik nga jashtë. Kështu, një nga fazat më të rëndësishme të zhvillimit, sipas RUP, do të jetë faza e përcaktimit të kërkesave, e cila konsiston në mbledhjen e të gjitha dëshirave të mundshme për funksionimin e sistemit që mund të vijnë vetëm në mendjen e përdoruesve dhe analistëve. Më vonë, këto të dhëna do të duhet të sistemohen dhe strukturohen, por në këtë fazë, përmes intervistave me përdoruesit dhe studimit të dokumenteve, analistët duhet të mbledhin sa më shumë kërkesa për sistemin e ardhshëm, gjë që nuk është aq e thjeshtë sa duket në pamje të parë. Përdoruesit shpesh nuk e kanë idenë se çfarë duhet të marrin në fund. Për të lehtësuar këtë proces, analistët përdorin diagramet e rasteve të përdorimit (Fig. 2)

Fig 2. Shembull i një diagrami të rastit të përdorimit

Diagrami është një pasqyrim i aktorëve (aktantëve) që ndërveprojnë me sistemin, dhe reagimi i objekteve të softuerit ndaj veprimeve të tyre. Aktantët mund të jenë si përdorues ashtu edhe agjentë të jashtëm që duhet të transmetojnë ose marrin informacion. Ikona e rastit të përdorimit pasqyron përgjigjen e sistemit ndaj hyrjes së jashtme dhe tregon se çfarë duhet bërë për aktantin.

Për të detajuar një rast specifik përdorimi, përdoret një Diagram Aktiviteti, një shembull i të cilit është dhënë në Figurën 3.

oriz. 3 Shembull i një diagrami aktiviteti

Thjeshtësia e diagramit të rastit të përdorimit i lejon analistët të komunikojnë lehtësisht me klientët gjatë procesit të përcaktimit të kërkesave, duke identifikuar kufizimet e vendosura në sistem dhe në zbatimin e kërkesave individuale, si koha e përgjigjes së sistemit, të cilat më vonë bien në seksionin e jofunksionalëve. Kërkesat.

Një diagram rasti i përdorimit mund të përdoret gjithashtu për të krijuar skenarë testimi pasi të gjitha ndërveprimet midis përdoruesve dhe sistemit janë përcaktuar tashmë.

Për të përcaktuar saktë kërkesat, zhvilluesit duhet të kuptojnë kontekstin (pjesë të fushës së temës) në të cilën do të funksionojë sistemi i ardhshëm. Për ta bërë këtë, krijohen një model domeni dhe një model biznesi, të cilat janë qasje të ndryshme për të njëjtën çështje. Shpesh krijohet një gjë: një model domeni ose një model biznesi.

Dallimi midis këtyre modeleve është se modeli i domenit përshkruan konceptet e rëndësishme me të cilat do të funksionojë sistemi dhe lidhjet e tyre me njëri-tjetrin. Ndërsa një model biznesi përshkruan proceset e biznesit (ekzistuese ose të ardhshme) që sistemi duhet të mbështesë. Prandaj, përveç përcaktimit të objekteve të biznesit të përfshirë në proces, ky model përcakton punonjësit, përgjegjësitë e tyre dhe veprimet që duhet të kryejnë.

Për të krijuar një model domeni, përdoret një diagram i rregullt i klasës (Figura 6), por qartësisht nuk mjafton për të krijuar një model biznesi. Në këtë rast, një diagram rasti i përdorimit përdoret duke përdorur ikona shtesë që pasqyrojnë thelbin e proceseve të biznesit - këto janë aktanti i biznesit, rasti i përdorimit të biznesit, entiteti biznesor dhe menaxhimi i biznesit. Ky model është shumë më afër modelit tjetër të krijuar në procesin e zhvillimit - modelit të analizës.

2.Analiza

Pas përcaktimit të kërkesave dhe kontekstit në të cilin do të funksionojë sistemi, është koha për të analizuar të dhënat e marra. Gjatë procesit të analizës, krijohet një model analitik që udhëzon zhvilluesit në arkitekturën e sistemit të ardhshëm. Një model analitik është një pamje e një sistemi nga brenda, në krahasim me një model të rastit të përdorimit, i cili tregon se si do të duket sistemi nga jashtë.

Ky model ju lejon të kuptoni se si duhet të dizajnohet sistemi, çfarë klasash duhet të ketë dhe si duhet të ndërveprojnë me njëri-tjetrin. Qëllimi i tij kryesor është të përcaktojë drejtimin e zbatimit të funksionalitetit të identifikuar në fazën e mbledhjes së kërkesave dhe të skicojë arkitekturën e sistemit.

Ndryshe nga modeli i projektimit që krijohet më vonë, modeli i analizës është më shumë një model konceptual dhe vetëm i afron zhvilluesit me klasat e zbatimit. Ky model nuk duhet të ketë kontradikta të mundshme që mund të ndodhin në modelin precedent.

Për të shfaqur modelin e analizës duke përdorur UML, përdoret një diagram klasë me stereotipe (modele sjelljeje) "klasa kufitare", "entitet", "kontroll" dhe diagramet e bashkëpunimit përdoren për detajimin (Figura 4). Stereotipi i "klasës kufitare" përshkruan një klasë që ndërvepron me aktantë të jashtëm, stereotipi "entitet" përshkruan klasat që janë depo të dhënash dhe stereotipi "kontroll" përshkruan klasat që menaxhojnë pyetjet për entitetet.

Figura 4. Shembull i një diagrami bashkëpunimi

Numërimi i mesazheve tregon renditjen e tyre, por qëllimi i diagramit nuk është të marrë në konsideratë renditjen e mesazheve të shkëmbyera, por të tregojë qartë marrëdhëniet e klasave me njëra-tjetrën.

Nëse fokusohemi në rendin e ndërveprimit, atëherë një paraqitje tjetër do të ishte një diagram sekuence (Sequence), i paraqitur në figurën 5. Ky diagram ju lejon të shikoni shkëmbimin e mesazheve me kalimin e kohës, duke shfaqur vizualisht sekuencën e procesit. Kur përdorni një mjet për krijimin e modelit si Rational Rose, këto dy lloje diagramesh mund të krijohen automatikisht nga njëri-tjetri (mund të lexoni më shumë rreth Rational Rose, për shembull, në).

Oriz. 5 Shembull i një diagrami sekuence

Vendimi se cili nga dy diagramet të krijohet i pari varet nga preferencat e zhvilluesit individual. Meqenëse këto diagrame janë një paraqitje e të njëjtit proces, të dyja ju lejojnë të pasqyroni ndërveprimin midis objekteve.

3.Dizajni

Faza tjetër në procesin e krijimit të një sistemi është dizajni, gjatë së cilës krijohet një model dizajni bazuar në modelet e krijuara më herët. Ky model pasqyron zbatimin fizik të sistemit dhe përshkruan produktin e krijuar në nivelin e klasës dhe komponentit. Ndryshe nga modeli i analizës, modeli i projektimit ka një varësi të qartë nga kushtet e zbatimit, gjuhët e programimit dhe komponentët e përdorur. Për një kuptim sa më të saktë të arkitekturës së sistemit, ky model duhet të jetë sa më i zyrtarizuar dhe i përditësuar gjatë gjithë ciklit jetësor të zhvillimit të sistemit.

Për të krijuar një model dizajni, përdoret një grup i tërë diagramesh UML: diagramet e klasave (Fig. 5), diagramet e bashkëpunimit, diagramet e ndërveprimit, diagramet e aktivitetit.

Fig 6. Shembull i një diagrami të klasës

Për më tepër, kjo rrjedhë e punës mund të krijojë një model vendosjeje që zbatohet bazuar në një Diagram të vendosjes. Ky është lloji më i thjeshtë i diagramit i krijuar për të modeluar shpërndarjen e pajisjeve në një rrjet. Për shfaqje, përdoren vetëm dy opsione për ikonat e procesorit dhe pajisjes, së bashku me lidhjet ndërmjet tyre.

4.Zbatimi

Detyra kryesore e procesit të zbatimit është krijimi i një sistemi në formën e komponentëve - kodet burimore të programit, skriptet, skedarët binare, modulet e ekzekutueshme, etj. Në këtë fazë, krijohet një model zbatimi që përshkruan se si zbatohen elementet e modelit të projektimit, cilat klasa do të përfshihen në komponentë të veçantë. Ky model përshkruan mënyrën e organizimit të këtyre komponentëve në përputhje me mekanizmat e strukturimit dhe modularizimit të adoptuar në mjedisin e përzgjedhur të programimit dhe përfaqësohet nga një diagram komponenti (Fig. 7).

oriz. 7 Shembull i diagramit të komponentit

5.Testimi

Gjatë procesit të testimit, kontrollohen rezultatet e zbatimit. Për këtë proces, krijohet një model testimi, i cili përbëhet nga rastet e testimit, procedurat e testimit, komponentët e testimit, por nuk ka një paraqitje të diagramit UML, kështu që ne nuk do të ndalemi në të.

6.Përfundim

Këtu janë marrë parasysh vetëm proceset kryesore të metodologjisë Racionale. RUP është mjaft i gjerë dhe përmban rekomandime për ekzekutimin e projekteve të ndryshme softuerike, nga krijimi i programeve nga një grup zhvilluesish prej disa personash, deri te projektet e softuerit të shpërndarë që bashkojnë mijëra njerëz në kontinente të ndryshme. Sidoqoftë, pavarësisht dallimeve të tyre të mëdha, metodat për përdorimin e modeleve të krijuara duke përdorur UML do të jenë të njëjta. Diagramet UML, të krijuara në faza të ndryshme të zhvillimit, janë të pandashëm nga pjesa tjetër e objekteve të një projekti softuerësh dhe shpesh janë lidhja midis proceseve individuale RUP.

Vendimi për të përdorur diagrame specifike varet nga procesi i zhvillimit të ngritur në kompani, i cili edhe pse quhet i unifikuar, nuk është diçka e ngrirë. Rational jo vetëm që ofron për ta përmirësuar dhe rafinuar atë, por gjithashtu ofron mjete speciale për të bërë ndryshime në bazën e të dhënave RUP.

Por në çdo rast, përdorimi i UML së bashku me një proces të unifikuar do t'ju lejojë të merrni një rezultat të parashikueshëm, të përmbushni buxhetin e caktuar, të rrisni ndikimin e pjesëmarrësve të projektit dhe cilësinë e produktit të krijuar softuer.

Kratchen. F. Hyrje Procesi i Unifikuar Racional . Ed. 2 - M.: Shtëpia Botuese Williams, 2002. - 240 f.: ill.

Jacobson A., Buch G., Rambo J. Procesi i unifikuar i zhvillimit të softuerit - Shën Petersburg: Peter, 2002. - 496 f.: ill.

Fowler M., Scott K. UML me pak fjalë. Zbatimi i një gjuhe standarde të modelimit të objekteve: Përkth. nga anglishtja – M.:Mir, 1999. – 191 f., ill.

Beck. E. Programim ekstrem. – Shën Petersburg: Peter, 2002. – 224 f.: ill.

TrofimovS. Teknologjitë CASE: Punë praktike në Rational Rose.
Ed. 2 - M.: Binom-Press, 2002 - 288 f.

Procesi i Unifikuar përdor në mënyrë aktive gjuhën e unifikuar të modelimit ( UML). Në thelb UML qëndron një model që lejon ekipin e zhvillimit të kuptojë në mënyrë të thjeshtuar shumëllojshmërinë e proceseve komplekse të kërkuara për zhvillimin e softuerit. Modele të ndryshme të përdorura në Procesi i unifikuar, ju lejon të vizualizoni sistemin, të përshkruani strukturën dhe sjelljen e tij dhe të dokumentoni vendimet e marra gjatë procesit të zhvillimit.

Historia e origjinës

Origjina e kornizës qëndron në punën e një punonjësi Ericsson Ivar Jacobson, botuar në fund të viteve 1960. Jacobson dhe kolegët e tij modeluan sisteme të mëdha telekomunikacioni duke përdorur shtresa "blloqesh" (të cilat më vonë u bënë të njohura si "përbërës"): shtresat e poshtme shërbyen si bazë për nënsistemet nga shtresat e sipërme. Ekipi ndërtoi blloqet e poshtme duke marrë në konsideratë "rastet e trafikut" që mund të ndodhin me përdoruesit e sistemit. Ishin këto "incidente" që u bënë prototipi i rasteve të përdorimit, të cilat u përfshinë më vonë UML. Puna e Jacobson frymëzoi gjithashtu krijimin e diagrameve të përdorura në UML, duke përfshirë diagramet e aktivitetit dhe sekuencës .

Në 1987, Jacobson themeloi kompaninë e tij Objekti AB dhe së bashku me partnerët kaluan disa vite duke zhvilluar një projekt dhe produkt të quajtur Objekti. Në vitin 1995, Jacobson botoi librin " Inxhinieri softuerike e orientuar nga objekti”, duke përshkruar një proces zhvillimi të drejtuar nga kërkesat e klientit që përkthehen në produktin përfundimtar përmes rasteve të përdorimit. Publikimi i librit përkoi me publikimin e parë të versionit online të kernelit Procesi i unifikuar.

Në vitin 1995 kompania Objekti AB absorbohet nga korporata Racionale. Me ndihmën e një numri të rritur ndjeshëm kolegësh, Jacobson fillon të zgjerojë procesin Objekti, duke e plotësuar atë me mjete për menaxhimin dhe zhvillimin e projektit. Së bashku me Grady Booch dhe James Rumbaugh, të cilët punuan në Racionale më parë, Jacobson u bë anëtar i grupit të "tre miqve", të cilët udhëhoqën punën për të krijuar një proces të quajtur Procesi i objektit racional (ROP), si dhe shpërndarjen Procesi i unifikuar, e cila u bë bazë për Gjuha e unifikuar e modelimit.

Në procesin e punës për ROP Dhe UML, korporatë Racionale bashkimet dhe blerjet e vazhdueshme të kompanive të përfshira në krijimin e mjeteve të zhvillimit të softuerit. Këto mjete ofruan aftësi për menaxhimin e kërkesave (“RequisitePro”), testimin e përgjithshëm (“SQA”), testimin e performancës, menaxhimin e konfigurimit dhe menaxhimin e ndryshimeve. Në vitin 1998 Racionale ndryshon emrin e produktit në RUP, thelbi konceptual i të cilit mbetet Procesi i unifikuar.

Karakteristikat

Procesi i unifikuar bazuar në raste te perdorimit, duke përshkruar një ose më shumë aktorë që ndërveprojnë me sistemin dhe marrin rezultate që janë të vlefshme për pjesëmarrësit në proces. Janë rastet e përdorimit ato që janë forca kryesore lëvizëse që drejton të gjithë procesin e zhvillimit, duke filluar me mbledhjen dhe diskutimin e kërkesave, dhe duke përfunduar me analizën, projektimin dhe zbatimin. Rastet e përdorimit përshkruhen në gjuhë të thjeshtë dhe të kuptueshme, në mënyrë që të jenë të kuptueshme për një lexues të jashtëm.

Sipas Procesi i unifikuar, në qendër të procesit të zhvillimit qëndron arkitekturës- organizimi themelor i të gjithë sistemit. Mund të përfshijë elementë statikë dhe dinamikë, ndërveprimin e tyre dhe ju lejon të zgjidhni çështjet e efikasitetit të produktit, shtrirjes, aftësisë për të ripërdorur elementët dhe të ndihmoni në kapërcimin e kufizimeve ekonomike dhe teknike. Ekipi i projektit fillon punën për përshkrimin e arkitekturës sa më shpejt që të jetë e mundur, dhe vazhdimisht e zgjeron dhe e përmirëson atë gjatë procesit të zhvillimit. Arkitektura konsiderohet një aspekt i rëndësishëm Procesi i unifikuar për një sërë arsyesh, çelësi i të cilave është aftësia për të parë pamjen e plotë të asaj që po ndodh, aplikimi i saktë i përpjekjeve të zhvilluesit, lehtësimi i mundësive për ripërdorimin e komponentëve, zhvillimi i sistemit dhe përzgjedhja e saktë e rasteve të përdorimit.

Parimi i tretë themelor Procesi i unifikuarështë përdorimi qasje përsëritëse dhe rritëse. Përsëritjet janë projekte në miniaturë që ju lejojnë të lëshoni një version më të ri të sistemit. Rezultati i përsëritjes, ndryshimet e bëra në sistem, quhet rritje. Në veçanti, qasja përsëritëse ju lejon të përmirësoni vazhdimisht arkitekturën e sistemit, të trajtoni ndryshime të vazhdueshme në kërkesa dhe të rregulloni në mënyrë fleksibël planin e të gjithë projektit. Angazhimi ndaj parimit të integrimit të vazhdueshëm ju lejon të identifikoni problemet e mundshme në një fazë të hershme. Për më tepër, përsëritja ndihmon në minimizimin e rreziqeve që lidhen me kufizimet teknike, arkitekturën dhe kërkesat në ndryshim.

Fazat e zhvillimit

Madhësia relative e fazave të zhvillimit për një projekt tipik

Çdo cikël zhvillimi, sipas Procesi i unifikuar, përbëhet nga katër faza, të cilat përfaqësojnë periudhën kohore ndërmjet momenteve të rëndësishme të projektit, duke i lejuar menaxherët të marrin vendime të rëndësishme në lidhje me vazhdimin e procesit të zhvillimit, fushëveprimin e punës, buxhetin dhe orarin.

Varietetet e rrjedhës së punës

Brenda Procesi i unifikuar Në secilën fazë të zhvillimit, ekzistojnë pesë lloje të proceseve të punës: kërkesat, analiza, projektimi, zbatimi dhe testimi.

Çdo proces është një grup aktivitetesh të kryera nga anëtarë të ndryshëm të ekipit të projektit. Kështu, qëllimi i proceseve të mbledhjes së kërkesave është krijimi i një modeli të rasteve të përdorimit që lejon dikë të identifikojë kërkesat themelore funksionale për sistemin. Proceset e analizës dhe modeli përkatës i lejojnë zhvilluesit të strukturojnë kërkesat funksionale; Procesi i projektimit përshkruan zbatimin fizik të rasteve të përdorimit dhe është një abstraksion për modelin e mëposhtëm. Procesi dhe modeli i zbatimit përshkruajnë se si elementët e dizajnit lidhen me komponentët e softuerit, duke përfshirë kodin burimor, bibliotekat dinamike, etj. Modeli i fundit, i cili përshkruan testimin, shpjegon se cilat teste të sistemit dhe teste të njësive duhet të kryhen dhe si duhet t'i kryejë ato ekipi i zhvillimit.

Përsëritje dhe rritje

Secila nga fazat e përshkruara në Procesin e Unifikuar përbëhet nga përsëritjet, të cilat janë nënprojekte në miniaturë me kohëzgjatje të kufizuar. Në mënyrë tipike, çdo përsëritje përfshin të pesë elementët e rrjedhës së punës në shkallë të ndryshme. Rezultati i përsëritjes është rritje, një version që përmban përmirësime në krahasim me versionin e mëparshëm të produktit.

Procesi i Unifikuar Racional(RUP) është një kornizë teknologjike e zhvillimit të softuerit e zhvilluar dhe tregtuar nga Rational Software. Ai përfshin praktikat më të mira globale në zhvillimin e softuerit dhe ofron një qasje disiplinore për caktimin dhe menaxhimin e detyrave dhe përgjegjësive brenda një organizate të zhvillimit të softuerit. Duke aplikuar këtë proces, ekipet e zhvillimit të softuerit do të jenë në gjendje të krijojnë softuer me cilësi të lartë që plotëson nevojat e përdoruesve të tyre fundor, dhe ta bëjnë këtë brenda një plani dhe buxheti të parashikueshëm.

RUP udhëzon profesionistët e softuerit që të zbatojnë në mënyrë efektive praktikat më të mira aktuale si p.sh zhvillim iterativ, aplikacion Qasja e arkitekturës në qendër, rastet e përdorimit, reduktimi i rrezikut në të gjitha fazat e procesit dhe verifikimi i vazhdueshëm i programit.

Procesi i Unifikuar Racional bazohet në disa parime themelore, të mbledhura nga shumë projekte të suksesshme:

· Filloni të sulmoni më herët rreziqet kryesore dhe kryeni atë vazhdimisht, ose ata vetë do të shkojnë në ofensivë kundër jush.

· Sigurohuni që kërkesat e klientit janë përmbushur.

· Përqendrohuni në programin që po ekzekutohet.

· Përshtatuni me ndryshime që në fillim të projektit.

· Krijimi i hershëm i arkitekturës së ekzekutueshme.

· Ndërtoni një sistem nga komponentët.

· Punoni së bashku si ekip.

· Bëjeni cilësinë një mënyrë jetese, jo një mendim të mëvonshëm.

Përdoret RUP qasje përsëritëseÇdo përsëritje bën një pjesë të punës së kërkesave, analizës, dizajnimit, zbatimit dhe testimit. Çdo përsëritje bazohet në rezultatet e përsëritjeve të mëparshme dhe prodhon një program të ekzekutueshëm që lëviz një hap më afër produktit përfundimtar.

RUP ofron qasje e strukturuar ndaj zhvillimit përsëritës, duke e ndarë projektin në katër faza: Fillimi, Projektimi, Ndërtimi dhe Zbatimi. Çdo fazë shoqërohet me një të ashtuquajtur moment historik, një pikë kontrolli të procesit, në të cilën kontrollohet arritja e qëllimeve të fazës tjetër dhe merret një vendim për kalimin (ose jo) në fazën tjetër. Kështu, secila nga katër fazat e RUP ka një moment historik dhe një grup qëllimesh të përcaktuara qartë. Këto qëllime përdoren për të përcaktuar se cilat detyra duhet të kryhen dhe çfarë artefakte të krijohen. Çdo fazë fokusohet rreptësisht në atë që është e nevojshme vetëm për të arritur qëllimet e biznesit të fazës.

Të gjithë elementët e procesit - role, detyra, artefakte dhe të lidhura konceptet, udhëzuesit dhe shabllonet të grupuara në kontejnerë logjikë të quajtur Disiplinat(Disiplina). Ekzistojnë vetëm nëntë disiplina në produktin standard RUP. Këto përfshijnë: modelimin e biznesit, menaxhimin e kërkesave, menaxhimin e projektit, menaxhimin e ndryshimit dhe mjedisin.

Çdo rrjedhë pune e procesit: mbledhja e kërkesave, analiza, dizajnimi, zbatimi dhe testimi përcakton një grup artefaktesh dhe aktivitetesh të lidhura. Kujtoni që një objekt është një dokument, raport, element i ekzekutueshëm, etj. Artifakt mund të prodhohet, përpunohet ose konsumohet.

Model- lloji më i rëndësishëm i artefaktit. Janë dhënë nëntë modele, së bashku ato mbulojnë të gjitha zgjidhjet për vizualizimin, specifikimin, dizajnimin dhe dokumentimin e sistemeve softuerike:

· model biznesi. Përcakton abstraksionin e organizatës për të cilën po krijohet sistemi;

· modeli i domenit. Rregullon mjedisin kontekstual të sistemit;

· Rasti i përdorimit të modelit. Përcakton kërkesat funksionale për sistemin.

· model analize. Interpreton kërkesat e sistemit për sa i përket modelit të projektimit;

· modeli i projektimit. Përcakton fjalorin e fushës së problemit dhe zgjidhjen e tij;

· modeli i vendosjes. Përcakton topologjinë e harduerit në të cilën funksionon sistemi;

· modeli i zbatimit. Përcakton pjesët që përdoren për montimin dhe zbatimin e një sistemi fizik;

· model testimi. Përcakton rastet e testimit për të kontrolluar sistemin;

· modeli i procesit. Përkufizon paralelizmin në sistem dhe mekanizmat e sinkronizimit.

Artefakte teknike ndahen në katër grupe kryesore:

· grup kërkesash. përshkruan Çfarë sistemi duhet të bëjë;

· set dizajni.

· grup zbatimesh. Përshkruan montimin e komponentëve të softuerit të zhvilluar;

· set vendosjeje. Ofron të gjithë informacionin në lidhje me konfigurimin e dhënë.

Set kërkesash mund të përfshijë një model Use Case, një model kërkesash jofunksionale, një model domeni, një model analize dhe forma të tjera të shprehjes së nevojave të përdoruesit.

Kompleti i projektimit mund të përfshijë një model projektimi, një model testimi dhe forma të tjera të shprehjes së thelbit të sistemit.

Set i implementimeve grupon të gjitha të dhënat rreth elementeve të softuerit që përbëjnë sistemin (kodi i programit, skedarët e konfigurimit, skedarët e të dhënave, komponentët e softuerit, informacioni i montimit të sistemit).

Seti i vendosjes grupon të gjitha informacionet në lidhje me paketimin, transportin, instalimin dhe fillimin e sistemit.

Çdo proces teknologjik shoqërohet rreziku. Gjatë zhvillimit të një produkti softuer, një rezultat i pakënaqshëm (OKB) mund të jetë: tejkalimi i buxhetit, besueshmëria e ulët, funksionimi i gabuar, etj. Ndikimi i rrezikut llogaritet duke përdorur shprehjen

Treguesi i rrezikut = Probabiliteti (LP) * Humbja (LP).

Menaxhimi i riskut përfshin gjashtë veprime:

1. Identifikimi i rrezikut – identifikimi i elementeve të rrezikut në projekt.

2. Analiza e riskut – vlerësimi i probabilitetit dhe madhësisë së humbjes për çdo element rreziku.

3. Renditja e riskut – renditja e elementeve të riskut sipas shkallës së ndikimit të tyre.

4. Planifikimi i menaxhimit të rrezikut – përgatitja për t'u marrë me çdo element të rrezikut.

5. Zgjidhja e rrezikut – eliminimi ose zgjidhja e elementeve të rrezikut.

6. Monitorimi i rrezikut – ndjekja e dinamikës së elementeve të rrezikut, ndërmarrja e veprimeve korrigjuese.

Tre veprimet e para i përkasin fazës së vlerësimit të rrezikut, tre veprimet e fundit në fazën e kontrollit të rrezikut.

Ekzistojnë tre kategori të burimeve të rrezikut: rreziku i projektit, rreziku teknik dhe rreziku tregtar. Pas identifikimit të elementeve të rrezikut, ndikimi i tyre në projektin e softuerit duhet të matet dhe të zgjidhen pyetjet rreth humbjeve të mundshme. Këto çështje trajtohen gjatë hapit të analizës së rrezikut. Dhe së fundi, një plan për menaxhimin e secilit element rreziku, domethënë një grup funksionesh për menaxhimin e secilit element rreziku, është i integruar në planin e përgjithshëm të projektit softuer.