Web programming

Units WEB1P and WEB2P

SWS group task 2012-2013c1

Group task (Task B)

Task details

Deliverables

At approximately 1030 to 1100, each group must submit the following deliverable:

  1. A short report (which may be a diagram) showing the basic elements of their design and which member(s) of the group will be responsible for detailed design and implementation of each element.

At the end of the SWS (1630), each group must submit the following deliverables:

  1. A group cover sheet.
  2. A printed copy of the final version of any Java code you wrote or amended.
  3. A printed copy of the final version of any HTML or JSP pages you wrote or amended.

    Ensure that all of the above are securely fastened together by staples, or contained in a wallet or folder.

  4. A demonstration of all aspects of your system to the assessor during the SWS.
  5. One email to the assessor (Jim.Briggs@port.ac.uk) that meets the following specification:

Hints and tips

  1. Remember, a SWS is an educational experience as well as an assessment one. If you don't know, ask your group. If no one in your group knows, ask the assessor.
  2. Use the online documentation and your reference books.
  3. Don't leap into coding. Make sure you have a feasible design for your solution before you start programming it.
  4. Devise a way to even out the workload of your group, and so that you can work in parallel. Three people watching one person typing is unlikely to be the most productive means of solving the problem! You may ask the assessor if they think the division of work among members of your group is a reasonable one.
  5. Allow plenty of time to integrate separately developed parts of the program. It is often only at this stage that you find flaws in the design.
  6. You may reuse code taken from elsewhere (including textbooks and the web), but such code MUST be clearly distinguished and the source of it MUST be acknowledged by a comment in the program listing.
  7. Develop your code in small parts. Test each part as you implement it. Run your program frequently – don’t add more than about 10-15 lines of code (at maximum) without compiling it to check what you’ve done. Use the breakpoint debugger to run the program to find out whether variables have the values you think they should have. Think carefully about the design of each part of your program. Don’t reject well thought out code just because you get compilation errors – work out why you’ve got an error and correct it, don’t throw away the good with the bad. Don’t be over ambitious. Demonstrate your code to the assessor in small parts. Get feedback.
 

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

 
The web programming units include some material that was formerly part of the WPRMP, WECPP, WPSSM and WEMAM units.