The iterative development model is a cyclic software development process, developed to oppose the waterfall model and its weaknesses. It is an essential part of the agile software development and often is used in web application development.

The main idea of the iterative methodology is to produce a software system incrementally, allowing the web developers to take advantage of what was being learned during the earlier software development, and produce incremental, deliverable builds of the system. Learning comes from QA, testing, programming and coding, and use of the system. The process itself looks like that: start of the web development with a simple implementation of a subset of main and the most important requirements and iteratively enhance it with additional features until the full system is implemented. At each iteration, design modifications are or may be made and new features are added.

The development process consists of the following steps: initialization, iteration, and the project control list. The initialization step creates a prototype of the system or a base version. The main goal for this initial implementation is to create a software build to which the customer can react and if necessary give the development team new requirements or enhance the existing ones.

To manage and guide the development process, a project control list is created, which contains a set of all tasks that need to be implemented. It includes new features to be implemented and areas of redesign of the existing application. As a result of the analysis phase the control list is constantly being revised to improve the functionality on next iteration.

Each iteration involves the implementation of the needed features form a control list, redesign of the needed functionality, and the analysis of the current version of the system. The goal for the implementation and design of any iteration is to be simple and modular, supporting redesign if needed. Design detail level in such model is subject to discuss and should be chosen for the project specifically, depending on the project itself. In this case the iterative model doesn’t dictate the needed level of detail.
The analysis of iteration is based upon customer’s feedbacks. Also, it involves the analysis of the interface usability, reliability, efficiency, structure, modularity and achievement of the main goals. When the analysis is over, the IT project control list may be modified, depending on the results.

The waterfall model (one of the approaches to software development or web development project) describes a linear development method that is often considered the classic approach to the systems development life cycle. This model is a sequential model, used to create different kinds of software, where project development is seen as flowing steadily downwards (like a waterfall) through the phases of software development requirements analysis, UI design, software implementation, project verification and software maintenance. The process itself can be divided into different phases, depending on the IT project or other web development requirements.

The main idea of the waterfall model is that software development proceeds from one phase to the next step in a purely sequential manner or way. For example, the wed development team first completes requirements and when all the desired requirements are fully completed, reviewed and approved, the IT team proceeds to GIU design phase. So, the waterfall model means that the programming team should move to a next following step only when previous phase is completed and everything is approved. However in some model modifications some slight or major variations and even changes may be included.

The most important advantage of the waterfall idea is that it allows for departmentalization and managerial control. In the common practice a schedule with deadlines for each phase of project development is made and a product can proceed through the development process under the created schedule.

The next argument for the waterfall model is that it puts solid requirements on theproject documentation (design documents and requirements specs) as well as the source code. And if any of team members left the project, less knowledge would be lost in comparison to a project with less designed and documented methodologies. In the waterfall model a fully working design document should be present so, that a new team member or even the entire new team will easily familiarize themselves with a project by reading the documents.

In common practice waterfall methodologies result in a project schedule with 20-40% of the time invested for the first two phases, 30-40% of the time to coding, and the rest dedicated to testing and implementation time. The actual project organization needs to be highly structured. Most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project.
In theory, such process leads to the project being delivered on time because of detailed plan for each phase, created previously.

However, in practice it’s often impossible to follow the pure waterfall model, because it does not consider the inevitable changes and revisions that become necessary in the development process. Also, many specialists argue on the waterfall model as a bad idea in practice, generally because of the inability to perfect one stage of a software product, before moving to another stage and learning something new from them for any non-trivial project.
For example, customers may not be sure of what requirements exactly they want before they see a working prototype and can comment upon it; they may change their requirements constantly after seeing a result of development, and program designers and implementers may have little or no control over this. If customers change their requirements after a design document is finished, then the document must be modified to correspond to the new requirements. Also, project designers may not be aware of future implementation or development difficulties when writing a design for an unimplemented software product. For example, it may become clear on the implementation phase that a particular area of product functionality is extraordinarily difficult to implement. In this situation, it is better to revise and change the design document rather to persist in using a conception, that was made based on incorrect predictions and that does not consider the newly discovered problem areas. This is one of the reasons, why the waterfall model isn’t commonly used in agile software development.

So, to conclude – the most significant weakpoint of the waterfall model is the possibility that a poor or wrong design choice will not be discovered until the final stages of implementating or testing. The risk of this happening will increase as the project duration and size go up. Even competent people make simple mistakes and considering the solid waterfall timetable, mistakes made in the design or requirements documents may not be discovered until half of a year of programming have been completed and the system is being tested.
From the author’s point of view the waterfall model in its pure form can be successfully used either on small projects or on trivial projects, where all requirements are known before the project starts and they won’t change over the time. For example, in mobile games development industry all requirements are usually developed and perfected before the project starts, what allows the development team to work on the pure waterfall model. However if there is even a miserable chance that the project is non-trivial or there are non-completed requirements the waterfall model won’t be the best one to work on.