Iterační a přírůstkový vývoj - Iterative and incremental development

Iterativní a přírůstkový vývoj je jakákoli kombinace iteračního designu nebo iterační metody a modelu přírůstkového sestavení pro vývoj .

Použití termínu začalo ve vývoji softwaru , přičemž pro velké vývojové úsilí byla široce navrhována dlouhodobá kombinace obou termínů iterativní a přírůstková . Například DOD-STD-2167 z roku 1985 zmiňuje (v části 4.1.2): „Během vývoje softwaru může probíhat více než jedna iterace cyklu vývoje softwaru současně.“ a „Tento proces lze popsat jako přístup„ evoluční akvizice “nebo„ přírůstkové budování “.“ V softwaru je vztah mezi iteracemi a přírůstky určen celkovým procesem vývoje softwaru .

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy
Iterační vývojový model

Přehled

Zjednodušená verze typického iteračního cyklu v agilním řízení projektů

Základní myšlenkou této metody je vyvinout systém prostřednictvím opakovaných cyklů (iterativně) a v menších částech najednou (přírůstkově), což vývojářům softwaru umožní využít toho, co se naučili během vývoje dřívějších částí nebo verzí systému. Učení vychází z vývoje a používání systému, kde možné klíčové kroky procesu začínají jednoduchou implementací podmnožiny softwarových požadavků a iterativně vylepšují vyvíjející se verze, dokud není implementován celý systém. Při každé iteraci se provádějí konstrukční úpravy a přidávají se nové funkční možnosti.

Samotný postup se skládá z inicializačního kroku, iteračního kroku a seznamu řízení projektu. Krok inicializace vytvoří základní verzi systému. Cílem této počáteční implementace je vytvořit produkt, na který může uživatel reagovat. Měl by nabídnout ukázku klíčových aspektů problému a poskytnout řešení, které je dostatečně jednoduché na to, aby bylo snadno pochopitelné a snadno implementovatelné. Pro vedení procesu iterace je vytvořen seznam řízení projektu, který obsahuje záznam všech úkolů, které je třeba provést. Obsahuje položky, jako jsou nové funkce, které mají být implementovány, a oblasti předělání stávajícího řešení. Kontrolní seznam je v důsledku fáze analýzy neustále revidován.

Iterace zahrnuje přepracování a implementace iterace má být jednoduchá, přímočará a modulární a podporuje přepracování v této fázi nebo jako úkol přidaný do seznamu řízení projektu. Úroveň detailů designu není diktována iteračním přístupem. V lehkém iterativním projektu může kód představovat hlavní zdroj dokumentace systému; v kritickém iterativním projektu však lze použít formální dokument Software Design . Analýza iterace je založena na zpětné vazbě od uživatelů a dostupných nástrojích pro analýzu programu. Zahrnuje analýzu struktury, modularity, použitelnosti , spolehlivosti, účinnosti a dosažení cílů. Kontrolní seznam projektu je upraven s ohledem na výsledky analýzy.

Iterační vývoj.

Fáze

Přírůstkový vývoj rozděluje funkčnost systému na přírůstky (porce). V každém přírůstku je část funkcí poskytována prostřednictvím práce mezi obory , od požadavků až po nasazení . Tyto Unified Process přírůstky skupiny / iterací do fáze: založení, zpracování, konstrukce, a přechod.

  • Počátek identifikuje rozsah projektu, požadavky (funkční i nefunkční) a rizika na vysoké úrovni, ale dostatečně podrobně, aby bylo možné práci odhadnout.
  • Elaboration přináší funkční architekturu, která zmírňuje nejvyšší rizika a splňuje nefunkční požadavky.
  • Konstrukce postupně vyplňuje architekturu kódem připraveným pro produkci vytvořeným z analýzy, návrhu, implementace a testování funkčních požadavků.
  • Transition dodává systém do produkčního operačního prostředí.

Každá z fází může být rozdělena do 1 nebo více iterací, které jsou obvykle časově ohraničené, nikoli hranaté. Architekti a analytici pracují o jednu iteraci před vývojáři a testery, aby udrželi své nevyřízené produkty a pracovní produkty plné.

Použití/Historie

Mnoho příkladů raného použití je uvedeno v článku Craiga Larmana a Victora Basiliho „Iterační a přírůstkový vývoj: Stručná historie“, přičemž jedním z prvních je projekt Merkur NASA ze 60. let .

Někteří z těchto techniků z Merkuru později vytvořili novou divizi v IBM , kde „další raný a pozoruhodný příklad velkého úspěchu IID [byl] samotným srdcem softwaru raketoplánu NASA - primárního softwarového systému pro avioniku, který [postavili] od roku 1977 do roku 1980. Tým aplikoval IID v sérii 17 iterací během 31 měsíců, v průměru kolem osmi týdnů na iteraci. Jejich motivací pro zamezení životního cyklu vodopádu bylo, že se požadavky programu raketoplánu během procesu vývoje softwaru změnily. “

Některé organizace, jako například americké ministerstvo obrany, upřednostňují iterační metodiky, počínaje MIL-STD-498 „jasně podporující evoluční získávání a IID“.

Pokyny DoD 5000.2 vydané v roce 2000 uváděly jasnou preferenci pro IID:

K plné kapacitě existují dva přístupy, evoluční a jednokrokový [vodopád]. Upřednostňuje se evoluční přístup. … [V tomto] přístupu je konečná schopnost poskytovaná uživateli rozdělena do dvou nebo více bloků s rostoucími přírůstky schopností ... vývoj softwaru se bude řídit iterativním spirálovým vývojovým procesem, ve kterém jsou neustále se rozšiřující verze softwaru založeny na učení dřívější vývoj. Lze to provést i ve fázích.

Nedávné revize DoDI 5000.02 již neodkazují na „spirálový vývoj“, ale zastávají obecný přístup jako výchozí bod pro programy náročné na vývoj/zadávání zakázek. Kromě toho Agentura Spojených států pro mezinárodní rozvoj (USAID) také využívá iterativní a inkrementální vývojový přístup k jeho programového cyklu navrhnout, monitorovat, vyhodnocovat, učit se a přizpůsobovat mezinárodní developerské projekty s přístupem k řízení projektu, který se zaměřuje na začlenění spolupráce, učení a adaptační strategie pro iteraci a přizpůsobení programování.

Kontrast s vývojem Waterfall

Programovací paradigmata

Hlavní příčinou selhání projektů vývoje softwaru je výběr modelu, proto by měl být prováděn s velkou péčí.

Například paradigma vývoje Waterfall dokončuje v rámci celého projektu pracovní produkty každé disciplíny v jednom kroku, než v úspěšném kroku přejde k další disciplíně. Obchodní hodnota je dodávána najednou a pouze na samém konci projektu, zatímco zpětné sledování je možné v iterativním přístupu. Při srovnání těchto dvou přístupů se začínají objevovat některé vzorce:

  • Zapojení uživatele : V modelu vodopádu je uživatel zapojen do dvou fází modelu, tj. Požadavků a testů přijetí a případně vytvoření materiálu pro vzdělávání uživatelů. Zatímco v přírůstkovém modelu je klient zapojen v každé fázi.
  • Variabilita : Software je uživateli dodán až poté, co je dokončena fáze sestavení životního cyklu, za účelem přijetí uživatelem. Na druhou stranu je každý přírůstek doručen uživateli a po schválení uživatele se vývojář může přesunout směrem k dalšímu modulu.
  • Lidské zdroje : V přírůstkovém modelu je ve srovnání s vodopádovým modelem potenciálně zapotřebí méně zaměstnanců.
  • Časové omezení : Provozní produkt je dodáván po měsících, zatímco v přírůstkovém modelu je produkt předán uživateli během několika týdnů.
  • Velikost projektu : Vodopádový model není vhodný pro malé projekty, zatímco přírůstkový model je vhodný pro malé i velké projekty.

Implementační směrnice

Pokyny, které řídí implementaci a analýzu softwaru, zahrnují:

  • Jakékoli potíže s návrhem, kódováním a testováním změny by měly signalizovat potřebu přepracování nebo překódování.
  • Úpravy by se měly snadno vejít do izolovaných a snadno dostupných modulů. Pokud tak neučiní, je možná zapotřebí nějaký redesign.
  • Úpravy tabulek by měly být obzvláště snadné. Pokud není jakákoli úprava tabulky provedena rychle a snadno, je indikován přepracování.
  • Jak postupují iterace, úpravy by měly být snadněji proveditelné. Pokud tomu tak není, existuje základní problém, jako je konstrukční chyba nebo šíření záplat .
  • Opravy by normálně měly existovat pouze pro jednu nebo dvě iterace. Opravy mohou být nutné k zamezení předělávání během fáze implementace.
  • Stávající implementace by měla být často analyzována, aby se určilo, jak dobře odpovídá cílům projektu.
  • Kdykoli jsou k dispozici prostředky pro analýzu programu, měly by být použity k pomoci při analýze dílčích implementací.
  • Reakce uživatele by měla být vyžádána a analyzována z hlediska náznaků nedostatků v současné implementaci.

Použití v hardwaru a vestavěných systémech

Zatímco termín iterativní a přírůstkový vývoj začal v softwarovém průmyslu, mnoho úsilí o vývoj hardwaru a vestavěného softwaru využívá iterační a přírůstkové techniky.

Příklady toho lze vidět v řadě průmyslových odvětví. Jedním z odvětví, které bylo touto změnou myšlení v poslední době podstatně ovlivněno, je průmysl vypouštění kosmických lodí , kde podstatné nové konkurenční síly v práci přináší rychlejší a rozsáhlejší technologické inovace, které vznikají díky formování soukromých společností usilujících o vesmírné vypuštění. Tyto společnosti, jako jsou SpaceX a Rocket Lab , nyní v uplynulém desetiletí poskytují služby komerčního orbitálního startu, což před deseti lety dělalo pouze šest zemí. Nové inovace v přístupech k vývoji technologií, cenách a nabídkách služeb-včetně schopnosti, která existuje teprve od roku 2016, létat do vesmíru na dříve prolétlé (opakovaně použitelné) posilovací fázi- dále snižovat cenu za získání přístupu do vesmíru.

Společnost SpaceX se výslovně vyjádřila ke svému úsilí vnést do kosmického průmyslu iterativní postupy navrhování a používá tuto techniku ​​na kosmických lodích, nosných raketách, elektronice a avionice a operativním letovém hardwaru.

Vzhledem k tomu, že se průmysl začal měnit, začínající konkurenti začínají měnit své postupy dlouhodobého rozvoje také u vládních agentur . Například velký poskytovatel spouštěcích služeb v USA United Launch Alliance (ULA) zahájil v roce 2015 desetiletý projekt restrukturalizace startu-redukce dvou lau nch vozidel na jedno- pomocí iterativního a inkrementálního přístupu k částečně znovupoužitelnému použití a mnohem levnější spouštěcí systém v příštím desetiletí.

Viz také

Poznámky

Reference