What Do You Mean You Can t Install The Product?


What Do You Mean You Can't Install The Product?

Every software project has concerns that are outside the realm of producing code. Sometimes these issues are pushed aside ”we forget about them, or we don't believe that the concerns will develop into problems. During our project, an issue cropped up early and we ignored it. In retrospect, we should have attended to it earlier. The issue was: How does the end user install the software?

The lack of an installation utility didn't seem like a big deal to Gary and Chris. They just needed to build the software. With the required runtime components installed on their computers, the code ran fine. Surely, everyone could load the Java runtime software and the J2EE distribution. Gary wrote a simple script called runPSPTools that started the software. Of course, the software had to be in the same directory as the script, the runtime components had to be installed in the right directories, and a couple of environment variables needed to be set. How hard could that be? After all, each of us was an experienced professional in the software industry, and we were comfortable experimenting with early versions of new tools.

Testers and other quality professionals will quickly recognize what happened . How often do engineers say, "It works on my machine, you must have done something wrong?" This phrase seems to be etched on developers' minds. They use it when someone is unable to get their software working. Gary should know better because he tries as much as possible to act like a naive user when trying out someone else's software. When it came to the installation of the PSP Tools product and the required supporting software, he regressed. He was too close to the software and had difficulty seeing the problem.

Two events occurred that should have given Gary notice that installation wasn't as trivial as he thought. First, he spent over an hour with Liz one day helping her set up her machine so she could run the software and begin testing. Liz reports that even after getting Gary's help, each time she wanted to start the tool, she first had to look up the steps. During part of the project, she realized she was avoiding starting the software because it was too hard to work with.

Next, Jas had trouble getting the software to work when he installed it from the build drop area we set up on Groove. Jas turned to Gary; through a series of chat sessions on Groove and one or two phone calls, he got the software working. Gary knew that he needed to address the installation, but he kept deferring it. These events were just one-time occurrences, so it wasn't really that important.

Actually, it was that important. As soon as we finished the Elaboration phase, more people wanted to try the software. They needed to install it without problems, and we didn't have a satisfactory way for them to do it. Jas worked with people who tried to install the software and gave up in frustration. Jas kept requesting a better installation experience but Gary still deferred the work. Because we weren't ready when potential users wanted to use the software, we missed an opportunity to get early feedback.

Creating a usable installation process actually was very simple, but Gary didn't want to think about it. He wanted to write the code for the product and see the functionality from the critical use cases materialize. Without an acceptable way to install the software, however, prospective users would never get to the use cases. A well-known lesson in software product development is that if a customer, or potential customer, tries your product and fails to use it the first time, you may have lost that customer forever. You certainly have lost the customer's trust and have to work especially hard to get it back and convince him or her to give your product another try.

How could we have avoided this problem? The simplest way would have been to make installing the software a use case in our requirements at the beginning. It isn't clear whether we would have prioritized it as a critical one in our Inception phase, but we would have thought about it and when the need arose, we would have had some idea of how it might work. In Chapter 8, you will see that the problem wasn't hard. In fact, it took Gary less than an hour to produce an acceptable install solution. A lot of damage had been done by that time. Hopefully the potential users will give PSP Tools another try.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net