Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Techniki i rozwiązania IT w optymalizacji procesów Inżynieria wymagań

Podobne prezentacje


Prezentacja na temat: "Techniki i rozwiązania IT w optymalizacji procesów Inżynieria wymagań"— Zapis prezentacji:

1 Techniki i rozwiązania IT w optymalizacji procesów Inżynieria wymagań

2 Problemy realizacji zadań IT 1/3 Wg Standish Group International w początkach lat 90tych w USA wydawane było ponad 250 mld USD rocznie na tworzenie aplikacji IT w blisko różnych przedsięwzięciach Średni koszt stworzenia oprogramowania –dla dużej formy ponad USD –dla średniej powyżej USD –dla małej blisko USD

3 Problemy realizacji zadań IT 2/3 31% tych przedsięwzięć jest anulowanych przed zakończeniem Ponad 52% kosztuje blisko 190% pierwotnego szacunku Koszty utraconych korzyści nie są mierzalne, ale bez większych problemów mogą być liczone w miliardach

4 Problemy realizacji zadań IT 2/3 W latach 2000 – 2006 sytuacja uległa poprawie ale w dalszym ciągu wiele projektów kończy się niepowodzeniem: –tylko 35% kończy się sukcesem (16,2% w roku 1994) –19% to całkowita porażka –46% to projekty z przekroczonym czasem lub kosztami

5 Przyczyny niepowodzeń

6 Główne czynniki sukcesu

7 Znaczenie problemów

8 Względny koszt usuwania wad

9 Źródła dodatkowych kosztów 1/2 Ponowna specyfikacja Ponowne projektowanie, kodowanie i dokumentowanie Zmiana dyspozycji –przekazanie użytkownikom i operatorom informacji o wymianie wadliwej wersji systemu na wersję poprawioną Działania korygujące – likwidacja potencjalnych uszkodzeń u klienta

10 Źródła dodatkowych kosztów 2/2 Anulowanie części kodu, projektu czy już wykonanych testów Wycofanie od użytkowników wadliwych finalnych wersji oprogramowania i podręczników obsługi Koszty gwarancji czy serwisu Odpowiedzialność karna związaną z produktem

11 Proces zarządzania wymaganiami Analizowanie problemu

12 Specyfikacja wymagań 1/2 Według Dorfmana i Thaylera wymaganie to: –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 Wymagania to możliwości i funkcjonalności jakich musi dostarczyć projektowany system

13 Specyfikacja wymagań 2/2 Zarządzanie wymaganiami można traktować jako zbiór zorganizowanych, uniwersalnych i usystematyzowanych technik zajmowania się wymaganiami stawianymi złożonemu, dużemu przedsięwzięciu Jednym z narzędzi zarządzania wymaganiami jest diagram wymagań

14 Uzgodnienie definicji problemu Problem polega na… –opis analizowanego problemu Problem dotyczy… –identyfikacja udziałowców, których dotyczy problem Rezultatem problemu jest… –opis wpływu problemu na udziałowców i działalność przedsiębiorstwa Korzyści z rozwiązania problemu… –ustalenie proponowanego rozwiązania i zaznaczenie podstawowych korzyści

15 Zrozumienie podstawowych przyczyn problemu 1/3 Technika analizy podstawowej przyczyny polega na systematycznym znajdowaniu podstawowej przyczyny badanego problemu lub symptomu problemu Najprostsza droga to pytanie osób zainteresowanych Jeżeli takie podejście nie przyniesie założonych rezultatów, należy możliwie szczegółowo zbadać każdy pokrewny problem oraz określić jego indywidualny wpływ

16 Zrozumienie podstawowych przyczyn problemu 2/3 Formalny sposób zapisu zaobserwowanych problemów - Diagramy Ishikawy

17 Zrozumienie podstawowych przyczyn problemu 3/3 Głównym celem jest określenie ilościowego udziału każdej podstawowej przyczyny Pewnych podstawowych przyczyn nie warto ustalać, gdyż koszt ich usunięcia przekroczy koszt rozwiązania problemu Zebrane dane warto umieścić na wykresie Pareto, w celu wykrycia przyczyn generujących najwyższe koszty i będących najsilniej związanymi z problemem

18 Zidentyfikowanie udziałowców i użytkowników tworzonego systemu Użytkownikiem, udziałowcem systemu jest każdy na kogo implementacja nowego systemu lub nowej aplikacji ma zasadniczy wpływ Klasy udziałowców: –końcowi użytkownicy systemu, na których działanie systemu ma największy wpływ –pośredni użytkownicy systemu – system tylko w pewnym stopniu wpływa na wyniki ich działalności –udziałowcy, którzy w najmniejszym stopniu związani są ze środowiskiem aplikacji

19 Zdefiniowanie granicy systemu rozwiązania

20 Kryteria dekompozycji spójność elementów składowych systemu (cohesion) –pożądana jest maksymalna spójność elementów na wszystkich poziomach abstrakcji więź między elementami składowymi systemu (coupling) –należy dążyć do minimalizacji siły powiązań na każdym poziomie abstrakcji

21 Problemy dekompozycji rejestracja zamówień sterowanie serwisem klient rozliczanie usług system logistyki system f-k rejestracja zamówień sterowanie serwisem klient system logistyki system f-k A B granice dekompozycji granice dekompozycji

22 Zidentyfikowanie ograniczeń nałożonych na rozwiązanie 1/4 Ograniczenia ekonomiczne –Jakie zastosowanie mają ograniczenia finansowe lub budżetowe? –Czy koszty sprzedawanych produktów i ceny produktów powinny być uwzględniane? –Czy występują zagadnienia związane z licencją? Ograniczenia polityczne –Czy występują wewnętrzne lub zewnętrzne zagadnienia polityczne, które mają wpływ na potencjalne rozwiązania? –Jaki problemy lub zagadnienia między wydziałowe są związane z systemem?

23 Zidentyfikowanie ograniczeń nałożonych na rozwiązanie 2/4 Ograniczenia techniczne –Czy istnieją ograniczenia w wyborze technologii? –Czy jesteśmy zmuszeni pracować na istniejącej platformie lub w istniejącej technologii? –Czy istnieją ograniczenia w zastosowaniu nowych technologii? –Czy mamy używać zakupionych pakietów oprogramowania?

24 Zidentyfikowanie ograniczeń nałożonych na rozwiązanie 3/4 Ograniczenia systemowe –Czy rozwiązanie ma być wbudowane w naszych istniejących systemach? –Czy musimy zachować kompatybilność z istniejącymi rozwiązaniami? –Jakie systemy operacyjne i środowiska muszą być obsługiwane? Ograniczenia środowiskowe –Czy są ograniczenia środowiskowe lub normatywne? –Czy są ograniczenia prawne? –Czy są wymagania bezpieczeństwa?

25 Zidentyfikowanie ograniczeń nałożonych na rozwiązanie 4/4 Planowanie i zasoby –Czy plan jest określony? –Czy jesteśmy ograniczeni od istniejących zasobów? –Czy możemy zatrudnić pracowników spoza firmy? –Czy możemy zwiększyć zasoby (tymczasowe/stałe)?

26 Proces zarządzania wymaganiami Zrozumienie potrzeb użytkownika

27 Uzyskiwanie wymagań od użytkowników oraz innych udziałowców systemu Bariery związane z uzyskiwaniem wymagań: –syndrom tak, ale –syndrom nieodkrytych ruin –syndrom użytkownik i programista

28 Techniki uzyskiwania wymagań - wywiad Wywiad jest najważniejszą i najbardziej skuteczną techniką gromadzenia wymagań Początkowo należy wysłuchać sugestii użytkownika W drugiej fazie wywiadu można zasugerować pewne rozwiązania Po przeprowadzeniu wywiadu należy podsumować uzyskane od klienta informacje

29 Techniki uzyskiwania wymagań - warsztat wymagań 1/2 Celem warsztatu wymagań jest osiągnięcie w jak najkrótszym czasie zgody pomiędzy projektantami i użytkownikami w sprawie wymagań stawianych aplikacji oraz do uzyskania szybkiego porozumienia co do podjęcia określonych zadań Najważniejsi udziałowcy przedsięwzięcia gromadzą się przez krótki, ale intensywnie wykorzystywany czas, zwykle nie dłużej niż dwa dni, koncentrując się na tworzeniu lub przeglądzie najważniejszych cech

30 Techniki uzyskiwania wymagań - warsztat wymagań 2/2 Kierowanie warsztatem powinno być przekazane członkowi zespołu lub jeszcze lepiej doświadczonemu inżynierowi wymagań pochodzącemu spoza przedsiębiorstwa Przygotowanie warsztatu: –prezentacja koncepcji – należy zaprezentować koncepcję warsztatu wymagań na forum firmy –zapewnienie obecności właściwych udziałowców –logistyka – osiągnięcie pożądanych rezultatów jest możliwe tylko przy właściwej organizacji warsztatu –materiały wprowadzające – materiały kształtujące wyobrażenie uczestników warsztatu na dany temat

31 Techniki uzyskiwania wymagań – burza mózgów Burza mózgów i redukcja pomysłów to przeważnie część warsztatu poświęcona znajdowaniu nowych pomysłów i cech aplikacji Technika ta polega na redukcji i grupowaniu pomysłów wygenerowanych w pierwszej fazie burzy Na podstawie wyselekcjonowanych pomysłów generowane są cechy systemu, które porządkowane są według priorytetów Przydatną modyfikacją tej techniki jest przeprowadzenie burzy mózgów z wykorzystaniem Internetu lub intranetu oraz przez założenie grup dyskusyjnych

32 Techniki uzyskiwania wymagań – rysunkowe szkice ujęć Pasywne – przekazują użytkownikowi informacje. Przeważnie składają się ze szkiców, obrazów, zdjęć ekranu, prezentacji czy przykładowych wydruków, na których przedstawiane są zasady przedsiębiorstwa, raporty końcowe czy sposób, w jaki system reaguje na akcję użytkownika. Aktywne – przekazują zautomatyzowany opis, w jaki sposób zachowuje się system w typowym scenariuszu działań lub zastosowania. Przyjmuje on postać pokazu slajdów, animacji czy symulacji działania systemu. Interaktywne – angażują użytkownika w swoje działanie jednocześnie pozwalając mu poznać system, tak jak w warunkach rzeczywistych. Mogą przyjąć postać programu demonstracyjnego na żywo czy interaktywnej prezentacji.

33 Techniki uzyskiwania wymagań – diagram przypadków użycia Diagramy służą do określania wymagań co do projektowanego systemu Celem metody jest: –zrozumienie użycia systemu –zwiększenie stopnia świadomości analityków i projektantów co do celu systemu –umożliwienie interakcji w zespole projektowym

34 Techniki uzyskiwania wymagań – diagram przypadków użycia Celem metody jest: –weryfikacja poprawności i kompletności projektu –odzyskanie wszystkich strukturalnych i funkcjonalnych własności projektu –ustalenie składowych systemu i planu jego konstrukcji –opracowanie podstawy do planu testów Diagramy mogą być łączone z diagramami sekwencji

35 Używane symbole

36

37 Inna notacja (wer. 1.3)

38 Scenariusze przypadków użycia Pojedynczy przypadek może być sekwencją czynności wykonywanych w jego ramach Do opisu scenariuszy można użyć: –opisu słownego mniej lub bardziej uporządkowanego –sformalizowanego opisu słownego – pseudokodu –diagramów aktywności

39 Visual Paradigme - raport

40 Scenariusz uporządkowany 1/4 Nazwa funkcji i identyfikator: –przesłanie zamówienia do odbiorcy – F127 opis ogólny: –przedstawiciel handlowy raz w tygodniu wprowadza do systemu dane o zgromadzonych zamówieniach i przesyła je do Systemu warunki wstępne: –przedstawiciel zakończył pracę w tygodniu i sprawdził poprawność danych

41 Scenariusz uporządkowany 2/4 Wyniki działania funkcji: –dane o zamówieniach z tygodnia od przedstawiciela są wstępnie sprawdzone i zapisane w bazie danych opis scenariusza –przedstawiciel loguje się do systemu i wprowadza z klawiatury dane o zamówieniach do odpowiedniego formularza oraz potwierdza kompletność danych; system sprawdza poprawność i kompletność danych; przedstawiciel akceptuje wprowadzone dane i żąda ich wysłania; System przesyła dane do bazy danych

42 Scenariusz uporządkowany 3/4 Scenariusze alternatywne: –przedstawiciel nie może zalogować się do systemu – uruchamiana jest procedura opisana w przypadku F128 –System wykrył błędy w danych i zgłasza je przedstawicielowi – przedstawiciel próbuje poprawić błędy –przedstawiciel nie potrafi poprawić błędów - uruchamiana jest procedura opisana w przypadku F129 –przedstawiciel zauważył błędy we wprowadzonych danych i ich nie akceptuje – konieczna jest ich poprawa

43 Scenariusz uporządkowany 4/4 Wykaz powiązanych reguł: –R127 – weryfikacja danych o zamówieniach Opis reguł: –nazwa reguły i identyfikator, –opis ogólny, –przykład, –źródło (podstawa), –reguły związane

44 Notacja dla scenariuszy Zdania o prostej gramatyce SVD(PI) System umieszcza dane klienta na liście klientów. podmiot (S) orzeczenie (V) dopełnienie (D) przyimek (P) dopełnienie dalsze (I) S – Subject, V – Verb, D – Directobject, P – Preposition, I - Indirectobject

45 Pisanie scenariuszy – dobre praktyki Fraza czasownikowa w nazwie –przesłanie zamówienia do odbiorcy a nie scen. 127 Obojętność technologiczna –nie powinno się używać terminów technicznych, np. wybiera z listy, klika –nie należy używać wskazań implementacyjnych, np. dane są zapisane do relacyjnej bazy danych –w niektórych przypadkach można załączyć rysunki lub szkice

46 UML – diagram aktywności Diagram aktywności to wersja klasycznych diagramów przepływu – flow charts Za pomocą ściśle zdefiniowanego zestawu symboli pozwala przedstawić graficznie przepływ działań i logikę tych działań

47

48 Techniki uzyskiwania wymagań – odgrywanie ról Technika odgrywania ról pozwala zespołowi programistycznemu poznać świat użytkownika dzięki odgrywaniu roli użytkownika W najprostszej postaci odgrywania ról, programista, analityk albo członek zespołu projektowego po prostu zajmuje miejsce użytkownika i wykonuje jego czynności

49 Techniki uzyskiwania wymagań – stosowanie prototypów 1/2 Prototypem oprogramowania możemy nazwać pierwotną postać systemu oprogramowania, który jest w stanie zademonstrować część już zaimplementowanej funkcjonalności systemu Jeżeli ryzyko przedsięwzięcia związane jest głównie z wykonalnością podejścia technologicznego (nie ma pewności, czy zastosowana technologia pozwoli na osiągnięcie celów i wydajności) dobrym wyborem będzie prototyp strukturalny (architektoniczny), który demonstruje wykonalność danej technologii

50 Techniki uzyskiwania wymagań – stosowanie prototypów 2/2 Jeżeli w przedsięwzięciu przeważa ryzyko związane z interfejsem użytkownika, to wtedy należy użyć prototypu wymagań Prototyp wymagań to częściowa implementacja systemu oprogramowania, utworzona, aby pomóc programistom, użytkownikom i klientom lepiej zrozumieć wymagania stawiane systemowi

51 Proces zarządzania wymaganiami Cechy a wymagania

52 Pojęcie cechy systemu 1/2 Udziałowcy, z którymi przeprowadzana jest rozmowa na temat ich potrzeb lub wymagań stawianych projektowanemu systemowi, często nie opisują ich dokładnie Potrzeby definiowane przez użytkowników nie mogą być zaklasyfikowane ani do kategorii potrzeb rzeczywistych, ani do kategorii faktycznych wymagań stawianych systemowi

53 Pojęcie cechy systemu 2/2 Rozmyte określenia pożądanego zachowania systemu nazywane są cechami produktu lub systemu Maksymalna możliwa liczba cech powinna mieścić się w zakresie od 25 do 99, przy preferowanej liczbie nie większej niż 50

54 Atrybuty cech Status - śledzi postęp podczas definiowania podstawowej linii przedsięwzięcia oraz późniejsze tworzenie rozwiązania Priorytet/Korzyść - klasyfikowanie według względnego priorytetu lub korzyści dla końcowego użytkownika umożliwia dialog między udziałowcami a członkami zespołu programistów Wysiłek - oszacowanie liczby zespołów, członków lub tygodni, wierszy kodu lub miejsc występowania funkcji

55 Atrybuty cech Ryzyko - prawdopodobieństwo, że cecha spowoduje niepożądane zdarzenie Stabilność - prawdopodobieństwo, że zmieni się cecha lub zmieni się rozumienie cechy przez członków zespołu programistów Wersja docelowa - rejestrowana jest planowana wersja produktu, w której cecha pojawi się po raz pierwszy. W połączeniem z polem Status, zespół może proponować, zapisywać i omawiać różne cechy bez zobowiązania do ich zapewnienia

56 Atrybuty cech Przydzielenie do - cechy muszą być przydzielone do przyszłych zespołów odpowiedzialnych za dalsze pozyskiwanie i zapisywanie wymagań stawianych oprogramowaniu i, być może, odpowiedzialnych nawet za implementację Powód - stosowany do śledzenia źródła pożądanej cechy, może być odwołaniem np.: do stron i numeru wiersza specyfikacji produktu lub do znacznika na obrazie pokazującym wywiad z ważnym klientem

57 Proces zarządzania wymaganiami Definiowanie systemu

58 Dokumentowanie wymagań

59

60

61

62 Dokument wizji dla projektowanego przedsięwzięcia Dokument wizji jest zwięzłym opisem wszystkiego co jest uważane za najistotniejsze w odniesieniu do produktu i aplikacji Dzięki temu dokumentowi możliwe jest określenie potrzeb użytkownika, cech systemu jak i innych użytecznych wymagań dla danego przedsięwzięcia Dokument ten definiuje na wysokim poziomie abstrakcji zarówno problem jak i rozwiązanie

63 Proces zarządzania wymaganiami Udoskonalanie definicji systemu

64 Wymagania stawiane oprogramowaniu Wejścia do systemu – oprócz zawartości wejścia należy określić, o ile jest to konieczne, szczegóły urządzeń wejściowych, formę i wygląd, a także stosowany protokół komunikacji Wyjścia z systemu – określając ten element należy wziąć pod uwagę opis urządzeń wyjściowych, protokół jak i format danych generowanych przez system Funkcje systemu – odwzorowanie wejść i wyjść oraz ich kombinacji Atrybuty systemu – to takie elementy jak: niezawodność, łatwość konserwacji, dostępność i przepustowość Atrybuty środowiska – to z kolei: zdolność systemu do działania przy pewnych ograniczeniach operacyjnych czy kompatybilność z systemem operacyjnym

65 Klasyfikacja wymagań

66 Wymagania funkcjonalne Ten typ wymagań związany jest z zachowaniem się systemu – z funkcjami, jakie realizuje Wymagania te związane są z określonymi czynnościami, jakie wykonuje użytkownik przy wykorzystaniu systemu Dotyczą one głównie wejść, wyjść i szczegółów przetwarzania Informują jak system ma się zachować przy pewnych danych wejściowych lub w pewnych warunkach

67 Wymagania funkcjonalne Większość wymagań funkcjonalnych może być określona prostymi, opisowymi zdaniami lub przyjąć formę przypadków użycia Jedno- lub dwuzdaniowe określenie wymagania zazwyczaj dobrze opisuje potrzeby użytkownika na takim poziomie, aby programista miał jasność jak to zrealizować

68 Wymagania niefunkcjonalne – użyteczność 1/2 Łatwość poznania i użytkowania systemu przez jego użytkowników: –należy określić czas szkoleń, jaki jest wymagany dla konkretnego użytkownika, aby stał się wydajny dla określonych aplikacji; może to wymagać również dodatkowego opisu –istotną kwestią jest podanie czasów wykonywania typowych zadań, które będą realizowanie przez użytkownika końcowego; czas ten zależy również od czynników technicznych (mocy CPU, ilość RAM czy przepustowości łącza)

69 Wymagania niefunkcjonalne – użyteczność 2/2 –Należy porównać użyteczność nowego systemu z systemami znanymi i lubianymi przez użytkownika –Kolejnym istotnym elementem w określaniu użyteczności jest zaznaczenie istnienia i określenie cech systemów pomocy on-line, kreatorów, wskazówek narzędziowych, podręczników użytkownika oraz innych form dokumentacji i pomocy

70 Wymagania niefunkcjonalne – niezawodność 1/2 Dostępność systemu do użytku operacyjnego wyrażona w czasie określonym procentowo Średni czas międzyawaryjny (MTBF) – wyrażony w godzinach, dniach miesiącach czy latach Średni czas naprawy (MTTR) określa jak długo system może nie działać po wystąpieniu awarii

71 Wymagania niefunkcjonalne – niezawodność 2/2 Dokładność – jaka precyzja jest wymagana w systemie, na wyjściu którego znajdują się dane w formie liczbowej Maksymalna liczba błędów lub współczynnik błędu – wartość zwykle wyrażona w błędach na tysiące linii kodu lub w liczbie błędów na funkcję Błędy według typu – wyrażone w kategoriach: błędy małe, znaczące i krytyczne; należy określić jakie negatywne zachowania systemu mieszczą się w poszczególnych kategoriach błędów

72 Wymagania niefunkcjonalne – efektywność Czas odpowiedzi dla transakcji – średni, maksymalny Przepustowość – wyrażona w liczbie transakcji na sekundę Pojemność – określana liczbą transakcji lub klientów jaką system może obsłużyć Tryby degradacji – jaki tryb operacji jest akceptowalny, w wypadku pogorszenia się jakości działania systemu

73 Wymagania niefunkcjonalne – Przystosowalność Łatwość modyfikowania i weryfikowania oprogramowania Niektóre aplikacje mogą mieć z góry określone przyszłe udoskonalenia, a w wymaganiu dla takiego rozwiązania może zostać określony czas reakcji grupy konserwacyjnej dla prostych, średnich i złożonych udoskonaleń

74 Ograniczenia projektowe Ograniczenia dotyczące projektowania systemu lub procesu tworzenia systemu, które nie mają wpływu na zachowanie zewnętrzne systemu, ale które muszą być spełnione, aby dotrzymać zobowiązań technicznych, ekonomicznych lub wynikających z umowy: –środowisko operacyjne (np. wymagany jakiś konkretny język programowania) –kompatybilność z istniejącymi systemami –standardy aplikacji –standardy i najlepsze metody przedsiębiorstwa

75 Specyfikacji Wymagań stawianych Oprogramowaniu (SWO) SWO ma służyć jako podstawa komunikacji między wszystkimi stronami: między programistami oraz między programistami a grupami zewnętrznymi, użytkownikami i innymi udziałowcami, z którymi muszą się komunikować; formalnie lub nieformalnie pakiet reprezentuje również porozumienie między różnymi stronami. SWO ma być standardem, do którego odwołują się kierownicy oprogramowana; kierownik używa pakietu jako podstawy w dyskusji z zespołem programistów.

76 Specyfikacji Wymagań stawianych Oprogramowaniu (SWO) Pakiet ma dostarczać danych wejściowych grupom zajmującym się projektowaniem i implementacją SWO powinien dostarczać danych wejściowych dla grup testowania oprogramowania oraz grup zapewnienia jakości SWO steruje rozwojem systemu przez cały etap tworzenia systemu – zmiany wprowadzone w dokumencie wizji są jednocześnie opracowywane w pakiecie

77 Struktura SWO 1/4 Opis ogólny Historia korekt Spis treści Wstęp –Cel –Zakres –Odwołania –Założenia i zależności

78 Struktura SWO 2/4 Przegląd modeli przypadków użycia Przegląd aktorów Wymagania –Wymagania funkcjonalne –Wymagania niefunkcjonalne Użyteczność Niezawodność Efektywność Przystosowalność

79 Struktura SWO 3/4 Dokumentacja użytkownika on-line oraz wymagania stawiane systemowi pomocy Ograniczenia projektowe Zakupione komponenty Interfejsy –Interfejsy użytkownika –Interfejsy sprzętowe –Interfejsy programowe –Interfejsy komunikacyjne

80 Struktura SWO 4/4 Wymagania licencyjne Uwagi prawne, związane z prawem autorskim i inne Stosowane standardy Indeks Słownik

81 Miary jakości wymagań stawianych oprogramowaniu Wymagania mają wysoką jakość jeżeli są: –poprawne – oznacza to, że każde z wymagań reprezentuje coś, czego zespół wymaga od systemu, coś, co ma być zbudowane –jednoznaczne – wymaganie jest jednoznaczne wtedy i tylko wtedy, gdy istnieje dla niego tylko jedna interpretacja –kompletne – zbiór wymagań jest kompletny wtedy i tylko wtedy, gdy opisuje wszystkie znaczące wymagania, będące przedmiotem zainteresowania użytkownika, łącznie z wymaganiami związanymi z funkcjonalnością, wydajnością, ograniczeniami projektowymi, atrybutami lub interfejsami zewnętrznymi

82 Miary jakości wymagań stawianych oprogramowaniu –spójne – zbiór wymagań jest spójny wtedy i tylko wtedy, gdy w żadnym jego podzbiorze nie występują wymagania będące ze sobą w konflikcie –uporządkowane według ważności i stabilności – w wysokiej jakości zbiorach wymagań wymagania są uporządkowane według ważności dla klienta oraz w kategoriach stabilności; jeżeli zasoby są niewystarczające do implementacji wszystkich wymagań w ramach ustalonego planu i budżetu wtedy ważne jest, aby wiedzieć, które z wymagań są niestabilne, a które są krytyczne dla użytkownika

83 Miary jakości wymagań stawianych oprogramowaniu –weryfikowalne – wymagania mogą być uważane za weryfikowalne wtedy i tylko wtedy, gdy istnieje skończony ekonomicznie efektywny proces, dzięki któremu możliwe jest określenie przez osobę lub przy wykorzystaniu maszyny, że tworzony system oprogramowania rzeczywiście spełnia wymagania –modyfikowalne – zbiór wymagań jest modyfikowalny wtedy i tylko wtedy, gdy struktura i styl wymagań pozwala na łatwe, całkowite i spójne przeprowadzanie zmian, przy zachowaniu istniejącej struktury i stylu zbioru

84 Miary jakości wymagań stawianych oprogramowaniu –możliwe do śledzenia – wymaganie jest możliwe do śledzenia wtedy i tylko wtedy, gdy pochodzenie każdego z jego wymagań składowych jest określone i jeżeli istnieje mechanizm, który umożliwia odwołanie się do tego wymagania w przyszłym procesie jego tworzenia i realizacji –możliwe do zrozumienia – zbiór wymagań jest możliwy do zrozumienia, jeżeli zarówno użytkownicy, jak i programiści są zdolni w pełni zrozumieć wymagania indywidualne oraz agregować funkcjonalność wynikającą ze zbioru wymagań

85 Techniczne metody określania wymagań 1/2 pseudokod – stanowi próbę połączenia nieformalności języka naturalnego ze ścisłą składnią i strukturami sterowania języka programowania maszyny o skończonej liczbie stanów drzewa decyzyjne – stosowane, gdy zespół ma do czynienia z wymaganiem, które dotyczy kombinacji wejść

86 Techniczne metody określania wymagań 1/2 diagramy czynności (schematy blokowe) modele związków jednostek (ERD) analiza obiektowa analiza strukturalna – diagramy przepływu danych (DFD)

87 Proces zarządzania wymaganiami Budowanie odpowiedniego systemu

88 Budowanie odpowiedniego systemu zależy bezpośrednio od ciągłego sprawdzania, czy budowane oprogramowanie zmierza we właściwym kierunku sprawdzania, czy wyniki tworzenia oprogramowania są poprawne umiejętności zarządzania zmianą podczas tworzenia oprogramowania

89 Weryfikacji oprogramowania 1/2 cechy, które zostały określone, rzeczywiście spełniają potrzeby przypadki użycia i wymagania, które pochodzą z cech, rzeczywiście je wspierają przypadki użycia są zaimplementowane w projekcie

90 Weryfikacji oprogramowania 2/2 projekt obejmuje funkcjonalne i niefunkcjonalne aspekty zachowania systemu kod rzeczywiście odpowiada projektowi oraz celom projektu testy w pełni obejmują wymagania i przypadki użycia, które zostały stworzone

91 Odwzorowywanie wymagań w projekcie i kodzie 1/2 Zdarza się, że w wymaganiach są wyrażane takie elementy, które istnieją w rzeczywistości, a nie mają swoich odpowiedników w kodzie; język wymagań i język kodu to dwa zupełnie różne języki Czasem nie można fizycznie przeprowadzić odwzorowanie wymagania w strukturze logicznej projektu; w takim przypadku w implementacji nie ma miejsca na takiego typu wymagania

92 Odwzorowywanie wymagań w projekcie i kodzie 2/2 Dla pewnych wymagań funkcjonalnych, pewna liczba elementów systemu musi być w interakcji w celu uzyskania określonej funkcjonalności; spojrzenie na pewną część to nie to samo, co spojrzenie na całość, a implementacja wymagania jest rozłożona na cały kod

93 Możliwość śledzenia - traceability Stopień ustalenia związku między co najmniej dwoma produktami procesu tworzenia, w szczególności produktów, dla których zachodzi wzajemny związek typu poprzednik-następnik lub podrzędny-nadrzędny Przykładowo, w jakim stopniu wymagania odpowiadają cechom a projektowane funkcjonalności wymaganiom

94 Jawna i niejawna możliwość śledzenia Jawna możliwość śledzenia – związki tworzące tą możliwość są ustalane przez zespół i w rzeczywistości nie muszą występować Niejawna możliwość śledzenia - taki związek możliwości śledzenia może dostarczyć sam model (dobrym przykładem są wymagania nadrzędne i podrzędne)

95 Wersja macierzowa związków możliwość śledzenia wg IBM® Rational® RequisitePro®

96

97 Zatwierdzanie poprawności systemu Proces oceniania systemu lub komponentu podczas lub na koniec procesu tworzenia w celu ustalenia, czy są spełnione określone wymagania Proces ten realizowany jest przez kompleksowe testowanie

98 Testy akceptacyjne Testy akceptacyjne z udziałem klienta potwierdzają, że produkt działa w sposób przez niego pożądany Bazują na pewnej liczbie scenariuszy określonych przez użytkownika i wykonywanych w środowisku zastosowania systemu Biorą pod uwagę również pewne czynniki środowiskowe, takie jak wewnętrzną współpracę z innymi aplikacjami

99 Zasady testowania Proces tworzenia oprogramowania musi obejmować planowanie czynności testowania Proces tworzenia musi także zapewniać czas i zasoby dla projektu testów Proces musi również zapewniać czas i zasoby do wykonania testów, zarówno na poziomie jednostki jak i całego systemu

100 Zarządzanie zmianą – powody zmian Powody związane z czynnikami zewnętrznymi –zmienił się problem –użytkownicy zmienili swoją opinię o tym, co powinien robić system, –zmieniło się środowisko zewnętrzne Powody związane z czynnikami wewnętrznymi –zespół w trakcie procesu projektowania nie objął wszystkich udziałowców lub nie zadał wszystkich pytań; zmiana pojawiła się, ponieważ niezrozumiano prawdziwych wymagań, –nie udało się stworzyć praktycznego procesu pomagającego zarządzać zmianami, np. poprzez zamrożenie wymagań, co ostatecznie sprawiło, że wszystko stało się zmianą i zespół zagubił się w szczegółach, tracąc obraz całości

101 Proces zarządzania zmianą Rozpoznanie, że zmiana jest nieunikniona, i jej zaplanowanie Utworzenie linii bazowej wymagań Ustalenie pojedynczej osoby (osób) do kontroli zmiany Użycie systemu kontroli zmiany do wykrywania zmiany Hierarchiczne zarządzanie zmianami

102 Narzędzia zarządzania wymaganiami

103 IBM® Rational® RequisitePro® IBM® Rational® RequisitePro® pozwala: –gromadzić i zarządzać wymaganiami dla systemu –śledzić skąd pochodzi żądanie umieszczenia danego wymagania w projekcie –nadawać priorytety wymaganiom oraz dodawać przydatne dla twórców i kierowników projektu informacje dotyczące trudności i względnego obciążenia dla każdego wymagania obecnego w systemie

104 IBM® Rational® RequisitePro® - konstrukcja Program jest zintegrowany z programem Microsoft® Word Dostarcza infrastrukturę bazodanową z synchronizacją odbywającą się w czasie rzeczywistym z dokumentami Worda Współpracuje z takimi bazami danych jak DB2, MS Access, MS SQL oraz Oracle

105 Okno główne

106 Definiowanie typów

107 Definiowanie ogólnych danych o wymaganiu 1/2

108 Definiowanie ogólnych danych o wymaganiu 2/2

109 Definiowanie miejsca w strukturze

110 Określanie powodów zmian

111 Tabela łącząca cechy z wymaganiami

112 System Zintegrowanego Zarządzania Wymaganiami (Integrated Requirements Management) "jpm-IRM"

113 Możliwości systemu Rejestrowanie wymagań definiowanych na etapie analizy, projektowania i zarządzania zmianami w dowolnego typu projektach Zdefiniowane wymagania przedstawiane są za pomocą drzewa wymagań Zdefiniowana w postaci drzewa hierarchia wymagań, ułatwia łatwą nawigację i wyszukiwanie wymagań

114 Możliwości systemu Tworzenie tzw. linii bazowych, w których umieszczane są zatwierdzone przez klienta wymagania, będące podstawą realizacji prac projektu Definicja wymagania obejmuje m.in. nazwę, unikalny tag, szczegółowy opis, powiązania z innymi wymaganiami, powiązania z linkami URL, powiązania z linkami do zewnętrznych dokumentów, diagramy UML bądź dowolnego typu inne diagramy Interaktywne definiowanie sprawozdań generowanych z systemu

115 Możliwości systemu Definiowanie kategorii wymagań, np.: wymagania funkcjonalne, niefunkcjonalne, formatki, przypadki testowe, etc. Kategorie wymagań jak i poszczególne wymagania, zorganizowane są w postaci drzewiastej struktury danych Wymagania definiowane są za pomocą zbioru grup atrybutów. Istnieją predefiniowane w systemie grupy atrybutów

116 Możliwości systemu Dostęp do funkcji w postaci menu i pasków narzędziowych Tworzenie projektów dla których spisywane są wymagania Mechanizm generowania raportów Wyszukiwanie wymagań Wyszukiwanie opisów Przesuwanie wymagań – jako operacja edycyjna

117

118

119

120

121 OSRMT – strona główna

122 Edycja wymagania

123 Literatura Institute of Electrical and Electronics Engineers, Inc. (IEEE), IEEE Recommended Practice for Software Requirements Specifications IEEE Std , IEEE, 1994 Leffingwell D., Widrig D., Zarządzanie wymaganiami, Wydawnictwa Naukowo- Techniczne, Warszawa, 2003


Pobierz ppt "Techniki i rozwiązania IT w optymalizacji procesów Inżynieria wymagań"

Podobne prezentacje


Reklamy Google