| PSD3 Group Exercise 1 |
A Support System
for Group Projects |
Guidance
on Individual Report 2 |
| last update: 11/3/09 |
The report must cover:
The report should be no longer than 5 pages. You may use any document preparation system you like.
Be careful to:
Your report will be assessed on these criteria:
Each of the 5 criteria will be marked in bands. The criteria for award of marks is as shown in the table below. The overall average aggregate score will be converted to a proportion of 12.5 to award the contribution to the overall PSD3 mark.
|
A
|
B
|
C-D
|
H
|
|
| Presentation | Well structured; almost no grammatical or spelling errors. | Structured; some grammatical and/or spelling errors | Disorganised; frequently ungrammatical; many spelling errors. | Difficult or impossible to understand. |
| Coverage | Complete coverage of main topics. Substantial coverage of range of subtopics under Software Design. | Mostly complete. | Very patchy. | No topics covered. |
| Points Made | Several distinct points for each main topic. Each point showing some insight into experience (lessons learned). | Several relevant/insightful points made. | Few points and/or not relevant or insightful. | No points made. |
| Evidence | All points backed by evidence; several detailed concrete examples illustrating the points made. | Points sometimes backed by evidence; some examples, but little detail. | Little evidence; almost no examples from exercise. | No evidence or examples. |
| Links to Course Material | Frequent relevant links to course material with clear and correct references; evidence of reading beyond basic course notes. | Some links to course or related material; relevance sometimes unclear and/or occasionally missing references. | Few references to course material; relevance frequently unclear; missing references. | No links to course materials. |
Thus, example 1 below would be considered to be at grade A, while example 2 would be a D for quality of points made, evidence, and for links to course material.
Example 1: During the design of our system, we initially used two separate, unrelated, classes to represent assessed feedback and unassessed feedback. This resulted in having to maintain two separate lists and iterate over them separately. During a design meeting in week 3, we realised that a heterogeneous list would be a better idea, so the two classes were made implementations of a single parent interface and a single heterogeneous list implemented with elements of the interface type. This simplified our code and made it easier to test and maintain. This illustrated an application of the heterogenous list pattern (see lecture xx), exploited inclusion polymorphism (lecture XX) and enabled us to put refactoring into practice (see Fowler, Refactoring Addison-Wesley, 2003). It was particularly interesting to observe how little effort the refactoring was (about 1 hour's coding), given the improvement in the resulting code; for the cost of 1 additional interface (15 lines of code), we were able to reduce list processing code to half the previous number of lines, viz., around 25 rather than 50.
Example 2: During the exercise we found it useful to change our code to make it more efficient.
At the end of the individual report, include an assessment of each member of your group, including yourself Give full names of group members, please!
You will carry out two assessments, one for quality of work and one for effort expended. For each assessment, you have a total of N X 20 points, where N is the number of members of your team (i.e., you have 20 points per team member). Allocate this total as you wish to the members of your team such that the total number of points awarded adds up to the total available.
If there is a large difference in point allocation then give a brief justification for the outlier(s). This information will be used to determine the potential award of a positive or negative delta to each student’s overall mark, if appropriate.
The peer assessment does not count towards the five page limit.