Copyright © Jerzy R. Nawrocki Inżynieria wymagań Inżynieria oprogramowania II Wykład 6.

Prezentacja na temat: "Copyright © Jerzy R. Nawrocki Inżynieria wymagań Inżynieria oprogramowania II Wykład 6."— Zapis prezentacji:

1 Copyright © Jerzy R. Nawrocki Inżynieria wymagań Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/io Inżynieria oprogramowania II Wykład 6

2 J.Nawrocki, Inżynieria wymagań Plan wykładów 11.03 Zasady skutecznego działania 18.03 Kontrola jakości oprogramowania 1.04 Szacowanie rozmiaru i pracochłonności 15.04 Standardy serii ISO 9000 29.04 Modele CMMI 29.04 Inżynieria wymagań 6.05 Zarządzanie projektami i PRINCE2 13.05 Personal Software Process 20.05 Team Software Process 3.06 Rational Unified Process 10.06 Zwinne metodyki programowania 17.06 Projekty dyplomowe i XPrince

3 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

4 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

5 J.Nawrocki, Inżynieria wymagań Wymaganie.... jest to zdolność ( capability ) lub warunek, który system musi spełnić.

6 J.Nawrocki, Inżynieria wymagań Wymagania.... są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane. Sommerville & Sawyer97

7 J.Nawrocki, Inżynieria wymagań SRS SRSSRS SRS = Software Requirements Specification SRS jest specyfikacją szczególnego ( particular ) produktu programistycznego, programu, lub zbioru programów realizującego pewne funkcje w konkretnym ( specific ) środowisku. IEEE Std 830-1998

8 J.Nawrocki, Inżynieria wymagań Główne problemy Funkcjonalność Funkcjonalność (co oprogramowanie ma robić?) Zewnętrzne interfejsy Zewnętrzne interfejsy (ludzie, sprzęt, inne oprogramowanie) Wydajność Wydajność (prędkość, dostępność, czas odpowiedzi itp.) Atrybuty Atrybuty (przenośność, pielęgnowalność, bezpiecz. itp. ) Ograniczenia projektowe Ograniczenia projektowe (standardy, język implementacji, ograniczenia zasobowe, środowisko funkcjonowania itp.) IEEE Std 830-1998

9 J.Nawrocki, Inżynieria wymagań Specyfikacja wymagań Wymagania funkcjonalne Wymagania pozafunkcjonalne Interfejs użytkownika Scenariusze testów akceptacyjnych

10 J.Nawrocki, Inżynieria wymagań Środowisko operacyjne System Użytkownik ENV1 Urządzenie System zewnętrzny ENV2

11 J.Nawrocki, Inżynieria wymagań Środowisko operacyjne Użytkownik System

12 J.Nawrocki, Inżynieria wymagań Funkcje systemu STOP 0.1234 Funkcja (Operacja) Nie do nas! Dokładność? Efekty uboczne Wej. Wyj.

13 J.Nawrocki, Inżynieria wymagań Funkcje systemu FUN1: Pobranie faktury WEJŚCIE: - WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF-1/2001.09) EFEKT UBOCZNY: Pobrana faktura jest usuwana z segregatora. Jeśli jest to jedyna faktura w segregatorze, segregator staje się pusty. PRZETWARZANIE: - DOKŁADNOŚĆ: Cześć ułamkowa każdej kwoty ma dwie cyfry po przecinku.

14 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

15 J.Nawrocki, Inżynieria wymagań Klasyfikacja dobrych praktyk Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych Podst.Pośred.Zaaw. 8 6 5 4 3 4 4 2 36 - 6 2 1 3 3 3 3 21 - 1 1 - - 1 2 4 9

16 J.Nawrocki, Inżynieria wymagań Punktacja 3 – standaryzacja : udokumentowany standard stosowany i sprawdzany jako część procesu zarządzania jakością; 2 – normalne użycie : szeroko stosowane ale nie obowiązkowe; 1 – od czasu do czasu : stosowane wg upodobań kierownika proj.; 0 – nigdy : nigdy lub prawie nigdy; 3 0

17 J.Nawrocki, Inżynieria wymagań Poziomy dojrzałości Zdefiniowany > 85 Podst & > 40 Pośr. & Zaaw. Zdefiniowany > 85 Podst & > 40 Pośr. & Zaaw. Powtarzalny > 55 Podst. & < 40 Pośr. & Zaaw. Powtarzalny > 55 Podst. & < 40 Pośr. & Zaaw. Początkowy < 55 Podst. Początkowy < 55 Podst.

18 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

19 J.Nawrocki, Inżynieria wymagań Klasyfikacja dobrych praktyk Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych Podst.Pośred.Zaaw. 8 6 5 4 3 4 4 2 36 - 6 2 1 3 3 3 3 21 - 1 1 - - 1 2 4 9

20 J.Nawrocki, Inżynieria wymagań Dokument wymagań Zdefiniuj standardową strukturę dokumentu Wyjaśnij, jak korzystać z dokumentu Dołącz streszczenie wymagań Opracuj uzasadnienie biznesowe dla systemu Zdefiniuj terminy specjalistyczne Wybierz czytelny szablon dokumentu Pomóż czytelnikom znaleźć informację Uczyń dokument łatwym do zmiany

21 J.Nawrocki, Inżynieria wymagań Kryteria jakości dokumentu SRS a) Poprawność; b) Jednoznaczność; c) Kompletność; d) Spójność; e) Informacja o ważności i stabilności; f) Weryfikowalność; g) Modyfikowalność; h) Możliwość śledzenia powiązań ( traceability ). IEEE Std 830-1998

22 J.Nawrocki, Inżynieria wymagań Struktura SRS 1. Wprowadzenie 1.1 Cel dokumentu 1.2 Zakres produktu 1.3 Definicje, akronimy i skróty 1.4 Odwołania do literatury 1.5 Omówienie dokumentu 2. Ogólny opis produktu 3. Wymagania funkcjonalne 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std 830-1998

23 J.Nawrocki, Inżynieria wymagań Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 2.1 Kontekst funkcjonowania 2.2 Charakterystyka użytkowników 2.3 Główne funkcje produktu 2.4 Ograniczenia 2.5 Założenia i zależności 3. Wymagania funkcjonalne 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std 830-1998

24 J.Nawrocki, Inżynieria wymagań Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2.1 Członek PTL 3.2.1.1 Czytanie danych 3.2.1.2 Aktualizacja danych 3.2.2 Zarząd PTL 3.2.2.1 Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std 830-1998

25 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

26 J.Nawrocki, Inżynieria wymagań Ivar Jacobson 1967: Ericsson, systemy telekomunikacyjne 1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm 1987: Założyciel Objectory AB 1995: Objectory AB łączy się z Rationalem 2003: IBM kupuje Rationala http://www.analisi-disegno.com/uml/JacobsonInterview.html http://www.jaczone.com/

27 J.Nawrocki, Inżynieria wymagań Ivar Jacobson Addison-Wesley, 1992

28 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

29 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

30 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

31 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

32 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

33 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

34 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

35 J.Nawrocki, Inżynieria wymagań Ten sam cel Przypadki użycia a scenariusze Scenario #1 Scenario #2 Scenario #3 Przypadek użycia

36 J.Nawrocki, Inżynieria wymagań Przykładowy przypadek użycia Zarejestruj IO Aktor Aktor: Rejestrator IO Cel Cel: Zarejestrować w systemie nową IO. Zdarzenie Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz 1.Rejestrator IO 1.Rejestrator IO: Wprowadza NIP lub REGON IO. 2.System 2.System: Sprawdza poprawność wprowadzonego NIP/REGON. 3.Rejestrator 3.Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. 4.System 4.System: Weryfikuje poprawność składniową wprowadzonych danych. 5.Rejestrator 5.Rejestrator: Wprowadza dane dotyczące jednostek IO.Rozszerzenia 2a. 2a. NIP/REGON jest niepoprawny 2a1. 2a1. System wyświetla komunikat i wracamy do kroku 1

37 J.Nawrocki, Inżynieria wymagań Zalety przypadków użycia Są półformalne. Wprowadzają strukturę do opowieści. Opisują także sytuacje błędne. Są podstawą do szacowania pracochłonności, specyfikacji szczegółowych wymagań, projektowania interfejsów i scenariuszy testowych.

38 J.Nawrocki, Inżynieria wymagań Źle napisany przypadek użycia Zapisz się na przedmiot (Główny scen.) 1.Wyświetl pusty plan zajęć. 2.Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć. 3.Wykonaj. 4.Student klika na przedmiot. 5.Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. 6.Student klika na godziny a potem na przycisk Dodaj przedmiot.

39 J.Nawrocki, Inżynieria wymagań 1.Wyświetl pusty plan zajęć. 2.Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć. 3.Wykonaj. 4.Student klika na przedmiot. 5.Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. 6.Student klika na godziny a potem na przycisk Dodaj przedmiot. Źle napisany przypadek użycia Za dużo szczegółów dot. GUI

40 J.Nawrocki, Inżynieria wymagań Inne często popełniane błędy Za dużo niskopoziomowych przypadków użycia (Authorize user). Stosowanie przypadków użycia do prezentacji informacji nie-behawioralnej (np. opis formularzy – do dodatków). Za długie (powinny być krótkie, zazwyczaj 3-9 kroków). Fragmenty zdań (np. pomijanie nazwy aktora w opisie kroków).

41 J.Nawrocki, Inżynieria wymagań Poziomy opisu systemu informatycznego Kodowanie i testowanie Modelowanie biznesowe Specyfikacja wymagań Projektowanie Asembler, C, Java,... Pseudokod, schematy blokowe, UML,... Język polski, przypadki użycia,... UML, BPMN, przypadki użycia,...

42 J.Nawrocki, Inżynieria wymagań Poziomy przypadków użycia Book tripBook hotelBook flight Poziom użytkown. Book trip Poziom celu Book trip Book hotelBook flight Find flight Reserve seat Find hotel Reserve room Poziom podfunkcji

43 J.Nawrocki, Inżynieria wymagań Krótki formatActor Administrator Use Case Set Monitor Parameters Select MonitorDescription Person monitoring and controlling job control systemDescription Allow administrator to specify boundaries and precision of items being monitored Choose something to monitor (e.g. a process or wait queue)

44 J.Nawrocki, Inżynieria wymagań Pełen format Buy Something Primary Actor Primary Actor: Requestor Goal in Context Goal in Context: Requestor buys something through the system, gets it. Does not include paying for it. Scope Scope: Business – The overall purchasing mechanism, electronic adn non-electronic, as seen by the people in the company. Level Level: Summary Stakeholders and Interests Requestor Requestor: Wants what he/she ordered. Company Company: Wants to control spending but allow needed purchases. Vendor Vendor: Wants to get paid for any goods delivered. Precondition Precondition: None

45 J.Nawrocki, Inżynieria wymagań Pełen format Success Guarantees Success Guarantees: Requestor has goods, correct budet ready do be debited. Trigger Trigger: Requestor decides to buy something. Main Success Scenario 1.Requestor 1.Requestor: Initiate a request. 2.Approver 2.Approver: Check money in the budget, check price of goods, complete request for submission. 3.Buyer 3.Buyer: Check contents of storage, find best vendor for goods. 4.Authorizer 4.Authorizer: Validate Approvers signature....Extensions 1a. Requestor does not know vendor or price: leave those parts blank and continue.

46 J.Nawrocki, Inżynieria wymagań Pełen format Priority Priority: Various Response Time Response Time: Various Frequency Frequency: Three times a day Channel to Primary Actor Channel to Primary Actor: Internet browser, mail system, or equivalent Channels to Secondary Actors Channels to Secondary Actors: Fax, phone, car Open Issues Open Issues: When is a canceled request deleted from the system? What authorization is needed to cancel a request?

47 J.Nawrocki, Inżynieria wymagań Plan wykładu Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe

48 J.Nawrocki, Inżynieria wymagań Użytkownicy RequisitePro RequisitePro Autor Obserwator Admin

49 J.Nawrocki, Inżynieria wymagań Wymaganie W RequisitePro: Nazwa, tekst, atrybuty Rational RequisitePro

50 J.Nawrocki, Inżynieria wymagań Składniki RequisitePro Baza danych Paleta Widoki MS Word RequisiteWeb

51 J.Nawrocki, Inżynieria wymagań Macierz atrybutów Znacznik Pełny tekst Krótki tekstAtrybut

52 J.Nawrocki, Inżynieria wymagań Rational Suite Rational RequisitePro Zarządzanie wymaganiami Rational ClearCase LT Zarządzanie wersjami Rational ClearQuest Zarządzanie zmianami Rational Rose SoDA Generowanie raportów AnalystStudio

53 J.Nawrocki, Inżynieria wymagań Literatura IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830- 1998, June 1998. I.Sommerville, P. Sawyer, Requirements Engineering. A Good Practice Guide. John Wiley & Sons, Chichester, 1997.

54 J.Nawrocki, Inżynieria wymagań Podsumowanie Wymagania Model Sommervillea-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro

55 J.Nawrocki, Inżynieria wymagań Ocena wykładu 1. Wrażenie ogólne (1 - 6) 2. Za szybko czy za wolno? 3. Czy dowiedziałeś się czegoś ważnego? 4. Co i jak poprawić?

56 J.Nawrocki, Inżynieria wymagań Plan wykładu Rola analityka Modelowanie biznesowe Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe