A well-designed software product is more than just a computer program. A software product consists of quality code, a well thought out design developed via disciplined professional engineering standards, appropriate literate documentation including requirements, design and testing documents, a manual, and the appropriate installation files and instructions needed to get the product to work. The product has to be correct (i.e. it must satisfy all the requirements specified by the client), usable, efficient, safe and maintainable.

The goal of this course is to provide students with an opportunity to integrate what they have learned in earlier computer science courses, deepen their understanding of that material, extend their area of knowledge, and apply their knowledge and skills in a realistic simulation of professional experience. The end result must be a substantial software product.

This course is run on a tight schedule over the Fall and Winter Terms; work is ongoing and regular. The course is intended to help with the transition from being a student to being an active professional in industry. During the course students are expected to perform independent study, plan their work, make decisions, and take ownership of the consequences of their mistakes.

A combination of teamwork and individual work is required. The requirements elicitation, requirements analysis, design, coding, testing, and implementation of the product will be a team effort. However, individual responsibilities must be clearly identified in every deliverable.

This project will be of significant size and like most industrial projects it will be time and resource limited. Students must meet the specified deadlines. As a result, they will have to set their goals and plan their work accordingly.

Students must apply sound mathematics, good engineering design, and algorithms throughout the project. However, they will also need to apply heuristics and design patterns, or “rules of thumb”, where sound, well-understood algorithms are not available. Any such heuristics must be clearly identified and supported by arguments that justify their choice. The teams will be required to show that the heuristic cannot fail in a way that will violate safety restrictions or other restrictions designated as critical.

• 10%: Precise Requirements Document (December 2015)
• 10%: Design Document and some working code (January 2016)
• Most code working (February 2016)
• Testing Document and all code working (April 2016)
• Presentation (May 2016?)
• Final revised documents, deployment of code, and user manual