Search

Our software framework, Proteus, treats adaptation as a first-class object, enabling rapid development of robust, adaptive applications. Proteus developers specify their programs' intent and adaptable components (or knobs). A control-theoretic runtime continually monitors the running application, adjusting knobs so that the specified intent is met.

Errors in safety-critical software can have disastrous consequences. However, tools exist that developers can use to thoroughly analyze software subsystems for critical safety properties.

Nine rising stars in software engineering describe how software engineering research will evolve, highlighting emerging opportunities and groundbreaking solutions. They predict the rise of end-user programming, the monitoring of developers through neuroimaging and biometrics sensors, analysis of data from unstructured documents, the mining of mobile marketplaces, and changes to how we create and release software.

Over time, source code tends to drift from the intended software architecture, often resulting in the loss of desired software qualities. To help keep code aligned with the intended architecture, the developers of core parts of the open source Eclipse platform introduced API Tools to express and check architectural rules. Researchers analyzed five years of Eclipse architecture-checking reports that API Tools produced. They investigated what kinds of rules the developers found helpful to check, how code diverged from the intended architecture, and how the developers dealt with architectural violations over time. This article is part of a special issue on Software Architecture.

Unexpected responses to a study questionnaire led to the realization that the context in which software is being used is extremely important. One particular thing to keep in mind is the software's operating range; that is, the conditions in which the software works best.

Software adaptation has become prominent owing to the proliferation of software in everyday devices. In particular, computing with the Internet of Things requires adaptability. Traditional software maintenance, which involves long, energy-consuming cycles, is no longer satisfactory. Adaptation is a lightweight software evolution that provides more transparent maintenance for users. This article classifies types of adaptation and describes an implementation of it.

Software-driven industries are advancing in five dimensions: collaboration, comprehension, connectivity, cloud, and convergence. However, companies often can get stuck in an overly narrow technology focus. To avoid this, they should connect architecture and functionality, master the entire software development life cycle, strengthen globally distributed teams, and streamline development.

Programmers have found creative ways around programming rules. However, such tactics have a cost.

A coderetreat is an event where software developers gather to spend a day exploring their craft in an informal yet intellectually challenging environment. It encourages reflective practice by addressing a single programming problem from different perspectives, with multiple coding partners, freed from the daily pressures of deadlines and the need to deliver completed artifacts. This article describes an experiment in which a coderetreat was run with a group of final-year undergraduates studying software architecture. The authors gathered qualitative and quantitative data to explore the ways in which the activity contributed to the participants' reflective practice. The results suggest that coderetreats are an excellent vehicle for reflective practice in software development, providing a context within which multiple aspects of self-reflection and motivation can be developed. The Web extra at http://youtu.be/racyZfkbgnQ is an audio recording in which author David Parsons expands on the article "Coderetreats: Reflective Practice and the Game of Life," discussing how coderetreats can encourage self-reflection in software engineers.

Refactoring changes a program's source code without changing its external behavior, typically to improve the software's design The articles selected for this issue range from historical, exploring refactoring research's origins, to practical, exploring software developers' experiences with refactoring, to theoretical, exploring new refactoring techniques that haven't yet appeared in the wild. The Web extra at https://youtu.be/f2IK3V9wwa8 is an audio recording of Davide Falessi speaking with guest editors Emerson Murphy-Hill of North Carolina State University, Don Roberts of the University of Evansville, and Peter Sommerlad of Fachhochschule Ostschweiz / Hochschule fur Technik Rapperswil about past, present, and future approaches to refactoring.

The paper presents an empirical study that compares IT professionals' perceptions about the ease of reuse in modeling business systems from component versus object libraries. Results indicate that they perceive components to be much easier to reuse than objects.

Although commercial-off-the-shelf (COTS) product integration presents clear advantages in a variety of engineering fields, several problems can arise in part due to their heterogeneous nature. Little research addresses the integration of particular COTS to specific domains. A University of Vigo project for reusable software development in the engineering domain adopted this approach. The underlying hypothesis was that making COTS integration easier would facilitate the development of domain-specific applications. The solution consists of a two-layer wrapping approach. The first layer captures the COTS domain model, facilitating integration of general-purpose functionality. A second layer provides better integration of more domain-specific functionality. Several real software development projects have used the proposed solution, and the results yielded notable effort savings, showing the approach's utility in reducing COTS integration efforts.

Employing a software platform is an approach to achieve a higher degree of software reuse by enabling multiple software products to share the platform-provided services. However, platform development usually involves stakeholders from different application domains. Their application situations vary widely and thus nonfunctional requirements (NFRs) for the software platform must address a wider range of needs than those for a single product. This article describes lessons learned in developing NFRs for a large software platform, the challenging issues, and the techniques used to address them. The techniques are pragmatic and helped with NFR reconciliation and management. The improved quality of the NFR specifications has permitted automation of platform performance testing for the past two years.

The authors describe an issue that they think is extremely important: the relationship between applications and solutions in the software engineering and information systems fields. In particular, they believe the fields desperately need a taxonomy of application domains, a taxonomy of solution approaches, and a mapping between the two. This article has a Web extra that offers an interview with one of the article's authors, Robert L. Glass, about the "dark side" of this topic.

Software engineering (SE) conference in 1968, Doug Mc Ilroy introduced the concept of software components during his keynote speech, "Mass-Produced Software Components." That components hold such an esteemed place in SE history should come as no surprise: componentization is a fundamental engineering principle. Top-down approaches decompose large systems into smaller parts-components and bottom-up approaches compose smaller parts components into larger systems. Since 1968, components have played a role in both SE research and practice. For example, components have been an immanent part of software architecture from its early days.2 In 1998, the In ternational Conference on Software Engineering introduced component based software engineering (CBSE) as a specific area within SE at the first workshop on CBSE.

Model-driven software development (MDD) is gaining increasing acceptance, mainly because it can raise the level of abstraction and automation in software construction. MDD techniques (see the sidebar "MDD Basic Concepts"), such as metamodeling and model transformation, not only apply to the creation of new software systems but also can be used to evolve existing systems. These techniques can help reduce software evolution costs by automating many basic activities in software change processes, such as representing source code at a higher level of abstraction, providing information to analyze the impact of the changes, or automatically generating software artifacts of the evolved system. Several experiences of applying MDD in platform migration scenarios have recently been published,1'2 but they define ad hoc metamodels that hinder interoperability.

Our collaborative research activities in software development (at the University of Colorado's Center for Lifelong Learning and Design, the University of Tokyo, and Software Research Associates) have focused on understanding the implications of the quickly disappearing distinction between users and developers. We've also concentrated on establishing new software development methodologies by viewing software systems as continuously evolving sociotechnical systems driven by design activities of both professional software engineers and users. We believe that domain experts, as the owners of problems, need to be in charge of developing the software they require. Toward that end, we've created the metadesign framework, which reformulates software development activities as a continuum of different degrees of design and use. In addition, on the basis of our research and our findings in the research literature, we've developed a set of guidelines for supporting domain experts in software development.

Situated software, a type of opportunistic software, is created by a small subset of users to fulfill a specific purpose. For example, business users have been creating situated software through mashups, which combine data from multiple sources on internal systems or the Internet. Situated software can change the way users access, perceive, and consume information, and can allow users to finally focus on what to do with information, rather than where to find it or how to get to it. However, situated software also has limitations. This article identifies situated software's role, provides examples of its use, traces the Internet's role in its rapid evolution, outlines areas where it is appropriate, describes its limitations, and presents enablers for adopting situated software in an enterprise.

Software development tools often fail to deliver on inflated promises. Rather than the predicted progression toward ever-increasing levels of abstraction, two simple trends have driven the evolution of currently available software development tools: integration at the source-code level and a focus on quality. Thus source code has become the bus that tools tap into for communicating with other tools. Also, focus has shifted from defect removal in the later phases to defect prevention in the earlier phases. In the future, tools are likely to support higher levels of abstraction, perhaps in the form of domain-specific languages communicated using XML.

For many years, the IT industry has sought to accelerate the software development process by assembling new applications from existing software assets. However, true component-based reuse of the form Douglas Mcllroy envisaged in the 1960s is still the exception rather than the rule, and most of the systematic software reuse practiced today uses heavyweight approaches such as product-line engineering or domain-specific frameworks. By component, we mean any cohesive and compact unit of software functionality with a well-defined interface - from simple programming language classes to more complex artifacts such as Web services and Enterprise JavaBeans.

Over the past decade, software agents and multiagent systems have grown into a powerful software engineering paradigm. They enable abstractions not only from the problem domain but also toward dynamic solutions that evolve in real time, depending on environmental stimuli to the software system. Agent-oriented software engineering supports the design of dynamically interacting components, each with its own thread of control, and using complex coordination protocols such as networking applications, ubiquitous computing, and sensor networks. The major pitfall so far has been the lack of sufficient engineering methodology. Author Hisham Mubarak looks at the engineering of agent-oriented systems and provides practical guidance to get started.

An action research project involving scientists from the National Research Council Canada and the Institute for Ocean Technology analyzed difficulties in using software to collect data and manage processes. The project identified three requirements for increasing research productivity: ease of use for end users, managing scientific workflows, and facilitating software interoperability. On the basis of these requirements, the researchers developed Sweet, a software framework, to help automate scientific workflows.

Software product-line development lets organizations better optimize software development efficiency by building a shared set of assets for reuse in multiple products. This process introduces many challenges, not least of which is creating the initial set of reusable software assets. To accomplish this, organizations often establish a central software platform group. Such a group faces a serious problem: existing systems groups already have a large set of software components that they use to build their products. If companies are to successfully transition to product-line development, these systems groups must shift their investments from existing software components to the new reusable product-line assets. One way to encourage this is to create an internal open source software community that lets systems groups actively contribute their existing components to the platform. In OSS, a community works together to develop software. Because the software's users are part of the community, they can add the assets they need. Inner-source-software (ISS) development applies OSS within a limited environment that has a closed border (such as a company, a division, or a consortium). So, companies using the ISS approach essentially establish an OSS community within the confines of their organization.

One area from which we might gain leverage in the ubiquitous- and embedded-systems domain is software architecture, which has emerged over the past decade as an area of intense interest among researchers and practitioners. Such interest has resulted in many approaches to dealing with architectural description and analysis, architectural styles, domain-specific and application family architectures, and architecture-based dynamic system adaptation. By and large, however, these approaches share assumptions that make them suited specifically to the domain of traditional, desktop-based development platforms. Those comparatively few architecture-based solutions that have focused on software systems for embedded devices have faced some traditional development challenges (such as applying solutions across an application family) but have also had different priorities (for example, ensuring efficient, architecture-compliant system implementations). In this article, the author draw general distinctions between "traditional" software architectures and those targeted at embedded systems. The author focuses on several areas that traditional software architecture research has studied and discusses their applicability and potential shortcomings in the embedded-systems context.

Test Driven Development: A Practical Guide by David AstelsAgile & Iterative Development: A Manager's Guide by Craig LarmanSoftware by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang

In general, software reuse is defined as "the process of creating software systems from existing software". Software reuse does more than improve productivity in software development; it also increases the quality of the resulting software systems because it uses validated artifacts. However, requirements reuse lacks tool support. Techniques for retrieving, adapting, and consolidating reusable requirements have received relatively little attention in comparison with all the work on software reuse. The work in this area has not made sufficient progress to date to determine whether such approaches may be practical and may scale up. Our REUSER project seeks to address this tool gap by seamlessly assisting analysts as they reuse UML (Unified Modeling Language) artifacts. In particular, it automates artifact retrieval.

What tools do we use to develop and debug software? Most of us rely on a full-screen editor to write code, a compiler to translate it, a source-level debugger to correct it, and a source-code control system to archive and share it. These tools originated in the 1970s, when the change from batch to interactive programming stimulated the development of innovative languages, tools, environments, and other utilities we take for granted. Microsoft Research has developed two generations of tools, some of which Microsoft developers already use to find and correct bugs. These correctness tools can improve software development by systematically detecting programming errors.

In the development of any technology, there's always a tendency to lose sight of the basic problems that stimulated its introduction in the first place. Technologies in software construction are no exception. One of the essential parts of software construction is the underlying programming paradigm. In the last few decades, different software construction paradigms have evolved - for example, structured programming in the 1970s and object-oriented programming in the 1980s. Although OOP dominates current software construction, it introduces several problems that might raise questions about its understandability and efficiency. W. Cave (1995) was the first to propose and develop the separation principle as a programming paradigm. One major contribution is that it moves most complex issues related to data sharing, parameter passing, and scope into a programming model in which simple graphics can represent access to data. The separation principle can simplify or even eliminate these issues. By expressing access permissions in simple, canonical drawings, the separation principle makes it easy to comprehend the full range of relationships between data and instructions, and thus the code's structure. A simple way to show connectivity, a key property affecting program understandability, is by separating data from instructions. Two of prediction systems' flagship products, the visual software environment (VSE) and the general simulation system (GSS), embody this idea. This paper discusses the separation principle in the context of conventional languages such as C and C++.

Many hail service-oriented software as the next revolution in software development. Web services' capabilities are constantly expanding from simple message passing toward the construction of full-fledged applications such as those envisaged by the UK's Pennine Group in their Software as a Service (SaaS) framework. These new, service-oriented approaches appear to many to solve the significant issue of software inflexibility that arises during maintenance and evolution. While they address sonic aspects of the problem, however, understanding the software still poses some difficulty. This shift toward service orientation compels us to consider its implications for software understanding, which is potentially the primary cost in software engineering. Using an example of on-the-fly software services construction, we discuss the problems software engineers still face when working with service-oriented software. We also introduce some new issues that they must consider, including how to address service provision difficulties and failures.

The open source movement is affecting software development products and processes. Software products benefit from reusable elements' increased availability and flexibility but might suffer from tighter coupling and more complex dependencies between reused components. The software development process is gaining from the widespread availability and use of sophisticated open source development platforms and tools, and the adoption of corresponding development and coding practices by the programmer community. In addition, code as literature is helping the meaningful education of programmers. However, process integration and the coevolution of multiple open source and proprietary projects are still open problems.

MDD has improved productivity, quality, and platform independence but hasn't been that successful at supporting reuse and system evolution. To do so, a system must be specified as a composition of multiple views corresponding to stakeholders and their concerns. The proposed Template abstraction addresses this problem in an integrated way, dealing with separation of concerns at both the model and the code level.

Software process comprises activities such as estimation, planning, requirements analysis, design, coding, reviews, and testing, undertaken when creating a software product. Effective software process management involves proactively managing each of these activities. Statistical process control tools enable proactive software process management. One such tool, the control chart, can be used for managing, controlling, and improving the code review process.

Solving the problem of failed project ownership is not merely a process of assigning developers to subsystems. This article describes four code ownership models, ranging from one individual owning an entire system to the collective ownership that is a core extreme programming practice. No single code ownership model is best. In fact, many projects would benefit from dynamically adjusting the ownership model over time as development progresses through, for example, the four phases of the unified process.

Separation-of-concerns technologies are key to improving the maintainability and adaptability of software artifacts. These technologies identify loosely coupled, modular, and reusable units of description from which developers can generate tailored software systems with minimal effort. Aspect-oriented programming provides perhaps the most explicit application of the separation-of-concerns tenet.

Commercial-off-the-shelf software components are considered an important technology for future software development. However, compared to their potential benefit, their market success has been modest. This article discusses how unrestricted proliferation of functionally similar software components is technically and economically disadvantageous. Software patents can slow it further by channeling it into either additional applications of existing technology or more significant improvements to that technology. This would facilitate component-based software reuse and strengthen COTS software's weak business model.

Web applications have very high requirements for numerous quality attributes. This article discusses some of the technological challenges of building today's complex Web software applications, their unique quality requirements, and how to achieve them.

This article addresses a key issue in security: how to inspire trust by disclosing security properties of software components to others in a component-based software development environment. The authors introduce a component security characterization framework in this endeavor that characterizes security properties by exposing software security profiles to others. The active interface lets software engineers know up front the impact of security properties of a composition's candidate components.

Is the variety of smartphones really a blessing to users? How can software developers ensure the quality of their products within only 18 weeks of development? Is it possible to test a large number of device models within a short time period? Conventional methods extract the coordinates of touch events, and cannot easily adapt to different device models. In this paper, we propose a fast, automated, adaptive gesture testing method for a wide variety of smartphones.

Using the right software is increasingly critical to project success, but the choices keep getting wider and more confusing. Open source software (OSS) has entered the mix, leaving the traditional confines of the hacker community and entering large-scale, well-publicized applications. However, although some argue that it is ready for wide-scale commercial adaptation and deployment, the myriad number of OSS packages make actual adoption a real challenge. This article presents a straightforward and practical roadmap to navigate your OSS adoption considerations. We do not have a universally accepted definition of OSS. For instance, Netscape, Sun Microsystems, and Apple recently introduced what they call "community-source" versions of their popular software-the Mozilla project, Solaris, and MacOS X, respectively. Such efforts, while validating the OSS concept, also make their inclusion into the OSS community a potential topic for contention. We use the loose definition of OSS that includes publicly available source code and community-source software.

Software development has not reached the maturity of other engineering disciplines; it is still challenging to produce software that works reliably, is easy to use and maintain, and arrives within budget and on time. In addition, relatively small software systems for highly specific applications are in increasing demand. This need requires a significantly different approach to software development from that used by their large, monolithic, general-purpose software counterparts such as Microsoft Word. The paper discusses the use of components for rapid distributed software development. It reports on the the experience of a large testbed called Educational Software Components of Tomorrow (www.escot.org), supported by the US National Science Foundation.

While formal methods are gaining acceptance in the software industry, there is a need for practical guidelines for making the best use of formal specifications. The author provides a few such pragmatic tips for people involved in the industrial use of formal specifications. The 15 guidelines are split into two areas, dealing with process and content. The author also includes a full-page reference for literature available over the Web.

Software is deterministic. Given a starting state and a fixed series of inputs, software will produce the exact same output every single time those inputs are applied. In fact, many of the technologies we apply during development (reviews, formal proofs, testing, and so forth) rely on this determinism; they would not work otherwise. But if software is deterministic, why do weird things happen? Why is it that we can apply a sequence of inputs and observe a failure and then be unable to reproduce that failure? Why does software work on one machine and fail on another? How is it that you can return from lunch and find your Web browser has crashed when it wasn't being used? The answer is, of course, that modern software processes an enormous number of inputs and only a small percentage of these inputs originate from human users. When testers can't reproduce failures, the reason is that they are only resubmitting the human input without sufficient regard to the operating system return codes and input from runtime libraries. When software fails on a new computer after running successfully on another, the reason can only be that the new system is supplying input that differs in content from the old one. And the browser that crashes when you are at lunch is responding to input from a nonhuman external resource.

The software industry has practiced pair programming (two programmers working side by side at one computer on the same problem) with great success for years, but people who haven't tried it often reject the idea as a waste of resources. The authors demonstrate that using pair programming in the software development process yields better products in less time-and happier, more confident programmers.

Developers can use this new sizing metric called Web Objects and an adaptation of the Cocomo II model called WebMo to more accurately estimate Web based software development effort and duration. Based on work with over 40 projects, these estimation tools are especially useful for quick-to-market development efforts.

Automating support for the Goals-Questions-Metrics (GQM) process can cut data collection costs by exploiting the data available in configuration management systems as well as the data supplied by code analysers. The author introduces a tool that is designed for this purpose and reviews its development and applications in industry.

A software project's estimate of effort commonly requires input specifying the project size, and a reliable size estimate depends on many factors. This study examines a completed C++ project and considers programming artifacts that we can readily trace to requirements and early class design.

Introducing object-oriented development methods into a large organization requires some special kind of methodological guidance. The paper discusses the AD-model (Application-Development model) which integrates modeling, programming, architecture, and process guidelines to provide a coherent OO development approach that can be applied to a wide range of projects. The paper considers its introduction in a large banking organization.

Not all scientific computing is high-performance computing—the variety of scientific software is huge. Such software might be complex simulation software developed and running on a high-performance computer, or software developed on a PC for embedding into instruments; for manipulating, analyzing or visualizing data or for orchestrating workflows. This special issue provides some flavor of that variety. It also explores the question of how the development of scientific software can be improved.

In the essay "Code Ownership-a Quality Issue," Sigrid Eldh argues for adapting code ownership to specific situations, focusing on quality, and taking into account ownership of the test code. In the essay "Code Ownership-More Complex to Understand Than Research Implies," Brendan Murphy argues for a broader and deeper analysis of code ownership.

Do the old tried and true principles of software engineering make any sense on the completely new playing field of the Internet? See what nine software leaders have to say.