CSC/ECE 517 Spring 2014/ch1 1w1m bm

Comparison of Waterfall, Prototype, and Agile Development

Introduction

This article seeks to provide information about different development strategies, comparing their efficacy through empirical research.

Background

Over the past few years, the trend in software development has been to use an agile approach. Before this, traditional approaches required precise and extensive planning, which left the process vulnerable to changing requirements and unforeseen problems. Agile development, on the other hand, attempts to adapt to changing conditions and requirements. Similarly, prototyping helps decide what specifications and features should be implemented in a product by providing a working model that users can interact with, thus allowing them to provide more beneficial feedback. The following sections provide a quick overview of these software development processes.

Traditional (Waterfall) Development

As stated before, waterfall relies on extensive planning, mapping out an entire process from start to finish. Progress flows steadily in one direction (as in a waterfall). The phases in this process include Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance <ref>Understanding the pros and cons of the Waterfall Model of software development</ref>. In the early days of software development, this methodology was adapted from construction and manufacturing industries because there was no formal model for software development.

When following the waterfall model, during the Conception, Initiation, Analysis, and Design stages, the specifications for the project are permanent. This is essentially a blueprint that software developers will use to construct the product. These designs may be in the form of different components that will be later combined to produce functionality; however, a new phase may not be started until the first is completely done.

Advantages

Traditional software development has the advantage of fully understanding the problem from the outset and producing a clear, and finalized set of specifications. This allows progress to clearly be identified, as each step in the process can be measured. This also allows all team members to be on the same page; if someone is unsure about an aspect of the project, they can refer to the concrete list of specifications. Because so much effort goes into planning before writing code actually begins, it is also easy to identify design flaws.

Disadvantages

While fully understanding a problem before software development begins is great, this is often not the case in the real world. In reality, customers often do not know what they want, or if they do, this often changes once they see the product in action. Furthermore, rapidly evolving technologies often make fully understanding a problem before development difficult. More often, it is not known how something will be implemented before development begins, or a theoretical design may prove unfeasible.

References

<references />