Among the approaches that investigate the similarity between web services, hardly any concentrates on the impacts from contexts. In this paper we introduce service2vec which is an approach to represent web services as service embeddings based on a recent popular deep learning technique word2vec. Our approach composes and combines web services to be a document that is trained by the modeling technique of word2vec. As a result, each web service in the document is vectorized. By taking the advantage of word2vec, the resulting service embeddings of service2vec can be used to illustrate the contextual relations between web services. The experimental results suggest that service2vec can deliver contextual similarity between web services.

Developers participating in an open source software (OSS) project make contributions to the project at different levels and aspects. Their underlying technical interests, expertise, and working habits are indirectly delineated by their personal contributions. This paper is to discover the individualized contribution features of developers by latent Dirichlet allocation (LDA) approach. Dominant latent topics of each developer and the corresponding topic coverage degree are extracted from the source codes committed to the project repository, and such topic model is validated to be feasible for representing the individualized contribution features by statistics tests. Four types of topic evolution patterns are observed from the commit history of a developer. Temporal locality is partially exhibited in the topic evolution but there usually exhibit drastic changes between time-adjacent contributions of a developer. Respective proportions of the four evolution patterns and the degree of temporal locality in the topic evolution delineate a developer’s individualized working habits in the time dimension. It is also proved that the correlation among the topic models of different developers is not equivalent to the real social collaborations among them. The outcome of this study would help OSS project coordinators get deep understanding on the work preferences and behavioral patterns of team members, thus facilitate project coordination activities such as task allocations.

Journal of Software: Evolution and ProcessVolume 29, Issue 11 e1869 SPECIAL ISSUE PAPER ICSSP 2016 – Special Issue Introduction Marco Kuhrmann, Corresponding Author Marco Kuhrmann [email protected] orcid.org/0000-0001-6101-8931 Clausthal University of Technology, Goslar, Germany Correspondence Clausthal University of Technology, Institute for Applied Software Systems Engineering, Wallstraße 6, 38640 Goslar, Germany. Email: [email protected] for more papers by this authorRory V. O'Connor, Rory V. O'Connor orcid.org/0000-0001-9253-0313 Dublin City University, Dublin, IrelandSearch for more papers by this authorDewayne E. Perry, Dewayne E. Perry University of Texas, Austin, TX, U.S.A.Search for more papers by this authorDavid Raffo, David Raffo Portland State University, Portland, OR, U.S.A.Search for more papers by this author Marco Kuhrmann, Corresponding Author Marco Kuhrmann [email protected] orcid.org/0000-0001-6101-8931 Clausthal University of Technology, Goslar, Germany Correspondence Clausthal University of Technology, Institute for Applied Software Systems Engineering, Wallstraße 6, 38640 Goslar, Germany. Email: [email protected] for more papers by this authorRory V. O'Connor, Rory V. O'Connor orcid.org/0000-0001-9253-0313 Dublin City University, Dublin, IrelandSearch for more papers by this authorDewayne E. Perry, Dewayne E. Perry University of Texas, Austin, TX, U.S.A.Search for more papers by this authorDavid Raffo, David Raffo Portland State University, Portland, OR, U.S.A.Search for more papers by this author First published: 08 November 2017 https://doi.org/10.1002/smr.1869Read the full textAboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Volume29, Issue11Special Issue: Process in Action: The Best Papers from The International Conference on Software and Systems Process 2016November 2017e1869 RelatedInformation

Open Source Software (OSS) is usually developed by geographically-distributed developers in a collaborative manner.Different developers exhibit different behaviors and make diversified contributions to OSS projects.Objective of this paper is to discover individualized characteristics and common patterns of how developers contribute to OSS projects.Continuity is used to delineate how a developer actively contributes to the project over time.Case studies on two OSS projects reveal some significant phenomena on the distribution of developers' contributions relative to absolute time and relative to the milestones (i.e., releases) of OSS projects.We have found that OSS developers' contributions exhibit the "temporal locality", and most of the releases of an OSS project are dominated by the contributions of a limited number of developers.

In Free/Libre and Open-Source Software (FLOSS) project teams, different roles make different types of contributions to the projects, and it has been demonstrated that keeping a rational role distribution is of great significance to the potential growth and expansion of the projects. To identify the underlying patterns of team structures and role transformations, we perform an empirical study on 89 popular GitHub projects. The distribution of 9 roles and 66 types of role transformations are analyzed. Four clusters of FLOSS projects are identified in terms of the distinct characteristics on the proportion of 9 roles (i.e., the team structure) and the frequency of occurrence, duration, and Times of Activeness (ToA) of role transformations. This study would help FLOSS project coordinator have a deeper understanding of dynamic role distributions and role transformations in their teams, so as to take initiatives to improve their team structures.

Regression testing is widely used in practice for validating program changes. However, running large regression suites can be costly. Researchers have developed several techniques for prioritizing tests such that the higher-priority tests have a higher likelihood of finding bugs. A vast majority of these techniques are based on dynamic analysis, which can be precise but can also have significant overhead (e.g., for program instrumentation and test-coverage collection). We introduce a new approach, REPiR, to address the problem of regression test prioritization by reducing it to a standard Information Retrieval problem such that the differences between two program versions form the query and the tests constitute the document collection. REPiR does not require any dynamic profiling or static program analysis. As an enabling technology we leverage the open-source IR toolkit Indri. An empirical evaluation using eight open-source Java projects shows that REPiR is computationally efficient and performs better than existing (dynamic or static) techniques for the majority of subject systems.

Understanding the severity of reported bugs is important in both research and practice. In particular, a number of recently proposed mining-based software engineering techniques predict bug severity, bug report quality, and bug-fix time, according to this information. Many bug tracking systems provide a field "severity" offering options such as "severe", "normal", and "minor", with "normal" as the default. However, there is a widespread perception that for many bug reports the label "normal" may not reflect the actual severity, because reporters may overlook setting the severity or may not feel confident enough to do so. In many cases, researchers ignore "normal" bug reports, and thus overlook a large percentage of the reports provided. On the other hand, treating them all together risks mixing reports that have very diverse properties. In this study, we investigate the extent to which "normal" bug reports actually have the "normal" severity. We find that many "normal" bug reports in practice are not normal. Furthermore, this misclassification can have a significant impact on the accuracy of mining-based tools and studies that rely on bug report severity information.

Global software development (GSD) is considered as the coordinated activities of software development that are geographically and temporally distributed.The management of architectural knowledge, specifically, architectural design decisions (ADDs), becomes important in GSD due to the geographical, temporal, and cultural challenges in global environments.Based on our previous work on ADD management in localized software development (LSD), we present five ADD paradigms used for GSD projects with different organizational structures.We also investigate the benefits and the challenges of the ADD paradigms by conducting an evaluation of the paradigms using extensive archived semi-structured interview data from industrial GSD projects.We aim to provide a fundamental framework for managing ADD documentation and evolution in GSD, as well as offer useful insights into managing architectural knowledge in a global setting.

Global software development (GSD) is considered as the coordinated activities of software development that are geographically and temporally distributed. The management of architectural knowledge, specifically, architectural design decisions (ADDs), becomes important in GSD due to the geographical, temporal, and cultural challenges in global environments. Based on our previous work on ADD management in localized software development, we present five ADD paradigms for GSD projects with different organizational structures. We also investigate the benefits and the challenges of these ADD paradigms by conducting an evaluation of the paradigms using extensive archived semi-structured interview data from industrial GSD projects. We aim to provide a fundamental framework for managing ADD documentation and evolution in GSD, as well as offer useful insights into managing architectural knowledge in a global setting.

Context Bug fixing is an integral part of software development and maintenance. A large number of bugs often indicate poor software quality, since buggy behavior not only causes failures that may be costly but also has a detrimental effect on the user’s overall experience with the software product. The impact of long lived bugs can be even more critical since experiencing the same bug version after version can be particularly frustrating for user. While there are many studies that investigate factors affecting bug fixing time for entire bug repositories, to the best of our knowledge, none of these studies investigates the extent and reasons of long lived bugs. Objective In this paper, we investigate the triaging and fixing processes of long lived bugs so that we can identify the reasons for delay and improve the overall bug fixing process. Methodology We mine the bug repositories of popular open source projects , and analyze long lived bugs from five different perspectives: their proportion, severity, assignment, reasons, as well as the nature of fixes. Results Our study on seven open-source projects shows that there are a considerable number of long lived bugs in each system and over 90% of them adversely affect the user’s experience. The reasons for these long lived bugs are diverse including long assignment time, not understanding their importance in advance, etc. However, many bug-fixes were delayed without any specific reasons. Furthermore, 40% of long lived bugs need only small fixes. Conclusion Our overall results suggest that a significant number of long lived bugs may be minimized through careful triaging and prioritization if developers could predict their severity, change effort, and change impact in advance. We believe our results will help both developers and researchers better to understand factors behind delays, improve the overall bug fixing process, and investigate analytical approaches for prioritizing bugs based on bug severity as well as expected bug fixing effort.

Localizing bugs is important, difficult, and expensive, especially for large software projects. To address this problem, information retrieval (IR) based bug localization has increasingly been used to suggest potential buggy files given a bug report. To date, researchers have proposed a number of IR techniques for bug localization and empirically evaluated them to understand their effectiveness. However, virtually all of the evaluations have been limited to the projects written in object-oriented programming languages, particularly Java. Therefore, the effectiveness of these techniques for other widely used languages such as C is still unknown. In this paper, we create a benchmark dataset consisting of more than 7,500 bug reports from five popular C projects and rigorously evaluate our recently introduced IR-based bug localization tool using this dataset. Our results indicate that although the IR-relevant properties of C and Java programs are different, IR-based bug localization in C software at the file level is overall as effective as in Java software. However, we also find that the recent advance of using program structure information in performing bug localization gives less of a benefit for C software than for Java software.

Locating bugs is important, difficult, and expensive, particularly for large-scale systems. To address this, natural language information retrieval techniques are increasingly being used to suggest potential faulty source files given bug reports. While these techniques are very scalable, in practice their effectiveness remains low in accurately localizing bugs to a small number of files. Our key insight is that structured information retrieval based on code constructs, such as class and method names, enables more accurate bug localization. We present BLUiR, which embodies this insight, requires only the source code and bug reports, and takes advantage of bug similarity data if available. We build BLUiR on a proven, open source IR toolkit that anyone can use. Our work provides a thorough grounding of IR-based bug localization research in fundamental IR theoretical and empirical knowledge and practice. We evaluate BLUiR on four open source projects with approximately 3,400 bugs. Results show that BLUiR matches or outperforms a current state-of-the-art tool across applications considered, even when BLUiR does not use bug similarity data used by the other tool.

Understanding the evolution of clones is important both for understanding the maintenance implications of clones and building a robust clone management system. To this end, researchers have already conducted a number of studies to analyze the evolution of clones, mostly focusing on Type-1 and Type-2 clones. However, although there are a significant number of Type-3 clones in software systems, we know a little how they actually evolve. In this paper, we perform an exploratory study on the evolution of Type-1, Type-2, and Type-3 clones in six open source software systems written in two different programming languages and compare the result with a previous study to better understand the evolution of Type-3 clones. Our results show that although Type-3 clones are more likely to change inconsistently, the absolute number of consistently changed Type-3 clone classes is higher than that of Type-1 and Type-2. Type-3 clone classes also have a lifespan similar to that of Type-1 and Type-2 clones. In addition, a considerable number of Type-1 and Type-2 clones convert into Type-3 clones during evolution. Therefore, it is important to manage type-3 clones properly to limit their negative impact. However, various automated clone management techniques such as notifying developers about clone changes or linked editing should be chosen carefully due to the inconsistent nature of Type-3 clones.

Stack Overflow is a highly successful question-answering website in the programming community, which not only provide quick solutions to programmers’ questions but also is considered as a large repository of valuable software engineering knowledge. However, despite having a very engaged and active user community, Stack Overflow currently has more than 300K unanswered questions. In this paper, we perform an initial investigation to understand why these questions remain unanswered by applying a combination of statistical and data mining techniques. Our preliminary results indicate that although there are some topics that were never answered, most questions remained unanswered because they apparently are of little interest to the user community.

Abstract Software evolution is an increasingly challenging and compelling concern for every developed software system because of the changes in the requirements, the technology, etc. When software evolution is carried out, software architecture emerges as one of the cornerstones that should be considered from two different points of view: as an artifact for the evolution, as it helps the architect plan and restructure the system, and as an artifact of the evolution, because it has to be modified as well. This paper focuses on the second point of view—that is, on the evolution of the software architecture, but taking into account architectural knowledge as a key driver of the process. Given that architecture rationale and design intent are critical in evolving software systems, it is imperative that they be captured in some useful form to aid that evolution process. We present a new approach for evolution styles that extends them by considering in their description the architectural knowledge as a valuable asset of the evolution process. Copyright © 2012 John Wiley & Sons, Ltd.

The release and deployment phase of the software development process is often overlooked as part of broader software engineering research. In this paper, we discuss early results from a set of multiple semi-structured interviews with practicing release engineers. Subjects for the interviews are drawn from a number of different commercial software development organizations, and our interviews focus on why release process faults and failures occur, how organizations recover from them, and how they can be predicted, avoided or prevented in the future. Along the way, the interviews provide insight into the state of release engineering today, and interesting relationships between software architecture and release processes.

Background: Software agents are becoming increasingly common in the engineering of software systems. We explore the use of humans in creating benchmarks for the evaluation of software agents. In our case studies, we address the domain of instructable software agents (e-students) as proposed by the Bootstrapped Learning project [Oblinger, 2006]. Aim: Our aim is to define and refine requirements, problem solving strategies, and evaluation methodologies for e-students, paving the way for rigorous experiments comparing e-student performance with human benchmarks. Method: Little was known about what factors would be critical, so our empirical approach is exploratory case studies. In two studies covering three distinct groups, we use human subjects to develop an evaluation curriculum for e-students, collecting quantitative data through online quizzes and tests and qualitative data through observation. Results: Though we collect quantitative data, our most important results are qualitative. We uncover and address several intrinsic challenges in comparing software agents with humans, including the greater semantic understanding of humans, the eidetic memory of e-students, and the importance of various study parameters (including timing issues and lesson complexity) to human performance. Conclusions: Important future work will be controlled experiments based on the experience of these case studies. These will provide benchmark human performance results for specific problem domains for comparison to e-student results. I.

Software releases form a critical part of the life cycle of a software project. Typically, each project produces releases in its own way, using various methods of versioning, archiving, announcing and publishing the release. Understanding the release history of a software project can shed light on the project history, as well as the release process used by that project, and how those processes change. However, many factors make automating the retrieval of release history information difficult, such as the many sources of data, a lack of relevant standards and a disparity of tools used to create releases.

Alloy is a declarative modelling language based on first-order logic with sets and relations. Alloy formulas are checked for satisfiability by the fully automatic Alloy Analyzer. The analyzer, given an Alloy formula and a scope, i.e. a bound on the universe of discourse, searches for an instance i.e. a valuation to the sets and relations in the formula, such that it evaluates to true. The analyzer translates the Alloy problem to a propositional formula for which it searches a satisfying assignment via an off-the-shelf propositional satisfiability (SAT) solver. The SAT solver performs an exhaustive search and increasing the scope leads to the combinatorial explosion problem. We envision annotations, a meta-data facility used in imperative languages, as a means of augmenting Alloy models to enable more efficient analysis by specifying the priority, i.e. order of solving, of a given constraint and the slover to be used. This additional information would enable using the solutions to a particular constraint as partial solutions to the next in case constraint priority is specified and using a specific solver for reasoning about a given constraint in case a constraint solver is specified.

The definitive version can be found at : http://onlinelibrary.wiley.com/ Copyright Wiley [Full text of this article is not available in the UHRA]

We present a novel approach to optimize incremental scope-bounded checking of programs using a relational constraint solver. Given a program and its correctness specification, scope-bounded checking encodes control-flow and data-flow of bounded code segments into declarative formulas and uses constraint solvers to search for correctness violations. For non-trivial programs, the formulas are often complex and represent a heavy workload that can choke the solvers. To scale scope-bounded checking, our previous work introduced an incremental approach that uses the program's control-flow as a basis of partitioning the program and generating several sub-formulas, which represent simpler problem instances for the underlying solvers. This paper introduces a new approach that uses the program's dataflow, specifically variable-definitions, as a basis for incremental checking. Experimental results show that the use of data-flow provides a significant reduction in the number of variables in the encoded formulas over the previous control-flow-based approach, thereby further improving scalability of scopebounded checking.

Parallel changes are becoming increasingly prevalent in the development of large scale software system. To further study the relationship between parallel changes and faults, we have designed and implemented a semantic conflict analyzer (SCA) to detect semantic interference between parallel changes. SCA combines data dependency analysis and program slicing. Data dependency analysis can disclose the semantic structure of the program. And program slicing can identify which semantic structures are impacted by a change. By comparing the overlap between impacts of two changes, SCA can detect if there are semantic interference between the two changes. An experiment with an industrial project shows that SCA can detect a significant portion of the faults in highly parallel changes. SCA is effective in predicting faults (based on "direct" semantic interference detection) in changes made within a short time period. SCA is both efficient (averaging less than two minutes) and scalable (requiring only the local context)

Conventional data networks are based on layered architectures. The introduction of wireless networks has created a need to violate this layering discipline to create cross- layer designs or adaptations. Ad-hoc implementations of such cross-layer adaptations reduce the level of modularity and abstraction in the network's implementation, giving rise to a significant increase in complexity. We present a taxonomy of possible cross-layer adaptations that is then used to derive an architecture for their implementation that significantly preserves the networks structure. We present implementation results that validate this architecture in the context of a real wireless network implementation.

Parallel developments are becoming increasingly prevalent in the building and evolution of large-scale software systems. Our previous studies of a large industrial project showed that there was a linear correlation between the degree of parallelism and the likelihood of defects in the changes. To further study the relationship between parallel changes and faults, we have designed and implemented an algorithm to detect "direct" semantic interference between parallel changes. To evaluate the analyzer's effectiveness in fault prediction, we designed an experiment in the context of an industrial project. We first mine the change and version management repositories to find sample versions sets of different degrees of parallelism. We investigate the interference between the versions with our analyzer. We then mine the change and version repositories to find out what faults were discovered subsequent to the analyzed interfering versions. We use the match rate between semantic interference and faults to evaluate the effectiveness of the analyzer in predicting faults. Our contributions in this evaluative empirical study are twofold. First, we evaluate the semantic interference analyzer and show that it is effective in predicting faults (based on "direct" semantic interference detection) in changes made within a short time period. Second, the design of our experiment is itself a significant contribution and exemplifies how to mine software repositories rather than use artificial cases for rigorous experimental evaluations.

Use case diagrams (UCDs) are widely used to describe requirements and desired functionality of software products. However, UCDs are loosely linked to source code, and maintaining traces between the source code and elements of UCDs is a manual, tedious, and laborious process. These traces help programmers to understand code that they maintain and evolve.

Even though there has been some research on system evolution, there is no well defined vocabulary to indicate deviation of a system from desired goals. Further, there are no objective measures to indicate whether changes incorporated into a system as part of its evolution violates the integrity of the architectural design. Also, little research has been done to categorize the aspects of a software system that is subject to deviation as the system evolves. In this paper we develop a model for tracking software evolution and propose measures that will objectively indicate the extent of deviation or divergence in a software system. We also categorize the different aspects of software, changes to which can significantly impact usability as well as conceptual coherence.

The topic of this full-day tutorial was the correct use and interpretation of case studies as an empirical research method. Using an equal blend of lecture and discussion, it gave attendees a foundation for conducting, reviewing, and reading case studies. There were lessons for software engineers as researchers who conduct and report case studies, reviewers who evaluate papers, and practitioners who are attempting to apply results from papers. The main resource for the course was the book Case Study Research: Design and Methods by Robert K. Yin. This text was supplemented with positive and negative examples from the literature.

Monitoring is a task of collecting measurements that reflect the state of a system. Administration is a collection of tasks for control and manipulation of computer systems. Monitoring and Administering computer Resources (MARS) in a distributed grid computing environment (i.e. a distributed environment for coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations) is an important, expensive, and critical task. We present a novel solution based on applying crosscuts using binary rewriters and an event-based model that allows developers to create non-trivial MARS programs easily and uniformly. Our approach converts low-level API resource calls into system-wide events that MARS programs can monitor. This is accomplished by introducing advice that contains event-generating code at join points in programs that represent computer resources. We categorize low-level resource APIs by imposing a transactional metaphor to simplify the complexity of interactions between resources and to enable reasoning about MARS programs. We report both a case study and simulation that supports the viability of our approach.

Parallel changes are a basic fact of modern software development. Where previously we looked at prima facie interference, here we investigate a less direct form that we call semantic interference. We reduce the forms of semantic interference that we are interested in to overlapping defuse pairs. Using program slicing and data flow analysis, we present algorithms for detecting semantic interference for both concurrent changes (allowed in optimistic version management systems) and sequential parallel changes (supported in pessimistic version management systems), and for changes that are both immediate and distant in time. We provide these algorithms for changes that are additions, showing that interference caused by deletions can be detected by considering the two sets of changes in reverse-time order.

As software development becomes increasingly globally distributed, and more software functions are delegated to common open source software (OSS) and commercial off-the-shelf (COTS) components, practicing software engineers face significant challenges for which current software engineering curricula may leave them inadequately prepared. A new multi-faceted distributed development model is emerging that effectively commoditizes many development activities once considered integral to software engineering, while simultaneously requiring practitioners to apply engineering principles in new and often unfamiliar contexts. We discuss the challenges that software engineers face as a direct result of outsourcing and other distributed development approaches that are increasingly being utilized by industry, and some of the key ways we need to evolve software engineering curricula to address these challenges.

Software Product Lines (SPL), Component Based Software Engineering (CBSE) and Commercial Off The Shelf (COTS) components provide a rich supporting base for creating software architectures. Further, they promise significant improvements in the quality of software configurations that can be composed from pre-built components. Software architectural styles provide a way for achieving a desired coherence for such component-based architectures. This is because the different architectural styles enforce different quality attributes for a system. If the architectural style of an emergent system could be predicted in advance, a System Integrator could make necessary changes to ensure that the quality attributes dictated by the system requirements were satisfied before the actual system was deployed and tested. In this paper we propose a model for predicting architectural styles based on use cases that need to be met by a system configuration. Moreover, our technique can be used to determine stylistic conformance and hence indicate the presence or absence of architectural drift

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development, maintenance, and evolution. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes by focusing on the properties of the changes rather than the properties of the code itself. Our study reveals that 1) there is less than 4 percent probability that a one-line change introduces a fault in the code, 2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes, 3) nearly 50 percent of the changes were small changes, 4) nearly 40 percent of changes to fix faults resulted in further faults, 5) the phenomena of change differs for additions, deletions, and modifications as well as for the number of lines affected, and 6) deletions of up to 10 lines did not cause faults.

Building systems from existing applications written in two or more languages is common practice. Such systems are polylingual. Polylingual systems are relatively easy to build when the number of APIs needed to achieve language interoperability is small. However, when the number of distinct APIs become large, maintaining and evolving polylingual systems becomes a notoriously difficult task. In this paper, we present a simple, practical, and effective way to develop, maintain, and evolve large-scale polylingual systems. Our approach relies on recursive type systems whose instances can be manipulated by reflection. Foreign objects (i.e. objects that are not defined in a host programming language) are abstracted as graphs and path expressions are used for accessing and manipulating data. Path expressions are implemented by type reification - turning foreign type instances into first-class objects and enabling access to and manipulation of them in a host programming language. Doing this results in multiple benefits, including coding simplicity and uniformity that we demonstrate in a complex commercial project.

The topic of this paper was the correct use and interpretation of case studies as an empirical research method. Using an equal blend of lecture and discussion, it gave a foundation for conducting, reviewing, and reading case studies. There were lessons for software engineers as researchers who conduct and report case studies, reviewers who evaluate papers, and practitioners who are attempting to apply results from papers. The main resource for the course was the book Case Study Research: Design and Methods by Robert K. Yin. This text was supplemented with positive and negative examples from the literature.

No abstract available.

We have found that, when software is developed by multiple, geographically separated teams, the cost-benefit trade-offs of software inspection change. In particular, this situation can significantly lengthen the inspection interval (calendar time needed to complete an inspection). Our research goal was to find a way to reduce the inspection interval without reducing inspection effectiveness. We believed that Internet technology offered some potential solutions, but we were not sure which technology to use nor what effects it would have on effectiveness. To conduct this research, we drew on the results of several empirical studies we had previously performed. These results clarified the role that meetings and individuals play in inspection effectiveness and interval. We conducted further studies showing that manual inspections without meetings were just as effective as manual inspections with them. On the basis of these and other findings and our understanding of Internet technology, we built an economical and effective tool that reduced the interval without reducing effectiveness. This tool, Hypercode, supports meetingless software inspections with geographically distributed reviewers. HyperCode is a platform-independent tool, developed on top of an Internet browser, that integrates seamlessly into the current development process. By seamless, we mean the tool produces a paper flow that is almost identical to the current inspection process. HyperCode's acceptance by its user community has been excellent. Moreover, we estimate that using HyperCode has reduced the inspection interval by 20 to 25 percent. We believe that, had we focused solely on technology (without considering the information our studies had uncovered), we would have created a more complex, but not necessarily more effective tool. We probably would have supported group meetings, restricted each participant's access to review comments, and supported a wider variety of inspection methods. In other words, the principles derived from our empirical studies dramatically and successfully directed our search for a technological solution.

An essential characteristic of large-scale software development is parallel development by teams of developers. How this parallel development is structured and supported has a profound effect on both the quality and timeliness of the product. We conduct an observational case study in which we collect and analyze the change and configuration management history of a legacy system to delineate the boundaries of, and to understand the nature of, the problems encountered in parallel development. The results of our studies are (1) that the degree of parallelism is very highhigher than considered by tool builders; (2) there are multiple levels of parallelism, and the data for some important aspects are uniform and consistent for all levels; (3) the tails of the distributions are long, indicating the tail, rather than the mean, must receive serious attention in providing solutions for these problems; and (4) there is a significant correlation between the degree of parallel work on a given component and the number of quality problems it has. Thus, the results of this study are important both for tool builders and for process and project engineers.

There are three interdependent factors that drive our software development processes: interval, quality and cost. As market pressures continue to demand new features ever more rapidly, the challenge is to meet those demands while increasing, or at least not sacrificing, quality. One advantage of defect prevention as an upstream quality improvement practice is the beneficial effect it can have on interval: higher quality early in the process results in fewer defects to be found and repaired in the later parts of the process, thus causing an indirect interval reduction.

Separation of concerns has been central to software engineering for decades, yet its many advantages are still not fully realized. A key reason is that traditional modularization mechanisms do not allow simultaneous decomposition according to multiple kinds of (overlapping and interacting) concerns. This workshop was intended to bring together researchers working on more advanced modularization mechanisms, and practitioners who have experienced the need for them, as a step towards a common understanding of the issues, problems and research challenges.

ncreasing levels of software reuse constitute one of the most pervasive and profound influences in software engineering today. Technological innovations (e.g., objectoriented languages, distributed object models, domain specific languages) and process innovations (e.g., domain modeling, architectural analysis, reuse metrics) are enabling organizations to meet ever-more stringent cost, quality, and interval requirements. Furthermore, there is actually now a reuse market-place: One can literally buy class libraries, frameworks, and components out of catalogues. The Fifth International Conference on Software Reuse that was held in Victoria, B.C., Canada, included papers, mini-workshops, panels, and tutorials dedicated to various aspects of the software reuse enterprise, including objectorientation, domain modeling, domain specific languages, software architecture, and reuse over the internet. Out of the 31 papers (selected from 96 submissions) that were presented, a select few were nominated by the program committee as representing special, innovative contributions. These were subjected a special rereview and two were selected for this special issue. These two papers represent two of the major technological approaches to software reuse: generative/transformational reuse, and object-oriented reuse. The first paper, by Batory, Chen, Robertson, and Wang, considers the problem of selecting the best realizations and algorithms for a general purpose data structure, a container [1]. There are several different implementation choices for such a data structure: linked lists, hash tables, binary trees, etc. Some of these can also be used in conjunction on the same container data structure to provide multiple access modes. Containers can also be concurrent, persistent, secure, and so on. Each of these feature combinations offers specific performance characteristics suitable for specific usage profiles. Selecting the specific combinations of implementation features, given a particular workload, involves the application of specialized design knowledge. The Batory et al. paper describes a framework that encapsulates this design knowledge into a design wizard. This design wizard helps a programmer select a particular combination of container implementation features tailored to a specific application and usage profile. Once a feature set has been selected, code that implements that specific feature combination is generated after applicable optimizations have been performed. As reuse libraries become larger, more feature-rich, and complex, the design choices involved in using them become more difficult; Biggerstaff has called this the “library scaling problem” [4]. The wizard approach of Batory et al. is an important step toward ameliorating this problem. The second paper, by Maruyama and Shima, is concerned with the problem of adapting class libraries for specific requirements. The authors note that OO reuse typically involves two phases: finding a related class, and modifying it to suit the new requirements. They further observe that during the modification phase, developers make heavy use of change precedents: What types of changes have been made before in similar contexts. The modification phase, then, can be viewed as a process of integrating change precedents. They seek to provide automated support for this activity. Changes made to class libraries are stored in change histories. Using their tools involves several steps: Identify a candidate class for adaptation, then identify change precedents, and, finally, integrate change precedents into the candidate class. Their approach is based on [2] and makes use of program slicing, dependence graph, and graph matching. Maruyama and Shima’s work can be viewed as a way to systematically capture and replay typical modifications and extensions that occur during the evolution of object-oriented systems. Some of the early stirrings of software reuse can be traced back to 1958 [1], with the introduction of separate compilation of subroutines in Fortran II, and the increasing use of Fortran subroutine libraries in scientific computation over the following years. There has been dramatic progress since then in languages, component models, transformational techniques, reuse metrics, and processes. The papers in this special section, and those in the Proceedings of the Fifth International Conference of Software Reuse contain important, intriguing ideas that will sustain the progress of software reuse research. We invite you to join in this exciting endeavor.

THE importance of exception handling is well-recognized by system designers and software engineers. Exception handing is very often the most important part of the system because it deals with abnormal situations. The goal of

1 THE ARTICLES THE second part of this special issue on Current Trends in Exception Handling includes four papers which primarily deal with exception handling in human-centered systems such as workflow, requirements specification, and new interactive programming models such as spreadsheets. These research contributions demonstrate that exceptions are not restricted to programming languages, but occur in many, if not most, real-world situations. These papers also reflect that exceptions can be deviations from normal conditions and may not necessarily imply errors. This is similar to Goodenough's observations in his classic paper in the 1970s [1]. These papers lead us to observe that anything that has an algorithmic flow, whether it be workflow or a design process or a program, has a pervasive exception handling need. Programming may be the ultimate in an algorithm, so many of the problems encountered there have analogies in other areas. Moreover, the computation model presented by programming languages tends to be relatively more simple in regard to handling of exceptions in contrast to dealing with such problems in large-scale systems such as enterprise-wide workflow. In those environments, it is not simply exception handling language constructs that are needed, but a methodology on how to use exception handling. The programming model of spreadsheet systems raises many unique issues related to exception handling. This is a widely used model of programming by end users through the use of many commercial products. In the paper aException Handling in the Spreadsheet Paradigm,o Margaret Burnett, Anurag Agrawal, and Pieter van Zee discuss these issues and present an approach for handling exceptions in this programming paradigm. Many spreadsheet programs can be quite large and complex and, therefore, both reliability as well maintainability of such programs becomes an issue when exception handling is introduced. The authors present their experience with and analysis of the error value models for spreadsheet programs. Achieving a high level of fault tolerance is one of the main concerns in developing modern workflow systems due to many factors: Distributed environment, long duration of activities, and complexity of the software involved are among them. The paper aException Handling in Workflow Management Systemso by Clause Hagen and Gustavo Alonso describes an advanced fault tolerance mechanism for incorporating both transactions and exception handling into such systems. The approach is unique for workflow systems as it treats workflow support as a programming environment and relies on general research on developing fault-tolerant software. The authors use fundamental research on linguistic issues of exception handling and propose simple ways of applying these concepts to transactional workflow management. The modeling language incorporates special features for error detection and handling which are conceptually similar to exception handling features found in programming languages. Another important way in which this approach is new is how it combines transaction atomicity and exception handling. A validation technique is developed to make it possible to assess the correctness of workflow specification in situations when exceptions are raised and handled. In the paper aHandling of Irregularities in Human Centered Systems: A Unified Framework for Data Processes,o Takahiro Murata and Alex Borgida address exception handling problems in human-centered systems. In such systems, exception handling is required for dealing with errors, as well as deviations, in data as well as processes, from their normal constraints. The paper focuses on exception handling in enterprise workflow systems. Generally, in enterprise systems, process models are used for describing the dynamic nature of activities of humans and semi-automated system entities. Most often, such models do not capture many unanticipated deviations. Sometimes such deviations have to be corrected and other times they are to be tolerated. This paper presents a unified model for handling errors and deviations, which are treated as exception conditions resulting from violations of some specified constraints. When permitting deviations to persist, it relies on runtime checks for assessing their consequences. Axel van Lamsweerde and Emmanuel Letier address the issues of aHandling Obstacles in Goal-Oriented Requirements Engineering.o The requirements elicitation process often results in goals, requirements, and assumptions about the desired system that are too idealized and that do not take into account the various kinds of problems that can occur. Not anticipating exceptional behaviors results in unrealistic, unachievable, or incomplete requirements specifications. This, in turn, leads to systems that are not robust enough and which may fail at critical times, perhaps with critical consequences. The authors present formal techniques for IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 26, NO. 10, OCTOBER 2000 921

Geographically distributed development creates new questions about how to coordinate multi-site work. In this paper, we present four methods product development organizations used to coordinate their work: functional areas of expertise, product structure, process steps, and customization. We describe the benefits and difficulties with each model. Finally, we discuss two difficulties that occur irrespective of the model used: consequences of unequal distribution of project mass, and finding expertise.

Article Software evolution and "light" semantics (extended abstract) Share on Author: Dewayne E. Perry Bell Laboratories, 600 Mountain Ave., Murray Hill, NJ Bell Laboratories, 600 Mountain Ave., Murray Hill, NJView Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 587–590https://doi.org/10.1145/302405.302706Online:16 May 1999Publication History 3citation339DownloadsMetricsTotal Citations3Total Downloads339Last 12 Months1Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

An essential characteristic of large scale software development is parallel development by teams of developers. How this parallel development is structured and supported has a profound effect on both the quality and timeliness of the product. We conduct an observational case study in which me collect and analyze the change and configuration management history of a legacy system to delineate the boundaries of, and to understand the nature of, the problems encountered in parallel development. The results of our studies are: 1) that the degree of parallelism is very high-higher than considered by tool builders; 2) there are multiple levels of parallelism and the data for some important aspects are uniform and consistent for all levels and 3) the tails of the distributions are long, indicating the tail, rather than the mean, must receive serious attention in providing solutions for these problems.

In the context of a hypothesis attributing the slow progress in achieving major global software process improvement, in part, to overlooking the role of feedback in that process, the FEAST/1 project is studying the impact of feedback on software evolution. Amongst its activities the project is analysing metrics of the evolution of several industrial systems, ranging from a financial transaction system to a very large real time system. The similarities which have emerged from a comparison of evolution metrics from several systems, support conclusions reached in a 1970s study of OS/360 evolution. The latest results suggest some refinement of earlier conclusions but indicate that both the metrics and the conclusions derived from them must be taken into account in the planning and implementation of successful software maintenance. Papers discussing the FEAST/1 results may accessed via the FEAST web page [fwp98].

and the time savings from the reduction in distribution interval of the inspection package (sometimes involving international mailings) have been substantial.These savings together with the seamless integration into the existing environment are the major factors for this acceptance.From our viewpoint as experimentalists, the acceptance came too readily.Therefore we lost our opportunity to explore this tool using a series of controlled experiments to isolate the underlying factors or its effectiveness.Nevertheless, by using historical data we can show that the new process is less expensive in terms of cost and at least as effective in terms of quality (defect detection effectiveness).

Article Free AccessAn overview of the state of the art in software architecture Author: Dewayne E. Perry Bell Laboratories, Murray Hill, NJ Bell Laboratories, Murray Hill, NJView Profile Authors Info & Claims ICSE '97: Proceedings of the 19th international conference on Software engineeringMay 1997 Pages 590–591https://doi.org/10.1145/253228.253487Published:01 May 1997Publication History 10citation324DownloadsMetricsTotal Citations10Total Downloads324Last 12 Months6Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

No abstract available.

Software evolution is usually considered in terms of corrections, improvements and enhancements. While helpful, this approach does not take into account the fundamental dimensions of well-engineered software systems (the domains, experience, and process) and how they themselves evolve and affect the evolution of systems for which they are the context. I discuss each dimension, provide examples to illustrate its various aspects and summarize how evolution in that dimension affects system evolution. Only by taking this holistic approach to evolution can we understand evolution and effectively manage it.>

Features are often the basic unit of development for a very large software system and represent long-term efforts, spanning up to several years from inception to actual use. Developing an experiment to monitor (by means of sampling) such lengthy processes requires a great deal of care in order to minimize casts and to maximize benefits. Just as prototyping is often a necessary auxiliary step in a large-scale, long-term development effort, so, too, is prototyping a necessary step in the development of a large-scale, long-term process monitoring experiment. Therefore, we have prototyped our experiment using a representative process and reconstructed data from a large and rich feature development. This approach has yielded three interesting sets of results. First, we reconstructed a 30-month time diary for the lead engineer of a feature composed of both hardware and software. These data represent the daily state (where the lead engineer spent the majority of his time) for a complete cycle of the development process. Second, we found that we needed to modify our experimental design. Our initial set of states did not represent the data as well as we had hoped. This is exemplified by the fact that the "Other" category is too large. Finally, the data provide evidence for both a waterfall view and an interactive, cyclic view of software development. We conclude that the prototyping effort is a necessary part of developing and installing any large-scale process monitoring experiment.>

A general model of software development environments that consists of structures, mechanisms, and policies is presented. The advantage of this model is that it distinguishes intuitively those aspects of an environment that are useful in comparing and contrasting software development environments. Four classes of environments-the individual, the family, the city. and the state-are characterized by means of a sociological metaphor based on scale. The utility of the taxonomy is that it delineates the important classes of interactions among software developers and exposes the ways in which current software development environments inadequately support the development of large systems. The generality of the model is demonstrated by its application to a previously published taxonomy that categorizes environments according to how they relate to language-centered, structure-oriented, toolkit, and method-based environments.>

Infuse is an experimental software development environment focusing on change coordination during the maintenance/evolution phase of large-scale software projects. Its core philosophy is to integrate strongly connected modules first and more weakly connected sets of modules later, moving up a hierarchy from singletons to clusters of interdependent modules and, finally, merging the change set into the baseline. The use of Infuse is extended to dynamic consistency, i.e. testing. Unit testing is done for the individual modules at the leaves of the hierarchy, integration testing for the intermediate clusters and acceptance testing at the root. Infuse supports this by partially automating the construction of test harnesses and regression test suites at each level of the hierarchy from components available from lower levels. Infuse is implemented in C and is used to support its own evolution, but the implementation does not yet provide the test management described.>

The Inscape Environment is an integrated software development enviroment for building large software systems by large groups of developers. It provides tools that are knowledgeable about the process of system construction and evolution and that work in symbiosis with the system builders and evolvers. These tools are integrated around the constructive use of formal module interface specifications. We first discuss the problems that Inscape addresses, outline our research strategies and approaches to solving these problems, and summarize the contributions of the Inscape Environment. We then discuss the major aspects of the Inscape Environment: the specification language, system construction, system evolution, use and reuse, and validation. We illustrate these various components with examples and discussions. Keywords: Integrated Software Development Environment; Formal Module Interface Specifications; Practical use of Formal Methods; Semantic Interconnection Model; City Model; Static Sem...