Integrating Quality Management System into Software Development Processes

This article was written with the support of Rainer SCHARPEGGE, Senior Expert - SES Bonn

1. About

Software Quality Management System refers to the activities used by companies to manage the delivery of high-quality products. It can be realized in various ways depending on organization and type of projects developed but it should support the whole software development life cycle: collecting the requirements, design the solution, solution implementation, change management, and closing project.

To understand properly the Software Development processes it is important prior to get in touch with some close related concepts: Quality Assurance, Quality Control and Quality Plan.

Quality Assurance (QA) refers to the process used to create the deliverables and can be performed by a manager, client, or even a third-party reviewer. Examples of quality assurance include process checklists, project audits and methodology and standards development.

Quality Control (QC) refers to quality-related activities associated with the creation of project deliverables. Quality control is used to verify that deliverables are of acceptable quality and that they are complete and correct. Examples of quality control activities include inspection, deliverable peer reviews and the testing process.

Quality Plan (QP) refers to the process used for each project for declaring project commitment to follow an applicable set of standards (code standards), regulations, procedures (on how QC and QA are being executed), guidelines (best practices) and tools during the development lifecycle. In addition, QP should contain quality goals to be achieved, expected risks, and risk management. Quality Planning provides input for Quality Assurance (procedures, QA checklist, QA milestones).

2. QA vs QC

Comparing the differences in matter of activities and responsibilities between Quality Assurance and Quality Control provides us with a good appreciation of these different terms. QC validates that a specific deliverable meets standards and specifications.

In contrast, QA is a broad function covering proactive planning and monitoring throughout the development life cycle. Testing, on the other hand, forms an integral part of QC. For an organization to effectively implement Quality Management processes, these streams must work in tandem. It is recommended that organizations carefully consider the various possible challenges and have appropriate plans in place prior to embarking on quality management processes.

3. Is Software Quality Assurance the same as Testing?

The terms Testing and Software Quality Assurance (SQA) are often used almost interchangeably in the IT industry with testing professionals often classed as quality assurance professionals.

So, are these terms the same?

Although both have quality as their overall objective, a fundamental difference between the two is that testing is performed after a product has been built, or in the case of static testing, after a document has been written. In contrast, quality assurance consists of activities.

To appreciate the differences between Testing and SQA further, we have to go back to the closely related concepts, Quality Control and Quality Assurance.

Quality Control ensures that delivered products are checked for quality and determines how well it is built. Its focus is to find defects and to ensure that they are corrected. QC is the responsibility of the project team.

Testing forms an integral part of Quality Control. However, not all QC activities are testing activities. Code inspections, technical reviews, and stage gates are other examples of Quality Control activities.

The goal of QA is to ensure that quality will be built into the product. These activities usually precede the development of the product and continue while the development is in progress.

It is a QA responsibility to develop and implement processes and standards to improve the development life cycle and to make sure that these procedures are followed. The focus of QA is defect prevention, processes and continual improvement of these processes. Examples of QA activities include establishing standards and processes, quality audits, selection of tools and training.

4. How do test and QA team responsibilities differ?

Test teams perform test basis document reviews, test planning, test analysis, and design, test validation and verification, and test reporting through the different test levels.

In contrast, QA teams perform the following functions:

• Implement organizational quality policies, standards, and processes
• Assist projects with preparing software quality assurance or project quality plans
• Assure that project processes conform to quality plans
• Assure that:

o Independent reviews are conducted

o Change control procedures for projects are in place

o Configuration management procedures for projects are in place

o Procedures are in place for identification and management of Risks

o There are retrospectives or lessons learned processes planned and conducted

• Conduct regular audits of project products and processes, and present regular assessments to senior management
• Provide assurance through the system development life cycle
• Conduct continuous improvements to QA process and guidelines based on lessons learned

Although these attributes are labeled as QA team responsibilities, it should be noted that this does not mean that the QA team will develop these artifacts, but rather assure they are produced in a manner that is ‘fit for purpose’.

5. How to improve Quality Assurance?

To be successful, QA teams need to be independent of project and delivery teams. This provides the team with the ability to conduct an objective assessment of projects.

QA teams would find it much easier to work with project teams if they keep in mind the ‘fit for purpose’ principle. Providing guidance and assistance to project teams, forms a basis for maintaining good relationships, which is an important aspect of successful QA teams.

QA teams can only ensure adherence to processes and organizational policies if there is strong and consistent leadership team support.

Another ingredient for successful QA teams is employing the right staff. People with experience in the system development life cycle or software engineering make good candidates for QA roles.

Standard checklists are a useful mechanism to conduct reviews or audits of projects, particularly if they are developed in line with the phases of the development life cycle. For example, in the Design phase a checklist question could be ‘Is there traceability between design and requirement elements?’

QA teams need to continually get approval for changes to quality processes and standards and ensure effective communication with stakeholders.

Lessons learned from projects provide a QA team with a basis for evaluating its quality processes and guidelines and incorporating continual improvements. We learned several lessons that required making changes to our procedures. This included developing checklists, flexibility, maintaining good stakeholder relationships, and making improvements to our regular management reports.

6. Staffing a development project

• Include people who fit into the existing team culture. Good teams do not just appear magically one day, but instead are grown and nurtured over time. Invite people onto the team who will add value and, furthermore, who will not be disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing team and they do not seem to be able to change.
• People should want to be on the team. People are far more productive when they are working on a project that they believe in and want to see succeed.
• Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in their existing specialties as well as in other areas, including both technical and domain areas. Generalizing specialists add value to the team because they have specialized skills that you need, while at the same time appreciate the full range of issues that a general understanding of the software development process and the business domain offers.
• Include stakeholders. Stakeholders, including business stakeholders (such as end-users) and technical stakeholders (such as operations staff), can add significant value to your team. Instead of just interviewing them to gain information from them, or asking them to review your work, why not include them as active participants on the team?
• Include specialists for short-term, specialized work. Specialists can still add value on an agile development team, particularly when they have specific skills and experience that existing team members do not have. It can often be very effective to bring a specialist into the team for a short period of time to help with a specific task (such as installation and setup of an application server, the development of an architectural spike, or simply taking part in a review).
• Give people opportunities to evolve their skills. At the beginning of a project, the team may not have the full range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles they are filling. This is a very common risk taken by the majority of project teams for the simple reasons that you often cannot find the perfect combination of people and, even if you could, you still want to provide people with opportunities to grow as professionals.
• Adding people to a late project will only make it later.
  The consequence is that removing people from a late project may speed things up.

7. How to improve the productivity of teams?

Communication is tied directly to bringing comprehension of project objectives to common understanding, this is why involving the team to increase communication is a very important aspect.

Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service. Setting up an informative, shared workspace can help.

Institute a vigorous program of education and self-improvement. Every team member has an essential role in a project, this is why everyone needs to work to accomplish the transformation. The transformation is everybody's job. Measure productivity and efficiency on yearly reviews for example.

On any project the team setup needs to be done at the beginning: specify and define tasks for each person and set responsibilities. Tailoring the method in terms of check-in/out, deploy and test procedures, intervals and time of test, how to proceed in case of “misunderstandings”, etc also need to be taken into consideration.

Evaluate the estimation of planned per feature and reverse breakdown per person (avoid overloading). Set milestones for clean-up and product optimization. Also plan a maintenance release.

Everything needs to be documented. Document updates and code check-in with clear and understandable reasons, also valid for HELP files.

Aligning business and technical decisions through weekly and quarterly planning to check status, problems and fixes, special architectural issues, etc. Document the minutes of the meetings by an assistant (not the Project Manager).

One the most important indicators of a team member’s productivity is the ‘finish in time’ rate and the quality of code that can be evaluated for example by the number of bugs found on a feature.

Project reviews at end of project, steps or stage to conclude how to improve next project. Study the Process, not the results alone.

Conclusion

Software Quality Management System is essential to every project development life cycle. Without it, many development groups would not reach their release goals/deadlines or having incomplete releases because they would be spending too much time revising requirements, design, code, and documentation of each portion of a project to match. Establishing certain standards (rules) lowers the time spent working on making every part of the project look the same.

Also, it decreases the time from development to deployment. Reviewing these standards against what has been developed can help catch any errors before they become very costly to fix. These standards can be reused across many projects, which will improve the development time and lower the costs of each project involved.