Abstract Reversing an outsourcing decision and retaking control of the development and operations of IT systems can be a viable option for organizations facing outsourcing-related challenges, such as problematic vendor relationships, high costs, or the recognition of software development as a core competence. Despite its increasing practical importance, backsourcing has received little attention in the software engineering literature. This paper presents an in-depth case study of a large public organization that successfully backsourced the development of the majority of its large portfolio of software systems. Based on interviews with 61 representatives of the backsourcing organization and its vendors and an analysis of corporate documentation, we present the rationale for backsourcing, the six main guiding principles shaping the approach, and the outcomes and lessons learned from the initiative. The primary reason for backsourcing in the case organization was cost reduction. The IT department led the effort, granting various application areas considerable autonomy in the practical implementation of backsourcing. The effort was characterized by close and constructive collaboration with the outsourcing vendors, who were being phased out, an incremental approach to assuming responsibility for the applications, and the concurrent implementation of agile development at scale. Over three years, the organization successfully backsourced over 100 systems and established an agile development organization with over 300 people. As a result of backsourcing, the organization reported an increased sense of system ownership, increased personnel motivation, faster deliveries, and better quality-in-use. We were unable to find clear evidence of significant cost savings. Key challenges included managing the change effort, building and retaining the necessary competencies, and addressing organizational tensions resulting from the IT department’s central role in the backsourcing effort.

While agile software development is increasingly adopted in large organizations, there is still a lack of studies on how traditionally organized enterprises adopt and scale agile forms of organization. This industrial multiple embedded case study explores how the organizational model of a large public sector entity evolved over four years to support the adoption of agile software development methods. Data was collected through semi-structured interviews and document analysis. We describe the change in three phases: pre-transformation, initial transformation, and maturing. Changes in three subcases of organizational units are further described in detail. Moving from an outsourced project-based way-of-working with separate business, IT and vendor organizations, the new organizational design emphasizes internal development capability, cross-functional autonomous teams organized around products and grouped in product areas, and continuous delivery. Starting from the IT department, the transformation expanded to the whole organization, and went beyond software development to the finance and leadership. We describe the target and intermediate organizations employed when adopting agile development methods for the whole organization and three organizational units responsible for different services. Defining suitable product boundaries, achieving alignment across teams, enhancing the competence of product owners, the coexistence of old and new types of systems, processes, and structures, and balancing the teams’ need for autonomy with the organizational needs for coordination and control are remaining challenges.

Cloud computing is emerging as a major trend in the ICT industry. While most of the attention of the research community is focused on considering the perspective of the Cloud providers, offering mechanisms to support scaling of resources and interoperability and federation between Clouds, the perspective of developers and operators willing to choose the Cloud without being strictly bound to a specific solution is mostly neglected. We argue that Model-Driven Development can be helpful in this context as it would allow developers to design software systems in a cloud-agnostic way and to be supported by model transformation techniques into the process of instantiating the system into specific, possibly, multiple Clouds. The MODAClouds (MOdel-Driven Approach for the design and execution of applications on multiple Clouds) approach we present here is based on these principles and aims at supporting system developers and operators in exploiting multiple Clouds for the same system and in migrating (part of) their systems from Cloud to Cloud as needed. MODAClouds offers a quality-driven design, development and operation method and features a Decision Support System to enable risk analysis for the selection of Cloud providers and for the evaluation of the Cloud adoption impact on internal business processes. Furthermore, MODAClouds offers a run-time environment for observing the system under execution and for enabling a feedback loop with the design environment. This allows system developers to react to performance fluctuations and to re-deploy applications on different Clouds on the long term.

This paper presents on-going work in a research project on defining methodology and tools for model-driven migration of legacy applications to a service-oriented architecture with deployment in the cloud, i.e. the Service Cloud paradigm. We have performed a comprehensive state of the art analysis and present some findings here. In parallel, the two industrial participants in the project have specified their requirements and expectations regarding modernization of their applications. The SOA paradigm implies the breakdown of architecture into high-grain components providing business services. For taking advantage of the services of cloud computing technologies, the clients' architecture should be decomposed, decoupled and be made scalable. Also requirements regarding servers, data storage and security, networking and response time, business models and pricing should be projected. We present software engineering challenges related to these aspects and examples of these in the context of one of the industrial cases in the project.

Software companies must often make decisions about applying new software development methodologies, technologies or tools. Various evaluation methods have been proposed to support this decision making; from those that focus on values (especially monetary values) to the more exploratory ones, and also various types of empirical studies. One common challenge of any evaluation is to choose evaluation criteria. While there have been a growing number of published empirical studies evaluating different methodologies, few of them include rationale for selecting their evaluation criteria or metrics. Therefore they also have problems with explaining their results. This paper proposes an approach for identifying relevant evaluation criteria that is based on the concepts of (core) practices and promises of a methodology. A practice of a methodology is a new concept or technique or an improvement to established ones that is an essential part of the methodology and differentiates it from other methodologies. A promise is the expected positive impact of a practice. Evaluation criteria or metrics are selected in order to evaluate the promises of practices. The approach facilitates identifying relevant criteria for evaluation and describing the results, and thus improves the validity of empirical studies. It will also help developing a common research agenda when evaluating new methodologies and answering questions such as whether a methodology helps improving a quality attribute and how, what the differences are between two methodologies, and which studies are relevant when collecting evidence about a methodology. The proposed approach is applied on software reuse and model-driven engineering as examples based on the results of two literature surveys performed in these areas.

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.

In model-driven engineering (MDE), models are the prime artifacts, and developing high-quality systems depends on developing high-quality models and performing transformations that preserve quality or even improve it. This paper presents quality goals in MDE and states that the quality of models is affected by the quality of modeling languages, tools, modeling processes, the knowledge and experience of modelers, and the quality assurance techniques applied. The paper further presents related work on these factors and identifies pertinent research challenges. Some quality goals such as well-formedness and precision are especially important in MDE. Research on quality in MDE can promote adoption of MDE for complex system engineering.

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.

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.