48770 assessment criteria, Spring 2006
From SoftwarePractice.org
NOT OFFICIAL YET
As per the Subject Guide, the marking for the project is divided up as follows:
- Project documentation: 30%
- Project implementation: 20%
- Workbook: 10%
This article is a more detailed breakdown of the mark distribution and assessment criteria. Please make sure that you take careful note of these criteria, as claims for more marks because you worked extra-hard on one particular aspect of your project will not be accepted.
Note that all projects are of equal difficulty. They are all open-ended -- that is, no matter how well you implement what you think are the project requirements, there is more that can be done. One of your goals, then, is to carefully analyze and structure your work, so that you can determine and achieve a useful and working program within the available time. A carefully-planned and executed project will achieve a higher mark than one in which team members work like crazy but in an ad-hoc manner.
Contents |
Project documentation
The marks for the project documentation will be allocated as follows:
Literature review, research, and discussion: 5%. You will summarize existing techniques in the literature relevant to your project, and include proper references. You will evaluate your choice of technique with respect to other techniques in terms of what is achievable by you, both in terms of difficulty and time for implementation.
Theory of operation: 10%. You will explain the theory of operation behind your project, using the language of signal theory. You will include relevant mathematics, and (original) Matlab code and plots to illustrate. The discussion is expected to be targeted specifically towards your project, so you will also use Matlab code and plots to show how well your implementation supports (or doesn't) the theoretical basis.
Explanation of implementation: 10% You will explain your implementation, its structure, and its operation. The discussion will include performance evaluation, discussion of alternative implementation techniques, user documentation on how to use the program, and so on. It will also include evaluation of your program against the goals of a potential user of the program, its limitations and advantages, and discuss what improvements could be made to the program in future.
Systems and development perspective: 5%. You will discuss how your program fits into a broader context in which the program could be implemented as part of a product. You should discuss how you would realize the program on realtime hardware, how your program would fit into a larger system (with some realistic examples), and in what ways your program and the larger system could be made into a product. Your overall engineering approach to the project will also affect this portion of the mark.
Documentation length and quality
Your written documentation must be clear and concise. Do not try and "blow up" your documentation with verbose explanations or (worse) text copied from other sources. Make every paragraph count. Marks will be deducted for excess verbosity or lack of clarity.
Similarly, don't produce dozens of plots without a good reason for each. Demonstrate your engineering (and communication) skills by choosing the plots that best illustrate your point(s), and explaining them carefully. (Plots without explanations, by the way, are worthless.)
There is no hard and fast rule about length. If, however, your total documentation exceeds about 5,000 words, you should ask yourself whether your documentation is properly focused. You can also ask an instructor for feedback.
Project implementation
The project implementation will be assessed as follows. Note that you must deliver a working program on a CD to the instructor. If you Matlab program fails to run when the instructor is assessing it, you will receive a reduced mark (possibly as low as zero).
In-lab demonstration: 5%. The instructor will ask you to demonstrate your working program in the lab. The overall quality of the program and the preparedness of your demonstration will be assessed.
Functionality: 10%. This assessment is based on how well your program meets the expectations set out in the project description.
Quality of implementation: 5%. This assessment is based on how well you have constructed the program. Is the user interface well-thought out? Is the code well-structured. Does the program run efficiently?
Workbook
The workbook is your record of your activities and progress in the subject. You should use it to record your work done in the labs, in your team, and individually. It is not expected to be a copy of everything you do, but to be a focused repository of the key and important things that you have done and learnt. The workbook assessment will be split into:
Labs: 6%. Your lab work should be documented, with key points learned and key points not understood (and how you subsequently solved them). Be careful not to simply paste in code or plots without understanding what they mean. A plot with meaningless axes, for example, shows the instructor that you have not understood that part of the lab.
Project work: 4%. Record your team meetings, actions, issues, and so on. Also include notes on your individual work -- what you did, how long it took, feedback from other team members, and so on.
Individual participation
All team members are expected to participate and contribute actively to their project documentation and implementation. The marking guidelines above apply to individuals as well as the team as a whole. Do not simply assign team members to completely different parts of the project, as individual team members will have their marks adjusted according to their participation in each and every aspect of the project.
Example 1: Team member A works only on the Matlab implementation, while team member B works only on the documentation. "A" is therefore eligible to only receive marks for the implementation, and will receive zero for the documentation. Conversely, "B" will receive zero of the marks for the implementation.
Example 2: Team member C does all of the literature review and research. Team member C can therefore receive up to 5 marks for this part of the documentation, while all other team members will receive zero.
Summary: all team members are expected to contribute all aspects of the project. In addition, they must demonstrate this contribution in the Wiki logs and in their workbook.
