1 / 48

Inżynieria wymagań

Inżynieria oprogramowania II Wykład 6. Inżynieria wymagań. Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/io. Plan wykładu. Wymagania Model Sommerville’a-Sawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro. Kontrola jakości Szacowanie rozmiaru i

tamekah-hardin
Download Presentation

Inżynieria wymagań

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

  3. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

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

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

  6. SRS IEEE Std 830-1998 • 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ń

  7. Główne problemy IEEE Std 830-1998 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 implementacji, ograniczenia zasobowe, środowisko funkcjonowania itp.) J.Nawrocki, Inżynieria wymagań

  8. Specyfikacja wymagań • Wymagania funkcjonalne • Wymagania pozafunkcjonalne • Interfejs użytkownika • Scenariusze testów akceptacyjnych  IEEE Std. 830 J.Nawrocki, Inżynieria wymagań

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

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

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

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

  13. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

  14. Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 36 21 9 8 - - 6 6 1 5 2 1 4 1 - 3 3 - 4 3 1 4 3 2 2 3 4 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ń

  15. Punktacja 3 0 • 3 – standaryzacja: udokumentowany standard stosowany i sprawdzany jakoczęść 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; J.Nawrocki, Inżynieria wymagań

  16. 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ń

  17. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

  18. Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 36 21 9 8 - - 6 6 1 5 2 1 4 1 - 3 3 - 4 3 1 4 3 2 2 3 4 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ń

  19. 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ń

  20. Kryteria jakości dokumentu SRS IEEE Std 830-1998 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ń

  21. Struktura SRS IEEE Std 830-1998 • 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ń

  22. Struktura SRS IEEE Std 830-1998 • 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ń

  23. Struktura SRS IEEE Std 830-1998 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ń

  24. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

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

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

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

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

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

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

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

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

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

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

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

  36. 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ń

  37. Źle napisany przypadek użycia Zapisz się na przedmiot (Główny scen.) • Wyświetl pusty plan zajęć. • 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ęć. • Wykonaj. • Student klika na przedmiot. • Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. • Student klika na godziny a potem na przycisk „Dodaj przedmiot” . J.Nawrocki, Inżynieria wymagań

  38. Źle napisany przypadek użycia Za dużo szczegółów dot. GUI • Wyświetl pusty plan zajęć. • 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ęć. • Wykonaj. • Student klika na przedmiot. • Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. • Student klika na godziny a potem na przycisk „Dodaj przedmiot” . J.Nawrocki, Inżynieria wymagań

  39. 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ń

  40. Plan wykładu • Wymagania • Model Sommerville’a-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 J.Nawrocki, Inżynieria wymagań

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

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

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

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

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

  46. 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ń

  47. Podsumowanie Wreszcie! • Wymagania • Model Sommerville’a-Sawyera • Praktyki dotyczące dokumentu • Przypadki użycia • Rational Requisite Pro J.Nawrocki, Inżynieria wymagań

  48. 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ń

More Related