Enterprise web programming

Units ENTWA (Level 6) and APSW (Level 7)

APSW 2016-2017 Coursework 2

Introduction

All students must do a web application development project.

Students are expected to draw on material taught (and material otherwise learned) during all the units on their course in tackling this problem. This assessment thus integrates many of the elements covered during the course.

The coursework is individual, but students are expected to form groups to ensure that their solutions interoperate. Groups can be from 2-6 students in size. Each student in a group must work on a different module.

Problem

The School of Computing uses an online system for the management of student projects (both final-year undergraduate and masters). This is called SUMS (Student and Unit Management System).

The aim of this coursework is for each group of students to develop a number of modules of that system. The number of modules developed must be equal to the number of students in the group. While the modules can be developed separately, they must be capable of interoperation. This means they must:

It is recommended that the sharing be achieved by sharing a source code repository and other software engineering tools.

The required modules are:

Project Registration

The existing PUMS system gives an example of how registration for projects is conceived. The primary goal is to allow students to self-register with their course and unit details. This is the first step in the project process.

A previously created requirements specification for this module.

Project Ideas

The School of Computing's MSc project ideas database is currently implemented in a non-MVC style. It also has limited searching functionality. It does not permit people who submit ideas to be able to edit them or withdraw them. This functionality needs to be added.

A previously created requirements specification for this module.

Project Allocation

The aim of the project allocation system is to match up students with ideas and supervisors. Students can select ideas in order of preference; similarly they can select prefered supervisors. The Project Co-ordinator must have a mechanism to allocate ideas and supervisors to students. If this can be automated or semi-automated, all the better.

A previously created requirements specification for this module.

Project Monitoring

As the project progresses, students must meet certain milestones. At each milestone, they submit a short written report to their supervisor, who then approves it (or not).

This module must allow the Project Co-ordinator to set up milestones for a group of students.

A previously created requirements specification for this module.

 

Project Marking

The current marking system was developed using Apache Struts and pre-dated the introduction of JPA. It is thus riddled with overlapping entity class definitions and consequent JDBC access code. This needs to be "cleaned up" while retaining the existing functionality (though additional functionality is desirable).

A previously created requirements specification for this module.

Source code (in Kenai - see instructions)

Sample mark form

Project Feedback

Once a project has been marked (by two members of staff), the marks and written remarks must be fedback to the student. This is governed by rules concerning how the two sets of marks (and associated comments) are reconciled.

A previously created requirements specification for this module.

In each case, your aim is to make substantial developments to the relevant module(s). Those developments will be in using the Java EE technologies (at least JSF, EJB, JPA) PLUS one or more of the following:

Groups may either start from scratch and build a system of their own, or (after discussion with the unit coordinator) start from his existing codebase. Obviously in the latter case, a more advanced endpoint will be expected, but students will have the advantage of starting with a partially developed system and the framework of existing code that it provides.

Groups

The coursework will be carried out in groups of up to 6.

Groups formed

Revised 24 February 2017

Group Approach Registration Ideas Allocation Monitoring Marking Feedback
Z New Ifeoluwa Oye Russell Score Nur Azhar Ramazan Esmeli Jinet Ale Pathmaian Sriskandarajah
Y New Joshua Vowles David Ralph Gilberto Abreu Calum Fairchild Adam Piper -

* to be confirmed

People as yet unallocated to groups

 

 
 
 

Deliverables

Deadline Date Deliverable(s) Submission arrangements Marks
Week 5 practical Tuesday 7th February
  • First draft of requirements specification
  • Bring printed copy to practical session
5%
Week 7 practical Tuesday 21st February
  • First draft of user interaction design (organisation structure diagrams and/or storyboards and/or architecture maps)
  • Bring printed copy to practical session
5%
Week 9 practical Tuesday 7th March
  • Alpha version of the web application (demonstrating some subset of the functionality)
  • Jim will download it from your version control repository.
  • Demonstrate it at practical session
  • Ensure your web application is in the specified format and that your repository is set up correctly.
10%
Week 13 (CAP)

 

Thursday 27th April
  • Demonstrable web application
  • Completed documentation
    • Requirements specification
    • User interaction design specification
  • Source code listings and Javadocs
  • Evidence of use of JIRA and Subversion
  • Jim will download it from your version control repository.
  • Allow all other students on the unit auditor (or equivalent) rights on your repository so that they can also view it.
  • Bring a working electronic copy of your web application to the SWS
  • Ensure your web application is in the specified format and that your repository is set up correctly.
40%
  • Report on coursework
  • Submit report via Moodle
40%

Notes on deliverables

Marking

Resources

Students are encouraged to use whatever resources and facilities are available to them. All material (including programming code) that is copied from elsewhere must be identified and its source cited. The member of staff who set this assessment may be consulted for guidance on your approach, and to a limited extent with technical problems that arise.

 

Last updated by Prof Jim Briggs of the School of Computing at the University of Portsmouth

 
The enterprise web programming units include some material that was formerly part of the WEB1P and WEB2P units.