【软件项目管理】

一、概述

1.项目: 为创造唯一产品或提供唯一服务所进行的临时性的工作。项目必须具备唯一性和临时性

2.项目与日常活动不同：一次性；以目标为导向；存在变更管理；通过项目经理进行团队化管理

3.项目的特点：唯一性、目标性（成果性目标）、约束性（资源有限）

4.项目和运营：

（1）区别：运营不产生唯一的产品（唯一性）；运营没有明确的开始结束节点（临时性）

（2）共同点：需要包括人力资源在内的资源；严格受资源限制；要被管理 需要计划；有明确目标

5.软件项目的特点：

（1）软件本身不是物理实体，只是一种逻辑载体，因此软件项目具有抽象性。

（2）软件不存在老化和磨损问题，但是软件在生存期内会随着环境的变化和技术的更新而出现退化的现象。

（3）软件具有可复用性。

（4）软件开发基本是定制过程，无法利用现有软件组装成新的软件。

（5）软件项目的开发依赖于计算机系统。

（6）软件项目的开发需要高强度、复杂的脑力劳动，因此它的成本比较高。

6.软件项目管理的根本目的：为了保证软件项目的整个生命周期都能在管理者的控制下，按照既定的成本，保质如期地完成软件开发并交付客户。

7.软件项目管理的四大变量：范围、进度、成本、质量（具体关系如下图）

8.成功的项目应该是在工程允许的范围内满足成本、进度和客户满意的产品质量。判断项目成功的因素包括：项目范围、进度计划、项目成本以及客户满意度

9.项目干系人：利益受项目的执行和完成所影响（积极/消极）的个人或组织。

10.项目管理的五个要素：技术、方法、团队建设、信息、沟通

11.项目管理的五个过程组：启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组

        各阶段关系图如下

二、项目集成管理

1.项目集成管理的主要过程：制定项目章程、创建初步的项目范围说明书、制定项目管理计划、指导和管理项目实施、监控项目工作、集成变更控制、项目收尾

2.项目章程

内容：项目发起人及发起时间 、项目的预期交付成果形式 、 项目开展的进度计划 、 项目要实现的目标、项目经理及联系方式 、项目开展的必要性 、 项目正式名称 、项目团队介绍、项目执行过程的重点和难点问题 、 项目成本预算和预期效益等

项目章程一般采用表格形式展示，如图：

3.制定项目章程的工具：要素分层法、方案比较法、净现值法、层次分析法等

4.项目执行控制过程：指导和管理项目执行、监控项目工作、集成变更控制

5.项目收尾的一个重要过程就是项目的最后评审

三、项目范围管理

1.项目范围管理阶段：项目需求、范围定义、范围核实、范围控制

2.软件项目管理的特殊性：

（1）软件项目是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以保证；

（2）软件系统的复杂性导致开发过程中各自风险的难以预见和控制。

（3）软件项目实现的结果与软件需求分析的结果息息相关。

3.软件需求：

（1）用户为解决某一问题或达到某一目标所需条件或权能

（2）系统或系统构件为了满足合同、规约、标准或其他正式实行的文档所需具有的条件或权能

（3）一种反映上述（1）或（2）所述条件或权能的文档说明。

4.软件需求的三个层次：业务需求、用户需求、功能需求

        根据业务需求、用户需求、功能需求确定软件需求规格（SRS）

        软件需求阶段主要的输出是需求规格说明文档（SRS）

5.软件需求获取具有模糊性、不确定性、易变性和主观性的特点。在面向对象的方法中，项目干系人通过用例图来获取软件需求

6.工作分解结构WBS

WBS是面向可交付成果的对项目元素的分组，组织并定义了整个项目的范围，是一个分级的树型结构，是对项目由粗到细的分解过程。

（1）WBS工作分解原则：

① 一个任务只在 WBS 中的一个地方出现。

② WBS 中某项任务的内容是其下所有 WBS 项的总和。

③ 一个 WBS 项只能由一个人责任，其他人只能是参与者。

④ 每个 WBS 项都必须文档化，以确保准确理解工作范围。

⑤ 分解粒度合理。

⑥ 确定关键任务、阶段及里程碑 。

（2）WBS构成：编码、工作包（最底层元素，最小的“可交付成果”）、WBS元素、WBS字典（用于描述和定义WBS元素中的工作的文档）

（3）工作分解的两种模式：基于功能的分解；基于过程的分解

（4）工作分解的类型：清单类型、图表类型

采用清单类型的分解方式，就是将任务分解的结果以清单的表述形式进行层层分解的过程，如下图

采用图表类型的任务分解就是进行任务分解时采用图表的形式进行层层分解的方式。

（5）工作分解种类：组织分解结构OBS、材料清单BOM、风险分解结构RBS、资源分解结构RBS

四、软件项目成本管理

1.成本估算——代码行方法LOC

例如，某软件公司统计发现该公司某项目源编码为15万行，该项目累计投入工作量为240人月，每人月费用为10 000元，则该项目中1LOC的价值为：

                              (240×10000)元/150000=16元

2.成本估算——功能点方法FP

（1）功能点是用系统的功能数量来测量其规模，以一个标准的单位来度量软件产品的功能

（2）构成：外部输入EI、外部输出EO、内部逻辑文件ILF、外部接口文件EIF、外部查询EQ

技术复杂度因子TCF、未调整功能点数UFC

（3）公式：FP = UFC * TCF

（4）例：某软件的五类功能计数项如下表表示，假设这个软件项目所有的技术复杂程度都是显著影响（显著对应的调整系数为4），计算这个软件的功能点。

根据Albrecht复杂度权重表，将每个类型组件的每一级复杂度计算值输入到下表中。每级组件的数量乘以所示的级数得出定级的值。表中每一行的定级值相加得出每类组件的定级值之和。这些定级值之和再相加，得出全部的未调整功能点计数（UFC），则UFC结果表如下表所示。

UFC=6×3+4×4+3×6+7×4+5×5+4×7+2×7+4×10+6×15+3×5+4×7+5×10+3×3+2×4+4×6=411

TCF=0.65+0.01×14×4=1.21

FP=UFC×TCF=411×1.21=497.31

3.成本估算——类比估算法（自顶向下方法）

（1）从项目的整体出发，进行类推，即估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中，是一种自上而下的估算形式

（2）简单易行，花费较少；但是准确性较差

（3）以下情况的类推估计是可靠的：（1）先前活动和当前活动是本质上类似而不仅仅是表面的相似；（2）专家有所需专长。对于软件项目，利用企业的历史数据进行历史估计是常见的方法。

4.成本估算——自下而上估算法

（1）估算个别工作包或细节最详细的计划活动的费用，然后将这些详细费用汇总到更高层次，以便于报告和跟踪目的；通常利用任务分解结构图，对各个具体工作包进行详细的成本估算，然后将结果累加起来得出项目总成本。

（2）花费时间较长，估算本身有一定的成本，可能发生虚报现象

5.成本估算——专家估算法（最流行的：Delphi方法）

（1）由一个被认为是该任务专家的人来进行估算，并且估算过程的主要部分是基于不清晰、不可重复的推理过程，即直觉。

（2）专家估算法是解决成本估算问题的最直接的选择；但缺点在于，专家的个人偏好、经验差异与专业局限性都会为成本估算的准确性带来风险。

6.成本估算——参数模型估算法

（1）找到软件工作量的各种成本影响因子，并判定它对工作量所产生的影响的程度是可加的、乘数的或指数的，以期得到最佳的模型算法表达形式。当某个因子只影响系统的局部时，则为可加的。

（2）结构化成本模型COCOMO是世界上应用最广泛的参数型软件成本估价模型，包含三个层次：基本模型、中间模型、详细模型

7.项目资源管理PRM

（1）确定项目资源：人力资源管理、外部协调、项目资金管理等

（2）为了降低项目成本，而对项目所需人力、材料、机械、技术、资金等资源所进行的计划、组织、指挥、协调和控制等活动。

（3）项目资源管理的全过程包括项目资源的计划、配置、控制和处置。

8.成本控制——挣值管理方法EVM

（1）计划价值（ PV）：计划要做多少事；

挣值（EV）：实际上做了多少事；

实际成本（AC）：实际上花了多少钱；

完工预算（BAC）：完成整个项目计划多少预算（总预算）；

成本偏差（ CV）：截止到某时点发生的实际成本与计划成本的偏差，负数代表成本超支的部分；

进度偏差（SV）：截止到某时点的实际进度与计划进度的偏差，负数代表落后的工作量；

成本绩效指数（CPI）：实际花了多少钱，但是实际上完成做了多少钱的事；

进度绩效指数（SPI）：截止到某时点衡量进度绩效的一种指标，也就是实际完成的工作量与计划完成工作量之比，假设为0.75则代表当前只完成计划任务量的75%的进度；

完工成本预算（EAC）：在某个时点，预测完成整个项目需要的成本，如果剩余工作还是以当前成本绩效指数CPI来完成，那么也可以这么计算 EAC = BAC / CPI ，这个公式也好理解，其实就是整个项目工作量除以成本绩效指数；完工估算EAC实际上就是预测项目完工时候的实际成本AC。

（2）公式：CV = EV - AC、SV = EV - PV、CPI = EV / AC、SPI = EV / PV、 EAC = BAC / CPI 

9.成本控制——结果

工作绩效信息、成本预测、变更请求、经验教训

五、软件项目时间管理

1.项目时间管理的过程：活动定义、活动排序、活动资源估计、活动工期估计、进度安排、进度控制

2.活动排序

（1）一般活动之间存在的关系：

结束—>开始FS：表示A任务（活动）在B任务（活动）开始前结束；

结束—>开始FF：表示A任务（活动）结束B（活动）任务才可以开始；

开始—>开始SS：表示A任务（活动）开始，B任务（活动）才可以开始；

开始—>结束SF：表示A任务（活动）开始，B任务（活动）才能结束。（极少使用）

（2）一般的项目中活动之间存在的关系

紧前活动：必须在某个活动之前完成的任务。

紧后活动：必须在某个活动之后进行的任务。

（3）活动之间的关联关系

强依赖关系（硬逻辑关系）：活动之间本身存在的、无法改变的逻辑关系

自由依赖关系（软逻辑关系）：人为组织确定的，两项活动可先可后的组织关系

外部利来关系：项目活动与非活动之间的依赖关系（软件项目测试活动的进度可能取决于来自外部的硬件是否到货）

3.计划活动资源估算

（1）计划活动资源估算就是确定在实施项目活动时要使用何种资源（人员、设备或物资），每一种使用的数量，以及何时用于项目计划活动。

（2）活动资源估算过程和成本估算过程紧密结合。

（3）资源顾忌的主要输出：活动资源清单、资源分解结构、变更申请、活动属性和资源日历的更新

4.项目工期历时估计

（1）输入：活动清单、活动属性、活动资源需求、资源日历、项目范围说明、企业环境因素、组织过程资产

（2）常用的工期估算方法：基于规模的进度估算；工程评估评审技术（ PERT）；专家估算法；类比估算法；关键路径法；三点估算法；参数估算法；自上而下经验比例法

（3）基于规模的进度估算

①定额估算法：

        T代表活动持续时间；Q代表活动工作量（人天、人月等）；R代表人力或设备数量；S代表开发效率（单位时间完成的工作量）

        

②经验导出模型：

        D代表活动持续时间；E代表活动工作量；a代表2~4之间的参数；b代表1/3左右的参数

        

（4）工程评估评审技术 PERT

①采用加权平均的算法：

②O代表最大乐观值；P代表最大悲观值；M代表最大可能估算值

③例题如下

④标准差：

标准正态分布图如下

（5）关键路径法CPM

①最早开始时间（ES）：表示一项任务（活动）的最早可以开始执行的时间。

最晚开始时间（LS）：表示一项任务（活动）的最晚可以开始执行的时间。

最早完成时间（EF）：表示一项任务（活动）的最早可以完成的时间。

最晚完成时间（LF）：表示一项任务（活动）的最晚可以完成的时间。

超前：表示两个任务（活动）的逻辑关系所允许的提前后置任务（活动）的时间，它是网络图中活动间的固定可提前时间。

滞后：表示两个任务（活动）的逻辑关系所允许的推迟后置任务（活动）的时间，是网络图中活动间的固定等待时间。

浮动时间：就是可以延迟开始的时间

关键路径：最早和最迟时间相同就是关键任务，关键路径上的所有任务浮动时间都等于零

②举例如下

（6）三点估算法

①估计活动执行的三个时间，乐观持续时间a，悲观持续时间b，最可能持续时间m，对应于PERT网络期望时间公式为：t = ( a + 4m + p ) / 6

②例题如下

5.软件进度管理安排的表示方法：甘特图、网络图、里程碑图

（1）甘特图

①按内容区分：分为计划图表、负荷图表、机器闲置图表、人员闲置图表和进度表五种形式

②表示方法

棒状图：用棒状表示任务的起止时间，空心棒状图代表计划起止时间，实心棒状图代表实际起止时间，棒状图中一个任务要占用两行空间。

三角形图：用三角形表示特定日期，方向向上三角形表示开始时间，向下三角形表示结束时间，计划时间和实际时间分别用空心三角和实现三角表示，一个任务仅占用一行空间。

③优缺点：易于理解；仅能部分地反映项目管理的时间、成本和范围的关系

（2）网络图

①网络图能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系

②PDM网络图（前导图法）：

节点：表示的是工作，一个节点则表示一个工作。

箭线：表示的是工序之间的逻辑关系

线路：在单代号网络途中，每条线路都用其该线路上的节点编号，依照从小到大的顺序进行表述。

③ADM网络图（箭线图）

箭头表示任务，节点表示前一道任务的结束，同时也表示后一道任务的开始。

④CDM网络图（条件箭头线图法）

允许活动序列相互循环和反馈，诸如一个环（比如：某试验须重复多次）或条件分支（比如：一旦检查中发现错误，设计就要修改）

⑤PDM和ADM都不允许回路或有条件分支存在

（3）里程碑图

①项目计划以里程碑为界限，将整个开发周期划分为若干阶段。里程碑仅表示事件的标记，不消耗资源和时间

②里程碑的设置要尽量符合实际，并且不轻易改变里程碑的时间。

6.进度控制需要遵循的定理：动态原理、系统原理、封闭循环。、信息原理、弹性原理

六、软件项目质量管理

1.质量：质量是产品或者服务满足明确和隐含需要能力的性能特性的总体

2.质量特点：明确或隐含的需求是项目需求开发的依据。就项目而言，质量管理的一个关键就是通过利害相关者分析，将利害关系者需求、需要转化为项目范围管理中的要求。

3.软件质量反映了三方面的问题：

（1）软件需求是度量软件质量的基础，不满足需求的软件就不具备质量。

（2）不遵循各种标准中定义的开发规则，软件质量就得不到保证。

（3）只满足明确定义的需求，而没有满足应有的隐含需求，软件质量也得不到保证。

4.软件质量模型——McCall质量模型

（1）产品的质量操作：

        正确性：程序满足其规格说明以及实现用户目的的程度。

        可靠行：程序能够在规定的精确下执行预期功能的程度。

        有效性：软件所需要的计算机资源的数量。

        完整性：控制未经授权的用户访问软件或数据的程度。

        可用性：学习、操作、准备输入数据和解释输出所需要的工作量。

（2）产品修订质量：

        可维护性：定位和修改运行程序中的错误所需要的工作量。

        可测试性：测试程序确保程序实现预期功能所需要的工作量。

        灵活性：修改运行程序所需要的工作量。

（3）产品转变质量：

        可移植性：把程序从一种硬件配置/或软件系统环境转移到另一种环境所需要的工作量。

        可重用性：程序能用在其他应用程序中的程度。

        互操作性：把系统和另一个系统相互耦合需要的工作量。

5.软件质量模型——Boehm质量模型

（1）Boehm模型反映了对软件质量的全过程理解，即软件做了用户要它做的、有效地使用系统资源、易于用户学习和使用、易于测试和维护

（2）如图所示

    

6.软件质量模型——ISO/IEC9126质量模型

分为三个：内部质量模型、外部质量模型、使用中质量模型（如图所示）

7.软件缺陷

（1）根据软件缺陷所造成的危害的恶劣程度来划分，一般分为致命的、严重的、一般的和微小的缺陷。

（2）根据软件缺陷产生的技术类型分为来分类，一般分为五种类型：输入/输出缺陷、逻辑缺陷、计算错误、接口缺陷和数据缺陷。

8.石川图（因果图）

将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因

9.质量是计划出来的，不是检查出来的

10.质量保证QA：为了提供信用，证明项目会达到有关质量标准，而开展有计划、有组织的工作活动

11.软件质量保证SQA：验证在软件开发过程中是否遵循了合适的过程和标准。其主要作用是保证软件透明开发的主要环节，贯穿整个项目的始终

12.软件质量保证实施的步骤：目标、计划、执行、检查、改进

（1）计划阶段：确保制定了软件开发质量计划和软件配置管理计划

（2）需求分析阶段：确保客户提出的需求是可行的，确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们的目的，确保开发人员和客户对于需求没有误解或者误会，确保按照需求实现的软件系统能够满足客户提出的要求。

（3）设计阶段：

确保规格定义能够完全符合、支持和覆盖前面描述的系统需求；可以采用建立需求跟踪文档和需求实现矩阵的方式，确保规格定义满足系统需求的性能、可维护性、灵活性的要求；确保规格定义是可以测试的，并且建立了测试策略；确保建立了可行的、包含评审活动的开发进度表；确保建立了正式的变更控制流程。

    在详细设计阶段，要确保建立了设计标准，并且按照标准进行设计；确保设计变更被正确的跟踪、控制、文档化；确保按照计划进行设计评审；确保设计按照评审准则评审通过并被正式批准之前，没有开始正式编码。

（4）编码阶段：确保建立了编码规范、文档格式标准，并且按照该标准进行编码；确保代码被正确地测试和集成，代码的修改符合变更控制和版本控制流程；确保按照进度计划编写代码；确保按照进度计划进行代码审查。

（5）测试阶段：确保建立了测试计划，并按照测试计划覆盖了所有的系统规格定义和系统需求；确保经过测试和调试，软件仍旧符合系统规格和需求定义。

（6）系统交付和安装阶段：确保按照软件交付计划交付、安装软件系统，并按照培训计划对用户进行培训；确保交付给用户所有的文档；制定并评审、批准了软件维护计划；用户进行了验收确认

13.质量控制的过程：技术评审，代码走查，代码评审，软件测试，软件缺陷跟踪

14.质量控制的控制工具：检验、因果图、控制图、帕累托图、流程图。散点图、趋势分析、抽样统计

15.能力成熟度集成模型CMMI

（1）CMMI的连续表示

CMMI模型中固定的4个能力水平依次为0～3编号，分别是：

CL0不完备级，过程域的一个或多个目标没有被满足；

CL1已执行级，过程通过转换可识别的输入工作产品，产生可识别的输出工作产品，能实现过程域的特定目标；

CL2管理级，过程作为已管理的过程被制度化；

CL3已定义级，过程作为已定义的过程被制度化。

（2）CMMI的阶段式表示

CMMI模型中规定的5个成熟度水平依次从1～5编号。分别为：

ML1初始级，遵循的规程是随意的，有些项目可能会成功，仅仅是因为某个人的技能。因为没有0级，所以组织默认都属于这个等级；

ML2已管理级，这个等级的组织有基本的项目管理规程。然而，单个任务的完成情况完全取决于做这项任务的人；

ML3已定义级，组织已经定义了软件开发生命周期中每个任务应该完成的方法；

ML4已量化管理级，软件开发中涉及的产品和过程都必须进行度量和控制；

ML5优化级，能使用从度量过程中获得的数据来设计和实现对规程的改进。

16.能力成熟度模型CMM

初始级：软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤。

可重复级：建立了基本的项目管理过程和实践来跟踪项目费用。进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功

已定义级：管理和工程两方面的软件过程已经文档化、标准化

已管理级：制定了软件过程和产品质量的详细度量标准

优化级：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进