Term Project Finalization

In Class Demo

On the last day of class, each group will give a five minute demo of their project. The purpose of this demo is to showcase the features and quality of your application in addition to providing explanations for any unclear portions of the final product.

Some marks will be assigned for the presentation, and each group member present should do some of the talking.

Agreed Upon List of Who Did What

In class, on the last day of class, submit a hard-copy (print out) listing of who did which parts of the project. This should simply be an itemized list of tasks and the names of group members who performed them. All group members present that day must sign it. This ensures that everyone agrees. Those who don't come to class miss their chance to check it. The list is not worth any marks, but if not submitted, or if terribly incomplete, then all group members get 0 on the project. The list should include the contributions of each member, such as:

• Design, technical & coding contributions.
• Application asset creation (art work, sound…) and UI design.
• Service to group (debug someone's code, or resolve Git issues).
• Any significant challenges faced that delayed their work (such as a computer being stolen).

Individual Peer Review

Each group member should electronically submit a self and peer review. It will be marked based on the quality of comments and evaluations. Comments should be in the form of constructive feedback, and supported by evidence. Your fellow teammates may see the feedback that you provide to them.

Submissions must have both of the following:

• Feedback to group members:

  • 1 paragraph about each other group member. Suggested discussion points include:

    • Teamwork: What role did he/she play in the team? Were they easy to work with? What did they do well? How could they improve? How effective were they as a Scrum Master?
    • Technical Skills: Did his/her work always meet your expectations? What did they do that impressed you? How could they improve? How was their coding style?
    • Communication: How clearly can he/she communicate (written and verbally)? How can they improve?
    • Group Interactions: Did they work well with others? Did they arrive on time? Did they complete their work on time? Generally, how could he/she improve as a team member?

  • Comments about each group member will be collected and provided to him/her if requested. The name of the student who wrote the comment will not be included, but depending on what you say, they may figure out who said it. The idea is to proved each student with honest feedback about what they are like to work with, and how they could improve. Imagine you are writing them a reference letter, what would you say? This type of feedback is hard to get, so pay careful attention to what your group members say!

• Private feedback to instructor:

  • Required part: Self evaluation of personal contribution to the project. Use the same list of points mentioned for the anonymous section above.
  • Optional part: Comments about each other group members that will not be distributed to other group members.
  • Optional part: Comments about project in general.

Giving constructive criticism does not cause a group member to lose mark. Each of us have things we can improve on; this is an opportunity to help your group members identify their strengths and weaknesses.

Client Review

An outside "client" will provide feedback on each project and rate the quality according to their needs and expectations. Based on this rating, groups may be given a small number of bonus marks to reward excellence.

The best project will be selected for an award, assuming at least one project meets the client's expectations. In this case, each member of the team producing the winning app will receive a prize (unrelated to their grade).

Notes on Marking

These deliverables give group members feedback and help assess individual contributions to the group. Students who are not assets to their groups may get 0 on the project, and other group members may gain marks. For example, if one group member is in charge of the settings but fails to work on the project, he/she may get 0 on the project and other group members might not be penalized for poor handling of the settings.

Other mechanisms will be used to review individual performance, such as reviewing number and quality of Git check-ins.

_{^{Guidelines for project finalization courtesy of Dr. B Fraser}}