When it comes to methodologies, one size doesn't fit all. By examining all the options, you can create a mix-and-match approach that best suits your project.
December 01, 2003
URL:http://www.drdobbs.com/the-right-tool-for-the-job/184415067
Software Development
December 2003
One of my grandfather’s favorite sayings was “Use the right tool for the job”—common-sense advice that applies to a wide range of situations. Unfortunately, as Mark Twain observed, common sense isn’t very common—many organizations seem to struggle with identifying the best software processes for them. To succeed, you must understand the available options, as well as the issues surrounding software process selection.
“Common Software Processes” illustrates the leading software processes—and there’s a wide range to choose from. Some processes are agile; some are not. Some are full lifecycle; some are not. Some are well defined; some, such as Extreme Programming, are nearly philosophical in nature. The good news? There’s a lot to choose from. That’s the bad news, too.
Waxing Philosophical
How do you pick the right tool for the job? When it comes to software process selection, I’m guided by several key philosophies:
Risk-Based Selection
It’s easy to say that you need to use the right process for your project—but very difficult to achieve. Barry Boehm and Richard Turner provide good advice in Balancing Agility with Discipline: A Guide for the Perplexed (Addison-Wesley, 2003), presenting a risk-based approach for choosing a methodological strategy for a project. They advise that uncertain requirements, complex technologies and low employee turnover favor agile projects, whereas larger teams and a diverse group of stakeholders lend themselves to more prescriptive methods. They note that you’ll probably need to tailor agile methods with prescriptive techniques to scale them, and, similarly, tailor prescriptive methods with agile techniques to make them more effective—it isn’t a black and white world, after all.
My experience is that cultural issues are important, and Boehm and Turner concur. Do the people on a project team require a well-defined process or are they comfortable with one that is looser? “Comparing Leading Software Processes” evaluates processes using two factors: definition and scope. The horizontal axis indicates how well defined the processes are, while the vertical axis addresses the methodologies’ scope, or completeness. Some methods, such as Agile Modeling (AM) and Test-Driven Development (TDD), are partial approaches, whereas others, such as DSDM and FDD, address the entire lifecycle. If you need to develop a single project, processes such as XP or RUP are good candidates. However, if you must address the full system lifecycle, you may need to adopt the EUP or IEEE 12207, as well.
To pick the right process for your job, you need to understand the strengths and weaknesses of your options, and mix and match techniques to arrive at the right approach. Many organizations find that the partial processes such as Scrum, AM and TDD provide commonality among teams following differing base processes such as XP, FDD and RUP. Maybe things aren’t as difficult as they appear, after all.
Scott W. Ambler is a senior consultant with Ronin International Inc. His latest book is Agil Database Techniques: Effective Strategies for the Agile Software Developer (Wiley, 2003)
Software Development
The Right Tool for the Job
When it comes to methodologies, one size doesn’t fit all. By
examining all the options, you can create a mix-and-match approach that best
suits your project.
By Scott W. Ambler
Software Development
The Right Tool for the Job
When it comes to methodologies, one size doesn’t fit all. By
examining all the options, you can create a mix-and-match approach that best
suits your project.
By Scott W. Ambler
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.
December 2003
Common Software Processes
Process/Method
Description
When/How to Use
It
Agile
Data (AD)
A partial agile methodology focusing on techniques that support evolutionary
(iterative and incremental) database development.
Tailor AD philosophies and techniques into other evolutionary processes.
Agile
Modeling (AM)
A partial practices-based methodology that describes techniques for effective
modeling and documentation of systems.
Tailor AM principles and practices intoother agile or near-agile processes.
Dynamic System
Development Method (DSDM)
An agile software development methodology that has received ISO 9001 certification.
In many ways, DSDM is a formalization of the Rapid Application Development
(RAD) methodologies of the 1980s.
Appropriate for developing user interface–intensive systems and/or
complex business applications.
Enterprise
Unified Process (EUP)
A rigorous full lifecycle methodology that includes development, operation
and retirement of software-based systems. The EUP extends the RUP to a multisystem
view that includes enterprise architecture, reuse management, portfolio
management and people management activities.
You’ve been successful at several RUP projects and wish to now take
the full system lifecycle into account, as well as cross-project issues
such as portfolio management, strategic reuse and enterprise architecture.
Extreme
Programming (XP)
An agile software development methodology that focuses on the critical
activities required to build software.
Small, colocated project teams (4–10 people), where the requirements
are un-certain, and a good relationship (potentially) exists with project
stakeholders.
Feature
Driven Development (FDD)
An agile software development methodology based on short iterations that
includes explicit modeling activities.
Small project teams (4–20 people), uncertain requirements, and your
team is willing to follow a modeling-driven approach.
IEEE
12207
A rigorous full lifecycle methodology process that includes development,
operation and retirement of software-based systems.
Medium to large project teams (20+ people). You are mandated (for example,
by government) to follow this approach, or you intend to outsource part
of the development effort.
Rational
Unified Process (RUP)
A rigorous software development process that is iterative
and incremental. Can potentially be instantiated in an agile manner (see
Gary Evans’ “Palm-Sized
Process: Point-of-Sale Gets Agile,” Sept.
2001), although this rarely occurs successfully in practice.
Medium to large project teams (10+ people), or where a phased approach
is required to support the outsourcing of construction.
Scrum
A partial agile methodology that describes effective project management
techniques.
Tailor Scrum into agile or near development methods.
Test Driven Development (TDD) (See my article, “Test-Driven
Development,” Oct.
2002)
A partial development methodology that describes how to write high-quality,
tested source code.
Tailor TDD into any development or full-lifecycle process.
December 2003
Comparing Leading Software Processes
The horizontal axis indicates how well defined the processes are, showing
“code and fix” as ad hoc (undefined), whereas processes such as
RUP and IEEE 12207 are prescriptive (very well defined).