SWS group task 2016-2017c1
Group task (Task B)
Task details
Deliverables
At approximately 1100 to 1115, each group must submit the following deliverable:
- 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 approximately 1530, each group must:
- demonstrate all aspects of its system to the assessor.
Before the end of the SWS (1630), each group must submit the following deliverables:
- One email to the assessor (Jim.Briggs@port.ac.uk) that meets the following specification:
- Subject line: "APSW SWS1 2016-2017 – Group [X]" (where X is the letter identifying your group)
- Body contains the names of the members of the group
- One attachment - a Zip file containing your web application (including source code). (Hint: zip up the root folder of your web application).
Hints and tips
- 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.
- Use the online documentation and your reference books.
- Don't leap into coding. Make sure you have a feasible design for your solution before you start programming it.
- 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.
- 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.
- 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.
- 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.
