Inżynieria wymagań, AZ#38A6EE0DEB/DL-ebwm/epub (Wydawnictwo Naukowe PWN)

Tytuł Inżynieria wymagań Podtytuł Studium przypadków Autorzy Karolina Zmitrowicz, Adam Roman Język polski Wydawnictwo Wydawnictwo Naukowe PWN ISBN 978-83-01-20143-2 Rok wydania 2018 Warszawa Wydanie 1 ilość stron 268 Format epub, mobi Spis treści Od 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 oczekiwaniami? 33 2.3. O porażkach w projektowaniu systemów 35 2.4. Sugestia 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. Kreujemy system 42 2.4.6. Model rozwiązania systemowego 48 2.4.7. Struktura modelu wymagań 48 2.4.8. Przepis na powiązanie części zależnych w EA 52 2.4.9. Przypadki zastosowania 57 2.4.10. Śledzenie zależności 64 2.4.11. Nie wyobrażaj sobie, sprawdź 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 producenta 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. Zaimplementowane 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, niewiele danych 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 cyklu 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 cykl 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, żeby 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ł na etapy i usługi uzupełniające 153 6.7. Rezultat 153 6.8. Wnioski, zalecenia i rekomendacje 154 CZĘŚĆ III. ZESPÓŁ I UMIEJĘTNOŚCI MIĘKKIE 157 7. Janusze analityki. Czy warto być samotnym wilkiem w zespole? 161 7.1. Wprowadzenie 161 7.2. Samotny wilk 162 7.3. Zespół nadchodzi z odsieczą 163 7.4. Chaos: razem, lecz osobno 165 7.5. Konsekwencje 167 8. Wprowadzanie Scruma – problemy i korzyści 169 8.1. Wstęp 169 8.2. O teorii autodeterminacji 171 8.3. Praca w Scrumie 176 8.3.1. Samoorganizacja zespołu – autonomia 176 8.3.2. Rozwiązanie 177 8.3.3. Sens pracy i trudność realizowanych zadań 178 8.3.4. Rozwiązanie 179 8.3.5. Poczucie kompetencji – ciągły rozwój 179 8.3.6. Możliwość wpływania na produkt 181 8.3.7. Rozwiązanie 183 8.3.8. Relacje z innymi – potrzeba przynależności 183 8.3.9. Współpraca a rywalizujące Zosie samosie 184 8.3.10. Rozwiązanie 185 8.3.11. Rola relacji z użytkownikami 186 8.3.12. Rozwiązanie 187 8.4. Podsumowanie 188 9. Outsourcing analizy. Jak się przygotować 189 9.1. Przedmiot – charakterystyka projektu i problemu do rozwiązania 189 9.2. Problemy, rozwiązanie i rezultat 192 9.2.1. Koordynacja zależności prac analitycznych 192 9.2.2. Komunikacja w zespole 192 9.2.3. Narzędzie CASE do modelowania 194 9.2.4. Wspólne szablony wymagań 195 9.2.5. Repozytorium. Gdzie przechowywać dokumenty? 196 9.2.6. Odbiór produktów analitycznych 197 9.3. Wnioski, zalecenia i rekomendacje 197 10. Coaching w analizie 199 10.1. Wstęp 199 10.1.1. Coach i coaching 200 10.2. Role w coachingu 201 10.2.1. Coach 201 10.2.2. Klient coachingu (inaczej: coachee) 201 10.2.3. Sponsor coachingu 201 10.3. Części coachingu 201 10.4. Model coachingowy 202 10.5. Przebieg procesu coachingowego 212 10.6. Umiejętności coachingowe 215 10.6.1. Aktywne słuchanie 215 10.6.2. Pytania sięgające sedna 216 10.6.3. Ćwiczenie 216 10.6.4. Bezpośrednia komunikacja 217 10.6.5. Ćwiczenie 217 10.6.6. Obecność 217 10.6.7. Ćwiczenie 217 10.6.8. Tak, i… 218 10.6.9. Ćwiczenie 218 10.7. Podejście coachingowe 219 CZEŚĆ IV. EWOLUCJA 231 11. Projektowanie nastawione na zmianę 233 11.1. Wstęp 233 11.2. Ewolucja systemów informatycznych 234 11.3. Inżynieria wymagań w kontekście ewolucji systemów 237 11.4. Inżynieria wymagań wspierająca ewolucję systemów 238 11.4.1. Model CoRE 238 11.4.2. Metody statystyczne 241 11.4.3. Przewidywanie przyszłości 242 11.4.4. Cztery podejścia do wymagań 242 11.4.5. Oczekiwania w systemach eksperckich 245 11.4.6. Podsumowanie metod 245 11.5. Projektowanie nastawione na zmianę 246 11.5.1. Wiedza domenowa 247 11.5.2. Modułowość rozwiązań 247 11.5.3. Uniwersalne interfejsy 249 11.5.4. Konfigurowalność 250 11.5.5. Myślenie o przyszłości 254 11.6. Podsumowanie 254 Bibliografia 256 O autorach 258