Tags: %TAGME{ tpaction="" web="SCMP391" tag="" }% view all tags

Project 4 - Team Project

Moodle Link

Chat.jpeg TTT.png pong.png


The goal of this team project is to update your project 3 for better User Interface, functionality and features as well as to improve code quality. This has the following sub-goals

  1. To learn the processes of improving code quality
  2. To explore and improve the quality of the user interface
  3. To design and add improved features

Project 4 Team Assignments

Team Name Team Members Project and Link
Team 1 Solorio, Christian
Iduma, Elizabeth
Wilhelm, John
Tic Tac Toe
Team 2 Coire Gavin-Hanner
Seaver, Alexander
Team 3 Fukuyama, Miku
Vance, Spalding
Chat System
Team 4 Olivier, Daniel
Juviand Rivera
Murphy, Aidan
Chat System
Team 5 Schutz, Joey
Twitchell, Natalie
Basting, Preston
Chat System
Team 6a Yanqi Xu
Alperin, Jessie
Chat System
Team 6b Ogilvie-Thompson, Harold
Grigull, Bennett
Chat System
Team 7 Neau Tess
Khan, Malik Ahmed
Ghada Bokbauk
Chat System


Step 1 - Propose System

Due: March 24, midnight

Pick the system (from above) you wish to do. The first step is to consider the features in your program. Meet as a team and come up with five or more possible new features. This could include:

  • More then two users in the same sessionMultiple groups of user
  • A basic design of the user interface.
  • A list of desirable functions
Step 2 - System Design

This includes the a design of the following:

  1. A design of the architecture of the
Finally, considering that your team as a total of about 30-40 man hours to complete the updates, pick the features that you will attempt, justifying it based on the estimates and priorities above.

Turn in the writeup on Moodle.

Step 2 - Propose Code Quality Improvements

Due: March 27, midnight

The first step will involve evaluating and improving code quality. Your team will meet with the professor to review the code, and to consider the quality in terms of what has been presented in class. You will then propose a set of changes to improve the code.

Make a numbered list of improvements to make. For each:

  • Explain the problem, giving specific references to factors from the text/class.
  • Explain how you will improve the code, referring to the text.
  • Estimate the time required to achieve each change.
  • Assign the improvements to (a) teammate(s).
Turn the list in on Moodle

Step 3 - Propose user interface improvements

Due: March 29, midnight

Review the User Interface of your program. Review the user interface slides and presentation from class. For you program make a list of UI issues or possible improvements. For each:

  1. Describe the UI issue, categorizing based on the criteria given in class.
  2. Give a proposal for how to improve this aspect of the UI.
  3. Give an estimate of the time required to make the update.
  4. Assign each improvement to a teammate.
Turn the list in on Moodle

Step 4 - Complete - better code, better user interface, new features

Due: April 5, midnight

Complete the work from above, turn in the complete work on Moodle (with links to a working system) and be prepared to demonstrate in class.

Project final grading rubric

Criteria Excellent Acceptable Unacceptable
Documented & Maintainable
(The program is well-documented with appropriate names and comments making it easy to understand.)
  • all naming conventions are followed
  • both in-line and header comments are included and clearly explain the what the code accomplishes and how
  • white space is used well
  • most naming conventions are followed
  • some comments are confusing or missing
  • white space is used well in most places
  • poor or no use of naming conventions
  • too few or too many comments are used and they are unclear or inaccurate
  • poor use of white space
Adaptable & Reusable
(The program is modular, using abstraction well and any limitations are clearly specified.)
  • all interfaces between objects are clear
  • appropriate utility functions are used and well-documented
  • most code can be reused
  • most object interfaces are clear
  • some appropriate utility functions are used and documented
  • some code can be reused
  • poor object interface definitions
  • few or no utility functions
  • no code can be reused
Robust & Correct
(The program provides the correct output for all possible input.)
  • the program works completely as expected
  • the output is displayed to specification for all valid input
  • the program responds appropriately for all invalid input
  • the program works as expected for most input
  • there may be minor errors in output formatting for valid input
  • not all invalid input is handled reasonably
  • the program does not produce correct output for even the sample input
  • the program fails to handle invalid input
  • exceptions are not caught
Efficient & Elegant
(The program uses both time and space on the computer effectively, without losing source code clarity.)
  • no extra variables or definitions are used
  • the code is small, efficient yet still easily understood
  • extra variables do not make the code harder to understand
  • brute-force problem solving approach
  • extra variables are pervasive and confusing
  • the code is unnecessarily long and patched together
  25-20% 19-11% 10-0%

Grading Results

Criteria Comments Grade (25-0)
Documented & Maintainable    
Adaptable & Reusable    
Robust & Correct    
Efficient & Elegant    
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2017-11-03 - JimSkon
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback