Structural coverage criteria are often used as an indicator of the thoroughness of testing, but complete satisfaction of a criterion is seldom achieved. When a software product is released with less than 100% coverage, testers are explicitly or implicitly assuming that executions satisfying the remaining test obligations (the residue) are either infeasible or occur so rarely that they havenegligible impact on quality. Violation of this assumption indicates shortcomings in the testing process. Monitoring in the deployed environment, even in the beta test phase, is typically limited to error and sanity checks. Monitoring the residue of test coverage in actual use can provide additional useful information, but it is unlikely to be accepted by users unless its performance impact is very small. Experience with a prototype tool for residual test coverage monitoring of Java programs suggests that, at least for statementcoverage, the simple strategy of removing all probes except those corresponding to the residue of coverage testing reduces execution overhead to acceptably low levels. Keywords Testing, coverage, instrumentation. 1

The fundamental goal of all good design and engineering is to create maximal value added for any given investment. There are many dimensions in which value can be assessed, from monetary profit to the solution of social problems. The benefits sought are often domain-specific, yet the logic is the same: design is an investment activity. Software economics is the field that seeks to enable significant improvements in software design and engineering through economic reasoning about product, process, program, and portfolio and policy issues. We summarize the state of the art and identify shortfalls in existing knowledge. Past work focuses largely on costs, not on benefits, thus not on value added; nor are current technical software design criteria linked clearly to value creation. We present a roadmap for research emphasizing the need for a strategic investment approach to software engineering. We discuss how software economics can lead to fundamental improvements in software design and engineering, in theory and practice. 1

The gulf between the user and the developer perspectives lead to diculties in producing successful software systems. Users are focused on the problem domain, where the system's features are the primary concern. Developers are focused on the solution domain, where the system's life-cycle artifacts are key. Presently, there is little understanding of how to narrow this gulf.

Abstract not found

Abstract not found

Abstract: The two most commonly used techniques for evaluating the fit between application design and use — namely, usability testing and beta testing with user feedback — suffer from a number of limitations that restrict evaluation scale (in the case of usability tests) and data quality (in the case of beta tests). They also fail to provide developers with an adequate basis for: (1) assessing the impact of suspected problems on users at large, and (2) deciding where to focus development and evaluation resources to maximize the benefit for users at large. This paper describes an agent-based approach for collecting usage data and user feedback over the Internet that addresses these limitations to provide developers with a complementary source of usage- and usability-related information. Contributions include: a theory to motivate and guide data collection, an architecture capable of supporting very large scale data collection, and real-word experience suggesting the proposed approach is complementary to existing practice.

Abstract not found

The success of Linux and Apache has strengthened the opinion that the open source paradigm is one of the most promising strategies to enhance the maturity, quality, and efficiency of software development activities. This observation, however, has not been discussed in much detail and critically addressed by the software engineering community. Most of the claims associated with open source appear to be weakly motivated and articulated. For this reason, this paper proposes some qualitative reflections and observations on the nature of open source software and on the most popular and important claims associated with the open source approach. The ultimate goal of the paper is to identify the concepts and intuitions that are really peculiar to open source, and to distinguish them from features and aspects that can be equally applied to or found in proprietary software. 1

We argue that organizations often fail to organize effectively because individuals have lay theories about organizing that lead to coordination neglect. We unpack the notion of coordination neglect and describe specific cognitive phenomena that underlie it. To solve the coordination problem, organizations must divide a task and then integrate the components. Individuals display shortcomings that may create problems at both stages. First, lay theories often focus more on division of labor than on integration. We discuss evidence that individuals display partition focus (i.e. they focus on partitioning the task more than on integration) and component focus (i.e. they tend to focus on single components of a tightly interrelated set of capabilities, particularly by investing to create highly specialized components). Second, when individuals attempt to reintegrate a task, they often fail to use a key mechanism for integration: ongoing communication. Individuals exhibit inadequate communication because the ‘curse of knowledge’ makes it difficult to take the perspective of another and communicate effectively. More importantly, because specialists find it especially difficult to communicate with each other, the

The maintenance of enterprise application software at a customer site is a potentially complex task for software vendors. This complexity can unfortunately result in a significant amount of work and risk. This paper presents a case study of a product software vendor that tries to reduce this complexity by integrating product data management (PDM), software configuration management (SCM), and customer relationship management (CRM) into one system. The case study shows that by combining these management areas in a single software knowledge base, software maintenance processes can be automated and improved, thereby enabling a software vendor of enterprise software to serve a large number of customers with many different product configurations.