To begin with, I don’t see any real reason why software medical device manufacturers should fear Agile. I do, however, see some stipulations that need to be made. Here is a rather dated article on the subject (from 2007) : Agile Development in an FDA Regulated Setting. The author of the blog post concludes: It… Continue reading Is the Software Medical Device World Ready for Agile?
Category: Medical Device Software
Valuable Unit Tests in a Software Medical Device, Part 9
I thought I was done, but here is yet another good reason to incorporate complex function automated testing: Validation of multiple Java runtime environments. Fabrizio Giudici proposes this as a solution for testing with Java 7, but we can always take it a step further, verifying multiple OS environments as well. Of course, this requires… Continue reading Valuable Unit Tests in a Software Medical Device, Part 9
The V-Model Approach: Just a Fancy Waterfall
I read this article at MEDS Magazine about Strkyer’s software development process. Stryker is a large and very successful company, so I was a bit surprised to learn that they have had success with the V-Model in software development. In my humble opinion, the V-Model is simply a glorified waterfall model approach, and we’ve seen… Continue reading The V-Model Approach: Just a Fancy Waterfall
Continuous Integration on Software Medical Device Projects, Part 9
Using a CI Environment to Replace the Traditional DHF Naturally, an important part of continuous integration is having a CI build that can be checked regularly for continued build success. This is probably what is commonly though of as the key benefit, but there is much more to be gained. Any continuous integration environment that… Continue reading Continuous Integration on Software Medical Device Projects, Part 9
Continuous Integration on Software Medical Device Projects, Part 8
Build Script Creation Ant should automatically determine which files will be affected by the next build. Programmers should not have to figure this out manually. While we will use an IDE for most development, we must not rely on the build scripts that are generated by the IDE. There are a few reasons for this:… Continue reading Continuous Integration on Software Medical Device Projects, Part 8
Continuous Integration on Software Medical Device Projects, Part 7
Build Labelling A build is labeled with a predetermined version number (e.g., “2.0”) and with a Subversion changeset number. The beauty of this is that we have a build that is associated with a particular changeset and, by association, an entire set of project documents and sources (as long as we put everything in a… Continue reading Continuous Integration on Software Medical Device Projects, Part 7
Continuous Integration on Software Medical Device Projects, Part 6
Build Scheduling Jenkins-CI allows teams to set up a project so that a build is performed whenever a change is committed through a version control system. The “Poll Version Control System” option is selected to do this. From there, the team must set up a schedule so that Jenkins will know how often to poll… Continue reading Continuous Integration on Software Medical Device Projects, Part 6
Continuous Integration on Software Medical Device Projects, Part 5
What I am proposing in this article is something that I, personally, have never done. In my positions as a software lead, architect, developer and software quality analyst, I have worked only with a DHF as a particular folder with specific subsets of documentation within. This approach has always resulted in a documentation nightmare. I’ve… Continue reading Continuous Integration on Software Medical Device Projects, Part 5
Continuous Integration on Software Medical Device Projects, Part 4
21 CFR Part 820 – DHF Requirements 820.30(e) Design History File (DHF) means a compilation of records which describes the design history of a finished device. –Device Advice: Regulation and Guidance, Software Validation Guidelines, http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance Medical device software is audited and controlled by standards defined by FDA, specifically 21 CFR parts 11 and 820. Many… Continue reading Continuous Integration on Software Medical Device Projects, Part 4
Continuous Integration on Software Medical Device Projects, Part 3
Jenkins CI For the purposes of this article, the focus will be on one specific continuous integration build tool, Jenkins CI. This is one of the more popular (open source) tools available. Jenkins CI (the continuation of a product formerly called Hudson) allows continuous integration builds in the following ways: 1. It integrates with popular… Continue reading Continuous Integration on Software Medical Device Projects, Part 3
Continuous Integration on Software Medical Device Projects, Part 2
Continuous Integration refers to both the continuous compiling and building of a project tree and the continuous testing, releasing and quality control. This means that throughout the project, at every stage, the development team will have a build available with at least partial documentation and testing included. The CI Build is used to perform certain… Continue reading Continuous Integration on Software Medical Device Projects, Part 2
Continuous Integration on Software Medical Device Projects, Part 1
I’m currently working on an article about continuous integration on software medical device projects, and how the CI environment can actually be used to solve many of the design and tracing requirements that must be dealt with on such a project. I’m not finished, but I wanted to post a little bit here. Here goes.… Continue reading Continuous Integration on Software Medical Device Projects, Part 1
What is a Software Medical Device?
When writing software for medical purposes, that software may or may not be subject to FDA scrutiny. We may or may not be required to submit for a 510k. What does this mean? How do we know? Its all a little confusing. As I considered a series of articles on the subject, I wanted to… Continue reading What is a Software Medical Device?
Valuable Unit Tests in a Software Medical Device, Part 8
The Traceability Matrix A critical factor in making unit tests usable in an auditable manner is incorporating them into the traceability matrix. As with any test, requirements, design elements and hazards must be traced to one another through use of the traceability matrix. The project team must document traceability of requirements through specification and testing… Continue reading Valuable Unit Tests in a Software Medical Device, Part 8
Valuable Unit Tests in a Software Medical Device, Part 7
Regulated Environment Needs Per 21 CFR Part 820 (Subpart C—Design Controls): (f) Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the… Continue reading Valuable Unit Tests in a Software Medical Device, Part 7
Valuable Unit Tests in a Software Medical Device, Part 6
Many of the benefits of functional unit testing listed above are gained only when unit tests are written alongside design and development (test-driven methodologies aside). It is imperative that the development team develop and observe test results while design and activities take place. This is of benefit to the quality assurance team as well, as… Continue reading Valuable Unit Tests in a Software Medical Device, Part 6
Valuable Unit Tests in a Software Medical Device, Part 5
What is the value of unit testing? Immediate Feedback within Continuous Integration: Developer Confidence Too often we view testing as an activity that occurs only at specific times during software development. At worst, software testing takes place upon completion of development (which is when it is learned that development is nowhere near complete). In other… Continue reading Valuable Unit Tests in a Software Medical Device, Part 5
Valuable Unit Tests in a Software Medical Device, Part 4
“The hardware system, software program, and general quality assurance system controls discussed below are essential in the automated manufacture of medical devices. The systematic validation of software and associated equipment will assure compliance with the QS regulation; and reduce confusion, increase employee morale, reduce costs, and improve quality. Further, proper validation will smooth the integration… Continue reading Valuable Unit Tests in a Software Medical Device, Part 4
Valuable Unit Tests in a Software Medical Device, Part 3
Automating Functional Tests Using Unit Test Framework Most software projects, especially in any kind of Agile environment, undergo frequent changes and refactoring. If the traditional single-flow waterfall model worked, recorded test scripts such as those noted previously would probable work just fine as well, albeit with little benefit. But it should be well known by… Continue reading Valuable Unit Tests in a Software Medical Device, Part 3
Valuable Unit Tests in a Software Medical Device, Part 2
While I personally have never been a fan of test-driven development (I feel that the assumptions required by test-driven development do not allow for a true iterative approach), I do believe that creation of unit tests in parallel with development leads to much more quality software. In the world of Agile, this means that no… Continue reading Valuable Unit Tests in a Software Medical Device, Part 2
Valuable Unit Tests in a Software Medical Device, Part 1
In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. In object-oriented programming a unit is usually a… Continue reading Valuable Unit Tests in a Software Medical Device, Part 1
Agile for Medical Devices
Good article over at MED Magazine about Agile Development for software medical devices. I’d like to expand on this is bit… [MED Magazine: Agile Software Development Streamlines FDA-Regulated Applications]
Published!
My first real publication! Very excited! [MDDI Online: Best Practices for Design and Development of Software Medical Devices]
Use a Single Version Control System for Everything
Every single artifact related to the creation of your software should be under version control. Developers should use it for source code, of course, but also for tests, database scripts, build and deployment scripts, documentation, libraries and configuration files for your application, your compiler and collection of tools, and so on—so that a new member… Continue reading Use a Single Version Control System for Everything
Handling Development in a Medical Device World (Part 8)
CONTINUOUS INTEGRATION BUILDS To answer the first question, before it is even asked: Yes, a software project should have continuous integration (CI) builds. This goes for projects with a large team as well as projects with a small team. While the CI build is very useful for a large group to collaborate there is tremendous… Continue reading Handling Development in a Medical Device World (Part 8)
Handling Development in a Medical Device World (Part 7)
USE THE ISSUE TRACKING SYSTEM FOR ALL PROJECT DESIGN AND DEVELOPMENT I propose that it is not enough to simply leave functional requirements in the software requirements specification document. This does not provide sufficient tracing, nor does it provide a clear path from idea to functional code. Here are the steps that I suggest: All… Continue reading Handling Development in a Medical Device World (Part 7)
Handling Development in a Medical Device World (Part 5)
RELEASING SOFTWARE When software is released it is typically given some kind of version number (e.g., 1.0). This is good, but it doesn’t tell us the specifics of what went into that build. It’s a good idea to include the Subversion changeset number somewhere in the release so that we always know EXACTLY what went… Continue reading Handling Development in a Medical Device World (Part 5)
Handling Development in a Medical Device World (Part 4)
VERSION CONTROL The earliest phase of any software project is the planning phase. At this stage, people involved with the project have meetings and discuss some very high level needs. There are probably some presentations and documents that are created. Project management plans have not been developed, but they should be thought about. And as… Continue reading Handling Development in a Medical Device World (Part 4)
Handling Development in a Medical Device World (Part 3)
ONE APPROACH After that long introduction, my desire is to write about one approach to handling design and development activities of a software project. This is an approach that works well for any software project, not just one in which a 510K is being pursued. Given the fact that the biggest needs are for good… Continue reading Handling Development in a Medical Device World (Part 3)
Handling Development in a Medical Device World (Part 2)
WHAT WENT WRONG? So what went wrong during this audit? The obvious and most simple answer is that I wasn’t prepared. Yet, even as I reflect, to this day I’m not entirely sure what the auditor wanted to know. The project manager was irritated with me for not understanding the questioning, yes, but what was… Continue reading Handling Development in a Medical Device World (Part 2)
MTR 