Popište proces vývoje softwaru, jeho jednotlivé fáze a charakterizujte profese, které se na něm podílejí. Odlište vodopádový a spirálový styl vývoje. Vysvětlete, jak se typicky označují jednotlivé verze

Software (dále jen SW), neboli programové vybavení počítače, které provádí nějakou činnost. Jedná se o nehmotnou část počítače, tedy opak hardwaru.

Vývoj software

Metodika vývoje software

• Metoda nám definuje jak dosáhnout požadovaného cíle, je nějaký prostředek poznání.
• Metodika je nauka o metodě (neboli pracovní postup), jde o doporučený souhrn různých postupů, etap, přístupů, zásad, postupů, pravidel, metod, technik, nástrojů a dokumentů, plánování a řízení vývoje a zároveň také samostatný obor zabývající se vytvářením, prováděním a ovlivňováním jednotlivých metodik vývoje SW. Definuje odpověď na otázky co, kdy, kdo, a proč.

Dříve se používaly tradiční metodiky vývoje, ty se nakonec neujaly kvůli velké byrokratické zátěži a přešlo se k agilním metodám.

Metodika UP

Metodika UP neboli Unified Process (Unifikovaný/jednotný proces) je základní, generickou a otevřenou metodikou. Tato metodika vychází z průmyslového standardu SEP (Software Engineering Process) a popisuje generický proces pro jazyk UML (Unified Modeling Language). Je možné ji přizpůsobit jakékoliv šíři projektu, zahrnuje řízení rizik a případů užití, soustředění se na architekturu, iterace a přírůstky, vytvoření softwarového produktu.

Metodika RUP

Metodika RUP neboli Rational unified proces je běžně dostupnou verzí UP, která je rozšířena o bohaté uživatelské prostředí.

Fáze vývoje

Vývoj SW se dělí do jednotlivých fází, které představují posloupnost jednotlivých kroků vývoje. Dělení na fáze se odvíjí od způsobu, metody a charakteru organizace i vyvíjeného SW.

1. Způsob dělení

• Definování požadavků na systém
• Vytvoření konceptuálního modelu
• Fáze vytvoření implementačního modelu
• Implementační zavedení
• Testování
• Udržování systému a provoz
• Stažení systému z užívání (po jeho neaktuálnosti)

2. Způsob dělení

• Akvizice
• Vývoj
• Provoz
• Údržba
• Vyřazení

Tento druhý způsob je specifický pro rychlý vývoj, tzv. RAD (Rapid Application Development).

Profese podílející se na vývoji

Na projektu vývoje SW pracuje celý tým specialistů. V týmu je důležité aby měl každý jasně dané své kompetence, pracovní náplň a věděl co co má jak a kdy přesně dělat. Nepostradatelná jen tedy koordinace všech činností a jednotlivců jako celku. Složení týmu nemusí být vždy stejné, záleží na použité metodice vývoje, fázi nebo etapě ve které se projekt zrovna nachází.

Každý tým při vývoji SW podléhá určité organizaci a určitému dělení. Jednou z takových organizací může být např. rozdělení:

řízení projektů vývoje IS:

• zabývá se organizační a ekonomickou stránkou vývoje IS
• odpovědný projektový manažer (PM)
• PM má k dispozici řídicí a realizační tým pracovníků – odborníků

projektování IS:

• vývojáři IS - součástí projektového týmu,
• odpovědný hlavní řešitel (hlavní analytik),
• specifikace zadání, analýza, návrh, implementace, testování, zavádění do provozu.

Týmy je možné rozdělit rovněž podle druhu přístupu. Nejčastějším rozdělením podle přístupu je dělení na týmy:

• strukturované – práce je dělena podle profese
• „chirurgický tým“
• „tým hlavního programátora“
• „agilní skupina“, atd.
• nestrukturované – práce je dělena podle objemu
• samostatní pracovníci („osaměli vlci“)
• „horda“
• „demokratická skupina“, atd.

Vedoucí týmu

Vedoucí vývojového týmu úzce spolupracuje s projektovým manažerem, organizuje a plánuje dílčí úkoly a práci každého jednotlivce v týmu. Je členem komise řízení změn, má kompetenci účastnit se jednání projektového managementu a odpovídá za výslednou práci celého vývojového týmu, který řídí.

Metodik

Specialista na metodiky a metody vývoje SW doporučuje vhodné metodické postupy a metody vývojovému týmu. Navrhuje návrhářské, analytické, programovací, testovací postupy i tvorbu dokumentace. Během vývoje působí pro jednotlivé pracovníky jako odborný konzultant.

Analytik

Odpovídá za specifikace požadavků na počátku, definici typů uživatelů, uživatelské rozhraní, rozhraní SW pro napojení na jiné systémy, funkce SW, chování SW, datové toky, detailní rozbor informací (tak aby podle něj bylo možné zpracovat návrh SW). Musí se orientovat v modelování a problematice zákaznických potřeb. Musí mít schopnost logického uvažování a komunikace jak s týmem, tak se zákazníkem.

Návrhář (GUI, API...)

Na základě práce analytika musí zpracovat kompletní návrh SW. Jeho práce musí odpovídat na otázky "co" má systém zjišťovat, "jak" to bude zjišťovat a jaká bude jeho struktura chování. Zodpovídá tedy za návrh rozhraní, funkcí, datových struktur, chování, řízení a bezpečnosti SW.

Databázový specialista

Odborník zaměřený na databázové systémy (Oracle, MS SQL, Sybase...atd.). Odpovídá za zpracování modelu SW na implementační úrovni ve vybraném databázovém prostředí a instalaci databázových systémů (testovací i provozní fáze u zákazníka).

Programátor

Programátor/vývojář má na starosti tvorbu kódu vyvíjeného SW. Měl by se specializovat na jazyk SQL, vyšší programovací jazyky, tvorbu webových i mobilních aplikací a orientovat se v nástrojích CASE. Odpovídá za výsledný programový kód spustitelných souborů, knihoven tříd, funkcí a procedur...atd., který je v souladu s bezpečnostními požadavky na systém.

Tester

Odpovídá za přípravu testovacích procedur a vlastní testování SW.

Dokumentarista

Tvůrce dokumentací zpracovává dokumentaci k vyvíjenému SW, může se také podílet na tvorbě příruček pro uživatele a materiálů určených pro školení uživatelů.

Školitel

Připravuje proškolení (ke všem verzím systému) uživatelů a také jej provádí. Dělá školení pro zákazníka.

Uživatelská podpora

Služba, která je zákazníky často vyžadována a může tvořit podstatnou část příjmů dodavatele SW. Od dodavatele za to vyžaduje vybudování organizační struktury, která bude službu zajišťovat a řešení problémů a připomínek ze strany zákazníka.

vodopádový X spirálovitý styl vývoje

Vodopádový (Watterfall)

Framework - lineární nebo také tzv. sekvenční typ
Vodopádový styl vývoje SW je považován za první kompletní metodiku vývoje SW. Vývoj je v tomto modelu vyobrazen jako neustále se svažující tok činností bez cyklických návratů. Postup je přesně daný, jde od první fáze k další přísně sekvenčním způsobem. Fáze jdou za sebou bez iterací a po každé fázi následuje schvalovací proces, kterým musí projit také veškerá dokumentace. Bez tohoto procesu schválení není možné pokračovat a začít další fázi vývoje. Pokud se i přes schválení najde v další fázi chyba, je nutné se vrátit zpět do fáze předchozí. Model je spíše teoretický myšlenkový postup pro studium etap životního cyklu.

Klady

• jednoduchost - jednoduchý na pochopení, práci i jeho řízení.
• přehlednost - je snadno zjistitelné v jaké fázi se projekt právě nachází, co už je splněno a kde nastala chyba, pokud se tak stane.

Zápory

• stáří - změna postoje společnosti na vývoj SW od jeho zavedení.
• není flexibilní - pokud se během vývoje objeví nový požadavek na SW, musí se celý proces začít znovu od začátku.
• zákazník vidí až konečný výsledek - není možné během vývoje prezentovat zákazníkovi jak bude vypadat výsledek, jelikož jsou hotové jen určité fáze vývoje. Konečný výsledek, tedy nemusí být pro zákazníka uspokojivý.

Spirálovitý

Framework - kombinace sekvenčního a iterativního typu.
Novější metodika, než watterfall. Je výsledkem snahy napravit nedostatky předchozího modelu. Vznikl v roce 1958 z iniciativy Barryho Boehma. Tento model se dá označit spíše za model životního cyklu SW než metodiky vývoje jelikož je v něm vyobrazeno cyklické opakování jednotlivých kroků vývoje (tzv. iterace). Pokud chceme přejít do další fáze vývoje, je nutné provést analýzu možných problémů a rizik.

Vychází z předchozího modelu, ale přináší novinky:

• interaktivní přístup
• podrobná analýza rizik

Klady

• vhodné i pro velké projekty - nezávislost na metodice, která se při samotném vývoji použije.

Zápory

• komplikovaný
• zákazník vidí až konečný výsledek

Označení verzí SW

Běžným způsobem je označovat verze desetinným třídníkem čili řadou číslic oddělených tečkou. První je tzv. major verze (hlavní verze), za tečkou následuje minor verze (vedlejší verze) a třetí číslice označuje revizi. Verze se s postupujícím vývojem navyšují, obvykle s ohledem na rozsah provedených změn. Podle číslic může kdokoli poznat, která verze je starší a která novější. Zatímco změna nejnižší číslice (koncová číslice) obvykle znamená nevýznamné změny, případně izolované opravy programátorských chyb. Změny číslic od tečky vlevo znamenají zásadnější změny (změna API, kompletní přepsání kódu).

Některá stadia vývoje softwaru se mohou označovat dalšími přívlastky, např. alfaverze, betaverze, stable, prerelease (zkratka „pre“), release candidate (zkratka „RC“) aj.

Zdroje

Použitá literatura

Martinů Jiří, Čermák, Petr. Metodiky vývoje software[online]. Olomouc: Moravská vysoká škola Olomouc, o.p.s., 2018 [cit. 2020-11-22]. dostupné z: https://dl1.cuni.cz/pluginfile.php/886974/mod_resource/content/1/Metodiky-v%C3%BDvoje-software-studijn%C3%AD-text.pdf Danel. Informační systémy: Úvod do softwarového inženýrství. [online]. [cit. 2020-11-22]. Dostupné z: http://homel.vsb.cz/~dan11/is_skripta/IS%202011%20-%20Softwarove%20inzenyrstvi%20-%20klasicke%20metodiky.pdf

Podobné články

Software Metodiky projektového managementu, jejich obsah a smysl Agilní metody projektování. Principy, role, organizace, nástroje Pracovní rozklad činností (WBS). Principy tvorby, smysl a návaznosti na další části plánu projektu. Řízení změn Konceptuální model

Klíčová slova: Vývoj software, software, metodiky, metody, konceptuální model, Vodopádový model, Spirálovitý model, agilní metody, projektový management, verze SW