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
-
Three 50-minute lectures and student presentations weekly: Tuesdays, Wednesdays
and Fridays 12.30-13.20
-
One three hour meeting weekly: Mondays or Fridays (depending on your league
assignment) 14.30-17.20, labs and league meetings
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
-
Students will become more experienced and confident in software development
and be able to carry out group projects including planning, scheduling,
milestone definition, etc.
-
Students will learn how to identify and document requirements.
-
Students will be able to design simple user interfaces.
-
Students will learn and experience the importance of designing to an interface
specification.
-
Students will become skilled in writing precise program documentation for
maintainers.
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:
-
an individual grade for each student, based only on that one student's
performance,
-
a group grade for each team, based on the group's work and results, and
-
the final grade for each student combining the two grades above.
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:
-
40% project work (individual design, review and testing reports, see below)
-
25% mid-term examination
-
35% final examination
8.2. Team grades
Each team's group grade will be made up of grades for the following
factors weighted as follows:
-
30% performance of the team's module (Any program that does not play or
makes an illegal move will receive 0 for this grading component. Programs
that play legally will receive at least 15%. The tournament winner will
receive the full 30%. The team's performance grade will depend on its average
rank in the games in which it played.)
-
60% team report, including organization, completeness, overall programming
style, correctness, efficiency, simplicity, clarity ("inspectability"),
etc.
-
10% in-class presentations
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
-
if the student's individual grade is a failure, that individual grade or
-
if the student's individual grade is a pass, the higher of
-
the weighted average of the individual grade (70% weight) and the student's
group grade (30% weight) or
-
50% (pass).
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:
-
30% project (group work)
-
28% project (individual work)
-
17.5 % mid-term examination
-
24.5 % final examination
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:
-
Baber, Robert L., Error Free Software: Know-How and Know-Why of Program
Correctness, John Wiley & Sons, Chichester, 1991. Available in
pdf format without charge, see http://www.cas.mcmaster.ca/~baber/Books/Books.html.
-
Baber, Robert L., Translating English to Mathematics. Available
in pdf format without charge at http://www.cas.mcmaster.ca/~baber/Courses/General/EnglToMath.pdf.
-
Denvir, Tim, Introduction to Discrete Mathematics for Software Engineering,
Macmillan, 1986.
-
Gries, David and Schneider, Fred B., A Logical Approach to Discrete
Math, Springer-Verlag, 1993.
-
Hoffmann, D. and Strooper, P., Software Design, Automated Testing, and
Maintenance — A Practical Approach, International Thomson Computer
Press, 1995.
-
Kernighan, B. and Pike, R., The Practice of Programming, Addison-Wesley,
1999
-
Other manuals and handbooks for the programming language and system used
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.
-
January 7 Tuesday: Introduction to the course and to the project, grading
rules, etc.
-
January 15 Wednesday: We present the specification of the interface between
the Main Control Program and the teams' player modules.
-
January 21 Tuesday and 22 Wednesday: Leagues present their Module Guides,
first
draft
-
January 28 Tuesday and 29 Wednesday: Leagues present their Module Guides,
second
draft
-
February 4 Tuesday and 5 Wednesday: Leagues present samples of their Module
Interface Specifications: first draft
-
February 11 Tuesday and 12 Wednesday: Leagues present samples of their
Module Interface Specifications: second draft
-
February 12 Wednesday: Leagues present their schedules
-
February 14 Friday: Team schedules with individual assignments and deadlines
due
(February 17 Monday to 22 Saturday: mid-term recess)
-
February 25 Tuesday: Teams present samples of their Module Internal Designs:
first
draft
-
March 5 Wednesday: Teams present samples of their Module Internal Designs:
second
draft
-
March 7 Friday: Deadline for submitting individual design reports
-
March 11 Tuesday and 14 Friday: Leagues present their guidelines for interface
implementation conventions
March 12 Wednesday: Mid-term examination in room ABB/B163
-
March 18 Tuesday: Leagues present their report concerning the testing and
the inspection of the critical part
-
March 18 Tuesday 9.00 am: Deadline for optional submission of preliminary
team modules
-
March 18 Tuesday: Deadline for submitting individual review reports
-
March 25 Tuesday 9.00 am: Deadline for submitting team modules and league
modules
-
March 25 Tuesday: Deadline for submitting individual testing reports
-
March 28 Friday and April 1 Tuesday: Game tournament
-
April 1 Tuesday: Deadline for submitting team documentation (report)
-
April 8 Tuesday: Last class
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.