| title | layout |
|---|---|
About |
default |
UCSOP is run by a steering committee of faculty members from several Canadian Universities under the umbrella of the Canadian Association of Computer Science.
Software development is no longer bound by time zones or national borders. Projects of all kinds—academic, commercial, and open source—may have their GUI designers in Boston, their database team in Bangalore, and their testers in Budapest and Buenos Aires. Working effectively in such teams is challenging: it requires strong communication skills, and makes proper use of coordination tools such as version control, ticketing systems, code review and continuous integration more important than ever. But it is also an opportunity for students to build ties with peers across the country and around the world.
- Students: Work on an open-source project with other students from across the country—for credit! What could be better? Find out how to apply.
- Faculty mentors: We are always happy to welcome new schools or new faculty supervisors.
- Open source project mentors: Are you involved in an open source project? Help a team of students make a contribution.
- Sponsors: We need your help to bring students together for a code sprint. And—hint, hint—UCOSP participants will be looking for employment.
- Mid-August: finalize which open source projects will be participating
- Mid-August: start matching student with projects
- Early September: teams have their first online meeting and start work
- Third weekend in September: co-located code sprint (locations vary year to year) for all participating students
- Early December: work on projects wraps up
- Late October: finalize which open source projects will be participating
- Early December: start matching student with projects
- Early January: teams have their first online meeting and start work
- Third weekend in January: co-located code sprint (locations vary year to year) for all participating students
- Early April: work on projects wraps up
For students to gain hands-on experience with real-world development practices in a realistic environment while simultaneously learning and applying some core concepts of computer science.
See the projects page.
This varies from team to team. In general, though, there’s enough work for everyone to spend most of their time working on something they find interesting.
The programming skills required vary widely from project to project: students are more likely to succeed in a Java-based project if they already speak Java, and more likely to do well on a cellphone project if they have some previous experience with handheld devices or wireless networks. Students should also be familiar with, or willing to learn, version control, bug tracking, and other coordination tools. Keep in mind, though, that being able to set their own goals, manage their own time, and communicate with others is at least as important as knowing any particular programming language or operating system.
Cooperation, communication, and commitment. For many students, this is the first time they have had to set their own goals and deadlines, and some struggle with that freedom during the first few weeks.
Experience working in a distributed team on a meaningful project; peer contacts (social/professional networking); something cool to demo in interviews for jobs and graduate school.
Yes.
The same as any other course, i.e., about 8-10 hours/week.
Unfortunately, we are only able to accept full-time students who are not currently on a co-op term into the UCOSP program.
The organizers take care of week-by-week project management, though other faculty are very welcome to get involved as well.
Grades are awarded jointly by the local faculty organizer in consultation with the project lead. Grading schemes are tailored to individual teams and projects, and take into account the requirements of the courses in which students are officially registered. (For example, a student who is registered in a senior course on Software Architecture may spend more time on design and documentation than on coding.) In many projects, students themselves propose grading schemes once they are familiar with the project. There is usually not a midterm or final exam, but some schools require students to do an end-of-term presentation and/or create a screencast to show what they have accomplished.
Standard software development processes are not well-suited to students’ realities: unlike professionals in industry, students usually have to work on several projects at once, and are almost always new to the technologies they’re using and the problem domain they’re working in. Based on past experience, the best fit is a mix of open source practices and Scrum:
- Every project keeps its work in a version control repository, uses tickets to track work items, etc. Teams are strongly encouraged to do code reviews.
- Each team has an hour-long online meeting each week to review progress, set goals, answer questions, and resolve outstanding issues.
- Work is usually done in two-week iterations. At the end of each iteration, each team member sets their goals for the next one, so that students have a chance to develop planning and estimation skills.
- Each team is required to produce a five-minute screencast demo of their work at the end of the term.
All the things that real software projects need, including design, construction, testing, packaging, and documentation.
Yes—there is a weekend-long code sprint near the start of each term at which teams meet in person to discuss the strategies for the term, attend team-building social events, and write lots of code. The sprint location varies from term to term (it has been held at UofT, Mozilla, Communitech in Waterloo, UBC, and at Facebook in Melno Park in the past).
Via the usual online tools, such as blogs, chat, mailing lists, and Skype. Team members may agree on something else new and trendy, such as Twitter or Google Wave.
(Almost) all of these projects are producting software for real-world use, so standards are high. Remember, “95% correct” may be an ‘A’ academically, but if 5% of an application is buggy, users aren’t going to be happy.
Yes, where possible. Unlike most university courses, we strongly encourage students to communicate with each other and their predecessors.
Students post finished work (including tests) to their team’s code review site. Another team member then reads it through and gives the author on what needs to be fixed before it can be committed. Once the author has made all the fixes suggested, and the reviewer gives the ok, the code is put into the version control repository for others to use.
Since September 2008, undergraduates from several schools in North America have been taking part in joint capstone projects in order to learn first-hand what distributed development is like. Previously run as a pilot project, UCOSP has emerged into a truly national program.
Information about previous years is available here.
For more information about the program, please get in touch!