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: Porovnání verzí
Řádek 4: | Řádek 4: | ||
=== Metodika vývoje software === | === Metodika vývoje software === | ||
− | *'''Metoda''' nám definuje '''jak''' dosáhnout požadovaného cíle, je nějaký prostředek poznání. | + | *'''Metoda''' nám definuje, '''jak''' dosáhnout požadovaného cíle, je nějaký prostředek poznání. |
*'''[[Metodiky projektového managementu, jejich obsah a smysl|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č'''. | *'''[[Metodiky projektového managementu, jejich obsah a smysl|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č'''. | ||
Řádek 10: | Řádek 10: | ||
=== Metodika UP === | === 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 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 === | ||
Řádek 23: | Řádek 23: | ||
* Fáze vytvoření implementačního modelu | * Fáze vytvoření implementačního modelu | ||
* Implementační zavedení | * Implementační zavedení | ||
− | * Testování | + | * [[Testování softwaru]] |
* Udržování systému a provoz | * Udržování systému a provoz | ||
* Stažení systému z užívání (po jeho neaktuálnosti) | * Stažení systému z užívání (po jeho neaktuálnosti) | ||
Řádek 36: | Řádek 36: | ||
=== Profese podílející se na vývoji === | === 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í. | + | 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í. |
<br /> | <br /> | ||
Řádek 43: | Řádek 43: | ||
<br /> | <br /> | ||
− | '''řízení projektů vývoje IS:''' | + | '''řízení projektů vývoje [[Informační systém|informačního systému (IS)]]:''' |
* zabývá se organizační a ekonomickou stránkou vývoje IS | * zabývá se organizační a ekonomickou stránkou vývoje IS | ||
* odpovědný projektový manažer (PM) | * odpovědný projektový manažer (PM) | ||
Řádek 54: | Řádek 54: | ||
<br /> | <br /> | ||
'''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:''' | '''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“ | * „chirurgický tým“ | ||
* „tým hlavního programátora“ | * „tým hlavního programátora“ | ||
* „agilní skupina“, atd. | * „agilní skupina“, atd. | ||
− | + | nestrukturované – práce je dělena podle objemu | |
* samostatní pracovníci („osaměli vlci“) | * samostatní pracovníci („osaměli vlci“) | ||
* „horda“ | * „horda“ | ||
Řádek 70: | Řádek 70: | ||
==== Analytik ==== | ==== 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. | + | 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 [[Informace|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...) ==== | ==== 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. | + | 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é struktury|datových struktur]], chování, řízení a bezpečnosti SW. |
==== Databázový specialista ==== | ==== Databázový specialista ==== | ||
Řádek 93: | Řádek 93: | ||
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. | 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álový styl vývoje == |
=== Vodopádový (Watterfall) === | === Vodopádový (Watterfall) === | ||
Řádek 107: | Řádek 107: | ||
* '''není flexibilní''' - pokud se během vývoje objeví nový požadavek na SW, musí se celý proces začít znovu od začátku. | * '''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ý. | * '''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álový === |
[[Soubor:Spirálovitý model.png|vpravo|náhled]] | [[Soubor:Spirálovitý model.png|vpravo|náhled]] | ||
Framework - kombinace '''sekvenčního a iterativního typu'''. | Framework - kombinace '''sekvenčního a iterativního typu'''. | ||
Řádek 124: | Řádek 124: | ||
* '''komplikovaný''' | * '''komplikovaný''' | ||
* '''zákazník vidí až konečný výsledek''' | * '''zákazník vidí až konečný výsledek''' | ||
− | + | * '''Pravidelné testování''' - dochází k včasnému odhalení chyb. | |
== Označení verzí SW == | == 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). | 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). | ||
Řádek 147: | Řádek 147: | ||
Klíčová slova: Vývoj software, software, metodiky, metody, konceptuální model, Vodopádový model, Spirálovitý model, agilní metody, projektový management, verze SW | Klíčová slova: Vývoj software, software, metodiky, metody, konceptuální model, Vodopádový model, Spirálovitý model, agilní metody, projektový management, verze SW | ||
+ | |||
+ | Kategorie: Státnicové otázky UISK |
Aktuální verze z 27. 11. 2020, 18:35
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.
Obsah
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í softwaru
- 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 informačního systému (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.[1]
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álový 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álový
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
- Pravidelné testování - dochází k včasnému odhalení chyb.
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.[2]
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
Reference
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
Kategorie: Státnicové otázky UISK