1 Inżynieria wymagań

2 2 Dlaczego borykamy się z poważnymi problemami wynikającymi z jakości oprogramowania Wynikają one z faktu, że obecnie stosowane oprogramowanie (aplikacje programowe) były projektowane i rozwijane z pominięciem wszelkich zasad inżynierii. Nagminny brak: –Specyfikacji wymagań, –Specyfikacji funkcjonowania systemu (przedsiębiorstwa), –Specyfikacji projektowej, –Specyfikacji testów odbiorczych oprogramowania jako produktu docelowego (końcowego), –Szkodliwego wpływu romantycznej idei Artysty Programisty.

3 3 Symptomy problemów z rozwojem oprogramowania Użytkownicy i ich potrzeby biznesowe rozmijają się Mieszanie wymagań Modułu się nie integrują System jest trudny w utrzymaniu Późne wykrywanie wad Niska jakość i niewielkie doświadczenie użytkowników Nie wystarczająca wydajność systemów Brak koordynacji wysiłków zespołu Tylko wyniki

4 4 Rozwiązanie problemów (części) Najlepsze praktyki Rozwijaj iteracyjnie Zarządzaj zmianami Używaj architektur komponentowych Modelu wizualnie (UML) Stale weryfikuj jakość Zarządzaj zmianami

5 5 Rational Unifield Process Rational Unifield Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów, oraz przykładów postępowania dla prawie wszystkich działań związanych z procesem wytwarzania oprogramowania

6 6 Problemy projektowe Symptomy Niespełnione wymagania Bałagan w wymaganiach Niedopasowane moduły Trudne utrzymanie Późno wykryte błędy Słaba jakość Słaba wydajność Konflikty deweloperów Trudności w publikacji Pierwotne przyczyny Niedostateczne wymagania Dwuznaczna komunikacja Kruche architektury Duża złożoność Niewykryte niezgodności Słabe testowanie Subiektywność ocen Niezaatakowanie ryzyka Niekontrolowane zmiany Niedostateczna automatyzacja

7 7 Iteracyjny cykl życia oprogramowania Proces iteracyjny łączy w sobie zalety modelu wodospadowego z ideą przyrostowej produkcji oprogramowania Proces opiera się na prostej idei powielenia cyklu „wodospadu” Przejście przez wodospad odbywa się wiele razy (iteracyjnie) podczas projektu W każdej fazie wykonywane są (ze zmiennym natężeniem) wszystkie czynności procesu wodospadowego Natężenie poszczególnych czynności zależy od aktualnego numeru iteracji. W pierwszych iteracjach przeważają czynności modelowania biznesowego. W następnych przeważa projektowanie, itd.

8 8 Przyrostowość cyklu iteracyjnego Wynikiem każdej iteracji jest przyrost funkcjonalności gotowego systemu W pierwszych iteracjach budowana jest funkcjonalność krytyczna z punktu widzenia jego działania Potem realizowane są pozostałe funkcje. Takie podejście znacznie zmniejsza ryzyko niepowodzenia, gdyż architektura systemu jest weryfikowana już na wstępie W podejściu iteracyjnym zestawy artefaktów dojrzewają wraz z upływem czasu

9 9 Implementacja najlepszych praktyk Technologia obiektowa pomaga zaimplementować następujące najlepsze praktyki: –Rozwijaj iteracyjnie: tolerancja zmieniających się wymagań, ciągła integracja systemu, możliwość ponownego wykorzystania elementów –Wykorzystuj architektury komponentowe: duży nacisk na definiowanie architektury, rozwój systemów z wykorzystaniem komponentów –Modeluj wizualnie: prosty sposób wprowadzania modyfikacji, prosta notacja wizualna

10 10 Dobre praktyki Początkowy projekt systemu będzie się prawdopodobnie koncentrować na grupie kluczowych wymagań Późno odkryte błędy projektowe mogą prowadzić do przekroczenia terminu oraz do przerwania projektu Czas i pieniądze poświęcone na implementację złych wymagań nie zostaną zwrócone

11 11 Zarządzanie wymaganiami Upewnij się, że: –Rozwijasz właściwy problem –Budujesz właściwy system poprze zastosowanie systematycznego podejścia do: –Zbierania –Organizowania –Dokumentowania –Zarządzania zmieniającymi się wymaganiami Twojego systemu

12 12 Specyfikacja Wymagań Systemowych (SWS) ang. System Requirements Specification Jest to sformułowany i udokumentowany zbiór wymagań stawianych przed systemem i określonych przez klienta Stanowi podstawę do budowy całego systemu

13 13 SWS Niezwykle ważny etap budowy oprogramowania Wymaga dokładnej weryfikacji i walidacji Błędy na tym etapie prowadzą w skrajnym przypadku do wytworzenia nieodpowiedniego lub niepotrzebnego oprogramowania Koszty naprawy tych błędów rosną dziesięciokrotnie wraz z każdym kolejnym etapem produkcji

14 14 SWS powinna być: Kompletna – zawierać wszystkie istotne wymagania Poprawna – nie zawierać wymagań błędnych lub sprzecznych z innymi Sukces całego projektu zależy od tego czy dobrze zrozumiemy co jest przedmiotem tego projektu i co jest od niego wymagane

15 15 Inżynieria Wymagań W przypadku ogólnym otrzymanie prawidłowej SWS zależy głównie od jakości pozyskiwania i analizy wymagań, które stanowią procesy składowe Inżynierii Wymagań (IW) (ang. Requirements Engineering) Techniki wspomagające (np. prototypowanie)

16 16 Walidacja i weryfikacja SWS Walidacja (ang. Validation) – działania mające na celu upewnienie się, że wymagania właściwie odzwierciedlają oczekiwania wszystkich istotnych udziałowców systemu. Weryfikacja (ang. Verification) – niedopuszczenie do wymagań źle wypowiedzianych, niejasnych, nieprecyzyjnych lub sprzecznych z innymi

17 17 Typowa struktura otrzymanych wymagań

18 18 Planowanie strategiczne Pozwala na określenie zakresu projektu Obejmuje: –Zidentyfikowanie niezbędnych z punktu widzenia biznesu cech systemu –Zdefiniowanie projektów dotyczących modyfikacji istniejących systemów –Ustalenie względnych priorytetów tych projektów

19 19 Planowanie strategiczne... –Zdefiniowanie celów biznesowych dla każdego projektu –Określenie harmonogramu i budżetu osiągania celów biznesowych –Zidentyfikowanie wyższych warstw zarządzających, które będą odpowiedzialne za system i które powinny wspierać projekt –Zdefiniowanie zakresu w terminach funkcji, które mają być realizowane przez system

20 20 Brak planowania strategicznego prowadzi do: Włączania do specyfikacji wymagań nadmiarowych, niepotrzebnych Wydłużania czasu projektu Przekraczania budżetu

21 21 Odpowiedzialność Klient zwykle nie jest na tyle świadomy swoich potrzeb aby samemu wyspecyfikować wszystkie wymagania na odpowiednim poziomie jakościowym Wskazana intensywna komunikacja pomiędzy dostawcą a klientem Pozostawienie SWS wyłącznie w gestii dostawcy powoduje zwykle niedostateczne uwzględnienie punktu widzenia klienta

22 22 Współpraca klient - dostawca

23 23 Uzgodnienie celu systemu Ważne by ustalić wspólny cel wszystkich członków wyższego kierownictwa (ang. senior management) Nie należy zakładać, że cel jednego z nich jest celem wcześniej uzgodnionym z pozostałymi Prawie zawsze pojawia się potrzeba negocjowania zakresu projektu z kierownictwem przyjmując za punkt startowy pewien zdefiniowany zakres strategiczny

24 24 Uzgodnienie ograniczeń systemu Prawie zawsze dotyczą budżetu i harmonogramu Analitycy muszą pilnować aby wypowiadane przez udziałowców wymagania nie spowodowały przekroczenia ograniczeń Ważna jest waga ograniczeń. Mało ważne ograniczenie nie może spowodować usunięcia z SWS istotnego wymagania Inne ograniczenia: bezpieczeństwo (safety), zabezpieczenia (security)

25 25 Punkty widzenia Każda osoba zaangażowana w projekt reprezentuje swój punkt widzenia (viewpoint) Podobnie każdy inny system lub sieć do którego budowany system ma zostać podłączony określa własne punkty widzenia i związane z nimi wymagania Udziałowiec (stokeholder) – termin określający podmiot (niekoniecznie osobę), reprezentujący punkt widzenia uwzględniany przy formułowaniu wymagań

26 26 Punkty widzenia... Jeżeli chcemy pozyskać wszystkie wymagania względem systemu, należy zidentyfikować wszystkich istotnych udziałowców i uważnie przeanalizować ich punkty widzenia

27 27 Proces pozyskiwania wymagań Obejmuje trzy etapy: –Wydobycie (capture) –Wstępna reprezentacja –Wstępna analiza Proces iteracyjny wymagający powrotów do etapu wydobywania wymagań (od udziałowców) w celu sprawdzenia czy wypowiedziane wymagania pokrywają się z intencjami danego udziałowca

28 28 Wydobywanie wymagań Przepływ informacji od udziałowców do analityków Nie jest to zagadnienie czysto techniczne dające się zrealizować przy pomocy pewnej zdefiniowanej procedury Jest to również zagadnienie psychologiczne wymagające harmonii i dobrych relacji międzyludzkich

29 29 Wydobywanie wymagań... Zdarza się, że osoba która powinna posiadać daną informację w rzeczywistości jej nie posiada Często osoba, która posiada pożądaną informację jest tego nieświadoma lub nie wie jak ją wypowiedzieć Wymaga to umiejętności przeprowadzania wywiadów, zadawania właściwych pytań, rozpoznawania kiedy przekazano właściwą informację

30 30 Wydobywanie wymagań... Wymagania względem nowego systemu ewoluują Istnieje możliwość pojawienia się nowych idei, potrzeb lub ulepszonych usług Ciągła optymalizacja SWS i dążenie do możliwie pełnej i wczesnej identyfikacji wymagań i ich niezbędnych zmian jest bardzo opłacalne

31 31 Rola analityka w wydobywaniu wymagań Doprowadzenie do sytuacji w której klient rozumie konsekwencje swoich wymagań Pomoc w odróżnieniu wymagań od sformułowań które nimi nie są (są np. cechą projektu) Zrozumienie organizacji klienta, funkcji użytkowników oraz docelowego środowiska systemu Dokładne notatki

32 32 Wstępna reprezentacja wymagań Reprezentacja – wypowiedzenie i udokumentowanie wymagań zgodnie z tym jak są one rozumiane przez analityków Umożliwia to przedstawienie wymagań udziałowcowi, od którego zostały one wydobyte, w celu ich potwierdzenia W dokumentowaniu wymagań należy użyć wszelkich środków zwiększających jasność i kompletność wypowiedzi (wszelkie diagramy)

33 33 Wstępna reprezentacja wymagań... Możliwe użycie formuł matematycznych tam gdzie będą przydatne Należy jednak pamiętać, że celem nadrzędnym wstępnej reprezentacji wymagań jest jej weryfikacja i walidacja przez udziałowca od którego wymagania zostały pobrane Wymagana odpowiednia struktura reprezentacji ułatwiająca ich wstępną analizę

34 34 Wstępna analiza wymagań Na tym etapie analiza oznacza przede wszystkim potwierdzenie, że w opinii każdego udziałowca, jego wymagania zostały wiarygodnie odzwierciedlone w wypowiedziach analityka Jest to zabieg walidacyjny, ale przeprowadzany z perspektywy danego punktu widzenia, w oderwaniu od pozostałych Na tym etapie dokonywane są korekty wymagań

35 35 Wstępna analiza wymagań... Powinna być sterowana następującymi pytaniami: –Czy to powiedziałeś? –Czy to miałeś na myśli? –Czy moja interpretacja jest poprawna? Jeżeli dwa wymagania pozostają w konflikcie, analityk powinien uświadomić ten fakt udziałowcowi Niezbędne może być wykonanie kilku iteracji tego etapu, ponieważ konfrontacja klienta z własnymi wymaganiami często powoduje powstawanie nowych

36 36 Pomoce w pozyskiwaniu wymagań Wszystkie wymienione wcześniej zabiegi wcale nie gwarantują końcowego sukcesu Prawdopodobieństwo zmian w trakcie budowy lub po jej zakończeniu jest wysokie Często możliwe funkcje i usługi jakie system może zaoferować widać dopiero w trakcie jego użytkowania Możliwe są techniki minimalizujące takie ryzyko :

37 37 Prototypowanie Polega na zbudowaniu modelu (prototypu), zazwyczaj znacznie uproszczonego, pokrywającego tylko niektóre aspekty proponowanego systemu na wczesnym etapie projektowania Możliwość zademonstrowania typowych scenariuszy współpracy z systemem

38 38 Realizacja ewolucyjna Dostarczana jest najpierw pewna część systemu, a następnie jest on rozbudowywany i zmieniany zgodnie ze specyfikacją początkową oraz z uwzględnieniem rosnących doświadczeń użytkowników Dzięki temu zmiany są dokonywane na bieżąco w trakcie budowy systemu (zmniejszenie kosztów)

39 39 Konsolidacja i redakcja wymagań W efekcie procesu pozyskiwania powstaje udokumentowana reprezentacja wymagań pochodzących od wszystkich istotnych udziałowców systemu Każdy indywidualny zbiór wymagań reprezentuje punkt widzenia danego udziałowca Każdy taki zbiór jest niezależny od pozostałych

40 40 Konsolidacja i redakcja wymagań... Zbiory te zawierają: –Sprzeczności, które muszą zostać usunięte –Nadmiarowości które muszą zostać wykryte i rozwiązane –Ograniczenia, które powinny zostać zrozumiane i głębiej wyjaśnione –Luki, które muszą zostać wypełnione –Wymagania niechciane, które muszą zostań zidentyfikowane i wyeliminowane

41 41 Konsolidacja i redakcja wymagań... Proces konsolidacji i analizy wymagań ma na celu umieszczenie wszystkich wymagań we wspólnej specyfikacji oraz pogrupowanie wymagań w ramach kategorii Pogodzenie występujących pomiędzy nimi konfliktów

42 42 Grupowanie wymagań Określone są uniwersalne kategorie wymagań –Pozwala to łatwo zrozumieć znaczenie poszczególnych grup –Nadaje to całej specyfikacji jednolitą strukturę

43 43 Wymagania funkcjonalne Określają to co system ma robić i to czego robić nie powinien (opisują funkcje tj. czynności, operacje wykonywane przez system Dotyczą rezultatów oczekiwanych przez użytkownika Najliczniejsza kategoria dlatego jej elementy są dalej kategoryzowane (interfejsy, tryby pracy...) Funkcje te mogą być również wykonywane przy użyciu systemów zewnętrznych Mogą być wyspecyfikowane w języku naturalnym lub w pewnej notacji

44 44 Wymagania niefunkcjonalne Opisują ograniczenia, przy których system ma realizować swoje funkcje Zdolność systemu do powrotu do poprzednich, poprawnych warunków działania (dostępność, niezawodność, odtwarzalność, pielęgnowalność) Zdolność systemu do uwzględniania przyszłych zmian (rozszerzalność, kompatybilność oprogramowania, przenośność)

45 45 Inne kategorie wymagań Cele biznesowe (np. ograniczenie zatrudnienia dzięki wdrożeniu systemu) Ograniczenia narzucane przez użytkownika (np. dotyczące budżetu czy terminu zakończenia projektu) Założenia (np. szacowany czas rozwoju systemu może bazować na założeniu, że tempo pracy i produktywność będą takie same jak w poprzednich przypadkach)

46 46 Inne kategorie wymagań... Wymagania polityczne (np. wdrażanie do systemu funkcji tylko dlatego, że system konkurencyjny ich nie posiada – cel propagandowy) Wymagania względem czynnika ludzkiego – wymagania dotyczące sposobów w jaki ludzie związani z systemem będą z nim współpracować. Definiują one podział zadań pomiędzy ludzi i system oraz ustalają wzajemne interfejsy

47 47 Atrybuty specyfikacji Jednoznaczność – istnieje tylko jedna jej interpretacja Kompletność – zwiera pełny zbiór wymagań klienta i każde wymaganie jest kompletnie opisane Poprawność – każde wymaganie zostało przeanalizowane i potwierdzone przez klienta

48 48 Atrybuty specyfikacji... Spójność – brak konfliktów pomiędzy poszczególnymi wymaganiami Weryfikowalność – SWS jest weryfikowalna gdy każde wymaganie jest weryfikowalne (można sprawdzić czy pracuje w systemie) Modyfikowalność – zmiany w wymaganiach mogą być wykonywane łatwo, kompletnie i spójnie

49 49

50 50 Podsumowanie Etap specyfikacji jest niewątpliwie etapem najważniejszym, ponieważ stanowi bazę do dalszych etapów projektu Etap często niedoceniany, traktowany jako coś przez co trzeba przejść, by mogła się rozpocząć „właściwa praca”