Inynieria oprogramowania II Wykad 7 Inynieria wymaga Jerzy

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

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 PRINCE 2 13. 05 Personal Software Process 20. 05 Team Software Process 3. 06 Rational Unified Process 10. 06 Zwinne J. Nawrocki, Inżynieria wymagańmetodyki programowania

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ń

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ń

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ń

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

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

3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 User class 1 3. 2. 1. 1 Functional requirement 1. 1. . . 3. 2. 1. n Functional requirement 1. n. . . 3. 2. m User class m 3. 2. m. 1 Functional requirement m. 1. . . 3. 2. m. n Functional requirement J. Nawrocki, m. n. Inżynieria wymagań IEEE Std 8301998

3. Specific requirements IEEE Std 8301998 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements 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ń

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/Jacobson. Interview. html 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

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ń

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. 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 wymagań on a course time and then clicks on the J. Nawrocki, Inżynieria

Źle napisany przypadek użycia Za dużo szczegółów dot. GUI 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 wymagań on a course time and then clicks on the J. Nawrocki, Inżynieria

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ń

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

Poziomy przypadków użycia Poziom celu Book trip Book flight Poziom użytkow n. Book hotel Book trip Book flight Reserve seat Find flight J. Nawrocki, Inżynieria wymagań Book hotel Find hotel Reserve room Poziom podfunkcj i

Krótki format Actor Description Administrator Person monitoring and controlling job control Use Case Set Monitor Parameters Select Monitor system Description Allow administrator to specify boundaries and Precision of items being monitored Choose something to monitor (e. g. a process J. Nawrocki, Inżynieria wymagań

Pełen format Buy Something Primary Actor: Actor Requestor Goal in Context: 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: None Precondition J. Nawrocki, Inżynieria wymagań

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

Pełen format Priority: Priority Various Response Time: Time Various Frequency: Frequency Three times a day Channel to Primary Actor: Actor Internet browser, mail system, or equivalent Channels to Secondary Actors: Actors Fax, phone, car Open Issues: Issues When is a canceled request deleted from the system? What authorization is needed to cancel a request? 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ń