IEEE Software (March/April)

88 Pages·2002·2.852 MB·English

from the editor
Editor in Chief: Steve McConnell (cid:2) Construx Software (cid:2) [email protected]
Real Quality For Real
Engineers
Steve McConnell
F
or decades, experts have struggled to visible to the software’s developers) include
define quality. Edwards Deming said maintainability, flexibility, portability, re-
that the only definition of quality that usability, readability, scalability, testability,
mattered was the consumer’s.1 Joseph and understandability. The ities that affect
Juran said that quality was fitness for the software’s external quality (visible to the
use.2 Philip Crosby provided the customer) include usability, reliability, adapt-
strictest definition of quality as “confor- ability, and integrity, as well as correctness,
mance to requirements.”3 accuracy, efficiency, and robustness.4
Some of these characteristics overlap, but
Conformance to all have different shades of meaning that are
requirements desired more in some cases and less in others.
Although they differ on the de- The attempt to maximize certain characteris-
tails, quality experts agree that tics invariably conflicts with the attempt to
the customer’s view of require- maximize others. Figure 1 presents a sum-
ments is critically important. For mary of the ways in which external quality
that reason, I’ve found Crosby’s characteristics affect each other.
definition of “conformance to re- These characteristics will be prioritized
quirements” to be the most useful differently on different projects, which means
definition in examining software the software quality target is always chang-
quality. Taking into account ing. Finding an optimal solution from a set of
many software projects’ tendency to elicit competing, changing objectives is challeng-
some but not all of the customer’s complete ing, but that’s part of what makes software
requirements, “requirements” cannot be in- development a true engineering discipline.
terpreted solely as the written requirements.
Requirements must also include implicit re- From product quality to project
quirements—those that the customer as- quality
sumes regardless of whether the develop- When software people refer to quality, we
ment team happens to write them down. usually refer to the quality of the software
Thus, the working definition of quality that product we are producing. From a manage-
I use is “conformance to requirements, both ment perspective, however, customers also
stated and implied.” have requirements for projects. I think it’s
reasonable to draw an analogy from prod-
The “ities” of software quality ucts to projects, conceiving project qualityas
In addition to specific functional require- conformance to requirements, both stated
ments, software quality is also affected by and implied. Customers’ functional require-
common nonfunctional characteristics that ments for projects draw from a small num-
are often referred to as the “ities.” The ities ber of possible attributes, namely schedule,
that affect software’s internal quality (quality resources, cost, and quality of the product
Copyright © 2002 Steven C. McConnell. All Rights Reserved. March/April 2002 IEEE SOFTWARE 5
FROM THE EDITOR
How focusing
on the factor
BDoEoPkAshReTlMf: EWNaTrr eEnD KITeuOfRfeSl, btthoee lto hfwaec ratiogffrhetcts Correctness Usability Efficiency Reliabilty Integrity Adaptability Accuracy Robustness
[email protected]
⇑ ⇑ ⇑ ⇑ ⇓
Construction: Andy Hunt and Dave Thomas, Correctness
Pragmatic Programmers,
{Andy, Dave}@pragmaticprogrammer.com Usability ⇑ ⇑ ⇑
Country Report: Deependra Moitra, Lucent Technologies
[email protected] ⇓ ⇑ ⇓ ⇓ ⇓ ⇓ ⇓
Efficiency
Design: Martin Fowler, ThoughtWorks,
[email protected] ⇑ ⇑ ⇑ ⇑ ⇑ ⇓
Reliabilty
Loyal Opposition: Robert Glass, Computing Trends,
[email protected] ⇓ ⇑ ⇑
Integrity
Manager: Don Reifer, Reifer Consultants,
[email protected] ⇓ ⇑ ⇑
Adaptability
Quality Time: Jeffrey Voas, Cigital,
[email protected] ⇑ ⇓ ⇑ ⇓ ⇑ ⇓
Accuracy
STAFF
⇓ ⇑ ⇓ ⇓ ⇓ ⇑ ⇓ ⇑
Senior Lead Editor Robustness
Dale C. Strok
[email protected] ⇑ Helps ⇓ Hurts
Group Managing Editor
Crystal Chweh
Figure 1. Interactions between product quality external
Associate Editors
Jenny Ferrero and characteristics.
Dennis Taylor
Staff Editors
Shani Murray, Scott L. Andresen,
produced. In some cases, a customer (cid:2) Sustainability: The duration for
and Kathy Clark-Fisher
Magazine Assistants might prioritize cost higher—in oth- which a project can continue using
Dawn Craig ers, schedule or product quality. its current practices.
[email protected]
Additionally, project quality includes (cid:2) Visibility:The ability of a customer
Pauline Hosillos
nonfunctional requirements such as to accurately determine project sta-
Art Director
Toni Van Buskirk tus and progress.
Cover Illustration (cid:2) Efficiency: Minimal use of sched-
Dirk Hagner
ule, budget, and staff to deliver a These project characteristics inter-
Technical Illustrator
particular software product. play with each other just as the soft-
Alex Torres
(cid:2) Flexibility: The extent to which ware quality attributes do. Figure 2
Production Artist
Carmen Flores-Garvey the project can be modified to de- shows the interactions. In addition to
Executive Director liver software other than that for the interactions shown in Figure 2,
David Hennage
which the project was originally some of these project quality character-
Publisher
Angela Burgess intended or to respond to changes istics tend to support or undermine the
Assistant Publisher in project goals. various product characteristics summa-
Dick Price (cid:2) Improvability: The degree to rized in Figure 1.
Membership/Circulation which project experiences can be Different projects have different
Marketing Manager
Georgann Carter fed back into the project to im- priorities among efficiency, flexibility,
Advertising Assistant prove project performance. improvability, and the other character-
Debbie Sims (cid:2) Predictability: The degree to which istics shown in Figure 2. An estab-
CONTRIBUTING EDITORS a project’s cost, schedule, and prod- lished business might place high values
uct quality outcomes can be fore- on efficiency, predictability, improv-
Greg Goth, Denise Hurst, Gil Shif, Keri Schreiner,
and Margaret Weatherford cast in advance. ability, and repeatability. A start-up
(cid:2) Repeatability: The degree to which company might place a higher value
the project after the current project on robustness and visibility; it might
Editorial:All submissions are subject to editing for clarity,
style, and space. Unless otherwise stated, bylined articles can be conducted using practices not value sustainability and repeata-
and departments, as well as product and service descrip- similar to those used on the cur- bility at all. This suggests that there
tions, reflect the author’s or firm’s opinion. Inclusion in
IEEE Softwaredoes not necessarily constitute endorsement rent project. isn’t one best definition of project
by the IEEE or the IEEE Computer Society.
(cid:2) Robustness: The degree to which quality for all projects; the best defi-
To Submit:Send 2 electronic versions (1 word-processed
and 1 postscript or PDF) of articles to Magazine Assistant, the project will continue to func- nition depends on the project’s con-
IEEESoftware, 10662 Los Vaqueros Circle, PO Box 3014,
Los Alamitos, CA 90720-1314; [email protected]. Ar- tion in the presence of stressful en- sumers and those consumers’ specific
ticles must be original and not exceed 5,400 words including vironmental conditions. project requirements.
figures and tables, which count for 200 words each.
6 IEEE SOFTWARE March/April 2002
FROM THE EDITOR
EDITOR IN CHIEF:
Steve McConnell
10662 Los Vaqueros Circle
Los Alamitos, CA 90720-1314
[email protected]
How focusing
obtthonee ltto hhfwaeec ratfioagffrchettcotrs Efficiency Flexibility ImprovabilityPredictabilityRepeatabilityRobustness SustainabilityVisibility ASESDAOIlTCaOnIA RMT I.EN D ECaDvHiIIsET, FOO REmMSn EiI-RNVIi TsCtUaHSI:EF
⇑ ⇓ ⇓ ⇑ Design: Maarten Boasson, Quaerendo Invenietis
Efficiency
[email protected]
Construction: Terry Bollinger, Mitre Corp.
⇑ ⇓ ⇑ ⇓
Flexibility [email protected]
Requirements: Christof Ebert, Alcatel Telecom
Improvability ⇑ ⇑ ⇑ ⇑ ⇑ ⇑ ⇑ [email protected]
Management: Ann Miller, University of Missouri, Rolla
⇑ ⇓ ⇑ ⇓ ⇑ [email protected]
Predictability Quality: Jeffrey Voas, Cigital
[email protected]
⇓ ⇓ ⇑ ⇑ ⇑
Repeatability Experience Reports: Wolfgang Strigel,
Software Productivity Center; [email protected]
⇓ ⇑ ⇑ ⇑
Robustness
EDITORIAL BOARD
⇓ ⇑ ⇑ ⇑
Sustainability Don Bagert, Texas Tech University
Richard Fairley, Oregon Graduate Institute
Visibility ⇑ ⇑ ⇑ ⇑ ⇑ ⇑ ⇑ ⇑ Martin Fowler, ThoughtWorks
Robert Glass, Computing Trends
⇑ Helps ⇓ Hurts Andy Hunt, Pragmatic Programmers
Warren Keuffel, independent consultant
Brian Lawrence, Coyote Valley Software
Karen Mackey, Cisco Systems
Figure 2. Interactions between project quality characteristics. Deependra Moitra, Lucent Technologies, India
Don Reifer, Reifer Consultants
Suzanne Robertson, Atlantic Systems Guild
Dave Thomas, Pragmatic Programmers
Real engineering team, manager, and sponsoring orga- INDUSTRY ADVISORY BOARD
One difference between a crafts- nization can all be considered con- Robert Cochran, Catalyst Software (chair)
man and an engineer is that a crafts- sumers of a project. A manager Annie Kuntzmann-Combelles, Q-Labs
Enrique Draier, PSINet
man defines quality on his own might consider a project to have high
Eric Horvitz, Microsoft Research
terms, whereas an engineer defines quality if it provides good visibility, David Hsiao, Cisco Systems
quality through his customers’ eyes. robustness, and repeatability. The Takaya Ishida, Mitsubishi Electric Corp.
Dehua Ju, ASTI Shanghai
The craftsman settles into a way of project team might value efficiency, Donna Kasperson, Science Applications International
working that suits him personally, improvability, and sustainability. The Pavle Knaflic, Hermes SoftLab
Günter Koch, Austrian Research Centers
while the engineer adapts his ap- sponsoring organization might value
Wojtek Kozaczynski, Rational Software Corp.
proach on each project to best satisfy predictability and flexibility. Tomoo Matsubara, Matsubara Consulting
his customer’s requirements. A manager who factors product Masao Matsumoto, Univ. of Tsukuba
Dorothy McKinney, Lockheed Martin Space Systems
Software engineering purists ar- quality into the project plans but ig- Nancy Mead, Software Engineering Institute
gue that software should always be nores project goals takes an abridged Stephen Mellor, Project Technology
Susan Mickel, AgileTV
produced to the highest level of view of software quality. One hall-
Dave Moore, Vulcan Northwest
quality, by which they mean the mark of engineering work is the con- Melissa Murphy, Sandia National Laboratories
highest levels of product quality. stant balancing of trade-offs. With Kiyoh Nakamura, Fujitsu
Grant Rule, Software Measurement Services
End-user requirements certainly the extensive trade-off decisions re- Girish Seshagiri, Advanced Information Services
should be considered, but the orga- quired to balance both software Chandra Shekaran, Microsoft
Martyn Thomas, Praxis
nization that builds and sells the product attributes and software pro-
Rob Thomsett, The Thomsett Company
software is another consumer whose ject goals, software personnel have John Vu, The Boeing Company
requirements must be taken into ac- abundant opportunities to hone their Simon Wright, Integrated Chipware
Tsuneo Yamaura, Hitachi Software Engineering
count. The product characteristics engineering skills in this area.
that constitute quality to the end
MAGAZINE OPERATIONS COMMITTEE
user do not necessarily satisfy the
George Cybenko (chair), JamesH. Aylor, Thomas J.
software-developing organization’s References Bergin, Frank Ferrante, Forouzan Golshani, Rajesh
Gupta, Steve McConnell, Ken Sakamura, M. Satya-
project quality requirements. 1. W. Edwards Deming, Out of the Crisis, MIT narayanan, Nigel Shadbolt, Munindar P. Singh,
As Deming pointed out in Out of Press, Cambridge, Mass., 2000. Francis Sullivan, James J. Thomas
2. J.M. Juran, Juran’s Quality Handbook, Mc-
the Crisis, different consumers can
Graw-Hill, New York, 1998. PUBLICATIONS BOARD
have different definitions of quality 3. P.B. Crosby, Quality Is Free: The Art of Mak-
Rangachar Kasturi (chair), Mark Christensen,
for the same product, and this ap- ing Quality Certain, Mentor Books, Denver
George Cybenko, Gabriella Sannitti di Baja, Lee
Colo., 1992.
plies as much to project quality as it Giles, Thomas Keefe, Dick Kemmerer,
4. S. McConnell, Code Complete, Microsoft Anand Tripathi
does to product quality. The project Press, Redmond, Wash., 1993.
March/April 2002 IEEE SOFTWARE 7
manager
Editor: Donald J. Reifer (cid:2) Reifer Consultants (cid:2) [email protected]
Ten Deadly Risks in
Internet and Intranet
Software Development
Donald Reifer
W
hen I think of Internet develop- erwise. As the economy fizzled last year,
ment, I picture a handful of devel- large firms stopped expanding, instead con-
opers working frantically against solidating and moving to the Web to cut
the clock amid the litter of take- costs. Yes, lots of startups bit the dust, but
out food containers to churn out in many cases Big Business accelerated its
code for the Web. As you might move to the Web. Firms such as GE have re-
expect, these developers tend to be recent portedly saved millions by pursuing such
graduates who use the latest technology to strategies (James P. Pelz, “GE Takes to the
turn out applications that live for Net to Lower Company Costs,” Los Angeles
weeks but not years. Times, 9 Oct. 2000, pp. C1–5).As an exam-
Not that this is bad. Some of ple of the impact, a large financial client of
the best work I have seen in years mine currently has over 2,000 programmers
has come about this way. The involved in Web development. Five years
reason is simple. With their “We ago, its 3,000-member software workforce
can do anything” attitude, these worked solely on client-server applications.
teams are willing to work on
technology’s proverbial bleeding Traditional versus Internet and
edge. They know what they pro- intranet development risks
duce is going to change, so they Based on this background information,
aren’t afraid to try something you might well ask, “As firms large and
new. That’s because they know they can fix small move applications across the enter-
problems as they occur without suffering the prise to the Web, what risks do they face?
severe penalties they might have faced in ear- How do these compare with risks that
lier development environments. they’ve previously encountered?” Table 3
This article contrasts the current Internet answers these questions. In the first two
and intranet development climate with ear- columns, I’ve listed the risks in terms of
lier releases (see Table 1) and identifies the their cost and schedule impacts for both tra-
10 greatest risks facing today’s Young Inter- ditional as well as Internet/intranet develop-
net/intranet Lions. ments. You’ll see why I consider them
deadly. The noticeable differences in risks
Where’s the action on today’s stem from the project characteristics (large
Internet? versus small teams, technology-driven ver-
With the world economy’s recent slow- sus requirements-driven, and so forth) and
down, you might easily think that the move who’s moving to the Net (large firms instead
to the Net has also slackened. Don’t believe of small startups, for example). While many
it. As Table 2 shows, current trends in Inter- of the risks are familiar to traditional proj-
net and intranet project work indicate oth- ects, the impact of unrealistic expectations
12 IEEE SOFTWARE March/April 2002 0740-7459/02/$17.00 © 2002 IEEE
MANAGER
and technology volatility should strikeyou as new and
important. Don’t get confused by Table 3. The mitiga-
tion strategies listed are aimed primarily at Internet/in-
tranet developments.
How do I mitigate these risks? RAPID A game-changing, non- WHAT IS DSDM? DSDM
proprietary rapid and agile (Dynamic Systems Development
Just identifying the risks is easy. Knowing how to development project model for Method) is a framework that
reduce their deadly consequences is much harder. The building business solutions of any encompasses all aspects needed
size in short timeframes. It shortens
third column of Table 3 lists my recommendations for for successful delivery: people,
the clock-speed (and time to market)
dealing with primarily the Internet/intranet risks. for delivery of core business process and technology - with
emphasis on people; most
Most of these mitigation strategies aren’t new, but benefits. It is the only approach that
projects fail as a result of
can guarantee delivery on an exact
some are innovative, I believe. That’s because, until re- people-based problems.
day under tight, Internet-time
cently, issues identified in Internet and intranet pro- DSDM is primarily non-
deadlines.
jects hadn’t surfaced or were deemed less important. prescriptive so it is
For example, you need to specifically align Web de- AGILE Created using synergistic with many
agile techniques and now software development
velopment with your business goals. Else, why build in version 4.0, it continues methods such as XP,
them? As another example, concepts such as nightly to be evolved using DSDM, Scrum, Adaptive, Crystal,
builds, weekly releases to the field, and having the cus- the only Agile Method created DSDM etc. The framework
using an Agile Method. provides underlying
tomer function as a member of the programming team
principles, processes, project
are novel. NON-PROPRIETARY lifecycle, artifacts, key roles and
If you’re interested in risk management, you’ll find The non-proprietary DSDM method responsibilities, and guidance on
evolved collaboratively over the last
many publications on the topic, many based on expe- management techniques and
6 years by an International nonprofit
development techniques. It's a
rience rather than theory. But, be warned. In most consortium. It's tool and technology
tool to effectively:
cases, you will have to extend this experience into the independent. No tools to purchase * Understand,
or be hamstrung by.
Internet/intranet world as you try to address the pecu- * Plan,
liarities of Web projects. That’s not so bad when you BUSINESS CENTERED Built in * Communicate,
think about it. It’s easier to extend existing knowledge partnership with big business for * Control, and
business. DSDM will scale from five * Deliver all projects.
than to plow new ground.
to hundreds of developers. As the
T most business benefit focused LEARN MORE visit the DSDM
he list of 10 deadly Internet and intranet risks method in the world, many of the Consortium web site at
won’t surprise many. But based on them, software world's largest companies and http://www.dsdm.org or contact
numerous government bodies have DSDM directly at
engineers need to strike a balance between the tech- established DSDM as their standard. 800-610-6776.
nologies that many in the Internet world depend DSDM is ISO 9000 certified.
Table 1
Traditional versus Internet/intranet development
Characteristic Traditional approaches Internet/intranet development
Primary goal Build quality software products at minimum cost Bring quality products to market as quickly as possible
Typical project size Medium to large (20 or more team members) Small (3 to 7 team members)
Typical timeline 10 to 18 months Several weeks to 6 months
Development approach Classical requirements-based paradigms; done Rapid application or spiral development
employed phased or incrementally; document-driven with (Rational Unified Model, MBase, and so on)
focus on getting the design right before coding
Primary technologies used Traditional methods; object-oriented approaches, Agile methods; component-based approaches; multimedia;
procedural languages (C, C++); limited, multimedia, new language environments (Java, XML, HTML, and so
CASE tools; use cases; lots of modeling; and so on forth); visualization; and so on
Processes employed Software Capability Maturity Model, SPICE, Generally ad hoc, pairwise programming; refactoring
ISO-based
Products developed Code-based systems; mostly new; some reuse; lots Object-based systems; many reusable building blocks; few
of legacy involved; many external interfaces; external interfaces; little interaction; simple applications
lots of interactions; often complex applications
People involved Professional software engineers typically with 5+ Less experienced programmers; users as developers;
years of experience in at least two pertinent graphic designers; new hires right out of school
application domains
March/April 2002 IEEE SOFTWARE 13
MANAGER
upon, on the one hand, and the tried practices have emerged for Internet “Good software engineering pays off
and true processes that promote risk development, many time-tested soft- on Internet applications, too.” Try
management and help us achieve ware engineering practices were jetti- them, they’ll make your job easier.
business goals, on the other. soned based on the faulty belief that
The “just do it” attitude of the teams don’t have time to put these
past few years has done as much practices to work. By looking at the
harm as good to the software engi- list of deadly risks, we can recognize Don Reiferis president of Reifer Consultants and visiting
associate of the Center for Software Engineering at the Univer-
neering profession. While a few good our mistake. My message is that
sity of Southern California. Contact him at [email protected].
Table 2
Who’s Developing Internet/intranet Applications?
Time Period Who’s playing? What’s their primary interest?
1980s Researchers Technical issues (protocols, for example)
Early 1990s Internet service providers Meeting the demand for performance (many subscribers)
Late 1990s Internet startups Content is king as everyone moves to the Net
Now Large firms as well as yet more startups Save money, collaborate, and build an e-business infrastructure
Table 3
Traditional and Internet and intranet project risks and mitigation strategies
Traditional risks Ten deadly Internet and intranet project risks Internet/intranet Risk mitigation strategies
Personnel shortfalls Personnel shortfalls Bring on a skilled core team.
Have the team mentor new people.
Make training and teamwork part of the culture.
Hire top-notch personnel while the job market remains soft.
Unrealistic budgets and schedules Misalignment with business goals Align developments with business goals and highlight
importance of development.
Volatile requirements Unrealistic customer and schedule expectations Make the customer part of the team.
Set schedule goals around frequent deliveries of varying
functionality.
Shortfalls in externally Volatile technology, changing so rapidly that Introduce new technology slowly, according to a plan.
furnished components it is hard to keep up (SML, .NET, Persistence, J2EE, Use technology because it supports business goals,
and so forth) not because it is the latest and greatest thing to do.
Gold-plating Unstable software releases (although the software Stabilize requirements and designs as much as practical.
works, it performs poorly and crashes frequently) Plan to refactor releases from the start.
Don’t deliver applications when quality is poor and system
crashes (say “no”).
Released software has poor quality Constant changes in software functionality Manage functionality using releases.
(shooting at a moving target) Deliver working prototypes before you target new functionality.
New methods and unstable tools Even newer methods and more unstable tools (causes Introduce new methods and tools slowly, as justified by
(primarily causing schedule delays) heartburn, headaches, and schedule delays) business cases, not merely because they are new and
appealing.
Make sure methods and tools are of production quality.
High turnover (especially of High turnover (especially of those personnel skilled Set clear expectations and measures of success.
skilled personnel) in the new technology) Make effort a learning exercise (to make staff feel they are
learning, growing, and gaining valuable experience).
Friction between developers Friction within the team (lack of leadership, overwork, Staff the team carefully with compatible workforce.
and customers unrealistic expectations, and so forth) Build team and provide it with leadership.
Manage conflicts to ease friction.
Unproductive office space Unproductive office space Acquire dedicated workspace for the team.
Appropriate collaboration tools.
Lots of space available for meetings and pizza.
14 IEEE SOFTWARE March/April 2002
requirements
Editor: Suzanne Robertson (cid:2) The Atlantic Systems Guild (cid:2) [email protected]
Managing Requirements
for Business Value
John Favaro
Requirements engineers are often asked the question, “What will the investment in require-
ments give to our business?” John Favaro uses his experience in financial engineering to help
us answer this question by providing some tools for quantifying the value of requirements.
—Suzanne Robertson
M
anaging requirements for busi- where requirements simply arrived, if you
ness value? What’s there to man- were lucky, on a one-way street from the
age? Aren’t they just...there?” customer. An analyst who masters the re-
Such perplexity was perfectly un- quirements process can become an active
derstandable in the good old participant in the strategic conception of a
days, when all you had to do was system or product. He or she can elicit and
get the requirements from your formulate requirements in such a way that
customer, design your system, the path from requirement to implemented
and produce one of those awful system feature is illuminated in all of its con-
conformance matrices that sequences, both technical and economic. Of
demonstrated that you had im- course, we already know that a robust re-
plemented each and every one of quirements process is a key factor in resolv-
the requirements in your system. ing problems early in the life cycle, with all
Against this dreary backdrop of the familiar economic benefits. But an ac-
conformance matrices and the tively managed requirements process gives
like, it is indeed hard to imagine you much more than that. Requirements an-
a role for requirements in the de- alysts and customers alike can discover a
velopment and execution of busi- new flexibility. Although there are always a
ness strategy. But, as the song says, the few nonnegotiable requirements (such as no
times, they are a changin’. We are now look- loss of human life), the vast majority are
ing outside the traditional boundaries and suitable for examination, reformulation, ne-
developing ways of getting maximum busi- gotiation, or adaptation. As unexpected
ness value from our investment in require- consequences are uncovered (for example,
ments. This column discusses three ways of the projected high cost of implementation),
realizing this value: managed requirements the analyst can cooperate with the customer
process, requirements agility, and contrac- to search for other, equally satisfactory re-
tual innovation. quirements formulations. The economic
tools of cost–benefit analysis for this process
Toward requirements reuse have been well understood for years.
The first important change in recent years A full cost–benefit analysis of a require-
has been the emergence of a true, actively ment (or group of requirements) needs an
managed requirements process, which re- investment in time and resources. Further-
places the passive approach of the past more, assessing the cost–benefit of require-
0740-7459/02/$17.00 © 2002 IEEE March/April 2002 IEEE SOFTWARE 15
REDQEUPITR ETMITELNETS
ments is more difficult than design or system. Requirements that once were say, $10 implementation cost versus
implementation, because require- vague become crystal clear as uncer- $15 in benefits. But, an enormously
ments are the furthest upstream in tainty is resolved; a requirement once uncertain environment undermines the
the development process. Conse- thought to be rigid could be negoti- cost–benefit analysis. The customer
quently there are more unknown fac- ated and reformulated to permit sev- admits that the uncertainty (“volatil-
tors; it can take a full development eral alternative features that could ity”)of his estimate is as much as 100
cycle before the complete economic satisfy it. percent. If the knowledge manage-
impact of a requirement is known. Such changing conditions provide ment system is never introduced,
Perhaps you can now understand opportunities for the strategist to in- then it will have been a waste of time
why requirements researchers are crease the value of his process. How- to provide the access capability.
studying techniques for creating re- ever, the traditional tools of cost–ben- However, if it is introduced, the ac-
usable requirements.1 The first time efit analysis that apply so well to the cess capability could become far
you conceive a system based on a re- noniterative requirements process more valuable than originally envi-
quirement, estimating the costs and have proven less adequate to help the sioned. The customer says that the
benefits might be difficult. But, after requirements analyst examine the eco- uncertainty will be resolved in a year.
carrying through the system to imple- nomic value of his or her newfound The XP process permits the strategy
mentation, you will have a much bet- strategic flexibility—and this brings of waiting until a future iteration to
ter idea of the costs and benefits trig- me to the third important change in re- take up the requirement. Is there any
gered by that requirement. A well- cent years. I’d like to draw now on my way to calculate the economics of
formulated, measurable, reusable re- interaction with Kent Beck over the this alternative strategy? The tools of
quirement—including a full cost– past few years to discuss some cutting- option pricing theory can in fact cal-
benefit analysis as part of its descrip- edge ideas about the relationship be- culate the value of waiting to be
tion—is every bit as valuable as a tween strategy and finance and their slightly less than $8—more than the
reusable software module. effect on requirements management. $5 of benefit accrued by immediate
development.4
Agile requirements Contractual innovation The option to delay implementing
The second important change has Evaluating the financial impact of a requirement is an example of the
been the emergence of strategies for strategic decisions has been the sub- way that contingent claims analysis
confronting the bête noire of the re- ject of great debate since the dawn of is making a profound impact on the
quirementsprocess: vague and chang- economics as a discipline. In a list of requirements process in the form of
ing requirements. These strategies are the Top 10 Unsolved Problems in Cor- contractual innovation, a result of
best reflected in a new generation of porate Finance first compiled by the the new discipline of financial engi-
software life cycles known as agile legendary financial authors Richard neering born with the advent of op-
processes (see www.agilealliance.org). Brealey and Stewart Myers in 1981 tion pricing theory. Beck likes to say
Some prominent examples of agile and unchanged in last year’s sixth edi- that unlike fixed-scope traditional
processes include Alistair Cockburn’s tion of their classic textbook Princi- contracts, XP contracts have op-
CrystalMethods, Bob Charette’s Lean ples of Corporate Finance, the finan- tional scope: every iteration provides
Development, and Jim Highsmith’s cial impact was ranked Number 1.3In a formal decision point in which the
Adaptive Software Development. recent years, people have placed hope customer can change direction, aban-
The common denominator of these in a new branch of financial theory doning requirements, introducing
agile processes is the iterative devel- known as contingent claims analysis— new requirements, or selecting be-
opment paradigm, which breaks up or more popularly, real options— tween alternative requirements.
the tradition of upfront requirements made possible by the breakthroughs For example, you sign such con-
elicitation and analysis. No longer do in the 1970s in option pricing theory. tracts not for a fixed set of functional-
you fire and forget requirements and In this approach, the opportunities ity, but for a team’s best effort for a
then move on to the next phase. Re- created by strategic flexibility are eval- fixed period at a fixed price. The pre-
quirements may be introduced, mod- uated with the financial tools of op- cise scope to be implemented will be
ified, or removed in successive itera- tion pricing theory. negotiated periodically over the life of
tions. As Kent Beck (chief evangelist Let’s take an example from XP. the contract, much as professional ser-
of Extreme Programming, the most Suppose the customer requires your vices contracts are run today. Changes
visible of the agile processes) exhorts application to provide access to an in the team’s actual velocity and the
us, requirements management should enterprise-wide knowledge manage- relative estimates attached to each fea-
“embrace change.”2 Business condi- ment system that he or she is con- ture are factored into these scope ne-
tions change, giving rise to new re- templating introducing in a few gotiations, as are changes in the per-
quirements; requirements thought to months. A simple cost–benefit analy- ceived relative value of these features.
be critical turn out not to be as the sis on the system features that would Option pricing theory yields some
customer sees the first versions of the satisfy this requirement is positive, surprising insights to the economic
16 IEEE SOFTWARE March/April 2002
REDQEUPITR ETMITELNETS
value of such contracts. For instance, Adding value age,” or to “minimize risk,” or even to
there is an exotic type of option known What does all this mean for you as a “satisfy the customer.” The purpose of
as a best-of or rainbow option. The requirements analyst? As the require- the requirements process is to add busi-
owner possesses two options, of which ments process evolves to embrace in- ness value. It is a subtle shift in perspec-
only one can be exercised. The rain- creased strategic flexibility, and the new tive for the requirements analyst, but it
bow option has the most value when financial tools of contingent claims makes all the difference because it puts
the alternatives are negatively corre- analysis mature, requirements become you in the position of managing re-
lated—that is, when the same condi- an important currency in system char- quirements to make the most of your
tions that increase one alternative’s acteristic negotiation. By learning to strategic opportunities.
value will decrease the other’s. This create reusable requirements with a
implies that a contract’s value is en- companion cost–benefit analysis, you
hanced by contradictory requirements. bring valuable material to the table References
For example, two requirements each from the very beginning. By studying 1. S. Robertson and J. Robertson, “Chapter 12:
Reusing Requirements,” Mastering the Re-
specifying the application to run on a the new generation of agile develop-
quirements Process, Addison-Wesley, Reading,
different platform is a rainbow option. ment processes, you become fluent in Mass., 1999, pp. 218–234.
If the choice can be delayed to some the strategic possibilities to add value to 2. K. Beck, Extreme Programming Explained:
Embrace Change, Addison-Wesley, Reading,
later time, it adds value for the cus- the requirements process over the entire
Mass., 1999.
tomer, letting him hedge the ultimate product life cycle. By learning some- 3. R. Brealey and S.C. Myers, Principles of Cor-
platform choice in the contract. thing about the new tools of financial porate Finance, McGraw-Hill, New York,
2000.
Similarly, a requirement whose util- analysis I’ve introduced, you can better
4. M. Amram and N. Kulatilaka, Real Options:
ity is uncertain (estimated cost and understand how strategic flexibility in Managing Strategic Investment in an Uncer-
value are close) gains value by inclusion the requirements process adds value. tain World, Harvard Business School Press,
Cambridge, Mass., 1999.
in an optional scope clause, because the For that is what the requirements
option to delay implementation has process should be about. If you remem-
demonstrable economic value. Where ber nothing else from this column, re-
John Favarois an independent consultant based in Pisa,
contractual flexibility exists to select member this—stamp it on your forehead Italy. He is European co-chair of the IEEE Technical Subcommittee
among alternative requirements, add if necessary: the purpose of the require- on Software Reuse and a founding member of the steering com-
mittee of the Society for Software Education. He has degrees in
requirements, or even to abandon re- ments process should not be to “cover
computer science from Berkeley and Yale. Contact him at Via
quirements, economic value is added. all eventualities,” or to “limit the dam- Gamerra 21, 56123 Pisa, Italy; [email protected].
Get CSDP Certified
Announcing IEEE Computer Society’s new
Certified Software Development
Professional Program
Doing Software Right
"The exam is valuable to me for two reasons:
One,it validates my knowledge in various areas of exper-
• Demonstrate your level of ability in tise within the software field, without regard to specific
knowledge of tools or commercial products...
relation to your peers
Two,my participation,along with others,in the exam and
in continuing education sends a message that software de-
• Measure your professional knowledge velopment is a professional pursuit requiring advanced ed-
ucation and/or experience,and all the other requirements
and competence
the IEEE Computer Society has established.I also believe
in living by the Software Engineering code of ethics en-
The CSDP Program differentiates between dorsed by the Computer Society.All of this will help to im-
you and others in a field that has every kind of prove the overall quality of the products and services we
provide to our customers..."
credential, but only one that was developed by,
— Karen Thurston,Base Two Solutions
for, and with software engineering professionals.
Register Today
Visit the CSDP web site at http://computer.org/certification
or contact [email protected]
design
Editor: Martin Fowler (cid:2) ThoughtWorks (cid:2) [email protected]
Public versus Published
Interfaces
Martin Fowler
O
ne of the growing trends in software though the method might be used anywhere,
design is separating interface from im- I can easily find the users with a search tool.
plementation. The principle is about If I have one of the new breeds of refactor-
separating modules into public and ing tools (see www.refactoring.com for de-
private parts so that you can change tails) available for Java, I can do it with a
the private part without coordinating simple menu click—the tool will then auto-
with other modules. However, there is a fur- matically update all the callers. So, changing
ther distinction—the one between public and a public method isn’t a big deal.
published interfaces. This distinction is im- However, things rapidly change if I put
portant because it affects how you that software out on the Web as a compo-
work with the interface. nent, and other people, whom I don’t know,
start building applications on top of it. If I
Public versus published now delete the parameter, everybody else’s
Let’s assume I’m writing an ap- code will break when I upgrade. Now I must
plication in a modern modular do something a little more elaborate. I can
language—to make things more produce the new method with one less para-
concrete, let’s assume this lan- meter but keep the old method—probably
guage is Java. My application thus recoding the old method to call the new one.
consists of several classes (and in- I mark the old method as deprecated, assum-
terfaces), each of which has a pub- ing people will move the code over and that
lic interface. This public interface I can change it in the next release or two.
of a class defines a group of methods that any The two cases are quite different, yet
other class in the system can invoke. there’s nothing in the Java language to tell
While I’m enhancing a public method, I re- the difference—a gap that’s also present in a
alize that one of its parameters is redundant— few other languages. Yet there’s something
I don’t need to use it in the method (maybe I to be said for the public–published distinc-
can get that value through some other route tion being more important than the more
or maybe I just don’t need it anymore). At this common public–private distinction.
point, I can eliminate that value from the The key difference is being able to find
method signature, clarifying the method and and change the code that uses an interface.
potentially saving work for its callers. Because For a published interface, this isn’t possible,
this method is public, any class in the system so you need a more elaborate interface
can call it. Should I remove the parameter? update process. Interface users are either
In this case, I would argue yes, because callers or are classes that subclass or imple-
there are benefits and it isn’t difficult. Al- ment an interface.
18 IEEE SOFTWARE March/April 2002 0740-7459/02/$17.00 © 2002 IEEE