Inżynieria wymagań
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.
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 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ł na etapy i usługi dodatkowe 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, ale 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ść wykonywanych 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. Elementy 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. Wymagania 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
