第三章软件项目管理

第三章软件项目管理主讲：肖丁dxiao@;北京邮电大学通信软件工程中心203二月2023提纲3.1项目管理过程3.2风险管理3.3软件质量和效率度量3.4软件项目估算3.5软件项目进度安排3.6项目组织结构设计3.7项目过程监控303二月20233.1项目管理过程项目的定义：是为创造独特产品、服务或其它成果而进行的一次性工作。项目的属性：（对比常规运作）一次性/独特性；目标的确定性/过程的不确定性；时间、成果、需求的满足；确定性项目目标允许修改；不确定性活动的整体性/过程的渐进性；项目组织的临时性和开放性；对资源的依赖性；403二月20233.1项目管理过程项目管理的定义：是以项目为对象的系统管理方法。即：由柔性组织（临时/专门）运用：知识、技术、工具、手段进行：高效率的计划、组织、执行、控制实现：项目过程的动态管理、项目目标的综合协调与优化。软件项目管理的定义：为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动。503二月2023项目的全目标管理：面向系统（可交付的软件）、组织（运营该软件的组织）、人员（组成该组织的人员）；全面满足质量、进度、费用的要求。项目的全过程管理：启动过程---确定目标、范围；计划过程---时间、任务、进度；执行过程---实施所需的任务；控制过程---监控度量项目的进程；结束过程---验收603二月20233.1项目管理过程软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。。为使软件项目开发获得成功，关键问题是必须对软件开发项目的工作范围、可能风险、需要资源（人、硬件／软件）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等做到心中有数软件项目管理可以提供上述信息。软件项目开始于技术工作开始之前，持续进行于软件实现过程中，终止于软件工作过程结束。703二月20233.1项目管理过程项目管理过程包括下列任务：人员的组织与管理，软件度量，项目计划，风险管理，质量保证，软件过程能力评估，配置管理等。软件项目的主要活动包括：3.1.1启动一个软件项目3.1.2度量3.1.3估算3.1.4风险分析3.1.5进度安排3.1.6追踪和控制3.1.7结束项目803二月20233.1.1启动一个软件项目在制定软件项目计划之前，必须

明确项目的目标和范围考虑候选的解决方案标明技术和管理上的要求有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。903二月20233.1.2度量进行度量工作，是为了了解产品开发的技术过程和产品本身。度量开发过程的目的是为了改进过程，度量产品的目的是为了提高产品的质量。度量的作用是为了有效地定量地进行管理。管理人员和技术人员可利用这些度量来了解软件工程过程的实际情况和它所生产的产品质量。问题：请思考，哪些是可度量的指标？1003二月20233.1.3估算在软件项目管理过程中关键的活动就是制定项目计划。做计划必须就需要的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）做出估算。这种估算大多是利用以前的花费做为参考而做出的。如果新项目与以前的一个项目在大小上和功能上十分类似，则新项目可以参考老项目。假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。1103二月20233.1.3估算现在已有了许多用于软件开发的估算技术。其共同特点是：

事先建立软件工作范围以软件度量（以往的度量）为基础作出估算项目被分解为可单独进行估算的小块管理人员大多使用不止一种估算技术，并用一种估算技术做为另一种估算技术的交叉检查。1203二月20233.1.4风险分析风险的概念：可能发生的危险。包括两个要素：

风险=损失*可能性软件项目风险是由项目的不确定性造成的。比如：在构建一个软件时，总是存在某些不确定性。

用户要求是否能确切地被理解？在项目最后结束之前要求实现的功能能否建立？是否存在目前仍未发现的技术难题？在项目出现严重误期时是否会发生一些变更？等等。1303二月20233.1.4风险分析风险分析对于软件项目管理是决定性的，然而现在还有许多项目不考虑风险就着手进行。所谓风险分析实际上就是一系列风险管理步骤，其中包括风险识别、风险估计、风险优化、风险管理策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。1403二月20233.1.5进度安排对于进度安排，需要考虑的是：

预先对进度如何计划？工作怎样就位？如何识别定义好的任务？

管理人员对结束时间如何掌握？如何识别和监控关键路径？对进展如何度量？如何建立分隔任务的里程碑。1503二月20233.1.5进度安排软件项目的进度安排与任何一个工程项目的进度安排基本相同。首先识别一组项目任务，再建立任务之间的相互关联；然后估算各个任务的工作量，分配人力和其它资源，制定进度时序1603二月20233.1.6追踪和控制由项目管理人员负责追踪在进度安排中标明的每一个任务。如果任务实际完成日期滞后于进度安排，则管理人员必须确定在项目的中间里程碑上进度误期所造成的影响。还可对资源重新定向对任务重新安排（做为最坏的结果）可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。1703二月2023提纲3.1项目管理过程3.2风险管理3.3软件质量和效率度量3.4软件项目估算3.5软件项目进度安排3.6项目组织结构设计3.7项目过程监控1803二月20233.2风险管理进度过分紧迫；预算过分紧张；性能过分的超群，软件可靠性要求过高；人员缺乏经验，组织结构不适宜；期望过高而不现实；没有明确或理解合同的条款；软件规模估计不恰当；管理部门缺乏经验；风险分析和管理不恰当；缺乏政策性支持；不熟悉技术或过程；不熟悉必要的硬件；需求不一致（或定义不充分）；需求不断变动；软件开发计划不恰当；软件开发过程模型不适用；缺乏软件工程技术和方法；缺乏自动化工具的支持；常见的软件风险类别：进度、经费、性能、组织、管理、人事、过程、方法、工具等。如下例证：1903二月20233.2风险管理对软件项目的管理部门来说，在做出与规定费用、按规定时间交付规定产品、或达到规定性能水平的决断时，风险是永远存在的。软件项目管理部门因风险而导致工作失败有三种方式：产品达不到规定的功能及性能水平、实际费用过高、交付过迟等。就一个项目而言，其面临的风险可分为五个方面：技术（与功能和性能有关）、保障性（与性能有关）、计划（与信息环境有关）、费用和进度（与人员有关）。2003二月20233.2风险管理技术风险：可以定义为发展某项新设计所包含的风险，发展这项设计可能因为受到某些新的约束条件的作用而使性能水平原封未动，甚至反而有所下降。许多技术风险往往是由于对新系统和新设备提出前所未有的性能要求造成的。计划风险：是包括获取和使用一些可能不受软件项目控制但又可能影响软件项目方向的可用资源和活动。计划风险一般不会与改善技术水平有直接关系。计划风险可按一些因素的性质和来源分类，这些因素有可能中断软件项目实施计划。造成软件中断的因素主要以下几种：（1）与软件项目直接有关的高层权力机构决策造成的中断；（2）一些影响软件项目的事件或行动造成的中断；（3）主要由于一些不能预见的与生产有关的问题造成的中断；（4）因能力不足造成的中断。2103二月20233.2风险管理保障性风险：是与系统的部署和维护有关的风险，这些系统指目前正在研制或正在部署的系统。保障性风险包含有技术和计划两个方面风险的特征。费用和进度风险：一些性能和设计技术问题有时要靠增加费用和延长进度来解决，这往往会使问题变得复杂化。费用和进度增长指预计软件项目费用和进度与实际费用和时间之间的差异。因此，费用和进度增长会造成两个主要的费用/进度风险区：预计时定下不合理的低费用/进度目标所造成的风险；要想满足合理的费用/进度目标，软件项目就必须给定一个谨慎的风险。2203二月20233.2.1风险估计是否所有项目都要进行风险分析。

No,风险分析成本较高，只有当软件的成本、性能、作用、与其他系统间的关系对于重要的系统有比较大的影响时，即软件的风险对整个系统的成败有关键影响时，才有必要进行风险分析和管理。风险估计的步骤1.明确项目的目标、策略、可以使用的方法和资源；2.保证项目的目标和结果是可度量的，并标明使用的资源；3.制定项目成功的标准集合；（见下页）4.根据估计的结果确定是否进行风险分析。2303二月20233.2.1风险估计度量项目成功的标准：

1.最大限度的收益；（1-5对开发方）

2.最小的费用；

3.最小的风险损失；

4.最大限度的市场；

3.最小的周期性波动；

6.形成有益的形象；

7.最佳的服务质量；（对用户方）

8.最高的增长率；

9.员工的满意度最高；

10.公司的声望最高。2403二月20233.2.2风险分析步骤一：风险识别（已知-未知）根据已知的风险事件，标识潜在风险项：收集信息，标明相关的风险。观察风险的征兆，理解其原因。收集信息：主要依靠过去的经验和一些著名的案例，考虑类似的因素并进行常识性的判断。（如需求变动的风险）判断收集到的信息是否有用。信息分类：如：有风险（经常发生的情况）、可预见的风险（较高概率发生）、不可预见的风险（事前很难预料），原因可分为：缺乏信息、管理和时间等。2503二月2023风险识别–

风险检查表举例需求阶段：可能的风险事件包括：项目目标不清；项目范围不明确；用户参与和沟通少；对业务了解不够，缺少领域知识；对需求了解不够；没有进行可行性研究；2603二月2023风险识别–

风险检查表举例设计阶段：可能的风险事件包括：项目队伍缺乏经验，比如缺乏有经验的系统分析员；没有变更控制计划；仓促计划，可能带来进度风险；漏项；2703二月2023风险识别–

风险检查表举例开发阶段：可能的风险事件包括：开发环境未准备好；设计错误带来的实施困难；程序员开发能力差；项目范围改变；项目进度改变；人员变动；开发团队内部沟通不畅；没有切实可行的测试计划；测试人员经验不足；2803二月20233.2.2风险分析步骤二：单个风险分析 估计每个风险的大小及其出现的可能性：度量风险的后果和严重程度。选择一种度量尺度：命名尺度、序次尺度、坐标尺度、比例尺度等；将待估计的风险信息（叙述性、定性、定量三种类型）与度量尺度相对应，确定风险等级；消除风险估计中的主观判断的偏差。（缺乏可以用来进行判断风险的信息，只能凭自己的观念和偏好进行主观理解，与客观情况必然存在着偏差。）2903二月20233.2.2风险分析步骤三：多个风险分析：要考虑风险间的相互作用。（第二步考虑的是单个风险的影响）考虑各种风险的综合影响后，对已识别风险发生的可能性及其后果给出最终的量值；标明风险优先程度，以便予以适当安排；考虑其它可替代的方案，寻求可以避免风险的基本方法。3003二月20233.2.3风险评估第一步：确定风险评估标准，确定风险的后果，判定该风险是否可以忍受；第二步：确定风险最终的级别（风险特征的三个方面：发生频率、损害的严重性、发生的时刻可知性）；第三步：把系统风险和“对照风险”相比较，确定系统风险是否可以接受。（<<可接受；>>不可能接受；≈不适合接受）3103二月20233.2.3风险评估什么是“对照风险”呢？对照风险是一组单个风险的集合，也可是对项目造成最大损害的一个或多个风险。对照风险考虑了风险间可能发生的耦合或复合情况。对照风险说明了在把系统作为整体条件下，风险会造成系统失败或成功的概率。3203二月20233.2.4风险管理任务风险管理的任务：制定风险计划：

风险管理计划—RMP和风险排除计划—RA（aversion）P。（确定风险可接受目标；调整新的“对照风险”；寻求可替代的解决方案。）进行风险控制：

执行风险计划中体现风险排除策略的控制机制。（确定风险排除策略：后果、时间和频率；确定风险排除战术：建立在软件工程过程基础上；建立风险管理计划：有关工作编入文档｛风险状态估计RES说明项目的总体状况，风险管理计划RMP说明如何在一个项目中施行风险分析和管理程序，风险排除计划RAP是排除风险的详细计划｝。）对风险进行监管：监管软件工程过程和产品，确定风险排除策略是否达到预期目标，是否有可能进一步改进风险排除计划，为控制新的风险提供一些必要的决策信息等。3303二月2023提纲3.1项目管理过程3.2风险管理3.3软件质量和效率度量3.4软件项目估算3.5软件项目进度安排3.6项目组织结构设计3.7项目过程监控3403二月20233.3软件质量和效率度量度量是任何工程项目最基础的工作，软件工程也不例外。LordKelvin：如果谁能够度量他所说的事物并能用数字来表示它时，则说明他了解了它；但当他不能度量它，也不能用数字表示出来时，则说明他对那种事物的知识还比较贫乏、不足；这也可能是了解的开始，但在他的思想中很难达到科学的境地。软件度量的范围涉及很广，在软件项目管理范围内，应主要关心生产率与质量的度量，即根据投入的工作量，对软件开发活动和开发成果的质量作出度量。3503二月20233.3.1为什么要进行度量表明软件产品的质量；弄清软件开发人员的生产率；定量管理给出使用了新的软件工程方法和工具所得到的（在生产率和质量两方面）的效益；建立项目估算的“基线”；过程改进帮助调整对新的工具和附加培训的要求。3603二月20233.3.2软件度量方式软件工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度量包括产生的代码行数（LOC）、执行速度、存储量大小、在某种时间周期中所报告的差错数。软件产品的间接度量包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。3703二月20233.3.2软件度量方式集中在软件工程过程的输出。软件满足用户要求的程度。集中在软件的性能指标而不是软件开发全过程上。收集与直接度量有关的软件工程输出信息和质量信息。提供直接度量的尺度。收集有关人们开发计算机软件所用方式的信息和人们理解有关工具和方法的效率的信息。3803二月20233.3.3面向规模的度量面向规模的度量是对软件和软件开发过程的直接度量。可以建立一个面向规模的数据表格来记录项目的某些信息。该表格应列出在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。3903二月20233.3.3面向规模的度量工作量和成本是针对软件开发全过程的，而不是仅针对编码。4003二月20233.3.3面向规模的度量对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。 生产率＝KLOC／PM（人月） 质量＝错误数／KLOC

成本＝元／LOC

文档＝文档页数／KLOC4103二月20233.3.3面向规模的度量大多数争议是是否使用代码行数（LOC）做为度量的依据。支持者认为LOC是所有软件开发项目的必然产物，它能够很容易地被计算；现在许多既存的软件估算模型都是使用LOC或者KLOC做为关键输入的；而且大量以LOC为根据的文献和数据已经存在。反对者们认为LOC度量与程序设计语言有关，它们不适用于设计很好且较短的程序，也不适合于非过程型语言。若在估算中使用，很难达到要求的详细程度（计划者必须在分析和设计远未完成之前就要估算出需要生产的LOC）。4203二月20233.3.4面向功能的度量面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对LOC计数。该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点FP。4303二月20233.3.4面向功能的度量面向不同应用的输入数面向不同应用的输出(报告、屏幕信息、错误信息)数不同即时查询的计数逻辑主文件(逻辑上的一组数据，可以是一个数据库的一部分，也可以是一个单独的文件)数。与系统中其他设备通过外部接口读写信息的次数使用者自行拟定一些准则来确定一个系数，带有主观性。4403二月20233.3.4面向功能的度量计算功能点，使用如下的关系式：

FP＝总计数×(0.65＋0.01×SUM(Fi))Fi（i＝1..14）是复杂性校正值，它们应通过逐一回答下一页的提问来确定。Fi的取值0..5：

0

没有影响

1

偶然的

2

适中的 3

普通的

4

重要的 5

极重要的SUM（Fi）是求和函数。4503二月20233.3.4面向功能的度量1.

系统是否需要可靠的备份和恢复？2.

是否需要数据通信？3.

是否有分布处理的功能？4.

是否性能成为关键？3.

系统是否运行在现有的高度实用化的操作环境中？6.

系统是否需要联机数据项？7.

联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。8.

主文件是否联机更新？9.

输入、输出、文件、查询是否复杂？10.

内部处理过程是否复杂？11.

程序代码是否可复用？12.

设计中是否包括了转移和安装？13.

系统是否设计成可以重复安装在不同机构中14.

系统是否设计成易修改和易使用？4603二月20233.3.4面向功能的度量一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：

生产率＝FP／PM（人月） 质量＝错误数／FP

成本＝元／FP

文档＝文档页数／FP4703二月20233.3.4面向功能的度量功能点度量的支持者认为FP与程序设计语言无关，它所依据的是在项目评估早期就可能知道的数据。反对者认为这种方法需要某些“魔术手法”：在其计算中依赖的是主观因素而不是客观实际。

信息域的数据事后很难收集，而且FP没有直接的物理意义，它只不过是一个数字。4803二月20233.3.5软件质量度量质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到的度量可作为判断设计和测试质量好坏的依据。这一类度量包括程序复杂性、有效的模块和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的缺陷数和系统的可维护性方面。4903二月20程序复杂性度量程序复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少、开发周期的长短和软件内部潜伏错误的多少。（1）代码行度量法（2）McCabe度量法（3）Halstead度量法5003二月2023代码行度量法源代码行数度量法基于两个前提：程序复杂性随着程序规模的增加不均衡地增长；控制程序规模最好是采用分而治之的办法。统计一个程序模块的源代码行数目，以源代码行数做为程序复杂性的度量。设每行代码的出错率为每100行源程序中可能有的错误数目。Thayer曾指出，程序出错率的估算范围是从0.04％～7％之间，每行代码的出错率与源程序行数之间不存在简单的线性关系5103二月2023代码行度量法Lipow指出，对于小程序，每行代码出错率为1.3%～1.8％；对于大程序，每行代码的出错率增加到2.7％～3.2％之间，这只是考虑了程序的可执行部分，没有包括程序中的说明部分。Lipow及其他研究者得出一个结论：对于少于100个语句的小程序，源代码行数与出错率是线性相关的。随着程序的增大，出错率以非线性方式增长。5203二月2023McCabe度量法McCabe度量法，又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法。它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。程序图是退化的程序流程图。流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧。5303二月20235403二月2023（2）McCabe度量法程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作，以及分支和循环的具体条件。计算环路复杂性的方法：根据图论，在一个强连通的有向图G中，环的个数由以下公式给出：

V(G)＝m－n＋p

其中，V(G)是有向图G中环路个数，m是图G中弧数，n是图G中结点数，p是图G中的强连通分量个数。在例示中，n＝11，m＝13，p＝1，则有

V(G)＝m－n＋p＝13－11＋1＝3.等于程序图中弧所封闭的区域数。5503二月2023（2）McCabe度量法环路复杂度取决于程序控制结构的复杂度。当程序的分支数目或循环数目增加时其复杂度也增加。环路复杂度与程序中覆盖的路径条数有关。环路复杂度是可加的。例如，模块A的复杂度为3，模块B的复杂度为4，则模块A与模块B的复杂度是7。5603二月2023McCabe度量法McCabe建议，对于复杂度超过10的程序，应分成几个小程序，以减少程序中的错误。这种度量的缺点是：对于不同种类的控制流的复杂性不能区分

简单IF语句与循环语句的复杂性同等看待

嵌套IF语句与简单CASE语句的复杂性是一样的

模块间接口当成一个简单分支一样处理一个具有1000行的顺序程序与一行语句的复杂性相同（3）Halstead度量法采用一组基本的度量值，这些度量值可以通过编码之后，或者提前到设计完成之后得到。预测的Halstead长度：n1表示不同的操作符个数；n2表示不同操作数的个数；则H=n1

log2n1+n2

log2n2操作符包括：算术运算符、赋值符、数组操作符、逻辑运算符、分界符，关系运算符等操作数包括变量和常量5703二月2023Halstead度量法实际的Halstead长度N1为程序中实际的操作符总个数；N2为程序中实际的操作数总个数；则H=N1+N2程序的词汇表词汇表为不同的操作符种类数和不同的操作数种类数的总和，用n表示；则n=n1+n25803二月2023（3）Halstead度量法5903二月2023SUBROUTINESORT（X，N）

DIMENSIONX（N）

IF（N.LT.2）RETURN

DO20I=2,N

DO10J=1,I

IF（X（I）.GE.X（J））GOTO10

SAVE=X（I）

X（I）=X（J）

X（J）=SAVE

10CONTINUE

20CONTINUE

RETURN

END

运算符

计数

运算对象

计数

可执行语句结束7X6

数组下标6I5

＝

5J4IF（

）2N2DO222

，2SAVE2

程序结束111.LT.1

n2＝7N2＝22.GE.1

GOTO101

n1＝10N1＝28

Halstead度量法预测的词汇量H=n1

log2n1+n2

log2n2=10log210+7log27=52.87实际的词汇量N=N1+N2=28+22=50程序的词汇表n=n1+n2=10+7=176003二月2023Halstead度量法程序量V，表明程序在“词汇上的复杂性”V=(N1+N2)log2(n1+n2)V*

表示只有两个操作符的情况程序量比率：L=V*/V

针对前一页的例子：V=(28+22)log2(10+7)=2046103二月2023Halstead度量法程序员工作量EE=V/L或E=H×log2(n1+n2)×[(n1×n2)/(2×n2)]程序的潜在错误BB=(N1+N2)log2(n1+n2)/3000B=V/3000一个程序对75个数据库表共访问1300次，对150个操作符共使用了1200次，那么预测该程序的错误数：B=(1300+1200)log2(75+150)∕3000=6.56203二月20236303二月20233.3.6使用软件度量LOC/PM(FP/PM)不能用来评价单个系统的性能，因为有许多因素都会影响生产率。人的因素：软件开发组织的规模和专长；（90%）问题因素：问题的复杂性和对设计限制，以及需求的变更次数；（40%）过程因素：使用的分析与设计技术、语言和CASE工具的有效性，及评审技术；（50%）产品因素：计算机系统的可靠性和性能需求；（140%）资源因素：CASE工具、硬件和软件资源的有效性。（40%）6403二月20233.3.6使用软件度量功能点和LOC已被公认是比较精确的软件开发工作量和成本预测工具。使用软件度量建立项目基线，管理部门能够建立改进软件工程过程的目标，从而评价项目的生产率和质量。建立基线：根据历史经验，在软件工程过程的衔接处划出一条基线，在此基线上附有一些用于度量的经验目标信息，作为工程过程评估的依据，判断工程过程的完成是否达到预想的要求。质量度量数据一旦收集到，软件开发组织就可以根据它们来调整其软件工程项目，以消除那些对软件开发有重大影响的差错产生的根源。6503二月20233.3.6使用软件度量为了帮助计划、成本和工作量估算，基线的数据应当具有下列属性：数据必须合理、精确，应避免单纯根据以往项目进行“盲目估算”；应从尽可能多的项目中收集数据；数据必须一致；基线数据的应用必须与要做估算的工作类似。6603二月2023提纲3.1项目管理过程3.2风险管理3.3软件质量和效率度量3.4软件项目估算3.5软件项目进度安排3.6项目组织结构设计3.7项目过程监控6703二月20233.4软件项目估算软件项目管理过程开始于项目策划。项目策划的首要活动就是估算(Estimation)。估算所需的资源、成本及进度。估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据。---确定基线估算本身带有风险。估算往往存在某些不确定性。现在已使用的实用技术是成本和工作量估算。6803二月20233.4.1估算的影响因素项目的复杂性较大程度地影响到估算的不确定性。项目规模越大，划分越困难，模块间的连接越复杂，估算的风险越高。估算与风险6903二月20233.4.1估算的影响因素项目的规模越大，项目划分越困难，项目元素间的连接复杂，估算风险越高；项目的结构化程度越高，功能分解和信息分层越容易，项目估算能力越强；历史信息的有效性影响估算的风险；其他风险：项目范围不确定、用户要求经常变更。7003二月20233.4.2软件项目策划项目策划目标：提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。项目策划的步骤：（1）项目策划的首要任务是确定软件范围：包括功能、性能、限制、接口和可靠性。

-成本和进度的估算都与功能有关；(采用功能分析的原因) -性能包括处理和响应时间的需求；

-限制表示外部硬件、可用存储或其他现有系统对软件的限制。

功能、性能和限制要一起估算。7103二月20233.4.2软件项目策划

-接口：软件和硬件间的接口、软件间的接口、人机接口、软件运行前后的一系列过程；必须明确通过接口的信息转换。

-可靠性：很难在策划阶段使用量化的可靠性，只能通过软件的一般性质规定一些具体要求来保障可靠性。通过这些规定的具体要求来调整工作量和成本的估算公式。7203二月20233.4.2软件项目策划（2）项目策划的第二个任务是对完成该项目所需的资源进行估算。7303二月20237403二月20233.4.2软件项目策划（3）第三步，软件成本和工作量估算-很难精确，因为变化因素太多：人、技术、环境、政治等都会影响最终成本和工作量。

-得到可靠的成本和工作量的方法有：

>估算推到项目后期进行（必须事前度量）

>使用相对简单的分解技术生成项目的成本和工作量的估算结果。

>为软件成本和工作量估算开发或配备一个经验模型；

>获取一个或更多的自动估算工具。7503二月20233.4.3利用分解技术进行估算当一个待解决的问题过于复杂时，我们可以把它进一步分解一组较小的问题，直到分解后的子问题变得容易管理为止。然后，再定于它们的特性。可以从两个不同的角度进行分解：问题分解；过程分解；首先要解决的软件规模问题。7603二月20233.4.3利用分解技术进行估算基于问题的估算。应用LOC/FP度量。作为估算变量；作为基线度量；功能分解，估算LOC/FP，导出每个功能的成本和工作量。为每个功能计数值分别计算“乐观”Sopt、‘可能’Sm、‘悲观’Spess值，

S=（Sopt+4Sm+Spess)/67703二月20233.4.3利用分解技术进行估算来自于历史基线数据基于LOC/FP进行估算7803二月20233.4.3利用分解技术进行估算基于过程的估算。根据所采用的软件过程将问题分解为一组较小的任务，估算每个任务的工作量。抽取软件功能，给出实现功能的一系列软件框架活动。估算各个软件活动所需的工作量，估算成本时应考虑劳动力的不同成本。7903二月20233.4.3利用分解技术进行估算基于直接工作量进行估算8003二月20233.4.3利用分解技术进行估算对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事，要进行一系列的估算处理。主要靠分解和类推。基本估算方法分为三类。自顶向下的估算方法

自底向上的估计法差别估计法8103二月20233.4.3利用分解技术进行估算自顶向下的估算方法这种方法的主要思想是从项目的整体出发，进行类推。估算人员根据以前已完成项目所消耗的总成本（或总工作量），推算将要开发的软件的总成本（或总工作量），然后按比例将它分配到各开发任务单元中去，再来检验它是否能满足要求。这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。8203二月20238303二月20233.4.3利用分解技术进行估算自底向上的估算方法这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级（配置管理、质量管理、项目管理）工作量.8403二月20233.4.3利用分解技术进行估算差别估计法这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按过去的实际量自顶向下进行估算，不同的部分则采用自底向上方法进行估算。这种的方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。8503二月20233.4.4专家评判技术由多位专家进行成本估算单独一位专家可能会有种种偏见。最好由多位专家进行估算，取得多个估算值。有多种方法把这些估算值合成一个估算值。一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摒弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。8603二月20233.4.4专家评判技术标准Delphi技术

①组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们进行估算。

②专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：

ai（最小）mi（可能）bi（最大），无记名地填写表格，在填表的过程中，专家互相不进行讨论但可以向组织者提问。

③组织者对专家们填在表格中的答复进行整理：

a.计算各位专家估算的期望值Ei;

b.对专家的估算结果分类摘要。

专家对此估算值另做一次估算。

④在综合专家估算结果的基础上，组织专家再次无记名地填写表格。比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。 ⑤上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。8703二月20233.4.5软件估算的经验模型软件估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。工作量是LOC/FP的函数用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。还没有一种估算模型能够适用于所有的软件类型和开发环境。应该对估算模型进行调整，以反映当前项目的情况。方法：将数据代入模型中，将实际结果与预期结果进行比较，并进行调整，循环往复。8803二月20233.4.5软件估算的经验模型估算模型的结构。典型的估算模型是通过回归分析得出，形式如下：E=A+B*（ev）C其中：A，B，C是常量，E是工作量，ev是估算变量（LOC/FP）可根据项目特性进行调整，如：复杂性、经验、环境。分析三种模型IBM模型Putnam模型COCOMO模型8903二月20IBM模型E＝3.2×L0.91D＝4.1×L0.36

＝14.47×E0.35S＝0.54×E0.6DOC＝49×L1.01L是源机器代码行数（KLOC），E

是工作量（PM），D是项目持续时间（月），S

是人员需要量（人），DOC是文档数量（页）。9003二月20IBM模型IBM模型是静态单变量模型。在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。定义:转换系数＝机器指令条数／非机器语言执行步数。如：Fortran的转换系数为4~6。9103二月20Putnam模型Putnam模型是一种动态多变量模型。适用于大型项目，但也可以应用在一些较小的软件项目中。它是假定在软件开发的整个生存期中工作量有特定的分布。大型软件项目的开发工作量分布可以用Rayleigh-Norden曲线表示。这个曲线把已交付的源代码行数与工作量和开发时间联系起来。9203二月20Putnam模型9303二月2023用Rayleigh-Norden曲线可以导出一个“软件方程”L是源代码行数（LOC），Ck是技术状态常数，因开发环境而异。K是软件开发与维护在内的整个生存期所花费的工作量（人年），td

是开发持续时间（年）9403二月20Putnam模型9503二月20COCOMO模型COnstructiveCOstModel(Boehm)结构型成本估算模型是一种精确、易于使用的成本估算方法。应用开发模式和成本驱动因子来反映项目的特性。在该模型中使用的基本量有以下几个：1.DSI(DeliverySourceInstruction):源程序行数；1KDSI=1024DSI2.MM:开发工作量；（人月）1MM=19人日=152人时=1/12人年3.TDEV:开发进度；（月）由工作量决定9603二月20COCOMO模型基本COCOMO模型：是一个静态单变量模型，它用源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。中间COCOMO模型：在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型：包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。9703二月20.1基本COCOMO模型9803二月20.2中间COCOMO模型进一步考虑15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。中间COCOMO模型的名义工作量与进度公式9903二月20.2中间COCOMO模型10003二月20.3详细COCOMO模型详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。工作量因素分级表分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。使用这些表格，可以比中间COCOMO模型更方便、更准确地估算软件开发工作量。10103二月2023软件可靠性工作量因素分级表(子系统层)10203二月2023提纲3.1项目管理过程3.2风险管理3.3软件质量和效率度量3.4软件项目估算3.5软件项目进度安排3.6项目组织结构设计3.7项目过程监控10303二月20233.5软件项目进度安排前置条件：已经选择合适的软件过程模型，确定了必须完成的软件工程任务（问题分解），估算了工作量和资源（人员数），明确了项目的结束期限，甚至已进行了风险分析。项目进度安排和跟踪创建任务网络，保证按时完成工作；为每个任务确定责任，确保履行责任；10403二月20233.5软件项目进度安排导致项目进度延误的原因是：“某天某时”。项目管理者职责：定义所有的项目任务；建立任务网络来描述任务之间的依赖关系；明确网络中的关键路径；跟踪关键任务的进展，确保能在“某天某时”发现进度延误情况。总之：需要详细的项目进度表，监督进度、控制项目。软件项目进度安排—是活动。将工作量——〉任务---〉进度表分配10503二月20233.5软件项目进度安排项目进度安排的指导原则：划分/分解：将项目划分成可管的活动、任务；相互依赖性：任务之间的依赖关系（顺序、并发）；时间分配：任务量（人月或人日），起止时间。工作量确认：确保所分配工作量<可分配工作量。确定责任：安排进度计划的每个任务都应指定人。明确结果：明确每个任务的输出结果。确定里程碑：每个任务/任务组都应与一个项目里程碑相关联。10603二月20233.5软件项目进度安排软件开发项目的进度安排有两种方式：

（1）系统最终交付日期已经确定，软件开发