Microsoft Office Tutorials and References
In Depth Information
Concerning Yourself with the End User
Executing the development effort
After you identify user needs, determine the approach that you’ll take to meet those needs, and
decide on the components that you’ll use for the user interface, it’s time to get down to the
nittygritty and start creating the application. This step, of course, comprises a great deal of the total
time that you spend on a particular project.
How you go about developing the application depends on your own personal style and the
nature of the application. Except for simple fill-in-the-blanks template workbooks, your
application will probably use macros. Developing the macros is the tough part. Creating macros in Excel
is easy, but creating good macros is difficult.
Concerning Yourself with the End User
In this section, I discuss the important development issues that surface as your application becomes
more and more workable and as the time to package and distribute your work grows nearer.
Testing the application
How many times have you used a commercial software application, only to have it bomb out on
you at a crucial moment? Most likely, the problem was caused by insufficient testing that didn’t
catch all the bugs. All nontrivial software has bugs, but in the best software, the bugs are simply
more obscure. As you’ll see, you sometimes must work around the bugs in Excel to get your
application to perform properly.
After you create your application, you need to test it. Testing is one of the most crucial steps; it’s
not uncommon to spend as much time testing and debugging an application as you did creating
the application in the first place. Actually, you should be doing a great deal of testing during the
development phase. After all, whether you’re writing a VBA routine or creating formulas in a
worksheet, you want to make sure that the application is working the way it’s supposed to work.
Like standard compiled applications, spreadsheet applications that you develop are prone to
bugs. A bug can be defined as (1) something that does happen but shouldn’t happen while a
program (or application) is running, or (2) something that doesn’t happen when it should happen.
Both species of bugs are equally nasty, and you should plan on devoting a good portion of your
development time to testing the application under all reasonable conditions and fixing any
problems that you find. In some cases, unfortunately, the problems aren’t entirely your fault. Excel,
too, has its problems (see the “Bugs? In Excel?” sidebar).
I probably don’t need to tell you to thoroughly test any spreadsheet application that you develop
for others. And depending on its eventual audience, you may want to make your application
bulletproof. In other words, try to anticipate all the errors and screw-ups that could possibly occur
and make concerted efforts to avoid them — or, at least, to handle them gracefully. This foresight
not only helps the end user but also makes it easier on you and protects your reputation. Also
consider using beta testing; your end users are likely candidates because they’re the ones who
will be using your product. (See the upcoming sidebar “What about beta testing?”)
Search JabSto ::

Custom Search