Pearl Brereton

Turning software into a service

The software as a service model composes services dynamically, as needed, by binding several lower-level services-thus overcoming many limitations that constrain traditional software use, deployment, and evolution.

Service-based software: the future for flexible software

For the past 40 years, the techniques, processes and methods of software development have been dominated by supply-side issues, giving rise to a software industry oriented towards developers rather than users. To achieve the levels of functionality, flexibility and time-to-market required by users, a radical shift is required in the development of software, with a more demand-centric view, leading to software which will be delivered as a service within the framework of an open marketplace. Already, there are some signs that this approach is being adopted by industry, but in a very limited way. We summarise research and a research method which has resulted in a long-term strategic view of software engineering innovation. Based on this foundation, we describe more recent work, which has resulted in an innovative demand-side model for the future of software. We propose a service architecture in which components may be bound instantly, just at the time they are needed, and then the binding may be discarded. A major benefit of this approach is that it leads to highly flexible and agile software that should be able to meet rapidly changing business needs.

A systematic review of systematic review process research in software engineering

Context: Many researchers adopting systematic reviews (SRs) have also published papers discussing problems with the SR methodology and suggestions for improving it. Since guidelines for SRs in software engineering (SE) were last updated in 2007, we believe it is time to investigate whether the guidelines need to be amended in the light of recent research. Objective: To identify, evaluate and synthesize research published by software engineering researchers concerning their experiences of performing SRs and their proposals for improving the SR process. Method: We undertook a systematic review of papers reporting experiences of undertaking SRs and/or discussing techniques that could be used to improve the SR process. Studies were classified with respect to the stage in the SR process they addressed, whether they related to education or problems faced by novices and whether they proposed the use of textual analysis tools. Results: We identified 68 papers reporting 63 unique studies published in SE conferences and journals between 2005 and mid-2012. The most common criticisms of SRs were that they take a long time, that SE digital libraries are not appropriate for broad literature searches and that assessing the quality of empirical studies of different types is difficult. Conclusion: We recommend removing advice to use structured questions to construct search strings and including advice to use a quasi-gold standard based on a limited manual search to assist the construction of search stings and evaluation of the search process. Textual analysis tools are likely to be useful for inclusion/exclusion decisions and search string construction but require more stringent evaluation. SE researchers would benefit from tools to manage the SR process but existing tools need independent validation. Quality assessment of studies using a variety of empirical methods remains a major problem.

Component-based systems: a classification of issues

Developing and using various component forms as building blocks can significantly enhance software-based system development and use, which is why both the academic and commercial sectors have shown interest in component-based software development. Indeed, much effort has been devoted to defining and describing the terms and concepts involved. Briefly, we describe software components as units of independent production, acquisition, and deployment that interact to form a functional system. We identify a set of issues organized within an overall framework that software developers must address for component-based systems (CBS) to achieve their full potential.

The future of software

Companies like British Telecommunications whose business is based on the performance of their software systems, should emphasize accessibility, adaptability, transparency, fail-safe operation, and a human face. Software Producing such software is difficult and involves high costs and risks. Adopting the most appropriate methods, technologies, and tools at just the right time is a major problem for the software industry. Recognition of the critical role played by software in so many aspects of society has therefore led us to pursue the following goals: • Forming a vision of software and software development based on the systematic use of expert judgement and peer review; • Establishing the need for a long-term software-development research agenda; and • Outlining a long-term research agenda that helps meet societys future needs for software that is reliable, adaptable, available when needed, and reasonably priced. Predicting the future is a popular pastime in many disciplines. In the field of software development, the February 1997 Communications offered many personal hopes and visions for the future of computer technology [1]. Authors expressed their personal views relating to particular technologies and applications , including databases [2], the Internet [3], and computational humanities [6]. In another personal view of future needs, Stuart Shapiro [5] examined a number of key software technology publications dating from as far back as the 1960s, concluding we need a more pluralistic approach to software engineering, Society is increasingly dependent on large and complex software systems. Indeed, if many of the current predictions about the Y2K computer problem turn out to be accurate, this dependency will be demonstrated dramatically on January 1, 2000. Users need software that meets stringent requirements, supports a range of interaction styles, can be produced quickly, and can be maintained to keep pace with the ever-increasing demand for functional-ity, quality, flexibility, and cost-effectiveness.

Performing systematic literature reviews in software engineering

Context: Making best use of the growing number of empirical studies in Software Engineering, for making decisions and formulating research questions, requires the ability to construct an objective summary of available research evidence. Adopting a systematic approach to assessing and aggregating the outcomes from a set of empirical studies is also particularly important in Software Engineering, given that such studies may employ very different experimental forms and be undertaken in very different experimental contexts.Objectives: To provide an introduction to the role, form and processes involved in performing Systematic Literature Reviews. After the tutorial, participants should be able to read and use such reviews, and have gained the knowledge needed to conduct systematic reviews of their own.Method: We will use a blend of information presentation (including some experiences of the problems that can arise in the Software Engineering domain), and also of interactive working, using review material prepared in advance.

Evidence relating to Object-Oriented software design: A survey

Case study is an important research methodology for software engineering. We have identified the need for checklists supporting researchers and reviewers in conducting and reviewing case studies. We derived checklists for researchers and reviewers respectively, using systematic qualitative procedures. Based on nine sources on case studies, checklists are derived and validated, and hereby presented for further use and improvement.There is little empirical knowledge of the effectiveness of the object-oriented paradigm. To conduct a systematic review of the literature describing empirical studies of this paradigm. We undertook a Mapping Study of the literature. 138 papers have been identified and classified by topic, form of study involved, and source. The majority of empirical studies of OO concentrate on metrics, relatively few consider effectiveness.

An investigation of software engineering curricula

We adapted a survey instrument developed by Timothy Lethbridge to assess the extent to which the education delivered by four UK universities matches the requirements of the software industry. We propose a survey methodology that we believe addresses the research question more appropriately than the one used by Lethbridge. In particular, we suggest that restricting the scope of the survey to address the question of whether the curricula for a specific university addressed the needs of its own students, allowed us to identify an appropriate target population. However, our own survey suffered from several problems. In particular the questions used in the survey are not ideal, and the response rate was poor.Although the poor response rate reduces the value of our results, our survey appears to confirm several of Lethbridges observations with respect to the over-emphasis of mathematical topics and the under-emphasis on business topics. We also have a close agreement with respect to the relative importance of different software engineering topics. However the set of topics, that we found were taught far less than their importance would suggest, were quite different from the topics identified by Lethbridge.

Presenting software engineering results using structured abstracts: a randomised experiment

When conducting a systematic literature review, researchers usually determine the relevance of primary studies on the basis of the title and abstract. However, experience indicates that the abstracts for many software engineering papers are of too poor a quality to be used for this purpose. A solution adopted in other domains is to employ structured abstracts to improve the quality of information provided. This study consists of a formal experiment to investigate whether structured abstracts are more complete and easier to understand than non-structured abstracts for papers that describe software engineering experiments. We constructed structured versions of the abstracts for a random selection of 25 papers describing software engineering experiments. The 64 participants were each presented with one abstract in its original unstructured form and one in a structured form, and for each one were asked to assess its clarity (measured on a scale of 1 to 10) and completeness (measured with a questionnaire that used 18 items). Based on a regression analysis that adjusted for participant, abstract, type of abstract seen first, knowledge of structured abstracts, software engineering role, and preference for conventional or structured abstracts, the use of structured abstracts increased the completeness score by 6.65 (SE 0.37, p < 0.001) and the clarity score by 2.98 (SE 0.23, p < 0.001). 57 participants reported their preferences regarding structured abstracts: 13 (23%) had no preference; 40 (70%) preferred structured abstracts; four preferred conventional abstracts. Many conventional software engineering abstracts omit important information. Our study is consistent with studies from other disciplines and confirms that structured abstracts can improve both information content and readability. Although care must be taken to develop appropriate structures for different types of article, we recommend that Software Engineering journals and conferences adopt structured abstracts.

Hypertext: the next maintenance mountain

Hypertext documents are quickly becoming large, complex, and unwieldy. The paper considers whether lessons learned from software maintenance can be applied to the problem. Since software maintenance is a major problem and since hypertext documents share many of the characteristics of software: structure, development process, and economic value, maintaining hypertext documents is also likely to become a major problem requiring immediate action.