Software prototyping

Abstract

"In the early 1980's, organizations used prototyping approximately thirty percent (30%) of the time in development projects. By the early 1990's, its use doubled to sixty percent (60%)".[1] It is clear that prototyping is gaining rapid acceptance in the software development field. This paper aims to introduce the reader to prototyping techniques as they apply to software engineering and development. Different methods and tools are discussed.

Introduction

Developing software systems is often a very time and labor intensive process. As such, it is in the best interest of a development team to maximize its resources by developing a system that meets the user requirements, thus eliminating the need to rebuild the system after completion. It has been argued that defining the user requirements can be quite a difficult task. For the users, many large systems projects are often difficult to fully grasp when they are in the very early stages of design. "In classical software development, the client usually cannot view a physical representation of the final system until the testing phase."[2] Because of this problem, defining systems requirements is a difficult task. Prototyping is one possible way to overcome this difficulty.

Prototyping is a euphemism for "failure", in recognition that it is almost impossible to succeed the first time…"Rapid prototyping" assumes that it is difficult, if not impossible, to capture user requirements early in the design process…Prototypers believe that "working models" of system concepts can facilitate communication among users and designers in some ways that words alone cannot. Prototyping provides a way to refine and validate user requirements. [3]

Prototyping, as a process in general is extremely popular, as can be witnessed by the many manufacturing and chemical companies that use it daily. In software development, the process is relatively young, but is gaining momentum as a valid addition to most development efforts.

The creation of a prototype has been a standard practice in many engineering and manufacturing industries for decades. The benefit of building a prototype instead of the actual object is that there is no manufacturing risk…There is no manufacturing risk in software, but there is considerable development risk.[4] A software prototype implements part of the presumed software requirements to learn more about actual requirements or about alternative designs that could satisfy the requirements. Without prototyping, developers could easily create software that satisfies an incorrect set of requirements. [5]

Types of Prototyping

Since it was first proposed in the late 70's[6], software prototyping has had many variants. As it is now, prototyping comes in many forms. However, all of the various methods are based in some way on two major types of prototyping. They can be classed into two families: Throwaway Prototyping and Evolutionary Prototyping.

Throwaway Prototyping

Throwaway or Rapid Prototyping is the most easily understood prototyping method. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.[7]

There are many strong reasons for using Throwaway Prototyping. The most obvious one is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. In addition, the speed is crucial since with a limited budget of time and money, the majority must be spent on the most difficult task: coding the system. By creating prototypes quickly, the time saved can be very useful.

Making changes early in the development lifecycle is also extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable amount of work has been done, small changes could require very large efforts to institute since software systems have many dependencies.

Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, grasping how the system will work is a much easier task.

…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and useable system from the user's perspective via conventional software development models. [8]

Not exactly the same as Throwaway Prototyping, but certainly in the same family is the usage of storyboards, animatics, or drawings to show how the system will look. These representations, although not functional, can be very useful.

Evolutionary Prototyping

Evolutionary Prototyping is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built on to it."[7]

When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. "…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."[5] This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.

For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.[9]

Evolutionary Prototyping has a very big advantage over Throwaway Prototyping. The advantage is in the fact that evolutionary prototypes are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."[7]

Also important to note, is that when using Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.

To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.[10]

Advantages of Prototyping [11]

There are many advantages to using prototyping in software development. Some are tangible, and some are abstract - all are important to consider.

Prototyping Reduces Development Time

As we've seen, system development can be a very time consuming process. Even when done right, a system designed with the traditional structured development methodology can take a considerable amount of time to complete. By using prototyping, the time spent developing a system can be dramatically lowered because the requirements are much more refined which leads to fewer changes during development.

Prototyping Reduces Development Costs

Whenever there is a savings of time, there is a related savings in money. "Davis compiled data from 3 separate corporate studies which showed that when problems were discovered early, they were least costly to repair".[8]

Prototyping Requires User Involvement

One of the fundamental tenants of prototyping is to involve the users more in the development of the system than they usually are. The most obvious reason is that the user is the one the system is being built for, however there is a deeper benefit to the users being actively involved. The user knows the problem domain better than anyone on the development team does.

In traditional development, the systems analysts job when collecting requirements is to transfer…

all knowledge about the existing system from the mind of the user into a specification to be used by the development team [which is further transferred] to the mind of the programmer. This transfer of information involves a massive overhead in specification, and opens up all kinds of opportunity for misunderstanding and error.

In the case of an evolutionary development approach there is no need for this complete transfer; the prototyper and the user are working in partnership on the analysis and design, so that the repository of detailed knowledge about the existing system can remain in the mind…of the user. [7]

With Prototyping, Developers Receive Quantifiable User Feedback

Since the users are 'in the loop' their feedback is more direct and timely. Using structured methods, the users are usually interviewed at the beginning of the project and then never called upon until the product is finished. Using prototyping, the developers are often in direct contact with the users throughout development.

Prototyping Facilitates System Implementation and Results in Higher User Satisfaction

Using traditional forms of software development has often been a problem when it came time to implement the finished system. Often users aren't happy with the way the system looks, feels or performs. The problem arises because the new system has not been seen by the users until it is finished. This initial friction with the users isn't a problem when prototyping is used because the users have been a part of the development and are familiar with the system before it's implemented.

Prototyping Exposes Developers to Future System Enhancements

Since development of software systems often takes time, the design team is constantly dealing with changes in the company, problem domain, and the requirements of the system. Usually, there is a 'freeze-date' where no new requirements are added to the system. Because the development team is involved with the users more, they are able to see potential new requirements and log them for the next revision of the system.[7]

Disadvantages of Prototyping [11]

Prototyping Can Lead To Insufficient Analysis

It is easy to develop a prototype and have the users agree that it's perfect. Because of this, there is a problem in that developers decide that their work is done at that point. The only job, from their point of view, is to make the prototype into a real system. In addition, a problem is that by quickly developing a prototype, other (more satisfactory) solutions to the problem may not be considered.

With Prototyping, Users Expect the Performance of the Ultimate System to be the Same as the Prototype

Often, prototypes are optimized to highlight a specific feature of the proposed system. It's important to keep the users aware that the prototype is not the finished system and that its primary focus is to define requirements.

Developers can Become too Attached to Their Prototypes

When developers work very hard on prototypes, it can be a problem to get them to throw them away. This problem also applies to the features that a developer may implement. They may work great and be elegant solutions, but they may not have any bearing on the actual user, or business requirements of the system.

Prototyping can Cause Systems to be Left Unfinished and/or Implemented Before They are Ready

The users may very well see a prototype and decide that it is ready. When using throwaway prototyping, this is certainly not desirable since the prototype is usually not very robust and also isn't fully functional. This can also become a problem if a user becomes attached to a feature that will be discontinued, or is just being tested for future upgrades.

If Sophisticated Software Prototypes are Employed, the Time Saving Benefit of Prototyping Can be Lost

The key to prototyping is the fact that it's supposed to be done quickly. If the developers loose sight of this fact, they very well may try to develop a prototype that is very complex and robust. This development may in fact take a lot of time, time that was better spent coding the actual product.

Methods

Since prototyping has become popular, it follows that many formal methods have grown out of its popularity. There is no formal 'Prototyping Methodology' as yet; instead, there are several competing methodologies. The ironic thing is that most of the proposed methods of prototyping use Evolutionary Prototyping as their base.

We will look at three methodologies here. Note that they are not necessarily the most popular, or the 'accepted' methodologies, but a sampling of what is being used in the field today.

Operational Prototyping

Operational Prototyping was proposed by Alan Davis as a way to integrate throwaway and evolutionary prototyping with conventional system development. "[It] offers the best of both the quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop only well-understood features in building the evolutionary baseline, while using throwaway prototyping to experiment with the poorly understood features."[5]

Davis' belief is that to try to "retrofit quality onto a rapid prototype" is not the correct approach when trying to combine the two approaches. His idea is to engage in an evolutionary prototyping methodology and rapidly prototype the features of the system after each evolution.

The specific methodology follows these steps: [5]

• An evolutionary prototype is constructed and made into a baseline using conventional development strategies, specifying and implementing only the requirements that are well understood.
• Copies of the baseline are sent to multiple customer sites along with a trained prototyper.
• At each site, the prototyper watches the user at the system.
• Whenever the user encounters a problem or thinks of a new feature or requirement, the prototyper logs it. This frees the user from having to record the problem, and allows them to continue working.
• After the user session is over, the prototyper constructs a throwaway prototype on top of the baseline system.
• The user now uses the new system and evaluates. If the new changes aren't effective, the prototyper removes them.
• If the user likes the changes, the prototyper writes feature-enhancement requests and forwards them to the development team.
• The development team, with the change requests in hand from all the sites, then produce a new evolutionary prototype using conventional methods.

Obviously, a key to this method is to have well trained prototypers available to go to the user sites. However, overall, the Operational Prototyping methodology has many benefits in systems that are complex and have few known requirements in advance.

Evolutionary Systems Development

Evolutionary Systems Development is a class of methodologies that attempt to formally implement Evolutionary Prototyping. One particular type, called Systemscraft is described by John Crinnion in his book: Evolutionary Systems Development.

Systemscraft was designed as a 'prototype' methodology that should be modified and adapted to fit the specific environment in which it was implemented.

Systemscraft was not designed as a rigid 'cookbook' approach to the development process. It is now generally recognised[sic] that a good methodology should be flexible enough to be adjustable to suit all kinds of environment and situation…[7]

The basis of Systemscraft, not unlike Evolutionary Prototyping, is to create a working system from the initial requirements and build upon it in a series of revisions. Systemscraft places heavy emphasis on traditional analysis being used throughout the development of the system.

Evolutionary Rapid Development

ERD was developed by the Software Productivity Consortium, a technology development and integration agent for the Information Technology Office of the U.S. Defense Advanced Research Projects Agency. It is a more refined and up-to-date methodology than Systemscraft, which focuses on using small teams with tight deadlines to create parts of the system in parallel with each other.

Fundamental to ERD is the concept of composing software systems based on the reuse of components, the use of software templates and on an architectural template. Continuous evolution of system capabilities in rapid response to changing user needs and technology is highlighted by the evolvable architecture, representing a class of solutions. The process focuses on the use of small artisan-based teams integrating software and systems engineering disciplines working multiple, often parallel short-duration timeboxes with frequent customer interaction.

Key to the success of the ERD-based projects is parallel exploratory analysis and development of features, infrastructures, and components with and adoption of leading edge technologies enabling the quick reaction to changes in technologies, the marketplace, or customer requirements.[9]

Some key features of ERD include:[12]

Significant Customer/End-User Participation

The vision for the system and how it could be used must evolve along with the users' understanding of their needs. As the system gains capability, the users become aware of additional needs and set updated priorities for the features to include in the system.

To elicit customer/user input, frequent scheduled and ad hoc/impromptu meetings with the stakeholders are held. Demonstrations of system capabilities are held to solicit feedback before design/implementation decisions are solidified. Frequent releases (e.g., beta) are made available for use to provide insight into how the system could better support user and customer needs. This assures that the system evolves to satisfy existing user needs.

"Time Boxing"

The ERD process is structured to use demonstrated functionality rather than paper products as a way for stakeholders to communicate their needs and expectations. Central to this goal of rapid delivery is the use of the "time box" method. Time boxes are fixed periods of time in which specific tasks (e.g., developing a set of functionality) must be performed. Rather than allowing time to expand to satisfy some vague set of goals, the time is fixed (both in terms of calendar weeks and person-hours) and a set of goals is defined that realistically can be achieved within these constraints.

COTS-Based, Reuse Driven Approach

The ERD process is based on an aggressive strategy that systematically identifies and uses government, industry, or academia-provided components, tools, and technology as a basis for composing the system.

The COTS-based approach for incorporating reuse into the development process leverages the use of templates and frameworks whenever possible; and in some cases may require that new templates be synthesized from existing components or example software.

Small Team Composition

The ERD process invests heavily in maintaining its human resources. Highly experienced individuals are cloistered together and provided liberal amounts of computer infrastructure, tooling, and access to technical literature and knowledge bases. The process includes a set of roles defining responsibilities within the development team. The roles establish a career path whereby junior individuals can participate in highly specialized programming roles and learn from more senior members through activities such as code reviews and testing using a test buddy approach.

Continuous Process and Product Improvement

Since it is an iterative strategy, evolutionary development allows for re-specifying the need and the technology as the user, business, and technology environments change. Unproductive iteration is controlled by an overriding vision, or concept, for the product and its use. Each iteration either further refines the vision or incrementally produces versions to satisfy all or part of the vision. Feedback between increments provides for both adjusting the vision and determining the features to implement across each iteration.

Cusp Identification

Analysis and planning for change is central to the ERD process. Cusp identification deals with identifying trends in the emergence and use of technology within an industry. This practice requires tracking the publishing and acceptance of standards, identifying changes in the marketplace for price/performance, observing the number of applications using a technology, and identifying trends within industry surveys. The objective is to position the development (e.g., the architecture) to anticipate and react to beneficial changes at the right time.

Architecture-Based Composition and Integrated Domain Engineering

The design framework for the system is based on using existing published or de facto standards. The system is organized to allow for evolving a set of capabilities that includes considerations for performance, capacities, and functionality. The architecture is defined in terms of abstract interfaces that encapsulate the services and their implementation (e.g., COTS applications). The architecture serves as a template to be used for guiding development of more than a single instance of the system. It allows for multiple application components to be used to implement the services. A core set of functionality not likely to change is also identified and established.

Long-Range/Short-Range Planning

To keep development from degenerating into a "random walk," long-range plans are defined to guide the iterations. These plans provide a vision for the overall system and set boundaries (e.g., constraints) for the project. Each iteration within the process is conducted in the context of these long-range plans. The time period that the long-range plan covers is extended as necessary. There is a continuum from concept through composition and deployment/enhancement. Decisions about the process or product are made from a life-cycle perspective.

Continuous Integration and Testing

Once an architecture is established, software is integrated and tested on a daily basis. This allows the team to assess progress objectively and identify potential problems quickly. Since small amounts of the system are integrated at one time, diagnosing and removing the defect is rapid. User demonstrations can be held at short notice since the system is generally ready to exercise at all times.

When is it Best to Use Prototyping

It's been argued that prototyping, in some form or another, should be used all the time. However, in a system that will have many interactions with the users, prototyping really gets a chance to show its strengths.

It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The more the interaction between the computer and the user, the more benefit can be obtained from building a quick system and letting the user play with it.[7]

Systems that don't have much user interaction, such as batch processing, or systems that mostly do calculations, prototyping isn't a good tool. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.[7]

Prototyping, as we've seen is also a very good tool for designing interfaces and building good HCI. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."[8]

Potential Problems

Prototyping can have problems. One common one is that the start up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean re-training, re-tooling, or both.

Many companies tend to just jump into the game and don't bother to retrain their workers as much as they should.

A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.[13]

What Tools are Used?

Since the birth of prototyping, many tools have been created to support its use. Some tools can be bought off the shelf while others were built from the ground up. It's very common to see 4th generation programming languages like Visual Basic used since they are cheap, well known and relatively easy and fast to use. CASE tools, like the Requirements Engineering Environment are often developed for the military and other large organizations. Object oriented tools are also being developed, like LYMB from the GE Research and Development Center.

Visual Basic

Probably the most popularly used tool for Rapid Prototyping is Visual Basic from Microsoft. It can be argued that Microsoft's Visual Basic possesses many features, which a developer can use to facilitate an effective prototyping process. The features are:

• An interactive/visual user interface design tool.
• Easy connection of user interface components to underlying functional behavior.
• Easy to learn and use implementation language (i.e. Basic).
• Modifications to the resulting software are easy to perform.
• As well this, Visual Basic is appropriately suited to this form of rapid development because the software is executed on an interpretative basis, and does not rely upon lengthy compilation processes. Although this maybe considered a limiting factor when developing production quality systems, whose speed and response times are crucial, prototyping does not requires this.[14]

Requirements Engineering Environment

"The Requirements Engineering Environment (REE), under development at Rome Laboratory since 1985, provides an integrated toolset for rapidly representing, building, and executing models of critical aspects of complex systems."[15]

Requirements Engineering Environment is currently used by the Air Force to develop systems. It is:

an integrated set of tools that allows systems analysts to rapidly build functional, user interface, and performance prototype models of system components. These modeling activities are performed to gain a greater understanding of complex systems and lessen the impact that inaccurate requirement specifications have on cost and scheduling during the system development process. Models can be constructed easily, and at varying levels of abstraction or granularity, depending on the specific behavioral aspects of the model being exercised.[15]

REE is composed of three parts . The first, called proto is a case tool specifically designed to support rapid prototyping. The second part is called the Rapid Interface Prototyping System or RIP, which is a collection of tools that facilitate the creation of user interfaces. The third part of REE is a user interface to RIP and proto that is graphical and intended to be easy to use.

Rome Laboratory, the developer of REE, intended it to support their internal requirements gathering methodology. Their method has three main parts:

[One:] Elicitation from various sources (users, interfaces to other systems), specification, and consistency checking [Two:] Analysis that the needs of diverse users taken together do not conflict and are technically and economically feasible [and Three:] Validation that requirements so derived are an accurate reflection of user needs.[15]

In 1996, Rome Labs contracted Software Productivity Solutions (SPS) to further enhance REE to create "a commercial quality REE that supports requirements specification, simulation, user interface prototyping, mapping of requirements to hardware architectures, and code generation…"[16] This system is named the Advanced Requirements Engineering Workstation or AREW.

LYMB [17]

LYMB is an object-oriented development environment aimed at developing applications that require combining graphics-based user interfaces, visualization, and rapid prototyping. These are some of LYMB's main features:

A library of over 600 classes of objects that have been reused or extended for applications in engineering design, medical imaging, command and control, quality control, and maintainability/service. The rapid creation of prototypes achieved by combining an interpreted environment with object classes that are compiled for fast execution. Highly portable environment that runs on Unix workstations, including HP, Sun, SGI, DEC, and IBM. LYMB has direct links to specific workstation display renderers and also integrates directly with Motif and X Windows. A built-in mechanism to distribute applications over a network of servers and clients.

Screen Generators and Design Tools

Also commonly used are screen generating programs that enable prototypers to show users systems that don't function, but show what the screens may look like. Developing HCI can sometimes be just as important to the development effort since to the users, the interface is essentially the system. There are many types of screen generators and HCI tools available.

Conclusion

It should be obvious that prototyping is a tool that should be used in all development. Since it was first proposed as a formal methodology, it has gained much attention and become quite popular. This paper has aimed to show that the way a company or development group decides to implement prototyping is not as important as weather they decide to implement at all. It has been shown how strong a tool prototyping is in terms of saving time, money and work in the development process.

[Prototyping] is not a tool to prove that we are right. It is a tool to show us where we are wrong. [Prototyping] allows us the opportunity to make mistakes by uncovering the error in an expeditious way. [Prototyping] provides the comfort of knowing that it is feasible to detect and correct our mistakes prior to a full commitment to the design.[6]

References

[1] C. Melissa Mcclendon , Larry Regot , Gerri Akers: The Analysis and Prototyping of Effective Graphical User Interfaces. October 1996. [1]

[2] D.A. Stacy, professor, University of Guelph. Guelph, Ontario. Lecture notes on Rapid Prototyping. August, 1997. [2]

[3] Stephen J. Andriole: Information System Design Principles for the 90s: Getting it Right. AFCEA International Press, Fairfax, Virginia. 1990. Page 13.

[4] R. Charette, Software Engineering Risk Analysis and Management. McGraw Hill, New York, 1989.

[5] Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.

[6] Todd Grimm: The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies, vol. 3 no. 3. Accelerated Technologies, Inc. May 1998 . Page 1. [3]

[7] John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 17.

[8] S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.

[9] Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.

[10] Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104-118

[11] Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.

[12] Adapted from Software Productivity Consortium. PPS 10-13.

[13] Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.

[14] Paul W. Parry. Rapid Software Prototyping. Sheffield Hallam University, Sheffield, UK. [4]

[15] Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. [5]

[16] Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. [6]

[17] from GE Research and Development. http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html

Also a good list of commonly used Tools - [7]