Software Engineering Capstone Project Course: Rules for Projects

This document contains the rules for the Software Engineering Capstone Project. There is also a pdf version of this document and a French version (version Fran;çais)

1. Group size

Students will normally work in groups of between 2 and 6.

2. Kinds of projects that are acceptable

All the projects must involve serious software engineering work. You must do requirements analysis, design, implementation, testing and deployment. However the details will depend heavily on the project. A project could be a prototype of a more complex system, or a final version of a simpler system. It could also be an enhancement to an existing system. The waterfall model is not acceptable; an iterative approach should be used, and agile methods are highly recommended. All aspects of quality will be important, including maintainability, usability and reliability. You will also have to use project management skills to estimate costs, plan schedules, make sure you don't try to do too much etc.

3. Customers and project selection

Each project has to have at least one defined customer -- the person who has the problem you are solving. This could be a professor, somebody from a company, or the 'open market'. In the latter case, you have to do a market analysis and actually find some people who will review requirements and prototypes and beta-test your product (these people should not be students in SITE). You will spend a lot of time interacting with your customer(s); they will be asked to read your documentation, act as beta testers and complete two questionnaires that will be used to help determine your final mark. Students are responsible for defining their own teams, their projects, and finding customers for their projects. Students will be provided guidance by the professor in charge of the project course, who will email them in the weeks (and months) before the first class with various suggested projects (with customers)

4. Type of software

Anything goes as long as it involves real software development. Some possible types of software include data processing, MIS, personal productivity, e-commerce, telecom, real-time, embedded, games, etc. However, for some kinds of software you will clearly have a harder time delivering something, so you will have to justify the feasibility of the project. Web sites, per se, are not considered valid projects, but the web can be used as the user interface provided there is useful programmed functionality in the site (e.g. JavaScript/Ajax and server capabilities). Projects that purely involve research (e.g. analyzing an algorithm) are not acceptable, although developing software to support researchers would be acceptable if it meets other criteria.

5. Team structure

The professor in charge of the capstone course will act as if he were the CEO of a small company, where each team is a unit of that company. The professor will veto things of which he or she disapproves, and also give students general advice, etc. One member of each team will normally be elected 'project manager'. This does not mean that that person can order the others around, just that he has the prime responsibility for project management. Others on the team may take other specialized responsibilities such as 'chief programmer', 'user interface expert', 'documentation manager/technical writer/configuration manager', 'quality assurance manager', or 'requirements manager'. Part of your documentation will include a description the work each person performed.

6. How will projects be found?

This can occur in several ways. Firstly, if any group of students has a project in mind, they can suggest it to the professor. Secondly, the professor will approach industry and faculty members to see if they have any ideas.

Although not the preferred situation, the professor may accept projects that relate to a student's existing employer. The student should discuss this with the professor in advance. In general, the following should normally apply: a) Capstone project work should be in addition to the paid work, b) the professor in charge must retain the ability to direct the student's work, with the employer being considered the customer, c) the student must be able to stick to the same schedule as other students in the team, and d) the employer must declare in writing that the students will be able to manage their own project according to these rules, and that the project can continue even if the employer changes plans.

7. Financial compensation and intellectual property

Unless the students and customer have an agreement (explicit or implicit) to the contrary, SEG project students retain the intellectual property rights to their project (but only those aspects of the project they actually worked on). They may therefore sell it or derivatives of it for profit. Students have a responsibility to let their customers know this, and give the customers the opportunity to negotiate some alternative arrangement. Students may, for example, receive financial compensation for their project work; if they receive such compensation then the customer will normally retain the intellectual property rights. Any intellectual property arrangements must be disclosed to the SEG project supervisor. In all cases, the SEG project supervisor must be granted rights to read and run results of the project.

8. Schedule

Note: SEG490 and SEG4911 are held concurrently. SEG4910 is the start of the project and SEG4911 is the conclusion. All students in both SEG4910 and SEG4911 attend all student presentations for both courses. The professor in charge of each course will post the schedule of meetings. Some meetings will be organizational in nature (for either SEG4910 or for SEG4911. Others will be presentations, where both groups attend.

SEG4910 (Sept-Dec for out-of-phase students; Jan-April for regular co-op students)

• Compulsory initial group meeting: 3-4 days after classes start.
• The project must be approved by the end of the second week of classes.
• Work on project:
  • Ongoing iterative/agile development with continuous integration
  • All code to be on a hosting site such as Github
  • Agile documentation should typically be on a wiki, and updated as needed. This would include as a minimum an outline of requirements (e.g. user stories or use cases), an outline of the design/architecture, an outline of test procedures and test data to use, and minutes of meetings of the team and with clients.
  • Near the end of the semester, students will present their work so far including an outline of the requirements and design, plus lessons learned and a demonstration. Ideally the software would be in 'minimum viable product' state at this time, although that might not always be possible.
  • Oral status reports presented in class.
• Intermediate evaluation by customers: end of the semester.

SEG4911 (Jan-April for out-of-phase students; Sept-Dec for regular co-op students

• Work on project:
  • Continued agile development, with regular merging of pull requests, updates to the agile documentation, and status reports presented in class..
  • A mid-semester presentation with an overview of the design, and a focus on how quality assurance is being managed. This should include some sort of graphics or table to quantify progress and amount of work left (e.g. issues dealt with, issues remaining). There would be no demonstration, although a few screen shots would be appropriate.
  • A final demo of the running system at the very end of the semester.
  • The final state of the code comments and agile documentation will be taken together to constitute the 'final report'.
• The project must be in its final state five days after the start of the official university exam period, unless otherwise negotiated with the professor in charge of the capstone course.
• Final evaluations by customers: Same date as the project reaches its final state.

9. On peut faire le projet en français.

10. Workload

Each person to put in about 3-4 person-weeks of work (full-time equivalent) for each of the two semesters of the project. This is the normal workload for a 1 semester 3-credit course.

11. Grading

Your grade will be determined as follows.

• 20%: Satisfaction of customers. Computed from two questionnaires completed by your customers worth 10 marks each. One at the end of each of the courses (i.e., each semester). This questionnaire will ask about all aspects of the work including whether the customer's problem was adequately solved, the customer's perception of the quality of the software, whether the students communicated well with the customer, etc. If you do work without a defined customer, then you get 0 for this component. If you have multiple customers, then they will all complete the questionnaire, and the average value will be used.

• 20%: Evaluation of course professor based on the effectiveness of project management and professionalism of the team. There will be a mark out of 10 assigned at the end of each course (i.e., each semester). You will be asked to give regular reports to the professor as the project progresses. At the end of the project, the professor will assess the project management aspects of these. Marks will be given for such aspects as regularity in updates to code and documentation, quality and accuracy of schedules and cost estimates, effectiveness of distribution of work to team members, and overall professional attitude. At the discretion of the course professor, this part of the evaluation can combine an individual grade for each team member with the overall group grade based on their participation, effort, performance and overall professional attitude.

• Team member adjustment: If team members agree that one member of a team contributed more than others, then that member's mark may be increased by up to 5%, with the other team members' marks being reduced to compensate. Such an agreement must be arranged and approved no later than the design deliverable due data (e.g., end of the first month of the second semester).

The following items will be judged by the professor, based on the six deliverables (three each semester).

• 10%: Quality of presentations: Each team will present their work. The presentations will be rated by the professor and other faculty members or customers who attend.

• 20%: Quality of the software's design, including maintainability, usability and reliability. In some projects other aspects of quality such as safety and efficiency will be of great importance. You should provide analyses that prove you have reached satisfactory levels of quality (e.g., the results of usability evaluation, algorithm analysis, proofs of program correctness and/or performance evaluation). The marker will also study your design, looking for weaknesses.

• 10%: Quality of the writing and graphics. This includes writing style, clarity and effectiveness of communication.

• 10%: Completeness of the written material. Good marks if you have requirements, design, test cases, user manual, report on usability evaluation. etc. The exact components of the written material will vary depending on the needs of each project. You have to justify the documentation you produce. Also, don't produce unnecessary documentation. Material delivered late will not count.

• 10%: Complexity/difficulty/innovation of project: If you get a lower mark on satisfaction of customers or quality of the software (e.g., the project is not working properly) because you ran into technical difficulties, then you may be able to compensate in this category. The default mark in this category is 5 marks. A project judged with lower than average complexity will get less than 5; a project with higher than average complexity will get more than 5.

Please note that the above grading scheme provides 100% for the project. A mark will be assigned to each of the two courses based on half of the project grading, that is, the grade for SEG4910 will be based on the first half of project grade, while the grade for SEG4911 will be based on the second half of the project grade.

12. Proposals

In order to officially start work on your project, the SEG project professor must accept a written proposal. This should be reasonably detailed and must be accepted by the project start date. You should submit it within the first week of class in SEG4910. The proposal must include:

• Names, student numbers and co-op/non-co-op status of the group members. Also describe each member's role on the team.
• Title, and a few paragraphs describing the project, including a clear problem statement.
• Names and backgrounds of customers, and plan for interacting with the customers. If your customers are from off campus, include their addresses and telephone numbers. If you have solicited customers (e.g., in an open-market project), include a letter from them indicating they agree to evaluate the resulting software, as beta-testers.
• If you are interfacing with non-standard hardware or software, describe this.
• If you are working on a part of a larger project (e.g., with electrical engineering students doing the hardware component), describe the larger project.
• Engineering challenges and risks you expect to face, and how you anticipate addressing them.
• Impact Analysis: what are the potential liabilities and benefits of the project from a business, environmental, financial, legal, and end-user perspective. What standards and/or legislation are relevant to your project?
• Development process you plan to follow. E.g. RUP, SCRUM, spiral model, etc. Give some details.
• How you plan to evaluate your work. It is suggested that you set measurable quality objectives, and describe procedures you will follow to verify you have met these objectives. Your evaluation procedures can include formal reviews or inspections, analyses of various kinds, and usability evaluation (videotaped, heuristic and/or cognitive).
• Schedule for the work, including documents you plan to deliver, and on what dates. Gantt and Pert charts can help convey this information.

You will be permitted to make changes to the above as you develop the project, although the original proposal, and any changes, is subject to approval by the professor.

13. Delivery dates

Rather than imposing specific delivery dates, and agile or iterative approach is required, with continuous or regular delivery of updates. The only hard deadlines are the dates of the presentations, mentioned above, and the date for the system to be in its final state, also mentioned above.

14. Meetings with customers

Groups should meet with their customers on a weekly or bi-weekly basis, and more often when requirements are being gathered and prototypes are being evaluated. If the customer is at a distant location, then videoconferencing or audioconferencing communication is acceptable, and regular emails or communications via an issue tracker.

15. Scheduled meetings with the professor in charge of the capstone course

All students in the course will discuss the progress of each group in regular classes. The professor in charge of the capstone course may schedule with each group a specific time to review the design of both the system being built, and the processess/tools being used to build and test the system.

These will be held as needed and will be compulsory for all students as indicated in the tables below. The following will be the general schedule for the meetings. Students from both streams are encouraged to attend all meetings. Each meeting will fit into a 1.5 hour pre-assigned time slot.

 

The specific dates for the present or coming semester will be as follows. This is subject to change, so attend class and check your emails for details

16. Presentation in semester 1

You will have a fixed time (to be announced by the professor, but likely 15-20 minutes) minutes to present to the class: a) An overview of your project's problem and requirements; b) Your project plan; c) Your plan and approach for addressing quality assurance in your project; d) Any design you have created so far; e) traceability of your requirements to the design and architecture of the system; and f) the test plan, testing strategies and process, and test tools that will be used to verify the requirements and validate the design. Allow for up to 5 minutes of questions during your presentation.

17. Presentations in semester 2

For the first semester will have a fixed time in which you should highlight the main difficulties you encountered, and how you overcame them. The objective will be to help the other class members learn something from your experiences. You will be expected to define the progress and quality of what you have developed . Allow for up to 5 minutes of questions during your presentation. You will also give a separate demonstration at the very end o the course.

18. Presentations in general:

Consider the following to help improve your presentations:

• Use PowerPoint or a similar tool.
• Understand the intent of the presentation and get to the point. Do not take up a lot of time with uninteresting background. You may have done a lot of work, but focus on a few points about which your audience will be most interested (leave full details for a written report).
• Make sure font size is at least 32 point for slide headings and 20 point for other text.
• Make sure no point takes more than 2 lines. Don't expect readers to read a long sentence - use point form.
• Use diagrams (e.g., UML or pictures of screens) as much as possible. You can point to these and explain details of them.
• Plan on using one slide for each 1-3 minutes.
• Make sure you proofread your slides so they do not have spelling or grammar errors.
• Your slides should only highlight key points of what you will say orally. Make sure you don't 'read' your slides.
• Practice your presentation in advance in front of other members of your group, plus other friends. Make sure you get the timing right.
• Practice speaking up and projecting your voice. Try to put energy into your presentation. Convince your audience that you are enthusiastic about what you are trying to say.
• Each group member should be involved in the presentations during the course, however it is acceptable for a single group member to do one presentation, while the next presentation is done by another group member.

19. Individual Group Meetings

Groups may also meet with the professor (and/or TA if one is assigned) individually on an ad-hoc basis. Generally speaking, it is expected that groups will schedule such a meeting at least once a month in addition to regularly scheduled meetings when good progress is being made, and that they will schedule even more meetings, as needed, if problems arise. Please try to give 5 days notice of a desired meeting, but if problems occur the professor should be contacted immediately by email, if not in person. If the professor is not satisfied with any work, then he or she may request a meeting.

Last update to this page: Tuesday, 11-Jan-2022 18:39:50 EST