Laser scanner for testing semiconductor chips

Individual ''fingerprint'' signals are produced when system photoexcites chips. ''Fingerprints'' are analyzed for characteristics associated with defects, including many not visible to the naked eye. Electromagnetic radiation photogenerates free electrons and holes in semiconductor chip. These carriers produce electrical signals at terminals. Signals vary depending on what defects are present

Reducing regression test size by exclusion.

Operational software is constantly evolving. Regression testing is used to identify the unintended consequences of evolutionary changes. As most changes affect only a small proportion of the system, the challenge is to ensure that the regression test set is both safe (all relevant tests are used) and unclusive (only relevant tests are used). Previous approaches to reducing test sets struggle to find safe and inclusive tests by looking only at the changed code. We use decomposition program slicing to safely reduce the size of regression test sets by identifying those parts of a system that could not have been affected by a change; this information will then direct the selection of regression tests by eliminating tests that are not relevant to the change. The technique properly accounts for additions and deletions of code. We extend and use Rothermel and Harrold’s framework for measuring the safety of regression test sets and introduce new safety and precision measures that do not require a priori knowledge of the exact number of modification-revealing tests. We then analytically evaluate and compare our techniques for producing reduced regression test sets

Reducing regression test size by exclusion.

Operational software is constantly evolving. Regression testing is used to identify the unintended consequences of evolutionary changes. As most changes affect only a small proportion of the system, the challenge is to ensure that the regression test set is both safe (all relevant tests are used) and unclusive (only relevant tests are used). Previous approaches to reducing test sets struggle to find safe and inclusive tests by looking only at the changed code. We use decomposition program slicing to safely reduce the size of regression test sets by identifying those parts of a system that could not have been affected by a change; this information will then direct the selection of regression tests by eliminating tests that are not relevant to the change. The technique properly accounts for additions and deletions of code. We extend and use Rothermel and Harrold’s framework for measuring the safety of regression test sets and introduce new safety and precision measures that do not require a priori knowledge of the exact number of modification-revealing tests. We then analytically evaluate and compare our techniques for producing reduced regression test sets

Can Thomas Kuhn's paradigms help us understand software engineering

Peer reviewe

The impact of using pair programming on system evolution a simulation-based study

In this paper we investigate the impact of pair--programming on the long term evolution of software systems. We use system dynamics to build simulation models which predict the trend in system growth with and without pair programming. Initial results suggest that the extra effort needed for two people to code together may generate sufficient benefit to justify pair programming.Peer reviewe

Using software development progress data to understand threats to project outcomes

Peer reviewe

Filling the gaps of development logs and bug issue data

It has been suggested that the data from bug repositories is not always in sync or complete compared to the logs detailing the actions of developers on source code. In this paper, we trace two sources of information relative to software bugs: the change logs of the actions of developers and the issues reported as bugs. The aim is to identify and quantify the discrepancies between the two sources in recording and storing the developer logs relative to bugs. Focussing on the databases produced by two mining software repository tools, CVSAnalY and Bicho, we use part of the SZZ algorithm to identify bugs and to compare how the"defects-fixing changes" are recorded in the two databases. We use a working example to show how to do so. The results indicate that there is a significant amount of information, not in sync when tracing bugs in the two databases. We, therefore, propose an automatic approach to re-align the two databases, so that the collected information is mirrored and in sync.Dr. Felipe Orteg

Persuading developers to buy into software process improvement: a local opinion and empirical evidence

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.---- Copyright IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.In order to investigate practitioners’ opinions of software process and software process improvement, we have collected a large volume of qualitative evidence from 13 companies. At the same time, other researchers have reported investigations of practitioners, and we are interested in how their reports may relate to our evidence. Thus, other research publications can also be treated as a form of qualitative data. In this paper, we review advice on a method, content analysis, that is used to analyse qualitative data. We use content analysis to describe and analyse discussions on software process and software process improvement. We report preliminary findings from an analysis of both the focus group evidence and four publications

Persuading developers to buy into software process improvement: an exploratory analysis

In order to investigate practitioners' opinions of software process and software process improvement, we have collected information from 13 companies, in a variety of ways i.e. the use of Repertory Grid Technique, survey and focus group discussions. Both the Repertory Grid Technique and the focus group discussions (43 discussions occurred, in total) produced a large volume of qualitative data. At the same time, other researchers have reported--investigations of practitioners, and we are interested in how their reports may relate to our own. Thus, other research publications can also be treated as a form of qualitative data. In this paper, we review advice on a method, content analysis, that is used to analyse qualitative data. Content analysis is a method for identifying and classifying words and phrases used in--ordinary language. We use content analysis to describe and analyse discussions on software--process and software process improvement. We report preliminary findings from an analysis--of both the focus group evidence and some publications. Our main finding is that there is an--apparent contradiction between developers saying that they want evidence for software process improvement, and what developers will accept as evidence. This presents a serious problem for research: even if researchers could demonstrate a strong, reliable relationship between software process improvement and improved organisational performance, there would still be the problem of convincing practitioners that the evidence applies to their particular situation