11
Nov
2022

Thoughts on Metrics

, , , ,
0
Just a few thoughts on metrics … specifically software metric.  A software metric defines a standard way of measuring some attribute of the software development process or an attribute of a software component. A software metric allows us to compare and evaluate one process or component with another, and plan to improve quality of a component or improve efficiency of a process.  For example, you might ask, “what design verification activities most effectively identify software defects for my software system?”  What would you do or where would you go to answer that question?

Data Driven Process

I would suggest that you would want to have data to support your answer, whatever that answer might be.  Ideally, your data would span the entire software development lifecycle for your software system.  We need to know where and how the defect got into the software.  For example, the defect could be a missing or poorly communicated “system requirement,” and unrelated to the software coding at all.  In fact, IEC 62304 identifies three sources for software defects:
  1. Missing or poorly communicated system requirement
  2. Missing or poorly communicated software requirement or software design specification
  3. Software coding error
We might expand #3 to include:
  • Error in custom authored software, open source software or other acquired software
  • Improper use or interface with open source software or other acquired software

Using this information for example, we can address the process by which system requirements are elicited and generated from the Design Input.  It could be that the problem might be addressed with earlier review and evaluation of system requirements, or involving subject matter experts to breakdown the medical impact at a system level so that the variability from software can be critically reviewed earlier.  Certainly defects in software requirements and/or design should cause us to analyze how software requirements are generated or design is actually done (if at all) and reviewed.  Coding defects may lead to changes in coding standards.

Another useful metric is when and where was the defect found in the lifecycle?  This can help us consider methods and processes to find and eliminate defects easier in the process.  A defect found early in the lifecycle is a “gift” – it is a good thing.  Celebrate it. That is the goal.

Obviously, taking the time to properly categorize defects can provide great benefits for quality improvement. However, often I hear, “we don’t have time to properly investigate root causes.” Wisdom suggests otherwise … I advise to listen to her.
About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  June 5-7, 2024
Boston, MA

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

Register Now

 

Risk Management (Public or Private)

Our newly updated ISO 14971:2019 Medical Device Risk Management, A Software Organization’s Perspective training course is now open for scheduling!

  • Coverage of ISO 14971:2019, IEC 62304; amd1, and IEC/TR 80002-1.
  • System level hazards analysis – mapping to software, cybersecurity, and usability
  • Why FMEA is incomplete for medical device risk management.
  • How to perform software hazards analysis.
  • And more!

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructors: Dr. Peter Rech, Brian Pate

Next public offering:  TBD

 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering:  TBD

 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
office@softwarecpr.com
Partners located in the US (CA, FL, MA, MN, TX) and Canada.