Zarządzanie projektem informatycznym

Prezentacja na temat: "Zarządzanie projektem informatycznym"— 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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.
Definicja wymagań (1) 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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

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

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

22 © SWEBOK 2004 - Guide to the Software Engineering Body of Knowledge

23 Procesy inżynierii wymagań (3)
Określanie i analizowanie wymagań Studium wykonalności Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonalności Model systemu Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

24 Inżynieria wymagań Cykliczny proces

25 Inżynieria wymagań Cykliczny proces
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.

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

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ń
7. Specyfikacja wymagań 6. Sprawdzanie wymagań 8. Dokumentacja wymagań 1. Rozpoznanie dziedziny 5. Nadawanie priorytetów Początek procesu 2. Zbieranie wymagań 4. Usuwanie sprzeczności 3. Klasyfikacja ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

31 Czynności procesu analizy wymagań
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ń ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

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 Specyfikacja wymagań oprogramowania
Przykład 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

36 Specyfikacja wymagań oprogramowania
Struktura treści

37 Specyfikacja wymagań oprogramowania
Struktura treści

38 Szablon opisu procesu biznesowego
Specyfikacja wymagań oprogramowania Szablon opisu procesu biznesowego

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

40 Szablon opisu procesu biznesowego
Specyfikacja wymagań oprogramowania Szablon opisu procesu biznesowego

41 Specyfikacja wymagań z użyciem standardowego formularza
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. ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

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

43 Zatwierdzanie wymagań
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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

44 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.
Sprawdzanie wymagań 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ć? ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

45 Techniki zatwierdzania wymagań
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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

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

47 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.
Przeglądy wymagań 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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

48 Lista sprawdzeń dla wymagania
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. ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

49 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.
Zmiany wymagań 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 ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

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

51 Zarządzanie zmianami wymagań
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 Rozpoznany problem Skorygowane wymaganie Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany ©Ian Sommerville 2000: Inżynieria oprogramowania. Rozdziały 5 i 6.

52 Dziękuję za uwagę