Przypadki użycia. Czyli jak opisywać funkcjonalność. Jerzy Nawrocki Mirosław Ochodek

Podobne dokumenty
Jerzy Nawrocki, Inżynieria oprogramowania II

Wprowadzenie do jakości systemów informatycznych

Inżynieria oprogramowania. Przypadki użycia. Piotr Miklosik Mirosław Ochodek

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL

Język UML w modelowaniu systemów informatycznych

SPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE)

Inżynieria oprogramowania II

XPrince dla architektów 1

Modelowanie i analiza systemów informatycznych

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Diagramy przypadków użycia - MS Visio

Wprowadzenie do przedmiotu 1

Testowanie oprogramowania

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Projekt aplikacji internetowej specyfikacja wymagań (cz.1)

UPEDU: Rozpoznanie wymagań (ang. requirements discipline)

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

Inżynieria oprogramowania I

Spis treúci. 1. Wprowadzenie... 13

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Tom 6 Opis oprogramowania

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Technologia programowania

Overlord - specyfikacja uzupełniająca. Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej

Specyfikowanie wymagań przypadki użycia

dr inż. M. Żabińska, Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

Opis metodyki i procesu produkcji oprogramowania

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Inżynieria oprogramowania

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.

Pozyskiwanie i dokumentowanie wymagań

Zasady organizacji projektów informatycznych

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

PRZEWODNIK PO PRZEDMIOCIE

Inżynieria oprogramowania

Wykład 1 Inżynieria Oprogramowania

Inżynieria oprogramowania

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Jerzy Nawrocki, Inżynieria oprogramowania II

INŻYNIERIA OPROGRAMOWANIA. laboratorium

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Wymagania pozafunkcjonalne

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 2013

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

Proces Inżynierii Wymagań

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Projektowanie interakcji

Instrukcja aktywacji aplikacji Mobile Biznes

Modelowanie i analiza systemów informatycznych

ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH

Dobre wdrożenia IT cz. I Business Case.

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

WPROWADZENIE DO UML-a

IO - inżynieria oprogramowania. dr inż. M. Żabińska, zabinska@agh.edu.pl

Inżynieria oprogramowania

Zagadnienia (1/3) Inżynieria Oprogramowania

Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect

Modelowanie i analiza systemów informatycznych Spis treści

Projektowanie systemów informatycznych

Diagramy przypadków użycia

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Procesowa specyfikacja systemów IT

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Inżynieria oprogramowania (Software Engineering) Wykład 1

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne:

Analiza i częściowa implementacja systemu elektronicznej wymiany danych na przykładzie e-faktury

SPECYFIKACJA WYMAGAŃ

The concept, models and metrics of software quality an overview

Tom 6 Opis oprogramowania

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Ćwiczenia 3: Specyfikacja wymagań Pytania:

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Inżynieria oprogramowania

Prowadzenie rachunków bankowych, obsługa Kart oraz korzystanie z Elektronicznych Kanałów Dostępu osoby małoletnie

Cele przedsięwzięcia

Model jakości McCalla

Jarosław Kuchta. Projektowanie Aplikacji Internetowych. Wprowadzenie

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Zarządzanie inicjatywami i wymaganiami w projektach IT

UML cz. I. UML cz. I 1/1

Ewolucja norm jakości produktu programowego

Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia

Studencka Pracownia Inżynierii Oprogramowania Zespół nr 2, IIUWR 2008/09. Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski.

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Case study - bankomat. Piotr Ciskowski

Artur Wielogórski.

MASZ TO JAK W BANKU, CZYLI PO CO NAM KARTY I INNE PRODUKTY BANKOWE.

slajd 1 Model przypadków użycia Anna Bobkowska

PŁATNOŚCI W STANDARDZIE BLIK WSTĘPNA ANALIZA CUSTOMER EXPERIENCE

Transkrypt:

Przypadki użycia Czyli jak opisywać funkcjonalność Jerzy Nawrocki Jerzy.Nawrocki@cs.put.poznan.pl Mirosław Ochodek Miroslaw.Ochodek@cs.put.poznan.pl

Wymagania w kontekście procesu wytwarzania Opis problemu Scenariusze operacyjne Wymagania Projekt & Implementacja

Struktura SRS 1. Introduction 2. Overall description of the product 3. Functional requirements 3.1 Aktor (rola) 3.1.1 Funkcja 1 3.1.2 Funkcja 2 4. Non-functional requirements Appendices Index IEEE Std 830-1998

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 http://www.analisi-disegno.com/uml/jacobsoninterview.html http://www.jaczone.com/

Use Case Diagram w UML Find flight Travel agent Construct itinerary Reserve flight Issue ticket Airline reservation Merchant bank

Przypadek użycia jako zbiór scenariuszy Ten sam cel Scenariusz #1 Scenariusz #2 Use Case Scenariusz #3

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ę

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.

Scenariusze wypłata z bankomatu Nazwa: Wypłata z bankomatu Aktor: Wypłacający, (Bankomat) Scenariusz #3 1. Bankomat informuje o awarii 2.

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.].

Poziomy przypadków Book trip Business Level Book flight Book hotel User Level Find flight Reserve seat Find hotel Reserve room Subfunction Level

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

Wzbogacanie use case ów

Trening Sprawdzenie poczty Dodanie kontaktu do książki Wysłanie poczty

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

ISO 9126 wymagania pozafukcjonalne

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Członek PTL 3.1.1 Czytanie danych 3.1.2 Aktualizacja danych 3.2 Zarząd PTL 3.2.1 Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std 830-1998

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

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.

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.

Jakość wewnętrzna i zewnętrzna External and Internal Quality Characteristics Functionality Reliability Usability Efficiency Maintainability Portability

Jakość wewnętrzna i zewnętrzna External and Internal Quality Characteristics Funkcjonalność Niezawodność Użyteczność Wydajność Łatwość utrzymania Przenośność

Przypadki użycia Dziękuje za uwagę