io_wyklad2.pdf

Egzamin: cz

ęść

teoretyczna

Test jednokrotnego wyboru, około 20-25 pyta

Przykładowe pytanie testowe:

Poj

cie „kryzysu oprogramowania” odnosi si

do:

a) niewystarczaj

cej

znajomo

technik

informatycznych

ród

społecze

stwa,

b) niewystarczaj

cych, w stosunku do obecnych wymaga

, mo

liwo

sprz

tu komputerowego,

K. Bartecki, In

ynieria oprogramowania, II/2

sprz

tu komputerowego,

c) powi

kszaj

cej si

rozbie

ci mi

dzy moc

obliczeniow

sprz

komputerowego a rozwojem technik wytwarzania oprogramowania,

d) skutków, jakie miał w roku 2000 wywoła

sposób zapisu daty

w programach komputerowych.

Egzamin: zadanie praktyczne

Zamodelowa

diagram zwi

zków encji dla opisanego systemu.

Zamodelowa

w j

zyku UML diagram klas dla opisanego systemu.

●

jest zbiorem czynno

ci i zwi

zanych z nimi wyników, które prowadz

do powstania produktu programowego (programowania),

Proces tworzenia oprogramowania

do powstania produktu programowego (programowania),

●

e to by

tworzenie oprogramowania od zera, ale coraz cz

ęś

ciej

nowe oprogramowanie powstaje przez rozbudow

i modyfikowanie

istniej

cych systemów.

K. Bartecki, In

ynieria oprogramowania, II/3

Idea przy

wiecaj

ca wytwarzaniu oprogramowania:

c o czym

bardzo skomplikowanym, nie próbuj

robi

wszystkiego jednocze

nie.

Podziel to na mniej zło

one cz

ęś

ci i skoncentruj si

kolejno na ka

dej z nich.

K. Bartecki, In

ynieria oprogramowania, II/4

Z tego wzgl

du proces wytwarzania oprogramowania dzieli si

zwykle

na pewne fazy.

Ogólne fazy procesu produkcji
oprogramowania

●

specyfikacja – okre

lenie i zapisanie wymaga

, które musi spełnia

oprogramowanie,

●

projektowanie – ustalenie ogólnej architektury systemu oraz wymaga

dla poszczególnych jego składowych,

●

implementacja – realizacja ustalonej architektury poprzez tworzenie
kodu składowych systemu (modułów) oraz poł

cze

dzy nimi,

●

integracja – zintegrowanie poszczególnych składowych (modułów)
w jeden system, testowanie całego systemu,

●

ewolucja – uruchomienie systemu, usuwanie wykrytych podczas jego
u

ywania bł

dów, rozszerzanie systemu.

K. Bartecki, In

ynieria oprogramowania, II/5

Modele cyklu

ycia oprogramowania

●

model kaskadowy,

●

model przyrostowy (iteracyjny),

●

model V,

●

model prototypowy,

●

programowanie odkrywcze,

●

model spiralny,

●

model formalnych transformacji.

K. Bartecki, In

ynieria oprogramowania, II/6

Model kaskadowy

W modelu kaskadowym (ang. waterfall model), nazywanym tak

modelem liniowym, wszystkie podstawowe czynno

ci przy tworzeniu

oprogramowania wykonywane s

jako odr

bne fazy projektowe, jedna po

drugiej.

Wymagania

Projektowanie

Implementacja

Testowanie

Konserwacja

K. Bartecki, In

ynieria oprogramowania, II/7

Model kaskadowy – fazy

●

Faza okre

lenia wymaga

(ang. requirements) – okre

lane s

cele oraz

szczegółowe wymagania wobec tworzonego systemu,

●

Faza projektowania (ang. design) – powstaje szczegółowy projekt
systemu, spełniaj

cego ustalone wcze

niej wymagania,

●

Faza implementacji (ang. implementation) – projekt implementowany
(kodowany)

jest

w okre

lonym

rodowisku

programistycznym

oraz

wykonywane s

testy jego modułów,

●

Faza testowania (ang. verification) – nast

puje integracja oraz testowanie

cało

ci oprogramowania,

●

Faza

konserwacji

(ang.

maintenance)

–

oprogramowanie

jest

wykorzystywane

przez

ytkowników,

producent

dokonuje

jego

konserwacji (usuwanie bł

dów, rozszerzanie funkcji, wsparcie techniczne).

K. Bartecki, In

ynieria oprogramowania, II/8

Dodatkowe fazy modelu kaskadowego

Wymagania

Projektowanie

Implementacja

Testowanie

Konserwacja

Strategiczna

Analiza

Instalacja

Dokumentacja

●

Faza strategiczna (ang. strategy) – strategiczne decyzje dotycz

kolejnych etapów prac,

●

Faza analizy (ang. analysis) – budowa logicznego modelu systemu,

●

Faza dokumentacji (ang. documentation) – wytwarzanie dokumentacji
u

ytkownika,

●

Faza instalacji (ang. installation) – instalacja systemu i przekazanie
go u

ytkownikowi.

K. Bartecki, In

ynieria oprogramowania, II/9

Model kaskadowy z iteracjami

li która

z faz da niezadowalaj

cy efekt, cofamy si

, wykonuj

c kolejne

iteracje, a

do momentu, kiedy na ko

cu „schodków” otrzymamy

satysfakcjonuj

cy produkt.

Wymagania

Projektowanie

Implementacja

Testowanie

Konserwacja

K. Bartecki, In

ynieria oprogramowania, II/10

Zalety modelu kaskadowego:

●

przejrzysto

ść

●

łatwo

ść

zarz

dzania przedsi

wzi

ciem,

●

stanowi podstaw

dla wielu innych modeli

ycia oprogramowania.

Wady modelu kaskadowego:

●

narzucenie twórcom oprogramowania

cisłej kolejno

ci wykonywania

●

narzucenie twórcom oprogramowania

cisłej kolejno

ci wykonywania

prac – nie mo

na przej

ść

do nast

pnej fazy przed zako

czeniem

poprzedniej,

●

wysoki koszt bł

dów popełnionych we wst

pnych fazach – iteracje s

bardzo kosztowne, gdy

powtarzamy wiele czynno

ci,

●

długa przerwa w kontaktach z klientem – projektowanie oraz
implementacja wykonywane s

wył

cznie przez firm

programistyczn

K. Bartecki, In

ynieria oprogramowania, II/11

Model przyrostowy (iteracyjny)

W modelu przyrostowym (ang. incremental model), po okre

leniu

wymaga

oraz

zbudowaniu

ogólnego

projektu

systemu,

wybierany,

implementowany oraz dostarczany klientowi jest kolejny podzbiór funkcji
systemu.

wymagania

ogólny projekt

proces realizowany

K. Bartecki, In

ynieria oprogramowania, II/12

ogólny projekt

wybór podzbioru

funkcji

projekt, imple-

mentacja, testy

dostarczenie

klientowi

proces realizowany

iteracyjnie

Model przyrostowy – fazy

●

okre

lenie cało

ci wymaga

(na ile uda si

je sprecyzowa

), oraz

wykonanie wst

pnego, ogólnego projektu cało

ci systemu,

●

wybór pewnego podzbioru funkcji systemu,

K. Bartecki, In

ynieria oprogramowania, II/13

●

wybór pewnego podzbioru funkcji systemu,

●

szczegółowy

projekt

(zgodnie

modelem

kaskadowym)

oraz

implementacja cz

ęś

ci systemu realizuj

cej wybrane funkcje,

●

testowanie zrealizowanego fragmentu i dostarczenie go klientowi,

●

powtarzanie kolejnych etapów (od wyboru nowego podzbioru funkcji), a

do zako

czenia implementacji całego systemu.

Zalety modelu przyrostowego:

●

stsze ni

w modelu kaskadowym kontakty z klientem,

●

brak konieczno

ci definiowania z góry cało

ci wymaga

●

liwo

ść

wcze

niejszego wykorzystania przez klienta fragmentów

systemu,

●

liwo

ść

elastycznego

reagowania

opó

nienia

realizacji

fragmentu – przyspieszenie prac nad innymi cz

ęś

ciami.

Wady modelu przyrostowego:

●

dodatkowy koszt zwi

zany z niezale

realizacj

fragmentów

systemu,

●

trudno

ci z wycinaniem podzbioru funkcji w pełni niezale

nych,

●

konieczno

ść

implementacji szkieletów (interfejs).

K. Bartecki, In

ynieria oprogramowania, II/14

Model V

●

jest

rozwini

ciem

modelu

kaskadowego, charakteryzuj

cym

rozbudowan

faz

testów,

●

testy te maj

na celu weryfikacj

poprawno

ci ka

dego etapu,

ródło: testerzy.pl

K. Bartecki, In

ynieria oprogramowania, II/15

poprawno

ci ka

dego etapu,

●

dzi

ki temu,

e ka

dy z etapów wytwórczych ko

czy si

przegl

dami i

inspekcjami, prawdopodobie

stwo pojawienia si

bł

du lub niezgodno

z wymaganiami przy wdro

eniu i eksploatacji jest du

o mniejsze ni

klasycznym modelu kaskadowym,

●

implementacja stanowi zako

czenie „lewego ramienia” – projektowania,

●

prawe rami

, czyli weryfikacja, to sprawdzanie, czy wst

pne zało

enia

zostały

wypełnione

–

poczynaj

sprawdzania

najmniejszych

komponentów na całym zintegrowanym systemie ko

Zalety modelu V:

●

mniejsze ni

w modelu kaskadowym prawdopodobie

stwo

wyst

pienia bł

dów,

●

w zwi

zku z powy

szym – znacz

ce obni

enie kosztów piel

gnacji

systemu,

●

zach

ca do jak najwcze

niejszego rozpocz

cia procesu tworzenia

planów testów, specyfikacji testowej i samego testowania.

Wady modelu V:

●

stanowi

jedynie

niewielk

modyfikacj

modelu

kaskadowego,

powielaj

c jego wady,

●

stanowi jedynie propozycj

(w du

ej mierze teoretyczn

) „idealnego

wiata” współpracy mi

dzy architektami, a programistami, testerami i

klientami.

K. Bartecki, In

ynieria oprogramowania, II/16

Model prototypowy

polega

stworzeniu

podczas

projektowania

prototypu systemu w celu przedyskutowania oraz
akceptacji ze strony klienta.

Metody budowy prototypu:

●

„rozpisanie” interfejsów u

ytkownika na kartce papieru,

K. Bartecki, In

ynieria oprogramowania, II/17

●

realizacja wył

cznie interfejsu u

ytkownika, np. z wykorzystaniem

narz

dzi RAD (ang. Rapid Application Development),

●

niepełna realizacja – np. implementacja jedynie kilku modułów systemu,

●

implementacja metod działaj

cych jedynie w wi

kszo

ci przypadków lub

dla niektórych danych, w celu pokazanie jedynie idei,

●

niskiej jako

ci system wykonany za pomoc

modelu odkrywczego,

który stosunkowo szybko si

wykonuje.

Zalety modelu prototypowego:

●

pozwala klientowi szybko zobaczy

jak

„mniej wi

cej” b

dzie wygl

dał system,

●

zwi

ksza zrozumienie twórców systemu co do potrzeb klienta,

●

w zale

ci od rodzaju prototypu, mo

e pozwala

rozpocz

ąć

szkolenie obsługi systemu po stronie klienta,

●

prototyp jest łatwy do zmiany.

●

prototyp jest łatwy do zmiany.

Wady modelu prototypowego:

●

wysoki koszt budowy systemu – po weryfikacji prototyp jest najcz

ęś

ciej

porzucany

lub

tylko

ęś

ciowo

wykorzystywany

budowy

wła

ciwego systemu,

●

liwo

ść

nieporozumie

z klientem – klient widzi „prawie gotowy”

produkt, który w rzeczywisto

ci jest dopiero w pocz

tkowej fazie

rozwoju.

K. Bartecki, In

ynieria oprogramowania, II/18

Programowanie odkrywcze

Programowanie odkrywcze (ang. exploratory programming) to model,
w którym budowa systemu rozpoczyna si

natychmiast po okre

leniu

ogólnych wymaga

Zbudowany system jest weryfikowany przez klienta – je

eli zostanie

uznany za nieodpowiedni, budowana (modyfikowana) jest kolejna jego
wersja – tak długo, a

jedna z kolejnych jego wersji zadowoli klienta.

K. Bartecki, In

ynieria oprogramowania, II/19

Okre

lenie

ogólnych

wymaga

Budowa

systemu

Testowanie

systemu

Dostarczenie

systemu

System

działa

poprawnie?

Zalety programowania odkrywczego:

●

liwo

ść

stosowania przy bardzo trudnych

sytuacjach z okre

leniem wymaga

klienta,

●

dobrze opisuje amatorski sposób tworzenia oprogramowania,

●

w profesjonalnych projektach dobrze nadaje si

do budowy prototypu,

Wady programowania odkrywczego:

●

brak mo

liwo

ci opracowania i zachowania sensownej struktury

systemu,

●

testowanie odbywa si

jedynie przy obecno

ci klienta ze wzgl

na pełnych brak wymaga

K. Bartecki, In

ynieria oprogramowania, II/20

Model spiralny

modelu

spiralnym

(ang.

spiral

model)

proces

tworzenia

oprogramowania ma posta

spirali, której ka

da p

tla reprezentuje jedn

iteracj

procesu. Najbardziej wewn

trzna p

tla przedstawia pocz

tkowe

etapy projektowania, np. studium wykonalno

ci, kolejna definicji wymaga

systemowych, itd.

Analiza ryzyka w oparciu
o wymagania wst

pne

Analiza ryzyka na podstawie

K. Bartecki, In

ynieria oprogramowania, II/21

Wymagania wst

pne,

plan projektu

Kolejne wersje produktu

Analiza ryzyka na podstawie
ocen u

ytkownika

Weryfikacja planu projektu oraz
planowanie kolejnej iteracji na
podstawie ocen u

ytkownika

Model spiralny – fazy

Model spiralny składa si

z czterech głównych faz, wykonywanych cyklicznie:

●

planowanie – definiowanie konkretnych celów, wymaganych w danejfazie
przedsi

wzi

cia.

K. Bartecki, In

ynieria oprogramowania, II/22

przedsi

wzi

cia.

●

analiza ryzyka – identyfikacja ogranicze

i zagro

, ustalanie planów

realizacji,

●

tworzenie i zatwierdzanie – tworzenie oprogramowania w oparciu
o najbardziej odpowiedni model, wybrany na podstawie oceny zagro

●

ocena i planowanie – recenzja post

pu prac i planowanie kolejnej fazy

przedsi

wzi

cia, b

zako

czenie projektu.

Zalety modelu spiralnego:

●

na wykorzysta

gotowe projekty,

●

faza oceny przeprowadzana w ka

dym cyklu pozwala unikn

ąć

bł

dów

lub odpowiednio wcze

nie je wykry

●

cały czas istnieje mo

liwo

ść

rozwijania projektu.

Wady modelu spiralnego:

●

metodologia nie do ko

ca dopracowana – ka

dy projekt jest inny

i powstaje w innych warunkach,

●

tworzenie

oparciu

ten

model

wymaga

wiadczenia

w prowadzeniu tego typu projektów oraz wiedzy ekonomicznej
w zarz

dzaniu,

●

przeznaczony tylko dla du

ych przedsi

wzi

ęć

programistycznych.

K. Bartecki, In

ynieria oprogramowania, II/23

Model formalnych transformacji

W metodzie formalnych transformacji (ang. formal transformations)
zakłada si

e wymagania systemowe zapisywane s

w pewnym

formalnym j

zyku.

Nast

pnie

podlegaj

one

automatycznym

(tzn.

bez

udziału

ludzi)

transformacjom do kolejnych form coraz bli

szych kodowi.

K. Bartecki, In

ynieria oprogramowania, II/24

Formalna

specyfikacja

wymaga

Posta

rednia

Kod

Posta

rednia

. . .

Zalety modelu formalnych transformacji:

●

pełna automatyzacja procesu wytwarzania
oprogramowania,

●

wysoka niezawodno

ść

li nie popełniono bł

dów na etapie

okre

lania wymaga

Wady modelu formalnych transformacji:

●

trudno

ść

formalnej specyfikacji wymaga

– polega ona tu wła

ciwie na

napisaniu „programu” rozwi

zuj

cego pewien problem, który podlegał

dzie stopniowej „kompilacji” do poziomu kodu,

●

mała efektywno

ść

tak uzyskanego kodu,

●

brak dobrze rozwini

tych j

zyków formalnej specyfikacji wymaga

●

model stanowi wła

ciwie jedynie propozycj

teoretyczn

, zwi

zan

z tzw. nurtem formalnym in

ynierii oprogramowania.

K. Bartecki, In

ynieria oprogramowania, II/25

Co to jest RUP ?

●

RUP (ang.

Rational

Unified

Process)

–

proces

iteracyjnego

wytwarzania oprogramowania opracowany przez firm

Rational Software

Corporation (przedsi

biorstwo zostało przej

te przez IBM).

K. Bartecki, In

ynieria oprogramowania, II/26

●

Proces RUP został opracowany z u

yciem tych samych technik, których

zespół Rational u

ywał do modelowania systemów – czyli głównie j

zyka

UML. J

zyk UML powstawał równolegle z RUP.

●

Powstał

bazie

analizy

najcz

stszych

przyczyn

niepowodze

istniej

cych procesów wytwarzania oprogramowania.

RUP bazuje na zbiorze zasad in

ynierii programowania oraz na tzw.

najlepszych praktykach, w

ród których mo

na wymieni

●

iteracyjne wytwarzanie oprogramowania (Iterative Development),

●

zarz

dzanie wymaganiami (Requirement Management) – skupione na

zaspokojeniu oczekiwa

ytkowników ko

cowych systemu poprzez

identyfikacj

i specyfikacj

ich potrzeb oraz wykrywanie zmiany tych

wymaga

●

ywanie architektury bazuj

cej na komponentach (Component-based

K. Bartecki, In

ynieria oprogramowania, II/27

●

ywanie architektury bazuj

cej na komponentach (Component-based

architecture) – komponentem nazywamy zbiór powi

zanych obiektów

(w sensie programowania obiektowego),

●

graficzne projektowanie oprogramowania,

●

kontrol

jako

ci oprogramowania (Quality Assurance) – RUP zakłada,

e ka

dy członek zespołu jest odpowiedzialny za jako

ść

w ci

całego procesu,

●

proces kontroli zmian w oprogramowaniu (Change Management).