第08章 维护.ppt

* * * * 用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的； 系统文档描述系统设计、实现和测试等各方面的内容。 * * * * * * 第一种做法很盲目，通常人们采用后3种做法。其中第4种做法称为软件再工程，这样的维护活动也就是本章8.1节中所说的预防性维护，而第3种做法实质上是局部的再工程。 * * * * * * * * * * * * 本章结束 * * * * * 计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件宣告出现，经常推出新操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；另外，应用软件的使用寿命却很容易超过10年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。 * * * * * 这是最明显的代价，但是很显然这不是唯一的代价。 * * * （1）c：复杂程度——非结构化设计和缺少文档都会增加软件的复杂程度 （2）软件的开发途径不好，即没有使用软件工程方法学 * 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。 * * * * * * * 首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误(改正性维护)，而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。 * * 当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题。如果对一个组织来说，“救火”是常见的过程，那么必须怀疑它的管理能力和技术能力。 * * * 缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。 * * * * * 8.3 软件维护的过程 3. 维护的事件流 右图8.1描绘了一项维护要求而引出的一串事件。 首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误(改正性维护)，而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。 8.3 软件维护的过程 8.3 软件维护的过程 由上图可知，对一项改正性维护要求(图中“错误”通路)的处理，从估量错误的严重程度开始。如果是一个严重的错误，则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。 适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样。如果一项维护要求的优先次序非常高，可能立即开始维护工作。 8.3 软件维护的过程 8.3 软件维护的过程 不管维护类型如何，都需要进行同样的技术工作。包括： 修改软件设计、复查、必要的代码修改、单元测试和集成测试(包括使用以前的测试方案的回归测试)、验收测试和复审。 不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。 8.3 软件维护的过程 8.3 软件维护的过程 在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题。 在当前处境下设计、编码或测试的哪些方面能用不同方法进行? 哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。 8.3 软件维护的过程 8.3 软件维护的过程 4. 保护维护记录 Swanson提出了： 1程序标识；2源语句数；3机器指令条数；4使用的程序设计语言；5程序安装的日期；6自从安装以来程序运行的次数；7自从安装以来程序失效的次数；8程序变动的层次和标识；9因程序变动而增加的源语句数；10因程序变动而删除的源语句数；11每个改动耗费的人时数；12程序改动的日期；13软件工程师的名字；14维护要求表的标识；15维护类型；16维护开始和完成的日期；17累计用于维护的人时数；18与完成的维护相联系的纯效益。 应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库的基础。 哪些数据是值得记录的？ 8.3 软件维护的过程 8.3 软件维护的过程 5. 评价维护活动 可以