David Budgen

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.

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.

Empirical evidence about the UML: a systematic literature review

The Unified Modeling Language (UML) was created on the basis of expert opinion and has now become accepted as the ‘standard’ object‐oriented modelling notation. Our objectives were to determine how widely the notations of the UML, and their usefulness, have been studied empirically, and to identify which aspects of it have been studied in most detail. We undertook a mapping study of the literature to identify relevant empirical studies and to classify them in terms of the aspects of the UML that they studied. We then conducted a systematic literature review, covering empirical studies published up to the end of 2008, based on the main categories identified. We identified 49 relevant publications, and report the aggregated results for those categories for which we had enough papers— metrics, comprehension, model quality, methods and tools and adoption. Despite indications that a number of problems exist with UML models, researchers tend to use the UML as a ‘given’ and seem reluctant to ask questions that might help to make it more effective. Copyright

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.

What Do We Know about the Effectiveness of Software Design Patterns

Context. Although research in software engineering largely seeks to improve the practices and products of software development, many practices are based upon codification of expert knowledge, often with little or no underpinning from objective empirical evidence. Software design patterns seek to codify expert knowledge to share experience about successful design structures. Objectives. To investigate how extensively the use of software design patterns has been subjected to empirical study and what evidence is available about how and when their use can provide an effective mechanism for knowledge transfer about design. Method. We conducted a systematic literature review in the form of a mapping study, searching the literature up to the end of 2009 to identify relevant primary studies about the use of the 23 patterns catalogued in the widely referenced book by the “Gang of Four.” These studies were then categorized according to the forms of study employed, the patterns that were studied, as well as the context within which the study took place. Results. Our searches identified 611 candidate papers. Applying our inclusion/exclusion criteria resulted in a final set of 10 papers that described 11 instances of “formal” experimental studies of object-oriented design patterns. We augmented our analysis by including seven “experience” reports that described application of patterns using less rigorous observational forms. We report and review the profiles of the empirical evidence for those patterns for which multiple studies exist. Conclusions. We could not identify firm support for any of the claims made for patterns in general, although there was some support for the usefulness of patterns in providing a framework for maintenance, and some qualitative indication that they do not help novices learn about design. For future studies we recommend that researchers use case studies that focus upon some key patterns, and seek to identify the impact that their use can have upon maintenance.

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.