Austen Rainer

Case Study Research in Software Engineering: Guidelines and Examples

Based on their own experiences of in-depth case studies of software projects in international corporations, in this bookthe authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on thecase study research method.

Key success factors for implementing software process improvement : a maturity-based analysis

Original article can be found at: http://www.sciencedirect.com/science/journal/01641212 Copyright Elsevier Inc. [Full text of this article is not available in the UHRA]

Software Process Improvement Problems in Twelve Software Companies: An Empirical Analysis

In this paper we discuss our study of the problems 12 software companies experienced in software development. In total we present qualitative data collected from 45 focus groups that involved over 200 software staff. We look at how different practitioner groups respond to software process improvement problems. We show our classification and analysis of this data using correspondence analysis. Correspondence analysis is a graphical data representation method new to software development research. The aim of the work we present is to develop a more holistic understanding of the problems practitioners are experiencing in their attempts to improve their software processes. Our main finding is that there is an association between a companys capability maturity and patterns of reported problems. Organizational problems are more associated with high maturity companies than with low maturity companies. Low maturity companies are closely linked to problems relating directly to projects such as documentation, timescales, tools and technology. Our findings also confirm differences in practitioner group problems. Senior managers cite problems with goals, culture and politics. Project managers are concerned with timescales, change management, budgets and estimates. Developers are experiencing problems with requirements, testing, documentation, communication, tools and technology. These associations are displayed graphically through correspondence analysis maps.

Using an expert panel to validate a requirements process improvement model

In this paper we present components of a newly developed software process improvement model that aims to represent key practices in requirements engineering (RE). Our model is developed in response to practitioner needs highlighted in our empirical work with UK software development companies. We have now reached the stage in model development where we need some independent feedback as to how well our model meets our objectives. We perform this validation through involving a group of software process improvement and RE experts in examining our RE model components and completing a detailed questionnaire. A major part of this paper is devoted to explaining our validation methodology. There is very little in the literature that directly relates to how process models have been validated, therefore providing this transparency will benefit both the research community and practitioners. The validation methodology and the model itself contribute towards a better understanding of modelling RE processes.

Implementing Software Process Improvement: An Empirical study

In this paper we present survey data characterizing the implementation of SPI in 85 UK companies. We aim to provide SPI managers with more understanding of the critical success factors of implementing SPI. We present an analysis of the critical implementation factors identified in published case studies. We use a questionnaire to measure the use of these factors in ‘typical’ software companies. We found that many companies use SPI but the effectiveness of SPI implementation is variable. Many companies inadequately resource SPI and fail to evaluate the impact of SPI. On the other hand, companies show a good appreciation of the human factors associated with implementing SPI. Copyright

Defining a Requirements Process Improvement Model

Both software organisations and the academic community are aware that the requirements phase of software development is in need of further support. We address this problem by creating a specialised Requirements Capability Maturity Model (R-CMM1). The model focuses on the requirements engineering process as defined within the established Software Engineering Institute’s (SEI’s) software process improvement framework. Our empirical work with software practitioners is a primary motivation for creating this requirements engineering process improvement model. Although all organisations in our study were involved in software process improvement (SPI), they all showed a lack of control over many requirement engineering activities.This paper describes how the requirements engineering (RE) process is decomposed and prioritised in accordance with maturity goals set by the SEI’s Software Capability Maturity Model (SW CMM). Our R-CMM builds on the SEI’s framework by identifying and defining recommended RE sub-processes that meet maturity goals. This new focus will help practitioners to define their RE process with a view to setting realistic goals for improvement.

Robot-Mediated Interviews - How Effective Is a Humanoid Robot as a Tool for Interviewing Young Children?

Robots have been used in a variety of education, therapy or entertainment contexts. This paper introduces the novel application of using humanoid robots for robot-mediated interviews. An experimental study examines how children’s responses towards the humanoid robot KASPAR in an interview context differ in comparison to their interaction with a human in a similar setting. Twenty-one children aged between 7 and 9 took part in this study. Each child participated in two interviews, one with an adult and one with a humanoid robot. Measures include the behavioural coding of the children’s behaviour during the interviews and questionnaire data. The questions in these interviews focused on a special event that had recently taken place in the school. The results reveal that the children interacted with KASPAR very similar to how they interacted with a human interviewer. The quantitative behaviour analysis reveal that the most notable difference between the interviews with KASPAR and the human were the duration of the interviews, the eye gaze directed towards the different interviewers, and the response time of the interviewers. These results are discussed in light of future work towards developing KASPAR as an ‘interviewer’ for young children in application areas where a robot may have advantages over a human interviewer, e.g. in police, social services, or healthcare applications.

the neglected technical skill

In this paper we discuss the importance of communication in software development. Communication has long been recognized as an important element of a successful software project. The quality of communication within the development team and between the development team and external entities impacts on the performance of the software project. However there is little evidence to suggest that approaches to software development have adequately emphasized high quality communications. Our findings suggest that the SEIs family of Capability Maturity Models, arguably the most influential models of software development, address communication in a very superficial way. We consider the impact of poor communication on the performance of a team of developers working in a software organization that has been assessed at CMM Level 5. We conducted multi-level interviews with all developers in the software team. Our main findings are that, although the team recognizes the importance of communication, many communication problems are reported. Furthermore, we found that human-centric processes, such as communication, were much less mature than the technical processes. We discuss the typical personality traits that may mitigate against developers being good communicators. We conclude that one way to overcome this is for development models to address communication more explicitly.

An analysis of some ‘core studies’ of software process improvement

In this paper we analyse 39 publications that have reported issues relating to software process improvement. Together, the 39 publications refer to 14 sites in 11 organizations. The 11 organizations include all five of the organizations that have been awarded the IEEE Computer Society Award for Process Achievement. Twelve of the 14 sites have been assessed at CMM level 3 or higher. Two main issues, and a number of more specific issues, emerge from our analysis. The two main issues are organizational stability and process expertise. We further distinguish between inter- and intra-organizational stability. Several other specific issues are identified and discussed. We direct attention at how the specific issues relate to each other, how the two main issues relate to each other, and how all these issues relate to software process improvement. We speculate that organizational stability provides a stable environment within which to perform the process and to develop expertise. In addition to the 39 publications, the paper provides cross-references to survey studies and other case studies on process improvement, and studies into process understanding. Copyright

The longitudinal, chronological case study research strategy: A definition, and an example from IBM Hursley Park

Context: There is surprisingly little empirical software engineering research (ESER) that has analysed and reported the rich, fine-grained behaviour of phenomena over time using qualitative and quantitative data. The ESER community also increasingly recognises the need to develop theories of software engineering phenomena e.g. theories of the actual behaviour of software projects at the level of the project and over time. Objective: To examine the use of the longitudinal, chronological case study (LCCS) as a research strategy for investigating the rich, fine-grained behaviour of phenomena over time using qualitative and quantitative data. Method: Review the methodological literature on longitudinal case study. Define the LCCS and demonstrate the development and application of the LCCS research strategy to the investigation of Project C, a software development project at IBM Hursley Park. Use the study to consider prospects for LCCSs, and to make progress on a theory of software project behaviour. Results: LCCSs appear to provide insights that are hard to achieve using existing research strategies, such as the survey study. The LCCS strategy has basic requirements that data is time-indexed, relatively fine-grained and collected contemporaneous to the events to which the data refer. Preliminary progress is made on a theory of software project behaviour. Conclusion: LCCS appears well suited to analysing and reporting rich, fine-grained behaviour of phenomena over time.