Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria wymagań Jarosław Kuchta Dokumentacja i Jakość Oprogramowania.

Podobne prezentacje


Prezentacja na temat: "Inżynieria wymagań Jarosław Kuchta Dokumentacja i Jakość Oprogramowania."— Zapis prezentacji:

1 Inżynieria wymagań Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

2 2/28Inżynieria wymagań Cele inżynierii wymagań Określenie celu biznesowego projektu Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań Identyfikacja wymagań funkcjonalnych funkcjonalnych niefunkcjonalnych niefunkcjonalnych Alokacja wymagań do poszczególnych składników systemu informatycznego Alokacja wymagań do poszczególnych składników systemu informatycznego

3 Dokumentacja i Jakość Oprogramowania 3/28Inżynieria wymagań Składniki systemu informatycznego System informatyczny Baza danych Oprogramowanie Sprzęt Ludzie Procedury Dokumentacja

4 Dokumentacja i Jakość Oprogramowania 4/28Inżynieria wymagań Alokacja wymagań – przykład Rejestracja opinii od klientów Rejestracja opinii od klientów 1. Rozwiązanie pierwsze – pracownik działu reklamacji analizuje opinie przychodzące telefonicznie lub pocztą i wpisuje je do odpowiedniego formularza. Dane są rejestrowane w bazie danych. 2. Rozwiązanie drugie – serwis internetowy udostępnia formularz opinii. Klienci składający reklamacje muszą odpowiednio szczegółowo wypełnić formularz. Dane są rejestrowane w bazie danych. 3. Rozwiązanie trzecie – włącza się automatyczny serwis telefoniczny. System rozpoznawania głosu wyławia kluczowe słowa z wypowiedzi klienta i tworzy skróconą charakterystykę opinii. Dane są rejestrowane w bazie danych wraz z pełnym nagraniem wypowiedzi.

5 Dokumentacja i Jakość Oprogramowania 5/28Inżynieria wymagań Ustalenie osób zainteresowanych użytkownicy końcowi (wymagania funkcjonalne) użytkownicy końcowi (wymagania funkcjonalne) administrator systemu (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) administrator systemu (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) wyższe kierownictwo (cele biznesowe) wyższe kierownictwo (cele biznesowe) kierownik marketingu (cechy marketingowe) kierownik marketingu (cechy marketingowe) kierownik finansowy (koszty) kierownik finansowy (koszty) kierownik ochrony (bezpieczeństwo) kierownik ochrony (bezpieczeństwo)

6 Dokumentacja i Jakość Oprogramowania 6/28Inżynieria wymagań Ustalenie udziałowców Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Z każdą rolą jest związany określony punkt widzenia. Z każdą rolą jest związany określony punkt widzenia. Osoba występująca w danej roli jest udziałowcem projektu. Osoba występująca w danej roli jest udziałowcem projektu. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Punkty widzenia różnych udziałowców są różne. Punkty widzenia różnych udziałowców są różne. Wszystkie punkty widzenia udziałowców są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia udziałowców są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać przeanalizowane. Wszystkie punkty widzenia powinny zostać przeanalizowane. Pojawiające się konflikty powinny zostać rozstrzygnięte. Pojawiające się konflikty powinny zostać rozstrzygnięte.

7 Dokumentacja i Jakość Oprogramowania 7/28Inżynieria wymagań Ustalenie klienta Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klient powinien należeć do udziałowców projektu, w przeciwnym wypadku nie jest zainteresowany wprowadzeniem systemu, stąd szanse powodzenia są minimalne. Klient powinien należeć do udziałowców projektu, w przeciwnym wypadku nie jest zainteresowany wprowadzeniem systemu, stąd szanse powodzenia są minimalne. W organizacji musi być wyznaczona osoba odpowiedzialna reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi udziałowcami, aby zapewnić ich współpracę w fazie formułowania wymagań. W organizacji musi być wyznaczona osoba odpowiedzialna reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi udziałowcami, aby zapewnić ich współpracę w fazie formułowania wymagań. W przypadku klienta szerokiego (produkt przeznaczony dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących udziałowców (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania. W przypadku klienta szerokiego (produkt przeznaczony dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących udziałowców (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania.

8 Dokumentacja i Jakość Oprogramowania 8/28Inżynieria wymagań Proces pozyskiwania wymagań Wydobywanie informacji Wstępna reprezentacja Wstępna analiza Ocena specyfikacji

9 Dokumentacja i Jakość Oprogramowania 9/28Inżynieria wymagań Podstawowy problem – zrozumienie Wiem, że sądzisz, iż rozumiesz to, co myślisz, że ja powiedziałem, ale nie jestem pewien, czy zdajesz sobie sprawę z tego, że to co słyszałeś nie jest tym, co ja myślałem...

10 Dokumentacja i Jakość Oprogramowania 10/28Inżynieria wymagań Wydobywanie informacji Uświadomienie sobie przez udziałowców ich potrzeb. Uświadomienie sobie przez udziałowców ich potrzeb. Sformułowanie potrzeb. Sformułowanie potrzeb. Transformowanie potrzeb na wymagania względem systemu. Transformowanie potrzeb na wymagania względem systemu. Zdobycie informacji potrzebnych do zrozumienia wymagań. Zdobycie informacji potrzebnych do zrozumienia wymagań.

11 Dokumentacja i Jakość Oprogramowania 11/28Inżynieria wymagań Uświadomienie potrzeb Udziałowiec może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami. Udziałowiec może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami. Udziałowiec może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Udziałowiec może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Udziałowiec prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. Udziałowiec prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. W przypadku, gdy udziałowcem jest urządzenie lub system, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji. W przypadku, gdy udziałowcem jest urządzenie lub system, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji.

12 Dokumentacja i Jakość Oprogramowania 12/28Inżynieria wymagań Formułowanie potrzeb Udziałowiec może mieć kłopoty z formułowaniem jasnych wypowiedzi. Udziałowiec może mieć kłopoty z formułowaniem jasnych wypowiedzi. Udziałowiec może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Udziałowiec może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Udziałowiec może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać. Udziałowiec może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać.

13 Dokumentacja i Jakość Oprogramowania 13/28Inżynieria wymagań Transformowanie potrzeb na wymagania systemowe Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Wymagania mogą być funkcjonalne i niefunkcjonalne. Istnieje konieczność klasyfikacji wymagań. Wymagania mogą być funkcjonalne i niefunkcjonalne. Istnieje konieczność klasyfikacji wymagań. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań.

14 Dokumentacja i Jakość Oprogramowania 14/28Inżynieria wymagań Zdobycie informacji potrzebnych do zrozumienia wymagań Informacje mogą być przechowywane w głowach pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi. Informacje mogą być przechowywane w głowach pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi. Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być niekompletne. Informacje mogą być niekompletne. Informacje mogą być sprzeczne. Informacje mogą być sprzeczne. Informacje mogą być mylące. Informacje mogą być mylące.

15 Dokumentacja i Jakość Oprogramowania 15/28Inżynieria wymagań Wstępna reprezentacja Opis słowny – może mieć niejednoznaczną interpretację, może być niejasny (sformułowany językiem specjalistycznym), duże prawdopodobieństwo nadmiarowości i sprzeczności. Opis słowny – może mieć niejednoznaczną interpretację, może być niejasny (sformułowany językiem specjalistycznym), duże prawdopodobieństwo nadmiarowości i sprzeczności. Opis graficzny – jest bardziej czytelny (notacja musi być znana dla udziałowców, np. diagramy blokowe, czytelne symbole), ułatwia precyzowanie faktów. Opis graficzny – jest bardziej czytelny (notacja musi być znana dla udziałowców, np. diagramy blokowe, czytelne symbole), ułatwia precyzowanie faktów. Opis matematyczny (naukowy, tabelaryczny) – stosuje się jedynie do niektórych wymagań Opis matematyczny (naukowy, tabelaryczny) – stosuje się jedynie do niektórych wymagań Opis kombinowany – problem spójności Opis kombinowany – problem spójności Potrzeba logicznego uszeregowania wymagań – ujawnia luki, nadmiarowości i sprzeczności w wymaganiach. Potrzeba logicznego uszeregowania wymagań – ujawnia luki, nadmiarowości i sprzeczności w wymaganiach. Wymagania różnych udziałowców rejestruje się osobno i następnie tworzy ich kompilację. Wymagania różnych udziałowców rejestruje się osobno i następnie tworzy ich kompilację. Wymagania muszą być ponumerowane, tak aby w późniejszych fazach móc się do nich odwoływać. Wymagania muszą być ponumerowane, tak aby w późniejszych fazach móc się do nich odwoływać.

16 Dokumentacja i Jakość Oprogramowania 16/28Inżynieria wymagań Wstępna analiza Cel – walidacja wymagań przez udziałowców. Cel – walidacja wymagań przez udziałowców. Środek – analiza przez udziałowca wyspecyfikowanych przez siebie i zredagowanych przez analityka wymagań. Środek – analiza przez udziałowca wyspecyfikowanych przez siebie i zredagowanych przez analityka wymagań. Pytania stawiane przez analityka: Pytania stawiane przez analityka: Co takiego? Co takiego? Dlaczego? Dlaczego? Czy istnieją inne możliwości? Czy istnieją inne możliwości?

17 Dokumentacja i Jakość Oprogramowania 17/28Inżynieria wymagań Środki pomocnicze prototypowanie prototypowanie prototypem na etapie specyfikacji może być model systemu (rysunek szkicowy interfejsu użytkownika, wyszczególnienie najważniejszych pozycji menu, szkic najważniejszych raportów) prototypem na etapie specyfikacji może być model systemu (rysunek szkicowy interfejsu użytkownika, wyszczególnienie najważniejszych pozycji menu, szkic najważniejszych raportów) prototypem może być uproszczony program realizujący jedynie wybrane funkcje prototypem może być uproszczony program realizujący jedynie wybrane funkcje podejście ewolucyjno-iteracyjne podejście ewolucyjno-iteracyjne realizacja projektu ze świadomie ograniczoną funkcjonalnością przy założeniu dalszego udoskonalania systemu w przyszłości. realizacja projektu ze świadomie ograniczoną funkcjonalnością przy założeniu dalszego udoskonalania systemu w przyszłości.

18 Dokumentacja i Jakość Oprogramowania 18/28Inżynieria wymagań Rezultaty wymagania poprawnie wyspecyfikowane wymagania niepoprawnie wyspecyfikowane zakres projektu

19 Dokumentacja i Jakość Oprogramowania 19/28Inżynieria wymagań Trzy grupy wymagań Wymagania jawnie wyspecyfikowane (dotyczące konkretnego projektu) Wymagania jawnie wyspecyfikowane (dotyczące konkretnego projektu) Wymagania domyślne – nie wyspecyfikowane jawnie, lecz konieczne dla realizacji celów projektu Wymagania domyślne – nie wyspecyfikowane jawnie, lecz konieczne dla realizacji celów projektu Wymagania obligatoryjne – nie muszą być wyspecyfikowane jawnie, lecz występują ze względu na regulacje prawne lub wymogi rynku. Wymagania obligatoryjne – nie muszą być wyspecyfikowane jawnie, lecz występują ze względu na regulacje prawne lub wymogi rynku.

20 Dokumentacja i Jakość Oprogramowania 20/28Inżynieria wymagań Specyfikacja Wymagań Systemowych 1. Wstęp 2. Opis informacyjny 3. Wymagania funkcjonalne 4. Wymagania niefunkcjonalne 5. Kryteria akceptacyjne 6. Bibliografia 7. Dodatki

21 Dokumentacja i Jakość Oprogramowania 21/28Inżynieria wymagań SWS – Wstęp Identyfikacja systemu Identyfikacja systemu Skrócony opis organizacji Skrócony opis organizacji Cel wprowadzenia systemu (cel biznesowy) Cel wprowadzenia systemu (cel biznesowy) Podstawowe ograniczenia Podstawowe ograniczenia

22 Dokumentacja i Jakość Oprogramowania 22/28Inżynieria wymagań SWS – Opis informacyjny Szczegółowy opis problemów do rozwiązania Szczegółowy opis problemów do rozwiązania Diagramy przepływu (sterowania lub danych) najwyższego poziomu Diagramy przepływu (sterowania lub danych) najwyższego poziomu Reprezentacja zawartości informacyjnej Reprezentacja zawartości informacyjnej Opis interfejsów systemowych (użytkownika, softwerowych, sprzętowych) Opis interfejsów systemowych (użytkownika, softwerowych, sprzętowych)

23 Dokumentacja i Jakość Oprogramowania 23/28Inżynieria wymagań SWS – Wymagania funkcjonalne Lista funkcji (podział hierarchiczny) Lista funkcji (podział hierarchiczny) Opis każdej funkcji Opis każdej funkcji opis tekstowy opis tekstowy ograniczenia ograniczenia wymagania wydajnościowe wymagania wydajnościowe zastrzeżenia projektowe zastrzeżenia projektowe diagramy pomocnicze diagramy pomocnicze Opis sterowania Opis sterowania specyfikacja sterowania specyfikacja sterowania zastrzeżenia projektowe zastrzeżenia projektowe

24 Dokumentacja i Jakość Oprogramowania 24/28Inżynieria wymagań SWS – Wymagania niefunkcjonalne Wymagania wydajnościowe Wymagania wydajnościowe Wymagania niezawodnościowe Wymagania niezawodnościowe Wymagania dot. bezpieczeństwa Wymagania dot. bezpieczeństwa inne inne

25 Dokumentacja i Jakość Oprogramowania 25/28Inżynieria wymagań SWS – Kryteria akceptacyjne Klasy testów Klasy testów Oczekiwane odpowiedzi systemu Oczekiwane odpowiedzi systemu Zastrzeżenia szczególne Zastrzeżenia szczególne

26 Dokumentacja i Jakość Oprogramowania 26/28Inżynieria wymagań SWS – Bibliografia Inne dokumenty inżynierii oprogramowania Inne dokumenty inżynierii oprogramowania Instrukcje techniczne Instrukcje techniczne Literatura pomocnicza Literatura pomocnicza Standardy Standardy

27 Dokumentacja i Jakość Oprogramowania 27/28Inżynieria wymagań SWS – Dodatki Słownik pojęć Słownik pojęć Dane tabelaryczne Dane tabelaryczne Wykresy Wykresy Specyfikacja szczególnych algorytmów Specyfikacja szczególnych algorytmów

28 Dokumentacja i Jakość Oprogramowania 28/28Inżynieria wymagań Literatura Pressman R.S., Software engineering. A practitioners approach, McGraw-Hill, International Edition, 1992 Pressman R.S., Software engineering. A practitioners approach, McGraw-Hill, International Edition, 1992 Górski J. et al., Inżynieria oprogramowania w projekcie informatycznym,wyd. Mikom, Warszawa, 2000 Górski J. et al., Inżynieria oprogramowania w projekcie informatycznym,wyd. Mikom, Warszawa, 2000


Pobierz ppt "Inżynieria wymagań Jarosław Kuchta Dokumentacja i Jakość Oprogramowania."

Podobne prezentacje


Reklamy Google