Software Engineering 2B03: Software Design II

Course outline, 2003 February 26

1. Instructor

Dr.-Ing. Robert L. Baber
Office: ITB/168, telephone extension: 27874
Email: Baber@McMaster.CA
Course web site: http://www.cas.mcmaster.ca/~baber/Courses/2B03
Office hours: Tuesdays 10.30-11.30 and 15.30-16.30 or by appointment or when available

2. Course Structure

A major component of this course is a team project to document, design and develop a specified software module. Teams will be grouped into three leagues. Each league will agree on a structure of the software to be developed and will specify the interfaces between the subsystems. Each team will complete its module adhering to its league's internal interface specifications and deliver a correctly functioning module. In addition, each league must deliver a correctly functioning module using at least one component from each team in the league.

The system to be developed will involve playing a board or a card game. Each team's module will represent one player in the game. The team's modules will play against each other in a tournament near the end of the term.

Each student and each team will keep a log in a bound notebook. (A spiral or a looseleaf notebook is not acceptable.) Each log shall contain a record of all consultations in which the individual or team receives information or in which decisions are made. See also section 11 below.

3. Teaching Assistants

A teaching assistant (TA) is assigned to each league. The TA for each league is available during the weekly league meeting times and in the room reserved for the lab or league meeting. At these times the TA will advise on your design and will monitor progress.

4. Prerequisite and Corequisite Knowledge

Prerequisites: SFWR ENG 2A04, 2E03 or 2E04 (requires 1D04), 2F03 or 2F04
Corequisite: SFWR ENG 2C04

5. Calendar Description

Software system design, documentation, implementation, inspection and testing. Requirements documentation. Designing large sequential programs including precise documentation. Modularisation, module interface design. Hierarchical structures. Project organization.

6. Mission

The mission of this course is to teach students how to design and implement software systems working in project teams of five or more developers. Students learn to develop mathematically precise requirements for their software, to decompose the module into components (subsystems), to write precise interface specifications for those components, to write precise internal design documents for those components, to implement and test the components, to integrate the separately produced components and to test the complete module. They learn to decompose the project into work assignments (frequently corresponding to the components).

7. Objectives

8. Grading

Grading will distinguish between individual and group performance as outlined below. Each student must achieve a passing grade on the individual work in order to pass the course; a failing grade on the individual work will result in failing the course. I.e., substandard individual work cannot be compensated by a higher grade on the group work.

Three grades will be calculated:

8.1. Individual grades

There will be one mid-term examination and a final examination in this course. The student must pass at least one of these to pass the course. A student who fails both the mid-term and the final examination will fail the course. In this case, the student's individual (and final) grade will be the average of the two examinations weighted 40% and 60% respectively.

If the student passes either the mid-term or the final examination or both, the student's individual grade will be made up of the grades for individual project work and examinations weighted as follows:

8.2. Team grades

Each team's group grade will be made up of grades for the following factors weighted as follows:

The group grade will be adjusted for each individual student in the team by a peer assessment as described below.

8.3. Final grade for each student

The final grade for each student will consist of

Thus, when the individual grade and the student's group grade are both passes (the normal situation), the student's final grade will be made up of the several grading components weighted as follows: Note that each student's individual grade alone determines whether or not that student passes or fails the course. If the individual grade is a pass, the student's group grade will affect the student's final grade. That effect can be positive or negative.

Each student will be required to perform individually certain parts of the project work and to prepare the corresponding parts of the documentation. In particular, each student must design and code at least one routine in the group's final system, review at least one routine designed by some other member of the group, test at least one routine designed and reviewed by other members of the team, and prepare the corresponding parts of the documentation. These parts of the documentation will be graded as individualproject work (see the composition of grades above). This will ensure that each student gains experience in these different aspects of designing and implementing a software system. It is not permitted that only some of the team members, for example, do all of the design and coding; some others, all the testing; some others, preparing all the documentation, etc. Submitting individual documentation on design, review or testing work actually performed by another member of the team will be considered academic dishonesty (see also below).

Each member of a team will assess the contribution of each other member of the team. These peer assessments will be made individually and confidentially and submitted directly to the instructor. Each student will distribute a given number of points among the other members of her/his team according to the relative values of the other team members' contributions to the work of the team. All aspects of such contributions are to be considered, including technical and organizational contributions as well as cooperation, the degree to which the other member facilitated and supported the work of the team, ease of interaction with the other team members, etc. Ten percent of the group grade will be redistributed over the individuals in the team based on these peer assessments. More precisely, each student's group grade will be calculated by the following formula:

SGG = min(TGG*(0.9 + 0.1*n*f), (100+TGG)/2)
where SGG is the student's group grade (in %), TGG is the team's group grade (in %), n is the number of members in the team and f is the fraction of the peer assessment points received by the student in question. Thus, the peer assessment could reduce a team member's group grade by at most ten percent (e.g. from 70% to 63%) or increase it half way to 100% at most. If the members of a team receive equal peer assessments, each student's group grade will be the team group grade.

In addition, we reserve the right to differentially grade individual team members based on their documented relative contributions to the group's work on the project.

9. Reference literature

No new textbook is required for this course. In addition to the material used for 2A04 and slides and other material presented in the lectures in this course, the following reference literature is recommended:

10. Schedule

The following is a tentative schedule for this semester. Changes will be announced in class and/or a revised schedule will be published as required. Lectures will be given in the class periods between the key dates shown below.

(February 17 Monday to 22 Saturday: mid-term recess)
March 12 Wednesday: Mid-term examination in room ABB/B163
The lectures in the classes between the above project dates will cover the topics subdividing a module into subcomponents, Module Guide and Uses Hierarchy, Module Interface Specification, Module Internal Design, testing programs, module testing, software inspection, requirements documentation, scope and existence (persistence) of identifiers, Interface Implementation Conventions, project management and scheduling, working in teams and brief reviews of such topics as translating a specification in natural language into mathematical language, designing a routine based on its interface specification, etc.

11. Notes

Discrimination

"The Faculty of Engineering is concerned with ensuring an environment that is free of all adverse discrimination. If there is a problem that cannot be resolved by discussion among the persons concerned, individuals are reminded that they should contact their Department Chair, the Sexual Harrassment/Anti-Discrimination Officer (SHADO), as soon as possible." Academic Dishonesty "Students are reminded that they should read and comply with the Statement on Academic Ethics and the Senate Resolutions on Academic Dishonesty as found in the Senate Policy Statements distributed at registration and available in the Senate Office." It is the responsibility of an engineer to keep a complete log recording consultations in which he/she receives information or in which decisions are made. You are required to keep both an individual and a team log for this project. All consultations must be recorded. If we discover collaboration that was not recorded in the log, we will consider it academic dishonesty.

The documents referred to above (the Statement on Academic Ethics and the Senate Resolutions on Academic Dishonesty) are also available online at
http://www.mcmaster.ca/senate/academic/acadeth.htm and http://www.mcmaster.ca/senate/academic/academic.htm.