A Multidimensional Software Engineering Course

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

413

A Multidimensional Software Engineering Course Ohad Barzilay, Orit Hazzan, and Amiram Yehudai

Abstract—Software engineering (SE) is a multidimensional field that involves activities in various areas and disciplines, such as computer science, project management, and system engineering. Though modern SE curricula include designated courses that address these various subjects, an advanced summary course that synthesizes them is still missing. Such a course would enable young practitioners to get a comprehensive description of SE, to experience a genuine software development process, and to appreciate the relations and tradeoffs between the various domains of SE. This paper proposes a multidimensional SE course framework aimed at giving SE students just such comprehensive, cross-paradigm, practical, and theoretical experience and background. The course is organized along four axes: a) fundamentals of SE; b) practices and tools; c) productization; and d) technology evolution. Each of these axes, in themselves multifaceted, enables an examination of SE on various scales and from different perspectives; together they create a holistic multidimensional description of SE. The course is evaluated according to accepted criteria highlighting the course scope, pedagogic decisions, and relevance. The authors also describe their experience of teaching the course three times in the Tel Aviv University and the academic college of Tel-Aviv-Yaffo, Israel. Index Terms—Course design, course evaluation, educational axes, multidimensional domain, multidimensional software engineering course, software engineering, software engineering education.

I. INTRODUCTION OFTWARE engineering (SE) is a multidimensional field that involves activities in various areas and disciplines, such as computer science, project management, system architecture, human factors, and technological evolution. Several efforts have been made to map the different dimensions of SE and to design a proper curriculum that addresses them all [1], [2]. Accordingly, this domain diversity is often reflected in computer science (CS) and SE curricula, in which separate courses address the different topics. It is suggested that not enough effort has been made to place these topics in their wider context. Although the archival literature describes good course frameworks for specific SE topics, an advanced summary course that relates these topics to one other is still missing. Such a course is crucial for a young practitioner to understand that tradeoffs exist, not only within a domain (e.g., “technology A or technology B,” “development process

S

Manuscript received April 01, 2008; revised July 26, 2008. First published May 05, 2009; current version published August 05, 2009. O. Barzilay and A. Yehudai are with the Blavatnik School of Computer Science, Tel Aviv University, Tel-Aviv 69978, Israel (e-mail: [email protected]; [email protected]). O. Hazzan is with the Department of Education in Technology and Science, Technion—Israel Institute of Technology, Haifa 32000, Israel (e-mail: [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TE.2008.930094

X versus development process Y”), but also between domains (e.g., “how fast technology A can be mastered by a given team” or “how a specific software development process influences customer satisfaction”). To close this gap, at least partially, this paper describes an advanced multidimensional SE course framework that meets the challenges of SE education [3]. The course combines lectures, discussions and hands-on work, and provides SE students with a comprehensive, cross-paradigm, practical and theoretical experience and background in SE. The students build nontrivial software products, while maintaining a well-defined development process and considering a variety of human, architectural and technological alternatives. During this process, they experience requirement analysis, several product deliveries, customer communication and code maintenance. In order to encompass a wide range of topics in various dimensions, a four-axes mechanism is introduced. Each axis represents an educational objective related to SE, namely: a) fundamentals of SE; b) practices and tools; c) productization; and d) technology evolution. The axes mechanism assists the authors in building a varied and balanced syllabus and promotes an inter domain synergy, combining technology with methodology and theory with practice. This course may be taught as a summary course of CS and SE programs, after most of their topics have been taught in specific designated courses, giving the students the message that “The whole is greater than the sum of its parts.” By addressing the interaction between the different SE dimensions and their crosscutting nature, the course aims to promote students’ experience in multiple dimensions of software engineering, such as project management, product architecture, development processes, and working with cutting-edge technologies and tools. The work presented in this paper reflects the continuous evolution of the contextual, pedagogical, and organizational aspects of the course during three offerings of the course in the Tel Aviv University and the academic college of Tel-Aviv-Yaffo. The paper is organized as follows. Section II presents alternative strategies for building such an advanced SE course, as found in the literature. Section III presents the course overview, describing its learning objectives and pedagogical guidelines. In Section IV, the course syllabus according to its four axes is outlined. Section V describes the course evaluation based on conventional criteria presented in the literature. Section VI presents data gathered from each of the three times that the course was taught to CS and SE students. Section VII summarizes the paper. II. RELATED WORK Designing a SE advanced course is a “zero sum game.” Due to time and other resource limitations, educators are forced to prioritize the expected benefits of the course and to build a syllabus accordingly. Bernhart et al. suggest [4] evaluating SE courses by

0018-9359/$26.00 © 2009 IEEE

414

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

TABLE I DIMENSIONS OF VARIATIONS [4]

introductory programming courses and the software project and operating systems courses. Many students take the course after they have studied other elective courses relating to topics that are partly covered by this course, such as concurrency, databases, requirement analysis, and computer networks. This groundwork reduces the amount of new material being taught and enables the focus to be left on the crosscutting nature of various topics. A. Learning Objectives

positioning them on the axes of nine dimensions that express the pedagogic choices made by course instructors (see Table I). It is implied that with respect to most of the axes, the course focus tends towards one of the edges of the axes, which is indeed the case with many of the basic SE courses. The proposed multidimensional SE course presented in this paper, however, challenges this implication. For example, the course includes both processes and product deliverables, both business logic and technical API, and both initial development and software evolution. To serve as a comparison with the breadth of the course described here, several examples of SE courses that take an alternative, narrower approach are described below. Postema et al. [5] chose a maintenance perspective. They demonstrate how the four maintenance activities—corrective, adaptive, perfective and preventative—can be included in the practical component of a SE course, providing students with a realistic view of SE. Over the semester the students change, enhance, and debug a working preexisting software system whose code consists of approximately 2000 source lines of code. A similar approach is taken by [6]. Gnatz et al. take a project perspective [7]. They report on a SE project course in which 12 students built from scratch a software system of 10 500 lines of code, using nontrivial technologies and maintaining a methodological software process. The course does not include lectures, but about half of the students had already taken SE courses and had acquired useful methods for solving typical SE problems. Dubinsky and Hazzan focus on teaching software development methods [8] in a capstone project-based course, which also contains lectures in which Extreme Programming and project development processes are discussed. Each team of 10 to 12 students works on a specific operating system project throughout the semester; each team has its own studio, which is equipped with computers, tables, and white boards, and an academic coach who guides the development process. Most of the topics covered in the practices and tools axis of the advanced multidimensional course reported here are taken from [8]. As part of the preparation for the course described in this paper, its lecturer observed for one semester the course described in [8]. III. COURSE OVERVIEW The course described in this paper is offered to CS and SE students at Tel Aviv University as an advanced, elective course. As a prerequisite for this course, students are required to study the

The course’s goals are to: • expose students to the multidimensional nature of SE; • establish effective and manageable team work; • enhance students’ understanding of the rationale of building software tools and using certain technologies; • educate students for effective learning and for selflearning; • enable students to gain additional programming experience while addressing the different axes. These learning objectives are promoted in various ways, such as frequent reflective questionnaires, team meetings with the course instructor, development assignments, a written final exam, and a final feedback questionnaire on teaching quality and insights regarding SE elicited by the course. The programming assignments that accompany the course, as well as other course assignments, are tightly related to all of the course topics. B. Using Axes to Face the Challenges of an Advanced SE Course The nature and scope of the course might render it too eclectic due to its many topics, too low in level due to the many technological details, or too abstract if the choice is made to ignore technology altogether. In order to avoid these pitfalls, a set of four axes is introduced, two of which are methodological and two are more technical.1 The programming assignments, carried out in teams, tie together the various topics discussed in the course by integrating both technical and methodological aspects. The four axes of the course framework provide educators with a ready means of adapting the framework to their needs by adding, removing or changing individual modules, as long as the axis rationale is kept. In what follows, the four axes are briefly presented; in Section IV they are presented in detail. • Fundamentals of SE: This axis is a “meta-axis” which provides students with a comprehensive and broad picture of the nature of SE as a body of knowledge. Its topics widen and increase student awareness with respect to other SE topics and encourage critical thinking. • Practices and tools: This course axis aims at articulating the importance of a well-defined development process. Since this is the driving force of the actual teamwork that takes place as part of the course, the first two weeks of the course are dedicated almost entirely to process-related 1The term dimensions refers to the various fields of the SE domain, whereas the term axes refers to the educational perspective used by the course with respect to the domain dimensions. Though some of the axes might correspond to specific dimensions, axes could be multidimensional. Explicitly articulating the course axes assist the educator in the course design process to avoid the pitfalls mentioned above.

BARZILAY et al.: MULTIDIMENSIONAL SE COURSE

415

TABLE II COURSE STRUCTURE

practices and tools. The process used in the course is based on Extreme Programming practices; other educators may prefer a different set of practices. • Productization: This axis relates to characteristics and concerns that software systems should adopt as soon as they become a product. Deployment, security, configuration, and usability are such concerns. • Technology evolution: Real world applications are built using standard technology to handle concerns such as persistence, concurrency and networking. Although these topics are learned in other designated courses, their direct implication on software engineering is hardly discussed. Along this course axis these concerns are investigated from an SE perspective. C. Pedagogy 1) Teaching Technology in Advanced SE Course: The temptation to teach technology in advanced SE academic courses is a slippery slope. A mechanism must be established to avoid being drawn into technical details, thus losing sight of the broader picture. Different organizational and conceptual methods are used in the course for this purpose. First, the course is built along four axes (see Table II), two of which—fundamentals of SE and practices and tools—are less technical than the other two—productization and technology evolution. This structure enables the course to proceed without the students being swamped with technical details, and allows

the different topics to be addressed at a higher level of abstraction. Second, each week, both technical and nontechnical topics are discussed. Finally, although the productization and technology evolution axes are technical in nature (currently emphasizing Java technology and web programming), focus is placed on the role of the technology, leaving the technical details as pre- and post-lesson reading assignments for the students. 2) Assignments: Throughout the course, students are given five programming assignments. The first four assignments are performed in teams of six students over two or three weeks each. Teams are required to follow the development process discussed in class (in the past three semesters Extreme Programming [9] was used) and must hold at least one team meeting for each assignment, with the participation of the course instructor (see below). Programming assignments are evolutionary, in the spirit of the idea: “The experimental code of today is the legacy code of tomorrow.” Specifically, the application developed during the first three weeks is continually upgraded, changed, augmented, refactored, configured, ported to various platforms, and expanded to support concurrency, persistency, and networking in subsequent assignments. The fifth and final assignment is a collaborative effort of the entire class. The assignment is presented and described to the students in a one hour session in which the main tasks are assigned to teams and individuals, and team leaders and a project manager are chosen. One of the pedagogical goals of this assignment is to demonstrate to the students the amount and kind of administration required when more than one team is involved.

416

3) Team Meetings: Each team is required to hold a meeting for each assignment. The team is free to schedule the meetings at any time before the submission date, when there is still work to be done . As mentioned, the course instructor is present at the meetings, during which he or she “wears different hats.” First, the instructor serves as the meeting moderator, though the intention is to interfere as little as possible with team dynamics. Second, the instructor raises reflection questions from which he or she believes the team will benefit. Third, the instructor serves as the customer for the programming assignments, and the team uses these face-to-face meetings with the customer to report progress and to receive feedback. Fourth, during the meetings, the team can ask questions and consult with the instructor on different issues encountered during the work. 4) Versatile Learning: Since, due to rapid technological changes, courses and textbooks are not always available, a modern software engineer should be able to use various other sources of information effectively. Online tutorials, discussion groups, mailing lists, and web searches are some of the tools a software engineer must master in order to obtain the required information. For this purpose, software practitioners must acquire appropriate learning skills. Thus, learning to learn is one of the course’s explicit objectives (see Section III-A). Learning new technologies poses an additional challenge. As modern technologies are complex, learning them is a time-consuming task and the practitioner must adapt a selective, ad hoc learning method. Practitioners should be able to find their way around the system even if they do not master all of the languages used in the system, and to learn these languages to the extent of a general and more abstract comprehension. The course promotes versatile learning in several ways: • Learning by doing. Group assignments play a major role in helping students understand the relations and tradeoffs between the various dimensions. This approach conforms to the constructivism learning theory [10], which advocates active learning for meaningful knowledge construction. • Trial and error. When using third party code or an API, trial and error is an effective way to become familiar with the system, even without having mastery of all the languages used in the system. JavaScript and XML are examples of languages with which an experienced software engineer should not be afraid to “play.” • Learning in class. Class learning uses two strategies: Technology-intensive topics are taught in the lecture format, while the teaching of softer topics aims to promote class discussion and students’ active learning. For example, when Brooks’ texts [11], [12] are discussed, students are encouraged to share their views about alternatives in software team structure and management. • Learning from experience. Due to the large number of assignments, teams and individuals gain experience from one delivery to the next; this experience, in turn, allows them to tune their process and practices as the semester progresses. This learning approach is enhanced by frequent reflection questionnaires and team meetings that encourage postmortem processes on previous deliveries. • Online tutorials. Several online self-paced tutorials, offered by Sun Microsystems as part of the Sun Academic

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

Initiative2, are used. This initiative gives students free access to some of Sun’s online content and training. As well as making it unnecessary to cover technical details in class, so that students can complete homework assignments, learning from online tutorials also serves the self-learning course objective. The MySQL3 online tutorial is also used, to acquaint students with SQL. • Learning in teams. Team learning takes place both during pair programming sessions and during team meetings, held with and without the course instructor. • Learning among teams. Since each team implements a different part of the final project, some teams may not be exposed to certain technologies during their work. In such cases, one student teaches the rest of the class the said technology. IV. COURSE SYLLABUS In this section, the four axes (see Table II) are elaborated, and most of the topics addressed in the course are described. A. Fundamentals of SE This course axis aims at providing the students with a comprehensive picture of the nature of SE as a body of knowledge. 1) Classic Texts: During the semester, Brook’s two classic texts – No Silver Bullet: Essence and Accidents of Software Engineering [11] and The Mythical Man-Month [12]—are discussed in class. These two texts were chosen for several reasons. First, to demonstrate that not much has changed during the short history of SE. Second, these writings deliver the core course message that SE is not merely a technical and scientific domain, but involves additional aspects, such as human and managerial facets. Last but not least, discussions of these classic texts facilitate the establishment of a SE esprit de corps at a time when the field, established in 1968 [13], is turning 40 years old. Port and Klappholz [14] suggest a more active approach for the incorporation of The Mythical Man-Month into the classroom. This approach is planned to be adopted in future semesters, as well as introducing additional classic texts, such as Classics in software engineering edited by Yourdon [15]. 2) Standards for Software Development: Many SE standards exist, addressing almost all of its aspects. Standards are one means to define and enforce quality in software processes and products. In class, two such standards are discussed: ISO/IEC 90003:2004, which addresses the application of ISO 9001 – a quality management standard—to software, and IEEE/EIA 12207.0: Software Life Cycle Processes. The discussion goes beyond just investigating the specific standards themselves, but uses them to demonstrate the general notion that in order to comply with a given standard, it is not necessary to follow a specific method, but rather to follow some method and be able to demonstrate its quality. Such an approach typically requires effort by the entire organization, as well as significant management support. 2Sun Academic Initiative (June 2008): http://www.sun.com/solutions/landing/industry/education/sai/index.xml 3MySQL’s Website (June 2008): http://www.mysql.com/

BARZILAY et al.: MULTIDIMENSIONAL SE COURSE

3) Multidimensional Principles in SE: Meyer lists 13 principles of SE, most of which are multidimensional, such as abstraction, recursion, and exceptions [16]. Within the course framework, focus is placed on the principles of scale (also mentioned by Meyer), as well as consistency and redundancy, as is described in what follows. • Scale. Software does not scale well, which poses a fundamental problem. The growth in computation power was identified by Dijkstra to be the root cause of the “software crisis” [17]. From the course perspective, the scalability problem is indeed multifaceted, manifesting itself in the size of the code, in the number of personnel involved in the project, and in the amount of time required to complete a software project. • Consistency. Consistency is becoming crucial as software systems become larger. Again, consistency is a multifaceted notion: consistency considerations affect requirements, code, and design. • Redundancy. In the course, several SE aspects of redundancy are highlighted: • Code redundancy. Code redundancy is considered to be a bad thing, implying redundant work and future loss of consistency. Programming languages tackle redundancy by promoting code reuse, use of functions, module composition, inheritance and more. • Redundant activities. Redundancy occurs not only within a project, but also across several projects. Projects in the same domain usually involve reoccurring activities, such as configuration and deployment. Redundant activities are a primary motivation for the development of software tools and for the formulation of development frameworks. • System-level redundancy. This kind of redundancy is one of the main ways to enhance reliability. For example, the use of replicated servers eliminates the risk of a single point of failure. • Process-level redundancy. Such redundancy promotes business incentives. For example, by using seemingly redundant steps in the product lifecycle, the spiral model for software development enables a gradual and incremental refinement of design and implementation, based on early client feedback. 4) Classification of Software Systems: The characteristics of the software development method used, and of the software product itself, are derived mainly from the product’s target domain. For example, real-time programs differ significantly from enterprise administration systems. Another distinction is whether the developing company develops software for its own use or for an external client. Moreover, in some cases, the development company is not a software company at all, but perhaps a bank or an insurance company, developing their software in house. The development process in such a case differs from that employed by the R&D group of a software-specialized corporation. Furthermore, in some cases, business decisions affect the development process, the technology used, and even product architecture. In addition to the discussion about the categorization of software systems, and in order to emphasize the relevance of the course to the software industry, the course may include an in-

417

dustry invited talk. In the past year, a talk was given by a CEO of a hi-tech company, who described the business-driven software architecture used by his company and its implications. 5) Interaction Between SE Domains: Relationships between the various SE domains are not always explicit. Two illustrative examples of domain interactions discussed in class follow: • Interfaces: Programming languages—system design—human aspects. Interfaces are an example of the intersection between the programming language domain, the system design facet, and the human aspect. First, as a language construct, interfaces are naturally handled in the programming language domain; specifically, in order to use them properly, their compilation rules and runtime behavior should be specified. Second, interfaces serve as design elements that are language independent. Third, interfaces play a role in the human dimension of SE as contracts between developers; hence, system design reflects not only module interactions but also human interactions, such as the negotiation between developers about the services that a certain module should offer. • Automatic refactoring tool: Software lifecycle—programming practices—software architecture. An automatic refactoring tool not only allows the software engineer to write quick-and-dirty code, but also promotes incremental design, and changes the status of the design phase in the software lifecycle [18]. At the same time, refactoring has some shortcomings related to software architecture. Nord, Tomayko, and Wojcik present those shortcomings and investigate architecture-centric methods for addressing them [19]. In general, the interaction between SE domains is discussed with respect to topics related to different axes, for example, by addressing potential tradeoffs between alternatives. B. Practices and Tools This axis examines the way in which SE principles and concerns are reflected in agile software development, software tools, and training of software engineers. 1) Agile Practices: The agile approach comprises a family of development methods that focus on common values, principles, and practices involved in software development processes and environments. One prominent member of this family is the Extreme Programming (XP) method [9], which highlights five key values in software development, namely, feedback, simplicity, communication, courage, and respect, as well as a set of 14 principles such as quality, self-similarity, and reflection. Using the XP values and principles, the method founders came up with a set of 20 practices, such as weekly cycle, incremental design, and test-first. Agile software development in general, and XP in particular, are multidimensional. In the course, they are explored mainly with respect to software processes, human aspects, and architecture. The test-first practice, for example, provides an opportunity to discuss testing and program correctness. Furthermore, in order to emphasize the coupling between software practices and software tools, practices that are incorporated into software development tools, such as test-first in JUnit and incremental design using a refactoring tool in Eclipse, are highlighted.

418

In addition, following Dubinsky and Hazzan’s framework for teaching software development methods [8], XP practices are used as teamwork guidelines throughout the course. 2) Tools: Tools used by software practitioners are classified by comparing them and by investigating their respective purposes and advantages. Discussing some development activities from the perspective of tool usage helps students to understand the context of these activities and highlights the importance of good tool selection. Examples of discussion topics are: In what sense does a library or a framework serve as a tool as opposed to compilers? What differentiates a high-level programming language from a scripting language? How can a debugger assist in program comprehension? In what cases should programmers write their own tools? 3) Team and Individual Training: Software practitioners worldwide have heterogeneous backgrounds and training. This fundamental issue has started to attract the attention of SE practitioners and researchers in recent years. One of the class discussions addresses questions such as: What is the desirable training for a software practitioner? Which portion of the training should be carried out in the workplace? In this context, several training frameworks, such as old-time blacksmith apprenticeship and the more modern, law and medicine apprenticeships, are discussed in class. Another class discussion compares basketball team training with software team training. The basketball players’ skills, abilities, and training, and their contribution to the team’s success are identified. It is argued that individual training is not enough; even the most talented individuals cannot deliver if they meet for the first time only on the parquet floor at the beginning of the game. The analogy is clear: software development is performed by teams, not only by breaking down the task vertically, but also by horizontal collaboration. The basketball team analogy is further used to discuss software development metrics, which can be seen as analogues of team and individual statistics. C. Productization This course axis contains concepts that are related to the creation of a software product together with their various implications. 1) Distribution and Deployment: Though software distribution and deployment seem to be merely technical topics, they do influence program usability and popularity. To illustrate this point, after the students submitted their first assignment (a computer game), they are asked what is missing in their game that would enable their parents and grandparents to play it. This question starts a discussion about the importance of easy deployment and the barriers that stand between the software and its future users. Several technologies related to distribution and deployment, such as Java Applets and Web Start, and Eclipse-based technologies, are inspected. The students are also presented with examples of each, and examine the rationale behind the different alternatives and strategies adopted by the technology developer. Finally, trends in this area, manifested by technological evolutions, such as rich client development, server-side development, and web deployment, are identified. 2) Software Crosscutting Concerns: Software crosscutting concerns are program aspects that intersect with other concerns,

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

such as logging and persistency. These concerns often cannot be clearly separated from the rest of the system, in both design and implementation, and result either in program scattering or tangling, or in both [20]. Identifying such concerns and properly addressing them impact both software architecture and system modularity. Three strategies to cope with such concerns are presented in the course. First, an intermediate layer may be built to manage the relevant concerns. Second, some programming languages support crosscutting concerns as language constructs, e.g., the programming language AspectJ, which uses the aspect construct to address a crosscutting concern. A third option is using a framework that already takes care of these concerns, such as application servers. In the course, three illustrative cases of software-crosscutting concerns, involving interaction between technology and software architecture, are examined: networking and communication, persistency, and concurrency. 3) Configuration: Configuration is a multidimensional principle of SE. The term configuration is used to describe the ability to adapt a computer system, after it has been written, so that it conforms to different uses and platforms. In the course, software configuration is explored on various abstraction levels and magnitudes. First, different types of configuration and different strategies for their implementation are investigated. Second, automatic configuration and usability factors are discussed. Third, some of the dominant methods, tools, and technologies used for configuration are reviewed in various resolutions: the programming language level, scripting languages, and configurable software architectures. Fourth, versioning, software updates, and backward compatibility in the context of configuration are also discussed. An interesting challenge is posed by gigantic business software systems, such as Enterprise Resource Planning systems (ERPs). These systems attempt to integrate into a unified computer system all the data and processes of an organization. Companies that develop ERPs should configure their product to suit as many customers as possible. Some of the strategies used to accomplish this challenge (for example, customer configuration versus allocating programmers in the company) are presented and compared in the course. D. Technology Evolution Certain technologies are encountered several times over the course of the semester, each time in a different context, in order to impart the feeling that the course is not only theoretical, but also grounded in the software industry. Nevertheless, when technology is taught, code examples are used, but the technical details are left to the students as reading assignments. 1) Web Programming: In the course, the primary domain for investigating software tools and system architecture is web programming. Due to the huge industrial interest in web programming, it is fascinating to track how software tools and frameworks evolve and how architectural considerations are embedded in them. Many aspects of this, such as software configuration, installation, and distribution, are demonstrated in the course using common web development frameworks and technologies.

BARZILAY et al.: MULTIDIMENSIONAL SE COURSE

The rapid development of the area of web programming serves also to educate students into taking a judicious approach towards third party software. In contrast to compilers, databases, and operating systems, which enjoy a certain feeling of stability, the vast number of premature software tools in the web domain emphasizes the uncertainty of the underlying infrastructural technology and stresses the significance of proper tool choice. 2) Enabling Technologies: The term “enabling technology” suggests that the technology should be discussed in a wider SE context. That is, the technology enables (or contributes to) the development of a conceptual or methodological SE area, beyond the technical details related to the said technology. Two enabling technologies are discussed in the course: Eclipse and XML. Eclipse: Eclipse is an open-source software framework written primarily in Java. Users can extend its capabilities by installing plug-ins written for the Eclipse software framework and can write and contribute their own plug-in modules. Throughout the course, Eclipse technology is encountered in the following contexts (some of which overlap): • User interface. Eclipse is built using the Standard Widget Toolkit (SWT) graphical user interface (GUI) library. • Software tools. Eclipse is a configurable and extendable integrated development environment, used both to develop new tools and to embed and integrate existing tools. • Deployment and integration. Eclipse plug-in technology and the Eclipse Rich Client Platform (RCP) offer a deployment mechanism for newly built applications. They address many concerns related to resource management, GUI, configuration, deployment, and integration. XML: The Extensible Markup Language (XML) is a general-purpose markup language. Throughout the course, XML technology is encountered in the following contexts: • Standards and interoperability. Being a simple and widely accepted standard, XML technology has become a common underlying syntax for many tools, languages, standards, and communication protocols. • Configuration management. XML technology serves both as the de-facto standard for configuration files and as an enabling technology for the Ant configuration tool. • System integration and architecture. XML-based web services are the building blocks of the Service-Oriented Architecture (SOA) approach. • Dynamic web programming. XML serves as an enabling technology for dynamic client-side web programming using asynchronous JavaScript and XML (AJAX). • Data abstraction. Data abstraction is achieved by defining classes in XML (instead of Java), and using XML-based databases. XML is also one of the means used to create a semantic web in which software systems can “understand” other software systems. 3) Networking and Communication: The syllabi of many universities include computer networks courses, which typically focus on the underlying protocols but usually do not touch on

419

SE issues. In the course presented here, the discussion of networking and communication concentrates on the topic in terms of system crosscutting concerns. For example, the pros and cons of working with standard protocols and the tradeoffs between client-side and server-side programming are examined. Also modern web frameworks and scripting languages that tackle the shortcomings of the standard HTTP protocol (such as simplistic graphics and poor interactivity) are examined. 4) Persistency: Persistency is also a system crosscutting concern. Though programmers can achieve persistency by using simple file writing, the general case involves complicated issues, such as allowing concurrent access, working with huge amounts of data, disaster recovery, transactional support, heterogeneous clients, and more. The relational database, which uses a standard SQL dialect, is the most dominant solution for persistency. Relational databases are based on firm theoretical foundations, established thanks to extensive academic and industrial research aimed at ensuring their correctness and reliability. Using relational databases, however, has some SE-related shortcomings, two of which are presented here. First, database access is still scattered and tangled with the system code, and more importantly, relational schema cannot express object relations in complex object-oriented domain models. Several ways for overcoming these shortcomings are discussed in the course, including: 1) abandoning SQL and using Java’s built-in persistence mechanism 2); using application frameworks in which persistency is automatically handled; and 3) using an object-oriented database system. The pros and cons of these alternatives are presented and cases in which their use might be appropriate are examined. Among the various considerations, the following are addressed: application size, complexity, technology maturity, the learning curve, and performance overhead. Thus, this application serves as an interesting test case for technology evolution and evaluation. 5) Concurrency: Concurrency issues affect software architecture and may crosscut entire systems. The course discusses how concurrency can be achieved by using multiple processes and multiple threads, and situations in which the use of multiple threads or multiple processes pay-offs are examined. Concurrency is also used to examine code reuse. It is shown that a software module in which concurrency issues are handled explicitly (thread creation or scheduling) cannot be reused in a single-threaded system, and Java language constructs that assist in overcoming this obstacle are presented. Discussions also cover standard frameworks, such as J2EE web containers, in which concurrency issues are handled behind the scenes, and which can be configured using XML configuration files.

V. THEORETICAL COURSE EVALUATION The presented course is evaluated by standard and accepted criteria. This evaluation addresses the pedagogy expressed in the course, the course scope, and its relevance. For these ends we, use dimensions of variations [4], knowledge areas [1], and software education challenges [3] (presented in Sections V-A–C, respectively).

420

Fig. 1. Dimensions of variations as manifested in the proposed course (reflected in the dark edges of the axes).

A. Dimensions of Variations In this section, the course is evaluated based on [4], which suggests evaluating SE courses by positioning them on nine axes that express the pedagogical choices made by course instructors (see Table I). Based on the graphical representation suggested in [4], Fig. 1 reflects the positioning of the course along the nine dimensions. As can be seen, the suggested multidimensional course covers both extremities of most of the dimensions. Moreover, it is argued that the axes’ edges which are not included in the suggested multidimensional course, such as full topics coverage, working by multiple process models and individual manual-based work, do not actually represent genuine industrial software development settings; they do, however, represent genuine educational considerations. In what follows, this graphical image and the choices made with respect to each dimension are explained. Discipline focus: Full versus partial coverage of topics. Since the aim of the course is to enable the students to gain a theoretical and practical comprehensive picture of SE, many topics are addressed only partially. For example, though software lifecycle is addressed, only several activities are addressed in depth. The variety of areas, however, allows a concentration on the interconnections between the different SE aspects. Assignment focus: Independent exercises versus projects. A series of programming exercises is given to the students, some of which are based on previous exercises. All the assignments include a full software development cycle using XP (including delivery), as opposed to assignments that require only analysis or design documents. This approach achieves two goals: first, it emphasizes the spirit of XP as a multifaceted development method; second, it delivers the message that code delivery must include software deployment. As a final assignment, the students are given a project submitted jointly by the entire class, which illustrates the strong interdependency between the individuals and the teams.

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

Development focus: Initial development versus maintenance and evolution. The series of programming exercises balances maintenance and development bootstrapping. Maintenance is achieved by requirement changes, both within the business domain and within the enabling technologies used to implement the system; exercises in a similar domain (in this case, games) allow the students to experience development bootstrapping as well and to improve their understanding of this aspect from one assignment to the next. Further, evolutionary exercises allow the students to gain intuitions about the tradeoffs between design generality and development speed. Process model: Single in-depth versus overview of many. As XP is a multidimensional development process, the choice to concentrate on XP is highly compatible with the general integrative spirit of the course. Thus, this choice supports both the desire to discuss other SE aspects (especially, human aspects), which are clearly reflected in XP development environments, and the decision that all the assignments include code delivery. Deliverables: Process versus product focus. Students are graded both on their final product and on a systematical application of the process. Grading is, however, biased towards the product, in that a perfect product is always given a perfect grade. Yet, as in real life, there is no such thing as a perfect product: requirements are always overly ambitious and time is always short. Organization: Team versus individual. As in the real world, in which software development processes are performed in teams, the students in the course work in teams and for each team, all team members are given the same grade. It is easy to spot “hitchhikers” thanks to the meetings with the course instructor, in which each student describes his or her work. Although hitchhiking has not been found to be a problem, it nevertheless reflects a genuine situation from the real world and, if it does occur, can serve as an opportunity to discuss with the students possible reactions to such situations. Alternatives for forming and rewarding student teams are elaborated in [8], [21], and [22]. Technology focus: Universal versus specific. The choice of web programming using Java technology is both universal and specific. The choice is specific because it focuses on Java-related technologies and ignores competing technologies related to C# or C++; it is universal in that Java promotes open-standards technology and is not vendor-specific. Tools: Manual based work versus tool support. The preferred choice is tool support; web programming using Java technology is almost impossible otherwise. Moreover, one of the course objectives is to encourage students to explore, experiment, and evaluate software tools and technologies. Nevertheless, a hands-on approach is important in more basic courses to increase students’ awareness of what goes on “under the hood.” Exercise domain: Administrative software versus technical software. The software developed during the course is both administrative and technical. Most of the course assignments implement well-known games together with

BARZILAY et al.: MULTIDIMENSIONAL SE COURSE

TABLE III KNOWLEDGE AREAS AND UNITS OF SEEK [1]

421

as professionalism and ethics, which naturally suits the course’s spirit and orientation, has not been appreciated when the course was first designed and they will be included in future courses. • Lack of time. For example, topics related to verification and validation could be appropriate for the proposed course framework had more time been available. C. Software Education Challenges

their logic, while their configuration, deployment, and presentation aspects are highly technical. B. Knowledge Areas This multidimensional SE course serves also as an integrative, concluding course for the entire SE syllabus. The evaluation of the course framework can, therefore, be made according to the knowledge areas of SE. Since SE2004 [1] is a widely accepted description of what needs to be taught in an undergraduate SE program, its ten knowledge areas are used to examine the domain coverage of our course. Table III shows which of the knowledge areas and units are addressed in the proposed course. It is based on [1, Ch. 4], in which all topics and units included in each knowledge area are listed. A knowledge unit is marked as explicitly addressed in the course only if most of its topics are discussed as part of the course syllabus. However, since the aim of the course is to provide a multidimensional perspective on SE, it is not purported to replace any of the designated courses in the various knowledge areas or claim full domain coverage. Some knowledge areas and units are not addressed in the course for the following reasons: • Outside the course scope. For example, computer science topics are too basic; general modeling and notations are too theoretical for the course. • Topics originally excluded, but to be incorporated in future offerings. The importance of some topics, such

Lethbridge et al. [3] discuss eight challenges on which they believe “efforts should be focused in the future so as to improve not only the quality of SE education, but also the quality of the workforce, and, consequently, the quality of software developed.” In this section, those challenges related to SE academic training are discussed in the context of the suggested course framework and the way in which these challenges are achieved is shown. • Making programs attractive so as to appeal to good students and to meet societal demand. This challenge is achieved in the course thanks to the domain selection and the emphasis on the agile approach. Discussing and using cutting-edge technology and tools, though not an explicit objective of the course, are very appealing to many students; the absence of modern technology from the curriculum is often used to portray the academy as irrelevant to the software industry. The emphasis on the agile approach in general, and on XP in particular is used, among other reasons, to dispel some of the stereotypical image of SE as being “geeky” and unsocial. • Focusing education appropriately. Lethbridge et al. [3] advocate the movement to “diversify” computing education by including SE specialties. They state that student understanding of the field dimensions is a primary tool to achieve that goal. This is also the primary goal of the course framework presented in this paper. • Communicating real-world industrial practices to students more effectively. Industrial practices are addressed in the course in three ways. First, process and productization dimensions are presented as an integral part of software construction; specifically, homework assignments are carried out in teams, which are required to follow a welldefined process, and deliverables are judged also based on their configuration management and deployment. Second, class discussions, mainly on topics related to practices and fundamentals, attempt to confront theory and practice. In this spirit, since most of the course students are seniors and many of them work in the industry in student positions, assertions such as: “but no one works like this” or “this could never work in the real world” are heard from time to time during the discussions. Third, the industry’s voice is communicated in various ways through invited talks, mailing lists, and new books reviews. • Defining forward-looking curriculum standards. The choice to teach technology evolution and evaluation addresses precisely this issue. By emphasizing the rationale instead of the solution, deeper understanding of the role of software tools and technology in SE is enhanced. In the future, when the students identify new concerns they have

422

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

TABLE IV DROP OUT NUMBERS AFTER THE FIRST TWO WEEKS

never encountered before, it is hoped that they will be able to extrapolate their needs based on their understanding of technology evolution. • Making SE education evidence-based. Though industrial data is not used in the course, students justify their actions using metrics taken over the course of the semester. Each team is required to track three significant and informative metrics, and, based on the metrics analysis, explain the changes that occur from one week to the next. In addition, each student is required to answer a reflection question posted on the course website on an iterative basis and to state one lesson learned from the iteration. On subsequent iterations, students are asked to explain how they implemented these lessons. VI. EMPIRICAL COURSE EVALUATION The course is offered as an elective advanced course for thirdyear students both in Tel Aviv University (TAU) (taught twice as the time of writing) and at the academic college of Tel-AvivYaffo (MTA) (taught once as the time of writing). Student feedback is collected during the course in various forms. In what follows, only preliminary data is presented. Further data will be presented in future publications. A. Course Workload As can be seen in Table IV, the drop out rate of students during the first two weeks of the semester was high, probably because students did not realize the extent of the course workload before the first meeting. During the semester, when students complained about the heavy workload, they were encouraged to negotiate the task scope, never to negotiate time and quality (in the spirit of XP [9]), and to support the negotiation with data. This negotiation is made during the team meeting with the instructor, in which the students present their time estimation for the next iteration based on their progress so far; then, the tasks for the next iteration are selected and prioritized to match the expected team productivity [9]. In the three course offerings so far, the students developed computer games. Each team implemented two games and also took part in the class final project (a wedding portal). While lines of code (LOCs) do not necessarily reflect the complexity of software products, in order to reflect the amount of work required in the course, Table V shows the size of Java code involved in the programming assignments over one semester. In some cases, the LOC metric includes also comments and unit tests, hence the number of actual LOCs is about half of that size. On the other hand, the statistics do not include configuration files (xml), scripting languages (JavaScript), and other forms of code besides Java source code. The course poses challenges for instructors as well:

TABLE V ILLUSTRATION OF ASSIGNMENT SIZES (SPRING 2007, TAU)

• Preparing the course. Due to the diversity of the course’s topics and its unique perspective, it is not a single textbook course. Therefore, the lecturer is required to learn, collect, and adjust the course material. • During the semester. Team meetings are time consuming (one hour per team every two weeks). In addition, the departmental technical support team should take care of the development environments in the computer labs, since some of the technologies and tools involved may not have been installed or configured beforehand. • Between semesters. Due to the technical nature of some of the course axes, the instructor is required to be attentive to new trends and update the course material accordingly. B. Reflection Questionnaires Reflection questions, which students are asked to answer after submitting each assignment, are a significant source of student feedback. Usually, one or two open-ended questions regarding insights they learned from their work on the assignment are presented. During the consequent team meeting, the raised issues are revisited in order to check whether the students learned from their experience. Examination of the issues raised by the students in the reflection questionnaires reflects that these concern various aspects of software development such as human factors, learning curve, time management, and technology limitations. The variety expressed in students’ answers supports the course objective and demonstrates the students’ awareness to various aspects of SE. C. Student Perceptions Another source of data is an anonymous feedback survey handled at the end of the spring 2007 semester at TAU (see Table VI). From the free text comments written at the end of the form, it is apparent that most students find this course interesting, relevant and important. All students mentioned the contribution of the programming assignments to their learning processes, though some of them indicated that the workload of the course was heavy and that they found the timetable stressful. One student specifically mentioned that “splitting the lecture into two parts was correct from a technological perspective.” Another student wrote: “…lots of time was spent during the assignments on organizational and coordination instead of learning and doing the assignments itself. It would have been much more effective to work in teams of 2–3 students. I learned nothing from working in large teams…” This comment actually

BARZILAY et al.: MULTIDIMENSIONAL SE COURSE

423

TABLE VI FEEDBACK SUMMARY (SPRING 2007, TAU)

indicates that the student indeed experienced the organizational and coordination challenges posed by working in large teams.

VII. SUMMARY This paper proposes a multidimensional SE course framework, aimed at providing students with a comprehensive crossparadigm, practical, and theoretical experience. The course investigates the relations between the various SE dimensions, examines fundamental field principles from different aspects, and explores software evolution and trends from various perspectives. The course is still under development. Though students’ feedback is positive, the plan is to improve the course, using the instructors’ cumulative experience and an open dialogue with the SE educational and professional communities. It is hoped that this paper will contribute to a fruitful and constructive discussion on the proposed course framework and will inspire other educators to adopt the framework by implementing similar courses. Moreover, the authors believe that the above key ideas may be also useful for educators in other engineering domains than SE, who wish to design a multidimensional course framework in their own field. Some of these key ideas are: identifying the domain dimensions, choosing educational axes, establishing a mechanism to balance the various axes, and stating explicit learning objectives and monitoring their accomplishment.

REFERENCES [1] “Software Engineering 2004 (SE2004): Curriculum guidelines for undergraduate degree programs in software engineering,” 2008 [Online]. Available: http://sites.computer.org/ccse/ [2] “Software engineering body of knowledge,” 2008 [Online]. Available: http://www.swebok.org/index.html [3] T. C. Lethbridge, J. D. Diaz-Herrera, R. J. J. LeBlanc, and J. B. Thompson, “Improving software practice through education: Challenges and future trends,” in FOSE ’07: 2007 Future of Software Eng.. Washington, DC: IEEE Computer Soc., 2007, pp. 12–28. [4] M. Bernhart, T. Grechenig, J. Hetzl, and W. Zuser, “Dimensions of software engineering course design,” in Proc. 28th Int. Conf. Software Eng., 2006, pp. 667–672. [5] M. Postema, J. Miller, and M. Dick, “Including practical software evolution in soft. eng. Education,” in Proc. 14th Conf. Software Eng. Educ. Training, 2001, pp. 127–135. [6] J. Buchta, M. Petrenko, D. Poshyvanyk, and V. Rajlich, “Teaching evolution of open-source projects in software engineering courses,” in Proc. 22nd IEEE Int. Conf. Software Maint., Washington, DC, 2006, pp. 136–144. [7] M. Gnatz, L. Kof, F. Prilmeier, and T. Seifert, “A practical approach of teaching software engineering,” in Proc. 16th Conf. Software Eng. Educ. Training (CSEET), Washington, DC, 2003, pp. 120–120. [8] Y. Dubinsky and O. Hazzan, “A framework for teaching software development methods,” Comput. Sci. Educ., vol. 15, no. 4, pp. 275–296, 2005. [9] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed. Reading, MA: Addison-Wesley Professional, 2005. [10] S. Hadjerrouit, “Constructivism as guiding philosophy for software engineering education,” SIGCSE Bullet., vol. 37, no. 4, pp. 45–49, 2005. [11] J. F. P. Brooks, “No silver bullet: Essence and accidents of software engineering,” Computer, vol. 20, pp. 10–19, 1987. [12] J. F. P. Brooks, The Mythical Man-Month (Anniversary Ed.). Reading, MA: Addison-Wesley Longman, 1995. [13] B. Randell, “Software engineering in 1968,” in Proc. 4th Int. Conf. Software Eng., 1979, pp. 1–10.

424

IEEE TRANSACTIONS ON EDUCATION, VOL. 52, NO. 3, AUGUST 2009

[14] D. Port and D. Klappholz, “So you want Brooks in your classroom?,” in Proc. ICSE ’06: Proc. 28th Int. Conf. Software Eng., New York, 2006, pp. 655–660. [15] E. N. Yourdon, Classics in Software Engineering. Upper Saddle River, NJ: Yourdon, 1979. [16] B. Meyer, “Software engineering in the academy,” Computer, vol. 34, no. 5, pp. 28–35, 2001. [17] E. W. Dijkstra, “The humble programmer,” Commun. ACM, vol. 15, no. 10, pp. 859–866, 1972. [18] M. Fowler, Refactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 2000. [19] R. L. Nord, J. E. Tomayko, and R. Wojcik, “Integrating software-architecture-centric methods into extreme programming,” 2004, Tech. Rep., CMU/SEI-2004-TN-036. [20] R. Laddad, “I want my AOP! Separate software concerns with aspect-oriented programming,” 2002 [Online]. Available: http://www. javaworld.com [21] J. E. Tomayko and O. Hazzan, Human Aspects of Software Engineering. New York: Charles River Media, 2004. [22] J. H. Hayes, T. C. Lethbridge, and D. Port, “Evaluating individual contribution toward group software engineering projects,” in Proc. 25th Int. Conf. Software Eng., Portland, OR, 2003, pp. 622–627. Ohad Barzilay received the B.Sc. degree in computer science and mathematics and the M.Sc. degree in computer science from the Tel Aviv University, Israel, in 2000 and 2004, respectively. He is working toward the Ph.D. degree in computer science at Tel Aviv University. His research interests include empirical methods in software engineering research, programming languages, tools and frameworks, agile development, and “real world” software engineering education. His professional experience includes working as a Software Engineer at several software companies, teaching Computer Science and Software Engineering courses in five academic institutes, training in various industrial companies, and teaching mathematics in private schools.

Orit Hazzan received the B.Sc., M.Sc., and Ph.D. degrees from the Department of Education in Technology and Science, Technion—Israel Institute of Technology, Haifa, and the MBA from the Department of Industrial Engineering, Technion, in 1989, 1991, 1995, and 2000, respectively. Currently, she is an Associate Professor with the Department of Education in Technology and Science of the Technion. Her main research topics are Computer Science and Software Engineering education and human aspects of Software Engineering. Her professional experience is summarized in approximately 50 research articles published in refereed professional journals and her two books: Human Aspects of Software Engineering (coauthored with J. Tomayko, 2004) and Agile Software Engineering (coauthored with Y. Dubinsky, New York: Springer, October 2008).

Amiram Yehudai received the B.Sc. degree in electrical engineering from the Technion, Israel Institute of Technology, Haifa, in 1973, and the M.Sc. and Ph.D. degrees in computer science from the University of California, Berkeley, in 1974 and 1977, respectively. He is currently a Professor with the School of Computer Science, Tel Aviv University, Israel, which he joined in 1977. He held visiting positions with the University of California at Berkeley and Los Angeles, with the University of Maryland, College Park, with GMD, Germany, and with the US Naval Postgraduate School. He was Vice President for Academic Affairs and Head of the Computer Science Program in the Academic College of Tel-Aviv-Yaffo from 2000 to l 2003. His main research areas are Software Engineering and Programming Languages. His work has been funded by grants from the Israel Academy of Sciences, the German-Israel Fund, the Israeli Ministry of Sciences, and the Israeli Ministry of Defense.