Inynieria wymaga Jolanta Sala Halina Taska Olsztyn 2019

Inżynieria wymagań Jolanta Sala Halina Tańska Olsztyn 2019

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. 2

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 3

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

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 5

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 6

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. 7

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 8

Implementacja najlepszych praktyk • Technologia obiektowa pomaga zaimplementować 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 9

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 10

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

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 12

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 13

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 14

Inżynieria Wymagań (IW) • 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ń (ang. Requirements Engineering) • Techniki wspomagające (np. prototypowanie) 15

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 16

Typowa struktura otrzymanych wymagań 17

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 18

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 19

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

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 21

Współpraca klient - dostawca 22

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 23

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 może spowodować usunięcia z SWS istotnego wymagania • Inne ograniczenia: bezpieczeństwo (safety), zabezpieczenia (security) 24

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ń 25

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 26

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 27

Wydobywanie wymagań 1 z 3 • 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 28

Wydobywanie wymagań. . . 2 z 3 • 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ę 29

Wydobywanie wymagań. . . 3 z 3 • 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 30

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 31

Wstępna reprezentacja wymagań 1 z 2 • 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) 32

Wstępna reprezentacja wymagań. . . 2 z 2 • 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ę 33

Wstępna analiza wymagań 1 z 2 • 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ń 34

Wstępna analiza wymagań. . . 2 z 2 • 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 35

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 36

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 37

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) 38

Konsolidacja i redakcja wymagań 1 z 3 • 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 39

Konsolidacja i redakcja wymagań. . . 2 z 3 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 40

Konsolidacja i redakcja wymagań. . . 3 z 3 • 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 41

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

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 43

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ść) 44

Inne kategorie wymagań 1 z 2 • 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) 45

Inne kategorie wymagań. . . 2 z 2 • 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 46

Atrybuty specyfikacji 1 z 2 • 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 47

Atrybuty specyfikacji. . . 2 z 2 • 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 48

49

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” 50