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 successful.

Usually someone—like 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 the fundamental
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.

Getting cost-effective results

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 do follow.

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:

1. Proposal

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 is essential.

2. Requirements

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.

3. Architecture

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 proceeds.

6. Implementation