Senior Software Engineering Project: CS 4791/4792
Syllabus Schedule Assignments Links
Michigan Tech
Computer Science


Charles Wallace
(906) 487-3431


Class meeting: Rekhi 101, Tuesday 10-11
Team meetings: By arrangement
Office hours: Rekhi 205, time TBA


CS 4711 (Software Processes & Management)
CS 4712 (Software Quality Assurance)

Course description

In this course, you will work with other students to develop a real software product for real clients. In doing so, you will draw on the software engineering knowledge and skills you have developed in earlier courses:


We will use Scrum as the framework for software development. Scrum is an iterative approach, in which projects progress in short intervals called sprints. The result of each sprint is a deliverable "product" (not necessarily complete, but functional in some way that is meaningful to the client). Team members work in a highly collaborative fashion and have a high degree of control over what is accomplished in each sprint. Scrum is particularly effective at handling changing or uncertain requirements. In a teaching environment, it gives us plenty of opportunities (at the end of each sprint) to reflect on the project, and on what we have learned about software development. It is easy to learn, and it is fun, but it also requires a high degree of participation and responsibility.


In addition to the team members who create the tangible products of the sprint (through design, implementation, testing, documentation, etc.) there are two distinguished roles:

The roles of Scrum master and Product owner require a different perspective, broader than the intense focus of the sprint requirements. Typically, second semester students (enrolled in CS4792) take these roles.


Creating the backlog. In each sprint, the team chooses a set of requirements and then sets to work fulfilling them. The requirements are chosen from a preexisting product backlog, maintained by the Product owner. To kickstart the whole process, the product backlog must be populated with requirements, expressed as stories. To do this, the Product owner first consults with the client, to get a vision of the ultimate purpose of the product and a set of prioritized features and time constraints. The Product owner takes this information to the team, who then break it down into a backlog of feasible items, along with any necessary technical requirements that are outside the purview of the client. For backlog items to be feasible, they must be readily estimable and testable: each item must have an estimated amount of effort necessary to complete it, and a clear means to test whether the item has been completed successfully. Once the process is underway, the Product owner keeps the backlog up to date through communication with the client.

Sprint planning meeting. At the beginning of each sprint, team members select items from the product backlog that are to be completed in the current sprint. They then form a sprint backlog of short tasks, most requiring less than a day of work, that together accomplish the requirements of the sprint. Finally, individual team members sign up for tasks in the sprint backlog. The length of the sprint is determined by the team, but each sprint should last 2-3 weeks.

Daily scrum. Four days a week, a 15-minute meeting of all team members takes place. The meeting takes place at the same time and location every day. To encourage brevity, the meeting is "stand-up": all participants stand for the entire meeting. Each team member reports on his/her status by answering the "questions three":

  1. What have you done since yesterday?
  2. What are you planning to do today?
  3. Do you have any problems preventing you from accomplishing your goal?

After all individuals have reported, the Scrum master has the option of

Sprint review meeting. At the end of each sprint, the team presents its results to the client: a review of what was and was not completed, and a demo of the completed work.


Your project experiences provide a great opportunity to reflect on the software process: our method for conducting software projects. We will spend some time doing this both individually and colletively.

Sprint retrospective. After the review meeting, we have an opportunity to reflect on the results of the sprint: what went well, and what could be improved? If you find it awkward to answer some of these questions at the retrospective meeting, due to issues with team members, I strongly encourage you to meet with me individually and discuss them.

Communication exercises. There are four course assignments focused on communication (reading/writing, listening/speaking, and teaming). In these exercises you will reflect on the communication challenges in your project and on how you have met them. The exercises themselves will give you experience in a variety of communicative genres and styles.

Course expectations

Each team member is expected to put at least 10 hours of work into the project each week. A collaborative approach to work, where team members work face-to-face on shared tasks on a regular basis, is in keeping with the Scrum approach and is encouraged.

We will use Bugzilla to maintain product and sprint backlogs. You can find information on setting up and using Bugzilla here.

We will use Subversion for version control. Shared storage is available in the csl domain.

Team members should also write the following material and store it in the team's repository:

Each team member is expected to demonstrate the qualities of leadership, technical competence, and communication, through the following activities and roles:


Since projects and project roles vary so significantly in this class, a fixed, quantitative grading rubric doesn't work. Instead, I use the following qualitative rubric:

Performance characteristics Grade
Shows strong effort in all three categories: leadership, technical competence and communication. As a team member, consistently takes on and completes significant tasks. Reflection activities show consistently thoughtful and well crafted work. A
Shows effort in all three categories. As a team member, usually takes on and completes significant tasks. Reflection activities are usually thoughtful and well crafted. B
Fails to show meaningful effort in one of the three categories. As a team member, completes some tasks but has some problems with consistency. Demonstrates some effort in reflection activities, but exhibits some problems with content or presentation. C
Fails to show meaningful effort in two of the three categories. As a team member, completes some tasks but has serious, recurring problems with consistency. Demonstrates little effort in reflection activities. D

I will give a narrative evaluation of your performance after each sprint. The evaluations will balance individual and team performance roughly equally. Your comfort level and effectiveness within the Scrum framework will (hopefully) increase over time, and I will take that into consideration when evaluating the early sprints.

Attendance at meetings is crucial. An unexcused absence from a major meeting, like a scrum review, will drop your final grade by a full letter (A to B, AB to BC, etc.).

Affirmative Action/ADA

Michigan Technological University complies with all federal and state laws and regulations regarding discrimination, including the Americans with Disabilities Act of 1990. If you have a disability and need a reasonable accommodation for equal access to education or services at Michigan Tech, please call the Dean of Students Office, at 487-2212. For other concerns about discrimination, you may contact your advisor, Chair/Dean of your academic unit or the Affirmative Programs Office, at 487-3310.