Ühtne protsess - see on tarkvara loomise protsessi üldine raamistik, mis võib olla. spetsialiseerunud paljudele tarkvarasüsteemidele. Tarkvarasüsteemi mudeli väljatöötamiseks kasutab ühtne protsess ühtlast modelleerimiskeelt.

alustage rünnakut peamiste riskide suhtes, juhtige seda pidevalt, vastasel juhul lähevad riskid teie peale solvavaks.

veenduge, et kliendi nõuded oleksid täidetud: dokumendinõuded kliendile arusaadaval viisil ning järgige neid nõudeid rangelt projekteerimisel ja rakendamisel

keskenduge käivitatavale programmile: töötav tarkvaratoode, mis läbib testid, on parem kui põhjalik dokumentatsioon

kohaneda muudatustega juba projekti alguses: kaasaegsed rakendused on piisavalt keerulised, et saaksime konkreetsed nõuded juba arenduse alguses. Seetõttu on vaja PCB arhitektuuri panna nii, et see oleks muutustele vastuvõtlik.

pange käivitatava arhitektuuri alus võimalikult varakult. Käivitatav arhitektuur on võtmekasutusjuhud. VI võti on süsteemi funktsionaalsus, ilma milleta pole tarkvaral mõtet. Võti. VI moodustab kõigist variantidest 7–10%

ehitada komponentidest süsteem. Komponendipõhised rakendused on kiiremad, muudatuste osas paindlikumad, suhteliselt madalad.

töötada ühe meeskonnana

muuta kvaliteet eluviisiks, mitte tagantjärele

6 Ühtse protsessi elutsükkel. Iga etapi eesmärgid.

Ühtne protsess kordub tsükliliselt. See ühendatud protsessi korduste jada tähistab süsteemi elutsüklit. Iga tsükkel lõpeb toote väljaandmisega klientidele.

Iga tsükkel koosneb neljast etapist - nõuete analüüs ja planeerimine, projekteerimine, ehitamine ja rakendamine. Iga faas, nagu allpool arutletud, jaguneb veel kordusteks.

Ajal analüüsi ja planeerimise etapid nõuded hea mõte muutub valmistoote kontseptsiooniks ja luuakse selle toote arendamiseks äriplaan. Eelkõige tuleks selles etapis saada vastused küsimustele:

Mida peaks süsteem tegema peamiselt oma peamiste kasutajate jaoks?

Kuidas peaks süsteemi arhitektuur välja nägema?

Mis on plaan ja mis maksab tootearendus?

Selles etapis luuakse prooviarhitektuur. Tavaliselt on see visand, mis sisaldab kõige olulisemaid alamsüsteeme. Selles etapis selgitatakse välja ja tähtsustatakse kõige olulisemad riskid, kavandatakse üksikasjalikult projekteerimisetapp ja hinnatakse ligikaudselt kogu projekti.

Ajal projekteerimisetapid enamikku kasutusjuhtumeid kirjeldatakse üksikasjalikult ja süsteemi arhitektuur on välja töötatud.

Projekteerimisetapi lõpus vastutab tegevuste kavandamise ja projekti lõpuleviimiseks vajalike ressursside arvutamise eest projektijuht. Põhiküsimus on siinkohal järgmine: kas kasutusjuhtumid, arhitektuur ja plaan on hästi välja töötatud ja kas riskid on kontrolli all piisavalt, et kogu arendustöö lepinguliselt lõpule viia?

Ajal ehitusetapid toode luuakse - luustikule lisatakse lihased (arhitektuur) (täielikud programmid). Selles faasis kasvab baasarhitektuur täielikult välja töötatud süsteemiks. Mõisted arenevad tooteks, mis on kasutajatele üleandmiseks valmis. Faasi ajal suureneb vajalike ressursside hulk. Selle etapi lõpus sisaldab toode kõiki kasutusjuhtumeid, mille juhtkond ja klient on kokku leppinud praeguses versioonis. Tõsi, need võivad sisaldada vigu. Enamik defekte avastatakse ja kõrvaldatakse rakendamise etapis. Etapi lõpus on põhiküsimus järgmine: kas toode vastab kasutaja nõudmistele, nii et mõnda klienti saab eelnevalt välja saata?

Rakendusetapp hõlmab perioodi, mille jooksul toode eksisteerib beeta- või beetaversioonina. Väike hulk kvalifitseeritud kasutajaid, kes töötavad toote beetaversiooniga, teatavad avastatud defektidest ja puudustest. Seejärel parandavad arendajad avastatud vead ja lisavad mõned väljapakutud täiustused peamisele väljaandele, mida valmistatakse ette laialdaseks levitamiseks. Rakendusetapp hõlmab selliseid tegevusi nagu tiraaži tootmine, kliendi töötajate koolitamine, vihjeliinide tugiteenuste korraldamine ja pärast kohaletoimetamist avastatud defektide kõrvaldamine.

Ratsionaalne ühtne protsess (RUP) on üks parimaid arendusmetoodikaid tarkvaraloodud Rational Software poolt. Tuginedes paljude edukate tarkvaraprojektide kogemustele, võimaldab ühtne protsess luua keerukaid tarkvarasüsteeme, mis põhinevad tööstuse arendusmeetoditel. RUP-i üks põhisambaid on mudelite loomine, kasutades ühtlast modelleerimiskeelt (UML). See artikkel käsitleb UML-diagrammide rakendamist Rational Software Development töövoole.

Pole saladus, et tarkvara loomine on keeruline protsess, millel on ühelt poolt palju pistmist loovusega, ja teiselt poolt, kuigi see on väga kasumlik, on see ka kulukas äri. Tihe konkurents turul sunnib arendajaid rohkem otsima tõhusad meetodid töö. Luues tarkvarasüsteeme veelgi enam lühike aeg, väiksemate kulude ja parema kvaliteediga. Programmide keerukus kasvab pidevalt. Kuni viimase ajani võisid tarkvaratooteid lähitulevikus luua üksikisikud või näiteks automatiseeritud ettevõtte IT-osakonnas.

Nüüd jäävad üksikutele, kes loovad "põlvili" programme, väikeste utiliitide ala ja mitmesugused "raskete" tarkvaratoodete laiendusmoodulid. Tulevik kuulub tööstuslikule lähenemisele tarkvaraarenduses. 1913. aastal käivitas Henry Ford esimese autokonveieri ja 90ndatel kasutati sarnast konveierit ka IT-tehnoloogiate valdkonnas. Meeskonna arendamine nõuab hoopis teistsugust lähenemist ja teistsugust metoodikat, mis varem või hiljem tuli luua.

Rational Software Corporation (http: // www .rational .com) on loonud struktureeritud teadmusbaasi nimega Rational Unified Process (RUP), mis on põhjalik juhiste kogum praktiliselt iga tarkvaratoote loomiseks. Parimate arenduste kogemuste põhjal on RUP üksikasjalikult öelnud, millal, keda ja mida tuleks projektis teha, et tarkvarasüsteem õigeaegselt, kindla funktsionaalsusega ja eraldatud eelarve piires saada.

Ühtset protsessi võib pidada summaks erinevad tüübid arendajaettevõtte tegevus, mis on vajalik klientide nõuete muutmiseks tarkvarasüsteemi. Süsteem, mis pakub kasutajatele "sisukaid tulemusi" ja teeb täpselt seda, mida nad süsteemist ootavad. Seetõttu juhivad protsessi süsteemi kasutamise juhtumid või muul viisil - pretsedendid.

Kliendi nõuete õigeaegseks rakendamiseks jagatakse ühtne protsess faasideks, mis koosnevad iteratsioonidest, seetõttu nimetatakse protsessi ka iteratiivseks ja inkrementaalseks. Iga iteratsioon läbib põhitöö tsükli ja viib arendajad lõppeesmärgi juurde: tarkvarasüsteemi loomiseni. Korduste käigus luuakse projekti edukaks lõpuleviimiseks vajalikud vaheartefaktid ja tarkvarasüsteemi versioon, mis rakendab teatud funktsioonide komplekti, mis suureneb iteratsioonist iteratsioonini. Protsessi faasid ja peamised töövood on näidatud joonisel fig. 1 on toodud ka faaside ligikaudsed tööjõukulud.

joon. 1 RUP-faasid ja töövood

Tuleb märkida, et joonisel fig. 1 näitab ainult ühendatud protsessi põhitegevusi. Näiteks ei kuvata siin skeemi risustamise vältimiseks tegevuste haldamise tegevusi.

Kogu tarkvaraarendust vaadeldakse RUP-is kui artefaktide loomise protsessi. Kõik projekti töö tulemused, olgu need siis lähtekoodid, objektimoodulid, kasutajale edastatud dokumendid, mudelid on kõigi projekti artefaktide alaklassid. Iga projektimeeskonna liige loob oma esemed ja vastutab nende eest. Programmeerija loob programmi, juht projektiplaani ja analüütik süsteemimudelid. RUP võimaldab teil määratleda, millal, kelle poolt ja milline artefakt tuleb luua, muuta või kasutada.

Projektide artefaktide üks huvitavamaid klasse on mudelid, mis võimaldavad arendajatel tarkvarasüsteemi artefakte määratleda, visualiseerida, kujundada ja dokumenteerida. Iga mudel on iseseisev vaade arendatavale süsteemile ja on mõeldud nii probleemide piiritlemiseks kui ka lahenduste pakkumiseks. Mudelite iseseisvus tähendab, et analüütik või arendaja saab kogu vajamineva teabe konkreetselt mudelilt ilma muudest allikatest kasutamata.

Mudelid võimaldavad teil arvestada tulevase süsteemi, selle objektide ja nende koostoimega juba enne märkimisväärsete rahaliste vahendite arendusse investeerimist, võimaldavad seda näha juba tulevaste väliste kasutajate ja seestpoolt arendajate pilgu kaudu juba enne lähtekoodi esimese rea loomist. Enamikku mudeleid esindavad UML-diagrammid, UML-i kohta saate rohkem lugeda näiteks.

Ühtne modelleerimiskeel tekkis 1980. aastate lõpus ja 1990. aastate alguses, peamiselt tänu Grady Boochi, Jim Rambeau ja Ivar Jacobsoni "kolme sõbra" pingutustele. OMG on nüüd selle keele kasutusele võtnud standardse modelleerimiskeelena, mis annab arendajatele selge märke kuvada mudeleid graafiliste elementidena, mis on üldiselt aktsepteeritud ja arusaadavad kõigile projekti liikmetele.

Siiski ei tohiks unustada, et modelleerimiskeel pakub ainult märke - tööriista süsteemi kirjeldamiseks ja modelleerimiseks ning ühtne protsess määrab selle tööriista kasutamise metoodika, samuti muud tööriistad Rationali metoodika toetamiseks. UML-i saab kasutada ilma kindla metoodikata, kuna see on protsessist sõltumatu ja kumb protsessivarianti rakendatakse, saate diagrammide abil dokumenteerida arendamise käigus tehtud otsuseid ja kuvada loodud mudeleid.

Tarkvarasüsteem on loodud konkreetsete kasutajaprobleemide lahendamiseks, mitte aga programmeerijate uute tehnoloogiate katsetamiseks ja projektijuhi kogemuste saamiseks. Üldiselt pole kasutajal vahet, kas kasutate arendusprotsessis objektorienteeritud lähenemist, UML-i, RUP-i või loote süsteemi XP (extreme programmeerimine) meetodil. Teatud meetodite, tehnoloogiate kasutamine, projekti optimaalse sisestruktuuri loomine jääb arendajate südametunnistusele, kes teevad otsuseid varasema kogemuse ja oma eelistuste põhjal. Kuid kasutaja ei andesta teile, kui ignoreerite tema nõudeid. Kas tarkvarasüsteem on välja töötatud vähemalt kümme korda, kasutades tipptehnoloogilisi meetodeid ja tehnoloogiaid, kui kasutaja ei saa sellest nn märkimisväärset tulemust, kukub teie tarkvaraprojekt haledalt läbi.

Sellest järeldub, et UMLi mõtlematu kasutamine lihtsalt sellepärast, et see on moes, ei too mitte ainult kaasa edu arendamisele, vaid võib põhjustada ka rahulolematust töötajate seas, kes peavad uurima suurt hulka täiendavat kirjandust, ja projektijuhte, kui selgub, et projekti tööjõukulud suurenevad. ja tootlus ei suurene. Peate olema selge, mida soovite selle tehnoloogia rakendamisel saada, ja järgige seda eesmärki. UML-i kasutamine säästab arendusressursse, sest see võimaldab teil süsteemist ettekujutuse saada kiiremini kui makettide ja prototüüpide loomine, kulutades võrreldamatult vähem ressursse.

Diagrammid hõlbustavad projekti liikmete omavahelist suhtlemist ja mis on eriti väärtuslik, kaasavad protsessi süsteemi lõppkasutajad. Modelleerimine võimaldab teil vähendada projekti riske, kuna programmeerijatel on alati lihtsam teha seda, mis on selge ja arusaadav, kui minna ebakindla tulemuseni. Diagrammide koostamine sarnaneb ehituses projekti loomisega - ilma selleta saab ka näiteks suvilasse kuuri ehitades, aga mida suurem on hoone (meie puhul tarkvaratoode), seda keerulisem on seda teha ja seda ebakindlam on lõpptulemus.

Õpetasin kunagi tarkvarafirmas RUP-seminari, mis on kümme aastat turul üsna edukalt tegutsenud, kuid ei kasuta oma töövoos modelleerimist, vaid põhineb prototüüpidel. Umbes kakskümmend noort ja kogenud programmeerijat kogunesid saali ja kuulasid hoolikalt kõike, mida ma neile RUP-i ja UML-i kohta rääkisin. Ja üks neist, vaadates skeemide näidetega tähistatud tahvlit, märkis: "See kõik on huvitav ja sobib tõenäoliselt ka teiste projektide jaoks," ütles ta, "kuid me oleme ilma selleta pikka aega töötanud, kuna oleme endiselt saime läbi ilma UMLita, ilmselt pole seda lihtsalt vaja. "

See küsimus pani mind mõtlema, et äriprotsesside muutus, mis peab tarkvarafirmas paratamatult toimuma RUP-i ja UML-i juurutamisel, võib olla sama keeruline kui infosüsteemi juurutamine tööstusettevõttes. Iga rakendamine on stereotüüpide murdmine. Kuna tarkvaraarendusettevõttes on töötajate kvalifikatsioon üsna kõrge, on sellistel inimestel raskem oma seisukohtadest loobuda kui "pelgalt surelikel" ning tekkivaid raskusi ja tagasilükkamist saab võrrelda üleminekuga protseduuriliselt mõtlemiselt objektiivsele mõtlemisele.

1. Nõuete määratlemine

Ühtne protsess on kasutusjuhtumipõhine protsess, mis haarab kasutaja interaktsiooni stsenaariume. Tegelikult on see kasutaja vaade tarkvarasüsteemile väljastpoolt. Seega saab RUPi sõnul üheks olulisemaks arenguetapiks nõuete kindlaksmääramise etapp, mis seisneb kõigi võimalike soovide kogumises süsteemi toimimiseks, mis võivad tekkida ainult kasutajatele ja analüütikutele. Hiljem tuleb need andmed süstematiseerida ja struktureerida, kuid praeguses etapis peavad kasutajate intervjuude ja dokumentide uurimise ajal analüütikud koguma tulevase süsteemi jaoks võimalikult palju nõudeid, mis pole nii lihtne, kui esmapilgul tundub. Kasutajatel pole sageli aimugi, mida nad lõpuks peaksid saama. Selle protsessi hõlbustamiseks kasutavad analüütikud juhtumiskeeme (joonis 2)

joonis 2. Kasutusjuhtumi skeemi näide

Diagramm kajastab süsteemiga suhtlevaid osalejaid (näitlejaid) ja tarkvaraobjektide reaktsiooni nende tegevusele. Näitlejad võivad olla nii kasutajad kui ka välised agendid, kellel on vaja teavet edastada või vastu võtta. Kasutusjuhtumi ikoon peegeldab süsteemi reageerimist välisele stiimulile ja näitab, mida tuleb aktandi jaoks teha.

Konkreetse kasutusjuhtumi kirjeldamiseks kasutatakse tegevuste skeemi, mille näide on toodud joonisel 3.

joon. 3 Näide tegevuse diagrammist

Kasutusjuhtumi skeemi lihtsus võimaldab analüütikutel nõuete määratlemisel klientidega hõlpsalt suhelda, tuvastada süsteemile ja üksikute nõuete täitmisele seatud piirangud, näiteks süsteemi reageerimisaeg, mis hiljem jaguneb mittetoimivate nõuete jaotisse.

Kasutamisjuhtude skeemi saab kasutada ka teststsenaariumide loomiseks, kuna kogu kasutaja ja süsteemi interaktsioon on juba määratletud.

Nõuete õigeks määratlemiseks peavad arendajad mõistma konteksti (domeeni osa), milles tulevane süsteem töötab. Selleks luuakse domeenimudel ja ärimudel, mis on samale küsimusele erinevad lähenemised. Sageli luuakse üks asi: domeenimudel või ärimudel.

Nende mudelite erinevus seisneb selles, et domeenimudel kirjeldab olulisi mõisteid, millega süsteem töötab, ja nende suhteid omavahel. Ärimudel kirjeldab äriprotsesse (olemasolevaid või tulevasi), mida süsteem peab toetama. Seetõttu määratleb see mudel lisaks protsessis osalevate äriobjektide määratlemisele ka töötajad, nende kohustused ja tegevused, mida nad peavad tegema.

Domeenimudeli loomiseks kasutatakse tavalist klassiskeemi (joonis 6), kuid ärimudeli loomiseks sellest selgelt ei piisa. Sel juhul rakendatakse kasutusjuhtude skeemi, kasutades täiendavaid ikoone, mis kajastavad äriprotsesside olemust - äriaktant, ärikasutusjuhtum, äriüksus ja ärijuhtimine. See mudel on palju lähemal järgmisele arenduse käigus loodud mudelile - analüüsimudelile.

2. Analüüs

Pärast nõuete ja süsteemi toimimise konteksti määratlemist on aeg saadud andmeid analüüsida. Analüüsi käigus luuakse analüütiline mudel, mis viib arendajad tulevase süsteemi arhitektuurini. Analüütiline mudel on pilk süsteemile seestpoolt, erinevalt kasutusjuhtumismudelist, mis näitab, kuidas süsteem väljastpoolt välja näeb.

See mudel võimaldab teil mõista, kuidas süsteem peaks olema kavandatud, millised klassid selles peaksid olema ja kuidas nad peaksid üksteisega suhtlema. Selle peamine eesmärk on määrata kindlaks nõuete kogumise etapis tuvastatud funktsionaalsuse rakendamise suund ja teha visand süsteemi arhitektuurist.

Erinevalt hiljem loodavast disainimudelist on analüüsimudel pigem kontseptuaalne mudel ja viib arendajad rakendusklassidele lähemale. Sellel mudelil ei tohiks olla võimalikke vastuolusid, mis võivad esineda kasutusjuhtumudelis.

UML-i kasutava analüüsimudeli kuvamiseks kasutatakse klasside skeemi stereotüüpidega (käitumismustrid) "piiriklass", "üksus", "kontroll" ja üksikasjalikumalt kasutatakse koostööskeeme (Collaboration) (joonis 4). Stereotüüp "piiriklass" kuvab klassi, mis suhtleb väliste aktantidega, "olem" - kuvab klassid, mis on andmekogud, ja "haldus" - klassid, mis haldavad üksustele päringuid.

joonis 4. Koostööskeemi näide

Sõnumite numeratsioon näitab nende järjekorda, kuid skeemi eesmärk pole näidata sõnumite vahetamise järjekorda, vaid visuaalselt näidata klasside suhet üksteisega.

Kui keskendume interaktsiooni järjekorrale, siis on selle teine \u200b\u200besitus joonisel 5 näidatud järjestusdiagramm (järjestus). See skeem võimaldab teil vaadata sõnumite vahetust ajas, visuaalselt kuvada protsessi jada. Tööriista kasutamisel selliste mudelite loomiseks nagu Rational Rose, saab neid kahte tüüpi diagramme üksteisest automaatselt luua (Rational Rose'i kohta leiate lisateavet näiteks aadressilt).

Joonis: 5 Näidisjärjestuse skeem

Otsus selle kohta, kumb kahest diagrammist kõigepealt luua, sõltub konkreetse arendaja eelistustest. Kuna need diagrammid peegeldavad sama protsessi, võimaldavad mõlemad kajastada objektide vastastikust mõju.

3. Kujundus

Järgmine etapp süsteemi loomise protsessis on disain, mille käigus luuakse varem loodud mudelite põhjal kujundusmudel. See mudel kajastab süsteemi füüsilist rakendamist ja kirjeldab loodavat toodet klasside ja komponentide tasandil. Erinevalt analüüsimudelist sõltub disainimudel otsesõnu rakendamistingimustest, kasutatud programmeerimiskeeltest ja komponentidest. Süsteemi arhitektuuri kõige täpsemaks mõistmiseks tuleks see mudel võimalikult palju vormistada ja ajakohastada kogu süsteemi arendamise elutsükli vältel.

Kujundusmudeli loomiseks kasutatakse tervet UML-diagrammide komplekti: klasside skeemid (joonis 5), koostööskeemid, interaktsioonidiagrammid ja tegevusdiagrammid.

joonis 6. Klassiskeemi näide

Lisaks võib see töövoog luua juurutusdiagrammil põhineva juurutusmudeli. See on lihtsaim skeemitüüp seadmete jaotuse võrgus simuleerimiseks. Kuvamiseks kasutatakse ainult kahte protsessori ja seadme ikooni versiooni koos nende vaheliste ühendustega.

4. Rakendamine

Rakendusprotsessi peamine ülesanne on luua süsteem komponentide kujul - programmide lähtekoodid, skriptid, binaarkaardid, käivitatavad moodulid jne. Selles etapis luuakse rakendusmudel, mis kirjeldab, kuidas kujundusmudeli elemente rakendatakse, millised klassid lisatakse konkreetsetesse komponentidesse. See mudel kirjeldab nende komponentide korraldamise viisi vastavalt valitud programmeerimiskeskkonnas vastuvõetud struktureerimise ja mooduliteks jaotamise mehhanismidele ning seda esindab komponentide skeem (joonis 7).

joon. 7 Komponentskeemi näide

5. Testimine

Testimisprotsess kontrollib rakendamise tulemusi. Selle protsessi jaoks luuakse testimismudel, mis koosneb testjuhtumitest, testimisprotseduuridest, testikomponentidest, kuid millel pole UML-diagrammiga vastendamist, seega me ei peatu sellel.

6. Järeldus

Siin on käsitletud ainult ratsionaalse metoodika põhiprotsesse. RUP on üsna ulatuslik ja pakub juhiseid erinevate tarkvaraprojektide haldamiseks alates programmide loomisest mitme inimese arendajate meeskonna poolt kuni hajutatud tarkvaraprojektideni, mis ühendavad tuhandeid inimesi erinevatel mandritel. Vaatamata nende kolossaalsele erinevusele on UML-iga loodud mudelite rakendamise meetodid samad. Erinevates arenguetappides loodud UML-diagrammid on tarkvara projekti ülejäänud artefaktidest lahutamatud ja on sageli ühenduslüliks üksikute RUP-protsesside vahel.

Konkreetsete skeemide kasutamise otsus sõltub ettevõtte arenguprotsessist, mis, ehkki seda nimetatakse ühtseks, pole siiski midagi külmutatud. Rational pakub mitte ainult selle täiustamist ja täpsustamist, vaid pakub ka spetsiaalseid tööriistu RUP-i andmebaasi muudatuste tegemiseks.

Kuid igal juhul võimaldab UML-i kasutamine koos ühtse protsessiga saada prognoositavat tulemust, hoida ettenähtud eelarve piires, suurendada projektis osalejate tasuvust ja loodud tarkvaratoote kvaliteeti.

Krachten. F. Sissejuhatus Ratsionaalne ühtne protsess . Ed. 2 - e. - M.: Kirjastus "Williams", 2002. - 240 lk: ill.

Jacobson A., Booch G., Rambeau J. ühtne tarkvaraarendusprotsess - Peterburi: Peter, 2002. - 496 lk: ill.

Fowler M., Scott K. UML kokkuvõttes. Objektide modelleerimise standardkeele rakendamine: Per. inglise keelest. - M .: Mir, 1999. - 191 lk., Ill.

Beck. E. Äärmuslik programmeerimine. - SPb.: Peter, 2002. - 224 lk: ill.

Trofimov S. CASE tehnoloogiad: Praktiline töö aastal Rational Rose.
Ed. 2. - M.: Binom-Press, 2002 - 288 lk.

Ühtne protsess Ratsionaalne arendus (Rational Unified Process, RUP) on erinevate tegevuste summa, mis on vajalik kasutajate vajaduste muutmiseks tarkvarasüsteemiks. Selle abstraktne ja laiendatud kujutis on näidatud joonisel fig. 7.2.

RUP-i põhimõisted on artefakt ja pretsedent. Artefaktid on mõned projekti tooted, mis on loodud või kasutatud selles finaali kallal töötades tarkvaratoode. Pretsedendid või kasutamise juhtumid(kasutamise juhtum) ‑ need on toimingute jadad, mida tarkvarasüsteem teeb vaadeldava tulemuse saamiseks.

Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP as artefakti loomise protsess... Veelgi enam, see, mis jääb lõppkasutaja kätte, olgu see tarkvaramoodul või tarkvara dokumentatsioon, on kõigi projekti artefaktide üks alaklass.

Iga projektimeeskonna liige loob oma esemed ja vastutab nende eest. Programmeerija töötab välja programmi, juht projektiplaani ja analüütik süsteemimudelid. RUP võimaldab teil määrata, millal, kellele ja mis artefakt tuleb luua.

(ja)

Joonis: 7.2.Ühtne tarkvaraarendusprotsess ( ja- abstraktne esitus, b - üksikasjalik ülevaade peamistest RUP-protsessidest)

Kuid RUP on rohkem kui üks protsess, see on üldine protsessiraamistik, mis võib olla spetsialiseerunud väga erinevatele tarkvarasüsteemidele, erinevatele rakendusvaldkondadele, oskuste tasemele ja projekti suurusele. RUP - komponentidele orienteeritud.See tähendab, et loodud tarkvarasüsteem on üles ehitatud tarkvarakomponentide baasil, mis on ühendatud täpselt määratletud liideste abil.

Tarkvarasüsteemi graafiliste esituste (mudelite) väljatöötamiseks kasutab RUP Ühtne modelleerimiskeel(UML) . Tegelikult on UML RUP-i lahutamatu osa - need töötati välja koos.

Kuid RUP-protsessi tõeliselt spetsiifilised aspektid on kolmes fraasis - kasutamise juhtum, arhitektuurile orienteeritud, korduv ja inkrementaalne... See muudab Unified Process ainulaadseks.

Tarkvarasüsteemi täielik esitus RUP-is sisaldab üheksat mudelit, mis hõlmavad üheskoos kõiki kriitilisi otsuseid seoses tarkvarasüsteemi visualiseerimise, spetsifikatsiooni, kujunduse ja dokumenteerimisega (joonis 7.3):

1. äriprotsessi mudel, mis vormistab organisatsiooni abstraktsiooni (koos kõigi juhtimissüsteemi kasutamise võimalustega ja nende seostega kasutajatega);

2. kasutage juhtumimudelit - vormistab süsteemi funktsionaalsed nõuded;

3. domeenimudel või ärimudelkirjeldades süsteemi konteksti.

4. analüüsimudel, millel on kaks eesmärki - selgitada kasutusjuhtumite üksikasju ja luua süsteemikäitumise esmane jaotus objektide komplekti suhtes, mis pakuvad erinevaid võimalusi käitumine;

5. protsessimudel (valikuline) - vormistab süsteemi paralleelsuse ja sünkroniseerimise mehhanismid;

6. kujundusmudelmis määratleb: ja) - süsteemi staatiline struktuur, nagu alamsüsteemid, klassid ja liidesed, ja b) - kasutamisjuhud rakendatud kujul ühistudalamsüsteemide, klasside ja liideste vahel;

7. rakendamise mudel, mis sisaldab komponente (mida pakub lähtekood) ja klasside paigutust komponentide kaupa;

8. kasutuselevõtu mudelmis määratleb füüsilised arvutid - võrgusõlmed ja nende sõlmede komponentide paigutuse;

9. testimismudelsee kirjeldab testjuhtumeid kasutusjuhtumite kinnitamiseks;

Joonis: 7.3. RUP-mudelid (vastavate UML-diagrammide kujul)
ja nende seosed,

Kõik need mudelid on omavahel seotud. Koos kirjeldavad nad tarkvarasüsteemi täielikult. Ühe mudeli elementidel on edasi ja tagasi suunamispiirangud, mis on korraldatud linkide abil teistele mudelitele (vt joonis 7.3). Näiteks võib kasutusjuhtumi (kasutamisjuhtumi mudelis) jälgida kasutusjuhtumi (disainimudelis) ja testjuhtumi (testmudelis) vastavale teostusele. Jälgimine hõlbustab mõistmist ja muudatuste tegemist. RUP-i arendusprotsessi käigus loodud UML-diagrammid pakuvad tarkvaratoote täielikku ülevaadet).

Põhirõhk RUP-is ei ole mitte dokumentide kui selliste ettevalmistamisel, vaid sellel modelleerimine arendatav süsteem. Mudelid aitavad välja tuua nii probleemi kui ka selle lahendamise viisid ning nende loomisel kasutatakse UML-keelt, mis on pikka aega muutunud keerukate süsteemide kirjeldamise de facto standardiks ja võimaldab arendajatel määratleda, visualiseerida, kujundada ja dokumenteerida igasuguse keerukusega tarkvarasüsteemide artefakte.

Unified Process (UP) on üldine rümpprotsess, mis võib olla spetsialiseerunud paljudele tarkvarasüsteemidele, erinevatele rakendusvaldkondadele, oskuste tasemele ja projekti suurusele.

Ühtne protsess komponentidele orienteeritud.See tähendab, et loodud tarkvarasüsteem on üles ehitatud tarkvara baasil komponendid, ühendatud täpselt määratletud liideste abil.

UP spetsiifilised aspektid seisnevad selle kolmes tunnuses:

● ajendatud kasutusjuhtumitest;

● on arhitektuurile orienteeritud;

● on korduv ja inkrementaalne .

Ühtne protsessi elutsükkel

UP elutsükkel on jaotatud tsükliteks, millest igaüks lõpeb toote väljalaskega. Iga arendustsükkel koosneb neljast etapist - nõuete analüüs ja planeerimine, projekteerimine, ehitamine, rakendamine. Iga faas jaguneb kordusteks.

UP sisaldab kaheksat töövoogu: viis peamist- nõuete määratlemine, analüüs, kavandamine, rakendamine, testimine ja kolm täiendavat (peamise toetamiseks) - konfiguratsioonihaldus ja nõuete muutmine, projektijuhtimine, keskkonnajuhtimine.

Töövoo struktuuri määratlemiseks peate kõigepealt kindlaks määrama, milline esinejate tüübidprotsessis osaleda. Siis määratud esemeidselle töövoo käigus looma igat tüüpi täitjad.

18. XP on protsess.

Äärmuslik programmeerimine (English Extreme Programming, XP) on üks paindlik tarkvaraarenduse metoodika. Metoodika autorid on Kent Beck, Ward Cunningham, Martin Fowler jt.

Kaksteist põhilist äärmist programmeerimistehnikat (vastavalt raamatu Esmane väljaanne selgitamisele) on võimalik rühmitada nelja rühma:

1. Lühike tsükkel tagasiside (Peen skaala tagasiside)

a. Testpõhine arendus

b. Planeerimise mäng

c. Klient on alati olemas (kogu meeskond, kohapealne klient)

d. Paaride programmeerimine

2. Pidev, mitte partiiprotsess

a. Pidev integratsioon

b. Refaktoreerimine (disaini täiustamine, refaktor)

c. Sagedased väikesed väljalasked

3. Kõigi ühine mõistmine

a. Lihtsus (lihtne disain)

b. Suhtlus

c. Austus

d. Kollektiivse koodi omandus või valitud kujundusmustrid (kollektiivsete mustrite omand)

e. Kodeerimise standard või kodeerimise tavad

4. Programmeerija sotsiaalkindlustus (programmeerija hoolekanne):

a. 40 tundi töönädal (Säästev tempo, nelikümmend tundi nädalas)

XP-s on protsess jaotatud kavandatud protsessidega võrreldes väga väikesteks sammudeks. See toob kaasa asjaolu, et esimesed sammud võivad kose mudeli iga sammu jaoks võtta mitu päeva või mitu kuud või isegi aastaid. Esiteks kirjutatakse arenduseesmärkide kirjeldamiseks automatiseeritud testid. Siis tuleb kodeerimine, mis lõpeb hetkel, kui kõik testid läbitakse, ja programmeerijad ei saa uute testidega välja tulla. Kujunduse teevad samad inimesed, kes koodi kirjutavad. (ainult viimane samm - seos kujunduse ja koodi vahel on ühine kõikidele kiiretele protsessidele). Lõpetamata, kuid toimivat süsteemi näidatakse kitsale kasutajate ringile (enamasti on need arendajad ise). Siinkohal hakkavad nad kirjutama katseid süsteemi järgmise tähtsaima osa jaoks.

19. ICONIX on protsess.

ICONIXi töötas välja Doug Rosenberg aadressil Tarkvara ICONIXICONIXi protsess põhineb kasutusjuhtumitel, kuid ei kannata paljusid selle puudusi. Selles protsessis kasutatakse ka UML-i modelleerimise keelt, kuid kasutatakse ainult UML-i põhilisi märke - see on 20% keelest. ICONIX-protsess põhineb neljal peamisel tarkvaraarenduse etapil, mis põhinevad kasutusjuhtumitel:

● domeeni modelleerimine;

● pretsedentide modelleerimine;

● nõuete sobivuse analüüs (kõigi funktsionaalsete nõuete täitmise kontrollimine);

● järjestusdiagrammide koostamine.

Protsessi peamised etapid on järgmised:

● Nõuete analüüs

● Eelprojekt

● Kujundus

● Rakendamine

Protsess põhineb minimaalse arvu mudelite loomisel, mis kajastavad tulevast süsteemi. Analüüsi etapis luuakse juhtumimudelid, kasutajaliidese mudel ja domeenüksuse mudel. Esialgsel projekteerimisetapil luuakse vastupidavuse skeem. See täiendab ka kasutusjuhtumi mudelit ja domeeni olemimudelit. Detailse projekteerimise etapis luuakse SequenceDiagram ja klassi diagramm. Rakendamise etapis genereeritakse lähtekood. Sellisel juhul on võimalik luua juurutamise skeem ja komponentide skeem. iga etapp lõpeb vastastikuse eksperthinnangu verstapostiga, kus loodud graafikuid tuleb kolleegidega arutada.

20. SCRUM on protsess.

Scrum on põhimõtete kogum, millele arendusprotsess on üles ehitatud, võimaldades jäigalt fikseeritud lühikese aja jooksul ( sprindid2 kuni 4 nädalat) pakkuda lõppkasutajale töötavat tarkvara koos uute funktsioonidega, mille jaoks määratakse kõige olulisem prioriteet. Tarkvara võimalused järgmises sprindis rakendamiseks määratakse kindlaks sprindi alguses planeerimise etapis ja neid ei saa kogu selle kestuse jooksul muuta. Samal ajal annab rangelt fikseeritud lühike sprindi kestus arenguprotsessile ennustatavuse ja paindlikkuse.

Peamised näitlejarollid Scrumis: ScrumMaster - see, kes juhatab Scrum ja tagab kõigi põhimõtete järgimise Scrum (roll ei tähenda muud kui filmi õiget käitumist Scrum-a, projektijuht on pigem a Toote omanik ja ei tohiks olla ScrumMaster);Toote omanik (Toote omanik) - isik, kes esindab tootes lõppkasutajate ja teiste sidusrühmade huve; ja ristfunktsionaalne Käsk (Scrumi meeskond), mis koosneb nii arendajatest kui ka testijatest, arhitektidest, analüütikutest jne (samas kui meeskonna suurus on ideaalis 7 ± 2 inimest). Meeskond on ainus arenduses täielikult kaasatud osaleja ja vastutab tulemuse eest tervikuna. Keegi peale meeskonna ei saa sprindi ajal arenguprotsessi segada.

Iga sprindi käigus luuakse tarkvara funktsionaalne kasv. Igas sprindis rakendatud võimekuste komplekt pärineb etapist, mida nimetatakse toote mahajäämus (töötaotluse dokumentatsioon), millel on täidetavate töönõuete taseme osas kõrgeim prioriteet. Töösoovid ( mahajäänud üksusedjooksul määratud sprindi planeerimise näpunäited (sprindi planeerimise koosolek) viiakse sprindietappi. Kogu selle koosoleku jooksul teavitab tooteomanik täidetavatest ülesannetest. Seejärel määrab meeskond, kui suure osa soovist nad suudavad täita, et järgmisel sprindil vajalikud osad täita. Sprindi ajal täidab meeskond kindla kindla ülesannete loetelu (nn. sprindi mahajäämus). Sel perioodil pole kellelgi õigust muuta töökohtade nõuete loetelu, mida tuleks mõista kui nõuete külmutamist ( nõuded) sprindi ajal.

Artefaktid

Toote mahajäämus on dokument, mis sisaldab funktsionaalsuse nõuete loetelu, mis on järjestatud prioriteedi järgi. Toote mahajäämus on loetelu sellest, mida tuleb rakendada. Selle loendi üksusi nimetatakse "lugudeks" ( kasutaja lugu) või mahajäämuse elemendid ( mahajäänud üksused). Toote mahajäämus on kõigile Scrumi protsessis osalejatele redigeerimiseks avatud.

Sissejuhatus

ratsionaalne ühtne protsess (Rational Unified Process) on tarkvara spiraalse arendamise metoodika. Metoodika on toetatud autor Rational Tarkvara, tootevärskendusi tehakse umbes kaks korda aastas. Aastal modelleeriva keelena ühine alus teadmised kasutavad ühtlast modelleerimise keelt (UML).

Iteratiivne tarkvaraarendus RUP-is hõlmab projekti jagamist mitmeks väikeseks projektiks, mis viiakse läbi järjestikku ning iga arenduse iteratsioon on selgelt määratletud iteratsiooni lõpus saavutatavate eesmärkide kogumi abil. Lõplik kordus eeldab, et iteratsiooni eesmärkide komplekt peab täpselt vastama toote kliendi määratud eesmärkide kogumile, see tähendab, et kõik nõuded peavad olema täidetud.

RUP on üsna hästi vormistatud ja kõige rohkem tähelepanu pööratakse projekti arendamise algfaasidele - analüüsile ja modelleerimisele. Seega on selle metoodika eesmärk vähendada riskide maandamist, avastades vigu varases arengujärgus. Tehnilisi riske (hinnatakse) hinnatakse ja seatakse esmatähtsaks arendustsükli alguses ning seejärel vaadatakse need läbi aja jooksul ja projekti arenguga järgnevate korduste käigus. Uued eesmärgid ilmuvad sõltuvalt nende riskide prioriteetidest. Väljalasked jaotatakse nii, et kõigepealt kõrvaldatakse kõige olulisemad riskid.

Protsess hõlmab mudelite arengut; arendustsükli iteratsioon on ainulaadselt seotud tarkvaramudeli konkreetse versiooniga. Kõik iteratsioonid (töövoog) sisaldavad tarkvara elutsükli haldamise elemente: analüüs ja disain (modelleerimine), juurutamine, integreerimine, testimine, juurutamine. Selles mõttes on RUP spiraalmudeli teostus, ehkki seda kujutatakse sageli graafikute tabelina. Allpool toome välja protsessi peamised komponendid.

Sest edukas protsess arendamiseks on vaja kolme komponenti (joonis 1): protsess, märge ja utiliitide komplekt. Protsess kirjeldab, mida me teeme, mis järjekorras ja kuidas; noodistamine on suhtlusvahend; utiliitide komplekt aitab protsessi automatiseerida ja hallata.

Joonis: 1. Edu kolmnurk

Kõik kolm komponenti on RUP-is esindatud. Vaatame kõigepealt tähistamise funktsioone, mis teevad järgmist:

Teostab protsessi "liimimise" ühtseks tervikuks;

On keeleline otsuste tegemise tööriist, mis pole lähtekoodi põhjal ilmne;

Pakub semantikat oluliste strateegiliste ja taktikaliste otsuste kaardistamiseks;

Annab vormi, mis on piisav mõtlemiseks ja seejärel otsuste vastuvõtmiseks ning tööriistad protsessi automatiseerimiseks, et vormistatud andmetega manipuleerida.

Tegelikult hõlmab noot tarkvaraarendust analüüsist toote juurutamiseni. Märge RUP-i puhul - UML on ametlik keelevahend protsessi kirjeldamiseks (UML-i käsitletakse allpool). Järgnevalt kaalume protsessi struktuuri ja anname ka utiliitide komplekti, mida kasutatakse projekti arendamise juhtimisel RUP-i järgi.

RUP struktuur

UP pakub struktureeritud lähenemisviisi iteratiivsele tarkvaraarendusele, jagades protsessi ajaliselt neljaks peamiseks etapiks (verstapostid): algus, väljatöötamine, ehitus ja üleminek. Kahjuks puudub venekeelne väljakujunenud terminoloogia, seetõttu kasutame edaspidi ingliskeelseid termineid, lisades neile tõlke vene keelde. Joonisel fig. 2 on laialdaselt kasutatav RUP-faaside kujutis. Kõigi nende etappide eesmärgid on:

Algus on mõistmine, mida me loome. Teabe kogumise ja nõuete analüüsimise etapp, projekti kui terviku kuvandi määratlemine;

Töötamine - mõistmine, kuidas me seda loome. Nõuete analüüsi ja süsteemi kavandamise etapp, vajalike toimingute ja ressursside kavandamine, funktsioonide ja disainifunktsioonide täpsustamine;

Ehitus - toote beetaversiooni loomine. Arendamise ja kodeerimise põhietapp, toote loomine korduste alt-üles järjestusena (koodiversioonid);

Üleminek - toote lõpliku versiooni loomine. Toote tutvustamise etapp, toote tarnimine konkreetsele kasutajale.

Joonis: 2. RUP-i etapid

Need on toote evolutsiooni faasid - olelusringi kordused. RUP eeldab lähenemist lõppeesmärgile, kuid erinevalt klassikalisest ISO standardist (juga metoodika), kus üleminek on lõppfaas, saab iga faasi korrata mitu korda, peegeldades toote kliendi muutuvaid nõudeid.

RUP-metoodika põhineb üheksal põhivoolul (töövoo), mis on tarkvara elutsükli iteratsiooni elemendid:

Äri modelleerimine - hõlmab olelusringi antud iteratsiooni nõuete analüüsimist, soovitud süsteemi parameetrite ja kasutaja vajaduste määramist;

Nõuded - süsteemipildi vormistamine. See hõlmab nõuete kogumist ja nõuete haldamist, nõuete muutmist funktsionaalseteks spetsifikatsioonideks. Siit algab kasutusjuhtumite analüüs ja kasutusjuhtumite (kasutajalugude) konstrueerimine - kasutajate nõuete ametlik kaardistamine UML-is. Tulemuseks on juhtimistasandi dokumendid;

Analüüs ja kujundus - hõlmab kogutud nõuete tõlkimist formaalseks programmeerimismudeliks. Tulemuseks on süsteemi kirjeldus juurutamise etapis (tehniline disain) - need on süsteemiarendajate taseme dokumendid. Formaliseerimiskeel - Unified Modeling Language (UML), mida arutatakse allpool. Korduva arengu käigus areneb selle konkreetse voo toode - projekti mudel. Kõik muudatused on RUP-is seotud otseselt mudelitega ning automatiseerimisvahendid ja üsna paindlik modelleerimiskeel võimaldavad teil seda protsessi aja või ressursside osas enam-vähem valutult juhtida. Siinkohal peame silmas asjaolu, et arenduse tulemus pole mudel, vaid käivitatav kood, mistõttu kliendile ei meeldi tavaliselt modelleerimise eest maksta, kuna mudelid pole tema jaoks vajalik toode);

Rakendamine (juurutamine, kodeerimine) - hõlmab koodi tegelikku kirjutamist. RUP-i koodielemendid on loodud juba analüüsi ja kujundamise etapis, kuna UML-i juurutamise tööriist Rational Rose võimaldab teil luua koodielemente mitmes programmeerimiskeeles. Metoodika - objektile suunatud programmeerimine;

Test - hõlmab toote testimist antud iteratsioonis. Tuleb eriliselt märkida, et regressioonitestimine (toote "riknemise testimine") peaks sel juhul sisaldama kõiki eelmise iteratsiooni ja eelmise üleminekufaasi aktsepteerimistestide tegelikke katseid;

Juurutamine (juurutamine) - hõlmab toote paigaldamist kliendi juurde, personali koolitamist, süsteemi käivitamist koos vastuvõtukatsetega, pakendite ja toodete turustamisstandardite ettevalmistamist, materjalide üleandmist müügiosakonnale (toimingud on valikulised, sõltuvalt toote eripärast).

Ülaltoodud elemendid pole tarkvaraarenduse elutsükli osas uued, kuna neid esineb peaaegu igas metoodikas - võib-olla, välja arvatud XP (kus need on sellegipoolest esitatud väga originaalsel kujul). RUP-i rakendamise eripära on ajaline rõhk, nimelt sellel, millistes iteratsioonides domineerivad teatud niidid, samuti universaalse keele ja utiliitide komplekti olemasolu, mis võimaldab kirjeldada arendusprotsessi. Nagu näeme joonisel fig. 2 on toote arengu algfaasis keskendutud projekti vormistamisele (analüüs, modelleerimine), mille eesmärk on vähendada äririske ja vähendada disainivigade kulusid. Kui pilt on enam-vähem selge, algab toote tegelik väljatöötamine, testimine ja lõpuks ka rakendamine.

Esialgne interna on tegelikult dokumendid, mille on välja andnud tehniline nõukogu ettevõtte juhtidele. Esialgsete etappide põhieesmärk on lepingu või tahtekokkuleppe sõlmimine. Edasised kordused on tegelikult arendusmeeskonna töö algus, kellel on aega ja ressursse ametlike mudelite koostamiseks. UML-il on sel juhul vahendid mudeli kaardistamiseks elementide kodeerimiseks. Näiteks kuvatakse objektipuu otse, variatsioonid sõltuvad arendajate valitud programmeerimiskeele rakendamise võimsusest, samuti G. Boochi ja selle keele arendajate seisukohtade kokkulangemisest objektimudelil. Sama kehtib ka meetodite kohta.

Nüüd vaatame põhilisi töövooge:

Konfiguratsioonihaldus (konfiguratsiooni ja muudatuste haldamine) - võimas haldustoimingute kiht, mis on suunatud tooteversioonide haldamisele, mis hõlmab lähtekoodi juhtimist (mudel, käivitatavad failid, testid, dokumentatsioon), tooteversioonide juhtimist, ettevõtte standardeid koodi ja dokumentide arendamiseks, muudatuste jälgimist ja vead (vigade jälgimine); testimise ja klienditoega tihedalt seotud;

Juhtimine (projektijuhtimine) - hõlmab projekti haldamiseks haldusmeetmete komplekti vastavalt RUP ideoloogiale, kasutatakse projektijuhtimise tööriistu (Rational toodete loetelu leiate allpool);

Keskkond - hõlmab loomist ja hooldust analüüsivahendid, disain, arendus, testimine (nii tarkvara kui ka riistvara).

Iteratiivne areng;

Nõuete haldamine;

Modulaarsete arhitektuuride kasutamine;

Visuaalne modelleerimine;

Kvaliteedi kontrollimine;

Muudatuste jälgimine.

Tavad ei ole otseselt selle osa rUP-protsess, kuid väga soovitatav kasutamiseks. Mõned praktikad tulenevad otseselt RUP-ideoloogiast. Näiteks iteratiivne arendus on osa RUP-raamistikust, kuna see protsess on üks "spiraalsetest" teostustest. Nõuete haldamine RUP-is ilmub analüüsi alguses. Teoreetiliselt võimaldab modulaarne arhitektuur koodi taaskasutada ja süsteem on paindlikum. Tulenevalt asjaolust, et UML on objektikeel, on võimalik modulaarsust eirata, kuid ... mõnevõrra keeruline. Visuaalne modelleerimine võimaldab tõhusalt toime tulla süsteemide suureneva keerukusega. Lisaks on mudelid arendajate omavaheline suhtlemisvahend, kuid selleks peavad arendajad rääkima UML-i, mis nõuab teatavat koolitust. Visuaalset modelleerimist kasutatakse sageli tööriista Rational Rose abil, mis võimaldab hankida halduritele, süsteemiadministraatoritele, arendajatele, testijatele ja koodielementide genereerimiseks väga kasulike dokumentide komplekti. See tööriist pole ainus UML-i juurutus - saadaval on nii kommertsalternatiivid (näiteks Microsoft Visio) kui ka tasuta. Tuleb märkida, et modelleerimisvahendites rakendatud UML-murded ei ole alati ühesugused: ratsionaalses murdes on mõningaid olulisi erinevusi, mida on kirjeldatud nii dokumentatsioonis kui ka UML-raamatutes.

Tooted, mis toetavad RUP-i

järgmised on kõige kuulsamad tooted, mis toetavad ratsionaalset ühtset protsessi:

Rational Rose - visuaalse modelleerimise tööriist CASE infosüsteemidmillel on võime genereerida koodielemente. Toote eriväljaanne - Rational Rose RealTime - võimaldab hankida väljundisse käivitatava mooduli;

Rational Requisite Pro on nõuete haldamise tööriist, mis võimaldab teil luua, struktureerida, prioriseerida, jälgida, kontrollida rakenduste komponentide väljatöötamise mis tahes etapis toimuvaid muutusi;

Rational ClearQuest on projekt muudatuste haldamiseks ja defektide jälgimiseks projektis (vigade jälgimine), mis on tihedalt integreeritud testimise ja nõuete haldamise tööriistadega ning pakub ühtset keskkonda kõigi vigade ja dokumentide üksteisega sidumiseks;

Rational SoDA on projektdokumentatsiooni automaatseks genereerimiseks mõeldud toode, mis võimaldab teil sisemistele dokumentidele seada ettevõtte standardi. Samuti on võimalik viia dokumentatsioon olemasolevatele standarditele (ISO, CMM);

Ratsionaalse puhastamise, ratsionaalse kvantifitseerimise, Rational PureCoverage'i, testimise ja silumise tööriistad:

Rational Purify on väga võimas jooksuaja tõrkeotsingu tööriist rakenduste ja komponentide arendajatele, kes programmeerivad C / C ++ keeles,

Rational Visual Quantify on jõudluse mõõtmise tööriist rakenduste ja komponentide arendajatele, kes programmeerivad C / C ++, Visual Basic ja Java; aitab tuvastada ja kõrvaldada tarkvara jõudluse kitsaskohad,

Rational Visual PureCoverage - tuvastab automaatselt testimata koodipiirkonnad.

Rational ClearCase on tarkvara konfiguratsioonihaldustoode (Rational's Software Configuration Management, SCM), mis võimaldab hallata kõigi projektidokumentide versiooni. Selle abiga saate samaaegselt toetada mitut projektiversiooni, vahetades neid kiiresti. Rational Requisite Pro hooldab värskendusi ja jälgib muudatusi arendustiimi nõuetele;

SQA TeamTest - testautomaatika tööriist;

Rational TestManager on testide haldamise süsteem, mis koondab kõik testidega seotud tööriistad, artefaktid, skriptid ja andmed;

Rational Robot - tööriist testide loomiseks, muutmiseks ja automaatseks käitamiseks;

SiteLoad, SiteCheck - tööriistad veebisaitide toimivuse ja katkiste linkide olemasolu testimiseks;

Rational PerformanceStudio - süsteemi jõudluse omaduste mõõtmine ja ennustamine.

Artefaktid ja rollid

rUP-i lahutamatu osa on artefakt, pretsedent ja roll. Artefaktid on mõned projekti tooted, mis on loodud või mida kasutatakse lõpptoodangu koostamisel. Kasutusjuhud on toimingute jadad, mille süsteem on teinud vaadeldava tulemuse saamiseks. Tegelikult on üksikisiku või rühma mis tahes töö tulemus artefakt, olgu see siis analüüsidokument, mudeli element, koodifail, testskript, vea kirjeldus jne. Selle või selle tüüpi esemete loomise eest vastutavad teatud spetsialistid. Seega määratleb RUP selgelt arendusmeeskonna iga liikme vastutuse ühes või teises etapis, see tähendab, millal ja kes peaksid selle või selle artefakti looma. Kogu tarkvarasüsteemi arendamise protsessi peetakse RUP-is artefaktide loomise protsessiks - alates esialgsetest analüüsidokumentidest kuni käivitatavate mooduliteni, kasutusjuhenditeni jne. Allpool on artefaktide komplekt (mudelid, dokumendid jne) iga voo jaoks.

Äri modelleerimine

Äriprotsesside mudel - ärinõuete määratlemine arendatavale süsteemile;

Ettevõtte struktuurimudel - artefakt süsteemi funktsionaalse mudeli väljatöötamiseks;

Dokumendimudelid, äriüksused, ärifunktsioonide stsenaariumimudelid, majandusüksuste olekumudelid - kasutajaliidese, andmebaasisüsteemide kujundamiseks; on süsteemi staatiliste ja dünaamiliste olekute kirjeldus erinevatest vaatepunktidest;

Ärireeglite mudelid - artefakt, mida kasutatakse reeglite modelleerimiseks tarkvaras.

Dokumendi artefaktid - kasutab RequisitePro, SoDA, tekstitöötlusprogrammid, Microsofti projekt:

Hinnang kliendi organisatsioonile, äristruktuurile;

Domeeniterminite sõnastik;

Ärireeglite kogum;

Äripakkumine;

Ärifunktsioonide spetsifikatsioonid;

Tööplaan ärimudeli staadiumis;

Taotluste muutmine.

Nõuded

Mudeli esemed - kasutab Rational Rose:

Süsteemi funktsiooni mudel;

Süsteemi funktsioonide stsenaariumi mudel;

Kasutajaliidese mudel;

Süsteemikasutaja stsenaariumide mudel;

Väljundvormide mudel;

Süsteemi reeglite mudel.

Nõuete haldamise kava;

Süsteemi sõnastik;

Tarkvarasüsteemi spetsifikatsioon;

Süsteemi funktsiooni spetsifikatsioon;

Süsteemi reeglid;

Sidusrühmade päringud;

Tööplaan süsteemile esitatavate nõuete kindlaksmääramise etapis;

Taotluste muutmine.

Analüüs ja kujundus

Mudeli esemed - kasutab Rational Rose:

Loogiline andmemudel;

Füüsiliste andmete mudel;

Süsteemi komponentide spetsifikatsiooni mudel;

Süsteemikomponente rakendavate klasside koostoime stsenaariumid.

Dokumendi artefaktid - kasutab RequisitePro, SoDA, tekstiprotsessorid, MS Project:

Tarkvara arhitektuur;

Tarkvara komponentide spetsifikatsioonid;

Tööplaan analüüsi ja kujunduse etapis;

Taotluste muutmine.

Rakendamine

Mudeli esemed - kasutab Rational Rose:

Rakenduskomponendi mudel.

Koodiartefaktid - kasutab Rational Rose, programmeerimistööriistad, tekstitöötlusprogrammid:

Rational Rose'ilt saadud koodi genereerimise elemendid;

Tegelik rakenduse kood;

Dokumentatsioon.

Dokumendi artefaktid - kasutab RequisitePro, SoDA, tekstiprotsessorid, MS Project:

Rakenduse loomise plaan;

Tööplaan rakendamise etapis.

Test

Mudeli esemed - kasutab Rational Rose:

Testjuhtumi mudel;

Testprogrammi funktsionaalne mudel;

Testprogrammi komponentide spetsifikatsiooni mudel;

Testiprogrammi komponentide interaktsiooni rakendavate klasside koostoime stsenaariumid.

Testjuhtumite kirjeldus;

Testiplaan;

Tööplaan testimise etapis;

Taotluste muutmine.

Rakenduse testimine - kvantifitseerimine, puhastamine, PureCoverage, robot, SiteLoad, SiteCheck.

Juurutamine

Mudeli esemed - kasutab Rational Rose:

Paigutusmudel - komponentide töötlemissõlmedele paigutamise kirjeldus.

Dokumendi artefaktid - kasutavad SoDA, tekstitöötlejad, MS Project:

Õppematerjalid;

Paigaldusdokumendid;

Süsteemiversioonide kirjeldus;

Rakenduskava.

Selle sarja järgmine artikkel keskendub ühtsele modelleerimiskeelele (UML).