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

Prezentacja na temat: "Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014."— Zapis prezentacji:

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

2  Ryzyko to sytuacja, która może spowodować straty lub w inny sposób zagrozić sukcesowi projektu. Ryzyko to jeszcze nie problem, ale przewidywana sytuacja, która może być źródłem problemu.  Zarządzanie ryzykiem to proces identyfikowania, oceniania i kontrolowania zagrożeń, zanim zaszkodzą one projektowi. Zarządzanie ryzykiem stosowane jest w celu zminimalizowania prawdopodobieństwa wystąpienia albo ograniczenia wpływu potencjalnych problemów. 2

3  Związane z wymaganiami  Zależność od zewnętrznego czynnika (podwykonawca, inny projekt)  Nieumiejętne szacowanie  Rotacja zatrudnienia  Zmiany technologii (w szczególności w zaawansowanych projektach programistycznych)  Brak wiedzy/doświadczenia zespołu wykonawczego  Ciągle zmieniające się przepisy prawa Im większy i bardziej skomplikowany projekt tym bardziej formalne i kompleksowe powinno być zarządzanie ryzykiem. 3

4 Zarządzanie ryzykiem to stosowanie narzędzi i procedur, mających na celu uwzględnienie zagrożeń w możliwych do przyjęcia granicach. Potrzebne są do tego standardowe metody, które pozwolą identyfikować oraz dokumentować czynniki ryzyka, szacować jego dotkliwość oraz proponować strategie łagodzenia jego skutków. 4

5  Szacowanie ryzyka ◦ Identyfikowanie zagrożeń – można użyć listy często spotykanych zagrożeń ◦ Analizowanie ryzyka – potencjalne skutki zagrożeń w danym projekcie ◦ Priorytetyzacja zagrożeń – skupienie na najważniejszych zagrożeniach, poprzez oszacowanie narażenia na ryzyko wystąpienia każdego z nich  Unikanie ryzyka – jeżeli tylko jest to możliwe należy unikać ryzykownych projektów, zadań  Kontrolowanie ryzyka ◦ Planowanie zarządcze – stworzenie planów opisujących postępowanie z poszczególnymi zagrożeniami – metody łagodzenia, plany awaryjne, właściciele i ramy czasowe ◦ Rozwiązywanie problemów – realizowanie opracowanych planów ◦ Monitorowanie ryzyka – śledzenie postępów w zakresie rozwiązywania problemów 5

6 6

7 7

8 8

9  Niejasna wizja produktu i pełzający zakres projektu ◦ Napisz dokument wizji i zakresu, zawierający wymagania biznesowe i wykorzystuj go przy podejmowaniu decyzji zmieniających zakres projektu  Ograniczanie czasu poświęcanego na opracowywanie wymagań ◦ Zapisuj ile faktycznie czasu zajmuje opracowywanie wymagań, żeby móc ocenić czy zaproponowana ilość czasu wystarczy  Niewystarczające zaangażowanie klienta ◦ Zidentyfikuj interesariuszy, klientów i wyznacz przedstawiciela każdej klasy użytkowników ◦ Wyznacz kluczowych interesariuszy na mistrzów produktów i pilnuj czy się wywiązują ze swoich obowiązków  Braki w kompletności i poprawności specyfikacji wymagań ◦ Zbieraj wymagania, które przekładają się na wymagania biznesowe ◦ Wymyślaj scenariusze, pisz testy, proś użytkowników, żeby definiowali własne kryteria akceptacji, twórz prototypy ◦ Zachęcaj klienta do udziału w ocenianiu wymagań i modeli 9

10  Niepewność wymagań dotyczących produktów innowacyjnych ◦ Kładź duży nacisk na badania rynkowe i tworzenie prototypów ◦ Korzystaj z grup fokusowych w celu uzyskania opinii klientów na temat wizji innowacyjnego produktu  Niedostateczne zdefiniowanie wymagań pozafunkcjonalnych ◦ Wypytaj klienta o wymagania pozafunkcjonalne, udokumentuj je i określ ich kryteria akceptacji  Brak porozumienia z klientami co do wymagań ◦ Określ kim są główni klienci, zdobądź odpowiednią reprezentację klientów (wyznaczając mistrzów produktów) i ich zaangażowanie ◦ Poproś przedstawicieli interesariuszy o ocenę wymagań  Wymagania niewyartykułowane ◦ Spróbuj zidentyfikować założenia, które mogą przyjmować klienci ◦ Zachęcaj klientów do dzielenia się swoimi przemyśleniami (spytaj np. co sprawiłoby, że odrzuciliby produkt) 10

11  Istniejące produkty w roli źródła wymagań (projekty ulepszające i zastępujące) ◦ Zastosuj inżynierię odwrotną w celu pozyskania wymagań z istniejących aplikacji  Rozwiązania przedstawiane jako potrzeby ◦ Staraj się poznać rzeczywiste intencje – wymagania użytkownika  Brak zaufania między stroną biznesową a zespołem programistycznym ◦ Staraj się zachowywać, rozmawiać i odnosić do klienta w sposób, który będzie budował zaufanie i wzajemny szacunek 11

12  Brak priorytetyzacji wymagań ◦ Upewnij się, że każde wymaganie uzyskało swój priorytet i oceniaj priorytety nowych wymagań  Technicznie trudne funkcje ◦ Oceniaj wykonalność każdego wymagania ◦ Śledź statusy wykonania poszczególnych wymagań, aby w razie potrzeby podjąć działania korygujące ◦ Twórz prototypy dla nowych, nieznanych i ryzykownych wymagań  Nieznane technologie, metody, języki, narzędzia albo sprzęt ◦ Nie bagatelizuj czasu wymaganego na zapoznanie się z nowymi technologiami i technikami potrzebnymi do realizacji wymagań ◦ Zapewnij dostateczny czas i możliwości na naukę, eksperymenty i możliwe początkowe niepowodzenia 12

13  Niewłaściwe zrozumienie wymagań ◦ Powierzaj programistom, testerom i klientom przeprowadzenie przeglądów koleżeńskich wymagań ◦ Doświadczeni analitycy biznesowi powinni napisać wysokiej jakości specyfikację ◦ Przeglądaj i analizuj modele i prototypy  Presja czasu, aby kontynuować mimo istnienia otwartych kwestii ◦ Oznaczaj kwestie pozostające do wyjaśnienia i wyznacz osobę odpowiedzialną za domknięcie otwartych kwestii i docelową datę  Niejednoznaczna terminologia ◦ Utwórz glosariusz z definicjami terminów biznesowych i technicznych, które mogą być różnie interpretowane  Projekt dołączony do wymagań ◦ Oceniaj wymagania, aby upewnić się, że nie narzucają rozwiązania, ograniczając możliwość osiągnięcia optymalnego produktu 13

14  Wymagania bez walidacji ◦ Przydziel czas i zasoby na wykonanie oceny specyfikacji wymagań i opracowanie testów ◦ Zobowiąż przedstawicieli klienta do wzięcia udziału w przeglądach wymagań  Brak biegłości w inspekcji ◦ Przeszkol wszystkich członków zespołu, którzy będą uczestniczyć w inspekcjach dokumentów wymagań ◦ Poproś doświadczonego inspektora, aby przyjrzał się wcześniejszym inspekcjom i przeszkolił uczestników 14

15  Zmiana wymagań ◦ Projektuj systemy, mając na uwadze łatwość wprowadzania w nich zmian, szczególnie gdy realizujesz je w cyklu iteracyjnym  Brak zdefiniowanego procesu zmiany wymagań ◦ Wprowadzaj zmiany zgodnie z ustalonym procesem, uwzględniającym analizę wpływu, kontrolę zmian, odpowiednie narzędzia wspomagające realizację zmian ◦ Komunikuj zmiany odpowiednim interesariuszom  Niezaimplementowane wymagania ◦ Śledź wymagania, żeby nie przeoczyć któregoś z nich na etapie projektowania, tworzenia i testowania produktu  Rozszerzanie zakresu projektu ◦ Sporządzaj plany etapowo lub w cyklu przyrostowym ◦ We wczesnych etapach implementuj funkcje o najwyższym priorytecie, a w późniejszych iteracjach rozwijaj możliwości systemu 15

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

17  Analityk biznesowy to osoba, której główną odpowiedzialnością jest pozyskiwanie, analizowanie, dokumentowanie oraz walidacja potrzeb interesariuszy projektu.  Analityk pełni funkcję głównego interpretatora, przez którego przepływają wymagania między społecznością klientów a zespołem pracującym nad oprogramowaniem.  Odgrywa on centralną rolę w gromadzeniu oraz przekazywaniu informacji o produkcie, podczas gdy menedżer projektu zajmuje się przede wszystkim informacjami dotyczącymi projektu. 17

18 18

19  Podjęcie decyzji o zaangażowaniu utalentowanego analityka może zadecydować o różnicy dzielącej projekt zakończony sukcesem od projektu borykającego się z trudnościami.  Specyfikacje pisane przez doświadczonego analityka można czytać dwukrotnie szybciej niż specyfikacje tworzone przez analityka początkującego, gdyż te pierwsze zawierają mniej defektów.  Doświadczenie i umiejętności analityka wywierają znaczący wpływ na wysokość kosztów oraz nakłady poniesione na projekt.  Analitycy o dużym doświadczeniu mogą przyczynić się do zmniejszenia o jedną trzecią łącznych nakładów związanych z projektem w porównaniu z podobnymi projektami, za które odpowiadali niedoświadczeni analitycy. 19

20  Definiowanie wymagań biznesowych  Planowanie podejścia do wymagań  Identyfikowanie interesariuszy projektu oraz klas użytkowników  Pozyskiwanie wymagań  Analizowanie wymagań  Dokumentowanie wymagań  Komunikowanie wymagań  Prowadzenie walidacji wymagań  Pomoc w priorytetyzacji wymagań  Zarządzanie wymaganiami 20

21  Umiejętność słuchania  Umiejętność rozmawiania i zadawania pytań  Umiejętność szybkiego podejmowania decyzji  Zdolności analityczne  Myślenie w kategoriach systemów  Umiejętność uczenia się  Umiejętności facylitacyjne  Zdolności przywódcze  Spostrzegawczość  Umiejętności komunikacyjne  Zdolności organizacyjne  Umiejętność tworzenia modeli  Umiejętności interpersonalne  Kreatywność 21

22 Zawód analityka wymaga kompetencji społecznych, które są w mniejszym stopniu techniczne, ale za to bardziej ukierunkowane na człowieka Skuteczny analityk biznesowy łączy w sobie wysokie umiejętności komunikacyjne oraz interpersonalne, wiedzę techniczną i związaną z dziedziną biznesu. Znajomość biznesu, branży oraz organizacji przynosi ogromne korzyści efektywnemu analitykowi biznesowemu. Analitycy rozumiejący dziedzinę organizacji oraz dziedzinę biznesową często potrafią odgadnąć niewypowiedziane potrzeby i pozostające w ukryciu wymagania. Analityk powinien także rozumieć współczesne praktyki inżynierii wymagań i wiedzieć, jak je stosować w kontekście różnych cykli tworzenia oprogramowania. Cierpliwość i autentyczna chęć do pracy z innymi ludźmi są najistotniejszymi czynnikami decydującymi o sukcesie. 22