treść wykładów 6 i 7.
This commit is contained in:
parent
775d03aee2
commit
43f149c7b4
@ -6,7 +6,7 @@
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciagła integracja</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
@ -36,7 +36,7 @@
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Nasz prototyp\n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany prototyp za pomocą zaktualizowanej w stosunku do laboratorium nr 2 makiety dynamicznej. \n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany system za pomocą prototypu papierowego.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
@ -78,7 +78,7 @@
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "06. Prototypowanie i ciagła integracja[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
|
||||
@ -36,7 +36,7 @@
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Nasz prototyp\n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany prototyp za pomocą zaktualizowanej w stosunku do laboratorium nr 2 makiety dynamicznej. \n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany system za pomocą prototypu papierowego.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
|
||||
@ -14,6 +14,11 @@
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -22,7 +27,76 @@
|
||||
" \n",
|
||||
"<h3>Zakres systemu informatycznego</h3>\n",
|
||||
" \n",
|
||||
"Zakres systemu to precyzyjne określony obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co jest zadaniem projektowym kogoś innego, lub tego, co leży poza projektem.\n",
|
||||
"Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).\n",
|
||||
"\n",
|
||||
"Zakres <b> funkcjonalny </b>– zestaw usług oferowanych przez system.\n",
|
||||
"\n",
|
||||
"Zakres <b> projektowy </b>– zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Jak zdefiniować zakres projektu?\n",
|
||||
"\n",
|
||||
"Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:\n",
|
||||
"\n",
|
||||
"1. Określenie ogólnego zakresu projektu, a w nim:\n",
|
||||
"\n",
|
||||
" * Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu\n",
|
||||
" * Charakterystyka wykonawców\n",
|
||||
" * Lista „wykonawca-cel”\n",
|
||||
" * Lista „in-out”\n",
|
||||
"\n",
|
||||
"2. Specyfikacja wymagań\n",
|
||||
" * Wymagania funkcjonalne\n",
|
||||
" * Wymaganie niefunkcjonalne\n",
|
||||
" \n",
|
||||
"3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Określenie ogólnego zakresu projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Uczestnicy i wykonawcy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Uczestnik</h3>\n",
|
||||
" \n",
|
||||
"Uczestnik – ktoś lub coś, mający interes związany z zachowaniem systemu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"Uczestnik może być osobą, firmą lub przedsiębiorstwem, programem komputerowym lub systemem komputerowym.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Wykonawca</h3>\n",
|
||||
" \n",
|
||||
"<b> Wykonawca </b> to Uczestnik, który kontaktuje się z systemem.\n",
|
||||
"\n",
|
||||
"<b> Wykonawca główny </b> to Wykonawca, który kontaktuje się z systemem w celu uzyskania jednej z jego usług. Wykonawca główny najczęściej rozpoczyna przypadek użycia. \n",
|
||||
"\n",
|
||||
"<b> Wykonawca pomocniczy </b> to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
@ -31,12 +105,55 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Reprezentacje zakresu projektu\n",
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Uczestnik ma interesy. \n",
|
||||
"Wykonawca ma zachowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Charakterystyka wykonawców\n",
|
||||
"Charakterystykę wykonawców można opisać za pomocą tabeli. \n",
|
||||
"\n",
|
||||
"* Określenie wizji\n",
|
||||
"* Diagram zakresu projektowego (rysunek)\n",
|
||||
"* Lista „aktor-cel”\n",
|
||||
"* Lista „in-out”"
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawcy.png\" alt=\"Lista Wykonawców\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista Wykonawca-Cel\n",
|
||||
"Na podstawie charakterystyki wykonawców oraz zakresu systemu tworzy się listę **Wykonawca - Cel**, w której dla każdego typu wykonawców określa się cele, jakie wykonawca stawia przed systemem. \n",
|
||||
"\n",
|
||||
"Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: **Uczestnik – Cel**. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawca-cel.png\" alt=\"Lista wykonawca-cel\" width=600px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista In-Out\n",
|
||||
"Na podstawie listy Wykonawca-Cel, biorąc pod uwagę priorytety celów, tworzy się listę In-Out, która precyzyjnie określa zakres systemu. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"<img src=\"obrazy/in-out.png\" alt=\"Lista In-Out\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Specyfikacja wymagań"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -53,27 +170,96 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymagania użytkownika a wymagania systemowe\n",
|
||||
"### Wymagania użytkownika\n",
|
||||
"**Wymagania użytkownika** to ogólny opis oczekiwań względem systemu w języku naturalnym, będacy rezultatem wstępnych rozmów wykonawcy z zamawiającym lub użytkownikiem.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * menedżerów zamwiającego.\n",
|
||||
" * menedżerów wykonawcy,\n",
|
||||
" * potencjalnych użytkowników systemu.\n",
|
||||
" \n",
|
||||
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"### Wymagania funkcjonalne a wymagania niefunkcjonalne"
|
||||
"<img src=\"obrazy/wymagania użytkownika.png\" alt=\"Przykład wymagań użytkownika\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymaganie systemowe\n",
|
||||
"**Wymagania systemowe** to sformalizowany opis oczekiwań względem systemu.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * inżynierów zamwiającego,\n",
|
||||
" * twórców oprogramowania, \n",
|
||||
" * architektów systemu. \n",
|
||||
" \n",
|
||||
"Wymagania systemowe dzielą się na:\n",
|
||||
" * funkcjonalne,\n",
|
||||
" * niefunkcjonalne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania funkcjonalne\n",
|
||||
" * Opisują funkcje (czynności, operacje) wykonywane przez system.\n",
|
||||
" * Dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem.\n",
|
||||
" \n",
|
||||
"Przykłady wymagań funkcjonalnych (system do prowadzenia testów na wykładzie):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne1.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne2.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania niefunkcjonalne\n",
|
||||
" * Opisują warunki, przy których system musi realizować swoje funkcje:\n",
|
||||
" * Wymagania dotyczące produktu\n",
|
||||
" * Wymagania dotyczące procesu\n",
|
||||
" * Wymagania zewnętrzne\n",
|
||||
" * Wymagania niefunkcjonalne powinny być weryfikowalne. Realizowane jest to przy pomocy systemu miar opisujących wymagane cechy systemu.\n",
|
||||
"\n",
|
||||
"Przykłady miar wymagań niefunkcjonalnych:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/miary.png\" alt=\"Przykłady miar wymagań niefunkcjonalnych\" width=600px>\n",
|
||||
"\n",
|
||||
"Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania niefunkcjonalne.png\" alt=\"Przykład wymagań niefunkcjonalnych\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przypadek użycia</h3>\n",
|
||||
"<h3>Przypadek użycia (PU) </h3>\n",
|
||||
" \n",
|
||||
"Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li>W przypadku użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie jednego z uczestników, zwanego aktorem głównym.</li>\n",
|
||||
"<li>Przypadek użycia reprezentowany jest przez sekwencję akcji realizowanych przez system analizowany, które dają zauważalny efekt. Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"<li>Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.\n",
|
||||
" <li>Przypadek użycia reprezentowany jest przez sekwencję <b> akcji </b> realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
@ -82,17 +268,183 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Elementy składowe opisu przypadku użycia\n",
|
||||
"1. Aktor główny\n",
|
||||
"2. Zakres \n",
|
||||
"3. Poziom celu\n",
|
||||
"4. Uczestnicy i interesy\n",
|
||||
"5. Warunek początkowy\n",
|
||||
"6. Wyzwalacz\n",
|
||||
"7. Gwarancje minimalne\n",
|
||||
"8. Gwarancja powodzenia\n",
|
||||
"9. Scenariusz powodzenia\n",
|
||||
"10. Rozszerzenia scenariusza"
|
||||
"## Elementy składowe opisu przypadku użycia \n",
|
||||
"1. Wykonawca główny (który rozpoczyna wykonanie przypadku użycia)\n",
|
||||
"2. Poziom celu\n",
|
||||
"3. Warunkie początkowe\n",
|
||||
"4. Wyzwalacz\n",
|
||||
"5. Gwarancje minimalne\n",
|
||||
"6. Gwarancja powodzenia\n",
|
||||
"7. Scenariusz powodzenia\n",
|
||||
"8. Rozszerzenia scenariusza"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1. Przypadek użycia. Poziom celu\n",
|
||||
"Poziom celu określa stopień ogólności przypadku użycia:\n",
|
||||
" * Poziom streszczenia – najbardziej ogólny,\n",
|
||||
" * Poziom użytkownika – pośredni,\n",
|
||||
" * Poziom podfunkcji – najbardziej szczegółowy.\n",
|
||||
" \n",
|
||||
"#### Poziom streszczenia\n",
|
||||
"Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:\n",
|
||||
" * Pokazują kolejność działania przypadków użycia niższego poziomu,\n",
|
||||
" * Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom streszczenia.png\" alt=\"Przykład przypadku użycia o poziomie streszczenia\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom użytkownika\n",
|
||||
"Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć aktor główny, żeby wykonać swoje zadanie. \n",
|
||||
" * Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.\n",
|
||||
" * Przypadki te są najbardziej warte opisania w specyfikacji.\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie użytkownika:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom użytkownika.png\" alt=\"Przykład przypadku użycia o poziomie użytkownika\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom podfunkcji\n",
|
||||
"Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.\n",
|
||||
" * Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).\n",
|
||||
" * Trzy przykłady przypadków użycia o poziomie podfunkcji:\n",
|
||||
" > Wybierz odpowiedź na pytanie testowe. \n",
|
||||
" > Przejdź do następnego pytania. \n",
|
||||
" > Zaloguj się w systemie. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Przypadek użycia. Warunki początkowe\n",
|
||||
"**Warumek początkowy** to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia. \n",
|
||||
" * Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku. \n",
|
||||
" * Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia. \n",
|
||||
" \n",
|
||||
" Przykład warunku początkowego (system do testów):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/warunek początkowy.png\" alt=\"Przykład warunku początkowego\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Przypadek użycia. Wyzwalacz\n",
|
||||
"**Wyzwalacz** to zdarzenie, które automatycznie powoduje rozpoczęcie przypadku użycia.\n",
|
||||
"\n",
|
||||
" Przykłady wyzwalaczy (system do testów):\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/wyzwalacze.png\" alt=\"Przykłady wyzwalaczy\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.4. Przypadek użycia. Gwarancje minimalne\n",
|
||||
"**Gwarancje minimalne** to najmniejsze obietnice składane przez system.\n",
|
||||
" * Są realizowane zarówno wtedy, gdy cel aktora głównego jest spełniony (scenariusz powodzenia) i gdy nie jest on spełniony. (Szczególnie w tym drugim przypadku minimalne gwarancje są istotne).\n",
|
||||
" * Zapisywane są w postaci kilku stwierdzeń, które będą na pewno prawdziwe po zakończeniu przypadku użycia.\n",
|
||||
" \n",
|
||||
" Przykłady gwarancji minimalnych:\n",
|
||||
" <img src=\"obrazy/gwarancje minimalne.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Przypadek użycia. Gwarancja powodzenia\n",
|
||||
"**Gwarancja powodzenia** ustala, jakie interesy uczestników są zaspokojone po udanym zakończeniu przypadku użycia (scenariusz powodzenia).\n",
|
||||
" * Zapisywana jest w postaci prostych stwierdzeń, opisujących świat po udanym zakończeniu przypadku użycia.\n",
|
||||
" * Często ma postać rozszerzenia minimalnych gwarancji.\n",
|
||||
" \n",
|
||||
"Przykłady gwarancji powodzenia:\n",
|
||||
"\n",
|
||||
" <img src=\"obrazy/gwarancja powodzenia.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.6. Przypadek użycia. Scenariusz powodzenia\n",
|
||||
"**Scenariusz powodzenia** to ciąg akcji od rozpoczęcia do zakończenia przypadku użycia, który realizuje gwarancje powodzenia.\n",
|
||||
"Scenariusz powodzenia opisuje najbardziej typowe zachowanie systemu i nie bierze pod uwagę zdarzeń niesprzyjających.\n",
|
||||
"#### Wskazówki przy pisaniu scenariusza powodzenia\n",
|
||||
"\n",
|
||||
"##### 1. Używaj prostych składni zdań\n",
|
||||
"<img src=\"obrazy/prosta składnia.png\" alt=\"Przykład prostej składni\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n",
|
||||
"<img src=\"obrazy/podmiot.png\" alt=\"Przykład podmiotu czynności\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 3. Pisz \"z lotu ptaka\"\n",
|
||||
"<img src=\"obrazy/lot ptaka.png\" alt=\"Przykład z lotu ptaka\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 4. Przesuwaj proces wyraźnie do przodu\n",
|
||||
"<img src=\"obrazy/proces.png\" alt=\"Przykład przesuwania procesu\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n",
|
||||
"<img src=\"obrazy/że.png\" alt=\"Przykład stwierdzania że\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n",
|
||||
"<img src=\"obrazy/odwołania.png\" alt=\"Przykłady odwołania\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n",
|
||||
"<img src=\"obrazy/iteracje.png\" alt=\"Przykłady iteracji\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Przypadek użycia. Rozszerzenia scenariusza\n",
|
||||
"**Rozszerzenie scenariusza** to niestandardowe zachowanie systemu, które\n",
|
||||
" * zaczyna się w konkretnym kroku w scenariuszu powodzenia,\n",
|
||||
" * gdy zdarzają się niestandardowe sytuacje – zwane **warunkami rozszerzenia scenariusza**.\n",
|
||||
" \n",
|
||||
"#### Warunki rozszerzenia scenariusza\n",
|
||||
"**Warunki rozszerzenie scenariusza** to sytuacje, w których system zachowuje się inaczej, niż to przewidziano w scenariuszu powodzenia.\n",
|
||||
"* Warunki rozszerzenia sformułowane są z punktu widzenia systemu (co system może wykryć, a nie - co się stało).\n",
|
||||
"<img src=\"obrazy/warunki rozszerzenia.png\" alt=\"Przykłady warunku rozszerzenia\" width=300px>\n",
|
||||
"\n",
|
||||
"##### Jak znajdować potencjalne rozszerzenia scenariusza?\n",
|
||||
" * Przemyśl alternatywne ścieżki scenariusza, np.\n",
|
||||
" * Wykonawca głóny postępuje niepoprawnie\n",
|
||||
" * Brak działania wykonawcy głównego\n",
|
||||
" * Wykonawca pomocniczy reaguje z opóźnieniem\n",
|
||||
" * Przeanalizuj wszystkie wystąpienia wyrażeń typu „System stwierdza, że...”\n",
|
||||
" * Przeanalizuj sytuacje awaryjne\n",
|
||||
" * Awarie wewnętrzne projektowanego systemu, które należy wykryć i obsłużyć\n",
|
||||
" * Awarie wewnętrzne systemu, które wystarczy wykryć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie - jak stworzyć specyfikację systemu informatycznego?\n",
|
||||
" 1. Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu \n",
|
||||
" 2. Charakterystyka wykonawców \n",
|
||||
" 3. Lista „wykonawca-cel” \n",
|
||||
" 4. Lista „in-out” \n",
|
||||
" 5. Wymagania funkcjonalne \n",
|
||||
" 6. Wymaganie niefunkcjonalne \n",
|
||||
" 7. Opis przypadków użycia "
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -79,8 +79,8 @@
|
||||
" * Zmiana - projekt to środek do przeprowadzenia zmiany.\n",
|
||||
" * Tymczasowość - projekt ma swoją datę początku i końca.\n",
|
||||
" * Wielofukcyjność - przy projektach zaangażowani są ludzie o różnych kompetencjach.\n",
|
||||
" * Wyjątkowość - każdy projekt jest wyjątkowy (nawet jak jest jakiś wzorzec projektu, to każdy projekt się czymś wyróżnia: albo zespołem, albo klientem, albo położeniem geograficznym, itp.\n",
|
||||
" * Niepewność - projekty ze swojej natury są ryzykowne, bo mają wprowadzić zmianę."
|
||||
" * Wyjątkowość - każdy projekt jest wyjątkowy (nawet jak jest jakiś wzorzec projektu, to każdy projekt się czymś wyróżnia: albo zespołem, albo klientem, albo położeniem geograficznym, itp.)\n",
|
||||
" * Ryzyko (niepewność) - projekty ze swojej natury są ryzykowne, bo mają wprowadzić zmianę."
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -146,6 +146,7 @@
|
||||
" * skrupulatne zbieranie wymagań\n",
|
||||
" * dokładną analizę\n",
|
||||
" * istotność dokumentacji.\n",
|
||||
" \n",
|
||||
"Sprawdzają się w projektach z dobrze określonymi wymaganiami już od początku. \n",
|
||||
"Produkt ma być realizowany i dostarczony zgodnie z określonym planem. W planowaniu nie analizuje się szczegółowo, w jaki sposób produkt ma być wykonany. "
|
||||
]
|
||||
|
||||
@ -257,12 +257,12 @@
|
||||
" \n",
|
||||
"3. **Build on your machine**\n",
|
||||
"\n",
|
||||
"* **Repeat** \n",
|
||||
" * Kompiluję swój kod i buduję wersję wykonywalną,\n",
|
||||
" * Przeprowadzam testy jednostkowe,\n",
|
||||
"* **Until**\n",
|
||||
" * Kod się skompilował poprawnie oraz\n",
|
||||
" * Testy zakończyły się powodzeniem.\n",
|
||||
" * **Repeat** \n",
|
||||
" * Kompiluję swój kod i buduję wersję wykonywalną,\n",
|
||||
" * Przeprowadzam testy jednostkowe,\n",
|
||||
" * **Until**\n",
|
||||
" * Kod się skompilował poprawnie oraz\n",
|
||||
" * Testy zakończyły się powodzeniem.\n",
|
||||
" \n",
|
||||
"4. **Integrate with Repository**\n",
|
||||
"\n",
|
||||
@ -451,7 +451,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
"version": "3.7.6"
|
||||
},
|
||||
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
|
||||
@ -14,6 +14,11 @@
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -22,7 +27,76 @@
|
||||
" \n",
|
||||
"<h3>Zakres systemu informatycznego</h3>\n",
|
||||
" \n",
|
||||
"Zakres systemu to precyzyjne określony obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co jest zadaniem projektowym kogoś innego, lub tego, co leży poza projektem.\n",
|
||||
"Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).\n",
|
||||
"\n",
|
||||
"Zakres <b> funkcjonalny </b>– zestaw usług oferowanych przez system.\n",
|
||||
"\n",
|
||||
"Zakres <b> projektowy </b>– zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Jak zdefiniować zakres projektu?\n",
|
||||
"\n",
|
||||
"Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:\n",
|
||||
"\n",
|
||||
"1. Określenie ogólnego zakresu projektu, a w nim:\n",
|
||||
"\n",
|
||||
" * Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu\n",
|
||||
" * Charakterystyka wykonawców\n",
|
||||
" * Lista „wykonawca-cel”\n",
|
||||
" * Lista „in-out”\n",
|
||||
"\n",
|
||||
"2. Specyfikacja wymagań\n",
|
||||
" * Wymagania funkcjonalne\n",
|
||||
" * Wymaganie niefunkcjonalne\n",
|
||||
" \n",
|
||||
"3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Określenie ogólnego zakresu projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Uczestnicy i wykonawcy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Uczestnik</h3>\n",
|
||||
" \n",
|
||||
"Uczestnik – ktoś lub coś, mający interes związany z zachowaniem systemu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"Uczestnik może być osobą, firmą lub przedsiębiorstwem, programem komputerowym lub systemem komputerowym.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Wykonawca</h3>\n",
|
||||
" \n",
|
||||
"<b> Wykonawca </b> to Uczestnik, który kontaktuje się z systemem.\n",
|
||||
"\n",
|
||||
"<b> Wykonawca główny </b> to Wykonawca, który kontaktuje się z systemem w celu uzyskania jednej z jego usług. Wykonawca główny najczęściej rozpoczyna przypadek użycia. \n",
|
||||
"\n",
|
||||
"<b> Wykonawca pomocniczy </b> to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
@ -31,12 +105,55 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Reprezentacje zakresu projektu\n",
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Uczestnik ma interesy. \n",
|
||||
"Wykonawca ma zachowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Charakterystyka wykonawców\n",
|
||||
"Charakterystykę wykonawców można opisać za pomocą tabeli. \n",
|
||||
"\n",
|
||||
"* Określenie wizji\n",
|
||||
"* Diagram zakresu projektowego (rysunek)\n",
|
||||
"* Lista „aktor-cel”\n",
|
||||
"* Lista „in-out”"
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawcy.png\" alt=\"Lista Wykonawców\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista Wykonawca-Cel\n",
|
||||
"Na podstawie charakterystyki wykonawców oraz zakresu systemu tworzy się listę **Wykonawca - Cel**, w której dla każdego typu wykonawców określa się cele, jakie wykonawca stawia przed systemem. \n",
|
||||
"\n",
|
||||
"Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: **Uczestnik – Cel**. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawca-cel.png\" alt=\"Lista wykonawca-cel\" width=600px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista In-Out\n",
|
||||
"Na podstawie listy Wykonawca-Cel, biorąc pod uwagę priorytety celów, tworzy się listę In-Out, która precyzyjnie określa zakres systemu. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"<img src=\"obrazy/in-out.png\" alt=\"Lista In-Out\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Specyfikacja wymagań"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -53,27 +170,96 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymagania użytkownika a wymagania systemowe\n",
|
||||
"### Wymagania użytkownika\n",
|
||||
"**Wymagania użytkownika** to ogólny opis oczekiwań względem systemu w języku naturalnym, będacy rezultatem wstępnych rozmów wykonawcy z zamawiającym lub użytkownikiem.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * menedżerów zamwiającego.\n",
|
||||
" * menedżerów wykonawcy,\n",
|
||||
" * potencjalnych użytkowników systemu.\n",
|
||||
" \n",
|
||||
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"### Wymagania funkcjonalne a wymagania niefunkcjonalne"
|
||||
"<img src=\"obrazy/wymagania użytkownika.png\" alt=\"Przykład wymagań użytkownika\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymaganie systemowe\n",
|
||||
"**Wymagania systemowe** to sformalizowany opis oczekiwań względem systemu.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * inżynierów zamawiającego,\n",
|
||||
" * twórców oprogramowania, \n",
|
||||
" * architektów systemu. \n",
|
||||
" \n",
|
||||
"Wymagania systemowe dzielą się na:\n",
|
||||
" * funkcjonalne,\n",
|
||||
" * niefunkcjonalne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania funkcjonalne\n",
|
||||
" * Opisują funkcje (czynności, operacje) wykonywane przez system.\n",
|
||||
" * Dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem.\n",
|
||||
" \n",
|
||||
"Przykłady wymagań funkcjonalnych (system do prowadzenia testów na wykładzie):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne1.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne2.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania niefunkcjonalne\n",
|
||||
" * Opisują warunki, przy których system musi realizować swoje funkcje:\n",
|
||||
" * Wymagania dotyczące produktu\n",
|
||||
" * Wymagania dotyczące procesu\n",
|
||||
" * Wymagania zewnętrzne\n",
|
||||
" * Wymagania niefunkcjonalne powinny być weryfikowalne. Realizowane jest to przy pomocy systemu miar opisujących wymagane cechy systemu.\n",
|
||||
"\n",
|
||||
"Przykłady miar wymagań niefunkcjonalnych:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/miary.png\" alt=\"Przykłady miar wymagań niefunkcjonalnych\" width=600px>\n",
|
||||
"\n",
|
||||
"Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania niefunkcjonalne.png\" alt=\"Przykład wymagań niefunkcjonalnych\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przypadek użycia</h3>\n",
|
||||
"<h3>Przypadek użycia (PU) </h3>\n",
|
||||
" \n",
|
||||
"Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li>W przypadku użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie jednego z uczestników, zwanego aktorem głównym.</li>\n",
|
||||
"<li>Przypadek użycia reprezentowany jest przez sekwencję akcji realizowanych przez system analizowany, które dają zauważalny efekt. Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"<li>Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.\n",
|
||||
" <li>Przypadek użycia reprezentowany jest przez sekwencję <b> akcji </b> realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
@ -82,17 +268,183 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Elementy składowe opisu przypadku użycia\n",
|
||||
"1. Aktor główny\n",
|
||||
"2. Zakres \n",
|
||||
"3. Poziom celu\n",
|
||||
"4. Uczestnicy i interesy\n",
|
||||
"5. Warunek początkowy\n",
|
||||
"6. Wyzwalacz\n",
|
||||
"7. Gwarancje minimalne\n",
|
||||
"8. Gwarancja powodzenia\n",
|
||||
"9. Scenariusz powodzenia\n",
|
||||
"10. Rozszerzenia scenariusza"
|
||||
"## Elementy składowe opisu przypadku użycia \n",
|
||||
"1. Wykonawca główny (który rozpoczyna wykonanie przypadku użycia)\n",
|
||||
"2. Poziom celu\n",
|
||||
"3. Warunki początkowe\n",
|
||||
"4. Wyzwalacz\n",
|
||||
"5. Gwarancje minimalne\n",
|
||||
"6. Gwarancja powodzenia\n",
|
||||
"7. Scenariusz powodzenia\n",
|
||||
"8. Rozszerzenia scenariusza"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1. Przypadek użycia. Poziom celu\n",
|
||||
"Poziom celu określa stopień ogólności przypadku użycia:\n",
|
||||
" * Poziom streszczenia – najbardziej ogólny,\n",
|
||||
" * Poziom użytkownika – pośredni,\n",
|
||||
" * Poziom podfunkcji – najbardziej szczegółowy.\n",
|
||||
" \n",
|
||||
"#### Poziom streszczenia\n",
|
||||
"Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:\n",
|
||||
" * Pokazują kolejność działania przypadków użycia niższego poziomu,\n",
|
||||
" * Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom streszczenia.png\" alt=\"Przykład przypadku użycia o poziomie streszczenia\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom użytkownika\n",
|
||||
"Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć wykonawca główny, żeby wykonać swoje zadanie. \n",
|
||||
" * Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.\n",
|
||||
" * Przypadki te są najbardziej warte opisania w specyfikacji.\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie użytkownika:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom użytkownika.png\" alt=\"Przykład przypadku użycia o poziomie użytkownika\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom podfunkcji\n",
|
||||
"Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.\n",
|
||||
" * Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).\n",
|
||||
" * Trzy przykłady przypadków użycia o poziomie podfunkcji:\n",
|
||||
" > Wybierz odpowiedź na pytanie testowe. \n",
|
||||
" > Przejdź do następnego pytania. \n",
|
||||
" > Zaloguj się w systemie. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Przypadek użycia. Warunki początkowe\n",
|
||||
"**Warumek początkowy** to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia. \n",
|
||||
" * Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku. \n",
|
||||
" * Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia. \n",
|
||||
" \n",
|
||||
" Przykład warunku początkowego (system do testów):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/warunek początkowy.png\" alt=\"Przykład warunku początkowego\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Przypadek użycia. Wyzwalacz\n",
|
||||
"**Wyzwalacz** to zdarzenie, które automatycznie powoduje rozpoczęcie przypadku użycia.\n",
|
||||
"\n",
|
||||
" Przykłady wyzwalaczy (system do testów):\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/wyzwalacze.png\" alt=\"Przykłady wyzwalaczy\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.4. Przypadek użycia. Gwarancje minimalne\n",
|
||||
"**Gwarancje minimalne** to najmniejsze obietnice składane przez system.\n",
|
||||
" * Są realizowane zarówno wtedy, gdy cel wykonawcy głównego jest spełniony (scenariusz powodzenia) i gdy nie jest on spełniony. (Szczególnie w tym drugim przypadku minimalne gwarancje są istotne).\n",
|
||||
" * Zapisywane są w postaci kilku stwierdzeń, które będą na pewno prawdziwe po zakończeniu przypadku użycia.\n",
|
||||
" \n",
|
||||
" Przykłady gwarancji minimalnych:\n",
|
||||
" <img src=\"obrazy/gwarancje minimalne.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Przypadek użycia. Gwarancja powodzenia\n",
|
||||
"**Gwarancja powodzenia** ustala, jakie interesy uczestników są zaspokojone po udanym zakończeniu przypadku użycia (scenariusz powodzenia).\n",
|
||||
" * Zapisywana jest w postaci prostych stwierdzeń, opisujących świat po udanym zakończeniu przypadku użycia.\n",
|
||||
" * Często ma postać rozszerzenia minimalnych gwarancji.\n",
|
||||
" \n",
|
||||
"Przykłady gwarancji powodzenia:\n",
|
||||
"\n",
|
||||
" <img src=\"obrazy/gwarancja powodzenia.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.6. Przypadek użycia. Scenariusz powodzenia\n",
|
||||
"**Scenariusz powodzenia** to ciąg akcji od rozpoczęcia do zakończenia przypadku użycia, który realizuje gwarancje powodzenia.\n",
|
||||
"Scenariusz powodzenia opisuje najbardziej typowe zachowanie systemu i nie bierze pod uwagę zdarzeń niesprzyjających.\n",
|
||||
"#### Wskazówki przy pisaniu scenariusza powodzenia\n",
|
||||
"\n",
|
||||
"##### 1. Używaj prostych składni zdań\n",
|
||||
"<img src=\"obrazy/prosta składnia.png\" alt=\"Przykład prostej składni\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n",
|
||||
"<img src=\"obrazy/podmiot.png\" alt=\"Przykład podmiotu czynności\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 3. Pisz \"z lotu ptaka\"\n",
|
||||
"<img src=\"obrazy/lot ptaka.png\" alt=\"Przykład z lotu ptaka\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 4. Przesuwaj proces wyraźnie do przodu\n",
|
||||
"<img src=\"obrazy/proces.png\" alt=\"Przykład przesuwania procesu\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n",
|
||||
"<img src=\"obrazy/że.png\" alt=\"Przykład stwierdzania że\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n",
|
||||
"<img src=\"obrazy/odwołania.png\" alt=\"Przykłady odwołania\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n",
|
||||
"<img src=\"obrazy/iteracje.png\" alt=\"Przykłady iteracji\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Przypadek użycia. Rozszerzenia scenariusza\n",
|
||||
"**Rozszerzenie scenariusza** to niestandardowe zachowanie systemu, które\n",
|
||||
" * zaczyna się w konkretnym kroku w scenariuszu powodzenia,\n",
|
||||
" * gdy zdarzają się niestandardowe sytuacje – zwane **warunkami rozszerzenia scenariusza**.\n",
|
||||
" \n",
|
||||
"#### Warunki rozszerzenia scenariusza\n",
|
||||
"**Warunki rozszerzenie scenariusza** to sytuacje, w których system zachowuje się inaczej, niż to przewidziano w scenariuszu powodzenia.\n",
|
||||
"* Warunki rozszerzenia sformułowane są z punktu widzenia systemu (co system może wykryć, a nie - co się stało).\n",
|
||||
"<img src=\"obrazy/warunki rozszerzenia.png\" alt=\"Przykłady warunku rozszerzenia\" width=300px>\n",
|
||||
"\n",
|
||||
"##### Jak znajdować potencjalne rozszerzenia scenariusza?\n",
|
||||
" * Przemyśl alternatywne ścieżki scenariusza, np.\n",
|
||||
" * Wykonawca głóny postępuje niepoprawnie\n",
|
||||
" * Brak działania wykonawcy głównego\n",
|
||||
" * Wykonawca pomocniczy reaguje z opóźnieniem\n",
|
||||
" * Przeanalizuj wszystkie wystąpienia wyrażeń typu „System stwierdza, że...”\n",
|
||||
" * Przeanalizuj sytuacje awaryjne\n",
|
||||
" * Awarie wewnętrzne projektowanego systemu, które należy wykryć i obsłużyć\n",
|
||||
" * Awarie wewnętrzne systemu, które wystarczy wykryć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie - jak stworzyć specyfikację systemu informatycznego?\n",
|
||||
" 1. Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu \n",
|
||||
" 2. Charakterystyka wykonawców \n",
|
||||
" 3. Lista „wykonawca-cel” \n",
|
||||
" 4. Lista „in-out” \n",
|
||||
" 5. Wymagania funkcjonalne \n",
|
||||
" 6. Wymaganie niefunkcjonalne \n",
|
||||
" 7. Opis przypadków użycia "
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
Loading…
Reference in New Issue
Block a user