Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 1 Proces inżynierii wymagań l Służy do określania, analizowania i zatwierdzania wymagań

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 1 Proces inżynierii wymagań l Służy do określania, analizowania i zatwierdzania wymagań"— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 1 Proces inżynierii wymagań l Służy do określania, analizowania i zatwierdzania wymagań stawianych systemowi.

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 2 Cele l Rozumieć podstawowe czynności inżynierii wymagań i związki między nimi. l Znać kilka metod określania i analizowania wymagań. l Rozumieć znaczenie zatwierdzania wymagań oraz to, jak w tym procesie używa się przeglądów wymagań. l Rozumieć, dlaczego zarządzanie wymaganiami jest niezbędne oraz to, jak wspomaga ono inne czynności inżynierii wymagań.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 3

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 4 Zawartość l Studium wykonalności l Określanie i analizowanie wymagań l Zatwierdzanie wymagań l Zarządzanie wymaganiami

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 5 l Obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. l Istnieją cztery ogólne czynności wysokiego poziomu w procesie inżynierii wymagań: studium wykonalności określenie i analizowanie wymagań specyfikowanie i dokumentowanie wymagań zatwierdzanie wymagań Proces inżynierii wymagań

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 6 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.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 7 l Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu. l Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na kilka pytań: 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? Studium wykonalności

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 8 l Obejmuje określenie i zebranie informacji oraz pisanie raportu l Kilka przykładów pytań: 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? Przeprowadzanie studium wykonalności

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 9 Określanie i analizowanie wymagań l Po wstępnych studiach wykonalności następna fazą inżynierii wymagań jest określanie i analizowanie wymagań. l W trakcie tej czynności techniczni budowniczowie 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. l W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie. Pojęcie uczestnik odnosi się do każdego, kto powinien mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe.

10 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 10 Problemy analizy wymagań l Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego. l Uczestnicy systemu w naturalny sposób wyrażają wymagania za pomocą własnych pojęć. l Różni uczestnicy mogą stawiać różne wymagania. l Czynniki polityczne mogą mieć wpływ na system l Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest dynamiczne. Nieuchronnie zmienia się w trakcie procesu analizy.

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 11 Proces określania i analizowania wymagań Początek procesu Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzenie wymagań Specyfikacja wymagań Dokumentacja wymagań

12 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 12 Czynności procesu l Rozpoznanie dziedziny l Zbieranie wymagań l Klasyfikacja l Usuwanie sprzeczności l Nadawanie priorytetów l Sprawdzanie wymagań

13 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 13 Modelowanie systemu l Określanie i analizowanie wymagań jest procesem iteracyjnym z ustawicznym przekazywaniem informacji zwrotnej między czynnościami. l Cykl procesu rozpoczyna się od rozpoznania dziedziny, a kończy na sprawdzeniu wymagań. l Stopień zrozumienia dziedziny przez analityków rośnie z każdym cyklem.

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 14 Określanie oparte na punktach widzenia l Średnie i wielkie systemy maja zwykle kilku różnych użytkowników. l Wielu uczestników w jakiś sposób interesuje się wymaganiami systemowymi.

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 15 System bankomatowy - przykład l Służy do automatycznego dokonywania operacji bankomatowych. l W uproszczonej wersji służy wielu zwykłym klientom i oferuje bardziej skomplikowane usługi wybranym klientom. l Usługi obejmują: wypłatę, wpłatę, przekazywanie informacji.

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 16 Uczestnicy systemu bankomatowego l Obecni klienci banku l Przedstawiciele innych banków l Dyrektorzy oddziałów banków l Pracownicy obsługi klienta w oddziałach l Administratorzy baz danych l Osoby odpowiedzialne za bezpieczeństwo w banku l Dział marketingu banku l Inżynierowie pielęgnacji sprzętu i oprogramowania

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

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 18 Model zewnętrznych punktów widzenia l 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. l Punkty widzenia są zewnętrzne wobec systemu, stanowią zatem naturalny sposób strukturalizacji procesu określania wymagań. l 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. l Punkty widzenia i usługi stanowią dobry sposób strukturalizacji wymagań niefunkcjonalnych. Każda usługa może być powiązana z wymaganiami niefunkcjonalnymi.

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 19 Method-based analysis l Widely used approach to requirements analysis. Depends on the application of a structured method to understand the system. l Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods l A viewpoint-oriented method (VORD) is used as an example here. It also illustrates the use of viewpoints

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 20 Etapy metody VORD Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowywanie punktów widzenia do systemu

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 21 Etapy metody VORD c.d. l Identyfikacja punktów widzenia Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu, oraz na wyszukiwaniu szczególnych usług oferowanych reprezentantom konkretnych punktów widzenia. l Strukturalizacja punktów widzenia Polega na grupowaniu podobnych punktów widzenia w hierarchie. l Dokumentacja punktów widzenia Udoskonalanie opisu znalezionych punktów widzenia i usług. l Przyporządkowywanie punktów widzenia do systemu Znajdowanie obiektów w projekcie obiektowym za pomocą związanej z punktami widzenia informacji o usługach.

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 22 Szablony formularzy i punktów widzenia 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ę

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 23 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

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 24 Informacja o usługach przypisanych 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

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 25 Dane wejściowe i dane 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

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 26 Hierarchia punktów widzenia Usługi InżynierMenedżerKasa Klient obcy Właściciel konta Klient Personel banku Wszystkie PW Pytanie o saldo Wypłata gotówki Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 27 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

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

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 29 l Opis stanu systemu na początku scenariusza. l Opis normalnego następstwa zdarzeń scenariusza. l Opis tego, co może pójść źle, i jak to jest obsługiwane. l Informacje o innych czynnościach, które można wykonywać w tym samym czasie. l Opis stanu systemu po zakończeniu scenariusza. Cechy scenariusza

30 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 30 l Scenariusze zdarzeń są używane w VORD do dokumentowania zachowania systemu, gdy zajdą konkretne zdarzenia. l 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. l Obejmują opis przepływu danych, akcji systemu i wyjątków, które mogą się pojawić. l Aby zapoznać się z przykładem scenariusza zdarzenia rozważmy schemat, na którym przedstawiono scenariusz zdarzenia Zacznij transakcję. Scenariusze zdarzeń

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 31 Konsekwencje dotyczące diagramów scenariuszy zdarzeń l Dane odbierane i przekazywane do reprezentantów punktów widzenia są przedstawione w postaci elips. l Informacja sterująca wchodzi w każdy prostokąt od góry, a opuszcza z dołu.. l Dane opuszczają prostokąty z prawej strony. Jeśli te dane nie są otoczone elipsą, oznacza to, że są wewnętrzne dla systemu. l Wyjątki są pokazywane na dole prostokątów. Jeśli tych wyjątków jest kilka, to oznacza się je prostokątem. l Nazwa następnego zdarzenia oczekiwanego po zakończeniu scenariusza jest przedstawiana w cieniowanym prostokącie.

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 32 Opis wyjątków l Część metody nie zawiera opisu wyjątków l W tym przykładzie: Przekroczenie limitu czasu. Klient może nie wprowadzić PIN przed upływem wyznaczonego czasu. Karta jest zwracana. Karta nieważna. Nie rozpoznano karty. Karta jest zwracana. Karta ukradziona. Rozpoznano kartę jako skradzioną. Karta jest zatrzymywana.

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 33 l Przypadek użycia jest metodą opartą na scenariuszach, służącą do określania wymagań. l 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. l W najprostszej postaci w przypadku użycia definiuje się aktorów biorących udział w interakcji i wskazuje typ tej interakcji. Przypadki użycia

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 34 Obsługa wypożyczania Przypadek użycia Wypożyczanie

35 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 35 c Czytelnik Obsługa wypożyczania Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu Przypadki użycia biblioteki

36 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 36 Diagramy przebiegu l Zdefiniowane w UML diagramy przebiegu mogą służyć do dodawania szczegółowej informacji do przypadku użycia. l Na takich diagramach przedstawia się aktorów biorących udział w interakcji, obiektyw systemie, z którymi komunikują się aktorzy, oraz operacje powiązane z tymi obiektami. l Rysunek zawiera przykład takiego diagramu- interakcję obejmującą nabywanie i katalogowanie książek w bibliotece.

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 37 : 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

38 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 38 Przykłady l Na rysunku pokazano dwa obiekty klas Składnik biblioteki i Katalog, które biorą udział w przypadku użycia Zarządzanie katalogiem. l Akcje są wykonywane w kolejności z góry na dół, a etykietki na strzałkach między aktorami i obiektami są nazwami operacji. l 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.

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

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 40 Skoncentrowana etnografia l Rozwinięta w projekcie badającym proces kontroli lotów. l Łączy etnografię z prototypowaniem. l Prototypowanie pomaga w pokierowaniu etnografią przez identyfikowanie problemów i pytań, które potem mogą być rozważone przez etnografa. l Wadą etnografii jest to, że bada ona istniejące zachowania, które mogą mieć jakieś historyczne podłoże, które nie jest już odpowiednie.

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 41 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

42 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 42 l Opis wymagań wynikających z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego formalne definicje procesów. l Opis wymagań, które wynikają z kooperacji i świadomości czynności innych osób. Cele etnografii

43 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 43 Zatwierdzanie wymagań l Zatwierdzanie wymagań polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik. l 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.

44 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 44 Sprawdzenie wymagań l Sprawdzenie ważności. Użytkownik może być przekonany, że system powinien spełniać pewne funkcje. l Sprawdzenie niesprzeczności. Wymagania zapisane w dokumentacji nie powinny być sprzeczne. l Sprawdzenie kompletności. Dokumentacja wymagań powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika systemu. l Sprawdzenie realności. Znając obecną wiedze techniczną, należy sprawdzić, czy wymagania mogą być naprawę zaimplementowane. l 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ć.

45 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 45 l Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. l Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. l Generowanie testów Idealnie byłoby, aby wymagania dało się testować. l 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ń

46 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 46 Przeglądy wymagań l 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ęć. l Można też zorganizować go w większej skali z wieloma uczestnikami sprawdzającymi różne części dokumentacji. l 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.

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

48 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 48 Wymagania zapisane w języku formalnym Baza danych wymagań Raport o błędach w wymaganiach Procesor wymagańAnalizator wymagań Zautomatyzowane sprawdzanie niesprzeczności wymagań

49 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 49 l 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. l W trakcie procesu tworzenia oprogramowania stopień zrozumienia problemu stale się zmienia, a zmiany te mają zwrotny wpływ na wymagania. Zarządzanie wymaganiami

50 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 50 l 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ń. l 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. l Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany muszą być odzwierciedlone w samym systemie. Wymagania stawiane wielkim systemom

51 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 51 Ewolucja wymagań Wstępne zrozumienie problemu Zmienione rozumienie problemu Wstępne wymagania Zmienione wymagania Czas

52 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 52 Wymagania stałe i zmienne l 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. l Wymagania zmienne to wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania. Takimi wymaganiami są na przykład wymagania, które wynikają z polityki zdrowotnej rządu.

53 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 53 Klasyfikacja wymagań zmiennych l Wymagania zmieniające się Zmieniają się na skutek zmian środowiska, w którym działa firma. l Wymagania pojawiające się Pojawiają się w trakcie procesu tworzenia w miarę coraz lepszego rozumienia systemu przez klienta. l Wymagania wynikowe Wynikają z wdrożenia systemu komputerowego. l Wymagania zgodności Zależą mów lub procesów gospodarczych wewnątrz firmy.

54 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 54 l 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 »Jest to zbiór czynności szacowania wpływu i kosztu zmian. Strategia śledzenia pochodzenia »Te strategie definiują zależności między wymaganiami i projektem systemu, które należy odnotowywać. Użycie narzędzi CASE »Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach. Planowanie zarządzania wymaganiami

55 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 55 l Możliwość śledzenia pochodzenia jest ogólną cechą specyfikacji wymagań l Trzy typy informacji o pochodzeniu, które warto gromadzić Informacje o uczestnikach, którzy zaproponowali dane wymagania, wraz z ich uzasadnieniem.. Informacje o uzależnieniu wymagań wiążą w dokumentacji wymagań te wymagania, które od siebie zależą. Informacje o uzależnieniu projektu wiążą wymagania z modułami projektu, które implementują te wymagania. Pochodzenie

56 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 56 Macierz zależności Id wymagań UR 1.2URU 1.3RR 2.1RUU 2.2U 2.3RU 3.1R 3.2R

57 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 57 l 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ń. l Zarządzania zmianami Proces zarządzania zmianami jest znacznie prostszy, gdy aktywnie korzysta się ze wspomagania narzędzi. l Zarządzania zależnościami Wspomaganie narzędzi przy śledzeniu zależności umożliwia wykrywanie powiązanych wymagań. Korzystanie z narzędzi CASE w zarządzaniu wymaganiami

58 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 58 l Zarządzanie zmianami wymagań należy zastosować do wszystkich postulowanych zmian wymagań. l Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany. Proces rozpoczyna się od rozpoznania problemu z wymaganiem lub czasem od konkretnej 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 implementacje systemu. Zarządzanie zmianami wymagań

59 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 59 Rozpoznany problem Implementacja zmiany Analiza zmiany i ocena kosztów Analiza problemu i specyfikacja zmiany Skorygowane wymagania Zarządzanie zmianami wymagań

60 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 60 Główne tezy l Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie wymagań, zatwierdzanie wymagań oraz zarządzanie wymaganiami. l Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie priorytetów i zatwierdzanie.

61 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 61 Główne tezy l 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. Punkty widzenia odpowiadają źródłom lub przeznaczeniom danych, różnym reprezentacjom systemu albo bytom spoza systemu, które korzystają z jego usług. l 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.


Pobierz ppt "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 1 Proces inżynierii wymagań l Służy do określania, analizowania i zatwierdzania wymagań"

Podobne prezentacje


Reklamy Google