Softwarové projekty a jejich plánování
Příčiny vzniku softwarového inženýrství, historie a vývoj. Softwarový projekt, modely životního cyklu projektů, plánování projektů, techniky dokumentace.
Příčiny vzniku softwarového inženýrství
Proč to vůbec vzniklo?
· Něco bylo špatně
· Počítačů přibývalo, přibývalo i softwarových projektů, ale ubývalo úspěšně dokončených projektů
· Někdy to došlo až na hranici únosnosti – software byl, nebo mohl být, příčinou havárií
(první vesmírné mise např. sonda Mariner I.)
Softwarové inženýrství je disciplina, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích.
Příčina vzniku SWI?
· Obvykle se říká, že to způsobil jev nazývaný „softwarová krize“.
· Dokud výkon počítačů nepřesáhl určitý rozměr, bylo možno se spolehnout na programátorské „hvězdy“.
· Často se počítače využívaly pro vědeckotechnické výpočty, kde záleželo spíše na preciznosti řešení, než na efektivitě tvorby programů.
Moorův zákon: „Výkon hardwaru vzrůstá zhruba dvakrát za dva roky“.
Edsger W. Dijkstra: Hlavní příčinou softwarové krize byl nárůst výkonu hardware. Jinak řečeno, programování nemělo problémy, dokud neexistovaly počítače. Dokud jsme měli slabé počítače, mělo programování jen snesitelně těžké problémy. Nyní máme gigantické počítače a k nim gigantické problémy se softwarem.
Příčinou softwarové krize vždy byl nesoulad mezi složitostí vytvářeného produktu a relativní nedostatečností a nezkušeností softwarové profese. Tento rozdíl způsobuje rozevírání nůžek a důsledkem pak jsou softwarové krize.
Projevy softwarové krize:
· Projekty překračují rozpočet.
· Projekty překračují čas.
· Software nemá dostatečnou kvalitu.
· Software neodpovídá požadavkům.
· Projekt není dobře řiditelný a software je obtížně udržovatelný.
Historie a vývoj
Termín „software“ zavedl v roce 1958 statistik John Tukey (také autor termínu „bit“). Za okamžik zrození termínu „softwarové inženýrství“ se obvykle považuje rok 1968, kdy NATO sponzoruje první konferenci s tímto názvem a na toto téma.
Organizátoři první konference „Softwarové inženýrství“ v roce 1968 zvolili termín „softwarové
inženýrství“úmyslně jako provokativní – naznačující, že produkce software musí přejít na jiné postupy a být podložena teoretickými disciplinami, podobně, jako je tomu u inženýrského přístupu v jiných oborech.
V roce 1969 na ni navázala konference „Techniky softwarového inženýrství“. V roce 1972 vychází první časopis „Transactions on Software Engineering“ (IEEE Computer Society). V roce 1976 vytváří IEEE Computer Society první komisi, která by měla definovat obsah oboru „softwarové inženýrství“.
Další historie - standardizace
· V roce 1979 vytváří Fletcher Buckley standard IEEE 370 pro vytváření plánů zajišťujících kvalitu software. V roce 1986 vzniká standard IEEE 1002, který definuje taxonomii softwarově inženýrských standardů.
· 1990 – 1995 vznikají standardy pro proces životního cyklu software (Standard for Software Life Cycle Processes) - standard ISO/IEC12207, vychází z DoD Std 498.
· V roce 1993 vznikají komise IEEE a ACM, které ústí do společného úsilí definovat softwarové inženýrství jako disciplinu
Co nám SWI přineslo? - Řadu novinek, namátkou některé:
· Softwarové profese a týmy.
· Modely životního cyklu.
· Oddělení správy dat od správy funkčnosti.
· Strukturované metody.
· Objektově-orientované metody.
· Komponentové metody.
· Nové programovací jazyky.
· Softwarové zápisy – unifikovaná notace UML.
· Metodiky tvorby softwaru.
· Plánování, metriky, organizace
Základní znalostní oblasti SWI
· Správa požadavků (Software requirements)
· Softwarový návrh (Software design)
· Tvorba softwaru (Software construction)
· Testování softwaru (Software testing)
· Údržba softwaru (Software maintenance)
· Správa konfigurací (Software configuration management)
· Řízení vývoje (Software engineering management)
· Softwarový proces (Software engineering process)
· Nástroje a metody softwarového inženýrství (Software engineering tools and methods)
· Kvalita softwaru (Software quality)
Softwarový project
Co je to „projekt“?
· Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec, je zaměřena na dosažení nejistého cíle a je uskutečňována pomocí zdrojů lidí a prostředků.
· Projekt je specifická nerutinní akce, která proto vyžaduje plánování.
· Čím složitější je projekt, tím více vyžaduje plánování.
Softwarový projekt je projekt, jehož cílem je vytvoření nebo využití programového díla.
Modely životního cyklu projektů
Hrubý životní cyklus programového díla
· Nápad
· Vznik cca 20% života
· Instalace
· Provoz a údržba cca 80% života
· Zánik
Životní cyklus program. díla
· Nápad
· Neformální specifikace (odborný článek, úvodní studie)
· Formální specifikace (analýza)
· Dekompozice (návrh) - programování ve velkém
· Řešení komponent (modulů)
· Implementace komponent – programování v malém
· Testování komponent
· Integrace komponent do celku
· Testování celku (akceptační test)
· Instalace
· Provoz a údržba
Pro standardizaci postupů jsou zavedeny typové modely životních cyklů, např.:
· Model vodopád (Waterfall)

· Model průzkumník

· Spirálový model

· Přírůstkový model

· Model životního cyklu určuje základní schéma postupu
· Životní cyklus by měl vždy začínat dostatečně přesnou specifikací a návrhem
· Není nutno realizovat celý systém najednou – naopak přírůstky poskytují uživateli dobrý pocit postupu prací
· Model RAD (Rapid Application Development) - model určený pro dobře srozumitelné a dobře vymezené problémy, s malými riziky, využívající krátký vývojový cyklus (cca do 3 měsíců), problém je rozdělen na samostatné moduly
· Evoluční model - využívá skládání komponent, které mohou být vyvíjeny současně, či zakoupeny a upraveny
· Formální metody - využívají specifikací řízený styl vývoje, tj. Generování programů ze specifikací
· Extrémní programování a podobné techniky
· Testy řízený vývoj
Plánování projektů
Co je cílem plánování?
· Plány nejsou vytvářeny proto, aby se dodržovaly (i když se na to dají také použít).
· Plánování je nutné proto, abychom si rozmysleli, co je třeba udělat.
· Plánování je zaměřeno na odstranění nejistoty.
· Plánování se využívá pro sestavení odhadů harmonogramu a rozpočtu.
· Plánování je nástrojem pro řízení projektů.
Plánování projektů je řešení problému: „Jak dlouho a za kolik“ metodou „divide et impera“
Typy plánování
· Strategické plánování
o dlouhodobé – řádově desítky let a více
o cíle organizace, možné způsoby jejich realizace, vnější a vnitřní činitelé, kteří ovlivňují možnosti, výběr alternativ
· Taktické plánování
o střednědobé – řádově měsíce až roky
o způsob, kterým je vybraná alternativa uskutečňována
o přidělení potřebných zdrojů
o rozvržení času
· Operační plánování
o krátkodobé – řádově hodiny až měsíce
o rozvržení času a přidělení potřebných prostředků
Postup plánování
· Strategické plánování definuje potřebné projekty. Plán jejich realizace vzniká taktickým plánováním, kde je projekt rozdělen na úlohy. Řešení úloh přiřazenými zdroji je věcí operativního plánování.
· Plánování projektů je zaměřeno na realizaci – podrobný popis dílčích činností na projektu, jejich vzájemné vztahy a rozvržení času, zdrojů a prostředků na tyto dílčí činnosti.
· Plánování realizace SW projektů je taktické plánování
· Příklad nástroje pro vytváření plánů projektů a sledování jejich realizace je MS Project
Elementy plánu projektu
· úlohy (tasks) - vyžadují čas a zdroje
· milníky (milestones) - kontrolní okamžiky
· zdroje (resources) - lidé, vybavení, místa
· vztahy (dependencies, assignments) - co dříve, co později, kdo-co udělá
Základní problém

Proces plánování projektu
· Vytvoření a uspořádání plánu projektu – rozdělení plánové činnosti na jednodušší elementy
· Rozvržení úloh – analýza vztahů mezi elementy
· Doplnění zdrojů (lidí, zařízení, prostředků) do projektu – odhad potřeb
· Přiřazení nákladů úlohám a zdrojům – porovnání se skutečnými možnostmi
· Úpravy a ladění plánu (až vznikne směrný plán)
· Monitorování a sledování plánu
· Uzávěrka projektu (úschova plánu pro budoucnost)
Techniky dokumentace
Podrobněji popsáno v jednotlivých kapitolách o UML
· strukturované
· pomocí uživatelských scénářů
· s využitím case nástrojů