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.