We were delighted to have the paper “A Methodology for Collecting Valid Software Engineering Data”, by Victor Basili and David Weiss (1984) considered one of the most influential papers of IEEE Transaction of Software Engineering’s first decade. The paper discusses data or information on software quality and what were the most effective software development techniques. It was published in November, 1984. It was written at a time when software development was just becoming widespread practice, but it was not common to use data or information on software quality in order to learn what were the most effective software development techniques under different conditions. To try to alleviate this problem, we suggested that when people (or organizations) developed software, they should try to measure the effectiveness of their development techniques. In particular, since software is typically long-living, change data should be collected so that methods and processes could be managed.

This paper summarizes the motivation, objectives, and format of the 5th International Workshop on Product LinE Approaches in Software Engineering (PLEASE15). The main goal of the PLEASE workshop series is to encourage and promote the adoption of Software Product Line Engineering. This year's edition focuses on the link between software product line engineering (SPLE) and new challenges posed by emerging societal trends. Towards this end, we invited reports on (1) opportunities posed by societal challenges for SPLE research and practice and (2) concrete solutions exemplifying application of SPLE techniques to societal challenges.

A key issue in defining a product line is specifying the allowable set of products that will be produced using product line assets, i.e., the scope of the domain. This paper conducts an evaluation to compare two different approaches for defining domain scope, decision model as defined in the Family-oriented Abstraction, Specification, Translation (FAST) process and the feature model as defined in the Feature-Oriented Domain Analysis (FODA) process. The comparison is based on applying the approaches to two examples, one a textbook example and the other to a product line we maintain on an open source website, in order to identify guidelines for improving the identification and representation of a software family. Our conclusion is that decision model includes both commonality and variability definition at software architecture level and thus it is more suitable for larger product line with a significant number of commonality and variability.

Software engineering project courses where student teams are geographically distributed can effectively simulate the problems of globally distributed software development (DSD). However, this pedagogical model has proven difficult to adopt or sustain. It requires significant pedagogical resources and collaboration infrastructure. Institutionalizing such courses also requires compatible and reliable teaching partners. The purpose of this workshop is to continue building on our outreach efforts to foster a community of international faculty and institutions committed to developing, teaching and researching DSD. Foundational materials presented will include pedagogical materials and infrastructure developed and used in teaching DSD courses along with results and lessons learned. The third CTGDSD workshop will also focus on publishing workshop results and collaborating with the larger DSD community. Longrange goals include: lowering adoption barriers by providing common pedagogical materials, collaboration infrastructure, and a pool of potential teaching partners from around the globe.

This paper summarizes PLEASE 2013, the Fourth International Workshop on Product LinE Approaches in Software Engineering. The main goal of PLEASE is to encourage and promote the adoption of Software Product Line Engineering. To this end, we aim at bringing together researchers and industrial practitioners involved in developing families of related products in order to (1) facilitate a dialogue between these two groups and (2) initiate and foster long-term collaborations.

Companies around the world routinely distribute their software development across different sites. Students, however, rarely get a chance to learn the potential problems that arise, and the potential solutions to those problems, when conducting distributed development. It is especially difficult to simulate the situation for students when development is distributed across time zones and cultures. We have developed a course that requires teams of students at widely separated universities to collaborate with each other to complete a software development project. Instances of the course have been presented four times using combinations of five different universities, and we are seeking to create a larger pool of universities interested in and capable of presenting it. This paper discusses our goals, the characteristics of the course and the results of teaching it, with a primary result that all the universities want to and will offer the course again.

Software Product Line Engineering (SPLE) is a promising process for software development that has started to mature in the past ten years. Early indications are that it provides an improvement in productivity of about 3 to 1 over the software production and sustainment cycle of systems [2]. Although SPLE has been effective for early adopters, we still need to continue research to provide evidence of the effectiveness of SPLE, to find ways to improve SPLE technology and processes, and to establish strategies, methods, and capabilities for teaching SPLE and for training practitioners. Collaborative SPLE provides opportunities and challenges for researchers, educators and practitioners. Our goal is to create a Laboratory for Collaborative Software Product Line Engineering (LCSPLE) with worldwide membership that is willing and able to work towards making SPLE a mature technology that is widely used, that is, moving it from an early adopter technology to a majority technology, used in industry and taught in the universities. This workshop will start the process of creating the LCSPLE by bringing together, for the first time, a group of people who share its goal.

Software engineering project courses where student teams are geographically distributed can effectively simulate the problems of globally distributed software development (DSD). However, this pedagogical model has proven difficult to adopt or sustain. It requires significant pedagogical resources and collaboration infrastructure. Institutionalizing such courses also requires compatible and reliable teaching partners.

PLEASE workshop series focuses on exploring the present and the future of Software Product Line Engineering techniques. The main goal of PLEASE 2011 is to bring together industrial practitioner and software product line researchers in order to couple real-life industrial problems with concrete solutions developed by the community.

The concept of value can be formalized as the ratio of benefits to costs. The value is realized if total benefits outweigh total costs, while value-adding consists of delivering higher benefit at lower cost. Software Product Line Engineering (SPLE) has shown its power to bring benefits and reduce costs for practitioners in various domains, however, systematic value-adding analysis is rare and adding value through SPLE is a dynamic process. FISCAN, a leading manufacturer of security inspection systems in China, continues to explore the value-adding process through SPLE during the evolution of its software product lines in the security inspection domain. This paper discusses the value-adding effect of the "invisible hand" of the market. We identify economic, technical and organizational factors for value-adding through SPLE based on the SPLE practices at FISCAN. We describe the influence of the FISCAN product lines on FISCAN itself, the market and other stakeholders, and suggest what the future may bring in value-adding through SPLE.

Test coverage is sometimes used to measure how thoroughly software is tested and developers and vendors sometimes use it to indicate their confidence in the readiness of their software. This survey studies and compares 17 coverage-based testing tools primarily focusing on, but not restricted to, coverage measurement. We also survey features such as program prioritization for testing, assistance in debugging, automatic generation of test cases and customization of test reports. Such features make tools more useful and practical, especially for large-scale, commercial software applications. Our initial motivations were both to understand the available test coverage tools and to compare them to a tool that we have developed, called eXVantage (a tool suite that includes code coverage testing, debugging, performance profiling and reporting). Our study shows that each tool has some unique features tailored to its application domains. The readers may use this study to help pick the right coverage testing tools for their needs and environment. This paper is also valuable to those who are new to the practice and the art of software coverage testing, as well as those who want to understand the gap between industry and academia.

We investigate relationships among software quality measures commonly used to assess the value of a technology, and several aspects of customer perceived quality measured by Interval Quality (IQ): a novel measure of the probability that a customer will observe a failure within a certain interval after software release. We integrate information from development and customer support systems to compare defect density measures and IQ for six releases of a major telecommunications system. We find a surprising negative relationship between the traditional defect density and IQ. The four years of use in several large telecommunication products demonstrates how a software organization can control customer perceived quality not just during development and verification, but also during deployment by changing the release rate strategy and by increasing the resources to correct field problems rapidly. Such adaptive behavior can compensate for the variations in defect density between major and minor releases.

Software product line engineering (SPLE) takes advantage of the commonalities and predicts variabilities among members of a family to create efficient means of producing those members. Different approaches use different methods for defining the product line and producing members of the product line. We describe and demonstrate through a case study the FAST process for achieving generation of members of the product line. The case study introduces the idea of representing constraints among variabilities as edges in a graph and using different graph walking algorithms to generate members of the product line.

A hall of fame serves as a way to recognize distinguished members of a community in a field of endeavor. Those elected to membership in a hall of fame represent the highest achievement in their field, serving as models of what can be achieved and how. Each Software Product Line Conference culminates with a session in which members of the audience nominate systems for induction into the Software Product Line Hall of Fame. These nominations feed discussions about what constitutes excellence and success in product lines. The goal is to improve software product line practice by identifying the best examples in the field. Nominations are acted on by a panel of expert judges, who decide which nominees will be inducted into the Hall of Fame. You can read about the current members of the Software Product Line Hall of Fame at http://www.sei.cmu.edu/productlines/plp_hof.html. Inductees from 2005 will be announced at the SPLC 2006 Hall of Fame session.

We set out to answer a question we were asked by software project management: how much effort remains to be spent on a specific software project and how will that effort be distributed over time? To answer this question we propose a model based on the concept that each modification to software may cause repairs at some later time and investigate its theoretical properties and application to several projects in Avaya to predict and plan development resource allocation. Our model presents a novel unified framework to investigate and predict effort, schedule, and defects of a software project. The results of applying the model confirm a fundamental relationship between the new feature and defect repair changes and demonstrate its predictive properties.

Companies that engage in multi-site, multi-project software development continually face the problem of how to understand and improve their software development capabilities. We have defined and applied a goal-oriented process that enables such a company to assess the strengths and weaknesses of those capabilities. Our goals are to help a) to decrease the time and cost to develop software, b)to decrease the time needed to make changes to existing software, c) to improve software quality, d) to attract and retain a talented engineering staff, and e) to facilitate more predictable management of software projects. In response to the variety of product requirements, market needs, and development environments, we selected a goal-oriented process, rather than a criteria-oriented process, to advance our strategy and ensure relevance of the results. We describe the design of the process, discuss results achieved, and present vulnerabilities of the methodology. The process includes both interviews with projects' personnel and analysis of change data. Several common issues have emerged from the assessments across multiple projects, enabling strategic investments in software technology. Teams report satisfaction with the outcome in that they act on the recommendations, ask for additional future assessments, and recommend the process to sibling organizations.

A software product line is a family of products that share common features to meet the needs of a market area. Systematic processes have been developed to dramatically reduce the cost of a product line. Such product-line engineering processes have proven practical and effective in industrial use, but are not widely understood. The Family-Oriented Abstraction, Specification and Translation (FAST) process has been used successfully at Lucent Technologies in over 25 domains, providing productivity improvements of as much as four to one. In this paper, we show how to use FAST to document precisely the key abstractions in a domain, exploit design patterns in a generic product-line architecture, generate documentation and Java code, and automate testing to reduce costs. The paper is based on a detailed case study covering all aspects from domain analysis through testing. Copyright © 2000 John Wiley & Sons, Ltd.

No abstract available.

This paper discusses the organization of software that is inherently complex because of very many arbitrary details that must be precisely right for the software to be correct. We show how the software design technique known as information hiding, or abstraction, can be supplemented by a hierarchically structured document, which we call a module guide. The guide is intended to allow both designers and maintainers to identify easily the parts of the software that they must understand, without reading irrelevant details about other parts of the software. The paper includes an extract from a software module guide to illustrate our proposals.

An effective data collection methodology for evaluating software development methodologies was applied to five different software development projects. Results and data from three of the projects are presented. Goals of the data collection included characterizing changes, errors, projects, and programmers, identifying effective error detection and correction techniques, and investigating ripple effects.

An effective data collection method for evaluating software development methodologies and for studying the software development process is described. The method uses goal-directed data collection to evaluate methodologies with respect to the claims made for them. Such claims are used as a basis for defining the goals of the data collection, establishing a list of questions of interest to be answered by data analysis, defining a set of data categorization schemes, and designing a data collection form. The data to be collected are based on the changes made to the software during development, and are obtained when the changes are made. To ensure accuracy of the data, validation is performed concurrently with software development and data collection. Validation is based on interviews with those people supplying the data. Results from using the methodology show that data validation is a necessary part of change data collection. Without it, as much as 50 percent of the data may be erroneous. Feasibility of the data collection methodology was demonstrated by applying it to five different projects in two different environments. The application showed that the methodology was both feasible and useful.