Úvod do softwarového inženýrství

Hlavním cílem předmětu je praktické seznámení s softwarovým procesem, činnostmi při vývoji softwaru a vizuálním modelováním pomocí UML. Ve výsledku by měl student být schopen vhodně použít tyto metody k dosažení vyšší kvality své práce (a tedy i vyšší spokojenosti klienta a v neposlední řadě pak vyšší odměny).

K tomu budeme po celý semestr používat variaci na klasické téma - elektronický obchod. První cvičení budeme věnovat popsání požadavku klienta (“nejvíc se nám vyplatí prodej příslušenství”) a jejich převedení na vykonatelné požadavky (“po přidání produktu do košíku nabídnout vždy nejprodávanější přislušenství k tomuto produktu”).

<note important>Cvičení 14.9.2011 je z důvodu mé nepřítomnosti nahrazeno samostudiem. Vžijte se do role klienta - vaší motivací je navymýšlet si do svého e-shopu co nejvíce věcí (prozatím bez ohledu na technickou realizovatelnost nebo cenu). Prozkoumejte tedy na internetu běžící e-shopy a nabídku firem vyrábějících e-shopy. Své požadavky si sepište a přineste na další cvičení. Pokud nevíte, kde začít, zkuste http://www.google.cz/search?q=tvorba+eshopu</note>

Tyto požadavky ohodnotíme podle náročnosti na stupnici 1 až 10 (pokud by náročnost přesáhla 10, pak musíme požadavek rozdělit na více menších) a pokusíme se “vyjednat s klientem smlouvu”.

V optimálním případě je celý vývoj aplikace předcházen business modelováním (detailně viz. příslušný předmět v magisterském studiu). To ovšem nebývá pravidlem a je třeba, aby se to odrazilo v následující části, specifikování požadavků.

Specifikace požadavků slouží převážně k dohodnutí všech zúčastněných stran na tom, co by měla budoucí aplikace splňovat. Dohodnuté funkce a vlastnosti bývají následně podkladem pro smlouvu a není tedy vhodné tuto část odbýt, protože byste pak nemuseli za svou práci dostat zaplaceno.

Požadavky se dělí na funkční a nefunkční, přičemž typicky funkční požadavky představují objemově větší část celé specifikace, ale nemusí představovat větší část celkových nákladů na zhotovení. Klasickým nefunkčním požadavkem je rychlost odezvy, množství současně pracujících uživatelů, zálohování nebo použitá technologie.

Funkční požadavky bývají zachyceny ve formě tzv. případů užití (use case), popř. volném textu. Doplňkově se vytváří i use case diagram k vizuálnímu zachycení vazeb (include, extend, generalization, association), nebývá ovšem opěrným bodem pro implementaci.

Případ užití může být popsán různými způsoby, ovšem typické jsou následující prvky:

• název
• původce (pokud za klienta vystupuje více osob)
• datum vytvoření
• spustění a podmínky (například uživatelské role, které mají k funkci přístup)
• popis událostí (základní cesta, alternativní cesta, rozšíření, chybové cesty)
• návaznosti
• historii změn

Pro vyzkoušení naučených pojmů si zkuste následující diagram převést do slovního popisu. Na druhý den si můžete pak zkusit ze slovního popisu diagram nakreslit, zda bude odpovídat originálu.