Środowiska systemów informatycznych wykłady

background image

O czym mówimy - definicje kluczowe

System informatyczny.

Oprogramowanie (aplikacja/program
komputerowy).

1

Zbiór powiązanych ze sobą elementów, którego funkcją jest
przetwarzanie danych przy użyciu techniki komputerowej:

 sprzęt komputerowy

 oprogramowanie

 zasoby ludzkie

 elementy organizacyjne (procedury) i informacyjne (bazy
wiedzy)

Całość informacji w postaci zestawu instrukcji,
zaimplementowanych interfejsów i zintegrowanych danych
przeznaczonych dla komputera do realizacji wyznaczonych
celów.

background image

O czym mówimy – definicje kluczowe

2

Inżynieria oprogramowania.

Cykl życia oprogramowania.

Dziedzina inżynierii systemów zajmująca się wszelkimi
aspektami wytwarzania oprogramowania: od analizy
potrzeb/wymagań, przez projektowanie i wdrożenie, do
ewolucji gotowego oprogramowania.

Szereg wzajemnie zależnych od siebie etapów, w których
podejmowane są działania, począwszy od ujawnienia potrzeby
wytworzenia oprogramowania, prezentacji jego idei,
wytworzeniu, użytkowaniu, przystosowaniu do ewentualnych
zmian funkcjonowania aż do jego wycofania.

background image

O czym mówimy – definicje kluczowe

3

Proces wytwarzania oprogramowania.

Modele procesu wytwarzania

oprogramowania.

Proces obejmujący typowo fazy: specyfikacja, projektowanie,

implementacja, integracja, ewolucja (utrzymanie)

PODEJŚCIA KLASYCZNE

 model kaskadowy

 model prototypowy

 model przyrostowy

 model równoległy

model V

model spiralny

PODEJŚCIA ‘ZWINNE’

 programowanie zwinne

programowanie ekstremalne

STANDARDY

 PMBOK

 RUP

background image

Klasy systemów
informatycznych

4

Systemy wsparcia przedsiębiorstw

Systemy informowania kierownictwa

Systemy wspomagania decyzji

Systemy ekspertowe (sztuczna inteligencja)

background image

Proces wytwarzania oprogramowania

oraz

pozyskiwanie wymagań

5

Wykład 2

Materiały do wykładu opracowane na podstawie:
software.com.pl/przeglad-modeli-cyklu-zycia-oprogramowania
zasoby.open.agh.edu.pl/~10sdczerner/page/okreslanie_wymagan
wymagania.net/baza-wiedzy

background image

Proces wytwarzania oprogramowania

6

background image

Grupy działań

(działania programowe rozwoju oprogramowania)

Działania
podstawowe

Działania wsparcia

7

I.

Planowanie

II.

Ocena/Analiza

III.

Projektowanie

IV.

Programowanie

V.

Walidacja i weryfikacja

I.

Zarządzanie
wymaganiami

II.

Zarządzanie
projektami

III.

Zarządzanie jakością

IV.

Zarządzanie
konfiguracją

V.

Wprowadzenie do
oprogramowania

VI.

Dokumentacja

background image

8

Planowanie

•Aktywizacja wymagań

•Specyfikacja (wymogi, definicje)

•Oszacowanie wysiłku

•Model procesu

Ocena

•Prototyp wyjściowy

•Analiza procesu

•Object Oriented Analisys (OOA)

Projekt

•Architektura oprogramowania

•Structured Design (SD)

•Object Oriented Desing (OOD)

•Unify Modelling Language

Programowanie

:

•Standaryzowane metody

programowania

•Programowania strukturalne

•Programowanie obiektowe

•Functionall Programming

Walidacja i

weryfikacja

•Testy jednostkowe

•Testy integracyjne

•Testowanie systemu

•Testowanie odbiorcze

Zarządzanie

wymaganiam

i

• Zarządzanie wymaganiami

Zarządzanie

projektem

(PM)

• Zarządzanie grupą

• Zarządzanie ryzykiem

• Monitoring i kontrola

• Zarządzanie umową z dostawcami

Zarządzanie

jakością

(QM)

• Capability, Maturity Model

• Spice standard (Software Process Improvement)

• Zarządzanie incydentami

• Zarządzanie problemem

• Pomiar cech oprogramowania

• Analiza statystyczna

• Ergonomiia oprogramowania

Zarządzanie

Konfiguracj

ą (CM)

• Wersjonowanie

• Zarządzanie zmianami

• Zarządzanie wersjami

• Application Management

Wprowadzenie

do

oprogramowani

a

• Wprowadzenie do oprogramowania

Dokumentacj

a

• Dokumentacja techniczna

• Dokumentacja oprogramowania

• Narzędzia dokumentacji oprogramowania

• Dokumentacja systemu

• Dokumentacja operacyjna

• Instrukcja dla użytkowników

• Procesy biznesowe (projekt rozwoju)

• Dokumentacja procesu

background image

Określanie wymagań

9

Wymagania dotyczą systemu. Są opisem systemu pod względem
wykonywanych przez niego funkcji oraz sposobu realizacji tych funkcji.

Określanie wymagań może odbywać się na różnych etapach realizacji

projektu:

w fazie przeprowadzania studium wykonalności projektu (feasibility study)

po podjęciu decyzji o realizacji projektu, ale przed podpisaniem kontraktu
o jego realizacji (lub ogłoszeniem przetargu),

po podpisaniu kontraktu.

Proces określania wymagań dla systemu informatycznego można podzielić
na następujące fazy:

faza ustalania wymagań (odkrywania wymagań).

faza specyfikacji wymagań (tworzenia opisu wymagań).

faza atestacji (walidacji) wymagań.

background image

Określenie wymagań

10

Obie strony, klient i wykonawca, muszą porozumieć się co do
wielu elementów, przy czym:

klient często nie rozumie specyfiki funkcjonowania programów,

wykonawca nie zna specyfiki dziedziny zastosowań.

Klient musi ustalić swoje wymagania w kontekście możliwości i
ograniczeń charakterystycznych dla systemów informatycznych.
Wykonawca musi dostosować funkcjonowanie programów do
standardów
i konwencji dziedziny zastosowań.

background image

Klasyfikacja wymagań

11

Z punktu widzenia rodzaju wymagań można je podzielić na:

wymagania funkcjonalne – dotyczące tego co ma realizować
system, jakie ma spełniać funkcje, jakich dostarczać usług, jak
zachowywać się w określonych sytuacjach;

wymagania niefunkcjonalne – dotyczące tego jak system powinien
realizować swoje zadania; np. wymagania dotyczące koniecznych
zasobów, ograniczeń czasowych, niezawodności, bezpieczeństwa,
przenośności, współpracy z określonymi narzędziami i środowiskami,
zgodności z normami i standardami,
a także przepisami prawnymi, w tym dotyczącymi tajności i
prywatności, itp.

Wymagania funkcjonalne powinny być:

kompletne – opisywać wszystkie usługi żądane od systemu,

spójne – nie zawierać stwierdzeń sprzecznych.

background image

Specjalne grupy wymagań

12

Ważnym przykładem specyficznej grupy wymagań
wymagania dotyczące zabezpieczania systemu. Obejmują one
wymagania:

identyfikacji użytkowników,

autentykacji użytkowników,

autoryzacji,

wykrywania ataków,

odporności na ataki (wirusów, robaków, itp.),

integralności danych (odporność na niszczenie danych),

uniemożliwiania zaprzeczaniu uczestnictwa w transakcjach,

prywatności,

sprawdzalności zabezpieczeń,

odporności podsystemu zabezpieczeń na zmiany dokonywane
w innych częściach systemu.

background image

Techniki pozyskiwania wymagań

13

Pomocnymi technikami w odkrywaniu wymagań są:

poznanie całości otoczenia systemu (poprzez obserwacje,
zaznajomienie z odpowiednimi dokumentami, itp),

wykorzystanie istniejących systemów realizujących podobne
funkcje,

obserwacje i wywiady z przyszłymi użytkownikami systemu,

stosowanie scenariuszy wykorzystania systemu
(przypadków użycia),

modelowanie systemu,

tworzenie prototypów systemu.

background image

Techniki pozyskiwania

wymagań

14

Przydatną techniką przy odkrywaniu wymagań jest rozważanie tzw.
punktów widzenia (viewpoints).
Punkt widzenia określa dowolną osobę, której w jakiś sposób dotyczy
funkcjonowanie systemu, ewentualnie element szeroko rozumianego
otoczenia wpływający na wymagania systemu.

Punkty widzenia można podzielić następująco:

bezpośrednie – związane z ludźmi bezpośrednio korzystającymi z
systemu bądź obsługującymi system

pośrednie – związane z ludźmi pośrednio zainteresowanymi
funkcjonowaniem systemu (kierownictwo, osoby odpowiedzialne
za bezpieczeństwo)

związane z dziedziną – standardy, przepisy organizacyjne, itp.

Punkty widzenia są źródłem rozmaitych oczekiwań, wizji i
konkretnych wymagań w stosunku do systemu.

background image

Techniki według BABOK

®

15

BABOK

®

- Bussines Analysis Body of Knowledge

Techniki:

Burza mózgów. Technika polegająca na wspólnym tworzeniu
i analizowaniu pomysłów podczas grupowego spotkania.

Analiza dokumentacji. Polega na przeglądaniu istniejącej w organizacji
dokumentacji w celu identyfikacji wymagań obecnych i potencjalnych.

Analiza interfejsów. Analiza zewnętrznych interfejsów polega na identyfikacji i
badaniu zarówno interfejsu użytkownika, jak i interfejsów do/z zewnętrznych
systemów lub urządzeń.

Wywiad. Technika polegająca na zadawaniu pytań dotyczących określonego
obszaru działania danej osoby, procesu czy problemu. Wywiad przeprowadzany jest
przez analityka, zaś osobą pytaną jest ekspert dziedzinowy, przedstawiciel biznesu
czy wręcz użytkownik końcowy projektowanego rozwiązania.

Obserwacja. Technika ta polega na wyciąganiu wniosków na podstawie obserwacji
pracy ludzi wykonujących swoje zadania.

Prototypowanie. Prototypy aplikacji (tworzone np. jako statyczne lub dynamiczne
strony HTML) pozwalają na wizualizację wstępnego projektu analityka
i weryfikację rozwiązania przez przedstawicieli klienta.

Warsztaty. Warsztaty wymagań stanowią ustrukturyzowaną metodę pozyskiwania
wymagań. Warsztaty służą do określania zakresu, identyfikacji, szczegółowego
definiowania i ustalania priorytetów wymagań projektowanego systemu.

background image

Porządkowanie wymagań

16

Wygodnym sposobem porządkowania informacji uzyskanych z różnych
punktów widzenia jest tworzenie scenariuszy – opisów możliwych sekwencji
zdarzeń związanych z funkcjonowaniem systemu.

Scenariusze można następnie grupować w zbiory odpowiadające
realizacji konkretnych funkcji lub grup funkcji systemu zwanych przypadkami
użycia.

Uporządkowanie i hierarchizacja możliwych punktów widzenia oraz scenariuszy
i przypadków użycia może być podstawą określania konkretnych wymagań.

Zarządzanie wymaganiami Zarządzanie wymaganiami oznacza proces
kontroli zmian wymagań i ich konsekwencji dla systemu w ciągu całego cyklu
życia systemu.

Zarządzanie wymaganiami jest konieczne, gdyż w praktyce wymagania
zawsze się zmieniają z powodu zmian technologicznych, organizacyjnych i
czysto ludzkich.

background image

Modelowanie wymagań

17

UML – Unified Modelling Language jest rozbudowanym językiem
modelowania systemów oraz tworzenia specyfikacji.

Powstał w wyniku rozwoju notacji graficznych związanych z
trzema metodologiami tworzenia oprogramowania obiektowego:

OOAD (Object Oriented Analysies and Design) Boocha,

OOSE (Object Oriented Software Engeenering) Jacobsona,

OMT (Object Modelling Technique) Rumbaugh.

Obecnie rozwijany jest jako standard organizacji OMG
(Object Management Group).

background image

Modelowanie wymagań

18

Diagramy przypadków użycia:

definiują granice modelowanego systemu,

określają jego kontekst,

wymieniają użytkowników systemu i jednostki zewnętrzne,

przedstawiają funkcje dostępne dla użytkowników,

określają powiązania i zależności pomiędzy nimi.

W późniejszych fazach tworzenia oprogramowania przypadki użycia (i tworzące je
pojedyncze scenariusze) są przekształcane w bardziej szczegółowe opisy
funkcjonowania systemu, takie jak np.:

diagramy interakcji między obiektami systemu,

diagramy czynności realizowanych przez system,

diagramy stanów,

specyfikacje za pomocą warunków początkowych i końcowych,

mniej lub bardziej sformalizowane opisy w języku naturalnym,

pseudokod.

W ostatecznym kodzie tym co realizuje przypadek użycia jest najczęściej
kooperacja – zbiór klas, interfejsów itp. wspólnie dostarczających funkcjonalność
nieosiągalną w pojedynkę.

background image

Narzędzia CASE

19

CASE: Computer Aided Software Engineering,

Computer Aided System Engineering.

Narzędzia CASE wspomagające proces określania wymagań związane są
najczęściej z konkretną ustaloną notacją lub metodyką postępowania.

Funkcje narzędzi CASE to analiza, projektowanie i programowanie.

Narzędzia CASE automatyzują metody projektowania, dokumentacji oraz
tworzenia struktury kodu programu w wybranym języku programowania,
najczęściej w programowaniu obiektowym.

Typowymi narzędziami CASE są:

narzędzia do modelowania w języku UML i podobnych,

narzędzia do zarządzania konfiguracją zawierające system kontroli wersji,

narzędzia do refaktoryzacji

.

background image

Narzędzia CASE

20

Systemy CASE można podzielić według faz cyklu życia systemu na:

Upper-CASE - wspomaga pierwsze fazy budowy systemu – analizę

organizacyjną i funkcjonalną i procesową, modelowanie funkcji, procesów,
obiektów, modelowanie struktur i potrafi tworzyć wszelkie diagramy. Te
narzędzia zajmują się bardziej opisem i modelowaniem rzeczywistości,
modelowaniem struktury systemu, bez wszelkich faz implementacji.

Lower-CASE, wspomaga rzeczywiste budowanie oprogramowania –

modelowanie bazy danych, generowanie kodu i testy.

Czasami wyróżnia się także systemy Middle-CASE, które pozwalają
określić samą strukturę systemu informatycznego, oraz Integrated-
CASE
, czyli systemy łączące Upper- i Lower-CASE.

Według zakresu zastosowań narzędzia CASE można również podzielić na
pakiety narzędziowe oraz pakiety zintegrowane.

background image

Narzędzia CASE

21

O zaawansowaniu danego systemu i spełnieniu wymagań użytkownika świadczy zakres
oferowanych funkcjonalności.

Słowniki danych (repozytoria) – bazy wszelkich danych o tworzonym systemie wraz z
narzędziami edytującymi, zarządzającymi i wyszukującymi te dane.

Edytor Notacji Graficznych – program graficzny, umożliwiający tworzenie i edycję diagramów dla
faz określania wymagań systemu, analizy i projektowania. Powinien też umożliwiać powiązania
między symbolami w modelu a innymi, zdekomponowanymi modelami, oraz wydruk tych
diagramów.

Moduł Kontroli Poprawności – narzędzie do wykrywania i poprawiania błędów w diagramach i
repozytoriach. Bardzo często działa w czasie rzeczywistym, co znacząco wpływa na komfort pracy.

Moduł Kontroli Jakości – narzędzie do oceny pewnych ustalonych miar jakości projektu –
np. stopnia złożoności lub powiązań składowych modelu.

Generator Raportów – narzędzie tworzące dowolny raport na podstawie danych z repozytorium.

Generator Kodu – narzędzie transformujące projekt na szkielet kodu w wybranym języku
programowania. Usprawnia pracę programistów, pozwala na zautomatyzowanie pewnych
fragmentów kodu, a także na uzupełnienie kodu o dodatkowe informacje ze słownika danych.

Generator Dokumentacji Technicznej – generator ustandaryzowanych dokumentów,
zawierających specyfikację, opisy faz projektu, diagramy oraz wybrane raporty.

Moduł Projektowania Interfejsu Użytkownika – narzędzie do projektowania menu, okien
dialogowych oraz innych elementów interfejsu użytkownika.

Moduł Inżynierii Odwrotnej – narzędzie pozwalające odtworzyć słownika danych oraz diagramów,
na podstawie kodu źródłowego lub struktury bazy danych.

Moduł Importu/Eksportu Danych – narzędzie służące do wymiany danych z innymi CASE'ami czy
też innymi programami.

Moduł Zarządzania Pracą Grupową – narzędzie umożliwiające współpracę grupy osób podczas
pracy nad projektem.

background image

Modele procesu

22

Wykład 3

Materiały do wykładu opracowane na podstawie:
software.com.pl/przeglad-modeli-cyklu-zycia-oprogramowania
zasoby.open.agh.edu.pl/~10sdczerner/page/okreslanie_wymagan
wymagania.net/baza-wiedzy

background image

Modele cyklu wytwarzania oprogramowania

23

Model kaskadowy (waterfall)

W modelu kaskadowym kolejne etapy procesu
rozwoju oprogramowania następują po sobie w
ściśle określonym porządku.

Każda następna faza rozpoczyna się dopiero
często po formalnym przyjęciu/zamknięciu fazy
poprzedzającej.

background image

Model kaskadowy

24

Zalety:

uporządkowanie procesu wytwarzania

Wady:

Uzyskanie efektu zadawalającego klienta jest niezmiernie zależne od
stabilności wymagań ustalonych na początku procesu

Weryfikacja zgodności z wymaganiami i jego użyteczności następuje
dopiero w końcowej fazie procesu

Próba dopasowania produktu do zmieniających się wymagań jest bardzo
droga

Brak elastyczności w zakresie przenikania się faz procesu wytwarzania

Wysoki koszt późnego wykrywania błędów popełnianych we wczesnych
fazach procesu

Zmarginalizowanie roli klienta w procesie wytwarzania oprogramowania

Odmiana modelu kaskadowego:
Realizacja kierowana dokumentami

background image

Model V

25

Modelowanie

Projektowanie

Implementacj

a

Testowanie jednostek

oprogramowania i

integracyjne

Testowanie

walidacyjne i

systemu

background image

Model iteracyjny

26

Analiza wymagań

biznesowych

Analiza wymagań

biznesowych

Zgrubna analiza

wymagań

projektowych

Zgrubna analiza

wymagań

projektowych

Wybór podzbioru

zadań do realizacji

Wybór podzbioru

zadań do realizacji

Szczegółowa

analiza, projekt,

implementacja

i testowanie

Szczegółowa

analiza, projekt,

implementacja

i testowanie

Nowa wersja

systemu

Nowa wersja

systemu

Proces

iteracji

I Etap: Prototyp fitness

background image

Model iteracyjny

27

Zalety:

Pozwala na szybką implementację przynajmniej części wymaganej
funkcjonalności

Pozwala na bardzo szybką weryfikację realizowalności
wytwarzanego systemu i informację zwrotną od klienta

Pozwala na szybsze uzyskiwanie wpływów finansowych

Wady:

Wymaga bardzo dobrej umiejętności (praktyki) pogrupowania
procesu na właściwe iteracje

Synonimy tego procesu: proces ewolucyjny, przyrostowy, spiralny

background image

28

Czas

Budżet

Zasob

y

Analiza
wstępna
realizowalnoś
ci

background image

Model spiralny

29

Jest pewną próbą formalizacji modelu iteracyjnego.

Główną cechą tego modelu jest analiza ryzyka występująca w każdej fazie tego
procesu.

Główną zaletą jest próba minimalizacji ryzyka niepowodzenia przedsięwzięcia
oraz ciągła weryfikacja produktu przez klienta (użytkownika).

Model spiralny można postrzegać jako cykliczne powtarzanie czterech czynności:

Planowanie – na podstawie wymagań i celów wyznaczonych przez klienta,
dokonuje się określenia alternatyw i ograniczeń oraz planowania iteracji przy
każdorazowym rozpoczęciu kolejnego cyklu spirali

Analiza ryzyka – sprowadza się do oceny rozwiązań alternatywnych oraz próby
identyfikacji i analizy ryzyka związanego z każdą z możliwych konstrukcji
kolejnego wydania

Konstrukcja – ma postać „małego wodospadu”, a jej celem jest wytworzenie
kolejnego wydania systemu.

Ocena przez klienta – walidacja wydania i jego ocena z możliwością modyfikacji
wymagań na system

background image

Model prototypowania

30

Zbieranie

wymagań

Zbieranie

wymagań

Zgrubna

analiza

wymagań

Zgrubna

analiza

wymagań

Szybki projekt

Szybki projekt

Budowa

prototypu

Budowa

prototypu

Ocena

prototypu

przez klienta

Ocena

prototypu

przez klienta

Prototyp

spełnia

oczekiwania

klienta

Prototyp

spełnia

oczekiwania

klienta

Modyfikacja

wymagań

Modyfikacja

wymagań

Wymagania

Wymagania

Projektowanie

Projektowanie

Implementacja

Implementacja

Testowanie

Testowanie

Wdrożenie

Wdrożenie

NIE

TAK

Analiza wymagań

Wytworzenie produktu

background image

Model prototypowania

31

Prototypowanie polega na budowaniu kolejnych „przybliżeń” systemu aż do
momentu, gdy prototyp stanie się dobrym odzwierciedleniem wymagań.

Cechą charakterystyczną modelu jest budowa „szybkiego projektu” bez dbałości
o jego jakość i dostosowanie do środowiska docelowego.

Przy tworzeniu kolejnego prototypu odrzuca się wcześniej przygotowany
kod
.

Do budowy prototypu także trzeba wykorzystać jakiś model rozwoju
oprogramowania.

Wady:

częste niezrozumienie przez klienta potrzeb kolejnego prototypowania

możliwość przyzwyczajenia się klienta do funkcjonalności, które oferuje prototyp,
a które nie wynikają z wymagań

background image

Model wytwarzania odkrywczego

32

Wytwarzanie odkrywcze (exploratory development) jest wariantem modelu
ewolucyjnego, w którym iteracje dotyczą całego cyklu wytwarzania
oprogramowania

Istotą wytwarzania odkrywczego jest stała współpraca z klientem, który
otrzymuje kolejne, coraz bogatsze wersje systemu i na ich podstawie określa i
uszczegóławia swoje wymagania

Wytwarzanie odkrywcze dobrze radzi sobie z występującym powszechnie
faktem zmiany wymagań przez klientów

Wytwarzanie odkrywcze polega na stałej modyfikacji kodu, bez odrzucania
dotychczas wytworzonego oprogramowania (przeciwnie do prototypowania)

Wytwarzanie odkrywcze musi poradzić sobie z dwoma istotnymi problemami:

jak często dokonywać rewizji aktualnego stanu kodu (problem ważny dla
efektywnego zarządzania wytwarzaniem programów)

jak nie dopuścić do utraty jednolitej struktury przez ciągle modyfikowany kod

W przypadku stosowania wytwarzania odkrywczego konieczne jest
wypracowanie strategii zarządzania wersjami, np. takiej, w której istnieją
wersje będące drobnymi poprawkami w stosunku do poprzednich oraz istotne
zmiany, przy których odrzuca się znaczne części poprzedniej wersji kodu
(która może być wtedy traktowana jako prototyp).

background image

Diagramy przypadków użycia

UML

33

Wykład 4

background image

Diagramy przypadków użycia

34

Diagramy przypadków użycia zawierają następujące główne
kategorie pojęciowe
:

przypadki użycia,

aktorzy,

związki.

Kategorie te w każdym diagramie są ze sobą ściśle powiązane.

background image

Przypadek użycia

35

Przypadek użycia (use case us) to specyfikacja ciągu akcji i ich
wariantów, które system (lub inna jednostka) może wykonać
poprzez interakcję z aktorami tego systemu.
Jest to więc kompleksowe działanie realizowane w systemie w
konsekwencji określonej aktywności aktora (actor).

Nazwę przypadku użycia stanowi zwięzłe polecenie
wykonania funkcji
w projektowanym systemie, sformułowane w
trybie rozkazującym.

Rezerwuj

wycieczk

ę

Sprzedaj

towar

Rezerwuj wycieczkę

Sprzedaj towar

Rezerwuj wycieczkę

Sprzedaj towar

A)

B)

C)

background image

Aktorzy

36

Aktor jest to spójny zbiór ról odgrywanych przez użytkowników
przypadku użycia w czasie interakcji z tym przypadkiem użycia.

Aktorzy mogą być osobowi (np. osoba, zespół, dział, instytucja,
organizacja, zrzeszenie, itp.) lub nieosobowi (systemy
zewnętrzne, podsystemy, bazy danych, urządzenia oraz czas).

Nazwę aktora wyraża się rzeczownikiem lub określeniem
rzeczownikowym w liczbie pojedynczej. Identyfikując aktorów
należy pamiętać, że reprezentują oni nie indywidualne obiekty ze
świata rzeczywistego, ale pełnione przez nie funkcje.

background image

Aktorzy - stereotypy

37

Rodzaje aktorów w reprezentacji obiektów:

ludzi oraz zespołów,

systemów zewnętrznych,

urządzeń,

czasu.

Urządzenie

System zewnętrzny

Czas

Konsultant
Sprzedawca
Dział sprzedaży

Nagrywarka DVD
Laptop Toschiba

System obsługi
kart płatniczych

Termin płatności

background image

Związek

38

Związek stanowi semantyczne powiązanie pomiędzy elementami

modelu.

Każdy aktor umieszczony na diagramie przypadków użycia
powinien być bezpośrednio powiązany z co najmniej jednym
przypadkiem użycia.

W diagramie języka UML można wyróżnić cztery rodzaje
związków:

asocjację,

uogólnienie,

zależność,

realizację.

background image

Związek

39

Asocjacja jest związkiem pomiędzy dwoma lub więcej
klasyfikatorami, opisującym powiązania między ich instancjami.

W diagramie przypadków użycia asocjacja wskazuje zatem
domyślnie na dwukierunkową komunikację pomiędzy
aktorem a przypadkiem użycia.

Może ona dodatkowo występować w formie z kierunkiem
nawigacji (jawne przedstawienie inicjatora interakcji).

background image

Przykładowy DPU aukcji internetowej

40

background image

Przykładowy DPU obsługi hurtowni

41

background image

Zaawansowane składniki diagramu

42

Do zaawansowanych koncepcji diagramów przypadków użycia
należy zaliczyć:

rozbudowę DPU poprzez różnicowanie związków,

zależności zawierania,

zależności rozszerzania,

uogólnienie,

rodzaje aktorów,

liczebność,

nawigację,

realizację,

przypadki użycia typu CRUD,

diagram kontekstowy,

dokumentację przypadków użycia.

background image

Rozbudowa DPU poprzez różnicowanie związków

43

Zależność to taki związek pomiędzy dwoma elementami modelowania,
w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny.

I tak w obrębie pojedynczego diagramu przypadków użycia zależności w DPU
występują w postaci stereotypowanej, przede wszystkim jako zależności:

zawierania,

rozszerzania.

background image

Zależności zawierania (wymagana)

44

Zależność zawierania «include» przedstawia powiązanie pomiędzy przypadkiem
zawierającym
, tj. bazowym przypadkiem użycia, a przypadkiem zawieranym.

Sens tworzenia zależności zawierania na diagramie UML występuje w dwóch
przypadkach, gdy:

istnieje możliwość wydzielenia w formie zawieranego przypadku użycia pewnej

spójnej, wspólnej dla kilku innych przypadków użycia funkcjonalności (czytelność
diagramu); w tym przypadku często występująca funkcjonalność jest
reprezentowana jednokrotnie na diagramie i wykorzystywana przez inne przypadki
użycia;

interakcje aktor-system wyrażone w dokumentacji scenariusza tego przypadku są

bardzo liczne.

«include»

Przypadek użycia

‘zawierany’

dokonywany

każdorazowo dla

przypadku

‘Dokonaj

rezerwacji’

Przypadek

użycia

‘zawierający’

background image

Zależności rozszerzania (opcjonalne)

45

Zależność rozszerzenia «extend» przedstawia powiązanie pomiędzy
rozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, a
przypadkiem rozszerzającym.

Związek ten, w odróżnieniu od zależności zawierania, ma charakter
opcjonalny.

Funkcjonalność reprezentowana przez rozszerzający przypadek użycia
może, ale nie musi zostać włączona do rozszerzanego przypadku
użycia. Włączenie przypadku rozszerzającego wymaga spełnienia
określonego warunku.

Przypadek

rozszerzan

y

Przypadek

rozszerzając

y -

opcjonalny

background image

Zależność rozszerzania -
warunki

46

Miejsca/punk

ty

rozszerzenia

Dodatkowa funkcjonalność zawarta w przypadkach rozszerzających
nie jest
wykonywana automatycznie, a dopiero po spełnieniu określonych
warunków określanych dla przypadku bazowego jako
miejsca/punkty rozszerzenia.

background image

Uogólnienia

47

Uogólnienie to związek o charakterze taksonomicznym
pomiędzy klasyfikatorem ogólnym a specjalizowanym.

Związki uogólnienia (generalization) dotyczą w kontekście
charakteryzowanego diagramu zarówno przypadków użycia, jak i
aktorów.

Element specjalizowany z założenia dziedziczy wszelkie cechy
elementu ogólnego.

background image

Liczebność i Nawigacja

48

Diagramy przypadków użycia pozwalają na określenie
liczebności (multiplicity) końcówek związku asocjacji pomiędzy
aktorami i przypadkami użycia.

Nawigacja pozwala wskazać inicjatora interakcji. Używana jest
wyłącznie wtedy, gdy wskazanie inicjatora jest istotne i wymaga
udokumentowania.

background image

Realizacja

49

Realizacja to związek znaczeniowy między klasyfikatorami, z których
jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego.

Związki realizacji w odniesieniu do przypadków użycia pozwalają
modelować relacje występujące pomiędzy ogólnym, funkcjonalnym
opisem systemu w postaci diagramów przypadków użycia a jego
wdrożeniem.
W ten sposób diagram przypadków użycia pozostaje powiązany z
innymi diagramami, które zawierają informacje niezbędne do jego
poprawnego rozwinięcia i implementacji.

background image

Diagram kontekstowy

50

Diagram kontekstowy stanowi zestawienie aktorów będących
w interakcji z danym systemem traktowanym w kategorii
pojedynczego procesu.

background image

Dokumentacja przypadków użycia

51

NAZWA:

Pełna nazwa przypadku użycia

Numer:

Numer identyfikacyjny przypadku użycia

Twórca:

Dane twórcy (imię, nazwisko, stanowisko)

Poziom ważności:

Określony z perspektywy użytkownika (niski, średni, wysoki)

Typ przypadku:

Określony z punktu widzenia złożoności oraz ważności dla
zaspokojenia potrzeb użytkownika

Aktorzy

Lista aktorów będących w związku z przypadkiem użycia

Krótki opis

Krotka ogólna charakterystyka przypadku użycia

Warunki wstępne:

Lista warunków inicjujących przypadek

Warunki końcowe:

Stan systemu po realizacji przypadku użycia

Główny przepływ zdarzeń

Wypunktowana lista przepływów zdarzeń zachodzących podczas
realizacji – scenariusz główny

Alternatywny przepływ
zdarzeń

jw. dotyczy alternatywnych scenariuszy

Specjalne wymagania

Wypunktowana lista dodatkowych zidentyfikowanych wymagań
niefunkcjonalnych, które mogą być istotne przykładowo podczas
projektowania lub implementacji

Notatki

Lista wszelkich komentarzy dotyczących przypadku użycia i lista
pozostałych otwartych kwestii, które powinny zostać rozwiązane.

background image

52

NAZWA:

Anuluj rezerwację

Numer:

5

Twórca:

Pani Iksińska, projektant

Poziom ważności:

Średni

Typ przypadku:

Ogólny

Aktorzy

Recepcjonista, Kierownik recepcji

Krótki opis

Anulowanie istniejącej rezerwacji pokoju lub apartamentu

Warunki wstępne:

Co najmniej jedne pokój lub apartament musi być zarezerwowany

Warunki końcowe:

System odnotowuje pokój lub (i) apartament jako dostępny

Główny przepływ
zdarzeń

1. Recepcjonista weryfikuje rezerwację, uruchamiając funkcję

„Rezerwacje”

2. System wyświetla okno z informacjami o rezerwacjach (pokoje i

apartamenty hotelowe)

3. Pracownik recepcji zaznacza rezerwacje do anulowania i uruchamia

funkcję „Anuluj rezerwacje”

4. System wyświetla komunikat „Czy anulować zaznaczone

rezerwacje?”

5. Pracownik recepcji potwierdza operację anulowania zaznaczonych

rezerwacji

6. System potwierdza wykonanie operacji komunikatem „Anulowano

wybrane rezerwacje” i odświeża ekran monitora

Alternatywny przepływ
zdarzeń

2a. System wyświetla komunikat „Brak rezerwacji”
3a. Pracownik recepcji potwierdza operację anulowania zaznaczonych
rezerwacji
3b. Jeśli podczas rezerwacji podany został adres e-mail, pracownik może
wysłać do klienta pocztą elektroniczną informację o anulowaniu
rezerwacji

Specjalne wymagania

1. Wysoka niezawodność systemu
2. Czas przetwarzania operacji anulowania rezerwacji nie może

przekroczyć 5 sekund

Notatki

Brak

background image

53

background image

UML 2.0 - Diagramy sekwencji

54

Diagram sekwencji – jeden z podstawowych diagramów interakcji.
Umożliwia modelowanie interakcji pomiędzy obiektami wraz z
komunikatami, jakie między nimi przepływają.

OŚ pozioma
[instancje
klasyfikatorów]

O

Ś

p

io

n

o

w

a

[p

rz

e

p

ły

w

k

o

m

u

n

ik

a

w

w

cz

a

si

e

]

Obiekt 1

Obiekt n

. . .
.

Komunikat 1

Komunikat 2

.
.

• Pozwalają uzyskać

odpowiedź na pytanie,
jak w czasie przebiega
komunikacja między
obiektami?

• Stanowią podstawową

technikę modelowania
zachowania systemu,
które składa się na
realizację przypadku
użycia.

background image

Diagramy sekwencji – notacja i
semantyka

55

klasyfikator

linia życia

ośrodek sterowania

komunikat

dezaktywacja

aktywacja

background image

Instancje klasyfikatorów

56

Klasy

Klasa jest pojęciem ogólnym. Np. system zarządzania obejmuje szereg pojęć

ogólnych jak: projekty, menadżerów, zespoły, produkty pracy, wymogi,
systemy.

Klasa definiuje zatem typ obiektu i jego właściwości, w tym cechy strukturalne

i behawioralne.

Na diagramie UML klasa jest przedstawiana w postaci prostokąta,

narysowanego linią ciągłą, i zawierającego trzy standardowe przedziały,
odseparowane od siebie liniami poziomymi. W górnym przedziale wpisuje się
nazwę klasy; w środkowym (opcjonalny) listę atrybutów;
w dolnym (opcjonalny) listę operacji.

Na potrzeby diagramów sekwencji stosujemy notację tylko z nazwą klasy.

Pracownik

Projekt

Produkt

pracy

background image

Instancje klasyfikatorów

57

Rola klasy

W diagramie sekwencji rolę klasy przedstawiamy w tej samej

notacji co klasę lecz nazwę klasy poprzedza prawy ukośnik, po
nim następuje nazwa roli, z którą obiekt musi być zgodny, aby
uczestniczyć w roli,
a następnie dwukropek.

Rysunek przedstawia rolę Organizacja Projektu klasy Organizacja

/Organizacja Projektu:

Organizacja

background image

Instancje klasyfikatorów

58

Obiekty

Obiekt jest konkretnym pojęciem, inaczej instancją klasy; ma

właściwości zdefiniowane przez klasę, w tym cechy
strukturalne i behawioralne. Cechy strukturalne definiując co
obiekt „wie”, a behawioralne co ten obiekt „może zrobić”. Do
cech strukturalnych należą wartości atrybutów i powiązania.
Do cech behawioralnych należą operacje i metody, wspólne dla
wszystkich obiektów w klasie.

Najważniejszą cechą obiektu jest to, że posiada własną

tożsamość. Dwa obiekty nigdy nie są takie same, nawet jeśli
mają identyczne wartości cech strukturalnych.

background image

Instancje klasyfikatorów

59

Obiekty

W diagramie UML obiekt jest przedstawiany w postaci prostokąta,

narysowanego linią ciągłą i podzielnego poziomą linią na dwa
standardowe przedziały. Przedział górny zawiera

nazwę

obiektu

, po której następuje dwukropek i

nazwa klasy

obiektu

, a cały ciąg jest podkreślony linią ciągłą. Dwukropek

powinien być obecny tylko wtedy, gdy podajemy nazwę klasy.

Natalia

:

Student

Natalia:Student

ID=2
Imię= ”Natalia”
-AdresEmail[1]=”nat@wp.pl”
-
AdresEmail[2]=”nat@gmail.co
m

Natalia:

:Student

Obiekt anonimowy

Obiekt niesprecyzowany

background image

Instancje klasyfikatorów

60

Obiekty

W diagramie sekwencji konkretny obiekt z danej klasy, zgodny z

rolą klasy, przedstawia się wpisując nazwę obiektu, a następnie
prawy ukośnik, nazwę roli, dwukropek i nazwę klasy, a całość
jest podkreślona.

Na rysunku Grupa Natalii jest grupą zarządzającą należącą do roli

Grupa Zarządzanie, które wychodzą z klasy Grupa Studencka.

Grupa Natalii/ Grupa

Zarządzanie:

Grupa Studencka

background image

Linia życia i aktywacja

61

Linia życia i aktywacja

Linia życia przedstawiona w postaci pionowej linii przerywanej

biegnącej od elementu, reprezentuje istnienie tego elementu w
czasie.

Aktywacja

Aktywacja przedstawiana jako wąski wzdłużny prostokąt na linii

życia, reprezentuje okres, w którym element wykonuje operację.
Górny bok prostokąta znajduje się na poziomie chwili inicjacji, a
dolny na poziomie chwili ukończenia.

background image

Komunikacja, komunikat, bodziec

62

W diagramie sekwencji komunikację przedstawia się w postaci

poziomej strzałki narysowanej linią ciągłą do linii życia lub
aktywacji nadawcy do linii życia lub aktywacji odbiorcy.

Najbardziej podstawowym opisem komunikacji jest nazwa

operacji.

background image

Komunikacja – opis szczegółowy

63

W języku UML komunikację opisuje się za pomocą następującej składni:

[dozór] *[iteracja] numer_sekwencyjny : zmienna_zwracana := nazwa_operacji

(lista_argumentów)

dozór jest opcjonalny i oznacza warunek, który musi zostać spełniony, aby komunikacja

nastąpiła. Nawiasy prostokątne usuwamy, jeśli dozór nie jest wyspecyfikowany.

iteracja jest opcjonalna i oznacza, ile razy komunikacja zostaje wysłana (występuje).

Gwiazdkę i nawiasy prostokątne usuwamy, jeżeli nie podajemy iteracji.

numer_sekwencyjny jest opcjonalną liczbą całkowitą, która określa kolejność komunikacji.

Następujący po nim dwukropek usuwamy jeżeli nie podajemy numeru.

zmienna_zwracana jest opcjonalna i oznacza nazwę wartości zwracanej przez operację. Jeżeli

nie chcemy przedstawiać zwracanej zmiennej lub operacja nie zwraca zmiennej należy
usunąć dwukropek i znak równości

nazwa_operacji wymagana nazwa operacji, którą należy wywołać
lista_argumentów jest opcjonalna i zawiera oddzielone od siebie przecinkiem argumenty

przekazywane do operacji. Każdy parametr może być konkretną wartością lub zmienną
zwróconą z wcześniejszej komunikacji. Jeżeli operacja nie wymaga żadnych argumentów,
pozostawiamy puste nawiasy.

background image

Komunikacja

64

Komunikacja wywołuje operację FormatujDanePracownika, która formatuje dane o

pracowniku.

Ta operacja wymaga jednostek pracy i produktów pracownika więc dodane

zostało: (JednostkiPracy, ProduktPracy)

Operacja zwraca też pewne dane w postaci łańcucha sformatowanego tekstu,

więc dodane zostało: DaneWyjściowe :=

Operacja występuje jakoś szósta komunikacja w ogólnej sekwencji, więc 6 :
Projekt może obejmować więcej niż jednego pracownika (operacja ma wystąpić

jednokrotnie dla każdego pracownika) więc zapisano *[Dla każdego
pracownika
]

Operacja ma wystąpić tylko wtedy, gdy projekt jest aktywy więc [Projekt jest

aktywny]

Obsługa

Generowania

Raportu Statusu

Projektu

/organizacja

Projektu:Organizac

ja

[Projekt jest aktywny] *[Dla każdego pracownika]
6 : DaneWyjściowe := FormatujDanePracownika
(JednostkiPracy, ProduktPracy)

background image

Komunikat

65

background image

Rodzaje komunikatów

66

komunikat opcjonalny

komunikat utracony

komunikat znaleziony

komunikat oczekujący

background image

Rodzaje komunikatów

67

Komunikat synchroniczny oznacza przekazanie sterowanie od klasyfikatora-
nadawcy do klasyfikatora-odbiorcy. W momencie przesłania tego komunikatu
aktualny przepływ sterowania nadawcy ulega przerwaniu – jest on wznawiany
dopiero po wykonaniu przez odbiorcę operacji wskazanej w komunikacie.

Komunikat asynchroniczny nie powodują przerwania aktualnego przepływu
sterowania nadawcy. Instancja klasyfikatora nadawcy nie oczekuje na
odpowiedź, zatem pozostaje w stanie aktywności, co umożliwia jej dalsze
przetwarzanie lub wysyłanie komunikatów.

Komunikaty zwrotne (opcjonalnie zaznaczane) wskazują na powrót sterowania
do instancji klasyfikatora nadawcy po wykonaniu komunikatu synchronicznego.
Funkcją komunikatu zwrotnego nie jest tylko przekazanie sterowania do danej
instancji, ale też zainicjowanie jej określonej operacji. (zmieńCenę – zwrot:
wyświetl(„Cena uaktualniona”)

Komunikat utracony, występuje wtedy, gdy nadawca jest znany, a odbiorca
jest nieznany

Komunikat znaleziony, występuje wtedy, gdy znany jest odbiorca, a nie jest
znany nadawca

Komunikat opcjonalny, oznacza, że nadawca wysłał do odbiorcy komunikat,
oczekując gotowości do jego niezwłocznej obsługi przez odbiorcę. Jeżeli
komunikat nie może zostać przyjęty w danej chwili przez odbiorcę nie zostaje
wykonany.

Komunikat oczekujący, różni się od opcjonalnego tym, że może poczekać na
obsłużenie przez określony odcinek czasu.

background image

Samowywołanie

68

background image

Warunek

69

background image

Rozgałęzienie

70

Klasyfikator – nadawca kilka klasyfikatorów – odbiorców

[warunek]

background image

Rozgałęzienie

71

Klasyfikator – nadawca jeden klasyfikator-odbiorca z
rozszczepioną linią życia

[warunek]

background image

Fragmenty wyodrębnione i operatory interakcji

72

background image

Alternatywa alt

73

background image

Opcja opt

74

background image

Iteracja loop

75

background image

76

background image

77

background image

Łączenie klasyfikatorów

78

background image

RUP (Rational Unified Process)

79

Wykład 5

background image

Agile (Metodyki zwinne)

80

Wykład 6

background image

Rozumienie Agile

81

1.

Ludzie i ich wzajemne interakcje:
w filozofii wytwarzania Agile samoorganizujące się zespoły
oraz ludzka motywacja są bardzo istotne, tak samo jak w
przypadku programowania parami czy kolokacji.

2.

Działające oprogramowanie:
działające oprogramowanie (nawet próbka) jest bardziej
przydatna w prezentacji wyników pracy klientowi, niż tylko
sucha dokumentacja i szkice poglądowe

3.

Współpraca z klientem:
wiedząc, że wymagania nie mogą być w pełni pozyskane
podczas pierwszego spotkania z klientem (tj. na początku
cyklu wytwarzania oprogramowania) dlatego ciągła
współpraca z klientem lub udziałowcami projektu jest
niezbędna dla prawidłowego wykonania projektu

4.

Reagowanie na zmiany: wytwarzanie w filozofii Agile jest
skoncentrowane na szybkim reagowaniu na zmiany
i ciągłym wytwarzaniu.

background image

Podstawowe zasady

82

osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania
oprogramowania,

działające oprogramowanie jest dostarczane okresowo
(raczej tygodniowo niż miesięcznie),

podstawową miarą postępu jest działające oprogramowanie,

późne zmiany w specyfikacji nie mają destrukcyjnego wpływu
na proces wytwarzania oprogramowania,

bliska, dzienna współpraca pomiędzy biznesem a developerem,

bezpośredni kontakt, jako najlepsza forma komunikacji w
zespole i poza nim,

ciągła uwaga nastawiona na aspekty techniczne oraz dobry
projekt (design),

prostota,

samozarządzalność zespołów,

regularna adaptacja do zmieniających się wymagań.

background image

Najważniejszy element:

zespół projektowy

83

Mały zespół bez hierarchizacji jak w

przypadku firm korporacyjnych.

Niezbędna częsta (codzienna) komunikacja

między członkami zespołu.

Niezbędne wspólne wypracowywanie

decyzji.

Niezbędne jednakowe zaangażowanie

członków zespołu w realizacji kolejnych
iteracji projektu oraz ustalanie planu
działań.

background image

Praca

84

Perspektywa czasowa: tydzień (max 4 tygodnie)

Codzienne spotkania: max 15 min

Grupa robocza: od 5 do 9 osób

Grupa uczestników: ‘pośrednik/kontakt’ klienta +
udziałowcy

Odpowiedzialność: każdy przyjmuje grupę zadań do
wykonania i z niej się rozlicza

Wymagania: konieczność ustalenia listy priorytetów
dla całej grupy w porozumieniu z klientem

Wynik: prezentacja wykonanego/działającego
fragmentu oprogramowania

background image

85

Proces iteracyjny/przyrostowy w Agile

background image

Metody filozofii Agile

86

Programowanie extremalne

Scrum

Dynamic Systems Developement Method

Adaptive Software Developement

Crystal Clear

Feature Driven Developement

Pragmatic Programming

Light Agile Developement

background image

Programowanie ekstremalne
(eXtrem Programming, XP)

87

Podejście stosowane do projektów o

wysokim ryzyku, gdzie nie do końca
wiadomo co i jak wytwarzać

Opiera się o dobre praktyki pozyskane

z projektów, które zakończyły się sukcesem

Dobiera się i tworzy hybrydy różnych

metod prowadzenia projektów, dogodnych
w danym momencie wytwarzania

Prowadzone w małych zespołach max 8

osobowych

background image

Programowanie ekstremalne:
główne zasady

88

Wytwarzać iteracyjnie

Nie projektować z góry: architektura systemu nie jest znana i należy ją
rozbudowywać w miarę przyrostu koncepcji efektu końcowego.

Prowadzić testy jednostkowe: testy jednostkowe pisze się zanim
jeszcze zacznie pisać się kod – najlepiej na początku iteracji. Potem pisze
się kod, który potrafi je wszystkie przejść.

Modyfikować architekturę: architektura systemu nie jest sztywnym
tworem i jeżeli jej modyfikacja nie pogorszy wyników testów
przeprowadzonych w poprzedniej iteracji to należy w razie konieczności ją
zmienić.

Programowanie parami: programiści pracują na przemiennie przy
pisaniu kodu, przy czym jeden zawsze fizycznie wklepuje kod, a drugi w
tym czasie go czyta, weryfikuje, wyłapuje błędy, zadaje pytania kontrolne.

Stały kontakt z klientem

Wady: brak dokładnej specyfikacji, konieczna stała dostępność klienta,
wspólna własność kodu – każdy może zmieniać dowolny fragment
systemu.

background image

Scrum developement

89

Rozwój produktu podzielony jest na mniejsze, trwające od dwóch to
czterech (max sześciu) tygodni fazy zwane sprintami. Fazy te
następują bezpośrednio po sobie.

Po każdy sprincie zespół powinien być w stanie dostarczyć działający
prototyp projektu.

Obowiązuje zasada, że zmiany wprowadzone w każdym sprincie muszą
być namacalne dla klienta, muszą wnosić wartość funkcjonalną.

Zaleca się stosowanie przebiegu o stałych długościach czasu trwania.

Zespół roboczy jest ciałem samoorganizującym się, nie istnieje odgórne
przypisywanie zadań, członkowie sami dobierają sobie zadania i
realizują je w danym sprincie.

background image

Scrum developement: zasady

90

Proces iteracji obejmuje:

Zebranie wymagań w postaci ‘historyjek’, z których każda
opisuje jedną cechę sytemu; klient jest zobowiązany dostarczyć
listę priorytetów realizacji funkcji systemu oraz głównego celu
danego sprintu Budowany jest rejestr wymagań, a cel sprintu
zapisywany jest w widocznym miejscu w pokoju roboczym.

Wybór priorytetów w danym sprincie, szacowanie czasu
realizacji każdego zadania. Lista zadań razem z czasem
przebiegu nosi nazwę rejestru zadań przebiegu sprint
backlog.

W trakcie realizacji sprintu nie można modyfikować jego
zawartości ani przebiegu.

Codziennie odbywają się tzw. scrum meeting (max 15 min)

Sprint kończy się tzw. sprint review, na którym prezentowany
jest wynik pracy zespołu w postaci zrealizowanego fragmentu
systemu. Powinni w nim uczestniczyć wszyscy zainteresowani
projektem.

background image

Scrum developement: role

91

Trzy główne role w Scrum:

Scrum Master –

osoba odpowiedzialna za umożliwianie

członkom zespołu bezzakłóceniowego wykonywania zadań

Product Owner –

przedstawiciel klienta, który może być

członkiem drużyny, ale nie zaleca się by był Scrum Masterem.

Scrum Team –

zespół projektowy obejmujący od 5 do 9

osób, odpowiedzialny za dostarczenie produktu


Document Outline


Wyszukiwarka

Podobne podstrony:
Analiza systemów informatycznych, Wykład 2, UML
Analiza systemów informatycznych, Wykład 3, Podejście obiektowe
Analiza systemów informatycznych, Wykład 4, Model Statyczny
Podstawy Informatyki Wykład V Struktury systemów komputerowych
Wykład VII, politechnika infa 2 st, Projektowanie Systemów Informatycznych
System informatyczny zarządzania, WSB Bydgoszcz, Informatyka wykłady
Systemy operacyjne - wykłady, Administracja, Administracja, Administracja i samorząd, Polityka spole
GIS-ściąga, studia ochrony środowiska, GIS Systemy Informacji Środowiskowych, GIS
Cykl życia systemu informatycznego, WSB Bydgoszcz, Informatyka wykłady
Wykład 2, Systemy informacyjne w zarządzaniu
Wyklad2 Modele systemów informatycznych zarządzania
Internet jako środowisko informacyjne wykłady
System Informacyjny, WSB Bydgoszcz, Informatyka wykłady
Wykład XI, politechnika infa 2 st, Projektowanie Systemów Informatycznych
Wykład VII, politechnika infa 2 st, Projektowanie Systemów Informatycznych
Wykład XII, politechnika infa 2 st, Projektowanie Systemów Informatycznych
System Informacyjny def, WSB Bydgoszcz, Informatyka wykłady
SIP WYKład, Systemy informacji przestrzennej (SIP)
Systemy informacji przestrzennej- notatki z wykładów, Geodezja i Kartografia UWMSC, Systemy Informac

więcej podobnych podstron