How to implement Software Quality Assurance

Software Quality Assurance (SQA-Software Quality Assurance) is a key process domain in level 2 of CMMs. It is a third-party independent audit activity that runs through the entire software process, common features that appear in the check and verification of most key process domains play an important role throughout the software development process. From the six key process domains included in level 2, whether it is requirement management, software project plan, software project tracking and monitoring, software sub-contract management, Software Configuration Management, it exists to varying degrees in the software project development process that we are currently developing. We are no longer unfamiliar with their understanding. Only SQA is a key process domain, we have never touched on software process improvement based on the key process domains required by cms2. In many software enterprises, there are no corresponding personnel or working methods, and the entire software quality assurance system focusing on the software development process has not yet been established. Therefore, SQA is often a difficult issue for enterprises to improve software processes based on the key process domains of cms2, directly involving changes in the organizational structure.

Implementation of SQA

The purpose of software quality assurance is to independently review the implementation of software development tasks from the perspective of a third party, provide developers and management with information and data reflecting product and process quality as to whether software projects are complying with established plans, standards and procedures to improve project transparency, at the same time, it assists the software engineering team to obtain high-quality software products. It mainly includes the following four aspects:

● Ensure Product Quality by monitoring the software development process;

● Ensure that the developed software and software development process comply with relevant standards and procedures;

● Ensure that non-conformity problems in software products and software processes are handled, and report the problems to senior managers if necessary;

● Ensure that the plans, standards and procedures developed by the project team are suitable for the project team's needs and meet the review and audit needs;

In addition to the above four points, we also hope that SQA can be used as an extension of the software engineering process team (SEPG) in the project team to collect good implementation methods in the project and find out the causes of adverse implementation, it provides a basis for modifying the overall software development specifications within the enterprise and provides advanced methods and samples for the implementation of the development process of other project teams.

Quality requirements for SQA personnel

1. SQA personnel (sometimes referred to as SQA) must have strong communication skills. It can be seen from the implementation of SQA that SQA is not a third party in the project and is independent from the software project, but he wants to know the development process and progress of the project, capture non-conforming issues in the project, which requires SQA to be able to go deep into the project and maintain good communication with the software development manager and the developers in the project team, in this way, real project information can be obtained in a timely manner.

2. SQA should be familiar with the software development process. As SQA, to ensure that the project team's plans, standards, and procedures meet the requirements of the project team, SQA must first understand the software project development process and existing development process specifications in the enterprise.

3. SQA should be well planned. On the one hand, SQA should supervise the software project team to compile the plan, on the other hand, SQA's own work should also be planned, and work should be carried out according to the plan.

4. SQA should be able to cope with complicated work. As SQA, many work products of the project team should be audited when tracking the project process, and participate in various activities of the project team. At the same time, a SQA may also face multiple project groups, so the tasks are relatively complicated and detailed, which requires SQA to be patient and meticulous when dealing with these tasks.

5. SQA should be objective and responsible. As a third party to supervise the project process, SQA must be able to maintain its own objectivity, not to favor the project manager, nor to become the policemen in the project team, otherwise it will affect the development of the work. For problems that cannot be solved by the project team through multiple coordination, the project manager can be informed to fulfill SQA's mission.

The above five points are the basic qualities that SQA should possess. In addition, a good SQA should have participated in one or more links as developers or Testers in the software development process, in this way, they can grasp the key points accurately in the process supervision. At the same time, their opinions and proposed solutions will be closer to the project team and will be easily accepted by the project team.

Composition of SQA personnel

SQA personnel in a software enterprise can be full-time or part-time personnel with relevant quality and passing SQA training in the enterprise. The resulting SQA team may be an independent physical department or a logical platform. However, whether it is an independent department or a logical platform, it requires a soul character-the SQA team leader to organize the daily activities of the SQA group.

When assigning SQA to a project team that is responsible for supervising its project process, note that SQA cannot be a developer, Configuration Manager, or Tester of the project team, in addition to monitoring the project process and completing SQA-related work, SQA of a project should not participate in other substantive work of the project team. Otherwise, SQA will be bundled with the project team and it is difficult to maintain objectivity.

Content of SQA work

SQA mainly includes the following six types of work:

1. work directly related to the SQA plan: In the early stage of the project, SQA should formulate its corresponding SQA plan according to the project plan, and define the inspection focus of each stage, identifies the work product objects for inspection and auditing, and the output products of SQA at each stage. The more detailed the definition, the more guidance SQA will provide for future work. It also facilitates the software project manager and SQA team lead to supervise its work. After preparing the SQA plan, organize the SQA Plan Review and form a review report. Send the reviewed SQA plan to the software project manager, project developers, and all relevant personnel.

2. participate in the periodic review and audit of the project: In the SQA plan, the phase check corresponding to the project stage has been defined according to the project plan, this includes participating in the project's review at this stage and auditing of its products. Audits of products at the stage usually check whether the products at the stage are output according to the plan and the content is complete. The procedures here include the unified internal procedures of the enterprise, as well as the self-defined procedures within the project team. However, SQA is generally not responsible for the correctness of the product content at the stage. The correctness of the content is usually reviewed by the project. SQA participation in the review starts from ensuring the effectiveness of the review process, for example, if the person who participates in the review is qualified or specified, all the persons who participate in the review are reviewed and each part of the object to be reviewed is reviewed, and a clear conclusion is given..

3. Check the compliance of routine project activities and procedures: This part of work content is the daily work content of SQA. Because SQA is independent of the project team, it is difficult for SQA to reflect the work process of the project team in a timely manner if it is only involved in the Periodic inspection and audit. Therefore, SQA must set several small tracking points between the two phase points, to monitor the progress of the project, so as to reflect the problems in the project team in a timely manner and track them. If you only check and audit at the stage, even if you find the problem, it will inevitably lag too far. It does not meet the overall goal of discovering the problem as soon as possible and keeping the problem within the minimum scope.

4. check and audit the Configuration Management Work: SQA should supervise the configuration management work in the project process according to the initial configuration management plan of the project, this includes whether the configuration management personnel perform such work on a regular basis and whether all users obtain a valid version of the development process product.

The process products here include the code and documentation generated during the project process.

5. tracking problem resolution: SQA should track the problems found during the review and the problems found in the daily work of the project until they are resolved. Problems that can be solved within the project team. problems that cannot be solved within the project team, or problems that cannot be solved after many reminders in the project team, reports to senior managers through independent reporting channels.

6. collect new methods and provide the basis for process improvement: such work is hard to be defined in the SQA plan, but SQA has the opportunity to directly access many project teams, first-hand information can be obtained accurately for the advantages and disadvantages of the project team in the development and management process. They have the opportunity to understand how the project team manages and what effective methods they use to share with other SQA activities in the SQA group. In this way, these good implementation instances can be spread to more project groups. Where the process specification definition in an enterprise is inaccurate or inconvenient, the software project team can also reflect it to the software engineering process team through the SQA team to facilitate the next steps to modify and improve the procedures.

Relationship between SQA and several types of roles

Department settings in an enterprise may vary, but many role settings are the same. Starting from SQA in a project, we can express the relationship between SQA and other related roles:

To show that only the relationship between SQA and the senior manager, the project team, and other relevant groups is not described in all the relationships between the above roles, so even if the project team reports directly to the senior manager, it has no direct relationship with SQA and is not shown in the figure.

FAQs about SQA

1. When SQA personnel were initially assigned to the project team, the value of SQA was not recognized.

Because it was the first time to start a new job and was used to managing projects by myself, it was inevitable that the project team reported to the senior manager had resistance. We need to solve this problem from two aspects: on the one hand, from the perspective of the Organization, we need to clarify the role and legitimacy of SQA; on the other hand, SQA should also win the approval of the project team with its professional work, add value to the project team.

2. How many projects SQA can work for a full-time SQA simultaneously?

There are different answers to this question for different project scales and organization management methods. Based on some experiences in implementation, this is usually the first implementation, taking on SQA for a project team of about 20 members requires about 30% of the workload of one person. As SQA matures, this proportion will be reduced to 15%. For a project team of less than 10 members, SQA needs to invest about 10% of its workload. Of course, the larger the project, the more SQA will invest.

3. The relationship between SQA and the project team is hard to handle

The relationship between SQA and the project team should follow the following two principles: to become a strict engineer of the project team in terms of process, correct errors, but do not report all errors; to be a friend of the project team, however, the project team cannot be pampered.

4. The project team has SQA, but the quality of Requirement documents and design documents is still not high.

Sorry, this is not the scope of SQA's direct work. To improve the quality of requirements and design, we should start with personnel training and strict review, so that experienced and qualified persons can complete the requirements and design documents. SQA can only supervise compliance with regulations.

In short, the establishment of SQA System in software enterprises is a necessary stage for software project management from governance to the rule of law. It is also a reference for software enterprises to use CMM models, an indispensable part of software process improvement. As long as software companies have established SQA standards and trained professional SQA personnel, they will truly appreciate its benefits.