Better Software - April 2008 - (Page 26)

Incremental Development Figure 1: The Validation V is a fact of life. Figure 2: The first increment delivers one slice of functionality through the whole system. Figure 3: The second increment delivers another slice of functionality through the whole system. Figure 4: The third increment delivers the rest of the system. Incremental development is easier to explain and to manage, so let’s start there. First, let’s get comfortable with the “Validation V” shown in figure 1. Read the figure from right to left, to see it as the dependency diagram it really is: We can’t ship our system until it’s been integrated, tested, and validated. It can’t be tested until there’s code, and we can’t design and code it until we’ve decided what to build. Some people see this diagram and immediately shout, “Waterfall!” (holding up the sign of the hex, or whatever). However, it is a simple fact of life, and we will take advantage of it in learning how to work with both incremental and iterative development. You can see the Validation V in action in figures 2 through 4, illustrating incremental growth of the system—multiple passes through the Validation V for each new section of the system to be built. In figures 2 through 4, the columns represent different features we wish to implement; the rows represent the different layers: user interface, application, middleware, and database. Figure 2 shows that the first feature is completely available after the first increment, figure 3 shows that the second feature is completely available after the second increment, and figure 4 shows that the last feature is completely available after the third increment. The figures don’t show that the application or the database might have been refactored during the second or third increments. Those are iterative (rework) issues. They show the perfect incremental situation, in which additional features are added without having to revise the pre-existing features. It is rare that we get to work in such a pure incremental fashion in software development, which is why we also need to understand and manage the iterative strategy. Incremental development is a very successful staging strategy that has been used as long as software has been built. The tragedy is that people forget to leave time to check for mistakes in understanding from the requirements gathering periods, and they forget to leave time to refine their designs. For these, they need iterative development. 26 BETTER SOFTWARE APRIL 2008 www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - April 2008

Better Software - April 2008 Contents Mark Your Calendar Contributions eLightenment Technology Speaking - A Change Would Do You Good Code Craft - A "D" In Programming, Part 1 Test Connection - Learning the Hardware Lessons Management Chronicles - The Art of Persuading Management Cover Story - Incremental and Iterative Development Developers...Start Your Engines Where Do I Go From Here Product Announcements 10 Things You Might Not Know About... The Last Word - Software Quality and the Prisoner's Dilemma Ad Index

Better Software - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.