In

ż

ynieria oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

1

Literatura do przedmiotu

Ian Sommerville: In

ż

ynieria oprogramowania

Włodzimierz D

ą

browski, Kazimierz Subieta:

Podstawy in

ż

ynierii oprogramowania

Perdita Stevens: UML. In

ż

ynieria

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

2

Perdita Stevens: UML. In

ż

ynieria

oprogramowania.

http://wazniak.mimuw.edu.pl/

Zagadnienia do zrealizowania na

wykładzie

Wprowadzenie

•

In

ż

ynieria systemów

komputerowych

•

Proces tworzenia oprogramowania

•

Zarz

ą

dzanie przedsi

ę

wzi

ę

ciami

Wymagania

•

Wymagania stawiane
oprogramowaniu

•

Proces in

ż

ynierii wymaga

ń

Systemy krytyczne

•

Pewno

ść

•

Specyfikowanie systemów
krytycznych

•

Wytwarzanie systemów krytycznych

Weryfikacja i zatwierdzanie

•

Weryfikacja i zatwierdzanie

•

Testowanie oprogramowania

•

Zatwierdzanie systemów krytycznych

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

3

•

Proces in

ż

ynierii wymaga

ń

•

Modele systemu

•

Prototypowanie oprogramowania

•

Specyfikacja formalna

Projektowanie

•

Projektowanie architektoniczne

•

Architektury systemów
rozproszonych

•

Projektowanie obiektowe

•

Projektowanie oprogramowania
czasu rzeczywistego

•

Projektowanie z u

ż

yciem

wielokrotnym

•

Projektowanie interfejsu
u

ż

ytkownika

•

Zatwierdzanie systemów krytycznych

Zarz

ą

dzanie

•

Zarz

ą

dzanie personelem

•

Szacowanie kosztu oprogramowania

•

Zarz

ą

dzanie jako

ś

ci

ą

•

Ulepszanie procesu

Ewolucja

•

Systemy odziedziczone

•

Modyfikacja oprogramowania

•

Restrukturyzacja oprogramowania

•

Zarz

ą

dzanie konfiguracjami

(UML)

Plan wykładu

Wprowadzenie do in

ż

ynierii oprogramowania i jej

roli w programowaniu

Odpowiedzi na podstawowe pytania dotycz

ą

ce

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

4

Odpowiedzi na podstawowe pytania dotycz

ą

ce

in

ż

ynierii oprogramowania (FAQ)

Wprowadzenie etycznych i profesjonalnych
zagadnie

ń

i wyja

ś

nienie roli jak

ą

graj

ą

w

in

ż

ynierii oprogramowania.

Co to jest oprogramowanie?

Produkty powszechne. S

ą

to samodzielne systemy, które buduje

si

ę

w firmie programistycznej, a nast

ę

pnie sprzedaje na wolnym

rynku wszystkim klientom, którzy s

ą

w stanie je kupi

ć

. Czasem

nazywa si

ę

je oprogramowaniem w torebkach foliowych.

Przykładami takich produktów s

ą

bazy danych, edytory tekstów,

pakiety do rysowania i narz

ę

dzia do zarz

ą

dzania przedsi

ę

wzi

ę

ciami.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

5

Produkty na zamówienie (dostosowane). Takie systemy s

ą

zamawiane przez konkretnego klienta. Oprogramowanie jest
opracowywane specjalnie dla tego klienta przez firm

ę

zleceniobiorc

ę

.

Przykładami takich produktów s

ą

systemy steruj

ą

ce urz

ą

dzeniami

elektronicznymi, systemy przeznaczone do wspomagania
okre

ś

lonego procesu przedsi

ę

biorstwa oraz systemy kontroli lotów.

Co to jest in

ż

ynieria oprogramowania?

In

ż

ynieria oprogramowania to dziedzina

in

ż

ynierii, która obejmuje wszystkie aspekty

tworzenia oprogramowania od pocz

ą

tkowej fazy

specyfikacji systemu a

ż

do jego piel

ę

gnacji po

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

6

dacie rozpocz

ę

cia jego u

ż

ytkowania.

Co to jest in

ż

ynieria oprogramowania?

,,Dziedzina in

ż

ynierii” In

ż

ynierowie sprawiaj

ą

,

ż

e rzeczy działaj

ą

.

Stosuj

ą

teorie, metody i narz

ę

dzia tam, gdzie s

ą

potrzebne. Stosuj

ą

je jednak selektywnie i zawsze próbuj

ą

znale

źć

rozwi

ą

zanie nawet

tam, gdzie nie ma jeszcze teorii i metod, które mogłyby im pomóc.
In

ż

ynierowie wiedz

ą

tak

ż

e,

ż

e musz

ą

pracowa

ć

w ramach

ogranicze

ń

organizacyjnych i finansowych, szukaj

ą

wi

ę

c rozwi

ą

za

ń

zgodnych z tymi ograniczeniami

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

7

zgodnych z tymi ograniczeniami

„Wszystkie aspekty tworzenia oprogramowania”. In

ż

ynieria

oprogramowania obejmuje nie tylko techniczny proces tworzenia
oprogramowania, ale tak

ż

e czynno

ś

ci takie, jak zarz

ą

dzanie

przedsi

ę

wzi

ę

ciem programistycznym, opracowywanie narz

ę

dzi,

metod i teorii wspomagaj

ą

cych tworzenie oprogramowania.

Jaka jest ró

ż

nica mi

ę

dzy in

ż

ynieri

ą

oprogramowania a informatyk

ą

?

Zasadniczo informatyka obejmuje teorie i podstawowe metody
działania komputerów i systemów komputerowych.

In

ż

ynieria oprogramowania obejmuje praktyczne problemy zwi

ą

zane

z tworzeniem oprogramowania.

Pewien zakres wiedzy informatycznej jest niezb

ę

dny dla ka

ż

dego

in

ż

yniera oprogramowania, tak samo jak pewien zakres fizyki jest

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

8

in

ż

yniera oprogramowania, tak samo jak pewien zakres fizyki jest

potrzebny in

ż

ynierom elektrykom.

In

ż

ynier oprogramowania dobrze powinien zna

ć

teorie

informatyczne. Niestety w rzeczywisto

ś

ci tak nie jest. In

ż

ynierowie

oprogramowania musz

ą

cz

ę

sto ad hoc wymy

ś

la

ć

sposoby produkcji

oprogramowania.

Eleganckie teorie informatyczne nie zawsze mog

ą

by

ć

zastosowane

do rzeczywistych, zło

ż

onych zada

ń

, które musz

ą

by

ć

rozwi

ą

zane za

pomoc

ą

oprogramowania.

Jaka jest ró

ż

nica mi

ę

dzy in

ż

ynieri

ą

oprogramowania a in

ż

ynieri

ą

systemów?

In

ż

ynieria systemów (bardziej precyzyjnie in

ż

ynieria systemów

komputerowych) obejmuje wszystkie aspekty tworzenia i ewolucji
systemów komputerowych, w których oprogramowanie odgrywa
główn

ą

rol

ę

.

In

ż

ynieria systemów mie

ś

ci w sobie tworzenie oprogramowania,

opracowywanie strategii, projektowanie procesu tworzenia,
wdro

ż

enie systemu, a tak

ż

e in

ż

ynieri

ę

oprogramowania.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

9

wdro

ż

enie systemu, a tak

ż

e in

ż

ynieri

ę

oprogramowania.

In

ż

ynierowie systemów bior

ą

udział w specyfikacji systemu i

definiowaniu jego ogólnej architektury. Nast

ę

pnie integruj

ą

ró

ż

ne

cz

ęś

ci i tworz

ą

z nich gotowy system. Mniej natomiast zajmuj

ą

si

ę

in

ż

ynieri

ą

składowych systemu (sprz

ę

t komputerowy,

oprogramowanie itd.).

In

ż

ynieria systemów jest dziedzin

ą

starsz

ą

ni

ż

in

ż

ynieria

oprogramowania.

Co to jest proces tworzenia

oprogramowania?

Proces tworzenia oprogramowania to zbiór czynno

ś

ci i zwi

ą

zanych z

nimi wyników, które zmierzaj

ą

do opracowania produktu

programowego. Wi

ę

kszo

ść

z tych czynno

ś

ci jest wykonywana przez

in

ż

ynierów oprogramowania.

•

Specyfikacja oprogramowania. Funkcjonalno

ść

oprogramowania i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

10

•

Specyfikacja oprogramowania. Funkcjonalno

ść

oprogramowania i

ograniczenia jego działania musz

ą

by

ć

zdefiniowane.

•

Tworzenie oprogramowania. Oprogramowanie spełniaj

ą

ce

specyfikacj

ę

musi by

ć

wyprodukowane.

•

Zatwierdzenie oprogramowania. Oprogramowanie musi by

ć

poddane

kontroli, aby zapewni

ć

,

ż

e robi to, czego klient oczekiwał.

•

Ewolucja oprogramowania. Oprogramowanie musi ewoluowa

ć

, aby

spełni

ć

zmieniaj

ą

ce si

ę

wymagania klienta.

Co to jest model procesu tworzenia

oprogramowania?

Model procesu tworzenia oprogramowania to
uproszczona prezentacja procesu tworzenia
oprogramowania z pewnego punktu widzenia. Modele ze
swej natury s

ą

uproszczeniami; model procesu tworzenia

oprogramowania jest wi

ę

c abstrakcj

ą

konkretnego

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

11

oprogramowania jest wi

ę

c abstrakcj

ą

konkretnego

procesu, który ma by

ć

opisany.

Modele procesów mog

ą

zawiera

ć

czynno

ś

ci składaj

ą

ce

si

ę

na proces, produkty programowe i role osób

bior

ą

cych udział w procesie tworzenia oprogramowania.

Modele procesu tworzenia

Model przepływu prac. Przedstawia ci

ą

g czynno

ś

ci procesu wraz z

ich wej

ś

ciami, wyj

ś

ciami i zale

ż

no

ś

ciami. Czynno

ś

ci w tym modelu

reprezentuj

ą

działania ludzi.

Model przepływu danych (lub model czynno

ś

ci). Przedstawia

proces w postaci zbioru czynno

ś

ci, z których ka

ż

da dokonuje

pewnego przekształcenia danych. Opisuje, jak wej

ś

cie procesu (np.

specyfikacja) jest przekształcane w wyj

ś

cie (np. projekt). W tym

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

12

specyfikacja) jest przekształcane w wyj

ś

cie (np. projekt). W tym

modelu czynno

ś

ci mog

ą

by

ć

zdefiniowane na ni

ż

szym poziomie

abstrakcji ni

ż

czynno

ś

ci w modelu przepływu prac. Reprezentuj

ą

przekształcenia wykonywane przez ludzi lub przez komputery.

Model rola-akcja. Przedstawia role osób bior

ą

cych udział w

procesie tworzenia oprogramowania oraz czynno

ś

ci, za które osoby

w tych rolach s

ą

odpowiedzialne.

Modele tworzenia oprogramowania

Model kaskadowy. Poszczególne czynno

ś

ci przedstawiono w nim jako oddzielne

fazy procesu, takie jak specyfikacja wymaga

ń

, projektowanie oprogramowania,

implementacja, testowanie itd. Po wykonaniu ka

ż

dej fazy zatwierdza si

ę

jej wyniki i

przechodzi do nast

ę

pnej fazy.

Tworzenie ewolucyjne. W tym procesie czynno

ś

ci specyfikacji, projektowania i

zatwierdzania przeplataj

ą

si

ę

. Pierwsza wersja systemu powstaje bardzo szybko na

podstawie niezwykle abstrakcyjnych specyfikacji. Jest pó

ź

niej udoskonalana zgodnie z

informacjami otrzymanymi od klienta. Prowadzi to do stworzenia systemu, który
spełnia oczekiwania klienta. Wówczas system jest dostarczany klientowi. Mo

ż

e by

ć

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

13

spełnia oczekiwania klienta. Wówczas system jest dostarczany klientowi. Mo

ż

e by

ć

równie

ż

zaimplementowany ponownie za pomoc

ą

lepiej uporz

ą

dkowanego podej

ś

cia,

by stał si

ę

mocniejszy i zdatny do piel

ę

gnacji.

Formalne przekształcenia. To podej

ś

cie jest oparte na budowaniu formalnych

matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program
za pomoc

ą

metod matematycznych. Te przekształcenia maj

ą

wła

ś

ciwo

ść

„zachowywania poprawno

ś

ci”. Oznacza to pewno

ść

,

ż

e zbudowany system spełnia

swoj

ą

specyfikacj

ę

.

Składanie systemu z komponentów ponownego u

ż

ycia. Ta technika zakłada,

ż

e

cz

ęś

ci systemu ju

ż

istniej

ą

. Proces budowy systemu polega głównie na integrowaniu

tych fragmentów, a nie tworzeniu ich od pocz

ą

tku.

Jakie s

ą

koszty oprogramowania?

Koszty oprogramowania cz

ę

sto dominuj

ą

systemy

komputerowe i cz

ę

sto s

ą

dro

ż

sze ni

ż

sam sprz

ę

t.

Koszt zarz

ą

dzania oprogramowaniem cz

ę

sto kosztuje

wi

ę

cej ni

ż

koszt jego wytworzenia. W systemach z

„długim czasem

ż

ycia” cz

ę

sto koszty obsługi s

ą

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

14

„długim czasem

ż

ycia” cz

ę

sto koszty obsługi s

ą

wielokrotnie wy

ż

sze ni

ż

koszty opracowania programu

In

ż

ynieria oprogramowania koncentruje si

ę

na „mo

ż

liwie

efektywnym” koszcie opracowania systemu
(oprogramowania)

Koszt in

ż

ynierii oprogramowania

Około 60% kosztów to koszt opracowania, 40% koszty to
koszy testowania. Dla oprogramowania ”indywidualnego”
koszt rozwoju/testowania cz

ę

sto przewy

ż

sza koszt

opracowania.

Oczywi

ś

cie koszty ró

ż

ni

ą

si

ę

w zale

ż

no

ś

ci od systemu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

15

Oczywi

ś

cie koszty ró

ż

ni

ą

si

ę

w zale

ż

no

ś

ci od systemu

który powstaje, od wymaga

ń

dotycz

ą

cych wydajno

ś

ci i

wiarygodno

ś

ci systemu (ilo

ś

ci bł

ę

dów które jeste

ś

my w

stanie zaakceptowa

ć

)

Koszty dystrybucji zale

żą

równie

ż

od modelu

projektowania jaki został przyj

ę

ty.

Koszty in

ż

ynierii oprogramowania

Taka struktura kosztów wyst

ę

puje

wówczas, gdy koszty specyfikacji,
projektowania, implementacji i integracji s

ą

mierzone oddzielnie.

Je

ś

li oprogramowanie jest tworzone

ewolucyjnie, to nie ma wyra

ź

nej granicy

mi

ę

dzy specyfikacj

ą

, projektowaniem i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

16

mi

ę

dzy specyfikacj

ą

, projektowaniem i

budow

ą

.

Oprócz kosztów tworzenia ponosi si

ę

tak

ż

e koszty zmian w oprogramowaniu,

które s

ą

wprowadzane po oddaniu go do

u

ż

ytku.

W wypadku wielu systemów
komputerowych, które pracuj

ą

przez długi

czas, koszty te prawdopodobnie
przekrocz

ą

koszty tworzenia trzy- lub

nawet czterokrotnie

Koszty projektu

Poprzedni slajd prezentował rozkład kosztów dotycz

ą

cych oprogramowania na

zamówienie, które wyspecyfikował klient, a stworzył zleceniobiorca.

Produkty działaj

ą

ce (głównie) na komputerach osobistych b

ę

d

ą

miały profil

kosztów b

ę

dzie prawdopodobnie inny. Takie produkty s

ą

zwykle budowane na

podstawie szkicowej specyfikacji za pomoc

ą

podej

ś

cia ewolucyjnego. Koszty

specyfikacji s

ą

raczej niskie. Takie produkty maj

ą

by

ć

jednak u

ż

ywane w ró

ż

nych

konfiguracjach i dlatego musz

ą

by

ć

niezwykle starannie przetestowane.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

17

Co to s

ą

metody in

ż

ynierii oprogramowania?

Metoda in

ż

ynierii oprogramowania to uporz

ą

dkowane podej

ś

cie do

tworzenia oprogramowania, którego celem jest zbudowanie
oprogramowania wysokiej jako

ś

ci w ekonomiczny sposób.

Opis modelu:

•

Opisy modeli systemu (mog

ą

by

ć

graficzne), które nale

ż

y opracowa

ć

oraz

notacje u

ż

yte do definicji tych modeli (Modele obiektów, modele przepływu

danych, modele maszyn stanowych, itd.).

Reguły

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

18

Reguły

•

Ograniczenia, którym podlegaj

ą

modele systemu

Rekomendacje

•

Zawieraj

ą

„dobre zasady” projektowania (Heurystyki, które okre

ś

laj

ą

dobre

zwyczaje projektantów w ramach danej metody. Uwzgl

ę

dnianie tych

rekomendacji powinno doprowadzi

ć

do powstania dobrze zorganizowanego

modelu systemu.

Poradnictwo na temat procesu tworzenia

•

Opis czynno

ś

ci, które nale

ż

y wykona

ć

aby opracowa

ć

modele systemu oraz

porz

ą

dek tych czynno

ś

ci.

Co to jest CASE (Computer-Aided Software Engineering

– In

ż

ynieria Oprogramowania Wspierana Komputerowo

CASE obejmuje rozmaite programy wykorzystywane do
wspomagania czynno

ś

ci procesu tworzenia oprogramowania, np.

analizy wymaga

ń

, modelowania systemu, wyszukiwania i usuwania

bł

ę

dów oraz testowania.

Wszystkie współczesne metody s

ą

powi

ą

zane z narz

ę

dziami

technologii CASE takimi jak edytory notacji u

ż

ywanej w metodzie,

moduły analityczne, które weryfikuj

ą

poprawno

ść

modelu zgodnie z

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

19

moduły analityczne, które weryfikuj

ą

poprawno

ść

modelu zgodnie z

regułami metody, oraz generatory raportów, które pomagaj

ą

opracowa

ć

dokumentacj

ę

systemu.

Narz

ę

dziami CASE s

ą

tak

ż

e generator kodu, który automatycznie

tworzy kod

ź

ródłowy na podstawie modelu systemu, oraz poradniki

opisuj

ą

ce proces, które doradzaj

ą

in

ż

ynierowi oprogramowania

kolejno

ść

czynno

ś

ci.

Jakie wła

ś

ciwo

ś

ci ma dobre

oprogramowanie?

Zdatno

ść

do piel

ę

gnacji

•

Oprogramowanie powinno by

ć

napisane w taki sposób, aby mogło

ewoluowa

ć

zgodnie ze zmieniaj

ą

cymi si

ę

potrzebami klientów. Ten

atrybut jest niezb

ę

dny, poniewa

ż

ewolucja oprogramowania jest

nieodzown

ą

konsekwencj

ą

zmieniaj

ą

cego si

ę

ś

rodowiska

gospodarczego

Niezawodno

ść

•

Niezawodno

ść

oprogramowania obejmuje wiele wła

ś

ciwo

ś

ci, m.in.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

20

•

Niezawodno

ść

oprogramowania obejmuje wiele wła

ś

ciwo

ś

ci, m.in.

solidno

ść

, zabezpieczenia i bezpiecze

ń

stwo. Niezawodne systemy nie

powinny powodowa

ć

ani fizycznych, ani ekonomicznych katastrof, gdy

ulegn

ą

awarii

Efektywno

ść

•

Oprogramowanie nie powinno marnotrawi

ć

zasobów systemu takich

jak pami

ęć

lub czas procesora. Efektywno

ść

obejmuje zatem szybko

ść

reakcji, czas przetwarzania, u

ż

ycie pami

ę

ci itd.

U

ż

yteczno

ść

•

Oprogramowanie musi by

ć

u

ż

yteczne (bez zb

ę

dnego wysiłku) dla

u

ż

ytkowników, dla których je zaprojektowano. Oznacza to,

ż

e powinno mie

ć

odpowiedni interfejs u

ż

ytkownika i adekwatn

ą

dokumentacj

ę

Jakie s

ą

najistotniejsze wyzwania

dla in

ż

ynierów oprogramowania?

Wyzwanie dziedzictwa. Chocia

ż

wi

ę

kszo

ść

obecnie u

ż

ywanych du

ż

ych

systemów opracowano wiele lat temu, ci

ą

gle pełni

ą

powa

ż

ne funkcje

gospodarcze. Wyzwanie dziedzictwa polega zatem na piel

ę

gnacji i

modyfikacji takiego oprogramowania tak, aby unikn

ąć

przesadnych kosztów i

podtrzyma

ć

dostarczanie zasadniczych usług.

Wyzwanie ró

ż

norodno

ś

ci. Coraz cz

ęś

ciej wymaga si

ę

od systemów, aby

pracowały jako systemy rozproszone w sieci i obejmowały coraz wi

ę

cej

ró

ż

nych typów komputerów i rozmaitych rodzajów systemów

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

21

ró

ż

nych typów komputerów i rozmaitych rodzajów systemów

wspomagaj

ą

cych. Wyzwanie ró

ż

norodno

ś

ci polega zatem na

opracowywaniu metod budowy niezawodnego oprogramowania, które jest
wystarczaj

ą

co elastyczne, aby radzi

ć

sobie z ró

ż

norodno

ś

ci

ą

.

Wyzwanie dor

ę

czenia. Wiele tradycyjnych technik in

ż

ynierii

oprogramowania jest bardzo czasochłonnych. Czas, który pochłaniaj

ą

, jest

niezb

ę

dny do osi

ą

gni

ę

cia dobrej jako

ś

ci oprogramowania. Obecnie

gospodarka musi jednak natychmiast reagowa

ć

na zmiany i ewoluowa

ć

bardzo gwałtownie. Wyzwanie dor

ę

czenia polega na skróceniu czasu

dostarczenia wielkich zło

ż

onych systemów bez utraty ich jako

ś

ci.

Odpowiedzialno

ść

etyczna i zawodowa

In

ż

yniera oprogramowania zawiera szerszy

zakres odpowiedzialno

ś

ci ni

ż

tylko techniczne

przygotowanie in

ż

yniera.

In

ż

ynier musi post

ę

powa

ć

etycznie je

ż

eli chce

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

22

In

ż

ynier musi post

ę

powa

ć

etycznie je

ż

eli chce

by

ć

postrzegany jako profesjonalista

Zachowanie etyczne jest to co

ś

wi

ę

cej ni

ż

przestrzeganie prawa

Odpowiedzialno

ść

profesjonalisty

Zachowywanie tajemnicy. In

ż

ynierowie powinni zawsze dochowywa

ć

tajemnic powierzonych przez swych pracodawców i klientów, niezale

ż

nie od

tego, czy podpisano formaln

ą

umow

ę

o ochronie tajemnicy.

Kompetencja. In

ż

ynierowie nie powinni zawy

ż

a

ć

poziomu swoich

kompetencji. Nie powinni

ś

wiadomie przyjmowa

ć

prac, które przekraczaj

ą

ich mo

ż

liwo

ś

ci.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

23

Prawo własno

ś

ci intelektualnej. In

ż

ynierowie powinni zna

ć

miejscowe

prawo reguluj

ą

ce korzystanie z własno

ś

ci intelektualnej, takiej jak patenty,

prawo autorskie itd. Powinni szczególnie dba

ć

o poszanowanie intelektualnej

własno

ś

ci swoich pracodawców i klientów.

Niewła

ś

ciwe u

ż

ycie komputera. In

ż

ynierowie oprogramowania nie powinni

u

ż

ywa

ć

swoich technicznych umiej

ę

tno

ś

ci do niewła

ś

ciwego u

ż

ywania

cudzych komputerów. Niewła

ś

ciwe u

ż

ycie komputera mo

ż

e by

ć

do

ść

banalne (np. granie na maszynie pracodawcy) lub skrajnie powa

ż

ne

(rozsiewanie wirusów).

ACM/IEEE Kodeks etycznego

post

ę

powania (Code of Ethics)

Profesjonalne organizacje opracowały kodeks
etyczny.

Członkowie organizacji musieli przestrzega

ć

te

postanowienia

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

24

postanowienia

Kodeks etyki

Preambuła

•

Wersja skrócona kodeksu streszcza jego cele na wysokim poziomie
abstrakcji; postanowienia zawarte w wersji pełnej zawieraj

ą

przykłady i

szczegółowe informacje o tym, jak powinni

ś

my post

ę

powa

ć

b

ę

d

ą

c

prawdziwie profesjonalnymi in

ż

ynierami oprogramowania. Bez

okre

ś

lenia celów szczegóły mog

ą

wydawa

ć

si

ę

drobiazgowe i nudne.

Bez szczegółów cele b

ę

d

ą

brzmiały górnolotnie, ale pusto. Cele i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

25

Bez szczegółów cele b

ę

d

ą

brzmiały górnolotnie, ale pusto. Cele i

szczegóły razem wzi

ę

te stanowi

ą

spójny kodeks.

•

In

ż

ynierowie oprogramowania musz

ą

przyj

ąć

na siebie zobowi

ą

zanie

utwierdzenia analizy, specyfikacji, projektowania, budowy, testowania i
piel

ę

gnacji oprogramowania jako zawodu po

ż

ytecznego i szanowanego.

Zgodnie z tym zobowi

ą

zaniem wobec zdrowia, bezpiecze

ń

stwa i

dobrobytu społecze

ń

stwa, in

ż

ynierowie oprogramowania powinni

stosowa

ć

si

ę

do nast

ę

puj

ą

cych zasad:

Kodeks etyki

SPOŁECZE

Ń

STWO — In

ż

ynierowie oprogramowania powinni post

ę

powa

ć

dla dobra społecze

ń

stwa.

KLIENT I PRACODAWCA — In

ż

ynierowie oprogramowania powinni

post

ę

powa

ć

zgodnie z interesami swojego klienta lub pracodawcy zgodnymi

z dobrem społecze

ń

stwa.

PRODUKT — In

ż

ynierowie oprogramowania powinni zapewni

ć

,

ż

e ich

produkty i zwi

ą

zane z nimi zmiany spełniaj

ą

najwy

ż

sze standardy

profesjonalizmu.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

26

profesjonalizmu.

ROZS

Ą

DEK — In

ż

ynierowie oprogramowania powinni zachowywa

ć

rozs

ą

dek i niezale

ż

no

ść

swoich s

ą

dów.

ZARZ

Ą

DZANIE — Zarz

ą

dzaj

ą

cy in

ż

ynierami oprogramowania i

zwierzchnicy powinni przyj

ąć

i promowa

ć

etyk

ę

w zarz

ą

dzaniu tworzeniem i

piel

ę

gnacj

ą

oprogramowania.

PROFESJA — In

ż

ynierowie oprogramowania powinni podnosi

ć

wiarygodno

ść

i reputacj

ę

profesji zgodnie z dobrem społecze

ń

stwa.

KOLE

Ż

ENSTWO — In

ż

ynierowie oprogramowania powinni by

ć

uczciwi i

ch

ę

tni do pomocy swoim kolegom.

JA SAM — In

ż

ynierowie oprogramowania powinni bra

ć

udział w

długofalowej nauce praktyki swojego zawodu. Powinni tak

ż

e promowa

ć

etyczne działania w praktyce swej profesji.

Dylematy etyczne

Jak si

ę

zachowa

ć

je

ż

eli si

ę

nie zgadzamy z

przeło

ż

onym.

Jak si

ę

zachowa

ć

je

ż

eli pracodawca post

ę

puje

nieetycznie np. w sprawie projektów od których
zale

ż

y bezpiecze

ń

stwo ludzi (np. nie testuje do

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

27

zale

ż

y bezpiecze

ń

stwo ludzi (np. nie testuje do

ko

ń

ca systemu)

Staramy si

ę

rozwi

ą

zywa

ć

problemy szanuj

ą

c

pracodawc

ę

Dylematy etyczne

Czy bra

ć

udział w projektach sprzecznych z naszymi

zasadami (np. tworzenie wojskowych systemów
nuklearnych)

Na wst

ę

pie nale

ż

y przedstawi

ć

pracodawcy swoje

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

28

Na wst

ę

pie nale

ż

y przedstawi

ć

pracodawcy swoje

pogl

ą

dy.

Dalsza dyskusja spowodowała by przekształcenie
wykładu z in

ż

ynierii w wykład z filozofii…

Główne tezy in

ż

ynierii oprogramowania

In

ż

ynieria oprogramowania to dziedzina in

ż

ynierii, która

obejmuje wszystkie aspekty tworzenia oprogramowania.

Produkty programowe składaj

ą

si

ę

z utworzonych programów

oraz zwi

ą

zanej z nimi dokumentacji. Zasadniczymi atrybutami

produktów s

ą

zdatno

ść

do piel

ę

gnacji, niezawodno

ść

,

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

29

produktów s

ą

zdatno

ść

do piel

ę

gnacji, niezawodno

ść

,

efektywno

ść

i u

ż

yteczno

ść

.

Proces tworzenia oprogramowania składa si

ę

z czynno

ś

ci

prowadz

ą

cych do utworzenia produktu programowego.

Głównymi czynno

ś

ciami s

ą

specyfikacja oprogramowania,

tworzenie, zatwierdzanie i ewolucja.

Główne tezy in

ż

ynierii oprogramowania

Metody to uporz

ą

dkowane sposoby budowy oprogramowania.

Obejmuj

ą

sugestie wyboru procesu tworzenia, notacji, reguły

okre

ś

laj

ą

ce, jakie opisy systemu opracowa

ć

, a tak

ż

e wskazówki

projektowe.

Narz

ę

dzia CASE to systemy komputerowe, które s

ą

przeznaczone

do wspomagania rutynowych czynno

ś

ci procesu tworzenia takich jak

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

30

do wspomagania rutynowych czynno

ś

ci procesu tworzenia takich jak

praca nad diagramami projektowymi, sprawdzanie poprawno

ś

ci

diagramów oraz

ś

ledzenie wykonanych testów.

In

ż

ynierowie oprogramowania ponosz

ą

odpowiedzialno

ść

przed

kolegami po fachu i społecze

ń

stwem. Nie powinni zajmowa

ć

si

ę

jedynie aspektami technicznymi.

Stowarzyszenia zawodowe publikuj

ą

kodeksy post

ę

powania, które

definiuj

ą

standardy zachowania oczekiwane od swoich członków.

In

ż

ynieria systemów

komputerowych

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

31

komputerowych

Co to jest in

ż

ynieria systemów

komputerowych?

In

ż

ynieria systemów to czynno

ść

specyfikowania,

projektowania, implementowania, weryfikowania,
wdra

ż

ania i piel

ę

gnacji systemów postrzegana jako

cało

ść

. In

ż

ynierowie systemów nie zajmuj

ą

si

ę

tylko

oprogramowaniem, ale tak

ż

e sprz

ę

tem komputerowym

oraz interakcjami systemu z jego u

ż

ytkownikami i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

32

oraz interakcjami systemu z jego u

ż

ytkownikami i

ś

rodowiskiem.

Usługi, które system oferuje, ograniczenia, w ramach
których system musi by

ć

zbudowany i w których musi

działa

ć

, oraz interakcji ze

ś

rodowiskiem.

In

ż

ynierowie oprogramowania musz

ą

rozumie

ć

in

ż

ynieri

ę

systemów, (problemy in

ż

ynierii oprogramowania s

ą

cz

ę

sto wynikiem decyzji in

ż

ynierów systemów).

Co to jest system?

System jest celow

ą

kolekcj

ą

powi

ą

zanych ze

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

33

System jest celow

ą

kolekcj

ą

powi

ą

zanych ze

sob

ą

komponentów, które współpracuj

ą

, aby

osi

ą

gn

ąć

pewien cel.

Wła

ś

ciwo

ś

ci systemu

„Całkowity ci

ęż

ar” systemu jest to wła

ś

ciwo

ść

wła

ś

ciwo

ś

ci, któr

ą

mo

ż

na wyznaczy

ć

z wła

ś

ciwo

ś

ci

poszczególnych komponentów.

Niezawodno

ść

systemu zale

ż

y od niezawodno

ś

ci

komponentów systemu i zwi

ą

zków mi

ę

dzy nimi.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

34

komponentów systemu i zwi

ą

zków mi

ę

dzy nimi.

U

ż

yteczno

ść

systemu jest bardzo zło

ż

on

ą

wła

ś

ciwo

ś

ci

ą

,

która nie zale

ż

y jedynie od oprogramowania i sprz

ę

tu, ale

tak

ż

e od operatorów systemu i

ś

rodowiska, w którym si

ę

go u

ż

ywa.

Wła

ś

ciwo

ś

ci systemu - podsystemy

Wła

ś

ciwo

ś

ci funkcjonalne, które s

ą

widoczne, gdy

wszystkie cz

ęś

ci systemu współpracuj

ą

, aby osi

ą

gn

ąć

pewien cel. (Rower ma na przykład cech

ę

funkcjonaln

ą

bycia

ś

rodkiem transportu, gdy scali si

ę

go z jego cz

ęś

ci).

Wła

ś

ciwo

ś

ci niefunkcjonalne, takie jak niezawodno

ść

,

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

35

Wła

ś

ciwo

ś

ci niefunkcjonalne, takie jak niezawodno

ść

,

efektywno

ść

, bezpiecze

ń

stwo i zabezpieczenia. S

ą

zwi

ą

zane z zachowaniem systemu w jego

ś

rodowisku

pracy. Niektóre funkcje systemu mog

ą

nie by

ć

potrzebne

wszystkim jego u

ż

ytkownikom, a zatem system mo

ż

na

bez tych funkcji zaakceptowa

ć

. System, który jest jednak

zawodny lub zbyt wolny, b

ę

dzie prawdopodobnie

odrzucony przez wszystkich u

ż

ytkowników.

Czynniki wpływaj

ą

ce na niezawodno

ść

systemu

Niezawodno

ść

sprz

ę

tu - jakie jest prawdopodobie

ń

stwo

awarii komponentu sprz

ę

towego i jak długi jest czas jego

naprawy? (czy to musi by

ć

komponent sprz

ę

tu

komputerowego?)

Niezawodno

ść

oprogramowania - jakie jest

prawdopodobie

ń

stwo wytworzenia przez komponent

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

36

prawdopodobie

ń

stwo wytworzenia przez komponent

programowy bł

ę

dnych danych wyj

ś

ciowych? Awarie

oprogramowania istotnie ró

ż

ni

ą

si

ę

od awarii sprz

ę

tu,

poniewa

ż

oprogramowanie nie zu

ż

ywa si

ę

. Mo

ż

e dalej

działa

ć

nawet wówczas, gdy wytworzyło niepoprawny wynik.

Niezawodno

ść

operatora - jakie jest prawdopodobie

ń

stwo

bł

ę

du operatora systemu? (czy system jest zabezpieczony

przed nieautoryzowanym dost

ę

pem?, jakie mog

ą

by

ć

konsekwencje dost

ę

pu)

Systemy i ich

ś

rodowiska

Systemy nie s

ą

niezale

ż

nymi bytami, ale istniej

ą

w pewnym

ś

rodowisku.

Ś

rodowisko to ma wpływ

na funkcjonowanie i efektywno

ść

systemu.

Czasem

ś

rodowisko mo

ż

na uwa

ż

a

ć

za system

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

37

sam w sobie, ale w ogólniejszym wypadku
składa si

ę

ono z pewnej liczby oddziałuj

ą

cych na

siebie systemów.

Przykład systemu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

38

Czy in

ż

ynierowie systemu musz

ą

zna

ć

otoczenie systemu?

W wielu wypadkach system ma powodowa

ć

pewne zmiany w swoim

ś

rodowisku. (np.

ogrzewanie)

Na funkcjonowanie systemu mog

ą

mie

ć

wpływ

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

39

Na funkcjonowanie systemu mog

ą

mie

ć

wpływ

trudne do przewidzenia zmiany zachodz

ą

ce w

ś

rodowisku (np. zaniki napi

ę

cia, burze)

Czynniki wpływaj

ą

ce na projekt systemu

Zmiany procesu. Czy system wymaga zmian w procesach pracy
wykonywanej w

ś

rodowisku? Je

ś

li tak, to b

ę

d

ą

potrzebne szkolenia.

Je

ś

li zmiany s

ą

powa

ż

ne lub oznaczaj

ą

utrat

ę

pracy przez pewne

osoby, to istnieje niebezpiecze

ń

stwo sprzeciwu u

ż

ytkowników wobec

systemu.

Zmiany zawodu. Czy system zmniejsza umiej

ę

tno

ś

ci u

ż

ytkowników

i sprawia,

ż

e musz

ą

zmieni

ć

swój styl pracy? Je

ś

li tak, mog

ą

oni

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

40

i sprawia,

ż

e musz

ą

zmieni

ć

swój styl pracy? Je

ś

li tak, mog

ą

oni

aktywnie sabotowa

ć

wprowadzenie systemu do organizacji. Projekty,

które zmuszaj

ą

zarz

ą

dzaj

ą

cych do zmiany sposobu pracy tak, aby

dostosowa

ć

si

ę

do systemu komputerowego, bardzo cz

ę

sto nie s

ą

akceptowane. Mened

ż

erowie mog

ą

odczuwa

ć

,

ż

e systemy

umniejszyły ich rol

ę

w firmie.

Zmiany organizacyjne. Czy system zmienia struktur

ę

o

ś

rodków

władzy politycznej w organizacji? Je

ś

li firma zale

ż

y, na przykład, od

zło

ż

onego systemu, to osoby, które wiedz

ą

, jak si

ę

mm posługiwa

ć

,

maj

ą

wi

ę

ksz

ą

władz

ę

polityczn

ą

.

Co musimy wiedzie

ć

projektuj

ą

c system

Jakie ludzkie, społeczne i organizacyjne czynniki
wpływaj

ą

na proces.

Jak wykorzysta

ć

socjotechniki (w celu okre

ś

lenia wpływu

systemu na organizacj

ę

pracy)

W idealnej sytuacji powinna by

ć

znana wiedza o

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

41

W idealnej sytuacji powinna by

ć

znana wiedza o

ś

rodowisku – do którego ma by

ć

adresowany produkt

(system)

Wiedza o otoczeniu w którym ma pracowa

ć

system i

poprawne przeszkolenie z zasad działania systemu (np.
elektromagnetyczne bramki)

Modelowanie systemu

Najcz

ęś

ciej prezentowany jest diagram blokowy

zawieraj

ą

cy podsystemy i i poł

ą

czenia pomi

ę

dzy

nimi

W modelu architektury systemu mamy poł

ą

czone

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

42

W modelu architektury systemu mamy poł

ą

czone

ze sob

ą

elementy programowe i sprz

ę

towe-

cz

ę

sto bez wyra

ź

nego rozgraniczenia.

Przykładowy model systemu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

43

Komponenty funkcjonalne systemu

Komponenty detektorowe zbieraj

ą

informacje ze

ś

rodowiska

systemu. Przykładami takich komponentów s

ą

radary w systemie

kontroli lotów, detektory papieru w drukarkach laserowych i
termopara w piecu.

Komponenty efektorowe (uruchamiaj

ą

ce) powoduj

ą

zmiany w

ś

rodowisku systemu. Przykładami takich komponentów s

ą

zawory,

które otwieraj

ą

si

ę

i zamykaj

ą

, aby zwi

ę

kszy

ć

lub zmniejszy

ć

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

44

które otwieraj

ą

si

ę

i zamykaj

ą

, aby zwi

ę

kszy

ć

lub zmniejszy

ć

przepływ cieczy w rurze, stateczniki samolotu, które wyznaczaj

ą

kierunek lotu, i mechanizm wci

ą

gania papieru do drukarki, który

przesuwa papier za detektor papieru.

Komponenty obliczeniowe pobieraj

ą

dane wej

ś

ciowe, wykonuj

ą

na

nich pewne obliczenia i wytwarzaj

ą

wyniki. Przykładem takiego

komponentu jest procesor zmiennopozycyjny, który wykonuje
obliczenia na liczbach rzeczywistych.

Komponenty funkcjonalne systemu

Komponenty komunikacyjne umo

ż

liwiaj

ą

komunikacj

ę

innym

komponentom systemu. Przykładem takiego komponentu jest sie

ć

Ethernet ł

ą

cz

ą

ca ró

ż

ne komputery wewn

ą

trz budynku.

Komponenty koordynuj

ą

ce koordynuj

ą

operacje innych

komponentów. Przykładem takiego komponentu jest proces
szereguj

ą

cy w systemach czasu rzeczywistego, który decyduje,

kiedy poszczególne procesy powinny mie

ć

przydzielony procesor.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

45

kiedy poszczególne procesy powinny mie

ć

przydzielony procesor.

Komponenty interfejsu przetwarzaj

ą

dane w reprezentacji

u

ż

ywanej przez jedne komponenty na reprezentacje u

ż

ywane przez

inne komponenty. Przykładem mo

ż

e by

ć

komponent interfejsu do

komunikacji z człowiekiem, który pobiera pewien model systemu i
wy

ś

wietla go operatorowi. Innym przykładem jest przetwornik

analogowo-cyfrowy, który zamienia wej

ś

cie analogowe na wyj

ś

cie

cyfrowe.

Komponenty systemu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

46

Przykładowy system:

systemu kontroli lotów

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

47

Proces in

ż

ynierii systemów

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

48

Proces in

ż

ynierii systemów a proces

tworzenia oprogramowania

Wiele ró

ż

nych dziedzin in

ż

ynierii wchodzi w skład

in

ż

ynierii systemów. Liczba mo

ż

liwych nieporozumie

ń

jest ogromna, poniewa

ż

dla ró

ż

nych dziedzin in

ż

ynierii

posługujemy si

ę

odmienn

ą

terminologi

ą

.

Ograniczona mo

ż

liwo

ść

modyfikacji w trakcie tworzenia

systemu. Gdy pewne decyzje techniczne (np.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

49

systemu. Gdy pewne decyzje techniczne (np.
umiejscowienie radarów systemu kontroli lotów) s

ą

ju

ż

podj

ę

te, zmienianie ich jest bardzo kosztowne.

Przekształcenie projektu systemu tak, aby rozwi

ą

za

ć

takie problemy, jest mo

ż

liwe bardzo rzadko. Jedn

ą

z

przyczyn znaczenia oprogramowania w systemach jest
jego elastyczno

ść

— mo

ż

na dokonywa

ć

zmian w

odpowiedzi na nowe wymagania.

Interdyscyplinalno

ść

in

ż

ynierii systemów

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

50

Definicja wymaga

ń

systemowych

Abstrakcyjne wymagania opcjonalne. Podstawowe funkcje, które
system ma wypełnia

ć

, s

ą

definiowane na wysokim poziomie

abstrakcji. Szczegółowa specyfikacja wymaga

ń

funkcjonalnych ma

miejsce na poziomie podsystemów. Np. baza danych ruchu
samolotów (cez struktury bazy).

Wła

ś

ciwo

ś

ci systemu. S

ą

to niefunkcjonalne pojawiaj

ą

ce si

ę

wła

ś

ciwo

ś

ci systemu. Mo

ż

e to by

ć

dost

ę

pno

ść

, efektywno

ść

i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

51

wła

ś

ciwo

ś

ci systemu. Mo

ż

e to by

ć

dost

ę

pno

ść

, efektywno

ść

i

bezpiecze

ń

stwo. Te niefunkcjonalne wła

ś

ciwo

ś

ci systemu maj

ą

wpływ na wymagania stawiane wszystkim podsystemom.

Cechy, których system ma nie mie

ć

. W specyfikacji systemu

kontroli lotów mo

ż

na na przykład ustali

ć

,

ż

e system nie powinien

jednocze

ś

nie podawa

ć

kontrolerowi zbyt wiele informacji.

Przykłady wymaga

ń

systemu

Dostarczy

ć

antywłamaniowy i przeciwpo

ż

arowy system

alarmowy biurowca, który na zewn

ą

trz i we wn

ę

trzu

wyemituje ostrze

ż

enie o po

ż

arze lub włamaniu.

Zapewni

ć

, aby normalna praca w biurowcu nie była

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

52

Zapewni

ć

, aby normalna praca w biurowcu nie była

powa

ż

nie zakłócana przez po

ż

ary i włamania.

Zaprojektowa

ć

system ostrzegania przed trz

ę

sieniami

ziemi…..

Projektowanie systemu

Podział wymaga

ń

. Analizuje si

ę

i ł

ą

czy w grupy powi

ą

zane ze sob

ą

wymagania. W tej fazie procesu mo

ż

na utworzy

ć

kilka ró

ż

nych opcji.

Identyfikacja podsystemów. Podsystemy samodzielnie lub zespołowo
spełniaj

ą

wymagania. Grupy wymaga

ń

s

ą

zwykle skojarzone z

podsystemami, a zatem t

ę

czynno

ść

i grupowanie wymaga

ń

mo

ż

na ze sob

ą

poł

ą

czy

ć

.

Przypisywanie wymaga

ń

podsystemom. W praktyce nie mamy jednak

nigdy do czynienia z idealn

ą

zgodno

ś

ci

ą

podziału wymaga

ń

i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

53

nigdy do czynienia z idealn

ą

zgodno

ś

ci

ą

podziału wymaga

ń

i

zidentyfikowanych podsystemów. Z ogranicze

ń

narzuconych przez kupione

na zewn

ą

trz podsystemy mo

ż

e wynikn

ąć

konieczno

ść

zmiany wymaga

ń

.

Okre

ś

lenie funkcjonalno

ś

ci podsystemów. Specyfikuje si

ę

poszczególne

funkcje realizowane przez podsystemy. Czynno

ść

t

ę

mo

ż

na uwa

ż

a

ć

za

cz

ęść

fazy projektowania systemu albo fazy specyfikacji wymaga

ń

, gdy

podsystem jest systemem oprogramowania. Nale

ż

y tak

ż

e rozpozna

ć

zwi

ą

zki

mi

ę

dzy podsystemami.

Definicja interfejsów podsystemów. Definiuje si

ę

interfejsy oferowane i

wymagane przez poszczególne podsystemy. Po ich uzgodnieniu mo

ż

na

równolegle pracowa

ć

nad podsystemami.

Projektowanie systemu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

54

Tworzenie podsystemów

W czasie tworzenia podsystemów implementuje si

ę

podsystemy

zidentyfikowane w trakcie projektowania. Mo

ż

e to oznacza

ć

rozpocz

ę

cie kolejnego procesu in

ż

ynierii systemów dla

poszczególnych podsystemów. Je

ś

li jest to podsystem

oprogramowania, to prawdopodobnie rozpocznie si

ę

proces

tworzenia oprogramowania obejmuj

ą

cy gromadzenie wymaga

ń

,

projektowanie, implementacj

ę

itd.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

55

projektowanie, implementacj

ę

itd.

Proces tworzenia rzadko b

ę

dzie polegał na budowie wszystkich

podsystemów od zera. Zwykle kupienie istniej

ą

cego produktu jest

znacznie ta

ń

sze ni

ż

stworzenie własnego wyspecjalizowanego

komponentu. W tej fazie prawdopodobnie nale

ż

y cofn

ąć

si

ę

do

projektowania, aby przystosowa

ć

si

ę

do nowego kupionego

komponentu.

Integracja systemu

Integracja systemu polega na pobraniu niezale

ż

nie

zbudowanych podsystemów i scaleniu ich w jeden
kompletny system. Integracj

ę

mo

ż

na przeprowadzi

ć

za

pomoc

ą

podej

ś

cia „wielkiego wybuchu”, gdy wszystkie

podsystemy s

ą

integrowane w tym samym czasie. Z

powodów technicznych i mened

ż

erskich najlepiej jest

przyrostowo

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

56

powodów technicznych i mened

ż

erskich najlepiej jest

jednak integrowa

ć

przyrostowo, tzn. w jednym kroku

jest integrowany jeden system.

Zwykle nie da si

ę

ustali

ć

harmonogramów budowania

wszystkich podsystemów tak, aby ko

ń

czyły si

ę

w tym

samym czasie.

Integracja przyrostowa zmniejsza koszty wykrywania
bł

ę

dów.

Instalacja systemu - problemy

Ś

rodowisko, w którym system ma by

ć

zainstalowany, jest inne ni

ż

to,

które zakładali twórcy systemu. Jest to najcz

ęś

ciej wyst

ę

puj

ą

cy

problem w trakcie instalacji systemów oprogramowania. System
mo

ż

e na przykład korzysta

ć

z funkcji oferowanych przez specyficzn

ą

wersj

ę

systemu operacyjnego.

Potencjalni u

ż

ytkownicy systemu mog

ą

by

ć

wrogami jego

wprowadzenia. System mo

ż

e zmniejszy

ć

zakres ich

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

57

wprowadzenia. System mo

ż

e zmniejszy

ć

zakres ich

odpowiedzialno

ś

ci lub liczb

ę

stanowisk w firmie.

Nowy system ma koegzystowa

ć

z istniej

ą

cym systemem do czasu

przekonania firmy,

ż

e nowy system pracuje poprawnie. Instalacja

nowego systemu mo

ż

e nie by

ć

mo

ż

liwa bez usuni

ę

cia starego.

Próby z nowym systemem mog

ą

si

ę

zatem odbywa

ć

jedynie w

czasie, gdy stary system nie jest u

ż

ywany.

Mog

ą

wyst

ą

pi

ć

fizyczne problemy z instalacj

ą

. Wstawienie systemu

do istniej

ą

cego budynku mo

ż

e by

ć

niemo

ż

liwe z braku miejsca,

braku wymaganej klimatyzacji, zbyt itd. Je

ś

li system ma by

ć

instalowany w budynku zabytkowym, to jakiekolwiek przebudowy
b

ę

d

ą

prawdopodobnie zakazane.

Działanie systemu

Po zainstalowaniu system zaczyna działa

ć

. Uruchomienie systemu

mo

ż

e wymaga

ć

organizacji sesji szkoleniowych dla operatorów i

zmiany normalnego toku pracy, aby jak najefektywniej wykorzysta

ć

nowy system. Nie wykryte problemy mog

ą

pojawi

ć

si

ę

w tej fazie,

poniewa

ż

specyfikacja systemu mogła zawiera

ć

bł

ę

dne lub niepełne

dane

Jednym z problemów, które mog

ą

wyj

ść

na jaw dopiero po

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

58

Jednym z problemów, które mog

ą

wyj

ść

na jaw dopiero po

uruchomieniu systemu, jest współpraca nowego systemu z
istniej

ą

cymi ju

ż

systemami. Mog

ą

wyst

ą

pi

ć

fizyczne problemy z

niekompatybilno

ś

ci

ą

. Przeniesienie danych mi

ę

dzy systemami mo

ż

e

by

ć

trudne. Bardziej subtelne s

ą

problemy z bardzo ró

ż

ni

ą

cymi si

ę

interfejsami u

ż

ytkownika ró

ż

nych systemów. Wprowadzenie nowego

systemu mo

ż

e doprowadzi

ć

do zwi

ę

kszenia liczby bł

ę

dów

operatorów, poniewa

ż

operatorom mog

ą

si

ę

myli

ć

polecenia

dost

ę

pne w ró

ż

nych interfejsach u

ż

ytkownika.

Ewolucja systemu - koszty

Proponowane zmiany musz

ą

by

ć

bardzo starannie rozwa

ż

one z

punktu widzenia przedsi

ę

biorstwa i technologii. Musz

ą

by

ć

zaakceptowane przez rozmaite osoby, zanim b

ę

d

ą

wprowadzone.

Podsystemy nigdy nie s

ą

całkowicie niezale

ż

ne, zatem zmiany w

jednym systemie mog

ą

ź

le wpłyn

ąć

na zachowanie i efektywno

ść

innych podsystemów. Odpowiednie zmiany powinny by

ć

wi

ę

c

wprowadzone do tych podsystemów.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

59

wprowadzone do tych podsystemów.

Przyczyny pierwotnych decyzji projektowych zwykle nie s

ą

zapisywane. Osoby odpowiedzialne za ewolucj

ę

systemu musz

ą

ustali

ć

, dlaczego podj

ę

to takie a nie inne decyzje.

W miar

ę

starzenia si

ę

systemu jego struktura staje si

ę

coraz bardziej

skomplikowana przez zmiany, a koszt wprowadzenia nowych zmian
jest coraz wi

ę

kszy.

Likwidacja systemu

Likwidacja systemu oznacza wycofanie go po okresie jego
po

ż

ytecznego u

ż

ytkowania. Czasem jest to proste, niektóre jednak

systemy mog

ą

zawiera

ć

surowce niebezpieczne dla

ś

rodowiska.

W wypadku oprogramowania nie ma mowy o

ż

adnych fizycznych

problemach z likwidacj

ą

. Pewne funkcje oprogramowania mog

ą

jednak wyst

ę

powa

ć

w systemie po to, aby ułatwi

ć

proces likwidacji.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

60

Oprogramowanie mo

ż

e na przykład monitorowa

ć

stan innych

komponentów systemu. Gdy system ulega likwidacji, nie zu

ż

yte

komponenty mo

ż

na zidentyfikowa

ć

i ponownie u

ż

y

ć

.

Je

ś

li dane przechowywane w likwidowanym systemie musz

ą

by

ć

zachowane to nale

ż

y je przekształci

ć

i przenie

ść

do innego

systemu. Cz

ę

sto mo

ż

e si

ę

to wi

ą

za

ć

z wysokimi kosztami, poniewa

ż

struktury danych mog

ą

by

ć

niejawnie zdefiniowane w samym

oprogramowaniu.

Zaopatrywanie w system

Aby kupi

ć

lub podpisa

ć

kontrakt na projekt i

budow

ę

systemu, nale

ż

y najpierw na wysokim

poziomie abstrakcji opracowa

ć

specyfikacj

ę

tego, co system ma robi

ć

.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

61

Mo

ż

e si

ę

zdarzy

ć

,

ż

e taniej jest kupi

ć

system („z

półki”), ni

ż

go zaprojektowa

ć

, wyprodukowa

ć

i

zbudowa

ć

jako oddzielne przedsi

ę

wzi

ę

cie.

Proces zaopatrywania w system

Komponenty „z półki” zwykle nie spełniaj

ą

wymaga

ń

idealnie, chyba

ż

e napisano te wymagania z my

ś

l

ą

o tych wła

ś

nie komponentach.

Wybór systemu oznacza zatem znalezienie najlepszego
dopasowania mi

ę

dzy wymaganiami stawianymi systemowi a

mo

ż

liwo

ś

ciami systemów z półki.

Gdy system b

ę

dzie budowany na zamówienie, specyfikacja

wymaga

ń

jest podstaw

ą

kontraktu na zaopatrzenie w system. Jest to

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

62

wymaga

ń

jest podstaw

ą

kontraktu na zaopatrzenie w system. Jest to

wi

ę

c dokument zarówno prawniczy, jak i techniczny.

Po wybraniu wykonawcy systemu nast

ę

puje okres negocjacji

kontraktu, w trakcie którego uzgadnia si

ę

dalsze zmiany wymaga

ń

i

omawia ró

ż

ne sprawy, na przykład koszt zmian.

Proces zaopatrywania w system

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

63

In

ż

ynieria systemów - posumowanie

In

ż

ynieria systemów jest zło

ż

onym i trudnym procesem, który wymaga

wkładu pracy specjalistów wielu innych dziedzin in

ż

ynierii.

Pojawiaj

ą

ce si

ę

wła

ś

ciwo

ś

ci systemu s

ą

charakterystykami systemu jako

cało

ś

ci, a nie jego cz

ęś

ci składowych. S

ą

to m.in. efektywno

ść

,

niezawodno

ść

, u

ż

yteczno

ść

, bezpiecze

ń

stwo i zabezpieczenia. Powodzenie

lub pora

ż

ka systemu cz

ę

sto zale

ż

y od tych pojawiaj

ą

cych si

ę

wła

ś

ciwo

ś

ci.

Architektury systemów zwykle prezentuje si

ę

na diagramach blokowych,

przedstawiaj

ą

cych główne podsystemy i zwi

ą

zki mi

ę

dzy nimi.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

64

przedstawiaj

ą

cych główne podsystemy i zwi

ą

zki mi

ę

dzy nimi.

Typami komponentów funkcjonalnych systemu s

ą

komponenty detektorowe,

komponenty efektorowe, komponenty obliczeniowe, komponenty
koordynuj

ą

ce, komponenty komunikacyjne i komponenty interfejsu.

Proces in

ż

ynierii systemów obejmuje specyfikacj

ę

, projektowanie, tworzenie,

integracj

ę

i testowanie. Integracja systemu (ł

ą

czenie podsystemów od

ró

ż

nych dostawców tak, aby współpracowały) jest zwykle najtrudniejsza i

najwa

ż

niejsza.

Proces zaopatrywania w system obejmuje specyfikacj

ę

systemu, ogłoszenie

przetargu, wybór dostawcy i zawarcie kontraktu na dostaw

ę

systemu.

Niektóre cz

ęś

ci systemu komputerowego s

ą

kupowane jak komercyjne

komponenty z półki.

Proces tworzenia

oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

65

oprogramowania

Tworzenie oprogramowania

Specyfikowanie oprogramowania. Funkcjonalno

ść

oprogramowania i ograniczenia jego działania musz

ą

by

ć

zdefiniowane.

Projektowanie i implementowanie oprogramowania.
Oprogramowanie, które spełnia specyfikacj

ę

, musi by

ć

stworzone.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

66

stworzone.

Zatwierdzanie oprogramowania. Oprogramowanie musi
by

ć

zweryfikowane, aby zapewni

ć

,

ż

e robi to, czego

oczekiwał klient.

Ewolucja oprogramowania. Oprogramowanie musi
ewoluowa

ć

, aby spełnia

ć

zmieniaj

ą

ce si

ę

potrzeby

u

ż

ytkowników.

Modele procesów tworzenia

oprogramowania

Model kaskadowy. W tym modelu podstawowe czynno

ś

ci

specyfikowania, tworzenia, zatwierdzania i ewolucji s

ą

odr

ę

bnymi fazami

procesu takimi jak specyfikowanie wymaga

ń

, projektowanie

oprogramowania, implementacja, testowanie itd.

Tworzenie ewolucyjne. W tym procesie czynno

ś

ci specyfikowania,

projektowania i zatwierdzania przeplataj

ą

si

ę

. Pierwsza wersja systemu

powstaje bardzo szybko na podstawie abstrakcyjnych specyfikacji.
Pó

ź

niej jest udoskonalana zgodnie z informacjami otrzymanymi od

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

67

Pó

ź

niej jest udoskonalana zgodnie z informacjami otrzymanymi od

klienta. Prowadzi to do stworzenia systemu, który spełnia oczekiwania
klienta.

Tworzenie formalne systemu. To podej

ś

cie jest oparte na budowaniu

formalnych matematycznych specyfikacji systemu i przekształcaniu tych
specyfikacji w program za pomoc

ą

metod matematycznych. Weryfikacja

komponentów systemu polega na wnioskowaniu matematycznym o ich
zgodno

ś

ci ze specyfikacj

ą

.

Tworzenie z u

ż

yciem wielokrotnym. W tym podej

ś

ciu zakłada si

ę

istnienie du

ż

ej liczby komponentów zdatnych do ponownego u

ż

ycia.

Proces budowy systemu polega głównie na integrowaniu tych
fragmentów, a nie na tworzeniu ich od pocz

ą

tku.

Model kaskadowy

Definiowanie i analiza wymaga

ń

. Usługi, ograniczenia i cele systemu s

ą

ustalane w czasie narad z u

ż

ytkownikami systemu. S

ą

pó

ź

niej szczegółowo

definiowane i słu

żą

jako specyfikacja systemu.

Projektowanie systemu i oprogramowania. Proces projektowania systemu
prowadzi do podziału wymaga

ń

na systemy sprz

ę

tu i oprogramowania. Ustala

ogóln

ą

architektur

ę

systemu. Projektowanie oprogramowania obejmuje

identyfikowanie i opisywanie zasadniczych abstrakcji systemu oprogramowania i
zwi

ą

zki mi

ę

dzy nimi.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

68

zwi

ą

zki mi

ę

dzy nimi.

Implementacja i testowanie jednostek. W tym kroku projekt oprogramowania
jest realizowany w postaci zbioru programów albo jednostek programów.
Testowanie jednostek polega na sprawdzeniu, czy ka

ż

da jednostka spełnia

swoj

ą

specyfikacj

ę

.

Integracja i testowanie systemu. Jednostki programów albo programy s

ą

integrowane i testowane jako kompletne systemy, aby upewni

ć

si

ę

, czy

spełniono wymagania. Po zako

ń

czeniu testowania system jest dostarczany

klientowi.

Działanie i piel

ę

gnacja. Zwykle (chocia

ż

niekoniecznie) jest to najdłu

ż

sza faza

cyklu

ż

ycia. System jest zainstalowany i przekazany do praktycznego

u

ż

ytkowania. Piel

ę

gnacja obejmuje poprawianie bł

ę

dów, których nie wykryto we

wcze

ś

niejszych fazach cyklu

ż

ycia, poprawianie implementacji jednostek

systemu i wzbogacanie usług systemu w miar

ę

odkrywania nowych wymaga

ń

.

Model kaskadowy

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

69

Wady modelu kaskadowego

Wad

ą

modelu kaskadowego jest zawarty w nim

nieelastyczny podział na rozł

ą

czne etapy. Zobowi

ą

zania

musz

ą

by

ć

podejmowane w bardzo wczesnej fazie

procesu. Oznacza to trudno

ś

ci z reagowaniem na

zmieniaj

ą

ce si

ę

wymagania klienta.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

70

Model kaskadowy powinien by

ć

u

ż

ywany jedynie

wówczas, gdy wymagania s

ą

jasne i zrozumiałe. Ten

model odzwierciedla jednak normaln

ą

praktyk

ę

in

ż

yniersk

ą

. Procesy tworzenia oprogramowania oparte

na tym modelu s

ą

ci

ą

gle cz

ę

sto u

ż

ywane, a szczególnie

wtedy, kiedy s

ą

cz

ęś

ciami wi

ę

kszych przedsi

ę

wzi

ęć

in

ż

ynierii systemów.

Tworzenie ewolucyjne

Tworzenie ewolucyjne polega na opracowaniu
wst

ę

pnej implementacji, pokazaniu jej

u

ż

ytkownikowi z pro

ś

b

ą

o komentarze i

udoskonalaniu jej w wielu wersjach a

ż

do

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

71

powstania odpowiedniego systemu. Nie ma tu
oddzielnych czynno

ś

ci specyfikacji, tworzenia i

zatwierdzania, a s

ą

one raczej przeprowadzane

równolegle z szybkim reagowaniem na
informacje zwrotne.

Tworzenie ewolucyjne

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

72

Typy tworzenia ewolucyjnego

Tworzenie badawcze, w którym celem procesu jest praca
z klientem, polegaj

ą

ca na badaniu wymaga

ń

i

dostarczeniu ostatecznego systemu. Tworzenie
rozpoczyna si

ę

od tych cz

ęś

ci systemu, które s

ą

dobrze

rozpoznane. System ewoluuje przez dodawanie nowych
cech, które proponuje klient.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

73

cech, które proponuje klient.

Prototypowanie z porzuceniem, w którym celem procesu
tworzenia ewolucyjnego jest zrozumienie wymaga

ń

klienta i wypracowanie lepszej definicji wymaga

ń

stawianych systemowi. Budowanie prototypu ma głównie
na celu eksperymentowanie z tymi wymaganiami
u

ż

ytkownika, które s

ą

niejasne.

Zalety tworzenia ewolucyjnego

Najdokładniej odpowiadaj

ą

potrzebom

u

ż

ytkowników.

Zalet

ą

procesu tworzenia oprogramowania

opartego na podej

ś

ciu ewolucyjnym jest

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

74

opartego na podej

ś

ciu ewolucyjnym jest

przyrostowe opracowywanie specyfikacji.

Wypracowanie coraz lepszego zrozumienia
przez u

ż

ytkowników ich problemu znajduje swoje

odzwierciedlenie w systemie oprogramowanym.

Wady

Proces nie jest widoczny. Mened

ż

erowie potrzebuj

ą

regularnych wyników, aby mierzy

ć

post

ę

p prac. Je

ś

li

systemy s

ą

tworzone szybko, nie opłaca si

ę

generowa

ć

dokumentów opisuj

ą

cych ka

ż

d

ą

wersj

ę

systemu.

System ma zł

ą

struktur

ę

. Nieustaj

ą

ce modyfikacje

przyczyniaj

ą

si

ę

do psucia struktury oprogramowania.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

75

przyczyniaj

ą

si

ę

do psucia struktury oprogramowania.

Wprowadzanie nowych zmian w programach staje si

ę

coraz trudniejsze i bardziej kosztowne.

Konieczne mog

ą

by

ć

specjalne narz

ę

dzia i techniki.

Ułatwiaj

ą

szybkie tworzenie, ale mog

ą

by

ć

niekompatybilne z innymi narz

ę

dziami lub technikami.

Prawdopodobnie niewiele osób potrafi si

ę

nimi

posługiwa

ć

Tworzenie formalne systemów

Tworzenie formalne systemów jest podej

ś

ciem,

które ma wiele wspólnego z modelem
kaskadowym. Proces tworzenia jest tu jednak
oparty na matematycznych przekształceniach

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

76

specyfikacji systemu w program wykonywamy.

Ró

ż

nice w podej

ś

ciu formalnym a

kaskadowym

Specyfikacja wymaga

ń

stawianych

oprogramowaniu jest zapisywana w postaci
szczegółowej formalnej specyfikacji wyra

ż

onej

za pomoc

ą

notacji matematycznej.

Procesy projektowania, implementacji i

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

77

Procesy projektowania, implementacji i
testowania jednostek s

ą

zast

ą

pione przez proces

tworzenia z przekształceniem, w którym
specyfikacja formalna jest udoskonalana przez
ci

ą

g przekształce

ń

, które prowadz

ą

do powstania

programu.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

78

Przekształcenia formalne

W procesie przekształcania formalna matematyczna
reprezentacja systemu jest metodycznie przekształcana
w bardziej szczegółowe, ale wci

ąż

matematycznie

poprawne reprezentacje systemu. Ka

ż

dy krok dodaje

nowe detale i trwa to do chwili, w której specyfikacja

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

79

nowe detale i trwa to do chwili, w której specyfikacja
formalna stanie si

ę

równowa

ż

nym jej programem.

Przekształcenia s

ą

odpowiednio małe, co oznacza,

ż

e

wysiłek po

ś

wi

ę

cony na ich sprawdzenie nie jest

nadmierny. Mo

ż

na zatem zagwarantowa

ć

,

ż

e je

ś

li nie

było bł

ę

dów weryfikacji, to otrzymany program jest

naprawd

ę

implementacj

ą

wyj

ś

ciowej specyfikacji.

Przekształcenia formalne

Formalnie wykonuje si

ę

ka

ż

dy krok i dowodzi jego

poprawno

ś

ci. Nie ma testowania w poszukiwaniu usterek

w procesie, a testowanie systemu koncentruje si

ę

na

zapewnieniu niezawodno

ś

ci systemu.

Taki proces jest szczególnie przydatny do tworzenia

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

80

Taki proces jest szczególnie przydatny do tworzenia
systemów z surowymi wymaganiami bezpiecze

ń

stwa,

niezawodno

ś

ci i zabezpiecze

ń

. Podej

ś

cie formalne

upraszcza generowanie przypadków testuj

ą

cych

bezpiecze

ń

stwo i zabezpieczenia, które słu

żą

do

wykazywania klientom i instytucjom certyfikuj

ą

cym,

ż

e

system rzeczywi

ś

cie spełnia wymagania dotycz

ą

ce

bezpiecze

ń

stwa i zabezpiecze

ń

.

Stosowanie podej

ś

cia formalnego

Oprócz specjalistycznych dziedzin procesy oparte na
przekształceniach formalnych s

ą

u

ż

ywane rzadko.

Wymagaj

ą

specjalistycznej wiedzy i w praktyce okazuje

si

ę

,

ż

e w wypadku wi

ę

kszo

ś

ci systemów nie powoduj

ą

zmniejszenia kosztów lub polepszenia jako

ś

ci w

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

81

zmniejszenia kosztów lub polepszenia jako

ś

ci w

porównaniu z innymi podej

ś

ciami.

Główn

ą

tego przyczyn

ą

jest fakt,

ż

e interakcje systemów

nie poddaj

ą

si

ę

łatwo specyfikowaniu formalnemu, a to

wła

ś

nie jest bardzo du

ż

a cz

ęść

wysiłku tworzenia w

wi

ę

kszo

ś

ci systemów oprogramowanych.

Tworzenie z u

ż

yciem wielokrotnym

W wi

ę

kszo

ś

ci przedsi

ę

wzi

ęć

programistycznych

wyst

ę

puje u

ż

ycie wielokrotne oprogramowania.

Dzieje si

ę

to zwykle nieformalnie, gdy

zatrudnione osoby znaj

ą

projekty lub kody

programów podobne do tych wymaganych.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

82

programów podobne do tych wymaganych.
Szukaj

ą

ich, modyfikuj

ą

zgodnie z wymaganiami

i wł

ą

czaj

ą

do swojego systemu.

W podej

ś

ciu ewolucyjnym u

ż

ycie wielokrotne jest

cz

ę

sto uwa

ż

ane za podstaw

ę

szybkiego

tworzenia systemów.

Tworzenie z u

ż

yciem wielokrotnym

W metodzie z u

ż

yciem wielokrotnym zakłada si

ę

istnienie

wielkiego zbioru dost

ę

pnych komponentów

programowych u

ż

ycia wielokrotnego oraz integruj

ą

cej je

struktury. Niekiedy komponenty te s

ą

same w sobie

systemami, które dostarczaj

ą

specyficznej

funkcjonalno

ś

ci, np. formatowanie tekstu, obliczenia

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

83

funkcjonalno

ś

ci, np. formatowanie tekstu, obliczenia

numeryczne.

Pocz

ą

tkowa faza specyfikacji wymaga

ń

i faza

zatwierdzania s

ą

podobne do innych procesów; etapy

po

ś

rednie w procesie opartym na u

ż

yciu wielokrotnym s

ą

inne.

Etapy po

ś

rednie w metodzie

Analiza komponentów. Na podstawie specyfikacji wymaga

ń

poszukuje si

ę

komponentów implementuj

ą

cych t

ę

specyfikacj

ę

. Zwykle nie mo

ż

na znale

źć

idealnie pasuj

ą

cych komponentów; te, które mo

ż

na wykorzysta

ć

,

dostarczaj

ą

jedynie cz

ęść

wymaganej funkcjonalno

ś

ci.

Modyfikacja wymaga

ń

. W trakcie tej fazy analizuje si

ę

wymagania pod

k

ą

tem uzyskanych komponentów. Nast

ę

pnie modyfikuje si

ę

wymagania, aby

odzwierciedlały dost

ę

pne komponenty. Je

ś

li modyfikacje nie s

ą

mo

ż

liwe, to

czynno

ść

analizy komponentów mo

ż

e by

ć

powtórzona w celu poszukiwania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

84

czynno

ść

analizy komponentów mo

ż

e by

ć

powtórzona w celu poszukiwania

innych rozwi

ą

za

ń

.

Projektowanie systemu z u

ż

yciem wielokrotnym. Projektanci bior

ą

pod

uwag

ę

ponownie u

ż

yte komponenty i tworz

ą

zgodnie z ich wymaganiami.

Pewne nowe fragmenty oprogramowania mog

ą

by

ć

potrzebne, je

ś

li nie s

ą

dost

ę

pne komponenty u

ż

ycia wielokrotnego.

Tworzenie i integracja. Tworzy si

ę

oprogramowanie, którego nie mo

ż

na

było kupi

ć

. Integruje si

ę

w system komponenty i zakupione systemy. W tym

modelu integracja systemu mo

ż

e by

ć

cz

ęś

ci

ą

procesu tworzenia, a nie

oddzieln

ą

czynno

ś

ci

ą

.

Zalety

Model oparty na u

ż

yciu wielokrotnym ma

oczywist

ą

przewag

ę

nad innymi redukuje ilo

ść

tworzonego oprogramowania, zmniejsza zatem
koszt i zagro

ż

enia.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

85

Zwykle powoduje tak

ż

e szybsze dostarczenie

oprogramowania. Kompromisy zwi

ą

zane z

wymaganiami s

ą

tu jednak nieodzowne, co mo

ż

e

oznacza

ć

,

ż

e system nie b

ę

dzie spełniał

rzeczywistych potrzeb u

ż

ytkowników.

Wady

Traci si

ę

cz

ęść

kontroli nad ewolucj

ą

systemu,

poniewa

ż

firma korzystaj

ą

ca z komponentów

u

ż

ycia wielokrotnego nie ma wpływu na ich nowe

wersje.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

86

Koniec poprzedniego…..

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

87

Podej

ś

cia hybrydowe (iteracja procesu)

Tworzenie przyrostowe, w którym specyfikacja,
projektowanie i implementacja s

ą

podzielone na ci

ą

g

po kolei realizowanych przyrostów.

Tworzenie spiralne, w którym system rozwija si

ę

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

88

Tworzenie spiralne, w którym system rozwija si

ę

ruchem spiralnym na zewn

ą

trz od pocz

ą

tkowego

szkicu do ko

ń

cowego systemu.

Podej

ś

cia hybrydowe (iteracja procesu)

Istot

ą

procesu iteracyjnego jest to,

ż

e specyfikacja

jest opracowywana w poł

ą

czeniu z

oprogramowaniem.

Pełna specyfikacja systemu jest cz

ęś

ci

ą

kontraktu

na jego tworzenie. W wypadku tworzenia

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

89

na jego tworzenie. W wypadku tworzenia
przyrostowego nie ma pełnej specyfikacji a

ż

do

chwili wyspecyfikowania ostatniego przyrostu. To
wymaga nowej formuły kontraktów, która mo

ż

e by

ć

trudna do zaakceptowania przez powa

ż

nych

klientów, na przykład agencje rz

ą

dowe.

Tworzenie przyrostowe

Podej

ś

cie ewolucyjne do tworzenia umo

ż

liwia odło

ż

enie

w czasie decyzji projektowych i dotycz

ą

cych wymaga

ń

,

ale prowadzi do zbudowania oprogramowania o złej
strukturze, trudnego do zrozumienia i piel

ę

gnacji.

Model kaskadowy tworzenia zmusza klientów do

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

90

Model kaskadowy tworzenia zmusza klientów do
zatwierdzenia pewnego zbioru wymaga

ń

, zanim

rozpocznie si

ę

projektowanie. Zmusza równie

ż

projektantów do zatwierdzenia konkretnych strategii
projektowych przed przyst

ą

pieniem do implementacji.

Tworzenie przyrostowe jest podej

ś

ciem po

ś

rednim, które

ł

ą

czy w sobie zalety obu tych modeli.

Tworzenie przyrostowe

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

91

Tworzenie przyrostowe - zalety

Klienci nie musz

ą

czeka

ć

na dostarczenie całego systemu, zanim

zaczn

ą

czerpa

ć

z niego korzy

ś

ci.

Klienci mog

ą

u

ż

ywa

ć

wst

ę

pnych przyrostów jako rodzaju prototypu i

zdobywa

ć

do

ś

wiadczenia, które inspiruj

ą

wymagania wobec

pó

ź

niejszych przyrostów.

Ryzyko całkowitej pora

ż

ki przedsi

ę

wzi

ę

cia jest mniejsze. Chocia

ż

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

92

Ryzyko całkowitej pora

ż

ki przedsi

ę

wzi

ę

cia jest mniejsze. Chocia

ż

mog

ą

pojawi

ć

si

ę

problemy w niektórych przyrostach,

prawdopodobnie wiele usług b

ę

dzie z powodzeniem dostarczone

klientowi.

Usługi o najwy

ż

szym priorytecie b

ę

d

ą

dostarczone jako pierwsze, a

pó

ź

niejsze przyrosty b

ę

d

ą

z nimi integrowane, a zatem

najwa

ż

niejsze usługi systemu b

ę

d

ą

najdokładniej przetestowane.

Oznacza to,

ż

e klienci maj

ą

mniejsz

ą

szans

ę

dozna

ć

awarii

oprogramowania najbardziej istotnych cz

ęś

ci systemu.

Tworzenie przyrostowe - wady

Mo

ż

e by

ć

trudno przypisa

ć

wymagania klienta do

przyrostów odpowiedniej wielko

ś

ci. Co wi

ę

cej, wi

ę

kszo

ść

systemów wymaga zbioru podstawowych udogodnie

ń

,

które s

ą

u

ż

ywane przez ró

ż

ne cz

ęś

ci systemu. Skoro

wymagania nie s

ą

szczegółowo zdefiniowane przed

implementacj

ą

przyrostu, trudno jest zidentyfikowa

ć

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

93

implementacj

ą

przyrostu, trudno jest zidentyfikowa

ć

wspólne udogodnienia potrzebne wszystkim przyrostom.

Ewolucja podej

ś

cia przyrostowego doprowadziła ostatnio

do powstania tzw. „programowania ekstremalnego”.
Opiera si

ę

ono na tworzeniu i dostarczaniu bardzo

małych przyrostów funkcjonalno

ś

ci, wł

ą

czeniu klienta w

cały proces, ustawicznym poprawianiu kodu.

Tworzenie spiralne

Proces nie jest tu przedstawiany jako ci

ą

g

czynno

ś

ci z pewnymi nawrotami od jednej do

drugiej, ale ma posta

ć

spirali. Ka

ż

da p

ę

tla tej

spirali reprezentuje jedn

ą

faz

ę

procesu.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

94

Najbardziej wewn

ę

trzna p

ę

tla mo

ż

e by

ć

wi

ę

c

po

ś

wi

ę

cona wykonalno

ś

ci systemu, nast

ę

pna

definicji wymaga

ń

stawianych systemowi, kolejna

projektowaniu systemu itd. Ka

ż

da p

ę

tla spirali

jest podzielona na cztery sektory

Tworzenie spiralne

Ustalanie celów. Definiuje si

ę

konkretne cele tej fazy przedsi

ę

wzi

ę

cia.

Identyfikuje si

ę

ograniczenia, którym podlega proces i produkt. Rysuje si

ę

szczegółowe plany zarz

ą

dzania. Rozpoznaje zagro

ż

enia przedsi

ę

wzi

ę

cia.

Rozpoznanie i redukcja zagro

ż

e

ń

. Przeprowadza si

ę

szczegółow

ą

analiz

ę

ka

ż

dego z rozpoznanych zagro

ż

e

ń

przedsi

ę

wzi

ę

cia. Podejmuje si

ę

kroki

zmierzaj

ą

ce do redukcji tych zagro

ż

e

ń

. Je

ś

li zagra

ż

a nam na przykład to,

ż

e

wymagania s

ą

nieodpowiednie, mo

ż

na opracowa

ć

prototyp systemu

Tworzenie i zatwierdzanie. Po ocenie zagro

ż

e

ń

wybiera si

ę

model

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

95

Tworzenie i zatwierdzanie. Po ocenie zagro

ż

e

ń

wybiera si

ę

model

tworzenia systemu. Je

ś

li najpowa

ż

niejsze zagro

ż

enie jest zwi

ą

zane z

interfejsem u

ż

ytkownika, to odpowiednim modelem tworzenia mo

ż

e by

ć

prototypowanie ewolucyjne. Je

ś

li najbardziej zagro

ż

one jest

bezpiecze

ń

stwo, to tworzenie oparte na przekształceniach formalnych mo

ż

e

by

ć

najwła

ś

ciwsze itd. Model kaskadowy mo

ż

e by

ć

uzasadniony w wypadku,

gdy głównym rozpoznanym ryzykiem jest integracja podsystemów.

Planowanie. Recenzuje si

ę

przedsi

ę

wzi

ę

cie i podejmuje decyzj

ę

, czy

rozpoczyna

ć

nast

ę

pn

ą

p

ę

tl

ę

spirali. Je

ś

li jest ona pozytywna, to planuje si

ę

nast

ę

pn

ą

faz

ę

przedsi

ę

wzi

ę

cia.

Tworzenie spiralne

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

96

Tworzenie spiralne

Wa

ż

n

ą

cech

ą

odró

ż

niaj

ą

c

ą

model spiralny od innych

modeli procesów jest wyst

ę

puj

ą

ce w tym modelu jawne

potraktowanie zagro

ż

e

ń

. Nieformalnie, zagro

ż

enie to

po prostu co

ś

, co mo

ż

e pój

ść

ź

le.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

97

Je

ś

li mamy na przykład zamiar u

ż

y

ć

nowy j

ę

zyk

programowania, to zagro

ż

eniem jest zawodno

ść

dost

ę

pnych kompilatorów lub to,

ż

e mog

ą

generowa

ć

nie

do

ść

efektywny kod po

ś

redni. Kłopoty przedsi

ę

wzi

ę

cia,

na przykład przekroczenie kosztów lub harmonogramu,
równie

ż

powoduj

ą

zagro

ż

enie.

Specyfikowanie oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

98

Specyfikowanie oprogramowania

Specyfikowanie wymaga

ń

Studium wykonalno

ś

ci. Ocenia si

ę

, czy rozpoznane potrzeby

u

ż

ytkowników mog

ą

by

ć

spełnione przy obecnych technologiach sprz

ę

tu i

oprogramowania. Studium pozwoli zdecydowa

ć

, czy proponowany system

b

ę

dzie opłacalny z punktu widzenia ekonomii oraz czy mo

ż

na system ten

zbudowa

ć

w ramach zało

ż

onego bud

ż

etu.

Okre

ś

lanie i analiza wymaga

ń

. Jest to proces okre

ś

lania wymaga

ń

stawianych systemowi na podstawie obserwacji istniej

ą

cych systemów,

rozmów z potencjalnymi u

ż

ytkownikami i zaopatrzeniowcami, analizy zada

ń

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

99

rozmów z potencjalnymi u

ż

ytkownikami i zaopatrzeniowcami, analizy zada

ń

itd.

Specyfikowanie wymaga

ń

. Jest czynno

ś

ci

ą

polegaj

ą

c

ą

na zapisywaniu

informacji zebranych w czasie analizy w dokumencie definiuj

ą

cym zbiór

wymaga

ń

. Mog

ą

w nim pojawi

ć

si

ę

dwa rodzaje wymaga

ń

. Wymagania

u

ż

ytkownika s

ą

abstrakcyjnymi okre

ś

leniami wymaga

ń

stawianych

systemowi spisanymi dla klienta i u

ż

ytkownika. Wymagania systemowe s

ą

bardziej szczegółowym opisem funkcjonalno

ś

ci, któr

ą

nale

ż

y dostarczy

ć

.

Zatwierdzanie wymaga

ń

. W tej czynno

ś

ci sprawdza si

ę

realizm, spójno

ść

i

kompletno

ść

wymaga

ń

. W jej trakcie niemal pewne jest wykrycie bł

ę

dów.

Nast

ę

pnie nale

ż

y zmodyfikowa

ć

dokumentacj

ę

wymaga

ń

tak, aby usun

ąć

te

bł

ę

dy.

Specyfikowanie wymaga

ń

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

100

Projektowanie i implementowanie

oprogramowania

Faza implementowania w tworzeniu oprogramowania to
proces przekształcania specyfikacji systemu w działaj

ą

cy

system.

Projekt oprogramowania to opis struktury
oprogramowania, które ma by

ć

zaimplementowane,

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

101

oprogramowania, które ma by

ć

zaimplementowane,

danych, które s

ą

cz

ęś

ci

ą

systemu, interfejsów mi

ę

dzy

komponentami systemu i u

ż

ytych algorytmów.

Ko

ń

cowym wynikiem tego procesu jest precyzyjna

specyfikacja algorytmów i struktur danych, które nale

ż

y

zaimplementowa

ć

.

Projektowanie i implementowanie

oprogramowania

Projektowanie architektury. Identyfikuje i dokumentuje si

ę

podsystemy

tworz

ą

ce system oraz zwi

ą

zki mi

ę

dzy nimi.

Specyfikowanie abstrakcyjne. Opracowuje si

ę

abstrakcyjn

ą

specyfikacj

ę

usług ka

ż

dego podsystemu oraz ogranicze

ń

, w ramach których musi

pracowa

ć

.

Projektowanie interfejsów. Projektuje i dokumentuje si

ę

interfejsy ka

ż

dego

podsystemu z innymi podsystemami. Specyfikacja interfejsów musi by

ć

jednoznaczna, poniewa

ż

umo

ż

liwia korzystanie z podsystemów bez

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

102

jednoznaczna, poniewa

ż

umo

ż

liwia korzystanie z podsystemów bez

znajomo

ś

ci ich działania.

Projektowanie komponentów. Przypisuje si

ę

usługi do ró

ż

nych

komponentów i projektuje interfejsy tych komponentów.

Projektowanie struktur danych. Szczegółowo specyfikuje si

ę

i projektuje

struktury danych u

ż

yte w implementacji systemu.

Projektowanie algorytmów. Szczegółowo specyfikuje si

ę

i projektuje

algorytmy słu

żą

ce do realizacji usług.

Projektowanie i implementowanie

oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

103

Metody projektowania

Metodyczne podej

ś

cia do projektowania oprogramowania

zaproponowano w „metodach strukturalnych”, które s

ą

zbiorami

notacji i porad dla projektantów oprogramowania.

U

ż

ycie metod strukturalnych polega zwykle na opracowaniu

graficznych modeli systemu i prowadzi do utworzenia ogromnej ilo

ś

ci

dokumentacji projektowej. Metody strukturalne były z powodzeniem
u

ż

ywane w wielu ogromnych przedsi

ę

wzi

ę

ciach. Mog

ą

doprowadzi

ć

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

104

u

ż

ywane w wielu ogromnych przedsi

ę

wzi

ę

ciach. Mog

ą

doprowadzi

ć

do istotnego zmniejszenia kosztów, poniewa

ż

obejmuj

ą

standardowe

notacje i zapewniaj

ą

powstanie standardowej dokumentacji

projektowej.

Metoda strukturalna zawiera model procesu projektowania, notacje
do zapisu projektu, formaty raportów, zasady i porady dla
projektantów.

Metody strukturalne

Model przepływu danych, w którym system jest
opisywany za pomoc

ą

przekształce

ń

danych

wykonywanych w trakcie ich przetwarzania.

Model encja-zwi

ą

zek, który słu

ż

y do opisu

podstawowych encji w projekcie i zwi

ą

zków mi

ę

dzy nimi.

Modele encja-zwi

ą

zek s

ą

przyj

ę

t

ą

technik

ą

opisu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

105

Modele encja-zwi

ą

zek s

ą

przyj

ę

t

ą

technik

ą

opisu

struktury baz danych.

Model strukturalny, w którym dokumentuje si

ę

komponenty systemu i ich interakcje.

Metody obiektowe zawieraj

ą

model dziedziczenia w

systemie, modele statycznych i dynamicznych zwi

ą

zków

mi

ę

dzy obiektami oraz modele interakcji obiektów w

czasie działania systemu.

Programowanie i wyszukiwanie bł

ę

dów

Tworzenie programu, który implementuje system, nast

ę

puje zwykle

po procesie projektowania systemu. W wielu wypadkach programista
musi doda

ć

jedynie szczegóły operacji ka

ż

dego komponentu

programu.

Programowanie jest indywidualn

ą

czynno

ś

ci

ą

i nie istnieje

ż

aden

ogólny proces, zgodnie z którym si

ę

post

ę

puje. Niektórzy

programi

ś

ci zaczn

ą

od komponentów, które rozumiej

ą

, utworz

ą

je, a

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

106

programi

ś

ci zaczn

ą

od komponentów, które rozumiej

ą

, utworz

ą

je, a

potem przejd

ą

do pracy z mniej zrozumiałymi komponentami. Inni

post

ą

pi

ą

odwrotnie, pozostawiaj

ą

c znajome komponenty na koniec,

poniewa

ż

wiedz

ą

, jak je utworzy

ć

.

Niektórzy programi

ś

ci lubi

ą

wcze

ś

nie definiowa

ć

dane, a potem

u

ż

ywa

ć

ich do kierowania pisaniem programów. Inni pozostawi

ą

dane bez specyfikacji tak długo, jak to tylko jest mo

ż

liwe.

Programowanie i wyszukiwanie bł

ę

dów

Programi

ś

ci wykonuj

ą

pewne testy kodu, który napisali. Cz

ę

sto

prowadzi to do wykrycia bł

ę

dów, które nale

ż

y usun

ąć

z programu.

Czynno

ść

ta nosi nazw

ę

usuwania bł

ę

dów.

Testowanie usterek i usuwanie bł

ę

dów to dwa ró

ż

ne procesy.

Testowanie wykazuje istnienie bł

ę

dów. Usuwanie bł

ę

dów polega na

ich lokalizacji i poprawieniu.

Usterki w kodzie nale

ż

y zlokalizowa

ć

i zmodyfikowa

ć

program tak,

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

107

Usterki w kodzie nale

ż

y zlokalizowa

ć

i zmodyfikowa

ć

program tak,

aby spełnił wymagania. Testowanie nale

ż

y powtarza

ć

, aby zapewni

ć

wła

ś

ciwe wprowadzenie zmian.

Proces usuwania bł

ę

dów jest zatem cz

ęś

ci

ą

zarówno tworzenia, jak i

testowania oprogramowania.

Zatwierdzanie i testowanie

oprogramowania

Zatwierdzanie oprogramowania lub bardziej ogólnie weryfikacja i
zatwierdzanie maj

ą

wykaza

ć

,

ż

e system jest zgodny ze swoj

ą

specyfikacj

ą

i spełnia oczekiwania klienta, który go kupuje. Obejmuje

proces sprawdzania, m.in. kontrole i recenzje w ka

ż

dym kroku

procesu tworzenia od definicji wymaga

ń

u

ż

ytkownika do pisania

programów. Wi

ę

kszo

ść

kosztów zatwierdzania powstaje po

zaimplementowaniu, gdy testuje si

ę

działaj

ą

cy system.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

108

zaimplementowaniu, gdy testuje si

ę

działaj

ą

cy system.

Z wyj

ą

tkiem małych programów, nie nale

ż

y testowa

ć

systemu jako

pojedynczej, monolitycznej cało

ś

ci. Wielkie systemy buduje si

ę

z

podsystemów, te s

ą

z kolei składane z modułów, w skład których

wchodz

ą

procedury i funkcje. Proces testowania powinien by

ć

zatem

wykonywany w wielu krokach, w których testuje si

ę

przyrostowo

jednocze

ś

nie z implementowaniem systemu.

Zatwierdzanie i testowanie

oprogramowania

Testowanie jednostek. Testuje si

ę

poszczególne komponenty, aby

zapewni

ć

.

ż

e działaj

ą

poprawnie. Ka

ż

dy komponent jest niezale

ż

nie

testowany bez udziału innych komponentów systemu.

Testowanie modułów. Moduł jest kolekcj

ą

niezale

ż

nych

komponentów takich jak klasy obiektów, abstrakcyjne typy danych,
albo bardziej lu

ź

n

ą

kolekcj

ą

procedur i funkcji. Moduł zamyka w

sobie powi

ą

zane komponenty, mo

ż

na go zatem testowa

ć

bez

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

109

sobie powi

ą

zane komponenty, mo

ż

na go zatem testowa

ć

bez

udziału innych modułów systemu.

Testowanie podsystemów. Ta faza obejmuje testowanie kolekcji
modułów, które zintegrowano w podsystemie. W wypadku wielkich
systemów głównymi napotykanymi tu problemami s

ą

niezgodno

ś

ci

interfejsów. Proces testowania podsystemu powinien zatem
prowadzi

ć

do wykrycia bł

ę

dów w interfejsach modułów przez

intensywne próbkowanie tych interfejsów.

Zatwierdzanie i testowanie

oprogramowania

Testowanie systemu. Podsystemy zintegrowano ju

ż

w system. Ten

proces testowania ma wykry

ć

bł

ę

dy wynikaj

ą

ce z nie przewidzianych

interakcji mi

ę

dzy podsystemami i problemów z interfejsami

podsystemów. W tej fazie sprawdza si

ę

tak

ż

e, czy system spełnia

stawiane mu wymagania funkcjonalne i niefunkcjonalne. Bada si

ę

tak

ż

e pojawiaj

ą

ce si

ę

wła

ś

ciwo

ś

ci systemu.

Testowanie odbiorcze. Jest to ko

ń

cowa faza procesu testowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

110

Testowanie odbiorcze. Jest to ko

ń

cowa faza procesu testowania

przed przyj

ę

ciem systemu do u

ż

ytkowania. System testuje si

ę

za

pomoc

ą

danych dostarczonych przez u

ż

ytkownika, a nie danych

symulowanych. Testowanie odbiorcze mo

ż

e doprowadzi

ć

do

wykrycia bł

ę

dów i zaniedba

ń

w definicji wymaga

ń

stawianych

systemowi, poniewa

ż

prawdziwe dane wypróbowuj

ą

system w

zupełnie inny sposób ni

ż

dane testowe. Testowanie odbiorcze mo

ż

e

równie

ż

ujawni

ć

problemy z wymaganiami polegaj

ą

ce na tym,

ż

e

udogodnienia systemu nie w pełni odpowiadaj

ą

potrzebom

u

ż

ytkowników lub efektywno

ść

systemu jest nie do zaakceptowania.

Zatwierdzanie i testowanie

oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

111

Fazy testowania w procesie tworzenia

oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

112

Fazy testowania w procesie tworzenia

oprogramowania

Za testowanie jednostek i testowanie modułów zwykle odpowiadaj

ą

programi

ś

ci, którzy utworzyli komponent. Programi

ś

ci opracowuj

ą

własne dane testowe i przyrostowo testuj

ą

swój kod w miar

ę

jego

tworzenia. Takie podej

ś

cie jest sensowne ekonomicznie, poniewa

ż

to wła

ś

nie programista zna najlepiej swój komponent, jest zatem

najwła

ś

ciwsz

ą

osob

ą

do wygenerowania danych testowych.

Testowanie jednostek jest cz

ęś

ci

ą

procesu implementacji. Oczekuje

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

113

Testowanie jednostek jest cz

ęś

ci

ą

procesu implementacji. Oczekuje

si

ę

,

ż

e w wyniku tego procesu b

ę

dzie dostarczony komponent

zgodny ze swoj

ą

specyfikacj

ą

.

Pó

ź

niejsze fazy testowania obejmuj

ą

integracj

ę

prac wielu

programistów; nale

ż

y je uprzednio zaplanowa

ć

. Powinien je

wykonywa

ć

niezale

ż

ny zespół testerów na podstawie wcze

ś

niej

zapisanych planów testów opracowanych na podstawie specyfikacji i
projektu systemu.

Fazy testowania w procesie tworzenia

oprogramowania

Testowanie odbiorcze jest czasem nazywane testowaniem alfa.
Systemy na zamówienie s

ą

tworzone dla jednego klienta. Proces

testowania alfa trwa do chwili, w której wytwórca systemu i klient
zgodz

ą

si

ę

,

ż

e dostarczony system jest mo

ż

liw

ą

do przyj

ę

cia

implementacj

ą

wymaga

ń

stawianych systemowi.

Je

ś

li system jest sprzedawany jako produkt programowy, cz

ę

sto

stosuje si

ę

proces testowania zwany testowaniem beta. Testowanie

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

114

stosuje si

ę

proces testowania zwany testowaniem beta. Testowanie

beta polega na dostarczeniu systemu pewnej liczbie potencjalnych
klientów, którzy zgodzili si

ę

z niego korzysta

ć

. Informuj

ą

oni

wytwórców o pojawiaj

ą

cych si

ę

problemach. Sprawia to,

ż

e produkt

podlega prawdziwemu u

ż

ytkowaniu i umo

ż

liwia wykrycie bł

ę

dów,

których nie przewidzieli budowniczowie systemu. Po otrzymaniu tych
zwrotnych informacji modyfikuje si

ę

system i udost

ę

pnia do dalszego

testowania beta lub do ogólnego u

ż

ytku.

Ewolucja oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

115

Ewolucja oprogramowania

Elastyczno

ść

systemów oprogramowanych jest jedn

ą

z

głównych przyczyn,

ż

e coraz wi

ę

cej oprogramowania

wł

ą

cza si

ę

do wielkich, zło

ż

onych systemów.

Po podj

ę

ciu decyzji o wyprodukowaniu sprz

ę

tu zmiany w

jego projekcie s

ą

bardzo kosztowne.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

116

jego projekcie s

ą

bardzo kosztowne.

W wypadku oprogramowania zmiany mog

ą

by

ć

jednak

wprowadzane w ka

ż

dej chwili tworzenia lub nawet po

jego zako

ń

czeniu. Koszt tych zmian mo

ż

e by

ć

bardzo

wysoki, ale wci

ąż

b

ę

dzie ni

ż

szy ni

ż

odpowiednie zmiany

w sprz

ę

cie systemu.

Ewolucja oprogramowania

Od dawna istniało wyra

ź

ne rozgraniczenie mi

ę

dzy

procesem tworzenia oprogramowania a procesem
ewolucji oprogramowania (piel

ę

gnacji oprogramowania).

Tworzenie oprogramowania jest uwa

ż

ane za czynno

ść

twórcz

ą

, w której system oprogramowany ze wst

ę

pnego

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

117

twórcz

ą

, w której system oprogramowany ze wst

ę

pnego

pomysłu staje si

ę

działaj

ą

cym systemem.

Piel

ę

gnacja oprogramowania to proces zmieniania

systemu po przekazaniu go do u

ż

ytku. Chocia

ż

koszty

„piel

ę

gnacji” s

ą

zwykle wielokrotnie wy

ż

sze ni

ż

koszt

wst

ę

pnego tworzenia, proces piel

ę

gnacji jest uwa

ż

any za

mniejsze wyzwanie ni

ż

tworzenie oprogramowania.

Ewolucja oprogramowania

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

118

Zautomatyzowane wspomaganie

procesu

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

119

procesu

CASE

Komputerowo wspomagana in

ż

ynieria oprogramowania

(Computer-aided Software Engineering, CASE) jest
nazw

ą

oprogramowania u

ż

ywanego do wspomagania

czynno

ś

ci procesu tworzenia oprogramowania, takich jak

in

ż

ynieria wymaga

ń

, projektowanie, programowanie i

testowanie. Narz

ę

dzia CASE obejmuj

ą

zatem edytory

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

120

testowanie. Narz

ę

dzia CASE obejmuj

ą

zatem edytory

projektów, słowniki danych, kompilatory, programy do
usuwania bł

ę

dów, narz

ę

dzia do budowania systemu itd.

Technologia CASE wspomaga proces tworzenia
oprogramowania przez automatyzacj

ę

niektórych

czynno

ś

ci procesu i dostarczanie informacji o tworzonym

oprogramowaniu.

Czynno

ś

ci które mo

ż

emy

zautomatyzowa

ć

Opracowywanie graficznych modeli systemu jako cz

ęś

ci

specyfikacji wymaga

ń

i projektu oprogramowania.

Czytanie projektu za pomoc

ą

słownika danych, który

przechowuje informacje o encjach i zwi

ą

zkach w

projekcie.

Generowanie interfejsu u

ż

ytkownika na podstawie

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

121

Generowanie interfejsu u

ż

ytkownika na podstawie

graficznego opisu interfejsu opracowanego interaktywnie
przez u

ż

ytkownika.

Ś

ledzenie bł

ę

dów przez udost

ę

pnienie informacji o

wykonuj

ą

cym si

ę

programie.

Automatyczne tłumaczenie programów ze starych wersji
j

ę

zyków programowania (np. COBOL) na ich bardziej

aktualne wersje.

Ograniczenia CASE

In

ż

ynieria oprogramowania jest głównie czynno

ś

ci

ą

projektowania opart

ą

na kreatywnym my

ś

leniu. Istniej

ą

ce

systemy CASE automatyzuj

ą

rutynowe czynno

ś

ci, ale

próby zastosowania sztucznej inteligencji do
wspomagania projektowania nie były udane.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

122

wspomagania projektowania nie były udane.

W wi

ę

kszo

ś

ci firm in

ż

ynieria oprogramowania jest

czynno

ś

ci

ą

zespołow

ą

. In

ż

ynierowie sp

ę

dzaj

ą

wi

ę

c sporo

czasu na interakcji z innymi członkami zespołu.
Technologia CASE nie daje tu

ż

adnego wsparcia.

CASE

Perspektywa funkcjonalno

ś

ci, w której klasyfikuje si

ę

narz

ę

dzia CASE wzgl

ę

dem ich specyficznej funkcji.

Perspektywa procesu, w której klasyfikuje si

ę

narz

ę

dzia

CASE wzgl

ę

dem wspomaganych przez nie czynno

ś

ci

procesu.

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

123

procesu.

Perspektywa integracji, w której klasyfikuje si

ę

narz

ę

dzia CASE wzgl

ę

dem sposobu ich integracji w

spójne jednostki, które oferuj

ą

wspomaganie jednej lub

wi

ę

cej czynno

ś

ci procesu.

Klasyfikacja

Narz

ę

dzia do planowania – np. arkusze kalkulacyjne

Narz

ę

dzia do edycji – edytory tekstów, diagramów

Narz

ę

dzia do zarz

ą

dzania zmianami- Systemy kontroli zmian

Narz

ę

dzia do zarz

ą

dzania konfiguracjami – zarz

ą

dzanie wersjami

Narz

ę

dzia do prototypowania- j

ę

zyki wysokiego poziomu, generatory

interfejsów
Narz

ę

dzia do wspomagania metod – edytory projektów, słowniki danych,

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

124

Narz

ę

dzia do wspomagania metod – edytory projektów, słowniki danych,

generatory kodu

Narz

ę

dzia do przetwarzania j

ę

zyków- kompilatory, interpretatory

Narz

ę

dzia do analizy programów – generatory wzajemnych odwoła

ń

,

analizy statystyczne

Narz

ę

dzia do testowania – generatory danych testowych (porównuj

ą

ce

pliki)

Narz

ę

dzia do usuwania bł

ę

dów – systemy interakcyjnego usuwania

bł

ę

dów

Narz

ę

dzia do dokumentowania- programy składu, edytory rysunków

CASE

©Ian Sommerville /

W. Suszyński

Inżynieria oprogramowania 1

125