Capstone Project

Background
Finding an advisor
Writing Your Proposal

Background

Students are strongly encouraged to complete an independent Capstone project as one of their elective choices during the final semester. Here you will find details on choosing a project, choosing an advisor, writing your proposal, and completing the process.

The goal of the Capstone project is to demonstrate fluency with the tools of scholarship and professional practice in your field, an ability to independently plan and carry out a non-trivial piece of work, and an ability to present your work in written and oral formats.

The Capstone project can count for 2-6 credits in the program, and is expected to require at least 50 hours of effort per person pre credit. The policy in MSSE is that if a student selects a topic that requires a substantial technology-related learning curve, (such as learning a new language or operating system, etc.), then that portion of the effort is over and above the effort expected for the Capstone project itself.

Your Capstone project can take many forms, depending on your interests. It must be educational, have a research component, and relate to the Software Engineering program. It should also have a clear focus and well-defined success criteria. Here are some examples of past MSSE Capstone projects:

Technology analysis: Analyze and compare competing approaches or products relative to some application or class of problems. One team of two compared Microsoft .NET and Sun J2EE with respect to a class of web-enabled enterprise applications.
Software design and implementation: Analyze a problem, research known solutions and products that address the problem, develop a design and a plan, choose some interesting or challenging portion of the problem to implement and test. A recent graduate implemented an agent communication layer for a multiplayer FPS game. Another developed a distributed build manager that allows a build to depend on remote external libraries.
Process assessment and improvement: Evaluate and document the current state of practice in an organization, identify problem areas and potential improvements, develop and document an improvement plan. One recent project analyzed a series of project failures and identified organizational factors related to misalignment between knowledge, motivation, and authority among technical teams and the user organization.

The MSSE Program Office maintains a file of past Capstone projects to inspire you and to help you get a better feel for what's expected, and many students have agreed to have their final reports published on the program website.

Process and timeline

Finding an advisor

There are two approaches to finding an advisor: (1) based on research interests and knowledge relevant to your project area, and (2) based on desire to work with a particular faculty member. If you want to work in an area and don't know where to look to find someone who can help you, you can visit the research pages of the University's academic departments, or you can ask one of your professors or your DGS for help. Your advisor can be any member of the MSSE faculty.

Writing your proposal

Your written proposal must include the following elements. It may be submitted by email as long as you avoid proprietary document formats.

Project title.
Problem description - what is the problem, why is it interesting?
Brief outline of known related work.
How you propose to solve or address the problem.
A brief project plan, including at least one intermediate milestone with a date and deliverable.
For group projects only, a brief description of how project responsibilities will be divided among team members.
Evaluation or completion criteria - what do you want to be able to tell your advisor when you are finished.

Ideally, the proposal will be just one page, two at the most. Save the verbiage for the report.

Process and Timeline

The basic outline of the Capstone process is something like this:

Identify an advisor and a project, and negotiate the scope and goals of your project with your advisor.
Write a project proposal that describes your project and identifies your advisor, and submit it to the DGS and the UMSEC office.
Keep your advisor informed of the status of your project as agreed in your project plan.
Prepare a final report and submit it to your advisor.
If you agree to publish your final report on the program website, sign the release form available from the program office and send a pdf copy to the program associate.

Capstone projects may be group or individual efforts. In MSSE we encourage group efforts, with the proviso that the contributions of each individual student must be evident and of reasonable scope. It is normal, but not required, for each student in a group project to have the same advisor.

There are 4 parties who play important roles in the Capstone project process:

The student presumably wishes to complete the MSSE degree.
The advisor supervises the student's work.
The MSSE program office in UMSEC keeps records, facilitates interactions with the Graduate School, and keeps a library of past successful projects to help students gain perspective on the process.
The Director of Graduate Studies (DGS) is responsible for the academic quality and consistency of the program.

Here is a recommended timeline for the process that shows what each party is expected to do, and when. All of these activities are during the second year, but there is no reason a student needs to wait until the second year to get started.

Date	Student	Advisor	UMSEC Staff	DGS
Late Spring, first year				Discuss Capstone procedures and timeline with students.
Summer or Fall semester	Settle on a topic, possibly organize a team. Find an advisor.	Help student to scope a project that is relevant to the program and of reasonable scope.	Library copies of past Capstone projects are available for checkout. Contact UMSEC staff.
Fall semester			Staff available to answer procedure and other process-related questions.	Follow-up information session and progress check.
late January	Get your degree program form and commencement attendance form from the UMSEC office. You must have your advisor sign these forms before the end of February and return them to the office.
Early February	After reviewing with your advisor, submit your project proposal to DGS and UMSEC office.	Ensure that the proposal contains the essential elements.		Register proposal.
as agreed between student and advisor	Report progress to advisor, meet and discuss as necessary.	Offer assistance as requested, expect conformance to plans in lieu of agreed re-planning, but don't drive the process.
6 weeks prior to completion	Fill out the Application for Degree form and turn it in to the MSSE office.		Forward Application for Degree to the Graduate School.
2-4 weeks prior to completion	Prepare your final report (and presentation, if that is part of the process you have negotiated with your advisor). If you are giving a presentation, you may want to do a dry run with your advisor or spouse or someone who will give you an honest critique.	Give critical feedback on the final report, send it back for revisions if needed.
After report is accepted	Make final changes to your report if required by your advisor. Breathe a sigh of relief. Celebrate.	Enter final grade for independent study credits.

Project Ideas

Most students choose a project from one of four categories:

Workplace problems: There may be some problem in your work environment that needs attention, is related to Software Engineering, and is of particular interest to you. Many students choose such projects. One excellent example was the student who developed a process for remote collaboration in a far-flung development team. The project involved interviewing participants, evaluating and choosing tools, installing the tools and developing a process around them, and finally using the new process on an ongoing project and evaluating its effectiveness.
University research: There are a great many fascinating research going on at the University. In Computer Science, we are working in programming languages, formal specification methods, robotics, electronic commerce, distributed systems, graphics and visualization, human-computer interfaces, and a wide variety of other areas. Many of these areas have active groups of graduate students, and will welcome engineering and implementation help. Many other research areas also need the expertise we can offer. Past MSSE students have worked in data modeling for genetics research, distributed architectures for electronic commerce, machine emulation by on-the-fly program translation, and several other areas.
Personal interest: Perhaps you have a project you've been dying to work on, but couldn't think of an excuse to devote the time. We've had students work on remote weather stations, a generic "gauge" interface for race car data monitoring, agent communication for multiplayer games, and data modeling for a home business.
Open-source projects: One of the more active areas of open-source development is in software development and engineering tools. One student developed a distributed build system for open-source projects, and others are working to assemble a requirements-management tool from open-source components. At tigris.org is a collection of open-source software engineering tools. How good are they? Is Subversion a good replacement for cvs, for ClearCase, for Perforce?

Regardless of what you choose, there are few general criteria to keep in mind:

If you are not personally interested in your project, you will find it very hard to finish.
Your project must bear some relationship to the MSSE program. Implementations and software demonstrations are not necessary, and if done are more often proof-of-concept prototypes and not finished products. Of course, if your real topic is something about an engineering process that helps produce finished products, then finishing something might be a good demonstration. It is generally best to focus most of your attention in one area, like design, architecture, process, metrics, data modeling, technology evaluation, etc.
The project must have some research content. That doesn't mean that it must meet the novelty standard of a Ph.D. thesis. It means that you must place and present your work in context, and to do that you must know what else has been or is being done that is similar or complementary. Generally it isn't enough to just write a program. If you really want to write a program, then it should be done as a demonstration of some process or a tool for supporting a process, or as a proof-of-concept of an architectural idea, or a demonstration of the usability of some new technology, or as a way of testing some human-computer interaction idea.
You must produce a written report, and you must make an oral presentation at your examination. A working program or a set of slides for your talk is not sufficient. Generally, Capstone project reports are between 15 and 30 pages, exclusive of data, program listings, and other appendices. More bulk is not necessarily better, some excellent papers have been under 10 pages.

Specific ideas

(please email jcollins [at] cs [dot] umn [dot] edu to suggest additions to this list)

Evaluate subversion or other open-source tools for specific engineering process needs.
Evaluate the value of the OMG's Model-Driven Architecture in a real project that is large enough to give it a realistic test