Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria Oprogramowania 3. Inżynieria wymagań Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl.

Podobne prezentacje


Prezentacja na temat: "Inżynieria Oprogramowania 3. Inżynieria wymagań Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl."— Zapis prezentacji:

1 Inżynieria Oprogramowania 3. Inżynieria wymagań Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl

2 Inżynieria oprogramowania 3. Inżynieria wymagań 2/70 Literatura Ian Sommerville, Inżynieria oprogramowania - rozdział 6

3 Inżynieria oprogramowania 3. Inżynieria wymagań 3/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

4 Inżynieria oprogramowania 3. Inżynieria wymagań 4/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

5 Inżynieria oprogramowania 3. Inżynieria wymagań 5/70 Wymagania... 1/3 W wymaganiach stawianych systemowi oprogramowania ustala się co system powinien robić definiuje się ograniczenia działania i implementacji Wymagania funkcjonalne charakterystyki usług, które system ma oferować albo opisy sposobu przeprowadzania obliczeń Wymagania niefunkcjonalne wymagania produktowe: ograniczają system wymagania procesu: dotyczą procesu tworzenia wymagania zewnętrzne: zwykle są powiązane z pojawiającymi się właściwościami systemu, a zatem stosują się do systemu jako całości

6 Inżynieria oprogramowania 3. Inżynieria wymagań 6/70 Wymagania... 2/3 Wymagania użytkownika przeznaczone dla osób, które mają używać i zaopatrywać się w system język naturalny, tabele i diagramy, zrozumiałe Wymagania systemowe precyzyjne i jednoznaczne można je zapisać w języku strukturalnym; może to być strukturalna postać języka naturalnego, język podobny do języka oprogramowania wysokiego poziomu lub specjalny język do specyfikowania wymagań

7 Inżynieria oprogramowania 3. Inżynieria wymagań 7/70 Wymagania... 3/3 Dokumentacja wymagań jest uzgodnionym zapisem wymagań systemowych należy nadać jej odpowiednią strukturę, aby mogła być używana zarówno przez klientów systemu, jak i twórców oprogramowania

8 Inżynieria oprogramowania 3. Inżynieria wymagań 8/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

9 Inżynieria oprogramowania 3. Inżynieria wymagań 9/70 Proces inżynierii wymagań Wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych Cztery ogólne czynności wysokiego poziomu: studium wykonalności określanie i analizowanie w. specyfikowanie i dokumentowanie w. zatwierdzanie w.

10 Inżynieria oprogramowania 3. Inżynieria wymagań 10/70 Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonalności Model systemu Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań Proces inżynierii wymagań c.d.

11 Inżynieria oprogramowania 3. Inżynieria wymagań 11/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

12 Inżynieria oprogramowania 3. Inżynieria wymagań 12/70 Studium wykonalności Wynik: raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu S.W.: krótkie, skumulowane opracowanie Odpowiedzi: Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

13 Inżynieria oprogramowania 3. Inżynieria wymagań 13/70 Przykładowe pytania w S.W. Jak firma poradziłaby sobie, jeśli system nie byłby zaimplementowany? Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji? Jaki byłby bezpośredni wkład systemu w osiąganie celów gospodarczych? Czy można przekazywać informacje do i z innych systemów przedsiębiorstwa? Czy system wymaga technologii, których wcześniej w firmie nie stosowano? Co system musi wspomagać, a czego nie musi?

14 Inżynieria oprogramowania 3. Inżynieria wymagań 14/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

15 Inżynieria oprogramowania 3. Inżynieria wymagań 15/70 Określanie i analizowanie wymagań Techniczni wykonawcy oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd. W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie Uczestnik: każdy, kto powinien mieć wpływ na wymagania systemowe (pośredni, bezpośredni)

16 Inżynieria oprogramowania 3. Inżynieria wymagań 16/70 Problemy analizy wymagań Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego Uczestnicy w naturalny sposób wyrażają wymagania za pomocą własnych pojęć Różni uczestnicy stawiają różne wymagania (uwaga: oponenci, destruktorzy!) Czynniki polityczne mogą mieć wpływ na system (uwaga: wpływy w firmie!) Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest zmienne (uwaga: polityka firmy, prawo!)

17 Inżynieria oprogramowania 3. Inżynieria wymagań 17/70 Proces ustalania wymagań Początek procesu Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzenie wymagań Specyfikacja wymagań Dokumentacja wymagań

18 Inżynieria oprogramowania 3. Inżynieria wymagań 18/70 Czynności procesu Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań Specyfikacja Dokumentacja

19 Inżynieria oprogramowania 3. Inżynieria wymagań 19/70 Modelowanie systemu Określanie i analizowanie wymagań jest procesem iteracyjnym z ustawicznym przekazywaniem informacji zwrotnej między czynnościami Cykl procesu rozpoczyna się od rozpoznania dziedziny, a kończy na sprawdzeniu wymagań Stopień zrozumienia dziedziny przez analityków rośnie z każdym cyklem Aż wszyscy są zadowoleni

20 Inżynieria oprogramowania 3. Inżynieria wymagań 20/70 Określanie oparte na punktach widzenia Średnie i wielkie systemy mają zwykle kilku różnych użytkowników Wielu uczestników w jakiś sposób interesuje się wymaganiami systemowymi Pomaga odkryć wszystkie funkcje systemu

21 Inżynieria oprogramowania 3. Inżynieria wymagań 21/70 System bankomatowy - przykład Służy do automatycznego dokonywania operacji bankomatowych Wersje: uproszczona: dla wielu zwykłych klientów skomplikowana: dla wybranych klientów Usługi obejmują: wypłatę, wpłatę przekazywanie informacji

22 Inżynieria oprogramowania 3. Inżynieria wymagań 22/70 Uczestnicy systemu bankomatowego Obecni klienci banku Przedstawiciele innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta w oddziałach Administratorzy baz danych Osoby odpowiedzialne za bezpieczeństwo w banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

23 Inżynieria oprogramowania 3. Inżynieria wymagań 23/70 Różne punkty widzenia Źródło lub przeznaczenie danych Osoba mająca taki punkt widzenia użytkuje lub produkuje dane Analiza polega na rozpoznawaniu wszystkich takich punktów widzenia, danych, które są produkowane lub użytkowane, oraz przeprowadzanym przetwarzaniu Zrąb reprezentacji Osoba mająca taki punkt widzenia jest związana z konkretnym typem modelu systemu Odbiorca usług W tym wypadku punkty widzenia są zewnętrzne wobec systemu; osoby mające ten punkt widzenia korzystają z usług systemu.

24 Inżynieria oprogramowania 3. Inżynieria wymagań 24/70 Model zewnętrznych punktów widzenia Reprezentanci tych punktów widzenia współpracują z systemem przez otrzymywanie usług od systemu oraz przekazywanie do systemu danych i sygnałów sterujących Punkty widzenia są zewnętrzne wobec systemu, stanowią zatem naturalny sposób strukturalizacji procesu określania wymagań Dość łatwo jest stwierdzić, czy coś jest punktem widzenia, czy nie reprezentanci punktów widzenia muszą bowiem w pewien sposób oddziaływać na system Punkty widzenia i usługi stanowią dobry sposób strukturalizacji wymagań niefunkcjonalnych każda usługa może być powiązana z wymaganiami niefunkcjonalnymi

25 Inżynieria oprogramowania 3. Inżynieria wymagań 25/70 Etapy metody VORD VORD: Viewpoint-Oriented Requirements Definition Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowywanie punktów widzenia do systemu

26 Inżynieria oprogramowania 3. Inżynieria wymagań 26/70 Etapy metody VORD c.d. Identyfikacja punktów widzenia znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu, oraz wyszukiwanie szczególnych usług oferowanych reprezentantom konkretnych punktów widzenia Strukturalizacja punktów widzenia grupowanie podobnych punktów widzenia w hierarchie Dokumentacja punktów widzenia udoskonalanie opisu znalezionych punktów widzenia i usług Przyporządkowywanie punktów widzenia do systemu znajdowanie obiektów w projekcie obiektowym za pomocą związanej z punktami widzenia informacji o usługach

27 Inżynieria oprogramowania 3. Inżynieria wymagań 27/70 Szablony punktów widzenia i usług Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariu- szy zdarzeń opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usługi Podrzędne Nazwy podrzędnych PW: punktów widzenia Szablon do usług Odnośnik: Nazwa usługi Uzasadnienie: Przyczyna oferowania usługi Specyfikacja: Odnośnik do listy specyfikacji usług, które mogą być opisane za pomocą różnych notacji Punkty Lista nazw punktów widzenia, widzenia: których reprezentanci korzy- stają z usługi Wymagania Odnośnik do zbioru wymagań niefunkcjo- niefunkcjonalnych ogranicza- nalne: jących usługę Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę

28 Inżynieria oprogramowania 3. Inżynieria wymagań 28/70 Burza mózgów w trakcie identyfikacji punktów widzenia Pytanie o saldo Menedżer Odczyt transakcji Zasoby maszyny Interfejs użytkownika Właściciel konta Zdalna diagnostyka Karta skradziona Niezawodność Informacje o koncie Koszt systemu Baza danych klientów Wypłata gotówki Aktualizacja konta Zamówienie wyciągu Obcy klient Dziennik komunikatów Przelew środków Zdalna aktualizacja oprogramowania Zamówienie czeków Zwrot karty Dziennik transakcji Drukarka Rozmiar oprogramowania Zatrzymanie karty Nieuprawniony użytkownik Kasa banku Weryfikacja karty Przekazywanie komunikatów Zabezpieczenia Pielęgnacja oprogramowania Punkt widzenia Usługa Inne

29 Inżynieria oprogramowania 3. Inżynieria wymagań 29/70 Przykład: Usługi przypisane do punktów widzenia WŁAŚCICIEL KONTA OBCY KLIENT KASA BANKU Lista usług Wypłata gotówki Pytania o saldo Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Wypłata gotówki Pytania o saldo Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

30 Inżynieria oprogramowania 3. Inżynieria wymagań 30/70 Dane wejściowe i sterujące związane z punktami widzenia WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcje Informacje z karty Anuluj transakcje PIN Zakończ transakcje Żądana kwota Wybór usługi Komunikat

31 Inżynieria oprogramowania 3. Inżynieria wymagań 31/70 Hierarchia punktów widzenia Usługi InżynierMenedżerKasa Klient obcy Właściciel konta Klient Personel banku Punkty widzenia Pytanie o saldo Wypłata gotówki Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków

32 Inżynieria oprogramowania 3. Inżynieria wymagań 32/70 Opis punktu widzenia klienta i opis usługi wypłaty gotówki Odnośnik: Klient Atrybuty: Numer konta PIN Zdarzenia: Zacznij transakcję Wybór usługi Anuluj transakcję Zakończ transakcję Usługi: Wypłata gotówki Pytanie o saldo Podrzędne PW: Właściciel konta Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby dokumentów papierkowych Specyfikacja: Użytkownicy wybierają tę usługę przez naciśnięcie przycisku wypłata gotówki. Następnie wprowadzają żądaną kwotę. Potwierdza się ją i jeśli na koncie są odpowiednie środki następuje wypłata PW: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później

33 Inżynieria oprogramowania 3. Inżynieria wymagań 33/70 Scenariusze Ludzie zwykle wolą przykłady wzięte z życia niż abstrakcyjne opisy Inżynierowie wymagań mogą skorzystać z informacji zebranych w trakcie dyskusji do formułowania rzeczywistych wymagań systemowych Scenariusze są szczególnie użyteczne przy uszczegóławianiu opisu wymagań Są opisami przykładowych sesji interakcyjnych Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji

34 Inżynieria oprogramowania 3. Inżynieria wymagań 34/70 Cechy scenariusza Opis stanu systemu na początku scenariusza Opis normalnego następstwa zdarzeń scenariusza Opis tego, co może pójść źle, i jak to jest obsługiwane Informacje o innych czynnościach, które można wykonywać w tym samym czasie Opis stanu systemu po zakończeniu scenariusza

35 Inżynieria oprogramowania 3. Inżynieria wymagań 35/70 Scenariusze zdarzeń Scenariusze zdarzeń są używane w VORD (Viewpoint-Oriented Requirements Definition) do dokumentowania zachowania systemu, gdy zajdą konkretne zdarzenia Każde odrębne zdarzenie w interakcji, takie jak wsunięcie karty do bankomatu albo wybranie usługi, może być udokumentowane za pomocą oddzielnego scenariusza zdarzenia Obejmują opis przepływu danych, akcji systemu i wyjątków, które mogą się pojawić Przykład: schemat ze scenariuszem zdarzenia Zacznij transakcję

36 Inżynieria oprogramowania 3. Inżynieria wymagań 36/70 Konwencje dla diagramów scenariuszy zdarzeń Dane odbierane i przekazywane do reprezentantów punktów widzenia: elipsy Informacja sterująca wchodzi w prostokąt od góry, a opuszcza z dołu Dane opuszczają prostokąty z prawej strony Jeśli dane nie są otoczone elipsą, to są to dane wewnętrzne dla systemu Wyjątki są pokazywane na dole prostokątów. Jeśli tych wyjątków jest kilka, to oznacza się je prostokątem Nazwa następnego zdarzenia oczekiwanego po zakończeniu scenariusza: w cieniowanym prostokącie Poproś o PIN Sprawdź użytkownika Wybierz usługę Zły PIN Ponownie wprowadzić Zły PIN Zwróć kartę Czas przekroczony Zwróć kartę Karta nieważna Zwróć kartę Karta skradziona Zatrzymaj kartę Karta PIN Wsunięto kartę Karta ważna Użytkownik OK Numer konta Numer konta PIN

37 Inżynieria oprogramowania 3. Inżynieria wymagań 37/70 Przypadki użycia Przypadek użycia jest metodą opartą na scenariuszach, służącą do określania wymagań Po raz pierwszy użyto jej w metodzie Objectory (Jacobson i inni, 1993). Obecnie stała się podstawowym elementem notacji UML do opisywania obiektowych modeli systemu W najprostszej postaci w przypadku użycia definiuje się aktorów biorących udział w interakcji i wskazuje typ tej interakcji

38 Inżynieria oprogramowania 3. Inżynieria wymagań 38/70 Obsługa wypożyczania Przypadek użycia: Wypożyczanie

39 Inżynieria oprogramowania 3. Inżynieria wymagań 39/70 c Czytelnik Obsługa wypożyczania Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu Przypadki użycia biblioteki

40 Inżynieria oprogramowania 3. Inżynieria wymagań 40/70 Diagramy przebiegu Diagramy przebiegu mogą służyć do dodawania szczegółowej informacji do przypadku użycia Zdefiniowane w UML Przedstawia się aktorów biorących udział w interakcji obiekty w systemie, z którymi komunikują się aktorzy operacje powiązane z tymi obiektami Rysunek: przykład takiego diagramu - interakcja obejmującą nabywanie i katalogowanie książek w bibliotece

41 Inżynieria oprogramowania 3. Inżynieria wymagań 41/70 : Książki: Katalog Sprzedawca książek Składnik: Składnik biblioteki Katalogujący: Personel biblioteki Nowy Usuń Kataloguj składnik Usuń składnik z katalogu Nabądź Diagram przebiegu zarządzania katalogiem

42 Inżynieria oprogramowania 3. Inżynieria wymagań 42/70 Opis przykładu Pokazano dwa obiekty klas Składnik biblioteki i Katalog, które biorą udział w przypadku użycia Zarządzanie katalogiem Akcje są wykonywane w kolejności z góry na dół, a etykietki na strzałkach między aktorami i obiektami są nazwami operacji Po zakupie książki, wykonuje się zatem operację Nowy na katalogu Nabądź i na Składniku. Gdy książka jest już dostępna, na Składniku wykonuje się operację Kataloguj składnik.

43 Inżynieria oprogramowania 3. Inżynieria wymagań 43/70 Etnografia To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych Analityk pogrąża się w środowisku pracy, w którym system będzie używany Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników Zaleta: pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie

44 Inżynieria oprogramowania 3. Inżynieria wymagań 44/70 Skoncentrowana etnografia Rozwinięta w projekcie badającym proces kontroli lotów Łączy etnografię z prototypowaniem Prototypowanie pomaga w pokierowaniu etnografią przez identyfikowanie problemów i pytań, które potem mogą być rozważone przez etnografa Wada etnografii: bada istniejące zachowania, które mogą mieć historyczne podłoże, które nie jest już odpowiednie

45 Inżynieria oprogramowania 3. Inżynieria wymagań 45/70 Etnografia i prototypowanie Analiza etnograficzna Analiza etnograficzna Prototypowanie systemu Prototypowanie systemu Ogólne tworzenie systemu Ogólne tworzenie systemu Narady Szczegółowa etnografia Szczegółowa etnografia Ocena prototypu Ocena prototypu

46 Inżynieria oprogramowania 3. Inżynieria wymagań 46/70 Cele etnografii Opis wymagań wynikających z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego formalne definicje procesów Opis wymagań, które wynikają z kooperacji i świadomości czynności innych osób

47 Inżynieria oprogramowania 3. Inżynieria wymagań 47/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

48 Inżynieria oprogramowania 3. Inżynieria wymagań 48/70 Zatwierdzanie wymagań Zatwierdzanie wymagań polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik Ponieważ błędy w dokumentacji wymagań mogą przyczynić się do poważnych kosztów powtarzania prac po sukcesywnym wykrywaniu tych błędów w trakcie tworzenia lub nawet po rozpoczęciu korzystania z systemu

49 Inżynieria oprogramowania 3. Inżynieria wymagań 49/70 Sprawdzenie wymagań Sprawdzenie ważności. Użytkownik może być przekonany, że system powinien spełniać pewne funkcje. Sprawdzenie niesprzeczności. Wymagania zapisane w dokumentacji nie powinny być sprzeczne. Sprawdzenie kompletności. Dokumentacja wymagań powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika systemu. Sprawdzenie realności. Znając obecną wiedze techniczną, należy sprawdzić, czy wymagania mogą być naprawę zaimplementowane. Możliwość weryfikacji. Aby uniknąć późniejszych sporów między klientem a zleceniobiorcą, wymagania systemowe zawsze powinny być napisane tak, aby można było je weryfikować.

50 Inżynieria oprogramowania 3. Inżynieria wymagań 50/70 Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów Idealnie byłoby, aby wymagania dało się testować. Zautomatyzowane sprawdzanie sprzeczności Jeśli wymagania wyrażono w modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE mogą sprawdzić niesprzeczność systemu. Modele zatwierdzania wymagań

51 Inżynieria oprogramowania 3. Inżynieria wymagań 51/70 Przeglądy wymagań Przegląd wymagań jest ręcznym procesem, w którym wielu czytelników, zarówno ze strony klienta, jak i zleceniobiorcy, sprawdza dokumentację wymagań w poszukiwaniu anomalii i pominięć. Można też zorganizować go w większej skali z wieloma uczestnikami sprawdzającymi różne części dokumentacji. Przeglądy wymagań mogą być formalne albo nieformalne. Przeglądy nieformalne polegają na tym, że zleceniobiorcy rozmawiają o wymaganiach z największą liczbą uczestników, jak to jest możliwe.

52 Inżynieria oprogramowania 3. Inżynieria wymagań 52/70 Sprawdzenie wymagań Możliwość weryfikacji. Czy wymaganie wyrażono tak, aby można je praktycznie sprawdzić? Zrozumiałość. Czy klienci i użytkownicy systemu właściwie zrozumieli wymaganie? Pochodzenie. Czy jawnie zaznaczono źródło, z którego pochodzi wymaganie? Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe?

53 Inżynieria oprogramowania 3. Inżynieria wymagań 53/70 Wymagania zapisane w języku formalnym Baza danych wymagań Raport o błędach w wymaganiach Procesor wymagańAnalizator wymagań Zautomatyzowane sprawdzanie niesprzeczności wymagań

54 Inżynieria oprogramowania 3. Inżynieria wymagań 54/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

55 Inżynieria oprogramowania 3. Inżynieria wymagań 55/70 Zarządzanie wymaganiami Wymagania stawiane wielkim systemom oprogramowania zawsze się zmieniają Jedną z przyczyn takiej sytuacji jest to, że systemy te są zwykle budowane po to, aby rozwiązać problemy złośliwe W trakcie procesu tworzenia oprogramowania stopień zrozumienia problemu stale się zmienia Zmiany te mają zwrotny wpływ na wymagania

56 Inżynieria oprogramowania 3. Inżynieria wymagań 56/70 Wymagania stawiane wielkim systemom Z wielkich systemów korzysta zwykle bardzo urozmaicona społeczność użytkowników. Różni użytkownicy stawiają różne wymagania i przypisuje im inne priorytety i może to prowadzić do zmiany wymagań. Ludzie, którzy płacą za system, i jego użytkownicy to zwykle różni klienci. Klienci systemu formułują wymagania wynikające z ograniczeń organizacyjnych i budżetowych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany muszą być odzwierciedlone w samym systemie.

57 Inżynieria oprogramowania 3. Inżynieria wymagań 57/70 Ewolucja wymagań Wstępne zrozumienie problemu Zmienione rozumienie problemu Wstępne wymagania Zmienione wymagania Czas

58 Inżynieria oprogramowania 3. Inżynieria wymagań 58/70 Wymagania stałe i zmienne Wymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu w szpitalu zawsze będą wymagania dotyczące pacjentów, lekarzy, pielęgniarek, terapii, itp. Wymagania zmienne to wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania np. wymagania, które wynikają z polityki zdrowotnej rządu

59 Inżynieria oprogramowania 3. Inżynieria wymagań 59/70 Klasyfikacja wymagań zmiennych Wymagania zmieniające się Zmieniają się na skutek zmian środowiska, w którym działa firma Wymagania pojawiające się (emerging) Pojawiają się w trakcie procesu tworzenia coraz lepszego rozumienia systemu przez klienta Wymagania wynikowe Wynikają z wdrożenia systemu komputerowego Wymagania zgodności Zależą od umów lub procesów gospodarczych wewnątrz firmy

60 Inżynieria oprogramowania 3. Inżynieria wymagań 60/70 W trakcie tej fazy zarządzania wymaganiami należy podjąć decyzje dotyczące następujących zagadnień: Oznakowanie wymagań Każde wymaganie musi być unikatowo oznakowane tak, aby można było robić do niego odnośniki z innych wymagań i używać tego wymagania przy ocenianiu pochodzenia. Proces zarządzania zmianami Zbiór czynności szacowania wpływu i kosztu zmian. Strategie śledzenia pochodzenia Strategie definiują zależności między wymaganiami i projektem systemu. Użycie narzędzi CASE Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach. Planowanie zarządzania wymaganiami

61 Inżynieria oprogramowania 3. Inżynieria wymagań 61/70 Pochodzenie Możliwość śledzenia pochodzenia jest ogólną cechą specyfikacji wymagań Trzy typy informacji o pochodzeniu, które warto gromadzić Informacje o uczestnikach, którzy zaproponowali dane wymagania, wraz z ich uzasadnieniem Informacje o zależnościach wymagań wiążą wzajemnie zależne wymagania Informacje o uzależnieniu projektu wiążą wymagania z modułami projektu, które implementują te wymagania

62 Inżynieria oprogramowania 3. Inżynieria wymagań 62/70 Macierz zależności: Uzależnione, Relacja Id wymagań UR 1.2URU 1.3RR 2.1RUU 2.2U 2.3RU 3.1R 3.2R

63 Inżynieria oprogramowania 3. Inżynieria wymagań 63/70 Narzędzia CASE w zarządzaniu w. Przechowywania wymagań Wymagania należy gromadzić w zabezpieczonej i administrowanej składnicy danych, która jest dostępna dla wszystkich biorących udział w procesie inżynierii wymagań Zarządzania zmianami Proces zarządzania zmianami jest znacznie prostszy, gdy aktywnie korzysta się ze wspomagania narzędzi Zarządzania zależnościami Wspomaganie narzędzi przy śledzeniu zależności umożliwia wykrywanie powiązanych wymagań

64 Inżynieria oprogramowania 3. Inżynieria wymagań 64/70 Zarządzanie zmianami wymagań Zarządzanie zmianami wymagań należy zastosować do wszystkich postulowanych zmian wymagań. Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany proces rozpoczyna się od rozpoznania problemu z wymaganiem lub od propozycji zmiany Analiza zmiany i ocena kosztów korzystając z informacji o uzależnieniu i ogólnej wiedzy o wymaganiach systemowych ocenia się wpływ proponowanej zmiany Implementacja zmiany modyfikuje się dokumentacje wymagań oraz, jeśli zachodzi taka potrzeba, również projekt i implementację systemu

65 Inżynieria oprogramowania 3. Inżynieria wymagań 65/70 Rozpoznany problem Implementacja zmiany Analiza zmiany i ocena kosztów Analiza problemu i specyfikacja zmiany Skorygowane wymagania Zarządzanie zmianami wymagań

66 Inżynieria oprogramowania 3. Inżynieria wymagań 66/70 Plan Powtórka o wymaganiach Inżynieria wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

67 Inżynieria oprogramowania 3. Inżynieria wymagań 67/70 Podsumowanie 1/4 Proces inżynierii wymagań: studium wykonalności określanie, analizowanie, sprawdzanie, specyfikowanie wymagań zatwierdzanie wymagań zarządzanie wymaganiami Analizowanie wymagań to proces iteracyjny: rozpoznanie dziedziny zbieranie wymagań klasyfikację, strukturalizację nadawanie priorytetów sprawdzanie i zatwierdzanie

68 Inżynieria oprogramowania 3. Inżynieria wymagań 68/70 Podsumowanie 2/4 Różni użytkownicy systemu mogą stawiać różne wymagania. Wszystkie złożone systemy należy więc analizować z kilku punktów widzenia odpowiadają źródłom lub przeznaczeniom danych, różnym reprezentacjom systemu albo bytom spoza systemu, które korzystają z jego usług Pomagają uporządkować strukturę: scenariusze zdarzenia przypadki użycia wymagania

69 Inżynieria oprogramowania 3. Inżynieria wymagań 69/70 Podsumowanie 3/4 Reprezentacje: punkty widzenia i usługi przedstawia się w formularzach scenariusze i przypadki użycia przedstawia się także na diagramach diagram scenariuszy (struktura) diagram przebiegu (czas) wszystko to można zapisać (narysować) w UML Jedną z technik wykrywania scenariuszy, przypadków, a zatem i wymagań jest etnografia

70 Inżynieria oprogramowania 3. Inżynieria wymagań 70/70 Podsumowanie 4/4 Wymaganiami i ich zmianami trzeba zarządzać powiązania wymagań, według pochodzenia i zależności między nimi Czynniki społeczne i organizacyjne mają silny wpływ na wymagania systemowe i od nich głównie zależy, czy system będzie faktycznie używany, czy nie.

71 Inżynieria oprogramowania 3. Inżynieria wymagań 71/70 Dziękuję


Pobierz ppt "Inżynieria Oprogramowania 3. Inżynieria wymagań Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl."

Podobne prezentacje


Reklamy Google