软件项目管理的组织与过程

1、软件工程项目管理第六章项目管理3L 从十匕二芒牛一咎：T二一疋 " k 6.1 i目管理概述m.4尹项目管理的特点 .5|6.1.2项目管理的过程.86.2 项目计划.106.3进度安排.126.4项目估算.146.4.1软件规模估算 .166.4.2软件开发成本估算.196.5项目组织.236.5.2人员配备246.6软件质量.25软件质量及质量保证.25质量保证的主要内容.26质量保证体系27软件工程标准化 .28665 CMM 模型366.7 软件配置管理396.7.1 概述406.7.2 配置管理的过程 416.8 常用软件项目管理工具 43第六章项目管理本章要点软件项目管理

2、概念项目管理组织及过程软件质量及保证CMI模型本章学习目标了解软件项目管理的任务与目标、软件的作用范围 理解可行性研究、成本估算技术与成本估算模型、 软件项目的组织与计划、软件质量保证。软件理解软件能力成熟度模型 (CMM的基本概念、 过程的成熟度等级、关键过程区域、软件企业如何 实施CMM掌握软件管理技术的基本方法。6.1 项目管理概述软件项目管理同样体现出管理的四个基本职能，即计划、组织、领导和控制。软件项目管理是项目管理方法的一个应 用领域，项目管理就是为了满足甚至超越项目涉及人员对项 目的需求和期望而将理论知识、技能、工具和技巧应用到项 目的活动中去。要想满足或超过项目涉及人员的需求和

3、期 望，我们是需要在下面这些相互间有冲突的要求中寻求平 衡：范围、时间、成本和质量有不同需求和期望的项目涉及人员明确表示出来的要求（需求）和未明确表达的要求（期望）项目管理关注计划和资源分配以保证在预算内按时完成 质量合格的系统。项目管理也面临技术开发同样的问题：复杂和变化。复杂的产品需要很多有着不同背景和能力的开发 者参与开发。市场竞争和需要使开发过程需要变化，带来了经常性的资源重新分配，并使得对项目状况的跟踪也变得困 难。管理者和开发者使用同样的方法处理和多变问题：通用模型、交流、基本原理和配置。项目管理已经成为一种广泛应用于各行各业的技术管 理过程。 在软件行业， 对项目实施有效的管理是

4、软件成败的 关键。项目管理已经得到越来越多的企业和政府部门的重 视，学习和借鉴国际上先进的项目管理经验是非常明智和有 益的。软件企业的项目规范是许多公司通过几十年的摸索和 实践逐步发展形成的。随着我国正式加入世界贸易组织(WTO ,我国与国际上的交流与合作更加频繁， 越来越多的国内软件将承接外包软 件作为业务发展的一个方向。 外包软件指的是发达国家的企 业将软件开发项目转移到他国。 利用他国廉价的劳动力成本 来降低软件开发的成本。 国外企业选择外包软件的合作伙伴 时，最看重的是项目管理的项目经理的综合素质要求较高， 好的项目经理应该在软件开发技术， 软件开发技术， 软件工 程理论与实践， 项目

5、管理， 人际沟通等方面均要有较深的造 诣。6.1.1 项目管理的特点软件项目管理除涉及计算机软硬件领域技术外，还涉及 到系统工程学、心理学、社会学、经济学、乃至法律等方面 的问题。 需要用到多方面的综合知识， 特别是要涉及到社会 的因素、 精神的因素、 人的因素比技术问题复杂得多。 在相 关领域的研究成果和实践已经比较丰富， 但在具体的软件项 目实践中， 必须结合该项目的工作条件、 人员和社会环境等 多种因素来开展和实施。 软件工程发展的实践证明， 软件项 目成败的关键往往在于项目管理能力水平的高低， 管理得好 就能带来效率， 赢得时间， 最终将在技术前进的道路上取得 领先地位。软件项目的特点

6、：软件产品与其他任何产业产品相比有它自己的特点，它 是无形的，没有物理属性，它是一个物理系统的逻辑影射， 因此难以理解难于驾驶。但它确实是把思想、概念、算法、 流程、组织、效率、优化等融合在一起了。文档编制的工作 量在整个项目过程研制过程中站有很大的比重， 但往往人们 并不重视， 因而直接影响了软件的质量。 软件开发工作技术 性很强，要求参加工作的人员具有一定的技术水平和实际工 作的经验。 另外， 人员的流动对项目的影响很大， 离去的人 员不但带走了重要信息，还带走了工作经验。软件项目管理的困难1. 智力密集，可见性差：软件工程充满了大量高强度的 脑力劳动。软件开发的成果是不可见的逻辑实体，软

7、 件产品的质量的尺度加以衡量，对于不深入掌握软件 知识或缺乏软件经验的人员，是不可能领导做好软件 管理工作的。2. 单位生产：在内容、形式各异的基础上研制或生产， 与其它领域中大规模现代化生产有着很大的差别，也 自然会给管理工作造成许多实际困难。3. 劳动密集，自动化程度低：软件项目经历的各个阶段 都渗透了大量的手工劳动，这些劳动十分细致、复杂 和容易出差。尽管近年来已经有了软件工具和 CASE 的研究，但远未达到 自动化的程度。软件产品 的提高自然受到了很大影响。4. 使用方法繁琐，维护困难：软件工作渗透人的因素： 不仅要求软件人员具有一定的技术水平和工作经验， 而且还要求他们具备良好的心理

8、素质。软件人员的情 绪和他们的工作环境对他们工作有好大的影响。在总结和分析足够数量失误的软件项目之后， 看出其原 因大都与管理工作有关问题渗透及到软件项目研制中的计 划制定， 进度估计资源使用， 人员配备， 组织机构和管理方 法等管理的许多侧面。软件项目管理的主要职能包括： 制定计划：规定待完成的任务、要求、资源和进度等 建立组织： 为实施计划， 保证任务的完成， 需要建立分 工明确的责任制度。配备人员：任何各种层次的技术人员和管理人员。 指导：鼓励和动员软件人员完成所分配的工作。检验：对照计划和标准，监督和检查实施的情况。6.1.2 项目管理的过程为使软件项目开发获得最终成功， 必须对软件项

9、目的工 作范围，可能遇到的风险，需要的资源（人，软 / 硬件）， 要实现的任务，过程中的里程碑，花费的工作量（成本）， 以及进度的安排作到心中有数。 软件项目管理应该提供这些 信息， 这种管理开始于技术工作开始之前， 在软件从概念到 实现的过程中持续进行，最后终止于软件项目工程结束。 通常，软件项目管理包括以下过程：1 软件项目启动 通常，项目管理人员和用户是在系统工程启动阶段确定 项目的目标和范围。 当明确了软件项目的目标和范围后， 就 考虑可能的解决方案， 标明技术和管理上的要求， 确定合理， 精确成本估算，实际可行的任务分解以及可管的进度安排。2 度量度量的工作是为了有效地定量地进行管理

10、。 度量的目的 是为了把握软件工程实际情况和它所生产的产品质量。 在对 过去未度量的事项进行度量时， 需要解决是哪些适合于过程 和产品 , 如何使用收集到的数据，用于比较个人、过程或产 品的度量是否合理。3 估算在软件项目管理过程中一个关键的活动是制定项目计 划。在做计划时，必须就需要的人力、项目持续时间、成本 作出估算。这种估算大多是参考以前的花费作出的 。管理 人员可使用各种估算技术， 并可用一种估算技术作为另一种 估算技术的交叉检查。4 风险分析风险分析对软件项目管理是决定性的， 风险分析实际上 就是贯穿在软件工程过程中的一系列风险管理步骤， 其中包 括风险识别、 风险估计、 风险管理方

11、案、 风险解决和风险监 督，它能让人们去主动“攻击”风险。5 进程安排 软件项目的进程安排与任何一个项目的进程安排没有 实质上的不同。 首先识别一组项目任务， 再建立任务之间的 相互关联， 然后估算各个任务的工作量， 分配人力和其它资 源，制定进度时序。6 追踪和控制 项目管理人员追踪在制度安排的每个任务， 如果任务实 际完成日期滞后于进度安排， 则管理人员可以使用一种自动 的项目进度安排工具来确定在项目的中间里程碑上进度误 期所造成的影响。 此外， 还可以对资源重新定向， 对任务重 新安排或者可以修改交付日期以调整已经暴露的问题。 用这 种方式可以较好地控制软件的开发。6.2 项目计划计划是

12、管理工作的重要职能， 在软件项目管理中， 软件 项目从制定项目计划开始。 项目计划中需要确定以下几项内 容：目标： 定义了待完成的目标， 迫切需要的资源， 约束和 优先级。范围： 定义待开发系统的边界， 什么包括在系统里， 什 么不包括在系统里。产品技术说明：说明软硬件信息以及有关功能、性能、 安全性等方面的约束。时间：进度表。资金：预算。 地点：工作空间分配。 人员：参与人员以及项目组织。在这里，我们强调， 项目计划所需确定的内容最终必须 以文档的形式保留下来， 无论软件项目的规模多少， 项目计 划文档都是必需的。因为：1、撰写项目计划的过程也是一个澄清模糊认识，整理 思路的过程，只有用文字

13、记录下来的东西，才是明确的。2、文档能够作为同其他人的沟通渠道。项目计划可以 帮助客户了解我们的开发活动， 帮助项目组成员了解项目的 约束和策略，帮助项目经理跟踪项目的进展。3、项目计划文档可以作为数据基础和检查列表。通过 定期回顾，项目经理能清楚项目所处的状态以及哪些环节需 要重点进行更改和调整。很明显， 在做这些计划时并为进行项目需求分析， 所依 据的基础是系统计划， 以系统规格说明为依据。 要准确回答 以上问题是比较困难的， 主要靠的是估计， 估计的准确程度 也与项目的风险直接相关。项目计划针对不同的工作目标，类型有如下几种 :项目实施计划， 这是软件开发的综合性计划， 包括人物、 进度

14、、人力、环境、资源，组织等。质量保证计划， 把软件开发的质量要求具体规定为在每 批个开发阶段中可以检查的质量保证活动。软件测试计划， 规定测试活动的人物、 测试方法、 进度、 资源、人员职责等。文档编制计划，规定所开发的项目应编制的文档种类、 内容、进度、人员职责等。用户培训计划， 规定对用户进行培训的目标、 要求、 进 度、人员职责等。综合支持计划， 规定软件开发过程中所需要的支持， 以 及如何获得和利用这些支持。软件分发计划，软件项目完成后，如何提交给客户。在以上各类计划中， 软件项目实施计划是综合性的， 进 行工作的划分是该计划应首先解决的问题， 常用的计划结构 有按阶段进行项目的计划

15、, 任务分解结构和人物责任矩阵。6.3 进度安排软件开发项目的进展安排有两种考虑方式：1. 统最终交付日期已经确定， 软件开发部门必须在规定 期限内完成任务。2. 系统最终交付日期只确定了大致的年限， 最后交付日 期由软件开发部门确定 进度安排的准确程度可能比成本估算程度更重要。 如果进度 安排落空， 会导致市场机会的丧失， 使得用户不满意， 而且 也会导致成本的增加。 因此， 在考虑进度安排时， 要把人员 的工作量与花费的时间联系起来对于一个小型软件开发项目， 一个人就可以完成需求分 析、设计、编码和测试工作。 而对于一个稍大型的软件项目， 一个人单独开发，时间太长。因此，软件开发组是必要的

16、。 一般软件开发组的规模不能太大，人数不能太多，2-8 人左右较合适当参加同一软件工程项目的人数超过一人的时 候，开发工作就会出现并行情况。在软件开发过程的各个活动中， 第一项任务是进行项目的需求分析和评审，此项工作为以后的并行工作打下了基 础。 一旦软件的需求得到认可， 并且通过了评审、 概要设计 （系统结构设计和数据设计） 工作和测试计划制定工作就可 以并行进行。 如果系统的模块结构已经建立， 对各个模块的 详细设计、 编码、 单元测试等工作也可以并行进行。 待到每 个模块都已经完成， 就可以对它们进行组织， 并进行组装测 试。最后，进行确认测试，为软件交付进行确认工作。软件 工程项目的并

17、行性提出一系列进度要求。 因为并行任务是同 时发生的， 以进度计划决定任务之间的从属关系， 确定各个 任务的先后次序和衔接， 以及各个任务完成的持续时间。 此 外，应注意构成关键路径的任务， 即要保证整个项目能按进 度要求完成，就必须保证这些关键任务要按进度要求完成。 这样，就可以确定在进度安排中应保证的重点。前人在整个定义与开发的阶段工作量分配了一种建议 方案。这个分配方案称为 40-20-40 规则。它指出在整个软 件开发过程中，编码的工作量分配仅占20%，编码前的工作量占 40%，编码后的工作量占 40%。40-20-40 规则只是用来 作为一个指南， 实际的工作量分配比例必须按照每个项

18、目的 特点来决定。 一般在计划阶段的工作量很少超过总工作量的 2%-3%，除非是具有高风险的巨额投资的项目。需求分析可 能占总工作量的 10%-25%。花费在分析或原型化方面的工作量应当随项目规模和复杂性成比例地增加。 通常用于软件设 计的工作量在 20%-25%之间， 而在设计评审与反复修改的时 间也必须考虑在内。 由于软件设计已经投入了工作量， 因而 其后的编码工 作相对来说困 难要小一些， 用工作量的 15%-20%就可以完成。测试和随后的调试工作约占总工作量 的 30%-40%，所需要的测试量往往取决于软件的重要程序。 在项目实施过程中进行追踪和控制是软件项目管理的一项 重要工作。 比

19、如定期举行项目状态会议。 评价在软件工程过 程中所产生的所有评审的结果。 确定由项目的计划进度所安 排的可能选择的正式的里程碑， 比较在项目计划表中所列出 的每个想没的任务的实际开始时间和计划开始时间。6.4 项目估算软件项目管理过程从一开始被称为项目计划的活动开 始。 这些活动中的第一个是估算。 无论何时进行估算， 我们 都是在预测未来没， 在做软件项目估算时往往存在某些不确 定性， 使得软件项目管理人员无法正常迟迟不能完成。 虽然 估算是一门科学， 但它更是一门艺术， 可这个重要的活动不 能以随意的方式开进行。 现在已使用的实用技术是时间和工 作量估算。 因为估算是所有其他项目计划活动的基

20、石， 且项 目计划又为软件工程提供了工作方向， 所以不能没有计划就 着手开发，否则将会陷入盲目开发。对软件项目进行有效的估算， 取决于掌握多少有关项目范围的原始资料。 通常，应当根据正式的需求描述进行估算。 正式的需求描述可以是需求说明书、 系统规格说明书或软件 需求说明书等。 如果开始时缺乏一些正式的资料， 也可以采 用口头描述或草稿的方式开始估算工作。 在得到项目范围的 正式资料后，必须进行再估算。估算的两个主要方法是： 第一种方法是根据项目特征和算法进行估算。 例如， 根 据软件系统的输入、输出、查询、文件及外部接口等信息、 使用功能点估算出系统的规模。 基于功能点估算是按照用例 (Us

21、e case )来做的，而不是软件功能来做。通过研究初始 应用需求来确定各种输入、 输出、 计算和数据库需求的数量 和特性。第二种方法是采用类比的方法， 根据历史数据来进行估 算。如果有一个以前做过的类似项目并且掌握它的规模， 就 可以把新项目的各个主要部分与原有项目的相应部分进行 比较， 得出一个比例关系， 将各部分相对于原项目规模比例 相加， 计算出新项目的规模。 如果估算者的经验丰富并且新 项目与老项目具有足够的相似性，就能够得到合理的估算 值。但是采用类比法， 往往还要解决可重用代码的估算问题。 估计可重用代码量的最好办法就是由程序员或系统分析员 详细地考查已存在的代码， 估算出新项目

22、可重用的代码中需重新设计的代码百分比、 需重新编码或修改的代码百分比以 及需重新测试的代码百分比。6.4.1 软件规模估算软件项目的规模估计历来是比较复杂的事， 因为软件本 身的复杂性、 历史经验的缺乏、 估算工具缺乏以及一些人为 错误，导致软件项目的规模估计往往和实际情况相差甚远。 因此，估计错误已被列入软件项目失败的主要原因之一。先介绍一个衡量软件项目规模最常用的概念 -LOC（Line of Code） , LOC指所有的可执行的源代码行数， 包括可交付的工作控制语言（ JCL：Job Control Language） 语句、数据定义、数据类型声明、等价声明、输入 / 输出格 式声明等

23、。一代码行（1LOC的价值和人月均代码行数可以 体现一个软件生产组织的生产能力。 组织可以根据对历史项 目的审计来核算组织的单行代码价值。例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（.c和.h文件）约为250K。某项目的源文 件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为 240 人月，每人月费用为 10000 元（包括人均工资、福利、办公费用公滩等），则该项目中 1LOC的价值为：(240 X 10000) /150000 = 16 元 /LOC改项目的人月均代码行数为：150000/240=625LOC/ 人月方法一、 Delphi 法D

24、elphi 法是最流行的专家评估技术，在没有历史 数据的情况下， 这种方式适用于评定过去与将来， 新技术与 特定程序之间的差别， 但专家 "专" 的程度及对项目的理解程 度是工作中的难点，尽管 Delphi 技术可以减轻这种偏差， 专家评估技术在评定一个新软件实际成本时通常用得不多， 但是， 这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。 这个技术， 要求有多种软件 相关经验人的参与，互相说服对方。Delphi 法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因 素；3、各专家匿名填写迭代表格

25、；4、协调人整理出一个估计总结，以迭代表的形式 返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复 4-6 ， 直到达到一个最低和最高估计的一 致。方法二、 类比法 类比法适合评估一些与历史项目在应用领域、 环境 和复杂度的相似的项目， 通过新项目与历史项目的比较得到 规模估计。类比法估计结果的精确度取决于历史项目数据的 完整性和准确度， 因此， 用好类比法的前提条件之一是组织 建立起较好的项目后评价与分析机制， 对历史项目的数据分 析是可信赖的。其基本步骤是：1、整理出项目功能列表和实现每个功能的代码行；2、标识出每个功能列表与历

26、史项目的相同点和不 同点，特别要注意历史项目做得不够的地方；3、通过步骤 1 和 2 得出各个功能的估计值；4、产生规模估计。软件项目中用类比法， 往往还要解决可重用代码的 估算问题。估计可重用代码量的最好办法就是由程序员或系 统分析员详细地考查已存在的代码， 估算出新项目可重用的 代码中需重新设计的代码百分比、 需重新编码或修改的代码 百分比以及需重新测试的代码百分比。根据这三个百分比， 可用下面的计算公式计算等价新代码行：等价代码行 = （ 重新设计 % +重新编码 % +重新测试）/3 x已有代码行方法三、功能点估计法功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始

27、应用需求来确定各种输入、 输出、计算和数据库需求的数量和特性。通常的步骤是：1、计算输入，输出，查询，主控文件，和接口需 求的数目。2、将这些数据进行加权乘。下表为一个典型的权 值表。功能类型 权值输入 4输出 5查询 4主控文件 10接口 103、估计者根据对复杂度的判断， 总数可以用 +25%、0、或 -25%调整。据发现， 对一个软件产品的开发， 功能点对项目早 期的规模估计很有帮助。 然而， 在了解产品越多后， 功能点 可以转换为软件规模测量更常用的 LOC。6.4.2 软件开发成本估算软件开发成本主要是指软件开发过程中所花费的工作量 及相应的代价。 它不同于其他物理产品的成本， 不包

28、括原材 料和能源的消耗， 主要是人的劳动消耗。 人的劳动消耗所需 代价就是软件产品的的开发成本。 另一方面， 软件产品开发 的计算方法不同于其他物理产品成本的计算。 软件产品不存 在重复制造过程， 它的开发成本是以一次性开发过程所花费 的代价来计算的。 因此， 软件开发成本的估算， 应是从软件 计划、需求分析、设计、编码、单元测试、组装测试到确认 测试，整个软件开发过程所花费的代价作为依据的。对于一个大型的软件项目，要进行一系列的估算处理， 主要靠分解和类推的方法进行。基本估算方法分为 3 类：1、自顶想下的估算方法。这种方法的主要思想是：从 项目的整体出发， 进行类推。 即估算人员根据以前已

29、完成项 目所消耗的总成本， 来推算将要开发的软件的总成本， 然后 按比例将它分配到各开发任务单元中去。 这种方法的优点是 估算工作量小， 速度快。 缺点是对项目中的特殊困难估计不 足，估算出来的成本盲目性大， 有时会遗漏被开发软件的某 些部分。2、自底向上的估算法。这种方法的主要思想是：把待 开发的软件细分， 直到没个子任务都已经明确所需要的开发 工作量，然后把它们累加起来，得到软件开发的总工作量。这是一种常见的估算方法。 它的优点是估算各部分的准确性高。缺点是缺少各个子任务之间相互联系所需要的工作量， 还缺少许多同软件开发有关的系统级工作量。 所以估算值往 往偏低，必须用其他方法进行校验和校

30、正。3、差别估计法。 这种方法综合了上述两种方法的优点， 其主要思想是把待开发的软件项目与过去已完成的软件项 目进行类比， 从各个子任务中区分出类似的部分和不同的部 分。类似的部分按实际量进行计算， 不同的部分则采用相应 的方法进行估算。这种方法的优点是提高估算的准确程度， 缺点是不容易明确所谓“类似”的界限。 常见的几种估算模型为：1、IBM 模型1977年，IBM的Walston和Felix 提出了如下的估算公式：工作量=5.2 X L0.91 ,（以PM计）=4.1 X L0.36 ,=0.54 X E0.6 ,DOC= 49X L1.01L是源代码行数（以KLOC计）,E是D是项目持续

31、时间（以月计）S是人员需要量（以人计）DOC是文档数量（以页计）在此模型中， 一般指一条机器指令为一行源代码。 一个软件 的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程 序，应转换成机器指令源代码行数来考虑。2、Putnam 模型这是 1978 年 Putnam 提出的模型，是一种动态多变量模 型。它是假定在软件开发的整个生存期中工作量有特定的分 布。这种模型是依据在一些大型项目 （总工作量达到或超过 30 个人年）中收集到的工作量分布情况而推导出来的，但 也可以应用在一些较小的软件项目中。Putnam 模型可以导出一个“软件方程”，把已

32、交付的 源代码（源语句） 行数与工作量和开发时间联系起来。 其中， td是开发持续时间（以年计J, _3是软件开发与维护在内的L=C K K 3 td 3 整个生存期所花费的工作量（以人年计）， L 是源代码行数（以LOC计），Ck是技术状态常数，它反映出“妨碍程序 员进展的限制”， 并因开发环境而异。 其典型值的选取如下 表所示。3、COCOM模 型这是由TRW公司开发。Boehm提出的结构型成本估算模型， 是一种精确、 易于使用的成本估算方法。 在该模型中使用的基本量有以下几个：DSI （源指令条数）定义为代码或卡片形式的源程序行数。 若一行有两个语句， 则算做一条指 令。它包括作业控制语

33、句和格式语句，但不包括注释语句。KDSI= 1000DSI。MM（度量单位为人月）表示开发工作量。 TDEV（度量单位为月）表示开发进度。它由工作量决定。（ 1 ）软件开发项目的分类在COCOM模型中，考虑开发环境，软件开发项目的总体类型可分为三种:组织型、 嵌入型和介于上述两种软件之间的半独立型（2）COCOM模型的分类COCOM模型按其详细程度分成三级:即基本 COCOM型、中间COCOM详细COCOM模型。基本 COCOM模型是一个静态单变量模型， 它用一个以已估算出来的源代码 行数（LOC为自变量的（经验）函数来计算软件开发工作 量。中间COCOM模型则在用LOC为自变量的函数计算软件

34、 开发工作量 （ 此时称为名义工作量 ） 的基础上，再用涉及产 品、硬件、人员、项目等方面属性的影响因素来调整工作量 的估算。详细COCOM模型包括中间COCOM模型的所有特性， 但用上述各种影响因素调整工作量估算时， 还要考虑对软件 工程过程中每一步骤（分析、设计等）的影响。6.5 项目组织6.5.1 组织原则在建立项目组织时应注意到以下原则：（1）早落实原则（2）减少接口（3）责权均衡6.5.2 人员配备合理地配备人员是成功地完成软件项目的切实保证。所 谓合理地配备人员应包括： 按不同阶段适时任用人员， 恰当 掌握用人标准。1. 配备人员的原则：配备软件人员时，应注意以下 3 个主要原则：

35、（ 1） 重质量：软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用教多的经验不足的人员更有限。（ 2） 重培训：花力气培养所需的技术人员和管理人 员是有效解决人员问题的好方法。（ 3） 双阶梯提升：人员的提升应分别按技术职务和 管理职务进行，不能混在一起。2. 对项目经理人员的要求软件经理人员是人员的组织者， 他的管理能力的强弱是项目成败的关键。 除去一般的管理要求外， 他应具有的能力：1）把用户提出的非技术性要求加以整理提炼，以技术说明书形式转告给分析员和测试员。 2）能说服用户放弃一些不 切实际的要求，以便保证合理的要求得以满足。3）具有综合问题

36、的能力。 4）要懂得心理学。3. 评价人员的条件软件项目中人的因素越来越受到重视。在评价和任用软 件人员时，必须掌握一定的标准。人员素质要求：1）牢固掌握计算机软件的基础知识和技能。 2）善于分析和综合问 题，具有严密的逻辑思维能力。 3）工作踏实、细致、不靠 碰运气，遵循标准和规范，具有严格的科学作风。4）工作中表现出耐心、有毅力、有责任心。 5）善于听取别人的意 见，善于与周围人员团结协作，建立良好的人际关系。6）具有良好的书面和口头表达能力。6.6 软件质量计算机科学与技术的迅速发展和应用范围日益广泛，计 算机软件的重要性与日俱增。人民对软件质量要求越来越 高，对软件的质量控制和质量管理

37、越来越重视。 软件产业的 迅猛发展急需软件工程方法、 技术的支持， 软件工程的理论 也随着软件产业的实践而逐渐丰富。6.6.1 软件质量及质量保证按照 ANSI/IEEE1983 年的标准，软件质量定义为“与软 件产品满足需求所规定的和隐含的能力有关的特征和特性 的全体。”具体包括：（1）软件产品中所能满足用户给定的全部特性的集合。（2）软件具有所期望的各种属性组合的程度（3）用户主观得出的软件是否满足其综合期望的程度。（4）决定所用软件在使用中将满足其综合期望程度的 软件合成特性。软件质量是降低软件开发成本的基本保障。 提高软件质 量是软件企业竞争的需要， 是软件企业生存的基础， 也是其 进

38、入国际市场的基本条件。软件质量保证（SQA是软件工程学科的一部分，是一个 复杂的系统， 它根据一系列的标准， 采用一定的方法， 技术 和工具， 处理和调整软件产品各个特性之间的相互关系， 以 确保软件产达到其应该达到的质量水平。6.6.2 质量保证的主要内容软件工程保证应用于整个软件过程的保护活动，包括：（ 1） 质量管理方法（ 2） 有效的软件工程技术（方法和工具）。（ 3） 应用于整个软件过程的形式化技术评论。（ 4 ） 多等级测试策略。（5）软件文档以及对软件进行改变和维护的控制和约束。（6）确保遵照软件开发标准的过程。（7）测量和报告机制。质量保证包括管理的审核和报告功能。 质量保证的

39、目的 是以有关产品的基本数据进行质量管理， 从而保证产品质量 不断地找着其质量目标迈进。 质量保证活动提供大量有关质 量的基本数据， 不过， 根据这些数据所指出的质量问题必须 通过质量管理来解决。6.6.3 质量保证体系为了更好地协调好软件质与软件生产率、软件开发成本 之间的关系， 保证软件达到一定的质量水平， 必须遵守一定 的软件质量保证原则。软件质量保证原则：（1） 在开始制定项目计划时， 充分考虑用户的要求， 确 定实用的质量特征（ 2） 详细制定质量计划。（3）对阶段性成果进行各种质量检查、校对等评审活动。（4）不断地优化和完善质量计划。（5）尽早发现并及时改正错误和缺陷。（ 6） 由

40、独立的测试小组进行测试。（7） 在对开发过程进行质量评估似的基础上， 检查质量 测试的结果以发现与质量计划的偏差，确定适当的修 改方案。6.6.4 软件工程标准化随着软件工程学科的发展， 人们对计算机软件的认识逐 渐深入。软件工作的范围从只是使用程序设计语言编写程 序，扩展到 整个软件生存期。诸如，软件概念的形成、需 求分析、设计、实现、测 试、制造、安装和检验、运行和 维护直到软件引退 （ 为新的软件所代 替） 。同时还有许多技 术管理工作 （ 如过程管理、产品管理、资源管理） 以及确认与验证工作 （ 如评审与审计、 产品分析、 测试等 ） 常常是跨越 软件生存期各个阶段的专门工作。所有这些

41、方面都应逐步 建立起标准或规范来。另一方面， 软件工程标准的类型也是多方面的。 它可能 包括过程标准 （ 如方法、 技术、 度量等 ） 、产品标准 （ 如需求、 设计、部件、 描述、计划、报告等 ） 、专业标准 （ 如职别、 道德准则、认证、特许、课程等 ） 以及记法标准 （如术语、表 示法、语言等 ） 。在全面考虑以上两个方面的情况下， 软件工程的标准 可用一张二维的表格来表示。表61（a） 和 （b） 给出了这个二维表的大致格式。(b)表是(a)表的继续。表中填入了二个标准的例子(请注意 它们在表中所处的位置)表6.1 (a)软件工程标准分类软件生存期概念需求设计实现测试制造安装与检验运行

42、与维护引退标准类 型过程力法技术度且 量产品需求设计部件描述计划报告专业职别道德 准 则认证特许课程记法、亠 丿术语表示法ISO5807语、. 言 FIPSI05是美国国家标准局发布的软件文档管理指南 (National Bureau OfStandards , Guideline for Software Documentation Management, FIPS PUB105， June 1984) NSA 39是美国核子安全分析中心发布的安全参 数显示 系统的验证与确认 (Nuclear Safety Analysis Center ， Verification and Validat

43、ion for Safety Parameter Display Systems，NSA 39，De cemberl981) ISO 5807是国际标准化组织公布(现已成为我国国家标 准)的信息处理一一数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定(本书第四章4. 1节讨论过的标准程序流程图正是以此为依 据)。这个表不仅告诉了我们软件工程标准的范围和标准如 何分类，而且对标准的开发具有指导作用。已经制定的标准都可在表中找到相应的位置，而且它可启发我们去制定新的标准。表6.1 (b)软件工程标准分类技术管理确认与验证过程产品:资源平审与产品分则试管理管理管理审计析

44、标准类 型过程力法NSAC-39NSAC-39NSAC-39技术FIPS105度且量产品需求7设计部件描述计划报告专业职别道德准则认证持许课程记法、亠 术语表示法语、. 言软件工程标准的制定与推行软件工程标准的制定与推行通常要经历一个环状的生命期（参看图6. 1）。最初，制定一项标准仅仅是初步设想，经发起后沿着环状生命期，顺时针进行要经历以下的步骤：CTO)厂吒修仃_£建衩丄 zWD I 足图6. 1软件工程标准的环状生命期.建议，拟订初步的建议方案*开发：制定标准的具体内容咨询：征求并吸收有关人员意见审批，由管理部门决定能否推出-公布：公开发布，使标准生效*培训：为推行标准准备人员

45、条件-实施：投入使用，需经历相当期限审核：检验实施效果，决定修订还是撤销-修订：修改其中不适当的部分，形成标准的新版本，进入新的周期软件工程标准化的意义为使标准逐步成熟，可能在环状生命周期上循环若干 圈，需要 做大量的工作。事实上，软件工程标准在制定和 推行过程中还会 遇到许多实际问题。其中影响软件工程标 准顺利实施的一些不利因素应当特别引起重视。这些因素可能有：标准本身制定得有缺陷， 或是存在不够合理，不够恰当 的部分。标准文本编写得有缺点， 例如，文字叙述可读性差，难 于 理解，或是缺少实例供读者参阅。主管部门未能坚持大力推行， 在实施的过程中遇到问题又 未能及时加以解决。未能及时作好宣传

46、、培训和实施指导。未能及时修订和更新。一个软件开发项目有多个层次、不同分工的人员相互配合，在开发项目的各个部分以及各开发阶段之间也都存在 着许多联系和衔接问题。如何把这些错综复杂的关系协调 好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，需要进行阶段评审和验收测试。投 入运行的软件，其维护工作中遇到的问题又与开发工作有着 密切的关系。软件的管理 工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行动规范和衡量准则， 使得各种工作都能有章可循。 软件工程的标准化会给软件工作带来许多好处，比如： 提高软件的可靠性、可维护性和可移植性 ( 这表明软件 工程 标准化

47、可提高软件产品的质量 )提高软件的生产率 提高软件人员的技术水平 提高软件人员之间的通信效率，减少差错和误解 有利于软件管理 有利于降低软件产品的成本和运行维护成本 有利于缩短软件开发周期6.6.5 CMM 模型CMM(Capability Maturity Model) 即能力成熟度模型， 定义了当一个组织达到不同的过程时应该具有的软件工程 能力。 它描述了软件过程从无序到有序、 从特殊到一般、 从 定性管理到定量管理、 最终到达可动态优化的成熟过程。 给 出了该过程中 5 个成熟阶段的基本特性和应遵循的原则、 采 取的行动，以帮助软件组织改进其软件过程。CMM勺基本前提是：软件质量在很大程

48、度上取决于开发软 件的软件过程的质量和能力； 软件过程是一个可管理、 可度 量并不断改进勺过程； 软件过程勺质量受到用以支撑它勺技 术和设施的影响；软件开发组织在软件过程中所采用的技术 层次应适应于软件过程的成熟度。CMh强调的是软件组织能一致地、可预测地生产高质量软 件产品的能力。软件过程能力是软件过程生产计划中产品内 在能力。在完全理解软件过程成熟之前，需要先理解几个基本概念。将CMMA织成下图所示的 5个等级，其意在于增加软件 过程成熟的改进行动按优先级 排序。图中带有标记的箭头， 指示在成熟度框架的每一步骤上， 组织应予以规范化的过程 能力的类型。1）初始级（ 1 级）。软件过程的特点

49、是无秩序的，偶 尔甚至是混乱的。几乎没有什么过程是经过定义的， 成功依赖于个人的努力。2）可重复级（ 2 级）。已建立基本的项目管理过程去 跟踪成本、进度和功能的实现必要的过程要求已经建 立，且作为纪律严格执行，使得今后完成类似的应用 项目能重复以前的成功，并不受人员流动的限制。已建立基本的项目管理过程去跟踪成本、 进度和功能性。 必要的过程纪律已经就位，使具有类似应用的项目能重 复以前的成功。3）已定义级（ 3 级）。管理活动和工程活动两方面的 软件过程均已稳定化，标准化，并将它们集成为软件 开发组的标准软件过程。组织内全部软件开发项目均 采用该标准软件过程的一个经批准的裁减版本，本进 行软

50、件的管理、开发和维护等活动。4）已管理级（ 4 级）。已采集详细的有关软件过程和 产品质量的度量数据，使软件过程和产品质量均得到 定量的了解和控制。因此，软件开发的成本、进度和 软件质量等都是定量的、可预测的。5）优化级（ 5 级）。自觉利用在执行过程中总结出来 的经验，以及来自新思想和技术的先导性试验的定量 反馈信息，来持续不断地改进组织的标准软件过程， 从而使组织的软件过程能力不断地增强和优化。6.7 软件配置管理系统配置指的是交付给特定客户的一个系统构件的集 合，例如一个系统开发软件可能有个人版， 专业版和完全功 能的企业版， 不同的交付版本就对应着不同的系统配置。 软 件配置管理是监督

51、和控制工作产品中变化的过程。 变化遍及 整个软件开发过程。 当客户要求新功能时， 或者当开发人员 加深了对应域的认识时， 需要都会发生改变。 当新技术变得 可用时，系统的硬件 / 软件平台发生变化，当测试发现故障 并修正时， 系统发生变化。 软件配置管理用于维护领域， 并 在系统中逐步达到完善。 然而， 在现代化开发过程中， 变化 比维护出现得更早。 开发与维护之间的界限变得， 模糊不清， 在所有阶段能用配置管理来处理变化。配置管理使得开发人员能跟踪变化。系统由许多能被单 独修改的配置项构成。 对每一个配置项， 可对其一系列版本 的演化进行跟踪。 当变化失败时， 检查并选取版本能使得开 发人员

52、返回到明确定义的系统状态。配置也使得开发人员能控制变化。当定义了基准后，任 何变化实现前都需要评估和批准这样使得管理能够确保系 统正朝着项目目标进展， 并确保引入系统的问题数目是有限 的。6.7.1 概述软件配置管理是软件系统发展过程中管理和控制变化的规范 IEEE StD.1042-1987 。配置管理系统使得版本的识 别、存储和检索以及支持状态记录自动完成。 配置管理包括 下列活动：配置项的确定 系统组件以及它们工作产品和对应的 版本是进行唯一识别和标识的。开发人员在项目鉴定协议 后，即一旦对系统的主要交付组件达成一致意见就可以确定 配置项。 随着系统的进展， 由开发人员创建版本和附加配置

53、 项。变化控制 系统的变化以及发布给用户的版本要确保 与项目一致。 变化控制可以由开发人员、 管理人员或控制委 员会管理，取决于要求的质量等级和变化速度。状态记录 单个组件、 工作产品和变化请求的状态都要 加以记录。他使得开发人员更容易辨认不同版本并跟踪与变 化请求的状态都要加以记录。它使得开发速度。审核 选择发布的版本要确保产品的完全性、一致性和 质量。审核由质量控制小组完成。6.7.2 配置管理的过程软件配置管理的方法大致分三类：单独文件、增量和条 件编译。单独文件是指为每个不同的系统版本单独保存一份完整 的分支。采用单独文件的方式进行配置管理的一个缺点是存 储的冗余度较大， 不同的系统版

54、本中相同部分占大多数， 不 同处只是少部分。 而且， 如果采用单独文件方式进行配置管 理，A版本中存在的问题在 B版本中也会存在，需要以同样 的方式来排除这些问题， 在这种情况下保持版本的一致性和 正确性都比较困难。 当然， 这种方式也有优点， 即可靠性较 高，在一个或多个分支被破坏的情况下， 只要有一个分支能 恢复， 那么就能恢复不同版本之间相同的部分， 丢失的只是 不同版本之间的差异部分。所谓增量技术是指在进行配置管理时将一个特定的版本 作为系统的主版本， 其他版本作为主版本的变体。 对于其他 版本之存储其余诸版本的不同之处，而不需要存储整个分 支。存储版本之间的差别即称为增量，包含一些编辑命令， 这些命令描述了如何从主版本切换到不同版本。 采用增量技 术进行配置管理的好处在于对公共功能的修改只需要在主 版本上进行。 缺点在于如果主版本破坏则所有版本相关信息 都丢失了。条件编译只用相同的代码文件包含所有版本内容，代码 文件中的条件编译语句使得编译器决定哪条语句应用到哪 个版本。 因为不同的版本共享的代码只有一份， 可以将一次 性修改