Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Procesy Inżynierii Wymagań l Procesy służące do zidentyfikowania, przeanalizowania.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Procesy Inżynierii Wymagań l Procesy służące do zidentyfikowania, przeanalizowania."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Procesy Inżynierii Wymagań l Procesy służące do zidentyfikowania, przeanalizowania i zatwierdzenia wymagań systemowych

2 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 2 Cele l Rozumienie podstawowych czynności inżynierii wymagań l Poznanie metod określania i analizowania wymagań l Rozumienie znaczenia zatwierdzania wymagań l Rozumienie roli zarządzania wymaganiami oraz tego, jak wspomaga ono inne czynności inżynierii wymagań

3 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3 Zawartość l Studium wykonalności l Określenie i analizowanie wymagań l Zatwierdzanie wymagań l Zarządzanie wymaganiami

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 4 Procesy inżynierii wymagań l Procesu używane w IW różnią się mocno w zależności od dziedziny, w której działamy i odludzi zaangażowanych w działanie organizacji i budowę systemu. l Mimo to istnieje kilka czynności wspólnych dla wszystkich sytuacji Wydobywanie wymagań Analiza wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 5 Proces inżynierii wymagań Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Specyfikowanie wymagań Raport o wykonalności Model systemu Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 6 Studium wykonalności l Studium wykonalności decyduje czy warto wykonać system l Krótkie opracowanie, odpowiadające na pytania Czy system przyczyni się do realizacji celów organizacji Czy system może być stworzony przy użyciu dostępnych technologii w ramach określonego budżetu i ograniczeń czasowych czy system może być zintegrowany z istniejącymi systemami

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7 Przeprowadzenie studium wykonalności l Określenie i zebranie informacji a następnie napisanie raportu l Pytania, które powinny być zadane Co się stanie jeśli system nie powstanie? Jakie problemy aktualnie występują? Jak system pomoże w ich rozwiązaniu? Jakie będą problemy z integracją? Jakie nowe technologie są potrzebne? Jaki umiejętności? Jakie udogodnienia musi wspierać system a jakich nie?

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8 Wydobywanie i analiza l Czasem nazywana odkrywaniem wymagań l Angażuje technicznych budowniczych, którzy pracując z klientami wydobywają od nich wiedzę o dziedzinie, informacje o usługach, które system powinien udostępniać i ograniczenia dla działania systemu l Może angażować użytkowników końcowych, inżynierów klienta, ekspertów z dziedziny, i innych. Nazywamy ich uczestnikami

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 9 Problemy z analizą wymagań l Uczestnicy nie wiedzą czego naprawdę oczekują l Uczestnicy wyrażają wymagania w hermetycznym języku l Różni uczestnicy mają sprzeczne wymagania l Czynniki organizacyjne i polityczne wpływają na wymagania systemowe l Wymagania zmieniają się w czasie trwania procesu analizy. Pojawiają się nowi uczestnicy a otoczenie biznesowe się zmienia

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10 Proces analizy wymagań Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań Specyfikacja wymagań Dokumentacja wymagań Początek procesu

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11 Czynności procesu l Rozpoznanie dziedziny l Zebranie wymagań l Klasyfikacja l Usuwanie sprzeczności l Nadawanie priorytetów l Sprawdzanie wymagań

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12 Modele systemu l Różne modele mogą powstawać podczas różnych czynności analizy wymagań l Analiza wymagań może angażować trzy czynności systematyzujące, które prowadzą do trzech różnych modeli Dzielenie. Odnajduje strukturalne (część czegoś) związki pomiędzy encjami. Abstrakcja. Odnajduje generalizacje pomiędzy encjami Projekcja. Identyfikuje różne spojrzenia na ten sam problem l O modelach systemu opowiem za tydzień

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13 Określanie oparte na punktach widzenia l Uczestnicy miewają różne punkty widzenia na ten sam problem l Analiza z wielu perspektyw jest ważna, ponieważ nie istnieje jedynie słuszna metoda na analizowanie wymagań

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14 System obsługi bankomatu l Przykład opisuje bankomat, który może dostarczać wielu usług l Upraszczamy system mówiąc, że bankomat jest własnością banku i klientom tego banku oferuje pełną gamę usług, a klientom innych banków usługi w ograniczonym zakresie l Usługi zawierają: wypłatę pieniędzy, wysłanie wiadomości do banku, wydruk stanu konta i przelew pieniędzy

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15 Punkty widzenia dla bankomatu l Klienci banku l Przedstawiciele innych banków l Inżynierowie pielęgnacji sprzętu i oprogramowania l Dział marketingu banku l Dyrektorzy oddziałów banku l Administratorzy baz danych i dział bezpieczeństwa l Inżynierowie komunikacji l Pracownicy obsługi klienta w oddziałach

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 16 Typy punktów widzenia l Źródło lub przeznaczenie danych Punkt widzenia odpowiedzialny za produkowanie lub użytkowanie danych. Analiza polega na rozpoznaniu wszystkich takich punktów widzenia i sprawdzeniu czy założenia dotyczące danych są poprawne l Zrąb reprezentacji Osoba związana z konkretnym typem modelu systemu. Odpowiednie dla systemów czasu rzeczywistego. l Odbiorca usług Punkty widzenia są zewnętrzne wobec systemu.

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 17 Zewnętrzne punkty widzenia l Naturalny sposób myślenia o końcowych użytkownikach systemu l Punkty widzenia w naturalny sposób porządkują wymagania l Łatwo stwierdzić czy coś jest punktem widzenia czy nie l Punkty widzenia i usługi stanowią dobry sposób na uporządkowanie wymagań niefunkcjonalnych

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18 Analiza oparta na metodach l Szeroko stosowane podejście do analizy wymagań. Zależnie od zastosowanej metody uzyskamy inny stopień zrozumienia systemu l Metody koncentrują się na różnych celach. Niektóre są przeznaczone do wydobywania wymagań, inne są bliskie projektowaniu l Jako przykład przedstawię opartą na punktach widzenia metodę VORD

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 19 Metoda VORD Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowanie punktów widzenia do systemu

20 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20 Model procesu VORD l Identyfikacja punktów widzenia Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu i usług dla tych reprezentantów l Strukturalizacja punktów widzenia Grupowanie podobnych punktów widzenia w hierarchię. Wspólne usługi są umieszczone wyżej l Dokumentowanie punktów widzenia Udoskonalanie opisów punktów widzenia i usług l Przyporządkowywanie punktów widzenia Przekształcanie punktów widzenia w projekt obiektowy

21 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 21 Szablony formularzy VORD Szablon do punktu widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariuszy opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usług Podrzędne: Nazwy podrzędnych punktów 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ć zapisane za pomocą różnych notacji Punkty widzenia: Lista nazw punktów widzenia, których reprezentacji korzystają z usługi Wymagania niefunkcjonalne: Odnośnik do zbioru wymagań niefunkcjonalnych ograniczających usługę Dostawca: Lista obiektów systemu oferujących tę usługę

22 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 22 Identyfikacja punktów widzenia Pytanie o saldo Odczyt transakcji Zasoby maszyny Zdalna diagnostyka Wypłata gotówki Zdalna aktualizacja oprogramowania Zamówienie czeków Przelew środków Zamówienie wyciągu Przekazywanie komunikatów Baza danych klientów Menedżer Właściciel konta Obcy klient Pielęgnacja oprogramowania Kasa banku Informacje o koncie Interfejs użytkownika Koszt systemu Karta skradziona Niezawodność Aktualizacja konta Dziennik komunikatów Zwrot karty Rozmiar oprogramowania Drukarka Zabezpieczenia Dziennik transakcji Nieuprawniony użytkownik Zatrzymanie karty Weryfikacja karty

23 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 23 Informacje o usługach Właściciel kontaObcy klientKasa banku Lista usług Wypłata gotówki Diagnostyka Pytanie o saldo Dodanie gotówki Zamówienie czekówDodanie papieru Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków

24 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 24 Dane wejściowe i sterujące WŁAŚCICIEL KONTA Dane sterująceDane wejściowe Rozpocznij transakcję Informacje z karty Anuluj transakcjęPIN Zakończ transakcj꯹dana kwota Wybór usługiKomunikat

25 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 25 Hierarchia punktów widzenia Wszystkie PW Personel bankuKlient Właściciel konta Klient obcy KasaInżynierMenedżer Usługi Pytanie o saldo Wypłata gotówki Usługi Zamówienie czeków Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków

26 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 26 Wzory: klient/wypłata 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: Właściciel konta, Klient Obcy Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby papierowych dokumentów 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 Punkty widzenia: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później

27 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27 Scenariusze l Scenariusze są przykładami, jak system jest używany w praktyce l Są przydatne podczas wydobywania wymagań, ponieważ ludzie rozumieją je dużo lepiej niż abstrakcyjne opisy tego, co oczekują od systemu l Scenariusze są szczególnie przydatne w dodawaniu szczegółów do ogólnych opisów

28 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28 Opis scenariusza l Stan systemu przed rozpoczęciem scenariusza l Normalny przebieg zdarzeń scenariusza l Co może pójść źle i jak to jest obsługiwane l Inne zdarzenia, które mogą dziać się w tym samym czasie l Stan systemu po zakończeniu scenariusza

29 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29 Scenariusze zdarzeń l Scenariusze zdarzeń mogą być używane do opisu jak system odpowiada na jakieś konkretne zdarzenie np. początek transakcji l VORD zawiera graficzne konwencje do przedstawiania scenariuszy zdarzeń. Dane odbierane i przekazywane Informacja sterująca Obsługa wyjątków Następne zdarzenia

30 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 30 Scenariusz zdarzenia – zacznij transakcję Karta PIN Poproś o PIN Przekroczenie limitu czasu Zwróć kartę Karta skradziona Zatrzymaj kartę Karta nieważna Zwróć kartę Wsunięto kartę Zły PIN Wprowadź ponownie PIN Zły PIN Zwróć kartę Sprawdź użytkownika Numer konta PIN Karta ważna Wybierz usługę Użytkownik OK Numer konta

31 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31 Konwencje dla scenariuszy zdarzeń l Elipsy to dane przekazywane z i do reprezentantów punktów widzenia l Informacja sterująca wychodzi z góry prostokąta l Dane wychodzą z boku prostokąta l Wyjątki są pokazywane na dole prostokątów l Następne zdarzenie w cieniowanym prostokącie

32 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32 Opis wyjątków l Większość metod nie posiada udogodnień do opisu wyjątków l W tym przykładzie wyjątkami są Przekroczenie limitu czasu. Klientowi nie udało się wprowadzić kodu PIN w wyznaczonym czasie Karta nieważna. Nie udało się rozpoznać karty Karta skradziona. Karta została zgłoszona jako skradziona

33 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 33 Przypadki użycia l Przypadki użycia są używaną w UML-u techniką opartą na scenariuszach i definiują aktorów biorących udział w interakcji, co opisuje samą interakcję l Zbiór przypadków użycia powinien opisywać wszystkie interakcje w systemie l Diagramy przebiegów mogą służyć do dodawania szczegółowej informacji do przypadków użycia

34 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 34 Przypadek użycia - wypożyczenie Obsługa wypożyczania

35 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 35 Przypadki użycia biblioteki Czytelnik Obsługa wypożyczania Dostawa Zarządzanie użytkownikami Obsługa katalogu Personel biblioteki

36 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 36 Zarządzanie katalogiem Sprzedawca książek Nabądź Składnik: Składnik biblioteki Książki: Katalog Katalogujący: Personel biblioteki Nowy Kataloguj składnik Usuń składnik z katalogu Usuń

37 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37 Czynniki organizacyjne i społeczne l Systemy komputerowe istnieją w otoczeniu organizacyjnym i społecznym. To może wpływać lub wręcz zdominować wymagania systemowe l Czynniki organizacyjne i społeczne oddziałują nie na jeden, ale na wszystkie punkty widzenia l Analityk powinien wyczuwać takie czynniki, ale na razie nie istnieje systematyczna metoda ich opisu

38 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 38 Przykład l Zastanówmy się nad systemem, który powinien pozwalać wyższej kadrze zarządzającej na dostęp do informacji z pominięciem średniej kadry Status menedżerów. Menedżerowie mogą myśleć, że są zbyt ważni,,by używać klawiatury. To może ograniczać interfejs Zadania menedżerów. Menedżerowie mogą nie mieć wystarczająco dużo czasu, żeby nauczyć się obsługiwać system Opór organizacyjny. Średni menedżerowie mogą celowo podawać mylące lub niekompletne informacje, aby nie okazało się, że ich znaczenie w firmie maleje

39 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 39 Etnografia l Socjologowie spędzają dużo czasu obserwując jak ludzie rzeczywiście pracują l Ludzie nie muszą wyjaśniać jak pracują l Mogą być zaobserwowane czynniki społeczne i organizacyjne l Studia etnograficzne zazwyczaj pokazują, że organizacja pracy jest bardziej skomplikowana niż modele systemu

40 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40 Szczegółowa etnografia l Powstała podczas informatyzacji systemu kontroli lotów l Łączy etnografię i prototypowanie l Tworzenie prototypów prowadzi do powstania pytań na które odpowiada etnografia l Problemem etnografii jest to, że obserwuje ona istniejące działania, które mogą mieć podstawy historyczne nie istotne w chwili obecnej

41 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 41 Etnografia i prototypowanie Analiza etnograficzna Narady Szczegółowa etnografia Ocena prototypu Ogólne tworzenie systemu Prototypowanie systemu

42 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 42 Zakres etnografii l Wymagania opisują jak ludzie pracują, zamiast definiować jak ludzie powinni pracować l Wymagania są wydobywane z zakresu pracy i obowiązków pracujących ludzi

43 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 43 Zatwierdzanie wymagań l Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik l Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać Poprawianie błędów w wymaganiach może kosztować sto razy więcej niż poprawianie błędów w implementacji

44 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 44 Sprawdzenia wymagań l Ważność. Czy system rzeczywiście dostarcza funkcji, które najlepiej spełniają potrzeby użytkownika? l Spójność. Czy wymagania nie są sprzeczne? l Kompletność. Czy są wszystkie wymagania? l Realność. Czy można zaimplementować wszystkie wymagania? l Weryfikowalność. Czy można je zweryfikować?

45 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 45 Techniki zatwierdzania wymagań l Przeglądy wymagań Systematyczne analizy wymagań l Prototypowanie Przedstawianie klientom działającego modelu systemu l Generowanie testów Tworzenie testów dla sprawdzenia czy wymagania są weryfikowalne l Automatyczne sprawdzanie niesprzeczności Sprawdzanie niesprzeczności wymagań wyrażonych w strukturalnej lub formalnej notacji

46 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 46 Przeglądy wymagań l Powinny odbywać się regularnie dopóki formułowane są nowe wymagania l Powinny być wykonywane przez zespół składający się z pracowników obu stron l Mogą być formalne (udokumentowane) lub nieformalne. Dobra komunikacja między twórcami, klientami i użytkownikami daje dobre efekty i pozwala na identyfikację problemów we wczesnych fazach

47 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 47 Lista sprawdzeń dla wymagania l Weryfikowalność. Czy wymaganie można praktycznie sprawdzić? l Zrozumiałość. Czy wymaganie jest zrozumiałe? l Pochodzenie. Czy wiadomo skąd pochodzi wymaganie? l Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe.

48 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 48 Automatyczne sprawdzanie niesprzeczności Wymagania w języku formalnym Kompilator Baza danych wymagań Raporty o sprzecznych wymaganiach Generator raportów

49 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 49 Zarządzanie wymaganiami l Zarządzanie wymaganiami to proces zarządzania zmianami wymagań podczas zbierania wymagań i tworzenia systemu l Wymagania są praktycznie zawsze niekompletne i sprzeczne Nowe wymagania pojawiają się podczas trwania przedsięwzięcia ze względu na zmiany w otoczeniu i lepsze zrozumienie systemu Różne punkty widzenia mają różne i często sprzeczne wymagania

50 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 50 Zmiany wymagań l Ważność wymagań zależy od punktu widzenia l Klienci systemu mogą wyrażać wymagania z perspektywy biznesowej co może być sprzeczne z wymaganiami użytkowników końcowych l Otoczenie biznesowe i techniczne zmienia się w trakcie trwania przedsięwzięcia

51 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 51 Ewolucja wymagań Czas Wstępne zrozumienie problemu Wstępne wymagania Zmienione zrozumienie problemu Zmienione wymagania

52 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 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 l Wymagania zmienne to wymagania,,które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkownika

53 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 53 Klasyfikacja wymagań zmiennych l Wymagania środowiskowe Wymagania, które zmieniają się na skutek zmian środowiska l Wymagania pojawiające się Wymagania pojawiające się podczas lepszego zrozumienia powstającego systemu l Wymagania wynikowe Wymagania, które wynikają z wdrożenia systemu komputerowego l Wymagania zgodności Wymagania, które zależą od konkretnych systemów lub procesów wewnątrz firmy

54 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 54 Planowanie zarządzania wymaganiami l Podczas zarządzania wymaganiami musisz zaplanować: Oznakowanie wymagań »Jak wymagania są unikatowo oznakowane Proces zarządzania zmianami »Proces, który następuje po zmianie wymagania Strategia śledzenia pochodzenia »Ilość informacji o zależnościach pomiędzy wymaganiami, która jest utrzymywana Użycie narzędzi CASE »Narzędzie wspierające zarządzanie wymaganiami

55 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 55 Śledzenie l Śledzenie opisuje związki pomiędzy wymaganiami, ich pochodzeniem i projektem systemu l Informacje o pochodzeniu Wiązania pomiędzy uczestnikami i wymaganiami wraz z uzasadnieniem tych wymagań l Informacje o uzależnieniu wymagań Wiązania pomiędzy zależnymi wymaganiami l Informacje o uzależnieniu projektu Wiązania pomiędzy wymaganiami a częściami projektu

56 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 56 Macierz zależności

57 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 57 Narzędzia CASE l Przechowywanie wymagań Wymagania należy gromadzić w zabezpieczonej i administrowalnej składnicy danych l Zarządzanie zmianami Proces zarządzania zmianami to proces przepływu pracy, którego stany mogą być precyzyjnie zdefiniowane przez co można go zautomatyzować l Zarządzanie zależnościami Automatyczne ustalanie zależności pomiędzy wymaganiami a innymi elementami systemu

58 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 58 Zarządzanie zmianami wymagań l Należy stosować do wszystkich postulowanych zmian wymagań l Główne kroki Analiza problemu. Rozpoznanie problemu z wymaganiem i propozycja zmian Analiza zmiany i ocena kosztów. Szacuje efekty wprowadzenia zmiany Implementacja zmiany. Modyfikuje dokumentację wymagań i inne dokumentacje jeśli zachodzi taka potrzeba

59 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 59 Zarządzanie zmianami wymagań Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany Rozpoznany problem Skorygowane wymaganie

60 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 60 Główne tezy l Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie i zarządzanie wymaganiami l Analiza wymagań to proces iteracyjny obejmujący zrozumienie dziedziny, zbieranie wymagań, klasyfikowanie, nadawanie priorytetów, strukturalizację i zatwierdzanie l Systemy mogą mięć różnych użytkowników z różnymi wymaganiami

61 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 61 Główne tezy l czynniki społeczne i organizacyjne mają wpływ na wymagania systemowe l Zatwierdzanie wymagań to proces sprawdzania wymagań pod względem ważności, niesprzeczności, kompletności, realności i zdatności do zatwierdzania l Zmiany gospodarcze prowadzą do zmian wymagań l Zarządzanie wymaganiami obejmuje planowanie i zarządzanie zmianami


Pobierz ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Procesy Inżynierii Wymagań l Procesy służące do zidentyfikowania, przeanalizowania."

Podobne prezentacje


Reklamy Google