Inżynieria oprogramowania

Krzysztof Sacha

Uzyskaj dostęp

Zakup książkę

ISBN/ISSN:

978-83-01-16179-8

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2010

Liczba stron:

426

XML:ISBN/ISSN:

ONIX MARC21

Bibliografia:

Sacha, Krzysztof. Inżynieria oprogramowania. Red. . Warszawa: Wydawnictwo Naukowe PWN, 2010, 426 s. ISBN 978-83-01-16179-8

Bibliografia refWorks:

RT Book, Whole

SR Electronic(1)

A1 Sacha, K.

T1 Inżynieria oprogramowania

PB Wydawnictwo Naukowe PWN

PP Warszawa

YR 2010

SN 978-83-01-16179-8

Bibliografia BibTex:

@Book{ 1761, author = "Sacha, Krzysztof", editor = "", title = "Inżynieria oprogramowania", publisher = "Wydawnictwo Naukowe PWN", year = "2010", address = "Warszawa", isbn = "978-83-01-16179-8" }

Bibliografia endNote:

TY - BOOK

AU - Sacha, Krzysztof

ED -

TI - Inżynieria oprogramowania

PB - Wydawnictwo Naukowe PWN

CY - Warszawa

PY - 2010

SN - 978-83-01-16179-8

ER -

Netografia (standard APA):

Sacha, Krzysztof. Inżynieria oprogramowania [baza danych online] Warszawa: Wydawnictwo Naukowe PWN, 2010 [dostęp: 27 06 2024]. Dostęp w Ibuk Libra: https://libra.ibuk.pl/reader/inzynieria-oprogramowania-krzysztof-sacha-1761.

informatyka, programowanie

Książka jest nowoczesnym podręcznikiem inżynierii oprogramowania. Obejmuje wszystkie etapy wytwarzania oprogramowania: od określenia wymagań, poprzez proces wytwórczy, aż po konserwację produktu. Łączy ścisły opis działań analitycznych zmierzający...

Więcej

ISBN/ISSN:

978-83-01-16179-8

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2010

Liczba stron:

426

XML:ISBN/ISSN:

ONIX MARC21

Przedmowa8
Część I. Procesy i metody14
1. Wprowadzenie14
1.1. Proces rozwoju systemu informatycznego16
1.2. Określenie wymagań20
1.3. Wytwarzanie oprogramowania22
1.3.1. Procesy24
1.3.2. Metody31
1.4. Weryfikacja i zatwierdzanie34
1.5. Inżynieria oprogramowania38
1.5.1. Raport Chaos39
1.5.2. Polski rynek IT41
1.6. Historia i kierunki rozwoju44
2. Inżynieria wymagań51
2.1. Klasyfikacja wymagań52
2.1.1. Zakres wymagań52
2.1.2. Poziomy opisu wymagań55
2.2. Proces określania wymagań58
2.2.1. Analiza SWOT59
2.2.2. Studium wykonalności63
2.2.3. Przygotowanie wykonania projektu65
2.3. Pozyskiwanie i dokumentowanie wymagań67
2.3.1. Metody pozyskiwania wymagań68
2.3.2. Specyfikacja wymagań69
2.4. Prototypowanie (prototyping)72
2.5. Zarządzanie wymaganiami75
2.6. Uwagi bibliograficzne77
3. Metody strukturalne80
3.1. Narzędzia modelowania81
3.1.1. Hierarchia funkcji81
3.1.2. Diagram przepływu danych83
3.1.3. Diagram encji86
3.1.4. Schemat struktury88
3.2. Techniki analizy strategicznej90
3.2.1. Modelowanie przetwarzania91
3.2.2. Modelowanie danych94
3.2.3. Schemat kontekstu97
3.3. Techniki analizy strukturalnej99
3.3.1. Budowa modelu fizycznego100
3.3.2. Budowa modelu logicznego104
3.3.3. Modelowanie danych107
3.3.4. Budowa nowego modelu fizycznego109
3.4. Techniki projektowania aplikacji111
3.4.1. Projektowanie struktury programu112
3.4.2. Projektowanie bazy danych115
3.4.3. Projektowanie interfejsu użytkownika118
3.4.4. Technologie wspomagające120
3.5. Uwagi bibliograficzne121
4. Metody obiektowe124
4.1. Narzędzia modelowania125
4.1.1. Model przypadków użycia127
4.1.2. Diagram klas133
4.2. Modelowanie procesów biznesowych141
4.2.1. Narzędzia modelowania142
4.2.2. Budowa modelu145
4.3. Modelowanie wymagań użytkownika151
4.3.1. Budowa modelu biznesowego154
4.3.2. Budowa modelu systemowego156
4.3.3. Reguły biznesowe161
4.4. Modelowanie dziedziny162
4.4.1. Narzędzia modelowania162
4.4.2. Modelowanie struktury166
4.4.3. Modelowanie zachowania169
4.5. Projektowanie oprogramowania171
4.5.1. Narzędzia modelowania struktury172
4.5.2. Narzędzia modelowania współdziałania176
4.5.3. Projektowanie architektury oprogramowania179
4.5.4. Projektowanie programów184
4.6. Technologie obiektowe196
4.6.1. Architektura warstwowa197
4.6.2. Projektowanie architektury oprogramowania199
4.6.3. Projektowanie programów204
4.7. Proces RUP210
4.7.1. Faza rozpoczęcia212
4.7.2. Faza opracowania214
4.7.3. Faza konstrukcji216
4.7.4. Faza przekazania217
4.8. Uwagi bibliograficzne218
5. Testowanie oprogramowania221
5.1. Poziomy testowania222
5.2. Organizacja procesu testowania227
5.2.1. Planowanie testów227
5.2.2. Przygotowanie testów229
5.2.3. Testowanie a usuwanie defektów232
5.3. Metryki233
5.3.1. Metryki pokrycia kodu234
5.3.2. Metryki pokrycia wymagań237
5.3.3. Inne metryki238
5.4. Metody testowania241
5.4.1. Testowanie czarnej skrzynki242
5.4.2. Testowanie białej skrzynki245
5.5. Automatyzacja testowania247
5.6. Uwagi bibliograficzne252
Część II. Zarządzanie projektami256
6. Zarządzanie projektem informatycznym256
6.1. Struktura organizacyjna projektu257
6.1.1. Schemat struktury organizacyjnej257
6.1.2. Projekty zamawiane260
6.2. Planowanie projektu262
6.2.1. Określenie podziału pracy263
6.2.2. Tworzenie harmonogramu268
6.2.3. Plan projektu273
6.3. Planowanie kosztów275
6.3.1. Heurystyczne metody szacowania276
6.3.2. Analityczne metody szacowania278
6.3.3. Tworzenie budżetu288
6.4. Zarządzanie przebiegiem projektu289
6.4.1. Kontrola postępów290
6.4.2. Działania korekcyjne291
6.5. Zarządzanie ryzykiem295
6.6. Metoda PRINCE2299
6.7. Uwagi bibliograficzne303
7. Zarządzanie jakością306
7.1. Jakość oprogramowania (ISO 9126)307
7.1.1. Model jakości308
7.1.2. Metryki jakości310
7.2. System zarządzania jakością313
7.2.1. Kompleksowe zarządzanie jakością (TQM)314
7.2.2. Norma ISO 9001315
7.2.3. Model CMMI319
7.3. Metody zapewnienia jakości320
7.3.1. Standardy321
7.3.2. Przeglądy i inspekcje324
7.3.3. Projektowanie metryk jakości (GQM)326
7.4. Plan zapewnienia jakości331
7.5. Uwagi bibliograficzne333
8. Metodyka zwinna335
8.1. Planowanie wydania336
8.2. Iteracja projektu339
8.2.1. Planowanie iteracji340
8.2.2. Wykonanie iteracji342
8.3. Zasady344
8.3.1. Reguły tworzenia kodu344
8.3.2. Metody pracy346
8.3.3. Manifest zwinności347
8.4. Praktyki zwinne348
8.5. Uwagi końcowe349
9. Konserwacja oprogramowania351
9.1. Struktura konserwacji352
9.2. Proces konserwacji354
9.2.1. Procedura kontroli zmian355
9.2.2. Norma IEEE 1219356
9.3. Inżynieria odwrotna358
9.4. Systemy odziedziczone361
9.4.1. Opakowanie363
9.4.2. Korporacyjna szyna usług364
9.5. Uwagi bibliograficzne365
10. Systemy krytyczne367
10.1. Wymagania368
10.2. Analiza bezpieczeństwa372
10.3. Projektowanie strukturalne377
10.3.1. Proces projektowy377
10.3.2. Budowa modelu funkcjonalnego379
10.3.3. Budowa modelu implementacyjnego383
10.4. Automatyczna generacja programów388
10.5. Uwagi bibliograficzne394
Bibliografia395
Indeks411

1.Wprowadzenie

Dlazilustrowaniazłożonościproblemuokreśleniawymagańrozważmyponow-

nieoprogramowaniesystemuwspierającegodziałaniebanku,opisanegonapoczątku

tegorozdziału.Czegoodtegosystemużądamy?

SCzymajedynieprowadzićkontaklientów,którzylokująswojeśrodkiwban-

ku,czytakżeobsługiwaćkredytyudzielaneklientom,którzykontawtym

bankuniemają?

SJeżelimaobsługiwaćkredyty,towjakimzakresie:czytylkokontroliiksię-

gowaniaspłacanychratkredytu,czytakżeocenyryzykakredytowegoiauto-

matyzacjiobsługiwnioskówkredytowych?

SJakmaprzebiegaćprocesprzyznaniakredytuinapodstawiejakichdanych

mazapaśćdecyzja?Czyoprzyznaniukredytumadecydowaćsystem,czy

pracownikbanku?

SJakmabyćnaliczaneoprocentowaniekontikredytów–tygodniowo,mie-

sięcznie,kwartalnieczyrocznie?Czymabyćobliczanaefektywnastopapro-

centowa?

SCzykontaklientówmająbyćprzechowywanewcentralnejbaziedanychczy

wlokalnychbazachoddziałówbanku?Jakmasięsystemzachowaćwrazie

przerwaniałącznościoddziałuzcentralą?

SComoże,aconiemożesięzdarzyćwchwiliawarii?Napewnoniemoże

dojśćdoutratydanychostaniekontikredytów.Alejakszybkosystemmusi

wznowićdziałanie?Natychmiast?Pokilkugodzinach?Pokilkudniach?

Każdaodpowiedźnapostawionepytaniawymagainnegodziałania,aczasem

iinnejbudowyoprogramowania.Ktomatychodpowiedziudzielić–projektantczy

użytkownik?Raczejużytkownik,tyleżespełnienieniektórychwymagańmożebyćbar-

dzokosztowne.Naprzykład,żądanienatychmiastowegowznowieniadziałaniapoawarii

wymagazbudowaniasystemuzapasowego,copodwajakosztyprojektu,aniejest,być

może,niezbędne.Koniecznajestjakaśwymianainformacjimiędzyużytkownikiem

aprojektantem,prowadzącadokompromisurównoważącegopotrzebyzmożliwościami.

Uzgodnioneizatwierdzonewymaganiastająsięczęściądecyzji(umowy)reali-

zacjioprogramowania.Bardzoczęstowrazzwymaganiamidefiniujesięmetody

sprawdzeniastopniaspełnieniawymagańpodczasodbiorugotowegoproduktu.

Określenieizatwierdzeniewymagańniejestaktemjednorazowym.Zarówno

wczasietrwaniaoryginalnegoprojektu,jakipotem,podczaseksploatacjioprogramo-

wania,wymaganiamogąsięzmieniaćwwynikuzmianzachodzącychwrealnym

świeciebiznesu.Możezmienićsięprawo,mogąpojawićsięnoweproduktybankowe,

możezmienićsiętechnologia.Niemożnapoprostuzignorowaćtychzmian.Zdrugiej

stronykażdysystemtworzypewnąspójnącałośćidostosowaniesystemudozmienio-

nychwymagańmożeokazaćsiękosztowne.Cowięcej,każdamodyfikacjagroziwpro-

wadzeniemnowychbłędówiwymagakosztownejweryfikacjiwszystkichzmienionych

Brak wyników

Inżynieria oprogramowania

Treść książki

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