Welcome to this IBM Rational podcast, Continuous Integration for Agile Embedded Software. Development. I'm Kimberly Gist with IBM.

Transcription

1 IBM Podcast [ MUSIC ] GIST: Welcome to this IBM Rational podcast, Continuous Integration for Agile Embedded Software Development. I'm Kimberly Gist with IBM. Software teams have increasingly benefited from Agile development methods in recent years. They have adopted practices based on iterative and incremental development where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Today Martin Bakal, Worldwide Offering Manager, Electronics Industry for IBM Rational Software; and, Jennifer Althouse, Systems Sales Leader, Electronics Industry for IBM Rational software join us on the podcast to show how continuous integration can be employed in the context of embedded software development to improve a business's bottom line. Martin and Jennifer, welcome to the podcast today. ALTHOUSE: Thanks. BAKAL: Thank you very much. GIST: Martin, why don't you take our first question, which is, what do you mean by continuous integration for -1-

2 Agile embedded software development? BAKAL: Sure. So, continuous integration is a process that's part of Agile in general that some people use in Agile. What it really is is a process that allows you to sort of always integrate each of the pieces that you do whenever you do a check in and then have the different tests occur afterwards in different pieces like that. When we talk about embedded development, we're talking about development where something goes inside of an actual device and actually gets embedded inside of it. And the difficulty there for doing Agile has been a number of different things which we'll discuss further on, but primarily you can't get access to the hardware that easy to actually do some of the tests which it calls for testing all the time in Agile. It's not like sitting on a PC and just testing that device. So, continuous integration means whenever you bring the integration in, then you can sort of farm it out to the correct piece of hardware which might be back in a lab somewhere. And that way, multiple users can all be sort of doing the tests kind of offsite as they do it whoever they integrate different parts in. That's why continuous integration is actually important, to allow embedded developers to actually -2-

3 be agile. ALTHOUSE: Right. To build on what Marty was just saying, the whole value to the business of doing continuous integration is that you get constant feedback on the quality of the product you're developing. And it was kind of started over on the IT side of the house where people were building applications that were meant for the Web or meant to be posted on servers, but now that we're seeing the time to market pressures increase in embedded software development we're seeing it jump over into that area. And as Marty was mentioning, it's difficult to make sure that an entire system comes together when you have pieces that are hardware components, you have pieces that are software components. So it adds a certain complexity over a traditional IT continuous integration circuit where you have to make sure that you test the software you're creating, but you also have to make sure you test it in context with that hardware. GIST: That was a great definition. Jennifer, why do software teams need to adopt Agile development methods? -3-

4 ALTHOUSE: Well, Agile development methods help teams do a few things: one is to make sure that they can handle change. So as we've moved into an area where embedded software is having a very short time to market requirement, they have needed to kind of compress the entire development cycle down. And traditionally embedded development had a much longer cycle. They could afford to do a lot of this testing at the end. They could afford to write all the requirements at the beginning. And they could afford to in the middle do all of that development work and still meet those requirements. So what's happened is you compress that. You're having to get things out the door faster. Well, one of the ways to take cycle time out of a development effort is to not leave all that testing risk to the end and try to test your quality in, but to try to make sure that you're doing a constant cycle of testing. And that's the basic idea of what Agile development is, doing smaller chunks of development, breaking things down into kind of predictable smaller bites. But then also making sure that at the end of that development cycle you have a fully working and testing and validated piece of software. -4-

5 And so, again, it's that market condition that has changed. And that's what's requiring folks to get things done faster, and to get things done faster you need to take out any and all waste. And getting that testing early and often reduces the risk and squeezes out that extra waste in the development cycle. BAKAL: Another part to it is actually customer feedback is a very important piece. And Agile is very good because not only does it -- just like Jennifer mentioned, it actually allows you to basically get the feedback quicker because you're actually testing and then, here's a buildable entity. Let me show it to a customer or let me show it to my marketing group and say, is this what you mean? And then you can kind of develop the next part and go from there. So as we're getting much more responsive to customer needs in all industries, we're trying to develop things that they really want rather than things that they think they might want. The question really becomes, how do we do that? And so, for us, in many cases the importance there is really to understand what the customers want, show them a working prototype, give them feedback, allow them to get feedback really quickly, and then respond to that and develop it differently if need be. -5-

6 So I agree with Jennifer, it's to get it out quicker; it's also to get that feedback even if the product will take a while but come out the final product. If it's a medical device and it has to go through FDA requirements and stuff, you can still get earlier feedback and understand the customer needs ahead of time. GIST: Great. Well, then Marty, why don't you take this question: how can Agile practices apply to systems' development projects? BAKAL: Okay. So, I guess first we define what systems development projects are. When we say systems development projects we mean sort of embedded devices built into an overall entire system. It could be building a medical device. It could be building an airplane or something along those lines. And traditionally, Agile has been slower adoption in these industries because they're regulated and people want to have a plan in place. This is the whole plan we're going to do all the way through. But what they've started to see over the years is they really need to do more than that. They really need exactly what Agile's providing: better feedback from customers, testing earlier and often, and all those pieces. The hard -6-

7 part is that if they have a plan they have to be able to meet that plan, the customer signed off on those requirements, it has to be regulated. That's where things like continuous integration help keep them on that path, keep testing, and they can show that the thing is working correctly. They can map it to the actual requirements. They can show what they're actually doing so they actually have something that has traceability across the whole life cycle. That's the part that's so important, whether you're talking about aerospace and defense, medical, building mobile phones, building automobiles. All these different types of things you do in sort of a systems marketplace you have to have complete traceability across that. And the way to do that is to somehow automate some of that grudge work, make sure the traces all occur, and make sure you know from requirements through your design, through your testing, that everything actually fits correctly. And that can work fine in Agile, it just takes having that plan and understanding it and then being able to adjust to change as you go through it. ALTHOUSE: Marty, that was great. I don't have anything to add. -7-

8 GIST: Well, I see that testing and feedback are definitely consistent things throughout this topic of discussion. Jennifer, how does embedded software development discipline differ from IT application development? ALTHOUSE: It differs in a few different ways. One difference is that IT development is typically done with a very standard platform. So all of the IT development is going to look and feel somewhat similar in that it's interfaced with a machine where there's a monitor and you have that computer to talk to or to interface with. In embedded system development, you are typically scaling everything down to kind of very small processors. Right? So you don't have as much space. You don't have as much wiggle room to have extra memory used or to have extra cycles in what you're producing. The other thing is that often we are more tolerant of errors in IT development. So if the machine, your computer, has to be rebooted once a week, you find that to be completely acceptable. Even if it has to be rebooted every night, people are tolerant of that level of reboot. But as soon as we're talking about maybe your telephone or -8-

9 your automobile or some of the other more embedded medical devices, the idea of that having problems that would cause it to be rebooted once a day would be completely intolerable. Right? So no one wants to have to turn their car on and off periodically for everything to work right - -even though on the IT side that level of defect rate is acceptable. The other big difference is that as we start to talk about embedded development, a lot of times we're talking about something that does have some safety critical nature to it, like an automobile or a medical device, and again anything with a safety critical nature has this elevated level of testing because certainly you don't want your automobile to fail and cause harm to yourself or other people. So if you look at just those two factors: the factor of safety critical, the factor of kind of tolerance for a defect rate, the embedded software development has less tolerance for defects. And that's what's so nice about Agile development and this cyclic development being brought into the embedded development area is that it allows you to get that more constant feedback. It allows you to reduce your risk and reduce your defect rate earlier in your cycle of development so that over time you don't have these things coming out in the field in -9-

10 actual usage. And kind of back to the other part where I talked about the fact that you are often limited, you are limited in your ability to have memory for those devices, limited in the ability to have processor power. It also gives you more chance to vet out the architecture and vet out the way that your application runs and cycles, and also to make sure that that is running as efficiently as possible. So each time you go through a testing cycle you have the ability to get rid of some of what they call your architectural debt. So anything that you built up, anything that you got out the door but you didn't get out the door as efficiently as possibility so that it had room for improvement. Every cycle you get through Agile you get that chance to fix it or make it better, whereas with traditional waterfall development, everything's pushed to the end. You didn't have as many times or as many chances to kind of remove that extra excess. BAKAL: Jennifer, I thought that was a great answer. I think you covered most of what I wanted to say. I guess the only other thing I'd add is when you talked about regulated devices, one of the pains or advantages there is that it has -10-

11 to go through a regulatory process. It's going to take a longer period of time before you actually release and give it to customers. You don't want a heart pump to not be tested and qualified by the FDA and make sure everything works correctly at the end of the process. And that's very different than a lot of the software we see now in IT systems where they sort of...some company put something up on a Web site and just hopes that it all actually works. And if it doesn't, well, fine. They can replace it very easily. I once worked in a company that did a sub pump that inside the sewer system was measuring data on the sewer system itself. Nobody wants to go back in there and replace that. Now maybe they could do a software update on the fly. But if they really had to patch some things like the issue with how it did the software update on the OS or something else, then it'd be a real pain to have to go in and go get those living out of the sewer systems. A very expensive operation. So there are a lot of different types of things like that where updating it is much, much harder in embedded systems, and that makes it different than IT. -11-

12 GIST: Well, we've given a definition, we've looked at adoption, talked about the importance of feedback and obviously identified some of the discipline differences. So for our last question, what would you say are the benefits of using continuous integration for Agile embedded software development? Why don't we start with you, Marty? BAKAL: I think deep integration has benefits across all different types of Agile development because in general you're integrating into the strain quite regularly. But when we talk about Agile development, a lot of these Agile development projects tend to be very critical, but they also tend to be very large and have multiple teams working together. So you want to make sure you integrate things regularly. The advantage of continuous integration is to build a process in place where you actually can bring something into the stream much more quickly. Every day you're sort of putting something in there, having it testing, making sure it works so people don't kind of hang on to their code for a long period of time, which then breaks everyone else in the system's parts. We are dealing with a large group of people all working together to make sure it all works. That's very important. Another part of it is when you're doing testing in the lab -12-

13 you actually want to actually have the builds work in a kind of automated fashion. So you release it, you build it, you make sure it all works correctly. Now it gets scheduled automatically to be tested in lab on the different devices that you're working there. That's something that embedded people really need. People working on IT apps can test it on their computer because it's the same thing as the final device is going to be on in many cases. They have direct access to the hardware that's going to be the final system. But embedded, you don't have that type of direct access, which means you need to use a process like continuous integration in order to have it scheduled and to have the testing scheduled as part of what you're doing. GIST: Jennifer? ALTHOUSE: Sure. So with continuous integration, I mean, the idea being that you test early and often -- so, as soon as you finish testing, you test everything again. What that allows you to do is create an environment where little bugs don't grow into big bugs. Big bugs are exponentially harder to debug than little bugs. So it makes it so that you have this constant chance to -13-

14 catch the little bugs before they have a chance to grow up. And anyone who's done debugging of any kind of software, be it embedded or IT software development, they know that this kind of small thing that you just put in before it has a chance to compound and have other people's bugs on top, it's just infinitely easier. So again, it's all back to efficiency and making sure that you're not wasting any cycles in your develop time. And as requests for products coming out to market faster, as those become faster and faster cycles, I think this is just one more way for a business to reduce its overall test process. GIST: Thank you, Martin and Jennifer. A very interesting review on continuous integration with Agile. We sincerely appreciate you both sharing your time and expertise with us today. That was Martin Bakal, Worldwide Offering Manager, Electronic Industry for IBM Rational Software; and, Jennifer Althouse, Systems Sales Leader, Electronics Industry for IBM Rational, with a great overview of our topic: Continuous Integration for Agile Embedded Software Development. To hear this specific podcast or to browse additional topics check out our Rational Talks to You podcast page at This has been an IBM -14-

15 podcast. I'm your moderator Kimberly Gist. Thank you for listening, and we hope that you will choose to keep tuning in as Rational Talks to You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -15-