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

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

INFORMĀCIJAS SISTĒMU METODOLOĢIJAS
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> INFORMĀCIJAS SISTĒMU METODOLOĢIJAS Asoc. prof., Dr.sc.ing. Mārīte Kirikova Rīgas Tehniskā universitāte Datorzinātnes un informācijas tehnoloģijas fakultāte Lietišķo datorsistēmu institūts Sistēmu teorijas un projektēšanas katedra

Priekšmeta pamatdati Priekšmeta pieteicējs: Mārīte Kirikova
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Priekš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 uzdevumi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Priekš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 uzdevumi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Priekšmeta mērķi un uzdevumi Uzdevumi: Izprast saistību starp organizācijas funkcionālo, vadības un informācijas sistēmu. Apgūt dažādas domāšanas struktūras informācijas sistēmu projektēšanā (dažādu metodoloģiju pamatus) Gūt priekšstatu par metodoloģiju novērtēšanas kritērijiem un integrēšanas iespējām Gūt priekšstatu par piemērotas metodoloģijas izvēli atbilstoši informācijas sistēmas projektēšanas situācijai

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums>
Pamatlitetratūra Avison D. and Fitzgerald Information Systems Development: Methodologies, Techniques, Tools, 3ed.m McGraw-Hill, 2003.

Papildliteratū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ārdi informācijas sistēma sistēmu inženierija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Atslē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ēmas Informācijas sistēmu ontoloģija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pamattē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.

Informācijas sistēmu ontoloģija
1. tēma

Informācijas sistēmu definīcijas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Informā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 :1997: Information processing system, together with associated organisational resources, such as humans, technical and financial resources, that provides and distributes information ISO/IEC :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āšanas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Dati, informācija, zināšanas Mērķis Dati, informācija, zināšanas Dati, informācija, zināšanas IS ārējā vide Dati IS Dati IS ārējā vide Dati Informācijas sistēma un tās datorizētā daļa atbalsta organizācijas mērķus Prasī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 definīcija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Informācijas sistēmu metodoloģijas definī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, Wand un Weber ontoloģija (1)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (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ā.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (2) Ī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).

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (3) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (4) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (5) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (6) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (7) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (8) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (9) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (10) 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ā.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (11) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (12) 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ā.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Bunge, Wand un Weber ontoloģija (13) 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 elementi Valodas konstrukcija Izskaidrojums Realitātes tips 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 Developing a meta model for the Bunge-Wand-Weber ontological constructs, Michael Rosemann, Peter Green, 2001

Lieta, īpašība, klase, veids un atribūts
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Lieta, īpašība, klase, veids un atribūts Developing a meta model for the Bunge-Wand-Weber ontological constructs, Michael Rosemann, Peter Green, 2001

Lieta, savienošana pāros, sistēma, kompozīcija un vide
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Lieta, savienošana pāros, sistēma, kompozīcija un vide Developing a meta model for the Bunge-Wand-Weber ontological constructs, Michael Rosemann, Peter Green, 2001

Īpašību apakštipi <Pasniedzēja v. uzvārds. Priekšmeta nosaukums>
Developing a meta model for the Bunge-Wand-Weber ontological constructs, Michael Rosemann, Peter Green, 2001

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

Informācijas sistēmu un informācijas sistēmu projektu veidi
2.tēma

Informācijas sistēmu veidi (1)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Informācijas sistēmu veidi (2) 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ēmas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pā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

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Informācijas sistēmu veidi (3) 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 veidi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Informā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ības veidi (1) Padomdevēja līdzdalība
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Līdzdalības 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ā.

Līdzdalības veidi (2) Pārstāvnieciska līdzdalība
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Līdzdalības veidi (2) 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.

Līdzdalības veidi (3) Vienprātības līdzdalība
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Līdzdalības veidi (3) 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 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).

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

Praktiskā sarežģītība
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Praktiskā 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 sistēmu tipiem
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Sarežģītība attiecībā pret dažādiem sistē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 adekvāta (1)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Iemesli, kāpēc teorētiskā sarežģītība nav 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 adekvāta (2)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Iemesli, kāpēc teorētiskā sarežģītība nav 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āpes
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> IT 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)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> IS kvalitātes rādītāji (2) 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ā.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> IS kvalitātes rādītāji (3) Ā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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> IS kvalitātes rādītāji (4) 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> IS kvalitātes rādītāji (5) 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.

Organizāciju un informācijas sistēmu arhitektūru orientēta projektēšana
4. tēma

Arhitektūru veidi Produktu arhitektūra Informācijas arhitektūra
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Arhitektūru veidi Produktu arhitektūra Informācijas arhitektūra Procesu arhitektūra 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 Lietojumu arhitektūra Tehniskā arhitektūra

Sowa un Zachman arhitektūra
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Sowa un Zachman arhitektūra

Federal Enterprise arhitektūra
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Federal Enterprise arhitektūra Veikuma atsauces modelis (PRM) Ieejas, izejas un iznākumi Unikāli pielāgoti veikuma indikatori Biznesa atsauces modelis (BRM) Biznesa līnijas Aģentūras, klienti, partneri Pakalpojuma komponenšu atsauces modelis (SRM) Uz biznesu virzīta pieeja Uz komponentiem bāzēta arhitektūra Pakalpojuma apgabali, pakalpojuma tipi Biznesa un pakalpojuma komponenti Datu atsauces modelis (DRM) Uz biznesu koncentrēta datu standartizācija Starpaģentūru informācijas apmaiņas Tehniskās atsauces modelis (TRM) Pakalpojumu komponentu interfeisi, savienojamība Tehnoloģijas, rekomendācijas

Gartner EA procesu modelis
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Gartner EA procesu modelis Biznesa stratēģija Vides tendences Veidošana Izstrādāt prasības Izstrādāt principus Izstrādāt modeļus Nākotnes stāvokļa arhitektūra Strādāt pie arhitektūras Spraugas aizvēršana Pārvaldīšana un pārzināšana Pašreizējā stāvokļa arhitektūra Dokumentēšana

MIT uzņēmumu arhitektūras nodevumi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> MIT uzņēmumu arhitektūras nodevumi Bez laika/evolucionārs Pašreizējais stāvoklis Ceļa karte Sistēmas loģiskās un fiziskās arhitektūras diagrammas Uzņēmuma datu modelis Sistēmas konteksta diagramma Konteksts Arhitektūras migrācijas kartes Biznesa procesu plūsmas un scenāriji Galveno sistēmu inventārs Pakalpojumu matrica Ierosinājumu saraksts Arhitektūras apskata process Integrācijas inventārs Sistēmas uz lapas Prioratizācijas modelis Arhitektūras principi Nākotnes stāvoklis Nākotnes stāvokļa pakalpojumu matrica Īstermiņa ceļu karte Tehnoloģiju standarti Biznesa stratēģija IT pārvaldes process Ilgtermiņa ceļu karte Nākotnes stāvokļa loģiskās arhitektūras redzējums

Aģentu orientētas metodoloģijas
5. tēma

Aģentu orientētas metodoloģijas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Aģ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) 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, 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 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 Springer, pp: 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, 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 Caise

Informācijas dalīšana
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> ADEPT vide Mārketinga komanda Dizaina komanda Inteliģentais aģents Vienošanās protokols Pakalpojumi Pakalpojumu līmeņa vienošanās Informācijas dalīšana Realizācijas komanda Juridiskais departaments

Aģenta arhitektūra http://users.ecs.soton.ac.uk/nrj/adept/
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Aģenta arhitektūra

Piemērs (1) http://users.ecs.soton.ac.uk/nrj/adept/
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Piemērs (1)

Noteikt cenu un projektēt klienta tīklu
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Piemērs (2) Projektēšanas daļa Noteikt cenu Novērtēt klienta lielumu Analizēt prasības Kontroles departaments Novērtēt klienta lielumu Projektēt tīklu Juridiskais padoms Klientu pārbaudes organizācijas Dot juridisko padomu Noteikt cenu un projektēt klienta tīklu Juridiskais departaments Pārbaudīt klientu Nodrošināt klienta cenas noteikšanu Pārbaudīt klientu Realizācija Aģents Uzdevums Pakalp. uz piepras. Parasts pakalp. Pakalp. bez viena Aģentūra Klientu pakalpojumu daļa Iegūt klienta prasības ID pakalp. pras. profils Identificēt pakalpojumu Iegūt klienta informāciju Noteikt cenu

TROPOS http://www.troposproject.org/
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> TROPOS

Solīšana <Pasniedzēja v. uzvārds. Priekšmeta nosaukums>
Paolo Giorgini. Manuel Kolp. John Mylopoulos. Agent Oriented Software Development. In Proceedings of the 2nd Hellenic Conference on Artificial Intelligence (SETN-02)

Hierarhiskā līgšana Paolo Giorgini. Manuel Kolp. John Mylopoulos. Agent Oriented Software Development. In Proceedings of the 2nd Hellenic Conference on Artificial Intelligence (SETN-02)

Kooptācija <Pasniedzēja v. uzvārds. Priekšmeta nosaukums>
Paolo Giorgini. Manuel Kolp. John Mylopoulos. Agent Oriented Software Development. In Proceedings of the 2nd Hellenic Conference on Artificial Intelligence (SETN-02)

Kursa-eksāmena vadības situācijas izpēte
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Kursa-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

Problēmu orientētas metodoloģijas
6. tēma

Elastīgā sistēmu metodoloģija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Elastīgā sistēmu metodoloģija Pievieno konfliktus starp personālu un funkciju Problēmas īpašnieks Problēmas risinātājs Sistēma Vadītājs Lietotājs Analītiķis Cilvēki Uzdevumi Sistēma Klimats Attiecības Analītiķis veic analīzi kā transformāciju “Bagātā bilde” kā izeja Organizācijas palīdzība kā ieeja 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

Šella MF Bagātā bilde Pakalpojumi Materiāli Klients Jauna tehnoloģija Darbības rezultāti Pašreizējā sistēma Konkurents Produkti Tirgus

Šella MF pasaules skatījums uz apmācību
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Šella MF pasaules skatījums uz apmācību Apmācāmais Labi apmācīts personāls ar lietderīgu pieredzi Vajadzības: Labi apmācīts personāls ar ražošanas kompetenci. Ražošanas kompetence citās funkcijās. Citas funkcijas Notiekošie MF uzdevumi Pakalpojumu nodrošināšana Tehnoloģiju attīstība Laiks

Šella MF apmācības konceptuālais modelis
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Šella MF apmācības konceptuālais modelis

CATWOE skaidrojums CATWOE skaidrojums ir sekojošs:
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> CATWOE skaidrojums CATWOE skaidrojums ir sekojošs: C: Apmācītie; caur tiem uzņēmums A: MF personāls T: 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 uzdevumi Ievērojiet, ka šīs transformācijas pasaules skatījums īsteno apmācību caur pieredzi.

Apmācības sistēmas, kas darbojas pēc šī koncepta, saknes definīcija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Apmācības sistēmas, kas darbojas pēc šī koncepta, 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ā.

Piedāvātās sistēmas salīdzinājums ar realitāti
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Piedāvātās sistēmas salīdzinājums ar realitāti 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 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

Cits piemērs (1) “Rich picture” projekta vēsturēm
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Cits piemērs (1) Atskaites Datu bāzes pārdevēji Cilvēku dati Klientu dati Produktivitātes info Izmaksas Iepriekšējie projekti IMS Projekta komanda Mēs beidzam projektu un esam pārāk aizņemti vēstures pabeigšanai Projektēšanas komanda Esošā struktūra Projektu vēstures mums nes maz labuma Mēs gribam izmantot projektu vēstures jaunos projektos Projekta vadītājs Projektu vēstures ir noderīgas Formas Procedūras Datubāze Atskaites Nav realizācijas stratēģijas projektu vēsturu pabeigšanai Projektēšanas vadītāji Konstruēšanas komanda Pilnībā jārealizē projekta vēstures ASAP Vākt Projektu vēstures mums var nodrošināt priekšroc. Vākt Augstākā vadība Mūsu prioritāte ir projekta pabeigšana Kontrolēt Laiks ir nauda Inženieru vadītājs Ekonomiskais stāvoklis Augstākā vadība Dažādas prioritātes KM var palīdzēt realizēt un pārvaldīt projektu vēstures Konkurenti “Rich picture” projekta vēsturēm

Cits piemērs (2) Projekta saknes definīcija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Cits piemērs (2) 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.

Cits piemērs (3) 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.

Cits piemērs (4) Projekta vadītāji – pašreizējie projekti
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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) 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 Iegūt specifiska projekta detaļas vēstures izveidošanai 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 Pielietot projektu vēstures Izveidot projektu vēstures Solījumi par jauniem projektiem Projektu vēstures

Biznesa procesu orientētas metodoloģijas
7. tēma

Galvenie jautājumi, uz kuriem atbild biznesa procesu modelēšanā
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Galvenie jautājumi, uz kuriem atbild biznesa 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)*
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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 pielietojumi (1)*
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Daži procesu modeļu pielietojumi (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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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.

<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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 procesu modeļu tipi (1)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Biznesa procesu modeļu tipi (1) Viens pats biznesa process Biznesa process kā daļa no organizācijas vides Biznesa procesa modelis Objekta modelis Biznesa likumi Biznesa procesa modelis Aktieri ...

Biznesa procesu tipi – BPMN (2)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Biznesa procesu tipi – BPMN (2) 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 process Aizgūts no BPMN rokasgrāmatas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Privāts process 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 Aizgūts no BPMN rokasgrāmatas

Abstrakts process Pacients Aizgūts no BPMN rokasgrāmatas
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Abstrakts process Pacients 8) Paņem savas zāles un vari iet 10) Te būs Jūsu zāles 6) Es jūtos slims 1) Es gribu redzēt ārstu 5) Aiziet pie ārsta 9) Man vajag manas zāles Saņem ārsta pieprasījumu Pieraksta vizīti Uzzina simptomus Nosūta recepti Saņem zāļu pieprasījumu Nosūta zāles Aizgūts no BPMN rokasgrāmatas

Administrators/Ārsts
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Sadarbības process 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 Pacients 8) Paņem savas zāles un vari iet 6) Es jūtos slims 10) Te būs Jūsu zāles 1) Es gribu redzēt ārstu 5) Aiziet pie ārsta 9) Man vajag manas zāles Saņem ārsta pieprasījumu Pieraksta vizīti Uzzina simptomus Nosūta recepti Saņem zāļu pieprasījumu Nosūta zāles Administrators/Ārsts Aizgūts no BPMN rokasgrāmatas

Biznesa procesu tipi (3)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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ērs
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> “As-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ērs
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> “To-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)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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 veidne DARBA PROCESI VADĪBAS UN UZTURĒŠANAS PAKALPOJUMI
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> APQC veidne DARBA PROCESI Attīstīt vīziju un stratēģiju Radīt un attīstīt produktus un pakalpojumus Piegādāt produktus un pakalpojumus Pārdot produktus un pakalpojumus Vadīt klientu apkalpošanu VADĪBAS UN UZTURĒŠANAS PAKALPOJUMI 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

Pakalpojumu orientētas metodoloģijas un pakalpojumu orientētas arhitektūras
8.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.

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.

Pakalpojumu orientēta arhitektūra (SOA) un tās komponentes
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojumu orientēta arhitektūra (SOA) un tās komponentes Prezentācija Uz lietotāju centrētie slāņi Apgabala modelis Problēmu apgabals Pielietojums Prasības Procesi Risinājuma apgabals Pakalpojumi Īpašības Komponentes Uz sistēmu centrētie slāņi Klases Objekti Ref 28

Saikne starp biznesa procesa un pakalpojuma funkcionalitāti
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Saikne starp biznesa procesa un pakalpojuma funkcionalitāti Biznesa process Biznesa process Biznesa process Atbilst ? Ir daļa no ? Ir vienāds ar ? Pakalpojums Pakalpojums Pakalpojums

SOA kontraktu mehānisms
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> SOA kontraktu mehānisms Pakalpojuma piegādātājs Reģistrējas Reģistrācija 1. solis: Pakalpojuma piegādātājs reģistrē kontrakta un endpoint informāciju Dod man pakalpojumu, kas dara XYZ Pielieto endpoint, lai izmantotu pakalpojumu Atgriež piemēroto pakalpojumu sarakstu 2. solis: Pakalpojuma patērētājs saņem sarakstu ar piemērotiem kontraktiem 3. solis: Iekšējais process labākā pakalpojuma izvēlei 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 Patērētājs Iegūst endpoint Ref66 - Practical Guide to Enterprise Architecture by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo

Pakalpojuma dimensijas - Redzesloks
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojuma dimensijas - 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,

Pakalpojuma dimensijas – Īpašumtiesības
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojuma dimensijas – Ī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? Rosen Mike, BPM and SOA,

Pakalpojuma dimensijas - Granularitāte
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojuma dimensijas - 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. Rosen Mike, BPM and SOA,

Pakalpojuma dimensijas - Konstrukcija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojuma dimensijas - 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”. Rosen Mike, BPM and SOA,

Pakalpojuma tipu hierarhija
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Pakalpojuma tipu hierarhija Biznesa process Biznesa pakalp. Biznesa pakalp. Apgabala pakalp. Apgabala pakalp. Servisa pakalpojums Integrācijas pakalp. Ārējs pakalp. Rosen Mike, BPM and SOA,

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. Rosen Mike, BPM and SOA,

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. Rosen Mike, BPM and SOA,

Uzņēmuma pakalpojumu kopne ar pieslēgtiem tālvadības pakalpojumiem
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Uzņēmuma pakalpojumu kopne ar pieslēgtiem tālvadības pakalpojumiem Papazodlou & Co

Uzņēmuma pakalpojumu kopnes iespējas (potenciālās)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Uzņēmuma pakalpojumu kopnes iespējas (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

Aspektu orientētas metodoloģijas
9. tēma

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

Drošība daļēji pārklāj lietošanas piemērus
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Banka Transporta līdzekļa īpašnieks Maksāt rēķinu Reģistrēt transporta līdzekli <<pēc>> <<pirms>> Konfidencialitāte Integritāte UN Drošība Drošība daļēji pārklāj lietošanas piemērus

Cosmos interešu skati un modeļa elementi: pārskats
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Cosmos interešu skati un modeļa elementi: pārskats Interešu skati Loģiskais Klasifikācijas Klases Instances Īpašības Tipi Fiziskais Kolekcijas Atribūti Predikāti Attiecības Grupas // 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 vairākdimensiju kubs
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Interešu skatu telpa, attēlota kā CORE vairākdimensiju kubs Interešu skats 1 Interešu skats n Interešu skats 2 Interešu skats 3

Meta interešu skatu telpa
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Meta sakaru telpa Meta interešu skatu telpa Sistēmas telpa Prasības

AORE procesu modelis http://www.early-aspects.net/
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> AORE procesu modelis

Dažādi interešu skati arhitektūrā
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Dažādi interešu skati arhitektūrā Mainīgums Izmaksas Arhitektūra Informācijas izgūšana Pieejamība

AOREC pamatprocess http://www.early-aspects.net/
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> AOREC pamatprocess

Arhitektūras aspekti un šķērsgriezuma interfeisi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Arhitektūras aspekti un šķērsgriezuma interfeisi AspektsA Apzīmējumi: Aspekta komponents Komponents AspektsB Šķērsgriezuma interfeiss Normāls interfeiss KomponentsA Šķērsgriezumi

Topošais projektēšanas process
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Topošais projektēšanas process

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

Metodoloģijas komponentes
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Metodoloģ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)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> 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ālo un spējo metožu salīdzinājums
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Tradicionālo un spējo metožu salīdzinājums 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, šūna Kruchten, P., (2007), “Voyage in the Agile Memeplex”, ACM Queue, Volume 5, No. 5, pp. 42.

EKD-CMM uzņēmuma attēlojuma slāņi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> EKD-CMM uzņēmuma attēlojuma slāņi Barrios, J., Nurcan, S., “Model Driven Architectures for Enterprise Information Systems”

EKD-CMM Ceļa karte Barrios, J., Nurcan, S., “Model Driven Architectures for Enterprise Information Systems”

Informācijas sistēmas projektēšanas metodoloģijas izvēles un lietošanas process (Carroll 2003) Projekta raksturojums Izvēlētā metodoloģija Metodoloģijas adaptēšanas process Aizgūts no Samuli Pekkola

Piemērs (CARE metodoloģija)
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Piemērs (CARE metodoloģija) Aizgūts no Samuli Pekkola

Metametodes un CAME rīki ISD metodes un CASE rīki
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Metožu inženierija (1) Lieto Metametodes un CAME rīki Definēt redzespunktu ME līmenis Uztver Piemērot ISD objektu sistēma Lieto ISD metodes un CASE rīki Definēt redzespunktu ISD līmenis Piemērot Uztver IS specifikācijas Attēlot Objektu sistēma

Metožu inženierija (2)

Divi stāvokļu meta-modeļi
<Pasniedzēja v. uzvārds. Priekšmeta nosaukums> Divi stāvokļu meta-modeļi

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

Similar presentations

Presentation on theme: "INFORMĀCIJAS SISTĒMU METODOLOĢIJAS (DSP404)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "INFORMĀCIJAS SISTĒMU METODOLOĢIJAS (DSP404)"— Presentation transcript:

Similar presentations

About project

Feedback