I. Introduction
JMJuran considers quality control as a routine process by which actual quality performance is measured and compared to standards, and action is taken when discrepancies arise. From this, Donald Reifer gives the definition of software quality control: software quality control is a series of verification activities, at any point in the software development process, to evaluate whether the developed product technically complies with the specifications formulated at this stage.
2. Software defect analysis
In IEEE 1983 of IEEE Standard 729, a standard definition of software defects is given: from the inside of the product, software defects are various problems such as errors and faults in the process of software product development or maintenance; from the outside, software defects are The failure or violation of a function that the system needs to achieve.
Software defect is a broader concept, and software error (error) belongs to a kind of defect??? Internal defect is often a problem of the software itself, such as program algorithm error, syntax error or incorrect data calculation, data overflow, etc. . Software errors often lead to the failure of a certain function of the system, or become a malfunction of the system. Software failures and failures refer to the functions or services provided by the software to users that fail to meet the user's requirements or fail to meet the pre-designed indicators, are interrupted when the functions are used, and the final results or obtained results are incorrect.
The occurrence of software defects is mainly determined by the characteristics of software products and the development process. For example, the requirements of software are often not clear enough, and the requirements change frequently. ”, often doing undesired things, creating the most problems. At the same time, software competition is very fierce, technology is changing with each passing day, and the use of new technology is also prone to problems.
From the further analysis of the software's own characteristics, team work and project management, it is relatively easy to determine some details of the causes of software defects, which are summarized as follows:
(1) Problems caused by the characteristics of the software itself.
The requirements are not clear, causing the design goals to deviate from the customer's needs, resulting in defects in functions or product characteristics. The system structure is very complex, but it cannot be designed into a good hierarchical structure or component structure, resulting in unexpected problems or difficulties in system maintenance and expansion; It is difficult to complete the combined test of the interaction of various objects and classes, and some problems such as parameter passing, method invocation, and object state changes are hidden.
The adoption of new technologies may involve technical or system compatibility issues that have not been considered in advance.
The boundary of the program logic path or data range is not considered comprehensively enough, and it is easy to make mistakes in the boundary conditions or exceed the complexity of the system operating environment.
The complex operating environment of the system, not only the computer environment used by users is ever-changing, but also the various operation modes of users or various input data, which are easy to cause problems in some specific user environments; in the practical application of the system, the amount of data is very large, May cause strength or load issues.
For some real-time application systems, careful design and technical processing should be carried out to ensure accurate time synchronization, otherwise it is easy to cause time inconsistency or problems caused by inconsistency.
The self-recovery of the system or the off-site backup of data after a system crash is not considered, so there are hidden dangers in system security and reliability.
Due to the large number of communication ports and the inconsistency of access and encryption methods, problems such as system security or applicability will be caused.
(2) The problem of software project management.
Lack of quality culture, lack of emphasis on quality plans, poor balance of quality, resources, tasks, costs, etc., it is easy to squeeze out time for requirements analysis, review, testing, etc., and there will be more defects left. The needs of customers are not very clear during system analysis, or there are some difficulties in communication with users. The development cycle is short, and various tasks such as requirements analysis, design, programming, and testing cannot be performed in full accordance with the defined process. The development process is not perfect, there is too much randomness and there is a lack of rigorous internal audit or review mechanism, which is easy to cause problems. Inadequate documentation, insufficient risk estimates, etc.
(3) The problem of team work.
Developers at different stages have inconsistent understanding of each other, software designers have deviations in understanding the results of requirement analysis, and programmers do not pay enough attention to certain contents in the system design specification, or have misunderstandings. Design or programming assumptions or dependencies that are not adequately communicated. The technical level of the project team members is uneven, there are many new employees, or the lack of training can also easily cause problems.
Software defects are caused by many reasons, but if these defects are classified according to the results of the entire software development cycle??? software products (market requirement documents, specifications, system design documents, program codes, test cases, etc.), statistics It turns out that the specification sheet is the place where software defects appear the most.
Software product specifications are the place with the most software defects, and the main reasons are as follows:
Users are generally non-computer professionals, software developers and users have great difficulties in communication, and they have inconsistent understanding of the product functions to be developed.
由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。
用户的需求总是在不断变化的，容易引起前后文、上下文的矛盾和需求描述的不一致。
需求分析没有得到足够重视。在规格说明书设计和写作上投人的人力、时间不足。排在产品规格说明书之后的是设计，编程排在第三位。而许多人印象中，软件测试主要是找程序代码中的错误，从分析看，这是一个误区。
如果从软件开发各个阶段所能发现的软件缺陷分布来看，也主要集中在需求分析、系统设计阶段，代码阶段的错误要比前两个阶段少。
三、分析及应对措施
(一)定义合适的项目过程。
软件过程是指开发和维护软件产品的活动、技术和实践的集合。在以计算机网络为基础的现代社会信息化背景下，过程管理作为现代企业管理的先进思想和有效工具，随着外部环境与组织模式的变化而变化。因此，作为一个好的软件项目过程，必须针对企业和项目的实际情况，确定软件项目运作流程，定义软件功能及相关性能，明确各阶段的进入条件和退出条件，进行有效的过程控制与管理，在提高软件开发的效率和项目的成功率的基础上进一步保证所开发软件的质量。
(二)明确项目需求。
对于任何软件项目过程而言，需求不仅是一个不可避免的环节，也是软件开发的基础。往往用户需求明确、变更少的项目的成功率就高，而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。但是，在现实生活中，用户需求总是在开发进入中后期时，因为各种不同的原因而发生变化。这就给软件项目过程实施带来不确定因素。在涂装项目中，由于前期需求不明确以及随意变更需求，导致项目组在开发阶段不停的返工，进而造成代码质量低下，测试拖期等一系列问题。因此，在项目实施过程中，为了保证软件开发的顺利进行和最后交付的产品质量，应该对项目需求变更进行管理。
1、需求说明书要描述明确、详尽。由于与用户沟通的需求人员并不是最后的开发人员，所以有可能导致开发人员对需求说明书的理解与用户真正的意图会产生一定的偏差。另外，当项目在进行到开发(编码)阶段时，由于记忆的缺失，对当初所作的需求说明书的理解也会产生偏差。
2、要对需求变更进行管理。通常需求分析完成后项目就进入开发阶段，用户可能会因为市场或策略的变化而提出需求变更的要求。此时，若是合理变更则有利于项目实施，但有时所作的变更可能会影响项目整体的设计和开发，造成项目进度的延期。对于这一情况，项目组应该积极与用户沟通，制订需求变更说明书，在双方都认可的情况下方可实施。
3、在项目开发过程中要尽早明确用户需求，有些内容一时无法确定则应该暂缓该部分的开发，尽量降低因需求变更而带来的风险。
(三)代码走查。
软件质量在很大程度上依赖于代码质量。在实际环境中对于同一项目而言，由于项目组成员的编程能力、习惯、风格、对需求的理解和个性的不同，所开发的代码质量也不尽相同。再加上一些难以预测的人为因素，由此带来的隐患将严重影响代码质量，最终造成软件质量低下，使得用户无法正常使用并为以后的维护带来更大的工作量和难度。
在软件开发过程中可以根据需要引进代码走查。每周在规定的时间内，轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量，另一方面在走查过程中可以获得他人的意见进一步改善代码效率，使开发成员共享项目实施过程中问题解决的思路和方法，使得软件质量更有保障。
(四)进行正式的测试，并形成制度测试就是对软件产品的检验。
项目测试分集成测试和系统测试，主要进行功能测试、健壮性测试、性能-效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。测试过程通常在模拟环境中进行。要尽可能覆盖整改项目过程，从最初的需求到部署阶段，都应该制订详细的计划并编制相应的文档，如测试计划、测试用例文档、测试报告等。通过测试活动，尽可能早得发现每个阶段中软件存在的缺陷，以方便后续阶段的实施。总之，一切测试应该符合用户需求。