“除了讨论过程改进之外，Sami Zahran还实践者的角度提供了有用的指导。他清晰地阐明过程改进的目的和方法，并对主要方法的原理性牲和特性进行比较。最重要的是，他讨论了用户在实行过程改进时将会面对的各种问题。”
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——Watts Humphrey, CMM之父
　　本书将帮助读者：
　　管理和控制软件产品的质量
　　建立以过程为中心的软件七发机构
　　设计并实现在规定的预算和时间内开发高质量软件产品的规程
　　以软件过程的行业标准（包括CMM、ISO 9001、新的ISO/IEC 15504以及Bootstrap）对机构进行基准测试

Sami Zahram是软件过程改进的主要倡导者之一，他在卡内基梅隆大学的软件工程研究所接受过软件过程改进方面的培训，有30多年大型机构（包括ICL、联合国、DEC和IBM）软件行业高级职位的从业经验。他教授软件过程改进方面的课程多年，并且是许多国际会议和研讨会的特邀演讲人。

Software development is si challenging endeavour
　　Developing reliable software on time and within budget represents a difficult endeavour for many organizations. As the role of software becomes increasingly critical for business as well as for human lives, the problems caused by software products that are late or over budget, or that do not work,become magnified. Loss of life or widespread inconvenience caused by unreliable software makes big headlines in the news media. It is estimated that in the last few years around 4OOO people have died as a result of software defects. In a modern aircraft. if software stops functioning for more than 2OO milliseconds, the aircraft is irrecoverable. In June l996 a European Space Agency rocket carrying a number of European satellites exploded seconds after
its launch. The accident was attributed to software failure. A few years ago,unreliable software made big news in the VX, from emergency services disasters to social security payment blunders, let alone the failure of a large project for the London Stock Exchange. Improved software quality is essential to ensure reliable products and services, and to gain customer satisfaction. The US Government Accounting Office (GAO) reported recently on 'cost rising by millions of dollars, schedule delays of not months but years, and multi-billion dollar systems that do not perform as envisioned' (Paulk et al., l994).
　　 CASE tools sire not enough
　　 Stories about failure of software projects that still excite the press are in sharp contrast to the inflated promises of CASE tools that filled the same press back in the mid and late l98Os. The industry has realized that tools are not enough.
　　One fact that the software industry has established is that 'a fool with a tool is still a fool!'. Vsually business solutions have three main aspects: people,process, and technology. It is evident from industry experience that, when implementing a business solution or introducing a change, the least problematic aspect is usually technology, while processes and people are the critical factors that could make the difference between success and failure.People are an integral part of the process, since they are the enablers of the process activities, process monitoring and process management.
　　 Competent individusils sire not enough
　　 The software industry's experience with CASE tools has proved that the main reason for failing software projects has little to do with technology and tools,and much to do with lack of process discipline. Software development is a team effort. In the absence of process discipline, a team may follow different processes, or more commonly use no defined process at all. In such a case it will be 'like a ball team with some team members playing soccer, some baseball, and others football. Under these conditions, even the best individual players will form a poor team' (Humphrey, l995). In contrast, a team that follows consistent process definitions can better coordinate the work of individual members. direct the efforts of the team members towards the common goal and more precisely track the progress.
　　 Process focus offers better chances for success
　　 Software development as a discipline has existed for more than four decades,but we have not yet turned the software industry into an engineering discipline.The recent focus on the software development process is a step in the right direction. Only by creating a disciplined process for software development can we manage and control the quality of software products. Organizations are realizing that their fundamental problem is the immaturity of their software development process. All the evidence is that investing in software process improvement promises to offer better hope for the software industry, as it has done for other industries such as manufacturing. Also, there is a difference in motivation between a software movement based on tools and one based on process improvement. Process improvement is the responsibility of the organization developing the software and there are no tool vendors with vested interest. The use of tools to automate a chaotic process will lead to more (automated) chaos. Examples are abundant, but one striking example outside the software industry is the shipping of sophisticated armoury and destructive weapons to a chaotic war between two tribal factions in a primitive country.These 'technological tools' are not likely to result in stability. but will probably increase human suffering. Experience has shown that introducing new technology and tools in an immature or undisciplined environment is likely to increase the chaos. A software project without defined processes for control and management (for example quality assurance. configuration management
and project management) will not benefit from tools. Dumping tools into such a project is likely to increase the chaos, to speed uP the production of faulty software and to multiply user dissatisfaction. Such projects could ultimately end up as a disappointment to all concerned. Such disappointments take various forms, such as wasted effort, time, money and resources, and possibly unavoidable disasters.
　　Software process movement: the s-cond wave in the software industry
　　Structured methods were developed in the l97Os to cater for the increasing demands and complexity of software, and consequently the increasing size of development teams. That was the first wave of the software industry. It came as a response to the growing need to build complex interactive commercial applications using shared systems and to make such systems maintainable. Structured methods focus on ways to formalize the definition of requirements
and on the traceability of requirements through design and build into finished systems. Some of these transformations have been assisted to varying degrees by automated tools. Although this was the beginning of transforming software development from a 'cottage industry' to mass production, it was not quite enough. Real issues that make or break software projects, such as project management and requirements management, were not a mainstream focus.The software process movement came as a response to the increasing rate of failure of software projects. Focus on process started through sponsorship by the US Department of Oefense (DoD) which funded the Software Engineering Institute (SEI) to come up with a method for assessing the capability of the Deparment's software subcontractors. Watts Humphrey first joined the SEI in an undefined position and in a couple of months was named Oirector of the Process Program. Since that time the process message coming out of the SEI has gone from strength to strength to influence the whoIe software industry worldwide.
　　One can easily trace the roots of the software process to the quality movement that started in the l93Os and prevai1ed throughout the l97Os, l980s and l990s. The concepts of quality gurus such as Edwards Deming and Philip Crosby gained popularity across manufacturing industry all over the world.Watts Humphrey applied those same quality principles to software development. The process maturity movement prepares the way for the third wave of the software industry: 'software industrialization'. In the third wave software development will become like an assembly and manufacturing process. Enabling technologies for the third wave include object-oriented technology and reusable component libraries. It will then be possible to assemble software from standard reusable components. A critical enabling factor for the third wave is a disciplined software engineering process with predictable quality. schedule and functionality.
　　Aims of this book
　　This book offers a pragmatic approach to the effective implementation of software process improvement. It provides guidelines for creating process support infrastructure, and makes the case for adopting a process view to software development. It outlines a practical approach for setting up a disciplined and continuously improving software process environment. In summary, the book presents a framework for establishing an effective environment for continuous software process improvement.
　　The arguments in the book put emphasis on the people aspect.Understanding and following the process is as important as the process definition. Another equally important emphasis is on the impact of process discipline on team performance and business goals and objectives.
　　The concepts offered in this book are the result of more than thirty years of the author's practical work in the software industry. Most of those years were spent in practica1 experience and research on different facets of software engineering. This included experiencing the pains and pleasures associated with developing software and managing software projects. The projects covered business and industrial applications for a variety of industry sectors ranging from oil, banking and government, to defence, manufacturing and aerospace.They also included involvement in the development of operating systems.database management systems, data dictionary systems, transaction processing systems and a large number of commercial applications. Having lived through both successes and failures of software projects, I readily identified with the process message and teachings which I first received at the Software Engineering Institute, Carnegie Mellon Vniversity, in February l992. Since that time my dedication to the software process has been uninterrupted.
　　Intended audience
　　This book is relevant to and readable by a wide audience, including those who already have some knowledge of softWare process assessment and improve- ment and those who have little knowledge beyond knowing that the subject is significant for them. In other words it contains new ideas and approaches that will interest those who have prior knowledge, and is simple and readable enough to interest those who do not. In particular. it is aimed at the following special interest groups.
　　Softvare englvieerlvig managers and professionals
　　The whole book should be of interest to everyone involved in software engineering activities including management, coordination, development and control. This includes business managers with interest in software. project managers. team leaders, software engineers, and software support tlinctions,such as configuration management, quality assurance and process improve-ment teams. Also the book is suitable for inclusion in graduate software engineering degrees within a unit on software process improvement.
　　Process improvement improvement teams
　　The first part of the book discusses process thinking in generic terms. It should be beneficial to a11 those interested in process improvement activities including business process re-engineering, business process redesign and business process improvement.
　　Process research scientists
　　The book offers a holistic approach to a process improvement environment.The concepts and discussions in the book are intended to provide inspiration for further research effort on process modelling and quality concepts.
　　Structuro of the book
　　The book is structured in five parts, followed by a glossary and list of references.
　　Part 1: Process thinking
　　This part 1ays the intellectual foundation for the rest of the book. It defines and explains process thinking, relates the concepts discussed to process discipline,and describes the characteristics of an effective process environment. It alsorelates these concepts to the software process environment. Part l contains fourchapters:
　　Chapter l. Process thinking
　　Chapter 2. Process discipline
　　Chapter 3. Effective process environment
　　Chapter 4. Process maturity: the second wave of the software industry
　　Part 2: A framework for sofware process improvement
　　This part describes the framework proposed for the software process environment. It describes the components of the framework. the process infrastructure, process improvement roadmaps, process assessment methods. and process improvement plans. This framework should lead to a continuous process improvement environment. Part 2 contains five chapters:
　　Chapter 5. A framework for software process improvement
　　Chapter 6. Software process infrastructure
　　Chapter 7. Process improvement roadmaps
　　Chapter 8. Fundamentals of software process assessment
　　Chapter 9. Software process improvement action plan
　　Part 3: Making sofware process improvement happen
　　Part 3 describes strategies and plans for planning and launching a software process improvement programme in your organization. It discusses steps for converting the assessment results into an improvement plan and highlights theneed for measuring the benefits of software process improvement. It discusses the critical success factors for software process improvement and summarizes some approaches suggested for implementing and institutionalizing the software process, and for measuring its business benefits. Part 3 contains three chapters:
　　Chapter lO. Launching software process improvement
　　Chapter ll. Implementing and institutionalizing software process improvement
　　Chapter l2. Measuring the benefits of software process improvement
　　Part 4: Current models and standards for sofware process improvement
　　Part 4 describes some of the most significant models and standards for software process assessment and improvement. These include the Software Engineering Institute's Capability Maturity Model (CMM) and CMM-based assessments, the International Standards Organization's ISO/IEC l55O4 and its draft guide for assessments, and the BOOTSTRAP assessment method. It also discusses other initiatives and models including ISO 9OOl, MIL-STO-498,Trillium and the V-Model. Part 4 contains six chapters:
　　Chapter l3. The Capability Maturity Model (CMM)
　　Chapter l4. CMM-based software process assessment
　　Chapter l5. ISO/IEC l5504 Oraft Standard to Software Process Assessment
　　Chapter l6. ISO/IEC l55O4 draft guide to conducting assessment
　　Chapter l7. BOOTSTRAP software process assessment
　　Chapter l8. Other initiatives (ISO, MIL-STO-498, Trillium and the V-Model)
　　Part 5: Business benefits Of sofware process improvement
　　Part 5 describes the business benefits of software process improvement, and summarizes some of the case studies in Europe and the USA which have tracked and measured the benefits. Finally it discusses some scenarios for thefuture of software process improvement. Part 5 contains two chapters:
　　Chapter l9: The evidence: business benefits of software process improvement
　　Chapter 20: Epilogue: future of software process improvement

Sami Zahran：暂无简介

I. PROCESS THINKING.
1. Process Thinking.
What is process thinking
What is a process
Process focus.
Process maturity.
2. Process Discipline.
Process discipline.
Benefits of Process discipline.
Process discipline and product quality.
Process-focused organizations.
3. Effective Process Environment.
Process myths and realities.
What is an effective process
Mechanisms for making the process effective.
Process culture.
4. Process Maturity: The Second Wave of the Software Industry.
Waves and megatrends of the software industry.
The software process maturity movement.
Levels of software process institutionalization.
Software process maturity standards and initiatives.
I. A FRAMEWORK FOR SOFTWARE PROCESS IMPROVEMENT.
5. A Framework For Software Process Improvement.
Software process improvement environment.
Software process infrastructure.
Software process improvement roadmap.
Software process assessment.
Software process improvement plan.
6. Software Process Infrastructure.
Justification and definition.
Organizational and management infrastructure.
Process technical infrastructure.
An example of a software process support infrastructure.
Making the infrastructure effective.
7. Process Improvement Roadmaps.
Learning from the quality gurus.
Software process improvement models.
Staged versus continuous architecture for SPI models.
Standards and models for SPI.
8. Fundamentals Of Software Process Assessment.
Definitions of assessment.
Assessment principles and critical success factors.
Assessment domains.
Assessment generic phases.
Mapping assessment approaches to the generic cycle.
9. Software Process Improvement Action Plan.
Creating a software process improvement action plan.
Allocating responsibilities for implementing SPI actions.
Guidance for Action Planning (GAP) -- an example of an action planning method.
III. MAKING SOFTWARE PROCESS IMPROVEMENT HAPPEN.
10. Launching Software Process Improvement.
Stages for making software process improvement happen.
Launching software process improvement.
Adopting a software process improvement model.
Humphrey's process change requirements.
Ingredients for successful software process improvement.
11. Implementing and Institutionalizing Software Process Improvement.
Implementation and institutionalization phases.
Principles for implementing and institutionalizing SPI.
Implementing SPI actions and managing the change.
Institutionalizing software process improvement.
The SEI IDEAL model -- an example of an SPI implementation model.
12. Measuring the Benefits of Software Process Improvement.
Measuring software process performance.
Principles of software process measurement.
Issues with software process measurement.
An example of a software process measurement method.
IV. CURRENT MODELS AND STANDARDS FOR SOFTWARE PROCESS IMPROVEMENT.
13. The Capability Maturity Model (Cmm).
Overview of the Capability Maturity Model.
Maturity levels of the CMM.
Internal structure of the CMM.
Uses of the CMM.
CMM Version 2.0.
14. CMM-Based Software Process Assessment.
CMM-based appraisals.
The SEI maturity questionnaire.
The SEI-assisted assessment process.
SEI software capability evaluation (SCE).
15. ISO/IEC 15504 Draft Standard for Software Process Assessment.
Introduction.
Architecture of the ISO/IEC 15504 standard.
ISO/IEC 15504 process categories.
ISO/IEC 15504 capability levels.
ISO/IEC 15504 capability measurements.
Relationship of ISO/IEC 15504 to other international standards.
16. ISO/IEC 15504 Draft Guide to Conducting Assessment.
Overview.
Assessment planning.
Fact gathering.
Fact analysis.
Presenting the assessment output.
ISO/IEC 15504 guidance on assessment instruments.
Using ISO/IEC 15504 guidance for conducting assessments.
17. Bootstrap Software Process Assessment.
Motivation and background.
BOOTSTRAP process model.
Capability scale and assessment instruments.
The BOOTSTRAP assessment process.
BOOTSTRAP and other initiatives.
18. Other Initiatives.
ISO 9000 quality standards.
ISO/IEC 12207, `Software Life Cycle Processes'.
DoD standard MIL-STD-498.
Trillium.
The V-Model.
V. BUSINESS BENEFITS OF SOFTWARE PROCESS IMPROVEMENT.
19. The Evidence: Business Benefits of Software Process Improvement.
Relating SPI benefits to the business.
Evidence from Europe.
Evidence from the USA.
Lessons learned.
20. Epilogue: Future Of Software Process Improvement.
Process maturity: is it another buzzword
Role of international standards.
Process discipline is a prerequisite for software industrialization.
What next
Glossary.
References.
Index.