Pirmoje dalyje pasirinkome lyginti programinės įrangos kūrimo metodikas tokius rodiklius kaip metodikos ir iteracinio kūrimo santykis bei formalumo laipsnis kuriant darbo medžiagas ir apskritai kuriant. Šioje dalyje mes naudojame šiuos rodiklius, kad palygintume žinomiausias programinės įrangos kūrimo praktikas.

Žiūrėsim kaip seksis…

Deja, ši kategorija yra sunkiausiai apibūdinama – juk joje yra tiek pradedančiojo, bet kokia kaina bandančio užbaigti savo pirmąjį projektą, konvulsyvaus metimo produktas, tiek gana brandžios ir nusistovėjusios metodikos, kurios įsisavino daugelį metų. įvairi konkrečių kūrimo komandų patirtis ir net aprašyta vidaus taisyklėse. Kadangi žmonės, kurie sugeba sukurti savo metodiką, paprastai gali patys ją įvertinti iteracijos ir formalizavimo požiūriu, daugiausia dėmesio skirsime pradedantiesiems. Deja, dažniausiai tai reiškia, kad kūrimo taisyklių arba visai nėra, arba jos buvo sukurtos ir priimtos, bet neįgyvendinamos. Natūralu tokiomis sąlygomis yra itin žemas išsivystymo formalizmas. Taigi viskas aišku.

Kūrimas „Kaip tai veikia“

O kaip iteracinis metodas? Deja, kaip taisyklė, jis nenaudojamas tokiuose projektuose. Visų pirma dėl to, kad tai leistų net pirmosiomis iteracijomis projektą įvertinti kaip itin abejotiną ir reikalaujantį skubaus aukštesnės vadovybės įsikišimo tvarkai atkurti. Juk iteraciniame projekte tradicinis programuotojo atsakymas, kad jam viskas 90% paruošta, trunka tik iki pirmosios iteracijos pabaigos...

Struktūrinės metodikos

Struktūrinės metodikos

Struktūriniai metodai yra metodikų grupė, sukurta, kaip taisyklė, dar prieš plačiai naudojant objektines kalbas. Visi jie susiję su krioklio plėtra. Nors, kaip paaiškėjo, dar tame straipsnyje, kuris dažnai minimas kaip pirmasis krioklio požiūrio pristatymas, buvo pasakyta, kad norima pradėti projektą nuo prototipo kūrimo, tai yra atlikti bent dvi iteracijos.

Nepaisant to, šių metodikų pagrindas yra nuoseklus perėjimas nuo darbo prie darbo ir kito etapo rezultatų (dokumentų) perdavimas kito etapo dalyviams.

Be to, visos šios metodikos yra labai formalizuotos, nors jose galima rasti teiginių apie pagrįstą dokumentų kiekį. Vienas iš neakivaizdžių pavyzdžių, kad programinės įrangos kūrimo metodikos buvo sukurtos ne tik Vakaruose, yra citata iš devintojo dešimtmečio pradžioje mūsų šalyje išleistos knygos, kurioje teigiama, kad programavimo užduoties formalizavimo laipsnis turi būti nustatomas remiantis. apie tai, kaip gerai analitikas ir programuotojas. Ir tai nepaisant to, kad knygos tema apėmė gana kritiškų, kaip dabar vadinamų, sistemų kūrimą, kurių klaidos sukelia rimtų nuostolių ar net nelaimių.

Agile metodikos

Agilios metodikos remiasi dešimčia principų, iš kurių įvardinsime tik tuos, kurie lemia šių metodikų vertinimą pagal pasirinktus parametrus:

• svarbiausia yra patenkinti klientą ir kuo greičiau pateikti jam prekę;
• nauji gaminio leidimai turėtų pasirodyti kas kelias savaites, kraštutiniais atvejais – mėnesius;
• dauguma efektyvus metodasžinių perdavimas plėtros dalyviams ir tarp jų – asmeninis bendravimas;
• veikianti programa yra geriausias vystymosi progreso rodiklis.

Taigi šie metodai aiškiai orientuoti į kartotinį programinės įrangos kūrimą ir minimalų proceso formalizavimą. Tačiau būtina padaryti išlygą dėl antrojo punkto: šie metodai yra orientuoti į minimalų formalizavimo lygį, priimtiną konkrečiam projektui. Bent viena iš lanksčios grupės metodikų – Crystal – turi modifikacijų, skirtų atlikti procesus su skirtingu dalyvių skaičiumi ir skirtingu kuriamos programinės įrangos kritiškumu (programinės įrangos kritiškumą lemia galimos klaidų pasekmės, kurios gali skirtis nuo smulkių finansinių nuostolių ištaisius katastrofišką klaidą). Kad tolesnis palyginimas su lanksčiomis metodikomis nebūtų beprasmis, trumpai apibūdinsime keletą iš jų.

Ekstremalus programavimas arba XP (ekstremalus programavimas)

XP metodika, kurią sukūrė Kent Beck, Ward Cunningham ir Ron Jeffries, šiandien yra geriausiai žinoma iš judrių metodikų. Kartais pati „judrių metodikų“ sąvoka tiesiogiai arba netiesiogiai tapatinama su XP, skelbiančia visuomeniškumą, paprastumą, Atsiliepimas ir drąsos. Jis apibūdinamas kaip praktikų rinkinys: planavimo žaidimas, trumpi leidimai, metaforos, paprastas dizainas, kodo pertvarkymas (refactoring), bandymas į priekį kūrimas, porinis programavimas, kolektyvinė kodo nuosavybė, 40 valandų darbo savaitė, nuolatinis klientų buvimas ir kodo standartai. Susidomėjimas XP augo iš apačios į viršų – iš kūrėjų ir testuotojų, kankinamų skausmingo proceso, dokumentacijos, metrikų ir kitokio formalizmo. Jie neatmetė drausmės, tačiau nenorėjo beprasmiškai laikytis formalių reikalavimų ir ieškojo naujų greitų ir lanksčių požiūrių į kokybiškų programų kūrimą.

Naudojant XP, kruopštų preliminarų programinės įrangos projektavimą pakeičia, viena vertus, nuolatinis kliento buvimas komandoje, pasiruošęs atsakyti į bet kokį klausimą ir įvertinti bet kokį prototipą, kita vertus, reguliarios kodo peržiūros (vad. pertvarkymas). Projektinės dokumentacijos pagrindu laikomas išsamiai komentuojamas kodas. Metodikoje daug dėmesio skiriama testavimui. Paprastai kiekvienam naujam metodui pirmiausia parašomas testas, o tada sukuriamas tikrasis metodo kodas, kol testas pradeda sėkmingai vykdyti. Šie testai saugomi rinkiniuose, kurie automatiškai vykdomi pakeitus kodą.

Nors porinis programavimas ir 40 valandų darbo savaitė yra bene labiausiai žinomos XP savybės, jos vis tiek palaiko savo pobūdį ir prisideda prie didelio kūrėjo produktyvumo bei sumažinimo kūrimo klaidų.

Švarus

Crystal – tai metodikų šeima, kuri nustato reikiamą kūrimo proceso formalizavimo laipsnį, priklausomai nuo dalyvių skaičiaus ir užduočių kritiškumo.

„Crystal Clear“ metodika našumu nusileidžia XP, tačiau ja naudotis yra kuo lengviau. Ją įgyvendinti reikia minimalių pastangų, nes dėmesys sutelkiamas į žmogaus įpročius. Manoma, kad ši metodika apibūdina natūralią programinės įrangos kūrimo tvarką, kuri nusistovi pakankamai kvalifikuotose komandose, jeigu jos neužsiima kryptingu kitos metodikos įgyvendinimu.

Pagrindinės „Crystal Clear“ savybės:

• pasikartojantis laipsniškas vystymasis;
• automatinis regresijos testavimas;
• vartotojai įtraukiami į aktyvų dalyvavimą projekte;
• dokumentacijos sudėtį nustato projekto dalyviai;
• paprastai naudojami kodo versijos valdymo įrankiai.

Be „Crystal Clear“, „Crystal“ šeimoje yra keletas kitų metodikų, skirtų didesniems ar svarbesniems projektams. Jie skiriasi šiek tiek griežtesniais reikalavimais dėl dokumentų kiekio ir pagalbinių procedūrų, tokių kaip pakeitimų ir versijų valdymo.

Funkcijomis pagrįstas kūrimas

Funkcijomis pagrįstas vystymas (FDD) veikia pagal sistemos ypatybę arba funkciją, kuri yra gana artima RUP naudojimo atvejo koncepcijai. Bene reikšmingiausias skirtumas yra papildomas apribojimas: „kiekviena funkcija turi leisti įgyvendinti ne ilgiau kaip dvi savaites“. Tai yra, jei naudojimo atvejis yra pakankamai mažas, jis gali būti laikomas funkcija, o jei jis yra didelis, tada jis turėtų būti suskirstytas į keletą santykinai nepriklausomų funkcijų.

FDD apima penkis procesus, o paskutiniai du kartojami kiekvienai funkcijai:

• bendro modelio kūrimas;
• būtinų sistemos funkcijų sąrašo sudarymas;
• planuoti darbą su kiekviena funkcija;
• funkcinis dizainas;
• funkcijų konstrukcija.

Darbas su projektu apima dažnas kūrimas ir yra padalintas į iteracijas, kurių kiekviena įgyvendinama naudojant tam tikrą funkcijų rinkinį.

FDD kūrėjai skirstomi į „klasių meistrus“ ir „vyriausiuosius programuotojus“. Pagrindiniai programuotojai įtraukia dalyvaujančių klasių savininkus dirbti su kita nuosavybe. Palyginimui: XP nėra asmeniškai atsakingi už klases ar metodus.

Bendrų bruožų

Lanksčių metodikų sąrašas šiuo metu gana platus. Nepaisant to, mūsų aprašytos metodikos suteikia labai išsamų visos šeimos vaizdą.

Beveik visose judriose metodikose naudojamas kartotinis metodas, kai detaliai suplanuojamas tik ribotas darbo kiekis, susijęs su kitos laidos išleidimu.

Beveik visos judrios metodikos yra orientuotos į patį neformaliausią požiūrį į vystymąsi. Jei problemą galima išspręsti įprasto pokalbio metu, geriau tai padaryti. Ir nupiešti sprendimą popierine forma arba elektroninis dokumentas reikalingas tik tada, kai be jo neįmanoma išsiversti.

Agile metodikos

GOST

GOST, kaip ir kitame skyriuje aprašyti CMM reikalavimai, nėra metodikos. Jie, kaip taisyklė, neaprašo pačių programinės įrangos kūrimo procesų, o tik formuluoja tam tikrus reikalavimus procesams, kuriems vienokiu ar kitokiu laipsniu atitinka skirtingos metodikos. Reikalavimų palyginimas pagal tuos pačius kriterijus, pagal kuriuos lyginame metodikas, padės iš karto apsispręsti, kokias metodikas naudoti, jei reikia kurti pagal GOST.

Šiuo metu Rusijoje galioja seni 19, 34 ir daugiau serijų GOST naujas GOST R ISO IEC 122207. 19 ir 34 serijų GOST yra griežtai orientuoti į pakopinį požiūrį į programinės įrangos kūrimą. Kūrimas pagal šiuos GOST vyksta etapais, kurių kiekvienas apima griežtai apibrėžto darbo atlikimą ir baigiasi pakankamai išleidžiant didelis skaičius labai formalizuoti ir dideli dokumentai. Taigi iš karto griežtas šių standartų laikymasis ne tik lemia krioklio metodą, bet ir labai aukštas laipsnis plėtros formalizavimas.

GOST reikalavimai

GOST 12207, priešingai nei 19 ir 34 serijų standartai, programinės įrangos kūrimą apibūdina kaip pagrindinių ir pagalbinių procesų rinkinį, kuris gali veikti nuo projekto pradžios iki pabaigos. Modelis gyvenimo ciklas galima pasirinkti atsižvelgiant į projekto specifiką. Taigi šis GOST aiškiai nedraudžia naudoti kartotinio metodo, tačiau aiškiai nerekomenduoja jo naudoti. GOST 12207 taip pat yra lankstesnis kūrimo proceso formalumo reikalavimų atžvilgiu. Jame pateikiami tik nurodymai apie būtinybę dokumentuoti pagrindinius visų procesų rezultatus, tačiau nėra reikalingų dokumentų sąrašų ir nurodymų dėl jų turinio.

Taigi GOST 12207 leidžia kartotinį ir mažiau formalizuotą programinės įrangos kūrimą.

Kūrimo proceso brandos modeliai (CMM, CMMI)

Be nacionalinių ir tarptautinių standartų, yra keletas kūrimo proceso sertifikavimo būdų. Garsiausios iš jų Rusijoje, matyt, yra CMM ir CMMI.

CMM (Capability Maturity Model) – programinės įrangos kūrimo procesų brandos modelis, skirtas įvertinti kūrimo proceso brandos lygį konkrečioje įmonėje. Pagal šį modelį yra penki vystymosi proceso brandos lygiai. Pirmasis lygis atitinka „kaip tai vyksta“ kūrimą, kai kūrėjai į kiekvieną projektą eina kaip į žygdarbį. Antrasis atitinka daugiau ar mažiau nusistovėjusius procesus, kai galima pakankamai užtikrintai tikėtis teigiamų projekto rezultatų. Trečiasis atitinka išplėtotų ir gerai aprašytų procesų, naudojamų kuriant, buvimą, o ketvirtasis – aktyvų metrikų naudojimą valdymo procese, siekiant nustatyti tikslus ir stebėti jų pasiekimą. Galiausiai, penktasis lygis reiškia įmonės gebėjimą optimizuoti procesą pagal poreikį.

CMM ir CMMI reikalavimai

Po CMM atsiradimo buvo pradėti kurti specializuoti brandos modeliai, skirti kurti Informacinės sistemos, tiekėjų atrankos procesui ir kai kuriems kitiems. Jų pagrindu buvo sukurtas integruotas CMMI modelis (Capability Maturity Model Integration). Be to, CMMI buvo bandoma įveikti iki tol pasireiškusius CMM trūkumus – formalių procesų aprašymų vaidmens perdėjimą, kai tam tikros dokumentacijos buvimas buvo vertinamas kur kas aukščiau, nei tik nusistovėjusios, o ne tik nusistovėjusios dokumentacijos buvimas. bet neaprašytas procesas. Tačiau CMMI taip pat orientuojasi į labai formalizuoto proceso naudojimą.

Taigi CMM ir CMMI modelių pagrindas yra kūrimo proceso formalizavimas. Jomis siekiama, kad kūrėjai įgyvendintų reglamentuose ir instrukcijose išsamiai aprašytą procesą, o tam, savo ruožtu, reikia parengti daug projektinės dokumentacijos, kad būtų galima tinkamai kontroliuoti ir teikti ataskaitas.

CMM ir CMMI ryšys su iteraciniu vystymusi yra labiau netiesioginis. Formaliai nė vienas iš jų nepateikė konkrečių reikalavimų, susijusių su krioklio ar iteracinio požiūrio laikymusi. Tačiau, pasak kai kurių ekspertų, CMM labiau suderinamas su krioklio metodu, o CMMI taip pat leidžia taikyti kartotinį metodą.

RUP

Žinoma, RUP yra pasikartojanti metodika. Nors formaliai RUP niekur nenurodytas privalomas visų fazių vykdymas ar koks nors minimalus pakartojimų skaičius, visas požiūris yra orientuotas į tai, kad jų yra gana daug. Ribotas kiekis iteracijos neleidžia išnaudoti visų RUP privalumų. Tuo pačiu metu RUP taip pat gali būti naudojamas beveik pakopiniuose projektuose, kurie iš tikrųjų apima tik keletą iteracijų: vieną kūrimo fazėje, o kitą - perdavimo fazėje. Beje, tai yra iteracijų skaičius, kuris iš tikrųjų naudojamas krioklio projektuose. Galų gale, sistemos testavimas ir bandomasis veikimas apima pataisymus, kurie gali apimti tam tikrus veiksmus, susijusius su analize, projektavimu ir plėtra, tai yra, iš tikrųjų jie yra dar vienas perėjimas per visus kūrimo etapus.

RUP metodika

Kalbant apie metodikos formalumą, RUP pateikia vartotojui labai plačias galimybes. Jei atliksite visus darbus ir užduotis, sukurkite visus artefaktus ir pakankamai formaliai (su oficialiu recenzentu, parengus pilną apžvalgą elektronine ar popierinis dokumentas ir tt), kad būtų galima atlikti visas peržiūras, RUP gali būti labai formali, sudėtinga metodika. Tuo pačiu metu RUP leidžia kurti tik tuos artefaktus ir atlikti tik tuos darbus ir užduotis, kurie būtini konkrečiame projekte. O pasirinktus artefaktus galima atlikti ir peržiūrėti su savavališku formalumu. Galima reikalauti išsamios kiekvieno dokumento išstudijavimo ir kruopštaus įforminimo, vienodai kruopščiai atliktos ir formalizuotos peržiūros suteikimo ir netgi, vadovaujantis sena praktika, kiekvienai tokiai peržiūrai pritarti įmonės mokslinėje ir techninėje taryboje. Arba galite apsiriboti el. laišku arba eskizu popieriuje. Be to, visada yra dar viena galimybė: susiformuoti dokumentą galvoje, tai yra apgalvoti aktualų klausimą ir priimti konstruktyvų sprendimą. Ir jei šis sprendimas susijęs tik su jumis, apsiribokite, pavyzdžiui, komentaru programos kode.

Taigi, RUP yra iteracinė metodika, turinti labai platų spektrą galimi sprendimai kalbant apie kūrimo proceso formalizavimą.

Apibendrinkime antrąją straipsnio dalį. RUP, skirtingai nei dauguma kitų metodikų, leidžia pasirinkti kūrimo proceso formalizavimo ir iteracijos laipsnį plačiame diapazone, priklausomai nuo projektų ir besivystančios organizacijos savybių.

O kodėl tai taip svarbu – aptarsime kitoje dalyje.

1. Kaskadas (angliškas krioklys) – standartinis kūrimo modelis

Kaskadinis kūrimo modelis – modelis, kuriame visi kūrimo etapai vykdomi nuosekliai – baigus ankstesnį prasideda kitas etapas.

Šis modelis apima šiuos programinės įrangos kūrimo proceso veiksmus:

Visų pirma, tai nustatoma Techninės specifikacijos būsima programa, todėl patvirtinamas programinės įrangos reikalavimų sąrašas. Toliau pereinama prie projektavimo, kurio metu sukuriama dokumentacija, kuri programuotojams aprašo planą ir būdą, kaip įgyvendinti reikalavimus.

Baigę projektavimą programuotojai įgyvendina (sukonstruoja) projektą. Įgyvendinimo etape visi projekto komponentai yra integruoti. Tik visiškai užbaigus šiuos etapus, atliekamas gatavo produkto testavimas ir derinimas. Be to, programinės įrangos produktas gali būti įdiegtas ir po įdiegimo teikti palaikymą – įdiegti naujas funkcijas ir pašalinti klaidas.

Pagrindiniai krioklio plėtros pranašumai:

2. Agilios programinės įrangos kūrimo metodika

Įvairios kūrimo metodikos programinė įranga, kuriame numatytas bendras užsakovo ir kūrėjų atstovų darbas. Judrus kūrimo metodas pagrįstas iteraciniu požiūriu, dinamišku reikalavimų formavimu ir jų įgyvendinimu trumpais etapais.

Kiekvieno tokio etapo, įskaitant iteracijų ciklą, rezultatas yra miniatiūrinis programinės įrangos projektas,

Egzistuoja keli judrūs kūrimo metodai, žinomiausi yra Scrum, Extreme Programming, DSDM.

Pagrindiniai judrios plėtros pranašumai:

		rizikos mažinimas; laipsniškas programinės įrangos produkto funkcionalumo didinimas; nedidelis kiekis rašytinės dokumentacijos; kuo greičiau paleisti bazinę programos versiją.
Taip pat yra trūkumų:
		nesugebėjimas tiksliai nustatyti projekto biudžeto; neįmanoma nustatyti tikslaus projekto pasirengimo laiko; netinka valstybinėms ir biudžetinėms organizacijoms; reikalauja motyvacijos iš atsakingų užsakovo atstovų.

Agile Software Development Manifestas Nuolat atrandame geresnių programinės įrangos kūrimo būdų kurdami tiesiogiai ir padėdami kitiems. Atlikto darbo dėka galėjome suprasti, kad: Žmonės ir bendravimas svarbesni už procesus ir įrankius Veikiantis produktas svarbiau nei išsami dokumentacija Bendradarbiavimas su klientu svarbiau nei derėtis dėl sutarties sąlygų Pasirengimas pokyčiams yra svarbesnis pagal pirminį planą Tai yra, neneigdami svarbos to, kas yra dešinėje, vis tiek labiau vertiname tai, kas yra kairėje.

Agile plėtros principai:

Klientų pasitenkinimas dėl greito ir nepertraukiamo reikiamos programinės įrangos pristatymo; sveikintina reikalavimų pasikeitimus net ir kūrimo pabaigoje (tai gali padidinti gaunamo produkto konkurencingumą); dažnas veikiančios programinės įrangos pristatymas (kas mėnesį ar savaitę ar net dažniau); glaudus, kasdienis užsakovo ir kūrėjų bendravimas viso projekto metu; projektą vykdo motyvuoti asmenys, kuriems sudaromos būtinos darbo sąlygos, parama ir pasitikėjimas; rekomenduojamas informacijos perdavimo būdas – asmeninis pokalbis (akis į akį); veikianti programinė įranga yra geriausias progreso matas; rėmėjai, kūrėjai ir vartotojai turi turėti galimybę neribotą laiką išlaikyti pastovų tempą; nuolatinis dėmesys techninės kompetencijos ir vartotojui patogaus dizaino gerinimui; paprastumas – menas neatlikti nereikalingų darbų; geriausi techniniai reikalavimai, dizainas ir architektūra ateina iš savarankiškai organizuotos komandos; nuolatinis prisitaikymas prie besikeičiančių aplinkybių.

Programinės įrangos kūrimo modeliai Waterfall Cascade modelis Spiral Ekstremalus programavimas UI prototipų kūrimo prieauginio W modelio testavimo vieningo programinės įrangos kūrimo proceso (USDP) MSF metodika

Krioklio modelis Reikalavimų analizė Produkto specifikacijos sudarymas Dizainas Produkto architektūros sudarymas Įgyvendinimas Šaltinio kodo kūrimas Atskirų šaltinio kodo dalių integravimas Testavimas ir trikčių šalinimas

Ekstremalūs programavimo pradiniai reikalavimai Analizė Dizainas Integravimas Įgyvendinimas Testavimas Nauji reikalavimai Peržiūrėti/patvirtinti/keisti plėtros plano išleidimo produktas

UI prototipų kūrimas Produkto išleidimas Programinės įrangos kūrimas atsižvelgiant į pokyčius Reikalavimų ir specifikacijų paaiškinimas Prototipo modifikavimas ir kai kurių funkcijų tobulinimas Pagrindinės funkcijos Sąsajos prototipas Preliminari specifikacija

Prieauginio kūrimo iteracija 1 iteracija 2 iteracija …. Reikalavimai Analizė Projektas Įgyvendinimas Komponentų testavimas Integravimas Visos visos iteracijos testavimas N

Vieningas programinės įrangos kūrimo procesas (USDP) Ø Naudojimo atvejo modelis, aprašo atvejus, kuriais programa bus naudojama. Ø Analitinis modelis apibūdina pagrindines programos klases. Ø Projektavimo modelis apibūdina ryšius ir ryšius tarp klasių ir pasirinktų objektų Ø Diegimo modelis aprašo programinės įrangos paskirstymą kompiuteriuose. Ø Įgyvendinimo modelis aprašo vidinė organizacija programos kodas. Ø Bandymo modelis susideda iš testavimo komponentų, bandymo procedūrų ir skirtingų bandymų atvejų

Vieningo programinės įrangos kūrimo proceso (USDP) reikalavimų rinkimas Iter 1…. Iter N projektavimas Iter 1…. Iter N Iter 1 įgyvendinimas…. Iter N projektavimas Iter 1…. Iter N testavimas Iter 1…. Iteris N

Tipiniai programinės įrangos produkto architektūros komponentai ir tipiniai programinės įrangos reikalavimai Ø Ø Ø Ø Programos organizavimas Pagrindinės sistemos klasės Duomenų organizavimas Verslo taisyklės Vartotojo sąsaja Išteklių valdymas Sauga Veikimas Mastelio keitimas Sąveika su kitomis sistemomis (integracija) Internacionalizavimas, lokalizavimas Įvesties-išvesties duomenys Klaidų tvarkymas

Tipiški programinės įrangos produkto architektūros komponentai ir tipiniai programinės įrangos reikalavimai Gedimų tolerancija – tai sistemos ypatybių rinkinys, padidinantis sistemos patikimumą aptikdamas klaidas, atkurdamas ir išskirdamas blogas pasekmes sistemai. Projektuojant bet kokią realią sistemą, užtikrinančią gedimų toleranciją, būtina numatyti visas galimas situacijas, kurios gali sukelti sistemos gedimą ir sukurti gedimų valdymo mechanizmus. Patikimumas – tai sistemos gebėjimas atlaikyti įvairius gedimus ir gedimus. Gedimas – tai sistemos perėjimas dėl klaidos į visiškai neveikiančią būseną. Gedimas – tai sistemos veikimo klaida, kuri nesukelia sistemos gedimo. Kuo mažiau gedimų ir gedimų tam tikrą laiką, tuo sistema laikoma patikimesne.

Tipiški programinės įrangos produkto architektūros komponentai ir tipiniai programinės įrangos reikalavimai Patikimumo kreivė N t 1 t Kuo toliau, tuo sunkiau bus rasti klaidą. Kuo sudėtingesnė sistema, tuo didesnė gedimų ir gedimų tikimybė.

Tipiniai programinės įrangos produkto architektūros komponentai ir tipiniai programinės įrangos reikalavimai Ø Sukurtos architektūros realizavimo galimybės. Ø Per didelis funkcionalumas. Ø Sprendimo pirkti gatavus programinės įrangos komponentus priėmimas. Ø Keisti strategiją.

Kontrolinis klausimų sąrašas, leidžiantis padaryti išvadą apie architektūros kokybę: Ø Ar aiškiai aprašyta bendra programos organizacija; Ø Ø Ø Ar specifikacija apima architektūros apžvalgą ir jos pagrindimą. Ar tinkamai apibrėžti pagrindiniai programos komponentai, jų atsakomybės sritys ir sąveika su kitais komponentais. Ar visas reikalavimų specifikacijoje nurodytas funkcijas įgyvendina pagrįstas sistemos komponentų skaičius. Ar aprašytos ir pagrįstos svarbiausios klasės. Ar pateikiamas duomenų bazės organizavimo aprašymas. Ar visos verslo taisyklės apibrėžtos? Ar aprašytas jų poveikis sistemai?

Kontrolinis klausimų sąrašas, leidžiantis padaryti išvadą apie architektūros kokybę: Ø Ar aprašyta vartotojo sąsajos projektavimo strategija. Ø Ar tai padaryta vartotojo sąsaja modulinis, kad jo pakeitimai nepaveiktų likusios sistemos. ØAr pateiktas duomenų įvesties/išvesties strategijos aprašymas. Ø Ar buvo atlikta sistemos, kuri bus įdiegta naudojant šią architektūrą, veikimo analizė. Ø Ar buvo atlikta suprojektuotos sistemos patikimumo analizė. Ø Ar buvo atlikta sistemos mastelio ir išplečiamumo klausimų analizė.

Programinės įrangos pertvarkymas Refaktorizavimas apima programinės įrangos pritaikymą naujai aparatūra ir naujoms operacinėms sistemoms, naujiems kūrimo įrankiams, naujiems reikalavimams ir programinės įrangos architektūrai bei funkcionalumui. Tai yra vidinės programinės įrangos struktūros pakeitimas jos nekeičiant. išorinis elgesys skirta programinei įrangai modifikuoti. Pagrįstos pertvarkymo priežastys: Kodas kartojasi; metodo įgyvendinimas per didelis; per daug kilpų lizdų arba pati kilpa yra labai didelė; klasė turi prastą ryšį (klasės savybės ir metodai turėtų apibūdinti tik 1 objektą); klasės sąsaja nesudaro nuoseklios abstrakcijos; metodas reikalauja per daug parametrų. Turėtumėte stengtis, kad parametrų skaičius būtų kuo mažesnis; atskiros klasės dalys keičiasi nepriklausomai nuo kitų klasės dalių;

Programinės įrangos pertvarkymas keičiant programą reikalauja lygiagrečiai pakeisti kelias klases. Susidarius tokiai situacijai, būtina pertvarkyti klases, kad ateityje būtų kuo mažesnės galimų pokyčių vietos; turi lygiagrečiai keisti kelias paveldėjimo hierarchijas; jūs turite pakeisti keletą bylų blokų. Būtina modifikuoti programą taip, kad atvejo realizavimas būtų blokuotas, ir programoje jį iškviesti reikiamą skaičių kartų; susiję duomenų nariai, naudojami kartu, nėra suskirstyti į klases. Jei pakartotinai naudojate tą patį duomenų elementų rinkinį, tuomet patartina apsvarstyti galimybę šiuos duomenis sujungti ir su jais atliktas operacijas sudėti į atskirą klasę;

Programinės įrangos pertvarkymo metodas naudoja daugiau kitos klasės elementų nei jo paties. Tai reiškia, kad metodą reikia perkelti į kitą klasę ir iškviesti iš senosios; elementarus duomenų tipas yra perkrautas. Norėdami apibūdinti realaus pasaulio esmę, geriau naudoti bet kurią klasę, nei perkrauti bet kurią esamo tipo duomenys; klasė turi per ribotas funkcijas. Šios klasės geriau atsikratyti perkeliant jos funkcionalumą į kitą klasę; „Paklysti“ duomenys perduodami metodų grandinėje. Duomenys, kurie perduodami vienam metodui tik tam, kad būtų perduoti kitam metodui, vadinami atsitiktiniais duomenimis. Iškilus tokioms situacijoms, pabandykite pakeisti klasių architektūrą ir metodus, kad jų atsikratytumėte.

Žiniasklaidos objekto pertvarkymas nieko nedaro. Jei klasės vaidmuo yra nukreipti metodų iškvietimus į kitas klases, geriausia pašalinti tą tarpinį serverį ir tiesiogiai skambinti į kitas klases; viena klasė per daug žino apie kitą klasę. Esant tokiai situacijai, būtina sugriežtinti inkapsuliavimą, kad įpėdinis turėtų minimalių žinių apie savo tėvą; metodas turi nelaimingą pavadinimą; duomenų nariai yra vieši. Tai ištrina liniją tarp sąsajos ir įgyvendinimo, neišvengiamai nutraukia inkapsuliavimą ir apriboja programos lankstumą; skelbti komentarus pirminis kodas;

Programinės įrangos pertvarkymo poklasis naudoja tik nedidelę dalį savo protėvių metodų. Ši situacija atsiranda, kai sukuriama nauja klasė, kad būtų galima paveldėti kelis metodus iš pagrindinės klasės, o ne aprašyti naują objektą. Norint to išvengti, reikia transformuoti bazinę klasę taip, kad ji suteiktų prieigą prie naujos klasės tik jai reikalingiems metodams; kode yra globalūs kintamieji. Tik tie kintamieji, kuriuos iš tikrųjų naudoja visa programa, turėtų būti visuotiniai. Visi kiti kintamieji turi būti vietiniai arba tapti kokio nors objekto savybėmis; programoje yra kodas, kurio kada nors gali prireikti. Kuriant sistemą, patartina numatyti vietas, kur ateityje bus galima pridėti šaltinio kodą.

Taigi, struktūrinio požiūrio į EIS programinės įrangos kūrimą esmė slypi jos skaidyme (skirstyme) į automatizuotas funkcijas: sistema suskirstyta į funkcines posistemes, kurios savo ruožtu skirstomos į subfunkcijas, tos į užduotis ir pan. iki konkrečių procedūrų. Tuo pačiu metu sistema išlaiko holistinį vaizdą, kuriame visi komponentai yra tarpusavyje susiję. Kuriant „iš apačios į viršų“ sistemą, nuo atskirų užduočių iki visos sistemos, prarandamas vientisumas, kyla problemų aprašant atskirų komponentų informacinę sąveiką.

Visi dažniausiai naudojami struktūrinio požiūrio metodai yra pagrįsti daugeliu Bendri principai:

1. Principas „skaldyk ir valdyk“;

2. Hierarchinės tvarkos principas – sistemos sudedamųjų dalių suskirstymo į hierarchines medžio struktūras principas, kiekviename lygyje pridedant naujų detalių.

Pasirinkimas iš dviejų Pagrindiniai principai nereiškia, kad kiti principai yra antraeiliai, nes kurio nors iš jų ignoravimas gali sukelti nenuspėjamų pasekmių (įskaitant viso projekto nesėkmę). Pagrindiniai iš šių principų yra šie:

1. Abstrakcijos principas – esminių sistemos aspektų išryškinimas ir atitraukimas nuo neesminio.

2. Sistemos elementų nuoseklumo, pagrįstumo ir nuoseklumo principas.

3. Struktūravimo principas duomenys – duomenys turėtų būti struktūrizuotas ir hierarchiškai organizuotas.

Struktūriniame požiūryje iš esmės yra dvi įrankių grupės, apibūdinančios funkcinę sistemos struktūrą ir ryšius tarp duomenų. Kiekviena įrankių grupė atitinka tam tikrus modelių tipus (diagramas), tarp jų labiausiai paplitę:

· DFD (Data Flow Diagrams) – duomenų srautų diagramos;

SADT (Structured Analysis and Design Technique - struktūrinės analizės ir projektavimo metodika) - modeliai ir atitinkamos funkcinės diagramos: žymos IDEF0 (funkcinis sistemų modeliavimas), IDEF1x (koncepcinis duomenų bazių modeliavimas), IDEF3x (objekto kokybei įvertinti pastato sistemos). grafinis srauto procesų, procesų ir šių procesų keičiamų objektų sąveikos aprašymas);

· ERD (Entity – Relationship Diagrams) – „esybės ir santykių“ diagramos.

Beveik visuose struktūrinio metodo (struktūrinės analizės) metoduose programinės įrangos reikalavimų formavimo etape naudojamos dvi modeliavimo įrankių grupės:

1. Diagramos, iliustruojančios funkcijas, kurias turi atlikti sistema, ir ryšius tarp šių funkcijų – DFD arba SADT (IDEF0).

2. Diagramos, modeliuojančios duomenis ir jų ryšius (ERD).

Konkreti išvardintų diagramų forma ir jų konstrukcijų interpretacija priklauso nuo programinės įrangos gyvavimo ciklo etapo.

Programinės įrangos reikalavimų formavimo stadijoje SADT modeliai ir DFD naudojami modeliui „AS-IS“ ir „TO-BE“ modeliui sukurti, taip atspindint esamą ir siūlomą organizacijos verslo procesų struktūrą bei jų tarpusavio sąveiką. (naudojant SADT modelius, kaip paprastai apsiribojama tik šiuo etapu, nes jie iš pradžių nebuvo skirti programinei įrangai kurti). ERD pagalba atliekamas organizacijoje naudojamų duomenų aprašymas konceptualiu lygmeniu, nepriklausomai nuo duomenų bazės (DBVS) diegimo priemonių.

Anotacija: Apsvarstytas lankstus požiūris į programinės įrangos kūrimą, pagrindiniai lankstaus kūrimo principai. Pateikiamas sąrašas metodų, kurie tam tikru mastu atitinka lanksčios programinės įrangos kūrimo principus. Išnagrinėtos pagrindinės judrios plėtros vertybės ir principai.

Šios paskaitos pristatymą galite atsisiųsti.

Paskaitos tikslas:

Įgykite supratimą apie judrios programinės įrangos kūrimo tikslą ir pagrindinius principus.

Įvadas

Agile programinės įrangos kūrimo metodika orientuotas į iteracinio metodo naudojimą, kuriame programinė įranga kuriama palaipsniui, mažais žingsneliais, įskaitant tam tikro reikalavimų rinkinio įgyvendinimą. Manoma, kad reikalavimai gali keistis. Agile metodikas taikančios komandos formuojamos iš įvairiapusių kūrėjų, kurie programinio produkto kūrimo procese atlieka įvairias užduotis.

Naudojant judrias metodikas, rizikos mažinimas atliekamas sumažinant plėtrą iki trumpų ciklų, vadinamų iteracijos, trunka 2-3 savaites. Iteracija yra užduočių, kurias planuojama atlikti, rinkinys tam tikras laikotarpis laikas. Kiekvienoje iteracijoje sukuriama veikianti programinės įrangos sistemos versija, kurioje didžiausias prioritetas (šiai iteracijai) klientų reikalavimus. Kiekviena iteracija atlieka visas užduotis, reikalingas kuriant veikiančią programinę įrangą: planavimą, reikalavimų analizę, projektavimą, kodavimą, testavimą ir dokumentacija. Nors išleidimui paprastai neužtenka vienos iteracijos nauja versija produktas, suprantama, kad srovė programinė įranga paruoštas leidimui kiekvienos iteracijos pabaigoje. Kiekvienos iteracijos pabaigoje komanda iš naujo nustato programinės įrangos produkto reikalavimų prioritetus, galbūt pakoreguodama sistemos kūrimą.

Judraus vystymosi principai ir prasmė

Agile plėtros metodikai yra paskelbti pagrindiniai postulatai, leidžiantys komandoms pasiekti aukštą našumą:

• žmonės ir jų sąveika;
• Darbinės programinės įrangos pristatymas;
• bendradarbiavimas su klientu;
• atsakas į pokyčius.

Žmonės ir bendravimas.Žmonės yra patys svarbiausi komponentas sėkmė. Atskiri komandos nariai ir geras bendravimas yra būtini gerai veikiančioms komandoms. Siekiant palengvinti bendravimą, judrios praktikos apima dažnas darbo rezultatų ir sprendimų keitimo diskusijas. Diskusijos gali būti rengiamos kasdien po kelias minutes ir kiekvienos iteracijos pabaigoje, analizuojant darbo rezultatus ir retrospektyvą. Kad susitikimų metu bendrautų efektyviai, komandos nariai turi laikytis toliau nurodytų dalykų pagrindinės taisyklės elgesys:

• pagarba kiekvieno komandos nario nuomonei;
• būti tiesus bet kokiame bendravime;
• visų duomenų, veiksmų ir sprendimų skaidrumas;
• pasitikėjimas, kad kiekvienas dalyvis palaikys komandą;
• įsipareigojimas komandai ir jos tikslams.

Be veiksmingos komandos ir geros komunikacijos, reikia tobulų programinės įrangos įrankių, kad būtų galima sukurti našias komandas naudojant judrias metodikas.

Veikianti programinė įranga yra svarbesnė už išsamią dokumentaciją. Visose judriose metodikose pabrėžiamas poreikis iš anksto nustatytais intervalais klientui pristatyti mažas veikiančios programinės įrangos dalis. Programinė įranga, kaip taisyklė, turi išlaikyti vieneto testavimo lygį, testavimą sistemos lygiu. Dokumentų kiekis turėtų būti minimalus. Projektavimo proceso metu komanda turėtų nuolat atnaujinti trumpą dokumentą, kuriame būtų motyvuotas sprendimas ir struktūros aprašymas.

Bendradarbiavimas su užsakovu yra svarbesnis nei formalūs susitarimai pagal sutartį. Kad projektas būtų sėkmingai užbaigtas, būtinas reguliarus ir dažnas bendravimas su užsakovu. Klientas turi nuolat dalyvauti aptariant priimtus sprendimus dėl programinės įrangos, išsakyti savo pageidavimus ir pastabas. Norint sukurti kokybišką produktą, būtina įtraukti klientą į programinės įrangos kūrimo procesą.

Greitai reaguoti į pokyčius svarbiau nei laikytis plano. Gebėjimas reaguoti į pokyčius daugiausia lemia programinės įrangos projekto sėkmę. Kuriant programinės įrangos produktą jie dažnai keičiasi klientų reikalavimus. Klientai dažnai tiksliai nežino, ko nori, kol nepamato, kad tai veikia. programinė įranga. Agile metodikos ieško atsiliepimų iš klientų kuriant programinės įrangos produktą. Norint sukurti produktą, kuris teiktų klientų pasitenkinimą ir verslo vertę, būtina reaguoti į pokyčius.

Judraus vystymosi principai remiasi 12 principų. Agile specifinės metodikos apibrėžia procesus ir taisykles, kurios daugiau ar mažiau atitinka šiuos principus. Lanksčios programinės įrangos produktų kūrimo metodikos grindžiamos šiais principais:

1. Didžiausias prioritetas yra patenkinti kliento norus per trumpą laiką pateikiant naudingą programinę įrangą su vėlesniais nuolatinis atnaujinimas. Agile praktika apima greitą pradinį leidimą ir dažnus atnaujinimus. Komandos tikslas – pristatyti veikiančią versiją per kelias savaites nuo projekto pradžios. Toliau programinės įrangos sistemos laipsniškai plečiantis funkcionalumas turėtų būti pristatomas kas kelias savaites. Klientas gali pradėti komercinė operacija sistema, jei jis mano, kad ji pakankamai veikia. Be to, klientas gali tiesiog skaityti Dabartinė versija programinę įrangą, pateikite atsiliepimus su komentarais.
2. Neignoruokite besikeičiančių reikalavimų, net ir vėlyvoje kūrimo stadijoje. Judrūs procesai leidžia prisitaikyti prie pokyčių siekiant užtikrinti Konkurencinis pranašumas klientas. Komandos, taikančios judrias metodikas, siekia, kad programos struktūra būtų kokybiška, su minimaliu pakeitimų poveikiu visai sistemai.
3. Naujas veikiančias programinės įrangos versijas teikite dažnai, kas savaitę ar du mėnesius, pirmenybę teikiant trumpesniems terminams. Kartu siekiama pateikti vartotojo poreikius atitinkančią programą su minimalia pridedama dokumentacija.
4. Klientai ir kūrėjai turi dirbti kartu viso projekto metu. Manoma, kad norint, kad projektas pavyktų, klientai, kūrėjai ir visos suinteresuotosios šalys turi bendrauti dažnai ir įvairiais būdais, siekiant kryptingai tobulinti programinį produktą.
5. Projektus turėtų įgyvendinti motyvuoti žmonės. Suteikite projekto komandai sveiką darbo aplinką, suteikite jiems reikalingą paramą ir pasitikėkite, kad komandos nariai atliks darbą.
6. Veiksmingiausias ir produktyviausias būdas perduoti informaciją kūrėjų komandai ir keistis nuomonėmis joje yra pokalbis akis į akį. Judriuose projektuose pagrindinis bendravimo būdas yra paprasta žmonių sąveika. Rašytiniai dokumentai kuriami ir atnaujinami laipsniškai tobulėjant programinei įrangai ir tik tada, kai to reikia.
7. Darbo programa yra pagrindinis projekto eigos rodiklis. Judraus projekto artėjimas iki užbaigimo vertinamas pagal tai, kiek turima Šis momentas programa atitinka užsakovo reikalavimus.
8. Judrūs procesai skatina ilgalaikę plėtrą. Klientai, kūrėjai ir vartotojai turi turėti galimybę neribotą laiką išlaikyti pastovų tempą.
9. Nenumaldomas dėmesys inžinerijos meistriškumui ir kokybiškam dizainui padidina judrių technologijų grąžą. Agile komandos nariai stengiasi sukurti kokybišką kodą reguliariai pertvarkydami.
10. Paprastumas yra menas pasiekti daugiau darant mažiau. Komandos nariai einamąsias užduotis sprendžia kuo paprasčiau ir efektyviau. Jei ateityje kiltų problemų, kokybės kodą galima pakeisti be didelių išlaidų.
11. Geriausią architektūrą, reikalavimus ir dizainą sukuria savarankiškai besiorganizuojančios komandos. Lanksčiose komandose užduotys skiriamos ne atskiriems nariams, o visai komandai. Pati komanda nusprendžia, kaip geriausiai įgyvendinti užsakovo reikalavimus. Komandos nariai bendradarbiauja visais projekto aspektais. Kiekvienam dalyviui leidžiama prisidėti prie bendro tikslo. Nė vienas komandos narys nėra atsakingas tik už architektūrą, reikalavimus ar testus.
12. Komanda turėtų reguliariai galvoti, kaip tapti dar efektyvesnė, o tada atitinkamai pakoreguoti ir patobulinti savo elgesį. Judrus kolektyvas nuolat koreguoja savo organizaciją, taisykles, susitarimus ir santykius.

Minėti principai tam tikru mastu atitinka daugybę programinės įrangos kūrimo metodikų:

Judrus modeliavimas	sąvokų, principų ir technikų (praktikų) rinkinys, leidžiantis greitai ir paprastai atlikti modeliavimą ir dokumentavimą programinės įrangos kūrimo projektuose;
Agile Unified Process (AUP)	supaprastinta IBM RationalUnifiedProcess (RUP) versija, kurioje aprašomas paprastas ir suprantamas aproksimacija (modelis) kuriant programinę įrangą verslo programoms;
Atidaryti	tai iteracinis-prieauginis programinės įrangos kūrimo metodas. Padėtas kaip lengvas ir lankstus RUP variantas;
AgileDataMethod	pasikartojančių programinės įrangos kūrimo metodų grupė, kurioje reikalavimai ir sprendimai pasiekiami bendradarbiaujant skirtingoms tarpfunkcinėms komandoms;
DSDM	dinaminių sistemų kūrimo metodika, pagrįsta greito taikomųjų programų kūrimo koncepcija (RapidApplicationDevelopment, RAD). Atstovauja kartotiniam ir laipsniškam metodui, kuris pabrėžia nuolatinį vartotojo / vartotojo dalyvavimą procese;
Ekstremalus programavimas (XP)	ekstremalus programavimas;
Adaptyvusis programinės įrangos kūrimas (ADD)	adaptyvi programinės įrangos kūrimas;
Funkcijomis pagrįstas vystymas (FDD)	plėtra, orientuota į laipsnišką funkcionalumo papildymą;
Tapti tikru	iteracinis metodas be funkcinių specifikacijų, naudojamas žiniatinklio programoms;
MSFfogAgileSoftwareDevelopment	Agile programinės įrangos kūrimo metodika iš Microsoft;
Scrum	nustato kūrimo proceso valdymo taisykles ir leidžia naudoti esamą kodavimo praktiką koreguojant reikalavimus arba atliekant taktinius pakeitimus [