Context: Software architecture documentation is used to communicate architectural knowledge. It is often difficult for document users to find all the architectural knowledge they need to do their tasks, and this results in wasted time and mistakes during development. Objective: In this paper we investigate how ontology-based documentation may support users in finding the architectural knowledge they need. Method: We executed a controlled experiment to test for differences in knowledge retrieval efficiency and effectiveness between two groups of master students that used two ontologies built from different understandings of the architectural knowledge needs of document users. Results: Use of the ontology built based on a better understanding of architectural knowledge needs was significantly more efficient or effective for retrieving part of the knowledge needed by document users. We analysed participants' search actions and identified which organisation of knowledge in the ontologies resulted in efficient and effective knowledge retrieval. Conclusion: We found that an improved understanding of knowledge needs allows for the construction of an ontology from which document users retrieve knowledge more efficiently and effectively. In some cases we found that the ontology support for knowledge needs had to be traded off against ontology design criteria.

Understanding the causes of architecture changes allows us to devise means to prevent architecture knowledge vaporization and architecture degeneration.But the causes are not always known, especially in open source software (OSS) development.This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications.Architecture information is communicated in development mailing lists of OSS projects.To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e., architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information.The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes.(3) more than 45% of architecture changes in both projects happened before the first stable version was released, which indicates that the architectures of the investigated OSS projects are relatively stable after the first stable release.

The causes of architecture changes can tell about why architecture changes, and this knowledge can be captured to prevent architecture knowledge vaporization and architecture degeneration. But the causes are not always known, especially in open source software (OSS) development. This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications. Architecture information is communicated in development mailing lists of OSS projects. To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e. architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information. The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes, and the causes of architecture changes are further classified to functional requirement, external quality requirement, and internal quality requirement using the coding techniques of grounded theory; (3) more than 45% of architecture changes in both projects happened before the first stable version was released.

Information technology (IT)-enabled financial services are typically delivered by a network of interdependent IT service providers. Such networks need information to resolve IT incidents in their delivered IT services. The objective of this research is to identify the set of information that needs to be visible within IT provider networks to effectively resolve IT incidents. To this end, we conducted an inductive case study in a network of nine interdependent IT service providers. We found that the required information is distributed over multiple technological stores, and operational IT staff in the network needs visibility over these technological stores. Operational staff also needs visibility over the social network of incident handling staff, given the tacit nature of the required information. We therefore premise that better information sharing and enhanced knowledge reuse in the service network has a positive impact on incident handling in IT service provider networks. The main contribution of this paper is a structured set of information types that positively impacts IT incident handling performance in the IT service network, packaged into a conceptual model. Copyright © 2014 John Wiley & Sons, Ltd.

Software documents are used to capture and communicate knowledge in software projects. It is important that this knowledge can be retrieved efficiently and effectively, to prevent wasted time and errors that negatively affect the quality of software. In this paper we investigate how software professionals search for knowledge in documentation. We studied the search behaviour of professionals in industry. Prior knowledge helps professionals to search software documents efficiently and effectively. However, it can also misguide professionals to an incomplete search.

Software architecture (SA) documentation provides a blueprint of a software-intensive system for the communication between stakeholders about the high-level design of the system. In open source software (OSS) development, a lack of SA documentation may hinder the use and further development of OSS, but how much "architecture" documentation is enough and appropriate is largely dependent on the contextual factors of development. In order to understand the state of the practice of SA documentation in OSS projects, we conducted a documentation-based survey to explore how SA is documented in OSS projects. Out of 2,000 OSS projects from four major OSS sources, we found that 108 projects have some SA documentation, which shows that the SA documentation is scarce in OSS development. We analyzed these 108 projects to understand what SA information has been documented and how they have been described. We have found that frequently-documented architectural information is model, system, and mission, natural language is the most frequently-used architectural language for specifying architectural information in OSS SA documents. The results also show that the likelihood that an OSS project will document SA is increased when more developers are involved in the project, and industry and research OSS projects are more likely to create SA documents than freelance projects.

A common collaboration structure in global software development (GSD) is clustering, wherein people tend to be closer to others with whom they share common characteristics. Clusters often create barriers in communication, coordination and expertise awareness between remote teams, restraining the development of transactive memory (TM). In order to overcome such barriers, the role of brokers has emerged. In this paper, we examine the role of brokers as facilitators in the development of transactive memory. We use social network theory to analyze the collaboration of an EU-funded project, where development teams come from different partners and different locations. Our results suggest that task-based clusters emerge and that project members who coordinate activities as well as those who contribute to the code development act as brokers. Our empirical evaluation shows that clustering has a negative effect on TM and that brokers can moderate that effect.

In large internal information technology (IT) organizations, multiple teams are often involved in handling incidents, so these teams come to depend on one another. We hypothesize that the knowledge these teams have of the agreed upon and realized incident handling performance of themselves and other teams will impact their performance. We tested this hypothesis at a large financial institute, using log data from the IT service management application and a survey to measure the knowledge of teams. We found (1) a significant positive correlation between incident handling performance of a team and the knowledge a team has of its own performance; (2) no correlation between the knowledge of agreed upon performance and realized performance within a team; (3) that teams have very little knowledge of agreed upon or realized performance of other teams; and (4) that improving the knowledge a team has of the agreed upon and realized performance of that team and dependent teams results in higher incident handling performance. The results show that increasing information visibility within and across teams in large IT providers is one way to improve incident handling performance. Copyright © 2014 John Wiley & Sons, Ltd.

Communities of developers have rapidly become global, encompassing multiple timezones and cultures alike. In previous work we investigated the possible shapes of communities for software development. In addition, we explored mechanisms to uncover communities emerging during development. However, we barely scratched the surface. We found that development communities yield properties of dynamic change and organic evolution. Much work is still needed to support such communities with mechanisms able to proactively react to community dynamism. We argue that service-networks can be used to deliver this support. Service-networks are sets of people and information brought together by the internet. This paper is a first attempt at studying this research area by means of a real-life case-study in a large global software development organisation.

In industrial settings, multiple service teams are often involved in handling incidents, so these service teams come to depend on one another. We hypothesize that the knowledge these service teams have of the agreed upon and realized incident handling performance of themselves and other service teams will impact their performance. We tested this hypothesis at a large financial institute, using log data from the IT service management tool and a survey to measure the knowledge of service teams. We found a significant positive correlation between incident handling performance of a service team and the knowledge a service team has of its own performance. We found no correlation between the knowledge of agreed upon performance and realized performance within a service team. Finally, we found that teams have very little knowledge of agreed upon or realized performance of other service teams. The results suggest that increasing performance visibility within and across teams is one way to help improve performance.

SUMMARY The architect of a large, evolving system may wish to revise its decomposition from time to time; for instance, because the structure has deteriorated over time, certain components need to be outsourced to another site. One way to assess the current decomposition is to consider the past evolution, searching for components that often changed together. We iteratively devised and implemented a process for doing so at Philips Healthcare MRI. In this paper, we describe the lessons learned on how to effectively support architects to improve their system decomposition. Copyright © 2011 John Wiley & Sons, Ltd.

In the past few years, software engineering researchers have adopted social network analysis techniques to understand collaboration patterns in global software teams. In this paper, we investigate current research in global software development where social network theory is used as an analysis technique. We do so through a systematic literature review where we collect and analyze previous work that adopt a social network perspective in distributed software development. We use the 3C collaboration model to classify our results based on the communication, coordination and cooperation aspects of global networks. Our results reveal two main coordination structures used in distributed teams, namely the clustering and the core-periphery structure. The analysis of the cooperation activities of the global networks reveal differences between planning and practice. Finally, several tools have been identified that aim to improve communication patterns among distributed team members.

In this paper we present the results of a case study at two offshore projects that recently adopted the agile way of working. We analyze their multi-site governance activities adopted and adjusted based on the Scrum methodology. Furthermore, we identify those changes that the Scrum adoption brought, in comparison with the previous governance structure of the Rational Unified Process (RUP). We find that a transition from RUP to Scrum brings a positive effect in requirements engineering, communication, cost management and cross-functionality of the distributed teams. We also observe a negative change with regard to the development pace and delivery time. Overall, we add to the body of knowledge in the field of distributed agile, with an additional field study where we describe and compare the migration from RUP to Scrum, and the implications of this transition.

In Global Software Engineering (GSE), people are organized in teams, distanced in space, time and culture. Organizational research calls this interplay of people an Organizational Social Structure (OSS). Previous literature in GSE shows that its OSS is highly dynamic and unpredictable. This paper presents a mapping of OSS types onto GSE organizational factors, based on empirical evidence. We made two observations: first, current OSS types don't support factors related to GSE process management and organizational efficiency (e.g. risk management, language, etc.). Second, OSSs in GSE have attributes which don't map onto any GSE factor, rather introduce a new one, awareness management (e.g. awareness of skills to others, awareness of tasks, tasks (re-)localization, etc.). Our conclusions are twofold. First, OSSs for GSE should focus on increasing support to process management and organizational efficiency. Lastly, research in GSE should include factors focusing on awareness management.

Software Development Governance (SDG) is an emerging field of research, under the umbrella of information technology governance. SDG challenges increase when software development activities are distributed across multiple locations. Coordination of knowledge management processes requires specific attention in multi-site development. This paper outlines a multi-site software governance structure, based on three aspects: the business strategy that binds the relationship of the remote offices, the structure and composition of the remote teams and the way tasks are allocated across sites. Knowledge management processes (including knowledge creation, knowledge transfer and communication) are identified and the influence of different governance structures on these processes is discussed. We do so through a case study at Océ, a multi-national company in printing systems.

The study of Software Configuration Management (SCM) has so far focused on the use of tools, SCM models, strategies, patterns or best practices. There are few industry studies on how an organization actually practices file branching and merging. In this empirical study at Océ, we have observed that some developers create branches freely without regards to their consequences on merging. This contradicts recommended best practices and SCM processes. So we investigate if there are hidden costs in propagating or merging changes at Océ. The investigation led us to understand that branching and merging can be done freely under certain circumstances to provide development concurrency. However, some files cannot be branched freely and it may be better to use recommended practices to edit them. Some roles were also noted to be more affected by branching of files.

In this paper, we reflect on our experiences with using semantic wikis for architectural knowledge management in two different contexts: e-government and distributed software development. Whereas our applications of semantic wikis in e-government focus on organizing and structuring architectural knowledge for reuse, the applications in distributed software development focus on searching and querying architectural knowledge. Yet, the emerging research challenges -- alignment of knowledge models, knowledge versioning, change acknowledgements -- are very similar.

We propose to view architecting as a risk- and cost management discipline. This point of view helps architects identify the key concerns to address in their decision making, by providing a simple, relatively objective way to assess architectural significance. It also helps business stakeholders to align the architect's activities and results with their own goals. We examine the consequences of this point of view on the architecture process, and give some guidance on its implementation, using examples from practicing architects trained in this approach.

In an agile environment, where the architect's role is not crisply defined, the architect may have to deal with a number of issues that arise during development and are considered architecture-related. Such issues range from feature requests and enhancements through to defects found during testing. Architect specifications that turn into issues boomerang the architect to resolve them. In a case study we looked at issues entered into the issue tracking system that were assigned to architects to understand the root causes for their inception. We found that many of the avoidable issues can be circumvented by better communication between the architect and other stakeholders, and by small adaptations in the development process.

The basic format in which software requirements and architecture designs are documented is essentially file-based, and it has persisted for decades. Current indexing methods used in file-based documentation are not conducive to retrieving software knowledge. We propose to index software documents with a suitable lightweight ontology to improve the retrieval and traceability of software knowledge. Initial results from a prototype implementation have shown promising prospects.

The wicked nature of software architecture calls for educational methodologies that deviate from the traditional active lecturer-passive student relation. In this paper we present our experiences with applying a community of learners approach, in which students are treated as partners in the knowledge development process, to software architecture education. In our course the students are actively involved, either as architects or as stakeholders, in the design of an architecture for a large and realistic system. In this community of learners, the students not only learn about but also experience the important issues in software architecture. Students indicate that, although the workload is high, the required effort is outweighed by the learning effect of their active involvement.

Software engineering courses often include some form of project, aimed at bridging the theory-practice gap. These projects tend to emphasize technical topics. Because software engineering has an important organizational and social dimension as well, and because software engineering courses may be taken by non-CS majors too, there is every reason to also include these non-technical issues in the software project. In this paper we discuss how we designed a multi-disciplinary software engineering project course that pays attention to non-technical issues. We report about our experience in four editions of the same project, and discuss lessons learned. Our general conclusion is that software engineering projects need to have specific characteristics to attract a multi-disciplinary student population.

Practices for architectural knowledge management (AKM) may alleviate the challenges involved with GSD. We have conducted empirical research at a large Dutch IT service provider to validate a set of practices for architectural knowledge management in GSD and to specifically investigate the relation between the number of sites and the perceived usefulness of these practices. The results show that AKM practices supporting a personalization strategy towards knowledge management are perceived to be more useful than practices that support a codification strategy. Further, the usefulness of AKM practices in general is confirmed. Finally, we observe a peak in the perceived usefulness of AKM practices in projects that evolved to a multi-site situation. This high perceived usefulness denotes a more critical need to plan for AKM practices in advance.

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.

The way in which a system's software archive is partitioned influences the evolvability of that system. The partition of a software archive, e.g. subsystem decomposition, is mostly assessed by looking at the static (include, call) relations between the parts. In the literature history information is also taken into account to assess the partition. In this paper we describe our history-based approach to (automatically) assess the extent in which a certain partition allows its parts to evolve independently. We use the assumption that software entities which co-evolved often in the past are likely to be modified together in the near future as well. Hence, the elements of such a set should in principle belong to the same part. Our approach, therefore, identifies sets of co-evolving software entities, where each set has elements from more than one part of the archive. We illustrate our approach with a case study of a large software system that evolved during more than a decade, and has over 7 million lines of code.

In recent years, management of architectural knowledge has become a more prominent theme in software architecture research. Although various specialized tools have been proposed for use in the architecting process, observations show that architects in industry have yet to meet a tool environment that matches their knowledge needs. In order to discover what architectural knowledge needs architects have, we conducted a study in a large organization. In this study we discovered that architects are especially in need for 'just-in-time architectural knowledge'. To fulfill this need we designed and implemented an architectural knowledge sharing portal. Our portal's integrated functionality supports architects in their decision-making process, by providing easy access to the right architectural knowledge at any given point in time.

This paper presents a European Master programme on global software engineering (SE), being put forward by four leading institutions from Sweden, UK, Netherlands and Italy. The Global SE European Master (GSEEM) programme aims to provide students with an excellence in SE based on sound theoretical foundations and practical experience, as well as prepare them to participate in global development of complex and large software systems. GSEEM has been designed with three noteworthy aspects: 1) Three specialization profiles in which the consortium excels: Software Architecting, Real-time Embedded Systems Engineering, and Web Systems and Services Engineering. 2) Two market-driven routes: "professional" to work as professionals, and "scientific" to continue the education towards research degrees. 3) An innovative concept of "shared modules", delivered together by multiple institutions. Four types of shared modules are foreseen: "parallel" twin modules which run remotely between universities, "shifted" modules which teach SE concepts incrementally with shifts in study locations and timeline ,"complementary" modules in which complementary SE concepts are taught in parallel through shared projects, and "common" modules which share the presentations and the project. The profiles realize "integrated knowledge" by complementing partial knowledge available at partner institutions. The paper explains how GSEEM achieves the objectives of educating global software engineers.

Global software development (GSD) faces additional challenges as compared to single-site software development. Some of the better known challenges include temporal, geographical, and socio-cultural differences. To overcome these challenges, organizations need to revert to measures in order to deliver software in time in a distributed setting. Some of these measures may exist in the form of architectural rules: principles and statements on the software architecture that must be complied with throughout the organization. From the GSD literature we distilled four main GSD challenges and seven sub-challenges, or issues. For each issue, we list possible solutions and observe that solutions to GSD challenges may be obtained by adhering to architectural rules. We present a study on how two organizations involved in GSD solve the GSD challenges and issues. One of the organizations mainly uses rules regulating the architecture of the product. The other organization does not emphasize these architectural rules but rather focuses on the joint team effort in establishing and committing to measures that mainly pertain to the architecture process. We conclude that rules regulating a combination of both proves valuable in handling GSD challenges.

Architectural knowledge is reflected in various artifacts of a software product. In the case of a software product audit this architectural knowledge needs to be uncovered and its effects assessed, in order to evaluate the quality of the software product. A particular problem is to find and comprehend the architectural knowledge that resides in the software product documentation. The amount of documents, and the differences in for instance target audience and level of abstraction, make it a difficult job for the auditors to find their way through the documentation. This paper discusses how the use of a technique called latent semantic analysis can guide the auditors through the documentation to the architectural knowledge they need. Using latent semantic analysis, we effectively construct a reading guide for software product audits.

Multi-site development organizations require coordination and communication efforts between different sites to ensure successful distributed development. These efforts need to be guided by a set of principles and statements on the software architecture that must be complied with throughout the organization: architectural rules. It is of paramount importance that multi-site development organizations incorporate measures in the architecting process to secure compliance with these rules throughout the organization. We describe a method to assess the degree to which compliance measures are secured in multi-site development organizations. We share our experience in applying this method in a large development organization in the consumer electronics domain.

Knowledge management plays an important role in the software architecting process. Recently, this role has become more apparent by a paradigm shift that views a software architecture as the set of architectural design decisions it embodies. This shift has sparked the discussion in both research and practice on how to best facilitate sharing of so-called architectural knowledge, and how tools can best be employed. In order to design successful tool support for architectural knowledge sharing it is important to take into account what software architecting really entails. In this paper, we define the main characteristics of architecting, based on observations in a large software development organization, and state-of-the-art literature in software architecture. Based on the defined characteristics, we determine how best practices known from knowledge management could be used to improve architectural knowledge sharing. This results in the definition of a set of desired properties of architectural knowledge sharing tools. Finally, we highlight the design and implementation of EAGLE, an architectural knowledge sharing portal that implements those properties.

Software architecture is a relatively new topic in software engineering. It is quickly becoming a central issue, and leading-edge organizations spend a considerable fraction of their development effort on software architecture. Consequently, software architecture is increasingly often the topic of a dedicated course in software engineering curricula. There are two general flavors as for the contents of such a course. One flavor emphasizes the programming-in-the-large aspects of software architecture and concentrates on design and architectural patterns, architecture description languages and the like. The other emphasizes the communication aspects of software architecture to a variety of stakeholders, thereby acknowledging a broader view of software architecture. In this paper we report our experiences with two master-level courses in software architecture that focus on these communication aspects. We show that, by appropriately focusing the contents of such a course, key aspects of this industrially very relevant field within software engineering can be taught successfully in a university setting

Design for change is a well-known adagium in software engineer-ing. We separate concerns, employ well-designed interfaces, and the like to ease evolution of the systems we build. We model and build in changeability through parameterization and variability points (as in product lines). These all concern places where we ex-plicitly consider variability in our systems. We conjecture that it is helpful to also think of and explicitly model invariability, things in our systems and their environment that we assume will not change. We give examples from the literature and our own experience to illustrate how evolution can be seriously hampered because of tacit assumptions made. In particular, we show how we can explicitly model assumptions in an existing product family. From this, we derive a metamodel to document assumptions. Finally, we show how this type of modeling adds to our understanding of the archi-tecture and the decisions that led to it.

Based on many years of teaching software engineering, I present a number of lessons I have learned over the years. I do so in the form of a series of myths, the reverse of which can be considered challenges to educators. The overall message I wish to convey is that there's more to software engineering than engineering. The engineering metaphor gives us a lot of useful guidance in shaping our profession. But there's also a downside, in that this goes at the expense of the human, social dimension that is an essential element of our profession.

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use case model for an architectural knowledge system.

In the software architecture education session, we discussed four main issues: how to make a software architecture course sufficiently realistic, how to teach non-technical competencies of software architects, the place of such a course in a university curriculum, and how to grow software architects beyond the university. The session resulted in a first sketch of software architecture knowledge areas, and the extent to which these are deemed required for certain classes of software professionals.

Based on interviews with a number of architects and managers from a wide range of organizations, we characterize how architecture is perceived in practice. We identify three groups of organizations that differ with respect to their level of architectural thinking and the alignment of business and IT on architectural issues. Analysis of the interviews further indicates that these three groups differ in the architecture aspects and critical success factors they emphasize. Our results provide a starting point for assessing architecture maturity and alignment within organizations, and can be used to help harmonize different architectural tunes played within organizations.

Most software engineering approaches restrict the user interface to everything a user may perceive or experience. As a result, it is often designed rather independently of the system functionality. Chances are then that it does not get the attention it deserves. In the approach to software development we sketch, the design of the user interface and the design of the functionality go hand in hand. We give a number of examples of user interface problems, and illustrate how these can be caught early if a more integrated approach is taken. We conclude with an outline of a minimal course on human-computer interaction that we feel should be part of everyone's software engineering curriculum.

Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a system's quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modifiability analysis for business information systems we found that the views in current view models do not include all information required. In this paper we discuss the views we found useful for architecture level impact analysis of business information systems. They are illustrated using a case study we performed for the Dutch Tax and Customs Administration. We claim that when these views are required for architecture level impact analysis, the decisions they capture should also be considered during architecture development.

In this paper we investigate the differences between software maintenance and software development from a service point of view, and the consequences for the maturity of software maintenance organizations. We argue that software maintenance can be seen as providing a service, whereas software development is concerned with the development of products. Differences between products and services affect the way in which customers assess their respective quality. Consequently, customers judge the quality of software maintenance differently from how they judge the quality of software development. This in turn implies a need to carry out software maintenance through different processes from those used by the average software development organization. We discuss two overall approaches to achieving a high-quality IT service organization which include these service-specific processes: ITIL and the IT service capability maturity model. ITIL is a set of best practices widely used within the IT service industry. The IT service CMM is a maturity growth model akin to the software CMM. Copyright © 2000 John Wiley & Sons, Ltd.

Software architecture analysis helps us assess the quality of a software system at an early stage. We describe a case study of software architecture analysis that we have performed to assess the flexibility of a large administrative system. Our analysis was based on scenarios, representing possible changes to the requirements of the system and its environment. Assessing the effect of these scenarios provides insight into the flexibility of the system. One of the problems is to express the effect of a scenario in such a way that it provides insight into the complexity of the necessary changes. Part of our research is directed at developing an instrument for doing just that. This instrument is applied in the analysis presented.

In this paper we present the results of two measurement programs, that were aimed at investigating possible cost drivers for software maintenance. The two measurement programs were implemented in the software maintenance departments of two different organizations. Both programs were set up in roughly the same way. We use standard statistical techniques-principal component analysis and multiple regression analysis-to analyse the datasets. Surprisingly, with one of the datasets we are able to explain a fair amount of variance in the effort, while with the other dataset we can explain much less. From a closer inspection of the different environments we conjecture that the existence of a consistently applied process is an important prerequisite for a successful measurement program. In addition, if the process exists in multiple variants, it is important to know which variant is applied when.

Function point analysis (FPA) is a well-known method to measure the functionality of a system, from the user's point of view. Both Albrecht's (1979) original model and a local variant we studied assume that effort is primarily related to the size of a change. Analysis of data gathered on a major system over a period of 18 months does not confirm this relation. Rather our data suggests that the size of the component to be changed has a much larger impact on effort than the size of the change itself. Furthermore, the various corrective factors of the function point model do not help to improve effort estimates in the environment we studied. Finally, we found that expert estimates outperform the function point estimates, while analogy-based estimates slightly outperform the expert estimates

Abstract Tagging is the augmentation of run‐time data with some form of self‐description for type checking or storage management purposes. We have studied the contribution of automatic tagging by converting two programs written in object‐oriented languages to PL/1. We had thought that much of the apparent superiority of the object‐oriented version came from dynamic binding of operator invocations. However, of several factors contributing to program quality, automatic storage management and the availability of generic abstract data types seem equally important in the examples studied. Tags turned out to be needed for only a few data objects and are used in only a few places. When the obligatory tags are modelled in PL/1, the code becomes particular to the problem at hand and is less elegant. On the other hand, current implementations of object‐oriented languages have considerable overhead in both time and space for tags. This led us to consider combining tagged and non‐tagged objects in a single language.