Copyright ©1990 - 2005 Touch Technologies, Inc.

Contents

Index

Purpose of this Guide

Intended Audience

The successful software application designer excels in using a minimum of time to develop an application that results in happy end users and programmers.

A designer can use the traditional approach to designing an application or may prefer the prototyping approach.

The traditional approach to designing an application has often resulted in mis-communication between programmers and end users. The traditional approach consists of the following steps:

• Interview the end user
• Design the application
• Write the code
• Test the application
• Sign off

The traditional approach, however, does not provide the end user with a clear picture of the final application during the design process. The end user may be disappointed when the application does not meet expectations. This can result in many changes in design and coding and costly production delays.

Table 1-1 Definitions

Prototype	An interim version or mock-up of the application used to communicate to the end user an idea of what the final application will look like.
Prototyping	The process of making a prototype.
Prototyping tool	A tool that gives the end user a means to visualize the final application in its various stages of development.
Prototyping methodologies	The technical methods used to do prototyping.
Cycle time	The time it takes the designer to implement a change in an application after the change has been requested by the end user.

The prototyping approach allows the designer to use a tool, such as a mock-up. This mock-up is used early in the design process to discuss an application with an end user. The prototyping tool:

• has a very short cycle time.
  
• rapidly gives the end user a deliverable item.
  
• allows the designer to let the user SEE something or FEEL something extremely early in the design process.
  
• facilitates communication between the designer and the end user because what the user sees is exactly what results.
  
• allows changes to be made easily and rapidly.
  
• has crisp code.
  
• quickly pinpoints bugs.
  
• provides instant compiles and link cycles.
  
• avoids scheduling delays.
  
• results in reduced development time with happy users and happy programmers.

Prototyping uses the following steps:

• interview the end user
• design a prototype of the application
• continuous communication between designer and end user
• make changes in prototype
• sign off on each phase of prototype
• coding
• testing
• final sign off

1. Interview the End User
   
   The interview helps determine what the end user wants to accomplish.
   
   End users have difficulty explaining to programmers what they want done and programmers have difficulty understanding what end users want.
   
   End users tend to think of things in terms of file cabinets, drawers and sheets of paper. It is not unusual to have an interview with an end user where the end user is thinking about an 8 1/2" x 11" sheet of paper with all kinds of check boxes on it.
   
   The programmer is thinking about something totally different. The programmer imagines a 24-line screen with a reserve line on the top, two reserve lines on the bottom, and some things reserved in the middle. They are both thinking that they are going to fit something on the first screen. This causes complications later on.
   
   

   Note DESIGNER-END USER COMMUNICATION USING A PROTOTYPING TOOL IS ESSENTIAL EARLY IN THE DESIGNING PHASE.

   
   
2. Design the Prototype of the Application
   
   What you see is what you get.
   
   When designing the application, the designer uses a prototyping tool,such as a report or graph, etc., while interviewing the end user.
   
   Most users don't care what the daily input screen looks like or the processing information looks like, they care about what the output of the system is.
   
   So that the end user has a clear picture of the output, the designer creates, report layouts and mock test data.
   
   

   Note REPORT LAYOUTS SHOULD BE DONE BEFORE ANY CODING IS ATTEMPTED.

   
   
3. Communication Between Designer and End User - Discussion of Prototype Tool
   
   

   Note FLEXIBILITY OF THE PROTOTYPING TOOL RESULTS IN BETTER COMMUNICATION. THIS IS THE NUMBER ONE PURPOSE OF PROTOTYPING TOOLS.

   
   The prototyping tool provides a concrete means by which the designer and the end user can discuss the design of the application.
   
   When there is a meeting between an end user and a programmer, the end user thinks that the programmer knows what is going on. And the programmer thinks the end user knows what is going on. THEY ARE PROBABLY BOTH WRONG! The end user is thinking in terms of sheets of paper, and the programmer is thinking in terms of screens and layout forms.
   
   Words are not enough. End users describing to the programmer what they see in their head is not enough. The prototyping tool allows the user to sit with the programmer and show them exactly what they want the application to accomplish.
   
   For example, when the end user sees a prototype report, he might say, "take this column out, add this description," etc.
   
   The design, interview, signoff can be done all in the same session, with the designer sitting down at a terminal with the end user. This can be done in an office with a screen and a printer. The report is printed out, the end user looks at it, and says, "Yes, this report looks pretty nice, this is what I want to do."
   
   
4. Make Changes in Prototype
   
   Fields can be moved around on the screen; reports can be changed. A lot of mock ups can be done, working rapidly.
   
   Reduced Cycle Time
   
   A prototyping tool also results in a faster cycle time. Typical prototyping tools have a cycle time of UNDER TWO MINUTES. This means that a fairly significant change to the prototype can be made. Within TWO MINUTES, all the reports and screens have been adjusted, instead of waiting DAYS as when writing the application using traditional coding methods.
   
   The user might ask for some changes, e.g., "Could you make the phone number double high so it would be easier to see on the screen?" The programmer says, "Sure," and then SHOWS it to the user on the screen. The user might then say "It looks too thin, could you widen it?" Then when the programmer does that, the user might see that it doesn't fit on the screen, so they want the phone number back to the original way!
   
   That's what communication is about.
   
   
5. Pre-Coding
   
   Pre-coding is coding that is done to produce the prototype or interim version of the final application. There should be a pre-coding phase so that what the end user sees in the prototype is close to the final design of the application.
   
   Pre-coding takes place before any time-consuming hard-core coding is done.
   
   Prototypes can be very, very slow in handling massive amounts of data. End users tend to become impatient when they are slow.
   
   
6. Timed Waits
   
   

   Note PUT TIMED WAITS IN THE PROTOTYPE, OTHERWISE YOU WILL HAVE USER DISSATISFACTION.

   
   Please see Chapter Two for further information on timed waits.
   
   
7. Project Scheduling
   
   Prototyping provides an estimated time of completion. If prototyping is done correctly, changes are determined before the heavy-duty coding starts. This gives you a pretty accurate idea of when a project will be complete. Prototyping plus sign off helps you know a lot before coding starts.
   
   The length of time, for example, a project can be off schedule might be reduced to only a couple of days. (The longest delay TTI has ever experienced on a project is two days on a six-month project. This is because we use both prototyping and sign-off.)
   
   
8. Reduced Development Time
   
   Sign-off results in MUCH-REDUCED DEVELOPMENT TIME. There is less wasted coding time. Sign off avoids all those times when the developer thinks a project is just about done and then the user comes along with a change. If there is NO SIGN OFF, the user does not see this as a change.
   
   They just think they are clarifying something that the designer already agreed to do. This misconception can result in massive amounts of coding changes.
   
   Additional coding changes then require another testing phase, another documentation phase---a lot of wasted time. When a prototyping tool is used, there is much less wasted coding time.
   
   
9. Sign Off on Prototype
   
   The user's approval is indicated by means of a written sign off on the prototype BEFORE the coding starts.
   
   Sign off means that the end user says, "Yes, this is what I want." A sign-off phase causes the end users to share the responsibility for the completion of a phase of the application. This sign off indicates that Phase I has been completed and Phase II has started.
   

   Note IF THERE IS NO SIGN-OFF, END USERS THINK THAT NOTHING IS EVER FINISHED.

   
   Sign off trains users to AGREE to something---they never had to do this before. It works out well to have this agreement.
   
   Example
   
   User satisfaction went up when TTI started doing prototyping and sign off. End users no longer said the developer delayed the project. Instead, they said that the project was delayed due to mutually agreed on specification changes.
   
   The prototype sign-off document says "I have agreed to the following (attached piece of paper)." A screen print out can be attached to the agreement. On it, the user can indicate, "Yes, this is what I want."
   
   This does not mean that the prototype cannot be changed. But, when users ask for a change, you can tell them by how much time the schedule will then be impacted. If they agree to the schedule change, they then sign another piece of paper saying that they understand it will take longer. This way, users take on responsibility for the schedule change.
   
   
10. Testing the Application
    
    It is essential to test the application before giving it to the end user.
    
    TTI has a testing manager. This person gets brownie points for breaking things---to find and report glitches. Programmers tend to want to test only those things that work. Certain user responses at prompts never occur to them, e.g., typing in two commas, five backslashes, etc.
    
    Example
    
    A company in San Diego does a lot of testing for the military. They had a system out on a ship that would crash at 2:00 A.M. every morning. What was happening was that on one person's shift, he would prop his feet up on the keyboard, not realizing that his feet were hitting a key, and at the same time was pushing other buttons. No one had ever tried that before!!
    
    So, the testing phase is really important!
    
    
11. Final Sign Off
    
    This is the final sign off on the REAL application.