|
|
| Řádka 1: |
Řádka 1: |
| − | {{predmet|Softwarové inženýrství|Jan Pavelka|SWI026}} | + | {{predmet|Softwarové inženýrství|Tomáš Smolík|SWI026}} |
| − | :Materiály ke zkoušce: ftp://barbora.ms.mff.cuni.cz//usr/vyuka/pavelka/swi/
| + | |
| | | | |
| | + | Přednáška o softwerovém inženýrství. Obvykle přednášel [[Jan Pavelka]]. |
| | + | V roce 2007 přednášel [[Tomáš Smolík]]. |
| | | | |
| − | | + | ; Obsah přednášky Jana Pavelky : [[SWI026 Pavelka]] |
| − | == Životný cyklus SW ==
| + | ; Materiály ke zkoušce Jana Pavelky : ftp://barbora.ms.mff.cuni.cz//usr/vyuka/pavelka/swi/ |
| − | === Procesy životního cyklu ===
| + | ; Materiály k přednášce Tomáše Smolíka : http://academy.profinit.cz/courses/SWI026/ |
| − | :Q: '''Umět vyjmenovat procesy životního cyklu software.'''
| + | |
| − | ====Proces životního cyklu, tak jak ho známe ====
| + | |
| − | *1-nápad
| + | |
| − | *2-neformální specifikace
| + | |
| − | *3-formální specifikace (analýza)
| + | |
| − | *4-dekompozice (návrh)
| + | |
| − | *5-řešení komponent
| + | |
| − | *6-implementace komponent
| + | |
| − | *7-testovaní komponent
| + | |
| − | *8-integrace komponent do celku
| + | |
| − | *9-testování celku
| + | |
| − | *10-instalace
| + | |
| − | *11-provoz a údržba
| + | |
| − | v zkratce: požadavky -> formální specifikáce -> návrh -> kódovaní -> testovaní -> používaní
| + | |
| − | | + | |
| − | ====Proces životního cyklu podle normy ISO/IEC 12207====
| + | |
| − | *Primární procesy
| + | |
| − | **Smluvní pohled: proces pořízení, proces dodávky
| + | |
| − | **Inženýrsky pohled: proces vývoje , proces údržby
| + | |
| − | **Provozní pohled: proces provozu
| + | |
| − | *Podpůrné procesy
| + | |
| − | **Dokumentace
| + | |
| − | **Konfigurační řízení
| + | |
| − | **Pohled jakosti: zajištění jakosti, verifikace, validace, kontrolní dny, audit
| + | |
| − | **Řešení problémů
| + | |
| − | *Organizační procesy
| + | |
| − | **Manažérsky pohled:proces řízení
| + | |
| − | **proces infrastruktury
| + | |
| − | **proces zdokonalování
| + | |
| − | **proces školení
| + | |
| − | Organizační procesy se používají pro vytvoření a implementaci základní struktury připravené navazujícími procesy životního cyklu a personálem a pro nepřetržité zdokonalování struktury a procesů.
| + | |
| − | | + | |
| − | === Modely životního cyklu SW ===
| + | |
| − | http://www.levela.com/software_life_cycles_swdoc.htm
| + | |
| − | | + | |
| − | Model popisuje vzájemné vztahy mezi jednotlivými fázemi vývoje.
| + | |
| − | | + | |
| − | *spiral model
| + | |
| − | *waterfall model
| + | |
| − | *(navíc) throwaway prototyping model
| + | |
| − | *(navíc) evolutionary prototyping model
| + | |
| − | *(navíc) incremental/iterative development
| + | |
| − | *(navíc) reusable software model
| + | |
| − | *(navíc) automated software synthesis
| + | |
| − | | + | |
| − | ==== Model vodopád ====
| + | |
| − | | + | |
| − | Vodopádový model –lineární, neodráží známou skutečnost potřeby “zpětných kroku” při tvorbě SW a nutnost dusledného prověřování výsledku každé etapy
| + | |
| − | http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm
| + | |
| − | :http://www.csm.uwe.ac.uk/~prawling/waterfall.jpg
| + | |
| − | | + | |
| − | ==== V - životní cyklus (The V Life Cycle) ====
| + | |
| − | :Q: '''Nakreslit V-model životního cyklu podle ISO 12207 a vysvětlit obsah jednotlivých etap.'''
| + | |
| − | *na přednášce byl trochu jiný
| + | |
| − | Tento model vychází z konceptu potřeby neustálého testování, aby se dosáhla vysoká jakost software. Ukazuje nutnost plánovat testy současně se vznikem požadavků na ověřování jednotlivých kroku .
| + | |
| − | | + | |
| − | Velice stručný náhled na obrázku. Detaily v slajdech.
| + | |
| − | :http://www.uksh.com/images/sdlc_v_model.gif
| + | |
| − | | + | |
| − | ==== Spirálový model ====
| + | |
| − | :Q: '''Vysvětlit spirálový model.'''
| + | |
| − | | + | |
| − | ======Spirálový model, jak ho původně publikoval Barry Boehm======
| + | |
| − | :http://www.ics.uci.edu/~wscacchi/Software-Process/Images/Spiral-Model-Boehm-1987.gif
| + | |
| − | | + | |
| − | Jedu po spirále od středu, postupně mi roste cena.
| + | |
| − | *Charakterizace jednotlivých kvadrantů :
| + | |
| − | **4 kvadrant : určení cílu, alternativ vedoucích k dosažení cílů, omezení vyplývajíci z daných alternativ
| + | |
| − | **1 kvadrant : vyhodnocení jednotlivých variant a jejich analýza risku, zvolení varianty, prototyping
| + | |
| − | **2 kvadrant : simulace, testování, modely + ostatní části, které po spirále tvoří v podstatě model vodopád
| + | |
| − | **3 kvadrant : kvadrant plánování
| + | |
| − | **Důležité je, že po každém cyklu následuje fáze hodnocení a předložení dílčích výsledků komisi
| + | |
| − | | + | |
| − | *Postupnost kroku po spirále
| + | |
| − | ** záměr, celkový plán
| + | |
| − | ** požadavky, plán vývoje
| + | |
| − | ** návrh systému, jeho verifikace a validace, plán integrace
| + | |
| − | ** detailní plán, kódování, integrace, instalace
| + | |
| − | | + | |
| − | == Příprava a plánování ==
| + | |
| − | === Úrovně řízení ===
| + | |
| − | :Q: '''Umět vyjmenovat a charakterizovat úrovně řízení.'''
| + | |
| − | | + | |
| − | *Strategická úroveň (3 až 5 let - zkracuje se) - zajišťuje :
| + | |
| − | **strategie - svěřeno správní rade a vrcholovému managementu
| + | |
| − | **vrchol hierarchie řízení
| + | |
| − | **hlavní cíl podniku, dosažení zisku, zvýšení rentability a likvidity
| + | |
| − | **úkol: vytváření koncepce podnikání, další strategie rozvoje podniku, typy výrobků a poskytované služby v dlouhodobém horizontu
| + | |
| − | *Taktická úroveň (1 až 2 roky) - zajišťuje :
| + | |
| − | **analýza a plánování - štábní útvary
| + | |
| − | **monitorování a řízení - střední management
| + | |
| − | **úkol: prosazení strategie do praxe, snížení výrobních nákladů v komplexním pojetí celé výroby, co kdy a jak bude provedeno (nasazení nové techniky, velikost podniku, zavedení nové výroby apod.)
| + | |
| − | **výsledek taktického řízení: základní určení programu výroby
| + | |
| − | *Operativní úroveň (dny až týdny) zajišťuje :
| + | |
| − | **transakce - nižší management
| + | |
| − | **běžný provoz (výkonná úroveň) - operace - výkonní pracovníci
| + | |
| − | **úkol: nasazení existujícího výrobního systému tak, aby byl zajištěn hospodárný výkon
| + | |
| − | **svázána přímo s výrobou
| + | |
| − | **zodpovědnost: snížení mzdových a materiálových nákladů, plynulý bezporuchový chod strojů, plynulý a efektivní tok materiálu výrobou, údržba
| + | |
| − | **tvoří jádro vazby na dodavatele a odběratele podniku.
| + | |
| − | | + | |
| − | | + | |
| − | Popovídat o jednotlivých úrovní v těchto oblastech. Každá úroveň má specifické črty, které lze lehko odvodit z názvu úrovně a lidí, kteří v ní pracují
| + | |
| − | *obecná charakteristika - činnost; od vizionárské práce po ruční výrobu
| + | |
| − | *plánovací horizont - několik let až dny
| + | |
| − | *charakteristika informací a dat - přesnost dat, zdroje dat
| + | |
| − | *typ a objem zpracování - také existence špiček, spůsob spracovnání, požadavky na zdroje a automatizace
| + | |
| − | *prezentace informací - srozumitelnost, komu jsou určene a k jakému účelu
| + | |
| − | *software - jaký softvér je potřebný pro pracovníky na jednotlivých úrovních a odkud pochází
| + | |
| − | | + | |
| − | === Stakeholders ===
| + | |
| − | :Q: '''Vysvětlit pojem zájmové skupiny (stakeholder) a uvést příklady. ''' | + | |
| − | *stakeholders - lidé, kterí mají zájem na úspěchu organizace v uskutečnování jejích záměrů a podporují její perspektivní produkty a služby
| + | |
| − | *shareholders - opak
| + | |
| − | zájmové skupiny :
| + | |
| − | nejenom : investoři, dodávatelé, zákazníci, zaměstnanci
| + | |
| − | ale také : vláda, politické strany, obchodné organizace ...
| + | |
| − | | + | |
| − | [[wikipedia:Stakeholder_theory]] | + | |
| − | | + | |
| − | === Kritické faktory úspěchu - Critical success factor (CSF) ===
| + | |
| − | :Q: '''Vysvětlit, co jsou kritické faktory úspěchu; uvést jejich klasifikaci a příklad.'''
| + | |
| − | Kritický faktor úspěchu:
| + | |
| − | *vlastnost organizace nebo okolního prostředí, která má svou povahou takový dopad na úspěch obchodní činnosti, že její sledování je kritické pro úspěch v podnikání, resp. faktor ohrozujuci úspech podnikania
| + | |
| − | | + | |
| − | Klasifikace kritických faktorů úspěchu podle :
| + | |
| − | *možnosti ovlivnění:
| + | |
| − | **aktivní, které je možno přímo ovlivňovat
| + | |
| − | **pasivní, které nemohou být přímo ovlivněny, musí však být sledovány
| + | |
| − | *podle vztahu k organizaci:
| + | |
| − | **interní - vlastnosti organizace
| + | |
| − | **externí - vlastnosti okolí
| + | |
| − | | + | |
| − | | + | |
| − | *Příklady (Rockart, 1979)
| + | |
| − | **vývoj nových produktů
| + | |
| − | **dobrá distribuce
| + | |
| − | **účinná reklama pro potravinársky průmysl (effective advertising for the food processing industry)
| + | |
| − | | + | |
| − | http://informationr.net/ir/6-3/paper108.html
| + | |
| − | | + | |
| − | http://c2.com/cgi/wiki?CriticalSuccessFactor
| + | |
| − | | + | |
| − | === Strategické plánování ===
| + | |
| − | ''(optional)''
| + | |
| − | | + | |
| − | Skládá se z nasledujících činností:
| + | |
| − | * určení kontextu záběru strategie (čeho se týká, podmínky a metody vypracování)
| + | |
| − | * charakterizace současného stavu - jeho silných stránek a slabin, příležitostí a ohrožení (SWOT - Strenths, Weaknesses, Opportunities, Threats), tedy ([[wen:SWOT|SWOT]] tabulka)
| + | |
| − | | + | |
| − | * vymezení cílů pro strategii (popis možných cílů a kritéria výběru vhodné podmnožiny ze spektra alternativ)
| + | |
| − | * posouzení současného stavu jako východiska pro realizaci migračního plánu
| + | |
| − | | + | |
| − | * určení migračního plánu k dosáhnutí cílů (lepší suboptimálný než optimální a křehký)
| + | |
| − | | + | |
| − | === Cyklus strategického plánování ===
| + | |
| − | :Q: '''Vyjmenovat fáze cyklu strategického plánování IS/IT.'''
| + | |
| − | | + | |
| − | http://www.alignedstrategy.com/weblog/ProductStrategy.jpg
| + | |
| − | | + | |
| − | | + | |
| − | *'''0.'''sběr písemných podkladů, určení kontextu a šírky záběru
| + | |
| − | **IN: zpracováná revize a celková strategie
| + | |
| − | *'''1.''' identifikace informačních potřeb
| + | |
| − | **IN: zpracováná revize a celková strategie
| + | |
| − | **OUT: potřeby organizace
| + | |
| − | *'''2.''' návrh architektur a přehled strategických možností
| + | |
| − | **IN: současný stav IS/IT, existující/revidované strategické a taktické plány
| + | |
| − | **OUT: vize IS/IT, strategická řešení, projekty
| + | |
| − | *'''3.''' určení strategických řešení
| + | |
| − | *'''4.''' zpracováni a schválení realizačního plánu
| + | |
| − | **OUT: existující/revidované strategické a taktické plány
| + | |
| − | | + | |
| − | *řízení, monitorování a kontrola – běží paralelně s předchozími; podstupuje revize
| + | |
| − | **IN: OUTy z 1-tky a 2-jky
| + | |
| − | **OUT: zpracování a údržba celkové strategie -> START
| + | |
| − | | + | |
| − | :''(ale je potřeba se podívat na obrázek na slidu 2-16 :-)''
| + | |
| − | | + | |
| − | [http://www.blackerbyassoc.com/ptp.html GPRA Strategic Planning: Start Here How to Write a Plan-to-Plan]
| + | |
| − | | + | |
| − | === 1. fáze cyklu strategického plánování ===
| + | |
| − | Fáze 1 - identifikace informačních potřeb (IP)
| + | |
| − | :Q: '''Popsat cíle, postup a výsledky prvních dvou fází cyklu strategického plánování IS/IT.'''
| + | |
| − | | + | |
| − | *Cíle:
| + | |
| − | **Analyza strategického plánu z hlediska IS/IT, jeho danosti, omezení,neurčitosti ztěžující plánování
| + | |
| − | **Identifikovat informační potřeby pracovních činností
| + | |
| − | **Zpracovat první návrh kandidátů na projekty
| + | |
| − | *Postup:
| + | |
| − | **Seznámení s písemnými podklady, příprava na interview
| + | |
| − | **Provedení interview
| + | |
| − | **Analýza a validace poznatků
| + | |
| − | **Konsolidace závěrů a jejich schválení managementem
| + | |
| − | *Výsledky
| + | |
| − | **Formalizované záznamy výsledků interview
| + | |
| − | **Konsolidovaný přehled informačních potřeb
| + | |
| − | **První verze návrhů projektů
| + | |
| − | | + | |
| − | -príklady informačních potřeb : strategie, provoz ...
| + | |
| − | | + | |
| − | | + | |
| − | :Q: '''Vysvětlit obsah strukturovaného záznamu interview a konsolidovaného záznamu potřeb.'''
| + | |
| − | | + | |
| − | *Obsahem interview jsou tabulkové záznamy o činnostech, jejich cílech, kritických faktorech úspěchu, měřitelných kritériích, prioritě a informačních potřebách.
| + | |
| − | *Obsahem konsolidovaného záznamu potřeb je souhrn informačních potřeb z interview, kde ke každé potřebě mám :
| + | |
| − | **základní vlastnosti IP : reference, popis,
| + | |
| − | **zdroj: iniciály (cie ???) a lok. priorita (???)
| + | |
| − | **globální priorita /V|N|S/
| + | |
| − | **podmínky pro dosažení potenciálních přínosů
| + | |
| − | **pokrytí stávajícími systémy
| + | |
| − | | + | |
| − | | + | |
| − | :Q: '''Popsat strukturu matice informační nabídky a poptávky. ??? /-potřebné upřesniť/'''
| + | |
| − | | + | |
| − | *matice informační poptávky
| + | |
| − | **řádky – poptávky; / mozna je to poptávka jedné informační potřeby z interview/ (strategia)
| + | |
| − | **sloupce – nabídky; útvary, co něco nabízejí (marketing)
| + | |
| − | **buňka - poptávka danej IP od daného útvaru (analýza trhu)
| + | |
| − | | + | |
| − | === 2. fáze cyklu strategického plánování ===
| + | |
| − | Fáze 2 - Návrh architektur a určení strategických možností
| + | |
| − | :Q: '''Popsat cíle, postup a výsledky prvních dvou fází cyklu strategického plánování IS/IT.'''
| + | |
| − | | + | |
| − | | + | |
| − | *Cíle:
| + | |
| − | **Vyhodnotit, jak stávající IS naplňují potřeby informační podpory a jaký je výhled do budoucnosti
| + | |
| − | **Pro identifikované informační potřeby navrhnout ideální aplikační architekturu
| + | |
| − | **Navrhnout informační architekturu
| + | |
| − | **Identifikovat strategické možnosti naplnění informačních potřeb
| + | |
| − | **Rozpracovat obchodní případy (business case) pro pokrytí zjištěných potřeb
| + | |
| − | *Postup
| + | |
| − | **Zpracování přehledu stávajících aplikací (vč. vyhodnocení)
| + | |
| − | **Zpracování procesního modelu organizace
| + | |
| − | ***cíl : zjistit, jak to v organizaci chodí
| + | |
| − | **Vytvoření a analýza mapy aplikačního pokrytí (jak aplikace pokrývají procesy)
| + | |
| − | ***cíl : zjistit, jak jsou procesy pokryty aplikacemi
| + | |
| − | **Vytvoření informační architektury
| + | |
| − | ***cíl : zmapovat typy informací a vztahy mezi nimi
| + | |
| − | ***v podstatě vypracování globálního konceptuálního schématu
| + | |
| − | **Analýza vztahů aplikací a dat
| + | |
| − | ***cíl : namapovat aplikační architekturu na informační architekturu
| + | |
| − | **Identifikace a vyhodnocení strategických alternativ
| + | |
| − | ***cíl : vytýčit možnosti pokrytí zjištěných informačních potřeb
| + | |
| − | **Zapracování návrhů projektů do návrhu celkového plánu - Formulace projektových záměrů (co se tedy bude dělat)
| + | |
| − | *Výsledky
| + | |
| − | **Přehled stávajících aplikací s jejich hodnocením
| + | |
| − | **Procesní model, aplikační architektura, informační architektura
| + | |
| − | **Návrh plánu rozvoje IS/IT
| + | |
| − | | + | |
| − | | + | |
| − | :Q: '''Vysvětlit metodiku hodnocení stávajících aplikací.'''
| + | |
| − | | + | |
| − | Vytvořím tabulku hodnocení stávajících aplikací.
| + | |
| − | řádek tabulky :
| + | |
| − | *popisu aplikace : název, stav, datum uvedení do provozu, prostředí, uživ. rozhraní, poznámky
| + | |
| − | *hodnocení následujícich charakteristik hodnotami 0-5: spokojenost, provozní stabilita, výkon, spolehlivost/bezpečnost, možnost růstu
| + | |
| − | | + | |
| − | -příklad :
| + | |
| − | *popis: budík, v provozu, 1950, , dávkové, neimplementována minútová ručička
| + | |
| − | *hodnocení : spokojenost: 2, provozní stabilita: 2, výkon: 2, spolehlivost/bezpečnost: ??:), možnost růstu : 5
| + | |
| − | | + | |
| − | | + | |
| − | :Q: '''Popsat osnovu projektového záměru.'''
| + | |
| − | *hlavičky (typický obsah : název projektu, autor, posuzovatelé, schvalující orgán, datumy ...)
| + | |
| − | *stručná charakteristika projektu
| + | |
| − | *zdůvodnění existence
| + | |
| − | *užití dat
| + | |
| − | *předpokládáné objemy a zátěž
| + | |
| − | *procesní a informační vazby
| + | |
| − | *požadavky na (výkon|spolehlivost|bezpečnost|správu)
| + | |
| − | *alternativy realizace
| + | |
| − | *technologické požadavky
| + | |
| − | *vazby na jiné projekty
| + | |
| − | *požadavky na zdroje
| + | |
| − | *harmonogram
| + | |
| − | *shrnutí přínosů/nákladů
| + | |
| − | | + | |
| − | | + | |
| − | :Q: '''Umět v notaci podle vlastního výběru zakreslit konkrétní proces na základě slovního popisu.'''
| + | |
| − | *Proces: množina činností provázaných řídicími a informačními toky
| + | |
| − | -príklad : proces návrhu výťahu
| + | |
| − | *U každého procesu se identifikují : IN/OUT informace, IN/OUT řídicí události, činnosti a pracovní postupy,
| + | |
| − | role a jejich odpovědnosti a pravomoci, kontroly, zdroje (zejména informační)
| + | |
| − | *Vyjadřovací prostředky: Procesní mapy, DFD (Data Flow Diagrams), RAD (Role-Activity Diagrams)
| + | |
| − | | + | |
| − | === Osnova projektového záměru ===
| + | |
| − | :Q: '''Popsat osnovu projektového záměru.'''
| + | |
| − | *hlavičky (typický obsah : název projektu, autor, posuzovatelé, schvalující orgán, datumy ...)
| + | |
| − | *stručná charakteristika projektu
| + | |
| − | *zdůvodnění existence
| + | |
| − | *užití dat
| + | |
| − | *předpokládáné objemy a zátěž
| + | |
| − | *procesní a informační vazby
| + | |
| − | *požadavky na (výkon|spolehlivost|bezpečnost|správu)
| + | |
| − | *alternativy realizace
| + | |
| − | *technologické požadavky
| + | |
| − | *vazby na jiné projekty
| + | |
| − | *požadavky na zdroje
| + | |
| − | *harmonogram
| + | |
| − | *shrnutí přínosů/nákladů
| + | |
| − | | + | |
| − | == Smluvní pohled ==
| + | |
| − | === Proces pořízení neboli akvizice ===
| + | |
| − | Definuje činnost nabyvatele (objednatele) – toho, kdo si softvér nebo službu pořizuje.
| + | |
| − | | + | |
| − | :Q:''' Vyjmenovat činnosti procesu pořízení (akvizice).'''
| + | |
| − | | + | |
| − | *zahájení akvizice
| + | |
| − | *příprava poptávkového dokumentu
| + | |
| − | *příprava a aktualizace smlouvy
| + | |
| − | *dohled nad dodávkami (zajištění jakosti)
| + | |
| − | *přejímka a ukončení projektu
| + | |
| − | | + | |
| − | === Popsat a vysvětlit osnovu projektového záměru ===
| + | |
| − | [[#Osnova projektového záměru|viz výše]]
| + | |
| − | | + | |
| − | === Akviziční plán ===
| + | |
| − | :Q: '''Vysvětlit jednotlivé body akvizičního plánu.'''
| + | |
| − | | + | |
| − | Osnova
| + | |
| − | *požadavky na systém
| + | |
| − | *zamýšlený způsob nasazení (rozsah, dopad na procesy, pilotní zóny)
| + | |
| − | *typ použité smlouvy (např smlouva o dílo)
| + | |
| − | *odpovědnost zúčastněných organizací
| + | |
| − | *způsob podpory
| + | |
| − | *identifikace rizik a jejich řešení
| + | |
| − | | + | |
| − | === Popsat způsob výběru dodavatele a osnovu zadávací dokumentace ===
| + | |
| − | Způsob výběru
| + | |
| − | *veřejná soutěž (někdy předepsáno zákonem)
| + | |
| − | *oslovení předem vybraných kandidátů
| + | |
| − | | + | |
| − | Zadávací dokumentace
| + | |
| − | *požadavky na systém (co to má být)
| + | |
| − | *technická omezení (kde to má běžet)
| + | |
| − | *rozsah funkcí (co od toho chceme)
| + | |
| − | *smluvní podmínky
| + | |
| − | *podmínky na subdodavatele (řešitel někdy zadává jednotlivé kusy dalším firmám, a my např. nechceme, aby byly z Libye a Íránu)
| + | |
| − | *závazná struktura nabídky
| + | |
| − | *instrukce pro podávání nabídek(jejich struktura, jak se mají podat, etc)
| + | |
| − | | + | |
| − | === Smlouva ===
| + | |
| − | :Q: '''Popsat osnovu smlouvy na zhotovení/nasazení informačního systému a vysvětlit jednotlivá ustanovení smlouvy.'''
| + | |
| − | | + | |
| − | *identifikace stran
| + | |
| − | *účel smlouvy
| + | |
| − | *přehled a místo plnění
| + | |
| − | *závazky zhotovitele
| + | |
| − | *závazky objednatele
| + | |
| − | *součinnost zhotovitele a objednatele
| + | |
| − | *způsob komunikace (co není popsáno zde, nemusí být bráno jako závazné)
| + | |
| − | *termíny
| + | |
| − | *cenové a platební podmínky
| + | |
| − | *ochrana a utajení informací
| + | |
| − | *duševní vlastnictví, práva třetích osob
| + | |
| − | *vady díla a jejich řešení
| + | |
| − | *odpovědnost za škodu
| + | |
| − | *řešení sporů
| + | |
| − | **statutární zástupci
| + | |
| − | **arbitráž prostřednictvím IEE
| + | |
| − | *přechodná a závěrečná ustanovení
| + | |
| − | | + | |
| − | === Vysvětlit způsob dohledu nad dodávkami ===
| + | |
| − | Nabyvatel bude dohlížet na činnosti dodavatele v souladu s 4 podpůrnymi procesy :
| + | |
| − | *1) společné kontroly - kontrolní dny
| + | |
| − | **Proces společné kontroly (kontrolní dny, oponentury) slouží k vyhodnocování stavu a produktů vybraných projektových činností.
| + | |
| − | **Seznam činností: Tento proces sestává z následujících činností:
| + | |
| − | ***Ustavení procesu kontrolních dní; /provedení procesu podle plánu, dohodnutí potřebných zdroju, nezainteresovanost kontroly, zaznamenání problemu../
| + | |
| − | ***Manažerské kontrolní dny : vyhodnotení stavu projektu vůči relevantním plánům, harmonogramům, normám a doporučením
| + | |
| − | ***Technické kontrolní dny : vyhodnocení uvažovaných softwarových produktů nebo služeb a doložení, že jsou úplne, vyhovují špecifkaci, harmonogramum, normám, plánum, konfiguračnímu řízení...
| + | |
| − | | + | |
| − | *2) proces auditu
| + | |
| − | **Proces auditu slouží ke zjištění souladu s relevantními požadavky, plány a smlouvami.
| + | |
| − | **Seznam činností: Tento proces sestává z následujících činností:
| + | |
| − | ***Ustavení procesu; /viď výše/
| + | |
| − | ***Audit - úkoly :
| + | |
| − | ****SW odpovída zdokumentovanému návrhu, svým specifikacím, byl otestován
| + | |
| − | ****testovací data jsou v souladu se specifikací, náklady a harmonogram odpovídají schváleným plánům ...
| + | |
| − | | + | |
| − | *3) [[#Verifikace a validace|verifikace]]
| + | |
| − | **Proces verifikace slouží ke zjištění, zda softwarové produkty určité činnosti splňují požadavky nebo podmínky, které na ne kladou předchozí činnosti.
| + | |
| − | *4) [[#Verifikace a validace|validace]]
| + | |
| − | **Validace slouží ke zjištění, zda požadavky a finální výsledek splňuje zamýšlený účel systému. Validaci je možno provést v raných etapách projektu.
| + | |
| − | | + | |
| − | | + | |
| − | *kontrolují se jak produkty, tak i procesy
| + | |
| − | *[[#Popsat a vysvětlit osnovu plánu jakosti podle normy IEEE 730|plán jakosti]]
| + | |
| − | **orgán, co má jakost zajišťovat
| + | |
| − | **závazné pracovní postupy
| + | |
| − | **struktura a evidence dokumentace
| + | |
| − | **kontrolní mechanismy
| + | |
| − | **postupy schvalování (mezi)produktů
| + | |
| − | **harmonogram kontrol
| + | |
| − | **řešení krizí
| + | |
| − | | + | |
| − | === Proces dodávky ===
| + | |
| − | Definuje činnost dodavatele.
| + | |
| − | | + | |
| − | *zahájení
| + | |
| − | *příprava nabídky
| + | |
| − | *příprava a aktualizace smlouvy
| + | |
| − | *realizace a řízení (zahrnuje oponentury, hodnocení, etc)
| + | |
| − | *dodávka a kompletace
| + | |
| − | ----
| + | |
| − | :Q: '''Popsat plán dodávky.'''
| + | |
| − | | + | |
| − | Plán dodávky zahrnuje
| + | |
| − | *organizační struktura projektu, pravomoci a odpovědnosti
| + | |
| − | *vývojové prostředí
| + | |
| − | *struktury rozkladu prací
| + | |
| − | *řízení jakosti produktů a služeb
| + | |
| − | *řízení bezpečnosti, důvěrnosti a jiných požadavků
| + | |
| − | *výběr subdodavatelů a řízení subdodávek
| + | |
| − | *součinnost nabyvatele a uživatelů
| + | |
| − | *řízení rizik
| + | |
| − | *bezpečnostní politika
| + | |
| − | *plánování termínů a hlášení stavu prací
| + | |
| − | *podpora a školení personálu
| + | |
| − | | + | |
| − | == Řízení projektu ==
| + | |
| − | === Definovat řízení, vyjmenovat a vysvětlit jeho pět základních funkcí ===
| + | |
| − | Řízení(Management ): tvorba a udržování prostředí, ve kterém jednotlivci pracují společně a účinně dosahují vytyčených cílů
| + | |
| − | | + | |
| − | Funkce řízení
| + | |
| − | *organizování (zřízení a udržování účelné struktury rolí a pravidel)
| + | |
| − | *personalistika (výběr lidí a jejich příprava)
| + | |
| − | *vedení (působení na lidi, aby dobře pracovali :)
| + | |
| − | *plánování (strukturování práce (procesy, činnosti, úkoly), její časové rozvrhování a přidělování zdrojů)
| + | |
| − | *kontrolování (sledování a měření termínů, kvality a spotřeby zdrojů)
| + | |
| − | | + | |
| − | === Definovat projekt ===
| + | |
| − | Projekt je jedinečné a jednorázové vynaložení práce, vyznačující se plánem a určeným začátkem a koncem. Projekt také má nějaké cíle a omezující podmínky.
| + | |
| − | | + | |
| − | === Nakreslit a vysvětlit typickou organizační strukturu projektu ===
| + | |
| − | Na vršku '''statutární zástupci''' obou organizací, pod nimi jádro – '''''řídící výbor''''' (napojený na '''orgán pro jakost'''), pod tím '''dva manažeři''' projektu (za dodavatele i objednatele) a pak '''realizační týmy''' (v nich zastoupeny taky obě strany, jsou dělené podle problémů nebo podle subsystémů) a případně '''specialisté'''
| + | |
| − | :*''pro ty s nedostatkem představivosti slajd 4-29''
| + | |
| − | | + | |
| − | === Vyjmenovat a vysvětlit náležitosti plánu projektu ===
| + | |
| − | *rekapitulace cílů (úvod)
| + | |
| − | *souhrn pro vedení (manažerský výcuc)
| + | |
| − | *pozadí (informační strategie organizace, že ten projekt je potřeba, apod.)
| + | |
| − | *účel, rozsah a cíle projektu
| + | |
| − | *rozklad prací a milníky
| + | |
| − | *organizace projektu
| + | |
| − | **organizační jednotky
| + | |
| − | **manažerská odpovědnost
| + | |
| − | **struktura projektového týmu
| + | |
| − | **zajištění zdrojů
| + | |
| − | **nominace klíčových lidí
| + | |
| − | *hrubý harmonogram a matice odpovědnosti
| + | |
| − | *systém řízení projektu
| + | |
| − | *rizika a předpoklady (+zavrhnutá řešení)
| + | |
| − | *rozpočet
| + | |
| − | *zdůvodnění projektu jako investice (náklady/přínosy)
| + | |
| − | | + | |
| − | === Vyjmenovat a vysvětlit povinnosti manažera projektu ===
| + | |
| − | *řídit realizaci plánu (aby to šlo podle cílů a kritérií)
| + | |
| − | *monitorovat realizaci projektu (hlášení dle smlouvy)
| + | |
| − | *identifikovat a řešit problémy
| + | |
| − | *hlásit stav prací, zajistit jeho hodnocení dle požadavků (míněny požadavky na výsledek)
| + | |
| − | *na konci shrnout hodnocení a vyjádřit se ke splnění cílů a plánů
| + | |
| − | | + | |
| − | === Metoda PERT a Ganttovy diagramy ===
| + | |
| − | :Q: '''Vysvětlit metodu PERT a Ganttovy diagramy; umět nakreslit diagram pro konkrétní příklad, umět spočítat kritické cesty.'''
| + | |
| − | *Obe metódy jsou pužívané pro podporu projektového řízení
| + | |
| − | *PERT (Evaluation and Review Technique): mám graf projektu, hrany jsou činnosti, uzly propojují činnosti !
| + | |
| − | | + | |
| − | **Alternativa: činnosti v uzlech
| + | |
| − | *** v uzle jsou záznamy (ES /early start/, EF /early finish/, LS /last start/, LF /last finish/, F /float/- rezerva, D - duration)
| + | |
| − | ***návaznosti znázornené šípkami
| + | |
| − | **kritická cesta: nesmí se zpozdit, jinak ohrozí celý projekt ''(Když dělám vepřové stehno, mám kritickou cestu: zabití prasete -> porcování prasete -> vaření stehna -- když se zpozdí zabití prasete, mám problém. Naproti tomu ochutnávka mozečku je mimo kritickou cestu, takže mi u ní zpoždění tolik nevadí.)''
| + | |
| − | **[[wikipedia:PERT]]
| + | |
| − | *Ganttovy (úsečkové) diagramy: takové ty čáry z MS Project (v Linuxu např. Imendio planner), smysl je podobný
| + | |
| − | ** řádky : task name
| + | |
| − | **sloupce : časové úseky
| + | |
| − | **provázanost medzi úkoly šípkami naznačujícimi vazby /predlevy, předstih ../
| + | |
| − | **[[wikipedia:Gantt chart]]
| + | |
| − | | + | |
| − | === Vyjmenovat typy metrik a vysvětlit jejich účel ===
| + | |
| − | *pro řízení (sledování a vyhodnocení již vykonané práce)
| + | |
| − | **spotřeba zdrojů (spotřeba kapacit, uplynulý čas, spotřeba dalších zdrojů (výpočetní kapacity atd.))
| + | |
| − | **plnění plánu (procento plnění etap např. zakódovaných modulů)
| + | |
| − | **kvalita – počty chyb (s ohledem na závažnost)
| + | |
| − | *pro predikci (cíl: odhadnout celkový objem práce na základě dat z časných etap)
| + | |
| − | Cíl: odhadnout koncový objem práce (např. řádky kódu) na základě dat zjištěných v časových etapách
| + | |
| − | **rozsah výsledku
| + | |
| − | **trvání etap i projektu celkově
| + | |
| − | **nasazování a spotřeba kapacit
| + | |
| − | | + | |
| − | === COCOMO ===
| + | |
| − | :Q: '''Vysvětlit model COCOMO.'''
| + | |
| − | | + | |
| − | * pointa: řádky vynásobím nějakými koeficienty podle náročnosti, a vyjde mi člověkočas
| + | |
| − | * [[wikipedia:COCOMO]]
| + | |
| − | * [http://www.softstarsystems.com/overview.htm COCOMO overview]
| + | |
| − | * malá kalkulčka pro obrazotvornost, 15 měřitelných faktorů a 3 typy týmů
| + | |
| − | **http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html
| + | |
| − | | + | |
| − | === Vysvětlit model funkčních bodů ===
| + | |
| − | *Nějakým mustrem (váženě se sčítají typy vstupů, výstupů, vnitřních reprezentací, a podobné věci) se určí velikost projektu ve funkčních bodech (univerzální jednotky pro velikost projektu). Dodavatelům pak stačí říct cenu za funkční bod, a objednatel si jednoduše může porovnat, jak jsou drazí.
| + | |
| − | *Používají to na [[wikipedia:New Zealand|Novém Zélandu]]. Asi.
| + | |
| − | *[[wikipedia:Function points]]
| + | |
| − | *ukážka výpočtu UFP na konrétním příkladu
| + | |
| − | **http://www.his.sunderland.ac.uk/~cs0mel/Alb_Example.doc
| + | |
| − | | + | |
| − | === Formulovat softwarovou rovnici a odvodit její důsledky ===
| + | |
| − | *objem díla = c * spotřeba kapacit<sup>p</sup> * doba vývoje<sup>q</sup>
| + | |
| − | **c ... nějaká technologická konstanta /volená s ohledem na zadání a použité zechnologie/
| + | |
| − | **p,q ... nějaké parametry /získané často empirciky/, dosazuje se třeba p=0,55; q=0,66
| + | |
| − | *důsledky :
| + | |
| − | **Teoreticky můžu jednu věc vždy dopočítat z dalších dvou.
| + | |
| − | **Odvození mnohých důležitých vztahu jako : možnosti zkracování termínů..
| + | |
| − | ***Odhady se liší. Podle jednoho z nich zkrácení času o 25% sežere víc než dvojnásobek zdrojů.
| + | |
| − | | + | |
| − | === Formulovat a vysvětlit Brookův zákon ===
| + | |
| − | Zvyšování kapacit pouze protahuje zpožděný projekt. /=> existují meze zkracování termínu/
| + | |
| − | | + | |
| − | Příčiny: komunikační režie, přínos jednotlivce klesá. Existuje optimální velikost projektového týmu. (Když je ale lidí opravdu málo, tak jejich přidání pomůže – zaškolování nových lidí může zpozdit projekt o tři měsíce, ale když jich nechám málo, protáhne se to třeba o půl roku.)
| + | |
| − | | + | |
| − | *Celková produktivita týmu Ltot(y) - závislost celkové produktivity na velikosti týmu je graf Ltot(y)
| + | |
| − | ** Ltot(y) = P* L(y)
| + | |
| − | *Průměrná individuální produktivita L(y)
| + | |
| − | ** L(y) = L – z(P – 1)<sup>y</sup>
| + | |
| − | *** y - 0 < y < 1 je míra komunikačního provázání týmu
| + | |
| − | *** z - ztráta produktivity na jedno komunikační spojení
| + | |
| − | *** L - průměrná individuální produktivita např. v KLOC
| + | |
| − | *** P - počet lidí v týmu
| + | |
| − | | + | |
| − | === Alokace zdrojů ===
| + | |
| − | :Q: '''Vysvětlit aplikace Rayleighova rozdělení na spotřebu kapacit v průběhu projektu.'''
| + | |
| − | Jakési diferenciální rovnice, vycházející z předpokladu, že produktivita práce roste lineárně s časem. (Což je sice ptákovina, ale ona přece jen roste – zkušenosti s projektem a tak – a lineární aproximace dává výsledky, které se docela blíží realitě.)
| + | |
| − | | + | |
| − | Ve výsledku vychází, že nejdřív je kapacit potřeba málo, pak to roste do maxima zhruba ve třetině, a následně plynule klesá ke konci.
| + | |
| − | | + | |
| − | == Konfigurační řízení ==
| + | |
| − | === Uvést definici konfigurační položky ===
| + | |
| − | Část vývojového prostředí nebo dodávky, která musí být samostatně identifikována, uchovávána, testována, měněna a udržována.
| + | |
| − | | + | |
| − | Test: záleží, jestli jsme to ztratili nebo blbě (resp. ve správné verzi) použili?
| + | |
| − | | + | |
| − | === Vysvětlit životní cyklus konfigurační položky ===
| + | |
| − | Středobodem životního cyklu je správce konfigurace. Od něj si vývojář může vyžádat rezervaci a zápůjčku. Když pak správce vývojáři položku zarezervuje a půjčí, vývojář si ji povyvine, otestuje a (i s testovacími protokoly) dá správci zpět.
| + | |
| − | | + | |
| − | Jednou za čas správce vytlačí novou globální verzi, kterou dostanou uživatelé a udělají z ní štůsky hlášení o problému, z nichž se pak dělají požadavky na změny.
| + | |
| − | | + | |
| − | ----
| + | |
| − | To, čo je napísané vyššie, je spôsob, ako predísť kolíziám pri zmene jednej verzie konfiguračnej položky viacerými subjektami (napr. vývojármi) nasadený na životný cyklus položky.
| + | |
| − | | + | |
| − | Ale cyklus samotný pozostáva približne z nasledujúcich krokov:
| + | |
| − | # Identifikovanie konfiguračnej položky, jej vytvorenie a pridanie do databáze konfiguračných položiek
| + | |
| − | # Používanie konfiguračnej položky
| + | |
| − | # Potreba zmeniť konfiguráciu
| + | |
| − | # Vykonanie zmien na danej položke
| + | |
| − | # Uloženie novej verzie položky do databáze konfiguračných položiek (povôdná verzia pritom ostáva v databáze a nemení sa!)
| + | |
| − | # Späť na krok 2.
| + | |
| − | | + | |
| − | === Vysvětlit principy evidování a řízení problémů a změnových požadavků ===
| + | |
| − | Evidenci hlášení problémů (chyb, poruch, neshod, etc) a změnových požadavků je výhodné sloučit, protože mají podobný průběh a dopady na postup v projektu. (Hlášení problému implikuje požadavek na změnu -- minimálně na jeho odstranění. Navíc z hlášení problému se často vyklube čistokrevný požadavek na změnu nebo může být charakter požadavku dokonce předmětem sporu -- např. při nepřesné specifikaci.)
| + | |
| − | | + | |
| − | == Podpůrné procesy ==
| + | |
| − | === Popsat a vysvětlit osnovu plánu jakosti podle normy IEEE 730 ===
| + | |
| − | *účel (jakost čeho chceme zajistit)
| + | |
| − | *odkazy (související dokumenty)
| + | |
| − | *řízení (lidé a jejich odpovědnost)
| + | |
| − | *dokumentace projektu (jaké dokumenty, formát, obsah, jak se hodnotí jejich jakost); '''minimálně''' následující:
| + | |
| − | **specifikace požadavků
| + | |
| − | **popis návhu
| + | |
| − | **plán testů
| + | |
| − | **protokoly o testech
| + | |
| − | **uživ. dokumentace
| + | |
| − | *standardy projektu
| + | |
| − | *postupy kontroly jakosti (jak to bude kotrolováno, verifikační a validační aktivity)
| + | |
| − | *konfigurační řízení
| + | |
| − | *dokumentování a řešení problémů (jak hlásit, přidělování řešitelům, sledování průběhu, odpovědnost)
| + | |
| − | *nástroje, techniky a metodologie (ladicí a testovací techniky a prostředky)
| + | |
| − | *změnové řízení
| + | |
| − | *správa médií (achivace, ochrana)
| + | |
| − | *řízení subdodavatelů (jak zajistit kvalitu jejich práce)
| + | |
| − | *dokumentace zajištění jakosti (archivace dokumentů okolo toho)
| + | |
| − | | + | |
| − | === Vyjmenovat a vysvětlit typické dokumenty vznikající v průběhu projektu ===
| + | |
| − | *smlouvy (i s přílohami a dodatky)
| + | |
| − | *plány (včetně harmonogramů)
| + | |
| − | *zpráva o analýze požadavků
| + | |
| − | *specifikace a validační plán
| + | |
| − | *předběžný návrh a integrační plán
| + | |
| − | *detailní návrh a plány ladění
| + | |
| − | *identifikační listy kódu a poznámky o jejich testech
| + | |
| − | *integrační, validační a přejímací protokoly
| + | |
| − | *zápisy z jednání
| + | |
| − | *hlášení o problémech
| + | |
| − | *dokumentace
| + | |
| − | | + | |
| − | === Vyjmenovat a vysvětlit typy a úrovně testů ===
| + | |
| − | *funkční
| + | |
| − | **shoda se specifikací
| + | |
| − | **ekvivalence konvertovaných dat se zdroji
| + | |
| − | **rozhraní
| + | |
| − | **výstupy
| + | |
| − | **reakce na chybové a okrajové situace
| + | |
| − | **provozuschopnost (přiměřenost dokumentace, schopnosti uživatelů s tím pracovat)
| + | |
| − | *strukturální
| + | |
| − | **výkonové (odezvy, průchodnost dávek)
| + | |
| − | **zátěžové (reakce na extrémní zátěž)
| + | |
| − | **bezpečnostní (interní i externí hrozby)
| + | |
| − | **zotavení
| + | |
| − | *aplikační (testují se jednotlivé aplikace)
| + | |
| − | *integrační (spolupráce aplikací)
| + | |
| − | *systémové (strukturální testy, které doteď neměly smysl např. kvůli chybám)
| + | |
| − | *akceptační (před přejímkou do provozu)
| + | |
| − | | + | |
| − | === Podrobnost (míra pokrytí) testování ===
| + | |
| − | :Q: Umět uplatnit různá kritéria pokrytí na příklady jednoduchých algoritmů a testovacích množin.
| + | |
| − | | + | |
| − | *pokrytí příkazů
| + | |
| − | **Množina testovacích případů T splňuje kritérium pokrytí příkazů programu P, jestliže pro každý příkaz p programu existuje případ t z T takový, že při spuštění programu P se vstupem t bude proveden příkaz p.
| + | |
| − | *pokrytí hran
| + | |
| − | **Množina testovacích případů T splňuje kritérium pokrytí hran pro program P, jestliže pro každou hranu h grafu programu P existuje případ t z T takový, že při spuštění programu P se vstupem t projde výpočet hranou h.
| + | |
| − | *pokrytí podmínek
| + | |
| − | **Množina testovacích případů T splňuje kritérium pokrytí podmínek pro program P, jestliže splňuje kritérium pokrytí hran a navíc pro každou složenou podmínku C a každou její komponentu K existují případy t1, t2 z T takové, že při provádění programu P se vstupem t1 se komponenta K vyhodnotí kladně a při provádění programu P se vstupem t2 se komponenta K vyhodnotí záporně.
| + | |
| − | *pokrytí cest
| + | |
| − | **Množina testovacích případů T splňuje kritérium pokrytí cest s omezením n pro program P, jestliže splňuje kritérium pokrytí podmínek a navíc pro každou cestu S v grafu programu P spojující vstupní a koncový uzel grafu a obsahující nejvýše n cyklů existuje testovací případ t Î T takový, že při provádění programu P se vstupem t1 projde výpočet cestou S.
| + | |
| − | :''(podrobnosti ;-) ve slajdech)''
| + | |
| − | | + | |
| − | === Vysvětlit principy evidování a řízení problémů a změnových požadavků ===
| + | |
| − | [[#Vysvětlit principy evidování a řízení problémů a změnových požadavků|viz výše]]
| + | |
| − | | + | |
| − | == Jakost ==
| + | |
| − | === Vyslovit definici jakosti a vysvětlit cyklus P-D-C-A ===
| + | |
| − | Jakost: souhrn znaků produktu/procesu/služby, které mají vliv na jeho schopnost splnit (i nevyslovená) očekávání.
| + | |
| − | | + | |
| − | [[wikipedia:PDCA|PDCA]]
| + | |
| − | *plan (rozmyslíme, co a jak budeme dělat)
| + | |
| − | *do (uděláme to)
| + | |
| − | *check (šlo to, jak jsme čekali?)
| + | |
| − | *act (zlepšeme se, ať se to příště povede)
| + | |
| − | | + | |
| − | === Sestavit Ishikawův diagram pro konkrétní problém ===
| + | |
| − | [[wikipedia:Fishbone diagram|„fishbone“]]: v kořeni je problém, z toho do více úrovní větvím možné příčiny
| + | |
| − | | + | |
| − | [[Image:Fishbone.png]]
| + | |
| − | | + | |
| − | === Vysvětlit rozdíl mezi managementem jakosti a zajištěním jakosti ===
| + | |
| − | *zajištění jakosti
| + | |
| − | **vztaženo k konkrétnímu projektu
| + | |
| − | *management jakosti
| + | |
| − | **systém plánování, koordinace uvnitř organizace, dlouhodobá věc
| + | |
| − | **zahrnuje i zajištění jakosti
| + | |
| − | | + | |
| − | === Vysvětlit (ne memorovat) články normy ISO 9001:2000 ===
| + | |
| − | odpovědnost vedení, pod tím řízení zdrojů, pak podpora podnikových procesů (s I/O vazbami na zákazníky), pod tím navázáno měření, analýzy a zlepšování
| + | |
| − | | + | |
| − | === Vysvětlit strukturu a filosofii [[wikipedia:CMMI|CMMI]]-SW ===
| + | |
| − | *specifický pro SW (byl ale úspěšně aplikován i na jiné oblasti)
| + | |
| − | *pět úrovní (ne jen certifikováno/necertifikováno, navíc každý má defaultně úroveň 1)
| + | |
| − | *copyrightované ([[wen:Software Engineering Institute|Software Engineering Institute]] při [[wen:Carnegie Mellon University|Carnegie Mellon University]])
| + | |
| − | *certifikace hodnotitelů
| + | |
| − | | + | |
| − | Z úrovní zralosti vyplývají generické cíle (a generické praktiky), pro různé procesní oblasti pak ještě specifické cíle a specifické praktiky. Je požadováno splnění cílů a existence praktik.
| + | |
| − | | + | |
| − | Kategorie generických cílů:
| + | |
| − | *angažovanost
| + | |
| − | *provozuschopnost
| + | |
| − | *usměrňování implementace
| + | |
| − | *prověřování implementace
| + | |
| − | | + | |
| − | === Vyjmenovat úrovně CMMI-SW a jejich klíčové procesní oblasti ===
| + | |
| − | #počáteční (chaos)
| + | |
| − | #řízená (správa požadavků, správa konfigurací, zajištění jakosti, řízení subdodávek, plánování a monitorování projektů)
| + | |
| − | #definovaná (koordinace mezi skupinami, integrované řízení projektů, program výcviku a školení, verifikace, validace, řízení rizik, definice procesů v organizaci, všichni účastníci mají potřebné znalosti a dovednosti)
| + | |
| − | #kvantitativně řízená (organizování účinnosti procesů, kvantitativní řízení procesů, iniciativa ke zlepšování na straně projektů)
| + | |
| − | #optimalizující (organizování inovace a zavádění změn, prevence defektů, iniciativa ke zlepšování na straně jednotlivců)
| + | |
| − | | + | |
| − | == Rizika ==
| + | |
| − | :Q: '''Vyslovit definice různých typů rizik.'''
| + | |
| − | '''Riziko''': možnosti vzniku ztráty či nezdaru (neurčitý výsledek, který může dopadnout špatně).
| + | |
| − | | + | |
| − | *čisté (negativní odchylka od cíle)
| + | |
| − | *spekulativní (může vzniknout ztráta, ale také zisk)
| + | |
| − | *investiční (vývoj hodnot aktiv)
| + | |
| − | | + | |
| − | === Co dělat s rizikem ===
| + | |
| − | :Q: '''Diskutovat možnosti řízení projektových rizik s ohledem na jejich pravděpodobnost a očekávaný dopad.'''
| + | |
| − | | + | |
| − | {| border="1" cellpadding="2"
| + | |
| − | |-
| + | |
| − | | || nízká pravděpodobnost || vysoká pravděpodobnost
| + | |
| − | |-
| + | |
| − | | nízká tvrdost (moc nebolí) ||
| + | |
| − | *[http://www.novinky.cz/04/59/55.html zadržení neboli retence] (skousnu to)
| + | |
| − | ||
| + | |
| − | *zadržení
| + | |
| − | *redukce (snažím se riziko snížit)
| + | |
| − | |-
| + | |
| − | | vysoká tvrdost (moc bolí) ||
| + | |
| − | *přesun (pojištění)
| + | |
| − | *krizové plány
| + | |
| − | ||
| + | |
| − | *redukce
| + | |
| − | *vyhnutí se (změnou zadání)
| + | |
| − | |}
| + | |
| − | | + | |
| − | = Další zajímavé a užitečné informace z přednášky =
| + | |
| − | == Terminologie ==
| + | |
| − | *[[wen:vaporware|'''vapourware''']] ''(výparovér)'' - zaplacený, ale nedodaný SW (napr. zrušen vývoj)
| + | |
| − | *'''shelfware''' ''(šuplíkovér)'' - zaplacený, dodaný, ale nepoužitý SW
| + | |
| − | | + | |
| − | == 7 smrtelných hříchů SW vývoje ==
| + | |
| − | * [[wen:Se7en#Gluttony|'''obžerství''']] - chtít, užívat a dělat víc než je potřeba
| + | |
| − | ** honba za vysokým počtem řádku, zbytečná funkcionalita a polykání výpočetní kapacity základním SW
| + | |
| − | * [[wen:Se7en#Envy and Wrath|'''závist''']] - bažit po něčem, co nemůžeme mít
| + | |
| − | ** velké očekávání od vývojových nástroju, které jsou však defektní v některém významném ohledu
| + | |
| − | * '''bláznovství''' (nedostatek soudnosti)
| + | |
| − | ** vkládaní přehnané důvěry do dílčich technik (OOP)
| + | |
| − | ** snaha vynálezt kolo (naprogramovat si všechno sám)
| + | |
| − | * [[wen:Se7en#Greed|'''lakomství''']] - neochota postkytnout jiným podíl na našem bohatství
| + | |
| − | ** vydíraní zákazníků licencemi, monopol, utajování rozhraní, nesdílení zkušeností
| + | |
| − | * [[wen:Se7en#Sloth|'''lenost''']] (pohodlnost)
| + | |
| − | ** neochota přemýšlet a konat včas, dodávaní zabugovaného SW zákazníkům, strata porozumění o fungování vlastního díla
| + | |
| − | * '''hazardérství''' - zanedbání rizik a varovních signálu, nepořádek v konfiguračním řízení
| + | |
| − | * [[wen:Se7en#Pride|'''pýcha''']] - důraz na vlastní důležitost, chybějící respekt k jiným (uživatelům)
| + | |
| − | | + | |
| − | == Verifikace a validace ==
| + | |
| − | '''Verifikace''' kontroluje konzistenci a správnost postupu, např. že je daný výstup zpracován '''správně''' – je v souladu se standardy, s právními a interními předpisy, s požadavky ve specifikaci atd.
| + | |
| − | | + | |
| − | '''Validace''' kontroluje faktickou správnost výsledku, např. zda je daný výstup '''správný''' – odpovídá skutečným požadavkům uživatelů a dalším relevantním skutečnostem.
| + | |
| − | | + | |
| − | ''Příklad: u konkrétní funkce programu může nastat libovolná kombinace toho, zda je nebo není v souladu s designem a zda je nebo není správně (tak, jak to opravdu chceme). Zatímco verifikace kontroluje konzistenci s designem, validace kontroluje, zda se funkce chová tak, jak skutečně chceme.
| + | |
| − | ''
| + | |
| − | | + | |
| | [[category:Informatika]] | | [[category:Informatika]] |
