Proces Inżynierii Wymagań
|
|
- Mieczysław Cieślik
- 8 lat temu
- Przeglądów:
Transkrypt
1 Proces Inżynierii Wymagań michał możdżonek
2 Literatura 1. Sommerville I. (2003): Inżynieria oprogramowania, WNT, Warszawa 2. Leffingwell D., Widrig D. (2003): Zarządzanie wymaganiami, WNT, Warszawa 3. Pressman R. S. (2004): Praktyczne podejście do inżynierii oprogramowania, WNT, Warszawa
3 Proces Inżynierii Wymagań Procesy służące do zidentyfikowania, przeanalizowania i zatwierdzenia wymagań systemowy Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3
4 Cele Rozumienie podstawowych czynności inżynierii wymagań Poznanie metod określania i analizowania wymagań Rozumienie znaczenia zatwierdzania wymagań Rozumienie roli zarządzania wymaganiami oraz tego, jak wspomaga ono inne czynności inżynierii wymagań
5 Zawartość Studium wykonalności Określenie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami
6 Procesy inżynierii wymagań Procesu używane w IW różnią się mocno w zależności od dziedziny, w której działamy i odludzi zaangażowanych w działanie organizacji i budowę systemu. Mimo to istnieje kilka czynności wspólnych dla wszystkich sytuacji Wydobywanie wymagań Analiza wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami
7 Proces inżynierii wymagań Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Raport o wykonalności Model systemu Zatwierdzanie wymagań Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań
8 Studium wykonalności Studium wykonalności decyduje czy warto wykonać system Krótkie opracowanie, odpowiadające na pytania Czy system przyczyni się do realizacji celów organizacji? Czy system może być stworzony przy użyciu dostępnych technologii w ramach określonego budżetu i ograniczeń czasowych? Czy system może być zintegrowany z istniejącymi systemami?
9 Przeprowadzenie studium wykonalności Określenie i zebranie informacji a następnie napisanie raportu Pytania, które powinny być zadane Co się stanie jeśli system nie powstanie? Jakie problemy aktualnie występują? Jak system pomoże w ich rozwiązaniu? Jakie będą problemy z integracją? Jakie nowe technologie są potrzebne? Jaki umiejętności? Jakie udogodnienia musi wspierać system a jakich nie?
10 Wydobywanie i analiza Czasem nazywana odkrywaniem wymagań Angażuje technicznych budowniczych, którzy pracując z klientami wydobywają od nich wiedzę o dziedzinie, informacje o usługach, które system powinien udostępniać i ograniczenia dla działania systemu Może angażować użytkowników końcowych, inżynierów klienta, ekspertów z dziedziny, i innych. Nazywamy ich uczestnikami
11 Problemy z analizą wymagań Uczestnicy nie wiedzą czego naprawdę oczekują Uczestnicy wyrażają wymagania w hermetycznym języku Różni uczestnicy mają sprzeczne wymagania Czynniki organizacyjne i polityczne wpływają na wymagania systemowe Wymagania zmieniają się w czasie trwania procesu analizy. Pojawiają się nowi uczestnicy a otoczenie biznesowe się zmienia
12 Proces analizy wymagań Początek procesu Rozpoznanie dziedziny Sprawdzanie wymagań Specyfikacja wymagań Nadawanie priorytetów Dokumentacja wymagań Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja
13 Czynności procesu Rozpoznanie dziedziny Zebranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań
14 Modele systemu Różne modele mogą powstawać podczas różnych czynności analizy wymagań Analiza wymagań może angażować trzy czynności systematyzujące, które prowadzą do trzech różnych modeli Dzielenie. Odnajduje strukturalne (część czegoś) związki pomiędzy encjami. Abstrakcja. Odnajduje generalizacje pomiędzy encjami Projekcja. Identyfikuje różne spojrzenia na ten sam problem O modelach systemu opowiem za tydzień
15 Określanie oparte na punktach widzenia Uczestnicy miewają różne punkty widzenia na ten sam problem Analiza z wielu perspektyw jest ważna, ponieważ nie istnieje jedynie słuszna metoda na analizowanie wymagań
16 System obsługi bankomatu Przykład opisuje bankomat, który może dostarczać wielu usług Upraszczamy system mówiąc, że bankomat jest własnością banku i klientom tego banku oferuje pełną gamę usług, a klientom innych banków usługi w ograniczonym zakresie Usługi zawierają: wypłatę pieniędzy, wysłanie wiadomości do banku, wydruk stanu konta i przelew pieniędzy
17 Punkty widzenia dla bankomatu Klienci banku Przedstawiciele innych banków Inżynierowie pielęgnacji sprzętu i oprogramowania Dział marketingu banku Dyrektorzy oddziałów banku Administratorzy baz danych i dział bezpieczeństwa Inżynierowie komunikacji Pracownicy obsługi klienta w oddziałach
18 Zewnętrzne punkty widzenia Naturalny sposób myślenia o końcowych użytkownikach systemu Punkty widzenia w naturalny sposób porządkują wymagania Łatwo stwierdzić czy coś jest punktem widzenia czy nie Punkty widzenia i usługi stanowią dobry sposób na uporządkowanie wymagań niefunkcjonalnych
19 Identyfikacja punktów widzenia Pytanie o saldo Zasoby maszyny Interfejs użytkownika Właściciel konta Zdalna diagnostyka Odczyt transakcji Informacje o koncie Menedżer Koszt systemu Karta skradziona Zamówienie wyciągu Niezawodność Baza danych klientów Dziennik komunikatów Obcy klient Zwrot karty Aktualizacja konta Wypłata gotówki Rozmiar oprogramowania Drukarka Pielęgnacja oprogramowania Zdalna aktualizacja oprogramowania Przelew środków Dziennik transakcji Kasa banku Zabezpieczenia Przekazywanie komunikatów Zamówienie czeków Nieuprawniony użytkownik Zatrzymanie karty Weryfikacja karty
20 Informacje o usługach Właściciel konta Obcy klient Kasa banku Lista usług Lista usług Lista usług Wypłata gotówki Wypłata gotówki Diagnostyka Pytanie o saldo Pytanie o saldo Dodanie gotówki Zamówienie czeków Wysłanie komunikatu Dodanie papieru Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków
21 Dane wejściowe i sterujące WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcję Anuluj transakcję Informacje z karty PIN Zakończ transakcję Żądana kwota Wybór usługi Komunikat
22 Hierarchia punktów widzenia Wszystkie PW Usługi Pytanie o saldo Wypłata gotówki Klient Personel banku Usługi Zamówienie czeków Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Właściciel konta Klient obcy Kasa Menedżer Inżynier
23 Wzory: klient/wypłata gotówki Odnośnik: Klient Atrybuty: Numer konta, PIN Zdarzenia: Zacznij transakcję, Wybór usługi, Anuluj transakcję, Zakończ transakcję Usługi: Wypłata gotówki, Pytanie o saldo Podrzędne: Właściciel konta, Klient Obcy Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby papierowych dokumentów Specyfikacja: Użytkownicy wybierają tę usługę przez naciśnięcie przycisku wypłata gotówki. Następnie wprowadzają żądaną kwotę. Potwierdza się ją i jeśli na koncie są odpowiednie środki, następuje wypłata Punkty widzenia: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później
24 Scenariusze Scenariusze są przykładami, jak system jest używany w praktyce Są przydatne podczas wydobywania wymagań, ponieważ ludzie rozumieją je dużo lepiej niż abstrakcyjne opisy tego, co oczekują od systemu Scenariusze są szczególnie przydatne w dodawaniu szczegółów do ogólnych opisów
25 Opis scenariusza Stan systemu przed rozpoczęciem scenariusza Normalny przebieg zdarzeń scenariusza Co może pójść źle i jak to jest obsługiwane Inne zdarzenia, które mogą dziać się w tym samym czasie Stan systemu po zakończeniu scenariusza
26 Scenariusz zdarzenia zacznij transakcję Wsunięto kartę Karta PIN Poproś o PIN Przekroczenie limitu czasu Zwróć kartę Karta nieważna Numer konta PIN Sprawdź użytkownika Zły PIN Karta ważna Wprowadź ponownie PIN Numer konta Użytkownik OK Wybierz usługę Zwróć kartę Zły PIN Karta skradziona Zwróć kartę Zatrzymaj kartę
27 Konwencje dla scenariuszy zdarzeń Elipsy to dane przekazywane z i do reprezentantów punktów widzenia Informacja sterująca wychodzi z góry prostokąta Dane wychodzą z boku prostokąta Wyjątki są pokazywane na dole prostokątów Następne zdarzenie w cieniowanym prostokącie
28 Opis wyjątków Większość metod nie posiada udogodnień do opisu wyjątków W tym przykładzie wyjątkami są Przekroczenie limitu czasu. Klientowi nie udało się wprowadzić kodu PIN w wyznaczonym czasie Karta nieważna. Nie udało się rozpoznać karty Karta skradziona. Karta została zgłoszona jako skradziona
29 Przypadki użycia Przypadki użycia są używaną w UML-u techniką opartą na scenariuszach i definiują aktorów biorących udział w interakcji, co opisuje samą interakcję Zbiór przypadków użycia powinien opisywać wszystkie interakcje w systemie Diagramy przebiegów mogą służyć do dodawania szczegółowej informacji do przypadków użycia
30 Przypadek użycia - wypożyczenie Obsługa wypożyczania
31 Przypadki użycia biblioteki Czytelnik Obsługa wypożyczania Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu
32 Zarządzanie katalogiem Sprzedawca książek Składnik: Składnik biblioteki Książki: Katalog Katalogujący: Personel biblioteki Nabądź Nowy Kataloguj składnik Usuń Usuń składnik z katalogu
33 Przykład Zastanówmy się nad systemem, który powinien pozwalać wyższej kadrze zarządzającej na dostęp do informacji z pominięciem średniej kadry Status menedżerów. Menedżerowie mogą myśleć, że są zbyt ważni,,by używać klawiatury. To może ograniczać interfejs Zadania menedżerów. Menedżerowie mogą nie mieć wystarczająco dużo czasu, żeby nauczyć się obsługiwać system Opór organizacyjny. Średni menedżerowie mogą celowo podawać mylące lub niekompletne informacje, aby nie okazało się, że ich znaczenie w firmie maleje
34 Etnografia Socjologowie spędzają dużo czasu obserwując jak ludzie rzeczywiście pracują Ludzie nie muszą wyjaśniać jak pracują Mogą być zaobserwowane czynniki społeczne i organizacyjne Studia etnograficzne zazwyczaj pokazują, że organizacja pracy jest bardziej skomplikowana niż modele systemu
35 Szczegółowa etnografia Powstała podczas informatyzacji systemu kontroli lotów Łączy etnografię i prototypowanie Tworzenie prototypów prowadzi do powstania pytań na które odpowiada etnografia Problemem etnografii jest to, że obserwuje ona istniejące działania, które mogą mieć podstawy historyczne nie istotne w chwili obecnej
36 Etnografia i prototypowanie Analiza etnograficzna Narady Szczegółowa etnografia Ogólne tworzenie systemu Prototypowanie systemu Ocena prototypu
37 Zakres etnografii Wymagania opisują jak ludzie pracują, zamiast definiować jak ludzie powinni pracować Wymagania są wydobywane z zakresu pracy i obowiązków pracujących ludzi
38 Zatwierdzanie wymagań Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać Poprawianie błędów w wymaganiach może kosztować sto razy więcej niż poprawianie błędów w implementacji
39 Sprawdzenia wymagań Ważność. Czy system rzeczywiście dostarcza funkcji, które najlepiej spełniają potrzeby użytkownika? Spójność. Czy wymagania nie są sprzeczne? Kompletność. Czy są wszystkie wymagania? Realność. Czy można zaimplementować wszystkie wymagania? Weryfikowalność. Czy można je zweryfikować?
40 Techniki zatwierdzania wymagań Przeglądy wymagań Systematyczne analizy wymagań Prototypowanie Przedstawianie klientom działającego modelu systemu Generowanie testów Tworzenie testów dla sprawdzenia czy wymagania są weryfikowalne Automatyczne sprawdzanie niesprzeczności Sprawdzanie niesprzeczności wymagań wyrażonych w strukturalnej lub formalnej notacji
41 Przeglądy wymagań Powinny odbywać się regularnie dopóki formułowane są nowe wymagania Powinny być wykonywane przez zespół składający się z pracowników obu stron Mogą być formalne (udokumentowane) lub nieformalne. Dobra komunikacja między twórcami, klientami i użytkownikami daje dobre efekty i pozwala na identyfikację problemów we wczesnych fazach
42 Lista sprawdzeń dla wymagania Weryfikowalność. Czy wymaganie można praktycznie sprawdzić? Zrozumiałość. Czy wymaganie jest zrozumiałe? Pochodzenie. Czy wiadomo skąd pochodzi wymaganie? Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe.
43 Automatyczne sprawdzanie niesprzeczności Wymagania w języku formalnym Raporty o sprzecznych wymaganiach Kompilator Generator raportów Baza danych wymagań
44 Zarządzanie wymaganiami Zarządzanie wymaganiami to proces zarządzania zmianami wymagań podczas zbierania wymagań i tworzenia systemu Wymagania są praktycznie zawsze niekompletne i sprzeczne Nowe wymagania pojawiają się podczas trwania przedsięwzięcia ze względu na zmiany w otoczeniu i lepsze zrozumienie systemu Różne punkty widzenia mają różne i często sprzeczne wymagania
45 Zmiany wymagań Ważność wymagań zależy od punktu widzenia Klienci systemu mogą wyrażać wymagania z perspektywy biznesowej co może być sprzeczne z wymaganiami użytkowników końcowych Otoczenie biznesowe i techniczne zmienia się w trakcie trwania przedsięwzięcia
46 Ewolucja wymagań Wstępne zrozumienie problemu Zmienione zrozumienie problemu Wstępne wymagania Zmienione wymagania Czas
47 Wymagania stałe i zmienne Wymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu Wymagania zmienne to wymagania,,które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkownika
48 Klasyfikacja wymagań zmiennych Wymagania środowiskowe Wymagania, które zmieniają się na skutek zmian środowiska Wymagania pojawiające się Wymagania pojawiające się podczas lepszego zrozumienia powstającego systemu Wymagania wynikowe Wymagania, które wynikają z wdrożenia systemu komputerowego Wymagania zgodności Wymagania, które zależą od konkretnych systemów lub procesów wewnątrz firmy
49 Planowanie zarządzania wymaganiami Podczas zarządzania wymaganiami musisz zaplanować: Oznakowanie wymagań Jak wymagania są unikatowo oznakowane Proces zarządzania zmianami Proces, który następuje po zmianie wymagania Strategia śledzenia pochodzenia Ilość informacji o zależnościach pomiędzy wymaganiami, która jest utrzymywana Użycie narzędzi CASE Narzędzie wspierające zarządzanie wymaganiami
50 Śledzenie Śledzenie opisuje związki pomiędzy wymaganiami, ich pochodzeniem i projektem systemu Informacje o pochodzeniu Wiązania pomiędzy uczestnikami i wymaganiami wraz z uzasadnieniem tych wymagań Informacje o uzależnieniu wymagań Wiązania pomiędzy zależnymi wymaganiami Informacje o uzależnieniu projektu Wiązania pomiędzy wymaganiami a częściami projektu
51 Macierz zależności Req id 1.1 U R 1.2 U R U 1.3 R R 2.1 R U U 2.2 U 2.3 R U 3.1 R 3.2 R
52 Narzędzia CASE Przechowywanie wymagań Wymagania należy gromadzić w zabezpieczonej i administrowalnej składnicy danych Zarządzanie zmianami Proces zarządzania zmianami to proces przepływu pracy, którego stany mogą być precyzyjnie zdefiniowane przez co można go zautomatyzować Zarządzanie zależnościami Automatyczne ustalanie zależności pomiędzy wymaganiami a innymi elementami systemu
53 Zarządzanie zmianami wymagań Należy stosować do wszystkich postulowanych zmian wymagań Główne kroki Analiza problemu. Rozpoznanie problemu z wymaganiem i propozycja zmian Analiza zmiany i ocena kosztów. Szacuje efekty wprowadzenia zmiany Implementacja zmiany. Modyfikuje dokumentację wymagań i inne dokumentacje jeśli zachodzi taka potrzeba
54 Zarządzanie zmianami wymagań Rozpoznany problem Skorygowane wymaganie Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany
55 Główne tezy Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie i zarządzanie wymaganiami Analiza wymagań to proces iteracyjny obejmujący zrozumienie dziedziny, zbieranie wymagań, klasyfikowanie, nadawanie priorytetów, strukturalizację i zatwierdzanie Systemy mogą mięć różnych użytkowników z różnymi wymaganiami
56 Główne tezy Czynniki społeczne i organizacyjne mają wpływ na wymagania systemowe Zatwierdzanie wymagań to proces sprawdzania wymagań pod względem ważności, niesprzeczności, kompletności, realności i zdatności do zatwierdzania Zmiany gospodarcze prowadzą do zmian wymagań Zarządzanie wymaganiami obejmuje planowanie i zarządzanie zmianami
Inż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ółowoInżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot
Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie
Bardziej szczegółowoInżynieria Programowania Inżynieria wymagań
Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 11 marca 2017 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu
Bardziej szczegółowoInżynieria wymagań. Inżynieria wymagań 1/1
Inżynieria wymagań Inżynieria wymagań 1/1 Inżynieria wymagań 2/1 Wymagania stawiane oprogramowaniu Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. Proces wynajdowania, analizowania, dokumentowania
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
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ółowoInżynieria wymagań. Proces inżynierii wymagań
Inżynieria wymagań. Proces inżynierii wymagań Dilbert by Scott Adams, tłum. własne Wykorzystane materiały: prezentacje J.E. Sienkiewicza i M.A. Płotki I. Sommerville, Inżynieria oprogramowania, WNT 2003
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
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ółowoWytwórstwo oprogramowania. michał możdżonek
Wytwórstwo oprogramowania michał możdżonek 01.2008 Plan wykładu 1. Proces tworzenie oprogramowania 2. Zarządzanie projektami 3. Wymagania 4. Projektowanie 5. Testowanie 6. Szacowanie złożoności i kosztu
Bardziej szczegółowoWstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań
Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec
Bardziej szczegółowoProjektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik
Projektowanie oprogramowania Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik Agenda Weryfikacja i zatwierdzanie Testowanie oprogramowania Zarządzanie Zarządzanie personelem
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
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ół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ół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ół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ółowoDiagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI 2006 1
Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI 2006 1 Model podstawowy składa się z: modelu środowiskowego modelu
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ółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoInżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Inżynieria wymagań Jarosław Kuchta Cele inżynierii wymagań Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
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ół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ółowoCykle życia systemu informatycznego
Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów
Bardziej szczegółowoZasady organizacji projektów informatycznych
Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych
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ół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ółowoProjektowanie BAZY DANYCH
Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne
Bardziej szczegółowoPrzedsięwzięcia Informatyczne w Zarządzaniu
Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,
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ółowoAPIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI
APIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI dr inż. Grażyna Hołodnik-Janczura W8/K4 CO SIĘ MOŻE DZIAĆ PODCZAS WYKONYWANIA BIZNESOWEJ FUNKCJI
Bardziej szczegółowoŁatwa czy niełatwa droga do celu? - wdrożenie COSMIC w ZUS
- wdrożenie COSMIC w ZUS Warszawa, 07.06.2017 Dlaczego w ZUS zdecydowano się na wdrożenie wymiarowanie złożoności oprogramowania akurat metodą COSMIC? jest metodą najbardziej transparentną i ograniczającą
Bardziej szczegółowoSYSTEM OBSŁUGI PROCESU TWORZENIA ZAMÓWIEŃ. Wersja demonstracyjna aplikacji w Internecie : http://www.datacube.com.pl/edeal.php
SYSTEM OBSŁUGI PROCESU SKŁADANIA ZAPOTRZEBOWAŃ I TWORZENIA ZAMÓWIEŃ Wersja demonstracyjna aplikacji w Internecie : http://www.datacube.com.pl/edeal.php Manualna praca i sterta dokumentów w wersji papierowej
Bardziej szczegółowoSpis treści. Wstęp... 9
Wstęp... 9 Rozdział 1 ZARYS TEORII STEROWANIA PROCESAMI PRZEDSIĘBIORSTWA... 11 1. Zakres i potencjalne zastosowania teorii... 11 2. Opis szkieletowego systemu EPC II... 12 2.1. Poziomy organizacyjne, warstwy
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
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ółowoProjektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)
Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II) Jacek Cichosz www.zssk.pwr.wroc.pl Katedra Systemów i Sieci Komputerowych Politechnika Wrocławska Narzędzia modelowania
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ółowoZagadnienia (1/3) Inżynieria Oprogramowania
Zagadnienia (1/3) Pozyskiwanie i analiza Reprezentacje na poszczególnych etapach projektu Najczęściej pojawiające się problemy podczas pozyskiwania oraz metody ich rozwiązywania Reprezentacja z punktu
Bardziej szczegółowoInżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań
Inżynieria oprogramowania Wykład 6 Analiza i specyfikowanie wymagań Proces inżynierii wymagań Feasibility Study Feasibility Report Requirements Analysis System Models Requirements Definition Definition
Bardziej szczegółowoWymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne
Definiowanie wymagań Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: 1. Definicja wymagań jest zapisana w języku naturalnym jako rezultat rozmów z przedstawiciela klienta 2. Specyfikacja
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
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ółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
Bardziej szczegółowoFaza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja
Faza strategiczna określenie wymagań specyfikowanie projektowanie kodowanie implementacja testowanie produkt konserwacja Faza strategiczna Analiza Synteza Dokumentacja Instalacja Faza strategiczna (ang.
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ółowo020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła
020 ANALIZA WYMAGAŃ Prof. dr hab. Marek Wisła Wymagania Wymaganie (ang. requirement) - pojęcie wymagania jest różnie interpretowane przez różne organizacje zajmujące się produkcją oprogramowania. Może
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoProces zarządzania danymi
Proces zarządzania danymi PRAWO DPK=Dobra Praktyka Kliniczna (GCP) składa się z 13 podstawowych zasad z których dwie odnoszą się bezpośrednio do danych pochodzących z badań klinicznych PRAWO - ZASADY GCP
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ółowoUsługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
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ółowoDwie szkoły oceny 360 stopni. Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem
Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem Czy stosowanie tradycyjnego podejścia do metody 360 stopni jest jedynym rozwiązaniem? Poznaj dwa podejścia do przeprowadzania procesu oceny
Bardziej szczegółowoWszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.
Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym
Bardziej szczegółowoMetody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31
Metody wytwarzania oprogramowania Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania 2/31 Wprowadzenie Syndrom LOOP Late Późno Over budget Przekroczono budżet Overtime nadgodziny
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Inżyniera wymagań Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoInżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.
Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.
Bardziej szczegółowoInżynieria oprogramowania (Software Engineering)
Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie
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ół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ół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ółowoTom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania
Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu
Bardziej szczegółowoAutomatyzacja procesu i zarządzanie zespołem
Nowoczesne BOK Automatyzacja procesu i zarządzanie zespołem Wstęp: Automatyzacja w procesach obsługi klienta jest obecnie koniecznym elementem samej obsługi. Myślenie procesowe, związane z Business Process
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ół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ółowoMaciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
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ółowoUdane wdrożenie systemu IT
Udane wdrożenie systemu IT Maciej Guzek CMMS Department Marketing & Sales Manager mguzek@aiut.com.pl To nie takie proste Czego klient potrzebował Co klient zamówił Co zrozumiał analityk Co opisywał projekt
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ółowoCRM. Relacje z klientami.
CRM. Relacje z klientami. Autor: Jill Dyche Książka przeznaczona jest dla wielu czytelników -- od menedżerów do użytkowników Część 1. skierowana jest do kadry zarządzającej, menedżerów projektów oraz ludzi
Bardziej szczegółowoDESIGN THINKING. Peter Drucker. Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale.
DESIGN THINKING Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale. Peter Drucker WSTĘP Zdajemy sobie sprawę, że każdą organizację tworzą ludzie, dlatego
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoLaunch. przygotowanie i wprowadzanie nowych produktów na rynek
Z przyjemnością odpowiemy na wszystkie pytania. Prosimy o kontakt: e-mail: kontakt@mr-db.pl tel. +48 606 356 999 www.mr-db.pl MRDB Szkolenie otwarte: Launch przygotowanie i wprowadzanie nowych produktów
Bardziej szczegółowoInformatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu w języku angielskim Modeling and Analysis of Information Systems Obowiązuje od roku akademickiego
Bardziej szczegółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
Bardziej szczegółowoSPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE)
SPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE) Na podstawie http://wazniak.mimuw.edu.pl/index.php?title=io-2-lab Prof. dr hab. Marek Wisła INTERNETOWA SPRZEDAŻ KSIĄŻEK Księgarnia internetowa Przygotuj
Bardziej szczegółowoInżynieria Programowania Zarządzanie projektem
Inżynieria Programowania Zarządzanie projektem Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 12 października 2015 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4
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ółowoInstrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro.
Instrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro aktualizacja: 12 czerwca 2017 r. Spis treści: 1. Pierwsze logowanie do
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ółowoJakość w procesie wytwarzania oprogramowania
Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu
Bardziej szczegółowoPortal zarządzania Version 7.5
Portal zarządzania Version 7.5 PODRĘCZNIK ADMINISTRATORA Wersja: 29.8.2017 Spis treści 1 Informacje na temat niniejszego dokumentu...3 2 Informacje o portalu zarządzania...3 2.1 Konta i jednostki... 3
Bardziej szczegółowoJakie mamy rodzaje kart i do czego może służyć bankomat.
Jakie mamy rodzaje kart i do czego może służyć bankomat. Zgodnie z ustawą - Prawo bankowe - kartą płatniczą jest karta identyfikująca wydawcę i upoważnionego posiadacza do wypłaty gotówki lub dokonywania
Bardziej szczegółowoE-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Kod modułu E-1IZ2-1003-s2 Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu
Bardziej szczegółowoZnakowanie, zarządzanie i dystrybucja produktów w oparciu o standardy GS1
Znakowanie, zarządzanie i dystrybucja produktów w oparciu o standardy GS1 Szkolenia obejmuje przegląd najważniejszych i najczęściej stosowanych standardów GS1 wraz z praktycznymi informacjami na temat
Bardziej szczegółowoCEMEX Go. Faktury. Wersja 2.1
Faktury Wersja 2. Faktury Stawiając na innowacje i doskonaląc obsługę Klienta, firma CEMEX stworzyła zintegrowane rozwiązanie cyfrowe, nazwane, które pozwoli Ci zarządzać firmą w czasie rzeczywistym. WPROWADZENIE
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 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoE-I2SG-2010-s1. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Kod modułu E-I2SG-2010-s1 Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu
Bardziej szczegółowoZAŁĄCZNIK NR 1 DO ZAPYTANIA OFERTOWEGO
ZAŁĄCZNIK NR 1 DO ZAPYTANIA OFERTOWEGO 1. MODYFIKACJA MECHANIZMÓW GRY. Scenariusz główny 1. Wprowadzenie konsekwencji nie płacenia przez gracza za faktury/rachunki. W przypadku niezapłacenia terminowego
Bardziej szczegółowoPROJEKT INŻYNIERIA OPROGRAMOWANIA. Temat: System obsługi kasy - projekt wzorcowy
Wydział Elektroniki Politechniki Wrocławskiej Kierunek:., Specjalność:... PROJEKT INŻYNIERIA OPROGRAMOWANIA Temat: System obsługi kasy - projekt wzorcowy Opracowanie: dr inż. Paweł Skrobanek Wrocław 2006
Bardziej szczegółowoCase Study. aplikacji Microsoft Dynamics CRM 4.0. Wdrożenie w firmie Finder S.A.
Case Study aplikacji Microsoft Dynamics CRM 4.0 Wdrożenie w firmie Finder S.A. PRZEDSTAWIENIE FIRMY Finder jest operatorem systemu lokalizacji i monitoringu, wspomagającego zarządzanie pracownikami w terenie
Bardziej szczegółowoDiagramy przepływu danych I
Literatura bazowa: Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych I E.Yourdon, Współczesna analiza strukturalna, WNT, Warszawa 1996 J.Roberston, S.Robertson, Pełna analiza systemowa,
Bardziej szczegółowoMiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska
MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego
Bardziej szczegółowo