Analýza 3 část

1. ANALÝZA
První krok nejen při vývoji softwaru
3- část
2015 Aktualizovaná verze
Martin Paták

2. Minule jsme prošli
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

3. Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny
Minule a předminule jsme prošli

4. Analýza požadavků
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

5. Zachmanův model
Data
(What)
Function
(How)
Network
(Where)
People
(Who)
Time
(When)
Motivation
(Why)
Scope
(Lvl. 1)
Entity Process List Locations of the
Enterprise
List of
Organizations/
Divisions
Major Business
Events or
Cycles
Business
Strategy
Business Model
(Lvl. 2)
Entity/
Relationship
Overall Process
Model
Interactions
between
locations
Org Chart, List
of Roles
Detailed
Schedule
Business Plan,
Project
Objectives
System Model
(Lvl. 3)
Logical Data
Model
Detailed
Process
Description
Detailed
Interaction
Model
Entity History,
Processing
Business Rule
Model
Technology
Model
(Lvl. 4)
User Interface
Design and
Flow
Business Rule
Design
Detailed
Representation
(Lvl. 5)
Detailed UI,
Security
Business Rule
Specification

6. BABOK
http://www.theiiba.org/

7. BABOK

8. Techniky
 Procesní přístup
 Prototypový přístup
 Use case přístup
 Objektový přístup
 Kontextový přístup
Vždy jde jen o to který
z pohledů je hlavní,
nikdy ovšem není sám.

9. Vizuální modelování je
komunikační nástroj
OBCHODEM
IT

10. Vizuální Modelování
 Umožňuje rychlou orientaci v systému
 Pomáhá definovat architekturu softwaru
 Pomáhá identifikovat znovupoužitelné části
 Srozumitelné i pro netechnické členy týmu

11. Vizuální modelování umožní
naleznout a definovat
Procesy
Funkce
Omezení
Vlastnosti
Role

12.  standard pro modelování systémů
 UML není metodikou pro vývoj SW
 Závazná vizuální notaci
UML

13. Diagramy - druhy
Strukturální diagramy – jaké jsou součásti systému
Diagramy chování – co se má v systému dít
Interakční diagramy – tok dat a rozdělení ovládání
součástí systému

14. Diagramy - struktura
Použití jednotlivých diagramů je závislé na konkrétních
potřebách daného projektu.

15. Úroveň detailu
 Analytická (business, koncepční …)
 Designová (technická, architektonická …)

16. Use Case Diagram
Use Case
Use Case má grafickou část – Diagram
a textovou část – Description / Popis
Zobrazuje funkcionalitu systému
ud Use Case Model
Zákazník
Výběr zboží
Nákup vybraného
zboží
Zaplacení

17. Use Case Diagram
Extend znamená, že daný UC je
někdy použit; při splnění daných
podmínek
Include znamená, že daný UC je
vždy použit, zahrnut
ud Use Case Model
Actor2
Use Case2
Use Case3
Use Case4
«extend»
«include»

18. • Výchozí podmínky - Precondition:
• Základní tok událostí - Basic Flow:
Pouze jeden
• Alternativní tok událostí - Alternative Flow
Více
• Chybový tok událostí - Exception Flow:
Více
• Závěrečné podmínky - Postcondition:
Popis Use Case

19. Plánování vývoje pomocí UC
 Iterace jsou nejčastěji plánovány na základě modelu
případů užití
 Pro iteraci je vybrána množina případů užití (případně jejich scénářů)
 Inkrementální rozšiřování v dalších iteracích
 Dříve implementujeme ty případy užití, které představují
riziko
 Usuzujeme podle hodnot atributů
 Nezapomínáme na ostatní požadavky (výkon, spolehlivost, použitelnost,
technologie)
 Kriteria pro plánování podle případů užití:
 Neznámá implementace
 Opakující se problém (typové řešení)
 „Nutně potřebná“ funkcionalita

20. Příklad
Na základě textu (Příp. studie II):
 Definujte aktory
 Najděte všechny UC
 Vytvořte Use case diagram

21. UML má omezení v rámci modelování „strategických“
procesů
Pro modelování procesů v „čistém“ UML se používá
diagram aktivit.
Procesy a UML

22. Penker - Ericsson
cd skolaQ
Activity2
Actor1
Event1
Object1
Object2
Entity1
Object3
Object4

23. Penker - Ericsson
od Kontakt s klientem banky.
Příchod
klienta do
banky
Přivítání klienta
bankovním poradcem
Zjištění důvodu
kontaktování banky
klientem
Důvod
kontaktu
Telefonický
kontakt s
klientem
IS - nalezení klienta
banky
Vyhledání informaci o
klientovi v IS

24. BPMN a UML
BPMN (Business Process Modeling Notation UML
poskytují různé pohledy na daný systém a vzájemně
doplňují
Tam kde se BPMN zaměřuje na procesy,
UML se zaměřuje na softwarový design
UML používá objektově-orientovaný přístup pro
modelování
BPMN používán procesně-orientovaný přístup pro
modelování

25. BPMN
Příklad BPMN diagramu:
od Business Process Model
žádost o půjčku
Vyžádání údajů o
klientovi
Vyžádání údajů o
půjčce
Vyhodnocení informací Poskytnutí půjčkyDoplnění informací
Zamítnutí půjčky
Vypršel čas pro
doplnění informací

26. Procesy
 Hlavní
 Vedlejší
 Klíčové
 Podpůrné

27. Procesy
 Proces
 Sub-proces
 Aktivita

28. Modelovací nástroje
 Enterprise Architect
 Rational Rose
 Component Architect
 Magic Draw
 Aris
 MS Visio
 Poseidon http://gentleware.com/index.php

29. Rozdíly a příklady
Proces dle MS Visio
<Function><Function> <Function><Function><Function><Function>
Aktivta
Aktivita
Výstup
Aktivia
Actor
UseCase1
UseCase2
«extends»
UseCase3
«uses»
MS Visio 2003
Enterprise Architect 6.1
cd UCM
Actor1
Use Case1
Use Case3
Use Case2
«extend»
«include»

30. Zdroje
Web
SparxSystems http://sparxsystems.com.au/resources/tutorial/
IBM (Rational) http://www-306.ibm.com/software/rational/uml/
OMG http://www.omg.org/
UML - Web Links http://www.michael-thomas.com/tech/uml/
UML Links and References http://theopensourcery.com/osumlref.htm
Knihy
UML Distilled, Addison Wesley ISBN: 0-321-19368-7
UML Bible, Wiley, ISBN: 0764526049

31. Obsah
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

32. Jak získat dokonalé požadavky
Revidujeme požadavky
 Revidujte formálně a neformálně, včas a často
 Používejte checklist, který pomůže najít nedostatky v
požadavcích
 Zajistěte, aby všechny požadavky byly v souladu s
vymezeným rozsahem
 Zkontrolujte charakteristiky pro dokonalé požadavky - SMART

33. Jak získat dokonalé požadavky
Revidujeme požadavky
 Zajistěte, aby všechny požadavky sloužily jako základ pro
vývoj
 Zkontrolujte podmínky pro výjimky a řešení chyb
 Oprostěte se od architektury a vývoje
(kromě omezení)
 Účastníci: analytik, zástupce zákazníka, designer, tester,
projekt leader, autor uživatelské dokumentace

34. Úroveň review
Úroveň Min. Min. celkem Hodin MD (8h)
1 5 5 0,1 0,0
2 10 10 0,2 0,0
3 20 20 0,3 0,0
4 40 40 0,7 0,1
Stran 1

35. Příklad
Úroveň Min. Min. celkem Hodin MD (8h)
1 5 150 2,5 0,3
2 10 300 5,0 0,6
3 20 600 10,0 1,3
4 40 1200 20,0 2,5
Stran 30

36. Změny
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

37. Důvody pro změny
 Nové požadavky
 Nové informace o „starých“ požadavcích
 Změna technologie
 Změna vlastníka požadavků nebo jiného stk.
 Změna „business“ prostředí
 Změny v TC (rozsah, čas, rozpočet)

38. Proces změny požadavků
 Analýza změny
 Definice dopadů
 Úprava, zamítnutí změny

39. Změnový požadavek
 Důvod změny
 Priorita
 Dopady
 Rizika
 Popis změny
 Vazba na ostatní požadavky

40. Konec
Děkuji za pozornost
martin.patak@cleverlance.com