Design Article
Using agile methods in medical device development
Martin Bakal, IBM
10/9/2012 9:17 AM EDT
Page 3
Another question that is asked is how can I make an agile process work when targeting an embedded device? Since agile promotes developers to test their device frequently but in many cases there is limited hardware availability and it is in a lab that isn’t convenient to the developer working at his/her desk. There are a couple of ways to manage these issues. One is to use some sort of simulator of hardware itself. Many real-time operating systems offer simulators that work well. In addition, if you choose to model your design in a tool like Rational Rhapsody then it has the ability to run a simulation of your actual on your desktop to see how it executes.
While executing on host or simulator works in many cases it doesn’t work when you have to talk to specific hardware and or need to see the actual response of the hardware itself. In those cases an addition to agile called Continuous Integration (CI) helps. The concept is pretty simple. CI is the practice of frequently integrating one's new or changed code with the existing code repository. This should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.[4] As you build a story make sure you do frequent checkins and then build into your check-in process the ability to do a build of the device. The added complexity is to then have the configuration management environment schedule the tests to be run on the device since many times it is located in the lab. Automating your build process can make this much more seamless so integrations and testing occurs much more frequently. This way the build engine can work with a scheduler to manage access to at least some of the physical hardware so developers are not fighting for the scarce resource.
In conclusion, agile development works and is being used in medical device development. The issue is you need to have a good toolchain that allows for complete traceability across the entire lifecycle in order to comply with standards. It is also very important to integrate and test frequently. This, in turn, leads to the need for build automation. With all of this in place, agile development for medical devices becomes much easier to make work.
About the author:
Matin Bakal has over a decade of experience working in various capacities in the embedded systems and software industry with extensive customer experience worldwide in multiple industries including medical devices manufacturers and other embedded industries. He is currently the electronics industry lead at IBM Rational and in that role leads the initiative around medical device including leading the SME work around our overall medical device solution. He holds a BS in Electrical Engineering and a Master of Science degree in Engineering Management, both from Tufts University.
See related links:
Agile hardware development – nonsense or necessity?
Case study: Collaboration changes in agile workspaces
FPGAs for meeting size, reliability, security goals in medical devices
Another question that is asked is how can I make an agile process work when targeting an embedded device? Since agile promotes developers to test their device frequently but in many cases there is limited hardware availability and it is in a lab that isn’t convenient to the developer working at his/her desk. There are a couple of ways to manage these issues. One is to use some sort of simulator of hardware itself. Many real-time operating systems offer simulators that work well. In addition, if you choose to model your design in a tool like Rational Rhapsody then it has the ability to run a simulation of your actual on your desktop to see how it executes.
While executing on host or simulator works in many cases it doesn’t work when you have to talk to specific hardware and or need to see the actual response of the hardware itself. In those cases an addition to agile called Continuous Integration (CI) helps. The concept is pretty simple. CI is the practice of frequently integrating one's new or changed code with the existing code repository. This should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.[4] As you build a story make sure you do frequent checkins and then build into your check-in process the ability to do a build of the device. The added complexity is to then have the configuration management environment schedule the tests to be run on the device since many times it is located in the lab. Automating your build process can make this much more seamless so integrations and testing occurs much more frequently. This way the build engine can work with a scheduler to manage access to at least some of the physical hardware so developers are not fighting for the scarce resource.
In conclusion, agile development works and is being used in medical device development. The issue is you need to have a good toolchain that allows for complete traceability across the entire lifecycle in order to comply with standards. It is also very important to integrate and test frequently. This, in turn, leads to the need for build automation. With all of this in place, agile development for medical devices becomes much easier to make work.
About the author:
Matin Bakal has over a decade of experience working in various capacities in the embedded systems and software industry with extensive customer experience worldwide in multiple industries including medical devices manufacturers and other embedded industries. He is currently the electronics industry lead at IBM Rational and in that role leads the initiative around medical device including leading the SME work around our overall medical device solution. He holds a BS in Electrical Engineering and a Master of Science degree in Engineering Management, both from Tufts University.See related links:
Agile hardware development – nonsense or necessity?
Case study: Collaboration changes in agile workspaces
FPGAs for meeting size, reliability, security goals in medical devices
|
|
|
|
|
Navigate to related information