Pub. Date:
Better Software Practice for Business Benefit: Principles and Experience / Edition 1

Better Software Practice for Business Benefit: Principles and Experience / Edition 1

by Richard Messnarz, Colin Tully


Current price is , Original price is $126.0. You
Select a Purchase Option
  • purchase options

Product Details

ISBN-13: 9780769500492
Publisher: Wiley
Publication date: 10/28/1999
Series: Perspectives Series , #2
Pages: 409
Product dimensions: 7.01(w) x 10.12(h) x 0.87(d)

Read an Excerpt

Better Software Practice for Business Benefit

Principles and Experience

John Wiley & Sons

ISBN: 0-7695-0049-8

Chapter One

Road Map for Readers and How to Use the Book

Dr. Richard Messnarz International Software Consulting Network (ISCN), Ireland


This chapter classifies the experience presented in this book and provides a road map to guide the reader to extract the experience which is most applicable and beneficial. It starts with a structural analysis illustrating dependencies, links, and relevance for certain phases of the improvement cycle, and finally offers decision support for identifying which parts of the book are usable in the context of the reader's organisation.

While Chapters 2 to 17 present principles and experience, Chapter 1 will make it easy for different target groups in an organisation to select reusable experience and to draw from a large set of data from European process improvement initiatives and projects.


Combined Use of Methodologies

Many process improvement experts are too convinced from only one (their own) approach, leading to statements such as: Only Capability Maturity Model (CMM) will work; or, Only BOOTSTRAP will work; or, Just skip all assessment methods and use goal-based metrics, and so forth. This book is a collection of different experiences with different projects and proposes a combined use of methodologies. This combination of business aspects with pragmatic improvement approaches is essential in order to make the right improvement decisions. It is senseless to make process improvement with just a pragmatic goal to formalize. Return on investment (ROI) and the support of the organization's business success must be the real drivers of any process improvement action.

A big electronics company in Europe, for instance, made an assessment resulting in maturity levels for different areas of the organization and the identification of weaknesses such as unrealistic planning, no process for design reviews, and weak configuration management. The organization was already International Organization for Standardization (ISO) 9001 certified but only 30 percent actually accepted the guidelines due to missing practicability (formally well documented but not realistic for projects in the field). A formal pragmatic assessment and improvement approach would then, for example, decide about introduction of configuration management and so forth, but does this really now meet the organization's business goals? Without any additional data than the normal assessment methodologies (CMM, BOOTSTRAP, etc.) this unfortunately cannot be answered.

So this electronics company decided to run a goal analysis based on the Goal Question Metrics Methodology (GQM) approach, in parallel interviewing business managers, department heads, Information Technology (IT) managers, and project managers to design a consistent goal tree from top to bottom. See Figure 1.1.

One of the specific business policies was to create a financial framework for the next years which allows the funding of a reserve budget to be used to introduce new products to the market. To establish this marketing budget, the business managers decided to stabilize the development effort from divisions at x percent so that, with all other overheads and cost, a certain percentage is saved every year. This enables the marketing budget to be available at the time the product is announced. At this moment, the divisions were certainly higher than ITL×ITL percent and the improvement actions (based on the previously identified weaknesses from the assessment) had three years to demonstrate the success of achieving this business goal.

The technical staff were frightened and thought that people would be dismissed but the truth was that a proper interpretation of the business goals led to a completely different view. The business managers expected that process improvement provides a better work process and environment so that with the same staff more projects and tasks can be done and over time the development effort is stabilized at x percent. Under this perspective the three process weaknesses were again analyzed and further interviews showed a potential of reuse because in all systems in the sector nearly 80 percent of the functionality was always the same. So the improvement plan focused on an integration of design, and on configuration management and review of a reuse pool of these 80 percent functions; and reduction of the development for each project to the only 20 percent additions-thus enhancing productivity and achieving the effort stabilization.

Now, let us assume that only a pragmatic assessment would have been performed. Three weaknesses would have been identified and without reuse orientation would have led to a pragmatic proposal to first run a pilot project to identify a configuration management system and field test it, to disseminate it to other projects, and to help make it a divisionwide standard. Sounds simple, but unfortunately the business context is lost. What then happens is that management sees additional effort, the development effort further increases and, with no vision of decrease of the development effort, the business manager after one year (before benefits can be made visible) would really decide about things like dismissals.

A More People-Oriented Process View

The book, of course, in general follows the principle that an improved process will lead to higher product quality. However, the book also adds to the statement "A fool with a tool is still a fool (so a tool is less important than having a process)" and a further one, "A fool with a process is still a fool." And it is not so much the maturity of each single person itself, it is the teamwork capability that is decisive.

Therefore, in Chapter 3 the book makes a teamwork scenario based definition of management processes in which people identify themselves with roles, people in these roles communicate, and people work together in a team. The workflow (process steps) is then just a waste product of the information flows in the team work (Chapters 3 and 14).

An Inclusion of the Business Context in General

Sometimes people are told that process improvement is a simple step by step pragmatic approach and can be described with technical checklists and levels of maturity. However, as business is dynamic also the requirements for improvement are continuously changing so that the improvement paths themselves underly a continuous adaptation.

Well, in this respect the book demonstrates a number of different viewpoints which might easily be misinterpreted as contradictions. Practice shows that the same strengths and weaknesses profile (as an output from assessments) at different organisations (depending on the business goals, the current infrastructure, the available resources, the cultural approach to change-very different in Japan and Germany compared to the United States) leads to different action plans and results.

So my answer to the above opinion is: I sometimes see persons that accelerate to full speed with confidence although they are directed toward a heavy wall. These are different roads to follow, even with the same starting situation, in different organisations depending on a number of factors, and the most important one is the business context.

Different Process Improvement Languages and Target Groups

Business managers, project managers, and practitioners speak different languages and might have different viewpoints on the same situation. Business managers speak about fixed cost, variable cost, return on investment, leveraging, market trends, product sales, and customer satisfaction. Middle and project managers speak about budget, work plans, quality plans, configuration management, requirements analysis and structured analysis, and always fear to be delayed or to overrun the budget provided by the business managers. Practitioners deal with modules, design them, implement, and test them, and deliver them so that they can be integrated into the system architecture planned by the project manager.

It is the nature of process improvement methodologies that measurement and control functions are installed which again will be seen differently by the different target groups. Business managers-not understanding that software process improvement (SPI) needs investment with a return on investment (ROI) in about 3 years-sometimes demand that process improvement is performed without any assignment of budget to it: let's do quality but it should not cost any dollars. This certainly leads to a disaster and top management commitment is the number one success criteria for starting an improvement program. Middle managers will like the process improvement most because it provides them with methodologies and facilities to better define the processes, to better visualize the productivity and quality, and to improve the predictability which leads to the fact that schedules and budget (which are set by the business managers) are better kept. At the beginning, the practitioners usually see the implementation of a process improvement program as a dirty trick of middle and project management to better control their performance. However, after some time they start to realize that more reliable plans give them enough time for design, and that better design reduces the rework and maintenance stress. Formalized reports help them to identify the root cause of problems and to track the correction, and they can learn and improve themselves based on measures.

It is a key to success to have all groups behind the initiative and to act as a translator of the different viewpoints.


Basically there are three types of relationships in this book outlined in Table 1.1.

Structure of Part I-Principles

Part I-Principles (see Figure 1.2) provides two basic clusters of chapters. A "process" cluster makes a role and teamwork-based software process definition (Chapter 3), introduces goal and process analysis, and provides an overview of currently existing models and methods for software process analysis and improvement (Chapter 4).

A "business" cluster describes the business managers views and return on investment principles (Chapter 2), approaches for goal analysis starting from business goals and breaking down into improvement goals (Chapter 5), and a set of metrics to quantitatively measure if the goals are achieved (Chapter 6). It also provides an overview of cost and benefits in software process improvement (Chapter 7).

It is important to note (Figure 1.2) that the process analysis results and proposed improvement actions must be aligned with the business goals (thus there is a double arrow between Chapter 4 and Chapter 5) resulting in ROI.

Structure of Part II-Experience

Part II-Experience contains three basic clusters of chapters (see Figure 1.3). Chapter 8 discusses Siemens's assessment and improvement programme, and Chapters 9 and 10 illustrate the experience with improvement projects at Italtel, one starting with the Siemens assessment approach and one starting with the BOOTSTRAP assessment approach. Chapter 12 discusses Alcatel's experience in the same application domain as presented in Chapters 9 and 10 by Italtel.

Chapter 13 discusses experience with the ISO 12207 process modeling standard which formed the basis for the Software Process Improvement and Capability Determination (SPICE) methodology, and Chapter 16 presents the experience with the SPICE trials.

Chapters 11, 14, 15, and 17 represent industrial case studies from small- and medium-sized enterprises (SMEs) and very small enterprises covering process analysis, improvement planning, measurement, and benefit analysis.

Principles and Experience-Links between Chapters of Parts I and II

Table 1.2 illustrates which company contributed experience with which approach. Plan Do Check Act Cycle (PDCA), Goal Question Metrics Methodology (GQM), and Application of Metrics in Industry (ami) are in one category. This is because practice showed that ami is a framework to do GQM and that goal-oriented methodologies usually refer to a general improvement framework like PDCA. This is the curious reason why these three categories are combined into one in this book.


There are different types of improvement projects such as

technology transfer based process improvement process modeling based process improvement training based process improvement

A process improvement project usually consists of a group of miniprojects combining the three types mentioned above. This could, for instance, be (1) to analyse and model a work scenario for configuration management, (2) to select and introduce a proper technology for supporting the work, and (3) to train the people to effectively follow the guidelines and use the infrastructure. However, in some cases you only need a better process model, or there might be a process already in place but the technology is missing, or there might be a proper technology in place but due to cultural issues the acceptance was missing. Thus, a process improvement project does not always cover all three components.

Technology Transfer Based Improvement

The selection and introduction of new technologies and platforms is a complex process and the required effort is often underestimated. All recent improvement models emphasise that organisational aspects are most important, and that methodology is more important than technology. This means that before selecting any technology the work scenario must be designed and discussed with the engineers and, based on a defined organisational process, technology requirements are established to support certain process steps-and only then a technology is selected which satisfies the defined requirements. In BOOTSTRAP profiles, for instance, this becomes visible when the technology satisfaction is high, whereas the methodology level is low. Usually engineers also do not accept a new technology if it is not an integrated part of their work environment.

Therefore a technology transfer based improvement project is like a professional development project, with phases like:

Analyse and design the work scenario (process modeling based process improvement) Identify the process steps which should be supported by technology Identify quantitative goals (expected benefits) in terms of quality and productivity Establish a list of requirements for the technology Evaluate the technology available on the market against the established requirements Select one (or more) candidates and implement them in pilot projects Measure the impact of the new technology on quality and productivity Extract best practices from the pilot projects Prepare the best practice for internal dissemination and training Train and transfer best practices to all other projects in the organisation

Process Modeling Based Improvement

Problems resulting from the increasing complexity of software systems were budget and schedule overruns, and reliability and quality problems leading to extremely high maintenance costs. In the early eighties Boehm discussed the so-called "S-curve," which shows that software is becoming increasingly expensive, whereas hardware is getting cheaper. The "S-curve" was investigated in the United Kingdom (U.K.) and it was found that in 1985 the distribution of the percent of total cost was as follows: 10 percent hardware, 90 percent software, with about 60 percent of the software activities being maintenance related.

All approaches to process improvement at the beginning of the eighties to cope with the software crisis were of a technocratic type, and the promises of the CASE manufacturers (including analysis and design components as well as code generators and 4GL facilities) have not been fulfilled. The above-mentioned study continued the analysis of the "S-curve" until 1991, and it was shown that the high maintenance costs of 1985 could not be reduced. Moreover, a Canadian study pointed out that in 1989, due to the international software crisis, the distribution of the percent of total effort was: 55 percent maintenance, 35 percent enhancements, and only 10 percent for new applications.

Because of the failure of the technology-driven approaches the interest in process-driven approaches started to increase in the mid-eighties. This led to the SEI technical report from Humphrey at 1987, the ISO 9001 standards, the IEEE software engineering standards, the ESA PSS05 software engineering standards, the different CMMs, and methodologies such as ami, BOOTSTRAP, etc. which were then developed between 1987 and 1993. And with SPICE this initiative is continuing.


Excerpted from Better Software Practice for Business Benefit Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Table of Contents



Chapter 1: Road Map for Readers and How to Use the Book.

Chapter 2: The Software Process in the Context of Business Goals and Performance.

Chapter 3: Software Process Analysis and Improvement: Concepts and Definitions.

Chapter 4: Software Process Analysis and Improvement: A Catalogue and Comparison of Models.

Chapter 5: Goal-Based Software Process Improvement Planning.

Chapter 6: Process and Product Measurement.

Chapter 7: Costs and Benefits of Software Process Improvement.


Chapter 8: Siemens Process Assessment Approach.

Chapter 9: Quantifying the Benefit of a Long-Lasting Process Improvement Programme in Switching Applications.

Chapter 10: From Assessment to Improvement: An Experience in the GSM Application Domain.

Chapter 11: Process Improvement in Internet Service Providing.

Chapter 12: Alcatel's Experience with Process Improvement.

Chapter 13: Software Process Identification: A Case Study Using the ISO/IEC 12207 Software Life Cycle Processes Standard.

Chapter 14: Experience With A Lean Team Model and Open Architecture Culture.

Chapter 15: AIMing for Increases In Software Process Maturity: Some Irish Case Studies.

Chapter 16: Success Factors and Barriers for Software Process Improvement.

Chapter 17: Applying Quantitative ISO Auditing Techniques -
The BICO Approach.


Chapter 18: Summary and Outlook.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews