Inżynieria wymagań

-20%

Inżynieria wymagań

Studium przypadków

1 ocena

Format:

ibuk

WYBIERZ RODZAJ DOSTĘPU

 

Dostęp online przez myIBUK

WYBIERZ DŁUGOŚĆ DOSTĘPU

6,15

Wypożycz na 24h i opłać sms-em

27,6034,50

cena zawiera podatek VAT

ZAPŁAĆ SMS-EM

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.


Liczba stron268
WydawcaWydawnictwo Naukowe PWN
ISBN-13978-83-01-19505-2
Numer wydania1
Język publikacjipolski
Informacja o sprzedawcyRavelo Sp. z o.o.

TA KSIĄŻKA JEST W ABONAMENCIE

Już od 19,90 zł miesięcznie za 5 ebooków!

WYBIERZ SWÓJ ABONAMENT

INNE EBOOKI AUTORA

EBOOKI WYDAWCY

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

W celu zapewnienia wysokiej jakości świadczonych przez nas usług, nasz portal internetowy wykorzystuje informacje przechowywane w przeglądarce internetowej w formie tzw. „cookies”. Poruszając się po naszej stronie internetowej wyrażasz zgodę na wykorzystywanie przez nas „cookies”. Informacje o przechowywaniu „cookies”, warunkach ich przechowywania i uzyskiwania dostępu do nich znajdują się w Regulaminie.

Nie pokazuj więcej tego powiadomienia