Application Development Models

The Simply Bits Enterprise Services (SBES) application development team has worked on development projects using the following standard development models. Each model is a slightly different approach to software development, and each has its own advantages and disadvantages. These models should not be confused with our project lifecycle, which we apply to all development models.

Waterfall Projects

The basis behind developing a project on a traditional "waterfall" model with a fixed bid is that the time spent upfront on a project in the requirements, specification and design phases will yield a complete understanding of the project and setup a development phase with less problems and bugs due to errors in design. Ultimately, the goal is to spend more time upfront and work down the correct path rather than discovering later in the project lifecycle that a project is missing important elements and having to redevelop parts of the system.

A fixed bid is done upfront and is based on the requirements, specifications, and sometimes the design, of a project. These pieces are typically, in themselves, paid exercises to complete, but they account for only a fraction of the total project cost. Because time is spent upfront on the planning and design of a system, the remaining costs for the project (development, support, and warranty) can be properly determined upfront before any code is actually written.

Why Work Waterfall? Predictability.

Doing fixed bid work allows the cost and schedule of the project to be predicted upfront. As a solution is being developed, you have little freedom to make changes in direction or adjustments to the requirements of the project, so an accurate vision and detailed review of the requirements and specification are important. Still, some changes can be made through change orders to projects to account for unforeseen changes or requirements. We find that waterfall projects yield better formal documentation and conform better to the budgetary planning requirements of companies, but they are also more expensive than projects based on other models. Waterfall model projects can produce a product that was “what we thought we wanted” but not what was needed in the end.

Agile Projects

Agile work is done in short sprints of effort at the discretion and priority of the client. Typically, each sprint is a two or four-week period wherein a predefined objective is completed. At the end of each sprint, anything completed is delivered to the client for review. Usually, the first step of an agile project is to setup a general overall plan and start on a core framework as more specific pieces are defined. Each subsequent sprint then builds upon the last, adding new features and functionality until the project is complete.

With each sprint, SBES gives a base design of the work to be done, an estimate of how long the work will take and a tentative schedule. The end-cost of an agile project is not known upfront. Work is usually done on an hourly basis with estimated totals for each sprint.

Why Work Agile? Flexibility.

Work based upon an agile model allows your project to be flexible. Once an agile project is underway, there is more transparency for the client through many delivery points, and more freedom to change direction, adjust requirements, or even stop development. Although sometimes more difficult to fit into budgetary planning for companies, agile development tends to deliver solutions that better meet the client’s needs in the end Agile development is also cheaper that other models.

Hourly Projects

Hourly work is done at the discretion and priority of the client. Under an hourly agreement, all activity is purely at the discretion of the client. With each request, SBES typically gives an estimate on how long the work will take, and before we begin any work effort, we agree on a tentative schedule. In most cases, this estimate will be accurate. However, in some cases the work will be less, and in some it will be more.

Fixed bid projects are specked out and priced. Included in a fixed bid is a percentage to cover the expected time for management, support and warranty. In contrast, hourly work is always done completely on hourly bases and does not include any management, support or warranty time. As a result the final price of an hourly project is never known upfront.

Why work hourly? Speed.

Doing work on an hourly basis allows your project to move along quickly. This is especially useful for small projects or simple consulting arrangements. As requests are received, they are reviewed and assigned to a developer. The developer completes the request and only productive time spent is billed. As a result, the turnaround time on requests is much faster than other methods. Also, since only the actual time spent on the task is billed, you never pay more than the actual effort needed to perform a task.