Software Engineering

224
CHAPTER 12 
Configuring the Physical Architecture
●
 
Prototypes fail to scale.
 Since a prototype is limited in functionality, the design 
it characterizes may not scale well when extended to solve the original customer 
requirements. In many cases, the fragile structural framework upon which the 
prototype was developed will not be capable of being enhanced in a manner to 
provide a stable, long-term design solution.
●
 
Users mistake the prototype as a nearly finished product.
 Customers view a 
software prototype as a nearly complete, final product that merely needs to 
be enhanced and fine-tuned. This leads customers to form misconceptions 
concerning the readiness of the development team to deliver the final product. 
Customers may demand that the prototype be introduced into an operational 
situation well before the product is ready for such a trial.
●
 
Developers become attached to the prototype.
 Developers become loyal to 
prototypes they have spent a great deal of effort producing. This can lead to 
attempts to renovate a limited prototype into a final system even though the pro-
totype is not founded upon a durable, underlying design architecture. (This sug-
gests that throwaway prototyping, rather than evolutionary prototyping, is the 
preferred approach.)
●
 
Excessive development time dedicated to the prototype.
 A key property to pro-
totyping is the fact that it is supposed to be done quickly. If the developers lose 
sight of this fact, they very well may try to develop a prototype that is too com-
plex and too costly.
●
 
Expense of implementing a prototype.
 The costs for constructing a software 
prototype may exceed the benefits gained from its existence. The original pur-
pose of a prototype is to be evaluated to resolve engineering design challenges. 
However, as a prototype consumes an increasingly large amount of the software 
development budget it becomes a significant investment that may be difficult to 
scrap.
There are situations for which a software prototype development effort should 
be commissioned. Each assessment of the structural solution may reveal a techni-
cal challenge or risk that can best be reconciled by prototyping a software-based 
solution. When considering the development of a software prototype, the following 
considerations must be factored into the scope of the effort:
1. 
Each commissioned software prototype is an engineering step toward solving a 
more significant problem. The commitment of resources to the development of 
a prototype must provide a return on investment in terms of clarifying customer 
needs and requirements or providing a resolution to design challenges or risks.
2. 
Software prototypes must be “engineered” in a similar manner as the deliverable 
software product. The prototype must be undertaken with the understanding 
that certain features and characteristics envisioned for the final product will not 
be incorporated or addressed by the prototype. The scope of the prototype must 
be dedicated to the engineering problem for which answers are being sought. 
However, the prototype must be sufficiently crafted based on software engineer-
ing practices to tolerate demanding test conditions.

---