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

hakake ründama peamisi riske, tehke seda pidevalt, muidu ründavad riskid teid.

tagage kliendi nõuete täitmine: dokumenteerige nõuded kliendile arusaadaval viisil ning järgige neid nõudeid projekteerimisel ja rakendamisel rangelt

keskenduge käepärast olevale programmile: jooksmisele tarkvara testide läbimine parem kui põhjalik dokumentatsioon

kohaneda muutustega juba projekti algusest peale: kaasaegsed rakendused on piisavalt keerulised, et saaksime spetsiifilisi nõudeid esitada juba arenduse alguses. Seetõttu on vaja tarkvara arhitektuur kujundada selliselt, et see oleks vastuvõtlik muutumisele.

panna käivitatavale arhitektuurile alus võimalikult varakult. Käivitatav arhitektuur – peamised kasutusjuhud. VI võti on süsteemi funktsionaalsus, ilma milleta pole tarkvaral mõtet. Võti. VI-d moodustavad 7-10% kõigist valikutest

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

töötada 1 meeskonnana

muuta kvaliteet eluviisiks, mitte järelmõtlemiseks

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

Ühtset protsessi korratakse tsükliliselt. See ühtse protsessi iteratsioonide jada esindab süsteemi elutsüklit. Iga tsükkel lõpeb toote väljalaskega klientidele.

Iga tsükkel koosneb neljast etapist – nõuete analüüs ja planeerimine, projekteerimine, ehitamine ja teostus. Iga faas, nagu allpool kirjeldatud, on jaotatud edasi iteratsioonideks.

ajal analüüsi ja planeerimise etapid nõuded hea mõte muutub valmistoote kontseptsiooniks ja koostatakse äriplaan selle toote arendamiseks. Eelkõige tuleks selles etapis vastata järgmistele küsimustele:

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

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

Mis on plaan ja kui palju toote arendamine maksma läheb?

Selles etapis luuakse arhitektuuri prooviversioon. Tavaliselt on see ülevaade, mis sisaldab kõige olulisemaid alamsüsteeme. Selles etapis tehakse kindlaks ja seatakse prioriteediks kõige olulisemad riskid, kavandatakse üksikasjalikult projekteerimisfaas ning hinnatakse ligikaudselt kogu projekt.

ajal projekteerimise etapid enamik kasutusjuhtumeid on üksikasjalikult kirjeldatud ja süsteemi arhitektuur on välja töötatud.

Projekteerimisfaasi lõpus tegeleb projektijuht tegevuste planeerimisega ja projekti lõpuleviimiseks vajalike ressursside arvutamisega. Siinkohal on võtmeküsimus: kas kasutusjuhud, arhitektuur ja disain on piisavalt küpsed ning kas riskid on piisavalt kontrolli all, et õigustada lepingulist kohustust arendustöö lõpule viia?

ajal ehitusfaasid luuakse toode - luustikule (arhitektuurile) lisatakse lihased (lõpetatud programmid). Selles faasis kasvab arhitektuuri põhitase terviklikuks küpseks süsteemiks. Kontseptsioonid töötatakse välja tooteks, mis on valmis kasutajatele üle andma. Etapi jooksul suureneb vajalike ressursside hulk. Selle etapi lõpus sisaldab toode kõiki kasutusjuhtumeid, mille juhtkond ja klient nõustusid praegusesse väljalaskesse lisama. Tõsi, need võivad sisaldada vigu. Enamik defekte avastatakse ja parandatakse rakendamisetapis. Etapi lõpu põhiküsimus on järgmine: kas toode vastab kasutaja nõudmistele niivõrd, et mõnele kliendile saab ette tarnida?

Rakendusfaas hõlmab perioodi, mille jooksul toode eksisteerib beetaversiooni või beetaversioonina. Väike arv kvalifitseeritud kasutajaid, kes töötavad toote beetaversiooniga, teatavad defektidest ja puudustest. Seejärel parandavad arendajad leitud vead ja lisavad mõned soovitatud täiustused suurele väljalasele, mis on valmis laialdaseks levitamiseks. Rakendusfaas hõlmab selliseid tegevusi nagu koopiate valmistamine, klienditöötajate koolitamine, vihjeliini toe korraldamine ja pärast tarnimist avastatud defektide parandamine.

Rational Unified Process (RUP)- arendusmetoodika tarkvara, loodud poolt Rational Tarkvara.

Põhimõtted: Suuremate riskide varajane tuvastamine ja pidev (kuni projekti lõpuni) kõrvaldamine. Keskendumine kliendi nõuete täitmisele käivitatava programmi osas (pretsedentide mudeli (kasutusjuhtumite) analüüs ja konstrueerimine). Arendusprotsessi käigus on oodata muutusi nõuetes, disainiotsustes ja teostuses. Projekti alguses rakendatud ja testitud komponentide arhitektuur. Pidev kvaliteedi tagamine projekti (toote) arendamise kõikides etappides.

Projekti kallal töötamine tihedas meeskonnas, milles arhitektidel on võtmeroll.

RUP kasutab iteratiivne arengumudel. Iga iteratsiooni (ideaaljuhul 2–6 nädalat) lõpus peaks projektimeeskond saavutama selle iteratsiooni jaoks kavandatud eesmärgid, looma või viimistlema disainiartefakte ning hankima lõpptoote vahepealse, kuid funktsionaalse versiooni.

Kogu tootearenduse elutsükkel koosneb neli faasi, millest igaüks sisaldab ühte või mitut iteratsiooni: algfaas, selgitamise, kavandamise ja rakendamise faas.

Extreme Programming (XP)

Ekstreemne programmeerimine(Extreme Programming, XP) – üks paindlikke tarkvaraarenduse metoodikaid

12 põhitehnikatäärmusliku programmeerimise (vastavalt raamatu Extreme programming selgitatud esimesele väljaandele) saab ühendada nelja rühma:

Lühike tsükkel tagasisidet: (Testipõhine arendus, planeerimismäng, klient on alati olemas, paarisprogrammeerimine

Pidev kui partiiprotsess: Pidev integreerimine, ümbertegemine, sagedased väikesed väljaanded

Kõigile jagatud arusaam: lihtsus, süsteemimetafoor, koodi või valitud kujundusmustrite kollektiivne omamine, kodeerimisstandard

Programmeerija sotsiaalkindlustus: 40 tundi töönädal

Paarprogrammeerimine hõlmab kogu koodi, mille loovad programmeerijapaarid, kes töötavad samas arvutis. Kollektiivne omand tähendab, et iga meeskonnaliige vastutab kogu lähtekoodi eest. XP-s pole "klient" mitte see, kes arveid maksab, vaid see, kes süsteemi reaalselt kasutab.

Dokumentatsiooni standardid

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

SVVP- Plaan määrab, kuidas ja millises järjestuses projekti etappe testida. Kinnitamine on protsess, mille käigus kontrollitakse, kas rakendus on õigesti üles ehitatud. Valideerimine kinnitab, et vajalik toode on kokku pandud.

SQAP- Tarkvara kvaliteedikontrolli plaan

SCMP- Majandamiskava tarkvara projekt

SRS- Tarkvaranõuete spetsifikatsioon

SDD- Tarkvara projekteerimisdokumentatsioon

STD- Tarkvara testimise dokumentatsioon

Dokumentatsiooni järjepidevus ja terviklikkus.

Dokumendihaldus nõuab olulisi organiseerimisoskusi. Hea ja paindliku dokumentatsiooni kirjutamine sarnaneb hea ja paindliku koodi kirjutamisega.

Dokumendihaldus tähendab selle säilitamist täielikkus Ja järjepidevus ja sisaldab ka Konfiguratsiooni juhtimine.

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

Järjepidevus tähendab, et dokumentide kogum ei sisalda sisemisi vastuolusid Probleem on selles, et kui see hulk on suur, siis on üsna raske vältida üksteist välistavate väidete ilmnemist selles.

Konfiguratsiooni tugi - see on dokumentatsiooni ja programmikoodi erinevate versioonide ja osade koordineerimine.

RUP on näide nn "raske" protsess, mida kirjeldatakse üksikasjalikult ja soovitatakse toetada tarkvara lähtekoodi tegelikku väljatöötamist koos suure hulga abitoimingutega. Sellised tegevused on näiteks plaanide väljatöötamine, tehnilised ülesanded, arvukad disainimudelid, projekteerimisdokumentatsioon jne. Selle protsessi peamine eesmärk on eraldada edukad tarkvaraarenduse ja -hoolduse praktikad konkreetsetest inimestest, kes oskavad neid rakendada. Arvukad toetavad tegevused annavad lootust seda teha edukas lahendus keerukate süsteemide ehitamise ja toetamise ülesanded olemasolevate töötajate abiga, kes ei pruugi olla üliprofessionaalid.

Selle saavutamiseks viiakse läbi hierarhiline samm-sammult üksikasjalik kirjeldus antud olukorras tehtud toimingute kohta, et tavalist töötajat saaks õpetada sarnaselt tegutsema. Projekti käigus luuakse palju vahedokumente, mis võimaldavad arendajatel järjestikku jaotada ees seisvad ülesanded lihtsamateks. Need samad dokumendid aitavad kontrollida igal etapil tehtud otsuste õigsust, samuti jälgida töö üldist edenemist ja selgitada soovitud tulemuste saavutamiseks vajalike ressursside hinnanguid.

Ekstreemne programmeerimine, vastupidi, esindab nn "elusad" (agiilsed) arendusmeetodid, nimetatud ka "valgus" protsessid. Nad rõhutavad pigem heade arendajate kui heade arendusprotsesside kasutamist. Eluviisid väldivad plaanide selgeks tegemise kohustust, et võimaldada projektipõhiselt suuremat paindlikkust, ning takistavad ka täiendavate dokumentide väljatöötamist, mis ei aita otseselt kaasa valmis tööprogrammile.

Ratsionaalne ühtne protsess

RUP on üsna keeruline, detailne iteratiivne elutsükli mudel KÕRVAL .

Ajalooliselt on RUP arendusprotsessi mudeli edasiarendus, mille Ericsson võttis kasutusele 20. sajandi 70. ja 80. aastatel. Selle mudeli lõi Ivar Jacobson, kes asutas hiljem, 1987. aastal, oma ettevõtte Objectory AB spetsiaalselt selle arendamiseks. tehnoloogiline protsess tarkvara arendamine eraldi tootena, mida saaks teistele organisatsioonidele üle anda. Pärast Objectory ühendamist Rationaliga 1995. aastal integreeriti Jacobsoni arendused Royce'i (Walker Royce, "klassikalise" autori poeg) loominguga. kaskaadmudel), Kruchten (Philippe Kruchten) ja Booch (Grady Booch), samuti paralleelse arendusega universaalne modelleerimiskeel (Unified Modeling Language, UML).

RUP põhineb kolmel põhiideel:

Kogu töö edenemist juhivad projekti lõplikud eesmärgid, mis on väljendatud vormis kasutusjuhtumeid- tulemuseks oleva tarkvarasüsteemi interaktsiooni stsenaariumid kasutajate või muude süsteemidega, mille käigus kasutajad saavad nende jaoks tähendusrikkaid tulemusi ja teenuseid. Arendus algab kasutusjuhtude tuvastamisest ja igal etapil kontrollitakse nende rakendamise läheduse astme järgi.

• Peamine projekti käigus tehtud otsus on arhitektuur tulemuseks olev tarkvarasüsteem. Arhitektuur määrab kindlaks komponentide komplekti, millest tarkvara koostatakse, iga komponendi vastutusalad (st alamülesanded, mida see lahendab süsteemi üldiste ülesannete raames), määratleb selgelt liidesed, mille kaudu nad saavad suhelda, nagu samuti seda, kuidas komponendid üksteisega suhtlevad.

  Arhitektuur on nii kvaliteetse tarkvara hankimise aluseks kui ka tööde planeerimise ja projekti hinnangute aluseks teatud tulemuste saavutamiseks kuluva aja ja ressursi osas. See on komplekti kujul graafilised mudelid UML keeles.

• Arendusprotsessi aluseks on planeeritud Ja juhitud iteratsioonid, mille ulatus (iteratsiooni raames realiseeritav funktsionaalsus ja komponentide komplekt) määratakse arhitektuuri alusel.

Ühtne protsess(UP) on üldistatud raami protsess, mida saab spetsialiseeruda paljudele tarkvarasüsteemidele, erinevatele rakendusvaldkondadele, oskuste tasemetele ja projekti suurustele.

Ühtne protsess komponendile orienteeritud. See tähendab, et loodud tarkvarasüsteem on üles ehitatud tarkvara baasil komponendid, ühendatud hästi määratletud liidestega.

UP spetsiifilised aspektid seisnevad selle kolmes omaduses:

● juhitud kasutusjuhtudest;

● on arhitektuurile orienteeritud;

● on iteratiivne ja inkrementaalne .

Ühtne protsessi elutsükkel

UP elutsükkel on jaotatud tsükliteks, millest igaüks kulmineerub toote vabastamisega. Iga arendustsükkel koosneb neljast etapist – nõuete analüüs ja planeerimine, projekteerimine, ehitamine, teostus. Iga faas on jagatud iteratsioonideks.

UP sisaldab kaheksat töövoogu: viis peamist- nõuete määratlemine, analüüs, projekteerimine, juurutamine, testimine ja kolm abi (peamiste toetamiseks) - nõuete konfigureerimine ja muudatuste juhtimine, projektijuhtimine, keskkonnajuhtimine.

Töövoo struktuuri määratlemiseks peate esmalt kindlaks määrama, mis esinejate tüübid protsessis osaleda. Siis otsustati artefaktid, mille peavad looma igat tüüpi töötajad antud töövoo käigus.

18. XP on protsess.

Ekstreemne programmeerimine(inglise keeles: Extreme Programming, XP) on üks paindlikke tarkvaraarenduse metoodikaid. Metoodika autorid on Kent Beck, Ward Cunningham, Martin Fowler jt.

Ekstreemse programmeerimise kaksteist põhitehnikat (vastavalt raamatu Extreme programming selgitatud esimesele väljaandele) saab ühendada nelja rühma:

1. Lühike tagasisidetsükkel (täpse skaala tagasiside)

a. Testipõhine arendus

b. Planeerimismäng

c. Klient on alati läheduses (terve meeskond, kohapealne klient)

d. Paari programmeerimine

2. Pigem pidev kui partiiprotsess

a. Pidev integreerimine

b. Refactoring (disaini täiustamine, ümberehitamine)

c. Sagedased väikesed väljaanded

3. Arusaam, mida jagavad kõik

a. Lihtsus (lihtne disain)

b. Suhtlemine

c. Respekt

d. Kollektiivne koodi omandiõigus või valitud kujundusmustrid (kollektiivsete mustrite omandiõigus)

e. Kodeerimisstandard või kodeerimise kokkulepped

4. Programmeerija heaolu:

a. 40-tunnine töönädal (jätkusuutlik tempo, neljakümnetunnine nädal)

XP-s jaguneb protsess ajastatud protsessidega võrreldes väga väikesteks sammudeks. Selle tulemuseks on see, et esimestel sammudel kulub jugamudeli iga etapi jaoks kuude või isegi aastate asemel päevi või nädalaid. Esiteks kirjutatakse arenduseesmärkide kirjeldamiseks automatiseeritud testid. Seejärel tuleb kodeerimine, mis lõpeb hetkel, kui kõik testid läbivad ja programmeerijad ei saa uusi teste välja mõelda. Disaini teevad samad inimesed, kes koodi kirjutavad. (ainult viimane samm – disaini ja koodi ühendamine – on ühine kõikidele agiilsetele protsessidele). Lõpetamata, kuid toimivat süsteemi näidatakse kitsale kasutajate ringile (enamasti on need arendajad ise). Sel hetkel hakkavad nad kirjutama teste süsteemi järgmise olulise osa jaoks.

19. ICONIX on protsess.

ICONIXi töötas välja Doug Rosenberg kell ICONIX tarkvara ICONIX-protsess põhineb kasutusjuhtumitel, kuid sellel pole palju puudusi. See protsess kasutab ka UML-i modelleerimiskeelt, kuid kasutatakse ainult UML-i põhimärke - see on 20% keelest. ICONIX protsess põhineb neljal peamisel kasutusjuhtumipõhisel tarkvaraarenduse etapil:

● domeeni modelleerimine;

● pretsedentide modelleerimine;

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

● jadaskeemide koostamine.

Protsessi peamised etapid on järgmised:

● Nõuete analüüs

● Eelprojekt

● Disain

● Rakendamine

Protsess põhineb minimaalse arvu mudelite loomisel, mis kajastavad tulevast süsteemi. Analüüsi etapis luuakse kasutusjuhtude mudelid, kasutajaliidese mudel ja domeeni olemi mudel. Eelprojekteerimise etapis koostatakse vastupidavuse diagramm. Täiendatakse ka pretsedendimudelit ja domeeni olemi mudelit. Detailse projekteerimise etapis koostatakse järjestusskeem (SequenceDiagram) ja klassiskeem. Rakendusfaasis luuakse lähtekood. Samuti saate luua juurutusskeemi ja komponentide diagrammi. iga etapp kulmineerub ülevaate verstapostiga, kus genereeritud diagramme tuleb kolleegidega arutada.

20. SCRUM on protsess.

Scrum on põhimõtete kogum, millele arendusprotsess on üles ehitatud, võimaldades rangelt fikseeritud lühikesi ajaperioode ( sprintid 2 kuni 4 nädalat) pakkuda lõppkasutajale töötavat tarkvara uute funktsioonidega, millel on kõrgeim prioriteet. Tarkvara võimalused järgmise sprindi rakendamiseks määratakse sprindi alguses planeerimisetapis ja ei saa kogu selle kestuse jooksul muutuda. Samas annab sprindi rangelt fikseeritud lühike kestvus arendusprotsessile etteaimatavuse ja paindlikkuse.

Peamised rollid Scrumis: ScrumMaster- see, kes juhib Scrum koguneb ja tagab kõigi põhimõtete järgimise Scrum(roll ei tähenda midagi muud kui õiget käitumist Scrum-ah, projektijuht pigem viitab Toote omanik ja ei tohiks olla ScrumMaster);Toote omanik (Toote omanik) - isik, kes esindab lõppkasutajate ja teiste tootest huvitatud isikute huve; ja ristfunktsionaalne Meeskond (Scrum meeskond), mis koosneb nii arendajatest kui testijatest, arhitektidest, analüütikutest jne (ideaalse meeskonna suuruseks on 7±2 inimest). Meeskond on ainuke täielikult arendusse kaasatud osaleja ning vastutab tulemuse eest ühtse tervikuna. Mitte keegi teine ​​peale meeskonna ei saa sprindi ajal arendusprotsessi segada.

Iga sprindi käigus luuakse tarkvara funktsionaalne kasv. Igal sprindil tarnitavad funktsioonid pärinevad etapist nimega toodete mahajäämus(töösoovide dokumenteerimine), millel on sooritatavate tööde nõuete taseme osas kõrgeim prioriteet. Töösoovid ( mahajäänud esemed), määratud läbivalt sprindi planeerimisnõukogu (sprindi planeerimise koosolek), viiakse sprindi etappi. Selle koosoleku käigus teavitab tooteomanik ülesandeid, mis tuleb täita. Seejärel määrab meeskond kindlaks, kui palju sellest, mida nad soovivad järgmise sprindi jooksul vajalike osade täitmiseks teha. Sprindi ajal täidab meeskond kindla kindla ülesannete nimekirja (nn. sprindi mahajäämus). Selle aja jooksul ei ole kellelgi õigust muuta töönõuete loetelu, mida tuleks mõista külmutamisnõuetena ( nõuded) sprindi ajal.

Artefaktid

Toodete mahajäämus on dokument, mis sisaldab funktsionaalsusnõuete loendit, mis on järjestatud tähtsuse järgi. Toodete mahajäämus on nimekiri sellest, mida tuleb tarnida. Selle loendi üksusi nimetatakse "lugudeks" ( kasutaja lugu) või mahajäänud elemente ( mahajäänud esemed). Toodete mahajäämus on redigeerimiseks avatud kõigile Scrumi protsessis osalejatele.

Sissejuhatus

Rational Unified Process (RUP) on üks spiraalseid tarkvaraarenduse metoodikaid. Metoodikat toetab Rational Software ning toodet uuendatakse ligikaudu kaks korda aastas. Modelleerimiskeelena sisse ühine alus teadmisi, kasutatakse ühtset modelleerimiskeelt (UML).

Iteratiivne tarkvaraarendus RUP-is hõlmab projekti jagamist mitmeks väikeseks projektiks, mis viiakse läbi järjestikku, ja iga arendusiteratsioon on selgelt määratletud eesmärkide kogumiga, mis tuleb iteratsiooni lõpus saavutada. Lõplik iteratsioon eeldab, et iteratsioonieesmärkide kogum peab täpselt ühtima tootekliendi määratud eesmärkide kogumiga, st kõik nõuded peavad olema täidetud.

RUP on üsna hästi vormistatud ning suurimat tähelepanu pööratakse projekti arendamise algfaasidele – analüüsile ja modelleerimisele. Seega on antud metoodika suunatud äririskide vähendamisele (riskide maandamisele), tuvastades vigu arengu varases staadiumis. Tehnilisi riske hinnatakse ja seatakse prioriteediks arendustsükli varajases staadiumis ning aja jooksul ja projekti arenedes läbi järgnevate iteratsioonide vaadatakse need seejärel üle. Sõltuvalt nende riskide prioriteetidest ilmnevad uued eesmärgid. Versioonide väljalaseid levitatakse nii, et esmajärjekorras käsitletakse kõrgeima prioriteediga riske.

Protsess hõlmab mudelite evolutsiooni; arendustsükli iteratsioon vastab ainulaadselt tarkvaramudeli konkreetsele versioonile. Iga iteratsioon (töövoog) sisaldab tarkvara elutsükli juhtimise elemente: analüüs ja projekteerimine (modelleerimine), juurutamine, integreerimine, testimine, juurutamine. Selles mõttes on RUP spiraalmudeli teostus, kuigi seda kujutatakse sageli tabeligraafikuna. Allpool tutvustame protsessi põhikomponente.

Sest edukas protsess Arenduseks on vaja kolme komponenti (joonis 1): protsess, tähistus ja utiliitide komplekt. Protsess kirjeldab, mida me teeme, mis järjekorras ja mil viisil; märkimine on suhtlusvahend; utiliitide komplekt aitab protsessi automatiseerida ja hallata.

Riis. 1. Edu kolmnurk

RUP sisaldab kõiki kolme komponenti. Kõigepealt vaatame tähistusfunktsioone, mis teevad järgmist.

"Liimib" protsessi ühtseks tervikuks;

on keelepõhine vahend selliste otsuste tegemiseks, mis lähtekoodist ei ilmne;

Annab semantika oluliste strateegiliste ja taktikaliste otsuste esindamiseks;

Pakub vormi, mis on piisav kajastamiseks ja seejärel otsuste tegemiseks ning vahendid protsessi automatiseerimiseks, et manipuleerida formaliseeritud andmetega.

Tegelikult hõlmab tähistus tarkvaraarendust analüüsist toote juurutamiseni. Märkimine RUP–UML-i puhul on formaalne keeleline vahend protsessi kirjeldamiseks (UML-i käsitletakse allpool). Järgmisena kaalume protsessi ülesehitust ja pakume ka utiliitide komplekti, mida kasutatakse projekti arendamise juhtimise protsessis vastavalt RUP-ile.

RUP struktuur

UP pakub struktureeritud lähenemist iteratiivsele tarkvaraarendusele, jagades protsessi aja jooksul neljaks verstapostiks: algus, väljatöötamine, ehitamine ja üleminek. Kahjuks puudub vene keeles väljakujunenud terminoloogia, mistõttu kasutame edaspidi ingliskeelseid termineid koos nende tõlkega vene keelde. Joonisel fig. Joonisel 2 on laialt kasutatav RUP-faaside kujutis. Kõigi nende etappide eesmärgid on:

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

Viimistletud arusaam, kuidas me seda loome. Nõuete analüüsi ja süsteemi projekteerimise faas, vajalike tegevuste ja ressursside planeerimine, funktsioonide ja disainifunktsioonide täpsustamine;

Toote beetaversiooni ehitusloomine. Arenduse ja kodeerimise põhifaas, toote ülesehitamine iteratsioonide tõusva jadana (koodiversioonid);

Toote lõpliku versiooni ülemineku loomine. Toote tutvustamise faas, toote tarnimine konkreetsele kasutajale.

Riis. 2. RUP faasid

Need on toote evolutsiooni juhtimise etapid – elutsükli iteratsioonid. RUP hõlmab lõpp-eesmärgile lähenemist, kuid erinevalt klassikalisest ISO standardist (juga metoodika), kus üleminek on lõppfaas, saab iga faasi korrata mitu korda, peegeldades muutusi kliendi nõuetes tootele.

RUP metoodika põhineb üheksal peamisel töövool, mis on tarkvara elutsükli iteratsiooni elemendid:

Äri modelleerimine (ärianalüüs) - hõlmab nõuete analüüsimist elutsükli antud iteratsioonil, soovitud süsteemi parameetrite ja kasutajate vajaduste määramist;

Nõuded süsteemipildi vormistamine. Hõlmab nõuete kogumist ja haldamist, nõuete muutmist funktsionaalseteks spetsifikatsioonideks. Siit algab pretsedentide analüüs ja kasutusjuhtude (kasutajalugude) konstrueerimine kasutajanõuete formaalne kaardistamine UML-is. Tulemuseks on juhtimistasandi dokumendid;

Analüüs ja projekteerimine (analüüs ja modelleerimine) – hõlmab kogutud nõuete tõlkimist formaliseeritud tarkvaramudeliks. Tulemuseks on süsteemi kirjeldus juurutamisetapis ( tehniline projekt) on süsteemiarendajate tasandi dokumendid. Formaaliseerimiskeel on ühtne modelleerimiskeel (UML), mida käsitletakse allpool. Iteratiivse arenduse käigus areneb selle konkreetse voo toode – projektimudel. Kõik muudatused RUP-is on otseselt seotud mudelitega ning automatiseerimistööriistad ja üsna paindlik modelleerimiskeel võimaldavad seda protsessi ajaliselt ja ressursse arvestades enam-vähem valutult juhtida. See viitab asjaolule, et arenduse tulemuseks ei ole mudel, vaid käivitatav kood, mistõttu kliendile ei meeldi tavaliselt modelleerimise eest tegelikult maksta, kuna mudelid pole see toode, mida ta vajab);

Rakendamine ( juurutamine, kodeerimine ) – hõlmab tegelikult koodi kirjutamist. RUP-i koodielemendid luuakse juba analüüsi- ja projekteerimisfaasis, kuna UML-i juurutamise tööriist - Rational Rose - võimaldab luua koodielemente mitmes programmeerimiskeeles. Metoodika – objektorienteeritud programmeerimine;

Test hõlmab toote testimist antud iteratsiooniga. Eraldi väärib märkimist, et regressioonitestid (tagastustestid, toote "mitteriknemise" testimine) peaksid sel juhul sisaldama kõiki eelmise iteratsiooni praeguseid teste ja eelmise üleminekufaasi vastuvõtuteste;

Kasutuselevõtt (juurutamine) hõlmab toote paigaldamist kliendi asukohas, personali koolitamist, süsteemi käivitamist pluss vastuvõtutestid, toote pakendamise ja levitamise standardite koostamist, materjalide edastamist müügiosakonda (toimingud on valikulised olenevalt toote spetsiifikast ).

Ülaltoodud elemendid ei ole tarkvaraarenduse elutsükli seisukohalt uued, kuna need esinevad peaaegu igas metoodikas - võib-olla välja arvatud XP (kus need on siiski esitatud väga originaalsel kujul). RUP-i rakendamise tunnuseks on ajaline rõhuasetus, nimelt teatud lõimede iteratsioonide domineerimine, samuti universaalse keele ja utiliitide komplekti olemasolu, mis võimaldab kirjeldada arendusprotsessi. Nagu näeme joonisel fig. 2, toote arendamise algfaasis pööratakse põhitähelepanu projekti vormistamisele (analüüs, modelleerimine), mille eesmärk on vähendada ärilisi riske ja vähendada projekteerimisvigade maksumust. Kui pilt on enam-vähem selge, algab toote tegelik arendus, testimine ja lõpuks ka juurutamine.

Esialgne interna on tegelikult dokumendid, mille on välja andnud ettevõtete juhtide tehniline nõukogu. Algetappide põhieesmärk on lepingu või kavatsuste protokolli sõlmimine. Edasised iteratsioonid on arendusmeeskonna töö tegelik algus, kellel on aega ja ressursse formaalsete mudelite koostamiseks. UML-il on sel juhul tööriistad, mis võimaldavad teil mudeli koodielementidele vastendada. Näiteks kuvatakse otse objektide puud, variatsioonid sõltuvad arendajate valitud programmeerimiskeele realiseerimisvõimsusest, samuti G. Butchi ja selle keele arendajate seisukohtade kokkulangemisest objektimudeli suhtes. . Sama kehtib ka meetodite kohta.

Vaatame nüüd tootetoega seotud elemente – põhilisi toetavaid töövooge:

Konfiguratsioonihaldus (konfiguratsiooni- ja muudatuste haldamine) on võimas tooteversioonide haldamiseks mõeldud haldustoimingute kiht, mis hõlmab lähtekoodi (mudel, käivitatavad moodulid, testid, dokumentatsioon), tooteversiooni juhtimist, ettevõtte koodiarenduse ja dokumentatsiooni standardeid, muudatuste ja vigade jälgimine (vigade jälgimine); tihedalt seotud testimise ja klienditoega;

Juhtimine (projektijuhtimine) - hõlmab projektijuhtimiseks vajalike haldustoimingute kogumit vastavalt RUP-i ideoloogiale, kasutatakse projektijuhtimise tööriistu (vt allpool ratsionaalsete toodete loendit);

Keskkond hõlmab loomist ja hooldamist analüüsivahendid, projekteerimine, arendus, testimine (nii tarkvara kui riistvara).

Iteratiivne arendus;

Nõuete haldamine;

Modulaarsete arhitektuuride kasutamine;

Visuaalne modelleerimine;

Kvaliteedikontroll;

Jälgi muudatusi.

Need tavad ei ole otseselt RUP-i protsessi osa, kuid on väga soovitatavad. Mõned tavad tulenevad otseselt RUP-ideoloogiast. Seega on iteratiivne arendus RUP-i struktuuri sisse ehitatud, kuna see protsess on üks "spiraali" rakendusi. RUP-i nõuete haldamine ilmub analüüsi kõige varasemates etappides. Teoreetiliselt võimaldab modulaarne arhitektuur koodi uuesti kasutada, muutes süsteemi paindlikumaks. Tänu sellele, et UML on objektkeel, on võimalik modulaarsust ignoreerida, aga... see on mõnevõrra keeruline. Visuaalne modelleerimine võimaldab tõhusalt toime tulla süsteemide kasvava keerukusega. Lisaks on mudelid arendajatevahelise suhtluse vahendid, kuid selleks peavad arendajad rääkima UML-i keeles, mis nõuab teatud koolitust. Visuaalset modelleerimist kasutatakse sageli Rational Rose'i tööriista abil, mis võimaldab hankida juhtidele, süsteemiadministraatoritele, arendajatele, testijatele väga kasulikke dokumente ja luua koodielemente. See tööriist ei ole ainus UML-i rakendus – saadaval on nii kaubanduslikud alternatiivid (näiteks Microsoft Visio) kui ka tasuta. Tuleb märkida, et modelleerimisvahendites rakendatud UML-i murded ei ole alati samad: ratsionaalsel murdel on mõned suured erinevused, mida on kirjeldatud nii dokumentatsioonis kui ka UML-i raamatutes.

Tooted, mis toetavad RUP-i

Järgmised on kõige tuntumad tooted, mis toetavad ratsionaalset ühtset protsessi:

Rational Rose CASE visuaalse modelleerimise tööriist infosüsteemid, millel on koodielementide genereerimise võimalus. Toote Rational Rose RealTime eriväljaanne võimaldab teil saada väljundina käivitatava mooduli;

Rational Requisite Pro nõuete haldustööriist, mis võimaldab teil luua, struktureerida, prioritiseerida, jälgida ja juhtida nõuete muudatusi, mis tekivad rakenduse komponentide arendamise mis tahes etapis;

Rational ClearQuest toode muudatuste haldamiseks ja defektide jälgimiseks projektis (vigade jälgimine), mis on tihedalt integreeritud testimis- ja nõuetehaldustööriistadega ning pakub ühtset keskkonda kõigi vigade ja dokumentide omavaheliseks sidumiseks;

Ratsionaalne SoDA toode projekti dokumentatsiooni automaatseks genereerimiseks, mis võimaldab teil määrata sisedokumentidele ettevõtte standardi. Samuti on võimalik viia dokumentatsioon olemasolevatele standarditele (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - testimis- ja silumistööriistad:

Rational Purify on väga võimas käitusaegne vigade otsimise tööriist rakenduste ja komponentide arendajatele, kes programmeerivad C/C++ keeles,

Rational Visual Quantify jõudluse mõõtmise tööriist rakenduste ja komponentide arendajatele programmeerimiseks C/C++, Visual Basic ja Java keeles; aitab tuvastada ja kõrvaldada tarkvara jõudluse kitsaskohti,

Rational Visual PureCoverage – tuvastab automaatselt koodipiirkonnad, mida ei testita;

Rational ClearCase on tarkvara konfiguratsioonihalduse toode (Rational's Software Configuration Management, SCM), mis võimaldab kõikide projektidokumentide versioonikontrolli. Selle abiga saate toetada korraga mitut projekti versiooni, vahetades nende vahel kiiresti. Rational Requisite Pro toetab uuendusi ja jälgib arendusmeeskonna nõuete muudatusi;

SQA TeamTest testimise automatiseerimise tööriist;

Rational TestManager testihaldussüsteem, mis koondab kõik testiga seotud tööriistad, artefaktid, skriptid ja andmed;

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

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

Rational PerformanceStudio – mõõdab ja ennustab süsteemi jõudlusnäitajaid.

Artefaktid ja rollid

RUP-i lahutamatu osa on artefaktid, pretsedendid ja rollid. Artefaktid on mõned projekti tooted, mis luuakse või kasutatakse projektis lõpptoote kallal töötades. Kasutusjuhud on tegevuste jadad, mida süsteem jälgitava tulemuse saavutamiseks teeb. Tegelikult on iga üksikisiku või rühma töö tulemus artefakt, olgu selleks analüüsidokument, mudeli element, koodifail, testskript, vea kirjeldus vms. Teatud spetsialistid vastutavad üht või teist tüüpi artefakti loomise eest. Seega määratleb RUP selgelt iga arendusmeeskonna liikme kohustused ühes või teises etapis ehk millal ja kes peaks selle või teise artefakti looma. Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP-is kui artefaktide loomise protsessi - alates esialgsetest analüüsidokumentidest kuni käivitatavate moodulite, kasutusjuhenditeni jne. Allpool on iga voo artefaktide komplekt (mudelid, dokumendid jne).

Äri modelleerimine

Äriprotsessi mudeli ärinõuete määramine arendatavale süsteemile;

Ettevõtte struktuuri mudel – artefakt süsteemi funktsionaalse mudeli väljatöötamiseks;

Dokumentide mudelid, äriüksused, ärifunktsioonide stsenaariumide mudelid, äriüksuste olekute mudelid - kasutajaliidese, andmebaasisüsteemi kujundamiseks; kujutavad endast süsteemi staatiliste ja dünaamiliste olekute kirjeldust erinevatest vaatenurkadest;

Ärireeglite mudelite artefakti kasutatakse reeglite modelleerimiseks tarkvaras.

Dokumentide artefaktid, mida kasutavad RequisitePro, SoDA, tekstitöötlusprogrammid, Microsofti projekt:

Kliendi organisatsiooni, äristruktuuri hindamine;

Ainevaldkonna terminite sõnastik;

Ärireeglite kogum;

Kommertspakkumine;

Ärifunktsiooni spetsifikatsioonid;

Tööplaan äri modelleerimise etapis;

Muudatustaotlused.

Nõuded

Rational Rose'i kasutatud artefaktimudelid:

Süsteemi funktsiooni mudel;

Süsteemi funktsiooni stsenaariumi mudel;

Kasutajaliidese mudel;

Süsteemi kasutaja stsenaariumide mudel;

Väljundvormide mudel;

Süsteemireeglite mudel.

Nõuete haldamise plaan;

Süsteemiterminite sõnastik;

Spetsifikatsioon jaoks tarkvarasüsteem;

Süsteemi funktsioonide spetsifikatsioon;

Süsteemi reeglid;

Huvirühmade päringud;

Tööplaan süsteeminõuete kindlaksmääramise etapis;

Muudatustaotlused.

Analüüs ja disain

Rational Rose'i kasutatud artefaktimudelid:

Loogiline andmemudel;

Füüsiline andmemudel;

Süsteemi komponentide spetsifikatsioonide mudel;

Süsteemikomponente rakendavate klasside interaktsiooni stsenaariumid.

RequisitePro, SoDA, tekstitöötlusprogrammide ja MS Projecti kasutatavad dokumendiartefaktid:

Tarkvara arhitektuur;

Tarkvarakomponentide spetsifikatsioonid;

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

Muudatustaotlused.

Rakendamine

Rational Rose'i kasutatud artefaktimudelid:

Komponentide rakendusmudel.

Rational Rose'i kasutatud artefaktide kood, programmeerimisvahendid, tekstitöötlusprogrammid:

Koodi genereerimise elemendid pärinevad ettevõttest Rational Rose;

tegelik rakenduse kood;

Dokumentatsioon.

RequisitePro, SoDA, tekstitöötlusprogrammide ja MS Projecti kasutatavad dokumendiartefaktid:

Rakenduse ehitusplaan;

Tööplaan elluviimise etapis.

Test

Rational Rose'i kasutatud artefaktimudelid:

Katsejuhtumi mudel;

Testprogrammi funktsionaalne mudel;

Testprogrammi komponentide spetsifikatsioonimudel;

Testprogrammi komponentide koostoimet rakendavate klasside interaktsiooni stsenaariumid.

Katsejuhtumite kirjeldus;

katseplaan;

testimisetapi tööplaan;

Muudatustaotlused.

Testimisrakenduse kvantifitseerimine, puhastamine, PureCoverage, Robot, SiteLoad, SiteCheck.

Kasutuselevõtt

Rational Rose'i kasutatud artefaktimudelid:

Komponentide paigutuse mudeli kirjeldus töötlemissõlmedesse.

SoDA, tekstitöötlusprogrammide, MS Projecti kasutatavad dokumendiartefaktid:

Õppematerjalid;

Paigaldusdokumendid;

Süsteemi versioonide kirjeldus;

Rakendusplaan.

Selle seeria järgmine artikkel on pühendatud ühtsele modelleerimiskeelele (UML).