POLECAMY
Koszyk
Inżynieria wymagań w praktyce
Wydawca:
Format:
epub, mobi, ibuk
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 aspektach czy narzędziach inżynierii wymagań, brak jest natomiast publikacji opisujących całościowo proces inżynierii wymagań, jego kontekst w wytwarzaniu produktu, czynności i ich praktyczne zastosowanie, możliwe ryzyka i sposoby ich uniknięcia. Książka skierowana jest do osób zawodowo zajmujących się analizą biznesową i systemową, odpowiedzialnych za jakość oprogramowania i systemów oraz architektów czy kierowników projektów, jak również osób pragnących zrozumieć wyzwania związane z inżynierią wymagań i jej wzajemne zależności z innymi procesami w ogólnym procesie wytwarzania produktu.
Dowiesz się: - jak zarządzać wymaganiami w różnych projektach od formalnych po zwinne (ang.
Agile), - jak przekładać język i potrzeby biznesu na ich realizację w systemach informatycznych, - jak łatwo weryfikować możliwość realizacji wymagań przed rozpoczęciem projektu, - jak zadawać pytania klientowi, aby uniknąć problemów po zakończeniu projektu.
Powinieneś znać: - podstawowe zagadnienia inżynierii oprogramowania, - podstawowe zagadnienia zarządzania projektami informatycznymi, - realia pracy z klientami i wyzwania z tym związane.
| Rok wydania | 2015 |
|---|---|
| Liczba stron | 382 |
| Kategoria | Programowanie |
| Wydawca | Wydawnictwo Naukowe PWN |
| ISBN-13 | 978-83-01-18049-2 |
| Numer wydania | 1 |
| Język publikacji | polski |
| Informacja o sprzedawcy | ePWN sp. z o.o. |
Ciekawe propozycje
Spis treści
| Od Autorów | 11 |
| 1. Wprowadzenie do inżynierii wymagań | 13 |
| 1.1. Wyzwania związane z projektami IT | 15 |
| 1.1.1. Cele i wizja | 16 |
| 1.1.2. Złe planowanie projektu | 16 |
| 1.1.3. Słaba komunikacja | 19 |
| 1.1.4. Złe zarządzanie oczekiwaniami interesariuszy | 20 |
| 1.1.5. Problemy z wymaganiami i ich zakresem | 21 |
| 1.1.6. Brak umiejętności miękkich | 22 |
| 1.1.7. Nierealistyczne oczekiwania | 23 |
| 1.1.8. Brak zasobów ludzkich | 24 |
| 1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego | 26 |
| 1.2. Podstawowe definicje oraz klasyfikacje | 27 |
| 1.2.1. Wymagania biznesowe | 29 |
| 1.2.2. Wymagania interesariuszy | 29 |
| 1.2.3. Wymagania rozwiązania | 30 |
| 1.2.4. Wymagania przejścia | 30 |
| 1.3. Atrybuty wymagań | 31 |
| 1.4. Kryteria jakości wymagań | 34 |
| 1.5. Wymagania w procesie zapewnienia jakości oprogramowania | 36 |
| 1.6. Inżynieria wymagań oraz jej znaczenie w projekcie | 37 |
| 1.7. Podstawowe role w procesie inżynierii wymagań | 39 |
| 1.8. Koncepcja interesariuszy | 40 |
| 1.9. Standardy oraz normy | 42 |
| 1.9.1. ISO 9000 | 43 |
| 1.9.2. ISO/IEC 25000 – Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE | 43 |
| 1.9.3. ISO 9241 | 43 |
| 1.9.4. ISO 31000: Risk Management | 44 |
| 1.9.5. IEEE 610:1990: Standard Glossary of Software Engineering Terminology | 44 |
| 1.9.6. IEEE 828-2012: Standard for Configuration Management in Systems and Software Engineering | 44 |
| 1.9.7. IEEE 830-1998: Recommended Practice for Software Requirements Specifications . | 44 |
| 1.9.8. IEEE 1233-1996: Guide for Developing of System Requirements Specifications | 45 |
| 1.9.9. IEEE 1362-1998: Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document | 45 |
| 1.9.10. IEEE 29148-2011 – Systems and software engineering – Life cycle processes – Requirements engineering | 45 |
| 1.9.11. IEEE 1028:2008 Standard for Software Reviews and Audits | 45 |
| 1.9.12. SWEBOK: The Guide to the Software Engineering Body of Knowledge (ISO Technical Report 19759) | 46 |
| 1.9.13. CMMI | 46 |
| 1.9.14. BABOK – A Guide to the Business Analysis Body of Knowledge | 46 |
| 1.10. Słowniki | 47 |
| 2. Proces inżynierii wymagań | 49 |
| 2.1. Definicja procesu | 51 |
| 2.2. Inżynieria wymagań a analiza biznesowa | 56 |
| 2.3. Zasady tworzenia udanych wymagań | 58 |
| 2.3.1. Zrozum krytyczne cele najwyższego poziomu | 59 |
| 2.3.2. Koncentruj się na dostarczeniu wartości | 60 |
| 2.3.3. Zdefiniuj wymaganie jako „stan końcowy o wartości dla interesariusza” | 60 |
| 2.3.4. Wyrażaj wymagania ilościowo | 61 |
| 2.3.5. Nie mieszaj środków z celami | 63 |
| 2.3.6. Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności | 65 |
| 2.3.7. Zapewnij „bogatą specyfikację” | 65 |
| 2.3.8. Wykonuj kontrolę jakości specyfikacji | 68 |
| 2.3.9. Uznaj, że wymagania się zmieniają | 69 |
| 3. Inżynieria wymagań a inne procesy | 71 |
| 3.1. Zarządzanie projektem | 73 |
| 3.2. Zarządzanie ryzykiem | 77 |
| 3.3. Testowanie i zapewnienie jakości | 83 |
| 3.4. Wpływ wymagań na inne artefakty projektu | 86 |
| 4. Inżynieria wymagań w procesach tworzenia oprogramowania | 89 |
| 4.1. Model V jako przykład kaskadowego wytwarzania systemów | 91 |
| 4.2. IBM Rational Unified Process | 94 |
| 4.2.1. Zarządzania wymaganiami w IBM Rational Unified Process | 96 |
| 4.2.2. Przepływ prac dla wymagań w IBM Rational Unified Process | 97 |
| 4.2.3. Role i artefakty w IBM Rational Unified Process | 99 |
| 4.3. Zwinne metodyki w zarządzaniu wymaganiami | 100 |
| 4.4. Programowanie ekstremalne | 102 |
| 4.5. Scrum (według Scrum.org) | 107 |
| 4.5.1. Rejestr produktowy, czyli metoda na zorganizowanie wymagań | 111 |
| 4.5.2. Wyzwania związane z migracją do Scrum | 114 |
| 4.6. Disciplined Agile Delivery | 115 |
| 4.7. Przypadek biznesowy | 116 |
| 4.7.1. Informacja o firmie i sytuacja rynkowa | 116 |
| 4.7.2. Potrzeba | 116 |
| 4.7.3. Rozwiązanie | 116 |
| 4.7.4. Zyski | 117 |
| 5. Identyfikacja wymagań | 119 |
| 5.1. Źródła wymagań | 122 |
| 5.2. Wizja oraz cel przedsięwzięcia | 122 |
| 5.3. Identyfikacja interesariuszy projektu | 128 |
| 5.4. Techniki identyfikacji wymagań | 130 |
| 5.4.1. Warsztat wymagań | 131 |
| 5.4.2. Wywiad | 134 |
| 5.4.3. Ankieta – kwestionariusz | 138 |
| 5.4.4. Samodzielna rejestracja | 142 |
| 5.4.5. Reprezentant klienta po stronie dostawcy | 144 |
| 5.4.6. Identyfikacja na podstawie istniejących dokumentów | 147 |
| 5.4.7. Ponowne użycie specyfikacji | 150 |
| 5.4.8. Obserwacja w terenie | 153 |
| 5.4.9. Mentorowanie/praktykowanie | 156 |
| 5.4.10. Burza mózgów | 158 |
| 5.4.11. Prototypowanie | 163 |
| 5.4.12. Przypadki użycia | 166 |
| 5.4.13. Scenorys | 171 |
| 5.5. Wymagania funkcjonalne i niefunkcjonalne | 174 |
| 6. Analiza wymagań | 183 |
| 6.1. Analiza problemu biznesowego | 186 |
| 6.2. Oganizacja wymagań | 189 |
| 6.3. Powiązania i zależności między wymaganiami | 190 |
| 6.4. Usuwanie konfliktów i duplikatów wymagań | 194 |
| 6.5. Kontrola jakości | 198 |
| 6.6. Szacowanie wysiłku | 198 |
| 6.6.1. Techniki wykorzystujące algorytmy | 200 |
| 6.6.2. Techniki wykorzystujące przybliżenia | 207 |
| 6.7. Priorytetyzacja wymagań | 210 |
| 6.8. Modelowanie rozwiązania | 213 |
| 6.8.1. Model dziedziny | 214 |
| 6.8.2. Diagram przepływu danych (ang. Data Flow Diagram) | 216 |
| 6.8.3. Diagram związków encji (ang. Entity Relationship Diagram) | 216 |
| 6.8.4. Modelowanie interfejsu użytkownika | 218 |
| 6.8.5. Unified Modeling Language (UML) | 219 |
| 6.8.6. System Modeling Language (SysML) | 228 |
| 6.8.7. Inne notacje do modelowania | 231 |
| 6.9. Akceptacja wymagań | 235 |
| 7. Specyfikacja wymagań | 239 |
| 7.1. Pojęcie specyfikacji | 241 |
| 7.2. Rodzaje specyfikacji | 241 |
| 7.2.1. Specyfikacja wymagań | 242 |
| 7.2.2. Specyfikacja rozwiązania | 243 |
| 7.2.3. Specyfikacja techniczna | 245 |
| 7.3. Szablony dla specyfikacji wymagań (na podstawie IEEE 830) | 246 |
| 7.3.1. IEEE 830 | 246 |
| 7.3.2. Wzorzec Volere | 251 |
| 7.3.3. Historie użytkownika | 252 |
| 7.3.4. Przypadki użycia jako sposób na wymagania funkcjonalne | 252 |
| 7.4. Jakość specyfikacji wymagań | 256 |
| 8. Zarządzanie wymaganiami | 259 |
| 8.1. Śledzenie wymagań | 261 |
| 8.2. Zarządzanie konfiguracją | 268 |
| 8.3. Zarządzanie zmianą | 271 |
| 8.4. Zarządzanie wymaganiami dotyczącymi projektu oraz systemu | 275 |
| 8.5. Plan zarządzania wymaganiami | 277 |
| 8.6. Przypadek biznesowy – wdrożenie procesu zarządzania wymaganiami | 278 |
| 8.6.1. Informacja o firmie i sytuacja rynkowa | 278 |
| 8.6.2. Potrzeba | 278 |
| 8.6.3. Rozwiązanie | 279 |
| 8.6.4. Zyski | 284 |
| 9. Wymagania a zarządzanie jakością | 287 |
| 9.1. Planowanie jakości | 289 |
| 9.2. Kontrola jakości | 295 |
| 9.2.1. Przeglądy | 296 |
| 9.2.2. Inspekcje | 304 |
| 9.2.3. Listy kontrolne | 307 |
| 9.3. Miary jakości wymagań | 309 |
| 9.4. Doskonalenie procesu | 311 |
| 10. Narzędzia wspierające proces inżynierii wymagań | 315 |
| 10.1. Narzędzia służące do zarządzania wymaganiami | 317 |
| 10.1.1. IBM Rational Requirements Composer | 317 |
| 10.1.2. Borland Caliber RM | 319 |
| 10.1.3. Serene Dimensions | 320 |
| 10.1.4. Rational DOORS (Dynamic Object Oriented Requirements System) | 321 |
| 10.1.5. Blueprint Requirements Center | 322 |
| 10.1.6. Open Source Requirements Management Tool/aNimble Platform | 323 |
| 10.1.7. Cechy dobrego narzędzia do zarządzania wymaganiami | 324 |
| 10.1.8. Wdrożenie narzędzia do zarządzania wymaganiami | 325 |
| 10.2. Czynniki istotne przy doborze odpowiednich narzędzi | 328 |
| 10.3. Narzędzia do modelowania wymagań | 329 |
| 10.3.1. Sparx Enterprise Architect | 329 |
| 10.3.2. IBM Rational Software Architect | 330 |
| 10.3.3. StarUML | 331 |
| 10.4. Narzędzia służące do modelowania procesów biznesowych | 332 |
| 10.4.1. Boc Group Adonis | 332 |
| 10.4.2. iGrafx Process | 333 |
| 10.4.3. BizAgi Process Modeler | 334 |
| 10.4.4. Rational System Architect | 335 |
| 10.5. Narzędzia do zarządzania konfiguracją | 336 |
| 10.5.1. GIT | 336 |
| 10.5.2. Subversion | 337 |
| 10.5.3. IBM ClearCase | 339 |
| 10.6. Narzędzia do zarządzania zmianami | 339 |
| 10.6.1. Atlassian Jira | 339 |
| 10.6.2. IBM Rational Team Concert | 340 |
| 10.7. Zarządzanie procesem testowania oprogramowania | 342 |
| 10.7.1. HP Quality Center | 342 |
| 10.7.2. IBM Rational Quality Manager | 343 |
| 10.7.3. Testia Tarantula | 344 |
| 10.7.4. Requirements Testing Hub | 345 |
| 10.7.5. TestLink | 346 |
| 10.8. Ryzyko związane ze złym zakupem narzędzia | 347 |
| Podsumowanie | 349 |
| Przypadki biznesowe | 353 |
| Projekt 1 - Wdrażanie procesu inżynierii wymagań | 355 |
| Informacja o firmie i sytuacja rynkowa | 355 |
| Potrzeba | 355 |
| Rozwiązanie | 356 |
| Zyski | 361 |
| Projekt 2 – Integracja narzędzi w procesie wytwarzania | 362 |
| Informacja o firmie i sytuacja rynkowa | 362 |
| Potrzeba | 362 |
| Rozwiązanie | 362 |
| Etap 1 – Integracja wymagań z procesem zarządzania testami | 364 |
| Etap 2 – Integracja wymagań z zarządzaniem konfiguracją | 365 |
| Etap 3 – Integracja wymagań z zarządzaniem zmianami | 366 |
| Zyski | 368 |
| Projekt 3 – Kontrola jakości wymagań na wczesnych etapach projektu | 370 |
| Informacja o firmie i sytuacja rynkowa | 370 |
| Potrzeba | 370 |
| Skutek | 371 |
| Przyczyna | 371 |
| Rozwiązanie | 371 |
| Projekt 4 – Zarządzanie wymaganiami przy użyciu historii użytkownika | 372 |
| Informacja o firmie i sytuacja rynkowa | 372 |
| Potrzeba | 372 |
| Rozwiązanie | 372 |
| Zyski | 373 |
| Bibliografia | 375 |
| Spis rysunków | 377 |
| Spis tabel | 379 |
| Indeks | 380 |
KUP NA PREZENT
Inżynieria wymagań w praktyce
66,60 zł
Uzupełnij informacje na temat odbiorcy.
Produkt został pomyślnie dodany do koszyka.
Nieudana próba zakupu produktu. Spróbuj jeszcze raz.
Wypożyczaj w abonamencie!
Już od 2,66 zł za ebooka
