Halina Tańska
Inżynieria wymagań
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),
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
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
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
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
Pierwotne przyczyny
• Niedostateczne wymagania
• Dwuznaczna komunikacja
• Kruche architektury
• Duża złożoność
• Niewykryte niezgodności
• Słabe testowanie
• Subiektywność ocen
• Niezaatakowanie ryzyka
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
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
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
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
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
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
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
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
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)
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
Typowa struktura otrzymanych wymagań
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
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
Brak planowania strategicznego prowadzi do:
• Włączania do specyfikacji wymagań nadmiarowych, niepotrzebnych
• Wydłużania czasu projektu
• Przekraczania budżetu
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
Współpraca klient - dostawca
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
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 ),
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
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
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
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
1 z 3
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ę
2 z 3
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
3 z 3
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
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
1 z 2
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ę
2 z 2
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ń
1 z 2
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
2 z 2
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
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
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)
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
1 z 3
Konsolidacja i redakcja wymagań ...
• 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
Zbiory te zawierają:
2 z 3
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
3 z 3
Grupowanie wymagań
• Określone są uniwersalne kategorie wymagań – Pozwala to łatwo zrozumieć znaczenie
poszczególnych grup
– Nadaje to całej specyfikacji jednolitą strukturę
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
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ść)
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
1 z 2
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ą
2 z 2
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
1 z 2
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
2 z 2
custom model w ymagań
w ymagania funkcj onalne + Dodawanie uczestników w ymagania niefunkcj onalne
+ Kopiowanie danych osobowych + Wgląd do haseł przez Administratora
Zarządzanie ofertą szkoleń Zarządzanie trenerami Dodawanie uczestników
Rejestrowanie szkolenia Powiadamianie uczestników
Przypisz uczestnika do
szkolenia
Wprow adź dane uczestnika
Przej rzyj listę uczestników przypisanych do
szkolenia
Modyfikuj upraw nienia
Kopiowanie danych osobowych
Wgląd do haseł przez
Administratora
Modyfikuj ofertę szkoleń
Rej estruj Trenera
Modyfikuj szkolenie z ofertą szkoleń
Usuń
«extend»
