Unified Process (PU) , nebo " Unified Process (UP) " v angličtině nebo " Unified Software Development Process (USDP), " je řada objektově orientovaného vývoje software metod . Je charakterizován iterativním a přírůstkovým přístupem, který je poháněn případy použití a je zaměřen na architekturu a modely UML . Definuje proces integrující všechny designové a výrobní činnosti v rámci vývojových cyklů složených z fáze vytváření, fáze vývoje, fáze výstavby a fáze přechodu, včetně každé několika iterací.
V roce 1987 vytvořil Ivar Jacobson Objectory AB, aby uvedl na trh objektově orientovanou vývojovou metodu nazvanou Objectory Process. Tato metoda je výsledkem přístupu zaměřeného na komponenty, který vyvinul od roku 1967 ve společnosti Ericson . Objectory je založen na případech použití , konceptu, jehož autorem je Jacobson. Metoda poté sleduje systematický přístup zaměřený na posloupnost modelů OOSE k dosažení realizace softwaru.
V roce 1992 zveřejnil Grady Booch , zaměstnanec společnosti Rational Software, Boochovu metodu objektově orientovaného vývoje. Skládá se z jazyka pro grafické modelování , iteračního procesu vývoje a sady osvědčených postupů .
V roce 1995 Rational Software získal Objectory AB a spojil tyto dvě vývojové metody pod názvem Rational Objectory Process. Společnost také najala Jamese Rumbaugha , tvůrce modelovacího jazyka OMT .
V roce 1997 se „unified modeling language“, UML , stal standardem v objektově orientované analýze a designu po sjednocení tří hlavních notací té doby, OOSE, Booch a OMT, nejprve v rámci Rational Software, poté větší konsorcium. Nová notace je poté integrována do produktu Rational Objectory Process (verze 4.1).
V roce 1998, po akvizici několika dalších společností specializujících se na nástroje softwarového inženýrství, Rational Software vylepšil svoji metodu a přejmenoval ji na „ Rational Unified Process (RUP)“ (verze 5.0). Jedná se o patentovanou metodu chráněnou registrovanou ochrannou známkou.
V roce 1999 publikovali Jacobson, Booch a Rumbaugh „Jednotný proces vývoje softwaru“ s cílem širšího šíření myšlenek, které stojí za RUP, veřejnosti. Poukazují na to, že se jedná jak o sjednocení vývojových přístupů, tak o sjednocení použitých modelů, a že tento proces zahrnuje velké množství příspěvků metodických specialistů ze společnosti Rational Software a stovek dalších společností.
Sjednocený proces je metoda vývoje softwaru charakterizovaná:
Sjednocený proces splňuje definici obchodního procesu . Zaměřuje se tedy na zajištění vývojového cyklu se systematickými a opakovatelnými sekvencemi aktivit založených na dobře definovaných artefaktech a zároveň usnadňuje integraci nových lidí do týmů. Metoda dále zvažuje, že produkt se skládá nejen z kódu, ale také ze všech prvků přispívajících k udržitelnosti a následnému vývoji softwaru.
Sjednocený proces je cyklický: jeho cílem je prostřednictvím řady projektů poskytnout nejprve životaschopnou verzi produktu a poté postupné publikovatelné verze („vydání“ v angličtině).
Každý projekt má životní cyklus ve čtyřech fázích, z nichž každá je rozdělena do několika iterací:
Sjednocený proces prosazuje přístup založený na riziku, který prostřednictvím různých iterací usiluje o vyřešení největších nejistot jako priority.
Sjednocený proces nabízí následující pracovní sekvence, které lze konfigurovat podle potřeb projektu:
Termín „disciplína“ se také používá k označení obecných sekvencí.
Na rozdíl od modelu vodopádu, který definuje odlišné fáze pro každou z těchto sekvencí aktivit, sjednocený proces integruje tyto aktivity prostřednictvím různých iterací a fází projektu. Sjednocený proces je dále navržen pro zpracování komplexních systémů založených na komponentách. Našli jsme tedy myšlenky cyklu V , jako je architektonická vize založená na komponentách, integraci systému a různých úrovních validace, ale bez omezení jejich uspořádání v postupných fázích.
Sjednocený proces také definuje role aktérů zapojených do těchto aktivit (např. Architekt, inženýr komponent, návrhář uživatelského rozhraní atd.). Autoři však zdůrazňují, že se jedná o role a nikoli o lidi; stejný člen týmu proto může kombinovat několik rolí. Unifikovaný proces nakonec definuje řadu artefaktů, tj projektové výstupy .
Sjednocený proces vyžaduje iterativní plánování, ve kterém „plán předchází akci“.
Princip spočívá v tom, že celkový plán určuje podle složitosti projektu iterace nezbytné pro každou fázi a umisťuje fáze v čase. Tento celkový plán neobsahuje podrobnosti na iteraci. Iterace jsou plánovány postupně, jak projekt postupuje. Aktuální iterace je naplánována podrobně, jakmile začne, s plánem a cílem obsahu (případ použití, který má být zpracován, změny, které mají být provedeny v dodávkách z předchozích iterací, komponenty, které mají být provedeny atd.). Plán dalších iterací je připraven, když jsou prvky známy. Proto se nejprve odhaduje v širokém obrysu, poté se zpřesňuje podle informací objevených během aktuální iterace.
V konkrétním případě fáze vytváření je obrys projektu obecně příliš nejistý, aby umožnil realistické plánování. Plán první iterace této fáze by proto měl být považován za plán pokusu, který by měl být v případě potřeby upraven. Na konci této fáze je stanovena proveditelnost rozvoje a může být vytvořen celkový plán odpovídající vizi projektu.
Řízení případů použití používá diagramy případů použití ( DCU ) doplněné textovými popisy. Z DCU jsou odvozeny modely analýzy, designu, nasazení, implementace a testování. Z těchto modelů vychází architektura systému. Navrhuje se také systematický přístup k odvození případů použití z tříd analýzy a návrhu podle schématu kontroly entit a hranic . Toto jsou také případy použití, které umožní vývoj testovacích scénářů, protože nový software bude muset umožnit provedení plánovaných případů použití. DCU jsou tedy modely, které zaručují soudržnost procesu vývoje tím, že slouží jako společné vlákno pro všechny činnosti.
Aktivity modelování jsou založeny na UML . Tento modelovací jazyk pokrývá strukturální a dynamické aspekty softwarové architektury a designu. Usnadňuje modelování komponent pomocí objektově orientovaného přístupu . Tvůrci UML jsou také u zrodu jednotného procesu, který měl doplnit UML o ucelený a obecný vývojový proces .
Architektura systému je od počátku koncipována velmi pragmaticky : je přizpůsoben pracovnímu kontextu, potřebám uživatele, možnostem opětovného použití ( opětovného použití ) již existujících knihoven nebo „cihel“. Vývoj architektury je především hrubý a nezávislý na případech použití (zajistíme však, aby to nezabránilo jejich realizaci), poté je identifikována podmnožina základních funkcí a architektura se podle této sady opakuje a podrobně popisuje. Od specifikace k přesnosti případu se architektura vyvíjí, případně zahrnuje nové případy atd., Dokud architektura nedosáhne dostatečně vysoké a stabilní úrovně vývoje, aby mohla vést k vývoji prototypu, který bude představen zákazník tak dokončil iteraci.
Iterace je posloupnost sledů činností. Přírůstek je krokem vpřed ve fázích vývoje. Při každé iteraci najdeme aktivity specifikace potřeb, designu, až po spustitelný prototyp. Nová iterace, například po předvedení prototypu uživatelům, obnoví specifikaci uvedením nebo opravou, následným obnovením vývoje atd.
Přírůstky jsou definovány projektem a každý přírůstek přidá nové funkce. Přírůstky mohou následovat například různé případy použití. Potíž bude spočívat ve skutečnosti v konečném důsledku sloučení dílčích projektů nebo přírůstků dohromady a při respektování jejich vzájemných závislostí a obecné konzistence předpokládaného produktu. Navrhuje se tedy také vývoj ve formě komponent. Bude co nejlépe využívat příspěvky objektových technologií.
PU integruje dva cíle, aby se minimalizovalo riziko nesprávné interpretace ve vztahu k potřebám i riziko nekonečného, nedefinovaného, nedefinovaného nebo nedokončeného vývoje: Zde si uživatel může na prototypech napravit obrat vývoj . Od začátku se získají hmatatelné výsledky, i když jsou pouze prototypové. Některé implementace PU považují prototypy za plnou verzi finálního systému. Podřízené funkce mohou být v takové perspektivě velmi dobře opuštěny, například pro otázky nákladů nebo termínů . A konečně, pokud uživatel potřebuje během vývoje změnu, lze tento vývoj do určité míry integrovat. To není případ postupného vývoje.
PU organizuje životní cyklus seskupením iterací (specifikace, analýza, návrh, implementace a testování) do fází. Tyto fáze jsou buď počáteční (vytvoření), nebo střední (vývoj, konstrukce) nebo konečné (přechod k uživateli nebo uvedení do výroby). Tyto fáze omezují produkci produktu jako časovou posloupnost (sekvence), ale zahrnují všechny strukturální úkoly projektu (postupné zdokonalování, iterace) a navrhují maticovou organizaci celkového objemu poskytované činnosti: je zřejmé, fáze vytváření bude větší část času věnována analýze potřeb než testům; naopak v přechodné fázi stále probíhají testy, zatímco analýza potřeb a její zdokonalení jsou teoreticky dokončeny od fáze výstavby.
Sjednocený proces je konfigurovatelný, a lze jej proto přizpůsobit specifikům projektů a organizací, v nichž je zaměstnán. Existuje tedy mnoho specializací obecné metody. Objevilo se také několik zásadnějších variant, které zažily širší distribuci.
Běžné názvy a zkratky jsou:
Akronym | Označení | První verze | Autoři | Zvláštnosti |
---|---|---|---|---|
MOHL | Sjednocený proces | 1999 | Ivar Jacobson , Grady Booch a James Rumbaugh | obecné zásady metody |
NAHORU | Sjednocený proces | 1999 | (viz PU) | Anglický název PU |
USDP | Jednotný proces vývoje softwaru | 1999 | (viz PU) | jiný anglický název pro PU za názvem knihy, která metodu publikovala |
NEBO | Racionální jednotný proces | 1998 | Rational Software (IBM), tým RUP pod vedením Philippe Kruchten | Proprietární metoda společnosti Rational Software (IBM), na které byla založena PU |
EUP | Jednotný proces Enterprise | 2000 | Scott Ambler a Larry Constantine | integruje poimplementační fáze a aktivity k pokrytí životního cyklu softwaru ve výrobě, dokud není stažen z výroby; jméno je ochranná známka. |
XUP | Jednotný proces eXtreme | hybridní integrace UP s extrémním programováním . | ||
HORNÍ | Agilní jednotný proces | 2005 | Scott Ambler | hybrid kombinující podmnožinu UP s pravidly agilních metod - distribuován jako webový server dokumentující metodu, ale neudržovaný od roku 2006 |
2TUP | dvě stopy Unified Process | Valtech | pravděpodobně zohlední vrtochy a omezení spojené s neustálými a rychlými změnami IS společností | |
EssUP | Základní jednotný proces | 2006 | Ivar Jacobson | hubená alternativa UP integrující agilní předpisy a šířená jeho společností Ivar Jacobson Consulting. EssUP je tvořen souborem takzvaných „základních“ postupů, které lze libovolně volit a kombinovat, což nabízí velkou flexibilitu při jejich používání. |
Rational Unified Process (RUP) je původem sjednoceného procesu a jako takový je nejznámější implementací. Jedná se o produkt a ochrannou známku společnosti Rational Software, kterou mezitím získala společnost IBM. Metoda je dodávána na klíč a je doprovázena nástroji, které týmům pomohou při přizpůsobení a provedení procesu.
Rámec pro vývoj softwaru navržený RUP reaguje na charakteristiky jednotného procesu: jedná se o vývojovou metodu, která se řídí potřebami uživatelů, zaměřenou na softwarovou architekturu, iterativní a inkrementální, implementující UML pro modelování.
RUP rozšiřuje řetězy aktivit také na pokrytí
Agile Unified Process (AUP) je zjednodušená varianta UP, která zahrnuje agilní postupy, jako je testovaný vývoj (TDD). Zabírá tedy postupné fáze a mezníky na konci fáze jednotného procesu, ale posiluje agilní přístup doporučením aktualizace plánu na konci každé fáze, implementace potenciálně publikovatelné verze na konci každé fáze, ukončení každé iterace a aplikace principů agilního manifestu . Proto je použití modelů jako artefaktu dokumentace omezeno na model požadavků a návrhový model. AUP obohacuje modelování požadavků o obchodní modely. Metoda dále doporučuje soustředit modelování na obrysy a vyhnout se detailům, které lze snadno odvodit z kódu. AUP je k dispozici zdarma online jako komprimovaný archiv, ale od roku 2006 nebyl zachován.
Essential Unified Process (EssUP) se snaží odlehčit jednotný proces, který je sice iterativní a inkrementální často vnímán jako příliš těžkopádný a příliš formalizovaný. EssUP pro to přijímá zásadu oddělení obav . Spíše než monolitický proces definuje EssUP sadu nezávislých postupů, které lze libovolně kombinovat a vytvořit proces vhodný pro kontext.
Postupy identifikované programem EssUP jsou seskupeny do 8 rodin předmětů: tým, produkt, životní cyklus, iterace, případy použití 2.0, architektura, komponenty a provedení testu. EssUP je k dispozici online.
Sjednocený proces využívá postupné fáze, jako jsou vodopády . Fáze však nejsou strukturovány uměle podle technických oborů, ale reagují na logiku snižování rizika po etapách, přičemž každá fáze v různé míře integruje všechny disciplíny. Sjednocený proces navíc prosazuje spíše iterativní a adaptivní plánování než rigidní a podrobné plánování.
Sjednocený proces má podobnosti s V-cyklem v tom, že se zaměřuje na architekturu systémů vyrobených z komponent a rozlišuje mezi testováním jednotek, integračním testováním a testováním systému. Fáze PU však nejsou strukturovány podle architektonické úrovně a disciplíny, ale reagují na logiku iterativního zrání. Kromě toho PU v každé fázi integruje ověřovací a ověřovací činnosti.
Sjednocený proces je blízký agilním metodám , protože prosazuje iterativní a přírůstkový přístup zaměřený na potřeby uživatelů. Od agilních metod se však liší proaktivním sběrem většiny požadavků během prvních iterací projektu a definicí upstream architektury před produkcí publikovatelných verzí („ release “ v angličtině).). Zaměřuje také přístup na modely, zatímco agilní metody upřednostňují produkci kódu před produkcí dokumentace. Tento poslední rozdíl je však třeba uvést do perspektivy, protože někteří agilisté také obhajují přístup založený na modelování. Tyto agilní metody sdílejí s UP vizi přírůstkového modelování, kde se různé modely (požadavky, analýza, design) zdokonalují paralelně během každé iterace, nikoli postupně po jednotlivých fázích.
Sjednocený proces velmi využívá modely UML . Artikuluje různé typy diagramů s různými účely modelování (analýza, návrh, test). Obohacuje tak UML, což je obecný modelovací jazyk, se systematickým přístupem, ale specifickým pro konkrétní metodu vývoje.
Sjednocený proces kombinuje výhody několika přístupů, a zejména strukturovaný přístup ve fázích s velkou flexibilitou v iteracích.
Hlavní kritika spočívá v tom, že podrobný popis sekvencí činností a artefaktů dává PU určitou tíhu, a proto vyžaduje vysokou kvalifikaci členů projektového týmu (zejména: zvládnutí iterativních přístupů, důkladná znalost UML , znalost sekvencí činností a jejich vzájemných závislostí).
Sjednocený proces také ponechává velkou volnost uznání za přizpůsobení činností specifikům společnosti. Tato flexibilita v kombinaci se složitostí procesu a velkou svobodou výkladu může vést k velmi rigidním implementacím PU, přestože má v zásadě vlastnosti agilní metody.
Přijetí PU organizací často vychází z touhy disciplinovat vývojové postupy s využitím konkrétních nástrojů a sledováním zavedených a homogenních pravidel chování . Proces vývoje softwaru je sám o sobě předmětem procesu reengineeringu („BPR“) s cílem optimalizovat činnosti IT oddělení. Agilní vývoj se naopak zasazuje o volbu nejjednodušších nástrojů a hladké nebo „nástrojové“ používání modelů jazyka nebo fází metody. Existuje tedy paradox v touze rigidizovat kodifikací postupů, které jsou od přírody určeny pro flexibilitu.
Podle Scotta Amblera nemohou některé základy PU koexistovat s pravidly agility: je třeba upustit od preeminence a hnací role diagramů případů použití . Pokud skutečně umožňují správně dokumentovat chování softwaru, nelze je použít ke kontrole všech aktivit projektu: omezení, uživatelská rozhraní a jejich kinematika, obchodní pravidla, která musí software respektovat, nelze odvodit případy použití. PU také přidává soubor „dalších specifikací“, aby tento nedostatek kompenzoval. Podle Amblera tedy, pokud analýza potřeb může vést projekt, případy použití nemohou a představují pouze marketingovou rétoriku specifickou pro instance jako RUP nebo EUP .
Mnoho lehčích variant jednotného procesu se objevilo, aby zmírnilo počáteční těžkost jeho popisu. Objevilo se také několik agilních variant, které se snaží posílit iterativní charakter, odlehčit dokumentaci nebo usnadnit integraci určitých agilních postupů do procesu.
Nejnovější vývoj, zejména EssUP, si klade za cíl přeměnit jednotný proces na „sadu nástrojů“. Zásadou je identifikovat a definovat komponenty procesu, například jeho rozdělení do fází, jeho iterativní techniky pilotování a určité techniky modelování, aby byly nezávislé a znovu použitelné a umožnily projektovým týmům vybrat a kombinovat ty, které jsou relevantní pro kontext.