Techniki i rozwiązania IT w optymalizacji procesów

Prezentacja na temat: "Techniki i rozwiązania IT w optymalizacji procesów"— 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 90’tych w USA wydawane było ponad 250 mld USD rocznie na tworzenie aplikacji IT w blisko 175 000 różnych przedsięwzięciach Średni koszt stworzenia oprogramowania dla dużej formy ponad 2 300 000 USD dla średniej powyżej 1 300 000 USD dla małej blisko 440 000 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 system logistyki A rozliczanie usług granice dekompozycji system f-k rejestracja zamówień sterowanie serwisem granice dekompozycji klient B system f-k system logistyki

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) dopełnienie (D) dopełnienie dalsze (I) orzeczenie (V) przyimek (P) 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 Krok 1. Zmieniające się wymagania stawiane systemowi są nieuniknione, a nawet w niektórych sytuacjach wręcz konieczne. Zespół projektowy powinien być bardzo wrażliwy na zachodzące zmiany oraz powinien posiadać odpowiedni plan zarządzania zmianą. Zmiany mogą pochodzić od: udziałowców, którzy mają realną potrzebę i możliwość dodania rzeczywistej wartości do aplikacji, zespołu programistów, ponieważ zespół ten wie więcej na temat systemu niż ktokolwiek inny, realizatorów, którzy są najbliżej systemu.Dzięki zaangażowaniu tych grup w proces zarządzania zmianą można uzyskać lepszy system dla właściwych użytkowników. Krok 2. Zespół powinien określić linię bazową wszystkich znanych wymagań stawianych systemowi pod koniec etapu opracowywania cyklu tworzenia produktu. Zbiór wyszczególnionych wymagań w dokumencie: wizji, wymagań stawianych oprogramowaniu oraz modeli przypadków użycia, tworzy linię bazową informacji na temat wymagań i przewidywanych przypadków użycia dla systemu. Umożliwia to zespołowi rozróżnienie znanych lub starych wymagań od nowych i tych, które zostały dodane, usunięte lub zmodyfikowane i które można teraz odróżnić od znanych wymagań linii bazowej. Krok 3. Zmiany wprowadzane w systemie oprogramowania mogą okazać się podstępne, gdyż na początku nigdy nie wiadomo jak nowa zmiana wpłynie na już istniejącą strukturę systemu. Może eliminować lub utrudniać realizację istotnych cech. Krytycznym jest, aby każda zmiana przechodziła przez osobny kanał w celu określenia jej wpływu na system i podjęcia oficjalnej decyzji, czy dana zmiana zostanie dołączona do już istniejącego zbioru wymagań. Kanałem może być: w małych przedsięwzięciach – właściciel dokumentu wizji lub ktoś kto ma ogólne pojęcie o wymaganiach stawianych systemowi i o projekcie, w dużych systemach – kilka osób, które wspólnie ponoszą odpowiedzialność i decydują kiedy żądane zmiany będą oficjalnie zatwierdzone. Krok 4. Podczas procesu tworzenia oprogramowania występuje wiele typów potencjalnych zmian w systemie. W każdym takim przypadku jest wymagana analiza sytuacji wraz z decyzją, gdzie będzie implementowana zmiana. Zespół powinien wdrożyć system do gromadzenia wszystkich żądań zmian, który składałby się m.in. z: centralnej składnicy wszystkich żądań, automatycznego śledzenia statusu i trendu, automatycznego powiadamiania zainteresowanych stron czy mechanizmu przekazywania żądań do systemu zarządzania wymaganiami. Głównym celem działania takiego systemu byłoby zapobieganie próbom wprowadzenia do projektu niepożądanych i niekontrolowanych zmian. Krok 5. Zainteresowanie wielu osób w procesie wprowadzania zmian w wymaganiach, nie jest złe samo w sobie. Jednak mogą rodzić się pewne obawy. Fakt, że wprowadzane zmiany nie zostałyby udokumentowane czy przeanalizowane, stanowi pewien problem i jeżeli nie są one zarządzane w sposób ostrożny, może wydarzyć się coś nieoczekiwanego. Zmiana jednego wymagania może mieć katastrofalny wpływ na inne związane z nim wymagania, projekt lub podsystemy. W celu łagodzenia skutków takiego działania, zmiany wymagań powinny być przeprowadzane hierarchicznie od góry do dołu. Dzięki takiemu podejściu zmiana jest kontrolowaną sytuacją awaryjną i można z nią postępować logicznie według hierarchii. co po części może sprawić, że zmiany będą ograniczone do obszarów bezpośrednio związanych z wymaganiami, które się zmieniły.

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