Java: Iterative/Incremental Development

There are many ways to divide the Software Development Life Cycle. I've choosen some common terms, but don't be surprised to see other terms. Here's a brief explanation of the what each means.

• Analysis - Also called requirements analysis. This is the process of figuring out what the customer wants or needs.
• Design - This is the process of deciding how to structure the program. For large projects this is often divided into two stages: architectural design and detailed design.
• Testing - This is the process of trying to detect errors in the program. For large programs this is typically divided into two parts: unit testing tests individual modules and integration testing sees if the total program works when all the modules are run together.

Waterfall technique -- traditional, but risky

When you understand a problem and its solution very well, it's possible write a program by following the steps at the left. But problems are rarely understood as well at initially thought, and this "waterfall" approach has turned out to be responsible for an extraordinarily high number of software project failures. There are several reasons for this. Mistakes in the understanding the the early phases (eg, requirements analysis and design) that are not discovered until the testing or integration phases are expensive (ie, time consuming) to fix, costing much more time (eg 20x) to fix than if they had been done right the first time. The earlier mistakes are discovered, the easier they are to fix. The cost of finding an error that must be fixed in the completed design or coding phases is usually quite high. Student programs often suffer from this in several ways. The requirements of a programming problem may not be well understood. For example, the instructor may not have written a clear problem statement. If the student is designing their own project, they may not always be clear about what they want. Typically, the idea for a student project evolves as the project progresses. Sometimes the programming solution may not be well understood, and a plan is made based on incorrect ideas about what will work. The resources (ie, time) required to complete a program are not accurately estimated (almost always in the optimistic direction). In commercial development this results in late delivery and cost overruns or cancellation. In student programs it means that the program doesn't run, with unhappy consequences. This are some of the typical reasons that use of the Waterfall methodology is not recommended. An iterative/incremental approach is better.

Disadvantages compared to iterative method

• The cycle of getting rid of compilation errors can be unnecessarily long.
• The output may not be what you want, but when debugging an entire program, it's harder to identify the source of the error.

Advantages of waterfall devlopment

Although it is probably responsible for more failures than successes, not everything is bad about this approach.

• By writing the entire program first, you are become aware of problem areas, and take corrective action.
• If the problem is very well understood, this may be the most efficient solution. However, experience has shown that it is frequently inferior to iterative programming.
• It may simply suit your personality better. is this a good reason to use it?

Iterative and Incremental Development

Start with a very small version of the program. So small that maybe it doesn't too much besides show some part of the graphical user interface, but doesn't do anything. Test it to make sure it runs ok. Analysis. Decide which improvement should be made next. Make a small change. Design how you will will code the change. Code it and compile to make sure your coding is correct. Often I type only a couple of lines of code before recompiling. Some IDEs, such as NetBeans, does continuous compilation which shows your errors without the need for an explicit compilation request. Testing. Run the program, using test data if necessary. If it doesn't run, the program must be debugged and either the coding or design should be changed. Because the last change should have been small, it's usually easy to identify the source of the problem. Continue around this loop until the program is finished, or you've run out of resources (time). Using the iterative appoach means that there's a running program at the end of each iteration. It doesn't to everything, but it is something you can turn in. For a company this means that it may be able to use the program for some work and get value out of it before it is finished. It also means that the project can be terminated as soon as the program is "good enuf".

It's often hard for students to restrict themselves to small changes, and they write many, many lines of code. Or to think of it another way, many bugs. The more simultaneous bugs a program has, the harder it is to debug, so keep the number of new bugs to a minimum.

Making very small changes, compiling and testing means that you are much less likely to be faced with a long list of error messages with no idea how to find the problem. A single missing left brace can produce many error messages. If you've only entered a few lines of code before recompiling, you know the error is in those few lines of code and it's much easier to track it down.

Advantages of iterative development

• You always have a running version of the program, eg, if you run out of time, you can deliver the last iteration, which may not have all functionality, but it does something. This is usually worth more to your instructor than a program which doesn't even compile yet.
• It helps identify the source of the last error (compilation or execution), because you know it's in the code you just added in this iteration. This makes finding bugs much faster.
• It's psychologically more satisfying to get positive feedback on your work, ie, a running program.
• Corrections early in development generally take less time than later in the development process.

Disadvantages of iterative development

• The iterative approach tempts you to start coding too early. You should have a good idea of what the final program should look like before starting. Unless you're clear on what you want, it's likely that many extra iterations will be required.