IEEE Software (May/June)

84 Pages·2001·4.186 MB·English

from the editor
Editor in Chief: Steve McConnell (cid:2) Construx Software (cid:2) [email protected]
An Ounce of Prevention
Steve McConnell
A
“
stitch in time saves nine,” the old perhaps only an ounce of cure.3Some claim that
saying goes. “An ounce of preven- we are expending more effort on prevention than
tion is worth a pound of cure.” In we would by fixing the defects later—that we’re
software, these expressions translate spending a pound of prevention to avoid an
into the common observation that ounce of cure.
the longer a defect stays in process,
the more expensive it is to fix.1Industry reports Old support for an old saying
about the magnitude of the cost increase have One common project dynamic is to cut cor-
varied over the years. The highest ratio I’ve ners because “we’re only 30 days from ship-
seen published came from Barry ping.” If you’re in a hurry, for example, you
Boehm and Philip Papaccio in might decide that you don’t have time to de-
1988.2 They reported that require- sign and code a separate, completely clean
ments defects that made their way printing module. So you piggyback printing
into the field could cost 50 to 200 onto the screen display module. You know
times as much to correct as defects that’s a bad design that won’t be extensible or
that were corrected close to the maintainable, but you don’t have time to do
point of creation. Of course, “50 to the right design.
200 times” is a rough average, and Three months later, when the product still
in the worst cases, the sky is the hasn’t shipped, those cut corners come back to
limit for defect costs—literally. The haunt you. You find that the people using the
US space program had two high- prerelease software are unhappy with printing,
profile failures in 1999: in both, correcting a and the only way to satisfy their requests is to
defect “in the field” was not possible, and the significantly extend the printing functionality,
software errors that went undetected until the which can’t be done with the piggybacked ver-
software was in the field ended up costing hun- sion. Unfortunately, in the three months since
dreds of millions of dollars. you took the shortcut, the printing functionality
I’ve previously presented a rough rule of and the screen display functionality have be-
thumb that early, upstream defects generally come thoroughly intertwined. Redesigning
cost 10 to 100 times as much to remove late printing and separating it from the screen dis-
downstream as they do to remove close to the play is now a tough, time-consuming, error-
point where they are created.1 These observa- prone operation.
tions have been used to justify a focus on up- We have understood the dynamic in play in
stream quality assurance activities such as ex- this example at least since the 1970s when
tensive requirements work, design work, and IBM observed that software quality and soft-
technical reviews. ware schedules were related. It found that the
These old sayings and rules of thumb have products with the lowest defect counts were
come under attack in recent years. Some people also the products with the shortest schedules.4
claim that software defects aren’t as expensive to Work on a software project generally follows
correct as they used to be; costs don’t increase as a pattern of a small number of high-leverage up-
quickly as they used to. In other words, an ounce stream decisions providing the basis for a much
of prevention is not worth a pound of cure, but larger number of lower-leverage downstream
Copyright © 2001 Steven C. McConnell. All Rights Reserved. May/June 2001 IEEE SOFTWARE 5
FROM THE EDITOR
decisions. Thus we make high-leverage our understanding of how to detect up-
requirements decisions that provide the stream defects has improved consider-
basis for medium-leverage design deci- ably. Not too many years ago, we
DEPARTMENT EDITORS sions, which in turn provide the basis thought that the best way to detect re-
Bookshelf: Warren Keuffel, for low-leverage code, test-case, and quirements defects was to capture an
[email protected] end-user-documentation decisions. exhaustive set of requirements in a
Country Report: Deependra Moitra, A small mistake in upstream work monolithic requirements specification
[email protected]
can affect large amounts of downstream and then to subject that specification to
Design: Martin Fowler, ThoughtWorks,
[email protected] work. A change to a single sentence in a intensive reviews. Although industry
Loyal Opposition: Robert Glass, Computing Trends, requirements specification can imply data suggests that this approach is
[email protected] changes in hundreds of lines of code cost-effective compared to the alterna-
Manager: Don Reifer, Reifer Consultants, spread across numerous classes or mod- tive of jumping straight into coding
[email protected]
ules, dozens of test cases, and numerous and then fixing requirements defects
Quality Time: Jeffrey Voas, Cigital,
[email protected] pages of end-user documentation. at construction time, we now know of
Capers Jones reports that reworking numerous alternatives that are often pref-
STAFF defective requirements, design, and code erable to the monolithic-requirements-
Group Managing Editor typically consumes 40 to 50 percent or specification approach:
Crystal Chweh
more of the total cost of most software
Senior Lead Editor projects and is the single largest cost dri- (cid:2) Involve end users as early as possible.
Dale C. Strok
[email protected] ver.5Tom Gilb reports that about half of Several studies have found that end-
Associate Lead Editors all defects usually exist at design time,6 user involvement is key to stable
Jenny Ferrero and which is confirmed by Jones’s data. If requirements and software project
Dennis Taylor
half of all defects are upstream defects, success.9
Staff Lead Editor
Shani Murray you should be able to save effort by de- (cid:2) Create a throwaway prototype. Cre-
Staff Editor tecting defects earlier than system test- ate a throwaway UI and put the
Scott Lorenz Andresen ing. Jones reports that, as a rule of prototype in front of real end users.
Magazine Assistant thumb, every hour you spend on techni- Get feedback. Revise the prototype
Dawn Craig
[email protected] cal reviews upstream will reduce your until the user is excited about the
Art Director total defect repair time from three to ten system. Then build the system. This
Toni Van Buskirk hours; that is, one ounce of prevention is approach correlates with good re-
Cover Illustration worth three to ten ounces of cure.7 quirements stability and low system
Dirk Hagner
Has this dynamic changed in recent cost.5
Technical Illustrator
years? Recent data from Hughes Air- (cid:2) Deliver the software incrementally.
Alex Torres
craft shows that the average require- Write production code for a small
Production Artists
Carmen Flores-Garvey and Larry Bauer ments defect still takes 10 times as much amount of the system. Put that
Acting Executive Director effort to correct during system testing as functionality in front of the user.
Anne Marie Kelly it does during requirements analysis.8 Revise the requirements, design, and
Publisher
The dynamics of defect-cost increase code until the user is excited about
Angela Burgess
are inherent in the nature of software the system. This approach does not
Membership/Circulation
Marketing Manager engineering work. It doesn’t matter entirely eliminate the defect-cost in-
Georgann Carter whether the project follows an old- crease dynamic, but it shortens the
Advertising Assistant fashioned waterfall life-cycle model or feedback loop from requirements to
Debbie Sims
uses a cutting-edge iterative approach— user feedback in a way that reduces
CONTRIBUTING EDITORS design, code, test cases, and documenta- the number of downstream depen-
Greg Goth, Kirk Kroeker, Nancy Mead, tion will have dependencies upon re- dences that will be based on erro-
Ware Myers, Judy Shane, quirements regardless of whether the neous upstream work. This sort of
Margaret Weatherford
project is done all at once or divided incremental delivery approach corre-
into numerous incremental releases. lates with high user satisfaction and
Editorial:All submissions are subject to editing for clarity, Overall, I see no indication either lower total development costs.1,6
style, and space. Unless otherwise stated, bylined articles from industry data or analysis that the (cid:2) Conduct a requirements workshop.
and departments, as well as product and service descrip-
tions, reflect the author’s or firm’s opinion. Inclusion in dynamics of defect-cost increase have Fast requirements elicitation tech-
IEEE Softwaredoes not necessarily constitute endorsement changed in recent years. niques such as joint application de-
by the IEEE or the IEEE Computer Society.
velopment sessions are an effective
To Submit:Send 2 electronic versions (1 word-processed What does that ounce of way to shorten the time required to
and 1 postscript or PDF) of articles to Magazine Assistant,
IEEESoftware, 10662 Los Vaqueros Circle, PO Box 3014, prevention look like? collect accurate requirements while
Los Alamitos, CA 90720-1314; [email protected]. Ar-
While the underlying dynamic of simultaneously reducing require-
ticles must be original and not exceed 5,400 words including
figures and tables, which count for 200 words each. defect-cost increase has not changed, ments volatility downstream.5
6 IEEE SOFTWARE May/June 2001
FROM THE EDITOR
EDITOR IN CHIEF:
Steve McConnell
10662 Los Vaqueros Circle
(cid:2) Perform use case analysis. Rather many good techniques have emerged in Los Alamitos, CA 90720-1314
[email protected]
than being satisfied with the users’ the past few years.
first explanation of what they want EDITOR IN CHIEF EMERITUS:
Alan M. Davis, Omni-Vista
a system to do, examine the system’s
expected usage patterns to better References ASSOCIATE EDITORS IN CHIEF
understand users’ real needs. 1. S. McConnell, Rapid Development, Microsoft Design: Maarten Boasson, Quaerendo Invenietis
(cid:2) Create the user manual first. Some Press, Redmond, Wash., 1996. [email protected]
organizations have had good suc- 2. B.W. Boehm and P.N. Papaccio, “Understand- Construction: Terry Bollinger, Mitre Corp.
ing and Controlling Software Costs,” IEEE [email protected]
cess creating their user manuals as a Trans. Software Eng., vol. 14, no. 10, Oct. Requirements: Christof Ebert, Alcatel Telecom
substitute for or supplement to a 1988, pp. 1462–1477. [email protected]
3. K. Beck, Extreme Programming Explained: Management: Ann Miller, University of Missouri, Rolla
traditional requirements specifica-
Embrace Change, Addison-Wesley, Reading, [email protected]
tion. End users seem to be better able Mass., 2000. Quality: Jeffrey M. Voas, Cigital
to understand the contents of a user 4. C. Jones, Applied Software Measurement: [email protected]
Assuring Productivity and Quality, 2nd ed.,
manual than a traditional require-
McGraw-Hill, New York, 1997. EDITORIAL BOARD
ments specification, and requirements 5. C. Jones, Estimating Software Costs,
elicitation goes more smoothly. McGraw-Hill, New York, 1998. Don Bagert, Texas Tech University
Andy Bytheway, Univ. of the Western Cape
6. T. Gilb, Principles of Software Engineering
Richard Fairley, Oregon Graduate Institute
Management, Addison-Wesley, Wokingham,
New twists on old sayings U.K., 1988. Martin Fowler, ThoughtWorks
Robert Glass, Computing Trends
Software engineering advances by 7. C. Jones, Assessment and Control of Software Natalia Juristo, Universidad Politécnica de Madrid
periodically reexamining questions that Risks, Yourdon Press, Englewood Cliffs, N.J., Warren Keuffel, independent consultant
1994. Brian Lawrence, Coyote Valley Software
we think we’ve already answered. An 8. R.R. Willis et al., Hughes Aircraft’s Wide- Karen Mackey, Cisco Systems
ounce of prevention is still generally spread Deployment of a Continuously Im- Stephen Mellor, Project Technology
proving Software Process, tech. report Deependra Moitra, Lucent Technologies, India
worth a pound of cure, but some recent CMU/SEI-98-TR-006, Software Eng. Inst., Don Reifer, Reifer Consultants
developments have improved the Carnegie Mellon Univ., Pittsburgh, 1998. Wolfgang Strigel, Software Productivity Centre
“ounces of prevention” at our dis- 9. Charting the Seas of Information Technology, Karl Wiegers, Process Impact
tech. report, The Standish Group, Dennis,
posal. I find it encouraging that so Mass., 1994.
INDUSTRY ADVISORY BOARD
Robert Cochran, Catalyst Software, chair
Annie Kuntzmann-Combelles, Q-Labs
Enrique Draier, PSINet
Eric Horvitz, Microsoft Research
David Hsiao, Cisco Systems
Takaya Ishida, Mitsubishi Electric Corp.
Dehua Ju, ASTI Shanghai
U p c o m i n g T o p i c s Donna Kasperson, Science Applications International
Pavle Knaflic, Hermes SoftLab
Günter Koch, Austrian Research Centers
Wojtek Kozaczynski, Rational Software Corp.
Tomoo Matsubara, Matsubara Consulting
Masao Matsumoto, Univ. of Tsukuba
July/August ‘01:
Dorothy McKinney, Lockheed Martin Space Systems
Susan Mickel, AgileTV
Fault Tolerance
Dave Moore, Vulcan Northwest
Melissa Murphy, Sandia National Laboratories
Kiyoh Nakamura, Fujitsu
Suzanne Robertson, Altantic Systems Guild
September/October ‘01:
Grant Rule, Software Measurement Services
Benchmarking Software Organizations Girish Seshagiri, Advanced Information Services
Chandra Shekaran, Microsoft
Martyn Thomas, Praxis
Rob Thomsett, The Thomsett Company
November/December ‘01: John Vu, The Boeing Company
Simon Wright, Integrated Chipware
Extreme Programming Update Tsuneo Yamaura, Hitachi Software Engineering
MAGAZINE OPERATIONS COMMITTEE
January/February ‘02: Sorel Reisman (chair), JamesH. Aylor, Jean Bacon,
Thomas J. Bergin, Wushow Chou, William I.
Grosky, Steve McConnell, Daniel E. O’Leary, Ken
Building Security from the Ground Up
Sakamura, Munindar P. Singh, Francis Sullivan,
James J. Thomas, Yervant Zorian
March/April ‘02: PUBLICATIONS BOARD
Rangachar Kasturi (chair), Angela Burgess (pub-
The Engineering of Internet Software lisher), Jake Aggarwal, Laxmi Bhuyan, Mark Chris-
tensen, Lori Clarke, Mike T. Liu, Sorel Reisman,
Gabriella Sannitti di Baja, Sallie Sheppard, Mike
Williams, Zhiwei Xu
May/June 2001 IEEE SOFTWARE 7
manager
Editor: Donald J. Reifer (cid:2) Reifer Consultants (cid:2) [email protected]
Software Engineering
and the Law
John Cosgrove, P.E.
F
or good or otherwise, the legal system wrongful termination involving computer
has discovered the world of comput- system crashes, production of evidence of
ers and its practitioners. Anyone gambling during business hours, and acade-
opening a daily newspaper knows mic plagiarism charges. Resolving all these
that litigation involving computers disputes required computer expertise.
and software has exploded in recent More important are the computer-related
years. On balance, the net effect of this at- issues that threaten our economic structure
tention might be positive because it gives and our citizens’ health and safety. These
practitioners an economic incentive to im- threats have been with us for some time, but
prove the way we work. Indeed, only recently has the legal system identified
lawyers might well be the ones the litigation potential of computers and
who provide the incentives for software.
realistic contractual commit-
ments, worst-case software engi- Why software is different
neering development practices, Most engineered systems start with com-
and a total organizational com- prehensive plans and specifications. Few
mitment to quality. Something software-intensive systems do!
similar happened to the US auto- This simple fact sets the stage for most
mobile industry, benefiting both of the issues leading to litigation. In fact, it
carmakers and the public. is usually impossible to completely define
most practical software systems. Watts
The threat Humphrey stated the dilemma: “With soft-
Tom DeMarco and Tim Lister estimate ware the challenge is to balance the un-
that “costs of litigation are rising faster than knowable nature of the requirements with
any other aspect of software development,” the business need for a firm contractual re-
and “[l]itigation costs are … a larger com- lationship.”2 Thus, there is no clear an-
ponent than coding.”1 The legal system has swer to the inevitable legal ambiguities.
not overlooked computing’s pervasive pres- Both parties must learn to live with these
ence in every aspect of society. In the recent ambiguities and cooperatively resolve each
flood of computer-related litigation, soft- issue in a timely manner. When this under-
ware forensic consulting in particular has standing breaks down, litigation results,
multiplied in recent years, as DeMarco and and the ultimate resolution is costly for
Lister also noted. Usually, this involves dis- both parties. DeMarco and Lister titled
putes over computer projects and contracts their article “Both Sides Always Lose: Liti-
but often requires an expert opinion in un- gation of Software-Intensive Contracts.”
likely matters. Recent forensic clients have The challenge as a software professional is
included a divorce dispute needing an eco- to steer the parties away from this disas-
nomic evaluation of a software product, a trous state.
14 IEEE SOFTWARE May/June 2001 0740-7459/01/$10.00 © 2001 IEEE
MANAGER
Explaining the unexplainable
ects. Litigation has stimu-
As the wit said of computer- lated many manufacturers
intensive technical claims: “All to apply worst-case design
the parties are lying, but none principles to their engineer-
of them knows it.” That’s ing practices. Thus, car
doubly true of legal discourse manufacturers can defend
involving computers. People themselves by citing the ex-
have become so accustomed to tensive research and testing
asserting the most unsupport- they’ve undertaken to vali-
able conclusions from com- date their designs before
puter “facts” that they come to product release. Although
believe that almost anything not yet perfect, major im-
can be true sometimes, so provements in safety and re-
they might as well claim it. liability have resulted. Soft-
Because the complexity is ware engineering likely will
usually very high, it is exceed- soon feel the same pressure.
ingly difficult to “prove” any
assertion false in a typical le- Managing expectations
gal proceeding. Humphrey also expressed
a cultural weakness con-
What to do cerning unrealistic expecta-
There are no guarantees, but if the team’s culture is seldom driven by prac- tions: “[D]irected by top manage-
record of the system development tices that a lawyer could defend as “all ment to run a mile in two minutes,
process shows “all reasonable steps,” reasonable steps” in court. Real-life what should they do? … many pro-
this is the best defense possible. Even projects are defined by needs that are grammers start looking for their
though a well-documented process is often independent of any achievable running shoes.”2 As long as this re-
no guarantee of quality, high quality means. Humphrey’s Why Software Or- sponse continues, “reasonable” can-
and consistent results are almost al- ganizations Are Chaotic describes a not often be truthfully applied to
ways a result of a well-conceived, and project: “the schedule … represented software development.
usually well-documented, process. At what was needed and had nothing to A recent case involved a customer
least, the accusation of negligence is do with an achievable plan to make it who expected delivery of a “state-of-
unlikely to hold if this is done. Also, work.”2 Even if a software-develop- the-art” financial system in six
the performance of the steps should ment team meets the schedule, it has months or less. The customer knew
be recorded. I’ll describe the method made so many compromises that the that the undertaking was unprece-
of defining the reasonable steps in a quality is usually unacceptable, estab- dented (never before accomplished),
moment. lishing a different basis for litigation. large (over 500K lines of code), criti-
The solution is to insist on achievable cal (mistakes risking millions of dol-
Avoiding and surviving litigation expectations that enable the team to lars a day), and ill-defined (tens of
Several years ago, Bud Lawson engineer the system according to the communication interfaces changing
proposed a method to define the en- “all reasonable steps” principle. constantly). Even so, the buyer termi-
gineering processes used to develop As one approach, software devel- nated the contract and sued the sup-
software-intensive, safety-critical sys- opers might apply worst-case design plier when it could not meet those
tems. Simply stated, the method “as- principles to their development proj- expectations. The expert’s role was
sumes—a priori—that legal action to explain the reality of what the op-
has been brought against them for posing side expected and the implica-
the product that they are about to tions of the constant changes that the
produce.”3 Then, “all reasonable customer imposed on the developer
steps” must be present in the engi- during the project’s life. Soon after-
As the wit said of
neering activities to defend against wards, the case settled. These types
computer-intensive
the action. DeMarco and Lister sug- of expectations are not as rare as
gest a similar strategy in that “[t]he technical claims: “All the they should be. Many argue that
things you do to win a litigation … some lack of realism is the norm in
parties are lying, but
also are … the principal things that software development.
you should do to avoid litigation.” none of them knows it.” It is safe to say that, when unreal-
Simply stated, good engineering in istic expectations are left alone, litiga-
the best sense is the best legal defense. tion will likely follow. Software de-
Typically, a software development velopers avoid the issue because the
May/June 2001 IEEE SOFTWARE 15
MANAGER
process of educating the customer is
always painful and often fatal to
IEEE
keeping the contract going. The alter-
native—litigation—might be worse.
The only solution is the painful
CCAALLLL
process of confronting each percep-
RArticles
tion in a patient, orderly way and
O documenting the mutual understand-
ing or unresolved questions. It is only
F
“good engineering” to insist on defin-
Software Engineering ing a project in achievable terms.
of Internet Software
Warning
Litigation—potential or other-
ahinnatdso ifIanan tl crlle oeondsftsu r ecate-lhb dhau inasg ihnanwe edwsaesy c.la afdnoegr, uw athgoeer l.dI n wWteiedr ens epctoe mahkam soe fgr crIeon,tw einnrnf oferrtom tmiam taieo ,ln iIt,n tatleen-rdkn neeont wtseonrft tabwianacmkre er,no ata.n d dT ohtfhis en s erhrisidfest wwiniacsrreee— aissiin ncvgloleylav rilinymg p gcooorimntagpn utt ote prbase ract noodmf se o tafhtne-
computer professional’s life. Conse-
sbshtorouuptcEi tqwsuusrieenesnd tcotiohwamal stpt, o dan enaepilwell osso ypft hastalphictei ksr cs iWr,se aaetnhtbede s bitsthaoeenfst k wut onsaoionrltesge stto.hh nae t wl amhtaeicskhte ste e-tcbhhuens oiInnloetgesysrn, ersuto nfwstw otraokr .et h Flerieo smW b etebhh eind idens ftirhgaen- qweruese —ncotolnyrd, uwricsetk nt hebeee dcb outmosi nicnehgsa sn pogafe r ctt ohmeo fpw uaatny-
endless lose-lose litigation scenario.
iptnhr oitnhcgeeH s obrsuweescs ah idsm t ioftefh esiesrt-e acnnkoetenw? n ce AlIacnntitmdeed srh? nai env t Ae tsh rwoeef etntw hefewoa rr tgeWoo odteltibsfef infedi reiifemdfne ptwr oetornhtrtaal?dnn ? tAt hpreer i nstcohifpet lwedsea sroeifg ncsrsoe fadttwieffdae rrbeee nefton?rg eiAn eervee ertirnhyge- Agmocootrudea— lrlyge,ao loimtdyu , cephna giionnffe ueltr hihnisog ncephsrataync gtwiec ietsihs,
bosses and clients, and so forth—
that Wmeig shet ebke oardigdirneasls aerdt iicnleclsu doen (wbuhta ta irte mneoat nlism tiote ddo t oIn)t:ernet software. Specific questions wFiinlla blleyn, efailtl evseorfytwonaer ei n pthroe fleosnsigo rnuanls.
• How do we apply engineering techniques to Internet software? must accept the obligation to always
• Is it all “code and fix” or can we apply a broader variety of effective practices? apply principles of worst-case engi-
• How have Internet time and new technologies affected the culture of software neering—in such common use by
development organizations? other engineering disciplines—or the
• What role does technology play? legal profession will make it excruci-
• Hothwe dsoaemse u?ser interface design change for a Web interface? How does it stay afetsinsigolny schleoaurl dw hhayv teh ed ocnoem spou! ter pro-
• What are the design principles and patterns behind effective Internet software? References
• What are the real problems and solutions behind data interchange on the global 1. T. DeMarco and T. Lister, “Both Sides Always
Internet scale? Lose: Litigation of Software-Intensive Con-
• How are Internet software development and testing practices different from other ptrpa.c t4s–,”6 C; wrowsswT.asltksc, .vhoilll.. a1f3.m, nilo/C. r2o, sFsteabl.k 2/2000000,/
kinds of software development? feb/demarco.asp.
2. W. Humphrey, Managing the Software Process,
at laArgueth, oerms pshhaosuizldin pgr elessesnotn tsh eleira rwneodrk f rino mte rpmrasc ttihcaatl eaxrep eursieefnucle t.o the software community 3. AHd.Wdi.s oLna wWseosnle, y“, ARnea Adisnsegs, sMmeansst. ,M 19et9h0o,d po. lo5g9y.
sfiiPnnooogcrflt s uwtdPsasatilcsneyrr gaeilpe /2sit,le0a l,u u0scstubl thabryowram irtt.oii1yhotr, t5nd tm swsa, .A noooud rrSeg u2lcuesbo,sc8pmntt0art iaoc0s2ecns–t.0ii 5co0 t,nFch41osoe0. pr 0 iaeA drswre,et o tiocranpdlieeelses e,id rnw -s rRihateTohuvF utei helaodowcr rh e Mb ideglil cuursai4odtns–redoal1i ftn2tioae Wnrsed,, o ogrusrsdaebu pelabeh nj-e,dcs co optorma ntcpetaeou bdi tnl ee e rPpcd.oaoDitugrFigne no/tsg-r, John ftCohroo rSs aagfter btoyuv dCe@r,i dtPiac.maEle .Sk,y.hksattseh bm.eseesn,.” a csoofntwtaarcet etnhgein aeeur- for
over 40 years and a self-employed consultant for more than 30.
magazine assistant Dawn Craig at His specialties include forensic engineering, project management,
[email protected]. Guest Editors: software architecture, real-time critical systems, and hardware–
software interfaces. He has extensive experience with aviation
Elisabeth Hendrickson, Quality Tree Software, Inc.
computer systems, including development of aircraft navigation
Publication: 7563 Cottonwood Lane, Pleasanton, CA 94588, USA systems and communication devices. He has a Masters of Engineer-
[email protected] ing from UCLA and a BSEE from Loyola Marymount, Los Angeles.
March/April 2002
He is a California-registered Professional Electrical Engineer, a se-
Martin Fowler, Chief Scientist, Thoughtworks
Submission deadline: 651 W Washington Blvd, Suite 500, Chicago, IL 60661, USA nior member of the IEEE Computer Society, and a member of ACM
and the National Society of Professional Engineers. Contact him at
15 August 2001 [email protected]
Cosgrove Computer Systems, Inc., 7411 Earldom Ave., Playa del
Rey, CA 90293-8058; [email protected].
16 IEEE SOFTWARE May/June 2001
focus
guest editor’s introduction
Organizational Change
Ann Miller, University of Missouri–Rolla
alt Disney is cred-
W
ited with saying that
“Change is inevitable;
growth is optional.”
We certainly have witnessed signifi-
cant change in the software industry
in the last few years. Furthermore,
even the rate of change seems to be
increasing. Will the pace level off or
will it continue accelerating? And
as we change, are we growing? Cer-
tainly the size of software in prod-
ucts is increasing. A few years ago, a
study of one product family indi-
cated that its software content was
expanding at more than 80 percent
18 IEEE SOFTWARE May/June 2001 0740-7459/01/$10.00 © 2001 IEEE
per year; furthermore, this product line had tion in which a two-tiered hierarchy of CCBs
been experiencing that growth rate for was established: one senior-level CCB and sev-
Some plan and
nearly two decades.1 Are we growing pro- eral second-tier boards, one for each major
portionately in our knowledge of how to subsystem. The chair of the senior CCB dic- lead change,
manage, develop, and maintain software? tated that only the proposed changes whose
others manage
impact was estimated to cost $1 million or
Lead, manage, cope, or none of the more should reach this higher-level review and it, still others
above? approval board. It was amazing how many accommodate
Organizational change is this issue’s focus. proposed modifications were estimated to cost
change, and
In the software and information technology “only” half a million dollars. This dictate dis-
industry, organizational change has been a couraged engineers from carefully considering many simply try
way of life. It is quite telling to listen to indi- and tracing the potential ramifications of their
to cope with it.
viduals discussing change in their organiza- proposed changes. Furthermore, although
tions. Their words frame their philosophies: representatives from other subsystem projects
some plan and lead change, others manage it, attended every meeting of the second-tier
still others accommodate change, and many boards, they were not voting members. Thus,
simply try to cope with it. Then there is the eu- even if these codevelopers saw the potential
phemistic phrase “change control.” I have al- for significant impact to their own subsystem
ways found this phrase particularly curious, from a change within a different subsystem, all
especially since change control boards often they could do was voice that concern. To take
don’t control change effectively. In a major the matter to the senior board, the affected
system development project, I recall a situa- subsystem group had to carry out its own
study and demonstrate that the total cost of
the proposed change would exceed the magic
million-dollar mark. That project certainly did
not control change effectively; on more than
one occasion, senior management had to re-
scind an approved change after receiving a
more detailed impact analysis.
Change is not only inevitable, it is every-
where. Organizational change occurs at many
levels and across many dimensions. When I
worked in industry, my colleagues and I often
commented on the organizational chart du
jour; some part of our large company was al-
ways undergoing change. But change occurs
not just in management structures; it also oc-
curs in products, processes, technology, tools,
communication media—in virtually every as-
pect of an organization, down to its very core:
its corporate culture and people. Change usu-
ally also involves some element of risk. Con-
versely, when a potential risk becomes a real-
ity, some sort of change becomes necessary.
Some people thrive in the energy and turmoil
of change; others resist it mightily. Thus, the
articles appearing here address social issues as
well as technical ones.
The theme articles
Just as organizational change spans a wide
spectrum, so too do the articles and features in
this special focus. In the first article, Michael
Deck addresses the importance of process di-
versity. In recent years, there has been a trend
May/June 2001 IEEE SOFTWARE 19
in companies to standardize the software de- officer. It is Novell’s latest ad campaign that
velopment process; one supporting argument triggered the interview: The use of David
People are
for this common process is that a software en- Bowie’s classic rock song, “Changes.”
always key to gineer from one project can easily move to a Schmidt has been at the helm of Novell
different project and be productive quickly in through a sea of change, and he shares some
any process
the new environment. However, many soft- of his insights gained over that time.
improvement, ware engineers feel that one size does not fit all When companies embark on a significant
so methods to when it comes to development and test transformation, they frequently seek advice
process. They frequently subvert or ignore a from consultants. Today, there is a new breed
help staff ramp
standard process because they feel it is too re- of consultants who prefer the title “coach.”
up on the strictive on a given project. “Managing They stress dialog, not one-way communica-
Process Diversity While Improving Your Prac- tion; they stress collaboration and teamwork;
learning curve
tices” addresses diversity management within and they deal specifically with change. Our
of a technology an organization to tailor a standard process to second interview is with Mary Boone, presi-
meet specific project needs. dent of Boone Associates. She is an executive
or process are
We continue with software process im- coach and consultant who specializes in or-
extremely
provement in “SPI Patterns: Learning from ganizational communication and the strate-
important. Experience” by Marina Blanco, Pedro gic application of information technology.
Gutiérrez, and Giuseppe Satriani, who dis-
cuss the European Software Institute’s
repository of over 250 process improvement To bring some insight and stability in a
experiments. The authors have analyzed the time of change, Albert Einstein’s three
repository for patterns to help organizations rules of work offer good advice:
plan improvement initiatives.
In the third article, “Mentoring Object- 1.Out of clutter, find simplicity.
Oriented Projects,” Ramkumar Ramaswamy 2.From discord, find harmony.
discusses the value of on-the-job mentoring 3.In the middle of difficulty lies opportunity.
in learning process and design skills, particu-
larly in object-oriented projects. People are There are those who argue that change is
always key to any process improvement, so just the swing of the pendulum; so perhaps
methods to help staff ramp up on the learn- the words of another philosopher, John
ing curve of a technology or process are ex- Mellencamp, are appropriate when he sings,
tremely important to the success of that tech- “I know there’s a balance—I see it when I
nology or process adoption. swing past.”
The fourth article explores the business
aspects of organizational change. In “What Acknowledgments
Makes Measuring Software So Hard?” Stan Many thanks to the reviewers who contributed
their valuable time and expertise in critiquing the arti-
Rifkin discusses the importance in having a
cles that form this special focus.
software measurement program aligned
with the organization’s business goals and Reference
objectives.
1. T. DeMarco and A. Miller, “Managing Large Software
When working on software, requirements Projects,” IEEE Software, vol. 13, no. 4, July 1996, pp.
24–27.
inevitably change and grow; moreover, each
of the key stakeholders—customer, end user,
About the Author
manager, developer—approach the same re-
quirements from different perspectives. The
final article, “Developing Groupware for Re- Ann Milleris the Cynthia Tang Missouri Distin-
guished Professor of Computer Engineering at
quirements Negotiation: Lessons Learned” by
the University of Missouri-Rolla and is the IEEE
Barry Boehm, Paul Grünbacher, and Robert Softwareassociate editor for software manage-
O. Briggs, presents a distributed groupware ment. She also serves on the NATO Information
Systems Technology Panel and chairs the NATO
system called WinWin and discusses how it
Task Group on Validation, Verification, and Certi-
facilitates the requirements process. fication of Embedded Systems. She has over 12
In addition to the contributed articles, years of software experience in industry and
three years of senior executive service in the US Department of Defense.
this issue features two interviews. The first is
She has a BS, MS, and PhD in mathematics from St. Louis University. Contact
with Eric Schmidt, Novell’s chief executive her at [email protected].
20 IEEE SOFTWARE May/June 2001
focus
organizational change
Managing Process
Diversity While
Improving Your Practices
Michael Deck, Cleanroom Software Engineering, Inc.
n recent years, the industry has gradually moved toward implement-
I
ing standard processes across large organizations. The benefits of do-
ing so include simplified accounting, measuring, and managing. Im-
plementing organization-wide processes also makes it easier to judge
Software
the capabilities of an organization as a whole, which is important in large-
process
improvement scale software development where organizational structures can have a pro-
efforts will fail found impact on success.
if we try to make
development But there are also drawbacks to process This article describes a project in which lo-
uniformity, including cases where clean calized software practice improvements led
processes
process documentation hides chaos in the to process diversity. It describes certain
completely
trenches. Another drawback is the difficulty problems that we encountered and resolved
uniform to modify an organization-wide process that during the effort. It also presents some sim-
across large has been carefully vetted by committee after ple techniques that any project—small or
committee. An organizationally uniform large—can use for managing diversity. The
organizations.
process can prevent smaller software teams techniques I discuss in this article evolved in
By focusing
working within large organizations from the course of one multiyear project.
on localized adopting a process tailored to fit their needs. If you do not carefully plan and manage
software I define software practice improvement process diversity, it quickly becomes un-
as a set of goals that sits between individual manageable. I used to advocate process uni-
practice
programming practices and organization- formity, warning against the management
improvement,
level software process improvement. By fo- problems caused by diversity, but recent ex-
organizations cusing on improving software practices, we periences have suggested more effective
can tailor stand a better chance of achieving success ways to address these problems. This article
using well-understood techniques such as explores these alternative strategies, which
processes to
risk analysis, incremental development, and include adopting a basic set of practices
meet specific
team ownership. that are uniformly enforced across all de-
needs. I define process diversityas using several velopment steps, using risk analysis as a
different process variants simultaneously. technique for selecting targets for software
0740-7459/01/$10.00 © 2001 IEEE May/June 2001 IEEE SOFTWARE 21