Reuse 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 the experience 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: The development organization develops 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. The experience factory supports 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.

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

No abstract

No abstract

No abstract