Prototyping in Systems Analysis

Introduction

Organizations of all types do it. Microsoft, Disney, and Boeing do it. It is known by several names: simulate, model, prototype. It is a process by which organizations innovate, better communicate both with their customers and with each other internally, develop and improve their products. Boeing builds digital prototypes of its aircraft allowing the detection of design conflicts before the parts are manufactured and assembled. Disney uses storyboards to work through the process of producing feature-length films. Microsoft sends out thousands of copies of "beta" versions of its software and then uses its customers as the testers of its "prototype" [12]. Its a powerful technique, but what place does it have in systems analysis?

This paper will look at what prototyping is to systems analysis. It will explain some of the advantages and disadvantages of prototyping and discuss why an organization might or might not want to consider prototyping. It will discuss who should be involved in prototyping and how to choose a prototyping approach and a prototyping tool. This is meant to be an overview of prototyping in systems analysis rather than a step-by-step guide. Links are provided where more information is available online.

Table of Contents

What is Prototyping?

As mentioned earlier a prototype is like a model or a simulation of a real thing.  In systems analysis a prototype is a model of the system (or subsystem) under analysis [2].  A system can be anything from the food ordering system at a restaurant to the air traffic control system of a major airport. Prototypes of these systems can take many forms. They can be paper-based or computer-based. They can model the entire system with real data or just a few screens with sample data.  Prototyping is the process of developing prototypes . It is a methodology in its own right and a technique and supplemental methodology to other methodologies. In this case, we will focus on the ways in which prototyping is used as a technique and a supplemental methodology to the systems development life cycle (SDLC).

A survey of MIS managers in Fortune 1000 firms [3] suggests that there are four prototyping methodologies in use today which supplement the traditional systems development life cycle: 

1. Illustrative: produces only mockups of reports and screens.

2. Simulated: simulates some system functions but does not use real data or a database, model not implemented. 

3. Functional: performs some actual system functions and uses real data and/or a database, model not implemented. 

4. Evolutionary: produces model(s) that become part of the final operational system.

Others suggest such categorizations as evolutionary versus throw-away [10]. Evolutionary in this case is similar to #4 mentioned above (sometimes known as operational [8] ). It produces a model that evolves throughout the development of the system and eventually becomes the final system. Throw-away (sometimes known as exploratory [8] , or expendable [5]) would encompass the other three methodologies previously mentioned. A throw-away prototype is just what it sounds like. Once its purpose is fulfilled it is thrown away.

Another way that prototypes are classified is by the fidelity of the prototype, or the degree to which the prototype represents the appearance and interaction of the system.[4]  A low-fidelity prototype is one that is quickly constructed to depict concepts, design alternatives, and screen layouts. Medium-fidelity prototypes partially simulate the system interaction and functionality. High-fidelity prototypes are fully interactive, simulating much of the functionality in the final product. The chart below suggests techniques that could be used at different fidelity levels.

Included in the chart above are terms used to describe other prototyping concepts. A horizontal prototype models many features with little functionality. While a vertical prototype models few features, but with great detail in functionality. [8] A scenario prototype has both very few features and very little functionality. The figure below illustrates these concepts:

Another prototyping concept similar to those just discussed is that of a diagonal prototype. One that is horizontal down to a certain point and then is vertical beyond that. 

One final classification of prototypes is global versus local. A global prototype models the entire system. It is much like a horizontal prototype, but goes into greater detail. A local prototype models a single system component. It is much like a vertical prototype that is focused on only one feature.[8]

As shown here a prototype can be defined by its functionality, features, data, interaction, and lifespan. There are no doubt more ways to classify and categorize prototypes, but these few demonstrate how characteristics can vary  from one prototype to the next.

Top of Page    Table of Contents

Advantages of Prototyping in Systems Analysis

Systems analysis is the requirements determination phase of the systems development life cycle (SDLC). In this phase developers determine how the current system functions and what users would like to see in a new system. [7]  In Rapid Development: Taming Wild Software Schedules [10], Steve McConnell states that  "A survey of more than 8000 projects found that the top three reasons that projects were delivered late, over budget, and with less functionality than desired all had to do with requirements-management practices: lack of user input, incomplete requirements, and changing requirements (Standish Group 1994)." Systems development today is any many ways software development. Just as with software, getting this phase right is critical to the success of the entire system. The reasons mentioned above for project shortfalls are really the result of poor communication. Prototyping, when used as a communication tool between the developers and the users, can help to overcome these problems. 

As a model of the new system a prototype allows for several forms of communication. First, it allows the developers to communicate to the users their understanding of the requirements. (Obviously before a prototype can be built there must be some initial requirements discussions between developers and users). The initial prototype, whatever form it takes, will automatically reflect the developer's understanding of those early requirements. After viewing/interacting with the initial prototype the second form of communication begins. The users give the developers feedback. Not only will the users correct any misconceptions by the developers, but they will likely recognize misconceptions or requirements they did not anticipate of their own. From this point on the process is iterative.  Developers will make corrections and changes to the prototype based on user feedback and the users will view/interact with the prototype and make changes to the requirements. This continues until they come to an agreement on the requirements or run out of time or money or both. At its best this process provides for very rich user input resulting in well thought out requirements both for the user and the developer.

Improved communication is just one of many benefits that can be realized when prototyping in the systems analysis phase. Here are some others reported in systems development literature [13, 8, 11, 6, 10]:

• Provides a process to perfect the requirements definition.

• Provides a formal specification embodied in an operating replica.

• More enthusiastic and constructive end-user, customer participation in requirements activities. 

• Improved morale of end-users, customers, and developers. 

• Greater level of user satisfaction with systems development.

• Users better prepared for later stages of development due to familiarity with prototype.

• Delivery of early proof-of-concept. 

• Prototype may be easily changed and even discarded. 

• Allows productive work to proceed despite initial uncertainties.

• Demonstrates progress at an early stage of development.

• May provide early training for future users of the system.

• May produce some useful deliverables even if the project runs out of time or money.

• Should result in a product that is a better fit for the customer's requirements.

• Systems produced through prototyping may be judged easier to learn and easier to use.

Opinions on the cost of prototyping vary. Some feel prototyping can allow for lower maintenance costs since the prototype is meant for change. While upfront costs can be high when purchasing special prototyping tools. [8]  Others feel that the cost of prototyping is about the same as traditional requirements gathering. They argue the tool cost and extra time for building the prototype are offset by the time saved later in getting the requirements right.

Top of Page    Table of Contents

Disadvantages of Prototyping in Systems Analysis

Even though the benefits of prototyping are strong there are disadvantages and potential risks associated with it. The primary concerns are that of excessive change requests and "feature creep". Just by the nature of the iterative process users will again and again request changes. As they reexamine the prototype they may think of new features they would like that are beyond the scope of the original project. These can be controlled with proper planning but both are legitimate concerns. Other concerns include  [8, 10, 2]:

• Can result in unrealistic schedule and budget expectations.

• Iterative nature makes it difficult for management to plan and schedule.

• Can bias the system analysis process. If the prototype is computer-based manual alternatives are unlikely to be considered. 

• Working prototypes may lead management and customers to believe that the final product is almost ready for delivery.

• People can begin to think of the prototype as the solution.

• The excellent (or disappointing) performance characteristics of prototypes may mislead the customer.

• Prototypes generally lack security, auditing, and other controls, and data integrity may be difficult to ensure. 

• Often inefficient and difficult to maintain.

• Tendency not to document. 

• Customers may not be prepared to provide the level or frequency of feedback required for iterative prototyping.

Tying a Sensible Knot [1] is a look at the best practices of New York State local government information systems projects. In a section on prototyping this guide summarizes how the NYS Department of Social Services considered "feature creep" to be a good thing. Click here to download a pdf version of this guide. The article on prototyping begins on page 68.

Top of Page    Table of Contents

Who should be involved in Prototyping?

The primary participants in the prototyping process are the developers and the users. The developers provide the development and prototyping expertise. The users provide the systems expertise. As with any project management support is critical both for the developers and the users. The developers will need support from their management to acquire the necessary resources for the project. Both developers and users will need management support to continue the iterative process through to its conclusion. 

 In the study described in Toward a Contingency Model for Selecting an Information System Prototyping Strategy, [5] the authors found that there were five variables, when combined with prototyping, that affected system success. The first two variables involved project innovativeness and system impact on the organization. The remaining three variables involved the developers and users. 

The first developer/user variable determined to affect system success when used with prototyping was developer experience with prototyping. According to the study, the primary benefit of experience is that the developer is prepared for the frequent changes in user requirements and for the high level of interpersonal communication required. Ironically, this study found if developers were already familiar with the application in development prototyping was of little use because less interaction was needed to determine requirements.

The remaining two factors which appear to affect system success are the amount of user participation and the number of users involved in the project. It should come as no surprise that when higher user participation is combined with prototyping projects are more likely to succeed. What is critical is that the high user participation comes from just a few people. A large number of users mixed with prototyping makes the development process more difficult to manage. Each user has his own ideas about how the system should work. Processing and implementing the changes of each user becomes considerably more difficult when a large number of users are involved.

Top of Page    Table of Contents

Deciding whether to Prototype or not 

Systems development efforts differ in so many ways. Each has its own scope, requirements, developers, users, management, level of innovativeness, development time, complexity, organizational culture, etc. While prototyping can be a strong asset for one project it can turn out to be a burden for another. The key is to use prototyping wisely.  System development experts suggest that prototyping positively affects the outcome of a system under development in the following situations [2, 9, 5] :

Some suggest [13, 2 , 5] considering other options for:

*These recommendations are not universal. For example, some argue that the high number of changes in requirements for a project of long duration justify prototyping. While others argue that prototyping's lack of manageability make its use questionable in projects of long duration. Some argue that existing systems projects do not benefit from prototyping, whiles others argue that when the existing system becomes the prototype it can be beneficial.[5]

Top of Page    Table of Contents

Choosing the Prototyping Approach 

Once an organization decides to use prototyping during systems analysis they must then decide on what kind of prototype they will build. Will they use an evolutionary or throw-away prototype? Will they use a low, medium or high-fidelity prototype? Will it demonstrate lots of features with little real functionality as with a horizontal prototype? Or will it have a lot of functionality in one area with few features as with a vertical prototype?

Here are some key points to considering when deciding on the most appropriate approach.[4]  The approach solutions suggested here are based on fidelity but the key points apply to any approach:

Top of Page    Table of Contents

Choosing a Prototyping Tool

After deciding on a the prototyping approach the prototyping tool must be selected. The goal is to fit the tool to the requirements of the system under development, the skills of the developers, and the needs of the users.  Here is a brief list of prototyping tools starting at the top with the less formal moving down to more formal tools [8, 2].  The links in this list provide one of three things: either information about general use of the tool, information about prototyping use of the tool, or an example of the use of the tool with prototyping. 

• Pencil and paper
• Drawing software
• Demo makers 
• Animation and slide-show software such as Microsoft PowerPoint
• Screen painters, menu builders, report generators
• Perl + Motif  + Tcl/Tk (UNIX)
• CASE tools such as Oracle Designer
• "Visual" RAD tools such as Optima++, Borland Delphi, and Visual Basic
• 4GLs such as FOCUS Six 
• UIMSs (User Interface Management Systems) such as WINTERP  
• Executable specification languages (VDM variants)
• The tool of the final system.

Here are a set of features to be aware of when selecting a prototyping tool. They are derived from a set of requirements for user-interface prototyping [14], but can easily be extended to other parts of a prototyping project.

• Ease of use: good prototyping tools should allow all members to participate in development and refinement of the prototype. Steep learning curves are unacceptable because many of the contributors do not have time to learn the tools. 
• Fast turn-around: in prototyping many small refinements must be made. Tools should allow developers to quickly make changes and quickly see the results.
• Extensive control over prototype features: prototyping tools should be very flexible so developers can try out new ideas. 
• Data collection capabilities: for more complex projects an ideal prototyping tool would be able to capture information about task specifications, system functionality, interface functionality, screen layouts and behavior, design rationale, user feedback, benchmarks, reusable code.
• Executability: the prototype should be as faithful to the real system as developers require to increase reliability of information collected.
• Lifecycle support: prototyping tools can help with all phases of development even beyond systems analysis.
• Team design: should support groups of people working together either simultaneously or asynchronously, or remotely if these are required by the project.
•  Version control: developers may want to explore and evaluate alternative designs. The prototyping tool should allow for version control if it is required by the situation.

Top of Page    Table of Contents

Prototyping within other Methodologies

It should be mentioned that prototyping is not only used as a supplement to the SDLC, but it is also heavily used in Rapid Application Development (RAD) and Object-Oriented methodologies. 

The promise of RAD is "cheaper, faster, better". [16] It strives to achieve that promise through [15]: 

• Gathering requirements using workshops or focus groups 

• Prototyping and early, reiterative user testing of designs

• The re-use of software components  

• A rigidly paced schedule that defers design improvements to the next product version 

• Less formality in reviews and other team communication

Object-Oriented methodologies often use prototyping and are often associated with RAD.  The Information System Consultant's Handbook [2] describes the purpose of object-oriented analysis as finding and describing the business objects and in identifying the relationships between the objects via a conceptual model. Prototyping naturally helps developers and users in finding and describing these business objects and identifying the relationships by giving them a hands-on tools. One of the primary advantages reported of object-oriented development is the increase in productivity because objects and code can be reused. Prototyping and reuse go together because it is easier to prototype if there is a library of reusable classes.

Top of Page    Table of Contents

Conclusion

Prototyping can be a powerful technique in systems analysis. Before deciding to prototype developers must look at the system under development and consider whether prototyping is appropriate. They must weigh the potential benefits against the potential risks. They must consider the people involved in the project, whether they are experienced prototypers or unenthusiastic users. They must consider the prototyping approach, whether illustrative, simulated, functional, evolutionary, or throwaway, vertical, or horizontal, low-fidelity, or high-fidelity, global or local.  They must consider the tools available to them.

Appropriately used in systems analysis, prototyping can lead to improved communication between developers and users. It can provide a process for defining the requirements. It can allow productive work to proceed even while uncertainties remain. It can provide a living specification for the final system. Appropriately used, prototyping can be the difference between success and failure.

Top of Page    Table of Contents   References & Link Summary