Inżynieria wymagań w praktyce

Bartosz Chrabski, Karolina Zmitrowicz

Uzyskaj dostęp

Zakup książkę

ISBN/ISSN:

978-83-01-18049-2

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2015

Liczba stron:

384

XML:ISBN/ISSN:

ONIX MARC21

Bibliografia:

Chrabski, Bartosz; Zmitrowicz, Karolina. Inżynieria wymagań w praktyce. Red. . Warszawa: Wydawnictwo Naukowe PWN, 2015, 384 s. ISBN 978-83-01-18049-2

Bibliografia refWorks:

RT Book, Whole

SR Electronic(1)

A1 Chrabski, B.

A1 Zmitrowicz, K.

T1 Inżynieria wymagań w praktyce

PB Wydawnictwo Naukowe PWN

PP Warszawa

YR 2015

SN 978-83-01-18049-2

Bibliografia BibTex:

@Book{ 137405, author = "Chrabski, Bartosz and Zmitrowicz, Karolina", editor = "", title = "Inżynieria wymagań w praktyce", publisher = "Wydawnictwo Naukowe PWN", year = "2015", address = "Warszawa", isbn = "978-83-01-18049-2" }

Bibliografia endNote:

TY - BOOK

AU - Chrabski, Bartosz

AU - Zmitrowicz, Karolina

ED -

TI - Inżynieria wymagań w praktyce

PB - Wydawnictwo Naukowe PWN

CY - Warszawa

PY - 2015

SN - 978-83-01-18049-2

ER -

Netografia (standard APA):

Chrabski, Bartosz; Zmitrowicz, Karolina. Inżynieria wymagań w praktyce [baza danych online] Warszawa: Wydawnictwo Naukowe PWN, 2015 [dostęp: 07 05 2024]. Dostęp w Ibuk Libra: https://libra.ibuk.pl/reader/inzynieria-wymagan-w-praktyce-bartosz-chrabski-karolina-137405.

informatyka, programowanie, inżynieria, praktyka, wymagania

W ostatnich latach rośnie zainteresowanie dziedziną inżynierii wymagań i zagadnień z nią bezpośrednio związanych, takich jak modelowanie biznesowe czy zarządzanie projektem. Istniejące książki i publikacje z reguły koncentrują się na wybranych asp...

Więcej

ISBN/ISSN:

978-83-01-18049-2

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2015

Liczba stron:

384

XML:ISBN/ISSN:

ONIX MARC21

Od Autorów12
1. Wprowadzenie do inżynierii wymagań14
1.1. Wyzwania związane z projektami IT16
1.1.1. Cele i wizja17
1.1.2. Złe planowanie projektu17
1.1.3. Słaba komunikacja20
1.1.4. Złe zarządzanie oczekiwaniami interesariuszy21
1.1.5. Problemy z wymaganiami i ich zakresem22
1.1.6. Brak umiejętności miękkich23
1.1.7. Nierealistyczne oczekiwania24
1.1.8. Brak zasobów ludzkich25
1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego27
1.2. Podstawowe definicje oraz klasyfikacje28
1.2.1. Wymagania biznesowe30
1.2.2. Wymagania interesariuszy30
1.2.3. Wymagania rozwiązania31
1.2.4. Wymagania przejścia31
1.3. Atrybuty wymagań32
1.4. Kryteria jakości wymagań35
1.5. Wymagania w procesie zapewnienia jakości oprogramowania37
1.6. Inżynieria wymagań oraz jej znaczenie w projekcie38
1.7. Podstawowe role w procesie inżynierii wymagań40
1.8. Koncepcja interesariuszy41
1.9. Standardy oraz normy43
1.9.1. ISO 900044
1.9.2. ISO/IEC 25000 – Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE44
1.9.3. ISO 924144
1.9.4. ISO 31000: Risk Management45
1.9.5. IEEE 610:1990: Standard Glossary of Software Engineering Terminology45
1.9.6. IEEE 828-2012: Standard for Configuration Management in Systems and Software Engineering45
1.9.7. IEEE 830-1998: Recommended Practice for Software Requirements Specifications45
1.9.10. IEEE 29148-2011 – Systems and software engineering – Life cycle processes – Requirements engineering46
1.9.11. IEEE 1028:2008 Standard for Software Reviews and Audits46
1.9.8. IEEE 1233-1996: Guide for Developing of System Requirements Specifications46
1.9.9. IEEE 1362-1998: Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document46
1.9.12. SWEBOK: The Guide to the Software Engineering Body of Knowledge (ISO Technical Report 19759)47
1.9.13. CMMI47
1.9.14. BABOK – A Guide to the Business Analysis Body of Knowledge47
1.10. Słowniki48
2. Proces inżynierii wymagań50
2.1. Definicja procesu52
2.2. Inżynieria wymagań a analiza biznesowa57
2.3. Zasady tworzenia udanych wymagań59
2.3.1. Zrozum krytyczne cele najwyższego poziomu60
2.3.2. Koncentruj się na dostarczeniu wartości61
2.3.3. Zdefiniuj wymaganie jako „stan końcowy o wartości dla interesariusza”61
2.3.4. Wyrażaj wymagania ilościowo62
2.3.5. Nie mieszaj środków z celami64
2.3.6. Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności66
2.3.7. Zapewnij „bogatą specyfikację”66
2.3.8. Wykonuj kontrolę jakości specyfikacji69
2.3.9. Uznaj, że wymagania się zmieniają70
3. Inżynieria wymagań a inne procesy72
3.1. Zarządzanie projektem74
3.2. Zarządzanie ryzykiem78
3.3. Testowanie i zapewnienie jakości84
3.4. Wpływ wymagań na inne artefakty projektu87
4. Inżynieria wymagań w procesach tworzenia oprogramowania90
4.1. Model V jako przykład kaskadowego wytwarzania systemów92
4.2. IBM Rational Unified Process95
4.2.1. Zarządzania wymaganiami w IBM Rational Unified Process97
4.2.2. Przepływ prac dla wymagań w IBM Rational Unified Process98
4.2.3. Role i artefakty w IBM Rational Unified Process100
4.3. Zwinne metodyki w zarządzaniu wymaganiami101
4.4. Programowanie ekstremalne103
4.5. Scrum (według Scrum.org)108
4.5.1. Rejestr produktowy, czyli metoda na zorganizowanie wymagań112
4.5.2. Wyzwania związane z migracją do Scrum115
4.6. Disciplined Agile Delivery116
4.7. Przypadek biznesowy117
4.7.1. Informacja o firmie i sytuacja rynkowa117
4.7.2. Potrzeba117
4.7.3. Rozwiązanie117
4.7.4. Zyski118
5. Identyfikacja wymagań120
5.1. Źródła wymagań123
5.2. Wizja oraz cel przedsięwzięcia123
5.3. Identyfikacja interesariuszy projektu129
5.4. Techniki identyfikacji wymagań131
5.4.1. Warsztat wymagań132
5.4.2. Wywiad135
5.4.3. Ankieta – kwestionariusz139
5.4.4. Samodzielna rejestracja143
5.4.5. Reprezentant klienta po stronie dostawcy145
5.4.6. Identyfikacja na podstawie istniejących dokumentów148
5.4.7. Ponowne użycie specyfikacji151
5.4.8. Obserwacja w terenie154
5.4.9. Mentorowanie/praktykowanie157
5.4.10. Burza mózgów159
5.4.11. Prototypowanie164
5.4.12. Przypadki użycia167
5.4.13. Scenorys172
5.5. Wymagania funkcjonalne i niefunkcjonalne175
6. Analiza wymagań184
6.1. Analiza problemu biznesowego187
6.2. Oganizacja wymagań190
6.3. Powiązania i zależności między wymaganiami191
6.4. Usuwanie konfliktów i duplikatów wymagań195
6.5. Kontrola jakości199
6.6. Szacowanie wysiłku199
6.6.1. Techniki wykorzystujące algorytmy201
6.6.2. Techniki wykorzystujące przybliżenia208
6.7. Priorytetyzacja wymagań211
6.8. Modelowanie rozwiązania214
6.8.1. Model dziedziny215
6.8.2. Diagram przepływu danych (ang. Data Flow Diagram)217
6.8.3. Diagram związków encji (ang. Entity Relationship Diagram)217
6.8.4. Modelowanie interfejsu użytkownika219
6.8.5. Unified Modeling Language (UML)220
6.8.6. System Modeling Language (SysML)229
6.8.7. Inne notacje do modelowania232
6.9. Akceptacja wymagań236
7. Specyfikacja wymagań240
7.1. Pojęcie specyfikacji242
7.2. Rodzaje specyfikacji242
7.2.1. Specyfikacja wymagań243
7.2.2. Specyfikacja rozwiązania244
7.2.3. Specyfikacja techniczna246
7.3. Szablony dla specyfikacji wymagań (na podstawie IEEE 830)247
7.3.1. IEEE 830247
7.3.2. Wzorzec Volere252
7.3.3. Historie użytkownika253
7.3.4. Przypadki użycia jako sposób na wymagania funkcjonalne253
7.4. Jakość specyfikacji wymagań257
8. Zarządzanie wymaganiami260
8.1. Śledzenie wymagań262
8.2. Zarządzanie konfiguracją269
8.3. Zarządzanie zmianą272
8.4. Zarządzanie wymaganiami dotyczącymi projektu oraz systemu276
8.5. Plan zarządzania wymaganiami278
8.6. Przypadek biznesowy – wdrożenie procesu zarządzania wymaganiami279
8.6.1. Informacja o firmie i sytuacja rynkowa279
8.6.2. Potrzeba279
8.6.3. Rozwiązanie280
8.6.4. Zyski285
9. Wymagania a zarządzanie jakością288
9.1. Planowanie jakości290
9.2. Kontrola jakości296
9.2.1. Przeglądy297
9.2.2. Inspekcje305
9.2.3. Listy kontrolne308
9.3. Miary jakości wymagań310
9.4. Doskonalenie procesu312
10. Narzędzia wspierające proces inżynierii wymagań316
10.1. Narzędzia służące do zarządzania wymaganiami318
10.1.1. IBM Rational Requirements Composer318
10.1.2. Borland Caliber RM320
10.1.3. Serene Dimensions321
10.1.4. Rational DOORS (Dynamic Object Oriented Requirements System)322
10.1.5. Blueprint Requirements Center323
10.1.6. Open Source Requirements Management Tool/aNimble Platform324
10.1.7. Cechy dobrego narzędzia do zarządzania wymaganiami325
10.1.8. Wdrożenie narzędzia do zarządzania wymaganiami326
10.2. Czynniki istotne przy doborze odpowiednich narzędzi329
10.3. Narzędzia do modelowania wymagań330
10.3.1. Sparx Enterprise Architect330
10.3.2. IBM Rational Software Architect331
10.3.3. StarUML332
10.4. Narzędzia służące do modelowania procesów biznesowych333
10.4.1. Boc Group Adonis333
10.4.2. iGrafx Process334
10.4.3. BizAgi Process Modeler335
10.4.4. Rational System Architect336
10.5. Narzędzia do zarządzania konfiguracją337
10.5.1. GIT337
10.5.2. Subversion338
10.6. Narzędzia do zarządzania zmianami340
10.5.3. IBM ClearCase340
10.6.1. Atlassian Jira340
10.6.2. IBM Rational Team Concert341
10.7. Zarządzanie procesem testowania oprogramowania343
10.7.1. HP Quality Center343
10.7.2. IBM Rational Quality Manager344
10.7.3. Testia Tarantula345
10.7.4. Requirements Testing Hub346
10.7.5. TestLink347
10.8. Ryzyko związane ze złym zakupem narzędzia348
Podsumowanie350
Przypadki biznesowe354
Projekt 1 - Wdrażanie procesu inżynierii wymagań356
Informacja o firmie i sytuacja rynkowa356
Potrzeba356
Rozwiązanie357
Zyski362
Projekt 2 – Integracja narzędzi w procesie wytwarzania363
Informacja o firmie i sytuacja rynkowa363
Potrzeba363
Rozwiązanie363
Etap 1 – Integracja wymagań z procesem zarządzania testami365
Etap 2 – Integracja wymagań z zarządzaniem konfiguracją366
Etap 3 – Integracja wymagań z zarządzaniem zmianami367
Zyski369
Projekt 3 – Kontrola jakości wymagań na wczesnych etapach projektu371
Informacja o firmie i sytuacja rynkowa371
Potrzeba371
Przyczyna372
Rozwiązanie372
Skutek372
Projekt 4 – Zarządzanie wymaganiami przy użyciu historii użytkownika373
Informacja o firmie i sytuacja rynkowa373
Potrzeba373
Rozwiązanie373
Zyski374
Bibliografia376
Spis rysunków378
Spis tabel380
Indeks381

WPROWADZENIEDOINŻYNIERIIWYMAGAŃ

podstawienieprecyzyjnychwymagańsązazwyczajniemożliwedorealizacji.Brakuje

czasunawykonaniewszystkichczynnościzwiązanychzpoprawnymwytworzeniem

produktu.Jakijestskutek?PróbujesięHoszczędzić”niecoczasu,maksymalnieskra-

cającpewneetapyprocesuwytwórczego.Jakmożnasiędomyślić,zregułyskra-

casięczasprzeznaczonynaszczegółowąanalizęwymagańlub/itesty,ponieważ

wobiegowej,aczkolwiekcałkowiciebłędnejopiniiprocesytemająnajmniejsząwar-

tośćdodanądlawytworzeniaproduktu.Analizanietworzyprzecieżkodu,czyżnie?

Skracanieczasuanalizyoznaczaryzykopominięciawymagań,ważnychograni-

czeńczyregułbiznesowych,awkonsekwencji–nieprawidłowylubniepełnypro-

jektrozwiązania.Idącdalej–poważneproblemyprzyodbiorzeproduktu,ponieważ,

cojestcałkowicieuzasadnione,klientniewyrazizgodynaodbiórsystemuizapła-

tęzajegodostarczenie,jeżeliproduktniespełnijegooczekiwań.Wartododać,że

wtakimprzypadkujedynymrozsądnymrozwiązaniemjestpoprawienieproduktu

zgodniezzastrzeżeniamiklienta–czyliwprowadzeniezmianwwytworzonym,sta-

bilnymoprogramowaniu.Skutkipóźnychzmiansąoczywiste–wysokieryzykode-

stabilizacjisystemuizwiązanaznimkoniecznośćwzmożonychtestówregresyjnych

ipoprawek.

1.1.6.Brakumiejętnościmiękkich

Komunikacjawzespoleidobrzedobranekompetencjejegoczłonkówsązazwyczaj

podstawąsukcesuprzedsięwzięcia,jednakichbrakbywarównieczęstoprzyczyną

klęski.Kompetencjemiękkie,częstookreślanewogłoszeniachopracęjakoumie-

jętnośćpracyzespołowej,stanowiąpodstawędozrozumienia,dialogu,budowania

zaufaniapodczasrealizacjiprojektuoraznaetapiejegoutrzymania.

Brakumiejętnościnawiązywaniakontaktu,odpowiedniegozadawaniapytań

czywzbudzaniazaufaniamożeskutecznieutrudniaćbudowanierelacjizklientem,

awrezultacietakistotnąkomunikacjęwprojekcie.Jejzaniedbaniemożemyutożsa-

miaćzjednoczesnymodcięciemodinformacjinatemattego,codziejesięunaszego

klienta,albosposobu,wjakipostrzegaonrealizacjęsamegoprojektu.Przykładem

problemuznawiązywaniemkontaktumogąbyćzespołyhandlowe,którychpodsta-

wowymzadaniemjestposzukiwanieklientów.Jeślisprzedawcaprzykleinakompu-

terzekartkęznapisamHZadzwońdoklientajutro”,podwóchtygodniachzadanie

częstonadalniejestwykonanebokarteczkaprzecieżmówiHjutro”.Częstokierują

namilęki,odruchyiprzyzwyczajenia,wtymprzypadkustrachprzedpodniesieniem

słuchawkiikontaktemznieznanąosobą.

Kompetencjetenależywykształcić.Wzespole,któryjestsilnieukierunkowany

nazadaniatechniczne,częstoniesąonećwiczonelubwyuczone.Stałatechniczna

pracazkomputeremzamykanaswmałymświecie,wktórymkoncentrujemysięna

realizacjizadania,skutecznieodcinającsięodludzi,którzynasotaczają.Rezultatem

tegosąstereotypyinformatyków,którzygłównieprogramująlubwykonująinną

pracęnakomputerze,jednakniesąwstanienawiązaćrelacjizinnymiludźmi.

Wwielukrajachsystemedukacjinieobejmujeprzemawiania,nawiązywa-

niakontaktu,dyplomacjiczydyskusji.Polskanieodbiegapodtymwzględemod

światowejśredniej.Cierpimynatympóźniej,kiedystajemyprzedzarządemfirmy

Brak wyników

Inżynieria wymagań w praktyce

Treść książki

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