Page 358 - Introduction to Programming with Java: A Problem Solving Approach

324 Chapter 8 Software Engineering 8.9 Iterative Enhancement
Often, you have to start working on a problem in order to understand how to solve the problem. That leads to a design process that is often iterative in nature. In the first iteration, you implement a bare-bones solution to the problem. In the next iteration, you add features and implement an improved solution. You continue adding features and repeating the design process until you have implemented a solution that does everything you need. This repetitive process is called iterative enhancement.
Prototyping—An Optional First Step
A prototype is a very “thin” or “bare-bones” implementation or perhaps just a faked “simulation” of a pro- spective program. Because of a prototype’s limited scope, developers can produce prototypes relatively quickly and present them to customers very early in the development process.
Make sure you are solving the right problem.
A prototype helps end users get an early feel for what it will be like to use the program—well before the program is finished. It helps clients provide early feedback that improves the quality of product specification. Thus, prototyping provides a valuable adjunct to the first part of the top-down design process, and it complements early work in a bottom-
up design process. Without a prototype, there’s always a risk that you’ll solve the wrong problem. Even if you solve the problem with great elegance, if it’s the wrong problem, the whole effort is a waste of time.
There are two basic ways to generate a prototype. One way is to write a very limited version of the final
program in Java. Since a prototype should be relatively simple, you could use whatever design approach
seemed easiest. The other way is to use a computer application that provides nice presentations to simulate
the final program’s user interface for particular “canned” data or a narrow range of user inputs.
Apago PDF Enhancer
Prototyping can be a valuable communication tool, but use it with caution. Suppose you create a pro- totype, show it to the client, and the client says: “I like it. Give me a copy so I can start using it tomorrow!” Don’t do it! If your prototype is an early iteration of an orderly sequence of planned iterations, fold in what you learn from client reaction, and proceed to the next iteration as originally planned. If your prototype is just a visual presentation pasted together from disparate components, resist the temptation to expand that prototype into a finished product. That’s tempting because you might think it would reduce development time. However, adding patches to a cobbled-together mock-up typically produces a messy result that is hard to maintain and upgrade. Eventually, it becomes necessary to rewrite massive amounts of code, and the as- sociated confusion can destroy the program. It’s better to think of this kind of prototype as no more than a communication aid that elicits feedback which improves product specification.
Iterating
The first normal design iteration—or the iteration after an optional prototype—should be either a simple adaptation of some already existing program or a bare-bones implementation developed with either the top- down or bottom-up design strategy. Subsequent iterations may or may not continue to use the same design strategy.
How do you decide which strategy to use for each iteration? Select that strategy which best addresses your greatest current need or concern:
• If your greatest current need is to understand what the customer wants, construct a prototype.
• If your greatest concern is on-time delivery, try to use an adaptation of existing software.
Adjust design strategy to address greatest current need with resources currently available.