How to estimate the software project cycle-code line Estimation

A project is a series of activities that achieve the expected benefits within a certain period of time at a certain cost. The "Life Cycle" of a project is an important indicator for project management, and estimation of the project cycle is an important part of project management. This "Project Management" section describes how to estimate the software project cycle.

Estimation is a very important part in software development: Project Cycle estimation is too short, which may lead to a low labor cost, a low cost budget, and a short schedule. In the end, human resources are exhausted, and costs exceed the budget, to complete the project, you have to wait for a while, which may affect the project quality or even lead to project failure. The project cycle estimation is too long, but it does not seem to affect much, but it will also lead to the consequences of high cost estimation and low efficiency. Periodic estimation is like building a foundation in a building. It is the basis of subsequent work, and its impact will go through the entire project.

However, software development is a very complex project. It not only contains different sub-processes, such as requirement analysis, design, coding, testing, implementation, and maintenance, it also involves many factors such as development tools, developers, project management, and risks. Different factors have different effects on estimation. These aspects must be taken into account during software estimation (including Estimation Via tools), otherwise the estimation results will be significantly different from the actual results. Next, we will discuss several common factors.

Software scale is the foundation of project estimation

Software scale usually refers to the size of software. It can be described by the length of the code line, number of functional functions, number of tables in the database, size of the database, and other factors. Generally, the larger the software scale, the longer the development cycle it takes. However, this is not a simple linear function relationship, but also the issue of code reuse should be considered. For example, if the code of a module is long but may contain many public functions, you should reduce the number of code lines in estimation.

The more functional modules a software project contains, the more complex (or the larger the software), the longer the development cycle. This time is by no means a simple superposition of the module development time, because the increase in the number of module functions directly leads to the mutual correlation between software modules and the increased complexity, this leads to the need to spend more time in the demand, design, and other stages, which is much more complicated than considering a single module. On the other hand, with the increase in the number of modules, the development cycle is not particularly obvious for projects with high degree of productization. This is because a considerable number of modules can be fully reused, and the actual development volume is greatly reduced.

Therefore, when estimating the actual software development cycle, the software scale must be the first consideration. In specific estimation, reusable parts should be removed when considering the software scale. In addition, the complexity caused by the association between software functions must be paid enough attention.

Risk impact period

Any project has more or less risks, which cannot be avoided during software project development and has its own characteristics. The most common risks come from technology, customers, and project personnel. Project risks should be taken into account during development cycle estimation, especially technical and customer risks --

Technical RisksTechnical risks mainly come from the technical difficulty of the software. For a set of mature products, the technical risks of custom development are relatively small, because important technologies have been developed, and customers rarely have new requirements that can bring difficult technical problems, this risk is small. However, for completely re-developed projects, or R & D projects, special attention must be paid to technical risks. Taking the development platform as an example, the development platform must be suitable for the software development involved in the project and meet the final needs. The incorrect selection of the platform will lead to a huge development workload, even if the user needs are met, the system may suffer from low efficiency and poor scalability, and the software may be quickly eliminated.

In actual estimation, it is recommended that the technical difficulty be divided into ten levels, with each level increasing by 10% on the first estimated code line,

Final estimation code length = initial estimation code length × (1 + 0.1 × n)

Assume that module A estimates 15000 lines of code behavior for the first time, but considering the risk of high technical difficulty, the technical difficulty level is set to level 2, and the estimated number of final code lines is 15000 × (1 + 20%) = 18000.

As the analysis of technical risks is a highly technical task, the persons who require technical risk analysis must be technical experts and have rich experience in related technical fields. The analysis results of major technical risks must be reviewed to ensure accuracy.

Customer risksCustomer risks exist in custom projects. The customer industry has different characteristics, and their technical and understanding levels are also quite different. In the projects I have developed, 80% of project delays are due to the customer's reasons, and the controllability of such risks is very low. The impact on the project exceeds the technical risk.

Before estimating the development cycle, the project manager should carefully analyze the customer's specific conditions, including the customer's computer level, management level, and level of communication, based on the previous experience, we can determine whether it will significantly affect the development. We can classify the customer based on the above technical risks and determine the development cycle. In this process, the experience of the project manager is extremely important. The analysis of the customer is based on the experience, and the management personnel are required to have a large amount of customer experience and industry analysis capabilities.

Speed of Project Team impact

For software development projects, human resources are the core force. The impact of human resources on estimation is manifested in the technical level, understanding ability, and communication ability. The quality of project technical personnel, such as programming leveling, work efficiency, Team adaptability, and communication ability, will affect the development progress. The technical level is the most critical factor. Evaluation of the programmer's technical level can be considered from several factors such as programming proficiency, programming speed, and ability to solve technical problems: programming proficiency refers to the degree of familiarity with software functions implemented by programmers using programming tools; programming speed refers to the speed at which a certain function is completed; the ability to solve technical problems can reflect the technical skills of programmers-if 100% is used as the sum, the three factors account for 70%, 15%, and 15% respectively.

Before estimating the software development cycle, we recommend that you classify developers based on the three factors described above. In the initial estimation, we can assume that the developer is an intermediate programmer, and then make corrections based on the actual level of the project team, so that the accuracy of the results can be greatly improved.

Valuable experience

Estimating the software development cycle based on historical data is a common method. This method is based on the historical software development cycle and compares the current software project situation with historical data during the estimation, to get the final result.

Estimation of the development cycle based on historical data is still accurate, but this method is only applicable to the development of a certain type of software, such as the development of a business system in an industry. When the software to be estimated differs too much from the historical software, for example, the development tools are completely different, or the project type is completely different, you cannot rely on this method. At the very least, you should use other estimation methods. If you do not have historical data or develop a new field of software, you can use the code line or function point estimation method, and then use other methods for correction.

When using the historical data estimation method, it is recommended that the project manager create a historical project database. The database contains detailed data such as the development cycle, project scale, developer status, and customer status of all previous projects. When estimating, find the most similar historical project in the database based on the current project status, and then compare the differences between the two projects in terms of project scale, project risks, and human resources, assume that the development cycle of the historical project is a. The cycle of the current project can be obtained according to the following formula:

Estimated project cycle = A × (2 × S + R + P + 2 × C)/6

S: represents the software scale R: represents the risk P: represents the human resources C: represents the customer

(The above values refer to the ratio of the current project to the historical project)

The actual comparison factors should be more than that, but the software scale, risks, human resources and customer conditions are the most important and have the greatest impact on software development, therefore, this formula only takes these factors into account. The software scale and customer account for the largest proportion, which is based on the project management experience. Other factors can also be added flexibly when using the historical data estimation method.