Advantages & Disadvantages of the SDLC

A Little Disambiguation

The acronym ‘SDLC’ is used within the technology field for more than just one ‘thing’ and those ‘things’ are so closely related we enter what seems to be a recursive loop in defining one or the other.

  1. Systems Development Life Cycle
  2. Software Development Life Cycle

I come from a software development background as a Web Application Architect for a healthcare technology provider. When I initially read the first chapter of ‘Systems Analysis and Design’ I was completely confused in that what they were describing as ‘Systems Development Life Cycle’ was in fact the good old ‘Software Development Life Cycle’ I have been using in one form or another over the past 7 years they had just given it a different name.

After a little research online I found the reason they are so familiar, ‘Software Development Life Cycle’ is thought to be a subset of ‘Systems Development Life Cycle’. This is due to the fact that it focuses not on the complete system but instead on a specific piece of software or a product which may only be a component of the complete system (“Software Development Process”, n.d.).


Another concern I ran into in the reading is that the book treats the SDLC as an actual step by step methodology for system design and implementation whereas in my experience it has been considered to be the overarching ‘theory’ as to the cycles involved in a systems life not necessarily how they should be designed. With the SDLC being the theory of the life of an application there have been various methodologies spawned from it in order to actually do the design and implementation.

From my understanding and experience the following design and implementation methodologies were created in direct response to handle the SDLC (Systems Development Life Cycle, n.d.):

  • Waterfall
  • Spiral
  • Agile
  • Rapid Prototyping
  • Incremental
  • Synchronize and Stabilize

Please feel free to help me out on this one if my understanding is imperfect or skewed based on my perspective. I have just never run into a development effort where someone said we were going to use the SDLC this time, they have always utilized one of the methodologies listed above.

Since the book is treating the SDLC not as a theory but as an actual methodology I am assuming our discussion is focused on the strict SDLC process as outlined in the book (Kendall,2011). It is from this standpoint I will address the following points.


Strictly speaking, the reality of all system design efforts is the fact that no methodology is ever perfectly executed as prescribed. But if we were to step into a perfect world and were to execute the SDLC in its entirety we would obtain the following benefits:

Complete Documentation of the Entire System

The SDLC dictates that there be painstaking attention to detail in documenting not only the overall design of the system but all pieces thereof,including but not limited to: existing systems, business needs, business processes, software, databases, interfaces, user manuals, training material, etc (Kendall, K.E. 2011).

Complete System Design prior to Development

The entire system including all of its pieces are designed prior to the start of development. A benefit of this is you have a much better understanding of the overall system, how each piece fits into the whole, and the responsibilities each piece has within the system. It removes a lot of the uncertainty and doubt once development begins.


Slow Rate of Change to Meet Business Needs

Due to the extremely detailed and step by step processes within the SDLC it is extremely rigid and inflexible. Businesses today are constantly changing in order to pull ahead of the pack and gain competitive advantage. A lot of this change is due to just how fast paced technology is developing and its direct impact on said businesses. Mixing a rigid design process with an extremely dynamic business can only lead to the inability for a system to change at a rate fast enough to keep up with the business needs.

Lack of, or Monopolization of Resources

Because the enormous amount of effort required to design, document and then develop an entire information system and all of its required features at once using the SDLC it requires an equally enormous amount of talent. This leads to either a lack of resources or a monopolization of existing resources. In either case it will end up costing the business in additional salaries or the inability to hit other business directives due to lack of resources.


Based on the identified factors above the systems which would benefit the most from a strict adherence to the SDLC would be large to extremely large information systems which are relatively stable. In other words complicated, possibly distributed, systems which live within industries which have a relative low rate of change in their business process. Examples would be industries like: Healthcare, Finance, and Government.

The converse also holds, the SDLC would not be a viable option for medium to small information systems which live within industries which have a relatively high level of fluctuation in both business processes and accelerated advancements in the technology used to gain competitive advantage.


No matter the methodology you end up selecting it will have its advantages and its disadvantages. It is up to you to weigh them all and select the one whose advantages outweigh the disadvantages or whose advantages best fit the business needs creating greater competitive edge.


Kendall, K.E. (2011). Systems Analysis and Design.
      Pearson Education, Inc., publishing as Prentice Hall

Software Development Process, (n.d.). In Wikipedia’s online encyclopedia
     Retrieved from

Systems Development Life Cycle, (n.d.). In Wikipedia’s online encyclopedia
     Retrieved from

Published by

Tim Clark

Experienced Business Owner, Chief Information Officer, Vice President, Chief Software Architect, Application Architect, Project Manager, Software Developer, Senior Web Developer, Graphic Designer & 3D Modeler, University Instructor, University Program Chair, Academic Director. Specialties: Ruby, Ruby on Rails, JavaScript, JQuery, AJAX, Node.js, React.js, Angular.js, MySQL, PostgreSQL, MongoDB, SQL Server, Responsive Design, HTML5, XHTML, CSS3, C#,, Project Management, System Design/Architecture, Web Design, Web Development, Adobe CS6 (Photoshop, Illustrator)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s