Basic Software Quality Practices at Enterprise Application Development

Quality Management

The Quality Management Guru Philip B. Crosby formulated four principles. The first principle says the definition of Quality is conformance to the requirements. The second principle says prevention is the system of quality. The third principle defines the performance standards as zero defects with respect to the requirements. The fourth principle is the price of non conformance as the measure of quality.

Software Development Process Quality

How to apply these principles to the Software Development? Which one to choose among the ISO 9001 certifications or CMMI maturity level declarations or domain specific process certifications for the quality management? What about the Product Certifications for the developed software?

Models for Software Process Quality

The ISO or CMMI or Domain specific quality frameworks or standards are built on well defined process models. Selecting the process models suitable to your process is difficult. Nowadays the Agile Methodologies are being practiced widely. The widely known agile methodologies are Scrum, Lean and Pair Programming.

The quality frameworks or standards have enough compatibility to adapt the Agile Methodologies. Make a matrix diagram containing requirements of quality frameworks or standards verses the key tasks of Agile Methodology. Align these to the Vision and Mission of the company. You will find the essential attributes of quality will be mapping to each other. The mindset of having every thing must be documented is not valid. Any task or documents with out value addition can be tailored in any quality framework.

If your business or product domain specific process standards ( such as aerospace standards, safety standards, infrastructure standards, environmental standards, security standards) are available, then make them as your process models. That is enough for software development processes.

Believe both the ISO 9001 and CMMI are highly similar to each other. Here any one is enough for software development processes.

The 5S methodologies are very much essential for Software Configuration Management Process. The software version control tools such as GIT, SVN and Release tools such as Jenkins are to be used for the better control of software development.

Many times two or three frameworks and standards are required and sufficient for the software quality management. Do not go for many frameworks. More the frameworks the more complex and we have to pay a plenty of price of conformance.

Models and Tools for Software Product Quality

The models for Software Product Quality can be adapted by tailoring the models from standards such as ISO9126. Many software architects perform the product security assessment, product risk assessment etc. and then arrive at the models and metrics to assure the Software Product Quality. Some will use the home grown models using the characteristics such as Functionality, Usability, Reliability, Portability and Maintainability. The software reliability is till a nascent field. The Code As infrastructure is emerging and will improve the quality of deployment. The Containers and Orchestration tools such as Kubernetes will improve the production oriented operations.

In order to get the good returns all the models and related measurements need to be automated using Tools. Making the code with best coding standards is not possible with out a tool.

Make more effort on practicing or embedding the Software Design Patterns, Patterns of Enterprise Application Architecture, Refactoring rather than developing the silos or statistical metrics. Nowadays the software development is moving from frameworks to the Platforms. Select the platform which provides the required architecture and attriutes for the product.

Quality is Conformance to requirements.

Mostly the software development starts with the requirements or specifications mentioned in the RFP (Request for proposal). These are very high level statements. Then the delivery of the software ends with the pass for all acceptance criteria. This end is the start of maintainance life of the product. A traceability chart is the most used tool to assure the journey towards the conformance to requirements. All the quality check list need to be embedded in the software life cycle tools.

While preparing the User Stories and Software Requirements definitions did we involve the User Domain Expertise (End User and Subject Matter Expertise)? Or we simply did the “cut and paste” of the specifications mentioned in the RFP. This matters a lot..

The Acceptance Criteria for the Non Functional Requirements (NFR) is the real challenge for both the Development and also for testers to prove that NFR. Many times we will under do or over do these tasks. This makes either the price of conformance or price of non conformance heavy.

Requirement Changes

The requirement changes emerge at any stage but those emerging at last stages of the project impacts more. These changes are usually from End users who are mostly vital for the project whom we neglected or we assumed we know what they want. An essential skill of negotiating these last minute changes to shift to the next release or to the maintenance phase is not uncommon. The Change Control Board (CCB) members need to have strong negotiation skills.

Defects Prevention

The software development is mostly based on the competency of the development team. The major factor that plays important in the defect prevention are skill levels of the team at the selected technology and tools of the project, understanding the team work, leveraging open standards and understanding the fundamentals of the End User Domain. The thumb rules such as only Certified professionals or persons with minimum 2 years of experience will be allowed to write the production software will help in prevention of defects.

Zero Defects with respect to requirements

This concept is very difficult in the software development. The software bugs are like icebergs under the sea. Many software development processes will have the release rule stating that the software would be released if no major defects reported at Acceptance testing. Do not forget the acceptance testing is valid only for the stated environmental or test or pre conditions.

The concept of the service level agreement and meeting the service level agreements are another path for the Zero Defects with respect to requirements.

The software defect tracking tools must be used continuously to log and track the defects reported. This provides the metrics such as downtime, defects Density extra which are related to the Zero defects with respect to reuirements.

Price of non conformance as the measure of quality.

The Cost of Quality (COQ) is made up of Price of Conformance (POC) and Price of Non Conformance (PONC). The Price of Non Conformance (PONC) includes rework, field failures etc.

The Price of Conformance (POC) have two components namely Appraisal Cost and Prevention Cost.

The Appraisal Cost can be reduced by using tools such as Selenium or equivalents or Automated Test Tools. For a good project the POC will be between 30 to 40% of Cost of Quality.

The prevention costs include the competency development training, failure mode and effect Analysis.

The Root Cause Analysis on the reported defects provides the area where the preventive measures can be implemented.

The Policy encouraging the innovations rather than improvements will provide the leap reduction at the Price of Non Conformance.

Acknowledgments

The Quality terms used here are the Principles of Quality Guru Philip B. Crosby.