研读Software.Engineering.Quality.Practices - chapter 1.2 Quality Drivers

1.2 Quality Drivers
......

Thus, from these three studies it is clear that the most critical factors affecting software cost and quality are product complexity and human capabilities.Vital human capabilities include knowledge of the problem omain, modern programming practices, and software tools. Other important factors include various timing and space constraints, product reliability needs, and the stability of the adopted technologies and the personnel who use them.

影响软件成本的关键因素是：产品的复杂度和人们的能力。人们的能力包括 问体领域的知识、软件编程实践能力和使用工具能力。其他重要的因素包括 各种时间和空间 约束、产品的可信度需求和 使用该软件的人员接受技术的稳定性。

Furthermore, several studies have identified the most common types of software defects, including explanations for their occurrence [24–26]. During the requirements definition phase, requirements are often incompletely,
inconsistently, or vaguely stated, and many needed requirements (e.g., maintainability, reliability, and usability requirements) are often left undefined whereas many unneeded requirements are defined. Some of the causes of such problems include using the wrong people to define requirements who often misunderstand their responsibilities, lack adequate experience or knowledge, suffer from unclear reasoning and biases, incorrectly understand the assumptions or facts underlying requirements, and select solutions before they understand the user’s needs or requirements. Likewise, stakeholders often do not completely understand their needs or computer capabilities and limitations, often have conflicting views, and seldom participate in requirements engineering.

进一步来说，通过一些研究可以知道软件缺陷的大部分类型，包括对他们出现的说明。在软件需求定义阶段，需求结果通常是不完整、有矛盾的甚至是以漠然的方式来做的。许多需要的需求（维护能力、可维护性和可用性需求）经常没有定义出来，许多无用的需求却被置于列表。导致这些问题的一部分原因是由错误的人来定义需求，这些人经常误解他们的责任，缺乏充足的知识和经验，有着不清晰的推理能力和价值观，不能正确理解处于需求之下的假设或者事实，没有在充分理解用户要求和需求之前就去定义解决方案。

A consequence of these problems is the definition of unstable requirements, which is one of the most common sources of cost and schedule overruns and project cancellations [23, 27, 28]. Hence, volatile requirements generally have a significant impact on product development and either must be eliminated before development occurs or managed as they arise during development. However, because some domains can only be understood over time and organizational goals often change because of  broader organizational change, organizations must learn to embrace change as a necessary part of survival because the tractability and invisibility of software exposes it to continual requirements churn [3, 29, 30].  Furthermore, because individual skills, team experience, and proper domain knowledge are important factors in requirements definition, organizations should attempt to develop teams of highly skilled software engineers and managers with high levels of domain knowledge to obtain more predictable performance [31, 32].
As mentioned, complexity is one of the largest drivers affecting software quality. Complexity is often incidentally introduced into software, which sometimes increases its size. Both size and complexity work against the development of quality software. Therefore, software should be developed adhering to good design practices that reduce complexity and size. Fortunately, simple metrics can be used to measure design quality. Note, however, that this approach simply attempts to deal with human cognitive limitations by placing bounds on software design tasks, which are unlike most engineering problems that are constrained by physical properties and laws.
Defects that arise during coding have been extensively studied [9, 22, 33–35]. These analyses have identified several common types of coding defects. Table 1.2 shows the most common ones, which are grouped by major categories.

TABLE 1.2 Common Types of Coding Defects

Control flow defect types • Multi-way branch assumption • Infinite loop • Non-terminating function • Unreachable code • Incorrect loop termination Data declaration defect types • Undeclared variable type declaration • Incorrectly declared variable type declaration • Under-constrained variable type declaration • Implicitly initialized variable • Improperly initialized variable • Incorrect variable storage class specification • Incorrect variable length specification Computation defect types • Use of non-arithmetic data type in arithmetic operation • Use of different numerical types in arithmetic operation • Data truncation during variable assignment • Occurrence of underflow or overflow exception • Illegal division by zero • Inaccurate numerical computation • Invalid range of numerical variable • Incorrect operator precedence assumption

Data reference defect types • Unused variable • Uninitialized variable • Multiply initialized variable • Illegal array reference • Illegal memory reference • Use of incorrect variable Other common defect types • Inconsistent data type comparison • Mixed data type comparison • Different length variable comparison • Use of incorrect comparison operator • Use of incorrect logical expression • Use of exact floating-point comparison operator • Incorrect specification of the number of function arguments • Incorrect order of function arguments • Incorrectly declared type of a function argument • Inappropriate modification of actual input argument • Incorrect handling of input, output, or other exception • Illegal function input or output • Unused enumeration items

Finally, Jones showed that defects had the following characteristics: 20 percent of defects were introduced while defining requirements, 25 percent during design, 35 percent when coding, 12 percent while writing documentation, and 8 percent when repairing defects [36]. He also showed that the number of defects remaining in delivered software were introduced during requirements definition 31 percent of the time, in design 25 percent of the time, in coding 12 percent of the time, in documentation 16 percent of the time, and during repairs 16 percent of the time. It is interesting to note that the highest defect removal rate, in percentage terms, occurs during coding, followed by design, and then by requirements definition. This is probably not coincidental; it is probably a result that verification of earlier stages of software development typically occur later in the software development life cycle.

That is, requirements are usually created, followed by the creation of designs and then code. After this, the code is usually checked, followed by the verification of the design, and finally by the verification of the requirements. Thus, a logical outcome of this is that software engineers should verify requirements and designs immediately after they are completed, and adopt an iterative software development life cycle to get quicker feedback on the quality of software.