Record for the day
Weather: The sun shines on the earth without reservation. The sky is as blue as a gemstone, without a single cloud. It's a sunny day that makes people's moods brighten up.
Mood: My heart is like a calm lake without ripples, peaceful and carefree.
Discussion on SQA-related content
Overview of Software Quality Assurance (SQA)
Zhongke Yonglian Advanced Technology Training Center (Official website: ) has a clear definition of software quality assurance. Software Quality Assurance (SQA) is a well - planned and systematic method system. Its core mission is to guarantee to the management that the established standards, procedures, practices, and methods can be correctly applied in all projects. Through this system, the software process becomes visible to management personnel. Specifically, it conducts reviews and audits of software products and related activities to verify whether the software meets the established standards. Moreover, the Software Quality Assurance Group will be deeply involved from the very beginning of the project to jointly formulate plans, standards, and processes, aiming to ensure that software projects meet the requirements of the institutional policy.
Basic objectives
1. Planning: Software quality assurance work is like a precise battle, where every step of the action needs to be planned in advance. Only by carrying out work in a planned manner can we ensure that all tasks are advanced in an orderly manner and avoid chaos and disorder.
2. Objective verification: Objectively and fairly verify whether the software project products and work comply with appropriate standards, procedures, and requirements. This is like a referee strictly judging the performance of athletes on the field according to the rules without the slightest partiality or subjective assumption.
3. Information transfer: Timely and accurately convey the software quality assurance work and its results to relevant groups and individuals. Unimpeded information can enable all parties to promptly understand the project's progress and quality status, so as to make reasonable decisions.
4. Problem reporting: Enable senior management to access non - conformity issues that cannot be resolved within the project. Senior management has more abundant resources and higher decision - making power. Their involvement can provide a more effective way to solve problems.
The origin of QA
In many large foreign companies, such as IBM, CA, and PeopleSoft, initially, the main responsibility of QA was testing, especially system testing. However, as time passed, problems gradually emerged. Due to insufficient project planning and management, the time allotted for system testing was extremely limited. For example, in some projects, the system testing time was even only one day, with no room for negotiation. Meanwhile, requirements changed frequently, and there was a lack of complete requirement documents. Testers could only conduct tests based on their own imagination. In this situation, testing could hardly guarantee product quality, so the QA function of pre - prevention emerged. This pre - prevention concept draws on the idea of Total Quality Management (TQM) and also conforms to the principle in software engineering that "the earlier a defect is discovered and corrected, the more cost - effective it is". Its ideological origin can even be traced back to ancient Chinese allusions, such as "Bending the Chimney and Moving the Firewood" and "Bian Que's Discussion on Medical Skills". The allusion of "Bian Que's Discussion on Medical Skills" is mentioned in foreign articles. Unfortunately, Chinese people have neglected the ideological and cultural heritage of their ancestors.
The current situation of QA
Nowadays, more and more enterprises are starting to implement the CMM model, which requires the establishment of the QA role. The QA here is like a process policeman, mainly responsible for checking whether the development and management activities are consistent with the established process strategies, standards, and procedures, and whether the work products follow the content and format specified in the templates. To ensure the objectivity of the evaluation, the QA is usually required to be independent of the project team. However, in China, most QAs lack a technical background, and the deviations they detect are often insignificant. Coupled with their lack of a convincing background and the support of leaders, it makes it extremely difficult to carry out their work.
The QA work itself is extremely challenging. It requires QA personnel to have knowledge in many aspects such as software engineering, software development, industry background, mathematical statistics, project management, and quality management. In the work, QA personnel often encounter improvement bottlenecks, feel inadequate, and get trapped in a cycle of depression. Even if they master all the knowledge and break through numerous obstacles, the QA work is not always smooth sailing. Due to the limitations in the definition of the QA role, acting as a process policeman can easily lead to hostile relationships within the project team and undermine the team spirit. Therefore, the QA work also requires good interpersonal skills to handle various relationships in an artistic way.
The future of QA
To some extent, the independent QA review mechanism is a product of the waterfall model. With the development of modern software development technologies, the spiral model and iterative model have gradually emerged, and the QA mechanism is also quietly changing, shifting from an independent full - time QA to a part - time QA throughout the process. In the CMMI model, this kind of part - time QA is also allowed. This is because advanced methodologies such as XP and RUP first build the architecture and then conduct incremental development until completion. In this mode, requirements and design defects can be discovered and fixed as early as possible in each iteration cycle. Quality is built into the architecture and the process, and the project's cost and schedule can also be guaranteed. However, some enterprises with lower maturity still need an independent QA to ensure the effectiveness of process execution and the objectivity of evaluation.
Theoretical exploration of SQA
1. Understanding of the process: A project mainly involves three aspects: cost, schedule, and quality. Excellent project management requires comprehensive consideration of these three factors, balancing their goals, and ultimately achieving the project tasks. These three aspects restrict and influence each other, and the enterprise's balancing strategy for them even determines the enterprise's behavior. For example, IBM takes software quality as the primary goal, while Microsoft pursues the strategy of "good enough software." Therefore, SQA work should be based on the enterprise's strategic goals and form a theoretical understanding of SQA from this perspective.
It is generally believed in the software industry that the factors affecting the progress, cost, and quality of software projects are mainly "people, process, and technology", among which people are the most crucial factor. However, many people implementing CMM nowadays are overly indulged in CMM theory and overly emphasize the "process", which is a dangerous tendency and has been strongly criticized abroad. The proposal of various agile process methods is a reflection on the emphasis on process. The idea of "people are more important than process" in "XP" deserves our in - depth consideration. When carrying out process improvement, we should adhere to the principle of "people - oriented" and emphasize the harmonious unity of process and people.
According to the investigations of numerous failed projects in modern software engineering, management is the main reason for project failures. However, this doesn't mean that good management can guarantee project success. Nevertheless, many people have drawn such a conclusion based on wrong logic. This error is particularly evident in the understanding of SQA. Historically, CMM initially emerged as an "evaluation standard" mainly used to evaluate the ability of suppliers of the US Department of Defense to ensure quality. The software production that CMM focuses on features important quality and large scale. It introduced the methods of "total quality management" and "statistical process control", and these two concepts are the foundation of CMM.
2. Metaphor of the production line: If software production is compared to factory production, then the production line is the process, and products are produced in accordance with the regulations of the production line. The responsibility of SQA is to ensure the implementation of the process, that is, to ensure the normal operation of the production line. The management system model should at least include three important aspects: "decision-making, execution, and feedback". The responsibility of QA is to ensure the effective implementation of the process and supervise the project to carry out activities in accordance with the process. However, it is not responsible for supervising product quality, reporting project status to management, or representing management for management. It only represents management to ensure the implementation of the process.
3. Combination of SQA and other work: In many enterprises, the work of SQA is often confused with that of QC, SEPG, and organizational project managers. Sometimes, more emphasis is even placed on other aspects of work, neglecting the core work of SQA. According to hjhza, there are basically three types of QA in China at present, namely process improvement type, configuration management type, and testing type. This is the result of the combination of SQA work with other different types of work.
In - depth analysis of the relationships among various characters
The relationship between QA and QC
Before discussing the relationship between QA (Quality Assurance) and QC (Quality Control), let's first clarify their basic responsibilities.
The core task of QC is to inspect product quality. Its goal is to ensure that products can meet customers' needs, and it is the direct inspector of product quality. This is like a strict quality inspector carefully examining each product on the production line, not letting go of any possible defects.
QA, on the other hand, focuses on auditing the quality of the process and is committed to ensuring that all processes are correctly implemented. It is the auditor of process quality. It is more like an off - stage supervisor, constantly paying attention to whether the entire production process follows the established rules.
Special attention needs to be paid to the differences between the concepts of inspection and audit. Inspection, in layman's terms, is like what we commonly call "finding faults," which is a process of specifically looking for problems. It focuses on finding surface or obvious problems in products. Audit, on the other hand, is a process of seeking evidence to confirm whether a project is carried out as required. In the CMM (Capability Maturity Model), the term "confirmation" is widely used in the inspections of SQA (Software Quality Assurance) in each KPA (Key Process Area), which indicates that the content of audit mainly revolves around processes. Comparing the review contents of project managers and senior managers, they pay more attention to specific product details.
From the perspective of the management system model, QC is responsible for conducting quality control and feeding back quality information to the management. The responsibility of QA is to ensure that QC carries out quality control activities in accordance with the established process and report the inspection results to the management as required by the process. This is the close relationship between the work of QA and QC.
Under the principle of division of labor, QA mainly checks whether a project has carried out a certain activity according to the process and whether specific products have been produced. Meanwhile, QC focuses on checking whether products meet the quality requirements.
If an enterprise originally has QC personnel but is short of QA personnel, it can consider having QC personnel temporarily take on QA work. However, this can only be a temporary solution. Since QC work itself also needs to follow process requirements and its process needs to be audited. If these responsibilities are mixed for a long time, it is difficult to guarantee the process quality of QC work.
The relationship between QA and SEPG
The basic responsibilities of SEPG (Software Engineering Process Group) and QA each have their own focuses. The main task of SEPG is to formulate processes and implement process improvements. It is like the designer of the enterprise's processes, responsible for planning and optimizing the entire process. On the other hand, QA ensures that these processes are correctly executed, just like the guardian of the processes.
The SEPG needs to provide process guidance to the project team, help the project team formulate suitable project processes, and conduct effective planning to ensure that the project team can work efficiently and execute the processes. When there are differences in the understanding of the process between the project team and the QA, the SEPG will act as the final arbiter. In order to achieve effective process improvement, the SEPG must conduct in - depth analysis of project data to identify the problems existing in the process and the directions for improvement.
Although QA itself is also responsible for process specification, not all QAs are suitable for joining the SEPG. Usually, those QAs with the most experience and the greatest ability can participate, but attention should be paid to the differences between the two.
If the SEPG personnel of an enterprise have a profound development background, they can concurrently take on the SQA work. Doing so is beneficial for the continuous improvement of the process because they not only understand the development process but also can optimize it from the perspective of process improvement. However, this situation where legislation and law - enforcement are combined in one body can also easily lead to the SQA being overly dominant, thus affecting the independence of the project.
For enterprises with a relatively mature management process, since the corporate culture and management mechanism are already well - established, the work within the scope of SQA responsibilities is relatively less. Usually, they only need to formulate a well - focused SQA plan for specific projects, which will greatly reduce the SQA audit work and enable it to audit more projects simultaneously.
On the other hand, with the refinement of division of labor and the complication of the management system, enterprises often need full-time SEPG personnel. These personnel need to have a comprehensive understanding of all management processes and operational situations of the enterprise in order to carry out process improvement from an overall perspective. At this time, those SQA personnel who understand the overall situation become the main candidates for full-time SEPG. They will gradually shift from SQA work to SEPG work and learn management knowledge more deeply, while SQA work gradually becomes their part-time job. This situation is quite common in many CMM5 enterprises. Sometimes, it is even rare to see SQA personnel in the project team. The integration of SEPG and SQA is particularly beneficial to the organization's process improvement work. Since SEPG determines the content of process improvement and the SQA plan focuses on reflecting these improvement contents, it ensures effective improvement and helps the enterprise meet the requirements of CMM5. This also explains why the salaries of SQA personnel abroad are relatively high, while currently SQA personnel in China are easily underestimated. The reason is that the management processes of Chinese enterprises are not yet perfect enough, and the value of SQA personnel has not been fully reflected.
The relationship between QA and organizational-level supervision and management
Some enterprises have established the role of "organizational-level supervisors and managers" to better supervise and manage projects. Their responsibility is to conduct unified tracking, supervision, and appropriate management of all projects to ensure that the management has visibility and manageability over all projects. To achieve effective project management, "organizational-level supervisors and managers" must conduct in-depth analysis of project data.
From the perspective of the management system model, the "organizational supervisors" mainly perform the "feedback" function. QA itself rarely conducts feedback work, and at most only provides feedback on information about the process execution.
The responsibilities of SQA should preferably not be mixed with those of "organizational project managers". Otherwise, an SQA dilemma is likely to occur: On the one hand, SQA may not be able to accurately position its own work; on the other hand, process executors may be quite wary of SQA personnel.
If an enterprise establishes a good management process, it will enhance the visibility of projects, thus ensuring the enterprise's effective management of all projects. And the responsibility of QA is to ensure the smooth operation of this management process.
The work content and methods of SQA
SQA needs to formulate a detailed SQA plan for specific projects to ensure that the project team can correctly execute the process. When formulating the SQA plan, the following points need to be noted:
Have key points: Determine the key points of the audit based on the enterprise's goals and the specific circumstances of the project. Different projects may have different key links, so targeted audits are required.
Clarify the audit content: Clearly determine which activities and products need to be audited. This helps SQA personnel to have a clear target during the audit process and improve the audit efficiency.
Clarify the audit method: Determine which method to use for the audit, such as regular reviews, random spot checks, or special audits, etc.
Clarify the rules for the audit result report: Specify the recipients and methods of the audit result report to ensure that the audit results can be promptly and accurately conveyed to relevant personnel.
Audit/Verification
SQA personnel conduct audit work according to the SQA plan and issue audit result reports in accordance with the rules. During the audit process, project team members must accompany the SQA personnel to avoid surprise inspections. Both parties should be open and honest with each other to ensure the smooth progress of the audit work.
The main contents of the audit include whether the project has carried out corresponding activities as required by the process and whether corresponding products have been produced as required by the process. Through the audit, SQA personnel can identify problems in the project process and promptly put forward improvement suggestions.
Problem tracking
Regarding the issues discovered during the audit, SQA personnel require the project team to make improvements and follow up until the issues are resolved. This process requires SQA personnel to have strong tracking and coordination abilities to ensure that the issues will not be shelved or delayed.
Quality requirements of SQA
Process-centered: SQA personnel should consider issues from the perspective of the process. As long as the correctness of the process is ensured, QA has fulfilled its responsibility. This requires SQA personnel to have an in - depth understanding and grasp of the entire process of the enterprise.
Service spirit: SQA personnel should serve the project team and help the project team ensure the correct execution of processes. They should provide support and assistance to the project team with a positive attitude, rather than merely acting as supervisors.
Understanding the process: SQA personnel need to have a profound understanding of the enterprise's engineering process and possess certain theoretical knowledge of process management. Only in this way can they accurately judge whether the project process meets the requirements.
Understand development: Have a certain understanding of the basic situation of development work and be able to understand the project activities. This helps SQA personnel communicate better with developers and identify potential problems in the development process.
Communication skills: Be good at communication, which can create a good atmosphere and prevent the audit activity from becoming a nit - picking activity. Good communication skills can enable SQA personnel to establish a good cooperative relationship with project team members and improve work efficiency.
SQA activities
Software Quality Assurance (SQA) is an activity that runs through the entire software process, and it includes the following aspects:
Quality management method: Adopt scientific quality management methods to ensure the stability and improvement of software quality.
Effective software engineering techniques: Apply advanced software engineering techniques (methods and tools) to improve the efficiency and quality of software development.
Formal technical review: Adopt formal technical reviews throughout the software process to promptly identify and resolve issues in the software.
Multi - level testing strategy: Develop a multi - level testing strategy to conduct comprehensive testing on the software and ensure its reliability.
Control of software documentation and its modifications: Strictly control software documentation and its modifications to ensure the integrity and accuracy of the documentation.
Ensure software compliance with software development standards: Ensure that the software development process and products comply with relevant software development standards.
Measurement and reporting mechanism: Establish a measurement and reporting mechanism to conduct quantitative evaluation of software quality and report the software quality status in a timely manner.
SQA is associated with two different types of participants, namely software engineers who do technical work and the SQA group responsible for the planning, supervision, documentation, analysis, and reporting of quality assurance.
Software engineers consider quality issues by adopting reliable technical methods and measures, conducting formal technical reviews, and performing well - planned software tests, and complete software quality assurance and quality control activities.
The main responsibility of the SQA group is to assist the software engineering group in obtaining high-quality final products. Specifically, it includes the following aspects:
Prepare the SQA plan: Prepare an SQA plan for the project. This plan is determined when formulating the project - specified project plan and is reviewed by all interested relevant departments. The content of the plan includes the audits and reviews to be carried out, the standards that the project can adopt, the procedures for error reporting and tracking, the documents generated by the SQA group, and the amount of feedback provided to the software project team, etc.
Participate in the review of the process description: Participate in the software process description of the development project and review whether the process description is consistent with the organizational policy, internal software standards, external standards, and other parts of the project plan.
Review software engineering activities: Review various software engineering activities to verify whether they comply with the defined software process. Record and track deviations from the process, and promptly identify and resolve problems existing in the process.
Audit of software work products: Audit the specified software work products to verify whether they meet the pre - defined requirements. Conduct a review of the products, identify, record, and track the deviations that occur, and verify whether they have been corrected. Report the work results to the project manager on a regular basis.
Handling deviations: Ensure that deviations in software work and products are documented and handled in accordance with the predetermined procedures.
Report non - conforming parts: Record all non - conforming parts and report them to senior leaders so that senior managers can timely understand the quality situation of the project.
VIII. Formal Technical Review (FTR)
Formal technical review is a crucial part of the software quality assurance system. It is an important activity jointly participated in by software engineers and other relevant personnel. In the complex process of software development, it is like a strict quality inspector, ensuring the high - quality delivery of software.
Review objectives
Formal technical reviews have multiple important objectives. Firstly, they aim to discover errors in the software at the functional, logical, or implementation levels. In the software development process, even a tiny logical error may cause serious problems in subsequent use. Through reviews, these potential hidden dangers can be detected in a timely manner. Secondly, it is necessary to confirm that the reviewed software can indeed meet the established requirements. Software development is centered around user requirements. If the final product fails to meet the requirements, all previous efforts will be in vain. Thirdly, it is required to ensure that the software representation complies with the predefined standards. Uniform standards contribute to improving the readability and maintainability of the software, enabling different developers to smoothly take over and understand the code. Additionally, through reviews, software developed in a consistent manner should be obtained, which helps to improve the efficiency of team collaboration and avoid chaos caused by differences in development methods. Finally, reviews can also make the project easier to manage. Through the inspection and evaluation of various aspects of the software, project managers can better grasp the progress and quality status of the project.
Review meeting
The review meeting is usually attended by 3 - 5 people and lasts no more than 2 hours. The participants include the review chairperson, reviewers, and producers. During the meeting, one of the following decisions must be made:I. Determine whether the work product can be accepted without modification. If the work product meets all requirements in every aspect and has no obvious errors or problems, it can be directly accepted.II. If serious errors are found in the work product and it fails to meet the basic requirements, then the work product needs to be rejected.III. If there are some problems with the work product, but these problems are not serious enough to require direct rejection, the work product can be temporarily accepted and then modified and improved later.
Review Summary Report
The review summary report is an important output of the review process. It answers key questions such as what is being reviewed, who conducts the review, and what the conclusion is. This report is not only part of the project's historical records but also an important basis for subsequent improvement work. It can identify the problem areas in the product, just like a map, indicating the directions for improvement to the producers. Meanwhile, it can also serve as an administrative item checklist to guide the producers in making targeted corrections.
Review guiding principles
During the review process, a series of guiding principles need to be followed.I. First, review the product rather than the producer. The purpose of the review is to improve the quality of the software, not to criticize individuals. Therefore, when pointing out errors, be polite and create a relaxed atmosphere so that the producers are more willing to accept the opinions and make positive improvements.II. Second, stay on topic and limit arguments. At the review meeting, there may be some controversial issues, but don't have excessive arguments at the meeting. Instead, record these issues and conduct in - depth discussions and solutions after the meeting.III. Third, express opinions on all issues, give full play to the wisdom of the review team, and comprehensively identify the problems in the software. However, the problem - solving should be carried out after the review meeting to avoid the meeting being too long and deviating from the theme.IV. Fourth, it is necessary to establish a checklist for each work product to be reviewed. Corresponding checklists should be established for analysis, design, coding, test documents, etc., which can ensure the comprehensiveness and accuracy of the review.V. Fifth, allocate resources and time reasonably, schedule the review as a software engineering task, and ensure that the review work can be completed on time and with high quality.VI. Finally, the previous reviews should also be reviewed. By summarizing experience and lessons, continuously improve the review methods and processes.
IX. Statistical Software Quality Assurance
Statistical software quality assurance is a means of software quality guarantee based on data and statistical methods. It calculates and analyzes the error indicators of each step in the software process to evaluate the quality status of the software and put forward improvement suggestions.
Error indicator calculation
In each step of the software process, multiple error indicators need to be calculated. First, several important parameters are defined: Ei represents the total number of errors found in the i-th step, Si represents the number of serious errors, Mi represents the number of general errors, Ti represents the number of minor errors, and PS represents the product scale of the i-th step (which can be the number of lines of code, the number of design statements, or the number of document pages, etc.). Meanwhile, weighting factors Ws, Wm, and Wt are set for serious, general, and minor errors respectively, and the recommended values are Ws = 10, Wm = 3, and Wt = 1.
In each step, first calculate the stage indicator PIi for each stage using the formula PIi = Ws(Si / Ei) + Wm(Mi / Ei) + Wt(Ti / Ei). This indicator comprehensively considers the proportions and weights of different types of errors and can more accurately reflect the quality status of the stage. Then, calculate the overall error indicator using the formula Error Indicator Ei = ∑(i×PIi) / PS = (PI1 + 2PI2 + 3PI3 + … + i*PIi) / PS.
Quality improvement
Combining the error indicators with the previously collected information can yield the overall improvement indicators for software quality. Through the analysis of these indicators, we can identify the weak links in the software process and propose targeted improvement measures. For example, if the error indicators for a certain stage are too high, it is necessary to conduct an in - depth analysis of the development process of that stage, find out the causes of the errors, and take corresponding improvement measures, such as strengthening code review and increasing test coverage. At the same time, considering the error indicators of the "vital few", that is, focusing on the error types and stages that have a greater impact on software quality and concentrating efforts on improvement, can more effectively improve the overall quality of the software.
VII. Quality Assurance and Inspection
Quality assurance and inspection play a crucial role in the software development process. They are like two strong lines of defense, ensuring the quality of each development process and preventing software errors from spreading to the next process like a virus.
Purpose of the test
There are mainly two purposes for testing. Firstly, it is to effectively manage the development stage and check the quality assurance of each development stage. Software development is a phased process, and each stage has its specific goals and tasks. Through testing, it can be ensured that the work of each stage meets the corresponding quality standards, laying a foundation for the smooth progress of subsequent stages. Secondly, it is to prevent in advance the losses caused to users by software errors. Once the software is delivered to users, if there are errors, it may bring inconvenience to users or even cause significant losses. Therefore, conducting strict testing during the development process can nip errors in the bud and safeguard the interests of users.
Inspection type
Inspections can be divided into various types. Supply inspection is an examination of components, specifications, semi - finished products, or products that constitute software products, which are purchased or transferred after the development work is entrusted to an external unit. In today's era when software outsourcing is becoming increasingly common, supply inspection can ensure that the purchased software components meet the requirements and avoid affecting the quality of the entire software due to problems with external suppliers. The purpose of intermediate inspection/stage review is to determine whether it is possible to enter the next stage for subsequent development and prevent errors from spreading to subsequent work. Conducting reviews at the end of each development stage can promptly identify problems and make corrections, ensuring that the work of the next stage can continue on the correct basis. Acceptance inspection is to confirm whether the product has met the quality requirements for product inspection. It is the last checkpoint before product delivery. Only after passing the acceptance inspection can the product enter the market. Product inspection is to determine whether the software product provided to users has reached a satisfactory level. From the user's perspective, a comprehensive evaluation is carried out on aspects such as the software's functions, performance, and usability.
X. Contents of inspection items
The content of inspection items covers all stages of software development. Through detailed inspections of different stages, the quality of the software is ensured.
Requirement analysis
During the requirements analysis phase, it is necessary to check the development purpose, target values, development volume, required resources, product operation content at each stage, and the rationality of the development system. Requirements analysis is the starting point of software development. Only by clarifying the development purpose and target values, reasonably estimating the development volume and required resources, planning the product operation content at each stage, and establishing a scientific development system can the correct direction be provided for the subsequent development work.
Design
The design phase includes structural design, data design, and process design. In this phase, it is necessary to check the planned quantity and actual quantity of the product, the reviewed quantity, the number of errors, the review method, the causes of errors and their handling, as well as the criteria for judging the end of the phase. The quality of the design directly affects the software's architecture and performance. By checking these aspects, the rationality and feasibility of the design scheme can be ensured, and problems that arise during the design process can be discovered and solved in a timely manner.
Realize
The implementation phase includes program coding, unit testing, integration testing, and confirmation testing. In addition to the above inspection items, the testing environment and the design method of test cases also need to be inspected. The rationality of the testing environment and the effectiveness of test cases directly affect the test results. A good testing environment can simulate real usage scenarios, and reasonably designed test cases can cover various functions and boundary conditions of the software, ensuring that the software can run stably in actual use.
Acceptance
In the acceptance stage, the main tasks are to check the instruction manual and the program. The instruction manual is an important guide for using the software, and it should accurately and clearly describe the software's functions and usage methods. The program check involves a comprehensive inspection of the final version of the software to ensure that it can run normally and meet the users' needs.
1.3 Implementation of Quality Assurance
The implementation of software quality assurance needs to follow certain standards and steps. Through comprehensive evaluation and continuous improvement of software quality, it is ensured that the software can meet the users' needs.
Software quality evaluation criteria
Software quality evaluation criteria include quality requirement criteria, quality design criteria, and quality measurement criteria. The focus of quality requirement criteria is whether the requirements of users are met. The ultimate goal of software is to serve users. Only when the requirements of users are met does the software have the value of existence. Quality design criteria focus on whether developers ensure quality according to software requirements during the design and implementation process. Reasonable design is an important guarantee for software quality. Quality measurement criteria specify some inspection items for quality measurement, including precision measurement, comprehensive measurement, and simple measurement. Precision measurement conducts detailed measurement according to quality measurement criteria and can more accurately evaluate the quality of software; comprehensive measurement conducts a comprehensive evaluation of software from multiple aspects; simple measurement conducts a preliminary evaluation of software quality in a concise way.
Implementation steps
The implementation of quality assurance can be divided into five steps. Firstly, there is the Target step. Based on user requirements and development tasks, evaluate the setting of quality targets for the quality characteristics of quality requirement criteria and quality design criteria. Clear quality targets can provide directions for subsequent development and evaluation work.Secondly, there is the Plan step. Set up evaluation and inspection items suitable for the software to be developed, usually 20 - 30 items are set. These inspection items can cover all aspects of software quality to ensure the comprehensiveness of the evaluation.Thirdly, there is the DO step. Under the guidance of development standards and quality evaluation criteria, produce high - quality specification documents and programs. High - quality documents and code are the foundation of software quality.Fourthly, there is the ChECk step. Evaluate according to the quality evaluation criteria set in the Plan stage, calculate the scores, present them in the form of a quality chart, and compare the quality scores of the evaluation results with the quality targets to see if they are qualified. Through the intuitive quality chart, the quality status of the software can be clearly understood.Finally, there is the Action step. Carry out improvement activities for the problems found in the evaluation, and repeat the process from Plan to Action until the development project is completed. Continuous improvement is the key to improving software quality.
1.4 Software reliability
Software reliability is an important indicator for measuring software quality, and it is related to the stability and usability of software in actual use.
Reliability definition
The statistical definition of software reliability is the probability that a program runs successfully as designed within a given environment and a given time interval. In actual use, software may encounter various complex environments and situations. The higher the reliability of the software, the more it can ensure normal operation under these circumstances.
Main indicators
The main indicators of software reliability include MTBF (Mean Time Between Failures), MTTF (Mean Time To Failure), and MTTR (Mean Time To Repair). MTBF represents the average time interval between two failures of the software, MTTF represents the average time from the start of the software's operation to the occurrence of a failure, and MTTR represents the average time required to repair the software after a failure occurs. The relationship among the three is MTBF = MTTF + MTTR. Software availability refers to the probability that a program can execute as required at a given point in time, and the calculation formula is availability = MTTF / (MTTF + MTTR) × 100%. Through the analysis and optimization of these indicators, the reliability and availability of the software can be improved to meet users' requirements for software stability.
1.5 ISO9000 Quality Standard
The ISO9000 quality standard is a set of widely recognized and adopted quality management system standards, which provides software enterprises with a set of scientific and standardized quality management methods.
Adoption status of standards
The ISO9000 standard has been adopted by many countries, including all members of the European Union, as well as Canada, Mexico, the United States, Australia, New Zealand and the Pacific region. This fully demonstrates the international influence and recognition of this standard.
Registration process
To register as one of the quality assurance system models included in ISO9000, a company's quality system and operations should be carefully examined by a third - party auditor to check for compliance with the standards and the effectiveness of the operations. Only by passing a rigorous audit can a company obtain registration eligibility. After successful registration, the company will receive a certificate issued by the registration entity represented by the auditor. Thereafter, a surveillance audit will be conducted every six months to ensure that the company continuously meets the standard requirements.
ISO 9001 standard
ISO 9001 is a quality assurance standard applied to software engineering. This standard includes 20 requirements that an efficient quality assurance system must embody. Since the ISO 9001 standard is applicable to all engineering industries, a subset of the ISO guidelines, ISO 9000 - 3, was specifically developed to help explain the use of this standard in the software process. The requirements described in ISO 9001 cover topics such as management responsibility, quality system, contract review, design control, document and data control, product identification and traceability, process and control, inspection and testing, corrective and preventive actions, quality control records, internal quality audits, training, service, and statistical techniques. By following the ISO 9001 standard, software enterprises can establish a comprehensive quality management system and improve the quality and competitiveness of their software.