Software Process, Management,
and Quality
李 宣 东
南京大学计算机科学与技术系
Outline
• Software Process
• Software Quality Assurance
• Software Configuration Management
• Software Project Management Concepts
Software Process
• The software process has been the focus of considerable
attention over the last decade. 软件过程是近十年来人们关注
的焦点。
• A software process is a framework for the tasks that are required
to build high-quality software.软件过程是为开发高质量软件
所需要完成的任务的框架。
• More important, software engineering is performed by creative,
knowledgeable people who should work within a defined and
mature software process.
软件工程是有创造力、有知识的人在定义好的、成熟的软件
过程框架中进行的。
Software Process
Software engineering layers
tools
methods
process
A quality focus
Software Process
Software engineering is a layered technology:
• Any engineering approach (including software
engineering) must rest on an organizational
commitment to quality.
任何工程方法（包括软件工程）必须以有组织
的质量保证为基础。
Software Process
Software engineering is a layered technology:
• Total quality management and similar philosophies foster a
continuous process improvement culture, and it is this
culture that ultimately leads to the development of
increasingly more mature approaches to software
engineering.
全面的质量管理和类似的理念刺激了不断的过程改进，正是这种
改进导致了更加成熟的软件工程方法的不断出现。
• The bedrock that supports software engineering is a focus
on quality.
支持软件工程的根基就在于对质量的关注。
Software Process
Process layer of software engineering
• The foundation for Software engineering is the process
layer.
• Software engineering process is the glue that holds the
technology layers together and enables rational and timely
development of computer software.
软件工程过程是将技术层结合在一起的凝聚力，使得软件能够被
合理地和及时地开发出来。
Software Process
Process layer of software engineering
• Process defines a framework for a set of key process areas
(KPAs) that must be established for effective delivery of
software engineering technology. 过程定义了一组关键过程区
域的框架，这对于软件工程技术的有效应用是必须的。
• The key process areas form the basis for management control of
software projects and establish the context in which technical methods
are applied, work products (models, documents, data, reports, forms,
etc.) are produced, milestones are established, quality is ensured, and
change is properly managed. 关键过程区域构成了软件项目管理控
制的基础，并且确定了上下各区域之间的关系，规定了技术方法
的采用、工程产品（模型、文档、数据、报告、表格等）的产生、
里程碑的建立、质量的保证及变化的适当管理。
Software Process
Methods layer of software engineering
• Software engineering methods provide the technical how-to’s
for building software. 软件工程方法提供了为开发软件在技术上
需要“如何做”。
• Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing,
and maintenance. 方法涵盖了一系列的任务：需求分析、设计、
编程、测试和维护。
• Software engineering methods rely on a set of basic principles
that govern each area of the technology and include modeling
activities and other descriptive techniques. 软件工程方法依赖于
一组原则，这些原则控制了每一个技术区域，且包含建模活动和
其他描述技术。
Software Process
Tool later of software engineering
• Software engineering tools provide automated or semiautomated support for the process and methods. 软件工程工
具对过程和方法提供了自动的或半自动的支持。
• When tools are integrated so that information created by
one tool can be used by another, a system for the support
of software development, called computer-aided software
engineering (CASE), is established.当这些工具被集成起来使
得一个工具产生的信息可以被另外一个工具使用时，一个支持软
件开发的系统就建立了，称为计算机辅助软件工程（CASE）。
Software Process
Tool later of software engineering
• CASE combines software, hardware, and software
engineering database (a repository containing important
information about analysis, design, program construction,
and testing) to create a software engineering environment.
CASE集成了软件、硬件和一个软件工程数据库（包含了关于分
析、设计、编程和测试的重要信息），从而形成了一个软件工程
环境。
Software Process
A generic view of software engineering
The work associated with software
engineering can be categorized into three generic
phases, regardless of application area, project size,
or complexity:
• The definition phase focuses on what.
• The development phase focuses on how.
• The support (maintenance) phase focuses on change.
Software Process
A generic view of software engineering
The phases and related steps described in generic
view of software engineering are complemented
by a number of umbrella activity (保护性活动):
•
•
•
•
•
•
•
•
Software project tracking and control
Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management
Software Process
• 过程：为实现一个给定目标而进行的一
系列运作步骤。
• 过程具有一系列的性质：时间性、并发
性、嵌套性和度量性等。
• 软件过程：开发和维护软件及其相关产
品所设及的一系列活动。过程是框架的
集合；框架是任务的集合；任务是把输
入转换为输出的活动。
Software Process
A software process can be characterized as follows:
• A common process framework is established by defineing a
small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.
• A number of task sets - each a collection of software
engineering work tasks, project milestones, work products, and
quality assurance points - enable the framework activities to be
adapted to the characteristics of the software project and the
requirements of the project team.
• Umbrella activities - such as software quality assurance,
software configuration management, and measurement - overlay
the process model. Umbrella activities are independent of any
one framework activity and occur throughout the process.
Software Process
Common process framework
Framework activities
Task sets
Tasks
Milestones, deliverables
SQA points
Umbrella activities
Software Process
软件过程提供了一个框架，在该框架下可
以建立一个软件开发的综合计划：
• 若干框架活动适用于所有软件项目，而不在乎其规模
和复杂性。
• 若干不同任务的集合----每一个集合都由任务、里程碑、
交付物以及质量保证点组成----使得框架活动适应于不
同软件项目的特征和项目组的需求。
• 若干保护性活动----如软件质量保证、软件配置管理、
测试与度量----它们贯穿于整个过程模型之中。保护性
活动独立于任何一个框架活动，且贯穿于整个过程之
中。
Software Process Models
软件过程模型是软件开发的指导思
想和全局性框架，软件过程模型的提出
和发展反映了人们对软件过程的某种认
识观，体现了人们对软件过程认识的提
高和飞跃。
Software Process Models
瀑布模型
定义
分析
设计
编码
测试
强调阶段的划分
维护
及其顺序性、各阶段工作
及其文档的完备性，是一种严格线性的、
按阶段顺序的、逐步细化的开发模式。
Software Process Models
瀑布模型的特点：
• 结构简单明了；历史较长、应用面广泛、
为广大软件工作者所熟悉；已有与之配
套的一组十分成熟的开发方法和丰富的
支撑工具。
• 确定了需求分析的绝对重要性，但是在
实践中要想获得完善的需求说明是非常
困难的；反馈信息慢。
Software Process Models
The Prototyping model (原型模型)
Listen to
customer
Build/revise
mock-up
Customer
test drives
mock-up
Software Process Models
原型模型的特点：
• 原型作为标识软件需求的一种机制，原
型被建造仅是为了定义需求，之后就该
被抛弃（或至少部分抛弃）；
• 实际的软件在充分考虑了质量和可维护
性之后才被开发。
Software Process Models
Evolutionary software process models
(演化软件过程模型)
• There is growing recognition that software, like all
complex systems, evolves over a period of time. Business
and product requirements often change as development
proceeds, making a straight path to an end product
unrealistic.
人们已经越来越认识到软件就象所有复杂系统一样要经过一段时
间的演化。业务和产品需求随着开发的发展常常发生改变，想找
到最终产品的一条直线路径是不可能的。
Software Process Models
Evolutionary software process models
(演化软件过程模型)
• Tight market deadlines make completion of a
comprehensive software product impossible, but a limited
version must be introduced to meet competitive or business
pressure; a set of core product or system requirements is
well understood, but the details of product or system
extensions have yet to be defined.
紧迫的市场期限使得难以完成一个完善的软件产品，但可以先提
交一个有限的版本以对付竞争或商业的压力；只要核心产品或系
统需求能够很好地理解，而产品或系统的细节部分可以进一步定
义。
Software Process Models
Evolutionary software process models
(演化软件过程模型)
• Evolutionary models are iterative. They are
characterized in a manner that enables software
engineers to develop increasingly more complete
versions of the software.
演化模型是利用一种迭代的思想方法，它的特征是使
软件工程师渐进地开发逐步完善的软件版本。
• The incremental model (增量模型)
• The spiral model (螺旋模型)
Software Process Models
The incremental model (增量模型)
分析
设计
分析
分析
编码
设计
设计
测试
编码
编码
增量1
测试 增量2
测试 增量3
Software Process Models
增量模型的特点：
• 以功能递增的方式进行软件开发
• 能较快地产生可操作的系统；
• 在每一步递增中，都可以把用户/开发者
的经验结合到不断求精的产品中；
• 可改善测试效果和降低软件开发总成本。
Software Process Models
需求定义
The spiral Model
螺旋模型
风险分析
评审
工程实现
Software Process Models
螺旋模型的特点：
• 把软件开过程组成为一个逐步细化的定
义周期（螺旋周期）序列，每经历一个
周期，系统就得到进一步的细化和完善；
• 本质上，具有上述特征的螺旋是一直运
转的直到软件退役。有时这个过程处于
睡眠状态，但任何时候出现了改变，过
程都会从合适的入口点开始；
Software Process Models
螺旋模型的特点：
• 紧密围绕开发中的风险问题，用风险分
析推动软件设计向深一层扩展、求精；
• 强调持续地判断、确定和修改用户任务
目标，并按成本、效益来分析候选的软
件产品性质对任务目标的贡献；
• 可结合采用多种软件开发方法，但究竟
结合哪一种方法仍由风险分析来决定。
Software Process Models
The formal methods model
(形式化方法模型)
形式化方法的主要目的是要把软件开发过程
建立在严密可行的数学基础之上，从而提高软
件质量和软件生产率。
• 事后的或并行的一种辅助手段，用以对系统的性质进
行严格的验证；
• 集成到软件开发过程中，希望在严格的形式系统的基
础上，实现从需求规约到程序代码的转换和过渡。
Software Process Management
改进软件过程
• 研究软件过程本质上是为了突出关键过
程以改善软件的质量。人们已经得到共
识，要提高软件质量必须改进软件过程。
Software Process Management
改进软件过程
• 软件机构形成一套完整而成熟的软件过
程不是一蹴而就的，它需要一个从无序
到有序，从特殊到一般，从定性到定量，
最后再从静态到动态的历程，或者说软
件机构在形成成熟的软件过程之前必须
经历一系列的成熟阶段。
Software Process Management
改进软件过程
• 因此有必要建立一个软件过程成熟度模
型来对过程作出一个客观、公正的评价，
以促进软件开发组织改进软件过程。
Software Process Management
软件过程成熟度
指一个特定的软件过程被显式定义、管理、
度量、控制和能行的程度。成熟度可以用于指
示企业加强其软件过程能力的潜力。 当一个企
业达到了一定的软件过程成熟级别后，它将通
过制定策略、建立标准和确立机构结构使它的
软件过程制度化。而制度化又促使企业通过建
立基础设施和公司文化来支持相关的方法、实
践和过程。从而使之可以持续并维持一个良性
循环。
Software Process Management
不成熟企业的标志：
• 缺乏确定的软件过程和相应的管理和控
制；
• 即使给出了软件过程，也不严格的遵循
和强制执行；
• 管理是完全被动的，管理者采用的策略
是救火式的，即出了事才去解决，解决
的时候也难以纵观全局，往往只顾眼前；
Software Process Management
不成熟企业的标志：
• 由于缺乏有依据的估算，制订软件预算
和生产计划时往往跟着感觉走，实际生
产时则常常超标；
• 如果强制在预定期限内完成，那么软件
的功能和质量肯定是得不到保证；
• 缺乏评价软件产品质量和解决产品缺陷
和过程问题的客观基础。
Software Process Management
成熟企业的标志：
• 具有在企业范围内管理、控制软件开发
和维护过程的能力；
• 现有人员和新进人员均了解所遵循的软
件过程，且工作活动均按照事先的计划
完成；
• 在定义好的软件过程中，所有项目和机
构中的角色和责任分明；
Software Process Management
成熟企业的标志：
• 制定的计划是有效的且与实际的工作进
展一致；
• 软件过程在必要时可按照一定规则和程
序加以修改；
Software Process Management
成熟企业的标志：
• 软件产品和过程具有一定的可控性：
1. 管理者能够监督软件产品的质量和生产过程；
2. 具有客观的和定量化的措施来判断产品质量并分析产品与生产
过程中的问题；
3. 计划和预算有章可循，它是基于历史数据的，从而是实际可行
的；
4. 预算的结果，包括成本、时间表、产品功能和质量等，通常能
够达到；
5. 有关的参与者完全理解遵循软件过程的价值并认真地遵循之；
6. 具有支撑软件过程的基础设施，如标准过程库、历史数据库等。
Software Process Management
软件能力成熟度模型
（ Capability Maturity Model，CMM）
• 软件能力成熟度模型提美国大学Carnegie
Mellon University软件工程研究所出的一套系统、
规范的对软件生产过程进行管理的模型，其有
效性已为大量实践所证实，并已成为对一个软
件企业的生产能力和产品质量进行衡量的事实
标准。
Software Process Management
软件能力成熟度模型（CMM）
• CMM被用来确定一个机构的软件过程的成熟
程度以及指明如何提高该成熟度的参考模型。
• CMM描述了软件过程从无序到有序、从特殊
到一般、从定性管理到定量管理、最终到达可
动态优化的成熟过程，给出了该过程中五个成
熟阶段的基本特征和应遵循的原则、 采取的行
动，以帮助软件机构改进其软件过程。
Software Process Management
CMM的主要作用
CMM可以指导软件机构如何控制软件产品的开发
和维护过程，以及如何向成熟的软件工程体系演化，
并形成一套良性循环的管理文化。具体说来，一个企
业要想改进其生产过程，应该采取如下策略和步骤：
• 确定软件企业当前所处的过程成熟级别；
• 了解对改进软件生产质量和加强生产过程控制起关键
作用的因素；
• 将工作重点集中在有限几个关键目标上，有效达到改
进机构软件生产过程的效果，进而可持续地改进其软
件生产能力。
Software Process Management
CMM的基本前提
• 软件质量在很大程度上取决于产生软件
的软件过程的质量和能力；
• 软件过程是一个可管理、可度量并不断
改进的过程；
• 软件过程的质量受到用以支撑它的技术
和设施的影响；
• 企业在软件过程中所采用的技术层次应
适应于软件过程的成熟度。
Software Process Management
CMM的基本原理
• CMM强调连续的软件过程改进。该连续的改
进基于多个演化步骤。CMM将这些演化步骤
划分成五个级别。这种分级结构的理论依据是
软件质量原理。
• 每一级别都包括若干目标。当满足某一目标后，
软件过程的相应部分便确定下来。
• 五级成熟度定义了一个标准，用以度量机构的
软件过程成熟度和评价其软件过程能力。
Software Process Management
CMM的基本内容
• 机构和资源的管理：涉及机构本身的责
任，人员和其它资源设施。
• 软件工程过程及其管理：涉及软件工程
过程，即软件过程的深度、范围和完整
性以及如何度量、管理和改进这样的过
程。
• 工具和技术：软件工程过程中使用的开
发工具和技术。
Software Process Management
CMM contains five process maturity levels
(CMM的五个成熟度级别)
•
•
•
•
•
Level 1: Initial (初始级)
Level 2: Repeatable (可重复级：有规章的过程 )
Level 3: Defined (定义级：标准化、一致的过程)
Level 4: Managed (管理级：可预测过程)
Level 5: Optimizing (优化级：可持续改进的过程)
Software Process Management
CMM的初始级（第一级）
• 成功来源于个人英雄主义而非机构行为，
因此它不可重复，更换人员后成功便难
以维持。
Software Process Management
CMM的可重复级（第二级）
• 针对特定软件项目建立管理该项目的策略和实
现这些策略的过程。
• 新项目的计划和管理基于类似项目的经验。
• 软件过程能力主要通过管理单个项目的软件生
产过程来得到提高和增强。
• 不同的项目可有不同的软件过程，机构应当建
立一定的方针和策略以针对具体的项目选择合
适的软件生产过程并进行管理。
Software Process Management
CMM的可重复级（第二级）
可重复级的主要特点在于确定了基本的软件生产
管理和控制，具体来讲有：
• 结合已有项目的经验和新项目的特点来确定本项目的
责任和承诺；
• 软件生产成本、时间表和实现的功能被有效跟踪；
• 识别实现承诺所需解决的关键问题；
• 定义软件项目过程标准，机构要确保其被遵守。
Software Process Management
CMM的可重复级（第二级）
概括来说，第二级的主要特点是项
目计划和跟踪是确定且有效的，项目的
软件过程是可控的，以及已有的成功经
验是可重复的。
Software Process Management
CMM的定义级（第三级）
• 有一个机构范围内标准的软件过程，软件工程活动和
管理活动被集成为一个有机的整体。标准化的目的是
使高层管理者和软件技术人员能够有效合作。
• 有一个组例如软件工程组（SEPG）专门负责订立机构
的标准软件过程，并且在机构中制定培训计划来确保
相关人员和管理者有足够的知识和技能完成标准过程
所赋予的角色。
• 标准的软件过程结合具体项目的特点经过裁剪即形成
项目定义软件过程，它是一组集成的完善定义的软件
工程和管理过程。
Software Process Management
CMM的定义级（第三级）
• 一个完善定义的软件过程应包括就绪准则、输入、工
作过程、验证机制、输出和完成准则。
• 对于已建立的产品生产线，其成本、时间表和实现功
能均可跟踪和控制，软件产品的质量可以得到保证。
• 软件过程能力的实现主要基于在机构范围内对一个定
义软件过程的活动、角色和责任的共同理解。
Software Process Management
CMM的定义级（第三级）
概括来说，第三级的主要特征在于
软件过程已被提升成标准化过程，从而
更加具有稳定性、重复性和可控性。
Software Process Management
CMM的管理级（第四级）
软件的过程和产品有定量的质量指标：
• 重要的软件过程活动均配有生产率和质
量方面的度量指标；
• 应用数据库来收集和分析定义软件过程
中涉及的各种数据；
• 对项目软件过程和软件质量的评价有定
量的基准。
Software Process Management
CMM的管理级（第四级）
软件项目的产品和生产过程的控制具有
可预测性：
• 将软件过程效能可能出现的偏差控制在
可接受的量化界限内；
• 具体区分影响过程效能发生偏差的有效
因素和偶然因素；
• 向新领域拓展的风险是可预知的并被仔
细管理和权衡。
Software Process Management
CMM的管理级（第四级）
概括来说，第四级的主要特征是定
量化、可预测、异常控制和高质量。
Software Process Management
CMM的优化级（第五级）
机构集中于持续的过程改进：
• 具有标识过程缺陷和增强过程能力的有效手段。
• 利用试验数据分析使用新技术所需的代价和带
来的效益，然后再有选择地采用。
• 当出现偏差时，软件项目人员能够分析出错原
因并采取有效手段防止其再次出现。
• 防止不必要的浪费是第五级的重点。
Software Process Management
CMM的优化级（第五级）
改进的途径有两个，一个是对已有
过程的渐进式改进；另一个则是有选择
地使用新技术和新方法所带来的革新。
概括来说，第五级的主要特征是新
技术的采用和软件过程的改进被作为日
常的业务活动来加以计划和管理。
Software Process Management
如何看待CMM：
•
•
•
•
梯子
镜子
牌子
补药
Software Quality
Software quality is defined as
• Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards, and implicit
characteristics that are expected of all
professionally developed software.
明确声明的功能和性能需求、明确文档化过的开发标
准、以及专业人员开发的软件所应具有的所有隐含特
征都得到满足。
Software Quality
Definition of software quality
• Software requirements are the foundation from which
quality is measured. Lack of conformance to requirements
is lack of quality.
软件需求是进行“质量”度量的基础。与需求不符就是质量不高。
• Specified standards define a set of development criteria
that guide the manner in which software is engineered. If
the criteria are not followed, lack of quality will almost
surely result.
指定的标准定义了一组指导软件开发的准则。如果不能遵守这些
准则，就极有可能导致质量不高。
Software Quality
Definition of software quality
• A set of implicit requirements (e.g., the desire for ease of
use and good maintainability) often goes unmentioned. If
software conforms to its explicit requirements but fails to
meet implicit requirements, software quality is suspect.
通常有一组“隐含需求”是不被提及的（如对维护性的需求）。
如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然
值得怀疑。
Software Quality
软件质量
质量要素
衡量标准
度量
度量
质量要素
衡量标准
度量
度量
衡量标准
度量
度量
衡量标准
度量
度量
Software Quality
McCall模型中的软件质量要素
Maintainability(易维护性)
Flexibility (灵活性)
Testability (易测试性)
产品
修改
产品
变迁
Portability (易移植性)
Reusability (易复用性)
Interoperability (互用性)
产品
运行
Correctness (正确性) Reliability (可靠性) Efficiency (高效率)
Integrity (完整性) Usability (易使用性)
Software Quality Assurance
• Software quality assurance (SQA) is an
umbrella activity that is applied throughout
the software process.
Software Quality Assurance
SQA encompasses
• a quality management approach (一种质量管理方法)
• effective software engineering technology (methods and tools) (有效
的软件工程技术（方法和工具))
• formal technical reviews that are applied throughout the software
process (在整个软件过程中采用的正式技术复审)
• a multitiered testing strategy (一种多层次的测试策略)
• control of software documentation and the changes made to it (对软件
文档及其修改的控制)
• a procedure to ensure compliance with software development
standards (保证遵从软件开发标准的规程)
• measurement and reporting mechanism (度量和报告机制)
SQA小组
• 在一个组织中有多个机构负有保证软件
质量的责任，包括软件工程师、项目管
理者、客户、销售人员和SQA小组成员。
• SQA小组负责质量保证的计划、监督、
记录、分析及报告工作。
• SQA小组充当客户在公司内部的代表。
这就是说，SQA小组的成员必须以客户
的观点看待软件。
SQA计划
SQA计划为建立软件质量保证提供一张行
路图，其由SQA小组和项目组共同制定，充当
软件项目中SQA活动的模板。
•
•
•
•
•
•
需要进行的评价；
需要进行的审计和复审；
项目可采用的标准；
错误报告和跟踪过程；
由SQA小组产生的文挡；
为软件项目组提供的反馈数量。
SQA活动
• 为项目准备SQA计划；
• 参与开发该项目的软件过程描述；
• 复审各项软件工程活动、对其是否符合定义好的软件
过程进行核实；
• 审计指定的软件工作产品、对其是否符合定义好的软
件过程中的相应部分进行核实；
• 确保软件工作及工作产品产品中的偏差已被记录在案，
并根据预定规程进行处理；
• 记录所有不符合的部分，并报告给高级管理者；
• 协调变化的控制和管理，并帮助收集和分析软件度量
信息。
Software Configuration Management
• Change is inevitable when computer software is built.
And change increases the level of confusion among
software engineers who are working on a project.
Confusion arises when changes are not analyzed
before they are made, recorded before they are
implemented, reported to those with a need to know,
or controlled in a manner that will improve quality
and reduce error. 当开发软件系统的过程中，变化是不可避免
的。这些变化使得在同一个项目中工作的软件开发人员之间的彼
此不理解程度更加增大。当变化进行前没有经过分析、变化实现
前没有被记录、没有向那些需要知道的人报告变化、或变化没有
以可以改善质量及减少错误的方式被控制时，大量的不理解问题
将会产生。
Software Configuration Management
• The art of coordinating software development to
minimize confusion is called software
configuration management (SCM).
协调软件开发以减少由变化带来的不理解性到最小程
度的技术称为配置管理。
• SCM is an umbrella activity that is applied
throughout the software process.
软件配置管理（SCM）是贯穿于整个软件过程中的保
护性活动。
Software Configuration Management
SCM activities are developed to:
• identify change
• control change
• ensure that change is being properly
implemented
• report changes to others who may have an
interest
Software Configuration Management
It is important to make a clear distinction between
software support (maintenance) and configuration
management
• 维护是发生在软件已经被交付给客户、并且投入运行
后的一系列软件工程活动。
• 软件配置管理则是当软件项目开始时就开始、并且仅
仅当软件退出运行后才终止的一组跟踪和控制活动。
Software Configuration
• Computer programs (both source level and
executable forms)
• documents that describe that computer programs
(targeted at both technical practitioners and users)
• data (contained within the program or external to
it)
所有在软件过程中产生的信息，总称为软件配置
Origin of changes
有四种基本的变化源：
• 新的商业或市场条件，引起产品需求和业务规则的变
化。
• 新的客户需要，要求修改信息系统产生的数据、产品
提供的功能、或基于计算机的系统提供的服务。
• 改组和/或企业规模减小，导致项目优先级或软件工程
队伍结构的变化。
• 预算或进度的限制，导致系统或产品的重定义。
Software Configuration Items, SCI
软件配置项（Software Configuration Items,
SCI）定义为部分软件工程过程中创建的信息，
在极端情况下，一个SCI可被考虑为某个大的
规约中的某个单独段落，或在某个大的测试用
例集中的某种测试用例，更实际地，一个SCI
是一个文档、一个全套的测试用例、或一个已
命名的程序构件（例如，C＋＋函数或Ada95软
件包）。
Baselines (基线)
• A baseline is a software configuration
management concept that help us to control
change without seriously impeding justifiable
change.
基线是一个软件配置管理的概念，它帮助我们在不严
重阻碍合理变化的情况下来控制变化。
Baselines
The IEEE (IEEE Std. No.610.12-1990)
defines a baseline as:
• A specification or product that has been formally
reviewed and agreed upon, that thereafter serves
as the basis for further development, and that can
be changed only through formal change control
procedures.
已经通过正式复审审核批准的某规约或产品，它因此
可以作为进一步开发的基础，并且只能通过正式的变
化控制过程而改变。
Baselines
• A baseline is analogous to the kitchen doors in the
restaurant. Before a software configuration item
becomes a baseline, change may be made quickly
and informally. However, once a baseline is
established, we figuratively pass through a
swinging one-way door. Changes can be made, but
a specific, formal procedure must be applied to
evaluate and verify each change.在软件配置项变成基线
前，变化可以迅速而非正式地进行，然而，一旦基线已经建立，
我们就得象通过一个单向开的门那样，变化可以进行，但是，必
须应用特定的、正式的规程来评估和验证每个变化。
Baselines
• In the context of software engineering, a baseline
is a milestone in the development of software that
is marked by the delivery of one or more software
configuration items and the approval of these SCIs
that is obtained through a formal technical review.
在软件工程的范围内，基线是软件开发中的里程碑，
其标志是有一个或多个软件配置项的交付，且这些SCI
已经经过正式技术复审而获得认可。
The Most Common Software Baselines
系统工程
系统规约
需求定义
软件设计
编
码
测
试
发
布
软件需求规约
设计规约
源代码
测试计划/过程/数据
可操作的系统
Progression of Events that lead to a Baseline
修改
SCIs
项目数据库
软件
工程
任务
SCIs
正式
技术
复审
认可
SCIs
存储
SCIs
SCM
控制
SCIs
提取
Baselined SCIs (成为基线的SCIs)
• 系统规约
• 软件项目计划
• 软件需求规约
图形分析模型；处理规约；原型；数学规约
• 初步的用户手册
Baselined SCIs
• 设计规约
数据设计描述；体系结构设计描述；模块设计
描述；界面设计描述；对象描述（如果使用面
向对象技术）
• 源代码清单
• 测试规约
测试计划和过程；测试用例和结果记录
• 操作和安装手册
Baselined SCIs
• 可执行程序
模块的可执行代码；链接的模块
• 数据库描述
模式和文件结构；初始内容
• 联机用户手册
• 维护文档
软件问题报告；维护请求；工程变化命令
• 软件工程的标准和规约
Baselined SCIs
• 除了上面列出的SCI，很多软件工程组织也将
软件工具列入配置管理之下，即，特定版本的
编辑器、编译器和其他CASE工具被“固定”
作为软件配置的一部分。因为这些工具被用于
生成文档。源代码和数据，所以当对软件配置
进行改变时，必然要用到它们。虽然问题并不
多见，但有可能某工具的新版本（如，编译器）
可能产生和原版本不同的结果。为此，工具就
象它们辅助生产的软件一样，可以被基线化，
并做为综合的配置管理过程的一部分。
SCM Process
软件配置管理是软件质量保证的重要
一环，其主要责任是控制变化。然而，
SCM也负责个体SCI和软件的各种版本的
标识、软件配置的审计（以保证它已被
适当地开发）、以及配置中所有变化的
报告。
SCM Process
任何关于SCM的讨论均涉及一系列复杂问题：
• 一个组织如何标识和管理程序（及其文档）的很多现
存版本，以使得变化可以高效地进行？
• 一个组织如何在软件被发布给客户之前和之后控制变
化？
• 谁负责批准变化，并给变化确定优先级？
• 我们如何保证变化已经被恰当地进行？
• 采用什么机制去告知其他人员已经实行的变化？
SCM Process
SCM tasks：
•
•
•
•
•
identification (标识)
version control (版本控制)
change control (变化控制)
configuration auditing (配置审计)
reporting (报告)
Identification of Objects in SCM
• 为了控制和管理软件配置项，每个配置项必须被
独立命名，然后用面向对象的方法组织。
• 有两种类型的对象可以被标识：基本对象和聚集
对象。
• 基本对象是软件工程师在分析、设计、编码或测
试中创建的“文本单元（unit of text）” ，例如，
一个基本对象可能是需求规约的一个段落、模块
的源程序清单或一组用于测试代码的测试用例。
• 一个聚集对象是基本对象和其他聚集对象的集合。
Identification of Objects in SCM
• 每个对象均具有一组唯一地标识它的、独特的特
征：名字、描述、资源表、以及“现实” 。
• 对象名是无二义性地标识对象的一个字符串；对
象描述是一个数据项的列表，它们标识：
该对象所表示的SCI类型（如，文档、程序、数据）；
项目标识符；以及变化和/或版本信息；
• 资源是由对象提供、处理、引用或需要的实体，
例如，数据类型、特定函数、或甚至变量名也可
以作为对象资源；
• 现实是一个指针，对基本对象而言指向“文本单
元” ，对聚集对象而言则指向null。
Identification of Objects in SCM
• 配置对象的标识也必须考虑存在于命名对象之
间的关系，一个对象可被标识为某聚集对象的
<part-of>，关系<part-of>定义了一个对象层次。
• 对于软件对象的标识模式必须认可对象在整个
软件过程中的演化，在一个对象被确定为基线
前，它可能会变化很多次，甚至在基线已经建
立后，变化也可能经常发生。有可能为任意对
象创建一个演化图，演化图描速了对象的变化
历史。
Identification of Objects in SCM
obj
1.0
obj
1.1
obj
1.3
obj
1.4
obj
2.0
obj
2.1
obj
1.2
obj
1.1.1
Obj
1.1.2
对象演化图
Version Control in SCM
• 版本控制结合了规程和工具以管理在软件工程
中所创建的配置对象的不同版本。
• SCM中的版本控制可以描述如下：配置管理使
得用户能够通过对适当版本的选择来指定可选
的软件系统的配置，这一点的实现是通过将属
性关联到每个软件版本上，然后通过描述一组
所期望的属性来指定（和构造）配置的。
Change Control in SCM
对于大型的软件开发项目，无控制的变化
将迅速导致混乱，SCM变化控制结合人的规程
和自动化工具以提供一个变化控制的机制。
Change Control in SCM
• 一个变化请求被提交和评估，以评价技术指标、潜在副作
用、对其他配置对象和系统功能的整体影响、以及对于变
化的成本预测。
• 评估的结果以变化报告的形式给出，该报告被变化控制审
核者（change control authority, CCA）----对变化的状态及优
先级作最终决策的人或小组----使用。对每个被批准的变化
生成一个过程变化命令（engineering change order, ECO），
ECO描述了将要进行的变化、必须注意的约束、以及复审
和审计的标准。
• 将被修改的对象从项目数据库“提取（check out）”出来，
进行修改，并应用于合适的SQA活动，然后，将对象“提
交（check in）”进数据库，并使用合适的版本控制机制去
建立软件的下一个版本。
Change Control in SCM
“提交”和“提取”过程实现了两个
主要的变化控制要素----访问控制和同步
控制：
• 访问控制管理哪个软件工程师有权限去访问和
修改某特定的配置对象。
• 同步控制帮助保证由两个不同人员完成的并行
修改不会互相覆盖。
Change Control in SCM
基于一个被批准的变化请求和ECO，
软件工程师提取出配置对象，访问控制
功能保证该软件工程师有权限提取该对
象，而同步控制对项目数据库中的该对
象加锁，使得当前提取出的版本在被放
回以前不能对它作任何其他修改。注意，
可以提取出其他的备份，但是，不能进
行其他修改。
Change Control in SCM
• 非正式变化控制：
在SCI变成基线以前，只需要进行非正式
的变化控制。配置对象（SCI）的开发者可以
进行任何被管理和技术需求证明是合适的修改
（只要修改不会影响到在开发者工作范围之外
的更广的系统需求），一旦对象已经经过正式
的技术复审并已被认可，则创建了一个基线。
Change Control in SCM
• 项目级变化控制：
一旦SCI变成基线，则项目级的变化控制
就开始实施了。这时，为了进行修改，开发者
必须获得项目管理者的批准（如果变化是“局
部的” ），或CCA的批准（如果该变化影响到
其他SCI）。在某些情况下，变化需求、变化
报告和ECO的正式生成可以省略，然而，需要
管理对每个变化的评价，并对所有变化进行跟
踪和复审。
Change Control in SCM
• 正式的变化控制：
当软件产品发布给客户时，正式的变化控
制就开始实施了
Change Control in SCM
•
•
•
•
变化控制审核者（CCA）在第二和第三层控制上扮
演了活跃的角色，依赖于软件项目的规模和性质 ，
CCA可能包含一个人----项目管理者----或一组人（如，
来自软件、硬件、数据库工程、支持、市场等五方面
的代表）。CCA的角色是从全局的观点来评估变化对
SCI之外的事务的影响：
变化将如何影响硬件？
变化将如何影响性能？
变化将如何改变客户对产品的感觉？
变化将如何影响产品的质量和可靠性？
这些和很多其他的问题需被CCA处理。
Configuration Audit in SCM
标识、版本控制和变化控制帮助软件开发者
维持秩序，否则情况可能将是混乱和不固定的。
然而，即使最成功的控制机制也只能在ECO产
生后才可以跟踪变化。我们如何帮助变化被合
适的实现呢？回答是两方面的：
（1）正式的技术复审；
（2）软件配置审计。
Configuration Audit in SCM
正式的技术复审关注已经被修改的配
置对象的技术正确性，复审者评估SCI以
确定它与其他SCI的一致性、遗漏、及潜
在的副作用，正式的复审应该对所有的
变化进行，除了那些最琐碎的变化之外。
Configuration Audit in SCM
软件配置审计通过评估配置对象的通常不在复审中考虑的特
征，而形成正式复审的补充。审计询问并回答如下问题：
•
•
•
•
•
•
在ECO中说明的变化已经完成了吗？加入了任意附加的修改吗？
是否已经进行了正式的技术复审，以评估技术的正确性？
是否适当地遵循了软件工程标准？
变化在SCI中被“显著地强调（highlighted）”了吗？是否指出了变化的
日期和变化的作者？配置对象的属性反应了变化吗？
是否遵循了标注变化、记录变化并报告变化的SCM规程？
所有相关的SCI被适当修改了吗？
在某些情况下，审计问题被作为正式的技术复审的一部分而
询问，然而，当SCM是一个正式的活动时，SCM审计由质量保证
组单独进行。
Status Reporting in SCM
配置状态报告（Configuration status
reporting, 有时称为status accounting）是
一个SCM任务，它回答下列问题：
•
•
•
•
发生了什么事？
谁做的此事？
此事是什么时候发生的？
将影响别的什么吗？
Status Reporting in SCM
配置状态报告(CSR)的信息流如下：
• 每次当一个SCI被赋上新的和修改后的标识时，则一个
CSR条目被创建；
• 每次当一个变化被CCA批准时（即，一个ECO产生），
一个CSR条目被创建；
• 每次当配置审计进行时，其结果作为CSR任务的一部
分被报告。
• CSR的输出可以放置到一个联机数据库中，使得软件
开发者或维护者可以通过关键词分类访问变化信息。
此外，CSR报告被定期生成，并允许管理者和开发者
评估重要的变化。
Status Reporting in SCM
配置状况报告在大型软件开发项目的成功中
扮演了重要角色，当涉及到很多人员时，有可
能会发生“左手不知道右手在做什么”的综合
症：
• 两个开发者可能试图以不同的或冲突的意图去修改同
一个SCI；
• 软件工程队伍可能花费几个月的工作量针对过时的硬
件规约建造软件；
• 能认识到被建议的修改有严重副作用的人并不知道该
修改已经进行。
CSR通过改善所有相关人员之间的通信，帮
SCM Standards
在过去20年中，已经提出了一系列的软件
配置管理标准。很多早期的SCM标准，如MILSTD-483、DOD-STD-480A、和MIL-STD—
1521A，主要用于为军事用途而开发的软件。
然而，最近的ANSI/IEEE标准，如ANSI/IEEE
Std. No. 828-1983，No. 1042-1987，和Std.
No.1028-1988，可应用于商业软件，并被向大
型的和小型的软件工程组织推荐。
Software Project Management Concepts
软件项目管理是软件工程的保护性
活动，它先于任何技术活动之前开始，
并且持续贯穿于整个计算机软件的定义、
开发和维护之中。
The Management Spectrum
有效的项目管理集中于三个P上：
• 人员（people）
• 问题（problem）
• 过程（process）
其顺序不是任意的。任何管理者如果忘记了软件工
程是人的智力密集的劳动，他就永远不可能在项目管
理上取得成功；任何管理者如果在项目开发早期没有
支持有效的用户通信，他有可能为错误的问题构造一
个不错的解决方案。最后，对过程不在意的管理者可
能冒把有效的技术和工具插入到真空中的危险。
The People (项目管理的人员)
• Players (项目参与者)
• Team leaders (项目负责人)
• Software team (软件项目组)
The Players (项目参与者)
• 高级管理者：负责确定商业问题，这些问题往
往对项目产生很大影响。
• 项目（技术）管理者：必须计划、激励、组织
和控制软件开发人员。
• 开发人员：负责开发一个产品或应用软件所需
的专门技术人员。
• 客户：负责说明待开发软件的需求的人员。
• 最终用户：一旦软件发布成为产品，最终用户
是直接与软件进行交互的人。
Team Leaders (项目负责人)
• 解决问题：一个有效的软件项目负责人应该能
够准确地诊断出技术的和管理的问题；系统地
计划解决方案；适当地激励其他开发人员实现
解决方案；把从以前的项目中学到的经验应用
到新的环境下；如果最初的解决方案没有结果，
能够灵活地改变方向。
• 管理能力：一个好的项目负责人必须掌管整个
项目，他在必要时必须有信心进行控制，必须
保证让优秀的技术人员能够按照他们的本性行
事。
Team Leaders
• 激励能力：为了提高项目组的生产率，项目负
责人必须奖励具有主动性和作出成绩的人。并
通过自己的行为表明约束下的冒险不会受到惩
罚。
• 理解和控制能力：一个有效的项目负责人必须
能够“读懂”人；他必须能够理解语言的和非
语言的信号，并对发出这些信号的人的要求做
出反应。项目负责人必须在高压力环境下保持
良好的控制能力。
The Software Team (软件项目组)
项目分配人力资源的若干可选方案，设该项目
需要n个人工作k年：
• n个人被分配来完成m个不同的功能任务，相对而言几
乎没有合作的情况发生；协调是软件管理者的责任，
而他可能同时还有六个其他项目要管。
• n个人被分配来完成m个不同的功能任务（m<n），建
立非正式的小组；指定一个专门的小组负责人；小组
之间的协调由软件管理者负责。
• n个人被分成t个小组；每一个小组完成一个或多个功
能任务；每一个小组有一个特定的结构，该结构是为
同一个项目的所有小组定义的；协调工作由小组和软
件项目管理者共同控制。
The Software Team
软件工程小组的组织方式：
• 民主分权式（Democratic Decentralized, DD）：这种软件工程小组
没有固定的负责人。任务协调者是短期指定的，之后就由其他协
调不同任务的人取代。问题和解决方法的确定是由小组讨论决策
的。
• 控制分权式（Controlled Decentralized, CD）：这种软件工程小组
有一个固定的负责人，他协调特定的任务及负责子任务的二级负
责人关系。问题解决仍是一个群体活动，但解决方案的实现是有
小组负责人在子组之间进行划分的。子组和个人间的通信是平行
的，但也会发生沿着控制层产生的上下级的通信。
• 控制集权式（Controlled Centralized, CC）：顶层的问题解决和内
部小组协调是由小组负责人管理的。负责人和小组成员之间的通
信是上下级式的。
The Software Team
计划软件工程小组结构时应该考虑的因素：
• 待解决问题的困难程度；
• 要生成的程序的规模，以代码行或功能点来衡
量；
• 小组成员需要待在一起的时间（小组生命期）；
• 问题能够被模块化的程度；
• 待开发系统所要求的质量和可靠性；
• 交付日期的严格程度；
• 项目所需要的社交性（通信）的程度。
The Software Team
• 因为集中式的结构能够更快地完成任务，因此
最适合处理简单问题。而分散式的小组比起个
人而言能够产生更多更好的解决方案，因此这
种小组在处理复杂问题时成功的可能性更大。
因为CD小组是集中式地解决问题，所以CD或
CC小组结构能够成功地用来解决简单的问题。
而DD结构则适合于解决难度较大的问题。
• 因为小组的性能与必须进行的通信量成反比，
所以如果子组很容易协调的话，很大的项目最
好采用CC或CD结构的小组组织方式。
The Software Team
• 因为小组的性能与必须进行的通信量成反比，所以如
果子组很容易协调的话，很大的项目最好采用CC或CD
结构的小组组织方式。
• DD小组结构最适合于解决模块化程度较低的问题，因
为它需要更多的通信。如果有可能要较高的模块化程
度，则CC或CD结构更加合适。
• CC和CD小组已被发现能够产生比DD小组更少的缺陷，
但这与小组所采用的质量保证活动密切相关。分散式
结构通常需要比集中式结构更多的时间来完成一个项
目，但是如果要求高社交性，它是最合适的。
The Software Team
软件工程小组的组织范型：
• 封闭式范型：按照传统的权利层次来组织小组
（类似CC小组）。这种小组在开发与过去已经
做过的产品类似的软件时十分有效，但这种封
闭式范型下难以进行创新式的工作。
• 随机式范型：松散地组织小组，并依赖于小组
成员个人的主动性。当需要创新或技术上的突
破时，按照这种随机式范型组织的小组很有优
势。但当需要“有次序的执行”才能完成工作
时，这种小组组织范型就会陷入困境。
The Software Team
软件工程小组的组织范型：
• 开放式范型：试图以一种既具有封闭式范型的
控制性、又包含随机式范型的创新性的方式来
组织小组。工作的执行结合了大量的通信和基
于小组一致意见的决策。开放式范型小组结构
特别适合于解决复杂问题，但可能不象其他类
型小组那么效率高。
• 同步式范型：依赖于问题的自然划分，组织小
组成员各自解决问题的片段，他们之间没有什
么主动的通信需求。
Coordination and Communication Issues
(协调和通信问题)
• 有很多原因会使软件项目陷入困境。许多开发项目规
模宏大，以至于使小组成员间的关系复杂性高混乱、
难以协调。不确定性是经常存在的，它会引起困扰项
目组的一连串的改变。
• 软件工程小组必须建立有效的方法，以协调参与工作
的人员之间的关系。要完成这项任务，必须建立小组
成员之间及多个小组之间的正式的和非正式的通信机
制。
• 正式的通信是通过文字、会议及其他相对而言非交互
和非个人的通信渠道来实现。非正式的通信则更加个
人化。软件工程小组的成员在一个特别的基础上共享
想法，出现问题时相互帮助，且每天相互交流。
Project Coordination Techniques
• 正式的、非个人的方法：包括软件工程文档和交付物（如
源程序）、技术备忘录、项目里程碑、进度和项目控制工
具、修改请求及相关文档、错误跟踪报告、中心库数据。
• 正式的、个人间的规程：集中表现于软件工程工作中产品
的质量保证活动中，包括状态复审会议及设计和代码检查。
• 非正式的、个人间的规程：包括信息传播、问题解决的小
组会议。
• 电子通信：包括电子邮件、电子公告栏、Web站点以及基于
视频的会议系统。
• 个人间的网络：与项目组之外的人进行的非正式的讨论，
这些人可能有足够的经验或见解，能够帮助项目组成员。
The Problem (项目管理的问题)
软件项目管理者从软件项目一开始就面临
着进退两难的局面。需要定量的估算成本和有
组织的计划项目的进展，但却没有可靠的信息
可以使用。对软件需求的详细分析可以提供必
要的估算信息，但分析常常要花数周甚至数月
的时间才能完成。更糟糕的是，随着项目的进
展经常发生改变，需求可能是不固定的。
Software Scope
软件项目管理的第一个活动是软件范围的确
定。范围是通过回答下列问题来定义的：
• 背景：待开发的软件如何适应大型的系统、产品或商
业的背景，在该背景下要加什么约束？
• 信息目标：软件要产生什么样的客户可见的数据对象
来作为输出使用？需要什么样的数据对象作为输入？
• 功能和性能：软件要执行什么样的功能使得输入数据
才能变换为输出数据？需要满足什么特殊的性能特征
吗？
Software Scope
软件项目范围在管理层和技术层都
必须是无二义性的和可理解的。对软件
范围的描述必须是确定的。即，
• 明确给出定量的数据（如并发用户数目、邮件
列表的大小、允许的最大响应时间）；
• 说明约束和/或限制（如产品成本、内存大小）；
• 描述其他的特殊因素（如要用的算法能够很好
地理解，并写成C++程序）。
Problem Decomposition
• 问题分解，有时称为划分，是一个软件需求分析的核
心活动。在确定软件范围的活动中并没有完全分解问
题。分解一般用于两个主要领域：
（1）必须交付的功能；（2）交付所用的过程。
• 面对复杂的问题人们常常采用分而治之的策略。简单
讲，就是将一个复杂的问题划分成若干较易处理的小
问题。这是项目计划开始时所采用的策略。在估算开
始之前，范围中所描述的软件功能必须被评估和精化，
以提供更多的细节。因为成本和进度估算都是面向功
能的，所以某种程度的分解是很有用的。
The Process (项目管理的过程)
• 软件过程的一般阶段（定义、开发和维护）适
用于所有软件项目。问题在于如何选择一个合
适项目组要开发的软件过程模型。
• 项目管理者必须决定哪一个过程模型最适合待
开发项目，然后基于公共过程框架活动集合，
定义一个初步的计划，便可以开始进行过程分
解，即建立一个完整的计划，以反映框架活动
中所需要的工作任务。
Melding the Problem and the Process
(合并问题和过程)
项目计划开始于问题和过程的合并。
软件项目组要开发的每一个功能都必须
通过为软件组织定义的框架活动集合来
完成。
Project
疲惫不堪的产业专家们在讨论特别
困难的软件项目时，常常提及90-90规则：
• 一个系统的第一个90%花费了所分配工作量和
时间的90%，系统最后10%也会花费所分配工
作量和时间的90%。
Project
• 评估进度所采用的方法是有缺陷的（很显然，如果9090规则是真的，90%的完成度就不是一个准确的指
标）。
• 没有办法测定进度，因为没有可用的、量化的度量。
• 项目计划没有考虑协调所需要的资源。
• 没有明确地考虑风险，没有建立缓解、监控和管理风
险的计划。
• 进度计划是不现实或有缺陷的。
为了克服这些问题，在项目开始时必须花时
间建立一个现实的计划，在项目进行中监控该
计划，并在项目整个过程中控制质量和变化。
软件项目估算
• 软件项目管理过程从一组称为项目计划的活动
开始，这些活动中的第一个就是估算。
• 无论何时进行估算，我们都是在预测未来，并
会接受某种程度的不确定性。
• 虽然估算是一门科学，但它更是一门艺术，但
这个重要的活动不能以随意的方式进行，因为
估算是所有其他项目计划活动的基础。
软件项目估算
项目管理者应该具备的素质：
• 具有在错误真正发生之前就知道它的能力。
• 在未来还是一团迷雾的时候就有勇气进行估算。
软件项目估算
估算一个软件开发工作的资源、成本和进
度需要：
• 经验
• 了解以前的有用信息
• 当仅存在定性的数据时进行定量测量的勇气
估算具有与生俱来的风险，而正是这种风险导
致了不确定性。
软件项目估算
影响估算的因素：
• 项目复杂性对计划中固有的不确定性产生重大影响，
复杂性是一个受到对以前工作的熟悉程度影响的相对
的测量。
• 项目规模影响估算准确性，随着规模的增长，软件中
各个元素之间的相互依赖性也迅速增加。项目规模的
增长会对项目成本和进度产生几何级数的影响。
• 结构不确定性的程度也会对估算的风险产生影响。这
里结构是指：需求能被确定的程度，功能能被分解的
容易程度，以及需要加工的信息的层次性。
软件项目估算
影响估算的因素：
• 历史信息的可用程度也决定了估算的风险。当存在大
量可用的关于过去项目的软件度量时，估算就会有更
大的保证。
• 风险是由为资源、成本及进度建立的定性估算中存在
的不确定性来测量的。如果对项目范围理解很差或需
求不断变化，不确定性及风险就会很高。
• 应该满足于事物的本性所能容许的精确度，当只能近
似于真理时，不要去寻求绝对的准确。
软件项目估算
• 软件项目计划的目标是提供一个框架，使得管理
者能够对资源、成本及进度进行合理的估算。
• 估算是在软件项目开始时在一个限定的时间框架
内所做的，并且随着项目的进展不断更新。
• 估算应该定义“最好的情况”和“最坏的情况”，
使得项目的结果能够限制在一定范围内。
软件项目估算
• 软件成本及工作量估算永远不会是一门精确的
科学。
• 太多的变化--人员、技术、环境、策略影响了
软件的最终成本及开发所需的工作量。
软件项目估算途径
• 将估算拖延到项目的最后阶段（显然，如果在
项目完成之后进行估算，能够赢得100%的准确
率）。
• 基于已经完成的类似的项目进行估算。
• 使用简单的“分解技术”进行项目成本和工作
量估算。
• 使用一个或多个经验模型进行软件成本和工作
量的估算。
软件项目估算途径
• 分解技术采用“分而治之”的策略进行软件项目估算。将
项目分解成若干主要的功能及相关的软件工程活动，通过
逐步求精的方式进行成本及工作量估算。
• 经验估算模型可用于补充分解技术，并提供一种潜在有价
值的估算方法。该模型是基于经验（历史数据）来进行的，
可以用以下公式表示：
d=f(v)
其中d是要估算的值（如工作量、成本、项目持续时间），
v是选择出来的独立参数（如被估算的代码行或功能点）。
• 软件的估算参量取决于用于估算的历史数据。若没有历史
数据存在，成本估算也就建立在一个很不稳定的基础之上。
风险管理
• 风险关注未来将要发生的事情。
• 风险涉及改变（如思想、观念、行为或
地点的改变）。
• 风险涉及选择及选择本身所包含的不确
定性。
风险管理
• 当没有办法消除风险，甚至连试图降低
该风险也存在疑问时，这些风险就是真
正的风险了。
• 在能够标识出软件项目中的“真正风险”
之前，识别出所有对管理者及开发者而
言均为明显的风险是很重要的。
被动和主动的风险策略
• 被动策略：风险变成现实后才处理，
“救火模式”。
• 主动策略：预防为主。标识出潜在风险，
评估它们出现的概率和产生的影响，且
按重要性加以排序。然后，软件项目组
建立一个计划来管理风险。
软件风险
• 不确定性：刻划风险的事件可能发生也不可能
发生。
• 损失：如果风险变成了现实，就会产生恶性后
果或损失。
• 进行风险分析时，重要的是量化不确定性的程
度及与每个风险相关的损失的程度。
软件风险
• 项目风险
潜在的预算、进度、人力、资源、客户及需求等方面
的问题以及它们对软件项目的影响。
• 技术风险
潜在的设计、实现、接口、验证和维护等方面的问题，
威胁待开发软件的质量和交付时间。
软件风险
商业风险（威胁待开发软件的生存能力）：
• 开发了一个没有人真正需要的优秀产品或系统（市场
风险）。
• 开发的产品不再符合公司的整体商业策略（策略风
险）。
• 建造了一个销售部门不知道如何去卖的产品。
• 由于重点的转移或人员的变动而失去了高级管理层的
支持（管理风险）。
• 没有得到预算或人力上的保证（预算风险）。
软件风险
• 可预测风险
能够从过去项目的经验中推断出来。
• 不可预测风险
它们可能、也会真的出现，但很难实现识别。
软件风险
• 一般性风险
对每一个软件项目而言都是一个潜在的威胁。
• 特定产品的风险
只有那些对当前项目的技术、人员及环境非常了解的
人才能识别出来。
识别风险
• 试图系统化地确定风险对项目计划（估
算、进度、资源分配）的威胁，在可能
时避免风险，在必要时控制风险。
识别风险
识别下列常见子类型中的已知的及可预测的风险：
• 产品规模：与要建造或要修改的软件的总体规模相关的风险。
• 商业影响：与管理或市场所加诸的约束相关的风险。
• 客户特性：与客户的素质以及开发者和客户定期通信的能力相关
的风险。
• 过程定义：与软件过程被定义的程度以及它们被开发组织所遵守
的程度相关的风险。
• 开发环境：与用以建造产品的工具的可用性及质量相关的风险。
• 建造的技术：与待开发软件的复杂性及系统所包含技术的“新奇
性”相关的风险。
• 人员数目及经验：与参与工作的软件工程师的总体技术水平及项
目经验相关的风险。
产品规模风险
项目风险直接与产品规模成正比。
•
•
•
•
•
•
•
•
以何种方法估算产品的规模？
对于估算出的产品规模的信任程度如何？
是否以程序、文件或事务处理的数目来估算产品规模？
产品规模与以前产品规模的平均值的偏差百分比是多少？
产品创建或使用的数据库大小如何？
产品的用户数有多少？
产品的需求改变多少？交付之前有多少？交付之后有多少？
复用的软件有多少？
在每一种情况下，待开发产品的信息必须与过去的经
验加以比较。若出现了较大的百分比偏差，或如果数
字相近但过去的结果很不令人满意，则风险较高。
商业影响风险
销售部门是受商业驱动的，而商业考虑有时会直接与
技术现实发生冲突。
•
•
•
•
•
•
•
•
•
•
本产品对公司的收入有何影响？
本产品是否得到公司高级管理层的重视？
交付期限的合理性如何？
将会使用本产品的用户数及本产品是否与用户的需要相符合？
本产品必须能与之互操作的其它产品/系统的数目？
最终用户的水平如何？
必须产生并交互给用户的产品的量与质如何？
政府对本产品开发的约束？
延迟交付所造成的成本消耗是多少？
产品缺陷所造成的成本消耗是多少？
客户相关的风险
并非所有客户都是一样的。
• 客户有不同的需要
• 客户有不同的个性
• 客户与他们的供应商之间也有各种不同的通信
方式。
• 客户常常是矛盾的
客户相关的风险
•
•
•
•
•
•
•
你以前是否曾与这个客户合作过？
该客户是否很清楚需要什么？他能否花时间把需求写出来？
该客户是否同意花时间召开正式的需求收集会议以确定项目范围？
该客户是否愿意建立与开发者之间的快速通信渠道？
该客户是否愿意参加复审工作？
该客户是否具有该产品领域的技术素养？
该客户是否愿意让你的人来做他们的工作（当你的人在做具体的
技术工作时，该客户是否会坚持在旁边监视）？
• 该客户是否了解软件过程？
如果对于以上任何一个问题的答案是否定的，则需要
进行进一步的调研，以评估潜在的风险。
过程风险
• 如果软件过程定义得不清楚；如果分析、
设计、测试以无序的方式进行；如果质
量是每个人都认为是很重要的概念，但
没有人切实地采取行动来保证它，那么，
这个项目就处于风险之中。
• 过程风险
过程问题
技术问题
过程风险
过程问题
• 你的高级管理层是否 支持一份已经写好的政策综述，该综述中强
调了软件开发标准过程的重要性吗？
• 你的组织是否已经建立了一份已经成文的、用于本项目的软件过
程的说明？
• 开发人员是否“签约”同意按照文档所写的软件过程进行开发工
作，并自愿使用它？
• 该软件过程是否可用于其他项目？
• 你的组织是否已经为管理及技术人员开设了一系列的软件工程培
训课程？
• 是否为每一个软件开发者和管理者都提供了印好的软件工程标准？
• 是否为作为软件过程一部分而定义的所有交付物建立了文档概要
及示例？
过程风险
过程问题
• 是否定期对需求规约、设计和编码进行正式的技术复审？
• 是否定期对测试过程和测试情况进行复审？
• 是否对每一次正式技术复审的结果要建立文档，其中包括发现 的
错误及使用的资源？
• 是否有什么机制来保证软件工程标准的方案指导的工作开展正常？
• 是否使用配置管理来维护系统/软件需求、设计、编码及测试用例
之间的一致性？
• 是否使用一个机制来控制用户需求的变化及其对软件的影响？
• 对于每一个承包出去的子合同，是否有一份文档化的工作说明、
一份软件需求规约及一份软件开发计划？
• 是否有一个可遵循的规程来跟踪及复审子合同承包商的工作？
过程风险
技术问题
• 是否使用方便易用的规格说明技术来辅助客户与开发者之间的通
信？
• 是否使用特定的方法进行软件分析？
• 是否使用特定的方法进行数据和体系结构的设计？
• 是否90%以上的代码都是采用高级语言编写的？
• 是否定义及使用特定的规则进行代码编写？
• 是否使用特定的方法进行测试用例设计？
• 是否使用软件工具来支持计划和跟踪活动？
• 是否使用配置管理软件工具来控制和跟踪软件过程中的变化活动？
• 是否使用软件工具来支持软件分析和设计过程？
过程风险
技术问题
• 是否使用工具来创建软件原型？
• 是否使用软件工具来支持测试过程？
• 是否使用软件工具来支持文档的生成和管理？
• 是否收集所有软件项目的质量度量值？
• 是否收集所有软件项目的生产率度量值？
如果对于上述问题中大多数的答案是否定的，则
软件过程是薄弱的，且风险很高。
技术风险
• 该技术对于你的组织而言是新的吗？
• 客户的需求是否需要创建新的的算法或输入、输
出技术？
• 软件是否需要使用新的或未经证实的硬件接口？
• 待开发软件是否需要与开发商提供的未经证实的
软件产品接口？
• 待开发软件是否需要与其功能及性能均未在本领
域中得到证实的数据库系统接口？
• 产品的需求中是否要求采用特定的用户界面？
技术风险
• 产品的需求中是否要求开发某些程序构件，这些构件
与你的组织以前所开发的构件完全不同？
• 需求中是否要求使用新的分析、设计、或测试方法？
• 需求中是否要求使用非传统的软件开发方法，如形式
化方法，基于AI的方法、以及人工神经网络？
• 需求中是否有过分的对产品的性能约束？
• 客户能确定所要求的功能是“可行的”吗？
如果对于这些问题中任何一个的答案是肯定的，
则需要进一步的调研，来评估潜在的风险。
开发环境风险
•
•
•
•
是否有可用的软件项目管理工具？
是否有可用的软件过程管理工具？
是否有可用的分析和设计工具？
分析和设计工具是否支持适用于待开发产品的方
法？
• 是否有可用的编译器或代码生成器，且适用于待
建造产品？
• 是否有可用的测试工具，且适用于待建造产品？
开发环境风险
•
•
•
•
•
•
是否有可用的软件配置管理工具？
环境是否利用了数据库或仓库？
是否所用软件工具都是彼此集成的？
项目组的成员是否已经接受过关于每个工具的培训？
是否相关的专家能够回答关于工具的问题？
工具的联机帮助及文档是否适当？
如果对于上述问题中大多数的答案是否定的，
则软件过程是薄弱的，且风险很高。
与人员数目相关的风险
•
•
•
•
•
•
•
•
是否有最优秀的人员可用？
人员在技术上是否配套？
是否有足够的人员可用？
开发人员是否能够自始自终地参加整个项目的工作？
项目中是否有一些人员只能部分时间工作？
开发人员对自己的工作是否有正确的期望？
开发人员是否接受过必要的培训？
开发人员的流动是否仍能保证工作的连续性？
如果对于这些问题中任何一个的答案是肯定的，
则需要进一步的调研，来评估潜在的风险。
风险因素
• 性能风险
产品能够满足需求且符合于其使用目的的不确定的程
度。
• 成本风险
项目预算能够被维持的不确定的程度。
• 支持风险
软件易于纠错、适应及增强的不确定的程度。
• 进度风险
项目进度能够被维持且产品能按时交付的不确定的程
度。
风险预测
风险预测试图从两方面评估每一个风险：
• 风险发生的可能性或概率；
• 如果风险发生了，所产生的后果。
风险预测活动：
•
•
•
•
建立一个尺度，以反映风险发生的可能性；
描述风险的后果；
估算风险对项目及产品的影响；
标注风险预测的整体精度，以免产生误解。
建立风险表
风险
规模估算可能非常低
用户数量大大超出计划
复用程度低于计划
最终用户抵制该系统
交付期限将被紧缩
资金将会流失
用户将改变需求
技术达不到预期的效果
缺少对工具的培训
人员缺少经验
人员流动比较频繁
……
类别
概率
影响
PS
PS
PS
BU
BU
CU
PS
TE
DE
ST
ST
60%
30%
70%
40%
50%
40%
80%
30%
80%
30%
60%
严重的
轻微的
严重的
轻微的
严重的
灾难的
严重的
灾难的
轻微的
严重的
严重的
可忽略的
RMMM
建立风险表
• 根据概率及影响对风险进行排序。高发生概率、高影
响的风险放在表的上方，低概率、低影响风险移到表
的下方。
• 在风险表上定义一条中止线：只有那些在线上的风险
才会得到进一步的关注，而在线下的风险则需要再评
估以完成第二次排序。
• 从管理的角度考虑风险影响及概率：一个具有高影响
但发生概率很低的风险因素不应该花太多的管理时间；
而高影响且发生概率为中到高的风险，以及低影响且
高概率的风险，应该首先列入管理考虑之中。
• 所有中止线之上的风险都必须进行管理。风险表中标
有RMMM的列指向相应的风险缓解、监控和管理计划。
评估风险影响
确定风险整体影响的步骤：
• 确定每个风险元素发生的概率；
• 确定每个风险元素的影响；
• 完成风险表，并分析其结果。
风险评估
在风险评估过程中，进一步审查在
风险预测阶段所做的估算的精确度，为
所发现的风险排除优先次序，并开始考
虑如何控制和/或避免可能发生的风险。
风险评估
风险评估的依据是如下形式的三元组：
[ r, l, x ]
其中r表示风险，l表示风险发生的概率，x表示
风险产生的影响。
风险评估
进行风险评估必须定义一个风险参考水平值：
• 对于大多数软件项目而言，主要风险因素（性能、成
本、支持、进度）也代表了风险参考水平值。即，对
于性能下降、成本超支、支持困难、进度延迟（或这
四种的组合），都有一个参考水平值的要求，超过参
考水平值就会导致项目被迫终止。如果风险的组合所
产生的问题引起一个或多个参考水平值被超过，则工
作将会停止。
风险评估
临界点（成本，时间）
进
度
延
迟
终止项目
成本超支
风险评估
风险评估过程：
• 定义项目的风险参考水平值。
• 建立每一组[r,l,x]与每一个参考水平值之间的关
系。
• 预测一组临界点以定义项目终止区域。
• 预测什么样的风险组合会影响参考水平值。
风险缓解、监控和管理
处理风险的策略：
• 风险避免
• 风险监控
• 风险管理及意外事件计划
风险缓解、监控和管理
实例（三元组）
• 项目风险：频繁的人员流动
• 概率：70%
• 影响：对项目成本和进度有严重的影响
风险缓解、监控和管理
实例（风险缓解策略）
• 与现有人员一起探讨人员流动的原因（如，恶劣的工作条件，低
报酬，竞争激烈的劳动力市场）。
• 在项目开始之前，采取行动以缓解那些在管理控制之下的原因。
• 一旦项目启动，假设会发生人员流动，采取一些技术一保证但人
员离开时的连续性。
• 对项目组进行良好组织，使得每一个开发活动的信息能被广泛传
播和交流。
• 定义文档的标准，并建立相应的机制以确保文档能被及时建立。
• 对所有工作进行详细复审，使得不止一个人熟悉该项工作。
• 对每一个关键的技术人员都指定一个后备人员。
风险缓解、监控和管理
实例（风险监控活动，应该监控下列因素）
•
•
•
•
•
•
项目组成员对项目压力的一般态度。
项目组的凝聚力。
项目组成员彼此之间的关系。
与报酬和利益相关的潜在问题。
在公司内及公司外工作的可能性。
相应风险缓解步骤（策略）的效力。
风险缓解、监控和管理
实例（风险管理及意外事件计划，假设缓解工
作失败，风险变成了现实）
• 使用后备人员。
• 调整项目进度，使得新加入人员能够“赶上”。
• 要求那些要离开的人员停止工作，并在最后几个星期
进入“知识交接模式”。
风险缓解、监控和管理
值得注意的是，风险缓解、监控和管理计
划将导致额外的项目开销（例如，花费时间去
“备份”每一个关键的技术人员是需要花钱
的）。因此，风险管理的部分任务是评估是否
以及何时风险缓解、监控和管理计划所产生的
效益低于它们所花费的成本。
风险缓解、监控和管理
• 对于一个大型项目，可能标出30或40种风险。
如果为每种风险定义3至7个风险管理步骤，则
风险管理本身就可能变成一个“项目”！
• Pareto的80-20规则：整个软件项目风险的80%
（即，可能导致失败的80%的潜在因素）能够
由仅仅20%的已标出风险来说明。
RMMM计划
• 风险管理策略可以包含在软件项目计划中，也可以组
织成一个独立的风险缓解、监控和管理计划（RMMM
计划）。
• 一旦建立了RMMM计划，且项目开始启动，则风险缓
解及监控步骤随即开始。
• 风险缓解是一种问题避免活动，风险监控是一种项目
跟踪活动。
RMMM计划
风险监控的主要目的：
•
•
•
•
评估一个被预测的风险是否真正发生了；
保证为风险而定义的缓解步骤被正确地实施；
收集能够用于未来风险分析的信息；
在很多情况下，项目中发生的问题可以追溯的不止一
个风险，风险监控应该试图在整个项目中确定“起源”
（什么风险引起了什么问题）。
RMMM计划
1. 引言
（1）文档的范围和目的
（2）主要风险综述
（3）责任
管理者
技术人员
2. 项目风险表
（1）中止线上的所有风险的描述
（2）风险元素的概率及影响
RMMM计划
3. 风险缓解、监控和管理
对每一个风险元素：
（1）缓解
一般策略
缓解风险的特定步骤
（2）监控
被监控的因素
监控方法
（3）管理
意外事件计划
特殊的考虑
4. RMMM计划的时间安排
5. 总结
项目延迟交付的原因
• 一个不现实的截止期限，有软件工程组以外的人所设
立并强加给软件工程组内的管理者和项目开发者。
• 对工作量和/或完成该工作所需的资源的数量估计不足。
• 在项目开始时，没有将可以预测的和/或不可预测的风
险考虑在内。
• 事先无法预计的技术困难。
• 事先无法预计的人力困难。
• 由于项目组成员之间的交流不畅而导致的延期。
• 项目管理者未能发现进度拖后，也未能采取行动解决
这一问题。
预测项目延迟后的处理
• 如果最乐观的估算都表明截止期限是不现实的，
一个胜任的管理者就应该保护其队伍免受不适
当的进度安排的压力并将这种压力给施加压力
的一方。
• 实例：
一个软件开发小组的任务是构造一个医疗诊断仪器的
实时控制器，该控制器需要在9个月之内推向市场。在
进行了仔细的估算和风险分析之后，软件项目管理者
得到的结论是在现有人员条件下，需要14个月的时间
才能完成这个项目。怎么办？
预测项目延迟后的处理
推荐处理步骤：
• 使用从以前的项目中得到的数据，进行详细的估算，确定
项目的估算工作量和持续时间。
• 使用增量过程模型，制定一个软件开发策略，以能够在规
定的交付日期提供关键功能，而将其他功能的实现推到以
后，并将这一计划做成文档。
• 与客户会谈并（用详细的估算结果）解释为什么规定的交
付日期是不现实的，一定要指出所有这些估算都是基于以
往的项目实践，而且一定要指出为了在目前规定的交付期
限完成项目，与以往相比在工作效率上必须提高的百分比。
• 将增量开发策略作为可选计划提交给客户。
项目进度安排的基本原则
• 划分：项目必须被划分成若干可以管理的活动和任务。
为了实现项目的划分，对产品和过程都需要进行分解。
• 相互依赖性：各个被划分的活动或任务之间的相互关
系必须是确定的。项目有些任务必须顺序发生；而其
他的则可以并发进行。有些活动只有在其他活动产生
的工作产品完成时才能够开始，而其他的则可以独立
进行。
• 时间分配：必须为每个被调度的任务分配一定数量的
工作单位。此外，必须为每个任务指定开始和结束日
期，这些日期是与工作完成的方式相互依赖的，是工
作方式的函数。
项目进度安排的基本原则
• 工作量确认：每个项目都有预定数量的人员参与。在
进行时间分配时，项目管理者必须确保在任意时段中
分配给任务的人员数量不会超过项目组人员的数量。
• 定义责任：每个被调度的任务都应该指定某个特定的
小组成员来负责。
• 定义结果：每个被调度的任务都应该有一个定义好的
结果。
• 定义里程碑：每个任务或任务组都应该与一个项目里
程碑相关联。当一个或多个工作产品经过质量复审并
且得到认可时，标志着一个里程碑的完成。
项目工作量分布
• “40-20-40”规则：40%或更多的工作量分配给前端的分
析和设计任务；类似比例的工作量用于后端测试。
• 项目计划的工作量很少超过2%到3%，除非提交给组织
的项目计划费用极大，而且具有高风险。
• 需求分析大约占用10%到25%的工作量，用于分析或原
型开发的工作量应该与项目规模和复杂度成正比的增
长。
• 通常有20%到25%的工作量用于软件设计。
• 编码工作一般占用15%到20%的工作量。
• 测试和调试工作将占用30%到40%的软件开发工作量。
项目跟踪的方式
• 定期举行项目状态会议，有项目组的各个成员
分别报告进度和问题。
• 评估所有在软件工程过程中所进行的复审的结
果。
• 确定正式的项目里程碑是否在预定日期内完成。
• 比较各项任务的实际开始日期与计划开始日期。
• 与开发者进行非正式会谈，获取他们对项目进
展及可能出现的问题的客观评估。
Summary
任何工程方法（包括软件工程）必
须以有组织的质量保证为基础。全面的
质量管理和类似的理念刺激了不断的过
程改进，正是这种改进导致了更加成熟
的软件工程方法的不断出现。支持软件
工程的根基就在于对质量的关注。