How to estimate test workload (2) code line Analysis Method

How to estimate the test workload

(2)Code line analysis method-Common Software Scale Estimation Methods

 

The estimation of testing workload is often closely related to the scale of software development. many software companies often estimate the testing workload after estimating the scale of the software to be developed, and then sum up the final workload estimation of the project. this method is suitable for companies or projects that have accumulated experience and stable testing and development models. It provides a relatively accurate and informative number. however, because it fully depends on its premise-the Development workload estimation, it seems quite fragile. If the development workload is greatly deviated, the testing workload will become useless. in addition, the code line itself has many problems and limitations. Therefore, when choosing it as a project estimation method, you need to understand its principles, advantages and disadvantages, and then use it selectively.

The code line is the source and English line of code. The code line analysis method is to measure the number of lines in the source code of the software product. However, if you think about it carefully, you may have the following questions:

L is it the number of physical lines or the number of program commands?

L is empty rows calculated?

L is the annotation calculated?

L is the pre-defined file calculated?

L how to calculate different versions?

L is there a series of Rule definition problems designed here?

L is the configuration script in the Development Process calculated by compiling the script?

L how to calculate shared files (such as header files of shared development library files?

Now, the general rule is to calculate the number of physical rows without empty rows or comments. for other options, it is generally used to calculate all files in the root directory of the source file. therefore, a code line refers to the number of lines of All executable source code, including the deliverable control language (jcl: Job control language) statement, data definition, data type declaration, equivalent declaration, input/output format declaration, etc. Commonly used units include sloc (single line of code), kloc (thousand lines of code), lloc (logical line of code), and ploc (physical line of code), ncloc (non-commented line of code), DSI (delivered source instruction ). Sloc and kloc are commonly used.

The code line analysis method is meaningful to technicians because it does reflect the size of software from a program and is physically measurable. However, this method also has the following problems.

L in the requirement, plan, and design phase, because there is no code line, estimation is required. The overall estimation accuracy is not high unless you have years of experience in similar projects. The accuracy of the estimation depends on whether there are data of similar items and the experience of the estimator. Data can be counted directly in the coding, testing, and implementation phases.

L The ability to meet customer requirements and reflect progress is unsatisfactory, which is of little significance to managers. Therefore, it is difficult for the project to take actions to track the number of lines of code as a whole.

L recently, a large number of visual programming tools, template libraries, and class libraries have been widely used. There are a large number of automatically generated code or complex automatic configuration scripts or resource file settings in the program results, in projects using these tools, the significance of using the code line analysis method to obtain numerical values has been greatly reduced.

L for different programming languages, the code line also lacks a trusted conversion method.

Although the Code-line method has many disadvantages, it is easy to use and has low operation costs (if appropriate support tools are used ), we recommend that you use code lines as a reference and supplementary means for software project management.

 

References:Partially Excerpted from <Function analysis methods and practices>