Senior Design

Senior design consists of a two-semester sequence in which students work in teams of five students (typically) to propose, implement, test, document, and deploy an computing project. During this sequence, students will develop a project from inception to completion using sound computer science and software engineering practices. Senior design is an opportunity for students to demonstrate mastery of their discipline as well as an opportunity for additional experience and mentoring.

Students from multiple majors may work on the same team. The official course descriptions can be found at CSC4901/SWE4901 and CSC4902/SWE4902.

Teams are formed in the spring of the junior year. Each team must work with its advisor to develop two project proposals before the end of the spring quarter. A team may determine over the summer that it would prefer to work on something different. Such changes must receive advisor approval prior to the start of the fall term.

The senior design project is a culminating educational experience. It is an opportunity to showcase your expertise in a number of disciple areas. Essentially you are building a project with the expectation that it will be released to the market no later than May. The development will involve a number of Sprints, evolving the product from conception to final release.

What makes for a good project?

First, it should be interesting to you. You will be dedicating nine months of effort to this, so it should be something that captivates you and your teammates.

The project should result in something useful. What value does this end product deliver? Most likely, it should not be a reimplementation of an existing system unless it involves a truly novel implementation.

It should be challenging to your team. Of course, it should be doable, but there should be stretch goals inherent in the project that will test your skills developed over the past three years.

You should be able to pitch your idea as if you are pitching a new product for investment. Think: market, problem, opportunity, solution, and approach.

If you are a software engineering student, it should exercise most of the elements of software engineering:

  • Requirements - Definition and analysis including selecting at least one stakeholder. You will need to become familiar with the domain.
  • Software Architecture and Modeling - It should involve some interesting elements of software system design, including throughtful exploration of the architeture to support iterations.
  • Design - Strategies employed, such as the use of patterns and allowances for evolution of the product.
  • Testing - Building it to be testable and testing it. How good is the automation of the testing and was it considered from the beginning?
  • Tools - Good use of development, testing, and management tools (including GitLab).
  • Experimentation and Prototyping - Applied to unknown technology to improve knowledge and reduce risks. As the architecture is developed and key mechanisms are determined, what risks arise and how will you address them in the development process?
  • Third Party Components - Demonstrate your skill in discovering and employing third party components.
  • Documentation - This takes many forms including continuous documentation such as, notes associated with tasks that our updated regularly, weekly reviews, sprint reviews, and other artifacts such as a technology report, discussions of where you achieved specific course outcomes, project presentations, poster, and final report.

If you are a computer engineering student, you will exercise a different set of elements that are core to computer engineering.

General Routine

In general, senior design does not meet as a class. Exceptions are for information sessions and team presentations. Otherwise, teams work independently and meet weekly with their advisor. Meeting times should be established by the start of each quarter. Each student is expected to spend at least 10 hours per week working on senior design (including meetings).

Development Cycle

Teams will use the Scrum framework to develop their project. The first few weeks of the fall term will be used to more clearly define the scope of the project by developing a product backlog, developing experiments and prototypes to reduce risks and justify technology choices. Beginning in week 3 of the fall term teams will begin four 3-week sprints. A sprint consists of:

  1. team committing to delivering a working product
  2. team building the working product
  3. team demonstrating the working product (at the scheduled advisor meeting)
  4. stakeholder(s) providing feedback to the team during the demonstration

Sprint Planning

A Scrum planning meeting will take place with the team, stakeholder(s), and the advisor at the beginning of each sprint. It is critical that the team have a well groomed backlog. Tasks for the highest priority product backlog items should be fleshed out prior to the meeting and included in comments in the GitLab issue.

Sprint Execution

The execution of the sprint will consist of the completion of tasks to achieve the increment (working product) for the sprint. Team members must document relevant information about each PBI by editing the issue to add pertinent information and log time. Advisor meetings for the two weeks in the middle of a sprint will focus on discussing team progress, identify successes and problems, and, if necessary, make adjustments to the plan. Prior to each weekly meeting with their advisor, the team must prepare a status report.

Sprint Retrospective

At the end of each sprint, the team must evaluate its progress regarding the sprint. A sprint retrospective document is generated at the end of each sprint to report on the effectiveness of the team and to document any changes to the way the team works.

Development Process

Teams will use GitLab for project management, source control, and communication. Backlog items are markdown files in the .issues directory. PBIs begin in the .issues/backlog directory, move to the .issues/open directory when committed to in a sprint, and placed in the .issues/closed directory when completed or abandoned. A list of tasks that must be accomplished to complete the product backlog item must be documented within the issue. Once a sprint begins, all PBIs to be completed during the sprint are associated with the sprint and the tasks are assigned time estimates. Each task is assigned to one team member who is responsible for its completion. Each team member logs time against their assigned tasks in their .log/lastname.md log file and updates the task with comments describing the work completed whenever time is logged. You should log the time to the task immediately after working on the task in order to communicate your progress to your team and advisor.

Developing proficiency with process tools is an important part of managing a project. Therefore, a portion of each member's senior design grade is based on the individual's ability to effectively use the tools. The issues, issues notes, repository commit logs, build history, and pull requests and subsequent feedback all provide useful information for determining each individual's level of contribution to the senior design project. All are encouraged to spend time early in the fall term becoming proficient with the tools.

FAQ

Got a question? Check the FAQ first. If it's not addressed, or the answer is unclear, please ask.