第八章软件维护ppt课件
合集下载
软件工程导论PPT课件-第8章-维护
改错或修改的要求不能及时满足引起的用户不满； 维护时的改动，引入潜伏错误，导致软件质量降低； 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量：生产性劳动+非生产性劳动。
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件工程课件之第8章维护第6版张海潘编著
(1) 必须描述如何使用这个系统，没有这种描述时即 使是最简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可 维护的。
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
软件工程 第8章 软件维护
8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。
8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。
8.2.3 非结构化维护
无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
软件工程 第8章 软件维护 ppt
3. 维护的事件流
图8.2 维护阶段的事件流
4. 保存维护记录 ◆ 哪些数据是值得记录的? Swanson 提出了下述内容： ① 程序标识； ② 源语句数； ③ 机器指令条数； ④ 使用的程序设计语言； ⑤ 程序安装的日期； ⑥ 自从安装以来程序运行的次数； ⑦ 自从安装以来程序失效的次数； ⑧ 程序变动的层次和标识； ⑨ 因程序变动而增加的源语句数； 因程序变动而删除 的源语句数； 每个改动耗费的人时数； 程序改动的 日期； 软件工程师的名字； 维护要求表的标识； 维 护类型； 维护开始和完成的日期； 累计用于维护的 人时数； 与完成的维护相联系的纯效益。
2. 文档重构
◆ 老程序固有的特点是缺乏文档。具体情况不同，处理这
个问题的方法也不同： 1）如果一个程序是相对稳定的，正在走向其有用生命的终 点，而且可能不会再经历什么变化，那么，让它保持现 状。 2）为了便于今后的维护，必须更新文档，不是一下子把某 应用系统的文档全部都重建起来，而是只针对系统中当 前正在修改的那些部分建立完整文档。随着时间流逝， 将得到一组有用的和相关的文档。 3）如果某应用系统是完成业务工作的关键，而且必须重构 全部文档，则仍然应该设法把文档工作减少到必需的最 小量。
5. 评价维护活动 ◆根据保存的维护记录，至少可以从下述7个方面 度量维护工作：
(1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序 变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。
5. 数据重构 ◆ 与代码重构不同，数据重构发生在相当低的抽象 层次上，它是一种全范围的再工程活动。 ◆ 在大多数情况下，数据重构始于逆向工程活动， 分解当前使用的数据体系结构，必要时定义数据 模型，标识数据对象和属性，并从软件质量的角 度复审现存的数据结构。 ◆ 当数据结构较差时，应该对数据进行再工程。 ◆ 由于数据体系结构对程序体系结构及程序中的算 法有很大影响，对数据的修改必然会导致体系结 构或代码层的改变。
软件维护ppt课件-PPT文档资料
第八章、软件维护
一、计算机病毒 二、硬盘的整理 三 虚拟机的使用
计算机病毒的特征
非授权可执行性 隐蔽性 传染性 潜伏性 表现性或破坏性 可触发性
计算机病毒的分类
病毒存在的媒体
病毒可以划分为网络病毒，文件病毒，引导型病毒。
病毒破坏的能力
根据病毒破坏的能力可划分为以下几种： 无害型： 除了传染时减少磁盘的可用空间外，对系统没有其它
影响。 无危险型： 这类病毒仅仅是减少内存、显示图像、发出声音 危险型： 这类病毒在计算机系统操作中造成严重的错误。 非常危险型：这类病毒删除程序、破坏数据、清除系统内存区和
操作系统中重要的信息。
计算机病毒的预防
不打开来历不明邮件的附件 首次安装防病毒软件时，一定要对计算机做一
最新病毒介绍
AV杀手病毒名称： Trojan/KillAV.ak“AV杀手”变种ak是“AV杀手”木马家族的最新 成员之一，采用Delphi语言编写，并经过加壳处理。“AV杀手”变种ak运 行后，自我修改文件属性为“隐藏”。强行篡改注册表相关键值，致使文件 夹选项中的“显示隐藏文件”功能失效。利用Windows映像劫持技术 （IFEO），修改注册表，致使许多与安全相关的软件无法启动运行。在被 感染计算机的后台调用系统“spoolsv.exe”进程，将恶意代码注入其中并 调用运行，隐藏自我，防止被查杀。在后台连接骇客指定远程服务器站点， 下载恶意程序并在被感染计算机上自动调用运行。在所有盘根目录下生成 “autorun.inf”文件（磁盘映像劫持文件）和病毒体文件，实现用户一双 击盘符就启动“AV杀手”变种ak运行的功能。
次彻底的病毒扫描 不要从任何不可靠的渠道下载任何软件 不要用共享的软盘安装软件，或者更为糟糕的
一、计算机病毒 二、硬盘的整理 三 虚拟机的使用
计算机病毒的特征
非授权可执行性 隐蔽性 传染性 潜伏性 表现性或破坏性 可触发性
计算机病毒的分类
病毒存在的媒体
病毒可以划分为网络病毒，文件病毒，引导型病毒。
病毒破坏的能力
根据病毒破坏的能力可划分为以下几种： 无害型： 除了传染时减少磁盘的可用空间外，对系统没有其它
影响。 无危险型： 这类病毒仅仅是减少内存、显示图像、发出声音 危险型： 这类病毒在计算机系统操作中造成严重的错误。 非常危险型：这类病毒删除程序、破坏数据、清除系统内存区和
操作系统中重要的信息。
计算机病毒的预防
不打开来历不明邮件的附件 首次安装防病毒软件时，一定要对计算机做一
最新病毒介绍
AV杀手病毒名称： Trojan/KillAV.ak“AV杀手”变种ak是“AV杀手”木马家族的最新 成员之一，采用Delphi语言编写，并经过加壳处理。“AV杀手”变种ak运 行后，自我修改文件属性为“隐藏”。强行篡改注册表相关键值，致使文件 夹选项中的“显示隐藏文件”功能失效。利用Windows映像劫持技术 （IFEO），修改注册表，致使许多与安全相关的软件无法启动运行。在被 感染计算机的后台调用系统“spoolsv.exe”进程，将恶意代码注入其中并 调用运行，隐藏自我，防止被查杀。在后台连接骇客指定远程服务器站点， 下载恶意程序并在被感染计算机上自动调用运行。在所有盘根目录下生成 “autorun.inf”文件（磁盘映像劫持文件）和病毒体文件，实现用户一双 击盘符就启动“AV杀手”变种ak运行的功能。
次彻底的病毒扫描 不要从任何不可靠的渠道下载任何软件 不要用共享的软盘安装软件，或者更为糟糕的
软件工程课件-第八章维护ppt
例如，在软件交付用户使用之后，解决在开发时没有测 试所有可能的执行通路而带来的问题；
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步，大约每 过38个月就有新一代的硬件宣告出现；另一方面，应用软 件的使用寿命却很容易超过十年，远远长于最初开发这个 软件时的运行环境的寿命。因此，适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动，是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性，或为了给未来的 改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对
于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价，见下页图示。
维护机构
维护要求 （软件问题报告）
● 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题，都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题：
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步，大约每 过38个月就有新一代的硬件宣告出现；另一方面，应用软 件的使用寿命却很容易超过十年，远远长于最初开发这个 软件时的运行环境的寿命。因此，适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动，是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性，或为了给未来的 改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对
于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价，见下页图示。
维护机构
维护要求 （软件问题报告）
● 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题，都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题：
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
虑 平均每个程序、每种语言、每种维护类型所做的程序变动数；
7
8.4 可维护性(1)
决定软件可维护性的因素
因素
内
容
软件的结构、接口、功能和内部过程的难易程度；
可理 解性
模块化、详细设计文档、结构化设计、源代码内部的文档；
程序设计语言。
诊断和测试的难易程度取决于软件容易理解的程度；
可测 良好的文档对诊断和测试是至关重要的诊断和测试； 试性 软件结构、可用的测试工具和调试工具，以往的测试过程是很重要的；
二.软件维护包括四类活动：改正性维护、适应性维护、完善性维 护和预防性维护。
三.软件的可理解性、可测试性和可维修性是决定软件可维护性的 基本因素。
四.软件生存周期的每个阶段和软件可维护性密切相关。 五.文档是影响软件可维护性的决定因素。 六.文档分为用户文档和系统文档，它们都必须和程序代码同时维
护才有真正的价值。
维护
满足用户在使用过程中提出增加新的功能或修改已有
种类 完善性 功能的建议而进行的工作；
预防性 为了改善未来的可维护性或可靠性而修改软件的工作。
软件维护的工作量非常大，不同应用领 改正性 17—21% 适应性 18—25% 域的维护成本差别也很大。一般大型软件 的维护成本平均高达开发成本的四倍左右。 完善性 50—66% 预防性 4%左右
软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支
出的20-30%到70-80%。而无形的代价更是无法估计的。
2
8.3 维护的过程(1)
一.建立软件维护的组织,在组织中有总负责人、系统管理员和维护管理员等。 二.编写维护的报告
用标准化的格式表达所有软件维护的要求。要求包括下列内容： 1.满足维护要求表中提出的要求所需要的工作量； 2.维护要求的性质； 3.该项要求的优先顺序； 4.与修改有关的事后数据。 三.为每一个维护要求规定一个标准化的事件序列(见下页图形) 1.明确维护的类型:纠错性维护,进一步分清是适应性维护还是完善性维护； 2.对纠错性维护从评价错误的严重性开始,分别不同程度采取不同的方法； 3.适应性维护和完善性维护沿着同一路径推进，确定优先顺序后开始工作； 4.对恶性软件故障，应把所有的资源用来解决问题； 5.对任何类型的维护都要进行同样的技术工作，包括：修改软件设计、设计
据 程序变动的层次和标识；
累计用于维护的人时数；
因程序变动而增加的源语句数； 与完成的维护相联系的纯效益。
工 每次程序运行平均失效的次数； 用于同一类维护活动的总人时数；
作 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 量 考 不同维护类型所占的时间比。 增加或删除一个源语句平均花费的人时数
使用手册:简要说明如何使用这个系统； 参考手册：详尽描述用户可以使用的系统设施及方法，以及可能产
生的出错信息含义；
操作员指南：说明操作员如何处理使用中出现的各种情况。 系统 从问题定义、需求说明到验收测试这样一系列和系统实现有关的文9档。 文档
第八章 小 结
一.软件维护是软件生存周期的最后一个阶段，也是持续时间最长、 代价最大的一个阶段。
10
第八章 习 题
1.为什么说软件的维护是不可避免的？ 2.软件的维护一般分为哪几类？ 3.影响软件维护的因素有哪些？ 4.软件维护困难主要表现在什么方面？ 5.决定软件可维护性的因素？ 6.软件价格应该计入维护成本吗？为什么？ 7.对前面各章中分析的各应用系统，提出改进和扩充功能的要求？
(1)教材销售采购系统； (2)图书管理系统； (3)房产管理系统。
一个软件项目在生命周期的各个不同阶段所需要的人员的类型及其数量是不相同的。 如：计划与分析阶段只需要很少的人，概要设计需要的人略多一些，详细设计又多一 些，到了编码和测试阶段所需人数最多。在运行初期，需要较多的人参加维护，但很 快就可减少下来。如何按照实际需要来确定各阶段所需的人力？有无规律可循？如何 组织？是软件开发中必须解决好的问题。
软件项目的规模越大，所需要
的管理支持工作量越大。统计资料
表明在软件项目的规模达到一定程
工 作
度时，所需的软件管理工作量将达 量
到总工作量的一半。如图所示：
软件项目的规模,决定了采用怎样 的管理水平、开发工具和开发方法。
技术工作
100% 50%
管理工作 软件规模
13
9.1 软件项目特点和管理的职能(2)
第八章软件维护ppt课件
8.1 软件维护的概念
软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。
问题
内
容
维护 满足用户对已开发产品的性能与运行环境不断提高的要求，进而
目的 达到延长软件寿命的目的。
改正性 对程序使用期间发现的程序错误进行诊断和改正的过程；
适应性 配合变化了的环境进行修改软件的活动；
一.Rayleigh-Norden 曲线(右图)
横坐标：T(时间)；纵坐标:人力；
人力
1.曲线方程：
人力=(K/Td)×eS×(T/Td)
其中 s=－0.5 ×(T/Td)2；
Td:曲线达到峰点的时间； K：软件生存周期总工作量；
0
Td
T
(1)在Td之前，单位时间开发所需的人力逐渐上升；
(2)在Td达到峰值，单位时间开发所需的人力达到最大值；
自底 向上 估计
将开发任务分成若干子任务,子任务又 分成子子任务,直到每一个单元内容足够 明确为止；把各个任务单元的成本估计出 来,汇合成项目的总成本。
该方法得到的结果比较接近实际。
具体工作人员只主意到自己范 围内的工作,对综合测试、质量管 理和项目管理等涉及全局的花费 可能估计不足，甚至完全忽视。 因此可能使成本估计偏低。
外部设备 控制
CAD系统开发过程的WBS图
CAD系统开发过程
项目计划
项目开发
系统测试
项目管理
需求 分析
设计
编码与 单元测试
综合 测试
确认 测试
质量 保证
进度 安排
18
9.2 成本估算(3)
二.估算中通常采用的技术 1.任务分解技术:估计完成该项任务需要的人力(以人月为单位),再乘以每 人每月的平均支付金额确定软件成本。 2.代码行技术:用每行代码的平均成本乘以行数确定软件成本；
(3)在Td之后，单位时间所需的人力逐渐下降。
(4)Td两侧的比为4：6，即计划与开发所需的工作量约占生存期总工作量的40%，
而维护工作量约占生存期总工作量的60%。
20
9.3 人员的分配和组织(2)
2.软件开发的权衡定律
E=常数/ (T或Td)4 即开发工作量与开发时间的4次方成反比。 例.某软件两种开发时间的比较:
利用任务分解技术例子
任务 需求分析
人力 (人月)
5.0
$/人 月
3400
设 计 15.0 3200
编码与 单元测试
8.0 2650
综合测试 16.5 2900
总 计 44.5
3.算法模型(略)
成本($)
1700 48000 21200
47850 134050
利用代码行技术例子
功能
获取数据 更新数据库 脱机分析 产生报告 实时控制
14
9.1 软件项目特点和管理的职能(3)
二.软件项目管理的特殊困难 1.智力密集,可见性差,对没有软件知识和软件开发实践经验的人 员很难做好管理工作。 2.特定的开发环境,加上特定的开发方法、工具和语言。建立在这 种内容、形式各异基础上的研制或生产方式，与其他领域大规 模现代化生产的管理区别很大，给管理造成的实际困难也更多。 3.劳动密集、自动化程度低，加之软件本身的复杂性，各种错误 难以避免，为确保软件质量，给管理提出了更高的要求。 4.使用方法繁琐，维护困难。 5.对从事软件项目开发工作的人员,不仅需要一定的技术水平和工 作经验,而且要求具有良好的心理素质。因此对软件人员的管理 是一个不可忽视的问题。
一般将上述两种方法结合使用。此外可采用系统的“分类活动结构图”(简称 WBS)有效地避免在估计中遗漏任务。例下页的CAD系统产品的两种WBS图。
17
9.2 成本估算(2)
CAD系统产品的WBS图
系统输入
CAD系统产品 图形设计
图形输出
用户接口 数据结构 二维图 三维图
控制
管理
分析
分析
设计 分析
图形 显示
总计
生产 率 92 102 134 145 80
估计 行数
840 1210
600 450 1100
每行 成本 36 18 24 11 45
成本($) 人月
30240 9.1 21780 11.8 14400 4.4
4950 3.1 49500 13.7 120870 42.1
19
9.3 人员的分配和组织(1)
件的工程化生产。最终目标是以合理的费用和进度，圆满完成计划
所规定的软件项目。
16
9.2 成本估算(1)
一.成本估算的方法
方法
实
现
不足
自顶 向下 估计
首先估算出项目总的开发成本，然后在 一般对开发中的某些局部问题 项目内部进行成本分配。由少数专家参与， 或特殊困难容易低估,甚至没有 依靠他们过去的经验，将要开发的软件与 考虑到。如果所开发的软件缺乏 过去开发过的软件进行“类比”，以估计 可以借鉴的经验,在估计时就可 新的软件开发所需要的工作量和成本。 能出现较大的误差。
时间(年) 2.0 1.84
一.软件项目的特点 1.软件项目与其他任何产业项目不同，它是算法、思想、概念、 组织、流程、效率、优化等的融合体； 2.开发软件项目产品,在多数情况下,用户给不出明确的想法和要 求。 3.在开发过程中，程序及其相关的文档资料常常需要修改，在修 改过程中又可能带来新的问题，且这些问题要在很久以后才会 发现。 4.在研制开发过程中，文档资料是不可缺少的，但工作量又是巨 大的,往往也是人们不愿去作的。 5.参加软件项目的工作人员，要求具有一定的业务水平和实际工 作经验，而很难完全避免的人员流动，对工作的影响是很大的。 离开的人员不仅带走了重要的信息，而且带走了工作经验。