Getting Started at NASA GSFC

• Please (re)read:
  http://www.cs.wpi.edu/~cew/courses/projguide.html
  http://www.cs.wpi.edu/~dcb/project-grades.html
  http://www.cs.wpi.edu/~dcb/writing.html

• 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 their offices.

• 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 standards.

• if you cant get answers immediately, at least collect and refine your questions.

• 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, implementation, testing.

• 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 document.

• 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 control) flows.

• 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 itself.

• 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!