CS@NAU: Senior Capstone Design

What makes a "good" CS Capstone Project

As you start thinking about potential projects that you might submit for implementation, our lengthy experience allows us to offer a few hints on project characteristics. Successful projects resulting in satisfied clients will have the following characteristics:

• Must have substantial design and coding content. There has to be a strong focus on developing reasonably complex software elements. For instance, a powerful new web app or mobile app might be a reasonable challenge, whereas implementing "a nice company website" is probably not. The Capstone Coordinator faculty member will help you refine this focus in initial discussions.
• Must focus on producing a well-defined software product, e.g., an application, web-app, and mobile app. Sometimes sponsors would like "research assistance", e.g., would like a team to "explore a new algorithm idea" or "help on miscellaneous projects in our lab". Such "projects" are completely inappropriate for CS Capstone. The entire program is based on formally specifying, designing, implementing, and delivering a single, clear software product.
• Must have appropriate complexity and scope for the skills/timeline. A good project will be complex/large enough to keep a 3-4 person team of seniors busy for a year (keeping in mind that they have other classes as well)...but also not TOO complex/large that they couldn't realistically get something useful done in the alloted timeframe. Again, conversations with the Capstone Coordinator faculty member can help here.
• Are based on a solid premise...but not fully fleshed-out. Even if you think you do have a fairly clear idea of what the solution might look like, the project should ask the team to explore from the ground up: feasibility, competing design options, and alternatives. This may present the client with novel options never before considered, and truly allows the team to bring the breadth of its design skills to bear.
• Exhibit a flexible timeline, without being overly reliant on critical deadlines. This allows for inevitable delays and accommodates the fact that software effort estimation is notoriously difficult and fraught with inaccuracy.
• Have strong value-added but are not mission critical. This just states the obvious: this is a student project, they are still learning, so it is unwise to choose a "critical path" project within your company's development plan. Much better are peripheral projects or explorations of new ideas where timeline is more flexible. The idea is to give the client real value while not relying overly on the project team for critical enterprise deadlines.
• Will have a well thought out set of core features that are desired. You don't have to have *complete* detail here...after all, the first semester is devoted to exploring technical options and refining the specs. But the less vague your product vision is, the more attractive it will be to students. I strongly recommend (a) bulleting out key requirements in your description, after you've intro'd the project concept overall, and (b), even more powerfully, separating your requirements into three groups: basic features you'd need for a "minimal viable product", then additional features you'd want in a "comfortably equipped" product that you'd enjoy using, and finally, features that are "icing on the cake" (we call them "stretch goals"). This provides students with a clear idea of the challenge...not to mention making you think carefully about what you need.

Finally, success or failure is also defined by client expectations. You are "hiring" skilled young professionals, but they are still inexperienced and making the transition to real CS practice. Accordingly, an expectation level of “cautiously optimistic” is appropriate!

You can review a list of past projects here, if you'd like to get an idea of the range of size/scope that we're talking about.

BACK to Sponsor Home