Evaluering av språk for arbeidsprosessmodellering

Transkript

1 Fordypningsprosjekt høsten 2001 i faget SIF 8093 ved NTNU; Norges teknisknaturvitenskapelige universitet, institutt for datateknikk og informasjonsvitenskap Evaluering av språk for arbeidsprosessmodellering Skrevet av Sofie de Flon Arnesen, 5.klasse datateknikk 1

2 2

3 Forord Denne prosjektrapporten er resulatet av faget SIF 8093 Informasjonssystemer Fordypning ved NTNU høsten Prosjektet heter Evaluering av språk for arbeidsprosessmodellering. Jeg vil rette en takk til veilederen jeg har hatt; John Krogstie. Jeg vil takke Statoil ved Harald Rønneberg for den praktiske vinklingen oppgaven fikk ved at Statoil kom med konkrete krav til et språk for arbeidsprosessmodellering og et konkret case. Jeg vil også takke Harald Rønneberg for kommentarer og innspill underveis. Jeg vil også takke Timon for all oppmuntring og maling på fanget mitt mens jeg har sittet foran PC`en og jobbet om kveldene. Trondheim; 20. november Sofie de Flon Arnesen 3

4 4

5 Sammendrag Jeg har evaluert fem modelleringsspråk på bakgrunn av krav Statoil stiller til et språk for arbeidsprosessmodellering. Statoil er veldig opptatt av at språket må kunne brukes av ledere/mellomledere som ikke er modellsterke, dvs at de ikke har erfaring med å modellere ved hjelp av et grafisk språk. Det betyr at språket må være enkelt samtidig som det må ha tilstrekkelig uttrykkskraft. Jeg har evaluert disse fem språkene: 1. Gjersvik sitt språk 2. EEML 3. Statoil sitt språk (det språket Statoil bruker i dag) 4. UMLs aktivitetsdiagram 5. IDEF-0 Jeg fikk også et case av Statoil som var modellert med det språket Statoil bruker i dag. Dette caset har jeg også modellert med de fire andre språkene for å få litt bedre innsikt i teorien rundt språkene før jeg evaluerte dem. Språkene er evaluert ved hjelp av rammeverket til Sølvberg og Krogstie [9]. Språket til Statoil og UML sitt aktivitetsdiagram kom best ut av evalueringen. Min anbefaling er at Statoil tar disse to språkene videre og gjør en litt mer detaljert vurdering av disse to før endelig valg tas. Jeg har foreslått forbedringer av begge språkene, men det er opp til Statoil å vurdere hvilket de føler passer best og hva de ønsker å forandre på i språkene i forhold til det jeg har foreslått. 5

6

7 Innholdsfortegnelse 1 Innledning Oppgaveteksten Presisering av oppgaveteksten Krav fra Statoil Case-beskrivelsen fra Statoil Arbeidsprosessmodellering Hva er en modell og hvorfor modellerer man? Arbeidsprosess Arbeidsflyt Administrasjon av arbeidsflyt Rammeverket for vurdering av språkkvalitet Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Krav til modelleringsspråkene Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Presentasjon av språkene Gjersvik sitt språk Prosess Produkt Flyt Eksempel på modellering med Gjersvik sitt språk EEML Prosesselement Roller Ressurser Relasjoner i EEML Eksempel på modellering med EEML Språk for arbeidsprosessmodellering i Statoil Notasjonen Eksempel på modellering med språket til Statoil UML Aktivitetsdiagram Eksempel på modellering med aktivitetsdiagram IDEF Notasjonen Syntaksregler for IDEF-0 diagrammet Forskjellige typer diagrammer

8 5.5.4 ICOM-koding Hvordan nummereres boksene? Eksempel på modellering med IDEF Evaluering Gjersvik sitt språk Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Generell evaluering EEML Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Generell evaluering Språket til Statoil Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Generell evaluering UML; Aktivitetsdiagram Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Generell evaluering IDEF Passende for domenet Passende for deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Passende for bedring av teknisk aktørs tolkning Generell evaluering Sammenlikningstabell med karakter for alle de evaluerte språkene Konklusjon Vedlegg A Kildehenvisning

9 Figurliste Figur 1: Modell av Statoil-caset ved å bruke Statoil-språket Figur 2 : Arbeidsflyt taksonomi [24] Figur 3 : Rammeverk for språkkvalitet [9] Figur 4 : prosess Figur 5 : Mellom-produkt Figur 6: Ende-produkt Figur 7 :Symbol for flyt Figur 8: Modell av Statoil-caset ved å bruke Gjersvik sitt språk Figur 9: EEML sine prosessfenomener og hvordan de hører sammen i hierarkiet Figur 10: Objekt rolle i sammenheng med en task Figur 11: Task Figur 12: Beslutningspunkt Figur 13 : Milepæl Figur 14 : Finish Figur 15 : Start Figur 16 : EEML sine rollefenomener og hvordan de hører sammen i hierarkiet Figur 17 : Person Rolle Figur 18 : Verktøy rolle Figur 19 : Objekt rolle Figur 20 : Organisasjonsenhet- rolle Figur 21: EEML sine ressursfenomener og hvordan de hører sammen i hierarkiet Figur 22 : Person Figur 23 : Organisasjon Figur 24 : Software verktøy Figur 25 : Manual verktøy Figur 26 : Informasjons objekt Figur 27 : Material objekt Figur 28 : Flyt Figur 29: Modell av Statoil-caset ved å bruke EEML Figur 30: Prosesshierarki Figur 31: Role Figur 32: Input Figur 33: Output Figur 34: Process Figur 35: Activity Figur 36: Decision point Figur 37: Delivery flow Figur 38: Delivery flow showing the deliveries name Figur 39: Internal connector Figur 40: Eksempel på bruk av Internal connector Figur 41: External connector Figur 42: Eksempel på bruk av External connector Figur 43: QA check point Figur 44: Document

10 Figur 45: Information system Figur 46: Styrende dokument legger rammer for utførelsen av prosessen Figur 47: Informasjonssystemstøtte Figur 48: Dokument som leveranseflyt Figur 49: Data legges inn i et informasjonssystem Figur 50: Start Figur 51: Slutt Figur 52: Aktivitet Figur 53: Enkel pil Figur 54: Joining - piler Figur 55: Forking - piler Figur 56: Beslutningspunkt Figur 57 :Modell av Statoil-caset ved å bruke aktivitetsdiagram Figur 58 : Symbol for funksjon Figur 59: Pilens posisjon på boksen bestemmer hvilken rolle den får Figur 60: Syntaks for flyt Figur 61: Tunnelpil Figur 62: Begrensninger Figur 63 : Samtidige hendelser Figur 64: Forelder- til barnediagram-koding med ICOM Figur 65:Modell av Statoil-caset ved å bruke IDEF

11 Tabell-liste Tabell 1: Passende for domenet- Underliggende basis, krav til modelleringsspråkene Tabell 2: Passende for domenet- Ekstern representasjon, krav til modelleringsspråkene Tabell 3: Passende for deltakernes kunnskap- Underliggende basis, krav til modelleringsspråkene Tabell 4: Passende for deltakernes kunnskap- Ekstern representasjon, krav til modelleringsspråkene Tabell 5: Passende for bedring av felles forståelse- Underliggende basis, krav til modelleringsspråkene Tabell 6: Passende for bedring av felles forståelse- Ekstern representasjon, krav til modelleringsspråkene Tabell 7: Process Overview Tabell 8: Input and Source Tabell 9: Output and Customer Tabell 10: Role and activity description Tabell 11: Role description Tabell 12: Karakterskala ved vurdering av krav Tabell 13: Passende for domenet- Underliggende basis, Gjersvik sitt språk Tabell 14: Passende for domenet- Ekstern representasjon, Gjersvik sitt språk Tabell 15: Passende for deltakernes kunnskap- Underliggende basis, Gjersvik sitt språk Tabell 16: Passende for deltakernes kunnskap- Ekstern representasjon, Gjersvik sitt språk Tabell 17: Passende for bedring av felles forståelse- Underliggende basis, Gjersvik sitt språk Tabell 18: Passende for bedring av felles forståelse- Ekstern representasjon, Gjersvik sitt språk Tabell 19: Passende for domenet- Underliggende basis, EEML Tabell 20: Passende for domenet- Ekstern representasjon, EEML Tabell 21: Passende for deltakernes kunnskap- Underliggende basis, EEML Tabell 22: Passende for deltakernes kunnskap- Ekstern representasjon, EEML Tabell 23: Passende for bedring av felles forståelse- Underliggende basis, EEML Tabell 24: Passende for bedring av felles forståelse- Ekstern represenatsjon, EEML Tabell 25: Passende for domenet- Underliggende basis, Språket til Statoil Tabell 26: Passende for domenet- Ekstern representasjon, Språket til Statoil Tabell 27: Passende for deltakernes kunnskap- Underliggende basis, Språket til Statoil Tabell 28: Passende for deltakernes kunnskap- Ekstern represenatsjon, Språket til Statoil Tabell 29: Passende for bedring av felles forståelse- Underliggende basis, Språket til Statoil Tabell 30: Passende for bedring av felles forståelse- Ekstern represenatsjon, Språket til Statoil 92 Tabell 31: Passende for domenet- Underliggende basis, UML; Aktivitetsdiagram Tabell 32: Passende for domenet- Ekstern representasjon, UML; Aktivitetsdiagram Tabell 33: Passende for deltakernes kunnskap- Underliggende basis, UML; Aktivitetsdiagram. 95 Tabell 34: Passende for deltakernes kunnskap- Ekstern representasjon, UML; Aktivitetsdiagram Tabell 35: Passende for bedring av felles forståelse- Underliggende basis, UML; Aktivitetsdiagram Tabell 36: Passende for bedring av felles forståelse- Ekstern representasjon, UML; Aktivitetsdiagram

12 Tabell 37: Passende for domenet- Underliggende basis, IDEF Tabell 38: Passende for domenet- Ekstern representasjon, IDEF Tabell 39: Passende for deltakernes kunnskap- Underliggende basis, IDEF Tabell 40: Passende for deltakernes kunnskap- Underliggende basis, IDEF Tabell 41: Passende for bedring av felles forståelse- Underliggende basis, IDEF Tabell 42: Passende for bedring av felles forståelse- Ekstern representasjon, IDEF Tabell 43: Sammenlikningstabell for karakterer fått ved evaluering

13 1 Innledning I dette prosjektet har jeg evaluert fem språk for arbeidsprosessmodellering ved hjelp av rammeverket til Krogstie og Sølvberg [9]. I kapittel 1 beskriver jeg først oppgaveteksten slik den forelå, og så forklarer jeg presiseringen som er gjort med den. Etter det tar jeg for meg kravene Statoil har til et språk for arbeidsprosessmodellering. Til slutt i presenterer jeg et modelleringscase jeg fikk av Statoil. I kapittel 2 tar jeg for meg arbeidsprosessmodellering og i kapittel 3 presenterer jeg rammeverket til Krogstie og Sølvberg som jeg skal bruke til å vurdere språkkvalitet med. I kapittel 4 beskriver jeg kravene Statoil har kommet med og som jeg skal evaluere språkene etter. I kapittel 5 presenterer jeg de fem språkene jeg skal evaluere. I kapittel 6 foretar jeg evalueringen av de fem språkene på bakgrunn av kravene Statoil har kommet med, og hvor disse kravene er satt i sammenheng med rammeverket. I kapittel 7 har jeg satt opp en sammenlikningstabell med karakterpoengene alle språkene fikk i hvert krav, og under tabellen er det en drøfting av resultatet. Kapittel 8 er en videreføring av drøftingen, hvor jeg kommer med noen anbefalinger til forbedringer av de to språkene som kommer best ut i evalueringen. 1.1 Oppgaveteksten I forbindelse med endringer i organisasjoner, benyttes modellering på ulikt nivå i mange sammenhenger. Det er tidligere utviklet et generelt rammeverk for å forstå hva det vil si at modeller er av høy kvalitet. Rammeverket dekker også kvalitet av modelleringsspråk som middel for kunne lage modeller av høy kvalitet, og kan spesialiseres i forhold til ulike modelleringsoppgaver. Statoil vurderer å standardisere sitt språk for prosessmodellering/virksomhetsmodellering. På bakgrunn av de krav Statoil stiller til et språk for arbeidsprosessmodellering, skal rammeverket brukes til å evaluere relevante språk i denne sammenheng. 1.2 Presisering av oppgaveteksten Jeg vil presisere at jeg i tillegg til å evaluere relevante språk for arbeidsprosessmodellering,også vil komme med noen anbefalinger til Statoil om forbedringer, på bakgrunn av resultatet i evalueringen. 1.3 Krav fra Statoil Statoil har en del krav til det modelleringsspråket de skal bruke i arbeidsprosessmodellering. Under er de kravene jeg fikk skriftlig av Statoil, som har vært med på å bygge opp kravtabellene i kapittel 4 og som jeg senere evaluerer språkene etter. 13

14 Statoils krav Statoil har følgende overordnede krav til språket: Språket må kunne brukes av ledere/mellomledere og andre ansatte som ikke er modellsterke, dvs at de ikke har erfaring med å modellere ved hjelp av et grafisk språk. Det betyr at språket må være enkelt samtidig som det må ha tilstrekkelig uttrykkskraft. Språket skal ikke være rettet mot et bestemt fagområde, også kalt domene. Språket skal være egnet til å beskrive arbeidsprosesser uavhengig av domenet. Språket skal være egnet til å beskrive både rutinearbeid og ikke-rutinearbeid. Fenomener som språket må kunne uttrykke: 1. Prosesser en prosess består av flere underprosesser eller aktiviteter, dvs at en prosess må kunne dekomponeres 2. Aktiviteter laveste nivå i en prosessmodell. Vil ikke bli ytterligere dekomponert. 3. Roller 4. Beslutningspunkter 5. Flyt flyt mellom prosesser, aktiviteter og beslutningspunkter Fenomener som språket bør kunne uttrykke: 1. Leveranser (resultater) 2. Systemressurser (i denne oppgaven betyr det informasjonssystemer) Det er nødvendigvis ikke et krav at alle disse fenomenene skal kunne uttrykkes med et eget symbol. Det må være mulig å utvikle/bygge modellen trinnvis, dvs. at det må være mulig å modellere visse fenomener uavhengig av de andre. For Statoil betyr dette konkret at: det må være mulig å bare konsentrere seg om (modellere) prosesser og flyten mellom disse uten å ta hensyn til andre forhold det må være mulig å bare konsentrere seg om (modellere) aktiviteter og flyten mellom disse uten å ta hensyn til andre forhold roller, beslutningspunkter, systemressurser og leveranser må kunne legges til uavhengig av hverandre når modelløren finner det hensiktsmessig 1.4 Case-beskrivelsen fra Statoil Under er case-beskrivelsen fra Statoil og den tilhørende modellen hvor Statoil sitt språk (beskrevet i kapittel 5.3) er brukt til å modellere, se figur 1. Det er dette caset jeg bruker når jeg skal gi eksempler på hvordan man kan bruke de forskjellige språkene til å modellere med, se kapittel 5.1.4, kapittel 5.2.5, kapittel 5.3.2, kapittel 5.4.2, kapittel Caset er innført i oppgaven så jeg skal få prøvd hvordan språkene er å modellere med. 14

15 Case-beskrivelsen En eller annen person får en ide. Ideen presenteres til aktuelle forretningsenheter. Prosess-eiere og/eller interesserte forretningsenheter evaluerer ideen. På bakgrunn av evalueringen tas det en beslutning (DG = decision gate = beslutningspunkt) på om ideen skal utredes videre eller om den skal legges død. Hvis ideen skal utredes videre må prosesseiere og/eller interesserte forretningsenheter finne én sponsor som får det finansielle og forretningsmessige ansvaret for ideen. Sponsoren sammen med den interne IT tjenesteleverandøren utarbeider et business case, spesifiserer det potensielle prosjektets omfang, mm., dvs gjennomfører en forstudie som i praksis blir et prosjektforslag. Prosjektforslaget kvalitetsikres av ITs fagledere (rådgivere) og eventuelle forbedringer gjøres. Sponsor avgjør om prosjektforslaget skal sendes til en arena for prioritering og anbefaling eller om det skal tas en beslutning uten å involvere en arena. Det tas uansett omsider en beslutning på om prosjektforslaget skal stoppes eller gjennomføres. Hvis prosjektforslaget skal gjennomføres, utsteder sponsor en bestilling som går til intern IT tjenesteleverandør for gjennomføring. Under er dette caset modellert med språket til Statoil, se figur 1. 15

16 Starting IT projects Initiator idea present to business stop initiative No Process owner, business area evaluate continue (DG0) Yes specify who is to be the sponsor for the initiative No stop initiative Sponsor specify scope and business case prioritize, present or comment No continue (DG1) Yes order project Corporate staff /S/IT, Process board, TEK arena's Yes prioritize, comment and recommend IT discipline advisors QA and advice Internal IT service provider advise and specify the likely IT architecture start project Figur 1: Modell av Statoil-caset ved å bruke Statoil-språket 16

17 2 Arbeidsprosessmodellering Først i dette kapittelet tar jeg for meg hva som menes med arbeidsprosessmodellering og hva som er hensikten med å modellere. Deretter sier jeg litt om arbeidsprosess, arbeidsflyt og administrasjon av arbeidsflyt. Jeg har valgt å definere arbeidsprosessmodellering som følger: Arbeidsprosessmodellering er å lage modell(er) av arbeidsflyten til en arbeidsprosess. 2.1 Hva er en modell og hvorfor modellerer man? En modell er en forenkling av virkeligheten. En modell kan beskrive hva et fenomen 1 gjør, hva som kontrollerer det, hva fenomenet arbeider på, hva det bruker til å utføre det det skal og hva det produserer. En modell utvikles for å fortså, analysere, forbedre og/eller erstatte fenomenet man ser på. I for eksempel en utviklingsprosess, er det viktig å bruke modeller for å kunne abstrahere og avgrense virkeligheten og for å kunne gjenspeile de sentrale delene av virkeligheten som er relevant for den gitte problemstillingen. Dette gjør det enklere å analysere problemet. Det er også enklere å manipulere med modeller i stedet for med virkeligheten. En modell gir en forenklet beskrivelse av den delen av virkeligheten man er interessert i å se nærmere på, og modellen skal være enkel å forandre på dersom virkeligheten forandres. En modell skal forenkle kommunikasjonen mellom de involverte aktørene og gjøre det enklere for partene å forstå problemet [17]. Det finnes tre hovedtyper av modeller; formelle, uformelle og hybride. Formelle modeller er uttrykt ved hjelp av formelle språk, for eksempel DFD eller ER. Uformelle modeller er uttrykt ved hjelp av uformelle språk, det vil si ren tekst (norsk språk). Hybride modeller er en blanding av formelle og uformelle modeller 2. I denne oppgaven vil jeg kun se på formelle språk. Utfordringen er at modelleringsspråket bør være så enkelt som mulig samtidig som det har nødvendig uttrykkskraft, og disse to kravene er vanskelig å forene. Kvaliteten på modellen og modelleringsspråket har mye å gjøre med i hvor stor grad dette tilfredsstilles. 2.2 Arbeidsprosess En arbeidsprosess definerer en arbeidsflyt. Reiseregnings-eksemplet under er en arbeidsprosess. 1 Et fenomen er noe observerbart, for eksempel en prosess, en rolle, en melding, flyt, ressurs, produkt, aktivitet, aktør etc. 2 Egentlig er vel alle modeller hybride, på den måten at det ofte brukes tekst til å forklare hele eller deler av modellen. 17

18 2.3 Arbeidsflyt Arbeidsflyt er et sett av steg eller en sekvens av aktiviteter (enheter av arbeid). Arbeidsflyt er bevegelse av aktiviteter gjennom en prosess [13], [15]. For eksempel at en ansatt leverer reiseregningen sin manuelt til sekretæren som har ansvaret for å motta den. Sekretæren leser gjennom og sjekker at alt er OK, deretter sender hun den videre til en mellomleder som skal godkjenne, og sånn kan reiseregningen gå gjennom flere ledd før den er endelig godkjent og sendt til regnskapsavdelingen og pengene har kommet inn på konto. Alle disse stegene er arbeidsflyt: reiseregningen flyter mellom folk som gjør arbeid med den. Følgende, til og med figur 2, er tatt fra [24]: I henhold til Marshak er viktige arbeidsflyt-karakteristikker oppgaver eller aktiviteter som blir utført av personer med ulike roller som bruker støtte-verktøy som gir tilgang til forskjellige delte informasjons-ressurser (shared information resources). Dette er illustrert i figur 2. 18

19 Business Processes Routes Role 3 Role 1 Role 5 Role 2 Role 4 Activities Activity 3 Activity 1 Activity 2 Activity 4 Activity 5 Activity 6 Productivity Tools Forms Processor Legacy IS Spread- Sheet Word Processor Shared Information Resources Figur 2 : Arbeidsflyt taksonomi [24] 19

20 2.4 Administrasjon av arbeidsflyt Administrasjon av arbeidsflyt (workflow management) er kunsten å kontrollere og administrere en sekvens av aktiviteter [1]. Ved administrasjon av arbeidsflyt defineres aktiviteter, roller, arbeidsoppgaver og avviksregler. Administrasjon av arbeidsflyt innebærer at organisasjonen kan definere og kontrollere de ulike aktivitetene, videre at de kan måle og analysere utføringen av aktivitetene, slik at man kan gjøre stadige forbedringer. Resultatet er at for eksempel vare- og informasjonsflyten automatiseres og ressursinnsatsen kan fokuseres mot oppgaver som ut fra gitte kriterier ikke tilfredsstiller kravene for automatisert behandling. Ressursinnsatsen som f.eks er knyttet til kontering og godkjenning av inngående faktura effektiviseres betydelig som følge av handlingsregler og datastyrt arbeidsflyt. Med datastyrt arbeidsflyt blir den enkelte oppgave automatisk styrt til rett person [2], [14], [16]. Statoil er ikke interessert i automatisering i forbindelse med denne oppgaven, de er kun interessert i et modelleringsspråk hvor man kan modellere arbeidsprosesser. Statoil vil altså bare modellere hvordan de gjør ting, eller hvordan ting burde ha vært gjort. 20

21 3 Rammeverket for vurdering av språkkvalitet Et rammerverk gjør det mulig å diskutere/evaluere kvaliteten på de ulike språkene. Det man evaluerer med et rammeverk er potensialet til språket med hensyn til kvalitet, hvor kvalitet er relativt i forhold til de kravene som er gitt. Jeg vil her gi en presentasjon av det rammeverket jeg skal bruke til å evaluere de utvalgte språkene som er beskrevet i kapittel 5. Først presenterer jeg hovedfenomenene og relasjonene til rammeverket (figur 3) på et overordnet nivå. Deretter går jeg mer i detalj for relasjonene, med det mener jeg at jeg gir en detaljert beskrivelse av relasjonene med både underliggende basis og ekstern representasjon for alle relasjonene; Passende for domenet, Passende for deltakernes kunnskap, Passende for å uttrykke deltakernes kunnskap, Passende for bedring av felles forståelse og Passende for bedring av teknisk aktørs tolkning. Hovedkonseptet til rammeverket og relasjonene mellom dem er beskrevet under og er vist i figur 3 [8], [9]. Hovedkonseptene: L: Språkekstensjonen (Language extension): Alle de utsagn det er mulig å uttrykke i henhold til det valgte modelleringsspråkets vokabular, syntaks 3 og struktur. D: Modelleringsdomenet (Modeling domain): Alle utsagn som kan uttrykkes om interesseområdet gitt modelleringens hensikt. K: Den relevante eksplisitte kunnskapen (participant knowledge) til de aktørene som utfører modelleringen. Det er summen av kunnskapen til alle aktørene. Det aktørene vet og skal prøve å uttrykke med språket. I: Tolkningen til de sosiale aktørene (Social actor interpretation): De utsagn som de som forholder seg til modellen tolker den til å inneholde. T: den tekniske Aktørens tolkning (Technical actor interpretation): Stegene i modellen slik den blir tolket av forskjellige verktøy brukt i modellering, typisk et dataprogram (case-verktøy). 3 Syntaks er strukturelle komponentene og egenskapene til et modelleringsspråk og reglene som definerer relasjonene mellom komponentene. 21

22 Modellers kunnskap K Sosial aktørs tolkning I Passende for deltakernes kunnskap og passende for å uttrykke deltakernes kunnskap Passende for bedring av felles forståelse Modelleringsdomenet D Passende for domenet Språk- ekstensjon L Passende for teknisk aktørs tolkning Tekniske aktørens tolkning T Figur 3 : Rammeverk for språkkvalitet [9] 22

23 Relasjonene: Passende for domenet: kan beskrives slik: D/L = Ø, der Ø er lik den tomme mengde. Det betyr at det ikke er noen utsagn i domenet som ikke kan bli uttrykt i språket. Dette betyr igjen at forskjellige språk er mer eller mindre egnet til forskjellige problemstillinger, og man må sjekke om språket passer til domenet. Kan man få uttrykt alle utsagn i domenet ved hjelp av det gitte språket? Språket bør være yttrykkskraftig nok til å kunne uttrykke alt i domenet. Og på en annen side skal det ikke være mulig å uttrykke noe som ikke er i domenet, hvis dette tar fokus fra problemstillingen. Språket må altså være formelt og utvetydig. Passende for deltakernes kunnskap: Målet er at utsagnene uttrykt i språket skal være en del av den eksplisitte kunnskapen til deltakerne, når forskjellige deltakere bruker språket. Deltakernes kunnskap blir relatert til språket. Det betyr at man sjekker om deltakernes kunnskap om modelleringsspråket (eller potensialet til å lære), passer til språket. Passende for å uttrykke deltakernes kunnskap kan beskrives slik: K/L = Ø. Det betyr at det ikke finnes noen utsagn som ikke kan bli uttrykkt i språket. Språket blir relatert til deltakernes kunnskap. Passer språket til å uttrykke deltakernes kunnskap? Passende for bedring av felles forståelse er det settet av utsagn som er forstått av deltakerne og som kan bli modellert i språket. Ideelt sett er L/I = Ø. Det betyr at alle mulige utsagn i språket er forstått av deltakerne. Her relatereres språket til de sosiale aktørenes tolkning. Er språket med på å bedre deltakernes felles forståelse? Passende for teknisk aktørs tolkning betyr at språket blir relatert til den tekniske aktørens tolkning. Blir den bedret? Teknisk aktør er for eksempel et modelleringsverktøy. Hvor egnet er språket til automatisert eksekvering og resonnering? For hvert av disse kriteriene skiller man mellom: Underliggende basis: Kriterier for den underliggende (konseptuelle) basis til språket. For eksempel konstruksjonene til språket Ekstern representasjon: Kriterier for den eksterne representasjonen til språket. For eksempel hvordan disse konstruksjonene representeres visuelt. 23

24 Kapittel 3.1 til og med kapittel 3.5 er tatt fra [9]: 3.1 Passende for domenet Passende for domenet oppnås dersom det ikke er noen utsagn innen domenet som ikke kan uttrykkes i språket. Det betyr at forskjellige språk er mer eller mindre egnet for forskjellige problemområder. Underliggende basis Ideelt sett må basis være kraftig nok til å kunne uttrykke alt innen domenet. På en annen side skal det ikke være mulig å kunne uttrykke noe som ikke er i domenet, hvis dette medfører at man fokuserer på feil aspekt. Et typisk eksempel på dette er forskjellen mellom analyse- og designmodeller. Et språk som er veldig godt for designmodellering, trenger ikke være så godt for analyse, siden det trenger å inkludere programvarespesifikke konstruksjoner som, dersom det ble brukt innen analyse, kan resultere i et produkt heller enn en problemorientert modell. Det er et uendelig antall utsagn som man kanskje trenger å foreta seg, og disse håndteres gjennom et lite antall fenomener på grunn av Passende for bedring av felles forståelse (se kapittel 3.4). Dette betyr at: Fenomenet må være generelt heller enn spesielt. Fenomenet må være komponerbart, hvilket betyr at vi kan gruppere relaterte utsagn på en natulig måte. Når man bare er opptatt av passende for domenet er det en fordel at alle tenkelige kombinasjoner er tillatt, og at hver av dem gir en egen mening. Språket må være fleksibelt i presisjon: For å uttrykke presis kunnskap trengs presise konstruksjoner. Dette betyr at språket må være formelt og utvetydig. På samme tid trenger man vage konstruksjoner for å modellere vag kunnskap. For å tilfredsstille begge krav må også vagheten bli formalisert. (For eksempel til og med de vage konstruksjonene må ha en bestemt fortolkning. Konstruksjonene er kalt vage fordi deres fortolkning er vid sammenliknet med de mer bestemte konstruksjoner.) Støtte for relevante perspektiver. Disse er: Strukturelt perspektiv: fokuserer på den statiske strukturen til systemet. For eksempel ERdiagrammer. Funksjonelt perspektiv: fokuserer på prosesser, ivaretatt i for eksempel dataflytdiagrammer. Oppførsel perspektiv: fokuserer på systemets oppførsel. For eksempel tilstander, meldingsflyt, og så videre. Regel perspektiv: fokuserer på systemets regler. For eksempel if betingelse, then aksjon. Objekt perspektiv: fokuserer på objektorienterte fenomener som objekter, prosesser og klasser, samt relasjoner som arv, aggregering og assosiasjoner. Kommunikasjon perspektiv: fokuserer på kommunikasjonen mellom fenomener. Aktør- og rolle perspektiv: fokuserer på aktører og roller. 24

25 Ekstern representasjon Det eneste kravet til den eksterne representasjonen er at den ikke ødelegger den underliggende basis. Derfor: Ethvert mulig utsagn innen språket skal ha en unik representasjon i basis, hvis ikke vil presisjonen i språket bli ødelagt. Ethvert mulig utsagn i den underliggende basis skal ha minst én ekstern representasjon, hvis ikke vil allmenngyldigheten bli redusert. På samme måte som for fenomen, må symbolene i språket være komponerbare. Som indikert, bare korrespondansen fra symbol til fenomen trenger å være unik. Det er i orden å ha flere alternative eksterne representasjoner for samme utsagn. 3.2 Passende for deltakernes kunnskap Passende for deltakernes kunnskap oppnås dersom alle utsagn i en modell i et språk er en del av modellerers (deltakers) eksplisitte kunnskap. Underliggende basis Den underliggende basis må korrespondere så mye som mulig med måten individene oppfatter virkeligheten på. Dette vil være forskjell fra person til person, og mellom personer i forskjellige grupper, utifra deres tidligere erfaringer. Dette vil derfor initielt være direkte avhengig av deltakerne i et modelleringsarbeid. På en annen side er ikke deltakernes kunnskap statisk, det er for eksempel mulig å lære en person til å bruke et spesielt språk. I dette tilfellet bør man basere språket på erfaringer med språk for konseputell modellering som tidligere har vært brukt på en suksessfull måte i liknende oppgaver. Et annet viktig punkt i den forbindelsen er at det med språket må være mulig å uttrykke inkonsistens og uenighet, siden inkonsistens mellom hvordan personer oppfatter virkeligheten er et faktum som er nyttig å representere, slik at disse kan avsløres og diskuteres eksplisitt. Ekstern representasjon Den eksterne representasjonen av forskjellige fenomen må være intuitiv i den forstand at de valgte symboler for et spesielt fenomen må reflektere dette bedre enn et annet symbol ville ha gjort. Dette er også delvis avhengig av deltakerne, til og med dersom generelle retningslinjer medfølger. 25

26 3.3 Passende for å uttrykke deltakernes kunnskap Passende for å uttrykke deltakernes kunnskap er dersom det ikke eksisterer utsagn i den eksplisitte viten til deltakerne som ikke kan uttrykkes i språket. I det opprinnelige materialet er det ikke skilt mellom underliggende basis og ekstern representasjon for dette kriteriet. Derfor gjør ikke jeg det heller. 3.4 Passende for bedring av felles forståelse Passende forbedring av felles forståelse oppnås dersom alle mulige utsagn innen språket blir forstått av deltakerne som bruker språket. Underliggende basis Fenomenene i språket må tydelig kunne fraskilles hverandre. Antall fenomen må være rimelig/ fornuftig. Bruken av fenomen må være uniform i hele settet av utsagn som er mulig å uttrykke i et språk. Å bruke de samme konstruksjonene for ulike fenomen eller ulike konstruksjoner for den samme funksjon avhengig av kontekst, vil gjøre språket forvirrende. Språket må være fleksibelt i detaljeringsgrad: Utsagn må være lette å bygge på (utvide) med andre utsagn som gir bedre detaljeringsnivå. Samtidig må detaljer lett kunne gjemmes. Dette betyr at språket må inkludere abstraksjonsmekanismer. Separasjon av oppgaver: Det er mulig å dele modellen laget i et språk i naturlige deler, for å gjøre det mulig å støtte arbeidsdeling i den betydning at individuelle deltakere kan konsentrere seg om områdene de er interessert i. Uttrykke sparsommelighet De mest hyppige utsagn må være så kortfattet som mulig. De viktigste utsganene må være så kortfattet som mulig. Ekstern representasjon Det må være lett å se forskjell på de ulike symbolene i språket. Det eksterne språket må være så konsistent som mulig, på den måten at symbolene må være uniforme (enhetlige), det vil si at et symbol ikke må representere ett fenomen i én sammenheng og noe helt annet i en annen sammenheng. Man må heller ikke bruke forskjellige symboler for det samme fenomenet i forskjellige sammenhenger. Man må tilstrebe enkelhet i symbolene, både med hensyn på de primitive symbolene i språket og måten de er antatt forbundet. Hvis symbolene i seg selv er visuelt komplekse, så vil modeller som inneholder en mengde symboler bli enda mer komplekse, og derfor vanskelige å forstå. 26

27 Bruken av uthevelser i språket må være ioverenstemmelse med den relative viktighet til utsagnet. Faktorer som har en viktig innvirkning på visuell utheveing er størrelse, soliditet (for eksempel uthevet skrift), farge, posisjon, grad, og så videre. Gruppering av relaterte utsagn: Har språket konstruksjoner som støtter gruppering av relaterte utsagn? Den eksterne representasjonen har mange muligheter som den underliggende basis ikke har: Utelatelse av symboler som er forstått i konteksten. Spesielle symboler kan defineres for konstruksjoner som er hyppige (eller viktige). Gjentatte omtaler av det samme fenomen er uunngåelig på basisnivået. På det eksterne nivået kan slike gjentatte omtaler ofte unngås. Fallgruver som bør unngås: Blanke symboler, det vil si symboler som ikke inneholder noe informasjon for noen. Ekstern redundans, det vil si visning av samme fenomen på flere ulike måter i den samme eksterne representasjonen. Et annet aspekt ved Passende for bedring av felles forståelse er toleranse, definert som frihetsgraden man har ved modellering av det samme domenet. På den ene siden er høy toleranse nyttig, siden det gjør det mulig å reformulere en modell på mange ulike måter. På den annen siden kan toleranse føre til forvirring, siden det kanskje blir vanskelig å se likehetene mellom to modeller. 3.5 Passende for bedring av teknisk aktørs tolkning Underliggende basis For den tekniske aktør er det svært viktig at språket lener seg mot automatisert resonnering. Dette krever formalitet (det vil si både formell syntaks og semantikk som er operasjonell og/eller logisk), men formalitet er ikke nødvendigvis nok, siden resonneringen også må være ganske effektiv for å være praktisk anvendbar. Dette dekkes av eksekverbarhet. På den annen side kan en modell som er uttrykkt i et naturlig språk også være nyttig fra dette synspunkt, siden teknikker for å forstå naturlig språk er forbedret. Konstruksjoner for skjuling av informasjon Her benytter det underliggende materiale denne overskriften. Jeg har derfor valgt å gjøre det samme, selv om det bryter med konsistenten i overskriftene. Innkapsling av deler av modellen begrenser dens tilganger fra andre komponenter, det vil si for å opprette uavhengige deler. Dette er en nyttig egenskap når modellene brukes til å generere 27

28 programkoden, og derfor gjør testing lettere. Det er også nyttig når man ønsker å fokusere på bare en del av en modell. 28

29 4 Krav til modelleringsspråkene På bakgrunn av kravene fra Statoil som ble presentert i kapittel 1.3, og på bakgrunn av krav jeg fant i [9] som også passet for Statoil i dette tilfellet, og ved hjelp av muntlig koordinering med Statoil, har jeg utarbeidet en del konkrete krav til språkene som jeg skal evaluere etter i kapittel 6. Krav-tabellene er satt i sammenheng med rammeverket som er beskrevet i kapittel 3. Først ser jeg på krav i forbindelse med Passende for domenet, deretter ser jeg på krav innenfor Passende for deltakernes kunnskap, deretter krav innenfor Passende for å uttrykke deltakernes kunnskap, Passende for bedring av felles forståelse og Passende for bedring av teknisk aktørs tolkning. 4.1 Passende for domenet Underliggende basis Nr. Krav 1 Språket må være uavhengig av fagområdet. 2 Ideelt sett må basis være kraftig nok til å kunne uttrykke alt innen domenet. 2.1 Prosesser: en prosess består av flere underprosesser eller aktiviteter, det vil si at en prosess må kunne dekomponeres. 2.2 Aktiviteter: laveste nivå i en prosessmodell. Vil ikke bli ytterligere dekomponert. 2.3 Roller 2.4 Beslutningspunkter 2.5 Flyt- flyt mellom prosesser, aktiviteter og beslutningspunkter. 2.6 (bør- Leveranser (resultater) krav) 2.7 (bør- Systemressurser (i denne oppgaven betyr det krav) informasjonssystemer). 3 Fenomenet må være dekomponerbart med mulighet for hierarkisk oppbygning. For Statoil er det bare krav til at prosessen skal være dekomponerbar. Tabell 1: Passende for domenet- Underliggende basis, krav til modelleringsspråkene Ekstern representasjon Nr. Krav 4 På samme måte som for fenomen må symbolene 29

30 også være dekomponerbare. Tabell 2: Passende for domenet- Ekstern representasjon, krav til modelleringsspråkene 4.2 Passende for deltakernes kunnskap Underliggende basis Nr. Krav 5 Navngivningen av fenomenene må være de samme som navngivningen i domenet. 6 Språket må være lett å lære. Tabell 3: Passende for deltakernes kunnskap- Underliggende basis, krav til modelleringsspråkene Ekstern representasjon Nr. Krav 7 Den eksterne representasjonen av forskjellige fenomen må være intuitiv da de valgte symboler for et spesielt fenomen må reflektere dette bedre enn et annet symbol ville ha gjort. Tabell 4: Passende for deltakernes kunnskap- Ekstern representasjon, krav til modelleringsspråkene 4.3 Passende for å uttrykke deltakernes kunnskap Her har ikke Statoil noen krav fordi det ikke lar seg gjøre å vite hva slags kunnskap deltakerne sitter med. 4.4 Passende for bedring av felles forståelse Underliggende basis Nr. Krav 8 Fenomenene i språket må tydelig kunne skilles fra hverandre. 9 Antall fenomen må være rimelig/ fornuftig. 30

31 10 Språket må være fleksibel i detaljeringsgrad: Utsagn må være lette å bygge på (utvide) med andre utsagn som gir bedre detaljeringsnivå. Med dette menes at det skal kunne legges inn nye fenomener etter hvert. Tabell 5: Passende for bedring av felles forståelse- Underliggende basis, krav til modelleringsspråkene Ekstern representasjon Nr. Krav 11 Det må være lett å se forskjell på de ulike symbolene i språket. 12 Det eksterne språket må være så konsistent som mulig på den måten at symbolene må være uniforme (enhetlige), det vil si at et symbol ikke må representere ett fenomen i én sammenheng og noe helt annet i en annen sammenheng. Man må heller ikke bruke forskjellige symboler til å uttrykke det samme fenomenet i forskjellige sammenhenger. Idéelt sett bør hvert fenomen ha et eget symbol, men dette er ikke et absolutt krav fra Statoil fordi modellen da kan bli for kompleks. 13 Man må tilstebe enkelhet i symbolene, både med hensyn på de primitive symbolene i språket og i måten de er antatt forbundet. Hvis symbolene i seg selv er visuelt komplekse, så vil modeller som inneholder en mengde symboler bli enda mer komplekse, og derfor vanskelig å forstå. 14 Bruken av uthevelser i språket må være i overenstemmelse med den relative viktighet i utsagnet. Faktorer som har en viktig innvirkning på visuell uthevning er følgende: Størrelse Soliditet (for eksempel uthevet skrift) Forskjell fra det vanlige mønsteret Forgrunn/bakgrunn Bilde Posisjon Grad osv Tabell 6: Passende for bedring av felles forståelse- Ekstern representasjon, krav til modelleringsspråkene 31

32 4.5 Passende for bedring av teknisk aktørs tolkning Statoil er i denne sammenhengen ikke interessert i automatisk resonnering og eksekvering. Statoil ønsker ikke at krav relatert til teknisk aktørs tolkning skal ha betydning for valg av språk for arbeidsprosessmodellering. 32

33 5 Presentasjon av språkene I dette kapittelet skal jeg ta for meg notasjonen til de gitte modelleringsspråkene. Jeg presenterer språkene fordi det er nyttig å vite om teorien bak hvert modelleringsspråk hvis man skal få noe ut av å lese evalueringen. Basert på innspill fra oppgavestiller og Statoil, har jeg valgt å evaluere følgende fem språk: 1) Gjersvik sitt språk 2) EEML (Extended Enterprise Modeling Language) 3) Språket til Statoil 4) UML (Unified Modeling Language) Her velger jeg å se på aktivitetsdiagram. 5) IDEF-0 (Integration DEFinition language 0) Dersom noen eller alle språkene er kjent, anbefaler jeg at du hopper over det som er kjent og eventuelt begynner å lese rett på evalueringen. Når jeg presenterer språkene, vil jeg først si litt generelt om dem, deretter tar jeg for meg hva notasjonen inneholder og presenterer symbolet til notasjonen. Til slutt for hvert språk, gir jeg et eksempel på hva slags modell man får når man bruker språket til å modellere caset fra Statoil. Det siste gjør jeg for min egen del, slik at jeg får satt meg ordentlig inn i hvert modelleringsspråk. På den måten blir jeg bedre i stand til å gjennomføre evalueringen i kapittel 6. I kapittel 5.1 ser jeg på Gjersvik sitt språk, i kapittel 5.2 beskriver jeg EEML. Deretter, i kapittel 5.3 tar jeg for meg språket til Statoil. Det er dette språket Statoil bruker nå. I kapittel 5.4 presenterer jeg notasjonen til aktivitetsdiagrammer i UML. I kapittel 5.6 tar jeg for meg IDEF-0 (Integration DEFinition language 0). 5.1 Gjersvik sitt språk Gjersvik sitt modelleringsspråk er utviklet spesielt for arbeidsprosessmodellering og fokuserer på prosesser og produkter. Prosesser produserer produkter, og prosesser bearbeider produkter. Flyten mellom prosessene og produktene angis med en strek fra figur til figur. Notasjonen til Gjersvik sitt språk består av tre symboler. 1) Prosess 2) Produkt 3) Flyt Først tar jeg for meg Prosess, deretter Produkt og Flyt. Til slutt viser jeg hvordan caset fra Statoil blir som modell når man bruker Gjersvik sitt språk til å modellere med, se figur 8. 33

34 5.1.1 Prosess En prosess brukes når man har en serie av aktiviteter eller sub-prosesser som produserer et spesifikt produkt. Et eksempel er tegn tekniske installasjoner. Prosesser krysser ofte organisasjonelle grenser og beskrives ved hjelp av -verb og substantiv-, for eksempel -evaluere idè-. Prosesser er handlinger. Symbolet på en prosess er illustrert i figur 4 : Figur 4 : prosess Prosessene kan også betraktes som kunder og leverandører. Kunden er den som krever produktet og bruker produktet, mens leverandøren produserer produktet. For eksempel er prosessen Avle opp laks leverandør til prosessen Slakte og bearbeide laks. Prosessen Slakte og bearbeide laks blir da kunden til prosessen Avle opp laks. Slakte og bearbeide laks er leverandør til prosessen Selge fisken i butikken, mens prosessen Selge fisken i butikken, som det for eksempel kan være Rema 1000 som gjør, er kunde av Slakte og bearbeide laks. En prosess kan altså både være kunde og leverandør, det kommer an på hvor i flyten vi ser og hvilken vei vi ser Produkt Et produkt er et resultat av en prosess (i krav fra en kunde). En prosess kan få flere produkter inn, og et produkt kan gå til flere prosesser. Et eksempel er produktet frossen laks fra eksempelt over. Èn prosess kan gi flere produkter. Prosessen over kan for eksempel i tillegg til frossen laks også ha fiskesuppe som produkt. Man skiller mellom ende-produkter og mellomprodukter, og disse symboliseres som i figur 5 og figur 6. Figur 5 : Mellom-produkt Figur 6: Ende-produkt 34

35 5.1.3 Flyt Flyt vises med en strek mellom de symbolene det går flyt. Se figur 7. Figur 7 :Symbol for flyt For mer utdypende informasjon om Gjersvik sitt språk, se [11] og [12] Eksempel på modellering med Gjersvik sitt språk Her har jeg modellert caset fra Statoil med Gjersvik sitt språk. Da får jeg følgende modell, se figur 8. 35

36 Utarbeide idé idé Kvalitetssikre og rådgi Presentere idé presentert ide Evaluere idé Beslutte om prosjektforslag skal være gjenstand for prioritering Prosjektforslag Kvalitetskontrollert prosjektforslag Kvalitetskontrollert prosjektforslag Kvalitetskontrollert prosjektforslag evaluert ide Skal idéen utredes videre Prioritere, kommentere og anbefale stoppet ide akseptert idé Beslutte om prosjektforslaget skal godkjennes Prioritert prosjektforslag Utnevne prosjektsponsor Ikke godkjent prosjektforslag Godkjent prosjektforslag Sponsor akseptert idé Bestille prosjekt Spesifisere omfang og "business case" Rådgi og spesifisere IT arkitektur Bestilt prosjekt Starte prosjekt Prosjekt Fortsetter i modellen til venstre 36

37 Figur 8: Modell av Statoil-caset ved å bruke Gjersvik sitt språk. 37

38 5.2 EEML EEML (Extended Enterprise Modelling Language) er et veldig uttrykkskraftig språk. Det fokuserer på prosesser, ressurser og roller, og mellom disse eksisterer det en rekke forskjellige relasjoner. Kort fortalt er sammenhengen mellom task 4 og en rolle slik at en rolle utfører en task, og en rolle er bekledd av en ressurs. EEML er spesielt utviklet for forretningsmodellering, simulering og arbeidsflyt. Fenomenene til EEML er delt inn på følgende måte: 1) Prosesselement Task Abstrakt Beslutningspunkt (Abstract Decision Point) Beslutningspunkt Milepæl Finish Start Innput port Utput port 2) Roller Person Objekt Verktøy Organisasjonsenhet 3) Ressurser Person Organisasjon Verktøy Manuelt verktøy Software verktøy Objekt Materialobjekt Informasjonsobjekt 4) Relasjoner Flow Carries Resource Is Filled By Has Part Has Resource Role 4 Jeg bruker det engelske ordet task gjennom hele oppgaven, fordi det ikke er et godt norsk ord som dekker betydningen i alle sammenhenger. 38

39 I kapittel ser jeg på prosesselement, i kapittel ser jeg på roller, i kapittel tar jeg for meg ressurser og i kapittel ser jeg på relasjoner mellom EEML-fenomener. I kapittel viser jeg Statoil-caset modellert med EEML, se figur 29. Ønskes en mer utdypende forklaring av notasjonen enn det jeg presenterer, henvises det til [5] Prosesselement Under er EEML sine prosessfenomener hierarkisk oppbygd, se figur 9. «type» processelement «EE Process» task «EE Process» abstractdecisionpoint «EE Process» milestone «EE Process» inputport «EE Process» outputport «EE Process» decisionpoint «EE Process» start «EE Process» finish Figur 9: EEML sine prosessfenomener og hvordan de hører sammen i hierarkiet. Jeg vil nå beskrive prosessfenomenene ytteligere, og presentere symbolene med forklarende tekst. Først i dette kapittelet presenterer jeg prosesselementet task, deretter tar jeg for meg abstrakt beslutningspunkt. Denne er delt inn i beslutningspunkt, milepæl (som er delt inn i finish og start) innput port og utput port. 39

40 Task Task brukes til å representere en avgrenset del av arbeidet innenfor prosessen man modellerer. En task kan bli dekomponert til mindre tasker, det vil si at taskene da er mer detaljert, og en task kan da altså være en del av en større task. En task kan innholde objekter av typen rolle og objekter av typen abstrakt-beslutningspunkt. Rollene står nærmere beskrevet under kapittel 5.2.2; Roller, og de er tilgjengelige gjennom relasjonen has resource role som går mellom tasken og rollene som er inkludert i tasken. Abstrakt-beslutningspunkt inkluderer blant annet innputport og utputport og er betingelser for å starte og avslutte tasken. Tasken kan også inneholde andre abstrakte beslutningspunkter som milepæler og generelle beslutningspunkter. Disse er tilgjengelige gjennom haspart-relasjonen fra tasken til det abstrakte beslutningspunktet. Symbolet til tasken er vist i figur 11. Man ser av figuren at taskene har forskjellige farger. De får en farge etter hvilken status de har rapportert. Den nederste rette linjen avgrenser området satt av til roller eller ressurser. Alle roller eller ressurser som er definert innenfor tasken er visualisert under denne linjen som vist i figur 10. Figur 10: Objekt rolle i sammenheng med en task Sirklene inni taskene er innput port (den venstre) og utput port (den høyre). Figur 11: Task Vanligvis er input porten plassert til venstre i figuren og output porten er plassert il høyre. Det er mulig å forandre på dette hvis formålet er at modellen skal bli enklere å lese og forstå, eller hvis man vil forhindre at linjer krysser hverandre, eller man vil forhindre linjer med mange kurver. En task har slutt-tid, varighet og tilstand. De definerte tilstandene er planned, waiting, ready, ongoing, suspended, finished og terminated. 40

41 Abstrakt beslutningspunkt Abstrakt beslutningspunkt er delt inn i beslutningspunkt, milepæl (som igjen er delt inn i finish og start), innput port og utput port. Beslutningspunkt Beslutningspunkt kan sees på som enhetlige tasker med null varighet, bare brukt for å representere bestemmelser som er nødvendig for å uttrykke forgrening i tasknettverket. Et beslutningspunkt uttrykker en beslutning. Oppførselen til beslutningspunktene er definert av Logic Relation [5], som beskriver hvordan man skal håndtere mange flyter inn eller ut av et beslutningspunkt. Logical Relation kan ha èn av følgende tre verdier: 1) and: alle innkommende flyter må være aktivert for at beslutningspunktet skal bli aktivert. 2) xor: med en gang èn innkommende flyt er aktivert, blir beslutningspunktet aktivert. Og så blir nøyaktig èn av de utgående flytene aktivert. 3) unspecified: hva som skal skje med hensyn til mange innkommende og utgående flyter må bli bestemt av noen andre enn de innkommende flytene, vanligvis gjøres dette av brukerne. Legg merke til at i den nåveærende versjonen av EEML, bør man unngå å bruke mange flyter i mer enn èn retning. Med andre ord; hvis det er mange flyter inn til et beslutningspunkt, burde bare èn utgående flyt bli satt sammen med beslutningspunktet, og vice versa. Symbolet til et beslutningspunkt er vist i figur 12: Figur 12: Beslutningspunkt 41

42 Milepæl Milepæl fenomenet brukes for å angi et beslutningspunkt, hvor beslutningspunktet blir betraktet å være spesielt viktig i prosessen den er en del av. Symbolet for milepæl er vist i figur 13 under: Figur 13 : Milepæl Milepæl er delt inn i Finish og Start. Finish Finish fenomenet er av typen milepæl og brukes for å betegne det beslutningpunktet hvor totalprosessen er ferdig. finish -symbolet er vist i figur 14: Figur 14 : Finish Start Start fenomenet er en type milepæl. Den brukes for å vise beslutningspunktet hvor prosessen starter. Start symbolet er vist i figur 15: Figur 15 : Start Innput port En innput port er en nødvendig komponent som enhver task har. Den indikerer flyten som må være tilstede før man starter opp tasken. En task har kun èn innput port. Hvis mer avanserte logiske relasjoner skal bli modellert, må man gjøre dette ved å legge til beslutningspunkter inni tasken. 42

43 Utput port En utput port er en nødvendig komponent som enhver task må ha. Den indikerer flyten som må sendes ut før man kan gjøre seg ferdig med tasken. En taks har kun én utput port. Hvis mer avanserte logiske relasjoner skal bli modellert, må man gjøre dette ved å legge til beslutningspunkter inni tasken. Innput og utput er uatskillelige fra tasken de hører til, derfor kan ingen av de bli opprettet eksplisitt av brukeren Roller Her vil jeg først ta for meg rollen Person, deretter rollen Verktøy, rollen Objekt og til slut presenterer jeg rollen Organisasjonsenhet. I figur 16 er EEML sine rollerfenomener vist i hierkarkiet. «type» role «EE Process» personrole «EE Process» orgunitrole «EE Process» objectrole «EE Process» toolrole Figur 16 : EEML sine rollefenomener og hvordan de hører sammen i hierarkiet. Rolle er et generelt begrep. En rolle bekles av en ressurs som er et spesielt begrep. Dette betyr at for eksempel rollen Person er generell og inneholder prosjektleder. Ressursen Person er spesiell og bekler rollen Person og innholder Nils Nilsen. 43

44 Sammenhengen rollen er i må alltid forklares, og dette innebefatter 1) virksomheten sett under ett 2) organisasjonelle deler innenfor virksomheten 3) en oppgave innenfor virksomheten Den nåværende versjonen av EEML håndterer bare roller av type 2) over. Roller kan bli sett på som erstatninger for ressurser. Rollene deles opp i mindre underenheter, og det kommer an på hvilke ressurser som spiller rollene, hvordan de deles opp. EEML skiller mellom forskjellige typer roller. Jeg tar for meg rollen Person, deretter beskriver jeg rollen Verktøy og så tar jeg for meg rollen Objekt. Til slutt ser jeg på rollen Organisasjonsenhet. Rollen Person En person er den eneste som kan inneha rollen Person. Symbolet er vist i figur 17: Figur 17 : Person Rolle Rollen Verktøy Både Software Verktøy og Manuelt Verktøy kan være en Verktøy Rolle. Symbolet er vist i figur 18 : Figur 18 : Verktøy rolle 44

45 Rollen Objekt En rolle av typen Objekt kan være både et material objekt eller et informasjons objekt. Den kan bli brukt til å modellere passive roller. Men det er også mulig å modellere aktive roller, siden material objektet kan representere ikke-mennekser, og disse kan delta aktivt i en prosess eller et system. Rollen representerer ressurser som er utviklet, brukt eller oppbrukt i tasken. Objekt rollen er vist i figur 19: Figur 19 : Objekt rolle Rollen Organisasjonsenhet Det er kun en organisasjon som kan inneha rollen Organisasjonsenhet. Organisasjonsenhet rollen brukes typis til å uttrykke ett av følgende: 1) til å representere en gruppe av personer. I slike tilfeller er en gruppe definert som èn enhet som har denne rollen, ikke individene innenfor gruppen. 2) Usikkerhet/ubeslutsomhet: Rollen i seg selv må tydelig betegne en del som må spilles av èn eller flere individer. Uansett vil vi heller kunne uttrykke hvilken organisasjon aktøren kommer fra i stedet for å vite identiteten til den enkle aktøren. Dette kan bli modellert ved å introdusere rollen Organisasjonsenhet i stedet for Person rollen. I dette tilfellet vil de organisasjonsobjektene som har disse rollene måtte bli tolket som et sett av kandidater og ikke bestemte deltakere. Symbolet for organisasjonsenhet-rolle er vist i figur 20: Figur 20 : Organisasjonsenhet- rolle 45

46 5.2.3 Ressurser I dette kapittelet tar jeg for meg ressursen Person, ressursen Organisasjon, ressursen Verktøy som deles inn i Software verktøy og Manuelt verktøy. Til slutt ser jeg på ressursen Objekt som deles inn i Informasjons objekt og Material objekt. Ressurser er altså det man fyller rollene med når man vet mer spesielt hva rollene skal inneholde. I figur 21 er ressursfenomenene presentert i hierarki. «type» resource «EE Resource» person «EE Resource» organization «type» tool «type» object «EE Resource» softwaretool «EE Resource» manualtool «EE Resource» materialobject «EE Resource» informationobject Figur 21: EEML sine ressursfenomener og hvordan de hører sammen i hierarkiet. Ressursen Person Symbolet i figur 22 brukes for å representere mennesker/ personer. En person- ressurs kan settes til å fylle en Person- rolle. Kun én person- ressurs kan fylle en Person- rolle. Figur 22 : Person 46

47 Ressursen Organisasjon En annen ressurs er organisasjon som vist i figur 23. Symbolet brukes for å representere alle typer organisasjoner. Figur 23 : Organisasjon Ressursen Verktøy Verktøy deles inn i Software verktøy og Manuelt verktøy. Software verktøy Symbolet er vist i figur 24. Figur 24 : Software verktøy Dette symbolet brukes når man skal vise aktuelle software applikasjoner eller software komponenter som man trenger for å utføre en gitt task. EEML har ingen begrensing i forhold til detaljeringsgrad. For eksempel kan man velge å modellere MS Office som ett software verktøyobjekt, eller man kan modellere det som flere objekter og dele de inn i hver og èn applikasjon; MS Word, MS Excel og så videre. Manuelt verktøy Dette symbolet brukes for å representere fysiske verktøy som man trenger for å utføre arbeid. EEML setter ingen begrensninger i forhold til hvor detaljert det skal modelleres. Symbolet er vist i figure 25: Figur 25 : Manual verktøy 47

48 Ressursen Objekt Objekt deles inn i Informasjons objekt og Material objekt Informasjons objekt Dette symbolet brukes til å representere informasjonsskilder og ressurser, som for eksempel dokumenter, bøker, tekst filer, databaser og så videre. Noen informasjonsobjekter har også materielle eller fysiske aspekter. Måten man løser det problemet på er å modellere bøker, dokumenter og lignende som informasjonsobjekter, når fokus er på informasjonsinnholdet og ikke på de fysiske egenskapene. Symbolet er vist i figur 26: Figur 26 : Informasjons objekt Material objekt Material objektet brukes til å representere kunstige objekter og fysiske objekter. Se figur 27: Figur 27 : Material objekt Relasjoner i EEML EEML har mange forskjellige relasjoner mellom prosessene, ressursene og rollene. Relasjonene som blir beskrevet i dette kapittelet er Flow, Carries Resource, Is Filled By, Has Part og Has Resource Role. Jeg velger å ha overskriftene på relasjonene på engelsk, men i omtale i teksten bruker jeg norske ord. Ønskes forklaring på flere relasjoner enn de under, se [5]. Flow Flyt er relasjonen mellom to abstrakte beslutningspunkt, det være en innputport, utputport, milepæl eller beslutnings punkt. Flyten viser i hvilken rekkefølge man skal lese modellen, hvilket prosesselement som kommer når. 48

49 Det er tre restriksjoner på hva slags abstrakte beslutningspunkter som kan være forbundet med flyt: 1) Flyt fra en innput port til en output port betyr at man kortslutter en eller flere tasker, og det er ikke lov. Alle andre kombinasjoner er greit, så lenge punkt 2 og 3 under er tilfredsstilt. 2) All flyt til en innput port må komme utenfra tasken tilknyttet den gitte innput porten. All flyt fra en innput port må ha som mål et abstrakt beslutningspunkt innenfor den tasken som er tilknyttet den gitte innput porten (eller en subtask av den). 3) All flyt fra en output port må ha som mål et abstrakt beslutningspunkt utenfor den tasken tilknyttet den gitte output porten. All flyt til en output port må komme fra et beslutningspunkt innenfor den tasken som er tilknyttet output porten. Dette betyr følgende: En innput port kan ha flyt til seg fra ethvert annet abstrakt beslutningpunkt utenfor tasken tilknyttet inntput porten, inkludert andre innput porter. En output port kan ha flyt fra seg til alle andre beslutningspunkter utenfor beslutningspunktets task, inkludert andre output porter. De abstrakte beslutningspunktene som er bundet til andre beslutningspunkt kan bli plassert relativt til hverandre på to måter: 1) De to forbundede abstrakte beslutningspunktene er inkludert i adskilte tasker, hvor ingen av dem er subtasker av de andre. I dette tilfellet forteller flyten i hvilken sekvens taskene skal utføres i; den antatte arbeidsflyten. På den måten uttrykker flyt en sekvensiell avhengighet mellom de sammenbundede taskene. 2) De forbundede beslutningspunktene er inkludert i adskilte tasker som er subtasker av hverandre. Dette kan bli brukt i mange situasjoner, for eksempel loops og exists. Symbolet for flyt er vist i figur 28. Figuren indikerer en flyt mellom to abstrakte beslutningspunkter, start og innputport. Figur 28 : Flyt 49