A measurement and analysis process provides the mechanisms for identifying and addressing information needs of all types and levels. It addresses both the selection of appropriate measures to satisfy the information needs and the collection and analysis of the data. Information products make up the primary output of the measurement process.
The T-VEC modeling and tools provide measures that can support project and product measurement.
An attribute is a property or characteristic of a process or product that is the subject of measurement. Four attributes support T-VEC-related measurement analysis: DCPs (requirement threads), object mappings, requirements, and variables.
A base measure is a quantification of a single attribute obtained from some method or operation. There are several possible base measures that can be obtained through operations associated with the T-VEC attributes.
|Number of DCPs||DCPs produced during a particular measurement period|
|Number of variables||Input and output variables produced during a particular measurement period that require a corresponding object mapping|
|Number of object mappings||Object mappings specified during a particular measurement period|
|Total number of DCPs||Sum of the DCPs measured from the start of the project|
|Total number of variables||Sum of input and output variables measured from the start of the project|
|Total number of object mappings||Sum of specified object mappings measured from the start of the project|
|Total number of requirements||Sum of total requirements being modeled using TAF for the project|
To better understand the progress being made during project development, it is necessary to measure the DCPs, object mappings, and variables produced each week (these measures could be tracked daily, monthly, or yearly). Although it is idealistic to think that the total number of requirements will remain constant for a project, this seldom happens, so the total number of requirements for a project also should be monitored weekly. Fortunately, the total number of DCPs is generated as part of the status report for a project. Similarly, number of variables and object mappings produced each week can be recorded at the same time as the DCPs, etc.
A derived measure combines two or more base measures using a mathematical function. For example, the requirements per DCP is a derived measure relating the number of requirements to modeled-derived DCPs. If a project manager can estimate the total number of requirements that must be modeled, it is possible to predict the total number of DCPs for the project. If the rate of DCP production per week were known, the scheduled end date could be predicted. This report assumes that the measurement period is weekly. Table 8 identifies some derived measures.
|DCP rate||The average number of DCPs produced per week|
|DCP rate (current week)||The average number of DCPs produced per week at some week, where current week is a week number starting from the beginning of the project|
|DCP density||The number of DCPs per requirement|
|Object mapping rate||The average number of object mappings specified per week|
|Object mapping rate (current week)||The average number of object mappings specified per
week at some week
|Variables per DCP||The number of input and output variables per DCP|
These types of derived measures can be associated with an individual, project, project team, product, product family, business unit, or an entire corporation. Project teams as well as project team members will have different DCP rates and object mapping rates. These rates can vary based on the modeling skills of the team members, and can be affected by requirement rework caused by poorly documented or unknown requirements or poorly defined interfaces.
An indicator is a base or derived measure or a combination of such measures that are associated with decision criteria by means of a mathematical or heuristic model. Indicators often are presented in graphic or chart form. Consider the following example that illustrates the use of the measurement construct. Assume that project decision makers want to compare the DCP density of some current project to previously captured data because it is believed that a DCP density in a certain range provides optimal requirement-to-test traceability. Assume the following:
- Base measures for DCPs and requirements have been collected.
- The number of requirement headers is the base measure for number of requirements, where a requirement header is associated with a body of requirement text.
- The data collected from prior projects estimates the number of DCPs per requirement.
Starting from the bottom of the following figure, the two attributes are DCPs and requirements. Assume some sample project developed 223 DCPs in models for 21 requirements. Dividing the number of DCPs by the number of requirements produces a derived measure of 10.6 DCPs per requirement (i.e., DCP density). Compare this derived data to historical data, where the density was 16.3 DCPs per requirement. A possible interpretation of this information product is that the requirement traceability accuracy for the current project is better than the organizational average. If the current DCP density has a variance greater than 10 from the organizational average, then it may be necessary for the requirement engineers to attend a training class on techniques for developing better requirements.