| Previous | Contents | Index |
When you use prototyping methodologies, you end up with happy users. Users can see that what they signed off on is exactly what they get.
Another benefit of prototyping is HAPPY PROGRAMMERS! Programmers like to know that the end users appreciate what they did. When our TTI programmers have completed a project and the users have accepted it, it's really great to have something signed off.
This reduces friction between programmers and users, when nothing is ever done. Some meetings contribute to a sense of frustration. Someone asks what the developer is working on and find that a year later the same thing is being worked on. Users can't make up their minds and don't know what they want.
Many people lack visual skills---they can't picture things clearly in their minds. They don't think that way. A lot of users and programmers are not visual. It's much better to show users a prototype---something they can actually look at on the screen.
People like to TOUCH AND FEEL things. E.g., handouts to go along with a talk makes understanding easier. A terminal in front of each listener would be even more effective. It makes things more real. PRINT IT OUT FOR THEM and put it into their hands immediately! This way they can mark changes on the paper.
So, prototyping tools allow you to rapidly get to the point that you have a deliverable item, eg., a report---something they can touch and feel.
Also, users always know what they DON'T want. "Do you want it like this?" "NO!" They don't know what they want or don't want until they see it. That's how end users are.
End users measure success by what they can touch and feel. They view success by the data entry and query screens and by reports. That's what you use your prototyping systems for. TTI has found that it is not particularly useful to spend a lot of time working with the end user to design a batch process that runs overnight that you don't see. The users really don't care how it works as long as it's done by 7:00 or 8:00 in the morning.
Users want the RESULTS of the system. They didn't design the system so they could do data input---they designed the system so they could get results---analysis results, summary results, queries.
It is important that the designer choose a prototyping tool that allows response time delays (timed waits). These timed waits should be put into the prototype so that the end users experience from the beginning the timed waits that they will experience in the final application.
Suppose a whole system is designed for end users with report data input screens. The programmer says, "Let's go through this, we think we have it the way you want it." The end users look at it and see the year-to-date report is what they want, and they sign off.
Three months later the coding and testing is done. The end users get the final application that is no longer using a little data file with 150 customers. The data file now has 150,000 customers! The final application looks remarkably similar to the one that was prototyped. But, this new report may now take 40 seconds to produce instead of three and the users want the old report back! The users wonder what the designer has been doing for three months!
Projections should take into consideration the amount of data there is---and you should know some of these data rates if you are designing the system. If your projections are that it is going to take a minute and a half for the application to do a certain kind of report, put a minute and a half timed wait in the report!
The end users see the prototype of the report sit there for a minute and a half, and may ask, "What's it doing?" You can say, "Let me put something on the screen so you can see what it's doing. It takes about a minute and a half for it to go through all the data." The users get used to seeing what the timed wait is going to be.
It also may turn out that a minute and a half is not acceptable to them for what they need to do.
TTI had a customer that was involved in installing phone systems. One of their systems had a request for a phone installation. The response time, from the initial request to getting a screen up was TEN MINUTES on the real system. If that timed wait had been made clear ahead of time, the customer would not have agreed to sign off on the original system.
Why did it take ten minutes? Because the customer wanted a million different pieces of information. Over thirty files of data had been collected and displayed on the screen. They might have opted instead not to show so much data on the one screen and do a thirty-SECOND version instead.
Reduced cycle time allows coding to remain crisp. Otherwise, when the project slows down, the programmers start dragging and their code shows it. Earlier coding is nice and crisp and lined up with good comments. A year later the coding is kind of hap hazard. There has been a lot of cutting and pasting; the programmer hasn't changed the comments on the top to match the coding. This results in a major mess!
Prototyping results in HAPPY PROGRAMMERS, because they experience success right away.
When the prototype is well done, the programmer can write the rest of the code without having to talk to the end user.
Collection of data for reports is critical.
Suppose end users want to know the number of hours logged per support call and they consider this to be a critical item on the report. In the interview, you ask, "Where does that data come from?" They answer, "We don't collect that data currently." You say, "If you want it on the report, you are going to have to collect the data."
It doesn't occur to them that if they want the results, they need to collect the data. If they were to collect this number of hours, what kind of forms would they have? Let's get some forms designed to show us the data.
TTI has been working with some colleges for a number of years and there is a tendency for the management levels of the colleges and universities to want all kinds of analysis---ten years, fifteen years back. But they haven't been collecting the data for more than three years! They have to understand that; otherwise, they might be very disappointed when they get the final report.
You promised REPORTS, not data collection. You don't want to have an argument with the end users at the end of the system, you want to have that discussion when you are looking at the data elements on the interim reports.
TTI has a bank customer that had some nifty little reports that looked stunning---they went all the way to 132 columns. All of a sudden they decided to change from dollars to yen. If the report had not been done first, they would not have known there was a problem. They thought they had asked for a simple conversion, not realizing that the change had impact all across the system! This change included the data input display screens (a ten-position field for the money) and now they want yen! Rounding to the nearest million yen might not be acceptable to them.
Almost all prototyping tools do instant compiles. This means that when the programmer types in the new line of code, that code is immediately syntaxed, checked, compiled, live and running--- INSTANTLY!
Small errors (missing parentheses, etc.) are found out as soon as the return key is pressed. The errors can be fixed immediately in the editor.
BUGS take a lot less time to track down. Most prototyping tools have very high-level language statements like SORT, SELECT, and involve relations, etc. This is a part of the language construct. This does not involve writing a lot of code. A simple statement implies many things happening on the screen.
What programs run perfectly the first time, with no glitches? Most often they are the ones reduced to a single line of code. E.g., PRINT "Hello." RUN "Hello." The more code you have, the worse off you are.
It has been shown that there are usually only fifteen to twenty lines of code per day that are tested perfect, running. But that code today does much more than it used to years ago. E.g., open a window, bring up a menu with bars on it, get the input and process this routine is now fifteen lines of code. That used to take 1,000 to 10,000 lines of code.
THE LESS CODE YOU HAVE, THE FEWER ERRORS YOU HAVE. |
END USERS and PROGRAMMERS NEED QUICK RESULTS. If it takes your programmer four days to try the next iteration of the code, they are not going to be successful---they need quick results. They don't like things dragging on for a long time.
A project that runs on too long disheartens the programmers because it takes too long to see results. What does the project actually DO so far?
A rapid prototyping tool keeps the measurement of project completion easy and simple because you can break things into small deliverables for the end user. Even on a major project, every six weeks you can have something that is absolutely complete. Prototyping gets done at the prototyping interview---but at end of six weeks is something FUNCTIONAL that has an end user TOUCH FEEL thing attached to it.
A programmer's job is to program. This is not to be confused with an end user programmer,e.g., an accountant who likes doing things with your prototyping tool.
Prototyping reduces project man-hours. The number one reason for increased manhours is WASTED TIME, e.g., designing something that the end user didn't quite understand. Prototyping tools have an incredibly fast cycle time (on one of TTI's projects, INTOUCH, Something new could be seen every three seconds.)
This results in increased satisfaction for programmers because they can see measurable and appreciated results. They like to be able to say they have finished several projects.
IDEALLY, YOU SHOULD HAVE A SOFTWARE APPLICATION WHERE ALL ASPECTS CAN BE PROTOTYPED. |
Not only reports, but ALL aspects of the project can be prototyped. E.g., all data input, analysis, batch processing. All the multiple users, and live data sizes can be handled.
TTI has its programmers, at least once for each project, make a data file that is the size of the final data files. These are files that the end user is going to have within the next couple of years. In that way, the user can see what the project is like.
| Previous | Next | Contents | Index |