Programų sistemų inžinerija

5 paskaita Programų sistemų inžinerijos procesų

modeliai (paradigmos)

Skaidrės paruoštos remianti prof. A.Čaplinsko ir I.Sommerville medžiaga

2

Paradigmos PS inžinerijos paradigmos

• PS inžinerijos paradigmos – tai skirtingi požiūriai į tai, kaip turi būti kuriamos programų sistemos.

– Iš principo, PS galima sukurti pasinaudojant bet kuria paradigma.

– Kurią paradigmą rinktis, priklauso ir nuo vykdytojų įgūdžių, ir nuo kuriamos PS pobūdžio, ir nuo sandorio su užsakovu pobūdžio ir nuo kitų konkretaus projekto ypatumų.

– Bet kuri iš PSI paradigmų užduoda tiktai tam tikrą principinę PS kūrimo schemą

3

Paradigmos PS inžinerijos paradigmos

• Nei viena PSI paradigma neduoda projektuotojui

jokių atsakymų į jokius konkrečius klausimus. Ji yra

tik kelrodė žvaigždė, primenanti projektuotojui,

kokius projektavimo sprendimus jis turi priimti.

4

Paradigmos

Populiariausios PS inžinerijos paradigmos – Krioklio paradigma (waterfall)

– Paradigma “iš viršaus žemyn” (top-down approach)

– Paradigma “iš apačios aukštyn” (bottom-up approach)

– Riešuto paradigma (bootstrap approach)

– Iteracinė paradigma (prototyping)

– Evoliucinio kūrimo paradigma (incremental development)

– Spiralės paradigma

– Komponentinė paradigma (reuse-based development)

– Sintezės paradigma (formal development)

5

Principai ir paradigmos Paradigma “iš viršaus žemyn” (top-down) • Taikant šią paradigmą

– sistemos kūrimas pradedamas jos vartotojo interfeisų projektavimu

• be to, nustatomi iš išorės stebimos sistemos elgsenos vertinimo kriterijai;

• kitaip tariant, PS traktuojama kaip juodoji dėžė;

– po to žingsnis po žingsnio judama žemyn, kiekviename žingsnyje visų pirma nustatant, ką tame žingsnyje nagrinėjami komponentai darys ir kokius interfeisus jie turės, ir tik po to pradedant galvoti, kaip reikia realizuoti jų elgseną (funkcijas)

• t.y. komponentai traktuojami kaip juodosios dėžės

Krioklio (kaskadinė) paradigma

6

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Krioklio paradigmos fazės

• Krioklio modelyje naudojamos tokios atskiros fazės, kurios vykdomos nuosekliai t.y. prie tolimesnės fazės prieinama tik baigus prieš tai buvusią fazę.

• Krioklio paradigmos fazės:

– Reikalavimų analizė ir apibrėžimas

– Programų sistemos projektavimas

– Programų kūrimas ir komponentų testavimas

– Komponentų integravimas ir sistemos testavimas

– Programų diegimas ir palaikymas

• Pagrindinis krioklio paradigmos trūkumas – sunku atlikti pakeitimus, kai procesas jau prasidėjęs.

7

Krioklio paradigmos problemos

• Nelankstus projekto suskaldymas į fazes apsunkina reagavimą į užsakovo pareikštus pakeitimus.

– Krioklio paradigma tinkama tik tuomet, kai reikalavimai yra gerai išsiaiškinti ir pakeitimai bus labai nežymiai projekto eigoje.

– Tik labai maža dalis programų sistemų turės nekintamus reikalavimus projekto eigoje.

• Krioklio paradigma dažniausiai naudojama didelių PS kūrimo projektuose, kuriuose dalyvauja kelios IT įmonės ir pakeitimų įvedimas yra labai skausmingas.

– Tokiais atvejais griežtai suplanuotas procesas padeda koordinuoti visą darbą.

8

5 tema 9

“Iš viršaus žemyn” Paradigma “iš viršaus žemyn” (top-down)

• Taikant šią paradigmą

– projektavimas baigiamas “nulipus” iki kompiuterinės platformos lygmens ir suformulavus kompiuterinės technologijos reikalavimus, garantuojančius suprojektuotų interfeisų veikimą ir norimą sistemos elgseną.

• Taigi, vadovaujantis šia paradigma, galima apsisaugoti nuo vartotojų turimos PS vizijos iškraipymų, dažnai atsirandančių kuriant sistemas kitais būdais.

– Tačiau, ir vadovaujantis šia paradigma, vartotojų vizija gali būti iškreipta, jei, kaip tai neretai atsitinka, analitikai iki galo neperpras vartotojų poreikių.

10

“Iš viršaus žemyn” Paradigma “iš viršaus žemyn”

• “Iš viršaus žemyn” paradigmoje intensyviai

naudojami abstrakcijos ir dekompozicijos principai

– kiekvienas abstrakcijos lygmuo yra dekomponuojamas į

komponentus (juodąsias dėžes), kurie “tikslinami”

žemesniuose abstrakcijos lygmenyse.

• Paradigma pritaikyta projektuotojams, gebantiems

projektuoti komponentus, tenkinančius iš anksto

užduotas specifikacijas.

11

“Iš viršaus žemyn” Paradigma “iš viršaus žemyn”

• Projektavimo sprendimai priimami vadovaujantis funkciniais kriterijais.

– problema dekomponuojama į komponentus (modulius, duomenų struktūras ar kt.),

– komponentai realizuojami panaudojant žemesnio lygmens (patikslintus) komponentus, kurie vis labiau ir labiau atspindi tikslinės kompiuterinės platformos ypatumus.

12

“Iš viršaus žemyn”

Pradinė problema

Skaidymas į smulkesnes problemas

Elementarios

problemos

(aprašomos

viena funkcija)

Projektavimas “iš viršaus žemyn”

13

“Iš apačios aukštyn” Taikant iš apačios aukštyn paradigmą

– sistemos kūrimas pradedamas nuo kompiuterinės platformos

• kompiuterinė platforma užduoda rinkinį griežtai apibrėžtų

sąvokų, per kurias galima išreikšti sudėtingesnes įvairių

dalykinių ir probleminių sričių sąvokas;

– po to konstruojamos vis abstraktesnės ir abstraktesnės

sąvokos, kuriomis galų gale pavyksta aprašyti PS

sprendžiamą problemą

• taigi, yra parenkama kompiuterinė technologija, o po to

sprendžiama kaip šios technologijos priemonėmis kurti

reikiamą PS.

14

“Iš apačios aukštyn” Paradigma “iš apačios aukštyn” • Tai viena iš populiariausių PS kūrimo paradigmų

– šios paradigmos populiarumas yra natūralus, nes naudojama technologija visuomet lemia tai, kokias PS yra įmanoma sukurti;

• rinkoje pasirodantys naujo pobūdžio programiniai produktai dažniausiai esti naujų kompiuterinių technologijų pasirodymo pasekmė.

• Ši paradigma neblogai tinka nedidelėms PS kurti

– projektuojant sudėtingesnes PS, dėl iš anksto daromų technologinių prielaidų dažniausiai yra iškraipoma vartotojų turima PS vizija, nes suprojektuojami tokie sistemos interfeisai, kuriuos patogu realizuoti turimomis technologinėmis priemonėmis, o ne tokie, kurie būtų patogūs vartotojui.

15

“Iš apačios aukštyn”

Paradigma “iš apačios aukštyn”

• Projektavimo “iš apačios aukštyn” paradigma grindžiama intensyviu abstrakcijos principo ir konkatenacijos operacijos naudojimu

– kiekviename abstrakcijos lygmenyje, panaudojant konkatenacijos operaciją, žemesnio lygmens komponentai kombinuojami į sudėtingesnius komponentus.

Konkatenacijos operacija

16

“Iš apačios aukštyn” Paradigma “iš apačios aukštyn”

• Projektavimas pradedamas nusakant bendrais bruožais sistemos programinę realizaciją:

– t.y. nusprendžiant, kokios procedūros ir duomenų struktūros galėtų būti naudingos, konstruojant reikiamą PS.

• Toliau žingsnis po žingsnio vyksta konkatenacijos procesas.

– vietoje to, kad leistis nuo uždavinio prie programavimo kalbos, kaip tai daroma taikant “iš viršaus žemyn” paradigmą, nuo programavimo kalbos yra kylama prie uždavinio, vienas po kito konstruojant abstrakcijos lygmenis (juos galima traktuoti kaip programavimo kalbas) vis labiau ir labiau pritaikytus sprendžiamam uždaviniui aprašyti.

17

“Iš apačios aukštyn” Paradigma “iš apačios aukštyn”

• Procesas užbaigiamas, suprojektavus probleminio

pobūdžio komponentus panaudojus kuriuos galima

įgyvendinti užduočių formulavimo kalbą (vartotojo

interfeisus).

• Paradigma pritaikyta projektuotojams, kurie linkę

visų pirma įvertinti komponento, kurį jie rengiasi

projektuoti, technologinį tinkamumą (našumą ir pan.)

kuriamai programų sistemai.

18

“Iš apačios aukštyn” Paradigma “iš apačios aukštyn”

• Projektavimo sprendimai priimami vadovaujantis

technologiniais kriterijais

– komponentai kombinuojami, norint gauti aukštesnio

lygmens komponentus, kurie, manoma, yra “tinkamesni“

vartotojo interfeisams įgyvendinti, nes yra labiau

probleminio (ne technologinio) pobūdžio.

19

“Iš apačios aukštyn”

Paradigma “iš apačios aukštyn”

• Rekomenduojama vadovautis “iš apačios aukštyn” paradigma, kuomet norima sukurti PS sprendžiančią bendresnę problemą negu problema, kurią sprendžia kokia nors jau esama PS.

• Kaip jau minėta, svarbiausias paradigmos trūkumas yra tas, kad apatiniuose abstrakcijos lygmenyse priimti technologiniai sprendimai paveikia visą PS, įskaitant vartotojo interfeisus.

– vadovaujantis “iš viršaus žemyn” paradigma, pradedama ne nuo technologinių sprendimų, jie atidedami vėlesniam laikui.

20

“Iš apačios aukštyn”

Projektavimas “iš apačios aukštyn”

Norima

programa

Tinkamos

funkcijos

Tinkamos

kombinacijos

21

Paradigmų sugretinimas

Probleminė sritis

Kompiuterinė platforma

“iš viršaus

žemyn”

“iš apačios

aukštyn”

Vartotojo interfeisas

Paradigmų sugretinimas

22

Paradigmų sugretinimas

Lipant “iš viršaus žemyn” galima nenulipti į turimą kompiuterinę

platformą. Lipant “iš apačios aukštyn” galima neužlipti į sprendžiamą

problemą. Todėl praktikoje dažniausiai abi paradigmos yra derinamos

viena su kita.

"Iš viršaus žemyn"

"Iš apačios aukštyn"

Trūkis

Kompiuterinė platforma

Sprendžiama problema

23

Riešuto paradigma Riešuto paradigma • Programų sistema kuriama kaip specializuota virtualioji

mašina, turinti visas duomenų struktūras ir komandas, pritaikytas reikiamai problemai spręsti, o taip pat tą problemą sprendžiančią programą.

– Virtualiajai mašinai vykdant šią programą, yra įvykdoma reikiama užduotis.

• Po to, žingsnis po žingsnio konstruojamos naujos, žemesnio lygmens virtualiosios mašinos, skirtos aukštesnio lygmens mašinoms įgyvendinti

– Kiekviena tokia mašina patikslina (realizuoja) aukštesnio lygmens virtualiosios mašinos komandas ir duomenų struktūras.

24

Riešuto paradigma Riešuto paradigma

• Procesas baigiamas tada, kada visos aukštesnio lygmens mašinos komandos ir duomenų struktūros yra realizuotos kokia nors programavimo kalba.

• Iš esmės, tai specialus paradigmos “iš viršaus žemyn” atvejis

– Kiekvienas abstrakcijos lygmuo čia projektuojamas kaip virtualioji mašina.

– Pagrindinė idėja yra palaipsniui pertvarkyti probleminio pobūdžio virtualiąją mašiną į kompiuterinės platformos lygmens mašiną.

25

Riešuto paradigma Riešuto paradigma • Riešuto paradigmą galima traktuoti ir kaip specialų

paradigmos “iš apačios aukštyn atvejį”:

– šiuo atveju PS pradedama kurti nuo vadinamojo “branduolio”,

t.y. virtualiosios mašinos, realizuojančios bazines sistemos

funkcijas;

– šios mašinos kalba programuojamos papildomos funkcijos, t.y.

kuriama nauja virtualioji mašina, kuri tarsi “kevalas” padengia

“branduolį”;

– procesas tęsiamas tol, kol sukuriama sistema, tenkinanti turimą

reikalavimų specifikaciją.

26

Riešuto paradigma

Realus

kompiuteris

Makroinstrukcijų

interpretatorius

Operacinė sistema

C

ko

mp

iliatoriu

s

Ada

kompiliatorius

For

tran

kom

piliat

oriu

s

Lisp

kompiliatorius Pascal

kompiliatoriusB

asic

interp

retatoriu

s

Ase

mbl

eris

...................

C mašina

Fortran mašina

Lisp mašina

Ada mašina

Pascal mašina

Basic mašina

Asemblerio mašina

27

Iteracinė paradigma Iteracinė paradigma

• Vadovaujantis šia paradigma

– kuriamas ir testuojamas būsimosios PS prototipas

(funkciniu ar kitais požiūriais neišbaigta PS);

– prototipas perdirbamas į labiau išbaigtą variantą (naują

prototipą);

– procesas tęsiamas kol galų gale sukuriama išbaigta PS,

tenkinanti reikalavimų specifikaciją.

28

Iteracinė paradigma

Sommerville, 2000

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Prototipo

tikslų

nustatymas

Prototipo

funkcionalumo

nustatymas

Prototipo

kūrimas

Prototipo

vertinimas

Veikiantis

prototipas Vertinimo

rezultatai

Funkciniai

reikalavimai Darbų planas

29

Iteracinė paradigma

Sommerville, 2000

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Parengti PS

specifikaciją

Pateikti

užsakovui

Sukurti (perdirbti)

prototipą

Išbandyti

prototipą

Ar

tinkamas?

30

Iteracinė paradigma

Sommerville, 2000

Vadovaujantis šia paradigma, nuosekliai vienas

po kito vyksta sistemos reinžinerijos projektai.

Understanding andtransformation

Existingsoftware system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Software re-engineering

Forward engineering

Projektavimas ir

realizacija

Analizė ir

perdarymas

Nauja

sistema

Sistemos

specifikacija

Esama programų

sistema

Perdaryta

sistema

Tiesioginė inžinerija

PS reinžinerija

Boehm spiralės paradigma

• PS procesas atvaizduojamas kaip spiralė, o ne kaip

ciklinė veiksmų seka.

• Kiekvienas spiralės ciklas vaizduoja vieną PS

procesą.

• Fazės nefiksuojamos (pvz. reikalavimų specifikacija

arba projektavimas). Spiralės ciklai pasirenkami

pagal poreikį.

• Ypatingas dėmesys kreipiamas rizikų identifikavimui

ir valdymui.

31

Boehm spiralės paradigma

32

Spiralės sektoriai

• Siekinių nustatymas

– Nustatomi fazes specifiniai siekiniai (tikslai)

• Rizikos vertinimas ir mažinimas

– Įvertinama rizika ir apibrėžiamos veiklos rizikos mažinimui.

• Projektavimas, kodavimas, atestavimas

– Parenkama PS paradigma, labiausiai tinkanti projektui.

• Planavimas

– Projekto tarpinis vertinimas ir sekančios spiralės fazės planavimas.

33

Spiralės paradigmos naudojimas

• Spiralės paradigma padeda suprasti iteracinį PS

projekto vystymo modelį vertinti rizikas kiekvienoje

fazėje.

• Spiralės paradigma praktikoje naudojama retai.

34

5 tema 35

Evoliucinė paradigma

• Sistema yra kuriama kaip užsakovui vienas po kito pateikiamų papildinių (increments) seka:

– suprojektavus visos sistemos architektūrą, kuriami ir pateikiami užsakovui tos sistemos “branduolys” (svarbiausios funkcijos) ir jo papildiniai;

– kiekvienam papildiniui rengiama jo reikalavimų specifikacija ir jo projektinė dokumentacija;

– kol kuriamas naujas papildinys, vartotojai dirba su einamąja PS versija ir išryškina jos trūkumus.

36

Evoliucinė paradigma

Sommerville, 2000

Validateincrement

Build system

incrementSpecify system

incrementDesign system

architecture

Define system

deliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO

Nustatyti produkto reikalavimus

Suprojektuoti architektūrą

Specifikuoti papildinį

Sukurti papildinį

Išbandyti papildinį

Integruoti papildinį

Išbandyti sistemą

Pateikti galutinį produktą

Ar sistema pabaigta?

37

Evoliucinė paradigma

Sommerville, 2000

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outline

description

Concurrent

activities

Lygiagrečios

veiklos

Pradinė

versija

Galutinė

versija

Tarpinės

versijos

Pradinis

aprašas

Specifikavimas

Kūrimas

Bandymai

38

Evoliucinė paradigma

Ekstremalus programavimas (extreme programming)

• Specialus (šiuo metu labai populiarus) evoliucinės paradigmos atvejis, numatantis, kad kuriami ir užsakovui pateikiami labai maži papildiniai:

– grindžiamas nuolatiniu kodo tobulinimu, tiesioginiu vartotojo dalyvavimu PS kūrimo procese ir programavimu poromis;

– priskiriamas prie “judriųjų (agile) metodų”

termino “ekstremalus” dėl neigiamų asociacijų pradedama atsisakyti.

39

Evoliucinė paradigma

Ekstremalus programavimas

• Programavimas poromis:

– prie ekrano sėdi dviese ir kartu rašo programą;

– šitaip vienas kitą tikrina ir išvengia daugelio klaidų;

– be to, kiekvieną programą žino mažiausiai du

žmonės ir, jei vienam kas nors atsitiko, kitas gali tą

programą keisti ir taisyti.

40

Evoliucinė paradigma

Evoliucinio kūrimo paradigma

• Evoliucinė paradigma yra panaši į iteracine, tačiau yra sukuriama geriau struktūrizuota PS ir jos kūrimo procesą yra lengviau valdyti.

– PS funkcionalumas pateikiamas užsakovui anksčiau (nors ir dalimis);

– pradiniai papildiniai vaidina prototipų vaidmenį, nes padeda patikslinti vėlesnių papildinių reikalavimus;

– sumažėja projekto žlugimo rizika;

– galima geriau išbandyti (daugiau testavimo) svarbiausias sistemos funkcijas.

41

Komponentinė paradigma (Reused oriented software engineering)

Sistema renkama iš turimų komponentų:

– grindžiama daugkartiniu rinkoje parduodamų

komponentų (COTS – components of the shelf)

panaudojimu;

– didelę svarbą įgyja komponentų integravimo

metodai;

– labai svarbu, kiek reikia pastangų komponentui

perprasti.

5 tema 42

Komponentinė paradigma • Programų sistemos kūrimas pradedamas komponentų

analize ir jų reikalavimų keitimu.

• Dažniausiai iš komponentų surenkama tiktai tam tikra

kuriamos PS dalis, todėl komponentinė paradigma

turi būti kombinuojama su kitomis paradigmomis.

43

Komponentinė paradigma

Sommerville, 2000

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Reikalavimų specifikavimas

Komponentų analizė

Reikalavimų keitimas

Komponentinis projektavimas

Sistemos bandymai

Kūrimas ir integravimas

Reused oriented software engineering

44

Karkaso paradigma Karkaso paradigma

• Tai specialus programų sistemų šeimos paradigmos atvejas.

– dirbant pagal šią paradigmą, ruošinys yra kuriamas kaip objektinis ar kitoks PS sistemos architektūrinis karkasas (apibendrinta parametrizuota PS);

– konkreti PS sistema yra kuriama konkretizuojant karkasą (suteikiant parametrams konkrečias reikšmes) ir užpildant jį konkrečiu funkcionalumu;

– šitaip, pavyzdžiui, kuriamos vadinamosios verslo procesų valdymo sistemos (ERP paketai).

45

Karkaso paradigma Karkaso paradigma

• Architektūrinis karkasas yra tam tikri PS “griaučiai”

– realizuojamos duomenų struktūros, modulių interfeisai, jų sąveika ir kiti konstrukciniai PS ypatumai;

– tačiau pats karkasas nėra užpildytas jokiu konkrečiu

funkcionalumu t.y. jame pačių modulių realizacijos nėra.

5 tema 46

Karkaso paradigma Karkaso paradigma • Objektinis karkasas kuriamas kaip tarpusavyje susietų

abstrakčiųjų klasių rinkinys

– abstrakčiosios klasės naudojamos paveldėjimo hierarchijoms konstruoti;

– jos neturi realizacijų, jose apibrėžtos tik virtualios

operacijos t.y. karkase klasių realizacijos nėra.

47

Karkaso paradigma Objektiniai karkasai iš esmės skiriasi nuo klasių bibliotekų

– bibliotekos tiražuoja programų kodą, karkasai realizuoja ir tiražuoja PS šeimai būdingas architektūrines bendrybes (tipinius projektavimo sprendimus);

– naudojant klasių biblioteką valdymo srautas teka į vieną pusę: iš klasių biblioteką naudojančios programos į bibliotekos klases;

– naudojant objektinį karkasą, valdymo srautas yra abipusis, nes, viena vertus, programos klasės paveldi abstrakčiųjų karkaso klasių ypatumus, o, kita vertus, virtualiosios operacijos, panaudojant dinaminio susiejimo mechanizmą (dynamic binding), susiejamos su jas realizuojančiu kodu programos vykdymo metu.

5 tema 48

Karkaso paradigma

Dalykinės

taksonomijos Dalykinės

programų

sistemos

Dalykinių sričių

modeliai

Architektūros stiliai

Tipiniai projektiniai sprendimai

Karkasai

Karkasų užpildai

Sistemos kūrimo maršrutas

Naujo karkaso

kūrimas

Užpildų

kūrimas

49

Karkaso paradigma Karkaso paradigma

• Norint karkaso pagrindu sukurti konkrečią PS šeimos sistemą reikia sukurti karkaso klasėmis numatytą funkcionalumą realizuojantį kodą (karkaso užpildą)

– paprastai kartu su karkasu yra tiražuojamas ir standartinis užpildas (arba bent jau jo dalis);

– realizuojant konkrečią PS, standartinis užpildas gali būti visas arba iš dalies pakeistas nestandartine, tai konkrečiai sistemai būdinga realizacija.

50

Sintezės paradigma Sintezės paradigma

• Dirbant pagal šią paradigmą, formali (matematinė)

sistemos specifikacija pagal formalias taisykles

(automatiškai) transformuojama į veikiančią PS.

– transformavimas atliekamas per kelis tarpinius žingsnius;

– transformacijos neįneša klaidų, todėl kodas visuomet

atitinka sistemos specifikaciją;

– todėl atpuola būtinybė testuoti šitaip gautą kodą.

51

Sintezės paradigma

R2Formal

specificationR3

Executableprogram

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1

Formalios transformacijos

Transformacijų korektiškumo įrodymas

Formali

specifikacija

Programos

kodas

52

Sintezės paradigma Sintezės paradigma

• Problemos

– reikalingi specialūs įgūdžiai ir aukšta kvalifikacija;

– sudėtinga formaliai specifikuoti kai kuriuos sistemos aspektus, pavyzdžiui, vartotojo sąsają;

– darant sistemos pakeitimus, prireikia sukurti naujas transformacijas ir įrodyti jų teisingumą;

– kaip taisyklė, nepavyksta keisti šitaip kuriamų sistemų mastą (does not scale).

• Taikymų sritis

– Kritinės programų sistemos.

Veiklos kaštų pasiskirstymas Krioklio modelis

It Evoliucinis kūrimas

Komponentinis kūrimas

Kūrimo ir vystymo kaštai ilgai naudojamoms sistemoms

S Sistemos vystymas

1 0 2 00 3 0 400 0

S Sistemos kūrimas

Specifikavimas Projektavimas Kūrimas Integravimas ir testavimas

2 5 5 0 7 5 1 00 0

Specifikavimas Kūrimas Integravimas ir testavimas

2 5 5 0 7 5 1 00 0

Specifikavimas Iteratyvus kūrimas S Sistemos testavimas

2 5 5 0 7 5 1 00 0

Pakeitimų valdymas

• Pakeitimai programų kūrimo metu - pati

didžiausia problema dideliuose projektuose.

– Užsakovo poreikių pakeitimai veda prie naujų arba

modifikuotų reikalavimų.

– Platformų keitimas reikalauja naujų žinių ir

gebėjimų.

• Pakeitimai verčia atlikti papildomus darbus

realizuojant naujus funkcionalumus, kas didina

projekto kainą.

54

Pakeitimų kainos mažinimas

• Reikia naudoti tokias programų inžinerijos paradigmas, kuriose naudojamos veiklos sukuria mažesnes

pakeitimų kainas. – Pavyzdžiui evoliucinė, iteracinė paradigmos, judrūs

programų kūrimo metodai.

– Naudojant mažesnes iteracijas dažniau sukuriami prototipai, kuriuos vertina vartotojai, pareikšdami galimus pakeitimus, kurie išaugia mažesnes darbų apimtis pakeitimams įgyvenidinti.

– Dažnesnius evoliuciniai papildiniai taip pat mažina pakeitimų darbų kiekį.

55

PS inžinerijos veiklos

• PS inžinerijos procesas – tai suderintų veiksmų seka:

– specifikuojant,

– projektuojant,

– realizuojant

– testuojant

programų sistemas.

• Priklausomai nuo pasirinktos PS kūrimo paradigmos, šios

veiklos gali būti vykdomos nuosekliai (krioklio

paradigma) arba būti persidengiančios (iteracininės

paradigmos).

56

Programinės įrangos specifikavimas

• Specifikavimas – tai procesas nustatantis, kokios paslaugos reikalingos užsakovui ir apibrėžiantis apribojimus sistemos naudojimui bei kūrimui.

• Reikalavimų inžinerija

– Galimybių nagrinėjimas • Ar yra techninės ir finansinės galimybės sukurti pageidaujamą PS.

– Reikalavimų rinkimas ir analizė

• Ko užsakovams reikia, kokie jų lūkesčiai ir ką jie tikisi gauti iš PS.

– Reikalavimų specifikavimas

• Nustatomi detalūs PS reikalavimai.

– Reikalavimų atestavimas

• Tikriname ar nustatyti ir aprašyti reikalavimai yra teisingi.

Reikalavimų inžinerijos procesas

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirements

document

Reikalavimų

nagrinėjimas ir

ataskaita

Reikalavimų rinkimas ir

analizė, sistemos modeliai Reikalvimų specifikavimas,

reikalavimai vartotojui ir sistemai

Reikalavimų atestavimas ir

reikalavimų dokumentas

Projektavimas ir realizacija

• Procesas, keičiantis sistemos specifikaciją į veikiančią sistemą

• Programų sistemų projektavimas – programinės įrangos, realizuojančios specifikaciją,

struktūros projektavimas

• Realizavimas (programavimas) – paverčia struktūros projektą į veikiančią programą

• Projektavimas ir realizacija yra glaudžiai susijusios ir gali persidengti.

Projektavimo proceso veiklos

• Architektūrinis projektavimas – Nustatoma struktūros schema, komponentai, ryšiai

• Sąsajos projektavimas – Nustatomos sąsajos tarp atskirų komponentų

• Komponentų projektavimas – Komponentų detalus projektavimas, nustatymas kaip jie

veikia.

• Duomenų bazių struktūros projektavimas – Nustatomos duomenų struktūros, sukuriamas duomenų

bazės projektas

• Algoritmų projektavimas – Apibrėžiami, projektuojami duomenų apdorojimo

algoritmai.

Projektavimo procesas

61 Chapter 2 Software Processes

Programavimas ir derinimas

• Projekto realizavimas – tai programavimas ir klaidų

šalinimas (debuging).

• Programavimas yra individuali veikla - tai nėra

bendras programavimo procesas.

• Programuotojai atlieka dalį programos testavimo ir

klaidų ištaisymo programos derinimo procese.

Derinimo procesas

Locateerror

Designerror repair

Repairerror

Re-testprogram

Nustatyti

klaidos vietą

Klaidos ištaisymo

projektavimas

Klaidos ištaisymas Programos

pakartotinis

testavimas

Programinės įrangos atestavimas

• Tikrinimas (verification ) ir atestavimas (validation ) turi parodyti, kad sistema atitinka specifikaciją ir sistemos užsakovo reikalavimus.

• Susidedamosios dalys: – tikrinimo bei peržiūros procesai

– sistemos testavimas

• Sistemos testavimas yra jos vykdymas su testavimo duomenimis iš realiai naudojamų duomenų specifikacijos.

Testavimo procesas

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting

Komponentų

testavimas Apjungiantis

testavimas

Vartotojų

testavimas

Testavimo etapai • Komponentų testavimas

– Atskirų komponentų testavimas

• Modulių testavimas

– Susijusių komponentų rinkinių testavimas

• Posistemės testavimas

– Moduliai sujungiami į posistemes ir testuojami. Didžiausias

dėmesys turi būti skiriamas interfeiso testavimui

• Sistemos testavimas

– Vientisos sistemos ir pasireiškiančių savybių testavimas

• Tinkamumo testavimas

– Sistemos tinkamumo testavimas su vartotojo duomenimis

Kūrimo ir testavimo fazės

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

Programinės įrangos tobulinimas

Evolution

• Programinei įrangai būdingas lankstumas ir galimybė keistis.

• Kintant verslo sąlygoms keičiasi reikalavimai, todėl programinė įranga palaikanti verslą irgi turi keistis.

• Kūrimo svarba vis labiau mažėja, nes vis mažiau sistemų yra visiškai naujos.

Sistemos evoliucija

Assess existing

systems

Define systemrequirements

Propose systemchanges

Modify

systems

Newsystem

Existing

systems

Nustatyti reikalavimus

sistemai

Įvertinti egzistuojančias

sistemas Siūlyti sistemos

pakeitimus

Modifikuoti

sistemas

Egzistuojančios

sistemos

Naujos sistemos

Reziumė

• Programų sistemų kūrimo procesas yra veiksmų

seka, kurios tikslas sukurti produktą.

• Proceso veiklos organizuojamas (išdėstomos)

remiantis tam tikromis paradigmomis (modeliais).

• Pagrindiniai PS kūrimo proceso veiklos yra:

– specifikavimas, projektavimas ir realizacija

(programavimas), atestavimas ir tobulinimas.

• Iteraciniai proceso modeliai nusako programinės

įrangos kūrimo procesą kaip veiksmų ciklą.

70

71

Klausimai?