Does Staff Expertise Affect Software Quality?

Software Quality

Many years ago, Capers Jones, the software metrics guru, analyzed his database of thousands of software projects for the key factors affecting “real” software quality.  “Real” software quality relates to how the software actually performed and how robust in the field.   His list in priority order was:

  1. Programmer Application (domain) Experience
  2. Programmer Technical Experience
  3. Reuse
  4. Structured Methods
  5. Stable Requirements
  6. Private Office Space
  7. Careful Reviews / Inspections
  8. Experienced Management
  9. Realistic Schedule Targets

Can we learn from his research?  Does this fit current models of development and field quality?  Do modern development and test tools affect “real” software quality?

One clear takeaway in my view is the value of training software development and test staff.  While our process may expect system engineers and safety engineers to create solid and correct inputs to software development, you just cannot duplicate the value of a software developer having domain experience.  Their ability to question, constructively criticize, and otherwise scrutinize the requirements, design, and performance of the software early during development is irreplaceable.  Clearly the company that has software developers with domain experience will produce higher quality and likely safer software than the company that does not.

So how does one obtain domain expertise if they do not have it when you hire them?  Get them into the field!  Allow software developers to spend time in customer service and complaint handling roles.  Create realistic user environments onsite and have the software developers perform user roles in simulated circumstances.  Ensure that the software developers participate in product level and system level risk analysis so that they understand and have a healthy concern for how the device can hurt people or the environment.  For perspective, read Nancy Leveson’s excellent analysis of the Therac-25 accident.

Why are requirements so important?  Could it be that “working software” cannot tell us everything about the software?  Requirements provide a natural language description of the what we expect the software to do.  For efficiency, perhaps we do not require as much description of the software where its behavior is obvious and clear from use.  But certainly behaviors related to safety and essential functionality should be “agreed upon” in natural language.  Read our post on a checklist of quality attributes for requirements.

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:  TBD

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

Registration Link:

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 (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now

 


 

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
Partners located in the US (CA, FL, MA, MN, TX) and Canada.