Website construction is now a carrier of information, spreading useful information to people in need, Website construction Including software, in the work of expert witness in many software litigation cases, the author noticed a long-standing software project management problem. Many failed projects and projects with serious schedule delays or major quality problems have not found any problems through normal progress reports during development. It can be seen from various witness testimony and case adduction that both software engineers and front-line project managers know that there are problems in their projects, but when they first found those problems, the project manager did not write them into the status report reported to customers and senior management at the first time. Until very late, when higher management or customers really realize serious schedule delays, quality problems or other major problems, the situation usually cannot be reversed.
When asked why we should hide the problems in the project. Most of the answers are that grass-roots managers do not want senior management to see the bad situation of the project. Of course, when the problem finally surfaced, in fact, the grass-roots managers looked worse. In contrast, those successful software projects always deal with the problems in the project in a more rational way. They can find problems as soon as possible, set up special task teams to solve these problems, and usually control the situation before these problems become too serious to solve. An interesting feature of agile methods is to discuss the problems existing in the project every day. The same is true of team software process (TSP).
Software project problems are a bit like serious medical problems. They usually don't disappear. In order to eliminate these problems, many professional "treatment" methods are needed. The problems of software projects are a bit like serious medical problems. They usually don't disappear by themselves. In order to eliminate these problems, many professional "treatment" methods are needed. Once a software project is started, there is usually no fixed and reliable guiding method to judge the actual progress rate of the project. For a long time, the civil software industry has been using the method of specific milestones to determine project progress, such as design completion or coding completion. However, these milestones are also notoriously unreliable.
Software project status tracking needs to involve the following two unrelated issues: (1) reaching specific and determined milestones; (2) Consume project resources and funds within a clear budget amount. As software project milestones and costs are affected by requirements changes and "scope extension", when these changes affect the total number of function points, the scale growth of requirements changes becomes the most important. However, as mentioned in the previous section of this chapter, some demand changes called "demand fluctuations" do not affect the total number of function point sizes, while demand spread and demand fluctuations often occur randomly. Demand fluctuation is more difficult to measure than demand spread, and it can only be measured by "backfire analysis" or mathematical conversion between the number of procedural code statements and function point indicators.
As of 2009, there are many available automation tools to help project managers record various important information required for project milestone reports. These tools can record project progress, resources, scale changes and various project problems. For an industry with a long history of 60 years, it is somewhat surprising that there is no set of universal or universal project milestones to mark the substantive progress of the project!
