A Gradual Approach to CASE

by
Thomas Sears, Principal Staff Engineer, Motorola Paging Infrastructure Group
(Ghost written by Mark Haas)

CASE tools such as Software through Pictures can be tremendous aids in designing and developing software systems. But if not introduced into the production environment properly, any CASE tool can cause serious disruptions, including product delays, as engineers focus too much on process and not enough on results. After a disasterous initial attemp at introducing CASE into Motorola Paging Infrastructure, we found a more gradual, phased-in approach enabled us to realize the true benefits of CASE.

Beep, Beep

Every day, thousands of doctors, engineers, real estate agents and other mobile professionals use portable pagers, commonly referred to as "beepers," to maintain vital communication links with their business associates. Pagers have become so widespread in many areas, they're even being used by parents needing to track the whereabouts of their children and by couples expecting the delivery of a new baby. Without realizing it, all these people are relying on a sophisticated, computer-based communications infrastructure to relay their messages to the proper destination quickly and reliably.

Motorola is one of the world's leading manufacturers of this specialized equipment. Each system Motorola's Paging Infrastructure Group produces for paging service providers incorporates customized software, providing them with service enhancements to entice new subscribers. Motorola's modular systems approach provides it with a significant market advantage by enabling its customers to easily integrate the new equipment with existing radio transmitter base stations (one of the most expensive portions of the paging infrastructure). As a result of its ability to efficiently customize its products, Motorola has flourished in a highly competitive marketplace.

Motorola was faced with a considerable challenge during this period of rapid growth: managing the software development for its new and existing products. New product development was transforming what had been a single team of engineers into concurrent engineering groups developing related products in parallel.

In the past, software development was handled virtually on an ad hoc basis. A few engineers with the complete model of the system in their minds were able to direct a small group of engineers who basically sat down and began writing assembly code without performing any sort of structured analysis or design. But as the small, intimate group of engineers -- one that could easily communicate the details of a system's design amongst themselves -- grew rapidly from 8 people in 1989 to more than 40 people today, it soon became clear that the old ways were no longer adequate to keep up. A method to capture this model and disseminate it to others had to be found. This knowledge was too valuable to reside solely in the minds of a few key engineers.

Capturing the Concept

This was the situation I found when I first arrived in the Paging Infrastructure Group about a year ago. The rapid growth of the group was straining its ability to successfully develop new products quickly and effectively.

Looking down the road was even more frightening. With British Telecom now requiring us to have software documentation, and the impending ISO 9000 requirements for extensive documentation, I had to act fast to begin modeling the existing products, and establish a systematic approach for documenting new products. I turned to Software through Pictures because of its flexibility, ease of use and open data dictionary.

But while it was obvious to me that a graphical CASE tool would be ideal to capture and document these ideas, the Paging Infrastructure Group's past experience with such tools had left a bad taste. When the group had first tried to change over to newer methods, the group jumped in with both feet, and eyes closed. Although they were able to generate all the diagrams and so on, they had spent so much time trying to satisfy the rigid constraints of the CASE tool they were using then, that by the time the products were supposed to be available, all they had were bubble charts. Everyone panicked, immediately reverted back to doing things the old way (it had worked in the past, right?) and dropped the thought of ever using a CASE tool again.

And so my decision to introduce StP was met with some skepticism, not to mention outright resistance. But I had encountered this problem before in another part of Motorola. They, too, had tried to swing the pendulum too far, too quickly, essentially telling everyone to stop what they're doing, sit down and begin using a CASE tool. And this approach failed there for the same reason it had failed here: People were having to learn a tool at the same time they were trying to do development, and in the process, they no longer were really producing anything.

A Phased-In Approach

Software through Pictures allowed us to start using a CASE tool without all the pain the group had suffered attempting to use a CASE tool before. Because I had used StP before, I was able to take the existing code and from that generate a top-level model, a context diagram, in a week or two. This block diagram of the system had external input, a basic process block, and external output.

Then we agreed on a fundamental rule: Whenever the group changed any of the existing code, as when customizing the system and adding enhancements for a new customer, we'd also incorporate these changes into the model. One year later, we'd completed the entire model just by incorporating the changes we've made to satisfy new contracts.

By building the model piece by piece, starting at the top level and integrating as we went along, it became a natural part of the process. After a while, the process began to become intuitive, and the engineers started using StP not just to create documentation, but to troubleshoot as well. Now they are able to look at the system, understand how all the pieces work together and distinguish when they have system problems and when they have code problems. Before, the first thing they did was look at the code, but now the model has made them much more productive.

Now when we make modifications to the system, we have the model created using StP as a starting point, as when we wanted to add a modem. For the first time, the group first described the modem operation it wanted, and then generated specifications and requirements using Interleaf. Then, we looked at the top-level model I developed a year earlier, and clearly saw how the functions we wanted to add connected to the rest of the system.

Using the StP Data Flow Editor, one of our engineers created another top-level model for the modem section. Together, we kept pushing it down to the point where we were able to generate the P specs, resulting in a complete model of the modem operation and how it connected to the rest of the system. Then, the group decided to go ahead and generate structure charts for the modem, and was then able to generate approximate requirements specifications using the document preparation system.

Thus, for the first time, the group got to see a software requirement specification in a raw form coming from the graphics. We completed the process by filling in the remaining things required by the document preparation system, such as titles, and now the group was able take this documentation, graphically describe what they were going to do on the model, and build a proper requirement spec with annotations on it. For this group, it was revolutionary.

Getting the Work Done

The key to our successfully introducing Software through Pictures was making people understand they didn't have to do it perfectly the first time. Instead of worrying about mixing control flow with data flow, the idea was to capture their thoughts in a way that makes sense to them. After all, these diagrams are for use by people, not machines, and if what they're putting down makes sense to them, that's all that matters. While this may offend some CASE purists, I find it's far more important for people to be able to get their ideas down in any form rather than getting bogged down concentrating on precisely following the correct structured methodology.

Software through Pictures is particularly well-suited to this approach. StP is very tolerant of mistakes. When the group began using StP, they weren't intimidated by having to be perfect the first day out. Although most had several errors when generating the data dictionary, StP was flexible enough to just warn them of the errors. Instead of stopping, it completes building the model, completes the document preparation system, and generates an SRS.

People need to concentrate on the fact that they can do it, they can succeed. They start with baby steps, just the basics, get the ideas down by representing the data the best way they can so that it makes sense to them. Then after they get used to that, they can go back and refine it, learn more about how the methodology works at their own pace. It's an iterative process, just like software development itself. They begin with a core, look at it, test it, and then add the frills.

We even have some people that still use flow charts; have been for a long time. They're never going to change. And so all I ask them to do is use the picture editor in StP to generate their flow charts. StP, because of its open data dictionary, allows me to manipulate their data and make it part of the P specs. Now their work is part of the model, and they find this very satisfying. They feel they're part of the process.

Quality is the Bottom Line

While the phased-in approach requires effort and patience, the benefits far outweigh the costs. The number of defects at significant points in our development process have dropped significantly, from the specification phase to delivery to customers. Because each unit we ship is essentially a custom design, we used to spend a lot of time out in the field at a new installation. Now, in many cases, new equipment installed at the customer site works the first time. What's more, the time it takes us to generate the custom components has gone down significantly.

Another important benefit we've realized by using StP is the reduced time it takes to get new employees up to speed. When I got here, I was handed reams of code and told to look it over; the operation of the system was obvious. Today, because we have the models, I was able to hire a new graduate and get him up and running fairly quickly. Now he's writing some diagnostic software, and the models allow us to explain to him what's going on much better than they could explain it to me.

Most companies in the United States are rate a level 1 or 2 by the Software Engineering Institute (SEI). When I first arrived at the Paging Infrastructure Group, it was rated a zero minus. Today, we're rated a level, and we expect to be at level 2 by the end of the year. And I'm confident that with Software through Pictures we can reach a level 3.

Through our use of StP, we now have a better understanding of our system, we can create modifications of greater quality more quickly and have created a solid foundation for future versions. StP's ease of use, flexibility and open data dictionary have enabled us to employ a gradual phased-in approach to introducing CASE, and all the benefits associated with it.

# # #