Towards Service-oriented Requirements Engineering Process

1. REIKALAVIMŲ INŽINERIJOS PROCESAS
SKIRTAS PASLAUGŲ REIKALAVIMAMS
(angl.TowardsService-orientedRequirementsEngineering
Process)
Sandra Svanidzaitė
Informatika (07 T), vadovas prof. dr. A.Čaplinskas
Vilniaus Universitetas, Matematikos ir informatikos institutas
Programų sistemų inžinerijos skyrius

2. Paslaugoms skirta paradigma
(SOA)
Paslaugoms skirta (angl. Service orientation) paradigma tai
nauja programų sistemų kūrimo paradigma siūlanti kurti ir
komponuoti sistemas iš nepriklausomų paslaugų (angl. services)
− Ši paradigma yra kilusi iš prieš tai vyravusių paradigmų tokių kaip:
− Objektinės paradigmos - OOP (angl. Object-oriented paradigm)
− Komponentinio programavimo - COP (angl. Component-oriented
programming )
− Atvirųjų išskirstytų skaičiavimų – ODP (angl. open distributed
processing )
Paslaugų stiliaus architektūra (angl. Service-oriented
architecture - SOA) tai paslaugų kūrimui skirtas architektūrinis
stilius. 2

3. Paradigmų evoliucija
3

4. Paslaugoms skirta reikalavimų
inžinerija (SoRE)
• SoRE kaip ir tradicinė reikalavimų inžinerija, susijusi su
sistemos reikalavimų analize ir specifikavimu, tačiau jos
dėmesys yra sutelktas į paslaugų, jų darbų sekų (angl.
workflow) identifikavimą ir modeliavimą bei jų
pakartotinio naudojimo galimybių analizę.
• Paslaugoms skirta programinės įrangos inžinerija - SoSE yra santykinai
nauja ir vis dar sparčiai auganti mokslinių tyrimų ir plėtros srityje. Ši
disciplina atsirado praėjusio amžiaus paskutiniame dešimtmetyje [24-
25], kaip atsakas į nevienalyčių programų (angl. heterogeneous
applications) įskaitant ir pasenusios, likutinės (angl. legacy) PĮ
integracijos iššūkius bei siekiant sumažinti atotrūkį tarp verslo modelių ir
PĮ architektūros.
• Savo pradiniuose etapuose SoRE daugiausiai buvo susikoncentravusi į į
paslaugoms skirtos programinės įrangos kūrimo procesą, atsižvelgiant į
jį, kaip į Rational Unified Process [26] arba į IBM Global Service [27]
metodų papildinį ir atnaujinimą.
4

5. Paslaugoms skirta reikalavimų
inžinerija (SoRE)
• SoRE kaip neatsiejama SoSE dalis atsirado pirmame XXI a. penkmetyje .
Pirmosios publikacijos šia tema diskutavo apie šios disciplinos
prigimtį, skirtumus tarp paslaugoms skirtos ir tradicinės reikalavimų
inžinerijos, reikalavimų gyvavimo ciklo struktūrą bei galimus metodus
funkcinių ir nefukcinių reikalavimų identifikavimui ir valdymui [28-29].
• Publikacijų skaičius skirtas šios reikalavimų inžinerijos atšakos būklės analizei buvo išties
didelis. Buvo stengiamasi pabrėžti atviras SoRE problemas bei iššūkius, numatyti veiksmų
planą, kuriuo remiantis būtų vykdomi moksliniai tyrimai.
• Dauguma tuometinių publikacijų šiandieną jau yra pasenę ir nebegali būti laikomos
patikimomis. Nei viena iš publikacijų neatlieka visuminės, pritaikytų paslaugoms sistemų
reikalavimų inžinerijos proceso analizės, nes koncentruojasi į tam tikrą SoRE aspektą [2-4]. Be
to nuo to laiko buvo pasiūlyta keletas paslaugoms pritaikytų sistemų kūrimo metodikų[9-
14], kurios nėra skirtos reikalavimų inžinerijai, tačiau niekados nebuvo analizuota kaip jos
galėtų pasitarnauti SoRE struktūrizavimui bei apibrėžimui.
• Pirmasis žingsnis siekiant pažangos šiuo klausimu yra atkreipti dėmesį į
pagrindines problemas ir iššūkius, su kuriais šiandien susiduria SoRE
išdėstant pagrindinius skirtumus tarp tradicinės reikalavimų
inžinerijos, komponentinės reikalavimų inžinerijos ir paslaugoms skirtos
reikalavimų inžinerijos.
5

6. Tradicinės reikalavimų inžinerijos
problematika
Bano ir Irkam [2] nurodo, kad tradicinė RE susiduria su tokiais iššūkiais
kaip:
• Išsūkiai susiję su susinteresuotomis šalimis (angl.Issues regarding
stakeholders) kai kiekviena suinteresuota šalis turi savitus sistemos
poreikius ir skirtingus požiūrius į ją.
• Funkcinių ir nefunkcinių reikalavimų identifikavimas, modeliavimas
ir analizė (angl. Capturing, Modeling and Analyzing Functional and
Non-Functional Requirements).
• Reikalavimų analizės modelių ir formaliaus reikalavimų
atvaizdavimo iš natūralios kalbos pakartotinis panaudojamumas
(angl. Ensuring Reuse of Requirement Models and Formal
Representation of Requirements from Natural Language).
• Reikalavimų pokyčiai/evoliucija ir konfliktų sprendimai (angl.
Requirement change/ evolution and Conflict resolution). Su šiais
iššūkiais yra susiduriama reikalavimų valdymo ir reikalavimų pokyčių
valdymo veiklų metu.
6

7. Komponentinės reikalavimų
inžinerijos problematika
• Komponentinių sistemų RE susiduria su tokiomis problemomis kaip:
• RE proceso nebuvimas, kuris spręstų komponentų paieškos ir atrankos
problemas
• Metodikų, kurios leistų apibrėžti nefunkcinius reikalavimus nebuvimas. Šios
metodikos ypatingai praverstų tuomet kai reiktų palyginti du komponentus
teikiančius tą patį funkcionalumą tačiau turinčius skirtingas kokybines
charakteristikas.
• Tradicinės RE metodai negali būti pritaikyti dar dėl šių priežasčių:
• Egzistuojančių komponentų specifikacijos turėtų būti vertinamos renkant
sistemos reikalavimus
• Reikalingas sistematinio vertinimo ir testavimo metodas, kuris leistų įvertinti
komponento atitikimą vartotojo reikalavimams
• Kadangi komponentai yra traktuojami kaip “juodosios dėžės” (angl. Black box)
pagal jų prigimtį ir paskirtį, pirminis programos tekstas (angl. Source code)
nėra pateikiamas. Tai sukelia problemų komponentų adaptavimo ir sistemos
integravimo metu.
• Komponentų versijavimas gali sukelti problemų, jeigu nauja komponento
versija neatitinka sistemos reikalavimų.
7

8. Paslaugoms skirtos reikalavimų
inžinerijos problematika
SoRE iššūkiai ir problematika yra tam tikru mastu paveldėti iš tradicinės ir
komponentinės RE. Išskiriami tokie pagrindiniai iššūkiai:
• RE technikų skirtų paslaugų suradimo problematikai (angl. Non-
existence of RE techniques for Service Discovery issues) spręsti
nebuvimas. Paslaugų suradimo galimybė yra viena iš svarbiausių į
paslaugas orientuotos paradigmos savybių, todėl efektyvūs paslaugų
suradimo mechanizmai pagal vartotojo reikalavimus yra būtini.
• Struktūrizuoto, iteratyvaus RE proceso nebuvimas. Šis procesas
reikalingas siekiant kurti ir atnaujinti reikalavimų specifikacijas bei
siekiant užtikrinti reikalavimų atsekamumą (angl. traceability) bei
reikalavimų pokyčių valdymą.
• RE technikų, kurios leistų perprojektuoti paslaugą pagal kintančius
vartotojo reikalavimus nebuvimas.
• RE technikų, kurios leistų užpildyti atotrūkį tarp semantinių
spragų, kurios yra neišvengiamos kai paslaugos iš mišrių (angl. hybrid)
aplinkų yra komponuojamos tarpusavyje.
• RE technikų, kurios leistų valdyti žinias apie paslaugų grupę teikiančią
panašų funkcionalumą nebuvimas.
8

9. Paslaugoms skirta reikalavimų
inžinerija (SoRE)
Taigi, trumpai tariant SoRE turi spręsti šiuos uždavinius:
Paslaugų specifikavimo (angl. Service Specification),
Paslaugų suradimo (angl. Service Discovery),
Žinių apie paslaugas valdymo (angl. Service Knowledge
Management) ir
Paslaugų komponavimo (angl. Service Composition)
9

10. Reikalavimų inžinerija
Reikalavimų inžinerijos proceso paskirtis apibrėžti reikalavimų
išsiaiškinimo, analizės ir dokumentavimo veiklas siekiant sukurti
ekonomiškai efektyvų praktinių problemų sprendimą taikant mokslines
žinias [15].
• Tai kritiškai svarbus PĮ inžinerijos procesas, kurį atlikus turėtų būti gauti PĮ
reikalavimai pasižymintys šiomis savybėmis:
išbaigtumu, nedviprasmiškumu, išmatuojamumu, atsekamumu, dokumentuoja
mumu.
• Reikalavimų inžinerija yra pats svarbiausias SDLC – Software Development Life
Cycle etapas, dėl to, kad visos sistemos kokybė tiesiogiai priklauso nuo sistemos
reikalavimų kokybės. SDLC RE etapas susideda iš šių veiklų:
• Reikalavimų išsiaiškinimo (angl. Requirements Elicitation),
• Reikalavimų analizės (angl. Requirement Analysis),
• Reikalavimų verifikavimo (angl. Requirements Verification)
• Reikalavimų valdymo (angl. Requirements Management)
• Visos šios veiklos turi būti atliktos RE proceso metu. Šių veiklų organizavimui yra
taikomi modeliai, kurie yra skirstomi į keletą rūšių priklausomai nuo to, kokio
tipo PĮ norima jų pagalba kurti, koks PĮ kūrimo ir įsigyjimo procesas, koks yra
kompanijos dydis ir branda. 10

11. Tradicinis RE procesas ir jo
modeliai
Klasikiniai RE modeliai skiriasi nuo paprasčiausių pavyzdžiui [16 ], [17]:
• Įvesties/išvesties reikalavimų inžinerijos proceso modelis (angl. Input/Output of
Requirements Engineering Process), kuris siūlo pasitelkti penkiais darbo
produktais kaip įeitimi : (1) Esamos sistemos informacija, (2) Suinteresuotųjų
šalių poreikiais, (3) Organizaciniais standartais, (4) Reglamentais ir taisyklėmis
(5) Dalykinės srities informacija, taikyti reikalavimų inžinerijos procesą ir gauti
tris darbo produktus: (1) Sutartus reikalavimus (2) Sistemos specifikaciją ir (3)
Sistemos modelius.
Tobulinant šį modelį buvo atrasti tokie pažangesni modeliai kaip:
• Tiesinis reikalavimų inžinerijos proceso modelis (angl. Linear Requirements
Engineering Process Model),
• Linijinis iteracinis reikalavimų inžinerijos proceso modelis (angl. Linear Iterative
Requirement Engineering Process Model),
• Iteracinis reikalavimų inžinerijos proceso modelis (angl. Iterative Requirement
Engineering Process Model), kuris teigia, kad šios veiklos turėtų būti atliekamos
iteracijomis : (1) Reikalavimų aiškinimasis, (2) Reikalavimų specifikavimas, (3)
Reikalavimų validavimas. Iteratyvus reikalavimų inžinerijos proceso modelis yra
labai tinkamas kuomet PĮ versijomis yra išleidžiama į rinką.
• Spiralinis reikalavimų inžinerijos proceso modelis (angl. Spiral Requirement
Engineering Process Model) yra taikomas, kuomet norima į rinką išleisti sistemos
versiją, kuri tenkintų visus tuometinius sistemos vartotojo reikalavimus.
11

12. 12

13. 13

14. 14

15. Reikalavimų generavimo modelis
J.D. Arthur, M. K. Gröner [18] pasiūlė Reikalavimų generavimo modelį
(RGM – Requirements Generation Model) – tai struktūrizuotas požiūris
į reikalavimų specifikavimą, kuris grindžiamas dviem RE komponentais:
• RE karkasu (angl. framework) kuris struktūrizuoja ir kontroliuoja RE
veiklas ir susideda iš dviejų etapų – mokymosi (angl. Indoctrination)
ir reikalavimų rinkimo (angl. Requirements Capturing). Mokymosi
etape siekiama: supažindinti klientą su RGM, supažindinti verslo
analitikus su kliento verslo dalykine sritimi, apibrėžti ir nustatyti
užduotis ir atsakomybę. Reikalavimų rinkimo etapas susideda dar iš
trijų etapų: Pasiruošimo (angl. Preparation) - pasirengti reikalavimų
aiškinimosi susitikimams, Reikalavimų aiškinimosi (angl.
Requirements Elicitation) - dalyvauti reikalavimų aiškinimosi
susitikimuose ir apibrėžti reikalavimus, ir Apžvalgos (angl.
Review), aptarti ir išanalizuoti išsiaiškintus reikalavimus.
• Monitoringo metodika (angl. Monitoring methodology), kuri
užtikrina, kad visos reikalavimų rinkimo veiklos yra atliekamos
laikantis tinkamų procedūrų. 15

16. 16

17. Mūsų siūlomas RE modelis
Išanalizavę visus anksčiau išvardintus tradicinės reikalavimų
inžinerijos modelius, siūlome pažangesnį (angl. sophisticated) RE
modelį, kuris paveldi visas esmines tradicinės RE savybes ir kuris
vėliau, bus naudojamas SoRE struktūrizavimui.
• Trumpai tariant mūsų siūlomas RE modelis – iteratyvus RE
modelis, kuris dengia visas SDLC RE veiklas ir turi papildomą
monitoringo veiklą, skirtą užtikrinti, kad visos veiklos yra
vykdomos kokybiškai.
• Modelis dėl savo iteratyvumo savybės yra tinkamas sudėtingų
ir kompleksinių SOA sistemų reikalavimų analizei ir
specifikavimui.
17

18. Paslaugoms skirtas RE procesas
ir jo modeliai
• Sistematinis paslaugoms skirtas reikalavimų inžinerijos procesas (angl.
Systematic Service-oriented Requirements Engineering Process) [3] yra
skirtas paslaugų specifikavimo uždavinių sprendimui. Jis paremtas trejopu
požiūriu į paslaugą: (1) aukšto lygio paslauga – sukurta sistema turi
automatizuoti verslo procesą, remti verslo strategiją ir tikslus, (2) operacinio
lygmens verslo paslauga - sukurta sistema turi automatizuoti verslo proceso
konkrečias veiklas, (3) IT lygio paslauga – aukšto lygmens verslo reikalavimai
turi būti išreiškiami operacinio lygmens reikalavimais. Procesas susideda iš
trijų etapų:
• Verslo procesų modeliavimo (angl. Business Process Modeling) – apibrėžiami
verslo tikslai, verslo procesai, kurie remia tuos tikslus
• Verslo proceso analizės (angl. Flow-Down) – analizuojamas detaliau kiekvienas
verslo procesas, nustatomos procesų veiklos ir taip suformuojama verslo procesų
architektūra.
• Formalaus reikalavimų specifikavimo etapas (angl. Formal Requirements
Specification). Reikalavimai, kuriuos turi tenkinti sukurta sistema yra formaliai
specifikuojami naudojantis: (1) Paslaugų lygio susitarimais (angl. SLA- Service Level
Agreement), ir (2) Operacinio lygmens susitarimais (angl. OLA – Operational Level
Agreement)
18

19. 19

20. Paslaugoms skirtas RE procesas
ir jo modeliai
Kitas SoRE process struktūrizavimo būdas buvo pasiūlytas Flores et al.
[3], [19] susidedantis iš 6 veiklų:
• Kontekstinės analizės (angl. Contextual Analysis). Nagrinėjama išorinė įtaka
(ekonominė, politinė, verslo tikslų, teisinė), kuri gali įtakoti sėkmingą sistemos
kūrimą.
• Aiškinimosi (angl. Elicitation). Nagrinėjamos suinteresuotos šalys, jų
poreikiai, problemos bei jų noras suteikti reikalingą informaciją.
• Analizės (angl. Analysis). Analizuojami reikalavimai ir jų tarpusavio ryšiai.
• Modeliavimo ir atvaizdavimo (angl. Modeling and Representation).
Reikalavimai yra atvaizduojami susitartu visiems suprantamu būdu.
• Komunikacijos ir derybų (angl. Communication and Negotiation).
Reikalavimai yra pristatomi visoms suinteresuotoms šalims siekiant išvengti
klaidų ir nesusipratimų.
• Validacijos ir galutinio specifikavimo (angl. Validation and Final
Specification). Visi identifikuoti reikalavimai yra validuojami, jeigu
nenustatomas papildomų korekcijų poreikis, tada rengiamos galutinės
reikalavimų specifikacijos.
• Pokyčių valdymo (angl. Change Management). Veikla atliekama po
kiekvienos iš aukščiau išvardintų veiklų siekiant susekti kiekvieną įvykdytą
pakeitimą. Veikla naudinga audito ir nuolatinio tobulėjimo tikslais.
20

21. SOA kūrimo metodikos
Yra siūloma keletas paslaugoms pritaikytų sistemų kūrimo
metodikų tokių kaip: IBM
RUP/SOMA, SOAF, SOUP, metodikos pagal Tomas Erl ir
Michael Papazoglou.
SOA gyvavimo ciklas šiose metodikose gali būti suskaidytas į tokius etapus:
1. Paslaugoms pritaikytas planavimas/Pradžia (angl. Service-oriented
planning/Inception)
2. Paslaugoms pritaikyta analizė (angl. Service-oriented analysis),
3. Paslaugoms pritaikytas projektavimas (angl. Service-oriented design),
4. Paslaugų kūrimas (angl. Service Construction),
5. Paslaugų testavimas (angl. Service Testing),
6. Paslaugų priežiūra (angl. Service Provisioning),
7. Paslaugų diegimas (angl. Service Deployment),
8. Paslaugų vykdymas (angl. Service Execution)
9. Paslaugų stebėjimas (angl. Service Monitoring)
21

22. IBM RUP/SOMA
IBM RUP/SOMA [12], [20] yra integruota, patentuota
metodika, sukurta IBM siekiant įnešti unikalius SOMA
(Service-oriented Modeling Approach) aspektus į RUP.
Metodika susideda iš keturių etapų:
1. Verslo transformacijos analizės (angl. Business
Transformation Analysis),
2. Paslaugų identifikavimo (angl. Identification)
3. Paslaugų specifikavimo (angl. Specification), ir
4. Paslaugų realizavimo (angl. Realization of services).
22

23. Thomas Erl metodika
Thomas Erl’s [20] paslaugų analizės ir projektavimo
metodika yra aprašyta dvejose jo knygose Thomas Erl
[10], [11]. Ši metodika pažingsninis vadovas per
paslaugoms skirtus analizės ir projektavimo etapus.
23

24. Papazoglou metodika
Metodika pagal Papazoglou [9], [20]. Metodika nagrinėja
paslaugų kūrimą iš dviejų požiūrio taškų: tiekėjo (angl.
Provider) ir vartotojo (angl. Consumer) ir dengia visą SOA
sistemos kūrimo ciklą.
• Ši iteratyvi ir laipsniška (angl. Incremental) metodika
susideda iš vienos parengiamosios - Planavimo veiklos
iš 8 pagrindinių ankščiau minėtų veiklų.
24

25. SOAF
SOAF - Service Oriented Architecture Framework [13], [20]
susideda iš penkių pagrindinių etapų:
1. Informacijos aiškinimosi (angl. Information Elicitation),
2. Paslaugų identifikavimo (angl. Service Identification)
3. Paslaugų apibrėžimo (angl. Service Definition),
4. Paslaugų realizavimo (angl. Service Realization), ir
5. Veiksmų plano sudarymo bei planavimo (angl. Roadmap
and Planning).
SOAF metodikos tikslas palengvinti paslaugų
identifikavimo, apibrėžimo ir realizavimo veiklas derinant “iš
viršaus į apačią” tipo (angl. top-down) egzistuojančių verslo
procesų analizę ir modeliavimą su “iš apačios į viršų” tipo (angl.
bottom-up) egzistuojančių sistemų analize. 25

26. SOUP
SOUP- Service-oriented Unified Process [14], [20], yra hibridinė
programinės įrangos inžinerijos metodika, kurią pasiūlė K. Mittal.
Kaip rodo metodikos pavadinimas, ši metodika visų pirma yra
grindžiama RUP - Rational Unified Process. Ji susideda iš šešių
etapų:
1. Pradžios (angl. Inception),
2. Apibrėžimo (angl. Define),
3. Projektavimo (angl. Design),
4. Kūrimo (angl. Construct),
5. Diegimo (angl. Deploy) ir
6. Palaikymo (angl. Support).
SOUP metodika gali būti naudojama dviem šiek tiek skirtingais
variantais: pirminis - remiasi RUP, skirtas SOA sistemų kūrimui
nuo pradžios, antrinis – remiasi XP ir skirtas esamų SOA sistemų
priežiūrai.
26

27. SOA kūrimo metodikų
palyginimas
Į paslaugas orientuotų sistemų kūrimo metodikos buvo
palygintos [23] šaltinyje nurodytu būdu, kuris teigia, kad
metodikas galima palyginti naudojantis šiomis
charakteristikomis:
1. SOA analizės ir projektavimo strategija (angl. SOA analysis
& design strategy),
2. SoSD metodikų etapų ir jų veiklų išvardinimas bei
tarpusavio palyginimas (angl. SoSD phases and their
activities mapping),
3. SoSD metodikų detalumo analizė (angl. Degree of
methodology prescription),
4. Egzistuojančių analizės ir projektavimo technikų bei
notacijų pritaikymas (angl. Adoption of existing techniques
and notation)
27

28. SOA kūrimo metodikų
palyginimo rezultatai
• Atliktas SoSD metodikų palyginimas parodė, kad:
• Dvi metodikos: IBM RUP/SOMA ir metodika pagal Tomas Erl
dengia tiktai paslaugoms skirtos analizės ir projektavimo etapus.
• Dvi metodikos: SOUP ir metodika pagal Papazoglou turi
papildomą paslaugoms pritaikytą planavimo etapą.
• Metodika pagal Papazoglou, SOAF ir SOUP dengia visą
paslaugoms pritaikytų sistemų kūrimo gyvavimo ciklą.
• Analizuotos SoSD metodikos yra labai skirtingo detalumo
lygmens - nuo pačių detaliausių kurios pateikia kiekvieno
etapo, jo veiklų, įeigos bei išeigos produktų aprašus iki
tokių, kurios pateikia tik etapo glaustą aprašą
• Pati detaliausia metodika yra IBM RUP/SOMA, kuri yra
patentuota ir plačiai naudojama industriniuose projektuose. 28

29. SOA kūrimo metodikų
palyginimo rezultatai
• Atliktas SoSD metodikų palyginimas parodė, kad:
• Dauguma iš analizuotų metodikų remiasi “vidurio” (angl. meet-in-
the-middle) analizės strategija, nusakančia, kad dauguma SOA
projektų prasideda ne nuo nulio, o nuo esamų sistemų keitimo
naujomis. Tai reiškia, kad atlikdami reikalavimų analizę turime
vienodai dėmesio skirti ir naujų reikalavimų analizei ir esamų
sistemų galimybių analizei siekiant išsiaiškinti, kaip jas galime
pritaikyti naujiems reikalavimams.
• Vienas iš didžiausių analizuotų metodikų trūkumų yra tas, kad jos
visiškai nedengia reikalavimų valdymo, reikalavimų pokyčių
valdymo veiklų, taip pat neturi jokių reikalavimų valdymo veiklų
monitoringo procedūrų. Jos tik dalinai dengia SDLC reikalavimų
aiškinimosi, analizės, verifikavimo, specifikavimo veiklas.
• Rezultate, SoSD metodikos gali būti taikomos kaip informacijos
šaltinis paslaugoms skirto reikalavimų inžinerijos proceso
struktūrizavimui, tačiau tikslui pilnai pasiekti būtina naudotis ir kitais
šaltiniais.
29

30. Siūlomos paslaugoms skirto reikalavimų
inžinerijos proceso charakteristikos
Tradiciškai reikalavimų inžinerijos procesas yra atliekamas
sistemos kūrimo gyvavimo ciklo pradžioje, tačiau, kaip jau
matėme, sudėtingų sistemų kūrimui naudojami
iteratyvūs, laipsniški, spiraliniai reikalavimo inžinerijos proceso
modeliai. Todėl, darydami išvadą, galime teigti, kad SOA sistemų
kūrimui turėtų būti taikomas ankščiau pristatytas pažangesnis
(angl. sophisticated) reikalavimų inžinerijos proceso
modelis, kuris dengtų šias veiklas:
• SDLC RE veiklas, bei papildomai:
• Verslo kontekstinės analizės (angl. Business Contextual Analysis),
• Komunikacijos ir reikalavimų derybų (angl. Communication and
Requirement Negotiation),
• Reikalavimų pokyčių valdymo (angl. Requirement Change
Management),
• RE proceso monitoringo (angl. RE Process Monitoring Activity)
30

31. Siūlomos paslaugoms skirto reikalavimų
inžinerijos proceso charakteristikos
Paslaugoms skirtas reikalavimų inžinerijos procesas turėtų būti
paremtas pažangesnio reikalavimų inžinerijos proceso
charakteristikomis bei pasižymėti unikaliomis charakteristikomis
būdingomis tik paslaugų paradigmai, tokiomis kaip:
1. SOA reikalavimai yra veikiami dviejų suinteresuotų šalių -
tiekėjų ir vartotojų. Tiekėjai turi sukurti tokias
paslaugas, kurios tenkintų daugelio vartotojų poreikius, o
vartotojai ieško paslaugų, kurios tenkintų jų poreikius,
2. SoRE turi teikti galimybę rasti paslaugas projektavimo
metu (statinė SOA) ir vykdymo (angl. runtime) metu
(dinaminė SOA),
3. SoRE turi teikti dinamines SOA sistemos
komponavimo, perkomponavimo galimybes jos veikimo
metu.
31

32. Siūlomos paslaugoms skirto reikalavimų
inžinerijos proceso charakteristikos
Siūlome SoRE procesą struktūrizuoti panaudojant šiuos etapus:
• Verslo kontekstinę analizę (angl. Contextual Analysis Phase)
• Verslo procesų modeliavimą (angl. Business Process Modeling
Phase), kur analiziojami verslo strateginiai tikslai bei kaip
verslo procesai padeda juos įgyvendinti
• Paslaugų identifikavimą (angl. Service Identification)
32

33. Siūlomos paslaugoms skirto reikalavimų
inžinerijos proceso charakteristikos
Siūlome SoRE procesą struktūrizuoti panaudojant šiuos etapus:
• Paslaugų kūrimo (angl. Service Development) – skirtas atskirų
paslaugų ar jų komponentų reikalavimų kūrimui
• Paslaugoms skirtų sistemų kūrimo (angl. Service-oriented
Systems Development Phase) – skirtas paslaugų reikalavimų
komponavimui
• Reikalavimų valdymo ir reikalavimų pokyčių valdymo (angl.
Requirements Management and Requirements Change
Management Phase)
• Reikalavimų monitoringo (angl. Requirement Process
Monitoring Phase)
33

34. Literatūra
• [1] R.Kumar, Mr.K.Singh, “A Literature Survey on black box testing in component based
software engineering”, International Journal of Advanced Research in Computer
Science and Software Engineering, Volume 2, Issue 3, March 2012, ISSN 128X
• [2] M.Bano, N.Ikram, M.Niazi, “Thesis proposal on Requirement Engineering Process
for Service Oriented Software Development”, Proceedings of the 11th International
Conference on Product Focused Software, pp. 84-88, 2010
• [3] F. Flores, M. Mora, F. Álvarez, L. Garza and H.Durán, “Towards a Systematic
Service-oriented Requirements Engineering Process (S-SoRE)”, ENTERprise
Information Systems Communications in Computer and Information Science Volume
109, 2010, pp 111-120
• [4] F. Flores, M. Mora, F. Álvarez, L. Garza and H.Durán, H.Gerardo Gonzalez, From
Requirements Engineering to Service-oriented Requirements Engineering: An Analysis
of Transition , Thirteenth International Conference on Information Systems, 2009
• [5] D.Barker "itSMF – ITIL Best Practice. Are we Getting the Message?" ServiceTalk –
Journal of IT Service Management Forum, 66, pp. 3 (2004)
• [6] A.Lamsweerde,"Requirements Engineering in the Year 00: A Research
Perspective". In Proceedings of the ICSE 2000 Conference, pp. 5-19. (2000)
• [7] J.J.M.Trienekens, J.J.Bouman, M. van der Zwan “Specification of Service Level
Agreements: Problems, Principles and Practices”, Software Quality Journal, 12(1), pp.
43-57, (2004)
• [8] W.T.Tsai, Z.Jin, P.Wang, B.Wu “Requirement Engineering in Service-Oriented System
Engineering”, IEEE International Conference on e-Business Engineering, (2007)
34

35. Literatūra
• [9] M.P. Papazoglou, “Service-Oriented Design and Development Methodology”, Int.
J. of Web Engineering and Technology (IJWET), 2006
• [10] T. Erl, “Service-Oriented Architecture: Concepts, Technology and
Design”, Prentice Hall PTR, 2005
• [11] T. Erl, “SOA Principles of Service Design”, Prentice Hall PTR, 2008
• [12] IBM RUP/SOMA available at: http://www.michael-
richardson.com/rup_classic/#core.base_rup/guidances/supportingmaterials/introduc
tion_to_rup_36B63436.html, April 2013
• [13] A. Erradi, S. Anand, N. Kulkarni, "SOAF: An Architectural Framework for Service
Definition and Realization", IEEE International Conference on Services Computing
(SCC'06), 2006
• [14] SOUP available at http://www.kunalmittal.com/html/soup.html, April 2012
• [15] M.Shaw, "Prospects for an Engineering Discipline of Software". IEEE
Software, 7(6): 15-24, (1990)
• [16] Mr. S.Ul Arif, Mr. Q. Khan, S. A. K. Gahyyur, "Requirement Engineering Processes
Tools/Technologies & Methodologies", IJRIC, 2009-2010
• [17] G.Kotonya, I.Sommervile, "Requirements Engineering Process And
Techniques", John Wiley & Sons, 1998
• [18]J.D. Arthur, M. K. Gröner, "An operational model for structuring the requirements
generation process", Requirements Engineering, pp. 45-62, 10(1), 2005
• [19] F.Flores, M.Mora, F.Álvarez, R. O’Connor, J.Macias, "Handbook of Research on
Modern Systems Analysis and Design Technologies and Applications", In IGI Global
(eds), pp. 96 -111 (2008)
35

36. Literatūra
• [20] E. Ramollari, D.Dranidis, A.JH Simons "A survey of service oriented development
methodologies." The 2nd European Young Researchers Workshop on Service Oriented
Computing, 2007
• [21] M. Galster, E.Bucherer. "Towards Requirements Engineering in a Service-Oriented
Environment--Extending the SOA Interaction Triangle.", Computational Intelligence for
Modelling Control & Automation, 2008 International Conference on. IEEE, 2008
• [22] A.Van Lamsweerde,"Requirements engineering in the year 00: A research perspective."
Proceedings of the 22nd international conference on Software engineering. ACM, 2000.
• [23] S. Svanidzaite, “A Comparison of SOA Methodologies Analysis & Design
Phases”, DB&Local Proceedings 2012: 202-207
• [24] A. Arsanjani, "Service Provider: A Meta-Domain Pattern and its Business Framework
Implementation", In Online Proceedings of the Pattern Languages in Programming
Conference, 1999
• [25] P. Layzell, et al., “Service-based Software: The Future for Flexible Software”, In
Proceedings of Asia-Pacific Software Engineering Conference, 5-8 December, Singapore.
, IEEE Computer Society, 2000
• [26] Rational Software, “Rational Unified Process: Best Practices for Software Development
Teams”, Rational Software Corporation, 1998
• [27] A. Arsanjani, “Enterprise Component: A compound pattern for building component
architectures”, IEEE Computer Society, 2001
• [28] P. Van Eck, R. Wieringa, “Requirements Engineering for Service-Oriented Computing”: a
Position Paper”, In Proceedings of First International E-Services Workshop, ICEC 03,.
Pittsburgh, USA, , pp. 23-28, 2003.
• [29] J. Trienekens, J. J. Bouman, M. van der Zwan, “Specification of Service Level
Agreements: Problems, Principles and Practices”, Software Quality Journal, 12(1), pp. 43-
57, 2004.
36