Courses:

Special software is required to use some of the files in this section: .m, .xls, .zip.

A text editor can be used to open the .asv files.

Overview

Homework assignments for this course will indicate the scope of the design to undertake e.g., how many factors to optimize between, but rarely the specific problem to solve.  Instead, student teams will choose problems of interest, and refine their design objectives in consultation with the faculty.  In that regard, each student team will propose both the problem and the solution.

Process

Homework for this class will be completed in teams that are selected by the instructors and changed during the semester. Homework will be handed out every other Wednesday and will be due one week later. In some cases each team's homework problems may be unique. When homework is turned in you should make two copies of your work, one for the instructor and one for another team to evaluate. In the next week you will prepare an evaluation of the other team's work.

Software Modules

Most of the homework problems will require the coding of software modules. We suggest you use MATLAB® to code these modules and will provide a tutorial to help you learn the programming language. We intend for these modules to be useful in future subjects (e.g. 16.89) or satellite system design work beyond your studies at MIT. The point of analyzing the other teams' work and receiving comments on your own is to help you build useful and effective tools. Your modules will very likely be used in 16.89 Space Systems Engineering.

The modules should mathematically capture the relationships between the discipline's inputs and outputs and in general relate subsystem performance and cost to the subsystem's requirements. When used in an integrated concurrent engineering context, you will be asked to determine how the subsystem performance or cost will change as a result of changes in the requirements. The module must be complex enough to capture the important relationships yet simple enough to provide outputs that make sense. You should ensure that your modules are appropriately documented with explicit definitions of input and output so that you and others will understand its structure in the 16.851 evaluation as well as future applications. You are likely to use this program again in the future or may need to use part of it in developing the solution to another problem. You might have to update it or correct errors. In any case, the faculty and the review team will grade it. Documentation is essential so that we can understand and give proper credit for your work. Good documentation would include:

1. Programmer's name
2. A concise requirements specification
3. Descriptions of problem inputs, expected outputs, constraints and applicable formula
4. A pseudo-code or flowchart for its algorithm (optional)
5. A source program listing
6. A hardcopy of a sample test run of the program
7. A user's guide explaining to nonprogrammer users how the program should be used (optional).

Assignments

The assignments for this course that were completed by each student group in Fall 2003 are provided in the table below.  A brief description of the problem each group selected may be found under 'Assignments'.  The 'Solutions' linked in the table are based upon pieces of code included under 'Tools'. The student work is courtesy of the students listed below.