Vieningas programinės įrangos kūrimo procesas. Vieningas kūrimo procesas ir ekstremalus programavimas

Pagal GOST 34.601-90 „AS. Sukūrimo etapai“ nustato šiuos AIS kūrimo etapus, kurie, savo ruožtu, gali būti suskirstyti į etapus:

· reikalavimų AIS formavimas;

· AIS koncepcijos kūrimas;

techninės specifikacijos;

· preliminarus projektas;

· techninis projektas;

· darbo dokumentacija;

· paleidimas.

Kiekvienas etapas turi savo projektinę dokumentaciją ir sistemos techninių bei programinių modulių diegimą. Praktika rodo, kad sistemos kūrimo procesas yra kartotinis ir laipsniškas. UML autoriai tai pabrėžia apibrėždami sąvoką vieningas programinės įrangos ir informacijos kūrimo procesas. Nors pirmajame etape sudaromas reikalavimų rinkinys visai AS, iš tikrųjų jis pradžioje visada yra neišsamus ir paaiškinamas vėlesniuose etapuose. turiu padaryti iteracijos, tai yra, pakartokite atskirus veiksmus ir etapus visiškai arba iš dalies. Be to, reali sistema yra daugiafunkcė ir sudėtinga, todėl dažniausiai skirstoma į posistemes ir atskirus užduočių rinkinius, išskiriant pirmos pakopos, antrojo ir kt. posistemes ir užduotis. Sistema kuriama laipsniškai, palaipsniui didinant funkcionalumą, pakeičiant preliminaraus dizaino sprendimus labiau išvystytais, geriau atitinkančiais vartotojų poreikius. Tai sumažina finansinę riziką ir sutaupo laiko bei išteklių sąnaudas paskutiniuose kūrimo etapuose.

Naudojant UML metodiką kuriant AIS programinę įrangą ir informacijos palaikymą, siūloma sukurti tarpusavyje susijusių modelių rinkinį, atspindintį statines ir dinamines būsimos sistemos savybes:

· naudojimo atvejo modelis;

· analizės modelis;

· dizaino modelis;

· diegimo modelis;

· įgyvendinimo modelis;

· testavimo modelis.

Naudokite atvejo modelį apima naudojimo atvejų diagramas ir atitinkamus scenarijus, aprašo funkcinius sistemos reikalavimus ir jos elgesį bendraujant su vartotojais.

Analizės modelis apima bendrąsias klasių diagramas, skirtas įgyvendinti loginio lygio naudojimo atvejus, susijusias sekos diagramas ir (arba) bendradarbiavimo diagramas, ir yra eskizas, kaip bus įgyvendinti loginio lygio naudojimo atvejai.

Dizaino modelis yra detalus analizės modelio fizinio įgyvendinimo vaizdas ir apima paketų (posistemių) diagramas, išsamias klasių diagramas, sekos diagramas ir (arba) bendradarbiavimo diagramas, būsenų diagramas, įvairaus detalumo veiklos diagramas.

Diegimo modelis apima preliminarias diegimo diagramas, kurios apibrėžia visas tinklo konfigūracijas, kuriose gali veikti sistema. Diegimo diagramos nurodo tinklo mazgus, ryšio tipus ir aktyvių sistemos klasių pasiskirstymą tarp mazgų.

Įgyvendinimo modelis aprašoma, kaip projektavimo klasės įgyvendinamos kaip komponentai. Atitinkamai, jame yra komponentų diagramos, klasių (diegimo) pėdsakai, išsamios diegimo diagramos ir sistemos architektūros aprašymas.

Bandomasis modelis yra bandymo atvejų rinkinys, testavimo procedūros ir testo komponentų aprašymai. Jame nurodomi vykdomųjų sistemos komponentų testavimo metodai.

Palyginkime modelių kūrimo procesus su standartizuotais AS kūrimo etapais. Naudojimo atvejo modelis kuriamas AS reikalavimų formavimo etape; analizės modelis yra AS koncepcijos kūrimo stadijoje. Techninių specifikacijų ir preliminaraus projekto etape sudaromas projektinis modelis. Jis patobulintas techninio projektavimo etape ir papildytas diegimo modeliu. Darbo dokumentacijos etape sukuriami įgyvendinimo ir testavimo modeliai. Galiausiai, paleidimo etape testavimo modelis yra tobulinamas ir eksploatacijos metu tampa etaloniniu modeliu, skirtu periodiškai tikrinti, ar sistema tinkamai funkcionuoja ir diagnostika.

1.5 UML kalbos komponentai

Vieningoji modeliavimo kalba UML(Unified Modeling Language) yra vizualinio modeliavimo kalba, naudojama sudėtingoms sistemoms (įskaitant programinę įrangą) nurodyti, vizualizuoti, konfigūruoti ir dokumentuoti naudojant objektinę technologiją.

Kuriant AS UML metodikoje, naudojami struktūrinės sistemos analizės principai, žinomi iš Hein/Sarson ir SADT metodikų:

· kūrimas iš viršaus į apačią etapais;

· diagramų sudarymo technika;

· aprašymų hierarchija;

· griežtas projektinių sprendinių aprašo įforminimas;

· pradinis projekto kūrimas loginiu lygiu be techninio įgyvendinimo detalių;

· konceptualus modeliavimas pagal dalykinę sritį, kad klientas suprastų sistemos dizainą;

· technologinis palaikymas su įrankiais (CASE sistemos).

Sudėtingos sistemos modelis UML gali būti tiriamas, siekiant gauti apskaičiuotas sistemos procesų efektyvumo charakteristikas.

AS programinės įrangos ir informacijos palaikymo UML diegimo, diegimo ir testavimo modeliai gali būti naudojami kaip taikomųjų programų projektas su vėlesniu automatiniu programos kodo generavimu vienoje iš pasirinktų programavimo aplinkų.

Gana išsamus sudėtingos sistemos modelis turėtų atspindėti du aspektus:

-statinis(struktūrinė) – sudedamųjų dalių sudėtis, struktūra ir jų santykiai;

-dinamiškas(elgesio) – sistemoje vykstančių ar diegtinų procesų logikos aprašymas.

Pagrindinis UML modelių vaizdavimo būdas yra diagramos, pateikiamos su tekstine informacija, įskaitant išraiškas įtaisytoje suvaržymo kalboje OCL, taip pat programavimo ir informacijos užklausų kalbomis, naudojamomis sistemai įgyvendinti.

Pagrindinis modeliavimo principas: sistema modeliuojama kaip grupė diskrečių objektų, kurie sąveikauja tarpusavyje taip, kad patenkintų vartotojo poreikius.

Statinis modelis nurodo struktūrą, objektų tipus ir ryšius tarp objektų. Dinaminis modelis nustato objektų elgseną laikui bėgant (objektų istoriją) ir jų sąveiką.

Iš esmės UML yra diskrečioji modeliavimo kalba, tai yra, joje yra diskrečių įvykių ir būsenos pokyčių sąvoka. Nuolatiniai procesai modeliuojami apytiksliai diskretizuojant.

Modelis turi du aspektus: semantinę informaciją (semantiką) ir vizualinį atvaizdavimą (žymėjimą).

Visa modelio vaizdų UML kalba sudėtis pateikta 1 lentelėje

1 lentelė. Sistemos modelių vaizdavimas UML.

Labiausiai paplitęs konceptualus sistemos modelis yra naudojimo atvejų diagrama, kuri yra kitų diagramų kūrimo pradžios taškas.

Visos kalbos diagramos yra specialaus tipo grafikai, kuriuose yra viršūnių (geometrinių figūrų), sujungtų briaunomis (lankais). Paprastai vaizdo mastelis ir viršūnių vieta nėra ypač svarbūs, tačiau sekos diagramoje įvedama laiko ašis ir ten ji yra reikšminga.

Ryšiai plokštumoje žymimi įvairiomis linijomis, figūrų viduje rašomas tekstas, šalia viršūnių ir jungčių gali būti pavaizduoti kai kurie grafiniai simboliai. UML plėtiniai leidžia kurti erdvines diagramas.

Kalba turi 4 tipų grafines struktūras:

· piktogramos (piktogramos);

· grafiniai simboliai plokštumoje;

· takai (linijos);

· teksto eilutės.

1.6 Koncepcinis lygis. Naudokite atvejo modelį

Apskritai, į objektą orientuotas projektavimo procesas vyksta pagal pagrindinius struktūrinių sistemų analizės principus: projektavimas iš viršaus į apačią su diagramų hierarchijos konstravimu, kuris palaipsniui perkelia mus iš lygio į lygį: konceptualus – loginis – fizinis (įgyvendinimas)

Aukščiausio lygio diagrama laikoma tokia, kurią pasiūlė A. Jacobsonas OOSE naudojimo atvejų diagrama sistemos kaip visuma. Būtent tai yra pradinis konceptualus sistemos vaizdas ir yra sukurtas siekiant:

· nustatyti bendras modeliuojamos dalykinės srities ribas ir kontekstą;

· suformuluoti bendruosius sistemos funkcinės elgsenos ir sąsajos reikalavimus;

· parengti pirminę dokumentaciją kūrėjų ir klientų – sistemos vartotojų sąveikai.

Modelio požiūris: išorinis sistemos vartotojas. Naudojimo atvejų diagrama apima veikėjus, naudojimo atvejus ir asociacijas.

Aktantas(aktorius, išorinis subjektas, veikėjas) – abstraktus pranešimų šaltinių/gavėjų, kurie tiesiogiai sąveikauja su sistema, posisteme ar klase, klasės aprašymas. Tai yra aprašymas vaidmenisžaidžia vartotojas (asmuo ar kita sistema, posistemis, klasė) sąveikos su sistema metu. Iš esmės tai yra panašių informacijos užklausų apibendrinimas sistemai, kurioms reikia tam tikro paslauga(paslaugos).

Aktantas nebūtinai turi būti tapatinamas su konkrečiu asmeniu ar įrenginiu, nors tai kartais iš esmės įmanoma, jei jie atlieka tik vieną vaidmenį. Dažniausiai – fiziškai – tai skirtingi žmonės ir įrenginiai, prisijungiantys prie sistemos, norėdami gauti tą pačią paslaugą. Pavyzdžiui, aukščiausiu lygmeniu veikiantieji gali būti operatorius, sistemos administratorius, duomenų bazės administratorius, eilinis vartotojas arba tam tikra įrenginių klasė.

Visi galimi aktantai išnaudoja visus įmanomus vartotojo sąveikos su sistema būdus (posistemę, klasę). Diegiant sistemą, aktantai įkūnija žmones ir fizinius objektus. Vienas asmuo arba fizinis objektas, priklausomai nuo sąveikos būdo, gali atstovauti keliems aktantams (skirtingiems vaidmenims). Pavyzdžiui, tas pats asmuo gali būti operatorius ir duomenų bazės administratorius, pardavėjas ir pirkėjas ir kt.

Daugelyje AS nėra kitų veikėjų, išskyrus žmones. Tačiau aktyvatoriai gali būti išorinė sistema, įvesties / išvesties įrenginys arba laikmatis (dažniausiai randamas įterptosiose realaus laiko sistemose). Tarp aktantų naudojimo atveju išsiskiria vienas pagrindinė veikėja(pagrindinis veikėjas), kuris pradeda darbą su sistema. Likusieji yra antraeiliai, jie taip pat dalyvauja naudojimo atveju, gaudami rezultatus ir įvesdami kai kuriuos tarpinius duomenis.

Loginiame ir fiziniame lygmenyse aktantus vaizduoja klasės ir objektai, kurie yra klasių pavyzdžiai. Galima sukurti aktantų hierarchiją, paveldint visus vaidmenis ir santykius, atributus ir operacijas, kurias turi aktanto protėvis. Vaiko aktanto atvejis visada gali būti naudojamas toje sistemos vietoje, kur deklaruojamas protėvio aktanto naudojimas (pakeitimo principas).

Diagramose aktantas gali būti pavaizduotas dviem būdais:

3. Klasės simbolis (stačiakampis) su vidine stereotipo nuoroda

4. Standartiškesnis: „vyras“ su užrašu (asmens simbolis)

Aktantas yra už sistemos ribų ir jo vidinė struktūra nenustatyta. Tai yra pranešimų šaltinis / gavėjas.

Klientas

Naudojimo dėklas(precedentas, naudojimo atvejis) – abstraktus paslaugų klasės (paslaugų funkcijų) aprašymas, pateikiamas aktantui reaguojant į jo prašymus.

Paslaugą gali teikti visa sistema, posistemis arba klasė. Taigi naudojimo atvejis reiškia tam tikros sistemos funkcionalumo ar elgesio dalies modeliavimą. Naudojimo atvejis turi pavadinimą ir reiškia tam tikrą veiksmų seką, matomą išoriniam šaltiniui / imtuvui (aktantui). Vidinis varianto įgyvendinimo būdas yra paslėptas ir atskleidžiamas žemesniu detalumo lygiu. bendradarbiavimo diagrama. Kaip ir bet kuri klasė, naudojimo atvejis turi atributų ir operacijų, kurių įgyvendinimas rodomas fiziniame lygmenyje.

Naudojimo atvejis apima visą pranešimų seką, kurią aktantas pradeda ir baigia sistema (posisteme, klase). Todėl bet koks naudojimo atvejo diegimo atvejis visada turi pradžią laike ir pabaigą, kai joks veikėjas nesiunčia pranešimų šiai parinktimi. Tai apima ir klaidų pranešimus, techninės priežiūros funkcijos atlikimo su įvairiais nustatymais (alternatyvomis) parinktis.

Naudojimo atvejo pavyzdys yra naudojimo atvejo vykdymas, kuris prasideda pirmą kartą gavus pranešimą iš veikiančio egzemplioriaus. Atsakydamas į duotą pranešimą, naudojimo atvejis atlieka tam tikrą veiksmų seką, pvz., siunčia pranešimą kitiems aktanto egzemplioriams (ne tik iniciatoriui). Savo ruožtu šie veikėjai siunčia pranešimus šiam naudojimo atvejo egzemplioriui, o sąveika tęsiasi tol, kol daugiau tokių pranešimų negaunama. Tai žymi naudojimo atvejo pabaigą.

Parodytas aktanto ir naudojimo atvejo santykis asociacija.

Diagramoje naudojimo atvejis pavaizduotas dviem būdais:

1) elipsė, viduje dedamas vardas

2) stačiakampis – kaip ir bet kuri klasė

Klientas

Jutiklis

Tarp veikiančiųjų ir naudojimo atvejų asociacija yra vienintelis ryšio tipas. Be to, jis turi semantiką perjungiamas ryšys, ty pranešimo perdavimas, paprastai nepažymėtas, nes kontekstas yra aiškus iš aktanto ir vartosenos raidžių žymėjimo. Bet jūs galite tai pažymėti ir nurodyti ryšio daugumą:

Banko klientas

Daugybė(daugybė) apibūdina konkrečių klasės egzempliorių, dalyvaujančių tam tikrame ryšyje, skaičių (vienas klientas gali išduoti neribotą skaičių paskolų).

Apskritai asociacija yra ryšys tarp dviejų ar daugiau modelio komponentų. Kadangi daugeliu atvejų komponentai yra kai kurios objektų klasės, susiejimo egzempliorius yra tiesiog sutvarkytas nuorodų į konkrečius atvejus sąrašas, galbūt aprūpintas asociacijos atributais (ypatybėmis).

Asociacijos pavadinimas, jei toks yra, turi būti unikalus. Jis formuojamas pagal santykių tarp klasių, kurios yra asociacijos dalyviai, prasmę. Pavyzdžiui, „Darbuotojas veikia_į Skyrius“, „Vadovas užbaigia Kompiuteris“ ir kt.

Asociacijos pačios yra klasės ( asociacijos klasė, asociacijos klasė), ji turi ir klasės, ir asociacijos savybių. Šios klasės egzemplioriai yra ryšiai, turintys ne tik nuorodas į objektus, bet ir atributų (ypatybių) reikšmes.

Asociacijos nariai vadinami jos stulpai. Visi poliai yra jungtyje dalyvaujančių klasių vaidmenys, jie yra skirtingi ir gali būti išvardyti tam tikrame eilės tvarka. Daugeliu atvejų asociacijos yra dvejetainės (du vaidmenys asociacijoje su tam tikra semantika), tačiau gali būti ir n -ari. Viena ir ta pati klasė gali atlikti skirtingus vaidmenis, tai yra vienu metu būti dviejuose asociacijos poliuose.

Prie polių nurodomas jungčių gausumas.

Sistemos veikimo metu gali atsirasti ir išnykti jungtys ir atitinkami predikatai gali būti nurodyti asociacijos poliuose.

Kartais ryšys keičiasi tik viename iš polių. Jei nuoroda turi atributus, juos galima keisti operacijomis, tačiau nuorodos į nuorodos dalyvius nesikeičia.

Asociacija vaizduojama kaip ištisinė linija, jungianti 2 klasių ribas n-ary, tada nubrėžiamas rombas (sujungimo ženklas):

		Daug asociacijų - agregacija
	Dvejetainė asociacija

Naudojimo atvejai nesikeičia pranešimais tarpusavyje ir gali būti tik santykiuose (ryšiuose) plėtiniai(pratęsti) įtraukimas(įskaitant) ir apibendrinimai(apibendrinimas).

IN dėl plėtimosi naudojimo atvejis – klientas įveda papildomą veiksmų seką, pradedant nuo kurio nors pagrindinės sekos taško, ir tokių „įterpimų“ gali būti keli. Visi šie taškai vadinami išplėtimo taškai.

Rational Unified Process (RUP) yra viena geriausių programinės įrangos kūrimo metodikų, kurią sukūrė Rational Software. Remiantis daugelio sėkmingų programinės įrangos projektų patirtimi, „Unified Process“ leidžia kurti sudėtingas programinės įrangos sistemas, pagrįstas pramonės plėtros metodais. Vienas iš pagrindinių ramsčių, kuriuo remiasi RUP, yra modelių kūrimo procesas naudojant vieningą modeliavimo kalbą (UML). Šis straipsnis yra apie UML diagramų naudojimą programinės įrangos sistemų kūrimo darbo eigoje, naudojant Rational Software metodiką.

Ne paslaptis, kad programinės įrangos kūrimas yra sudėtingas procesas, kuris, viena vertus, turi daug bendro su kūrybiškumu, o kita vertus, nors ir labai pelningas, bet ir brangus verslas. Arši konkurencija rinkoje verčia kūrėjus ieškoti efektyvesnių darbo metodų. Būdai sukurti programinės įrangos sistemas dar greičiau, mažesnėmis sąnaudomis ir geresne kokybe. Programų sudėtingumas nuolat didėja. Dar visai neseniai programinės įrangos produktus per numatytą laikotarpį galėjo sukurti asmenys arba, pavyzdžiui, automatizuotos įmonės IT skyrius.

Šiais laikais asmenims, kurie kuria programas ant kelių, lieka mažų komunalinių paslaugų ir įvairių „sunkių“ programinės įrangos produktų išplėtimo modulių. Ateitis priklauso pramoniniam požiūriui į programinės įrangos kūrimą. 1913 metais Henris Fordas paleido pirmąją automobilių surinkimo liniją, o 90-aisiais panaši surinkimo linija pradėta naudoti IT technologijų srityje. Komandos ugdymas reikalauja visai kito požiūrio ir kitokios metodikos, kurią anksčiau ar vėliau reikėjo sukurti.

„Rational Software Corporation“ (http://www.rational.com) išleido struktūrizuotą žinių bazę, pavadintą „Rational Unified Process“ (RUP), kuri yra išsamių rekomendacijų, kaip sukurti beveik bet kokį programinės įrangos produktą, rinkinys. Pasisavinusi geriausių patobulinimų patirtį, RUP išsamiai pasakoja, kada, kas ir ką turėtų daryti projekte, kad programinė įranga būtų sukurta laiku, su tam tikru funkcionalumu ir neviršijant numatyto biudžeto.

Vieningą procesą galima suvokti kaip įvairių kūrimo įmonės veiklų, reikalingų klientų reikalavimams paversti programinės įrangos sistema, suma. Sistema, kuri vartotojams suteiktų „prasmingų rezultatų“ ir padarytų būtent tai, ko jie tikisi iš sistemos. Todėl procesas yra valdomas sistemos panaudojimo atvejais arba kitaip – ​​precedentais.

Siekiant laiku įgyvendinti klientų reikalavimus, vieningas procesas yra padalintas į fazes, susidedančias iš iteracijų, todėl procesas taip pat vadinamas kartotiniu ir laipsnišku. Kiekviena iteracija atlieka pagrindinio darbo ciklą ir priveda kūrėjus prie galutinio tikslo: sukurti programinės įrangos sistemą. Iteracijų metu sukuriami tarpiniai artefaktai, reikalingi sėkmingam projekto užbaigimui ir programinės įrangos sistemos versija, kuri įgyvendina tam tikrą funkcijų rinkinį, kuris didėja nuo iteracijos iki iteracijos. Proceso fazės ir pagrindiniai darbo srautai parodyti fig. 1, ten taip pat pateikiamos apytikslės darbo sąnaudos pagal fazes.

ryžių. 1 RUP fazės ir darbo srautai

Reikėtų pažymėti, kad pav. 1 parodytas tik pagrindinis vieningo proceso darbas. Pavyzdžiui, veiklos valdymo veikla čia nerodoma, kad diagrama nebūtų netvarkinga.

Visas programinės įrangos kūrimas RUP laikomas artefaktų kūrimo procesu. Bet koks projekto rezultatas, ar tai būtų šaltinio kodai, objektų moduliai, vartotojui perduoti dokumentai, modeliai – tai visų projekto artefaktų poklasiai. Kiekvienas projekto komandos narys kuria savo artefaktus ir yra už juos atsakingas. Programuotojas kuria programą, vadovas – projekto planą, o analitikas – sistemos modelį. RUP leidžia nustatyti, kada, kam ir kokį artefaktą reikia sukurti, modifikuoti ar naudoti.

Viena iš įdomiausių projektų artefaktų klasių yra modeliai, leidžiantys kūrėjams apibrėžti, vizualizuoti, konstruoti ir dokumentuoti programinės įrangos sistemų artefaktus. Kiekvienas modelis yra atskiras kuriamos sistemos vaizdas ir skirtas problemoms apibūdinti ir sprendimų pasiūlymui. Modelių savarankiškumas reiškia, kad analitikas ar kūrėjas gali gauti visą jam reikalingą informaciją iš konkretaus modelio nesikreipdamas į kitus šaltinius.

Modeliai leidžia apgalvoti būsimą sistemą, jos objektus ir jų sąveiką dar prieš investuojant dideles lėšas į plėtrą, jie leidžia pamatyti tai būsimų vartotojų akimis iš išorės ir kūrėjų akimis iš vidaus dar prieš pirmąją pirminio kodo eilutę; yra sukurtas. Dauguma modelių yra pavaizduoti UML diagramomis, pavyzdžiui, galite perskaityti daugiau apie UML.

Vieninga modeliavimo kalba atsirado devintojo dešimtmečio pabaigoje ir 90-ųjų pradžioje, daugiausia dėl „trijų draugų“ Gradi Bucha, Jimo Rambo ir Ivar Jacobson pastangų. Dabar OMG konsorciumas ją priėmė kaip standartinę modeliavimo kalbą, kuri suteikia kūrėjams aiškią žymėjimą, leidžiančią modelius rodyti grafiniuose elementuose, kurie yra įprasti ir suprantami kiekvienam projekto dalyviui.

Tačiau nereikėtų pamiršti, kad modeliavimo kalba pateikia tik žymėjimą – sistemos aprašymo ir modeliavimo įrankį, o vieningas procesas apibrėžia šio įrankio naudojimo metodiką, o taip pat ir kitas metodikos palaikymo priemones iš Rational. UML galima naudoti be konkrečios metodikos, nes ji yra nepriklausoma nuo proceso ir nesvarbu, kuri proceso parinktis naudojama, galite naudoti diagramas, kad dokumentuotų kūrimo metu priimtus sprendimus ir atvaizduotų sukurtus modelius.

Programinė įranga yra sukurta tam, kad išspręstų konkrečias vartotojo problemas, o ne programuotojams, kad išbandytų naujas technologijas ir įgytų patirties projekto vadovui. Apskritai vartotojui nerūpi, ar kūrimo procese naudojate objektinį metodą, UML, RUP, ar kuriate sistemą naudodami XP (ekstremalaus programavimo) metodą. Tam tikrų metodų, technologijų panaudojimas, optimalios vidinės projekto struktūros sukūrimas lieka ant kūrėjų sąžinės, kurie sprendimus priima remdamiesi ankstesne patirtimi ir savo pageidavimais. Tačiau vartotojas jums neatleis už jo reikalavimų ignoravimą. Net jei programinės įrangos sistema yra sukurta dešimt kartų naudojant naujausius metodus ir technologijas, jei vartotojas iš jos negaus vadinamojo „prasmingo rezultato“, jūsų programinės įrangos projektas apgailėtinai žlugs.

Iš to išplaukia, kad neapgalvotas UML naudojimas vien dėl to, kad tai madinga, ne tik neprives tobulėjimo į sėkmę, bet ir gali sukelti darbuotojų, kuriems reikia perskaityti daug papildomos literatūros, ir projektų vadovų nepasitenkinimą, kai paaiškės, kad darbo sąnaudos projekte didėja, o grąža nedidėja. Turite aiškiai suprasti, ko norite gauti įdiegę šią technologiją, ir laikytis šio tikslo. UML naudojimas taupo kūrimo išteklius, nes leidžia greičiau susidaryti vaizdą apie sistemą nei kuriant maketus ir prototipus, išleidžiant nepalyginamai mažiau išteklių.

Diagramos palengvina projekto narių tarpusavio bendravimą ir, kas ypač vertinga, į procesą įtraukia galutinius sistemos vartotojus. Modeliavimas leidžia sumažinti projekto riziką, nes programuotojams visada lengviau daryti tai, kas aišku ir suprantama, nei siekti neapibrėžto rezultato. Diagramų kūrimas yra panašus į projekto kūrimą statybose - galite apsieiti be jo, pavyzdžiui, statydami trobą ant vasarnamio, tačiau kuo didesnis pastatas (mūsų atveju programinės įrangos produktas), tuo sunkiau. daryti ir tuo labiau neapibrėžtas galutinis rezultatas.

Kartą vedžiau seminarą apie RUP vienoje programinės įrangos įmonėje, kuri dešimt metų gana sėkmingai dirbo rinkoje, tačiau savo darbo eigoje visiškai nenaudojo modeliavimo, o buvo paremta prototipais. Salėje susirinko apie dvidešimt jaunų ir patyrusių programuotojų, kurie atidžiai klausėsi visko, ką jiems pasakojau apie RUP ir UML. Ir vienas iš jų, žiūrėdamas į lentą, padengtą pavyzdinėmis schemomis, pastebėjo: „Visa tai įdomu ir tikriausiai tinka kitiems projektams“, – sakė jis, „bet mes jau gana ilgai dirbame be viso to, nes esame vis tiek mes apsiėjome be UML, tikriausiai mums to tiesiog nereikia.

Šis klausimas privertė susimąstyti, kad verslo procesų pasikeitimas, kuris neišvengiamai turi įvykti programinės įrangos kūrimo įmonėje diegiant RUP ir UML, gali būti toks pat sunkus kaip ir informacinės sistemos diegimas pramonės įmonėje. Bet koks diegimas yra stereotipų laužymas. Kadangi programinės įrangos kūrimo įmonės darbuotojų kvalifikacija yra gana aukšta, tokiems žmonėms yra sunkiau atsisakyti savo pažiūrų nei „paprastiems mirtingiesiems“, o kylančius sunkumus ir atmetimą galima palyginti su perėjimu nuo procedūrinio prie objektinio. orientuotas mąstymas.

1.Reikalavimų apibrėžimas

Vieningas procesas yra procesas, kurį lemia naudojimo atvejai, atspindintys vartotojo sąveikos scenarijus. Tiesą sakant, tai vartotojų požiūris į programinės įrangos sistemą iš išorės. Taigi, vienas svarbiausių kūrimo etapų, anot RUP, bus reikalavimų nustatymo etapas, kuris susideda iš visų įmanomų sistemos veikimo pageidavimų, kuriuos gali sugalvoti vartotojai ir analitikai, surinkimo. Vėliau šiuos duomenis reikės sisteminti ir struktūrizuoti, tačiau šiame etape analitikai, apklausdami vartotojus ir tyrinėdami dokumentus, turi surinkti kuo daugiau reikalavimų būsimai sistemai, o tai nėra taip paprasta, kaip atrodo iš pirmo žvilgsnio. Vartotojai dažnai neįsivaizduoja, ką jie turėtų gauti. Norėdami palengvinti šį procesą, analitikai naudoja naudojimo atvejų diagramas (2 pav.)

2 pav. Naudojimo atvejo diagramos pavyzdys

Diagrama yra veikėjų (aktantų), kurie sąveikauja su sistema, atspindys ir programinės įrangos objektų reakcija į jų veiksmus. Veikėjai gali būti ir vartotojai, ir išoriniai agentai, kuriems reikia perduoti arba gauti informaciją. Naudojimo atvejo piktograma atspindi sistemos reakciją į išorinę įvestį ir parodo, ką reikia padaryti su aktyvantu.

Norint detalizuoti konkretų naudojimo atvejį, naudojama veiklos diagrama, kurios pavyzdys pateiktas 3 paveiksle.

ryžių. 3 Veiklos diagramos pavyzdys

Naudojimo atvejų diagramos paprastumas leidžia analitikams lengvai bendrauti su klientais reikalavimų apibrėžimo proceso metu, nustatant apribojimus, taikomus sistemai ir įgyvendinant individualius reikalavimus, pvz., sistemos atsako laiką, kurie vėliau patenka į nefunkcionalumo skyrių. reikalavimus.

Naudojimo atvejų diagrama taip pat gali būti naudojama kuriant bandymo scenarijus, nes visos vartotojų ir sistemos sąveikos jau apibrėžtos.

Norėdami teisingai nustatyti reikalavimus, kūrėjai turi suprasti kontekstą (dalykos sritį), kuriame veiks būsima sistema. Tam sukuriamas domeno modelis ir verslo modelis, kurie yra skirtingi požiūriai į tą pačią problemą. Dažnai sukuriamas vienas dalykas: domeno modelis arba verslo modelis.

Skirtumas tarp šių modelių yra tas, kad domeno modelis apibūdina svarbias sąvokas, su kuriomis sistema veiks, ir jų ryšius tarpusavyje. Tuo tarpu verslo modelis apibūdina verslo procesus (esamus ar būsimus), kuriuos sistema turėtų palaikyti. Todėl šis modelis ne tik apibrėžia procese dalyvaujančius verslo objektus, bet ir apibrėžia darbuotojus, jų pareigas ir veiksmus, kuriuos jie turi atlikti.

Domeno modeliui sukurti naudojama įprasta klasių diagrama (6 pav.), tačiau jos aiškiai nepakanka sukurti verslo modelį. Šiuo atveju naudojama naudojimo atvejų diagrama, naudojant papildomas piktogramas, kurios atspindi verslo procesų esmę – tai verslo veikėjas, verslo naudojimo atvejis, verslo subjektas ir verslo valdymas. Šis modelis yra daug artimesnis kitam modeliui, kuriamam kūrimo procese – analizės modeliui.

2.Analizė

Nustačius reikalavimus ir kontekstą, kuriame sistema veiks, laikas analizuoti gautus duomenis. Analizės proceso metu sukuriamas analitinis modelis, nukreipiantis kūrėjus į būsimos sistemos architektūrą. Analitinis modelis yra sistemos vaizdas iš vidaus, o ne naudojimo atvejo modelis, kuris parodo, kaip sistema atrodys iš išorės.

Šis modelis leidžia suprasti, kaip sistema turėtų būti sukurta, kokias klases ji turėtų turėti ir kaip jos turėtų sąveikauti viena su kita. Jo pagrindinis tikslas – nustatyti reikalavimų rinkimo etape nustatyto funkcionalumo įgyvendinimo kryptį ir nubraižyti sistemos architektūrą.

Skirtingai nuo vėliau sukurto dizaino modelio, analizės modelis yra labiau konceptualus modelis ir tik priartina kūrėjus prie diegimo klasių. Šis modelis neturėtų turėti galimų prieštaravimų, kurie gali atsirasti precedento modelyje.

Analizės modeliui atvaizduoti naudojant UML, naudojama klasių diagrama su stereotipais (elgesio modeliais) „ribinė klasė“, „esybė“, „kontrolė“, o detalizavimui naudojamos bendradarbiavimo diagramos (4 pav.). „Ribinės klasės“ stereotipas vaizduoja klasę, kuri sąveikauja su išoriniais veikėjais, „esybės“ stereotipas vaizduoja klases, kurios yra duomenų saugyklos, o „kontrolės“ stereotipas vaizduoja klases, kurios valdo užklausas subjektams.

4 pav. Bendradarbiavimo diagramos pavyzdys

Laiškų numeracija rodo jų eiliškumą, tačiau diagramos tikslas yra ne pažvelgti į apsikeitimo žinučių tvarką, o aiškiai parodyti klasių tarpusavio ryšius.

Jei sutelksime dėmesį į sąveikos tvarką, tada kitas vaizdas būtų sekos diagrama (Sequence), parodyta 5 paveiksle. Ši diagrama leidžia pažvelgti į apsikeitimą pranešimais laikui bėgant, vizualiai atvaizduojant proceso seką. Naudojant modelio kūrimo įrankį, pvz., „Rational Rose“, šių dviejų tipų diagramas galima sukurti automatiškai (pavyzdžiui, daugiau apie „Rational Rose“ galite perskaityti).

Ryžiai. 5 Sekos diagramos pavyzdys

Sprendimas, kurią iš dviejų diagramų sukurti pirmiausia, priklauso nuo individualaus kūrėjo pageidavimų. Kadangi šios diagramos yra to paties proceso vaizdas, abi jos leidžia atspindėti objektų sąveiką.

3.Dizainas

Kitas sistemos kūrimo proceso žingsnis – projektavimas, kurio metu pagal anksčiau sukurtus modelius sukuriamas projektavimo modelis. Šis modelis atspindi fizinį sistemos įgyvendinimą ir apibūdina sukurtą produktą klasės ir komponento lygiu. Skirtingai nuo analizės modelio, projektavimo modelis aiškiai priklauso nuo įgyvendinimo sąlygų, programavimo kalbų ir naudojamų komponentų. Siekiant tiksliausiai suprasti sistemos architektūrą, šis modelis turėtų būti kiek įmanoma formalizuotas ir nuolat atnaujinamas per visą sistemos kūrimo ciklą.

Projektavimo modeliui sukurti naudojamas visas rinkinys UML diagramų: klasių diagramos (5 pav.), bendradarbiavimo diagramos, sąveikos diagramos, veiklos diagramos.

6 pav. Klasių diagramos pavyzdys

Be to, ši darbo eiga gali sukurti diegimo modelį, kuris yra įgyvendinamas pagal diegimo diagramą. Tai paprasčiausias diagramos tipas, skirtas modeliuoti įrenginių pasiskirstymą tinkle. Ekranui naudojamos tik dvi procesoriaus ir įrenginio piktogramų parinktys bei jungtys tarp jų.

4.Įgyvendinimas

Pagrindinis diegimo proceso uždavinys yra sukurti sistemą komponentų pavidalu – programos šaltinio kodai, scenarijai, dvejetainiai failai, vykdomieji moduliai ir kt. Šiame etape sukuriamas įgyvendinimo modelis, kuriame aprašoma, kaip realizuojami projektavimo modelio elementai, kokios klasės bus įtrauktos į konkrečius komponentus. Šis modelis apibūdina šių komponentų organizavimo būdą pagal pasirinktoje programavimo aplinkoje priimtus struktūrizavimo ir moduliavimo mechanizmus ir yra pavaizduotas komponentų diagrama (7 pav.).

ryžių. 7 Komponentų diagramos pavyzdys

5.Testavimas

Testavimo proceso metu tikrinami diegimo rezultatai. Šiam procesui yra sukurtas testavimo modelis, kuris susideda iš testavimo atvejų, testavimo procedūrų, testavimo komponentų, tačiau neturi UML diagramos atvaizdavimo, todėl prie jo nesigilinsime.

6.Išvada

Čia buvo nagrinėjami tik pagrindiniai Racionalios metodologijos procesai. RUP yra gana platus, jame pateikiamos rekomendacijos, kaip vykdyti įvairius programinės įrangos projektus – nuo ​​programų kūrimo kelių žmonių kūrėjų grupės iki paskirstytų programinės įrangos projektų, vienijančių tūkstančius žmonių skirtinguose žemynuose. Tačiau nepaisant didžiulių skirtumų, modelių, sukurtų naudojant UML, naudojimo metodai bus tokie patys. UML diagramos, sukurtos įvairiuose kūrimo etapuose, yra neatskiriamos nuo kitų programinės įrangos projekto artefaktų ir dažnai yra atskirų RUP procesų sąsaja.

Sprendimas naudoti konkrečias diagramas priklauso nuo įmonėje nustatyto kūrimo proceso, kuris, nors ir vadinamas unifikuotu, nėra kažkas sustingusio. „Rational“ ne tik siūlo ją tobulinti ir patobulinti, bet ir suteikia specialius įrankius RUP duomenų bazės pakeitimams atlikti.

Bet bet kuriuo atveju UML naudojimas kartu su vieningu procesu leis gauti nuspėjamą rezultatą, įvykdyti skirtą biudžetą, padidinti projekto dalyvių poveikį ir kuriamo programinio produkto kokybę.

Kratchen. F. Įvadas Racionalus vieningas procesas . Red. 2 - M.: Williams Publishing House, 2002. - 240 p.: iliustr.

Jacobson A., Buch G., Rambo J. Vieningas programinės įrangos kūrimo procesas – Sankt Peterburgas: Peter, 2002. – 496 p.: iliustr.

Fowler M., Scott K. UML trumpai. Standartinės objektų modeliavimo kalbos taikymas: Transl. iš anglų kalbos – M.:Mir, 1999. – 191 p., iliustr.

Beck. E. Ekstremalus programavimas. – Sankt Peterburgas: Petras, 2002. – 224 p.: iliustr.

Trofimovas S. CASE technologijos: Praktinis darbas Rational Rose.
Red. 2 - M.: Binom-Press, 2002 - 288 p.

Unified Process aktyviai naudoja vieningą modeliavimo kalbą ( UML). Šerdyje UML yra modelis, leidžiantis kūrėjų komandai supaprastintu būdu suprasti sudėtingų procesų, reikalingų programinei įrangai kurti, įvairovę. Naudojami įvairūs modeliai Vieningas procesas, leidžia vizualizuoti sistemą, aprašyti jos struktūrą ir elgesį bei dokumentuoti kūrimo proceso metu priimtus sprendimus.

Kilmės istorija

Karkaso ištakos glūdi darbuotojo darbe Ericsson Ivaras Jacobsonas, išleistas septintojo dešimtmečio pabaigoje. Jacobsonas ir jo kolegos sumodeliavo didžiules telekomunikacijų sistemas, naudodamos „blokų“ sluoksnius (kas vėliau tapo žinomas kaip „komponentai“): apatiniai sluoksniai buvo viršutinių sluoksnių posistemių pagrindas. Komanda sukūrė apatinius blokus, atsižvelgdama į „eismo atvejus“, kurie gali nutikti sistemos naudotojams. Būtent šie „incidentai“ tapo naudojimo atvejų prototipu, kurie vėliau buvo įtraukti UML. Jacobsono darbai taip pat įkvėpė kurti diagramas, naudojamas UML, įskaitant veiklos ir sekos diagramas .

1987 m. Jacobsonas įkūrė savo įmonę Prieštaravimas AB ir kartu su partneriais keletą metų praleido kurdami projektą ir produktą pavadinimu Prieštaravimas. 1995 metais Jacobsonas išleido knygą „ Objektinė programinės įrangos inžinerija“, aprašantis kūrimo procesą, kurį lemia klientų reikalavimai, kurie panaudojimo atvejais paverčiami galutiniu produktu. Knygos išleidimas sutapo su pirmuoju internetinės branduolio versijos publikavimu Vieningas procesas.

Įmonė 1995 m Prieštaravimas AB absorbuojamas korporacijos Racionalus. Padedamas žymiai padidėjusio kolegų skaičiaus, Jacobsonas pradeda plėsti procesą Prieštaravimas, papildant jį projektų valdymo ir plėtros įrankiais. Kartu su Grady Booch ir Jamesu Rumbaugh, kurie dirbo Racionalus anksčiau Jacobsonas tapo „trijų draugų“ grupės nariu, kuris vadovavo darbui sukurti procesą, vadinamą Racionalus objekto procesas (ROP), taip pat platinimas Vieningas procesas, kuris tapo pagrindu Vieninga modeliavimo kalba.

Darbo procese ROP Ir UML, korporacija Racionalus tęsiasi įmonių, dalyvaujančių programinės įrangos kūrimo įrankių kūrime, susijungimai ir įsigijimai. Šios priemonės suteikė reikalavimų valdymo ("RequisitePro"), bendrojo testavimo ("SQA"), našumo testavimo, konfigūracijos valdymo ir pakeitimų valdymo galimybes. 1998 metais Racionalus pakeičia produkto pavadinimą į RUP, kurio konceptualus branduolys išlieka Vieningas procesas.

Charakteristikos

Vieningas procesas remiantis naudojimo atvejų, apibūdinantis vieną ar daugiau veikėjų, kurie sąveikauja su sistema ir gauna proceso dalyviams vertingus rezultatus. Būtent naudojimo atvejai yra pagrindinė varomoji jėga, kuri skatina visą kūrimo procesą, pradedant reikalavimų rinkimu ir aptarimu, baigiant analize, projektavimu ir įgyvendinimu. Naudojimo atvejai aprašyti paprasta ir suprantama kalba, kad būtų suprantami pašaliniams skaitytojams.

Pagal Vieningas procesas, kūrimo proceso centre yra architektūra- pagrindinė visos sistemos organizacija. Tai gali apimti statinius ir dinaminius elementus, jų sąveiką ir leidžia išspręsti gaminio efektyvumo, išplečiamumo, elementų pakartotinio naudojimo klausimus bei padėti įveikti ekonominius ir techninius apribojimus. Projekto komanda kuo anksčiau pradeda dirbti su architektūros aprašymu, o kūrimo proceso metu jį nuolat plečia ir tobulina. Architektūra laikoma svarbiu aspektu Vieningas procesas dėl daugelio priežasčių, kurių svarbiausia yra galimybė matyti visą vykstantį vaizdą, teisingas kūrėjo pastangų pritaikymas, sudarytos palankesnės sąlygos pakartotinai naudoti komponentus, kurti sistemą ir teisingai parinkti naudojimo atvejus.

Trečiasis pagrindinis principas Vieningas procesas yra naudojimas pasikartojantis ir laipsniškas metodas. Iteracijos yra miniatiūriniai projektai, leidžiantys paleisti naujesnę sistemos versiją. Iteracijos rezultatas, sistemos pakeitimai, vadinamas prieaugiu. Visų pirma, iteracinis metodas leidžia nuosekliai tobulinti sistemos architektūrą, tvarkyti nuolatinius reikalavimų pokyčius ir lanksčiai koreguoti viso projekto planą. Įsipareigojimas laikytis nuolatinės integracijos principo leidžia ankstyvoje stadijoje nustatyti galimas problemas. Be to, iteracija padeda sumažinti riziką, susijusią su techniniais apribojimais, architektūra ir besikeičiančiais reikalavimais.

Vystymo etapai

Santykinis tipinio projekto kūrimo etapų dydis

Kiekvienas plėtros ciklas, pagal Vieningas procesas, susideda iš keturių etapų, kurie atspindi laikotarpį tarp svarbių projekto etapų, leidžiančių vadovams priimti svarbius sprendimus dėl plėtros proceso tęstinumo, darbų apimties, biudžeto ir grafiko.

Darbo eigos veislės

Viduje Vieningas procesas Kiekviename kūrimo etape yra penki darbo procesų tipai: reikalavimai, analizė, projektavimas, įgyvendinimas ir testavimas.

Kiekvienas procesas – tai veiklų, kurias atlieka skirtingi projekto komandos nariai, visuma. Taigi reikalavimų rinkimo procesų tikslas – sukurti naudojimo atvejų modelį, leidžiantį nustatyti pagrindinius sistemos funkcinius reikalavimus. Analizės procesai ir atitinkamas modelis leidžia kūrėjams struktūrizuoti funkcinius reikalavimus; Projektavimo procesas apibūdina fizinį naudojimo atvejų įgyvendinimą ir yra šio modelio abstrakcija. Diegimo procesas ir modelis aprašo, kaip dizaino elementai yra susiję su programinės įrangos komponentais, įskaitant šaltinio kodą, dinamines bibliotekas ir kt. Paskutinis modelis, kuriame aprašomas testavimas, paaiškina, kokius sistemos testus ir vienetų testus reikia atlikti ir kaip juos turėtų atlikti kūrimo komanda.

Iteracijos ir prieaugiai

Kiekviena iš Unified Procese aprašytų fazių susideda iš iteracijos, kurie yra ribotos trukmės miniatiūriniai subprojektai. Paprastai kiekviena iteracija skirtingu laipsniu apima visus penkis darbo eigos elementus. Iteracijos rezultatas yra prieaugis, leidimas, kuriame yra patobulinimų, palyginti su ankstesne produkto versija.

Racionalus vieningas procesas(RUP) yra programinės įrangos kūrimo technologijų sistema, kurią sukūrė ir parduoda Rational Software. Ji apima pasaulinę geriausią programinės įrangos kūrimo praktiką ir suteikia disciplininį požiūrį į programinės įrangos kūrimo organizacijos užduočių ir atsakomybės paskirstymą ir valdymą. Taikydamos šį procesą, programinės įrangos kūrimo komandos galės sukurti aukštos kokybės programinę įrangą, atitinkančią galutinių vartotojų poreikius, ir tai padaryti neperžengdamos nuspėjamo grafiko ir biudžeto.

RUP padeda programinės įrangos specialistams efektyviai taikyti dabartinę geriausią praktiką, pvz pasikartojantis vystymasis, taikymas į architektūrą orientuotas požiūris, naudojimo atvejai, rizikos mažinimas visuose proceso etapuose ir nuolatinis programos tikrinimas.

Racionalus vieningas procesas yra pagrįstas keliais pagrindiniais principais, surinktais iš daugelio sėkmingų projektų:

· Pradėkite atakuoti pagrindines rizikas anksčiau ir vykdykite tai nuolat, kitaip jie patys imsis puolimo prieš jus.

· Užtikrinti, kad būtų patenkinti klientų reikalavimai.

· Susikoncentruokite į vykdomą programą.

· Prisitaikykite prie pokyčių nuo pat projekto pradžios.

· Anksti sukurti vykdomąją architektūrą.

· Sukurti sistemą iš komponentų.

· Dirbti kartu kaip komanda.

· Kokybę paverskite gyvenimo būdu, o ne paskubomis.

RUP naudoja pasikartojantis požiūris Kiekviena iteracija atlieka tam tikrą reikalavimų darbą, analizę, projektavimą, įgyvendinimą ir testavimą. Kiekviena iteracija grindžiama ankstesnių iteracijų rezultatais ir sukuria vykdomąją programą, kuri vienu žingsniu priartėja prie galutinio produkto.

RUP suteikia struktūrinis požiūris į kartotinį vystymąsi, padalijant projektą į keturis etapus: pradžią, projektavimą, statybą ir įgyvendinimą. Kiekvieną fazę lydi vadinamasis etapas, proceso kontrolinis taškas, kuriame tikrinama, kaip pasiekti kito etapo tikslai, ir sprendžiama dėl perėjimo (ar ne) į kitą etapą. Taigi kiekvienas iš keturių RUP etapų turi etapą ir aiškiai apibrėžtus tikslus. Šie tikslai naudojami norint nustatyti, kokias užduotis atlikti ir kokius artefaktus sukurti. Kiekviena fazė griežtai sutelkia dėmesį į tai, kas būtina tik etapo verslo tikslams pasiekti.

Visi proceso elementai - vaidmenys, užduotys, artefaktai ir susiję koncepcijos, vadovai ir šablonai sugrupuoti į loginius konteinerius, vadinamus Drausmės(Disciplinos). Standartiniame RUP gaminyje yra tik devynios disciplinos. Tai apima: verslo modeliavimą, reikalavimų valdymą, projektų valdymą, pokyčių valdymą ir aplinką.

Kiekviena proceso eiga: reikalavimų rinkimas, analizė, projektavimas, įgyvendinimas ir testavimas apibrėžia susijusių artefaktų ir veiklų rinkinį. Prisiminkite, kad artefaktas yra dokumentas, ataskaita, vykdomasis elementas ir kt. Artefaktas gali būti gaminamas, perdirbamas ar vartojamas.

Modelis– svarbiausias artefakto tipas. Pateikiami devyni modeliai, kartu apimantys visus programinės įrangos sistemų vizualizavimo, specifikavimo, projektavimo ir dokumentavimo sprendimus:

· verslo modelis. Apibrėžia organizacijos, kuriai kuriama sistema, abstrakciją;

· domeno modelis. Fiksuoja sistemos kontekstinę aplinką;

· Modelio naudojimo atvejis. Apibrėžia funkcinius sistemos reikalavimus.

· analizės modelis. Aiškina sistemos reikalavimus projektavimo modelio požiūriu;

· dizaino modelis. Apibrėžia problemos ir jos sprendimo srities žodyną;

· išdėstymo modelis. Apibrėžia aparatinės įrangos topologiją, kurioje veikia sistema;

· įgyvendinimo modelis. Apibrėžia dalis, kurios naudojamos fizinei sistemai surinkti ir įdiegti;

· bandomasis modelis. Apibrėžia bandomuosius atvejus, kad patikrintų sistemą;

· proceso modelis. Apibrėžia lygiagretumą sistemoje ir sinchronizacijos mechanizmus.

Techniniai artefaktai yra suskirstyti į keturis pagrindinius rinkinius:

· reikalavimų rinkinys. Apibūdina Ką sistema turėtų tai padaryti;

· dizaino rinkinys.

· įgyvendinimų rinkinys. Apibūdina sukurtų programinės įrangos komponentų surinkimą;

· išdėstymo rinkinys. Pateikiama visa informacija apie pateiktą konfigūraciją.

Reikalavimų rinkinys gali apimti naudojimo atvejo modelį, nefunkcinių reikalavimų modelį, domeno modelį, analizės modelį ir kitas vartotojo poreikių išreiškimo formas.

Dizaino rinkinys gali apimti projektavimo modelį, bandomąjį modelį ir kitas sistemos esmės išraiškos formas.

Įgyvendinimų rinkinys sugrupuoja visus duomenis apie programinės įrangos elementus, kurie sudaro sistemą (programos kodas, konfigūracijos failai, duomenų failai, programinės įrangos komponentai, sistemos surinkimo informacija).

Įdėjimo rinkinys sugrupuoja visą informaciją apie pakavimą, siuntimą, montavimą ir sistemos paleidimą.

Kiekvienas technologinis procesas yra lydimas rizika. Kuriant programinės įrangos produktą, nepatenkinamas rezultatas (JT) gali būti: biudžeto viršijimas, mažas patikimumas, netinkamas veikimas ir kt. Rizikos įtaka apskaičiuojama naudojant išraišką

Rizikos rodiklis = tikimybė (LP) * Nuostolis (LP).

Rizikos valdymas apima šešis veiksmus:

1. Rizikos identifikavimas – rizikos elementų nustatymas projekte.

2. Rizikos analizė – kiekvieno rizikos elemento nuostolių tikimybės ir dydžio įvertinimas.

3. Rizikos reitingavimas – rizikos elementų rikiavimas pagal jų įtakos laipsnį.

4. Rizikos valdymo planavimas – pasiruošimas susidoroti su kiekvienu rizikos elementu.

5. Rizikos sprendimas – rizikos elementų pašalinimas arba išsprendimas.

6. Rizikos stebėjimas – rizikos elementų dinamikos sekimas, korekcinių veiksmų atlikimas.

Pirmieji trys veiksmai priklauso rizikos vertinimo etapui, paskutiniai trys – rizikos kontrolės etapui.

Yra trys rizikos šaltinių kategorijos: projekto rizika, techninė rizika ir komercinė rizika. Nustačius rizikos elementus, reikėtų kiekybiškai įvertinti jų poveikį programinės įrangos projektui ir išspręsti klausimus dėl galimų nuostolių. Šios problemos sprendžiamos rizikos analizės etape. Ir galiausiai kiekvieno rizikos elemento valdymo planas, tai yra kiekvieno rizikos elemento valdymo funkcijų rinkinys, yra integruotas į bendrą programinės įrangos projekto planą.