 |
 |
 |
 |
| |
|||||
|
|
|
|
|
||||
Are Agile Software Methods Appropriate for Prototyping? Jim Moore and Tim Rice 
n old proverb about software development says, "If you don't know where you're going then any road will do." The implication is that you have to thoroughly understand and plan a software project before commencing work. However, in prototyping we truly may not know where we are going. The purpose of developing a prototype may be to explore a set of possible solutions to a difficult problem so that we can better understand the nature of the problem. In this article, we first look at some important characteristics of prototypes. Then we discuss the general problems of software development (a big part of prototyping) and the reason for the emergence of "agile" methods for software development. We next consider the use of agile methods for developing complex software products and identify some shortcomings. Finally, we observe that some of the shortcomings for product development are not relevant to prototype development and reach a conclusion on agile methods and prototyping. Characteristics of Prototypes Although some sources distinguish between a "throw-away" mockup and a "usable" prototype, the term prototype is generally used broadly to mean a product that has restricted function or capacity and is intended to be displaced by a product that lacks those restrictions. Sometimes the prototype is grown into the final product and sometimes it is simply thrown away and replaced. We sometimes develop prototypes to learn lessons because we're not sure what we want in the final product or we're not sure if the problem can be solved. Complex modern products, and thus their prototypes, usually include software. In addition, prototypes sometimes use software in the place of components ultimately intended for implementation in hardware. This is done on the assumption that software components can be modified quickly in response to trial usage and experimental results. Agile Methods One of the challenging aspects of software engineering is the difficulty of constructing, within a limited schedule and budget, satisfactory products that meet the stated requirements, satisfy the implicit expectations of the users, and exhibit high quality. Because it is difficult to measure software product quality, the emphasis over the past three decades has been on defining high quality software development processes on the presumption that high quality processes will produce high quality products. As software systems became larger and more complex, so did the development processes meant to ensure quality. The result, according to some software developers, is that the complexity of these processes has resulted in development that is slow, clumsy, and difficult—and has stifled creativity and supported mediocrity. These developers claim that when using these processes, they cannot rapidly and economically react to changes in system requirements that are simply a fact of life as users better understand their needs. A group of developers started looking for a better way—faster and more flexible and responsive—to develop software. These approaches are now referred to as "agile methods." Generally, these methods minimize the overhead of development, including documentation, up-front planning, and controls on development. Instead, they emphasize frequent delivery of improved releases of increasingly capable software that can be directly evaluated by users of the system. By minimizing the overhead, they claim to make the software easy to change, hence reactive to changing needs. Agile methods are a hot topic in commercial information technology because the proponents of the methods say they are faster, cheaper, and more responsive to user needs than the traditional methods of software engineering. A dozen or so different agile methods are becoming well known, with names like Extreme Programming, Scrum, and Internet Speed Development. Agile methods generally have the following characteristics:
Complex Software Are agile methods appropriate in developing prototypes? We are still gaining experience and knowledge in this area. However, we do know that some of the characteristics listed above may be problematic for the development of large, complex, long-lived software systems. For example, the quickly developed code may "speak" to the original development team, but the lack of supplementary documentation may present a difficulty to maintainers years hence who are trying to figure out how to fix a problem or improve the product. The methods are particularly questionable for the development of systems with safety-critical needs. For example, we may not find users willing to try out partial solutions in the development of anti-lock braking systems. Safety-critical systems typically undergo many different forms of verification before users are allowed to try them. Advocates of agile methods versus traditional software engineering methods generally divide along this question: Is a software product/prototype easy to change or hard to change? Traditional developers answer "hard" because they know they have to revise detailed development plans, modify the software, perform various reviews to ensure quality, and prepare extensive documentation explaining what they did. Agile developers, however, are more likely to say that changing software is easy because they don't have a detailed plan, don't perform reviews, and don't prepare much documentation. So to change the product, they just alter the code, test the changes, and try it out on sample users. If it's a disaster, they back it out. If it's not right, they fix it. It is the treatment of planning that provides the sharpest distinction between traditional methods and agile methods. Suitability of Agile Methods Regardless of their applicability to the development of large, complex software systems, agile methods do appeal to prototype developers. For one thing, the agile methods' focus on producing working software as the end product fits well with the needs of some prototype developers. Also, the quick turnaround of user evaluation—receive change request, implement code, have users re-evaluate—supports the use of prototypes to evaluate a variety of solutions to the users' problem. Some people may object that these methods are simply undisciplined "code and fix" programming without any underlying rigor. There is evidence, however, that some agile methods introduce just enough rigor to be suitable for prototyping. For example, the method known as Extreme Programming (XP) requires that programmers work in pairs—two programmers sharing one computer—so that every line of code will be read by two sets of eyes. XP also ensures comprehensive, but low-cost, regression testing by requiring programmers to write the tests for their code before writing the code and by automatically running those tests periodically on the evolving product to ensure that no function is ever lost. Here's another way to look at the contrasts between the traditional and agile approaches to software development: There are two different ways to climb a mountain. You can climb slowly, following a detailed plan that anticipates every problem, leading a train of porters carrying all of the equipment that you might need to set up a string of camps. Or, you can climb fast and light, carrying only the essentials on your back, improvising as you go—hoping to get to the top before problems arise. Both ways can succeed; both ways can fail. In building a prototype, we are often unable to make a detailed plan. The purpose of developing a prototype may be to explore a set of possible solutions so that we can better understand the nature of the problem. In this case, the heavy approach may not work because we don't know which problems to anticipate. In short, the jury is still out on the question of using agile methods for building large, complex software products. The application of agile methods to prototyping, however, does seem like a sensible fit, particularly when the objective of the prototype is to discover the real needs of the user. |
|||||
| For more information, please contact Jim Moore or Tim Rice using the employee directory. Page last updated: January 7, 2005 | Top of page |
|||||
Solutions That Make a Difference.® |
|
|
Download this issue [1.9 MB]