Download presentation
Presentation is loading. Please wait.
1
软件项目管理 项目管理过程 软件生产率和质量的度量 软件项目的估算 软件项目计划的目标 软件成本和工作量估算 进度安排 软件项目的组织与计划
软件过程与软件过程成熟度模型
2
项目管理过程 软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。
为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件／软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。
3
启动一个软件项目 在制定软件项目计划之前，必须 考虑候选的解决方案 标明技术和管理上的要求
明确项目的目标和范围 考虑候选的解决方案 标明技术和管理上的要求 有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。
4
软件人员和用户是在系统工程步骤中确定项目的目标和范围。
目标标明了软件项目的目的但不涉及如何去达到这些目的。 范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。 当明确了软件项目的目标和范围后，就应考虑候选的解决方案。
5
有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制。
6
度量 进行度量工作，是为了了解产品开发的技术过程和产品本身。 度量产品的目的是为了提高产品的质量。 度量的作用是为了有效地定量地进行管理。
度量开发过程的目的是为了改进过程， 度量产品的目的是为了提高产品的质量。 度量的作用是为了有效地定量地进行管理。
7
为有效地度量，常常需要考虑：对于过程和产品，
合适的度量是什么？ 所收集的数据如何使用？ 用于比较个人、过程或产品的度量是否合理？ 管理人员和技术人员可利用这些度量来了解软件工程过程的实际情况和它所生产的产品质量 。
8
估算 在软件项目管理过程中关键的活动就是制定项目计划。
在做计划时必须就需要的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）做出估算。 这种估算大多是利用以前的花费做为参考而做出的。
9
如果新项目与以前的一个项目在大小上和功能上十分类似，则新项目需要工作量、开发持续时间、成本大致与那个老项目相同。
假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。 现在已有了许多用于软件开发的估算技术。其共同特点是：
10
以软件度量（以往的度量）为基础，以做出估算 项目被分解为可单独进行估算的小块
事先建立软件范围 以软件度量（以往的度量）为基础，以做出估算 项目被分解为可单独进行估算的小块 管理人员大多使用不止一种估算技术，并用一种估算技术做为另一种估算技术的交叉检查。
11
风险分析 每当新建一个程序时，总是存在某些不确定性。 用户要求是否能确切地被理解？ 在项目最后结束之前要求实现的功能能否建立？
是否存在目前仍未发现的技术难题？ 在项目出现严重误期时是否 会发生一些变更？等等。
12
风险分析对于软件项目管理是决定性的，然而现在还有许多项目不考虑风险就着手进行。
所谓风险分析实际上就是一系列风险管理步骤，其中包括风险识别、风险估计、风险优化、风险管理策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。
13
进度安排 每一个软件项目都要求制定一个进度安排，但不是所有的进度都得一样安排。 对于进度安排，需要考虑的是： 预先对进度如何计划？
工作怎样就位？ 如何识别定义好的任务？ 管理人员对结束时间如何掌握 ?
14
如何识别和监控关键路径以确保结束？ 对进展如何度量？ 如何建立分隔任务的里程碑。 软件项目的进度安排与任一个工程项目的进度安排基本相同。首先识别一组项目任务，再建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，制定进度时序。
15
追踪和控制 一旦建立了开发进度安排，就可以开始着手追踪和控制活动。 由项目管理人员负责追踪在进度安排中标明的每一个任务。
如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。
16
还可对资源重新定向 对任务重新安排 （做为最坏的结果）可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。
17
软件生产率和质量的度量 生产率与质量的度量是以投入工作量为依据的软件开发活动的度量和开发成果质量的度量。 为什么要对软件进行度量
面向规模的度量 面向功能的度量 软件质量的度量 在软件工程过程中使用度量
18
为什么要对软件进行度量 ① 表明软件产品的质量； ② 弄清软件开发人员的生产率；
③ 给出使用了新的软件工程方法和工具所得到的（在生产率和质量两方面）的效益； ④ 建立项目估算的“基线”； ⑤ 帮助调整对新的工具和附加培训的要求。
19
度量的方式 在物理世界中的度量有两种方式。 间接度量（例如，用次品率来度量生产出的螺栓质量）。 软件度量也同样分为两类：直接度量与间接度量。
直接度量（例如，度量一个螺栓的长度）； 间接度量（例如，用次品率来度量生产出的螺栓质量）。 软件度量也同样分为两类：直接度量与间接度量。
20
软件工程过程的直接度量包括所投入的成本和工作量。
软件产品的直接度量包括产生的代码行数（LOC）、执行速度、存储量大小、在某种时间周期中所报告的差错数。 软件产品的间接度量包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。
21
软件度量域的分类
22
面向规模的度量 面向规模的度量是对软件和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某些信息。
该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。
23
面向规模的数据表格
24
根据数据表格可以对所有的项目计算出平均值：
生产率 ＝ KLOC／PM（人月） 质量 ＝ 错误数／KLOC 成本 ＝ 元／LOC 文档 ＝ 文档页数／KLOC
25
面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量。
面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对 LOC计数。 该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点 FP。
26
面向功能的数据表格
27
功能点计算 确定五个信息域的特征，并在表格中相应位置给出计数。 (1) 用户输入数：各个用户输入是面向不同应用的输入数据。
(2) 用户输出数：各个用户输出是面向应用的输出信息，包括报告，屏幕信息，错误信息等。在报告中的各个数据项不应再分别计数。
28
(3) 用户查询数：查询是一种联机的交互操作，每次询问/响应具备应计数。
(4) 文件数：每一个逻辑主文件都应计数。逻辑主文件是指逻辑上的一组数据，可以是一个大数据库的一部分，可以是一个单独的文件。 (5) 外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。
29
一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。
一个信息域是简单的、平均的还是复杂的，由使用功能点方法的机构自行确定，从而计算出加权计数。 计算功能点，使用如下的关系式： FP ＝ 总计数×( 0.65＋ + 0.01×SUM ( Fi ) ) 总计数是所有加权计数项的和
30
Fi（i＝1..14）是复杂性校正值，它们应通过逐一回答如下提问来确定。
0 没有影响 1 偶然的 2 适中的 3 普通的 4 重要的 5 极重要的 SUM（Fi）是求和函数。
31
复杂性校正值 Fi 1. 系统是否需要可靠的备份和恢复？ 2. 是否需要数据通信？ 3. 是否有分布处理的功能？ 4. 是否性能成为关键？
5. 系统是否运行在既存的高度实用化的操作环境中？ 6. 系统是否需要联机数据项？ 7. 联机数据项是否需要建立多重窗口
32
显示和操作，以处理输入处理。 8. 主文件是否联机更新？ 9. 输入、输出、文件、查询是否复杂？ 10. 内部处理过程是否复杂？ 11. 程序代码是否可复用？ 12. 设计中是否包括了转移和安装？ 13. 系统是否设计成可以重复安装在不同机构中 14. 系统是否设计成易修改和易使用？
33
一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：
生产率 ＝ FP／PM（人月） 质量 ＝ 错误数／FP 成本 ＝ 元／FP 文档 ＝ 文档页数／FP
34
功能点度量是为了商用信息系统应用而设计的。
特征点度量（Feature Points）可以用于系统和工程软件应用 特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。
35
为了计算特征点，可以象功能点计算那样，对信息域值进行计数和加权。此外，特征点度量要对一个新的软件特征“算法”进行计数。
计算特征点可使用一个计算表格。 对于每一个度量参数只使用一个权值，并且使用 FP＝总计数×( 0.65＋0.01×SUM ( Fi ) ) 来计算总的特征点值。
36
特征点度量计算表格
37
软件质量的度量 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。
在软件交付之前得到的度量可作为判断设计和测试质量好坏的依据。这一类度量包括程序复杂性、有效的模块性和总的程序规模。 在软件交付之后的度量则把注意力集中于还未发现的差错数和系统的可维护性方面。
38
使用得最广泛软件质量的事后度量包括正确性、可维护性、完整性和可使用性。
(1) 正确性：一个程序必须正确地运行，并为它的用户提供某些输出。正确性要求软件执行所要求的功能。正确性的度量是每千代码行(KLOC)的差错数，其中将差错定义为已被证实是不符合需求的缺陷。
39
(2) 可维护性：软件维护比其它的软件工程活动需要更多的工作量。还没有一种方法可以直接度量可维护性，因此必须采取间接度量。
有一种简单的面向时间的度量，叫做平均变更等待时间MTTC。 这个时间包括分析变更要求、设计适当的修改、实现变更并测试、及把变更发送给所有的用户。 一个可维护的程序与不可维护的程序相比，应有较低的MTTC。
40
(3) 完整性：完整性度量一个系统抗拒对它的安全性攻击（事故的和人为的）的能力。软件的所有三个成分程序、数据和文档都会遭到攻击。
度量完整性，需要定义两个附加的属性：危险性和安全性。 危险性是特定类型的攻击将在一给定时间内发生的概率，安全性是排除特定类型攻击的概率。
41
一个系统的完整性可定义为完整性＝∑( 1－危险性×( 1－安全性) )
其中，对每一个攻击的危险性和安全性都进行累加。 (4) 可使用性：如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。可使用性量化“用户友好性”，并依据以下四个特征进行度量：
42
为学习系统所需要的体力上的和智力上的技能；
为达到适度有效使用系统所需要的时间； 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值； 用户角度对系统的主观评价（可以通过问题调查表得到）。
43
在软件工程过程中使用度量 建立基线 为了将LOC和FP用于软件估算技术中，必须建立历史数据基线。
根据历史经验，在软件工程过程的衔接处划出一条基线，在此基线上附有一些用于度量的经验目标信息，作为工程过程评估的依据，判断工程过程的完成是否达到预想的要求。
44
质量度量数据一旦收集到，软件开发组织就可以根据它们来调整其软件工程项目，以消除那些对软件开发有重大影响的差错产生的根源。
大多数软件开发人员都希望了解：哪些用户需求可能会变更？系统中哪些模块容易出错？对每一个模块要做多少测试？在测试时能够预计多少错误？如果能收集到相关的度量数据，就能确定这些问题的答案。
45
软件项目的估算 软件项目管理过程开始于项目计划。 在做项目计划时，第一项活动就是估算。
在做估算时往往存在某些不确定性，使得软件项目管理人员无法正常进行管理而导致产品迟迟不能完成。 现在已使用的实用技术是时间和工作量估算。
46
估算对风险的影响
47
项目的复杂性对于增加软件计划的不确定性影响很大。复杂性越高，估算的风险就越高。
项目的规模对于软件估算的精确性和功效影响也比较大。随着软件规模的扩大，问题分解会变得更加困难。项目的规模越大，开发工作量越大，估算的风险越高。
48
项目的结构化程度也影响项目估算的风险。随着结构化程度的提高， 进行精确估算的能力就能提高，而风险将减少。
历史信息的有效性也影响估算的风险。对过去的项目进行综合的软件度量，可借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。
49
如果对软件项目的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。
计划人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义。
50
软件项目计划的目标 软件项目管理人员在开发工作一开始需要进行定量估算。
软件项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。 这些估算应当在软件项目开始时的一个有限的时间段内做出，并且随着项目的进展定期进行更新。
51
软件的范围 软件范围包括功能、性能、限制、接口和可靠性。
估算开始时，应对软件的功能进行评价，对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分解。
52
性能的考虑包括处理和响应时间的需求。 约束条件则标识产品成本、外部硬件、可用存储或其它现有系统对软件的限制。 功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。
53
还要叙述某些质量因素（例如，给出的算法是否容易理解等）。
软件与其它系统元素是相互作用的。要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为： 运行软件的硬件（如处理机与外设）及间接受软件控制的设备（如机器、显示器）;
54
对于每一种情况，都必须清楚地了解通过接口的信息转换。
必须与新软件链接的现有的软件（如数据库存取例程、子程序包、操作系统）; 通过终端或其它输入／输出设备使用该软件的人; 该软件运行前后的一系列操作过程。 对于每一种情况，都必须清楚地了解通过接口的信息转换。
55
软件开发中的资源 软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。 软件开发所需的资源有 现成的用以支持软件开发的工具
──硬件工具及软件工具 最基本的资源 ──人
56
软件开发中的资源
57
通常，对每一种资源，应说明以下四个特性：
（1）资源的描述; （2）资源的有效性说明; （3）资源在何时开始需要; （4）使用资源的持续时间。 最后两个特性统称为时间窗口。
58
1. 人力资源 在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。 计划人员首先估算范围并选择为完成开发工作所需要的技能。还要在组织和专业两方面做出安排。
59
对于一些规模较小的项目（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。
对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。下面是各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线。
61
2. 硬件资源 硬件是作为软件开发项目的一种工具而投入的。 （1）宿主机（Host）─ 软件开发时使用的计算机及外围设备； （2）目标机（Target）─ 运行已开发成功软件的计算机及外围设备； （3）其它硬件设备 ─ 专用软件开发时需要的特殊硬件资源；
62
3. 软件资源 软件工程人员在软件开发期间使用了许多软件工具来帮助开发。这种软件工具集叫做计算机辅助软件工程（CASE）。 （1）业务系统计划工具集 （2）项目管理工具集 （3）支援工具──文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及配置管理工具。
63
（4）分析和设计工具 （5）编程工具 （6）组装和测试工具 （7）原型化和模拟工具 （8）维护工具 （9）框架工具──这些工具能够提供建立集成项目支撑环境（IPSE）的框架。
64
4. 软件复用性及软件部件库 为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部件库。
65
软件成本和工作量的估算 软件成本和工作量的估算中变化的东西太多，人、技术、环境、政治，都会影响软件最终成本和工作量。
软件项目的估算能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。 成本估算必须“事前”给出。时间越久，了解得越多，估算中出现的严重误差就越少。
66
分解技术 当一个待解决的问题过于复杂时，我们可以把它进一步分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。
67
LOC和FP估算 在软件项目估算中，在两个方面使用了LOC和FP数据： 把LOC和FP数据当做一个估算变量，用于量度软件每一个元素的规模。
68
LOC和FP的共性在于: 给出一个有界的软件范围的叙述 由此叙述把软件分解成一些小的可分别独立进行估算的子功能
把基线生产率度量(如LOC／PM或FP／PM) 用做特定的估算变量，导出子功能的成本或工作量 综合子功能的估算得到整个项目的总估算。
69
项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。
利用历史数据或凭实际经验（当其它的方法失效时），对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值。记作a、m、b。 接着计算LOC或FP的期望值 E。 E ＝ （a＋4m＋b）／6
70
所有子功能的总估算变量值除以相应于该估算变量的平均生产率度量得到项目的总工作量。
例如，若假定总的FP估算值是310，基于过去项目的平均FP生产率是5.5FP／PM，则项目的总工作量是： 工作量 ＝ 310／5.5 ＝ 56 PM 作为LOC和FP估算的实例，考察一个为CAD应用而开发的软件包。
71
系统定义评审指明，软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标器、数字化仪、高分辩率彩色显示器和激光打印机。
在这个实例中，使用LOC做为估算变量。 根据系统规格说明, 软件范围的初步叙述如下
72
“软件将从操作员那里接收2维或3维几何数据。 操作员通过用户界面与 CAD系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其它支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并与能各种外部设备，包括鼠标器、数字化仪、激光打印机和绘图仪交互。”
73
经过分解, 识别出下列主要软件功能： 通过分解，可得到如下估算表 用户界面和控制功能 二维几何分析 三维几何分析 数据库管理
计算机图形显示功能 外设控制PC 设计分析模块 通过分解，可得到如下估算表
74
估算表
75
软件开发成本估算 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不包括原材料和能源的消耗，主要是人的劳动的消耗。
人的劳动消耗所需代价就是软件产品的开发成本。 软件产品开发成本的计算方法不同于其它物理产品成本的计算。
76
软件的开发成本是以一次性开发过程所花费的代价来计算的。
软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的。
77
软件开发成本估算方法 对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事，要进行一系列的估算处理。主要靠分解和类推。
基本估算方法分为三类。 自顶向下的估算方法 自底向上的估计法 差别估计法
78
自顶向下的估算方法 这种方法的主要思想是从项目的整体出发，进行类推。
估算人员根据以前已完成项目所消耗的总成本（或总工作量），推算将要开发的软件的总成本（或总工作量），然后按比例将它分配到各开发任务单元中去，再来检验它是否能满足要求。
80
这种方法的优点是估算工作量小，速度快。 缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。
81
自底向上的估计法 这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。 它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量.
82
差别估计法 这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。 类似的部分按实际量进行计算，不同的部分则采用相应方法进行估算。
83
专家判定技术 由多位专家进行成本估算 单独一位专家可能会有种种偏见，最好由多位专家进行估算，取得多个估算值。
有多种方法把这些估算值合成一个估算值。
84
一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。
一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摈弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。
85
Deiphi技术 标准Deiphi技术 组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们进行估算。
专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：ai (最小), mi (可能), bi (最大), 无记名地填写表格
86
组织者对专家们填在表格中的答复进行整理：
a. 计算各专家估算的期望值 Ei; b. 对专家的估算结果分类摘要。 专家对此估算值另做一次估算。 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 比较两次估算的结果。若差异很大，要通过查询找出差异的原因。
87
上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。
最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。
88
软件开发成本估算的经验模型 软件开发成本估算是依据开发成本估算模型进行估算的。
开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。 用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。
89
IBM模型 E ＝ 5.2×L0.91 D ＝ 4.1×L0.36 ＝ 14.47×E0.35 S ＝ 0.54×E0.6
DOC ＝ 49×L1.01 L 是源代码行数 (KLOC)，E 是工作量 (PM)，D 是项目持续时间(月)，S 是人员需要量 (人)，DOC是文档数量 (页)。
90
IBM模型是静态单变量模型。 在此模型中，一般指一条机器指令为一行源代码。 一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。 对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。
91
定义: 转换系数＝机器指令条数／非机器语言执行步数。
转换系数表
92
Putnam模型 Putnam模型是一种动态多变量模型。适用于大型项目，但也可以应用在一些较小的软件项目中。
它是假定在软件开发的整个生存期中工作量有特定的分布。 大型软件项目的开发工作量分布可以用Rayleigh-Norden曲线表示。
94
用Rayleigh-Norden曲线可以导出一个“软件方程”
td 是开发持续时间 (年)， K是软件开发与维护在内的整个生存期所花费的工作量 (人年)，L是源代码行数 (LOC)，Ck是技术状态常数，因开发环境而异。
95
技术状态常数Ck的取值
96
COCOMO模型 （COnstructive COst MOdel）
结构型成本估算模型是一种精确、易于使用的成本估算方法。 DSI（源指令条数）定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI＝1000DSI。
97
MM（度量单位为人月）表示开发工作量。 TDEV（度量单位为月）表示开发进度。它由工作量决定。 软件开发项目的分类 软件开发项目的总体类型: 组织型 嵌入型 半独立型
98
COCOMO模型的分类 COCOMO模型按其详细程度分成三级：
基本COCOMO模型是静态单变量模型，用源代码行数(LOC) 为自变量的经验函数计算软件开发工作量。
99
中间COCOMO模型在用LOC为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。
详细COCOMO模型包括中间CO COMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。
100
基本COCOMO模型 基本COCOMO模型的工作量和进度公式
101
中间COCOMO模型 进一步考虑15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。 中间COCOMO模型的名义工作量与进度公式如下所示。
102
中间COCOMO模型的名义工作量 与进度公式
103
15种影响软件工作量的因素 fi 产品因素：软件可靠性、数据库规模、产品复杂性 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验 项目因素：现代程序设计技术、软件工具的使用、开发进度限制
105
此时，工作量计算公式改成 例1. 一个32KDSI的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有 MM ＝ 3.0（32）1.12 ＝ 146 又查表知 f1＝0.75，其它 fi＝1.00，则最终有MM ＝ 146×0.75 ＝ 110.
106
例14. 一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。
程序名义工作量 MM ＝ 2.8 (10)1.20 ＝ 44.38（MM） 程序实际工作量 MM ＝ 44.38× ＝ 44.38×1.17 ＝ 51.5（MM）
108
开发所用时间 TDEV ＝ 2.5 (51.5)0.32 ＝ 8.9 （月） 如果分析员与程序员的工资都按每月6,000美元计算，则该项目的开发人员的工资总额为 51.5×6,000 ＝ 309,000 （美元） 做为对比，现在用IBM模型计算： PM ＝ 5.2 (10)0.91 ＝ （人月） D ＝ 4.1 (10)0.38 ＝9.84 （月） S ＝ 0.54 (42.27)0.60 ＝ 5.1 (人)
109
详细COCOMO模型 详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。
工作量因素分级表分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。
110
例如，关于软件可靠性（RELY）要求的工作量因素分级表（子系统层），如表所示。
使用这些表格，可以比中间COCO MO模型更方便、更准确地估算软件开发工作量。
111
软件可靠性工作量因素分级表(子系统层)
112
进度安排 软件开发项目的进度安排有两种方式： （1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成； （2）系统最终交付日期只确定了大致的年限，最後交付日期由软件开发部门确定。
113
进度安排落空，会导致市场机会的丧失，使用户不满意，而且也会导致成本的增加。
因此，在考虑进度安排时，要把工作量与花费时间联系起来，合理分配工作量, 利用进度安排的有效分析方法严密监控软件开发的进展情况，使软件开发进度不致拖延。
114
软件开发小组人数与软件生产率的关系 当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。
115
若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有 n 个人，每两人之间都需要通信，则总的通信路径有 n(n-1)/2 (条)。
116
设一个人单独开发软件，生产率是5000行／人年。若 4 个人组成一个小组共同开发这个软件，则需要 6条通信路径。若在每条通信路径上耗费的工作量是 250 行／人年。则小组中每个人的软件生产率降低为
5000－6×250／4 ＝ = 5000－375 ＝ = 行／人年。
117
从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。
但是，开发小组不宜太大，成员之间避免太多的通信路径。 在开发进程中，切忌中途加人，避免太多的生产率损失。
118
任务的确定与并行性 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。
软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。 软件工程项目的并行性提出了一系列的进度要求。
120
因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。
项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。
121
制定开发进度计划 40－20－40规则 在整个软件开发过程中，编码工作量仅占 20％，编码前工作量占40％，编码后工作量占 40％。
40－20－40 规则只应用来做为 一个指南。实际的工作量分配比例必须按照各项目的特点来决定。
122
COCOMO模型 开发进度TDEV与工作量MM的关系： TDEV ＝ a（MM）b 如果想要缩短开发时间，或想要保证开发进度，必须考虑影响工作量的那些因素。按可减小工作量的因素取值。
124
按此比例确定各个阶段工作量的分配，从而进一步确定每一阶段所需的开发时间，然后在每个阶段，进行任务分解，对各个任务再进行工作量和开发时间的分配。
125
进度安排的方法 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。
为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。 在图示方法中，必须明确标明：
126
各个任务完成标志（即○文档编写和△评审）； 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；
各个任务的计划开始时间，完成时间； 各个任务完成标志（即○文档编写和△评审）； 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况； 完成各个任务所需的物理资源和数据资源。
127
(1) 甘特图（Gantt Chart） 在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。
129
(2) PERT技术和CPM方法 PERT技术叫做计划评审技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。 它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。
130
三个模块开发的网络图
131
通常用两张表来定义网络图。 一张表给出与一特定软件项目有关的所有任务（也称为任务分解结构WorkBreakdown Structure）; 另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表RestrictionList）。 PERT技术和CPM方法都为项目计划人员提供了一些定量的工具。
132
确定关键路径，即决定项目开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。
应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。 计算边界时间，以便为具体的任务定义时间窗口。
133
项目的追踪和控制 软件项目管理一项重要工作就是在 项目实施过程中进行追踪和控制：
定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。 评价在软件工程过程中所产生的所有评审的结果。 确定由项目的计划进度所安排的可能选择的正式的里程碑。
134
比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。
非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。 当问题出现的时候， 项目管理人员必须实行控制以尽快地排解问题。
135
软件项目的组织与计划 制定计划 软件项目组织的建立 人员配备
136
制定计划 软件开发项目的计划涉及到实施项目的各个环节，带有全局性质。 计划的合理性和准确性往往关系着项目的成败。
计划应力求完备。要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确。尽可能提高所依据数据的可靠程度。
137
1. 制定计划目标和进行风险分析 制定计划的目的就是要回答：这个软件项目的范围是什么？需要哪些资源？花费多少工作量？要用的成本有多少？以及进度如何安排等等一系列问题。 这步工作应当以系统计划为基础，以系统规格说明为依据。
138
在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以往的开发经验做出估算，很难达到准确。
从估算出发，项目必然带有一定的风险。估算的准确性越差，风险也就越大。研制的软件项目越复杂，规模越大，结构化程度越低，资源、成本、进度等因素的不确定性越大，承担这一项目所冒的风险也越大。
139
组织软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，只有这样才能避免出现灾难性的后果，取得项目预期的成果。
140
2. 软件计划的类型 针对不同工作目标，软件计划有：
项目实施计划（软件开发计划） 这是软件开发的综合性计划，通常应包括任务、进度、人力、环境、资源、组织等多个方面。 质量保证计划 把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动。
141
软件测试计划 规定测试活动的任务、测试方法、进度、资源、人员职责等。
文档编制计划 规定所开发项目应编制的文档种类、内容、进度、人员职责等。 用户培训计划 规定对用户进行培训的目标、要求、进度、人员职责等。
142
综合支持计划 规定软件开发过程中所需要的支持，以及如何获取和利用这些支持。
软件分发计划 软件开发项目完成后，如何提供给用户。
143
3. 项目实施计划中任务的划分 如何进行工作划分是实施计划首先应解决的问题。常用的计划结构有：
阶段项目计划 按软件生存期，把开发工作划分为若干阶段，对每一阶段工作做出计划。再把每一阶段工作分解为若干任务，做出任务计划。还要把任务细分为若干步骤，做出步骤计划。
144
任务分解结构 按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构。进一步把工作内容、所需工作量、预计完成的期限也规定下来。 任务责任矩阵 在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示任务的分工和责任。
145
任务分解结构
146
任务责任矩阵
147
软件项目组织的建立 开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。 1、组织原则
(1) 尽早落实责任： 在软件项目工作开始时，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。
148
（2）减少接口： 一个组织的生产率随完成任务中存在的通信路径数目增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。
（3）责权均衡： 软件经理人员所负的责任不应比委任给他的权力还大。
149
2. 组织结构的模式 （1）按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。
150
（2）按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。
151
（3）矩阵形模式 这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个 专门组，又参加某一项目的工作。
153
3.程序设计小组的组织形式 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。 （1）主程序员制小组 小组的核心由一位主程序员(高级工程师)、二至五位技术员、一位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实现项目中的关键部分。
154
技术员负责项目的具体分析与开发，文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。
主程序员制小组还可以由一些专家(如通信专家或数据库设计专家)、辅助人员(如打字员和秘书)、软件资料员协助工作。
155
（2）民主制小组 在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。工作目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性。有人认为这种组织形式适合于研制时间长、开发难度大的项目。
156
（3）层次式小组 在层次式小组中，组内人员分为 三级：组长（项目负责人）一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。 他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。
157
这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。
这种组织方式比较适合于大型软件项目的开发。
159
人员配备 如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括： 按不同阶段适时任用人员 恰当掌握用人标准。
160
1. 项目开发各阶段所需人员 一个软件项目完成的快慢，取决于参与开发人员的多少。 在开发的整个过程中，多数软件项目是以恒定人力配备的。
实际人力需求与开发进度的关系如下图中的曲线所示。
162
按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。
如果恒定地配备人力，在开发初期将会有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。 恒定地配备人力将浪费人力资源。
163
2. 配备人员的原则 重质量 软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。
重质量 软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。 重培训 培养所需技术人员和管理人员是有效解决人员问题的好方法。 双阶梯提升 人员提升应分别按技术职务和管理职务进行，不能混在一起。
164
3. 对项目经理人员的要求 软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。他应具有以下能力：
把用户提出的非技术性要求加以整理提炼, 以技术说明书的形式转告给分析员和测试员。 能说服用户放弃一些不切实际的要求, 以保证合理的要求得以满足。
165
能够把表面上似乎无关的要求集中在一起, 归结为 “需要什么”, “要解决什么问题”。这是一种综合问题的能力。
要懂得心理学, 能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强, 乐 于接受，并受到启发。
166
4. 评价人员的条件 软件项目中人的因素越来越受重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。
牢固掌握计算机软件的基本知识和技能。 善于分析和综合问题，具有严密的逻辑思维能力。
167
工作踏实、细致, 不靠碰运气，遵循标准和规范，具有严格的科学作风。
工作中表现出有耐心、有毅力、有责任心。 善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。 具有良好的书面和口头表达能力。
168
软件过程与过程成熟度模型 软件过程是软件生存期中的一系列相关过程。 过程是活动的集合； 活动是任务的集合； 任务是将输入变换为输出的操作；
活动的执行可以是顺序的，重复的，并行的、嵌套的；
169
为了得到满足要求的软件产品，不但需要有好的开发方法，还需要有好的工程支持和工程管理。
170
基本过程 获取过程 供应过程 开发过程 运行过程 维护过程
171
获取过程 是需方为了获得一个软件产品所进行的一系列活动：该过程从为获取该软件产品的需求定义开始，经过招标准备，合同的准备和修改，对供方的监督，直到验收完成。
172
供应过程 是供方为向需方提供软件产品所进行的一系列活动：该过程从理解软件的需求开始，经过投标准备，签订合同，制定计划，实施计划及控制，进行评审和评价，直至完成交付。
173
开发过程 是软件开发者根据合同开发和交付软件的一系列活动。包括的活动有： 过程的实施准备 系统需求分析 系统结构设计 软件需求分析
软件体系结构设计 软件详细设计
174
程序编码和单元测试 软件集成 软件确认测试 系统集成 系统确认测试 软件安装 软件验收支持
175
运行过程 软件开发完成后，软件从开发环境转移到用户的实际运行环境。在运行时对用户的要求提供帮助和咨询，对运行效果进行评价。
实施过程的准备 运行测试 系统向实际运行环境转移 系统运行
176
对用户运行的支持 系统运行评价 用户运行评价
177
维护过程 过程的实施准备 问题分析和修改分析 修改的实施 对维护进行评审／验收 移植 软件退役
178
支持过程 文档过程 配置管理过程 质量保证过程 验证过程 确认过程 联合评审过程 审计过程 问题解决过程
179
文档过程 文档过程是一个记录由某一过程或活动所产生的信息的过程。它由以下活动组成: 过程的实施准备 设计与开发 制作与发行 维护
180
配置管理过程 过程的实施准备 配置的确定 配置的控制 配置情况报告 配置的评价 发行管理和提交
181
质量保证过程 这是一个为使软件过程和软件产品符合规定需求，并按预定计划按时完成提供适当保证的过程。 软件产品的质量保证
过程的实施准备 软件产品的质量保证 软件过程的质量保证
182
验证过程 确定系统或软件的需求是否完备和正确, 以及每一阶段的软件产品是否达到前一阶段对它的要求和条件。 代码验证 集成验证
过程的实施准备 验证 合同验证 过程验证 需求验证 设计验证 代码验证 集成验证 文档验证
183
确认过程 确认需求和最终建立的系统或软件是否满足原计划的特定应用。 过程的实施准备 确认
184
联合评审过程 这是评价项目的某个活动或阶段的执行情况, 以及产品是否合乎要求的过程。 过程的实施准备 项目管理评审 技术评审
185
审计过程 这一过程是要审计确定合作的另一方遵照需求、计划合同到什么程度的过程。 过程的实施准备 审计
186
问题解决过程 这是一个用于分析和排除在开发、运行、维护或其它过程中发现的问题和不一致的过程。 过程实施准备 问题解决
187
组织过程 管理过程 基础设施过程 改进过程 培训过程
188
管理过程 管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。
管理的对象是进度、系统规模及工作量估算、经费、组织机构很人员、风险、质量、作业和环境配置等。
189
过程的实施准备 管理计划的制定 计划的实施与控制 评审和评价计划的完成程度 编写管理文档。
190
基础设施过程 该过程建立、维护各个过程所需的基础设施。 基础设施包括硬件、软件、工具、技术、标准, 以及开发、运行、维护所需的设施。
191
改进过程 该过程建立、评估、度量、控制和改进软件生存期的过程。主要活动是制定一组组织计划, 评估相关过程, 实施分析、改进过程。
192
培训过程 该过程为系统或软件产品提供人员培训。主要活动有制定所需人员用人计划和培训计划, 开发培训资料, 实施培训活动等。
193
软件过程的度量 软件过程成熟度 是指对过程计划或定义水平、过程实施水平、过程管理和控制水平、过程改善潜力等指标的综合评价。
分为 5 级: 初始级、可重复级、可定义级、可管理级、可优化级。
194
评估软件过程时遵循的原则 在很大程度上，软件产品的质量取决于生产该产品的过程质量。 软件过程是一个可管理、可测量和可改进的过程。 软件过程的质量受其支持技术的影响。 用于软件工程的技术水平应与过程的成熟度相适应。
195
1 初始级 特点 过程执行杂乱无序 关键问题 项目计划管理、配置管理、软件质量保证 达标标准 过程活动无一定秩序，开发过程的可重复性差
196
2 可重复级 特点 过程管理工作依赖管理人员的技能 关键问题 培训、技术评审、标准
2 可重复级 特点 过程管理工作依赖管理人员的技能 关键问题 培训、技术评审、标准 达标标准 使项目管理处于严格控制之下，包括严格的项目计划和追踪、子合同管理、需求变更和产品基线控制
197
3 可定义级 特点 过程可定义、可执行 关键问题 过程度量、过程分析、 质量计划
3 可定义级 特点 过程可定义、可执行 关键问题 过程度量、过程分析、 质量计划 达标标准 定义一个适合该组织的软件过程，有正规的文档化的规范，并能根据不同项目的要求裁剪和优化这个软件过程
198
4 可管理级 特点 过程成为可度量的 关键问题 改善技术、问题分析、 防止出错
4 可管理级 特点 过程成为可度量的 关键问题 改善技术、问题分析、 防止出错 达标标准 为定义好的过程建立一套详细的度量机制，为产品和过程设立质量目标，度量软件过程和产品
199
5 可优化级 特点 通过反馈来改善过程 关键问题 自动化、反馈技术
5 可优化级 特点 通过反馈来改善过程 关键问题 自动化、反馈技术 达标标准 用第 4 级建立的度量机制，不断地指导过程改善，技术革新和防止出错
200
关键过程领域KPA （Key Process Area）
除去初始级以外，其它 4 级都有若干个引导软件机构改进软件过程的要点，称为关键过程领域。 每一个关键过程领域是一组相关的活动，成功地完成这些活动，将会对提高过程能力起重要作用。
201
关键过程域
Similar presentations
