Skip to Main Content

CS481 Sponsors

This article is for sponsors wishing to propose a Senior Design project; the page for students enrolled in CS481 is located here.

Who can Sponsor a Project?

Successful projects have been submitted by business (e.g. a sole proprietorship, a limited liability partnership, a corporation, a non-profit organization) ventures having real-world applications, end-users and schedules, and by government agencies, and by the BSU Venture College.  Sponsors must supply the name of a contact(s) who will have time allocated (about 1..2 hours/week average) to collaborate with the student team.  Sponsors must be comfortable with the risks of working with an inexperienced student team that likely won’t deliver all the required features on the required schedule.  We are especially interested in open-source and public-service projects in addition to proprietary ventures.

Sponsors understand the instructor will focus the student teams on software quality and process deliverables.  CS481 is not a hackathon cranking out untested features.  The student team is learning how to control their project to deliver an appropriate quality, predictable, sustainable result — it is unlikely you will get all the features you desire.

Sponsors need not be software engineers.  Students will use the popular “scrum” process for capturing your business and customers’ needs, estimating how much work will be required, and for prioritizing the deliverables when the work exceeds the available effort.  The Scrum process was originally published in The Harvard Business Review and is readily accessible to management.  In fact, Scrum:  A Breathtakingly Brief and Agile Introduction can be read in a couple hours and will help you interact with your team.

How do I Propose a Project?

Please use our Microsoft Word Template.  The template guides you through many aspects (e.g. intellectual property, schedule, deliverables, contact information, etc) of your proposal that are important to your agenda.  EMail your completed proposal to and include a subject similar to, “Senior Design Project Proposal.”

I need to receive the final draft of your proposal before the first day of classes of the semester when your project would begin; I recommend sending proposals at least a month sooner so that difficulties/questions can be resolved.

Project Guidelines

While we evaluate each project proposal on its own merits, the best projects have developed a prototype or a preliminary version of a real-world product that explored a new application or technology concept as opposed to short-term, business-critical deliverables.  Good projects develop products that fulfill real-world needs (not busy-work), and require students to engage in requirements gathering, software design, implementation, documentation, and quality assurance activities.

If you are a start-up venture, you might think of your project as developing a product or service that you’ll demonstrate to your potential investors.  You should hope to achieve investor and customer feedback with this first step in your journey.  Few capstone projects achieve the scale and functionality required to achieve revenue.

If you are an established enterprise, you might think of your project as a means of investigating a business opportunity beyond the capacity of your internal resources.  It’s a chance for even a main-street business to explore an innovative or potentially disruptive venture.

If you are a non-profit, community, or government agency, you might think of your project as your last resort, a chance to achieve what funding has denied you.  Because many students may not be able to sign non-disclosure agreements (NDAs) nor assign rights to a private enterprise, we are especially interested in “open source” proposals that benefit the public.

We have not had a good experience with faculty research projects.  Their open-ended requirements, lack of business objective, and hackathon-like expectations have not aligned with CS481’s outcomes.

Multi-Discipline Projects

A multi-discipline project has software as one of several components.  An automated garden composter, for example, may have software, electrical and mechanical components.  These have proven challenging for students in the past.  A successful multi-discipline proposal will need to address the following:

  • Some one will need to submit a software project proposal.  All CS Senior Design projects require a proposal approved by the faculty.
  • The software component scope must be significant enough to provide a software development team experience as required by our ABET outcomes.
  • CS481 is a required course and the software team will include A, B and C students.  The multi-discipline team cannot “cherry pick” the software team members.
  • Schedule compatibility:  Senior Design projects begin in CS471 and are completed in CS481.  The proposal needs a plan to engage with the software team about four weeks into the CS471 semester even if the mechanical/electrical/whatever components are not yet ready.  For example, the proposal may suggest development on off-the-shelf hardware using LEDs, switches and position encoders attached to digital i/o ports until the custom hardware is available.  It is wholly infeasible for the CS students to wait until the hardware is ready.
  • Our Senior Design program does not have a budget for lab equipment (e.g. emulators, hardware, specialized tools, sensors, etc).  The proposal must identify these needs and how they will be fulfilled.

Project Staffing Steps

  1. The sponsor proposes a project using the template referenced above
  2. The CS faculty reviews the proposal, identifies the required skills, and either approves or rejects the proposal
  3. Student teams rank all faculty-approved projects, indicating their preferences
  4. The faculty assigns projects to teams by matching team skills (evidenced by their 400-level electives) with the team preferences (step 3) and the projects’ required skills
  5. The faculty notifies teams and sponsors of the matching results

Not all proposals will be staffed with a student team.  Some proposals may be rejected (because, for example, of a potential IP conflict).  Sometimes we have more proposals than available teams.  And sometimes no student team will have the necessary skills to succeed.

Project Teams

Sponsors do not get to choose their team members.  Most teams consist of 3..7 students.  Larger proposals can sometimes be implemented by multiple teams.  If each student contributes 9 hours/week on the project,  a single team’s total effort will be roughly that of 1 Full-Time Equivalent (FTE) engineer.  Teams may consist of A, B, C and occasionally D or F students.

Teams form near the beginning of a CS471 semester.  Students spend this first semester learning software engineering skills and capturing your requirements, and, in most cases, developing an initial executable prototype of the final product.  Most software development occurs during the second semester in CS481, Senior Design Project.

Sponsor’s Suggested Donation

Corporate project sponsors are asked to make a $1000 tax-deductible donation through the Boise State University Foundation, memo “Computer Science Department Fund (NR070) for Senior Design,” to help defray our costs.  Government agencies, non-profits, the  Venture College incubator, startups having fewer than 10 employees, and the department’s existing donors are exempt.

How do Senior Design Projects Differ from Internships?

Every CS481 Senior Design project is a team project; an internship is an individual student effort.  A Senior Design team’s process deliverables are graded.  Academic internships are graded pass/fail.

Unless you hire them, Senior Design students are not your employees nor contractors.  Their deliverables are defined and assessed by the faculty, and their software is not a work-for-hire.  Interns are  usually employees whose day-to-day schedule and deliverables are established and assessed by their industry supervisor (not by the faculty).

You typically interview interns, but senior design students are assigned to teams by the faculty.

Intellectual Property Considerations

Software you Produce:  In the United States, the original creator of Intellectual Property (IP, e.g. software) owns the copyright.  If the student team members are not employees nor independent contractors of the sponsor, then the student team, not the sponsor nor BSU, owns the software they create, and the students are entitled to enforce their rights unless prior arrangements (e.g. contracts) are made.  Sponsors must identify their IP requirements in the project proposal so a student team will know what to expect when choosing their project.  While students are responsible for choosing acceptable projects, BSU can not force students to assign their intellectual property to sponsors.  Sponsors are responsible for all necessary legal documents, and obtaining any required signatures from the student team before work commences.  

Software you Leverage:  If your project leverages existing software (many if not most do), sponsors are responsible for ensuring the existing software’s license agreements are compatible with their business model.  Many important open-source packages are released under the terms of the GNU Public License (GPL) whose “copyleft” license text may be incompatible with some business models.  Important non-copyleft (permissive) licenses include the MIT License, the BSD License and the Apache License.  Senior Design students are not attorneys.

Sponsor’s Responsibilities

Regular engagement (about once every two/three weeks) with the student team is the most critical responsibility of the sponsor.  Your team will ask you to participate in Sprint Planning and Sprint Review Meetings in which you will be asked to describe what your business needs, prioritize those needs, and provide feedback on what the team constructed to meet those needs.  Students may also need to contact you outside of these meetings to clarify details or respond to questions that arise.

Sponsors designate a contact who is responsible for:

  • Responds to the student team’s questions (about one hour/week)
  • Represents the sponsor’s business agenda in the team’s meetings including the Sprint Planning Meeting and Sprint Review Meeting
  • Represents the end users’ needs (students will call these User Stories)
  • Helps the student team prioritize the Scrum Product Backlog, a prioritized list of all User Stories
  • Helps the student team define Acceptance Criteria for each backlog item.  The student team uses these to determine if the product is working as expected.

While the sponsor may provide guidance and a few key User Stories, the student team is usually responsible for writing the majority of the stories in the backlog.  We do this intentionally to provide students with the opportunity to define a product’s requirements.

Sponsors may need to provide specialized software development tools (e.g. an Apple Developer license), services (e.g. Amazon Web Services), libraries, or hardware (e.g. iPad, server) required to implement their product.

What Sponsors can Expect

  • The students will build the product in incremental releases of functionality called sprints
  • Nearly all Senior Design teams develop a product containing many though rarely all of the desired features
  • Most student teams will initially underestimate the effort required to complete User Stories in the Product Backlog
  • Most student teams are learning how to use the scrum process to find a compromise between the competing requirements for features, quality and effort
  • Most students will need to learn some new technology, tool or process to complete the project — this will slow them down
  • The faculty will impose time-consuming deliverables on the students that emphasize artifacts of the development process, quality, documentation and supportability — this how we grade the students’ projects
  • Most teams deliver a viable prototype of their sponsor’s vision, the best teams have delivered release-quality products