Inżynieria wymagań

• Kategorie:
  1. Ebooki i Audiobooki »
  2. Informatyka
  1. Ebooki i Audiobooki »
  2. Technika
• Język wydania: polski
• ISBN: 978-83-01-20143-2
• ISBN druku: 978-83-01-19505-2
• Liczba stron: 268
• Sposób dostarczenia produktu elektronicznego
  Produkty elektroniczne takie jak Ebooki czy Audiobooki są udostępniane online po uprzednim opłaceniu (PayU, BLIK) na stronie Twoje konto > Biblioteka.

  Pliki można pobrać zazwyczaj w ciągu kilku-kilkunastu minut po uzyskaniu poprawnej autoryzacji płatności, choć w przypadku niektórych publikacji elektronicznych czas oczekiwania może być nieco dłuższy.

  Sprzedaż terytorialna towarów elektronicznych jest regulowana wyłącznie ograniczeniami terytorialnymi licencji konkretnych produktów.
• Ważne informacje techniczne
• Minimalne wymagania sprzętowe:
  • procesor: architektura x86 1GHz lub odpowiedniki w pozostałych architekturach
  • Pamięć operacyjna: 512MB
  • Monitor i karta graficzna: zgodny ze standardem XGA, minimalna rozdzielczość 1024x768 16bit
  • Dysk twardy: dowolny obsługujący system operacyjny z minimalnie 100MB wolnego miejsca
  • Mysz lub inny manipulator + klawiatura
  • Karta sieciowa/modem: umożliwiająca dostęp do sieci Internet z prędkością 512kb/s
• Minimalne wymagania oprogramowania:
  • System Operacyjny: System MS Windows 95 i wyżej, Linux z X.ORG, MacOS 9 lub wyżej, najnowsze systemy mobilne: Android, iPhone, SymbianOS, Windows Mobile
  • Przeglądarka internetowa: Internet Explorer 7 lub wyżej, Opera 9 i wyżej, FireFox 2 i wyżej, Chrome 1.0 i wyżej, Safari 5
  • Przeglądarka z obsługą ciasteczek i włączoną obsługą JavaScript
  • Zalecany plugin Flash Player w wersji 10.0 lub wyżej.
• Informacja o formatach plików:
  • PDF - format polecany do czytania na laptopach oraz komputerach stacjonarnych.
  • EPUB - format pliku, który umożliwia czytanie książek elektronicznych na urządzeniach z mniejszymi ekranami (np. e-czytnik lub smartfon), dając możliwość dopasowania tekstu do wielkości urządzenia i preferencji użytkownika.
  • MOBI - format zapisu firmy Mobipocket, który można pobrać na dowolne urządzenie elektroniczne (np.e-czytnik Kindle) z zainstalowanym programem (np. MobiPocket Reader) pozwalającym czytać pliki MOBI.
  • Audiobooki w formacie MP3 - format pliku, przeznaczony do odsłuchu nagrań audio.
• Rodzaje zabezpieczeń plików:
  • Watermark - (znak wodny) to zaszyfrowana informacja o użytkowniku, który zakupił produkt. Dzięki temu łatwo jest zidentyfikować użytkownika, który rozpowszechnił produkt w sposób niezgodny z prawem.
  • Brak zabezpieczenia - część oferowanych w naszym sklepie plików nie posiada zabezpieczeń. Zazwyczaj tego typu pliki można pobierać ograniczoną ilość razy, określaną przez dostawcę publikacji elektronicznych. W przypadku zbyt dużej ilości pobrań plików na stronie WWW pojawia się stosowny komunikat.

  Więcej informacji o publikacjach elektronicznych

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