To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Most people would answer your question in two words: Iterative Development.
Unfortunately, few people realize that two-word conventional wisdom answer is only partly accurate. It's overly simplistic, illusory, and likely to mask many of the issues that will continue to plague the situation you ask about if you fall into iterative development traps.
Iterative development comes in many popular flavors, such as Rapid Application Development (RAD), Prototyping, Spiral Development, Rational Unified Process (RUP), and Agile Development's several variations. Each is a way to build a little, check it with the users, adjust accordingly, build a little more, check it again, adjust and so on.
Waterfall concepts and misconceptions
Iterative development arose as an alternative to practices which many people equate to the "waterfall" development model. The waterfall has a series of sequential phases: feasibility analysis, requirements definition, system design, development (coding and testing, which should be treated together, although some people consider testing a separate phase from coding), implementation and operations and maintenance.
Waterfall is commonly interpreted to mean that each phase is done in its entirety for the project before moving to the next phase and there is no going back to a prior phase once it's been completed. While undoubtedly some organizations do go forward inflexibly through full project phases, many waterfall projects do not. For example, it's common to break a big project into multiple subprojects, including some which are implemented in a quick timeframe similar to iterative.
Moreover, a management review should be held at the end of each waterfall phase, sometimes called a "gate review" can be used to determine that the phase has been completed successfully before proceeding and to make a Go/No Go decision about whether it still makes sense to continue with the project. If the phase's deliverables are not acceptable, the project may well return to prior phases as needed to get the information necessary to get back on track. If the decision is not to proceed, the project may simply be stopped or it may return to a prior phase to redefine the project.
The common concern about waterfall projects is that there can be a long delay between project initiation and when the user has their first opportunity to see what's actually been developed, when they finally become aware of problems. It's frequently felt that the waterfall increases the likelihood and impact of those problems.
Those who study development find time and again that inadequately-defined requirements are the major source of problems. Waterfall's critics contend that waterfall assures requirements are defined inadequately because they say it's impossible to know the requirements early in a project. Also, they say waterfall extends the project duration, and the longer the project lasts the more its requirements will change. Together, these requirements issues necessitate redoing much of the project work, much later when rework takes longer and costs more to do.
Iterative development's advantages
The big advantage of iterative development is that it breaks the project work into smaller pieces which are checked more frequently. Since the project can't get as far off track before problems are detected, less time and effort is wasted on work which turns out to be wrong. Instead of spending time trying to get requirements right and yet still having them change, wait for the changes and then build systems in response to the changed requirements so work doesn't have to be redone so much. Functionality grows steadily as additional small pieces of working code are developed, checked, and implemented.Reducing wasted effort and delivering working code quicker certainly are laudable.
Issues iterative's advocates don't recognize
Unfortunately, there's often a lot going on that usually isn't recognized by conventional wisdom's idyllic picture of iterative development. It doesn't mean that iterative is bad, and surely not all bad; only that as frequently practiced, iterative is not nearly so good as blindly believed or as good as it could be with a bit broader awareness.
All life cycles follow the same set and sequence of phases. Iterative development just does it multiple times with smaller pieces of functionality. However, too often in practice iterative skips or short changes the most important feasibility, requirements, and design phases. People don't realize that their iterative development frequently emulates the classic cartoon, "You start coding, and I'll go find out what the requirements are."
While it's preferable to redo smaller pieces rather than larger ones, iterative's leaping into coding can lead to redoing many smaller pieces with a seldom-recognized large total rework cost. Furthermore, insufficient design can cause integration difficulties and additional avoidable rework. When requirements errors are considered inevitable and rework is masked, such as by calling it "refactoring" and treating it as a virtue, wasteful activities can become a self-fulfilling prophecy.
Much of the difficulty stems from mistaken beliefs about requirements. Development iterations are mainly responding to changes in requirements of the product, system, or software being built, which actually are a form of human-defined high-level design. The REAL business requirements that the product/system/software must satisfy exist within the business environment and tend not to change nearly so much; but because they haven't been identified adequately, repeated failed product design efforts to satisfy them make it seem as though the requirements are changing.
Effective development starts by discovering the REAL, business requirements that provide value when met and then mapping them to a product/system/software design which will meet them. Discovering requirements directly takes relatively little time, certainly far less than backing into them by writing, checking, and adjusting code.
Then, the product design can be partitioned reliably into pieces which can be developed iteratively, including further detailed business requirements discovery, and ultimately integrated effectively. It actually can cost far less and deliver a better result quicker.
|
