Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Copyright © Jerzy R. Nawrocki Inżynieria wymagań i IEEE 830 Inżynieria oprogramowania II.

Podobne prezentacje


Prezentacja na temat: "Copyright © Jerzy R. Nawrocki Inżynieria wymagań i IEEE 830 Inżynieria oprogramowania II."— Zapis prezentacji:

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

2 J.Nawrocki, Inżynieria wymagań i IEEE 830 Plan wykładu Kontrola jakości oprogramowania Szacowanie rozmiaru i pracochłonności Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań i IEEE 830 Zarządzanie projektami i PRINCE 2 Personal Software Process Team Software Process Zwinne metodyki programowania Rational Unified Process Projekty dyplomowe 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

3 J.Nawrocki, Inżynieria wymagań i IEEE 830 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ń i IEEE 830 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ń i IEEE 830 Literatura IEEE Recommended Practice for Software Requirements Specifications, IEEE Std , June I.Sommerville, P. Sawyer, Requirements Engineering. A Good Practice Guide. John Wiley & Sons, Chichester, 1997.

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

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

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

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

10 J.Nawrocki, Inżynieria wymagań i IEEE 830 Główne problemy FunkcjonalnośćZewnętrzne interfejsy Funkcjonalność + Zewnętrzne interfejsy Ograniczenia projektoweWydajność Ograniczenia projektowe + WydajnośćAtrybuty IEEE Std

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

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

13 J.Nawrocki, Inżynieria wymagań i IEEE 830 Środowisko operacyjne Użytkownik System

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

15 J.Nawrocki, Inżynieria wymagań i IEEE 830 Funkcje systemu FUN1: Pobranie faktury WEJŚCIE: - WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF-1/ ) 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.

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

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

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

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

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

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

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

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

24 J.Nawrocki, Inżynieria wymagań i IEEE 830 Struktura SRS 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements Appendixes Index IEEE Std

25 J.Nawrocki, Inżynieria wymagań i IEEE Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements User class Functional requirement n Functional requirement 1.n m User class m 3.2.m.1 Functional requirement m m.n Functional requirement m.n IEEE Std

26 J.Nawrocki, Inżynieria wymagań i IEEE Specific requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements IEEE Std

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

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

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

30 J.Nawrocki, Inżynieria wymagań i IEEE 830 Źle napisany przypadek użycia 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the Add Course button. Zapisz się na przedmiot (Główny scen.)

31 J.Nawrocki, Inżynieria wymagań i IEEE 830 Źle napisany przypadek użycia 7. Check if the Student has the necessary prerequisites and that the course offering is open. 8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message You are missing the prerequisites. Choose another course. 9. Mark the course offering as enrolled in the schedule. 10. End do when the Student clicks on Save Schedule. 11. Save the schedule and return to the main selection screen. Zapisz się na przedmiot (Główny scen. – kont.)

32 J.Nawrocki, Inżynieria wymagań i IEEE 830 Źle napisany przypadek użycia 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the Add Course button. Za dużo szczegółów dot. GUI

33 J.Nawrocki, Inżynieria wymagań i IEEE 830 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).

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

35 J.Nawrocki, Inżynieria wymagań i IEEE 830 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)

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

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

38 J.Nawrocki, Inżynieria wymagań i IEEE 830 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?

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

40 J.Nawrocki, Inżynieria wymagań i IEEE 830 Użytkownicy RequisitePro RequisitePro Autor Obserwator Admin

41 J.Nawrocki, Inżynieria wymagań i IEEE 830 Wymaganie W RequisitePro: Nazwa, tekst, atrybuty Rational RequisitePro

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

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

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

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

46 J.Nawrocki, Inżynieria wymagań i IEEE 830 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ć?

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


Pobierz ppt "Copyright © Jerzy R. Nawrocki Inżynieria wymagań i IEEE 830 Inżynieria oprogramowania II."

Podobne prezentacje


Reklamy Google