Software Engineering Capstone Project
SEG4910 / SEG4911
Course Description (en Français)
Lecture Notes (This link can only be accessed on campus.)
This course sequence is the “capstone project” in the undergraduate software engineering curriculum which is accredited by the Canadian Engineering Accreditation Board. For more information about licensing as a professional engineer please the web site of the Professional Engineers of Ontario. The following quote sets out the guidelines for what the CEAB expects in a capstone project:
"Engineering design integrates mathematics, basic sciences, engineering sciences and complementary studies in developing elements, systems and processes to meet specific needs. It is a creative, iterative and often open-ended process subject to constraints which may be governed by standards or legislation to varying degrees depending upon the discipline. These constraints may relate to economic, health, safety, environmental, social or other pertinent interdisciplinary factors.
The engineering curriculum must culminate in a significant design experience which is based on the knowledge and skills acquired in earlier course work and which preferably gives students an exposure to the concepts of team work and project management. A research project may be interpreted as engineering design provided it can be clearly shown that the elements of design, as noted in the definition, are fulfilled in the completion of the project.”
The course takes your project through one complete software lifecycle in six iterations over two semesters. You are responsible for organizing yourselves in teams of 4-6, and finding a project with a real customer. Here are a list of customers who have projects you could work on if you have not found one yet. You must work in the same group on the same project during both semesters (SEG4910, SEG4911).
The deliverables for the course and the "process" we are following have been customized to fit the needs of SEG 4910/4911. They are based on RUP (Rational Unified Process) which is a proposed industry standard from IBM for defining software process. However, agile methods are relevant to the small project teams and relatively "quick" timeline of the course. This chapter on RUP and agile methods is relevant, RUP xp , as is this open source slide deck on the SCRUM methodology. Prof. Lethbridge also has an excellent list of references which are very relevant to this course. In addition to lectures, each group must their own individual review meeting with the instructor on a regularly scheduled basis (minimum monthly). There will be a technical audit at the each of each semester to walk through the system code and development environment and to validate the contribution of each group member.
You will need to invest time in the development environment you set up and the coordination of group work. In previous classes, teams have opted to use the facilities at www.github.com that provide source control, bug tracking and other tools for free.
PLEASE BE AWARE OF THE FOLLOWING:
· Information about academic fraud (found at this link: www.uottawa.ca/academic/info/regist/crs/0305/home_5_ENG.htm ). Please take note that although the academic fraud regulations webpage dates back to 2003-2005, the regulations have remained the same and still apply.
· Class attendance is mandatory. As per academic regulations, students who do not attend 80% of the class will not be allowed to write the final examinations. All components of the course (i.e laboratory reports, assignments, etc.) must be fulfilled otherwise students may receive an INC as a final mark (equivalent to an F).
Back to top
There are deliverables associated with each iteration. These are worth 60% of your final grade (10% for each iteration). The evaluation filled out by your customer is worth 20%, and the evaluation of the instructor on how effectively and professionally your project was managed is worth the final 20%. All deliverables for review should be submitted in electronic form by email to lpeyton@uottawa.ca and must be approved by the customer before being submitted.
Deliverables are graded based on engineering quality, writing or presentation quality, and completeness. UML notation should be used for all engineering diagrams. There is a template or guideline for each deliverable (click on the links below for each deliverable in each iteration).
Late Penalties
Each deliverable should go through a process of review within the group, with the customer and with the professor who gives the final approval to each deliverable (and a grade). You are responsible for managing that process. If a deliverable is late, a penalty of 1 mark (out of 10) will be deducted from the grade for the deliverable. If the deliverable is more than 1 week late a penalty of 2 marks (out of 10) will be deducted. Deliverables more than 2 weeks late will receive a mark of 0.
Milestone 0: "Kickoff" & Registration Due Week 2, Semester 1
1. First draft of Project Definition
Milestone 1: "Approved" & Definition Due Week 4, Semester 1
1. Final version of Project Definition
Milestone 2: "Hello World" & Analysis Documentation Due Week 9, Semester 1
2. Project Status Report including screen shots and description of "Hello World" version of system.
The "Hello World" version of the system demonstrates that you have set up your development environment and are able to create rudimentary implementations of the major components of your system that interact with each other. You will also have mocked up or implemented key portions of your user interface to define the look and feel for your system ... but they will not be incorporated into the "Hello World" system. The user interface mockup is part of the analysis report.
Milestone 3: "Demo" & Quality Assurance Plan Due Week 13, Semester 1
1. Quality Assurance Presentation (see Presentation Guidelines)
2. Project Status Report including screen shots and description of "Demo" version of system
3. Customer Evaluation (English or Français)
4. Technical Audit (There will be hands-on review of each project during the semester towards the end of the semester. This will be scheduled individually with each group.)
The "Demo" version of the system demonstrates that you have a running system that can be used to illustrate and test the critical scenarios for your system. The actual implementation may have completely hard-coded data and may have significant functionality stubbed out and missing. However, all major components are present and interacting and your interface is real and consistent with the mockups from your analysis report. Your build and test environment should be in place so that it is possible to do an automated build and acceptance test and start building your complete test framework.
Milestone 4: "Alpha" & Design Documentation Due Week 5, Semester 2
2. Project Status Report including screen shots and description of "Alpha" version of system
The "Alpha" version of the system demonstrates that you have a complete architecture defined and running. All interfaces on all components are implemented and conform to your design report. The actual observed behavior of your system may not be significantly different from your "Demo" version and there will still be significant functionality stubbed out or broken, but it should run off real live data. Your complete test framework will be in place and it will be possible to go through a complete test run and create a quality assurance report although many tests will fail and there will be some tests which can not be done at all. It may be possible to deploy the "Alpha" version to your customer for evaluation but only under carefully controlled conditions which make clear the limitations of the system.
Milestone 5: "Beta" & Quality Assurance Reporting Due Week 9, Semester 2
1. Quality Assurance Presentation II (Report on the plan from your first presentation and discuss deployment strategy) (see Presentation Guidelines)
2. Project Status Report including QA Report, screen shots and description of "Beta" version of system
The "Beta" version of the system demonstrates that you have a complete running system that can be used and deployed to a customer under controlled conditions. All planned features should have been coded although there may be many and significant defects in the implementation. However, the quality of the system should be a known quantity defined by the results of running through the complete test framework and as logged in your defect tracking system. There should be a set schedule that dictates when the complete test framework is run (daily, weekly, monthly ...). Your QA report should contain results from at least two such runs to demonstrate the progress that is being made to stabilize the system.
Milestone 6: "Deployed" & Final Report Due Week 13, Semester 2
1. Final Report
2. Final Customer Evaluation (English or Français)
3. Technical Audit (There will be hands-on review of each project during the semester towards the end of the semester. This will be scheduled individually with each group.)
The "final" version of the system should have been deployed to your customer by this point, although typically its use will still be controlled. There may still be significant work or improvements needed but they should be clearly identified in your defect tracking system and quantified in terms of effort required. The system should be packaged including executables, source code, and documentation. It should be a self-contained bundle complete with instructions so that it would be reasonable for any competent software engineer to take over the project as is. You should have also done a project post mortem that summarizes the achievements of the project, member contributions and the lessons learned.
Back to top