Przypadki użycia. Czyli jak opisywać funkcjonalność. Jerzy Nawrocki Mirosław Ochodek
|
|
- Lech Wróbel
- 8 lat temu
- Przeglądów:
Transkrypt
1 Przypadki użycia Czyli jak opisywać funkcjonalność Jerzy Nawrocki Mirosław Ochodek
2 Wymagania w kontekście procesu wytwarzania Opis problemu Scenariusze operacyjne Wymagania Projekt & Implementacja
3 Struktura SRS 1. Introduction 2. Overall description of the product 3. Functional requirements 3.1 Aktor (rola) Funkcja Funkcja 2 4. Non-functional requirements Appendices Index IEEE Std
4 Ivar Jacobson 1967: Ericsson, telecommunication systems 1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm 1987: Founder of Objectory AB -> (Objectory Process) 1995: Objectory AB merges with Rational 2003: IBM buys Rational
5 Use Case Diagram w UML Find flight Travel agent Construct itinerary Reserve flight Issue ticket Airline reservation Merchant bank
6 Przypadek użycia jako zbiór scenariuszy Ten sam cel Scenariusz #1 Scenariusz #2 Use Case Scenariusz #3
7 Scenariusze wypłata z bankomatu Nazwa: Wypłata z bankomatu Aktor: Wypłacający, (Bankomat) Scenariusz #1 1. Bankomat prosi o włożenie karty 2. Wypłacający wkłada kartę 3. Bankomat prosi o podanie nr PIN 4. Wypłacający podaje nr PIN 5. Bankomat prosi o podanie kwoty 6. Wypłacający podaje kwotę i zatwierdza 7. Bankomat wypłaca podaną kwotę
8 Scenariusze wypłata z bankomatu Nazwa: Wypłata z bankomatu Aktor: Wypłacający, (Bankomat) Scenariusz #2 1. Bankomat prosi o włożenie karty 2. Wypłacający wkłada kartę 3. Bankomat prosi o podanie nr PIN 4. Wypłacający podaje błędny nr PIN 5. Bankomat informuje o podaniu błędnego nr PIN 6.
9 Scenariusze wypłata z bankomatu Nazwa: Wypłata z bankomatu Aktor: Wypłacający, (Bankomat) Scenariusz #3 1. Bankomat informuje o awarii 2.
10 Use Case - wypłata z bankomatu Nazwa: Wypłata z bankomatu Aktor: Wypłacający, (Bankomat) Scenariusz główny: 1. Bankomat prosi o włożenie karty 2. Wypłacający wkłada kartę 3. Bankomat prosi o podanie nr PIN 4. Wypłacający podaje nr PIN 5. Bankomat prosi o podanie kwoty 6. Wypłacający podaje kwotę i zatwierdza 7. Bankomat wypłaca podaną kwotę Rozszerzenia: 1.A. Bankomat nieczynny 1.A.1. Bankomat informuje o awarii (Koniec) 4.A. Podano zły nr PIN 4.A.1. Bankomat informuje o podaniu złego nr PIN [3.]. 7.A. Nie ma wystarczającej gotówki do wypłaty 7.A.1. Bankomat informuj o braku gotówki i podaje maksymalną kwotę wypłaty [5.].
11 Poziomy przypadków Book trip Business Level Book flight Book hotel User Level Find flight Reserve seat Find hotel Reserve room Subfunction Level
12 Błędy w use case ach Opis interfejsu użytkownika (np. klika, zamyka okienko ) Zbyt dużo przypadków użycia niskiego poziomu. Używanie przypadków użycia do opisu niebehawioralnych części systemu (np. formularze) Zbyt długie (prawidłowa długość 3-9 kroków) Nie przedstawia pełnego scenariusza (lub brak alternatywnych ścieżek) Omijanie nazw aktorów w krokach
13 Wzbogacanie use case ów
14 Trening Sprawdzenie poczty Dodanie kontaktu do książki Wysłanie poczty
15 Zadanie Napisać specyfikację wymagań funkcjonalnych w postaci przypadków użycia dla sklepu internetowego 6-10 przypadków użycia Można wzbogacić przypadki użycia o szkice ekranów Sklep powinien mieć koszyk zakupowy, logowanie do systemu Dołącz diagram przypadków użycia UML
16 ISO 9126 wymagania pozafukcjonalne
17 Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Członek PTL Czytanie danych Aktualizacja danych 3.2 Zarząd PTL Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std
18 Wprowadzenie do ISO 9126 ISO 9126: Software Engineering Product Quality Part 1: Quality Model Part 2: External Metrics Part 3: Internal Metrics Part 4: Quality-in-use Metrics
19 Jakość w cyklu życia Proces rozwoju Jakość procesu Atrybuty jakości wewn. Produkt programistyczny Atrybuty jakości zewn. Wpływa Wpływa Wpływa Efekt użycia produktu Atrybuty jakości użytkow.
20 Jakość w cyklu życia Atrybuty jakości wewn. Produkt programistyczny Wpływa Atrybuty jakości zewn. Wpływa Efekt użycia produktu Atrybuty jakości użytkow.
21 Jakość wewnętrzna i zewnętrzna External and Internal Quality Characteristics Functionality Reliability Usability Efficiency Maintainability Portability
22 Jakość wewnętrzna i zewnętrzna External and Internal Quality Characteristics Funkcjonalność Niezawodność Użyteczność Wydajność Łatwość utrzymania Przenośność
23 Przypadki użycia Dziękuje za uwagę
Jerzy Nawrocki, Inżynieria oprogramowania II
Jerzy Nawrocki, Wymagania funkcjonalne Cel wykładu Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl Jak specyfikować wymagania funkcjonalne za pomocą przypadków użycia? Wymagania funkcjonalne (2) Wymaganie
Wprowadzenie do jakości systemów informatycznych
Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania Wprowadzenie do jakości systemów informatycznych http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc J.Kuchta@eti.pg.gda.pl
Inżynieria oprogramowania. Przypadki użycia. Piotr Miklosik piotr.miklosik@put.poznan.pl. Mirosław Ochodek Miroslaw.Ochodek@cs.put.poznan.
Inżynieria oprogramowania Przypadki użycia Piotr Miklosik piotr.miklosik@put.poznan.pl Mirosław Ochodek Miroslaw.Ochodek@cs.put.poznan.pl Znaczenie wymagań Standish Group, CHAOS Report 1994 Problem % porażek
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
DIAGRAM 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
Ję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)
SPECYFIKACJE 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
Inż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ś
XPrince dla architektów 1
Wprowadzenie do Laboratorium Inżynierii Oprogramowania Instytut Informatyki Politechnika Poznańska Jerzy Nawrocki Jerzy.Nawrocki@put.poznan.pl www.xprince.net Specjalność Software Engineering Konsorcjum
Modelowanie 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
Modelowanie 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.
Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008
Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd
Diagramy 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
Wprowadzenie do przedmiotu 1
Inżynieria wymagań Plan wykładu Inżynieria wymagań i IEEE 80 Jerzy.Nawrocki@put.poznan.pl Adam.Wojciechowski@put.poznan.pl Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI
Testowanie oprogramowania
Testowanie oprogramowania 1/30 Testowanie oprogramowania Testowanie niefunkcjonalne dr inż. Grzegorz Michalski 27 października 2015 Testowanie oprogramowania 2/30 Norma ISO ISO 9126 Norma dotycząca zagadnień
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Inż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
Cel 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
Projekt 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
UPEDU: Rozpoznanie wymagań (ang. requirements discipline)
Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 5: UPEDU: Rozpoznanie wymagań (ang. requirements discipline) Na podstawie podręcznika:
JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?
K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.
Inżynieria oprogramowania I
Kontakt Inżynieria I Andrzej Jaszkiewicz Andrzej Jaszkiewicz p. 424y, Piotrowo 3a tel. 66 52 371 jaszkiewicz@cs.put.poznan.pl www-idss.cs.put.poznan.pl/~jaszkiewicz Literatura A. Jaszkiewicz, Inżynieria,
Spis 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...
Inż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
Tom 6 Opis oprogramowania
Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa
Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych
Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Jak teoria pomaga w codziennej praktyce zapewniania i kontroli jakości Piotr Ślęzak Stowarzyszenie Jakości Systemów Informatycznych
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:
Overlord - specyfikacja uzupełniająca. Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej
Overlord - specyfikacja uzupełniająca Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 25 kwietnia 2006 Spis treści 1 Historia zmian 3 2 Wprowadzenie 3 3 Funkcjonalność 3 3.1 Log.........................................
Specyfikowanie 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
dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska
, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 [ISO 9000] Jakość jest określana jako ogół cech i właściwości wyrobu lub usługi wymaganych do zaspokojenia stwierdzonych lub przewidywanych
Opis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Okreś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
Inżynieria oprogramowania
Inżynieria oprogramowania Definicja IEEE: inżynieria oprogramowania jest to zastosowanie - systematycznego, - zdyscyplinowanego, - ilościowego podejścia do - rozwoju, - eksploatacji - utrzymania oprogramowania.
Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.
Inżynieria I Andrzej Jaszkiewicz Kontakt Andrzej Jaszkiewicz p. 8, CW Berdychowo tel. 66 52 933 ajaszkiewicz@cs.put.poznan.pl Rynek 2008 Świat 304 miliardy $ (451 miliardów 2013F) Bez wytwarzanego na własne
Pozyskiwanie i dokumentowanie wymagań
Pozyskiwanie i dokumentowanie wymagań Koncepcja wykładu: Jerzy Nawrocki/Łukasz Olek Slajdy/Lektor/Montaż: Łukasz Olek Witam Państwa serdecznie na kolejnym wykładzie z cyklu zaawansowana inżynieria oprogramowania.
Zasady 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
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków
PRZEWODNIK 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
Inżynieria oprogramowania
Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania część I dr inż. Bartłomiej Prędki$ Bartlomiej.Predki@cs.put.poznan.pl$ Pok. 124 CW, tel. 61665 2932$ http://zajecia.predki.com
Wykł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
Inżynieria oprogramowania
Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania część I dr inż. Bartłomiej Prędki Bartlomiej.Predki@cs.put.poznan.pl Pok. 124 CW, tel. 61665 2932 http://zajecia.predki.com
Nazwa 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:
Jerzy Nawrocki, Inżynieria oprogramowania II
Jerzy Nawrocki, Jerzy Nawrocki Instytut Informatyki Politechnika Poznańska Etap przedprojektowy Etap przedprojektowy (2) Piąta zasada zwinności Cykl życia wg XPrince Osoby i interakcje O K Działające oprogr.
INŻ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
1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Wymagania pozafunkcjonalne
Wymagania pozafunkcjonalne Opracowanie: dr inż. M. Ochodek? Plan wykładu Wymagania pozafunkcjonalne ISO 25010:2011 Jakość użycia produktu Jakość produktu Wymagania pozafunkcjonalne Wymagania pozafunkcjonalne,
Konfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 2013
Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 203 Unified Process Rama organizacji procesu wytwarzania oprogramowania. Posiada wyodrębionie fazy inicjowania, projektowania,
Projektowanie 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
Proces Inżynierii Wymagań
Proces Inżynierii Wymagań michał możdżonek 02.2008 Literatura 1. Sommerville I. (2003): Inżynieria oprogramowania, WNT, Warszawa 2. Leffingwell D., Widrig D. (2003): Zarządzanie wymaganiami, WNT, Warszawa
<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
Projektowanie interakcji
Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director
Instrukcja aktywacji aplikacji Mobile Biznes
Instrukcja aktywacji aplikacji Mobile Biznes Typ dokumentu: instrukcja/manual Wersja: 1.1 MOBILE BIZNES Mobile Biznes to aplikacja stworzona z myślą o Klientach firmowych i korporacyjnych. Już dziś zyskaj
Modelowanie 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.
ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH
ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH Streszczenie Andrzej Kobyliński Katedra Informatyki Gospodarczej Szkoła Główna Handlowa w Warszawie andrzej.kobylinski@sgh.waw.pl W minionym ćwierćwieczu
Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl
Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
WPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
IO - 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
Inżynieria oprogramowania
Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania część I dr inż. Bartł omiej Prę dki Bartlomiej.Predki@cs.put.poznan.pl Pok. 124 CW, tel. 61665 2932 http://zajecia.predki.com
Zagadnienia (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
Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect
Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Karolina Zmitrowicz Zarządzanie wymaganiami w projekcie może być trudne i czasochłonne, może być chaotyczne jeśli brak odpowiedniego
Modelowanie 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:
Projektowanie systemów informatycznych
Projektowanie systemów informatycznych Zarządzanie projektem Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski Cel wykładu Przedstawienie inżynierii wymagań jako istotnego i
Diagramy 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
Projektowanie 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
Procesowa 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
Komputerowe 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
Inżynieria oprogramowania (Software Engineering) Wykład 1
Inżynieria oprogramowania (Software Engineering) Wykład 1 Wprowadzenie do inżynierii oprogramowania Zarządzanie przedmiotem Wydział: WEiI Katedra: KIK Web site: http://moskit.weii.tu.koszalin.pl/~swalover/
Specyfikacja 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)
MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI
Inżynieria Rolnicza 7(105)/2008 MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI Agnieszka Buczaj Zakład Fizycznych Szkodliwości Zawodowych, Instytut Medycyny Wsi w Lublinie Halina Pawlak Katedra
FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne:
FAZA STRATEGICZNA Faza strategiczna jest wykonywana zanim podejmowana jest decyzja o realizacji przedsięwzięcia. Jej zadaniem jest określenie celów tworzonego systemu oraz wymagań odnośnie szczegółów jego
Analiza i częściowa implementacja systemu elektronicznej wymiany danych na przykładzie e-faktury
systemu elektronicznej wymiany danych na przykładzie e-faktury Pod kierownictwem mgr inż. Andrzeja Ptasznika systemu elektronicznej wymiany danych CEL PRACY Zbudowanie systemu do wystawiania, ewidencji,
SPECYFIKACJA WYMAGAŃ
SPECYFIKACJA WYMAGAŃ Autorzy: Wersja: 2 Historia zmian dokumentu Osoba
The concept, models and metrics of software quality an overview
Pojęcie, modele i metryki jakości oprogramowania przegląd Yuliia Horobets*, Marek Miłosz Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska JCSI 4 (2017) 92-98 Wysłane:
Tom 6 Opis oprogramowania
Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa pliku Tom 6 Opis oprogramowania, Część 2 Generator danych
KATEDRA 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,
Ćwiczenia 3: Specyfikacja wymagań Pytania:
Ćwiczenia 3: Specyfikacja wymagań Pytania: 1. Przygotuj przypadek użycia opisujący obsługę zamówienia w sklepie internetowym (krok po kroku). Zaczynamy od identyfikatora przypadku użycia (powiedzmy UC1),
Diagramy 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
Inżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
Prowadzenie rachunków bankowych, obsługa Kart oraz korzystanie z Elektronicznych Kanałów Dostępu osoby małoletnie
Prowadzenie rachunków bankowych, obsługa Kart oraz korzystanie z Elektronicznych Kanałów Dostępu osoby małoletnie Rozdział 1 Rachunki oszczędnościowo-rozliczeniowe konto Junior plan taryfowy * ) warunkiem
Cele 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
Model jakości McCalla
Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania Model jakości McCalla http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc J.Kuchta@eti.pg.gda.pl Czynniki jakości
Jarosław Kuchta. Projektowanie Aplikacji Internetowych. Wprowadzenie
Jarosław Kuchta Projektowanie Aplikacji Internetowych Wprowadzenie Zagadnienia Rola projektowania w procesie wytwarzania aplikacji internetowych (podejście klasyczne, podejście zwinne) Modele analityczne
Laboratorium 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
Co 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
Analiza 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.
Zarządzanie inicjatywami i wymaganiami w projektach IT
Zarządzanie inicjatywami i wymaganiami w projektach IT Spotkanie 1 Katarzyna Misiak katarzyna.misiak@gmail.com Czym się będziemy zajmować? Co będzie: 1. Zarządzanie wymaganiami 2. Przegląd oprogramowania
UML cz. I. UML cz. I 1/1
UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę
Ewolucja norm jakości produktu programowego
Andrzej Kobyliński Kolegium Analiz Ekonomicznych Szkoła Główna Handlowa w Warszawie Ewolucja norm jakości produktu programowego 1. Wstęp Kwestia jakości oprogramowania budzi wiele kontrowersji: wprawdzie
Analiza 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.
Studencka Pracownia Inżynierii Oprogramowania Zespół nr 2, IIUWR 2008/09. Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski.
Studencka Pracownia Inżynierii Oprogramowania Zespół nr, IIUWR 00/0 Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski Zium System zarządzania komunikacją miejską Harmonogram Data Wersja Opis Autor
Inż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
Case study - bankomat. Piotr Ciskowski
Case study - bankomat Piotr Ciskowski diagramy UML UML diagram Structure diagram Behavior diagram Class diagram Component diagram Use case diagram Interaction diagram Object diagram Deployment diagram
Artur Wielogórski.
Artur Wielogórski http://github.com/wodor Testowanie w PHP Po co piszemy i uruchamiamy testy? Testowanie w PHP Aby wiedzieć, że : To co implementujemy działa Testowanie w PHP Aby wiedzieć, że : To co implementujemy
MASZ TO JAK W BANKU, CZYLI PO CO NAM KARTY I INNE PRODUKTY BANKOWE.
MASZ TO JAK W BANKU, CZYLI PO CO NAM KARTY I INNE PRODUKTY BANKOWE. Szczecin, maj 2018 Tatiana Mazurkiewicz BANK KOMERCYJNY Instytucja finansowa: o gromadzi środki pieniężne gromadzi depozyty klientów
slajd 1 Model przypadków użycia Anna Bobkowska
slajd 1 Model przypadków użycia Anna Bobkowska Materia ły pomocnicze do wy kładu z Inżynierii Opr ogramowania na Wy dziale E TI PG. Ich lektura nie zastępuje obecności na wykładzie. Wykorzystanie materiałów
PŁATNOŚCI W STANDARDZIE BLIK WSTĘPNA ANALIZA CUSTOMER EXPERIENCE
PŁATNOŚCI W STANDARDZIE BLIK WSTĘPNA ANALIZA CUSTOMER EXPERIENCE Prezentacja z Konferencji Nowości płatnicze, czyli co nas czeka wkrótce Warszawa, czerwiec 2015 przyjaznyserwis.pl 1 Wstęp Na potrzeby konferencji