1. Introduction

This report documents the development of an Online Project Marking System for the University of Portsmouth.  In this first section the problem background is described along with the project aims and objectives.  Also, the development lifecycle selected and applied during the project is outlined and an overview of the remaining chapters of the report is provided.

1.1. Problem background

The project is based in the departments of ISCA and CSSE, which were amalgamated to form the School of Computing in August 2005, at the University of Portsmouth.  All of the degree courses run by the departments require students to undertake a project unit in their final year.  In the majority of cases, the project requires students to build a software artefact with the aim of solving a specified problem.  The project is assessed by means of a report submitted by the student which documents the development of the solution system.

Both departments adhere to a common set of procedures for the assessment of student project reports, which in recent years have become increasingly complex and difficult to co-ordinate.  Up until May 2005, the project marking process was entirely paper-based.  Academic staff members were required to complete project mark forms by hand (an example form is provided in Appendix A) and perform all marking calculations manually. 

The adherence to correct procedures in the marking process is a vital requirement and one which a paper-based system cannot provide an adequate level of assurance for.  The use of a paper-based system presents a number of associated problems; these include the risk of errors occurring during the calculation of project marks, time delays incurred by manual processing and lack of audit trailing. 

The implementation of a computer-based system to manage the marking process provides a potential means of overcoming many of the deficiencies of a paper-based system.  Dr Jim Briggs, a principal lecturer and MSc projects co-ordinator at the University, identified the need for a computer based solution.  In October 2004, he became the client for a student project [Reed (2005)] which had the aim of providing a solution for the web-based marking of projects.   Unfortunately, the project was largely unsuccessful in achieving its objectives, with the student only managing to deliver a design for the system’s back-end database. 

Due to the growing pressure for a system to be implemented, Dr Briggs continued to work on the project and had implemented the first version of the solution by Summer 2005.  Section 3.3.5 looks at this implementation in more detail, but to summarise, the system provided a means of submitting a project mark via a dynamically generated mark form.  Submission of a mark form resulted in the data being emailed to a member of the administration team for recording.  This system was only ever intended to provide an interim solution and carries many of the same problems presented by the paper-based system.  Essentially, the solution provided a mechanism for ensuring consistency in the project mark form and also a means of automatically calculating the project mark.  However, like the paper-based system it provided no means of managing the project marking process or establishing a project audit trail.  This brings us to the purpose of this project, which was to build upon the existing system in order to provide a complete solution for the web-based marking of student projects.

1.1.1. The SUMS system architecture

At this stage in the introduction it seems appropriate to explain how the Online Project Marking System will be integrated into the collection of existing web-based systems operated by the client.  Currently, a number of independent web-based systems are in place at the University to provide services such as the management of student projects, directories of potential project ideas and course unit selection.  The fact that all of these systems perform common functions such as authentication and authorisation has given rise to the planned development of the SUMS system.  The concept of SUMS, the Student Unit Management System, is to provide a means of centralising the common functions of each individual application.  This means that policies such as role based security can be applied globally to all applications. 

Figure 1.1 - SUMS system architecture

From a user perspective, SUMS provides the great advantage of allowing access to all of the various web-based services following a single stage of authentication.  Also, from a programming perspective SUMS reduces the amount of duplicated functionality in each application, thus making future maintenance easier.  Although the SUMS system is still in the early stages of development, the Online Project Marking System needed to be designed so that it could easily be integrated as a sub system of SUMS.

1.2. Selection of project

There were two main motivations for selecting this project; firstly there was a pressing need for the University to have a solution in place for web-based project marking.  This provided the opportunity to work on a real system which had the potential to enhance the current facilities available for marking student projects.  Secondly, a constraint of the project was that the solution had to be developed using the J2EE platform.  In comparison to other web centric technologies such as PHP or Perl, J2EE was of much greater interest due to its increasing popularity in the field of enterprise software development.  In addition, the developer’s previous experience with the technology meant that the phase of implementation could be approached with some degree of confidence.

1.3. Project aim

The primary aim of this project was to build upon the existing web-based project marking system in order to implement the project marking process.  Upon completion of this goal, a number of associated issues such as the publication of marks to students and audit trailing of the marking process needed to be addressed.

1.4. Project objectives

During the initial stage of developing a specification document for this project, which has been provided in Appendix E, a number of objectives were defined:

• Elicit and document the project requirements.
• Analyse the existing system and produce documentation (such as process flow diagrams and use cases) to support the design process.
• Research the project marking process and produce relevant documentation to support the design process.
• Investigate the feasibility of the options available for releasing marks to students and identify the most appropriate method.
• Design the replacement system, documenting the proposed system architecture, user interaction and interface.
• Implement the application and perform thorough testing.
• Conduct user evaluations of the system and make any necessary revisions.
• Produce detailed technical documentation.
• Investigate and plan further work (from the list of non-mandatory requirements) to be carried out during the remaining time. 
• Deliver the solution to client and perform integration testing.

1.5. Constraints

There were two main constraints placed upon this project, firstly the timeframe for development.  The project began in May 2005 with a deadline for completion of September 2005, therefore providing 5 months, with some of that time being required to document the project.  The second constraint, imposed by the client, was the choice of technology for the development of the web application.  The previous solution was developed using the J2EE platform, described in section 2.2 in conjunction with the J2EE web application development framework – Jakarta Struts, outlined in section 2.4.2.

1.6. Assumptions

The main assumption made during the development of this project was that the implementation of processes for authentication and authorisation were outside of the project’s scope.  This is based on that fact that these processes are to be implemented at the higher levels of the SUMS architecture.

1.7. Project planning

Appendices C and D provide both the original and revised plans for the development process.  The original project plan, created in Microsoft Project, uses the Gantt chart as a basis for organising the various project activities.  Following further consideration, this method was deemed inappropriate for a web-based project since it leans heavily towards the adoption of the waterfall development lifecycle.  Typically, the various activities undertaken during the development of a web application can be approached simultaneously; therefore it seemed more appropriate to state the proportion of time to be allocated to each activity during the course of the project.  In terms of the development lifecycle, an iterative approach (illustrated in Figure 1.2) was selected for this project.

Figure 1.2 - Iterative development lifecycle [Miller (2004)]

Under the iterative development lifecycle, the project requirements are prioritised and implemented as a number of separate phases.  Due to the large number of requirements associated with this project, this lifecycle was seen to be the best method for ensuring that the most important aspects of the system were implemented during the timeframe.

1.8. Report overview

The remainder of this report has been organised into the following sections:

Chapter 2 - Literature review

This chapter provides an overview of the J2EE platform used to develop the Online Project Marking System.  It also discusses the selection of J2EE design patterns and development framework applied during the phases of design and implementation.

Chapter 3 - Requirements analysis

This chapter describes the methodology selected for use during the stages of analysis and design.  It also explains how the requirements for the Online Project Marking System were established and how these requirements were documented.

Chapter 4 - Design

This chapter shows how the requirements were realised in a system design.  It looks at the design of the various components of the application including the database, user interface and application controller.

Chapter 5 - Implementation

This chapter shows how the system design was implemented and tested.  The various tools used during the development process are described, and a number of issues which were encountered are highlighted. 

Chapter 6 - Evaluation

This chapter looks back at the requirements defined in the analysis phase and identifies those which have been achieved and those which have not.  It also looks at some of the potential future developments for the Online Project Marking System.

Chapter 7 – Conclusion

This final chapter of the report reflects upon the approaches taken over the course of the project.  It identifies the various learning outcomes of the project and concludes by stating what has been achieved from its completion.