Implementing Software Engineering In a Small Workgroup
1
Karl E. Wiegers
Process Impact
716-377-5110
www.processimpact.com
The conference is over. You’re back at your desk, battling the same alligators that filled
the swamp before you left. You heard many interesting talks, with industry gurus preaching the
latest software development wisdom and telling you how you should build systems now and in
the future. What they didn’t tell you was how to reduce to practice the highfalutin’ ideas they
endorse while still trying to get yesterday’s project done by tomorrow. Besides, your projects
aren’t large enough to benefit from formal software engineering, and you don’t have the re-
sources to do it, anyway. The people in your group don’t want to hop from one bandwagon to
another, chasing the Holy Software Grail while your customers breathe down their necks. The
default decision is business as usual, with a vow to do it better sometime next year.
In this paper, I’ll describe how selected software engineering practices have been ap-
plied in and benefited several small software development groups in a large company. Our
emphasis is on using structured development methods and a practical quality assurance proc-
ess, not pursuing state-of-the-art techniques for all applications. We found that a systematic
approach to continual software process improvement, combined with selective application of
the many software engineering methods and tools now available, was not only feasible but re-
warding. A commitment to continual improvement in our software development process has
worked for us, and it can work for you. These, and related, experiences have been reported in
more detail elsewhere [Wiegers, 1996].
Who We Are
The software team whose experiences are described here is part of the Research
Laboratories at Eastman Kodak Company. We develop three principal kinds of software appli-
cations for our customers, who are Kodak photographic scientists and chemists:
• user interface-intensive, computation, data analysis, modeling, and graphics
programs
• real-time lab automation systems
• information systems
Over time, this group developed a set of principles that helped guide our technical
practices, management priorities, and team interactions. Such principles, often unspoken, help
define the culture of team of people working together. By identifying and applying a small
number of shared beliefs, a team can grow toward having a healthier software engineering
culture [Wiegers, 1996].
We focus on delivering high-quality software. We believe productivity increases will
materialize as a natural side benefit of quality, thanks to reduced maintenance over the prod-
uct’s lifetime. We further believe the greatest determinant in software quality is the degree and
quality of customer involvement during development, because our biggest challenge is sharing
a common vision of the final product with the customer. Without such a shared vision, some-
1
This article was originally published in Computer Language, June 1993. It is reprinted here (with modifi-
cations) with permission from Miller Freeman, Inc.
评论23