Inynieria Oprogramowania

WYKAD 2: Proces tworzenia oprogramowania

2013Z

Rozkad jazdy

2
0
1
3

1.

Etapy tworzenia oprogramowania

2.

Gwne czynnoci zwizane z rozwojem oprogramowania

1.

Identyfikacja i analiza wymaga

2.

Projekt systemu

3.

Implementacja i testowanie moduw

4.

Integracja i testowanie systemu

5.

Eksploatacja i utrzymanie

3.

Model kaskadowy procesu rozwoju oprogramowania

4.

Proces ewolucyjny

WYKAD 2

Etapy tworzenia
oprogramowania

2
0
1
3

WYKAD 2

Etap 1
Cel oprogramowania

2
0
1
3

WYKAD 2

Etap 2
Identyfikacja potrzeb klienta wynik analizy

2
0
1
3

WYKAD 2

Etap 3
Rezultat projektowania

2
0
1
3

WYKAD 2

Etap 4
Oprogramowanie

2
0
1
3

WYKAD 2

Etap 5
Wdroenie i testowanie

2
0
1
3

WYKAD 2

Etap 6
Koszt informatyzacji

2
0
1
3

WYKAD 2

Etap 7
Faktyczne potrzeby klienta

2
0
1
3

10

WYKAD 2

Gwne czynnoci zwizane z

rozwojem oprogramowania

2
0
1
3

11

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

W oglnym ujciu proces definiuje kto, co i w jaki sposb

wykonuje w celu osignicia okrelonego rezultatu.

Proces tworzenia bd rozwoju istniejcego

oprogramowania okrela si jako

software development process.

2
0
1
3

12

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

Proces tworzenia oprogramowania jest opisywany jako

zestaw dziaa potrzebnych do przeksztacenia wymaga
uytkownika w gotowe oprogramowane.

Na najwyszym poziomie abstrakcji, proces tworzenia

oprogramowania moe by przedstawiony jak na rys. 1.

2
0
1
3

13

WYKAD 2

Rys. 1. Uproszczony schemat procesu rozwoju oprogramowania

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

2
0
1
3

14

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

Wymagania klienta okrelaj cel tworzenia

oprogramowania.

S przygotowywane przez klienta (czasami z pomoc

inyniera oprogramowania) do okrelenia usug, ktre

system powinien zapewnia,
tj. wymaga funkcjonalnych.
2
0
1
3

15

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

Wymagania funkcjonalne powinny okrela co system

powinien robi, a nie w jaki sposb.

Oprcz wymaganych funkcjonalnoci, klient moe mie take

poza funkcjonalne ograniczenia, ktre chciaby wprowadzi do
systemu, takie jak czas potrzebny na odpowied czy
korzystanie z okrelonych standardw jzykowych.

2
0
1
3

16

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

Naley jednak pamita o nastpujcych

faktach, ktre sprawiaj, e identyfikacja i analiza

wymaga s bardzo trudne:

2
0
1
3

17

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

wymagania s czsto niekompletne

wymagania klienta s zwykle opisywane w kategoriach poj,

obiektw i terminologii, ktre mog nie by bezporednio zrozumiae

dla inynierw oprogramowania

wymagania klienta s zwykle niezorganizowane i nie cise,

obarczone s redundancj na rnym poziomie, zawieraj
niejasnoci i niespjnoci

2
0
1
3

18

Wymagania mog nie by moliwe do zrealizowania

WYKAD 2

Gwne czynnoci zwizane z rozwojem

oprogramowania

Dlatego te, kady proces rozwoju musi zaczyna si od

czynnoci identyfikacji i analizy wymaga klienta.

Te dziaania i zwizane z nimi rezultaty stanowi pierwszy

etap (lub podproces) w procesie zwanym

analiz wymaga (requirement analysis)

2
0
1
3

19

WYKAD 2

Identyfikacja i analiza wymaga

20

WYKAD 2

Identyfikacja i analiza wymaga

Identyfikacja i analiza wymaga jest kluczowa dla

przeprowadzenia odpowiedniego procesu tworzenia
oprogramowania.

Ich celem jest stworzenie dokumentu zwanego

specyfikacj wymaga.

2
0
1
3

Cay zakres identyfikacji i analizy wymaga stanowi tak

zwan inynieri wymaga.

21

WYKAD 2

Identyfikacja i analiza wymaga

Dokument specyfikacji wymaga wykorzystuje si jako:

1.

umow zawart pomidzy klientem a dostawc oprogramowania,

okrelajc co system powinien robi (i czego nie powinien
robi)

2.

podstaw wykorzystywan przez zesp programistw do

tworzenia systemu

3.
2
0
1
3

wystarczajco kompletny model, okrelajcy co jest potrzebne w

systemie

22

WYKAD 2

Identyfikacja i analiza wymaga

Proces analizy wymaga (rys. 2) powinien zawiera nastpujce, wysoce iteracyjne

czynnoci:

Zrozumienie dziedziny Analitycy powinni rozumie dziedzin klienta, pod ktem

docelowej aplikacji, aby moliwie jak najdokadniej zidentyfikowa wymagania

Identyfikacj wymaga Analityk powinien posiada zdolno do komunikacji z

klientem, tak, aby mc uchwyci wszystkie wymagania, a nastpnie mc jasno
komunikowa wszystkim zaangaowanym w projekt. Umiejtno abstrakcji pozwala na

identyfikacj istotnych elementw a pomijanie zbdnych

2
0
1
3

23

WYKAD 2

Identyfikacja i analiza wymaga

Klasyfikacja Czynno ta pozwala na zorganizowanie zidentyfikowanych

uprzednio nieustrukturalizowanych zbiorw wymaga w spjne grupy, a

nastpnie ustalanie priorytetw w zalenoci od ich znaczenia dla klienta i
uytkownikw docelowych

Walidacja czynno polegajca na sprawdzeniu, czy wymagania s zgodne i

kompletne; suy do rozwizywania konfliktw midzy wymaganiami

Studium wykonalnoci pozwala oceni, czy okrelone wymagania mog by

spenione przy uyciu danego oprogramowania i technologii, sprztu oraz
zdecydowa, czy proponowany system bdzie opacalny

2
0
1
3

24

WYKAD 2

Rys. 2. Perspektywa procesu analizy wymaga

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

identyfikacja
wymaga

zrozumienie
Deweloper

studium
wykonalnoci
Ekspert dziedzinowy

walidacja

Uytkownik
Dokument specyfikacji

2
0
1
3

25

WYKAD 2

klasyfikacja

Identyfikacja i analiza wymaga

Nie istniej adne sztywne reguy wskazujce na zakoczenie

procesu analizy wymaga i przejcie do kolejnego etapu tworzenia
(rozwoju) systemu

Przed przystpieniem do kolejnej fazy naley zatem zada sobie

nastpujce pytania:

Czy wymagania systemu zostay w peni zrozumiane przez klienta,

uytkownikw kocowych deweloperw (inynierw

2
0
1
3

oprogramowania)?
26

WYKAD 2

Identyfikacja i analiza wymaga

Czy zosta zbudowany kompletny model wymaga?

Jest to model systemu, okrelajcy co powinno by
wykonywane przez system, z perspektywy:

jakie funkcje (lub usugi) s dostpne

jakie s wejcia i wyjcia systemu

jakie dane s niezbdne

lecz nie powinien zawiera decyzji wykonawczych

2
0
1
3

27

WYKAD 2

Identyfikacja i analiza wymaga

Na tym etapie, model systemu wynikajcy ze specyfikacji wymaga

powinien by dostosowany i poprawiony jak tylko to bdzie konieczne

podczas kolejnych etapw rozwoju systemu

Istotnym dodatkowym dziaaniem zwizanym z analiz wymaga jest

testowanie wersji finalnej systemu:

plany testw powinny by wykonywane zgodnie ze specyfikacj wymaga

scenariusze testw powinny by zaprojektowane tak, aby obj wszystkie

kluczowe wymagane usugi

2
0
1
3

28

WYKAD 2

Identyfikacja i analiza wymaga

Podsumowujc, specyfikacj wymaga jest oficjalne owiadczenie o tym, co

jest wymagane w oprogramowaniu, ktre ma zosta stworzone.

To nie jest dokumentacja projektowa, poniewa zawiera to, co naley zrobi,

a nie w jaki sposb.

Powinna by ujta w formie, ktra bdzie traktowana jako punkt wyjcia do

tworzenia (rozwoju) oprogramowania.

2
0
1
3

Wykorzystuje si do tego okrelony jzyk specyfikacji (notacja).

Czsto stosowane s notacje graficzne.

29

WYKAD 2

Identyfikacja i analiza wymaga

Faza identyfikacji i analizy wymaga jest niezwykle

istotna, poniewa niewykryty bd na tym etapie,
najprawdopodobniej pozostanie niewykryty w fazach

pniejszych, a im pniej zostanie wykryty, tym

trudniejszy i bardziej kosztowny bdzie do
naprawienia.
2
0
1
3

30

WYKAD 2

Projekt systemu

31

WYKAD 2

Projekt systemu

Po tym, jak zostanie stworzona specyfikacja poprzez

analiz wymaga, maj miejsce dwa kolejne etapy
projektowania.

Pierwszy to projekt architektury (bd logiczny), w

ktrym wymagania zostaj podzielone na czci
(komponenty).

2
0
1
3

32

WYKAD 2

Projekt systemu

W rezultacie powstaje dokumentacja projektowa opisujca

co ktry z elementw powinien robi i w jaki sposb
interaguj ze sob w celu zapewnienia przez system
wszystkich niezbdnych usug.

Kady komponent jest z kolei projektowany oddzielnie, co

przekada si na szczegowy projekt (warstwa fizyczna).

2
0
1
3

33

WYKAD 2

Projekt systemu

Szczegowa dokumentacja projektowa opisuje sposb

funkcjonowania kadego komponentu, a przez co
funkcjonowanie caego systemu.

Czynnoci procesu projektowania oraz ich rezultaty

zostay przedstawione na rys. 3.

2
0
1
3

34

WYKAD 2

Rys. 3. Perspektywa procesu projektowania

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

Model specyfikacji wymaga

systemu

Projekt logiczny
Podzia
Co realizuj poszczeglne komponenty?
Zaleno komponentw

2
0
1
3

35

Konkretna, implementacyjnie zalena

szczegowa architektura systemu

Abstrakcyjna, implementacyjnie
niezalena oglna architektura
systemu

WYKAD 2

Projekt szczegowy
Doskonalenie
W jaki sposb komponenty to realizuj?
Projekt zalenoci

Projekt systemu

Dokument sporzdzony w fazie projektowania architektury

stanowi model skadajcy si ze specyfikacji poszczeglnych
elementw, ktre opisuj co kady element powinien robi
poprzez interfejsy komponentw.

Model systemu na tym poziomie jest wci abstrakcyjny i

niezaleny implementacyjnie, w dalszym cigu koncentrujc

2
0
1
3

si w wikszym stopniu na "co", ni na "w jaki sposb".

36

WYKAD 2

Projekt systemu

Podproces szczegowego projektu obejmuje kilka etapw

doskonalenia modelu architektury, prowadzc do stworzenia

szczegowego modelu projektu, ktry opisuje:

model funkcjonalnoci kadego komponentu, opisujcy w jaki sposb

zapewnia realizacj wymaganych funkcji

projekt interfejsu kadego komponentu, opisujcy w jaki sposb kady

element wiadczy usugi na rzecz pozostaych komponentw

2
0
1
3

Model systemu na tym etapie moe by postrzegany jako szkielet,

ktry konkretny, zaleny implementacyjnie, a take okrela "jak".

37

WYKAD 2

Implementacja i testowanie moduw

38

WYKAD 2

Implementacja i testowanie moduw

Na tym etapie kady z elementw z projektu jest

realizowany jako jednostka programowa (modu).

Kady modu powinien by zweryfikowany lub

przetestowany pod ktem specyfikacji wyznaczonych w

fazie projektowania.

2
0
1
3

39

Proces ten przedstawiony jest na rys. 4.

WYKAD 2

Rys. 4. Perspektywa procesu implementacji i testowania moduw

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

Specyfikacje projektowe

2
0
1
3

40

Implementacja
i
Testowanie moduw

WYKAD 2

Pakiety przetestowanych
jednostek programistycznych

Integracja i testowanie systemu

41

WYKAD 2

Integracja i testowanie systemu

Poszczeglne jednostki programowe (moduy) reprezentujce

komponenty systemu s czone i testowane jako cao w celu

sprawdzenia, czy wymagania programowe zostay spenione.

Kiedy oprogramowanie przejdzie pomylnie testy inynierw

zostaje ono przedstawione do testowania przez klienta (testy
akceptacyjne).

Etap ten koczy si, gdy produkt zostanie zaakceptowany przez

klienta.

2
0
1
3

42

WYKAD 2

Eksploatacja i utrzymanie

43

WYKAD 2

Eksploatacja i utrzymanie

Ten etap rozpoczyna si w czasie instalacji

oprogramowania do praktycznego wykorzystania, jak
tylko produkt zostanie dostarczony do klienta. Trwa do

pocztku fazy wycofania oprogramowania z uycia.

2
0
1
3

44

WYKAD 2

Eksploatacja i utrzymanie

Utrzymanie obejmuje wszystkie zmiany produktu, na ktre zgodzi

si klient, zawarte w dokumentacji specyfikacji.

Utrzymanie obejmuje rwnie konserwacj korekcyjn (lub

dziaania naprawcze), jak i rozbudow (np. update).

Na tym etapie w szczeglnoci koncentrujemy si na naprawie

bdw, ktre nie zostay wykryta w poprzednich fazach rozwoju
oprogramowania pozostawiajc dokumentacj specyfikacyjn bez
zmian.

2
0
1
3

45

WYKAD 2

Eksploatacja i utrzymanie

Istniej dwa dodatkowe rodzaje konserwacji:

Konserwacja kompletna zawiera zmiany, ktre klient uwaa za

istotne dla poprawy efektywnoci oprogramowania, takie jak
rozszerzona funkcjonalno, bd zwikszony czas reakcji

Konserwacja adaptacyjna polega na dokonywaniu zmian w

odpowiedzi na zmiany w otoczeniu, w ktrym oprogramowanie
operuje, np. zmiany regulacji prawnych

2
0
1
3

46

WYKAD 2

Eksploatacja i utrzymanie

Badania wskazuj, e rednio powica si okoo 17,5%

czasu na dziaania naprawcze, 60% na kompletn
konserwacj, a 18% na utrzymanie adaptacyjne.

2
0
1
3

47

WYKAD 2

Model kaskadowy procesu

rozwoju oprogramowania

2
0
1
3

48

WYKAD 2

Model kaskadowy procesu rozwoju

oprogramowania

Nawizujc do czynnoci zwizanych z

procesem tworzenia oprogramowania, cay

proces rozwoju czsto opisywany jest przy
pomocy modelu kaskadowego (rys. 5)

2
0
1
3

49

WYKAD 2

Rys. 5. Model kaskadowy tworzenia oprogramowania

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

Analiza wymaga

Projekt

Implementacja i testowanie
moduw

Integracja i testowanie
systemu

2
0
1
3

Eksploatacja i utrzymanie

50

WYKAD 2

Model kaskadowy procesu rozwoju

oprogramowania

Proces rozwoju oprogramowania jest zwany take cyklem ycia

oprogramowania.

Musimy pamita, e:

W praktyce etapy modelu kaskadowego nakadaj si na siebie i

dostarczaj informacji o sobie: w trakcie projektowania, problemy
specyfikacji wymogw zostaj okrelone, w trakcie kodowania pojawiaj

si problemy dotyczce projektu, itd.

Dlatego proces rozwoju nie stanowi prostego modelu liniowego, lecz
obejmuje sekwencj iteracji dziaa w ramach rozwoju oprogramowania.
2
0
1
3

51

WYKAD 2

Model kaskadowy procesu rozwoju

oprogramowania

Podczas kocowej fazy cyklu ycia, czynnoci konserwacji kompletnej

(perfektywnej) mog powodowa powtrzenie niektrych lub wszystkich

poprzednich etapw procesu.

Proces rozwoju, ktry zawiera czste powtrzenia moe spowodowa, e trudno

bdzie zidentyfikowa punkty kontrolne do zarzdzania, planowania i
sprawozdawczoci.

Dlatego te, po niewielkiej liczbie iteracji, naley zamrozi cz procesu, jak np.
specyfikacj, aby mc przej do kolejnych etapw.

2
0
1
3

Czasami trudno jest podzieli czynnoci procesu rozwoju w projekcie na odrbne

fazy.

52

WYKAD 2

Proces ewolucyjny

2
0
1
3

53

WYKAD 2

Proces ewolucyjny

Problemem modelu kaskadowego jest to, e istnieje

trudno wyodrbnienia granic poszczeglnych etapw
analizy wymaga

Czasami te jest trudne (lub nawet niemoliwe) do

osignicia szczegowej specyfikacji wymaga

2
0
1
3

54

WYKAD 2

Proces ewolucyjny

Proces ewolucyjny oparty jest na koncepcie stworzenia

wstpnej implementacji, przedstawiajc do oceny
uytkownika i doskonalenia poprzez wiele wersji a do

opracowania optymalnej wersji systemu

2
0
1
3

55

WYKAD 2

Proces ewolucyjny

Proces rozwoju rozpoczyna si krtkim opisem

systemu. Zamiast oddzielnych specyfikacji, rozwj
(projekt, wdroenie) i walidacja (testowanie i / lub

weryfikacja i / lub prototypowanie), dziaania te

prowadzone s jednoczenie z naciskiem na biece
(ad hoc) sprzenie zwrotne
2
0
1
3

56

WYKAD 2

Proces ewolucyjny

Techniki wykorzystywane w procesie ewolucyjnym to:

Programowanie rozpoznawcze, ktrego celem wsppraca z

klientem w celu identyfikacji wymaga i dostarczenia finalnej

wersji systemu.

Proces rozpoczyna si od tych czci systemu, ktre s

zrozumiae.

2
0
1
3

System ewoluuje przez dodawanie nowych funkcji w formie

proponowanej przez klienta.

57

WYKAD 2

Proces ewolucyjny

Prototypowanie, ktrego celem jest zrozumienie potrzeb

klienta, a tym samym na lepsze okrelenie wymaga dla
systemu.

Prototyp koncentruje si na eksperymentowaniu w ramach

tych wymaga klienta, ktre s sabo zrozumiae.

2
0
1
3

58

WYKAD 2

Rys. 6. Szacunkowe koszty wzgldne faz procesu tworzenia

oprogramowania
Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

80%
70%

Koszt

67%

60%

50%
40%
30%

20%
10%
2
0
1
3

8%

7%

Wymagania

Projekt

12%
6%

0%
59

Implementacja
WYKAD 2

Integracja

Utrzymanie

Rys. 7. Bdy w oprogramowaniu (a) rdo (b) korekta

Zhiming Liu, Object-Oriented Software Development with UML. UNU/IIST Report No. 259

60%

90%

56%

rda bdw
50%

60%
50%

30%

27%

40%

20%

30%

10%

7%

10%

20%

13%

10%

0%

1%

0%
Niekompletne
wymagania

60

Dziaania korekcyjne

80%
70%

40%

2
0
1
3

82%

Projekt

Kodowanie

Inne

Niekompletne
wymagania

WYKAD 2

Projekt

Kodowanie

4%
Inne

Proces ewolucyjny

Model iteracyjny oparty na zmianach na bieco charakteryzuje si

nastpujcymi problemami:

Proces nie jest widoczny trudno stworzy dokumentacj odzwierciedlajc kad z

wersji

System sabo ustrukturalizowany Cige zmiany powoduj uszkodzenia struktury

oprogramowania

Nie zawsze moliwy w przypadku wikszych systemw przeprowadzenie zmian na

pniejszych wersjach jest trudne, a czasami niemoliwe. Nowe wymagania mog si
wiza z rozpoczynaniem caego procesu od nowa, co pociga za sob wysokie koszty

2
0
1
3

61

Czste prototypowanie jest bardzo kosztowne

WYKAD 2

Proces ewolucyjny

Te problemy bezporednio prowadz do tego, e system jest trudny do

zrozumienia i utrzymania.

Dlatego te sugeruje si, by model ten by stosowany w nastpujcych

okolicznociach:

Tworzenie stosunkowo niewielkich systemw.

Tworzenie systemw z krtkim cyklem ycia. Taki system jest zaprojektowany do

wsparcia niektrych dziaa ograniczonych w czasie, a wic problem utrzymania nie
jest tak istotny.

2
0
1
3

Rozwj systemw lub elementw duych systemw, w ktrych nie da si stworzy z

gry szczegowej specyfikacji (np. systemy sztucznej inteligencji i interfejsy).

62

WYKAD 2

Na dzisiaj koniec

63

WYKAD 2