Most of today's products and services are software-based. Organizations that develop software want to maintain and improve their competitiveness by controlling software-related risks. To do this, they need to align their business goals with software development strategies and translate them into quantitative project management. There is also an increasing need to justify cost and resources for software and system development and other IT services by demonstrating their impact on an organization's higher-level goals. For both, linking business goals and software-related efforts in an organization is necessary. However, this is a challenging task, and there is a lack of methods addressing this gap. The GQM + Strategies ® approach effectively links goals and strategies on all levels of an organization by means of goal-oriented measurement. The approach is based on rationales for deciding about options when operationalizing goals and for evaluating the success of strategies with respect to goals. Keywords Need for Business AlignmentAlong with the growth in society's dependence on software and other forms of information technology (IT), the size and complexity of software systems have also grown. This has only magni-fied the cost, schedule, and quality concerns that have always plagued software development efforts. For decades, software engineering researchers and practitioners have attempted to control and reduce the costs of building software, to produce working software within shorter periods of time, and to increase the quality of the software produced. While great strides have been made in all three areas, the growth of software, along all dimensions (size, complexity, pervasiveness, criticality, etc.), has outpaced our ability to control all the factors related to its development.What has become clear, however, is that the issues related to software cost, schedule, and quality are inextricably linked with larger issues facing the businesses that develop the software. Such businesses come in a variety of flavors. Some are in the business of selling the software they develop to customers, either as custom-built software on contract or shrink-wrapped applications for some segment of the population. Others are in the business of selling some product or service, of which software is a significant component. Still others may only develop software to support their internal IT infrastructure, and do not sell software-related products. Some software organizations are not in business at all, but are non-profit organizations, government entities, or educational institutions. While all these organizational configurations provide quite different challenges to their development projects, the key here is that all software is developed within a larger business context, encompassing larger business goals, strategies, and measures of success.While all businesses employ various strategies to achieve their objectives, these objectives are not always stated explicitly or clearly enough to allow one to check whether or not ...

Software inspections provide a proven approach to quality assurance for software products of all kinds, including requirements, design, code, test plans, among others. Common to all inspections is the aim of finding and fixing defects as early as possible, and thereby providing cost savings by minimizing the amount of rework necessary later in the lifecycle. Measurement data, such as the number and type of found defects and the effort spent by the inspection team, provide not only direct feedback about the software product to the project team but are also valuable for process improvement activities.In this paper, we discuss NASA's use of software inspections and the rich set of data that has resulted. In particular, we present results from analysis of inspection data that illustrate the benefits of fully utilizing that data for process improvement at several levels. Examinin g such data across multiple inspections or projects allows team members to monitor and trigger cross project improvements. Such improvements may focus on the software development processes of the whole organization as well as improvements to the applied inspection process itself. KeywordsFormal software inspections, measurement and analysis, process monitoring and improvement, management by data, NPR 7150.2

This paper describes our experience in aggregating a number of historical datasets containing inspection defect data using different categorization schemes. Our goal was to make use of the historical data by creating models to guide future development projects. We describe our approach to reconciling the different choices used in the historical datasets to categorize defects, and the challenges we faced. We also present a set of recommendations for others involved in classifying defects.