- A Client's Responsibilities
This document outlines what
you can expect as a Client of Maxtech Solutions Concept when
the company is creating a program for you. It is very
important that you understand that, unless otherwise agreed
to beforehand, you will need to devote many hours of
your time in order to get the most of your program.
If you are not involved in the program creation, you will
receive the program we decide to build, which is likely not
what you wanted in the first place. Please review this
document and ensure you understand everything in it. During
the entire process, starting now, when in doubt, ask.
Solutions Concept follows standard procedures of program
creation. These procedures are not just customs, but are
practices that have been developed over the years to ensure
the final product is the one the customer requested.
that surprises many clients is that the actual act of
writing the program, called coding, is a very minor
part of program creation. The rule of thumb is that the more
time that is spent "up front", documenting what the program
does, the less time will be required to modify the program
after it is written.
Accordingly, the following list outlines the steps commonly
used to create a program.
Create the Problem Definition
This is a document written in a weird mixture of English
and Computer, but even so, you must understand
everything about it. This is the document the programmer
will follow when creating the following steps, and
ambiguities will lead to failure. Ambiguities pop up any
time people converse in different languages, and
programming is a language all to itself. Do not allow
the programmer to gloss over anything, do not fail to
understand everything and have the document
modified to show this understanding. This
document is the Bible when it comes to your program, and
minor changes to it at a later date can cause a cascade
effect throughout the remainder of the project,
resulting in a project that is over budget and late.
Your programmer/analyst should cover this document, in
detail, and refuse to proceed to the next step until it
is complete and agreed to by all. You and the
programming team lead should sign this document before
any further work is done, and before a final bid is
given and accepted for the time and money required for
Define the Data Structures
Your project may or may not require data structures. A
simple web site will, of course, not require any data
structures. But a full blown database/cgi program will.
As an example, an online address book must include all
fields you want stored, ie all information you want to
store and retrieve. Do you want to know a birthday for
each entry? Are we talking only about Nigerianís
contacts, or do we need to be set up for International
addresses. This definition is required for any project
that will store/retrieve information.
Sketches of all screens should occur here. Prototype
screens could also be created, to be used in the
following steps. If data structures were defined in the
previous steps, display information for all data visible
from the data structure should be included. At this
point, our problem definition should be showing its
effectiveness since the flow of the project will have
been defined there, resulting in a simple list of
screens that must be created.
Define Program Flow
How do we get from Screen 1 to Screen 2 above? What
actions need to be taken (defined in the Project
Definition) for each screen to move to subsequent
In Projects requiring data structures, there are reports
that need to be created. Do you need to know how many
people have signed up for your new service? At this
point, the information from the Data Structure
Definition and Screen Definitions above should be
combined to give the actual definition of report
creation. All of the following questions should be
do you want the reports sorted?
What information should be on each report.
do you want to limit the amount of information
what format do you want the information displayed.
Build Data Structures
At this point, the programmer actually creates the data
structure and delivers a representation of it to you.
There is no reason for you to understand every nuance of
this representation so long as the data structure was
defined well in step 2) above.
Populate Test Data
You should assist the programmer in creating test data
to populate the data structures created. Enough
information should be manually placed into the data
structures for testing by the programmer during the
At this point, the screen designer takes the sketches
created in Define Screens and makes them a
(possibly non-functional) reality. The first screen will
define the "look and feel" of the application, and even
the smallest detail should be exactly to your
specifications before any additional screens are
created. Colors, general layout, and the overall
usability of the screen should be looked at carefully.
Once approved, the following screens can be created and
you should review each, in detail.
The programmer now writes the "glue" that puts the
The programmer has already tested the project, correct?
The worst person to test any program, web site, or any
project, is the person who created it. At this
point, someone other than the programmer must test it.
The programmer has tested it (a process called alpha
testing) when they wrote it. But, with very few
exceptions, a programmer is a programmer. The programmer
does not know how you will use the program, and they can
not be expected to see outside the box long enough to
give a good test. They have been working on this project
for a while, and have pre-conceived ideas about how it
will work. As an example, a programmer would be unlikely
to put AAAAA in a age field. Why should they? It is for
In this stage, called beta testing, the program
must be tested by others. Each beta tester should have a
copy of the Problem Definition and use it to test the
program. Good beta testers fall into one of the
Getting another programmer to test a project is
great, as experienced programmers know many common
flaws that occur in programs.
There are many people who test programs for a
living. They sometimes have automated tools that
assist them, and the more experienced have knowledge
of many types of bugs that creep into programs.
Get as many end-users of the program to test as
possible. There is no substitute for end user
beta testing. Each user should actively
attempt to break the program. An incentive program
for the end-user who finds the most bugs, or who
offers the most suggestions that are implemented is
a great way to find (and fix) deficiencies before
Computer Illiterate Individuals
This is the class of people that tend to find the
most usability errors. Something that might be
intuitive to an end user who has been using a
similar program for years might be totally
unintelligible to your target audience if they will
contain people who do not use computers much (or at
Professional Testers and
programmers have a good idea of how to test a program, but
normal end users do not. Following are some guidelines to be
used when testing the program at this point. You should
ensure that each tester has the following list and
understands each of the points.
Test Every Link, Button or Action
Every time, each time, test every link, button,
action in the entire program. Even if the programmer
has only made one small change, those changes
sometimes have cascade effects throughout the
program that will fix one problem while breaking
something else. Test everything, every time you are
asked to test the program.
incorrect information in fields
What happens if you put 234.01.7619400 as a phone
number? Does the program understand using periods to
separate the parts of a phone number? Should we be
able to place International numbers in this field.
What happens if we put a -1 in a quantity field? Or
0. Or 9,999,999. Can we put control characters into
fields? Try to break the program. It is better to
break the program now than later, when it might be a
mission critical application that will cost money
and time to repair.
Leave required fields blank, or duplicate existing
If an important information is required at some
point, what happens if it is left out. Or, if you
have a customer ID that must be unique amongst all
of the data you store, what happens if you
successfully duplicate that customer ID.
At this point, if all of the above were carried out, the
program is ready to be used. It should be delivered with
documentation (created while the programmer worked on
the system and during testing).
point to be made. I reiterate that the Problem Definition is
the Bible of the project. Adding or modifying the Problem
Definition after it is approved has many negative effects
that will result in a poorer deliverable that costs more and
is delivered late. The effects result from the following.
Even a minor change to the problem definition at the end
of the project can cause a rippling cascade of changes
to the project as a whole. As an example, lets say we
forgot to include a birthday field in an address book; a
Now the programmer must add the field to the database,
then find all screens that use the field and modify
them. The coding now must be modified to ensure the
birthday field is populated and validated correctly. On
a large project, the programmer may have to go through
hundreds of screens and thousands of lines of code to
determine where to modify the project to make this one
simple change. Then, all documentation must be updated
and, since the project has been modified, the entire
beta test phase must be restarted from scratch. On a
simple project, adding this item may have resulted in 1
or 2 additional hours of work (most likely, less than an
hour overall), but if added at the end of the project,
it could result in tens of hours of code rewrite, screen
modifications, documentation modifications and testing.
Programmers tend to be very task oriented, linear
thinkers. Once they get their minds around a project,
they tend to see a clear path to the end and proceed
from Point A to Point B in a very structured manner. Any
intrusion that causes them to deviate from this path is
frustrating as it clouds the path. In extreme cases,
where many changes are introduced over the course of a
project, it can result in a total disorientation by the
programmers involved resulting in a project that they,
and you, feel will never be completed.
What is the solution?
Determine if the change is required in this release. Most
projects do not end once it is delivered. Many enhancements
are found that would make a project better, easier to use,
or gather and disperse information in more easily
recognizable manner. For these items, create a list of
enhancements for inclusion in future modifications. How to
differentiate is one of the most difficult parts of a
project manager, but a good rule of thumb is: will the
resulting project be unusable without the modification in
question. If a report gives incorrect information, then it
must be fixed before use. However, if the same report would
be easier to understand if delivered graphically instead of
textually, then this is a good candidate for modification
after the project is released and in use. Remember,
each modification made results in more out of pocket money
and more time spent before you can