第11章软件项目管理软件项目管理概述软件项目规模度量软件项目估算项目进度管理项目风险管理软件配置管理项目人员组织管理软件
能力成熟度模型11.1软件项目管理概述软件项目管理的特点软件项目有它自身的特点，它是针对人的知识、智力开发活动而进行的管理。在
整个软件开发活动进程中，需要对思想、架构、概念、算法、流程、逻辑、效率和优化等各项抽象因素进行综合管理，因而使得软件管理的过程更为
复杂和难以控制。软件项目管理的特点体现在：⑴软件项目的产品是抽象的逻辑产品，难以用尺寸、重量、体积、外观等物理实体标准来
衡量和评价，难以制定软件产品的质量评价体系。⑵软件产品的生产过程是人的智力活动过程，而非传统意义上的“制造”过程，难以监管并及
时纠正生产过程中出现的错误和问题。⑶软件产品开发过程中涉及软件分析师、设计工程师、程序员、测试人员、用户和管理人员等，人员配备
复杂，难以进行有效管理。11.1软件项目管理概述软件项目管理的特点⑷软件产品虽然分通用软件和领域软件，但其都是“定制”的定向
系统，目前仍无法摆脱手工开发模式。“没有完全一样的软件项目”，这不仅对项目实施过程难以控制，而且还需要根据具体应用领域、环境等制定
特殊管理过程和内容。⑸源于应用领域的复杂性和软件开发技术的复杂性，软件自身是一个复杂系统。因而软件管理要对复杂软件系统过程做到
未雨绸缪，对软件开发内容抽丝剥茧般的细致。⑹软件项目管理需要综合各方面，特别是社会因素、精神因素、认知要素、技术问题、领域问题
、用户沟通等各项复杂内容。⑺管理技术的基础是实践，只有反复实践才能提高管理技术、总结管理经验、更好地、有效地实施和控制管理过程
。11.1软件项目管理概述软件项目管理的内容⑴软件可行性分析⑵人员的组织与管理⑶软件度量⑷软件生产率⑸风险管理⑹
软件质量保证⑺软件配置11.1软件项目管理概述软件项目管理目标软件项目管理成功的目标包括以下几方面：⑴如期完成项目⑵项目
成本控制在计划之内⑶妥善处理用户的需求变动⑷保证项目质量⑸保持对项目进度的跟踪与控制11.1软件项目管理概述软件项目管理的
4P观点⑴人员(people)：软件项目管理实质上是对人的管理。⑵产品(product)：软件工程过程、项目管理的实施，都是为
了得到符合用户预期的软件产品。⑶过程(process)：分为技术实现过程和软件过程管理。⑷项目(project)：是对整个软件
工程中涉及的所有资源、人员、相关数据、文档的总和。11.2软件项目规模度量任何软件项目都需要定量描述才能制定软件开发成本。只有
把软件项目中设计的各项因素，如软件开发时间、人员数量、开发环境的软件工具和硬件系统、资金等资源的指标尽可能量化，才能准确估算软件产
品的规模、复杂度、工作总量。没有定量的项目，将难以展开软件管理和实施过程。对软件产品的度量分为直接度量和间接度量。直接度量是指
通过对软件产品的简单属性直接计算而得到结果的过程。简单属性是指代码行数、操作数和运算符个数、接口个数等能直接计数的特征，它反映的是
软件产品内部特征。间接度量是指通过对软件产品的简单属性、要素的各项特征、准则的经验值间接计算而得到结果的过程。如软件质量评价、软
件复杂性测量等。11.2软件项目规模度量一、代码行技术代码行技术是指用程序的代码量来衡量软件的规模。程序的代码量用代码行（L
ineofCode，LOC）表示。代码行既可以人工测量，也可以用工具自动计算。目前，几乎所有软件开发团队都保留代码行数据，同时
也把代码行作为宣传、描述软件产品的一个重要数据。通过代码行度量，还可以得到软件开发生产率、每行代码的平均成本，文档代码的比值、每
千代码行的错误率等，这些数据不仅评价系统规模，还能评价软件质量、文档管理等要素。11.2软件项目规模度量一、代码行技术生产率计
算：P=KL/EKL：千代码行数，E：项目工作量，用人·月表示每千行代码的平均成本：C=S/KLS：软件项目总成本每千行代
码的平均文档支持度：D=PG/KLPG：软件项目文档的总页数每千行代码错误率：R=ER/KL；ER：代码中的总错误数用户输出输
入文件外部系统查询读写接口软件系统11.2软件项目规模度量二、功能点计算鉴于相同功能，不同语言实现存在代码量的差异，且软件需求
是面向功能的描述，1979年Albrecht提出了面向功能点（FunctionPoint，FP）的度量。面向功能点的度量是基于
定义的5个信息领域的特征数，以及14项技术复杂性因子综合进行的间接度量。下图描述了可用于功能点度量的5个信息领域特征。11.2
软件项目规模度量面向功能点的度量FP=?(总计数值?加权因子)?[0.65+0?01??Fi]面向功能点的度量是用5个信息域（总计
数值）取值：输入项数:计算每个用户输入数据数；输出项数:计算每个用户输出数据(报表、屏幕、出错信息）；查询数：一个查询被定
义为一次联机输入，每一个不同查询都计算；文档数：计算每个逻辑的主文件数；外部接口数：计算可读的接口（如磁盘上的数据文件)。复
杂度的加权因子系数11.2软件项目规模度量面向功能点的度量FP=?(总计数值?加权因子)?[0.65+0?01??Fi]11.2
软件项目规模度量面向功能的度量一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性： 生产率P＝FP／E
质量R＝ER／FP 成本C＝S／FP 文档D＝PG／FP11.2软件项目规模度量面向功能的度量面向功能的度量的优
点：完全不依赖程序设计语言，因此它同样适用于4GL编写的程序规模的度量。根据用户需求规格说明就能确定信息领域特征及技术复杂性因素，
适用于在软件项目初期对软件规模的度量。面向功能的度量的缺点：对于复杂性技术因素确定的主观因素太多，量化标准把握不统一。计算所涉及的
某些数据不易采集，同时也由于主观因素造成数据确定困难。对于计算得到的功能点，难以说明其高或低的结果是由哪些因素所导致。11.2
软件项目规模度量调和不同的度量方法代码行(LOC)和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量.对于相同
功能点各种语言的平均代码行数的估算。语言LOC/FP（平均值）Assembly
320C128Pas
cal91Fortran
58Basic
64High-Order1054GL
1511.3软件项目估算对于将要开发的软件系统，常用的估
算方法有以下几类：(1)对比已有项目产生的实际成本，结合当前项目的需求估算项目成本和工作量。(2)总结已有项目的数据，分析并
概括软件项目成本和工作量的经验公式。(3)按项目中的问题分解。(4)按过程分解。11.3软件项目估算一、代码行、功能点的其
它估算模型⑴对于代码行和工作量之间的关系，Boehm给出了一个基本模型：E=3.2KLOC1.05其中，E是工作
量，KLOC是千代码行。⑵如果估算的代码行较大（大于9KLOC），Poty给出了一个更为准确的模型：E=5.288K
LOC1.047⑶IBM公司也提供了估算代码行与工作量间关系的模型：E=5.2KLOC0.91M=4.1
KLOC0.36D=49KLOC1.01P=0.54E0.6其中，M是项目开发时间（月），D是
文档数量（页），P是所需人员（人）。⑷对于功能点和工作量之间的关系，Albrecht和Gaffney给出了一个基本模型：E=
-13.39+0.054FP软件项目估算二、专家估算模型11.3软件项目估算三、Putnam软件方程式Putnam软件方程
式通过对4000多个软件项目生产率的统计而获得：E=L3/(C3T4)其中：L=代码行数T=软件开发
时间C=技术状态常数2000，比较差的软件开发环境C＝8000，一般的软件开发环境11000，比较好的软件开
发环境11.3软件项目估算四、经验估量模型之一——COCOMO(ConstructiveCostModel)模型有三个层次，
分别用于开发3个阶段性的COCOMO模型：基本模型：用于系统初期估算软件开发工作量（及成本）和软件开发所需时间中级模型：用于估算软
件各个子系统开发工作量（及成本）和开发所需时间详细模型：用于详细设计和编码阶段，估算独立的软部件、模块、核心算法的工作量和开发时间
。11.3软件项目估算基本COCOMO模型E=aKLOCbD=cEd其中，D是软件项目开发时间；a、b、c和
d是常数，具体取值见表项目类型abcd组织型2.41.052.50.38嵌入型3.61.202.50.32半独立型3.01.122
.50.3511.3软件项目估算中级COCOMO模型E=aKLOCbEAFD=3.0E0.33+0
.2(b-1.01)其中，EAF是有关产品、人员、项目等属性的调节因子，其计算模型为：具体参数取值见书311页。11.3软件
项目估算详细COCOMO模型详细COCOMO模型的工作量公式和开发时间公式与中间COCOMO模型相同。工作量因素分级表按照软件开发
的各个不同阶段给出。使用这些表格，可以比中级COCOMO模型更方便、更准确地估算软件开发工作量。11.3软件项目估算项目估算模型
的小结从以上介绍的各类模型可以看出，不同模型有不同的应用范围，也有其一定的局限性。相同项目使用不同模型，估算的成本和工作量都不一
样。因此，在进行项目估算时，必须根据当前项目特点，有选择的经过多个模型的共同估算结果来综合评定。11.3软件项目估算项目估算模
型的小结从各种估算模型不难看出，对于静态单变量模型，如果需要自定义工作量估算模型，则考虑其形式基于如下：E=ACFB
其中，A和B是常数，CF是代码行或功能点。如果需要细致的估算，结合各项影响因子，考虑增加影响因子模型EAF，则自定义工作量估
算模型可以考虑为：E=ACFBEAF其中，常数A、B和影响因子EAF中各因素的取值，从已有项目中通过函数逼近法
确定取值或取值区间，后续各阶段再不断修改和完善各项取值。11.4项目进度管理项目进度控制软件项目进度安排通过把工作量分配给特
定软件工程阶段，并规定完成各项任务的起止日期。进度计划将随着项目进程的变化而会有所更改，但作为整个项目开发时间的宏观控制，则不应有
太大变化。软件项目能否按计划时间完成并及时交付合格的产品是项目管理的重点，也是客户关心的重要内容。但如果为了缩短开发时间，则会大
大增加项目的工作量。Putnam模型已明确说明二者的关系。11.4项目进度管理项目进度控制对于软件项目延期的原因，通常有以下
几种情形：⑴项目进度本身不合理。⑵团队或小组成员的问题。⑶软件架构的问题。⑷对项目各阶段任务所需的资源投入不足，这源于对各
阶段工作量的估算不充分。⑸在项目开发过程中，遇到难以克服的困难。⑹用户需求变更。⑺项目风险管理未做好任务CBA时间11.4
项目进度管理甘特图甘特图（GanttChart）是表示工作进度计划及工作实际进展状况最为简明的图形表示方法。它是历史悠久，使
用广泛的进度计划工具之一。最早开始时刻机动时间事件编号持续时间最晚开始时刻t1t2t3t4t9t7t5t6t8t1011.4项
目进度管理工程网络图工程网络图是制定项目计划时又一种常用的图形工具，它不仅能描述项目的起止时间和各项任务的工期，更能现实的描述各
任务间彼此的依赖关系。11.4项目进度管理工程网络图11.4项目进度管理工程网络图关键路径：T1，T2，T3，T7，T8，
END11.5项目风险管理项目管理的重要内容之一就是对风险进行管理。在任何项目、任何任务的执行过程中，不遇到困难几乎是不可能
的。最后导致项目失败，纵其原因除了项目启动时的需求、估算未能完整分析以外，一类重要原因就是未能预测到风险的出现，以及出现风险时的处
理措施。因此，软件项目的成功与否，还应考虑在风险出现之前，是否能尽量预测风险，并尽量避免风险的发生。如果风险发生不可避免，那就必须
准备好必要的应急预案。11.5项目风险管理软件风险概念风险不同于软件工程过程中的其它事件，它有其自身的特点：⑴可能性。项目风
险是将来要发生的事情。虽然可以采取措施避免或减低风险发生所导致的损失，但完全消除项目风险是困难的。⑵偶然性。首先，软件项目，特别
是有较强领域特征的软件应用项目，是一次特定的开发过程，其产生的风险属于个别事件，有很大的不确定性。其次，软件开发的智力活动产生的风
险难以预料和控制，并且人员受环境、心理、任务等因素的影响较大，更增加风险发生的偶然性。⑶复杂性。软件项目各部分间的非线性关系，其
复杂度远远超过由少数几人就能掌握的程度，需要通过有效的技术分解和团队式管理才能胜任。⑷需求的变动。需求的不断变化，导致软件项目过
程的不断变化，风险平衡状态的出现是动态而短暂的，但其造成的后果可能是严重的，甚至是灾难性的。11.5项目风险管理风险管理过程—
—风险管理目标和模型风险管理目标主要是两点：⑴风险识别。风险识别就是要发现软件项目将来可能出现的风险，并对其进行分析、评估、排序
、建档，使得可能的风险提前“暴露”。⑵风险措施。风险措施分为两个方面：一方面是规避风险的发生，通过严密的开发方案、严格执行开发计
划，严肃进行过程控制管理，最大限度防止风险的发生。另一方面是制定风险发生后的应对措施。由于风险的偶然性和难以控制性，要在风险管理前
就制定风险应急方案，力求把风险影响和造成的损失降到最低，使得软件项目进度仍能按计划向前推进。11.5项目风险管理风险管理过程—
—风险识别风险识别是风险管理过程的第一步。根据具体的项目特征，列出可能出现的风险。风险的类别⑴项目风险⑵技术风险⑶
商业风险⑷人员风险11.5项目风险管理风险管理过程——风险估算假设风险检测表由m项风险，每项风险有n个检测指标。每项风险指
标的取值范围为[ak,bk]，通常ak是该项风险的最理想值，bk则相反。如果ak为0，bk为1，且取值为整数，则说明第k项风险的
评价是布尔型。设第i项风险的第j项指标值为Rij，对应的权值为wij，于是第i项风险的估算定义为：其中，0≤Wij≤1。因而
11.5项目风险管理风险管理过程——风险评估在风险评估中，执行以下步骤，并与水平值共同完成评估。⑴定义与当前项目有关的风险类型
和各项的风险水平参考值；⑵建立风险类型、风险发生概率与风险发生造成的后果与每项水平参考值之间的关系。⑶预先定义一组参考点（标准
）。当估算的风险值超过定义的参考点，将启动风险干预过程。⑷对每组参考点，要考虑哪些风险组合作为参考项。11.5项目风险管理风险
管理过程——风险控制风险控制的主动措施有两项：一是控制软件项目各阶段活动中风险的发生，认真执行风险监督和管理计划；二是当风险不可
避免的发生后，及时启动风险处理过程，降低风险造成的影响和损失，确保软件项目仍按计划，按质保量向前推进。建立风险控制策略是一项必然
的选择。有效的风险控制策略包括3个问题：风险避免风险监控风险管理及应急计划11.5项目风险管理风险管理过程——风险控制风险控
制策略可以是软件项目计划的一部分，也可以是独立的风险环节、监控和管理计划（RiskMitigation、Monitoring、M
anagement，RMMM）。RMMM计划将所遇风险分析都文档化。风险信息表（RiskInformationSheet，R
IS）就是对每项风险进行分析而记录的表单。11.6项目质量管理软件质量是软件产品的生命，它直接影响软件的使用、维护和用户体验
。所有软件开发人员、管理人员和用户都非常重视软件质量。无论是软件工程开发过程、控制，还是风险管理、软件配置管理，都是为了对质量引起
高度重视。什么是软件质量？如何保证软件质量是质量管理的重要内容。11.6项目质量管理软件质量因素可移植性可重用性可操作性可理解
性可维护性灵活性可测试性修改性转移性产品运行性正确性、可靠性、有效性完整性、可用性、风险McCall提出的表明软件质量因素及改进1
1.6项目质量管理软件质量因素检查项目（总）经理沟通软件质量保证项目小组1测试小组项目小组2认识与纠正沟通……项目小组n11.6
项目质量管理软件质量保证活动软件质量保证（SoftwareQualityAssurance，SQA）通过建立一套有计划的、
有系统的方法，保证拟定出的标准、步骤、实践和方法能够正确地被所有项目正确采用。SQA通过管理人员对软件产品和开发活动进行评审和审计
，并验证软件是否符合软件质量评价标准。11.6项目质量管理软件质量保证计划软件质量保证计划（SoftwareQuality
AssurancePlan，SQAP）规定在项目中采用的软件质量保证的措施、方法和步骤。文献[12]定义了SQAP文档格式及其
内容，并需要根据项目的具体情况有所变化，目的就是体现SQA组对用户需求，性能需求、领域需求等方面的约束，对软件工程实施的监督和控制
，对软件配置变更管理的记录和跟踪。11.7软件配置管理软件配置管理（SoftwareConfigurationManag
ement，SCM）是对软件修改进行标识、组织和控制的技术。SCM的目的是通过定义管理软件变化的一组活动来减少由此引起的混乱，提高
软件生产率。SCM定义的变更管理活动主要包括：标识变化；控制变化；监督、记录变化过程；通知与变化相关的所有人员、更新与变化相关
的文档。11.7软件配置管理软件配置项Pressman指出，任何软件产品的最终结果都可以分为如下3类信息：⑴计算机程序（包括
源程序、目标程序和可执行程序）。⑵软件产品在开发过程中生成的文档（面向开发人员和面向用户）。⑶软件产品内部和系统外部存储的数据
。11.7软件配置管理软件配置项⑴系统规格说明；⑵软件项目计划，包括软件开发计划、质量保证计划、配置计划和验收确认计划；⑶
软件需求规格说明；⑷软件设计规格说明，包括概要设计说明和详细设计说明。⑸程序，包括源代码、目标文件、可执行文件、软件部件库、
数据等。⑹软件测试文档，包括测试计划、测试用例、测试脚本和测试报告。⑺维护文档，包括软件维护计划、软件问题报告、变更报告。⑻
用户文档，包括用户手册、联机帮助、安装和部署文档等。⑼软件工程和软件质量管理的标准与过程。⑽对上述各项内容的按需组合，构成复合
软件配置项（针对中小型项目，以及极限编程、敏捷编程等软件开发过程的需要）。11.7软件配置管理管理配置过程软件配置管理是软件
质量管理中重要的环节，它管理的目的就是有效控制变化和修改，缩小更改的涉及面、减少修改带来的副作用。软件配置管理过程主要包括标识
软件配置对象、软件版本控制、变化控制、审计配置和软件配置报告。软件配置项命名软件版本控制变更控制配置审计配置状态报告11.8项
目人员组织管理团队组织——团队构件因素成功的完成软件开发项目，项目团队必须以高效、有益的方式组织起来，并能有效进行交互和通信。在
构建团队时，就要结合项目因素和人员因素考虑团队的组成结构。项目因素主要结合下面的问题来考虑：项目规模大小和复杂程度。对项目中用户
问题的分解程度。对项目性能、操作等非功能性要求的程度。项目开发时间的限制程度。对项目质量要求和可靠性要求的程度。与用户就项目的交流
程度。11.8项目人员组织管理团队组织——团队组织原则对于团队在组织过程中，因遵循以下原则：尽早落实责任：在软件项目工作开始时
，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。减少接口：一个组织的生产率随完成任务中存在的通信路径数目增加而降低。
要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。
11.8项目人员组织管理团队组织方式目前软件项目团队的组织方式很多，团队组织方式不仅涉及人员的构成和组织形式，更要取决于项目特点
、对人员的组织和管理经验。对项目问题分解方式的不同，团队组织和人员的分工也不一样。按项目划分按软件工程开发阶段划分软件开发人员
组织与分工11.8项目人员组织管理团队组织方式对人员的组织和管理，目前有3种常用的组织方式。民主制小组主程序员组层次式小组1
1.8项目人员组织管理11.9软件能力成熟度模型1986年底美国SEI/CMU开始着手研究和制定支持软件开发组织控制、管理
和改进软件过程的软件过程成熟度框架，并于1987年开发了“软件过程评估”和“软件成熟度评价”两个模型，于1991年发布软件能力成熟
度模型（CapabilityMaturityModelforSoftware，SW-CMM或CMM），陆续发布了CMMv
1.0和CMMv2.0。11.9软件能力成熟度模型基本概念⑴过程。虽然人们所处领域和角度的不同，但对过程的理解基本是一致的
。《牛津简明词典》中的定义：过程是一组活动与操作的集合。《韦氏大词典》中的定义：过程是用于产生某种结果的一整套操作、一系列活动、变
化以及作为最终结果的功能。《IEEE-Std－610》中的定义：过程是为完成一个特定目标而进行的一系列操作步骤。⑵软件过程。SE
I/CMU－CMM中的定义是：软件过程是用于软件开发及维护的一系列活动、方法及实践。⑶软件生存周期过程。《ISOIEC12207
－1995》中的定义为：它是一个框架，包含有遍历系统从需求确定到使用终止这一生存周期的软件产品的开发、运行和维护中需要实施的过程、
活动和任务。⑷软件过程能力。它用于描述通过执行软件过程、实现预期结果的能力。11.9软件能力成熟度模型基本概念⑸软件过程成熟
度。它是指一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。随着软件组织的过程成熟度的提高，其对软件组织结构的安排、组织
结构的建立、软件质量标准的规范和过程实施控制的严格，使得对软件过程有明确的管理和工程化方法。⑹CMM。CMM是对软件组织在项目定
义、组织构建、管理实施、项目度量、过程控制和改善的实践中，对各个开发阶段和管理过程的描述。CMM通过确定当前过程的成熟度、识别实施
软件过程的不足之之处，并提出对软件质量和过程的改进问题，最终形成对软件过程的改进策略。⑺CMM框架。CMM框架以CMM为基础，将
软件过程从无序到有序的进化过程，并将该过程划分为5个等级，为软件过程不断改进奠定了一个循序渐进的基础。11.9软件能力成熟度模
型软件能力成熟度等级CMM把软件过程的改进过程划分为5个等级，每个等级都有各自软件过程的基本特征、实践任务和管理目标，每个等级都
为过程改进的继续提供基础。当每个等级的过程实施达到该等级的过程目标，对该等级的特征、任务和管理建立一个重要成分并稳定下来，从而也导致在CMM框架中软件开发组织的过程能力得到一定程度的提高。优化级过程变更管理已管理级定量的过程管理已定义级综合软件管理可重复级软件项目计划、软件项目跟踪和监督初始级11.9软件能力成熟度模型基软件能力成熟度等级11.9软件能力成熟度模型关键过程域关键过程域（KeyProcessArea，KPA）是描述软件过程的属性集合。它通过定义一组相互关联的软件实践活动和有关的基础设施，达到成熟度等级的目标，同时体现和提高软件过程能力。等级成熟度可视性过程能力关键过程域1初始级有限的可视性一般达不到进度和成本的目标。2可重复级具有管理可视性由于基于过去的性能，项目开发计划比较现实可行。需求管理软件项目计划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理3已定义级项目定义软件过程的活动具有可视性基于已定义的软件过程，组织持续地改善过程能力。软件机构过程关注点软件机构过程定义培训计划整体化软件管理软件产品工程组间合作同行评审4已管理级定量地控制软件过程基于对过程和产品的度量，组织持续地改善过程能力。定量过程管理软件质量管理5优化级持续改善软件过程组织持续地改善过程能力。过程变更管理预防故障技术变更管理第11章软件项目管理小结一、软件项目管理的4P内容人员、产品、过程、项目二、软件项目估算代码行、功能点、专家估算模型、Putnam模型、COCOMO模型三、项目进度管理甘特图、工程网络图四、项风险管理、配置管理、人员组织管理五、软件能力成熟度模型CMM |
|
