240,374 research outputs found
A Review on Software Architectures for Heterogeneous Platforms
The increasing demands for computing performance have been a reality
regardless of the requirements for smaller and more energy efficient devices.
Throughout the years, the strategy adopted by industry was to increase the
robustness of a single processor by increasing its clock frequency and mounting
more transistors so more calculations could be executed. However, it is known
that the physical limits of such processors are being reached, and one way to
fulfill such increasing computing demands has been to adopt a strategy based on
heterogeneous computing, i.e., using a heterogeneous platform containing more
than one type of processor. This way, different types of tasks can be executed
by processors that are specialized in them. Heterogeneous computing, however,
poses a number of challenges to software engineering, especially in the
architecture and deployment phases. In this paper, we conduct an empirical
study that aims at discovering the state-of-the-art in software architecture
for heterogeneous computing, with focus on deployment. We conduct a systematic
mapping study that retrieved 28 studies, which were critically assessed to
obtain an overview of the research field. We identified gaps and trends that
can be used by both researchers and practitioners as guides to further
investigate the topic
Using blind analysis for software engineering experiments
Context: In recent years there has been growing concern about conflicting experimental results in empirical software engineering. This has been paralleled by awareness of how bias can impact research results. Objective: To explore the practicalities of blind analysis of experimental results to reduce bias. Method : We apply blind analysis to a real software engineering experiment that compares three feature weighting approaches with a na ̈ıve benchmark (sample mean) to the Finnish software effort data set. We use this experiment as an example to explore blind analysis as a method to reduce researcher bias. Results: Our experience shows that blinding can be a relatively straightforward procedure. We also highlight various statistical analysis decisions which ought not be guided by the hunt for statistical significance and show that results can be inverted merely through a seemingly inconsequential statistical nicety (i.e., the degree of trimming). Conclusion: Whilst there are minor challenges and some limits to the degree of blinding possible, blind analysis is a very practical and easy to implement method that supports more objective analysis of experimental results. Therefore we argue that blind analysis should be the norm for analysing software engineering experiments
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
Case Studies in Industry: What We Have Learnt
Case study research has become an important research methodology for
exploring phenomena in their natural contexts. Case studies have earned a
distinct role in the empirical analysis of software engineering phenomena which
are difficult to capture in isolation. Such phenomena often appear in the
context of methods and development processes for which it is difficult to run
large, controlled experiments as they usually have to reduce the scale in
several respects and, hence, are detached from the reality of industrial
software development. The other side of the medal is that the realistic
socio-economic environments where we conduct case studies -- with real-life
cases and realistic conditions -- also pose a plethora of practical challenges
to planning and conducting case studies. In this experience report, we discuss
such practical challenges and the lessons we learnt in conducting case studies
in industry. Our goal is to help especially inexperienced researchers facing
their first case studies in industry by increasing their awareness for typical
obstacles they might face and practical ways to deal with those obstacles.Comment: Proceedings of the 4th International Workshop on Conducting Empirical
Studies in Industry, co-located with ICSE, 201
Structured Review of the Evidence for Effects of Code Duplication on Software Quality
This report presents the detailed steps and results of a structured review of code clone literature. The aim of the review is to investigate the evidence for the claim that code duplication has a negative effect on code changeability. This report contains only the details of the review for which there is not enough place to include them in the companion paper published at a conference (Hordijk, Ponisio et al. 2009 - Harmfulness of Code Duplication - A Structured Review of the Evidence)
Recommended from our members
An Empirical Study of the Effectiveness of 'Forcing Diversity' Based on a Large Population of Diverse Programs
Use of diverse software components is a viable defence against common-mode failures in redundant softwarebased systems. Various forms of "Diversity-Seeking Decisions" (“DSDs”) can be applied to the process of developing, or procuring, redundant components, to improve the chances of the resulting components not failing on the same demands. An open question is how effective these decisions, and their combinations, are for achieving large enough reliability gains. Using a large population of software programs, we studied experimentally the effectiveness of specific "DSDs" (and their combinations) mandating differences between redundant components. Some of these combinations produced much better improvements in system probability of failure per demand (PFD) than "uncontrolled" diversity did. Yet, our findings suggest that the gains from such "DSDs" vary significantly between them and between the application problems studied. The relationship between DSDs and system PFD is complex and does not allow for simple universal rules
(e.g. "the more diversity the better") to apply
Agent-based simulation of open source evolution
We present an agent-based simulation model developed to study how size, complexity and effort relate to each other in the development of open source software (OSS). In the model, many developer agents generate, extend, and re-factor code modules independently and in parallel. This accords with empirical observations of OSS development. To our knowledge, this is the first model of OSS evolution that includes the complexity of software modules as a limiting factor in productivity, the fitness of the software to its requirements, and the motivation of developers.
Validation of the model was done by comparing the simulated results against four measures of software evolution (system size, proportion of highly complex modules, level of complexity control work, and distribution of changes) for four large OSS systems. The simulated results resembled the observed data, except for system size: three of the OSS systems showed alternating patterns of super-linear and sub-linear growth, while the simulations produced only super-linear growth. However, the fidelity of the model for the other measures suggests that developer motivation and the limiting effect of complexity on productivity have a significant effect on the development of OSS systems and should be considered in any model of OSS development
Towards a Theory of Software Development Expertise
Software development includes diverse tasks such as implementing new
features, analyzing requirements, and fixing bugs. Being an expert in those
tasks requires a certain set of skills, knowledge, and experience. Several
studies investigated individual aspects of software development expertise, but
what is missing is a comprehensive theory. We present a first conceptual theory
of software development expertise that is grounded in data from a mixed-methods
survey with 335 software developers and in literature on expertise and expert
performance. Our theory currently focuses on programming, but already provides
valuable insights for researchers, developers, and employers. The theory
describes important properties of software development expertise and which
factors foster or hinder its formation, including how developers' performance
may decline over time. Moreover, our quantitative results show that developers'
expertise self-assessments are context-dependent and that experience is not
necessarily related to expertise.Comment: 14 pages, 5 figures, 26th ACM Joint European Software Engineering
Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE
2018), ACM, 201
- …