George Amana is a senior system analyst/programmer for Tower Lawn and Garden, Inc. Tower is a distribution center for lawn and garden equipment in northern Louisiana.

George: just sat down to lunch in the company cafeteria.

Pete: Wilcox, the IT Director in the firm, joins him.

Pete: Hey, George, you look pretty frustrated. What's the problem?

George: I had to take over the sales information systems project that Judy left behind when she quit. It's total chaos. I was told that it was all but finished. Come to find out, she didn't finish several of the programs.

Pete: She did a good job of specifying all of the software requirements, right? What's so tough about finishing the programs? Judy always preached about the benefits of structured development. In fact, she taught me how to do it. Don't tell me she doesn't practice what she preaches.

George: Yes, the software requirements are well documented, and the code is structured. It's just that the programs seem so poorly designed. Some of her subroutines are so long and complex that it's difficult to get a grasp on small enough pieces to test them for correctness. It seems like an all-or-nothing proposition. If I encounter a bug, I have to test large sections of code to zero in on the problem. Sometimes the bug turns out to be in an entirely different subroutine!

Pete: Why didn't Judy break the system into smaller pieces?

George: Oh, she did, but it almost seems like she generated the modules on the fly - as if to say, "Well, this piece of code is getting complex, I'd better put it in a module to finish it." She left me a rough draft of a structure chart, but I just don't understand the reasons she factored the system the way she did.

Pete: When I used to develop programs, I started by trying to draw a flowchart on a single page - sort of the high-level flowchart. Then I factor the more complex processes into more detailed processes that I implement as modules. It sounds like that may be what Judy did.

George: Maybe she did. But that strategy causes the lower-level modules to be very dependent on other routines. I frequently encounter bugs that get traced back to other, seemingly unrelated routines. I'm just getting further behind schedule. I may just have to rewrite the programs from scratch.

Pete: Why don't you get some help? Barbara just finished her project. Maybe she can help you. You could divide up the work and get it done faster.

George: Divide up the work? I'm not sure how, since Judy's program specifications are just one big unorganized document. I'm not sure which file and report specifications to match up to which modules. For that matter, I'm not sure the programs themselves are fully documented.

Pete: Well, I've been reading about some of the benefits of agile development. Since this project is in such a mess, what do you think about using it as the first project to see if agile programming methods would work for us?

Based on the concepts and techniques discussed in Chapter 11 (Managing Systems Implementation): 5 a. (5) Answer Pete's question by outlining the pros and cons of switching to agile methods to complete the software development. b. (5) What would you recommend to Pete and provide rationale? c. (5) Regardless of the software development methodology used, how should the program modules be conceived?