Softwarové inženýrství
Definice softwarového inženýrství podle IEEE zní: „Softwarové inženýrství je aplikace systematických, disciplinovaných a měřitelných postupů na vývoj, provoz a údržbu software, tedy použití obecných inženýrských principů na software“
Vznik a rozvoj softwarového inženýrství jako uznávaného a samostatného oboru způsobila především tzv. softwarová krize v šedesátých letech 20. století. V této době se kvalita software neúnosně snižovala, projekty se prodražovaly, zpomalovaly a na trhu vládla nejistota. Vzniklo několik organizací, které měly za úkol tuto situaci napravit. Výsledkem je vznik softwarového inženýrství, které nabízí procesy, metody a nástroje použitelné k vývoji kvalitního software.
Rámcové aktivity (framework activities)
Dostane-li inženýr nějaký úkol, ptá se nejprve CO má přesně udělat. Když si je jistý, že porozuměl zadání, začne plánovat KDY bude kterou činnost dělat. Potom začne přemýšlet o tom JAK bude zadání realizovat. Teprve pak se pustí do práce a po jejím dokončení výsledek odevzdá.
Tento myšlenkový postup je velmi obecný a lze jej použít i na vývoj software. Uvedené schéma je sestavené z tzv. rámcových aktivit, které jsou stejné pro všechny projekty, nezávisle na jejich velikosti či složitosti. Těmito aktivitami jsou:
- Komunikace (communication) – CO
- Plánování (planning) – KDY
- Modelování (modeling) – JAK
- Vývoj (construction)
- Předání (deployment)
Komunikace
Tato aktivita vyžaduje spolupráci mezi dodavatelem (vývojářem) a zákazníkem. Zahrnuje především sběr požadavků a s ním související činnosti.
Jednoduché projekty
- Vytvořte seznam osob, které se budou podílet na realizaci projektu.
- Dohodněte neformální setkání těchto osob.
- Od každé osoby získejte požadavky na produkt.
- Diskutujte s nimi a sestavte konečný seznam požadavků.
- Každému požadavku přiřaďte prioritu.
- Nalezněte konflikty, rizika a nejasnosti v požadavcích.
Složitější projekty
- Vytvořte seznam osob, které se budou podílet na realizaci projektu.
- Pohovořte si s každou osobou zvlášť o jejich očekáváních a představách.
- Na základě těchto schůzek sestavte pracovní seznam požadavků.
- Naplánujte další schůzky pro sběr a upřesnění požadavků.
- Na každé schůzce vytvořte neformální scénáře.
- Další komunikací scénáře upřesněte.
- Obohaceni novými informacemi upravte pracovní seznam požadavků.
- Každému požadavku přiřaďte prioritu.
- Seskupte požadavky tak, aby je bylo možné implementovat a dodávat postupně.
- Zjistěte, kde leží hranice a omezení systému.
- Diskutujte o způsobu testování výsledného systému.
Plánování
Během plánování vzniká hrubá představa o času a prostředcích potřebných pro vývoj produktu. Také se vyhodnocují možná rizika.
Modelování
Během modelování vznikají modely, které slouží k lepšímu porozumění problematice (jak ze strany vývojáře, tak ze strany zákazníka) a vytváří se struktura celého systému. Při modelování vznikají grafická schémata a diagramy, které se lépe hodí k zachycení abstraktních myšlenek. Aby byly tyto diagramy mezinárodně srozumitelné a jednotné pro celý průmysl, bylo nutné pravidla pro kresbu těchto schémat a diagramů nějakým způsobem formalizovat.
Za oficiální grafický jazyk pro zakreslování schémat a diagramů (nejen) pro účely softwarového inženýrství se nyní považuje jazyk UML (Unified Modeling Language).
Během modelování je nanejvýš vhodné dodržovat nějaká dobrá a ověřená pravidla. Pro objektové programování existuje několik strategií, jako je například GRASP, SOLID a další. Mnohé z nich jsou ale použitelné i obecně.
Vývoj
Během vývoje vzniká vlastní zdrojový kód software v konkrétním programovacím jazyce. Do fáze vývoje patří i testování.
Testování
Úkolem testování je co nejdříve odhalit a popsat chyby (defekty, bugy) ve vyvíjeném produktu. Ty mohou vzniknout při implementaci nebo jako postranní efekt špatného návrhu. Čím dříve je chyba objevena, tím levnější je její oprava (debug). Zajímavým poznatkem je, že chyby se v software obecně nachází zejména na hranicích a přechodech (těsně před a po minimální i maximální hodnotou parametru, nuly…).
Při testování se využívají následující pomocné konstrukce:
- Pahýl (stub, dummy) je jednoduchá náhražka podkomponenty, která velmi jednoduše simuluje její chování nebo jen zaznamenává volané metody. Pahýly se postupně nahrazují plnohodnotnými komponentami.
- Driver je řídící program, který vytváří vstupy a kontroluje výstupy testované komponenty. Prakticky tedy simuluje uživatelské rozhraní či situaci, které (alespoň teoreticky) mohou nastat.
Existují různé přístupy k testování a druhy testů:
- Jednotkové testování (unit-testing) se zabývá testováním zpravidla nejmenších nedělitelných (atomických) komponent systému.
- Integrační testování se používá při skládání jednotlivých komponent do sebe. Většinou se spouští vždy, když je pahýl nahrazen skutečnou komponentou nebo se nějaká komponenta změní.
- Uživatelská validace je provedena zákazníkem po dodání produktu. Zákazník kontroluje, zda byly správně implementovány všechny jeho požadavky.
Předání
Když je produkt dokončen, zbývá jej předat zákazníkovi. Zákazník po vyzkoušení produktu poskytne zpětnou vazbu, která může být vstupem pro další vývoj systému. Do této fáze lze zařadit i následnou údržbu.
Údržba
Předpokládá se, že alespoň 80% existujícího zdrojového kódu není správně zdokumentováno, okomentováno či strukturováno. Proto je údržba obtížná a nákladná. Náklady na údržbu obvykle překračují 50% z celkových nákladů na vývoj a provoz software.
Definice údržby podle IEEE zní: „Údržba softwarového systému nebo jeho komponenty je jeho modifikace za účelem adaptace na změnu prostředí, zlepšení výkonnosti či ostatních jeho vlastností.“
Typy údržby
- Korektivní údržba – především oprava chyb.
- Adaptivní údržba – adaptace software na změnu prostředí, nemění funkcionalitu systému.
- Perfektivní údržba – implementace změn či upřesnění uživatelských požadavků.
- Preventivní údržba – pokrývá aktivity směřující ke zjednodušení budoucí údržby, například aktualizace dokumentace, přidávání komentářů a zlepšování modularity systému.
Zpětné inženýrství
Zpětné inženýrství je proces analýzy subjektu za účelem identifikace jeho komponent a jejich vzájemných vztahů, který vede k vytvoření reprezentace systému v jiné formě či vyšší úrovni abstrakce.
Inženýr pracující v údržbě software velmi často zpětné inženýrství využívá, aby jeho stávající zdrojový kód pochopil a provedl v něm požadované změny.
Standardní modely procesů
Softwarové inženýrství nabízí několik standardizovaných postupů, jak vyvíjet software. Vývojářský tým je může převzít a aplikovat v praxi.
Tradiční modely
Tradiční modely procesů patří mezi ty nejstarší, a tak jim je často vyčítána zastaralost, přílišná statičnost, formálnost a neohrabanost.
Waterfall Model (vodopádový)
Vodopádový model je nejstarším standardním modelem. Je přísně lineární a sekvenční. Je použitelný, když jsou požadavky zákazníka dobře specifikovány (např. úprava či vylepšení stávajícího systému). Podobná situace může nastat při údržbě.
Model naopak selhává v dynamickém prostředí, kde se prostředí i požadavky mění. Dalšími jeho nedostatky jsou poměrně pozdní dodání produktu (až na konci celého cyklu) a blokování lidských zdrojů.
vodopádový model (Waterfall Model)
Incremental Model (přírůstkový)
Přírůstkový model je iterativní variantou vodopádového modelu. Projekt je rozdělen do iterací. Každá iterace končí dodáním či vylepšením produktu nebo nějaké jeho části. Každá tato iterace probíhá jako vodopádový model.
Hlavní výhodou přírůstkového modelu je kratší doba nutná k dodání prvního produktu. Ten je poté v dalších iteracích vylepšován a rozšiřován. Model rozkládá riziko a je vhodný například pro menší týmy, které si netroufají na dlouhý sekvenční vývoj.
přírůstkový model (Incremental Model)
Evoluční modely
Evoluční modely berou na vědomí, že svět byznysu i software je podroben neustálým změnám. Tyto modely přijímají změnu jako nedílnou součást vývoje.
Spiral Model (spirálový)
TODO
Agilní modely
Extrémní programování (XP)
TODO
Scrum
TODO
Reference
- R. Pressman – Software Engineering: A Practitioner's Approach, Sixth Edition
- http://martinfowler.com/…ntStubs.html#…
- http://www.computer.org/…l/web/swebok
- http://www.uml.org/