Case: a whole new ball game - computer-aided software engineering - Technology Transfer - Column

Software Magazine, Dec, 1993 by Doreen Evans

This past October I attended Case World in Boston. As I looked at the array of computer-aided software engineering (Case) tools available, I was struck by the incredible value they can add to the sofware development process. So why isn't everyone singing their praises?

The problem is, there is an impediment to leveraging these tools. It is not a problem with the tools themselves --the problem lies with the firmsf buying these tools.

Most IS organizations have end users demanding more applications than ever before. IS managers are faced with an unending backlog for new applications at the same time that they must evaluate new technological solutions, handle budget decreases and introduce new tools. Developers are overworked maintaining essential applications, but are still being asked to learn new technologies.

These are the same problems companies have faced for most of the 25 years I have been in the business. But for most of those years the solution to improving productivity was technological: New mainframes faster than the one before, new DBMSs, new languages. Basically, firms automated manual processes they were familiar with, or speeded up work they knew how to do.

Many thought Case was one more productivity tool that fit into that model. Organizations purchased Case tools expecting to deliver better-designed applications in record time. Some even expected to see their application development backlogs disappear completely.

When I started developing courseware to train Case tool users nine years ago, I learned that the software engineering part of the Case acronym was missing for most. Just as a word processor cannot make a user write interesting articles, a tool will not make a good software engineer. Case has changed the rules. There is a whole new ball game being played out in today's IS world.

I recall when I was captain of my high school basketball team. At that time, the women's game involved six players -- three forwards on one side of the half-court line, and three guards on the other side. Each trio had to stay on its half of the court. And a player could only dribble three times before passing the ball.

Laster, when I was in college, the rules changed. The game became a full-court situation for all players. Players had to handle the ball, run the length of the court while dribbling, and shoot. Players had to decide whether they still wanted to play, and if so, how to learn the new skills.

Something similar has happened in software development. It is not just a matter of learning a new language; it is the process of developing software that must change. To be effective, IS professionals must understand the business, gain interpersonal skills such as team building and communication, and use engineering disciplines to model the requirements to communicate their understanding of the problem and the proposed solutions.

Managers have all heard that before. But it was not until Case tools came along that building models was really practical or worthwhile. Case has not just automated old tasks; it is allowing users to perform new tasks that were not part of the IS professional's technical training.

With Case, development has gone from an emphasis on coding and testing, to an emphasis on analysis and design. Both end users and IS need to learn how to communicate to understand the business problems, and then use technological solutions to provide quality service to their customers. IS professionals have a tremendous knowledge of the business, just as I knew a lot about basketball. Doesn't it make sense to use that legacy knowledge?

How would managers do that? What if a coach was charged with producing a winning team, but he or she had to work with my college team? If the coach had an unlimited budget, scholarships and time, perhaps the right skills could be found. But that would be difficult because few players know how to play this new game. In addition, the coach needs the players' loyalty and cannot risk bad press by cutting them from the team.

How will the coach teach the new skills, use each player's special knowledge, practice the plays and get everyone to work together? The team needs a rigorous, preseason work camp.

This strategy would have many components, such as lectures to teach the new rules, new strategies for plays, drills to learn the new skills in a controlled situation, and scrimmages to practice real-life situations.

That is what IS needs for a smooth transition from traditional ways of developing software to software engineering using automated tools.

If they can do that, their staff can become what I call "Case technologists." These people:

* Know how to define the problem to be solved.

* Understand team, rather than individual, roles. As Peter Senge from MIT, Cambridge, Mass., said, the IQ of a team can be much greater than the IQ of an individual. IS managers need to develop a group of people with all the skills to build quality software applications.