The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.
• Requirements: During this initial phase, the potential requirements of the application are methodically analysed and written down in a specification document that serves as the basis for all future development. The result is typically a requirements document that defines what the application should do, but not how it should do it.
• Analysis: During this second stage, the system is analysed in order to properly generate the models and business logic that will be used in the application.
• Design: This stage largely covers technical design requirements, such as programming language, data layers, services, etc. A design specification will typically be created that outlines how exactly the business logic covered in analysis will be technically implemented.
• Coding: The actual source code is finally written in this fourth stage, implementing all models, business logic, and service integrations that were specified in the prior stages.
• Testing: During this stage, QA, beta testers, and all other testers systematically discover and report issues within the application that need to be resolved. It is not uncommon for this phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to be properly squashed.
• Operations: Finally, the application is ready for deployment to a live environment. The operations stage entails not just the deployment of the application, but also subsequent support and maintenance that may be required to keep it functional and up-to-date.
Using a waterfall method does allow the project as a whole to maintain a more detailed, robust scope and design structure due to all the upfront planning and documentation stages. This is particularly well suited to large teams that may see members come and go throughout the life cycle of the project, allowing the burden of design to be placed on the core documentation and less on any individual team member.
Another advantage can be that it allows for early design changes, while it can be difficult to make design changes later in the process, the waterfall approach lends itself well to alterations early in the life cycle. This is great when fleshing out the specification documents in the first couple stages with the development team and clients, as alterations can be made immediately and with minimal effort, since no coding or implementation has actually taken place up to that point.
The most damning aspect of the waterfall model is its inherent lack of adaptability across all stages of the development life cycle. When a test in stage five reveals a fundamental flaw in the design of the system, it not only requires a dramatic leap backward in stages of the process, but in some cases, can be often lead to a devastating realization regarding the legitimacy of the entire system.
It doesn’t allow much reflection or revision. When the product is in testing phase, it is very difficult to go back and change something which is left during the requirement analysis phase.
The Iterative Model
An iterative life cycle model does not start with a full specification of requirements. In this model, the development begins by specifying and implementing just part of the software, which is then reviewed in order to identify further requirements. Moreover, in iterative model, the iterative process starts with a simple implementation of a small set of the software requirements, which iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed. Each release of Iterative Model is developed in a specific and fixed time period, which is called iteration.
• Planning Phase: This is the first stage of the iterative model, where proper planning is done by the team, which helps them in mapping out the specifications documents, establish software or hardware requirements and generally prepare for the upcoming stages of the cycle.
• Analysis and Design Phase: Once the planning is complete for the cycle, an analysis is performed to point out the appropriate business logic, database models and to know any other requirements of this particular stage. Moreover, the design stage also occurs in this phase of iterative model, where the technical requirements are established that will be utilized in order to meet the need of analysis stage.
• Implementation Phase: This is the third and the most important phase of the iterative model. Here, the actual implementation and coding process is executed. All planning, specification, and design documents up to this point are coded and implemented into this initial iteration of the project.
• Testing Phase: After the current build iteration is coded and implemented, testing is initiated in the cycle to identify and locate any potential bugs or issues that may have been in the software.
• Evaluation Phase: The final phase of the Iterative life cycle is the evaluation phase, where the entire team along with the client, examine the status of the project and validate whether it is as per the suggested requirements.
In iterative model we can only create a high-level design of the application before we actually begin to build the product and define the design solution for the entire product. Later on we can design and built a skeleton version of that, and then evolved the design based on what had been built.
In iterative model we are building and improving the product step by step. Hence we can track the defects at early stages. This avoids the downward flow of the defects.
In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of the product to users for their feedback, we are effectively asking them to imagine how the product will work.
In iterative model less time is spent on documenting and more time is given for designing.
Since the model is a cycle, the potential for iterative development to spin out of control and exceed its budget is immense. The cost-benefit of solving new problems that arise must therefore be closely-managed, and timescales and deliverables will still need to be defined and monitored.
Unlike the Waterfall model, where strict documentation of the entire development process is a design requirement, many iterative approaches favour lighter documentation. This can reduce project overheads. However, there is a risk that under-documentation could lead to needless duplication of effort, and time wasted developing within a task with a poorly-defined scope.
The Agile Development Model
This methodology was first introduced in 2001, when 17 people gathered at Snowbird Ski Resort in Utah and came up with the “Agile Manifesto.” This outlined 12 of the most important principles of development. They included communication, collaboration, open-mindedness, flexibility, and the importance of software. It is a type of incremental software development that moves along in rapid cycles–much like sprints. The results are small product releases, with each building on the previous product. Ideally, teams get more work done in less time. This method proved best for time-critical applications where the customer is available and willing to communicate throughout the entire lifecycle of development. It requires an adaptive team willing to respond and change based on product tests and reviews.
Increased revenue by releasing some of the benefits in stages while you continue to develop the product. Products hit the market quicker, releasing early and regularly, and customers get a return on their investment sooner. Quality assurance with integrated testing and regular inspections of a working product throughout development. Improved visibility for key stakeholders as agile software development encourages user involvement in a cooperative and collaborative effort. Decreased risk as the team identifies and corrects any issues early.
One important advantage of agile process models is the collaboration with the customer. The customer receives what he needs and not what he has specified. This is an important benefit for projects whose requirements are still unclear at the beginning or are subject to major changes caused by external influences.
Another advantage is the breakdown of bureaucratic structures, e.g. fewer documents need to be created and maintained. A typical criticism of classic process models is the distance from the client or user. While the specification still occurs in close cooperation, the client often has virtually no influence on the definition of the product during implementation. Agile software development on the other hand generally attempts to manage with less bureaucracy and fewer explicit rules.
For some software deliverables, developers cannot quantify the full extent of required efforts. This is especially true in the beginning of the development life cycle on larger products. Teams new to the agile methodology fear these unknowns. This fear drives frustration, poor practices, and often poor decisions. The more regimented, waterfall process makes it easy to quantify the effort, time, and cost of delivering the final product.
Testers, customers, and developers must constantly interact with each other. This involves numerous face-to-face conversations, as they are the best form of communication. All involved in the project must have close cooperation. Daily users need to be available for prompt testing and sign off on each phase so developers can mark it off as complete before moving on to the next feature. This might ensure the product meets user expectations, but is onerous and time-consuming. This demands more time and energy of everyone involved.
This method requires very little planning to get started, and assumes the consumer’s needs are ever changing. With so little to go on, you can see how this could limit the agile model. Then, if a consumer’s feedback or communications are not clear, a developer might focus on the wrong areas of development. It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one.
The Rapid Application Development (RAD) Model
Rapid application development (RAD) describes a method of software development which heavily emphasizes rapid prototyping and iterative delivery. The RAD model is, therefore, a sharp alternative to the typical waterfall development model, which often focuses largely on planning and sequential design practices. First introduced in 1991 in James Martin’s book by the same name, rapid application development has become one of the most popular and powerful development methods, which falls under the parental category of agile development techniques.
By utilizing a rapid application development method, designers and developers can aggressively utilize knowledge and discoveries gleaned during the development process itself to shape the design and or alter the software direction entirely.
1. Planning Requirements: During this initial stage designers, developers, and users come to a rough agreement on project scope and application requirements, so that future stages with prototyping can begin.
2. User Design: User feedback is gathered with heavy emphasis on determining the system architecture. This allows initial modelling and prototypes to be created. This step is repeated as often as necessary as the project evolves.
3. Rapid Construction: Once basic user and system design has begun, the construction phase is where most of the actual application coding, testing, and integration takes place. Along with User Design, the Rapid Construction phase is repeated as often as necessary, as new components are required or alterations are made to meet the needs of the project.
4. Cutover: The final Cutover (or Transition) stage allows the development team time to move components to a live production environment, where any necessary full-scale testing or team training can take place.
Measurable Progress: With frequent iterations, components, and prototypes coming down the pipe, progress on the overall project, as well as lesser segments, can be easily measured and evaluated to maintain schedules and budgets.
Quickly Generate Productive Code: As a larger percentage of active software developers move into multi-discipline roles (i.e. full-stack developers), a RAD methodology allows skilled team members to quickly produce prototypes and working code to illustrate examples that might otherwise take weeks or months to see the light of day using a slower development technique.
Simple Adaptability: During development, software is a fairly malleable form. Since code can be changed that dramatically alters the entire system or generates new components, it is to the advantage of the development team to make use of this flexibility early and often, by iterating and prototyping potential concepts or ideas throughout development.
Requires Modular Systems: Since each component within the system should be iterable and testable on its own accord, the overall system design when using RAD requires that each component be modular, allowing elements to be swapped in and out or altered by a variety of team members.
Difficulty within Large-Scale Projects: While rapid application development methods lead to far greater flexibility during the design and development process, it will also tend to reduce control and restrictions. While this isn’t inherently negative, properly managing this added flexibility and volatility within the scope of the whole project can be difficult for larger applications.
Depends Upon Skilled Developers: While many developers these days are multi-disciplined, it is worth noting that use of RAD techniques does require a greater overall skill across the development team, in order to quickly adapt as the system and components evolve.
The Spiral Model
The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Its one of the software development models like Waterfall, Agile, V-Model.
– Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.
– Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.
– Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.
– Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.