A Quality Assurance Information Site.

  Skills | Templates & Checklists | Terminology   
Helpful Links | Papers & Presentations | Books | Periodicals    

Testdog.com - - SDLC

Bugs, Defects, Etc. Development Terms Engineering Terms Testing Terms Sorting Out SDLC

Acronym for system development life cycle. SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps:

  • The software concept - identifies and defines a need for the new system

  • A requirements analysis - analyzes the information needs of the end users

  • The architectural design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources

  • Coding and debugging - creates and programs the final system

  • System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

Sorting Out SDLC Terminology

We’ve probably all seen the job postings with a “required skills” line item that reads something like the following:

Must be expert in a variety of software development methodologies including SDLC, RUP, XP, PMP, Agile, Waterfall, Spiral, SEI, PMI, CMMI, PIMBOC, and Scrum.

To which, you might reply, “What are they talking about?”

Clearly, there are people in HR and recruiting (and I know some in development) who are confused about software development methodologies, their names, acronyms, meanings, and relationships to one another.  Let’s try to sort this out a bit.

Untangling the terminology

To begin, many of the terms listed above are not SDLCs.  The term SDLC is an acronym that stands for Software Development Life Cycle (as well as System Design Life Cycle, System Development Life Cycle and Synchronous Data Link Control).  SDLC is used as a generic umbrella term for any number of software development methodologies.

SDLC by itself is not a methodology.  When the term SDLC shows up in a list of methodologies, it is a clear indicator that the person who wrote this is confused about what it really means.

The internet American Heritage dictionary gives us the following definition for methodology:

-A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods: the methodology of genetic studies; a poll marred by faulty methodology.

Some of the SDLCs listed above do not claim to be methodologies.  To be more accurate, an SDLC is an approach to managing a software development project.

However, I am using a very broad definition for “methodology” and it sounds more precise to talk about methodology instead of approach.


Neither PMI nor PMP are methodologies.  PMI, the Project Management Institute, is a nonprofit organization.  PMP, Project Management Professional, is one of the certifications that the PMI offers to qualified individuals.  The PMI and its members have a vested interest in project management methodologies.  Some, but not all, SDLCs lay claim to being a project management methodology.

The PMI has also developed and periodically updates A Guide to the Project Management Body of Knowledge (PMBOK® Guide).  It is usually pronounced as spelled in the sample job posting, which is an actual misspelling I recently encountered.  The PMBOK® is an attempt to document generally recognized project management best practices.  It does not claim to be a methodology but probably meets the dictionary definition.

Web resource: www.PMI.org


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.  In the mid-1980s the SEI developed a process improvement model labeled as the Capability Maturity Model or CMM.  The CMM has subsequently been superseded by the Capability Maturity Model Integration (CMMI).  Neither the CMM nor CMMI claim to be methodologies but instead use the phrase “process model.”

Web resource: www.sei.cmu.edu


Technically speaking, Agile isn’t a single methodology, but a group of related methodologies that refer to themselves as light-weight.  Agile was developed largely in response to what was felt as slow, bureaucratic, burdensome, and document-centric methodologies.  Agile methodologies generally emphasize short iterative cycles, team development and communication, and adaptation to changing needs.

Web resource: www.agileAlliance.com

What’s the difference?

We should keep in mind that a methodology is a body of practices.  It isn’t a script you can use in lieu of your critical thinking skills.  I like to think of the SDLC as a management roadmap.  It is used on software development projects to help answer important questions that continually arise, such as: “How do we make this work?”, “What happens next?”, or even “What are we supposed to do now?”  As such, the SDLC is an important management tool to help projects start right, work effectively, and finish satisfactorily.

The following chart outlines the remaining SDLCs that were cited at the beginning of this article, plus a few others.  They are listed in chronological order of when they generally came into practice.



Author / Attributor / Owner



Winston W. Royce

The Waterfall model has been widely attributed to an IEEE conference paper written by Winston W. Royce in 1970 titled “Managing the Development of Large Software Systems.”  He never used the term “waterfall” but the paper did include a graphic image depicting progress through distinct project phases that somewhat resembled a waterfall.  It is ironic that Royce himself described this model as one that “invites failure” and the paper also describes the need for iteration.




Barry Boehm

The Spiral model was originally defined in a 1985 article written by Barry Boehm titled “A Spiral Model of Software Development and Enhancement.”  This model uses iterations, lasting from months to years, which provide succeeding layers of functionality.  Boehm’s original paper describes this approach as being risk-driven, as opposed to document-driven or code-driven.





RUP is an acronym that stands for the Rational Unified Process originally developed by Rational Software, now a part of IBM.  RUP describes itself as a process framework and is designed to be adapted to the needs of individual projects.  RUP had its origins in the Rational Approach and the Rational Objectory Process with major contributions by Barry Boehm, Ken Hartman, and Ivar Jacobson.  By the time the term RUP was first used, the framework was on version 5.0 and the chief architect was Philippe Krutchen. 

The RUP framework divides a project into the four phases of Inception, Elaboration, Construction, and Transition with spiraled iterations inside of the last three phases.

Web resource: www.Rational.com


The remaining methodologies fall into the Agile category.





Takeuchi & Nonaka

Sutherland, Scumniotales, McKenna

Ken Schwaber

Scrum was originally described by Takeuchi & Nonaka in a 1986 article in the Harvard Business Review titled The New Product Development Game.  Scrum is named after the rugby term, which is a way to restart a game after the ball goes out of play or after an accidental infringement.

In 1993 Jeff Sutherland, John Scumniotales, and Jeff McKenna further defined the scrum approach while at Easel Corporation.  In 1995 Ken Schwaber formalized the scrum definition.  In 2004 he authored the book Agile Project Management With Scrum.

Among other things, scrum emphasizes close interaction with the customer, daily team status discussion, and working from a dynamic backlog of work to be completed.

Web resource: www.scrumAlliance.org


Extreme Programming (XP)


Kent Beck

Extreme Programming or XP was developed by Kent Beck, Ward Cunningham, and Ron Jeffries while at Chrysler Corporation in 1996.  In 1999 Kent Beck wrote a book on the subject titled Extreme Programming Explained.

XP was the first Agile methodology that became widely popular.

XP strives for adaptability amidst changing requirements.  A primary goal is to lower the cost of change.  This is accomplished by following a specific set of 12 practices designed to encourage certain values.  Among the most discussed practices are pair programming, test driven development, and continuous integration.

Web resource: www.extremeProgramming.org


Feature Driven Development (FDD)


Jeff De Luca

Feature Driven Development (FDD) was developed by Jeff De Luca in 1997 while working in Singapore.  As its name implies, FDD uses a feature list as a means of organizing work into iterative design and build activities.

FDD emphasizes object modeling, inspections, and project organization around discrete features.

Web resource: www.featureDrivenDevelopment.com


Adaptive Software Development


Jim Highsmith

Adaptive Software Development is an Agile approach developed by Jim Highsmith.  It has its origins in the “rapid application development”: work done by James Martin and others in the 80s and 90s.

Jim Highsmith authored a book in 2000 titled Adaptive Software Development: A Collaborative Approach to Managing Complex Systems.

ASD uses repeating cycles composed of speculate, collaborate, and learn.

Web resource: www.adaptivesd.com


Crystal Clear


Alistair Cockburn

Crystal Clear was developed by Alistair Cockburn, who authored a book in 2004 titled Crystal Clear: A Human-Powered Methodology for Small Teams.  As the book title implies, it is designed for small teams of up to 8 developers working in close cooperation and ideally co-located.

Crystal Clear strives to be people oriented, with emphasis on frequent code delivery, reflective improvement, and osmotic communication.


This list is not meant to be a comprehensive inventory of all of the available SDLCs.  Software Development is an evolving discipline and new approaches are continually coming into play.

So, which is best? 

Go back to the roadmap analogy.  Some maps might emphasize terrain, others roadways, others still, public transportation routes.  You might find one that is most suited for your journey and you might want to use more than one.

Which is best for you?  It depends: What are your needs?  Where have you had problems in the past?  How much of the work is using new technology?  Have you created similar software in the past?  How experienced is your staff and management?  In short, where is your pain?

Points to Ponder

Here are a few remaining things to consider when choosing an SDLC.

·        It’s probably wise to consider the business stakeholders who will be part of the process.  You want to use what will work for the corporate culture.

·        On many projects, it is often unclear who owns the SDLC.  In other words, who decides what to use?  Conflicts can occur among Project Managers, PMO types, Architects, Business Analysts, Quality Managers, and Developers.  It might be wise to come to a collaborative decision early on.

·        It is possible to adopt and adapt different elements from different SDLCs. 

·        Standardizing on a single SDLC for an organization, or for a class of projects within an organization, only makes sense if the projects tend to be very similar in size, scope, technology, risk factors, and stakeholders.

·        If you don’t proactively choose an SDLC you will get one anyway.  You will probably not be pleased with the results.

The Continuing Saga

Was anything left out?  Do you have any SDLC stories of your own?  If so, send us a note: support@testdog.com


methodology. Dictionary.com. The American Heritage® Dictionary of the English Language, Fourth Edition, Houghton Mifflin Company, 2004. http://dictionary.reference.com/search?q=methodology&x=44&y=10 (accessed: September 06, 2006).



Frequently-Asked-Questions| Testing & Tool Resource | Test Tool Comparisons
Free Tools  |Papers & Presentations | Books | Members | Site Map