Website Programming Applications IV (Python)

Assignment 2


Assignment 2 is for a group programming project and contributes 40% towards the final module mark.


The module syllabus requires a team assignment. Students will work in teams of between 2 and 4. Larger teams (3 or 4 students) are expected to deliver more comprehensive implementations and reports to achieve the same marks as smaller teams. Marks will be awarded both for the process leading towards the end result and for the final product which is delivered.

Students are expected to demonstrate a working CGI program meeting objectives agreed beforehand with the module coordinator, and to complete a suitable project report.

General objectives

Students project teams will research and decide objectives for original Python CGI applications to be designed, implemented and demonstrated. 20% of the assignment mark will be based on the software demonstration. The students must also prepare a joint project report containing documentation describing the design (20%), the team process (20%) by which objectives were agreed and achieved, printed and floppy-disk copies of all source codes including Python software and HTML (20%). The final 20% of the project mark will be based on an assessment of the quality and originality of the project as a whole.

Appropriate Level of difficulty

On-line commercial and community databases can usefully be maintained and viewed using CGI scripts for various purposes. These typically need to authenticate their users, e.g. by ensuring that before they are allowed to add data entries into the database a user is registered and issued with a unique userid and password identifier.

Applications might include but are not restricted to:

For these applications to deliver value to those who use them, it should be possible for more than one person to update the database in a controlled manner.

It is not considered acceptable that an application should receive all of its input using just one form. These interactions should be broken down, e.g. by having one screen for a user to input a userid and password, which results in the next screen allowing a room booking to be made or cancelled only if a valid login is processed. A third screen might indicate payments due to a particular account.

There should be some original underlying control logic relevant to the application. E.G in the case of a public room-booking system, multiple bookings for the same room for the same time-slot should not be possible, and only users with valid userids and passwords should be allowed to make or cancel bookings. Charges could be made for room bookings and late cancellations. One element of the control logic in an authenticated application is that no data update should be possible without a valid user authorisation.

To obtain maximum marks, teams of 2 should implement a CGI application with at least 2 distinct input screens and 2 possible valid output data displays, not being variations on the same template and not including error reports. A team of 2 should implement at least 2 distinct areas of underlying control logic. These numbers are increased by 1 for every additional team member, i.e. for teams of 4 there should be 4 input screens, 4 output data displays and 4 distinct areas of control logic required within the application.

Other relevant application concepts of similar levels of difficulty (e.g. involving the implementation of an on-line game requiring more internal logic but simpler input/output options) are likely to be acceptable.

Activities and Deadlines

The deadlines stated below are primarily set to help project teams ensure that relevant activities are completed in adequate time so that a satisfactory project outcome is achieved. However, failure to meet these deadlines is likely to be evidence of a lack of adequate preparation and planning by the students concerned, who will be marked down accordingly. It is therefore the responsibility of project teams to get the relevant documents in to the tutor by the dates stated. The coursework handing in system should be used for this purpose.

Most of these deadlines require the team to present documentation on paper, in order to record what has been agreed both within project teams and with the Tutor. The Tutor will sign and date a document he or she has agreed when presented with this in person or will indicate reasons for not accepting it. These documents must bear the names of all team members.

Students are required to meet the following deadlines:

a.Team registration and project title: Week 6 beginning 11 March 2002.

Decisions will have been made about team membership and a working project title. Students are expected to register team membership, a contact email address and project title.

b. Specification: Week 8 beginning 15 April 2002

Agreement must be reached with the Tutor based on a specification. This must include a clear description of assignment objectives describing the input data, output data and a set of transactions to be performed by the proposed program. It is strongly recommended that the contents of this specification be negotiated in detail during weeks 6 and 7 based on students' draft ideas and work, to allow for feedback and timely revision.

c. Software Reuse Agreement: Week 11 beginning 6 May 2002

The reuse of Free Software (as defined by The Free Software Foundation), the programs, sources and components to be reused and the extent of modification to these and of original programming work must be negotiated and agreed with the Tutor. Teams must provide a list of sources giving the URLs or books etc. from which copies may be obtained and names of original authors and/or current maintainers. If this requirement is not met and students are found subsequently to have made any unattributed or unlicensed use of software which they have not originated themselves, this failure will as a minimum, result in students' work being marked down as being unduly derivative, and may in severe cases result in zero marks or evidence being presented to a cheating committee. Therefore students finding relevantly reusable code must show this to the tutor and get the proposed reuse agreed in advance. Finding relevantly reusable code may enhance the value of a project, but this will not be accepted as an excuse to avoid original work, study and adaptation.

d. Project Demonstration: Week 14 beginning 27 May 2002

Students must arrange an appointment with the Module Tutor a week in advance for the purpose of demonstrating the CGI program they have developed. Students are required to have the software installed, fully tested and ready to run at the start of this appointment. All team members must attend the demonstration.

e. Project report 14 June 2002

This project report must be submitted including the names of all students who have participated in the team project. To obtain full marks this must include: