第7章 软件维护与项目管理.ppt

7;7.1软件维护;2．软件维护的内容;完善性维护;7.1.2软件的可维护性; 软件的可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。 软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。对于不同类型的维护，这七种特性的侧重点也是不相同。;2．可维护性质量;3．提高可维护性的方法;（3）建立明确的质量保证;（4）选择可???护的语言;7.1.3软件维护的实施;（1）维护组织机构 对于大型软件系统，建立一个专门的维护组织机构是必需的。即使是对较小的软件系统，也要委派一个专人负责软件维护工作，特别是收集、保存、整理维护活动的文档资料的工作是必须随时要做的。 在维护活动开始之前必须明确维护活动的审批制度。每个维护要求都要通过维护管理员转交给系统管理员去评价。系统管理员对维护申请做出评价后，由主管部门（人）决定是否进行软件修改。接到审批的维护申请报告后，将维护任务下达给指定的维护人员，并监控维护活动有条不紊地开展。合理的组织机构和精干的维护人员是保障维护活动顺利实施的基础。;（2）维护报告 任何维护申请都应该按规范化的方式提出。通常要求用户填写维护申请表。表中必须完整地描述每个错误发生的环境，包括：输入数据、输出结果等有关信息。对于适应性或完善性的维护要求，还应该提出一份修改说明书，提出用户希望的修改。维护申请表交维护组织后，经有关人员认真分析，并根据分析结果制定软件修改报告，内容应包括：;2．维护阶段;（4）在接受修改阶段，由请求的提交者进行检查，以确保所做的修改解决了相应的请求。 （5）迁移阶段（比如平台迁移）是个特例，并不会在所有的维护任务中都出现。如果软件必须在功能没有任何改变的情况下迁移到另一个平台上，那么这个阶段将被实施，通常这项任务会被指派给一个维护工程团队。 （6）最后一个维护阶段，也并不会在每个软件中都发生，就是对软件某一部分的弃用。;3．维护问题;（3）当需要对软件进行维护时，很难指望熟悉软件系统的原开发人员能全力以赴地亲临现场参与维护活动。 （4）绝大多数软件在设计时没有考虑将来的修改。 （5）软件维护不是一项吸引人的工作。最出色的、成功的维护也只不过是保证他人开发的系统能正常运行，而且维护别人开发的软件经常受挫，使得维护人员无成就感。;7.2 软件再工程;;(1)库存目录分析(Inventory Analysis);它访问的数据库。 过去18 个月所报告的错误。 用户数量。 它被安装的机器数量。 程序结构的复杂性、代码的复杂性和文档的复杂性。 文档的质量。 整体可维护性(等级值，scale value)。 预期寿命(以年算)。 预期在未来36 个月内的修改次数。 年度维护成本。; 应该对每一个现存的应用收集上面列出的信息，通过按照业务重要程度、寿命、当前可维护性、以及其他局部重要标准对这些信息排序，可以选出再工程的候选者，然后可以明智地分配资源。 必须注意：上面描述的目录表应该定期整理修订，应用的状况(如，业务重要程度)可能随时间发生变化，其结果是：再工程的优先级将发生变化。;(2)文档重构（document restructuring）; 选项2：文档必须更新，但是，我们只有有限的资源。我们将使用“使用时建文档”的方法。可能不需要对某应用全部重构文档，而是对系统中当前正在进行改变的那些部分建立完整文档。随时间流逝，将得到一组有用的和相关的文档。 选项3：系统是业务关键的，而且必须完全地重构文档。即使在此情形，明智的方法是设法将文档工作减少到必需的最小量。 每个选项均是可行的，软件组织必须选择最适合于每种情形的方法;(3)逆向工程(reverse engineering); 软件的逆向工程是相当类似的。然而，在大多数情况下，被逆向工程的程序不是来自于竞争者，而是公司自己的软件(经常是很多年以前的)。将被理解的“秘密”是未开发过相关规约所带来的模糊不明。因此，软件的逆向工程是分析程序以在比源代码更高的抽象层次上创建程序的某种表示的过程。 逆向工程是一个设计恢复过程，逆向工程工具从现存的程序中抽取数据、体系结构和过程的设计信息。;(4)代码重构(code restructuring);(5)数据重构(data restructuring); 当数据结构较差时(例如，平坦文件正被实现，而关系型方法将大大地简化处理)，数据被再工程。 因为数据体系结构对程序体系结构及其中的算法有很强的影响，对数据的改变将总是会导致体系结构或代码层的改变。;(6)正向工程