Continuous Quality Management of Software Applications
Today’s software applications are fundamentally different in nature as compared to what we have seen them till very recently. It is primarily in terms of how they are being developed, their complex architecture, variety of usage by end users, varying needs of users from the applications and its ability to sustain to big data needs. So it is of paramount importance that the applications are envisaged rightly for these needs and are ensured that it is getting rightly built throughout the life cycle phases of the same i.e. conceptualize to deployment. Continuous Application Quality Management (CAQM) is simple approach that will help all the software application teams to join hands and ensure the right application with right quality is delivered thought the life cycles. The testing team OR quality assurance team can play extremely important role in the same by providing right orchestration and collaboration of various independent teams of software development like BA, designer, architects, user experience team, QA, developers and many others. This article reveals the CAQM approach with some relevant tips and tricks of how to go about it.
CAQM is extremely powerful approach to ensure critical to quality requirements are gathered from right stakeholders and they are implemented well in an application.
What is “continuous application quality management i.e. CAQM”?
Every individual software system/application possesses unique set of quality requirements which are critical to that application. These quality requirements can be from functional perspective OR non-functional aspect as well. Most of the software projects pay attention to these quality requirements only at the time of system testing or performance testing. That is a reason that many a times software system which is functionally excellent fails to cater to the need of users as no one paid enough attention to these “critical to quality requirements” when the system was getting built. Even if there is adequate focus on to test these requirements during testing phase, it might be too late and too costly to fix the issues as cost of fixing a defect rises exponentially with each LC stage.
CAQM suggest that there should be focus on “critical to quality requirements” right from the beginning by various stakeholders involved in the application development. It also ensures that these parameters are monitored, measured through-out the life cycle of an application and corrective OR preventive actions are implemented at right time to get the application health on track.
Let me explain this concept with a simple day to day example. With this example, it would be very easy for you to relate the scenario with software application as well. Let’s say I have a mission in hand that in next 6 months I need to clear certain medical test of military entrance exams which has very stringent requirements on my health parameters. So first thing I will do is understand the “critical to quality” requirements of this entrance test i.e. the requirements in terms of health parameters like height, weight, BP, blood sugar levels, thyroid, B12 levels, vision etc. which will help me clear the test if they are in the best possible range. So I will identify the key parameters and its values that I should be attaining after 6 months. I visit my family doctor and discuss this. As he knows my medical history, he suggests 2 more parameters to track as they impact the thyroid levels. Then I conduct all the medical tests and measure the parameters. I create a plan like below in consultation with my doctor so as to reach to the target value of parameters. I also decide the frequency in which I need to measure the parameters on ongoing basis till the entrance exam date. So I create health assessment dashboard for all the parameters that are critical for me to be exactly same or better as that of target values like the one below. I have given it for couple of parameters and couple of intervals. But I need to maintain it for all parameters throughout the journey.
I can also track all my parameters on a spider chart graph as shown in the diagram. It helps to get a quick understanding of where exactly I stand today and where do I need to reach.
So as I have started right with identifying right health parameters, their expected target values, by consulting SMEs to understand what more should be focused. Then I am taking a stock of where am I on start of the journey so that I know how much ground is to be covered. I take necessary efforts and actions and measure the parameters on regular small intervals and take necessary course correction so as to ensure that I will achieve my targets. So with this approach likelihood of me clearing my military entrance test is more as compared to what I would have normally done. Normally one may not have gone with so much of a methodic approach and ensure regular frequency check -ups and possibly would have just checked the values before entrance tests. In such case, chances of me not clearing the tests are more as I have simply left it to my luck factor.
So essential take away from this approach is
- Gather right requirements/parameters that are critical for our mission
- Reach out to right set of stakeholders to understand these requirements from their perspective
- Set target values to these parameters so that the final outcome will be the best
- Periodically measure the values/health of the project
- Consult subject matter experts to take corrective/preventive actions at that stage only instead of making it very late in the cycle
- Implement action items and check its effectiveness in next interval results. If not effective, re-plan the same.
A very similar analogy can be drawn for software quality as well. Traditionally, for better software quality we just rely on system testing and performance testing just towards the end of life cycle and if something drastically wrong is found, it is almost impossible to go back and correct the same. We will still correct something and release application to production. But people may not use it because it is not serving the “critical to quality” needs of an end user.
Hence I will recommend the CAQM approach to address this issue and ensure right software is built and delivered.
CAQM is based on ISO 9126 concepts which define “Critical to Quality” requirements of any software. ISO 9126 defines various software characteristics like functionality, reliability etc. For each of the characteristics there are sub-characteristics associated like maturity and fault tolerance are sub-characteristics of reliability. For each of the sub-characteristics there are multiple metrics that can help evaluate that particular aspect of the same. One such sample metric is given below
- TurnAround time is a metric defined under efficiency characteristics and time behavior sub-characteristic.
- Definition: – What is the wait time the user experiences after issuing an instruction to start a group of related tasks and.
- Formula: – T = Time at which user finished getting output results – time at which user finished placing request
A quick summary of ISO 9126 characteristics and sub-characteristics is given below for reference.
But in case if your applications CTQ requirements are something other than the one mentioned in ISO 9126 model, you can include them for your application and track them.
How to implement CAQM in software development?
The below section depicts how CAQM can be implemented in a software project.
Key success criteria
The key success criteria for implementing this approach is –
- Collaborative approach – Typically the activities in CAQM demand that they need to be done in a collaborative fashion having various teams involved in as mentioned above. Every team needs to have a single vision i.e. best quality of application in optimal time to market and cost. They should be extremely open and flexible to accept the issues and problems that have occurred due to their contribution in the SDLC and should be ready to rework on it even if indicated by some other team.
- Customer willing ness to invest extra– As these are some additional activities that are suggested on and above the basic SDLC phases activities, there should be willingness by client to spend extra money on the effort and time needed to perform these activities. The expected ROI on these investments is huge as compared to the investment made.
- No cuts on any of the standard technical reviews of process artifacts at various life cycle stages – The approach suggested in CAQM is over and above the traditional life cycle appraisal and prevention activities. This does not recommend any cuts in the reviews/testing etc. which is part of the life cycle phases.
In absence of any one of the points below, the overall approach for CAQM will not be effective.
Conclusion
CAQM is an approach using which there can be constant focus on key health parameters of the application. Application health is monitored in multiple logical intervals and corrective/preventive actions can be taken up at right point in time.
This needs a collaborative approach for successful implementation. Though primarily it is based on ISO 9126 model, we can have any other critical to quality attributes which are specific to the application or client context. CAQM can be achieved in simple spreadsheet based tools that we can create to capture, track and create trend analysis of the data. If done in a right way and right spirit, it helps achieving great results in terms of application quality, productivity, cost and time to market.
References
1. ISO 9126 model