Ühtne tarkvara arendusprotsess. Ühtne arendusprotsess ja äärmuslik programmeerimine

Vastavalt standardile GOST 34.601-90 “AS. Loomise etapid" kehtestab järgmised AIS-i loomise etapid, mille saab omakorda jagada etappideks:

· nõuete kujundamine AISile;

· AISi kontseptsiooni väljatöötamine;

· tehniline ülesanne;

· eelprojekt;

· tehniline projekt;

· töödokumentatsioon;

· kasutuselevõtt.

Igal etapil on oma projekteerimisdokumentatsioon ning süsteemi tehniliste ja tarkvaramoodulite juurutamine. Praktika näitab, et süsteemi loomise protsess on iteratiivne ja inkrementaalne. UML-i autorid rõhutavad seda mõistet määratledes ühtne tarkvara ja teabe arendusprotsess. Kuigi esimeses etapis moodustatakse AS-ile kui tervikule esitatav nõuete kogum, on see tegelikult alguses alati puudulik ja selgitatakse järgmistes etappides. ma pean tegema iteratsioonid st korrake üksikuid samme ja etappe kas täielikult või osaliselt. Lisaks on reaalne süsteem multifunktsionaalne ja keeruline, seetõttu jagatakse see tavaliselt alamsüsteemideks ja eraldi ülesannete kogumiteks, eristades esimese, teise jne alamsüsteeme ja ülesandeid. Süsteem on loomisel järk-järgult, funktsionaalsuse järkjärgulise suurendamise kaudu, asendades esialgsed disainilahendused rohkem arenenud lahendustega, mis vastavad paremini kasutajate nõudmistele. See vähendab finantsriske ning säästab aega ja ressursikulu loomise lõppfaasis.

UML-i metoodika kasutamisel AIS-i tarkvara ja teabetoe loomiseks tehakse ettepanek luua omavahel ühendatud mudelite komplekt, mis kajastaks tulevase süsteemi staatilisi ja dünaamilisi omadusi:

· kasutusjuhtumi mudel;

· analüüsimudel;

· disainimudel;

· kasutuselevõtu mudel;

· teostusmudel;

· mudeli testimine.

Kasutage juhtumimudelit sisaldab kasutusjuhtude diagramme ja vastavaid stsenaariume, kirjeldab süsteemi funktsionaalseid nõudeid ja selle käitumist kasutajatega suhtlemisel.

Analüüsi mudel sisaldab üldisi klassiskeeme loogilise taseme kasutusjuhtude, seotud jadaskeemide ja/või koostöödiagrammide rakendamiseks ning on visand selle kohta, kuidas loogilisel tasemel kasutusjuhtumeid rakendatakse.

Disaini mudel on analüüsimudeli füüsilise teostuse detailne esitus ja sisaldab pakett- (allsüsteemi) diagramme, üksikasjalikke klassiskeeme, järjestusskeeme ja/või koostööskeeme, olekuskeeme, erineva detailsusastmega tegevusskeeme.

Kasutuselevõtu mudel sisaldab esialgseid juurutusskeeme, mis määratlevad kõik võrgukonfiguratsioonid, milles süsteem võib töötada. Juurutusskeemid näitavad võrgusõlmi, ühenduse tüüpe ja aktiivsete süsteemiklasside jaotust sõlmede vahel.

Rakendusmudel kirjeldab, kuidas disainiklasse komponentidena realiseeritakse. Sellest lähtuvalt sisaldab see komponentide diagramme, klasside (rakenduse) jälgi, üksikasjalikke juurutusskeeme ja süsteemi arhitektuuri kirjeldust.

Testmudel sisaldab testjuhtumite komplekti, testimisprotseduure ja testikomponentide kirjeldusi. See määrab käivitatavate süsteemikomponentide testimise meetodid.

Võrdleme mudelite ehitamise protsesse AS-i loomise standardiseeritud etappidega. Kasutusjuhtumi mudel on üles ehitatud AS-i nõuete kujundamise etapis; analüüsimudel on AS-i kontseptsiooni väljatöötamise staadiumis. Tehniliste kirjelduste ja eelprojekti staadiumis ehitatakse projekteerimismudel. Seda täiustatakse tehnilise projekteerimise etapis ja seda täiendatakse kasutuselevõtumudeliga. Töödokumentatsiooni etapis luuakse juurutus- ja testimismudelid. Lõpuks, kasutuselevõtu etapis, testimismudel viimistletakse ja sellest saab töötamise ajal etalonmudel, mis on ette nähtud süsteemi õige toimimise ja diagnostika perioodiliseks kontrollimiseks.

1.5 UML keele komponendid

Unified Modeling Language UML(Unified Modeling Language) on visuaalne modelleerimiskeel, mida kasutatakse objektorienteeritud tehnoloogia abil keerukate süsteemide (sh tarkvara) täpsustamiseks, visualiseerimiseks, konfigureerimiseks ja dokumenteerimiseks.

UML-i metoodikas AS-i loomisel kasutatakse Hein/Sarsoni ja SADT metoodikast tuntud struktuurisüsteemi analüüsi põhimõtteid:

· ülalt-alla järkjärguline arendus;

· diagrammitehnika;

· kirjelduste hierarhia;

· projektlahenduste kirjelduse range vormistamine;

· projekti esialgne arendamine loogilisel tasemel ilma tehnilise teostuse üksikasjadeta;

· kontseptuaalne modelleerimine ainevaldkonnas, et klient mõistaks süsteemi ülesehitust;

· tehnoloogiline tugi tööriistadega (CASE süsteemid).

UML-i keeruka süsteemi mudelit saab uurida, et saada süsteemi protsesside efektiivsuse hinnangulisi omadusi.

AS-i tarkvara juurutamise, juurutamise ja testimise ning UML-i teabetoe mudeleid saab kasutada rakendusprojektina koos järgneva rakenduskoodi automaatse genereerimisega ühes valitud programmeerimiskeskkonnas.

Kompleksse süsteemi üsna täielik mudel peaks kajastama kahte aspekti:

-staatiline(struktuurne) – koostis, komponentide struktuur ja nende seosed;

-dünaamiline(käitumuslik) – süsteemis toimuvate või rakendatavate protsesside loogika kirjeldus.

UML-is kasutusele võetud mudelite esitusmeetodiks on põhilised diagrammid, mis on varustatud tekstilise teabega, sealhulgas sisseehitatud piirangukeeles OCL, aga ka süsteemi juurutamiseks kasutatavates programmeerimis- ja teabepäringukeeltes.

Modelleerimise põhiprintsiip: süsteem modelleeritakse diskreetsete objektide rühmana, mis suhtlevad üksteisega nii, et rahuldatakse kasutaja nõudmisi.

Staatiline mudel määrab struktuuri, objektide tüübid ja objektidevahelised seosed. Dünaamiline mudel määrab objektide käitumise ajas (objektide ajaloo) ja nende vastasmõju.

Põhimõtteliselt on UML diskreetne modelleerimiskeel, see tähendab, et see sisaldab diskreetsete sündmuste ja olekumuutuste kontseptsiooni. Pidevaid protsesse modelleeritakse ligikaudu diskretiseerimise teel.

Mudelil on kaks aspekti: semantiline informatsioon (semantika) ja visuaalne esitus (notatsioon).

UML-keele mudeliesitluste täielik koosseis on toodud tabelis 1

Tabel 1 – Süsteemimudelite esitus UML-is.

MUDEL SKEEM KOMPONENDID
Kontseptuaalne tase Kasuta juhtumimudelit Loogika tase Analüüsimudel Disainimudel Füüsiline kiht Kasutuselevõtu mudel Kasutusjuhtude diagramm Analüüsipaketi diagramm Disaini paketi diagramm Analüüsi klassi diagramm Disaini klassidiagramm Olekudiagramm Tegevusdiagramm ( tegevusskeem Järjediagramm Koostööskeem Kasutusskeem Kasutusjuhtum Aktant (toimija) Seos (ühendus, seos, seos) Roll (roll seoses, roll) Stsenaarium (stsenaarium) Pakett (pakett) Mudel (mudel) Süsteem (süsteem) Allsüsteem ( alamsüsteem) Sõltuvusseos Jälgimisklassi objekti atribuudi toimimine Operatsiooni sõltuvussuhe Seos Agregatsioon Kompositsiooni koostis) Üldistus Jälg (jälg) Rakendus (teostus) Olek (olek) Sündmus (sündmus) Üleminek (üleminek) Toiming (tegevus) Tegevuse olek (tegevuse olek) Sündmus (sündmus) Üleminek (üleminek) Tegevus (tegevus) ) Tegevus ( tegevus Fork Merge Objekti teade Aktiveerimine Eluliini ujumisrada Objekti rolli sõnum (sõnum) Sõlm (rakendussõlm, sõlm) Komponent (komponent) Objekt (objekt) Sõltuvus (sõltuvussuhe)
Rakendusmudel Testimudel Teostusklassi diagramm Komponentide diagramm Seos Asukoht Pakett Süsteemi alamsüsteem Klass Klass Objekti atribuut Meetod Meetod Sõltuvus Seos ) Agregatsioon Koostis Üldistus Teostuskomponent Testkomponent Liides Sõltuvussuhe Realiseerimissuhe

Süsteemi kõige levinum kontseptuaalne mudel on kasutusjuhtude diagramm, see on lähtepunkt muude diagrammide koostamisel.

Kõik keelediagrammid on eritüüpi graafikud, mis sisaldavad servadega (kaaredega) ühendatud tippe (geomeetrilisi kujundeid). Tavaliselt ei ole pildi mastaap ja tippude asukoht eriti oluline, samas jadadiagrammis tuuakse ajatelg sisse ja seal on see oluline.

Seoseid tähistavad tasapinnal erinevad jooned, jooniste sisse on kirjutatud tekst, tippude ja ühenduste läheduses saab kujutada mõningaid graafilisi sümboleid. UML-i laiendused võimaldavad ruumidiagramme.

Keelel on 4 tüüpi graafilisi struktuure:

· ikoonid (piktogrammid);

· graafilised sümbolid tasapinnal;

· teed (jooned);

· tekstiread.

1.6 Kontseptuaalne tase. Kasutage juhtumimudelit

Üldiselt toimub objektorienteeritud projekteerimisprotsess vastavalt struktuurisüsteemide analüüsi aluspõhimõtetele: ülalt-alla projekteerimine koos diagrammide hierarhia ehitamisega, mis viib meid järk-järgult tasemelt tasemele: kontseptuaalne – loogiline – füüsiline (rakendamine)

Tipptaseme diagrammi peetakse A. Jacobsoni poolt OOSE-s välja pakutud diagrammiks kasutusjuhtude diagramm süsteemid tervikuna. See on süsteemi esialgne kontseptuaalne esitus ja see on üles ehitatud eesmärgiga:

· määrata modelleeritava ainevaldkonna üldised piirid ja kontekst;

· sõnastada üldised nõuded süsteemi funktsionaalsele käitumisele ja liidesele;

· koostada esmane dokumentatsioon suhtlemiseks arendajate ja klientide – süsteemi kasutajate vahel.

Modelli vaatenurk: süsteemi väliskasutaja. Kasutusjuhtude diagramm sisaldab osalejaid, kasutusjuhtumeid ja seoseid.

Aktant(toimija, väline üksus, tegutseja) – süsteemi, alamsüsteemi või klassiga vahetult suhtlevate sõnumiallikate/vastuvõtjate klassi abstraktne kirjeldus. See on kirjeldus rollid mida mängib kasutaja (isik või muu süsteem, alamsüsteem, klass) süsteemiga suhtlemise ajal. Põhimõtteliselt on see sarnaste teabepäringute üldistamine süsteemile, mis nõuavad teatud teavet teenus(teenused).

Aktant ei pea tingimata olema samastatud konkreetse indiviidi või seadmega, kuigi mõnikord on see põhimõtteliselt võimalik, kui nad täidavad ainult ühte rolli. Enamasti – füüsiliselt – on tegemist erinevate inimeste ja seadmetega, kes pääsevad süsteemi sama teenuse saamiseks. Kõrgeimal tasemel võivad aktandid olla näiteks operaator, süsteemiadministraator, andmebaasi administraator, tavakasutaja või mõni seadmete klass.

Kõik võimalikud aktandid ammendavad kõik võimalikud viisid kasutaja suhtlemiseks süsteemiga (alamsüsteem, klass). Süsteemi juurutamisel kehastuvad aktandid inimestes ja füüsilistes objektides. Üks inimene või füüsiline objekt võib olenevalt interaktsiooni viisist esindada mitut aktanti (erinevaid rolle). Näiteks võib sama isik olla operaator ja andmebaasi administraator, müüja ja ostja jne.

Paljudes AS-is pole peale inimeste teisi näitlejaid. Kuid aktandid võivad olla väline süsteem, I/O-seade või taimer (seda leidub tavaliselt manustatud reaalajasüsteemides). Kasutusjuhtumi aktantide hulgast torkab silma üks põhiaktant(esmane tegutseja), mis käivitab töö süsteemiga. Ülejäänud on teisejärgulised, nemadki osalevad kasutusjuhtumis, saades tulemusi ja sisestades mingeid vaheandmeid.

Loogilisel ja füüsilisel tasandil esindavad aktante klassid ja objektid, mis on klasside eksemplarid. On võimalik üles ehitada aktantide hierarhia, mis pärib kõik rollid ja suhted, atribuudid ja operatsioonid, mis esivanemal on. Lapse aktandi esinemist saab alati kasutada süsteemis, kus on deklareeritud esivanema aktandi kasutamine (asenduspõhimõte).

Aktanti saab diagrammidel kujutada kahel viisil:

3. Klassi sümbol (ristkülik) stereotüübi sisemise tähisega

Klient

4. Standardsem: “mees” koos pealdisega (isiku sümbol)

Aktant asub süsteemist väljas ja selle sisemine struktuur pole määratud. See on sõnumite allikas/vastuvõtja.

Klient

Kasutusjuhtum(pretsedent, kasutusjuhtum) – teenuseklassi (teenindusfunktsioonide) abstraktne kirjeldus, mis antakse aktandile vastuseks tema taotlustele.

Teenust võib pakkuda süsteem tervikuna, alamsüsteem või klass. Seega tähendab kasutusjuhtum süsteemi funktsionaalsuse või käitumise mingi osa modelleerimist. Kasutusjuhtumil on nimi ja see tähendab teatud toimingute jada, mis on nähtav välisele allikale/vastuvõtjale (aktant). Võimaluse sisemine viis on peidetud ja paljastatud madalamal detailsusastmel. koostöö diagramm. Nagu igal klassil, on ka kasutusjuhul atribuudid ja toimingud, mille rakendamine avaldatakse füüsilisel kihil.

Kasutusjuhtum hõlmab kogu sõnumite jada, mida aktant alustab ja lõpetab süsteemiga (alamsüsteem, klass). Seetõttu on igal kasutusjuhu juurutuse eksemplaril alati algus ajas ja lõpp, kui ükski toimija selle valiku jaoks sõnumeid ei saada. Siia kuuluvad ka veateated, hooldusfunktsiooni teostamise võimalused erinevate seadistustega (alternatiividega).

Kasutusjuhtumi eksemplar on kasutusjuhtumi täitmine, mis algab pärast seda, kui on esmalt saanud teade aktiivselt eksemplarilt. Vastuseks antud sõnumile teostab kasutusjuht teatud toimingute jada, näiteks saadab sõnumi aktandi teistele eksemplaridele (mitte ainult algatajale). Need aktandid saadavad omakorda sõnumeid sellele kasutusjuhtumi eksemplarile ja suhtlus jätkub seni, kuni selliseid sõnumeid enam vastu ei võeta. See tähistab kasutusjuhtumi lõppu.

Näidatakse aktandi ja kasutusjuhtumi suhet assotsiatsioon.

Diagramm kujutab kasutusjuhtu kahel viisil:

1) ellips, selle sisse pannakse nimi


2) ristkülik - nagu iga klass


Klient


Andur

Aktantide ja kasutusjuhtude vahel on seos ainsaks ühenduse tüübiks. Lisaks on sellel semantika side vahetamine, st sõnumi edastamist, tavaliselt ei märgistata, kuna kontekst on aktandi ja kasutusjuhtude tähistusest selge. Kuid saate selle märkida ja näidata ka ühenduse paljusust:


Panga klient

Paljusus(multiplicity) iseloomustab antud ühenduses osaleva klassi konkreetsete esinemisjuhtude arvu (üks klient võib väljastada piiramatul arvul laene).

Üldiselt assotsiatsioon on seos kahe või enama mudelikomponendi vahel. Kuna enamikul juhtudel on komponendid mingid objektide klassid, on seose eksemplar lihtsalt järjestatud loend konkreetsetele eksemplaridele viidetest, mis võib olla varustatud seose atribuutidega (omadustega).

Ühenduse nimi, kui see on olemas, peab olema kordumatu. See moodustub vastavalt ühenduses osalevate klasside vaheliste suhete tähendusele. Näiteks "Töötaja töötab sisse Osakond“, „Juhataja lõpetab Arvuti” jne.

Ühendused on ise klassid ( ühingu klass, assotsiatsiooniklass), sellel on nii klassi kui ka assotsiatsiooni omadused. Selle klassi eksemplarid on ühendused, millel pole mitte ainult linke objektidele, vaid ka atribuutide (omaduste) väärtusi.

Ühingu liikmeid nimetatakse selleks poolused. Kõik poolused on ühendusega seotud klasside rollid, need on erinevad ja neid saab loetleda mõnes järjestatud loendis. Enamasti on seosed binaarsed (kaks rolli teatud semantikaga ühenduses), kuid võib esineda ka n -ary. Üks ja sama klass võib tegutseda erinevates rollides ehk olla samaaegselt ühenduse kahes pooluses.

Ühenduste paljusus on näidatud pooluste juures.

Ühendused võivad tekkida ja kaduda süsteemi töö käigus piiranguid ja vastavaid predikaate saab määrata ühenduse poolustel.

Mõnikord muutub ühendus ainult ühel poolusel. Kui lingil on atribuute, saab neid operatsioonidega muuta, kuid lingid lingis osalejatele ei muutu.

Ühendus on kujutatud pideva joonena, mis ühendab 2 klassi piire n-ary, siis joonistatakse romb (liitumise märk):

Paljud ühendused - liitmine
Binaarne assotsiatsioon

Kasutusjuhtumid ei vaheta üksteisega sõnumeid ja võivad olla ainult suhetes (ühendustes) laiendused(pikendama) kaasamine(kaasa arvatud) ja üldistused(üldistamine).

IN laienemise osas kasutusjuhtum – klient tutvustab täiendavat tegevuste jada, alustades mõnest põhijärjestuse punktist ja selliseid “sisestusi” võib olla mitu. Kõiki neid punkte nimetatakse laienduspunktid.

  • II. Õppeainete õppeprotsessi REGULEERIV ÕIGUSLIK TUGI

  • Rational Unified Process (RUP) on üks parimaid tarkvaraarenduse metoodikaid, mille on loonud Rational Software. Tuginedes paljude edukate tarkvaraprojektide kogemusele, võimaldab Unified Process luua keerukaid tarkvarasüsteeme, mis põhinevad tööstuslikul arendusmeetodil. Üks peamisi tugisambaid, millele RUP tugineb, on mudelite loomise protsess UML (Unified Modeling Language) abil. See artikkel räägib UML-diagrammide kasutamisest tarkvarasüsteemide arendamise töövoos, kasutades Rational Software metoodikat.

    Pole saladus, et tarkvara loomine on keeruline protsess, millel on ühest küljest palju ühist loovusega, ja teisest küljest, kuigi see on väga tulus, on see ka kõrge kuluga äri. Tugev konkurents turul sunnib arendajaid otsima tõhusamaid töömeetodeid. Võimalused tarkvarasüsteemide loomiseks veelgi kiirema ajaga, madalamate kuludega ja parema kvaliteediga. Programmide keerukus kasvab pidevalt. Kuni viimase ajani said tarkvaratooteid ettenähtava aja jooksul luua üksikisikud või näiteks automatiseeritud ettevõtte IT-osakonnas.

    Tänapäeval on põlvili programme loovatele inimestele jäetud väikeste utiliitide ja erinevate laiendusmoodulite ala “raskete” tarkvaratoodete jaoks. Tulevik kuulub tarkvara loomise tööstuslikule lähenemisele. 1913. aastal käivitas Henry Ford esimese autode koosteliini ja 90ndatel hakati sarnast koosteliini kasutama 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 välja andnud struktureeritud teadmistebaasi nimega Rational Unified Process (RUP), mis sisaldab põhjalikke soovitusi peaaegu iga tarkvaratoote loomiseks. Parimate arenduste kogemuse ammutanud RUP räägib üksikasjalikult, millal, kes ja mida peaks projektis tegema, et õigeaegselt, teatud funktsionaalsusega ja ette nähtud eelarve piires tarkvarasüsteem valmis saaks.

    Ühtset protsessi võib käsitleda kui arendusettevõtte erinevate tegevuste summat, mis on vajalik kliendi nõuete tõlkimiseks tarkvarasüsteemi. Süsteem, mis annaks kasutajatele "tähenduslikke tulemusi" ja teeks täpselt seda, mida nad süsteemilt ootavad. Seetõttu juhivad protsessi süsteemi kasutusjuhtumid või muidu pretsedendid.

    Kliendi nõuete õigeaegseks rakendamiseks on ühtne protsess jagatud faasideks, mis koosnevad iteratsioonidest, mistõttu protsessi nimetatakse ka iteratiivseks ja inkrementaalseks. Iga iteratsioon läbib põhitöö tsükli ja viib arendajad lõppeesmärgini: tarkvarasüsteemi loomiseni. Iteratsioonide käigus luuakse vahepealsed artefaktid, mis on vajalikud projekti edukaks lõpuleviimiseks ja tarkvarasüsteemi versioon, mis realiseerib teatud funktsioonide komplekti, mis iteratsioonist iteratsioonini suureneb. Protsessi etapid ja peamised töövood on näidatud joonisel fig. 1 on seal toodud ka tööde orienteeruvad tööjõukulud faaside kaupa.

    riis. 1 RUP faasid ja töövood

    Tuleb märkida, et joonisel fig. 1 näitab ainult ühtse protsessi põhitööd. Näiteks ei kuvata siin tegevuste juhtimise tegevusi, et vältida diagrammi segadust.

    Kogu tarkvaraarendust käsitletakse RUP-is kui artefaktide loomise protsessi. Projekti mis tahes tulemus, olgu selleks siis lähtekoodid, objektimoodulid, kasutajale edastatud dokumendid, mudelid – need on kõigi projekti artefaktide alamklassid. Iga projektimeeskonna liige loob ise oma artefakte ja vastutab nende eest. Programmeerija koostab programmi, juht projektiplaani ja analüütik süsteemimudeli. RUP võimaldab teil määrata, millal, kes ja millist artefakti tuleb luua, muuta või kasutada.

    Üks huvitavamaid projektiartefaktide klasse on mudelid, mis võimaldavad arendajatel tarkvarasüsteemi artefakte määratleda, visualiseerida, konstrueerida ja dokumenteerida. Iga mudel kujutab endast eraldiseisvat vaadet arendatavale süsteemile ja on mõeldud nii probleemide visandamiseks kui ka lahenduste väljapakkumiseks. Mudelite iseseisvus tähendab seda, et analüütik või arendaja saab kogu vajaliku informatsiooni konkreetsest mudelist ilma muude allikate poole pöördumata.

    Mudelid võimaldavad teil mõelda tulevasele süsteemile, selle objektidele ja nende koostoimele juba enne märkimisväärsete rahaliste vahendite investeerimist arendusse, need võimaldavad teil näha seda tulevaste kasutajate silmade läbi väljastpoolt ja arendajate silmadega seestpoolt juba enne lähtekoodi esimest rida; on loodud. Enamik mudeleid on kujutatud UML-i diagrammidega, mida saate lugeda näiteks UMLi kohta.

    Ühtne modelleerimiskeel ilmus 80ndate lõpus ja 90ndate alguses, peamiselt tänu "kolme sõbra" Gradi Bucha, Jim Rambo ja Ivar Jacobsoni pingutustele. Nüüd on OMG konsortsium selle kasutusele võtnud standardse modelleerimiskeelena, mis pakub arendajatele selget tähistust, mis võimaldab mudeleid kuvada graafilistes elementides, mis on üldiselt aktsepteeritud ja kõigile projektis osalejatele arusaadavad.

    Siiski ei tasu unustada, et modelleerimiskeel pakub ainult tähistust – süsteemi kirjeldamise ja modelleerimise vahendit ning ühtne protsess määrab selle tööriista kasutamise metoodika, aga ka teised Rationali metoodikat toetavad tööriistad. UML-i saab kasutada ilma konkreetse metoodikata, kuna see on protsessist sõltumatu ning olenemata sellest, millist protsessi valikut kasutatakse, saate diagrammide abil dokumenteerida arenduse käigus tehtud otsuseid ja kuvada loodud mudeleid.

    Tarkvarasüsteem luuakse konkreetsete kasutajaprobleemide lahendamiseks, mitte programmeerijatele, kes testivad uusi tehnoloogiaid ja omandavad kogemusi projektijuhile. Üldjoontes ei huvita kasutajat, kas kasutate arendusprotsessis objektorienteeritud lähenemist, UML-i, RUP-i või loote süsteemi XP (äärmusliku programmeerimise) meetodil. Teatud meetodite, tehnoloogiate kasutamine ja projekti optimaalse sisemise struktuuri loomine jääb arendajate südametunnistusele, kes langetavad otsuseid varasemast kogemusest ja oma eelistustest lähtuvalt. Siiski ei andesta kasutaja teile tema nõuete eiramist. Isegi kui tarkvarasüsteemi arendatakse kümme korda tipptasemel meetodeid ja tehnoloogiaid kasutades, siis kui kasutaja ei saa sellest nn "tähenduslikku tulemust", kukub teie tarkvaraprojekt haledalt läbi.

    Siit järeldub, et UML-i mõtlematu rakendamine pelgalt moes olemise tõttu mitte ainult ei vii arengut eduni, vaid võib tekitada rahulolematust töötajates, kellel on vaja palju lisakirjandust uurida, ja projektijuhtides, kui selgub, et projekti tööjõukulud suurenevad ja tulu ei suurene. Peate selgelt mõistma, mida soovite selle tehnoloogia rakendamisega saada, ja järgima seda eesmärki. UML-i kasutamine säästab arendusressursse, sest võimaldab süsteemist kiiremini aimu saada kui makettide ja prototüüpide loomisel, kulutades võrreldamatult vähem ressursse.

    Diagrammid hõlbustavad projektiliikmetel omavahelist suhtlemist ja, mis on eriti väärtuslik, kaasavad protsessi lõppkasutajaid. Modelleerimine võimaldab teil projekti riske vähendada, kuna programmeerijatel on alati lihtsam teha seda, mis on selge ja arusaadav, kui minna ebakindla tulemuseni. Diagrammide koostamine sarnaneb projekti loomisega ehituses - saate ilma selleta hakkama näiteks suvilale kuuri ehitamisel, kuid mida suurem on hoone (meie puhul tarkvaratoode), seda keerulisem on see teha ja seda ebakindlam on lõpptulemus.

    Õpetasin kunagi RUP-teemalist seminari ühes tarkvarafirmas, mis oli kümme aastat turul üsna edukas olnud, kuid ei kasutanud oma töövoos üldse modelleerimist, vaid põhines prototüüpidel. Saali kogunes paarkümmend noort ja kogenud programmeerijat, kes kuulasid hoolega kõike, mida ma neile RUP-i ja UML-i kohta rääkisin. Ja üks neist, vaadates näidisskeemidega kaetud tahvlit, märkis: "See kõik on huvitav ja ilmselt sobib ka teistele projektidele," ütles ta, "aga me oleme ilma selle kõigeta töötanud üsna pikka aega, kuna oleme siiski saime ilma UML-ita hakkama, ilmselt pole meil seda vaja."

    See küsimus pani mind mõtlema, et äriprotsesside muutus, mis tarkvaraarendusettevõttes RUP-i ja UML-i juurutamisel paratamatult toimuma peab, võib olla sama raske kui infosüsteemi juurutamine tööstusettevõttes. Igasugune juurutamine on stereotüüpide murdmine. Kuna tarkvaraarendusettevõtte töötajate kvalifikatsioon on üsna kõrge, on sellistel inimestel raskem oma seisukohtadest loobuda kui "lihtsurelikel" ning tekkivaid raskusi ja tagasilükkamist võib võrrelda üleminekuga protseduuriliselt objektilt. orienteeritud mõtlemine.

    1.Nõuete määratlemine

    Ühtne protsess on protsess, mida juhivad kasutusjuhtumid, mis kajastavad kasutaja interaktsiooni stsenaariume. Tegelikult on see kasutajate vaade tarkvarasüsteemile väljastpoolt. Seega saab RUP-i hinnangul üheks olulisemaks arendusetapiks nõuete määramise etapp, mis seisneb kõigi võimalike süsteemi toimimise soovide kogumises, mis võivad vaid kasutajatele ja analüütikutele pähe tulla. Hiljem tuleb need andmed süstematiseerida ja struktureerida, kuid praeguses etapis peavad analüütikud kasutajatega küsitledes ja dokumente uurides koguma tulevasele süsteemile võimalikult palju nõudeid, mis polegi nii lihtne, kui esmapilgul tundub. Kasutajatel pole sageli aimugi, mida nad lõpuks saama peaksid. Selle protsessi hõlbustamiseks kasutavad analüütikud kasutusjuhtude diagramme (joonis 2).

    Joonis 2. Kasutusjuhtumi diagrammi näide

    Diagramm peegeldab osalejaid (aktante), kes süsteemiga suhtlevad, ja tarkvaraobjektide reaktsiooni nende tegevusele. Tegutsejad võivad olla nii kasutajad kui ka välisagendid, kes peavad infot edastama või vastu võtma. Kasutusjuhtumi ikoon peegeldab süsteemi reaktsiooni välisele sisendile ja näitab, mida tuleb aktandi heaks teha.

    Konkreetse kasutusjuhtumi üksikasjalikuks kirjeldamiseks kasutatakse tegevusskeemi, mille näide on toodud joonisel 3.

    riis. 3 Tegevusdiagrammi näide

    Kasutusjuhtumite diagrammi lihtsus võimaldab analüütikutel nõuete määratlemise protsessi ajal klientidega hõlpsasti suhelda, tuvastades süsteemile ja individuaalsete nõuete rakendamisele seatud piirangud, nagu süsteemi reageerimisaeg, mis hiljem langevad mittefunktsionaalsete osasse. nõuded.

    Kasutusjuhtumi diagrammi saab kasutada ka katsestsenaariumide loomiseks, kuna kõik kasutajate ja süsteemi vahelised suhtlused on juba määratletud.

    Nõuete õigeks kindlaksmääramiseks peavad arendajad mõistma konteksti (osa ainevaldkonnast), milles tulevane süsteem töötab. Selleks luuakse domeenimudel ja ärimudel, mis on erinevad lähenemised samale probleemile. 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 omavahelisi seoseid. Kusjuures ärimudel kirjeldab äriprotsesse (olemasolevaid või tulevasi), mida süsteem peaks toetama. Seetõttu määratleb see mudel lisaks protsessi kaasatud äriobjektide määratlemisele töötajad, nende kohustused ja toimingud, mida nad peavad tegema.

    Domeenimudeli koostamiseks kasutatakse tavalist klassidiagrammi (joonis 6), kuid ärimudeli koostamiseks sellest selgelt ei piisa. Sel juhul kasutatakse kasutusjuhtude diagrammi, kasutades täiendavaid ikoone, mis kajastavad äriprotsesside olemust – need on äriaktant, ärikasutusjuht, äriüksus ja ärijuhtimine. See mudel on palju lähemal järgmisele arendusprotsessis loodud mudelile – analüüsimudelile.

    2.Analüüs

    Pärast nõuete ja konteksti kindlaksmääramist, milles süsteem töötab, on aeg analüüsida saadud andmeid. Analüüsiprotsessi käigus luuakse analüütiline mudel, mis juhatab arendajad tulevase süsteemi arhitektuuri juurde. Analüütiline mudel on vaade süsteemile seestpoolt, erinevalt kasutusjuhtumi mudelist, 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 sellel peaksid olema ja kuidas need peaksid üksteisega suhtlema. Selle põhieesmärk on määrata kindlaks nõuete kogumise etapis tuvastatud funktsionaalsuse rakendamise suund ja visandada süsteemi arhitektuur.

    Erinevalt hiljem loodavast disainimudelist on analüüsimudel pigem kontseptuaalne mudel ja toob arendajaid juurutusklassidele vaid lähemale. Sellel mudelil ei tohiks olla võimalikke vastuolusid, mis võivad esineda pretsedendimudelis.

    Analüüsimudeli kuvamiseks UML-i abil kasutatakse klassidiagrammi stereotüüpidega (käitumismustritega) “piirklass”, “üksus”, “kontroll” ning detailiseerimiseks kasutatakse koostööskeeme (joonis 4). "Piiriklassi" stereotüüp kujutab klassi, mis suhtleb väliste aktantidega, "olemi" stereotüüp kujutab klasse, mis on andmehoidlad, ja "kontroll" stereotüüp kujutab klasse, mis haldavad olemitele päringuid.

    Joonis 4. Koostööskeemi näide

    Sõnumite nummerdamine näitab nende järjekorda, kuid diagrammi eesmärk ei ole mitte arvestada vahetatavate sõnumite järjekorda, vaid selgelt näidata klasside omavahelisi seoseid.

    Kui keskenduda interaktsiooni järjekorrale, siis teiseks esituseks oleks järjestusskeem (Sequence), mis on näidatud joonisel 5. See diagramm võimaldab vaadelda sõnumite vahetamist ajas, kuvades visuaalselt protsessi jada. Kui kasutate mudeli loomise tööriista nagu Rational Rose, saab neid kahte tüüpi diagramme üksteisest automaatselt luua (Rational Rose'i kohta saate näiteks lugeda lähemalt).

    Riis. 5 Jada diagrammi näide

    Otsus, kumb kahest diagrammist esimesena luua, sõltub konkreetse arendaja eelistustest. Kuna need diagrammid kujutavad endast sama protsessi, võimaldavad need mõlemad kajastada objektide vahelist koostoimet.

    3.Disain

    Süsteemi loomise protsessi järgmine etapp on projekteerimine, mille käigus luuakse varem loodud mudelite põhjal disainimudel. See mudel kajastab süsteemi füüsilist teostust ja kirjeldab loodud toodet klassi ja komponendi tasemel. Erinevalt analüüsimudelist on disainimudelil selge sõltuvus rakendustingimustest, programmeerimiskeeltest ja kasutatud komponentidest. Süsteemi arhitektuuri võimalikult täpseks mõistmiseks peaks see mudel olema võimalikult formaliseeritud ja ajakohastatud kogu süsteemi arenduse elutsükli vältel.

    Disainimudeli koostamiseks kasutatakse tervet komplekti UML diagramme: klassiskeeme (joon. 5), koostöödiagramme, interaktsiooniskeeme, tegevusskeeme.

    Joonis 6. Klassiskeemi näide

    Lisaks saab selle töövooga luua juurutusmudeli, mida rakendatakse juurutusskeemi alusel. See on lihtsaim diagrammitüüp, mis on loodud seadmete võrgus levitamise modelleerimiseks. Kuvamiseks kasutatakse protsessori ja seadme ikoonide jaoks ainult kahte valikut ning nendevahelisi ühendusi.

    4.Rakendamine

    Rakendusprotsessi põhiülesanne on süsteemi loomine komponentide kujul - programmi lähtekoodid, skriptid, binaarfailid, käivitatavad moodulid jne. Selles etapis luuakse rakendusmudel, mis kirjeldab, kuidas kujundusmudeli elemente realiseeritakse, millised klassid kaasatakse konkreetsetesse komponentidesse. See mudel kirjeldab nende komponentide organiseerimise viisi vastavalt valitud programmeerimiskeskkonnas kasutusele võetud struktureerimis- ja modulariseerimismehhanismidele ning on kujutatud komponentide diagrammil (joonis 7).

    riis. 7 Näidiskomponentide diagramm

    5.Testimine

    Testimisprotsessi käigus kontrollitakse juurutamise tulemusi. Selle protsessi jaoks luuakse testimismudel, mis koosneb testjuhtumitest, testimisprotseduuridest, testikomponentidest, kuid millel puudub UML diagrammi esitus, seega me sellel pikemalt ei peatu.

    6.Järeldus

    Siin käsitleti ainult ratsionaalse metoodika põhiprotsesse. RUP on üsna mahukas ja sisaldab soovitusi erinevate tarkvaraprojektide käitamiseks, alates programmide loomisest mitmest inimesest koosneva arendajate rühma poolt kuni hajutatud tarkvaraprojektideni, mis ühendavad tuhandeid inimesi erinevatel kontinentidel. Kuid vaatamata nende tohututele erinevustele on UML-i abil loodud mudelite kasutamise meetodid samad. Erinevatel arendusetappidel loodud UML-diagrammid on tarkvaraprojekti ülejäänud artefaktidest lahutamatud ja on sageli lüliks üksikute RUP-protsesside vahel.

    Konkreetsete diagrammide kasutamise otsus sõltub ettevõttes üles seatud arendusprotsessist, mis, kuigi nimetatakse ühtseks, ei ole midagi tardunud. Rational pakub mitte ainult selle täiustamist ja viimistlemist, vaid pakub ka spetsiaalseid tööriistu RUP-i andmebaasis muudatuste tegemiseks.

    Kuid igal juhul võimaldab UML-i kasutamine koos ühtse protsessiga saavutada prognoositava tulemuse, täita ettenähtud eelarve, tõsta projektis osalejate mõju ja loodud tarkvaratoote kvaliteeti.

    Kratchen. F. Sissejuhatus Ratsionaalne ühtne protsess . Ed. 2. - M.: Williams Publishing House, 2002. - 240 lk.: ill.

    Jacobson A., Buch G., Rambo J. Ühtne tarkvaraarenduse protsess - Peterburi: Peter, 2002. - 496 lk.: ill.

    Fowler M., Scott K. UML lühidalt. Standardse objektide modelleerimiskeele rakendamine: Transl. inglise keelest – M.:Mir, 1999. – 191 lk., ill.

    Beck. E. Ekstreemne programmeerimine. – Peterburi: Peeter, 2002. – 224 lk.: ill.

    TrofimovS. CASE tehnoloogiad: praktiline töö Rational Rose'is.
    Ed. 2. - M.: Binom-Press, 2002 - 288 lk.

    Dokumentatsiooni testimine Agile (, Lean, Scrum, FDD jne) Puhasruum OpenUP RAD RUP MSF DSDM TDD BDD Konfiguratsioonihaldus Projektihaldus Nõuete haldamine Kvaliteedi tagamine

    Unified Process kasutab aktiivselt ühtset modelleerimiskeelt ( UML). Tuumas UML peitub mudel, mis võimaldab arendusmeeskonnal lihtsustatult mõista tarkvara arendamiseks vajalike keeruliste protsesside mitmekesisust. Kasutatakse erinevaid mudeleid Ühtne protsess, võimaldavad süsteemi visualiseerida, kirjeldada selle struktuuri ja käitumist ning dokumenteerida arendusprotsessi käigus tehtud otsuseid.

    Päritolu ajalugu

    Raamistiku päritolu peitub töötaja töös Ericsson Ivar Jacobson, ilmus 1960. aastate lõpus. Jacobson ja tema kolleegid modelleerisid tohutuid telekommunikatsioonisüsteeme, kasutades "plokkide" kihte (mida hiljem hakati nimetama "komponentideks"): alumised kihid olid ülemiste kihtide alamsüsteemide aluseks. Meeskond ehitas alumised plokid, võttes arvesse "liiklusjuhtumeid", mis võivad süsteemi kasutajatega juhtuda. Just nendest "intsidentidest" sai kasutusjuhtumite prototüüp, mis hiljem kaasati UML. Jacobsoni töö inspireeris ka aastal kasutatud diagrammide loomist UML, sealhulgas tegevus - ja järjestusskeemid .

    1987. aastal asutas Jacobson oma ettevõtte Vastulause AB ja koos partneritega töötades mitu aastat välja projekti ja toote nimega Vastulause. 1995. aastal avaldas Jacobson raamatu " Objektorienteeritud tarkvaratehnika”, mis kirjeldab arendusprotsessi, mis on ajendatud klientide nõudmistest, mis muudetakse kasutusjuhtude kaudu lõpptooteks. Raamatu ilmumine langes kokku kerneli veebiversiooni esmakordse avaldamisega Ühtne protsess.

    1995. aastal ettevõte Vastulause AB ettevõtte poolt neelatud Ratsionaalne. Oluliselt suurenenud kolleegide hulga abiga hakkab Jacobson protsessi laiendama Vastulause, täiendades seda projektijuhtimise ja -arenduse tööriistadega. Koos Grady Boochi ja James Rumbaughiga, kes töötasid Ratsionaalne varem sai Jacobsonist “kolme sõbra” grupi liige, kes juhtis tööd protsessi loomiseks nn Ratsionaalne objekteerimisprotsess (ROP), samuti levitamine Ühtne protsess, mis sai aluseks Ühtne modelleerimiskeel.

    Töötamise käigus ROP Ja UML, korporatsioon Ratsionaalne jätkusid tarkvaraarendustööriistade loomisega seotud ettevõtete ühinemised ja ülevõtmised. Need tööriistad pakkusid võimalusi nõuete haldamiseks ("RequisitePro"), üldiseks testimiseks ("SQA"), jõudluse testimiseks, konfiguratsioonihalduseks ja muudatuste haldamiseks. 1998. aastal Ratsionaalne muudab toote nime RUP, mille kontseptuaalne tuum jääb alles Ühtne protsess.

    Omadused

    Ühtne protsess põhineb kasutusjuhtumeid, mis kirjeldab üht või mitut süsteemiga suhtlevat osalejat ja saavutab protsessis osalejatele väärtuslikke tulemusi. Just kasutusjuhtumid on peamine liikumapanev jõud, mis juhib kogu arendusprotsessi, alustades nõuete kogumisest ja arutelust ning lõpetades analüüsi, disaini ja juurutamisega. Kasutusjuhtumeid kirjeldatakse lihtsas ja arusaadavas keeles, et see oleks arusaadav ka välisele lugejale.

    Vastavalt Ühtne protsess, on arendusprotsessi keskmes arhitektuur- kogu süsteemi põhikorraldus. See võib sisaldada staatilisi ja dünaamilisi elemente, nende koostoimet ning võimaldab teil lahendada toote tõhususe, laiendatavuse, elementide taaskasutamise võimalusi ning aidata ületada majanduslikke ja tehnilisi piiranguid. Projektimeeskond alustab tööd arhitektuurikirjeldusega võimalikult varakult ning täiendab ja täiustab seda pidevalt arendusprotsessi käigus. Arhitektuuri peetakse oluliseks aspektiks Ühtne protsess mitmel põhjusel, mille võtmeks on võime näha toimuvast täit pilti, arendaja jõupingutuste õige rakendamine, komponentide taaskasutamise võimaluste hõlbustamine, süsteemiarendus ja kasutusjuhtude õige valik.

    Kolmas aluspõhimõte Ühtne protsess on kasutus iteratiivne ja järkjärguline lähenemine. Iteratsioonid on miniatuursed projektid, mis võimaldavad käivitada süsteemi uuema versiooni. Iteratsiooni tulemust ehk süsteemis tehtud muudatusi nimetatakse juurdekasvuks. Eelkõige võimaldab iteratiivne lähenemine järjekindlalt täiustada süsteemi arhitektuuri, tulla toime pidevate nõuete muutumisega ja paindlikult kohandada kogu projekti plaani. Pühendumine pideva integratsiooni põhimõttele võimaldab tuvastada võimalikud probleemid varajases staadiumis. Lisaks aitab iteratsioon minimeerida tehniliste piirangute, arhitektuuri ja muutuvate nõuetega seotud riske.

    Arengufaasid

    Tüüpilise projekti arendusfaaside suhteline suurus

    Iga arendustsükkel vastavalt Ühtne protsess, koosneb neljast faasist, mis tähistavad ajavahemikku oluliste projekti verstapostide vahel, võimaldades juhtidel langetada olulisi otsuseid arendusprotsessi jätkamise, töömahu, eelarve ja ajakava osas.

    Töövoo sordid

    Sees Ühtne protsess Igas arendusfaasis on viit tüüpi tööprotsesse: nõuded, analüüs, disain, juurutamine ja testimine.

    Iga protsess on tegevuste kogum, mida viivad läbi projektimeeskonna erinevad liikmed. Seega on nõuete kogumise protsesside eesmärk luua kasutusjuhtumite mudel, mis võimaldab tuvastada süsteemile esitatavad põhilised funktsionaalsed nõuded. Analüüsiprotsessid ja vastav mudel võimaldavad arendajatel struktureerida funktsionaalseid nõudeid; Disainiprotsess kirjeldab kasutusjuhtude füüsilist rakendamist ja on järgmise mudeli abstraktsioon. Rakendusprotsess ja mudel kirjeldavad, kuidas disainielemendid on seotud tarkvarakomponentidega, sh lähtekood, dünaamilised teegid jne. Viimases mudelis, mis kirjeldab testimist, selgitatakse, milliseid süsteemiteste ja ühikuteste tuleks läbi viia ning kuidas arendusmeeskond peaks neid tegema.

    Iteratsioonid ja juurdekasvud

    Iga ühtses protsessis kirjeldatud etapp koosneb iteratsioonid, mis on piiratud kestusega miniatuursed alamprojektid. Tavaliselt sisaldab iga iteratsioon erineval määral kõiki viit töövoo elementi. Iteratsiooni tulemus on juurdekasv, väljalase, mis sisaldab toote eelmise versiooniga võrreldes täiustusi.

    Ratsionaalne ühtne protsess(RUP) on tarkvaraarenduse tehnoloogiaraamistik, mille on välja töötanud ja turustab Rational Software. See hõlmab ülemaailmseid parimaid tarkvaraarenduse tavasid ning pakub distsiplinaarset lähenemist ülesannete ja vastutuste määramisel ja haldamisel tarkvaraarenduse organisatsioonis. Seda protsessi rakendades saavad tarkvaraarenduse meeskonnad luua kvaliteetset tarkvara, mis vastab nende lõppkasutajate vajadustele, ja teha seda prognoositava ajakava ja eelarve piires.

    RUP juhendab tarkvaraspetsialiste tõhusalt rakendama praeguseid parimaid tavasid, nagu iteratiivne areng, rakendus arhitektuurikeskne lähenemine, kasutusjuhud, riskide vähendamine protsessi kõikides etappides ja pidev programmi kontrollimine.

    Ratsionaalne ühtne protsess põhineb mitmel aluspõhimõttel, mis on kogutud paljudest edukatest projektidest:

    · Alusta peamiste riskide ründamist varem ja vii seda pidevalt läbi, vastasel juhul lähevad nad ise sinu vastu rünnakule.

    · Veenduge, et kliendi nõuded oleksid täidetud.

    · Keskenduge käivitatavale programmile.

    · Kohaneda muutustega juba projekti algusest peale.

    · Looge käivitatav arhitektuur varakult.

    · Ehitada komponentidest süsteem.

    · Töötage koos meeskonnana.

    · Muuda kvaliteet eluviisiks, mitte järelmõtlemiseks.

    RUP kasutab iteratiivne lähenemine Iga iteratsioon teeb natuke nõuetega seotud tööd, analüüsi, disaini, juurutamist ja testimist. Iga iteratsioon põhineb eelmiste iteratsioonide tulemustel ja loob käivitatava programmi, mis liigub lõpptootele sammu võrra lähemale.

    RUP pakub struktureeritud lähenemine iteratiivsele arengule, jagades projekti neljaks etapiks: algatamine, projekteerimine, ehitamine ja rakendamine. Iga faasiga kaasneb nn verstapost, protsessi kontrollpunkt, mille juures kontrollitakse järgmise faasi eesmärkide saavutamist ning tehakse otsus järgmisse faasi ülemineku (või mitte) kohta. Seega on igal RUP-i neljal etapil verstapost ja selgelt määratletud eesmärgid. Neid eesmärke kasutatakse selleks, et määrata, milliseid ülesandeid täita ja milliseid artefakte luua. Iga etapp keskendub rangelt sellele, mis on vajalik ainult etapi ärieesmärkide saavutamiseks.

    Kõik protsessi elemendid - rollid, ülesanded, artefaktid ja seotud kontseptsioonid, juhendid ja mallid rühmitatud loogilistesse konteineritesse nn Distsipliinid(distsipliinid). RUP standardtootes on ainult üheksa eriala. Nende hulka kuuluvad: äri modelleerimine, nõuete juhtimine, projektijuhtimine, muudatuste juhtimine ja keskkond.

    Iga protsessi töövoog: nõuete kogumine, analüüs, kavandamine, juurutamine ja testimine määratleb seotud artefaktide ja tegevuste komplekti. Tuletage meelde, et artefakt on dokument, aruanne, käivitatav element jne. Artefakt saab toota, töödelda või tarbida.

    Lõimede artefaktide vahel on sõltuvusi. Näiteks mudel Use Case, loodud nõuete kogumise ajal, TBC analüüsimudel projekteerimisprotsessist, rakendatakse rakendusmudel juurutusprotsessist ja kontrollitakse katsemudel testimisprotsessist.

    Mudel- kõige olulisem artefakti tüüp. Pakutakse üheksa mudelit, mis koos hõlmavad kõiki tarkvarasüsteemide visualiseerimise, spetsifikatsiooni, projekteerimise ja dokumenteerimise lahendusi:

    · ärimudel. Määratleb selle organisatsiooni abstraktsiooni, mille jaoks süsteemi luuakse;

    · domeeni mudel. Parandab süsteemi kontekstuaalset keskkonda;

    · Mudeli kasutusjuht. Määrab süsteemi funktsionaalsed nõuded.

    · analüüsimudel. Tõlgendab süsteeminõudeid disainimudeli seisukohast;

    · disaini mudel. Määratleb probleemi ja selle lahenduse valdkonnasõnavara;

    · paigutuse mudel. Määrab riistvara topoloogia, milles süsteem töötab;

    · rakendusmudel. Määratleb osad, mida kasutatakse füüsilise süsteemi kokkupanekuks ja juurutamiseks;

    · katsemudel. Määrab süsteemi testimiseks testjuhtumid;

    · protsessi mudel. Määratleb paralleelsuse süsteemis ja sünkroniseerimismehhanismid.

    Tehnilised artefaktid on jagatud nelja põhikomplekti:

    · nõuete kogum. Kirjeldab Mida süsteem peaks tegema;

    · disainikomplekt.

    Kirjeldab Kuidas süsteem peab olema projekteeritud;

    · rakenduste komplekt. Kirjeldab arendatud tarkvarakomponentide kokkupanekut;

    · paigutuskomplekt. Annab kogu teabe kaasasoleva konfiguratsiooni kohta.

    Nõuete kogum võib sisaldada kasutusjuhtumi mudelit, mittefunktsionaalsete nõuete mudelit, domeenimudelit, analüüsimudelit ja muid kasutajate vajaduste väljendamise vorme.

    Disain komplekt võib sisaldada disainimudelit, testmudelit ja muid süsteemi olemuse väljendamise vorme.

    Rakenduste komplekt rühmitab kõik andmed süsteemi moodustavate tarkvaraelementide kohta (programmikood, konfiguratsioonifailid, andmefailid, tarkvara komponendid, süsteemikoosteteave).

    Paigutuse komplekt koondab kogu teabe pakkimise, tarnimise, paigaldamise ja süsteemi käivitamise kohta.

    Iga tehnoloogiline protsess on kaasas risk. Tarkvaratoote arendamisel võib ebarahuldavaks tulemuseks (UN) olla: eelarve ületamine, madal töökindlus, ebakorrektne toimimine jne. Riski mõju arvutatakse avaldise abil

    Riski indikaator = tõenäosus (LP) * kahjum (LP).

    Riskijuhtimine sisaldab kuut toimingut:

    1. Riski tuvastamine – riskielementide tuvastamine projektis.

    2. Riskianalüüs – kahju tõenäosuse ja suuruse hindamine iga riskielemendi kohta.

    3. Riskide järjestus - riskielementide järjestamine nende mõju astme järgi.

    4. Riskijuhtimise planeerimine – valmistumine iga riskielemendiga tegelemiseks.

    5. Riski lahendamine – riskielementide kõrvaldamine või lahendamine.

    6. Riski monitooring – riskielementide dünaamika jälgimine, korrigeerivate tegevuste tegemine.

    Esimesed kolm tegevust kuuluvad riskihindamise etappi, kolm viimast tegevust riskikontrolli etappi.

    Riskiallikaid on kolm kategooriat: projektirisk, tehniline risk ja äririsk. Pärast riskielementide tuvastamist tuleks kvantifitseerida nende mõju tarkvaraprojektile ja lahendada küsimused võimalike kahjude kohta. Neid probleeme käsitletakse riskianalüüsi etapis. Ja lõpuks, iga riskielemendi haldamise plaan, st iga riskielemendi haldamise funktsioonide komplekt, on integreeritud tarkvaraprojekti üldplaani.