Assessment
Assessment sits at the intersection of learning objectives, the deliverables which demonstrate those objectives and the criteria used to judge the quality of the deliverables:
This relationship is not unique to assessing projectwork, it is common to all assessment. However, there are issues specific to projectwork which change these aspects.
Projectwork is, in general, at a larger scale than other assessed work; indeed, this is part of the rationale for having students undertake projects at all. Many of the problems of software development only become apparent as scale increases. Small-scale coursework typically consists of implementation from a given design, or design from a given specification, where there is neither scope for innovation nor necessity for multiple deliverables. This increase in scale also leads to a change in the nature of the required deliverables ? large scale projects inevitably requires a more rigorous approach to the process of generation of the products, which process must itself produce assessable artefacts. This is congruent with the principles of software engineering.
In many cases (particularly with final year projects), students are undertaking significantly different projects from one another, leading to a disparity in appropriate deliverables which must still be assessed under the same "rules". This can also make it especially difficult to generate criteria which are precise enough to be meaningful as aids to assessment, yet general enough to cover the range of projects undertaken in a particular instance.
In team and group projects "working together" is often an objective, and is often the first time that such methods have been required. This forces a change in the assessment criteria (especially in the minds of the students) where previously deprecated practices of producing joint work ("copying", "plagiarism") become an essential, assessed component.
If one of the objectives of a projectwork instance is that students learn process as well as produce products, then it is important that the deliverables of the project actually demonstrate stages and aspects of that process. [See: 6.5 What is a "report", anyway].
Most Some students are not motivated by the Joy of Learning. They are at University for the benefits that the qualification will give them in the job market, and therefore work primarily to maximise their marks. Staff can use this to their advantage in the assessment process by setting criteria and deliverables that manipulate students into learning the important bits, by giving them the most marks. [See: 6.4 "Authentic" Assessment Criteria].
Partly because of the scale of projects, partly because of the weighting they carry in the curriculum (from 3% to 30% of an undergraduate degree), partly because there are often a great variety of deliverables in a great variety of media (software artefacts, technical documentation, reports, code, oral presentations etc.) and partly because several members of staff are commonly involved, assessment of projects is a time consuming (and therefore expensive) activity.
Most Some staff perceive the extra work that projectwork assessment requires as excessive and unfair. One way to address this is to undertake an audit to see how long staff actually do spend reading reports/watching demonstrations etc. This might prove that project assessment is both costly (it takes a lot of time) and cost-effective (it produces results which could not be gained in a different/cheaper way).
Because project assessors are frequently the same as project supervisors, assessment may be coloured by their knowledge of students' effort. If they've "come a long way" should they get as many/more marks than another project which went further, but was easier? It is important to forge a consensus amongst supervisors and examiners as to the relative value of these two aspects.
It is important for the supervisor to have knowledge of where the "tricky bits" of the project fall so that apparently trivial pieces of implementation can be properly acknowledged, but it is equally important to have criteria that distinguish between effort and achievement.
There is a tension between assessing the products of a group and rewarding the efforts of individuals within that group, between "Group products get a group mark" (every group member gets the same mark, regardless of contribution) and "Only individual effort is rewarded" (attempting to completely determine individual contributions).
Although tempting on grounds of economy of assessment effort, "group" marking can be perceived by students as unfair, but is defended by its adherents on the grounds that if individual marks can be accrued from group work, then students will to work to maximise their own mark.
Mechanisms which reward individual effort in a group context are confounded by the difficulties which assessors have in determining what actually went on in the group, and by problems of determining appropriate weightings for different activities (e.g. "implementation" versus "documentation").
Between these two extremes, a proportion of the marks can be awarded for individual contribution to the work, with the rest going to the group as a whole. Many mechanisms have been devised to address this; commonly a proportion of the marks is handed over to the students to allocate amongst themselves so that they can reward the highest contributors (and punish the laggards).