情景 3.1 软件项目管理

1. 情景3.1 软件项目管理

2. 大型软件工程项目的失败---- 才使人们逐渐认识到软件项目管理的重要性和特殊性。 失败的原因---- 不是软发工程师无能，而主要是管理不善。 所谓管理---- 就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理---- 先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。 软件项目管理---- 从一组项目计划活动开始，其基础是工作量估算和完成期限估算。

3. 13.1 估算软件规模 • 13.1.1 代码行技术 • 代码行技术是比较简单的定量估算软件规模的方法。 • 为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值，再用下式计算程序规模的估计值 • L = • 单位是代码行数（LOC），或是千行代码数（KLOC）

4. 代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 代码行技术的缺点： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。 为了克服代码行技术的缺点，人们又提出了功能点技术。

5. 13.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性： （1） 输入项数(Inp) ： 用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。 （2） 输出项数(Out) ： 软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。 （3） 查询数(Inq) ： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。 （4） 主文件数(Maf) ： 逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。 （5） 外部接口数(Inf) ： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。

6. 2. 估算功能点的步骤 （1） 计算未调整的功能点数UFP 首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。 然后，用下式计算未调整的功能点数UFP： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf 其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。

7. (2) 计算技术复杂性因子TCF 这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素，并用Fi(1≤i≤14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI： DI= 技术复杂性因子TCF由下式计算： TCF=0.65+0.01×DI 因为DI的值在0~70之间，所以TCF的值在0.65~1.35之间。

8. （3） 计算功能点数FP 用下式计算功能点数FP： FP=UFP×TCF 功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。

9. 13.2 工作量估算 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。 支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。

10. 13.2.1 静态单变量模型 这类模型的总体结构形式如下： E=A+B×(ev)C 其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。下面给出几个典型的静态单变量模型。 1. 面向KLOC的估算模型 (1) Walston_Felix模型: E=5.2×(KLOC)0.91 (2) Bailey_Basili模型: E=5.5+0.73×(KLOC)1.16 (3) Boehm简单模型: E=3.2×(KLOC)1.05 (4) Doty模型（在KLOC>9时适用）: E=5.288×(KLOC)1.047

11. 2. 面向FP的估算模型 (1) Albrecht & Gaffney模型 E=-13.39+0.0545FP (2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP 从上面列出的模型可以看出，对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。

12. 13.2.2 动态多变量模型 动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=(LOC×B0.333/P)3×(1/t)4(13.2) 其中， E是以人月或人年为单位的工作量； t是以月或年为单位的项目持续时间； B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5~15），B=0.16,对于超过70 KLOC的程序，B=0.39; P是生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用的程序设计语言的级别； 软件环境的状态； 软件项目组的技术及经验； 应用系统的复杂程度。 开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。 从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。

13. COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这3个层次的估算模型分别是 （1） 应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。 （2） 早期设计模型。这个模型适用于体系结构设计阶段。 （3） 后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。 13.2.3 COCOMO2模型 COCOMO是构造性成本模型（constructive cost model)的英文缩写。 1981年Boehm在《软件工程经济学》中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。

14. 下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： E=(13.3) 其中: E是开发工作量（以人月为单位）， A是模型系数， KLOC是估计的源代码行数（以千行为单位）， B 是模型指数， fi(i=1~17)是成本因素。 每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。

15. 13.3 进度计划 • 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。 • 软件项目的进度安排是通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。 • 进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。

16. 软件开发小组人数与软件生产率的关系 • 当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。

17. 若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有 n个人，每两人之间都需要通信，则总的通信路径有 n(n-1)/2 (条)。

18. 设一个人单独开发软件，生产率是5000行／人年。若4 个人组成一个小组共同开发这个软件，则需要 6条通信路径。若在每条通信路径上耗费的工作量是 250 行／人年。则小组中每个人的软件生产率降低为 5000－6×250／4 ＝ = 5000－375 ＝ = 4625 行／人年。

19. 从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。 • 但是，开发小组不宜太大，成员之间避免太多的通信路径。 • 在开发进程中，切忌中途加人，避免太多的生产率损失。

20. 任务的确定与并行性 • 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。 • 软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。 • 软件工程项目的并行性提出了一系列的进度要求。

22. 因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。 • 项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。

23. 制定开发进度计划 • 40－20－40规则 • 在整个软件开发过程中，编码工作量仅占 20％，编码前工作量占40％，编码后工作量占 40％。 • 40－20－40 规则只应用来做为 一个指南。实际的工作量分配比例必须按照各项目的特点来决定。

24. 估算开发时间T的方程: (1) Walston_Felix模型 T=2.5E0.35 (2) 原始的COCOMO模型 T=2.5E0.38 (3) COCOMO2模型 T=3.0E0.33+0.2×(b-1.01) (4) Putnam模型 T=2.4E1/3 其中， E是开发工作量（以人月为单位）， T是开发时间（以月为单位）。

25. 进度安排的方法 • 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。 • 为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。 • 在图示方法中，必须明确标明：

26. 各个任务的计划开始时间，完成时间； • 各个任务完成标志（即○文档编写和△评审）； • 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况； • 完成各个任务所需的物理资源和数据资源。

27. (1) 甘特图（Gantt Chart） • 在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。

29. (2) PERT技术和CPM方法 • PERT技术叫做计划评审技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。 • 它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。

30. 三个模块开发的网络图

31. 通常用两张表来定义网络图。 • 一张表给出与一特定软件项目有关的所有任务（也称为任务分解结构WorkBreakdown Structure）; • 另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表RestrictionList）。PERT技术和CPM方法都为项目计划人员提供了一些定量的工具。

32. 确定关键路径，即决定项目开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。确定关键路径，即决定项目开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。 • 应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。 • 计算边界时间，以便为具体的任务定义时间窗口。

33. 项目的追踪和控制 软件项目管理一项重要工作就是在 项目实施过程中进行追踪和控制： • 定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。 • 评价在软件工程过程中所产生的所有评审的结果。 • 确定由项目的计划进度所安排的可能选择的正式的里程碑。

34. 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。 • 非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。 • 当问题出现的时候， 项目管理人员必须实行控制以尽快地排解问题。

35. 13.4软件项目的组织与计划 • 制定计划 • 软件项目组织的建立 • 人员配备

36. ★ 制定计划 • 软件开发项目的计划涉及到实施项目的各个环节，带有全局性质。 • 计划的合理性和准确性往往关系着项目的成败。 • 计划应力求完备。要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确。尽可能提高所依据数据的可靠程度。

37. 1. 制定计划目标和进行风险分析 • 制定计划的目的就是要回答：这个软件项目的范围是什么？需要哪些资源？花费多少工作量？要用的成本有多少？以及进度如何安排等等一系列问题。 • 这步工作应当以系统计划为基础，以系统规格说明为依据。

38. 在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以往的开发经验做出估算，很难达到准确。在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以往的开发经验做出估算，很难达到准确。 • 从估算出发，项目必然带有一定的风险。估算的准确性越差，风险也就越大。研制的软件项目越复杂，规模越大，结构化程度越低，资源、成本、进度等因素的不确定性越大，承担这一项目所冒的风险也越大。

39. 组织软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，只有这样才能避免出现灾难性的后果，取得项目预期的成果。组织软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，只有这样才能避免出现灾难性的后果，取得项目预期的成果。

40. 2. 软件计划的类型 • 针对不同工作目标，软件计划有： • 项目实施计划（软件开发计划） 这是软件开发的综合性计划，通常应包括任务、进度、人力、环境、资源、组织等多个方面。 • 质量保证计划 把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动。

41. 软件测试计划 规定测试活动的任务、测试方法、进度、资源、人员职责等。 • 文档编制计划 规定所开发项目应编制的文档种类、内容、进度、人员职责等。 • 用户培训计划 规定对用户进行培训的目标、要求、进度、人员职责等。

42. 综合支持计划 规定软件开发过程中所需要的支持，以及如何获取和利用这些支持。 • 软件分发计划 软件开发项目完成后，如何提供给用户。

43. 3. 项目实施计划中任务的划分 • 如何进行工作划分是实施计划首先应解决的问题。常用的计划结构有： • 阶段项目计划按软件生存期，把开发工作划分为若干阶段，对每一阶段工作做出计划。再把每一阶段工作分解为若干任务，做出任务计划。还要把任务细分为若干步骤，做出步骤计划。

44. 任务分解结构 按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构。进一步把工作内容、所需工作量、预计完成的期限也规定下来。 • 任务责任矩阵 在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示任务的分工和责任。

45. 任务分解结构

46. 任务责任矩阵

47. ★ 软件项目组织的建立 • 开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。 1、组织原则 (1) 尽早落实责任： 在软件项目工作开始时，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。

48. （2）减少接口： 一个组织的生产率随完成任务中存在的通信路径数目增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。 （3）责权均衡： 软件经理人员所负的责任不应比委任给他的权力还大。

49. 2. 组织结构的模式 （1）按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。

50. （2）按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。