Ćwiczenia z IO dotyczące przypadków użycia.
|
|
- Wanda Chrzanowska
- 7 lat temu
- Przeglądów:
Transkrypt
1 Radek Bartosiak Ćwiczenia z IO dotyczące przypadków użycia. Zagadnienia do omówienia na ćwiczeniach 1. Wprowadzenie do przypadków użycia jako sposobu przedstawienia interakcji użytkownika (a raczej aktora, np także innego systemu informatycznego) z systemem traktowanym jako czarna skrzynka. 2. Przypadek użycia jako dialog między aktorem a systemem 3. Przypadki użycia jako sposób opisu wymagań funkcjonalnych sytemu 4. Schematyczne przedstawianie przypadków użycia na diagramach UML owych, cele i ograniczenia takiej reprezentacji przypadków użycia (podkreślić, że diagramy pełnią jedynie funkcję pomocniczego spisu treści, trzeba pisać scenariusz przypadków użycia. 5. Które scenariusze przypadków użycia pisać najpierw, jak dokładnie pisać scenariusze przypadków użycia, czy trzeba pisać wszystkie scenariusze przypadków użycia. 6. Dokumentowanie stakeholderów i ich interesów (nawet jeżeli nie są aktorami, np urząd skarbowy w przypadku użycia Sprzedaż towarów za pomocą terminalu kasowego ) 7. Dokumentowanie warunków wstępnych i końcowych 8. Scenariusze główne i alternatywne. 9. Użycie innego przypadku użycia (jeżeli zawsze: include, jeżeli czasem: extend) 10. Dokumentowanie wymagań niefunkcjonalnych (np dotyczących kolorystyki, użycia ekranów dotykowych, wydajności systemu). 11. Napisane scenariusze przypadków użycia NIE są ostateczne (nie można liczyć, że udało nam się napisać scenariusze bezbłędne czy kompletne. Wymaganie podlegają identyfikacji i zmianom oraz ukonkretnieniu> Przykładowo na wczesnym etapie analizy wymagań nie należy pisać scenariuszy, które narzucają konkretne rozwiązania techniczne lub zbyt dokładnie określają GUI) 12. Wskazówki jak zidentyfikować PU Określ zakres (system=software, system=hardware+software,system=hardware+software+ludzie, system=organizacja). To zasadniczo decyduje czy tworzymy tzw biznesowy przypadek użycia, czy tzw systemowy przypadek użycia Zidentyfikuj aktorów Zidentyfikuj cele każdego aktora, zastanów się nad interesami stakeholderów Zdefiniuj przypadki użycia realizujące cele każdego z aktorów 13. Przydatne pytania (w identyfikacji przypadków i aktorów o których można łatwo zapomnieć)
2 Czy czas (albo zaufany serwer czasu :) jest aktorem Kto administruje systemem (uruchamia, wyłącza, dodaje/usuwa użytkowników, nadaje uprawnienia, monitoruje...) Kto bada, nadzoruje działanie systemu, kto jest powiadamiany w przypadku nieprawidłowości w przypadku jego działania, kto czyta logi. Czy istnieje proces, który restartuje system po jego awarii W jaki sposób oprogramowanie systemu jest aktualizowane Czy system kontaktuje się (korzysta z, udostępniania funkcje) z zewnętrznymi systemami informatycznymi. 14. Podkreślić, że to co jest przypadkiem użycia zależy od zakresu systemu! Test szefa: Szef pyta Co robi Pan dziś od rana (eliminuje przypadek użycia logowanie, który swoją drogą w pewnym momencie może się znów pojawić, gdy będziemy chcieli podjąć konkretne decyzje projektowe dotyczące autentykacji :) Test elementarnego procesu biznesowego: Zadanie wykonywane przez jedną osobę, w jednym miejscu i w konkretnym stosunkowo krótkim czasie (sekundy,minuty) w odpowiedzi na zaistnienie zdarzenia biznesowego, które przynosi wymierną wartość biznesową oraz pozostawia system w spójnym stanie. Eliminuje przypadki użycia typu: edycja wiersza dokumentu tekstowego (brak spójności oraz wymiernej korzyści biznesowej) oraz np projektowanie nowego samochodu(zbyt długi czas, ale może nadawać się na biznesowy przypadek użycia) 15. Przypadki użycia mają pomagać i jak zwykle należy dostosowywać metodologię do potrzeb i możliwości. Przykład 1 Omówić przykładowy przypadek użycia z rozdziału 6 (o przypadkach użycia), książki Craiga Larmana Applying UML and Patterns (strony 50 58, te strony można skserować studentom). Ćwiczenie 2 Producent sprzętu komputerowego wchodzi na nowy rynek urządzeń bankomatowych, każdy bankomat ma mieć własne oprogramowanie, które będzie się łączyło z oprogramowaniem operatora zarządzającego bankomatem. Twoim zadaniem jest opracowanie przypadku użycia Wypłata gotówki z bankomatu Uwagi: 1. Można podkreślić pewną sztuczność tej sytuacji (scenariusz jest dość dobrze określony), przeważnie tak nie jest i pisanie scenariusza jest większym wyzwaniem. 2. Identyfikacja aktorów, stakeholderów i ich interesów, zakresu systemu oraz (to ważne) innych przypadków użycia
3 3. Dyskusja na temat tego jak dokładnie modelować autoryzację w tym przypadku jestem za dokładnym modelowaniem tzn piszemy Aktor wprowadza PIN, a nie Aktor autoryzuje się, gdyż ta technologia (PIN) jest standardem i jest narzucona ). 4. Skupić się na scenariuszach alternatywnych (błędne hasło, brak gotówki w bankomacie, brak niektórych rodzajów banknotów (np nie można wypłacić 20PLN), zbyt duża kwota wypłaty, przekroczenie stanu konta, zbyt powolne wprowadzanie PINu, nie wyjęcie karty bankomatowej, niepodjęcie pieniędzy, karta bankomatowa nieczytelna, utrata połączenia z systemem zewnętrznym...) Podkreślić, że tu właśnie leży siła PU, sprawdzić czy studenci nie są teraz w stanie zidentyfikować nowych przypadków użycia naszego systemu (np pobranie zatrzymanych kart, powiadomienie o awarii, braku banknotów etc. Przedyskutować padające propozycje w kontekście zakresu i aktorów) 5. Warunki początkowe (np istnienie połączenia z systemem) i końcowe (przebieg operacji jest zapamiętany, informacje przekazane systemowi zewnętrznemu), niefunkcyjne (zagadnienia związane z czasem) 6. Przykład dobrze nadaje się do pokazania różnic gdy myślimy (ustalamy zakres), że system to samo oprogramowanie, oraz gdy myślimy o systemie jako o oprogramowaniu i sprzęcie Uwagi do ćwiczenia 3 1. To ćwiczenie jest mniej skoncentrowane na scenariuszach, po prostu pisanie scenariuszy jest czasochłonne i na ćwiczeniach musimy (mym zdaniem) przećwiczyć także inne rzeczy. Oczywiście zawsze podkreślamy studentom, że najważniejsze są scenariusze. 2. Ćwiczenie nadaje się do pokazania różnicy między systemowym, a biznesowym przypadkiem użycia. Ja biznesowy przypadek użycia Dodanie nowej funkcji każę modelować za pomocą diagramu czynności (z torami). Oczywiście możecie uważać, że na te diagramy jest jeszcze zbyt wcześnie, możecie zresztą całkowicie pominąć rozróżnienie między biznesowymi i systemowymi PU (choć moi studenci wydają się pojmować tę różnicę). 3. Jeżeli mamy diagram czynności to można wskazać w jaki sposób SPU wspierają dane czynności i pokazać w ten sposób śledzenie. 4. Na diagramach PU można tu pokazać generalizację (np generuj raport i dwie podklasy odpowiadające typom raportów), zawieranie i rozszerzanie (np powiadom o odrzuceniu). 5. Ćwiczenie pozwala na zbadanie czy studenci radzą sobie określeniem zakresu, wadą jest to że tak na prawdę nie udaje się zidentyfikować wszystkich przypadków użycia (można na to zwrócić uwagę: np zarządzanie użytkownikami zostanie za pewne pominięte przez studentów). No i krótki opis (oparty na moich notatkach z ćwiczeń z Arkiem Wojną) także nie może oddawać wszystkich problemów, wymagań.
4 Ćwiczenie 3 System jest przeznaczony dla działu informatyki firmy prowadzącej działalność ubezpieczeniową (sprzedaż polis posagowych, polis na życie itp). Dział informatyki zajmuje się utrzymaniem i rozwojem systemów informatycznych tej firmy. Wraz z ekspansją firmy, wprowadzaniem przez jej władze nowych usług i ofert oraz wraz ze zmianami przepisów prawnych pojawiają się potrzeby udostępniania nowych funkcji oraz zmiany istniejących funkcjonalności. System ma za zadanie zapewnić efektywną komunikację pomiędzy pracownikami związaną ze zgłaszaniem i realizacją tych potrzeb. Przy pojawieniu się nowego zapotrzebowaniapracownik zgłasza je do systemu podając: nazwę systemu który trzeba zmodyfikować, informację czy potrzebna jest nowa funkcja czy zmiana już istniejącej, opis funkcji (modyfikacji), priorytet oraz maksymalny czas realizacji. Po zgłoszeniu zadania osoba z działu informatyki zwana administratorem zadań dokonuje wstępnej analizy zapotrzebowania i przypisuje je do odpowiedniego zespołu projektowego. Kierownik zespołu projektowego wykonuję dokładną analizę zadania i albo je odrzuca, podając uzasadnienie, albo przyjmuje zadanie do wykonania. Jeżeli zadanie zostało odrzucone to zgłaszający zostaje o tym poinformowany. W przypadku akceptacji zadania kierownik zespołu musi wybrać z podzespołu programistów osobę która będzie miała za zadanie zaimplementować zadaną funkcję, a z podzespołu testerów osobę która przetestuje implementację i jej zgodność z wymaganiami zgłaszającego. Obsługa realizacji zadania przebiega w następujący sposób. Po przydziale osób wybrany programista jest informowany o nowym zadaniu i po jego wykonaniu zgłasza ten fakt do systemu podając również nazwy fizycznych komponentów systemu które uległy zmianie (dane, pliki wykonywalne, konfiguracyjne, dokumentacja techniczna, pomoc użytkownika, przypadki testowe oraz opisy testów wykonywanych w trakcie implementacji) System informuje wtedy testera o potrzebie przetestowania wprowadzonych zmian. Po wykonaniu testów tester wprowadza do systemu jego wyniki (oraz utworzone przypadki testowe). Jeżeli wynik jest pozytywny, to Dział Migracji jest informowany o potrzebie uaktualnienia wersji produkcyjnej systemu. Po wykonaniu migracji system informuje: kierownika zespołu, administratora zadań, oraz zgłaszającego o dostępności nowej lub zmienionej funkcjonalności Jeżeli wynik testu był negatywny informowany jest kierownik zespołu, który musi ponownie wykonać analizę zadania pod względem jego wykonalności i jeżeli nie zmienił decyzji to ponownie wybiera osoby do jego wykonania i przetestowania (mogą być to inne niż poprzednio osoby). Z każdym zadaniem system zapamiętuje również daty oraz autorów kolejnych operacji wykonywanych dla danego zadania, takich jak: zgłoszenie, przypisanie, wykonanie testów, odrzucenie zadania oraz aktualny status zadania. Pracownicy firmy mają dostęp do opisu, historii i aktualnego stanu realizacji zadań, przy czym zwykli pracownicy mogą przeglądać tylko informacje dotyczące zgłoszonych przez siebie zadań, pracownicy działu informatyki do wszystkich zadań przypisanych do ich zespołów, a administratorzy zadań i pracownicy Działu Migracji do wszystkich zgłoszonych zadań. Istnieje także grupa kierowników mających możliwość generowania i drukowania sumarycznych raportów dotyczących realizacji potrzeb. Istnieją dwa rodzaje raportów: pierwszy zawiera informacje ile potrzeb zostało zgłoszonych, ile zrealizowanych, ile odrzuconych w zadanym okresie czasu. Parametrami tego raportu są: okres czasu, dział(y) z których pochodziły zapotrzebowania, zespół
5 projektowy (zespoły projektowe) do których te zapotrzebowania zostały przypisane. Drugi rodzaj raportów zawiera informacje bieżące, czyli dla każdego statusu jest podana informacja, ile w danej chwili jest zadań o danym statusie (ten raport także można przygotować dla zadań z wybranych działów i zespołów projektowych). 1. Narysuj diagram czynności dla procesu biznesowego (biznesowego przypadku użycia): Dodanie nowej funkcji 2. Zidentyfikuj aktorów i systemowe przypadki użycia i przedstaw je na diagramie przypadków użycia.
Diagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoModelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia
Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.
Bardziej szczegółowoDIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL
Projektowanie Systemów Komputerowych Laboratoria/Projekty Krzysztof Regulski AGH, WIMiIP DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL 1) Zastosowanie Jedną ze stosowanych metodologii prowadzenia projektów
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoProjektowanie oprogramowania
Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Bardziej szczegółowoInżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia
Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu
Bardziej szczegółowoPriorytetyzacja przypadków testowych za pomocą macierzy
Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.
Bardziej szczegółowoUML 1 diagramy interakcji
UML 1 diagramy interakcji Materiał na ćwiczenia z rysowania diagramów interakcji wchodzących w skład UMLa. Forma ćwiczeń. Każdy ze studentów otrzymuje materiały w postaci referencji do odpowiednich diagramów
Bardziej szczegółowoNarzędzia informatyczne wspierające przedsięwzięcia e-commerce
Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza
Bardziej szczegółowoModelowanie i analiza systemów informatycznych Spis treści
Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoIO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl
IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju
Bardziej szczegółowoUsprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.
Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja
Bardziej szczegółowoProjektowanie oprogramowania
Wrocław, 26.09.2012 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia). Zajęcia składają się z
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoSzczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:
Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia
Analiza i projektowanie obiektowe 2017/2018 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.
Bardziej szczegółowoGłówny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów
Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów Specyfikacja procesów biznesowych SPIS TREŚCI 1 Wstęp... 4 1.1 Przeznaczenie dokumentu...
Bardziej szczegółowoPrzewodnik dla użytkownika. Instrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA
1. Wstęp... 3 2. Wymagania techniczne... 3 3. Instalacja mtoken Asseco MAA na urządzeniu mobilnym... 4 5. Logowanie do aplikacji mtoken Asseco MAA...10 5. Autoryzacja dyspozycji złożonej w systemie bankowości
Bardziej szczegółowoOkreślanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams
Cele przedsięwzięcia Określanie wymagań Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoPrzewodnik użytkownika systemu AgentWorks podwójna kontrola wydanie 11 wersja polska
Przewodnik użytkownika systemu AgentWorks podwójna kontrola wydanie 11 wersja polska 09/01/2013 2012 MoneyGram International Wszelkie prawa zastrzeżone. Spis treści 1. Zatwierdzenia menedżera... 2 2. Zgłoszenia
Bardziej szczegółowoSzkolenie: ISTQB Model-Based Tester
Szkolenie: ISTQB Model-Based Tester Szkolenie ISTQB Model-Based Tester rozszerza tematykę Poziomu Podstawowego o zagadnienia związane z testowaniem opartym na modelu. Skierowane jest do osób chcących rozszerzyć
Bardziej szczegółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegółowoArchitektura oprogramowania w praktyce. Wydanie II.
Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?
Bardziej szczegółowoDiagramy przypadków użycia - MS Visio
Diagramy przypadków użycia - MS Visio LABORKA Piotr Ciskowski zad. 1. Sklep internetowy - diagram przypadków użycia (Visio) o przykład z: Wrycza i in., UML 2.x. Ćwiczenia zaawansowane o narzędzie: MS Visio
Bardziej szczegółowoProjekt aplikacji internetowej specyfikacja wymagań (cz.1)
Cykl życia aplikacji internetowej modelowanej przy pomocy WebML Etapy: 1) Specyfikacja wymagań określenie wymagań funkcjonalnych i niefunkcjonalnych, jakie ma spełniać tworzona aplikacja. 2) Stworzenie
Bardziej szczegółowoModelowanie obiektowe - Ćw. 6.
1 Modelowanie obiektowe - Ćw. 6. Treść zajęć: Dokumentacja przypadków użycia diagramy czynności. Poznane wcześniej diagramy przypadków użycia pokazują co system powinien robić. Natomiast diagramy czynności
Bardziej szczegółowoPrzypadki użycia. Analiza. Model biznesowy. Specyfikacja wymagań. Model dziedziny problemu. Przypadki użycia
2 Analiza Model biznesowy Specyfikacja wymagań Przypadki użycia Model dziedziny problemu 3 Przypadek użycia Przypadek użycia to umowa między uczestnikami systemu, określająca sposób zachowania systemu
Bardziej szczegółowoProcedura uruchomienia nowych lub zmiany istniejących funkcjonalności w systemie SAP ERP w UJ
Procedura uruchomienia nowych lub zmiany istniejących funkcjonalności w systemie SAP ERP w UJ dr Marian Krupa Kierownik jakości (SAP) Sekcja Wdrożenia Systemu Zintegrowanego Kraków 2009 2 Spis treści 1.
Bardziej szczegółowo1. Moduł Print Master
1. Moduł Print Master 1.1. Wprowadzenie Print Master (PM) to moduł, którego główną funkcją jest autoryzacja wydruków wykonywanych przez użytkownika w systemie Windows. Autoryzacja obejmuje wydruki wykonywane
Bardziej szczegółowoAgenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
Analiza biznesowa Agenda Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia Cele projektu Cechy SMART S Specific Precyzyjne M Measurable Mierzalne A Agreed To Zaakceptowane
Bardziej szczegółowoProjektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc.
Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00-19.45 a podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie
Bardziej szczegółowoPROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH. załącznik do ZR 154/2014 z dnia 22 grudnia 2014 roku
PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH załącznik do ZR 154/2014 Spis treści I. CEL I ZAKRES OBOWIĄZYWANIA INSTRUKCJI... 3 II. DEFINICJE I SKRÓTY... 3 III.
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt
Bardziej szczegółowoZAŁACZNIK NR 1D KARTA USŁUGI Utrzymanie Systemu Poczty Elektronicznej (USPE)
Załącznik nr 1D do Umowy z dnia.2014r. ZAŁACZNIK NR 1D KARTA USŁUGI Utrzymanie Systemu Poczty Elektronicznej (USPE) 1. INFORMACJE DOTYCZĄCE USŁUGI 1.1. CEL USŁUGI: W ramach Usługi Usługodawca zobowiązany
Bardziej szczegółowoPLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji
Bardziej szczegółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoWprowadzenie do Behaviordriven
Wprowadzenie do Behaviordriven development Jakub Kosiński Email: ja@ghandal.net Czym jest BDD? praktyka, powstała na podstawie TDD, wykorzystywana w zwinnych metodykach stworzona przez Dana Northa w 2003
Bardziej szczegółowoDiagramy przypadków użycia. WYKŁAD Piotr Ciskowski
Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej
Bardziej szczegółowoRozwiązania CAD/CAM/CAE/PDM. esupport. System wsparcia technicznego firmy Premium Solutions Polska. Autoryzowany Dystrybutor:
Rozwiązania CAD/CAM/CAE/PDM esupport System wsparcia technicznego firmy Premium Solutions Polska Autoryzowany Dystrybutor: Spis treści: 1. Wstęp... 3 2. Uruchomienie... 4 3. Rejestracja Użytkownika...
Bardziej szczegółowoAcceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki
Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja
Bardziej szczegółowoInstrukcja tworzenia, logowania i obsługi kont w portalu:
Instrukcja tworzenia, logowania i obsługi kont w portalu: S24 (składania elektronicznych wniosków w celu rejestracji w KRS: spółki z o.o., jawnej i komandytowej w trybie jednego dnia i sprawozdania Z30)
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Diagramy przypadków użycia Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoDiagramy przypadków użycia
Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania Rodzaj zajęć: laboratorium PROJEKT ZESPOŁOWY DYPLOMOWY IO Team Project SE Forma studiów:
Bardziej szczegółowoTestujemy dedykowanymi zasobami (ang. agile testers)
Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania
Bardziej szczegółowoOpis Przedmiotu Zamówienia
Załącznik nr 1 do SIWZ/ załącznik nr 1 do umowy OP/UP/099/2011 Opis Przedmiotu Zamówienia 1. Przedmiot zamówienia 1.1. Przedmiotem zamówienia jest świadczenie usług konsultancko-developerskich dla systemu
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoZARZĄDZENIE Nr 10 DYREKTORA GENERALNEGO SŁUŻBY ZAGRANICZNEJ. z dnia 9 maja 2011 r.
36 ZARZĄDZENIE Nr 10 DYREKTORA GENERALNEGO SŁUŻBY ZAGRANICZNEJ z dnia 9 maja 2011 r. w sprawie wdrożenia i eksploatacji systemu Wiza-Konsul w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych
Bardziej szczegółowoBiznesowe przypadki użycia SOS
Biznesowe przypadki użycia SOS Marcin Suszczewicz Michał Woźniak Krzysztof Kostałkowicz Piotr Kuśka 24 kwietnia 2006 1 Spis treści 1 Wprowadzenie 5 1.1 Cel.......................................... 5 1.2
Bardziej szczegółowoInstrukcja dla Uczelnianego Administratora Systemu Antyplagiatowego Plagiat.pl
Instrukcja dla Uczelnianego Administratora Systemu Antyplagiatowego Plagiat.pl Materiały poufne, przeznaczone wyłącznie dla UASA. Plagiat.pl 2010 Strona 1 I. Logowanie Aby zalogować się jako Uczelniany
Bardziej szczegółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 6 Modelowanie przypadków uŝycia i czynności. Materiały dla studentów
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 6 Modelowanie przypadków uŝycia
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Bardziej szczegółowoSpecyfikowanie wymagań przypadki użycia
Specyfikowanie wymagań przypadki użycia Prowadzący Dr inż. Zofia 1 La1 La2 Forma zajęć - laboratorium Wprowadzenie do laboratorium. Zasady obowiązujące na zajęciach. Wprowadzenie do narzędzi wykorzystywanych
Bardziej szczegółowoI. Raport wykonywalności projektu
Spis treści: " I. " Raport wykonywalności projektu..." str. 2 " II. " Glosariusz projektu... " str. 4 " III. " Diagramy relacji encja-związek..." str. 6 " IV. " Diagramy przepływu danych..." str. 7 " V.
Bardziej szczegółowoNazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
Bardziej szczegółowoInstrukcja wiązania bankowości internetowej z aplikacją mobilną mtoken Asseco MAA (w przypadku autoryzacji za pomocą tokena lub sms-a)
Instrukcja wiązania bankowości internetowej z aplikacją mobilną mtoken Asseco MAA (w przypadku autoryzacji za pomocą tokena lub sms-a) Lubartów, kwiecień 2019 r. 1. WSTĘP mtoken Asseco MAA jest aplikacją
Bardziej szczegółowoDOTACJE NA INNOWACJE. Inwestujemy w waszą przyszłość. Zapytanie ofertowe
Nitrotek Sp. z o.o. ul. Krynicka 40/7 50-555 Wrocław Wrocław, dnia 07.01.2014 r. Zapytanie ofertowe W związku z realizacją projektu Wdrożenie nowoczesnego systemu B2B automatyzującego współpracę Nitrotek
Bardziej szczegółowoLista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania
Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania Inżynieria oprogramowania przykładowe pytania egzaminacyjne str. 2 Przykładowe pytania 1. Wymień i omów krótko podstawowe kategorie
Bardziej szczegółowoSerwis jest dostępny w internecie pod adresem www.solidnyserwis.pl. Rysunek 1: Strona startowa solidnego serwisu
Spis treści 1. Zgłoszenia serwisowe wstęp... 2 2. Obsługa konta w solidnym serwisie... 2 Rejestracja w serwisie...3 Logowanie się do serwisu...4 Zmiana danych...5 3. Zakładanie i podgląd zgłoszenia...
Bardziej szczegółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia
Bardziej szczegółowoZARZĄDZENIE NR 838/2009 PREZYDENTA MIASTA KRAKOWA Z DNIA 21 kwietnia 2009 r.
ZARZĄDZENIE NR 838/2009 PREZYDENTA MIASTA KRAKOWA Z DNIA 21 kwietnia 2009 r. w sprawie wprowadzenia do stosowania oraz określenia zasad korzystania ze Zintegrowanego Systemu Zarządzania Oświatą w Gminie
Bardziej szczegółowoRubik s Manager - Plan testów
Rubik s Manager - Plan testów Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 27 maja 2007 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoOprogramowanie ILUO Biznes pozwala na jednoczesne zarządzanie wieloma sklepami Internetowymi zbudowanymi na oprogramowaniu różnych producentów.
Oprogramowanie ILUO Biznes pozwala na jednoczesne zarządzanie wieloma sklepami Internetowymi zbudowanymi na oprogramowaniu różnych producentów. Niektóre z modułów Integracyjnych z ILUO Biznes zostały przygotowane
Bardziej szczegółowoProjekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie
Bardziej szczegółowoMiędzyplatformowy interfejs systemu FOLANessus wykonany przy użyciu biblioteki Qt4
Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Agnieszka Holka Nr albumu: 187396 Praca magisterska na kierunku Informatyka
Bardziej szczegółowoosobowe pracowników laboratorium SecLab EMAG w rozumieniu przepisów Kodeksu Pracy, konsultantów, stażystów oraz inne osoby i instytucje mające dostęp
Bezpieczeństwo danych projektowych w środowisku według ISO/IEC 27001 oraz ciągłość procesów wytwarzania i utrzymania w środowisku według BS 25999 warsztaty z wykorzystaniem specjalistycznego narzędzia
Bardziej szczegółowoInstrukcja obsługi xapp.pl
Instrukcja obsługi xapp.pl Aplikacja mobilna Logowanie do aplikacji Aby zalogować się do aplikacji należy posiadać połączenie z Internetem. Pracodawca powinien dostarczyć login w postaci adresu e-mail,
Bardziej szczegółowoSky-Shop.pl. Poradnik. Pierwsze kroki: Importowanie własnego pliku XML Integracje z hurtowniami
Sky-Shop.pl Poradnik Pierwsze kroki: Importowanie własnego pliku XML Integracje z hurtowniami Wstęp Sky-Shop.pl jest w pełni autorskim, opracowanym od podstaw programem do prowadzenia nowoczesnych sklepów
Bardziej szczegółowoSzczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.
Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania. Założenia projektowe systemu NETDOC. część 1: założenia ogólne i funkcjonalność rdzenia systemu Założenia ogólne Celem projektu jest
Bardziej szczegółowoInstrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA
Instrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA mtoken Asseco MAA to aplikacja instalowana w telefonie komórkowym lub innym urządzeniu mobilnym, służąca do autoryzacji dyspozycji pochodzących
Bardziej szczegółowoSLA ORAZ ZASADY ŚWIADCZENIA WSPARCIA I HELPDESK. Wykonawca zobowiązuje się do świadczenia Usług Wsparcia i Helpdesk w odniesieniu do Systemu.
SLA ORAZ ZASADY ŚWIADCZENIA WSPARCIA I HELPDESK Wykonawca zobowiązuje się do świadczenia Usług Wsparcia i Helpdesk w odniesieniu do Systemu. 1. ZAKRES USŁUG Nazwa Usługi Krótki opis Usuwanie Błędów Usuwanie
Bardziej szczegółowoProjektowanie oprogramowania
Wrocław, 24.09.2018 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Bardziej szczegółowoPLATFORMA DISTANCE LEARNING BLACKBOARD
PLATFORMA DISTANCE LEARNING BLACKBOARD PODRĘCZNIK UŻYTKOWANIA Spis treści Dostęp do platformy Blackboard / logowanie... 2 Dostosowanie platformy do potrzeb użytkownika... 3 Opcje menu i funkcjonalności
Bardziej szczegółowoOpis zmian w wersji Oprogramowania do Obsługi SR/FA/SW/DM/ST
Opis zmian w wersji 2-5.4 Oprogramowania do Obsługi SR/FA/SW/DM/ST 1. Dostosowanie systemu do generowania i eksportowania miesięcznego sprawozdania z zakresu świadczeń wychowawczych wg nowego wzoru obowiązującego
Bardziej szczegółowoOpis Przedmiotu Zamówienia
Załącznik nr 1 do SIWZ Załącznik nr 1 do Umowy CSIOZ/ /2016 Opis Przedmiotu Zamówienia Przedmiotem zamówienia jest realizacja zadania pod nazwą System do backupu urządzeń sieciowych (zwany dalej: Systemem
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.
Bardziej szczegółowo3S TeleCloud - Aplikacje Instrukcja użytkowania usługi 3S FAX SYSTEM
\ 3S TeleCloud - Aplikacje Instrukcja użytkowania usługi 3S FAX SYSTEM SPIS TREŚCI 1. LOGOWANIE DO APLIKACJI... 3 2. WYGLĄD OKNA... 4 3. SKRZYNKA ODBIORCZA... 5 3.1. SKRZYNKA ODBIORCZA - Objaśnienie kolumn:...
Bardziej szczegółowoInstrukcja wczytywania i przekazywania zbiorów centralnych w Centralnej Aplikacji Statystycznej przez użytkowników podobszaru FA
Instrukcja wczytywania i przekazywania zbiorów centralnych w Centralnej Aplikacji Statystycznej przez użytkowników podobszaru FA 1. Logowanie do aplikacji CAS Aby przejść do obsługi zbiorów centralnych
Bardziej szczegółowoPrzykładowa konfiguracja konta pocztowego w programie Thunderbird z wykorzystaniem MKS 2k7 (MS Windows Vista Busissnes)
Przykładowa konfiguracja konta pocztowego w programie Thunderbird z wykorzystaniem MKS 2k7 (MS Windows Vista Busissnes) KROK NR 1: Uruchamiamy dowolną przeglądarkę internetową w celu pobrania najnowszej
Bardziej szczegółowoCab4You Voucher. System obsługi zleceń bezgotówkowych. Instrukcja dla poziomu dostępu firma. Cab4You Voucher / System obsługi zleceń bezgotówkowych
Cab4You Voucher System obsługi zleceń bezgotówkowych Instrukcja dla poziomu dostępu firma Wstęp Cab4You płatności jest to system umożliwiający obsługę bezgotówkowych przejazdów w korporacjach taxi. System
Bardziej szczegółowoProjekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA. laboratorium
INŻYNIERIA OPROGRAMOWANIA laboratorium UML 1/4 UML (Unified Modeling Language) - język modelowania obiektowego systemów i procesów [Wikipedia] Spojrzenie na system z różnych perspektyw dzięki zastosowaniu
Bardziej szczegółowoInstrukcja pracy w systemie USOSweb dla wykładowców PWSZ w Koninie - wpisywanie ocen -
Instrukcja pracy w systemie USOSweb dla wykładowców PWSZ w Koninie - wpisywanie ocen - Obsługa serwisu USOSweb odbywa się za pomocą przeglądarki internetowej, np.: Internet Explorer, Firefox, Chrome, Mozilla.
Bardziej szczegółowo24/10/2011 Norma bezpieczeństwa PCI DSS. Korzyści i problemy implementacji. 1
24/10/2011 Norma bezpieczeństwa PCI DSS. Korzyści i problemy implementacji. 1 Norma bezpieczeństwa PCI DSS Korzyści i problemy implementacji Wojciech Śronek, Zespół Administratorów Sieci, Grupa Allegro
Bardziej szczegółowoZałącznik 1. Platforma komunikacyjna powinna posiadać następującą funkcjonalność:
Załącznik 1 Wytyczne dotyczące funkcjonalności platformy komunikacyjnej umożliwiającej wymianę danych o wspólnych beneficjentach powiatowych urzędów pracy, jednostek organizacyjnych pomocy społecznej i
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowotimetrack Przewodnik Użytkownika timetrack Najważniejsze Funkcje
timetrack Przewodnik Użytkownika timetrack jest łatwą w obsłudze aplikacją, stworzoną do rejestracji czasu. Pozwala ona na zapisywanie czasu spędzonego z klientami oraz podczas pracy nad projektami i zadaniami
Bardziej szczegółowoZasady sporządzania matrycy funkcji kontroli
Załącznik nr 1 do Regulaminu systemu kontroli wewnętrznej w Banku Spółdzielczym w Dołhobyczowie Zasady sporządzania matrycy funkcji kontroli 1 Matryca funkcji kontroli Matryca stanowi opis, powiązania
Bardziej szczegółowoPROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS
Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się
Bardziej szczegółowoSpecyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)
Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) 1. Wstęp: 1.1. Cel. Niniejszy dokument przestawia specyfikację wymagań systemowych (zarówno funkcjonalnych jak i niefunkcjonalnych)
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowo