Přednáška Softwarové inženýrství v podání <Jan%20Pavelka>.

Ž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 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 :-)

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%20projektového%20záměru>

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%20a%20validace> **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%20a%20validace> **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%20a%20vysvětlit%20osnovu%20plánu%20jakosti%20podle%20normy%20IEEE%20730>

**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%20chart

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

  • 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%20Zealand. Asi. *wikipedia:Function%20points

*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:

  1. Identifikovanie konfiguračnej položky, jej vytvorenie a pridanie do databáze konfiguračných položiek

  2. Používanie konfiguračnej položky

  3. Potreba zmeniť konfiguráciu

  4. Vykonanie zmien na danej položke

  5. 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!)

  6. 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%20principy%20evidování%20a%20řízení%20problémů%20a%20změnových%20požadavků>

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 *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%20diagram: 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%20Engineering%20Institute při wen:Carnegie%20Mellon%20University) *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.

*zadržení neboli retence (skousnu to)

*zadržení *redukce (snažím se riziko snížit)| || *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 (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%23Gluttony - 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%23Envy%20and%20Wrath - 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%23Greed - 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%23Sloth (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%23Pride - 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. *