In
the Beginning...
An
application begins with a need. There's a need for faster, easier, more
accurate tracking of financial information; presto, a spreadsheet application
is born. There's a need to send letters over the internet; presto, an
email application is born. You get the idea. The
customers of applications developers tend to have pretty specific ideas
about everything from what the application should do to how it should
look, but while they definitely know what they want, they don't often
know what they need.
For
instance, a customer may ask for an application that will read data
from one database, allow end-users to edit that data, and then export
the edited data to a second database. The need that caused the customer
to make this request is much simpler: he needs to get data out of one
database and into another, but the second database requires different
data formatting than the first. He
has assumed that the only way to reformat the data is to provide a middle-man
application that allows users to manually edit the data. In all likelihood,
an automated script can do the whole job for him, and there's not really
any need to create a full-featured application at all.
Beware
your customers' assumptions. When your customer speaks in explicit detail
about how he wants screens to look, how he wants data to be formatted,
and what tools he wants you to use to build the application, you can
be certain he has made a lot of assumptions and at least some of them
are false. Consider the following table.
| The
customer says she wants: |
But
what she actually NEEDS is: |
| a
spreadsheet |
a
means to group data and perform calculations on that data |
| an
asp web application |
a
means to display static data pulled from a database on the company
intranet |
| a
personnel database |
a
means to automatically generate organization charts |
| a
javascript |
a
means to provide real-time status of orders on the company's world
wide web site |
Notice
how much flexibility is introduced when WANTS are converted to NEEDS.
With the exception of applications built with an eye to intensive maintenance
by a pre-selected team with a pre-determined skillset, no one ever NEEDS
a specific application written in a specific language; needs are almost
always more general than that. People often NEED to get data up on an
intranet or the world wide web, but asp isn't the only way to accomplish
that goal. Similarly, people often NEED to be able to perform calculations
on data, but that doesn't mean that a spreadsheet is the only, or best,
way to accomplish that goal.
As
you go through each of the phases of application development, focus
on NEEDS, not WANTS. Be open minded; don't be too quick to assume you
understand the customer's needs. If the customer says he wants a certain
feature, ask why. Ask what that feature will do for the customer, how
it will make his work easier. Too often the customer asks for a feature
because he doesn't understand that the need beneath his request can
be met in a better or more efficient way. If he's asking for printed
reports, ask what will be done with those reports; if they will be packaged
and mailed to satellite offices, maybe an automated email of electronic
copies is a better idea. If the customer is asking for a direct interface
to his mail client, maybe all he actually needs is a way to generate
an email from within your application and send that email to his email
client without having to start an email client session. Ask questions
and get details every step of the way because it can only give you more
options in the long run.
Back
to Top
Requirements
Phase
The
requirements phase is the first phase of application development. This
phase is covered in more detail in the Thinkydink
Guide to Requirements Documents. Please also see the Thinkydink
Guide to Process Flows, as building process flows is a critical step
in the Requirements Phase.
Back
to Top
Design
Phase
In
the design phase, you take your requirements document and process flows
and use them to translate the required process into a solution. There
are entire books written on this subject alone and I won't try to go
into that level of depth here. Instead, I'll provide some basic, but
key, design principles.
Don't
Forget Human Factors - think like a user, and think like the least
knowledgeable user who could possibly be asked to use your application.
It may be obvious to you that clicking the little 'x' in the upper right
hand corner of any Windows-type application will close the application,
but it will not be apparent to every user so give them a "Close"
or "Exit" button. You may think it's sensible to assume that
users will log off of your secured application every time they're done
working with it, but human nature is to be lazy and just leave the application
open and running all day long. If it's important that users log off
after a period of inactivity, set a timeout variable. In all things,
make it simple and make it obvious.
Keep
the Interface Clean - fewer fields on more screens is far preferable
to fewer screens with more fields. Your screens must be easy to read
and easy to navigate.
Keep
the Interface Intuitive - does your application use the Tab key
to navigate from screen to screen even though users are likely to assume
that the Tab key will navigate from field to field on the current screen?
Are you using graphics instead of words on your function buttons, and
if so, are the meanings of those pictures completely obvious to an uneducated
onlooker? A backward-pointing arrow may seem like the obvious choice
for "Undo" from your perspective, but don't assume the user
will agree.
A
Forgiving Application is an Appreciated Application - are users
given a way to undo their most recent changes, or to recover a deleted
record? What happens if the computer shuts down while your application
is running---are all changes lost, are records left in a locked state,
or could the database be corrupted? Do your screens prompt for required
data as soon as the user enters a required field, or does it wait until
the user clicks a "Save" button? Does the screen blank out
all data fields when a save error occurs, or does it retain the most
recently entered values until the record is either saved, undone or
deleted? If you were the user, which would you prefer?
See
the Thinkydink Guide to Software Design Documents
for full details on how to document your design.
Back
to Top
Prototype
Phase
Once
you have your design worked out in the form of flow charts, sample screens
and the like, it's time to create a prototype to take back to your customer.
The prototype should demonstrate some of the functions the customer
has requested, and should clearly demonstrate how the application will
look. The prototype doesn't have to be a complete and completely functional
application in and of itself, but it should give the customer a good
idea of what the finished application will be like.
Use
dummy data, and use data that will conveniently provide the results
you want to show the customer; of course the finished application will
handle errors in a variety of custom ways, but for prototype purposes
you only need to show that the application will handle errors and a
single example of the type of response a user will get when she encounters
an error.
You
may be tempted to skip this phase, but don't. It's far better to find
out that you and your customer have widely varying ideas about what
you should be building at this early phase than to find out when you
roll out the finished, live application. Typically, the presentation
of your prototype will be an occasion for gathering more requirements
because once the customer sees what you're proposing, he will invariably
remember other requirements that he failed to mention during the requirements
gathering phase.
Prototyping
can be done with any of a number of tools, but it's not usually very
efficient to prototype with the tools and languages you will be using
to build the real application. It could take weeks to build a prototype
web site in HTML and java, but you can approximate the look and feel
in a Power Point presentation with embedded hyperlinks within a matter
of days. Access is often a great tool to use for quick-and-dirty prototyping
of Visual Basic or C++ applications. Think of your prototype like a
movie set; it should look great, but it's just a facade and most of
the action is simulated.
Back
to Top
Design
Modification Phase
Once
your customer has seen your prototype, you will undoubtedly have to
modify your design to some degree. Don't just make hand-written notes
or jot some stuff into your Palm Pilot. Take the time to edit your documentation.
Revise your requirements document, SWDD and process flows, and if your
customer has previously signed off on any of these documents, be sure
that they sign off on the revised copies.
It's
important to revise your documentation because if there are any dependencies
that will be impacted by your design changes, they will be readily apparent
in your documentation and will jump right out at you. No one can be
expected to have every detail of his or her application design committed
to memory, and you don't want to be knee-deep in code before you realize
that a requirement change has had a horrible ripple effect.
Back
to Top
Build
Phase
The
build phase is pretty self-explanatory; this is where you do the actual
coding and data conversion to create your application. What's important
to remember about this phase:
Copy
the Customer's Configuration -
have at least one PC on hand that's configured to be identical to your
customer's machines in every way. Make sure it's running the same operating
system, has the same amount of disk space and RAM, has the same drivers
and DLLs loaded, and has all the same programs that will run alongside
your application installed. If your application is going to conflict
with the customer's typical setup, you want to know about it as soon
as possible so you can resolve each issue as it arises.
Comment
Your Code As You Go - never plan to go back and insert comments
at the end, because you will find that you haven't allowed enough time
to do it at the end and that you can't remember what you were thinking
when you wrote a certain module weeks after the fact.
Edit
Your Documentation As You Go - if there is a requirement or design
change during the Build phase, revise your documentation immediately.
First, as with commenting code, there's never enough time to do this
after the fact. Second, you will need to refer to your documentation
as you work so it should always reflect the most recent and accurate
information.
Test
As You Go - test each newly built element as you finish building
it, and test on the customer configuration machine. The official Test
Phase is intended to test the overall application, but if there's an
auto-update field that doesn't update or a drop-down list that doesn't
drop down, you should've known about it and fixed it far in advance
of the Test Phase.
Back
to Top
Training
Phase
While
training is not truly a component of application development, most users
will require some level of training before even the most simple, intuitive
application in the world is rolled out to them. Training may occur before
or after the Test Phase, but I bring it in here because your user acceptance
testers will have to be trained to some degree just to complete their
testing of your application.
Training
may be a simple orientation in the form of a slide show users can view
at their leisure, or it may be a fully developed class with printed
training materials. Typically the customer will dictate how much training
is required, and you and the customer will agree in your Requirements
Document on the matters of who will give the training and what kind
of training will be given. No matter how much or how little training
users will get, be certain your application has a robust online help
system. All too often, an initial training is given to the first group
of users and then future users and new employees are trained by existing
employees in an informal fashion. In a well-designed application, training
requirements should be minimal.
Back
to Top
Test
Phase
Start
with a plan. Use a spreadsheet or database to create and store as many
different possible record and process scenarios as you can, then provide
spaces for the user to answer questions about how the application responded
to program triggers. Was
the record saved? Did the calculation run correctly? Was the automatic
email notice sent? If the application
is going to perform calculations, provide users with a means to audit
the calculation result---give them the information they need to double-check
the calculation via a ten key calculator or a spreadsheet.
Be
sure that your test plan includes every POSSIBLE scenario, and not just
every LIKELY scenario. The goal of your test plan is to expose flaws
in your design before the customer finds them. Be ruthless in trying
to "break" the application. Click the buttons you're not supposed
to click, backtrack through the required fields and delete some of them,
shut down your computer in the middle of a calculation or record save
operation. Pretend you're a new user with no training and see if you
can't get the application to fail in some way. Ask an associate who's
completely unfamiliar with your application to test for you; he or she
will certainly think of things to try that you would never consider.
Remember,
it's a good thing to find flaws now because no application is ever perfect
in its first release and if there have to be bugs, YOU should be the
one to find them. Once your test is over and you're confident you've
uncovered and corrected all the bugs in your application, it's time
for user acceptance testing. You can create the test plan or the customer
may want to create his own, but either way be sure that your user community
has an opportunity to test drive your application and sign off on it
before you release it. As with just about every other phase, it's likely
that the testers will raise issues and additional requirements that
haven't been brought to your attention previously. This late in the
game it makes sense to put any new requirements into a future enhancement
release, but it's certainly not unheard-of to find some critical flaw
during user acceptance testing and realize you need to go back to the
Design Modification phase and then re-do all of your testing.
Back
to Top
Release
Phase
The
release phase is the "go-live" period for your application.
A trial run on a small user group should be performed before a full-scale
rollout, and that user group should be one that would suffer the least
negative impact if there's any problem with the roll-out. You've done
all you can to be sure your application will play nice with the customer's
computer systems, but there's no way to predict what will happen when
you get your application up and running on the real, live system.
Assuming
your trial run was a success and you've resolved any issues that came
up, you can begin rolling your application out to the remainder of the
user group. If the user group is very large, it may make sense to break
them up into smaller groups and roll your application out to one group
at a time. If everyone will need access to the new application immediately,
you don't have the luxury of a gradual roll-out and should be prepared
to deal with any problems that arise when the whole user group goes
live.
Support
during this time is critical---don't leave your user group out in the
cold, no matter how certain you are that the application is flawless,
self-explanatory and easy to use. Be on site and have all your resources
available to answer questions and do mini, on-the-spot training sessions.
Be ready with quick reference cards, hand outs and any other materials
you can provide to make the go-live process as smooth and stress-free
as possible for the end users. Even if it turns out that your go-live
is so easy that no one ends up needing you, the customer will appreciate
that you were there and you were prepared, and that customer will think
of you the next time he wants a new application built.
Back
to Top
A
Word About Documentation...
Actually,
I have three words for you about documentation. They are: necessary,
important and smart. As I've indicated over and over again
all over this site, documentation is not an afterthought and documentation
is not optional. Documentation will save your hide, point you in the
right direction, clarify your thought process and make life a whole
lot easier for the software developers who inherit your applications.
Documentation
is part of the product you are expected to deliver to your customer.
Would you be satisfied with an off-the-shelf piece of software that
came with no user guide, installation instructions or support contact
information? Why should your customer expect anything less from you
and your application? Failure to provide complete and accurate documentation
is unfortunately typical among software developers, but customers expect
you to meet this requirement whether it's spelled out explicitly or
not. Repeat business doesn't come to those who annoy their customers,
and except for an application that's late, runs substantially over budget
or doesn't work, nothing's more annoying than a lack of documentation.
Take the time and do your job right; it really does pay dividends in
the long run.
Back
to Top
