1. Řízení projektu. 1.1 Vymezení projektu. 1.2 Projektové řízení. 1.3 Popis řízení. 1.4 Nástroje řízení

Transkript

1 Následující text se snaží vypracovat vymezené okruhy otázek, nicméně ne vše se dá z prezentací dobře odpovědět, tak nevím je doporučeno doplnit znalostí dokumentu Otazky.pdf (z dokumentového serveru). Struktura zkouškového testu na řízení projektu, postup tvorby a metriky uzavřené otázky; na metodiku UP a návrhové vzory otevřené otázky. 1. Řízení projektu 1.1 Vymezení projektu Projekt je dočasně vyvinuté úsilí, vynaložené na vytvoření jedinečného produktu nebo služby. Má jasně stanovený cíl, je jedinečný, dočasný, má omezené zdroje a náklady, provádí ho nejistota a rizika a není to periodicky se opakující činnost. 1.2 Projektové řízení Projektové řízení je uplatnění znalostí, dovedností a technik v projektových činnostech s cílem splnit nebo překročit požadavky zainteresovaných stran od projektu. Vyznačuje se vyrovnáním požadavků mezi rozsahem, časem, náklady a jakostí, potřebami zainteresovaných stran a stanovenými a nestanovenými požadavky. 1.3 Popis řízení Formulace projektového řízení rozlišuje projekt (řízený proces aplikace úkolů a zdrojů s definovaným cílem v určeném časovém rámci, např. rekonstrukce domu), subprojekty (začleněny do hlavního projektu), cíl projektu (očekávané změny, dobře měřitelné a snadno kontrolovatelné) a životní cyklus projektu (časová perioda od formulace projektu až po jeho ukončení a vyhodnocení). 1.4 Nástroje řízení CPM metoda kritické cesty síťová analýza PERT technika hodnocení a kontroly programů (Program Evaluation and Review Technique) síťový uzlově orientovaný graf Ganttův diagram (úsečková grafická prezentace na časové ose) Q-GERT grafická technika hodnocení a posouzení front (Queues Graphical Evaluation and Review Technique) EIS exekutivní informační systémy Distribuované projektové řízení aplikuje a integruje nástroje pro plánování a řízení inovací, nástroje pro podporu rozhodování, CAD, CAM, 1.5 Informační strategie Informační strategie je jasně a přesně definovaná strategie společnosti v oblasti využití IT přímo odvozená od strategických věcných cílů společnosti. 1

2 1.5.1 Role informační strategie Čtyři dimenze informační strategie jsou aplikační software, data, organizace a technologie. Ty směřují do koncepčního návrhu IT (vede k návrhu budoucí architektury IT a strategii IT) a vychází z trendů v IT. Informační strategie je součástí podnikatelské strategie, vychází z konceptuálního modelu (z toho vzniká popis stávající architektury IT vedoucí na koncepční návrh IT) Obsah informační strategie Návrh cílového stavu informačních systémů v podniku pro období příštích 2 3 let může obsahovat: Návrh celkové architektury informačních systémů, Stručný popis navrhovaných informačních systémů (aplikací), včetně zhodnocení stávajícího zabezpečení informačními technologiemi, Návrh využití datových objektů a technologické architektury, Návrh úprav organizační struktury, vyhovující definované architektuře informačních systémů. 1.6 Metodologie řízení projektu Výstupem jsou milníky, schvalovací procedury a dokumenty (účel, přiřazení postupu, role, zdroje, technická doporučení, schvalovací procedury). Etapy a kroky se rozdělují milníky, většinou smluvně podchycené (globální analýza, testování, ), mezi každým krokem se provádí revize business cílů a tvorba datového modelu. Činnost je nejmenší plánovatelné akce, tedy činnost je konkrétní úkol (např. studium podkladů, příprava schůzky). Pro role na projektu se udržuje seznam rolí, seznam orgánů, popis rolí a orgánů (poslání, předpoklady, odpovědnosti a pravomoci, doplňkové role, vztah k týmu, smluvní zajištění role), okomentované přiřazení k etapám, krokům a činnostem, a přiřazení ke zdrojům. 2

3 Techniky musí mít jasnou strukturu, ta je určena nástroji, postupem, příkladem, v praxi, účelem, základními pojmy nebo notací. (Příklady technik: analýza kritických požadavků, řízení projektu, datové modelování, školení, návrh architektury systému, návrh klient, návrh GUI, testování, instalace, konverze dat.) Nástroje musí mít následující informace název, verzi, způsob instalace, podporu a licenční podmínky. 1.7 Metriky pro popis projektu Vždy používat více metrik. Pravděpodobnost optimistického odhadu je menší než pesimistického odhadu. Ganttův diagram Metoda kritické cesty Function points analysis (FPA) pro celkové charakteristiky projektu se zjišťuje počet funkčních bodů (získaných koeficientem obtížnosti řešení v daných oblastech) Weighted average (WAVE) vážený průměr optimistického (BC), realistického (ML) a pesimistického (WC) odhadu pracnosti (trvání) každé činnosti na zvolené úrovni výsledek se pak počítá (BC+4ML+WC)/6 Analýza dle objektů (Object based) výpočet pracnosti dle odhadu počtu a statistiky průměrné pracnosti konkrétních prováděných prací (kroků a úkolů méně než činnost) (pracnost = počet objektů daného typu * průměrná pracnost potřebná k vytvoření jednoho objektu) Konsensus 1.8 Způsoby vedení (řídící styly) a motivování lidí 3

4 Pro motivaci může manažer použít peníze, pochvalu, sounáležitost, seberealizaci nebo stres. 1.9 Role lidí v týmu a psychologie osobnosti Týmové role rozdělujeme na profesní (znalosti, dovednosti, pravomoci, odpovědnosti) a sociální (vlastnosti, chování). Struktura osobnosti rozlišuje části kritické rodičovské já, ochranitelské rodičovské já, dospělé já, přirozené dětské já a přizpůsobivé dětské já. V týmu by každý měl mít povědomí o své roli, každý člověk může mít více rolí. V týmu by neměly dlouhodobě žádné role chybět. Další rozdělení rolí v týmu je na: inovátora, vyhledávače zdrojů, koordinátora, usměrňovače, monitora vyhodnocovače, týmového pracovníka, realizátora, kompletovače finišera a specialistu Projektová dokumentace projektu Důležité produktu projektového řízení jsou: Smlouva, Základní dokument projektu, Plán projektu, 4

5 Plán alokace zdrojů, Rozpočet projektu, Deník projektu, Report o stavu projektu, Evidence pracnosti, Předávací protokol, Akceptační protokol, Statistika projektu. Základní dokument projektu navazuje a rozpracovává Smlouvu, definuje výstupy, rozsah, kritéria úspěchu, rizika, rozpočet a způsob řízení. Schvaluje ho nejvyšší orgán projektu. Základní dokument projektu musí obsahovat cíle (kritéria pro smluvní plnění), přínosy (často jen orientační kritéria, lépe se kvantifikují jak cíle) a rozsah (předmět plnění, rozsah projektu). Předpoklady realizace projektu jsou kritické faktory úspěchu (vnitřní faktor, cokoliv, co když není dosaženo, může vážně ohrozit dosažení cílů), kritické předpoklady (vnější faktor) a rizika. Hlavní zásada pro psaní základního dokumentu projektu je psát jen to, co dokážeme a chceme zrealizovat. K projektu můžeme psát deník projektu, to je zaznamenání (paměť) všech důležitých událostí, které se na projektu staly nebo naopak nestaly. Slouží pro účely předávání řízení a pro spory. 5

6 2. Postup tvorby softwaru Iterativní vývoj je takový vývoj, kde jedna rostoucí aplikace má vyvinuté jádro a to se stále při iteracích používá. Typické pro agilní vývoj. Inkrementální vývoj je o připojováním různorodých aplikací většinou pomocí výměny zpráv nebo přes middleware. 2.1 Tradiční metodiky vývoje Životní cykly (předchůdci metodik) Stagewise model (posloupnost fází) Vodopádový model přímočarý sled fází projektu definice problému, analýza a specifikace požadavků, návrh a vytvoření architektury, implementace, integrace a testování, provoz a údržba jednoduchý (i na řízení), ale nepružný; vhodný pro malé projekty Spirálový model opakované vodopády s analýzou rizik (klíčové pojmy rizika, prototyp, plánování, iterativní vývoj) jeden cyklus se dělí na stanovení cílů, analýza rizik, realizace, plánování přizpůsobitelné, včas vylučuje nevhodné řešení, ale nelze zasahovat do cyklu; vhodný pro rozsáhlé a rizikové projekty Metodiky RUP (Rational Unified Process) nepopisuje jen životní cyklus aplikace a vývojové kroky, ale podrobně předepisuje proč, kdo, kdy a co se má v daném okamžiku udělat EUP (Enterprise Unified Process) 2.2 Agilní metodiky vývoje Příklady agilních metodik: DSDM (Dynamic Systems Development Method) ASD (Adaptive Software Development) FDD (Feature Driven Development) XP (Extreme Programming) zadání se rychle mění, nebo není jasné, pro týmy 2 10 programátorů; aktivity programování, testování, naslouchání a design Lean development Scrum rozděluje role na pigs (přímo souvisí s vývojem aplikace product owner a scrum master) a Dickens (uživatelé, stakeholders a manažeři), proces rozdělen do 2-4 týdenních sprintů (výsledkem každého je fungující software) Crystal metodiky Agilní modelování 2.3 Kritéria volby a identifikace vhodné metodiky Kritéria pro členění metodik jsou: Zaměření metodiky (globální nebo projektové), Rozsah metodiky (fáze a dimenze), 6

7 Váha metodiky (součin velikosti počtu kontrolních prvků, a hustoty metodiky míru podrobnosti), Typ řešení (nové, integrace, upgrade, customizace, užití), Doména. 7

8 3. Metriky 3.1 Podstata volby a zavedení vhodné metriky Metrika je vhodný nástroj pro podporu dosažení stanovených cílů, vyjasňuje vágní vize a cíle. Ukazatel je metrika nebo kombinace metrik, které poskytují náhled na softwarový projekt, proces nebo produkt. 3.2 Nejčastější metriky využité při vývoji softwaru BSC (Balanced Scorecard) rozděluje cíle a metriky do čtyř pohledů finanční, zákaznické, interních procesů a učení a růstu Business Readiness Scorecard připravenost podniku ke změně (metriky připravenosti, indikátory a hodnocení, zdroje informací, porovnání v čase) 3.3 Metriky členěné podle typu nasazení, podniku, druhu vývoje Metriky základně členíme na tvrdé (objektivně měřitelné) a měkké (subjektivní hodnocení uživateli).??? Metriky členěné podle typu nasazení Metriky členěné podle typu podniku Měření podle organizace měří přínosy a náklady podle úrovně řízení nebo podle organizační struktury. Jedná se o doplňkový pohled, není vhodný jako primární.??? Metriky členěné podle druhu vývoje 8

9 4. Metodika UP 4.1 Podstata metodiky Podstata Metodika je ucelený systém metod, technik, nástrojů a filosofického zdůvodnění KDO, CO, KDE, JAK a PROČ má udělat, aby se vytvořil software, který komputerizuje požadavky zákazníka na aktivity a zpracování dat v zadané problémové doméně. V případě metodiky UP se jedná o metodiku, která řídí vývojářskou práci výlučně případy užití a projektovým rizikem. Pozornost vývoje soustředí na architekturu cílového software, model životního cyklu je iterativní a přírůstkový (inkrementální). Jednotlivé fáze se popisují jazykem UML Základní pojmy (5 základních pracovních postupů, fáze, iterace) Projekt se dělí na fáze, ta na iterace, při každé iteraci se provádí pět základních pracovních postupů (workflows): Požadavky vznikají specifikace požadavků zákazníka, Analýza vyhodnocení požadavků a jejich přerod do funkcionality, Návrh odraz požadavků v architektuře softwarového systému, Implementace uskutečnění tvorby software, Testování verifikace toho, zda funguje implementace tak, jak požaduje zákazník. Plánovací body každé fáze jsou souhrnné cíle, primární zaměření a milník. 4.2 Zahájení, rozpracování, konstrukce, zavedení Fáze zahájení Startovací fáze metodiky, stanovují se podmínky proveditelnosti, nadnese se obchodní případ (obchodní přínos), zachycují se podstatné požadavky (rozsah vznikajícího systému) a označují se kritická rizika. V této fázi je nejvíc práce pro manažera projektu (informačního manažera žádající organizace), spolupodílí se systémový projektant. Na analýze požadavků se podílí zákazník sám, budoucí uživatelé nebo testeři. 9

10 Ve fázi dominují postupy zabývající se specifikací požadavků a jejich analýzou (důraz i na návrhářské a implementační práce), hlavní je stanovit celkový model životního cyklu vývoje software. Milníkem fáze je předmět životního cyklu a rozsah softwarového systému (Life Cycle Objectives) Fáze rozpracování Rozpracování se zaměřuje na tvorbu spustitelného architektonického základu, vylepšení odhadu rizik, definice atributů kvality, zachycení případů užití pro většinu funkčních požadavků, tvorbu přesného plánu konstrukce a formulace nabídky (výpočet potřebných prostředků, času, vybavení, personálu a náklad). Hlavní pracovníci fáze jsou zadavatelé, analytici a programátoři. U požadavků se zaměřujeme na upřesnění rozsahu systému a požadavků na něj kladených. U analýzy upřesňujeme to, co budeme tvořit. U návrhu tvoříme logickou architekturu softwaru. U implementace tvoříme spustitelný architektonický základ. U testování zkoušíme daný spustitelný základ. Hlavní v této fázi jsou workflows požadavky, analýza a návrh Fáze konstrukce V této fázi vzniká nutnost splnit všechny požadavky analýzy a návrhu, a ze spustitelného základu vytvořit cílový software se zachováním integrity navržené architektury. Hlavním procesem je implementace, u testování se realizují dílčí i integrační testy. Hlavními pracovníky fáze jsou analytici a programátoři. U požadavků se zaměřujeme na odhalení všech požadavků zadavatele. U analýzy se snažíme dokončit analytický model (statický a dynamický). U návrhu se snažíme dokončit model návrhu a prověřit zachování integrity architektury. U implementace zajišťujeme počáteční provozní způsobilost (počáteční funkční variantu). U testování testujeme tuto variantu. Milníkem této fáze je připravení počáteční funkční varianty systému pro testování na počítačích zadavatele Fáze zavedení V této fázi se opravují všechny chyby v otestované verzi software (beta) a dochází ke skutečnému přenesení software na všechny počítače zadavatele. Také se tvoří uživatelské manuály a probíhají konzultace se zadavatelem a současně s prvním uživatelem. Hlavními pracovníky jsou testeři, dále projektový manažer, systémový integrátor, analytici a programátoři. Hlavní kroky workflow jsou implementace (přizpůsobení software pracovišti, oprava chyb) a testování (beta a přejímací testy). Pokud je nutné se vrátit k analýze (pro úpravy návrhu), projekt byl špatně navržen. Milníkem fáze je nasazení uvolnění softwarového produktu (product release). To vyžaduje ukončení beta testů, přejímacích testů a opravy případných chyb. Takový produkt je přijat do užívání. 10

11 4.3 Role pracovníků v projektu - Manažer projektu Fáze zahájení - Systémový projektant - Zákazník, budoucí uživatel, tester - Zadavatel Fáze rozpracování - Analytik - Programátor - Analytik Fáze konstrukce - Programátor - Projektový manažer - Systémový integrátor Fáze zavedení - Analytik - Programátor - Tester 4.4 Milníky Fáze zahájení Fáze rozpracování Fáze konstrukce Fáze zavedení Předmět životního cyklu a rozsah softwarového systému Architektura životního cyklu Funkční varianta softwarového systému (počáteční provozní způsobilost) Product release (uvolnění softwarového produktu a nasazení) 4.5 Souhrnné cíle Primární zaměření - Specifikace požadavků a jejich analýza - Návrhářské a implementační práce Fáze zahájení - Kontextová analýza - Stanovení modelu životního cyklu - Požadavky upřesnění rozsahu systému - Analýza upřesnění toho, co budeme tvořit - Návrh tvorba logické architektury SW Fáze rozpracování - Implementace tvorba spustitelného architektonického základu - Testování testování korektnosti základu - Požadavky odhalit všechny požadavky zadavatele - Analýza dokončit analytický model - Návrh dokončit model návrhu a prověřit zachování integrity architektury Fáze konstrukce - Implementace zajistit počáteční funkční variantu - Testování testovat počáteční funkční variantu - Úprava návrhu (jsou-li odhaleny chyby v návrhu) - Implementace přizpůsobení SW pracovišti, oprava Fáze zavedení chyb nenalezených při testování - Testování beta testy, přejímací testy 11

12 4.5.2 Metriky jednotlivých fází Fáze zahájení Fáze rozpracování Fáze konstrukce Fáze zavedení 12

13 5. Návrhové vzory Návrhový vzor je obecné řešení problému, které se využívá při návrhu programů. Není to knihovna nebo část zdrojového kódu, která by se přímo dala vložit do programu. 5.1 Typy návrhových vzorů - Creational Patterns (vytvářející návrhové vzory) popsat postup výběru třídy nového objektu a zajištění správného počtu objektů (př. factory method, Abstract factory method, builder prototype, singleton) - Structural Patterns (strukturální návrhové vzory) uspořádání tříd nebo komponent v systému, snahou je zpřehlednit kód (př. adapter, bridge, composite, decorator, facade, flyweight, proxy) - Behavioral Patterns (návrhové vzory chování) chování systému (např. chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor) Alternativní dělení podle úkolu: - Implementační - Řízení počtu instancí - Zapouzdření - Optimalizace rozhraní - Tvorba složitých objektů - Zpřehlednění (zjednodušení) kódu - Jak přizpůsobit svoje třídy jiným 5.2 Rozdíly mezi návrhovými vzory??? 5.3 Nasazení návrhových vzorů Immutable object je takový objekt, u kterého není možné měnit jeho stav Simple Factory Method Jednoduchá (statická) tovární metoda. Ta definuje statickou metodu nahrazující konstruktor. Používá se všude tam, kde potřebujeme získat odkaz na objekt, ale přímé používání konstruktoru není z nejrůznějších důvodů optimálním řešením Crate / Messenger / Přeprava Návrhový vzor pro sloučení několika samostatných informací do jednoho objektu, jehož prostřednictvím je pak možné tyto informace jednoduše ukládat nebo přenášet mezi metodami Servant Služebník je třída, jejichž instance poskytuje metody, které mohou tuto činnost vykonávat, přičemž objekty, pro které tuto činnost vykonávají, přebírají jako parametry. 13

14 5.3.4 Null Object Formálně plnohodnotný objekt, který použijeme v situaci, kdy by nám použití prádzného ukazatele přinášelo nějaké problémy Proxy Návrhový vzor pro zajištění kontroly nad přístupem k jinému projektu rozdělujeme virtual, remote, protective a smart proxy Command Návrhový vzor o zabalení metody do objektu, takže s ní pak lze pracovat jako s běžným objektem. To umožňuje dynamickou výměnu požadovaných metod za běhu programu a optimalizaci přizpůsobení programu požadavkům uživatele Iterator Řeší problém, jak se pohybovat mezi prvky, které jsou sekvenčně uspořádány, bez znalosti implementace jednotlivých prvků posloupnosti. 14

15 5.3.8 State Řeší výrazný rozdíl mezi chováním objektů v různých stavech zavedením vnitřního stavu jako objektu reprezentovaného instancí některého ze stavových tříd. Změna stavu objektu se pak řeší záměnou objektu reprezentujícího stav Template method Definuje metodu obsahující kostru nějakého algoritmu. Ne všechny kroky tohoto algoritmu jsou však známé v době vzniku této šablony, jejich konkrétní implementaci definují až potomci Facade Řešení pro zjednodušení vstupního bodu do systému. 15

16 Adapter Návrhový vzor pro změnu rozhraní třídy Composite Řešení jak uspořádat jednoduché objekty a z nich složené kompozitní objekty. Snahou vzoru je, aby k oběma typům objektů bylo možné přistoupit jednotným způsobem Factory Method Deklaruje rozhraní s metodou pro získání objektu. Rozhodnutí o konkrétním typu vráceného objektu však ponechává na svých potomcích, tj. na překrytých verzích deklarované metody. 16

17 Prototype Návrhový vzor určuje, jak vytvořit kopii existujícího objektu místo vytváření nové třídy Builder Řeší problém, jak oddělit vytváření složitých objektů od jejich prezentace, aby stejný proces konstrukce mohl mít za výsledek rozdílný způsob prezentace Abstract Factory Řeší problém, jak vytvořit na základě rozhodnutí v běhu programu instanci třídy, která dále vytváří instanci souvisejících nebo závislých tříd Decorator Přidává další funkcionalitu k objektu tak, že objekt zabalí do jiného objektu, který má na starosti pouze přidanou funkcionalitu, a zbytek požadavků deleguje na zabalený objekt. Tím umožňuje přidávat funkčnost dynamicky a zavádí flexibilní alternativu k dědění Chain of Responsibility Existuje několik instancí různých tříd, které mohou potenciálně zpracovat požadavek. Klient jej odesílá bez přesného určení konkrétní instance třídy musí implementovat stejné rozhraní Observer Definování závislosti jednoho objektu k více objektům. Umožňuje šířit událost, která nastala v jednom objektu, ke všem závislým objektům Mediator Určuje jakým způsobem zajistit komunikaci mezi dvěma komponentami programu, aniž by byly v přímé interakci a tím musely přesně znát poskytované metody Bridge Bridge představuje problém oddělení rozhraní třídy od její vlastní implementace, aby obě tyto části mohly být vytvářeny nezávisle na sobě. Tento princip zajístí, že může být změněna implementace třídy bez toho, abychom měnili kód klienta Strategy Definuje množinu vyměnitelných objektů (algoritmů) řešící zadanou úlohu a umožňuje mezi nimi dynamicky přepínat. 17