Racionální jednotný proces - Rational Unified Process

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

Rational Unified Process ( RUP ) je iterativní vývoj software proces rámec vytvořený Rational Software Corporation, divize společnosti IBM od roku 2003. RUP není jediný konkrétní normativní proces, ale spíše adaptabilní proces rámec , určené k přizpůsobeny vývojové organizace a softwarové projektové týmy, které budou vybírat prvky procesu, které jsou vhodné pro jejich potřeby. RUP je konkrétní implementace Unified Process .

Dějiny

Rational Software původně vyvinul racionální jednotný proces jako produkt softwarového procesu. Produkt obsahuje hypertextovou databázi znalostí s ukázkovými artefakty a podrobnými popisy mnoha různých typů aktivit. RUP je součástí produktu IBM Rational Method Composer (RMC), který umožňuje přizpůsobení procesu.

Vedení původního týmu RUP měl za úkol zkušený technický zástupce Rational Philippe Kruchten .

Tyto počáteční verze kombinovaly rozsáhlé zkušenosti organizace Rational Software s budováním objektově orientovaných systémů (označované pracovníky Rational v terénu jako racionální přístup) s pokyny společnosti Objectory k praktikám, jako jsou případy použití, a začlenily rozsáhlý obsah technologie Object Modeling Technology (OMT) Jima Rumbaugha ) přístup k modelování, Grady Boochova Boochova metoda a nově vydaný UML 0,8.

Aby se tato rostoucí znalostní základna stala přístupnější, měl Philippe Kruchten za úkol sestavit explicitní procesní rámec pro moderní softwarové inženýrství. Toto úsilí využilo mechanismus doručování procesů založený na HTML vyvinutý Objectory. Výsledný „Rational Unified Process“ (RUP) dokončil strategický stativ pro Rational:

  • programů na zakázku proces, který veden vývoj
  • nástroje, které automatizovaly aplikaci tohoto procesu
  • služby, které urychlily přijetí procesu i nástrojů.

Tyto pokyny byly v následujících verzích rozšířeny o znalosti založené na zkušenostech společností, které společnost Rational získala.

V roce 1997 byly k přístupu přidány požadavky a testovací disciplína, většina dalšího materiálu pochází z metody Requirements College vyvinuté Deanem Leffingwellem a kol. ve společnosti Requisite, Inc., a metoda SQA Process vyvinutá ve společnosti SQA Inc., přičemž obě společnosti byly získány společností Rational Software.

V roce 1998 přidal Rational Software dvě nové disciplíny:

  1. obchodní modelování, velká část tohoto obsahu již byla v Objectory Process
  2. Disciplína konfigurace a změn, která pochází z akvizice společnosti Pure Atria Corporation.

Tyto dodatky vedou k zastřešující sadě zásad, které byly definovány společností Rational a vyjádřeny v rámci RUP jako šest nejlepších postupů pro moderní softwarové inženýrství:

  1. Vyvíjejte iterativně s rizikem jako primárním ovladačem iterace
  2. Spravujte požadavky
  3. Využijte architekturu založenou na komponentách
  4. Vizuálně modelujte software
  5. Průběžně ověřujte kvalitu
  6. Změny ovládání

Tyto osvědčené postupy byly úzce sladěny s produktovou řadou Rational a obě poháněly pokračující vývoj produktů Rational a také je používaly terénní týmy Rational, aby pomohly zákazníkům zlepšit kvalitu a předvídatelnost jejich úsilí při vývoji softwaru.

Byly zahrnuty další techniky včetně testování výkonu, návrhu uživatelského rozhraní, datového inženýrství a aktualizace, která odráží změny v UML 1.1.

V roce 1999 byla zavedena disciplína projektového řízení a techniky na podporu vývoje softwaru v reálném čase a aktualizací, které odrážejí UML 1.3. Kromě toho byla ve stejném roce vydána první kniha popisující tento proces, Unified Software Development Process ( ISBN  0-201-57169-2 ).

V letech 2000 až 2003 řada změn zavedla pokyny z pokračujících zkušeností Rational Field s iterativním vývojem, kromě podpory nástrojů pro uzákonění instancí RUP a přizpůsobení rámce RUP. Tyto změny zahrnovaly:

  1. zavedení konceptů a technik z přístupů, jako je eXtreme Programming (XP), které se později začaly souhrnně označovat jako agilní metody. To zahrnovalo techniky, jako je párové programování, návrh prvního testu a papíry, které vysvětlovaly, jak RUP umožnil škálování XP pro použití na větších projektech.
  2. kompletní přepracování testovací disciplíny, aby lépe odráželo, jak byla testovací práce prováděna v různých iteračních vývojových kontextech.
  3. zavedení podpůrných pokynů - známých jako „mentorové nástrojů“ - k uzákonění postupů RUP v různých nástrojích. Ty v zásadě poskytovaly uživatelům metod Rational nástrojovou podporu krok za krokem.
  4. automatizaci přizpůsobení RUP způsobem, který by zákazníkům umožnil vybrat součásti z rámce procesu RUP, přizpůsobit jejich výběr pomocí vlastních doplňků a stále začlenit vylepšení v následujících vydáních od Rational.

IBM získala Rational Software v únoru 2003.

V roce 2006 vytvořila IBM podmnožinu RUP přizpůsobenou pro poskytování agilních projektů - vydanou jako metodu OpenSource s názvem OpenUP prostřednictvím webové stránky Eclipse .

Racionální témata jednotného procesu

Stavební bloky RUP

RUP je založen na sadě stavebních kamenů a prvků obsahu, které popisují, co má být vytvořeno, potřebné potřebné dovednosti a podrobné vysvětlení popisující, jak má být dosaženo konkrétních rozvojových cílů. Hlavní stavební bloky neboli prvky obsahu jsou následující:

  • Role (kdo) - Role definuje soubor souvisejících dovedností, kompetencí a odpovědností.
  • Pracovní produkty (co) - Pracovní produkt představuje něco, co vyplývá z úkolu, včetně všech dokumentů a modelů vytvořených během zpracování procesu.
  • Úkoly (jak) - Úkol popisuje jednotku práce přiřazenou Role, která poskytuje smysluplný výsledek.

V rámci každé iterace jsou úkoly rozděleny do devíti oborů:

Čtyři fáze životního cyklu projektu

Fáze a disciplíny RUP.

RUP určil životní cyklus projektu sestávající ze čtyř fází. Tyto fáze umožňují, aby byl proces prezentován na vysoké úrovni podobným způsobem, jakým by mohl být prezentován projekt ve stylu „vodopádu“, ačkoli v zásadě klíč k procesu spočívá v iteracích vývoje, které leží ve všech fázích . Každá fáze má také jeden klíčový cíl a milník na konci, který označuje dosažený cíl. Vizualizace fází a disciplín RUP v čase se označuje jako hrbový graf RUP .

Počáteční fáze

Primárním cílem je adekvátně rozšířit systém jako základ pro validaci počátečních nákladů a rozpočtů. V této fázi je stanoven obchodní případ, který zahrnuje obchodní kontext, faktory úspěchu (očekávané příjmy, uznání trhu atd.) A finanční prognózu. Pro doplnění obchodního případu je generován základní model případu použití, plán projektu, počáteční posouzení rizik a popis projektu (základní požadavky projektu, omezení a klíčové vlastnosti). Po jejich dokončení je projekt zkontrolován podle následujících kritérií:

  • Souběh zúčastněných stran na definici rozsahu a odhadech nákladů/plánu.
  • Porozumění požadavkům, jak dokazuje věrnost primárních případů použití.
  • Důvěryhodnost odhadů nákladů/plánu, priorit, rizik a procesu vývoje.
  • Hloubka a šířka jakéhokoli architektonického prototypu, který byl vyvinut.
  • Stanovení výchozího bodu, podle kterého se budou porovnávat skutečné výdaje s plánovanými výdaji.

Pokud projekt tento milník, nazývaný cíl životního cyklu životního cyklu, neprojde, může být buď zrušen, nebo opakován poté, co byl přepracován tak, aby lépe splňoval kritéria.

Fáze zpracování

Primárním cílem je do konce této fáze zmírnit klíčové rizikové položky identifikované analýzou. Fáze zpracování je místo, kde se projekt začíná formovat. V této fázi je provedena analýza problémové domény a architektura projektu dostává základní podobu.

Výsledkem fáze zpracování je:

  • Model případu použití, ve kterém byly identifikovány případy použití a aktéři a je vyvinuta většina popisů případů použití. Model případu použití by měl být z 80% hotový.
  • Popis architektury softwaru v procesu vývoje softwarového systému.
  • Spustitelný architekturu , která si uvědomuje, architektonicky významné případy použití.
  • Seznam obchodních případů a rizik, které jsou revidovány.
  • Plán rozvoje celkového projektu.
  • Prototypy, které prokazatelně zmírňují každé identifikované technické riziko.
  • Předběžná uživatelská příručka (volitelně)

Tato fáze musí projít kritériem milníku architektury životního cyklu a odpovědět na následující otázky:

  • Je vize produktu stabilní?
  • Je architektura stabilní?
  • Znamená spustitelná ukázka, že hlavní rizikové prvky jsou vyřešeny a vyřešeny?
  • Je plán fáze výstavby dostatečně podrobný a přesný?
  • Souhlasí všechny zúčastněné strany, že současné vize lze dosáhnout pomocí současného plánu v kontextu současné architektury?
  • Jsou skutečné vs. plánované výdaje na zdroje přijatelné?

Pokud projekt nemůže tento milník projít, je ještě čas, aby byl zrušen nebo přepracován. Po opuštění této fáze však projekt přechází do vysoce rizikové operace, kde jsou změny mnohem obtížnější a škodlivější, pokud jsou provedeny.

Klíčovou analýzou domény pro zpracování je architektura systému.

Fáze výstavby

Primárním cílem je vybudování softwarového systému. V této fázi je hlavní důraz kladen na vývoj komponent a dalších funkcí systému. Toto je fáze, kdy probíhá převážná část kódování. Ve větších projektech může být vyvinuto několik iterací stavby ve snaze rozdělit případy použití na zvládnutelné segmenty za účelem produkce prokazatelných prototypů.

Přechodová fáze

Primárním cílem je „tranzit“ systému z vývoje do výroby, jeho zpřístupnění a porozumění koncovému uživateli. Činnosti této fáze zahrnují školení koncových uživatelů a správců a beta testování systému za účelem jeho ověření proti očekávání koncových uživatelů. Systém také prochází fází hodnocení, každý vývojář, který nevyrábí požadovanou práci, je nahrazen nebo odstraněn. Produkt je také zkontrolován z hlediska úrovně kvality stanovené ve Počáteční fázi.

Pokud jsou splněny všechny cíle, je dosaženo milníku vydání produktu a vývojový cyklus je dokončen.

Produkt IBM Rational Method Composer

Produkt IBM Rational Method Composer je nástrojem pro procesy vytváření, konfigurace, prohlížení a publikování. Další podrobnosti viz IBM Rational Method Composer a open source verze projektu Eclipse Process Framework (EPF).

Osvědčení

V lednu 2007 byla vydána nová certifikační zkouška RUP pro IBM Certified Solution Designer - Rational Unified Process 7.0, která nahrazuje předchozí verzi kurzu s názvem IBM Rational Certified Specialist - Rational Unified Process . Nová zkouška bude nejen testovat znalosti související s obsahem RUP, ale také s prvky struktury procesu.

K úspěšnému složení nové certifikační zkoušky RUP musí osoba absolvovat test IBM 839: Rational Unified Process v7.0 . Na zkoušku s 52 otázkami máte 75 minut. Průběžné skóre je 62%.

Šest osvědčených postupů

Pro softwarové projekty je definováno šest nejlepších postupů softwarového inženýrství, aby se minimalizovaly chyby a zvýšila produktivita. Tyto jsou:

Rozvíjejte iterativně
Nejlepší je znát všechny požadavky předem; často tomu tak však není. Existuje několik procesů vývoje softwaru, které se zabývají poskytováním řešení pro minimalizaci nákladů ve fázích vývoje.
Spravujte požadavky
Vždy mějte na paměti požadavky stanovené uživateli.
Použijte součásti
Rozbití pokročilého projektu je nejen navrženo, ale ve skutečnosti nevyhnutelné. To podporuje schopnost testovat jednotlivé součásti před jejich integrací do většího systému. Opětovné použití kódu je také velkým plusem a lze jej snáze provést pomocí objektově orientovaného programování .
Modelujte vizuálně
Pomocí diagramů představte všechny hlavní komponenty, uživatele a jejich interakci. „UML“, zkratka pro Unified Modeling Language , je nástroj, který lze použít k tomu, aby byl tento úkol proveditelnější.
Ověřte kvalitu
Vždy proveďte testování hlavní části projektu v libovolném okamžiku. Testování se v průběhu projektu stává těžším, ale mělo by být konstantním faktorem při tvorbě jakéhokoli softwarového produktu.
Změny ovládání
Mnoho projektů je vytvořeno mnoha týmy, někdy na různých místech, mohou být použity různé platformy atd. V důsledku toho je důležité zajistit, aby změny provedené v systému byly neustále synchronizovány a ověřovány. (Viz Plynulá integrace ).

Viz také

Reference

Další čtení

  • Ivar Jacobson , Grady Booch a James Rumbaugh (1999). Proces vývoje jednotného softwaru
  • Gary Pollice , Liz Augustine , Chris Lowe a Jas Madhur (2003). Vývoj softwaru pro malé týmy: přístup zaměřený na RUP
  • Per Kroll, Philippe Kruchten (2003). Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP
  • Per Kroll, Bruce Mac Isaac (2006). Agility a disciplína snadno: Praktiky z OpenUP a RUP
  • Philippe Kruchten (1998). Racionální jednotný proces: Úvod
  • Ahmad Shuja, Jochen Krebs (2007). Průvodce referencemi a certifikací RUP
  • Walker Royce, správa softwarových projektů, jednotný rámec

externí odkazy