Janet E. Burge

Using the inverted classroom to teach software engineering

An inverted classroom is a teaching environment that mixes the use of technology with hands-on activities. In an inverted classroom, typical in-class lecture time is replaced with laboratory and in-class activities. Outside class time, lectures are delivered over some other medium such as video on-demand. In a three credit hour course for instance, contact hours are spent having students actively engaged in learning activities. Outside of class, students are focused on viewing 3-6 hours of lectures per week. Additional time outside of class is spent completing learning activities. In this paper we present the inverted classroom model in the context of a software engineering curriculum. The paper motivates the use of the inverted classroom and suggests how different courses from the Software Engineering 2004 Model Curriculum Volume can incorporate the use of the inverted classroom. In addition, we present the results of a pilot course that utilized the inverted classroom model at Miami University and describe courses that are currently in process of piloting its use.

Rationale-Based Software Engineering

Many decisions are required throughout the software development process. These decisions, and to some extent the decision-making process itself, can best be documented as the rationale for the system, which will reveal not only what was done during development but the reasons behind the choices made and alternatives considered and rejected. This information becomes increasingly critical as software development becomes more distributed and encompasses the corporate knowledge both used and refined during the development process. The capture of rationale helps to ensure that decisions are well thought out and justified and the use of rationale can help avoid the mistakes of the past during both the development of the current system and when software products (architecture and design, as well as code) are reused in future systems. Burge, Carroll, McCall, and Mistrk describe in detail the capture and use of design rationale in software engineering to improve the quality of software. Their book is the firs t comprehensive and unified treatment of rationale usage in software engineering. It provides a consistent conceptual framework and a unified terminology for comparing, contrasting and combining the myriad approaches to rationale in software engineering. It is both an excellent introductory text for those new to the field and a uniquely valuable reference for experienced rationale researchers. The book covers the use of rationale for decision making throughout the software lifecycle, starting from the first decisions in a project and continuing through requirements definition, design, implementation, testing, maintenance, redesign and reuse.

Reasoning with Design Rationale

Design Rationale (DR) consists of the decisions made during the design process and the reasons behind them. Because it offers more than just a “snapshot” of the final design decisions, DR is invaluable as an aid for revising, maintaining, documenting, evaluating, and learning the design. Much work has been performed on how DR can be captured and represented but not as much on how it can be used. In this paper, we investigate the use of DR by building InfoRat, a system that inferences over a design’s rationale in order to detect inconsistencies and to assess the impact of changes.

AN INTEGRATED APPROACH FOR SOFTWARE DESIGN CHECKING USING DESIGN RATIONALE

Design Rationale (DR), the reasons behind decisions made while designing, offers a richer view of both the product and the decision-making process by providing the designer’s intent behind the decisions. DR is also valuable for checking to ensure that the intent was adhered to throughout the design, as well as pointing out any unresolved (or undocumented) issues that remain open. While there is little doubt of the value of DR, it is typically not captured during design. SEURAT (Software Engineering Using RATionale) is a system we have developed to explore uses of design rationale. It supports both the display of and inferencing over the rationale to point out any unresolved issues or inconsistencies. SEURAT is tightly integrated with a software development environment so that rationale capture and use can become integrated into the software development process.

Design rationale: Researching under uncertainty

Abstract Rationale research in software development is a challenging area because although there is no shortage of advocates for its value, there is also no shortage of reasons for why rationale is unlikely to be captured in practice. Despite more than 30 years of research there still remains much uncertainty: how useful are the potential benefits and how insurmountable are the barriers? Will the value of the rationale (design and otherwise) justify the cost of collecting it? Although there have been numerous rationale research projects, many, if not most, received little or no empirical evaluation. There also have not been many studies examining what the needs are of the practitioners who would be supported by the rationale. This article discusses the “doom and gloom” predictions of rationales failure, provides a survey of evaluations of rationale systems, and discusses what we hope is a brighter outlook for rationale research in the future. There are development standards and synergistic research areas that may help with rationale research and its acceptance in the software community with which we should be working. This article also presents the results of a pilot survey of software developers who were asked how they would envision using rationale and what they believe the most important barriers are. Although some results were as expected, there were also some surprises. Research on technology transfer indicates that, among other things, to transition successfully from research into practice we need to understand the need that is being met and demonstrate the value of our approach. Until we have determined how our work is needed by the people we are trying to help we will remain researching under uncertainty.

SEURAT: integrated rationale management

A completed software product is the end result of many decisions that must be made throughout the development lifecycle. Unfortunately, the rationale for these decisions is usually not captured and is therefore lost. The Software Using RATionale (SEURAT) system integrates with the Eclipse Interactive Development Environment to support rationale capture and use. In addition to presenting the rationale to the developer/maintainer as needed, SEURAT also supports requirements traceability and impact assessment.

Communication genres: Integrating communication into the software engineering curriculum

One way to improve the communication abilities of new software engineering graduates in the workplace is to integrate communication more effectively in the software engineering curriculum. But faculty typically conceive of communication as outside their realm of expertise. Based on the results of an NSF-funded project, we use theories of situated learning and genre to make the case that communication is integral to software engineering and that faculty are in the best position to guide students in becoming better communicators in the field. We identify software engineering genres and show how those genres may be used to integrate communication in the classroom and throughout the curriculum.

Using rationale to support pattern-based architectural design

Architectural design rationale describes the decisions made, alternatives considered, and reasons for and against each alternative considered when defining a software architecture. At least some of these reasons should reference the non-functional requirements (NFRs) for the system. The SEURAT_Architecture system uses a pre-defined pattern library and the NFRs for a software system to guide the selection of architectural patterns. Each pattern recommended by the system serves as an alternative to the architectural decision made and comes with rationale for why this pattern is considered useful. This system serves several purposes---to guide the architect through the decision-making process, to ensure that NFRs are considered when making these critical early decisions, and to capture the rationale for the architecture as a byproduct of the tool-supported selection process.

Views on software engineering from the twin peaks of requirements and architecture

The disciplines of requirements engineering (RE) and software architecture (SA) are fundamental to the success of software projects. Even though RE and SA are often considered in isolation, drawing a line between RE and SA is neither feasible nor reasonable as requirements and architectural design impact each other. This observation motivated the Twin Peaks model that was the subject of the Second International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks@ICSE 2013). TwinPeaks@ICSE 2013 was held in conjunction with the 35th International Conference on Software Engineering 2013 in San Francisco, CA. The workshop aimed at providing a forum for researchers, practitioners and educators from the areas of RE and SA to discuss their experiences, forge new collaborations, and explore innovative solutions that address the challenges that occur when relating RE and SA. The workshop provided participants with an opportunity to become familiar with the relationship between RE and SA in the broader context of software engineering, rather than in an isolated context of either RE or SA. The workshop featured one industrial keynote, five research paper presentations, two invited talks and four working group discussions.

Issues in the Design of Flexible and Dynamic Service-Oriented Systems

Due to the use of the concepts embedded in service-oriented architecture (SOA), software design, now more than ever, involves the use of incomplete information. Applications that utilize Web Services are also highly impacted by the problem of deployment and subsequent undeployment of services. Specifically, there is a level of uncertainty caused by the potential for services to become unavailable (either temporarily or permanently). In a scenario where an application must switch from one service to another due to the undeployment problem, the client application may require that new or different handlers be used to cope with the properties of the alternative service. In this current development climate, the design issues become clear: there is a need to reason about how a design is impacted by discovered services, design analysis must consider the transaction and event properties of discovered services, and design of systems must incorporate fault tolerance and high-integrity issues to cope with the dynamic landscape caused by the uncertainty associated with using services.