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. K druhému bodu je však potrebné urobiť výhradu: tieto metódy sú zamerané na minimálnu úroveň formalizácie prijateľnú pre daný projekt. 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é, uvedieme stručné popisy niekoľkých 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:
- vývoj spoločného modelu;
- 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 k procesom, 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 ďalšie nový GOST R ISO IEC 122207. GOST 19. a 34. série sú prísne zamerané na kaskádový prístup k vývoju softvéru. Vývoj v súlade s týmito GOST sa uskutočňuje v etapách, z ktorých každá zahŕňa výkon presne definovanej práce a končí uvoľnením dostatočne Vysoké číslo vysoko formalizované a rozsiahle dokumenty. 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 bol v CMMI urobený pokus o prekonanie nedostatkov CMM, ktoré sa do tej doby prejavovali - zveličovanie úlohy formálnych popisov procesov, kedy sa prítomnosť určitej dokumentácie hodnotila oveľa vyššie ako len dobre zabehnutá, ale 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é množstvo 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 vykonávate všetky práce a úlohy, vytvárajte všetky artefakty a dostatočne formálne (s oficiálnym recenzentom, s prípravou plnohodnotnej recenzie vo forme elektronickej resp. papierový dokument atď.) na vykonávanie všetkých preskúmaní môže byť RUP veľmi formálnou, ťažkopádnou metodológiou. 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. Alebo sa môžete obmedziť na e-mail alebo náčrt na papieri. 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:
V prvom rade je to určené Technické špecifikácie budúci program, 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, ktorá zabezpečuje spoločnú prácu zástupcov 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ého produktu; 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éruNeustá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; |
Modely vývoja softvéru Vodopád Kaskádový model Špirála Extrémne programovanie Prototypovanie používateľského rozhrania Prírastkové testovanie modelu W Jednotný proces vývoja softvéru (USDP) Metodológia MSF
Vodopádový model Analýza požiadaviek Kompilácia špecifikácie produktu Návrh Kompilácia architektúry produktu Implementácia Vývoj zdrojového kódu Integrácia samostatných častí zdrojového kódu Testovanie a riešenie problémov
Extrémne programovanie Analýza počiatočných požiadaviek Návrh Integrácia Implementácia Testovanie nových požiadaviek Kontrola/Schválenie/Úprava plánu vývoja Uvoľnenie produktu
UI Prototyping Vydanie produktu Vývoj softvéru s ohľadom na zmeny Objasnenie požiadaviek a špecifikácií Úprava prototypu a zdokonalenie niektorých funkcionalít Základná funkcionalita Prototyp rozhrania Predbežná špecifikácia
Prírastkový vývoj Iterácia 1 Iterácia 2 …. Analýza požiadaviek Návrh Implementácia Testovanie komponentov Integrácia Testovanie celej iterácie N
Unified Software Development Process (USDP) Ø Use case model, popisuje prípady, v ktorých bude aplikácia použitá. Ø Analytický model popisuje základné triedy pre aplikáciu. Ø Návrhový model popisuje prepojenia a vzťahy medzi triedami a vybranými objektmi Ø Model nasadenia popisuje distribúciu softvéru medzi počítačmi. Ø Popisuje model implementácie vnútorná organizácia programový kód. Ø Testovací model pozostáva z testovacích komponentov, testovacích postupov a rôznych testovacích prípadov
Požiadavky na jednotný proces vývoja softvéru (USDP) Zhromažďovanie Iter 1…. Iter N Navrhuje sa Iter 1…. Iter N Implementácia Iter 1…. Iter N Navrhuje sa Iter 1…. Testovanie Iter N Iter 1…. Iter N
Typické komponenty architektúry softvérových produktov a typické softvérové požiadavky Ø Ø Ø Ø Organizácia programu Hlavné systémové triedy Organizácia údajov Obchodné pravidlá Používateľské rozhranie Správa zdrojov Bezpečnosť Výkon Škálovateľnosť Interakcia s inými systémami (integrácia) Internacionalizácia, lokalizácia Vstupno-výstupné údaje Spracovanie chýb
Typické komponenty architektúry softvérových produktov a typické softvérové požiadavky Odolnosť voči chybám je súbor vlastností systému, ktoré zvyšujú spoľahlivosť systému zisťovaním chýb, obnovou a izoláciou zlých následkov pre systém. Pri navrhovaní akéhokoľvek reálneho systému na zabezpečenie odolnosti voči poruchám je potrebné predvídať všetky možné situácie, ktoré môžu viesť k zlyhaniu systému a vyvinúť mechanizmy na zvládanie porúch. Spoľahlivosť je schopnosť systému odolávať rôznym poruchám a zlyhaniam. Porucha je prechod systému v dôsledku chyby do úplne nefunkčného stavu. Porucha je chyba v prevádzke systému, ktorá nevedie k zlyhaniu systému. Čím menej porúch a porúch po určitú dobu, tým je systém považovaný za spoľahlivejší.
Typické komponenty architektúry softvérového produktu a typické softvérové požiadavky Krivka spoľahlivosti N t 1 t Čím ďalej, tým ťažšie bude nájsť chybu. Čím je systém zložitejší, tým väčšia je pravdepodobnosť porúch a porúch.
Typické komponenty architektúry softvérového produktu a typické softvérové požiadavky Ø Možnosti implementácie vyvinutej architektúry. Ø Nadmerná funkčnosť. Ø Rozhodnutie o kúpe hotových softvérových komponentov. Ø Zmeňte stratégiu.
Kontrolný zoznam otázok, ktorý vám umožní vyvodiť záver o kvalite architektúry: Ø Je jasne popísaná celková organizácia programu; Ø Ø Ø Či špecifikácia obsahuje prehľad architektúry a jej zdôvodnenie. Sú správne definované hlavné zložky programu, ich oblasti zodpovednosti a interakcia s ostatnými zložkami. Či sú všetky funkcie uvedené v špecifikácii požiadaviek implementované primeraným počtom komponentov systému. Sú popísané a odôvodnené najdôležitejšie triedy. Či je uvedený popis organizácie databázy. Sú definované všetky obchodné pravidlá? Je popísaný ich vplyv na systém?
Kontrolný zoznam otázok, ktorý vám umožní urobiť záver o kvalite architektúry: Ø Je popísaná stratégia návrhu používateľského rozhrania. Ø Je to hotové užívateľské rozhranie modulárne, aby jeho zmeny neovplyvnili zvyšok systému. Øči je uvedený popis stratégie vstupu/výstupu údajov. Ø Či bola vykonaná analýza výkonu systému, ktorý bude implementovaný pomocou tejto architektúry. Ø Či bola vykonaná analýza spoľahlivosti navrhnutého systému. Ø Či bola vykonaná analýza problémov škálovateľnosti a rozšíriteľnosti systému.
Refaktorovanie softvéru Refaktorovanie zahŕňa prispôsobenie softvéru novému hardvér a na nové operačné systémy, nové vývojové nástroje, nové požiadavky a softvérovú architektúru a funkčnosť. Ide o zmenu vnútornej štruktúry softvéru bez jej zmeny. vonkajšie správanie navrhnuté tak, aby umožňovali úpravu softvéru. Primerané dôvody na refaktorovanie: Kód sa opakuje; implementácia metódy je príliš veľká; príliš veľa vnorení slučiek alebo samotná slučka je veľmi veľká; trieda má slabú konektivitu (vlastnosti a metódy triedy by mali popisovať iba 1 objekt); rozhranie triedy netvorí konzistentnú abstrakciu; metóda vyžaduje príliš veľa parametrov. Mali by ste sa snažiť obmedziť počet parametrov na rozumné minimum; jednotlivé časti triedy sa menia nezávisle od ostatných častí triedy;
Refaktorovanie softvéru pri zmene programu si vyžaduje paralelnú zmenu niekoľkých tried. Ak takáto situácia nastane, je potrebné reorganizovať triedy, aby sa minimalizovali miesta možných zmien v budúcnosti; musieť paralelne zmeniť niekoľko hierarchií dedičnosti; musíte zmeniť niekoľko blokov prípadu. Je potrebné upraviť program tak, aby sa vykonala implementácia bloku prípadu, a zavolať ho v programe požadovaný počet krát; súvisiace dátové členy používané spoločne nie sú usporiadané do tried. Ak opakovane používate rovnakú množinu dátových prvkov, potom je vhodné zvážiť skombinovanie týchto dát a umiestnenie operácií s nimi vykonávaných do samostatnej triedy;
Metóda refaktorovania softvéru používa viac prvkov inej triedy ako jej vlastných. To znamená, že metódu je potrebné presunúť do inej triedy a zavolať ju zo starej; elementárny dátový typ je preťažený. Na opísanie podstaty skutočného sveta je lepšie použiť akúkoľvek triedu, než ktorúkoľvek preťažovať existujúci typúdaje; trieda má príliš obmedzenú funkčnosť. Je lepšie sa tejto triedy zbaviť prenesením jej funkčnosti do inej triedy; „zatúlané“ údaje sa prenášajú v reťazci metód. Údaje, ktoré sa prenesú do metódy, aby sa preniesli do inej metódy, sa nazývajú stratené údaje. Keď nastanú takéto situácie, skúste zmeniť architektúru tried a metód, aby ste sa ich zbavili.
Refaktorovanie mediálneho objektu nerobí nič. Ak je úlohou triedy presmerovať volania metód na iné triedy, potom je najlepšie odstrániť tento proxy server a volať priamo do iných tried; jedna trieda vie príliš veľa o inej triede. V tejto situácii je potrebné zapuzdrenie sprísniť, aby sa zabezpečilo, že dedič bude mať minimálne vedomosti o svojom rodičovi; metóda má nešťastný názov; dátové členy sú verejné. Toto stiera hranicu medzi rozhraním a implementáciou, nevyhnutne prerušuje zapuzdrenie a obmedzuje flexibilitu programu; uverejňovať komentáre v zdrojový kód;
Podtrieda refaktorovania softvéru používa len malý zlomok metód svojich predkov. Táto situácia nastane, keď sa vytvorí nová trieda len na zdedenie niekoľkých metód zo základnej triedy a nie na opis žiadnej novej entity. Aby sa tomu zabránilo, je potrebné transformovať základnú triedu takým spôsobom, aby umožnila prístup k novej triede iba metódam, ktoré potrebuje; kód obsahuje globálne premenné. Globálne by mali byť iba premenné, ktoré skutočne používa celý program. Všetky ostatné premenné musia byť buď lokálne, alebo sa musia stať vlastnosťami nejakého objektu; program obsahuje kód, ktorý môže byť jedného dňa potrebný. Pri vývoji systému je vhodné zabezpečiť miesta, kde je možné v budúcnosti pridať zdrojový kód.
Podstata štrukturálneho prístupu k vývoju softvéru EIS teda spočíva v jeho rozklade (rozdelení) na automatizované funkcie: systém je rozdelený na funkčné podsystémy, ktoré sa zase delia na podfunkcie, tie na úlohy atď. až po konkrétne postupy. Systém si zároveň zachováva holistický pohľad, v ktorom sú všetky jednotlivé komponenty vzájomne prepojené. Pri vývoji systému „zdola“ sa od jednotlivých úloh až po celý systém stráca celistvosť, vznikajú problémy pri popisovaní informačnej interakcie jednotlivých komponentov.
Všetky najbežnejšie metódy štrukturálneho prístupu sú založené na niekoľkých všeobecné zásady:
1. Princíp „rozdeľuj a panuj“;
2. Princíp hierarchického usporiadania - princíp usporiadania jednotlivých častí systému do hierarchických stromových štruktúr s pridaní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 ktorejkoľvek z nich môže viesť k nepredvídateľným následkom (vrátane zlyhania celého projektu“). Hlavnými z týchto princípov sú:
1. Princíp abstrakcie – zvýraznenie podstatných aspektov systému a odpútanie pozornosti od nepodstatného.
2. Princíp konzistentnosti, platnosti a konzistentnosti prvkov systému.
3. Princíp štruktúrovania dáta - dáta by mali byť štruktúrované a hierarchicky usporiadané.
V štrukturálnom prístupe existujú v zásade dve skupiny nástrojov, ktoré popisujú funkčnú štruktúru systému a vzťahy medzi dátami. Každá skupina nástrojov zodpovedá určitým typom modelov (diagramov), z ktorých najbežnejšie sú:
· DFD (Data Flow Diagrams) - diagramy dátových tokov;
SADT (Structured Analysis and Design Technique - metodológia štrukturálnej analýzy a návrhu) - modely a zodpovedajúce funkčné diagramy: zápisy IDEF0 (funkčné modelovanie systémov), IDEF1x (koncepčné modelovanie databáz), IDEF3x (budovanie systémov na hodnotenie kvality objektu grafický popis procesov toku, interakcie procesov a objektov, ktoré sa týmito procesmi menia);
· ERD (Entity - Relationship Diagrams) - "entity-relationship" diagramy.
Takmer vo všetkých metódach štrukturálneho prístupu (štrukturálna analýza) sa vo fáze tvorby softvérových požiadaviek používajú dve skupiny modelovacích nástrojov:
1. Diagramy znázorňujúce funkcie, ktoré musí systém vykonávať, a vzťahy medzi týmito funkciami – DFD alebo SADT (IDEF0).
2. Diagramy modelujúce dáta a ich vzťahy (ERD).
Konkrétna podoba uvedených diagramov a interpretácia ich konštrukcií závisí od štádia životného cyklu softvéru.
Vo fáze tvorby softvérových požiadaviek sa modely SADT a DFD používajú na zostavenie modelu „AS-IS“ a modelu „TO-BE“, čím odrážajú existujúcu a navrhovanú štruktúru podnikových procesov organizácie a interakciu medzi nimi. (pomocou modelov SADT, ktoré sa zvyčajne obmedzujú iba na túto fázu, pretože pôvodne neboli určené na návrh softvéru). Pomocou ERD sa vykonáva popis údajov používaných v organizácii na koncepčnej úrovni bez ohľadu na spôsob implementácie databázy (DBMS).
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 vykonanie určité obdobiečas. 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ší komponentúspech. 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. Pre efektívnu komunikáciu počas stretnutí musia členovia tímu dodržiavať nasledovné kľúčové pravidlá správanie:
- 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:
- Najvyššou prioritou je uspokojenie prianí zákazníka dodaním užitočného softvéru v krátkom čase s následným priebežná aktualizácia. Agilné postupy zahŕňajú rýchle počiatočné vydanie 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 začať komerčná prevádzka systému, ak ho považuje za dostatočne funkčný. Zákazník môže tiež jednoducho čítať aktuálna verzia softvér, poskytnite svoju spätnú väzbu komentárom.
- Neignorujte meniace sa požiadavky, dokonca ani neskoro vo vývoji. Agilné procesy umožňujú prispôsobiť sa zmenám konkurenčná výhoda 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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ú.
- 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.
- 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.
- 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.
- 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; |
| Vývoj softvéru MSFfogAgile | 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 [ |