SDLC & SDLC Methodologies

SDLC Methodologies

1 . Waterfall Methodology

  • Simple and easy to understand, use & 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.
  • Clearly defined stages, Well understood milestones, Easy to arrange tasks & Process and results are well documented.
  • No working software is produced until late during the life cycle.
  • High amounts of risk and uncertainty.
  • Not a good model for complex and object-oriented projects as well as long and ongoing projects.
  • Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
  • It is difficult to measure progress within stages.
  • Cannot accommodate changing requirements.
  • Adjusting scope during the life cycle can end a project.
  • Integration is done as a big-bang. at the very end, which doesn’t allow identifying any technological or business bottleneck or challenges early.

2 . Agile Methodology

  • Is a very realistic approach to software development.
  • Promotes teamwork and cross training.
  • Functionality can be developed rapidly and demonstrated.
  • Resource requirements are minimum.
  • Suitable for fixed or changing requirements
  • Delivers early partial working solutions.
  • Good model for environments that change steadily.
  • Minimal rules, documentation easily employed.
  • Enables concurrent development and delivery within an overall planned context.
  • Little or no planning required.
  • Easy to manage.
  • Gives flexibility to developers.
  • Not suitable for handling complex dependencies.
  • More risk of sustainability, maintainability and extensibility.
  • An overall plan, an agile leader and agile PM practice is a must without which it will not work.
  • Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.
  • Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction.
  • There is a very high individual dependency, since there is minimum documentation generated.
  • Transfer of technology to new team members may be quite challenging due to lack of documentation.

3 . Iterative Methodology

  • Some working functionality can be developed quickly and early in the life cycle.
  • Results are obtained early and periodically.
  • Parallel development can be planned.
  • Progress can be measured.
  • Less costly to change the scope/requirements.
  • Testing and debugging during smaller iteration is easy.
  • Risks are identified and resolved during iteration and each iteration is an easily managed milestone.
  • Easier to manage risk as High risk part is done first.
  • Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.
  • It supports changing requirements.
  • Initial Operating time is less.
  • Better suited for large and mission critical projects.
  • More resources may be required.
  • Although cost of change is lesser, but it is not very suitable for changing requirements.
  • More management attention is required.
  • System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle.
  • Defining increments may require definition of the complete system.
  • Not suitable for smaller projects.
  • Management complexity is more.
  • End of project may not be known which is a risk.
  • Highly skilled resources are required for risk analysis.
  • Projects progress is highly dependent upon the risk analysis phase.

4 . Spiral Methodology

  • Changing requirements can be accommodated.
  • Allows extensive use of prototypes.
  • Requirements can be captured more accurately.
  • Users see the system early.
  • Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
  • Management is more complex.
  • End of the project may not be known early.
  • Not suitable for small or low risk projects and could be expensive for small projects.
  • Process is complex
  • Spiral may go on indefinitely.
  • Large number of intermediate stages requires excessive documentation.

5 . V Model Methodology

  • This is a highly-disciplined model and Phases are completed one at a time.
  • Works well for smaller projects where requirements are very well understood.
  • Simple and easy to understand and use.
  • Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
  • High risk and uncertainty.
  • Not a good model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Not suitable for the projects where requirements are at a moderate to high risk of changing.
  • Once an application is in the testing stage, it is difficult to go back and change a functionality.
  • No working software is produced until late during the life cycle.

6 . Big Bang Methodology

  • This is a very simple model
  • Little or no planning required
  • Easy to manage
  • Very few resources required
  • Gives flexibility to developers
  • It is a good learning aid for new comers or students.
  • Very High risk and uncertainty.
  • Not a good model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Can turn out to be very expensive if requirements are misunderstood.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Charith Wijebandara

Charith Wijebandara

Software Engineering Undergraduate-University of Kelaniya