Design and implement a software system that simulates a space shuttle. It should be able to handle take-off, SRB separation, main tank separation, transition to orbit, orbit, re-entry, gliding, and landing. Include a graphical user interface that provides full 3D rendering of the shuttle during all phases of the mission. While you are not required to provide textured backrounds of the different environments, you may find it an easy way to improve the look and feel of your interface.

Your simulator should be fully tested and operational when you hand it in. The best submission will be sent to NASA to replace their current shuttle mission simulator (SMS). The equations that model the shuttle's behavior during the various phases are available on-line, however note that the transition functions that specify the boundary conditions are unreliable. See if you can improve them based on the empirical data, which is available from NASA's past mission analysis division (PMAD). Please use the techniques in the book on Adaptive Problem Reduction ILlustrations for your initial model, and of course you must use a Fully Object Oriented Language in your implementation.

The rest of the semester will be a set of related exercises whose purpose will be to expose you to the various stages of the software life cycle. You will be interviewing a client (me) to determine a set of requirements, coming up with a domain model, and then a design. When these stages are complete, you will then implement your design.

The domain will be the college domain. Your group has been contacted by a representative of Vassar College to design what they describe as an integrative registration system. They want to eliminate the need for paper during registration and during grade submission. That's all you know. Eager for the business, you claim your group has written many similar systems, and can deliver a product by May.

Your first project will be to arrange a meeting with the customer, and draw up an initial domain model and a set of requirements. Any domain specific language in the requirements document should be explained in the domain model. The customer expects the requirements and domain model by April 2 at 10AM. The model should include object and dataflow models.

Given the weekend to review them, you will meet again with the customer on April 6th or 7th to discuss the requirements.

The final working system will be the final group project. You may begin implementing it at any time. Note that in this case, early attempts at implementation may not always prove productive.