Upload
others
View
4
Download
1
Embed Size (px)
Citation preview
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?