Metodika vývoje softwaru

Tři základní postupy používané metodickými frameWorky softwarového vývoje.

Metodické frameworky softwarového vývoje se používají k návrhu, plánování a řízení procesu vývoje informačního systému, což zahrnuje např. i předběžnou definici výstupů a artefaktů, které budou vytvářeny a dodány projektovým týmem v rámci vývoje či údržby aplikace[2].

V průběhu let byla vyvinuta široká škála takových frameworků, přičemž každý z nich měl své silné i slabé stránky. Každý z dostupných metodických frameworků je vhodný pro jiné typy projektů s ohledem na jejich technické, organizační, projektové a další potřeby[2].

Metodické frameworky jsou často vázané na nějakou organizaci, které je dále rozvíjí, podporují a propagují jejich využití. Metodické frameworky jsou často definovány pomocí formální dokumentace. Mezi některé z nich patří např.:

• Rational Unified Process (IBM - RUP) od roku 1998
• Agile Unified Process (AUP) od roku 2005, vyvinul Scott Ambler
• Integrated IT Methodology (QAIassist) od roku 2007

Při praktickém nasazení frameworků softwarového vývoje došlo k rozvoji dalších specifických postupů mezi které patří:

v letech 1970-80

• Strukturované programování od roku 1969
• Cap Gemini SDM (z anglického System Development Methodology), metoda vyvinutá původně holandskou společností PANDATA v roce 1970, přeložená do angličtiny v roce 1974.

v letech 1980-90

• SSADM (z anglického Structured Systems Analysis and Design Methodology) od roku 1980

od 1990

• Rapid Application Development (RAD) od roku 1991.
• Scrum na sklonku 90. let.
• Team Software Process vyvinul Watts Humphrey, Software Engineering Institute (SEI)
• Extrémní programování od roku 1999

Původní "vodopádový model". Postupuje se odshora dolů, jako když teče vodopád.

Vodopádový model je sekvenční vývojový proces, ve kterém je vývoj nahlížen jako neustále se svažující tok (jako když teče vodopád) fázemi analýzy požadavků, návrhu, implementace, testování (validace), integrace a údržby. Jako první formální popis vodopádového modelu je často citován článek který publikoval v roce 1970 Winston W. Royce (1929–1995),[3] ačkoli Royce pojem „vodopádový“ ve svém článku nepoužil. Royce paradoxně představil tento model jako příklad chybného, nefungujícího modelu.[4] Hlavními principy vodopádového přístupu[2]:

• Projekt je rozdělen na fáze jdoucí postupně za sebou, přičemž některé se mohou překrývat.
• Důraz je kladen na plánování, časové rozvrhy, termíny, rozpočty a realizace celého systému najednou.
• Přísná kontrola je udržována po celou dobu životnosti projektu prostřednictvím využití rozsáhlých písemných dokumentů, jakož i prostřednictvím formálních revizí a schvalování uživatelem (signoff) a na konci většiny fází a vstupy od managementu informačních technologií před začátkem další fáze.

Vývoj pomocí vytváření prototypů je takový přístup k vývoji software, kde dochází k vývoji neúplných verzí software, tzv. prototypů. Základní principy prototypového přístupu[2]:

• Není samostatným a kompletním přístupem metodiky vývoje, ale spíše přístup k jednotlivým částem větších tradičních metodik vývoje software (tj. přírůstková metoda, spirála, nebo RAD - Rapid Application Development).
• Snaha snížit nebezpečí projektových rizik rozdělením projektu na menší části a zjednodušit tak možnost změn v průběhu procesu vývoje.
• Uživatel je zapojen v celém procesu vývoje, což zvyšuje pravděpodobnost přijetí konečné implementace uživatelem.
• Malé ukázky systému jsou vyvíjeny iterativním procesem, dokud se prototyp nevyvine tak, že splňuje požadavky uživatele.
• Většina prototypů je sice vyvíjena s tím, že budou vyřazeny, ale v některých případech je možné pokročit od prototypu k funkčnímu systému.
• Aby se předešlo vývoji, který řeší jiný problém, než bylo zadáno, je třeba pochopit základní business problematiku.

Inkrementální přístup je vhodný pro kombinaci sekvenčních a iteračních metodik softwarového vývoje. Cílem je omezit projektová rizika rozdělením projektu na menší segmenty a zjednodušuje možnost zavedení změn během procesu vývoje. Základní principy inkrementálního přístupu:[2]

• Jsou prováděny série malých vodopádů, kde každý vodopád je prováděn pro malou část systému a je dokončen před pokračováním na další přírůstek, nebo
• obecné požadavky jsou definovány dříve než se přikročí k evolučnímu vývoji pomocí malých vodopádů pro jednotlivé přírůstky systému, nebo
• Prvotní koncept, analýza požadavků, design architektury a systémové jádro jsou definovány vodopádovým přístupem, následuje iterativní prototypový přístup, který vrcholí instalací konečného prototypu jako funkčního systému.

Spirálový model.

Spirálový přístup je proces vývoje software, který kombinuje prvky designového přístupu a prototypového přístupu tak, aby zkombinoval výhody obou konceptů shora-dolů (prototypování) a zdola-nahoru (designování). Základní principy spirálového přístupu[2]:

• Zaměřuje se na analýzu rizik a minimalizaci projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje. V průběhu vývoje je také možné vyhodnocovat rizika a zvažovat další pokračování projektu v průběhu životního cyklu.
• Každý cyklus spirály spouští stejný sled kroků pro každou část produktu a pro každou úroveň elaborace (od konceptuálních dokumentů až po programování jednotlivých programů).
• Během každého cyklu spirály jsou tak spouštěny čtyři základní fáze (kvadranty):

1. Analýza – stanovení cílů, alternativ a rozsahu iterace
2. Vyhodnocení – vyhodnocení alternativ, identifikace a řešení rizik
3. Vývoj – vývoj produktu a kontrola očekávaných výsledků
4. Plánování – plán pro příští iteraci

• V počátku každého cyklu se identifikují zainteresované subjekty a jejich podmínky kladené na úspěch iterace, na konci každého cyklu se provádí revize a předání.

Rapid Application Development (RAD) je takový přístup k vývoji software, který zahrnuje iterativní vývoj prototypů. RAD byl původně použit k označení procesu vývoje software, který zavedl James Martin v roce 1991.

Základní zásady RAD [2]:

• Hlavním cílem rychlého vývoje a zavedení vysoce kvalitních (viz nástroje pro řízení kvality) systémů při relativně nízkých investičních nákladech.
• Snaha snížit nebezpečí projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje.
• Soustředí se na rychlý vývoj vysoce kvalitních systémů především pomocí iterativního protypování ve všech stádiích vývoje, aktivním zapojením uživatele a automatizovaných vývojových nástrojů. Tyto CASE (Computer Aided Software Engineering) nástroje mohou zahrnovat generátory grafického uživatelského rozhraní GUI (z anglického Graphical User Interface), programovací jazyky 4. generace, generátory kódu a objektově orientované techniky.
• Klíčový důraz je kladen na naplňování business potřeb, přičemž na technologickou nebo technickou dokonalost je kladen menší důraz.
• Řízení projektu zahrnuje stanovení priorit vývoje a stanovení dodacích lhůt nebo časových rámců. Pokud se projekt zpožďuje, postupuje se spíše snižováním požadavků, než posouváním termínu, aby byl termín naplněn.
• Obecně zahrnuje techniku JAD (Joint Application Development, Joint Application Design), který intenzivně zapojuje uživatele do procesu návrhu systému a to buď prostřednictvím shody na strukturovaných seminářích, nebo pomocí elektronicky vedené interakce.
• Aktivní zapojení uživatelů je nutností.
• Na rozdíl od jednorázových prototypů vzniká produkční software iterativně.
• Je vytvářena dokumentace potřebná pro snazší budoucí vývoj či údržbu.
• V rámci těchto postupů je možné použít standardní systémovou analýzu a design.

Mezi ostatní metodické přístupy a techniky patří:

• Objektově orientované metodické přístupy, jako je Objektově orientovaný design (OOD z anglického Object-oriented design), také známý jako objektově orientovaná analýza a design (OOAD z anglického object-oriented analysis and design), který zavedl Grady Booch. Tento model zahrnuje šest typů diagramů: diagram tříd (class), objektový diagram (object), stavový diagram (state transition), diagram interakcí (interaction), modulový diagram (module) a procesní diagram (process)[5][6].
• Programování metodou shora-dolů (dekompozice) – poprvé formulován výzkumníky IBM (Harlan Mills a Niklaus Wirth).
• Unified Process (UP) je framework pro iterativní vývoj software založení na UML (z anglického Unified Modeling Language). Vývoj organizuje do čtyř etap (Inception, Elaboration, Construction, and Guidelines), z nichž každá se skládá z jedné nebo více iterací. Jednou z nejznámějších aplikací UP je RUP (z anglického Rational Unified Process).
• Agile Software Development zahrnuje skupinu metodik pro vývoj software založených na iterativním vývoji, kde se požadavky i řešení vyvíjí prostřednictvím spolupráce mezi jednotlivými týmy. Termín byl v roce 2001 formulován manifestem.
• Integrated Software Development je metodický framework pro vývoj software zaměřený na dodávku výsledného produktu, který používá tři primární složky životního cyklu (projektový management, vývoj software a testování software). Tyto lze využít pomocí rozličných přístupů k vývoji software (iterativní, vodopádový, spirála, ...). Požadavky i řešení se vyvíjí prostřednictvím spolupráce mezi jednotlivými týmy.

TEAF Matrix pohledů

Pohledový model je framework který poskytuje různé úhly pohledu na systém a jeho prostředí, které mají být použity během procesu vývoje software. Pohledy jsou grafickou reprezentací jednotlivých úhlů pohledu.

Pohledy slouží k pochopení velmi složitých systémů a organizaci jednotlivých prvků problému a řešení do patřičných domén podle odbornosti. Při konstrukci systémů odpovídají úhly pohledu často schopnostem a odpovědnostem jednotlivých částí organizace[7].

Specifikace složitých systémů jsou tak rozsáhlé, že není v silách jednotlivce porozumět všem aspektům specifikací. Navíc má každý účastník procesu různé cíle v rámci systému a tedy i různé důvody pro přezkoumání specifikací systému. Např. manažer bude klást odlišné otázky ohledně sestavení systému, než jaké položí implementátor. Koncept frameworku pohledů tak slouží k poskytnutí odpovídajícího úhlu pohledu na specifikace daného složitého systému. Tyto úhly pohledu uspokojí vždy cílovou skupinu se zájmem o určitý soubor charakteristik systému. S každým úhlem pohledu je spojen specifický druh jazyka s přizpůsobenou slovní zásobou a specifický způsob prezentace pro cílovou audienci daného pohledu.

Příklad interakce business modelu a datového modelu [8]

Grafické znázornění aktuálního stavu poskytuje velmi účinný nástroj pro prezentaci informací jak uživatelům, tak i vývojářům systému.

• Business model zobrazuje funkce spojené s modelovaným procesem a organizace, které tyto funkce vykonávají. Popsáním a zobrazením aktivit a informačních toků je vytvořen základ k další vizualizaci, definici, pochopení a ověření podstaty procesu.
• Datový model poskytuje detailní informace o uložených informacích, které jsou dále použity pro generování kódu aplikace v konečné fázi vývoje, případně pro přípravu funkční specifikace na podporu rozhodnutí, zda aplikaci koupit, či vyrobit.[8]

Model bývá vytvořen většinou až po provedení pohovoru označovanému business analýza. Pohovor probíhá tak, že zprostředkující klade řadu otázek formulovaných tak, aby byly získány potřebné informace popisující celkový proces. Tazatel zprostředkovává získání informací, ale jsou to především účastníci pohovoru, kdo poskytuje informace. Tazatel by měl mít určité povědomí o popisovaných procesech, ale to není tak důležité jako mít strukturovanou metodiku která podporuje kladení otázek expertům. Metodika je velmi důležitá, jelikož obvykle dochází ke zpracování informací od celého týmu tazatelů a výsledky od všech tazatelů do sebe při kompletaci musí zapadat.[8]

V tomto článku byl použit překlad textu z článku Software development methodology na anglické Wikipedii.

• Softwarové inženýrství
• Programování
• Testování softwaru

• Obrázky, zvuky či videa k tématu metodologie vývoje softwaru na Wikimedia Commons