According to W. Edwards Deming, American companies require nothing less than a transformation of management style and of governmental relations with industry. In Out of the Crisis, originally published in 1982, Deming offers a theory of management based on his famous 14 Points for Management. Management's failure to plan for the future, he claims, brings about loss of market, which brings about loss of jobs. Management must be judged not only by the quarterly dividend, but by innovative plans to stay in business, protect investment, ensure future dividends, and provide more jobs through improved product and service. In simple, direct language, he explains the principles of management transformation and how to apply them.

Out of the Crisis

This sales letter may not influence you to be smarter, but the book that we offer will evoke you to be smarter. Yeah, at least you'll know more than others who don't. This is what called as the quality life improvisation. Why should this research methods in social relations? It's because this is your favourite theme to read. If you like this theme about, why don't you read the book to enrich your discussion?

Research methods in social relations

Like other sciences and engineering disciplines, software engineering requires a cycle of model building, experimentation, and learning. Experiments are valuable tools for all software engineers who are involved in evaluating and choosing between different methods, techniques, languages and tools. The purpose of Experimentation in Software Engineering is to introduce students, teachers, researchers, and practitioners to empirical studies in software engineering, using controlled experiments. The introduction to experimentation is provided through a process perspective, and the focus is on the steps that we have to go through to perform an experiment. The book is divided into three parts. The first part provides a background of theories and methods used in experimentation. Part II then devotes one chapter to each of the five experiment steps: scoping, planning, execution, analysis, and result presentation. Part III completes the presentation with two examples. Assignments and statistical material are provided in appendixes. Overall the book provides indispensable information regarding empirical studies in particular for experiments, but also for case studies, systematic literature reviews, and surveys. It is a revision of the authors book, which was published in 2000. In addition, substantial new material, e.g. concerning systematic literature reviews and case study research, is introduced. The book is self-contained and it is suitable as a course book in undergraduate or graduate studies where the need for empirical studies in software engineering is stressed. Exercises and assignments are included to combine the more theoretical material with practical aspects. Researchers will also benefit from the book, learning more about how to conduct empirical studies, and likewise practitioners may use it as a cookbook when evaluating new methods or techniques before implementing them in their organization.

Experimentation in Software Engineering

Empirical software engineering research needs research guidelines to improve the research and reporting processes. We propose a preliminary set of research guidelines aimed at stimulating discussion among software researchers. They are based on a review of research guidelines developed for medical researchers and on our own experience in doing and reviewing software engineering research. The guidelines are intended to assist researchers, reviewers, and meta-analysts in designing, conducting, and evaluating empirical studies. Editorial boards of software engineering journals may wish to use our recommendations as a basis for developing guidelines for reviewers and for framing policies for dealing with the design, data collection, and analysis and reporting of empirical studies.

/pdf/preliminary-guidelines-for-empirical-research-in-software-17mchb417s.pdf

Preliminary guidelines for empirical research in software engineering

While empirical studies in software engineering are beginning to gain recognition in the research community, this subarea is also entering a new level of maturity by beginning to address the human aspects of software development. This added focus has added a new layer of complexity to an already challenging area of research. Along with new research questions, new research methods are needed to study nontechnical aspects of software engineering. In many other disciplines, qualitative research methods have been developed and are commonly used to handle the complexity of issues involving human behaviour. The paper presents several qualitative methods for data collection and analysis and describes them in terms of how they might be incorporated into empirical studies of software engineering, in particular how they might be combined with quantitative methods. To illustrate this use of qualitative methods, examples from real software engineering studies are used throughout.

/pdf/qualitative-methods-in-empirical-studies-of-software-379hatmhwt.pdf

Qualitative methods in empirical studies of software engineering

Software requirements specifications (SRS) are often validated manually. One such process is inspection, in which several reviewers independently analyze all or part of the specification and search for faults. These faults are then collected at a meeting of the reviewers and author(s). Usually, reviewers use Ad Hoc or Checklist methods to uncover faults. These methods force all reviewers to rely on nonsystematic techniques to search for a wide variety of faults. We hypothesize that a Scenario-based method, in which each reviewer uses different, systematic techniques to search for different, specific classes of faults, will have a significantly higher success rate. We evaluated this hypothesis using a 3/spl times/2/sup 4/ partial factorial, randomized experimental design. Forty eight graduate students in computer science participated in the experiment. They were assembled into sixteen, three-person teams. Each team inspected two SRS using some combination of Ad Hoc, Checklist or Scenario methods. For each inspection we performed four measurements: (1) individual fault detection rate, (2) team fault detection rate, (3) percentage of faults first identified at the collection meeting (meeting gain rate), and (4) percentage of faults first identified by an individual, but never reported at the collection meeting (meeting loss rate). The experimental results are that (1) the Scenario method had a higher fault detection rate than either Ad Hoc or Checklist methods, (2) Scenario reviewers were more effective at detecting the faults their scenarios are designed to uncover, and were no less effective at detecting other faults than both Ad Hoc or Checklist reviewers, (3) Checklist reviewers were no more effective than Ad Hoc reviewers, and (4) Collection meetings produced no net improvement in the fault detection rate-meeting gains were offset by meeting losses. >

/pdf/comparing-detection-methods-for-software-requirements-13nkxyb49y.pdf

Comparing detection methods for software requirements inspections: a replicated experiment

In this article we summarize the strengths and weaknesses of empirical research in software engineering. We argue that in order to improve the current situation we must create better studies and draw more credible interpretations from them. We finally present a roadmap for this improvement, which includes a general structure for software empirical studies and concrete steps for achieving these goals: designing better studies, collecting data more effectively, and involving others in our empirical enterprises.

/pdf/empirical-studies-of-software-engineering-a-roadmap-3pibjjqd7v.pdf

Empirical studies of software engineering: a roadmap

In their efforts to determine how technology affects the software development process, researchers often overlook organizational and social issues. The authors report on two experiments to discover how developers spend their time. They describe how noncoding activities can use up development time and how even a reluctance to use e-mail can influence the development process. The first experiment was to see how programmers thought they spent their time by having them fill out a modified time card reporting their activities, which we called a time diary. In the second experiment, we used direct observation to calibrate and validate the use of time diaries, which helped us evaluate how time was actually being used. >

People, organizations, and process improvement

Large-scale software products must constantly change in order to adapt to a changing environment Studies of historic data from legacy software systems have identified three specific causes of this change: adding new features; correcting faults; and restructuring code to accommodate future changes Our hypothesis is that a textual description field of a change is essential to understanding why that change was performed In addition, we expect that difficulty, size, and interval would vary strongly across different types of changes To test these hypotheses we have designed a program, which automatically classifies maintenance activity based on a textual description of changes Developer surveys showed that the automatic classification was in agreement with developer opinions Tests of the classifier on a different product found that size and interval for different types of changes did not vary across two products We have found strong relationships between the type and size of a change and the time required to carry it out We also discovered a relatively large amount of perfective changes in the system we examined From the study we have arrived at several suggestions on how to make version control data useful in diagnosing the state of a software project, without significantly increasing the overhead for the developer using the change management system

/pdf/identifying-reasons-for-software-changes-using-historic-4pztcjnc19.pdf

Identifying Reasons for Software Changes Using Historic Databases

At each step in large software development, reviewers carry out inspections to detect faults. These inspections are usually followed by a meeting to collect the faults that have been discovered. However, we have found that these inspection meetings are not as beneficial as managers and developers think they are. Even worse, they cost much more in terms of products development interval and developer's time than anyone realizes.Analysis of the inspection and collection process leads us to make the following suggestions. First, at the least, the number of participants required at each inspection meeting should be minimized. Second, we propose two alternative fault collection methods, either of which would eliminate the inspection meetings altogether: (a) collect faults by deposition (small face-to-face meetings of two or three persons), or (b) collect faults using verbal or written media (telephone, electronic mail, or notes).We believe that such a change in procedure would increase efficiency by reducing production times without sacrificing product quality.

Lawrence G. Votta

Papers

Comparing detection methods for software requirements inspections: a replicated experiment

Empirical studies of software engineering: a roadmap

People, organizations, and process improvement

Identifying Reasons for Software Changes Using Historic Databases

Does every inspection need a meeting