第八章软件维护课件.ppt

《第八章软件维护课件.ppt》由会员分享，可在线阅读，更多相关《第八章软件维护课件.ppt（34页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、章软件维护软软件件维护维护的概念的概念软软件件维护维护的特点的特点软软件件维护维护的的过过程程软软件的可件的可维护维护性性1软件维护的概念软件维护的概念 软件维护是软件生存周期的最后一个阶段软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。不属于系统开发的过程。问题问题内内 容容维护维护目的目的 维护维护种类种类 满足用户对已开发产品的性能与运行环境不断提高的要求，进而满足用户对已开发产品的性能与运行环境不断提高的要求，进而达到延长软件寿命的目的。达到延长软件寿命的目的。改正性改正性适应性适应性完善性完善性预防性预防性对程序使用期间发现的程序错误进行诊断和改正的过程；对程序使用期间发

2、现的程序错误进行诊断和改正的过程；配合变化了的环境进行修改软件的活动；配合变化了的环境进行修改软件的活动；满足用户在使用过程中提出增加新的功能或修改已有满足用户在使用过程中提出增加新的功能或修改已有功能的建议而进行的工作；功能的建议而进行的工作；为了改善未来的可维护性或可靠性而修改软件的工作。为了改善未来的可维护性或可靠性而修改软件的工作。软件维护的工作量非常大，不同应用领软件维护的工作量非常大，不同应用领域的维护成本差别也很大。一般大型软件域的维护成本差别也很大。一般大型软件的维护成本平均高达开发成本的四倍左右。的维护成本平均高达开发成本的四倍左右。改正性改正性完善性完善性适应性适应性预防性

3、预防性左右左右 软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支出的到。而无形的代价更是无法估计的。出的到。而无形的代价更是无法估计的。2 维护的特点维护的特点()()维护要求维护要求评价代码评价代码评价设计评价设计配置配置复查复查修改程序修改程序修改设计修改设计计划途径计划途径？复查复查修改程序修改程序维护后软维护后软件与记录件与记录软件软件代码代码一一.维护方式维护方式 方式方式配置配置开始开始工作工作 成本成本难度难度结构化维护结构化维护非结构化维护非结构化维护每个阶段文档与程序代码每个阶段文

4、档与程序代码仅有程序代码仅有程序代码评价设计文档开始评价设计文档开始评价代码开始评价代码开始()()确定软件的结构特征、确定软件的结构特征、性能特性和接口特性，性能特性和接口特性，()()确定软件修改带来的影确定软件修改带来的影 响，找出一种处理方法；响，找出一种处理方法；()()修改设计、复审；修改设计、复审；()()再编写源程序代码，进行再编写源程序代码，进行 回归测试；回归测试；()()将修改后的软件交付使用将修改后的软件交付使用 软件结构、软件结构、全程数据结构、全程数据结构、系统接口、性系统接口、性能要求、设计能要求、设计约束等具体特约束等具体特点不清楚而很点不清楚而很难确定。难确定

5、。维护成本较低。维护成本较低。易于维护。易于维护。很高。很高。维护困难。维护困难。3 维护的特点维护的特点()()二二.与软件维护有关的问题与软件维护有关的问题影响影响维护维护因素因素维护维护困难困难 软件维护工作量模型：；：总工作量；：评价、修改设计和编写代码等软件维护工作量模型：；：总工作量；：评价、修改设计和编写代码等 工作量；：经验常数；：系统复杂程度；：维护人员对软件的熟悉程度。工作量；：经验常数；：系统复杂程度；：维护人员对软件的熟悉程度。()()模块化详细设计文档有助于理解软件的结模块化详细设计文档有助于理解软件的结 构、界面功能和内部流程；构、界面功能和内部流程；()()开发过

6、程中严格而科学的管理规划及清晰开发过程中严格而科学的管理规划及清晰 可靠的文档资料对发生错误后的理解与纠可靠的文档资料对发生错误后的理解与纠 错无疑是很重要的。错无疑是很重要的。()()模块的独立程度对软件修改的难易程度、模块的独立程度对软件修改的难易程度、改进和移植影响是很大的。改进和移植影响是很大的。软件开发及维护人员的水平；软件开发及维护人员的水平；使用标准的程序设计语言；使用标准的程序设计语言；使用标准的操作系统接口；使用标准的操作系统接口；使用规范化的文档资料；使用规范化的文档资料；测试用例的有效性。测试用例的有效性。别人写的程序在没有说明文档时，理解很困难，不为人喜欢；别人写的程序

7、在没有说明文档时，理解很困难，不为人喜欢；维护持续时间都很长，开发人员一般不在现场，对软件没有人说明。维护持续时间都很长，开发人员一般不在现场，对软件没有人说明。绝大多数软件在设计时都没有考虑将来的修改。除非设计中强调了绝大多数软件在设计时都没有考虑将来的修改。除非设计中强调了模块的独立性，否则软件的修改既困难又易发生差错。模块的独立性，否则软件的修改既困难又易发生差错。开发方法开发方法开发条件开发条件理解理解时间时间设计设计问题问题4 维护的过程维护的过程()()一一.建立软件维护的组织建立软件维护的组织,在组织中有总负责人、系统管理员和维护管理员等。在组织中有总负责人、系统管理员和维护管理

8、员等。二二.编写维护的报告编写维护的报告 用标准化的格式表达所有软件维护的要求。要求包括下列内容：用标准化的格式表达所有软件维护的要求。要求包括下列内容：.满足维护要求表中提出的要求所需要的工作量；满足维护要求表中提出的要求所需要的工作量；.维护要求的性质；维护要求的性质；.该项要求的优先顺序；该项要求的优先顺序；.与修改有关的事后数据。与修改有关的事后数据。三三.为每一个维护要求规定一个标准化的事件序列为每一个维护要求规定一个标准化的事件序列(见下页图形见下页图形).明确维护的类型明确维护的类型:纠错性维护纠错性维护,进一步分清是适应性维护还是完善性维护；进一步分清是适应性维护还是完善性维护

9、；.对纠错性维护从评价错误的严重性开始对纠错性维护从评价错误的严重性开始,分别不同程度采取不同的方法；分别不同程度采取不同的方法；.适应性维护和完善性维护沿着同一路径推进，确定优先顺序后开始工作；适应性维护和完善性维护沿着同一路径推进，确定优先顺序后开始工作；.对恶性软件故障，应把所有的资源用来解决问题；对恶性软件故障，应把所有的资源用来解决问题；.对任何类型的维护都要进行同样的技术工作，包括：修改软件设计、设计对任何类型的维护都要进行同样的技术工作，包括：修改软件设计、设计 复审、必要的代码修改、单元测试、集成测试、验收测试和复审等。复审、必要的代码修改、单元测试、集成测试、验收测试和复审等

10、。5 维护的过程维护的过程()()区分区分类型类型问题问题分析分析严重性严重性评价评价维护维护任务任务配置配置复审复审优先度优先度评价评价问题问题分析分析纠错项目表纠错项目表 纠错纠错 分配的人员分配的人员 已修改配置已修改配置 开发项目表开发项目表 测试测试 已修改软件已修改软件复审后供使用复审后供使用的软件配置的软件配置分配的人员分配的人员 适应适应严重严重完善完善不严重不严重计划改计划改正进度正进度低低高高维护事件序列图维护事件序列图维护事件序列图维护事件序列图维护要求维护要求6 维护的过程维护的过程()()维维护护记记录录中中的的数数据据工工作作量量考考虑虑程序标识；程序标识；自从安装

11、以来程序失败的次数；自从安装以来程序失败的次数；自从安装以来程序运行的次数；自从安装以来程序运行的次数；维护每种语言平均花费的人时数；维护每种语言平均花费的人时数；因程序变动而增加的源语句数；因程序变动而增加的源语句数；程序变动的层次和标识；程序变动的层次和标识；每次程序运行平均失效的次数；每次程序运行平均失效的次数；程序安装的日期；程序安装的日期；使用的程序设计语言；使用的程序设计语言；机器指令条数；机器指令条数；源语句数；源语句数；不同维护类型所占的时间比。不同维护类型所占的时间比。平均每个程序、每种语言、每种维护类型所做的程序变动数；平均每个程序、每种语言、每种维护类型所做的程序变动数；

12、与完成的维护相联系的纯效益。与完成的维护相联系的纯效益。累计用于维护的人时数；累计用于维护的人时数；维护开始和完成的日期；维护开始和完成的日期；维护类型；维护类型；维护要求表的标识；维护要求表的标识；软件工程师的名字；软件工程师的名字；程序改动的日期；程序改动的日期；每个改动所耗费的人时数；每个改动所耗费的人时数；因程序变动而删除的源语句数；因程序变动而删除的源语句数；用于同一类维护活动的总人时数；用于同一类维护活动的总人时数；一张维护要求表的平均周转时间；一张维护要求表的平均周转时间；增加或删除一个源语句平均花费的人时数增加或删除一个源语句平均花费的人时数7 可维护性可维护性()()决定软件

13、可维护性的因素决定软件可维护性的因素 因素因素内内 容容可理解性可理解性可测可测试性试性可修可修改性改性软件的结构、接口、功能和内部过程的难易程度；软件的结构、接口、功能和内部过程的难易程度；模块化、详细设计文档、结构化设计、源代码内部的文档；模块化、详细设计文档、结构化设计、源代码内部的文档；程序设计语言。程序设计语言。诊断和测试的难易程度取决于软件容易理解的程度；诊断和测试的难易程度取决于软件容易理解的程度；良好的文档对诊断和测试是至关重要的诊断和测试；良好的文档对诊断和测试是至关重要的诊断和测试；软件结构、可用的测试工具和调试工具，以往的测试过程是很重要的；软件结构、可用的测试工具和调试

14、工具，以往的测试过程是很重要的；在设计阶段应尽力把软件设计成容易诊断和测试的。在设计阶段应尽力把软件设计成容易诊断和测试的。与设计原理、规则直接相关；与设计原理、规则直接相关；与藕合、内聚、局部化、控制域、作用域等等都有关系。与藕合、内聚、局部化、控制域、作用域等等都有关系。8 可维护性可维护性()()与可维护性相关的文档与可维护性相关的文档 文档文档内内 容容文档描述文档描述要求要求用户用户文档文档系统系统文档文档如何使用这个系统；如何使用这个系统；怎样安装和管理这个系统；怎样安装和管理这个系统；系统需求和设计；系统需求和设计；系统的实现和测试。系统的实现和测试。功能描述功能描述:说明系统能

15、做什么；说明系统能做什么；安装文档安装文档:说明怎样安装该系统及使系统适应特定的硬件配置；说明怎样安装该系统及使系统适应特定的硬件配置；使用手册使用手册:简要说明如何使用这个系统；简要说明如何使用这个系统；参考手册：详尽描述用户可以使用的系统设施及方法，以及可能产参考手册：详尽描述用户可以使用的系统设施及方法，以及可能产 生的出错信息含义；生的出错信息含义；操作员指南：说明操作员如何处理使用中出现的各种情况。操作员指南：说明操作员如何处理使用中出现的各种情况。从问题定义、需求说明到验收测试这样一系列和系统实现有关的文档。从问题定义、需求说明到验收测试这样一系列和系统实现有关的文档。9第八章第八

16、章 小小 结结 一一.软件维护是软件生存周期的最后一个阶段，也是持续时间最长、软件维护是软件生存周期的最后一个阶段，也是持续时间最长、代价最大的一个阶段。代价最大的一个阶段。二二.软件维护包括四类活动：改正性维护、适应性维护、完善性维软件维护包括四类活动：改正性维护、适应性维护、完善性维 护和预防性维护。护和预防性维护。三三.软件的可理解性、可测试性和可维修性是决定软件可维护性的软件的可理解性、可测试性和可维修性是决定软件可维护性的 基本因素。基本因素。四四.软件生存周期的每个阶段和软件可维护性密切相关。软件生存周期的每个阶段和软件可维护性密切相关。五五.文档是影响软件可维护性的决定因素。文档

17、是影响软件可维护性的决定因素。六六.文档分为用户文档和系统文档，它们都必须和程序代码同时维文档分为用户文档和系统文档，它们都必须和程序代码同时维 护才有真正的价值。护才有真正的价值。10第八章第八章 习习 题题 .为什么说软件的维护是不可避免的？为什么说软件的维护是不可避免的？.软件的维护一般分为哪几类？软件的维护一般分为哪几类？.影响软件维护的因素有哪些？影响软件维护的因素有哪些？.软件维护困难主要表现在什么方面？软件维护困难主要表现在什么方面？.决定软件可维护性的因素？决定软件可维护性的因素？.软件价格应该计入维护成本吗？为什么？软件价格应该计入维护成本吗？为什么？.对前面各章中分析的各应

18、用系统，提出改进和扩充功能的要求？对前面各章中分析的各应用系统，提出改进和扩充功能的要求？()()教材销售采购系统；教材销售采购系统；()()图书管理系统；图书管理系统；()()房产管理系统。房产管理系统。11第九章软件工程管理 软件项目的特点和管理的职能软件项目的特点和管理的职能 成本估算成本估算 人员的分配和组织人员的分配和组织 进度安排进度安排 质量保证质量保证 项目计划项目计划 软件管理工具软件管理工具12 软件项目特点和管理的职能软件项目特点和管理的职能()()软件项目的规模越大，所需要软件项目的规模越大，所需要 的管理支持工作量越大。统计资料的管理支持工作量越大。统计资料 表明在软

19、件项目的规模达到一定程表明在软件项目的规模达到一定程 度时，所需的软件管理工作量将达度时，所需的软件管理工作量将达 到总工作量的一半。如图所示：到总工作量的一半。如图所示：技术和管理是软件生产中不可缺少的两个方面，对技术而言，技术和管理是软件生产中不可缺少的两个方面，对技术而言，管理意味着决策和支持。只有对生产过程进行科学的估量，作管理意味着决策和支持。只有对生产过程进行科学的估量，作到技术落实、组织落实和费用落实，才能达到提高生产率，改到技术落实、组织落实和费用落实，才能达到提高生产率，改善产品质量的目的。因此软件工程管理也是软件工程学中研究善产品质量的目的。因此软件工程管理也是软件工程学中

20、研究的领域之一。的领域之一。100%100%50%50%软件规模软件规模工工作作量量技术工作技术工作管理工作管理工作 软件项目的规模软件项目的规模,决定了采用怎样决定了采用怎样的管理水平、开发工具和开发方法。的管理水平、开发工具和开发方法。13 软件项目特点和管理的职能软件项目特点和管理的职能()()一一.软件项目的特点软件项目的特点 .软件项目与其他任何产业项目不同，它是算法、思想、概念、软件项目与其他任何产业项目不同，它是算法、思想、概念、组织、流程、效率、优化等的融合体；组织、流程、效率、优化等的融合体；.开发软件项目产品开发软件项目产品,在多数情况下在多数情况下,用户给不出明确的想法和

21、要用户给不出明确的想法和要 求。求。.在开发过程中，程序及其相关的文档资料常常需要修改，在修在开发过程中，程序及其相关的文档资料常常需要修改，在修 改过程中又可能带来新的问题，且这些问题要在很久以后才会改过程中又可能带来新的问题，且这些问题要在很久以后才会 发现。发现。.在研制开发过程中，文档资料是不可缺少的，但工作量又是巨在研制开发过程中，文档资料是不可缺少的，但工作量又是巨 大的大的,往往也是人们不愿去作的。往往也是人们不愿去作的。.参加软件项目的工作人员，要求具有一定的业务水平和实际工参加软件项目的工作人员，要求具有一定的业务水平和实际工 作经验，而很难完全避免的人员流动，对工作的影响是

22、很大的。作经验，而很难完全避免的人员流动，对工作的影响是很大的。离开的人员不仅带走了重要的信息，而且带走了工作经验。离开的人员不仅带走了重要的信息，而且带走了工作经验。14 软件项目特点和管理的职能软件项目特点和管理的职能()()二二.软件项目管理的特殊困难软件项目管理的特殊困难 .智力密集智力密集,可见性差可见性差,对没有软件知识和软件开发实践经验的人对没有软件知识和软件开发实践经验的人 员很难做好管理工作。员很难做好管理工作。.特定的开发环境特定的开发环境,加上特定的开发方法、工具和语言。建立在这加上特定的开发方法、工具和语言。建立在这 种内容、形式各异基础上的研制或生产方式，与其他领域大

23、规种内容、形式各异基础上的研制或生产方式，与其他领域大规 模现代化生产的管理区别很大，给管理造成的实际困难也更多。模现代化生产的管理区别很大，给管理造成的实际困难也更多。.劳动密集、自动化程度低，加之软件本身的复杂性，各种错误劳动密集、自动化程度低，加之软件本身的复杂性，各种错误 难以避免，为确保软件质量，给管理提出了更高的要求。难以避免，为确保软件质量，给管理提出了更高的要求。.使用方法繁琐，维护困难。使用方法繁琐，维护困难。.对从事软件项目开发工作的人员对从事软件项目开发工作的人员,不仅需要一定的技术水平和工不仅需要一定的技术水平和工 作经验作经验,而且要求具有良好的心理素质。因此对软件人

24、员的管理而且要求具有良好的心理素质。因此对软件人员的管理 是一个不可忽视的问题。是一个不可忽视的问题。15 软件项目特点和管理的职能软件项目特点和管理的职能()()三三.软件管理的职能软件管理的职能 .管理的目的管理的目的:按照工程预定的时间和费用按照工程预定的时间和费用,成功地完成软件的计划、开成功地完成软件的计划、开 发和维护任务。管理贯穿整个软件生存周期。发和维护任务。管理贯穿整个软件生存周期。.管理的内容管理的内容 ()()费用管理费用管理:对软件开发进行成本核算对软件开发进行成本核算,使软件生产按照商品生产的规使软件生产按照商品生产的规 律办事。包括律办事。包括:以简单、科学方法估算

25、软件开发费用以简单、科学方法估算软件开发费用,作为签定开发作为签定开发 合同的根据；管理开发费用的有效使用合同的根据；管理开发费用的有效使用,即用经济手段来保证产品即用经济手段来保证产品 如期按质完成。如期按质完成。()()质量管理质量管理:按项目的质量保证计划按项目的质量保证计划,确保各个开发阶段的开发和维护确保各个开发阶段的开发和维护 工作全部按软件工程的规范进行工作全部按软件工程的规范进行,保证软件产品的质量。保证软件产品的质量。()()配置管理配置管理:通过对于程序、文档和数据的各种版本所进行的管理，通过对于程序、文档和数据的各种版本所进行的管理，保证资料的完整性与一致性。保证资料的完

26、整性与一致性。()()项目管理：制定项目实施计划，按照计划的内容组织和实施软项目管理：制定项目实施计划，按照计划的内容组织和实施软 件的工程化生产。最终目标是以合理的费用和进度，圆满完成计划件的工程化生产。最终目标是以合理的费用和进度，圆满完成计划 所规定的软件项目。所规定的软件项目。16 成本估算成本估算()()一一.成本估算的方法成本估算的方法方法方法实实 现现不不 足足自顶自顶向下向下估计估计 自底向上自底向上估计估计 一般将上述两种方法结合使用。此外可采用系统的一般将上述两种方法结合使用。此外可采用系统的“分类活动结构图分类活动结构图”(”(简称简称)有效地避免在估计中遗漏任务。例下页

27、的系统产品的两种图。有效地避免在估计中遗漏任务。例下页的系统产品的两种图。首先估算出项目总的开发成本，然后在首先估算出项目总的开发成本，然后在项目内部进行成本分配。由少数专家参与，项目内部进行成本分配。由少数专家参与，依靠他们过去的经验，将要开发的软件与依靠他们过去的经验，将要开发的软件与过去开发过的软件进行过去开发过的软件进行“类比类比”，以估计，以估计新的软件开发所需要的工作量和成本。新的软件开发所需要的工作量和成本。将开发任务分成若干子任务将开发任务分成若干子任务,子任务又分子任务又分成子子任务成子子任务,直到每一个单元内容足够明确直到每一个单元内容足够明确为止；把各个任务单元的成本估计

28、出来为止；把各个任务单元的成本估计出来,汇汇合成项目的总成本。合成项目的总成本。该方法得到的结果比较接近实际。该方法得到的结果比较接近实际。一般对开发中的某些局部问题一般对开发中的某些局部问题或特殊困难容易低估或特殊困难容易低估,甚至没有考甚至没有考虑到。如果所开发的软件缺乏可虑到。如果所开发的软件缺乏可以借鉴的经验以借鉴的经验,在估计时就可能出在估计时就可能出现较大的误差。现较大的误差。具体工作人员只主意到自己范具体工作人员只主意到自己范围内的工作围内的工作,对综合测试、质量管对综合测试、质量管理和项目管理等涉及全局的花费理和项目管理等涉及全局的花费可能估计不足，甚至完全忽视。可能估计不足，

29、甚至完全忽视。因此可能使成本估计偏低。因此可能使成本估计偏低。17 成本估算成本估算()()用户接口用户接口控制控制CADCAD系统产品系统产品图形设计图形设计图形输出图形输出系统输入系统输入三维图三维图分析分析设计设计分析分析二维图二维图分析分析数据结构数据结构管理管理图形图形显示显示外部设备外部设备控制控制质量质量保证保证进度进度安排安排CADCAD系统开发过程系统开发过程系统测试系统测试项目管理项目管理项目计划项目计划项目开发项目开发综合综合测试测试确认确认测试测试需求需求分析分析设计设计编码与编码与单元测试单元测试系统开发过程的图系统开发过程的图系统产品的图系统产品的图18 成本估算成

30、本估算()()功功 能能生产生产率率估计估计行数行数每行每行成本成本成本成本($)人月人月获获 取取 数数 据据 更新数据库更新数据库脱脱 机机 分分 析析 产产 生生 报报 告告 实实 时时 控控 制制 总总 计计二二.估算中通常采用的技术估算中通常采用的技术 .任务分解技术任务分解技术:估计完成该项任务需要的人力估计完成该项任务需要的人力(以人月为单位以人月为单位),),再乘以每再乘以每 人每月的平均支付金额确定软件成本。人每月的平均支付金额确定软件成本。.代码行技术代码行技术:用每行代码的平均成本乘以行数确定软件成本；用每行代码的平均成本乘以行数确定软件成本；任任 务务人力人力(人月人月

31、)$人人月月成本成本($)需求分析需求分析 设设 计计编编 码码 与与单元测试单元测试 综合测试综合测试 总总 计计利用任务分解技术例子利用任务分解技术例子利用代码行技术例子利用代码行技术例子.算法模型算法模型(略略)19 人员的分配和组织人员的分配和组织()()0 0T Td dT T人力人力一一 曲线曲线(右图右图)横坐标：横坐标：(时间时间)；纵坐标；纵坐标:人力；人力；.曲线方程：曲线方程：人力人力()()()()其中其中 ()()；:曲线达到峰点的时间；曲线达到峰点的时间；：软件生存周期总工作量；：软件生存周期总工作量；一个软件项目在生命周期的各个不同阶段所需要的人员的类型及其数量是

32、不相同的。一个软件项目在生命周期的各个不同阶段所需要的人员的类型及其数量是不相同的。如：计划与分析阶段只需要很少的人，概要设计需要的人略多一些，详细设计又多一如：计划与分析阶段只需要很少的人，概要设计需要的人略多一些，详细设计又多一 些，到了编码和测试阶段所需人数最多。在运行初期，需要较多的人参加维护，但很些，到了编码和测试阶段所需人数最多。在运行初期，需要较多的人参加维护，但很 快就可减少下来。如何按照实际需要来确定各阶段所需的人力？有无规律可循？如何快就可减少下来。如何按照实际需要来确定各阶段所需的人力？有无规律可循？如何 组织？是软件开发中必须解决好的问题。组织？是软件开发中必须解决好的

33、问题。()()在之前，单位时间开发所需的人力逐渐上升；在之前，单位时间开发所需的人力逐渐上升；()()在达到峰值，单位时间开发所需的人力达到最大值；在达到峰值，单位时间开发所需的人力达到最大值；()()在之后，单位时间所需的人力逐渐下降。在之后，单位时间所需的人力逐渐下降。()()两侧的比为：，即计划与开发所需的工作量约占生存期总工作量的，两侧的比为：，即计划与开发所需的工作量约占生存期总工作量的，而维护工作量约占生存期总工作量的。而维护工作量约占生存期总工作量的。20 人员的分配和组织人员的分配和组织()()时间时间(年年)工作量工作量(人年人年)平均每年需要人数平均每年需要人数 即两年可以

34、完成的工作量个人年即两年可以完成的工作量个人年,若将开发时间压缩为人年若将开发时间压缩为人年 (时间缩短不到时间缩短不到),),而工作量将增至个人年而工作量将增至个人年(增长率达增长率达)。定律定律(时间与人员不能互换原则时间与人员不能互换原则)大量软件开发实践说明大量软件开发实践说明:向一个已经延迟的项目追加开发人员向一个已经延迟的项目追加开发人员,可能可能 使它完成得更晚。当开发人员以算术级数增长时，人员之间的通信将使它完成得更晚。当开发人员以算术级数增长时，人员之间的通信将 以几何级数增长，往往以几何级数增长，往往“得不偿失得不偿失”。.软件开发的权衡定律软件开发的权衡定律 常数常数(或

35、或)即开发工作量与开发时间的次方成反比。即开发工作量与开发时间的次方成反比。例例.某软件两种开发时间的比较某软件两种开发时间的比较:21 人员的分配和组织人员的分配和组织()()二二.人员组织人员组织 结构结构职职 能能 负责管理软件开发部门负责管理软件开发部门,在各个项目之间分配和协调各种资源。在各个项目之间分配和协调各种资源。软件软件经理经理项目项目经理经理开发开发小组小组审查审查小组小组 管理一个具体的的开发项目的各个方面管理一个具体的的开发项目的各个方面(计划、进度、审查、复查、计划、进度、审查、复查、用户界面等用户界面等)，领导，领导个程序设计小组。个程序设计小组。任任 务务每个小组

36、每个小组(人人)负责项目的一部分开发工作。负责项目的一部分开发工作。组织组织形式形式程序设程序设计小组计小组主程序主程序员小组员小组 非正式的组织形式，组长和成员完成同样的任务。多非正式的组织形式，组长和成员完成同样的任务。多数成员经验丰富、技术熟练的程序员数成员经验丰富、技术熟练的程序员.主程序员：全面负责系统的设计、编码、测试和安装主程序员：全面负责系统的设计、编码、测试和安装辅助程序员辅助程序员:协助主程序员工作。主要任务是设计测试协助主程序员工作。主要任务是设计测试 方案和分析测试结果，以验证主程序员的工作。方案和分析测试结果，以验证主程序员的工作。程序管理员程序管理员:完成和项目有关

37、的全部事务工作。完成和项目有关的全部事务工作。从事质量保证活动，在项目开发的每个阶段从事质量保证活动，在项目开发的每个阶段(软件生存周期软件生存周期)结束之前结束之前,进行技术审查和管理复审。进行技术审查和管理复审。22 进度安排进度安排()()测试测试数据数据2 2产品产品测试测试4 4测试测试计划计划2 2测试测试软件软件6 6终点终点文档文档2 2编码编码4 4设计设计4 4分析分析3 3起点起点一一.计划评审技术计划评审技术(简称技术简称技术).建立图建立图 例例.一个简单软件开发项目的图。图中的每一个圆框代表一项开发活动。一个简单软件开发项目的图。图中的每一个圆框代表一项开发活动。框

38、内的数字表示完成这一活动所需的时间框内的数字表示完成这一活动所需的时间(该例单位该例单位:月月)，框间的前头，框间的前头 代表活动发生的先后顺序。代表活动发生的先后顺序。23 进度安排进度安排()()起点起点(0,0)(0,0)测试测试计划计划2 2(0,2)(0,2)测试测试软件软件6 6(2,8)(2,8)测试测试数据数据2 2(3,5)(3,5)文档文档2 2(7,9)(7,9)产品产品测试测试4 4(11,15)(11,15)(0,3)(0,3)分析分析3 3终点终点(15,15)(15,15)设计设计4 4(3,7)(3,7)编码编码4 4(7,11)(7,11).找出关键路径找出关

39、键路径 从起点到终点从起点到终点,在每个活动框的上方标出该项活动的起止时间在每个活动框的上方标出该项活动的起止时间,如图。如图。其中需时最长的路径为关键路径。此例中需时最长个月，关键路径如其中需时最长的路径为关键路径。此例中需时最长个月，关键路径如 图紫色双前头表示。图紫色双前头表示。24 进度安排进度安排()()测试测试数据数据2 2产品产品测试测试4 4测试测试计划计划2 2测试测试软件软件6 6终点终点文档文档2 2编码编码4 4设计设计4 4分析分析3 3起点起点(0,2)(0,2)(2,8)(2,8)(3,5)(3,5)(7,9)(7,9)(0,0)(0,0)(0,3)(0,3)(7

40、,11)(7,11)(3,7)(3,7)(11,15)(11,15)(15,15)(15,15)()()()()()()()()()()()()()()()()()()()().标出每个活动最迟开始时间标出每个活动最迟开始时间 从终动到起点从终动到起点,在每个活动框的下方标出该项活动最迟起止时间。在每个活动框的下方标出该项活动最迟起止时间。如图所示。如图所示。25 进度安排进度安排()()测试测试数据数据2 2产品产品测试测试4 4测试测试计划计划2 2测试测试软件软件6 6终点终点文档文档2 2编码编码设计设计分析分析3 3起点起点()()()()()()()()()()()()()()()

41、()()()()()图的使用图的使用 ()()确保关键路径上的各项活动按时完成。确保关键路径上的各项活动按时完成。()()通过缩短关键路径上某些活动的时间，达到缩短项目开发的目的。通过缩短关键路径上某些活动的时间，达到缩短项目开发的目的。如图把设计时间从个月缩短为个月如图把设计时间从个月缩短为个月,编码从个月缩短为个月编码从个月缩短为个月,项目开发时间项目开发时间 从原来的个月缩短为个月。此时图中出现两条关键路径。对不在关键路从原来的个月缩短为个月。此时图中出现两条关键路径。对不在关键路 径上的活动，可根据需要调整起止时机，或者延缓活动的进度。径上的活动，可根据需要调整起止时机，或者延缓活动的

42、进度。26 进度安排进度安排()()活活 动动负责人负责人分分 析析测试计划测试计划设设 计计编编 码码测试软件测试软件测试数据测试数据产品测试产品测试文文 档档注注：活动开始和结束；：活动开始和结束；：活动已开始和结束；：活动已开始和结束；系统工程师；系统工程师；质量保证人员；质量保证人员；程序员程序员二图二图 图是安排软件进度计划的又一种工具。如图：图是安排软件进度计划的又一种工具。如图：图的左边列出项目的开发活动图的左边列出项目的开发活动,上方列出日历时间。在每一活动的开始和结束时上方列出日历时间。在每一活动的开始和结束时 间各画一个三角形，当活动的开始和结束时候，把三角形涂实。间各画一

43、个三角形，当活动的开始和结束时候，把三角形涂实。图优点：简单易用，容易修改，比图更加直观方便。图优点：简单易用，容易修改，比图更加直观方便。图缺点：不能显示各项活动之间的依赖关系。图缺点：不能显示各项活动之间的依赖关系。27 质量保证质量保证()()产品运行产品运行产品产品修改修改产品产品转移转移可理解性可理解性(能理解吗能理解吗?)?)可维护性可维护性(能修复吗能修复吗?)?)灵灵 活活 性性(能改变吗能改变吗?)?)可测试性可测试性(能测试吗能测试吗?)?)可移植性可移植性(能在另外机器上使用吗能在另外机器上使用吗?)?)可重用性可重用性(能再用它的某些部分吗能再用它的某些部分吗?)?)互

44、运行性互运行性(它能和另一系统结合吗它能和另一系统结合吗?)?)正确性正确性(能按需要工作吗能按需要工作吗?)?)风险风险(按计划能完成吗按计划能完成吗?)?)效率效率(完成预定工作需要计算机资源多吗完成预定工作需要计算机资源多吗?)?)完整性完整性(安全吗安全吗?)?)健壮性健壮性(对意外环境能作响应吗对意外环境能作响应吗?)?)可用性可用性(能使用它吗能使用它吗?)?)一一.软件质量软件质量 .软件质量含义软件质量含义 ()()软件与明确指定的功能和性能需求的一致性；软件与明确指定的功能和性能需求的一致性；()()软件与明确指定的文档开发标准的一致性；软件与明确指定的文档开发标准的一致性；

45、()()软件与未明确指定的，但为全部软件所期望的隐含特性的一致性。软件与未明确指定的，但为全部软件所期望的隐含特性的一致性。.影响软件质量的因素影响软件质量的因素:产品运行、产品修改、产品转移。产品运行、产品修改、产品转移。28 质量保证质量保证()()二二.软件质量保证措施软件质量保证措施 .软件质量保证的含义软件质量保证的含义 ()()它是为检验软件产品是否满足需求而采取的一系列有组织、有计划、它是为检验软件产品是否满足需求而采取的一系列有组织、有计划、规范化的活动；规范化的活动；()()它并不能保证软件的质量它并不能保证软件的质量,而是保证履行一系列检验软件质量的活动；而是保证履行一系列

46、检验软件质量的活动；()()它只能发现或诊断软件故障它只能发现或诊断软件故障,而纠正错误则是系统维护解决的问题；而纠正错误则是系统维护解决的问题；()()它工作贯穿软件开发的各个阶段。它工作贯穿软件开发的各个阶段。()()它需要独立的工作小组它需要独立的工作小组,但与开发人员和用户有关。但与开发人员和用户有关。.措施措施:评审、测试。评审、测试。三三.软件评审软件评审 .软件评审的目标。软件评审的目标。.软件评审的准则。软件评审的准则。.评审的步骤：计划；概貌介绍；准备；评审会；返工；复查。评审的步骤：计划；概貌介绍；准备；评审会；返工；复查。四四.测试测试 29 项目计划项目计划()()一一

47、.项目计划的内容项目计划的内容计划计划内内 容容概述概述阶段阶段组织组织测试测试变动控制变动控制文档文档培训培训复审和报告复审和报告安装和运行安装和运行资源和配置资源和配置索引索引一般性叙述开发的项目一般性叙述开发的项目,描述计划组织描述计划组织,并简述文档其余部分内容。并简述文档其余部分内容。详细说明开发周期各个阶段应完成的日期及不同阶段的重叠时间。详细说明开发周期各个阶段应完成的日期及不同阶段的重叠时间。规定从事这个开发项目的每个小组的具体责任。规定从事这个开发项目的每个小组的具体责任。概述测试所需的工具，及完成系统测试的过程和分工。概述测试所需的工具，及完成系统测试的过程和分工。确定在系

48、统开发过程中需求变动的管理控制机制。确定在系统开发过程中需求变动的管理控制机制。定义与管理与项目有关部分的文档。定义与管理与项目有关部分的文档。培训从事开发的程序员和使用系统的用户计划。培训从事开发的程序员和使用系统的用户计划。讨论如何报告项目的状况，并确定对项目进展情况进行正式复审的计划。讨论如何报告项目的状况，并确定对项目进展情况进行正式复审的计划。描述在用户现场安装该系统的过程。描述在用户现场安装该系统的过程。概述关键的细节计划概述关键的细节计划进度、阶段目标和按合同规定应交付的系统配置成分。进度、阶段目标和按合同规定应交付的系统配置成分。30 项目计划项目计划()()二二.项目报告项目

49、报告 .报告内容：在这段时间内已经完成的工作；下阶段计划要完成的工作；报告内容：在这段时间内已经完成的工作；下阶段计划要完成的工作；问题范围；到目前为止已经用掉的成本；预算执行情况及其它有关信息。问题范围；到目前为止已经用掉的成本；预算执行情况及其它有关信息。.制定项目计划时，应确立一系列阶段目标。在应该完成的每个阶段目标制定项目计划时，应确立一系列阶段目标。在应该完成的每个阶段目标 时时(或定期时间或定期时间)，开发人员应该把正式的进展报告交给管理人员。，开发人员应该把正式的进展报告交给管理人员。三三.变动控制变动控制 .任何软件开发都是迭代过程任何软件开发都是迭代过程,即在设计软件时会发现

50、需求说明的中问题即在设计软件时会发现需求说明的中问题,在实现过程中又会暴露出设计中的错误。预先计划控制变动的机制在实现过程中又会暴露出设计中的错误。预先计划控制变动的机制,建建 立评价变动的影响和把发生的变动记录下来的过程是十分重要的。立评价变动的影响和把发生的变动记录下来的过程是十分重要的。.变动通常分为两类：变动通常分为两类：()()为了改正小错误需要的变动。为了改正小错误需要的变动。()()为了增加和删除某些功能，或者为了改变某个功能的方法而变动的为了增加和删除某些功能，或者为了改变某个功能的方法而变动的 变动。变动。.高级管理人员应该注意防止在工程延期或成本超过预算时高级管理人员应该注