prototypframställnig för tidrapportering i oracle e-business...

Prototypframställning

för tidrapportering i

Oracle E-Business Suite R12

Prototype development of a Working Time Reporting Solution in Oracle E-Business Suite R12

Nikki Chau

Examensarbete inom teknik och management, grundnivå

Kandidat

Degree Project in Engineering and Management, First

Level

Stockholm, Sweden 2012

Kurs IK120X, 15hp

TRITA-ICT-EX-2012:154

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Sammanfattning

I

SAMMANFATTNING

Detta examensarbete har genomförts på företaget Navigate Consulting

Business Solutions AB, ett konsultbolag som erbjuder tjänster inom

affärssystem, såsom val av affärssystemslösning, implementering och

förvaltning.

Företaget vill utöka sitt framtida affärssystem, Oracle E-Business Suite R12,

genom att lägga till tidrapporteringsmodulen Oracle Time and Labor. För

att ta reda på om tidsrapporteringsmodulen möter verksamhetens krav

och förväntningar är det nödvändigt att företaget får en uppfattning hur

systemet möjligtvis kan lämpa sig, innan de bestämmer sig för att

implementera.

Med detta som bakgrund och utgångspunkt syftar detta examensarbete

till att visualisera den tidrapporteringsprocess och de krav som Navigate

har för Oracle E-Business Suite R12, genom användning av prototyp.

En inkrementell och iterativ arbetsmetod har tillämpats vid utveckling av

denna prototyp. Resultatet av detta examensarbete är en interaktiv

prototyp över företagets tidrapporteringsprocess. Stora delar av deras

krav har visualiserats, och det har totalt producerats femton skärmbilder

för att utveckla prototypen. Dessa har kopplats samman och tillförts med

interaktivitet genom prototypverktyget Justinmind Prototyper.

Trots att det har inneburit en tidskrävande process för utveckling av

prototypen har man funnit potentiella fördelar. Jämfört med stillbilder

(traditionella skärmbilder), fångar en interaktiv prototyp fler aspekter av

systemet som kan förmedlas till användaren. Detta skulle möjligtvis

kunna vara ett effektivt säljverktyg för Navigate vid försäljning av

exempelvis Oracle E-Business Suite R12.

För att utvecklingstiden ska kunna minskas bör därför Navigate bygga

upp ett eget ramverk.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Abstract

II

ABSTRACT

This bachelor thesis has been carried out at Navigate Consulting Business

Solutions AB, a consulting firm that provides enterprise resource planning

(ERP) services, such as choice of ERP system solutions, implementation

and management.

The company is currently looking to expand their future ERP system,

Oracle E-Business Suite R12, by supplementing the time reporting module

Oracle Time and Labor. To find out if the system meets the business’s

requirements and expectations, it is necessary for the company to get an

idea of how well the system may be suited before they decide to

implement it.

With this basis, the aim of this bachelor thesis is to visualize the time

reporting process and the requirements Navigate has for Oracle

E-Business Suite R12, by using a prototype.

An incremental and iterative method has been applied for the

development of this prototype. The result of this bachelor thesis is an

interactive prototype of the company's time reporting process. Several of

their requirements have been visualized, and a total of fifteen screenshots

have been produced for the development of the prototype. The

screenshots have been connected together and supplied with interactivity

through a prototyping tool called Justinmind Prototypes.

The development of the prototype has been a time consuming process, yet

despite this, potential benefits have been discovered. Compared to stills

(traditional screenshot), an interactive prototype captures several aspects

of the system which can be conveyed to the user. This could possibly serve

as an effective sales tool for Navigate in the sale of e.g. Oracle E-Business

Suite R12.

To reduce the development time is recommended that the company builds

up its own framework.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Förord

III

FÖRORD

Detta examensarbete om 15 hp är ett avslutande moment inom kandidat-

programmet Affärssystem vid Kungliga Tekniska högskolan. Arbetet har

utförts i samarbete med Navigate Consulting Business Solutions AB under

våren 2012.

Ett stort tack ska främst riktas mot Mats Eriksson och Peter Johansson från

Navigate. Deras stöd och engagemang har varit ovärderlig under arbetets

gång. Ett särskilt tack ska riktas till Helene Wenster som bidragit med

värdefulla kunskaper och tips.

Jag vill också tacka min examinator Anders Sjögren som gett konstruktiv

kritik och vägledning.

Slutligen vill jag tacka Ida Johansson och Maria Örnjäger som genomförde

deras examensarbete parallellt med mig. Det har varit en intressant resa

med många nya lärdomar och intryck.

Tack alla!

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Innehållsförteckning

IV

INNEHÅLLSFÖRTECKNING

SAMMANFATTNING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I I

FÖRORD .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I I I

FIGURFÖRTECKNING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

TABELLFÖRTECKNING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

1 INLEDNING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 BAKGRUND .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 PROBLEMFORMULERING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 SYFTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 MÅL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 AVGRÄNSNINGAR .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 TEORETISK REFERENSRAM .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 PROTOTYP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Definition ........................................................................................................ 3

2.1.2 Syfte ................................................................................................................ 3

2.1.3 Prototyper av olika karaktärer........................................................................ 4

2.1.4 Prototyper av olika fokus ................................................................................ 5

2.1.5 Prototyper av olika aspekter .......................................................................... 6

2.1.6 För- & nackdelar med prototyper................................................................... 7

2.2 PROTOTYPUTVECKLINGSM ETODER .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Evolutionär ..................................................................................................... 8

2.2.2 Throw-away .................................................................................................... 9

2.3 JUSTINMIND PROTOTYPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 METOD/MODELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 PROCESSMODELL FÖR PROTOTYPUTVECKLING .. . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 UTVECKLINGSMODELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 UTVECKLINGSMETOD ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 RESULTAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 ANALYS & DISKUSSION .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 ÖVRIGT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

KÄLLFÖRTECKNING .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

BILAGA A: TIDRAPPORTERING I ORACLE E-BUSINESS SUITE R12 . . . . . . . . . . . . 27

BILAGA B: KRAVSPECIF IKATION .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

BILAGA C: SKÄRMBILDSÖVERSIKT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

BILAGA D: SKÄRMBILDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Figurförteckning & Tabellförteckning

V

FIGURFÖRTECKNING

Figur 2.1 – Hur prototyper kan skäras på olika sätt ............................................................ 5

Figur 2.2 – Fyra dimensioner i modellen. ............................................................................ 6

Figur 2.3 – Prototyputvecklingsmetoder ............................................................................ 8

Figur 3.1 – Processmodell för prototyputveckling ............................................................ 11

Figur 3.2 – Evolutionär utvecklingsmodell ........................................................................ 12

Figur 3.3 – Inkrementell och iterativ utvecklingsprocess ................................................. 13

Figur 4.1 – Vad prototypen avser att testa ....................................................................... 15

Figur 4.2 – Scenariot för den centrala tidregisteringsprocessen i prototypen. ................ 16

Figur 4.3 – Variabelanvändning i prototypen ................................................................... 19

Figur 4.4 – Scenariot vid granskning av inlämnad tidrapport. .......................................... 21

Figur 5.1 – Tidrapporteringsflödet i Oracle EBS R12. ........................................................ 27

Figur 5.2 – Processflöde för att skapa tidrapport i Oracle EBS R12 .................................. 28

TABELLFÖRTECKNING

Tabell 5.1 – Kravspecifikation. .......................................................................................... 30

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Inledning

1

1 INLEDNING

1.1 BAKGRUND

Att implementera ett affärssystem kräver mycket kapital i form av tid,

pengar och kunskap. Vid utbyte av affärssystem påverkas hela

verksamheten i ett företag, det är inte bara ett teknikskifte som berör vissa

processer i arbetsflödet. Det är därför viktigt att säkerhetsställa att

affärssystemet tillgodoser och stödjer alla affärsprocesser i företaget [1].

Innan man implementerar ett affärssystem kan man därför använda sig av

en prototyp för att undersöka om det är möjligt eller lönsamt. Vad som

menas med prototyp kommer att vidareutvecklas senare i denna rapport.

Detta examensarbete har genomförts på företaget Navigate Consulting

Business Solutions AB (Navigate) under våren 2012. Företaget är ett

konsultbolag bestående av 17 anställda med en omsättning på cirka

23 miljoner kronor. De bedriver sin verksamhet inom området

affärssystem och erbjuder tjänster som val av affärssystemslösning,

implementering och förvaltning. De arbetar främst med produkter från

Oracle och har därför också sin expertis inom det område. Navigate

affärsidé är ”marknadens bästa kompentens för hantering av affärssystem”

och deras målsättning är ”bäst på att driva och genomföra

affärssystemsprojekt” [1].

Navigate har tidigare beslutat att implementera Oracle E-Business Suite

R12 (Oracle EBS R12) som deras affärssystem. Moduler som kommer att

användas är huvudbok, leverantörreskontra, kundreskontra, projekt,

inköp och CRM.

Navigate vill dessutom implementera en ytterligare modul i

affärssystemet, tidrapporteringsmodulen Oracle Time and Labor (OTL).

En förstudie har därför påbörjats för undersökning av systemets

lämplighet.

Förstudieprojektet med benämning ”Förstudie för implementering av

tidrapporteringsmodulen OTL” (FIMO) har bedrivits parallellt med detta

examensarbete. Förstudieprojektet utfördes som ett examensarbete av

studenter från Kungliga Tekniska högskolan. Informationsutbyte och

samarbete har skett mellan dessa projekt för att kunna genomföra

utvecklandet av prototypen.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Inledning

2

1.2 PROBLEMFORMULERING

Som ett led i undersökning av OTLs lämplighet för Navigate är det

nödvändigt att validera systemet mot företagets tidrapporteringsprocess och

krav. Företaget behöver få en uppfattning på hur systemet möter

verksamhetens krav och förväntning innan de bestämmer att implementera.

1.3 SYFTE

Syftet med arbetet är att visualisera den tidrapporteringsprocess och de

krav som Navigate har för Oracle EBS R12, genom användning av

prototyp.

1.4 MÅL

Målet med arbetet är att producera en interaktiv prototyp över Navigates

tidrapporteringsprocess i Oracle EBS R12, med hjälp av prototypverktyget

Justinmind Prototyper.

1.5 AVGRÄNSNINGAR

Andra affärsprocesser inom Navigate, utöver tidrapportering, kommer

inte att behandlas. Således kommer heller inte andra prototypverktyg

användas under utveckling av prototypen än det som nämns tidigare, se

avsnitt ”Mål”. Denna avgränsning har gjorts på rekommendation av

examinatorn. Bristen på tid att undersöka andra alternativa

prototypverktyg har också varit en avgörande beslutsfaktor.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Teoretisk Referensram

3

2 TEORETISK REFERENSRAM

2.1 PROTOTYP

2.1.1 Definition

Ordet prototyp är väldigt tvetydig och kan uppfattas på olika sätt

beroende på vilken källa man refererar till.

Nationalencyklopedins (NE) definition för ordet prototyp är följande:

”… originalmodell, som följande former baseras på. Inom industriell

produktutveckling avses försöksmodell som är riktig i funktion,

konstruktion och utseende men inte i tillverkningsmetod.” [2].

En annan definition av ordet prototyp får vi av Sommerville I [3]. Han ser

prototyp som en första version av ett system. Den har som uppgift att

demonstrera idéer, testa designförslag, undersöka problem och möjliga

lösningar.

Houde S och Hill C [4] tolkar ordet prototyp i likande bemärkelse. De

definierar prototyp som en representation av en idé, oavsett medium.

Enligt författarna utvecklar man en prototyp för att få svar på

designfrågor, där design omfattar både formgivning och konstruktion.

Göransson B och Gulliksen J [5] betraktar prototyp som ett fungerande

system men som inte är helt färdigutvecklat.

2.1.2 Syfte

En prototyp kan användas för olika typer av syften. Användnings-

områden kan bland annat vara:

Kommunikation

Demonstration av en idé

Kravhantering

Undersöka designproblem

Utvärdera och testa lösningsförslag

Modellskelett

Utbildning och marknadsföring


4

Prototyper kan användas som ett verktyg för kommunikation mellan

systemutvecklare och kund. Parterna får en gemensam grund att utgå

ifrån och får förståelse på vad som egentligen ska utvecklas/levereras. En

idé blir mycket mer konkret genom att demonstrera det med hjälp av en

prototyp och kan därför användas i marknadsföringssyfte [6].

En annan anledning är att prototyper kan vara ett medel under

kravhanteringsprocessen. Visualiserar krav men också ett sätt att samla

och validera systemkrav [3].

Med en prototyp kan man simulera delar i ett system för att testa

lösningsförslag eller kartlägga användarbarhetsproblem. I vissa fall kan

prototypen användas som ett underlag till utveckling av ett system.

Prototypen agerar som ett modellskelett som man successivt bygger ut till

ett fungerande system [6].

För att utbilda användare i ett system kan man använda prototyp i

utbildningssyfte. Det ger användarna en möjlighet att öva sig innan det

riktiga systemet levereras.

2.1.3 Prototyper av olika karaktärer

Ett sätt att dela in prototyper på är graden av detaljnivå. Det kan förklaras

med hur verklighetstroget prototypen är mot slutprodukten. Till exempel

kan skillnaden på graden av detaljnivå vara utseendemässiga men också

datamässigt, interaktionsmässigt (animering, system respons m.m.) och

funktionsmässigt.

2.1.3.1 Low fidelity

En low fidelity prototyp ligger på en högre abstraktnivå och skiljer sig långt

från den slutgiltiga produkten [6]. Dessa brukar framställas med hjälp av

simpla verktyg som exempelvis papper och penna, post it-lappar och

PowerPoint. Man brukar använda low fidelity prototyper för att generera

fram krav och testa innehåll/logik i processflödet [6].

2.1.3.2 High fidelity

En high fidelity prototyp har en lägre abstraktnivå än low fidelity dvs. den

har en högre grad av detaljnivå. Dessa prototyper brukar oftast vara

interaktiva och datorbaserade eftersom de försöker efterlikna den

slutgiltiga produkten så mycket som möjligt. High fidelity prototyper

används med fördel för att testa gränssnittet och integrationen mellan


5

användaren och systemet [6]. Lämpar sig ofta som marknadsförings-

verktyg tack vare att prototypen ser färdigutvecklat ut.

2.1.4 Prototyper av olika fokus

Prototyper kan skäras på olika sätt beroende på vilket syfte de har [5], se

Figur 2.1. Det kan finnas flera eller färre lager än vad som presenteras i

figuren och det behöver inte nödvändigtvis vara användargränssnittet

som är det översta lagret. Modellen är en förenkling av verkligheten för att

få en lättare förståelse för konceptet.

Figur 2.1 – Hur prototyper kan skäras på olika sätt. [5]

2.1.4.1 Vertikal

Prototyper som skär vertikalt, skär på djupet där alla lager inkluderas. Det

menas med prototypen utvecklas som en del av systemet fullt ut. All

funktionalitet inom den delen av systemet finns representerad i en vertikal

prototyp [5][7].

2.1.4.2 Horisontell

Horisontella prototyper skär endast genom ett enda lager. Till exempel

kan en horisontell prototyp utvecklas för hela användargränssnittet. Men

det ligger ingen funktionalitet bakom [5].

Användargränssnitt Användargränssnitt Användargränssnitt

Logik Logik Logik

Data Data Data

Vertikal Horisontell Scenario


6

2.1.4.3 Scenario

Scenario prototyper är ett enklare variant av vertikal prototyp, men som

inte inkluderar alla lager. Den är baserad på att göra en vis typ av

arbetsuppgift eller aktivitet [5].

2.1.5 Prototyper av olika aspekter

Enligt Houde S och Hill C [4] fokuserar man alldeles för mycket på

prototypens egenskaper, vilket språk och verktyg som används för

framställning. Denna fixering kan ge en förutfattad mening på

prototypens egentliga syfte.

Därför har Houde S och Hill C introducerat en annan typ av synsätt, där

fokuseringen ligger i vad prototypen syftar att testa. De nämner tre

dimensioner: Role (funktionalitet), Look and feel (utseende och känsla) och

Implementation, se Figur 2.2. Varje dimension representerar en viktig

aspekt som prototypen kan användas för att undersöka.

Figur 2.2 – Fyra dimensioner i modellen. Triangeln är ritat medvetet skev för att poängtera att ingen dimension i sig är viktigare än någon annan. [4]

2.1.5.1 Funktionalitet

Denna dimension handlar om vilken roll som systemet ska spela hos

användaren, dvs. vilka funktioner som systemet ska ha. En

funktionalitetsprototyp beskriver funktioner som en användare ska ha

nytta av [4]. Ett exempel kan vara en skiss över de aktiviteter som en

webbsida tillhandahåller, exempelvis kundvagn, beräkning av frakt m.m.

Funktionalitet

Implementation

Utseende och känsla känsa


7

2.1.5.3 Utseende och känsla

Prototyp inom denna dimension har i avsikt att utvärdera upplevelsen

som användaren får vid användning. Exempelvis kan en pizzakartong

agera som en look and feel prototyp för att underöka vilken form en bärbar

dator ska ha [4].

2.1.5.4 Implementation

Implementationsprototyper används för att undersöka tekniska aspekter.

Det handlar om tekniska lösningar för att få saker och ting att fungera.

Programkod kan vara ett exempel på en implementationsprototyp.

2.1.6 För- & nackdelar med prototyper

Enligt Tozer J [8] tillgodoses 80% av verksamhetens operationella behov

genom att bara utnyttja 20% av systemet. Med andra ord, räcker det att

bygga in 20% av kraven i prototypen för att uppnå verksamhetens

huvudsakliga behov.

Därför kan användning av prototyp vara ett effektivt sätt att utforska och

testa nya lösningar, funktionaliteter och krav, speciellt innan man

implementerar och utvecklar ett nytt system. Dessutom är det ett bra

verktyg för att hitta svagheter och testa prestanda, användargränssnitt etc.

[5]. Utvecklingskostnaderna kan även minskas eftersom eventuella

problem och hinder redan fått en lösning tidigt i processen. Det är ett

vedertaget faktum att utvecklingskostnaden ökar ju senare i processen

man gör förändringar och löser problem.

Men framförallt är prototyp ett kommunikationsverktyg mellan

utvecklare och användare [8][9]. Olsson S, Denizhan F och Lantz A. [6]

menar att prototyp kan hjälpa en att skapa en gemensam grund för ett

projekt. Det är en viktig faktor för att få en förståelse vad målet egentligen

är. Prototyp kan öka samspelet och förståelse mellan dem inblandade

aktörerna, som exempelvis projektledare, styrelsemedlemar, investerare

och andra externa intressenter.

Risker eller nackdelar som finns med prototyper är att användarna kan få

för höga förväntningar [9], som slutprodukten inte kan leverera. En

prototyp som utvecklas på väldigt kort tid skapar förväntning om att det

kommer ta lika lång tid att utveckla eller implementera det riktiga

systemet [8]. Speciellt gäller det för high fidelity prototyper. Kunden ser i

själva verket bara ett skal och kanske inte förstår att det egentligen inte


8

finns någon data eller logik bakom fasaden. Funktionaliteten i en prototyp

kan vara ”fejkad”, ett simulerat beteende i systemet som ännu inte är

implementerad eller utvecklad. I slutändan handlar det om en

missuppfattning om hur mycket arbete som återstår till det slutgiltiga

systemet. Ett sätt att motverka detta är att man har en tydlig

kommunikation mot kunden [8], att denne vet innebörden med

prototypen och omfattningen av det fortsatta arbetet.

En annan risk är att den prototypen som står som utgångpunkt vid

utvecklande av det riktiga systemet inte stämmer överens med varandra.

Vilket gör att kunden inte får den produkten som denne har förväntat sig.

2.2 PROTOTYPUTVECKLINGSMETODER

Det finns två huvudkategorier inom metoder för prototyputveckling,

evolutionär och throw-away. Den distinkta skillnaden mellan dessa

metoder är vad det genererar för resultat, se I Figur 2.3. En annan viktig

skillnad är även hur metoderna hanterar kvalitet i prototypen [3].

Figur 2.3 – Prototyputvecklingsmetoder. [3]

2.2.1 Evolutionär

Målet med att använda evolutionär prototyputvecklingsmetod är enligt

Sommerville I [3] att leverera ett slutgiltigt system till kunden och finna

nya krav. Det gör att man börjar med att bygga prototypen efter

användarnas krav som har högst prioritet.

Göransson B och Gulliksen J [5] utrycker det att man utvecklar en

kompromiss mellan det riktiga systemet och prototypen. Det kan förklaras

med att prototypen utvecklas successivt till det bildar det riktiga systemet.

Därför är det viktigt att välja rätt verktyg från start. Och kvaliteten måste

Throw-away utveckling

Evolutionär utveckling

Kravspecifikation

Slutgiltigt system

Prototyp +

System specifikation


9

vara på en lämplig nivå från början eftersom allt man gör i prototypen

kommer in i det slutgiltiga systemet.

En nackdel med den evolutionära metoden för prototyputveckling är att

man har en tendens att fixa brister än att försöka hitta andra lösningar

eller alternativ. Man vågar inte riktigt kasta det man har och börja om på

nytt. Vilket kan medföra att man mister en mer lämplig lösning [3].

2.2.2 Throw-away

Målet med att använda throw-away prototyputvecklingsmetod är att

validera krav eller ta fram nya krav. Därför bör man börja med att

utveckla prototypen efter de krav som man har minst koll på [3]. Eftersom

prototypen inte kommer att återanvändas i det slutgiltiga systemet, bör

man välja en teknik som är relativt billig i utvecklingskostnad [5].

Kvaliteten på prototypen behöver inte har lika hög standard jämfört med

den evolutionära metoden, eftersom den ändå ska kastas.

Som man ser i Figur 2.3 resulterar denna metod till en kravspecifikation

för systemet. Prototypens roll i det här fallet är att agera som en modell för

det slutgiltiga systemet [9].

Metoden är lämplig vid exempelvis testning av designlösningar eller

utvärdering av andra aspekter som man vill ha svar på. Nackdelen med

denna metod är att det finns risk att det slutgiltiga systemet inte

överensstämmer med prototypen.

2.3 JUSTINMIND PROTOTYPER

Justinmind Prototyper är ett programverktyg för att skapa prototyper,

interaktiva mockups och wireframes. Mockups kan beskrivas som en

generell modell över hur en eventuell webbplats eller programvara ska se

ut. Wireframes är däremot en generell modell över funktionalitet och

beteende. Tillsammans utgör de en generell benämning av ordet prototyp.

Programmet erbjuder bland annat följande:

Simulering av pekskärmsgester – Lägg till gester som svepa, tryck-

och-håll, nypa, roteringsgester etc.

Interaktivitet och data simulering – Lägg till interaktivitet som visa

och dölj innehåll, navigering med villkor, inmatingefält etc.


10

Data simulering – Lägg till data simulering i form av validering och

sökning utan att behöva koda.

Användarbarhetstest – Delningstjänst som möjliggör användare att

testa och kommentera prototypen.

Exportering – Prototypen kan exporteras till HTML format. All

information om prototypen kan exporteras till Microsoft Word och

OpenOffice. Verktyget Justinmind Prototyper finns för närvarande i två olika versioner.

Ena som en 30-dagars testversion med stöd för all funktionalitet. Den

andra är en gratisversion med begränsad funktionalitet.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Metod & Modell

11

3 METOD & MODELL

3.1 PROCESSMODELL FÖR PROTOTYPUTVECKLING

Arbetet med prototypen har baserats enligt en procesmodell för

prototyputveckling, se Figur 3.1. Modellen visar fyra olika moment

(rektangel med runda hörn), där varje moment leder till ett resultat.

(rektangel). De streckade linjerna mellan resultaten och momenten visar

deras beroendeförhållande, resultatet som har tagits fram i föregående

moment används till nästkommande moment.

Aktiviteten inlärning av prototypverktyg har lagts till i den ursprungliga

modellen, för att belysa tiden som behövdes för lära sig att använda

verktyget. Men också den tiden för att undersöka verktygets möjligheter

och begränsningar.

Figur 3.1 – Processmodell för prototyputveckling. [3]

Processen startar med att fastställa syftet med prototypen och utifrån det

kunna göra en plan för prototyputveckligen. Beroende på vilket syfte

prototypen har kommer utvecklingsplanen se annorlunda ut från fall till

fall, eftersom olika avsikter kräver skilda typer av aktiviteter. Nästa steg är

att definiera funktionaliteten på prototypen, dvs. bestämma sig vilka

funktioner som ska ingå och vilka funktioner som ska lämnas utanför. Här

kan man utgå ifrån kraven som kunden har på systemet för att kunna

definiera funktionaliteten. Det är viktigt att de funktioner som man tar

med i prototypen går i linje med prototypens syfte, för att säkerställa att

man utvecklar rätt prototyp för ändamålet. Nästföljande momentet är att

Fastställa syftet med prototyp

Definiera funktionalitet i

prototyp

Utveckla prototyp

Utvärdera prototyp

Plan för prototyp-utveckling

Översiktlig beskrivning

Prototyp Utvärderings-

rapport

Inlärning av prototypverktyg


12

utveckla prototypen, under avsnittet ”Utvecklingsmetod” beskrivs den

utvecklingsmetod som har används under arbetet. Sista stegen i processen

är att utvärdera prototypen. I det här fallet kommer resultatet av

utvärderingen vara avsnittet ”Analys & Diskussion” i denna rapport.

3.2 UTVECKLINGSMODELL

Vid utvecklingen av prototypen kommer inte alla krav vara fastställda vid

projektets start. Kraven kommer dessvärre uppdateras och tillkomma

under processens gång. Därför har utvecklingsarbetet följt en modell som

Sommerville J [3] benämner som evolutionär utvecklingsmodell,

se Figur 3.2. Tanken är att en första version av prototypen utvecklas

väldigt snabbt utifrån en översiktlig beskrivning. Prototypen kommer att

förfinas genom flertals versioner innan den slutgiltiga versionen arbetas

fram. Därför kommer aktiviteter som kravhantering, utveckling och

validering att bedrivas parallellt. Det ger tid för återkoppling mellan både

aktiviteterna och kunden.

Notera dock att kravhantering inte har behandlats i denna rapport. Denna

aktivitet är den del av förstudieprojektet som har bedrivits parallellt med

detta projekt, se avsnitt ”Bakgrund” för mer information.

Figur 3.2 – Evolutionär utvecklingsmodell. [3]

Parallella aktiviteter

Kravhantering

Utveckling

Validering

Första version

Översiktlig beskrivning

Mellanliggande version

Slutgiltig version


13

3.3 UTVECKLINGSMETOD

Utifrån modellen som nämndes i avsnitt ”Utvecklingsmodell” har en

inkrementell och iterativ utvecklingsmetod tillämpats under utvecklingen

av prototypen. Med inkrementell utveckling menas med att prototypen

byggs stegvis, där man succesiv bygger på prototypen med tillägg [3].

I varje tillägg finns nya funktioner som sedan integreras med den

befintliga prototypen.

Figur 3.3 – Inkrementell och iterativ utvecklingsprocess. [3]

Fokus har lagts på de centrala och viktigaste funktionerna. De mindre

viktigare funktionerna har tillkommit senare eller inte alls beroende på om

tiden har räckt till. Fördelen med denna metod är att man säkerställer att

de centrala delarna kommer med från första början, vilket gör att de

delarna också får mest tid för testning och bearbetning [3].

Med iterativ utveckling menas med att man upprepar samma process om

och om igen för att förbättra och hitta eventuella brister eller fel. På detta

sätt kan man fånga upp saker som blivit felaktiga och saker som man har

missat, förhoppningsvis tidigt under utvecklingsprocessen.

Nackdelen med inkrementell och iterativ utvecklingsmetod är att det kan

motverka idéer till radikala förändringar, som kanske skulle leda till en

bättre lösning på problemet [7]. Eftersom man alltid strävar till förbättring

av det som hittills har utvecklats. Det blir därför svårt att tänka om i nya

banor. Det finns också en risk att en dålig lösning bygger upp ett helt

Definiera innehåll i prototyp

Specificera prototyp

tillägg

Bygga prototyp

tillägg

Validera tillägg

Prototyp färdig?

Integrera tillägg

Validera prototyp

Design av prototyp-arkitektur

Leverera slutgiltig prototyp


14

projekt, där brister lappas ihop på vägen. Det kan resultera till en

slutprodukt med alldeles för många kompromisser.

Figur 3.3 är ett exempel på hur man kan arbeta efter ett inkrementell och

iterativ utvecklingsprocess. Notera att vid en inkrementell arbetsmetod

arbetar man också iterativt. Detta kan uttydas genom loopen som finns i

högra delen av figuren.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Resultat

15

4 RESULTAT

En interaktiv prototyp har utvecklats baserat på material från

förstudieprojektet FIMO. De material som har tagits del av är

kravspecifikation och den framtida tidrapporteringsprocessen hos

Navigate. För dem läsare som är intresserade hänvisas till FIMOs rapport

för respektive dokument.

Justering av Navigates framtida tidrapporteringsprocess har gjorts. Detta

för att anpassa deras flöde efter systemet. En processkarta har tagits fram,

denna finner ni under Bilaga A.

Prototypen som har arbetats fram skulle kunna definieras som en

blandning av high fidelity och low fidelity (se avsnitt ”Prototyper av olika

karaktärer”). Med detta menas att prototypen ser verklighetstrogen ut och

uppför sig som det riktiga systemet, därav high fidelity men det finns ingen

riktig fungerande teknik bakom funktionaliteterna, därav low fidelity. Den

är också scenariobaserad (se avsnitt ”Prototyper av olika fokus”) eftersom

prototypen endast skär i användargränssnittslager och logiklager.

Dessutom är inte all funktionalitetet inom modulen OTL inkluderad.

Figur 4.1 – Vad prototypen avser att testa. [4]

I Figur 4.1 visar vilka aspekter som prototypen syftar att testa enligt

modellen från Houde S och Hill C [4] (se avsnitt ”Prototyper av olika

aspekter”). Figuren visar att koncentrationen har varit mot dimensionerna

funktionalitet samt utseende och känsla. Och att dimensionen

implementation varit helt utesluten under utvecklingen.

Hela prototypen kan simulera stora delar av de krav som företaget har

ställt. För ytterligare information om kraven som har berörts, se

kravspecifikationslista under Bilaga B. För en fullständig lista över vilka

Funktionalitet

Implementation

Utseende och känsla

Prototypen


16

krav som Oracle EBS R12 stödjer, hänvisas till gap analysen i FIMOs

rapport.

I Figur 4.2 presenteras den centrala tidrapporteringsprocessen i

prototypen. Den visar hur man skapar en tidrapport och skickar det

vidare för godkännande. Varje rektangel representerar en skärmbild dvs.

det innehåll som visas på skärmen. Totalt har femton skärmbilder

producerats för att på ett så verklighetstroget sätt kunna

simulera tidrapporteringsflödet i Oracle EBS R12. Gränssnittet

på alla skärmbilder är baserat på Oracle EBS R12. Visuellt finns

det ingenting som är annorlunda från det riktiga systemet.

Figur 4.2 – Scenariot för den centrala tidregisteringsprocessen i prototypen. Beskrivet med skärmbilder.

Skärmbilderna har producerats genom en kombination av ”print screen”

(kopiera bildskärmens innehåll) från det riktiga systemet och

manipulation i bildverktyget Photoshop. Dessa har sedan länkats samman

i prototypverktyget Justinmind Prototyper. Med samma verktyg skapades

även andra typer av interaktivitet såsom validering, data simulation,

klickbara länkar och knappar m.m.

Login

OTL meny

Recent Timecards

Review

Templates

Create Timecard

Homepage

Confirmation


17

En fullständig karta över alla skärmbilderna som har producerats finns

under Bilaga C. Kartan beskriver dessutom skärmbildernas förhållande till

varandra.

Nedan följer beskrivning av de skärmbilder som ingår i den centrala

tidrapporteringsprocessen. I Bilaga D finns alla skärmbilderna visuellt

beskrivna.

1. LOGIN

Processen startar med att användaren ska logga in på Oracle EBS R12.

Skärmbilden består av två inmatningsfält, ”User Name” (användarnamn)

och ”Password” (lösenord). För att logga in behöver användaren ange rätt

användarnamn och lösenord. Simulering av denna funktionalitet finns

genom en when-funktion när man klickar på knappen ”Login”.

Funktionen kollar att båda fälten har rätt kombination av värden.

Uppfyller de kraven skickas man vidare till nästa skärmbild, annars får

man ett felmeddelande.

2. HOMEPAGE

Denna skärmbild är det första som presenteras för användaren efter en

lyckad inloggning. Här kan det finnas flera menyer med genvägar som

leder till olika funktioner i affärssystemet. Menyn anpassas till

användaren beroende på vilken behörighet som denne har. I det här fallet


18

finns det endast en meny, NC Navigate OTL Timecards. Den är klickbar

som leder till nästa skärmbild ”OTL Meny”.

3. OTL MENY

Tre klickbara länkar har skapats: Recent Timecards (Senaste tidrapporter),

Create Timecard (Skapa tidrapport) och Templates (Mallar). Varje länk är

kopplad till respektive skärmbild, se Figur 4.2.

4. CREATE TIMECARD (SKAPA TIDRAPPORT)

I den här skärmbilden registrerar man sin tid under en viss period. Det

finns inmatningsfält för respektive dag i veckan, projekt (project), aktivitet

(activities) och utgiftstyp (type).

För att simulera integrationen med projektmodulen kan man endast välja

fördefinierade projekt, aktiviteter och utgiftstyp. Varje projekt har i sin tur

ett antal aktiviteter som är kopplade till sig. Det betyder att beroende på

vilket projekt man väljer, blir endast vissa aktiviteter valbara. Funktionen

data master har används för att kunna simulera detta beteende.

Data master är Justinmind Prototypers motsvarighet till array eller databas.

Information om projekt, aktivitet och utgiftstyp sparas i respektive data


19

master. Sedan kan värdena visas upp i skärmen i form av en tabell. Det går

dessutom att filtrera värdena dvs. begränsa till ett antal värden som ska

visas (simulering av sökningsfunktion).

Genom att trycka på förstoringsglaset i kolumnen projekt visas de projekt

som finns tillgängliga. Samma princip gäller för aktivitet och utgiftstyp.

Vid val av aktivitet behöver användaren välja projekt först eftersom de är

kopplade till varandra, som nämndes i tidigare stycke. Det går därför inte

att välja aktivitet utan att först ha valt ett projekt.

Knappen Recalculate summerar ihop timmar dygnvis, veckovis samt per

rad. Detta görs med hjälp av att addera alla inmatningsfält per dag.

All information som anges vid denna skärmbild lagras sedan i varsin

variabel, som sedan kan återanvändas på flera olika ställen. I Figur 4.3

beskriver hur användning av variabler sett ut i prototypen. Figuren visar

från vilka skärmbilder som information lagrats till variablerna och vilka

skärmbilder som har återanvänt information från variablerna.

En kontroll av inmatningsfälten görs via knappen Continue. För att komma

vidare i processen måste användare ange rätt projekt, aktivitet och

utgiftstyp.

Figur 4.3 – Variabelanvändning i prototypen.

Create Timecard

Variabel

Review Timecard

Confirmation

Recent Timecards Submitted

Timecard 02 July


20

5. REVIEW (GRANSKA)

I den här skärmbilden har de inmatade information från ”Create Timecard”

återanvänds. Information om timmar, projekt, aktivitet och utgiftstyp

laddas från variablerna.

6. CONFIRMATION (BEKRÄFTELSE)

Här får man en bekräftelse på att man har lämnat in sin tidrapport.

Information om timmar, projekt, aktivitet och utgiftstyp laddas från

variablerna.


21

FÖRLÄNGNING AV PROCESSEN

Figur 4.4 visar en förlängning av den centrala tidrapporteringsprocessen.

Denna förlängning börjar efter att man har fått bekräftelse på inlämnad

tidrapport.

Figur 4.4 – Scenariot vid granskning av inlämnad tidrapport. Processen startar efter att tidrapporten är inlämnad, dvs. efter man har gått igenom den centrala tidrapporteringsprocessen.

7. RECENT TIMECARDS SUBMITTED (SENASTE INLÄMNADE

TIDRAPPORTER)

Här presenteras de senaste tidrapporterna som användaren har skapat

eller skickat in. På första raden är tidrapporten som skapades vid

skärmbilden ”Create Timecard”. Resterande raderna är statiska

tidrapporter. De är tidrapporter som alltid finns i prototypen, en lösning

för att visa hur olika tidrapporter ser ut i systemet.

I kolumnen Timecard Status visas vilken status tidrapporten har, statusen

kan antigen vara Approved (godkänd), Rejected (avvisad), Submitted

(inlämnad) och Working (utkast, sparad men ej inlämnad). I kolumnen

Details kan man klicka för att komma vidare för mer detaljerad

information för den valda tidrapporten.

Timecard 02 July

Recent Timecard Submitted


22

8. TIMECARD 02 JULY (TIDRAPPORT 02 JULI)

Tidrapporten som skapades vid skärmbilden ”Create Timecard”

presenteras här. Information om timmar, projekt, aktivitet och utgiftstyp

laddas åter ifrån variablerna.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Analys & Diskussion

23

5 ANALYS & DISKUSSION

Med hjälp av prototypverktyget Justinmind Prototyper, Phototshop och

ett antal skärmbilder har man kunnat visualisera en rättvis bild över

Navigates tidrapporteringsprocess i Oracle EBS R12. Stora delar av kraven

har också visualiserat. Allt detta utan att ha implementerat någon del av

det riktiga systemet. Arbetets syfte och mål har därför uppnåtts.

Anledningen till varför inte prototypen omfattar alla de krav som

Navigate har ställt, är en förklaring att det helt enkelt inte fanns tid för det.

Därför blev det också en sållning bland kraven innan utvecklingsarbetet

påbörjades men också under processen. Koncentrationen har varit att

visualisera kraven som i första hand berört konsulten.

En ytterligare förklaring är att det fanns krav som inte skulle vara möjligt

att simulera med den typen av prototyp som producerades. Exempelvis

fanns ett krav som gällde stöd för olika webbläsare. Sådant krav skulle

kräva en annan inriktning på prototypen för att kunna simulera det.

Nu i efterhand har den valda utvecklingsmetoden varit en bra

utgångspunkt att arbeta efter. Det inkrementella arbetssättet passade

väldigt bra när alla kraven inte var färdigställda innan arbetet startades.

Fler och omarbetade krav kom in i processen allteftersom tiden gick. Det

iterativa arbetssättet gjorde det lättare att ställa om sig och ändra på

prototypen.

Men det har även varit rörigt att arbeta på det sättet eftersom

förutsättningarna alltid ändrades. Detta ledde till att visa delar som

arbetats fram i början inte längre var aktuella och det man har planerat att

göra behövdes revideras om. Efter många rundor av delleveranser kan det

vara en utmaning att hålla reda på alla delar. Om prototypen hade varit

större, dvs. omfattat mer så tror jag att det hade varit ohanterligt. Vid ett

sådant projekt skulle den inkrementella metoden inte vara ett passande

arbetssätt. Enligt Sommerville I [3] bör ett större projekt arbeta efter en

modell som kombinerar vattenfallsmetoden och den inkrementella

metoden.

Utvecklingsprocessen har varit tidskrävande och frågan är om det hade

tagit kortare tid att utveckla prototypen i det riktiga systemet istället. Det

vill säga att göra en uppsättning i en testmiljö direkt i Oracle EBS R12, som

faktiskt skulle kunna fungera som en prototyp inför en implementering.


24

För en person som besitter den typen av kunskap om Oracle EBS R12 och

OTL, skulle tidsåtgången möjligvis vara lägre jämfört med att bygga

prototypen med Justinmind Prototyper. Men å andra sidan borde inte

tidsåtgången minskas om personen besitter sin yttersta kunskap i

prototypverktyget. Förståelse och kunskap behövs fortfarande för Oracle

EBS R12 och OTL för att utvecklingen ska vara gynnsam

Den största faktorn till att utvecklingsprocessen har varit så tidskrävande

kan bero på att prototypen har utvecklats utifrån ett standardsystem, där

funktionalitet och utseendet redan är fördefinierade. Standardsystem i det

här fallet menas Oracle EBS R12. Ett system som är generell och passar för

flera typer av användare. Det har lett till begränsningar och ”strikta regler”

som man är tvungen att följa, gällande bl.a. användargränssnitt,

funktionalitet och beteende. Man vill inte att prototypen ska avvika från

standardsystemet. Eftersom ett avvikande inom någon av dessa

parametrar, kan vilseleda användaren. Det skapar en förväntning på

systemet som det riktiga systemet inte kommer kunna uppnå.

Med denna anledning är kanske inte utveckling av denna typ av prototyp

passande till ett standardsystem. Möjligtvis fungerar det bättre att

utveckla denna typ av prototyp för ett system under utveckling.

5.1 ÖVRIGT

Trots tidsåtgången och restriktioner i utformande av den interaktiva

prototypen, som är baserad på standardsystem, kan det fortfarande finnas

potential att utnyttja.

Prototypen som utvecklades under arbetet skulle kunna återavändas och

lätt anpassas för andra företag. På detta sätt kan det fungera som ett

effektivt säljverktyg vid försäljning av exempelvis Oracle EBS R12. Jämfört

med stillbilder (traditionella skärmbilder) fångar en interaktiv prototyp

fler aspekter av systemet som man kan förmedla till potentiella kunder.

Om det ska vara värt i tid och ansträngning för Navigate att använda

interaktiv prototyp som försäljningsverktyg bör de bygga ett eget ramverk

till prototypverktyget. Med ramverk menas med att de har färdiga delar

av gränssnittet som de kan återvända och anpassa efter behov. De kan till

exempel vara färdiga scenarier inom fakturering där man visar hur man

skickar en faktura till leverantör. Med en sådan grund skulle

tidbesparingen vara mycket stor. Speciellt vid utveckling av en

försäljningsprototyp för varje enskild kund.


25

Om detta vore av intresse för Navigate bör de titta närmare på andra

prototypverktyg som finns på marknaden än Justinmind Prototyper. Inte

för att Justinmind Prototyper är ett dåligt verktyg för ändamålet utan mer

om det kanske finns ett verktyg som skulle passa företaget bättre. Det

gäller både faktorer som pris, funktionalitet och service.

Värt att notera är att Justinmind för närvarande erbjuder ramverk för

Oracle Fusion, som är senaste uppgraderade versionen av Oracle EBS R12.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Källförteckning

26

KÄLLFÖRTECKNING

[1] Navigate Consulting Business Solutions AB. [läst 2012-06-01]

Tillgänglig: www.navigateconsulting.se

[2] Nationalencyklopedin. [läst 2012-06-12]

Tillgänglig: http://www.ne.se/lang/prototyp/287850

[3] Sommerville I. Software Engineering. 8 uppl. Harlow:

Addison-Wesley; 2007.

[4] Houde S, Hill C. What Do Prototypes Prototype? I: Helander M,

Landauer T, Prabhu P, redaktörer. Handbook of Human-Computer

Interaction. 2 [rev] uppl. Amsterdam: Elsevier Science B.V; 1997.

[5] Göransson B, Gulliksen J. Användarcentrerad systemutveckling.

Stockholm: Centre for User Oriented IT Design, Kungliga

Tekniska högskolan; 2000.

[6] Olsson S, Denizhan F, Lantz A. Prototyping. Stockholm:

Centre for User Oriented IT Design, KTH; 2001.

[7] Rosson MB, Carroll J. Usability Engineering: Scenario-Based

Development of Human-Computer Interaction. San Francisco: Morgan

Kaufmann Publishers; 2002.

[8] Tozer J. Prototyping as a system development methodology:

opportunities and pitfalls. Information and Software Technology.

1987; 29(5): 265–269.

[9] Carey JM. Prototyping: alternative systems development methodology.

Information and Software Technology. 1990; 32(2): 119–126.

[10] Justinmind [läst 2012-06-20]

Tillgänglig: http://www.justinmind.com

http://www.navigateconsulting.se/

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga A: Tidrapportering i Oracle E-Business Suite R12

27

BILAGA A: TIDRAPPORTERING I ORACLE

E-BUSINESS SUITE R12

Figur 5.1 – Tidrapporteringsflödet i Oracle EBS R12. Se Figur 5.2 för information om vilka aktiviteter som ingår i ”Skapa tidrapport”.

Spara tidrapport

Granska tidrapport

Kontrollera status på

tidrapport

Logga in

Lämna in tidrapport

Välj befintlig tidrapport

Välj avvisad tidrapport

Korrigera tidrapport

Logga ut

Skapa

tidrapport

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga A: Tidrapportering i Oracle E-Business Suite R12

28

Figur 5.2 – Processflöde för att skapa tidrapport i Oracle EBS R12

Ange/sök och välj projekt

Ange/sök och välj

kostnadstyp

Ange timmar

Ange/sök och välj aktivitet

Välj tidperiod

Ange notering

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga B: Kravspecifikation

29

BILAGA B: KRAVSPECIFIKATION

ID Aktör Namn Beskrivning Prioritet

ID001 Konsult Månadsvis/veckovis

tidrapportering

Systemet skall kunna hantera

månadsvis samt veckovis

tidrapportering

Skall

ID002 Konsult Tidrapportering

via webb


tidrapportering via webben

Skall

ID003 Konsult Mobil

tidrapportering


tidrapportering via smarta telefoner

eller surfplattor

Bör

ID005 Konsult Projektnivå Systemet skall kunna hantera att

tid läggs på projektnivå

Skall

ID006 Konsult Befintliga projekt Systemet skall endast tillåta

tidrapportering på befintliga

projekt

Skall

ID007 Konsult Tidrapportering på

olika projekt

System skall kunna hantera att

tid läggs på olika projekt under

samma dag

Skall

ID009 Konsult Aktivitetsnivå Systemet skall kunna hantera att

lägga tid på aktivitetsnivå

Skall

ID010 Konsult Förutbestämda

aktiviteter

Tid skall endast kunna läggas på

förutbestämda kostnadsställen

Skall

ID011 Konsult Period som avser

projekt

Aktören skall endast kunna

tidrapportera på den period

som projektet avser

Skall

ID012 Konsult Noteringar i

tidrapport

Aktören skall kunna göra egna

noteringar i tidrapporten

Bör

ID013 Konsult Status Aktören skall kunna se status för

tidrapport

Skall

ID014 Konsult Sökfunktion Aktören skall kunna söka

efter projekt

Skall

Fortsättning på nästa sida.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga B: Kravspecifikation

30

ID Aktör Namn Beskrivning Prioritet

ID015 Admin

Konsult

Tidrapport

sökfunktion

Aktören skall kunna söka efter

aktuella och gamla tidrapporter

Skall

ID016 Konsult Aktivera tidrapport Aktören skall kunna aktivera

tidrapporten för godkännande

Skall

ID017 Konsult Aktiverad rapport Aktören skall ej kunna ändra tid i

en rapport som har aktiverats för

godkännande

Skall

ID020 Konsult Löneart Systemet skall kunna hantera att aktör

kan tidrapportera för olika lönearter

Skall

ID029 Admin

Konsult

Korrigera tidrapport Aktören skall kunna korrigera

tidrapport som blivit avvisad

Skall

ID039 Konsult Tillåt försenad

tidrapport

System skall kunna hantera att

tidrapporterskickas in försent

Skall

Tabell 5.1 – Kravspecifikation. Lista över de krav som har tagits med i prototypen. Kraven är ett urval från den fullständiga kravspecifikationen från förstudieprojektet FIMO.

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga C: Skärmbildsöversikt

31

BILAGA C: SKÄRMBILDSÖVERSIKT

Från varje skärmbild kan man ”logga ut” och hamnar då i skärmbild ”Login”. Notera att det inte går att komma från ”Recent

Timecards” till ”Submitted Recent Timecards” via gruppen ”Timecard” (gråa rutan).

Timecard 04 June

Timecard 11 June

Timecard 18 June

Timecard 25 June

Login

OTL meny

Recent Timecards

Review Create

Timecard

Templates Homepage

Confirmation

Failed Login

Timecard 02 July

Submitted Recent

Timecards

Prototypframställning för tidrapportering i Oracle E-Business Suite R12 Bilaga D: Skärmbilder

32

BILAGA D: SKÄRMBILDER

LOGIN

FAILED LOGIN

HOMEPAGE


33

OTL MENY

RECENT TIMECARDS

TEMPLATES


34

CREATE TIMECARD

Search Project

Search Task

Search Type

Period Template


33

REVIEW

CONFIRMATION


34

RECENT TIMECARDS SUBMITTED

TIMECARD 02 JULY


35

TIMECARD 04, 11, 18, 28 JUNE

prototypframställnig för tidrapportering i oracle e-business...

Documents