Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

FAV > ASWI > Flashcards

ASWI Flashcards

1
Q

Proč se zaobírat SW inženýrstvím? (motivace)

A

Studie 95:
15 % -> Success
55 % -> Challenge
30 % -> Failure

O 20 let později:
Failure stále kolem 10 %,
ale různé metodiky různé výsledky

+ dají se najít příklady, kdy selhání vývoje SW mělo fatální finanční důsledky

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Profesionalita a etika softwarového inženýra

A

Rozhodnutí SW. inženýra má dopady na fungování společnosti, tudíž by měl přijmout zodpovědnost za tato rozhodnutí. (profesionál vs. expert)

Př. bubliny na sociálních sítí zvyšují polarizace společnosti, vysoce návykové hry/webové stránky

Co s tím?
Learn: Studovat i věci mimo informatiku, filozofii etiku etc., poučení se z minulosti

Think: Zvažovat možnosti zneužití vyvíjeného SW

Act: Např. odejít z firmy, které se nechová eticky. Whistleblowing

Educate: Vzdělávat lidi i z jiných profesí

Connect: LinkedIn např.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Jak definovat úspěch softwarového projektu?

A
  1. pohled:
    1) On Schedule
    2) On Budget
    3) To Specification
  2. Pohled
    1) Plní potřeby skutečné potřeby stakeholderů
    2) Doručuje sw vysoké kvality se snadnou údržbou
    3) Poskytuje nejlepší ROI
    4) Doručuje když je projekt vhodný k předání

Čím dál více se posouvá vnímání úspěchu k 2. pohledu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Příčiny selhání SW projektu

A

1) Nefunguje komunikace se zákazníkem
2) Nefunguje náš vlastní management a proces

Z toho vycházíme při vývoji SW, abychom zvýšili pravděpodobnost úspěchu.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Příčiny úspěchu SW projektu

A

1) Správná metodika

2) Lidi kteří tomu rozumí (makáči)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Cesta ven z vysokého podílu neúspěšných projektů:

A

1) Dobře zvolený přístup
2) Dobře provozované konkrétní technické aktivity
3) Lidi, kteří to umějí uřídit

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Softwarový proces - principy (vykřičník)

A

Proces: Systematická série akcí vedoucí k určitému výsledku

Softwarový proces: výsledek = kvalitní software

Prvky každého procesu:
1. Čas (činnosti, fáze)
2. Činitelé (role)
3. Výstupy (artefakty)
\+ návody a nástroje
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Sw proces: aktivity

A
  1. Technické
    - Komunikace
    - Plánování
    - Modelování
    - Konstrukce
    - Nasazení
  2. Podpůrné
    - Řízení
    - Kontrola kvality
    - Správa konfigurace
    - Správa prostředí
    - Dokumentace

Programování != SW inženýrství

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Sw proces: role

A
  1. Technické
    - analytik
    - architekt
    - vývojář
    - správce konfigurace
    - tester
    - databázový specialista
  2. Manažerské
    - team leader
    - technický vedoucí projektu
    - šéf vývojářů
    - šéf projektu
    - CTO
    - CEO
  3. Podpůrné
    - poradce
    - lektor
    - už. podpora
    - dokumentace
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Příklad rolí Scrum/RUP

A

Scrum:

  1. Team
  2. Product owner
  3. Scrum master

RUP:
podrobně cca 25 rolí

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Význam artefaktů

A
  1. Preskriptivní metodiky
    - artefakty jsou cílem fáze procesu
  2. Empirický přístup
    - artefakty jsou prostředkem
    - cíl = smysluplný stav/přírůstek produktu

Testovací příklady jako cíl / testovací příklady jako prostředek k dobře otestovanému SW

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Proces X Projekt X Metodika

A

Projekt:
cíl, čas, zdroje

V určeném čase dojít k nějakému cíli. Jsou dostupné nějaké zdroje.

  • Každý projekt běží podle nějakého procesu.
  • Metodika je přepis, který říká, jak by měl proces vypadat. (předdefinovaný proces).
  • Proces se buď řídí metodikou, nebo je vlastně vytvářen projektem
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Životní cyklus

A
  • Životní cyklus ještě nad metodikou
    1. vývoj
    2. výroba
    3. údržba
    4. útlum

Vývoj a výroba součástí metodiky.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Varianty sw procesu (vykřičník)

A
  1. The “null” process
  2. Dle parametrů
    - Míra cykličnosti činností (iterativní x vodopádové)
    - Míra komplexnosti pravidel (low x high ceremony)
    - Míra danosti pravidel (empirické x preskriptivní)

Z toho vyplývá:
A) Sekvenční - vodopád
B) Iterativní - RUP
C) Adaptivní - eXtreme Programming

There is no silver bullet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

The null process

A

Buď analýza -> kódování

V horším případě jen kódování

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Sekvenční postup

A

Hlavní technické aktivity lineárně po sobě

  • plán pro celý projekt
  • stepwise refinement (od abstraktního po konkrétní)
  • oddělené mezirprodukty

Sledování plánu

  • neměnny kontext
  • zadání a technologie zřejmé
  • typicky preskriptivní proces

Př:

  1. Vodopádový model (autor zamýšlel 2 iterace)
  2. V-model
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Cyklický postup

A
  • Opakování technických aktivit
  • Produkt postupně roste
  • Omezování rizika (kontext zřejmý, zadání nebo technologie nejasné)

Př:

  1. Spirálový model
  2. Iterativní přístup
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Adaptivní postup

A

Cyklický postup:

  • krátké iterace, důraz na technické disciplíny
  • !empirický proces
  • Adaptace na změnu
  • Kontext, zadání proměnlivé, nejasné
  • Změny rozsahu pravdědpodobné
  • Technologie nevyzkoušené
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Agilní manifest

A

Jednotlivci a interakce před procesy a nástroji
Fungující software před vyčerpávající dokumentací
Spolupráce se zákazníkem před vyjednáváním o smlouvě
Reagování na změny před dodržováním plánu

Jakkoliv jsou body napravo hodnotné,
bodů nalevo si ceníme více.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Varianty procesu x míra nejistoty

A
  1. Čím větší projekt, tím pravděpodobnost úspěchu klesá

2. S adaptivními metodikami větší šance uřídit větší projekt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Metodiky pro adaptivní přístup

A 
Extrémní programování
Scrum
DAD = disciplined agile delivery
SAFe = scaled agile framework
LeSS = large scale scrum
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Alternativy dodávek funkčnosti

A

1) Velký třesk - na konci najednou
2) Přírůstkově - na základě plánu, úpravy obtížné
3) Evolučně - cíl -> dodávka -> zpřesnění

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Vazba SW procesu na obchodní model

A

1) Na začátku výsledná cena -> produkt dodaný -> dle smlouvy. Změny účtované zvlášť.

2) Rozdělení projektu na dvě fáze.
A) Analytická
B) Realizace, nasazení
Každá fáze vlastní smlouva. Výsledky první fáze vstup do druhé fáze.

3) Na začátku rámcová smlouva. Placeno po částech na konci určitého úseku.
4) Předplatné. Produkt dodáván jako služba.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Driving forces při výběru procesu pro projekt

A

1) Velikost problému
2) Složitost problému
3) Míra nejistoty
4) Návaznosti projektu
5) Kritičnost systému
6) Definice úspěchu
7) Charakter týmu
8) Typ a chování zákazníka

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Ortogonální charakteristy výběru procesu pro projekt

A

1) Na zakázku / interní / krabicový / pro radost
2) Greenfield / brownfield / integrační produkt
3) Výzkum / Vývoj / Rozvoj / Údržba
4) Closed source / Open source
5) Utilita / Systémová komponenta / Business critical / Safety Critical
6) Komerční zákazník, státní sféra, vertikály

Vertikály
př. banky x telcom
banky -> potřeba stability
telcom -> rychlé změny (nový balíček)
Je dobré vědět pro koho dělám, co očekávám
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Rozdíl program / produkt / systém

A

Program -> Produkt -> Systém

Při každém přechodu výš cca 3x obtížnější

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Úrovně flexibility při volbě SW procesu

A
  1. Principy
  2. Metodiky a standardy
  3. Software process improvement
  4. Vlastní ad-hod úpravy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Jak funguje iterativní vývoj

A
  • Rozdělelní projektu do řady miniaturních projektů
  • Iteraci řeším vodopádově
  • Cíl = iterační release (neúplný produkt)
  • Opakovaný postup (téměř stále stejné aktivity)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Průběh iterace (vykřičník)

A
  1. Plánování
    - cíle iterace
    - funkčnost
  2. Zpřesnění požadavků
  3. Úprava návrhu (pokud je třeba)
  4. Implementace
  5. Ověření
  6. Předání do provozu (validace zákazníkem)
  7. Zhodnocení
  • Je dobré vnímat na úrovni jednotlivých požadavků
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Parametry: počet a délka iterací

A

Počet:

  • dle charakteru projektu
  • obvykle alespoň 3
  • dle fází vývoje

Délka:

  • malá je lepší
  • 1-4 týdny pro malé, 3-6 týdnů pro velké projekty
  • produktivita vyšší při blízkém cíli
  • psychologie: včas nutí k těžkým rozhodnutím a kompromisům
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Techniky: Pravidla pro iterace

A
  • Běžící iterace uzavřená vůči změnám
  • Vždy pevné datum ukončení
  • Iterace timeboxované = délka známá předem (každá iterace stejně dlouhá)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Techniky: Předání a zhodnocení (iterativní vývoj)

A

A) Customer demo

  1. Předvedení zákazníkovi (nebo ne)
  2. Interní x Externí release
  3. Akceptace (nebo také ne)

Explicitně naplánovaná událost

  1. Ne úplně na konci iterace (rezerva)
  2. Živý produkt (no slideware)

B) Retrospektiva
co se dařilo = co zachovat
co se nedařilo a proč = co změnit
jak můžeme být příště lepší

kořeny v Kaizen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Kontext iterace v procesu vývoje

A

Sprint X Release X Product
Daily Plan x Iteration Plan x Release Plan x Product Roadmap x Product Vision

  • Iterace jako kolečkou v soukolí
  • Pro stromy nevidět les

Viz obrázek

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Globální řízení: milníky => fáze (vykřičník)

A

Cíl: eliminovat momentálně největší riziko, zabránit oddivergování projektu od původního cíle

  1. LCO = zahájení
    - definování terče - Vize produktu
  2. LCA = projektování
    - určení způsobu řešení - architektura technického řešení
    - ověření - modely, technické prototypy, testy (executable)
    - vývojářská infrastruktura
  3. IOC = konstrukce
    - schopnost efektivně vyrobit řešení
    - beta verze, all features
    - unit a funkční testy
  4. GA = nasazení
    - uvést produkt do rutinního provozu
    - support team v provozu
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Výhody iterativního vývoje oproti sekvenčnímu

A
  1. Better progress profile
    - nepřesnosti, nedospecifikované věci atd. se projevíc brzy, sekvenční na konci a projekt se protáhne
  2. Přesnost odhadu ceny/času
    - Ze začátku může být 4x větší/menší než skutečnost
    - Jak postupujeme iterace zpřesňujeme odhady kvalifikovaněji než u sekvenčního vývoje
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Fáze vývoje a charakter iterací

A

 Základní schema pevné, mění se činnosti a artefakty

 Zahájení – analytické činnosti, validace vize zákazníkem
 1-2 iterace

 Projektování – analytické a designérské činnosti,
ověřování prototypy, implementace
 2+ iterací

 Konstrukce – designérské a programátorské činnosti,
změnové řízení, testování a ověřování
 N iterací,

 Nasazení – integrační a konzultační činnosti, ověřování
provozem, náběh uživatelské podpory
 1-2 iterace

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

PDCA

A

Metodika
Plan - Do - Check - Adapt (act)

Každá iterace PDCA cyklus

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Význam plánování (eisenhower)

A

Plánování je nepostradatelné, ačkoliv se v průběhu ukáže, že ho stejně není možné 100% dodržet. Ale kdybysme neplánovali, tak narazíme na mnohem více problémů.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Základní fakta o plánování

A

1) Plánujeme konkrétní projekt
2) Rámec plánu udává metodika (iterace, plány, milníky)
3) Nějaký plán nutný vždy (harmonogram, přiřazení zdrojů)
4) Sledování plánu nutné vždy (kontrola postupu, reakce na změny/rizika)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Prediktivní plánování

A
  • Plan the work, work the plan
  • Pro sekvenční postup

Na začátku zmapuju, co je třeba udělat -> soupis prací, harmonogram do konce projektu

WBS - Work breakdown structure = rozpis prací

  • Jasné milníky/artefakty

Problémy:

  • velká míra nejistoty
  • neznalost odhadů
  • měnící se požadavky

Řešení:

  • zkušenosti
  • data z minulých projektů
  • menší projekty
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Adaptivní plánování

A

 Přístup
- detailně plánovat možné jen to, na co máme data
- přesnější odhady a plán až po nějaké době
 Typické pro adaptivní metodiky
 Postup:
- základ = hrubý rozpis prací a harmonogram
- plán na N+1 krok zpřesněn poznatky z N (adaptace)

 Základní problém = náročnost a orientace
- vyžaduje průběžné sledování a kvalitní management
- zvenku může působit nesystematicky
 Co s tím: globální pevné body plánu předem

tj. - na začátku hrubý rozpis prací/harmonogram, naplánovat nejbližší období, další kroky řešíme včas později

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Stupně volnosti při plánování (vykřičník)

A

Základ: čas, zdroje (cena), rozsah (funkčnost), kvalita

 Klasicky: rozsah pevný, čas + zdroje plánované
- obtížně měnitelné, odhadované
- kvalita obtížně řiditelná
x typický požadavek: „bude to v termínu, s daným rozpočtem,
samozřejmě v bezchybné kvalitě “
x typická realita: „you get crappy SW late“

: Železný trojúhelník projektového plánování
-> Když chci snížit čas, musím zvýšit cenu nebo snížit kvalitu (rozsah plocha trojúhelníku, čas + kvalita + cena jeho body)

 Agilně: čas + zdroje pevné, rozsah plánovaný

  • nejlepší faktor pro řízení projektu
  • nejsnáze měnitelný
  • vhodná granularita
  • snadné a přesné odhady
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Estimate vs Commitment při plánování

A
  • Plánování založeno na odhadech
  • Nedá se to určit přesně, ale jakmile z toho je plán, tak se z toho udělá commitment
  • Vzniklá stres/konflikt, když plán nevyjde

=> Princip: software development tvořivá činnost, nikoliv rutinní výrobní aktivita

Plán nemůže být commitment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Techniky pro plánování

A

1) Určení rozsahu
2) Určení kvality
3) Určení času
4) Určení nákladů
5) Určení pořadí aktivit a termínů

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Určení rozsahu při plánování

A

= Co všechno má být hotovo

 Rozsah (scope) = množství fcí a jejich charakter
 Sběr a analýza požadavků
 Work Breakdown Structure (WBS)
- dekompozice problému
- identifikace činností

 Problémy

  • „Feature Creep“ = vymýšlení dalších a dalších vlastností nad mez užitečnosti
  • „Analysis Paralysis“ = jste schopní na rozboru věcí, co je potřeba strávit více čas než je nutné a odkládat tak samotnou práci
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Určení kvality při plánování

A 
 DoD = You are not finished with a
sprint/feature/story/task until it meets
the benchmark defined by Done
 Project and team dependent
 Generally accepted traits

„Many Agile projects are not able to deliver value to the customer at the end of each sprint. The software these projects deliver at the end of each sprint is only half ready for release.“

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Určení času při plánování

A

„Jak dlouho to bude trvat?“
- klíčová součást plánování (čas + zdroje => cena)
Čas => Praconost (effort)

 Faktory: dopad činnosti, rozsah, kvalita, čas, úvazky lidí, …

 Metriky
- člověko-hodiny (co znamená „6 člověko-hodin“)
6 člověko-hodin nemusí znamenat kalendářní hodiny
- Story points (obtížnost x hodiny)

 Práce s časem

  • ideální inženýrská hodina vs režie
  • pesimismus vs optimismus dle role
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Odhadování pracnosti

A

1) Analyticky
viz WBS => pracnost jako součet dílčích

2) Adaptivně
- Planning poker
- Wideband Delphi

3) Analogií a odhadem
- zkušenosti, data

4) Výpočtem
- nástrojem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Určení nákladů při plánování

A
  • Kolik to bude stát

Cena:

  • práce (vývoj)
  • prostředků (auta, počítače, license)
  • infrastruktury (elektřina)
  • režie (sekretářka, obchodní zástupce)

Způsob určení:

  • analyticky - pracnost, čas, cena
  • tabulkově - typy prací a prostředků, objemy
  • limitem - rozpočet omezený, od něj odvozený výkon

Make Vs. Buy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Určení pořadí aktivit a termínů

A

„Do kdy má být co hotovo?“

Klasicky: WBS → návaznosti → CPM / PERT → Gantt
 určení závislostí prací (zdroje, technologické postupy)
 graf projektu, analýza kritické cesty
-> Program Evaluation and Review Technique
 zohlednění kalendářního času
-> zdroje, termíny

 Klasický způsob někdy rizikový … proto

=> Řízení riziky
 vyhodnotit rizikové faktory projektu
- designová/architektonická rizika, obchodní, legislativní
- neznámá funkčnost, použitelnost, …
 začít částmi funkčnosti/designu s největší mírou rizika

=> Řízení prioritami klienta
 určení pořadí výstupů je na zákazníkovi
- množství omezeno délkou časového úseku
- iterativní přístup: umožňuje pružně reagovat na aktuální potřeby
 začít částmi s největším významem pro zákazníka

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Okamžiky pro adaptivní plánování

A
  1. Na počátku projektu
     hlavní cíle, hrubé odhady – pracnost, čas, zdroje => cena
     viz „globální řízení projektu“
  2. Na začátku každé iterace
     seznam aktivit (úkolů) s přesnými odhady => “customer demo”
     (aktualizace plánu projektu)
     viz “průběh iterace”

X. Během iterace
 … se neplánuje, pokud možno

Pozn.: Nutný předpoklad: jsou zachycené požadavky

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Plánování projektu v iterativním vývoji

A

Výchozí bod: vize produktu
Okamžik: fáze zahájení projektu

  1. Odhadnout pracnost (rámcově)
    - hrubé WBS, člověko-měsíce
  2. Definovat milníky
    - po stupních přesnosti, míře rizika
    - (vodopád: po činnostech)
  3. Rozdělit prj na oddělené fáze
    - jasné určení cílů a výsledků
    - 1 fáze = 1..N iterací, jejich rámcové definování
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Plánování iterace

A

Cíle: určit účel iterace, podmnožinu funkčnosti k implementaci (např. implementovat kostru programu)

 Kdy:

  • první den iterace (nejpozději)
  • průběžná příprava podkladů

 Odhadnout pracnost <=> vybrat požadavky
 Definovat jednotlivé úkoly
- přechod od “requirements” k “change management”
 Stanovit finální obsah iterace

 Výsledek
- Plán iterace / iterační backlog

Planning Meeting – postup
 Naplánování miniprojektu
0. Cíl: co má být výsledkem iterace (business value)
1. Určení / výběr požadavků
 podmnožina „DSP“ odpovídající cíli, úroveň „use case“
 využívá dosud získané informace o požadavcích (priority)
2. Zpřesnění požadavků <=> odhad pracnosti
 zdroje: obsah vybraných požadavků + „Done“
 rozpad na úkoly (tasks)
3. Určení a commitment prací
 co je nejdůležitější + co je reálné udělat => co bude uděláno
 (vy)řazení / výměna úkolů
 přístupy: direktivní / týmové / Planning Game
4. Vytvoření plánu
 forma: dle dané míry ceremonie

Vypíchnutí:

  1. Plán je dohoda týmu -> commitment
  2. Část zpřesnění požadavků a odhad pracnosti mimo meeting
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Zpřesňování požadavků

A

Pro plánování nutné odhady, pro ně detaily požadavků

Podklady:
 specifikace požadavků (Vize, DSP, backlog, info od zákazníka, …)
 architektonické informace, dostupnost zdrojů

Postup:
 vyjasnění konkrétní funkčnosti / EFR se zákazníkem
 vytvoření návrhu pro realizaci (model, aspoň „v hlavě“ či na tabuli)
 stanovení realizačních prací (viz Definition of Done)

Výsledek: 1 requirement => 1..M úkolů v plánu iterace

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Úkoly (Work Item, Task)

A

Povaha:
 implementace části požadavku
 technické, podpůrné a administrativní aktivity

Vlastnosti: konkrétnost
 zadání, kritéria splnění
 komu přiřazeno
 termín
 odhad pracnosti [hod] – max 1 pracovní den
 související úkoly (nadřazený / blokující / …)

Forma:
 post-it
 úkolovník (Trello ap.)
 ALM

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Tradiční přístup: Iteration Plan (Dokument jako plán)

A

Obsah
 úkoly k realizaci funkčnosti
 opravy chyb
 organizační atd aktivity

  • Odhad pracnosti a alokace zdrojů
  • Priorita, návaznosti
  • Dokument
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Agilní metodiky: Backlog jako plán (vykřičník)

A 
Zahrnuje
• požadavky
• priority
• odhadování
• plánování
• průběh

 Product backlog
- epics + user stories = požadavky na produkt
 Iterační backlog
- stories + tasks = plán iterace
 Priority, rozpracovanost položek
=> pořadí implementace
 Aktivity související s používáním backlogu
- Produktový: backlog grooming, dot voting
- Iterační: planning meeting/game, daily standup

Zkratka DEEP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Zkratka DEEP:

A
  1. Detailed Appropriately

Items in the backlog should contain enough contextual information for you cross-functional team to understand and discuss. Higher-priority user stories will have greater detail and context and be clearly defined.

  1. Estimated

The effort involved with each user story should roughly estimate with a standardized measure agreed upon by the team. While lower-priority items will have less precise estimates than items at the top of the backlog, all items should have at least a rough estimate

  1. Emergent

Because a product backlog evolves, it’s easy to add new stories and items—or remove them—as new information arises. Nothing is permanent.

  1. Prioritized

Items on the backlog are ranked based on their value and the strategic purpose(s) they serve, with higher-value items placed at the top.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

Vztah produktového backlogu a iteračním backlogem

A

Iterační backlog je mapován na položky v produktovém backlogu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
60
Q

Štíhlé přístupy

A

Kanban board
TODO - DOING - DONE

  • průběžný vývoj
  • toto je třeba udělat, kdo má zrovna čas pracuje na úkolu
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
61
Q

Sledování průběhu (plánu)

A

Nutnost. Důvody:
 rozpoznat blížící se riziko
 schopnost reagovat na změnu

Project tracking and oversight
 cíl vs aktuální stav
 odhadovaný vs skutečně strávený čas

Metody
 metriky – produktové (velikost, kvalita), procesní (velocity, burnup)
 reporting – analytické nástroje
 transparentnost – veřejně přístupný plán („information radiator“)
 komunikace – schůzky, XP role „Tracker“

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
62
Q

Komunikace pro sledování postupu

A

1) Schůzky a porady (s vazbou na nástroje a metriky)
- plánovací
- kontrolní dny

2) Scrum / agile: Dauily Standup
- 15 minut standing up
- what have you been doing since last standup
- what will you be doing
- do you have any obstacles

3) Průběžné zjišťování
- management by walking around

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
63
Q

Burndown chart (vykřičník)

A

Vodorovná osa čas
Svislá osa pracnost

Dvě křivky

1) Časový plán (interpolace odhadovaných hodin)
2) Skutečnost (jak se daří plán plnit)

Když zjistím, že nestíhám, tak můžu snížit rozsah
Když jsem zapomněl něco naplánovat, tak burndown chart užitečný, jestli stíhám

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
64
Q

Úprava postupu

A

Výchozí zkušenosti
 plán není nedotknutelný
 ani krátkodobé plány (iterace) se vždy nepovedou

Uvnitř iterace
 opravdu nutné?
 výjimečné stavy a jejich řešení

 Mezi iteracemi
ideální chvíle pro reflexi a úpravy (plán, proces)
viz retrospektiva iterace

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
65
Q

Určení výkonnosti týmu

A

Viz „globální řízení“ iterativního vývoje
 chceme dosáhnout vize
 umíme odhadovat (víceméně) pouze iterace

Zákazník: „Kdy to tedy bude hotovo?“
 Team velocity
 faktory: tým (lidi) + požadavky (pracnost) + plán (čas) + realita (změny)
 průměrná, přibližná hodnota (>= 3 iterace)

Použití pro další plánování (ne pro hodnocení)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
66
Q

Fáze zahájení: Přehled a cíle

A

 RUP a DAD „Inception“ původní Scrum “Pre-game”

 Nápad -> poptávka -> nabídka -> zformování vize || kontrakt -> zahájení projektu

 Cíl fáze:
„To achieve concurrence among all stakeholders on the lifecycle objectives for the project“

 vize produktu – co se má vytvořit
 business case – zdůvodnění, že se to vyplatí
 technický koncept – ověření proveditelnosti

  • důležité porozumění mezi stakeholdery, aby projekt nedivergoval

 Milník: LCO

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
67
Q

Role analytika ve fázi zahájení

A

Analytik

1) analyzuje problém
2) snaží se porozumět potřebám stakeholderů
3) definuje systém a rozsah

Výstupem:

1) vize projektu
2) požadavky

Požadavky jsou:

1) identifikované
2) nastíněné (outline)
3) prioritizované

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
68
Q

Charakteristiky fáze zahájení

A

Důležitá zejména pro nově zahajované projekty
 pokračující / well-defined projekty: význam pro znovu-ověření předpokladů a odhadů

Počáteční „chaos“ => důsledky pro plánování iterací
 Význam „měkkých“ disciplín
= business modelování
= komunikace

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
69
Q

Fáze projektování: Přehled a cíle

A

 RUP a OpenUP „Elaboration“, DAD část „Construction“
 Zahájený projekt (vize) => sběr a analýza požadavků => návrh architektury technického řešení => ověření návrhu => příprava na vývoj

 „To baseline the architecture of the system to provide a stable basis for … the design and implementation effort “

  • > rozumně kompletní DSP – všechny klíčové/kritické požadavky
  • > architektura – základní rysy technického řešení
  • > vývojářská infrastruktura – prostředí pro realizaci

 Milník: LCA

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
70
Q

Fáze zahájení: Klíčové disciplíny a aktivity

A 
rozsah a hranice projektu
návrh ceny a harmonogramu
acceptance criteria
klíčové funkcionality (use cases) a omezující podmínky koncept technické architektury
ověření proveditelnosti
určení rizik
příprava prostředí projektu

Zakroužkované na obrázku: Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
71
Q

Fáze projektování: Klíčové disciplíny a aktivity

A 
doladění vize
sběr požadavků
zpřesnění klíčových požadavků
návrh architektury
validace architektury
výběr technologií a komponent
ujasnění procesu
příprava
vývojového prostředí
naplánování iterací pro realizaci

Zakroužkované na obrázku: Analysis & Desing, Environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
72
Q

Role analytika ve fázi projektování

A

Analytik:

1) Zpřesňuje systém
2) Řízení požadavků
3) Změny požadavků

Výstupem:

1) Change requests
2) Detailnější požadavky

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
73
Q

Požadavky: co, proč, kdy

A

Sběr požadavků, analýza: co se chce
 pochopení problému
 model reálného/projektovaného světa
 podklady – realizace, plán

(Návrh: jak to realizovat)

Úrovně detailu
 zahájení projektu: klíčové, obrysy
 projektování: podstatné, úplnost
 konstrukce: podrobnosti

Pozn: Fáze zahájení a projektování. Disciplíny „requirements“ a „analýza+návrh“

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
74
Q

Požadavek definice

A

Schopnost nebo vlastnost, kterou má
software mít, aby jej uživatel mohl používat k vyřešení
problému nebo dosažení cíle, který vedl k zadání, nebo aby splnil podmínky stanovené smlouvou, standardem, nebo jinou specifikací.

 nepotřebuje-li uživatel X, není X požadavkem
 požadavky jsou omezeny vnějšími podmínkami

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
75
Q

Účel specifikace požadavků:

A

 popsat zadání tak, aby se z toho dalo vycházet pro implementaci =>
 srozumitelnost pro zákazníka, jednoznačnost+struktura pro vývojáře

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
76
Q

Typy požadavků (vykřičník)

A

A) Jádro týkající se SW:

1) Funkční požadavky (to co najdete v menu)
2) Business rules (pravidla, které zpřesňují funkčnost)
3) Constraints (musí vyhovovat zákonu o veřejných zakázkách např.)
4) Mimofunkční (jak rychle, jak často, jak dobře… vlastnosti)

B) Businessové požadavky (zvýšit počet zákazníků v předvánočním období)

C) Systémové požadavky (požadavky na systém, např. celková spotřeba robota)

D) Smluvní požadavky (termín dodání, správná dokumentace)

E) Právní požadavky (GDPR)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
77
Q

Kategorie funkčních požadavků

A 
Klasifikace funkčnosti do čtyř kategorií
 jaké informace systém obsahuje, udržuje
 jaké funkce poskytuje uživatelům
 jaké analýzy dat provádí
 jaké jsou interakce s jinými systémy

Pro každý druh příslušné vlastnosti
 stačí jednoduché seznamy

+ not this time (až příště)
 mimo rozsah zadání
 doplňková funkčnost

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
78
Q

Lidé v analýze

A

Zákazník (právnická osoba)
 externí, interní
 doménový expert

x Uživatel (fyzická osoba)

Zainteresovaný hráč (stakeholder)
 ředitel / investor / standardizační orgán / daňový poplatník
 vliv na úspěch projektu

Analytik
 zprostředkovatel mezi zákazníkem a programátory

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
79
Q

Postup práce s požadavky (vykřičník)

A

A) Reqts development (zachycení požadavků a počáteční rozvoj)
1) Zjištění požadavků (elicit)
2) Analýza požadavků + komunikace (negotiate)
potenciálních požadavky -> stabilní (pevné) požadavky
3) Dokumentace požadavků
4) Revidování požadavků (review)
-> baselined požadavky (závazné)

B) Reqts management (změny požadavků)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
80
Q

Účel definice systému

A

 Základní, stručný popis účelu projektovaného systému

Vyjádřit cíl projektu
 soulad zákazník - dodavatel
 zabránit divergování během vývoje
 prevence nárůstu požadavků (feature creep)

 Etalon pro zhodnocení úspěšnosti projektu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
81
Q

Rozsah definice systému

A

Stručný popis problému

25 slov / jeden odstavec
 k čemu má systém sloužit
 jaké informace bude udržovat
 kdo jej bude používat
 co přinese, čemu pomůže

Tisková zpráva
 jak si představujeme výsledné řešení

Šablona RUP
• problém …
• postihuje … [koho]
• což vede k … [důsledky]
• řešení bude … [cílový stav]
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
82
Q

Kontextový model (definice systému)

A

Zobrazení vztahů systému s okolními entitami
 systém jako černá skříňka
 aktéři, stakeholders
 ostatní systémy

 Rozsah systému

 Rozhraní na okolí
HCI, API, data

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
83
Q

Vize produktu a rozsah projektu

A

Popis cíle, který má vzniknout
 esenciální, klíčové, vysoko-úrovňové požadavky
 „problem behind the problem“

Související artefakty:
 + Business case: proč se to chce
-> zdůvodnění výhodnosti-návratnosti projektu
 Požadavky: co to má dělat

 Též např. Concept of Operations, Definice systému, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
84
Q

Vize produktu: kostra (vykřičník)

A

 Popis problému a účelu
smysl a účel cílového produktu
obchodní příležitost, důvod ekonomické návratnosti

 Přehled stakeholders
kdo jsou zájemci o systém, typy uživatelů
(potenciální konkurence)

 Přehled očekávaných schopností a funkcí produktu
popis, kvalitativní charakteristiky, priority
stručný výčet bez detailů

 Omezení, standardy, závislosti
vztahující se k projektu

 (Rámec plánu projektu)
časový rozsah, plánované verze / vydání

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
85
Q

Use Case - definice

A

Sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou k výsledkům viditelným pro některého jeho uživatele.

-> elementární business process -> pro aktéra proces užitečný

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
86
Q

Definice systému s případy užití (vykřičník)

A

1) Víme jaká je vision and scope
2) Víme kdo jsou aktéři
3) Známe základní skupiny připadů užití
4) Od každého use casu máme stručný popis

UML připady užití mapuje aktéry na případy užití

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
87
Q

Glosář

A

Seznam důležitých pojmů

Faktura -> něco jiného pro zákazníka, firmu, finanční úřad

88
Q

Doménový model (vykřičník)

A

Často relační datový model (podobné ERA modelu)
- abstraktní, neřeším nepodstatné jednotlivosti

1) Obsahuje entity
2) Atributy (i když ty jsou často zřejmé, nebo se musí vyjasnit později)
3) Vazby (kardinalita)

(zjednodušený diagram tříd)

89
Q

Základní popis případu užití (vykřičník)

A

… ve fázi shromažďování požadavků:
základní popis dané funkce aplikace

1) Název (+ ID)
2) Stručný popis – 1 věta
3) Případně
 Základní kroky postupu pro klíčové PU
 Odkazy na zdrojové informace

90
Q

Prostředí: Fyzický rozsah systému (vykřičník)

A

Vztahy produktu a prostředí
 porozumění run-time a fyzickému prostředí
 charakteristiky, parametry – mimofunkční požadavky
 odhad nákladů + podklad pro architekturu

Varianty
 „zelená louka“ – součást návrhu architektury (později)
 „brownfield“ – nutná součást analýzy

Souvisí s diagramem nasazení UML

91
Q

Diagram nasazení

A
  • Kde systém poběží
  • Kolik se na něj bude připojovat uživatelů
  • Která role se bude připojovat kam

-> Slouží pro specifikaci mimofunkčních požadavků

92
Q

Cíl agilních specifikací požadavků

A

 Říci „produkt by měl umět X“
 Podpořit (podnítit) budoucí diskusi o detailech

 Nikoli „Funkce X produktu vypadá tak a tak“

Primárně TODO list

93
Q

User Story (vykřičník)

A

Co uživatel od systému očekává a proč

Obsah
 název
 stručný popis
 důležitost

Způsob zápisu
 karta
 položka v ALM
nástroji

“As a student (role) I want to purchase a parking pass (funkčnost) so that I can drive to school (přínos / bussiness case).

Priority: Should (priorita)
Estimate: 4 (odhad)”

Je to poukázka na rozhovor se zákazníkem, abych dále zjistil, co je třeba.

94
Q

Produktový backlog vztah k velikosti úkolů (vykřičník)

A

Product Backlog
 obsahuje epics, stories
 počátek projektu: features, epics (~ definice systému)
 just-in-time zpřesňování (příští iterace)

 Nejen požadavky
viz Plánování
viz změnové řízení

95
Q

Způsoby získávání požadavků

A

1) Neinteraktivní
 studium dokumentace, hlášení problémů (bugtracking, support)
 analýzy trhu
 konkurenční systémy

2) Interaktivní
 rozhovory; requirements workshop
 pozorování (shadowing), práce s uživateli
 průzkumy (marketingové), dotazníky
 prototypování
96
Q

Pro podrobnou specifikaci požadavků může být potřeba popsat cokoli z …

A 
 Očekávaná funkcionalita
 Mimofunkční požadavky
 Pravidla a procesy
 Uživatelské rozhraní
 Datový model
 Formální (dokazatelné) modely
  • Závisí na typu projektu
97
Q

Detailní analýza požadavků ve fázi projektování

A

Známe
 zadání a cíl projektu
 přehled důležitých funkcí / požadavků
 možné zdroje problémů

Co dál
 doplnit detaily požadavků, kde je třeba
 najít business mechanismy
 vymyslet jejich realizaci

98
Q

Podrobný popis případu užití (vykřičník)

A

Detailní rozbor komunikace aktér-systém

1) Standardní průběh
 nejčastější sled akcí
 bez chyb a různých možností

2) Vstupní a výstupní podmínky
 co potřebujeme pro standardní průběh

3) Chybové stavy a alternativní průběhy
 určení míst výskytu, příčin, následků
 popis alternativních a chybových akcí

99
Q

INVEST u user stories

A

• Independent
-> Neměly by záviset jeden na druhém, protože to vede k prioritizaci a problémům při plánování

• Negotiable
-> není to kontrakt, jsou psány tak, aby postupně mohly být dohadovány (zpřesňovány) se zákazníkem, nemusí proto obsahovat všechny detaily

• Valuable to users or customers
-> vynechat stories, která mají hodnoty jen pro developery (připojení do db jsou přes connection pool)

• Estimatable
-> měly by být dostatečně malé + developeři mají technické a doménové (oborové) znalosti

• Small
-> Epicy by se měly rozpadat na user stories, buď jsou složené, kde je rozpad triviální, nebo jsou komplexní, kde je vhodné přidat další story s analýzou. Měl by se vejít do jedné iterace.

• Testable
-> vyhnout se stories, které nelze otestovat (software is easy to use)

100
Q

FURPS+

A

Model třídění vlastností
 Functionality, Usability, Reliability, Performance, Supportability + constraints
 původně Hewlett-Packard

Omezující podmínky
 normy, zákony
 obchodní pravidla
 implementační omezení (technologie, rozhraní)
 fyzické charakteristiky

Jedná se o mimofukční požadavky

101
Q

Reprezentace vlastností (mimofukční požadavky)

A

Účel: možnost ověřit splnění v implementaci

Měřitelný způsob (numericky)
 obvyklá hodnota, povolené odchylky / četnost / přírůstky
 zvážení realizovatelosti funkčních požadavků
 vhodná reprezentace pro neměřitelné

Popis vlastností
 u případů užití
 u tříd problémové oblasti
 vázané na celý systém

  • Reprezentace mimofunkčních požadavků musí být testovatelná.
102
Q

Procesní modely

A

 Popis scénáře funkčnosti při složitém rozhodování
- když text nepřehledný
 Nadřazený proces dělený do funkčností (PU)
- business process model

Notace:
 UML diagram aktivit
 DFD

103
Q

Prototyp uživatelského rozhraní

A

Prototyp = reprezentace vnějšího rozhraní produktu nebo jeho části, v abstraktní (např. papírové) či konkrétní (spustitelná aplikace) podobě.
 podklad pro určování funkcí a ovládání aplikace
 diskuse nad prototypem korekce neshod v porozumění

Diskuse k prototypování
 jednoduchá testovací data
 abstraktní podoba uživatelského rozhraní
 řízení konečným automatem

Kam s ním?
 vyhodit uchovat
 hraniční třídy pro objektový návrh

104
Q

Vývoj datových entit

A

(Datová) entita typicky prochází vývojem
 životní cyklus

Model = stavový diagram
 vazba na doménový / datový model
 vazba na pravidla
 vazba na funkčnosti
(+ procesy)
105
Q

CRUD(L) matice

A

 Cíl: vědět kdo/co manipuluje s jakými údaji

 Create-Read-Update-Delete(-List)

Úroveň detailu:
 analytická – uživatel, případ užití X informace
 návrhová – třída, funkce, proces X tabulka

106
Q

Formy specifikace požadavků

A

Textový popis
 shopping list
 use case description, story cards
 strukturovaný text

Grafické notace, modely
 případy užití
 procesní atd. modely

Strukturovaný dokument
 normy (IEEE 830-1998)
 RUP šablona
 backlog

Implementace
 prototyp
 uživatelská příručka

Klíčové vlastnosti
- úplnost (všechny požadavky)
- bezrozpornost (např. dva požadavky podobné jiné aktéry -> to nedává logiku)
- trasovatelnost

Dvě základní:

1) Dokumenty
2) Nástroje - datová struktura

107
Q

Architektura systému - definice

A

The fundamental organization of a system … its components, their relationships, … the environment, and the principles guiding its design and evolution.

Dvě části:
1) Vnitřní organizace sw (klíčové aspekty)
 technologie
 struktura (hrubé členění)

2) Pravidla pro celou implementaci (politiky, konvence)
 vzory návrhu/implementace
 mimo-funkční aspekty
 napříč celou strukturou sw

Účel
 jednotnost, srozumitelnost (náklady na údržbu)

108
Q

Stupně volnosti při tvorbě architektury

A

Dáno: kontext
 okolí systému => vazby, technologie, omezení; důvody
- disciplína Enterprise architektura
 stakeholders => úhly pohledu => aspekty architektury
- navíc oproti vizi a požadavkům
- popis: logická struktura, procesní pohled, model nasazení
- datová aj. integrace, bezpečnost, provoz a podpora vč. infrastruktury

Možnost volby: konstrukce v rámci kontextu
 architectural principles – fundamentální přístup pro daný sw
 struktura (prvky, vazby), konvence
 technologie

109
Q

4 + 1 model (vykřičník)

A

1) Logical view
- jak rozdělit systém, abychom se v něm vyznali

2) Process view
= procesní dekompozice
- které částí jsou aktivní a pasivní a jak probíhá komunikace

3) Development view
= dekompozice subsystémů (vrstvy)
- jak to bude vypadat u vývojáře na disku

4) Physical view
= mapování software na hardware

+ scenarios
spojení pohledů dohromady

110
Q

Logický pohled (4+1)

A

 Motivace: monolitická aplikace nepřehledná

Subsystém = skupina souvisejících prvků implementace tvořících funkční celek
 funkčně soudržné (sada fčních požadavků)
 často vázané na jednoho aktéra

Vazby mezi subsystémy
 toky dat
 tok řízení

111
Q

Architektonické styly

A

Zavedené zvyky a standardy

“An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.”

  • Vrstvená architektura
  • Servisně orientované styly
  • Datově orientované styly
112
Q

Vrstvená architektura

A

 Delegování na podřízené
 Komunikace se sousedy

 Vrstvy např.

  • prezentace
  • řízení
  • doména
  • business služby
  • technická infrastruktura
  • knihovní třídy
  • systémové

 Klient-server
- tlustý klient

3-vrstvé a vícevrstvé
 oddělení prezentace, business logiky a datové části
 dnes standard

113
Q

Servisně orientované styly

A
  • Nejsou definované vrstvy
  • Každá služba samostatná entita vlastní rozhraní
  • Příliš mnoho vazeb = těžké se vyznat
  • Řešení broker (pattern) - service bus
114
Q

Fyzický pohled (4+1)

A

 Motivace: monolitická aplikace nepraktická

Subsystém = skupina souvisejících prvků implementace tvořících funkční celek
 funkčně soudržné (lokalita implementačních změn)
 samostatná správa – nasazení, údržba, přístup

Modul, komponenta, knihovna
 celek vhodný pro samostatný vývoj, nasazení a údržbu
 snaha o reuse = vícenásobnou použitelnost
 => kvalitativní charakteristiky důležité
 nutnost znát a spravovat závislosti

115
Q

Vývojový pohled (4+1)

A 
Realizace logické struktury se provádí
v konkrétních technických artefaktech
 Tyto je potřeba vytvořit
- jednotlivci, týmy, projekty
- technologické aspekty
- vývojářská infrastruktura
=> alokace prvků logické struktury do vývojových projektů
116
Q

4+1 - S čím pracuji v logickém, vývojovém a fyzickém pohledu

A

 Logický pohled: subsystémy, balíky => diagramy tříd
 Vývojový pohled: projekty, adresáře, sestavení
 Fyzický pohled: moduly, komponenty, knihovny

117
Q

Konvence a politiky

A

„Architectural policies“
 obecná pravidla pro návrh v libovolné části aplikace
 musí dodržovat všichni vývojáři

 Použité návrhové vzory
 Správa paměti
 Synchronizace, transakce
 Defenzivní programování
 Lokalizace (L10N, i18n)
 Dokumentace kódu
118
Q

Procesní pohled (4+1)

A

Dvě varianty:

1) Struktura paralelizace v implementaci
 procesy, vlákna; způsob synchronizace
 komunikace – synchronní/asynchronní
 propustnost, škálovatelnost, odolnost (deadlock, fault)
 podpora (OS, jazyk, knihovny)
- Vazba na strukturu nasazení (distribuované systémy)

2) Procesní model (workflow) systému
 alokace aktivit do modulů implementace
 synchronizace, předávání artefaktů

119
Q

Jak tvořit návrh architektury

A

Starting points:

1) Greenfield / brownfield / customization
- > greenfield vymyslet architekturu která je jednoduchá, ale funguje
- > brownfield architektura je už hotová, např. neměnit jí
- > customization vysokoúrovňová řešení, ještě něco jiného

2) build on existing / multiple candidates / one candidate arch.
- když vytváříme na zelené louce
- měla by následovat nějaka analýza rizik (měl bych si ověřit)

  • > build on existing -> vezmeme framework, který vyřeší určité rozhodování v oblasti architektury
  • > multiple candidates -> rozhodnutí, že např. vícevrstevná architektura, ale problém rozdělit vrstvy. Pak je dobré si udělat více variant návrhu a mezi nimi si vybrat.
  • > one candidate (systém je jednoduchý, architekt ví), velká pravděpodobnost, že bude správná
Vodítka:
 aktéři, znalost struktury fyzického systému
 architektonické styly a vzory
 možnosti reuse, vývojové kapacity
 zkušenost (role Sw architekt)
120
Q

Jak ověřit návrh architektury (máme více návrhů)

A

1) Diskuze
- modelování (na tabuli)
- joint application design
- what-if scénáře

2) Modelování
- UML nástroje
- Model-Driven Architecture/Development (MDA, MDD)

3) Prototypování
- technologické sondy (zkusit v dané technologie)
- proof of concept (implementace nějaké části funkčnosti)
- mob programming (jeden člověk sedí programuje, víc lidí okolo diskutuje, vytváření prototypu)

121
Q

Validace architektury (vykřičník)

A
  • Validace architektury pomocí spustitelného prototypu
  • Při dosažení LCA vytvoření takové architektury, kde jsme si jistí, že splníme všechny požadavky

1) Vymyslíme architekturu
2) Proof of concept (spustitelná implementace)
3) Na proof of concept zkontrolujeme, jestli vyhovuje všem požadavkům (na architektonicky důležitá funkčnost)

Mechanismy
 návrh na základě
klíčových use cases
a mimofčních pož.
 proof of concept
implementace
 oponentura
122
Q

Význam scénářů v 4+1

A

Mít specifikovány architektonicky důležité požadavky (cca 20 %), na kterých ověřím správnost architektury

123
Q

Dokumentace architektury

A

1) Dokument
2) Modely (diagramy X CASE)
3) Kostra aplikace (referenční architektura)

124
Q

Zdůvodnění arch. rozhodnutí

A

Význam
 proč je architektura právě taková
 kriticky důležité: vysvětluje architekturu i po mnoha letech,
pro čtenáře neznalé kontextu

Obsah
 klíčová funkčnost („architecturally significant use cases“)
 řešení klíčových prvků architektury
 vztah ke kontextu, omezujícím podmínkám, historii

125
Q

Fáze konstrukce: Klíčové disciplíny a aktivity

A 
zpřesnění požadavků
úpravy návrhu
vývoj a testování modulů
ověření vydávaných verzí dle vize
řízení zdrojů, dohled nad procesem

Zakroužkováno:

1) Implementation
2) Configuration & Change Management
3) Test & Deployment

126
Q

Výchozí problém(y) a motivace konfiguračního řízení

A

Při vývoji produktu ve více verzích a/nebo ve více lidech je nutné zamezit zmatkům při

 realizaci jednotlivých uživatelských požadavků
 implementaci změnových požadavků přidávaných za pochodu
 opravování chyb na různých verzích
 provádění změn na jednom objektu (dokumentu, tabulce)
 vytváření a označování spustitelné verze
 zjišťování aktuálního stavu vývoje, nasazené verze

Zjednodušeno:

1) Dvojí údržba
2) Nejasný stav

127
Q

Konfigurační management definice

A

Proces identifikování a definování prvků systému, řízení změn těchto prvků během životního cyklu, zaznamenávání a oznamování stavu prvků a změn, a ověřování úplnosti a správnosti prvků

 Software Configuration Management (SCM)
 řízení konfigurace, konfigurační řízení

128
Q

Konfigurace - definice

A

SW konfigurace = sestava prvků konfigurace reprezentující určitou podobu daného SW systému
 příklad: „první kompilovatelná verze programu XY pro Linux“

  • v konfiguraci musí být vše, co je potřebné k jednoznačnému opakovatelnému vytvoření příslušné verze produktu (včetně překladačů, build scriptů, inicializačních dat, dokumentace)
  • může být jednoznačně identifikovatelná

Konzistentní konfigurace = konfigurace, jejíž prvky jsou navzájem bezrozporné

 příklad: zdrojové soubory jdou přeložit, knihovny přilinkovat
 těsná souvislost SCM a QA

129
Q

Prvek konfigurace - definice

A

Prvek konfigurace = konstituující složka systému
 různé typy: zdrojový soubor, dokument, model, knihovna, script, spustitelný soubor, testovací data, …

Ve správě SCM
=> ví se o jeho existenci, vlastníkovi, změnách,
umístění v produktu
 atomický z hlediska identifikace, změn
 jednoznačně identifikovatelný: např. MSW/WS/IFE/SD/01.2
- typ prvku (dokument, zdrojový text, testovací data)
- označení projektu
- název prvku
- identifikátor verze

130
Q

Vztahy v konfiguraci

A

1) celek-část, master-dependent
- > určují strukturu a závislosti

2) zdrojový-odvozený
- > určují způsob produkce, tj. build produktu

131
Q

Úlohy SCM

A

1) Určení a správa konfigurace = “cfg idenfication and control”
 určení (identifikace) prvků systému, přiřazení zodpovědnosti za správu
 identifikace jednotlivých verzí prvků
 kontrolované uvolňování (release) produktu
 řízení změn produktu během jeho vývoje

2) Zjišťování stavu systému = „status accounting“
 udržení informovanosti o změnách a stavu prvků
 zaznamenávání stavu prvků konfigurace a požadavků na změny
 poskytování informací o těchto stavech
 statistiky a analýzy (např. dopad změny, vývoj oprav chyb)

3) Správa sestavení (build) a koordinace prací = „release management“
 určování postupů a nástrojů pro tvorbu spustitelné verze produktu
 ověřování úplnosti, konzistence a správnosti produktu
 koordinace spolupráce vývojářů při zpracování, zveřejňování a sestavení
změn

132
Q

Aktivity SCM v cyklu vývoje

A

1) Správa změn
2) Identifikace a správa verzí
3) Sestavení

133
Q

Správa změn (SCM)

A

Problém: Jak zvládat množství požadavků na úpravy produktu (opravy, vylepšení)? Jak poznat kdy už jsou vyřešeny? Jak dohledat, co bylo změněno?

-> změnové řízení, change management

Nutný striktní postup akcí:
 vyřešení prioritních, udržení konzistence a stability
 informovanost o změnách, prevence duplikování práce

Význam ve všech fázích ŽC:
 evidence požadavků během jejich sběru
 přiřazení příslušné práce během vývoje
 hlášení a opravy chyb nalezených při testování
 úpravy produktu během provozu a údržby
134
Q

Ticket, požadavek na změnu (SCM)

A

 Hlášení problému (bug report), feature request
= popis nalezeného nedostatku nebo požadovaného
vylepšení
 někdy obecně zváno „ticket“
 strukturovaný dokument, obvykle v ALM nástroji
 zdroj: QA aktivity, uživatel, marketing

Požadavek na změnu (change request, CR) – popisuje změny, které se mají provést na prvku/prvcích konfigurace

 1 ticket <=> 1..N požadavků na změny
 Někdy (často) spojovány do jednoho dokumentu/formy

1 bug report vede na více change requestů (implementace, dokumentace, testy…)

135
Q

Proces správy změn (vykřičník)

A

!naučit se diagram

Požadavek na změnu – stavy
 vytvořený
 schválený
 přiřazený
 vyřešený
 ověřený
 uzavřený
 znovuotevřený
 odmítnutý

Během provádění
 znovuotevření problémů
 vygenerování nových hlášení

4 role:

  • Submitter = vytváření, znovuotevření
  • CCB = vyhodnocení, přiřazení, odmítnutí, schválení
  • Assigned Worker = zpracování
  • Tester = ověření
136
Q

Detaily ticketu

A 
1) Při vytvoření
 nutné náležitosti: shrnutí (+ id, autor, datum)
 popis, co nejpřesnější
=> jak chyba vznikla
=> jak reprodukovat
 screenshot, vzorek dat, …
 závažnost, priorita (odhad)
 konfigurace daného sw a systému (OS, knihovny, …)
=> včetně identifikace verzí

2) Při vyhodnocení
 závažnost, priorita
 odhad pracnosti
=> přímé (kód), návazné (doc)
 komponenta, verze
 závislosti („meta-bug“)
 zodpovědný vývojář

3) Při uzavření
 shrnutí, zdůvodnění
 skutečná pracnost
 výsledná revize souborů/aplikace

137
Q

Případy nouze při změnovém řízení

A

Jsou situace, kdy to nejde udělat dle složitého postupu (hoří čas, mimo schéma)

Prezentace:
Kdy porušit pravidla (proces)
 marginální oprava těsně před release
 vyřešení problému u zákazníka
 …

Pravidla pro porušování pravidel
 je jasný (dlouhodobý) přínos výjimky
 nekamuflovat
-> každý má vidět, že nebyl dodržen standardní proces -> zdůvodnitelné, proč se tak stalo
 zpětně zdokumentovat provedené akce
-> vytvořit hlášení problému, popsat provedené změny
 opakované porušení musí vést k úpravě procesu
-> učit se z toho, co život přináší

138
Q

Change Control Board

A

Skupina členů projektu, která má zodpovědnost za
změnové řízení
 vyhodnocování a schvalování hlášení problémů
 rozhodování o požadavcích na změny
-> CCB může významně ovlivňovat podobu a chod projektu
 sledování hlášení a požadavků při jejich zpracování
 koordinace s vedením projektu

Složení CCB
 jedinec – vývojář, QA osoba
 tým – technické i manažerské role
-> vhodné pokud má změna mít velký dopad
-> znalost účelu produktu

Pozn: Roli vždy někdo dělá (např. v případě Kanbanu ten, co dal položku do TODO)

139
Q

Správa změn a řízení projektu

A

Jsou projekty, které řeknou “vydáváme, až bude málo chyb”

Prezentace:
Kritéria dodávky (release management)
 časový termín
 implementovaná funkčnost / vlastnosti
 kvalita produktu

 Jak určit termín podle kvality? Konverguje nám iterace?
 Změnové řízení je jádrem řízení ve fázi údržby

140
Q

Správa změn a verzování

A

Cíl: trasovatelnost

Vyhodnocení požadavku: jaké verze se týká
 uživatelská verze
 interní verze ze správy verzí

Uzavření požadavku
 do BT výsledou verzi
 do správy verzí ID vyřešeného požadavku

 Vazba ticket-commit klíčová
-> viz vzor „Task-level commit“

141
Q

Správa změn a požadavky

A

Požadavek = ticket typu feature request

Workflow
 vize
 požadavky DSP
 feature requests bugtracker
 (testy)
 bug report a/nebo re-open feature request

 Trasovatelnost -> např. mapování user stories na change requesty
 Flexibilita, souvislost s plánováním

142
Q

Správa změn a údržba

A

Provoz produktu (uživatelská podpora)
 vs. aktivní vývoj
 nutná o to větší pečlivost při úpravách

Hlášení problému
 oprava
 garance, servisní smlouva / vícepráce

Požadavek na vylepšení
 ihned => vícepráce
 naplánovat do přírůstku

143
Q

Systémy pro správu změn

A 
1) Bug tracking (BT) systémy
 evidence, archivace požadavků
 skupiny a uživatelé
 kategorie hlášení
 úrovně závažnosti, priority
 verze produktu, operační systém
 vyhledávání
 reporty, grafy, statistiky
 sledování stavu požadavku
 cfg workflow, reportu

2) ALM (Application Lifecycle Management)
 Bug/issue tracking funkčnosti a charakteristiky (viz vlevo)
 Odhad a realita pracnosti
 Plánování – milníky, fáze/iterace
 Sledování – metriky, grafy
 Těsná vazba na VCS
 Dokumentace a komunikace (wiki, dokumenty, notifikace)
 Multi-team a multi-project
 Integrace s IDE

144
Q

Správa verzí - charakteristika

A

Součást úlohy SCM „identifikace konfigurace“
 aby prvek konfigurace mohl být ve správě SCM, musí být identifikovatelný, včetně všech svých podob

 Účel správy verzí: udržení přehledu o podobách prvků konfigurace a konfigurací

Verze = jedna konkrétní podobu prvku nebo konfigurace
 jaké aspekty zahrnuje „podoba“ => druh verzování
 co je verzováno => granularita verzování
 jak je verze určena (identifikace) => typ verzování

Nástroje: úložiště a verzovací systém (VCS)

145
Q

Typy verzí (vykřičník)

A

Základní druhy verzí

1) historická podoba => revize (“Word 6.0”)
2) alternativní podoba => varianta (“Word pro Mac”)

“V historii jsem došel do bodu, kdy mám verzi konfigurace (např. 6.0), ale mám tři makefile pro tři zákazníky”

Jak určím, jakou verzi mám:
1) Verzování podle stavu
 identifikují se pouze podoby prvků
 výsledná verze vznikne vhodným výběrem

2) Verzování podle změn
 identifikují se (také) změny prvků (viz později changeset)
 výsledná verze vznikne aplikací změn
 změny můžou aplikovat i na jiný stav konfigurace
 není v div v gitu (div není samostatně identifikovatelný)

146
Q

Granularita verzování

A

1) Verzování komponent
 jednotlivé prvky samostatně
 konfigurace nemá verzi
=> pokud chci složit konfiguraci, vyberu prvky s verzí x

2) Úplné verzování
 verzi má celá (sub)konfigurace
 indukuje verze prvků
=> mám více podproduktů s vlastním verzovacím systénem. vyberu podprodukty s jejich verzí x

3) produktové (uniformní) verzování
 struktura (sub)konfigurace a systém verzování nezávislé
 výběr verze indukuje prvky konfigurace
=> jako git, tj. revize nad celým produktem, ne nad podproduktem nebo prvkem konfigurace

147
Q

Identifikace konkrétní verze

A 
1) Extenzionální verzování
 každá verze má jednoznačné ID
 jednoduchá implementace
=  problémy při větším počtu verzí
 naprostá většina VCS (v gitu 64 bitový hash)

2) Intenzionální verzování
 verze je popsána souborem atributů
 nutné pro větší prostory verzí => potřeba vhodných nástrojů
 např. chci verzi na DOS pro zákazníka ABC (nemusím znát id konfigurace)

148
Q

Informace o verzi

A

 Identifikátor verze (extenzionální)

  • > typicky se používají 3 (4) prvkové číselné identifikátory
  • > hodnoty pozic (rozdíly) nesou sémantiku

+meta-data
 datum/čas vytvoření, autor
 stav prvku/konfigurace
 předchůdce (předchůdci)

149
Q

Nástroje pro verzování

A

 Úložiště (databáze projektu, repository) = sdílený datový prostor, kde jsou uloženy všechny prvky konfigurace projektu
 centrální místo
 určitě všechny prvky ve všech verzích
(způsob uložení: dle granularity a typu verzování)

-> Nutný řízený přístup (udržení konzistence)

Version Control System (VCS)
 sada nástrojů pro práci s úložištěm

Implementace:
• souborový systém + dohodnutá pravidla používání
• verzovací nástroj
• databáze s rozhraním podporujícím postupy SCM

150
Q

Práce s úložištěm

A

Základní operace
 vytvoření – založení úložiště, případně zpřístupnění existujícího
 inicializace – naplnění bootstrap verzí projektu
 check out – kopie prvku do lokálního pracovního prostoru
 check in (commit) – uložení změněných prvků do úložiště
 branch + merge – oddělení různých prací
 tag – označení vybrané verze symbolickým identifikátorem
 zjišťování stavu – sledování změn v úložiště vs. prac.prostor

Přístup k zamykání při ci/co
 read-only pro všechny
 pesimistický: read-write kopie prvku jen pro pověřeného
 optimistický: read-write pro kohokoli, řešení konfliktů

151
Q

Centrální vs distribuovaný vývoj

A

Možnosti:
 centrální úložiště = nemá příčné vazby
 privátní větve
 distribuovaný verzovací systém = umožňuje pull i od jiného člena, nejen z centralu

Centralizovaný
 update
 commit
 Vyžaduje online přístup, zodpovědnost; poskytuje jednoduchost a přehled

Distribuovaný
 fetch, update, commit, cleanup
 push
 Vyžaduje znalosti a disciplínu, rozlišení zdrojového úložiště; poskytuje variabilitu procesu

Pozn: nezaměňovat „distribuovaný“ a „vymoženosti git + GitHub“

152
Q

workspace

A

Pracovní prostor (workspace) = soukromý datový prostor, v němž je možno provádět změny prvků konfigurace, aniž by byla ovlivněna jejich „oficiální“ podoba používaná ostatními vývojáři
 vývojářský (soukromý)
 integrační (sdílený)

Zpřístupnění úložiště pro práci
 checkout
 clone

153
Q

Delta, Changeset (verzování)

A

 Delta = množina změn prvku konfigurace mezi dvěma (po sobě následujícími) verzemi

  • > příklad: přidání sekce „kontext produktu“ do DSP, patch foo.c
  • > v některých systémech jednoznačně identifikovatelná (

Changeset
 související delty tvořící atomický celek, ve správě SCM
 obvykle též “+ důvod” tj. vazba na správu změn
 viz OpenUp Concept: Change Set
= sloučení množiny delt

154
Q

Tag (verzování)

A

Tag, label = označení konfigurace symbolickým jménem
 štítek
 různé způsoby realizace

155
Q

Baseline (verzování)

A

Konzistentní konfigurace tvořící stabilní základ pro produkční verzi nebo další vývoj

-> příklad: milník „stabilní architektura“, beta verze aplikace

 stabilní: vytvořená, otestovaná, a schválená managementem
 změny prvků baseline jen podle schváleného postupu

 Při problémech návrat k tag, baseline

Význačné:
1) Interní release (iterace)

2) Milníky projektu
- > jednotlivé fáze životního cyklu
- > alfa verze = „feature complete“, interní testování
- > beta verze = testování u (vybraných) zákazníků

3) Finální release produktu
- > verze dodané zákazníkovi/na trh

156
Q

Paralelní práce

A

Souběžné úpravy stejné konfigurace spravované VCS
 Důvod: velké úpravy, release, spekulativní vývoj, varianty
 Cíl: vzájemná izolace paralelních prací
=> aby ukládané změny během nich neovlivnily ostatní
=> oddělení paralelních vývojových linií

 Cena za izolaci od změn = řešení konfliktů

157
Q

Větvení a spojování

A

Kmen (trunk, master) – hlavní vývojová linie
Větev (branch) – paralelní vývojová linie
 konkrétní účel viz vzory pro verzování
 operace vytvoření větve (branch-off, split)
Spojení (merge) – sloučení změn na větvi do kmene
 slučuje se delta od branch-off nebo posledního merge
 řešení konfliktů: automatizace vhodná, ale ne vždy možná
 2-way a 3-way merge

Varianty u Git:

  • squash
  • rebase
158
Q

Codeline (vykřičník)

A

Codeline (vývojová linie) = série podob (verzí) množiny prvků konfigurace tak, jak se mění v čase

= V podstatě větev v gitu doplněná o pravidla

HEAD = poslední commit na větvi (mám tolik headů kolik větví)
TIP = nejčerstvější HEAD (jeden v projektu)
Pravidla (policy):
• typ prací (vývoj, údržba, release, …)
• očekávaná kvalita kódu
• pravidla/akce před ci, po checkout, …
• jak a kdy ci, co, branch, merge
• přístup pro osoby a skupiny
• kam (codeline) exportovat změny, odkud importovat
• doba platnosti či podmínky odstavení
159
Q

Vzory pro verzování

A

1) Privátní verze (private versions)
 soukromé úložiště pro častější check-in
 abych nedával commit na master, ale dělal do svého workspace

2) Check-in pro úkol (task-level commit)
 minimum nutného
 pro každý úkol v change managementu jeden commit

3) Větev pro úkol (task branch)
 složitější úpravy s většími následky
 izolace změn (většího úkolu)
 feature branch

4) Hlavní vývojová linie a (mainline) a pravidla (codeline policy)
 jedna codeline pro průběžný vývoj

5) Stabilizační období (code freeze)
 pravidla před release

6) Větev pro release a jeho přípravu (release prep, rel line)
 místo code freeze

7) Správa kódu třetích stran (third party codeline)
 vlastní větev pro každý kód od externího dodavatele

160
Q

Řízení sestavení

A

 Aktivity provádějící transformaci zdrojových prvků
konfigurace na odvozené => zejména sestavení celého produktu
 Cíl: vytvořit systematický a automatizovaný postup

Pojmy
 sestavení / build (též integration) – proces a výsledek (artefakt) vytvoření částečné nebo úplné podoby aplikace

161
Q

Sestavení: proces (kroky) (vykřičník)

A
  1. příprava
  2. check-out
  3. preprocessing
  4. překlad, linkování
  5. nasazení
  6. spuštění
  7. testování
  8. značkování, check-in
  9. informování

Sestavení != gcc a.c

162
Q

Sestavení: pravidla (vykřičník)

A

1) Jedinečnost a identifikovatelnost
 sestavení jako artefakt: PROJEKT_v2_build2134_20041220T1954
 identifikátor jednoznačný, čitelný
 vytvořitelný a zpracovatelný automaticky (schema pro id)

2) Úplnost
 tvoří kompletní systém, obsahuje všechny komponenty

3) Konzistence
 vzniklo ze správných verzí správných komponent
=> tj. z konzistentní konfigurace

4) Opakovatelnost
 možnost opakovat build daného sestavení kdykoli v budoucnu se stejným výsledkem

5) Dodržuje pravidla vývojové linie
 build odpovídající baseline
 zejména release má striktní pravidla

163
Q

Součásti prostředí pro sestavení

A

1) Pravidla -> Jak to provést?
 vývojová linie
 součásti a vlastnosti sestavení

2) Scripty -> Čím to provést?
 check-out, značkování, check-in
 preprocessing, překlad, linkování
 nasazení, spouštění, testování
některé nebudou u interpretovaných jazyků, dokumentů apod.
 informování vývojářů, vytváření statistik
 vytvoření distribuční podoby (packaging)

3) Vyhrazený stroj a workspace -> Kde to provést?
 „build machine“
 zejména pro integrační a release sestavení

164
Q

Typy sestavení (vykřičník)

A

Liší se:

1) Obsahem sestavení
 přírůstkový (inkrementální) build
 čistý
 úplný

2) Účelem sestavení
 soukromý
 integrační (oficiální)
 release build

165
Q

Vzory pro sestavení

A

1) Základní postupy
 soukromé sestavení (private system build) -> nad privátním workspace
 integrační sestavení (integration build) -> nad sdíleným úložištěm, odstíněné od konfigurací vývojářů

2) QA-related postupy
 zkouška těsnosti (smoke test)
 regresní testy (regression test)

Cíl 1 + 2 => odchytit co nejdříve okamžik kdy „se to rozbilo“

3) Vydávání produktu
 release build
 balení a distribuce (packaging)
=> rozšíření integračního buildu, to co vznikne sestavení je verze produkt rozšířená o metadata indentifikující verzi + readme atd., slouží pro zákazníka

4) Podpůrné aktivity
 kusovník (Bill of Materials) a zapouzdřená identifikace
 archivace prostředí

Cíl 3 + 4 => opakovatelná záruka dostatečné kvality

166
Q

Soukromé sestavení - vzor pro sestavení (jen prolétnout)

A

Cíl: ověřit si konzistenci konfigurace
 produkt lze sestavit po mnou provedených změnách
 před check-in (problémy řeším já x všichni)

Postup: sestavit produkt v soukromém prostoru
 pomocí sestavení (scriptu) co nejpodobnějšího oficiálnímu
=> postup, verze nástrojů, adresářová struktura
=> rozdíly = problémy
 obsahuje všechny závislé součásti produktu
 ze zdrojových textů zejména změněné a přímo související
=> ze správy vzít pro build verzí vše / kromě označeného / pouze označené

Urychlení průběhu
 použít inkrementální sestavení, kde je to vhodné
=> pozor při přidávání souborů, rozsáhlých a/nebo významných změnách
=> úplné sestavení: dělat na čistém (novém) workspace
 vynechat postupy pro balení, vkládání info o verzi
 pomoci si sdílením odvozených prvků (shared version cache)

167
Q

Integrační sestavení - vzor pro sestavení (jen prolétnout)

A

Cíl: spolehlivě ověřit, že produkt jde sestavit
 soukromý build nestačí
=> složité závislosti, specifiká ve workspace, zjednodušení pro zrychlení
 úplné sestavení trvá dlouho => nemůže provádět vývojář

Postup: celý produkt (vč. závislostí) sestaven centrálně, automatizovaným a opakovatelným procesem

 postup co nejpodobnější sestavení pro release
=> vždy „na zelené louce“ (clean full build)
 maximální automatizace - typicky běží přes noc
 spolehlivé mechanismy zaznamenání chyb a informování o nich
=> emailové notifikace začátek, konec, výsledek
=> web s přehledy a detaily
 úspěšné sestavení může být označkováno ve verzovacím systému

168
Q

Kusovník - vzor pro sestavení (jen prolétnout)

A

 kompletní seznam prvků sestavení
=> reprodukovatelnost sestavení kdekoli, kdykoli
=> zejména při distribuovaném nebo jinak složitém buildu
 samoidentifikující konfigurace pomůže
=> znalost verzí bez přístupu k verzovacímu systému
 viz strojírenství ; automatizace (ClearCase make)

169
Q

Archivace prostředí - vzor pro sestavení (jen prolétnout)

A

 správa verzí objektů, které nejsou v úložišti
=> nástroje, platformy, hardware, prostředí - identifikovat sestavení
 klíčové pro dlouho žijící software (např. povinné v letectví)

170
Q

Release build - vzor pro sestavení (jen prolétnout)

A

Význačné integrační sestavení: dodáno zákazníkovi
=> může být interní zákazník, např. QA

Náležitosti release:
 revize/verze konfigurace použité pro sestavení
=> které prvky, v jakých verzích (vč. 3rd party)
 datum vytvoření
 identifikátor sestavení
 další metadata
=> zodpovědná osoba
=> zdrojová značka konfigurace (z verzovacího systému)
=> jakými prošlo testy, výsledky testů
=> cesta k logům překladu, testů
 „marketingová verze“ – např. OpenCms 7.5

171
Q

Daily Build and Smoke test (vykřičník)

A

=> jednou za den integrační sestavení, jehož součástí jsou smoke testy

Výhody
 malé množství změn během denních check-in
=> zvladatelné množství oprav, včas detekce problémů „vždyť včera to fungovalo“, analýza změn kódu místo ladění – viz diskuse o sestavení
 pravidelný, obecně známý rytmus projektu
 lepší morálka týmu („to nám to roste“)

Cena: trocha discipliny, trocha automatizace

172
Q

Continuous Integration

A

Integrace 1x denně => neustálie

 Klíč: automatizace
 co/ci, sestavení, testování, oznamování
 robot na spouštění

173
Q

Fáze předání: Přehled a cíle

A

(Hotová beta) -> Dát produkt k dispozici uživatelům
 … triviální až extrémně složitá fáze

V rámci fáze předání se ukáže, jestli projekt naplnil potřeby a cíle zákazníka. -> Význam Vize

Milník: GA (REL)

174
Q

Fáze předání: Klíčové aktivity a disciplíny

A
  • nasazování produktu dle plánů nasazení
  • dopracování podpůrných materiálů
  • field testing a finální úpravy
  • release
  • marketingová kampaň, výroba, distribuce

Deployment Manager -> Plánování nasazení, vytvořit verzi produktu pro nasazení, vlastní nasazení

Vývojáři a Testeři -> Zbylý vývoj, zbylé QA, integrace systému

Technická podpora -> Vytvoření podpůrných materiálů, školení, videa, uživatelská příručka

Managemenet -> Uzávěrka projektu

175
Q

Fáze předání: Charakteristika

A

Počet a povaha iterací různý
 online služba
 malý krabicový produkt
 nová verze systému (např. řízení rozvodné sítě)

Možný současný / následný náběh nového cyklu

Legislativní a technické důsledky
 záruka
 servisní smlouva
 podpora a údržba

176
Q

Příprava vydání (vykřičník) (aktivity + role)

A 
Nutné / obvyklé aktivity
 field testing a korekce (testování v prostředí zákazníka)
-> konfigurace, použitelnost
-> pokud funkčnost pak je problém
 konverze  a integrace dat
-> napojení na okolí
-> autorizace a autentizace (přístupová práva uživatelů)
-> data z release 1 do release 2
 příprava překlopení (cutover)
-> kterým okamžikem poběží nová verze, příprava
 přejímka (akceptační řízení)
-> musí být zadavatelem systém schválený
 informační kampaň, školení uživatelů

Zainteresované role
 development, operations
 marketing, vrcholový management projektu, legal

177
Q

Akceptační řízení

A

Formální odsouhlasení dodávky zástupcem uživatele
 produkt a doprovodné materiály splňují požadavky
 bylo dosaženo cílů vytyčených v plánu projektu

Následuje po [úspěšných] uživatelských testech produktu

Role
 zástupce zákazníka
 project manager, vedoucí týmů / oddělení

Podklady
 iteration assessment
 výsledky testů (funkčnost, instalace, dat, …) a dalších QA aktivit
 prohlášení o ukončení přechodu na nový systém

Výsledek
 akceptováno / s výhradami / neakceptováno
 zákazník přebírá produkt do vlastnictví

178
Q

Uzávěrka projektu

A

Cíl = formálně ukončit projekt, shrnout zkušenosti
 zcela poslední iterace projektu

Interní audit konfigurace
 kontrola úplnosti baseline (zde release) – fyzický audit
 kontrola správnosti baseline – funkční audit
 soupis chybějících prvků, neotestovaných funkčností, nefunkčních částí, neuzavřených change requests, …
 opravy a začištění projektu

Post-mortem review
 „only by analyzing our shortcomings can we learn to do better“ – viz dále Process improvement
 obecné kroky: zjištění nastalých problémů, analýza jejich příčin (root cause analysis), určení opatření k nápravě
 důležité faktory: komunikace, dokumentace, věcnost

Možný postup post-mortem review:

  1. dotazník
  2. data projektu, časová osa průběhu
  3. meeting a debata (tým)
  4. data a příčiny (vybraní)
  5. report
179
Q

Pojmy CI / CD

A

 Jakmile vývojář dokončí práci na úkolu …

1) Vanilla Development
 nic se nestane (v lepším případě “merge na dev branch”)

2) Continuous Integration (CI)
 změny kódu integrovány do mainline a procházejí sestavením

3) Continuous Deployment
 sestavení je nasazováno na cílové prostředí

4) Continuous Delivery (CD)
 nasazení znamená zpřístupnění koncovým uživatelům

180
Q

Důvody pro CD

A

Agile Manifesto: Principle1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “

Proměna technology/sw landscape
 cloud (SaaS), mobile apps, služby postavené na sw
 zmenšující se podíl instalovaných aplikací/systémů

Tlak na Time to Market
 vydání produktu (start-ups), funkční a bezpečnostní aktualizace
 vs délka procesu nasazení/vydání

Tlak na spolehlivost, dostupnost a bezpečnost
 ekonomické důsledky, zodpovědnost provozovatele

Výkonnost organizace a vývojářský stres
 chybovost systémů, frekvence změn, deployment pain

181
Q

Přístup CD (principy)

A

To get product to users safely, quickly and sustainably:
 build quality in
 work in small batches
 computers perform repetitive tasks; people solve problems
 relentlessly pursue continuous improvement
 everyone is responsible

organizační kultura
 generativní (výkonově orientovaná)
 vysoká míra spolupráce
 experimentování, chyby vedou k analýze příčin

182
Q

DevOps

A

Základ pro CD

Tradiční model
 vývojový tým oddělen od provozní tým
 nasazení do provozu je věcí provozního týmu
 třecí plochy: akceptační testy, hotfixes, časté přírůstky

Dev(elopment plus)Op(eration)s těsně spolupracující
 jeden tým (společná zodpovědnost)
– viz Scrum “cross-functional, empowered”
 nové specifické dovednosti
 úzká vazba na QA
 intenzivní nástrojová podpora – rychlá integrace, verifikace, nasazení přírůstků; agile + SCM + cloud

183
Q

CD jako proces životního cyklu

A

Týká se celého vývojového procesu, nikoli fáze předání
 Kontext = zejména webové systémy, služby
=> rychlé zpřístupnění nových funkcí a oprav uživatelům

Fáze
 Identification => business case
 Inception => (viz UP)
 Initiation => (~ Elaboration)
 Develop and release => Construction+Transition
 Operation => Production+Retirement (viz EUP)

Poslední dvě pak ve smyčce

184
Q

Provoz a podpora produktu (vykřičník)

A

Provozní fáze: Nejdelší období životního cyklu sw
Cíl: udržení užitečnosti a efektivity

Operations and support:
 zajištění provozu produktu, péče o prostředí
 monitorování systému, zálohování a disaster recovery
 spouštění jednorázových / zřídkavých úloh
 pomoc uživatelům a komunikace s nimi
 analýza problémů, reporty chyb a rozšíření, nasazení oprav
 … viz konfigurační řízení

185
Q

Údržba produktu (vykřičník)

A

Cíl: zabránit degradaci
= Vývojářská disciplína

Klasické typy údržby
 corrective (opravy)
 adaptive (např. přidání podpory pro nový typ zařízení)
 perfective (nice to have věci, na které předtím nebyl čas)
 preventive (refactoring)

Rozvoj produktu
 souvislost s obchodním modelem
 samostatný projekt .. předplacená služba

186
Q

Discipliny pro enterprise kontext

A

= Obchodní obálka kolem vývoje

1) Enterprise administration
 jak organizace vytváří, udržuje, spravuje a uvádí do provozu své „assets“ pro IT infrastrukturu
 zajištění provozu systémů, dat, informací a bezpečnosti
 “My potřebujeme license na OS, firewall…”

2) Enterprise architecture
 definuje celkové jednotné prostředí, do kterého jsou zasazovány jednotlivé produkty
 technické a organizační rámce, síťové prostředí, konfigurace, podpůrná infrastruktura
=> omezení architektury systémů
(např. požadavek výsledný produkt má být v technologii Microsoft)

3) Business modeling
 porozumění stávajícím (nezměněným) cílům, hranicím, procesům a strukturám organizace [zákazníka]
 význam pro BPR, potřeba hlídat rozsah
 UML: activity models. BPMN.

4) Software process improvement (SPI)
 podpora analýzy, vytváření a používání sw procesů vedoucích k efektivitě
 Agile: průběžná aktivita (retrospektivy, Scrum master)

187
Q

Vyřazení produktu

A

Odebrání z provozu (+ nahrazení novým)

Důvody:
 náhrada novým systémem, redundantní
 neudržováno / zastaralé
 k nepotřebě

Zainterestované skupiny
 vlastníci („investoři“)
 koncoví uživatelé
 operations and support
 obchod a marketing
188
Q

Postup vyřazení z provozu (vykřičník)

A

Aktivity
 analýza vazeb na ostatní systémy
 určení strategie a realizace postupu vyřazení + nahrazení
 testy (náhrada funkčnosti)
 aktualizace dokumentace
 migrace dat, uživatelů
 archivace dat, kódu, deployment procesu, dokumentace
 vypnutí přístupů (autorizační systémy) a konektorů
 odstranění systému

Základní strategie pro vyřazení
 „big bang“ / po etapách / v souběhu s novým

189
Q

Jaký software je „kvalitní“

A

Klíčový pojem: Fitness for purpose „The totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.“ (ISO 8402:1986 Quality – Vocabulary)
 => primární měřítko jsou uživatelské požadavky
 jiná definice: absence chyb (Six Sigma)

Funkcionalita je očekávána, kvalitativní vlastnosti prodávají
 „How do we define sw development success?“

Druhy kvality
 vnější – spolehlivost, výkonnost, použitelnost, bezpečnost, …
 vnitřní – architektura, odolnost proti změnám, testovatelnost, …
 Vnitřní kvalita je základem pro vnější

190
Q

ISO 25010 Software Quality Model

A 
 Functional Suitability
 Performance Efficiency
 Compatibility
 Usability
 Reliability
 Security
 Maintainability
 Portability
191
Q

Úroveň dosahované kvality

A

Široké spektrum
 „semestrální práce“
 utilita
 [systémový] produkt
 systém odolný proti poruchám (fault-tolerant)
 bezpečnostně kritický (safety-critical) systém

Určení úrovně kvality důležité pro technické i organizační aspekty projektu

192
Q

Opak kvality: geneze selhání sw

A

1) Omyl (error)
 přehlédnutí, omyl nebo špatné designové rozhodnutí
programátora; důsledkem je

2) Defekt (defect, též fault či bug)
 závada, nedostatek v [zdrojovém kódu dodaného] produktu; důsledkem může být

3) Chybový stav (run-time fault)
 jiný než očekávaný (správný) run-time stav nebo výstup (sub)systému; důsledkem může být

4) Selhání (failure)
 neschopnost systému nebo jeho části vykonávat požadované funkce v požadovaných výkonnostních limitech; pozorovatelné navenek.

193
Q

Řetězení a cena chyb

A

 Jednou vzniklá chyba působí řetězovou reakci
 Čím později odhalena tím dražší náprava
=> relativní cena odstranění chyby
 … následky chyby se zvětšují během vývoje

194
Q

Způsoby zajištění kvality (vykřičník)

A

 QA = Quality Assurance

 Verifikace (bezchybný produkt) a validace (správný produkt)

Detekční a opravné techniky
 cíl: najít a opravit již existující chybu
 testování a ladění
 typické v koncových fázích („výstupní kontrola“)

Preventivní techniky
 cíl: zabránit vzniku event. dalšímu šíření chyby
 „racionální proces“ a „best practices“
 kontroly a měření meziproduktů
 častější v úvodních fázích
195
Q

Testování

A

Ověření správné funkčnosti implementace

 Úrovně testování
 jednotkové -> integrační -> funkční -> systémové
 zátěžové, výkonnostní, bezpečnostní, instalační, použitelnosti
 interní, akceptační

Techniky pro testování
 white-box, black-box
 výběr dat (hraniční podmínky, fuzz testing, …)

196
Q

Smoke Test

A

Cíl: ověřit, že sestavení vytvořilo funkční produkt
 samotný překlad/linkování toto nezaručuje
 kompletní testování trvá dlouho
 potřebujeme rychlý základní test, jehož provedení „nebolí“

Postup: vytvořit testy ověřující základní funkčnost, bez
nároku na kompletní otestování
 odchytí nejkřiklavější chyby, odpustí drobnosti
 automatizace - spuštění, vyhodnocení
 spuštění při každém buildu (vč. soukromého)
-> podle toho náročnost, rozsah, počet testů
-> může být založena na testech modulů
-> přidání nových funkcí/vlastností => nové testy těsnosti

197
Q

Regresní testy

A

Cíl: zajistit, aby nové funkce a vylepšení nesnižovaly kvalitu již hotového kódu
 prevence stárnutí kódu: zanášení chyb při implementaci vylepšení
 vymyslet mechanismus jak vytvářet vhodné testy

Postup: ověřit build produktu pomocí testů, kterými již dříve prošel (kromě testů nových funkcí)
 indikátor existence systémových problémů
 určení zdroje chyby není nutné => testy integrační, modulů
 testování změn v (nečekaných) integračních aspektech
 spuštění při integračním sestavení, před velkými změnami

Dobrý zdroj testů: chyby objevené QA, při validaci, zákazníkem
 produkt selhal -> napsat test, který to dokáže -> přidat jej do sady regresních testů (odebírání testů ze sady není dobrý trik)

198
Q

Statická kontrola kódu

A

 Ověření formální správnosti + dodržování pravidel + metriky

Nástroje
 překladač a jeho hlášení (!)
 C: lint
 Java: pmd, findbugs, checkstyle, JSR 305

Postupy
 Programming by Contract
 review, párové programování
 automatický build – výběr pravidel, průběžné úpravy

199
Q

Formální verifikace

A

Matematické důkazy správnosti
 návrhu
 implementace

Model checking
 formální model systému – Petriho sítě, algebry (CSP)
 a-priori nebo získaný analýzou kódu
 model checker => deadlock-free, liveness, …
 soulad s implementací

Nástroje: Java PathFinder, SPIN, PRISM, SMV, …

200
Q

Preventivní techniky (vykřičník)

A

Best practices
 návrhové vzory, coding practices
 refactoring
 prověření (oponentura) meziproduktu nezávislou osobou
 techniky spolupráce => pair and mob programming (“víc očí víc vidí”)

Kontroly a úpravy procesu
 metriky a automatizované testy => zpětná vazba
 retrospektivy
 coaching, mentoring
 GQM přístup
201
Q

Technická oponentura

A

 Též Faganovská inspekce (Fagan, IBM 1976)

Skupinová technika (využití diverzity pohledů)
 Cíl: odhalit chyby v návrhu/kódu/dokumentu
 Souběžný efekt: sledování standardů, vzdělávání
 Ne: dělat potíže autorovi (neúčast vedení), hledat nápravu chyb

Role ve skupině (cca 4-7 lidí)
 moderátor – řídí diskusi
 průvodce – předkládá dílo (není autor)
 autor – vysvětluje nejasnosti
 zapisovatel – zaznamenává nalezené problémy
 oponenti – hledají chyby, obvykle podle seznamů otázek

202
Q

Technická oponentura – postup

A

Příprava
 distribuce díla (moderátor), projití a hledání problémů (oponenti)
 několik dní předem, cca 2h práce

Schůzka
 sekvenční procházení díla (průvodce či moderátor)
 vznášení připomínek
 zapisování nálezů (chyb a otevřených otázek)
-> nejvýše 2 hodiny
-> nepřipouštět dlouhé diskuse, řešení chyb (moderátor)
-> možná následná schůzka pro vyjasnění otázek

Závěry
 verdikt: v pořádku / drobné chyby / nutné přepracování / nová
oponentura
 autor odstraní chyby dle nálezů, moderátor zkontroluje
 dokument „Nálezy oponentury“

203
Q

„Lehčí“ techniky technické oponentury

A

1) Strukturované procházení
 podobné Faganovské inspekci
 menší důraz na formálnost, větší flexibilita
 shodné: příprava předem, schůzka s procházením, checklist
 není: striktně rozdělené role, následná kontrola oprav, statistiky

2) Peer review
 „kontrola nezaujatým čtenářem“
 autor prochází kód a vysvětluje
 kolega hledá problémy a komentuje
 častý jev: autor najde chyby ve svém kódu, když jej má vysvětli

3) XP edition: Párové programování
4) Modern Agile: Mob programming

204
Q

Statistické řízení procesu

A

Základ: metriky (statistické kontroly)
 indikátor „někde je něco špatně“
 kvantitativní ukazatele pomáhají najít slabiny kvality
 přesnost a dokazatelnost, možnost statistik

 Stanovení očekávaných / správných hodnot
 Průběžné monitorování
=> technika zasévání chyb
 Korekce procesu při odchylkách

205
Q

Účel měření v software

A

K dosažení požadované kvality potřebuje Kvantitativní ukazatele
 pomáhají najít slabiny => zlepšení
 dávají přehled a kontrolu
 kalibrují odhady

Výhody
 přesnost a dokazatelnost
 možnost statistik a vizuální prezentace

 Potřeba „Organizational focus“ – záměr zlepšovat kvalitu
 vede k potřebě mít informace

206
Q

Teorie měření (definice metriky, hodnoty, očekávání x skutečnost) (vykřičník)

A

Metrika = měřitelná charakteristika nějaké entity
 měřený objekt (entita): pro nás sw produkt, prvek sw procesu
 odvozená získána na základě dat (primitivních metrik)
 náhradní (proxy) metrika pro obtížně měřitelné entity

Hodnoty
 stupnice –
nominální => jen slovně, nemají jinou vazbu (tagy)
ordinální => seřazené hodnoty (priority)
intervalové => od-do (odhad času) (stupně Celsia)
poměrné => kolikrát je něco delší (stupně Kelvina)
proporcionální => poměr z celku (poměr kritických chyb)
procentuální => proporcionální v procentech
míra => kolikrát za jednotku času
 očekávané (min/max/průměr), skutečné (dtto, trend)

 Platnost (validnost) měření
=> korelace, závislé a nezávislé veličiny
 Spolehlivost měření
=> průměr/medián, odchylka
 Chyby měření
=> systematické, nahodilé
Př.:
• stav defektu
• priorita defektu
• odhad pracnosti
• velikost modulu
• četnost kritických chyb
• % kritických chyb
• změny požadavků
207
Q

Druhy metrik v SWI

A

1) Produktové
- velikost
- složitost, přehlednost
- kvalita
- spolehlivost
- problém: nehmotný produkt

2) Procesní
- rychlost
- kvalita
- efektivita
- problém: měření činností a vlastností lidí

208
Q

Produktové SW metriky

A

1) Velikost
 počet UC, funkčních bodů
 LOC (= lines of codes): možná někdy případně i také
=> SLOC, DSLOC, CBLOC, TLOC

2) Složitost, přehlednost
 McCabe cyclomatic complexity
 fan-in / fan-out (afferent / efferent coupling) => stabilita
 weighted method per class
 lack of cohesion
3) Spolehlivost
 MTBF = MTTF + MTTR
MTTF = střední doba poruchy
MTTR = střední doba opravy
MTBF = střední doba mezi poruchami
(meantime between failures)
 dostupnost [%] = (MTTF / MTBF) x 100
 dostupnost typická proxi pro spolehlivost

4) Kvalita
 pokrytí testy – kódu, požadavků
 charakteristiky defektů – hustota, výskyt
 kvalita zdrojového kódu – četnost chyb PMD/FindBugs
 složitost kódu

209
Q

Procesní metriky

A 
1) Postup
 pracnost
 project velocity / burndown
 burnup – sledování dostupných zdrojů
 jitter – change requesty a jejich zpracování, staff turnover, změny postupu/plánu

2) Kvalita (procesní stránka)
 breakage = průměrná váha změny (LOC / CR)
 pracnost celkem, přepočtená na CR
 defect discovery rate, defect removal (zpracování, trendy)
 průměrná doba opravy

=defect discovery (úroveň testování X úroveň SW) => co mi ta veličina říká

210
Q

Nástroje pro měření

A

Procesní
 ALM
 kalendář

Produktové
 statsvn
 junit a cobertura

 databáze
 spreadsheet
 Stata, IBM SPSS apod.

211
Q

Plánování a řízení měření

A

Organizational focus jako východisko
 management musí chtít „evidence-based process“

Plán měření = proč měřit, co měřit, jak měřit, jak s daty
pracovat, jaké akce provádět s výsledky
 definice metrik, jejich význam a zpracování – připravit lidi
 způsob získání dat – připravit nástroje

Sledování projektu a produktu
 automatické získávání a vyhodnocování
 sledování (management)
 korektivní akce

 Komplexní přístup: „Program měření“
 Lightweight přístup (agile): „Měřit za pochodu“

Ukazatele (metriky) samy o sobě „k ničemu“
 cílem je informace (trend, statistika) => odhalování příčin => reakce

Přístup k měření – ve firmě
 proč měřit
 jak s daty pracovat

Plán měření – pro projekt
 co měřit
 jak měřit
 akce při zjištění nesouladu

Techniky
 GQM
 zasévání chyb

212
Q

Goal-Question-Metric (vykřičník)

A

 Goal – problém + cíl měřicího programu
 Question – měřené objekty a způsob měření
 Metric – konkretizují získávaná data

G: Zlepšit spravedlivost v oceňování práce na projektu
Q: Kolik práce odvádí jednotliví členové týmu?
M: Počet řádek uložených v svn; Váha uzavřených tasků v bugtrackeru (součty severity*effort)

213
Q

Co je řízení jakosti

A

6.5.1.1 Identifikovat, monitorovat a kontrolovat všechny činnosti, jak technické tak manažerské, které jsou nezbytné pro zajištění toho, že software dosáhne požadované kvality.

To je nezbytné pro poskytnutí požadované kvalitativní obrany proti systematickým vadám a pro zajištění možnosti provádět audity, aby mohly byt verifikační a validační činnosti prováděny efektivně.

6.5.1.2 Poskytnout důkaz, že výše zmíněné činnosti jsou prováděny.

214
Q

Proč systémy řízení jakosti

A

Snaha o kvalitu výroby (práce) systematicky na úrovni celé organizace
 nestačí spoléhat na snahu jednotlivců

Problém se týká všech oblastí podnikání
 výrobní odvětví (vč. softwarového průmyslu)
 doprava a logistika
 ostatní služby
 kontrola výrobků a služeb
215
Q

Přístup systémového řízení jakosti

A

Premisa: pokud je kvalitní proces návrhu a výroby, bude kvalitní i produkt

QA systém = soustava organizačních postupů a technických nástrojů, které mají zajistit tvorbu kvalitních produktů či poskytování kvalitních služeb (tj. to, že budou odpovídat požadavkům)
 proaktivní přístup: snaha zajistit správnost výrobků během vývoje a výroby, nikoli až odstraňováním nekvalitních při výstupní kontrole
 zvláště významné pro software (vývoj vs výroba)

216
Q

Složky systémů řízení jakosti (vykřičník)

A

 Systém se týká celé organizace => všech pracovníků

Organizační prvky
 podpora vedení
 Manažer + Oddělení pro otázky kvality
 Interní kontroly – dokumentace, postupů

Postupy
 např. automatizované testování

Dokumentace
 normy a záznamy
 Standardy a definice – obecný popis (vlastností) systému
 Politika jakosti – přístup ke kvalitě
 Příručka jakosti – popis procedur
 Plány pro celý vývojový cyklus
 Záznamy – o dosažené kvalitě, průběhu vývoje, vzdělávání, …

Audit
 důkaz o kvalitě pro zákazníky/klienty
 Certifikační (registrační)
 Průběžný – periodická kontrola

217
Q

Software Process Improvement

A

Aims to understand the software process as it is used within an organisation and thus drive the implementation of changes to that process to achieve specific goals such as increasing development speed, higher product quality or reducing costs.

 The key purpose of process assessment (or “appraisal”, “capability evaluation”) is to determine whether a process satisfies the criteria at a given level and identify process activities and combinations that need to be modified to better achieve project goals.

 SEPG = software engineering process group = skupina, která se stará o SPI

 Capability maturity models = guides for assessment and (incremental) improvement

FAV (46 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions