How the TSP Impacts the Top Line

W hen thinking about productivity improvements, engineering management does not usually have precise data from which to determine the implications to the profit-and-loss statement of the organization. Deploying a new technology such as object oriented design is often done because everyone else in the industry is doing it, and the engineers want to use the latest hot technology. It is unclear how such process changes will impact the balance sheet; there is often no way to actually measure improvements. As a result, many organizations go year after year without knowing if meaningful improvement has occurred. Few organizations know the actual dollar cost of a thousand lines of code (KLOC); they think about head-count on a project, or person-years of effort, and so on. But when attrition is high and team turnover is not accurately measured, development costs become clouded. This article will present a model of determining process effectiveness using the Team Software Process SM (TSP SM). The costs to produce a KLOC using the TSP will be compared to a more traditional process focused on testing in quality. Finally, total lifetime costs of the TSP will be compared to the test-based process. A simple model of a development process is used as the basis for comparison. The model will have five major phases: requirements (REQ), high-level design (HLD), implementation (IMPL), test (TEST), and release (REL). The detailed phase breakdown is shown in Table 1. These phases represent the work required of a software development project and whether or not a process actually produces these products. All systems have requirements; however, not all processes produce them. To determine cost, two pieces of information are needed: how much time is spent in each phase and the cost of an engineer's time. The problem is that most software organizations do not have this information available. Therefore, it is necessary to take known aspects of development and infer other information in order to determine how much time is spent in each activity. For example, many organizations have measured the time to find and fix defects in various test activities, along with the expected numbers of defects found in these activities [1, 2]. Then this information can be used to determine the time spent in test. Using such data, Table 2 (see page 10), on percentage of time spent in phase, was created. The numbers for the traditional test-based process agree with studies that …