SDLC Models | Software Development Life Cycle Models

About SDLC Models

Software Development Life Cycle ( also called SDLC Models ) is a workflow process which defines the core stages and activities of development cycles or A framework that describes the operations performed at each phase of a software development project.

SDLC Models

The SDLC aims to produce high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

Some of the SDLC Models are as follows

  • Waterfall Model
  • Incremental SDLC Model
  • Spiral Model
  • Evolutionary Prototyping Model
  • Agile Model
  • RAD Model

1) Waterfall Model 

  • It is one of the oldest and most well-known SDLC models
  • It follows a sequential step-by-step process from requirements analysis to maintenance.
  • Systems that have well-defined and understood requirements are a good fit for the Waterfall Model


Waterfall Model Strong Points

  • Easy to understand, easy to use
  • Provides structure to inexperienced staff
  • Milestones are well understood
  • Sets requirements stability
  • Good for management control (plan, staff, track)
  • Works well when quality is more important than cost or schedule

Limitation of the Waterfall Model

  • Not suitable for the project where requirements are changing.
  • The high amount of risk and uncertainty
  • Not good for the object-oriented project
  • Poor model for long and ongoing project
  • Can give a false impression of progress
  • Integration is one big bang at the end
  • Little opportunity for the customer to preview the system 

Suitable Situation to use Waterfall Model

  • Work well for a small project
  • When Requirements are very well known
  • When Product definition is stable
  • When Technology is understood
  • When New version of an existing product
  • When Porting a current product to a new platform. 

2) Incremental SDLC Model


  • In this model, it constructs a partial implementation of a total system that is divide project into builds then slowly add functionality in each build.
  • The incremental model prioritizes the requirements of the system and then implements them in groups.
  • Each subsequent release of the system adds function to the previous version until all designed functionality has been implemented.

Incremental Model Strong Points

  • Develop high-risk or major functions first
  • Each release delivers an operational product
  • The customer can respond to each build
  • Uses “divide and conquer” breakdown of tasks
  • Lowers initial delivery cost
  • Initial product delivery is faster
  • Customers get important functionality early
  • Risk of changing requirements is reduced

Incremental Model Limitations

  • Requires good planning and design
  • Needs an early definition of a complete and fully functional system to allow for the definition of increments
  • Well-defined module interfaces are required (some will be developed long before others)
  • The total cost of the complete system is higher than the waterfall model

Suitable Situation to use Incremental Model

  • Risk, funding, schedule, program complexity, or need for early realization of benefits.
  • Most of the requirements are known up-front but are expected to evolve over time
  • A need to get basic functionality to the market early
  • On projects which have lengthy development schedules
  • On a project with new technology

3) Spiral SDLC Model

  • It is a “risk-driven” iterative model
  • It divides a project into iterations
  • Each iteration deals with 1 or more risks
  • Each iteration starts with a small set of requirements and goes through the development phase (except Installation and Maintenance) for those set of requirements.


Spiral Model Strong Points

  • It provides an early indication of insurmountable risks, without much cost
  • Development phases can be determined by the project manager, according to the complexity of the project.
  • Users can be closely tied to all lifecycle steps and can see the system early because of rapid prototyping tools
  • Project monitoring is very effective. Each phase requires a review from concerned people (Early and frequent feedback from users). This makes the model more transparent. The design does not have to be perfect
  • Estimates such as budget and schedule become more realistic as work progressed because important issues are discovered earlier.
  • Manages risks and develops the system into phases.
  • Changes can be introduced later in the life cycle as well.

Spiral Model Limitations

  • Time spent on evaluating risks too substantial for small or low-risk projects
  • Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
  • The model is complex
  • Risk assessment expertise is required
  • Spiral may continue indefinitely
  • Maybe hard to define the objective, verifiable milestones that indicate readiness to proceed through the next iteration
  • High cost and time to reach the final product.
  • Needs special skills to evaluate the risks and assumptions.

Suitable Situation to use Spiral Model

  • When the creation of a prototype is appropriate
  • When costs and risk evaluation is important
  • For medium to high-risk projects
  • For Long-term project commitment unwise because of potential changes to economic priorities
  • When users are unsure of their needs
  • When requirements are complex
  • For New product line
  • When Significant changes are expected (research and exploration) 

4)Evolutionary Prototyping Model


  • Developers build a prototype during the requirements phase
  • The prototype is evaluated by end users
  • Users give corrective feedback
  • Developers further refine the prototype
  • When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Steps in Prototyping SDLC Models

  • A preliminary project plan is developed
  • A partial high-level paper model is created
  • The model is a source for a partial requirements specification
  • A prototype is built with basic and critical attributes
  • The designer builds the database, user interfaces, and algorithmic functions
  • The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.
  • This loop continues until the user is satisfied

Evolutionary Prototyping SDLC Models Strong Points

  • Requires user involvement
  • Customers can “see” the system requirements as they are being gathered
  • Developers learn from customers
  • Reduce the development time
  • Reduce the development cost
  • Unexpected requirements accommodated
  • Allows for flexible design and development
  • Missing functionalities can be easily added
  • Result in higher user satisfaction

Evolutionary Prototyping SDLC Models Limitations

  • Too much involvement of the customer
  • Insufficient analysis
  • The design is of less quality
  • The resulting system is harder to maintain. Overall maintainability may be overlooked
  • A prototype is a quick-and-dirty” solution
  • The customer may want the prototype delivered.
  • The process may continue forever

Learn Business Analyst Training

Suitable Situation to use Evolutionary Prototyping SDLC Models

  • When requirements are unstable or must be clarified
  • For developing user interfaces
  • For Short-lived demonstrations
  • For the new, original development
  • With the analysis and design portions of object-oriented development.

5)Agile Model


  • The biggest problem with software development is changing requirements
  • Agile processes accept the reality of change versus the hunt for complete, rigid specifications
  • Speed up or bypass one or more life cycle phases
  • Usually less formal and reduced scope
  • Used for time-critical applications
  • Used in organizations that employ disciplined methods

Agile Model Strong Points

  • It can adapt well with changing requirement
  • Deliver a working product faster than a conventional linear development model
  • Customer feedback at every stage ensures that the end deliverable satisfies their expectations
  • No guesswork between the development team and the customer, as there is face to face communication and continuous inputs from the client
  • Decrease the time required to avail some system features.
  • A test can be conducted during the design cycle
  • Fewer risks and has more flexibilities
  • Modification in the system needs less time
  • The result is high-quality software in the least possible time duration and satisfied customer.

Agile Model Limitations

  • More Programmer centric than user-centric
  • For larger projects, it is difficult to judge the efforts and the time required for the project in the SDLC.
  • Since the requirements are ever-changing, there is hardly any emphasis, which is laid on designing and documentation. Therefore, chances of the project going off the track easily are much more
  • Scalability
  • The ability and collaboration of the customer to express user needs.
  • Documentation is done at later stages.
  • Reduce the usability of components.
  • Needs special skills for the team.

Rapid Application Development Model (RAD)


Phases in the RAD model are as follows,

  • Requirements planning phase – a workshop utilizing structured discussion of business problems
  • User description phase – automated tools capture information from users
  • Construction phase – productivity tools, such as code generators and screen generators
  • Cutover phase – installation of the system, user acceptance testing and user training 

RAD Model Strong Points

  • Reduced cycle time and improved productivity with fewer people means lower costs
  • Time-box approach mitigates cost and schedule risk
  • It increases the reusability components
  • Greater customer satisfaction
  • Fast delivery time
  • Reduce the development time
  • The focus moves from documentation to code (WYSIWYG).
  • Uses modeling concepts to capture information about business, data, and processes.

RAD Model Limitations

  • Large manpower is required to create the number of RD teams.
  • Risk of never achieving closure
  • Hard to use with legacy systems
  • Requires a system that can be modularized
  • Require highly skilled developer and designer.
  • Not useful when technical risks are high
  • Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

Suitable Situation to use RAD Model

  • Reasonably well-known requirements
  • The user involved throughout the life cycle
  • The project can be time-boxed
  • Functionality delivered in increments
  • High performance not required
  • Low technical risks
  • The system can be modularised

Software Development Life Cycle Phases

Leave a reply:

Your email address will not be published.

Site Footer

{"wp_error":"cURL error 60: SSL certificate problem: unable to get local issuer certificate"}