Inynieria oprogramowania II Wykad 6 Inynieria wymaga Jerzy

Inżynieria oprogramowania II Wykład 6 Inżynieria wymagań Jerzy. Nawrocki@put. poznan. pl www. cs. put.

Plan wykładu • Kontrola jakości • Szacowanie rozmiaru i • Standardy serii ISO 9000

Wymaganie. . jest to zdolność (capability) lub warunek, który system musi spełnić. J. Nawrocki,

Wymagania. . są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma

SRS IEEE Std 8301998 SRS = Software Requirements Specification SRS jest specyfikacją szczególnego (particular)

Główne problemy IEEE Std 8301998 Funkcjonalność (co oprogramowanie ma robić? ) Zewnętrzne interfejsy (ludzie,

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

Środowisko operacyjne ENV 1 ENV 2 Urządzenie Użytkownik J. Nawrocki, Inżynieria wymagań System zewnętrzny

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

Funkcje systemu Dokładność? Nie do nas! Funkcja (Operacja) Wej. Wyj. STO P 0. 1234

Funkcje systemu FUN 1: Pobranie faktury WEJŚCIE: WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura

Klasyfikacja dobrych praktyk Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie

Punktacja 3 0 3 – standaryzacja: udokumentowany standard stosowany i sprawdzany jako część procesu

Poziomy dojrzałości Zdefiniowany > 85 Podst & > 40 Pośr. & Zaaw. Powtarzalny >

Dokument wymagań Zdefiniuj standardową strukturę dokumentu Wyjaśnij, jak korzystać z dokumentu Dołącz streszczenie wymagań

Kryteria jakości dokumentu SRS IEEE Std 8301998 a) Poprawność; b) Jednoznaczność; c) Kompletność; d)

Struktura SRS 1. Wprowadzenie 1. 1 Cel dokumentu 1. 2 Zakres produktu 1. 3

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 2. 1 Kontekst funkcjonowania 2. 2

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3. 1 Opis

Ivar Jacobson 1967: Ericsson, systemy telekomunikacyjne 1985: Ph. D. , Dep. of Computer Systems,

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

Przykładowy przypadek użycia Zarejestruj IO Aktor: Aktor Rejestrator IO Cel: Cel Zarejestrować w systemie

Przypadki użycia a scenariusze Ten sam cel Scenario #1 Scenario #2 Scenario #3 J.

Zalety przypadków użycia • Są półformalne. Wprowadzają strukturę do opowieści. • Opisują także sytuacje

Źle napisany przypadek użycia Zapisz się na przedmiot (Główny scen. ) 1. Wyświetl pusty

Źle napisany przypadek użycia Za dużo szczegółów dot. GUI 1. Wyświetl pusty plan zajęć.

Inne często popełniane błędy Za dużo niskopoziomowych przypadków użycia („Authorize user”). Stosowanie przypadków użycia

Użytkownicy Requisite. Pro Autor Requisite. Pro Obserwator J. Nawrocki, Inżynieria wymagań Admin

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

Składniki Requisite. Pro Palet a Widok i MS Wor d Requisite. W eb Baza

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

Rational Suite Analyst. Studio Rational Requisite. Pro Zarządzanie wymaganiami Rational Clear. Case LT Zarządzanie

Literatura IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830 -1998, June 1998.

Podsumowanie • Wymagania • Model Sommerville’a. Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia

Ocena wykładu 1. Wrażenie ogólne (1 - 6) 2. Za szybko czy za wolno?

Slides: 48

Download presentation

Plan wykładu • 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 • Wymagania • Model Sommerville’a. Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro J. Nawrocki, Inżynieria wymagań

Plan wykładu • 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 • Wymagania • Model Sommerville’a-Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro J. Nawrocki, Inżynieria wymagań

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

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

SRS IEEE Std 8301998 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. J. Nawrocki, Inżynieria wymagań

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

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

Środowisko operacyjne ENV 1 ENV 2 Urządzenie Użytkownik J. Nawrocki, Inżynieria wymagań System zewnętrzny

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

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

Funkcje systemu FUN 1: 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. 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 J. Nawrocki, Inżynieria wymagań Podst. Pośre Zaaw 36 21 9 d. . 8 6 5 4 3 6 2 1 3 1 1 - 4 4 2 3 3 3 1 2 4

Punktacja 3 0 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 J. Nawrocki, Inżynieria wymagań

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

Plan wykładu • 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 • Wymagania • Model Sommerville’a-Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro 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 J. Nawrocki, Inżynieria wymagań

Kryteria jakości dokumentu SRS IEEE Std 8301998 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). 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 J. Nawrocki, Inżynieria wymagań IEEE Std 8301998

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 J. Nawrocki, Inżynieria wymagań IEEE Std 8301998

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 J. Nawrocki, Inżynieria wymagań IEEE Std 8301998

Plan wykładu • 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 • Wymagania • Model Sommerville’a-Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro 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 http: //www. analisi-disegno. com/uml/Jacobson. Interview. html 2003: IBM kupuje Rationala http: //www. jaczone. com/ J. Nawrocki, Inżynieria wymagań

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

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: IO Wprowadza NIP lub REGON IO. 2. System: System Sprawdza poprawność wprowadzonego NIP/REGON. 3. Rejestrator: Rejestrator Wprowadza pozostałe dane identyfikacyjne IO. 4. System: System Weryfikuje poprawność składniową wprowadzonych danych. 5. Rejestrator: Rejestrator Wprowadza dane dotyczące jednostek IO. 6. Rozszerzenia J. Nawrocki, Inżynieria wymagań

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

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. 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. J. Nawrocki, Inżynieria wymagań

Źle napisany przypadek użycia Za dużo szczegółów dot. GUI 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. 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). J. Nawrocki, Inżynieria wymagań

Plan wykładu • 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 • Wymagania • Model Sommerville’a-Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro J. Nawrocki, Inżynieria wymagań

Użytkownicy Requisite. Pro Autor Requisite. Pro Obserwator J. Nawrocki, Inżynieria wymagań Admin

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

Składniki Requisite. Pro Palet a Widok i MS Wor d Requisite. W eb Baza danych J. Nawrocki, Inżynieria wymagań

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

Rational Suite Analyst. Studio Rational Requisite. Pro Zarządzanie wymaganiami Rational Clear. Case LT Zarządzanie wersjami Rational Clear. Quest Zarządzanie zmianami Rational Rose So. DA Generowanie raportów 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. J. Nawrocki, Inżynieria wymagań

Podsumowanie • Wymagania • Model Sommerville’a. Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro 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ć? J. Nawrocki, Inżynieria wymagań