IntraPace software development manager Mace Volzing heads a team responsible for developing embedded software for abiliti -- a medical device implanted in obese patients to control hunger. How is developing software for this kind of device different from traditional software development? What methodology did they use and why? Site editor Yvette Francino asks these questions and more in the interview that follows. Read part 2.
SSQ: I looked at the IntraPace website and this abiliti device looks interesting. I want to hear more about doing software development on embedded software. Maybe you can start by telling us a little more about the abiliti device.
Mace Volzing: Okay. It’s an implantable device; it’s basically a pacemaker for the stomach, so what we’re able to do is sense when the patient is eating. We can also sense when they’re exercising or moving, so we use all that information to try to give [the users] the sensation of being full at the appropriate time. What we can do is we can effectively pace the stomach, give them the sensation of being full, and then try and curb their desire to eat. We’re trying to change their behaviors instead of changing their physiology. So we’re competing against lap-band or gastric bypass [surgery], and we believe our device is less invasive. It’s certainly not permanent; we can take it out. Yet, we’re in clinical trials to prove that we are just as effective.
SSQ: Can the device detect what’s being eaten? Healthy food vs. junk food?
Not yet. That would be the holy grail.
SSQ: Are there any dangers then that the person would not eat enough healthy food?
I don’t think we have that problem with out patients. Right now we’re only in the morbidly obese, so that means not a problem of enough calories going in. Monitoring and controlling the health of what they eat is something that we’re trying to attack through other avenues. An implanted device is only a piece of what we’re trying to do. In addition to that, we’re trying to add a social network site for our patients to interact, and to try and offer them information that would give them better dietary habits and exercise habits. And those are the two factors in controlling health and weight.
SSQ: Let’s talk about the difference in doing software development on embedded software vs. traditional software. Do you find that there are different needs you have in the application lifecycle management of embedded projects?
Not really. We use the same methodology throughout. On our Web-based development we do a little lighter control. But in terms of the medical device world, we’re pretty stringent on our requirements on and the process that we use for development. So I wouldn’t say that embedded is any different.
SSQ: Are there more regulations in this case because it’s a medical device?
Certainly. Part of our process is that we have to do risk analysis on everything we do. All of our software has to be driven by risk analysis. We have to decide which part of the software could potentially cause harm to a patient. So for an embedded device you certainly have to go through that process a lot deeper than you would say for a programmer, which is all external. Although you have risks in terms of when you develop a programmer, you have to make sure you don’t program parameters to a device that would allow it to cause harm to a patient. I would say what would happen is that there’s this other step that a lot of commercial products or non-medical device products don’t have to deal with and that is the risk analysis of everything you do. The traceability is what eventually the FDA comes and looks for.
SSQ: Another difference with embedded software is the ability to test. How can you test this device without actually putting it in someone?
Well, you test the requirements so you have to write requirements that are A) testable and B) that are truly going to give you what you need in terms of an end product. We set up automated testing here. We use a bunch of open source tools to do all of our automated testing. And what we try to do is we set things up so all the automated tests are traceable back to every single requirement and test case.
SSQ: So what kind of methodology do you use with software development?
We started off with waterfall and we recently pushed over to doing a Scrum style.
SSQ: Are you doing a hybrid or have you migrated?
The waterfall was done with the last firmware drive we did. We started Scrum when we started our Web development. So it will probably be a hybrid when we do our next round of firmware development. It works really well for the Web development because of its faster turnaround, and you can put everything on the table and pick out the three most important things and get those done. You can’t really do that when you’re doing firmware, but when you’re doing Web development, you can. It’s more of a style choice in terms of what the end product is.
SSQ: Was it the same engineers that did the Web and firmware development?
I have four engineers, so everyone helps on everything, but there were two different lead engineers.
SSQ: Do they have a preference between Scrum and waterfall?
Yes, so far I think Scrum has been the one they enjoy the most in terms of working style. And it integrates requirements and testing and development in a tighter cycle. You get better requirements and better testing out of it.
SSQ: So what are the reasons that Scrum wouldn’t be as much of an option for firmware development?
I think what I would end up doing next time is a hybrid where you try to get the framework of the requirements down to start with, but then work through a Scrum style, because I think what happens is if you write all the requirements up front, they’re going to change. You can’t do it because as you’re developing, you find stuff that needs to be done differently either for testing, safety reasons or because you can’t implement that. So if you do it in smaller chunks and testing follows, you tend to get code that’s better in terms of development, and it’s tested more thoroughly, which is very important.
SSQ: Right, that’s why people are switching to agile. What are the reasons you think you wouldn’t be able to 100% switch to Scrum?
I think when you have a closed system, you’re designing something like an implantable device that’s got a closed set of requirements you need to have a vision for all of those in terms of setting up an architecture before you start to implement. I look at Scrum as more of setting up process than a design process. But if you’re doing a website where you’re adding functionality, then Scrum works really well because you can pick and choose and put what you want in that.
SSQ: So there’s more flexibility with requirements?
In the medical device world the requirements are there, and they’re solid, and you know what they are, so you can put a framework of all of them down to start with. And then you can do a Scrum technology in terms of implementing it, but they’re still pretty much set. You’ve got a set of features that you have to have, and it doesn’t work unless they’re all there. Whereas with a website, if you do half of them, the website still works; you just don’t have half your functionality.