How Software Quality Engineering and Design Quality Are Similar
REFLECTION: FOR STUDENTS: If your education looks as if it may lead to a point where you have interactions that involve a QMS, be sure to pursue at least a basic understanding of software, as that understanding will be gold in all future industry employment.
FOR ACADEMICS: AI and ML are coming, but it will be a while before any doctors or engineers are actively replaced, but it would be wise to teach your students how to think for yourself, not just rely upon the computer. Teach students to be the person who writes the program or qualifies the program, not the person who is told by the computer what to do.
FOR PROFESSIONALS/PRACTITIONERS: Learn all you can about the software world if you have not yet. If you are purely a Software Quality Engineer, get as much exposure to other quality systems to help open your mind up to different problem-solving pathways. Always be a lifelong learner.
Definition of Quality
There is no single definition of quality that has ever or likely ever will be agreed upon even in a single company, much less an entire industry or across industries, but the ISO/IEC/IEEE Systems and Software Engineering-Vocabulary (ISO/IEC/IEEE, 2010)
provides an excellent layout of every aspect of defining quality.
- The degree to which a system, component, or process meets specified requirements
- The ability of a product, service, system, component, or process to meet customer or user needs
- The totality of characteristics of an entity that bears on its ability to satisfy stated and implied needs
- Conformity to user expectations, conformity to user requirements, customer satisfaction, reliability, and level of defects present
- The degree to which a set of inherent characteristics fulfills requirements
Each organization must decide what quality is, however, only a world-class organization will always be using the feedback from all stakeholders to evolve the organization’s definition of quality so that stakeholders are satisfied at every level.
Changes Are Coming
I have written a couple of posts about how Quality 4.0 and Industry 4.0 are here. However, based upon the fact that the Quality industry is in many areas still building the foundations of a Quality culture that will support Quality 4.0, there are likely to be many quality professionals who fall into one of three major groups.
Some may be in a state of denial or unawareness of the exponential growth level of the emerging technology and believe things will stay the same as they have for all these years. The next group is made up of those who are fully aware of the changes that are coming. The members of this group and are getting ready for the inevitable change. The last, and most likely smallest group (though I have no formal data, shame on me), would be those who know what is coming but actively do not want the change to occur.
The reason I believe that would be the smallest group would be the fact that the vast majority of quality professionals are problem solvers, change agents, and not comfortable with things just staying as they are. The old “If it isn’t broke, don’t fix it” axiom is the antithesis of the Quality mindset.
Software Quality Engineering
In the past few years, I have witnessed the medical device industry evolve rapidly. A few years ago, I saw DHFs (Design History File), DMRs (Device Master Record), and DHRs (Device History Record), all kept on paper in files in a locked room and carefully controlled. Quickly the entire paradigm shifted to Cloud storage of these documents with ultra-tight security, in addition to management of routing of document approvals moving from physical signatures to electronic signatures. I also witnessed software become officially regulated as medical devices (SaMD).
Software Quality Engineering is- The study and systematic application of scientific technology, economic, social, and practical knowledge, and empirically proven methods, to the analysis and continuous improvement of all stages of the software life cycle to maximize the quality of software processes and practices, and the products they produce. Generally, increasing the quality of software means reducing the number of defects in the software and in the processes used to develop/maintain that software (WestFall, 2016). Software development usually uses an Agile project management approach. Agile project management seems to draw heavily from the Lean philosophy, which focuses on creating better customer value while minimizing waste. Both philosophies emphasize fast deliverables. The emphasis of Lean is on reducing waste and unnecessary steps; however, Agile emphasizes breaking large tasks into small ones and delivering in short sprints. Both Lean and Agile use some sort of an action loop. In Lean, this is the build-measure-learn cycle, while Agile’s scrum methodology uses an iterative sprint approach (L. Allison Jones-Farmer, 2016).
The iterative steps used as part of the Agile Scrum methodology help prevent excessive costs. When a defect is not caught early in the development of software, the defect can impact many more aspects of the software. The later in the life cycle the defect is detected, the more effort (and therefore expense) it will take to isolate and correct defects. A single defect in the requirement phase may have a “butterfly effect” and cause exponential levels of cost as the defect goes undetected.
At the end of each iteration, the goal would be to have a working example demonstratable for stakeholder review and feedback so that any issues with correctness or quality can be addressed in the next iteration (WestFall, 2016).
Traditional Design Quality
Design Quality from the manufacturing perspective aligns closer to Crosby’s viewpoint of the need for a well-defined specification against which to measure quality. One of the things about the fast-changing Quality world is that software is less about the reproducibility to spec and more about innovation. As the manufacturing world has found itself thrown into a massive acceleration in the last few decades, traditional design perspectives have been re-evaluated. Engineering tools like TRIZ have been employed to help spur innovation in design and problem-solving. Design For Six Sigma (DFSS) shifted product design away from just doing it right the first time toward robustly employing QFD to obtain the voice of the customer. The best DFSS process for a new design (in my opinion) would be the IDOV method- Identity (obtain VOC & CTQs), Design, Optimize, Validate. At the Validate stage, a prototype is tested and validated, with risks thoroughly analyzed (and as required, sent back to an earlier stage if validation is not accepted) (Kubiak, 2017). I have seen more and more manufacturing operations learning to use agile methods for design, frequently combining Agile with Lean, Six Sigma, or Lean Six Sigma depending upon the culture and knowledge base. It is clear that as software, apps, and AI become integral parts of product and production, the pace at which innovation must occur to meet customer requirements will continue to grow, perhaps eventually leading to a permanent fusion of Agile, Lean, and Six Sigma.
Conclusion
There are many other methodologies out there, like the waterfall mythology, which has lost a bit of popularity over the past few years to Agile methods, as well as CMMI, which I have heard conflicting reports on how compatible CMMI is with Agile. I would appreciate input from those in the software industry who can tell me firsthand how well CMMI and Agile work together. Software DevOps is effectively designing a product for stakeholders from ideation to operational release and monitoring/maintenance. Designing a physical item to sell on the market based upon the VOC using a QFD may be slower and use a more thorough investigation of the requirements and desired outputs (since you are addressing something tangible rather than an idea for a program). An idea that can provide value (software) is much harder to define in a neat specification box. Still, just like a DOE, you keep adjusting your settings and continue trying until you determine what factors are critical. Then you optimize the settings for your critical factors to obtain the best outcome based upon cost, functionality, and VOC. If you are worried about the coming changes, do not be worried, embrace the change, and be part of the change. Yes, in 20 years, we will all be behind a computer console writing code (if AI has not replaced al the Quality Engineers), but as long as you are looking forward, you will be moving in the right direction.
Processing…
Success! You're on the list.
Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.
Try Amazon Prime 30-Day Free Trial
Bibliography
ISO/IEC/IEEE. (2010). ISO/IEC/IEEE 24765 Systems and Software Engineering. Geneva, Switzerland: ISO New York, NY.
Kubiak, T. a. (2017). The Certified Six Sigma Black Belt Handbook Third Edition. Milwaukee: ASQ Quality Press.
L. Allison Jones-Farmer, P. T. (2016, 10). asqstatdiv.org. Retrieved from ASQ: http://asq.org/statistics/2016/10/agile-teams-a-look-at-agile-project-management-methods.pdf
WestFall, L. (2016). The Certified Software Quality Engineer Handbook 2nd Edition. Milwaukee, WI: ASQ Quality Press.
How to Communicate the Cost of Quality (COQ) In a Way Top Management Understands
REFLECTION: FOR STUDENTS: Use your business and management classes to prepare you for Improvement Project management. Nothing happens in a business unless it is profitable.
FOR ACADEMICS: If you are teaching Project Management be sure to teach more than “Top Management must support your team”. It will help greatly if team members understand why top management must buy into a project, as the economic model cannot be explained at the beginning of every project.
FOR PROFESSIONALS/PRACTITIONERS: If your organization finds itself in a silo mentality between production, quality and management, always use cost as the negotiating method. Hard dollars are not subjective or debatable.
What is the Cost of Quality?
I use the term Cost of Quality because the common term Cost of Poor Quality (COPQ) seems to fail to capture all the efforts in the quality metric that should be communicated to Top Management.
For many years there was a lack of understanding between the production and quality department. Quality usually knew when a process was wasteful, but production was not particularly concerned with operational excellence. The prime metric from a production standpoint was, “How many widgets did we produce this shift?” and “Did it meet our Quota?”. The scrap costs and rework costs were hidden deeply in the metrics, not because the data did not exist, but because the data were not being actively tracked. Top Management frequently was blind to the full cost of all the quality efforts and failures that were occurring during production (or even design quality costs).
This lack of communication led to the infamous “Hidden Factory” effect that drove the first wave of modern Quality Guru’s to try to bring Quality to the forefront of Business consideration. Taguchi, Crosby, Juran, Deming, Ishikawa, and Ohno all had similar views on waste, though they did not all have the same philosophies.
The end result was: After many years, the Culture of Quality and Change Management has become more the norm (though there is still far to go in many areas). Most Top Management has a language with which they can talk to the Quality and Production departments and can share, and that language is Dollars. Top management had always wanted a bottom-line impact report. It was not genuinely concerned with what Quality had to say until Quality started talking about lost dollars that impacted the bottom line.
Since the actual cost of producing a product to spec is approximately 15% for manufacturing firms, varying from as low as 5% to as high as 35% based upon product complexity of total costs, it presents a clear opportunity to cut the bottom line for reducing these overall costs (Joseph M. Juran, 2010) (Bill Wortman, 2013).
There are three primary categories of Quality Costs categorization: Prevention, Appraisal, and Failure. Once your organization has a firm classification of these costs, choosing to document the quality costs will provide project managers with a way to measure and prioritize Quality Improvement projects. Peter Drucker is credited with the obvious truth – “If it cannot be measured, it cannot be improved”.
Though some individual items such as Audits overlap, this is a useful high-level guide to categorizing your Quality Costs. (Failure has been divided into Internal and External Failures)
- Prevention Costs of Quality- Total cost of all activities used to prevent poor quality and defects from becoming part of the final product or service.
- Quality Training and Education
- Quality Planning
- Supplier qualification and supplier quality planning
- Process Capability evaluation (including QMS audits)
- Quality Improvement activities
- Process Definition and Improvement
- Appraisal Costs of Quality- The total cost of analyzing the process, products, and services
- Document Checking
- Analysis, review and testing tools, databases, software tools
- Qualification of the supplier’s products
- Process, product, and service Audits
- V & V activities
- Inspection at all levels
- Test equipment maintenance
- Failure Costs of Quality- The costs which result from products and services not conforming to requirements or customer/user needs.
- Internal Costs of Failure
- Occur prior to delivery
- Scrap
- Design changes
- Repair
- Rework
- Reinspection
- Failure documentation and review
- Occur prior to delivery
- External Costs of Failure
- Occur after delivery or during the furnishing of the service
- Customer complaint Investigations
- Pricing errors
- Returns and Scrap
- Warranty Expenses
- Liability claims
- Restocking
- Engineering Change Notices
- Occur after delivery or during the furnishing of the service
- Internal Costs of Failure
- (Wortman, 2013) (WestFall, 2016)
Conclusion
Top management support is required for an improvement project.
Any quality dept. will want to improve a process, but for a business, a business case must be presented to top management so they will help remove the roadblocks and provide resources. The quality department must be able to present the estimated ROI (Return on Investment) using the Cost Benefits Analysis to show that there is a viable business case for supporting the improvement project to gain support for the project. Even though improving a process may be the smart thing to do, sometimes it is not the financially viable thing to do at the time. Keep those projects on a back burner and monitor them, though. At some point, some changes may make the improvement much more viable.
Processing…
Success! You're on the list.
Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.
Try Amazon Prime 30-Day Free Trial
Bibliography
Bill Wortman. (2013). The Certified Biomedical Auditor Primer. West Terre Haute, IN: Quality Council of Indiana.
Drucker, P. (1954). The Practice of Management. New York City: Harper & Row.
Joseph M. Juran, J. A. (2010). Juran’s Quality Handbook (Sixth Ed). New York: McGraw-Hill.
WestFall, L. (2016). The Certified Software Quality Engineer Handbook 2nd Edition. Milwaukee, WI: ASQ Quality Press.
Quality Concepts Matter 