V prvej časti sme na porovnanie metodík vývoja softvéru zvolili také ukazovatele ako pomer metodiky k iteračnému vývoju a stupeň formálnosti pri navrhovaní pracovných materiálov a vo všeobecnosti vo vývoji. V tejto časti používame tieto metriky na porovnanie najznámejších postupov vývoja softvéru.

Uvidíme ako to pôjde…

Toto je, žiaľ, najťažšie opísaná kategória – veď do nej patrí jednak produkt kŕčovitého zhadzovania začiatočníka snažiaceho sa za každú cenu dokončiť svoj prvý projekt, jednak celkom vyspelé a zabehnuté metodiky, ktoré pohlcujú dlhé roky. a rôznorodé skúsenosti konkrétnych vývojových tímov a dokonca popísané v interných predpisoch. Keďže ľudia, ktorí sú schopní vyvinúť si vlastnú metodiku, ju spravidla dokážu sami zhodnotiť z hľadiska iterácie a formalizácie, zameriame sa na začiatočníkov. Bohužiaľ, najčastejšie to znamená, že pravidlá na vykonávanie rozvoja buď vôbec neexistujú, alebo boli vyvinuté a prijaté, ale nerealizujú sa. Prirodzená je v takýchto podmienkach extrémne nízka úroveň rozvojového formalizmu. Takže toto je všetko jasné.

Vývoj "Ako to funguje"

Čo tak iteratívny prístup? Bohužiaľ, spravidla sa v takýchto projektoch nepoužíva. Predovšetkým preto, že by to umožnilo už pri prvých opakovaniach vyhodnotiť projekt ako mimoriadne pochybný a vyžadujúci naliehavý zásah vyššieho manažmentu na obnovenie poriadku. Koniec koncov, v iteratívnom projekte tradičná odpoveď programátora, že všetko je pre neho na 90% pripravené, trvá len do dokončenia prvej iterácie…

Štrukturálne metodológie

Štrukturálne metodológie

Štrukturálne metódy sú skupinou metodológií vyvinutých spravidla ešte pred rozšírením objektovo orientovaných jazykov. Všetky zahŕňajú vývoj vodopádov. Hoci, ako sa ukázalo, ešte v tom článku, ktorý sa často uvádza ako prvá prezentácia vodopádového prístupu, bolo povedané, že je žiaduce začať projekt vývojom prototypu, teda vykonať aspoň dve iterácie.

Základom týchto metodík je však postupný prechod z práce do práce a odovzdávanie výsledkov (dokumentov) ďalšej etapy účastníkom ďalšej.

Taktiež všetky tieto metodiky predpokladajú vysoko formalizovaný prístup, aj keď možno v nich nájsť vyjadrenia o primeranom množstve dokumentácie. Jedným z nesamozrejmých príkladov toho, že metodiky vývoja softvéru vyvinuté nielen na Západe, je citát z knihy vydanej u nás začiatkom 80. rokov, v ktorej sa uvádza, že miera formalizácie programovacej úlohy by sa mala určiť na základe o tom, ako dobre je analytik a programátor. A to aj napriek tomu, že téma knihy zahŕňala vývoj dosť kritických, ako sa dnes nazývajú, systémov, ktorých chyby vedú k vážnym stratám či dokonca katastrofám.

Agilné metodiky

Agilné metodiky sú založené na desiatich princípoch, z ktorých vymenujeme len tie, ktoré určujú posudzovanie týchto metodík podľa zvolených parametrov:

• hlavné je uspokojiť zákazníka a dodať mu produkt čo najskôr;
• nové verzie produktu by sa mali objaviť každých pár týždňov, v extrémnych prípadoch - mesiace;
• najviac efektívna metóda prenos vedomostí účastníkom rozvoja a medzi nimi - osobná komunikácia;
• bežiaci program je najlepším indikátorom pokroku vo vývoji.

Tieto metódy sú teda jednoznačne zamerané na iteratívny vývoj softvéru a minimálnu formalizáciu procesu. Pokiaľ však ide o druhý bod, je potrebné urobiť výhradu: tieto metódy sú zamerané na minimum prípustné pre tento projektúroveň formalizácie. Minimálne jedna z metodík zahrnutých do flexibilnej skupiny – Crystal – má modifikácie určené na vykonávanie procesov s rôznym počtom účastníkov a rôznou kritickosťou vyvíjaného softvéru (kritickosť softvéru je určená možnými následkami chýb, ktoré sa môžu líšiť od menších finančné straty pri oprave chyby na katastrofickú). Aby ďalšie porovnávanie s flexibilnými metodikami nebolo zbytočné, uvádzame krátke popisy niekoľko z nich.

eXtreme Programming alebo XP (extrémne programovanie)

Metodológia XP, ktorú vyvinuli Kent Beck, Ward Cunningham a Ron Jeffries, je dnes najznámejšou z agilných metodík. Niekedy sa samotný koncept „agilných metodológií“ explicitne alebo implicitne stotožňuje s XP, ktorý káže spoločenskosť, jednoduchosť, spätná väzba a odvahu. Opisuje sa ako súbor praktík: hra plánovania, krátke vydania, metafory, jednoduchý dizajn, refaktorovanie kódu (refaktorovanie), vývoj vopred na testovanie, párové programovanie, kolektívne vlastníctvo kódu, 40-hodinový pracovný týždeň, neustála prítomnosť zákazníka a kódové normy. Záujem o XP rástol zdola nahor – od vývojárov a testerov, sužovaných bolestivým procesom, dokumentáciou, metrikami a iným formalizmom. Neodmietali disciplínu, ale neboli ochotní nezmyselne dodržiavať formálne požiadavky a hľadali nové rýchle a flexibilné prístupy k rozvoju kvalitných programov.

Pri používaní XP je starostlivý predbežný návrh softvéru nahradený na jednej strane neustálou prítomnosťou zákazníka v tíme, pripraveného odpovedať na akúkoľvek otázku a zhodnotiť akýkoľvek prototyp a na druhej strane pravidelné revízie kódu (tzv. refaktorovanie). Dôkladne komentovaný kód sa považuje za základ projektovej dokumentácie. Veľká pozornosť v metodológii sa venuje testovaniu. Spravidla sa pre každú novú metódu najskôr zapíše test a potom sa vyvíja skutočný kód metódy, až kým test nezačne úspešne prebiehať. Tieto testy sú uložené v balíkoch, ktoré sa automaticky vykonajú po akejkoľvek zmene kódu.

Aj keď párové programovanie a 40-hodinový pracovný týždeň sú snáď najznámejšie funkcie XP, stále majú podporný charakter a prispievajú k vysokej produktivite vývojárov a zníženiu chýb vo vývoji.

Krištáľovo čistý

Crystal je rodina metodológií, ktoré určujú požadovaný stupeň formalizácie procesu vývoja v závislosti od počtu účastníkov a kritickosti úloh.

Metodológia Crystal Clear je z hľadiska výkonu nižšia ako XP, ale jej použitie je čo najjednoduchšie. Jeho implementácia si vyžaduje minimálne úsilie, pretože sa zameriava na ľudské návyky. Predpokladá sa, že táto metodika popisuje prirodzený poriadok vývoja softvéru, ktorý je stanovený v dostatočne kvalifikovaných tímoch, ak nie sú zapojené do cieľavedomej implementácie inej metodiky.

Kľúčové vlastnosti Crystal Clear:

• iteratívny prírastkový vývoj;
• automatické regresné testovanie;
• používatelia sú zapojení do aktívnej účasti na projekte;
• skladbu dokumentácie určujú účastníci projektu;
• spravidla sa používajú nástroje na kontrolu verzií kódu.

Okrem Crystal Clear existuje niekoľko ďalších metodológií v rodine Crystal určených pre väčšie alebo kritickejšie projekty. Líšia sa o niečo prísnejšími požiadavkami na množstvo dokumentácie a podporných procedúr, ako je zmena a kontrola verzií.

Vývoj riadený funkciami

Feature Driven Development (FDD) funguje z hľadiska systémovej funkcie alebo funkcie, ktorá je dosť blízka konceptu prípadu použitia RUP. Snáď najvýznamnejším rozdielom je dodatočné obmedzenie: „každá funkcia musí umožniť implementáciu najneskôr do dvoch týždňov.“ To znamená, že ak je prípad použitia dostatočne malý, možno ho považovať za funkciu, a ak je veľký, mal by sa rozdeliť na niekoľko relatívne nezávislých funkcií.

FDD zahŕňa päť procesov, pričom posledné dva sa opakujú pre každú funkciu:

• rozvoj všeobecný model;
• zostavenie zoznamu potrebných funkcií systému;
• plánovanie práce na každej funkcii;
• funkčný dizajn;
• konštrukcia funkcie.

Práca na projekte zahŕňa časté zostavovanie a je rozdelená do iterácií, z ktorých každá je implementovaná pomocou špecifického súboru funkcií.

Vývojári vo FDD sa delia na „triednych majstrov“ a „hlavných programátorov“. Hlavní programátori zapájajú vlastníkov zapojených tried do práce na ďalšej vlastnosti. Pre porovnanie: v XP nie sú osobne zodpovední za triedy alebo metódy.

Spoločné znaky

Zoznam flexibilných metodík je v súčasnosti pomerne široký. Napriek tomu, metodológie, ktoré sme opísali, poskytujú veľmi úplný obraz o celej rodine.

Takmer všetky agilné metodiky využívajú iteratívny prístup, pri ktorom sa detailne plánuje len obmedzené množstvo práce súvisiacej s vydaním ďalšieho vydania.

Takmer všetky agilné metodiky sú zamerané na čo najneformálnejší prístup k rozvoju. Ak sa problém dá vyriešiť v rámci bežného rozhovoru, potom je lepšie to urobiť. A kresliť rozhodnutie v papierovej forme resp elektronický dokument potrebné len vtedy, keď sa bez neho nedá zaobísť.

Agilné metodiky

GOST

GOST, podobne ako požiadavky CMM opísané v ďalšej časti, nie sú metodikami. Spravidla nepopisujú samotné procesy vývoja softvéru, ale iba formulujú určité požiadavky na procesy, ktorým v tej či onej miere zodpovedajú rôzne metodológie. Porovnanie požiadaviek podľa rovnakých kritérií, podľa ktorých porovnávame metodiky, vám pomôže okamžite rozhodnúť, ktoré metodiky by ste mali použiť, ak potrebujete vyvinúť v súlade s GOST.

V súčasnosti sú v Rusku v platnosti staré GOST 19. a 34. série a novšie GOST R ISO IEC 122207. GOST 19. a 34. série sú striktne zamerané na kaskádový prístup k vývoju softvéru. Vývoj v súlade s týmito GOST sa vykonáva v etapách, z ktorých každá zahŕňa výkon presne definovanej práce a končí vydaním pomerne veľkého počtu veľmi formalizovaných a rozsiahlych dokumentov. Okamžité prísne dodržiavanie týchto noriem teda vedie nielen k vodopádovému prístupu, ale poskytuje aj veľmi vysoký stupeň formalizácia vývoja.

Požiadavky GOST

GOST 12207, na rozdiel od noriem 19. a 34. série, popisuje vývoj softvéru ako súbor hlavných a pomocných procesov, ktoré môžu fungovať od začiatku do konca projektu. Model životný cyklus možno vybrať na základe špecifík projektu. Tento GOST teda výslovne nezakazuje použitie iteračného prístupu, ale výslovne neodporúča jeho použitie. GOST 12207 je flexibilnejší aj z hľadiska požiadaviek na formálnosť procesu vývoja. Obsahuje len náznaky potreby dokumentácie hlavných výsledkov všetkých procesov, neobsahuje však zoznamy požadovaných dokumentov a pokyny k ich obsahu.

GOST 12207 teda umožňuje iteratívny a menej formalizovaný vývoj softvéru.

Modely zrelosti procesu vývoja (CMM, CMMI)

Okrem národných a medzinárodných štandardov existuje viacero prístupov k certifikácii vývojového procesu. Najznámejšie z nich v Rusku sú zjavne CMM a CMMI.

CMM (Capability Maturity Model) je model vyspelosti procesov vývoja softvéru, ktorý je určený na posúdenie úrovne vyspelosti procesu vývoja v konkrétnej spoločnosti. Podľa tohto modelu existuje päť úrovní zrelosti vývojového procesu. Prvá úroveň zodpovedá vývoju „ako to chodí“, keď vývojári idú na každý projekt ako na výkon. Druhý zodpovedá viac-menej zabehnutým procesom, kedy je možné s dostatočnou istotou počítať s pozitívnym výsledkom projektu. Tretia zodpovedá prítomnosti rozvinutých a dobre popísaných procesov používaných pri vývoji a štvrtá zodpovedá aktívnemu využívaniu metrík v procese riadenia na stanovovanie cieľov a sledovanie ich dosahovania. Napokon piata úroveň sa týka schopnosti spoločnosti optimalizovať proces podľa potreby.

Požiadavky na CMM a CMMI

Po nástupe CMM sa začali vytvárať špecializované modely zrelosti informačné systémy, pre proces výberu dodávateľov a niektoré ďalšie. Na ich základe bol vyvinutý integrovaný model CMMI (Capability Maturity Model Integration). Okrem toho sa v CMMI uskutočnil pokus prekonať nedostatky CMM, ktoré sa v tom čase prejavili - zveličovanie úlohy formálne popisy procesov, kde bola prítomnosť určitej dokumentácie hodnotená výrazne vyššie ako len dobre zavedený, no nepopísaný proces. CMMI sa však zameriava aj na používanie vysoko formalizovaného procesu.

Základom modelov CMM a CMMI je teda formalizácia procesu vývoja. Zameriavajú sa na vývojárov na implementáciu procesu podrobne opísaného v predpisoch a pokynoch, ktoré si zase môžu vyžadovať vypracovanie veľkého množstva projektovej dokumentácie pre náležitú kontrolu a podávanie správ.

Vzťah CMM a CMMI k iteratívnemu vývoju je nepriamejší. Formálne ani jeden z nich nepredložil špecifické požiadavky na dodržiavanie vodopádového alebo iteračného prístupu. Podľa niektorých odborníkov je však CMM kompatibilnejší s vodopádovým prístupom, zatiaľ čo CMMI umožňuje aj iteračný prístup.

RUP

Samozrejme, RUP je iteratívna metodológia. Hoci formálne nie je v RUP nikde uvedené povinné vykonávanie všetkých fáz alebo nejaký minimálny počet iterácií, celý prístup je zameraný na to, že ich je pomerne veľa. Obmedzený počet iterácií vám neumožňuje plne využiť výhody RUP. Zároveň je možné RUP použiť aj v takmer kaskádových projektoch, ktoré skutočne zahŕňajú len niekoľko iterácií: jednu vo fáze Build a druhú vo fáze Transfer. Mimochodom, toto je počet iterácií, ktorý sa v skutočnosti používa vo vodopádových projektoch. Koniec koncov, testovanie a skúšobná prevádzka systému zahŕňa vykonanie opráv, ktoré môžu zahŕňať určité činnosti súvisiace s analýzou, návrhom a vývojom, to znamená, že v skutočnosti ide o ďalší prechod všetkými fázami vývoja.

Metodika RUP

S ohľadom na formálnosť metodiky RUP predstavuje užívateľovi veľmi široké možnosti. Ak urobíte všetku prácu a úlohy, vytvoríte všetky artefakty a pomerne formálne (s oficiálnym recenzentom, s prípravou úplnej recenzie vo forme elektronického alebo papierového dokumentu atď.) vykonáte všetky recenzie, RUP sa môže obrátiť je extrémne formálna, ťažkopádna metodológia. RUP zároveň umožňuje vyvíjať len tie artefakty a vykonávať len tie práce a úlohy, ktoré sú v konkrétnom projekte nevyhnutné. A vybrané artefakty možno vykonať a skontrolovať s ľubovoľným stupňom formálnosti. Je možné požadovať podrobné preštudovanie a starostlivé vyhotovenie každého dokumentu, zabezpečenie rovnako starostlivo vykonanej a formalizovanej kontroly a dokonca podľa starej praxe schváliť každú takúto kontrolu vedeckej a technickej rade podniku. Môžete obmedziť email alebo načrtnúť na papier. Okrem toho je tu vždy ešte jedna možnosť: sformovať si v hlave dokument, teda zamyslieť sa nad príslušným problémom a urobiť konštruktívne rozhodnutie. A ak sa toto rozhodnutie týka iba vás, obmedzte sa napríklad na komentár v kóde programu.

RUP je teda iteratívna metodika s veľmi širokým záberom možné riešenia v zmysle formalizácie procesu vývoja.

Zhrňme si druhú časť článku. RUP, na rozdiel od väčšiny ostatných metodík, umožňuje zvoliť si stupeň formalizácie a iterácie vývojového procesu v širokom rozsahu v závislosti od charakteristík projektov a rozvíjajúcej sa organizácie.

A prečo je to také dôležité - budeme diskutovať v ďalšej časti.

1. Cascade (anglický vodopád) - štandardný vývojový model

Kaskádový vývojový model - model, v ktorom sa všetky fázy vývoja vykonávajú postupne - ďalšia fáza začína po dokončení predchádzajúcej.

Tento model zahŕňa nasledujúce kroky v procese vývoja softvéru:

Najprv sa určia technické parametre budúceho programu, výsledkom čoho je schválenie zoznamu softvérových požiadaviek. Nasleduje prechod k dizajnu, počas ktorého sa vytvára dokumentácia, ktorá programátorom popisuje plán a spôsob implementácie požiadaviek.

Po dokončení návrhu programátori implementujú (zostavia) projekt. Vo fáze implementácie sú všetky komponenty projektu integrované. Až po úplnom dokončení týchto etáp nasleduje testovanie a ladenie hotového produktu. Softvérový produkt je možné ďalej implementovať a po implementácii poskytovať podporu - zavádzať novú funkcionalitu a odstraňovať chyby.

Hlavné výhody vývoja vodopádov:

2. Agilná metodika vývoja softvéru

Rad vývojových metodík softvér poskytovanie spoločná práca zástupcovia zákazníka a vývojárov. Metóda agilného vývoja je založená na iteratívnom prístupe, dynamickom formovaní požiadaviek a ich implementácii v krátkych etapách.

Výsledkom každej takejto fázy, vrátane cyklu iterácií, je miniatúrny softvérový projekt,

Agilných vývojových metód je viacero, najznámejšie sú Scrum, Extreme Programming, DSDM.

Hlavné výhody agilného vývoja:

		minimalizácia rizika; postupné zvyšovanie funkčnosti softvérový produkt; malé množstvo písomnej dokumentácie; spustenie základnej verzie programu čo najskôr.
Existujú aj nevýhody:
		neschopnosť presne určiť rozpočet projektu; nemožnosť určiť presné načasovanie pripravenosti projektu; nevhodné pre štátne a rozpočtové organizácie; vyžaduje motiváciu od zodpovedných zástupcov zákazníka.

Manifest agilného vývoja softvéru Neustále objavujeme lepšie spôsoby vývoja softvéru priamym vývojom a pomocou ostatným. Vďaka odvedenej práci sme si mohli uvedomiť, že: Ľudia a interakcia dôležitejšie ako procesy a nástroje Pracovný produkt dôležitejšie ako komplexná dokumentácia Spolupráca so zákazníkom dôležitejšie ako vyjednávanie o podmienkach zmluvy Dôležitejšia je pripravenosť na zmenu podľa pôvodného plánu To znamená, že bez popierania dôležitosti toho, čo je vpravo, si stále viac vážime to, čo je vľavo.

Princípy agilného vývoja:

Spokojnosť zákazníkov vďaka rýchlej a neprerušovanej dodávke potrebného softvéru; vítané zmeny v požiadavkách aj na konci vývoja (môže to zvýšiť konkurencieschopnosť výsledného produktu); časté dodávanie funkčného softvéru (každý mesiac alebo týždeň alebo aj častejšie); úzka, každodenná komunikácia medzi zákazníkom a vývojármi počas celého projektu; projekt realizujú motivovaní jednotlivci, ktorým sú poskytnuté potrebné pracovné podmienky, podpora a dôvera; odporúčaný spôsob prenosu informácií je osobný rozhovor (face to face); pracovný softvér je najlepším meradlom pokroku; sponzori, vývojári a používatelia musia byť schopní udržiavať konštantné tempo na dobu neurčitú; neustále zameranie na zlepšovanie technickej dokonalosti a užívateľsky prívetivého dizajnu; jednoduchosť - umenie nerobiť zbytočnú prácu; najlepší technické požiadavky, dizajn a architektúra sa získavajú od samostatne organizovaného tímu; neustále prispôsobovanie sa meniacim sa okolnostiam.

Anotácia: Flexibilný prístup k vývoju softvéru, zohľadňujú sa základné princípy flexibilného vývoja. Poskytuje sa zoznam techník, ktoré do určitej miery zodpovedajú princípom flexibilného vývoja softvéru. Analyzujú sa kľúčové hodnoty a princípy agilného rozvoja.

Prezentáciu k tejto prednáške si môžete stiahnuť.

Účel prednášky:

Získajte pochopenie účelu a základných princípov agilného vývoja softvéru.

Úvod

Agilná metodika vývoja softvéru zameraný na použitie iteračného prístupu, v ktorom softvér sa vytvára postupne, v malých krokoch, vrátane implementácie určitého súboru požiadaviek. Predpokladá sa, že požiadavky sa môžu zmeniť. Tímy využívajúce agilné metodiky sú tvorené všestrannými vývojármi, ktorí vykonávajú rôzne úlohy v procese vytvárania softvérového produktu.

Pri použití agilných metodík sa minimalizácia rizika uskutočňuje redukciou vývoja na sériu krátkych cyklov tzv iterácií, trvanie 2-3 týždne. Iterácia je súbor úloh naplánovaných na dokončenie v určitom časovom období. V každej iterácii sa vytvorí funkčná verzia softvérového systému, v ktorej má najväčšiu prioritu (pre túto iteráciu) požiadavky zákazníkov. Každá iterácia vykonáva všetky úlohy potrebné na vytvorenie funkčného softvéru: plánovanie, analýza požiadaviek, návrh, kódovanie, testovanie a dokumentáciu. Zatiaľ čo jedna iterácia vo všeobecnosti nestačí na uvoľnenie Nová verzia produktu, rozumie sa, že prúd softvér pripravený na uvoľnenie na konci každej iterácie. Na konci každej iterácie tím prehodnotí požiadavky na softvérový produkt, prípadne urobí úpravy vo vývoji systému.

Princípy a význam agilného rozvoja

Pre metodiku agilného vývoja sú deklarované kľúčové postuláty, ktoré umožňujú tímom dosahovať vysoký výkon:

• ľudia a ich interakcia;
• dodanie pracovného softvéru;
• spolupráca so zákazníkom;
• reakcia na zmenu.

Ľudia a interakcia.Ľudia sú najdôležitejšou súčasťou úspechu. Jednotliví členovia tímu a dobrá komunikácia sú nevyhnutné pre vysokovýkonné tímy. Na uľahčenie komunikácie zahŕňajú agilné postupy časté diskusie o pracovných výsledkoch a zmenách rozhodnutí. Diskusie môžu prebiehať denne niekoľko minút a na konci každej iterácie s analýzou výsledkov práce a retrospektívou. Na efektívnu komunikáciu na stretnutiach musia členovia tímu dodržiavať nasledujúce kľúčové pravidlá správania:

• rešpektovanie názoru každého člena tímu;
• byť pravdivý v akejkoľvek komunikácii;
• transparentnosť všetkých údajov, akcií a rozhodnutí;
• dôvera, že každý účastník podporí tím;
• oddanosť tímu a jeho cieľom.

Okrem efektívneho tímu a dobrej komunikácie sú potrebné dokonalé softvérové ​​nástroje na vytváranie vysokovýkonných tímov v agilných metodológiách.

Funkčný softvér je dôležitejší ako komplexná dokumentácia. Všetky agilné metodológie zdôrazňujú potrebu dodávať zákazníkovi malé kusy pracovného softvéru vo vopred stanovených intervaloch. softvér, spravidla musí prejsť úrovňou unit testovania, testovania na úrovni systému. Množstvo dokumentácie by sa malo obmedziť na minimum. Počas procesu návrhu by tím mal aktualizovať krátky dokument obsahujúci odôvodnenie rozhodnutia a popis štruktúry.

Spolupráca so zákazníkom je dôležitejšia ako formálne dohody podľa zmluvy. Pre úspešné ukončenie projektu je nevyhnutná pravidelná a častá komunikácia so zákazníkom. Zákazník sa musí pravidelne zúčastňovať diskusií o rozhodnutiach o softvéri, vyjadrovať svoje želania a pripomienky. Zapojenie zákazníka do procesu vývoja softvéru je nevyhnutné pre vytvorenie kvalitného produktu.

Rýchla reakcia na zmeny je dôležitejšia ako dodržiavanie plánu. Schopnosť reagovať na zmeny do značnej miery určuje úspech softvérového projektu. V procese tvorby softvérového produktu sa často menia požiadavky zákazníkov. Zákazníci často nevedia, čo presne chcú, kým neuvidia, že to funguje. softvér. Agilné metodiky hľadajú spätnú väzbu od zákazníkov v procese tvorby softvérového produktu. Schopnosť reagovať na zmeny je nevyhnutná na vytvorenie produktu, ktorý prináša spokojnosť zákazníkov a obchodnú hodnotu.

Zásady agilného vývoja sú podporované 12 princípmi. Agilné špecifické metodiky definujú procesy a pravidlá, ktoré viac-menej zodpovedajú týmto princípom. Flexibilné metodológie na vytváranie softvérových produktov sú založené na nasledujúcich princípoch:

1. Najvyššou prioritou je uspokojiť priania zákazníka dodávkou užitočného softvéru v krátkom čase s následnými priebežnými aktualizáciami. Agilné metódy znamenajú rýchle dodanie pôvodnej verzie a časté aktualizácie. Cieľom tímu je dodať pracovnú verziu do niekoľkých týždňov od spustenia projektu. Ďalej softvérové ​​systémy s postupne sa rozširujúcou funkcionalitou by sa mali odosielať každých pár týždňov. Zákazník môže spustiť komerčnú prevádzku systému, ak ho považuje za dostatočne funkčný. Zákazník sa tiež môže jednoducho zoznámiť s aktuálnou verziou softvéru, poskytnúť spätnú väzbu s komentármi.
2. Neignorujte meniace sa požiadavky, dokonca ani neskoro vo vývoji. Flexibilné procesy umožňujú zohľadňovať zmeny s cieľom zabezpečiť konkurenčnú výhodu zákazníka. Tímy využívajúce agilné metodiky sa snažia o to, aby bola programová štruktúra vysoko kvalitná s minimálnym dopadom zmien na systém ako celok.
3. Nové pracovné verzie softvéru dodávajte často, v intervaloch od jedného týždňa do dvoch mesiacov, pričom uprednostňujete kratšie termíny. Zároveň je cieľom dodať program, ktorý zodpovedá potrebám užívateľa, s minimom sprievodnej dokumentácie.
4. Zákazníci a vývojári musia spolupracovať počas celého projektu. Verí sa, že pre úspešný projekt musia zákazníci, vývojári a všetky zainteresované strany často a mnohými spôsobmi komunikovať, aby cielene zlepšovali softvérový produkt.
5. Projekty by mali realizovať motivovaní ľudia. Poskytnite projektovému tímu zdravé pracovné prostredie, poskytnite podporu, ktorú potrebujú, a verte, že členovia tímu prácu zvládnu.
6. Najúčinnejšou a najproduktívnejšou metódou sprostredkovania informácií vývojovému tímu a výmeny názorov v rámci neho je osobný rozhovor. V agilných projektoch je hlavným spôsobom komunikácie jednoduchá ľudská interakcia. Písomné dokumenty sa vytvárajú a aktualizujú postupne s vývojom softvéru a iba v prípade potreby.
7. Pracovný program je hlavným ukazovateľom pokroku projektu. Prístup agilného projektu k dokončeniu sa posudzuje podľa toho, koľko je k dispozícii tento moment program spĺňa požiadavky zákazníka.
8. Agilné procesy podporujú dlhodobý rozvoj. Zákazníci, vývojári a používatelia musia byť schopní udržiavať konštantné tempo na dobu neurčitú.
9. Neúnavné zameranie na inžiniersku dokonalosť a kvalitný dizajn zvyšuje návratnosť agilných technológií. Agilní členovia tímu sa snažia vytvárať kvalitný kód pravidelným refaktorovaním.
10. Jednoduchosť je umenie dosiahnuť viac tým, že urobíte menej. Členovia tímu riešia aktuálne úlohy čo najjednoduchšie a najefektívnejšie. Ak sa v budúcnosti vyskytne problém, potom je možné vykonať zmeny v kóde kvality bez veľkých nákladov.
11. Najlepšie architektúry, požiadavky a návrhy pochádzajú od samoorganizujúcich sa tímov. Vo flexibilných tímoch sa úlohy neprideľujú jednotlivým členom, ale tímu ako celku. Tím sám rozhodne, ako najlepšie zrealizovať požiadavky zákazníka. Členovia tímu spolupracujú na všetkých aspektoch projektu. Každý účastník môže prispieť na spoločnú vec. Žiadny člen tímu nie je výhradne zodpovedný za architektúru, požiadavky alebo testy.
12. Tím by mal pravidelne premýšľať o tom, ako sa stať ešte efektívnejšími, a podľa toho potom prispôsobiť a doladiť svoje správanie. Agilný tím neustále upravuje svoju organizáciu, pravidlá, dohody a vzťahy.

Vyššie uvedené princípy do určitej miery zodpovedajú množstvu metodík vývoja softvéru:

Agilné modelovanie	súbor konceptov, princípov a techník (praxov), ktoré umožňujú rýchlo a jednoducho vykonávať modelovanie a dokumentáciu v projektoch vývoja softvéru;
Agilný jednotný proces (AUP)	zjednodušená verzia IBM RationalUnifiedProcess(RUP), ktorá popisuje jednoduchú a zrozumiteľnú aproximáciu (model) na vytváranie softvéru pre podnikové aplikácie;
Sprístupniť	ide o iteratívno-inkrementálnu metódu vývoja softvéru. Umiestnené ako ľahká a flexibilná možnosť RUP;
AgileDataMethod	skupina iteračných metód vývoja softvéru, v ktorých sa požiadavky a riešenia dosahujú prostredníctvom spolupráce rôznych medzifunkčných tímov;
DSDM	metodika vývoja dynamických systémov založená na koncepte rýchleho vývoja aplikácií (RapidApplicationDevelopment, RAD). Predstavuje iteratívny a prírastkový prístup, ktorý zdôrazňuje nepretržité zapojenie užívateľa/spotrebiteľa do procesu;
Extrémne programovanie (XP)	extrémne programovanie;
Adaptívny vývoj softvéru (ADD)	vývoj adaptívneho softvéru;
Vývoj riadený funkciami (FDD)	vývoj zameraný na postupné dopĺňanie funkčnosti;
Získanie skutočného	iteratívny prístup bez funkčných špecifikácií používaný pre webové aplikácie;
MSFfogAgileSoftwareVývoj	Agilná metodika vývoja softvéru od spoločnosti Microsoft;
Scrum	stanovuje pravidlá pre riadenie procesu vývoja a umožňuje vám využiť existujúce kódovacie postupy úpravou požiadaviek alebo vykonaním taktických zmien [

1.Kódovanie

Vo fáze vývoja softvéru sa vykonávajú tieto hlavné akcie: kódovanie; testovanie; Vývoj referenčného systému pre softvér; vytváranie užívateľskej dokumentácie; vytvorenie verzie a inštalácia softvéru,

Kódovanie je proces konverzie výsledkov návrhu na vysokej a nízkej úrovni do hotového softvérového produktu. Inými slovami, pri kódovaní prebieha popis zostaveného PP modelu pomocou zvoleného programovacieho jazyka, ktorým môže byť ktorýkoľvek z existujúcich jazykov. Voľba jazyka sa vykonáva buď na žiadosť zákazníka, alebo s prihliadnutím na riešenú úlohu a osobná skúsenosť vývojárov.

Pri kódovaní je potrebné riadiť sa štandardom pre zvolený jazyk, napríklad pre jazyk C je to ANSI C a pre C++ je to ISO/IEC 14882 "Standart for the C++ ProgrammingLanguage".

Okrem všeobecne uznávaného štandardu pre programovací jazyk môže spoločnosť použiť aj vlastné dodatočné požiadavky na pravidlá pre písanie programov. V podstate sa týkajú pravidiel formátovania textu programu.

Dodržiavanie štandardu a pravidiel spoločnosti umožňuje vytvoriť program, ktorý funguje správne, je ľahko čitateľný, zrozumiteľný pre ostatných vývojárov, obsahuje informácie o vývojárovi, dátum vytvorenia, názov a účel, ako aj potrebné údaje pre správu konfigurácie.

Vo fáze kódovania programátor píše programy a sám ich testuje. Takéto testovanie sa nazýva testovanie jednotiek. Všetky otázky týkajúce sa testovania softvéru sú uvedené v kap. 10 popisuje aj technológiu testovania, ktorá sa používa vo fáze vývoja softvéru. Táto technika sa nazýva testovanie. "sklenený box" (sklenený box); niekedy nazývané aj testovanie "biely box" (whitebox) na rozdiel od klasického konceptu „black box“ (blackbox).

Pri testovaní čiernej skrinky sa s programom zaobchádza ako s objektom, ktorého vnútorná štruktúra je neznáma. Tester zadáva údaje a analyzuje výsledok, ale nevie, ako program funguje. Pri výbere testov špecialista hľadá vstupné údaje a podmienky, ktoré sú z jeho pohľadu zaujímavé, čo môže viesť k neštandardným výsledkom. V prvom rade ho zaujímajú tí zástupcovia každej triedy vstupných údajov, v ktorých sa s najväčšou pravdepodobnosťou objavia chyby testovaného programu.

Pri testovaní „skleneného boxu“ je situácia úplne iná. Tester (v tomto prípade samotný programátor) vyvíja testy na základe znalosti zdrojového kódu, ku ktorému má plný prístup. V dôsledku toho získa nasledujúce výhody.

1. Smer skúšania. Programátor môže testovať program po častiach, vyvíjať špeciálne testovacie podprogramy, ktoré volajú testovanú jednotku a odovzdávajú programátorovi údaje, ktoré ho zaujímajú. Jediný modul je oveľa jednoduchšie otestovať presne ako "sklenenú škatuľu".

2.Úplné pokrytie kódu. Programátor môže vždy určiť, ktoré fragmenty kódu fungujú v každom teste. Vidí, ktoré ďalšie vetvy kódu zostali netestované, a môže si vybrať podmienky, za ktorých budú testované. Tu je návod, ako sledovať svoj dosah programový kód vykonaných testoch.

3. Schopnosť kontrolovať tok príkazov. Programátor vždy vie, ktorá funkcia má byť v programe vykonaná ako ďalšia a aký má byť jej aktuálny stav. Ak chcete zistiť, či program funguje tak, ako si myslí, môže do neho programátor zahrnúť ladiace príkazy, ktoré zobrazujú informácie o priebehu jeho vykonávania, alebo použiť špeciálny softvérový nástroj zavolal debugger. Debugger môže robiť veľa užitočných vecí: sledovať a meniť postupnosť vykonávania príkazov programu, zobrazovať obsah svojich premenných a ich adresy v pamäti atď.

4. Schopnosť sledovať integritu údajov. Programátor vie, ktorá časť programu musí upraviť každý dátový prvok. Sledovaním stavu dát (pomocou rovnakého debuggera) dokáže identifikovať chyby ako sú zmeny dát nesprávnymi modulmi, ich nesprávna interpretácia alebo neúspešná organizácia.Programátor môže testovanie sám automatizovať.

5. Vízia vnútorných hraničných bodov. IN zdrojový kód tie hraničné body programu, ktoré sú skryté z vonkajšieho pohľadu, sú viditeľné. Napríklad na vykonanie určitej akcie možno použiť niekoľko úplne odlišných algoritmov a bez nahliadnutia do kódu nie je možné určiť, ktorý z nich si programátor vybral. Ďalším typickým príkladom by bol problém s pretečením vyrovnávacej pamäte, ktorý sa používa na dočasné ukladanie vstupných údajov. Programátor vie okamžite povedať, pri akom množstve dát pretečie vyrovnávacia pamäť a nemusí robiť tisíce testov.

6. Možnosť testovania, určená zvoleným algoritmom. Na testovanie spracovania dát, ktoré využíva veľmi zložité výpočtové algoritmy môže vyžadovať špeciálne techniky. Klasickými príkladmi sú maticová transformácia a triedenie údajov. Tester, na rozdiel od programátora, potrebuje presne vedieť, ktoré algoritmy sa používajú, takže sa musí odvolávať na odbornú literatúru.

Testovanie sklenenej skrinky je súčasťou procesu programovania. Programátori túto prácu robia stále, každý modul testujú po jeho napísaní a potom znova po jeho integrácii do systému.

Pri vykonávaní testovania jednotiek môžete použiť buď štrukturálne alebo funkčné testovacie techniky, alebo oboje.

Štrukturálne Testovanie je jedným typom testovania sklenených boxov. Jeho hlavnou myšlienkou je správna voľba testovanej softvérovej cesty. Na rozdiel od neho funkčné testovanie patrí do kategórie testovania „čiernej skrinky“. Každá funkcia programu je testovaná tak, že sa zoberie jej vstup a analyzuje sa výstup. V tomto prípade sa vnútorná štruktúra programu zohľadňuje veľmi zriedkavo.

Hoci štrukturálne testovanie má oveľa výkonnejšie teoretický základ, väčšina testerov preferuje funkčné testovanie. Štrukturálne testovanie je vhodnejšie pre matematické modelovanie, ale to vôbec neznamená, že je efektívnejšie. Každá z technológií umožňuje identifikovať chyby, ktoré v prípade použitia tej druhej chýbajú. Z tohto hľadiska ich možno nazvať rovnako účinnými.

Predmetom testovania môže byť nielen plná cesta program (postupnosť príkazov, ktoré vykonáva od začiatku do konca), ale aj jeho jednotlivé časti. Je absolútne nereálne testovať všetky možné spôsoby spustenia programu. Preto sa testeri odlišujú od všetkých možné spôsoby tie skupiny, ktoré musia byť nevyhnutne testované. Na výber používajú špeciálne kritériá tzv kritériá pokrytia (coveragecriteria), ktoré určujú celkom reálny (aj keď dosť veľký) počet testov. Tieto kritériá sa niekedy nazývajú logické kritériá pokrytia, alebo kritériá úplnosti.

3. Vývoj systému pomoci pre softvérový produkt. Vytváranie užívateľskej dokumentácie

Je vhodné určiť jedného z projektových zamestnancov technickým redaktorom dokumentácie. Tento zamestnanec môže vykonávať inú prácu, ale jeho hlavnou úlohou by mala byť analýza dokumentácie, aj keď ju vypracúvajú iní zamestnanci.

Často sa stáva, že na tvorbe softvéru pracuje viacero ľudí, no nikto z nich nie je plne zodpovedný za jeho kvalitu. Výsledkom je, že softvér nielenže neťaží z jeho vývoja viacľudí, ale aj stráca, pretože každý podvedome presúva zodpovednosť na toho druhého a očakáva, že tú či onú časť práce urobia jeho kolegovia. Tento problém sa rieši ustanovením redaktora, ktorý je plne zodpovedný za kvalitu a správnosť technickej dokumentácie.

referenčný systém PP je vytvorený na základe materiálu vyvinutého pre užívateľskú príručku. Tvorí a vytvára ho zodpovedný za výkon tejto práce. Môže to byť buď technický editor, alebo jeden z vývojárov spolu s technickým editorom.

Dobre zdokumentovaný PP má nasledujúce výhody.

1. Jednoduché použitie. Ak je PP dobre zdokumentovaný, potom je oveľa jednoduchšie uplatniť. Používatelia sa to učia rýchlejšie, robia menej chýb a vďaka tomu robia svoju prácu rýchlejšie a efektívnejšie.

2. Nižšie náklady technická podpora. Keď používateľ nevie prísť na to, ako vykonať potrebné akcie, zavolá výrobcu softvéru na službu technickej podpory. Údržba takejto služby je veľmi nákladná. Dobrá príručka na druhej strane pomáha používateľom riešiť problémy samostatne a znižuje potrebu kontaktovať skupinu technickej podpory.

3. Vysoká spoľahlivosť. Nezrozumiteľná alebo nedbalá dokumentácia spôsobuje, že softvér je menej spoľahlivý, keďže jeho používatelia sa častejšie dopúšťajú chýb, je pre nich ťažké prísť na to, čo ich spôsobuje a ako sa vysporiadať s ich následkami.

Jednoduchosť sprevádzania. Obrovské množstvo peňazí a času sa vynakladá na analýzu problémov, ktoré sú spôsobené chybami používateľov. Zmeny vykonané v nových verziách softvéru sú často len zmenou rozhrania starých funkcií. Zavádzajú sa, aby používatelia konečne prišli na to, ako softvér používať a prestali volať službu technickej podpory. Dobré vedenie do značnej miery

Teraz v softvérovom inžinierstve existujú dva hlavné prístupy k vývoju softvéru IP, medzi ktorými je zásadný rozdiel spôsobený rôzne cesty dekompozícia systémov: funkčno-modulárny (štrukturálny) prístup, ktorý je založený na princípe funkčnej dekompozície, pri ktorom je štruktúra systému popísaná z hľadiska hierarchie jeho funkcií a prenosu informácií medzi jednotlivými systémami. funkčné prvky, A objektovo orientovaný prístup, ktorý využíva dekompozíciu objektov, popisuje štruktúru IS z hľadiska objektov a vzťahov medzi nimi a správanie systému z hľadiska zasielania správ medzi objektmi.

Podstata štrukturálneho prístupu k vývoju softvéru IS teda spočíva v jeho rozklade na automatizované funkcie: systém je rozdelený na funkčné podsystémy, ktoré sa zase delia na podfunkcie, delia sa na úlohy atď. postupy. IS zároveň zachováva celistvosť reprezentácie, kde sú všetky komponenty vzájomne prepojené. Pri vývoji systému „zdola nahor“, od jednotlivých úloh až po celý systém, sa stráca celistvosť, vznikajú problémy pri popisovaní informačnej interakcie jednotlivých komponentov.

Základné princípy štrukturálneho prístupu sú:

o princíp" rozdeľuj a panuj“;

o princíp hierarchické usporiadanie - princíp organizácie komponentových systémov do hierarchických stromových štruktúr s pridávaním nových detailov na každej úrovni. Výber z dvoch základné princípy neznamená, že ostatné princípy sú druhoradé, pretože ignorovanie ktoréhokoľvek z nich môže viesť k nepredvídateľným následkom.

Hlavnými z týchto princípov sú:

o abstrakciu - zdôraznenie základných aspektov systému;

o konzistenciu - platnosť a konzistentnosť prvkov systému;

o štruktúrovanie údajov - údaje by mali byť štruktúrované a hierarchicky usporiadané.

Metodologické základy technológií vývoja softvéru

Vizuálne modelovanie. Softvérový model sa vo všeobecnosti nazýva formalizovaný popis softvérového systému na určitej úrovni abstrakcie. Každý model definuje špecifický aspekt systému, používa súbor diagramov a dokumentov v danom formáte a odráža myšlienky a aktivity rôznych ľudí so špecifickými záujmami, rolami alebo úlohami.

Grafické (vizuálne) modely sú nástroje na vizualizáciu, popis, navrhovanie a dokumentovanie architektúry systému. Zloženie modelov použitých v každom konkrétnom projekte a stupeň ich podrobnosti vo všeobecnom prípade závisia od nasledujúcich faktorov:

o ťažkosti navrhnutého systému;

o nevyhnutnú úplnosť jeho popisu;

o vedomosti a zručnosti účastníkov projektu;

o čas vyhradený na dizajn.

Vizuálne modelovanie výrazne ovplyvnilo najmä vývoj nástrojov CASE. Pojem CASE (Computer Aided Software Engineering) sa používa v širokom zmysle. Pôvodný význam tohto konceptu, obmedzený len úlohami automatizácie vývoja softvéru, teraz nadobudol nový význam pokrýva väčšinu procesov životného cyklu softvéru.

Technológia CASE je súbor metód návrhu softvéru, ako aj súbor nástrojov, ktoré vám umožňujú vizuálne modelovať predmetnú oblasť, analyzovať tento model vo všetkých fázach vývoja a údržby softvéru a vyvíjať aplikáciu v súlade s informačnými potrebami používateľov. Väčšina existujúcich nástrojov CASE je založená na štrukturálnej alebo objektovo orientovanej analýze a metódach navrhovania, pričom používa špecifikácie vo forme diagramov alebo textov na opis externých požiadaviek, vzťahov medzi modelmi systému, dynamikou správania systému a softvérovými architektúrami.