Getting Started at NASA GSFC
Prof. David C. Brown, CS Dept.
- Please (re)read:
- find your way around: collect room numbers and telephone info.
of key people + key places (e.g., library).
- make sure that you have the resources you need: Phones, computers,
access to a printer, access to appropriate software, access to
documentation, experts. Use Prof Looft's persuasive powers to make
these things appear. Make sure you know who to ask about needed
resources -- probably your main Mentor initially.
- make a list of what you need to know in order to do the project,
and keep it updated.
- establish lines of communication: discover who prefers a phone
call, who prefers a visit, who prefers email, and when people are in
- put contact info on the web page. (location, phones. FAX)
- keep your web page up to date! I can use it as a way of keeping
track of how you're doing when I'm not there.
- Your Advisor needs a weekly report via email, just like for the PQP.
Via email. Also put those reports on the web page.
- set up a weekly meeting with your Mentor(s)
- set up a weekly phone mtg with me. Try to get, or be able to get
to, a speaker phone so we can all meet together. I may also want to
talk to everyone individually.
- remember that I, DCB, prefer not to get Word or other M'Soft stuff.
Use plain text, PDF or postscript, or a web page.
If needed I can deal with it, but it may cause delays or garbled
documents. PLEASE use plain text for all email.
- make notes of what was thought of, discussed, decided.
Both in a group and individually.
- use the first week to try to get some project Requirements in
place. What must be accomplished, should be accomplished, and
might be accomplished if there's time. Also make sure you know
what NOT to do. Requirements should be a formal document approved
by the NASA Mentor(s).
- Note that NASA's engineering goals for your project and WPI's
academic goals aren't necessarily the same. We need to find a way
to make them happy while producing a project that is up to WPI's
- if you cant get answers immediately, at least collect and refine
- don't be afraid to contact someone at NASA (or elsewhere) for
any info you need that they might have. Tell them who and where
you are, and they'll probably help you. If in doubt ask me,
another WPI Advisor or Prof. Looft.
- draw up a general schedule for requirements gathering, design,
- Make project report writing a task that is done weekly,
not just at the end.
- Make a table of contents for your MQP as one of your FIRST tasks --
you can refine it gradually.
- find ways to divide the work between yourselves to maximize effort.
Make parallelism your friend.
- make sure that you have regular mtgs in your group, and with the
other related groups. I suggest a daily own group mtg at the start of the
day. Perhaps every other day with the other group?
- even if you talk to each other ALL the time (you should!) have a
formal meeting with an agenda of topics. This makes sure that you
all know what the status is.
- establish a way to sort out disagreements so that it isn't
personal. Strong technical arguments should win.
- initially two related groups will need to operate very much
together. As the project becomes well defined you'll move to doing
your own sections. You will be writing separate reports.
- It may take longer than you think to define the project. It
WILL be frustrating. Part of a WPI Advisor's job is to drive that
process. I can tell your Mentor to make decisions, or just tell
him what's been decided, while it may be hard for you. At some
point you'll have enough info to make decisions for yourselves.
- as it's very likely that code from related groups will need to be
compatible with what the other group has written, it's going to be
VITAL to define module (or function)(or method) interfaces clearly
and formally. Record this information as part of the design
- start drawing diagrams early, and use them for discussion. Make
sure that you record them so that you can refine them for use in
your report and presentation.
- get general experience with any specialized NASA software asap to
figure out its use. Try to keep track of what examples you've used
to test what functionality. Share with the others. Start with
simple examples and work up.
- try to establish a model/architecture for the software to be developed.
They may have one already. Separate out the
functionality, such as control, communication, diagnosis, repair,
planning, etc. Draw diagrams to show possible data (and/or
- use stubs to allow incremental development of your system. Try to
arrange for it always to work (i.e., do something sensible) , even
if it isn't all finished yet.
- you'll need a requirements document, a system design document, and
an implementation design document. i.e., the decisions you made
about all three of these. Also make documents explaining the
reasoning behind your choices. You'll also need a
testing/analysis/evaluation design document.
- the more you agree (and the earlier) about ways to handle all
this information (e.g., reports, test cases, etc) the better. Set
up directories for each kind of thing you'll be working with. Agree on
formats for documentation, etc. Make it easy to assemble your
report from already written pieces, rather than writing the report
- Prof. Looft will have some requirements of his own that he'll want
you to follow -- especially wrt the writing schedule. You need to
do it, otherwise you'll be working 24 hr days in the final week!
- Please don't hesitate to email or call your Advisor if there
are problems. If they're at you should have phone mtg asap. Keep
WPI informed as much as possible.
- Hit the ground running this first week, and dont waste it.
- Have a great first week!
Mon Aug 12 15:01:59 EDT 2002