Inżynieria wymagań

Karolina Zmitrowicz, Adam Roman

Uzyskaj dostęp

Zakup książkę

ISBN/ISSN:

978-83-01-20143-2

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2018

Liczba stron:

268

XML:ISBN/ISSN:

ONIX MARC21

Bibliografia:

Zmitrowicz, Karolina; Roman, Adam. Inżynieria wymagań. Red. . Warszawa: Wydawnictwo Naukowe PWN, 2018, 268 s. ISBN 978-83-01-20143-2

Bibliografia refWorks:

RT Book, Whole

SR Electronic(1)

A1 Zmitrowicz, K.

A1 Roman, A.

T1 Inżynieria wymagań

PB Wydawnictwo Naukowe PWN

PP Warszawa

YR 2018

SN 978-83-01-20143-2

Bibliografia BibTex:

@Book{ 187976, author = "Zmitrowicz, Karolina and Roman, Adam", editor = "", title = "Inżynieria wymagań", publisher = "Wydawnictwo Naukowe PWN", year = "2018", address = "Warszawa", isbn = "978-83-01-20143-2" }

Bibliografia endNote:

TY - BOOK

AU - Zmitrowicz, Karolina

AU - Roman, Adam

ED -

TI - Inżynieria wymagań

PB - Wydawnictwo Naukowe PWN

CY - Warszawa

PY - 2018

SN - 978-83-01-20143-2

ER -

Netografia (standard APA):

Zmitrowicz, Karolina; Roman, Adam. Inżynieria wymagań [baza danych online] Warszawa: Wydawnictwo Naukowe PWN, 2018 [dostęp: 06 05 2024]. Dostęp w Ibuk Libra: https://libra.ibuk.pl/reader/inzynieria-wymagan-karolina-zmitrowicz-adam-187976.

modelowanie, analiza, projekt, procesy biznesowe, analityk, outsourcing, coaching, wymagania, Inżynieria wymagań

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 ...

Więcej

ISBN/ISSN:

978-83-01-20143-2

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2018

Liczba stron:

268

XML:ISBN/ISSN:

ONIX MARC21

Od redaktorów10
CZĘŚĆ I. PROCESY I METODY12
1.1. Wstęp16
1.2. Projekt16
1. Planowanie i monitorowanie analizy16
1.3. Problemy17
1.4. Rozwiązanie17
1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej18
1.4.2. Zaplanowanie zaangażowania interesariuszy27
1.4.3. Planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej28
1.4.4. Identyfikacja usprawnień w przebiegu analizy biznesowej30
1.5. Podsumowanie33
2.1. Wstęp34
2.2. Jak zapanować nad wymaganiami?34
2. Od modelu do rozwiązania34
2.3. O porażkach w projektowaniu systemów36
2.4. Propozycja36
2.4.1. Narzędzia37
2.4.2. Case study37
2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywało38
2.4.4. Quo vadis World42
2.4.5. Tworzymy system43
2.4.6. Model rozwiązania systemowego49
2.4.7. Struktura modelu wymagań49
2.4.8. Przepis na powiązanie elementów zależnych w EA53
2.4.9. Przypadki użycia58
2.4.10. Śledzenie zależności65
2.4.11. Nie wyobrażaj sobie, zobacz68
2.4.12. Wykonaj z nami swój prototyp69
2.5. THE END72
3.1. Wstęp74
3. Model modelowi nierówny, czyli łamanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy74
3.2. Opis przypadku76
3.3. Problemy i wyzwania77
3.4. Rozwiązanie problemu78
3.4.1. Wizualizacja procesu78
3.4.2. Model procesów podstawowych w notacji BPMN 2.080
3.4.3. Proces wytwarzania wymagań81
3.4.4. Struktura zależności zagadnień i koncepcja zarządzania projektem88
3.5. Rezultat89
3.6. Wnioski, zalecenia i rekomendacje92
4.1. Wprowadzenie i cel rozdziału94
4. Behaviour-Driven Development jako platforma komunikacji94
4.2. Domena jako fundament komunikacji95
4.2.1. Kruszenie wiedzy domenowej własną głową95
4.3. Język domenowy jako medium komunikacji97
4.2.2. Wspólny cel i model domenowy97
4.3.1. Na początku był słownik…97
4.3.2. Parafraza jako narzędzie do budowania zrozumienia99
4.3.3. Wpływ kultury pracy na komunikację99
4.4. Komunikacja w rzeczywistym środowisku100
4.4.1. Zmiany widzę – wszędzie zmiany!100
4.4.2. Wyjdź zza biurka – analityk w terenie101
4.5. Przeniesienie komunikacji na wyższy poziom105
4.5.1. User Story jako format zapisu wymagań105
4.5.2. Jednoznaczne i czytelne testy kodu źródłowego106
4.5.3. Wykonywalna dokumentacja jako platforma komunikacji108
4.6. Podsumowanie109
CZĘŚĆ II. PRODUKTY PRAC110
5.1. Dokumentacja byle jaka112
5. Dokumentacja analityczna112
5.1.1. Przedmiot112
5.1.2. Problem113
5.1.3. Rozwiązanie115
5.1.4. Zastosowane techniki116
5.1.5. Rezultaty121
5.1.6. Wnioski, zalecenia, rekomendacje123
5.2. Potrzebujemy tylko dokumentu124
5.2.1. Przedmiot124
5.2.2. Problem126
5.2.3. Rozwiązanie126
5.2.4. Rezultat127
5.2.5. Wnioski, zalecenia, rekomendacje127
5.3. Dużo dokumentacji, mało informacji130
5.3.1. Przedmiot130
5.3.2. Problem130
5.3.3. Rozwiązanie136
5.3.4. Rezultat137
5.3.5. Wnioski, zalecenia, rekomendacje137
5.4. Wnioski wniosków139
6.1. Przedmiot – charakterystyka projektu/sytuacji i problemu do rozwiązania140
6.2. Stosowane definicje140
6. Czy można było jeszcze coś zepsuć?140
6.3. Opis zlecenia, terminy realizacji i otoczenie projektu141
6.3.1. Istniejąca aplikacja142
6.3.2. Stan udokumentowania wymagań do obsługi urządzeń142
6.3.3. Wiedza merytoryczna zespołu o zagadnieniu i wspieranych procesach u klienta143
6.3.4. Zespół143
6.4. Przebieg procesu analizy i powstałe produkty w pierwszej fazie przed wstrzymaniem projektu144
6.3.5. Odpowiedzialności poszczególnych ról w zespole144
6.3.6. Zamawiający144
6.5. Problemy, przed którymi stanęliśmy146
6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować146
6.5.2. Przeterminowane wymagania, brak właścicieli wymagań, zdefiniowanych interesariuszy147
6.5.3. Skupiono się na szczegółach, pominięto główne założenia147
6.5.4. Nie został rozpoznany proces biznesowy klienta148
6.5.5. Duży zakres dostarczanych usług bez podziału na etapy realizacji. Trudność estymacji pozostałych prac148
6.6. Rozwiązanie – podejścia, techniki i technologie, jakie wykorzystaliśmy w projekcie, by rozwiązać problem i zrealizować postawiony cel149
6.5.6. Pozostałe problemy149
6.6.1. Ankiety150
6.6.2. Eksperci dziedzinowi, weryfikacja rozwiązań i kontakt z klientem151
6.6.3. Lista wymagań151
6.6.4. Pseudouporządkowana logika biznesowa aplikacji152
6.6.5. Lista usług aplikacji152
6.7. Rezultat154
6.6.6. Podział na etapy i usługi dodatkowe154
6.8. Wnioski, zalecenia i rekomendacje155
CZĘŚĆ III. ZESPÓŁ I UMIEJĘTNOŚCI MIĘKKIE158
7.1. Wprowadzenie162
7. Janusze analityki. Czy warto być samotnym wilkiem w zespole?162
7.2. Samotny wilk163
7.3. Zespół nadchodzi z odsieczą164
7.4. Chaos: razem, ale osobno166
7.5. Konsekwencje168
8.1. Wstęp170
8. Wprowadzanie Scruma – problemy i korzyści170
8.2. O teorii autodeterminacji172
8.3. Praca w Scrumie177
8.3.1. Samoorganizacja zespołu – autonomia177
8.3.2. Rozwiązanie178
8.3.3. Sens pracy i trudność wykonywanych zadań179
8.3.4. Rozwiązanie180
8.3.5. Poczucie kompetencji – ciągły rozwój180
8.3.6. Możliwość wpływania na produkt182
8.3.7. Rozwiązanie184
8.3.8. Relacje z innymi – potrzeba przynależności184
8.3.9. Współpraca a rywalizujące Zosie samosie185
8.3.10. Rozwiązanie186
8.3.11. Rola relacji z użytkownikami187
8.3.12. Rozwiązanie188
8.4. Podsumowanie189
9.1. Przedmiot – charakterystyka projektu i problemu do rozwiązania190
9. Outsourcing analizy. Jak się przygotować190
9.2. Problemy, rozwiązanie i rezultat193
9.2.1. Koordynacja zależności prac analitycznych193
9.2.2. Komunikacja w zespole193
9.2.3. Narzędzie CASE do modelowania195
9.2.4. Wspólne szablony wymagań196
9.2.5. Repozytorium. Gdzie przechowywać dokumenty?197
9.3. Wnioski, zalecenia i rekomendacje198
9.2.6. Odbiór produktów analitycznych198
10.1. Wstęp200
10. Coaching w analizie200
10.1.1. Coach i coaching201
10.2. Role w coachingu202
10.3. Elementy coachingu202
10.2.1. Coach202
10.2.2. Klient coachingu (inaczej: coachee)202
10.2.3. Sponsor coachingu202
10.4. Model coachingowy203
10.5. Przebieg procesu coachingowego213
10.6. Umiejętności coachingowe216
10.6.1. Aktywne słuchanie216
10.6.2. Pytania sięgające sedna217
10.6.3. Ćwiczenie217
10.6.4. Bezpośrednia komunikacja218
10.6.5. Ćwiczenie218
10.6.6. Obecność218
10.6.7. Ćwiczenie218
10.6.8. Tak, i…219
10.6.9. Ćwiczenie219
10.7. Podejście coachingowe220
CZEŚĆ IV. EWOLUCJA232
11.1. Wstęp234
11. Projektowanie nastawione na zmianę234
11.2. Ewolucja systemów informatycznych235
11.3. Inżynieria wymagań w kontekście ewolucji systemów238
11.4. Inżynieria wymagań wspierająca ewolucję systemów239
11.4.1. Model CoRE239
11.4.2. Metody statystyczne242
11.4.3. Przewidywanie przyszłości243
11.4.4. Cztery podejścia do wymagań243
11.4.5. Wymagania w systemach eksperckich246
11.4.6. Podsumowanie metod246
11.5. Projektowanie nastawione na zmianę247
11.5.1. Wiedza domenowa248
11.5.2. Modułowość rozwiązań248
11.5.3. Uniwersalne interfejsy250
11.5.4. Konfigurowalność251
11.6. Podsumowanie255
11.5.5. Myślenie o przyszłości255
Bibliografia257
O autorach259

1.PLANOWANiEiMONiTOROWANiEANALiZY

łobyzastąpićobecnerozwiązania.Zakresinformacjiprzekazanychwewrześniu2017r.

obejmował:

•dokumentzdeﬁniowanyprzezNIBjakoDpróbaopisaniaplanowanegorozwiąza-

nia”,

•terminprzekazaniainformacjihandlowejzszacunkowąwyceną-listopad2017r.

21września2017r.opiekunhandlowyklientaprzekazałinformacjęopotrzebieuru-

chomieniaanalizydotyczącejopisanegowyżejprojektu.

1.3.

Problemy

Intencjaklientabyłaoczywista.ZamierzeniemNIB-ubyłoosiągnięciewzałożonymczasie

określonegowzrostuprzychodów,akluczemmiałobyćpodniesieniejakościusługświad-

czonychprzezNIB.Natomiastpytanie,naktórenależałodopieroodpowiedzieć,brzmiało:

jakmawyglądaćrozwiązanie,którypozwolitencelosiągnąć?

Dokonującporównaniaróżnychprojektów,możnadostrzec,żetypowymitrudno-

ściami,zktórymiprzychodzizmierzyćsięprzyplanowaniupodejściadoanalizy,sąszerokie

izmiennezakresyprojektóworazdziałaniewnarzuconymrygorzeczasowym.Niesąto

oczywiścieproblemy,którewystępująwkażdymprojekcie.Jeżelijednakplanowaniedotyczy

projektuzłożonego,unikalnegoipodatnegonazmianę,wskazanejestwykorzystaniepodej-

ściaempirycznego2.Wtakimprzypadkuplanowanieanalizyopierasięnaregularnymiodpo-

wiednioczęstymsprawdzaniuzałożonegoprzebieguanalizywceluzapewnieniaiteracyjnego

rozwijaniaplanu,jakrównieżodpowiednioszybkiejkorektypodejmowanychdziałań.

1.4.

Rozwiązanie

Prezentacjazastosowanegowomawianymprojekciepodejściadoplanowaniaimonito-

rowaniaanalizybyłabyniepełna,gdybyograniczyćjądoprzedstawieniaprzyjętegoplanu.

Obszarplanowaniaanalizyjestnieustanniepoddawanyusprawnieniom.Innymisłowy,

przyjętyplanreprezentujeto,cowedlebieżącegostanuwiedzyjestnajlepszymrozwią-

zaniem.Relacjonującprzebiegprocesupojegozakończeniu,zwyklewiadomo,comożna

byłozrobićinaczej.Stwierdzenie,żenieistniejeplananalizy,któregoniemożnabyzrobić

lepiej,motywujedogromadzeniazaleceńdowykorzystaniawprzyszłości.Ztegopowodu

planowanieanalizyjestwykonywaneindywidualniedlakażdegoprojektu,zzachowaniem

wypracowanychstandardów.Standardysąopartenadobrychpraktykachiwiedzywyni-

kającychzdotychczasowychdoświadczeń.Dobrepraktyki,doktórychodnosisiętreść

rozdziału,toprzedewszystkimzasóbwiedzy,jakimjestGuidetotheBusinessAnalysis

BodyofKnowledge®(BABOK®Guidev3)3zawierającyzbiórpraktykanalitycznychreko-

2KenSchwaber,MikeBeedle,AgileSoftwareDevelopmentwithScrum,UpperSaddleRiver,Pren-

ticeHall,2002,ISBN0-13-067634-9.OgunnaikeBabatundeA.,HarmonRayW.,ProcessDynamics.

ModelingandControl,OxfordUniversityPress,1994.

3InternationalInstituteofBusinessAnalysis,https://www.iiba.org/babok-guide.aspx(dostęp:

27.12.2016).

Brak wyników

Inżynieria wymagań

Treść książki

Znajdź bibliotekę blisko siebie, i uzyskaj dostęp do ebooka w systemie IBUK Libra