Estimation of the scale of software projects has always been complicated because of the complexity of the software, the lack of historical experience, the lack of estimation tools, and some human errors, the estimation of the scale of software projects is often far from the actual situation. Therefore, estimation errors have been listed as one of the four major causes of software project failure.
Software engineers are often asked how long it takes and how much money to compile a software. In the face of this problem, many people are very difficult, because the first user's requirements are too specific, and the second, they lack a scientific estimation method. This section describes how to estimate the scale of several software projects.
Concepts
First, we will introduce the most common concept of measuring the scale of software projects-loc (line of code), Loc refers to all the lines of executable source code, including the deliverable work control language (jcl: job control language) statement,
DataDefinition, data type declaration, equivalent declaration, input/output format declaration, etc. The value of a single line of code (1 LOC) and the average number of lines of code per month can reflect the production capacity of a software production organization. An organization can calculate the single-line code value of an Organization based on the audit of historical projects.
For example, a software company found that the source files (. C and. H files) generated by each 10 thousand lines of C language source code are about 250 kb. If the source file size of a project is 3.75 MB, it is estimated that the source code of the project is about 0.15 million lines, and the total investment of the project is 240 person-months, the monthly fee per person is 10000 yuan (including per capita salary, welfare, office expenses, and so on), the value of 1loc in this project is:
(240x10000)/150000 = 16 RMB/Loc
The number of lines of the daily average code for the project to be changed is:
150000/240 = 625loc/person-month
Method 1. Delphi Method
Delphi method is the most popular expert evaluation technology. Without historical data, this method is suitable for assessing the differences between the past and the future, between new technologies and specific programs, however, the degree of expert "specialization" and the degree of understanding of the project are difficult points in the work. Although Delphi technology can reduce this deviation, expert Evaluation techniques are rarely used to assess the actual cost of a new software, but this method is especially useful for deciding the input of its model. Participants are encouraged to discuss the issue through Delphi. This technology requires the participation of people with various software-related experiences to persuade each other.
The Delphi method is as follows:
1. The focal point provides the experts with the project specifications and estimation forms;
2. The focal point convenes various experts in the group to discuss factors related to the scale;
3. Fill in the iteration form anonymously by experts;
4. The coordinators sorted out an estimation summary and returned it to the experts in the form of representatives;
5. The facilitator convenes a group meeting to discuss large estimation differences;
6. Experts review the estimation summary and submit another anonymous estimate on the iteration table;
7. Repeat 4-6 until the minimum and maximum estimates are reached.
Method 2: Analogy
Analogy method is suitable for evaluating projects that are similar to historical projects in application fields, environment, and complexity, and obtaining scale estimation through comparison between new projects and historical projects. The accuracy of the estimation results of analogy method depends on the integrity and accuracy of historical item data. Therefore, one of the prerequisites for using analogy method is to establish a good post-project evaluation and analysis mechanism, data Analysis on historical projects is trustworthy.
The basic steps are as follows:
1. Sort out the project function list and code lines that implement each function;
2. Identify the similarities and differences between each function list and historical projects. Pay special attention to the areas where historical projects are insufficient;
3. Obtain the estimated values of each function through steps 1 and 2;
4. generate an estimate of the scale.
In software projects, analogy is often used to solve the estimation problem of reusable code. The best way to estimate the amount of reusable code is to let the programmer or system analyst examine the existing code in detail and estimate the amount of reusable code in a new project.
DesignThe Code percentage, the Code percentage to be reencoded or modified, and the code percentage to be retested. Based on the three percentages, the following formula can be used to calculate the equivalent new code line:
Equivalent code line = [(re-design % + re-code % + re-test %)/3] × existing code line
For example, if there are 10,000 lines of code, assuming that 30% needs to be re-designed, 50% needs to be re-encoded, and 70% needs to be re-tested, the equivalent code line can be calculated:
[(30% + 50% + 70%)/3] × 10,000 = 5,000 equivalent code lines.
Meaning: reusing the 10000 code is equivalent to writing 5000 lines of code.
Method 3: function point estimation
Feature measurement is a scale estimation method based on system functions in the demand analysis phase. The number and features of various input, output, computing, and database requirements are determined by studying initial application requirements. The general steps are as follows:
1. Calculate the number of input, output, query, master file, and interface requirements.
2. Weighted multiplication of the data. The following table shows a typical table of weights.
Function Type Weight
Input 4
Output 5
Query 4
Master file 10
Interface 10
3. Based on the estimation of complexity, the total number can be adjusted by + 25%, 0, or-25%.
It is found that the development of a software product, the function is very helpful for the early project scale estimation. However, after learning more about the product, the function points can be converted to the more commonly used loc for software scale measurement.
Method 4. Pert Estimation
PERT estimates the completion time of each project activity based on three different situations: the expected scale of a product, the minimum possibility, and the maximum possibility. The three estimates are used to obtain an pert statistical estimate of the expected scale and standard deviation of a product. PERT estimates the expected values of the code line E and standard deviation SD.
