Opis
Inżynieria wymagań to kluczowa faza każdego projektu informatycznego. Od jej powodzenia zależy sukces całego przedsięwzięcia. Dobrze przeprowadzony proces zbierania, modelowania i zarządzania wymaganiami pozwala zredukować liczbę problemów z nimi związanych, a w rezultacie znacznie obniżyć koszty projektu. Niniejsza publikacja przedstawia doświadczenia wielu analityków biznesowych z „pierwszej linii frontu” ich walk na rzecz zapewnienia odpowiedniego poziomu jakości wymagań. Zgodnie z założeniami serii „w praktyce”, opisują oni nie tylko swoje sukcesy, ale także poniesione porażki. Spis treściOd redaktorów 9 CZĘŚĆ I. PROCESY I METODY 11 1. Planowanie i monitorowanie analizy 15 1.1. Wstęp 15 1.2. Projekt 15 1.3. Problemy 16 1.4. Rozwiązanie 16 1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej 17 1.4.2. Zaplanowanie zaangażowania interesariuszy 26 1.4.3. Planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej 27 1.4.4. Identyfikacja usprawnień w przebiegu analizy biznesowej 29 1.5. Podsumowanie 32 2. Od modelu do rozwiązania 33 2.1. Wstęp 33 2.2. Jak zapanować nad wymaganiami? 33 2.3. O porażkach w projektowaniu systemów 35 2.4. Propozycja 35 2.4.1. Narzędzia 36 2.4.2. Case study 36 2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywało 37 2.4.4. Quo vadis World 41 2.4.5. Tworzymy system 42 2.4.6. Model rozwiązania systemowego 48 2.4.7. Struktura modelu wymagań 48 2.4.8. Przepis na powiązanie elementów zależnych w EA 52 2.4.9. Przypadki użycia 57 2.4.10. Śledzenie zależności 64 2.4.11. Nie wyobrażaj sobie, zobacz 67 2.4.12. Wykonaj z nami swój prototyp 68 2.5. THE END 71 3. Model modelowi nierówny, czyli łamanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy 73 3.1. Wstęp 73 3.2. Opis przypadku 75 3.3. Problemy i wyzwania 76 3.4. Rozwiązanie problemu 77 3.4.1. Wizualizacja procesu 77 3.4.2. Model procesów podstawowych w notacji BPMN 2.0 79 3.4.3. Proces wytwarzania wymagań 80 3.4.4. Struktura zależności zagadnień i koncepcja zarządzania projektem 87 3.5. Rezultat 88 3.6. Wnioski, zalecenia i rekomendacje 91 4. Behaviour-Driven Development jako platforma komunikacji 93 4.1. Wprowadzenie i cel rozdziału 93 4.2. Domena jako fundament komunikacji 94 4.2.1. Kruszenie wiedzy domenowej własną głową 94 4.2.2. Wspólny cel i model domenowy 96 4.3. Język domenowy jako medium komunikacji 96 4.3.1. Na początku był słownik… 96 4.3.2. Parafraza jako narzędzie do budowania zrozumienia 98 4.3.3. Wpływ kultury pracy na komunikację 98 4.4. Komunikacja w rzeczywistym środowisku 99 4.4.1. Zmiany widzę – wszędzie zmiany! 99 4.4.2. Wyjdź zza biurka – analityk w terenie 100 4.5. Przeniesienie komunikacji na wyższy poziom 104 4.5.1. User Story jako format zapisu wymagań 104 4.5.2. Jednoznaczne i czytelne testy kodu źródłowego 105 4.5.3. Wykonywalna dokumentacja jako platforma komunikacji 107 4.6. Podsumowanie 108 CZĘŚĆ II. PRODUKTY PRAC 109 5. Dokumentacja analityczna 111 5.1. Dokumentacja byle jaka 111 5.1.1. Przedmiot 111 5.1.2. Problem 112 5.1.3. Rozwiązanie 114 5.1.4. Zastosowane techniki 115 5.1.5. Rezultaty 120 5.1.6. Wnioski, zalecenia, rekomendacje 122 5.2. Potrzebujemy tylko dokumentu 123 5.2.1. Przedmiot 123 5.2.2. Problem 125 5.2.3. Rozwiązanie 125 5.2.4. Rezultat 126 5.2.5. Wnioski, zalecenia, rekomendacje 126 5.3. Dużo dokumentacji, mało informacji 129 5.3.1. Przedmiot 129 5.3.2. Problem 129 5.3.3. Rozwiązanie 135 5.3.4. Rezultat 136 5.3.5. Wnioski, zalecenia, rekomendacje 136 5.4. Wnioski wniosków 138 6. Czy można było jeszcze coś zepsuć? 139 6.1. Przedmiot – charakterystyka projektu/sytuacji i problemu do rozwiązania 139 6.2. Stosowane definicje 139 6.3. Opis zlecenia, terminy realizacji i otoczenie projektu 140 6.3.1. Istniejąca aplikacja 141 6.3.2. Stan udokumentowania wymagań do obsługi urządzeń 141 6.3.3. Wiedza merytoryczna zespołu o zagadnieniu i wspieranych procesach u klienta 142 6.3.4. Zespół 142 6.3.5. Odpowiedzialności poszczególnych ról w zespole 143 6.3.6. Zamawiający 143 6.4. Przebieg procesu analizy i powstałe produkty w pierwszej fazie przed wstrzymaniem projektu 143 6.5. Problemy, przed którymi stanęliśmy 145 6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować 145 6.5.2. Przeterminowane wymagania, brak właścicieli wymagań, zdefiniowanych interesariuszy 146 6.5.3. Skupiono się na szczegółach, pominięto główne założenia 146 6.5.4. Nie został rozpoznany proces biznesowy klienta 147 6.5.5. Duży zakres dostarczanych usług bez podziału na etapy realizacji. Trudność estymacji pozostałych prac 147 6.5.6. Pozostałe problemy 148 6.6. Rozwiązanie – podejścia, techniki i technologie, jakie wykorzystaliśmy w projekcie, by rozwiązać problem i zrealizować postawiony cel 148 6.6.1. Ankiety 149 6.6.2. Eksperci dziedzinowi, weryfikacja rozwiązań i kontakt z klientem 150 6.6.3. Lista wymagań 150 6.6.4. Pseudouporządkowana logika biznesowa aplikacji 151 6.6.5. Lista usług aplikacji 151 6.6.6. Podział