-
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.
PMI
and PMP
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
SEI,
CMM, and CMMI
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
Agile
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.
|
Term |
Year |
Author /
Attributor / Owner |
|
Waterfall |
1970 |
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.
|
|
Spiral |
1985 |
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 |
1998 |
IBM/Rational |
|
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. |
|
Scrum |
1986
1993
1995 |
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) |
1996 |
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) |
1997 |
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 |
2000 |
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 |
2004 |
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
Bibliography
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).
|
