48024 assessment criteria, spring 2006
From SoftwarePractice.org
As per the class discussion of 21st August 2006, the marking for the project is divided up as follows:
- Project documentation: 35%
- Project implementation: 25%
(The original 10% allocated for the workbook have been split between the documentation and implementation parts of the project.)
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 while doing your project!
Note: all projects are of equal difficulty. This is because they are all programs that could potentially be taken much further than any team could realistically implement in this subject. One of your goals, then, is to carefully follow the miniature Unified Process and the recommended techniques in order to 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:
Analysis: 10%. You will create and apply usage scenarios, use cases, and related artifacts to determine the scope and functionality of your program. All of your analysis artifacts must be reasonable, realistic, and consistent both with each other and with your "downstream" artifacts i.e. the UML models and the code. Together, they must paint a complete "picture" of what the program is, what it does, and why.
UML models: 15%. You will choose and create appropriate UML models and contracts to describe and document the design of your program. You will not be assessed on the quantity of your diagrams, but on the care, depth, and insight that you apply to choosing and designing your models. The models and contracts must be consistent with your analysis artifacts and with the program implementation. All diagrams must be accompanied by careful explanation -- a diagram without explanation is worthless.
Design of test cases: 5%. You will carefully design unit test and system tests based on your contracts and use cases. Part of this assessment is based on your choice of test cases: choose test cases that provide the most benefit in terms of locating potential weaknesses in the program. Carefully-chosen test cases will yield higher marks than a scatter-shot or exhaustive approach.
Quality and structure: 5%. You will be assessed on how well you have explained your design work. Careful structure, explanation, good writing, and thoughtful use of Wiki features will be considered in this part 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 diagrams without a good reason for each. Demonstrate your engineering skills by choosing your models and diagrams carefully, and explaining them carefully.
There is no hard and fast rule about length. If, however, your total documentation exceeds about 7,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 your program fails to compile or run when the instructor is assessing it, you will receive a reduced mark.
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 part of the assessment is based on how well your program meets the expectations set out in the project description.
Quality of implementation: 5%. This part of the assessment is based on how well you have constructed the program. Is the code well-structured? Is it adequately commented? Does the program run efficiently?
Quality and design of user interface: 5%. This part of the assessment is based on the overall quality of your user interface. Have your shown thought in the design and layout of your interface? Have you made effective use of Java UI support libraries? Have you made design sketches to work through design issues? Do your system tests / use cases run smoothly and easily (from the point of view of the user)?
Individual participation
Team members are expected to collaborate on all aspects of the project. You are learning how to create and apply UML models and how to tie those in with your implementation and testing activities. You are also learning how to express your designs and communicate them to others. Thus, it is counter-productive to the subject goals for team members to focus only on one or two aspects of the project and to ignore others.
Therefore, the marking criteria above apply to individuals as well as the team as a whole. All team members should make sure that they actively participate in all project activities, and that they demonstrate this participation in the Wiki documentation and during your project demonstration.
Scenario 1: Team member A works hard on only the implementation, while team member B works only on the documentation of UML models. The instructor expresses concern about the lack of integration and coherence between the UML models, the code, and the test effort. He also points out that neither student has achieved what the subject is designed to do. He awards the team a low-ish mark because of this lack of coherence, and reduces the marks of A and B by a further 20% because of their lack of participation in all aspects of the project.
Scenario 2: While team member A does a significant portion of the implementation, he realises that his team members will be left without any understanding of the connection between the UML and the Java program if he does it all. So, he works with his team members to encourage them to implement significant portions of the UML models, and supervises the integration and testing effort. In the process, he realizes that his understanding of the UML also had significant gaps. The instructor is impressed by the quality and coherence of the design and implementation, and the whole team receives a high mark.
Process and progress
As per the Subject Outline, failure to make progress in any iteration can potentially result in reduced marks. Please make sure that you make concrete progress in each iteration and update your documentation accordingly in order to demonstrate this progress.
Project Demo How-to/Rules
- 15 minutes only
- You must be ready to go when your turn comes up
- No questions from you (why? too late!)
- Each team member must demonstrate ONE system test case. Bring printed copy of both the test case and the corresponding use case.
- You must hand in a CD with a compiled program, all source code, and all auxiliary files, at your demo.
- Documentation (on wiki) due at midnight on Friday November 10th.
