Structure of a Research Project Proposal
- What is your hypothesis, question or goal?
- What will you learn?
- If performance-related, what will you measure and how?
- Why is your project important?
- What is your hypothesis, question or goal?
- "I hypothesize that SELinux is measurably slower than vanilla
Linux."
- "Why does Microsoft Word load faster on Vista than XP?"
- "I will build an OS call to measure the distance from the CPU to
the moon." (With a goal of building something, you must describe
why it is valuable, as well.)
- What will be the output of a successful project? (How will you know
when you're done?)
- What are the midterm milestones? (How will you know if you are on
schedule to finish or not?)
- What equipment and skills do you need in order to succeed? Do you
have them, or a good plan to acquire them?
Those are generic questions for *any* project. There are a couple
more for an educational project:
- What will you learn if the project is successful?
- What will you learn if the project fails?
For a performance measurement project, you need to be able to answer
the following questions. It is not always necessary to explicitly put
the answers in the proposal, but in this case it will be useful.
Also, the answers to these questions often take a little time to
develop fully, so they may not be ready when proposals are due, but
you need to answer them early during the project.
- Are you measuring throughput, latency, or both?
- In particular for measuring latency, do you know roughly what the
size of the phenomenon is that you're looking for? If it's a
difference of a few instructions, that's hard to measure; how will
you do it?
- What variables will be varied, and what variables will be fixed?
- What stastical techniques will be necessary to confirm your
hypothesis?
All of the above are sufficient for a class project. To move from
class project to research, you need to be able to answer the
following, as well:
- Why is your project important?
- Who will it affect?
- How big is the effect? (more of a result than part of the proposal,
but you should have some expectation that what you are doing is
likely to have an effect big enough to care about.)
- As technology changes (in particular, at the moment, as multicore
chips become standard), are your results likely to still be
applicable?
- Who else has worked on the same or similar projects?
- Why is your approach "better"? ("Different" is not usually reason
enough by itself.)
- Are there problems with their approach? Is their data now old?
I expect to see five things in any research proposal,
whether or not it's operating systems, though the length and rigor
of each of these will vary with the type of proposal:
- Problem Definition
(This is the "elevator pitch" for "why I should care". Convince me that it's a serious issue you're addressing.)
- Related Work
- The Idea
- Plans for Evaluating Your Work
(What will you measure? How? How will you prove to me that you have understood, and solved, the problem?)
- A Schedule
(This needs far more detail than just the
schedule I outlined in class! As the proposal develops, I
expect a development plan, including schedule with technical
milestones, and required resources (people, machines, network
bandwidth, storage space...))
Also, for specific projects, I expect:
- Who will do which chunks of the work
- What environment you will work in, what tools you will use
- How you will manage shared source code, data, etc.
A proposal will generally be 1-2 pages.