1 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

2  Poprawienie błędu jest o wiele kosztowniejsze po zaimplementowaniu systemu niż podczas opracowywania wymagań, zatem wykrycie błędów w specyfikacji wymagań, pozwoli zaoszczędzić czas i pieniądze  Uczestnicy projektu czasami niechętnie poświęcają czas na ocenianie i testowanie wymagań, uważając że to opóźni wdrożenie i oddanie produktu, a w rzeczywistości taka inwestycja może skrócić harmonogram dzięki ograniczeniu liczby wymaganych poprawek i przyspieszeniu integracji i testów systemu  Na etapie prac nad wymaganiami nie ma możliwości wykonania żadnych testów, ponieważ jeszcze nie istnieje działające oprogramowanie, ale bazujące na wymaganiach testy konceptualne (czyli niezależne od implementacji) pozwalają wykrywać błędy, wieloznaczności oraz braki w wymaganiach i modelach, zanim zespół przystąpi do pisania kodu. 2

3 3  Model V uwzględnia wczesne planowanie i projektowanie testów - czynności związane z testowaniem występują równolegle z odpowiadającymi im aktywnościami programistycznymi

4  Weryfikacja wymagań to sprawdzenie czy produkt będący wynikiem prowadzonych prac jest zgodny z wymaganiami, czyli czy robi coś tak, jak powinien.  Walidacja wymagań to sprawdzenie czy produkt spełnia potrzeby klienta, czyli czy robi to, co powinien (odniesienie do celów biznesowych). 4

5 Czynności związane z walidacją wymagań mają na celu zagwarantowanie, że: ◦ wymagania dokładnie opisują oczekiwane możliwości i właściwości systemu, które zaspokoją rozmaite potrzeby interesariuszy, ◦ wymagania zostały prawidłowo wywiedzione z wymagań biznesowych, wymagań systemowych, reguł biznesowych oraz innych źródeł, ◦ wymagania są pełne, wykonalne i weryfikowalne, ◦ wszystkie wymagania są niezbędne, a ich zbiór pozwoli w pełni osiągnąć cele biznesowe, ◦ poszczególne deklaracje wymagań nie są ze sobą sprzeczne, ◦ wymagania zapewniają wystarczającą podstawę do rozpoczęcia projektowania i konstruowania systemu. 5

6  Przeglądy wymagań to wydajna technika identyfikowania wieloznacznych lub nieweryfikowalnych wymagań, wymagań, które zostały zdefiniowane tak nieczytelnie, że nie można na ich podstawie rozpocząć projektowania  Przeglądy nieformalne – sprawdzają się podczas szukania rażących błędów, niespójności oraz luk, ale brakuje im systematyczności i spójności ◦ Sprawdzanie biurkowe – autor prosi kolegę aby przyjrzał się produktowi ◦ Podawanie dalej – autor prosi kilku kolegów aby jednocześnie sprawdzili jego produkt ◦ Obchód – autor opisuje produkt i prosi o komentarze na jego temat  Przeglądy formalne ◦ Formalne przeglądy koleżeńskie – zdefiniowany proces, którego efektem jest lista defektów oraz problemów ◦ Inspekcja – jedna z technik walidacji wymagań przynosząca najlepsze efekty 6

7  Inspekcji można poddawać dowolny efekt pracy, w tym wymagania, dokumenty projektowe, kod źródłowy, dokumentację testową oraz plany projektu.  Inspekcja to dobrze zdefiniowany wieloetapowy proces, w którym uczestniczy niewielka grupa osób, które uważnie sprawdzają produkt pod względem obecności defektów oraz okazji do ulepszeń  Uczestnicy inspekcji powinni reprezentować cztery różne perspektywy: ◦ Autor produktu, będącego przedmiotem inspekcji ◦ Osoby, które udzieliły informacji na temat elementu będącego przedmiotem inspekcji (np. przedstawiciel użytkowników, mistrz produktu) ◦ Osoby, które będą pracowały z wykorzystaniem elementu będącego przedmiotem inspekcji (programiści, testerzy, kierownik projektu, autor dokumentacji) ◦ Osoby odpowiedzialne za interfejsy systemu, na które będzie miał wpływ element będący przedmiotem inspekcji 7

8 Niektórzy z członków zespołu inspekcyjnego mogą odgrywać podczas inspekcji określone role:  Autor – przyjmuje pozycję pasywną, słucha komentarzy, odpowiada na pytania i myśli  Moderator – wspólnie z autorem planuje inspekcję, koordynuje przebieg spotkania, przed spotkaniem rozsyła uczestnikom materiały, w trakcie spotkania zachęca do aktywności, zapobiega rozpraszaniu uwagi i koncentracji na nieistotnych detalach, po spotkaniu wspólnie z autorem sprawdza proponowane zmiany  Lektor – jeden z inspektorów, który wyraża swoimi słowami wymagania i elementy poddane inspekcji; inni uczestnicy wskazują potencjalne defekty i problemy; przy mniej formalnych inspekcjach rola ta jest pełniona przez moderatora  Protokolant – dokumentuje omawiane kwestie oraz stwierdzone defekty i na koniec spotkania odczytuje je lub wyświetla w celu uzyskania potwierdzenia ich trafności 8

9 9

10  Kryteria początkowe: poprawność ogólna dokumentu, numeracja, moderator nie znalazł więcej niż 3 poważne defekty podczas 10-minutowego sprawdzania fragmentu dokumentu  Planowanie  Przygotowanie  Spotkanie inspekcyjne  Poprawki  Wnioski  Kryteria końcowe: omówiono wszystkie kwestie zgłoszone podczas inspekcji, poprawnie wprowadzono wszelkie zmiany dotyczące wymagań, omówiono wszystkie otwarte kwestie lub udokumentowano związane z nimi procesy decyzyjne, docelowe dane oraz ich właścicieli. 10

11  Planowanie ◦ Autor z moderatorem planują - kto ma wziąć udział w inspekcji, jakie materiały trzeba rozesłać, ile czasu zarezerwować i na kiedy wyznaczyć termin spotkania; określają również tempo inspekcji (powinno ono zależeć m. in. od: ilości tekstu na każdej stronie specyfikacji, złożoności wymagań, doświadczenia autora specyfikacji) 11  Przygotowanie ◦ Autor przedstawia inspektorom podstawowe informacje dotyczące wymagań, aby zrozumieli kontekst dokumentów poddawanych inspekcji i poznali cele jakie chce osiągnąć autor podczas inspekcji, a każdy inspektor powinien przeanalizować produkt w poszukiwaniu ewentualnych defektów, co usprawni przebieg spotkania

12  Spotkanie inspekcyjne ◦ Lektor odczytuje dokument, opisując własnymi słowami każde wymaganie, po czym każdy z inspektorów zgłasza ewentualne defekty oraz inne problemy, a protokolant wpisuje je na listę czynności do wykonania, którą otrzyma autor wymagań; spotkanie inspekcyjne nie powinno trwać dłużej niż dwie godziny, gdyż znużeni ludzie nie będą skutecznymi inspektorami ◦ Po analizie materiału zespół decyduje, czy przyjmie dokument wymagań w jego obecnej postaci, zaakceptuje go po wprowadzeniu drobnych poprawek, czy może zaleci dokonanie poważniejszych korekt  Poprawki ◦ Po spotkaniu inspekcyjnym autor wymagań powinien być gotowy do poświęcenia dodatkowego czasu na skorygowanie wymagań  Wnioski ◦ Finałowy etap inspekcji, na którym moderator współpracuje z autorem w celu zagwarantowania, że wszystkie otwarte kwestie zostały rozwiązane, a błędy naprawione (może się bowiem okazać, że niektóre z poprawek nie zostały wykonane w pełni lub że przeprowadzono je nieprawidłowo, co prowadzi do kolejnych korekt) 12

13 13

14  Obszerne dokumenty wymagań ◦ Przeglądy przyrostowe ◦ Przypisanie różnym recenzentom różnych części dokumentu ◦ Przeglądy formalne dla obszarów podwyższonego ryzyka i nieformalne dla materiału o niskim ryzyku  Duże zespoły inspekcyjne ◦ Każdy uczestnik inspekcji musi być po to, żeby szukać defektów ◦ Co najwyżej jeden reprezentant każdego punktu widzenia ◦ Organizacja mniejszych grup inspekcyjnych  Recenzenci w różnych lokalizacjach geograficznych ◦ Wykorzystanie wideokonferencji i przeglądy dokumentów elektronicznych znajdujących się we współdzielonym repozytorium i ich edycja w trybie recenzji 14

15  Testy są skutecznym narzędziem służącym zarówno do walidacji, jak i weryfikacji wymagań ◦ Już samo projektowanie testów pozwala ujawnić wiele problemów związanych z wymaganiami na długo przed uruchomieniem tych testów na funkcjonującym oprogramowaniu ◦ Pisanie testów funkcjonalnych umożliwia skrystalizowanie wyobrażeń dotyczących działania systemu w określonych warunkach  Testy powinny pokrywać przebiegi normalne każdego przypadku użycia, przepływy alternatywne oraz wyjątki zidentyfikowane podczas pozyskiwania i analizy 15

16  Kryteria akceptacji definiują minimum warunków, które powinny być spełnione, aby aplikację można było uznać za gotową do użycia. Kryteria akceptacji muszą także obejmować wymagania pozafunkcjonalne  Kryteria akceptacji powinny być konkretne, mierzalne, osiągalne, odpowiednie i formułowane we właściwym czasie  Testy akceptacyjne powinny weryfikować, czy produkt jest zgodny z udokumentowanymi wymaganiami i czy nadaje się do użycia w środowisku roboczym ◦ Skłonienie użytkowników do obmyślenia testów akceptacyjnych w znaczącym stopniu przyczyni się do efektywnego opracowania wymagań  Testy akceptacyjne powinny być skonfigurowane z wykorzystaniem wiarygodnych danych testowych 16

17 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

18 18

19 W kontekście zarządzania zmianami należy ustalić następujące kwestie:  narzędzia i techniki do przyjęcia w celu rozróżniania wersji poszczególnych wymagań oraz ich zbiorów  sposób, w jaki zbiory wymagań są zatwierdzane i przekształcane w bazę odniesienia  sposoby proponowania, oceniania, negocjowania i komunikowania nowych wymagań oraz zmian w wymaganiach istniejących  metody oceniania wpływu wywieranego przez proponowane zmiany  procedury związane z atrybutami i śledzeniem wymagań, w tym definicje statusów wymagań oraz wskazanie osób, które mogą je zmieniać,  metody efektywnego korzystania z narzędzi do zarządzania wymaganiami 19

20  Kontrolowanie wersji umożliwia jednoznaczną identyfikację wersji różnych elementów, najczęściej występujących w postaci dokumentów  Proces kontrolowania wersji należy rozpocząć zaraz po sporządzeniu wstępnych wersji wymagań lub dokumentów, dzięki czemu zachowana zostanie historia zmian, jakie były w nich wprowadzane  Aby ograniczyć nieład i nieporozumienia, aktualizacje wymagań powinny być przeprowadzane wyłącznie przez wyznaczone osoby, a identyfikator wersji powinien być zmieniany po każdej aktualizacji  Najbardziej niezawodną metodą prowadzenia kontroli wersji jest przechowywanie wymagań w narzędziu do zarządzania wymaganiami, które śledzą historię wprowadzanych zmian; umożliwiają też dodawanie komentarzy opisujących przesłanki kryjące się za dodaniem, modyfikacją lub usunięciem wymagania  Najprostszy sposób kontrolowania wersji polega na ręcznym oznaczaniu każdej wersji dokumentu zgodnie z przyjętą konwencją 20

21  Obok opisu każde wymaganie powinno być uzupełnione o pewne informacje - atrybuty, które będą z nimi skojarzone; takie atrybuty udostępniają kontekst i tło każdego z wymagań  Wartości atrybutów można przechowywać w dokumencie, arkuszu kalkulacyjnym, bazie danych albo w narzędziu do zarządzania wymaganiami, co jest najskuteczniejszym rozwiązaniem  Przykładowe, często występujące atrybuty wymagań: ◦ data utworzenia wymagania, ◦ bieżący numer wersji wymagania, ◦ autor wymagania, ◦ priorytet, ◦ status, ◦ pochodzenie lub źródło wymagania, ◦ przesłanka stojąca za wymaganiem, ◦ numer wydania lub iteracji, do którego (której) jest przypisane wymaganie, ◦ interesariusz, do którego należy kierować pytania lub który podejmuje decyzje dotyczące proponowanych zmian, ◦ metoda walidacji lub kryteria akceptacji wymagania. 21

22  Status jest jednym z atrybutów wymagań  Śledzenie statusu polega na porównaniu miejsca, do którego dotarły w danym momencie prace nad projektem, z tym, co oznacza „ukończony” w odniesieniu do danego cyklu rozwoju produktu  Śledzenie statusu każdego wymagania funkcjonalnego stanowi dokładniejszą miarę postępów dokonywanych w pracach nad projektem  Możliwe do stosowania statusy wymagań: ◦ Zaproponowane ◦ W trakcie ◦ Wstępne ◦ Zatwierdzone ◦ Zaimplementowane ◦ Zweryfikowane ◦ Odłożone ◦ Usunięte ◦ Odrzucone 22

23 23

24 24

25  Stosowanie narzędzi do śledzenia problemów dają następujące korzyści: ◦ gromadzone są problemy stwierdzone podczas przeglądów różnych wymagań, dzięki czemu żaden z nich nie zostanie pominięty, ◦ menedżer projektu łatwo może sprawdzać bieżący status każdego z problemów, ◦ każdy problem może zostać przypisany jednemu właścicielowi, ◦ istnieje możliwość dotarcia do historii dyskusji prowadzonych na temat danego problemu, ◦ znając zbiór otwartych kwestii, zespół może zacząć swoje prace wcześniej, bez konieczności czekania na skompletowanie dokumentu SRS 25

26  Mierzenie nakładów pracy – rejestrowanie codziennych czynności różnych członków zespołu  Należy rejestrować czas poświęcony na następujące czynności związane z wymaganiami ◦ planowanie związanych z wymaganiami czynności, które będą wykonywane na potrzeby projektu, ◦ prowadzenie warsztatów i wywiadów, analizowanie dokumentów oraz wykonywanie pozostałych czynności mających związek z pozyskiwaniem wymagań, ◦ pisanie specyfikacji wymagań, tworzenie modeli analitycznych i nadawanie priorytetów wymaganiom, ◦ tworzenie i badanie prototypów wspomagających opracowywanie wymagań, ◦ ocenianie wymagań i wykonywanie innych czynności walidacyjnych 26

27  Należy również rejestrować czas poświęcony na czynności związane z zarządzaniem wymaganiami ◦ konfigurowanie narzędzia do zarządzania wymaganiami na potrzeby projektu, ◦ zgłaszanie zmian w wymaganiach i proponowanie nowych wymagań, ◦ ocenianie zaproponowanych zmian, w tym przeprowadzanie analizy wpływu oraz podejmowanie decyzji, ◦ aktualizowanie repozytorium wymagań, ◦ komunikowanie zmian w wymaganiach wszystkim interesariuszom, których te zmiany dotyczą, ◦ śledzenie i raportowanie zmian statusów wymagań, ◦ tworzenie informacji dotyczących śledzenia wymagań Należy pamiętać, że czas poświęcony na czynności związane z wymaganiami jest nie tylko kosztem, ale stanowi także inwestycję. 27

28  Zmiana w oprogramowaniu nie jest niczym złym i w rzeczywistości jest niezbędna, gdyż w miarę postępu prac projektowych świat podlega zmianom — pojawiają się nowe szanse rynkowe, zmieniają się przepisy i strategie, a potrzeby biznesowe ewoluują.  Sprawne zarządzanie zmianami gwarantuje, że: ◦ proponowane zmiany w wymaganiach zostaną starannie ocenione przed podjęciem decyzji o przystąpieniu do ich realizacji, ◦ odpowiednie osoby podejmą przemyślane decyzje biznesowe dotyczące wnioskowanych zmian, ◦ czynności związane ze zmianą będą widoczne dla wszystkich interesariuszy, których one dotyczą, ◦ o zatwierdzonych zmianach będą informowani wszyscy zainteresowani uczestnicy, ◦ zmiany w wymaganiach dotyczących projektu będą wprowadzane w sposób spójny i efektywny 28

29  Jeśli interesariusze projektu nie zarządzają zmianami podczas prac nad projektem, nie będą naprawdę wiedzieć, jaki produkt zostanie oddany, co z kolei doprowadzi do powstania luki oczekiwań  Jeżeli zmiany będą wprowadzane bez uwzględnienia architektury i struktury projektu, kod może zrobić się kruchy  Niezakomunikowane zmiany wprowadzone w kodzie (dodanie lub zmodyfikowanie funkcji) mogą skomplikować procedury testowe i wymagać przeredagowania dokumentacji użytkownika  Pełzanie zakresu to zjawisko, podczas którego do projektu przyjmowane są nowe funkcje, a zasoby, harmonogramy albo cele jakościowe pozostają niezmienione 29

30 Polityka kontrolowania zmian powinna zakładać, że:  wszystkie zmiany muszą być realizowane w ramach projektu; jeśli zmiana nie jest zgłoszona zgodnie z procesem, nie będzie rozpatrzona,  w związku z niezatwierdzonymi zmianami nie zostaną przeprowadzone żadne prace oprócz sprawdzenia możliwości ich realizacji,  samo wnioskowanie zmiany nie oznacza, że zostanie ona wprowadzona; o zaimplementowaniu zmiany zdecyduje rada kontroli zmian,  treść zmiany musi być widoczna dla wszystkich uczestników projektu  dla każdej zmiany należy przeprowadzić analizę wpływu,  każda wprowadzona zmiana musi być powiązana z zatwierdzonym wnioskiem o jej dokonanie,  należy odnotować przesłanki stojące za każdym zatwierdzeniem albo odrzuceniem wniosku o dokonanie zmiany. 30

31 31

32  Cel i zakres – opis celu procesu i zakresu organizacyjnego  Role i odpowiedzialności – opis ról członków zespołu uczestniczących w procesie kontrolowania zmian i ich odpowiedzialności 32

33  Stany wnioskowanych zmian – wniosek o wprowadzenie zmiany przechodzi przez cykl zdefiniowanych stanów, które można przedstawić, korzystając z diagramu przejść stanów 33

34  Kryteria początkowe – warunek, aby wniosek o dokonanie zmiany, łącznie z wszystkimi niezbędnymi informacjami, wpłynął odpowiednim kanałem i został odpowiednio zapisany i przekazany otrzymującemu  Zadania – wykonywane w celu obsłużenia wniosku o zmianę ◦ Ocena propozycji zmiany – analiza wpływu, ryzyka i zagrożeń, kosztów zmiany ◦ Podjęcie decyzji – zatwierdzenie lub odrzucenie zmiany i nadanie priorytetu i daty implementacji ◦ Implementacja zmiany – wykonanie modyfikacji produktu wraz z aktualizacją wszystkich połączonych elementów ◦ Weryfikacja zmiany – przeglądy koleżeńskie  Kryteria końcowe – zmiana statusu wniosku na „zamknięty”, „odrzucony” lub „odwołany” i poinformowanie wszystkich interesariuszy o szczegółach zmiany 34

35 Narzędzie do kontrolowania zmian powinno:  umożliwiać definiowanie atrybutów opisujących wniosek o zmianę,  umożliwiać zaimplementowanie cyklu życia wniosku o zmianę z wieloma statusami tego wniosku,  wymuszać przestrzeganie modelu przejść stanów, dzięki czemu tylko autoryzowani użytkownicy będą mogli wprowadzać określone zmiany w statusach wniosków,  rejestrować datę każdej zmiany statusu i tożsamość osoby, która jej dokonała,  umożliwiać wysyłanie dedykowanych, automatycznych powiadomień e-mailowych, gdy zgłaszający złoży nowy wniosek lub gdy status wniosku ulegnie zmianie,  generować zarówno standardowe, jak i dedykowane raporty i wykresy 35