Software Engineering Curriculum Committee
Option Revision Group
Proposal for the Software Engineering Curriculum
2004 October 25
Contents
Summary
Brief History
Problems
Proposed Calendars and Handbooks
SE 465 : Software Quality and Maintenance
SE 464 : Software Design and Architectures
SE 463 : Software Requirements Specification and Analysis
The Project
Characteristics
Source of Input Materials
Effects on the CS/ECE Software Engineering Option
Summary
The Software Engineering curriculum has a sequence of three senior core courses based on the CS/
ECE Software Engineering Option. They are taken consecutively in 3B, 4A, and 4B. The current
order is:
Software Requirements Specification and Analysis (SE 463)
Software Design and Architectures (SE 464)
Software Testing, Quality Assurance, and Maintenance (SE 465)
The proposal is to deliver them in the reverse order.
Problems
This sequence is being given for the first time in Fall 2004 with the class of 2006, being in 3B, taking
SE-463. However, experience with the Software Engineering Option in CS and ECE has identified
the following problems:
• Students tend to make design and impementation decisions too early (i.e. during requirements
analysis).
• It’s hard to control project content downstream after free decisions have been taken in an earlier
course.
• Students cannot well foresee the future effects of their design decisions, nor do they actually see
them until it’s too late.
• Lecture material and project requirements are difficult to keep aligned.
• The important and realistic experience of working with “legacy” (i.e. other people’s designs) is
absent.
• Project development and group membership tends to be unstable through five terms including two
work terms (this maybe less a problem in the more stable population of the SE program)
In December 2003 Dan Berry and Andrew Malton devised the idea (within the SE Option) of
reversing the normal order of taking these courses, while preserving the waterfall project order within
them, as a way of regaining control and stability in project development, and of providing the
“legacy” experience. Furthermore, this reordering would enable students to experience downstream
the effects of upstream design errors and poor judgement before embarking on similar decisions
themselves. It would also be more realistic in breaking the “waterfall” development pattern.
In the reversed order, the project’s requirements would still be analysed in SE 463, the project would
still be designed and constructed in SE 464, and subject to systematic testing and some post-hoc
maintenance tasks in SE 465. However, students would take them in the reverse order, in each case
working in a group with materials produced by an earlier iteration of the upstream course.
Proposed Calendar Descriptions
The rest of this proposal contains slightly modified versions of the Calendar Descriptions of the three
couses in the proposed order. Changes are indicated as deletions and additions to the current text.
A fuller description of each course has been attached, based on the Handbook descriptions of the
corresponding courses in CS. Some Topics have been dropped and others added: the Notes which
follow explain why.
SE 465 DIS,LAB,LEC,TUT 0.50
Course ID: 010036
Software Testing and Quality Assurance and Maintenance
Systematic testing of software systems; unit, integration and system level testing;
software verification; code inspections; use of metrics; quality assurance;
measurement and prediction of software reliability; software maintenance; software
reuse and reverse engineering. Lab project involving a large software system.
[Note: Offered: W F]
Prereq: SE 464 STAT 206; 3B Software Engineering students only
Antireq: CS 447, ECE 453, ECE 355, CS 430
Topics
• Overview of the maintenance and testing activities within the life cycle; brief introduction to project
related CASE tools and necessary background; the theory of testing (3 hours).
• Software verification, correctness proofs, symbolic execution. Walkthroughs and inspections (2
hours).
• Cost estimation. Project scheduling. Specification of work units.
• Testing strategies, including unit level, path and dataflow testing, domain testing, decision tables,
and state-based testing; coverage metrics; object-oriented testing; effort, efficiency, and
effectiveness concerns (6 hours).
• Integration testing (decomposition based, bottom-up, top-down, call graph based, path based,
MM paths and atomic system functions). Validation and system testing (data, action, port, event
and thread testing, structural and functional approaches, operational profiles). TTCN test suites.
• Test categories, test design, system integration, system testing, acceptance testing, test planning,
execution, automation, and adequacy. (12 hours)
• Introduction, examination of various quality/complexity metrics; availability; measurement and
prediction of reliability (5 hours).
• Major maintenance activities. Estimating maintenance costs and productivity.Use of software
quality metrics. Principles of software reuse and reverse engineering techniques. Economics and
expectations of software reengineering. (8 hours)
Notes
The title change is proposed to be more in keeping with the view of Quality as a wider field inclusive
of testing; and to reflect the maintenance topic separately as is usual in the industry.
The description of the project is enlarged to emphasise the dependence on previous students’ work.
The course is now to be offered in the Fall, as the first course; and SE 464 is no longer a prerequisite
but a successor. The other constraint changes are corrections.
Project planning and management topics (e.g. cost estimation) were moved to SE 464 where they
seem more appropriate.
The approach to testing topics is rewritten to be more systematic and wider-ranging, as befits the
(now) first course in the sequence.
Walkthroughs and inspections are retained as industrially most relevant; the other non-executionbased quality techniques are removed to make room for more systematic presentation of testing
topics.
Software re-engineering is reduced to make room for the heightened emphasis on testing methods.
SE 464 DIS,LAB,LEC,TUT 0.50
Course ID: 004414
Software Design and Architectures
The Ssoftware design processes and its models, representations of designs/
architecture, software reference architectures, advanced design plans patterns,
design methods, design state assessment heuristics, design quality assurance,
design verification. Lab project involving a large software system..
[Note: Offered: S]
Prereq: SE 465; 4A Software Engineering students only
Antireq: CS 446, ECE 452, ECE 355, CS 430
Topics
• The design process: Input, constraints, results; the relationship between design and quality; design
and evolution; design in mature implementation technologies (1 hours).
• Searching the design space: state, goal structure, control; models of the design process:
transformational, plan/architecture driven (3 hours).
• Generative design operations, early quantitative evaluations
• Cost estimation, scheduling, and work unit specification in implementation projects (2 hours)
• Modeling languages: informal representations, design notations; formal representations; the UML;
domain-specific architectural description; standards; reference architectures; design
documentation. (11 hours)
• Design plans: data structures, concurrency, object-oriented design patterns; reference
architectures (e.g. for compilers, embedded control, DBMS, web servers, GUI-based applications)
(9 hours).
• Design strategies: object modeling, structured design, real-time, user interfaces; COTS (6 hours).
• Design assessment and tradeoffs, evolvability, understandability, complexity metrics; analytic,
simulation, rapid prototyping. (2 hours)
• Design reviews, scenarios and test cases, testing of executable design representations. (2 hours)
Notes
The changes in the course description are all small corrections that reflect the practice and
terrminology of current instructors of CS 446 / ECE 452.
The expanded project description conforms to the project description for the other two courses, and
emphasises the dependence on previous students’ work.
The small constraint change reflects block scheduling in the SE program.
A section on project management is added: it must be short and focused because SE students
already have studied project management in a whole course, SE 362.
UML and design patterns are added to reflect current practice in industry and in the teaching of the
SE Option in CS and ECE.
SE 463 DIS,LAB,LEC,TUT 0.50
Course ID: 004413
Software Requirements Specification and Analysis
This course is intended to introduce students Introduction to the requirements
definition phase of software development. Models, notations, and processes for
software requirements identification, representation, validation, and analysis. An
important component of the course is a group project: the software requirements
specification of a large software system. Lab project involving a large software
system.
[Note: Offered: F W]
Prereq: CS 342 and SE 362 SE 464; 4B Software Engineering students only.
Antireq: CS 445, ECE 451, ECE 355, CS 430
Topics
• Overview of software development and life cycle models; requirements: identification,
representation, validation, analysis; related standards and CASE tools (3 hours).
• Project discussion, including group management, member duties and group dynamics.
• Methods for obtaining requirements from various sources (3 hours).
• Overview of notations and presentation of case studies: entity relationship models, data flow
diagrams and structured analysis, SDL, UML; classification of requirements specification notations;
relationship to application characteristics; specification of control, functional, data requirements
(13 hours).
• Specification of maintainability, safety, reliability, performance, and the like (4 hours).
• Validation methods: active reviews, scenarios and threads, executable specifications, automated
analysis, formal verification, non-execution-based testing (7 hours).
• Estimating duration and cost of project based on requirements alone: expert judgement, Delphi
estimates, function points, algorithmic cost models. CPM graphs, Gantt charts, milestones (3
hours).
• The relationship between requirements and design specifications (3 hours).
Notes
The first change eliminates a needless difference from the description of CS 445. .
The expanded project description conforms to the project description for the other two courses, and
emphasises the dependence on previous students’ work.
The constraint changes reflect block scheduling in the SE program and the change to Winter offering
since this is now the last course in the sequence.
General project management topics are assumed from the prerequisite SE 362 and from the focused
review in SE 464 (which now precedes this course). Specific topics relating to project estimation
from requirements data are added.
The Project
Characteristics
A single software development project is carried through these three courses. During the last few
years of delivery of the corresponding Option courses (e.g. CS 445, 446, and 447) the project’s
defining characteristics have been:
• Group work in teams of three or four
• Total elapsed time of fifteen months (three on-campus terms and two work terms)
• About 150 man-days total labour (based on 1 day’s work per student per week during course)
• Waterfall-style development plan with large document milestones
• Use of free software
• Application is telephony including signaling control and management information subsystems
• Architecture is static (“closed”) “big client/server” style
• Maintenance task is “internationalization” of the user interface.
The telephony application has been supported by specially adpated Nortel Meridian equipment that
provide digital voice-over-internet, and the by the Solaris operating system.
The present proposal will add two characteristics to the project, increasing its “realism”:
• Software is developed from on legacy designs (i.e. from a previous iteration of an earlier phase)
• Sophistication is developed in reverse (i.e. from maintenance through design to requirements)
Source of Materials
In the previous régime, each iteration of the course project would be based on previous work by the
same students; in the new régime, it is to be based on previous work by other students. The
problems that arise from building on prior work are similar, namely, errors in prior work must be
identified and repaired; the general quality of prior work affects the progress and the learning
experience; and variaitions in quality of prior work causes unfair variations in performance and
grading. The new régime expects to control these problems better, because the instructor has more
choice and control over the “input” than before.
In the new régime, students in SE 465 will work on implementations made by other students from
specifications written by still other students.. The instructor then can choose
• particularly good implementations for which the maintenance task is not difficult
• particularly poor implementations which reveal by their weakness the need for good design
• a range of implementations from the previous iteration of SE-B, to improve the ongoing quality
of the courses
In a given iteration of the course, the instructor would choose one of these options. He need not be
constrained to choose only one project instance for all the teams, as long as the general quality of
the choices is roughly the same. A persistently assigned lab. coordinator could help with this choice
by maintaining a catalogue of well-understood implementations that are re-used in the course.
In the same way, students in SE 464 will work from requirements documents written by other
students. They are not now experts on the requirements, as they were in the previous régime. The
instructor therefore must choose to assign from
• particularly clear and complete requirements which given everyone a good start
• particularly poor requirements which give everyone a realistic sense of frustration and a sense
of the need to do requirements analysis well, when they get to SE-C.
• a range of requirements documents from a previous iteration of SE-C
In a given iteration of the course, the instructor would choose one of these options. His choice
should range over requirements documents of a similar quality. It may happen that a small set of
requirements documents can be re-used continually in the stable state of the course.
This raises issues of intellectual property, privacy, and paedogogy.
Legally the IP in student course work submissions may be used for academic purposes (such as
these) within the University. However, it is prudent and courteous to remind students of the fact in
this situation. It will probably be possible to withhold from reuse any submission which a student
requests to remain private, since probably not all submissions will need to be candidates for reuse.
Effects on the CS/ECE Software Engineering Option
Before we approve and implement the proposal for reversing the SE courses for the SE Option
students, we first have to figure out how to accommodate the CS students who take these courses
without completing the option. Historically, they have made up a significant fraction of both the
Requirements course and the Design course:
course
CS 445
term
F02
W03
F03
W04
F04
proportion of class who do not complete the Option
44 of 70 students
34 of 55 students
53 of 81 students
43 of 57 students
33 of 45 students (20% drop may be students lost to the SE degree program)
CS 446
S03
F03
S04
21 of 54 students
14 of 34 students
20 of 48 students
Below are some ideas for accommodating these CS students. These ideas are not provided for
discussion, as this issue is best addressed by the CS curriculum committee. The ideas are provided
to demonstrate that the CS students can feasibly be accommodated.
1 Have CS students take the Testing/Quality Assurance course. CS students don't get a solid
treatment of quality assurance in any other course. Many students and professionals believe that
testing is the lowest rung of the software-development ladder. But professional testers who have
the mindset of knowing how to break a system, who have ability to out think the developer and
guess what mistakes the developer might have made, and who know how to effectively and
economically test a software system are in high demand.
2 Remove the prerequisites from the three courses, and open up the course to all CS students.
The prerequisites are ideal, but are they essential? Would a CS student who took the courses in
another order come away with an acceptable knowledge of the course? Would such a student
be at an unfair disadvantage, or could we bring them up to speed in tutorial sessions? (I would
guess that such a student would do fine in the Design course, but that it would be harder to
bring them up to speed for the Requirements because prior knowledge of the project is more
critical in this course.) Would ECE want similar access to these courses (e.g., allow ECE students
to choose between ECE 355 and two of the three courses)?
We would want to reserve space in these courses for the SE Option students, either by reserving
spots or by not opening the course to CS students until open enrollment.
Also, it would be good if we could structure the prerequisites so that the SE Option students, at
least, took the courses in their desired order. We might be able to accomplish this by being
creative with the prerequisites. For example, prerequisites for CS 446 could be 4A Computer
Science/SE Option and CS 447) or 4A Computer Science
Such a prerequisite might also keep students from gaming the system by proclaiming
themselves to be Option students so that they have priority access to the courses, and then
dropping out of the Option once they'd taken the courses they wanted.
3 Introducing a stand-alone requirements course. If the real demand among the CS students it for
the requirements course, then we could offer separately from the Option sequence a
requirements that had its own stand alone project. It would be good if we could continue to offer
some kind of a requirements course to the CS students, because the philosophy, principles,
practices, and technology that are used in determining a software's requirements are different
from anything else that the students see or experience in their CS program.
4 A single compressed course on software engineering. People seem to think there is demand for
such a course. From prior experiences we expect problems with such a course:
• Students do not apparently learn very much in such courses.
• Professors do not know what to examine in such courses.
• Teaching resources may be insufficient, as they must already covering the degree sequence,
the option sequence, and CS 246.
The compressed course is what is done, or has historically been done, at other universities.
Some Canadian Universities currently have a two-course sequence: the University of Toronto
has systems analysis followed by software engineering; the University of British Columbia has
software engineering followed by software engineering project.