Teaching Software Engineering in a Computer Science Department G. Dobbie & G. Bartfai Department of Computer Science Victoria University of Wellington PO Box 600, Wellington, New Zealand fgill,
[email protected]
Abstract This paper discusses four issues that are related to teaching software engineering, which the authors have found of particular relevance with respect to the computer science programme oered by the Department of Computer Science at Victoria University of Wellington, New Zealand. These issues are programming vs. software engineering, structured vs. object-oriented methods, textbook selection and assessment of project work. Underlying these issues is the question of how industrial experience can be taught or simulated in software engineering courses. The aim of this paper is to share our experiences hoping to stimulate further discussion on how software engineering can best be taught.
1 Introduction In the Department of Computer Science at Victoria University of Wellington (VUW), like other Computer Science Departments worldwide, we teach courses in software engineering. The aims of these courses are to make students aware that analysis, design and planning are essential in large projects and to introduce the students to processes and concepts that are widely used in industry. This paper raises questions related to the teaching of software engineering in computer science departments and discusses these questions with respect to our program at VUW. The questions are: After their programmingat school and in rst and second year courses, students think they know what programming is all about. That is, students have this misconception that programming is only taking a specication, writing the program
to meet the specications, and running the program a few times. If the program needs maintaining then the author of the program makes the changes. How can we convince students that there is more to programming than this? In their rst and second years, students are again taught to write \good" programs. That is, programs that are well documented and modular, have low cohesion and high coupling and execute e ciently. They already know what a \good" program is | what can we tell them that is new? Most students have no industry experience, so they have no perception of what happens in industry. How can this be taught or simulated in software engineering courses? What is important in software engineering courses? How should the material be presented? What textbook(s) are relevant? In a software engineering team project, is there an objective and fair assessment scheme that keeps a good balance between the team and individuals? Should we teach structured analysis/structured design or object-oriented analysis/object-oriented design or both? The aim of this paper is to discuss these questions with respect to our experiences of teaching software engineering in a computer science department, and to share our experiences with the reader. Section 2 describes how software engineering ts into our programme in Computer Science at Victoria University of Wellington. Section 3 deals with some of the issues raised by the above questions. Section 3.1 highlights the issue of programming in the broader context of software engineering. Section 3.2 discusses the question of teaching structured and object-oriented methods. Section 3.3
looks at textbook selection. Section 3.4 deals with how projects are assessed. Finally, conclusions are drawn in section 4.
2 The programme at VUW The programme at VUW includes two rst year courses. Introduction to Computer Program Design is a course on programming in Pascal that emphasises good design of computer programs based on modularity and abstraction. It is followed by a course called Introduction to Data Structures and Algorithms. There are three second year courses. The major topics in System and Program Development are object-oriented design for large programs, and le organisation structures for large amounts of data. This course concerns practical programming, and currently involves learning the programming language C++ and undertaking several projects in program design and implementation 1]. Formal Methods of Computer Science introduces a number of fundamental topics in computer science, including data abstraction verication and analysis of algorithms algorithms for pattern matching, graph traversal, storage management grammars, languages and parsing. Computer Organisation covers the fundamentals of assembly language programming and related topics such as data representation, computer arithmetic, machine instruction set design, memory and input/output systems, digital logic, and reduced instruction set computers (RISC). There are nine third year courses. Software Engineering Principles introduces the basic methods, tools and procedures for software development in the large. This includes discussion of the software lifecycle, the common software engineering paradigms and their key elements, such as project planning, requirements analysis and specication, design, implementation, testing, maintenance, software quality assurance, and software conguration management. The practical work includes the application of a Computer Aided Software Engineering (CASE) tool1. Software Engineering Practice is a practical application through project work of the principles developed in Software Engineering Principles. A major component of the course is a team project, in which students work on a software product in teams of 4-6, going through the major stages of software develop1 The CASE tool that has been used for the past ve years is TeamWork from CADRE Technologies Inc.
ment. Database Systems reviews physical data organisation techniques and discusses external, conceptual and internal data models. Design and Analysis of Algorithms studies techniques for designing algorithms and for investigating their accuracy and efciency. Design techniques examined include Divide and Conquer, Dynamic Programming, Greedy Algorithms, and Graph Traversal. Programming Languages studies various programming languages chosen to illustrate signicant aspects of programming language design and implementation. Languages used in the course include Lisp, C++, Smalltalk, Ada, Scheme, ML and Prolog. Operating Systems covers the principle functions of an operating system: concurrency control, resource management, le systems and security. Data Communications examines, in detail, the architecture and protocols of data communication networks (both long haul and local area), and the algorithms used in their implementations. Introduction to Articial Intelligence covers basic concepts of knowledge representation and inference to provide the basic vocabulary of AI, before looking at some application areas including Expert Systems, game playing, natural language understanding and route planning. Computer Graphics includes data structures suitable for modelling solid objects rendering algorithms including ray-tracing and radiosity animation of rigid and exible objects. The fourth year courses which relate to software engineering are Formal Software Development, HumanComputer Interaction, Object-Oriented Paradigms, and Advanced Software Engineering. The next section discusses our software engineering courses in detail.
2.1 Structure of the software engineering course In the third year software engineering courses, most of the time is devoted to explaining what must be done in the project, so the emphasis is mainly on project planning and management, analysis and design. Software Engineering Principles teaches the principles while Software Engineering Practice allows the students to apply what they have learnt. There are many areas that aren't covered in these courses that are equally important. Some of these areas are covered in fourth year. Advanced Software Engineering is an extension of the third year courses, looking at the basis of concepts in the area and the current research in the area. In this course, there is the opportunity for students to pursue a particular area they are interested in, in the form of an essay. Because com-
munication is important, students do give individual presentations based on an area of their choice. In a project, they also have the opportunity to apply some technique like cost estimation or formal specication that they didn't use in their previous project. Formal Software Development covers a selection of topics in the application of logic to software specication, program development and verication. This course investigates approaches ranging from fully formal techniques through to rigorous methods which are mathematically based without being totally formal. There is an emphasis in this course on case studies and examples. Object-Oriented Paradigms attempts to examine various object-oriented phenomena to determine what is really going on. One of the major topics of this course is Object-Oriented Design and Analysis.
3 The issues In this section, we discuss four issues that we have found of particular relevance in teaching software engineering at VUW.
3.1 Programming vs. Software Engineering Students in their third year of study in computer science are expected to know what constitutes a good program. There is again a need to emphasise this and build on their knowledge. However, because of their past experiences, many of the students believe that they know what software development is all about. They indeed have been exposed to many issues like good program design, program development, and reuse. Rather than covering this material again, one of our tasks is to extend their view of a \good" program, and explain how programming ts into the broader view of the software life cycle (for example, by describing standards that companies adhere to, by describing the importance of maintainability). There is a need to reiterate the environment and point out other factors that are associated with this environment, for example, the need to write programs and documentation that are easily understood by others. Software Engineering Principles carefully describes the kind of environments the course is directed at. That is, projects produced by a team of people where the customer is often external to the team. Currently we don't have someone from industry discuss his/her role with the class but it would be helpful to have a project leader or someone who is involved in a team project to convince students that this is what
happens in industry { it is not just something that is concocted by the author of a textbook.
3.2 Structured vs. object-oriented methods In recent years, object-oriented analysis and design methods have gained increasing popularity (e.g. 2, 3, 4]). These, together with the use of object-oriented (OO) programming languages, facilitate an interactive software development whereby a coherent view, i.e. that of a system built up of interacting objects, is fostered throughout. As a result of this, the distinction between the dierent phases gets blurred, and most documents undergo continuous changes. This object-oriented paradigm is in contrast to the classical one that denes the project milestones more clearly, and changes to documents produced earlier need to be more formal. Until 1994, the software engineering course was centred around structured methods: structured analysis (SA 5]) and structured design (SD 13]). The strictly sequential nature of this paradigm tted well with both the teaching and the practical project component. Since 1994, we have made eorts to encourage the use of OO methods. However, we feel the OO methods still have not reached the level of maturity that they can be considered as a complete replacement for structured methods in software engineering education. Furthermore, SA and SD are still commonly used in industry. So currently the course is still set up, with its set milestones and deadlines, to favour structured methods, which certainly causes some tension for those teams that choose to follow the OO paradigm. As a result, we have seen projects where SA was used for the analysis, and OOD for the design, or even when only the programming was done using an object-oriented programming language. We have not found an easy and satisfactory answer to this problem to date. However, we believe that we should continue to teach both methodologies because both are understood and used in industry. With respect to OOA/OOD, which methodology to teach is still an open question. We have taught Coad and Yourdons' methodology because they split analysis and design. However, their method does not scale down well. In both Advanced Software Engineering and Object-Oriented Paradigms we concentrate on Booch's methodology 2] because it is one of the more mature and well documented methodologies.
3.3 Textbook selection So far we have not found a single book that has a balanced coverage of the principles as well as the practical guidance for doing a group project. These two issues most often seem to be handled separately, an example for which are the books by Stephen R. Schach 9, 10] where principles and practice are discussed in separate books. In the past 5 years, we have used two books (8] and 7]), which we now use in both the \principles" and the \project" course. Pressman's book is a popular text on software engineering. However, it lacks the kind of practical guidance that is needed in team projects. Mynatt, with its emphasis on project guidance and a lighter coverage of methodologies, complements Pressman nicely.
3.4 The project component The practical project is a central component of software engineering education 11]. Because most students have little industrial experience, it is necessary to provide them with such. Before 1995, this was an essential part of the only one-semester course on software engineering. In that course, analysis was introduced in lectures and then performed in the project, next design was introduced in lectures and then performed in the project. Thus the project dictated the order in which the lectures were introduced and there was no room for variation or slippage. We split this course in 1995, separating the lectures from the project. This has the advantage of being able to explain the whole picture before students start their projects. There are no longer the same time constraints imposed on the lectures. What makes the project unique is that students have to work in teams, typically of 4-6 people. This single factor accounts for most of the di culties, apart from the application of proper software engineering methodologies and tools. Very few students can really appreciate, quite naturally, what we mean by saying in the rst lecture that a useful prerequisite for the study of software engineering is that the student \should have been married at least once" (a quote from 11] attributed to Jon Bentley). This means that the student should have some ability to communicate and work together fairly harmoniously. Popular textbooks like 8] and 12] do discuss team organisation and management, but this can very much remain \in the air" without experiencing the di culties of working in teams. Each team is allocated a project with a customer and a supervisor. The customer is the expert in the
domain. The supervisor provides the software engineering expertise and also judges the team's progress. When the groups have completed their projects, they present them to their customer and other interested parties.
3.4.1 Assessment of project work
One of the challenging tasks we believe each course instructor has to face is how to create a fair project grading scheme. There are many factors that aect this such as the quality of the documents, the quality of the design, code, the commitment of each individual to the project, and so on. We do recognise there are individual dierences, but there is also one common goal towards which each team member must work as part of the team. We have adopted the following assessment scheme. The nal grade of each student is based on a group and an individual component, worth 30% and 40%, respectively. (The remaining 30% is an individual essay that is related to the project.) The group component itself is broken down to the following items: Item of assessment Weight Requirements and Specication 20% User Interface Design 15% Detailed Design 20% Integration and Test Plan 15% Source Code 10% Discretionary points 20% All but the last item refer to project milestones2 and are assessed through the corresponding document produced. The weights reect the relative importance of each document. Note, for example, that the source code itself is worth the least, which emphasises the importance of the preceding phases in the software life cycle, and that coding is a \natural consequence" of design. The last item (discretionary points) includes essentially all quality factors that cannot be assessed through the documents but nevertheless are integral parts of the assessment. It includes team organisation, keeping the deadlines, completion of the project, but also gives scope for us to make adjustments to the overall group grade (e.g. if a team member resigns halfway through the project, or the team has extreme di culty due to the instability of a programming tool). The group mark is the same for each team member. The individual mark should ideally reect the individual's contribution to the project. A reasonable
2 There are two more documents (Project Plan and Installation and User's Guide) that are produced, but are not formally assessed, primarily for workload considerations.
suggestion is that this contribution can be measured by the quality of the work and the amount of time and eort that have been put into the project (see, for example, pages 12{14 in 6]). Students, however, often have a misconception about the \quality" of the work at the beginning of the course. They have been taught, quite correctly, that quality is measured by standard criteria (e.g. high cohesion and low coupling in design, well-documented source code, etc.), and the mark they get is based purely on their individual work. In the context of group work, however, quality takes on a new dimension, namely whether the work the individual produces does actually contribute to the quality of the nal product. A piece of brilliant program code is worth very little if others in the team do not know how to use it, or if it has to be rewritten because it was implemented according to a dierent design concept (that perhaps the student had pursued earlier, but the team later decided to change). Based on the above considerations, we believe, that the individual mark cannot be handled independently from the group's performance. The above division of 30%/40% (between the group and individual components) in fact reects more of an academic constraint than the true nature of assessment in the project. Another important and distinctive aspect of the individual mark is that it is not broken down into a list of weighted items (like the group component), and that it is given out after the completion of the project. We aim for an objective marking scheme as much as possible. However, what can be observed by project supervisors is often insu cient to establish a grade for individuals in the team. Therefore, we also require each team member to hand in subjective ratings of all team members after each major phase, and also after the project is completed. This gives students a chance to express their view of other people allowing us to check whether the \public view" of the individual corresponds to the \private" one. Most problems can be picked up this way. The nal mark for the individual work is then decided by the course organiser in consultation with project supervisors, and the subjective ratings are also taken into account. We have found that this assessment scheme keeps a reasonable balance between the team and the individual's performance.
4 Conclusion This paper describes how software engineering is taught in the Computer Science Department at Victoria University of Wellington and discusses four issues
that have arisen. The rst issue is what should be covered in the software engineering courses. A subissue is how should the software engineering courses deal with the material that is taught in other courses. In our programme, some software engineering material is taught outside the software engineering courses. In particular, from rst year, students are taught about program design. We see this as an advantage because it allows our third year courses to concentrate on programming-in-thelarge. In the software engineering courses, we highlight the material that is taught in other courses and discuss how it relates to programming-in-the-large. The second issue is whether we should teach Structured Analysis/Structured Design or Object-Oriented Analysis/Object-Oriented Design. This issue is still unresolved. Because of our investment in Structured Analysis/Structured Design and because it is still relevant in industry, we continue to teach Structured Analysis/Structured Design. We also feel the need to introduce our students to Object-Oriented Analysis/Object-Oriented Design both because we are teaching C++ at second year and because it is widely recognised in industry. The third issue is textbook selection. We use two textbooks in the third year courses (8] and 7]). However, we are still searching for one textbook that covers both \principles" and the \project" courses nicely. The nal issue is assessment of project work. Because projects are done in teams, there is a need to recognise both the team eort and the individual efforts. So, our assessment scheme is based on a group and an individual component, worth 30% and 40% respectively. The remaining 30% is an individual essay that is related to the project. We hope this paper will encourage other software engineers to share their ideas and experiences, and stimulate discussion on how software engineering can be taught in computer science departments.
References 1] R.L. Biddle and E.D. Tempero. Teaching C++ Experience at Victoria University of Wellington. In Proc. of the Software Education Conference, pages 274{281, Dunedin, New Zealand, 1994. 2] G. Booch. Object-oriented analysis and design with applications. Benjamin/Cummings Pub. Co., 2nd edition, 1994. 3] P. Coad and E. Yourdon. Object-Oriented Analysis. Yourdon Press, 2nd edition, 1991.
4] P. Coad and E. Yourdon. Object-Oriented Design. Yourdon Press, 1991. 5] T. DeMarco. Structured Analysis and System Specication. Prentice-Hall, 1979. 6] B. T. Mynatt. Software Engineering with Student Project Guidance, Instructor's Guide. PrenticeHall International, Inc., 1989. 7] B. T. Mynatt. Software Engineering with Student Project Guidance. Prentice-Hall International, Inc., 1990. 8] R.S. Pressman. Software Engineering, A Practitioner's Approach. McGraw-Hill, Inc., 3rd edition, 1992. 9] S. R. Schach. Software Engineering. Richard D. Irwin, Inc., and Aksen Associates, Inc., 1990. 10] S. R. Schach. Practical Software Engineering. Richard D. Irwin, Inc., and Aksen Associates, Inc., 1992. 11] M. Shaw and J.E. Tomayko. Models for Undergraduate Project Courses in Software Engineering. Technical Report CMU/SEI-91-TR-10, Software Engineering Institute, Carnegie Mellon University, August 1991. 12] I. Sommerville. Software Engineering. AddisonWesley, 4th edition, 1992. 13] E.N. Yourdon and L.L. Constantine. Structured Design. Yourdon Press, 1978.
