By the end of the placement in July 2002, a beta version was being prepared for testing sites.

Transcription

1 Summary Intex Software Ltd specialises in the development of payroll software. During the third year of her undergraduate degree, the author did a ten month placement at Intex software as a junior developer. The placement at Intex began shortly after they started the development of Earnie IQ, their new upgraded payroll software. Along with seven senior developers and two other students, I was to be on the development team to write Earnie IQ. The payroll software would be written in VB6 and SQL and its original release date was July The release date was later postponed to September By the end of the placement in July 2002, a beta version was being prepared for testing sites. At Intex, all holidays, absences and overtime were requested on paper and handed to the departmental manager. Upon leaving Intex, the company requested a system to computerise these processes. The following solution has gone beyond the minimum requirements to create an efficient, usable system.

2 Acknowledgements I would like to thank John Davy for his invaluable advice and support throughout this project. I would also like to thank Natasha Shakhlevich for her suggestions after the mid-project report and the progress meeting. This project would not have been possible without the help and endless patience of those at Intex Software Ltd. Thank you very much, Charlie Pickering, Kathryn Simpson and Philip Mackey.

3 Table of contents Summary... ii Acknowledgements... iii 1 Introduction Motivation Project Aim Objectives.3 2 Background Research About Intex Software Ltd Evaluation of existing system Conclusion 6 3 Analysis Requirements & deliverables Choice of methods Choice of platforms Summary Design Database design Data Modelling Logical Database design Normalisation Integrity constraints and business rules Interface design Summary 27 5 Implementation Login Sub-systems implementation Holiday and Absence Overtime Implementation issues Summary 31 6 Testing White box and black box testing Test plan User testing Summary 35 7 Evaluation Evaluation against objectives Evaluation criteria User & personal evaluation Summary 40 8 Project management Project Schedule 42

4 9 Conclusion References Appendix A - Project reflection Appendix B - Program Specification Appendix C Holiday and Absence request forms Appendix D Complete ER diagram Appendix E Storyboards Appendix F Online forms Appendix G Intex Coding standards Appendix H Intex Interface standards Appendix I Test plans Appendix J Letter from Intex Appendix K Original schedule Appendix L Modified schedule... 60

5 1 Introduction The aim of this report is to outline the processes followed during the development of the system. Chapter 1 outlines the motivations for the project, and includes the project aims and objectives. This is followed by the background research in chapter 2. It includes a short section about the company and the existing system. Chapter 3 discusses the requirements and deliverables of the system. It also includes a discussion of the methods and platforms to be used. Chapter 4 deals with the design stage, mainly the database design and the user interface design. This is followed, in chapter 5, by an explanation of the process undertaken to combine the ideas and the designs. Chapter 6 outlines the methods of testing to be used and includes a discussion of the issues arising from the user testing. The project is then evaluated against the objectives in chapter 7. This also includes the users evaluation of the system and possible future enhancements. Chapter 8 comprises of the project schedule and a discussion of changes that were made to the original schedule. Finally, the project is concluded in chapter 9, along with suggestions for future enhancements of the system. 1.1 Motivation Admittedly, in the first two years at university, programming modules were not the author s strongest. Carrying out a placement at Intex has changed this outlook. Prior to the placement, the author had never come across VB6 and was sent a Teach Yourself guide by the company to learn the fundamental concepts. Having done ten months at Intex, programming does not seem so daunting. It was an additional bonus to have access to a fairly simple language with straightforward syntax. Though simple, VB is capable of broadening the understanding of programming techniques the concepts behind classes and objects that were taught in the School of Computing modules, SO11 and SO21.

6 Having discovered a new interest for software development, it was an honour to be sent the program specifications by the Quality Assurance (QA) team at Intex (Appendix B). Though the requirements had been laid out, they were broad enough to allow for new ideas and innovative designs. Having experienced the paper-based system first hand, the aim is to make the system more efficient and relieve departmental managers of unnecessary workload. It is also anticipated that this system can be used in conjunction with their main payroll software; especially the overtime sub-system (this is discussed further in chapter 7.3). Although good programming and development knowledge were acquired at Intex, a project of this nature is broad enough to allow the analysis and design stages to be carried out, which was not possible to do during the placement. 1.2 Project Aim The aim of this project is to implement a system to replace the paper-based one currently in use at Intex Software. The system records employee holiday bookings, absence and overtime payments. The current manual system requires an employee to fill in the relevant form and submit it to their manager. This is then confirmed by the manager who signs it and submits it to the payroll director to include in the next payroll run. Creating a computerised system will hopefully facilitate queries by employees relating to past holiday bookings. It will also simplify the integration between the payroll and payslips.

7 1.3 Objectives Before proceeding, the objectives of the project need to be identified. These objectives will then provide a basis for the evaluation of the system. The objectives of the project are outlined below. Acquire a complete program specification from the company. Ascertain why the system is an important issue to the company and, from the requirements, determine whether the platforms requested are suitable. Design the database structure to be used. Outline the methodology to be used to solve the problem. With thorough analysis and requirements gathering, design a good database structure and user interface which will meet the project aim. Implement the program. Develop the system in the time available. Ensure that the code is appropriately commented to allow changes to be added easily in the future. Install the program and use it within the company. Once the system development is complete, carry out user testing and make changes where needed. A final installation will then be carried out. Provide full documentation for the company. Provide written documentation for the company on how to use the system and on maintenance issues.

8 2.0 Background research This chapter examines Intex Software; what they have done in the past and what they are currently doing. It also includes an evaluation of the existing system and how this has prompted the request for the new computerised system. 2.1 About Intex Software Ltd Intex Software s mission statement is to make Intex the first choice for payroll (Intex, 2002). Intex Software have been payroll specialists since They are an award winning payroll provider and a leader in the UK payroll software market. With over 20 years experience writing and supporting payroll software, Intex now has more than 4000 customers using its products (Intex, 2002). Intex have recently moved away from the DOS environment and have been concentrating on producing and developing payroll software for the Windows environment. This has been a direct result of changes in the software market. Early DOS packages include BONUS! and CLASSIC and customers were using them for up to 16 years before upgrading to the Earnie windows payroll. This included Earnie/16, Earnie/32 and Earnie IQ the new SQL server version which was released in September Earnie/32 was rewritten from scratch and was based on the 16-bit payroll. It was launched in September Intex have recently completed the development of Earnie IQ, a client server payroll, which uses the latest features of the SQL 2000 database. The functionality is based on the previous version, Earnie/32 but it has been rewritten from scratch

9 to ensure that customers benefit from the technology. As a result, multi-user sites have quick and efficient access to their payroll information. A new timesheet entry module has been specially designed for use with Earnie IQ. This speeds up the processing of payroll, because timesheet details can be entered straight into the module. The P11D module was also rewritten specially for Earnie IQ. This P11D module is a tax form which sets out employee benefits and expenses for those employees earning in excess of 8500 p.a. As well as supporting the software products, Intex also offer a bureau service for companies that do not want to run their payroll in-house. 2.2 Evaluation of existing system At present, Intex Software only has about 60 employees. If any of these employees needed to book a holiday, a form would be filled in. This form states the dates of the holiday and the reason. The form is then submitted to the departmental manager who confirms the holiday, ensuring that there would be no staff shortages for that period. The next stage is to pass the form to the payroll directors to be included in the next month s payroll. This process can be timeconsuming and forms have been misplaced in the past. Similarly, to book an absence for a doctor s appointment, jury duty or illness, employees have to fill in a form stating the relevant information (Appendix C). In order to claim overtime, employees fill in the relevant form once the hours have been worked. They also state the reason for the overtime and the total number of hours worked.

10 All these forms will be used by the payroll director as input into the payroll run. A major problem with the manual system is the amount of paper work that it generates. 2.3 Conclusion Intex Software have requested a system to replace a current paper-based one. The manual system should be enhanced by implementing a computerised system in order to improve the management procedure currently in operation at Intex. Intex have requested this system because they are a relatively small company and it is cheaper than if they were to buy one off-the-shelf. In addition, with code written by a former employee, it will be to their coding and interface standards and this will allow for customisation and future improvements to the system. The company would benefit from a computerised system because with humans, delays are possible and many other factors would influence the consistency and accuracy of processing the data.

11 3.0 Analysis Having established the need for a new system in the previous chapters, this chapter outlines the requirements and the deliverables that will be made available to Intex. It also discusses the platforms requested and their suitability for this project. A suitable methodology to be used in the implementation of the final design is outlined in this chapter. 3.1 Requirements Requirement specifications should be a high level statement of what the new system is expected to do. The specifications will be used by Intex as a vital check on the completed software. The success of an information system depends strongly on the quality of the requirements definition, which should be drawn up in the early stages of the development process (Redmill, 1997). This will determine whether or not a useful system will be developed. These requirements have been specified by Intex, and include details of each subsystem s requirements (Appendix B). Although most of the requirement gathering was carried out by the QA department at Intex, it would not have been possible to proceed without some clarifications. Enquiries were made about the holiday year-to-date figures and their derivation and employee access levels. In addition, the access levels for the reports were clarified with the company. Minimum Requirements The project will be divided into two sub-systems and the minimum requirement of this project is to create the database system which covers holiday and absence. The overtime sub-system is not a minimum requirement, but may be included in the final stages, time permitting.

12 The system will be designed as an independent system, but it should be possible to integrate it with the company s latest payroll software, Earnie IQ. Deliverables The main deliverable will be the project report, and a working database system. In addition, a user manual will be provided for the company. A maintenance manual will not be included because personal assistance will be given for a certain period. After this time, the company will be able to claim full ownership and maintain the software themselves. 3.2 Choice of methods The waterfall model approach to development is a process of developing software iteratively in six stages. By following the life cycle, it becomes easier to plan and manage the different tasks of systems development. However, more traditional life cycles do not take into account the fact that requirements could change. It implies that the users know the goals and can proceed in a straight line (Avgerou & Cornford, 1998). For the Holiday, Overtime and Absence logging system, the waterfall model will be used, but in an iterative way so that it is possible to back track and make changes where necessary (Figure 3.1). The arrows go up and down, reflecting the fact that developers often have to rework earlier stages. A project milestone terminates each stage and the deliverable from that stage is approved by the users. However, it may be hard to do all the stages of the life cycle one after the other. There are too many unknowns and dynamic changes (Gilb, 1988). Trade offs and compromises need to be made so that feedback can be acquired from one stage and modifications can be made where necessary.

13 Analysis Feasibility study Requirements analysis Design Design Implementation Coding and Testing Conversion Review & maintenance Postimplementation review Figure 3.1 Waterfall model (adapted from Heathcote, 1998) This waterfall model is complimentary to the standard methodology for database projects as provided by the School of Computing (SoC, 2002). The SoC guidelines will be used in the design phase of the waterfall model. The main stages in the methodology are data modelling, a logical database design, performance of normalisation and the implementation of integrity constraints and business rules.

14 The waterfall model has more benefits than other lifecycle models such as the star model. The star model places the user at the centre of the lifecycle and involves them at every stage. It also involves the evaluation of four other stages carried out before the design is generated. These stages are task/functional analysis, requirements specifications, implementation and prototyping (Gilb, 1988). Though user involvement is important, it does not seem practical to involve them at every single stage. In addition, the users of the system are busy with work commitments and so it appears more logical to involve them in the most important stages, such as requirements gathering and testing and evaluation. Another problem is that the processes in the star model can be time consuming and expensive to carry out. 3.3 Choice of platform Intex have specified that they would like a database system using Access 97. However, it is important to consider other database options as well. A database is a good option and has its advantages. It will provide data for the organisation as a whole, not just for the individual departments. It will also be easier to ensure that the data is up-to-date and without duplications. Intex currently use and support both SQL server and Access, so the merits of these should be compared. Cost is not an issue because they do not have to buy either database systems. For this reason, Oracle and other database systems have not been included in this comparison. ACCESS To cope with a potentially high number of requests, the database needs to be efficient, reliable, robust and scalable. Microsoft Access is a multi-user relational database management system that was designed for the Microsoft Windows operating systems (such as Windows 9n,

15 Windows NT, Windows 2000). Access is highly visually oriented and easy to use. It makes extensive use of drag-and-drop and visual design for queries, forms, and reports (MSDN, 2002). Though the maximum database size is 1 Gb, the database can include linked tables in other files, and its total size is limited only by available storage capacity. Microsoft Access is a file server database which handles requests for data by directly accessing the database file located somewhere on the network or on the server itself. The requests are made from the database engine on the client s computer, which is responsible for locating the necessary database files and determining what data should be read. This is extremely inefficient, as large amounts of data need to be transferred to the client for processing. For example, when updating a record, a single request may actually require several accesses to the database. Therefore, a database like Access is best suited in a single-user applications, or systems with a small number of users with few requests. SQL SERVER SQL server is a client-server database which is more scalable and robust than Access. The server itself handles all requests for data. Applications on the client side send SQL queries, which the server processes and returns only the result for. The client does not directly read from or write to the database file. This approach is very efficient for handling a large number of requests. In addition to the significant performance and scalability advantages SQL Server has over Microsoft Access, there are a number of other key considerations to be taken into account. SQL Server is a transactional database system, meaning that data is always left in a consistent state, even in the event of the server crashing (MSDN, 2002). Microsoft Access does not offer such robustness and often fails under a heavy workload. Although Microsoft Access databases are much easier to develop

16 than SQL Server databases, the limited scalability and robustness does not make it a practical option for large development projects. Table 3.1 Comparison of SQL Server and Access Feature Microsoft SQL Server Microsoft Access (JET) Database size 1,048,516 Terabytes (TB) 2 gigabytes (GB) Objects in database Number of concurrent users 2,147,483,647 32,768 Unlimited 255 Failure recovery Point in time recovery Recoverable to the last backup Security Integrated with Windows 2000 and Windows NT security Based on use of workgroup information file (Microsoft, 2002) From the above table, it is clear that SQL server would be useful for a system which would support many users, as it is scalable and offers better security measures. However, Access is useful for systems which need to be compatible with earlier versions of Access. In addition, it is well suited to an environment with a small number of simultaneous users in which data will not grow beyond 2 Gb. These results have been presented to the company and it was suggested that SQL server be used instead of Access. It is clear that the merits of SQL far outweigh those of Access. However, since the proposed system is small and would only be used in-house for the time being, the company decided to use Access as the database. Nevertheless, SQL should not be totally dismissed,

17 because a future enhancement of such a system would be to increase the database capacity; changing from Access to SQL may achieve this. 3.4 Summary At this stage, the aim of the system has been specified. A problematic situation has been explored, systems requirements have been collected and assessed and different alternatives have been evaluated of which one has been selected. The next stage will be to specify the data that the new system will deal with and establish the database and interface designs.

18 4.0 Design This chapter outlines the different stages in the design phase of the project, as stated in the School of Computing guidelines for database projects (SoC, 2002). The first stage is data modelling, followed by logical database design and finally normalisation. It is vital to go through all the stages in order to design a good database structure, as omitting stages in the design could lead to data inconsistency in the future and duplications may occur. 4.1 Database design The information held in the database should be an accurate representation of the Universe of Discourse (Roberts, 2002). This is the concept behind data modelling, where real life situations are translated into graphical representation. This database design process can be simplified as shown in figure 4.1. The first stage is identifying the data needed from the UoD and the reasons for this data. This is shown as the requirements collection and analysis, and has been carried out in the preceding sections. Once all the requirements have been collected and analysed, the next step is to create a conceptual design or data model (Elmasri and Navathe, 2000). This is a brief description of the data requirements and a detailed description of the entities, relationships, attributes and constraints. The next step is the implementation of the database, using Access, and is shown on the diagram as the logical design. The final step is the physical design stage which is carried out in parallel with the application program design. This stage involves defining the storage structures and file organisations of the database (Elmasri & Navathe, 2000).

19 UoD Requirements collection and analysis Conceptual design Logical design Application program design Physical design Application program Figure 4.1 Main phases of database design (adapted from Elmasri & Navathe, 2000) Data Modelling From the requirements provided, it is evident that the UoD concerned is Intex Software. The information provided by the UoD needs to be classified as either entities, relationships or attributes. An entity is a real world object; for example, an employee. Each employee will have access to the system and they will all have the same attributes. So each

20 person at Intex Software is an instance of employee and an entity of entity-type employee. Each identified entity will have a set of attributes. The attributes describe the entity; for example, each entity-type employee will have an attribute called name. An attribute can appear in different entities, but never in the same entity twice. Relationships exist between two or more entities. In order to fully specify relationships that model the UoD, cardinalities and participations are used. There are three different types of relationships, as shown in Figure 4.2 Each relationship will also have a degree of participation. This describes whether an instance of an entity must be related to an instance of an entity to which it is related (Roberts, 2002). A solid line means compulsory participation, while a dotted line means optional participation. With this process complete, an Entity-Relationship (ER) diagram can then be developed. Using the Intex UoD, figure 4.3 was the initial ER diagram.

21 There are several criticisms of this diagram. The first is the relationship between the employee entity and the users entity. Given that all employees are users and all users are employees, one of the tables will be redundant. In addition, the relationship between a holiday and its year-to-date (YTD) figure has been omitted, but from the diagram it can be assumed to be 1:1. If this is the case then a YTD value can be regarded as an attribute of holiday (Proll, 2002). As a result, these two entities can be removed in order to ensure that the database will contain no duplications. The final ER diagram in figure 4.4 takes these points into consideration. The complete ER diagram showing all the entities and their attributes is shown in appendix D.

22 Participations and relationships in the ER diagram are described below. Membership/Participation Descriptions Partial participation for Employee, total (mandatory) participation for absence. Every absence needs to be requested by an employee. Not every employee needs to request an absence. Partial participation for Employee, mandatory participation for holiday. Every holiday needs to be requested by an employee. Not every employee needs to request a holiday. Partial participation for employee, mandatory participation for overtime.

23 Not every employee will have an overtime entry. An employee must log each overtime entry. Relationship descriptions and assumptions EMPLOYEES to HOLIDAY o An employee can have several holiday entries. EMPLOYEES to ABSENCE o An employee can have several absence entries. EMPLOYEES to OVERTIME o An employee can have several overtime entries. Entity Sub Types Employee entity is split into sub-types because each sub-type is a different type of user and they will have different access levels. These sub-types are mutually exclusive. No manager is a director; no normal employee is a manager; and no normal employee is a director. It should be noted at this stage that there have been no departures from the standard ER modelling techniques as outlined on the School of Computing website (SoC, 2002).

24 4.1.2 Logical database design The logical database design involves representing the database in terms of tables. This does not mean just translating entities and their attributes into tables; on the contrary, several mapping rules need to be followed. If all the rules for ER modelling have been followed, then this stage should not be complicated (Proll, 2002). The final outcome of this stage should be a functional database design which will be flexible enough to allow future modifications and requirements with minimum hassle. This will in turn create a high-level data independence. The standard mapping rules used for the logging system are outlined below (adapted from Proll (2002)). Mapping entity sets: Each entity set is associated with a table and the attributes in an entity set become the fields in the table. The key attributes in that entity set will become the primary key (PK) in the table. This will usually be the ID field which helps to identify each record. Mapping 1:1 relationships: 1:1 relationships are represented by posting the primary key of one entity set into the other entity set as a foreign key (FK). Mapping 1:M relationships: This is treated the same as a 1:1 relationship, except that the single end of the relationship is the master and the crows foot end of the relationship is the detail. The PK of the master entity set is posted as a FK in the detail entity set. Mapping M:N relationships: A new table needs to be created to represent this relationship type. The two PKs from the entity sets are posted as FKs in the new table. With these mappings in mind, it is now possible to convert the ER model into a logical database design as follows.

25 NB For each table, the primary key is underlined and the foreign key is in italics. Employee (EmpID, Name, UserName, Password, Group) Holiday (HolidayID, EmpID, Entitlement, Date, StartDate, EndDate, NoOfDays, Confirmed) Absence (AbsenceID, EmpID, Type, Date, StartDate, EndDate, LeavingTime, ReturningTime, Notes) Overtime (OvertimeID, EmpID, Date, HoursTaken, OvertimeRate, OvertimePaid) Employee table Field Null? Type Size Description EmpID No AutoNumber 4 Primary Key. Unique ID Name No Char 50 Employee s full name UserName No Char 20 User name Password No Char 15 Password Group No Char 15 Either employee, manager or director. Holiday Table Field Null? Type Size Description HolidayID No AutoNumber 4 Primary Key. Unique ID EmpID No Number 4 Foreign key from Employee table Entitlement No Number 2 Number of holidays allowed each year Date No Date 8 Date of application (Today s) StartDate No Date 8 First date of holiday EndDate No Date 8 Last date of holiday NoOfDays No Number 2 Calculation total days taken Confirmed No Yes/No - Yes/No

26 Absence Table Field Null? Type Size Description AbsenceID No AutoNumber 4 Primary Key. Unique ID EmpID No Number 4 Foreign key from Employee table Type Yes Char 255 Type of absence Date No Date 8 Date of application (Today s) StartDate No Date 8 First date of absence EndDate No Date 8 Last date of absence LeavingTime No Time 5 Time to leave work ReturningTime No Time 5 Time to return to work Notes Yes Char 255 Extra information Overtime Table Field Null? Type Size Description OvertimeID No AutoNumber 4 Primary Key. Unique ID EmpID No Number 4 Foreign key from Employee table Date No Date 8 Date of application (Today s) HoursTaken No Number 4 Number of hours worked OvertimeRate No Currency 3 Amount paid per hour worked OvertimePaid No Currency 3 Calc: HoursTaken x OvertimeRate Although it seems appropriate to include employee name in the holiday, absence and overtime tables (as requested in the requirements), it will not be included. The reason for this is that they do not need to be stored in the tables. The empid foreign key is enough to identify the employee. When using the system, the employee name will automatically default to the employee that has logged in, and this can be linked back to the empid because it is a unique identifier. These tables have been implemented in Access and their relationships have been established. This can be seen in figure 4.5.

27 4.1.3 Normalisation Figure 4.5 Logical design in Access Now that the table schemes have been established, the tables need to be normalised. This will eliminate inconsistent data and ensure that there are no redundancies in the database. Four normal forms exist and they use a top down approach. This implies that if a table is in 3 rd normal form (3NF), it must also be in 1 st (1NF) and 2 nd normal forms (2NF). These normal forms are described below. 1 st normal form: A table contains no repeating attributes or sets of attributes. 2 nd normal form: A table is in 1NF and each non-key attribute in the relation must be functionally dependent on the primary key. 3 rd normal form: The tables are in 2NF and there are no transitive dependencies. This means that none of the non-key attributes are dependent on another attribute which in turn is dependent on the relation key (Brown, 2001). Therefore, all attributes that are not dependent on the primary key must be eliminated.

28 Boyce-Codd normal form: The tables are in 3NF and all of its determinants (attributes upon which other attributes depend) are candidate keys (i.e. the attributes could have been chosen as keys) (Brown, 2001). So far, the functional dependencies in the database design satisfy BCNF. 4.2 Integrity constraints and business rules With the UoD still in mind, the aim here is to ensure an accurate representation of it. Integrity rules will limit the type of data that can be stored in a column; while business rules prevent inappropriate data from getting into the database. The integrity constraints and business rules for the system are as follows: Integrity constraints No primary key can be null. This should be enforced every time a new record is added to any of the tables, or part of the primary key is updated. An error should be raised if this rule is violated. The foreign key in the tables should either be wholly null or it should have the same value as the primary key in the corresponding table. The relational Database Management System (Access) provides for these integrity rules as part of the transaction manager, so the database designer does not have to implement them. However, the designer has to indicate which are primary and foreign keys, so that the DBMS knows where to apply the entity and referential integrity checks (Roberts, 2002). Validation rules refer to the validity of data that will be input to the system. These are as follows. Employee ID will be a maximum of four digits, without trailing 0. Holiday entitlement will be a maximum of two digits.

29 Date will be entered in the format dd/mm/yyyy Time will be entered using 24hr clock. Holiday ID and absence ID will also be a maximum of four digits, without trailing 0 Last date of holiday should be later than the first date of the holiday. Holiday dates should be later than today s date. Date of application should be today s date. At the start of each year, holiday entitlement cannot be blank or 0 (unless employee has left, in which case their record should be deleted.) Business Rules Employees will be able to view all holidays they have booked. Employees will only be able to view their details. Employees will not be able to amend other employees records. Employees will not be able to confirm holidays. Employees and managers will not be able to amend their entitlement. Managers and directors will be able to see all holidays booked and confirm holidays. Directors will be able to amend holiday entitlement. All groups of users will have the same access and amendment rights for the absence section. Managers can only view their own overtime rate and overtime paid; and they cannot amend its values. Directors can view and amend all overtime fields. 4.3 Interface design The user interface is an important part of the system. It will be the only means for users interact with the system, and it needs to be aesthetically pleasing. The user interface (UI) needs to be designed in such a way that the user feels in control of

30 the software. Nielsen (1990) developed ten usability heuristics that can be applied to the logging system. These are outlined below. Visibility of system status Keep users informed on what is going on and provide appropriate feedback. Match between system and the real world Use words and phrases that users are familiar with. Use information in a natural and logical way. User control and freedom Have clear exits for users to get out of unwanted situation. Each screen in the system will have a cancel button and an exit menu option. Consistency and standards Platforms and conventions should be followed. The system will be coded according to Intex coding standards and interface standards (Appendix G and H). Error prevention Make sure error messages are useful. Error handling should be included to prevent error messages in the first place. Recognition rather than recall All options should always be visible and the users should not have to remember information. Instructions should also be visible. Flexibility and efficiency of use The system should cater for both novice and expert users. The system should be customisable for expert users. Aesthetic and minimalist design Dialogues should not have irrelevant information. Help users recognise, diagnose, and recover from errors Error messages should be easy to understand, explaining the problem and suggesting a solution. Help and documentation Documentation should be provided that is easy to follow and not too large. These heuristics have guided the development of storyboards to design the main interface. From the storyboards, (Appendix E), some of these heuristics can be identified. All the forms are clearly marked with exits, and some with cancel buttons. Furthermore, the error messages are clear and useful and give the users advice on how to resolve the error.

31 In addition to the interface, it is also important to consider the usability of the system because an interface is not considered usable unless the needs of the users are supported. Usability is defined as the measure of how well people are going to be able and be motivated to use the system practically (Gilb, 1988). This includes measuring learnability and speed of task execution. In order to produce a usable user interface, evaluation must be carried out regularly to ensure that the above heuristics are being followed. 4.4 Summary The design phase of the logging system has been outlined in this chapter. A good database design has been successfully established, and user interface issues have been taken into consideration.

32 5.0 Implementation The aim of this chapter is to describe the implementation of each sub-system was carried out. Implementation encompasses a broad range of concerns which take us from a developed system to a system in use (Avgerou & Cornford, 1998). It requires that the system be understood so that people can take up and use the new system. Tasks of implementation are usually technically simple and do not require sophisticated methods. As discussed in chapter 2, the system is based on an Access database and the interface to the system will be Visual Basic. The table schemas outlined in chapter 4 formed the basis for the implementation and in order to meet the specifications, they will be reviewed frequently. 5.1 Login Having designed the database, the process of defining a usable interface can begin. This design is based on the storyboards defined in appendix E. The login was straightforward, with only three different access levels. Once a user logs onto the system, it will check their access level and determine what fields and records they will and will not have permission to see. The user name and password are case sensitive and if the user does not exist in the database, or if log in details are incorrectly spelt, then an error message will be displayed. The final login interface is shown in figure 5.1. Figure 5.1 Login interface

33 5.2 Sub-systems implementation The requirement specifications stated that the system will be divided into two areas and the implementation has been consistent with these requirements. The holiday and absence sub-systems are a minimum requirement and the overtime was added at the end, after some modifications to the project schedule (discussed in chapter 8). Once the user has logged in successfully, then the main form is displayed. This is a multi-document interface (MDI) which will allow multiple data documents to be open in the same application. This form has drop-down menus which allow the user to choose from a selection of options Holiday and Absence The company requested that this section be viewed in a diary format and allow unlimited number of entries for each day. The file menu for this option will open the diary interface as shown in figure 5.2. This will show all the existing holiday and absence bookings. All entries in the diary are colour coded, as requested in the specifications. In order to request a holiday, employees will enter the details on the online form as shown in appendix F. An extra functionality has been added for managers and directors to be able to scroll through all the provisional holidays. This will consequently allow them to confirm these holidays. Employee absence can be booked in the same way, on the absence form. This form allows employees to record the details of their absence by choosing from a predefined list. This list covers absences such as hospital appointments, jury service and solicitors. Employees can also add notes about their absence, if it is for a reason other than those listed.

34 Figure 5.2 Diary interface Overtime The overtime sub-system will allow employees to log the number of overtime hours worked for a specified pay period. These details are entered in the same way as the other sub-systems. However, the overtime rate will be entered by the manager and will be the same as the figure in the payroll details. Employees will not be able to amend this figure or view the rate for another employee. All the forms can be seen in appendix F. 5.3 Implementation issues A number of revisions were made to the interfaces, in order to accommodate new requests made by the company. A new field called group was added to the database so that employees can only see details for colleagues in their

35 department and not those in other departments. This helps to maintain some control over the information available to employees. From the start of the project, the users have been involved in the development of the system. This has meant that the requirements are as comprehensive as they can be because they were gathered by the users themselves. In addition, the users have supplied standards to which the system will be implemented (Appendix G). 5.4 Summary Implementation is not just programming the system, but it is also the process of preparing people for the introduction of a new system. The users have been involved in the development so far and will also be involved in the next phase, testing. In addition, the system has been implemented according to Intex coding and interface standards.

36 6 Testing Software testing is a critical element of software quality assurance (Pressman, 1997). The aim of this chapter is to discuss the different types of software testing and design a test plan. It also describes both the outcomes of the user and functional testing. 6.1 White box and black box testing There are three main objectives to carrying out testing (adapted from Pressman, 1997). It is a process of executing a program in order to find errors. Testing should have a high probability of finding an undiscovered error. A successful test will uncover an undiscovered error. In order to successfully test the system, these objectives have to be considered. Two different types of tests can be carried out in the hope of meeting these objectives. The first is white box testing. This test is based on knowledge of the program s code. Tests are based on code statements, paths and conditions, rather then functionality (Pressman, 1997). It requires the creation of possible scenarios and does not involve the source code. Black box testing is also known as functional testing. It enables tests to be carried out against input conditions. It attempts to find errors in functions, the interface and data structures. This test is more likely to uncover more class errors than the white box testing (Pressman, 1997). Though other methods of testing exist, only two have been outlined here. Outlining all the methods would be beyond the scope of this project. The graphical user interface will also need to be tested against the requirements. Intex have their own set of interface standards (Appendix H) and the interface will be tested to confirm that it looks like and behaves as the users would expect.

37 6.2 Test Plan An objective of the testing stage is to prove that all the parts of the system work correctly with the data input. It should also check that all the parts of the system that were requested by the users have been included. This is a combination of both the black box and the white box testing. Three test plans were drawn up; one for employee functions, one for managerial functions and one to test the user interface. These are in appendix I. The tests do not specify the input data. This is deliberate, as they are merely guidelines. The users testing the software are experienced and know the type of data that will produce errors. The aim is to encourage the users to find errors in the system. After all, testing is a process of executing a program with the intent of finding an error (Heathcote, 1998). The users were able to input erroneous data, some of which are outlined in the following section. 6.3 User testing From the start of the project, every effort was made to involve users in the development process, so that they could accept and use the system. After implementation, the system was tested by the users to get a final approval. User testing is aimed at checking whether the system s performance is consistent with the design and analysis specifications. It aims at making sure that everything is in place for the system to begin operations. Testing at this stage could be regarded as a final test for feasibility. The system was tested by the development manager at Intex, as well as a two other employees. The testing was extremely useful, as they were able to make suggestions on how to improve the system. For example, suggestions were made about how to improve the efficiency of the system. Rather than retrieving two recordsets from the database and populating the grid, the recordsets could be retrieved and populated individually. This will be quicker and more efficient for large databases.

38 The users also mentioned that the name of the user was not entirely obvious when amending holiday and absence details. This is particularly important for managers as it needs to be clear which employee details they are confirming. This has been taken into account and the forms now show the name of the employee at the top as shown in figure 6.1. In addition, the manager has asked for a new functionality to be added. He has requested a new menu item which allows him to enter new employee details and assign a username and password to that employee. Though this was not in the initial specifications, it is a valid function and will be added to the system. Other errors discovered during testing include the calculation of the total number of days and invalid dates. These have been taken into account and some of the changes have been made. The user interface was also tested at Intex. The main window opened properly, but the diary window was too large for the screen being used so not all the items were visible. As a result, the window could not be resized and changes had to be made in the code. This has now been resolved and all the items are visible. The company have decided that the new systems will not be run in parallel with the current one. They have decided to use a direct changeover. Though this may be risky, the company has good confidence in the new system. This method will be fast and will require minimum duplication of work.

39 6.4 Summary It is clear that exhaustive testing is not possible (Pressman, 1997), and so a combination of testing methods were used. This chapter has helped identify some of the errors in the code and in the interface design. Testing is by no means complete and will continue even when the system is in use.

40 7 Evaluation As the project progressed, a number of issues arose, which led to a change in design and a number of delays. This chapter highlights the objectives previously stated in section 1 and evaluates the final system against these objectives. The system will also be evaluated against other factors which have been identified as important. 7.1 Evaluation against objectives As stated in section 1, the objectives are as follows. Acquire a complete program specification from the company. Design the database structure to be used. Implement the program. Install the program and use it within the company. Provide full documentation for the company. During the early stages of the development, the requirements were obtained from the company. At that point in time, the requirements were thought to be complete, though some changes have been made to them since. These were discussed in section 6. A good database structure was consequently established from the requirements and these are in section 4. The design was then implemented and tested by both the author and the users at Intex Software. The suggestions made during the testing have been taken into account and some of these changes have been made to the software. However, due to time constraints, not all these changes have been done as yet. These changes will be made, so that the program installation can proceed. Full documentation has been written and will be given to the users upon installation. The documentation is a separate deliverable and is included alongside this report.

41 In conclusion, all these objectives have been met, except that the system has not been installed at the company. This will take place within the next two weeks. 7.2 Evaluation Criteria In addition to the objectives, several factors will also need to be considered when evaluating the system. Compatibility with existing hardware and software - Whether or not the system works on the existing hardware. Can files created in the package be exported to other systems in the company? Quality of documentation - Whether or not a manual is supplied. Quality of printed reports How useful are the reports and the information extracted from the system? Ease of use/ learning Is it easy to use, e.g. menus, icons, helpful error messages etc? Speed - The speed at which the system carries out critical operations. These criteria have been given a weighting on which they will be evaluated, as shown in table 7.1. Feature Weighting Compatibility 35 Quality of documentation 15 Quality of printed reports 10 Ease of use/ learning 25 Speed 15 Total 100 Table 7.1 Evaluation criteria

42 Compatibility is the most important criterion. The system will not be useful to the company if they cannot use it with their current hardware and software. This was the main reason for requesting that a system be written specifically for them. It is also important that the system be easy to use and easy to learn. The employees will have their current workload to deal with and would appreciate an easy system that does not require extensive training. The quality of the documentation is vital. Users will be provided with a manual so that they can learn to use the system quickly and effectively. The speed of this information retrieval will also be important. It does not seem worthwhile to have a system that is compatible with the company hardware, yet takes several minutes to load or even access holiday details. The printed reports should be of a high quality so that users can retrieve and view the relevant information from the system. For example, users may want to know the number of holidays they have taken in a specific month. 7.3 User & personal Evaluation Though the system has not yet been installed in the company, the users have expressed their desire to use the system. During the testing stage, some suggestions were made to improve the system. These have been taken into account and most of the changes have been completed. The manager intends to have the system installed and operational once the changes are made (Appendix J). The users were also able to score the system against the criteria set out in table 7.1. The results of this are shown below.