Unified Process ( anglicky unified process ) je metodika pro budování procesů vývoje softwaru , která umožňuje vývojovému týmu transformovat požadavky zákazníků na funkční produkt. V závislosti na požadavcích a dostupných zdrojích lze proces vývoje upravit zahrnutím nebo vyloučením určitých projektových činností. Příkladem vývojové metodiky založené na Unified Process je Rational Unified Process ( RUP ), který obsahuje řadu aktivit nepopsaných v obecnějším rámci, ale hodnotných pro konkrétní typ projektu [1] .
Unified Process intenzivně využívá Unified Modeling Language ( UML ). Jádrem UML je model, který umožňuje vývojovému týmu porozumět zjednodušeným způsobem rozmanitosti složitých procesů potřebných k vývoji softwaru. Různé modely používané v Unified Process umožňují vizualizovat systém, popsat jeho strukturu a chování, dokumentovat rozhodnutí učiněná během procesu vývoje [1] .
Počátky rámce leží v práci zaměstnance Ericssonu Ivara Jakobsona , publikované na konci 60. let. Jacobson a jeho kolegové modelovali obrovské telekomunikační systémy pomocí vrstev „bloků“ (co se později stalo známým jako „komponenty“): spodní vrstvy sloužily jako základ pro subsystémy z horních vrstev. Tým vytvořil spodní bloky sledováním dopravních případů , které se mohly stát uživatelům systému . Právě tyto „incidenty“ se staly prototypem případů užití , které se později staly součástí UML [2] . Jacobsonova práce také poskytla impuls pro diagramy používané v UML , včetně diagramů aktivit a sekvencí .
V roce 1987 Jacobson založil svou vlastní společnost Objectory AB a několik let strávil s partnery vývojem projektu a produktu s názvem Objectory . V roce 1995 Jacobson publikoval knihu Object-Oriented Software Engineering , která popisuje vývojový proces řízený požadavky zákazníků, které jsou prostřednictvím případů použití převedeny do konečného produktu. Vydání knihy se časově shodovalo s první online publikací jádra Unified Process .
V roce 1995 převzala Objectory AB společnost Rational Corporation . S pomocí výrazně zvýšeného počtu kolegů začíná Jacobson rozšiřovat proces Objectory o nástroje pro řízení projektů a vývoj. Spolu s Gradi Boochem a Jamesem Rumbaughem , kteří dříve pracovali v Rational , se Jacobson stal členem skupiny „tří kamarádů“ [3] [4] , kteří vedli práci na vytvoření procesu zvaného Rational Objectory Process ( ROP ), stejně jako distribuce Unified Process , která se stala základem pro Unified Modeling Language .
Při práci na ROP a UML pokračovala společnost Rational Corporation ve slučování a získávání společností zabývajících se tvorbou nástrojů pro vývoj softwaru. Tyto nástroje poskytovaly možnost spravovat požadavky ("RequisitePro"), obecné testování ("SQA"), testování výkonu, správu konfigurace a správu změn. V roce 1998 Rational mění název produktu na RUP , jehož koncepčním jádrem zůstává Unified Process .
Jednotný proces je založen na případech použití , které popisují jednoho nebo více aktérů, kteří interagují se systémem a vytvářejí výsledky, které jsou cenné pro účastníky procesu. Právě případy použití jsou hlavní hnací silou, která řídí celý vývojový proces, od sběru a projednávání požadavků až po analýzu, návrh a implementaci. Scénáře použití jsou popsány jednoduchým a srozumitelným jazykem tak, aby byly srozumitelné i pro vnějšího čtenáře.
Podle Unified Process je architektura základní organizací celého systému v centru vývojového procesu . Může zahrnovat statické a dynamické prvky, jejich interakci a umožňuje řešit otázky výkonu produktu, rozšiřitelnosti, možnosti opětovného použití prvků, pomáhá překonat ekonomická a technická omezení. Návrhářský tým začíná pracovat na popisu architektury co nejdříve a během vývoje jej neustále rozšiřuje a vylepšuje. Architektura je považována za důležitý aspekt sjednoceného procesu z mnoha důvodů, mezi které patří schopnost vidět celkový obraz, správná aplikace úsilí vývojářů, usnadnění příležitostí pro opětovné použití komponent, vývoj systému, správný výběr případů použití.
Třetím základním principem jednotného procesu je použití iterativního a inkrementálního přístupu . Iterace jsou miniaturní projekty, které umožňují provozovat novější verzi systému. Výsledek iterace, tedy změny provedené v systému, se nazývá přírůstek. Iterativní přístup umožňuje zejména důsledně vylepšovat architekturu systému, zvládat neustálé změny požadavků a flexibilně upravovat plán celého projektu. Závazek k principu nepřetržité integrace umožňuje identifikovat možné problémy v rané fázi. Iterativnost navíc pomáhá minimalizovat rizika spojená s technickými omezeními, architekturou a měnícími se požadavky [5] .
Každý vývojový cyklus se podle Unified Process skládá ze čtyř fází, které představují časový interval mezi důležitými milníky projektu a umožňují manažerům činit důležitá rozhodnutí ohledně pokračování vývojového procesu, rozsahu práce, rozpočtu a harmonogramu.
Počáteční fáze ( angl. Inception ) umožňuje načrtnout hranice systému, určit navrhovanou architekturu, identifikovat kritická rizika a učinit rozhodnutí týkající se zahájení projektu v závislosti na odhadovaných odhadech jeho nákladů, úsilí, harmonogramu a produktu. kvalitní. S touto fází je spojen důležitý milník projektu nazvaný Cíle životního cyklu.
Přípravná fáze ( anglicky Elaboration ) byla vytvořena pro řešení následujících úkolů: objasnění většiny funkčních požadavků; transformace zamýšlené architektury do funkčního prototypu zaměřeného na architekturu; eliminace kritických rizik; konečné rozhodnutí o zahájení projektu a vytvoření dostatečně podrobného plánu. Tato fáze končí milníkem nazvaným „Lifecycle Architecture“.
Konstrukční fáze zahrnuje iterativní vývoj systému, který může úspěšně komunikovat s uživateli v beta prostředí . Přítomnost více či méně fungujícího systému znamená úspěšné dosažení odpovídajícího milníku.
Předání ( angl. Transition ) plně funkčního systému uživatelům je poslední fází vývojového cyklu. Milníkem je pro ni uvedení produktu [6] .
V rámci sjednoceného procesu existuje v každé vývojové fázi pět typů pracovních postupů: požadavky, analýza, návrh, implementace a testování.
Každý proces je soubor činností vykonávaných různými členy projektového týmu. Účelem procesů shromažďování požadavků je například vytvořit model případů použití, který vám umožní identifikovat hlavní funkční požadavky na systém. Analytické procesy a odpovídající model umožňují vývojářům strukturovat funkční požadavky; Proces návrhu popisuje fyzickou implementaci případů užití a je abstrakcí pro následující model. Procesní a implementační model popisuje, jak se návrhové prvky týkají softwarových komponent, včetně zdrojového kódu, dynamických knihoven atd. Poslední z modelů, popisující testování, vysvětluje, jaké systémové testy a testy jednotek a jak by měl vývojový tým provádět [7] .
Každá z fází popsaných v Jednotném procesu se skládá z iterací , což jsou miniaturní dílčí projekty s omezeným trváním. Každá iterace zpravidla v té či oné míře zahrnuje všech pět prvků pracovního postupu. Výsledkem iterace je přírůstek , vydání obsahující vylepšení oproti předchozí verzi produktu.
Během iterace vývojový tým provede následující kroky:
V rámci Unified Process je artefakt jakákoliv informace, která hraje důležitou roli v procesu vývoje. Mezi artefakty používané inženýry patří modely, prototypy, výsledky testů atd. Artefakty manažera jsou plán projektu, obchodní případy atd. Důležitou součástí jednotného procesu je, že systém není považován za připravený k použití, dokud nejsou všechny relevantní artefakty nedokončený.
Exekutor je role, kterou může na projektu hrát jednotlivý zaměstnanec. Rozdíl mezi hercem a hercem (z případů užití) je v tom, že druhý se dívá na systém „zvnějšku“, zatímco herec se dívá „zevnitř“. Umělci vytvářejí artefakty, buď sami, nebo ve skupinách či týmech. Je důležité si uvědomit, že stejná osoba může v projektu hrát více rolí: analytik může například také identifikovat případy použití a popsat je.
Každá z variant pracovního postupu zahrnuje několik činností – úkolů, na kterých účinkující pracují, aby získali artefakty [9] .
Jednotný proces je základem řady metodologií vývoje softwaru, včetně [10] :
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|