INFORMĀCIJAS SISTĒMU METODOLOĢIJAS (DSP404)

Lekciju materiāls sagatavots projekta“RTU studiju programmas “Datorsistēmas” pilnveidošana absolventu profesionālās konkurētspējas paaugstināšanai “ ietvaros

©RTU, 2007

INFORMĀCIJAS SISTĒMU INFORMĀCIJAS SISTĒMU METODOLOĢIJAS METODOLOĢIJAS

(DSP404)(DSP404)

2“RTU studiju programmas “Datorsistēmas” pilnveidošana absolventu profesionālās konkurētspējas paaugstināšanai “2006/0238/VPD1/ESF/PIAA/06/APK/3.2.3.2/0015/0007

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums>

Asoc. prof., Dr.sc.ing. Mārīte Kirikova

Rīgas Tehniskā universitāteDatorzinātnes un informācijas tehnoloģijas fakultāteLietišķo datorsistēmu institūtsSistēmu teorijas un projektēšanas katedra

INFORMĀCIJAS SISTĒMU INFORMĀCIJAS SISTĒMU METODOLOĢIJASMETODOLOĢIJAS



Priekšmeta pamatdatiPriekšmeta pamatdati

• Priekšmeta pieteicējs: Mārīte Kirikova• Apjoms: 3 KP• Kontroles veids: Eksāmens, studiju darbs• Studiju līmenis: Maģistra profesionālās

studijas• Semestris: 1.



Priekšmeta mērķi un uzdevumiPriekšmeta mērķi un uzdevumi

• Mērķi:1. Iepazīstināt studentus ar dažādām pieejām

informācijas sistēmu izstrādē, īpaši tās sākotnējos posmos.

2. Attīstīt prasmi elastīgi domāt dažādos informācijas sistēmas izstrādes apraksta abstrakcija līmeņos

3. Attīstīt prasmi modelēt informācijas sistēmu un tās izmantošanas vidi, izmantojot populārākās modelēšanas paradigmas un to kombinācijas (ne tikai UML)

4. Veicināt tādu studentu mentālo modeļu izveidi, kas rada iespēju veiksmīgi sadarboties ar biznesa sfēras pārstāvjiem.



Priekšmeta mērķi un uzdevumiPriekšmeta mērķi un uzdevumi

• Uzdevumi:1. Izprast saistību starp organizācijas funkcionālo,

vadības un informācijas sistēmu.2. Apgūt dažādas domāšanas struktūras

informācijas sistēmu projektēšanā (dažādu metodoloģiju pamatus)

3. Gūt priekšstatu par metodoloģiju novērtēšanas kritērijiem un integrēšanas iespējām

4. Gūt priekšstatu par piemērotas metodoloģijas izvēli atbilstoši informācijas sistēmas projektēšanas situācijai



PamatlitetratūraPamatlitetratūra

Avison D. and Fitzgerald Information Systems Development: Methodologies, Techniques, Tools, 3ed.m McGraw-Hill, 2003.



PapildliteratūraPapildliteratūra

Stojanovic Z. And Dahanayake A. Service-Orineted Software System Engineering, Idea Group Publishing, 2004.

Jajodia S. And Strous L. Integrity and Internal Control in Information Systems VI, Cluver Academic Publishers, 2004.

Kursā aplūkoto metodoloģiju portāli



Atslēgas vārdiAtslēgas vārdi

• informācijas sistēma• sistēmu inženierija• prasību inženierija• sistēmu arhitektūra• informācijas sistēmas projekts• projektēšanas metodoloģija



PamattēmasPamattēmas• Informācijas sistēmu ontoloģija• Informācijas sistēmu un informācijas sistēmu

projektu veidi• Sistēmiskie faktori informācijas sistēmu izstrādē• Organizāciju un informācijas sistēmu arhitektūru

orientēta projektēšana• Aģentu orientētas metodoloģijas• Problēmu orientētas metodoloģijas • Biznesa procesu orientētas metodoloģijas• Pakalpojumu orientētās metodoloģijas un

pakalpojumu orientētās arhitektūras• Aspektu orientētas metodoloģijas• Informācijas sistēmu metodoloģiju izvēles un

kombinēšanas metodes.


©RTU, 2007

Informācijas sistēmu Informācijas sistēmu ontoloģijaontoloģija

1. tēma



Informācijas sistēmu definīcijasInformācijas sistēmu definīcijas

• Sistēma, kas apstrādā datus, lai iegūtu informāciju (Avison)

• Informācijas apstrādes sistēma un ar to saistītie organizatoriskie resursi (piem., cilvēkresursi, metodiskie, finansiālie un citi), kas nodrošina ar informāciju LVS ISO/IEC 2382-1:1997: Information processing system, together with associated organisational resources, such as humans, technical and financial resources, that provides and distributes information ISO/IEC 2382-1:1993

• Informācijas sistēma ir organizācijas kā sistēmas apakšsistēma, kas nodrošina tās funkcionēšanai nepieciešamo informāciju; datorizēta informācijas sistēma ir informācijas sistēma, kur daļa no nodrošināšanas funkcijām tiek izpildītas, izmantojot datorus.



Dati, informācija, zināšanasDati, informācija, zināšanas

IS

Dati, informācija,

zināšanas

Dati, informācija, zināšanas

Dati

Dati

Dati

Mērķis

IS ārējā vide IS ārējā vide

Informācijas sistēma un tās datorizētā daļa atbalsta organizācijas mērķusPrasību inženierija (IS konteksta plašākā nozīmē) nosaka prasības pret informācijas sistēmu un tās datorizēto daļu



Informācijas sistēmu metodoloģijas Informācijas sistēmu metodoloģijas definīcijadefinīcija

• Sistēmu izstrādes metodoloģija ir ieteicamie līdzekļi informācijas sistēmu izstrādāšanai vai daļējai izstrādāšanai, kas ir balstīta uz loģisku pamatojumu un filozofiju, kas atbalsta un attaisno šo ieteikumu attiecīgajā kontekstā. Ieteicamie līdzekļi parasti iekļauj fāžu identifikāciju, procedūras, uzdevumus, likumus, metodes, vadlīnijas, dokumentāciju un rīkus. Tie var arī iekļaut rekomendācijas, kas attiecas uz metodes pārvaldību un organizāciju, kā arī dalībnieku izvēli un apmācību.



Bunge, WandBunge, Wand un un Weber Weber ontoloģija ontoloģija (1)(1)

• Lieta– Lieta ir BWW modeļa elementārā vienība.

Reālā pasaule sastāv no lietām. Divas vai vairākas lietas (gan saliktas, gan vienkāršas) var tikt saistītas saliktā lietā.



• Īpašība (Iekšēja, Nesaistoša kopēja, Saistoša kopēja, Negaidīti radusies, Pārmantota, Atribūts)– Lietām piemīt īpašības. Īpašību veido kā

funkciju, kura piešķir lietai kādu vērtību. Saliktas lietas īpašība, kura pieder komponenta lietai, tiek saukta par pārmantotu īpašību. Citā gadījumā tā ir negaidīti radusies īpašība. Īpašības, kuras ir iedzimtas atsevišķām lietām, sauc par iekšējām īpašībām. Kopējas īpašības ir īpašības, kuras piemīt divām vai vairākām lietām. Nesaistošas kopējas īpašības neietekmē lietas, kurām tās piemīt, savukārt saistošas kopējas īpašības ietekmē. Atribūti ir vārdi, kurus izmanto, lai attēlotu noteiktas lietu īpašības (parasti abstraktas).




• Klase– Klase ir lietu kopa, kuru var definēt ar kopīgas

īpašības esamību.

• Veids– Veids ir lietu kopa, kuru var definēt ar divu vai

vairāku kopīgu īpašību esamību.

• Stāvoklis– Lietas stāvoklis ir visu lietas īpašību funkciju

vērtību vektors.




• Iespējamā stāvokļu telpa– Iespējamā stāvokļu telpa ir visu stāvokļu, kurus

lieta jebkad varētu ieņemt, kopa.

• Stāvokļa likums (Stabilitātes nosacījums, Koriģējošā darbība)– Stāvokļa likums ierobežo lietas īpašību vērtības

apakškopā, kura atbilst dabiskajiem vai cilvēku likumiem. Stabilitātes nosacījums norāda stāvokļus, kurus atļauj stāvokļa likums. Koriģējošā darbība parāda, kā ir jāmainās īpašības funkcijas vērtībai, lai stāvoklis kļūtu atbilstošs stāvokļa likumam.




• Likumīga stāvokļu telpa– Likumīga stāvokļu telpa ir lietas stāvokļu kopa,

kas pakļaujas lietas stāvokļa likumiem. Likumīga stāvokļu telpa parasti ir korekta iespējamās stāvokļu telpas apakškopa.

• Notikums– Notikums ir lietas stāvokļa maiņa.

• Process– Process ir iekšēji norīkota notikumu vai

stāvokļu virkne.




• Iespējamā notikumu telpa– Lietas notikumu telpa ir visu iespējamo

notikumu, kas var notikt ar lietu, kopa.

• Transformācija– Transformācija ir pāriešana no viena stāvokļa

uz otru.

• Likumīga tranformācija (Stabilitātes nosacījums, Koriģējošā darbība)– Likumīga transformācija nosaka, kuri lietas

notikumi ir atļauti. Stabilitātes nosacījums norāda notikumus, kurus atļauj transformācijas likums. Koriģējošā darbība norāda, kā ir jāmainās īpašības funkcijas vērtībām, lai stāvoklis būtu atbilstošs transformācijas likumam.




• Likumīga notikumu telpa– Likumīga notikumu telpa ir visu atļauto lietas

notikumu kopa.

• Vēsture– Lietas vēsture ir hronoloģiski sakārtoti stāvokļi,

kuros lieta ir atradusies.

• Iedarboties uz– Lieta iedarbojas uz citu lietu, ja tās eksistence

ietekmē citas lietas vēsturi.




• Savienošana pāros (Saistoša kopēja īpašība)– Divas lietas ir savienotas pāros (jeb savstarpēji

iedarbojas), ja viena lieta iedarbojas uz otru. Šīm divām lietām ir saistoša kopēja īpašība (jeb attiecība), tas ir, tām piemīt kopēja īpašība, kas ietekmē šīs lietas.

• Sistēma– Lietu kopa ir sistēma, ja, jebkādā veidā sadalot

sistēmu divās daļās, eksistē savienošana pāros starp lietām divās apakškopās.




• Sistēmas kompozīcija– Lietas sistēmā ir tās kompozīcija.

• Sistēmas vide– Lietas, kuras neatrodas sistēmā, bet

mijiedarbojas ar lietām tajā, tiek sauktas par sistēmas vidi.

• Sistēmas struktūra– Pāru kopa, kas eksistē starp lietām sistēmā un

starp lietām sistēmas vidē un sistēmā, tiek saukta par struktūru.




• Apakšsistēma– Apakšsistēma ir sistēma, kuras kompozīcija un

struktūra ir citas sistēmas kompozīcijas un struktūras apakškopas.

• Sistēmas dekompozīcija– Sistēmas dekompozīcija ir tādu apakšsistēmu

kopa, ka katrs sistēmas komponents ir vai nu viena no dekompozīcijas apakšsistēmām vai ir iekļauts vienas no dekompozīcijas apakšsistēmām kompozīcijā.




• Līmeņu struktūra– Līmeņu struktūra definē daļēju sakārtojumu

dekompozīcijas apakšsistēmas, lai parādītu, kuras apakšsistēmas ir citu apakšsistēmu komponentes un kuras ir sistēmas pašas par sevi.

• Ārējais notikums– Ārējais notikums ir notikums, kurš norisinās

lietā, apakšsistēmā vai sistēmā un kuru izraisa kādas vides lietas iedarbība uz lietu, apakšsistēmu vai sistēmu.




• Stabils stāvoklis– Stabils stāvoklis ir stāvoklis, kurā lieta,

apakšsistēma vai sistēma paliek tik ilgi, līdz tas ir spiests mainīties kādas vides lietas iedarbības uz lietu, apakšsistēmu vai sistēmu dēļ (ārējais notikums).

• Nestabils stāvoklis– Nestabils stāvoklis ir stāvoklis, kas pāries uz

citu stāvokli pēc transformācijas darbībām sistēmā.




• Iekšējais notikums– Iekšējais notikums ir notikums, kas rodas lietā,

apakšsistēmā vai sistēmā pēc likumīgas transformācijas lietā, apakšsistēmā vai sistēmā.

• Labi definēts notikums– Labi definēts notikums ir notikums, kurā vienmēr

var paredzēt nākošo stāvokli, ja ir zināms iepriekšējais stāvoklis.

• Vāji definēts notikums– Vāji definēts notikums ir notikums, kurā nevar

paredzēt nākošo stāvokli, ja ir zināms iepriekšējais stāvoklis.




Meta valodas elementiMeta valodas elementi

Developing a meta model for the Bunge-Wand-Weber ontological constructs, Michael Rosemann, Peter Green, 2001

Realitātes tips

IzskaidrojumsValodas konstrukcija

Saites tips, kas apvieno vismaz divus realitāšu tipus

Ja ir nepieciešams modelēt saites tipu saistītu ar citu datu modeļa elementu (realitātes vai saites tipu), tad saites tips ir jāinterpretē no jauna.

Ģeneralizācija, specializācija. Tā ir vai nu sadalīta (d) vai nesadalīta (n), kā arī tā ir pilnīga specializācija vai daļēja. Daļēja specializācija nozīmē, ka vēl eksistē apakštipi, kas modelī nav attēloti

Klasteris ietver datu modeļa elementus (ir-daļa-no saite) un izceļ to, ka viņiem ir kopēja speciāla semantika



Lieta, īpašība, klase, veids un atribūtsLieta, īpašība, klase, veids un atribūts




Lieta, savienošana pāros, sistēma, kompozīcija un Lieta, savienošana pāros, sistēma, kompozīcija un videvide




Īpašību apakštipiĪpašību apakštipi



©RTU, 2007

Informācijas sistēmu un Informācijas sistēmu un informācijas sistēmu projektu informācijas sistēmu projektu

veidiveidi2.tēma



Informācijas sistēmu veidi (1)Informācijas sistēmu veidi (1)

• Uzņēmumu informācijas sistēmas– Ražošanas uzņēmumu informācijas

sistēmas– Pakalpojumus sniedzošo uzņēmumu

informācijas sistēmas– Valsts pārvaldes informācijas sistēmas

• Zināšanu krātuvju informācijas sistēmas• Iegulto sistēmu informācijas sistēmas• Jauktās informācijas sistēmas




• Datu bāzu sistēmas• Transakciju apstrādes sistēmas• Operacionālās vadības informācijas sistēmas

– Statistisko datu apstrādes sistēmas– Lēmuma atbalsta sistēmas

• Pārvaldības informācijas sistēmas• Biznesa procesu vadības sistēmas• Lēmumu atbalsta sistēmas• Stratēģiskās vadības informācijas sistēmas• Zināšanu vadības sistēmas



Pārvaldības informācijas sistēmasPārvaldības informācijas sistēmas

• Īpašumu pārvaldības sistēmas• Noliktavu pārvaldības sistēmas• Cilvēku resursu pārvaldības sistēmas• Finanšu pārvaldības sistēmas

– Grāmatvedības sistēmas– Ieguldījumu plānošanas sistēmas

• Vides ekoloģijas pārvaldības sistēmas




• Personālās informacijas sistēmas• Grupu informācijas sistēmas• Organizāciju informācijas sistēmas• Starporganizāciju informācijas sistēmas



Informācijas sistēmu projektu veidiInformācijas sistēmu projektu veidi

• Iekšējie projekti• Projekts kā ārpakalpojums

• Sistēmas izstrāde iepriekš nedatorizētai IS

• Iepriekšējās sistēmas aizstāšana ar citu sistēmu

• Iepriekšējās sistēmas modificēšana



LīdzdalībasLīdzdalības veidi (1) veidi (1)

• Padomdevēja līdzdalība– Zemākā līdzdalības pakāpe – galvenie

projektēšanas uzdevumi tiek uzticēti sistēmanalītiķiem, bet par izmaiņām informē visus lietotāja daļas darbiniekus. Sistēmanalītiķiem, pārprojektējot sistēmu, ir jācenšas palielināt apmierinātību ar darbu. Lielākā daļa no tradicionālās sistēmu izstrādes pieejas atbalstītājiem izmanto šo līdzdalības pakāpi projektēšanas procesā.




• Pārstāvnieciska līdzdalība– Šajā līdzdalības pakāpē lietotāju nodaļa

iesaistās daudz vairāk. “Projektēšanas grupa” sastāv no lietotāju pārstāvjiem un sistēmanalītiķiem. Lietotājiem un izstrādātājiem ir vienādas tiesības katrā lēmumā. Lietotāju pārstāvjiem ir jāpārstāv visu lietotāju, kurus ietekmē projektēšanas lēmumi, intereses.




• Vienprātības līdzdalība– Šajā līdzdalības pakāpē projektēšanas procesā

cenšas iesaistīt visus lietotāju nodaļas darbiniekus – process ir balstīts uz lietotāju. Šajā pakāpē ir grūtāk pieņemt ātrus lēmumus, bet projektēšanas lēmumi atspoguļo darbinieku intereses. Dažreiz ir iespējams izdalīt atsevišķas uzdevumu kopas, par kurām projektēšanas lēmumus pieņem tie cilvēki, kuri tajās ir iesaistīti.



Tiešo lietotāju veidiTiešo lietotāju veidi

• Galalietotāji bez programmēšanas prasmēm – šiem lietotājiem ir relatīvi mazas IT prasmes, un viņi lieto programmatūru, kuru nodrošina citi.

• Komandlīmeņa lietotāji – šie lietotāji veic pieprasījumus un vienkāršus aprēķinus, kā arī sastāda atskaites, izmantojot 4GLs (ceturtās paaudzes valodas) vai vaicājumu valodas.

• Galalietotāji programmētāji – šie lietotāji spēj izmantot procedurālas programmēšanas valodas, lai radītu lietojumus personīgām vajadzībām.

• Funkcionālā atbalsta personāls – šiem lietotājiem ir prasmes sistēmu izstrādē, kā arī viņi kļūst par neformāliem citu galalietotāju atbalstītājiem (viņi nodrošina citu galalietotāju IT atbalstu un apmācību).


©RTU, 2007

Sistēmiskie faktori informācijas Sistēmiskie faktori informācijas sistēmu izstrādēsistēmu izstrādē



Praktiskā sarežģītībaPraktiskā sarežģītība

• Praktiskā sarežģītība ir teorētiskās sarežģītības apakškopa, jo reāli cilvēki neizmanto visas pieejamās (vai iespējamās) modelēšanas valodas konstrukcijas. Tādējādi praktiskā sarežģītība ir vienāda ar lietotās modelēšanas valodas kodolu, kuru lietotāji izmanto visvairāk.



Sarežģītība attiecībā pret dažādiem Sarežģītība attiecībā pret dažādiem sistēmu tipiemsistēmu tipiem

Erickson, J., Keng, S., (2007), “Theroretical and Practical Complexity of Modeling Methods”, Communications, August 2007, Volume 50, Number 8, pp. 48.



Iemesli, kāpēc teorētiskā sarežģītība nav Iemesli, kāpēc teorētiskā sarežģītība nav adekvāta (1)adekvāta (1)

• Teorētiskās sarežģītības analīze balstās uz visiem iespējamiem objektiem, saitēm un īpašībām, kaut arī praksē katrā diagrammā netiek izmantotas visas konstrukcijas.

• Cilvēka īstermiņa atmiņa ir ierobežota un spēj glabāt 7 plus mīnus 2 informācijas vienības. Tomēr cilvēki spēj uztvert sarežģītas diagrammas, prātā sadalot tās apakšdiagrammās un analizējot tās atsevišķi. Pašreizējie sarežģītības parametri to neņem vērā.



Iemesli, kāpēc teorētiskā sarežģītība nav Iemesli, kāpēc teorētiskā sarežģītība nav adekvāta (2)adekvāta (2)

• Reizēm ir nepieciešams piešķirt svarus atšķirīgām konstrukcijām. Piemēram, konstrukcijai, kurai ir lielāka iespēja kļūt par īstermiņa atmiņas problēmu, būtu jāpiešķir lielāks svars sarežģītības skalā nekā konstrukcijai, kura īstermiņa atmiņai problēmu, visticamāk, nesagādās.



IT pārvaldības trīs pakāpesIT pārvaldības trīs pakāpes

Raghupathi, W., (2007), “Corporate Governanace of IT: A Framework for Development”, Communications, August 2007, Volume 50, Number 8, pp. 95.



IS kvalitātes rādītāji (1)IS kvalitātes rādītāji (1)

• Pieņemamība – vai cilvēki, kuri izmanto sistēmu, atzīst to par apmierinošu un vai tā apmierina viņu informācijas vajadzības. Tas iekļauj biznesa lietotājus un vadītājus un viņu vajadzības.

• Pieejamība – vai sistēma ir pieejama, kad un kur tā ir nepieciešama.

• Integrētības pakāpe – vai starp komponentiem (apakšsistēmām) ir tāda mijiedarbība, ka informācijas sistēmas un biznesa sistēmas ir pilnībā integrētas.

• Savienojamība – vai sistēma ir savienojama ar citām sistēmām un organizācijas daļām.




• Dokumentācijas pieejamība – vai eksistē laba dokumentācija, kas atvieglo saskarsmi starp operatoriem, lietotājiem, izstrādātājiem un vadītājiem.

• Apmācības vieglums – vai apmācība jauniem lietotājiem ir īsa un intuitīva.

• Ekonomiskums – vai sistēmas izmaksas ir efektīvas un resursu un ierobežojumu ietvaros.

• Efektivitāte – vai sistēma darbojas vislabākajā iespējamā veidā, lai sasniegtu biznesa vai organizatoriskos mērķus.

• Ražīgums - vai sistēma patērē resursus labākajā iespējamā veidā.




• Ātras attīstības rādītājs – vai laiks, kas ir nepieciešams projekta attīstībai, ir mazs, salīdzinot ar tā lielumu un sarežģītību.

• Elastīgums – vai sistēmu ir viegli modificēt un vai tai ir viegli pievienot vai dzēst komponentus.

• Funkcionalitāte – vai sistēma izpilda prasības.• Ieviešanas realitāte – vai vecās sistēmas

nomaiņa uz jauno sistēmu ir realizējama tehniskā, sociālā, ekonomiskā un organizatoriskā ziņā.

• Vājsaistes pakāpe – vai mijiedarbība starp apakšsistēmām ir tāda, ka tās var mainīt, neietekmējot pārējo sistēmu.




• Uzturēšanas vieglums – vai ir nepieciešama liela piepūle, lai sistēma darbotos apmierinoši un pildītu mainīgās prasības visā tās dzīves cikla laikā.

• Pārnesamība – vai informācijas sistēma var strādāt citā aparatūrā vai citās atrašanās vietās.

• Uzticamība – vai kļūdu rādītājs ir minimāls un izejas dati ir konsekventi un pareizi.

• Robustums – vai sistēma ir bezatteices (fail-safe) un bojājumpiecietīga (fault-tolerant).

• Drošība – vai informācijas sistēma ir droša pret ļaunprātīgu izmantošanu.




• Vienkāršība – vai ir minimizētas daudznozīmības un sarežģītības.

• Testējamība – vai sistēmu ir iespējams pilnībā testēt, lai samazinātu darbības kļūdas un lietotāju neapmierinātību.

• Savlaicīgums – vai informācijas sistēma veiksmīgi darbojas normālos, sakāpinātos un jebkādos citos apstākļos, vienmēr sniedzot nepieciešamo informāciju.

• Caurredzamība – vai lietotājiem ir iespējams noskaidrot, kas izraisīja noteiktas darbības.


©RTU, 2007

Organizāciju un informācijas Organizāciju un informācijas sistēmu arhitektūru orientēta sistēmu arhitektūru orientēta

projektēšanaprojektēšana4. tēma



Arhitektūru veidiArhitektūru veidi

Jonkers H., Lankhorst M.M., ter Doest H.W.L., Arbab F., Bosma H., Wieringa R.J., Enterprise architecture: Management tool and blueprint for the organisation, Sprinter Science + Business Media, LLC 2006

Informācijas arhitektūra

Procesu arhitektūra

Lietojumu arhitektūra Tehniskā arhitektūra

Produktu arhitektūra



Sowa un Zachman Sowa un Zachman arhitektūra



Federal EnterpriseFederal Enterprise arhitektūra arhitektūra

Veikuma atsauces modelis (PRM)

Biznesa atsauces modelis (BRM)

Pakalpojuma komponenšu atsauces modelis (SRM)

Datu atsauces modelis (DRM)

Tehniskās atsauces modelis (TRM)

- Ieejas, izejas un iznākumi

- Unikāli pielāgoti veikuma indikatori

- Biznesa līnijas

- Aģentūras, klienti, partneri

- Pakalpojuma apgabali, pakalpojuma tipi

- Biznesa un pakalpojuma komponenti

- Uz biznesu koncentrēta datu standartizācija

- Starpaģentūru informācijas apmaiņas

-Pakalpojumu komponentu interfeisi, savienojamība

- Tehnoloģijas, rekomendācijas

Uz

biz

nes

u v

irzī

ta p

ieej

aU

z kom

po

nen

tiem b

āzēta arhite

ktūra



Gartner EAGartner EA procesu modelis procesu modelis

Vides tendences

Biznesa stratēģija

Veidošana

Izstrādāt prasības

Izstrādāt principus

Izstrādāt modeļus

Nākotnes stāvokļa arhitektūra

Pārvaldīšana un pārzināšana

Pašreizējā stāvokļa arhitektūra

Spraugas aizvēršana

Dokumentēšana

Str

ād

āt

pie

arh

itekt

ūra

s



MITMIT uzņēmumu uzņēmumu arhitektūras nodevumiarhitektūras nodevumiCurrent State

System ContextDiagram

Key SystemsInventory

System Logical andPhysical Architecture

DiagramsContext

Services Matrix

Integration Inventory Systems on a Page

Business Process Flowsand Scenarios

Future State

Technology Standards Business Strategy Future State ServicesMatrix

Future State Logical Architecture Vision

Road Map

List of Initiatives

Prioritization Model

Architecture MigrationMaps

Short Term Roadmap

Long Term Roadmap

Timeless/ Evolutionary

Enterprise Data Model

Architectural ReviewProcess

IT Governance Process

ArchitecturalPrinciples

Uzņēmuma datu modelis

Arhitektūras apskata process

Arhitektūras principi

Sistēmas konteksta

diagrammaKonteksts

Pakalpojumu matrica

Integrācijas inventārs

Sistēmas loģiskās un fiziskās

arhitektūras diagrammas

Tehnoloģiju standarti

Biznesa stratēģijaNākotnes stāvokļa

pakalpojumu matrica

Galveno sistēmu inventārs

Sistēmas uz lapas

Biznesa procesu plūsmas un

scenāriji

IT pārvaldes process

Arhitektūras migrācijas kartes

Ierosinājumu saraksts

Prioratizācijas modelis

Īstermiņa ceļu karte

Ilgtermiņa ceļu karte

Nākotnes stāvokļa loģiskās arhitektūras redzējums

Bez laika/evolucionārs Pašreizējais stāvoklis Ceļa karte

Nākotnes stāvoklis


©RTU, 2007

Aģentu orientētas Aģentu orientētas metodoloģijasmetodoloģijas

5. tēma



Aģentu orientētas metodoloģijasAģentu orientētas metodoloģijas

• Aģentu orientētas metodoloģijas• GAIA - Wooldridge, M. Jennings,N.R., Kinny, D.” The Gaia Methodology for Agent-Oriented Analysis and Design” Journal of

Autonomous Agents and Multi-Agent Systems 3(3):(2000) 285-312 • Maze - DeLoach, S. A. Multiagent Systems Engineering: A Methodology and Language for Designing Agent Systems, Agent-

Oriented Information Systems '99 (AOIS'99), Seattle WA, 1 May 1999. • MESSAGE/UML - Evans, R. et all “Message: Methodology for Engineering Systems of Software Agents” Technical Information,

Project P907, http://www.eurescom.de/~pub-deliverables/P900-series/P907/TI2/p907ti2.pdf • AUML - Odell, J., Parunak,H.V.D., Bauer, B. “Extending UML for Agents” In G. Wagner, Y. Lesperance, and E. Yu, editors,

Proceedings of the AgentOriented Information Systems Workshop (AOIS) at the 17th National Conference on Artificial Intelligence, pages 3--17, Austin, Texas, 2000

• MAS CommonKADS - Carlos A. Iglesias, Mercedes Garijo, Jos´e C. Gonz´alez, and Juan R. Velasco “Analysis and design of multiagent systems using MAS-CommonKADS” In AAAI’97Workshop on Agent Theories, Architectures and Languages, Providence, RI, July 1997. ATAL. (An extended version of this paper has been published in INTELLIGENT AGENTS IV: Agent Theories Architectures, and Languages, Springer Verlag, 1998.

• Troops - J. Castro, M. Kolp and J. Mylopoulos. “A Requirements-Driven Development Methodology”, In Proc of the 13th International Conference on Advanced Information Systems Engineering CAiSE 01, Interlaken, Switzerland, June 4-8, 2001.

• DESIRE - Jonker, C.M., Klush,M., Treur, J. “Design of Collaborative Information Agents” In M.Klush and L. Kerschberg (eds.), Cooperative Information Agents IV, Proc. Of CIA 2000. Springer, pp:262-283.

• CoMoMas - Glaser, L. " Contribution to Knowledge Modelling in a Multi-Agent Framework" Ph.D. Thesis, L'Université henri Poincaré, Nancy I, France, November 1996

• Cassiopeia - Collinot, A. Drogoul, A. and Benhamou, P. " Agent Oriented Design of a Soccer Robot Team" In Proc. of the Second Intl. Conf. on Multi-Agent Systems, Kyoto, Japan, Dec 1996

• Adept - Jennings, N.R., Faratin, P., Normam,T.J., O'Brien, P., Odgers, B. and Alty, J.L. " Implementing a Business Process Management System Using ADEPT: A Real-World Case Study", Intl. Journal of Applied AI 14(5), 2000, 421-465

• MASB - Multi Agent Scenario Based Method Moulin,B. and Brassard, M. " A Scenario-Based Design Method and an Evironment for the Development of Multi-Agent Systems" In D.Lukose and C.Zahng, editors, First Australian Workshop on Distributed Artificial Intelligence Springer-Verlag, Germany 1996

• Agent Oriented Methodology for Enterprise Modelling - Kendall, E.A., Malkoun, M.T. and Jiang,C. "A Methodology for developing Agent Based Systems for Enterprise Integration" In D.Lukose and C.Zahng, editors, First Australian Workshop on Distributed Artificial Intelligence Springer-Verlag, Germany 1996

• The Prometeus Methodology Lin Padgham and Michael Winikoff. Prometheus: A Methodology for Developing Intelligent Agents. To appear in proceedings of the the Third International Workshop on Agent-Oriented Software Engineering, at AAMAS'02

• HIM Methodology M. Elammari and W. Lalonde An Agent-Oriented Methodology: High-Level View and Intermediate Models In Proceedings of the AOIS 1999 @ Caise

http://www.cs.toronto.edu/km/aometh/methodologies.htm



ADEPT videADEPT vide

http://users.ecs.soton.ac.uk/nrj/adept/

Mārketinga komanda

Dizaina komanda

Vienošanās protokols

Inteliģentais aģents

Juridiskais departaments

Realizācijas komanda

Informācijas dalīšana

Pakalpojumi

Pakalpojumu līmeņa vienošanās



Aģenta arhitektūraAģenta arhitektūra




Piemērs (1)Piemērs (1)




Piemērs (2)Piemērs (2)


Projektēšanas daļa

Klientu pārbaudes organizācijas

Klientu pakalpojumu

daļa

Juridiskais departaments

Kontroles departaments

Analizēt prasībasNoteikt cenu

Projektēt tīklu

Novērtēt klienta lielumu

Novērtēt klienta lielumu

Noteikt cenu un projektēt klienta tīklu

Juridiskais padoms

Dot juridisko padomu

Nodrošināt klienta cenas noteikšanu

Pārbaudīt klientu

Pārbaudīt klientu

Iegūt klienta prasības

Iegūt klienta informāciju

Identificēt pakalpojumu

ID pakalp. pras. profils

Noteikt cenu

Realizācija

Aģents

Uzdevums

Pakalp. uz piepras. Parasts pakalp.

Pakalp. bez viena Aģentūra



TROPOSTROPOS

http://www.troposproject.org/



Paolo Giorgini. Manuel Kolp. John Mylopoulos. Agent Oriented Software Development. In Proceedings of the 2nd Hellenic Conference on Artificial Intelligence (SETN-02). 2002.

SolīšanaSolīšana




Hierarhiskā līgšanaHierarhiskā līgšana




KooptācijaKooptācija



Kursa-eksāmena vadības situācijas izpēteKursa-eksāmena vadības situācijas izpēte

Marco Roveri. Specifying and Analyzing Early Requirements: Some Experimental Results.RE-2003, the 11th IEEE International Symposium on Requirements Engineering Monterey Bay, California U.S.A. 8th-12th September 2003


©RTU, 2007

Problēmu orientētas Problēmu orientētas metodoloģijasmetodoloģijas

6. tēma



http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html#Stage1

Problēmas īpašnieks

Problēmas risinātājs

Pievieno konfliktus starp personālu un funkciju

Atgriezeniskā saite kā diskusijas ar problēmas īpašnieku

Problēmas būtība tiek izdibināta, problēma identificēta, un problēmas īpašnieks tiek informēts par situāciju

Informē īpašnieku par problēmas situāciju, bet ne izstrādā iespējamos risinājumus

Organizācijas palīdzība kā ieeja

Analītiķis veic analīzi kā transformāciju

“Bagātā bilde” kā izeja

Vadītājs Lietotājs

Sistēma

Sistēma

Cilvēki Uzdevumi

Klimats Attiecības

Analītiķis

Elastīgā sistēmu metodoloģijaElastīgā sistēmu metodoloģija




Konkurents

Jauna tehnoloģija

Klients

PakalpojumiMateriāli

TirgusProdukti

Pašreizējā sistēma

Darbības rezultāti

Šella MF Bagātā bildeŠella MF Bagātā bilde




Šella MF pasaules skatījums uz apmācībuŠella MF pasaules skatījums uz apmācību

Vajadzības:

Labi apmācīts personāls ar ražošanas kompetenci.

Ražošanas kompetence citās funkcijās.

Apmācāmais Labi apmācīts personāls ar lietderīgu pieredzi

Citas funkcijas

Laiks

Notiekošie MF uzdevumi

Pakalpojumu nodrošināšana

Tehnoloģiju attīstība



Šella MF apmācības konceptuālais modelisŠella MF apmācības konceptuālais modelis




CATWOE skaidrojumsCATWOE skaidrojums

CATWOE skaidrojums ir sekojošs: C: Apmācītie; caur tiem uzņēmumsA: MF personālsT: Nepieciešamība pēc apmācītiem un pieredzējušiem cilvēkiem tiek piepildīta. W: Apmācība var notikt arī ar MF darba rūpīgu plānošanu, nodrošinot atbilstošu pieredzi. O: MF E: MF galvenie uzdevumiIevērojiet, ka šīs transformācijas pasaules skatījums īsteno apmācību caur pieredzi.

http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html



Apmācības sistēmas, kas darbojas pēc šī Apmācības sistēmas, kas darbojas pēc šī koncepta, saknes definīcijakoncepta, saknes definīcija

• MF piederoša un ar darbiniekiem

nokomplektēta sistēma, kura, atbildot uz pastāvīgu vajadzību pēc augstākas kvalitātes personāla, kas apkalpotu un vadītu Shell Group ražošanas procesus, un vajadzību pēc ražošanas kompetences citās funkcijās, attīsta un apmāca cilvēkus un nodrošina tiem pieredzi izmaksu efektīvā veidā, nepārkāpjot ierobežojumus, kurus uzliek MF galvenie uzdevumi pakalpojumu sniedzēja un tehnoloģijas veidā. http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html



Darbība modelī

Eksistē? Kā? Kas? Labi/slikti Alternatīvas?

Izveidot prasmju krātuvi

JāDiskusija un pārvaldes darbība

MF pārvalde, Shell Corporation's personāls

Labi Izpildītājs

Noteikt nepieciešamās darbības dabu

Jā

MF/Shell Co. diskusija, mainīgi formāla-neformāla

MF un Shell Co. cilvēki

Kopumā labi

Nav alternatīvas

Noteikt prasmju uzkrāšanas redzesloku un dziļumu

Ne formāli Slikti

Speciāli uzdevumi, uzdevumu iedarbīgums, regulāri atjaunota datubāze

http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html

Piedāvātās sistēmas salīdzinājums ar Piedāvātās sistēmas salīdzinājums ar realitātirealitāti



http://www.construction-innovation.info/images/pdfs/Research_library/ResearchLibraryA/Refereed_Conference_papers/Five_Case_Studies.pdf

Cits piemērs (1)Cits piemērs (1)

Mēs gribam izmantot projektu vēstures jaunos projektos

Projektu vēstures ir noderīgas

Pilnībā jārealizē projekta vēstures

ASAPProjektu vēstures mums

var nodrošināt priekšroc.

Nav realizācijas stratēģijas projektu

vēsturu pabeigšanai

Mūsu prioritāte ir projekta pabeigšanaLaiks ir nauda

Dažādas prioritātes

KM var palīdzēt realizēt un pārvaldīt

projektu vēstures

Formas Procedūras Datubāze

Atskaites

Cilvēku dati Klientu dati

Produktivitātes info Izmaksas

Iepriekšējie projekti IMS

Mēs beidzam projektu un esam pārāk aizņemti vēstures

pabeigšanai

Projektu vēstures mums nes maz

labuma

Datu bāzes pārdevēji

Atskaites

Projektēšanas komanda

Inženieru vadītājs

Projektēšanas vadītāji

Projekta komanda

Esošā struktūra

Konstruēšanas komanda

Projekta vadītājs

Augstākā vadība

VāktVākt

Kontrolēt

Augstākā vadība

Ekonomiskais

stāvoklis

Konkurenti

“Rich picture” projekta vēsturēm





• Projekta saknes definīcija• Sistēma, kas pieder inženieru vadītājam, kurš kopā

ar projektēšanas vadītājiem meklē iepriekšējo projektu datus, informāciju un zināšanas, kas ir noglabātas projektu vēsturēs, lai sagatavotu reālistisku iepriekšēju izpratni par projektu un piedāvātā procesa izmaksu novērtējumu un tad sagatavotu solījumu par projektu.




CATWOE• Klients: Augstākā vadība, Nākošie projektēšanas vadītāji,

Projektu vadītāji• Aktieri: Inženieru vadītājs, Projektēšanas vadītāji, Projekta

vadītāji, Konstruēšanas komanda• Transformācija: Zināšanas, procesi un tehnoloģijas kopā ar

informāciju par pagātnes projektiem, tiek lietotas, lai radītu un uzturētu projektu vēsturu krātuvi, kuru var izmantot, lai sagatavotu solījumu par jaunu projektu.

• Weltanschauung (kāpēc pūlēties?): Lai novērtētu iespēju izdarīt solījumu, ir nepieciešama laba izpratne par projektu, kura tiek balstīta iepriekšējo organizācijas pieredzi un zināšanām.

• Īpašnieks: Inženieru vadītājs• Vide: Konkurējoša, Kritiska kvalitātes, izmaksu un laika ziņā,

Sabiedrības un korporatīvie mērķi.http://www.construction-innovation.info/images/pdfs/Research_library/ResearchLibraryA/Refereed_Conference_papers/Five_Case_Studies.pdf



Cits piemērs (4)Cits piemērs (4)Projekta vadītāji – pašreizējie projekti

Industrijas progress

Potenciālie projekti Tehnoloģiju piegādātāji (iekšējie un ārējie)

Solījumi par jauniem projektiem Projektu vēstures

Iegūt specifiska projekta detaļas

vēstures izveidošanai

Attīstīt un uzturēt nepieciešamās

zināšanas

Attīstīt un izprast laicīgas

ievērošanas procesu

Iegūt un īstenot projektu vēstures

veidošanas tehnoloģiju

Pielietot projektu vēstures

Uzstādīt kritērijus, kas vajadzīgi, lai novērtētu projektu vēstures un

to pārvaldības realizāciju

Novērot un kontrolēt projektu vēstures

Izveidot projektu vēstures



©RTU, 2007

Biznesa procesu orientētas Biznesa procesu orientētas metodoloģijasmetodoloģijas

7. tēma



Galvenie jautājumi, uz kuriem atbild biznesa Galvenie jautājumi, uz kuriem atbild biznesa procesu modelēšanāprocesu modelēšanā

• Kāpēc vispār būvēt sistēmu• Kur tā būtu jāizvieto• Kā var noteikt, kāda funkcionalitāte ir

optimāla konkrētajai sistēmai • Kur vajadzētu lietot manuālās apstrādes • Kādos gadījumos problēmas risināšanai

vajadzētu apsvērt pašas organizācijas restrukturizāciju

Ref58 - Leffingwell D. and Widrig D. Managing Software Requirements: A Unified Approach, Addison-Wesley, 2000



Saistītās tēmas (Sistēmas)Saistītās tēmas (Sistēmas)**

• Produkta sistēma ir projekta vēlamais rezultāts, tas ir, produkta vai pakalpojuma “recepte”.

• Organizācijas sistēma sastāv no cilvēkiem, kuri strādā, lai radītu produkta vai pakalpojuma sistēmu, tas ir, indivīdi, grupas, komandas vai citas organizatoriskas vienības, kuras savā starpā ir saistītas ar ziņojumiem, atskaitēm utt.

• Rīku sistēma attēlo tehnoloģijas, kuras izmanto cilvēki, lai paveiktu darbu, kas nepieciešams produkta vai sistēmas izstrādei.

* Ref33 - Browing T.R., Fricke E.,Negel H., Key Concepts in Modeling Product Development Processes, Systems Engineering, Vol.9, No. 2, 2006, 107pp.



Daži procesu modeļu pielietojumiDaži procesu modeļu pielietojumi (1)* (1)*

• Ļauj koncentrēties uz vērtību pievienojošām aktivitātēm nevis prātošanu, no kurienes iegūt ieejas datus un uz kurieni sūtīt izejas datus.

• Nodrošina uzskatāmību un situācijas pārredzamību darba spēkam. Tādā veidā katrs darbinieks var redzēt savu vietu visā uzņēmumā.

• Nodrošina labu lēmumu pieņemšanu, ko veic pareizie cilvēki pareizajā laikā, izmantojot pareizo informāciju.

• Saistības tiek izpildītas paredzamā, atkārtojamā, konsekventā veidā.

• Atbalsta kompleksu procesu izprašanu un apgūšanu.

* Ref33 - Browing T.R., Fricke E.,Negel H., Key Concepts in Modeling Product Development Processes, Systems Engineering, Vol.9, No. 2, 2006, 110pp.



Daži procesu modeļu pielietojumi Daži procesu modeļu pielietojumi (2)*(2)*

• Gūst labumu no iegūtajām zināšanām par to, kā darīt konkrētas lietas

• Nodrošina karkasu zināšanu organizēšanai par darbu un mijiedarbībām (zināšanu pārvaldība)

• Palīdz plānot un pārvaldīt darbu precīzi un pārliecinoši

• Palīdz izvairīties no neveiksmīgiem paņēmieniem, kas apturēja līdzīgus procesus iepriekš

• Ir kopēja vārdnīca darba un rezultātu apspriešanai• Veicina vienotu projekta izpildes pieeju. Katrs

projekta dalībnieks var ar biznesa procesa modeli salīdzināt savu iedomāto modeli un vai nu pielāgoties tam vai ierosināt diskusiju par potenciālajām problēmām.

* Ref33 - Browing T.R., Fricke E.,Negel H., Key Concepts in Modeling Product Development Processes, Systems Engineering, Vol.9, No. 2, 2006.



Daži procesu modeļu pielietojumi Daži procesu modeļu pielietojumi ((33)*)*

• Nodrošina vadlīnijas kaut kā paveikšanai, attiecībā pret ko var tikt mērīti uzlabojumi.

• Lieto kopēju, vislabāko pieeju, kad cilvēki dara vienādas lietas dažādos projektos vai programmās

• Dara iespējamas potenciālu procesa izmaiņu “what if” analīzi

• Dara iespējamus novatoriskus procesu uzlabojumus (reinženierija u.c.)

• Pārliecina klientus, ka viņu vajadzību apmierināšanai tiek lietota saprātīga, pierādīta pieeja

• Pārliecina auditorus, ka darbs tiek darīts atbilstoši attiecīgajiem standartiem (piemēram, ISO 9001)

Ref33 - Browing T.R., Fricke E.,Negel H., Key Concepts in Modeling Product Development Processes, Systems Engineering, Vol.9, No. 2, 2006, 111pp.



Biznesa procesa modelis

Objektamodelis

Biznesalikumi

Aktieri ...

Biznesa procesu modeļu tipi (1)Biznesa procesu modeļu tipi (1)

• Viens pats biznesa process

• Biznesa process kā daļa no organizācijas vides

Biznesa procesa modelis



Biznesa procesu tipiBiznesa procesu tipi – BPMN ( – BPMN (22))

• Privāti (iekšēji) biznesa procesi – iekšēji procesi specifiskā organizācijā

• Abstrakti (publiski) biznesa procesi – mijiedarbība starp privātu biznesa procesu un citu procesu vai dalībnieku

• Sadarbības (globāli) biznesa procesi – mijiedarbība starp divām vai vairākām biznesa vienībām



Privāts processPrivāts process

Aizgūts no BPMN rokasgrāmatas

Nosaka, ka pasūtījums ir

pabeigts

Pārbauda pieteicēja ierakstu

Nosaka darbības plāna

ieguvumu

Apstiprina vai noraida

darbības plānu

Informē pieteicēju par apstiprinājumu

vai noraidījumu



Abstrakts processAbstrakts process

Pacients

Saņem ārsta

pieprasījumu

Pieraksta vizīti

Uzzina simptomus

Nosūta recepti

Saņem zāļu

pieprasījumu

Nosūta zāles

1) Es gribu redzēt ārstu5) Aiziet pie ārsta

6) Es jūtos slims

8) Paņem savas zāles un vari iet

9) Man vajag manas zāles

10) Te būs Jūsu zāles




Sadarbības processSadarbības process

Saņem ārsta

pieprasījumu

Pieraksta vizīti

Uzzina simptomus

Nosūta recepti

Saņem zāļu

pieprasījumu

Nosūta zāles

1) Es gribu redzēt ārstu5) Aiziet pie ārsta

6) Es jūtos slims 8) Paņem savas zāles un

vari iet

9) Man vajag manas zāles

10) Te būs Jūsu zāles

Nosūta ārsta

pieprasījumu

Saņem vizīti

Nosūta simptomus

Saņem recepti

Nosūta zāļu

pieprasījumu

Saņem zāles

Pac

ien

tsA

dm

inis

trat

ors

/Ā

rsts




Biznesa procesu tipi (3)Biznesa procesu tipi (3)

• “As-is” modelis – procesa modelis patreizējā situācijā

• “To-be” modelis – projektējamais procesa modelis



““As-is” modeļa piemērsAs-is” modeļa piemērs

Trkman P., Groznik A., Measurement of SupplyChain Integration Benefits, Interdisciplinary Journal of information, Knowledge, and Management, 2006



““To-be” modeļa piemērsTo-be” modeļa piemērs

Trkman P., Groznik A., Measurement of SupplyChain Integration Benefits, Interdisciplinary Journal of information, Knowledge, and Management, 2006



Galvenās veidnes (frameworks)Galvenās veidnes (frameworks)

• APQC veidne• Value Chain veidne • Centers of Excellence (balstīta uz

procesu struktūru)• MIT (Masačusetas Tehnoloģiskā

institūta) veidne



APQC APQC veidneveidne

DARBA PROCESI

VADĪBAS UN UZTURĒŠANAS PAKALPOJUMI

Attīstīt vīziju un stratēģiju

Radīt un attīstīt produktus un pakalpojumus

Pārdot produktus un pakalpojumus

Piegādāt produktus un pakalpojumus

Vadīt klientu apkalpošanu

Attīstīt un vadīt cilvēku kapitālu

Vadīt informācijas tehnoloģijas

Vadīt finanšu resursus

Iegūt, būvēt un vadīt īpašumus

Vadīt vides veselību un drošību

Veidot ārējas attiecības

Pārvaldīt zināšanas, veikt uzlabojumus un sekot līdzi izmaiņām


©RTU, 2007

Pakalpojumu orientētas Pakalpojumu orientētas metodoloģijas un pakalpojumu metodoloģijas un pakalpojumu

orientētas arhitektūrasorientētas arhitektūras8.tēma



Pakalpojumu orientēta arhitektūra ir pakalpojumu krājums, kuri savā starpā sazinās. Pakalpojumi ir patstāvīgi un nav atkarīgi no cita pakalpojuma konteksta vai stāvokļa. Tie darbojas dalītu sistēmu arhitektūrās.

www.dmreview.com/resources/glossary.cfm



Nav vienota viedokļa par pakalpojumu orientētas arhitektūras definīciju, izņemot tās tiešo tulkojumu - tā ir arhitektūra, kuras galvenais darbības princips balstās uz pakalpojumu orientāciju. Pakalpojumu orientācija raksturo arhitektūru, kas biznesa procesu un lietotāju atbalstam lieto vāji saistītus pakalpojumus. Tīkla resursi pakalpojumu orientētas arhitektūras vidē ir pieejami kā neatkarīgi pakalpojumi, kuriem var piekļūt bez zināšanām par tiem pamatā esošās platformas realizāciju. Šos konceptus var pielietot biznesā, programmatūrā un citās ražotāja/patērētāja tipa sistēmās.

http://en.wikipedia.org/wiki/Service-oriented_architecture



Pakalpojumu orientēta arhitektūra (SOA) un tās Pakalpojumu orientēta arhitektūra (SOA) un tās komponenteskomponentes

Ref 28

Uz lietotāju centrētie slāņi

Uz sistēmu centrētie slāņi

Prezentācija

Pielietojums

Procesi

Pakalpojumi

Komponentes

Objekti

Apgabala modelis

Prasības

Īpašības

Klases

Ris

ināj

uma

apga

bals

Pro

blē

mu

apg

abal

s



Saikne starp biznesa procesa un Saikne starp biznesa procesa un pakalpojuma funkcionalitātipakalpojuma funkcionalitāti

Biznesa process

Pakalpojums

Atbilst ? Ir daļa no ? Ir vienāds ar ?

Biznesa process

Pakalpojums

Biznesa process

Pakalpojums



Ref66 - Practical Guide to Enterprise Architecture by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo

Pakalpojuma piegādātājs Reģistrācija

Patērētājs

Pielieto endpoint, lai izmantotu pakalpojumu

Reģistrējas

1. solis: Pakalpojuma piegādātājs reģistrē kontrakta un endpoint informāciju

Dod man pakalpojumu, kas dara XYZ

2. solis: Pakalpojuma patērētājs saņem sarakstu ar piemērotiem kontraktiem

3. solis: Iekšējais process labākā pakalpojuma izvēlei

Atgriež piemēroto pakalpojumu sarakstu

Iegūst kontraktu šī pakalpojuma Acme Service’s realizācijai

4. solis: Pakalpojuma patērētājs iegūst kontraktu un izveido klientu (saistās) šim pakalpojumam

Iegūst endpoint

SOA kontraktu mehānismsSOA kontraktu mehānisms



Pakalpojuma dimensijas - Redzesloks - Redzesloks

Redzesloks – nosaka organizatoriskās robežas, kurās pakalpojumam ir jādarbojas. – Piemēram, pakalpojumus, kuri ir paredzēti darbībai

uzņēmumā, izmanto procesi un citi pakalpojumi visā uzņēmumā. Otrā skalas pusē ir pakalpojumi, kurus izmanto tikai viens lietojums vai organizatoriskā grupa.

– Kāpēc visi pakalpojumi nav pieejami visā uzņēmumā? Tāpēc, ka eksistē cieša saistība starp pakalpojuma redzesloku un pakalpojuma pārvaldīšanas, uzturēšanas un uzlabošanas izmaksām. Jo vairāk lietotāji to izmanto, jo augstākas ir izmaksas.

Rosen Mike, BPM and SOA, www.bptrends.com, 2006



Pakalpojuma dimensijas – Īpašumtiesības – Īpašumtiesības

Īpašumtiesības – nosaka, kura organizatoriskā vienība ir atbildīga par pakalpojuma uzturēšanu. – Pakalpojumu orientētā arhitektūrā tas attiecas ne tikai

uz vienkāršu sistēmas uzturēšanu, bet arī uz visu pakalpojuma dzīves ciklu.

– Daži sarežģīti īpašumtiesību jautājumi: • Kā prioritizēt un izpildīt dažādu lietotāju dažādus

uzlabojumu pieprasījumus? • Cik daudz pakalpojuma versijas vienlaicīgi tiks

uzturētas? • Cik liela saderība ar iepriekšējām versijām būs

nepieciešama? • Cik ilgi tiks uzturētas iepriekšējās versijas?




Pakalpojuma dimensijas - Granularitāte - Granularitāte

Granularitāte – apraksta pakalpojuma izmēru. Pakalpojuma izmēri netiek mērīti kilobaitos vai koda daudzumā, bet gan paveiktās biznesa funkcijas apjomā vienā ieejas/izejas ziņojuma apmaiņā

– Maza pakalpojuma piemērs – pakalpojums paņem

pasta indeksu kā ieeju un atgriež pilsētas nosaukumu kā izeju.

– Liela pakalpojuma piemērs – pakalpojums paņem apdrošināšanas lietojumu kā ieeju un izveido izcenojumu kā izeju.




Pakalpojuma dimensijas - Konstrukcija - Konstrukcija

Konstrukcija – raksturo to, kā pakalpojums ir ticis realizēts.

– Piemēram, tas var būt realizēts kā kods (mazas granularitātes

pakalpojums) vai tas var sastāvēt no citiem pakalpojumiem.– Ir arī citas ļoti atšķirīgas pakalpojuma konstrukcijas iespējas,

kuras ir rūpīgi jāapsver. • Pakalpojums īstenībā var būt “pakalpojuma iesaiņojums

(wrapper)” ap kādu eksistējošu funkciju vai datiem. Tas tiek saukts par “integrācijas pakalpojumu”.

• Pakalpojumu var nodrošināt biznesa partneris, piemēram, spēju noteikt pārvadājuma atrašanās vietu, izmantojot tā izsekošanas numuru. Tas tiek saukts par “ārēju pakalpojumu”.




Pakalpojuma tipu hierarhijaPakalpojuma tipu hierarhijaBiznesa process

Biznesa pakalp. Biznesa pakalp.

Apgabala pakalp. Apgabala pakalp.

Ārējs pakalp.

Servisa pakalpojums

Integrācijas pakalp.




Pakalpojumu tipi (1)Pakalpojumu tipi (1)

• Biznesa pakalpojums – pakalpojums, kas nodrošina augstu biznesa vērtības granularitāti pakalpojuma patērētājiem visā uzņēmumā. Funkcijas un informācija ir ļoti līdzīgas biznesa procesos izmantotajai semantikai un sintaksei. Parasti biznesa pakalpojums sastāv no vairākiem detalizētākiem pakalpojumiem.

• Apgabala pakalpojums – viduslīmeņa pakalpojums, kas nodrošina biznesa funkcionalitāti specifiskā biznesa apgabalā. Apgabala pakalpojumi nodrošina kopēju funkcionalitāti biznesa pakalpojumu konstruēšanā, bet tie nav pieejami pakalpojuma patērētājiem ārpus biznesa apgabala.




Pakalpojumu tipi (2)Pakalpojumu tipi (2)• Servisa pakalpojums – Zema līmeņa

pakalpojums, kas nodrošina atsevišķu biznesa funkcionalitāti. Servisa pakalpojumus parasti lieto visā uzņēmumā, piemēram, adrešu pārbaude. Tos visbiežāk nodrošina un pārvalda centrāli.

• Integrācijas pakalpojums – pakalpojums, kas apvieno funkcijas un/vai datus no eksistējošām sistēmām un atklāj tos kā pakalpojumu. Pakalpojuma granularitāte ir kompromiss starp uzņēmuma modeļa vēlmēm un eksistējošās sistēmas iespējām. Integrācijas pakalpojumi parasti ietver pārveidošanu starp uzņēmuma modeli un lietojuma modeli.

• Ārējais pakalpojums – pakalpojums, kuru veic trešās puses piegādātājs, piemēram, kredītu pārbaude vai pārvadājumu izsekošana.




Uzņēmuma pakalpojumu kopne ar pieslēgtiem Uzņēmuma pakalpojumu kopne ar pieslēgtiem tālvadības pakalpojumiemtālvadības pakalpojumiem

Papazodlou & Co



Uzņēmuma pakalpojumu kopnes iespējasUzņēmuma pakalpojumu kopnes iespējas (potenciālās)(potenciālās)

• Esošo labo īpašību pastiprināšana• Pakalpojumu sazināšanās spējas• Dinamisku savienojumu spējas• Uz temats/saturs bāzētas maršrutēšanas iespējas• Galapunktu ar dažādām pakalpojumu īpašībām atklāšanas

iespējas• Integrācijas iespējas• Transakcijas iespējas• Uzticamas ziņošanas iespējas• Drošības iespējas• Ilgstošu procesu un transakciju iespējas• Iespēju pārvaldīšana un novērošana• Mērogojamība

Papazodlou & Co



http://www.early-aspects.net/

UML paplašinātā klasifikatora ar paplašinājuma punktiem UML paplašinātā klasifikatora ar paplašinājuma punktiem un punktu griezumiem un punktu griezumiem AOSD/UCAOSD/UC piemērs piemērs




Banka

Maksāt rēķinu Reģistrēt transporta līdzekli

Transporta līdzekļa īpašnieks

<<pēc>>

<<pirms>>

Konfidencialitāte Integritāte

UN

Drošība

Drošība daļēji pārklāj lietošanas piemērus




CosmosCosmos interešu skati un modeļa elementi: interešu skati un modeļa elementi: pārskatspārskats

• Interešu skati– Loģiskais

• Klasifikācijas• Klases• Instances• Īpašības• Tipi

– Fiziskais• Kolekcijas• Instances• Atribūti

– Predikāti– Attiecības– Grupas– Predikāti

• // apakštipi nav sīki izstrādāti

• Attiecības– Kategoriskas– Klasifikācijas– Vispārināšanas– Instances– Raksturojošas– Aktualitātes– Attiecinājuma– Dalības

• Skaidrojumi– Devums– Motivācija– Loģiskā realizācija– Loģiskā kompozīcija– Loģiskās prasības

• Fiziskie faktori– Fiziskā saistība– Fiziskās prasības

• Kartēšana– Kartēšanas saistība– Fiziskā realizācija




Interešu skatu telpa, attēlota kā CORE Interešu skatu telpa, attēlota kā CORE vairākdimensiju kubsvairākdimensiju kubs

Interešu

skats 2

Interešu skats 1

Interešu skats 3

Interešu skats n




Meta sakaru telpaMeta sakaru telpa

Meta interešu skatu telpa

Sistēmas telpa

Prasības




AORE procesu modelisAORE procesu modelis




Dažādi interešu skati arhitektūrāDažādi interešu skati arhitektūrā

Mainīgums

Pieejamība

Izm

aksa

s

Info

rmā

cija

s iz

gū

šan

a

Arhitektūra



AOREC pamatprocessAOREC pamatprocess





AspektsB

AspektsA

KomponentsA

Arhitektūras aspekti un šķērsgriezuma interfeisiArhitektūras aspekti un šķērsgriezuma interfeisi

Apzīmējumi:

Aspekta komponents

Komponents

Šķērsgriezuma interfeiss

Normāls interfeiss

Šķērsgriezumi



Topošais projektēšanas processTopošais projektēšanas process



©RTU, 2007

Informācijas sistēmu Informācijas sistēmu metodoloģiju izvēles un metodoloģiju izvēles un kombinēšanas metodes.kombinēšanas metodes.

10.tēma



Metodoloģijas komponentesMetodoloģijas komponentes

Metodoloģijas komponentes precizē:– Kā projekts tiks sadalīts posmos– Kādi uzdevumi tiks izpildīti katrā posmā– Kādi rezultāti tiks iegūti– Kad un kādos apstākļos tie tiks izpildīti– Kādi ierobežojumi tiks uzlikti– Kurus cilvēkus vajadzētu iesaistīt– Kā projekts būtu jāvada un jākontrolē– Kādus atbalsta rīkus varētu pielietot



Metodoloģijas piemērošana praksei (1)Metodoloģijas piemērošana praksei (1)

• Metodoloģija var aptveres konkrētība var svārstīties no produkta, kas apraksta katru posmu un uzsākto uzdevumu, līdz izplūdušai skicei, kurā ir īsi aprakstīti tikai pamatprincipi.

• Metodoloģija var nosegt ļoti atšķirīgus izstrādes procesa apgabalus – no augsta līmeņa stratēģisku un organizatorisku problēmu risināšanas līdz mazas datorsistēmas ieviešanai.

• Metodoloģija var pārklāt konceptuālas lietas vai fiziskas projektēšanas procedūras, vai visu starpposmu amplitūdu.



Metodoloģijas piemērošana praksei (2)Metodoloģijas piemērošana praksei (2)

• Metodoloģija var būt radīta pielietošanai specifiskiem problēmu tipiem noteiktā vidē vai industrijā, vai arī tā var būt visaptveroša metodoloģija vispārīgiem mērķiem.

• Metodoloģiju var potenciāli izmantot jebkurš, vai arī tā ir paredzēta labi apmācītiem speciālistiem vai lietotājiem, kas veido paši savus lietojumus.

• Metodoloģijas visu norādīto uzdevumu veikšanai var būt nepieciešami daudzi cilvēki, vai arī metodoloģijai tādi uzdevumi var vispār nebūt.

• Metodoloģija var iekļaut un var neiekļaut rīkus un rīku kopas.



Tradicionālās metodes Spējās (Agile) metodes

Nepieciešamība, prasība, lietojumu gadījums, scenārijs

Lietotāja stāsts, sāga, eposs

Fāze, iterācija Izrāviens, sprints

Neplānotas darba lietas Nepadarīts darbs

Pārstrādāšana, pārprojektēšana, labošana, sīkums

Pārstrāde

Rezultātu analīze, iztaujāšana, projekta beigu apskats

Retrospektīvs

Progresa sanāksme Stāvus sanāksme, pulcēšanās

Produktivitāte Ātrums

Risks, problēma, ierobežojums Šķērslis

Komanda Bars, šūnaKruchten, P., (2007), “Voyage in the Agile Memeplex”, ACM Queue, Volume 5, No. 5, pp. 42.

Tradicionālo un spējo metožu Tradicionālo un spējo metožu salīdzinājumssalīdzinājums



EKD-CMMEKD-CMM uzņēmuma attēlojuma uzņēmuma attēlojuma slāņislāņi

Barrios, J., Nurcan, S., “Model Driven Architectures for Enterprise Information Systems”



EKD-CMMEKD-CMM Ceļa karte Ceļa karte

Barrios, J., Nurcan, S., “Model Driven Architectures for Enterprise Information Systems”



Informācijas sistēmas projektēšanas Informācijas sistēmas projektēšanas metodoloģijas izvēles un lietošanas metodoloģijas izvēles un lietošanas

processprocess (Carroll 2003)(Carroll 2003)

Projekta raksturojums

Izvēlētā metodoloģija

Metodoloģijas adaptēšanas

process

Izvēlētāmetodoloģija

Aizgūts no Samuli Pekkola



Aizgūts no Samuli Pekkola

Piemērs (Piemērs (CARE CARE metodoloģija)metodoloģija)



http://www.cs.jyu.fi/~jpt/doc/thesis/ime-3_1.html

Metožu inženierija (1)Metožu inženierija (1)

ME līmenis

ISD līmenis

Lieto

Uztver

Metametodes un CAME rīki

Definēt redzespunktu

ISD objektu sistēma

LietoISD metodes un CASE rīki

Definēt redzespunktu

AttēlotObjektu sistēma

Uztver

Piemērot

Piemērot

IS specifikācijas



Metožu inženierija (2)Metožu inženierija (2)




Divi stāvokļu meta-modeļiDivi stāvokļu meta-modeļi


INFORMĀCIJAS SISTĒMU METODOLOĢIJAS (DSP404)

Documents

Transcript of INFORMĀCIJAS SISTĒMU METODOLOĢIJAS (DSP404)