Relationships between characteristics of Tennessee swine producers, numbers of contacts they had with county agricultural extension and numbers of recommended swine production practices adopted

The purpose of this study was to characterize Tennessee swine producers, and determine the relationship between the number of contacts producers had with Agricultural Extension agents and their use of recommended swine production practices. Eighteen hundred and seventy-nine swine producers were randomly selected and personal interviews were conducted by county Extension agents. Interview schedules were developed by The University of Tennessee Extension Swine Specialists and the Agricultural Extension Education Department and agents conducted the survey during the fall of 1979. Information recorded included the farm characteristics of the swine producers, their use of recommended swine practices, and the number of contacts the producers had with the Extension office over a 12-month period. The data were coded and punched on computer cards, and computations were made by The University of Tennessee Computing Center. One way analysis of variance F-test and the chi square test were used to determine the significance and strength of the relationship between the dependent and independent variables. The .05 probability level was accepted as significant. Major findings Included the following: 1. The average swine producer surveyed had farrowed 45 litters and raised 275 pigs to weaning during the previous 12-month period. 2. Over 38% of the swine producers had not attended any Extension meetings and 6.2% had had no contacts with Extension through any of the contact methods (i.e., meetings, office visits, telephone calls, or farm visits) during the previous 12 months. 3. Fourteen of the 18 recommended swine production practices were used by at least 507. of the producers. Over 30% of the swine producers said pig scours was their most serious pig production problem. 4. Producers\u27 use of nine of the 18 recommended swine production practices was significantly related to each type of Extension contact and to the total number of contacts producers had with Extension agents over a 12-month period. Only two practices were not significantly related to at least one type of Extension contact (i.e., worming weaned pigs and treating pigs for lice). 5. The use of 13 of the 14 recommended pig production practices was significantly related to the type of swine operation (feeder pig or farrow-to-finish). A larger percentage of the farrow-to-finish producers used each of these 13 practices when compared to feeder pig producers. 6. A significantly larger percentage of the full time farmers than of the part time farmers were farrow-to-finish producers. 7. Farrow-to-finish producers made significantly more contacts with Extension than did feeder pig producers. Implications and recommendations also were made

Dimensions of consistency in source versions and system compositions

In building systems there are various levels at which we consider the problems reasoning about consistency and it means different things at those various levels. At the version management level, consistency means what it does in databases: no data is lost due to concurrency problems (eg, race conditions). At the composition and substitution (or creation and evolution) levels it means something that is significantly different--- namely, the syntactic and semantic consistency of the various pieces that make up the system. I first address the issue of what makes a system composition well-formed both syntactically and semantically. I then address the issue of substitution in well-formed system compositions, first in the context of simple substitution and then in the context of compound substitution (that is, the simultaneous substitution of multiple components). Note: This paper derived and extended from papers: the well-formed system composition paper [9] was published only as a technical report at CMU (though variously used without references or with misleading ones) the version control paper from ICSE9 [16], the extended abstract for SCM3 [19], and the shared dependency paper from SCM6 [20] all of which have been published only in conference or workshop versions. There may be parts of the other Inscape papers (ICSE9 [15], ICSE11 [17], and TAV3 [18]) included as well- all of which have been published only in conference versions

INFUSE Test Management

This technical report consists of the two papers discussing testing technology. INFUSE: Integration Testing with Crowd Control describes the test management facilities provided by the lNFUSE change management system. lNFUSE partially automates the construction of test harnesses and regression test suites at each level of the integration hierarchy from components available from lower levels. Adequate Testing and Object-Oriented Programming applies the axions of adequate testing to object-oriented programming languages and examines their implications. Contrary to our original expectations, we discover that in the general case classes must be retested in every context of reuse

Validity concerns in software engineering research

Empirical studies that use software repository artifacts have become popular in the last decade due to the ready avail-ability of open source project archives. In this paper, we survey empirical studies in the last three years of ICSE and FSE proceedings, and categorize these studies in terms of open source projects vs. proprietary source projects and the diversity of subject programs used in these studies. Our survey has shown that almost half (49%) of recent empirical studies used solely open source projects. Existing studies either draw general conclusions from these results or explic-itly disclaim any conclusions that can extend beyond specific subject software. We conclude that researchers in empirical software engi-neering must consider the external validity concerns that arise from using only several well-known open source soft-ware projects, and that discussion of data source selection is an important discussion topic in software engineering re-search. Furthermore, we propose a community research in-frastructure for software repository benchmarks and sharing the empirical analysis results, in order to address external validity concerns and to raise the bar for empirical software engineering research that analyzes software artifacts

Change Management Support for Large Software Systems

This technical report consists of three related papers in the area of management of source code changes for large software systems. Infuse: A Toolfor Automatically Managing and Coordinating Source Changes in Large Systems presents Infuse, a software engineering environment that automatically panitions the source code files to be changed in order to limit the complexity of change propagation and negotiation of conflicting changes. Workspaces and Experimental Databases: Automated Support for Cooperation Among Programmers describes Infuse in more detail, focusing on the interactions between Infuse and source code modification tools. Smarter Recompilation presents an algorithm that could be used by Infuse or other software engineering environments to reduce recompilation costs after source code changes

Understanding software development: Processes, organisations and technologies

Our primary goal is to understand what people do when they develop software and how long it takes them to do it. To get a proper perspective on software development processes we must study them in their context — that is, in their organizational and technological context. An extremely important means of gaining the needed understanding and perspective is to measure what goes on. Time and motion studies constitute a proven approach to understanding and improving any engineering processes. We believe software processes are no different in this respect; however, the fact that software development yields a collaborative intellectual, as opposed to physical, output calls for careful and creative measurement techniques. In attempting to answer the question "what do people do in software development? " we have experimented with two novel forms of data collection in the software development field: time diaries and direct observation. We found both methods to be feasible and to yield useful information about time utilization. In effect, we have quantified the effect of these social processes using the observational data. Among the insights gained from our time diary experiment are 1) developers switch between developments to minimize blocking and maximize overall throughput, and 2) there is a high degree of dynamic reassignment in response to changing project and organizational priorities. Among the insights gained from our direct observation experiment are 1) time diaries are a valid and accurate instrument with respect to their level of resolution, 2) unplanned interruptions constitute a significant time factor, and 3) the amount and kinds of communication are significant time and social factors.- 2-1

Are These Bugs Really "Normal"?

International audienceUnderstanding the severity of reported bugs is important in both research and practice. In particular, a number of recently proposed mining-based software engineering techniques predict bug severity, bug report quality, and bug-fix time, according to this information. Many bug tracking systems provide a field "severity" offering options such as "severe", "normal", and "minor", with "normal" as the default. However, there is a widespread perception that for many bug reports the label "normal" may not reflect the actual severity, because reporters may overlook setting the severity or may not feel confident enough to do so. In many cases, researchers ignore "normal" bug reports, and thus overlook a large percentage of the reports provided. On the other hand, treating them all together risks mixing reports that have very diverse properties. In this study, we investigate the extent to which "normal" bug reports actually have the "normal" severity. We find that many "normal" bug reports in practice are not normal. Furthermore, this misclassification can have a significant impact on the accuracy of mining-based tools and studies that rely on bug report severity information

On the Effectiveness of Information Retrieval Based Bug Localization for C Programs

International audienceLocalizing bugs is important, difficult, and expensive, especially for large software projects. To address this problem, information retrieval (IR) based bug localization has increasingly been used to suggest potential buggy files given a bug report. To date, researchers have proposed a number of IR techniques for bug localization and empirically evaluated them to understand their effectiveness. However, virtually all of the evaluations have been limited to the projects written in object-oriented programming languages, particularly Java. Therefore, the effectiveness of these techniques for other widely-used languages such as C is still unknown. In this paper, we create a benchmark dataset consisting of more than 7,500 bug reports from five popular C projects and rigorously evaluate our recently introduced IR-based bug localization tool using this dataset. Our results indicate that although the IR-relevant properties of C and Java programs are different, IR-based bug localization in C software at the file level is overall as effective as in Java software. However, we also find that the recent advance of using program structure information in performing bug localization gives less of a benefit for C software than for Java software