+ All Categories
Home > Documents > Employee Expense and Reimbursement System Stuart … · The aim of this project is to develop an...

Employee Expense and Reimbursement System Stuart … · The aim of this project is to develop an...

Date post: 23-Jul-2018
Category:
Upload: lamhanh
View: 215 times
Download: 0 times
Share this document with a friend
53
The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. Stuart Mackie Employee Expense and Reimbursement System Stuart Mackie Computing 2004
Transcript

The candidate confirms that the work submitted is their own and the appropriate credit has

been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be

considered as plagiarism.

Stuart Mackie

Employee Expense and

Reimbursement System

Stuart Mackie

Computing 2004

- i -

Summary Cooper Cameron (U.K.) Limited is located in Leeds and is a subsidiary of Cooper Cameron

Corporation, a U.S. Company. The Company utilises high technology business solutions including

SAP R/3 and a full range of Microsoft , manufacturing and engineering dedicated software.

The project addresses employee expense reports which are currently prepared and submitted for

processing on paper which is cumbersome and inefficient. The objective is to provide a web based

system to facilitate the submission of expense reports on a weekly basis which will form the basis of

making data available for departmental costs, financial related transactions and re-imbursement to

employees.

The system will be a satellite system to the existing SAP R/3 with bridging being executed by the

Company’s I.T. department.

This report documents the process encompassing the initial study, design, implementation and final

system evaluation.

- ii -

Acknowledgements I would like to give acknowledgement to the under noted for their time, advice and support given

throughout this project:

Leeds University – Computing Department

Stuart Roberts

Sarah Fores

Cooper Cameorn (U.K.) Limited

Jim McPhail (Director of Information Services)

Alex Woolley (Accounts Payable Manager)

I.T. Department Staff

H.R Department Staff

Accounts Payable Staff

- iii -

Contents

1. Introduction 1 1.1 The Company 1

1.2 The Project 1

1.3 Background Research 2

1.4 Project Schedule 2

2. Objectives 3

2.1 Main Objectives 3

2.2 Minimum Requirements 3

2.3 Additional Requirements 4

3. Analysis 5 3.1 Requirements Gathering 5

3.1.1 The Current System 5

3.1.2 Interviews 6

3.1.3 Existing Solutions 6

3.2 User Requirements 7

3.2.1 Essential User Requirements 7

3.2.2 Enhanced User Requirements 8

3.3 Chosen Methodology 8

3.4 Chosen Technology 8

4. Design 10

4.1 Database Design 10

4.1.1 Entity Relation Diagram 10

4.1.2 Database Entities and Attributes 12

4.1.3 Database Constraints 13

4.1.4 Database Normalisation 13

4.2 System User Types 15

4.3 User Interface Design 16

4.4 Coding Style 18

4.5 Existing System Integration 19

- iv -

4.6 Security 20

5. Implementation

5.1 Database Implementation 23

5.2 Interface Implementation 24

5.3 Backup 31

6. Testing 32

6.1 Methods of Testing 32

6.2 System Testing 32

7. Evaluation

7.1 System Requirements 34

7.2 Methodology 34

7.3 Implementation and Testing 35

8. Conclusion 36

8.1 Future Enhancements 36

8.2 System Testing 36

Biography 37

Appendixes Appendix A – Personal Reflection 38

Appendix B – Initial Project Schedule 39

Appendix C – Revised Project Schedule 40

Appendix D – Entity Relationship Diagram 41

Appendix E – Database Schema 42

Appendix F – ASP Code Extract 46

Appendix G – Sample Test Plan 47

Appendix H – Current Company Paper Expense Report 48

- 1 -

1. Introduction

1.1 The Company

Cooper Cameron Corporation, a U.S.A. company is a leading international manufacturer of oil and

gas pressure control equipment, including valves, wellheads, controls, chokes, blowout preventers

and assembled systems for the oil and gas drilling, production and transmission used in onshore,

offshore and sub-sea applications. Cooper Cameron Corporation also provides aftermarket parts and

service to the energy industry worldwide.

Cooper Cameron (U.K.) Limited has a major manufacturing operation in Leeds and an aftermarket

facility in Aberdeen with the legal entity being a fully owned subsidiary of Cooper Cameron

Corporation. The U.K. subsidiary has over 1000 employees based in the U.K. and their operations

support Customer projects on a worldwide basis.

1.2 The Project The aim of this project is to develop an Employee Expense and Reimbursement System for

Cooper Cameron (U.K.) Limited (Cameron.). The Company has in place a paper based system and

has conducted some basic research into new solutions. For a number of reasons they have not found

any satisfactory solutions and have been considering a custom solution at a later date that will

interface with the current SAP R/3 system they use.

The project will involve requirements analysis for, and development of an appropriate solution to

allow employees in the Company to submit expense reports electronically, instead of the current

process which is done on a paper template either through Excel or handwritten. The electronic

expense report system would take into account the procedures currently in operation by the Company

as well as produce a more modern technologically advanced system making the process more

efficient for all involved.

All employees of Cameron use the same paper system, and administrative employees are required at

various stages through the process to handle the paperwork and enter the data from the employee

expense report documents into an electronic format. Due to the nature and size of the Company, the

initial application for the system would encompass all locations under the U.K. Legal Entity. Future

rollout of the system may be used by the Company at all locations across the World who utilise the

SAP system.

- 2 -

1.3 Background Research For this project to be successful and fulfil the system requirements, background research took place

for strategic areas of the project. After initial consideration of the project problem, it was apparent

that the following areas require research before being able to proceed :

• Data Protection

• Human Computer Interaction (HCI)

• Database Design

• Software Testing

These areas were researched before continuing with the project. References to these research

materials can be found on the Bibliography as well as referenced throughout the project. Rather than

devote a chapter explaining my findings, where a reference has been used I have explained the

information contained within the reference before considering how it affects the project.

1.4 Project Schedule Due to the limited time available for this project, a schedule was produced early on in the

development. My original schedule as found on Appendix B was acceptable to work to until January

2004. Unfortunately due to additional pressures the schedule was not appropriate for work targeted

to be completed after January 2004 leading up to the submission date. Subsequently the Project

Schedule was re-structured to accommodate an appropriate time frame for this period. The updated

schedule can be found on Appendix C.

- 3 -

2. Objectives

2.1 Main Objectives The main objectives of this project is produce an appropriate Expense, Reimbursement and Reporting

system for Cooper Cameron to replace their existing paper based system. The Company has

investigated a number of existing solutions and has found them to be inadequate for their needs.

They have since decided to have a custom solution produced which reduces the amount of time spent

by the employee and by the company processing expense reports. The new system should provide a

smooth and intuitive progression from the old paper system layout and process to the new electronic

version with the added advantage of automating the accounting transactions from the electronic data.

The current expense reports are manually transacted in SAP and the intention is to develop a system

that the Cameron I.T .Department can interface with and process into the standard SAP application.

The achievement of accurate expense report recording will automatically achieve significant

efficiencies in the reimbursement process

2.2 Minimum Requirements For the system to fulfil the minimum expectations of users, the following minimum (‘must have’)

requirements must be achieved :

• Investigate appropriate methodology for use in the development of this project.

• Document user and system requirements through contact with the Company, and

examination and evaluation of their existing procedures.

• Investigate possible solutions and select the most appropriate.

• Implement full Back-End (databases) and initial Front-End (basic web interface) for

the appropriate solution.

• Carry out planned technical testing and resolve any issues.

- 4 -

2.3 Additional Requirements If time permits, or for future system development, the following items have been considered:

• Implement Final Front-End

• Deploy the system for use at Cooper Cameron (U.K) Facilities.

• Carry out User Testing and make any necessary adjustments.

• Produce Appropriate Documentation for using the system

• Roll-out the Expense System for World Wide use.

- 5 -

3. Analysis

3.1 Requirements Gathering The basis of any project is a good understanding of what the end product is targeted to achieve. In

the case of this project three areas are available to help define these requirements, The Current

System, Staff Interviews and Existing Solutions. These three areas have been explained in more

detail below. The information gained from each of these areas will then be compiled in a listing of

User Requirements which the system will have to fulfil to be successful.

3.1.1 Current System

The current paper based system was closely examined, and notes were taken while watching staff

members using the system. Various stages exist in the current system which were also examined,

since they have a significant affect on the final version of an electronic replacement system.

The major data elements in the current paper Expense Report document are listed below. A full copy

of the current paper Expense Report can be found on Appendix H.

For Re-Imbursement to Employees

Employee Name, Number, Location and Cost Centre

Expense Report Period – Week Ending dd/mm/yyyy

Expense Report Submission Date

Company Vehicle Registration & Mileage

Employee Account No. (Vendor No.)

Expense – Type

Expense – Date Incurred

Expense – Amount (Gross)

VAT Amount : Finance to Complete

Expense – Net of VAT : Finance to Complete

Expense – Account Code : Finance to Complete

Company Paid Expenses – Not For Reimbursement (information only)

Air Travel

Rail Travel

Car Hire

- 6 -

Other Details

Cash Advance Details

Currency Conversion Rates

Date & Location and Business Purpose

Signatory Details / Management Approvals

Special Notes – Exceptional Expense/Circumstances

3.1.2 Interviews

Meetings with a number of main members of staff involved with the system have been carried out. A

number of areas were discussed ranging from the existing paper based system and its performance, to

any areas which they felt the current system failed to accommodate. Notes were taken during the

meetings which were then reviewed to produce a listing of requirements.

3.1.3 Existing Solutions

There are a number of existing solutions available from small scale companies to more sophisticated

companies such as SAP. Cameron as well as being heavily Microsoft orientated also has strong links

with SAP, and is currently running SAP R/3 (recently converted from SAP R/2) through the entire

company. When Cameron started investigating existing solutions they primarily started with SAP

R/3. After receiving the information from SAP the company ruled out this option due to it poor

interface and spiralling costs which were in excess of £300,000 per office/plant with additional

annual fees for maintenance support. Cameron currently do not utilise the SAP R/3 H.R. module

which is a prime requirement to implement the SAP Expense Report module. Effectively the current

decision was to utilise a non SAP application with bridging interface to SAP R/3.

The problem found with most other available systems is either additional features which interfere

with the main requirement features needed by Cameron, or the system is too basic and does not fulfil

the Company’s requirements.

Unfortunately due to the costs and implementations of the existing solutions available, I have been

unable to get any hands on testing with available software to be able to discuss the positive/negative

attributes of the applications. Cameron advised me that they should be able to make available for

review the system profile of the SAP Expense and Reporting package. However, this was not

achieved due to the Companies decision not to purchase this module.

- 7 -

3.2 User Requirements After reviewing the above three areas, it has been possible to produce a listing of Requirements

which this project has to target. These requirements have been split into two sections, Essential and

Enhanced. The Essential Requirements are those which the system will have to fulfil to be

successful, otherwise the project will fall short of the User and Company expectations. The

Enhanced Requirements are those which may provide extended use for the User and the Company.

These Requirements are not mandatory and could be included in the system at a later date after the

completion of the Project, or built into the project during development if time permits.

3.2.1 Essential User Requirements

Taking into account the previous analysis data extract, the following essential requirements were

derived :

• A web interface should be designed to allow employees to have access to the system.

• The system should store expense report data for at least 14 months, before moving it to an

archive.

• Employees should be able to submit expenses to the system which will be compiled on a

weekly basis

• The system must handle foreign currencies.

• The system should complete all Tax, VAT and other mathematical calculations required for

the Company and the User.

• The system where possible should provide a list of selectable items to accommodate any

restrictions on Expense types (i.e. Disallowable expenses for un-receipted claims above

£5.00 per item, baby sitters, spouse travel unless approved in advance, inappropriate

Entertainment, travel upgrades unless approved in advance, expense paid on another

employees behalf and office equipment which should be purchased on approved company

Purchase Orders etc)

• Security should be accommodated to make sure the system applies with the Data Protection

Act (1998). Under the Data Protection Act the Company has an obligation to ensure

records are “company confidential”. Expense Reports may include legitimate approved

expenses that must not be divulged. Examples would include Medical, Education,

Qualifications and Personal Information

• Users should only be able to view their own expense reports

• Employees who will be administering the expense report system should have higher

privileges, and control over settings used by the system

- 8 -

3.2.2 Enhanced User Requirements

• Options to store user preferences should be provided. These options include

preferred currency, car registration, personalised Expense categories.

• Scanners should be integrated into the system to allow receipts to be electronically

stored.

3.3 Chosen Methodology There are a number of main methodologies which could be considered for use with this project.

These include the Waterfall Model, Spiral Model (as used as part of the Structure Systems Analysis

and Design Methodology) and UML. Due to the restricted nature of this project, both in size and

time, I do not feel it appropriate to adhere to a strict pre-defined Methodology but hope to take on

board areas of some methodologies which are more appropriate to this type of project.

Since this is a customised project specific to Cameron in an area which the company has not

developed for a number of years, it is likely that alterations will be required at various stages

throughout the lifecycle to the design and implementation. The Waterfall Model does not

accommodate this, and modified versions of the Waterfall Model which do support changes to the

specifications during development are still very restrictive due to the nature of the ‘Waterfall

Design’.

To accommodate the requirements of this project, as well as the ability to make changes during the

development process I will be using an Iterative approach. Iteration is one of the main features of the

Spiral Model and I plan on following the principals of this Model during this project.

UML is another methodology which I hope to use, although not in its full context. For this Project,

certain parts of UML will be beneficial, in particular in diagrammatical context in which UML can

be used to demonstrate the development of the system to the client, as well as provide a structured

view for areas of development.

3.4 Chosen Technology Cameron is a large International company which is heavily reliant on computer technology. They are

heavily dependent on Microsoft technologies and after speaking with their main support departments

this will have to be taken into account when choosing appropriate Technologies. This project will

primarily require a web server, appropriate server side language and a database server. The company

has informed me that their preference in these cases for all new software they use is Windows 2003

Server running Internet Information Services (IIS6.0) which will facilitate the use of Active Server

Pages (ASP) for the server side scripting language. They have a number of database servers which

again are running on Windows 2003 Server with SQL 2000.

- 9 -

Cameron is currently in the process of upgrading their systems World Wide. Subsequently the

specifications for the chosen technology and systems which this software will run on have taken this

into account. Although this project would run on Cameron’s current system base, planning for the

completion of their upgrades which should be complete shortly was deemed the best action.

- 10 -

4. Design This section of the report aims to investigate the design criteria required for the software before

moving on to implementation. The section is broken down into a number of main areas – database

design, interface design, security and coding style

4.1 Database Design Through my analysis of the problem it was apparent that there was going to be a large number of

database entries on a regular basis, and a significant amount of information has to be stored. The

database design has to be efficient and accurate for use in the system for the immediate future, but

also be as flexible as possible to allow future software development to be incorporated without

compromising the design.

4.1.1 Entity Relationship Diagram

The first phase of the database design was to identify the central entities and relationships involved

and represent them on an Entity Relationship Diagram (ERD). E-R Diagrams are beneficial because

they do not contain any technical information which means they can be shown to the Company. The

Company can then comment on its validity allowing for any areas which have been overlooked to be

revealed early in the process. In terms of implementation of the final solution, E-R Diagrams ensure

that all user requirements have been considered and included.

The diagram below is a high level abstraction of the entities in the problem, and does not contain any

attributes for these entities. Appendix D contains an E-R Diagram taken at a lower level which uses

the information shown in the diagram below, with the addition of the data in the next Section

(Database Entities and Attributes). With the addition of these two Sections, the lower level diagram

demonstrates the final database design required for use in this project.

- 11 -

Entity Relationship Diagram

[Figure 4.1.1.1 – High Level E-R Diagram]

Figure 4.1.1.1 shows the relationship between the basic entities required for the database. The values

‘1’ and ‘m’ represent ‘one’ and ‘many’ respectively, for use in describing the relationship between

two specific entities. For example ‘one’ user may have ‘many’ Expense Reports, and ‘one’ Expense

Report may have ‘many’ Expense Items.

The diagram was done at a high level so that no detailed entities were drawn, and the diagram could

be used to demonstrate the relationship between the various entities. The use of this low detailed

diagram was particularly beneficial to use with non-technical members of the company to check that

on principal to main entities of their expense report system were included and nothing obvious was

missing.

Expense Item

Cost Centre

Function Group

System Group

Expense Report

User 1 m

1

m

1 1

m 1

1

m

- 12 -

4.1.2 Database Entities and Attributes

Using the information gathered during investigation of the user requirements and the Entity

Relationship Diagram produced in Section 4.1.1, it is possible to compile a list of Entities and their

attributes required by the system to store real world data :

Entity Attributes

Expense Report Report ID, Claimaint ID, Description, Cash

Advance, Cash Advance Currency, Cash

Advance Currency Rate, Submission Date,

Approval Date, Payment Date, Status

Expense Item Item ID, Expense Report ID, Description,

Expense Date, Amount, Currency, Exchange

Rate, Receipt, Receipt Type, VAT Rate

User Accounts User ID, Username, Password, Email Address,

System Group, Employee ID, Cost Centre

Cost Centre Cost Centre ID, Name, Manager

Function Group Function Group ID, Name, Parent

The above five entities will form the central core of the final Expense and Reporting System

database. A final database scheme can be found on Appendix E. The final database scheme will

take into account the following sections which include Database Constraints and Database

Normalisation. Subsequently the final database scheme may have a different structure to the Entity

and Attribute list above, as well as include additional entities and attributes which are specific to the

system. The reason for this is that the above listing only covers the real world entries and attributes,

whereas the database will also have to accommodate the system side equivalents. Similarly it is

likely that database design changes will take place during Normalisation.

- 13 -

4.1.3 Database Constraints

When storing data in a database it is important that the type of data entered/stored is of the expected

type. Database Constraints suggested by Elmasri & Navathe (1999) are documented below :

Key Constraints

Attributes can be used to identify a record uniquely. There are different types of Key Constraints

which can be used, but if an attribute is made a Primary Key it means that the value of that particular

attribute can only appear once. The one value then represents the whole record uniquely from all

records.

Domain Constraints

Each attribute in a database must be of a particular data type such as an Integer or a String. Domain

Constraints allow a data types to be set for attributes. Only data which matches this data type is then

allowed to be entered for a particular attribute.

Entity and Referential Integrity

Referential Integrity guarantees that a foreign key matches with a primary key from another relation.

Entity Integrity ensures that a primary key is not null.

Functional Dependencies:

A Functional Dependency is where an attribute in one database is dependent on an attribute in

another database. A real world example of a functional dependency would be the name of a person

and their National Security number. In this case the persons name is functionally dependent on their

National Security number.

4.1.4 Database Normalisation

Database Normalisation is a vital part of database design. Normalisation is the process of comparing

a database scheme based on its functional dependencies and primary keys against a set of conditions.

As described by Elmasri & Nevathe (2000) and Roberts (2002) the following advantages can be

gained if database normalisation is carried out :

• The process of normalisation connects tables together for referential integrity. Without

referential integrity, it is possible to have data in one table which should pair/match with data

in another table but doesn’t. An example of this would be a car dealership ordering a car. A

- 14 -

customer should be paired with a car if they have ordered it, but if referential integrity is not

maintained it would be possible for the system to store a car order with no linking to the a

customer.

• In a database system, poor design can result in data redundancy. This is where data is stored

multiple times unnecessarily. Data redundancy can produce inconsistency and makes

maintaining a database very difficult. As part of Normalisation, data redundancy is removed,

and if done correctly causes any tables with redundancy to be removed. This is done through

the use of primary and foreign keys.

• Normalisation makes use of primary keys at its various levels. An advantage of using

primary keys is the indexing it then allows the DBMS to provide. Primary keys are attributes

which can only exist once in a table which makes each entry uniqie. Indexing can therefore

be done using these keys which results in greater performance for almost all database

activities such as updating or deleting entries.

Normal Form is a progressive set of conditions with First Normal Form (1NF) being the least strict

through to Fifth Normal Form (5NF) being the most strict. Fourth & Fifth Normal Form are rarely

used, and there is an additional Normal Form called Boycee-Codd Normal Form (BCNF) which is

the equivalent of 3NF with a minor change. Below are explanations of the criteria for each type of

Normal Form.

First Normal Form (1NF) For a database to be in First Normal Form all values in a table must be atomic and there must be no

multi-valued attributes.

Second Normal Form (2NF)

For a database to be in Second Normal Form it must be in 1NF and all non-key attributes must fully

depend on the key. To resolve any attributes which are not full dependent on the key, these attributes

are normally split from the table and moved to another.

Third Normal Form (3NF)

For a database to be in Third Normal Form, it must be in 2NF, and mustn’t contact any transitive

dependencies. An attribute is transitively dependent if it depends on another attribute which is

dependent on a key.

- 15 -

Boyce-Codd Normal Form

Boyce-Codd Normal form is very similar but slightly stricter than 3NF. A database is in BCNF if

every determinant is a candidate key. A determinant is an attribute which has another attribute fully

dependent on it.

In general a well designed database should comply with 3NF or BCNF and most database designs

aim to comply with 3NF or BCNF. This produces the best all round solution which avoids some of

the major pitfalls such as data redundancy and missing referential integrity.

I have completed a number of modules covering database topics and have developed great personal

interest in the subject area. I have found the more databases I develop the more natural I find

designing these databases to comply with 3NF and BCNF. There have been certain rare

circumstances where the design is better if it doesn’t completely comply, but this is rare.

4.2 System User Types The Expense and Reporting System will be used by a wide variety of employees at Cameron. The

majority of these employees will be using the system to create expense reports, but a number of

specialist users also have to be accommodated. These two initial additional user types are :

Functional Group Managers

Function Group managers will be the first level of Administration above a basic user. When a user

submits a completed expense report, it will first be queued for authorisation by their manager. If the

expense report is valid the manager can authorise it, which then queues it for final audit/processing

by the Accounts Department. Although a manager is required to Authorise a member of staff’s

expense report, they should not be allowed to make any changes. It is against Cameron’s Company

policy for a Manager to make any changes to an employees expense report. If there are anomalies,

the expense report will not be approved

Accounts Department Staff

Members of the Accounts Department staff carry out the final level of Authorisation of an expense

report before the employee is reimbursed for their expenses. The Accounts Department will work

through a similar process as a Manager in terms of authenticating the expense report, but with one

major difference. Members of Accounts Department are allowed to make changes to an employees

expense report should any simple errors be found. Serious errors/omissions will result in the expense

- 16 -

report being rejected. The employee on accessing the system will see that the expense report has not

been released for payment.

The requirement for User Types and subsequently different levels of user permissions has a

significant affect on the design and implementation of the system. The two main areas which will

have to accommodate this in their design will be Security which is covered in Section 4.6, and the

User Interface which is covered in Section 4.3.

4.3 User Interface Design The user interface for the system is paramount for it to be successful. The design of a graphical user

interface (GUI) has to be considered carefully since there a number of very important areas to

consider to achieve an efficient and user friendly GUI. As explained by Ruddell(2002) the most

important areas to consider for a user interface are :

•The GUI should have a consistent layout to allow users to quickly and easily become fluent

with the system.

• Appropriate user of colours is vital. Colours should be chosen that highlight important

areas, while making sure main bodies of text are readable.

• The system should automate tasks and data entry as much as possible, but avoid completing

sections differently to the users needs creating additional work.

• Display appropriate and clear error messages to allow users to quickly understand and fix

any mistakes.

• Page layout should be consistent and flowing.

Taking these important issues into account, the Expense & Reporting System interface will

incorporate the following :

• The interface will have a consistent design throughout for all user types. The interface will

include a two level menu system at the top, with the main content area underneath, and a

shortcut menu bar at the bottom.

• The colour scheme for the system will be based around the colour scheme that the

Company utilises. Matching colours will be used throughout the site for header and other

important areas. The main body section will be a white background with black text which

is the most comfortable solution for a user’s vision. The surrounding areas of content will

be ‘soothing’ to provide the user with a ‘comfortable’ interface to use.

- 17 -

• The menu system will look very similar for all user types, but additional menu items will be

visible for Administrative levels of staff compared to a basic user. The menu system will

be available on every page within the site and provide access to all parts of the system.

• The system will automate data entry such as expense items dates where possible.

Automated data entries will either be fixed or editable after they are inserted depending the

particular data variable.

• The Company has a very up to date computer system. Although this is the case, it is still

standard for web design to accommodate 800x600 resolution computers. Since many users

are using the next resolution up (1024x768), a design which fills the screen using 800x600

will have a small ~100 pixel border down both sides which will be incorporated into the

design.

• The system shall accommodate three main error notification types. On submitting data

into the system, any data entry errors will be displayed to the user via a popup error box.

Errors related to data entry where the system believes the user has made an error will

displayed as a Advisory error to the user, but shall not affect the progress of the user in the

system.

Any System errors shall be ‘caught’ and processed to allow for system maintenance and problem

resolving. The user will not see this message, but instead be provided with an appropriate message

indicating the position of the system. Fatal errors where the system is effectively offline should be

avoided at all costs, and where practical the system should still function at a lower capacity to avoid

user inconvenience.

- 18 -

4.4 Coding Style As with any software, continued development and future expansion is always present. Since this

project is to produce software for use by a third party, it is likely that future development will

required by the writer, or possibly developed further internally by the company. To make it possible

for the software to be easily developed at a later date, the structure of the coding has to have

consistent formatting. This makes it possible for any experienced programmer to understand the

methods used, and be able to quickly understand the code to continue development. Although this

project uses the programming language ASP, coding conventions apply to any language. As such I

found the explanations of Wrox – PHP Programming (2003) below most helpful:

• Variable names will be comprised of an initial letter or word which describes their type e.g.

s for string, i for integer. The initial letter will then be followed by a word which describes

the relevance or originating source of the variable e.g. a web form variable may be

“sForm….”. Finally an appropriate term will be used to distinguish variables e.g. the login

web form may contain the variables “sFormUsername” and “sFormPassword”

• Function naming will use mixed case naming through out to provide a consistent format.

The names for functions will be such that they will be obvious to the reader their intention,

and the context they can be used in. For example a function for carrying out user

authentication may be “function getUserId {….}”

• Although consistent function naming should provide a significant amount of information to

a developer, it may not be obvious the nature in which the function can be used and the

information required to use it. Subsequently it is important that functions and important

areas of code are appropriately commented. A popular method of commenting function is

based on the ‘JavaDoc’ commenting format which will be used in this Project. The format

of this type of commenting is demonstrated below :

/**

* @param string – time to be set

* @ return boolean

* @access private

*/

function setLoginTime( dtSysTime ) {

return true;

}

- 19 -

4.5 Existing System Integration Through my initial research and contact with Cameron there was a need to provide system

integration in two areas. The company is extensively reliant on Microsoft technologies for day to

day client and server usage. They are currently still running NT Servers in a Domain Environment

with Windows 2000 and XP Workstations. Their final testing period has just completed for a full

rollout of Windows 2003 Servers with full Domain integration and Windows XP workstations.

Subsequently to avoid creating a new login system with its own user database for the Expense &

Reporting system, it is much more efficient to integrate the new system with Microsoft Active

Directory.

The Company requested that they be able to complete the integration with their new network since

they would also be upgrading other custom software to achieve the same result. To achieve this

within the software I have produced login and authentication functions within the software which are

used as their names suggest. The Company can integrate the Expense & Reporting System with their

Active Directory rollout by modifying these functions to interact and question Active Directory.

Since the functions are well documented through the coding standards explained in 4.3, the Expense

and Reporting system will not be affected as long as the changes made to the function comply with

the documented design of the functions. In particular the system expects to pass the to function

certain pieces of data, and expects a particular reply.

The end result of this integration will be a better streamlined use of the software for the user.

Company employees will be able to access the system using their primary network logon credentials

removing the possibility of problems when users are required to use different credentials for each.

Although the company is reliant on Microsoft technology for the networking environment, they also

have a similar level of reliance on SAP R/3 for many of their central software systems. With

particular respect to the Expense & Reporting system, SAP R/3 is used for processing information

between bank accounts, company transactions and employee salaries. The previous paper system

required an administrative employee to transfer the Expense sheets into SAP R/3 manually. With the

Expense & Reporting System each employee will enter the data for their own expenses which will be

stored in a central SQL Server database. The Company again wants to be able to gain access to this

data to automate the payment process through SAP R/3. This particular need does not have a direct

impact on the Expense & Reporting software, but well designed and accurate databases are required

to support the payments as well. The Company has a number of SAP specialist staff who will write a

bridging script to retrieve the data they require from the Expense and Reporting system databases and

process accordingly into SAP R/3 for further use. This is slightly inefficient since there will be a

small quantity of data redundancy between SAP R/3 and the Expense and Reporting system, but SAP

R/3 only requires a small number of database values per expense report, compared to the vast amount

- 20 -

of data stored in the developed Expense Report system. Subsequently there is little concern over

doing this, and the SAP R/3 integration can be view as a higher level summary of the expense reports

stored within the new system.

4.6 Security In the last few years Security in the Computing Industry has become a business in its own right. A

number of companies and software developers have overlooked this area subsequently leading to

spurious vulnerabilities. As discussed by Efford (2004), one of the main reasons for these security

problems in software was a view taken my many companies that the functionality of the software

being first priority with security being added/patched on afterwards if required. Effectively security

was a secondary consideration within software, and was seen as a ‘bolt-on’ which was added to the

software. Unfortunately with these development attitudes and practices, software does not provide

adequate levels of security and consistency required in today’s high technology world.

Taking this into account, the only way to provide a system that is secure is to take account of these

security problems during design rather than during implementation. The section of the report borders

Design and Implementation due to the nature of Security. As such many implementation decisions

will be made at the same time as designing security into the system since it is not suitable to have one

without the other.

Cameron is a large organisation with offices across the world. The Company takes security very

serious, and requires this system to include adequate protection. Due to the nature of this system

there are a number of areas which are susceptible without consideration for effective security

protection:

• On completion of the Company’s upgrade as discussed in section 4.4, the system integration

will vet the users when they logon with their credentials to the Expense System, since the

system queries an AD Domain Controller. If the credentials are correct the user is allowed

access to the system. The Company requires this and will take steps when completing the

integration by securing the data transmission between the client and server. Since the

programming language used for this project is a Microsoft Language, the language provides

appropriate integration with other Microsoft technologies such as AD.

- 21 -

• The system is highly dependent on Microsoft SQL Server to store the system date. If an error

incurs when using the database such as invalid parameter being passed as part of a query, the

system by default displays a detailed errors message. These error messages can disclosure a

large amount of information about the server, but more importantly it would give an attacker

information about specific databases and their tables which can then be abused in particular

attacks. To secure against this vulnerability the system will detect error messages and provide

a custom error message which will inform the user of a problem without disclosing any

underlying data. A system administrator can then be informed of the problem and appropriate

action can be taken.

• A number of different user types will have access to the system, ranging from basic users

who will be submitting their Expense Reports, to administrative members of the Finance

Department who will authorise employee Expense Reports. Each user of the system will have

a user level. When a user logs into the system, the system interface will be customised to

allow access to areas granted to that particular user level, and additional areas only accessible

to higher privileged users will be hidden.

• Although the interface displayed for a user is customised to their permission level, there is the

possibility of a malicious user attempting to gain access to areas they are not authorised to

access. The system will accommodate this by authenticating the users rights for each

webpage in the system. When a user requests any page, the system will compare the user’s

privileges with the required level for the page. If the user does not have the required privilege

level the system will deny access to that page and inform the user appropriately.

• Data entry into systems is another area which can be exploited by malicious users. A number

of vulnerabilities have been made public recently which allow a user to enter data into a web

form which when submitted cause the server to carryout an action written by the user. To

protect against this type of problem all user entered data will first be verified by the system as

a correct data type for that question, i.e. an error will be presented to the user if they enter

words in the form where numbers should have been used.

User data will also be examined for malicious code to make sure the system is protected

against any future software flaws made public which apply to the database server.

• The System from a basic point of view has the user entering data through a web page which is

then stored in a database. When the user enters their data into the web forms, the data has to

- 22 -

be transmitted across a network to the server to be processed. The standard way of

transmitting this data uses the Hypertext Transfer Protocol (HTTP) which sends this data in

plain text across the network. If no precautions were taken, the data could be monitored by a

third party allowing abuse through information disclosure or data modification. To protect

against this the web interface will use Secure Sockets Layer (SSL) with Secure Hypertext

Transfer Protocol (HTTPS). The process requires no alteration to the coding of the software

because the transmitted data is encrypted separately on the client before transmission, and

decrypted on the server when received.

- 23 -

5. Implementation This section of the report show how the design decisions made in Section 4 were used in the final

implementations.

5.1 Database Implementation In section 4.1 the design of the database was completed using the User Requirements and Entity-

Relationship Diagrams which was then processed using Database Normalisation. The database

design described was then built in SQL Server to store the data for the system. Once the design was

created in the SQL Server there was no other work required specific to the database implementation.

Once the database was complete, work was then required to produce appropriate SQL Queries to be

used by the interface. When a user views a page in the system, it is likely that the page will contain

dynamic content which will be retrieved from the database. To retrieve this data the website uses the

ASP scripting language which connects to the server, executes the query and returns a result or data.

An example query written for use in the system is a basic query which authenticates users when they

first login to the system :

SELECT u.screenname, u.pass, g.permission

FROM dbo.user_accounts u JOIN dbo.system_group g ON u. user_system_group=g.id

WHERE u.screenname= “[frmUsername]” AND u.pass= “[frmPassword]”

The above query will then return the result of the query which can be used by the system. Since the

each user’s username should be individual, if the user has entered a valid username, the query should

only return 1 result.

- 24 -

5.2 Interface Implementation The interface for the Expense and Reporting System has been broken down into a number of areas to

allow more detailed examination of the chosen design.

Main Design

[Figure 5.2.1 – Main Interface Design]

The screenshot above shows a general view of all the areas which will be covered in later sections.

The design and colour scheme for the website is consistent throughout, and as seen on the screenshot

the design accommodates all the design criteria specified in Section 4.3.

- 25 -

Menu System

[Figure 5.2.2 – General User Menu System]

[Figure 5.2.2 – Managerial & Account User Menu System]

The General User Menu System (Figure 5.2.2) forms the basis for all user types that have access to

the system. The menu is straight forward and intuitive for the user to use. The user firsts selects the

topic area that they would like to access. A second menu is then displayed with selectable options

dependent on their initial main menu choice. The user can then select which particular task they

would like to carry out and is taken to the relevant area of the system.

The second menu screenshot (Figure 5.2.2) shows a very similar menu to that used by a General User

which is for use by Function Manager or Accounts Department staff. The difference between the

menu system is the additional options which allow these higher privilege staff to review general user

expense reports for authorisation.

The custom menu system which is specific to each user type is vital for two reasons. Firstly, for ease

of use it is important that users only have to choose from the menu options which they should have

access to. The visibility of options not available to that user would cause confusion and waste a users

time. Secondly from a security point of view, if users were shown a menu system with options not

applicable to their user type, some users may be tempted to try and gain access to these areas of the

system. Although security has been designed into the system which would block their access, there

is nothing to gain by encouraging this type of behaviour. The visibility of these additional menu

items would also disclose information about the system unnecessarily again creating security

implications.

- 26 -

Content Area (Including Use of Text Formatting)

[Figure 5.2.3 – Main Content Area & Text Formatting]

Figure 5.2.3 demonstrates the use of appropriate colours and space for the main content area. As per

the design specifications the main content area uses primarily black text on a white background but

this does not have to mean the site design has to be white all over. The design incorporates a blended

surround down either side of the content area and any other areas of the interface where the

background can be seen. The reason for choosing this type of design was to make the interface more

comfortable on the eyes for the user while still using the well tested black text with white background

for the main content which is known to be the best combination to make reading easier on the eyes.

Figure 5.2.3 also contains an example of each font style used within the site. The implementation of

the text within the site mainly uses the HTML commands <H1> through <H6> and <P> (normal

paragraphed text) which is a specific set of HTML components for text. The advantage of using

approach is two fold. It is very easy when adding new pages to the system to use appropriate heading

styles for areas of text if you know in advance what styles are available to you. Also, the use of these

HTML commands integrates well with ‘Accessibility Features’ provided in most Operating Systems

- 27 -

and Browsers. These Accessibility Features allow user to over-ride these settings to accommodate

particular disabilities. For example although appropriate sizes and colours have been chosen for the

text used on the interface, a disabled employee with an eye sight condition (e.g. colour blind) could

adjust their Operating System Accessibility Options to over-ride the <H1>-<H6>. This would then

allow the rendered interface to make use of the user defined settings to accommodate the user’s needs

User Summary Data

[Figure 5.2.5 – User Summary Screen]

It is likely that users will log in regularly after submitting an expense report to get an update on its

status. Since this is a task likely to be carried out often, an expense report summary was integrated

into the main entry page of the system. This means that every time a user logs into the system they

will have instant access to the status of their expenses.

- 28 -

Expense Report Creation

[Figure 5.2.6 – Expense Report Creation]

When a user creates an expense report they will use the interface as pictured in Figure 5.2.6. The

creation of an expense report requires the user to enter general information which is applicable to all

the expense items added to the report. Some sections of the report are automatically filled in for the

user which the system does not allow them to edit such as their Cost Centre number. There are a

number of different types of form entry boxes which the user is requested to complete. To reduce

user error and decrease the time to enter the data,, where possible the user is given a drop down list

which is populated in advance. Form features such as drop down lists also assist in restricting the

type of data the user enters.

Once they have completed the form, the user selects ‘Create’ at the bottom to create the report in the

system. Once the report is created in the system, the user is questioned whether they would like to

add expense items to the report. If they select yes they are taken to the Expense Item Creation

screen, otherwise they are taken to their expense report summary page which will now contain the

new empty expense report which can have expense items added later.

Additional control buttons are also given at the bottom of the report to allow the user to reset the

form if they want to start again, or cancel the form if they no longer want to enter a report into the

system.

- 29 -

Expense Item Creation

[Figure 5.2.7 – Expense Item Creation]

Expense item creation is very similar to expense report creation previously explained. The item

creation form again makes use of the different data entry types to restrict the user’s entries. The form

also where possible calculates appropriate data values such as the amount of VAT on an expense

item. When the user enters the Receipt Total and the VAT Rate, the system will automatically

calculate the amount of VAT. Since the system has calculated the VAT amount, there is no need for

the user to be able to manually alter this since it was based on their previous data entry, the system

does not allow the user to manually enter the figure.

Expense items can be categorised into a number of areas. The system makes available a pre-defined

list of Item Expense Types for the user to choose from for each expense incurred. One main

advantage of providing the list for the user is to avoid the different descriptions each user may give to

the same expense. It also allows the system to restrict what types of Expense the employee can claim

for, although the system does allow the user to over-ride the provided list because there are situations

where a claim is valid but doesn’t naturally fall into a pre-defined category.

- 30 -

Managerial & Account Staff Administration Pages

[Figure 5.2.8 – Administration Pages]

The Managerial and Accounts Staff system interface is very similar to that of the general user. The

main differences as seen on the Summary screenshot in Figure 5.2.8 is that the

Managerial/Accounting Users are able to see submitted expense reports made by general users. As

well as being able to see general user expense reports, the Managerial staff of a function centre have

additional options buttons visible in the expense report to allow them to ‘Authorise’ or ‘Reject’ the

expense report.

Accounts staff an identical set of additional options, but they also have the ability to modify the

expense reports if they find an error.

- 31 -

User Preference Page

The system supports an initial small number of user preferences which are used to improve the use of

the system for the user. As seen on Figure 5.2.9, the user can store their preferences such as Default

Expense Type. With company expenses, in a number of circumstances, many users submit expenses

for regularly occurring events. When an expense item is added to an expense report the user has to

select the ‘type’ of expense item which best describes it.

5.3 Backup As with any system it is vital for appropriate backups to be taken. The Expense and Reporting

System will be hosted on a web server and database server within Cameron. Cameron already have

other systems which have similar requirements and as such have a documented and planned backup

policy. The data in the database is the most important part of the Expense and Reporting System in

terms of backup requirements since this is where all vital data is stored. The web interface which is

hosted on a web site is less important in terms of regular backup because it will rarely have any

changes made to it compared to the database which will have new data being added all the time.

- 32 -

6. Testing Testing for any software is vital to its success, and it is no different for the Expense and Reporting

System.

6.1 Methods of Testing There are a number of methods of testing which could be considered. From experience I have gained

from Jesty (2002) the three main methods I considering using were :

White Box Testing

This testing method carries out test at the code level for errors. White Box testing tests that functions

and pieces of code carry out their original design correctly. White box testing can be carried out

during the development.

Black Box Testing

This testing method carries out test which examine the input and outputs of the software. Black box

testing primary focuses on extreme and normal values of data entering and leaving the system. This

means that software normally has to be at an advanced stage before Black Box testing can be applied.

Acceptance Testing

Acceptance Testing is a form of Black Box testing which makes use of user interaction of the system

to find problems. Acceptance testing is normally carried out by the software writer giving a scenario

to a final user of the system and asking them to carry out the tasks just like they will do when the

software is complete. The user is then asked to make comments as they work through the scenario,

and point out any errors they come across. Is it normal practice for a system developer to monitor the

test because there may be errors found which the system user does not see or understand.

6.2 System Testing At the start of this project I knew that detailed testing would be required to be sure that the software

had no bugs. Because of this, I chose to use a combination of black box and white box testing during

development and acceptance testing at strategic areas of development.

During the initial implementation phases of the project it was possible to carry out White Box testing

on the ASP functions and code to validate that the carried out their purpose correctly. This testing

was less formal than the other two methods used because each function required a different

combination of data, and execution of pieces of code resulted in multiple areas being affected.

- 33 -

Black Box testing took place when sections of interface, its ‘back-end’ code and validation code were

complete. This testing was more formal than the White Box testing and comprised of using extreme

and expected values for data inputs and outputs. It was then possible to examine the results and

comparing the actual result with what was expected to find any errors. An example test plan can be

found below, and a copy of an actual test plan found on Appendix G.

Test Section:

Form Field Test Data Expected Result Actual Result

[Figure 6.2.1 – Example Black Box Test Plan]

Acceptance testing also contributed significantly to the full testing of the software. Acceptance

testing started at a later stage to the Black Box and White box testing because it was dependent on

user interaction with the system. Acceptance testing was particularly beneficial for testing data

related to the user interface, although there were a few issues raised by some of the staff regarding

missing data entries on certain forms.

Since Acceptance testing was carried out later in development, there was a risk that any significant

system design problems being raised by users at such a late stage in development would be

impossible to fix. To avoid this happening, new sections of the interface were made available to

users when they were completed to have the acceptance testing carried out just in case a major error

was found. The one restriction I found with acceptance testing was trying to get the company to

make time to carry it out. The Company and staff have their normal work to get done during the day

and the acceptance testing, although kept as short as was possible, still consumed some of their

valuable time. Taking this into account, the main testing was therefore definitely placed on Black

and White box testing.

The testing carried out was extremely important in the lifecycle of the project and helped root out a

number of faults which were then rectified.

- 34 -

7. Evaluation

7.1 System Requirements At the start of this project there were five minimum requirements and five additional requirements as

documented in Section 2.2 & 2.3. On completion of the project the solution produced fulfilled all

five minimum requirements and three out of five of the additional requirements, these being the

following :

• Implement Final Front-End

• Carry out User Testing and make any necessary adjustments.

• Produce Appropriate Documentation for using the system

The two additional requirements which could not be accommodated were “Deploy the system for use

at Cooper Cameron (U.K) Facilities” and “Roll-out the Expense System for World Wide use.”

Unfortunately Cooper Cameron is in the process of a major World Wide network and systems

upgrade to rollout Windows 2003 Servers in a Domain Environment with Windows XP Professional

workstations. At the same time the SAP R/3 Human Resources module is also being rolled out.

Taking this all into account the company could not accommodate the addition of the software to their

schedule and will review the situation in the coming months.

7.2 Methodology For this project is chose to take an Iterative Approach to the development rather than follow a pre-

planned Methodology. On looking back I am glad I decided to make this decision. During the

development of the software there have been a number of occasions where I have had to go back one

or two stages of the development process to make a change to the design because of information

provided late by the company, or by over-sight during those initial stages. If I had chosen a more

formal methodology, going back that far in the development process may not have been possible.

In saying this, during the project development modules taken at University I was made aware of this

type of situation occurring. To try and prepare in advance in case the need did arise, I specifically

tried to design the software in a module fashion which would allow the change to some modules

without having a major knock on effect. If the software had not been designed in this manner I

believe I may have had significant problems in meeting my scheduled dates because of delays.

- 35 -

The Iterative Methodology was subsequently a good approach to take with this project because it

allowed me to move back in the project development at any point, which is not possible for many

other methodologies.

7.3 Implementation and Testing The implementation of the system was the most enjoyable part. I was glad to have spent as much

time concentrating on the design to reduce any problems incurred during implementation. During the

implementation one factor which was always in my mind (which was covered during my design

considerations) was to allow for system expansion, without affecting the already implemented

system. To achieve this I found that treating each entry point in the system as its own entity was the

best way to get this effect. The method allowed me to produce a modular type system so that

additional modules could be plugged in which would work straight away, without requiring a

significant amount of work to be done on the system already developed.

The testing of the software took longer than expected to complete. I tried where possible to carry out

testing during development once a function, or full sections of the system was completed. This was

beneficial because it allowed me to catch obvious coding errors early during implementation, rather

than produce large numbers of errors at the end. I suspect my chosen methods of testing may have

been too pedantic for the type of system I developed, and if I were to develop another project again, I

may spend additional time investigating other possible methods, or adjust the proportions of the

methods I used in this case.

In saying this, the tests did find areas of the system where data was not validated correctly, or the

automation of an entry field did not take place. Without carrying out this testing the system would

have been made available with a number of bugs which would not have been acceptable and as such

the testing which took place was a success.

- 36 -

8. Conclusion The expense report project was a good choice and brought complexities in areas that go beyond the

technical attributes of the system. I had direct involvement in discussing the H.R. concern that the

processing of expenses is a key issues for employees in terms of their personal cash flow, but at the

same time conforming to Management demand of adherence to Company Policy on spending and the

need to limit spending to budgeted levels of cost. In addition financial Managements had to handle

the adherence to financial rules related to external parties, Banks, VAT Claims and reporting,

electronic payment systems (BACS) and approval in accordance with a defined structure of

hierarchy.

The data base and web development was extremely satisfying and the output results I feel meet the

demands of a quality company as Cooper Cameron is.

The current downside is the position where the Company has moved focus (temporarily) to review

the SAP H/R system. The intention is still not to utilise the SAP R/3 Expense Reporting module

since the H/R implementation will demand significant resource. At the appropriate point in time the

dedicated system as written will be reviewed and implemented in accordance with the requirement at

the time.

8.1 Future Enhancement

The developed system may be enhanced to support the following :

• Company Car mileage records and employee incurred vehicle costs.

• Reporting and analysis module to maximise the use of the database that could be extended to

record additional information such as Hotels utilised and analysis of cost on durations for

specific trips.

• An additional interface could be added to support mobile users with access to any mobile

enabled devices such as Smart Phones, Blackberry’s or Palms etc.

• Handling and communicating of expense receipts which proved to me a major issue due to

the external implication of VAT and internal checking/audit processes.

• Interface with Corporate Credit Cards to minimise cash advances and enable employees to

have minimum use of personal cash.

- 37 -

Bibliography

Baartse, Conway, David, Li, McFarlane Palmer, Stephens, Virdell, Williams, Wilton, Wooton, Yates

(2001), Professional Javascript 2nd Edition, Wrox

Dix A, Finlay J, Aboud G and Beale R (1998), Human Computer Interaction 2nd Edition, Prentice

Hall

Efford N. (2004), Secure Computing – SY32, University of Leeds

Elmasri & Navathe (2000), Fundamentals of Database Systems – 3rd Edition, Addison Wesley,

Chapter 14.3

Howard and LeBlanc (2003), Writing Secure Code 2nd Edition, Microsoft Press

Jesty. P (2002), SO22: Software Project Management, University of Leeds.

Lea, Buzzard, Cinis, Thomas (2002), PHP mySQL Website Programming, Wrox, Chapter 2.

Paul Wilton (2000), Beginning Javascript, Wrox

Roberts S. (2001), DB11: Introduction to Databases, University of Leeds.

Ruddell R, P Brna (2001), SI23 Introduction to Human Computer Interaction, University of

Leeds

Shneiderman, B (1998), Designing the User Interface, Addison Wesley

W3Schools (2004), ADO and ASP Reference Guide, URL:

www.w3schools.com

- 38 -

Appendix A: Personal Reflection

I found it constructive to take time and look back at the project and consider my experience.

The selection of the expense report system gave me an opportunity to evaluate what I already thought

was a fairly complex system, and at the same time recognising the importance and complexity in

developing the system within a company with major systems already in place.

In fact as I developed the design and system parameters I discovered that the requirement was even

broader than I initially thought, and this gave me the opportunity to develop my knowledge on

databases, web design and the discipline of project management.

I did incur some major drawbacks in the form of restrictions. The company decided not to pursue the

SAP R/3 Expense Reporting module since at the beginning they did not proceed with the H.R.

module which was linked to the expense report segment. This meant I did not get access to the SAP

R/3 expense report system. I also found that the expense receipts were problematical since they are

required to be reviewed by the company finance department (VAT Reporting etc). This required me

to “tag” the receipts by a unique number to link the receipts to the electronic expense report.

Involvement in the project encouraged me to focus on the following :

• Experience in discussing the project with management and selective employees of the

Company.

• Broader understanding of the day to day issues that impact a project of this complexity and

solutions found by discussion with involved parties.

• Benefit of exchanging ideas in both design and system concept taking into account the

technical attributes of the various systems I intended to use.

• Evaluation of business related attributes of expense reports from an Accounting, Management

and employees standpoint.

• The need to be prepared to change direction in system development to take into account

obstacles and problems encountered in the system development process.

• Adjust timetables to make up for lost time due to various development changes in design,

misunderstanding on key issues by either the Company or myself.

•Security attributes were high on my list and this was clearly a major item for a large company.

- 39 -

Appendix B: Initial Project Schedule

- 40 -

Appendix C: Revised Project Schedule

- 41 -

Appendix D: Entity Relationship Diagram

user_accounts

PK,FK3 user_id

user_screennameuser_passuser_emailuser_remind

FK1 user_system_groupemployee_id

FK2 cost_centre_idlast_login_iplast_login_hostlast_login_datestatusdeletedcreated_datemodified_datedeleted_date

system_group

PK id

display_namepermission

expense_report

PK id

FK1 user_iddescriptioncash_advance

FK2 cash_advance_currency_idcash_advance_currency_ratedate_submissiondate_approveddate_audited

FK3 status_idexpense_item

PK id

FK1 expense_report _iddescriptiondateamountcurrency_idexchange_ratereceiptvat_receiptvat_rate

function_group

PK id

display_nameparent _group_id

cost_centre

PK id

display_nameFK1 function_group_id

currencies

PK id

descriptionsymbol

expense_status_type

PK id

description

function_group _manager

PK,FK1 id

function_group_idmanager_id

expense_report _authorisation

PK id

FK1 expense_report _iduser_iddate

expense_report _auditing

PK id

FK1 expense_report _iduser_iddate expense_status_log

PK id

FK1 expense_report _idapprover _idnotes

- 42 -

Appendix E: Database Schema

A red attribute indicates a Primary Key.

• user_accounts

Columns Data Type Allow NULLS Default Value Other

user_id int(4) No Auto Increment

user_screename varchar(100) No

user_pass varchar(40) No

user_email varchar(150) No

user_remind varchar(100) No

user_system_group int(2) No

employee_id int(10) No

cost_centre_id int(4) No

last_login_ip varchar(15) No 0

last_login_host varchar(100) No

last_login_date timestamp No

status binary(1) No 1

deleted binary(1) No 0

created_date timestamp No

modified_date timestamp Yes

deleted_date timestamp Yes

• system_group Columns Data Type Allow NULLS Default Value Other

id smallint(2) No Auto Increment

display_name varchar(100) No

permission varchar(20) No

• cost_centre Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

display_name varchar(100) No

function_group_id smallint(2) No

- 43 -

• function_group Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

display_name varchar(100) No

parent_group_id int(4) No

• function_group_manager Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

function_group_id int(4) No

manager_id int(4) No

• expense_report

Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

user_id int(4) No

description varchar(500) No

cash_advance binary No

cash_advance_currency_id smallint(2) No

cash_advance_currency_rate double No

date_submission timestamp No

date_approved timestamp No

status_id int(2) No

- 44 -

• expense_item

Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

expense_report_id int(4) No

description varchar(500) No

date timestamp No

amount double No

currency_id int(3) No

exchange_rate float No

receipt int(1) No

vat_receipt int(1) No

vat_rate double No

• expense_status_type

Columns Data Type Allow NULLS Default Value Other

id int(2) No Auto Increment

description varchar(100) No

• expense_status_log Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment

expense_report_id int(4) No

approver_id int(4) No

notes blob No

• expense_report_authorisation

Columns Data Type Allow NULLS Default Value Other

id int(2) No Auto Increment

expense_report_id int(4) No

user_id int(4) No

notes blob No

- 45 -

• expense_report_auditing Columns Data Type Allow NULLS Default Value Other

id int(2) No Auto Increment

expense_report_id int(4) No

user_id int(4) No

notes blob No

• currencies

Columns Data Type Allow NULLS Default Value Other

id int(2) No Auto Increment

description varchar(100) No

symbol varchar(20) No

- 46 -

Appendix F: ASP Code Extract – System Logon <%

if (Request.Form("act") == "auth") {

%>

<!--#include virtual="/projectConnections/database.asp" -->

<!--#include virtual="/projectIncludes/objConn.asp" -->

<%

var objConn = Server.CreateObject("ADODB.Connection");

objConn.Open(database_conn_string);

var txtUsername=Request.Form("frmUsername");

var txtPassword=Request.Form("frmPassword");

//Compare to the User Database

var query_Auth = Server.CreateObject("ADODB.Recordset");

query_Auth.ActiveConnection = objConn;

query_Auth.Source = "SELECT SELECT u.screenname, u.pass, g.permission";

query_Auth.Source+= " FROM dbo.user_accounts u JOIN dbo.system_group g ON u.user_system_group=g.id";

query_Auth.Source+= " WHERE u.screenname= "‘+frmUsername+’ "AND u.pass= " ‘+frmPassword+”' AND

u.status = 1";

query_Auth.Open();

// User Authenticated

if (!query_Auth.EOF) {

Session("username")=authenticate.Fields.Item("screename").Value;

Session("userPermission")=authenticate.Fields.Item("permission").Value;

Session("userID")=authenticate.Fields.Item("user_id").Value;

}

// Authentication Failed

else {

var error = "authentication";

}

// Close Database Connection

authenticate.Close();

objConn.Close();

}

%>

- 47 -

Appendix G: Sample Test Plan

Test Section: Create Expense Report Screen

Form Field Test Data Expected Result Actual Result

Item Amount -0.01 Error Message Error Message

Item Amount 99999.99 Accepted Accepted

Exchange Rate -.0.01 Error Message Accepted

Exchange Rate 99999.99 Accepted Accepted

VAT Amount -.0.01 Error Message Error Message

VAT Amount 99999.99 Accepted Accepted

Description Not Filled Error Message Error Message

Date of Expense Not Filled Error Message Error Message

Item Amount Not Filled Error Message Error Message

Item Category Not Filled Error Message Error Message

Exchange Rate Not Filled Error Message Error Message

Currency Not Filled Error Message Error Message

Receipt Not Filled Error Message Error Message

VAT Receipt Not Filled Error Message Accepted

Add Item Button Click Proceed Proceed

Reset Form Button Click Reset Form Reset Form

Cancel Form Button Click Return to Expense

Report

Return to Expense

Report

- 48 -

Appendix H: Current Company Paper Expense Report


Recommended