Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "Inżynieria oprogramowania Specyfikacja wymagań Autor: Łukasz Olek."— Zapis prezentacji:

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

2 Inżynieria oprogramowania Specyfikacja wymagań (2) Plan wykładów Zasady skutecznego działania Specyfikacja wymagań Kontrola jakości artefakt ó w Język UML, cz. I 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 Plan wykładów

3 Inżynieria oprogramowania Specyfikacja wymagań (3) Wprowadzenie

4 Inżynieria oprogramowania Specyfikacja wymagań (4) Wprowadzenie

5 Inżynieria oprogramowania Specyfikacja wymagań (5) Wprowadzenie

6 Inżynieria oprogramowania Specyfikacja wymagań (6) Wprowadzenie

7 Inżynieria oprogramowania Specyfikacja wymagań (7) Wprowadzenie

8 Inżynieria oprogramowania Specyfikacja wymagań (8) Wprowadzenie

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

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

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

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

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

14 Inżynieria oprogramowania Specyfikacja wymagań (14) 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?

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

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

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

18 Inżynieria oprogramowania Specyfikacja wymagań (18) 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

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

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

21 Inżynieria oprogramowania Specyfikacja wymagań (21) Wymagania pozafunkcjonalne F unctionality - funkcjonalność U sability - użyteczność R eliability - niezawodność P erformance - wydajność S ecurity - bezpieczeństwo

22

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

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

25 Inżynieria oprogramowania Specyfikacja wymagań (25) 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)

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

27 Inżynieria oprogramowania Specyfikacja wymagań (27) Przypadki użycia Zalety: –łatwość spisywania –czytelność –łatwość zrozumienia i wyobrażenia sobie przyszłego systemu UC1: 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ę.

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

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

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

31 Inżynieria oprogramowania Specyfikacja wymagań (31) Przypadek użycia Forma ustrukturalizowana –Nazwa –Identyfikator –Główny scenariusz UC1: 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ę.

32 Inżynieria oprogramowania Specyfikacja wymagań (32) Przypadek użycia Forma ustrukturalizowana –Nazwa –Identyfikator –Główny scenariusz –Rozszerzenia UC1: 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ę. Rozszerzenia: 3.A. Sprzedawca nie dodał żadnej pozycji 3.A.1. System prosi o ponowne wprowadzenie pozycji (powrót do 2.)

33 Inżynieria oprogramowania Specyfikacja wymagań (33) Przypadek użycia Forma ustrukturalizowana –Nazwa –Identyfikator –Główny scenariusz –Rozszerzenia –Atrybuty UC1: 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: …

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

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

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

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

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

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

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

41 Inżynieria oprogramowania Specyfikacja wymagań (41) 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ę

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

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

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

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

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

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

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

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

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

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

52 Inżynieria oprogramowania Specyfikacja wymagań (52) 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

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

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

55 Inżynieria oprogramowania Specyfikacja wymagań (55) 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

56 Inżynieria oprogramowania Specyfikacja wymagań (56) 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

57 Inżynieria oprogramowania Specyfikacja wymagań (57) Często popełniane błędy UC1: 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.)

58 Inżynieria oprogramowania Specyfikacja wymagań (58) Często popełniane błędy UC1: 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.)

59

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

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

62 Inżynieria oprogramowania Specyfikacja wymagań (62) Dobre praktyki: Sommerville & Sawyer Obszar Podst. 36 Pośred. 21 Zaaw. 9 Dokument wymagań8-- Zbieranie wymagań661 Analiza i negocjacja wym.521 Opisywanie wymagań41- Modelowanie systemu33- Walidacja wymagań431 Zarządzanie wymaganiami432 IW dla systemów krytycznych234

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

64 Inżynieria oprogramowania Specyfikacja wymagań (64) 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.

65 Inżynieria oprogramowania Specyfikacja wymagań (65) 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ę

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

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

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

69 Inżynieria oprogramowania Specyfikacja wymagań (69) 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ń

70

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

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


Pobierz ppt "Inżynieria oprogramowania Specyfikacja wymagań Autor: Łukasz Olek."

Podobne prezentacje


Reklamy Google