Softwarové inženýrství: Porovnání verzí

Z ωικι.matfyz.cz
Přejít na: navigace, hledání
(Poznámky ke zkouškovým otázkam: tenhle nadpis tady takz nemusi byt)
(aktualizace)
 
Řá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 &ndash; 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 &lt; 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 &ndash; zkušenosti s projektem a tak &ndash; 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ě''' &ndash; 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ý''' &ndash; 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]]

Aktuální verze z 29. 5. 2007, 21:13

Softwarové inženýrství
Kód předmětu: NSWI026
Přednáší: Tomáš Smolík

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
Materiály ke zkoušce Jana Pavelky 
ftp://barbora.ms.mff.cuni.cz//usr/vyuka/pavelka/swi/
Materiály k přednášce Tomáše Smolíka 
http://academy.profinit.cz/courses/SWI026/