From 43f149c7b4700dff8d03f60f4c344a005d95fe81 Mon Sep 17 00:00:00 2001 From: Krzysztof Jassem Date: Sat, 30 Oct 2021 15:02:00 +0200 Subject: [PATCH] =?UTF-8?q?tre=C5=9B=C4=87=20wyk=C5=82ad=C3=B3w=206=20i=20?= =?UTF-8?q?7.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...i_ciągła_integracja_lab-checkpoint.ipynb | 6 +- ...otypowanie_i_ciągła_integracja_lab.ipynb | 2 +- ..._projektu_informatycznego-checkpoint.ipynb | 396 +++++++++++++++++- .../04_metodologia_Prince2.ipynb | 5 +- ...prototypowanie i ciągła integracja.ipynb | 14 +- ...pecyfikacja_projektu_informatycznego.ipynb | 396 +++++++++++++++++- 6 files changed, 762 insertions(+), 57 deletions(-) diff --git a/materiały na PBR (laboratorium)/.ipynb_checkpoints/06_prototypowanie_i_ciągła_integracja_lab-checkpoint.ipynb b/materiały na PBR (laboratorium)/.ipynb_checkpoints/06_prototypowanie_i_ciągła_integracja_lab-checkpoint.ipynb index 361f8b7..1b25afa 100644 --- a/materiały na PBR (laboratorium)/.ipynb_checkpoints/06_prototypowanie_i_ciągła_integracja_lab-checkpoint.ipynb +++ b/materiały na PBR (laboratorium)/.ipynb_checkpoints/06_prototypowanie_i_ciągła_integracja_lab-checkpoint.ipynb @@ -6,7 +6,7 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Projekt badawczo-rozwojowy

\n", "

6. Prototypowanie i ciagła integracja[laboratorium]

\n", "

Krzysztof Jassem (2021)

\n", "
\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, diff --git a/materiały na PBR (laboratorium)/06_prototypowanie_i_ciągła_integracja_lab.ipynb b/materiały na PBR (laboratorium)/06_prototypowanie_i_ciągła_integracja_lab.ipynb index 297bfe2..1b25afa 100644 --- a/materiały na PBR (laboratorium)/06_prototypowanie_i_ciągła_integracja_lab.ipynb +++ b/materiały na PBR (laboratorium)/06_prototypowanie_i_ciągła_integracja_lab.ipynb @@ -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", diff --git a/materiały na PPB (wykład)/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb b/materiały na PPB (wykład)/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb index 779640f..a151ae0 100644 --- a/materiały na PPB (wykład)/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb +++ b/materiały na PPB (wykład)/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb @@ -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", "

Zakres systemu informatycznego

\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 funkcjonalny – zestaw usług oferowanych przez system.\n", + "\n", + "Zakres projektowy – zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n", + "" + ] + }, + { + "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": [ + "
\n", + "

Uczestnik

\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", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Wykonawca

\n", + " \n", + " Wykonawca to Uczestnik, który kontaktuje się z systemem.\n", + "\n", + " Wykonawca główny 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", + " Wykonawca pomocniczy to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n", "\n", "
" ] @@ -31,12 +105,55 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "## Reprezentacje zakresu projektu\n", + "
\n", + " \n", + "Uczestnik ma interesy. \n", + "Wykonawca ma zachowania.\n", + "
" + ] + }, + { + "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", + "\"Lista" + ] + }, + { + "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", + "\"Lista\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", + "\"Lista" + ] + }, + { + "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" + "\"Przykład" ] }, { + "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", + "\"Przykład\n", + "\n", + "\"Przykład" + ] + }, + { + "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", + "\"Przykłady\n", + "\n", + "Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n", + "\n", + "\"Przykład" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# 3. Opis przypadków użycia" + ] + }, + { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ "
\n", " \n", - "

Przypadek użycia

\n", + "

Przypadek użycia (PU)

\n", " \n", "Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n", "\n", "\n", "
" ] @@ -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", + "\"Przykład\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", + "\"Przykład\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", + "\"Przykład" + ] + }, + { + "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", + "\"Przykłady" + ] + }, + { + "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", + " \"Przykłady" + ] + }, + { + "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", + " \"Przykłady\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", + "\"Przykład\n", + "\n", + "##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n", + "\"Przykład\n", + "\n", + "##### 3. Pisz \"z lotu ptaka\"\n", + "\"Przykład\n", + "\n", + "##### 4. Przesuwaj proces wyraźnie do przodu\n", + "\"Przykład\n", + "\n", + "##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n", + "\"Przykład\n", + "\n", + "##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n", + "\"Przykłady\n", + "\n", + "##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n", + "\"Przykłady" + ] + }, + { + "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", + "\"Przykłady\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 " ] } ], diff --git a/materiały na PPB (wykład)/04_metodologia_Prince2.ipynb b/materiały na PPB (wykład)/04_metodologia_Prince2.ipynb index 46ebb20..2bf6346 100644 --- a/materiały na PPB (wykład)/04_metodologia_Prince2.ipynb +++ b/materiały na PPB (wykład)/04_metodologia_Prince2.ipynb @@ -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. " ] diff --git a/materiały na PPB (wykład)/06_prototypowanie i ciągła integracja.ipynb b/materiały na PPB (wykład)/06_prototypowanie i ciągła integracja.ipynb index 0c2b68f..a74d111 100644 --- a/materiały na PPB (wykład)/06_prototypowanie i ciągła integracja.ipynb +++ b/materiały na PPB (wykład)/06_prototypowanie i ciągła integracja.ipynb @@ -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", diff --git a/materiały na PPB (wykład)/07_specyfikacja_projektu_informatycznego.ipynb b/materiały na PPB (wykład)/07_specyfikacja_projektu_informatycznego.ipynb index 779640f..34a914c 100644 --- a/materiały na PPB (wykład)/07_specyfikacja_projektu_informatycznego.ipynb +++ b/materiały na PPB (wykład)/07_specyfikacja_projektu_informatycznego.ipynb @@ -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", "

Zakres systemu informatycznego

\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 funkcjonalny – zestaw usług oferowanych przez system.\n", + "\n", + "Zakres projektowy – zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n", + "" + ] + }, + { + "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": [ + "
\n", + "

Uczestnik

\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", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Wykonawca

\n", + " \n", + " Wykonawca to Uczestnik, który kontaktuje się z systemem.\n", + "\n", + " Wykonawca główny 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", + " Wykonawca pomocniczy to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n", "\n", "
" ] @@ -31,12 +105,55 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "## Reprezentacje zakresu projektu\n", + "
\n", + " \n", + "Uczestnik ma interesy. \n", + "Wykonawca ma zachowania.\n", + "
" + ] + }, + { + "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", + "\"Lista" + ] + }, + { + "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", + "\"Lista\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", + "\"Lista" + ] + }, + { + "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" + "\"Przykład" ] }, { + "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", + "\"Przykład\n", + "\n", + "\"Przykład" + ] + }, + { + "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", + "\"Przykłady\n", + "\n", + "Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n", + "\n", + "\"Przykład" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# 3. Opis przypadków użycia" + ] + }, + { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ "
\n", " \n", - "

Przypadek użycia

\n", + "

Przypadek użycia (PU)

\n", " \n", "Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n", "\n", "\n", "
" ] @@ -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", + "\"Przykład\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", + "\"Przykład\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", + "\"Przykład" + ] + }, + { + "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", + "\"Przykłady" + ] + }, + { + "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", + " \"Przykłady" + ] + }, + { + "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", + " \"Przykłady\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", + "\"Przykład\n", + "\n", + "##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n", + "\"Przykład\n", + "\n", + "##### 3. Pisz \"z lotu ptaka\"\n", + "\"Przykład\n", + "\n", + "##### 4. Przesuwaj proces wyraźnie do przodu\n", + "\"Przykład\n", + "\n", + "##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n", + "\"Przykład\n", + "\n", + "##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n", + "\"Przykłady\n", + "\n", + "##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n", + "\"Przykłady" + ] + }, + { + "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", + "\"Przykłady\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 " ] } ],