You are on page 1of 31

Konvencije modelovanja poslovnih

procesa

Datum: 19.09.2017

1
Sadržaj
ARIS Konvencije Projekta............................................................................................. 3
1.1 Konvencije modelovanja ........................................................................................... 3
1.1.1 Jezik i pismo ............................................................................................................................ 3
1.1.2 Korišteni tipovi modela .......................................................................................................... 3
1.1.3 Korišteni objekti ...................................................................................................................... 4
1.1.4 Korišteni atributi ..................................................................................................................... 7
1.1.5 Kopiranje objekata ................................................................................................................ 10
1.1.6 Upotreba funkcija, događaja i operatora u EPC modelima............................................... 11
1.1.7 Upotreba petlje ...................................................................................................................... 15
1.1.8 Započinjanje EPC-a sa organizacijskom jedinicom .......................................................... 15
1.1.9 Modelovanje pod-procesa .................................................................................................... 16
1.1.10 Imenovanje kopije dokumenata........................................................................................... 17
1.1.11 Razmeštaj elemenata ............................................................................................................ 18
1.2 Grafičke konvencije ................................................................................................. 19
1.2.1 Osnovna grafička prilagodba .............................................................................................. 19
1.2.2 Formati teksta i fontovi ........................................................................................................ 19
1.2.3 Izgled modela ........................................................................................................................ 19
1.3 Pravila za upotrebu imena objekata (naming conventions NC) ............................ 25
1.4 Konvencije za rad s projektnom bazom podataka ................................................. 30

2
ARIS Konvencije Projekta

1.1 Konvencije modelovanja


Konvencije modelovanja koriste se kako bi se standardizovala i osigurao kvalitet celog
repozitorijuma (baze podataka) poslovnih procesa. Stoga je nužno da ih se pridržavaju svi
koji modeluju u ARIS-u.

1.1.1 Jezik i pismo

ARIS je višejezični alat, što znači da se informacije o modelima i objektima mogu održavati
na više jezika istovremeno.
Jezik koji se koristi za dokumentovanje je latinični srpski. Po potrebi, moguće je modele
prevesti na ćirilični srpski, kao dodatan jezik u ARIS-u.

1.1.2 Korišteni tipovi modela

ARIS sadrži veliki broj modela koje je moguće upotrebiti. Da bi se smanjila složenost, izvršen
je odabir najvažnijih modela kojima će se raditi na Projektu:

ARIS pogled tip modela obav. mog.


• Value added chain diagram - VAC

• Product/service tree - PST


procesni pogled
• Event driven process chain - EPC

• Function allocation diagram – FAD

• Quick model

• Information carrier diagrami

podatkovni pogled
• Application system type diagram

funkcijski pogled
• Organizational chart

organizacijski pogled

3
Objašnjenje:
1. VAC model se koristi za modelovanje procesa na višim nivoima, tako da je procesna
mapa i svi modeli procesa do EPC modelovana kroz VAC tip modela i ona je
obavezna.
2. PST modeli se koriste za opis proizvoda i usluga koji su predmet poslovanja
organizacije.
3. EPC modeli se koriste za modelovanje poslovnih procesa na nižim nivoima.
4. FAD modeli se koriste za detaljnije modelovanje jedne funckije u okviru procesa.
5. Quick model je model koji se koristi da bi se napravila ARIS kuća organizacije.
6. Information carrier dijagrami se koriste za definisanje svih dokumenata koji učestvuju
u procesima (bilo elektronskih ili papirnih).
7. Technical terms model se koristi za opis dokumenta i podataka koji se nalaze na
samom dokumentu
8. App system type modeli se koriste za definisanje aplikacija i rasporeda aplikacija na
serverima.
9. Organizational chart – modelovanje organizacione strukture.

1.1.3 Korišteni objekti

Odabir iz dostupnih objekata radi se, takođe, u svrhu smanjenja složenosti modelovanja.
Kako bi se osigurao kvalitet modelovanja definisani filter pokazuje samo odabrane objekte u
pojedinim tipovima modela:

ARIS-pogled tip modela simbol tip objekta simbol obav. mog.

Value added Value added


Funkcija
chain diagram Value-added chain chain
procesni pogled

Organizaciona
Organizaciona
jedinica
jedinica (nivo
Organizational unit (Organizational
sektora i iznad)
unit)
Organizaciona
Organizaciona
jedinica
Organizational unit jedinica (ispod
(Organizational
nivoa sektora)
unit)

4
Proizvod/usluga
Product Proizvod/usluga
(Product/Service)

Product/ Proizvod/usluga
Proizvod/usluga
service tree Product (Product/Service)

Service Usluga (Service) Usluga

Object
Quick model Brzi objekt

Event driven
Aktivnost Funkcija
process chain Funkcija
(Function)
(EPC)

Sistemska
Funkcija
System function (actual) funkcija (System
(Function)
function(actual))

Događaj Događaj
Event

Operator “i”

Operator
“ekskluzivno ili”

Operator
“inkluzivno ili”

Interfejs
Process interface Funkcija
(Process
(Function)
interface)

5
Organizaciona
Organizational unit jedinica (ispod
nivoa sektora)

Role Posao (Role) Role

Group Grupa (Group) Grupa (Group)

Spoljašna osoba
External person Osoba (Person) (External
person)

Radno mesto
Position Position
(Position)

Aplikacija
Application
Application (Application
system type System Type
System Type)

Klaster podataka
(Cluster data Klaster (Cluster)
Cluster
model)

Uređaj
Uređaj
(fotokopir...)
(Operating
Operating resource (Operating
Resource)
Resource)

Baza podataka
Baza podataka
File (Information
(File)
carrier)

Dokument na
Dokument
papiru (Information
Document (Document)
carrier)

Elektronski Elektronski
dokument dokument

6
(Information (Electronic
Electronic document
carrier) document)

Registrator
Registrator
(Information
Folder (Folder)
carrier)

CD
(Information CD
CD-ROM
carrier)

DVD
(Information DVD
DVD
carrier)

Printer
Printer (Information Printer
carrier)

Telefon
Telefon
Telephone (Information
(Telephone)
carrier)

Faks uređaj
Faks uređaj
(Information
Fax (fax)
carrier)

E-mail
E-mail (Information E-mail
carrier)

Internet
(Information Internet
Internet
carrier)

Intranet
(Information Intranet
Intranet
carrier)

Spoljna pošta
Spoljna pošta
(Information
Letter (letter)
carrier)

7
Spoljni dokument
General
General documentation (Information
documentation
carrier)

Podatkovni i funkcijski pogled i Function allocation diagram koriste iste simbole kao i EPC
dijagrami.

Organizaciona
Organizational
Organizational unit jedinica (nivo
organizacijski chart
sektora i iznad)
pogled
Organizaciona
Organizational unit jedinica (ispod
nivoa sektora)

Role
Posao (Role) Role

Group Grupa (Group) Grupa (Group)

Spoljašna
Spoljašna osoba
External person osoba (External
(External Person)
person)

Radno mesto
Position Position
(Position)

D attribute (ERM)

Atribut Atribut
(erm attribute) (D attribute)

Relationship type Vrsta veze Vrsta veze


(Relationship (Relationship
type) type)

8
1.1.4 Korišteni atributi

Atributi označavaju posebne karakteristike, te mogu biti dodeljeni modelu, objektu ili funkciji.
Koristiće se samo neki od mogućih atributa, a ukoliko se pojavi potreba za dodatnim
informacijama o modelu, objektu ili operatoru, dodatni atributi mogu se naknadno uključiti.

1.1.4.1 Atributi modela

Pomoću atributa modela moguće je opisati karakteristike modela. Pored atributa koje ARIS
automatski generiše tokom neke promene na modelu, za tačniju sliku modela potrebno je
uneti i druge atribute. Kako bismo dobili osnovnu informaciju o modelu, bez detaljnijeg ulaska
u sadržaj opisan modelom, nužno je uneti obavezne atribute. Ostali (mogući) atributi unosiće
se prema potrebi.

tip atributa primedba obav. mog. auto


Name koristiti kratka i precizna imena, koristiti jasne
skraćenice
Full name puni naziv modela
Detailed description detaljni opis sadržaja modela
Link 1/Title1 veza s spoljnim dokumentom ili aplikacijom
Link 2/Title 2 veza s spoljnim dokumentom ili aplikacijom
Link 3/Title 3 veza s spoljnim dokumentom ili aplikacijom
Link 4/Title 4 veza s spoljnim dokumentom ili aplikacijom
Identifier oznaka grupe korisnika koja je kreirala model
Creator ARIS korisnik koji je kreirao model
Last user zadnji ARIS korisnik koji je promenio model
Last change vreme zadnje promene modela
Type tip modela
Valid from početak period validnosti modela

1.1.4.2 Atributi objekata

Atributi objekata služe za detaljan opis objekata. Svakom tipu objekta dodeljena je lista
atributa, koji moraju/mogu biti unešeni od strane korisnika baze podataka ili su automatski
generisani.

9
Tip atributa Primjedba Obav. Mog. Auto
Name ime objekta
Detailed description detaljniji opis objekta (1-2 rečenice su
dovoljne da se objekt, ukoliko je potrebno,
detaljnije opiše)
Link 1/Title1 veza s spoljnim dokumentom ili aplikacijom
Link 2/Title 2 veza s spoljnim dokumentom ili aplikacijom
Link 3/Title 3 veza s spoljnim dokumentom ili aplikacijom
Link 4/Title 4 veza s spoljnim dokumentom ili aplikacijom
Number of broj zaposlenih u organizacionim jedinicama
employees ili radnim mestima
Identifier oznaka grupe korisnika koja je kreirala objekt
Creator ARIS korisnik koji je kreirao objekt
Last user zadnji ARIS korisnik koji je promenio objekt
Last change vreme zadnje promene objekta
Type tip objekta

Konvencije za unos atributa objekata važeće su za sve tipove objekata za koje nije drugačije
navedeno.

1.1.4.3 Atributi funkcija

Tip atributa Primjedba Obav. Mog. Auto


Daily/weekly/monthly/annually koliko će puta funkcija biti aktivirana u
frequency nekom vremenskom periodu
Average/maximum/minimum koliko je prosečno/maksimalno/minimalno
processing time vremena potrebno za izvršenje funkcije
Average/maximum/minimum koliko je prosečno/maksimalno/minimalno
wait time vrijeme čekanja da bi započelo izvršenje
funkcije
Average/maximum/minimum koliko je prosečno/maksimalno/minimalno
orientation time vremena potrebno za pripremu izvršenja
funkcije
Average/maximum/minimum kolika je prosečna/maksimalna/minimalna
total costs ukupna cena koštanja funkcije
Probability verovatnoća izvršenja funkcije

10
1.1.4.4 Tipovi veza

Radi pojašnjavanja mogućih veza između organizacionih elemenata i funkcija, potrebno je


način korištenja veze prikazati u modelu. S obzirom da je veza tipa “carries out” najčešće
korištena, nije je potrebno posebno isticati na modelu. Za ostale tipove veza potrebno je
upisati način korištenja veze u atribut “ Detailed description ” i istaknuti ga na modelu.

Tip veze Korištenje Načini korištenja Značenje


(connection role)
Carries out Izvršava Samostalno obavlja Stvara trošak koji se
funkciju proporcionalno
(procenat) deli
između svih radnih
mesta koja su
»carries out« vezom
vezani za tu funkciju
Contributes to Učestvuje Učestvuje u Stvara trošak koji se
obavljanju funkcije dodaje trošku
radnog mesta koje
izvršava funkciju
Must be informed about Mora da bude Ne učestvuje u Ne stvara trošak
informisan obavljanju funkcije,
ali rezultat funkcije
utiče na radno
mesto

1.1.4.5 Atributi veza

Atributi veza preciznije opisuju veze. Svim tipovima veza dodeljeni su isti atributi, koji mogu
biti unešeni od strane korisnika baze podataka ili su automatski generisani.

Tip atributa Primjedba Obav. Mog. Auto


Identifier oznaka grupe korisnika koja je kreirala objekt
Type tip veze

11
1.1.5 Kopiranje objekata

Napomena: U ARIS-u postoje definicije objekata (svaki objekt ima samo jednu definiciju) i
pojave objekata (slike ili simboli u grafičkom interfejsu kojih može biti više za isti objekt).

Pravila za upotrebu: Occurrence kopija


Definicija Upotreba
Occurrence kopije kreiraju novu pojavu objekta koji je u Koristiti za objekt koji se nalazi
modelu prikazan određenim simbolom. Definicija objekta drugde u istom ili drugom modelu,
postoji samo jednom u bazi podataka, a može imati onoliko a ima iste karakteristike (atribute).
pojava koliko je potrebno. Primer: aplikacija, organizaciona
Na taj su način modifikacije i izmene atributa objekata u jedinica, poslovni pojam...
nekom modelu vidljive na svim pojavama objekta.
Pažnja: Funkcije, događaji i operatori ne kopiraju se kao occurence kopije
Izuzeci: vezni element među procesima (process interface), početni događaj modela (treba biti isti
s zadnjim događajem prethodnog modela), početni i završni događaji pridruženog modela (trebaju
biti isti kao i u nadređenom modelu).

Pravila za upotrebu: Definition kopija


Definicija Upotreba
Definition kopije omogućuju da početni objekt bude kopiran sa Koristi se za kreiranje novog
svim svojim karakteristikama (atributima) kreirajući novu objekta sličnog postojećem.
definiciju objekta u bazi podataka.
Promene atributa početnog (izvornog) objekta nemaju efekta
na kopiju, i obrnuto.
Pažnja: Koristiti za funkcije, događaje i operatore, čak i kad imaju identična imena!
(ovo je pravilo nužno poštovati, kako bismo mogli ustanoviti troškove procesa/sprovesti simulaciju;
u ovu svrhu, posebne vrednosti, kao što su trošak, vreme, frekvencija... moraju biti dodeljeni
funkcijama, događajima, operatorima.)
Izuzeci: vidi izuzetke prethodnog pravila

12
1.1.6 Upotreba funkcija, događaja i operatora u EPC modelima

Pojedinačni poslovni procesi mogu se shvatiti kao sled funkcija (zadataka/aktivnosti).


Događaji određuju koje je stanje ili uslov iniciralo funkciju i koje stanje definiše izvršenje
funkcije. Za svaku su funkciju inicijalni, odnosno početni, te završni događaj obavezni.

U načelu svaki EPC mora započeti bar jednim događajem i završiti bar jednim
događajem. Samo je tako moguće garantovati definiciju tačnih uslova koji su doveli do
početka procesa kao i situacije koja je usledila po završetku procesa. Samo tačna definicija
stanja procesa čini mogućim povezivanje procesnih lanaca koji su modelovani odvojeno ili
postojećem procesnom lancu nastaviti tok. Krajnji rezultat procesa je početni događaj
sledećeg procesa u lancu.

Svi EPC modeli moraju zadovoljavati sled događaj-funkcija-događaj-funkcija-... odnosno, niti


u jednoj grani procesa ne smeju da se pojave dve funkcije ili dva događaja sledno.

Funkcije mogu biti inicirane ili završiti s nekoliko događaja.

Operatori (rules) se koriste kako bi se prikazala kombinacija početnih i rezultujućih veza u


EPC modelima.
“AND” operator (tok procesa mora ići svim naznačenim pravcima)
“exclusive OR” operator (tok procesa se nastavlja samo jednim od više mogućih pravaca)
“inclusive OR” operator (tok procesa se nastavlja barem jednim od više pravaca)

13
Pravila: AND operator (I)

Funkcija se može izvršiti tek kad se dogode svi


predviđeni događaji.

Izvršenje funkcije rezultovaće svim predviđenim


događajima.

Događaj će uslediti tek pošto su sve funkcije izvršene.

Nakon događaja moraju uslediti sve predviđene


funkcije.

14
Pravilo: Exclusive OR operator (ekskluzivno ILI)

Samo nakon jednog od ovih događaja uslediće


funkcija.

Nakon izvršenja funkcije dogodiće se samo jedan od


mogućih događaja.

Događaj će uslediti nakon izvršenja samo jedne od


funkcija.

Metodološki nije dozvoljeno: Događaj ne može


doneti odluku!! Odluku kojim od mogućih puteva
treba poći može doneti samo funkcija.

15
Pravilo: Inclusive OR operator (inkluzivno ILI)

Barem jedan od predviđenih događaja mora prethoditi


funkciji.

Nakon izvršenja funkcije dogodiće se bar jedan od


predviđenih događaja.

Događaj će biti posledica izvršenja bar jedne od


funkcija.

Metodološki nije dozvoljeno: Događaj ne može


doneti odluku!! Odluku kojim od mogućih puteva
treba poći može doneti samo funkcija.

16
Pažnja:
Samo jedna ulazna ili jedna izlazna veza mogu biti modelovane ispred /iza funkcije ili
događaja. Za modelovanje povratne veze (loop) obavezna je upotreba XOR operatora.

Pažnja:
Grananje procesa mora biti zatvoreno istom vrstom operatora kojom je bilo
započeto.Upotreba petlje

Ako se u procesu pojavljuje rekurzivna petlja, moguće ju je modelovati na dva načina:

1. S Loop Event objektima

Petlje se u pravilu modeluju uz pomoć Loop Eventa, koji moraju da budu Occurence
kopije.

Slika: Modelovanje petlje uz pomoć Loop Eventa

2. Bez Loop Event objekata

Ako se u petlji nalazi jedna ili dve funkcije, a pogotovo ako se u procesu nalazi
nekoliko petlji, petlje je moguće modelovati i bez Loop eventa, kako velik broj Loop
eventa ne bi doveo do nepreglednosti modela.

17
1.1.7 Započinjanje EPC-a organizacionom jedinicom

Svaki EPC dijagram treba u prvoj funkciji imati organizacionu jedinicu u kojoj se proces
odvija. Nakon toga nije više potrebno evidentirati organizacione jedinice sve dok proces ne
pređe u drugu organizacionu jedinicu. Tada je potrebno ponovo staviti u model novu
organizacionu jedinicu gde se proces nastavlja.

Event

Organizaciona jedinica
u kojoj se odvija proces

Application system
Function Position
type

Event

Slika: Početak EPC-a organizacionom jedinicom

18
1.1.8 Povezivanje modela process interface-om

Dva EPC modela se povezuju process interface simbolom. Ti simboli moraju imati
assignment na povezani EPC. Zadnji event prethodnog modela mora biti occurrence kopija
prvog događaja u povezanom procesu - EPC dijagramu (zadnji događaj prethodnog modela
mora biti prvi događaj narednog modela).

Slika: Proces interfejs između dva modela

1.1.9 Modelovanje podprocesa

Ako je funkciju je moguće razložiti u više aktivnosti (funkcija), one se mogu smestiti u
zaseban model. Umesto funkcije se stavi Process interface objekat i na njega se stavlja
assignment na model koji predstavlja podproces. Prvi događaj iz podprocesa je occurence
kopija zadnjeg događaja pre razložene funkcije iz glavnog procesa, a poslednji je occurence
kopija prvog događaja posle razložene funkcije u glavnom procesu. Ako se podproces odvija
u drugoj organizacionoj jedinici, na Proces interface se, dodatno, veže objekat
Organizacione jedinice u kojoj se subproces izvršava.

19
1.1.10 Imenovanje kopije dokumenata

Ako se u procesu navodi da je neki dokument kopija, onda ga treba imenovati kao Kopija +
originalni naziv dokumenta.

20
1.1.11 Razmeštaj elemenata

Objekti se na levu stranu funkcije vežu sledećim redosledom odozgo prema dole: Aplikacije,
resursi, ulazni dokumenti. S desne strane funkcije, uvek se vežu organizacione jedinice,
zatim radna mesta, i izlazni dokumenti.

Application system
Organizational unit
type

Function Position
Product/Service

Document
Electronic document

Document

Slika: Razmeštaj elemenata

21
1.2 Grafičke konvencije
1.2.1 Osnovno grafičko prilagođavanje

Kako bi se osiguralo da modelovanje bude unificirano/standardizovano, potrebno je pratiti


neke osnovne grafičke postavke.

Modelovaće se prema sledećim konvencijama: Objekti su u modelima poravnati prema mreži


uz razmak između objekata od 5 tačaka.

1.2.2 Formati teksta i fontovi

Četiri glavna formata teksta će biti upotrijebljeni u modelima u ARIS-u, a namenjeni su


određenoj svrsi:

naziv font stil veličina upotreba


standard arial standard 10 imena objekata, atributi
naslov arial naslov 18 zaglavlja, prezentacije
broj radnika arial standard 10 broj radnika u
organizacionom
dijagramu

Tabela 9: formati teksta i fontovi

1.2.3 Izgled modela

1.2.3.1 Organizational chart

Organizational chart (organizacioni dijagram) ima hijerarhijsku strukturu (stablo). Model


počinje s najvišom organizacionom jedinicom na vrhu, te se zatim spušta prema nižim
jedinicama, na više hijerarhijskih nivoa, do najnižeg.

1.2.3.2 Event driven process chain (EPC)

EPC (vidi Sliku 3) tip modela koristi se da bismo opisali procese u njihovom hronološkom
nizu. Osnovni objekti su funkcije i događaji. EPC model započinje s najmanje jednim
događajem. Objekti se dalje postavljaju od vrha prema dole (top-down). Događaji i funkcije
slažu se vertikalno. Ako je tok procesa razgranat pomoću nekog operatora, (AND, OR,
XOR), grane koje slede nakon operatora moraju biti modelovane paralelno. Preporuka je da
se grane koje završavaju pre ostalih smeste na desnu stranu.

22
Slika 1: Izgled modela tipa EPC

Organizacione jedinice, radna mesta, te drugi organizacioni objekti postavljaju se funkcijama


s desne strane. Objekti koji predstavljaju ulaz bilo koje vrste (npr. aplikacije, uređaji)
postavljaju se s leve strane, objekti koji predstavljaju izlazni podatak smešteni su s desne
strane funkcije.
Aplikacije i organizacioni objekti postavljaju se na vrh svoje strane, a dokumenti na dno. Ako
ima više organizacionih objekata oni se postavljaju odozgo prema dole na način da se
odgovorniji postave iznad manje odgovornih.

23
Application system
type
Position

Function
Product/Service
Document

Electronic document

Slika: Raspored objekata oko funkcije u EPC modelu

1.2.3.3 Povezivanje objekata

Svi objekti moraju da budu povezani međusobnim vezama. Standardna veza mora da
počinje od sredine jednog objekta do sredine drugog objekta. Sve veze moraju da budu
povučene što je moguće ravnije, a ako imaju prelom on treba da bude na sredini između dva
objekta.

Slika: Povezivanje objekata

1.2.3.4 Klasterizacija organizacionih jedinica

24
Ukoliko se neka aktivnost (funkcija) odvija u više organizacionih delova (istovremeno ili u
jednom od nekoliko mogućih organizacioniih jedinica), radi preglednosti modela takve
organizacione delove moguće je klasterizovati.

Slika: Klasterizacija organizacionih jedinica

1.2.3.5 Slanje i prosleđivanje dokumenata

Slanje i prosleđivanje dokumenata modeluje se tako da se sa desne strane funkcije modeluju


redom:
- Lica koja šalju ili prosleđuju dokumenat
- Dokumenat
- Lica koja primaju dokumenat
Funkcija slanja ili prosleđivanja mora u imenu sadržavati reči Slanje ili Prosleđivanje:
- Ako se dokumenti šalju izvan organizacije obavezno se koristi izraz »Slanje«
- Ako se dokumenti šalju unutar organizacije obavezno se koristi izraz »Prosleđivanje«

Event
Position

Function Document

Position

Event

Slika: Slanje i prosleđivanje dokumenata

25
1.3 Pravila za upotrebu imena objekata (naming conventions NC)

Pravilo NC 1 : Upotreba malog i velikog slova

Prva reč u imenu objekta uvek se piše velikim slovom.


Primer:

Ukoliko se u nazivu objekta nalazi puni naziv drugog objekta, naziv drugog objekta piše se
početnim velikim slovom.
Primer:

Pravilo NC 2: Upotreba redova u tekstu

Novi red pri pisanju imena objekata obično se upotrebljava poštujući sledeća pravila:

• Pri prelasku u novi red, u prethodnom redu se ne ostavlja razmak između reči.

• Termini koji se pri nazivanju koriste trebali bi stati u širinu objekta. Rastavljanje reči nije
dopušteno!

• Ukoliko je moguće, ime objekta ne bi trebalo prelaziti granice (veličinu) objekta.

• Dužina imena objekta ne bi smela prelaziti četiri reda (maksimalno je dozvoljeno 56


znakova).

Pravilo NC 3: Odvajanje reči

ARIS razmake (praznine), prelaske u novi red ili crtice za razdvajanje shvata kao znakove
koje menjaju ime objekta! Ovo se takođe odnosi i na upotrebu malih/velikih slova.

26
Kako bi se omogućila normalna upotreba objekata, izrazi i notacija moraju biti jedinstveni.
Potrebno je posebno pripaziti kod korištenja specijalnih znakova (zagrade, razmaci, prelasci
u novi red, …). Samo na ovaj način moguća je razumljiva, tačna i svrhovita upotreba ARIS-a.

Primer:
neispravno: ispravno:

Slika: Odvajanje reči

Pravilo NC 4: Uniformna notacija

Kad se jedna reč napiše na određen način, taj način treba podržavati u svakoj daljoj upotrebi!
Izmena slova (kao i kod slučaja skraćenica) nije dozvoljena!

Primer:

Proveravanje ispravnosti ili Provera ispravnosti

Ovo se takođe odnosi na upotrebu malog/velikog slova.

Primer:
SWIFT ili Swift
HOST ili Host

27
Pravilo NC 5: Skraćenice

Izrazi/imena u načelu se ne bi trebali skraćivati, osim ako su te skraćenice poznate i široko


prihvaćene.
Ako ime objekta prelazi predviđeni broj znakova (56), nužno je pronaći razumljivu i primerenu
skraćenicu.
Skraćenice se moraju upotrebljavati uniformno (ne sme se jednom prihvaćena skraćenica
pisati u punom obliku)!

Pravilo NC 6: Imena funkcija i događaja

Sva imena moraju biti tačna, nedvosmislena i u jednini. Samo ukoliko je to određeno drugim
tehničkim konvencijama, korištena imena mogu biti u množini.

1. Imena funkcija:

Imena funkcija u načelu se sastoje od dva dela:


• Glagol koji opisuje poduzete akcije vezane za navedeni objekt ili stanje (glagol u
prezentu)
• Ime objekta, stanja, činjenice (imenica bez člana)

Činjenice treba imenovati nedvosmisleno, i u skladu s tehničkim konvencijama.

Primer: Potpisivanje ugovora

Imena funkcija odnose se samo na jednu aktivnost. Ako je potrebno, aktivnosti se mogu
podeliti na dve funkcije.

28
Primer:
neispravno: ispravno:

Slika: Imena funkcija

Izuzetak od ovog pravila može biti ako se radi o nedeljivim aktivnostima ili o aktivnostima
višeg nivoa.

2. Imena događaja:

Događaj opisuje preduslov za izvršenje ili posledično stanje po izvršenju funkcije.


Ime događaja sastoji se od imenice (činjenice) i glagola u pasivu.
Ime se ili izvodi iz naziva prethodne funkcije ili opisuje rezultat / novonastalo stanje objekta.
Preporuka je da se koristi novonastalo stanje objekta kad god je to moguće.

Primer:

Slika: Imena događaja

29
Iz razloga štednje prostora, glagol biti u pozitivu ne treba upotrebljavati.

Primer:
neispravno: ispravno:

Slika: Imena događaja

Događaji se ne smeju opisivati pomoću reči “da” ili “ne”, nego opisno, npr. “odgovor primljen”
ili “odgovor nije primljen”.

Pravilo NC 7: Imena dokumenata

Dokumente treba nazivati njihovim punim imenom ili skraćenicom punog imena, ako je
dogovorena skraćenica. To je potrebno da se izbegne nazivanje različitih dokumenata istim,
opštim nazivima.

Primer:
neispravno: ispravno:

U nazivu dokumenta navodimo da se radi o kopiji (faks, fotokopija, scan, ...), samo ako je za
završetak procesa potreban i originalan dokument.

30
1.4 Konvencije za rad s projektnom bazom podataka
Podaci prikupljeni tokom rada na projektu čuvaće se u ARIS Business Architect alatu,
verzije 9.8 Da bi se koristila ukupna funkcionalnost ARIS baze podataka, kao i zbog što
boljeg razumevanja modelovanih informacija, nekoliko konvencija za rad s bazom podataka
treba unapred biti određeno.

Najviši nivo strukture baze podataka započeće glavnom grupom (direktorijum), čiji naziv
treba biti opšt, ali nedvosmisleno vezan za projekt. Ovaj će direktorijum potom biti podeljen
na različite pod-direktorijume namenjene smeštanju različitih objekata, odnosno modela u
logičke celine. Ti pod-direktorijumi mogu biti “1. Strategija”, “2. Procesi”, “3. Organizacija”,
“4.Sistemi”, “5. Dokumenta”, “6. Proizvodi i usluge” i “Zaglavlja”. Da bi se ovaj princip
osigurao, nove objekte koji će nastajati tokom modelovanja procesa treba smeštati u za to
predviđeni direktorijum. Poštujući ovo pravilo moguće je izbeći podudaranje, a informacije
koje se dobiju izveštajima su pouzdane. Jasno, ovo načelo primenjuje se i na ostale objekte
u bazi, na primer organizacione objekte. Njih ćemo odmah smeštati u direktorijum “3.
Organizacija”, te ćemo ih i pri ponovnoj upotrebi tamo i tražiti. U slučaju kad nam ovi objekti
trebaju za modelovanje procesa, koristićemo njihove pojave, dok će definicije i dalje biti
smeštene u predodređenim grupama.
Direktorijum “2. Procesi” u okviru glavne grupe, moguće je još dublje podeliti na pod-
direktorijume koji će predstavljati glavna područja rada koja ćemo identifikovati tokom
početne faze rada na projektu. Sve objekte koji imaju samo jednu occurence kopiju treba
smestiti u istu grupu u kojoj je smešten model. Kada se model premešta iz grupe u grupu,
potrebno je koristiti opciju »Move with objects«.
Jasno je da će logička struktura repozitorijuma, odnosno podela repozitorijuma na grupe biti
usklađena prema dogovoru, te usklađena prvenstveno sa specifičnostima projekta. Strukturu
grupa u repozitorijumu moguće je tokom projekta i promeniti, odnosno prilagoditi promenama
koje u radu na projektu mogu nastati.

31

You might also like