"Inżynieria wymagań"

Spis treści

Od redaktorów 10

CZĘŚĆ I. PROCESY I METODY 12

1.1. Wstęp 16

1.2. Projekt 16

1. Planowanie i monitorowanie analizy 16

1.3. Problemy 17

1.4. Rozwiązanie 17

1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej 18

1.4.2. Zaplanowanie zaangażowania interesariuszy 27

1.4.3. Planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej 28

1.4.4. Identyfikacja usprawnień w przebiegu analizy biznesowej 30

1.5. Podsumowanie 33

2.1. Wstęp 34

2.2. Jak zapanować nad wymaganiami? 34

2. Od modelu do rozwiązania 34

2.3. O porażkach w projektowaniu systemów 36

2.4. Propozycja 36

2.4.1. Narzędzia 37

2.4.2. Case study 37

2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywało 38

2.4.4. Quo vadis World 42

2.4.5. Tworzymy system 43

2.4.6. Model rozwiązania systemowego 49

2.4.7. Struktura modelu wymagań 49

2.4.8. Przepis na powiązanie elementów zależnych w EA 53

2.4.9. Przypadki użycia 58

2.4.10. Śledzenie zależności 65

2.4.11. Nie wyobrażaj sobie, zobacz 68

2.4.12. Wykonaj z nami swój prototyp 69

2.5. THE END 72

3.1. Wstęp 74

3. Model modelowi nierówny, czyli łamanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy 74

3.2. Opis przypadku 76

3.3. Problemy i wyzwania 77

3.4. Rozwiązanie problemu 78

3.4.1. Wizualizacja procesu 78

3.4.2. Model procesów podstawowych w notacji BPMN 2.0 80

3.4.3. Proces wytwarzania wymagań 81

3.4.4. Struktura zależności zagadnień i koncepcja zarządzania projektem 88

3.5. Rezultat 89

3.6. Wnioski, zalecenia i rekomendacje 92

4.1. Wprowadzenie i cel rozdziału 94

4. Behaviour-Driven Development jako platforma komunikacji 94

4.2. Domena jako fundament komunikacji 95

4.2.1. Kruszenie wiedzy domenowej własną głową 95

4.3. Język domenowy jako medium komunikacji 97

4.2.2. Wspólny cel i model domenowy 97

4.3.1. Na początku był słownik… 97

4.3.2. Parafraza jako narzędzie do budowania zrozumienia 99

4.3.3. Wpływ kultury pracy na komunikację 99

4.4. Komunikacja w rzeczywistym środowisku 100

4.4.1. Zmiany widzę – wszędzie zmiany! 100

4.4.2. Wyjdź zza biurka – analityk w terenie 101

4.5. Przeniesienie komunikacji na wyższy poziom 105

4.5.1. User Story jako format zapisu wymagań 105

4.5.2. Jednoznaczne i czytelne testy kodu źródłowego 106

4.5.3. Wykonywalna dokumentacja jako platforma komunikacji 108

4.6. Podsumowanie 109

CZĘŚĆ II. PRODUKTY PRAC 110

5.1. Dokumentacja byle jaka 112

5. Dokumentacja analityczna 112

5.1.1. Przedmiot 112

5.1.2. Problem 113

5.1.3. Rozwiązanie 115

5.1.4. Zastosowane techniki 116

5.1.5. Rezultaty 121

5.1.6. Wnioski, zalecenia, rekomendacje 123

5.2. Potrzebujemy tylko dokumentu 124

5.2.1. Przedmiot 124

5.2.2. Problem 126

5.2.3. Rozwiązanie 126

5.2.4. Rezultat 127

5.2.5. Wnioski, zalecenia, rekomendacje 127

5.3. Dużo dokumentacji, mało informacji 130

5.3.1. Przedmiot 130

5.3.2. Problem 130

5.3.3. Rozwiązanie 136

5.3.4. Rezultat 137

5.3.5. Wnioski, zalecenia, rekomendacje 137

5.4. Wnioski wniosków 139

6.1. Przedmiot – charakterystyka projektu/sytuacji i problemu do rozwiązania 140

6.2. Stosowane definicje 140

6. Czy można było jeszcze coś zepsuć? 140

6.3. Opis zlecenia, terminy realizacji i otoczenie projektu 141

6.3.1. Istniejąca aplikacja 142

6.3.2. Stan udokumentowania wymagań do obsługi urządzeń 142

6.3.3. Wiedza merytoryczna zespołu o zagadnieniu i wspieranych procesach u klienta 143

6.3.4. Zespół 143

6.4. Przebieg procesu analizy i powstałe produkty w pierwszej fazie przed wstrzymaniem projektu 144

6.3.5. Odpowiedzialności poszczególnych ról w zespole 144

6.3.6. Zamawiający 144

6.5. Problemy, przed którymi stanęliśmy 146

6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować 146

6.5.2. Przeterminowane wymagania, brak właścicieli wymagań, zdefiniowanych interesariuszy 147

6.5.3. Skupiono się na szczegółach, pominięto główne założenia 147

6.5.4. Nie został rozpoznany proces biznesowy klienta 148

6.5.5. Duży zakres dostarczanych usług bez podziału na etapy realizacji. Trudność estymacji pozostałych prac 148

6.6. Rozwiązanie – podejścia, techniki i technologie, jakie wykorzystaliśmy w projekcie, by rozwiązać problem i zrealizować postawiony cel 149

6.5.6. Pozostałe problemy 149

6.6.1. Ankiety 150

6.6.2. Eksperci dziedzinowi, weryfikacja rozwiązań i kontakt z klientem 151

6.6.3. Lista wymagań 151

6.6.4. Pseudouporządkowana logika biznesowa aplikacji 152

6.6.5. Lista usług aplikacji 152

6.7. Rezultat 154

6.6.6. Podział na etapy i usługi dodatkowe 154

6.8. Wnioski, zalecenia i rekomendacje 155

CZĘŚĆ III. ZESPÓŁ I UMIEJĘTNOŚCI MIĘKKIE 158

7.1. Wprowadzenie 162

7. Janusze analityki. Czy warto być samotnym wilkiem w zespole? 162

7.2. Samotny wilk 163

7.3. Zespół nadchodzi z odsieczą 164

7.4. Chaos: razem, ale osobno 166

7.5. Konsekwencje 168

8.1. Wstęp 170

8. Wprowadzanie Scruma – problemy i korzyści 170

8.2. O teorii autodeterminacji 172

8.3. Praca w Scrumie 177

8.3.1. Samoorganizacja zespołu – autonomia 177

8.3.2. Rozwiązanie 178

8.3.3. Sens pracy i trudność wykonywanych zadań 179

8.3.4. Rozwiązanie 180

8.3.5. Poczucie kompetencji – ciągły rozwój 180

8.3.6. Możliwość wpływania na produkt 182

8.3.7. Rozwiązanie 184

8.3.8. Relacje z innymi – potrzeba przynależności 184

8.3.9. Współpraca a rywalizujące Zosie samosie 185

8.3.10. Rozwiązanie 186

8.3.11. Rola relacji z użytkownikami 187

8.3.12. Rozwiązanie 188

8.4. Podsumowanie 189

9.1. Przedmiot – charakterystyka projektu i problemu do rozwiązania 190

9. Outsourcing analizy. Jak się przygotować 190

9.2. Problemy, rozwiązanie i rezultat 193

9.2.1. Koordynacja zależności prac analitycznych 193

9.2.2. Komunikacja w zespole 193

9.2.3. Narzędzie CASE do modelowania 195

9.2.4. Wspólne szablony wymagań 196

9.2.5. Repozytorium. Gdzie przechowywać dokumenty? 197

9.3. Wnioski, zalecenia i rekomendacje 198

9.2.6. Odbiór produktów analitycznych 198

10.1. Wstęp 200

10. Coaching w analizie 200

10.1.1. Coach i coaching 201

10.2. Role w coachingu 202

10.3. Elementy coachingu 202

10.2.1. Coach 202

10.2.2. Klient coachingu (inaczej: coachee) 202

10.2.3. Sponsor coachingu 202

10.4. Model coachingowy 203

10.5. Przebieg procesu coachingowego 213

10.6. Umiejętności coachingowe 216

10.6.1. Aktywne słuchanie 216

10.6.2. Pytania sięgające sedna 217

10.6.3. Ćwiczenie 217

10.6.4. Bezpośrednia komunikacja 218

10.6.5. Ćwiczenie 218

10.6.6. Obecność 218

10.6.7. Ćwiczenie 218

10.6.8. Tak, i… 219

10.6.9. Ćwiczenie 219

10.7. Podejście coachingowe 220

CZEŚĆ IV. EWOLUCJA 232

11.1. Wstęp 234

11. Projektowanie nastawione na zmianę 234

11.2. Ewolucja systemów informatycznych 235

11.3. Inżynieria wymagań w kontekście ewolucji systemów 238

11.4. Inżynieria wymagań wspierająca ewolucję systemów 239

11.4.1. Model CoRE 239

11.4.2. Metody statystyczne 242

11.4.3. Przewidywanie przyszłości 243

11.4.4. Cztery podejścia do wymagań 243

11.4.5. Wymagania w systemach eksperckich 246

11.4.6. Podsumowanie metod 246

11.5. Projektowanie nastawione na zmianę 247

11.5.1. Wiedza domenowa 248

11.5.2. Modułowość rozwiązań 248

11.5.3. Uniwersalne interfejsy 250

11.5.4. Konfigurowalność 251

11.6. Podsumowanie 255

11.5.5. Myślenie o przyszłości 255

Bibliografia 257

O autorach 259