FAV > ASWI > Flashcards

ASWI Flashcards

(217 cards)

Study These 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
Ortogonální charakteristy výběru procesu pro projekt
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 ```
26
Rozdíl program / produkt / systém
Program -> Produkt -> Systém | Při každém přechodu výš cca 3x obtížnější
27
Úrovně flexibility při volbě SW procesu
0. Principy 1. Metodiky a standardy 2. Software process improvement 3. Vlastní ad-hod úpravy
28
Jak funguje iterativní vývoj
- 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)
29
Průběh iterace (vykřičník)
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ů
30
Parametry: počet a délka iterací
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
31
Techniky: Pravidla pro iterace
- 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á)
32
Techniky: Předání a zhodnocení (iterativní vývoj)
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
33
Kontext iterace v procesu vývoje
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
34
Globální řízení: milníky => fáze (vykřičník)
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
35
Výhody iterativního vývoje oproti sekvenčnímu
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
36
Fáze vývoje a charakter iterací
 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
37
PDCA
Metodika Plan - Do - Check - Adapt (act) Každá iterace PDCA cyklus
38
Význam plánování (eisenhower)
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ů.
39
Základní fakta o plánování
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)
40
Prediktivní plánování
- 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
41
Adaptivní plánování
 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
42
Stupně volnosti při plánování (vykřičník)
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
43
Estimate vs Commitment při plánování
- 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
44
Techniky pro plánování
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ů
45
Určení rozsahu při plánování
= 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
46
Určení kvality při plánování
```  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.“
47
Určení času při plánování
„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
48
Odhadování pracnosti
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
49
Určení nákladů při plánování
- 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
50
Určení pořadí aktivit a termínů
„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
51
Okamžiky pro adaptivní plánování
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
52
Plánování projektu v iterativním vývoji
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í
53
Plánování iterace
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
54
Zpřesňování požadavků
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
55
Úkoly (Work Item, Task)
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
56
Tradiční přístup: Iteration Plan (Dokument jako plán)
Obsah  úkoly k realizaci funkčnosti  opravy chyb  organizační atd aktivity - Odhad pracnosti a alokace zdrojů - Priorita, návaznosti - Dokument
57
Agilní metodiky: Backlog jako plán (vykřičník)
``` 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
58
Zkratka DEEP:
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. 2. 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 3. 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. 4. 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.
59
Vztah produktového backlogu a iteračním backlogem
Iterační backlog je mapován na položky v produktovém backlogu
60
Štíhlé přístupy
Kanban board TODO - DOING - DONE - průběžný vývoj - toto je třeba udělat, kdo má zrovna čas pracuje na úkolu
61
Sledování průběhu (plánu)
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“
62
Komunikace pro sledování postupu
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
63
Burndown chart (vykřičník)
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
64
Úprava postupu
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
65
Určení výkonnosti týmu
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í)
66
Fáze zahájení: Přehled a cíle
 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
67
Role analytika ve fázi zahájení
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é
68
Charakteristiky fáze zahájení
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
69
Fáze projektování: Přehled a cíle
 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
70
Fáze zahájení: Klíčové disciplíny a aktivity
``` 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
71
Fáze projektování: Klíčové disciplíny a aktivity
``` 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
72
Role analytika ve fázi projektování
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
73
Požadavky: co, proč, kdy
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“
74
Požadavek definice
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
75
Účel specifikace požadavků:
 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
76
Typy požadavků (vykřičník)
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)
77
Kategorie funkčních požadavků
``` 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
78
Lidé v analýze
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
79
Postup práce s požadavky (vykřičník)
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ů)
80
Účel definice systému
 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
81
Rozsah definice systému
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] ```
82
Kontextový model (definice systému)
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
83
Vize produktu a rozsah projektu
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, …
84
Vize produktu: kostra (vykřičník)
 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í
85
Use Case - definice
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ý
86
Definice systému s případy užití (vykřičník)
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í
87
Glosář
Seznam důležitých pojmů Faktura -> něco jiného pro zákazníka, firmu, finanční úřad
88
Doménový model (vykřičník)
Č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
Základní popis případu užití (vykřičník)
… 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
Prostředí: Fyzický rozsah systému (vykřičník)
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
Diagram nasazení
- 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
Cíl agilních specifikací požadavků
 Ří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
User Story (vykřičník)
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
Produktový backlog vztah k velikosti úkolů (vykřičník)
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
Způsoby získávání požadavků
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
Pro podrobnou specifikaci požadavků může být potřeba popsat cokoli z …
```  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
Detailní analýza požadavků ve fázi projektování
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
Podrobný popis případu užití (vykřičník)
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
INVEST u user stories
• 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
FURPS+
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
Reprezentace vlastností (mimofukční požadavky)
Úč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
Procesní modely
 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
Prototyp uživatelského rozhraní
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
Vývoj datových entit
(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
CRUD(L) matice
 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
Formy specifikace požadavků
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
Architektura systému - definice
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
Stupně volnosti při tvorbě architektury
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
4 + 1 model (vykřičník)
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
Logický pohled (4+1)
 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
Architektonické styly
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
Vrstvená architektura
 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
Servisně orientované styly
- 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
Fyzický pohled (4+1)
 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
Vývojový pohled (4+1)
``` 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
4+1 - S čím pracuji v logickém, vývojovém a fyzickém pohledu
 Logický pohled: subsystémy, balíky => diagramy tříd  Vývojový pohled: projekty, adresáře, sestavení  Fyzický pohled: moduly, komponenty, knihovny
117
Konvence a politiky
„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
Procesní pohled (4+1)
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
Jak tvořit návrh architektury
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
Jak ověřit návrh architektury (máme více návrhů)
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
Validace architektury (vykřičník)
- 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
Význam scénářů v 4+1
Mít specifikovány architektonicky důležité požadavky (cca 20 %), na kterých ověřím správnost architektury
123
Dokumentace architektury
1) Dokument 2) Modely (diagramy X CASE) 3) Kostra aplikace (referenční architektura)
124
Zdůvodnění arch. rozhodnutí
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
Fáze konstrukce: Klíčové disciplíny a aktivity
``` 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
Výchozí problém(y) a motivace konfiguračního řízení
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
Konfigurační management definice
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
Konfigurace - definice
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
Prvek konfigurace - definice
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
Vztahy v konfiguraci
1) celek-část, master-dependent - > určují strukturu a závislosti 2) zdrojový-odvozený - > určují způsob produkce, tj. build produktu
131
Úlohy SCM
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
Aktivity SCM v cyklu vývoje
1) Správa změn 2) Identifikace a správa verzí 3) Sestavení
133
Správa změn (SCM)
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
Ticket, požadavek na změnu (SCM)
 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
Proces správy změn (vykřičník)
!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
Detaily ticketu
``` 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
Případy nouze při změnovém řízení
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
Change Control Board
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
Správa změn a řízení projektu
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
Správa změn a verzování
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
Správa změn a požadavky
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
Správa změn a údržba
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
Systémy pro správu změn
``` 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
Správa verzí - charakteristika
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
Typy verzí (vykřičník)
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
Granularita verzování
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
Identifikace konkrétní verze
``` 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
Informace o verzi
 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
Nástroje pro verzování
 Ú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
Práce s úložištěm
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
Centrální vs distribuovaný vývoj
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
workspace
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
Delta, Changeset (verzování)
 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
Tag (verzování)
Tag, label = označení konfigurace symbolickým jménem  štítek  různé způsoby realizace
155
Baseline (verzování)
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
Paralelní práce
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
Větvení a spojování
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
Codeline (vykřičník)
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
Vzory pro verzování
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
Řízení sestavení
 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
Sestavení: proces (kroky) (vykřičník)
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
Sestavení: pravidla (vykřičník)
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
Součásti prostředí pro sestavení
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
Typy sestavení (vykřičník)
Liší se: 1) Obsahem sestavení  přírůstkový (inkrementální) build  čistý  úplný 2) Účelem sestavení  soukromý  integrační (oficiální)  release build
165
Vzory pro sestavení
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
Soukromé sestavení - vzor pro sestavení (jen prolétnout)
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
Integrační sestavení - vzor pro sestavení (jen prolétnout)
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
Kusovník - vzor pro sestavení (jen prolétnout)
 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
Archivace prostředí - vzor pro sestavení (jen prolétnout)
 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
Release build - vzor pro sestavení (jen prolétnout)
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
Daily Build and Smoke test (vykřičník)
=> 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
Continuous Integration
Integrace 1x denně => neustálie  Klíč: automatizace  co/ci, sestavení, testování, oznamování  robot na spouštění
173
Fáze předání: Přehled a cíle
(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
Fáze předání: Klíčové aktivity a disciplíny
- 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
Fáze předání: Charakteristika
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
Příprava vydání (vykřičník) (aktivity + role)
``` 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
Akceptační řízení
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
Uzávěrka projektu
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
Pojmy CI / CD
 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
Důvody pro CD
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
Přístup CD (principy)
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
DevOps
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
CD jako proces životního cyklu
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
Provoz a podpora produktu (vykřičník)
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
Údržba produktu (vykřičník)
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
Discipliny pro enterprise kontext
= 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
Vyřazení produktu
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
Postup vyřazení z provozu (vykřičník)
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
Jaký software je „kvalitní“
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
ISO 25010 Software Quality Model
```  Functional Suitability  Performance Efficiency  Compatibility  Usability  Reliability  Security  Maintainability  Portability ```
191
Úroveň dosahované kvality
Š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
Opak kvality: geneze selhání sw
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
Řetězení a cena chyb
 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
Způsoby zajištění kvality (vykřičník)
 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
Testování
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
Smoke Test
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
Regresní testy
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
Statická kontrola kódu
 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
Formální verifikace
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
Preventivní techniky (vykřičník)
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
Technická oponentura
 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
Technická oponentura – postup
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
„Lehčí“ techniky technické oponentury
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
Statistické řízení procesu
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
Účel měření v software
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
Teorie měření (definice metriky, hodnoty, očekávání x skutečnost) (vykřičník)
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
Druhy metrik v SWI
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
Produktové SW metriky
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
Procesní metriky
``` 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
Nástroje pro měření
Procesní  ALM  kalendář Produktové  statsvn  junit a cobertura  databáze  spreadsheet  Stata, IBM SPSS apod.
211
Plánování a řízení měření
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
Goal-Question-Metric (vykřičník)
 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
Co je řízení jakosti
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
Proč systémy řízení jakosti
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
Přístup systémového řízení jakosti
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
Složky systémů řízení jakosti (vykřičník)
 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
Software Process Improvement
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
flashcards
Decks in class (46)
# Cards
Brainscape helps you reach your goals faster, through stronger study habits.
© 2026 Bold Learning Solutions. Terms and Conditions