reikalavimų inžinerijos procesas skirtas paslaugų reikalavimams (slides in lithuanian language)

REIKALAVIMŲ INŽINERIJOS PROCESAS SKIRTAS PASLAUGŲ REIKALAVIMAMS

(angl. Towards Service-oriented Requirements Engineering Process)

Sandra SvanidzaitėInformatika (07 T), vadovas prof. dr. A.Čaplinskas

Vilniaus Universitetas, Matematikos ir informatikos institutasProgramų sistemų inžinerijos skyrius

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

Paradigmų evoliucija

3

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


• 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

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

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

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


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

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, dokumentuojamumu.

• 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

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

Reikalavimų generavimo modelisJ.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

Mūsų siūlomas RE modelisIš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

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

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

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

IBM RUP/SOMAIBM 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

Thomas Erl metodikaThomas 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

Papazoglou metodikaMetodika 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

SOAFSOAF - 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), ir5. 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

SOUPSOUP- 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

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

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

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

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


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


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


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

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

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/introduction_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

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