Object-oriented cohesion as a surrogate of software comprehension: An empirical study

The concept of software cohesion in both the procedural and object-oriented paradigm is well known and documented. What is not so well known or documented is the perception of what empirically constitutes a cohesive 'unit' by software engineers. In this paper, we describe an empirical investigation using object-oriented (OO) classes as a basis. Twenty-four subjects (drawn from IT experienced and IT inexperienced groups) were asked to rate ten classes sampled from two industrial systems in terms of their overall cohesiveness; a class environment was used to carry out the study. Four key results were observed. Firstly, class size (when expressed in terms of number of methods) did not tend to influence the perception of cohesion by any subjects. Secondly, well-commented classes were rated most highly amongst both IT experienced and inexperienced subjects. Thirdly, the empirical study suggests that cohesion comprises a combination of various class factors including low coupling, small numbers of attributes and well-commented methods, rather than any single, individual class feature per se. Finally, the research supports the view that cohesion is a subjective concept reflecting a cognitive combination of class features; as such it is a surrogate for class comprehension

Making inferences with small numbers of training sets

A potential methodological problem with empirical studies that assess project effort prediction system is discussed. Frequently, a hold-out strategy is deployed so that the data set is split into a training and a validation set. Inferences are then made concerning the relative accuracy of the different prediction techniques under examination. This is typically done on very small numbers of sampled training sets. It is shown that such studies can lead to almost random results (particularly where relatively small effects are being studied). To illustrate this problem, two data sets are analysed using a configuration problem for case-based prediction and results generated from 100 training sets. This enables results to be produced with quantified confidence limits. From this it is concluded that in both cases using less than five training sets leads to untrustworthy results, and ideally more than 20 sets should be deployed. Unfortunately, this raises a question over a number of empirical validations of prediction techniques, and so it is suggested that further research is needed as a matter of urgency

Happy software developers solve problems better: psychological measurements in empirical software engineering

For more than 30 years, it has been claimed that a way to improve software developers' productivity and software quality is to focus on people and to provide incentives to make developers satisfied and happy. This claim has rarely been verified in software engineering research, which faces an additional challenge in comparison to more traditional engineering fields: software development is an intellectual activity and is dominated by often-neglected human aspects. Among the skills required for software development, developers must possess high analytical problem-solving skills and creativity for the software construction process. According to psychology research, affects-emotions and moods-deeply influence the cognitive processing abilities and performance of workers, including creativity and analytical problem solving. Nonetheless, little research has investigated the correlation between the affective states, creativity, and analytical problem-solving performance of programmers. This article echoes the call to employ psychological measurements in software engineering research. We report a study with 42 participants to investigate the relationship between the affective states, creativity, and analytical problem-solving skills of software developers. The results offer support for the claim that happy developers are indeed better problem solvers in terms of their analytical abilities. The following contributions are made by this study: (1) providing a better understanding of the impact of affective states on the creativity and analytical problem-solving capacities of developers, (2) introducing and validating psychological measurements, theories, and concepts of affective states, creativity, and analytical-problem-solving skills in empirical software engineering, and (3) raising the need for studying the human factors of software engineering by employing a multidisciplinary viewpoint.Comment: 33 pages, 11 figures, published at Peer

Qualitative software engineering research -- reflections and guidelines

Researchers are increasingly recognizing the importance of human aspects in software development and since qualitative methods are used to, in-depth, explore human behavior, we believe that studies using such techniques will become more common. Existing qualitative software engineering guidelines do not cover the full breadth of qualitative methods and knowledge on using them found in the social sciences. The aim of this study was thus to extend the software engineering research community's current body of knowledge regarding available qualitative methods and provide recommendations and guidelines for their use. With the support of an epistemological argument and a literature review, we suggest that future research would benefit from (1) utilizing a broader set of research methods, (2) more strongly emphasizing reflexivity, and (3) employing qualitative guidelines and quality criteria. We present an overview of three qualitative methods commonly used in social sciences but rarely seen in software engineering research, namely interpretative phenomenological analysis, narrative analysis, and discourse analysis. Furthermore, we discuss the meaning of reflexivity in relation to the software engineering context and suggest means of fostering it. Our paper will help software engineering researchers better select and then guide the application of a broader set of qualitative research methods.Comment: 30 page

Information Systems Skills Differences between High-Wage and Low-Wage Regions: Implications for Global Sourcing

Developing Information Systems (IS) skills for a company’s workforce has always been challenging, but global sourcing growth has caused the determination of needed IS skills to be more complex. The increased use of outsourcing to an IS service provider and from high-wage regions to low-wage regions has affected what IS skills are required globally and how to distribute the workforce to meet these needs. To understand what skills are needed in locations that seek and those that provide outsourcing, we surveyed IS service provider managers in global locations. Results from 126 reporting units provide empirical evidence that provider units in low-wage regions value technical skills more than those in high-wage regions. Despite the emphasis on commodity skills in low-wage areas, high- and low-wage providers value project management skills. Low-wage regions note global and virtual teamwork more than high-wage regions do. The mix of skills and the variation by region have implications for domestic and offshore sourcing. Service providers can vary their staffing models in global regions which has consequences for recruiting, corporate training, and curriculum