EP2069964A2 - Contextually analyzing data in tabular and graphical reports - Google Patents

Abstract

A set of tools and other mechanisms automatically enforce software development change policies by providing a way to map physical source control system codelines to projects and by providing a way to maintain current project and codeline state information. The set of tools and other mechanisms also provide ways to define change management rules and policies, as well as, ways to evaluate and allow or deny each proposed change against the defined change policy.

Description

CONTEXTUALLY ANALYZING DATA IN TABULAR AND GRAPHICAL REPORTS

CONTEXTUALLY ANALYZING DATA IN TABULAR AND GRAPHICAL REPORTS

HELD OF INVENTION

[0001] This invention relates to the enforcement of change policies in software development and related disciplines such as Computer Aided Design (CAD).

BACKGROUND

[0002] As part of the software development process, organizations define many policies to govern all aspects of the process. This is typically done to protect code quality and the organization' s intellectual property. These policies commonly include items such as (1) who can check- in, merge, branch or check-out code from what codelines at various stages of the development process; (2) what kinds of changes (new features, critical bug fixes, etc.) are allowed at various stages of the development process; and (3) what level of review is required for changes into codelines in the various stages of the development process.

[0003] Conventionally, these processes are enforced through management oversight.

Management oversight usually involves systems that include only very basic access controls to source control systems. In other words, these systems are typically all or nothing in nature: either allowing all authorized users to make changes at a given time or preventing all changes by any user. These simple measures do not allow organizations to automatically enforce more complicated change policies. This lack of enforcement can lead to unauthorized changes being made to sensitive work products. These unauthorized changes can (and often do) lead to system failures which can have large negative economic consequences.

[0004] Note that the approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued.

Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: [0006] FIG. 1 is a block diagram that illustrates an example operating environment for techniques described herein, according to one embodiment;

[0007] FIG. 2 is a flow diagram that illustrates a process for enforcing policies, according to one embodiment;

[0008] FIG. 3 is a flow diagram that illustrates a method for defining policy rules, according to one embodiment;

[0009] FIG. 4 is a block diagram that illustrates a system upon which embodiments of the invention may be implemented.

[0010] FIG. 5 is an example data set that is used to facilitate an explanation of embodiments of the invention;

[0011] FIG. 6 is a simple report displaying all bugs by operating system and priority;

[0012] FIGS. 7 A and 7B are block diagrams that illustrate a two step menu list that allows a user to two new dimensions for a new report;

[0013] FIG. 8 is a block diagram that illustrates a report that would be generated if a user selects Product by Assigned to as dimensions from the menu, according to an embodiment of the invention;

[0014] FIG. 9a and 9b are block diagrams that illustrate how valid dimensions would be displayed if a user chose to analyze the issues in an overall total cell, according to an embodiment of the invention;

[0015] FIG. 10 is a block diagram illustrating a report that would result from selecting reporter by assigned to, according to an embodiment of the invention;

[0016] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

[0017] FIG. 11 is a block diagram of a system configured to track and analyze defect density by source file, according to an embodiment of the invention;

[0018] FIG. 12 is a block diagram of process flow for capturing, validating and recording the files changed by task, according to an embodiment of the invention;

[0019] FIG. 13 illustrates a simple example of the raw data;

[0020] FIG. 14 illustrates a possible report output format, according to an embodiment of the invention; and

[0021] FIG. 15 is a block diagram of a system that may be used for capturing, validating and recording effort levels, according to an embodiment of the invention; [0022] FIG. 16 is flowchart illustrating a process flow for capturing, validating and recording effort levels, according to an embodiment of the invention;

[0023] FIG. 17A is block diagram illustrating a Screen Capture showing a form template inserted in CVS notepad checkin dialog box; and

[0024] FIG. 17B is a block diagram illustrating a Screen Capture showing a form template inserted in CVS Eclipse checkin dialog box.

DETAILED DESCRIPTION

[0025] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring embodiments of the present invention.

Method for enforcing Change policy based on project state

[0026] In one embodiment, mechanisms provide a simple but highly effective way to automatically enforce policies that control access to code based on the status of a project. These mechanisms allows users to define and enforce those policies at any time during the software development process. The software development process can also be referred to in terms of a lifecycle. Virtually every software development project goes through a project lifecycle. While different organizations use different terms and different numbers of states to define a project lifecycle, most organizations define a lifecycle that begins with formal specification requirements and ends when the software project is decommissioned. A simple, but not atypical, lifecycle of a software project might consist of the following 7 stages: (1) requirements gathering, (2) active development, (3) code complete, (4) code freeze, (5) beta testing, (6) production, and (7) end-of-life. Depending on the organization, a project lifecycle may also include other or different stages.

[0027] In one embodiment, at each stage in this process, software development organizations define different policies for what kinds of changes are allowed and by whom. For example, developers assigned to a project may be able to check-in changes at any time during the active development phase. While developers not assigned to the project are restricted from checking-in any changes to the project. As another example, during a code complete phase a policy may be enforced that only allows changes that are meant to fix bugs. As a third example, during a code freeze phase a policy may be implemented so that only changes to bugs of a certain priority level are allowed and, even then, all changes may need to be reviewed by a technical lead before being submitted. [0028] While the above examples are representative of the types of policies used during software development, the actual policies can be much more complex. Moreover, it can be common for these policies to vary significantly at each state in the project lifecycle. Unfortunately, current change management systems, do not allow for automatic policy enforcement based on project state. Hence, in one embodiment, mechanisms automatically enforce policies by providing a way to map physical source control system codelines to projects and a way to maintain current project and codeline state information. In an additional embodiment, mechanisms provide a way to define change management rules and policies, as well as, ways to evaluate and allow or deny each proposed change against the defined change policy.

POLICY ENFORCEMENT SYSTEM

[0029] FIG. 1 is a block diagram that illustrates example system 100 that performs techniques described herein, according to one embodiment. In other embodiments, system 100 may include a different set of tools and components. [0030] In one embodiment, system 100 includes Policy Enforcement tool 101 that works with Source Control Management (SCM) system 110 and Issue Tracking system 120. An SCM system, such as SCM system 110, can also be referred to as software change management systems. Popular examples of SCM systems include but are not limited to CVS, PVCS, and Perforce.

[0031] SCM system 110, in one embodiment, is designed to capture, store and manage access to and provide version control for software source files, designs, and similar files. This information can be stored by SCM system 110 in a repository such as SCM Store 111. Note that SCM Store 111 can be a standard database that maintains information and files related to a software development project. Alternatively, it may be some other type of repository. In addition to a store, SCM system 100 also may include the basic facilities to allow or deny changes to files during the software development process.

[0032] Policy Enforcement tool 101 can extends the facilities of SCM system 100 to enforce more sophisticated change policies (for example, those based on codeline state). In one embodiment, Policy Enforcement tool 101 can include a variety of components. Those components can include Change Capture component 102, Policy Evaluation and Enforcement component 103, Policy Database 104, and a set of Policy Definition and Administration components 105, 106, 107. In other embodiments, Policy Enforcement tool 101 may include a different set of tools and components. In addition, note that Policy Enforcement tool 101 and its components may be implemented in a variety of ways. For example, Policy Enforcement tool 101 may be a stand-alone program that includes application programming interface files to implement the various component tasks. Alternatively, Policy Enforcement tool 101 and/or its components may be implemented as dynamic link library files, as separate applications, or as integrated components, for example, of an SCM system.

[0033] According to one embodiment, Change Capture component 102 interacts with SCM system 110. Change Capture component 102, in one embodiment, intercepts proposed changes submitted by users to SCM system 110. From the intercepted data, Change Capture component 102 can capture any required information related to the proposed change (e.g., issue ID, or feature Id or enhancement ID) and can, in one embodiment, send a request to Policy Evaluation and Enforcement component 103 to approve the proposed change (e.g., by passing along all relevant details of the proposed change). Eventually, Change Capture component 102 receives a response from Policy Evaluation and Enforcement component 103 either accepting or rejecting the request. Depending on the response, Change Capture component 102 can either accept the proposed change or allow it to proceed into the SCM system or Change Capture component 102 can reject it and provide the user with an appropriate error message. [0034] When Policy Evaluation and Enforcement component 103 receives a proposed change, in one embodiment, it evaluates the proposed change against defined policy enforcement rules. Generally, a proposed change comes as input from Change Capture component 102, but in other embodiments, the proposed change may come from an alternative source. After receiving a proposed change, Policy Evaluation and Enforcement component 103, in one embodiment, retrieves the relevant rule set and other information from Policy Database 104 in order to determine if the proposed change should be accepted. In addition, Policy Evaluation and Enforcement component 103 can also communicate with the Issue Tracking System 120 to validate information gathered by Capture Change component 102 (e.g., issue IDs) and retrieve other relevant information needed to evaluate a rule (such as issue priority). In addition, Policy Evaluation and Enforcement component 103 may use well-known and widely implemented methods for the real-time evaluation of multiple rules. For example, Policy Evaluation and Enforcement component 103 may include a rules engine which has the capability to process and evaluate rules defined in a standard format. [0035] The set of Policy Definition and Rule Administration components 105, 106, 107 include those components that allow a software development process administrator to define and manage policies, codelines, and user-related information. According to one embodiment, the information defined by these components is stored in a Policy Database 104. These components are discussed in more detail below. [0036] In one embodiment, Policy Database 104 stores policy rules, codeline mappings, as well as, user, group and role information. Policy Database 104 may be implemented using an industry standard relational database management system (RDBMS), although other implementations (e.g., tables, arrays, text files, etc.) would work as well.

[0037] As with SCM systems, Policy Enforcement Tool 101 is designed to work with existing Issue Tracking Systems 120. Issue Tracking System 120 can include Issue Tracking Databases 121, which can be a repository that stores known issues related to the software being developed. In one embodiment, Issue Tracking System 120 is used to record and track both tasks that need to be completed for a project as well as open bugs and issues. Common examples of these systems include, but need not be limited to Bugzilla and Team Track.

MAPPING PHYSICAL SOURCE CONTROL SYSTEM CODELINE TO PROJECTS

[0038] To enforce policies by project state, in one embodiment, the system maps a physical source system codeline to projects, as well as, defines and maintains the state of these projects and what users or groups are assigned to these projects. [0039] For example, suppose two projects are actively being developed. One project is an application called "Sample Appl V3", which is made up of three modules (modulel, module2, and module3). The other project is "Sample App2 V6.1", which consists of four modules (module4, module5, moduleό, and module7). In this example, Sample Appl V3 is in the "development" phase and Sample App2 V6.1 is in the "Code Freeze" phase. Team 1 is assigned to Sample Appl V3 and Team 2 is assigned to Sample App2 V6.1. To map physical source control system codeline to projects, the SCM system is organized by module, with each module also having its own path in the system and each project having its own branch in the system. Table 1 below shows data that might be stored in the system for each project in this example: Project Name Sample App1 V3 Project Name Sample App2 V6.1

State Development State Code Freeze

Assigned Users Teami Assigned Users Team2

BranchlD main.app1 .v3 BranchlD main.app2.v61

Project Content and relative path Project Content and relative path

Modulei \module1 Module4 \module4

Module2 \module2 Moduleδ \module5

Module3 \module3 Moduleδ \module6

Module7 \module7

Table 1 - PROJECT DATA STORED IN AN SCM SYSTEM [0040] In Table 1, "State" is a foreign key reference to a table of valid states and "Assigned Users" is a foreign key reference to a table of valid users and groups. For simplicity and clarity other likely variables such as a unique project identifier, a project description, a project owner, and other project metadata have been omitted since they are not referred to in this example.

[0041] Based on the information stored in Table 1, when a change is submitted to the system, in one embodiment, the system determines what release/project this particular file belongs to and then checks the current state for that codeline. Based on that determination, system 100, as described herein, can invoke the appropriate set of policies to accept or reject submitted changes.

DEFINING CHANGE MANGEMENT POLICIES

[0042] In one embodiment, in addition to mapping codelines to projects, to control when and how changes are made to a project, an administrator uses tools to define change management policies. According to one embodiment, a change management policy consists of the following types of information: (1) a specified type of change that is being requested (e.g., check-in of a particular file or merge of two codelines); (2) a set of variables about the proposed change (e.g., what codeline is being changed, its state, who is making the change etc.); (3) a set of actions that can be taken for each type of change (e.g., accept, reject, notify etc.); and (4) a set of rules that combine the above 3 items to evaluate and process changes.

DEFINING TYPES OF PROPOSED CHANGES [0043] Accordingly, defining a change management policy, in one embodiment, includes first defining what types of changes trigger a rule. According to one embodiment, the changes that could trigger a rule include but are not limited to the following types of changes: (1) check-ins to an SCM system, (2) codeline merges in the SCM system, (3) branching in the SCM system, (4) check-outs from the SCM system, (5) downgrading or deferring of bugs in the bug system, and (6) closing of bugs in the bug system.

DEFINING VARIABLES ASSOCIATED WITH A PROPOSED CHANGE

[0044] Then, in one embodiment, for each of type of proposed change a wide range of variables can be used to help evaluate the proposed change. These variables can include but are not limited to: (1) the user, the user's role (e.g., manager, tech lead, junior programmer etc.), or the group membership of the person attempting to take the action; (2) the product or release the user is attempting to modify; (3) the state of the product or release the user is attempting to modify; (4) a valid work item ID in the issue/bug tracking system; (5) the priority of the work item / bug ID in the issue tracking system; (6) a valid reviewer ID; (7) a valid effort level entry; (8) information about whether a proposed change has passed automated quality assessment tests; (9) arbitrary Boolean operations on any data captured from the source SCM, bug-tracking or other system; (10) the size of the proposed change measured in terms of the # of lines of code changed; (11) the complexity of the code changes as measured by a code analysis tool; and (12) attributes on the particular module changes such as whether it is a critical or performance sensitive module Note that these are examples of the types of variables that may be used to help define a change management policy. Moreover, a proposed change may not need to include every single variable listed above. In fact, in many cases a proposed change utilizes fewer variables. In some cases, a proposed change may include no variables at all.

DEFINING SUPPORTED ACTIONS

[0045] Finally, a change management policy might include a wide range of output actions. In one embodiment, the output actions may need to be defined by the administrator so that proposed changes can occur. These actions can include, but are not limited to: (1) allow the change to proceed, (2) reject the change, (3) notify one or more people of the change, and (4) trigger an action on an external system such as the execution of a automated test suite or automated code analysis. In this way, the administrator can control how and when proposed changes occur. In other embodiments, a different set of supported actions may be defined.

[0046] By defining the changes that may occur, as well as the variables and actions that may trigger a change, administrators can define change policy rules.

[0047] In one embodiment, the change policy rules can be expressed using a variety of well known methods ranging from Boolean expressions to XML-based rules definition languages. Below is "Example Rule 1" expressed as a simple Boolean expression that says that check-ins (the change) to "development" state codelines must have a valid taskID (the variables) or they will be rejected (the action):

If change EQUALS check-in AND codeline_state EQUALS development AND taskID EXISTS THEN ACCEPT ELSE REJECT

Example Rule 1

[0048] In other embodiments, a change policy definition may include other or different information and/or be in another or different format.

EVALUATING AND ENFORCING CHANGE POLICY

[0049] According to one embodiment, once codelines are mapped and policies defined, then a change management policy can be enforced in a system. FIG. 2 is a flowchart that outlines process 200 that illustrates how a change policy is evaluated and enforced. Process 200 begins at step 210 with a developer submitting one or more proposed changes to an SCM system, such as SCM system 110 illustrated in FIG. 1. [0050] When the proposed change is submitted, information is captured from the proposed request in order to evaluate whether the change can proceed or not. In one embodiment, the information necessary to evaluate the proposed change includes determining an action (e.g., check- in, merge, etc.) in addition to a set of variables (e.g., files changed, user, taskID etc.). This information (and other information) is captured as part of the evaluation process. The determination can as to what type of action is being made can be determined, in one embodiment, by the SCM system or alternatively by a Policy Enforcement tool. The type of change being requested is generally implicit in the action the user is requesting be taken by the SCM system. Thus, the type of change being requested can be automatically captured by the system based on the request of the user. [0051] Other information can be captured as well. For example, a user submitting a change may have to be authenticated by the SCM system before a change can be submitted. Accordingly, the userID of the requesting user can be automatically captured by the system. This information as well as other variables, such as the names of files being changed, can also be automatically captured by the system as part of the normal change process.

[0052] In some cases, variable data, such as the taskID or reviewerID, may be input directly by the user or the user might be prompted to input the data. In one embodiment, some variables such as codeline state can be retrieved from the Policy, User and Group DB. Note that other variables and how those variables are obtained can vary from one implementation to the next. [0053] At step 220, in one embodiment, once the developer has submitted the proposed change and information from the proposed change captured, then, the system sends the captured information (e.g., what files were changed, the userID, the issue ID) to a policy enforcement module. The proposed change, in one embodiment, is not committed to the SCM system at this time, but is held in an "in-process" state. The in- process state indicates that the proposed change is being evaluated. [0054] At step 230, the policy enforcement module receives the proposed changes. Here, according to one embodiment, the system retrieves information in order to be able to evaluate the proposed change and determine if it will be allowed. For example, as discussed above in connection with FIG. 1, the following types of information may be retrieved to evaluate a proposed change: (1) the codeline in which the files with proposed changes reside (this information may be retrieved from a Policy, User and Codeline database); (2) the current status for this codeline (e.g., whether the codeline is in development, code-freeze, production etc.); (3) the project assignments for the developer requesting the change from the Policy, User and Codeline DB; and (4) the priority of the issueID from the Issue Tracking system.

[0055] At step 240, once that information has been gathered (e.g., from a Policy, Codeline, and User DB), the policy enforcement tool identifies policy rules which have been defined for the current state of the codeline the developer is attempting to modify. In this example, assume that the codeline is in a "code-freeze" state. Accordingly, the following rules may be retrieved from the DB: (1) only developers assigned to this project are allowed to check-in changes; (2) only changes for "high priority" issues are allowed; and (3) all other changes are rejected.

[0056] At step 250, the system evaluates whether the proposed change should be accepted. It does so by comparing the information it retrieved to the rules defined for the current codeline and codeline state. If the change violates any of the rules specified the change is rejected. In addition, the process can terminate and/or an error message may be displayed to the user. If the change does not violate any rules, the system accepts the change and "commits" it to the system.

[0057] In one embodiment, at step 260, the details (e.g., the time, date, user, bugID, files changed etc.) of the change are recorded, for example, in a Policy, Codeline, and User and DB to track all changes made to the project.

RULE DEFINITION PROCESS [0058] As described above, policy rules help define how, when, and by whom proposed changes can be committed to a system. According to one embodiment, policy rules are defined by a user, administrator, developer, etc. FIG. 3 is a flowchart that outlines process 300 for defining a set of policy rules. This process can be performed through a user interface that provides selectable controls that correspond to various rules options or the administrator may define the rules using text, markup text, a template, or some other means.

[0059] In one embodiment, process 300 begins with an administrator specifying the list (or at least a partial list) of release components that might be included in the next release (or update) of a project. In one embodiment, the list of release components can be a table in an SCM system, a record in a database, a text file, or some other mechanism that can be used to identify release components. The manner of the administrator uses to identify these components varies, for example, version numbers, file names, file metadata, header information, and other such mechanisms may all be used to identify the components.

[0060] Once an administrator has identified the set of release components, at step 320, for each component in the set, the administrator provides metadata such as the name and description of each component, as well as, a "branch" in the SCM system where the files for this component can be located. In this way, the administrator can customize what information is searched for by the various systems and components described herein.

[0061] At step 330, for each codeline the administrator chooses the appropriate state the release is in from a set of defined choices. For example, the release may be in a "code-freeze" state, "development" state, etc. By doing so, in one embodiment, the administrator is defining when a proposed change may be submitted to an SCM system. [0062] Then, in one embodiment, at step 340, the administrator defines which users or groups of users are assigned to this release. In this way, the administrator can control who accesses release files at the various stages of a project's lifecycle. [0063] Note that steps discussed above are described as occurring in a particular order. These steps may occur in any order. They may also occur independently of any other steps. In alternative embodiment, defining rules properly may include performing more or less than the steps enumerated above.

HARDWARE OVERVIEW [0064] FIG. 4 is a block diagram that illustrates a computer system 400 upon which an embodiment of the invention may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a processor 404 coupled with bus 402 for processing information. Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Computer system 400 further includes a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk or optical disk, is provided and coupled to bus 402 for storing information and instructions. [0065] Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

[0066] The invention is related to the use of computer system 400 for implementing the techniques described herein. According to one implementation of the invention, those techniques are performed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another machine-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, implementations of the invention are not limited to any specific combination of hardware circuitry and software.

[0067] The term "computer-readable medium" as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an implementation implemented using computer system 400, various machine-readable media are involved, for example, in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non- volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio- wave and infra-red data communications. All such media must be tangible to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine.

[0068] Common forms of machine -readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD- ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0069] Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404. [0070] Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0071] Network link 420 typically provides data communication through one or more networks to other data devices. For example, network link 420 may provide a connection through local network 422 to a host computer 424 or to data equipment operated by an Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 420 and through communication interface 418, which carry the digital data to and from computer system 400, are exemplary forms of carrier waves transporting the information.

[0072] Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418. [0073] The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution. In this manner, computer system 400 may obtain application code in the form of a carrier wave.

CONTEXTUALLY ANALYZING DATA IN TABULAR AND GRAPHICAL

REPORTS

[0074] Traditional multi-dimensional reporting mechanisms allow the user to change the dimensions of a tabular report (often called a pivot table) or click on a particular cell and "drill down" to see a more detailed view of that data item along the same dimensions as the current report. Current mechanisms allow either:

[0075] 1. The user to change the dimensions of the entire report

[0076] 2. User can take the data in a single cell and show it against two new dimensions

[0077] 2. View details of a single item in the same dimensions [0078] Neither of these mechanisms allows the user to perform instant analysis on a single data value across multiple dimensions. Therefore, an improved mechanism for multi-dimensional reporting is desirable.

[0079] Techniques are provided for analyzing data called "pivot points" which allows users to instantly generate a report based on all available dimensions for any cell in a tabular report or any data point in a graphical report. In one embodiment, the techniques involve:

[0080] 1. The system places a unique UI element or menu next to or on each data point

[0081] 2. Clicking on this UI element brings up an automatically filtered list of the valid reports or Dimensions available for just this sub-set of the data.

[0082] Once the user selects which view they want, a report is automatically generated based on those dimensions with just this subset of data

[0083] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0084] The FIGS. 5-8 illustrate how the Pivot Point method works with a very simple data set related to bugs in a software development setting. Software bugs were used for the example data set since it is likely familiar to most professionals working in software field. The approach described works independently of the kind of data being reported upon and could just as easily apply to virtually any data set.

[0085] Techniques described herein relate to how the end-user interacts with the data set in question, not how the data sets are stored or generated. So, the techniques work independently of how the data is stored and how the report itself is generated. The source data itself could be stored in a relational database (RDBMS), a multi-dimensional database, a spreadsheet or any other electronic store. The reports themselves could be generated using any of the many well known reporting techniques. [0086] Figure 5 provides an example data set. All other figures are based on this sample data. For simplicity the data set is small, but the techniques work with any multidimensional data set.

[0087] Figure 6 is a simple report displaying all bugs by operating system and priority. Notice the "pivot" icon next to each cell. A "right click" menu (a menu displayed when clicking the right or secondary mouse button in a standard graphical user interface) on the data element itself could also be used instead of the icon. [0088] Now for example suppose that the user is interested in the "Normal" priority Bugs on "Windows" operating system, by clicking on the "pivot point" next to this cell (Element 1), the system automatically gives the user the ability to select two new dimension for the new report on this subset of the data. This list of dimensions is automatically filtered by the data point in question. In this example, "Priority" is not shown as a valid dimension for further analysis. This is because all data elements in this cell are of a single priority (normal) so a further report on that dimension would not be meaningful. Similarly the "Operating System" dimension is not available because all data elements in this cell are related to a single Operating System, in this case "windows". [0089] From the two step menu list in Figures 7A and 7B, the user can select two new dimensions for the new report and the system will automatically generate that report based on the data in the active cell (in this case 2 normal bugs for windows). The system automatically filters the subsequent report to include just the data points underlying the cell in question.

[0090] Two step menu could easily be replaced by predefined reports list (which are on appropriate dimensions)

[0091] Figure 8 shows the report that would be generated if the user had selected

Product by Assigned to as dimensions from the menu. Notice that the report generated includes just the 2 normal windows bugs in question.

[0092] A similar approach can be applied to any data value in the report and a similar process is used to display on the meaningful dimensions for that particular data element.

To illustrate how this works with different data values in the same report, Figures 9A and

9B show the valid dimensions which would be displayed if the user chose to analyze the four issues in the overall total cell. All available dimensions are shown in this case however, since the data elements in question span multiple priorities and operating systems. After making selection in the first popup menu (in this case selecting

"reporter"), that selection is no longer available in the second popup menu.

[0093] Figure 10 shows the report that would result from selecting reporter by assigned to. Notice once again that the data set automatically filtered to the four issues in question.

[0094] The same techniques can be used with by clicking on "pivot points" next to or

"right clicking" on data elements in graphical reports such as bar charts, line charts, scatter plots etc.

Calculating Defect Density by File and Source Module

[0095] In software development and related fields, defects are tracked and analyzed in "bug tracking" or "task tracking" systems. When defects are entered into the system they are generally tracked and analyzed on such variables as, product version, platform, defect severity, and date entered. When defects are fixed, the defect tracking system is updated to change the status of the defect to resolved or closed. A short explanation or comment about the cause of the defect and the changes made to fix it are typically captured. [0096] These defect tracking systems are independent of the source control system which contains the actual work product (such as software code source code, design documents etc.) in question. As a result there is no correlation between the actual changes made to fix the defect and the information recorded in the defect tracking system. This lack of correlation between the defect tracked in the defect tracking system and the physical changes made to the source work product in the source control system presents many problems including:

• No ability to identify which source files or modules are most prone to defects.

• No ability to track whether the quality of a given source file or module is improving or declining over time

• No ability to prioritize quality assurance resources to test the most error prone files and modules

[0097] Organizations spend billions of dollars per year on quality assurance to find defects before product shipment. In addition, the economic cost of defects which are not found and cause later product failures is also very significant. So the inability of organizations to identify which source modules are most defect prone is a big issue with very real economic impacts.

[0098] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0099] Techniques are provided for tracking and analyzing defect density by source file or module. Defect density is the number of distinct defects which required changes to be made (to fix the defect) to a particular file or module in a given period of time. This metric is very useful for identifying the most critical areas of weakness of the system and hence the areas where additional investment/action may be taken. For example, this metric can be used to prioritize the area in which unit tests should be written, for which additional automated system tests should be written, or which project should be undertaken to re-write the error prone file or module to improve its quality and maintainability. FUNCTIONAL OVERVIEW

[00100] Techniques are provided for tracking and analyzing defect density by source file or module. Defect density is the number of distinct defects which required changes to be made (to fix the defect) to a particular file or module in a given period of time. In one embodiment, when a developer completes and "checks-in" the changes required to fix a defect into the source control system, the relevant defect tracking-ID from the defect tracking system is captured.

[00101] This defect ID is validated against the defect tracking system to ensure it corresponds to a valid, open defect. If the defect ID is valid the check-in is allowed to proceed, if not it is rejected.

[00102] For all completed check-ins (changes) the defect ID, and a list of all files/modules changed are captured and stored for later analysis.

[00103] Simply having a list of all files changed and defect IDs alone is not enough to provide a meaningful measure of defect density by file or module. The reason for this is that multiple versions of the same file typically exist in different versions of the same work product. These different versions are typically represented as different "branches" of the source control "tree". To solve this issue, all of the various physical version of the same file/module must be mapped back to a single logical entity, the canonical name of the file and corresponding module/component.

[00104] Having captured the above data, reports can now be generated which count the # of defects per source file/module over time. This defect density report can then be analyzed to determine which files/modules are most defects prone and whether the defect rate for a given file/module is increasing or decreasing over time. This data is very useful and can be used as a basis for quality assurance test prioritization and other corrective actions.

SYSTEM OVERVIEW

[00105] Figure #11 illustrates the major components of a system configured to perform the techniques described herein, and the relationship between those components and existing systems. The techniques described herein are designed to work with existing Source Control Management (SCM) systems (Figure #11 (a) & Q). These systems are sometimes also referred to as software change management systems. Popular examples of SCM systems include but are not limited to CVS, PVCS, and Perforce. SCM systems are designed to capture, store and manage access and provide version control for software source files, designs and similar files. SCM systems have basic facilities to allow or deny changes, the invention extends these facilities to enforce sophisticated change policies based on codeline state.

[00106] The Change Capture Component (Figure #11 (b)) intercepts proposed changes in the SCM system, captures any required information related to the proposed change (issue ID for example), "calls out" to the Data Validation Component (Figure #11 (c)) component passing along all relevant details of the proposed change and receives the response from the Data Validation Component (accept, reject etc.). Depending on the response, the Change Capture component either allows the proposed change to proceed into the SCM system or rejects it and provides the user with an appropriate error message. [00107] The Data Validation component (Figure #11 (c)) validates that the task ID is valid and that the hours entered are within an acceptable range. It takes input from the Change Capture components, retrieves the valid data ranges and other information from the Policy DB (Figure #ll(g)). It can also call out to the Issue Tracking System to validate Issue IDs or retrieve relevant information.

[00108] The Policy Administration Component (Figure #11 (d,e,f) allows the administrator to define and manage the Code Line Mapping and manage valid data ranges and userIDs for authorized users. The information defined in this component is stored in the Policy DB (Figure #ll(g)). The Policy DB (Figure #11 (g)) stores the codeline mapping and related information along with the names and userIDs of authorized users. This DB would typically be implemented using an industry standard relational database management system (RDBMS), although other implementations would be acceptable. [00109] As with SCM systems, the invention is designed to work with existing Issue Tracking Systems and Issue Tracking Databases (Figure #11 (h, i)). These systems are used to record and track both tasks that need to be completed for a project as well as open bugs and issues. Common examples of these systems include, but need not be limited to Bugzilla and Team Track.

Mapping Physical Source Control System Codeline to Projects

[00110] To enforce track bug density by module, one must be able to map changes to individual files in individual source control branches to all the other versions of those same files and modules in other source control branches. [00111] For example, suppose there are two active projects, one to release an application called "Sample Appl V3" which is made up of three modules (moduleA, moduleB, moduleC) and another called "Sample App2 V6.1" consisting of four modules (moduleD, moduleE, moduleF and moduleG). Sample Appl V3 is in the "development" phase and Sample App2 V6.1 is in the "Code Freeze" phase. Team 1 is assigned to Sample Appl V3 and Team 2 is assigned to Sample App2 V6.1. The source SCM system is organized by module, with each module having its own path and each project having its own branch. The table below shows the minimal data that would be captured for this example:

Product Name Sample App1 Product Name Sample App 1

Project Name Sample App1 V3 Project Name Sample App 1 V4

Branch Path Prefix /depot/p1 Branch Path Prefix /depot/p2

Project Content and relative path Project Content and relative path

ModuleA /moduleA Modulei /moduleA

ModuleB /moduleB Module2 /moduleB

ModuleC /moduleC Module3 /moduleC

[00112] With the above information whenever a change is made to any file, the system is able to determine what module that file is associated with regardless of which branch or release is being updated.

Capturing, Validating and Files Changed by Task

[00113] Figure #12 outlines the process flow for capturing, validating and recording the files changed by task using the components described above. The process begins with the developer submitting the proposed change(s) to the source control system (figure #12, (a))-

[00114] When the change is submitted the variables necessary (user, taskID and files modified) to evaluate the requested change are captured as part of this process. The data captured is outlined below:

• Since any user submitting a change would have already been authenticated by the SCM system, the userID of the requesting user would be automatically captured by the system

• The taskID associated with the proposed change

• The files changed as part of this check-in

• Any other variable which might be helpful in subsequent analysis of the data such as root cause or effort level.

[00115] Once the developer has submitted the change, the program sends the information captured to the Data Validation Component (figure #12, (b)). Note, the changes are not "committed" to the source control system at this time, but are held in an in-process state.

[00116] When the Data Validation Component receives the proposed changes (figure #12, (c)), the program retrieves the information necessary and validates that the taskID is valid by querying the issue tracking system. If either the taskID is invalid the change is rejected, with the SCM system being notified to reject the change and the end-user receiving an appropriate error message. If the data values are valid, the SCM system is notified to accept the change and "commit" it to the system.

Data Synchronization

[00117] Once the change has been successfully committed to the SCM system, the committed data must be recorded for reporting purposes. This extra step is required since while the Data Validation Component has notified the SCM system that it "can" accept the change, the SCM system is not required to do so and may still reject the change for some other reason (the file is locked by another user for example). To address this issue, once the change has been committed to the SCM system a background job creates a copy of the check-in data in and moves it into a separate reporting database. This is typically a relational database management system (RDBMS), but other implementation would be acceptable.

[00118] Calculating Bug Density by File or Module

[00119] Once the data has been captured as described above we have the following information available for reporting:

• All changes are now associated with a valid taskID

• For each taskID the files changed in working on that task / bug

• A mapping of files to modules across one or more releases

• The date on which each task/bug was fixed

[00120] With the above information stored in a standard database we can now calculate the number of bugs per file or module over a given period of time. This report can be generated in a variety of ways depending on the kind of data store and reporting tool being used. Further we can filter the data by various criteria to get reports of bug density on filtered data. One such example may be a report of Bug Density for Pl priority bugs. The Figure #13 provides a simple example of the raw data and Figure #14 one possible report output format. [00121] The system can also generate all of these reports by filtering on various dimensions, e.g. One may be interested in finding bug density for just the critical bugs (Pi's) as that will indicate the sources of critical issues. Such a report will be as follows:

Bug Density by Module (Pi's only)

[00122] The system can also get various other views by filtering appropriately. CAPTURING EFFORT LEVEL BY TASK UPON CHECK-IN TO SOURCE

CONTROL MANAGEMENT SYSTEM

[00123] A key requirement for effectively managing software development and similar projects is the ability to track effort level information (i.e. how many hours were spent on performing the activity) for a particular task or activity. This information is critical in assessing whether a project is on schedule and is often used to determine the cost and/or billing of a particular project.

[00124] Existing systems of tracking effort level require the user to first check in their artifacts in various systems such as the source control management (SCM) system and then go to a separate time tracking system and enter their effort level information for the particular task. The problem with this set up is that people often forget to update the time tracking system after "checking in" their artifacts. Also, since one may update the time tracking system sometime after the actual completion of work, it is likely that it will have less accuracy than information which is input at the time the change is made. [00125] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[00126] Techniques are provided for capturing the ID of a work item, and the corresponding effort level information, as a part of the actual check-in process of the artifacts into the underlying change management system. This effort information can then be propagated to an external system for subsequent reporting and analysis. A summary of the steps involved in this process are outlined below.

[00127] Tasks (or similar items such as issues or bugs) are entered into a common task or issue tracking system. As part of this process each task is assigned a unique identifier.

[00128] A "call-out" is added to the source control management system which captures the effort level and task ID associated with the proposed change.

[00129] The data entered is validated to ensure that the task ID is valid and that the effort entered is within a valid range.

[00130] If the data entered is valid, the change to the underlying artifact is allowed to proceed and the effort and task information is stored for later analysis. If the data is not valid, the proposed change is rejected and an appropriate error message is returned to the user.

Major Components

[00131] Figure #15 illustrates the major components of a system designed to implement the techniques described herein. FIG. 15 also illustrates the relationship between those components and existing systems. A system that implements the techniques described herein may work with existing Source Control Management (SCM) systems (Figure #15 (a) & (j). These systems are sometimes also referred to as software change management systems. Popular examples of SCM systems include but are not limited to CVS, PVCS, Clear Case, Accurev, Subversion and Perforce. SCM systems are designed to capture, store and manage access and provide version control for software source files, designs and similar files. SCM systems have basic facilities to allow or deny changes, the invention extends these facilities to capture effort and related task information as part of the routine change management process.

[00132] The Change Capture component (Figure #15 (b)) intercepts proposed changes in the SCM system and captures the required effort and task information related to the proposed change, "calls out" to the Data Validation Component (Figure #15 (c)) passing along all relevant details of the proposed change and receives the response from the Data Validation Component (accept, reject etc.). To facilitate the proper entry of the data, the change control component inserts a template into the SCM system commit form to allow users to enter appropriate information. (A sample screen capture of the form template is show in figures 3a (form template in notepad editor) and 3b (form template in eclipse)) Depending on the response, the Change Capture component either allows the proposed change to proceed into the SCM system or rejects it and provides the user with an appropriate error message.

[00133] The Data Validation component (Figure #15 (c)) validates that the task ID is valid and that the hours entered are within an acceptable range. It takes input from the Change Capture components, retrieves the valid data ranges and other information from the Policy DB (Figure #15(g)). It can also call out to the Issue Tracking System to validate Issue IDs or retrieve relevant information.

[00134] The Policy Administration Component (Figure #15 (d, f) allows the administrator to define and manage valid data ranges and userIDs for authorized users. The information defined in this component is stored in the Policy DB (Figure #15(g)). The Policy DB (Figure #15 (g)) stores the policy rules and related information along with the names and userIDs of authorized users. This DB would typically be implemented using an industry standard relational database management system (RDBMS), although other implementations would be acceptable.

[00135] As with SCM systems, the techniques described herein are designed to work with existing Issue Tracking Systems and Issue Tracking Databases (Figure #15 (h, i)). These systems are used to record and track both tasks that need to be completed for a project as well as open bugs and issues. Common examples of these systems include, but need not be limited to Bugzilla and Team Track.

Capturing, Validating and Recording Effort Level by Task

[00136] Figure #16 outlines the process flow for capturing, validating and recording the effort level by task evaluating using the components described above. The process begins with the developer submitting the proposed change(s) to the source control system (figure #16, (a)).

[00137] When the change is submitted the variables necessary (user, taskID and effort) to evaluate the requested change are captured as part of this process. The data captured is outlined below: • Since any user submitting a change would have already been authenticated by the SCM system, the userID of the requesting user would be automatically captured by the system

• The taskID associated with the proposed change

• Effort level (typically expressed in minutes, hours or days)

• Any other variable which might be helpful in subsequent analysis of the effort data such as root cause.

[00138] Once the developer has submitted the change, the program sends the information captured to the Data Validation Component (figure #16, (b)). Note, the changes are not "committed" to the source control system at this time, but are held in an in-process state.

[00139] When the Data Validation Component receives the proposed changes (figure #16, (c)), the program retrieves the information necessary and validates that the taskID is valid (by querying the issue tracking system) and that the effort entered is within the valid range (by retrieving this range from the Policy DB).

[00140] If either the taskID is invalid or the effort level is not within the allow range the specified the change is rejected, with the SCM system being notified to reject the change and the end-user receiving an appropriate error message. If the data values are valid, the SCM system is notified to accept the change and "commit" it to the system. At this point the effort level and associated taskID is also recorded for later reporting. The effort data captured could be sent to the issue tracking system and recorded along with there with the task or it could be stored in a separate reporting database for later analysis. [00141] Figure 17a is a block diagram illustrating a Screen Capture showing a form template inserted in CVS notepad checkin dialog box.

[00142] Figure 17b is a block diagram illustrating a Screen Capture showing a form template inserted in CVS Eclipse checkin dialog box.

[00143] In the foregoing specification, implementations of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A computer-implemented method comprising: receiving user input that selects a single data point in a report; and in response to the user input, automatically filtering a list of available reports, based on selection of the single data point, to generate a filtered list of valid reports available for the single data point; and displaying the filtered list of available reports.

2. The method of Claim 1 further comprising displaying a unique UI element for each data point in said report, wherein receiving user input involves receiving user input through the unique UI element that is associated with said single data point.

3. The method of Claim 2 wherein displaying a unique UI element for each data point includes displaying a separate icon for each data point.

4. The method of Claim 1 wherein the single data point is a cell in a tabular report.

5. The method of Claim 1 wherein the single data point is a data point in a graphical report.

6. The method of Claim 1 wherein the user input is a right-click on a region of a display that is associated with the single data point.

7. The method of Claim 1 wherein: the user input is first user input; the method further includes receiving second user input that selects a view from the filtered list of available reports; and in response to the second user input, automatically generating a data-point- specific report that includes only data associated with the single data point.

8. The method of Claim 7 wherein: the each report on the set of filtered reports corresponds to a set of one or more dimensions; and the step of automatically generating a data-point-specific report includes generating the data-point-specific report based on the set of dimensions associated with the view selected by the second user input.

9. A method for enforcing change policies in a software development environment comprising: receiving at a source control system a request to make a change to a project; before making said change, retrieving from said request metadata associated with said change; evaluating said metadata against one or more policy rules defined for said project; and if said metadata conforms to said one or more policy rules, storing said change in the source control system, else rejecting said change.

10. The method of claim 9, wherein said metadata includes user authentication information.

11. The method of claim 9, wherein said metadata includes information about the driver for said change.

12. The method of claim 11 wherein the information includes at least one of: a software defect, a feature id, or an enhancement id.

13. The method of claim 9, wherein evaluating said metadata comprises: determining a status for said project; and comparing said status to a state indicated by said one or more policy rules.

14. The method of claim 9, further comprising maintaining a state of said project and a state of a codeline.

15. The method of claim 14, further comprising maintaining a mapping between said project and said codeline.

16. The method of claim 9, wherein said policy rule is user-defined.

17. The method of claim 9, wherein if the change is rejected displaying an error message to a user.

18. The method of claim 9, wherein evaluating said metadata includes performing a real-time evaluation of the one or more policy rules.

19. The method of claim 18, wherein said real-time evaluation is performed by a rule engine.

20. The method of claim 9, further comprising recording whether the change was made to the project.

21. A computer-implemented method comprising: generating a defect density value for each unit of a plurality of units that contain code for a computer program; wherein the defect density value indicates how many distinct defects in said unit required changes to be made.

22. The method of Claim 21 wherein: said plurality of units are a plurality of modules of said computer program; and generating a defect density value for each unit of a plurality of units that contain code for a computer program includes generating a defect density value for each module of said plurality of modules.

23. The method of Claim 21 wherein: said plurality of units are a plurality of files that contain code for said computer program; and generating a defect density value for each unit of a plurality of units that contain code for a computer program includes generating a defect density value for each file of said plurality of files.

24. The method of Claim 21 further comprising prioritizing writing of tests for said units based on defect density values generated for said units.

25. The method of Claim 21 wherein the step of generating a defect density value for each unit of a plurality of units that contain code for a computer program includes: mapping multiple physical versions of a particular unit of said plurality of units to a single logical entity; and determining the defect density value for said particular unit based on a defect density value for said single logical entity based on how many distinct defects in said multiple physical versions required changes to be made.

26. The method of Claim 21 further comprising repeating the step of generating a defect density value for each unit for each time interval of a plurality of time intervals.

27. The method of Claim 26 further comprising using the defect density values, generated for a given unit over said plurality of time intervals, to determine whether the defect rate for said given unit is increasing or decreasing over time.

28. The method of Claim 25 wherein: the plurality of units are a plurality of files; and the method further comprises using a canonical name of a file, of the plurality of files, to determine the single logical entity to which the file corresponds.

29. A computer-implemented method comprising: receiving input representing a proposed change to a software source file; in response to the input, capturing an effort level and task ID associated with the proposed change; making said proposed change; storing data that indicates the task ID; and storing data, in association with the task ID, that indicates the effort level.

30. The method of Claim 29 further comprising the step of, before making said proposed change, validating the captured effort level and task ID to ensure that the effort level is within a valid range, and the task ID is a valid task ID.

31. The method of Claim 30 wherein the steps of making said proposed change; storing data that indicates the task ID; and storing data, in association with the task ID, that indicates the effort level; are all performed in response to determining that the effort level is within the valid range and the task ID is a valid task ID.

32. The method of Claim 29 wherein receiving input representing a proposed change to a software source file includes intercepting a proposed change that is being submitted to a source code management system.

33. A computer-readable storage medium comprising instructions for performing the method recited in any one of Claims 1-32.