Information Technologies (IT) continues to look for the "silver bullet" that will push software out as quickly...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and efficiently as possible. This "silver bullet" has taken several forms over the last 25 years, encompassing everything from hardware, to operating systems, to integrated development environments, to software development (SDLC) methodologies. In this article we will focus on the SDLC methodologies, the relative strengths and weaknesses of the commonly-employed methodologies, their common goals, and their fundamental differences.
In order to keep the discussion focused, we will begin by qualifying the three main attributes of an SDLC methodology. A methodology must:
- Support the Design of software to meet a business need
- Support the Construction of software to meet the specified design
- Support the Deployment of software to production
In addition, for the purposes of this discussion, a methodology should also support Maintenance of all deployed software artifacts.
If we have all these characteristics in play, we have a full-fledged SDLC methodology. There are many disciplines involved in meeting the objectives of any methodology -- everything from business analysis, to software development, to testing, to release management, to change management, and so on. The objective of this article is to highlight the differences between methodologies, not the specific processes within each methodology.
In this article we will give a brief overview of the development and deployment of SDLC methodologies, describe the two most common models (adaptive and predictive), describe their relative strengths and weakness (differences), and finally discuss how and when to leverage the appropriate aspects of each to meet your development goals.
SDLC methodologies-- How we got here…
Software development is a relatively new discipline which moved into the mainstream in the early eighties, though the origins of software development can be traced back to World War II. With the explosive growth of software in the early eighties, the software industry suffered a so-called software crisis, which really reflected the immaturity of software development as a discipline. Most development shops functioned as "cowboy development" shops with no holistic approach to developing software solutions.
Proponents of a more structured approach to software development began to emerge. During the eighties and nineties, the emphasis was placed on creating a sustainable, disciplined, and repeatable development process; this resulted in a sequential set of phases that attempted to design, construct and deploy software to meet the business need. Often referred to as predictive methodologies, they attempted to address software development as a strategic engineering exercise.
As the software development industry evolved and deployment expectations increased, many proponents began to argue that predictive strategic approaches could not maintain appropriate development velocities. More tactical approaches were required, ones that stressed development discipline, people instead of process, flexibility, and development in the "small"-- this resulted in the adoption of incremental software development approaches. Often referred to as adaptive methodologies, they attempted to address software development as a tactical team.
Both approaches have their strengths and weaknesses, but regardless of the the approach one chooses, adhering to the guiding principles of any given methodology is the key to success. Both can be incredibly successful or massive failures. For any methodology to succeed, a clear understanding of the core principles and deliverables is essential. In addition, the availability of appropriate resources, along with the discipline and skills required to deliver, are indispensable; without the appropriate resources, you will fail.
Sequential (predictive) SDLC methodologies
The classic example of a predictive SDLC methodology is the "waterfall model" – a set sequence of phases that flow as definable steps. This is usually presented as:
- Requirements Capture (Business and Software)
- Design (Business and Software)
- Testing and debugging
Each phase must be completed before the next one begins; methodologies derived from the waterfall model usually have a clear set of gates to define when a phase can begin and when the previous phase has been completed. Several commercial and non-commercial methodologies and supporting toolsets have been created around this predictive model, including some that attempt to address overall velocity by creating shorter iterations (i.e. Sashimi). Traditionally predictive models or "big design up front" are usually considered a good fit for:
- Mission critical functionality
- Organizations that contain a high percentage of junior developers
- Organizations that contain a large number of developers
- Stable business models where requirements do not change often
- Organization that demands order
These traditional qualifiers do not take into account the real-world success of adaptive methodologies in the "large." Perhaps a more appropriate selection criterion would be to ask the questions: "Is this a strategic or tactical initiative?" and "Will the deployment contain most, if not all, business functionality?" If the development is strategic in nature, and the deployment will contain most or all the business functionality, then most, if not all, aspects of predictive methodologies should be considered an appropriate fit.
The most popular and well-known predictive methodology is the waterfall methodology. While there are other methodologies that follow the linear, phased approach, the term waterfall has become the token predictive methodology in discussions debating the merits of predictive vs. adaptive. The strength of a predictive approach is its focus on structure and maintaining a holistic vision of the solution space. Its weakness is the inflexible rigor, but there is no reason not to harvest what you need from these methodologies with an eye for overall efficiencies.
Agile (adaptive) SDLC methodologies
Classic examples of a adaptive SDLC methodologies are Scrum, Extreme Programming (XP), or other methodologies that are considered "agile." Agile methodologies are defined as those that follow the Agile Manifesto –a set of core principles that support iterative development. The Agile Manifesto values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Furthermore, the original Agile Manifesto supports these underlying principles:
- Customer satisfaction by rapid delivery of useful software
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Even late changes in requirements are welcome
- Close, daily cooperation between businesspeople and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Self-organizing teams
- Regular adaptation to changing circumstances
Adaptive methodologies take an iterative or tactical approach to software development where the focus is on the abilities of the team to deliver functional software in small iterative packages. Traditionally adaptive or "light weight" methodologies are usually considered a good fit for:
- Non-mission critical functionality
- Organizations that contain a high percentage of senior developers
- Organizations that contain a small number of developers
- More dynamic business models where requirements change often
- Organizations that thrive on constant change
Once again, there are more than sufficient real-world examples to prove that adaptive methodologies do work in the "large." We can apply the same qualifying questions: "Is this strategic or tactical initiative?" and "Will the deployment contain most if not all business functionality?" If the development is tactical in nature and the deployment will contain a small subset of the overall business functionality, then most, if not all, aspects of adaptive methodologies should be considered an appropriate fit.
Adaptive methodologies range from Rapid Application Development (RAD), which basically prototypes products into existence, to Scrum, with its heavy reliance on team interaction, to XP, which takes adaptive to the extreme with its adoption of paired programming and constant reviews. These lighter more agile methodologies create software quickly, but they do tend to be rather tactical, often missing strategic opportunities.
Adaptive versus predictive
There have been some very heated debates over the merits of adaptive versus predictive SDLC methodologies over the last several years. Both "camps" have their proponents, but I believe both approaches have their merits when implemented appropriately; furthermore, there really is no reason not to pull the best aspects from both to harvest the maximum return from the development investment. For example, if you need to maintain a holistic view of the application landscape and need to increase overall deployment velocity, then why not pull from aspects of both in order to meet your needs. You could use the requirement management practices more closely associated with predictive methodologies to maintain your holistic view while adopting adaptive development techniques to gain appropriate deployment velocity.
That being said, in terms of pure development velocity, adaptive methodologies do appear to be faster. Whether this is due to the adaptive approach or due to the additional "buy-in" from the business because they see continuous progress in small perceivable sprints is really beside the point-- the software is delivered faster. With increased and continuous user input, you are much more likely to develop and deploy the appropriate solution.
Moving from a Waterfall approach to Agile