The investigation of vehicle defects, which is generally led by the National Highway Traffic Safety Administration (NHTSA) in the U.S., is critical to the continued trust of the general public in the safety of vehicles. NHTSA routinely receives millions of reports of potential defects, complaints, recalls, and manufacturer communications, which may provide evidence of a new vehicle defect. However, the large quantity and text-based communication make efficiently identifying defect trends difficult for analysts. To accelerate the investigation of defect reports, we introduce a natural language processing (NLP) application that identifies key topics and similar defect reports to assist analysts and investigators. Further, our application is built to provide users with a web interface for interacting with the NLP models. The integration of NLP with current NHTSA datasets provides a method for quickly identifying defect trends in large text-based datasets. To demonstrate the effectiveness of our method, we apply our approach to two publicly available NHTSA datasets, namely the Technical Service Bulletins and Recalls Dataset.

The object oriented paradigm has become widely used to develop large information systems. This paper presents a method for estimating the size and effort of developing object oriented software. The approach is analogous to function points, and it is based on counting rules that pick up the elements in a static object model and combine them in order to produce a composite measure. Rules are proposed for counting "Object Oriented Function Points" from an object model, and several questions are identified for empirical research.A key aspect of this method is its flexibility. An organization can experiment with different counting policies, to find the most accurate predictors of size, effort, etc, in its environment."Object Oriented Function Points" counting has been implemented in a Java tool, and results on size estimation obtained from a pilot project with an industrial partner are encouraging.

Abstract As with any engineering discipline, software development requires a measurement mechanism for feedback and evaluation. Measurement supports creating a corporate memory and is an aid in answering a variety of questions associated with the enactment of any software process. Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action. According to many studies made on the application of metrics and models in industrial environments, measurement in order to be effective must be. Focused on specific goals Applied to all life‐cycle products, processes, and resources Interpreted on the basis of characterization and understanding of the organizational context, environment, and goals This means that measurement must be defined in a top‐down fashion. It must be focused, based on goals and models. A metric‐driven, bottom‐up approach, will not work because there are many observable characteristics in software (e.g., time, number of defects, complexity, lines of code, severity of failures, effort, productivity, defect density). A context specific selection of metrics and guidelines on how to use and interpret them should be made, based on the appropriate models and goals of that environment. The most common and popular mechanism for goal‐oriented software measurement is the Goal Question Metric approach which is presented in this article in combination with examples from GQM application in industry

AbstractReuse of products, processes, and experience originating from the system life cycle is seen today as a feasible solution to the problem of developing higher quality systems at a lower cost. In fact, quality improvement is very often achieved by repeatedly reusing and modifying the same elements, learning about them by direct experience.This article presents an infrastructure, called theexperience factory, aimed at capitalization and reuse of life‐cycle experience and products. The experience factory is a logical and physical organization, and its activities are independent from those of the development organization. The activities of the development organization and of the experience factory can be summarized as follows:Thedevelopment organizationdevelops and delivers systems with the aid of analyzed, synthesized, and packaged experiences from the experience factory. It provides the experience factory with raw project information such as developmental and environmental characteristics, product parts, processes, and resource and defect data, representing the project being developed.Theexperience factorysupports project developments with direct feedback by analyzing and synthesizing all kinds of experiences gathered from projects as well as other state‐of‐the‐practice notions and acting as a repository for such experiences. These experiences include locally calibrated cost estimation models, processes demonstrated effective for the development environment, relevant products and product parts, and quality models.

We present a method for estimating the size, and consequently effort and duration, of object oriented software development projects. Different estimates may be made in different phases of the development process, according to the available information. We define an adaptation of traditional function points, called “Object Oriented Function Points”, to enable the measurement of object oriented analysis and design specifications. Tools have been constructed to automate the counting method. The novel aspect of our method is its flexibility. An organization can experiment with different counting policies, to find the most accurate predictors of size, effort, etc. in its environment. The method and preliminary results of its application in an industrial environment are presented and discussed.

We present a method for estimating the size, and consequently effort and duration, of object oriented software development projects. Different estimates may be made in different phases of the development process, according to the available information. We define an adaptation of traditional function points, called Object Oriented Function Points, to enable the measurement of object oriented analysis and design specifications. Tools have been constructed to automate the counting method. The novel aspect of our method is its flexibility. An organisation can experiment with different counting policies, to find the most accurate predictors of size, effort, etc. in its environment. The method and preliminary results of its application in an industrial environment are presented and discussed.

The Process Reuse Study (PRS) is dedicated to research related to software development and maintenance processes. These processes are key elements in understanding and improving the practice of software engineering. PRS attempts to provide a holistic vision by de ning a life cycle for software processes and methods for designing, improving, and performing software process models. In this report, we describe the motivation and rationale for the various areas of research of PRS and present our current status.

This paper presents a method for estimating the development size and effort of object oriented software. In an approach analogous to function points, counts of the elements in a static object model are combined to produce a composite measure. Rules are proposed for counting "Object Oriented Function Points" from an object model, and several questions are identified for empirical research. A key aspect of our method is its flexibility. An organization can experiment with different counting policies, to find the most accurate predictors of size, effort, etc. in its environment. Results are reported from a pilot project with an industrial partner. Size estimation was the subject of the study; the results are encouraging.

An object-oriented framework is an OO class hierarchy augmented with a built-in model which defines how the objects derived from the hierarchy interact with one another. Thus, a framework is more than a class library: it is a generic solution within a problem domain because the model of interaction is domain-specific. A framework is tailored to solve a particular problem by customizing its abstract and concrete classes. The framework architecture is reused by all specific solutions in that problem domain. By providing both design and infrastructure for developing applications, the framework approach promises to develop applications faster [Lew95]. The most popular frameworks are in the GUI application domain (e.g., MacApp, ET++, CommonPoint) and in the drawing domain (e.g., HotDraw, UniDraw), but frameworks have also been developed in other domains such as multimedia, manufacturing, financial trade, and data access.

Software reading is a key technical activity that aims at achieving whatever degree of understanding is needed to accomplish a particular objective. The various work documents associated with software development (e.g., requirements, design, code, and test plans) often require continual understanding, review and modification throughout the development life cycle. Thus software reading, i.e., the individual analysis of textual software work products, is the core activity in many software engineering tasks: verification and validation, maintenance, evolution, and reuse.

This paper presents an approach for defining evaluation criteria for reusable software components. We introduce a taxonomy of factors that influence selection, describe each of them, and present a hierarchical decomposition method for deriving reuse goals from factors and formulating the goals into an evaluation criteria hierarchy. We present some highlights from two case studies in which the approach was applied. The approach presented in this paper is a part of the OTSO method that has been developed for reusable component selection process.

This paper presents the OTSO method for reusable component selection. The OTSO method has been developed to provide a basis for evaluating and selecting reusable components for software development. The main characteristics of the OTSO method include (i) a well-defined, documented process, (ii) hierarchical and detailed evaluation criteria decomposition and definition, (iii) a model for making alternatives comparable in terms of cost and added value they produce, and (iv) use of appropriate techniques for consolidating evaluation data. The OTSO method has been evaluated in two real-world case studies. The case studies indicated that a well-defined process allows the selection process to take place efficiently, the overhead of formal criteria definition is marginal, and the use of different data consolidation methods may influence the results. * This work has been sponsored by the Hughes Information Technology Corporation.

As with any engineering discipline, software development requires a measurement mechanism for feedback and evaluation. Measurement is a mechanism for creating a corporate memory and an aid in answering a variety of questions associated with the enactment of any software process. It helps support project planning (e.g., How much will a new project cost?); it allows us to determine the strengths and weaknesses of the current processes and products (e.g., What is the frequency of certain types of errors?); it provides a rationale for adopting/refining techniques (e.g., What is the impact of the technique XX on the productivity of the projects?); it allows us to evaluate the quality of specific processes and products (e.g., What is the defect density in a specific system after deployment?). Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action.

Software reuse can be achieved through an organization that focuses on utilization of life cycle products from previous developments. The component factory is both an example of the more general concepts of experience and domain factory and an organizational unit worth being considered independently. The critical features of such an organization are flexibility and continuous improvement. In order to achieve these features we can represent the architecture of the factory at different levels of abstraction and define a reference architecture from which specific architectures can be derived by instantiation. A reference architecture is an implementation and organization independent representation of the component factory and its environment. The paper outlines this reference architecture, discusses the instantiation process, and presents some examples of specific architectures by comparing them in the framework of the reference model.

Identification and qualification of reusable software based on software models and metrics is explored. Software metrics provide a way to automate the extraction of reusable software components from existing systems, reducing the amount of code that experts must analyze. Also, models and metrics permit feedback and improvement to make the extraction process fit a variety of environments. Some case studies are described to validate the experimental approach. They deal with only the identification phase and use a very simple model of a reusable code component, but the results show that automated techniques can reduce the amount of code that a domain expert needs to evaluate to identify reusable parts.< >