Přednáška [[Softwarové inženýrství]] v podání [[Jan Pavelka|J.Pavelky]].
* [ftp://barbora.ms.mff.cuni.cz//usr/vyuka/pavelka/swi/ Materiály ke zkoušce]
== Životný cyklus SW ==
=== Procesy životního cyklu ===
: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, ztráta 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.
''
