Employee Expense and Reimbursement System. Stuart Mackie. Computing 2004

Transcription

1 Employee Expense and Reimbursement System Stuart Mackie Computing 2004 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

2 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. - i -

3 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 - ii -

4 Contents 1. Introduction The Company The Project Background Research Project Schedule 2 2. Objectives Main Objectives Minimum Requirements Additional Requirements 4 3. Analysis Requirements Gathering The Current System Interviews Existing Solutions User Requirements Essential User Requirements Enhanced User Requirements Chosen Methodology Chosen Technology 8 4. Design Database Design Entity Relation Diagram Database Entities and Attributes Database Constraints Database Normalisation System User Types User Interface Design Coding Style Existing System Integration 19 - iii -

5 4.6 Security Implementation 5.1 Database Implementation Interface Implementation Backup Testing Methods of Testing System Testing Evaluation 7.1 System Requirements Methodology Implementation and Testing Conclusion Future Enhancements 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 - iv -

6 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

7 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 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

8 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

9 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

10 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 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 - 5 -

11 Other Details Cash Advance Details Currency Conversion Rates Date & Location and Business Purpose Signatory Details / Management Approvals Special Notes Exceptional Expense/Circumstances 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 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

12 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 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 - 7 -

13 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

14 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

15 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 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

16 Entity Relationship Diagram Function Group 1 m Cost Centre 1 m User 1 1 System Group 1 Expense Item m 1 m Expense Report [Figure High Level E-R Diagram] Figure 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

17 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 Expense Report Expense Item User Accounts Cost Centre Function Group Attributes Report ID, Claimaint ID, Description, Cash Advance, Cash Advance Currency, Cash Advance Currency Rate, Submission Date, Approval Date, Payment Date, Status Item ID, Expense Report ID, Description, Expense Date, Amount, Currency, Exchange Rate, Receipt, Receipt Type, VAT Rate User ID, Username, Password, Address, System Group, Employee ID, Cost Centre Cost Centre ID, Name, Manager 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

18 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 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

19 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

20 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

21 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 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

22 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

23 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 : /** string time to be set return boolean private */ function setlogintime( dtsystime ) { return true; }

24 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

25 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

26 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

27 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

28 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

29 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 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

30 Menu System [Figure General User Menu System] [Figure 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

31 Content Area (Including Use of Text Formatting) [Figure Main Content Area & Text Formatting] Figure 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 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

32 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 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

33 Expense Report Creation [Figure Expense Report Creation] When a user creates an expense report they will use the interface as pictured in Figure 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