Measurement term 2: Application and Development Productivity (actual measurement Cases)

The shocking fact is that even common metrics such as productivity do not have a simple definition. Even the formula we often use: Productivity = work products/workload (work products can be code lines, functional points, or anything that can be counted, such as the number of document pages) all are errors.

If you try to use productivity for measurement normally, you should first divide it into the following two types of measurement data.

Note that the following example uses code lines for ease of understanding, but these two concepts are actually the classification of function points when ifpug (International Functional Point User Group) counts.

Application Type

The following dialog will generate an application metric data:

A: "How many lines of code does this software have ?"

B: "Wait for me to count ...... 10000 rows ".

A: "How many people are developed ?"

B: "about 100 person-days"

A: "Productivity = 10000 rows/100 person-days = 100 rows/person-days"

This productivity is produced based on the static scale measurement of an application, which may change dramatically over a period of time:

Three months later ......

B: "We modified some code, added some code, but also deleted some code"

A: "Oh ?"

B: "I have invested more than 100 person-days, but now there are still 10000 rows ."

A: "NowTotalProductivity: 10000 rows/200 person-days = 50 rows/person-days"

B: "Okay ...... The second phase is a big deal"

Development Data development type

A: "How many lines of code does this software have ?"

B: "There are two phases in total ...... Wait for me to count ...... In the first phase, 100 person-days developed 10000 rows ...... The second period is also 100 person-days. Add 2500 rows, delete 2500 rows, and modify 5000 rows ".

A: "The productivity in Phase I = 10000 rows/100 person-days = 100 rows/person-days"

B: What about Phase II ?"

A: "Phase II productivity = (increase 2500 + Delete 2500 + modify 5000)/100 person-days = 10000 rows/100 person-days = 100 rows/person-days"

B: "Yeah! "

A: "However, some systems say Phase II productivity = (increase 2500 + Delete 2500/2 + modify 5000)/100 person-days = 8750 rows/100 person-days = 87.5 rows/person-days

B: "Ah? "

A: "Wait ...... There is also a saying that the second phase of productivity = (increase 2500 + Delete 2500/4 + modify 5000/2)/100 person-days = ...... You can calculate this by yourself. "

B: "Okay, it's better to be busy. "

How to use it? Scenario 1: planning and performance appraisal = Development Data

It takes a lot of work to add, delete, and modify data. Therefore, it is fairer to use development data for planning and assessment.

However, it is generally more reasonable to use functions. For example, in refactoring, it is very likely to delete the code of a large segment (we used to refactor 4000 lines of code to 55 lines in about 15 minutes, and the function remains unchanged ), in fact, the application has not changed much. It is difficult to recognize the change that is hard to perceive by the outside world (customers and senior executives.

Which of the three systems (with the same value for addition, deletion, modification, or/2, or/2/4) can choose?

I don't know, because these three systems are all used. My suggestion is:

1. If the measurement is just started

Just select a method, but record the original data.

That is to say, remember how many new, deleted, and modified.

2. data accumulation is high.

Calculate all the three methods, and then compare the correlation coefficient between the calculation results and the actual workload (the correlation coefficient will be popular in the future, and the correl function (B1: G1, B2: g2), the higher the correlation coefficient, it indicates that this method is closer to the fact.

Measurement Analysis does not mean "which is the best in theory". Only data-based talents have the right to speak.

In other words, the essence of measurement analysis is to eliminate the subjectivity, one-sidedness, and idealization of various theories, and leave the voice to the data itself. Therefore, data analysis is inevitable.

Scenario 2: demand change control

However, no matter how many reasons, it is not a normal task for a software to modify or delete a function without adding a function.

Too many changes indicate that the demand analysis is not good at the beginning, while the deletion function indicates that too many useless functions are implemented.

To constrain the team and prevent them from taking "software change" as their workRatio of regular monitoring to application and developmentIf this data keeps decreasing, it indicates that everyone is modifying the previous functions. For a long time, there has been no significant increase in functions.

In the R & D of small and beautiful products, modifying functions may be a norm, but this cannot be used as a reason for not thinking deeply about the "best function.

In project development, especially outsourcing projects, modifying functions without adding functions is a disaster, because customers do not pay for modifying functions most of the time, they believe that this is because Party B fails to analyze the demand in depth.

Scenario 3: encoding Validity

That is, the question of how much code can be used to implement functions. The higher the encoding validity, the less code is required. (There will be detailed descriptions in the future)

Of course, the "function" here refers to the function measured by the functional points of international standards, rather than the intuitive function that we usually call "personal understanding is different in size.

In this scenario, you should use:Encoding validity = total code lines/total function points = total code lines/Application class function points.

For example, in the previous example, the second line of code may still contain 10000 rows. However, if the function is increased, the encoding validity increases.

Complete example

The following is a complete application scenario of Function Points, code lines, encoding validity, application and development data.

A: "How many lines of code and functions does this software have ?"

B: "There are two phases in total ...... Wait for me to count ...... In the first phase, 100 million lines were developed, with 10000 features ...... The second period is also 100 person-days. Add 2500 rows, delete 2500 rows, and modify 5000 rows. Add 50 Function Points, delete 20 function points, and modify 30 function points ".

A: "The productivity of Phase I code lines = 10000 lines/100 person-days = 100 lines/person-days, and functional points = 200 Function Points/100 person-days = 2 Function Points/person-days"

B: What about Phase II ?"

A: "Phase II productivity = (increase 2500 + Delete 2500 + modify 5000)/100 person-days = 10000 rows/100 person-days = 100 rows/person-days, function productivity = (increase by 50 + Delete 20 + change by 30) function Point/100 person-days = 100 Function Point/100 person-days = 1 function point/person-day "(currently only use the first algorithm for adding, deleting, modifying, and modifying the weight)

B: "Which project is doing fast? "

A: "From the perspective of the code line, the same is true. from the functional point of view, the first phase of the project is doubled ."

B: "Which one should be good ?"

A: "The functions are better, and it is easier for customers and leaders to explain"

B: "Phase II is really bad ."

A: "It's not necessary that your encoding efficiency has been improved ."

B: "how ?"

A: "After the completion of Phase II (not Phase II development itself), the entire product is still 10000 lines, but the function points are increased to 300, your current code efficiency has reached 10000/300 = 33 lines/function point (the lower the better, the first stage is 10000/200 = 50 )"

B: "productivity is reduced, and coding efficiency is improved ...... How to make an overall evaluation ?"

A: "Productivity improvement is the ultimate goal, but the improvement of coding effectiveness will help improve productivity and quality in the future. Therefore, the overall evaluation is that productivity has declined. The future depends on whether you can take advantage of the encoding efficiency in the future ."

How is it? If it was me, if I could write a project report composed of numbers, I wouldn't write a lot of ambiguous words.