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, Plan B 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 Dr. Collins 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