Inynieria oprogramowania Specyfikacja wymaga Autor ukasz Olek Inynieria

Inżynieria oprogramowania Specyfikacja wymagań Autor: Łukasz Olek

Inżynieria oprogramowania Plan wykładów Zasady skutecznego działania Specyfikacja wymagań Kontrola jakości artefaktów Język UML, cz. II Metody formalne Wzorce projektowe Zarządzanie konfiguracją Wprowadzenie do testowania Automatyzacja wykonywania testów Programowanie Ekstremalne Ewolucja oprogramowania i refaktoryzacja Specyfikacja wymagań (2)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (3)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (4)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (5)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (6)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (7)

Inżynieria oprogramowania Wprowadzenie Specyfikacja wymagań (8)

Inżynieria oprogramowania Wprowadzenie = ? Specyfikacja wymagań (9)

Inżynieria oprogramowania Wprowadzenie Kontrakt = Specyfikacja wymagań (10)

Inżynieria oprogramowania Wprowadzenie Kontrakt Specyfikacja wymagań = Specyfikacja wymagań (11)

Inżynieria oprogramowania Wprowadzenie • Wymaganie = opis co system powinien robić źródło: www. wikipedia. org • Specyfikacja = zbiór wymagań • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje Specyfikacja wymagań (12)

Inżynieria oprogramowania Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 1. Słowa nie mają znaczenia! Specyfikacja wymagań (13)

Inżynieria oprogramowania Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 1. Słowa nie mają znaczenia! – Załadunek kompletny? – Raport miesięczny? – SAD? Specyfikacja wymagań (14)

Inżynieria oprogramowania Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 2. Wiedza: – świadoma – nieświadoma Specyfikacja wymagań (15)

Inżynieria oprogramowania Wprowadzenie • Wymagania telefonu Nokia N 80: – duży wyświetlacz – duże, wygodne klawisze – aparat o wysokiej rozdzielczości Specyfikacja wymagań (16)

Inżynieria oprogramowania Wprowadzenie Co oznacza określenie „duże”? • Wymagania telefonu Nokia N 80: – duży wyświetlacz – duże, wygodne klawisze – aparat o wysokiej rozdzielczości Czy klawiatura Co oznacza – Wi. Fi nie może się określenie „wysoka”? znaleźć po drugiej stronie? Specyfikacja wymagań (17)

Inżynieria oprogramowania Jak sobie z tym poradzić? • Spisywanie wymagań to sztuka - nie ma uniwersalnego sposobu • Korzystaj z porad innych: – dobre praktyki – metody, które się sprawdziły Specyfikacja wymagań (18)

Inżynieria oprogramowania Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (19)

Inżynieria oprogramowania Podział wymagań • Funkcjonalne: – Wprowadzanie nowej faktury – Generowanie raportu miesięcznego • Pozafunkcjonalne – minimum 20 faktur na godzinę – 200000 h MTBF – maksimum 2 godziny potrzebne na przeszkolenie 1 pracownika Specyfikacja wymagań (20)

Inżynieria oprogramowania Wymagania pozafunkcjonalne • Functionality - funkcjonalność • Usability - użyteczność • Reliability - niezawodność • Performance - wydajność • Security - bezpieczeństwo Specyfikacja wymagań (21)

Inżynieria oprogramowania Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (23)

Inżynieria oprogramowania Wymagania funkcjonalne • „System powinien…” • Funkcje systemu • Przypadki użycia Specyfikacja wymagań (24)

Inżynieria oprogramowania „System powinien…” • Zalety: – łatwość spisywania • Wady: – słaba czytelność – trudne sprawdzanie kompletności, spójności – System powinien umożliwić wystawianie faktur – System powinien generować zestawienie miesięczne faktur – Faktura powinna zawierać co najmniej jedną pozycję … (tak przez kolejnych 200 stron) Specyfikacja wymagań (25)

Inżynieria oprogramowania Funkcje systemu Funkcja (operacja) Wejście Wyjście • Wady: – słaba czytelność – trudne do zrozumienia Efekty uboczne Specyfikacja wymagań (26)

Inżynieria oprogramowania Przypadki użycia • Zalety: Główny scenariusz: –łatwość 1. Sprzedawca pragnie wystawić spisywania fakturę. –czytelność 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej –łatwość nowy numer i zapisuje w rejestrze zrozumienia 4. Sprzedawca drukuje fakturę. i wyobrażenia sobie przyszłego systemu UC 1: Wystawianie faktury Specyfikacja wymagań (27)

Inżynieria oprogramowania Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (28)

Inżynieria oprogramowania Przypadek użycia • Forma Wystawianie faktury ustrukturalizowana – Nazwa Specyfikacja wymagań (29)

Inżynieria oprogramowania Przypadek użycia • Forma UC 1: Wystawianie faktury ustrukturalizowana – Nazwa – Identyfikator Specyfikacja wymagań (30)

Inżynieria oprogramowania Przypadek użycia • Forma ustrukturalizowana – Nazwa – Identyfikator – Główny scenariusz UC 1: Wystawianie faktury Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze 4. Sprzedawca drukuje fakturę. Specyfikacja wymagań (31)

Inżynieria oprogramowania Przypadek użycia • Forma UC 1: Wystawianie faktury ustrukturalizowana Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. – Nazwa 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy – Identyfikator numer i zapisuje w rejestrze. 4. Sprzedawca drukuje fakturę. – Główny Rozszerzenia: scenariusz 3. A. Sprzedawca nie dodał żadnej pozycji – Rozszerzenia 3. A. 1. System prosi o ponowne wprowadzenie pozycji (powrót do 2. ) Specyfikacja wymagań (32)

Inżynieria oprogramowania Przypadek użycia • Forma ustrukturalizowana – Nazwa – Identyfikator – Główny scenariusz – Rozszerzenia – Atrybuty UC 1: Wystawianie faktury Atrybuty: Główny aktor: Użytkownik Priorytet: Wysoki Źródło: Łukasz Olek Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze. 4. Sprzedawca drukuje fakturę. Rozszerzenia: … Specyfikacja wymagań (33)

Inżynieria oprogramowania Przypadki użycia, a UML • Diagram przypadków użycia: – Nazwy przypadków użycia – Powiązania z aktorami – Dobre jako „mapa” Specyfikacja wymagań (34)

Inżynieria oprogramowania Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (35)

Inżynieria oprogramowania Jak pisać przypadki użycia? • Steve Adolph, Paul Bramble: „Patterns for Effective Use Cases” Specyfikacja wymagań (36)

Inżynieria oprogramowania Jak pisać przypadki użycia? • • Przypadek użycia Zbiór przypadków użycia Proces Zespół Specyfikacja wymagań (37)

Inżynieria oprogramowania Jak pisać przypadki użycia? • • Przypadek użycia Zbiór przypadków użycia Proces Zespół Specyfikacja wymagań (38)

Inżynieria oprogramowania Przypadek użycia • „Fraza czasownikowa w nazwie”: – Wystawianie faktury – Generowanie raportu miesięcznego – Główny przypadek użycia – Przypadek użycia 2 – Zarządzanie Specyfikacja wymagań (39)

Inżynieria oprogramowania Przypadek użycia UC 1: Dodawanie nowej faktury • „Scenariusz i rozszerzenia”: Główny scenariusz: 1. Użytkownik pragnie dodać nową fakturę. 2. Użytkownik wpisuje pozycje faktury. – Nadrzędny cel: czytelność! 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze. – Scenariusz główny - najbardziej 4. Użytkownik drukuje fakturę. Rozszerzenia: prawdopodobna ścieżka 3. A. Użytkownik nie dodał żadnej pozycji 3. A. 1. System prosi o ponowne • 3 -9 kroków wprowadzenie pozycji (powrót do 2. ) – Rozszerzenia - alternatywne scenariusze • kiedy coś pójdzie nie tak • numer rozszerzenia: numer kroku + kolejna litera Specyfikacja wymagań (40)

Inżynieria oprogramowania Przypadek użycia • „Obojętność technologiczna”: – technologia jest zmienna – niepotrzebne ograniczenia – szczegóły GUI zaciemniają obraz – klient nie rozumie terminy technicznych • Przykłady: – Pracownik klika na link kalendarium – System zapisuje dane użytkownika w bazie danych – System za pomocą protokołu SOAP pobiera aktualną temperaturę Specyfikacja wymagań (41)

Inżynieria oprogramowania Jak pisać przypadki użycia? • • Przypadek użycia Zbiór przypadków użycia Proces Zespół Specyfikacja wymagań (42)

Inżynieria oprogramowania Zbiór przypadków użycia • „Rozwijalna historia”: – Hierarchiczne scenariusze – Można rozwijać lub zwijać w celu pokazania lub ukrycia szczegółów Specyfikacja wymagań (43)

Inżynieria oprogramowania Rozwijalna historia • Poziom celu użytkownika: – główny aktor osiąga zamierzony cel w ciągu jednej sesji przy komputerze Specyfikacja wymagań (44)

Inżynieria oprogramowania Rozwijalna historia • Poziom podfunkcji: – przecyzuje wykonanie funkcji Specyfikacja wymagań (45)

Inżynieria oprogramowania Rozwijalna historia • Poziom streszczenia (biznesowy): – kontekst dla wymagań użytkownika Specyfikacja wymagań (46)

Inżynieria oprogramowania Rozwijalna historia Specyfikacja wymagań (47)

Inżynieria oprogramowania Rozwijalna historia Specyfikacja wymagań (48)

Inżynieria oprogramowania Rozwijalna historia Specyfikacja wymagań (49)

Inżynieria oprogramowania Rozwijalna historia Specyfikacja wymagań (50)

Inżynieria oprogramowania Jak pisać przypadki użycia? • • Przypadek użycia Zbiór przypadków użycia Proces Zespół Specyfikacja wymagań (51)

Inżynieria oprogramowania Proces • „Szerokość przed głębokością”: pozyskiwanie wymagań - odkrywczy proces – zmiany na tym etapie - bardzo prawdopodobne – pisanie kompletnych przypadków użycia strata energii – rozwijaj w kolejności: • 1. lista aktorów • 2. nazwy przypadków użycia • 3. główny scenariusz • 4. rozszerzenia Specyfikacja wymagań (52)

Inżynieria oprogramowania Szerokość przed głębokością Lista Aktor-Cel: Firma Rejestracja na szkolenie Pobieranie artykułu Zgłoszenie do udziału w projekcie Konsultant Akceptuje zgłoszenia nowych firm Zarządza artykułami w portalu Przeprowadza ankiety Specyfikacja wymagań (53)

Inżynieria oprogramowania Jak pisać przypadki użycia? • • Przypadek użycia Zbiór przypadków użycia Proces Zespół Specyfikacja wymagań (54)

Inżynieria oprogramowania Zespół • „Mały zespół autorów” – wielkość zespołu to najważniejszy czynnik wpływający na jakość – 2 -3 osoby w zupełności wystarczają – zaangażuj więcej osób w proces recenzji – duże systemy – kilka małych zespołów z jednym architektem odpowiedzialnym za spójną wizję systemu Specyfikacja wymagań (55)

Inżynieria oprogramowania Zespół • „Zrównoważony zespół” – grupa podobnych specjalistów skupi się jedynie na ograniczonych problemach – synergia: kompensuj słabe strony jednych, dobrymi stronami innych – połącz ludzi różnej specjalności – analitycy i użytkownicy Specyfikacja wymagań (56)

Inżynieria oprogramowania Często popełniane błędy UC 1: Faktura Główny scenariusz: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Sprzedawca wpisuje kod dostępu. System weryfikuje użytkownika. Kliknięcie na przycisk wystawiania faktury. System prezentuje formularz. Wpisanie pozycji w dolnym okienku. Wpisanie wartości pozycji , stawki VAT, liczby pozycji i nr. porządkowego. System podlicza fakturę i prezentuje sumę. System nadaje nowy numer i zapisuje w rejestrze faktur. Wydruk faktury. Jeżeli wystawianie faktur zakończyło się, to użytkownik się wylogowuje. Rozszerzenia: 3. A. Sprzedawca nie dodał żadnej pozycji 1. 3. A. 1. System prosi o ponowne wprowadzenie pozycji (powrót do 2. ) Specyfikacja wymagań (57)

Inżynieria oprogramowania Często popełniane błędy UC 1: Faktura Główny scenariusz: 1. Sprzedawca wpisuje kod dostępu. 2. System weryfikuje użytkownika. 3. Kliknięcie na przycisk wystawiania faktury. 4. System prezentuje formularz. 5. Wpisanie pozycji w dolnym okienku. 6. Wpisanie wartości pozycji, stawki VAT, liczby pozycji i nr. porządkowego. 7. System podlicza fakturę i prezentuje sumę. 8. System nadaje nowy numer i zapisuje w rejestrze faktur. 9. Wydruk faktury. 10. Jeżeli wystawianie faktur zakończyło się, to użytkownik się wylogowuje. Rozszerzenia: 3. A. Sprzedawca nie dodał żadnej pozycji 3. A. 1. System prosi o ponowne wprowadzenie pozycji (powrót do 2. ) Specyfikacja wymagań (58)

Inżynieria oprogramowania Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (60)

Inżynieria oprogramowania Dobre praktyki inżynierii wymagań • Yan Sommerville & Pete Sawyer ‘ 97 • Zbiór dobrych praktyk • Model dojrzałości procesów inżynierii wymagań Specyfikacja wymagań (61)

Inżynieria oprogramowania Dobre praktyki: Sommerville & Sawyer Obszar Dokument wymagań Zbieranie wymagań Analiza i negocjacja wym. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych Podst. 36 Pośred. 21 Zaaw. 9 8 6 5 4 3 4 4 2 6 2 1 3 3 1 1 1 2 4 Specyfikacja wymagań (62)

Inżynieria oprogramowania Punktacja 3 - standard w organizacji 2 - powszechnie używane 1 - używane sporadycznie 0 - nigdy Specyfikacja wymagań (63)

Inżynieria oprogramowania Poziomy dojrzałości Zdefiniowany > 85 Podst. & > 40 Pośr. & Zaaw. Powtarzalny > 55 Podst. & < 40 Pośr. & Zaaw. Początkowy < 55 Podst. Specyfikacja wymagań (64)

Inżynieria oprogramowania Dobre praktyki: Dokument wymagań • • Określ standardową strukturę dokumentu Wytłumacz, jak korzystać z dokumentu Dołącz podsumowanie wymagań Zdefiniuj specjalizowane terminy (słownik) • Pomóż czytelnikom znaleźć informację Specyfikacja wymagań (65)

Inżynieria oprogramowania Zbieranie wymagań • Oceń możliwość zbudowania systemu • Zapisuj źródła wymagań • Zdefiniuj środowisko operacyjne Specyfikacja wymagań (66)

Inżynieria oprogramowania Analiza i negocjacja wymagań • Określ granice systemu • Korzystaj z list kontrolnych podczas analizy wymagań • Określ priorytety wymagań Specyfikacja wymagań (67)

Inżynieria oprogramowania Opisywanie wymagań • Zdefiniuj standardowy szablon do opisu wymagań • Korzystaj z prostego i spójnego języka • Dobrze wykorzystuj diagramy Specyfikacja wymagań (68)

Inżynieria oprogramowania Walidacja wymagań • Sprawdź, czy wymagania spełniają standardy • Zorganizuj formalne inspekcje wymagań • Zdefiniuj listy kontrolne walidacji • Wykorzystaj zespoły wielodyscyplinarne do przeglądów wymagań Specyfikacja wymagań (69)

Inżynieria oprogramowania Podsumowanie • Wymagania funkcjonalne: – Przypadki użycia – Jak pisać przypadki użycia? • Wymagania pozafunkcjonalne • Dobre praktyki Sommerville i Sawyer’a Specyfikacja wymagań (71)

Inżynieria oprogramowania Literatura • Y. Sommerville and P. Sawyer. Requirements Engineering. A Good Practice Guide. Wiley & Sons, 1997. • S. Adolph, P. Bramble, A. Cockburn, and A. Pols. Patterns for Effective Use Cases. Addison. Wesley, 2002. • A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2003. Specyfikacja wymagań (72)