Inżynieria wymagań. Studium przypadków

Spis treści książki

• Okładka
• Strona tytułowa
• Strona redakcyjna
• Spis treści
• Od redaktorów
• Część I. Procesy i metody
  • 1. Planowanie i monitorowanie analizy
    • 1.1. Wstęp
    • 1.2. Projekt
    • 1.3. Problemy
    • 1.4. Rozwiązanie
      • 1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej
      • 1.4.2. Zaplanowanie zaangażowania interesariuszy
      • 1.4.3. Planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej
      • 1.4.4. Identyfikacja usprawnień w przebiegu analizy biznesowej
    • 1.5. Podsumowanie
  • 2. Od modelu do rozwiązania
    • 2.1. Wstęp
    • 2.2. Jak zapanować nad wymaganiami?
    • 2.3. O porażkach w projektowaniu systemów
    • 2.4. Propozycja
      • 2.4.1. Narzędzia
      • 2.4.2. Case study
      • 2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywało
      • 2.4.4. Quo vadis World
      • 2.4.5. Tworzymy system
      • 2.4.6. Model rozwiązania systemowego
      • 2.4.7. Struktura modelu wymagań
      • 2.4.8. Przepis na powiązanie elementów zależnych w EA
      • 2.4.9. Przypadki użycia
      • 2.4.10. Śledzenie zależności
      • 2.4.11. Nie wyobrażaj sobie, zobacz
      • 2.4.12. Wykonaj z nami swój prototyp
    • 2.5. THE END
  • 3. Model modelowi nierówny, czyli łamanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy
    • 3.1. Wstęp
    • 3.2. Opis przypadku
    • 3.3. Problemy i wyzwania
    • 3.4. Rozwiązanie problemu
      • 3.4.1. Wizualizacja procesu
      • 3.4.2. Model procesów podstawowych w notacji BPMN 2.0
      • 3.4.3. Proces wytwarzania wymagań
      • 3.4.4. Struktura zależności zagadnień i koncepcja zarządzania projektem
    • 3.5. Rezultat
    • 3.6. Wnioski, zalecenia i rekomendacje
  • 4. Behaviour-Driven Development jako platforma komunikacji
    • 4.1. Wprowadzenie i cel rozdziału
    • 4.2. Domena jako fundament komunikacji
      • 4.2.1. Kruszenie wiedzy domenowej własną głową
      • 4.2.2. Wspólny cel i model domenowy
    • 4.3. Język domenowy jako medium komunikacji
      • 4.3.1. Na początku był słownik
      • 4.3.2. Parafraza jako narzędzie do budowania zrozumienia
      • 4.3.3. Wpływ kultury pracy na komunikację
    • 4.4. Komunikacja w rzeczywistym środowisku
      • 4.4.1. Zmiany widzę wszędzie zmiany!
      • 4.4.2. Wyjdź zza biurka analityk w terenie
    • 4.5. Przeniesienie komunikacji na wyższy poziom
      • 4.5.1. User Story jako format zapisu wymagań
      • 4.5.2. Jednoznaczne i czytelne testy kodu źródłowego
      • 4.5.3. Wykonywalna dokumentacja jako platforma komunikacji
    • 4.6. Podsumowanie
• Część II. Produkty prac
  • 5. Dokumentacja analityczna
    • 5.1. Dokumentacja byle jaka
      • 5.1.1. Przedmiot
      • 5.1.2. Problem
      • 5.1.3. Rozwiązanie
      • 5.1.4. Zastosowane techniki
      • 5.1.5. Rezultaty
      • 5.1.6. Wnioski, zalecenia, rekomendacje
    • 5.2. Potrzebujemy tylko dokumentu
      • 5.2.1. Przedmiot
      • 5.2.2. Problem
      • 5.2.3. Rozwiązanie
      • 5.2.4. Rezultat
      • 5.2.5. Wnioski, zalecenia, rekomendacje
    • 5.3. Dużo dokumentacji, mało informacji
      • 5.3.1. Przedmiot
      • 5.3.2. Problem
      • 5.3.3. Rozwiązanie
      • 5.3.4. Rezultat
      • 5.3.5. Wnioski, zalecenia, rekomendacje
    • 5.4. Wnioski wniosków
  • 6. Czy można było jeszcze coś zepsuć?
    • 6.1. Przedmiot charakterystyka projektu/sytuacji i problemu do rozwiązania
    • 6.2. Stosowane definicje
    • 6.3. Opis zlecenia, terminy realizacji i otoczenie projektu
      • 6.3.1. Istniejąca aplikacja
      • 6.3.2. Stan udokumentowania wymagań do obsługi urządzeń
      • 6.3.3. Wiedza merytoryczna zespołu o zagadnieniu i wspieranych procesach u klienta
      • 6.3.4. Zespół
      • 6.3.5. Odpowiedzialności poszczególnych ról w zespole
      • 6.3.6. Zamawiający
    • 6.4. Przebieg procesu analizy i powstałe produkty w pierwszej fazie przed wstrzymaniem projektu
    • 6.5. Problemy, przed którymi stanęliśmy
      • 6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować
      • 6.5.2. Przeterminowane wymagania, brak właścicieli wymagań, zdefiniowanych interesariuszy
      • 6.5.3. Skupiono się na szczegółach, pominięto główne założenia
      • 6.5.4. Nie został rozpoznany proces biznesowy klienta
      • 6.5.5. Duży zakres dostarczanych usług bez podziału na etapy realizacji. Trudność estymacji pozostałych prac
      • 6.5.6. Pozostałe problemy
    • 6.6. Rozwiązanie podejścia, techniki i technologie, jakie wykorzystaliśmy w projekcie, by rozwiązać problem i zrealizować postawiony cel
      • 6.6.1. Ankiety
      • 6.6.2. Eksperci dziedzinowi, weryfikacja rozwiązań i kontakt z klientem
      • 6.6.3. Lista wymagań
      • 6.6.4. Pseudouporządkowana logika biznesowa aplikacji
      • 6.6.5. Lista usług aplikacji
      • 6.6.6. Podział na etapy i usługi dodatkowe
    • 6.7. Rezultat
    • 6.8. Wnioski, zalecenia i rekomendacje
• Część III. Zespół i umiejętności miękkie
  • 7. Janusze analityki. Czy warto być samotnym wilkiem w zespole?
    • 7.1. Wprowadzenie
    • 7.2. Samotny wilk
    • 7.3. Zespół nadchodzi z odsieczą
    • 7.4. Chaos: razem, ale osobno
    • 7.5. Konsekwencje
  • 8. Wprowadzanie Scruma problemy i korzyści
    • 8.1. Wstęp
    • 8.2. O teorii autodeterminacji
    • 8.3. Praca w Scrumie
      • 8.3.1. Samoorganizacja zespołu autonomia
      • 8.3.2. Rozwiązanie
      • 8.3.3. Sens pracy i trudność wykonywanych zadań
      • 8.3.4. Rozwiązanie
      • 8.3.5. Poczucie kompetencji ciągły rozwój
      • 8.3.6. Możliwość wpływania na produkt
      • 8.3.7. Rozwiązanie
      • 8.3.8. Relacje z innymi potrzeba przynależności
      • 8.3.9. Współpraca a rywalizujące Zosie samosie
      • 8.3.10. Rozwiązanie
      • 8.3.11. Rola relacji z użytkownikami
      • 8.3.12. Rozwiązanie
    • 8.4. Podsumowanie
  • 9. Outsourcing analizy. Jak się przygotować
    • 9.1. Przedmiot charakterystyka projektu i problemu do rozwiązania
    • 9.2. Problemy, rozwiązanie i rezultat
      • 9.2.1. Koordynacja zależności prac analitycznych
      • 9.2.2. Komunikacja w zespole
      • 9.2.3. Narzędzie CASE do modelowania
      • 9.2.4. Wspólne szablony wymagań
      • 9.2.5. Repozytorium. Gdzie przechowywać dokumenty?
      • 9.2.6. Odbiór produktów analitycznych
    • 9.3. Wnioski, zalecenia i rekomendacje
  • 10. Coaching w analizie
    • 10.1. Wstęp
      • 10.1.1. Coach i coaching
    • 10.2. Role w coachingu
      • 10.2.1. Coach
      • 10.2.2. Klient coachingu (inaczej: coachee)
      • 10.2.3. Sponsor coachingu
    • 10.3. Elementy coachingu
    • 10.4. Model coachingowy
    • 10.5. Przebieg procesu coachingowego
    • 10.6. Umiejętności coachingowe
      • 10.6.1. Aktywne słuchanie
      • 10.6.2. Pytania sięgające sedna
      • 10.6.3. Ćwiczenie
      • 10.6.4. Bezpośrednia komunikacja
      • 10.6.5. Ćwiczenie
      • 10.6.6. Obecność
      • 10.6.7. Ćwiczenie
      • 10.6.8. Tak, i 
      • 10.6.9. Ćwiczenie
    • 10.7. Podejście coachingowe
• Część IV. Ewolucja
  • 11. Projektowanie nastawione na zmianę
    • 11.1. Wstęp
    • 11.2. Ewolucja systemów informatycznych
    • 11.3. Inżynieria wymagań w kontekście ewolucji systemów
    • 11.4. Inżynieria wymagań wspierająca ewolucję systemów
      • 11.4.1. Model CoRE
      • 11.4.2. Metody statystyczne
      • 11.4.3. Przewidywanie przyszłości
      • 11.4.4. Cztery podejścia do wymagań
      • 11.4.5. Wymagania w systemach eksperckich
      • 11.4.6. Podsumowanie metod
    • 11.5. Projektowanie nastawione na zmianę
      • 11.5.1. Wiedza domenowa
      • 11.5.2. Modułowość rozwiązań
      • 11.5.3. Uniwersalne interfejsy
      • 11.5.4. Konfigurowalność
      • 11.5.5. Myślenie o przyszłości
    • 11.6. Podsumowanie
• Bibliografia
• Przypisy
• O autorach

pokaż cały spis treści

ukryj recenzje