Consulting, why us!

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

Implementation begins, often using the strategy of first implementing a small, operational, core version of the system to which additional components can be added as they are completed. This allows certain technical risks to be addressed early, before the entire system is implemented. It also allows operational "rough edges" to be smoothed out early, before the final system is completed. Sometimes a small "vertical slice" proof-of-concept prototype is created very early in the project, during the external design phase, to insure that all components of the architecture function together correctly. In complex systems this reduces the risk that detailed design and implementation may be based on invalid technical assumptions.