Software projects are still facing with challenges of team coordination across global boundaries. Boundary spanner is an important organic coordination mechanism that is not much explored in GSD literature. This paper presents a finding from four case studies of how a boundary spanner resolve coordination gaps in organizationally distributed teams. The qualitative data were collected from 16 interviews from different types of global software projects. Boundary spanners have common characteristics of a coordinator, such as team member recognition, multiple perspective expertise, decision-making ability and work time flexibility. Task negotiation, conflict resolution, task information navigation and boundary object set-up are common activities to support team coordination. We also discussed a compound effect of other organizational roles and the impact of context factors on boundary spanner's activities.

Previous studies have shown that dependency cycles contain significant number of defects, defect-prone components and account for the most critical defects. Thereby, demonstrating the impacts of cycles on software reliability. This preliminary study investigates the variables in a cyclic dependency graph that relate most with the number of defect-prone components in such graphs so as to motivate and guide decisions for possible system refactoring. By using network analysis and statistical methods on cyclic graphs of Eclipse and Apache-Active MQ, we have examined the relationships between the size and distance measures of cyclic dependency graphs. The size of the cyclic graphs consistently correlates more with the defect-proneness of components in these systems than other measures. Showing that adding new components to and/or creating new dependencies within an existing cyclic dependency structures are stronger in increasing the likelihood of defect-proneness. Our next study will investigate whether there is a cause and effect between refactoring (breaking) cyclic dependencies and defect-proneness of affected components.

(Background) Defect distribution in software systems has been shown to follow the Pareto rule of 20-80. This motivates the prioritization of components with the majority of defects for testing activities. (Research goal) Are there significant variations between defective components and architectural hotspots identified by other defect measures? (Approach) We have performed a study using post-release data of an industrial Smart Grid application with a well-maintained defect tracking system. Using the Pareto principle, we identify and compare defect-prone and hotspots components based on four defect metrics. Furthermore, we validated the quantitative results against qualitative data from the developers. (Results) Our results show that at the top 25% of the measures 1) significant variations exist between the defective components identified by the different defect metrics and that some of the components persist as defective across releases 2) the top defective components based on number of defects could only identify about 40% of critical components in this system 3) other defect metrics identify about 30% additional critical components 4) additional quality challenges of a component could be identified by considering the pair wise intersection of the defect metrics. (Discussion and Conclusion) Since a set of critical components in the system is missed by using largest-first or smallest-first prioritization approaches, this study, therefore, makes a case for an all-inclusive metrics during defect model construction such as number of defects, defect density, defect severity and defect correction effort to make us better understand what comprises defect-prone components and architectural hotspots, especially in critical applications.

(Background) Software defects that most likely will turn into system and/or business failures are termed critical by most stakeholders. Thus, having some warnings of the most probable location of such critical defects in a software system is crucial. Software complexity (e.g. coupling) has long been established to be associated with the number of defects. However, what is really challenging is not in the number but identifying the most severe defects that impact reliability. (Research Goal) Do cyclic related components account for a clear majority of the critical defects in software systems? (Approach) We have empirically evaluated two non-trivial systems. One commercial Smart Grid system developed with C# and an open source messaging and integrated pattern server developed with Java. By using cycle metrics, we mined the components into cyclic-related and non-cyclic related groups. Lastly, we evaluated the statistical significance of critical defects and severe defect-prone components (SDCs) in both groups. (Results) In these two systems, results demonstrated convincingly, that components in cyclic relationships account for a significant and the most critical defects and SDCs. (Discussion and Conclusion) We further identified a segment of a system with cyclic complexity that consist almost all of the critical defects and SDCs that impact on system's reliability. Such critical defects and the affected components should be focused for increased testing and refactoring possibilities.

Effective team coordination is crucial for successful global software projects. Although considerable research effort has been made in this area, no agreement has been reached on the influence of dispersion on team coordination and performance. The objective of this paper is to summarize the evidence on the relationship among context dispersion, team coordination and performance in global software projects. We have performed a Systematic literature review (SLR) to collect relevant studies and a thematic analysis to synthesize the extracted data. We found 28 primary studies reporting the impact of five dispersion dimensions on team performance. Previously, only two primary studies considered and distinguished all of these dispersion dimensions in studying dispersed team performance. The dispersion dimensions affect team outcomes indirectly through influencing organic and mechanistic coordination processes. Empirical evidence show that geographical dispersion impacts negatively and temporal dispersion has a mixed effect on team performance. While studies with teams working across different time zones shows a tendency that the team performance is pessimistically perceived, studies that use direct measure on task performance shows a positive association to temporal dispersion. The paper provides implications for future research and practitioners in establishing effective distributed team coordination.

The number of scientific publications is constantly increasing, and the results published on Empirical Software Engineering are growing even faster. Some software engineering publishers have began to collaborate with research groups to make available repositories of software engineering empirical da

To estimate the corrective software maintenance effort, we must know the factors that have the strongest influence on corrective maintenance activities. In this study, we have analyzed activities and effort of correcting 810 software defects in one Norwegian software company and 577 software defects in another. We compared the defect profiles according to the defect correction effort. We also analyzed defect descriptions and recorded discussions between developers in the course of correcting defects in order to understand what led to the high cost of correcting some types of defects. The study shows that size and complexity of the software to be maintained, maintainers?' experience, and tool and process support are the most influential cost drivers of corrective maintenance in one company, while domain knowledge is one of the main cost drivers of corrective maintenance in the other company. This illustrates that models for estimating software corrective maintenance effort have to be customized based on the defect profiles and cost drivers of each company and project to be useful.

Abstract This paper reports on an industrial case study in a large Norwegian Oil and Gas company (StatoilHydro ASA) involving a reusable Java‐class framework and two applications that use that framework. We analyzed software changes from three releases of the reusable framework, called Java Enterprise Framework (JEF), and two applications reusing the framework, called Digital Cargo File (DCF) and Shipment and Allocation (S&A). On the basis of our analysis, we found the following: (1) Profiles of change types for the reused framework and the applications are similar, specifically, perfective changes dominate significantly. (2) Although on observing the mean value adaptive changes are more frequent and are active longer in JEF and S&A, these systems went through less refactoring than DCF. For DCF, we saw that preventive changes were more frequent and were active longer. (3) Finally, we found that designing for reuse seems to lead to a long‐term payoff in relation to non‐reusable software systems. Copyright © 2010 John Wiley & Sons, Ltd.

Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature on addressing software entropy, focussing on the detection of ldquocode smellsrdquo and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.

The effort that has been made to study risk management in the context of software architecture and its evolution, has so far focused on output from structured evaluations. However, earlier research shows that formal, structured evaluation is not commonly used in industry. We have performed a survey among software architects, in order to capture a more complete picture of the risk and management issues in software architecture evolution. Our survey is specifically about their current knowledge of actual challenges they have anticipated and experienced, as well as strategies they have employed in response. We received completely filled questionnaires from 82 respondents out of a total distribution of 511 architects from the software industry in Norway. While many of the risks we have identified can be aligned with results from earlier studies, we have also identified several risks which appear not to fit these risk categories. Additionally, we found a direct link to business risks, as well as a relatively low level of awareness that lack of software architecture evaluation represents a potential risk.

Component-Based Software Engineering (CBSE) with Open Source Software and Commercial-Off-the-Shelf (COTS) components, Open Source Software (OSS) based development, and Software Outsourcing (SO) are becoming increasingly important for the Chinese software industry. It is therefore necessary to establish pragmatic and possibly nation-specific guidelines for Chinese software companies regarding the use of CBSE, OSS, and SO. Such guidelines should be based on insights from actual practice, which are in our case, obtained through surveys. A European state-of-the-practice survey on COTS- and OSS-oriented CBSE was conducted in Germany, Italy, and Norway in 2004-2005. We repeated similar surveys in China, with an extended survey on OSS and SO. We encountered many difficulties in conducting the surveys, but in most cases managed to find working solutions. We report on the lessons learned while conducting these surveys. In particular, we address issues relating to sampling, contacting respondents, data collection, and data validation. The main lessons are: 1) it was necessary to cooperate with a third-party organization with close relations to Chinese software companies; 2) it was necessary to assign researchers to this third-party organization to facilitate data collection and to control the quality of the data collected; and 3) an email survey, after an initial telephone call to establish contact, was the best method for getting questionnaires completed by Chinese respondents.

Test driven development (TDD) is a software engineering technique to promote fast feedback, task-oriented development, improved quality assurance and more comprehensible low-level software design. Benefits have been shown for non-reusable software development in terms of improved quality (e.g. lower defect density). We have carried out an empirical study of a framework of reusable components, to see whether these benefits can be shown for reusable components. The framework is used in building new applications and provides services to these applications during runtime. The three first versions of this framework were developed using traditional test-last development, while for the two latest versions TDD was used. Our results show benefits in terms of reduced mean defect density (35.86%), when using TDD, over two releases. Mean change density was 76.19% lower for TDD than for test-last development. Finally, the change distribution for the TDD approach was 33.3% perfective, 5.6% adaptive and 61.1% preventive.

Background . This article describes a case study on the benefits of software reuse in a large telecom product. The reused components were developed in-house and shared in a product-family approach. Methods . Quantitative data mined from company repositories are combined with other quantitative data and qualitative observations. Results . We observed significantly lower fault density and less modified code between successive releases of the reused components. Reuse and standardization of software architecture and processes allowed easier transfer of development when organizational changes happened. Conclusions . The study adds to the evidence of quality benefits of large-scale reuse programs and explores organizational motivations and outcomes.

An international survey on risk management in software development with off-the-shelf (OTS) components is reported upon and discussed. The survey investigated actual risk-management activities and their correlations with the occurrences of typical risks in OTS component-based development. Data from 133 software projects in Norway, Italy, and Germany were collected using a stratified random sample of IT companies. The results show that OTS components normally do not contribute negatively to the quality of the software system as a whole, as is commonly expected. However, issues such as the underestimation of integration effort and inefficient debugging remain problematic and require further investigation. The results also illustrate several promising effective risk-reduction activities, e.g., putting more effort into learning relevant OTS components, integrating unfamiliar components first, thoroughly evaluating the quality of candidate OTS components, and regularly monitoring the support capability of OTS providers. Five hypotheses are proposed regarding these risk-reduction activities. The results also indicate that several other factors, such as project, cultural, and human-social factors, have to be investigated to thoroughly deal with the possible risks of OTS-based projects.

The business relationship between a software outsourcer and its suppliers is gradually moving from contract relationship to partnership. The partnership type between the outsourcer and the supplier is considered as a key predictor of outsourcing success. Although several studies have investigated the practices and benefits of building partnership from an outsourcer's perspective, few of them have studied these issues from the supplier's viewpoint, especially in the context of offshore software outsourcing. Since more and more Chinese software companies are getting outsourcing subcontracts from abroad, it is important to investigate the effect of business relationship on their performance, and to identify possible enhancements. Our study has collected data by a questionnaire-based survey from 53 finished projects in 41 Chinese software suppliers. Twenty-six of our investigated suppliers claim to have contract relationship with their outsourcers and the remaining 27 think they have partnership with outsourcers. Results from our study show, however, that 1) processes and methods used by suppliers to solve conflicts with outsourcers do not follow their self-claimed contract relationships or partnership; 2) there is no significant correlations between the type of relationship and the success of outsourced projects; 3) more personnel with proper language and communication skills need to be educated in order to facilitate Chinese companies to build and maintain a proper partnership with their outsourcers.

The benefits of reusing software components have been studied for many years. Several previous studies have concluded that reused components have fewer defects in general than non-reusable components. However, few of these studies have gone a further step, i.e., investigating which type of defects has been reduced because of reuse. Thus, it is suspected that making a software component reusable will automatically improve its quality. This paper presents an on-going industrial empirical study on the quality benefits of reuse. We are going to compare the defects types, which are classified by ODC (Orthogonal Defect Classification), of the reusable component vs. the non-reusable components in several large and medium software systems. The intention is to figure out which defects have been reduced because of reuse and the reasons of the reduction.

Component-based software development (CBSD) is becoming more and more important since it promotes reuse to higher levels of abstraction. As a consequence, many components are available being either open-source software (OSS) or commercial-off-the-shelf (COTS). However, it is still unclear how the decision for acquiring OSS or COTS components is made in practice. This paper describes an empirical study on why project decision-makers selected COTS instead of OSS components, or vice versa. The study was performed as an international survey in Norway, Italy and Germany. It focused on decision making on using off-the-shelf (OTS) components. We have gathered answers from 83 projects using only COTS components and 44 projects using only OSS components. Results of this study show significant differences and commonalities of integrating OSS or COTS components. Moreover, the study illustrates several research questions that warrant future research.

This paper describes the results of analyzing change requests from 4 releases of a set of reusable components developed by a large Oil and Gas company in Norway, Statoil ASA. These components are total 20348 SLOC (Source Lines of Code), and have been programmed in Java. Change requests in our study cover any change in the requirements. We have investigated the distribution of change requests over the categories perfective, adaptive and preventive changes that characterize aspects of software maintenance and evolution. In total there are 208 combined perfective, adaptive and preventive changes. The results reveal that 59% of changes are perfective, 27% of changes are adaptive and 14% of changes are preventive. The corrective changes (223 in total) are excluded in this paper, since they will be analyzed in future work. We have also investigated the relation between customers' and developers' priority on change requests and found no significant difference between customer and developers' priority of change requests. Larger components had more change requests as expected and priority level of change requests increases with component size. The results are important in that they characterize and explain the changes to components. This is an indication as to which components require more effort and resources in managing software changes at Statoil ASA.

This paper describes an industrial study of an effort estimation method based on use cases, the Use Case Points method. The original method was adapted to incremental development and evaluated on a large industrial system with modification of software from the previous release. We modified the following elements of the original method: a) complexity assessment of actors and use cases, and b) the handling of non-functional requirements and team factors that may affect effort. For incremental development, we added two elements to the method: c) counting both all and the modified actors and transactions of use cases, and d) effort estimation for secondary changes of software not reflected in use cases. We finally extended the method to: e) cover all development effort in a very large project. The method was calibrated using data from one release and it produced an estimate for the successive release that was only 17% lower than the actual effort. The study identified factors affecting effort on large projects with incremental development. It also showed how these factors can be calibrated for a specific context and produce relatively accurate estimates.

Software Configuration Management (SCM) is an important discipline in professional software development and maintenance. The importance of SCM has increased as programs have become larger, more long lasting, and more mission and life critical. This article discusses the evolution of SCM technology from the early days of software development to the present, with a particular emphasis on the impact that university and industrial research has had along the way. Based on an analysis of the publication history and evolution in functionality of the available SCM systems, we trace the critical ideas in the field from their early inception to their eventual maturation in commercially and freely available SCM systems. In doing so, this article creates a detailed record of the critical value of SCM research and illustrates how research results have shaped the functionality of today's SCM systems.

The paper describes results of an empirical study, where some hypotheses about the impact of reuse on defect-density and stability, and about the impact of component size on defects and defect-density in the context of reuse are assessed, using historical data (data mining) on defects, modification rate, and software size of a large-scale telecom system developed by Ericsson. The analysis showed that reused components have lower defect-density than non-reused ones. Reused components have more defects with highest severity than the total distribution, but less defects after delivery, which shows that that these are given higher priority to fix. There are an increasing number of defects with component size for non-reused components, but not for reused components. Reused components were less modified (more stable) than non-reused ones between successive releases, even if reused components must incorporate evolving requirements from several application products. The study furthermore revealed inconsistencies and weaknesses in the existing defect reporting system, by analyzing data that was hardly treated systematically before.

This paper presents a concurrent object model based on distributed recursive sets for data intensive applications that use complex, recursive data layouts. The set abstraction is used to represent irregular (recursive) data layouts. The distributed set abstraction is used to transparently distribute large data across multiple address spaces. We effectively map data to processors by using information about data accesses to preserve locality. This results in a consistency scheme with small communication requirements. The programming model is easy to use since the system automatically does the data distribution, mapping and consistency.

Many software engineering courses include all-term projects to convey principles relating to large-scale multi-person development. But even such projects will easily be too small and simple, unless a sufficient amount of study time is allocated to them. This time may be hard to find, especially in strictly programmed profession studies where a lot of general theory courses have to be taken. This paper reports on the experiences from a software engineering project where the solution to the above problem has been to have several courses share one project. This had some advantages. First of all, it allows time for a bigger and more complex project with reasonable sacrifices of "own time" in each of the participating courses. Equally important, it is possible to show connections between the courses. In spite of these advantages, there have also been problems with the project, still leaving room for improvement.

This paper proposes a data parallel programming model suitable for loosely synchronous, irregular applications. At the core of the model are distributed objects that express non-trivial data parallelism. Sequential objects express independent computations. The goal is to use objects to fold synchronization into data accesses and thus, free the user from concurrency aspects. Distributed objects encapsulate large data partitioned across multiple address spaces. The system classifies accesses to distributed objects as read and write. Furthermore, it uses the access patterns to maintain information about dependences across partitions. The system guarantees inter-object consistency using a relaxed update scheme. Typical access patterns uncover dependences for data on the border between partitions. Experimental results show that this approach is highly usable and efficient.

Software configuration management (SCM) is an important discipline in professional software development and maintenance. The importance of SCM has increased as programs have become larger, more complex, and more mission/life-critical. This paper presents a brief summary of a full report that discusses the evolution of SCM technology from the early days of software development to present, and the specific impact university and industrial research has had along the way.

This article examines the literature on case studies of knowledge management systems in use in organisations that develop software. We investigate knowledge management approaches in eight case studies, and what the reported benefits are. Surprisingly, very few organisations claim to have lowered software production costs or increased the quality of the software. But many claim to have improved the work situation for software developers and managers.

Most quality and software process improvement frameworks emphasize written (i.e. formal) documentation to convey recommended work practices. However, there is considerable skepticism among developers to learn from and adhere to prescribed process models. The latter are often perceived as overly "structured" or implying too much "control". Further, what is relevant knowledge has often been decided by "others"---often the quality manager. The study was carried out in the context of a national software process improvement program in Norway for small- and medium-sized companies to assess the attitude to formalized knowledge and experience sources. The results show that developers are rather skeptical at using written routines, while quality and technical managers are taking this for granted. This is an explosive combination. The conclusion is that formal routines must be supplemented by collaborative, social processes to promote effective dissemination and organizational learning. Trying to force a (well-intended) quality system down the developers' throats is both futile and demoralizing. The wider implications for quality and improvement work is that we must strike a balance between the "disciplined" or "rational" and the "creative" way of working.

Version management is a key part of software configuration management. A big variety of version models has been realized in both commercial systems and research prototypes. These version models differ with respect to the objects put under version control (files, directories, entities, objects), the organization of versions (version graphs versus multidimensional version spaces), the granularity of versioning (whole software products versus individual components), emphasis on states versus emphasis on changes (state-versus change-based versioning), rules for version selection, etc. We present a uniform version model-and its support architecture-for software configuration management. Unlike other unification approaches, such as UML for object-oriented modeling, we do not assemble all the concepts having been introduced in previous systems. Instead, we define a base model that is built on a small number of concepts. Specific version models may be expressed in terms of this base model. Our approach to uniform version management is distinguished by its underlying layered architecture. Unlike the main stream of software configuration management systems, our instrumentable version engine is completely orthogonal to the data model used for representing software objects and their relationships. In addition, we introduce version rules at the bottom of the layered architecture and employ them as a uniform mechanism for expressing different version models. This contrasts to the main stream solution, where a specific version model-usually version graphs-is deeply built into the system and version rules are dependent on this model.

Introduction Knowledge management by experience databases (EXDBs) is gradually getting into use. This applies e.g. for banking, oil production and ship building, as well as for software engineering. The goal is to create and sustain a learning organization, where the bottom-line criterion is satisfied customers in the spirit of TQM or ISO-9000. 2 Some useful definitions Knowledge is use of facts, truths or principles from studies or investigations. That is, the available information must be made operational for ("learned" by) the person or group in question. Thus, information is not automatically knowledge. Explicit knowledge is what can be formalized, e.g. as process models or guidelines in a quality system. Tacit knowledge is the operational skills among practitioners, including practical judgement capabilities (e.g. intuition). We can also distinguish between ease of transfer of local vs. global knowledge, and between ease of use of programmable (often explicit) vs. unique (o

The ability to handle changes is a characteristic feature of successful software projects. The problem addressed in this paper is what should be done in project planning and iterative replanning so that the project can react effectively to changes. Thus the work presents research results in software engineering, as well as transfer of methods in knowledge engineering to software engineering, applying the AI planning technique to software process modeling and software project management. Our method is based on inter-project experience and evolution patterns. We propose a new classification of software projects, identifying and characterizing ten software process evolution patterns and link them to different project profile. Based on the evolution patterns, we discuss the planning support for process evolution and propose several methods that are new or significantly extend existing work, e.g. cost estimation of process changes, evolution pattern analysis, and a coarse process model for the initial planning and the iterative replanning process. The preliminary results have shown that the study of evolution patterns, based on inter-project experience, can provide valuable guidance in software process understanding and improvement.

No abstract available.

This paper presents a case study of Norwegian banking software house where the objective is to adopt a categorization framework for managing evolution in software projects to identify project profiles and evolution patterns, and to suggest improvements to better support frequent evolutions.Based on an analysis of collected evolution data from an ongoing case study, we elaborate a QIP-inspired method and own techniques to evolve corresponding process models in our Process-centered Software Engineering Environment, called EPOS.The method describes also how to synthesize and reuse evolution experience from completed projects to improve planning and estimation in new similar projects.The collected data demonstrates that requirement changes which are detected in later development phases, are major causes for cost overruns in the studied organization.

Process-centered software engineering environments (PSEEs) are the most recent generation of environments supporting software development activities. They exploit an representation of the process (called the process model that specifies how to carry out software development activities, the roles and tasks of software developers, and how to use and control software development tools. A process model is therefore a vehicle to better understand and communicate the process. If it is expressed in a formal notation, it can be used to support a variety of activities such as process analysis, process simulation, and process enactment. PSEEs provide automatic support for these activities. They exploit languages based on different paradigms, such as Petri nets and rule-based systems. They include facilities to edit and analyze process models. By enacting the process model, a PSEE provides a variety of services, such as assistance for software developers, automation of routine tasks, invocation and control of software development tools, and enforcement of mandatory rules and practices. Several PSEEs have been developed, both as research projects and as commercial products. The initial deployment and exploitation of this technology have made it possible to produce a significant amount of experiences, comments, evaluations, and feedback. We still lack, however, consistent and comprehensive assessment methods that can be used to collect and organize this information. This article aims at contributing to the definition of such methods, by providing a systematic comparison grid and by accomplishing an initial evaluation of the state of the art in the field. This evaluation takes into account the systems that have been developed by the authors in the past five years, as well as the main characteristics of other well-known environments

The authors categorize some aspects of software process evolution and customization, and describe how they are handled in the EPOS PM system. Comparisons are made to other PM systems. A process model in EPOS consists of a schema of classes and meta-classes, and its model entities and relationships. There is an underlying software engineering database, EPOSDB, offering uniform versioning of all model parts and a context of nested cooperating transactions. Then, there is a reflective object-oriented process specification language, on top of the EPOSDB. Policies for model creation, composition, change, instantiation, refinement, and enaction are explicitly represented and are used by a set of PM automatic tools. The main tools are a planner to instantiate tasks, an execution manager to enact such tasks, and a PM manager to define, analyze, customize, and evolve the process schema.>

Software process models are meant to describe software engineering activities around evolving software products. Process models need modifications due to gained experience, changed policies or project-specific requirements, and a set of versions of the original models must be maintained. Thus, software process models are evolving products and should be under the control of a configuration management (CM) system. EPOS models software processes in an object-oriented data model. Both process models and running instances are stored in a versioned database. EPOS software process models may be evolved and reused by the same CM techniques as used for software systems.>