JOBS | MY NEQC
HOME | SEMINARS | RESOURCE | MEMBER LEADER TRAINING | CONFERENCE | LEADERSHIP | CONTACT US
NEQC CONFERENCE THE 56TH NORTH EAST QUALITY CONFERENCE
 
minus  56th Conference



minus  55th Conference



minus  54th Conference

 
     

Back to Programs


Software Development in the FDA-Regulated World: Why Test Only When We're "Done"?

Brian Shoemaker, Principal Consultant
ShoeBar Associates
199 Needham St, Dedham, MA 02026
bshoemaker@shoebarassoc.com
Ron Morsicato, Managing Partner
Agile Rules
162 Marrett Rd., Lexington, MA 02421
ronm@agilerules.com


Serious accidents in the 1980’s forced the FDA to regard software as a hazard item in medical products. Where software is used in producing a medical product, as part of a medical device, or in managing data from a clinical trial, the FDA expects that software to be validated.

Regardless of development methodology, software validation involves the same tasks: capturing end-user requirements, recording a design, testing the pieces and the completed product, and tracing tests to requirements and design. In the FDA-regulated context, such as medical devices, objective evidence for these activities is documentation.

Development projects are often planned with testing at the end – so the test schedule is cut when other work takes longer than expected. An alternative to this “testing squeeze” turns the conventional order on its ear: specify, design, code, and test concurrently rather than in separate phases.

One concurrent engineering implementation links a communications tool, where users state the behavior they need, and an acceptance testing subsystem. The communications tool results in executable requirements, which are run as tests to demonstrate the capability of the software in its current state. An electronic signature tool can then capture unalterable copies of these tests.

Clearly, this approach demands advanced skills in defining executable requirements. The payoff is to increase the value of effort: validation becomes integral to development rather than a hurried afterthought, traceability is built in, and test documentation is automatic.

Presenter:

Brian Shoemaker, Ph.D.
Brian Shoemaker,has been responsible for validation of software in a variety of FDA-regulated settings, from the embedded applications driving immunodiagnostics instruments to custom applications for clinical-trial data management. He has also designed and instituted quality systems for software development, and carried out 21 CFR Part 11 assessments of various software packages. Currently Principal Consultant of ShoeBar Associates, he has served with CSS Informatics (earlier PPD Informatics), Doxis, Inc., Behring Diagnostics (previously PB Diagnostics; a manufacturer of clinical immunoassay systems), and Technician Instruments. Brian earned his Ph.D. in chemistry from the University of Illinois; he holds ASQ certification as a Software Quality Engineer.

Ron Morsicato
A veteran developer of safety-critical and regulated software, Ron Morsicato co-founded the Lexington, MA consulting firm Agile Rules in 2003. He has developed software in diverse areas such as pharmaceutical and agricultural spectroscopy, embedded control systems, alcoholism treatment information and delivery, system simulation, and military systems. He teaches and coaches embedded teams in test-first software development methodologies such as Test Driven Development, and is a member of the IEEE 1648 Working Group for Establishing and Managing Software Development Efforts Using Agile Methods. Ron holds an MS in Operations Research from SUNY Buffalo. His current interest is in the integration if both internal and external customer needs with a comprehensive testing program for embedded products.


 

Back to Programs