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.
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.
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
Klasy systemów
informatycznych
4
Systemy wsparcia przedsiębiorstw
Systemy informowania kierownictwa
Systemy wspomagania decyzji
Systemy ekspertowe (sztuczna inteligencja)
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
Proces wytwarzania oprogramowania
6
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
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
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ń.
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ń.
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.
Specjalne grupy wymagań
12
Ważnym przykładem specyficznej grupy wymagań są
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.
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.
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.
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.
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.
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).
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ę.
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
.
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.
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.
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
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.
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
Model V
25
Modelowanie
Projektowanie
Implementacj
a
Testowanie jednostek
oprogramowania i
integracyjne
Testowanie
walidacyjne i
systemu
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
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
28
Czas
Budżet
Zasob
y
Analiza
wstępna
realizowalnoś
ci
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
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
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ń
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).
Diagramy przypadków użycia
UML
33
Wykład 4
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.
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)
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.
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
…
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ę.
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).
Przykładowy DPU aukcji internetowej
40
Przykładowy DPU obsługi hurtowni
41
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.
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.
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’
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
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.
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.
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.
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.
Diagram kontekstowy
50
Diagram kontekstowy stanowi zestawienie aktorów będących
w interakcji z danym systemem traktowanym w kategorii
pojedynczego procesu.
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.
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
53
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
tó
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.
Diagramy sekwencji – notacja i
semantyka
55
klasyfikator
linia życia
ośrodek sterowania
komunikat
dezaktywacja
aktywacja
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
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
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.
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
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
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.
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.
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.
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)
Komunikat
65
Rodzaje komunikatów
66
komunikat opcjonalny
komunikat utracony
komunikat znaleziony
komunikat oczekujący
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.
Samowywołanie
68
Warunek
69
Rozgałęzienie
70
Klasyfikator – nadawca kilka klasyfikatorów – odbiorców
[warunek]
Rozgałęzienie
71
Klasyfikator – nadawca jeden klasyfikator-odbiorca z
rozszczepioną linią życia
[warunek]
Fragmenty wyodrębnione i operatory interakcji
72
Alternatywa alt
73
Opcja opt
74
Iteracja loop
75
76
77
Łączenie klasyfikatorów
78
RUP (Rational Unified Process)
79
Wykład 5
Agile (Metodyki zwinne)
80
Wykład 6
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.
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ń.
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ń.
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
85
Proces iteracyjny/przyrostowy w Agile
Metody filozofii Agile
86
Programowanie extremalne
Scrum
Dynamic Systems Developement Method
Adaptive Software Developement
Crystal Clear
Feature Driven Developement
Pragmatic Programming
Light Agile Developement
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
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.
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.
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.
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