Strengths and Weakness of SDLC Models

Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Strengths
· Simple and easy to use.
· Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
· Phases are processed and completed one at a time.
· Works well for smaller projects where requirements are very well understood.

Weaknesses
· Adjusting scope during the life cycle can kill a project
· No working software is produced until late during the life cycle.
· High amounts of risk and uncertainty.
· Poor model for complex and object-oriented projects.
· Poor model for long and ongoing projects.


V-Shaped Model
Strengths
· Simple and easy to use.
· Each phase has specific deliverables.
· Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
· Works well for small projects where requirements are easily understood.

Weaknesses
· Very rigid, like the waterfall model.
· Little flexibility and adjusting scope is difficult and expensive.
· Software is developed during the implementation phase, so no early prototypes of the software are produced.
· Model doesn’t provide a clear path for problems found during testing phases


Incremental Model
Stengths
·Generates working software quickly and early during the software life cycle.
·More flexible – less costly to change scope and requirements.
·Easier to test and debug during a smaller iteration.
·Easier to manage risk because risky pieces are identified and handled during its iteration.
·Each iteration is an easily managed milestone.

Weaknesses
·Each phase of an iteration is rigid and do not overlap each other.
·Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.


Spiral Model
The spiral model is the most generic of the models. Most life cycle models can be derived as special cases of the spiral model. The spiral uses a risk management approach to software development. Some advantages of the spiral model are:
· defers elaboration of low risk software elements
· incorporates prototyping as a risk reduction strategy
· gives an early focus to reusable software
· accommodates life-cycle evolution, growth, and requirement changes
· incorporates software quality objectives into the product
· focus on early error detection and design flaws
· sets completion criteria for each project activity to answer the question: "How much is enough?"
· uses identical approaches for development and maintenance can be used for hardware-software system develop
Strengths
· High amount of risk analysis
· Good for large and mission-critical projects.
· Software is produced early in the software life cycle.

Weaknesses
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

Evolutionary Prototyping
Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration
Strengths
· Customers can see steady progress
· This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one fully understands the application area

Weakness
· It is impossible to know at the outset of the project how long it will take.
· There is no way to know the number of iterations that will be required.
Evolutionary Prototyping Summary The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.

Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Strengths
· No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities
· Requires little experience

Weakness
· Dangerous.
· No means of assessing quality or identifying risks.
· Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out.
Code-and-Fix Summary Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes

Weakness
· Won't be able to predict the full range of functionality.
Design-to-Schedule SummaryIn design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features. Leave the lower priority features for later

Staged Delivery
Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design, coding, testing and deployment.
Strengths
· Can put useful functionality into the hands of customers earlier than if the product were delivered at the end of the project.

Weakness
· Doesn't work well without careful planning at both management and technical levels

Staged Delivery Summary For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all dependencies between different components of the system

Evolutionary Delivery
Evolutionary delivery straddles evolutionary prototyping and staged delivery
Strengths
Enables customers to refine interface while the architectural structure is as

Weakness
Doesn't work well without careful planning at both management and

Evolutionary Delivery Summary For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions which are unlikely to be changed by customer feedback

Design-to-Schedule
Like staged delivery, design-to-schedule is a staged release model. However, the number of stages to be accomplished are not known at the outset of the project.
Strengths
· Produces date-driven functionality, ensuring there is a product at the critical date.
· Covers for highly suspect estimates