In

ż

ynieria oprogramowania

wykład II

Modele i fazy cyklu

ż

ycia oprogramowania

prowadz

ą

cy: dr in

ż

. Krzysztof Bartecki

www.k.bartecki.po.opole.pl

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

ś

ci

technik

informatycznych

w

ś

ród

społecze

ń

stwa,

b) niewystarczaj

ą

cych, w stosunku do obecnych wymaga

ń

, mo

ż

liwo

ś

ci

sprz

ę

tu komputerowego,

K. Bartecki, In

ż

ynieria oprogramowania, II/2

sprz

ę

tu komputerowego,

c) powi

ę

kszaj

ą

cej si

ę

rozbie

ż

no

ś

ci mi

ę

dzy moc

ą

obliczeniow

ą

sprz

ę

tu

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),

●

mo

ż

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:

My

ś

l

ą

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

ń

mi

ę

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

ż

e

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

u

ż

ytkowników,

a

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

ą

ce

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

Je

ś

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

z

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:

●

cz

ę

stsze ni

ż

w modelu kaskadowym kontakty z klientem,

●

brak konieczno

ś

ci definiowania z góry cało

ś

ci wymaga

ń

,

●

mo

ż

liwo

ść

wcze

ś

niejszego wykorzystania przez klienta fragmentów

systemu,

●

mo

ż

liwo

ść

elastycznego

reagowania

na

opó

ź

nienia

realizacji

fragmentu – przyspieszenie prac nad innymi cz

ęś

ciami.

Wady modelu przyrostowego:

●

dodatkowy koszt zwi

ą

zany z niezale

ż

n

ą

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

si

ę

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

ś

ci

z wymaganiami przy wdro

ż

eniu i eksploatacji jest du

ż

o mniejsze ni

ż

w

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

ą

c

od

sprawdzania

najmniejszych

komponentów na całym zintegrowanym systemie ko

ń

cz

ą

c.

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

na

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

ż

no

ś

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

cz

ęś

ciowo

wykorzystywany

do

budowy

wła

ś

ciwego systemu,

●

mo

ż

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:

●

mo

ż

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

ę

du

na pełnych brak wymaga

ń

.

K. Bartecki, In

ż

ynieria oprogramowania, II/20

Model spiralny

W

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

ż

e

ń

, ustalanie planów

realizacji,

●

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

ż

e

ń

,

●

ocena i planowanie – recenzja post

ę

pu prac i planowanie kolejnej fazy

przedsi

ę

wzi

ę

cia, b

ą

d

ź

zako

ń

czenie projektu.

Zalety modelu spiralnego:

●

mo

ż

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

w

oparciu

o

ten

model

wymaga

do

ś

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

ć

po

ś

rednia

Kod

Posta

ć

po

ś

rednia

. . .

Zalety modelu formalnych transformacji:

●

pełna automatyzacja procesu wytwarzania
oprogramowania,

●

wysoka niezawodno

ść

,

je

ś

li nie popełniono bł

ę

dów na etapie

okre

ś

lania wymaga

ń

.

Wady modelu formalnych transformacji:

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ł

b

ę

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)

–

to

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ł

na

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

ń

u

ż

ytkowników ko

ń

cowych systemu poprzez

identyfikacj

ę

i specyfikacj

ę

ich potrzeb oraz wykrywanie zmiany tych

wymaga

ń

,

●

u

ż

ywanie architektury bazuj

ą

cej na komponentach (Component-based

K. Bartecki, In

ż

ynieria oprogramowania, II/27

●

u

ż

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

ą

gu

całego procesu,

●

proces kontroli zmian w oprogramowaniu (Change Management).

Fazy RUP

K. Bartecki, In

ż

ynieria oprogramowania, II/28

Cykl

ż

ycia oprogramowania „na wesoło”:

K. Bartecki, In

ż

ynieria oprogramowania, II/29