Catálogo de publicaciones - libros

The “engineering” focus in software engineering education leaves instructors vulnerable to several traps. It also misleads students as to SE’s essential human and social dimensions. In this paper we argue that there’s more to SE than engineering. A major challenge is to reconcile the engineering dimension with the human and social dimension.

This paper is a collection of reflections on some of the curricular decisions made in “Software Engineering 2004,” the Software Engineering volume of the Computing Curricula 2001 project. We briefly describe the contents of the Volume and the process used in developing the Volume’s guidelines. We then look in more detail at the rationale behind some of the more controversial decisions made. We conclude with how we expect the Volume to be used in practice.

Software has jumped “out of the box” – it controls critical systems, pervades business and commerce, and infuses entertainment, communication, and other everyday activities. These applications are constrained not only by traditional capability and performance considerations but also by economic, business, market and policy issues and the context of intended use. The diver sity of applications requires adaptability in responding to client needs, and the diversity of clients and contexts requires the ability to discriminate among crite ria for success. As a result, software designers must also get out of their boxes: in addition to mastering classical software development skills, they must master the contextual issues that discriminate good solutions from merely competent ones. Current software engineering education, however, remains largely “in the box”: it neglects the rich fabric of issues that lie between the client’s problem and actual software development. At Carnegie Mellon we address this major shortcoming by teaching students to understand both the capabilities required by the client and the constraints imposed by the client’s context.

Software modeling plays an important role in software engineering education. There are a variety of modeling techniques; some are intuitive and quite accessible to novices, while some are highly sophisticated and attract theory oriented students and researchers. Thus, educators have freedom in selecting appropriate models in accordance with the level and the disposition of students.

In this chapter, we show that teaching multiple software modeling techniques from a unified viewpoint is a good way of obtaining balance between the scientific aspect and the practical aspect of software engineering education. At the same time, it is pedagogical to let students notice the difference between different models. Some models, particularly when illustrated as diagrams, look quite similar but such similarity is often misleading. It is emphasized in this chapter that explicitly teaching differences between models is also very important.

Successful software engineering requires experience and acknowledgment of complexity, including that which leads designers to recognize ambiguity within the software design description itself. We report on a study of 21 post-secondary institutions from the USA, UK, Sweden, and New Zealand. First competency and graduating students as well as educators were asked to perform a software design task. We found that graduating seniors were more likely to recognize ambiguities in under-specified problems than first competency students. Additionally, participants who addressed all requirements in the design were more likely than others to recognize ambiguities in the design specification. The behavior of recognizing ambiguity and gathering information appear to be independent of past performance, as measured by course grades.

Teaching students to read and write specifications is difficult. It is even more difficult to motivate specifications — to convince students of the value of specifications and make students eager to use them. The Groupthink specification exercise aims to fulfill all these goals. Groupthink is a fun group activity, in the style of a game show, that teaches students about teamwork, communication, and specifications. This exercise teaches students how difficult it is to write an effective specification (determining what needs to be specified, making the choices, and capturing those choices), techniques for getting them right, and criteria for evaluating them. It also gives students practice in doing so, in a fun environment that is conducive to learning. Specifications are used not as an end in themselves, but as a means to solving realistic problems that involve understanding system behavior.

Students enjoy the activity, and it improves their ability to read and write specifications. The two-hour, low-prep activity is self-contained, scales from classes of ten to hundreds of students, and can be split into 2 one-hour sessions or integrated into an existing curriculum. It is freely available from the author (mernst@csail.mit.edu), complete with lecture slides, handouts, a scoring spreadsheet, and optional software. Instructors outside MIT have successfully used the materials.

Software engineering is foremost an engineering discipline. Engineering in general and software engineering specifically has to balance many factors to achieve viable tradeoffs–an understanding of the factors as well as the viability criteria is at the heart of the educational challenge. All engineering has one ultimate goal: the delivery of artifacts (products, commercial or not) that meet the needs of those using such artifacts. All engineering lives in the intersection of people, technology, domain, and opportunity aspects. Software engineering, however, is laden with its own specific difficulties. Software as an engineering medium fills a space between the fluidity of digital content, with which software shares the representation, and the nature of machines, with which software shares the flexible and repeatable application. This brief article covers some of the author’s personal observations and suggestions with a hope to inspire (and provoke) those striving to improve software-engineering education.

We discuss the technical skills that a software engineer should possess. We take the viewpoint of a school of engineering and put the software engineer’s education in the wider context of engineering education. We stress both the common aspects that crosscut all engineering fields and the specific issues that pertain to software engineering. We believe that even in a continuously evolving field like software, education should provide strong and stable foundations based on mathematics and science, emphasize the engineering principles, and recognize the stable and long-lasting design concepts. Even though the more mundane technological solutions cannot be ignored, the students should be equipped with skills that allow them to understand and master the evolution of technology.

K.3.2 []

We present our experience made in the course “Information Systems Development” which is entirely taught online at the Virtual Global University (VGU). We identify current technical, economic, and pedagogical problems as well as challenges in online education, which are of interest to educators teaching software engineering online. We argue that despite the existing standards in the area of online learning, the reuse concepts of educational content are still immature, especially with respect to a reuse strategy. Building upon our own experience, we therefore present a proactive strategy to develop and reuse educational content, which is based on concepts that come from the area of software product lines.

Over the past decade, it has been established that a good education in software engineering requires a specialized program of study different from traditional computer science programs. What should constitute such a specialized program of study, however, is still a matter of debate. Here we bring to this debate a new perspective that describes how we believe software engineering education should be framed, namely through the in which software eventually is placed. That is, we must study software information, development design, technical social issues, synthesis analysis. At UC Irvine, we have designed and now offer a program of study that provides this focus – a four-year B.S. degree in Informatics. In this paper, we present our view of software engineering education, the principles underlying our Informatics curriculum, an overview of the curriculum itself and its pedagogy, some reflections on our experiences to date, and a concluding list of challenges that our approach addresses and that are critical for any approach to software engineering education.