The description below comes from the original course proposal. The details and design of the actual course in each year may differ considerably.

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.

The very nature of this course supports students in achieving the learning objectives. There are three players in this course: the student Team, a Sponsor, and the course Instructor.

The Sponsor is a client who has expressed a need for a substantial quality software product, and commits to spending a significant chunk of time with the Team needed to elicit the requirements for the product. In addition, the Sponsor signs off on the requirements document and also signs off, via acceptance testing, that the final product satisfies the requirements.

Teams: Students must work in Teams of no less than three members. Team members will evaluate the contribution of other members of the team.

Each Team will be required to meet with their Sponsor as required in order to elicit requirements.

There will both oral and written deliverables that the students must provide throughout this project.

Project Selection: The Team must develop a significant software product. The Team is responsible for finding a Sponsor. The Sponsor may be any faculty member of the York CSE department who will provide the requirements for the product and do the final acceptance testing. The Instructor may at her or his discretion, appoint as a Sponsor somebody outside of the Department (e.g. a suitable sponsor from industry).

Important Note: The Team is responsible for all aspects of the course from requirements elicitation to production of the final code and testing. The Instructor will meet on a regular basis with the Teams, and will assist where possible to deal with the problems that inevitably arise during an open-ended project of this nature, whether the problems are of a technical nature or of a human, social or organizational nature (team cohesiveness, issues with the Sponsor, etc.). However, Teams doing this project also need to recognize up-front that many things can go wrong. Individual Team members might withdraw. The Sponsor may not provide the input hoped for, or might withdraw prematurely. The project may prove too challenging. If such events happen, and the problems cannot be resolved by the Team (assisted by the Instructor), then students may not be able to pass this course in the first instance. In this sense, this course is “risky”, just as is software development in any industrial setting.

The Instructor is responsible for all grades assigned. Where relevant (see 1, 3, 4, 6 below) the Instructor will receive evaluative input from the Sponsor or the Teams themselves. A possible evaluation scheme is presented below. Please see the reading list for texts that discuss how to write software requirements, design and testing documentation.

By the end of first term:

1. (10%) Each Team must present an initial requirements document to the Instructor and the Sponsor. The grade will be assigned based (partially) on feedback from the Sponsor. The Team must provide a technically complete and literate requirements document written to professional standards. This document must be at a level that allows the Sponsor to understand and evaluate whether his or her goals are clearly and completely expressed.

2. (10%) An oral slide presentation to the Instructor of the preliminary design and documentation. Each team member must present an aspect of the whole design. The team must also provide the Instructor with a technically complete and literate design document at the beginning of the presentation written to professional standards. The grade is based on the presentation and documents.

By the end of the second term:

3. (10%) The final requirements documents (evaluated as discussed in (1)). The Sponsor must sign-off on this document.

4. (20%) The usability and correctness of the product via acceptance testing. The Instructor will assign a grade based on feedback from the Sponsor as well as his or her own judgement of the product. The team must provide the Sponsor and the Instructor with the final software product (code, installation procedures, and manual).

5. (40%) Each team member must present to the Instructor an aspect of the whole project. C0mplete design and testing documents must be provided to the Instructor at the beginning of the presentation. The grade depends on both the presentation and the documents. This part of the evaluation usually assumes that the product has already been shown to work as in (5).

6. (10%) Team self-assessment of each other.

The reading lists from COSC4312 and COSC4313 applies.

• Sommervile. Software Engineering, 8th edition, 2007, Addison-Wesley.
• Pressman. Software Engineering: a practitioner’s approach. McGraw Hill, 2005.
• Ian Bray, An Introduction to Software Requirements, Addison Wesley, 2002.
• Documenting Software Architectures. P. Clements et. al. Addison-Wesley 2003.
• Software Engineering. S.L. Pfleeger, Prentice Hall. 2001.
• The Unified Modeling Language Reference Guide. J. Rumbaugh, G. Booch, & I. Jacobson, Addison Wesley Longman. 1999.
• Design Patterns and Contracts. J.M. Jezequel et. al. Addison-Wesley 2000.
• Seamless Object Oriented Software and Architecture. K. Walden, and J.-M. Nerson, Prentice Hall, 1995
• Object Oriented Software Engineering with Eiffel. J.M. Jezequel. Addison-Wesley, 1996
• Facts and Fallacies of Software Engineering. Robert Glass. Addison-Wesley 2003.
• Lean Software Development.: an Agile Toolkit. Mary and Tom Poppendieck. Addison Wesley 2003.
• Software Fundamentals: Collected Papers by David Parnas. Editor David weiss. Addison Wesley 2001.
• Balancing Agility and Discipline. Boehm and Turner. Addison Wesley 2004.
• Blaha and Rumbaugh, Object Oriented modelling and Design with UML, Prentice Hall, 2005
• Meyer, Object Oriented Software Construction, Prentice Hall, 1997.
• Software Fundamentals: Collected papers by David Parnas, Collected papers of David Parnas, Addison-Wesley, 2001.
• Design Patterns. E. Gamma et. al. Addison-Wesley, 1995.

The Standish Group's CHAOS research is a software industry standard tracking the results of 30,000 completed software projects since 1994. Their statistics indicate improvements since 1994 due to a variety of factors including better process management, skilled project managers, a commitment early on to firm basic requirements and formal methodologies. Even so, the results for the year 2000 indicate that only 28% of projects succeeded (on time, within budget and with the functions originally specified), 23% of projects failed (i.e. never managed to complete), and 49% of projects were “challenged” (e.g. on average 45% over budget, 63% over time, and with only 67% of the required functionality) .

The purpose of the project course is to provide our students with a large software project that will be scrutinized for good design, correctness and quality, and that will more closely simulate the competitive industrial setting. At the same time, the academic setting will allow us to introduce best software practices. The project course is seen as the context in which all their software engineering knowledge comes to practice and fruition.

This course complements the newly introduced courses on Software Engineering Requirements and Testing (COSC 4312 and 4313). Knowledge obtained in these two courses will be applied in a practical setting throughout the duration of the project. This will make the rationale behind established software engineering practices apparent to our students, and will deepen their understanding of what it takes to build large software systems.