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.

Software interoperability property plays a vital role in enabling interoperation in todayfis system-of-systems, cyber-physical systems, ecosystems, etc. Despite the critical role of interoperability analysis in enabling a successful and meaningful software interoperation, it is still facing challenges that impede performing it effectively and efficiently. We performed an online survey of software engineers with software integration experiences to identify the main difficulties of performing interoperability analysis. The results confirm that the state of available practical support and current input artifacts used during the analysis are significantly perceived as important difficulties. Respondents claim a lack of guidelines and best practices for applying interoperability analysis and claim insufficiency of shared information about interoperable software units. This indicates the need for providing directive and rigorous guidelines for practitioners to follow and to enrich the content of shared documents about interoperable software units.

Successfully integrating a software system with an existing other software system requires, beyond technical mismatches, identifying and resolving conceptual mismatches that might result in worthless integration and costly rework. Often, not all relevant architectural information about the system to integrate with is publicly available, as it is hidden in internal architectural documents and not exposed in the public API documentation. Thus, we propose a framework of conceptual interoperability information and a formalization of it. Based on this framework, a system's architect can semi-automatically extract interoperability-relevant parts from his architecture and lower-level design documentation and publish it in a standardized and formalized way. The goal is to keep the additional effort for providing the interoperability-relevant information as low as possible and to encourage architects to provide it proactively. Thus, we extract from UML diagrams and textual documentation information that is relevant for conceptual interoperability. Companies that aim at interoperation of their systems with others, e.g. Companies initiating an ecosystem, should be highly motivated to provide such interoperability information in order to grow their business impact by more successful interoperations. In a more advanced level, also the architect, who is integrating his system with a provided one, could extract interoperability-related information about his existing system and we envision to automatically match the pieces of both sides and identify conceptual mismatches.

Building trustworthy knowledge in software engineering depends on the systematic synthesis of empirical evidence. In recent years the number of published syntheses has increased, but only a few showed high quality and scientific rigor. We performed an online survey of software engineering researchers to identify difficulties experienced when synthesizing evidence. The results confirm that the state of primary research and the low quality of reports are perceived as the most important difficulties. Respondents who were experienced in quantitative and qualitative synthesis methods claim a lack of support for selecting and applying synthesis methods. This indicates the need for identifying criteria for selecting synthesis methods, deriving recommendations, and developing more rigorous guidelines for applying them.

ABSTRACT Inspections and testing are two of the most commonly performed software quality assurance processes today. Typically, these processes are applied in isolation, which, however, fails to exploit the benefits of systematically combining and integrating them. In consequence, tests are not focused on the basis of early defect detection data. Expected benefits of such process integration include higher defect detection rates or reduced quality assurance effort. Moreover, when conducting testing without any prior information regarding the system's quality, it is often unclear how to focus testing. A systematic integration of inspection and testing processes requires context‐specific knowledge about the relationships between inspections and testing. This knowledge is typically not available and needs to be empirically identified and validated. Often, context‐specific assumptions can be seen as a starting point for generating such knowledge. On the basis of the integrated inspection and testing approach, In2Test, which uses inspection data to focus testing, we present in this article how knowledge about the relationship between inspections and testing can be gained, documented, and evolved in an analytical or empirical manner. In addition, this article gives an overview of related work and highlights future research directions. Copyright © 2012 John Wiley & Sons, Ltd.

SUMMARY Distributed software development imposes new project risks that are very different from the ones in collocated development and are overlooked easily. At the same time, they depend to a large extent on project‐specific characteristics. Therefore, new methods for identifying these risks in distributed projects have to be developed. This article presents a model for identifying these risks at the beginning of a project. The model systematically captures experiences from past projects in a set of logical rules describing how project characteristics influence typical risks in distributed development. Thus, it is able to assess risks individually for each project. In addition, the model can be used for evaluating different task assignment alternatives, which makes it possible to allocate tasks systematically. An instance of the model was developed by applying qualitative content analysis to 19 interviews with practitioners. An evaluation using expert interviews showed that the risks identified by the model matched the actual experiences in 81% of the cases; of these, 40% had not been regarded at project start. Copyright © 2011 John Wiley & Sons, Ltd.

The growing importance of software in ever more technical systems has led to new demands with respect to developing software. The demand for more functionality, higher quality, and faster delivery hence poses major challenges to the software industry. The software process community has responded with a variety of different development processes such as the waterfall model or the incremental commitment model, however, the number of late or failed projects has not decreased as much as it was desired. In the new millennium, agile development approaches promised a new way out of this dilemma. After several years of heated discussions, it is now time to evaluate applicability, advantages, and challenges of different software development approaches based on sound, empirical evidence instead of anecdotes and hearsay. This paper briefly investigates the major differences between agile and traditional approaches, illustrates the difficulties in selecting the "right" approach for a given project, and proposes hypotheses for empirical evaluation, in order to build a solid body of knowledge that can be used for said selection.

Inspections and testing are two of the most commonly performed software quality assurance processes today. Typically, these processes are applied in isolation, which, however, fails to exploit the benefits of systematically combining and integrating them. Expected benefits of such process integration are higher defect detection rates or reduced quality assurance effort. Moreover, when conducting testing without any prior information regarding the system's quality, it is often unclear which parts or which defect types should be prioritized. Existing approaches do not explicitly use information from inspections in a systematical way to focus testing processes. In this article, we present an integrated two-stage approach that routes inspection data to test processes in order to prioritize code classes and defect types. While an initial version of the approach focused on prioritizing code classes, this article focuses on the prioritization of defect types for testing. Results from a case study where the approach was applied on the code level show that those defect types could be prioritized before the testing that afterwards actually showed up most often during the test process. In addition, an overview of related work and an outlook on future research directions are given.

Many project risks in distributed software development are very different from the ones in collocated development and therefore are often overlooked. At the same time, they depend to a large extent on project-specific characteristics. This article presents a model for identifying risks early in a project. This model systematically captures experiences from past projects and is based on a set of logical rules describing how project characteristics influence typical risks in distributed development. Thus, the model is able to assess risks individually for each project. It was developed by applying qualitative content analysis to 19 interviews with practitioners. An evaluation using expert interviews showed that the risks identified by the model matched the actual experiences in 81% of the cases; of these, 40% have not been regarded yet at project start. The article describes the concepts of the model, its instantiation and evaluation, followed by a conclusion and future work.

Models for effort and cost estimation are important for distributed software development as well as for collocated software and system development. Standard cost models only insufficiently consider the characteristics of distributed development such as dissimilar abilities at the different sites or significant overhead due to remote collaboration. Therefore, explicit cost models for distributed development are needed. In this article, we present the initial development of a cost overhead model for a Spanish global software development organization. The model was developed using the CoBRA approach for cost estimation. As a result, cost drivers for the specific distributed development context were identified and their impact was quantified on an empirical basis. The article presents related work, an overview of the approach, and its application in the industrial context. Finally, we sketch the inclusion of the model in an approach for systematic task allocation and give an overview of future work.

The allocation of tasks can be seen as a success-critical management activity in distributed development projects. However, such task allocation is still one of the major challenges in global software development due to an insufficient understanding of the criteria that influence task allocation decisions. This article presents a qualitative study aimed at identifying and understanding such criteria that are used in practice. Based on interviews with managers from selected software development organizations, criteria currently applied in industry are identified. One important result is, for instance, that the sourcing strategy and the type of software to be developed have a significant effect on the applied criteria. The article presents the goals, design, and results of the study as well as an overview of related and future work.

Distributing development tasks in the context of global software development bears both many risks and many opportunities. Nowadays, distributed development is often driven by only a few factors or even just a single factor such as workforce costs. Risks and other relevant factors such as workforce capabilities, the innovation potential of different regions, or cultural factors are often not recognized sufficiently. This could be improved by using empirically-based multi-criteria distribution models. Currently, there is a lack of such decision models for distributing software development work. This article focuses on mechanisms for such decision support. First, requirements for a distribution model are formulated based on needs identified from practice. Then, distribution models from different domains are surveyed, compared, and analyzed in terms of suitability. Finally, research questions and directions for future work are given.

No abstract available.

No abstract available.

The Fraunhofer Gesellschaft e.V. in Germany is Europe's largest and most successful organization for applied research and technology transfer. Its 48 institutes cover all areas of technology and engineering ranging from materials and production technology to information & communication technology and solar energy. The Fraunhofer Institute for Experimental Software Engineering (IESE) in Kaiserslautern, Germany, focuses on software engineering methods, software product and process management, and learning organization concepts for software. It applies an experiment- or feedback-based transfer model, which has led to many successful and sustained improvements in the industrial practice of software development. In this presentation, the underlying transfer model, key business areas and core competencies of Fraunhofer IESE as well as examples of industrial transfer projects will be illustrated. The presentation will conclude with arguments why this transfer approach is well suited for software development and why it is a prerequisite for the professionalization of software development

The purpose of this panel is to introduce the Impact Project to the community, and to engage the community in a broad ranging discussion of the project's goals, approaches, and methods. Some of the project's early findings and directions will be presented.

S.240-243

This panel session includes an examination of: the modeling approaches the authors' groups are taking, the characteristics of the processes they are examining, the actual models that have been developed, and the lessons learned from these efforts.>

The Software Engineering Laboratory (SEL) is a joint venture between NASA's Goddard Space Flight Center, the University of Maryland, and Computer Sciences Corporation. The use of a goal-oriented approach to measurement establishing a maintenance improvement program within the SEL is discussed. Differences were found between the initial phase of the program and its routine application. The approach is demonstrated through concrete examples and lessons learned in the establishment of a measurement-based maintenance improvement program are summarized.>

A practical approach to improving software maintenance through measurement is presented. This approach is based on general models for measurement and improvement. Both models, their integration, and practical guidelines for transferring them into industrial maintenance settings are presented. Several examples of applications of the approach to real-world maintenance environments are discussed.>

Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture.>

This paper gives an overview of the INCAS (INCremental Architecture for distributed Systems) multicomputer project, which aims at the development of a comprehensive methodology for the design and implementation of locally distributed systems. A structuring concept for distributed operating systems has been developed and integrated into the system implementation language LADY. The concurrent high-level programming language CSSA, based on the actor model, has been designed for the implementation of distributed applications. A substantial effort in the INCAS project is directed towards the development of a distributed test methodology. An experimental system has been implemented on a network of ten MC68000 microcomputers. Preliminary experience with the methodology has been gained from a small number of prototype applications.

This paper describes a study on the impact of software structure on maintainability aspects such as comprehensibility, locality, modifiability, and reusability in a distributed system environment. The study was part of a project at the University of Kaiserslautern, West Germany, to design and implement LADY, a LAnguage for Distributed systems. The study addressed the impact of software structure from two perspectives. The language designer's perspective was to evaluate the general impact of the set of structural concepts chosen for LADY on the maintainability of software systems implemented in LADY. The language user's perspective was to derive structural criteria (metrics), measurable from LADY systems, that allow the explanation or prediction of the software maintenance behavior. A controlled maintenance experiment was conducted involving twelve medium-size distributed software systems; six of these systems were implemented in LADY, the other six systems in an extended version of sequential Pascal. The benefits of the structural LADY concepts were judged based on a comparison of the average maintenance behavior of the LADY systems and the Pascal systems; the maintenance metrics were derived by analyzing the interdependence between structure and maintenance behavior of each individual LADY system.