Metodika vývoje softwaru

Metodologie vývoje softwaru je souhrn různých postupů, pravidel a nástrojů používaných pro návrh, plánování a řízení vývoje softwaru a zároveň obor, který se zabývá vytvářením, porovnáváním a ovlivňováním jednotlivých metodik vývoje softwaru.

Metodika vývoje softwaru je jeden konkrétní postup používaný pro vývoj softwaru. Metodikou se též rozumí využití určitého frameworku a dalších specifických postupů pracovním týmem nebo celou organizací při vývoji aplikačního software nebo informačního systému.

Historie

První formalizovaný metodický framework pro vývoj informačních systémů byl sestaven v roce 1960 pod jménem SDLC (Systems development life cycle). Hlavní myšlenkou SDLC bylo "nastavit vývoj informačních systémů velmi účelným, strukturovaným a metodickým způsobem, což vyžadovalo, aby všechny fáze vývoje od nápadu až po dodání finálního systému byly provedeny postupně a vždy v nezměněné formě"[1]. Hlavním cílem tohoto metodického frameworku bylo "vyvinout rozsáhlé funkční obchodní systémy pro velké obchodní konglomeráty. Typickou aktivitou informačních systémů bylo hromadné zpracování dat a složité aritmetické výpočty, tzv. number crunching"[1].

Frameworky metodik softwarového vývoje

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řehled specifických postupů softwarového vývoje

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

Specifické přístupy metodik softwarového vývoje

Každý metodický framework softwarového vývoje předepisuje specifické přístupy jak vyvíjet a udržovat software. Od počátků informačních technologií vzniklo mnoho vývojových postupů. Mezi nejvýznamnější z nich patří:

  • Vodopádový přístup : lineární resp. sekvenční typ frameworku
  • Prototypový přístup : iterativní typ frameworku
  • Inkrementální přístup : kombinace sekvenčního a iterativního typu frameworku
  • Spirální přístup : kombinace sekvenčního a iterativního typu frameworku
  • RAD přístup (Rapid Application Development) : iterativní typ frameworku
  • Extrémní programování

Vodopádový přístup

Původní "vodopádový model". Postupuje se odshora dolů, jako když teče vodopád.
Související informace naleznete také v článku Vodopádový model.

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.

Prototypový přístup

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řírůstkový) přístup

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ý přístup

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) přístup

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.

Další postupy užívané při vývoji softwaru

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.

Témata metodik softwarového vývoje

Softwarové metodiky se dotýkají různých témat, kterými jsou také:

  • Pohledový model
  • Modelování business procesů a datové modelování
  • Automatizované softwarové inženýrství
  • Integrované vývojové prostředí
  • Modelovací jazyky
  • Programovací vzory
  • Softwarový framework
  • Proces vývoje softwaru

Pohledový model

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.

Modelování podnikových procesů a dat

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]

Odkazy

Reference

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

  1. a b Geoffrey Elliott, Global Business Information Technology, 2004, str.87
  2. a b c d e f g Centers for Medicare & Medicaid Services, Office of Information Services, Selecting a development approach Archivováno 31. 3. 2010 na Wayback Machine, 27. března 2008
  3. RERYCH, Markus. Wasserfallmodell > Entstehungskontext [online]. Institut für Gestaltungs- und Wirkungsforschung, TU-Wien [cit. 2008-12-31]. Dostupné online.  (německy)
  4. ROYCE, Winston. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON. Srpen 1970, čís. 26, s. 1–9. Dostupné v archivu pořízeném dne 2016-03-15.  Archivováno 15. 3. 2016 na Wayback Machine (anglicky)
  5. Georges Gauthier merx & Ronald J. Norman (2006). Unified Software Engineering s Java. p.201.
  6. Michal Beneš, Přehled OO notací a metodik Archivováno 22. 8. 2009 na Wayback Machine
  7. Edward J. Barkmeyer, Concepts for Automating Systems Integration, NIST 2003
  8. a b c Paul R. Smith & Richard Sarfaty, Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.

Související články

Externí odkazy

Média použitá na této stránce

Vodopadovy model.png
Autor: Původní autor Paul A. Hoadley, Licence: CC BY-SA 2.5
Vodopádový model
TEAF Matrix of Views and Perspectives cz.svg
TEAF Matrix of Views and Perspectives
Process and data modeling cz.svg
Process and data modeling
Software Development Spiral cz.svg
Spirálový přístup k vývoji sofware - analýza, hodnocení, vývoj a plánování
Three software development patterns mashed together cz.svg
Three software development patterns mashed together.