Agenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
|
|
- Urszula Komorowska
- 6 lat temu
- Przeglądów:
Transkrypt
1 Analiza biznesowa
2 Agenda Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
3 Cele projektu
4 Cechy SMART S Specific Precyzyjne M Measurable Mierzalne A Agreed To Zaakceptowane R Realistic Realne T Time constraint Ograniczone w czasie
5 Wizja projektu
6 Wizja projektu Zadania wizji projektu: Krótki opis problemu Zdefiniowanie ogólnego celu projektu Zdefiniowanie ogólnego zarysu funkcjonalności projektu Zdefiniowanie klientów i użytkowników projektu Wizja zebrana jest w dokumencie wizyjnym powstałym w wyniku spotkań wizyjnych
7 Wstępna deklaracja zakresu projektu Opis projektu na ogólnym poziomie zawierający: Wymagania dotyczące produktów cząstkowych projektu Wymagania dotyczące produktu projektu Ramy realizacji projektu (co jest w zakresie, a co jest poza zakresem projektu) Wizja zawiera wstępną deklarację zakresu projektu
8 Modelowanie biznesowe
9 Modelowanie biznesowe Analiza struktury i dynamiki organizacji przeanalizowanie struktury i dynamiki organizacji, w której oprogramowanie ma być wdrażane (tzw. organizacji docelowej ). Identyfikacja problemów Zrozumienie aktualnych problemów organizacji, które identyfikują miejsca dla potencjalnych ulepszeń Identyfikacja procesów biznesowych opis procesów biznesowych zachodzących u klienta, aby był jednakowo zrozumiały przez wszystkich uczestników projektu (klienta i zespół projektowy). Tak, aby postrzegali docelową organizację w jednakowy sposób (jej strukturę, dynamikę i problemy). Opis rozpatrywanego problemu
10 Wymagania użytkownika
11 Wymagania definicja (PMI) Uwarunkowanie lub zdolność, którą powinien spełnić lub posiadać system, wyrób, usługa, rezultat lub element składowy, aby wykazać zgodność z kontraktem, normą, specyfikacją lub innym formalnie narzuconym dokumentem
12 Definiowanie wymagań Wizja źródłem wymagań projektu Wymagania stanowią podstawę tworzenia planu zarządzania projektem Proces definiowania wymagań Zebranie informacji Analiza i interpretacja informacji Przygotowanie dokumentacji Uzyskanie akceptacji dokumentacji
13 Weryfikacja wymagań Prezentacja udokumentowanych wymagań przed kluczowymi interesariuszami Uwagi interesariuszy Dokument wymagań projektu Pozyskanie formalnego zatwierdzenia Dokumentu wymagań od sponsora
14 Kto tworzy wymagania użytkownika? Klient stawia wymagania odnośnie systemu Analityk bada rynek i tworzy wymagania funkcjonalne systemu Przyszły użytkownik systemu
15 Przykład system rejestrowania błędów System rejestrowania błędów: służy do obsługi błędów powstających podczas tworzenia oprogramowania i zarządzania nimi system wewnętrzny: wymagania użytkownika nie pochodzą od klienta
16 System obsługi błędów- wymagania Wymagania funkcjonalne Wprowadzanie zgłoszeń Przeglądanie zgłoszeń Obsługa zgłoszenia Definiowanie obiegu błędów dla projektu Zarządzanie użytkownikami systemu Wymagania systemowe Integracja z podsystemami Przyjazny interfejs użytkownika
17 Wprowadzanie zgłoszeń- wymagania System powinien umożliwić: wprowadzanie nowego zgłoszenia do systemu, przypisanie zgłoszenia do projektu lub modułu, ustalenie dla zgłoszenia wersji realizacji oraz priorytetu, przypisanie typu zgłoszenia, wymuszone przypisanie osoby prowadzącej zgłoszenie, edycję treści zgłoszenia i pozostałych jego parametrów wraz z zapisem wszelkich zmian w historii zgłoszenia, edycję informacji dodatkowych, ale tylko z zapisem w tekście, kto i kiedy dokonał zmiany, tworzenie duplikatu zgłoszenia, z możliwością zmiany dowolnego z parametrów lub zmiany w treści, tworzenie powiązań między zgłoszeniami, potrzebne są dwa typy powiązań jedno nie wpływające na kolejność realizacji zgłoszeń, a drugie określające kolejność realizacji, czyli nie można przejść w zgłoszeniu nadrzędnym do następnego stanu przed zamknięciem zgłoszenia podrzędnego, ustalenie, kto ma się zająć zgłoszeniem w przypadku, gdy dotrze ono do wybranego stanu z WorkFlow
18 Rola wymagań użytkownika Punkt wyjścia procesu projektowania Rozwiązywanie sprzeczności wynikających ze sprzecznych oczekiwań różnych klientów Pomoc w konstruowaniu planu rozwoju systemu poprzez nadawanie priorytetów Usuwanie niejednoznaczności sytuacji, w której istnieje kilka wzajemnie sprzecznych interpretacji pewnego tekstu lub sytuacji
19 Przyczyny powstawania niejednoznaczności brakuje wymagań: dodanie nowych wymagań może rozstrzygnąć niejednoznaczność niejednoznaczne wyrazy: posiadające wiele znaczeń wymagania wprowadzone przez projektanta (nie przez użytkownika): powstaje konflikt na poziomie języka
20 Analiza wymagań Czy nie ma niejednoznaczności? Czy wymagania są kompletne? Czy wymagania są zrozumiałe dla wszystkich zainteresowanych?
21 Przy tworzeniu wymagań warto zwrócić uwagę na Przeanalizowanie systemu istniejącego i zastosowanie wyciągniętych wniosków przy tworzeniu nowego systemu Słuchanie innych, jeżeli mówią, że idziemy złą ścieżką Wyodrębnienie działań priorytetowych, z możliwością późniejszej zmiany ich kolejności
22 Związki pomiędzy wymaganiami Wymagania z reguły nie są pojedynczym bytem sformułowanie jednego wymagania wpływa na drugie Im wymaganie jest bardziej ogólne tym bardziej wpływa na inne wymagania Wymagania można grupować: Jeżeli grupa wymagań cechuje się silnymi związkami wewnętrznymi, a nie wpływa w znacznym stopniu na pozostałe wymagania, to można z tego zrobić podsystem
23 Wyznaczanie priorytetów Wymaganie jest konieczne, jeżeli nie można się bez niego obejść w systemie Wymaganie jest przydatne, jeżeli jego pominięcie nie spowoduje poważnych problemów związanych z realizacją podstawowych zamierzeń Wymaganie jest nieistotne, jeżeli mogą okazać się przydatne w pewnych zastosowaniach, lecz wprowadzenie ich do systemu nie jest warte wysiłku Wymaganie jest zbędne, jeżeli nie wiąże się w żaden sposób z celem projektu
24 Przypadki użycia
25 Przykładowy przypadek użycia Zgłoszenie błędu Warunki wstępne: Użytkownik jest zalogowany systemie Przebieg podstawowy: 1) Przypadek rozpoczyna się w widoku zgłoszeń, gdy użytkownik wybierze opcję dodawania zgłoszenia. 2) Pojawia się okno szczegółów zgłoszenia, pracownik wpisuje tytuł treść zgłoszenia, wybiera także moduł do którego ono należy wypełnia pozostałe dane związane ze zgłoszeniem. 3) Po wyborze modułu zgłoszenia pobierane są dane dotyczące workflow tym module i na ich podstawie ustawiane ewentualne podpowiedzi przy dalszym wypełnianiu zgłoszenia. Jeżeli wybrany projekt/moduł nie ma zdefiniowanego workflow to użytkownik jest o tym informowany i musi wybrać inny lub anulować zgłoszenie. 4) Użytkownik musi też wybrać osobę odpowiedzialną za realizację następnego stanu zgłoszenia, system podpowiada użytkownikowi jaka osoba według ustawień WorkFlow powinna zostać przypisana do tego zgłoszenia. Będzie to zazwyczaj programista przypisany do modułu lub administrator projektu. Oczywiście pracownik nie musi zastosować się do sugestii może wybrać dowolną osobę spośród przypisanych do modułu, a nawet spośród pozostałych użytkowników systemu TrackNet. 5) Po zatwierdzeniu zgłoszenie zostaje utworzone. Jeżeli dla modułu, wybranego w zgłoszeniu jest ustawiona notyfikacja mailem na tworzeniu zgłoszenia, zostaje wysłana odpowiednia wiadomość do zdefiniowanej w notyfikacji osoby/grupy osób. Stan końcowy: Zgłoszenie zostało dodane do systemu. Ewentualne notyfikacje zostały wysłane.
26 Części składowe: Przypadki użycia Nazwa; Identyfikator (ID); Opis; Warunki wstępne (ang. precondition); Warunki końcowe (ang. postconditions); Sekwencja akcji
27 Rola przypadków użycia Opisują zachowanie się systemu z punktu widzenia użytkownika Definiują granice systemu oraz relacje pomiędzy systemem a jego otoczeniem Pokazują ogólny obraz funkcjonalności systemu nie ma na tym etapie żadnych decyzji odnośnie funkcjonalności Pokazują co się będzie działo w systemie. Umożliwia to przemyślenie bądź przeprojektowanie całego procesu na wczesnym etapie
28 Cechy charakterystyczne przypadków użycia Przypadki użycia powinny być: Kompletne Zrozumiałe Niezależne od implementacji i używanej technologii Dobrze zaprojektowane z punktu widzenia użytkownika
29 Dlaczego tak? Sponsorzy są w stanie stwierdzić, co będzie zrobione, a co nie Użytkownicy wiedzą, co system będzie robił, a co nie (ewentualne sugestie są możliwe na tym etapie) Developerzy wiedzą, nad czym będą pracować
30 Elementy diagramu przypadków użycia Aktorzy (ang. actors) osoba, organizacja, system wewnętrzny wchodzący w interakcję z danym systemem Przypadki użycia (ang. use cases) sekwencja akcji wykonywana przez aktora (- ów) Asocjacje (ang. associations) Powiązanie pomiędzy aktorem a przypadkiem użycia
31 Przykład diagramu
32 Czym są i do czego służą diagramy przypadków użycia Definicja diagramu przypadku użycia: Diagram ukazujący relacje między aktorami i przypadkami użycia wewnątrz system Zastosowanie diagramu przypadku użycia: Modelowania całości lub części wymagań użytkowników systemu W skład modelu przypadków użycia wchodzą: diagramy przypadków użycia dokumentacje specyfikujące przypadki użycia oraz definicje aktorów
33 Dobór aktorów Przy doborze aktorów istotne jest: Ustalenie jaka grupa użytkowników potrzebuje wspomagania ze strony systemu Z jakich systemów zewnętrznych musi korzystać system do poprawnego realizowania swoich funkcji Ustalenie czy jest to aktor konkretny (np. Jan Kowalski) czy określenie roli (np. sprzedawca) Relacje pomiędzy aktorami warto ustanowić relację dziedziczenia pomiędzy aktorami Ustalenie głównych zadań aktorów
34 Możliwości ponownego wykorzystania komponentów Relacja rozszerzania (<<extend>>) Relacja zawierania (<<include>> w UML 2.0; <<uses>> w poprzednich wersjach)
35 Zawieranie przypadków użycia Zależność zawierania pomiędzy przypadkami użycia (ang. include dependancy) Polega na wywoływaniu jednego przypadku przez drugi
36 Rozszerzanie przypadków użycia Zależność rozszerzania pomiędzy przypadkami użycia (ang. extend dependency) rozszerzenie polega na dodaniu dodatkowych sekwencji akcji do sekwencji przypadku bazowego - w ten sposób można tworzyć alternatywny scenariusz dla bazowego przypadku użycia
37 Dziedziczenie Przypadków użycia: Zastępuje sekwencję akcji dziedziczonego przypadku użycia przez sekwencję akcji dziedziczącego przypadku użycia Aktorów: Bardziej wyspecjalizowany aktor dziedziczy zachowanie mniej wyspecjalizowanego aktora
38 Przykład zależności pomiędzy aktora
39 Przebiegi alternatywne (1) UC01 Aktorzy Warunki wstępne Obsługa zgłoszeń (dodawanie, przeglądanie, modyfikacja) Użytkownik - Aktor musi być zalogowany w systemie - Aktor musi widzieć przynajmniej jedno zgłoszenie (dla przepływów I i III) Przepływ główny Przeglądanie listy zgłoszeń 1. Aktor wskazuje projekt/moduł którego zgłoszenia chce przeglądać 2. System wyświetla listę dostępnych dla aktora zgłoszeń i umożliwia ich przeglądanie Przepływy alternatywne I Przeglądanie szczegółów 3. Aktor wskazuje zgłoszenie którego szczegóły chce przeglądać 4. System wyświetla szczegółowe informacje o zgłoszeniu 5. Aktor wybiera opcję zakończenia przeglądania szczegółów 6. System przechodzi do kroku 2. przepływu głównego II Dodawanie zgłoszenia 3. Aktor wybiera opcje dodania zgłoszenia 4. System umożliwia wprowadzenie danych nowego zgłoszenia 5. Aktor wprowadza wymagane dane i zatwierdza wykonanie operacji 6. System potwierdza dodanie nowego zgłoszenia i przechodzi do kroku 2. III Modyfikacja zgłoszenia 3. Aktor wskazuje zgłoszenie które chce zmodyfikować 4. System wyświetla bieżące dane zgłoszenia i umożliwia modyfikację danych edytowalnych 5. Aktor modyfikuje wybrane dane i zatwierdza wykonanie operacji 6. System potwierdza modyfikację zgłoszenia i przechodzi do kroku 2.
40 Przebiegi alternatywne (2) Warunki końcowe Dla przepływu II i III zmiana stanu systemu Wyjątki Anulowanie wykonywania operacji (przejście z kroku II.5, III.5) System potwierdza anulowanie operacji i przechodzi do kroku 2. przepływu głównego Brak uprawnień (przejście z kroku I.4, II.3, III.3) System informuje o braku uprawnień do wykonania odpowiedniej czynności i powraca do kroku 2. przepływu głównego Błędne lub niepełne dane zgłoszenia (przejście z kroku II.6, III.6) System informuje o podaniu błędnych lub niepełnych danych zgłoszenia i umożliwia ponowne podanie danych zgłoszenia
41 Dobre rady dla projektantów Przypadki użycia Nazwy powinny być zaczerpnięte z rozpatrywanej dziedziny systemu Rozmieszczenie przypadków użycia z użyciem ograniczeń czasowych Przypadek użycia nie powinien być ani za bardzo ogólny ani za bardzo szczegółowy
42 Dobre rady dla projektantów c.d. Aktorzy Podstawowi aktorzy powinni być umieszczeni w lewym górnym rogu diagramu Nazwa aktora powinna być rzeczownikiem w liczbie pojedynczej, określającą rolę aktora (nie jego pozycję) Każdy aktor powinien być powiązany z jednym lub większą liczbą przypadków użycia
43 Dobre rady dla projektantów c.d. Relacje: Asocjacje pomiędzy aktorem a przypadkiem użycia powinny być wskazywane, jeżeli aktor pojawia się wewnątrz logiki przypadku użycia Relacja <<include>> używa się, jeżeli dokładnie wiadomo, kiedy wywołać przypadek użycia Relacja <<extend>> używa się, jeżeli przypadek użycia może być wywoływany w wielu miejscach innego przypadku użycia
44 Dobre rady dla projektantów c.d. Relacje c.d.: Relacje <<extend>> powinny być używane nie za często Unikanie więcej niż dwóch poziomów asocjacji przypadków użycia Umieszczanie zawieranego przypadku użycia po prawej stronie wywołującego Umieszczanie rozszerzającego przypadku użycia poniżej bazowego
45 Dobre rady dla projektantów c.d. Relacje c.d.: Umieszczanie dziedziczącego przypadku użycia poniżej przypadku bazowego Umieszczanie dziedziczącego aktora poniżej aktora bazowego
46 Dla zainteresowanych: Alistair Cockburn Writing Effective Use Cases
47 Dziękuje..
Technologia programowania
Wykład 1 2 październik 2018 Cel kursu Znacie język programowania oraz umiecie tworzyć proste aplikacje. Nie macie doświadczenia w tworzeniu dużych i złożonych systemów. Aby stworzyć duży system należy:
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoDiagram 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ółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
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ół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ół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ół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ół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ółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
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ół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ół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ół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ół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ółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
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ółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoPrzypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady
Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!!
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements
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ół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ół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ółowoCele przedsięwzięcia
Określanie wymagań Cele przedsięwzięcia 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ół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ółowoSystem CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski
System CRM dla banku Analiza i projekt Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski Spis treści 1 Cel projektu 3 2 Słownik 4 3 Wymagania funkcjonalne 5 3.1 F.BK Baza klientów.................................
Bardziej szczegółowoKarty pracy. Ustawienia. W tym rozdziale została opisana konfiguracja modułu CRM Karty pracy oraz widoki i funkcje w nim dostępne.
Karty pracy W tym rozdziale została opisana konfiguracja modułu CRM Karty pracy oraz widoki i funkcje w nim dostępne. Ustawienia Pierwszym krokiem w rozpoczęciu pracy z modułem Karty Pracy jest definicja
Bardziej szczegółowoZałącznik nr 1. Specyfikacja. Do tworzenia Mapy Kompetencji
Załącznik nr 1 Specyfikacja Do tworzenia Mapy Kompetencji 1. Cel projektu Celem projektu jest utworzenie Mapy kompetencji. Ma ona zawierać informacje o kompetencjach, celach kształcenia, umożliwiać ich
Bardziej szczegółowoProjektowanie systemów informatycznych. Diagramy przypadków użycia
Informacje ogólne i przykłady Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski jako narzędzie modelowania wymagań Nazwa use case diagrams. Cel stosowania Określenie wymagań
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ółowoSystem CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski
System CRM dla banku Analiza i projekt Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski Spis treści 1 Wprowadzenie 4 1.1 Cel projektu....................................... 4 1.2 Słownik.........................................
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ółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoFeature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
Bardziej szczegółowoJęzyk UML. dr inż. Piotr Szwed C3, pok
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,
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żynierski Projekt Zespołowy
Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,
Bardziej szczegółowoR o g e r A c c e s s C o n t r o l S y s t e m 5
R o g e r A c c e s s C o n t r o l S y s t e m 5 Nota aplikacyjna nr 003 Wersja dokumentu: Rev. B Uprawnienia Uwaga: Niniejszy dokument dotyczy RACS v5.2 (VISO 1.2.2 lub nowszy) Wprowadzenie W systemie
Bardziej szczegółowo1. Logowanie się do panelu Adminitracyjnego
Spis treści 1. Logowanie się do panelu Adminitracyjnego...1 2. Tworzenie i zarządzenie kategoriami...4 2.1 Nawigowanie po drzewie kategorii...5 2.2 Tworzenie kategorii...6 2.3 Usuwanie kategorii...9 3.
Bardziej szczegółowoSzkolenie z zakresu obsługi kreatora składania wniosków Witkac.pl po nowelizacji ustawy o działalności pożytku publicznego i o wolontariacie
Szkolenie z zakresu obsługi kreatora składania wniosków Witkac.pl po nowelizacji ustawy o działalności pożytku publicznego i o wolontariacie 21 listopada 2016 r. 1 Dodawanie oferty pojedynczego podmiotu
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoNowa Netia administrator firmy Nagrywanie połączeń-zarządzanie
RBT API v2.3 Nowa Netia administrator firmy Nagrywanie połączeń-zarządzanie Spis treści I. WPROWADZENIE 2 II. OPIS FUNKCJONALNOŚCI..3 1. LOGOWANIE I ZMIANA HASŁA...3 1.1 LOGOWANIE..3 1.2 WIDOK PO ZALOGOWANIU...4
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ółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowo1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail
1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce
Bardziej szczegółowoPlatforma e-learningowa
Dotyczy projektu nr WND-RPPD.04.01.00-20-002/11 pn. Wdrażanie elektronicznych usług dla ludności województwa podlaskiego część II, administracja samorządowa realizowanego w ramach Decyzji nr UDA- RPPD.04.01.00-20-002/11-00
Bardziej szczegółowoEXSO-CORE - specyfikacja
EXSO-CORE - specyfikacja System bazowy dla aplikacji EXSO. Elementy tego systemu występują we wszystkich programach EXSO. Może on ponadto stanowić podstawę do opracowania nowych, dedykowanych systemów.
Bardziej szczegółowoKonfiguracja i obsługa modułu Service Desk
Konfiguracja i obsługa modułu Service Desk wersja 07.03.2017 1. Wstęp Moduł Service Desk w BeeOffice pozwala na obsługę zgłoszeń serwisowych w ramach pojedynczej organizacji (np. użytkownicy IT i helpdesk
Bardziej szczegółowoDiagramy przypadków uŝycia. związków między nimi
Diagramy przypadków uŝycia Graficzne przedstawienie przypadków uŝycia, aktorów oraz związków między nimi Zadania diagramów platforma komunikacji pomiędzy inwestorem a twórcą systemu identyfikacja i dokumentacja
Bardziej szczegółowoZmiany wprowadzone w pakiecie. Projekt PSZ.eDOK
Projekt Wersja 4.0 2 kwietnia 2012 Dokument wg wzorca PULS/SW/KOD/FR/10 Strona: 1 Spis treści 1. 3 Moduł administratora 1.1. Poszerzono funkcjonalność zmiany drzewa struktury organizacyjnej 3 1.2. Umożliwiono
Bardziej szczegółowoPlatforma e-learningowa
Dotyczy projektu nr WND-RPPD.04.01.00-20-002/11 pn. Wdrażanie elektronicznych usług dla ludności województwa podlaskiego część II, administracja samorządowa realizowanego w ramach Decyzji nr UDA- RPPD.04.01.00-20-002/11-00
Bardziej szczegółowoDiagram wdrożenia. Rys. 5.1 Diagram wdrożenia.
Diagram wdrożenia Zaprojektowana przez nas aplikacja bazuje na architekturze client-server. W tej architekturze w komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia
Bardziej szczegółowoLaboratorium z przedmiotu: Inżynieria Oprogramowania INP
Laboratoria 5-7- część 1 Identyfikacja klas reprezentujących logikę biznesową projektowanego oprogramowania, definicja atrybutów i operacji klas oraz związków między klasami - na podstawie analizy scenariuszy
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ółowoWOJSKOWA AKADEMIA TECHNICZNA
WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko
Bardziej szczegółowoINSTRUKCJA LABORATORIUM Automatyzacja procesów przemysłowych.
INSTRUKCJA LABORATORIUM Automatyzacja procesów przemysłowych. SysML profil modelu własne stereotypy SysML002 str. 1/11 Tworzenie profilu modelu Profil modelu zawiera zmiany (rozszerzenia) języka modelowania,
Bardziej szczegółowoBeeOffice. Konfiguracja i obsługa modułu Urządzenia
BeeOffice Konfiguracja i obsługa modułu Urządzenia Wersja 23.08.2018 Spis treści 1. Wstęp... 3 2. Konfigurowanie rodzajów urządzeń... 4 Definiowanie pól dodatkowych... 5 3. Konfigurowanie dostępu dla administratorów
Bardziej szczegółowoKONTROLA JAKOŚCI Zapewnienie jakości w projekcie tworzenia oprogramowania
KONTROLA JAKOŚCI Zapewnienie jakości w projekcie tworzenia oprogramowania Model środowiska Model przypadków użycia Model czynności Model klas Model wymagań Model
Bardziej szczegółowoLista wprowadzonych zmian w systemie Vario v. 3.3 od wydania 3.003.60177.00403 do wydania 3.003.60180.00419
Lista wprowadzonych zmian w systemie Vario v. 3.3 od wydania 3.003.60177.00403 do wydania 3.003.60180.00419 LP Vario* Wersja Zmiany 1. BPM 3.003.60177.00403 Ulepszenie działania pola przeznaczonego do
Bardziej szczegółowoSystem CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski
System CRM dla banku Analiza i projekt Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski Spis treści 1 Wprowadzenie 4 1.1 Cel projektu....................................... 4 1.2 Słownik.........................................
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ółowoJerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro
Jerzy Skalski s9473, grupa WIs I.6-11c System wspierający obsługę klienta dla firm sprzedających na Allegro 1. WYMAGANIA UŻYTKOWNIKA Użytkownicy systemu: System powinien przechowywać informacje dotyczące:
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ół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 6 Diagramy komunikacji Diagram komunikacji (ang. communication diagram),
Bardziej szczegółowoINSTRUKCJA UŻYTKOWNIKA
INSTRUKCJA UŻYTKOWNIKA INSTRUKCJA DLA KLIENTA Wprowadzenie faktury sprzedaży Wersja 1.0 Marki, dn. 2018-02-20 Strona 2 z 9 Spis treści 1. CEL DOKUMENTU... 3 2. DEFINICJA NAZW I SKRÓTÓW... 3 3. SCHEMAT
Bardziej szczegółowoMAS dr. Inż. Mariusz Trzaska
MAS dr. Inż. Mariusz Trzaska Wykład 2 Model przypadków użycia Zagadnienia Prezentowanie diagramów Stereotypy; komentarze Klasyfikatory; wystąpienia klasyfikatorów Związki pomiędzy elementami modelowania
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ółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoPraktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek
Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC Jarosław Świerczek Punkty funkcyjne Punkt funkcyjny to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoModelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie klas i obiektów Jarosław Kuchta Podstawowe pojęcia (1) Byt, encja (entity) coś co istnieje, posiada własne cechy i wyodrębnioną tożsamość (identity); bytem może być rzecz, osoba, organizacja,
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ółowoSŁOWNIK STRUKTURY PRZEDSIĘBIORSTWA
J.B.R. ROGOWIEC SP. J. ul. Zapora 23, 43-382 Bielsko-Biała SŁOWNIK STRUKTURY PRZEDSIĘBIORSTWA Dostosowano do wersji 2.11 Systemu DMS SPIS TREŚCI SŁOWNIK STRUKTURY PRZEDSIĘBIORSTWA WPROWADZENIE... 3 1.
Bardziej szczegółowoInstrukcja wprowadzania i aktualizacji danych dotyczących realizacji wypłat w Oprogramowaniu do obsługi Świadczeń SR/SW/FA
Instrukcja wprowadzania i aktualizacji danych dotyczących realizacji wypłat w Oprogramowaniu do obsługi Świadczeń SR/SW/FA Dane dotyczące sposobu realizacji wypłat, w tym informację o numerze konta bankowego,
Bardziej szczegółowoZmiany funkcjonalne i lista obsłużonych zgłoszeń Comarch DMS
Zmiany funkcjonalne i lista obsłużonych zgłoszeń 1. Wstęp W niniejszym dokumencie zostały opisane modyfikacje wprowadzone w wersji. 2. Poprawa bezpieczeństwa danych w W instalatorze wprowadzono nową funkcjonalność
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ółowoPodręcznik użytkownika Obieg dokumentów
Podręcznik użytkownika Obieg dokumentów Opracowany na potrzeby wdrożenia dla Akademii Wychowania Fizycznego im. Eugeniusza Piaseckiego w Poznaniu W ramach realizacji projektu: Uczelnia jutra wdrożenie
Bardziej szczegółowoSYSTEM ZARZĄDZANIA RELACJAMI Z KLIENTEM CRM7
SYSTEM ZARZĄDZANIA RELACJAMI Z KLIENTEM CRM7 Administracja instrukcja Panel administracyjny jest dostępny z menu po lewej stronie ekranu. Użytkownicy bez uprawnień administracyjnych mają tylko możliwość
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ółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
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ół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ółoworaporty-online podręcznik użytkownika
raporty-online podręcznik użytkownika Ramzes Sp. z o.o. jest wyłącznym właścicielem praw, w tym wszelkich majątkowych praw autorskich do programu oraz treści podręcznika użytkownika. Powielanie w jakiejkolwiek
Bardziej szczegółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoInstrukcja obsługi Zaplecza epk dla Pracowników Instytucji w zakresie zarządzania danymi szczegółowymi dotyczącymi sposobu realizacji procedury
Instrukcja obsługi Zaplecza epk dla Pracowników Instytucji w zakresie zarządzania danymi szczegółowymi dotyczącymi sposobu realizacji procedury 1 Spis treści: 1 WSTĘP... 3 2 DOSTĘP DO SYSTEMU... 3 3 INSTYTUCJA
Bardziej szczegółowoERGODESIGN - Podręcznik użytkownika. Wersja 1.0 Warszawa 2010
ERGODESIGN - Podręcznik użytkownika Wersja 1.0 Warszawa 2010 Spis treści Wstęp...3 Organizacja menu nawigacja...3 Górne menu nawigacyjne...3 Lewe menu robocze...4 Przestrzeń robocza...5 Stopka...5 Obsługa
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoB2B Obsługa portalu zgłoszeniowego
B2B Obsługa portalu zgłoszeniowego Spis treści 1. Ustalenia loginu i hasła, reset hasła... 1 1.1 Ustalenia hasła przez użytkownika... 1 2. Logowanie do systemu uprawnienia pełne/uproszczone... 2 2.1 Uprawnienia
Bardziej szczegółowoPodstawy Zarządzania Projektami w Organizacjach
Podstawy Zarządzania Projektami w Organizacjach JAK DOBRZE ROZPOCZĄĆ PROJEKT 2010-05-14 Krzysztof Kamiński Przemysław Kotecki AGENDA Wprowadzenie do Zarządzania Projektami Rola rozpoczynania projektów
Bardziej szczegółowoUżytkownik przypisany zostaje również do danej grupu uprawnień szczegóły punkt 6.
Instrukcja IMZ Wersja 2.0 1. INFORMACJE OGÓLNE IMZ jest modułem umożliwiającym przesyłanie do firmy Nowa France zamówień i kosztorysów. Dowody są automatycznie importowane do systemu sprzedaży Nowa France.
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ółowoAnaliza procesów: notacja UML, modele przypadków użycia, Rich Picture
45 min Ergonomia pracy umysłowej prof. dr hab. inż. Marcin Sikorski Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture 7 Data wykładu:............. Razem slajdów: 23 Sytuacja problemowa
Bardziej szczegółowoInżynieria oprogramowania wykład IV Faza określenia wymagań
Inżynieria oprogramowania wykład IV Faza określenia wymagań prowadzący: dr inż. Krzysztof Bartecki Faza określenia wymagań Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza
Bardziej szczegółowo