For those seeking
Software and Design Quality -
QSAGE
Understanding the nature of quality
Edie Hovermale, founder of QSage has extensive experience in software quality.
She has established, grown and managed a variety of teams and organizations comprised of software development, quality and release engineers, managers, and documentation contributors, including several off-shore teams. She has worked to release database software, application development tools, e-commerce web applications, web server add-ons, biological pathways analysis web tool, mobile app platform, DNA variant analysis tool, patient care software, mobile app health monitor, several in-house tools and a QMS tool chain.
Edie has extensive experience directing software quality assurance organizations through coaching, planning, organizational development, staffing, forecasting, metrics, and by representing the quality disciplines and organizations.
“Through my years of experience I have taken part in many software product releases. The releases that ran smoothly had things in common; the team members understood that quality is a shared goal achieved through, controlling systems, implementing & following best practices, assessing & mitigating risk, and clearly understanding the goal of the testing efforts is to find and fix defects early.”
- Edie
Implement Controls and Best Practices for Quality Software
Quality comes from all supporting systems not just testing. Your quality strategy is a team effort and should be part of the development, testing, deployed environments, and customer engagements. Quality efforts can be compared to a smooth running car, if one mechanism is not running well it will effect the whole ride. Working together to identify, implement and refine best practices and controlled systems can create a well run, repeatable, quality release.
Goal of Testing - FIND AND FIX DEFECTS EARLY
The goal of testing is to find defects and to fix them early. Working towards implementing ‘defect finding structures and activities’ supports the quality efforts. These structures and activites include:
Understanding product domain and goals
Identifying tests
Identifying weak areas and prioritizing areas of risk
Ensuring test types are considered
Assessing usability & user experience and being a customer advocate
Identifying and understanding code dependencies
Implementing a test repository
Creating and maintaining test data
Automating regression tests
Execute tests early and often
Reviewing code
Understanding code changes
Controling test environments
Cleary reporting defects
Failure Mode and Effects Analysis - FMEA
FMEAs help us identify, understand and focus on the impact of potential risks for:
Systems
Designs
Processes
Services
Software
Manufacturing
An FMEA results in a prioritized list of risks, effects and controls. If a risk calculation is too high a mitigation action should be taken and the risk reassessed. The FMEA is a living document that should be updated and re-evaluated with each design / process change.
An FMEA is used as the basis for Control Plans which is a summary of proactive defect prevention, reactive detection techniques, and a well-thought out Reaction Plan if a failure does occur.
The FMEA, Control Plans, and Reaction Plan should be well understood by the cross functional team for a fast reaction if a failure occurs.
DESIGN CONTROL
“In many regulated programs the Design Control work is a separate, disconnected effort apart from the actual Development work. This separation causes duplicate work and missed opportunity to inform the quality efforts of the products.
How can companies integrate these efforts? Find the ‘Union of Common Work’. The ‘Union of Common Work’ refers to all documentation work required to develop a product intersected with all documentation required for supporting a product in a regulated environment.
Often documentation is created by the discipline experts for Development purposes. If the Development documents have to be re-written or modified to fit into the regulator requirements for inclusion into your QMS, the additional effort is time wasted. Training, coaching, and supporting those Development personnel to understand the Design Quality requirements can help them write the documentation in a way that can be used for both development and design purposes. Tool integration is another important element to help keep the design deliverables in the systems of work which can encourage ‘write once’, ‘use for many purposes’.”
- Edie
ISO 13485:2016
ISO 13485:2016 is an international standard used by organizations of all sizes involved in one or more stages of the life-cycle of a medical device, related services and associated activities.
ISO 13485:2016 specifies requirements for a quality management system where an organization demonstrates its ability to meet customer and applicable regulatory requirements.
The processes required by the standard are the responsibility of the organization whether or not the organization performs the processes and are accounted for in the organization's quality management system by monitoring, maintaining, and controlling the processes.
Regulatory requirements allow for exclusions of design and development controls, if these exclusions can be justification from the quality management system through alternative approaches and/or documentation.
The quality management system guides the organization in achieving quality objectives, continuous improvement, and customer satisfaction by including elements such as objectives, document management processes, and data management policies.