PSI 9 Projektavimas Testavimas 20151114 v01

Programų sistemų
inžinerija
9 dalis: Projektavimas ir testavimas
Skaidrės ruoštos remianti prof. A.Čaplinsko medžiaga
Doc. dr. Diana Kalibatienė

diana.kalibatiene@vgtu.lt
Paskaitos planas
• Programų sistemų inžinerija
– 5 dalis. Projektavimas ir testavimas
• Programų sistemos skaidymas į dalis. Sistemos hierarchija.
Verslo modelio vaidmuo sistemos projektavime. Koncepcinis
projektavimas. Eskizinis projektavimas. Detalusis
projektavimas.
• Programų sistemos architektūra. Coad & Yourdon architektūra.
• Sistemos dekomponavimas: funkcinis dekomponavimas,
objektinis dekomponavimas (OOSR, OOSD), funkcinis
projektavimas ir objektinis projektavimas, paslaugomis
grindžiama dekompozicija, užduotimis grindžiama
dekompozicija, funkcinis projektavimas ir užduotimis
grindžiamas projektavimas..
• Reikalavimų lokalizavimas, nuleidimas žemyn ir trasavimas.
Interfeisų nustatymas. Reikalavimų verifikavimas ir vertinimas
(peržiūra,inspektavimas) 2
Paskaitos planas
• Programų sistemų inžinerija
– 5 dalis. Projektavimas ir testavimas
• Projektavimo kokybės atributai: rišlumas, sankiba, sankiba ir
paveldėjimas, projekto suprantamumas, projekto
adaptyvumas, projekto adaptyvumas ir paveldėjimas
• Testavimas ir derinimas. Testavimo stadijos. Reikalavimai ir
testavimas. Padengimas testais.
• Programų sistemų gyvavimo ciklo modeliai (PSGCM):
samprata, “koduok ir atiduok” modelis, krioklio modelis,
prototipų naudojimas, išmetamieji prototipai, evoliucinis
modelis, greitojo dalykinių programų kūrimo modelis, grupinio
dalykinių programų kūrimo modelis, “sinchronizuok ir
stabilizuok” modelis, pažingsninio kūrimo modelis,
ekstremalusis programavimas, spiralinis modelis, formalaus
sistemos kūrimo modelis, pakartotinas panaudojamumas,
PSGCM reikalavimai. 3
Projektavimas
Programų sistemos
skaidymas į dalis
Dekomponavimas
• Net ir pati mažiausia programų sistema turi būti
išreikšta kaip komponentų hierarchija.
– Sistemos hierarchijos formavimo procesas dažnai
vadinamas sistemos skaidymu (partitioning) į dalis.
– Sistemos skaidymas į dalis yra sistemos
projektavimo proceso dalis.
– Sistemos projektavimas yra kūrybinis procesas.
5
Sistemos hierarchija
• Sistemos hierarchija
– IRS: Interfeiso reikalavimų specifikacija
Sistema
1 posistemis 1 IRS 2 posistemis
•••• 1 komponentas 2 IRS 2 komponentas
3 IRS 1 mazgas 2 mazgas 3 mazgas
•••• 1 modulis 2 modulis 3 modulis ••••

6
6
Projektavimas
Verslo modelis
Architektūros
Tipiniai
sprendimai
Projektavimas
Reikalavimai
PS architektūra
PS
7
Projektavimas
• Objektinis projektavimas traktuoja verslo
modelį kaip aprašą, aprašantį problemas,
kurias spręsti privalo kuriamoji programų
sistema (probleminės srities aprašą):
– Verslo modelis dažnai yra vadinamas
koncepciniu dalykinės srities modeliu
• Angliškai jį dar vadina object-oriented analysis
(OOA) model, nes tai yra pagrindinis dalykinės
srities (verslo) objektinės analizės rezultatas.
8
Projektavimas
• Projektas:
– papildo ir patikslina verslo modelį (t.y.
objektinės analizės rezultatus);
– išreiškia verslo modelį konkrečios realizavimo
infrastruktūros (kompiuterinė platforma,
programavimo kalba, tarpinė programinė įranga
ir kt.) terminais;
– nagrinėja kokiu mastu galima pakartotinai
panaudoti turimus
• objektus,
• tipinius projektavimo sprendimus,
• posistemių ir netgi visos sistemos architektūrą. 9
Projektavimas
• Projektavimas skirstomas:
– Koncepcinis projektavimas
– Eskizinis projektavimas
– Detalusis projektavimas
10
Projektavimas
Koncepcinis projektavimas
• Tai projektavimas aukščiausiame abstrakcijos
lygmenyje. Jo metu:
– verslo modelis transformuojamas į pradinį programų
sistemos modelį
• į sistemą įjungiama “dalykinė dalis”;
– apibrėžiami vartotojo interfeisai, parenkami duomenų
valdymo, komunikavimo ir užduočių valdymo būdai;
– parenkama koncepcinė programų sistemos architektūra;
– sprendžiama, kaip toje architektūroje įgyvendinti
parinktus duomenų valdymo, komunikavimo bei
užduočių valdymo būdus;
– sprendžiama, kaip pasinaudoti tipiniais projektavimo
sprendimais bei turimais gatavais komponentais. 11
Projektavimas
Eskizinis projektavimas
• koncepcinio projektavimo rezultatai patikslinami,
atsižvelgiant į konkrečią kompiuterinę platformą.
Detalusis projektavimas
• išreiškia eskizinį projektą realizavimo infrastruktūros
terminais
– detalūs algoritmai ir duomenų struktūros;
– objektinių struktūrų realizavimas;
– būsenų ir jų kaitos realizavimas;
– sistemos veikimo optimizavimas;
– pakartotinas gatavų komponentų panaudojimas;
– išimtinių situacijų apdorojimas;
– ir t.t.
12
Projektavimas:
PS architektūra
• PS architektūros aprašas aprašo:
– Bendrą sistemos organizavimo būdą (konstrukcijos
santykį).
– Sistemos struktūrinius elementus ir jų interfeisus
• struktūrinių elementų sąveika (o tuo pačiu ir konstrukcijos
santykis) realizuojama per jų interfeisus.
– Struktūrinių ir elgsenos elementų komponavimą į
posistemius.
– Architektūros stilių, t.y. taisykles, kuriomis
vadovaujantis bet kurio lygmens sistemos komponentai
jungiami vienas su kitu.
13
Projektavimas:
PS architektūra
• PS architektūra dažniausiai grindžiama tam tikrais
architektūriniais šablonais.
• Architektūrinis šablonas – tai sistemos
organizavimo būdo aprašas.
– Pvz., kliento-serverio architektūra, sluoksninė
architektūra, Kodo-Jordano architektūra, ...
• Architektūriniai šablonai sudaro architektūros
esmę ir yra naudojami PS projektuoti.
– Svarbu perprasti tuos šablonus ir tinkamai panaudoti
PS projektuoti.
14
Projektavimas:
Pasiteisinusi praktinė patirtis
• Įsitikink, kad parinktoji PS architektūra tikrai yra
tinkama problemai, kurią sprendžia sistema.
• Konstruok architektūrą žingsnis po žingsnio
(incrementally), pradėdamas nuo esminių dalykų
ir juos palaipsniui tikslindamas.
• Projektuok kruopščiai, neignoruok jokių
smulkmenų, bet visą laiką prisimink pagrindinį
projektavimo principą (KIS principle: Keep it
simple): parink kiek įmanoma paprastesnius
sprendimus.
15
Projektavimas
Koudo-Jodano (Coad & Yourdon) architektūra
• Numato, kad PS sudaro keturi posistemiai:
– DP: Dalykinis posistemis (Problem Domain Component);
– IP: Interfeiso posistemis (Human Interaction
Component);
– UVP: Užduočių valdymo posistemis (Task Management
Component);
– DVP: Duomenų valdymo posistemis (Data Management
Component).
– UVP ir DVP sistemoje gali ir nebūti.
16
Projektavimas:
Koudo-Jodano architektūra
Užduotis Rezultatas
Interfeiso
posistemis
Dalykinis
posistemis
Duomenų Užduočių
valdymo valdymo
posistemis posistemis
Operacinė
Duomenų sistema
bazė 17
Projektavimas:
• Dalykinis posistemis skirtas funkciniams
reikalavimams įgyvendinti
– DP klasės imamos tiesiogiai iš verslo modelio.
– Pridedama šakninė klasė, apjungianti visas dalykines
klases į vieną visumą.
– Sąveikai su interfeiso posistemiu įgyvendinti, į DP
pridedamas tam tikras skaičius DP interfeiso klasių.
– Projektuojama sąveika su duomenų valdymo
komponentu arba tiesioginė sąveika su DB
• Tam į kai kurias klases pridedami papildomi atributai bei
papildomos operacijos, kartais į DP pridedamos specialiai tam
skirtos klasės.
18
Projektavimas:
• Interfeiso posistemis realizuoja užduočių
aprašymo kalbą ir rezultatų pateikties funkcijas.
– IP – tai tam tikra ribinės PĮ rūšis.
– Jis operuoja langais, meniu ir kitais interfeiso
objektais.
– Jis transformuoja užduočių aprašus į reikalavimus
suteikti atitinkamas DP teikiamas paslaugas.
– IP realizuojamas panaudojant kokią nors įvykiais
valdomą architektūrą.
– Dažniausiai šį posistemį galima kurti pasinaudojant
rinkoje parduodamais gatavais komponentais. 19
Projektavimas:
• Užduočių valdymo posistemio prisireikia tik
tuomet, kuomet sistema projektuojama kaip
lygiagrečiai vykdomų užduočių rinkinys
(multitasking)
– UVP yra tarpinės programinės įrangos rūšis.
– Dažniausiai šį posistemį galima įsigyti rinkoje kaip
gatavą komponentą.
20
Projektavimas:
• Duomenų valdymo komponentas skirtas dalykinių klasių
prieigos prie duomenų bazės interfeisui (API, application
program interface) sukurti
– DB gali būti realizuota įvairiai: kaip reliacinė DB, kaip
objektinė DB, kaip failų rinkinys ir t.t.
– Jei DP realizuojamas kaip sunkiojo serverio (fat server)
dalis, tarkime. PL SQL priemonėmis, tai DVP yra
nereikalingas.
– DVP yra tarpinės PĮ rūšis
• plačiai žinomas DVP pavyzdys yra ODBC.
– DVP visuomet galima įsigyti rinkoje kaip gatavą
komponentą.
21
Projektavimas
• Koudo-Jodano architektūros projektavimas
išplečia
IP UVP DP DVP
Probleminė
eskizinis sritis
projek-
tavimas patikslina
ir atvaizduoja
detalusis
projek-
tavimas
22
Projektavimas:
Architektūros pavyzdys 1
• Sluoksninės architektūros pavyzdys (Somerville)
23
Projektavimas
Dekompozicija
• Sistemos dekompozicija yra esminė PS
projektavimo dalis
– Sistemos hierarchiją galima projektuoti
panaudojant skirtingus dekompozicijos tipus:
• funkcinę dekompoziciją;
• objektinę dekompoziciją;
• Paslaugomis grindžiamą (service-oriented)
dekompoziciją;
• Užduotimis grindžiamą (task-oriented) dekompoziciją
• ir kt.
24
Projektavimas:
Funkcinė dekompozicija
• Atliekant funkcinę dekompoziciją, sistema
traktuojama kaip funkcijų rinkinys.
• Funkcinė dekompozicija:
– sistema dekomponuojama į modulius;
– kiekvieną modulį dalykinėje srityje atitinka
pakankamai svarbus apdorojimo žingsnis
(funkcija);
– moduliai gali būti skaidomi į smulkesnius modulius.
25
Projektavimas:
• Galimas schema
Sistemos Viršutinis lygmuo
funkcija
Pateikti 1 hierarchijos lygmuo

Skaityti įeigą Apdoroti
rezultatus
Pateikti
Skaityti įeigą Apdoroti 2 hierarchijos lygmuo
rezultatus
Load R10 Add R1, R10 Mašininis lygmuo
26
Projektavimas:
27
Projektavimas:
• Lėktuvo valdymo sistemos pavyzdys
Navigavimo Variklio
sistema valdymas
Instrumentų
parodymai
Ryšio
Radaro
sistema sistema
28
Projektavimas:
• Lėktuvo valdymo sistemos viršutinio lygmens
objektai:
– navigavimo sistema;
– radaro sistema;
– ryšio sistema;
– instrumentų parodymų vaizdavimo sistema;
– variklio valdymo sistema;
– ...
29
Projektavimas:
• Lėktuvo valdymo sistemos funkcijos
(posistemių lygmuo):
– rodyti trasą (radaro posistemis);
– kompensuoti vėjo greitį (navigavimo posistemis);
– sumažinti greitį (variklio valdymo posistemis);
– rodyti aukštį (instrumentų parodymų vaizdavimo
posistemis);
– palaikyti dažnį (ryšio posistemis);
– ...
30
Projektavimas:
• Lėktuvo valdymo sistemos žemo lygmens
objektai:
– variklio būsena;
– lėktuvo koordinatės;
– aukštimatis;
– radijo švyturys;
– ...
31
32
Projektavimas:
• Kursų administravimo pavyzdys
• http://www.tutorialspoint.com/software_testing_dictionary/functional_decomposition.htm
33
Projektavimas:
Objektinė dekompozicija
• Sistema dekomponuojama į klases (“objektus”).
• Dauguma klasių atitinka dalykinės srities sąvokas.
• Klasės gali būti dekomponuojamos į smulkesnes
klases.
34
Projektavimas:
• Atliekant objektinę dekompoziciją, į sistemą
žiūrima kaip į objektų rinkinį.
• Yra du plačiai pripažinti (ankstyvieji) objektinės
dekompozicijos metodai:
– objektinis nuoseklių tikslinimų (object-oriented
stepwise refinement (OOSR)) metodas,
– objektinis struktūrinio projektavimo (object-oriented
structured design (OOSD)) metodas.
35
Projektavimas:
• Objektinis nuoseklių tikslinimų metodas
(ONPM) grindžiamas abstrakcijos principu. Tai
vienas iš seniausiųjų objektinių PS projektavimo
metodu, su juo supažindinama visuose PSI
kursuose.
– Paprastu nuoseklių tikslinimų principu grindžiamas
projektavimo metodas tinka projektuoti tik monolitines
programas
• tokios programos dar yra vadinamos “plokščios” architektūros
programomis.
– Siekiant projektuoti objektines programas, šis metodas
buvo išplėstas
• išplėstas metodas vadinamas “Tikslinimų metodika”
("Refinement Methodology“). 36
Projektavimas:
• ONPM palaiko iteratyvų programų kūrimo būdą,
apjungiantį į vieną gyvavimo ciklo stadiją
projektavimą ir kodavimą.
• Visą kūrimo laiką programa susideda iš dviejų
dalių:
– jau parašyto kodo: visa, kas iki to momento jau yra
galutinai suprogramuota;
– ketinamo parašyti kodo: visa, kas dar turi būti
suprogramuota
37
Projektavimas:
• Interfeisas tarp šių programos dalių yra
vadinamas neatliktų darbų interfeisu ( backlog
interface)
– jį sudaro visos tos esybės, kurios jau buvo
panaudotos parašytoje programos dalyje, tačiau
dar nėra iki galo apibrėžtos
– kitaip tariant, neatliktų darbų interfeisas – tai
ketinamos programuoti programos dalies projektas
• Jam priklauso esybės, kurias reikia apibrėžti artimiausioje
ateityje. Visos kitos programos esybės yra ignoruojamos.
38
Projektavimas:
• Tradicinio nuoseklių patikslinimo metodo, naudojamo
funkcinei dekompozicijai atlikti, neatliktų darbų
interfeisui priklauso tik dviejų tipų esybės:
procedūros ir funkcijos
– su duomenų struktūromis išreikštiniu būdu nėra operuojama, kas
apsunkina metodo panaudojimą.
• ONPM išplečia neatliktų darbų interfeisą: jam
priklauso duomenų struktūros, procedūros/funkcijos
ir tarp jų tekantys duomenų srautai
– Taigi, interfeisui priklauso procedūros, į kurias kreipiamasi iš
parašytos programos dalies, ir duomenų struktūros, per kurias tos
procedūros keičiasi duomenimis.
39
Projektavimas:
• Eilinis ONPM žingsnis susideda iš tokių veiksmų:
1. iš einamojo neatliktų darbų interfeiso išrenkamas
esybių klasteris;
2. apibrėžiamos tam klasteriui priklausančios esybės ir
šitaip gautu apibrėžčių paketu papildoma parašytoji
programos dalis;
• visi vidiniai duomenų srautai ir visos vidinės duomenų
struktūros yra paslepiami to paketo viduje;
• esybių klasteris yra parenkamas taip, kad visos jam
priklausančios esybės būtų susijusios arba su kokia nors
dalykinės srities esybe (pvz., knyga, skaitytoju ar pan.), arba
su kokiu nors abstrakčiu duomenų tipu (pvz., steku, aibe ar
pan.).
40
Projektavimas:
• Eilinis ONPM žingsnis susideda iš tokių veiksmų
(tęsinys):
3. Atnaujinamas neatliktų darbų interfeisas
• iš jo pašalinamos apibrėžtos esybės ir pridedamos papildomos
esybės, atsiradusios rašant tas apibrėžtis.
4. Neatliktų darbų interfeisas papildomas esybėmis,
reikalingomis duomenims perduoti tarp naujai
atsiradusių esybių.
41
Projektavimas:
• Objektinis struktūrinio projektavimo
metodas (OSPM):
– remiasi prielaida kad turima užduočių diagrama (use case
diagram) aprašanti programų sistemą aukščiausiame abstrakcijos
lygmenyje:
– kiekvieną PS reikalavimų dokumentacijoje aprašytą užduotį turi
atitikti užduotis užduočių diagramoje;
– po to, kiekviena užduočių diagramos užduotis turi būti aprašyta
tos užduoties vykdymo scenarijumi ir kiekvienas toks scenarijus
turi būti pavaizduotas atitinkama sekų diagrama;
– iš kiekvienos sekų diagramos generuojamos aukščiausiojo
abstrakcijos lygmens klasių ir būsenų diagramos;
– visos su viena užduotimi susijusios diagramos yra grupuojamos į
vieną paketą.
– šitaip gaunami paketai P1, P2, …., Pn
42
Projektavimas:
• Panaudojant standartinę užduočių modeliavimo
metodiką, kiekvienas paketas yra
dekomponuojamas į žemesnio abstrakcijos
lygmens paketus:
– kiekvienam neelementariam sekų diagrama aprašyto scenarijaus
žingsniui apibrėžiama žemesnio lygmens užduotis;
– kiekviena nauja užduotis aprašoma scenarijumi ir tas scenarijus
pavaizduojamas sekų diagrama;
– kiekvienai naujai užduočiai kuriamos žemesniojo lygmens klasių ir
būsenų diagramos (jos kuriamos detalizuojant aukštesniojo
lygmens diagramas, kam panaudojamos tų užduočių sekų
diagramos);
– kiekvienai naujai užduočiai kuriamas žemesnio lygmens paketas,
grupuojantis visas tos užduoties diagramas.
43
Projektavimas:
• Procesas yra pabaigiamas, kada nei viename
scenarijuje nebelieka nei vieno neelementaraus
žingsnio
– Scenarijaus žingsnis yra vadinamas elementariu, jei jis
yra aprašomas paprastu pranešimu.
44
Projektavimas:
• Objektinio struktūrinio projektavimo
metodo (OSPM) schema:
Reikalavimų
Requirements
specifikacija
specification
Projektavimo
Design activities darbai
Data
Duomenų
Architektūros
Architectural Paketų
Abstract Interfeisų
Interface Komponentų
Component Algorithm
Algoritmų
design specificatio design design structure
struktūrų design
projektavimas specifikavimas projektavimas projektavimas design projektavimas
n projektavimas
Duomenų
Data
Sistemos
System Software
Paketų Interfeisų
Interface Komponentų
Component Algoritmų
Algorithm
specification specifikacijos specifikacijos struktūrų
structure specifikacijos
architecture
architektūra specifikacijos specification specification specification
specification
specifikacijos
Design products
Projektavimo rezultatai
45
Projektavimas:
• Hierarchinė projekto struktūra
Sistemos
Systemlygmuo
level
Sub-system
level lygmuo
Posistemių
46
Projektavimas:
• Projektavimo žingsniai
– architektūros projektavimas: nustatomi žemesniojo lygmens
paketai;
– paketų specifikavimas: sudaromos visų paketų
specifikacijos;
– interfeisų projektavimas: projektuojami visų paketų
interfeisai;
– komponentų projektavimas: kiekvienam paketui
projektuojamas jį realizuojantis komponentas;
– duomenų struktūrų projektavimas: projektuojamos
probleminiams duomenims saugoti skirtos duomenų
struktūros t.y. DB klasių diagrama)
– algoritmų projektavimas: projektuojami komponentų veikimo
algoritmai.
47
Projektavimas
Funkcinio ir objektinio projektavimo skirtumai
– Funkcinis projektavimas
• Sistema traktuojama kaip funkcijų rinkinys. Sistema
turi centralizuotą būseną, su kuria dirba visos
funkcijos.
– Objektinis projektavimas
• Sistema traktuojama kaip sąveikaujančių objektų
rinkinys. Sistemos būsena decentralizuota, kiekvienas
objektas pats tvarko savo būseną. Objektai yra klasių
egzemplioriai ir komunikuoja vienas su kitu
keisdamiesi pranešimais.
48
Projektavimas
• Funkcinė kompiliatoriaus traktuotė
Pradinė
Source Tokens Tokens
Leksemos Syntax
Sintaksinis Objektinis
Object
Leksemos tree
program
programa medis kodas
code
Build
Ženklų
Scan Sintaksinė
Analyse Generate
Kodo
Programos symbol
lentelės
source analizė code
generavimas
skenavimas table
formavimas
Error
Symbols
Ženklai Ženklai Klaidos
Symbols indicator
Symbol
Ženklų Output
Klaidų
table
lentelė errors
spausdinimas
Error
Pranešimai
apiemessages
klaidas
49
Projektavimas
• Objektinė kompiliatoriaus traktuotė
Skenuoti
Scan Rašyti
Add
Source
Pradinė Token
Leksemų Symbol
Ženklų
program
programa stream
srautas table
lentelė
Tikrinti
Check Get
Gauti
Sintaksinis
Syntax Error
Pranešimai
Grammar
Gramatika
tree
medis messages
apie klaidas
Build Print
Konstruoti Spausdinti
Generuoti Generate
Abstract
Abstraktusis Object
Objektinis
code
kodas code
kodas
Generate
Generuoti
50
Projektavimas:
Paslaugomis grindžiama
dekompozicija
• Paslaugomis grindžiama (service-oriented)
dekompozicija aprašo sistemos dekomponavimą į
paslaugas.
• Paprastai tokia dekompozicija naudojama kuriant
paslaugų architektūros įmonių ar organizacijų
informacines sistemas.
– Siekiama dekomponuoti verslo sistemą į jos verslo
procesus palaikančias paslaugas ir kompiuterizuoti tas
paslaugas.
51
Projektavimas:
dekompozicija
• Šiuolaikinės įmonės bei organizacijos beveik
visuomet jau turi kokias nors programų sistemas,
palaikančias daugumą tos įmonės ar
organizacijos verslo funkcijų.
– Iš pirmo žvilgsnio gali pasirodyti, jog, pereinant
prie paslaugų architektūros, pakanka tų programų
sistemų funkcijas tiesiog paversti paslaugomis.
– Deja, toks požiūris yra visiškai klaidingas. Sistemą
reikia projektuoti iš naujo ir ją dekomponuoti į
paslaugas toli gražu nėra paprasta.
52
Projektavimas:
dekompozicija
• Pradinis taškas yra įmonės ar organizacijos verslo
sistemos modelis (enterprise business model).
– Darydami 2-ą laboratorinį darbą, jūs modeliavote UML
kalba savo pasirinktą verslo sistemą.
• Iš tiesų standartinė UML kalba tam nėra labai tinkama. Yra
sukurti net keli UML profailai, pritaikyti verslo sistemoms
modeliuoti ir praktikoje dažniausiai naudojamas kuris nors iš
jų.
• Yra taip pat ir specialiai verslui modeliuoti skirtų kalbų,
neturinčių nieko bendro su UML.
53
Projektavimas:
dekompozicija
• Yra daug skirtingų verslo sistemų modeliavimo
metodikų.
– Pagal bet kurią iš jų yra modeliuojami verslo procesai ir
ištekliai, reikalingi verslo tikslams pasiekti.
– Darydami 2-ą laboratorinį darbą, jūs modeliavote UML
kalba savo pasirinktą verslo sistemą.
• Kuriamos sistemos dekomponavimas į paslaugas
pradedamas nuo verslo procesų modelių.
– Visa įmonės ar organizacijos verslo sistema irgi yra
traktuojama kaip aukščiausio lygmens verslo procesas,
kuris yra sudarytas iš žemesnio lygmens verslo
procesų.
54
Projektavimas:
dekompozicija
55
Projektavimas
Įmonės verslo sistemos

modelio viršutinio
lygmens pavyzdys.
Tokia diagrama
visuomet turi būti
paprasta ir lengvai
apžvelgiama. 56
Projektavimas
• Verslo proceso modelio pavyzdys (su
IBMWebSphere Business Modeler).
57
Projektavimas:
dekompozicija
• Kaip ir kitokio sistemos dekomponavimo atveju,
dekomponavimas į paslaugas yra tam tikra
sistemos projektavimo iš viršaus žemyn forma.
• Rezultatas yra hierarchinė dekompozicija,
parodanti kaip verslo procesai yra dekomponuoti į
paslaugas bei žemesnio lygmens verslo procesus.
• Sistema traktuojama kaip verslo procesas
orkestruojantis jam įgyvendinti reikalingas
paslaugas.
– Orkestravimu vadinamas kokia nors specialiai tam
skirta kalba, pavyzdžiui, BPEL, parašyto aprašo,
aprašančio paslaugų naudojimo nuoseklumą ir jų
tarpusavio sąveikas, interpretavimas.
58
Projektavimas:
dekompozicija
• Po to kiekviena paslauga gali būti dekomponuota
į žemesnio lygmens verslo procesus,
orkestruojančius žemesnio lygmens paslaugas.
• Dekompozicija gali būti daroma vadovaujantis
skirtingais kriterijais.
– Dekomponavimo kriterijai parenkami atsižvelgiant į
pasirinktus sistemos projektavimo tikslus (našumas,
lankstumas, projekto trukmė ir pan.).
59
Projektavimas:
dekompozicija
• Kiekviena paslauga
dekomponuojama į
žemesnio lygmens
verslo procesus,
orkestruojančius
žemesnio lygmens
paslaugas.
60
Projektavimas:
dekompozicija
• Apskritai, dekomponuojant sistemą į paslaugas,
labai svarbūs yra du veiksniai:
– grūdėtumas;
– matomumas.
61
Projektavimas:
dekompozicija
• Grūdėtumas ir matomumas.
– Juo aukštesnio lygmens yra procesas ar paslaugas, tuo
jis yra stambesnis.
– Kviečiant žemesnio lygmens paslaugas, tenka atlikti
tam tikrą darbą, dėl ko prarandamas sistemos
efektyvumas.
– Kol kas nėra jokios matematinės teorijos, leidžiančios
nuspręsti, kokio grūdėtumas paslaugas reikėtų parinkti
kiekviename iš lygmenų.
62
Projektavimas:
dekompozicija
• Paslaugos kaip
granulės, talpinamos
vienos kitų viduje
63
Projektavimas:
dekompozicija
• Iš verslo požiūrio taško, paslaugos turėtų būti
projektuojamos atsižvelgiant į tai, ar:
– paslaugos reikalingumas tiesiogiai seka iš verslo
modelio;
– verslas nori padaryti paslaugą matomą savo
partneriams;
– verslas planuoja iš ko nors pirkti (outsource) tą
paslaugą;
– paslauga verslui yra kritinė.
64
Projektavimas:
dekompozicija
• Iš technologinio požiūrio taško, paslaugos turėtų
būti projektuojamos atsižvelgiant į tai, ar jas
ketinama panaudoti kituose verslo procesuose
arba galbūt netgi kitose verslo sistemose.
– Norint panaudoti paslaugas skirtingose sistemose ar
procesuose, ją reikia universalizuoti ir standartizuoti.
65
Projektavimas:
dekompozicija
• Matomumas
– Juo aukštesnio lygmens yra procesas ar
paslauga, tuo plačiau jie yra matomi.
• Pavyzdžiui, visa sistema kaip procesas yra matoma
visos įmonės ar organizacijos mastu. Kita vertus, kai
kurios paslaugos gali būti matomos tik kokiam nors
padaliniui ar netgi tik keliems darbuotojams.
– Paprastai, grūdėtumas ir matomumas yra
nagrinėjami kartu ir juo aukštesnio lygmens
yra paslauga, tuo ji yra stambesnė ir tuo
plačiau ji yra matoma.
66
Projektavimas:
dekompozicija
• Blogai
suprojektuotos
sistemos
grūdėtumas –
per daug
smulkių
paslaugų, per
mažai
hierarchijos.
67
Projektavimas:
dekompozicija
• Kiti technologiniai veiksniai, į kuriuos reikia
atsižvelgti projektuojant paslaugas:
– paslaugos pateikiamos per tinklą, tinklas gali būti
perkrautas, jame gali vykti trykiai ir kt.
– paslaugos turi būti parenkamos griežtai vadovaujantis
turinių atskyrimo principu, nes nei viena paslauga
nežino, kokios kitos paslaugos yra naudojamos
sistemoje;
• Kita vertus, vadovaujantis verslo modeliu, pastangas dažnai
patogu būtų klasterizuoti, paversti priklausomomis vienas nuo
kitų.
• Panašiai atsitinka ir tuomet, kuomet paslaugų sistema
projektuojama virš jau sukurtų programų sistemų.
68
Projektavimas:
dekompozicija
• Kiti technologiniai veiksniai, į kuriuos reikia
atsižvelgti projektuojant paslaugas:
– jei paslaugos komunikuoja besikeisdamos XML
schemomis specifikuotais pranešimais, paslaugų
interfeisai gali būti padaryti nepriklausomi ir nuo
programavimo kalbos, kuria programuojama paslaugų
realizacija, ir nuo konkrečios kompiuterinės platformos.
• Paslaugų interfeisų projektavimas yra esminė paslaugomis
grindžiamos dekompozicijos dalis.
69
Projektavimas:
dekompozicija
Paslaugų sistemos,
paslaugas teikiančių
komponentų ir tuos
komponentus
realizuojančių
programų
projektavimas.
70
Projektavimas:
Užduotimis grindžiama
dekompozicija (task-oriented)
• Naudojama agentinėms sistemoms projektuoti
– Ši metodika vartoja organizacijų projektavimo teorijos
sąvokas: užduotis (task), valdymas (control), darbas (job),
operacija (operation), vadovavimas (management),
koordinavimas (coordination) ir organizavimas
(organisation).
– Sistemos vykdomos užduotys yra dekomponuojamos į
darbus.
– Po to darbai vėl integruojami, panaudojant darbų
lokalizavimo (job allocation), koordinavimo ir organizacinio
pertvarkymo(organisational structuring) mechanizmus.
71
Projektavimas:
Užduotimis grindžiama
dekompozicija
• Yra keletas koordinavimo mechanizmų:
– Tiesioginis valdymas (Direct Supervision),
kuomet kas nors vienas sprendžia, ką turi daryti
visi kiti agentai.
– Daugkartinių patikslinimų (Mutual
Adjustment), kuomet agentai, komunikuodami su
kitais agentais, patys koordinuoja savo veiklą.
– Darbo proceso, rezultatų ir darbo būdų
standartizavimas, kuomet visi agentai veikia
pagal iš anksto nustatytas griežtas taisykles...
72
Projektavimas
Funkcinio ir užduotimis grindžiamo projektavimo
skirtumai
– Funkcinis projektavimas
• sistemą sudaro nuosekliai vienas po kito vykdomi
moduliai, realizuojantys nepriklausomas funkcijas.
– Užduotimis grindžiamas projektavimas
• sistemą sudaro lygiagrečiai vykdomi moduliai
(agentai), kiekvienas iš kurių vykdo kokias nors
specifines užduotis (jas moka vykdyti tik jis vienas).
73
Projektavimas:
Mišrios projektavimo strategijos
• Nors kartais yra teigiama, kad vienas kuris nors
projektavimo būdas yra geriausias, iš tiesų jie
papildo vienas kitą ir, projektuojant programų
sistemą, paprastai turi būti derinami keli
dekompozicijos metodai.
• Geras projektuotojas privalo gebėti kiekvienam
komponentui parinkti geriausiai jam tinkantį
projektavimo metodą.
74
Projektavimas:
Dekompozicija
• Bet kuriuo būdu atliekant sistemos
dekompoziciją, visuomet reikia atsižvelgti į
pasirinktąją tos sistemos architektūrą ir prie jos
taikytis:
– dekompozicija turi būti atliekama vadovaujantis
konkrečia architektūra (it is an architecture-oriented
activity);
– architektūrą reikia pasirinkti prieš pradedant
dekomponuoti sistemą.
75
Projektavimas:
Agregavimas
• Po to, kai sukuriami žemiausiojo lygmens

(baziniai) komponentai, jie yra integruojami į
stambesnius komponentus (funkcinius agregatus)
– Funkciniai agregatai yra integruojami į stambesnius ir
stambesnius agregatus, iki pakylama iki visos sistemos
lygmens.
– Dekomponuojama “iš viršaus žemyn”.
– Agreguojama “iš apačios aukštyn”.
76
Projektavimas:
Sistemos
dekomponavimo trasos
• Didesnės sistemos hierarchija gali būti gana
didelė ir sunkiai pavaizduojama viename
brėžinyje. Todėl ji yra dokumentuojama parodant
dekompozicijos trasas, t.y. parodant, koks
agregatas į kokias dalis buvo dekomponuotas.
• Trasos gali būti vaizduojamos grafiškai arba
aprašomos dekompozicijos trasų matrica.
77
Projektavimas
• Sistemos agregatų dekomponavimo trasos
C
F
B
D
A
Agregatų lygmuo
P O R Agregato D
dekompozicija
78
Projektavimas:
Dekompozicijos trasų
matrica
Kas dekomponuota Į ką dekomponuota

Sistema S 1 PS, 2 PS, 1 IRS
1 IRS 1 komp, 2 komp, 2 IRS
1 PS ……
…… …….
11 tema 79
79
Projektavimo
reikalavimai
Projektavimo
reikalavimai
• Dekomponavus sistemą į komponentus,
kiekvienam komponentui aprašomi reikalavimai.
• Šie projektiniai reikalavimai išvedami iš
reikalavimų iš reikalavimų specifikacijos.
81
Projektavimo reikalavimai:
Dekompozicija
• PS inžinieriui tenka dirbti su visų lygmenų
sistemos hierarchijos elementų reikalavimais:
– visos sistemos reikalavimais;
– visų lygmenų funkcinių agregatų reikalavimais;
– bazinių komponentų reikalavimais.
• Tai reiškia, kad terminas reikalavimų specifikacija
yra sąlyginis, tokia specifikacija gali aprašyti bet
kurio komponento reikalavimus
– Taigi, projekte paprastai esti daugiau negu viena
reikalavimų specifikacija.
82
Reikalavimų lokalizavimas
• Bet kuris sistemos reikalavimas turi būti
lokalizuotas (allocated) viename arba daugiau
jos komponentų
– tai reiškia, kad turi būti žinoma, kurie komponentai
realizuoja tą reikalavimą.
• Atliekant lokalizavimą gali paaiškėti, kad
– sistemos reikalavimus reikia keisti
• papildyti, modifikuoti, išbraukti kai kuriuos reikalavimus;
– kai kurių komponentų apibrėžtys nėra korektiškos.
83
• Reikalavimų lokalizavimo schema
Sistemos
reikalavimai
Lokalizuojami Nelokalizuojami Reikalavimai

reikalavimais (realizuojami sistemos
komponentų visuma)
Išvestiniai Tiesiogiai lokalizuojami

reikalavimai (susiejami su konkrečiais
komponentais)
Posistemis 1
Nelokalizuojami Tiesiogiai
lokalizuojami ∑ Posistemis 2
Posistemis 3
∑
84
• Lokalizavimo procesas yra iteratyvus,
užsibaigiantis lokalizavus visus sistemos
reikalavimus.
• Kiekvienas reikalavimas turi būti lokalizuotas bent
viename žemesniojo lygmens komponente.
• Lokalizuojami reikalavimai gali būti lokalizuojami
tiesiogiai arba netiesiogiai
– Tiesiogiai lokalizuojami reikalavimai nėra
keičiami, o tik susiejami su konkrečiais komponentais.
– Netiesiogiai lokalizuojami reikalavimai
reikalavimų nuleidimo žemyn metu yra perrašomi
(keičiami).
85
Reikalavimų lokalizavimo
matrica
Sistemos 1 2 ... 1 IRS

reikalavimai posistemis posistemis
1 SR X X ...
2 SR X ... X
……. ……. ……. …… …….
N SR X ...
86
Reikalavimų lokalizavimo
matrica
1 IRS 1 2 ... 2
reikalavimai komponentas komponentas IRS
1 IRS F 001 X ... X
2 IRS F 002 X ...
……. ……. ……. ... …….
1 IRS P001 ... X
……… ……. ……. … …
IRS – interfeiso reikalavimų specifikacija
87
Reikalavimų nuleidimas
žemyn
• Antras lokalizavimo proceso žingsnis vadinamas
reikalavimų nuleidimu žemyn (flowdown)
– Tai lokalizuotų reikalavimų perrašymas
komponentų, kuriuose jie yra lokalizuoti,
terminais.
• Lokalizavus reikalavimą posistemyje, tą reikalavimą reikia
suformuluoti kaip vieną ar daugiau posistemio reikalavimų.
• Dažniausiai formuluojami keli reikalavimai, bet gali būti ir
atvirkščiai, t.y. iš kelių posistemyje lokalizuotų reikalavimų gali
būti suformuluotas vienas (išvestinis) posistemio reikalavimas.
88
žemyn
• Antras lokalizavimo proceso žingsnis vadinamas
reikalavimų nuleidimu žemyn (tęsinys)
– Tai lokalizuotų reikalavimų perrašymas
komponentų, kuriuose jie yra lokalizuoti,
terminais.
• Žemesniojo lygmens reikalavimai gali būti labai panašūs į
aukštesniojo lygmens reikalavimus, bet gali būti ir visai
nepanašūs į juos.
• Pastaruoju atveju žemesniojo lygmens reikalavimai vadinami
išvestiniais.
89
Projektavimo
reikalavimai Tuo pat metu jie
Lygmuo po lygmens
lygmuo po lygmens
reikalavimai
nuleidžiami žemyn
lokalizuojami
iki apatinio
sistemos Sistema (modulių) lygmens
posistemiuose,
komponentuose,
mazguose ir 1 posistemis 1 IRS 2 posistemis
moduliuose
•••• 1 komponentas 2 IRS 2 komponentas
3 IRS 1 mazgas 2 mazgas 3 mazgas
•••• 1 modulis 2 modulis 3 modulis ••••
90
žemyn
• Judant sistemos hierarchija žemyn, reikalavimai
tampa vis detalesni ir konkretesni.
– Sistemos reikalavimai yra labai bendri, žemesniųjų
lygmenų reikalavimai yra vis konkretesni ir
konkretesni.
• Svarbiausieji reikalavimų inžinerijos instrumentai yra
dekompozicija ir abstrakcija: sistema skaidoma
(dekomponuojama) į vis smulkesnius ir smulkesnius
komponentus, abstraktūs (t.y. bendro pobūdžio) sistemos
reikalavimai smulkesniems komponentams yra vis labiau ir
labiau konkretizuojami.
91
žemyn
• Pavyzdys
Sistemos reikalavimai
001 SR. Sistemoje turi būti numatytos priemonės prieigai prie kitų sistemų
(Navision, RP/3, etc.) sukurtų failų.
Posistemio reikalavimai
F001 1PS. Vartotojas turi turėti galimybę nurodyti išorinio failo tipą.
F002 1PS. Su kiekvieno tipo failu turi būti susieta jam apdoroti skirta priemonė
F003 1PS. Kiekvienas leistinas tipas ekrane turi būti pavaizduotas specialia
piktograma.
F004 1PS. Vartotojas turi turėti galimybę apibrėžti naujus failų tipus ir su jais susieti
naujas piktogramas.
F005 1PS. Vartotojui parinkus failą vaizduojančią piktogramą ir nurodžius
failo pavadinimą, turi būti iškviesta tam failo tipui apdoroti skirta priemonė
ir jai kaip parametras turi būti perduotas apdorojamo failo pavadinimas. 92
žemyn
• Atliekant reikalavimų nuleidimą žemyn, gali būti
aptiktos lokalizavimo, sistemos hierarchijos
formavimo ir netgi sistemos reikalavimų klaidos
– reikalavimų nuleidimo procesas irgi yra iteratyvus, jis
gali iššaukti būtinybę pakartoti kai kuriuos ankstesnius
procesus.
93
žemyn matrica
Sistemos 1 2 ... 1 IRS

reikalavimai posistemis posistemis
001 SF F001 1PS F001 2PS ...
F002 1PS F002 2PS
F003 1PS
002 SF F003 2PS ... F001 1IRS
F002 1IRS
001 SR R001 2PS ...
R002 2PS
94
94
žemyn
• Sistemos skaidymo, reikalavimų lokalizavimo ir
reikalavimų nuleidimo procesas tęsiamas tol, kol
nėra nusileidžiama į patį apatinį sistemos
hierarchijos lygmenį.
• Nuleidimas žemyn transformuoja sistemos
reikalavimus į projektavimo reikalavimus,
vadovaujantis kuriais galima sukurti ir ištestuoti
visus sistemos komponentus.
– t.y. suformuluojamos konkrečios užduotys
projektuotojams, programuotojams ir testuotojams.
95
Reikalavimų
nuleidimą žemyn
vaizduojanti paketų
diagrama
11 tema 96
96
Reikalavimų trasavimas
• Atliekant reikalavimų nuleidimą ir lokalizavimą,
reikalavimų skaičius auga labai sparčiai
– Padarius prielaidas, kad
• sistemos hierarchija yra keturių lygmenų,
• kiekvienas komponentas žemesniame lygmenyje yra
skaidomas į keturis,
• kiekvienas reikalavimas lokalizuojamas dviejuose iš keturių
komponentų,
• nuleidžiant žemyn, iš kiekvieno reikalavimo yra išvedami trys
nauji reikalavimai,
kiekvienam sistemos reikalavimui apatiniame hierarchijos
lygmenyje gaunami 250 reikalavimų.
97
• Norint įsitikinti, kad reikalavimų nuleidimo metu
jokie reikalavimai neprapuolė ir neatsirado kokių
nors naujų, nemotyvuotų reikalavimų,
reikalavimus reikia susieti į trasas, parodant,
kokie reikalavimai iš kokių buvo išvesti
– atsakyti į tuos klausimus tiesiog skaitant ir nagrinėjant
reikalavimus bent kiek didesnėje sistemoje praktiškai
yra neįmanoma.
98
• Reikalavimų trasavimas – tai savotiška
reikalavimų inventorizacija, primenanti įsigyto
turto inventorizaciją buhalterinėje apskaitoje
– trasavimas padeda įsitikinti, kad reikalavimų
lokalizavimas ir nuleidimas žemyn buvo atlikti teisingai;
– jei tenka keisti pradinius sistemos reikalavimus, pagal
trasas yra nustatoma, kokius išvestinius projektavimo ir
realizavimo reikalavimus tie pokyčiai palies.
99
Reikalavimų trasavimo
matrica
Reikalavimas Iš ko Kur
išvestas lokalizuotas
F001 SR - 1PS, 2PS
F001 2PS SF 001 1 komp
SF 004 8 komp
F002 2PS SF 001 1 komp
3 IRS
…… ……. ………
100
• Pastaba:
– reikalavimų lokalizavimas ir nuleidimas žemyn yra
inžinerinio pobūdžio užduotys, be jų neįmanoma
sukurti programų sistemos;
– reikalavimų trasavimas nėra inžinerinio pobūdžio
darbas, tai pagalbinė užduotis, be kurios būtų sunku
tvarkyti reikalavimus.
101
Interfeisų specifikavimas
• Kiekviename sistemos hierarchijos lygmenyje,
atlikus reikalavimų lokalizavimą ir nuleidimą
žemyn, reikia specifikuoti to lygmens sistemos
elementų interfeisus.
– Specifikavimo procesas susideda iš dviejų žingsnių
• Specializuojami ir detalizuojami aukštesniojo lygmens
interfeisai
– pvz., sistemos vartotojo interfeisai lokalizuojami posistemiuose ir
nuleidžiami žemyn.
• Interfeisai papildomi elementais, reikalingais to lygmens
elementų tarpusavio sąveikai
– pvz., posistemiai kreipiasi vienas į kitą.
102
Praktinės pastabos
• Pateiktas darbo su reikalavimais procesas yra
sistemos projektavimo iš viršaus žemyn procesas.
– Pradedama nuo viršutinio sistemos hierarchijos
lygmens ir lygmuo po lygmens einama iki apatinio
lygmens.
• Praktikoje didelės programų sistemos niekuomet
nėra projektuojamos griežtai iš viršaus žemyn.
Kai kurios sistemos šakos (trasos) yra
suprojektuojamos pirma negu kitos ir įgyta
patirtimi pasinaudojama projektuojant tas kitas
šakas.
103
• Pažiūrėti Somerville ☺
104
Reikalavimų verifikavimas
ir vertinimas
ir vertinimas
• Paskutinė darbo su reikalavimais užduotis yra
atlikto darbo rezultatų verifikavimas ir vertinimas
– sistemos dekompozicijos, reikalavimų lokalizavimo bei
nuleidimo žemyn ir interfeisų specifikavimo rezultatų
verifikavimas ir vertinimas yra nei kiek nemažiau
svarbus negu tų rezultatų generavimas:
– prieš pradedant įgyvendinti reikalavimus, juos reikia
verifikuoti ir įvertinti
• jau kalbėjome, kaip yra vertinami sistemos reikalavimai; tą
patį reikia padaryti ir su posistemių bei visų kitų sistemos
komponentų reikalavimais;
• komponentų reikalavimus dar reikia ir verifikuoti, t.y. patikrinti
ar jie buvo teisingai lokalizuoti ir nuleisti žemyn.
106
ir vertinimas
• Projektavimo rezultatams verifikuoti ir vertinti yra
naudojamos tos pačios procedūros kaip ir
verifikuojant bei vertinant sistemos reikalavimus,
t.y.:
– peržiūra (walk-through);
– inspektavimas (inspection).
107
Peržiūra
• Peržiūra yra vertinimo procedūra, ji skirta priimtiems
sistemos projektavimo sprendimams įvertinti. Tam reikia
detaliai išsiaiškinti ir perprasti projektavimo rezultatus. Todėl
peržiūros grupės dalyviai yra skatinami užduoti kuo daugiau
klausimų asmenims, pristatinėjantiems tuos rezultatus.
• Prieš grupės susitikimą peržiūrima medžiaga yra išdalinama
visiems peržiūros grupės nariams.
• Peržiūros metu, pristatantysis trumpai apžvelgia pristatomus
darbo rezultatus, po to grupės nariai, atsakingi už atskirų
klausimų referavimą, žingsnis po žingsnio apžvelgia jų
peržiūrėtą medžiagą.
• Labai svarbu, kad peržiūros metu vyrautų laisva, neformali
atmosfera.
108
Inspektavimas
• Inspektavimas yra verifikavimo procedūra, ja siekiama atrasti
darbo metu padarytas klaidas ir užtikrinti aukštą rezultatų
kokybę.
– Tikrinama, ar teisingai buvo lokalizuoti ir nuleisti žemyn reikalavimai ir
ar teisingai buvo specifikuoti komponentų interfeisai.
• Inspektavimo grupę sudaro lygiateisiai nariai, gerai išmanantys
darbo su reikalavimais procedūras ir susipažinę su projekte
naudojamais standartais.
• Inspektuojama medžiaga (reikalavimai, projektinė
dokumentacija, programų tekstai ir kt.) išdalijama grupės
nariams keletą dienų prieš grupės posėdį. Kiekvienas grupės
narys gauna klausimyną, į kurio klausimus jam reikia atsakyti.
Klausimyno pobūdis priklauso nuo to, už ką atsakingas yra tas
grupės narys. Posėdžio metu, kiekvienas narys pristato savo
išvadas. Jas apibendrinus, gaunamas bendras inspektuojamos
medžiagos įvertinimas. 109
Peržiūra ir inspektavimas
• Peržiūros ir inspektavimo procedūros yra daug
kuo panašios: suburiamos ekspertų grupės,
analizuojama pateiktoji medžiaga, analizės
rezultatai aptariami grupės posėdyje, posėdžio
eiga protokoluojama, jame nusprendžiama, kokių
veiksmų reikia imtis padėčiai ištaisyti ir kokiais
terminais tai turi būti padaryta.
• Po to, rengiami kiti grupės posėdžiai, kuriuose
aptariama, kas buvo padaryta ir sprendžiama, ar
to jau pakanka.
110
Projektavimo kokybė
Projektavimo kokybė
• Projektavimo kokybės samprata yra gana
neapibrėžta. Kokybė priklauso nuo konkrečiame
projekte pasirinktų prioritetų.
– “gera” gali būti našiausia, patikimiausia, pigiausia,
lengviausiai aptarnaujama ar kitokia programų
sistema.
• Programų sistemos kokybės charakteristikos
(nefunkciniai reikalavimai) gali būti sėkmingai
panaudotos ir funkcinio bei objektinio
projektavimo rezultatams vertinti.
• Toliau aptariami specifiniai projektavimo rezultatų
kokybės vertinimo kriterijai visų pirma sietini su
112
kuriamos sistemos prižiūrimumu.
Projektavimo kokybė:
Rišlumas (cohesion)
• Komponento rišlumas – tai suprojektuoto
komponento “patvarumo” matas (kokia tikimybė,
kad jis subyrės, darant pakeitimus).
• Rišlus komponentas įgyvendina vieną sistemos
funkciją (funkciniame projektavime) arba vieną
sistemos esybę (objektiniame projektavime).
• Komponentų rišlumas yra pageidautina projekto
savybė, nes jis įgalina lokalizuoti daromus
pakeitimus konkrečiuose (rišliuose)
komponentuose.
• Yra keletas rišlumo lygmenų.
113
Rišlumo lygmenys
• Atsitiktinis rišlumas (silpnas)
– Komponento dalys niekaip nesusietos tarpusavyje.
• Loginis rišlumas (silpnas)
– Komponentas realizuoja kelias pagal panašius
algoritmus realizuojamas (turinčias panašią logiką)
funkcijas.
• Rišlumas pagal laiko momentą (silpnas)
– Visos komponento dalys yra vykdomos tuo pat metu,
bet jos naudojamos skirtingiems tikslams.
• Procedūrinis rišlumas (silpnas)
– Komponento dalys nuosekliai vykdomos viena po kitos
(sujungtos valdymo grandine).
114
Rišlumo lygmenys
• Komunikacinis rišlumas (vidutinis)
– Visos komponento dalys arba apdoroja tą pačią įeigą,
arba kuria tą pačią išeigą.
• Nuoseklus rišlumas (vidutinis)
– Komponento dalys siejamos duomenų grandine (vienos
dalies išeiga yra įeiga kitai daliai).
• Funkcinis rišlumas (stiprus)
– Visos komponento dalys skirtos tai pačiai funkcijai
realizuoti.
• Objektinis rišlumas (stiprus)
– Komponento dalys – tai operacijos, vykdomos ant tos
pačios duomenų struktūros (komponentas realizuotas kaip
objektas). 115
Rišlumas
Rišlumas kaip projektavimo kokybės vertinimo
kriterijus
• Suformuluotas nepakankamai griežtai. Dažnai
sunku nustatyti komponento rišlumo lygmenį.
• Klasės atributų paveldėjimas iš viršklasio silpnina
komponento rišlumą.
– Jei viršklasis ir klasė yra skirtinguose komponentuose,
norint perprasti komponentą, kuriame yra klasė, tenka
aiškintis dar ir viršklasį realizuojantį komponentą.
116
Komponentų sankiba (coupling)
• Komponentų sankiba – tai komponentų tarpusavio
priklausomumo matas (kokia tikimybė, kad aiškinantis
vieną komponentą, teks domėtis kitais komponentais).
• Jei komponentai yra silpnai sukibę, tai padidėja tikimybė,
kad, darant pakeitimus viename komponente, jie neturės
jokio poveikio kitiems komponentams.
• Komponentų sankiba išauga, jeigu jie naudojasi tomis
pačiomis duomenų struktūromis arba jeigu jie keičiasi
valdančiąja informacija.
• Sankiba mažinama decentralizuojant sistemos būseną,
pavyzdžiui, išskirstant ją po objektus ir keičiantis
informacija tik per gerai apibrėžtus interfeisus, geriausiai,
siunčiant pranešimus. 117
Sankiba
• Stipri sankiba
Module A A
Komponentas Module BB
Komponentas
Komponentas
Module C Komponentas
Module D
C D
Shared data
Bendri duomenys
area
11 tema 118
118
Sankiba
• Silpna sankiba
Komponentas
Module A A
A A’s data
duomenys
Komponentas
Module B B Komponentas
Module C C
B’s data
B duomenys C duomenys
C’s data
Module D D
Komponentas
D’s data
D duomenys
119
Sankiba ir paveldėjimas
• Objektinėse sistemose sankiba yra nedidelė, nes
sistemos būsena yra išskirstyta po objektus ir
objektai komunikuoja keisdamiesi pranešimais.
• Tačiau, objektinėse sistemose klasės yra
sukibusios su savo poklasiais. Keičiant klasės
atributus ar jos operacijas, tenka daryti
pakeitimus ir visose tos klasės poklasiuose. Visa
tai sužiūrėti yra pakankamai sudėtinga.
120
Projekto suprantamumas
• Projektinės dokumentacijos suprantamumas priklauso nuo
keleto dalykų
– Komponentų rišlumo. Kiek paprasta perprasti kiekvieną iš
komponentų?
– Komponentų pavadinimų. Ar jie yra prasmingi?
– Dokumentacijos išsamumo. Ar projektavimo sprendimai
pakankamai gerai dokumentuoti?
– Sudėtingumo. Kiek sudėtingi algoritmai įgyvendinami sistemoje?
• Kalbant neformaliai, esant dideliam sistemos sudėtingumui,
sunku yra perprasti sistemos komponentų sąryšius.
• Daugumas projektavimo kokybės matų yra skirti
sudėtingumui matuoti. Tokių matų naudingumas yra gana
ribotas.
121
Projekto adaptuojamumas
• Projektas yra nesunkiai adaptuojamas, jeigu:
– sistemos komponentai yra silpnai sukibę;
– projektavimo rezultatai yra išsamiai dokumentuoti ir
dokumentacija nėra pasenusi;
– projektinės dokumentacijos lygmenys surišti
tarpusavyje (trasos);
– visi komponentai yra pakankamai rišlūs.
• Adaptuojant projektą, jis yra keičiamas, todėl
reikia išanalizuoti kiekvieno pakeitimo pasekmes.
Čia labai padeda trasavimo matricos.
122
Adaptuojamumas ir
paveldėjimas
• Paveldėjimas esminiai pagerina adaptuojamumą.
Komponentą galima adaptuoti jo nekeičiant, bet
vietoj to sukuriant atitinkamą poklasį, kuriame ir
padaromi reikiami pakeitimai.
• Tačiau, didėjant paveldėjimo hierarchijos lygmenų
skaičiui, auga ir jos sudėtingumas. Prisireikia ją
periodiškai peržiūrėti ir pertvarkyti.
123
Programavimas ir
derinimas
Programavimas ir
derinimas
• Programavimas apima projektinės
dokumentacijos transformavimą į programos
kodą ir toje programoje esančių klaidų
pašalinimą.
– Programavimas yra individuali veikla. Jokio bendro
programavimo proceso kol kas sukurta nėra.
– Programuotojas, siekdamas rasti klaidas programoje,
tą programą testuoja ir, derindamas programą,
pašalina rastas klaidas.
125
Programavimas ir
derinimas
• Derinimo procesas
Locate
Rasti Design
Ją Ją
Repair Pakartoti
Re-test
klaidą
error išanalizuoti
error repair ištaisyti
error testą
program
126
Testavimas
• Programų sistemos testavimas yra suprantamas kaip
tos sistemos vykdymas su tokiais duomenimis, su
kuriais galima patikrinti, ar sistema tenkina
reikalavimus, kuriuos ji turėtų tenkinti.
• Testavimo žingsniai
– Modulių testavimas: tikrinama ar visi baziniai sistemos moduliai tenkina jiems
suformuluotus reikalavimus..
– Agregatų testavimas: tikrinama ar sistemos agregatai (tampriai susijusių modulių
grupės) tenkina jiems suformuluotus reikalavimus.
– Posistemių testavimas: tikrinama ar sistemos posistemiai tenkina jiems
suformuluotus reikalavimus.
• Pagrindinis dėmesys skiriamas interfeisų testavimui.
– Sistemos testavimas: tikrinamos funkcinės ir nefunkcinės sistemos savybės
• atliekamas vykdytojo kaip vidiniai sistemos bandymai..
– Baigiamasis (acceptance) testavimas: atliekamas perduodant sistemą užsakovui
(baigiamųjų bandymų metu) pagal su užsakovu suderintą testavimo planą. 127
Testavimas
The
Testavimo
testingprocesas
process
Unit
Modulių
testavimas
testing
Module
Agregatų
testavimas
testing
Sub-system
Posistemių
testavimas
testing
System
Sistemos
testing
testavimas
Atlieka programuotojai Baigiamasis
Acceptance
testavimas
testing
Atliekama integruojant
Atliekama integruojant
Component sistemątesting
Integration Atliekama User
perduodant
sistemą
testing sistemątesting
užsakovui
128
Testavimas
• Testavimo procesas
Requirements
Reikalavimų System
Koncepcinis System
Eskizinis Detailed
Detalusis
specification
specifikacija specification
projektas design
projektas design
projektas
Sistemos
System Posistemių
Sub-system Moduliųand
Module ir
Galutinio
Acceptance testavimo testavimo
testavimo integration integration agregatų
unit code
test plan planas planas testai
planas test plan test plan and tess
Perdavimo
Service Perdavimo
Acceptance Sistemos
System Posistemių
Sub-system
protokolas testai
test testai test
integration testai test
integration
129
Testavimas
• Reikalavimai ir testavimas
Reikalavimų Reikalavimų Reikalavimų

Vartotojų
formulavimas lokalizavimas įgyvendinimas
poreikiai
Reikalavimų Sistemos
formulavimo procesas projektavimas
yra iteratyvus,
apimantis visus
sistemos
hierarchijos lygmenis
Reikalavimų Programų
testavimas rašymas
130
Testavimas
• Reikalavimai ir testavimas
Vartotojų Funkciniai
reikalavimai Projektas
poreikiai
Tenkina Tenkina
Tikrina
Tikrina
Tikrina
Standartai
Perdavimo Funkciniai Komponentų

testai testai testai 131
Testavimas
• Padengimas testais
001 SF Patikrinta 1 testu
002 SF Patikrinta daugiau nei 1 testu
001 SP Patikrinta 1 testu

Test A
001 SA Patikrinta 1 testu
Test B
001 SI Patikrinta daugiau nei 1 testu
001 SN Nepatikrinta - PROBLEMA
132
Įgyvendinimo aspektai
13
• PSI apima visus PS kūrimo etapus, pradedant
nuo vartotojo poreikių ir sistemos reikalavimų
nustatymo ir baigiant, sistemos palaikymu ir
sukurtos sistemos valdymu.
• Kritinis etapas yra sistemos įgyvendinimas, kai
sukuriama vykdomoji sistemos versija.
• Įgyvendinimas gali apimti programavimą,
naudojant aukšto ir žemo lygmens kalbas,
surinkimą ir adaptavimą, atsižvelgiant į tam tikrus
reikalavimus.
134
• Išskiriami tokie aspektai:
1. Pakartotinis panaudojimas – daugelis šiuolaikinių PS
surenkamos iš jau egzistuojančių komponentų (bent iš
dalies). Todėl, kuriant PS, patariama išsiaiškinti kas yra jau
sukurta ir tai per-panaudoti.
2. Konfigūracijos valdymas – PS kūrimo metu sukuriama
daug skirtingų PS komponentų versijų. Todėl reikia užtikrinti
versijavimo procesą ir sekti versijų kūrimą, kitaip gali atsitikti
taip, kad į galutinę PS versiją įdėsite ne tą komponento
versiją.
3. Host-target development – sukurta PS dažniausiai veikia
ne toje aplinkoje , kurioje buvo sukurta (the host system), o
svetimoje aplinkoje (the target system). Kartais tos aplinkos
visiškai skiriasi. 135
Įgyvendinimo aspektai:
Atviro kodo kūrimas
• Atviro kodo kūrimas (angl. Open source
development) – tai būdas, naudojant kurį,
sukurtas PS kodas yra paskelbiamas laisvai ir
norintieji gali juo naudotis ir jį tobulinti
(Raymond, 2001).
• Šios idėjos pagrindas Free Software Foundation
(http://www.fsf.org), kuri propaguoja, kad kodas
turi būti viešais prieinamas tolimesniam
naudojimui ir tobulinimui.
136
Atviro kodo kūrimas 1
• Geriausia žinoma atviro kodo sistema yra Linux
operacinė sistema.
• Kiti atviro kodo produktai yra Java, Apache web
serveris ir mySQL DBVS.
• Kt.
137
138
139
140
Klausimai?
Atviro kodo licencija
• Atviro kodo principas dar nereiškia, kad kodą gali naudoti bet kas ir
bet kaip.
• Atviro kodo licencijavimas grindžiamas tokio tipo pagrindiniais
modeliais:
1. The GNU General Public License (GPL) – jeigu kūrėjas naudoji
atvirą kodą pagal šią licenciją, kūrėjas privalo taip pat viešai
paskelbti savo sukurtą kodą.
2. The GNU Lesser General Public License (LGPL) – tai tam tikras
GPL atvejis, kai kūrėjas neprivalo viešai paskelbti savo sukurtus
komponentus. Tačiau jeigu modifikuojami atviro kodo
komponentai, juos kūrėjas privalo paskelbti.
3. The Berkley Standard Distribution (BSD) License – kūrėjas
neprivalo skelbti savo modifikacijų ir sukurto kodo. Sukurtą kodą
galima įtraukti į sistemas, kurios vėliau bus parduodamos. 141
Gyvavimo ciklo modeliai
Gyvavimo ciklo
modeliai
• Programų sistemos kūrimo procesas nėra
vientisas, jis skaidomas į viena po kitos tam tikra
nustatyta tvarka vykdomas stadijas.
• Šis procesas apima ne tik programų kodo rašymą,
bet ir tikslų bei reikalavimų formulavimą,
projektavimą ir sukurtos sistemos aprobavimą.
143
Gyvavimo ciklo
modeliai
• Istoriniu požiūriu programų sistemų inžinerija yra
labai jauna profesija.
– Pirmoji oficiali programuotoja buvo Grace Hopper,
programavusi JAV kariniam jūrų laivynui nuo 1940 m.
vidurio.
– Realios verslui skirtos programos pasirodė tik apie
1960 m.
– Visi to meto darbai buvo amatininkiško pobūdžio ir
buvo kuriami vadovaujantis vien tik programuotojų
intuicija.
– Deja, tik labai nedidelis programuotojų skaičius gali
pasigirti gera intuicija. 144
Gyvavimo ciklo
modeliai
• Apie 1968 m. tapo akivaizdu, kad būtina griežtesnė darbo
disciplina.
• Buvo pradėti kurti pirmieji programų sistemų inžinerijos
metodai.
• To pasėkoje buvo suvokti programų sistemų kūrimo proceso
apimtis ir sudėtingumas.
• Tapo aišku, kad reikia susisteminti sistemų kūrimo procesą,
t.y. kad reikalingos sistemų kūrimo metodikos.
• Tai ir yra programų sistemų gyvavimo ciklo (PSGC) modeliai.
• PSGC – tai sistema (metodinė), skirta programų sistemoms
kurti ir prižiūrėti.
145
Gyvavimo ciklo
modeliai
• Programų sistemos kūrimo procesas paprastai
apima tokias veikas:
– Kompiuterizuojamo verslo sistema yra analizuojama ir
atskleidžiami jos trūkumai
• tradiciškai tai daroma imant interviu iš dalykinės srities
specialistų, bet mes aptarėme ir kitus, daug objektyvesnius
metodus.
– Formuluojami kuriamos sistemos reikalavimai
• jie turi būti tokie, kad sistema padėtų pašalinti nustatytus
verslo sistemos trūkumus.
146
Gyvavimo ciklo
modeliai
apima tokias veikas (tęsinys):
– Programų sistemos projektavimas
• Be kita ko, numatoma su koki technine įranga ir su kokia
operacine sistema dirbs kuriamoji programų sistema, kaip ji
veiks kompiuterių tinkluose, kokiomis programavimo kalbomis
bus programuojama ir kaip bus apsaugota nuo neteisėto
naudojimo.
– Programų sistemos sukūrimas ir jos diegimas.
• Sukuriami ir instaliuojami visi sistemos komponentai.
• Apmokomi sistemos vartotojai.
• Sprendžiant su sistema realius uždavinius, yra įvertinami jos
patikimumas ir našumas.
• Jei reikia, atliekami sistemos pataisymai.
147
Gyvavimo ciklo
modeliai
apima tokias veikas (tęsinys):
– Programų sistemos perdavimas eksploatacijai.
• Tai gali būti atlikta įvairiais būdais
– Palaipsniui, viena po kitos, rankinės darbo
procedūros keičiamos kompiuterizuotomis.
– Jei sistema keičia seną programų sistemą, jai
palaipsniui perduodamos tos sistemos funkcijos.
– Kartais gali būti pigiau “vienu ypu” seną sistemą
pakeisti nauja.
148
Gyvavimo ciklo
modeliai
apima tokias sveikas (tęsinys):
– Pradėjus sistemą eksploatuoti, ją reikia nuolat stebėti
bei vertinti ir galbūt papildyti ar keisti. Tai vadinama
programų sistemos priežiūra (maintenance)
• Visi sistemos vartotojai turi būti laiku informuoti apie visus
padarytus pakeitimus.
• Programų sistemos aptarnavimas ir jos priežiūra yra visiškai
skirtingi dalykai.
149
Gyvavimo ciklo
modeliai
• PSGCM buvo sukurti, siekiant struktūrizuoti visą
programų sistemų kūrimo procesą (nuo verslo
analizės iki sistemos diegimo ir priežiūros),
padaryti jį lengviau valdomą ir geriau
prognozuojamą.
• Yra sukurta daug skirtingų PSGCM.
150
Gyvavimo ciklo
modeliai
151
Gyvavimo ciklo
modeliai
• Krioklio (klasikinis) modelis
• Spiralinis modelis
• V modelis
• Iteratyvus arba pažangus kūrimas
• Agilusis kūrimas
• RAD
• Koduok ir atiduok
• Formalūs metodai
152
Gyvavimo ciklo
modeliai
“Krioklio” modelis (waterfall model)
• Jis dar vadinamas klasikiniu PSGCM. Grindžiamas
“iš viršaus žemyn” PS kūrimo paradigma. Proceso
stadijos (jų gali būti skirtingas skaičius)
vykdomos nuosekliai viena po kitos.
• Modelis pasiskolintas iš automobilių pramonės.
Šiuo metu plačiai naudojamas ir karinėje bei
kosmoso industrijoje.
• Geras vadybiniu požiūriu, nes nėra nei
persidengiančių, nei lygiagrečiai vykdomų stadijų.
153
154
Reikalavimų
formulavimas
Projektavimas
Programavimas
Integravimas ir
testavimas
Tipinės “krioklio” modelio stadijos

Gyvavimo ciklo
modeliai
Reikalavimų
Requirements
formulavimas
definition “Krioklio” modelio
pavyzdys
System and
Sistemos
software design
projektavimas
Programavimas ir
Implementation
modulių
and unit testing
testavimas
Integravimas
Integration andir
sistemos
system testing
testavimas
Aptarnavimas
Operation and
ir priežiūra
maintenance
155
Gyvavimo ciklo
modeliai
“Krioklio” modelis
• Tipinės stadijos:
– Poreikių analizė ir reikalavimų formulavimas.
– Programų sistemos projektavimas.
– Programavimas ir modulių testavimas.
– Modulių integravimas ir sistemos testavimas.
– Sistemos naudojimas, aptarnavimas ir priežiūra.
• Pagrindinis modelio trūkumas yra tas, kad
vėlesnėse stadijose paaiškėjus anksčiau
padarytoms klaidoms, tas klaidas yra labai sunku
ištaisyti. 156
Gyvavimo ciklo
modeliai
• Kitos modelio problemos:
– Nuoseklus stadijų vykdymas
• Pasidaro labai sunku atsižvelgti į pasikeitusius vartotojo
reikalavimus.
– Dirbtinis reikalavimų formulavimo atskyrimas nuo
projektavimo.
– Nenumato prototipų, pakartotinai panaudojamų
komponentų ir pan.
– Nėra lygiagrečiai vykdomų stadijų (darbai ilgai
užtrunka).
• Modelis geriausiai tinka tuomet, kuomet 157
reikalavimai yra gerai žinomi ir nekinta.
Gyvavimo ciklo
modeliai
Kas vyksta gyvenime
11 tema 158
158
Gyvavimo ciklo
modeliai
• “Krioklio” modelis
159
Gyvavimo ciklo
modeliai
• “Krioklio” modelis
160
Gyvavimo ciklo
modeliai
Spiralinis modelis
• Šis modelis kombinuoja “krioklio” modelio ir
prototipų panaudojimo metodikas.
• Spiralinis modelis rekomenduotinas dideliems,
brangiems ir sudėtingiems projektams.
161
Gyvavimo ciklo
modeliai
Spiralinis modelis
• Šiuo atveju procesas yra spiralinio, o ne
nuoseklaus (viena po kitos vykdomos veiklos)
pobūdžio.
– Spiralės vingiai atitinka proceso stadijas.
• Modelis neturi fiksuotų stadijų, jos parenkamos
kiekvienam projektui, priklausomai nuo jo
poreikių.
• Į modelį išreikštiniu būdu yra įvesti rizikos
analizės ir eliminavimo veiksmai.
162
Gyvavimo ciklo
modeliai
Tikslų, alternatyvų Alternatyvų vertinimas,
Determine objectives
ir ribojimų
alternatives and rizikos alternatives
Evaluate veiksnių analizė
identify, resolve risks
nustatymas
constraints Rizikos
Risk ir šalinimas
analizė
analysis
Rizikos
Risk
analizė
analysis
Rizikos
Risk
analizė
analysis 3 Opera-
Opera-
Prototype 3 cinis
tional
2 prototipas proto-
Prototype
prototipas2 protoype
Rizikos
Risk tipas
1 proto-
analizė Proto-
analysis
APŽVALGA
REVIEW tipas
type 1
Analizės planavimas
Requirements plan Imitavimas,
Simulations, modeliavimas,
models, benchmarks
PSGCM konstravimas
Life-cycle plan atestavimas
Poreikiųof
Concept
specifikacija Reikalavimų
Operation S/W Eskizinis
formulavimas
requirements Product
projekta- Detalus
Detailed
design
vimas projekta-
Reikalavimų
Requirement design
vimas
Kūrimo
Development
planas
plan vertinimas
validation Kodavimas
Code
Modulių
Unit test
Integrationir Projekto
Design testavimas
Integravimo vertinimas
testavimo planai V&V Integravimo
Integration
Kitos stadijos
Plan next phase
and test plan
testavimas
test
planavimas Acceptance
Baigiamieji Produkto
Paslaugos bandymai
Service test Develop, verifyir
kūrimas
next-level product
vertinimas
163
Gyvavimo ciklo
modeliai
Spiralinio modelio sektoriai (stadijų etapai)
• Tikslų, alternatyvų ir ribojimų nustatymas
– Definuojami einamosios stadijos tikslai, jų
įgyvendinimo alternatyvos ir ribojimai.
• Rizikos vertinimas ir eliminavimas
– Analizuojami rizikos veiksniai ir numatomos priemonės
rizikai sumažinti.
• Kūrimas ir vertinimas
– Gali būti parinktas bet kuris universalus PSGCM.
• Planavimas
– Atliekama stadijos rezultatų peržiūra ir planuojama kita
stadija (t.y. naujas spiralės vingis).
164
Gyvavimo ciklo
modeliai
165
Gyvavimo ciklo
modeliai
166
Gyvavimo ciklo
modeliai
V modelis
• Šį modelį 1986 m. sukūrė Vokietijos gynybos
ministerija, nuo 1991 m. Vokietijos standartas,
iš esmės peržiūrėtas ir patobulintas 2004 m.
• Modelio ypatumai:
– Sistemos kūrimas vyksta iš viršaus žemyn, o
verifikavimas ir vertinimas (apimant testavimą) – iš
apačios į viršų. Testuojami moduliai, atitikimas
architektūros reikalavimams, atitikimas sistemos
specifikacijai ir atitikimas vartotojo reikalavimams.
– Baigiamuosius bandymus vykdo užsakovas.
167
Gyvavimo ciklo
modeliai
V modelis
• Modelio ypatumai:
– Jei kuriame nors verifikavimo ir vertinimo etape
aptinkamos klaidos, joms ištaisyti kartojami atitinkami
sistemos kūrimo etapai.
– Skirtingai nuo krioklio modelio, dėmesys yra sutelktas
ne į kuriamus artifaktus, bet į veiklas ir jų
korektiškumą.
168
Gyvavimo ciklo
modeliai
• V modelis
tenkina Veikianti
Reikalavimai
sistema
Analizė Diegimas
tenkina Patikrinta
Specifikacija sistema
Projektavimas Integravimas
Patikrinti
Architektūra posistemiai
Realizavimas Testavimas
Kodas
169
Gyvavimo ciklo
modeliai
• V modelis
170
Gyvavimo ciklo
modeliai
• V modelis Configuration Management
– Standartizavimo Quality Assurance

lygmenys System Development
Project Management
Procedure
Methods
Tool Requirements
11 tema
171
Gyvavimo ciklo
modeliai
Moderniosios metodikos
• Moderniosiose PSGCM ypatingas dėmesys skiriamas
iteraciniams procesas ir rizikos valdymo problemoms.
– Pradiniai sistemos reikalavimai VISUOMET evoliucionuoja ir kinta
projekto eigoje, todėl didesniuose projektuose pradinių stadijų
rezultatus visuomet tenka vienaip ar kitaip perdirbinėti. Būtent
todėl ypatingas dėmesys yra skiriamas iteraciniams procesams.
– Iteraciniais gali būti visi modelio numatyti procesai.
• Du populiariausi (tarpusavyje susiję) PSGCM yra:
– evoliucinis modelis (incremental development).
– spiralinis modelis.
172
Gyvavimo ciklo
modeliai
Evoliucinis modelis
• Dirbant pagal šią metodiką, užsakovui sistema pateikiama
ne iš karto, bet pateikiant jos branduolį ir prieaugius
(increments)
– Kitaip tariant, sistema pateikiama versijomis, kiekviena versija
papildant jos funkcionalumą naujomis funkcijomis. Pradinė versija
(branduolys) įgyvendina minimalų funkcionalumą, be kurio
vartotojas negali atlikti jokių prasmingų veiksmų
– Vartotojų poreikiai (o tuo pačiu ir sistemos reikalavimai) yra
suskirstomi į prieaugius atitinkančias grupes ir toms grupėms yra
priskiriami prioritetai.
– Pradėjus kurti naują prieaugį, jo reikalavimai yra įšaldomi
(nebekeičiami), bet, kuriant kitą prieaugį, jie vėl gali būti keičiami.
173
Gyvavimo ciklo
modeliai
Evoliucinis modelis
• Evoliucinis modelis dar yra vadinamas iteracinių prieaugių
modeliu.
• Jis grindžiamas evoliucinio PS kūrimo paradigma.
• Iš pirmo žvilgsnio gali pasirodyti, evoliucionuojantis
maketavimas ir evoliucinis modelis yra labai panašūs, bet
iš tiesų jie iš esmės skiriasi.
– Naudojant evoliucinio maketavimo metodiką, tarpinės sistemos
versijos esti funkciniai išsamios, bet neišbaigtos realizaciniu
požiūriu.
– Dirbant pagal evoliucinį PSGCM, tarpinės sistemos versijos yra
išbaigtos realizaciniu požiūriu, bet funkciniai neišsamios.
174
Gyvavimo ciklo
modeliai
• Evoliucinis modelis
Define outline
Reikalavimų Reikalavimų
Assign requirements DesignPSsystem
architektūros
requirements
formulavimas versijavimas
to increments architecture
projektavimas
Develop system
Prieaugio Valida te
Prieaugio Integrate
Prieaugio Sistemos
Valida te
increment
kūrimas testavimas
increment integravimas
increment testavimas
system
Eilinė
Final
sistemos
system
versija
Dar yraincomplete
System prieaugių
175
Gyvavimo ciklo
modeliai
Evoliucinis modelis
• Privalumai
– Su kiekvienu prieaugiu sukuriama ir pateikiama užsakovui
papildoma vertė, vartotojai gali pradėti dirbti su (funkciniu
požiūriu neišsamia) sistema daug anksčiau, negu
naudojant kitus PSGCM.
– Pradiniai prieaugiai gali būti panaudoti kaip maketai ir
padėti tikslinti sistemos reikalavimus.
– Sumažėja projekto žlugimo rizika.
– Vartotojų požiūriu svarbiausios paslaugos yra realizuojamos
pradiniuose prieaugiuose, kurie yra testuojami išsamiausiai
(pakartotinai testuojami pridėjus kiekvieną naują prieaugį).
176
Gyvavimo ciklo
modeliai
Evoliucinis modelis
• Ekstremalusis programavimas
– Tai populiari evoliucinio modelio panaudojimo
metodika.
– Jos esmė – kiek įmanoma mažesnės apimties
prieaugiai.
• Galima sakyti, kad tai yra kodo nuolatinio tobulinimo
metodika.
– Kiti ypatumai: aktyvus vartotojų dalyvavimas sistemos
projektavimo darbuose ir programavimas poromis
(pair-wise programming).
177
178

Gyvavimo ciklo
modeliai
11 tema 179
179
Gyvavimo ciklo
modeliai
Prototipus naudojantis modelis
• Šis modelis numato prototipų (grubių būsimos
sistemos aproksimacijų) konstravimą, testavimą ir
perdirbimą, žingsnis po žingsnio artėjant prie
galutinės sistemos versijos.
• Modelis grindžiamas iteracine programų sistemų
kūrimo paradigma.
180
Gyvavimo ciklo
modeliai
• Kas vadinama prototipu?
– pradinė programų sistemos versija, demonstruojanti
kokius nors jos dalykinius (dažniausiai, interfeiso) ar
projektinius ypatumus.
181
Gyvavimo ciklo
modeliai
• Maketavimas (išmetamų prototipų
naudojimas)
– Maketai kuriami, siekiant išsiaiškinti sistemos
reikalavimus
• Pradedama nuo menkai perprastų reikalavimų.
• Konstruojamas tuos reikalavimus demonstruojantis maketas.
• Užsakovas pareiškia savo pastabas.
• Maketas patikslinamas.
Tai kartojasi iki tol, kol užsakovas nebeturi pastabų.
– Tinkamas tuomet, kuomet:
• sunku suformuluoti tikslius reikalavimus (dažniausiai,
182
interfeiso).
Gyvavimo ciklo
modeliai
Evoliucinis modelis
• Tiriamasis (exploratory) maketavimas
– Dirbama kartu su būsimaisiais vartotojais. Maketas
imituoja išorinę sistemos elgseną, modeliuoja visų jo
funkcijų vykdymą, bet nei viena iš funkcijų iš tiesų nėra
realizuota. Maketo bandymai atliekami kartu su
vartotojais, bandymų rezultatai analizuojami irgi kartu.
Tikslas – aprobuoti funkcinius sistemos reikalavimus ir
vartotojo interfeiso reikalavimus. Maketas keičiamas
tol, kol vartotojai pripažins, kad jis veikia taip, kaip
turėtų veikti būsimoji programų sistema. .
183
Gyvavimo ciklo
modeliai
• Tiriamasis (exploratory) maketavimas
– Dirbdami su maketu, vartotojai pamažu suvokia, kokios
priemonės jiems iš tiesų reikia jų kasdieniniam darbui
patobulinti.
– Taip žingsnis po žingsnio tikslinami kuriamosios
sistemos reikalavimai.
• Pradedama nuo geriausiai perprastų ir mažiausiai ginčų
sukeliančių reikalavimų.
• Į kiekvieną naują maketo versiją pridedama tai, kas užsakovo
nuomone yra labiausiai reikalinga.
184
Gyvavimo ciklo
modeliai
• Evoliucionuojantis maketavimas
(evoliucionary development)
– Šiuo atveju maketas nėra išmetamas, bet traktuojamas
kaip būsimosios sistemos prototipas. Maketai (tiksliau,
funkcijų realizacija) tikslinami žingsnis po žingsnio ir
šitaip artėjama prie galutinio sistemos varianto.
– Kaip ir tiriamojo maketavimo atveju, kiekvienas naujas
maketas vis labiau artėja prie galutinio varianto ne tik
realizavimo išbaigtumo, bet ir funkciniu požiūriu.
– Naudojant evoliucinio maketavimo metodiką, galima
tikslinti ir nefunkcinius (našumo, patikimumo ir kt.)
sistemos reikalavimus.
185
Gyvavimo ciklo
modeliai
• Evoliucionuojantis maketavimas
Concurrent
Lygiagrečios
activities
veiklos
Initial
Pradinis
Specifikacija
Specification
version
maketas
Outline
Pradiniai Kūrimas Intermediate
Tarpiniai
Development
description
reikalavimai versions
maketai
Programų
Final
Vertinimas
Validation
sistema
version
11 tema 186
186
Gyvavimo ciklo
modeliai
11 tema 187
187
Gyvavimo ciklo
modeliai
11 tema 188
188
Gyvavimo ciklo
modeliai
Evoliucionuojantis maketavimas
• Problemos
– Neskaidrus procesas (stadijos persipina).
– Dažnai sistema gaunasi prastai struktūrizuota.
– Programuotojai turi turėti specialius įgūdžius (pvz.,
mokėti naudotis prototipų kūrimo priemonėmis).
• Tinkamumas
– Mažoms ir vidutinio dydžio interaktyvioms sistemoms.
– Didelių sistemų komponentams (pvz., vartotojo
interfeisui).
– Trumpai gyvuojančioms sistemoms. 189
Gyvavimo ciklo
modeliai
Komponentinis modelis (reuse-oriented)
• Grindžiamas komponentine PS kūrimo paradigma.
Sistema renkama iš gatavų komponentų, paprastai,
įsigyjamų rinkoje (COTS: Commercial-off-the-shelf).
• Proceso stadijos:
– komponentų analizė;
– reikalavimų modifikavimas;
– sistemos projektavimas komponentų pagrindu;
– komponentų integravimas.
• Šis modelis darosi vis populiaresnis, bet praktinė jo
naudojimo patirtis vis dar yra nepakankama.
190
Gyvavimo ciklo
modeliai
• Komponentinis modelis
Requirements
Reikalavimų Komponentų
Component Requirements
Reikalavimų System design
Komponentinis
specification
specifikavimas analizė
analysis modification
keitimas with reuse
projektavimas
Development
Kūrimas ir System
Sistemos
and integration
integravimas validation
bandymai
Sommerville, 2000
191
Gyvavimo ciklo
modeliai
• Komponentinis modelis
192
Gyvavimo ciklo
modeliai
11 tema 193
193
Gyvavimo ciklo
modeliai
Grupinio kūrimo (joint application
development (JAD)) modelis
• Šis modelis numato užsakovų ir vartotojų
dalyvavimą projektavimo ir kituose sistemos
kūrimo procesuose.
• Tai padaroma sukuriant bendras darbo grupes ir
vykdant projektavimą tų grupių posėdžiuose (JAD
sessions).
194
Gyvavimo ciklo
modeliai
11 tema 195
195
Gyvavimo ciklo
modeliai
11 tema 196
196
Gyvavimo ciklo
modeliai
Modelis “sinchronizuok ir stabilizuok”
(synchronise-and-stabilise)
• Šis modelis numato, kad savarankiškos grupės
lygiagrečiai kuria skirtingus modulius, dažnai
derindami tarpusavyje tų modulių kodus ir
nuspręsdami įšaldyti (stabilizuoti) tam tikrus
projektavimo sprendimus.
197
Gyvavimo ciklo
modeliai
Grupių organizavimas ir sprendimų priėmimas

dirbant pagal sinchronizuok ir stabilizuok modelį
198
Įteratyvus arba pažangus
kūrimas
• Įteratyvus arba pažangus kūrimas numato, kad
PS kūrimas pradedamas nuo mažų porcijų, kurios
vis didinamos, kad visi įsitraukusieji aptiktų
problemas kuo greičiau ir jas ištaisytų.
• Įteratyvus arba pažangus kūrimas – tai
kombinacija įteratyvaus kūrimo ir pažangaus
kūrimo. Tai seniai žinomas PS kūrimo būdas
siūlomas didelioms PS kurti.
199
kūrimas
• For example, the 1985 DOD-STD-2167 mentions (in section
4.1.2): "During software development, more than one iteration
of the software development cycle may be in progress at the
same time." and "This process may be described as an
'evolutionary acquisition' or 'incremental build' approach."
• Ryšys tarp įteracijų ir pažangos nurodomas per visą PS kūrimo
metodiką ir PS kūrimo ciklą. Konkretus prieaugių skaičius ir
iteracijų skaičius priklauso nuo projekto.
• Įteratyvus arba pažangus kūrimas yra įtrauktas į modifikuotą
krioklio modelį, RUP‘ą, Ekstremalųjį programavimą ir kitas
agiliasias metodikas.
• Jis yra panašus į the plan-do-check-act (Demingo) ciklą,
naudojamą verslo procesui tobulinti.
200
kūrimas
• Įteratyvaus arba pažangaus kūrimo modelis.
201
AGILUSIS PS KŪRIMAS
Agilusis kūrimas
• Agilusis PS kūrimas grindžiamas įteratyviuoju
kūrimu, bet čia akcentuojamas lengvesnis ir
labiau į žmones nukreiptas požiūris, negu
tradicinėse PS kūrimo metodikose.
• Agilusis procesas įtraukia įteracijas ir nuolatinį
grįžtamąjį ryšį, tam kad užtikrinti sėkmingą PS
patikslinimą ir pristatymą laiku.
203
Agilusis kūrimas
• There are many variations of agile processes:
• Well-known agile software development methods and/or process
frameworks include:
– Adaptive Software Development (ASD)
– Agile Modeling
– Agile Unified Process (AUP)
– Crystal Methods (Crystal Clear)
– Disciplined Agile Delivery
– Dynamic Systems Development Method (DSDM)
– Extreme Programming (XP)
– Feature Driven Development (FDD)
– Lean software development
– Scrum
– Scrum-ban
204
Agilusis kūrimas
• Extreme Programming (XP) is a software development methodology which is
intended to improve software quality and responsiveness to changing customer
requirements. As a type of agile software development,[1][2][3] it advocates frequent
"releases" in short development cycles, which is intended to improve productivity and
introduce checkpoints at which new customer requirements can be adopted.
• Other elements of Extreme Programming include: programming in pairs or doing
extensive code review, unit testing of all code, avoiding programming of features until
they are actually needed, a flat management structure, simplicity and clarity in code,
expecting changes in the customer's requirements as time passes and the problem is
better understood, and frequent communication with the customer and among
programmers.[2][3][4] The methodology takes its name from the idea that the beneficial
elements of traditional software engineering practices are taken to "extreme" levels. As
an example, code reviews are considered a beneficial practice; taken to the extreme,
code can be reviewed continuously, i.e. the practice of pair programming.
• Critics have noted several potential drawbacks,[5] including problems with unstable
requirements, no documented compromises of user conflicts, and a lack of an overall
design specification or document.
205
Agilusis kūrimas
• Extreme Programming (XP)
206
Agilusis kūrimas
• Dynamic systems development method (DSDM) is an agile project delivery
framework, primarily used as a software development method. First released in 1994,
DSDM originally sought to provide some discipline to the rapid application development
(RAD) method. In 2007 DSDM became a generic approach to project management and
solution delivery. DSDM is an iterative and incremental approach that embraces
principles of Agile development, including continuous user/customer involvement.
• DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of
scope into musts, shoulds, coulds and won't haves to adjust the project deliverable to
meet the stated time constraint. DSDM is one of a number of Agile methods for
developing software and non-IT solutions, and it forms a part of the Agile Alliance.
• The most recent version of DSDM, launched in 2007, is called DSDM Atern. The name
Atern is a shortening of Arctic Tern - a collaborative bird[citation needed] that can travel vast
distances and epitomises many facets of the method which are natural ways of
working e.g. prioritisation and collaboration.
• The previous version of DSDM (released in May 2003) which is still widely used and is
still valid is DSDM 4.2 which is a slightly extended version of DSDM version 4. The
extended version contains guidance on how to use DSDM with Extreme Programming.
207
Agilusis kūrimas
208
Agilusis kūrimas
• Scrum is an iterative and incremental Agile software development
framework for managing software projects and product or application
development. It defines "a flexible, holistic product development strategy
where a development team works as a unit to reach a common goal." It
challenges assumptions of the "traditional, sequential approach" to product
development. Scrum enables teams to self-organize by encouraging physical
co-location of all team members and daily face to face communication among
all team members and disciplines in the project.
• A key principle of Scrum is its recognition that during a project the customers
can change their minds about what they want and need (often called
requirements churn), and that unpredicted challenges cannot be easily
addressed in a traditional predictive or planned manner. As such, Scrum
adopts an empirical approach—accepting that the problem cannot be fully
understood or defined, focusing instead on maximizing the team's ability to
deliver quickly and respond to emerging requirements
209
Agilusis kūrimas
• The SCRUM process
210
Gyvavimo ciklo
modeliai
Greito kūrimo (rapid application
development (RAD)) modelis
• Modelis daro prielaidą, kad kūrimo procesą
galima pagreitinti:
– panaudojant fokuso grupes;
– panaudojant prototipus ir tipinius projektavimo
sprendimus;
– griežtai prisilaikant suplanuotų terminų;
– mažiau formalizuojant darbo procedūras.
211
Gyvavimo ciklo
modeliai
• Greito kūrimo (rapid application
development (RAD)) modelis
212
Gyvavimo ciklo
modeliai
• Greito kūrimo modelis
213
214

Greito
kūrimo
modelis
Gyvavimo ciklo
modeliai
215
Gyvavimo ciklo
modeliai
216
Gyvavimo ciklo
modeliai
• Greito kūrimo modelis: instrumentinė aplinka
Code Generators & Output Code
Compilers Communications
Protocols / Transports
UML Programming
Language
Operating
System
GUI Platform
Graphics Libraries
MICO
Compatibility with
IDL MGV and SoS
COE Frameworks
217
Gyvavimo ciklo
modeliai
Modelis “Koduok ir atiduok” (Code & Fix
model)
• Istoriškai susiklostęs pats pirmasis darbo būdas
– Rašomas kodas; atiduodamas užsakovui.
– Jokios analizės ir jokio projektavimo.
• Problemos:
– Kodas netinkamai struktūrizuotas (nebuvo
projektavimo).
– Sistema prastai tenkina vartotojų operacinius poreikius
(neatlikta dalykinės srities analizė).
218
Gyvavimo ciklo
modeliai
219
Gyvavimo ciklo
modeliai
Modelis “Koduok ir atiduok”
• Procesas nesuskaidytas į žingsnius
– nėra reikalavimų specifikacijos, projekto, testavimo ir
t.t.
– nelieka jokių dokumentų, kuriais būtų galima
pasinaudoti vėliau darant pakeitimus programose.
• Neatskirti turiniai
– neįmanomas grupinis darbas,
– visa programa supinta į vieną kamuolį.
220
Gyvavimo ciklo
modeliai
Modelis “Koduok ir atiduok”
• Nėra būdų sumažinti sudėtingumą
– šitaip galima parašyti 100, galbūt, 1000 eilučių
programą,
– jokios normalaus dydžio programų sistemos šitaip
nesukursi.
221
Gyvavimo ciklo
modeliai
Formalaus PS kūrimo modelis (dar vadinamas
Balcerio transformaciniu modeliu)
• Grindžiamas sintezės paradigma
– t.y. pažingsnis matematinės sistemos specifikacijos
transformavimas į veikiančią sistemą.
• Transformacijos yra tokios, kad jos išsaugo
teisingumą, dėl ko atpuola būtinybė tikrinti ar
sistema tenkina reikalavimų specifikaciją
• Šiuo modeliu grindžiama ‘Cleanroom’ metodika
PS kurti
• Clean Room = Elektronikos inžinerijoje naudojamų inžinerinių
metodų pritaikymas PS inžinerijai.
222
Gyvavimo ciklo
modeliai
• Formalaus PS kūrimo modelis
Sistemosand
Integration
Reikalavimų
Requirements Specifikacijos
Formal Formalios
Formal
integravimas
formulavimas
definition formalizavimas
specification transformacijos
transformation system testing
ir testavimas
11 tema 223
223
Gyvavimo ciklo
modeliai
• Formalaus PS kūrimo modelis
Formalios
Formaltransformacijos
transformations
T1 T2 T3 T4
Formal
Formali Programos
Executable
R1 R2 R3
specification
specifikacija kodas
program
P1 P2 P3 P4
Proofs of transformation
Transformacijų correctness
korektiškumo įrodymas
Sommerville, 2000
224
Gyvavimo ciklo
modeliai
Formalaus PS kūrimo modelis
• Problemos
– Reikalingi aukštos kvalifikacijos specialistai, turintys
specialius įgūdžius.
– Kai kuriuos sistemos aspektus, pavyzdžiui, vartotojo
interfeiso reikalavimus, sunku formaliai specifikuoti.
• Panaudojamumas
– Kritinės sistemos, ypač tokios, kurios kelia grėsmę
žmonių gyvybei.
225
Gyvavimo ciklo
modeliai
MD modelis (model driven development)
• Specialus formalaus PS kūrimo modelio atvejis.
– Bet kuri sistema kuriama 3 transformacijomis.
11 tema 226
226
Gyvavimo ciklo
modeliai
MD modelis (model driven
development)
• CIM (computatation-independent model):
Koncepcinio lygmens modelis, gautas iš koncepcinio
verslo modelio. Jame nėra atsižvelgiama nei į
sistemos architektūrą, nei į kompiuterinę platformą,
kurioje sistema veiks.
• PIM (platform-independent model): Atsižvelgia į
pasirinktą architektūrą, bet nesiejamas su jokia
kompiuterine platforma, t.y. projektuojamas virtualios
mašinos terminais.
• PSM (platform-specific model): Gaunamas
transformuojant virtualiąją mašiną į konkrečią
kompiuterinę platformą 11 tema 227
227
Gyvavimo ciklo
modeliai
11 tema 228
228
229
11 tema 229
RUP
Gyvavimo ciklo
modeliai
• RUP (Rational Unified Process)
11 tema 231
231
Gyvavimo ciklo
modeliai
RUP (Rational Unified Process)
• RUP – tai:
– Iteratyvus programų sistemų kūrimo paradigma,
kurioje visų pirma yra akcentuojama kuriamos
sistemos architektūra (architecture centric) ir kuri yra
grindžiamas užduočių modeliavimo filosofija (use-case
driven).
– Griežtai apibrėžtas ir gerai struktūrizuotas
technologinis procesas programų sistemoms kurti.
– Konkrečiam projektui nesunkiai adaptuojamas
komercinis produktas (dokumentacija, programinė
įranga), palaikantis šią paradigmą ir šį procesą.
232
Gyvavimo ciklo
modeliai
• Iteratyvaus kūrimo stadijos ir kontroliniai taškai
Pradžia (inception): Suprasti, kas bus kuriama (sistemos vizija,

viršutinio abstrakcijos lygmens reikalavimai, kompiuterizuojamos
verslo užduotys.
Detalizavimas (elaboration): Suprasti, kaip bus kuriama: bazinė
architektūra, detalizuoti reikalavimai, eskizinis projektavimas
(projektavimas stambiu planu).
Konstravimas (construction): Sistemos konstravimas
(programos, testai, testavimo rezultatai).
Perdavimas užsakovui (transition): Baigiamieji bandymai. 233
Gyvavimo ciklo
modeliai
• Stadijos ir iteracijos
Iteracija – tai savarankiška veiklų seka, kuriai yra sudarytas

darbo planas, nustatyti vertinimo kriterijai ir kuri baigiasi
veikiančios sistemos atmainos (executable release) sukūrimu.
234
Gyvavimo ciklo
modeliai
• Kiekviena iteracija vyksta pagal krioklio modelį
11 tema 235
235
Gyvavimo ciklo
modeliai
• Iteracijų testavimas
236
Gyvavimo ciklo
modeliai
• Architektūros aprašas
237
238
11 tema 238
239
239
240
11 tema 240
Gyvavimo ciklo
modeliai
• RUP gyvavimo ciklo modelis
241
Gyvavimo ciklo
modeliai
• RUP gyvavimo ciklo modelis
242
Gyvavimo ciklo
modeliai
Pagrindinės RUP sąvokos
11 tema 243
243
Gyvavimo ciklo
modeliai
• Technologinis procesas: vaidmuo, veiklos,
artefaktai
244
Gyvavimo ciklo
modeliai
• Technologinis procesas: instrukcijos, šablonai,
mokymo priemonės
245
Gyvavimo ciklo
modeliai
• RUP darbų srautas
246
Gyvavimo ciklo
modeliai
• Užduotys aprašo paslaugas, kurias sistema turi
teikti vartotojams. Kiekvienoje iteracijoje jos yra
naudojamos: planuojant darbus, kuriant ir
vertinant architektūrą, projektuojant testus ir
testavimo procedūras, projektuojant vartotojo
interfeisus ir rašant vartotojui skirtą
dokumentaciją.
247
Gyvavimo ciklo
modeliai
248
Gyvavimo ciklo
modeliai
249
Gyvavimo ciklo
modeliai
RUP (Rational Unified
Process)
250
Gyvavimo ciklo
modeliai
• RUP kaip produktas
11 tema 251
251
Gyvavimo ciklo
modeliai
• RUP kaip produkto įsigijimas
11 tema 252
252
Gyvavimo ciklo
modeliai
• RUP kaip produktas
11 tema 253
253
Gyvavimo ciklo
modeliai
•RUP kaip
produktas
11 tema 254
254
Gyvavimo ciklo
modeliai
Pasiteisinusi patirtis
• Kiekvienam projektui gyvavimo ciklo modelis turi
būti projektuojamas individuliai, pasinaudojant
mūsų aptartais tipiniais modeliais. Tai labai
svarbu, nes visa, kas vyksta procese, priklauso
nuo pasirinkto PSGCM.
– Projekto sėkmė didžiąja dalimi priklauso nuo to,
kiek skrupulingai buvo jam suprojektuotas PSGCM.
– Vienok, geriau pasinaudoti bet kuriuo modeliu,

negu dirbti be jokio PSGCM.
255
Gyvavimo ciklo
modeliai
Dažniausiai pasitaikančios klaidos
• Pasirinktas PSGCM nėra palaikomas atitinkamų
instrumentinių sistemų ir viskas susiveda tik į
“kas ką ir kada darys".
• Blogai dirbo technologas. Turimos instrumentinės
priemonės ir PSGCM nėra tinkamai susieti į vieną
visumą.
256
Gyvavimo ciklo
modeliai
PSGCM reikalavimai
• Išskiriamos penkios PSGCM reikalavimų
kategorijos:
– panaudojimo sritis;
– techniniai aspektai;
– vadybiniai aspektai;
– panaudojamumas;
– diegimas.
257
Gyvavimo ciklo
modeliai
PSGCM reikalavimai
• Panaudojimo srities reikalavimai nusako kokio
tipo sistemoms bei projektams pritaikytas
PSGCM.
• Techniniai ir vadybiniai reikalavimai nusako
PSGCM numatomų užduočių tipus ir proceso
kuriamų rezultatų (deliverables) tipus.
• Panaudojamumo reikalavimai nusako, kokiais
būdais projekto vykdytojai gali pasinaudoti
PSGCM ir ką reikia padaryti, kad tuo modeliu būtų
paprasčiau pasinaudoti.
• Diegimo reikalavimai nusako, ką reikia padaryti,258
diegiant PSGCM konkrečiame projekte.
259
Klausimai?
Klausimai
1. Kaip yra suprantamas programų sistemos skaidymas į dalis? (1)
2. Kas vadinama sistemos hierarchija? (1)
3. Kaip, projektuojant programų sistemą objektiškai, yra pasinaudojama koncepciniu
verslo modeliu (koncepciniu dalykinės srities modeliu)? (3)
4. Kas daroma PS koncepcinio projektavimo metu? (3)
5. Kuo skiriasi eskizinis PS projektavimas ir jos detalusis projektavimas? (2)
6. Kas vadinama PS architektūra? (2)
7. Papasakokite apie Coad & Yourdon architektūrą ir jos komponentus (5)
8. Kokius PS dekompozicijos būdus jūs žinote? (1)
9. Paaiškinkite PS funkcinės dekompozicijos esmę.(3)
10. Paaiškinkite PS objektinės dekompozicijos esmę. (3)
11 tema 260
260
Klausimai
11. Paaiškinkite objektinio nuoseklių patikslinimų metodo esmę. (4)
12. Paaiškinkite objektinio struktūrinio projektavimo metodo esmę. (4)
13. Paaiškinkite funkcinio ir objektinio projektavimo skirtumus (2)
14. Paaiškinkite paslaugomis grindžiamos dekompozicijos esmę (3)
15. Paaiškinkite užduotimis grindžiamos dekompozicijos esmę. (3)
16. Kuo skiriasi funkcinis projektavimas ir užduotimis grindžiamas projektavimas? (2)
17. Kas vadinama reikalavimų lokalizavimu? Kas tai yra lokalizavimo matrica? (2)
18. Kas vadinama reikalavimų nuleidimu žemyn? Kas tai yra reikalavimų ryšio matrica?? (3)
19. Kas vadinama reikalavimų trasuojamumu? Kas tai yra trasuojamumo matrica? (2)
20. Kokie interfeisai yra apibrėžiami, atliekant reikalavimų lokalizavimą ir nuleidimą žemyn? (2)
11 tema 261
261
Klausimai
21. Kokius reikalavimų verifikavimo ir vertinimo metodus jūs žinote? Trumpai apibūdinkite
kiekvieną iš jų. (3)
22. Pagal kokias charakteristikas vertinama projektavimo kokybė programų sistemos
prižiūrimumo požiūriu? (1)
23. Kas vadinama komponento (modulio) rišlumu? Kokius rišlumo lygmenis jūs žinote? (4)
24. Kas vadinama komponentų (modulių) sankiba? Kaip siejasi tarpusavyje sankiba ir
paveldėjimas? (3)
25. Paaiškinkite, kaip yra suprantamas terminas “projekto suprantamumas? (2)
26. Paaiškinkite, kaip yra suprantamas terminas “projekto adaptuojamumas”. Kaip siejasi
tarpusavyje adaptuojamumas ir paveldėjimas? (3)
27. Paaiškinkite, kuo skiriasi testavimas ir derinimas. (3)
28. Kokias testavimo stadijas jūs žinote? Trumpai apibūdinkite kiekvieną iš jų. (3)
29. Paaiškinkite, kaip yra susieti tarpusavyje programų sistemos reikalavimai ir jos testavimas.
(3)
30. Paaiškinkite, ką reiškia terminas “padengimas testais”. (3)
11 tema 262
262
Klausimai
31. Kaip suprantamas terminas “programų sistemos gyvavimo ciklo modelis”
(PSGCM)? Kokias veiklas paprastai apima PSGCM? (5)
32. Kokius programų sistemos gyvavimo ciklo modelius jūs žinote? (1)
33. Trumpai apibūdinkite programų sistemos gyvavimo ciklo modelio “Koduok
ir atiduok” esmę. (1)
34. Apibūdinkite “krioklio” modelio esmę. (5)
35. Kaip programų sistemos gyvavimo ciklo modeliuose yra panaudojami
prototipai? Kas vadinama prototipu? (3)
36. Kaip programų sistemos gyvavimo ciklo modeliuose yra panaudojami
išmetamieji prototipai (maketai)?(3)
37. Apibūdinkite tiriamojo ir evoliucinio maketavimo esmę. (5)
38. Trumpai apibūdinkite greito PS kūrimo modelio esmę. (1)
39. Trumpai apibūdinkite grupinio PS kūrimo modelio esmę. (1)
40. Trumpai apibūdinkite programų sistemos gyvavimo ciklo modelio
“Sinchronizuok ir stabilizuok” esmę. (1)
11 tema 263
263
Klausimai
41. Apibūdinkite evoliucinio programų sistemų gyvavimo ciklo modelio
esmę. Kas vadinama ekstremaliuoju programavimu? (4)
42. Apibūdinkite spiralinio programų sistemų gyvavimo ciklo modelio esmę.
(5)
43. Apibūdinkite formalaus programų sistemų kūrimo modelio esmę(5)
44. Apibūdinkite komponentinio PS kūrimo modelio esmę. (4)
45. Kokias programų sistemų gyvavimo ciklo modelio reikalavimų
kategorijas jūs žinote. Trumpai apibūdinkite kiekvieną kategoriją. (4)
11 tema 264
264
Life cycle Models
The waterfall model
11 tema 265
265

PSI 9 Projektavimas Testavimas 20151114 v01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PSI 9 Projektavimas Testavimas 20151114 v01

Uploaded by

Copyright:

Available Formats

Programų sistemų

Skaidrės ruoštos remianti prof. A.Čaplinsko medžiaga

Doc. dr. Diana Kalibatienė

1 posistemis 1 IRS 2 posistemis

•••• 1 komponentas 2 IRS 2 komponentas

3 IRS 1 mazgas 2 mazgas 3 mazgas

•••• 1 modulis 2 modulis 3 modulis ••••

Pateikti 1 hierarchijos lygmuo

Load R10 Add R1, R10 Mašininis lygmuo

Įmonės verslo sistemos

• Po to, kai sukuriami žemiausiojo lygmens

Kas dekomponuota Į ką dekomponuota

Lokalizuojami Nelokalizuojami Reikalavimai

Išvestiniai Tiesiogiai lokalizuojami

Sistemos 1 2 ... 1 IRS

•••• 1 komponentas 2 IRS 2 komponentas

3 IRS 1 mazgas 2 mazgas 3 mazgas

•••• 1 modulis 2 modulis 3 modulis ••••

Sistemos 1 2 ... 1 IRS

Reikalavimų Reikalavimų Reikalavimų

Perdavimo Funkciniai Komponentų

001 SF Patikrinta 1 testu

002 SF Patikrinta daugiau nei 1 testu

001 SP Patikrinta 1 testu

001 SN Nepatikrinta - PROBLEMA

Gyvavimo ciklo modeliai

Tipinės “krioklio” modelio stadijos

– Standartizavimo Quality Assurance

Gyvavimo ciklo modeliai

Grupių organizavimas ir sprendimų priėmimas

Gyvavimo ciklo modeliai

Gyvavimo ciklo modeliai

Pradžia (inception): Suprasti, kas bus kuriama (sistemos vizija,

Iteracija – tai savarankiška veiklų seka, kuriai yra sudarytas

Gyvavimo ciklo modeliai

Gyvavimo ciklo modeliai

Gyvavimo ciklo modeliai

Pagrindinės RUP sąvokos

– Vienok, geriau pasinaudoti bet kuriuo modeliu,

The waterfall model

You might also like