Proces vývoje informačních systémů Vývoj informačních systémů

Pamatuj: Při realizaci softwarového projektuje velmi důležitá komunikace se zákazníkem. Komunikace se zákazníkem je jedna z nejobtížnějších částí projektu, a to i tehdy (často právě tehdy), jedná-li se o zákazníka poučeného.

Komunikace se zákazníkem Na počátku má zákazník obvykle velmi jednoduché otázky, na které je velmi obtížné a často nemožné okamžitě odpovědět: Rozumíte mému problému? Umíte navrhnout systém, který bude řešit můj problém? Jak dlouho vám bude trvat vyvinout takový systém? Kolik to bude stát?

Mýty o řízení projektu mýtus skutečnost Existují normy, procedury, kuchařky jak co udělat … Jsou nepoužitelné, nejsou kompletní, neřeší naše problémy … Máme CASE, nejnovější počítače.... Počítače nejsou rozhodující, i nejnovější CASE neřeší vše ... Jestliže "nestíháme", dodáme více programátorů.... Neumí, nejsou seznámeni s problémem, musíme je školit....

Zákaznické mýty mýtus skutečnost Obecné zadání stačí, aby se začal psát program Formální a detailní specifikace je podmínkou dobrého SW Požadavky se průběžně mění, ale SW je přizpůsobivý Ano, SW se snadno přizpůsobí, ale a jakou cenu? Čím později se požadují změny, tím jsou dražší

Mýty praktika mýtus skutečnost Jestliže napíšeme program a ten "chodí", je hotovo Čím dříve začneme psát program, tím později bude hotov. 50% - 70% práce na programu je až po předání zákazníkovi Dokud program "neběží" nezjistím jeho kvalitu Existují metody formální evaluace kvality Jediný produkt úspěšného projektu je funkční program Je to jen část výsledného produktu. Musíme doplnit dokumentaci, testování, údržbu, zaškolení

Plán projektu (1) Abychom mohli naplánovat práce na projektu, musíme mimo jiné vědět, co vše bychom měli zákazníkovi předat. Mezi předávané části - produkty (deliverables) patří: dokumentace předvedení funkce návrh subsystémů důkaz přesnosti prezentace efektivity, bezpečnosti a realizace

Plán projektu (2) Během práce na projektuje nutné stanovit jednotlivé aktivity a kontrolní dny, tzv. milníky (milestones).

Plán projektu (3)

Plánování času Pravidlo 90-90: Prvních 90% projektu spotřebuje 90% času. Zbývajících 10% projektu spotřebuje dalších 90% času 

Příčiny pozdního dodání softwaru Nejčastější příčiny pozdního dodání softwaru: nerealistický termín stanovený někým vně softwarové skupiny změna požadavků zákazníka, se kterou se nepočítalo podcenění pracnosti a nebo nutných zdrojů rizika, která nebyla uvažována při plánování projektu technické obtíže, které nebyly předpokládány lidské problémy, které nebyly předpokládány nedorozumění a nebo špatná komunikace mezi členy týmu chyba managementu projektu, že nepoznal, že se projekt zpožďuje a nezahájil opravné akce.

Obrana Obrana proti nerealistickým termínům zákazníka: Udělej podrobný odhad podle dat z minulosti. Urči odhad pracnosti a trvání projektu. Použij přírůstkový model procesu a sestav plán dodání jádra systému, které bude zahrnovat kritické funkce systému a bude jej možné dodat do plánovaného termínu. S tím, že se zbytek dodá později. Připrav dokumentaci tohoto plánu. Vysvětli zákazníkovi, že jeho termíny jsou nerealistické a proč. Navrhni mu přírůstkovou strategii a dohodni se na řešení.

Základní principy plánování času Rozdělení na zvládnutelné aktivity a úkoly Stanovení vzájemných závislostí Alokace času Zvážení pracnosti Stanovení odpovědností Stanovení výstupů Definování milníků

Pravidlo 40-20-40 „Jestliže nestíháme plnit časový plán, přijmeme víc programátorů a doženeme skluz.“ To je nesmysl, protože vztah mezi počtem lidí a produktivitou není lineární Pro rozložení pracnosti při práci na projektu platí pravidlo 40-20-40, které říká, že 40% práce je analýza, 20 % je kódování a 40 % testování

Náročnost projektů Projekty pro vývoj nového konceptu Projekty vývoje nové aplikace Projekty pro zdokonalení aplikace Projekty údržby aplikace Projekty pro reinženýrství (zpětné inženýrství)

Základní části plánu projektu úvod projektové odhady strategie řízení rizik časový harmonogram zdroje projektu organizační členění způsob kontroly přílohy

Jak sledovat plán? periodické schůze o stavu projektu (zprávy o pokroku a problémech) vyhodnocování výsledků všech kontrol během SI procesu sledování, zda formální milníky byly splněny v plánovaných dnech porovnání skutečných a plánovaným časů pro zahájení všech úkolů neformální setkám s realizátory k získání jejich subjektivního odhadu postupu a předpokládaných problémů

Základní imperativ sledování Je potřeba ihned reagovat na případné problémy (i časový skluz je příznakem nějakého problému)!

Nástroje pro sledování plánu Pro sledování plánu je užitečné použít existující nástroje, kterými jsou: Matice zodpovědností Síť úkolů (PERT.CPM) Časový diagram (Úsečkový graf, Ganttův diagram) Tabulka projektu (projekt table) Tabulka zdrojů (sloupcový graf, histogram)

Matice zodpovědností (1) Matice zodpovědností vymezuje role a pravomoci subjektů, účastnících se prací na projektu: Subjekt1 Subjekt2 Subjekt3 … Činnost1 P Činnost2 O Činnost3 K S

Matice zodpovědností (2) V prvním sloupci tabulky jsou uvedeny činnosti, pro které se přiřazují odpovědné subjekty. V první řádce tabulky jsou uvedeny odpovědné subjekty (osoby, role, organizační jednotky). Uvnitř tabulky jsou uvedena písmena označující typy zodpovědnosti.

Obvyklé typy zodpovědnosti subjekt je za činnost odpovědný O subjekt činnost provádí K subjekt má zodpovědnost konzultační S subjekt má odpovědnost schvalovací

CPM metoda kritické cesty (1) V této metodě se nejdřív stanoví doba trvání úkolů. Stanovuje se nejpravděpodobnější odhad času podle statistických modelů. Nemáme-li statistiku nebo modely, požádáme vhodného praktika (často externistu)

CPM metoda kritické cesty (2) Potom se spočítají hraniční časy pro jednotlivé úkoly podle těchto kriterií: B1 - nejdříve možné zahájení úkolu (když předchozí úkoly jsou zvládnuté v minimálním čase) B2 - nejpozději přípustný začátek úkolu (aniž by došlo ke skluzu projektu) E1 - nejdříve možné ukončení úkolu ((l)+doba trvání) E2 - nejpozději přípustný konec úkol ((2)+ doba trvání) povolený skluz určí se kritická cesta (řetěz úkolů, určujících trvání projektu)

CPM metoda kritické cesty (3) Kritická cesta je nejdelší cestou v grafu. Doba jejích činností přímo ovlivňuje dobu trvání projektu. Průchodem od začátku do konce se určí nejčasnější možné začátky činností (vstupuje-li do určitého uzlu více činností, je to maximální hodnota - max. součet nasbíraných dob trvání), Průchodem od konce se určí nejpozději přípustné začátky. Pak se určí časové rezervy a kritická cesta. Činnosti kritické cesty mají nulovou časovou rezervu.

CPM metoda kritické cesty (4) Dobu projektu můžeme zkrátit: změnou logiky vazeb přesunem vnitřních zdrojů (z nekritických do kritických činností) nasazením dodatečných zdrojů

Citát "Aplikace síťových metod v řízení softwarových prací trpí nepřesností v odhadech dob řešení. Rovněž návaznost může být jiná než se předpokládá.. .používají se spíše u velkých projektů a i tam se střídavým úspěchem.„ Prof. Jaroslav Král

Tabulka projektu (project table) Tabulka projektu obsahuje následující údaje: úkol plánované zahájení skutečné zahájení plánované skončení skutečné skončení přidělené osoby pracnost poznámky

Sloupcový diagram zdrojů Peak Units Overallocated Výhodnější je zapojit zdroje, co nejpozději (Metoda Just in Time) - projekt tak váže nejmenší objem oběžných prostředků.

Metoda členění prací, WBS (1) Základní principem metody tvorby WBS je hierarchická dekomposice projektu na menší celky, aby bylo možné zvýšit přesnost odhadů nákladů, času a zdrojů, definovat srovnávací základnu pro měření výkonů a řízení prací, umožnit jasné stanovení odpovědnosti

Metoda členění prací, WBS (2) WBS = Work Breakdown Structure

Postup WBS (1) Stanovte hlavní prvky projektu. Jsou to obecně předměty dodávek (služby i produkty) a řízení projektu. Jako první úroveň dekomposice mohou být použity fáze životního cyklu, které budou v další úrovni rozčleněny podle předmětů dodávek. Rozhodněte, zda na dané úrovni je možné stanovit odpovídající odhady nákladů a trvání. V případě, že je odpovídající odhad možný, přejděte ke kroku 4, jinak ke kroku 3. Stanovte dílčí předměty dodávek. Dílčí předměty by měly být stanoveny podle hmatatelných, ověřitelných výsledků. Mohou zahrnovat služby i produkty. Vraťte se ke kroku 2.

Postup WBS (2) Ověřte správnost dekomposice: Jsou položky na nejnižší úrovni dekomposice nutné a postačující pro dokončení dekomponované položky? Je každá položka definovaná jasně a úplně? Jinak je potřeba popisy revidovat nebo rozšířit. Může být každá položka naplánována, rozpočtována a přidělena konkrétní organizační jednotce (např. týmu nebo pracovníku), která převezme odpovědnost za její provedení? Jestliže ne, je potřeba provést revizi.

Postup WBS (3) Pokud jsou prvky WBS popsány jako předměty dodávek, přepište je jako činnosti,vedoucí k tvorbě těchto dodávek. Poznámka: Při tvorbě WBS využívejte jako vzory WBS minulých podobných projektů

Děkuji za pozornost.