Design.

Code and unit testing. Subsequent testing. System testing.

There are three main types of waterfall methodologies to consider when assigned a project. These three waterfall approaches depend entirely on a projects target date. These categories are:

No overlap. This is a purely sequential waterfall methodology where no phases overlap. Phases are completed before another phase starts. Usually, deliverables such as phase sign-offs and reviews are indicators of such a methodology.

One phase overlap. Adjacent phases are allowed to overlap by one phase only. This kind of overlapping often happens on a waterfall project.

Overlapping phases. Extensive overlap is present, with each phase overlapping the other. It does prove substantially more difficult to coordinate the deliverables and tasks and requires a competent project manager with the appropriate experience to undertake such an approach. If you run into trouble here, it is difficult to get back on track and requires rescheduling.

The disadvantage of the waterfall methodology in general is that it can be largely documentation-driven, which consumes time. The waterfall methodology makes it easier on the project manager and difficult on the client. For example, in a typical construction project, the specifications are usually detailed and take considerable time to complete. The first time a client actually sees the finished product is when the product has been built. (However, in construction, CAD software can simulate large projects.) Thus, if the client has changes, it is either usually too late or the changes are too complex.

Benefits of a Waterfall Methodology

The following are benefits of a waterfall approach:

It provides phase-by-phase checkpoints for the project.

You may need to proceed to only the following phase after the previous phase has been completed.

It can also be applied to an iterative approach (see Figure 4.8).

Figure 4.8: Incremental Iterations applied to a waterfall approach. Iteration #1 addresses the greatest risks. Each Iteration produces an executable release, providing more functionality as the iterations develop. Each Iteration must be tested for quality and integration.

Disadvantages of a Waterfall Methodology

Disadvantages of a waterfall approach include:

There is minimal feedback between project phases.

You start seeing results only later in the life cycle.

Each phase is tracked with far too many hard dates and milestones.

PREVIOUS NEXT

The Open Source Methodology

The concept of open-source software development has only recently gained popularity as a radical approach to developing projects. Two classic examples the Linux Operating System and Netscapes Web browser were driven largely because of the rise of the Internet, which proved itself as being an effective communication medium. Developers from around the globe working on open-source projects now communicate with one another using tools such as FTP, newsgroups, developer mailing lists, and e-mail. With open-source, you are not limited to certain projects. Any industry can make use of an open-source model if approached correctly.

The objective of any open-source project is the nonproprietary fashion by which a products source code is readily shared with any end user using open-source licensing. It is user driven with developers all over the globe becoming part of a user community when working on a specific project. As one developer finishes working on the initial source code and adds to its basic functionality, the source code is passed along to the next member of the user community. Coordination and communication for the project is essential; therefore, project methodology is needed. Concerns of critics of open-source methodology include:

There is virtually no design documentation or other project documentation. There is no system level testing.

There are no true user requirements apart from basic functionality. The marketing of the product, when completed, remains incomplete.

The methodology is revolutionary and has had great success to date. A few hobbyist developers initiate and drive the projects. They code-and-fix the source code until it is acceptable to them and then they pass it along to the user community. Figure 4.9 shows the two basic approaches to this method. Approach A starts with a team of developers designing and coding the software. They debug the software until the source code is acceptable. The source code is then released to the general user community, who in turn adds more functionality. The original team plays the role of project coordinators and planners. Approach B starts with a single developer who builds and codes the initial version with the minimal functionality he or she requires. It is then released to the user community to build further. The original developer becomes the project owner and coordinates the completion of the project.