Metodiky vývoje SW. Taxonomie metodik. Metodiky pro softwarový proces. Moderní strukturovaná analýza. Unifikovaný proces vývoje (UP) Klasické

Metodiky pro softwarový proces

Metodiky vývoje SW

Co to je softwarový proces – umění, manufaktura, modelování? Proces vývoje software by se měl řídit nějakým doporučením – sníží se tím pravděpodobnost chyb, opomenutí apod. Doporučení jsou obvykle shrnuta do metodiky (angl. methodology). Metodika je jen šablona, musíme ji přizpůsobit firmě, týmu, projektu, účelu (vývoj, provoz, přizpůsobení). Metodika předepisuje postup, jeho kroky a artefakty získané v těchto krocích. Skutečný proces vývoje pak využívá různé standardy, idiomy, předepsané formáty apod.

Richta: ZSI - Proces vývoje

Taxonomie metodik

Moderní strukturovaná analýza

Klasické

Strukturované, objektové, komponentové

Vodopád

(MSA, SSADM) Unifikovaný proces (UP) RUP (Rational Unified Process)

Agilní

Testy

řízený vývoj Extrémní programování (XP) Scrum AUP (Agile Unified Process)


3

Autoři E.Yourdon (analýza), M.Page-Jones (návrh). Sestavte aktéry a případy užití. Pro každý případ užití navrhněte funkci, která bude tento případ obsluhovat. Doplňte model o popis dat – pro každou funkci vymysli vstupní a výstupní data. Proveďte generalizaci a dekompozici těchto funkcí. Generalizací dospějete k modelu jednání, dekompozicí k elementárním funkcím (minispecifikacím). Tento výstup analýzy podrob tzv. transformační analýze (založené na transakční analýze) a navrhni řešení. Transakční analýzou vyber podmnožinu, která se zabývá jednou transakcí. V této podmnožině hledej vstupní úpravy, vlastní zpracování a výstupní formátování dat.


«centralBuffer» Model j ednání

UP je:

Náv rh funkcí

Generalizace

«centralBuffer» Model chov ání

«centralBuffer» Doplnění dat

Datov ý model

Dekompzice

Transakční analýza

«centralBuffer» Transformační analýza

Logický model

Řízen požadavky a případy užití (use case driven) Řízen rizikem Staví na architektuře Iterativní a přírůstkový proces

UP je:

5

Průmyslový standard kostry vývojového procesu Využívá notace UML (Unified Modeling Language) Je to otevřený standard (na rozdíl např. od RUP – Rational Unified Process, dříve Rational, nyní IBM) Základem je publikace Jacobson, Booch, Rumbaugh: „The Unified Software Development Process"

UP je:


4

Unifikovaný proces vývoje (UP)

act Moderní strukturov aná analýza (MSA)

Hledání aktérů a případů užití

2

pouze generická metodika, musí být uzpůsobena pro danou firmu, projekt - standardy, šablony, nástroje, …


6

Iterační a přírůstkový vývoj

Historie UP

Iterace jsou základem UP Každá iterace je malý vodopád:

Rational Unified Specification Rational Ongoing Ericsson Rational Unified Software RUP & Description Objectory Objectory RUP Approach Approach Process Development 2001 Language Process development (RUP) Process

Prehistory

1967

1976

1987

1997

1995

1998

1999

2001

2004

Jacobson working at Ericsson

Jacobson establishes Objectory AB

Rational acquires Objectory AB

UML becomes an industry standard

Plánování Analýza a návrh Konstrukce, implementace Integrace a testování Uvolnění verze

Celý produkt se tvoří řadou iterací, které představují přírůstky k řešení Iterace se mohou překrývat (paralelní vývoj) Iterace jsou rozděleny do fází, každá fáze může zahrnovat několik iterací, každá fáze končí milníkem

Zdroj: © Arlow, Neustadt: UML 2 a objektově orientovaný návrh. Richta: ZSI - Proces vývoje

7


8

Kroky v rámci iterace

Fáze UP

Každá iterace může obsahovat základní kroky a další postupy, podle její polohy v životním cyklu. UP specifikuje 5 základních kroků

Požadavky

Analýza

Návrh

Implementace

Testy

Iterace

Plánování

Zdroj: © Jacobson, Booch, Rumbaugh: The Unified Process. Richta: ZSI - Proces vývoje

9

Požadavky a jejich metamodel

Popisovač případů

Funkční požadavky Katalog požadavků Nefunkční požadavky

balík ikona kotvy Model jednání (Use case model)

P1

P2

Návrhář UI

Specifikace požadavků na software

Další postupy

10

act Postup tv orby specifikace požadav ků

Analytik

Odhady

Postup získávání požadavků

Smyslem tohoto kroku je vytvořit přehledovou („high-level“) specifikaci toho, co se má implementovat. Sháníme materiály, děláme interview se zainteresovanými osobami („stakeholders“), abychom zjistili, co by od systému potřebovali – jaké jsou jejich požadavky.

Architekt


Specifické postupy

P3


Strukturov ání modelu případů užití

Stanov ení priorit

Detailní popis případů užití

Náv rh a prototypov ání interface

případ užití (use case) aktér


11


12

Důležitost požadavků

act Postup tv orby specifikace požadav ků - 2

Analytik

A navíc


Strukturov ání modelu případů užití

Zdroje chyb projektů Architekt

Neúplné požadavky Stanov ení priorit

Popisovač případů

Uživatel nebyl dostatečně zainteresován Nedostatek zdrojů

Detailní popis případů užití

Nerealistická očekávání Náv rh a prototypov ání interface

Správce požadavků

Návrhář UI

Mapov ání požadav ků na případy užití

Chybí podpora exekutivy Náv rh funkčních požadav ků

Změny požadavků

Náv rh nefunkčních požadav ků

Pro správnou správu požadavků je třeba přidat aktivity související s návrhem funkčních a nefunkčních požadavků a jejich zapracováním do modelu Richta: ZSI - Proces vývoje

The <system> shall

Jaké chování bude systém nabízet. Specifické vlastnosti systému. Jaká omezení je třeba brát v úvahu.

Unikátní identifikátor Jméno systému keyword

Na počátku procesu konstrukce softwaru je dohoda o požadavcích mezi všemi zainteresovanými stranami. Katalog požadavků by měl být rozumně organizován do částí, které spolu souvisí. Model požadavků, kam patří funkční a nefunkční požadavky. Model jednání (use case model), kam patří přehled aktérů a případů užití (use cases).


Požadavek

Např. "32 Bankomat by měl validovat PIN."

SRS obsahuje dvě části:

14

Jak požadavky zapisovat?

V metodice UP se vytváří specifikace požadavků (Software Requirements Specification - SRS):


Požadavky - “Specifikace toho, co by mělo být implementováno”:

Není dále zapotřebí

The Standish Group, "The CHAOS Report (1994) " 13

Co to jsou požadavky?

Nedostatek plánování

Neúplná specifikace požadavků představuje primární zdroj možného neúspěchu projektu!

Stanov ení priorit

Není žádný obecný standard na psaní požadavků!

Funkční požadavky – co by měl systém dělat:

Nefunkční požadavky – omezení na způsob konstrukce a implementace:

15

Modelování případů užití

Doporučuje se např. formát výše uvedený. „Bankomat by měl poskytovat možnost identifikace zákazníka."

„Bankomat by měl identifikaci zákazníka zvládnout vždy nejdéle za 4 sec."


16


Součástí

modelování a správy požadavků by mělo být i modelování případů užití. Modelování případů užití spočívá v hledání: hranice

Doménový (business) model

Analytik

Model požadavků


Hrubý model jednání

systému

aktérů, případů

užití (use cases)

specifikace případů a scénářů, které se za nimi skrývají.

To

nám umožní definovat rozsah systému, kdo a na co jej má používat. Seznam požadovaných vlastností


17


Glosář projektu (datový slovník)

18

Subjekt, aktéři, případy užití

Předtím, než budeme cokoliv vytvářet, měli bychom znát:

Diagram případů užití

kde leží hranice systému, kdo nebo co bude systém užívat, jaké služby bude systém uživatelům nabízet.

Mail Order System use case diagram subject name

Mail Order System

subjekt communication relationship

JménoSystému

system boundary Place Order

Do modelu jednání vložíme:

Subjekt – hranici systému Aktéry – kdo se systémem komunikuje Případy užití – na co jej používá Vztahy mezi aktéry a případy užití.

Ship Product

Cancel Order

ShippingCompany Customer

Check Order Status Send Catalogue

actor

use case Dispatcher


19

Glosář projektu

Project Glossary Termín1

Definice Synonyma Homonyma

Termín2 Definice Synonyma Homonyma Termín3 Definice Synonyma Homonyma


20

Detailní popis případů užití V každé doméně existuje žargon, proto doplňujeme modely glosářem. Smyslem glosáře je definovat synonyma a homonyma. Vytváříte slovník pro potřeby diskuse se zainteresovanými osobami, které mohou používat žargon dané domény.

Model jednání [hrubý]

Popisovač případů užití (use case specifier)

Doplňující požadavky

Popis detailů případů užití

Případ užití (detailní popis)

… Glosář


21

Use case: PaySalesTax

use case identifier

ID: 1

brief description

Brief description: Pay Sales Tax to the Tax Authority at the end of the business quarter.

the actors involved in the use case

Primary actors: Time

Secondary actors: TaxAuthority the system state before the use case can begin

the actual steps of the use case

implicit time actor

1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of Sales Tax owed to the Tax Authority. 3. The system sends an electronic payment to the Tax Authority.

the system state when the use case has finished

Postconditions: 1. The Tax Authority receives the correct amount of Sales Tax.

alternative flows

Alternative flows: None.


Preconditions: 1. It is the end of the business quarter. Main flow:

22

Předpoklady a důsledky

Detailní specifikace případů užití use case name


23

Předpoklady (preconditions) a důsledky (postconditions) představují omezení. Předpoklady omezují stav systému před zahájením scénáře. Důsledky omezují stav systému po ukončení scénáře. Pokud nejso žádné předpoklady ani důsledky, je třeba to zdůraznit např. klíčovým slovem "None" pod hlavičkou.


Place Order Preconditions: 1. A valid user has logged on to the system

Postconditions: 1. The order has been marked confirmed and is saved by the system

24

Hlavní scénář

Větvení: If

<číslo> Scénář zachycuje posloupnost kroků v rámci zpracování případu užití. Vždy se začíná tím že aktér něco provede (iniciuje událost).

Dobrá technika je zahájit scénář: 1) Případ užití se spustí, když aktér -

Kroky scénáře by měly být :

Hlavní scénář by měl představovat úspěšné použití:

ID: 2 Brief description: The Customer changes the quantity of an item in the basket. Primary actors: Customer

There must be a Boolean expression immediately after if

Secondary actors: None.

Use indentation and numbering to indicate the conditional part of the flow Use else to indicate what happens if the condition is false (see next slide)

deklarativní, očíslované, uspořádané v čase.

Use case: ManageBasket

Use the keyword if to indicate alternatives within the flow of events

Vše probíhá podle očekávání, nenastaly chýby, odchylky, přerušení apod. Alternativní scénáře pak popisují tyto alternativy.

Preconditions: 1. The shopping basket contents are visible. Main flow: 1. The use case starts when the Customer selects an item in the basket. 2. If the Customer selects "delete item" 2.1 The system removes the item from the basket. 3. If the Customer types in a new quantity 3.1 The system updates the quantity of the item in the basket. Postconditions: None. Alternative flows: None.


25


Opakování: For

26

Opakování: While Use case: FindProduct

We can use the keyword For to indicate the start of a repetition within the flow of events The iteration expression immediately after For statement indicates the number of repetitions of the indented text beneath the For statement.

Use case: FindProduct

ID: 3

ID: 3

Brief description: The system finds some products based on Customer search criteria and displays them to the Customer. Actors: Customer Preconditions: None. Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. If the system finds some matching products then 5.1 For each product found 5.1.1. The system displays a thumbnail sketch of the product. 5.1.2. The system displays a summary of the product details. 5.1.3. The system displays the product price. 6. Else 6.1. The system tells the Customer that no matching products could be found.

We can use the keyword while to indicate that something repeats while some Boolean condition is true

Postconditions: None. Alternative flows: None.


27

Alternativy

We may specify one or more alternative flows through the flow of events:

Pick the most important alternative flows and document those. If there are groups of similar alternative flows - document one member of the group as an exemplar and (if necessary) add notes to this explaining how the others differ from it.


Primary actors: Customer Secondary actors: None Preconditions: None. Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. If the system finds some matching products then 5.1 For each product found 5.1.1. The system displays a thumbnail sketch of the product. 5.1.2. The system displays a summary of the product details. 5.1.3. The system displays the product price. 6. Else 6.1. The system tells the Customer that no matching products could be found. Postconditions: None. Alternative flows: None.


28

Referencování alternativ Use case: CreateNewCustomerAccount

Use case

Alternative flows capture errors, branches, and interrupts Alternative flows never return to the main flow

Potentially very many alternative flows! You need to manage this:

Brief description: The system finds some products based on Customer search criteria and displays them to the Customer.

alternative flows

main flow

List the names of the alternative flows at the end of the use case Find alternative flows by examining each step in the main flow and looking for:

Alternatives Exceptions Interrupts

Only document enough alternative flows to clarify the requirements!


Main flow: 1. The use case begins when the Customer selects "create new customer account". 2. While the Customer details are invalid 2.1. The system asks the Customer to enter his or her details comprising email address, password and password again for confirmation. 2.2 The system validates the Customer details. 3. The system creates a new account for the Customer. Postconditions: 1. A new account has been created for the Customer.

alternative flows 29

ID: 5 Brief description: The system creates a new account for the Customer. Primary actors: Customer Secondary actors: None. Preconditions: None.

Alternative flows: InvalidEmailAddress InvalidPassword Cancel

30

Příklad alternativy notice how we name and number alternative flows

Trasování požadavků

Alternative flow: CreateNewCustomerAccount:InvalidEmailAddress

ID: 5.1 Brief description: The system informs the Customer that they have entered an invalid email address.

Alternative flow: 1. The alternative flow begins after step 2.2. of the main flow. 2. The system informs the Customer that he or she entered an invalid email address.

always indicate how the alternative flow begins. In this case it starts after step 2.2 in the main flow

The alternative flow may be triggered instead of the main flow - started by an actor The alternative flow may be triggered after a particular step in the main flow - after The alternative flow may be triggered at any time during the main flow - at any time Richta: ZSI - Proces vývoje

31

Když u systému dominují funkční požadavky. Když systém poskytuje různou funkcionalitu různým aktérům. Pokud má systém rozmanitá rozhranní.

33

Struktura UP Požadavky (Life-cycle Objectives)

Milník


Elaborace

Beta verze (Initial Operational Capability)

Dodávka (Product Release)

Konstrukce

Přechod (Transition)

Pro každou fázi je nutno specifikovat:

Iterace

Iter 1

Proto se UP nazývá „iterativní a přírůstkové“.

34

Fáze Architektura (Life-cycle Architecture)

Incepce

Fáze

Představují dohodnutý základ pro další vývoj Mohou mýt měněny jen na základě formalizovaných postupů – konfigurace a změnové řízení.

Přírůstek je rozdíl mezi dvěma následujícími dodávkami.


32

Každá iterace produkuje dodávku. Dodávka je sada revidovaných a ověřených artefaktů, které:

Když u systému dominují nefunkční požadavky. Pokud má systém jen málo aktérů. Pokud má systém jednoduchá rozhranní.

Requirements Traceability Matrix

With UML tagged values, we can assign numbered requirements to use cases We can capture use case names in our Requirements Database

If there is no CASE support, we can create a Requirements Traceability matrix

Případy užití specifikují chování z hlediska poskytovaných funkcí. Nejsou vhodné:

R1 R2 R3 R4 R5


Případy užití popisují systém z pohledu aktérů. To je vhodné:

Use cases U1 U2 U3 U4

Dodávky a přírůstky

Kdy používat analýzu případů užití?

Hopefully we have CASE support for requirements tracing:

Postconditions: None.

One use case covers many individual functional requirements One functional requirement may be realised by many use cases

Requirements

Primary actors: Customer Secondary actors: None. Preconditions: 1. The Customer has entered an invalid email address

Given that we can capture functional requirements in a requirements model and in a use case model we need some way of relating the two There is a many-to-many relationship between requirements and use cases:

Iter 2

Iter 3

Iter 4

Iter 5

Iter 6

Základní postupy Cíl fáze Co je milník na konci fáze

Požadavky

Incepce

Elaborace

Konstrukce

Přechod

úsilí Analýza

Návrh

Implementace

5 základních P A N postupů

I

T

…

…

…

…

… Testy

Každá fáze může zahrnovat několik iterací.

Skutečný počet závisí na rozsahu projektu, u malých projektů může mít fáze jen jednu iteraci.

Předběžné iterace

I1

I2

In

In+1

In+2

Im

Im+1

Každá fáze končí milníkem.


35


36

Incepce

Milník – konec incepce

Relativní úsilí pro každý postup

P

(zahájení, úvodní studie) Požadavky – sestavit případy užití a rozsah. Vytipovat jejich důležitost.

A N I

Cíle projektu představující podmínky pro úspěšné řešení:

Incepce

Elaborace

Konstrukce

Přechod

Analýza – zhodnotit proveditelnost

Zaměřeno na

Návrh – ověření konceptu nebo technický prototyp

Implementace – ověření konceptu nebo technický prototyp

Testy – zde nemají smysl

Je určena hranice systému (system scope). Jsou definovány klíčové požadavky na systém a jsou schváleny zainteresovanými osobami (stakeholders). Existuje vize architektury systému, zatím jen hrubě. Je zpracována analýza rizik. Je zpracován odhad nákladů a výnosů (business case). Je povrzena proveditelnost projektu (feasibility study). Zainteresované osoby (stakeholders) souhlasí s objektivními charakteristikami projektu.

Cíle

Ověřit proveditelnost projektu – případně s využitím prototypů Sestavit požadavky a případy užití Vymezit hranici systému Identifikovat rizika Richta: ZSI - Proces vývoje

37

Elaborace


Milník – konec elaborace

P A N

I

T

(rozbor, analýza)

Je určena architektura :

Požadavky – zkompletovat požadabky a hranici

Incepce

Elaborace

Konstrukce

38

Přechod

Analýza – vymezení skutečného rozsahu

Zaměřeno na

Návrh – vytvoření stabilní architektury

Je definován robustní proveditelný, architektonický základ řešení. Je doplněna analýza rizik. Je vytvořen plán projektu, pro zajištění realistické představy o postupu. Obchodní plán je porovnán s plánem a původní představou. Zainteresované osoby (stakeholders) souhlasí s pokračováním.

Implementace – realizace základny pro architekturu Testy – testování architektonické základny

Cíle

Vytvoření a návrh architektury Vyhodnocení rizik Výběr 80% funkčních požadavků Vytvoření detailního plánu pro fázi konstrukce Formulace požadavků na zdroje, čas, vybavení, týmy a cenu Richta: ZSI - Proces vývoje

39

40

Milník - konec konstrukce

Konstrukce (návrh, implementace) Požadavky – objevování chybějících požadavků


P A Incepce

Elaborace

Konstrukce

N

I

T

Částečná funkčnost systému:

Produkt je připraven k beta-testování v prostředí uživatele.

Přechod

Analýza – dokončení analytického modelu

Zaměřeno na

Návrh – dokončení návrhového modelu

Implementace – vytvoření počáteční funkčnosti – beta verze Testy – testování beta verze

Cíle Richta: ZSI - Proces vývoje

Dokončení specifikace Dokončení analýzy, návrhu, implementace a testování Údržba integrity architektury systému Vyhodnocení rizik 41


42

Přechod

N

I

Milník – konec přechodu

T

(transition, provoz) Požadavky – nic

Incepce

Elaborace

Konstrukce

Produkt je k dispozici:

Přechod

Proběhlo beta-testování, akceptační test i opravy chyb. Produkt je uvolněn pro uživatele.

Analýza – nic

Zaměřeno na

Návrh – modifikace podle výsledků beta testů

Implementace – přizpůsobení softwaru prostředí uživatele, opravy chyb a beta testů Testy – akceptační testy v prostředí uživatele

Cíle

Opravy chyb Příprava prostředí uživatele a uzpůsobení softwaru tomuto prostředí Modifikace dle odhalených problémů Tvorba příruček a manuálů, dokumentace Poskytování konzultační podpory uživateli Vyhodnocení projektu


43

UP - shrnutí

Incepce Elaborace Konstrukce Přechod

Požadavky Analýza Návrh Implementace Testování


45

Extrémní programování (XP)

Psychologie týmu (http://agilemanifesto.org/) SCRUM (http://www.scrumalliance.org/) Crystal Clear (http://www.agilekiwi.com/crystal_clear.htm) XP - Extreme Programming (http://www.extremeprogramming.org/)

Každá fáze se skládá z jedné, či více iterací. Každá iterace má čtyři kroky:

44

Agilní metodiky

UP metodika založená na analýze případů užití, je řízena rizikem, soustředí se na architekturu. Jedná se o iterativní a přírůstkový proces. UP má 4 fáze:


46

Co to je XP?

Řízeno požadavky uživatelů (user stories) Používá metaforu pro budovaný systém Vyvíjí se v iteracích Pracuje se ve dvojici Co nejjednodušší návrh (neprogramujeme dopředu) Okamžité testování Refaktorizace kódu Kód je společný - standardy pro kódování Co nejrychlejší zpětná vazba, uživatel součástí vývojového týmu, minimum dokumentace Nepřehánět zátěž - 40 hodin týdně



47

Agilní technika vývoje softwaru, která dle „agilního manifestu“ upřednostňuje: Týmovou spolupráci a interakci před formálními procesy a nástroji. Fungující software před obsáhlou, komplexní dokumentací. Spolupráci mezi zákazníkem a vývojáři před specifikacemi, zadáními, dohodnutými kontrakty. Rychlou adaptaci na změny v zadání před dodržováním předem stanovených pravidel.


48

12 technik používaných v XP

Plánování hrou

Plánování hrou Malé dodávky (releases) Metafory Jednoduchý návrh Párové programování Intezivní testování Refaktorizace kódu Kolektivní vlastnictví kódu Spojitá intergace 40 hodin/týden Zákazník součástí týmu Kódové standardy


Software se vyvíjí v malých iteracích. Vyvíjí se vždy pouze to, co zákazník v danou chvíli potřebuje. Iterace se skládá z: Sepsání požadavků – user stories (zákazník) Rozdělení požadavků na úkoly (vývojáři) Časových odhadů jednotlivých úkolů (vývojáři) Určení priorit (zákazník) Programování (vývojáři) Akceptačních testů dle požadavků (zákazník)

49


Malé dodávky (releases)

Metafora

Na konci každé iterace (zpracování jednoho příběhu – user story) se vytvoří nová dodávka (release).

To znamená: Zákazník dostává poměrně často nové verze (jednou za dva týdny, týden, den). Existuje okamžitá zpětná vazba, neboť zákazník může software neustále testovat a připomínkovat. Zákazník má k dispozici funkční část softwaru velmi rychle a může ho začít používat.


51

Jednoduchý návrh

Jednoduchá paralela nebo příběh, který popisuje budovaný systém slovy a pojmy, které všichni zúčastnění intuitivně chápou. Slouží k lepšímu porozumění a komunikaci mezi členy týmu, vývojáři a zákazníky.


52

Párové programování

Scott W.Ambler: „Co přesně má software dělat a jak má vypadat víte v nejlepším případě až když ho potřetí přepisujete celý znova.“ Proto je vhodné udržovat návrh tak jednoduchý, jak to jde. Použít co nejjednodušší, který ještě splní akceptační testý. Neprogramovat pro budoucnost, netvořit „frameworky“, pokud to není nezbytně nutné.


50

53

Každá řádka kódu je napsána dvěma programátory u jednoho počítače s jedním monitorem a jednou klávesnicí. To zajišťuje: Vyšší spolehlivost kódu, neboť programátoři se kontrolují navzájem. Vyšší čitelnost a pochopitelnost kódu, neboť programátoři se kontrolují navzájem. Všeobecné povědomí všech vývojářů o celém kódu. Vzájemné učení se od sebe.


54

Testování

Refaktorizace

Neustálé testování je jedna z fundamentálních technik XP, bez testování nemůže XP fungovat. Vývojáři píší testy jednotek (unit tests) na každou komponentu vyvíjeného systému, dokonce na každou třídu, tyto testy se spouští neustále. Pokud neprochází všechny testy jednotek a akceptační testy pro daný příběh, nelze pokračovat ve vývoji.


55

Společné vlastnictví kódu

57

40 hodin týdně

56

Veškerý kód je zpřístupněn všem vývojářům ve společném repozitáři. Kdykoliv je vyřešen (naprogramován) a otestován nějaký úkol, je kód uložen do repozitáře.


58

Zákazník v týmu

Psychicky nebo intelektuálně unavený vývojář je: Nevýkonný Cybující Velmi „naštvaný“ Proto je nutné vývojovému týmu zajistit klid na práci, důstojné pracovní prostředí a hlavně je nepřetěžovat.



Neustálá integrace

Kterýkoliv vývojář v týmu využívajícím XP je oprávněn kdykoliv modifikovat kterýkoliv kus kódu, pokud po modifikaci procházejí testy.


Refaktorizace je technika zlepšování stávajícího kódu beze změny chování. Refaktoruje se kvůli: Zjednodušení kódu. Optimalizaci kódu. Lepší čitelnosti a pochopitelnosti kódu. Přidání nové funkcionality. Testy jednotek by měly zajistit, že se nezmění stávající chování.

59

Součástí týmu by měl být „on-site customer“, který představuje typického uživatele a je kdykoliv k dispozici vývojářům aby: Zodpovídal otázky vývojářů během práce Tvořil akceptační testy pro jednotlivé příběhy Testoval a podával zpětnou vazbu


60

Kódové standardy

Kdy se hodí XP?

Je nutné, aby všichni programátoři dodržovali stejné standardy: Stejné zarovnání kódu Stejné konvence pro identifikátory Stejně nastavené vývojové prostředí


61

Kdy se nehodí XP?

63

Metodika SCRUM (pojem z rugby)

62

XP představuje alternativu k vodopádovému modelu. Není to nekoordinované „hackování“ kódu zdivočelými programátory. Aby fungovalo, musí mít tým jisté zkušenosti a musí dodržovat všech 12 technik. XP není všelék, hodí se jen někdy, ale někdy může přinášet lepší výsledky za kratší čas.


64

SCRUM – základní principy

Žádné týmové hierarchie, tým do 7 osob, pracuje se v jedné místnosti (osmóza), tým si volí šéfa (scrum master) Krátké iterace (sprints) Plánovací schůzka před každou iterací Seznam akcí pro danou iteraci (backlog) Denní skrumáže (co jsem udělal, co budu dělat, jaké mám problémy) Retrospekce po každé iteraci (heartbeat session) Vlastníkem kódu je tým - standardy pro kódování



Srovnání

Když je nutný větší tým vývojářů (více než 15). Když je vývojový cyklus (oprava, překlad, sestavení spuštění) příliš dlouhý (5 minut, hodina). Když jsou testy příliš dlouhé (minuty, hodiny). Když nelze zákazníka dostat do týmu. Když zákazník nechápe principy XP.


Když je limitovaný čas nebo finance. Když zákazník není přesně co chce, nebo není schopen dodat dostatečně přesné zadání. Když zákazník chce spolupracovat na projektu. Když se ví, že se bude systém měnit. Když jsou členové týmu schopni spolupracovat a dobře spolu vycházejí.

65

Jednoduchost Hodnota pro zákazníka Analyzuj a uprav Pravidelná integrace Komunikace a spolupráce Kolektivní vlastnictví kódu Testování a revize součástí vývoje


66

SCRUM – životní cyklus

Scrum je kostra metodiky, která stanovuje následující role: vedoucí projektu (Scrum Master) – řídí procesy a celkovou práci, zadavatel (Product Owner) – který reprezentuje zainteresované osoby (stakeholders) a tým (Team) – který zahrnuje vývojáře.

Analýza Design a implementace Testování a revize

Doba trvání jednoho sprintu cca do 30 dnů Ohodnocení úloh body

Role v metodice SCRUM

Rozdělit práci na menší celky – „sprinty” Během sprintu by se měla stihnout celá úloha:

Duration = Effort / Velocity. Pro první plán: 1bod = 1man-day Bod je bezrozměrný, máme jen rychlost týmu

Výběr pořadí sprintů


67

Vytvoření plánu projektu (project backlog)

Sestavení případů užití (user stories) Vytvoření potřebných úloh (sprintů)

Realizace plánu projektu

68

Sprint

SCRUM - postup


Výběr sprintu (sprint backlog) Realizace sprintu Denní setkání (SCRUM Meetings, skrumáže) Sledování postupu (burndown graf)

Trvá typicky 2-4 týdny (rozhoduje si to tým). Výsledkem je přírůstek použitelného kódu. Zadání je vybráno z katalogu požadavků (product backlog) na schůzce (sprint planning meeting), kde zadavatel (product owner) informuje o požadavcích, které je zapotřebí realizovat – jsou součástí katalogu požadavků (product backlog). Tým si vybere co je schopen realizovat v rámci jednoho sprintu a určuje si plán sprintu (sprint backlog) - hierarchickou sada požadavků, které by měl sprint realizovat. Během sprintu se plán sprintu nemůže měnit (je zmrazen). Po ukončení sprintu tým prezentuje vytvořený přírůstek a dokumentuje jeho funkčnost.

Zdroj: Wikipedia Richta: ZSI - Proces vývoje

69


70

Výhody metodiky SCRUM

Metodika Scrum umožňuje vytváření samoorganizujících týmů – pro členy týmu to znamená větší pocit svobody, ale také větší zodpovědnost. Klíčový princip metodiky Scrum je připravenost na změny (nazývané requirements churn) a pochopení, že tuto skutečnost nelze řešit klasickou organizací a plánováním.


71

The End

Metodiky vývoje SW. Taxonomie metodik. Metodiky pro softwarový proces. Moderní strukturovaná analýza. Unifikovaný proces vývoje (UP) Klasické

Recommend Documents