Typy vývoje softwaru. Přehled procesu vývoje softwaru

správa softwaru

Softwarový proces je mnoho různých činností, metod, technik a kroků používaných k vývoji a vývoji softwaru a souvisejících produktů (plány návrhu, dokumentace, kód, testy, uživatelská dokumentace).

Dnes však neexistuje žádný univerzální proces vývoje softwaru – soubor technik, pravidel a předpisů, které jsou vhodné pro software jakéhokoli druhu, pro jakoukoli společnost, pro týmy jakékoli národnosti. Každý aktuální vývojový proces prováděný určitým týmem v rámci konkrétního projektu má velké množství rysů a individualit. Před zahájením projektu je však vhodné naplánovat pracovní proces, definovat role a odpovědnosti v týmu, produkty práce (střední a konečné), pořadí účasti členů týmu na jejich vývoji a podobně.

Proces tvorby softwaru není jednotný. Ta či ona metoda vývoje softwaru zpravidla určuje určitou dynamiku nasazení určitých typů činností, to znamená, že určuje model procesu.

Model je dobrou abstrakcí různých metod vývoje softwaru a umožňuje je prezentovat stručně, výstižně a informativně. Samotná myšlenka procesního modelu je však jednou z prvních v softwarovém inženýrství, kdy se věřilo, že úspěšný model je nejdůležitější věcí, která přispěla k úspěchu vývoje. Později se ukázalo, že existuje mnoho dalších aspektů (např. principy řízení a rozvoje, struktura týmu), které je třeba definovat ve vzájemném souladu. A začaly se vyvíjet integrované metodiky rozvoje. Existuje však několik klasických modelů procesu vývoje softwaru.

První model, který se stal široce známým a skutečně strukturoval proces vývoje, je kaskáda nebo vodopád. Vznikl po konferenci NATO o vědě a technice v roce 1968, kde se o podobných otázkách uvažovalo, a rozděluje proces tvorby softwarového produktu do po sobě jdoucích fází (nutno podotknout, že jej již používali různí vývojáři, ale ani počet, ani obsah etap sjednocen).

Obrázek 1 - Upravený vodopádový model vývoje softwaru

Upravený kaskádový model počítal s možností návratu k předchozím etapám.

Krátce po svém zrodu byl kaskádový model modifikován Winst Roycem s přihlédnutím k vzájemné provázanosti etap a nutnosti návratu k předchozím etapám, což může být způsobeno např. neúplnými požadavky nebo chybami při tvorbě úkol. V této „reverzibilní“ podobě kaskádový model existoval dlouhou dobu a byl základem mnoha projektů (obrázek 1).

Praktické použití tohoto modelu však odhalilo mnoho jeho nedostatků, z nichž hlavním bylo, že je vhodnější pro tradiční typy inženýrských činností než pro vývoj softwaru. Zejména se jako jeden z největších problémů ukázala jeho „dispozice“ k případným nesrovnalostem mezi výsledným produktem a požadavky, které na něj byly kladeny. Hlavním důvodem je to, že plně vytvořený produkt se objevuje až v pozdějších fázích vývoje, ale protože práce v různých fázích obvykle prováděli různí specialisté a projekt byl převeden z jedné skupiny do druhé, pak podle principu rozbitého telefonu se ukázalo, že výstup nebyl úplně takový, jak se původně očekávalo.

Aby se odstranily nedostatky vodopádového modelu, byl navržen model vývoje softwaru ve tvaru V nebo závěs (obrázek 2).

Obrázek 2 - Model vývoje softwaru ve tvaru V

Model ve tvaru V umožňuje mnohem lepší kontrolu nad výsledkem, aby bylo zajištěno, že splní očekávání, protože je zaměřen na testování.

Model ve tvaru V umožnil výrazně zlepšit kvalitu softwaru díky jeho zaměření na testování a také do značné míry vyřešil problém souladu vytvořeného produktu s předloženými požadavky díky ověřovacím a certifikačním postupům v raných fázích vývoje. vývoj (tečkované čáry na obrázku označují závislost úkolů fáze plánování/výroby a testování/přejímky).

Obecně je však model ve tvaru V jen modifikací kaskádového modelu a má mnoho svých nevýhod. Obojí je zejména špatně přizpůsobeno případným změnám požadavků zákazníků. Pokud proces vývoje trvá dlouho (někdy až několik let), může být výsledný produkt pro zákazníka vlastně zbytečný, protože se jeho potřeby výrazně změnily.

Software lze na rozdíl např. od mikroobvodu zprovozňovat po částech, což znamená, že jej lze vyvíjet a dodávat zákazníkovi i postupně. Právě na tom je založen inkrementální model, který zahrnuje fragmentaci produktu na relativně nezávislé komponenty, které jsou vyvíjeny a uváděny do provozu samostatně.

Tento model je výhodný jak pro zákazníka, tak pro tvůrce systému, protože umožňuje postupovat vpřed při respektování zájmů obou stran.

Má to však své nevýhody. Rozdělení do funkčních bloků obecně zpomaluje proces, protože je nutné zajistit jejich interakci. U mnoha řešení není tato metoda použitelná, protože z nich nelze izolovat jednotlivé komponenty, které by bylo možné dodat a fungovat nezávisle. Výrazně se zvyšuje i zátěž řídícího personálu z důvodu zkomplikování úkolů koordinace prací na jednotlivých komponentách systému a zvyšují se náklady na provádění změn již nainstalovaných hotových komponent a práce se zákazníkem.

Spirální model navržený Barrym Boehmem v roce 1988 byl významným průlomem v pochopení podstaty vývoje softwaru, i když kombinuje vodopádový přístup a iterativní proces navrhování založený na prototypování (obrázek 3).

Rýže. 3.

Boehmův spirálový model se zaměřuje na design, vývoj softwaru probíhá až na posledním otočení spirály podle obvyklého vodopádového modelu, tomu však předchází několik designových iterací založených na prototypování – přičemž každá iterace zahrnuje fázi identifikace a analýzy rizik a nejtěžších problémů.

Vzhledem k tomu, že spirálový model pokrývá především design, nebyl ve své původní podobě široce používán jako metoda pro řízení celého životního cyklu vývoje softwaru. Jeho hlavní myšlenka, že proces práce na projektu se může skládat z cyklů, které procházejí stejnými fázemi, však posloužila jako výchozí bod pro další výzkum a stala se základem nejmodernějších modelů procesu vývoje softwaru.

Iterativní model, který poprvé navrhl Philippe Crutchen v roce 1995, kombinuje hlavní výhody spirály, inkrementálního, vodopádového, prototypování a objektově orientovaného vývoje (obrázek 4). Získal si velkou oblibu a v té či oné podobě se používá v mnoha moderních projektech.

Obrázek 4 - Iterativní model vývoje softwaru

Podle iterativního modelu existují čtyři hlavní fáze životního cyklu vývoje softwaru (iniciace, průzkum, konstrukce a implementace). V každé fázi prochází projekt mnoha iteracemi, které vedou k vytvoření funkčních verzí: v počátečních fázích se vytvářejí prototypy, vyjasňují se požadavky a řeší se nejsložitější problémy; poslední vedou k vytvoření produktu, jeho vylepšení a rozšíření funkčnosti.

Iterační model kromě hlavních fází rozlišuje ještě dvě skupiny procesů: pracovní (správa požadavků, analýza a návrh, implementace, testování, nasazení) a pomocné (řízení konfigurace a změn, projekt a proces). Počet a podstata procesů se liší v závislosti na potřebách vývojáře, mohou mít i své cykly, které ani nemusí nutně odpovídat hlavním fázím. Výsledkem pracovních postupů však vždy je vytvoření verzí produktu.

Iterativní model, stejně jako spirálový model, umožňuje úspěšně se vyrovnat s riziky. Pokud se při práci na další verzi zjistí, že mzdové náklady na implementaci požadované funkcionality jsou příliš vysoké, lze překročení rozpočtu a zmeškaným termínům předejít korelací priorit vývoje a mzdových nákladů na začátku každé iterace. Tento model se tedy dobře hodí pro většinu typů softwarových projektů, ale jeho výhody jsou patrné zejména při práci na produktech určených pro vstup na volný trh, vzhledem k počátečnímu zaměření na vydávání sekvenčních verzí.

Za nejslavnější a nejuznávanější standard kvality je třeba považovat Capability Maturity Model (CMM) – model pro hodnocení úrovně vyspělosti vývojových procesů spolu s jeho deriváty. Byl vytvořen SEI (Software Engineering Institute), který je financován ministerstvem obrany USA a je strukturální jednotkou Carnegie Mellon University. První oficiální verze normy byla zveřejněna v roce 1993, ačkoli práce na ní začaly mnohem dříve - její hlavní ustanovení byla zveřejněna již v roce 1986. Úspěch CMM byl určen několika faktory. Tento standard byl jedním z prvních, který zpočátku zohledňoval specifika tvorby softwaru. Ukázalo se, že je to docela jednoduché a transparentní jak pro pochopení, tak pro použití a reguluje „co“ a ne „jak“ dělat, a proto bylo vhodné pro různé modely životního cyklu, metodiky vývoje a nekladlo žádná omezení na standardy dokumentace. , nástroje, prostředí a jazyky používané v projektech. A možná hlavním faktorem, který předurčil oblibu CMM, byla spolupráce SEI s ministerstvem obrany USA, což de facto znamenalo použití standardu při realizaci projektů zadaných tímto resortem.

Model CMM (tabulka 1) poskytuje pět úrovní zralosti, z nichž každá odpovídá určitým klíčovým procesním oblastem (Key Process Areas, KPA).

Tabulka 1 - Model HMM

Rozdělení do úrovní a definování KPA pro každou umožňuje konzistentní implementaci CMM s využitím standardu jako vodítka, které může zajistit neustálé zlepšování procesu vývoje.

Standard CMM se ukázal jako velmi úspěšný a následně na jeho základě vznikla celá řada standardů a dostal nový název - SW-CMM (Capability Maturity Model for Software), přesněji odrážející jeho postavení v poměrně velkém rodina standardů.

Praktická aplikace standardů řady CMM však ukázala, že neposkytují bezpodmínečný úspěch ve vývoji softwaru. Tyto standardy nebyly vzájemně dobře koordinovány - současná implementace různých modifikací CMM mohla být poměrně složitým úkolem a vedla ke zmatení specialistů organizací, které se s tím setkaly.

Významným problémem CMM je také potřeba „srovnat“ všechny procesy. Pokud organizace usiluje o certifikaci na konkrétní úrovni, pak musí zajistit, aby všechny její procesy byly na příslušné úrovni. I když specifika, metodika nebo vývojové prvky neumožňují implementaci určitých procesů, certifikace to vyžaduje.

Další problém vyplývá z pozice, kterou standardy CMM zaujaly v moderním softwarovém průmyslu. Protože se očekává, že organizace dosahující vysoké úrovně CMM bude poskytovat vyšší výkon softwarových produktů než organizace certifikované na nižších úrovních, standard se začal používat jako výběrové kritérium pro výběrová řízení na vývoj softwaru nebo projekty outsourcingu.

Tato situace byla umožněna díky nedostatkům v procesu certifikace. Certifikaci nepodléhá celá organizace jako celek, ale pouze konkrétní projekt. Nic nebrání organizaci vytvořit „vzorový“ projekt, který splňuje všechny požadavky vysokých úrovní standardu CMM, získat odpovídající úroveň certifikace a deklarovat, že všechny produkty splňují tuto úroveň standardu.

Nový standard SEI – Capability Maturity Model Integrated (CMMI) – integrovaný model pro hodnocení úrovně vyspělosti vývojových procesů je navržen tak, aby vyřešil většinu problémů CMM. Standard CMMI byl původně vytvořen tak, aby spojil stávající možnosti CMM a odstranil případné rozpory při jeho praktické aplikaci v různých oblastech činnosti high-tech společností.

Aby se eliminovala potřeba „ladit“ procesy organizace a byla více přizpůsobena jejím obchodním potřebám a ne naopak, má standard CMMI dvě formy prezentace – klasickou, víceúrovňovou, odpovídající CMM, a novou , kontinuální. Průběžná forma prezentace nezohledňuje úrovně zralosti, ale spíše úrovně způsobilosti, které se posuzují pro jednotlivé oblasti procesu (PA).

Tabulka 2 ukazuje zarovnání standardních úrovní vyspělosti CMM a také úrovní vyspělosti CMMI Layered View a úrovní schopností CMMI Continuous View.

Tabulka 2 – Soulad s úrovněmi vyspělosti standardů CMM a CMMI

SEI odstupuje od CMM a místo toho aktivně propaguje CMMI a slibuje zpřísnění kontroly nad certifikačním procesem, snížení nákladů a zatraktivnění pro menší organizace; zajištění kompatibility s normami ISO.

V moderních podmínkách není certifikát určité úrovně CMM/CMMI tak důležitým faktorem jako před několika lety a je akceptován bez dalších otázek s výjimkou projektů prováděných na základě vládních nařízení.

Norma ISO/IEC 15504 je určena k hodnocení procesu vývoje informačních systémů, zejména softwaru. Byl od počátku navržen tak, aby do značné míry vyhovoval průmyslovým standardům pro posuzování procesu tvorby softwaru. Právě tento požadavek určil podobnost normy se základními principy CMM/CMMI.

Model vyspělosti vývoje softwaru (CMM), vyvinutý Institutem softwarového inženýrství na Carnegie Mellon University, navrhuje pět úrovní vyspělosti (tabulka 3). Pomáhá organizacím zvýšit vyspělost jejich procesů vývoje softwaru a organizace mohou být hodnoceny a akreditovány podle těchto úrovní.

Tabulka 3 - Úrovně vyspělosti vývoje softwaru

Současné modely a metody používané ve skutečných projektech vývoje softwaru jsou tedy značně rozmanité. Každý z nich má své výhody, které se projevují v odpovídajících podmínkách. Dokonce i zastaralý model vodopádu je pro některé projekty naprosto dostačující. Každý proces má také řadu vlastností, které omezují rozsah jeho efektivního využití. Tato situace je zcela typická pro vývoj softwaru, kde již bylo nashromážděno mnoho technologií a technik, ale neexistuje žádná univerzální metoda, která by byla optimální pro jakýkoli úkol.

Vývoj softwarových produktů zná mnoho hodnotných metodologií – jinými slovy zavedené osvědčené postupy. Výběr závisí na specifikách projektu, systému rozpočtování, subjektivních preferencích a dokonce i temperamentu manažera. Článek popisuje metodiky, se kterými se u Edisona pravidelně setkáváme.

1. „Model vodopádu“ (kaskádový model nebo „vodopád“)

Jedna z nejstarších, zahrnuje postupný průchod fází, z nichž každá musí být kompletně dokončena před začátkem další. Model vodopádu usnadňuje správu projektu. Díky své tuhosti postupuje vývoj rychle, cena a termín jsou předem dané. Ale tohle je dvousečná zbraň. Vodopádový model poskytne vynikající výsledky pouze v projektech s jasně a předem definovanými požadavky a způsoby jejich realizace. Neexistuje způsob, jak udělat krok zpět; testování začíná až po dokončení nebo téměř dokončení vývoje. Produkty vyvinuté podle tohoto modelu bez odůvodněné volby mohou mít nedostatky (seznam požadavků nelze kdykoli upravit), které se projeví až na konci kvůli přísnému sledu akcí. Náklady na provedení změn jsou vysoké, protože k jejich zahájení je třeba počkat, dokud nebude dokončen celý projekt. Fixní náklady však často převažují nad nevýhodami tohoto přístupu. Náprava nedostatků realizovaných během procesu tvorby je možná a podle našich zkušeností vyžaduje jedno až tři dodatečné dohody ke smlouvě s malou technickou specifikací.

Pomocí vodopádového modelu jsme vytvořili mnoho projektů od nuly, včetně vývoje pouze technických specifikací. Projekty, o kterých se píše na Habré: střední - RTG mikrotomografie, malé - automatická aktualizace služby Windows na AWS.

Kdy použít metodologii vodopádu?

• Pouze tehdy, když jsou požadavky známy, pochopeny a zaznamenány. Neexistují žádné protichůdné požadavky.
• Problémy nejsou ani s dostupností programátorů s požadovanou kvalifikací.
• V relativně malých projektech.

2. "V-Model"

Strukturu „krok za krokem“ zdědil z kaskádového modelu. Model ve tvaru V je použitelný pro systémy, pro které je nepřerušovaný provoz obzvláště důležitý. Například aplikační programy na klinikách pro monitorování pacientů, integrovaný software pro ovládací mechanismy pro nouzové airbagy ve vozidlech a tak dále. Zvláštností modelu je, že je zaměřen na důkladnou kontrolu a testování produktu, který je již v počáteční fázi návrhu. Fáze testování se provádí současně s odpovídající fází vývoje, například testy jednotek se zapisují během kódování.

Příkladem naší práce založené na V-metodologii je mobilní aplikace pro evropského mobilního operátora, která šetří náklady na roaming při cestování. Projekt probíhá podle jasné specifikace, ale zahrnuje významnou fázi testování: pohodlnost rozhraní, funkčnost, zátěž a integrace, která by měla potvrdit, že několik komponent od různých výrobců spolupracuje stabilně, krádež peněz a půjček je nemožné.

Kdy použít V-model?

• Pokud je vyžadováno důkladné testování produktu, pak model V odůvodní svou vlastní myšlenku: validaci a ověření.
• Pro malé a střední projekty, kde jsou požadavky jasně definované a pevně dané.
• V podmínkách dostupnosti inženýrů s potřebnou kvalifikací, zejména testerů.

3. "Přírůstkový model" (přírůstkový model)

Inkrementální modely se používají tam, kde jsou jednotlivé požadavky na změnu jasné a lze je snadno formalizovat a implementovat. V našich projektech jsme jej použili k vytvoření čtečky DefView a následně sítě elektronických knihoven Vivaldi.

Jako příklad popíšeme podstatu jednoho přírůstku. Síť elektronických knihoven Vivaldi nahradila DefView. DefView je připojen k jednomu dokumentovému serveru a nyní se může připojit k mnoha. Úložný server je instalován na místě instituce, která chce vysílat svůj obsah konkrétnímu publiku, které přímo přistupuje k dokumentům a převádí je do požadovaného formátu. Objevil se kořenový prvek architektury - centrální server Vivaldi, který funguje jako jednotný vyhledávač pro všechny úložné servery instalované v různých institucích.

Kdy použít inkrementální model?

• Když jsou jasně definovány a pochopeny základní požadavky na systém. Některé detaily se přitom mohou časem dolaďovat.
• Je nutné včasné uvedení produktu na trh.
• Existuje několik rizikových funkcí nebo cílů.

4. „RAD Model“ (model rychlého vývoje aplikací nebo rychlý vývoj aplikací)

Model rychlého vývoje aplikací zahrnuje následující fáze:

• Obchodní modelování: definování seznamu informačních toků mezi různými odděleními.
• Datové modelování: informace shromážděné v předchozí fázi se používají k určení objektů a dalších entit nezbytných pro oběh informací.
• Procesní modelování: Informační toky propojují objekty za účelem dosažení rozvojových cílů.
• Sestavení aplikace: Používá automatizované montážní nástroje k převodu CAD modelů na kód.
• Testování: testují se nové komponenty a rozhraní.

Lze použít pouze s vysoce kvalifikovanými a vysoce specializovanými architekty. Rozpočet projektu je velký na to, aby tyto specialisty zaplatil spolu s náklady na hotové automatizované montážní nástroje. Model RAD lze vybrat s jistou znalostí cílového podnikání a potřeby urgentní výroby systému během 2-3 měsíců.

5. „Agilní model“ (flexibilní metodika vývoje)

V „agilní“ metodologii vývoje může zákazník po každé iteraci pozorovat výsledek a pochopit, zda ho uspokojuje nebo ne. To je jedna z výhod flexibilního modelu. Mezi jeho nevýhody patří skutečnost, že kvůli nedostatku konkrétních formulací výsledků je obtížné odhadnout mzdové náklady a náklady potřebné na vývoj. Extreme Programming (XP) je jednou z nejznámějších aplikací agilního modelu v praxi.

Tento typ je založen na krátkých denních schůzkách – „Scrum“ a pravidelně se opakujících schůzkách (jednou týdně, jednou za dva týdny nebo jednou za měsíc), nazývaných „Sprint“. Na každodenních schůzkách členové týmu diskutují:

• zprávu o práci vykonané od posledního Scrumu;
• seznam úkolů, které musí zaměstnanec splnit před příští schůzkou;
• potíže, se kterými se během práce setkáte.

Kdy Agile použít?

• Když se potřeby uživatelů v dynamickém podnikání neustále mění.
• Agilní změny jsou implementovány s nižšími náklady díky častým přírůstkům.
• Na rozdíl od vodopádového modelu vyžaduje agilní model jen trochu plánování, aby se projekt rozjel.

6. „Iterativní model“ (iterativní nebo iterativní model)

Diagram ukazuje iterativní „vývoj“ Mony Lisy. Jak vidíte, v první iteraci je pouze náčrt Mony Lisy, ve druhé se objeví barvy a třetí iterace přidá detaily, sytost a dokončí proces. V inkrementálním modelu je funkčnost výrobku budována kus po kuse, výrobek je složen z dílů. Na rozdíl od iterativního modelu představuje každý kus kompletní prvek.

Příkladem iterativního vývoje je rozpoznávání hlasu. První výzkum a příprava vědeckého aparátu začala již dávno, nejprve v myšlenkách, pak na papíře. S každou další iterací se kvalita rozpoznávání zlepšovala. Dokonalého rozpoznání však dosud nebylo dosaženo, takže problém ještě nebyl zcela vyřešen.

Kdy je optimální použít iterativní model?

• Požadavky na konečný systém jsou předem jasně definované a srozumitelné.
• Projekt je velký nebo velmi rozsáhlý.
• Musí být definován hlavní cíl, ale detaily implementace se mohou časem vyvíjet.

7. "Spirálový model" (spirální model)

„Spirální model“ je podobný inkrementálnímu modelu, ale s důrazem na analýzu rizik. Funguje dobře pro řešení kritických obchodních problémů, kdy je selhání neslučitelné s aktivitami společnosti, v kontextu uvádění nových produktových řad, kdy je nezbytný vědecký výzkum a praktické testování.

Spirálový model zahrnuje 4 fáze pro každé kolo:

1. plánování;
2. analýza rizik;
3. design;
4. vyhodnocení výsledku a pokud je kvalita uspokojivá, přechod do nové etapy.

Pojďme si to shrnout

Snímek ukazuje rozdíly mezi dvěma nejběžnějšími metodikami.

V moderní praxi jsou modely vývoje softwaru vícerozměrné. Neexistuje jeden správný model pro všechny projekty, startovací podmínky a platební modely. Ani námi všemi tolik milovaný Agile nelze pro nepřipravenost některých zákazníků či nemožnost flexibilního financování uplatnit všude. Metodiky se částečně překrývají v prostředcích a částečně jsou si navzájem podobné. Některé další koncepty sloužily pouze k propagaci vlastních překladačů a do praxe nepřinesly nic nového.

O vývojových technologiích:
Ještě jednou o sedmi hlavních vývojových metodikách.
10 hlavních chyb v systémech škálování.
8 zásad plánování rozvoje, které zjednodušují život.
5 hlavních rizik při vývoji softwaru na zakázku.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , Prosím.

Existuje několik modelů vývoje softwaru (životního cyklu). Nejprve si ale definujme, co to je – životní cyklus. Tento koncept zahrnuje všechny fáze, kterými softwarový produkt prochází. První z nich bude popis problému a poslední bude implementace. S fázemi životního cyklu softwaru se můžete seznámit na příkladu existujících modelů vývoje softwaru (konceptů).

Model životního cyklu softwaru je struktura obsahující akční procesy a úkoly, které jsou prováděny během vývoje, používání a údržby softwarového produktu. V současné době existují tři hlavní skupiny, do kterých lze zhruba rozdělit všechny známé modely vývoje softwaru:

Inženýrský přístup

S přihlédnutím ke specifikům úkolu

Moderní technologie rychlého rozvoje

Nyní se podíváme na stávající modely (podtřídy) a zhodnotíme jejich výhody a nevýhody.

Podívejme se blíže na podtřídy modelu.

Kódování chyb a model eliminace

Nejjednodušší z modelů je velmi často využíván studenty ve vzdělávacím procesu Algoritmus tohoto modelu se skládá z následujících kroků:

Krok 1: prohlášení o problému

Krok 2: Vytvořte program

Krok 3: testování

Krok 4: Analýza výsledku testu a možný přechod ke kroku 1

Tento model patří do první skupiny a pro profesionální vývoj softwaru není vůbec relevantní. Programátoři používali tyto algoritmy před 50-60 lety. Přílišná jednoduchost mu v tomto případě neumožňuje konkurovat ostatním stávajícím modelům. Nedostatky

"Vodopád" neboli vodopádový model životního cyklu softwaru

Do první skupiny patří i tento model životního cyklu softwaru Algoritmus této metody, který znázorňuji ve schématu, má oproti algoritmu předchozího modelu řadu výhod, ale má i řadu podstatných nevýhod.

Algoritmus vodopádového modelu

výhody:

Sekvenční realizace etap projektu v přesně stanoveném pořadí

Umožňuje zhodnotit kvalitu produktu v každé fázi

nedostatky:

Žádná zpětná vazba mezi fázemi

Neodpovídá reálným podmínkám vývoje softwarového produktu

Patří do první skupiny modelů.

"Whirlpool" nebo kaskádový model s meziregulací

Tento model poskytuje střední ovládání prostřednictvím zpětné vazby. Tato výhoda však přináší i nevýhody. Náklady na realizaci projektu se tímto přístupem zvyšují téměř 10krát. Tento model, jak jste již pochopili, je menší modifikací předchozího a patří do první skupiny.

Při skutečné práci podle modelu, který umožňuje pohyb pouze jedním směrem, obvykle nastávají problémy, když jsou odhaleny nedostatky a chyby učiněné v raných fázích. Ještě obtížnější je ale vypořádat se se změnami v prostředí, ve kterém je software vyvíjen (mohou to být změny požadavků, změny dodavatelů, změny v politice vyvíjející se nebo provozující organizace, změny v průmyslových standardech, vznik konkurenčních produkty atd.).

Iterativní model

Iterativní nebo inkrementální modely (je známo několik takových modelů) zahrnují rozdělení vytvořeného systému na sadu částí, které jsou vyvíjeny pomocí několika po sobě jdoucích průchodů celé práce nebo její části.

Kaskádový model se schopností vrátit se k předchozímu kroku v případě potřeby revidovat jeho výsledky se stává iterativním.

Iterační proces předpokládá, že různé typy činností nejsou pevně svázány s určitými fázemi vývoje, ale jsou prováděny podle potřeby, někdy se opakují, dokud není dosaženo požadovaného výsledku.

Spolu s flexibilitou a schopností rychle reagovat na změny přinášejí iterativní modely další složitost řízení projektů a sledování pokroku. Při použití iterativního přístupu je mnohem obtížnější adekvátně posoudit aktuální stav projektu a naplánovat dlouhodobý vývoj, stejně jako předvídat načasování a zdroje potřebné k zajištění určité kvality výsledku.

V model - vývoj řízený testem

Tento model má algoritmus, který se blíží moderním metodám, ale přesto má řadu nevýhod.Je to jedna z hlavních praktik extrémního programování a vyžaduje pravidelné testování produktu během vývoje.

Model založený na vývoji prototypu

Tento model je založen na vývoji prototypů a prototypování produktů a patří do druhé skupiny.

Prototypování se používá na začátku životního cyklu softwaru:

Vyjasnění nejasných požadavků (prototyp uživatelského rozhraní)

Vyberte si jedno z řady koncepčních řešení (implementace scénářů)

Analyzujte proveditelnost projektu

Klasifikace prototypů:

Horizontální prototypy – modelují výhradně uživatelské rozhraní bez ovlivnění logiky zpracování a databáze.

Vertikální prototypy - ověřování architektonických řešení.

Jednorázové prototypy - pro rychlý vývoj.

Evoluční prototypy jsou první aproximací evolučního systému.

Model životního cyklu spirálového softwaru

Tento model dokonale kombinuje postupné prototypování a design. A z konceptů zdola nahoru a shora dolů bylo do tohoto modelu převzato to nejlepší.

Výhody modelu:

Výsledek je dosažen v co nejkratším čase.

Konkurenceschopnost je poměrně vysoká.

Když se požadavky změní, nemusíte vše začínat od začátku.

Ale tento model má jednu významnou nevýhodu: nemožnost regulace fází provádění.

Zvláštní zmínku si zaslouží extrémní programování (XP), SCRUM a inkrementální model (RUP). To vše jsou modely, které patří do třetí skupiny, ale jejich analýze se budeme věnovat v samostatném článku.

A na závěr

Navzdory velkému pokroku v oblasti vývoje softwaru se v současné době vyvíjí a bude vyvíjet mnoho projektů podle následujícího schématu:

Jak vzniká software? Co vede specialisty v jejich činnosti? V této oblasti jsou důležité metodiky vývoje softwaru. Na některé z nich se podíváme v tomto článku a podrobně se zaměříme na úkoly, fáze, důležité principy a rozdíly mezi těmito metodikami.

co to je?

Začněme článek definicí. Metodologie vývoje softwaru je soubor principů, systém myšlenek a nástrojů, které nakonec určují styl vývoje softwaru. Jinými slovy, metodikou je zde implementace konkrétního standardu.

Důležité je poznamenat, že zde uvedené normy radí a nepředepisují, jak by věci měly být. Tvůrci softwaru proto zůstává svobodná volba a přizpůsobení teorie.

Specifické produkty jsou implementovány prostřednictvím metodiky vývoje softwaru. Určí, jak bude specialista vykonávat svou práci. Dnes existuje mnoho takových metodologií - ty hlavní zvážíme v průběhu materiálu. Co ovlivňuje výběr právě jednoho z nich? Důraz je kladen na velikost týmu, komplexnost a specifičnost konkrétního projektu, vyspělost a stabilitu procesů v zaměstnávající společnosti a osobní preference tvůrce softwaru.

Metodologie jsou tedy jádrem teorie řízení pro vývoj jakéhokoli softwaru. Dříve se ve vztahu k nim používala klasifikace, která rozdělovala všechny metodiky na dva typy: iterační a vodopádové (na základě použitých modelů životního cyklu). Dnes se používá moderní obecná klasifikace, která se také dělí na dvě skupiny: prediktivní a adaptivní. Pojďme se s nimi blíže seznámit.

Předpokládané metodiky

Jaké jsou tyto metodiky vývoje softwaru? Jsou to odrůdy, které jsou zaměřeny na detailní plánování do budoucna. Úkoly a zdroje jsou známy po celou dobu trvání projektu. Pracovní tým tak bude mít problém reagovat na neočekávané změny.

Plán je vypracován podle skladby potřebné práce a požadavků na ni. Změna požadavků tedy přímo vede ke změně celého plánu a designu projektu. Metodologie prognóz obvykle vytváří specializovaný výbor pro řízení změn, aby bylo zajištěno, že projekt bude řešit pouze kritické požadavky.

Adaptivní metodiky

Co je zvláštního na těchto metodologiích vývoje počítačového softwaru? Již nyní jsou zaměřeny na překonání očekávané nedokonalosti, neúplnosti požadavků a na jejich neustálou změnu. V souladu s tím, jak se mění požadavky, se bude měnit i vývojový tým projektu.

Přesný plán adaptivní metodiky se připravuje teprve pro blízkou budoucnost. Plány související s událostmi vzdálenějšími realitě existují ve formě deklarací o cílech práce, jejích výsledcích a očekávaných nákladech.

Agilní metodiky

Agilní metodiky vývoje softwaru - anglicky. Agilní vývoj softwaru. Odtud druhý název: agilní metody.

Flexibilní metodiky vývoje softwaru jsou souborem přístupů k vývoji softwaru, které jsou zaměřeny na využití iterativního vývoje, dynamické formování požadavků projektu, zajištění implementace jako výsledek nepřetržité interakce v rámci pracovních samoorganizujících se skupin složených ze specialistů v různých oborech.

Především se jedná o efektivní pracovní praxi pro malé týmy zabývající se stejným typem kreativní práce. V kombinaci s kombinovaným (demokratickým a liberálním) způsobem řízení.

Agilní metodiky vývoje počítačového softwaru jsou zaměřeny na minimalizaci rizik redukcí celkového projektu na soubor krátkých cyklů (tzv. iterací), z nichž každý trvá maximálně 2-3 týdny.

Iterace je zde miniaturní softwarový projekt, který zahrnuje všechny úkoly pro poskytnutí minifunkčního přírůstku. Například: plánování, analýza požadavků, návrh, programování, testování vývoje, dokumentace. K vydání finálního produktu samozřejmě nestačí jediná iterace. To znamená něco jiného. Na konci každé iterace je připraven flexibilní softwarový produkt. Na konci období musí tým také přehodnotit priority rozvoje.

Během každé iterace (fáze vývoje softwaru) je kladen důraz na přímou osobní komunikaci mezi specialisty. Většina týmů se nachází ve stejné kanceláři. Vyžaduje se přítomnost „zákazníka“ – autorizovaného zástupce prezentujícího požadavky na vývoj. Tuto roli má na starosti projektový manažer, klient-zákazník a obchodní analytik. Kancelář může také zahrnovat testery, technické autory, návrháře rozhraní atd.

Hlavní metrikou je zde konečný produkt. Výhodou přímé komunikace mezi specialisty je relativně malé množství doprovodné písemné dokumentace.

Agilní manifest

Podívejme se na základní standardy vývoje softwaru. První je soubor vývojových procesů nazývaných Agile. Je definována Agilním manifestem. Je důležité říci, že Agile neobsahuje konkrétní praktické rady, ale obsahuje hodnoty a principy, kterými by se vývojářské týmy měly řídit v jejich činnosti.

Agile Manifesto byl vyvinut a přijat 1. až 13. února 2001 v lyžařském středisku v pohoří Utah. Obsahuje 4 hlavní myšlenky a 12 principů týmové práce bez jediné praktické rady.

Pojďme si představit hlavní myšlenky této moderní metodiky vývoje softwaru:

• Spolupráce a lidé jsou důležitější než nástroje a procesy.
• Funkční produkt je lepší než komplexní dokumentace.
• Spolupráce s klientem je důležitější než dohodnutí individuálních smluvních podmínek.
• Ochota týmu ke změnám je důležitější než držet se původních plánů.

Také v rámci Agilního manifestu byly nastíněny následující principy developerské činnosti:

• Uspokojování potřeb zákazníků prostřednictvím nepřetržitého včasného dodávání cenného softwaru.
• Vítání změn požadavků i po dokončení projektu. Ostatně právě to může zvýšit její konkurenceschopnost.
• Časté dodávky funkčního softwaru - každý týden nebo měsíc.
• Projekt zaměstnává motivované jedince, kterým jsou poskytovány pohodlné pracovní podmínky, důvěra a podpora.
• Každodenní úzká interakce mezi zákazníkem a vývojovým týmem.
• Nejlepším měřítkem pokroku je fungující software.
• Uživatelé, sponzoři a vývojáři musí zvolené tempo udržovat po neomezenou dobu.
• Neustálá pozornost zlepšování designu výrobků, technických požadavků.
• Jednoduchost je umění nedělat zbytečnou práci.
• Neustálé přizpůsobování týmu měnícím se provozním podmínkám. Vývojáři musí neustále hledat způsoby, jak zefektivnit svou práci, a řídit se jimi i v budoucnu.

Model vodopádu

Od manifestu vývoje softwaru přecházíme k novému typu. Model vodopádu - „vodopád“ nebo kaskádový model. Jedna z nejstarších metodik. Zahrnuje sekvenční průchod fází vývoje softwaru, z nichž každá musí být dokončena před zahájením další.

Díky této rigiditě je celkem snadné řídit projekt pomocí této metodiky. Náklady a doba vývoje jsou předem dané, a proto práce postupují rychle. Je však také důležité pamatovat na tento aspekt: ​​kaskádový model dává vynikající výsledek pouze v projektech s předem jasně definovanými požadavky a metodami pro jejich realizaci. Zde specialisté nemají šanci „vrátit se“, protože testování začíná až po úplném dokončení fáze.

Pokud není volba takového modelu pro produkt dostatečně odůvodněna, pak může být výstupem software s významnými nedostatky. O jejich přítomnosti se totiž díky přísnému sledu činností dozví až po dokončení práce. Oprava chyb se zde ukazuje být poměrně drahá. Než bude možné začít s opravami, musíte počkat na dokončení vývoje.

Odborníci doporučují použít metodu „vodopádu“ v následujících případech:

• Požadavky na projekt jsou známé, srozumitelné a pevné. Nejsou mezi nimi žádné rozpory.
• Není problém přilákat programátory s potřebnou kvalifikací.
• Projekt je relativně malý.

V-Model

Fáze vývoje softwaru jsou zde také sekvenční. V-Model tuto vlastnost „zdědil“ od „vodopádu“. Zvláště dobré pro systémy, kde je vyžadován nepřetržitý provoz. Dobrým příkladem je vytvoření aplikačního softwaru pro kliniky sloužícího k průběžnému sledování pacientů. Nebo software, který řídí mechanismy airbagů ve vozidlech. Nebo aplikace pro mobilního operátora, která má uživateli šetřit náklady na roaming při cestách do zahraničí.

Projekt je realizován podle jasných bodů tvůrčího úkolu. Významnou roli však hraje také včasné testování: funkčnost, integrace, zátěž, použitelnost rozhraní.

Kdy je nutné použít tuto metodiku pro vývoj:

• V případech, kdy je vyžadováno důkladné testování produktu.
• Pro malé až středně velké projekty s jasně definovanými požadavky.
• V podmínkách, kde jsou k dispozici inženýři a testeři konkrétní kvalifikace.

Přírůstkový model

V této technice vývoje softwaru je soubor systémových požadavků rozdělen do sestav. Jinými slovy, toto je popis sestavení softwaru po jednotlivých fázích. Několik vývojových cyklů projektu tvoří komplex nazývaný „multi-vodopád“.

Cyklus je zase rozdělen do samostatných, snadno vytvořených modulů. Každý z nich prochází fázemi definice požadavků, návrhu, implementace, testování, kódování.

Zvláštností je, že v první velké fázi je uvolněn základní vývojový model. A pak se k tomu přidávají přírůstky – nové funkce. Tento proces pokračuje, dokud není vytvořen kompletní komplex. Inkrementální modely jsou dobré tam, kde jsou jednotlivé požadavky na změnu jasné a lze je jednoduše formalizovat a implementovat.

Popišme případy, kdy by použití přírůstkového modelu bylo opodstatněné:

• Jasně definované a srozumitelné požadavky na konečný produkt.
• Některé detaily je možné časem doladit.
• Existuje několik rizikových cílů.
• Je nezbytné včasné uvedení softwaru na trh.

Model RAD

Okamžitě poznamenejme, že model RAD je jednou z odrůd inkrementálního modelu. Komponenty nebo funkce programu jsou vyvíjeny paralelně několika týmy profesionálů. Výsledkem je několik miniprojektů. Čas na vytvoření každého z nich je přísně omezen. Všechny moduly jsou spojeny do společného funkčního prototypu. Na systému je dobré, že pomáhá zákazníkovi rychle prezentovat fungující produkt ke kontrole, který lze následně upravit.

Proces vývoje softwaru zde zahrnuje několik fází:

1. Obchodní modelování. Toto je definice informačních toků mezi řadou oddělení.
2. Informační modelování. Údaje shromážděné v první fázi slouží k identifikaci subjektů nezbytných pro oběh informací.
3. Během této fáze informační toky propojují konkrétní objekty za účelem dosažení vývojového cíle.
4. Sestavení aplikace. K převodu návrhových modelů na kód používá nástroje pro automatické sestavení.
5. nové komponenty a rozhraní.

Takový software by měl být používán pouze tehdy, má-li tým vysoce kvalifikované a „úzké“ specialisty. Rozpočet projektu je rozhodně velký: musíte zaplatit za práci profesionálů, náklady na hotové automatizované montážní nástroje.

Model je vybírán s jistou znalostí cílového podnikání v případech, kdy je nutné prezentovat hotový produkt v krátké době - ​​do 2-3 měsíců.

Iterativní model

Dalším příkladem organizace vývoje softwaru je iterativní (nebo iterativní) model. Zvláštností projektu je, že pro zahájení realizace není nutná úplná specifikace požadavků. Tvorba začíná stavbou základny, která by se měla stát základem pro stanovení dalších požadavků.

Verze v tomto případě nemusí být vůbec ideální. Hlavním požadavkem je, aby to fungovalo. Vývojář chápe a vidí konečný cíl práce. Musí se snažit, aby každý krok jeho činnosti byl efektivní a každá vytvořená verze funkční.

V některých ohledech zde tvorba softwaru připomíná tvorbu malby: nejprve se udělá náčrt, pak se naplní barvami, detaily, sytostí, přechody odstínů, dodělávky – a proces je dokončen.

Připomíná to trochu inkrementální model? Podívejme se na rozdíl. Podle inkrementální metodiky se produkt skládá z dílů a softwarová funkcionalita se skládá takříkajíc kus po kuse. Ale zároveň je každá část již integrálním prvkem. A „kousky“ v iterativním modelu nemají nezávislost.

Další pozoruhodný příklad vývoje softwaru pomocí této metodiky: zařízení pro rozpoznávání hlasu. Vše začalo přípravou vědecké základny. Poté byla shromážděna potřebná dokumentace. S každým dalším vývojem se kvalita zařízení zvyšovala. Ale ještě to nedosáhlo ideální úrovně. Projekt proto ještě není dokončen.

Použití iterativního modelu je oprávněné v těchto případech:

• Požadavky na finální verzi vývoje jsou jasné a jasně definované.
• Projekt je velmi rozsáhlý.
• Hlavní úkol je předem daný. Jeho detaily lze ale během pracovního procesu vylepšovat a měnit.

Spirálový model

Spirálový model je v mnohém podobný předchozímu. Důraz je však kladen na jiný úkol vývoje softwaru – hodnocení rizik. Především je tato metodika použitelná při řešení kritických obchodních úkolů, kdy neúspěch projektu může vážně poškodit činnost společnosti.

Spirální model je široce používán při vydávání nových řad softwaru, kdy je nutné provést vědecký výzkum projektu a praktické testování. Každý z „otoček spirály“ probíhá ve čtyřech fázích:

• Plánování.
• Analýza rizik.
• Konstrukce.
• Vyhodnocení výsledků. Pokud je pozitivní, vývojář přejde do nového „kola“ projektu.

Spirálový model by se neměl používat pro projekty s malým rozpočtem. Naopak se hodí spíše do velkých a drahých. Vynikajícím příkladem aplikace metodiky je vývoj systému správy bankovních dokumentů. Zde se velká pozornost nevěnuje ani tak samotnému programování, ale analýze každého již provedeného „zatáčky“.

LD

Takzvaný štíhlý vývoj softwaru. Je to jedna z větví flexibilní metodiky, o které jsme hovořili výše. Hlavní výhoda LD: udržení vysokého morálního a funkčního stavu specialistů. Konkrétně se jedná o následující:

• Povzbuzení každého zaměstnance k obzvláště úspěšným činnostem.
• Aktuální úkoly projektu se mění pouze v krajních případech nebo na žádost zákazníka.
• Přísná realizace plánu. Přepracovanost je zde považována za známku plýtvání časem i prostředky.
• Zavedení obecného konceptu činnosti do práce: „Mysli široce, dělejte chyby rychle, pracujte málo, učte se rychle.“

XP

Velmi zajímavým příkladem je metodika tzv. extrémního programování. Co se tu skrývá? Jedná se o řízení vývoje softwaru tváří v tvář neustále se měnícím požadavkům na produkty. Směr metodiky má následující charakteristické rysy:

• "Hra o plánování" Na začátku práce je uveden pouze hrubý plán. S každým kolem vývoje se jeho jasnost zvyšuje.
• Vysoká frekvence úniků. To znamená, že nová verze bude mít jen nepatrné rozdíly od předchozí, ale její vydání bude vynaloženo minimum času.
• Kontakt s klientem. Pro ty, kteří se touto metodikou řídí, je důležité rychle uspokojit všechny požadavky zákazníka – promptně reagovat na všechny jeho připomínky a přání.
• Refaktorování. Kvalita kódu je vylepšena bez snížení jeho funkčnosti.
• Standardní provedení kódu. Na tváři buď dodržování obecných pravidel, nebo absence neshod v procesu vývoje.
• Kolektivní odpovědnost. Ano, každý člen týmu je zaneprázdněn určitou oblastí práce. Za celkový výsledek už ale může celý tým.

FDD

A poslední metodika v našem článku. Poskytuje škálovatelnost a opakovatelnost. Zároveň je ale podporován kreativní přístup a využívání inovací v práci. Hlavní principy metodiky jsou následující:

• Rozvoj každého velkého projektu je systematická činnost.
• Všechny procesy by měly být jednoduché a dobře propracované.
• Logika a hodnota každého procesu by měla být jasná a srozumitelná každému členovi týmu.
• Preferovány jsou krátké cykly vývoje softwaru. To vám umožní snížit počet chyb a zároveň zvýšit funkčnost.

Hodnota metodiky je v tom, že jasně reguluje dobu trvání procesů. Zároveň by nemělo být v každém cyklu věnováno více než 25 % času organizačním záležitostem. Zbývajících 75 % je čistě na vývoj, montáž a testování funkčnosti.

Tímto končíme náš úvod k hlavnímu vývoji softwaru. Jak jste viděli, vlastnosti každého z nich vám umožňují zvolit vhodnou metodiku pro úspěšnou realizaci nejrůznějších typů projektů.

Metodika vývoje software - organizace práce včetně ideových zásad, plán, kontrola nad procesy, přístup k zaměstnancům. Zdůrazněme 12 typů:

• Vodopád je tradiční přístup.
• RUP (Rational Unified Process) - racionální.
• Agile je obecná flexibilní metodika vývoje.
• Crystal Clear je přístup k vyrovnání vývojářů v týmu.
• Spirála – spirální metoda.
• DSDM (Dynamic Systems Development Model) je dynamický model.
• FDD (Feature Driven Development) je metodika, která zvažuje budoucí změny.
• JAD (Joint Application Development) je přístup zaměřený na uživatele.
• RAD (Rapid Application Development) je model rychlého vývoje.
• Scrum je koncept práce v podmínkách nedodržení termínů a ideologické krize.
• XP (Extreme Programming) - extrémní vývoj v dynamickém prostředí.
• LD (Lean Development) je metoda, která zahrnuje pečlivé zacházení se všemi účastníky procesu.

Zkusme přijít na to, co se za těmito anglickými názvy skrývá.

Vodopád

Model Waterfall patří ke klasickému chápání vývoje softwaru. Celý proces je rigidní a lineární, má jasné cíle pro každou fázi, po dokončení předchozí fáze začíná nová fáze, není cesty zpět. Výhodou vodopádové metodiky je decentralizace a přísná kontrola nad načasováním a kvalitou provedení.

V praxi Waterfall často nesplní očekávání, protože ignoruje dynamické změny. Po otestování je tedy velmi obtížné vrátit proces zpět a přidat funkce, které nebyly brány v úvahu ve fázi vývoje. Waterfall je také neefektivní, protože zahrnuje dočasné odstávky zaměstnanců v rámci jednoho projektu. Testování se provádí až na konci vývoje, ačkoliv problémy zjištěné v této fázi jsou nákladné na opravu.

RUP

RUP je iterativní přístup, který řeší problémy, které má Waterfall. Co je na RUP dobré:

• Zohledňuje měnící se požadavky. Bez ohledu na to, jak dobrý je projektový manažer, nelze na začátku zohlednit vše.
• K integraci funkcí dochází postupně, to znamená, že každý „detail“ prochází cyklem vývoje, testování a implementace do projektu. V důsledku toho se snižují rizika a výrobní náklady.
• Předčasné vydání produktu. Software přichází s omezenou funkčností, aby obsadil mezeru na trhu a odolal konkurenci, poté zaroste „masem“.
• Znovu použít. Při zvyšování funkčnosti je snazší identifikovat standardní řešení, která zkrátí dobu vývoje.
• Neustálé učení. Díky častým iteracím nemají vývojáři dlouhé pauzy mezi revizemi kódu, takže profesionální růst probíhá hladce a bezbolestně.
• Neustálé zlepšování produktu. Iterace umožňují zhodnotit projekt nejen z pohledu shody s plánem a technickými specifikacemi, ale také najít způsoby, jak zvýšit efektivitu a kvalitu produktu.

Agilní

Agile je metoda flexibilního vývoje softwaru, která zahrnuje velké množství iterací. Dokument Agile Manifesto popisuje 4 myšlenky a 12 principů agilního přístupu, lze jej stručně popsat pouze ve dvou bodech:

• Neformální vztahy jsou důležitější než ty zdokumentované. To znamená, že nejdůležitější jsou ústní dohody mezi zaměstnanci, mezi zákazníkem a dodavatelem, jak se odráží v plánech, smlouvách a technických specifikacích. Jinými slovy, zákazník má vždy pravdu.
• Funkční produkt je hlavním hodnocením pokroku. Nejsou důležité nástroje, řešení, výkon nebo elegance, ale skutečnost, že jsou realizovány všechny plánované schopnosti.

Přes své nedostatky se Agile stala základním konceptem pro vývoj softwaru a odráží se i v dalších metodikách, o kterých bude řeč níže.

Křišťálově čistý

Metodika vytvořená pro malé týmy 6-10 zaměstnanců. Podporuje také principy agilního vývoje, ale je trochu konkrétnější. Hlavní myšlenkou, která je obsažena v názvu, je, že každý tým je soubor lidí s různou úrovní znalostí, různými dovednostmi a zkušenostmi.

Proto neexistuje univerzální přístup k vývoji softwaru, ten musí být stanoven v procesu komunikace v rámci skupiny. Jsou zde také přiřazeny role, nástroje a standardy. Poté je skupina brána jako jednotka a stejné problémy se řeší na vyšší úrovni, dokud se hierarchie nedostane k zákazníkovi.

Spirála

Spirální model životního cyklu je komplexní organizace životního cyklu softwaru, která se zaměřuje na včasnou identifikaci a zmírnění rizik projektu. Rozvoj začíná v malém měřítku, řeší se lokální problémy, posuzují se rizika a způsoby jejich snižování. Další krok pokrývá složitější úkoly – další otočení spirály.

Výhoda přístupu není ve zvýšení rychlosti vývoje, ale ve snížení míry rizik. Úspěch spirálové metody závisí na svědomitém, pečlivém a kompetentním vedení a velikost projektu není zásadní.

DSDM

Dynamický model vývoje systémů byl vyvinut ve Spojeném království v polovině 90. let a je evolučním vývojem rychlého vývoje aplikací (RAD). Hlavní myšlenka je standardní: při plánování na samém začátku není možné pochopit všechny složitosti vývoje, takže celý proces je výzkumná práce.

DSDM má také rozdělení do týmů, z nichž každý má osobu oprávněnou přijímat strategická rozhodnutí. Do procesu se mohou zapojit všechny zainteresované strany: uživatelé, vývojáři, zákazníci, manažeři. Testování probíhá v průběhu celého životního cyklu.

FDD

FDD je proces, který zajišťuje škálovatelnost a opakovatelnost a zároveň podporuje kreativitu a inovace. Zde jsou základní principy:

• Vývoj každého velkého projektu musí být systematický.
• Procesy by měly být jednoduché a dobře propracované.
• Hodnota a logika procesu by měla být jasná každému členu týmu.
• Přednost se dává krátkým, iterativním vývojovým cyklům. To snižuje počet chyb a umožňuje rychle zvýšit funkčnost.

FDD reguluje čas, který by měl být vynaložen na každý z procesů. Organizační aktivity v cyklu by neměly zabírat více než 23-25%, přičemž 75-77% času by mělo být věnováno přímému vývoji, montáži a testování funkcí.

JAD

JAD je metodika zaměřená na maximalizaci zapojení koncových uživatelů do vývoje. Děje se tak prostřednictvím setkání a společných seminářů. JAD byl vynalezen v 70. letech 20. století zaměstnanci IBM a je zaměřen na podnikání obecně. Postupem času se však tento koncept začal úspěšně aplikovat i na vývoj softwaru.

Na rozdíl od přístupu Waterfall má JAD za následek zkrácení doby vývoje, větší spokojenost zákazníků a úsporu nákladů na průzkum trhu. Na druhou stranu to vyžaduje velký vzorek klientů a nutnost vývojářů pracovat nikoli s přísnými požadavky technických specifikací, ale s neustále se měnícími názory.

RAD

RAD je metodologie, která upřednostňuje rychlost a snadnost vývoje. Jednou z hlavních podmínek je použití rychle se vyvíjejícího jazyka. To je název abstraktního programovacího jazyka, se kterým je programátor schopen řešit problémy rychleji než se zástupci třetí generace (C/C++, Pascal nebo Fortran). Zde je několik dalších bodů konceptu:

• Použití fokusních skupin ke shromažďování požadavků.
• Prototypování a uživatelské testování návrhů.
• Opětovné použití softwarových komponent.
• Použití plánu, který nezahrnuje redesign nebo design pro další verzi produktu.
• Vedení neformálních schůzek na žádost jedné ze stran.

RAD zahrnuje kromě jazyka pro rychlý vývoj použití celé řady nástrojů: systémy sběru požadavků, vývojová prostředí, frameworky, programy pro skupinovou komunikaci, testovací software.

Skrumáž

Scrum je flexibilní metoda projektového řízení, jejímž cílem je zvýšit produktivitu v týmech dříve paralyzovaných složitějšími metodickými procesy. Koncept je založen na „sprintech“. Sprint je krátká iterace, časově přísně omezená (obvykle 2–4 týdny). V tomto okamžiku je doba schůzek minimalizována, ale jejich frekvence se zvyšuje (nazývají se „skrumáže“).

Díky tomu je kontrola provádění flexibilnější a vývojáři mohou rychleji reagovat na vzniklé problémy. Tradiční plánování ustupuje do pozadí a jeho místo nastupuje sprint journal.

XP

Extrémní programování je schopnost vyvíjet se tváří v tvář neustále se měnícím požadavkům. Zde jsou některé známky:

• Plánovací hra. Na začátku projektu je pouze hrubý plán, po každé iteraci se jeho přehlednost zvyšuje.
• Vysoká frekvence úniků. Nová verze produktu má oproti předchozí drobné změny, ale doba vydání je minimální.
• Kontakt s klientem. Pro splnění požadavků koncového publika je nezbytná rychlá reakce na připomínky a návrhy.
• Refaktorování. Zlepšení kvality kódu bez omezení funkčnosti.
• Standard provádění kódu. Buď platí obecná pravidla, nebo neshody v designu nejsou předmětem diskuse a kritiky.
• Kolektivní odpovědnost. Navzdory skutečnosti, že každý člen týmu vykonává svou vlastní oblast práce, je celý tým zodpovědný za kód jako celek.

LD

Štíhlý vývoj softwaru je další odvětví flexibilní metodologie, která zahrnuje udržování vysokého morálního a funkčního stavu vývojářů. To je vyjádřeno takto:

• Odměňování zaměstnanců za úspěšnou práci.
• Změna aktuálních úkolů pouze podle potřeby nebo na žádost zákazníka.
• Přísná realizace plánu: cokoli přebytečného je považováno za ztrátu času a zdrojů.
• Představujeme obecný koncept „Mysli ve velkém, dělejte málo, dělejte chyby rychle, rychle se učte“.

V krátkém přehledu je obtížné odhalit všechny výhody a nevýhody metodik a ukázat efektivní oblasti použití. Dnes budeme hovořit samostatně o nejdůležitějších pojmech. Které přesně? Svá přání zanechte v komentářích.