Gift Guide

Improving Software Organizations: From Principles to Practice / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 95%)
Other sellers (Paperback)
  • All (8) from $1.99   
  • New (4) from $35.00   
  • Used (4) from $1.99   
Sort by
Page 1 of 1
Showing 1 – 3 of 4
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2006

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

Boston, MA 2001 Trade paperback New. BRAND NEW. Trade paperback (US). Glued binding. 368 p. Contains: Illustrations. Agile Software Development. Audience: General/trade.

Ships from: Northbrook, IL

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2008

Feedback rating:


Condition: New

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2014

Feedback rating:


Condition: New

Ships from: Idyllwild, CA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing 1 – 3 of 4
Sort by


Global competition, the time sensitivity of the new Internet economy, and increasing customer demand for better software quality are pushing companies to undertake software process improvement (SPI) initiatives. Numerous software organizations worldwide have implemented these initiatives with varying degrees of success. Many have adhered to standard SPI practice, only to experience less-than-satisfactory results when the execution proves more difficult than expected and enthusiasm and resources wane.

Improving Software Organizations offers a modern perspective on SPI. It outlines and discusses what it takes to move from SPI theory to successful SPI initiatives. Based on the results of the three-year National Danish SPI Initiative, this book draws on the experiences of four world-class companies—Danske Data, Brüel & Kjær, Ericsson Denmark, and Systematic Software Engineering. It presents a proven roadmap for successful SPI. It distills in-depth studies of these organizations—the strategies, approaches, and specific techniques that yielded tangible results. It presents a comprehensive framework for planning and executing successful SPI projects throughout the project lifecycle.

Improving Software Organizations presents the major lessons learned in the four companies. It provides an overview of the theories and models that formed the basis of the SPI initiatives. It also provides an in-depth examination of the four companies¿ development organizations, how each began the SPI initiative, what mistakes were made, and how they ultimately succeeded.

You will learn:

  • The five key principles of the SPI focus on problems, emphasize knowledge creation, encourage participation, integrate leadership, and plan for continuous improvement
  • How diverse companies adapt standard
  • SPI theory to achieve desired results
  • How to structure learning conditions in SPI initiatives
  • Maturity level assessments, including CMM, BOOTSTRAP, and other customized approaches
  • Knowledge transfer, customer maturity, and organizational learning
  • Proper paths for carrying out risk assessments
  • The specifics of implementing a metrics program
  • Tips on improving requirements specification

For each of the five SPI principles, the book offers examples from practice that demonstrate how successful organizations approached the issue. From these examples and the more detailed case studies, you will gain the understanding of how to design, implement, and execute an SPI initiative that is right for your organization.


Read More Show Less

Product Details

  • ISBN-13: 9780201758207
  • Publisher: Addison-Wesley
  • Publication date: 11/1/2001
  • Series: Agile Software Development Series
  • Edition number: 1
  • Pages: 368
  • Product dimensions: 7.20 (w) x 9.20 (h) x 0.90 (d)

Meet the Author


Read More Show Less

Table of Contents


1. Learning SPI in Practice.

2. Mapping SPI Ideas and Practices.


3. The Correct Effort.

4. The Ambitious Effort.

5. The Grassroots Effort.

6. The Adolescent Effort.


7. Learning from Assessments.

8. From Problem Reports to Better Products.

9. Problem Diagnosis in SPI.

10. Project Assessments.

11. A Framework for Selecting an Assessment Strategy.


12. Knowing and Implementing SPI.

13. Improving Customer Relations.

14. Strategies for Organizational Learning in SPI.


15. Implementing SPI: An Organizational Approach.

16. Risk Management in Process Action Teams.

17. Principles of Metrics Implementation.

18. Better Requirements.

Appendix A: Risk and Action Tables.

Research Team.

Index. 0201758202T10102001

Read More Show Less


Global competition and customer demands for better software quality are pushing companies to undertake software process improvement (SPI) initiatives. However, the scale and complexity of SPI organizational change can be daunting, and when it is not managed with great skill, the effort is likely to fail. Software development managers and engineers know too well the feelings of frustration associated with investing valuable resources and not achieving the desired SPI outcomes.

In this book, Improving Software Organizations, we discuss ways to understand and develop the core competencies required to succeed with SPI. Our approach is pragmatic and action-oriented. We examine SPI experiences from real-world situations and distill from them essential lessons for planning, implementing, and managing SPI initiatives to successful completion.

Our book is a result of a collaboration between four Danish companies—Danske Data, Brüel & Kjær, Ericsson Denmark, and Systematic Software Engineering—three universities—Aalborg University, Copenhagen Business School, and Technical University, Denmark—and an R&D organization, Delta. The project was part of the Danish National SPI Initiative and lasted from January 1997 to December 1999. It was funded in part by the government of Denmark through the Danish National Center for IT Research. During the three-year project, scientists and engineers from the companies and universities worked together on SPI projects within the companies. A primary objective of our collaboration was not only to successfully implement SPI in the companies but also to develop principles and strategies for effectively executing SPI initiatives. From the beginning, we set out to examine and develop solutions for difficult practical problems reported by other SPI experts. In these pages, we present our findings and reflections based on our experiences practicing SPI. We hope that you find our book informative and that the information in it supports your own efforts to solve the practical problems involved with planning and implementing your own SPI programs.


Following is general information about each company. As you’ll see, the companies vary in size and in the products they make. They also have various objectives and approaches to SPI. Such variety offers us a unique opportunity to examine a broad range of SPI issues of interest to both software managers and engineers. You are thus likely to find many issues and problems presented in this book that are similar to those facing your own organization, as well as solutions that you can adapt and implement.

Brüel & Kjær A/S

Brüel & Kjær is a leading manufacturer of high-precision measuring instruments. These technically advanced instruments are used in many industries—including automotive, telecommunications, electricity, and aerospace—as well as in environmental measuring and university and industrial research. Brüel & Kjær’s measuring instruments are based on both embedded real-time software and Windows NT applications. The Brüel & Kjær product line covers the entire range of measurement equipment, from simple transducers to highly advanced software for calculating and presenting measurement results.

Brüel & Kjær’s main office is in Nærum (just north of Copenhagen), and the company operates more than 50 sales offices and agencies worldwide. In 1998, Brüel & Kjær was divided into two separate companies:

  • Brüel & Kjær Sound and Vibration Measurement
  • Brüel & Kjær Condition Monitoring Systems

Sound and Vibration is the larger of the two companies, with 550 employees. Approximately 80 of these employees are development engineers, of whom 40 are software developers. Annually, 10 to 15 development projects are carried out, with 4 to 8 people in each project group. Condition Monitoring Systems has some 50 employees, of whom 10 are software developers. Over the past 10 to 15 years, Brüel & Kjær has been transformed from a company focused on hardware, mechanics, and electronics to a company focused on software. Today, two out of three engineers at Brüel & Kjær are software engineers. Most Brüel & Kjær employees have an engineering education; a few have backgrounds in business or computer science.

In the mid-1990s, Brüel & Kjær transformed itself from a departmental organization to a project-oriented organization. As part of this process, the entire middle management layer was replaced. Several other employees were trained in project management and given responsibility for managing development projects in the new organization. During the 1990s, Brüel & Kjær carried out several other organizational change initiatives. In 1994, the company successfully completed ISO 9000 certification.

When assessed in October 1996, Brüel & Kjær was measured at level 2.25 on the Bootstrap scale. It was the only one of the four collaborating companies that started the SPI project at maturity level 2. In the fall of 1999, Brüel & Kjær was again assessed using the Bootstrap model, and the result showed an increase of maturity to 2.5.

Danske Data A/S

Danske Data is a subsidiary of Danske Bank Group, a financial institution that provides all types of financial services (banking, mortgaging, insurance, and so on). The primary business function of Danske Data is the development of information technology (IT) systems for Danske Bank Group, including Danske Bank, the largest bank in Denmark. Danske Data was originally the IT department within the bank, but on July 1, 1996, it was spun off as an independent company.1 The company has approximately 900 employees located at four development centers and is one of Scandinavia’s largest IT companies.

Software development projects at Danske Data vary widely in size; most are small and short-term, but there are also some major projects that have strategic implications for the entire corporation. Project teams of 3 to 5 people typically handle the smaller projects, which usually take 6 to 12 months. Large projects, such as the Year 2000 compliance project, typically involve as many as 150 people and last 6 months to 3 years. Danske Data has four development divisions, each headed by a senior vice president. Each individual division is led by a vice president and organized into departments, typically with 20 to 50 people divided among five or so projects. Project managers oversee regular projects, and the vice president manages high-profile projects. Software developers at Danske Data typically have a bachelor’s degree in either an IT-related field or banking.

Danske Data develops software mainly for mainframe computers but also develops some applications for client/server environments, such as Internet banking. Danske Data mainframe applications run 24 hours a day and process a daily average of nine million transactions from about 11,000 workstations. The company’s mainframe installation is the largest in Northern Europe and is divided between two operation centers. Systems developed for this platform are based on an advanced event-oriented database principle, something that increases data processing flexibility. Security and reliability are the two main system requirements because data are mirrored in real time between the two operation centers in Århus and Copenhagen. Modern methods for modeling data, functions, and workflow are used along with the all-important business model—information framework—which is crucial to getting stakeholders from the user organization involved in the development process.

In May 1997, Danske Data conducted its first assessment of software process maturity. It used both the Capability Maturity Model (CMM) and Bootstrap assessment approaches, which showed the company to be right between level 1 and 2 (1.5 using the Bootstrap scale). Danske Data was again assessed in October 1999 and was at that point at level 2.0.

Ericsson Denmark

The Ericsson Corporation is one of the world’s largest suppliers of telecom equipment. During the past 20 years, the company has gradually transitioned from hardware-only products to embedded software products and pure software products. Ericsson’s major product areas are fixed and wireless switching equipment, mobile phones, telecommunication management systems, PBX systems, transmission equipment, defense systems, and Internet solutions—all of which rely heavily on software. Ericsson Denmark has a mid-sized systems development division within the Ericsson Corporation and employs approximately 500 people working in five product groups.

In early 1996, Ericsson Corporation changed its organizational structure from a line to a matrix organization. In the period following—from 1996 to 1998—Ericsson Denmark’s staff increased from 250 to 400, and each of its product groups reported to corresponding business units located in other countries. Both the Ericsson Corporation and Ericsson Denmark have a long history of improving software development. In 1992, the company took the first steps to set up a corporatewide SPI program, the Ericsson System Software Initiative (ESSI). From the beginning, ESSI was a strategic effort that ensured alignment, deployment, and follow-up on corporate SPI goals. ESSI’s first intervention was in Ericsson’s largest and most complex software development area, the telephone exchange software group. An aggressive goal was defined to reduce fault density in telephone exchange software products by 50% annually.

Another important ESSI initiative focused on CMM as a long-term strategy for improving software development performance. The initiative was supported by the creation of an international corps of trained CMM assessors tasked with determining the level of software process maturity throughout the company. At the end of 1996, the ESSI program had been operational worldwide for a couple of years, and most of the company’s international software development sites had shown good progress toward reaching the corporate fault density goals.

Ericsson Denmark was assessed at level 1 in 1995 and at level 2 in June 1998. In between the two assessments, the division underwent both Light Assessments and UltraLight Assessments.

Systematic Software Engineering

Systematic, founded in 1985, produces and integrates software for complex information and communications systems. Systematic’s international customers include military institutions and suppliers as well as data communication, transportation, and manufacturing companies and organizations in the finance and health care sectors. As a systems integrator, Systematic has established a core competency in the management and implementation of complex software projects that require high reliability and secure communications 24 hours a day. Systematic is recognized by its customers for the timely delivery of quality, cost-effective products.

In 1996, Systematic employed 137 people. Of these employees, 105 were software engineers and 32 worked in finance, administration, internal IT, quality assurance, canteen, and cleaning. By 1999, the number of employees had grown to 155. At Systematic, all software development takes place in project teams, led by a project manager. Most managers started with the company as software engineers and were later trained internally for management responsibilities. In 1998-99, project teams ranged in size from 2 to 18 members and projects lasted from two months to three years. Typically, project members were not rotated out; they stayed with the project from the analysis phase through requirements specification, design, programming, test, documentation, installation, and user training. This practice reflects the company’s belief that such consistency ensures maximum commitment and development of staff competence.

Despite the small number of graduates in computer science and systems engineering in Denmark, two-thirds of Systematic’s employees hold master’s or doctoral degrees. To facilitate high flexibility and preparedness for change, the company recruits highly educated people with knowledge of state-of-the-art technologies. One of the main reasons Systematic undertook SPI was to help meet its goal of becoming an internationally recognized software supplier and systems integrator in communications and interoperability between defense units, and in electronic commerce and data interchange between enterprises. In 1992, Systematic’s quality assurance system was certified in accordance with ISO 9001 and the military standards AQAP 110 and 150. The ISO 9001 certified quality management system is the basis of numerous elements in Systematic’s quality assurance procedures.

In 1997, Systematic conducted its first software process maturity assessment using both the CMM and Bootstrap approaches and was rated to be just under Bootstrap 2. In 1998 and 1999, the company conducted additional Bootstrap assessments, and in 1999 the company was assessed to be at level 2.5 (using the Bootstrap maturity scale).


The book is divided into five parts. Part I consists of Chapters 1 and 2 and introduces the major learning points of our three-year collaborative project. In this first part, we present an overview—a map—of the theories and models that inspired us and formed the basis of our practice in the projects. Part II, Learning from Experience, is divided into four chapters. Each of these chapters characterizes the SPI experience of one of the four collaborating companies and is named accordingly. For example, Chapter 3, The Correct Effort, describes how Ericsson Denmark attempted first to follow standard advice, only to discover that adherence to general prescriptions did not bring the desired results. Thus, it had to deviate, ultimately producing a truly “correct” effort through innovation and adaptation to its particular circumstances.

Part III, Initiating Learning, focuses on how to structure learning conditions and initiate learning in SPI initiatives. We discuss maturity level assessments as an important mechanism for learning. We have used a broad range of assessment methods. Some were inspired by formalized approaches, such as CMM or Bootstrap (discussed in Chapters 7 and 10), whereas others were invented in project groups (Chapters 8 and 9). Finally, Chapter 11 discusses how to select an appropriate assessment strategy. Part IV, Organizing for Learning, goes beyond assessments and takes a more reflective look at SPI: In Chapter 12, we reflect on knowledge transfer; in Chapter 13, we discuss customer maturity; and in Chapter 14 we focus on organizational learning in the SPI context.

Part V examines interesting details in different techniques for SPI. Chapter 15 presents a framework for implementing SPI programs, and the remaining chapters offer detailed discussions of how to carry out risk assessments (Chapter 16), how to implement a metrics program (Chapter 17), and how to improve requirements specification (Chapter 18).

This book is based on a truly collaborative effort. The team of engineers and scientists that have authored the chapters is listed at the very end of this book. Three of the authors—Lars Mathiassen, Jan Pries-Heje, and Ojelanki Ngwenyama—have edited this book assisted by Keri Schreiner who has interacted closely with the authors to help them write for practitioners. Finally, the staff at Addison-Wesley has provided valuable support in designing and producing the book.


Read More Show Less


When Watts Humphrey enticed me to replace him as the Director of the Software Process Program at the Software Engineering Institute in 1991, I began receiving weekly calls from organizations asking, "Now what?"; I would invite them to explain what they were asking about and they would reply, "We have just completed a software process assessment—you know, the SEI thing—now what?"; After I encouraged them to make improvements to some of their most pressing findings, they would invariably ask, "How do we do that?"; I would ask if they had a process group in place, and they would reply "No, should we?"; I would press the point with, "Wasn't someone assigned responsibility before the assessment to do something about the findings?"; Not surprisingly the usual reply refrained their original query, "No! Now what?"; By the end of the call I knew they were frustrated that I had not offered explicit guidance, and I was frustrated that there was little reported experience to support any guidance I might offer.

In those early days most of the advice we offered was based on the technology transfer literature. However, there were two problems with this advice. First, improving an organization's processes was not always like deploying a new technology. In fact the technology transfer literature was rife with examples of transfer failures caused when technologies required major changes to an organization's processes. Second, as we produced the CMM, we realized that introducing new technologies was a risky undertaking until an organization had reached at least level 3. In essence, the models that worked for technology transfer were primarily designed for organizations with defined processes. These were not the organizations calling us. What advice should we offer to organizations in the throes of level 1 adhocracy?

Fortunately, companies began reporting their software process improvement experiences over the next several years in journals and at conferences. Some people who had been in improvement groups began publishing books on their experiences and lessons learned. However, there was no source that integrated and compared software process improvement experiences from multiple companies. This book fills that void.

Improving Software Organizations: From Principles to Practice is one of the best books ever written on software process improvement. It describes real industrial experiences and admits to the problems that were experienced in implementing software process improvement and how they were addressed. Perhaps the greatest lesson in this book is that none of the reigning models of how to conduct improvement programs is sufficient to guarantee success. While most of the models seem academically proper, the action research reported here uncovers the very real limitations in their effectiveness. True to the tenets of good action research, the final chapters induce the lessons learned across this broad research program. Confidence in the generalizability of these lessons across companies is difficult to establish without the broad cooperation and support that was achieved in Denmark during the late 1990s.

With so many companies in so many nations spending so much money on software process improvement, why did an industry-leading book emerge from a country with a comparatively small population? First, because the country cared. The Danish government invested in learning how to increase the capability of its companies to compete in software development. It recognized that organized research and learning would serve the country's industry better than isolated reports delivered at foreign conferences.

Second, because management cared. The four companies that participated in producing the lessons presented in this book realized the critical role that software played in their businesses and that software process improvement was critical to their competitiveness. They believed that the rate of learning from comparing mutual experience exceeded the learning to be gleaned from their individual experiences. Management believed that the benefits gained from participating in pre-competitive research far exceeded the risks of sharing internal experiences, not all of which were positive.

Third, because academia cared. The action research tradition pioneered in Scandinavia is displayed at its most beneficial in this book. Danish researchers ventured beyond their laboratories and campuses to take the risk of applying their ideas in actual practice. This book stands as a testament to the national benefits that can accrue from energetic collaborations between government, industry, and academia. Does publishing these lessons reveal national secrets to countries that didn't pay for the research? Of course it does. But little competitive advantage will be lost, since these companies will be implementing a whole new round of improvements by the time you read this book.

This book is a critical resource for software organizations across the globe. It is important not only because of its valuable lessons, but also because it demonstrates the power of pre-competitive collaborative research. Research I wish I had had access to when I was responding to those phone calls in 1991.

Dr. Bill Curtis
Ft. Worth, Texas

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)