INNE EBOOKI AUTORA
Autor:
Wydawca:
Format:
epub, mobi, ibuk
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.
Rok wydania | 2018 |
---|---|
Liczba stron | 268 |
Kategoria | Zastosowania informatyki |
Wydawca | Wydawnictwo Naukowe PWN |
ISBN-13 | 978-83-01-20143-2 |
Numer wydania | 1 |
Język publikacji | polski |
Informacja o sprzedawcy | ePWN sp. z o.o. |
INNE EBOOKI AUTORA
EBOOKI WYDAWCY
POLECAMY
Ciekawe propozycje
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 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 |