Modern software development demands the use of Rapid Application Prototyping. Professor Luqi at the Naval Postgraduate School coined the term "Computer Aided Prototyping" to describe this work. Her leadership showed its effectiveness in gaining understanding of the requirements, reducing the complexity of the problem and providing an early validation of the system design. For every dollar invested in prototyping, one can expect a $1.40 return within the life cycle of the system development.
Dr. Barry Boehm's experiments showed that prototyping reduces program size and programmer effort by 40%. It is the technology that is the foundation for his Spiral development method. Prototyping is being used successfully to gain an early understanding of system requirements, to simplify software designs, to evaluate user interfaces and to test complex algorithms. It is a best-in-class software approach.
Fully 30 to 40% of system requirements will change without prototyping. Rapid Application Prototyping provides a look at the dynamic states of the system before we build it, whereas most other software engineering focuses on the source code. The special problems of reliability, throughput and response time as well as system features are addressed in the best prototypes. A new field of study, Software Dynamics, will emerge once Rapid Application Prototyping is widely practiced. It will focus on quantitative analysis of how software performs under various loads and include a set of design constraints that will make it possible for us to build components that can be hooked together without exhaustive coverage testing.
Software is hard because it has a weak theoretical foundation. Most of the theory that does exist focuses on the static behavior of the software, analysis of the source listing. There is little theory on its dynamic behavior, how it performs under load. To avoid serious network problems software systems are over-engineered with plenty of bandwidth for two or three times the expected load. Without analysis of the dynamic behavior, application designers have no idea of the resources they will need once their software is operational. Software has the awful propensity to fail with no warning. Even after we find and fix a bug, how do we restore the software to a known state, one where we have tested its operation? For most systems, this is impossible except with lots of custom design that is itself error-prone. Software prototyping has proven its mettle in helping designers avoid these problems in their production systems.
Much has been written about the best way to develop software applications. But there is no "best way." Both prototyping and requirements are necessary. The tried and true process of synthesis and analysis is used to solve Software Engineering problems. Bottom-up is synthesis. Top-down is analysis. Bottom-up is prototyping. Top-down is developing requirements. Prototyping is the best way to encourage synthesis. Prototyping also eases communication with the customer and with the designer. Formal written requirements are needed to establish a clear definition of the job, to control changes and to communicate the system capabilities between the customer and the developer.
So where does this leave us?
Start with an English language written statement of a problem and broadly outline its solution. Now build a prototype for the elements where you need insight. Analyze the prototype using computer aided prototyping technology and synthesize a new solution either by refining the prototype or building a new one. Once you and the customer agree on the workings of the prototype, write requirements that include features, performance goals, product costs, product quality, development costs and schedule estimates.
What do I mean by prototype?
Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it. Code resulting from prototyping is often used to train the programmers. Only after we have written specifications resulting from the experience with the prototype should we start the formal development process. If we are fortunate enough that some of the code that was developed for the prototypes can be carried forward, that's great, if not, there is no loss.
A prototype produces "running" software and the production development produces "working" software.
Recent project experience has led to the widespread acceptance of the concept that early prototyping is fundamental to the success of operations supporting software products.
The reasons why prototyping is fundamental include:
Mr. Bernstein is president of the Center of National Software Studies and is a recognized expert in Software Technology. He provides consulting through his firm Have Laptop - Will Travel and is the Executive Technologist with Network Programs, Inc. building software systems for managing telephone services.
Mr. Bernstein was an Executive Director of AT&T Bell Laboratories where he worked for 35 years.
