Syllabus

Objectives

The course covers a wide range of software development skills, from analyzing a problem to implementing a solution. On completion of the course, students should be able to:

1. Analyze a software development problem and express its essence succinctly and precisely;
2. Design a module structure to solve a problem, and evaluate alternatives;
3. Implement a module so that it executes efficiently and correctly;
4. Work in a small team, cooperating on these aspects of software development, and exchanging ideas in a constructive and organized fashion;
   
5. Appreciate engineering issues in the development of software, such as the importance of addressing the user's concerns, working with limited resources, maintainability, dependability, and division of labor.

Prerequisites

The course assumes that the student is able to

1. Write a small (ie, 100 line) program to meet a specification;
2. Understand basic notions of imperative programming (such as loops, procedures, exceptions, and aliasing) and of object-oriented programming (such as objects, references, self, interfaces, and subclassing);
3. Use, and understand programs that use, basic data structures such as arrays, hash tables, trees and lists.

Outcomes

On completion of the course, students should be able to

1. Identify key entities and relationships in the problem domain; write succinct textual descriptions of problems in the style of a user manual;
2. Design programs: Construct a design consisting of a collection of modules, using module dependency diagrams to express and evaluate couplings between modules, and object models to relate concrete to abstract state; Exploit well-known design patterns (such as Iterator, Observer, Factory and Visitor); Devise appropriate module specifications and express them informally in terms of pre- and post-conditions;Understand the appropriate roles of subtyping and inheritance, and use them effectively.
3. Implement programs: Write object-oriented code to satisfy the specification of a module; Express rep invariants, understand their impact on efficiency and ease of implementation, and implement them as runtime assertions; Understand the fundamental notions of data abstraction, and read and write informal abstraction functions for simple datatypes; Evaluate the correctness of a module by careful manual review using the specification, rep invariant and abstraction function; and Develop unit and system-level test suites, and evaluate their effectiveness using simple notions of specification and code coverage.
4. Perform a small development in a team, including problem analysis, design, implementation, and testing.

Each outcome supports the objective with the corresponding number. Objective (5) is supported by outcome (4).

All members of a team are usually given the same grade for the team project. The grade includes both written materials -- specifications, design and code -- as well as oral presentations and constructive participation in review sessions.

To encourage participation in reviews in the first half of term, teaching assistants can award significant credit (up to 20% of the final grade) for constructive contributions during review sessions. The total portion of the grade allotted to exercises and participation is capped at 50% of the total grade, but using participation credit, it is possible to achieve a perfect score despite points lost on written exercises.

Your written work will be graded on the quality of the ideas and the quality of their presentation. Code will be judged by its clarity, organization, style and correctness. It is the student's responsibility to demonstrate to the grader that the code is correct by showing the results of running a test suite. In the absence of such evidence, graders will assume that code is not correct. This is the standard you would be held to in industry. If there is no appropriate output to show, you should add a comment stating that a test suite executed successfully (or not, if it didn't).

We make every effort to standardize TA grading policies, but we reserve the right to normalize grades across recitation sections to account for remaining disparities.

Late/Missing work

Late work will receive no credit. Exercises are due at 4.05pm on Wednesdays in the course secretary's office (NE43-529). In unusual or extenuating circumstances (such as illness with a doctor's note), you may be able to turn in an exercise late and still obtain credit for it. Unless the circumstances are quite extraordinary, you must receive advance permission from your TA.

You must hand in: Exercise 4, and one of Exercise 5 or 6, and the project or you will fail the course. You will not pass the course if you receive no credit for these, or if what you hand in is too insubstantial to be deemed a reasonable effort. Grades of "incomplete" will not be given, except under extraordinary circumstances.

Collaborative Work

The Departmental Guidelines Relating to Academic Honesty require that we inform you of our expectations regarding permissible academic conduct.

You may discuss any of the course material with other students. You may discuss the exercises, and you may talk about potential solutions with other students, whether or not they currently enrolled in the class. What you hand in, however, must be entirely your own work (with the exception of reused code -- see below). You will be expected to be able to explain your work during reviews in front of other students, so it will be necessary for you to understand your solution to any problem in every detail. In particular, you must not copy explanations, written answers to questions, design diagrams, source code, or test cases from other students, in whole or in part.

Throughout the course, you may make use of any software artifact -- specifications, design, algorithms or code -- in the public domain , so long as it was not prepared by a student for 6.170. For example, you can use code you find in textbooks and on the web, but you can't copy code from your fraternity's bible. For the project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team will be expected to contribute equally to the design and implementation. We will expect the team to be able to account for what each team member contributed to the project. The same policies that apply to individual students during the first half the term also apply to the project teams. For instance, a team can discuss design ideas with another team, but must not copy any of its design models. 'Pair programming' is permitted for the project, but is strictly forbidden for the individual exercises.

This policy is more lenient than it has been in previous terms, in an attempt to foster constructive collaboration amongst students. We therefore depend on the honesty of students in not violating it, and will take very seriously even minor infractions. If you are found to have copied code from another student's work, you should expect to fail the course.

We rely on students' honesty in their declarations that test suites run successfully. It is a very serious violation of academic ethics to submit such a claim with code that does not in fact pass the suite. In order to avoid clerical errors that may give the appearance of dishonesty, we strongly suggest that you rerun all your test suites when you have completed your code immediately prior to submission.