The Internet is growing
in importance for all business uses. Electronic
mail is now seen as the most cost effective
and efficient business communication tool
a company can adopt. Communicating on
a local, national and international scale
is within reach of companies big or small.
The Internet is utilized to conduct electronic
commerce, provide customer service, and
for national and global marketing purposes.
Creating custom software is not an easy
task. Many projects fail. Making every
software project a success requires skills
far more subtle and elusive than just
being competent in C, C++ or any specific
technology. We at SOFTPEN have been creating
custom software since 1988. Our highest
priority has always been the practices
and skills needed to make every project
you—needing software first seeks
an off-the-shelf solution. Such software
is usually less expensive than a custom
solution and is low-risk. Often, however,
appropriate off-the-shelf software can't
be found. You are then faced with the
expensive and potentially high-risk option
of custom software. The problem is: how
to minimize the risk?
There is a long list of
practices and policies which, if understood
and followed, can reduce the risks of
creating custom software. Unfortunately,
these practices and policies are very
often understood superficially or not
followed in the "real world".
Our assurance to you—something
which makes SOFTPEN different from many
software developers—is that we are
a low-risk, extremely dependable resource
for custom software because:
* We understand from long
experience how to make every software
project a success
* We rigorously follow the practices and
policies which make this possible
* We hire "the best and the brightest"
Creating excellent, successful
software for each and every client is
principle on which SOFTPEN was built.
Now here are some further
comments about how we look at software
development and how we make sure you get
the best possible results.
Getting what you really need
When we begin a software
project we know your requirements and
your budget are the highest priorities.
But we also know that one's first conceptions
for a piece of software almost never address
your real needs adequately. It's almost
universally true that an understanding
of requirements becomes clearer and more
refined during the creation of the software.
The challenge is: how
to respect this fact, while also respecting
your budget and your original requirements?
How to distinguish between "changes"
which really ought to be made and "feature
creep" which has been the downfall
of many a project?
Being able to manage these
distinctions is one of the skills which
comes from years of successful software
development. Our project managers understand
these issues. And while they are always
vigilant against changes in project scope,
they also are constantly open to ways
the software can meet your needs even
better than originally planned.
Creating software is expensive
even when the development team is very
efficient. And although our first priority
is making your new software perform exactly
as needed, but we know that getting your
money's worth is just as important.
Our development practices
are aimed at giving desired results in
a cost-effective way. Some of these practices
are described below. It's worth noting
that these practices are based on just
a few fundamental principles.
For instance, two of these
principles are "doing things in the
right order" and "making the
state of the project visible" at
all times. While we haven't given these
principles a name, they are behind all
aspects of the development process described
in the next section. For example, requirements
analysis must precede design. Design must
precede implementation. The results of
these stages of development must be intelligibly
documented so that both client and developers
can review, understand, and approve them
before the next stage of development proceeds.
These are two obvious
and familiar principles which should never
be ignored. Unfortunately, these principles
and others often are ignored in varying
degrees, destroying any chance for a project
to be cost-effective.
Below is an overview of
some of our practices, based on principles
which we believe in and which we really
Our development process
First, please realize
this is just a summary. Second, in the
real world, no single development process
is optimal for all software projects.
What is right for a simple Windows business
application would not be appropriate for
a complex n-tier web site. What is adequate
for a small, low-budget project could
be totally insufficient for a mission-critical
application needing to be very maintainable,
reliable, and extensible.
In general, though, this
is our approach to creating custom software:
First comes our initial
understanding of your needs. Based on
this, we write a proposal, creating a
relatively detailed outline of the components
and deliverables for the project. We estimate
person-hours of effort by line-item so
you can see the expected effort and cost
associated with each part of the project.
We never hide behind lump-sum estimates
like "Design: $50,000." We want
you to know from the beginning that we
understand your project well enough to
base our estimate on a detailed project
plan. A clear mutual agreement about the
scope and expected cost of the project
The next step depends
on how fully-defined your requirements
are. In some cases requirements for a
project are well thought out and documented
before we write a proposal. In such cases,
we can proceed directly to a high-level
design. Otherwise, it is usually necessary
to have a requirements analysis phase.
The requirements analysis
identifies the "roles" of different
users of the software and describes their
needs or responsibilities. In describing
the manner in which the software supports
the users' needs and responsibilities,
we identify a set of software components
which comprises the "outputs"
of the system-reports, screen displays,
exported data, etc. Complementing this
set of "outputs" is a set of
"inputs" or sources of data
by which the system acquires the necessary
data for producing the outputs. Following
the flow of information from the set of
"inputs" to the set of "outputs"
makes it relatively easy to see database
requirements in general terms and to identify
major processing components required for
transforming data on its way to the "outputs."
In this way the requirements analysis
leads to a high-level view of the required
system components. It's on this basis
that high-level design can begin.
High-level design usually
has two parts. The first is a description
of system architecture. This is based
on the set of components identified in
the requirements analysis. Of course the
complexity of the architecture varies
considerably, depending on the type of
project. For a simple Windows project,
a description of the implementation language,
database to be used, and third-party components
might suffice. For a web application,
much more would be needed, including a
description of where various components
are hosted, how they communicate, implementation
languages, operating systems, middle-ware
components such as web servers, application
servers, message queues, firewalls, etc.
4. External Design
The second part of high-level
design is sometimes called "external
design." The screens or pages which
make up the user-interface are created
and report formats are laid out. Usually
a prototype is created which allows users
to navigate through the proposed screens.
Specifications are written which incorporate
all the screens, web pages, report layouts
and navigation maps. This documentation
and the prototype provide the basis for
a design review with the client. When
this stage of design is approved, the
functional design begins.
5. Functional design
The functional design
document specifies the detailed behavior
of each screen or web page, and indicates
its relationship to data sources, including
requirements for validation and exception
handling. Report options and data sources
are specified. Business objects are defined
in terms of their functional capabilities,
the information they are able to provide
to the user-interface and to reports,
and their relationship to databases and
other providers or consumers of data.
This document is then reviewed with the
client and must be approved before implementation