What data should the software project collect?

In the previous section, we mentioned some data that is widely used for statistics but may not actually be instructive. In this case, we will describe the data that requires statistics and has a positive impact on the project.

Generally, software projects are most concerned with quality, cost, and delivery ). Managers want to display these attributes in different ways and in different forms. The statistical data is centered on three aspects. At the same time, we also need to know what kind of help the data will provide for future improvement.

1. Lap complexity

Circle complexity is undoubtedly an indicator of software quality. There are ready-made tools for statistics on the complexity of the circle. The nunit of C #. net, Google Code Pro * of Java, and matrix can all collect statistics on this data. The recommendation index of the circle complexity cannot exceed 10. Code exceeding 10 should be improved. Excessively low performance may not be worthwhile in terms of ROI.

2. Average bug fixing time

Different from statistics on the bug convergence trend, bug quantity, secondary bug rate, bug distribution, and bug cause statistics, calculating the average bug fix time helps to understand the competitiveness of the organization in the market. The shorter the average bug fixing time, the shorter the release cycle, the more competitive the organization is. The bug fix time should be calculated from the bug registration, until the bug is completely repaired (that is, no second bug is tested through the known complete set test. This also includes the waiting time and testing time. Therefore, a good testing mechanism is required for a short bug fixing time. We will discuss in detail how to establish a good regression testing mechanism in later sections. Here we only emphasize that automated testing is required to shorten the average Bug repair time.

3. Test Coverage Rate

The test coverage rate indicates the coverage of the test, but the current test tool can only provide data at the C0 level. Moreover, if the code is executed, the Code is not tested. Therefore, the data of the current test coverage rate statistical tool can only be used as a reference. To better understand the test coverage, review of the test code is indispensable. In order to ensure the quality of testing, test cases of different categories should be increased as much as possible. It is also important to review the coverage of the test category. To better illustrate this problem, the following is an example:

For the question of test data in a text box that can only enter a positive integer, many people only provide the following conditions: integer, decimal, positive, negative, and 0.
In fact, the following are also crucial test cases:

A. Numbers in Chinese, Japanese, Korean, French, English, and Roman. Example: quatre
B. halfwidth and fullwidth numbers. Example: 8
C. A number with parentheses and circles. Example: (6)
D. a number with a plus sign. Example: + 6
E. Score. Example: 3/5
F. Scientific notation. Example: 2e5
G. symbol. Example: $
H. English. Example: Ask
I .8 in hexadecimal format. For example, 0x52, FF,
J. number ending with the decimal point, for example: 2.
K. maximum and minimum values: for example, integer. Max, integer. Min
L. Percentage. For example, 37%

4. Number of test cases

The number of test cases can reflect the strength of the test.

5. The time required to complete the task
This is used to replace the percentage progress report. As discussed previously, the percentage progress report cannot provide sufficient information. The time required to complete the task is an adjustable number. It is estimated that the remaining working hours are 10 hours today. After 8 hours, there should be 2 hours left tomorrow, however, due to the meeting today and other reasons, the remaining four hours are allowed. Such numbers are often accurate. Note that the value should not exceed 20 hours. If the value is exceeded, consider splitting the task. In addition, when the task finds that there are missing estimation conditions, you can expand the number, that is, the remaining work hours estimated today is 10 hours. After 8 hours, it should have been 2 hours, however, a major omission can be changed to 12 hours. As for the cause of omission, it is another problem that needs to be solved. However, when it comes to work hours and progress, such data statistics can be more accurate.

6. Progress Deviation

What is the deviation between the actual schedule and plan. This provides a reference for adjusting the progress or reducing the function.

7. Working hours used

The hours used should be listed separately. Especially for timeout. Overtime often results in negative effects. Make statistics on the actual situation, and analyze the relationship between the input time and the output value. If the overtime exceeds the legal limit, this is a more serious problem.

8. Deviation between input and budget

Project Investment includes not only work hours, it also includes the depreciation, rent, communication fee, travel expense, transportation fee, project activity fee, hardware and software license fee, outsourcing fee, and consulting fee incurred by project development. What is the relationship between the actual cost and the original budget. If you forget the cost, how can you improve it next time.

9. Number of lines of code

Statistics are not used to calculate the bug density, test density, and production efficiency. As mentioned above. Statistics are collected to understand the code scale and whether the code is bloated. We can compare the code lines of similar projects to see if the technology has been improved. For example, for a project with 0.3 million lines of code, the number of lines of code after rewriting is 30 thousand.