pilka/aitech-pbr-pilka
1
0
Fork 0
forked from AITech/aitech-ppb-pbr
Code Issues Pull Requests Projects Releases Wiki Activity

treść wykładów 6 i 7.

Browse Source
This commit is contained in:
Krzysztof Jassem 2021-10-30 15:02:00 +02:00
parent 775d03aee2
commit 43f149c7b4
6 changed files with 762 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
materiały na PBR (laboratorium)/.ipynb_checkpoints/06_prototypowanie_i_ciągła_integracja_lab-checkpoint.ipynb
View File

@ -6,7 +6,7 @@
"source": [
"![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\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,

2
materiały na PBR (laboratorium)/06_prototypowanie_i_ciągła_integracja_lab.ipynb
View File

@ -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",

394
materiały na PPB (wykład)/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb
View File

@ -14,6 +14,11 @@
"![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)"
]
},
{
"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",
"* Określenie wizji\n",
"* Diagram zakresu projektowego (rysunek)\n",
"* Lista „aktor-cel”\n",
"* Lista „in-out”"
"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",
"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",
"### Wymagania funkcjonalne a wymagania niefunkcjonalne"
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
"\n",
"<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>"
]
@ -83,16 +269,182 @@
"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"
"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 "
]
}
],

5
materiały na PPB (wykład)/04_metodologia_Prince2.ipynb
View File

@ -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. "
]

2
materiały na PPB (wykład)/06_prototypowanie i ciągła integracja.ipynb
View File

@ -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",

394
materiały na PPB (wykład)/07_specyfikacja_projektu_informatycznego.ipynb
View File

@ -14,6 +14,11 @@
"![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)"
]
},
{
"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",
"* Określenie wizji\n",
"* Diagram zakresu projektowego (rysunek)\n",
"* Lista „aktor-cel”\n",
"* Lista „in-out”"
"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",
"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",
"### Wymagania funkcjonalne a wymagania niefunkcjonalne"
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
"\n",
"<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>"
]
@ -83,16 +269,182 @@
"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"
"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 "
]
}
],