Unified Process - Unified Process

Vývoj softwaru
Hlavní činnosti
softwarového inženýrství
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy

Unified Software Development Process nebo Unified Process je iterativní a inkrementální proces vývoje softwaru rámec. Nejznámějším a rozsáhle dokumentovaným vylepšením Unified Process je Rational Unified Process (RUP). Dalšími příklady jsou OpenUP a Agile Unified Process .

Profil typického projektu ukazující relativní velikosti čtyř fází sjednoceného procesu.

Přehled

Sjednocený proces není jen proces, ale spíše rozšiřitelný rámec, který by měl být přizpůsoben konkrétním organizacím nebo projektům. Rational Unified Process je, podobně, přizpůsobitelný rámec. V důsledku toho je často nemožné říci, zda upřesnění procesu bylo odvozeno z UP nebo z RUP, a proto se názvy obvykle používají zaměnitelně.

Název Unified Process na rozdíl od Rational Unified Process se obecně používá k popisu obecného procesu, včetně těch prvků, které jsou společné pro většinu upřesnění. Název Unified Process se také používá, aby se zabránilo potenciálním problémům s porušováním ochranných známek, protože Rational Unified Process a RUP jsou ochranné známky společnosti IBM . První kniha, která tento proces popsala, měla název Unified Software Development Process ( ISBN  0-201-57169-2 ) a v roce 1999 ji vydali Ivar Jacobson , Grady Booch a James Rumbaugh . Od té doby různí autoři, kteří nejsou členy společnosti Rational Software , vydávají knihy a články pod názvem Unified Process , zatímco autoři přidružení k Rational Software upřednostňují název Rational Unified Process .

V roce 2012 byl vydán rámec Disciplined Agile Delivery , hybridní rámec, který přijímá a rozšiřuje strategie z Unified Process, Scrum, XP a dalších metod.

Sjednocené charakteristiky procesu

Iterační a přírůstkové

Diagram znázorňující, jak se mění relativní důraz různých oborů v průběhu projektu
Diagram znázorňující, jak se mění relativní důraz různých oborů v průběhu projektu

Unified Process je iterativní a přírůstkový vývojový proces. Fáze Vypracování, Konstrukce a Přechod jsou rozděleny do série iterací v časovém rámečku. (Počáteční fázi lze u velkého projektu také rozdělit na iterace.) Každá iterace má za následek přírůstek , což je vydání systému, který obsahuje přidané nebo vylepšené funkce ve srovnání s předchozím vydáním.

Ačkoli většina iterací bude zahrnovat práci ve většině procesních oborů ( např. Požadavky, design, implementace, testování), relativní úsilí a důraz se v průběhu projektu změní.

Orientace na architekturu

Unified Process trvá na tom, že architektura je jádrem úsilí projektového týmu o utváření systému. Protože žádný jediný model nepostačuje k pokrytí všech aspektů systému, sjednocený proces podporuje více architektonických modelů a pohledů.

Jedním z nejdůležitějších výstupů procesu je základní linie spustitelné architektury, která je vytvořena během fáze zpracování. Tato částečná implementace systému slouží k ověření architektury a slouží jako základ pro zbývající vývoj.

Zaměřeno na riziko

Sjednocený proces vyžaduje, aby se projektový tým zaměřil na řešení nejkritičtějších rizik na počátku životního cyklu projektu. Výstupy každé iterace, zejména ve fázi zpracování, musí být vybrány tak, aby bylo zajištěno, že budou nejprve řešena největší rizika.

Životní cyklus projektu (fáze sjednoceného procesu)

Unified Process rozděluje projekt do čtyř fází:

  • Počátek
  • Vypracování (milník)
  • Konstrukce (vydání)
  • Přechod (finální produkční vydání)

Každá fáze bude obecně obsahovat více iterací (na obrázku fáze UP pojmenované I1, E1, E2, C1 atd.). Přesný počet iterací v každé fázi závisí na rozsahu a povaze projektu. Všimněte si, že zde ukázka fáze UP obsahuje přesně 1, 2, 4 a 2 iterace ve čtyřech fázích, ale toto je pouze příklad toho, jak by konkrétní projekt mohl vypadat.

Počáteční fáze

Počátek je nejmenší fází projektu a v ideálním případě by měl být docela krátký. Pokud je počáteční fáze dlouhá, pak to může být známkou nadměrné up-front specifikace, což je v rozporu s duchem sjednoceného procesu.

Následující jsou typické cíle pro počáteční fázi:

  • Založit
  • Připravte si předběžný harmonogram projektu a odhad nákladů
  • Proveditelnost
  • Kupte si nebo rozvíjejte

Milník životního cyklu cíle znamená konec počáteční fáze.

Vytvořte přibližnou vizi systému, vytvořte obchodní případ, definujte rozsah a vytvořte hrubý odhad nákladů a harmonogram projektu.

Fáze zpracování

Během fáze vypracování se od projektového týmu očekává, že zachytí zdravou většinu požadavků na systém. Primárním cílem Elaboration je však řešit známé rizikové faktory a stanovit a ověřit architekturu systému. Běžné procesy prováděné v této fázi zahrnují vytváření diagramů případů použití , koncepčních diagramů ( třídní diagramy se pouze základním zápisem) a balíkových diagramů (architektonické diagramy).

Architektura je ověřována především implementací základní úrovně spustitelné architektury. Toto je částečná implementace systému, který zahrnuje hlavní architektonicky nejvýznamnější komponenty. Je postaven v sérii malých časově ohraničených iterací. Na konci fáze zpracování musí být architektura systému stabilizovaná a základní linie spustitelné architektury musí prokázat, že architektura bude podporovat klíčové funkce systému a bude vykazovat správné chování z hlediska výkonu, škálovatelnosti a nákladů.

Konečnou dodávkou fáze vypracování je plán (včetně odhadů nákladů a harmonogramu) pro fázi výstavby. V tomto okamžiku by měl být plán přesný a věrohodný, protože by měl být založen na zkušenostech s fází zpracování a protože během fáze vypracování by měly být řešeny významné rizikové faktory.

Fáze výstavby

Výstavba je největší fází projektu. V této fázi je zbývající část systému postavena na základech položených v Elaboration. Funkce systému jsou implementovány v sérii krátkých, časově ohraničených iterací. Každá iterace má za následek spustitelné vydání softwaru. Je obvyklé psát fulltextové případy použití během fáze výstavby a každý z nich se stane začátkem nové iterace. Běžné Unified Modeling Language (UML) diagramy použité v této fázi obsahují diagramy aktivit , sekvenční diagramy , spolupráce diagramy , přechod stavu schémat a diagram interakcí . Jsou provedeny iterativní implementace pro nižší rizika a jednodušší prvky. Poslední dodávkou fáze výstavby je software připravený k nasazení ve fázi přechodu.

Přechodová fáze

Poslední fází projektu je Transition. V této fázi je systém nasazen k cílovým uživatelům. Zpětná vazba přijatá z počátečního vydání (nebo počátečních vydání) může mít za následek další upřesnění, která budou začleněna v průběhu několika iterací přechodové fáze. Fáze přechodu zahrnuje také převody systému a školení uživatelů.

Upřesnění a variace

Upřesnění sjednoceného procesu se navzájem liší v kategorizaci projektových disciplín nebo pracovních toků . Rational Unified Process vymezuje devět oborů: Business modelování , Požadavky , analýza a návrh , Realizace , Zkušební , nasazení , konfigurace a řízení změn , správu projektů , a Životní prostředí . Unified Process Enterprise rozšiřuje RUP přidáním osmi „podnik“ disciplín. Agilní vylepšení UP, jako je OpenUP/Basic a Agile Unified Process, zjednodušují RUP snížením počtu oborů.

Upřesnění se také liší v důrazu kladeném na různé artefakty projektu . Agilní vylepšení zjednodušují RUP zjednodušením pracovních toků a snížením počtu očekávaných artefaktů.

Upřesnění se také liší ve specifikaci toho, co se stane po fázi přechodu. V racionálním sjednoceném procesu obvykle po přechodové fázi následuje nová počáteční fáze. V Enterprise Unified Process následuje po fázi přechodu výrobní fáze.

Počet vylepšení a variací Unified Process je nespočet. Organizace využívající sjednocený proces vždy začleňují své vlastní úpravy a rozšíření. Následuje seznam některých známějších vylepšení a variací.

Reference