X

  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
Inżynieria wymagań

SZCZEGÓŁY WYDANIA

Spis treści

Liczba stron  

268

Kategoria

Zastosowania informatyki

ISBN-13

978-83-01-19505-2

Numer wydania

1

Język publikacji

polski

Akceptowalne sposoby płatności

Karta kredytowa, przelew elektroniczny, płatny SMS

Informacja o sprzedawcy

Ravelo Sp. z o.o.

0.0 / 5 (0 głosów)
Wypożyczenie

Dostęp online przez aplikację myIBUK. Formaty plików: ibuk

X Format IBUK - ebook dostępny do wypożyczenia

- format książki elektronicznej
- bez instalowania oprogramowania, wystarczy przeglądarka internetowa oraz dostęp do Internetu,
- książka dostępna na Twojej półce w koncie myIBUK,
- dodatkowe funkcje: dodawanie notatek, tagów, zaznaczania fragmentów i cytatów,
- po pobraniu książka dostępna również bez dostępu do internetu.

Więcej informacji o formacie i wymaganiach technicznych IBUK »


od 4,92

Wypożycz teraz

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.


Sprawd? nowy abonament - to si? op?aca!
Ebook dost?pny w abonamencie
Inne ebooki autora Inne ebooki wydawcy Bestsellery w kategorii

Oceny użytkowników

Średnia ocena: ( 0 )
0
0
0
0
0
Oceń:  
Opinie użytkowników
Bądź pierwszy!