Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Module Support Management System David Goodwin BSc Computing 2004/2005 The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) _______________________________ Summary In Leeds University’s School of Computing postgraduates are employed to assist module leaders with their work load. The process involves allocating postgraduates to module work based on the skills they possess. The current method of doing this is entirely paper based and is not very efficient. The project’s purpose was to produce an electronic version of the system allowing data entry via webbased forms. The project required gathering the user requirements, analysing them and producing a design for a prototype system. The prototype was then implemented and tested. This report is a detailed description of all the work done on the project and the methods used. The project was a success in that the aim, objective and minimum requirements were met. The prototype was able to meet the minimum requirements but would require further work to meet all the user requirements identified. I Acknowledgments This section is dedicated to all the people that have helped me in their own special way throughout the project. The first acknowledgment goes out to Stuart Roberts my supervisor. Without his continuous support, advice and general guidance this project would not even exist. Thank you to Charlie Brown for his time, patience and detailed descriptions of the current system. Also thank you to Natasha Shakhlevich for her advice in the progress meeting which I have put to good use. Finally, to my parents who put up with my constant complaining over the Easter holidays a big thank you for being there for me. II CHAPTER 1: INTRODUCTION ........................................................................................................................ 1 1.1 THE PROBLEM .............................................................................................................................................. 1 1.2 AIM ............................................................................................................................................................... 2 1.3 OBJECTIVES ................................................................................................................................................. 2 1.4 MINIMUM REQUIREMENTS .......................................................................................................................... 2 1.5 DELIVERABLES ............................................................................................................................................ 3 1.6 PROJECT SCHEDULE .................................................................................................................................... 3 CHAPTER 2 – BACKGROUND READING ..................................................................................................... 4 2.1 BACKGROUND TO THE PROBLEM ................................................................................................................. 4 2.2 METHODOLOGY RESEARCH ......................................................................................................................... 5 2.3 THE WATERFALL MODEL ............................................................................................................................. 5 2.4 PROTOTYPING .............................................................................................................................................. 6 2.5 THE SPIRAL MODEL ..................................................................................................................................... 7 2.6 METHODOLOGY SELECTION ........................................................................................................................ 8 2.7 TECHNOLOGIES ............................................................................................................................................ 9 CHAPTER 3: ANALYSIS.................................................................................................................................. 11 3.1 ANALYSIS OF CURRENT PROCEDURE ......................................................................................................... 11 3.2 REQUIREMENTS.......................................................................................................................................... 12 3.3 ANALYSING USING SOFT SYSTEMS METHODOLOGY ................................................................................ 13 3.3.1 Rich picture......................................................................................................................................... 13 3.3.2 Root definition .................................................................................................................................... 15 3.3.3 CATWOE analysis.............................................................................................................................. 15 3.4 USE CASE DIAGRAM.................................................................................................................................... 16 CHAPTER 4: DESIGN ...................................................................................................................................... 19 4.1 DATABASE DESIGN ..................................................................................................................................... 19 4.1.1 Entity-Relationship modelling ........................................................................................................... 19 4.1.2 Normalisation ..................................................................................................................................... 21 4.2 INTERFACE DESIGN .................................................................................................................................... 26 4.2.1 Usability .............................................................................................................................................. 27 4.2.2 Colour ................................................................................................................................................. 27 4.2.3 Form designs ...................................................................................................................................... 28 CHAPTER 5: IMPLEMENTATION................................................................................................................ 31 5.1 CONNECTING TO THE DATABASE ............................................................................................................... 31 5.2 MODIFYING THE DATABASE ....................................................................................................................... 31 5.3 WRITING THE CGI SCRIPTS ....................................................................................................................... 32 5.3 THE ALLOCATION REPORT......................................................................................................................... 33 III 5.4 PROBLEMS ENCOUNTERED ........................................................................................................................ 35 5.5 SOURCE OF FORMS ..................................................................................................................................... 36 CHAPTER 6: TESTING .................................................................................................................................... 37 6.1 WHAT IS TESTING?..................................................................................................................................... 37 6.2 TYPES OF TESTING ..................................................................................................................................... 37 6.3 TESTING THE CODE .................................................................................................................................... 37 6.4 TESTING THE SYSTEM ................................................................................................................................ 37 6.5 TESTING THE FUNCTIONS ........................................................................................................................... 38 6.6 MEETING THE USER REQUIREMENTS ........................................................................................................ 39 6.7 USER WALKTHROUGH ................................................................................................................................ 39 6.7 .1 Skills form.......................................................................................................................................... 39 6.7 .2 Modules form..................................................................................................................................... 40 6.7 .3 Postgraduates form............................................................................................................................ 40 6.7.4 Report form......................................................................................................................................... 40 CHAPTER 7: EVALUATION........................................................................................................................... 41 7.1 EVALUATION CRITERIA.............................................................................................................................. 41 7.2 IS THE SYSTEM PRAGMATIC?..................................................................................................................... 42 7.3 IS THE SYSTEM USEABLE? .......................................................................................................................... 42 7.4 IS THE SYSTEM RELIABLE? ........................................................................................................................ 42 7.5 IS THE SYSTEM METAMORPHIC?................................................................................................................ 42 7.6 METHODOLOGY USE .................................................................................................................................. 43 7.7 TIME MANAGEMENT .................................................................................................................................. 43 7.8 COMPARISON WITH EXISTING SOLUTIONS ................................................................................................ 43 CHAPTER 8: THE FUTURE ............................................................................................................................ 45 8.1 FUTURE EXPANSION ................................................................................................................................... 45 8.2 FUTURE IMPROVEMENTS ........................................................................................................................... 45 REFERENCES: .................................................................................................................................................. 46 APPENDICES ..................................................................................................................................................... 48 APPENDIX A -REFLECTION ................................................................................................................................ 48 APPENDIX B – ORIGINAL TIME SCHEDULE ......................................................................................................... 50 APPENDIX C –ACTUAL TIME SCHEDULE ............................................................................................................. 51 APPENDIX D – POSTGRADUATE REQUEST FORM ................................................................................................ 52 APPENDIX E – WORK ALLOCATION FORM .......................................................................................................... 53 APPENDIX F – PAYMENT CLAIM FORM ............................................................................................................... 54 APPENDIX G – SCREENSHOTS ............................................................................................................................ 55 IV Chapter 1: Introduction 1.1 The problem Leeds University’s School of Computing offers a wide variety of modules for all the different degrees it caters. The module leaders often require additional assistance to cope with their large workload of running these modules at degree level. Assistance is acquired through employment of postgraduate students who have accomplished academic skills covering those required of the modules. Students that are undertaking modules are often given the opportunity to attend laboratory sessions where they are able to seek advice and receive help with their current coursework. Demonstrations may also be given by these employed postgraduates who run the sessions. Another task for which they are employed is that of marking. The amount of marking for just one module is quite considerable with possibly over a hundred attending students, each submitting more than one piece of coursework. In order to give the student the best possible feedback the coursework must be marked quickly and accurately. It is essential that the right postgraduate is matched to their task. A postgraduate who does not possess the required skills will be inadequate at performing their job. Problems may also occur if a postgraduate dislikes a certain programming language and is then allocated to hold a lab session for a piece of coursework based on that language. When applying for employment the postgraduates are encouraged to specify their likes and dislikes as well as their experiences and preferences. There is also a limit to the number of hours one postgraduate can work for. The module tasks are all defined in timescale by hours. Coursework marking has a recommended number of hours for completion whereas demonstrating will have a specified number of hours required. More than one postgraduate can work on a particular task for a module and modules can have more than one task. The current system utilises a mixture of paper-based resources and manually updated databases. Transferring information from paper to electronic form is time consuming and doesn’t make full use of technology presently available. Although the system does work it is not very efficient being a slow and messy procedure. Paper records are easily lost and are difficult to keep organised. Problems also occur with the collection of paper-based information within deadlines. This leads to essential information being omitted and not recorded. 1 Completely automating the process electronically will hopefully improve efficiency, by speeding up and improving the process organisation for entry and retrieval of data. Keeping to deadlines should be easier using electronic submission instead of pieces of paper. Data will not be lost as easily. It can be stored within a database in an orderly fashion. Transferring of data can all be done electronically and keep redundancy of data to a minimum. 1.2 Aim A definition of the project’s aim is: “To produce a system that allows the entry of module support requirements and postgraduate availability via a web based interface. The storage of the data in a database for later manipulation. All done using the existing SIS system.” 1.3 Objectives The objectives of this project include: • To understand the problem • To research into the current procedure and analyse • To interview the main users of the system and gather requirements • To decide on an appropriate methodology to use • To design and implement the database • To design and implement web based data entry forms • To design and implement data reports • To test the system • To evaluate the system 1.4 Minimum requirements The project’s minimum requirements are: • Produce a summary of the existing processes for capturing module support data and the efficiency of these processes. • Gather and analyse requirements and produce a specification of a new system. • To design and build a relational database that will store information on modules, postgraduates and their periods of availability. 2 • Design and implement web-based data entry forms. • Design and implement at least one report. Possible project extensions include: • Automatic scheduling algorithm • Design and implement reports detailing allocations, hours worked and amount spent. • Provide evidence to the university payroll system of the benefits of using electronic forms when dealing with the School of Computing. 1.5 Deliverables • The final project report • Prototype system 1.6 Project Schedule Due to the importance and size of this project the management of the limited time available had to be carefully handled. Different sections required varying amounts of time to be spent on them. The workload was balanced so that the majority of it took part in the second semester. The original Gantt chart, see Appendix B, was altered repeatedly due to unrealistic time scheduling, evaluation of how the project was managed and why the time scheduling changed can be found later in the report. 3 Chapter 2 – Background reading 2.1 Background to the problem Before a system could be built to solve the problem, background research had to be conducted. To fully understand the problem it was decided that meetings should be held with the people most associated with the current procedure. The purpose of the meetings was to gather as much information as possible about the current procedure and any problems that have arisen from using it. From the information gathered user requirements for a new system could be created. These would be used as the starting blocks for the system design. A meeting has the advantage of being bidirectional. New questions that arise can be put forward from both sides and answered immediately without the delay normally associated with methods such as email. A meeting is also more intimate and can be both formal and informal depending on the situation. It was very important to plan and structure the meeting in order to get the best possible result. They were treated as informal interviews with a set of questions prepared beforehand. The Allocation Officer is the person directly responsible for the allocation of postgraduates to module support. He holds the major role for the current procedure and without him there would be no procedure. He also understands, in intricate detail, the processes that occur in the procedure. All of this qualifies him as an ideal source for information gathering. Documentation of the results of the meeting included a detailed description of the current procedure. From this an analysis of the procedure was produced which currently resides in section 3.1 of this report. The analysis highlighted the problems with the system. These problems included the fact that the procedure is currently a mixture of paper-based resources and manually updated databases. The movement of data between the two mediums causes both time and efficiency problems which becomes a serious concern when strict deadlines have to be met. To combat the problem it has been concluded that a completely electronically based system would be beneficial in numerous ways. The proposed solution should hopefully simplify and increase the efficiency of the Allocation officer’s current job. The findings of the meeting deduced that the proposed system would have to be compatible with and implemented using current SIS data. SIS stands for the School Information System, a large relational database of administrative information in the School of Computing. Information it holds ranges from the details of the people within the school to performance statistics, Ainsworth (2004). Research into the technology of SIS was therefore essential. 4 A source for such information could have included any member of the SIS team, a group of people working with and having knowledge of the workings of SIS. The meeting, once conducted, produced documentation of a list of tables currently used in SIS. The list was useful as it could be used to produce a rough idea of the tables required to produce the proposed system. The main tables concerning the project included details about postgraduates and modules. Other information gathered from the meeting included that the database management system Postgres was used for SIS and the language perl was used to access the database. This proved to be useful when the decision needed to be made of the technology to use for the proposed system. 2.2 Methodology research Choosing the correct methodology to create the system is very important. The methodology will decide how to represent the system and ultimately go about designing it. If the wrong methodology is used then problems with the design and implementation may occur. Matravers (2003) states that although there are situations where an information system solution to a problem is obvious, this is not always the case. Matravers (2003) goes on to explain that sometimes the problem situation needs to be explored further to give a better understanding of the process. One way of doing this is using Soft Systems Methodology (SSM). Unlike a hard approach which concentrates on the technical side, SSM explores the social processes. Eva (2004) reveals that SSM does not represent strict steps that have to be followed but instead a loose framework of techniques. “It is based on systems thinking, which enables it to be highly defined and described, but is flexible in use and broad in scope,” Checkland & Scholes (1990). Once the problem has been clearly defined a hard approach can then be used to find a solution. The analysis of the meetings findings has explored the problem in greater depth. It has revealed its increased complexity and scope resulting in new factors having to be taken into account, making SSM more relevant. To complement the findings of the SSM analysis techniques a hard system methodology was required. Research into the different types was undertaken to find the best one for the proposed system. 2.3 The waterfall model According to Beauchemin (2000) the waterfall model was the first model in systems development to have a structure. It is linear, with the stages following a sequential order. Supremisitc (2005) explains the origin of the name. In a waterfall the water has no choice but to fall once it has gone over the edge. 5 It’s the same with each stage, once one is complete its time to go on to the next. Progress only flows in one direction so there is no going back. Although sources differ with their choice of names for each stage, the basic structure includes analysis, design, implementation, testing and evaluation as shown in figure 1. The arrows represent the flow of progress. Analysis Design Implementation Testing Evaluation Figure 1, Waterfall model Supremisitc (2005) states that one advantage of the waterfall model is its strictness, this allows a schedule with deadlines to be set. These deadlines must be met allowing a timescale of the project to be given. However, like every methodology the waterfall model also has its disadvantages “The disadvantage of waterfall development is that it does not allow for much reflection or revision”, Supremisitc (2005). This means that if something occurs that affects a stage that has already been completed it is not possible to go back and modify that stage. Therefore it is important that the stages are well thought out before the process starts. 2.4 Prototyping If requirements for the system are not fully understood when starting the project then Beauchemin (2000) advises using a prototyping model. This involves creating a prototype for the system, letting the users try it and then collect the feedback. This feedback could then be used to build an improved prototype. The process continues until the requirements are fully understood and the system can then be implemented. Figure 2 shows the different stages and how they relate according to Beauchemin (2000). Unlike the waterfall model progress does not just travel in one direction as stages can be revisited. Beauchemin (2000) warns that developing the system too quickly can lead to bad choices and design. Customers can also be mislead by the prototype and assume the system will be produced sooner than it actually will. 6 Collect requirements Design prototype Create/Modify prototype Assessment of prototype by users Implementation of system Figure 2, Model representation of prototyping 2.5 The Spiral model “The spiral model is a combination of the best features of both the waterfall model and prototyping”, Beauchemin (2000). Beauchemin (2000) expands further by explaining that the spiral model uses the method of repeatedly modifying the system until it reaches the clients expectations. However, each iteration makes use of the waterfall methodology. Risk assessment is a new feature that has been included which assesses the risk and decides whether it is wise to continue. Figure 3 taken from Boehm (1998) shows the spiral model in detail. According to Beauchemin (2000) the spiral model consists of four stages: • Objectives of the project – where objectives are determined and different approaches are considered. • Risk assessment – using the risk assessment the different approaches are evaluated. If continuing is worth the risk an approach to use is identified. • Engineering – the prototype is implemented • Planning and management – the user tests the prototype and provides feedback 7 The problem identified by Beauchemin (2000) is that due to the large number of steps the model consists of any delays become a serious issue. Figure 3, The spiral model 2.6 Methodology selection Evaluating each methodology in turn gives a clearer understanding of which is the most suitable. It has already been made clear that soft systems methodology techniques will be used to analyse the process to give a clearer view of the problem situation. However after the process has been fully analysed the results will be used to proceed with a hard methodology. The waterfall method is an attractive methodology if the requirements have been collected early on in the project, however it does not allow much room for error. If the implemented system is not to the standard the users would like it there is no room for improvement. The prototype method allows for repeated improvement of the system however it is time consuming and requires the design of the system to be created fairly quickly in the project. The spiral method is very time consuming and complex so is therefore not suitable for a project of this size. 8 As tine is of the up most importance for this project it makes sense to use the waterfall model. It will allow time for one iteration. The SSM will ensure that the analysis for the system is fully completed before the methodology continues hopefully reducing the chance of the system not reaching the users’ standards. 2.7 Technologies There are various methods of storing the required data. The documentation of the meeting with the allocation officer determines that the current solution uses a manually updated database to store the existing postgraduates. It reveals to be practical to use a database to store all details about both module requirements and postgraduates. Research shows that a database management system (DBMS) is required and that the three main contenders in the field are Oracle, PostgreSQL and MySQL. “The DBMS is hence a general-purpose software system that facilities the processes of defining, constructing and manipulating databases for various applications”, Elmasri & Navathe (2000). MySQL (2005) compares the features of the different DBMSs and shows their different capabilities. Features that are important to this project include being able to store a variety of different data types. Other areas that are relevant to the project are integrity constraints, access, and licence cost. Figure 4 is a table using the data from MySQL (2005) showing the features required for the system and if they are supported by the different DBMSs. Boolean data type is an important data type as is date which will be required for storing postgraduate availability. Access is important especially if in the future the system is implemented with SIS. Finally and most importantly the DBMS should be free to use. Features MySQL Oracle PostgreSQL Data type: Boolean Yes No Yes Data type: Date Yes Yes Yes Primary keys Yes Yes Yes Foreign keys No Yes Yes Set access privileges No Yes Yes Views No Yes Yes Licence cost No Yes No Figure 4, DBMS comparisons Vita Voom (2004) also shows comparisons between the DBMSs. The source claims that MySQL is slower and less efficient than PostgreSQL and that Oracle’s licence fees are very expensive. The meeting with the SIS team member revealed that the SIS currently uses Postgres so any data provided 9 would be in the form of a Postgres database. Taking everything into account it proves to be practical to use Postgres as the DBMS for the system. Research into PostgreSQL is essential. PostgreSQL (2005) explains that PostgreSQL is based on Postgres. It has all the same features as Postgres and more, yet still remains free. The query language has changed from PostQUEL to SQL making it even more favourable towards anyone who has a brief understanding of SQL. It would save them from having to learn a brand new query language. In order to use SQL properly and efficiently, revision of the topic is required. Refsnes Data (2005) gives a detailed tutorial on how to use SQL. Teorey (1990) discusses data modelling and design in detail which is essential for making the project’s database as efficient as possible. For the different users to enter their data into the database some sort of method is required. As all users will have access to the Internet, it deems feasible for it to be web-based. A website on the method and tools of web-based databases, Rittenhouse (2002), reveals the different ways to introduce web-based data entry forms. Rittenhouse (2002) explains that for dynamic web pages a common gateway interface (CGI) is required. The CGI script would have to be written in a programming language. Documentation from the meetings with the SIS team reveals that SIS uses perl with embedded SQL. As, according to Vita Voom (2004), PostgreSQL is compatible with many different languages such as Python, Perl and C++ it becomes a matter of the advantages and disadvantages of each. Perl would involve anyone who has previously programmed in both python and C++ before to learn a completely new language. However along with the tables of their data, SIS may also provide examples of perl scripting to connect a web page to SIS. The possibility that the project could be implemented with the SIS system sometime in the future makes it feasible to use perl to script. 10 Chapter 3: Analysis 3.1 Analysis of current procedure By the end of August the allocation officer has to have collected information about who is teaching what and when. This involves the lecturer, the name of the module including the module code which uniquely determines the module and the semester the module falls within. After the basic information about the modules has been collected the allocation officer needs to know the support requirements in detail. This involves the number of hours and postgraduates required. Date schedule for coursework including the deadline date for the students and the date by which it has to be returned to them by. All this information is currently collected by module leaders by either notifying the allocation officer by word of mouth or in writing. At the start of September the allocation officer starts collecting details about the postgraduates available for employment. The allocation officer has a database of postgraduates that have been employed in previous years. To find out about new postgraduates, paper based forms are provided that must be completed and returned by a strict set deadline. See Appendix D for an example of the form used in 2004. This form allows postgraduates to define their preferences for the type of work and their particular skills including their expertise and enjoyment. The next step involves allocating the postgraduates to the modules. A set number of hours are given to a postgraduate to work for a module. A paper based form is given to both the postgraduate and module leader to inform them of the allocation. See Appendix E for an example of the form used. As the postgraduates will be employed by the University’s School of Computing registration within the payroll system is required. This involves completing various forms such as registration documents, student income tax forms and bank transfer forms. Postgraduates must also provide a photocopy of a valid type of identification including passport or birth certificate. All of this must be returned to the allocation officer before the end of October. Postgraduates must register each year despite possible previous employment by the School. Postgraduates are paid three times a year, at the end of each term. Before they are paid they must prove they have completed the work allocated to them. This is done via a postgraduate claim for payment paper based form. See Appendix F for an example of the form. The form which has a submission deadline requires a signature of the module lecturer agreeing to the number of hours claimed. The allocation officer then collects and sends the pay claims to the pay roll section. 11 At the end of the year, between the months of June and July, the allocation officer and the director of learning and teaching analyse and summarise the whole procedure. This involves the total cost of employment and the total number of hours worked by the postgraduates. 3.2 Requirements Resulting from the meeting with the SIS team member it is known that the School of Computing holds PostgreSQL databases on a variety of subjects including postgraduates and modules. Although no electronic system currently exists for the procedure of employing postgraduates, the director of learning and teaching had proposed to the allocation officer that one be built. A list of general and user requirements were proposed. The requirements have since been modified, added to and agreed upon with the different users of the system and are recorded below: General requirements 1. The system to be based on SIS. All the allocation and hour details to be recorded on SIS. SIS data on postgraduates and modules to be available for input to the system. 2. For security aspects only module leaders can update hours worked for their own modules. Only postgraduates can enter their own details. 3. All viewing and modifying to be done over the School intranet. User requirements The following requirements are split into the different users of the system. Module leaders 1. Be able to specify the details of the support they require for their module. This includes type of work, number of hours, number of postgraduates and particular expertise. 2. For the coursework specify a schedule including the deadline date and date of return. 3. View the support allocated to their module. 4. Be able to update the hours worked by a postgraduate for their module. To be used as claim for payment. 5. View the hours remaining of allocated work for their module. Postgraduates 1. Be able to register their availability for work. 2. Be able to register their skills and their level of expertise and enjoyment.. 3. View their allocation details. 4. View the hours remaining of their allocated work. 12 Allocation officer 1. Allocate postgraduates to requests of support. Including checking against availability and checking hours allocated against hours requested. 2. Informing postgraduates and module leaders of completion of allocation and details of allocation. 3. Ensure all tasks are completed by the deadlines set. 4. View all allocations 5. View total hours worked by all postgraduates. 6. View total amount spent to date. Director of Learning and Teaching 1. View all allocations 2. View total hours worked by all postgraduates 3. View estimate of total amount committed 4. View total amount spent to date 3.3 Analysing using Soft Systems Methodology Peter Checkland’s Soft Systems Methodology involves seven stages. The first few stages consist of changing an unstructured problem to a structured problem. The way of doing this is by first, collecting as much information as possible about the problem and then trying to understand it. The process can only continue once the problem is fully understood. The problem is further analysed using a rich picture which is a way of representing the problem situation in a graphical format, Kremer (2001). “Rich pictures are used to provide a model for thinking about the system and to help the analyst to gain an appreciation of the problem situation”, Couprie et al (2004). There is no true structure to drawing a rich picture. They usually include people, also known as actors, who are directly involved in the situation. The actor’s wants are normally drawn in thought bubbles above them. The rich picture may also show any processes or transaction that take place between the actors and any conflicts that may occur, Jarvis (2004). 3.3.1 Rich picture Figure 5 shows the rich picture for the current situation of employing postgraduates and allocating them to module support requests. The conflicts that occur can not all be resolved in the system to solve the problem. This is mostly due to university payroll being outside of the aim of the project. The payroll is a large and complex system that would require time and expertise that is not available. The 13 payroll system has been included as it is part of the extended problem but it will not be dealt with in the project. Conflict: Allocation Officer v Module Leaders Conflict: University Payroll v Conflict: DoLT v An automatic allocation algorithm may speed up Postgraduates Postgraduates and simplify the process for the Allocation Postgraduates requiring a quick The DoLT requires trained Officer but it may not match the best PG for the payment could conflict with the Postgraduates for the jobs. job required. This could result in poor quality University Payroll system’s Untrained Postgraduate would work results for the Module Leaders. current process. then find themselves unable to get work. Figure 5, Rich picture of the current situation 14 3.3.2 Root definition After clarifying the situation, the next stage is to design a system that can act as a solution to the problem. A description of the system is required which is acquired using a root definition. The root definition is a short paragraph, describing why the system is being built, what it does and how it does it, Kremer (2001). As this project is concentrating on the allocation process, only this part of the situation will be represented via a root definition. The root definition is as follows: “A module support management system to enable data entry by conventional web-based data entry forms, for module support requirements and postgraduate availability in keeping with the existing SIS system, in order to allocate support where requested in the most efficient way.” What the system will do: “enable data entry… for module support requirements and postgraduate availability”. How the system will do this: “by conventional web-based data entry forms”. Why the system will do this: “in order to allocate support where requested in the most efficient way”. 3.3.3 CATWOE analysis To analyse the root definition a mnemonic known as CATWOE is used. This is composed of six different elements that are important to the system. CATWOE and root definitions normally go handin-hand as they are used together to help produce an accurate system, Couprie et al (2004). The following table shows the mnemonic CATWOE in relation to the proposed system. Acronym C What it stands for Customers What it means in The answer in relation to the relation to the system system People who would Undergraduates benefit from the system. A Actors Those who would Allocation Officer, actually do Director of Learning something in the and Teaching, system Postgraduates, Module Leaders 15 T Transformation What are the input Requirements and process and outputs of the availability give system? allocation. Allocation and money spent gives reports. W World view Why is the system Modern improved being built? SIS data makes this feasible O Owners Who has control and Director of Learning could stop the system and Teaching from happening? E Environmental Elements outside the Technology of SIS Constraints system that limit the database. capabilities of the University payroll system. system. Table 1, CATWOE analysis of system 3.4 Use case diagram It should be possible to build upon the soft systems methodology analysis to help produce Use case diagrams of what the system will do in detail. The diagrams will indicate exactly what each actor will do within the system based on their requirements. Figure 6 shows the Use case diagram of the proposed system, the requirements have been taken from the user requirements that have been collected. Each user of the system is represented by an actor in the diagram. It should be noted that in both the CATWOE analysis from table 1 and the Use case diagram of figure 6 the university payroll system does not play a part as an actor. The payroll system is part of the overall system as it pays the postgraduates. However, it is not classed as a user of the system being built for the project as it is more of an external factor and beyond the capacity of this project. Use case diagrams give more of an idea of the users’ requirements and how they interact with other users of the system. More detail is given about each requirement for each user specifying exactly what will happen in the process. 16 Register View all registered availability information Register skills Allocate and expertise postgraduates to support requests Allocation Officer Postgraduates View allocation details View hours View total hours remaining of worked by all allocated work postgraduates Update hours Module leaders worked by View total Director of postgraduate amount spent Learning and Teaching Register module support requests Figure 6, Use Case diagram of proposed system. Postgraduates • Register availability – The postgraduates will actually enter their periods of unavailability. This is because postgraduates are assumed to be available all year round. Periods of unavailability may include holidays and will have a start and end date. • Register skills and expertise – Postgraduates will choose from a list skills that they have. They will then give a rating, out of 5, for their enjoyment and expertise of that particular skill. They will also be able to enter a preference of work, either demonstrating or marking. Module leaders • Register module support requests – Once the support requests for the module are known, the module leader will be able to enter the details for various module tasks. These will include the 17 type of task, marking or demonstration, the number of postgraduates required, a brief description of the task, the number of hours it will take and any skills required to perform it. It will also have a start and end date. • Update hours worked by postgraduate – The module leader will be able to update the number of hours that the postgraduate has worked for that particular module once the postgraduate has done the work. Postgraduates and Module leaders • View hours remaining of allocated work – Both the postgraduate and module leader will be able to view how many hours of work remain for the postgraduate allocated to the module leader’s module. Allocation Officer • View all registered information – The allocation officer will be able to view all the module task details that have been entered and all the postgraduate details. • Allocate postgraduates to support requests – With all the details available to view the allocation office will be able to match the postgraduate to the module. This will be based on the skills required by the module’s tasks matching the skills of the postgraduate. It will be a manual process completed by the allocation officer with the postgraduate’s skills enjoyment, experience and preference all taken into account. Allocation Officer and Director of Learning and Teaching • View total hours worked by all postgraduates – Both of the allocation officer and the director will be able to view a summary of the total number of hours worked by all the postgraduates for all the modules. • View total amount spent – Using the hourly rate paid by the University it will be possible to display the total amount spent to both the allocation officer and the director. All users • View allocation details – All the users of the system will be able to view the allocation details that concern them. In the case a postgraduate it would be the allocation details involving themselves. Whereas a module leader would be able to view the allocation details involving their own module. Both the allocation officer and director of learning and teaching would have access to view all the allocations made involving all postgraduates and modules. 18 Chapter 4: Design 4.1 Database Design As it has been decided that all information will be held in a PostgreSQL database it is important that the database is designed well. The database should be designed so that the tasks performed upon it are efficient, fast and correct. This means that data should not be unnecessarily stored more than once and the relationships between the tables are correct. 4.1.1 Entity-Relationship modelling According to Holding (2000) an important tool for designing tables in a database and the relationship between them is entity-relationship modelling. Holding (2000) claims that entity-relationship modelling is made up of two parts. The first part is the list of items and events stored as information in the system. The second part is the relationship between the items and events which is shown using an entity-relationship diagram. From the analysis in Chapter 3 the following items of information need to be stored in the database. Module support requests, in the form of tasks, and postgraduate availability. From these it becomes apparent that both module and postgraduate details also need to be stored. The actual allocation details would be required to be stored in the database so they can be accessed and viewed. Finally, the skills are the important information that the allocation will be made upon. The skills that are required by the module tasks, and those that the postgraduates may possess, will be selected from a stored list. Holding (2000) describes the items as entities, which in themselves hold more information. The relationships between the entities vary. Holding (2000) states that there are three different types of relationships one-to-one, one-to-many and many-to many. The following relationships occur between the entities for the proposed system and are shown using an entity relationship diagram. One postgraduate can enter many periods of unavailability. A postgraduate’s unavailability slot is unique to that postgraduate so this is a one-to-many relationship. Postgraduates 1 N Postgraduate unavailability Figure 7.1 ER diagram for postgraduates and their unavailability One module can register many support requests known as module tasks. A module’s task is unique to that module. This is also a one-to-many relationship. 19 Modules 1 N Module Tasks Figure 7.2 ER diagram for modules and their tasks A postgraduate can possess one or more skills. A skill can be possessed by one or more postgraduates. This makes it a many-to-many relationship. Postgraduates M N Skills Figure 7.3 ER diagram for postgraduates and their skills A module task can require one or more skills. A skill can also be requested by more than one module task. This is also a many-to-many relationship. Module Tasks M N Skills Figure 7.4 ER diagram for module tasks and skills Originally it was assumed that postgraduates would be allocated to individual module tasks in the database. It was decided this was an inefficient and complex method. The solution was to allocate the postgraduates to the modules whose tasks requests they met. A postgraduate would then be associated with that module and perform all the tasks for that module. A postgraduate would be able to work for one or more modules and one or more postgraduates would be able to work for one module. Postgraduates M N Modules Figure 7.5 ER diagram for postgraduates and modules. Holding (2000) informs that many-to-many relationships cannot be built in a database. The solution is to transform the relation into two one-to-one relationships with a new entity between them. The new entity will hold both primary keys of the other two entities. Module Tasks M Module N Skills skills Figure 7.6 Revised ER diagram for module tasks and skills 20 Postgraduates M Pg N Skills skills Figure 7.7 Revised ER diagram for postgraduates and skills Postgraduates M Allocation N Modules Figure 7.8 Revised ER diagram for postgraduates and modules 4.1.2 Normalisation The entities will become tables in the database and they will require columns called attributes to store information. The SIS already holds existing data on postgraduates in a table called rs_student and module details in a table called ts_module_detail. The primary keys are stu_num for the postgraduates and module_code, year and semester for the modules. As extra columns are required to be stored in the postgraduate table a new table will be built which will be designed so that information from the SIS table can be referenced. The ts_module_detail table will be used directly for module details. Holding (2000) describes a second method of database design called normalisation. In a series of steps and rules it is possible to improve the quality and efficiency of the database. The three main stages of normalisation are first, second and third normal form and are described by Holding (2000) as follows: First normal form – If there are several rows where the same group of column data is repeated remove the columns and place them in new tables. Give each table a primary key column to uniquely identify each row. Any table’s column that references another table’s primary key becomes a foreign key. Second normal form – With a multi-column key table remove any other columns that depend on only part of the key. Place these columns in a different table. Third normal form – Remove any columns from a table that are not dependant on the key and place them in a new table. Also do the same for any columns that are dependant on other columns that are not the key. 21 Using the background reading, analysis, SIS tables and normalisation rules the following table designs were formed. For the data types and check constraints the PostgreSQL website documentation PostgreSQL (2005) was referred to on a regular basis. The primary key for each table is highlighted in bold whilst any foreign keys are indicated by an asterisk. Table: Postgraduates Column name Description Data type stu_num* student unique number character varying(10) pref_demonstrating preference for demonstrating boolean pref_marking preference for marking boolean pref_admission preference for admission boolean Check constraints visits hours_avail number of hours available for numeric(5,2) work Figure 8.1 Postgraduate table design In figure 8.1 the preference for admission visits has been added as it is used on the original form and could be used if the system was expanded, see Appendix D. The data type numeric (5, 2) is a variable 5 integers long of which 2 are decimal places, PostgreSQL (2005). The student number, stu_num, is also a foreign key as it references the column stu_num in the table rs_student from the existing SIS system. As SIS holds all the postgraduates this ensures only legitimate postgraduates can store their details. The ts_module_detail table from SIS will be used as it holds everything required. The primary key is made up of a module_code, year and semester. The module_code is of a length of up to 12 characters long whilst both the semester and year are small integers. Table: pg_unavailability Column name Description Data type unavail_id a unique number for ID SERIAL s_date start date date e_date end date date stu_num* student unique number character varying(10) Figure 8.2 postgraduate unavailability table design 22 Check constraints The SERIAL data type in figure 8.2 ensures that each time a new record is formed the unavail_id increments by one. The foreign key stu_num references stu_num in the postgraduates table to ensure only postgraduates that have registered their details can enter their unavailability periods. Table: module_tasks Column name Description Data type mt_id a unique number for ID SERIAL type type of task text Check constraints Demonstrating or Marking hours number of hours the task will numeric(5,2) take to complete pg_required number of postgraduates integer required for the task description a brief description of the task text d_start start date date d_end finish date date module_code* module unique code character varying (12) year* The year the module is held small integer semester* semester of study small integer Figure 8.3 module tasks table design The check constraint in figure 8.3 ensures only the specified values can be entered for that field. For type admission is not stated as module tasks do not include admission visits. For demonstrating both the start date and finish date will be the same. For coursework marking the start date will indicate the deadline date for the students, when the postgraduates will get the work to mark. The finish date will indicate the date it has to be given back to the students. The foreign key is made up of three parts all referencing ts_module_detail table from SIS. Table: skills Column name Description Data type skill_id a unique number for ID SERIAL name short description of skill character varying (30) Figure 8.4 skills table design 23 Check constraints Figure 8.4 shows the skills table where the primary key is the skill_id given to each skill description. Table: module_skills Column name Description Data type mt_id* module task id number integer skill_id* skill identification umber integer Check constraints Figure 8.5 module skills table design In the module skills table in figure 8.5 the mt_id and skill_id columns are both primary and foreign keys. This is due to the table being used in the middle of a many-to-many relationship between module tasks and skills. The mt_id column references the mt_id column in module tasks whilst the skill_id column references the column skill_id in the skills table. Pg_skills in figure 8.6 and allocation in figure 8.7 are similar types of table. Table: pg_skills Column name Description Data type Check constraints stu_num* Student unique number character varying (10) skill_id* skill identification number integer enjoyment the postgraduate’s enjoyment integer A value between 0 and 5 integer A value between 0 and 5 of the skill experience the postgraduate’s experience of the skill Figure 8.6 postgraduate skills table design In figure 8.6 the stu_num column references the stu_num column in the postgraduates table. The skill_id column references the skill_id column in the skills table. Both enjoyment and experience use a check constraint to ensure that the value for their fields is between 0 and 5 inclusive. 24 Table: allocation Column name Description module_code* Module unique code Data type Check constraints character varying (12) year* the year the module is held small integer semester* semester of study small integer stu_num* Student unique number character varying (10) hrs_allocated number of hours allocated to numeric(5,2) postgraduate for the module hrs_claimed number of hours claimed by numeric(5,2) postgraduate for the module verification verification of hours claimed boolean by postgraduate Figure 8.7 allocation table design In figure 8.7 the module_code, year and semester columns reference the columns of the same names in the ts_module_detail table. The stu_num column references the stu_num column in the postgraduates table. The verification field will be filled in by the module leader to verify the hours claimed by the postgraduate so that they can be paid. Figure 9 shows the completed ER diagram for the proposed system. The tables are represented by rectangles with the attributes of the tables represented by ovals. The diagram shows how all the tables relate to each other and completes the database design. The database is now ready be implemented in PostgreSQL. 25 Start End Name Stu_num Date Preference 1 Postgraduates N Is Postgraduate unavailability unavailable Hours M Enjoyment unavail_id available Experience N Is Pg Skills allocate Hrs_claimed Skill_id N N Verification M Skills Name Allocation M M Hrs_allocated Module Skills To Semester N Year Modules N 1 Module Tasks Description N Module_code Have Hours Number of Date PG’s required Start Type End Figure 9, Entity relationship diagram of proposed system 4.2 Interface Design Although the system may have a well designed normalised database it is of no use without a well designed interface. There is no point having a place to store information if the users of the system are unable to enter or retrieve the information. The interface design is important as it will be what the users of the system will rely on to make the system work. A poorly defined interface that doesn’t 26 allow information to be entered correctly is useless. On the other hand an interface that does exactly what it should but is hard to use or time consuming will put off prospective users. An interface should be easy to use and well presented requiring the least amount of time and effort as possible. This is difficult to achieve and extensive research into the subject is required. 4.2.1 Usability Jacob Nielsen is well-known for his work with usability on web sites. He has produced an effective method for testing usability known as heuristic evaluation and guidelines for producing a good user interface, Nielsen (2005). The ten guidelines are as follows: 1. Visibility of System status – the user should always be informed of the current status of the system via regular feedback. 2. Match between system and the real world – the user should not be confronted with unfamiliar language or terms when using the system. 3. User control and freedom – the user should be able to undo any mistakes they make. 4. Consistency and standards – the user should find the layout and processes consistent. 5. Error prevention – the user should find it as difficult as possible to make a mistake and cause an error to occur. 6. Recognition rather than recall – the user should not have to rely on their memory, everything should be clearly presented before them. 7. Flexibility and efficiency of use – the different users’ levels of expertise should all be catered for. 8. Aesthetic and minimalist design – the user should only have to view information that is relevant to them. 9. Help users recognize, diagnose, and recover from errors – in the event of an error the user should be presented with a helpful message explaining the problem and a solution. 10. Help and documentation – the user should be able to access small helpful documentation explaining exactly how things work. 4.2.2 Colour According to Parker (1997) colour has both good and bad points. It can be used to benefit the interface by attracting attention to and emphasising an important part. It can also be useful by helping increase understanding of something by clarifying and simplifying. However Parker (1997) warns that colour can be misused. Used incorrectly it can cause the opposite effect leading to confusion and disorder. Too much colour is bad and clashing the colours can lead to problems especially with text. A 27 particular colour font on the wrong colour background can lead to illegible text. A pale blue background with black text is therefore the colour of choice in the designs. 4.2.3 Form designs Three different data entry forms have to been designed: • One for postgraduates to enter their unavailability periods, select skills and preferences. • One for module leaders to enter their module requests. • One for an administrator to enter skills. The three main forms will each consist of many pages for each section of entering data. Each form should allow easy navigation for the required user by highlighting where they are at each stage of the process of entering data and having buttons to allow movement between pages in both directions. The postgraduate form will consist of a starting page, known as the selection page, where the postgraduates enter their unique student number to personalise the data entry process for them. If an incorrect number is entered then access to the data entry pages will not be allowed. Figure 10.1 is the initial design for the starting page for the postgraduate data entry form. It includes a text input box for entry of the number and a button labelled submit to send the number for confirmation. Pgs - selection Enter number: Submit Figure 10.1, Postgraduates selection The next page will be the main menu giving the postgraduates a choice of places to go to and enter data or alternatively log out. Figure 10.2 is rough design of the main menu. The title at the top will give the postgraduate unique number to show which postgraduate is currently entering data. The logout button will go back to the selection page and the form will no longer be personalised. The other buttons go to the respective pages. 28 Pgs – menu for (Pg number) Unavailability Skills Preferences Logout Figure 10.2, Postgraduates main menu If the unavailability button is selected then the postgraduate will be presented with the unavailability menu as shown in figure 10.3. Clicking the view button shows any existing records in the form of a table. If records do exist then new buttons will appear giving the option to sort the records by date or to delete the selected record. The menu button will send the postgraduate back to the main menu whilst the add button will bring up the page where unavailability is entered. The enter unavailability page will allow the postgraduate to select a start and end date using drop down boxes for the day, month and year. Pgs – unavailability for (Pg number) View Add Menu Figure 10.3, Unavailability menu For the skills page, accessed via the skills button on the main menu, the skills entered by the administrator in the skills data entry form will be available to select via a drop down list. To complement the skill selected the postgraduate will also be able to select an enjoyment and experience level from a drop down list. Postgraduates will have the option to add, view and delete skills from their records. The preference page will be the same concept as the skills page but instead of selecting a skill the postgraduate will select their preference choice using drop down lists. They will also be able to enter the number of hours they will be available for. 29 The module data entry form will be similar to the postgraduate form. Like the postgraduates enter their number, the module leaders will enter their module code on the starting page of the module form as well as the year and the semester of the module. It too will lead to a personalised main menu. The menu will give the option of logging out or entering a module task. The module task entry page will consist of drop down lists for the type of task and start and end dates. It will also contain text boxes for the number of hours, number of postgraduates and description. Once the task has been recorded then skills can be added to it on a separate page. This is because a task can require more then one skill. The skills will be selected from a drop down list with its selection coming from the administrator’s skill data entry form. All records will be able to be viewed in the form of a table and be able to be deleted using the delete button. Figure 10.4 shows a design for the task entry page. Enter tasks for (module code) Type Hours Postgraduates Description Start date End date Add Skills Delete Menu Figure 10.4, module task entry page For the skill data entry form that will be used by the administrator, skills will be entered in a text box and once recorded given a unique identification number. The administrator will be able to view all the skills and modify them by adding to them or deleting them. Searching the skills will be possible either by name or unique number. These skills once recorded will be then made available in drop down lists for both postgraduates and module leaders to select in their own forms. 30 Chapter 5: Implementation 5.1 Connecting to the database SIS technical support created a PostgreSQL database on the csweb2 server for the project. It included a list of tables full of existing data from SIS including module details and postgraduate details. They also included links to helpful references such as perldoc CGI and perldoc DBI for using perl to access the database. One link at ~mpc/pub/Perl/DBI/Postgres on the Linux machine led to a file called table_display. The file in question listed how to connect to the database using DBI. “DBI defines a set of functions, variables and conventions that provide a consistent database programming interface for Perl”, Patwardhan et al (2002). The code from table_display was modified slightly and used at the beginning of the CGI scripts to connect to the database. The code is shown below, the name of the database is scs2dag and the host is csweb2. The password has been removed from the code listing for security reasons. use DBI; $drh = DBI->install_driver('Pg'); $db = 'scs2dag'; $username = 'scs2dag'; $password = $dsn="DBI:Pg:dbname=$db"; $dbh = DBI->connect("$dsn;host=csweb2.leeds.ac.uk", $username, $password) or $dbh = DBI->connect($dsn,$username,$password); All the scripts are held on the WWWdev server in a folder called cgi-bin. Permissions are set to allow execution, read and write access. 5.2 Modifying the database Accessing the database is done using the command on one of the School of Computing’s Linux machines: psql -h csweb2 -d scs2dag -U scs2dag 31 The line of code was given by the SIS technical staff. PostgreSQL (2005) explains that psql is an interactive terminal for PostgreSQL. It allows the user to enter queries for the database via a command line and view the results. Initially tables were added to the database and modified using the command line. However, as the tables were constantly requiring modification it became a time consuming and tedious procedure with mistakes occurring frequently. As there were no graphical applications available in the School of Computing another method was sought. PostgreSQL (2005) suggested creating the queries in a text file and then using the command forward slash ’\’ and then the letter ‘i’ followed by the filename. This would run the query just like it would have if the query was typed in the command line interface. This allowed modification of the queries a lot quicker and efficiently as just the text file had to be modified and then run again. PostgreSQL (2005) was the main reference used for creating and modifying the tables as it is detailed yet simple to follow and covers a broad range of methods. Although the tables were created with some check constraints the majority of the validation was done using the perl code. This ensured that incorrect data was prevented from being sent to the database in the first place. 5.3 Writing the CGI scripts Guelich et al (2000) explains some features that are required for the CGI scripts: Each CGI script was written in perl and required a line at the top of the script showing where perl resides on the system: #!/usr/local/bin/perl -wT A perl module called CGI.pm was used to create the CGI scripts. The module has to be called using the code: Use CGI; As CGI is object-oriented a new CGI object is created using the code: $CGI = new CGI(); As the perl is going to produce a HTML page it requires a line of code to notify the browser that it is going to be sent a HTML page: print $CGI->header(); To include HTML in the code various print statements were used which had to be escaped with '\n' due to the use of speech marks. This is the simplest method of including HTML and as large sections of the code were similar, a lot of cutting and pasting was used. 32 Querying the database using DBI involves creating a statement, preparing the statement and then executing it. The statements were made up of normal SQL and the results are returned as rows that were stored in an array using the command: @row = $sth->fetchrow_array The number of rows returned was useful information and was stored in a variable using the code: $rows = $sth->rows The majority of the code involved manipulating the arrays and variables to give the information required and then displaying it in a user friendly manner in HTML. The forms pass data between their HTML generated pages using the POST method. 5.3 The allocation report The report was particularly difficult to implement. It consisted of matching the postgraduates to the module whose task skill requirements they met. A postgraduate can possess many skills and a module can include many module tasks with each module task requiring many skills. For a postgraduate to be considered for a module they must possess all the skills required by the module’s tasks. The problem came trying to find a SQL statement that would bring out the correct results as the join was trying to occur between two link tables pg_skills and module_skills matching on skill_id. Figure 11 is a basic example. Module task of mt_id nine requires skills of skill_id one and two; postgraduate of stu_num 800005 is the only postgraduate who possesses all the correct skills. However a SQL select statement SELECTS stu_num WHERE skill_id = 1 AND skill_id = 2 does not work. pg_skills stu_num module_skills skill_id mt_id skill_id 800005 1 5 2 800005 2 9 1 800004 1 9 2 Figure 11, example of allocation It was finally implemented using nested select statements, an iteration technique in perl and storing values in arrays and variables. The following is a slightly modified version of the actual code created: 33 1 $statement580 = "Select skill_id from module_skills where mt_id =?"; 2 $sth = $dbh->prepare($statement580); 3 $sth->execute($elem5700); 4 $rows5000= $sth->rows; 5 while($row5701 = $sth->fetchrow_array()) 6{ 7 push(@row5702, $row5701); 8} 9 $sth->finish; 10 if (@row5702) 11 { 12 $statement581 = "Select stu_num from Pg_skills where skill_id = @row5702[0]"; 13 $bracket = 0; 14 for (1..$rows5000){ 15 foreach $elem500(@row5702) 16 { $bracket = $bracket + 1; 17 $statement581 = $statement581 . " and stu_num in ( select stu_num from Pg_skills where skill_id = $elem500"; 19 } 20 } 21 while ($bracket > 0) 22 { 23 $statement581 = $statement581 . ")"; 24 $bracket = $bracket - 1; 25 } 26 } 27 else{ 28 $statement581 = "Select distinct stu_num from Pg_skills"; 29 } 30 $sth = $dbh->prepare($statement581); 31 $sth->execute(); Line 1 – 3 is just running a SQL statement to get all the skill_ids required for the module task in question. Line 4 saves the number of rows returned as a variable $rows5000 which is used to show how many skills are requested by the module task. Line 5- 8 pushes the rows returned into an array @row5702. Line 10 checks to see if the array contains values if it does then line 12 creates a SQL statement with the skill_id as the first element in the array. Line 14 – 20, for the number of skills requested the SQL statement grows in size with each skill_id becoming part of it. The bracket variable also increases in size at the same rate. Line 20-26, brackets are added to the end of the statement according to the number of skills. Line 27 -29 is for if the array was empty, the module task requested no skills, the resulting statement would select all postgraduates. Line 30 – 31 prepares and executes the statement it is given. 34 The statement works by selecting all the postgraduates that have the first skills and from that list selecting all the postgraduates that also have the second skill and continuing for all the skills requested. 5.4 Problems encountered One problem encountered was being unable to find a way of increasing the size of the submit buttons on the forms. This resulted in the buttons being left the same size. Another problem was sending a variable between html pages within a script when it wasn’t stored anywhere. This occurred when using the postgraduate identification number to personalise every page when the number had not been entered in any text box so couldn’t be selected using parameter calling. Guelich et al (2000) recommended solution was to use a hidden field’s value to store the number and then reference it using a parameter call. The hidden field works like a text box but is invisible on the form. Entering user input values to an SQL statement became a problem if the user enter something with an apostrophe. It was also dangerous as using the right command the whole database could be deleted. To combat this a question mark was used in place of the variable. Patwardhan et al (2002) refers to them as place holders. Values can then be bound to them before execution ensuring only the exact value is sent and nothing is escaped. The variable would then be set within the execute command, The final problem encountered was being unable to get the scripts to work in an Internet Explorer browser. The script worked in Mozilla but not in Internet Explorer, the pages wouldn’t change. An investigation into the problem revealed the buttons in the code were not within the form brackets and as such were not working. 35 5.5 Source of forms As the prototype system is a deliverable the following addresses link to the forms. The skills data entry form can be found at: wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/skills.cgi The modules data entry form can be found at: wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/modules.cgi The postgraduates data entry form can be found at: wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/postgraduates.cgi The report form can be found at: wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/report.cgi They are best viewed using Mozilla web browser as they were implemented using the browser as a reference. However they do work in Internet Explorer. Screen shots of the forms can be seen in Appendix G. 36 Chapter 6: Testing 6.1 What is testing? Emprend (2005) states that testing is a crucial part of the product development process. It is used to ensure that for a set of specified inputs, a design produces the correct and expected outputs. Testing is also used to ensure the product has met its initial requirements and is in such a position that it can be used efficiently and effectively by the users of the system. 6.2 Types of testing Almstrum (1998) describes different types of testing methods. Black box testing ignores anything internal, like the code, and concentrates on the functional performance of the system. White box testing is the opposite in that it concentrates on the code internally. Walkthrough testing is completed by a user to try and find faults with the system. 6.3 Testing the code Testing has been a continuous process throughout the building of the system. Each new piece of code once implemented was tested individually to ensure that it worked. This involved testing it with a variety of different inputs both valid and invalid to ensure that the correct output was given. The code was also continuously tested using the command perl -wcT <filename> to ensure that the perl syntax was correct. Guelich et al (2000) refers to it as a switch. The form was continuously refreshed to ensure that the HTML code was producing the desired result every time it was slightly modified. 6.4 Testing the system Testing the system as a whole was performed using different inputs, the expected output and what the actual output was. The inputs were a wide range of data including valid and invalid data. Ranges were tested as were data types. The database as a whole was tested to ensure that records could be added, deleted, modified and viewed. The system was also tested against the user requirements to ensure it met them. The final stage of testing involved getting users to test the system using a walkthrough. After they had finished they were interviewed and their responses were recorded. This allowed not only faults to be found in the system that may have been overlooked but also to find any usability issues that may 37 occur. It also allows the design of the interface to be commented on so that it can be modified in the future. 6.5 Testing the functions Figure 11 shows an example of the testing procedure that was performed on every input box on all the forms. The example is only short but as there is not room to show every testing procedure performed it gives a brief view of what the process consisted of and how it was performed. If an actual result was different to the expected result then the problem, if any, was rectified. Area Tested Input Expected result Actual result Problem rectified? Skill form – Search Valid number Return and display row Return and displays row N/A Invalid number Return no result Error message indicating N/A ID number Skill form – Search ID number Skill form – Search invalid number entered A letter Error message ID number Skill form – Search Error message indicating the N/A input was not numerical Nothing Error message ID number Error message indicating the N/A field was empty Figure 12, Example of data testing After the data testing was completed then the functions were tested to ensure the procedure worked as a whole. Records were added to the database to test how the tables interacted. Not all problems encountered could possibly be recorded so the following are brief examples: In the module form after deleting a skill from a task and then going back to the task entry form, the module code would disappear. The page would no longer be personalised to a particular module. The solution was to call the value for the module code that stored in a hidden field before displaying the task entry page. Another problem was in the report if a module task had no specified skill then all the postgraduates were listed, however they were listed for each skill they possessed. The solution was to use a DISTINCT value in the SQL statement so that they were only listed once. In the postgraduate form, if a user doesn’t register their preferences before their skills and unavailability then no records are created when trying to enter skills or unavailability. This is due to 38 the fact that the preferences actually creates a postgraduate record that the skills and unavailability reference. Unable to delete a module task record that has requested skills. This causes a referential integrity problem. The solution is to ensure the skills are deleted from the task before deleting the task itself. Another solution is to use cascade delete in the table designs, PostgreSQL (2005). 6.6 Meeting the user requirements As the system is only a prototype and only one iteration has been performed the system is not expected to reach all the user’s requirements. The system is mostly concerned with catching data and there is room for expansion. Testing the system against the user requirements led to problems being discovered and corrected. 6.7 User walkthrough The results of the user walkthrough are summarised below: In general the consensus was that instead of having several different addresses for all the different forms, one page should be used with links to all of them. Then only one address would be required. The background colour was considered a good colour to use and the font was clear and easy to read. The red text really stood out and was a good idea for important pieces of information like error messages. 6.7 .1 Skills form For the skills form, a user commented that just one button would be preferable for searching rather than have separate buttons for name and number. The preferable solution was that the user would able to fill in any field and search depending on what was entered. Criticisms included the navigation being poor with the skills entry and searching being on separate pages. The users didn’t enjoy, after entering a skill, having to go back to the search page to view the results as this required unnecessary clicks of buttons. 39 A final criticism for the skills form was that it didn’t contain a password. When entering the address the form opens up with the search page. Also, an introduction explaining what the page was and did would be advantageous. 6.7 .2 Modules form A problem occurred straight away as, given a module code, users were unable to log on. This was due to them not entering it in capital letters. Although users didn’t mind they claimed they would prefer it if it specified near the text box that data entry was case sensitive. When it came to the task entry form the size of the window was an issue. Users were unable to see the entire screen and had to scroll down to see everything, especially error messages. A popular thought was that it would be an improvement if the skills of the tasks were listed along with the task rather than having to travel to a separate page to view them. Points that were considered well designed were the error messages as they were informative, clear and precise. They explained exactly what the error was and how to solve it. The drop down lists for entering dates were also considered useful and easy to use. 6.7 .3 Postgraduates form Again more comments about how it is not very clear what everything does. Users quickly became confused and claimed more information was required. For the preferences a suggestion that rather than have to delete the record if the postgraduate wanted to change it they should be able to edit or update it. A large error occurred when trying to delete the record as it was unable to be deleted due to being referenced from records of postgraduate skills and unavailability. 6.7.4 Report form The report was considered well designed apart from that instead of using the postgraduate’s number it was suggested their names should be used instead. As the user walkthrough was performed at the end of the project and the system is only a prototype the suggestions of improvements could be considered for future expansion of the system. 40 Chapter 7: Evaluation 7.1 Evaluation criteria To correctly evaluate the system a set of criteria is required. Martin et al (2003) provides a general framework for evaluating business multimedia products. The framework includes a large list of criteria, some of which are appropriate for evaluating this system. The criteria chosen include: • Pragmatic – Does the system do what it is meant to? • Useable – Are users able to use the system? Can they find what they want easily enough? • Reliable – Is the system stable? • Metamorphic – Is the system able to expand to meet new requirements? Each criterion will now be justified to show its relevance to the system. For the pragmatic criterion the system needs to be able to do what is was designed to do. In the case of the system this would be if the project had met its minimum requirements. The minimum requirements specify the bare minimum the system is meant to do. This criterion is justified as it essential for evaluating what the project has achieved via the system. This also includes the minimum aim and objectives of the project. The system may also be evaluated against the user requirements. The justification of the useable criterion is that the system is no good if the users are unable to use it. Evaluating this will see if the design was done correctly and used a strong enough emphasis on HCI aspects. The testing procedure from Chapter 6 will help with the evaluation. As the system would hopefully be implemented with SIS in the future it would have to be stable and reliable. It would also have to be able to expand to meet all the user requirements and any new requirements that come with being implemented with SIS. This is the justification of the last two criteria in the list. Other criteria include the methodology that was used for producing the system to see if it was the correct one to use and time management to see if all deadlines and milestones were kept to. 41 7.2 Is the system pragmatic? The minimum requirements included to create a database, web-based data entry forms and at least one report. The system has all these features so it does what it is meant to. It has actually expanded upon these by allowing postgraduates to not only record their periods of availability but also record their skills and preferences. As for the user requirements the system does not meet them all as it is only a prototype and has only gone through one iteration of the development process. It allows both postgraduates and module leaders to enter their details which are stored in a PostgreSQL database. 7.3 Is the system useable? According to the users who tested it using the user walkthrough in Chapter 6 the system was useable. Although it could be greatly improved upon especially in the navigational aspects they still managed to use it to perform procedures such as creating records of postgraduate unavailability. The design of the database works until trying to delete a record that is referenced elsewhere and causing referential integrity problems, although this could be solved with more time. The design of the interface is poor and could have done with more research into it and maybe some initial testing instead of leaving it to the end. The colour scheme was effective and helped with the HCI aspects. 7.4 Is the system reliable? Although the system underwent vigorous testing new problems were constantly found. At the current state, once the referential integrity problem has been solved, the system is fairly stable. The system can perform the procedures declared in the minimum requires to a respectable degree. However, with the many different text boxes and the different values that can be entered it is not stable enough to be considered for anything other than a prototype. Something important that is missing from the system is the security aspects. There are no password fields and no part of the system is secure. 7.5 Is the system metamorphic? Although the system does not meet all the user requirements it is possible to expand upon the prototype to meet the rest. The database which can be referenced and modified currently includes a table for allocation details to be held. By implementing a form or modifying the report an expansion could include allocating a postgraduate to a module and then storing it in the table. This table when referenced could meet a lot more of the user requirements including allowing all the users to view the allocations that concern them. The code allows for expansion as it includes a lot of re-use of the same 42 methods. Although as a prototype it is along way off being implemented with SIS even it does use the same technology and language. 7.6 Methodology use The waterfall methodology was used due to the time constraints on the project which only allowed for one iteration. The use of SSM helped with the analysis to ensure everything was fully understood before the design took place. The waterfall model prevented going backwards so it was convenient that the process of going through the stages did not call for this. The main problem with the model was performing the main testing at the end as it left no time for amending any problems that were found. Although testing was a continuous process throughout the development it was only basic and the majority of problems only revealed themselves at the end. 7.7 Time management At the start of the project the time schedule of when each task would be completed was set in the form of a Gantt chart, see Appendix B. However the project was not keeping with the schedule due to the Christmas break not being used as efficiently as possible. Also the time process for learning perl was heavily underestimated. Due to these factors implementing the interface took longer resulting in there not being time to produce a prototype to show to the main users which could be improved upon. The testing therefore had to be done right at the end once the system had been fully implemented meaning it couldn’t be improved upon. The write up of the project which was known to be time consuming was started later than planned as more time was put into developing the system. The final time schedule of when the tasks were actually completed is shown in Appendix C. 7.8 Comparison with existing solutions The project has met all the minimum requirements, all the objectives set and reached its aim. In comparison with existing solutions a system was produced to solve a problem of using the current situation. The initial problem was that current situation was not very efficient. The solution was to speed up and increase the efficiency of data entry and storing it orderly in a database. All the transfers of data were to be done electronically while keeping redundancy to a minimum. The system does allow for easy and quick data entry. It is efficient and stores the data in a normalised database. However as a prototype it does not completely do everything the original situation does although it was never designed to. It couldn’t completely replace the existing situation but it gives some ideas of 43 how to improve the way things are done. Hopefully in the future after much work and expansion it could be considered a serious contender for replacing the current methods. 44 Chapter 8: The future 8.1 Future Expansion The original concept was to build a prototype for a system that could eventually after many iterations be implemented with SIS. The aim for the project actually claims that the project’s system should make use of SIS. It did in that it used and referenced copies of tables that exist on SIS. Future expansion would involve the system actually using the tables in SIS and possibly creating the tables from the system in SIS. However in this event the database would be completely redesigned and the standard forms for web-interface for SIS would most likely be used. 8.2 Future Improvements The prototype system could be improved in so many numerous ways that they can not all be listed. Firstly all the user requirements would have to be met. This would involve implementing all the different reports. At the moment the prototype only caters for postgraduates. To improve the system further Teaching Assistants could be taken into account. Deadline dates could be implemented into the system to ensure that data received is not after the deadline. Most importantly a proper logging in system for the forms with security including passwords and real user names would be a great improvement. Although the allocation process in the system doesn’t actually work in the system, the allocation report does produce a list of postgraduates suitable for each module based on skills. The method of allocation in the current situation is manual with the allocation officer choosing the postgraduates for the modules. That was what was intended for the system, a manual process based on skills possessed and requested. However in a future expansion instead of just skills other factors could also be taken into account. These could include dates of tasks, postgraduate unavailability dates and preferences. Now this is a very complex method for a manual allocation and could be made even more complex making use of the skill experience and enjoyment. One method of performing the allocation would be to turn it from a manual allocation into an automatic scheduling algorithm. Winston (1991) describes many different types of algorithms. 45 References: Ainsworth, J (2004) ‘SIS introduction’ http://www.comp.leeds.ac.uk/internal/sis/ [18th April 2005] Almstrum, V (1998) ‘V & V Plan Information’ http://www.cs.utexas.edu/users/almstrum/classes/cs373/fall98/doc-stds/VVP-info.html [20th April 2005] Beauchemin (2000) ‘Software development life cycle models’, http://www.csd.uwo.ca/courses/CS377b/CS377-Development.html [5th April 2005] Boehm, B (1998) ‘A Spiral Model of Software Development and Enhancement’ Computer, May 1988 (Vol. 21, No. 5), pp. 61-72. Checkland, P & Scholes, J. (1990) ‘Soft Systems Methodologies in Action’, Wiley Couprie et al (2004) ‘Soft systems Methodology’, http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html [5th April 2005] Elmasri, R & Navathe, S (2000) ‘Fundamentals of database systems’, third edition, Addison-Wesley Emprend inc. (2005) ‘Testing Techniques’ http://www.projectconnections.com/knowhow/kb_contents/skills/testtech.html [20th April 2005] Eva, M (2004) ‘Soft systems Methodology’, http://www.acca.org.uk/publications/studentaccountant/1073535 [5th April 2005] Guelich et al (2000) ‘CGI Programming’, second edition, O’reilly Holding, H (2000), ‘Mastering Database Design’, Macmillan Jarvis, C (2004) BOLA: CATWOE and Soft Systems Methodology http://www.brunel.ac.uk/~bustcfj/bola/research/ssm.html [5th April 2005] Kremer, R (2001) ‘Soft systems Methodology’ http://sern.ucalgary.ca/~bowen/613/report/#stagesRichPicture [5th April 2005] 46 Martin et al (2003) ‘A Simple Framework for the Evaluation of Business Multimedia products.’ http://www.ejise.com/volume6-issue2/issue2-art14.htm [21st April 2005] Matravers, J (2003) ‘The Conception of an IS Project Introduction to Soft System Methodology (SSM)’. IN11 lecture notes 4 and 5. The University of Leeds. MySQL (2005) ‘Database server feature comparisons’ http://dev.mysql.com/tech-resources/crash-me.php?res_id=2051&brief=1 [6th April 2005] Nielsen, J (2005), ‘Heuristics for user interface design’ http://www.useit.com/papers/heuristic/heuristic_list.html [11th April 2005] Parker, R (1997) ‘Web Design & Desktop Publishing for Dummies’, IDG Books Worldwide Patwardhan et al (2002) ‘Perl in a nutshell’, second edition, O’reilly PostgreSQL (2005), PostgreSQL 7.3.9 Documentation http://www.postgresql.org/docs/7.3/interactive/index.html [11th April 2005] Refsnes Data (2005) ‘SQL Tutorial’ http://www.w3schools.com/sql/default.asp [6th April 2005] Supremisitc (2005) ‘Software development methodologies’ http://www.supremistic.com/development-methodology.html [5th April 2005] Teorey, T.J. (1990) ‘Database Modelling and Design’, Morgan Kaufmann Vita Voom (2004) ‘PostgreSQL comparisons’ http://www.vitavoom.com/postgresql.html [6th April 2005] Winston, W (1991) ‘Operations research: applications and algorithms’, second edition, Pws-Kent 47 Appendices Appendix A -Reflection Having finally completed my project I can now reflect on the entire process. I believe the project to have been very challenging. It was a brand new experience for me; I have never undertaken anything before that requires so much time and work. Although I have found it hard work it has also been very rewarding and I feel enormous pride on completion for having achieved so much. It has required making use of existing computer skills as well as learning new ones. I feel this experience has benefited me by producing new abilities I will be able to call on in later life. The selection of the project was one that required a lot of time and consideration. I knew my forte lay in databases so it made sense to base my choice on this. It was after meeting with Stuart Roberts that a final choice was made. To me the project description chosen seemed both interesting and challenging and I felt I could really do something with it. Although I knew the project was going to be time consuming I didn’t realise just how much. Fortunately I had chosen my modules for my final year so that the majority were undertaken in the first semester leaving me more time to work on my project in the second semester. This is advice I would strongly recommend to any future students undertaking a final year project. Another lesson I have learnt is to try to stick to what you know best and not to take too much on. If the project does require learning new skills try to leave adequate time to learn to apply them. This was my main mistake, trying to learn perl CGI and PostgreSQL when I had never touched on either before. Although I had reasons for doing so, I don’t think the reasons justify the work that was not completed. If I were to do the project over again I would stick to a database management system I had used before and a computer language that I had at least had experience in Starting the project was the hardest part and I would advise any future student to plan their progress carefully by setting deadlines that are realistic and achievable. Understanding the problem exactly and getting the requirements early is essential as it will leave more time to work on the actual system. Finishing the system early will leave time for testing and improvements and hopefully another implementation. So it is highly recommended that a good methodology that suits the project is selected. Timing is essential as it soon runs out leaving you with too much work and not enough time to complete it in. There is a lot of man hours required but I would advise future students not to neglect 48 their other coursework and exams in favour of the project. Time management is an essential skill that I wish I put to better use; it would have definitely reduced the stress in the last few weeks. Although my solution is not fully working and doesn’t meet all the user requirements I have to remember it is only a prototype and that I was never expected to produce a fully implemented system. Overall I have really enjoyed the project, I am proud of what I have achieved and what I can do when I really put my mind to it. I’m sure that if I were to undertake a project of this size again I would learn from the mistakes I have made in this one. 49 Appendix B – original time schedule Aim and minimum requirements Mid Progress Final Project meeting report report Preference form Weeks project 1 2 3 4 5 6 7 8 9 10 11 Christmas Exams 1 2 3 4 5 6 7 8 Easter 9 10 Deadlines Draft chapter and table of contents Gather requirements Requirements analysis Review current method Background reading Research into methodologies Mid project report Model using diagrams (ER) Design database Implement database Design Interface Implement interface Design reports Implement reports Show prototype to main users Make changes Testing Evaluation Write up A waterfall method will be used here, leaving time for at least one iteration. 50 Appendix C –actual time schedule Weeks 1 2 3 4 5 6 7 8 9 10 11 Christmas Deadlines Gather requirements Requirements analysis Review current method Background reading Research into methodologies Mid project report Model using diagrams (ER) Design database Implement database Design Interface Implement interface Design reports Implement reports Testing Evaluation Write up 51 Exams 1 2 3 4 5 6 7 8 Easter 9 10 Appendix D – Postgraduate request form 52 Appendix E – work allocation form 53 Appendix F – payment claim form 54 Appendix G – screenshots 55 56