Rational Unified Process v testování softwaru
Metodika Rational Unified Process (RUP) využívá při svém návrhu objektově orientovaný přístup a pro znázornění procesů v akci je navržena a dokumentována notace UML (Unified Modeling Language). Používá komerčně ověřené techniky a postupy.
Jedná se o proces považovaný za těžký a přednostně použitelný pro velké vývojové týmy a velké projekty, ale skutečnost, že je rozsáhle přizpůsobitelný, umožňuje jeho přizpůsobení projektům libovolného rozsahu.
Specifika
Pro řízení projektů poskytuje model RUP(Rational Unified Process) disciplinované řešení, jako jsou úkoly a odpovědnosti nastíněné v rámci organizace vývoje softwaru.
RUP (Rational Unified Process) je sám o sobě softwarový produkt. Je modulární a automatizovaný a celá jeho metodika je podporována několika vývojovými nástroji integrovanými a prodávanými společností IBM prostřednictvím jejích „Rational Suites“.
Mezi konkurenční metody v oblasti softwarového inženýrství patří „čisté místnosti“ (považované za těžké) a agilní (lehké), jako je extrémní programování (XP-Extreme Programming), Scrum, FDD a další.
Existují určité pokyny a šablony, které jsou definovány, pro pracovníky výrobního cyklu, podle RUP: část klienta a hodnocení postupu projektu jeho vedením. To pomáhá vývojářům soustředit se na projekt.
Požadavky vedení
Vhodná dokumentace je nezbytná pro každý rozsáhlý projekt; všimněte si, že RUP popisuje, jak dokumentovat funkčnost, omezení systému, omezení návrhu a obchodní požadavky.
Případy užití a scénáře jsou příklady závislých procesních artefaktů, které byly považovány za mnohem účinnější při zachycování funkčních požadavků.
Použití architektury založené na komponentách
Architektura založená na komponentách vytváří systém, který lze snadno rozšiřovat, podporuje opakované použití a software intuitivní porozumění. Komponentou se obvykle rozumí objekt v objektově orientovaném programování.
RUP poskytuje systematický způsob budování tohoto typu systému, který se zaměřuje na tvorbu proveditelné architektury v raných fázích projektu, tedy před vyčleněním zdrojů ve velkém měřítku.
Komponenty, o nichž se zde hovoří, jsou zpravidla součástí infrastruktur, které již v místě existují. Mezi tyto infrastruktury patří CORBA a také Component Object Model (COM).
Použití vizuálních softwarových modelů v modelu RUP
Abstrahováním programování kódu a jeho reprezentací pomocí grafických stavebních bloků může být RUP účinným způsobem, jak získat přehled o řešení.
Používání vizuálních modelů může také umožnit osobám s méně technickým profilem (jako jsou klienti) lépe porozumět danému problému, a tím se více zapojit do projektu jako celku.
Modelovací jazyk UML se stal průmyslovým standardem pro reprezentaci projektů a je široce používán v RUP!“
Víte více: Přečtěte si o exkluzivních podrobnostech agilního testování
Kontrola kvality softwaru
Nezajišťuje kvalitu softwaru je nejčastějším selháním všech projektů počítačových systémů. Obvykle se na kvalitu softwaru myslí až po dokončení projektů nebo za kvalitu odpovídá jiný vývojový tým.
Řízení a kontrola změn softwaru
Ve všech softwarových projektech je existence změn nevyhnutelná. RUP definuje metody řízení a monitorování změn. Vzhledem k tomu, že malá změna může ovlivnit aplikace zcela nepředvídatelným způsobem, je řízení změn pro úspěch projektu nezbytné.
RUP (Rational Unified Process)také definuje oblasti práce a bezpečnosti, které programátorovi zaručují, že změny v jiném systému neovlivní váš systém.
Fáze metodiky RUP
Tyto pokyny jsou zatím obecné, je třeba je dodržovat a projít jimi celý životní cyklus projektu. Fáze (viz obrázek níže) označují důraz, který je v daném okamžiku kladen na projekt. Pro zachycení časového rozměru projektu rozděluje RUP projekt do čtyř různých fází:
Iniciace neboli návrh: důraz na rozsah systému;
Příprava: důraz na architekturu;
Stavba: důraz na vývoj;
Přechod: důraz na aplikaci.
RUP je také založen na 4 P:
- Lidé
- Design
- Produkt
- Proces
Vrstvy jsou složeny z iterací. Iterace jsou časová okna; iterace mají definovaný termín, protože fáze jsou objektivní.
Všechny fáze generují artefakty. Ty se použijí v další fázi a dokumentují projekt a umožňují lepší následnou kontrolu.
Fáze návrhu
Fáze návrhu neboli iniciační fáze obsahuje pracovní postupy nezbytné pro souhlas zúčastněných stran – stakeholderů – s cíli, architekturou a plánováním projektu. Pokud mají tito aktéři dobré znalosti, nebude nutné analyzovat. V opačném případě je třeba provést propracovanější analýzu.
V této fázi se základní požadavky na systém transformují do případů užití. Cílem není uzavřít je vůbec, ale pouze ty, které jsou nezbytné pro utváření stanoviska.
Tento krok je obvykle krátký a slouží k určení, zda je možné v projektu pokračovat, a k definování rizik a nákladů posledního z nich. Může být vytvořen prototyp, který má klient schválit. Jak uvádí RUP, ideální je provádět iterace, které musí být dobře definovány z hlediska jejich množství a cílů.
Fáze vypracování
Příprava bude sloužit k návrhu systému, jako doplněk k průzkumu a/nebo dokumentaci případů užití, před architekturou systému, k přezkoumání obchodního modelu projektu a k zahájení verze uživatelské příručky. Je třeba přijmout: Popis produktu (zvýšení + integrace) je stabilní; projektový plán je spolehlivý? Náklady jsou způsobilé?
Fáze výstavby
Ve fázi výstavby začíná fyzický vývoj softwaru, produkční kódy, alfa testy. Na začátku přechodové fáze byly provedeny beta testy.
Musíte přijmout testy, stabilní a testovací procesy a systémový kód je „základní“.
Přechodová fáze
V této fázi dochází k dodání („nasazení“) softwaru, kdy se provádí plán nasazení a dodání, monitorování a kvalita softwaru. Dojde k dodání produktů (verzí, vydání) a umístění spokojenosti zákazníka. V této fázi také probíhá školení uživatelů.
Disciplíny metodiky RUP (Rational Unified Process)
Disciplína business modelování
Organizace jsou stále více závislé na informačních systémech, proto je nezbytné, aby inženýři informačních systémů věděli, jak jsou aplikace integrovány do vývoje organizace. Společnosti investují do IT, které chápou konkurenční výhodu přidané hodnoty technologií.
Cílem obchodního modelování je nejprve nastolit lepší porozumění a komunikaci mezi obchodním inženýrstvím a softwarovým inženýrstvím.
Pochopení obchodu znamená, že softwaroví inženýři musí pochopit strukturu a dynamiku cílové společnosti (klienta), současné problémy, kterým organizace čelí, a potenciální metody a strategie nápravy.
Dalším důležitým aspektem, který nesmí být podceněn, je, že příslušné strany, jako jsou vývojáři i zákazníci a také koncoví uživatelé, musí mít jasnou představu o organizaci a důležitým rysem tohoto porozumění je, že musí být společné pro všechny zúčastněné strany.
Business modelování vysvětluje, jak popsat vizi organizace, v níž bude systém implementován, a jak tuto vizi použít jako základ pro popis procesů, funkcí a odpovědností.
Požadavky na systém
Tento předmět vysvětluje, jak získat požadavky od zainteresovaných stran („zúčastněných stran“) a převést je na soubor požadavků, aby produkty fungovaly v rámci budovaného systému, a poskytnout podrobné požadavky na to, co je pro systém nezbytné.
Analýza a návrh oboru („návrh“)
Účelem analýzy a návrhu je ukázat, jak bude systém prováděn. Cílem je vytvořit systém, který:
Vykonává v konkrétním prostředí provádění úkoly a funkce uvedené v popisech případů užití
Uspokojuje všechny potřeby
Je snadno udržovatelný, pokud nedochází ke změnám funkčních požadavků, výsledky projektu v modelu analýzy a návrhu volitelně má model analýzy.
Model návrhu se využívá jako konceptuální verze zdrojového kódu, zobrazuje pouze nezbytné minimum. To umožňuje uživateli libovolné jedné inspekce zjistit, jakým stylem byl zdrojový kód vykreslen.
Projektový model je vykreslen tak, že obsahuje různá dělení návrhů. Tato rozdělení jsou uložena v rámci určitých subsystémů.
Každý subsystém má odlišné rozhraní, které je přesně navrženo. Obsahuje také popisy toho, jak objekty v těchto třídách spolupracují při provádění návrhů případů užití.
Implementace disciplíny
Účinkem aplikace je:
- S odkazem na vrstvené subsystémy uspořádané pro aplikaci se konfiguruje organizační kód.
- Provádějí se různé třídy nebo rozdělení komponent. Mezi tyto komponenty patří
- Zdrojové soubory
- Spustitelné soubory a
- Binární soubory
- Komponenty vyvinuté jako jednotky jsou testovány
Inkorporují výsledky vytvořené jednotlivými vykonavateli (nebo týmy), do spustitelného systému. Systémy jsou dosaženy prostřednictvím komponent aplikace.
Proces má za cíl plnit důležitou funkci, kterou je definovat přesný postup, který má být využit, aby bylo možné znovu využít komponenty, které jsou buď; již existující, nebo byly čerstvě zavedeny.
To umožňuje bezproblémovou možnost údržby systému a podstatné zlepšení šancí na využití komponent.
Disciplinární testování
Účelem disciplinárního testování je:
- Kontrola interakce mezi objekty
- Kontrola správné integrace všech softwarových komponent
- Kontrola správného provedení všech požadavků
- Identifikace a zajištění odstranění závad před implementací softwaru
- Ujištění, že všechny závady jsou opraveny, přezkoumány a uzavřeny
Závěr
V případě, že se v projektu vyskytnou vady, může si jejich odstranění vyžádat zbytečné náklady, protože vady nebudou včas odhaleny.
Pokud je však projekt testován jako celek, bude to přínosné, protože veškeré vady, které by se mohly do projektů vkrádat, mohou být identifikovány a zjištěny co nejdříve.
To bude mít zase za následek masivní snížení nákladů spojených s odstraněním vad. To je iterativní přístup, který navrhuje Racionální unifikovaný proces.
Aby testování přineslo ovoce a mělo co nejlepší výsledky, musí být testy prováděny na čtyřech parametrech kvality a také musí být stanoveny normy, které musí být splněny, aby byl projekt považován za úspěšně prošlý testem.