CSC290 Communication Skills for Computer Scientists

Group Project

Learning to work in a group is a major part of this course. You will work collaboratively with your group to create an open-source game in Python. You will use the communication tools typically used in the community, and you will work with your group in a professional way. The group project is divided into the following components:

Group Membership Assignment

Groups will be assigned in tutorial 3. You will not be able to choose your group, so that you gain valuable skills working with people that you may not have met. Working with strangers is something you will frequently have to do in industry.

Project Selection

You may select a game to implement from the following list:

The harder games are realtime rather than turn-based. Your group will not receive extra credit for choosing a harder game, but can do so out of personal interest. You may also propose a game not on this list for instructor approval. A maximum of 1 group per tutorial section can choose the same game.

Programming Language

I recommend that your team use Python and a library like pygame to write your game. However, a team can unanomously decide to use a different programming language, but only if every team member agrees with the decision. Although you can use any software package you want, you should implement the game yourself.

Software

Unless agreed upon otherwise with the instructor, your project code will be open-source and hosted on GitHub. If your team would like to use a different platform, or keep the code close-source, please speak to the instructor.

Since many of these games are trademarked, your repository name should avoid using the "official" names of the game.

We will be using Microsoft PowerPoint as the standard presentation software for this course. You will be required to set up your slides to advance automatically without intervention, to avoid running over time. If you do not have MS PowerPoint, you can download the software from here.

Expectations

All portions of the assignment must be completed as a group. Every student must participate in all parts of the group assignment in order to earn the marks. If a group member is not contributing, please contact the instructor immediately.

You may have limited class time during tutorials to work on the group assignment. Your attendance to these classes will be recorded. Your attendance to these classes are a way that you demonstrate to the instructor that you are participating in your group work.

In the end, your primary responsibility is to your team members. If they report to me that you have not contributed to a part of the assignment, you may be removed from the group and receive a zero for all parts of this assignment.

Late group work will be assigned a grade of zero, so please submit early! The presentation slides must be submitted on time so that the TAs has time to review and queue them for the presentation day.

Presentations must be delivered in tutorials, as scheduled. Please contact the instructor in advance if you require special considerations. In case of illness or other disasters, contact the instructor as soon as possible.

Project Plan

A project plan outlines the various aspects of a project to internal stakeholders, including the projects scope, goals, stakeholders, deliverables, and deadlines. You can find many project plan formats on the internet, and adapt them to your particular need. You will be asked to include information not traditionally a part of a project plan. You may also look for templates for a "project charter" or "project proposal", which serve slightly different purposes.

Your project plan should answer the following questions:

• What is your project?
• What are its success criteria?
• How long will your project take?
• How will you divide up the work? How long will each piece take?
• What resources do you need?
• How do you measure success?
• How will the team members interact with each other? (online tools, in-person meetings, etc)
• Who will be responsible for submitting the deliverables on MarkUs?
• What are your milestones? Can you set dates for these to keep you on track?
• How will you handle the loss of a team member (eg. if your group member decides to drop the course)?
• What other risks are there that could potentially hinder success, and how will you overcome them?

Your plan must include a Work Breakdown Structure that breaks down the work into managable tasks, and assign those tasks in a fair way.

Format

There is no set template for this assignment, and you may create your own template to suit the needs of your team and project.

• http://s.casual.pm.s3.amazonaws.com/toolkit/WebsiteDesign.pdf
• http://isoconsultantpune.com/wp-content/uploads/2015/05/MassCommunicationProjectCharter.pdf

Grading

Your document will be marked for the following:

• Content (60%) Have you presented a well thought out plan for working as a team and for dealing with team issues? Have you identified the project goals, milestones, and other important factors for your team?
• Organization (20%) Have you formatted the document as a project plan document, organizing the information into appropriate sections with appropriate headings?
• Grammar & mechanics (20%) Are your sentences well-written and grammatically correct?

You should carefully read the rubric before starting.

Design Review Presentation

Planning is an important step in preparing for a successful software project. Many organizations review software design prior to writing any code. Assume that the audience for this presentation are your peers and people with more software design experience than your group.

To demonstrate planning and preparation, your group will present your software design in a presentation. The presentation should answer the following questions:

• What is your project?
• How will you structure your code?
• What are the different components?
• How will the different components talk to one another?
• Are there any portions of the code that will be difficult to write? How will you write it?

You should also include a class diagram in one of your earlier slides.

Your presentation must be between 6 and 7 minutes long, and each team member must speak for at least 1 minute. To ensure proper timing, your presentation slides must be set up to advance autoamtically without human intervention. Improper setup or presentations that runs over time will result in a 10% penalty.

Presentation slides must be submitted on time on MarkUs, so that the TAs has time to review and queue them for the presentation day. Only one person per group should submit the slides. Your slides must be no more than 15MB.

You must use MS PowerPoint to create the slides. If you do not have MS PowerPoint, you can download the software from here.

Grading

Your presentation will be marked for the following:

• Introduction (10%) Are your introductions clear, informative, and effective in "hooking" the audience? Do you have an effective agenda slide?
• Content (30%) Do you clearly describe the game mechanics? Do you use a class diagram to clearly explain design decisions? Do you describe key decisions, and persuasively explain why you chose certain designs over others?
• Conclusion (10%) Do you have a clear and effective conclusion that summarize the presentation content, and an effective call-to-action that reflects the presentation goals?
• Slides and Visuals (20%) Are your slides clear, succinct, cohesive, and enhace the presentation? Is your text readable, including texts in all diagrams?
• Presentation Delivery (20%) -- Individually Graded Are you audible throughout the room? Do you make good eye contact with the entire audience? Do you speak naturally and enthusiastically? Is your pronounciation clear? Do you speak too quickly or too slowly? Do you say "um" or "uh" a lot, or make distracting gestures?

You should carefully read the rubric before starting.

Code Commit

Each team member will submit one substantial commit, to show both their participation in the project, and to show the use of good coding practices. The commit should be decently sized, but not too large since each commit should be atomic. However, the commit should not be a simple typo fix or other trivial code.

Each submission will be graded on whether the code is readable, whether the commit message is clear, and whether the commit is consistent with the rest of the project.

Grading will be out of 4. With:

• 1 point for a non-trivial, atomic commit. If a commit is deemed trivial, you will receive a grade of 0/4 for this portion of the group assignment.
• 1 point for a commit message that follows the guidelines discussed in class.
• 2 point for code that follows the guidelines discussed in class.

Documentation / Progress Report

Each team member will write a short (1-page) description of all their code contributions to the project, and how their team members should use the code.

Your writing can be conversational, like an email or a letter. It can be more like a "progress report" rather than a formal documentation. Direct your documentation or report to your team mates, so that they can more fully understand what you've built, and how your contributions fits in the context of your project. However, your report should still be understandable by your TA, who does not know the full details of your project.

Submit a PDF file to MarkUs.

Grading will be out of 4. With:

• 1 point for substantial completion.
• 1 point for structure and grammar.
• 2 points for a clear description of your contributions, decisions, and how your team members should use your code.

Project Repository

The team's entire GitHub repostory will be graded. The repository should:

• Have a proper README with a description of:
  • The game
  • How to install and ruhn the game
  • How to play your implementation of the game
  • At least one screenshot of your game
  • License and author info (it doesn't matter what license you choose, but you should choose one)
• Have documentations that describe
  • Your project's directory structure
  • The major classes and functions
  • At least one example of how to extend the game (instructions on what to do if you want to add "x" to the game, for some "x" that you choose)
• Have commits that
  • Are atomic
  • Follow the commit message guideliens discussed in class
• Have good quality, including:
  • Properly named variable and function names
  • Docstrings that are descriptive and appropriate
  • Code that follows the standard guidelines for the language (e.g. PEP8 for python)
  • Atomic and testable functions
  • Code that contains no duplications
• Be well organized, cohesive
• Have roughly even contribution across all team members
• Have proper grammar and spelling

Examples

Here are some examples of project repositories with good READMEs and documentations

• https://github.com/tasdikrahman/spaceShooter
• https://github.com/stephank/arashi-js/blob/master/HACKING.md
• https://github.com/mbostock/polly-b-gone/wiki

Submission

Submit a link to your repository on MarkUs.

Final Presentation

Each group will present their work to the tutorial group. Like in the design review presentation, each group will have 6-7 minutes to present their work, and each team member must speak for at least 1 minute. To ensure proper timing, your presentation slides must be set up to advance autoamtically without human intervention. Improper setup or presentations that runs over time will result in a 10% penalty.

Your presentation must have a clear goal that is explained in the introduction, and reiterated in the conclusion. Your goal may be different. Here are some examples:

• Explain an interesting way that you solved a problem, and advocate for it.
• Convince your classmates to install your game.
• Convince your classmates to extend your game.

Presentation slides must be submitted on time on MarkUs, so that the TAs has time to review and queue them for the presentation day. Only one person per group should submit the slides. Your slides must be no more than 15MB.

Due to time constraints, your presentation cannot include a demo of your game. GIFs or videos are permitted so long as the slides are under 15MB.

Content

Your presentation should include:

• A description of how to install and play your game.
• At least one screenshot of the game.
• The way that your github repo, directory and code is structured.
• At least one thing that you learned from building the game.

Grading

Your presentation will be marked for the following:

• Introduction (10%) Are your introductions clear, informative, and effective in "hooking" the audience? Do you have an effective agenda slide?
• Content (30%) Do you clearly describe how to install and play your game? Do you include at least one screenshot? Do you explain the way that your code is organized? Do you explain at least one thing that you learned from building the game?
• Conclusion (10%) Do you have a clear and effective conclusion that summarize the presentation content, and an effective call-to-action that reflects the presentation goals?
• Slides and Visuals (20%) Are your slides clear, succinct, cohesive, and enhace the presentation? Is your text readable, including texts in all diagrams?
• Presentation Delivery (20%) -- Individually Graded Are you audible throughout the room? Do you make good eye contact with the entire audience? Do you speak naturally and enthusiastically? Is your pronounciation clear? Do you speak too quickly or too slowly? Do you say "um" or "uh" a lot, or make distracting gestures?

You should carefully read the rubric before starting.