Ü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.

hakake ründama peamisi riske, käituge 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 projekteerimisel ja rakendamisel rangelt

keskenduge jooksvale programmile: töötamine tarkvaratestide läbimine 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 paigutada nii, et see oleks muutustele vastuvõtlik.

pange käivitatava arhitektuuri alus võimalikult varakult. Käivitatav arhitektuur - võtmete kasutamise juhtumid. 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õudmistest saab hea idee valmistoote kontseptsioon 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 kogu arendustöö lepinguliseks sõlmimiseks on riskid piisavalt kontrolli all?

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 toiminguid nagu tiraaži tootmine, kliendi töötajate koolitamine, vihjeliinide tugiteenuste korraldamine ja pärast kohaletoimetamist avastatud defektide kõrvaldamine.

Ratsionaalne ühtne protsess (RUP) - arendusmetoodika tarkvaraloodud Rational Software poolt.

Põhimõtted: Peamiste riskide varajane tuvastamine ja pidev (kuni projekti lõpuni) kõrvaldamine. Keskendumine käivitatava programmi klientide nõuete täitmisele (kasutusjuhtumite (kasutusjuhtumite) mudeli analüüs ja konstrueerimine). Ootuste, disainiotsuste ja rakendamise muutuste ootamine arenduse käigus. Projekti alguses rakendatud ja testitud komponendi arhitektuur. Pidev kvaliteedi tagamine kõigis projekti (toote) arendamise etappides.

Töötamine tihedas meeskonnas projekti kallal, milles arhitektidel on võtmeroll.

RUP kasutab iteratiivne arengumudel... Iga iteratsiooni lõpus (ideaalsel juhul kestab see 2 kuni 6 nädalat) peaks projekti meeskond saavutama selle iteratsiooni jaoks kavandatud eesmärgid, looma või viimistlema kujunduse esemeid ja hankima lõpptoote vahepealse, kuid funktsionaalse versiooni.

Tootearenduse täielik elutsükkel koosneb neli faasi, millest igaüks sisaldab ühte või mitut kordust: algfaas, täpsustamis-, kavandamis- ja rakendamisetapp.

Äärmuslik programmeerimine (XP)

Äärmuslik programmeerimine (Extreme Programming, XP) on üks vilgas tarkvaraarenduse metoodika

12 põhitehnikat Äärmusliku programmeerimise (vastavalt raamatu esmatrükile Selgitatud äärmuslik programmeerimine) võib jagada nelja rühma:

Lühike tagasiside: (Testpõhine arendus, plaanimäng, klient on alati olemas, paari programmeerimine

Pidev, mitte partiiprotsess: Pidev integreerimine, refaktoreerimine, sagedased väikesed väljalasked

Kõigi ühine arusaam: Lihtsus, süsteemimetafoor, koodi või valitud kujundusmustrite ühine omamine, kodeerimisstandard

Programmeerija sotsiaalkindlustus: 40 tundi töönädal

Paaride programmeerimine eeldab, et kogu koodi loovad programmeerijate paarid, kes töötavad samas arvutis. Jagatud omand tähendab seda, et iga meeskonnaliige vastutab kogu lähtekoodi eest. XP klient ei maksa arveid, vaid see, kes süsteemi tegelikult kasutab.

Dokumentatsiooni standardid

Standardid tagavad projektide ühilduvuse. Standardid parandavad inseneride mõistmist. Insenerid peaksid standardeid mõistma kui midagi neile kasulikku, mitte kui takistuste kogumit. Selged ja mõõdetavad eesmärgid, mis nõuavad distsiplineeritud ja dokumenteeritud lähenemist, on arendajatele tavaliselt heaks motivatsiooniks.

SVVP -Plaan määratleb, kuidas ja millises järjekorras tuleks projekti etappe kontrollida. Kontrollimine on protsess, millega kontrollitakse, kas rakendus on õigesti ehitatud. Valideerimine kontrollib, kas vajalik toode on kokku pandud.

SQAP -Tarkvara kvaliteedikontrolli kava

SCMP -Majanduskava programmiprojekt

SRS -Tarkvaranõuete spetsifikatsioon

SDD -Tarkvara disaini dokumentatsioon

Suguhaigus -Tarkvara testimise dokumentatsioon

Dokumentatsiooni järjepidevus ja terviklikkus.

Dokumendihaldus nõuab märkimisväärseid korraldamisoskusi. Hea paindliku dokumentatsiooni kirjutamine sarnaneb hea paindliku koodi kirjutamisega.

Dokumendihaldus seisneb hoolduses täielikkus ja järjepidevus ja sisaldab ka konfiguratsiooni juhtimine.

Täielikkus -arendus- ja hooldusprotsessi hõlmava dokumentatsiooni olemasolu.

Järjepidevus tähendab, et dokumentide komplekt ei sisalda sisemisi vastuolusid. Probleem on selles, et kui see komplekt on suur, on selles üsna keeruline vältida üksteist välistavate avalduste esinemist.

Konfiguratsiooni tugi -see on dokumentatsiooni ja programmikoodi erinevate versioonide ja osade kooskõlastamine.

RUP on näide nn "raske" protsess, mida on üksikasjalikult kirjeldatud ja eeldades tuge tarkvara lähtekoodi tegelikule väljatöötamisele suure hulga abitoimingutega. Sellisteks toiminguteks on näiteks plaanide väljatöötamine, tehnilised kirjeldused, arvukad disainimudelid, projektdokumentatsioon jne. Sellise protsessi peamine eesmärk on eraldada edukas tarkvaraarendus- ja hooldustava konkreetsetest inimestest, kes oskavad neid rakendada. Arvukad toetavad tegevused pakuvad lootust võimaldada keerukate süsteemide väljatöötamise ja hooldamise probleeme edukalt lahendada olemasolevate töötajate abil, kes pole tingimata superprofessionaalid.

Selle saavutamiseks viiakse läbi hierarhiline üksikasjalik kirjeldus antud olukorras tehtud toimingute kohta, et tavalist töötajat saaks õpetada käituma sarnaselt. Projekti käigus luuakse palju vahedokumente, mis võimaldavad arendajatel oma ülesanded järjekindlalt lihtsamateks jaotada. Need samad dokumendid aitavad kinnitada igal etapil tehtud otsuseid, samuti jälgida üldist arengut ja täpsustada soovitud tulemuste saamiseks vajalike ressursside hinnanguid.

Äärmuslik programmeeriminevastupidi, see esindab nn Agile arendusmeetodidnimetatud ka "valgus" protsessid. Nad keskenduvad heade arendajate kasutamisele, mitte hästi töötavatele arendusprotsessidele. Elamismeetodid väldivad selgete toimemudelite fikseerimist, et pakkuda igas konkreetses projektis suuremat paindlikkust, ning on vastu ka täiendavate dokumentide väljatöötamisele, mis ei aita otseselt kaasa lõppenud tööprogrammis.

Ratsionaalne ühtne protsess

RUP on üsna keeruline, üksikasjalik iteratiivne olelusringi mudel KÕRVAL .

Ajalooliselt on RUP arendusprotsessi mudel, mille Ericsson võttis kasutusele XX sajandi 70. ja 80. aastatel. Selle mudeli lõi Ivar Jacobson, kes asutas hiljem, 1987. aastal, oma ettevõtte Objectory AB, et arendada tarkvaraarenduse töövoogu eraldi tootena, mida saaks üle kanda teistele organisatsioonidele. Pärast Objectory infusiooni Rationali 1995. aastal integreeriti Jacobsoni kujundused "klassika" autori poja Walker Royce'i loominguga kaskaadmudel), Kruchten (Philippe Kruchten) ja Booch (Grady Booch) ning arenevad paralleelselt Ühtne modelleerimiskeel (UML).

RUP põhineb kolmel põhiideel:

Kogu töö kulg on suunatud projekti lõppeesmärkidele, mis on väljendatud kujul kasutamise juhtumid - tekkiva tarkvarasüsteemi ja kasutajate või muude süsteemide koostoimimise stsenaariumid, mille teostamisel saavad kasutajad neile olulisi tulemusi ja teenuseid. Arendus algab kasutusjuhtumite tuvastamisest ja seda kontrollitakse igal etapil nende rakendamise lähendamise astme järgi.

• Peamine projekti käigus vastu võetud otsus on: arhitektuur saadud tarkvarasüsteem. Arhitektuur kehtestab komponentide komplekti, millest tarkvara ehitatakse, iga komponendi vastutus (st alamülesanded, mille see süsteemi üldiste ülesannete raames lahendab), määratletakse selgelt liidesed, mille kaudu nad saavad omavahel suhelda, samuti see, kuidas komponendid omavahel suhtlevad.

  Arhitektuur on nii kvaliteetse tarkvara hankimise alus kui ka tööde ja projektide hindamise planeerimine teatud tulemuste saavutamiseks vajaliku aja ja ressursside osas. See on kujundatud komplektina graafilised mudelid UML-keeles.

• Arendusprotsess põhineb planeeritud ja juhitud kordused, mille ulatus (iteratsioonis rakendatud funktsionaalsus ja komponentide komplekt) määratakse arhitektuuri põhjal.

Ühtne protsess (UP) on üldistatud 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 igat tüüpi töötajad loovad.

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 äärmusliku programmeerimise tehnikat (vastavalt raamatu Esmane väljaanne selgitamisele esmatrüki järgi) võib jagada nelja rühma:

1. 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. Koodiga kollektiivne omand või valitud mustrite omand

e. Kodeerimise standard või kodeerimise tavad

4. Programmeerija sotsiaalkindlustus (programmeerija hoolekanne):

a. 40-tunnine töönädal (jätkusuutlik 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 tarkvarajuhtimise neljal põhietapil, 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üüsifaasis luuakse kasutusjuhtumudelid, kasutajaliidese mudel ja domeeniolemismudel. 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, kui 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ärgmisel sprindil juurutamiseks määratakse 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 lõppkasutajate ja teiste tootest huvitatud osapoolte huve; ja ristfunktsionaalne Meeskond (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 teatud fikseeritud ü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 rakendamist vajavatest. 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 (RUP) on tarkvara spiraalse arendamise metoodika. Metoodikat toetab Rational Software ja toodet värskendatakse umbes kaks korda aastas. Aastal modelleeriva keelena ühine alus teadmised kasutavad ühtlast modelleerimiskeelt (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 arengutsükli alguses ning seejärel vaadatakse need aja jooksul ja projekti edasiste korduste käigus edasi. Uued eesmärgid ilmuvad sõltuvalt nende riskide prioriteetidest. Versiooniväljaanded 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;

Pakub vormi, mis on piisav mõtlemiseks ja seejärel otsuste langetamiseks, ning vahendi 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. Arenduse 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:

Ärimodelleerimine - hõlmab olelusringi antud iteratsiooni nõuete analüüsimist, soovitud süsteemi parameetrite ja kasutajate 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 kasutusjuhtude analüüs ja kasutusjuhtumite (kasutajalugude) konstrueerimine - algab 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 ei ole 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. Eriti tuleks märkida, et regressioonitestimine (pöördkatse, toote "halvenemise" testimine) peaks sel juhul sisaldama kõiki eelmise iteratsiooni ja eelmise üleminekuetapi aktsepteerimistestide asjakohaseid 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 need esinevad 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 ajutine rõhuasetus, nimelt see, millistes iteratsioonides domineerivad teatud niidid, samuti universaalse keele olemasolu ja utiliitide komplekt, mis võimaldab kirjeldada arendusprotsessi. Nagu näeme joonisel fig. 2, toote arendamise algfaasis on põhirõhk projekti vormistamisel (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 ülesehitamiseks. UML-il on sel juhul vahendid mudeli kaardistamiseks elementide kodeerimiseks. Näiteks kuvatakse objektide puu 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) - võtab projekti haldamiseks haldusmeetmete komplekti vastavalt RUP ideoloogiale, kasutatakse projektijuhtimise tööriistu (vt allpool Rational toodete loendit);

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.

Praktikad ei kuulu otseselt RUP-protsessi ossa, kuid on väga soovitatavad. 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 varases staadiumis. 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 juurutamine - 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, juhtida nõuete muudatusi, mis toimuvad rakenduse komponentide väljatöötamise mis tahes etapis;

Rational ClearQuest on projekt muudatuste haldamiseks ja defektide jälgimiseks (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 käitamisvigade leidmise 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 konfiguratsioonihalduse (SCM) toode, mis võimaldab kõigi projekti dokumentide versiooni juhtimist. Selle abiga saate korraga säilitada 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 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; kujutavad süsteemi staatiliste ja dünaamiliste olekute kirjeldust erinevatest vaatenurkadest;

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

Dokumendi artefaktid - kasutab RequisitePro, SoDA, tekstitöötlusprogrammid, Microsoft Project:

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äljundvormi 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.

Artefaktide kood - kasutab Rational Rose, programmeerimisvahendid, 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).