Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 3 Zarządzanie wymaganiami (wymagania stawiane oprogramowaniu) Oparty na:

Podobne prezentacje


Prezentacja na temat: "Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 3 Zarządzanie wymaganiami (wymagania stawiane oprogramowaniu) Oparty na:"— Zapis prezentacji:

1 Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 3 Zarządzanie wymaganiami (wymagania stawiane oprogramowaniu) Oparty na: Sommerville I.: Inżynieria Oprogramowania Bobkowska A.: Należyta staranność w inżynierii wymagań i modelowaniu systemów Materiały w Internecie

2

3 Definicja wymagań (1) ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Wymagania to opisy usług, które system ma udostępniać i ograniczeń, które musi spełniać Inżynieria wymagań to proces ustalenia jakich usług użytkownik oczekuje od systemu i ograniczeń, które system musi spełniać zarówno podczas tworzenia, jak i podczas działania

4 Definicja wymagań (2) Wymaganie jest to, wg Dorfmana i Thaylera: możliwość rozwiązania problemu i osiągnięcia celu, wymagana przez użytkownika możliwość spełnienia umowy, normy, specyfikacji lub innej narzuconej dokumentacji, którą musi mieć system lub komponent systemu Zarządzanie wymaganiami jest to: systematyczne podejście do uzyskiwania, organizowania i dokumentowania wymagań systemu oraz proces, który ustala i zachowuje umowę klientem a zespołem realizującym przedsięwzięcie w zależności od zmieniających się wymagań systemu

5 Definicja wymagań (3) Wymaganie (ang. requirement) jest głównym elementem komunikacji pomiędzy klientem zlecającym wykonanie systemu oraz jego wykonawcami. Według organizacji standaryzacyjnej IEEE: wymaganiem nazywa się udokumentowany warunek lub możliwość, którą musi mieć system lub komponent systemu, aby spełnić warunki kontraktu, standardu, specyfikacji lub innego formalnego dokumentu. Przenosząc tą definicję w świat projektów informatycznych wymaganiem można nazwać specyfikację tego, co powinno zostać zaimplementowane w systemie, innymi słowy jest to opis zachowania się systemu lub opis właściwości systemu.

6 Potrzeba istnienia specyfikacji 3 głównych partnerów (stackholders): klient, producent, końcowy użytkownik klient nie rozumie informatyki producent nie rozumie klienta specyfikacja likwiduje lukę w komunikacji między partnerami w specyfikacji opisane są potrzeby klienta i użytkowników, stanowi to podstawę budowy oprogramowania pomaga zrozumieć klientowi ukryte potrzeby

7 Korzyści ze specyfikacji wymagań stanowi podstawę do umowy klient/dostawca, co produkt będzie robił dostarcza punktu odniesienia do kontroli produktu końcowego wysoka jakość specyfikacji jest wstępnym warunkiem oprogramowania o wysokiej jakości specyfikacja dobrej jakości redukuje koszty budowy systemu

8 Dlaczego wymagania są ważne? (1) Przyczyny niepowodzeń projektów (case study) 1. Niekompletne wymagania (13.1%) 2. Brak zaangażowania użytkowników (12.4%) 3. Brak zasobów (10.6%) 4. Nierealistyczne oczekiwania (9.9%) 5. Brak wsparcia zarządu (9.3%) 6. Zmiany wymagań i specyfikacji (8.7%) 7. Brak planowania (8.1%) 8. System przestał być potrzebny (7.5%)

9 Dlaczego wymagania są ważne? (2) Błędy wymagań są najczęstszym typem błędów popełnianych przy tworzeniu systemów, a koszty ich poprawiania należą do największych. Koszt usunięcia błędów w specyfikacji wymagań wyrażony w roboczogodzinach: 2 – w fazie określania i analizy wymagań 5 – w fazie projektowania 15 – w fazie kodowania 50 – w fazie testowania 150 – w fazie serwisowania po wdrożeniu

10 Miejsce wymagań w cyklu życia projektu

11 Kamienie milowe w procesie określenia wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdział 4. Studium wykonalności Analizowanie wymagań Tworzenie prototypu Studium projektowe Specyfikowanie wymagań Raport wykonalności Wymagania użytkownika Raport oceniający Projekt architektoniczny Wymagania systemowe CZYNNOŚCI PRODUKTY

12 Problemy z wymaganiami Problemy z określeniem wizji systemu, jego celu i zakresu; Rozproszona wiedza na temat wymagań - wiele źródeł informacji; Trudności pozyskania wymagań, np. trudność dostępu do przyszłych użytkowników systemu, niechęć użytkowników do współpracy, trudności ze wypowiedzeniem wymagań, Sprzeczne wymagania różnych grup użytkowników; Trudności w precyzyjnym sformułowaniu wymagań, aby można było jednoznacznie zinterpretować; Zmienność wymagań.

13 Klasyfikacja wymagań Wśród wymagań definiujących system informatyczny wyodrębnić można dwie główne grupy: wymagania funkcjonalne, opisujące usługi, jakie oferuje system wymagania niefunkcjonalne, definiujące ograniczenia, przy których system musi realizować swoje funkcje.

14 Klasyfikacja wymagań Ponadto, osoby odpowiedzialne za pozyskiwanie wymagań powinny być również świadome istnienia: wymagań biznesowych, związanych z celem biznesowym, dla którego klient potrzebuje systemu, wymagań użytkownika, opisujących zadania, które użytkownik będzie mógł wykonać przy użyciu systemu.

15 Inżynieria wymagań Cykliczny proces

16 Klasyfikacja wymagań Wymagania biznesowe Wymagania biznesowe opisują główne cele firmy lub klienta odnośnie potrzeby wykorzystania projektowanego systemu. Stanowią one główny powód powołania projektu do życia i pochodzą przede wszystkim od reprezentanta użytkowników końcowych. Opisują cele biznesowe na ogólnym poziomie i praktycznie nie zmieniają się podczas realizacji projektu. Prawie zawsze nadrzędnym celem wymagań biznesowych jest zwiększenie zysków firmy. Na podstawie wymagań biznesowych tworzy się wymagania pozostałych typów. Spełnienie wymagań biznesowych w dużym stopniu decyduje o sukcesie projektu. Przykładem wymagania biznesowego może być przyspieszenie procedury rozliczania faktur.

17 Klasyfikacja wymagań Wymagania użytkownika Wymagania użytkownika definiują cele z perspektywy użytkownika końcowego, czyli zadania, które użytkownik będzie mógł wykonać korzystając z gotowego systemu. Najczęściej przedstawiane są w formie scenariuszy opisujących kolejne kroki działań podejmowane przez użytkownika i sposoby reakcji systemu. Często dokumentowane są one jako „przypadki użycia” (ang. use cases). Stanowią podstawę do tworzenia szczegółowych wymagań funkcjonalnych. Przykładem jest możliwość drukowania tygodniowego zestawienia transakcji.

18 Klasyfikacja wymagań Wymagania funkcjonalne Wymagania funkcjonalne, w przeciwieństwie do wymagań użytkownika, są definiowane z perspektywy systemu i szczegółowo opisują funkcjonalność systemu, czyli wszystkie usługi, jakie system musi wykonać. Przy budowaniu wymagań funkcjonalnych inicjatywa należy do zespołu programistów, analityków, architektów oprogramowania, którzy dzięki swej wiedzy i doświadczeniu wiedzą jak zrealizować daną funkcjonalność, aby była użyteczna dla użytkownika. Jako przykład można podać wymaganie definiujące przycisk ‘Zapisz’ wyzwalający akcję przepisania wprowadzonych danych do bazy danych.

19 Klasyfikacja wymagań Wymagania niefunkcjonalne Wymagania niefunkcjonalne nie mają wpływu na funkcje systemu, jednak nakładają ograniczenia na sposób, w jaki wymagania funkcjonalne będą zrealizowane. Wymagania te wynikają z kwestii technologicznych, bezpieczeństwa, wydajności, zgodności ze standardami, wymagań prawnych, polityki firmy itp. Są to pewne własności systemu. Określają jak system zachowuje się wykonując swoje zdefiniowane funkcje. Przykładem niech będzie wymaganie określające maksymalny czas potrzebny do zapisania danych

20 Klasyfikacja wymagań Metoda FURPS W projektach informatycznych bardzo często do klasyfikacji wymagań używa się także metody FURPS, której nazwa jest angielskim akronimem. Pierwsza litera (F) oznacza wymagania funkcjonalne, natomiast pozostałe cztery (URPS) definiują kolejne składowe wymagań niefunkcjonalnych: F (ang. Functionality) – funkcjonalność, uwzględnia również bezpieczeństwo systemu. U (ang. Usability) – użyteczność i ergonomia, oznacza łatwość użytkowania systemu. R (ang. Reliability) – niezawodność, mierzona np. częstością występowania błędów. P (ang. Performance) – wydajność, charakteryzująca czas odpowiedzi lub użycie zasobów. S (ang. Supportability) – wspieralność, uwzględniająca zdolność aplikacji do instalacji na różnych platformach, łatwość testowania i możliwości utrzymaniowe systemu.

21 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Typy wymagań niefunkcjonalnych Wymagania niefunkcjonalne Wymagania produktowe Wymagania organizacyjne Wymagania zewnętrzne Wymagania sprawnościowe Wymagania niezawodności Wymagania przenośności Wymagania współpracy Wymagania etyczne Wymagania zabezpieczeń Wymagania prawne Wymagania ochrony prywatności Wymagania implementacyjne Wymagania standardów Wymagania dostawy Wymagania użyteczności Wymagania efektywnościowe Wymagania pamięciowe

22 © SWEBOK Guide to the Software Engineering Body of Knowledge

23 Procesy inżynierii wymagań (3) ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. 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ń

24 Inżynieria wymagań Cykliczny proces

25 Elicitation. Identify sources of information about the system and discover the requirements from these. Analysis. Understand the requirements, their overlaps, and their conflicts. Validation. Go back to the system stakeholders and check if the requirements are what they really need. Negotiation. Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. Inżynieria wymagań Cykliczny proces

26 Documentation. Write down the requirements in a way that stakeholders and software developers can understand. Management. Control the requirements changes that will inevitably arise. Inżynieria wymagań Cykliczny proces

27 Inżynieria wymagań Cykliczny proces

28 Techniki pozyskiwania wymagań Studia literatury dotyczącej przedmiotu zawierającej podstawowe informacje na temat dziedziny problemowej; Identyfikacja udziałowców, czyli osób lub dokumentów mających pewien wpływ na powstający system lub punkt widzenia systemu; Wywiady i dyskusje z przyszłymi użytkownikami; Ankiety stosowane w celu pozyskania wymagań lub opinii użytkowników na temat powstającego systemu; Analiza dokumentów obowiązujących w danej organizacji; Analiza istniejącego systemu;

29 Techniki pozyskiwania wymagań Obserwacje przyszłych użytkowników systemu podczas ich pracy; Opis kontekstu działania systemu, np. warunki w jakich ma działać system; Symulacje punktów widzenia, stosowane w celu stwierdzenia, czy system będzie spełniał oczekiwania określonej grupy użytkowników; Prototypowanie – prezentacja użytkownikom ‘atrapy’ systemu, np. samego interfejsu użytkownika w celu pozyskania ich opinii lub dodatkowych wymagań; Prezentacje u dostawców podobnych systemów, stosowane w celu zapoznania się z podobnymi rozwiązaniami.

30 Proces analizy wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i Rozpoznanie dziedziny 2. Zbieranie wymagań 3. Klasyfikacja 4. Usuwanie sprzeczności 5. Nadawanie priorytetów 6. Sprawdzanie wymagań 7. Specyfikacja wymagań 8. Dokumentacja wymagań Początek procesu

31 Czynności procesu analizy wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Jest to proces iteracyjny z ciągłym przekazywaniem informacji zwrotnej między czynnościami Cykl rozpoczyna się od rozpoznania dzidziny, a kończy na sprawdzeniu wymagań Stopień zrozumienia dziedziny rośnie z każdym cyklem Czynności są następujące: –Rozpoznanie dziedziny –Zebranie wymagań –Klasyfikowanie wymagań –Usuwanie sprzeczności –Nadawanie priorytetów –Sprawdzanie wymagań

32 Specyfikacja wymagań oprogramowania Faza określenia wymagań kończy się przygotowaniem dokumentu specyfikacji wymagań oprogramowania (ang. Software Requirements Specification, SRS), który opisuje co system powinien wykonywać. SRS jest podstawą do organizacji prac projektowych i implementacyjnych.

33 Specyfikacja wymagań oprogramowania Cechy dobrej specyfikacji wymagań oprogramowania: poprawność jednoznaczność kompletność spójność uporządkowanie według ważności (priorytetyzacja) weryfikowalność modyfikowalność możliwość śledzenia zależności, wykonalność

34 Specyfikacja wymagań oprogramowania Przykład

35 Dokumenty opracowane przez: Instytut Informatyki Politechniki Poznańskiej Miasto Poznań PP - szablon specyfikacji wymagan.doc PP - przykladowa specyfikacja wymagan.doc PP - instrukcja sporzadzania specyfikacji wymagan.pdf Specyfikacja wymagań oprogramowania Przykład

36 Specyfikacja wymagań oprogramowania Struktura treści

37 Specyfikacja wymagań oprogramowania Struktura treści

38 Specyfikacja wymagań oprogramowania Szablon opisu procesu biznesowego

39 Specyfikacja wymagań oprogramowania Szablon przypadków użycia

40 Specyfikacja wymagań oprogramowania Szablon opisu procesu biznesowego

41 Specyfikacja wymagań z użyciem standardowego formularza ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Funkcja. Dodaj węzeł. Opis. Dodaje węzeł do istniejącego projektu.Użytkownik wybiera typ i położenie węzła. Po dodaniu do projektu węzeł jest zaznaczony. Użytkownik wybiera miejsce węzła przesuwając wskaźnik na obszar w którym dodano węzeł Dane wejściowe. Typ węzła i położenie węzła pochodzą od użytkownika, a identyfikator projektu z bazy danych. Przeznaczenie. Baza danych projektów. Projekt jest utrwalany w bazie danych po zakończeniu operacji. Wymagania. Korzeniem grafu projektu musi być dany identyfikator projektu. Warunek początkowy. Projekt jest otwarty i wyświetlony na ekranie użytkownika. Warunek końcowy. Projekt nie uległ zmianie z wyjątkiem dodania węzła zadanego typu o zadanym położeniu. Efekty uboczne. Brak.

42 Model procesu projektowania ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

43 Zatwierdzanie wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik 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 Ma wiele wspólnych cech z analizą wymagań, jednakże dotyczy kompletnej propozycji dokumentacji wymagań, podczas gdy analiza to praca z niekompletnymi wymaganiami

44 Sprawdzanie wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Zatwierdzanie polega na sprawdzaniu wymagań obejmującym: Ważność. Czy system rzeczywiście dostarcza funkcji, które najlepiej spełniają potrzeby użytkownika? Spójność. Czy wymagania nie są sprzeczne? Kompletność. Czy są wszystkie wymagania? Realność. Czy można zaimplementować wszystkie wymagania? Weryfikowalność. Czy można je zweryfikować?

45 Techniki zatwierdzania wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Przeglądy wymagań –Systematyczne analizy wymagań Prototypowanie –Przedstawianie klientom działającego modelu systemu Generowanie testów –Tworzenie testów dla sprawdzenia czy wymagania są weryfikowalne Automatyczne sprawdzanie niesprzeczności –Sprawdzanie niesprzeczności wymagań wyrażonych w strukturalnej lub formalnej notacji, np. za pomocą narządzi CASE

46 Automatyczne sprawdzanie niesprzeczności ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Wymagania w języku formalnym Kompilator Baza danych wymagań Raporty o sprzecznych wymaganiach Generator raportów

47 Przeglądy wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Powinny odbywać się regularnie dopóki formułowane są nowe wymagania Powinny być wykonywane przez zespół składający się z pracowników obu stron 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

48 Lista sprawdzeń dla wymagania ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Weryfikowalność. Czy wymaganie można praktycznie sprawdzić? Zrozumiałość. Czy klienci i użytkownicy systemu właściwie zrozumieli wymaganie? Pochodzenie. Czy określono źródło skąd pochodzi wymaganie? Elastyczność. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe.

49 Zmiany wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Gdy użytkownicy zdobędą pewne doświadczenie w pracy z systemem, wyłaniają się nowe wymagania, z następujących przyczyn: –Ważność wymagań zależy od punktu widzenia. Różni użytkownicy stawiają różne wymagania i przypisują im różne priorytety. Trzeba osiągnąć kompromis –Klienci systemu mogą wyrażać wymagania z perspektywy biznesowej co może być sprzeczne z wymaganiami użytkowników końcowych –Otoczenie biznesowe i techniczne zmienia się w trakcie trwania przedsięwzięcia

50 Ewolucja wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Czas Wstępne zrozumienie problemu Wstępne wymagania Zmienione zrozumienie problemu Zmienione wymagania

51 Zarządzanie zmianami wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6. Należy stosować do wszystkich postulowanych zmian wymagań Główne kroki procesu zarządzania zmianami –Analiza problemu i specyfikacja zmiany. Rozpoznanie problemu z wymaganiem i propozycja zmian –Analiza zmiany i ocena kosztów. Szacuje koszt wprowadzenia zmiany –Implementacja zmiany. Modyfikuje dokumentację wymagań i inne dokumentacje jeśli zachodzi taka potrzeba Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany Rozpoznany problem Skorygowane wymaganie

52 Dziękuję za uwagę


Pobierz ppt "Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 3 Zarządzanie wymaganiami (wymagania stawiane oprogramowaniu) Oparty na:"

Podobne prezentacje


Reklamy Google