The economic value of software quality is not well covered in the existing software engineering literature, Website production There are many reasons for this. The main reason is that the software quality measurement method in the software engineering field is quite poor. Many cost factors such as unpaid overtime are often ignored. In addition, there are frequent sulfur omissions and omissions in software cost data, such as the omission of project management costs, and the omission of part-time experts (such as technical document writers). In fact, only the cost of coding work has reasonably good data available. Any other work, such as data on requirements, design, review, testing, quality assurance, project office and documents, is often underreported or simply ignored.
As pointed out in other parts of the book, software engineering literature relies too much on vague and unpredictable quality definitions, such as "software products meet user needs" or meet a series of "features". These unscientific quality definitions slow down the research on the most economical price of software quality. The use of indicators in the other two invalid economies also affects the research on the economic value of software quality, namely, average defect cost and code lines. Average defect cost is bad for quality, but the software with the lowest defect cost is often full of holes. The line of code is disadvantageous to the high-level programming language. It covers up the value of high-level programming language in software quality and productivity research.
In this part, the author will try to use 8 research cases to show the economic research of software quality. Since the economic value of software quality is closely related to application scale, four discrete scales are used to illustrate: 100 function points, 1000 function points, 10000 function points and 100000 function points. The application software with 100 function points is usually a small function module of a large system rather than an independent application software. However, this magnitude is also the most common scale range of larger application software prototypes. There may be some small independent applications at the highest scale, such as currency converters or small applications on handheld devices (such as iPhones).
The application software with 1000 function points is usually independent application software, such as fuel injection control system, atomic watch control software, compilers for programming languages such as Java, and software estimation tools such as COCOMO. The basin level application software with 10000 function points is usually an important system in all aspects of business control, such as insurance claim processing, motor vehicle registration, child support application software and other software systems. The application software with 100000 function points is usually a major system such as the large international telephone switching system, an operating system such as Vista or IBM MVS, and an associated and collaborative application suite such as Microsoft Office. Some ERP application software also belong to this scale. It may even reach 300000 function points. Similarly, 41 defense applications such as the Global Military Command and Control System (WWMCCS) may also have up to 100000 function points.
To reduce the number of variables. All eight examples assume that code is written in C language, and each function point contains about 125 code statements. Since all 8 application examples assume that they are written in the same programming language, productivity and quality can be represented by undistorted code line indicators. Note that it is not valid to use code line indicators for comparison between different programming languages.
