A Web Based Overtime Logging System for Reuters … Web Based Overtime Logging System for Reuters Jonathan Price BSc Information Systems - Management Studies Session 2002/2003

A Web Based Overtime Logging System for Reuters

Jonathan Price BSc Information Systems - Management

Studies Session 2002/2003

Jonathan Price Reuters - Overtime Logging System

Summary

Objectives of the project

The objective of this system is to build an overtime logging system for use by Reuters Client Site Services

(CSS) UK. Their current process is outdated and complicated and does not give Managers a holistic view

of overtime activities. The can also sometimes be a backlog in paperwork with overtime not getting

processed in time. This project intends to design and implement a system that resolve the current

problems with process and meet the requirements of a new system.

What the project achieved

The system that has been developed has been installed onto one of the new Reuters corporate Intranet

servers. The system gives the three types of user new and more efficient ways to process overtime. The

fact that the system is on the Intranet means the Engineers can log overtime via dial up facilities on their

laptops at any time. The Managers can now have a simple way of extracting up to date overtime logged

into the system. The minimum requirement of developing a system was surpassed as the final product is a

highly usable and functional product. The final system also has potential to grow with changing

requirements of the company.

Page I


Acknowledgements

Firstly I would like to thank Martyn Clarke for his continued support throughout the development of this

project.

A special mention to Reuters Client Site Services, Reuters Webfarm Team and The CSS Web Team who

gave me the equipment to build the system for them and were so accommodating in letting me interview

members of their busy team.

I would like to also thank my parents for letting me annoy them with extracts of this project for their

opinion, their support has helped me to finish this project well within time.

I would also like to thank Helen and Jaime

Page II


SUMMARY…………………………………………………………........... I OBJECTIVES OF THE PROBLEM………………………………………………. I WHAT THE PROJECT ACHIEVED……………………………………………... I AKNOWLEDGEMENTS ………………………………………………… II INTRODUCTION…………………………………………………………... 1

Background…………………………………………………………………….... 1 The project…………………………………………………………………….… 1 Aims of the project……………………………………………………………… 2 Objectives……………………………………………………………………….. 2 Minimum requirements…………………………………………………….….... 2 Exceeding the minimum requirements………………………………………….. 2

RELEVANT RESEARCH………………………………………………………... 2 General Principles for System Development…………………………………... 2 Candidate Methodologies………………………………………………………. 3

SSADM……………………………………………………………………... 3

STRADIS…………………………………………………………………… 4

YSM………………………………………………………………………… 4

OOAD……………………………………………………………………… 4

ETHICS…………………………………………………………………….. 4

SSM……………………………………………………………………….... 5

RAD and Dynamic Systems Development Methodology (DSDM)…………. 5 Defining a project………………………………………………………………. 6

Defining this project……………………………………………………….. 6 Applying an appropriate methodology…………………………………….. 6

Usability………………………………………………………………………... 8 DEVELOPMENT CODE………………………………………………………... 9

Cold Fusion…………………………………………………………………….. 9 PLANNING……………………………………………………………………… 10

Project Plan…………………………………………………………………….. 10

FEASIBILITY…………………………………………………………........ 12

CURRENT SYSTEM…………………………………………………………….. 12 Data Input………………………………………………………………………. 12 Data Manipulation……………………………………………………………… 12 Advantages of the current system………………………………………………. 12 Disadvantages of the current system……………………………………………. 13

HARDWARE CONATRAINTS……..…………………………………………… 13 SOFTWARE CONTRAINTS…..…………………………………………………. 13

REQUIREMENTS ANALYSIS……………………………………………. 15

STATED REQUIREMENTS OF THE SYSTEM………………………………… 15

Page III


Functional requirements………………………………………………………… 15 Usable requirements……………………………………………………………... 15 Perceived methods of exceeding these requirements……………………………. 15

APPLYING THE MoSCoW RULES……………………………………………… 15 DESIGN……………………………………………………………………… 17

DATABASE DESIGN……………………………………………………………. 17 Proposed ER Diagram…………………………………………………………... 17 Normalisation…………………………………………………………………… 17 Application of normalisation to attributes ……………………………………… 18 Relationships……………………………………………………………………. 20 Additional Tables needed for the system……………………………………… 20

OVERALL VIEW OF WEB SYSTEM DESIGN……………………………….. 20 Logging Overtime……………………………………………………………… 21 Dealing with Engineers & Managers ………………………………………….. 21 Changing types and searching archives ……………………………………….. 21

SYSTEM ARCHITECTURE……………………………………………………. 22 System structure design ……………………………………………………….. 22

INTERFACE DESIGN…………………………………………………………... 23 Interface Consideration 1………………………………………………………. 23 Interface Consideration 2………………………………………………………. 23 Interface Consideration 3………………………………………………………. 23 Interface Consideration 4………………………………………………………. 24 Interface Consideration 5………………………………………………………. 24 Interface Consideration 6 ……………………………………………………… 25

TESTING DESIGN………………………………………………………………. 25 Functional Testing ……………………………………………………………... 25 Usability Testing ……………………………………………………………….. 25 Scenario Testing …………………………………………………………… 26 Direct Observations ………………………………………………………... 26 Questions & Interviews……………………………………………………... 27

INTERFACE DESIGN EVOLUTION. …….…….…….…….…….…….………. 28 CROSSOVER PLAN……………………………………………………………… 30

IMPLEMENTATION……………………………………………………... 31

DATABASE CONNECTIVITY………………………………………………… 31 CODE……………………………………………………………………………. 31

Establishing a connection throughout the code ……………………………….. 31 Demonstrating the output of the previous query ……………………………… 32 Demonstrating the main functionality of the system ………………………….. 33

Engineer logging overtime………………………………………………… 33 Form Validation Techniques ……………………………………………… 35 Enabling the managers to see their team holistically……………………… 35 System is maintained over the web…………………………………………. 37

IMPLEMENTATION OF USABLE ASPECTS OF DESIGN…………………… 37 ADDITIONAL FUNCTIONALITY……………………………………………… 40

Page IV


TESTING……………………………………………………………………. 41 FUNCTIONALITY TESTING…………………………………………………… 41 END USER TESTING…………………………………………………………… 41

Feedback………………………………………………………………………... 41 Major issues……………………………………………………………………. 41

Additional functionality & usability……………………………………….. 42 Usable Design inconsistencies and additions……………………………… 42 System ownership …………………………………………………………. 43 Functional errors in dates………………………………………………….. 44 Server problems …………………………………………………………… 44 Selective responsiveness under questioning ………………………………. 44 Positive Comments ………………………………………………………… 44

ROLLOUT………………………………………………………………………... 45

EVALUATION……………………………………………………………… 46

CRITERIA FOR EVALUATING THE SYSTEM ………………………………. 46 User requirements evaluation…………………………………………………… 46 Applying the quantifiable criteria……………………………………………….. 47

CRITERIA FOR EVALUATING THE PROJECT AS A WHOLE ……………… 48 FUTURE ENHANCEMENTS ……………………………………………………. 49 MAIN ADVNATAGES OVER THE OLD SYSTEM…………………………….. 49 EVALUATION SUMMARY……………………………………………………… 49

BIBLIOGRAPHY…………………………………………………………… 50 APPENDIX A………………………………………………………………… 52 APPENDIX B………………………………………………………………… 54

PROJECT GANTT CHART………………………………………………………. 54 BREAKDOWN OF GANTT CHART……………………………………….……. 55 REVISED GANTT CHART………………………………………………………. 56

APPENDIX C………………………………………………………………… 57

FLOW DIAGRAMS…….…….…….…….…….…….…….…….…….…………. 57 PROPOSED SYSTEM STRUCTURE DIAGRAMS…….…….…….…….……… 58 IMPLEMENTATION SCREEN GRABS…….…….…….…….…….…….……… 60

APPENDIX D………………………………………………………………… 64

TABLES OF FUNCTIONALITY…….…….…….…….…….…….…….………. 64

APPENDIX E………………………………………………………………… 65

Page V


USABILITY CHECKLIST…….…….…….…….…….…….…….…….…….….. 65

APPENDIX F………………………………………………………………… 66

FUNCTIONAL TEST PLAN…….…….…….…….…….…….…….…….……… 66 FUNCTIONAL TEST SHEET: RESULTS………………………………………... 70 TEST DATA FOR FUNCTIONAL TEST…….…….…….…….…….…….……... 75 QUESTIONS FOR SEMI STRUCTURED INTERVIEWS …….…….…….…….. 76 SUBSEQUENT REPOSNSES …….…….…….…….…….…….…….…….…….. 80 SCENARIO TESTING…….…….…….…….…….…….…….…….…….…….…. 98 SUBSEQUENT RESULTS…….…….…….…….…….…….…….…….…….…… 100

APPENDIX G…………………………………………………………………. 104

Page VI


1 Introduction _____________________________________________________________

1.1.1 Background

The basis of the project is a development of a Web Based Overtime Logging System for Reuters.

The request came from the Client Site Services (CSS) department that deal with managing the

maintenance and installation of Reuters Terminals on client sites. The managers within CSS want a

method of holistically tracking the overtime work of their engineers. The current system is a combination

of paperwork and highly dated spreadsheets. Issues of dual access and a general inefficient business

process are apparent. The current process is also complex and inconsistent, with a moderately high

turnover of administration staff within the department adding to the problem of learning the current

system. The business process could be re-engineered using the existing technologies and methods, as

there is scope for improving this approach. However the department has expressed a desire to make a re-

engineered version of the system available on the corporate Intranet. The 40 internal engineers that use

the current system have all recently been given access to dial up facilities off site and the management are

keen to harness improvements to business processes using this recent development.

The company is defined as “A global information company providing indispensable information tailored

for professionals in the financial services, media and corporate markets. Our information is trusted and

drives decision making across the globe. We have a reputation for speed, accuracy and freedom from

bias” (Reuters, 2003). With this corporate definition, a web based Information System solution could fit in

line with the corporate philosophy, it would seem appropriate so long as it maintains speed and accuracy

in the delivery of information. In 2002 Reuters United Kingdom and Ireland (UKI), which CSS belong to,

invested considerably in a new large corporate server, called the Webfarm, to migrate existing and host

new Intranet sites. Management are also keen to have systems running on this new and fast server. 1.1.2 The Project

The project will reflect upon the process of developing a web based system as well as the methodology

used, usability engineering and methods of evaluation.

Page 1


1.1.3 Aims of the Project

The successful development of web based solution to the problem set by Reuters. ‘Successful’ refers to

the delivery of a usable and functional system justified in evaluation and testing.

1.1.4 Objectives of the project

1. To clarify and finalise requirements

2. To select an appropriate methodology

3. Design website structure, appearance and functionality.

4. Successful implementation of the system onto the Reuters Intranet

5. Evaluate the effectiveness of the system in terms of functionality, usability and measure how

well it met the requirements.

1.1.5 Minimum requirements

A final working product that meets the functional and usable requirements set by Reuters.

1.16 Exceeding the minimum requirements.

The final product should not only meet the usable and functional needs of the system, it should surpass

them. The users may lack the understanding of the capabilities of what the system could do or feel like,

therefore additional functionality will be prescribed and usable design applied outside the user’s current

awareness.

1.2 Relevant Research

Research for the project has focused on:

• Principles for System Development

• Methodological Approach

• Candidate Methodologies

• Defining A Project

• Usability

1.2.1 General Principles for system development

Within any development of a system it is advised that a problem solving approach should be

followed, and before starting on developing the system considering the fundamentals of systems

development will help to give structure. (Whitten et al, 1994) General principles of system

development (Whitten et al, 1994):

Page 2


• The users should be involved:

Successful development of any information system should have end user involvement. However there

still lies a barrier of ‘us and them’, leading to communication breakdown and not meeting system

requirements. There are many arguments for and against end user involvement, but it is common belief

that it entirely depends on the context of the system you are building and the organisation you are

developing it for. User involvement will be limited in the case on this development. As the users are

based in London there will only be interaction in the requirements and evaluation phases of the project.

• A problem solving approach should be used:

The ISDLC is a problem solving approach to systems development. An understanding of the problem

should lead to a definition of the requirements of any suitable solution. The solution also should be within

the context provided. As a project management tool the ISDLC offers a well defined structure as a whole.

• Phases and Activities should be determined:

The size of the problem can be reduced if broken down into iterations. This allows components of the

development to be altered if say, the requirements change at all. The analyst can go back refer, or alter the

original conceptualisation. In terms of the Overtime Logging System it can be broken down into iterations

of users and functionality to help reduce the overall complexity of the development as a whole.

1.2.2 Candidate Methodologies

Various development methodologies have been analysed in ensuring that the most appropriate approach is

applied.

1.2.2.1 Structured systems analysis and design methodology (SSADM)

SSADM is one of the most comprehensive methodologies that have been developed. Primarily used in the

British Civil Service, the emphasis is on a highly structured, rule driven and guideline based theory. In its

version 4 it has seven stages from 0 to 6. It has its own set of timescales, plans controls and monitoring

procedures. End products (deliverables) of each phase are precisely defined, and this encourages use of an

appropriate project methodology. The recommended practice is to adopt PRINCE.

The methodology is highly time consuming as is well suited to very large scale systems, due to the amount

of complexity is construction. It is often suited to critical systems as the level of detail reassures the

developer. Its three basic techniques of DFD’s, entity models and entity life history are common to a

number of methodologies because of the assurance of detail they bring to analysis (Avison & Fitzgerald,

1995).

Page 3


1.2.2.2 Structured Analysis Design and Implementation of Information Systems (STRADIS)

This methodology is mixture of structured design and structured implementation techniques. Developed

by Gane and Sarson, this methodology is conceived to be applicable to any Information System,

irrespective of size and whether or not it is to become automated. This methodology is typically applied

to a situation when there is a backlog of systems to be developed and insufficient resource to devote all of

the time to a new system. It uses a top down iterative approach (Avison & Fitzgerald, 1995).

1.2.2.3 Yourdon Systems Method (YSM)

Similar to STRADIS, the top down approach to systems was broken down into smaller units. However,

the latest version (3.0 1993) has a ‘middle out’ approach. The analyst gathers information about the

system using a top-level context diagram, which highlight system boundaries. Then, after further

information gathering via interviews with internal users a list of what must be responded to is drawn out.

YSM looks at both the organisation as a whole and the individual system; Enterprise and system

requirements are modelled together. (Avison & Fitzgerald, 1995)

1.2.2.4 Object Orientated Analysis and Design (OOAD)

OOAD is a highly dynamic methodology that allows very flexible systems to be developed. It uses 4th

generation languages to develop component based architecture to systems. OOAD was developed in the

late 80’s by Booch, Coad, Yourdon, Martin, Odell and Runbaugh. It consists of 5 major activities: Finding

class-&objectives, identifying structures, identifying subjects, defining attributes and defining services.

(Booch, 1994)

These activities are not necessarily sequential stages, but it offers the analyst the ability to rotate around

the conventional analysis phase. This methodology is highly useful for developing generic systems.

Components that are developed within the system can be applied to other systems. This makes this

methodology scalable and flexible. (Johnson, 2000)

1.2.2.5 Effective Technical & Human Implementation of Computer-Based Systems (ETHICS)

Other types of methodology approached in the research looks for more soft systems principles of

development. The ETHICS methodology defines the main objective of the system is to improve the

effectiveness of the users and improve their quality of life. This is not necessarily to protect jobs of users,

but more so that the system fits in line with the objectives of the management and general organisation

(Mumford, 1995). ETHICS emphasises systems that fit in line with the users as it has a large degree of

user involvement. An ETHICS approach is suited to systems where acceptance by the users and by the

Page 4


organisation is paramount. However it is demanding in terms of end user interaction and therefore cannot

be considered as viable for this project (Avison & Fitzgerald, 1995).

1.2.2.6 Soft Systems Methodology (SSM)

Following on from the ETHICS approach, SSM is another example of a human orientated methodology

(or soft approach.) The view that the whole is greater then the sum of all parts is the underlying concept.

The complexity of human activity systems act differently when studied individually, this is opposed to

looking at the system in its entirety. The understanding of a soft systems approach is that there is only so

much you can learn of a complex situation through data modelling and a structured approach. Primarily

this is seen as an analysis model, the front-end before proceeding to the hard ‘aspects’ of systems

development. (Avison & Fitzgerald, 1995)

1.2.2.7 Rapid Application Development (RAD) and Dynamic Systems Development Methodology

(DSDM)

The overall objective is to get the easiest and most important 75% implementation done within a 90-day

time box and the rest to follow. It allows users to envisage additional requirements based on what they

have already. RAD is not based on the traditional lifecycle model, but adopts a prototyping approach. It

focuses on identifying important users and involves them as much as possible in the early stages. RAD is

based of 4 phases Requirements Planning, User Design, Construction and Cutover. Elements of this

methodology are more applicable to the project such as the implementation within a 90 day slot. RAD,

however, is based on user involvement at early stages in what is described as Joint Requirements Planning

(JRP) and Joint Application Design (JAD) (Avison & Fitzgerald, 1995) A further enhancement to this

methodology is to consider elements of Dynamic Systems Development Methodology (DSDM). This

uses the principals of RAD but is specifically used in the development of modern dynamic systems. Part

of this methodology incorporates a refining and prioritising of requirements by applying the MoSCoW

rules. A suggested practice in the development of a RAD project, it will allow focus on the main

objectives. It will also allow the finalised requirements (Section 3.1) to be separated into four categories

in order of importance, and give one guidance when implementing a system (Stapleton, 1997).

The requirements are defined as Must Have, Should Have, Could Have, and Would Have

Must Have “Fundamental requirements of the system, without them the system is worthless and

unworkable”

Should Have “For requirements that are important and classed as mandatory if there was less of a time

constraint”

Page 5


Could Have “For requirements that can easily be left out”

Would Have “For requirements that are valuable but cannot be implemented this time around (Stapleton,

1997)”

1.2.3 Defining a project

After defining what constitutes the general development of a system

Yourdon, (Yourdon 1998) defined a simple project as having 1’000 to 10’000 lines of code, with three to

four programmers working on the project for 6 – 12 months. This sort of project is large enough to have

some element of project management. However it may be unnecessary to have such a structured approach.

Yourdon also went on to suggest that the structured methodology will lead to a much more stable system

but it will eat into development time, it is therefore fair to assume that a small project does not need as

much structure. It is also conclusive that the size of the project is one of the factors that define the

methodology that is implemented. These definitions will have decisive implications whilst evaluating the

various methodologies.

1.2.3.1 Defining this project

By applying the principles of Yourdon in defining a project, a web based overtime logging system will not

contain more then 10’000 lines of code and the project has to do be completed within 6 months (Yourdon,

1998). Therefore the project as a whole is considered simple as opposed to complex and this will affect the

final methodology chosen.

1.2.3.2 Applying an appropriate methodology

After defining the project, there are also major factors in determining the methodology that is chosen, for

example the fact that the solution is likely to be a web based can prove to be an important factor of choice.

Typically web based system users have little interest in helping with the development of a system. If a

user is interested in a site they will use it, yet getting them to help with requirements gathering and testing

would prove difficult (Clemmensen, 2001). However, the thoughts of Clemmensen would not have the

same relevance in this system, as they apply to general public web systems, this is an internal system and

the users are defined.

Additional factors to consider in a methodology for web development, particularly in contrast to

traditional approaches are:

The development cycles once measured in months are now measured in days •

• Changing business models, continuously evolving techniques

Page 6


Higher software quality has never been more critical … should your software fail, so too could

your business

•

•

•

•

Unprecedented 24x7 global exposure

Unpredictable Web usage and traffic patterns

You’re trapped in the e-software paradox: you must build it fast and build it right! (Clemmensen,

2001)

A major final factor in the choice of methodology is the fact that there is little interaction with the end

users as they are in London. This issue would suggest a methodology that emphasises ensuring

requirements are correct and detailed first time.

SSADM is regarded as time consuming and therefore is more appropriate to very large-scale systems due

to the amount of complexity in construction (Avison & Fitzgerald, 1995). Yourdon’s definitions of

projects defines this project is a small-scale, thus SSADM or similar large methodologies should be

rejected. Also a complex and well-defined methodology is inappropriate for a small web system, the

limited time scale of the project allocated to development will restrict the detail required from the various

stages of a complex methodology such as SSADM.

The SSM and ETHICS (soft) approaches should be rejected on the basis that they are intensive in terms of

demand on the users to be involved. As stated the users will not be involved in the development of the

system apart from requirements gathering and testing, this is due to distance.

The OOAD approach is also not applicable, as the system would be developed in Cold Fusion, which is a

non object-orientated language.

A RAD approach would be the most applicable to the project, especially its emphasis on developing a

system in a relatively short period of time. This is reiterated from Clemmensen’s additional constraints of

developing web based systems. Elements of RAD will be omitted, such as the JRP workshops as these are

not feasible with the limited interaction with the end users. Avison & Shah define a methodology as “A

collection of procedures, techniques, tools and documentation aids which help systems developers in their

efforts to produce a new information system. Many organisations have developed their own ‘in-house’

methodology, selecting appropriate tools and techniques from various commercial methodologies.”

(Avison & Shah, 1997) Therefore it is perfectly reasonable to customise a methodology to your needs.

Page 7


Elements of a traditional life cycle model, which act as project management tool, will be sufficient in

ensure that the system is on schedule for completion and that testing is incorporated in the development

process. The traditional life cycle model is a prime example of a methodological approach to take. This

would go through each stage of the project, from identifying requirements to designing the system to

implementation and finally to testing (Avgerou et al, 1998).

1.2.4 Usability

In the development of the interfaces for the overtime logging system there needs to be considerable

understanding of usability. It is important not only that the system works but that the users want to use it

and can do so easily. Background research has also taken into consideration guidelines on usable design.

Jordan, 1998 Commented on 10 principles of usable design applied to any system. Jordan’s principles

include:

Consistency - tasks that are performed are done so in similar ways. This will apply to the way the site

navigates and the logging processes for the engineers are the same as other aspects of data-entry. Also

editing and deleting facilities should be consistent for any data that is being edited on the system. The

design could also bear resemblance to similar web systems that are in use.

Feedback - design the product so that the actions of the user are acknowledged and a meaningful

indication is given about the results of these actions. This could be the inclusion of screens to indicate

then data is being processed.

Visual clarity - information is read quickly and easily, it should be understood without confusion. This

will affect the font style that is selected, size shape etc

User control - the user should have as much control over what is happening. This can be applied in the

design of the system’s site navigation (Jordan, 1998).

The background research also covered some additional usable considerations. Based on the principles of

usable design from Hicks & Essinger some additional fundamentals could be applied.

Revealed Structure - The physical structure of the system should be hidden. Any structure that is

revealed should be done so graphically with navigation, icons etc. This will impact the choice of

diagrammatic representation used to define various areas. It should be clear that engineer is working

within the boundaries of his part of the system without looking at the URL

Support learning through exploration – Following on from the previous point, consideration towards

allowing the user to make options and navigate around the system, the visible structure though graphical

representation should encourage natural learning.

Page 8


Give ‘psychological closure’ - On aspects such as maintenance, navigation and changes to data so that

the user does not have to store this in their own memory. This is especially relevant if a user begins

altering the system, as it will be a database driven site the user should be aware when the data has been

committed. (Hicks et al)

The principles mentioned are applicable to web sites and systems in general. Nielson offers specific

guidance for developing an Intranet site. He refers the large-scale usage of internal terminology in

Intranet sites. It would put off customers of an external site but employees perform better when they

specialised terminology is used. Precise language helps internal users to understand exactly what is to

be discussed (Nielson, 2000).

Neilson also goes to point out that for Intranet design efficiency, memorability and error reduction

become the most important usability attributes. Because the users are using the Intranet everyday they

become experienced users and the efficiency to which they can navigate the Intranet and get their work

done will determine their productivity (Nielson, 2000).

1.3 Development Code

Reuters’ internal web systems are generally built in Cold Fusion. The reason for only having the one code

is that it makes it easier to further develop systems in the same language then to rebuild them from

scratch. Also the web teams specialise in this language, and developing in a different language would

cause conflict.

1.3.1 Cold Fusion

Cold fusion consists of several components which when put together form a very powerful development

and deployment environment for web applications. It consists of the following components:

Cold Fusion Mark-up Language (CFML) •

•

•

•

Cold Fusion Application Server

Cold Fusion Studio

Cold Fusion Administrator

CFML is very much like conventional HTML. It is a subset of HTML in that it is a tag based and does not

require learning a programming language with a unique syntax, such as ASP, Jscript and VBScript.

CFML can describe elements of web pages, such as tables, but it does a whole lot more. It defines actions

Page 9


that take place on the server and has powerful interactivity like ASP. The server administrators deal with

the other aspects of Cold Fusion, such as Studio and application server. For the sake of comparison these

elements will be overlooked. However it is important to understand that the coding behind the relevant

tags is inside the Application Server, therefore alleviating the programming complexity from the user

(Danesh & Motlagh 2000).

1.4. Planning

1.4.1 Project Plan

Appendix B has an initial Gantt chart that outlines the proposed plan of developing this system. As

previously stated the management of the project will follow a classic life cycle model, hence Feasibility,

Requirements Analysis, Design, Implementation and Evaluation. The specified time scales for each

section have consideration of adjustment and contain an overlap, the Gantt chart demonstrates the

overlaps. They are there to ensure buffer periods for adjustment.

Feasibility (6 – 8 Weeks)

Feasibility will discuss the appropriateness any solution and will also focus on the constraints of

developing a system for Reuters.

Analysis (8 Weeks)

This part of the project will focus on the feasibility of the proposed system and analyse the current

process that it used, and the relative strengths and weaknesses of solutions. The analysis will also cover

the specifications and limitations of the Reuters Intranet.

The analysis will also prioritise the specified the requirements (Section 3.1) by applying the MoSCoW

rules.

Design (5 Weeks)

Design will cover the functional and usable aspects of the system. Should a web-based solution be

provided a normalised and integral database will be designed, also the interface will have to be considered

in terms of usability. The actual web structure or architecture will also be designed. As a RAD approach

is being taken the envisaged duration for design is 5 weeks, this would be much longer if a harder

approach was applied.

Page 10


Implementation (8 Weeks) (Including Testing 5 Weeks)

A final product will have to be conceived. Deviations from design will be noted and the product will be

installed on the Reuters Intranet. The system will also be functionally tested to ensure that any data is

processed correctly and accurately. This will be ongoing throughout development. A Final test plan will

also be conceived to ensure that components of the system are not overlooked.

The final product will also be tested for usability with the end users

Evaluation (3 Weeks)

This critical stage identifies whether the initial objectives of the project have been met. It will identify the

successes and failures of the project and if the system as a whole is regarded as a success.

Page 11


2. Feasibility _____________________________________________________________ 2.1 Current System

2.1.1 Data Input

An engineer on completing overtime fill in the appropriate form that is handed to one of the team’s

Administrators. The information on the form is added to the engineer’s own spreadsheet record within a

shared team directory that can be viewed by those with the appropriate permissioning. The

Administrator’s role is to calculate the amount of overtime using formulae and to classify the type of

overtime. The standard schema for the current system is as follows:

• Date (DD/MM)

• Name

• Type (Installations /Project/Upgrade Program/Upgrade non-program/Power up/ Power

Down/Rota Time Off/Time On Call)

• Duration (Hours)

• Client Number (As allocated by Reuters e.g. UK088765)

• Total (Hours)

When the Field Service Managers want to view overtime for individuals they have to go to the appropriate

shared directory and ensure that nobody else has it open. (Fig 2.1 Appendix C)

2.1.2 Data Manipulation

If for some reason the information that was entered has caused a discrepancy, such as a client reports that

no work was done on the time stated, then the information needs to be manually retrieved and altered

accordingly following approval from the appropriate manager. The engineer’s personal spreadsheet is

recovered from the shared directory and the corrected data is inserted over the top. The same process

applies if, for example, the engineer’s name is altered due to marriage. The engineer should not have

access to his file as he or she may be able to alter the information illegally, it should be a read only access.

Any alteration of data needs approval. (Fig 2.2 Appendix C)

2.1.3 Advantages of the current system

• The process is relatively simple in process, even if it is not efficient.

• It’s an established process; the various users are aware of their roles and are comfortable with

them.

Page 12


• It is flexible in that it can be done as and when the PA’s have the time to input the data.

2.1.4 Disadvantages of current system

• There is no guarantee the data that is input is of adequate quality or done in a timely fashion.

• The processes of amendment is lengthy and laborious

• There is no way of viewing the data comparatively or holistically.

• A limit of overtime cannot be flagged by the system as it is static.

• The engineers have to be in the office or fax from on site to get the data to the PA. This is highly

inflexible and adds to the demands of the process.

2.2 Hardware Constraints

The major hardware constraint of the project is the fact that the development has no physical connection to

the Reuters Intranet as it is being developed on an independent unit with its own server software. The

eventual migration of the system will be done by using a physical copy installed on a set space on the

corporate server in London. There are also minor limitations in the processing ability of the machine that

has been assigned to this development however this does not substantially differ in ability from that of the

portable machines that the Engineers use.

Some of the engineers may be logging on remotely from a client site or at home via a dial-up network.

This means that the site has to be maximised in terms of loading time, minimising the amount of complex

script. Delay is inevitable when querying a database and confirming permissioning, particularly during

high periods of demand for example. However most of the logging will be done spread across a day and

with no more then 5–10 logs a day.

2.3 Software Constraints

The database software that will have to be used is Access XP as that is what came with machine used to

develop the system. Access is also the Reuters standard for database driven internal websites. There are

some sites that use Oracle but they are extensive client information databases and used internationally by

the company and by extranet clients. However as the standard database for the company is Access 2000,

the project database will have to be saved as compatible to Access 2000 standard, a feature within Access

XP.

Page 13


The operating system that dominates the Reuters internal network is Office 2000 (which is built on

Windows NT technology.) The development will take place on a machine that has Windows 2000

Professional Edition there will be no conceived problems in compatibility.

Cold Fusion is the language that has been selected to develop the system. The web team for the

department that the system is going to be used in are familiar with Cold Fusion. It is also in line with the

methodology suggested for development. It is a simple tag based language and can be very easily adapted

should requirements change. The corporate servers also have the latest version of Cold Fusion MX server

software so in running cold fusion they are fully compliant.

The development of the actual pages has to be done using Dreamweaver. This is because that

Dreamweaver is fully compatible with Cold Fusion development; in much the same way the MS Front

Page supports ASP. Also in using Dreamweaver it will not generate excessive amount of scripts that

could cause additional delay in site loading time.

When building a web system within Reuters there are certain guidelines that are put in place to ensure that

the system can be maintained and developed further should it need be. The structure of the site should

have secure elements in separate folders. The reasoning behind this is that the server administrator adds

permissioning by folder within a web structure using permissioning software such as Hyena. This

integrates with the corporate LDAP to permission by username. The permissioning software effects the

way a user maps to the server and what they see if they would like to edit the site, it also means that there

is a password prompt when entering via the website into secure areas. The database also needs to be kept

in its own folder; this is for quick access to developers if they need a hard copy of data. There are also

general ‘good housekeeping’ rules such as a separate image folder etc.

Reuters also have a corporate Cascading Style Sheet that should be used on any internal site. This is a

prime directive of the Corporate Web Office (CWO) and applies to any Reuters web site. The CSS folder

has been supplied along with the software for development. The CWO also has guidelines on use of the

Reuters logo.

Page 14


3. Requirements Analysis _____________________________________________________________ 3.1 Stated Requirements of the System

The specific requirements of the system have been generalised into the following list. Each requirement

has a relative weighting of importance, all of which should be considered when planning the development

of the system particularly with the temporal constraints and the constraints of the development language

chosen. Reuters delivered more specific breakdown of systems requirements to generate the following

list:

3.1.1 Functional Requirements

1. To enable engineers to add their overtime

2. To enable the managers to be able to see the overtime for their own team 'holistically'

3. That total hours be calculated in a given range for the managers to view.

4. That the system is maintained over the web (i.e. you can alter it without bothering others)

3.1.2 Usable Requirements 1. Easy to use.

2. Manual editing facility.

3. Easy to view / Print off.

3.1.3 Perceived methods of exceeding these requirements

The minimum requirements of the project are: “A final working product that meets the functional and

usable requirements set by Reuters.” (Section 3.1.1 and 3.1.2 highlight these stated requirements.) The

final product will meet and exceed these requirements in the following ways:

• By applying usability theory (Section 1.2.4) to the development of the interface it may increase

acceptance and effectiveness.

• Apply customised dynamic ‘home pages’ for each user entered into the system

• Allowing adding, deleting and editing of jobs

• Allow searching of jobs by range, specific date and individual engineer

• Giving each manager access their team of engineer’s details only to reduce the information load

• Validation of forms to ensure data integrity

3.2 Applying the MoSCoW rules

Page 15


Section 1.14 outlines the project objectives. The first objective of the project is to clarify and finalise

requirements (Section 3.1.) Applying the MoSCoW rules finalises the requirements and thus meets the

first objective of the project.

Must Have

• To enable engineers to add their overtime

• That total hours be calculated for the managers to view

• That the system will be maintained over the web (i.e. you can alter it without bothering others)

Should Have

• To enable the managers to be able to see the overtime for their own team 'holistically'

• Easy to use

• Manual edits

Could Have

• Easy to view and print off

Would Have

• In implementing the system there may be requirements that were not envisaged at first. They will

be noted down and put forward for further development versions of the system.

This will affect the design and the development of the system, as certain components, i.e. the ‘should

have’ and ‘must have’ functionality takes precedence. These make up the basic framework of the site.

The additional requirements suggested in (Section 3.13) will be regarded as ‘would have’. The end users

lack the understanding of the possible capabilities but meeting their core requirements takes precedence.

Page 16


4. Design _____________________________________________________________ 4.1 Database design

4.1.1 Proposed ER Diagram

A manager has many engineers but an engineer can

only belong to one manager.

Every job must have an engineer

Not every engineer on an overtime job

This ER diagram will now form the basis of the

whole structure of the table. The database structure

is relatively simple in structure; however it is

necessary to model the system off such a structure.

Job

ManagerEngineer

4.1.2 Normalisation

Normalisation is necessary to ensure that the data that lies within the database is ordered into logical

groupings. One piece of information is in one place and all related pieces of information are linked using

relations as opposed to the duplication of data. The process of normalisation results in data with

simplified relations, reduced redundancy and less likelihood of anomalies when manipulating that data.

Normalisation should not result in any data being lost from or added to the data provided in the original

set of un-normalised relations.

Four stages of normalisation

First normal form (1NF)

Second normal form (2NF)

Third normal form (3NF)

Boyce-Codd Normal Form (BCNF)

All attributes are atomic in that they only have one value and not a set of values so that they may be

compared in 1NF

Page 17

reuters

need to reference ulman and widdom


2NF is all non-key attributes are functionally dependent on the entire key and not determined by any part

of that key. If this is not so then a separate relation must be created with those attributes that are

dependant on none of or only part of the key together with that key.

The transitive dependency is removed in 3NF. All non-key attributes should be functionally dependant of

each other. If this is not so then create new relations that does not show any non-key dependence.

BCNF requires each determinant (attribute or combination of attributes that determine the value of

another attribute) be a candidate key. Any primary key will be a candidate key, and hence any relation in

BCNF will be in 3NF, but relations in 3NF may not be in BCNF.

4.1.3 Application of normalisation to attributes

There are various attributes that are necessary for the system to function. They have been identified as the

following:

• For Managers: Name / Password

These are both the only necessary attributes and only attributes needed by the system. It is a waste of

resource to apply additional attributes at this stage. However there could be scope for amendments to this

schema as the system develops.

• For Engineers: Name / Password

See above

• For Jobs: Job Number / Type / Date / Duration / Description

Job number is a number that is assigned outside of the boundaries of this system. It is a number assigned

by Reuters and given when overtime work becomes available. It is a requirement that this be included for

auditing purposes. However it bears no relation to the system that is being developed here. There is no

way to guarantee that the system that generated the job number is unique. Therefore for this system a

primary key will be added to ensure that if multiple instances of a job occur they are still unique within the

system. Date is necessary as it will be the criteria by which the management can flag particular working

periods. ‘Type’ refers to the type of overtime that the job is. This will come from a separate table to

populate this table (that will act as a drop down box to ensure integrity). The list of ‘overtime types’ that

has been defined by Reuters is subject to change. This point is poignant in design as the administration of

the system needs to be able to change these types. Description is a valid attribute as it will be a free text

Page 18

reuters

also may wish to put additional types of relational diagram in here


that allows the engineer to add additional notes about the job. This is not a necessary component; however

it offers the user scope for additional detail going above the specification.

Unormalised 1NF 2NF 3NF BCNF TABLES Mgr_Name Mgr_Name Mgr_ID Mgr_ID Mgr_ID Manager Mgr _Password Mgr _Password Mgr_Name Mgr_Name Mgr_Name Eng_Name Eng_Name Mgr _Password Mgr _Password Mgr _Password Eng_Password Eng_Password Eng_ID Eng_ID Job_No Job_No Eng_Name Eng_Name Eng_ID Engineer Job_Date Job_Date Eng_Password Eng_Password Mgr_ID* Job_Type Job_Type Job_ID Job_ID Eng_Name Job_Description Job_Description Job_No Job_No Eng_Password Job_Date Job_Date Job_Type Job_Type Job_ID Overtime_Log Job_Description Job_Description Eng_ID* Job_No Job_Date Job_Type Job_Description Bold determines elected primary key and grey* is the foreign key definition.

In each case the attributes have a left hand functional dependency on a key. For example Job_No is not

functionally dependant on the Job_Date as a particular job does not have to be having been done on a

particular date. The Job_ID does offer functional dependency for the rest of the attributes that make up

the job schema. This table does not show any definition of a PA, the reason for this is that they are not as

relative to the system modelling a bear no relevance in normalisation. There will still be a table for the

Administrators but this is for administration purposes.

An Administrator consists of:

Admin_Password

(This is a generic logon as they frequently change)

PasswordID

(set as an primary key should the level of administration change)

Page 19


4.1.4 Relationships

Fig 4.1 Relationship diagram taken from Access XP ‘relationship view’

4.1.5 Additional Tables needed for system

The system will also need an additional table that populates the drop down list for the type of overtime.

This table, shown in Fig 3.1 will be called “type” and its attributes will consist of “Type” and

“overtimeRef”. “Type” will be the textual representation of the overtime reference, for example type

“Begging of shift” will equal overtime reference “1”. By representing the type by a number it saves disk

space by minimising the text in the log.

4.2 Overall View of web system design

This section refers to the tables in Appendix D and Fig 4.2. In designing the system an understanding of

what each user’s role and subsequent functionality is fundamental.

Fig 4.2 highlights all possible entries into the system. If a user does not belong to any of these then they

can only view the home page.

Figs 4.3, 4.4 and 4.5 Appendix C highlight the relative proposed structure for each type of user, these

diagrams are the blueprints for the implementation.

Page 20


Possible points of access into the system

If not in system

Register

Login

As PA As Manager As Engineer

Administer System View Team

Accounts

Access Own

Account

Upload Overtime

Edit Overtime Details

Edit Engineer

Edit Manager

Fig 4.2 Diagram of possible points of entry into the system

4.2.1 Logging Overime

The first functional requirement specifies that overtime should be able to be logged. Table 3 (Appendix

D) demonstrates that all users have the ability to log overtime. If, for instance, the system went down and

a backlog was created, the administrators would enter the records manually so they need this functionality.

Engineers are not permissioned to alter records once they have inserted them, this prevents malpractice.

The ability to do this is placed with the administrators, who can alter or delete anybody’s records and the

manager’s who can alter and delete their own teams. This ensures the integrity of the records to some

extent.

4.2.2 Dealing with Engineers & Managers

Tables 1 and 2 (Appendix D) highlight the user types that are permissioned to altering/adding/ removing

users within the system. An Engineer can register himself, or a Manager can do it for him as can an

Administrator. An Engineer can change his own details, such as passwords and which manager they

belong to. The manager does need functionality like this, so the Administrator, who is effectively a ‘super-

user’ can change or delete anybody. An Administrator is also the only user type that can delete, edit and

add new managers into the system. This ability needs to be kept in one place thus ensuring the

relationships and integrity remain.

Page 21

reuters

in last section say how this needs record of altering data.


4.2.3 Changing types and searching archives

Tables 4 and 5 (Appendix D) show that all users have some means of searching archives. An engineer is

only allowed to view his own records for management reasons. A Manager can view an individual’s

records or search their team’s records, this is the only data that would interest them and prevents

bombarding them with too many options. The administrator has the ability to view everybody’s records,

an appropriate means of filtering the records to get to the Engineer they are looking for will need to be

implemented.

4.3 System Architecture

4.3.1 System Structure Design

If the site structure is unorganised, then no site navigation design can rescue it. Poor information

architecture will always lead to poor usability. The two most important rules of site structure are to have

one and to make it reflect the users’ view of the site and its information and services Neilson, 2000).

The three types of user in the system require different points of access from the main page. From a future

perspective it is viable to ensure that the files related to each type of user are grouped together. All files

relating to managers, for example, will be included within a management folder on the root of the site. In

doing this it ensures logical design for any development team that may wish to alter the system at a later

stage and locate pages within the site. It also makes sense to have a logical file structure as some

parameters within Cold fusion pages (.cfm) get passed along as a URL. It would be logical to ensure that

the structure reflects the ability to pass URLs simply and dynamically.

The structure also has to reflect the software constraints. Section 2.3 refers to the secure elements being

kept in a separate folder due to the method that the server permissions users to secure areas. The only

section that needs absolute security is the admin section. All pages to do with administering the system,

as technically these are ‘super-users’, should be kept separate from engineer pages for example. The

security, for demonstration purposes, will come through the database passwords administered locally

though Cold fusion. This is not the most secure way and managing the system but it demonstrates the

functionality that can be applied by the server software.

The proposed structures for the system is indicated in Appendix C. Figures 2.3 though to 2.6 demonstrate

the outline for structure.

Page 22


4.4 Interface Design

4.4.1 Interface Consideration 1: User areas are clearly defined

The web system is going to have three types of user, Administrators, Managers and the Engineers. Each

of these types of users will have to have their own area following the guidelines of usable design having

Visual Clarity. It should be clear to an administrator that they are in an administration area, and if they

are not it should be simple for them to get to it. This will be resolved by using the method of navigation

using a side bar. This will fit in with the idea of hiding address from users by incorporating the navigation

in a frameset.

4.4.2 Interface Consideration 2: Colour scheme that offers clarity and is in line with organisation

The colour scheme of the site has to take two things into consideration. The first is that garish colours or

incompatible colours such as blue and black will not work. This is especially poignant in that the site is

reliant on people viewing the data as this is the main functionality of the site.

The visual clarity aspect of usable design will be emphasised in the choice of fonts and colours that are in

line with corporate standards are easy to read (Hicks and Essinger).

The colour has to be clearly seen as is the font that is used, it also has to be able to look good and clear if

printed out. The second consideration is that sites within Reuters are advised to use the corporate

Cascading Style Sheet. This will be included in the implementation; however the CSS may be altered for

design flair.

Most of the users of the system will be the engineers and a large proportion of these are male. Men tend

to be more trusting of neutral colours, especially blues. Psychologically speaking, there is also a large

prevalence of colour blindness in men (about 8% of all men). As the site is geared mainly towards a male

audience appropriate colour cues should be selected. This can be seen in using Red as a cautionary colour,

with 8% of men being colour blind they may miss this. It is advisable therefore to have asterisk for

example in mandatory fields on a form (Braun et al, 2002)

4.4.3 Interface Consideration 3: General principles of usable design applied

Based on the background research there are a number of guidelines for usable design that should be

considered in interface development (Jordan, 1998). The text and areas of similar functionality have to be

consistent and should fit into users resource limitations. This will be approached by developing simple

jpeg images to identify the area the user is on e.g. “Engineer Logging”. They will also be fairly static

Page 23


images to avoid delay, i.e. the images will not be animated as this detracts away from the functionality and

is a waste of users’ resource. The dynamic parts of the site should provide the user with feedback so that

they are able to check that actions are being carried out. An example of this would be after a user logs

their information into the system they will receive a page that indicates the data was uploaded

successfully. This also encourages the prevention of double entry into the database through re-submitting

of data. Error prevention and recovery will be addressed by having an editable administration section

for both the system as a whole and the individual user. If an engineer enters their name wrong then they

have the option to alter that within their own account page. Also errors in overtime logging can be

managed by the administration section. This functionality should not be able to be accessed by the

engineers as it requires authorisation by management to alter it. The fact that the user maintains control

is highlighted with the navigation bar that will be included. Fitting in with the frameset, it is constantly on

the screen giving the user as much control as to the areas they are permitted to access.

The principles suggest by Nielson specific to Intranet sites should also be considered. Neilson suggests

that usable Intranet design should have efficiency, memorability and error reduction (Nielson, 2000).

The memorability will be emphasised though consistency of functionality. For example, to view more

detail of a particular job the user should click on that particular job. This functionality will be replicated

for other areas where more detail is required, such as activating an Engineer’s account. Error reduction

will be emphasised though error checking on the forms, informing the user where they have missed a

particular field, for example.

4.4.4 Interface Consideration 4: Structure and Support

The revealed structure is minimal and what structure that is revealed will be done so using only

graphics, as mentioned in section 4.4.1. The use of frames will again help conceal structure to the address

bar and the untrained eye. A section that helps users will be developed which is fairly standard. Also the

user will be supported through text such as “click here for more information” and “back”. This is in line

with user guidance and support requirements.

4.4.5 Interface Consideration 5: Minimising the revealed structure

There are also some additional constraints that should be considered in development of a truly ‘usable

interface’. It is advised (Hicks & Essinger) that users need not be able to see the structure of the system.

The revealed structure should be kept to a minimum and should only really be done through graphical

representation. This will affect the design in that the areas that the users are in should be identified

through symbolism either colour or graphical. The fact that the system will be developed in frames also

Page 24

reuters

although after testing they wanted this to happen point for evaluation at end


adds to hiding the structure. Security will be implemented using Cold Fusion, albeit for a temporary

demonstration reasons. The main security will be implemented by the server team at Reuters who will

apply specific restraints based on user names for example.

4.4.6 Interface Consideration 6: Allowing the user closure

Psychological closure is also an element of usable design that should be considered. For example when

an error has occurred the system should indicate this fact to the user and tell them where the problem is.

The overtime logging system could have this embedded in form validation. The error should be displayed

on the screen to reduce the amount of memory the user has to store. When updating the system it would

also be advisable to have to have reassurance on the screen telling the user what has happened. For

example “Engineer successfully entered into the system” gives the user reassurance that the correct data

has been entered. Should this not be seen on the screen then data could be entered twice or the user may

think that it has gone in when it hasn’t.

4.5 Testing Design

The system that will be developed should be tested for both functionality and usability. The system

should be proven to do what it says it does and also cater for the users needs in terms of usage. Testing

the system will be phased across two separate activities. Functional and usable attributes will be tested

respectively.

The functional testing is standard in a development like this as it ensures the integrity of the data and

functionality. Ensuring that forms have the correct validation and that data is being written to the database

are examples of functional testing.

The reason for testing the usability is that one of the requirements is a simple and easy to use system. A

measure of how this was met is done through usability testing. (Section 6 contains the testing for the

system.)

4.5.1Functional Testing

The system will have all of is functionality tested. This will be done ongoing throughout the

development; however a final test plan will be conceived when the system is complete to ensure that the

final installed product is fully working. Functionality attributes to be checked include: Links working,

Data correctly written to the database, Page loads etc.

Page 25


4.5.2 Usability Testing

Encompassing a range of methods for identifying how users actually interact with a prototype or complete

site (usability.gov, 2003). It is also defined as a technique used to evaluate the ease of use or ease of

learning of an interactive system (D’Hertefelt, 1999)

The findings of the usability test ideally want to establish what is working well on the site answering

questions like these:

Do the users complete a task successfully?

What paths do they take to in trying?

Where do they stumble? – What problems do they have? – Where do they get confused? (usability.gov,

2003). There shall be a variety of methods used in extracting the information required to justify the

usability.

4.5.2.1 Scenario Testing:

Placing the user somewhere in the system and informing them how to resolve the situation. The actions

will be recorded by observation in this case, as the user may not have the experience to be able answer

when questioned on what they did. The system is not very extensive this will be reflected in the scenario

situations. The location of the testing will make it hard to provide an amended version of these scenarios

so it will act to provide feedback and offer guidance in future development.

The findings of a scenario test could also be applied to other systems that get developed to act as a

benchmark for designing usable systems within the company. The time element will also prove a

problem. It is not possible to detract users away from their own jobs in order to test this system. In the

ideal world the users would work closely in improving a better version and a much more tailored system

for themselves. Part of a ‘discount usability evaluation’ devised by Neilson, allowing testing to be done on

a small time scale and selected expertise (Preece et al, 1994)

4.5.2.2 Direct Observations:

The users will be monitored on their interesting behaviour and performance as a way to measure the

usability. Issues that will be focused upon will include:

“Are the images distracting”

“Do the users realise where the links are on the page”

“Do they manage to fill the form in quickly enough” – This looks at the inclusion of drop-down

boxes and if the length within them proves too timely.

Page 26

reuters

need to back up justification


“Do the users attempt to try an area that they shouldn’t enter”

Direct Observation is the cheapest and most common way to record information on how the users interact

with the system. Some users may find somebody monitoring them is intrusive and their behaviour and

performance will alter as a result. This is known as the Hawthorne effect. Also as it is written down it

may not record everything the user is doing. (Preece et al, 1994)

4.5.2.3 Questions / Interviews

Following on from general observations a more detailed analysis is sought and achieved through

questioning or interviewing. This final method is simply asking the users questions while they are

interacting with the system.

The sort of questions that are considered good questions are:

• What do you think when you see this?

• Would you want to do if you wanted to achieve that?

(D’Hertefelt, 1999)

• What are the preconditions for doing this?

• What are the results of doing this?

• Do errors occur when doing this?

• Did you discover how to correct these errors?

(Neilson et al, 1986)

The other methods that will be used are lacking one key factor, the subjective opinion of the users. This

can only be defined by use of structured and unstructured interviews. The set questions that are going to

be asked will obtain feedback that is necessary for the true assessment of the system but opinions are also

useful as they may cover areas that may not have been thought of from the questions. A Semi structured

approach will therefore be used which is a combination of both (Preece et al, 1994).

Page 27


4.6 Interface design evolution

In getting to a final interface there are a series of adjustments made to an original concept shown below.

BA C D

E

Fig 4.3 Original concept of manager’s login page

A – Is proposed side bar navigation. The most common way to navigate is to have a list of all of the top

levels of the site, often a stripe down the left side. The benefit of this breadth-emphasising design is that

users are constantly reminded of the full scope of services available on the site (Nielson, 2000)

B – Is a sample of the options available, in this case, to a manager. The icons (the arrows) on the side

have a Jscript rollover effect that changed colour. The icons also have the same functionality as clicking

on the text that follows it.

C – The ‘visual clarity’ and ‘minimised revealed structure’ are dealt with though these jpegs that indicate

the area the user is in. The icons match the style of the rest of the site, i.e. with inclusion of cogs, so

maintain consistency which is another element of usable design from Jordan.

D – Here is an example of a ‘cog montage’ that has been used to decorate wastage of space, again these fit

in with site consistency.

This original design had scope for improvement, especially when considering the original requirements.

One of the wishes of the users was to ensure that the information could be printed off. The reason for this

Page 28


is so that a paper copy could be used should it be needed for verification. The black backgrounds of these

early versions did not cater for printing off. A printed version of the page would be hard to read with white

text on a black background. The site also looked untidy as it was built in frames; any overlap in size was

visible (See point E.)

The next version in design evolved addressing these issues (See Fig 4.5).

B

C

D

E

A

Fig 4.5 Revised design of the manager’s login page

A – The newer side navigation bar is much ‘cleaner’. The contents is identical but has now got a CSS

style that enables the text to shrink when it’s being hovered over. The inclusion of mini-cogs is in line

with the rest of the site.

B – The colours of the original text Jpeg has been inverted to coincide with the new white background.

C – The login has changed to a dynamic drop down off a list and is broken down into 2 steps that are

clearly identified. The text is also mainly in blue which fits in with the majority of users. There is also

the inclusion of the line which distinguishes the 2 parts of the login (name and password)

D – Use of a cold fusion form (CFFORM) is used to submit the entered data.

Page 29


E – Overall the distorted linkage between the frames is removed by having white backgrounds. It is also

much easier to read and print off. The cogs have remained a feature with a theme of ‘engineering’ and the

other icons have been removed as they appeared to clutter the screen.

4.7 Crossover Plan

They way the system will be built will mirror the structure of at typical Reuters Intranet site, (Section 4.3.)

The system will be burnt onto CD and transferred directly on to an allocated web space on the Reuters

Webfarm server. The space that has been allocated for the system is 20MB, this system cannot exceed

that. Other systems with larger databases already exist within a 20MB budget. If, after a very prolonged

period the system should grow to exceed the space the required, the server staff has software that

identifies this and an archive will be made. When the system is successfully migrated it will meet the

fourth objective of the project, “Successful implementation of the system onto the Reuters Intranet”.

Page 30


5. Implementation _____________________________________________________________ 5.1 Database connectivity

Database connectivity is managed through the Cold Fusion Administration Software. In the case of the

Overtime Logging system Cold Fusion Server MX was used to create a local ODBC connection, standard

for MS Access connections. The settings such as connections are capped to handle one machine as the

system is being developed on a single machine. When the system migrates to the Reuters Corporate

Intranet Server issues of multiple connections to the data sources are defined by the server software. They

can limit the amount of connections to improve performance, preventing users from having to queue. The

settings on the corporate server also handle the integrity of the data, ensuring that records are handled

accurately and double entries etc do not occur.

5.2 Code

5.2.1 Establishing a connection through the code

In developing the system there are a number of options that Cold Fusion allows for establishing a

connection for a given task. The connection is specific to a page but specific to a query. For example a

typical query in the system looks like this, in this case the connection string for the main engineer:

<CFQUERY name="view_name" dbtype="dynamic" connectstring="Driver={Microsoft Access Driver (*.mdb)}; Dbq=#expandpath('..\database\overtime.mdb')#;Uid=admin;Pwd=;">

SELECT * FROM engineer Order By engName </CFQUERY>

Fig 5.1 The connection string in the query that displays the drop down list of engineer’s names

The query opens with a cold fusion query tag <CFQUERY> and the query ends with a close tag

</CFQUERY>, this defines the query area. The name of the query, in this case “view_name”, is

referenced when the query is outputted. The “connectstring” specifies the database sort, in this case MS

Access, and this precedes the actual connection. The connection itself is using a function distinct to Cold

Fusion version 4.5+. The “expandpath” function returns the value of the absolute path without the user

being able to view it. The relative path is displayed next to it, which allows the localised address of the

database to be inserted. It is also noted that within a query there is a standard use of SQL to retrieve the

Page 31


appropriate data. In this case extracting all details from engineer and being ordered by name, which will

put the names in forename order.

5.2.2 Demonstrating the output from the previous query

The query from 5.2.1 was used as part of a drop down list within a form that allows the engineer to access

his personal home page. The code is demonstrated in fig 5.2.

NOTE: most of the standard HTML has been omitted so that the Cold Fusion tags stand out.

<CFFORM action="checkgo.cfm" method="post">

<table width="600" border="0">

<CFSELECT name="engId"

query="view_name"

value="engId"

display="engName"

required="yes"

multiple="no"

size="1">

</CFSELECT>

<input type="password" name="password">

<input type="submit" value="Submit" name="submit">

</table>

</CFFORM>

Fig 5.2 The query referenced in the body and within a CFFORM tag

The query from 5.2.1 is referenced, in this case, within the CFSELECT tag. Where the tag requests a

“query” the appropriate “view_name” query is encased. The tag also defines that the “engName” is the

field that is to be displayed and to pass the variable (primary key) “engID” for the next page

“checkgo.cfm” to use. The drop down is using the CFSELECT tag and therefore it has to be inside a

CFFORM tag to be recognised by the server. Fig 5.3 demonstrates the subsequent outcome of this code.

F

<CFQUERY name="security" dbtype="dynamic"

connectstring="Driver={Microsoft Access Driver (*.mdb)}; Dbq=#expandpath('..\database\overtime.mdb')#;Uid=admin;Pwd=;">

SELECT * FROM engineer WHERE engID = #form.engID# AND password LIKE '#form.password#' </CFQUERY>

ig 5.4 Subsequent query in checkgo.cfm checking the password is correct for the name

Page 32


Fig 5.3 Subsequent output of the code from Fig 5.1 & 5.2

5.2.3 Demonstrating the main functionality of the system

The functional requirements of the system from section 3.1.1

1. To enable engineers to add their overtime

2. To enable the managers to be able to see the overtime for their own team 'holistically'

3. That total hours be calculated in a given range for the managers to view.

4. That the system is maintained over the web (i.e. you can alter it without bothering others)

5.2.3.1 Engineer Logging Overtime

This is the first requirement. Once the engineer has entered themselves into the system using the register

pages their names will appear in the drop down list as demonstrated in section 5.2.2. From filling in their

password they will be taken to their own personal home page “Checkgo.cfm”. This page checks that the

local password taken from the form on the previous page is correct and displays the information relative to

the user. Fig 5.4 demonstrates the query code that checks the password.

This time the query is called “security” and the SQL is checking the password that was inserted. As the

password is a general text password and is not critical a “like” function is used. This can be altered to an

“=” to only allow the exact password.

Page 33


F T

t

p

m

a

t

d

F

<body > <cfif security.recordcount is "0"> <cfform action="checkgo.cfm" method="post"> <table width="600" border="0"> ERROR........... Sorry you appear to have entered the wrong password for your account</font><br> Try again, re-enter your password below...</font><br> <input type="password" name="password"> <input type="submit" value="Submit" name="submit"> <cfoutput><input type="hidden" value="#form.engId#" name="engID"></cfoutput> Or, alternatively you may have selected the wrong name. Re-select your name by</font> <a href="main.cfm" class="navbar">clicking here</a></td> <cfform> <cfelse> <cfoutput query="security"> #engName#'s personal overtime account </cfoutput> Welcome to your personal overtime account page. Here you can log your own overtime and change your personal details within the system<br> </cfif> </body> </html>

ig 5.5 Password Checking

he CFIF is a simple IF-THEN construct or expression builder. The CFIF tag is used here to specify what

o do with the password that is entered based on the query in Fig 5.4. If the “record count is 0” or the

assword from the query “security” does not match then output the message underneath. The error

essage allows the user to re-enter and subsequently resubmit the password. Ideally there should be use of

CFCOOKIE that will prevent the user from retrying the password, however time constraints prevented

his. The CFELSE sets the output if the condition (or password) is correct and outputs the subsequent

etails to the user.

ig 5.6 The error screen from the initial CFIF

Page 34


Fig 5.7 The successful login The next stage is the actual logging of a job, done by clicking the “log your overtime” hyperlink which

dynamically passes the ID of the engineer into the form to insert the record.

Fig 5.8 (Appendix C) demonstrates the code that is used in the form for inserting an overtime log into the

system. The query called “listtype” is used in a drop down to ensure that only types specified by the

system are used, thus ensuring integrity and furthermore allowing types of overtime job to be grouped in

the system as a possible addition to the system. Fig 5.9 (Appendix C) shows what is subsequently

displayed on screen, the form that user sees. The form ultimately ends up at the input page (pending

validation see section 5.3.2.2). Fig 5.12 (Appendix C) demonstrates the code that is used to input the new

record into the system. The code is very similar to the cold fusion query (CFQUERY) with the opening

tag being “CFINSERT”. Difference with this tag is that it has no closing tag and has the destination table

that this schema is going to, shown in “tablename=overtimelog”.

5.2.3.2 Form validation techniques

The form has also had validation code within the receiving page that prevents users from missing

mandatory fields. This has been achieved though implementing cold fusion checking. Fig 5.10

(Appendix C) demonstrates the code used that protects the mandatory fields. By setting the initial status

of a field as “true” and using “if field =0 then false” it prevents the user from progressing with the form.

The browser displays this code as shown in fig 5.11 (Appendix C). Note that the field that has been missed

out is referenced at the top of the page so the user sees what they missed out on the initial form. This

technique is used extensively throughout the site, wherever there is an appropriate form.

5.2.4 To enable the managers to be able to see the overtime for their own team 'holistically'

Page 35


This second requirement is implemented within the management area of the system. Once a manager is

logged in to their personal account (similar to that of 5.2.3.1) they can go to a search page. The system

gives the manager’s not only the ability to search by a range but by a specific date also (section 3.1.3).

Note the two forms going to separate pages Fig 5.13.

Fig 5.13 Manager Date Range Select

In putting an appropriate date range into the range ‘selector’ pulls up all the jobs for everyone in that team

across that range of jobs, provided they have been entered! The two dates get sent to the output page. Fig

5.14 (Appendix C) demonstrates the code that sorts the date range. The initial input page (Fig 5.13)

passes its manager ID and this is used to only pull out engineers for this manager. This is seen with the

inclusion of “Engineer.mgrID” in the select and “WHERE engineer.mgrId = #form.mgrID#”. There is

also need to establish a join between the overtime log and the engineer table, as the results require only

engineers belonging to the given manager (ID). The condition of extracting the data between dates used

resolved through the function “BETWEEN #createODBCdate(form.dateOfJob)#.. etc”. This function

returns, in this case, from ‘from’ date (taken from Fig 5.13) as a comparative date thus setting the first part

of the condition for searching. Fig 5.15 (Appendix C) shows the results as they are displayed in the

browser.

This functionality was harnessed in resolving the functional requirement for showing the totals of a given

range. Fig 5.16 demonstrates how similar the input form is, the only difference from a range select is that

an engineer is selected from a drop down, thus bringing up totals for that engineer. Only engineers

belonging to the manager is displayed this is done through joining the drop down query with a condition

of the current manager ID.

Page 36


Fig 5.16 Searching for sum totals over a given range.

The results of this page differ slightly as they have the inclusion of a total, and they are engineer specific,

i.e. it does not pull put all results for all of the team. It proved too difficult to have multiple ‘dynamic

sums’ for separate engineers on one results page. The resulting query code is shown in Fig 5.18 and the

displayed results in the browser are shown in Fig 5.17 (Appendix C).

Fig

5.18 The Cold Fusion for totalling the hours of a given engineer over a given range

<cfquery name="totaler" SELECT SUM (hours) AS Total FROM overtimeLog WHERE engID=#form.engID#

AND dateOfjob BETWEEN #createODBCdate(dateformat(form.dateOfJob,"dd/mm/yy"))# AND #createODBCdate(dateformat(form.lala,"dd/mm/yy"))#

</cfquery>

5.2.5 That the system is maintained over the web

This functionality is achieved through a variety of pages that have direct access to the database to change

the data. For example, the Administrators home page allows them to change the types of overtime

available, add new managers, delete, edit etc (See Appendix D).

Fig 5.19 (Appendix C) demonstrates one of the ways that ‘web maintainability’ is achieved. The

Administrator can change anything to do with a particular engineer or his logged jobs. Fig 5.20

(Appendix C) also demonstrates where the Administrators have the ability to change the types of

‘Overtime Type’.

5.3 Implementation of Usable aspects of design

Appendix E is a summary of usable design (Section 4.4) outlining the usable aspects for the system. The

system meets these requirements over several areas.

Page 37


A

B

C

Fig 5.21 A Manager login page demonstrating usable design

A – “User areas are clearly defined”. With this example one can see how a user can identify with their

personal area, both with image at the top and a dynamic output of the user’s name below.

B – “Colour scheme that offers clarity and is in line with organisation” The CSS is using different

combinations of corporate colours. As most of the users in this area are male there is use of blue. The

Functions are separated by a line and are displayed in a shade of grey. The font used is Arial and is very

easy to read in most sizes and colours.

C – “General principles of usable design applied”. The functions available to this user are clearly

differentiated both in screen position and by incorporating the use of cogs. The functions have cogs next

to their description, the user should use memorability from the cogs on the main navigation to understand

that they are ‘clickable’.

Page 38


D

E

Fig 5.22 An error screen after an incorrect data entry

D, E & F – “General principles of usable design applied”. This conforms to giving the user feedback and

maintaining the error reduction.

F

Fig 5.23 A warning screen for the administrators before deleting a Manager

G

H

Fig 5.24 A Confirmation that a record has been updated

G – “Allowing the user closure”. Fig 5.24 clearly demonstrates using text that an update has occurred.

Page 39


E – “General principles of usable design applied” The user maintains control of the system though not

having to use the browsers back button. In doing that data from a previous page could be entered again,

for example.

5.4 Additional functionality

To increase the efficiency of the system certain functions are added in. A perceived problem in

developing the system was helping the Administrators to extract information on a given Engineer. This

was resolved though the introduction of two types of search. One search was to locate an engineer by

manager the other was to do a free text search bringing up close matches.

F

Fig5.25A Search ‘by name’ and subsequent results page

With a high turnover of Administrators the page needs to be as practical as possible. From this and the

other manager search results page, the Administrator can alter information to do with a particular

engineer.

F – Demonstrates the colour separated functionality of the results page. Using the matrix the user can

work across to add or change OT as well as alter the personal details for this engineer.

Page 40


6. Testing _____________________________________________________________ Testing is necessary to ensure software functionality and correctness along with usability. If the system

does not posses these qualities then it could fail in use which would mean the objectives of the project

would not have been met.

6.1 Functionality Testing

As previously stated (Section 4.5) testing will be conducted in two phases. The first phase is to test the

system functionality and error tolerance. The system has been tested once a section was implemented.

This was to ensure that nothing was overlooked and errors were patched as soon as they occurred.

The test data used was designed with specific intent to cause the system to fail. An example of this would

be trying out a date format that would have violated system conditions within form validation. Appendix F

has the functional test conducted, subsequent results and test data used. Errors were noted within the test

and the system was altered accordingly where an error occurred.

6.2 End User Testing

The end user testing took the form of semi-structured interviews and scenario tests. There was no way to

revise the testing as it could only be done over a period of two days at the Reuters offices in London. The

scenarios, scenario results, interview questions and interview responses are all found in Appendix F.

There were three sets of questions for each type of user and three sets of scenarios. The tests had elements

of both functional tests and usable questions, this was to ensure that the functional testing that was self

conducted was sufficient. It was also a beneficial way of testing that the system functionality was

working on the new server.

6.2.1 Feedback

The semi-structured interviews were effective in gaining valuable information on the effectiveness of the

system. There was a range of responses raised across the range of user types and abilities. The scenario

testing also highlighted some minor inconsistencies that were noted. The end user testing also highlighted

some aspects of functionality that were worth considering

6.2.2 Major Issues

Some of the major issues that arose from the user testing:

• Additional functionality and usability

Page 41


• Usable design inconsistencies and additions

• System ownership

• Functional errors in dates

• Server problems

• Selective responsiveness under questioning

• Issues of the system absorbing work capacity of administrators

• Positive comments

6.2.2.1 Additional Functionality and Usability

After the system was installed it became apparent that that the functionality and usability were

encouraging the users into thinking of ways that system could be further enhanced. The biggest

enhancement was in adding report functionality.

Creating a new super user section, specifically designed for senior management. This means slightly

changing the existing search filters to pull out all data for all teams, as opposed to each manager going in

for his own team. This was spurned on though a combination of the current usable and functional aspects

of design of the system.

It was also suggested that graphical representation of the data would be beneficial for senior management.

This would mean applying the CFGRAPH function that exists in Cold Fusion version 5. However in

terms of this project, the set requirements were met and it was agreed that these ideas were additional

modifications to be made at a later stage of Reuters adopting the system.

There was also a concern that cut off dates were not included in the system. This was not a consideration

in the original design. The cut off dates determine which period the overtime pay is attributed to. There is

12 cut off dates in a year but they vary from year to year.

There was also concern that in auditing of the system evidence of changes would not be apparent. This is

overcome by applying an extra field in editing pages for managers and administrators where they can put

their name and date associated with the change.

Managers also would have liked the system to have dynamic forms based on the type of overtime. It is

feasible to a certain extent but this is way out of the scope of the project. It is noted as a future

amendment.

6.2.2.2 Usable design inconsistencies and additions

Page 42


The most recurring problem came with the assumption that users would understand how to get deeper into

the system. The concept that was assumed was by having an engineer’s name as a hyperlink or by having

a job number as a link to further job or engineer information. This was chosen against having “click here

for more detail” for example. Even though this principal was applied and successfully used elsewhere, the

intuition of the users did not occur. It was mentioned that to have a symbol or text saying click here would

have been much more effective at guiding the users.

There was also some minor inconsistencies and issues on pages including:

• Back buttons omitted on some pages

• Changes to data in the administration section were not outputted

• General unhappiness about the layout on certain pages, for example where the user had options

that were colour coded, as seen in editing options for engineers in the admin section, prompted a

much more pleasing reaction

• Some admin users have their screen quite high up despite this not being in line with health and

safety, it meant they were concentrating on the centre of the screen as opposed to closer to the top.

This meant the first thing admin users were looking at wasn’t necessarily the most important. This

was a very trivial issue raised and it was more obvious when data being retrieved was minimal,

hence not making the page appear proportional.

• Warnings should be in red

• The deleting functionality appears to be a bit random

• The logo could have a pound sign in it as well. The logo is quite ‘boyish’ and is also relevant to

money as well, hence use of the pound sign.

• The scenario testing found only two problems. It was a bit vague as to how a user would uncover

their full archive. The link for doing this is underneath their last 10 job list. However both

administrators that did the scenario could not find this without being prompted. This is not

regarded as a major problem as this is only a very trivial function and would have been discovered

naturally given more time.

6.2.2.3 System ownership

There was a small issue that was raised by one engineer user; he felt engineer users did not have enough

ownership. This particular engineer would like to have had more capabilities available to them, for

example the ability to be able to edit their own overtime. This has been modelled on the business process

so there is no justification for this functionality to be considered for engineer users. “The system would be

accepted much more” it was noted, “If engineers had the ability to control their own accounts”. Managers

Page 43


need to be able to sign off overtime that has gone into the system to ensure that there is no malpractice.

Managers would not allow this loop hole to be exploited.

6.2.2.4 Functional errors in dates

A problem not encountered within my functional testing was an error with the dates. The complications

with the format of Access date fields and converting it back in cold fusion proved more complex then

anticipated. This was resolved by removing the format mask of ‘short date’ in the database, changing it to

text and using a CFSET function to determine the output on the site. Once this was resolved dates were

being registered correctly.

6.2.2.5 Server problems

Initially when the system was brought across from CD to the server space all files were locked as read

only. This was only realised after dissecting the system within Dreamweaver. This problem was making

it impossible for data to be written to the database as it requires a read / write status for this. Once the

database was unlocked data was writing to it. The next problem that was encountered was that access to

the database, as in actually opening the structure as opposed to accessing the database through a website.

When the database was attempted to be accessed an error saying “access prohibited – sharing violation”

occurred. The database needed specific settings applied to it by server software to prevent the virtual

connection from being cashed. It was quickly resolved by the server team.

6.2.2.6 Selective responsiveness under questioning

The final noted problem was that under interviewing certain users appeared to give selective responses. It

was to be expected (Preece, 1994) that some users may find somebody monitoring them is intrusive and

their behaviour and performance will alter as a result. In my opinion this was also the case as time

pressures of getting the interviews out of the way meant quicker answers were obtained. However, this

was only a small point that was noted. The scenario testing proved some of the effectiveness that may

have been avoided within questioning

6.2.2.7 Positive comments

• There was considerable praise for the system once it went live on the Intranet. General aspects of

the system that had a positive reaction were:

• The colour scheme

• The functionality, some of which was not known by some users

• The speed and ease at which it migrated

Page 44


• The logo and general graphics (although some users would have liked to have seen rotating cogs!)

• The speed of the processing

• The text effects through the CSS

• Simplicity and intuitive nature of the functionality

6.3 Rollout

After the system was installed, tested and demonstrated a final decision on how the system was to be

rolled out was decided by the management. As the process is totally different to the existing system, it

was decided that a trial period of 2 months will be used. This ‘pilot period’ will be used to satisfy senior

management that the new system will offer prominent cost benefits.

Page 45


7. Evaluation _____________________________________________________________ The final stated objective of the project (Section 1.1.4) is to “Evaluate the effectiveness of the system in

terms of functionality, usability and measure how well it met the requirements.”

This section will evaluate the extent that the developed system meets the objectives set at the beginning of

the project, and discuss possible improvements which could be made to the system which were outside the

scope of this project. When evaluating a system, it can be thought of in monetary terms (benefits and

cost) or in terms or usefulness and success (as opposed to failure) (Angell et al, 1994). This means of

evaluation is applicable to this system in terms of the system being more ‘useful’ then the previous

business process. The managers can effectively organise the overtime information without great effort

and the engineers can log their overtime at a time that suits them. It also brings cost benefits in that

capacity of workload of all users is increased, as this system is considered a labour saving device.

7.1 Criteria for evaluating the system

Evaluating a system means focusing on its organisational impact rather than just physical performance. It

needs to be related to the requirements of the individual organisation and its users (Angell et al, 1994).

Therefore the first means of evaluation should asses the extent to which the user requirements were met.

Secondly the system should also be evaluated on how effective the solutions to the requirements are.

There are many ways to quantify the degree of success to which the developed solution met the

requirements. The most suitable for this system are:

Effectiveness – Evaluating the extent of how effective the new system performs particularly in

contrast to the previous process.

User satisfaction – Referring to the user acceptance of the system

7.1.1 User Requirements Evaluation

“To enable engineers to add their overtime”

The system meets this requirement and surpasses it. Not only can the engineers log their overtime but

once in the system it can be deleted or altered by an authorised member of staff. The method for logging

is fully validated to maintain the integrity of the data. The process is fully personalised as well, with each

user having an ‘account’ home page thus simplifying the process.

“To enable the managers to be able to see the overtime for their own team holistically”

Page 46


The managers can view any member of their team if they have registered with the system and assigned the

correct manager to themselves. Once any job is logged the manager has a complete holistic view of his

team’s logged records. Again, with the use of dynamic pages, each manager has an ‘account’ page to stop

information bombardment in that other team’s records are kept separate.

“That total hours be calculated in a given range for the managers to view.”

This functionality was implemented successfully. The delivered solution allows a total to be displayed by

individual over a set range. The engineers that are available to the manager are again filtered so only their

own team are listed for total hour calculation.

“That the system is maintained over the web (i.e. you can alter it without bothering others)”

(Also as a usable requirement “Manual editing facility”)

The administration section was created to cater for a large proportion of this functionality. There needed

to be a super user that could determine any variable. The fact that the passwords are created by the

individual over the web ensures that the server staff are not as harassed in permissioning users to certain

areas. Also with a high turnover of administrators in the group a generic password system catered for

changing admin users. If an Engineer wanted to change their password they can do that off their account

page or if they can’t get to a machine an administrator can do it for them. This highlights the flexibility

that the system has brought to the process.

“Easy to use”

There was a considerable investment of time in developing a usable interface. Taking into consideration

navigation, colours, clarity of text, revealing the structure through icons, confirming when updates have

occurred, validation and personalised accounts all made the system truly simple to use. This was

confirmed in the user testing as the general consensus regarding usage of the system was that of

“Simplicity and intuitive nature of the functionality”

“Easy to view / Print off”

The regard for this requirement was seen on the evolution of the interface. The background changed from

black to white, thus allowing a much clearer screen for printing (not to mention savings in toner!) On

testing the system there wasn’t any apparent problems with users unable to read the text. This is s sign that

this requirement was met, and to some extent exceeded.

7.1.2 Applying the quantifiable criteria

Page 47


This could only be carried out after the system was implemented and cannot be truly measured as there

was only a limited period that users could be assessed on how effective the system was and how satisfied

they were with it. The end user testing (Section 6.2) provided insight into the extent to which the system

was both effective and the level of satisfaction gained.

The system was effective in that it met the initial requirements of the users and from a demonstration the

managers quickly realised the extent to which the old business process could be made much more

effective. The possibilities for mining the data over a long period and the reporting capabilities of the

system were more then adequate. However, over the development period and once the managers realised

the potential of the new system, it was noted how much more effective the system could become. It was

highlighted (Section 6.2.2.1) that developments that can be made to the system, bringing it in line with

current demands.

Overall acceptance amongst the users for the system was obtained. Positive comments were outlined

(Section 6.2.2.7) after installation of the system. The benefits were immediately apparent to the users and

they were keen to see it as a fully applied application. In testimony to the system there is confirmation of

Reuters’ acceptance in Appendix G.

7.2 Criteria for evaluating the project as a whole - Meeting the project objectives

“To clarify and finalise requirements”

The requirements were confirmed and prioritised (Section 3).

“To select an appropriate methodology”

A methodological approach to the project as a whole was applied. Principles of a RAD methodology were

applied in the speed of development but a structured approach as a whole was used in gathering

requirements and evaluation for example. The project therefore incorporated elements of two different

types of methodology.

“Design website structure, appearance and functionality”

Adequate resource was invested in design (Section 4).

“Successful implementation of the system onto the Reuters Intranet”

Success can be defined as the successful migration procedure, bar the server problems (Section 6.2.2.5).

Success can also be defined as the level of user acceptance being appropriate in that the system will be

used and the users liked using it.

Page 48


7.3 Future enhancements

Modifications were outlined (Section 6.2.2.1) that could be made to the system to ensure its continued

acceptance. The main development would be to have a senior management section. Based on the

functionality of the administration section, a senior manager would have access to any engineer in the

system. With the use of on line graph generation (CFGRAPH function) the senior management can have

report generation, particularly beneficial in cost reduction exercises. This section would also require

searching by date and overtime type. This is easily achieved by modifying the existing search functions.

Another further development would be to implement the cut off dates into the process. By grouping

together dates by specific cut off periods it would ensure that the system would appeal to the HR

department and their payroll data.

7.4 Main Advantages over the old system

• As the system is web based the users can access the site over the corporate Intranet on site via dial

up. This saves the engineer the time and effort of having to come back to the office to hand the

relevant paper overtime forms in.

• The data is also archived and can be mined by the managers to check up on records

• The process has become much more simplified.

7.5 Evaluation Summary

Overall the system met and exceeded all of its requirements. It is a useful and adaptable system that has

resolved a genuine business problem. The future success of the system will be determined by the opinions

of senior management and the ability for the system to cater for their additional requests.

Page 49


Bibliography:

___________________________________________________________

• Angell, I, & Smithson, S, (1994), Information Systems Management, Macmillan Press

• Avgerou, C, & Cornford, T, (1998), Developing Information Systems, Concepts Issues and

Practice, Macmillan Press Ltd

• Avison, D E, & Fitzgerald, G, (1995), 2nd Edition, Information Systems Development:

Methodologies, Techniques and Tools, McGraw Hill, pp. 261-406

• Avison, D E, & Shah, H, (1997), The Information Systems Development Life Cycle: A First

Course in Information Systems, McGraw Hill, pp. 259-263

• Booch, G, (1994), 2nd Edition, Object orientated analysis and design with applications, Addison

Wesley

• Braun, K, Gadney, M, Haughey, M, Roselli, A, Synstelien, D, Walter, T, Wertheimer, D,

(2002), Usability: The site speaks for itself, Glasshouse Birmingham UK, pp. 12 - 222

• Clemmensen, T, & Holck, J, (2001), What makes web development different?, Copenhagen

Business School, Dept. of Informatics, URL: http://www.cbs.dk/staff/holck/iris.pdf

[April 3 2003]

• Danesh, A, & Motlagh, K A, (2000), Mastering Cold Fusion® 4.5, SYBEX Inc, Alameda CA

• D’Hertefelt, S, (1999), Interaction Architect, Observation methods and tips for usability testing,

URL:

• http://www.Interactionarchitect.com/knowledge/article19991212shd.htm

[Feb 3 2003]

• Hicks, R. & Essinger, J, (1997), Making Computers More Human – Designing for Human

Computer Interaction

• Johnson, O, (2000), IN21 Lecture Notes, Object orientated analysis and design, Leeds University

Computer School.

• Jordan, P W, (1998), Introduction to Usability

• Mumford, E, (1995), Effective Systems Design and Requirements Analysis – The ETHICS

Approach, Macmillan.

• Neilson, J, (2000), Designing Web Usability, New Riders Publishing, USA, pp. 203-264

• Neilson, J, Mack, R B, Bergendorff, K H, & Grischkowsky, N L, (1986), Integrated software

usage in the professional work environment: evidence from questionnaires and interviews. In

Page 50

http://www.cbs.dk/staff/holck/iris.pdf

http://www.interactionarchitect.com/knowledge/article19991212shd.htm


Human Factors in Computer Systems, CHI’86 Conference proceedings, New York ACM Press,

pp. 162-7.

• Preece, J, Rogers, Y, Sharp, H, Benyon, D, Holland, S, & Carey, T, (1994), Human Computer

Interaction, Addison Wesley, Harrow England

• Reuters, Corporate Information: About Us, URL: http://about.reuters.com/aboutus/overview/

[March 14 2003]

• Stapleton, J, (1997), DSDM Dynamic Systems Development Method, Addison Wesley, pp.28

• Usability.Gov (National Cancer Institute). (2002), Methods for designing usable web sites –

conducting and using usability tests, URL: http://usability.gov/methods/usability_testing.html

[Feb 3 2003]

• Whitten, J L, Bentley, L D, & Barlow, V M, (1994), Systems Analysis & Design Methods,

Irwin, Boston, Ma.

• Yourdon, H, (1998), 2nd Edition, Managing the systems life cycle, Yourdon Press, pp. p2-7

Page 51

http://about.reuters.com/aboutus/overview/

http://usability.gov/methods/usability_testing.html


Appendix A

_____________________________________________________________

The project was highly successful from my perspective. The final product was delivered on time and had

elements of usable design and additional functionality, often overlooked in the development of Reuters

Intranet systems. The use of a traditional life cycle methodology as a project management tool offered

stability and logic in the way that the project was delivered. It complemented the elements of RAD and

DSDM that were incorporated to ensure the actual build was kept within time constraints. Although after

completing the project I found specific web methodologies that I overlooked in my research. This raises

the question of how applicable a RAD methodology is in developing a web based information system,

particularly if other methodologies are web system specific.

The initial project plan offered a solid foundation for development; however it did not reflect the actual

final plan. There was need to refine the Gantt chart around January as the reality of the project was

proving different to the planned schedule. A revised Gantt chart is included in Appendix B with the

revised schedule. The first alteration was that I did not allocate time correctly around December, the

Christmas period left little time for project work. This subsequently put feasibility and requirements off

track by a week. The other major change was that I failed to appreciate the fact that, in some cases, as

soon as I had an idea I developed it as opposed to designing it properly. Hence the evolution of the

interface, at first it was black and not very simple to read, then I went back to the requirements and usable

literature and redeveloped. The implementation as a whole took a mere 3 weeks plus an extra week for

refinements. The functional testing became ongoing as the system developed as opposed to being at the

end of the development. The evaluation from the end users had to be done over one week. The initial

plan had catered for me spending some time interviewing and monitoring users. However this could only

be done over 2 days in London due to users work commitments, and were therefore unable to be revised.

Given more time I would like to evaluate the system after its pilot period and make any slight

modifications the users require. I also feel that, given more time, I could have allotted more time to work

with the users throughout the project. Distance and university commitments prevented this. I feel that if

these were not an issue then the rapid nature of the development could have given the additional

functionality not perceived at the start of the project.

I felt that the manner in which I conducted myself whilst dealing with Reuters CSS was both professional

and effective. Despite limited interaction a final product was built, installed and tested to deadline. The

testimony to this is reflected in the correspondence I received afterwards (Appendix G).

Page 52


I have learnt a lot through developing this system for third party. There are a number of relevant

suggestions for students undertaking a similar project in the future:

1. Ensure that there is adequate time allocated to background research, particularly usability. There

are a number of factors that I feel I would have overlooked or taken for granted in developing my

interface.

2. Involve your users as much as you can. Right at the start of the project I stated that Whitten’s

principles of system developed stated involving the users. This is a key to developing a truly

effective system that will be accepted by your users. Distance and time may prevent this, but one

should strive to forge a high degree of involvement.

3. Be prepared to change your plans or allow yourself ‘buffers’. In my case I originally planned to

have overlap between my iterations. This is vital as it allows slack for you to fix problems that

may occur and or unforeseen at the start of a project.

4. Try to do a project that you feel you will get something out of or enjoy. I have found this project

incredibly satisfying. To see your system being used by others to do their work more effectively

is a great feeling. The feeling is amplified when the users enjoy using the system.

Page 53


Appendix B

MayArea 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20 27 03 10 17 24 03 10 17 24 31 07 14 21 28 020. Initial Requirements0.10.20.3

1. Feasibility1.11.21.31.41.5

2.Requirements Analysis2.12.2

3. Design3.13.23.33.4

4. Implementation4.14.24.34.4

5. Testing5.15.25.3

6. Evaluation6.1

6. Administration7.1

Project Gantt ChartMarch AprilOctober November December January February

Page 54


Task Product Duration in Weeks Immediate Predecessor

0.1 Form project title 2

0.2 Background ResarchNotes on areas researched 8 0.1

0.3 Mid Project reportSubmit everything so far 1 0.2

1.1 Review current system 6 0.11.2 Examine system specifications Flow diagrams 5 1.11.3 Highlight problems with current system 6 1.2/1.21.4 Hardware Constraints 3 1.1

1.5 Software Constraints 3 1.1

2.1 Gather requirements 8 0.12.2 Prioritise requirements 1 2.1

3.1 Database Design

Normalisation and Relationship diagram 5 2.1

3.2 Structure Design System blueprints 2 2.1

3.3 Interface Design 2 2.1/0.23.4 Testing Plan Testing Plan 2 3

4.1 Site Build 7 34.2 Testing 3 3.34.3 Refinement 5 34.4 Crossover 1 4.1

5.1 Final Functionality Testing 2 45.2 End User Testing 2 3.3/45.3 Feedback 1 5.1/5.2

6.1 Evaluation of Project 3 2/3/4/5

7.1 Report Submit 14 1/2/3/4/5/6

4. Implementation

5. Testing

6. Evaluation

7. Administration

0. Initial Project Requirements

1. Feasibility

2. Requirements Analysis

3. Design

Page 55


MayArea 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20 27 03 10 17 24 03 10 17 24 31 07 14 21 28 020. Initial Requirements0.10.20.3

1. Feasibility1.11.21.31.41.5

2.Requirements Analysis2.12.2

3. Design3.13.23.33.4

4. Implementation4.14.24.34.4

5. Testing5.15.25.3

6. Evaluation6.1

6. Administration7.1

Revised Project Gantt ChartMarch AprilOctober November December January February

Page 56


Appendix C

_____________________________________________________________

Engineer fills out overtime

PA Receives form

Updated shared directory

Field Service Managers view

records

Update Now?

Yes

PA Waits until they have the

time

No

Fig 2.1 The current system as a flow chart.

Field Service Managers receive alteration request

PA alters information

PA Waits until they have

permission Yes No Manipulate

file Have

permission

Fig 2.2 What happens if there is a discrepancy over the log.

Page 57


Index.htm

Engineer Access Point

Manager Access Point

Administrator Access Point

Contact Us Help

Fig 4.3 Overall system structure at a high level.

Fig 1.4 Structure for engineers

Engineer Access Point

Register

Select Name from List

Password Check

View Job Details (HISTORY)

Edit Details Log Overtime

Page 58


Administrator Access Point

Password Check

Change Personal Details

Change Site Settings

(e.g. OT Type)

Add Job into system Edit Job Details

Fig 4.4 Structure for administrators

Fig 4.5 Structure for managers

Manager Access Point

Register

Select Name from List

Password Check

View Your Teams Details

Show all those that exceed overtime

limit over set period

Highlight all Details

Implementation screen grabs

Page 59


<cfquery name="details" SELECT * FROM engineer WHERE engID = #url.engID# </cfquery> <cfquery name="listtype" SELECT * FROM type </cfquery> <cfform action="inputovertimedone.cfm" method="post"> <cfselect name="overtimeRef" query="listtype" value="overtimeRef" display="type" required="yes" multiple="no" size="1"> </cfselect> <input type="text" name="ukJobno"> <input type="text" name="hours"> <input type="text" name="dateOfjob" validate> <input type="text" name="clientName"> <textarea name="notes" rows="7" cols="50"></textarea> <input type="submit" value="Upload to system"> <cfoutput> <input type="hidden" value="#url.engId#" name="engID"> </cfoutput> </cfform>

Fig 5.8 Form for inputting overtime

Fig 5.9 Subsequent input form

<cfset Valid=True> <cfset Error="">  <cfif Len(form.ukjobno) is 0> <cfset valid= False> <cfset Error = Error & "You have not put a uk job number in.<br>"> </cfif>  <cfif Len(form.d …..etc etc etc Page 60


Fig 5.10 Validating the input page code

Fig 5.11 Subsequent error message from validation Fig 5.12 Code for inserting the final data into the database.

…… <cfelse> <cfinsert dbtype="dynamic"

connectstring="Driver={Microsoft Access Driver (*.mdb)}; Dbq=#expandpath('..\..\database\overtime.mdb')#;Uid=admin;Pwd=;" tablename="overtimelog">

Fig 5.14 The inner join query that brings all jobs between the date range input.

<cfquery name="joblist" SELECT engineer.engName, engineer.engID, engineer.mgrId, overtimelog.engID, overtimelog.dateOfjob, overtimelog.hours, overtimelog.clientname, overtimelog.ukJobno, overtimelog.refNo FROM engineer inner join overtimelog ON engineer.engID = overtimelog.engID WHERE engineer.mgrId = #form.mgrID# AND dateOfjob

BETWEEN #createODBCdate(form.dateOfJob)# AND #createODBCdate(form.lala)#

ORDER BY overtimelog.dateOfjob desc </cfquery>

Page 61


Fig 5.15 Results of the search.

Fig 5.17 The results of search with total at top for given engineer.

Fig 5.19 Example of web maintenance 1- Changing various engineer records in admin section

Page 62


Fig 5.20 Example of web maintenance 2- Changing types of OT in admin section

Page 63


Appendix D _____________________________________________________________

Tables of functionality – Who can do what? Table1: Engineer Records Add Engineer Delete Engineer Edit Engineer Engineer X X Manager X Administrator X X X Table 2: Manager Records Add Manager Delete Manager Edit Manager Engineer Manager Administrator X X X Table 3: Overtime Record (Log) Add Record Delete Record Edit Record Engineer X Manager X X Administrator X X X Table 4: Change ‘Type of overtime’ Change type Engineer Manager Administrator X Table 5: Search Archives By Individual By Team By All Users Engineer X(View) Manager X X Administrator X X X

Page 64


Appendix E

_____________________________________________________________

Usability Checklist

A Summary of the usable aspects of design from section 4.4

4.4.1 Interface Consideration 1: User areas are clearly defined

• Visual Clarity (of user areas)

4.4.2 Interface Consideration 2: Colour scheme that offers clarity and is in line with organisation

• Visual clarity (clear text size / font / colour)

• Psychology of Colour

4.4.3 Interface Consideration 3: General principles of usable design applied

• Consistency (text & functionality)

• Feedback

• Error prevention and recovery

• User maintains control

• Efficiency, memorability and error reduction

4.4.4 Interface Consideration 4: Structure and Support

• The revealed structure is minimal

• User guidance and support

4.4.5 Interface Consideration 5: Minimising the revealed structure

• Minimised Revealed structure. (as 4.4.4)

4.4.6 Interface Consideration 6: Allowing the user closure

• Psychological Closure

Page 65


Appendix F _____________________________________________________________

Functional Test Plan This series of tests is aimed at testing the accuracy of the code, the navigation and that the appropriate changes are being made to the database. The system will be tested in the case each user type and a general site test from the top end General Site Check 1. Main Menu a) The site loads when URL is typed in b) The three separate frames load up c) The roll over CSS effects work on all of the main links. d) The relevant navigation aspect brings up the according main frame e.g. admin brings up admin e) Help page loads f) Contact us page loads 2. Engineer Section 2.1 Registration Page a) The page loads b) List of managers in the system on the drop down c) The information is accepted into the system d) Subsequent incorrect password does not work e) Subsequent password gets you into the system 2.2 Personal Home Page a) The page loads b) Correct name displayed at the top c) The CSS styles all work and like to correct page 2.2.1 Edit Personal Details Page a) The page loads b) The correct data is displayed in the original section c) The drop down list contains all of the managers d) The form takes you to an input page that directs you back. e) The changes are apparent 2.2.2 Log Your Overtime a) The page loads b) Insert incorrect format in the ‘date’ and ‘hours’ box should error c) Insert the correct format of data and accepted into system d) The form takes you to an input page that directs you back. e) The logged data is apparent and correct

f) Miss out the date in an entry of another job – an error screen should tell you mistake g) Resubmit but miss out the hours of the job – an error screen should tell you mistake h) Resubmit but miss out the client name – an error screen should tell you mistake

i) Repeat steps until 11 Jobs have been entered with different test in different date orders. 2.2.3 View Your Overtime a) The page loads b) The data from the previous test is displayed, up to the last 10 c) When clicking on the job it will bring up more detail d) This information is correct e) Get back to the main list of your last 10 jobs f) When clicking on all history the extra job is displayed 3. Manager Section 3.1 Registration Page a) The page loads

Page 66


b) List of managers in the system on the drop down c) The information is accepted into the system d) Subsequent incorrect password does not work e) Subsequent password gets you into the system 3.2 Personal Home Page a) The page loads b) Correct name displayed at the top c) The CSS styles all work and like to correct page 3.2.1 View Your Team’s Accounts a) The page loads b) The correct list of your engineers is displayed c) The link for that engineer takes you to his subsequent list d) The data shows up to the last 10 jobs e) When clicking on the job it will bring up more detail f) This information is correct g) Get back to the main list of last 10 jobs 3.2.2 Log Overtime For Your Team a) The page loads b) Insert incorrect format in the ‘date’ and ‘hours’ box should error c) Insert the correct format of data and accepted into system d) The form takes you to an input page that directs you back. e) The logged data is apparent and correct

f) Miss out the date in an entry of another job – an error screen should tell you mistake g) Resubmit but miss out the hours of the job – an error screen should tell you mistake h) Resubmit but miss out the client name – an error screen should tell you mistake

3.2.3 Search Your Team’s Archives By Set Parameters a) The page loads 3.2.3.1 Search By Specific Date a) Type in incorrect date that is not European format, Error screen should appear

b) Entered correct date format and it is accepted by form c) When entering a range of dates from previous test, they are displayed. d) When clicking on the job it will bring up more detail

e) This information is correct 3.2.3.2 Search By Specific Date Range a) Type in incorrect ‘From’ date that is not European format, Error screen should appear b) Type in incorrect ‘To’ date that is not European format, Error screen should appear c) Entered correct date format and it is accepted by form d) When entering a range of dates from 3.2.2 test, they are displayed. e) When clicking on the job it will bring up more detail

f) This information is correct b) When clicking back, it goes back to your account page 3.2.4 Amend Your Team’s Overtime a) The page loads

b) The correct list of engineers comes up on the screen c) When clicking on the name it brings up a list of overtime jobs for that engineer. d) When clicking on a job it will bring editable list with warning of original data e) Insert the correct format of data and accepted into system

d) The form takes you to an input page that directs you back. e) The logged data is apparent and correct

f) Miss out the date in an edit of another job – an error screen should tell you mistake g) Resubmit but miss out the hours of the job – an error screen should tell you mistake h) Resubmit but miss out the client name – an error screen should tell you mistake i) The final page should direct you to original job list of mgr and engineer 3.2.5 Check Overtime Totals For A Set Range a) The page loads b) The correct list of engineers for your team comes up in the drop down

Page 67


c) Incorrect entry of non-European date format brings up an error screen d)When entering a range of dates from 3.2.2 test, they are displayed. e) The sum of the jobs is correct, check. f) The date results are in order g) When clicking on the job it will bring up more detail

h) This information is correct 4. Administration Section 4.1 Login Page a) The page loads b) Subsequent incorrect password does not work c) The correct password is accepted d) Subsequent password gets you into the system

4.2 Personal Home Page a) The page loads b) Correct name displayed at the top c) The CSS styles all work and like to correct page 4.2.2 Search For Engineer By Manager a) The page loads b) Full list of all managers appears c) The CSS effect works on all managers’ names d) The correct list of engineers appears for that manager when clicked 4.2.2.1 View Engineer’s Archive a) The page loads b) There are at most 10 jobs on the list c) The full jobs list brings about the full archive for that person d) Clicking onto a job brings up relevant detail e) All back buttons work 4.2.2.2 Edit Engineers Archive

a) The page loads b) There are at most 10 jobs on the list

c) When clicking on a job it will bring editable list with warning of original data d) Insert the correct format of data and accepted into system

e) The form takes you to an input page that directs you back. f) The logged data is apparent and correct

g) Miss out the date in an edit of another job – an error screen should tell you mistake h) Resubmit but miss out the hours of the job – an error screen should tell you mistake i) Resubmit but miss out the client name – an error screen should tell you mistake j) The final page should direct you engineer page 4.2.2.3 Edit Engineers Details

a) The page loads b) The current details are displayed c) The changes are accepted d) The user is taken back to the main admin page 4.2.3 Search For Engineer By Engineer Name a) The page loads b) A name is inserted and near matches are found 4.2.3.1 View Engineer’s Archive a) As above 4.2.3.2 Edit Engineers Archive a) As above 4.2.3.3 Edit Engineers Details a) As above 4.2.4 Editing Overtime Types a) The page loads

Page 68


b) CSS effects working 4.2.4.1 Add Overtime Type a) Type in ‘test’ type and submits without error b) User prompted back to main menu c) Update complete checked 4.2.4.2 Edit Overtime Type a) Select ‘test’ type from 4.2.4.1a and ensure that this activates edit b) Edited test submits c) User prompted back to main menu d) Update complete checked 4.2.4.3 Delete Overtime Type a) Select edited ‘test’ type from 4.2.4.2a and ensure that delete is for this b) Delete taken to a second phase ok c) Delete activated ok d) The ‘test’ is removed from the system 4.2.5 Edit Manager Details a) The page loads b) The current details are displayed c) The changes are accepted d) The user is taken back to the main admin page 4.2.6 Add New Manager a) The page loads b) The form is submitted correctly with ‘test’ c) The user can get back to the menu d) The addition is recognised 4.2.7 Delete Manager a) Select edited ‘test’ mgr from 4.2.6a and ensure that delete is for this b) Delete taken to a second phase ok c) Delete activated ok d) The ‘test’ is removed from the system 4.2.8 Add New Engineer a) See 2.1 add ‘test’ data

4.2.9 Delete Engineer a) Select edited ‘test’ engineer from 4.2.8a and ensure that delete is for this b) Delete taken to a second phase ok c) Delete activated ok d) The ‘test’ is removed from the system 4.2.10 Change Admin Password a) The page loads ok b) Form submits ok c) Test changes in place on login page

Page 69


Functional Test Sheet: Results Test No. Title/Comment/Success 1 Main Menu a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes 2 Engineer Section 2.1 Registration Page a) Yes b) Yes c) Yes d) Yes e) Yes 2.2 Personal Home Page a) Yes b) Yes c) Yes 2.2.1 Edit Personal Details a) Yes b) Yes c) Yes d) Yes e) Yes 2.2.2 Log Your Overtime a) Yes - but got query error need fix. Now fixed. Re-tested. Works Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes i) Yes 2.2.3 View Your Overtime a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes 3 Manager Section 3.1 Registration Page a) Yes b) Yes

Page 70


c) Yes d) Yes e) Yes 3.2 Personal Home Page a) Yes b) Yes c) Yes 3.2.1 View your teams accounts a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes 3.2.2 Log overtime for your team a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes 3.2.3 Search your team’s archives by set parameters a) Yes b) Yes 3.2.3.1 Search by specific date a) Yes b) Yes c) Yes d) Yes e) Yes 3.2.3.2 Search by specific date range a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes 3.2.4 Amend your team’s overtime a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes

Page 71


i) Yes 3.2.5 Check overtime totals for a set range a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes 4. Administration Section 4.1 Login page a) Yes b) Yes c) Yes d) Yes 4.2 Personal home page a) Yes b) Yes c) Yes 4.2.2 Search for engineer by manager a) Yes b) c) Yes d) Yes 4.2.2.1 View engineer’s archive a) Yes b) Yes c) Yes d) Yes e) Yes 4.2.2.2 Edit engineer’s archive a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes i) Yes j) Yes 4.2.2.3 Edit engineer’s details a) Yes b) Yes c) Yes d) Yes 4.2.3 Search for engineer by engineer name a) Yes

Yes

Page 72


b) Yes 4.2.3.1 View engineer’s archive a) Yes b) Yes c) Yes d) Yes e) Yes 4.2.3.2 Edit engineer’s archive a) Yes b) Yes c) Yes d) Yes e) Yes f) Yes g) Yes h) Yes i) Yes j) Yes 4.2.3.3 Edit engineer’s details a) Yes b) Yes c) Yes d) Yes 4.2.4 Editing overtime types a) Yes b) Yes 4.2.4.1 Add overtime type a) Yes b) Yes c) Yes 4.2.4.2 Edit overtime type a) Yes b) Yes c) Yes d) Yes 4.2.4.3 Delete overtime type a) Yes b) Yes c) Yes d) Yes 4.2.5 Edit Manager Details a) Yes b) Yes c) Yes d) Yes 4.2.6 Add new Manager a) Yes b) Yes c) Yes

Page 73


d) Yes 4.2.7 Delete Manager a) Yes b) Yes c) Yes d) Yes 4.2.8 Add new Engineer a) Yes 4.2.9 Delete Engineer a) Yes b) Yes c) Yes d) Yes 4.2.10 Change admin password a) Yes b) Yes c) Yes

Page 74


Test Data for Functional Test Question Data 2.1 c) Name: “Jonathan Price” Password: “Jonathan” Manager: “Terry Carter” 2.1 d) Incorrect Password: “Greg” 2.1 e) Correct Password: “Jonathan” 2.2.1 c) Change manager to “Scott Wilson” 2.2.2 b) Incorrect Dates: “78/22/33” “test” 2.2.2 i) eng dateOfJob oTRef hours clientName ukJobno notes

Jonathan Price 03/03/2003 1 22 Smith 762181 Test Jonathan Price 03/02/2003 1 11 Rabbo 4325 Test lalala Jonathan Price 02/01/2001 9 11 West Deutche 1212 works Jonathan Price 02/05/2003 8 3 Test 14422 test test Jonathan Price 01/01/2002 17 2 William Hill 212121 eweweeewweJonathan Price 02/05/2003 3 3 Dave Bank 2121 feueihis Jonathan Price 02/05/2001 3 3 Dave Bank 233111 test1 Jonathan Price 03/05/2001 3 3 Dave Bank 2121222 test3 Jonathan Price 04/05/2001 3 3 Dave Bank 221231 test4 Jonathan Price 05/05/2001 3 3 Dave Bank 22222 test5 Jonathan Price 06/05/2001 3 3 Dave Bank 22122112 test6

3.2.2 b) eng dateOfJob overtimeRef hours clientName ukJobno notes Jonathan Price 02/01/2003 1 11 Smith Bank 23

3.2.3.1 a) 11/50/06 3.2.3.1 b) 02/01/03 3.2.3.1.d) 02/05/03 3.2.3.2 a) 11/50/06 3.2.3.2 b) 11/50/06 3.2.3.2 d) 01/01/03 – 06/05/03 4.1 b) “Dave” 4.2.3 b) “Jon..”

Page 75


Questions for semi-structured interviews Usability questions in black functionality questions in grey Engineer User 1. HOME PAGE 1.1 Describe the first thing you notice on the screen 1.2 Identify the ‘clickable/actionable’ elements on this page 1.3 What do you expect to find behind the links 2. LOGIN PAGE 2.1 Describe the first thing you notice on the screen 2.2 Identify the ‘clickable/actionable’ elements on this page 2.3 What do you expect to find behind the links 2.4 Did you understand what to do if your name wasn’t on the list (REGISTER PAGE) 2.4.1 Did you find the form straight forward 2.4.2 Is there anything else you expected on the form 2.4.3 Did it work, was there an error screen 2.4.4 Were you satisfied with the time taken to process 2.5 Could you get back to the log in page after registering 2.6 Did your new password work to get you into the system (ERROR PAGE) 2.6.1 Describe the first thing you notice on the screen 2.6.2 Was it clear where you made the error 2.6.3 Were you aware of the two different options available to move on 2.6.4 Did the corrected password work 3. MAIN MENU 3.1 Describe the first thing you notice on the screen 3.2 Identify the ‘clickable/actionable’ elements on this page 3.3 What do you expect to find behind the links 3.4 Would you say the options/capabilities for you are obvious 4. EDIT DETAILS 4.1 Describe the first thing you notice on the screen 4.2 Identify the ‘clickable/actionable’ elements on this page 4.3 Is it obvious what was the original and what you were changing it to 4.4 Did your changes work 5. VIEW HISTORY 5.1 Describe the first thing you notice on the screen 5.2 Identify the ‘clickable/actionable’ elements on this page 5.3 What do you think of the click through to view detail, was it made clear 5.4 What do you think about the colour scheme 5.5 Did the corresponding job detail come up when you clicked on it 6. LOG OVERTIME 6.1 Describe the first thing you notice on the screen 6.2 Where the form formats clear 6.3 Does the drop down make it simpler to fill in or more cumbersome 6.4 Did it work Administrator User

Page 76


Usability questions in black functionality questions in grey 7. HOME PAGE 7.1 Describe the first thing you notice on the screen 7.2 Identify the ‘clickable/actionable’ elements on this page 7.3 What do you expect to find behind the links 8. LOGIN PAGE 8.1 Describe the first thing you notice on the screen 8.2 Did it work, did you login, was there an error screen (ADMIN ERROR PAGE) 8.2.1 Describe the first thing you notice on the screen 8.2.2 Was it clear where you made the error 8.2.3 Were you aware of the two different options available to move on 8.2.4 Did the corrected password work 8.3 Were you satisfied with the time taken to process 8.4 Could you get back to the log in page after error screen 9. MAIN ADMIN MENU 9.1 Describe the first thing you notice on the screen 9.2 Identify the ‘clickable/actionable’ elements on this page 9.3 What do you expect to find behind the links 9.4 Would you say the options/capabilities for you are obvious 10. SEARCH / EDIT / ADD OT DETAILS SECTIONS (BY MGR)

10.1 MGR SELECT PAGE

10.1.1 Describe the first thing you notice on the screen 10.1.2 Identify the ‘clickable/actionable’ elements on this page 10.1.3 Is it obvious how you get to the engineer you are looking for

10.2 TEAM MEMBERS BY MGR RESULTS PAGE

10.2.1 Describe the first thing you notice on the screen 10.2.2 Identify the ‘clickable/actionable’ elements on this page

10.2.3 Do you like the colour scheme 10.2.4 In adding or changing details or OT any additional comments *

11. SEARCH / EDIT / ADD OT DETAILS SECTIONS (BY ENG NAME)

11.1 ENG SELECT PAGE

11.1.1 Describe the first thing you notice on the screen 11.1.2 Was the form obvious enough 11.1.3 Did the search bring you the right results

11.2 TEAM MEMBERS BY MGR RESULTS PAGE

11.2.1 SEE 10.2.1 11.2.2 SEE 10.2.2

11.2.3 SEE 10.2.3 11.2.4 SEE 10.2.4

12. EDIT / ADD / REMOVE TYPES 12.1 Describe the first thing you notice on the screen 12.2 Identify the ‘clickable/actionable’ elements on this page 12.3 Was the layout clear enough to distinguish the various functions (delete/add etc) 12.4 Were the warnings clear enough 12.5 Did the ‘edits’ / ‘adds’ / ‘deletes’ all work

Page 77


13. DELETE MANAGER 13.1 Identify the ‘clickable/actionable’ elements on this page 13.2 Were the warnings clear enough 13.3 Did the ‘deletes’ all work 14. DELETE ENGINEER 14.1 Identify the ‘clickable/actionable’ elements on this page 14.2 Were the warnings clear enough 14.3 Did the ‘deletes’ all work Manager User Usability questions in black functionality questions in grey 15 LOGIN 15.1 Describe the first thing you notice on the screen 15.2 Identify the ‘clickable/actionable’ elements on this page 15.3 What do you expect to find behind the links 15.4 Did you understand what to do if your name wasn’t on the list (REGISTER PAGE) 15.4.1 Did you find the form straight forward 15.4.2 Is there anything else you expected on the form 15.4.3 Did it work, was there an error screen 15.4.4 Were you satisfied with the time taken to process 15.5 Could you get back to the log in page after registering 15.6 Did your new password work to get you into the system (ERROR PAGE) 15.6.1 Describe the first thing you notice on the screen 15.6.2 Was it clear where you made the error 15.6.3 Were you aware of the two different options available to move on 15.6.4 Did the corrected password work 16. HOME PAGE 16.1 Describe the first thing you notice on the screen 16.2 Identify the ‘clickable/actionable’ elements on this page 16.3 What do you expect to find behind the links 16.4 Do you like the layout 17. VIEW TEAM RECORDS 17.1 Identify the ‘clickable/actionable’ elements on this page, was it made clear

17.2 VIEW PAGE 17.2.1 What do you think of the click through to view detail, was it made clear 17.2.2 What do you think about the colour scheme 17.2.3 Did the corresponding job detail come up when you clicked on it 17.2.4 Were the links on the bottom useful from where you are now

18. ADDING O/T FOR YOUR TEAM 18.1 Was it simple enough to process 18.2 Did it work 18.3 Any additional comments 19 SEARCHING THE ARCHIVES

19.1 SEARCH O/T BY SPECIFIC DATE PARAMETERS

Page 78


19.1.1 Describe the first thing you notice on the screen 19.1.2 Was it easy to distinguish what the forms were doing 19.1.3 Did the corresponding job detail come up when you clicked on it 19.1.4 Were the links on the bottom useful from where you are now 19.2 SEARCH WITH INTENT TO PRODUCE SUM TOTALS OF O/T

19.2.1 Describe the first thing you notice on the screen 19.2.2 Was the form simple to use 19.2.3 Did the corresponding jobs and correct totals come up 19.2.4 Were you happy with the layout 19.2.5 Additional Comments

20. AMENDING YOUR TEAMS OVERTIME RECORDS 20.1 Were you happy with the process as a whole 20.2 Was the process simple 20.3 From the other pages did you identify the clickable areas from the lists 20.4 Did it work 20.5 Any additional comments

Page 79


Scenario Testing Scenario 1. User type: Engineer Description:

For an Engineer to be able to log overtime once they are logged in as themselves, from their account home page.

Justification:

This is a fundamental requirement of the system. The processes of logging and navigation are highlighted in this test.

Expected outcome:

Even users that have not had exposure to the system but is familiar with the process itself, should be able to clearly read the navigation and the overtime will be logged successfully.

Scenario 2. User type: Administrator Description:

An administrator to be able to locate the name of an engineer in the system and view their subsequent O/T record.

Justification:

To test the usability and effectiveness of the searching facility, the quality of the navigation and clarity of text.

Expected outcome:

That the user manages to find the name of the engineer they are looking for and go onto view their subsequent record.

Scenario 3. User type: Manager Description: Pull out all overtime for your team for a selected period, simply for viewing

accounts of everybody in your team, not totals per individual.

Justification: To test the usability and effectiveness of the searching facility, the quality of the navigation and clarity of text.

Expected outcome:

That the user manages to find the name of the engineer they are looking for and go onto view their subsequent record with the correct amount of OT.

Scenario 4. User type: Administrator Description:

An administrator to be able to change the details of an engineer from viewing an engineer’s last 10 jobs.

Justification:

To ensure that the user can navigate away from one area and harness the functionality of a separate area for the same engineer.

Expected outcome:

The navigation is successful by the side bar not being used; the back buttons (i.e. return to main menu) should be efficient enough to navigate and the text should be clear enough.

Scenario 5. User type: Engineer Description:

Change your own personal details for example Password from your homepage

Justification:

To check that the navigation and functionality work. That the user understands how to work with their own data and understand what is available for them.

Expected outcome:

That the details edit page is found and successfully altered.

Page 80


Scenario6. User type: Manager Description: Change some specific test data overtime for one of your own team in some way,

e.g. change the date of the job to today’s date. Justification: As scenario 5 Expected outcome: That the data is successfully amended in the system and the user ends up at their

own home page. Scenario7 User type: Administrator Description: To change the password of a test manager Justification As scenario 6 Expected outcome: As scenario 6 Scenario8 User type: Engineer Description: To find your total list of jobs, i.e. your complete history of records. Justification To understand where some of the less obvious elements of functionality are and the

logic as to where they are. Expected outcome: That the user finds the option within the list of last 10 jobs to go to all jobs in

archive for that user. Scenario9 User type: Manager Description: To bring up the total overtime figure for one of your team over a set period. Justification To check the functionality meets the requirements and that the users can navigate

around their area and relevant data lies. Expected outcome: That the correct page is found and the data is correct Scenario10 User type: Administrator Description: Add an arbitrary type of overtime then delete it Justification To ensure that adding and deleting functionality meets requirements and is

acceptable to use. Also to ensure that the user understands the importance of how editing and deleting effects the data structure (relationships)

Expected outcome: That the correct page is found from the main menu and the data is removed afterwards!

Page 81


Scenario Testing Results Administrator: Jacqueline Berry Scenario 2 Description:


Notes:

Struggled at first despite text indicating in bold “to view” Mentioned it would be good to have “search by client as well” Unsure that what she was doing was correct way Used skills picked up from other pages in general question session, demonstrated intuitiveness.

Expected outcome:


Expected outcome achieved:

Yes

Scenario 4 Description:


Notes:

Knew how to get to view the last 10 jobs but could not spot to view full archive. Had to help out Became obvious once pointed out

Expected outcome:



No Did need help but that was based on the users general ability


To change the password of a test manager

Notes:

Used personal menu, followed buttons OK. FINE

Expected outcome:

That the data is successfully amended in the system and the user ends up at their own home page.


Yes


Add an arbitrary type of overtime then delete it

Notes:

Used list fine, noted the adding section separated from the edit list. Added OK deleted fine.

Expected outcome:

That the correct page is found from the main menu and the data is removed afterwards!


Yes

___________________________________________________________________

Administrator: Sara Moring

Page 82




Notes:

Used search by engineer name, used intuitively from walkthrough done during questions before hand. All fine

Expected outcome:



Yes



Notes:

Hesitant, not clear, took time to find. Had to ask me for help to point exactly where to look

Expected outcome:



No


To change the password of a test manager

Notes:

Wasn’t sure, firstly used search for engineer by manager (which is totally wrong) had to have help

Expected outcome:

That the data is successfully amended in the system and the user ends up at their own home page.


No


Add an arbitrary type of overtime then delete it

Notes:

Used menu at front, all fine it worked

Expected outcome:

That the correct page is found from the main menu and the data is removed afterwards!


Yes

___________________________________________________________________

Page 83


Engineer: Ali Rana Scenario 1 Description:


Notes:

Used form very quickly, followed formats that were indicated above, missed out a cell and noted the error message before re processing.

Expected outcome:



Yes

Scenario 5 Description: Change your own personal details for example Password from your homepage Notes:

Read the links properly, understood options. Raised issue of allowing spaces in passwords.

Expected outcome: That the details edit page is found and successfully altered. Expected outcome achieved:

Yes

Scenario 8 Description: To find your total list of jobs, i.e. your complete history of records. Notes: Found this easy, used intuitive knowledge from prior usage. Went to it very quickly

from the front end Expected outcome: That the user finds the option within the list of last 10 jobs to go to all jobs in

archive for that user. Expected outcome achieved:

Yes

Engineer: James Hellen Scenario 1 Description:


Notes: Used formats in the form. Quickly done, took time over the drop down. Expected outcome:



Yes

Scenario 5 Description: Change your own personal details for example Password from your homepage Notes: Used links, read what was available to him. Also noted the original and changing

to aspects of colour. Expected outcome: That the details edit page is found and successfully altered. Expected outcome achieved:

Yes

Page 84


Scenario 8 Description: To find your total list of jobs, i.e. your complete history of records. Notes: Read the text, found it straight forward. Naturally progressed to the full archive. Expected outcome: That the user finds the option within the list of last 10 jobs to go to all jobs in

archive for that user. Expected outcome achieved:

Yes

Manager: Terry Carter Scenario 3 Description:

Pull out all overtime for your team for a selected period, simply for viewing accounts of everybody in your team, not totals per individual.

Notes: At first went to the sum version, then went back to main menu. Hesitated. Picked the correct view by range button and went for a select date.

Expected outcome:

That the user manages to find the name of the engineer they are looking for and go onto view their subsequent record with the correct amount of OT.


Yes (eventually)

Scenario 6 Description: Change some specific test data overtime for one of your own team in some way,

e.g. change the date of the job to today’s date. Notes: From main menu read each option, initially went to view. Then understood

‘amend’ option. Selected name of list. Hesitated on selecting a job, unsure where to click despite using a similar page when simply viewing. After reading went in to edit.

Expected outcome: That the data is successfully amended in the system and the user ends up at their own home page.


Yes

Scenario 9 Description: To bring up the total overtime figure for one of your team over a set period. Notes: After mistake from scenario 3 went for correct page straight away. Understoof the

form. Fine Expected outcome: That the correct page is found and the data is correct Expected outcome achieved:

Yes

Page 85

Documents

A Web Based Overtime Logging System for Reuters … Web Based Overtime Logging System for Reuters Jonathan Price BSc Information Systems - Management Studies Session 2002/2003