软件维护-软件文档编制.ppt

第七章 软件维护与软件文档编制 ; 软件投入运行后，软件的开发工作已经结束，进入软件的维护阶段。软件维护所需的工作量相当大，许多国外的软件开发组织估计，软件维护所占的比例占有软件整个生命周期的60%以上的工作量，随着软件规模和数量的增大，软件维护工作将会束缚开发组织的手脚，使他们没有余力开发新的软件。人们对软件维护工作的认识加深后，软件技术服务已经可以独立承包给独立的技术厂商，由专门的技术服务公司进行软件维护，软件开发公司得以继续开发新的软件产品。 ;7.1 软件维护的内容 ;7.1 软件维护的内容 ;7.1 软件维护的内容 ;7.2 影响软件维护工作的主要因素 ;7.2 影响软件维护工作的主要因素 ;7.2 影响软件维护工作的主要因素 ;7.2 影响软件维护工作的主要因素 ;7. 3 软件维护的特点;7.3.1 软件工程与软件维护的关系;无形的维护成本： （1）一些看起来是合理的改错或修改的要求不能及时满足，使得用户不满意； （2）维护时产生的改动，可能会带来新的潜伏的故障，从而降低了软件的整体质量； （3）当必须把软件开发人员抽调去进行维护工作时，将在开发过程中造成混乱。;用于软件维护的工作量可以分为两部分：一部分用于生产性活动，另一部分用于非生产性活动。下面的表达式是由Belady和Lehman提出的维护工作量的计算模型：;（1）理解他人编写的程序一般都有一定的困难性。 （2）软件配置的文档严重不足甚至没有，或者没有合格的文档。 （3）当需要对软件进行维护时，由于软件人员经常流动，维护阶段持续的时间又很长，所以一般不能指望由原来的开发人员来完成或提供软件的解释。 （4）绝大多数软件在设计时没有考虑到将来的修改问题。 （5）软件维护可以说是一项毫无吸引力的工作。之所以形成这样一种观念，一方面是因为软件维护工作量大，看不到什么“成果”，更主要的原因是因为维护工作难度大，又经常遭受挫折。;7.4 软件维护过程;7.4.1 维护机构;7.4.2 维护申请报告 ;7.4.3 维护的工作流程;无论是哪一种类型的维护，都要进行以下工作：;7.4.4 维护记录 ;（8）程序修改的层次和名称；;7.4.5 维护评价 ;7.5 软件可维护性;可以从以下四个方面来度是软件的可维护性： 1．可理解性 2．可测试性 3．可修改性 4．可移植性;7.5.2 提高软件可维护性的方法 ;7.6 软件维护的副作用;（1）重新定义局部常量或全程常量； （2）重新定义记录格式或文件格式； （3）改变一个数组或高阶数据结构的大小； （4）修改全程变量； （5）重新初始化控制标记或指针； （6）重新排列输入输出或子程序的自变量。 修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。;维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修改没有反映在设计文档或用户文档中时，就会发生文档的副作用。 每当对数据流图、软件结构、模块算法过程和其它有关的特征进行修改时，必须同时对相应的文档资料进行更新。 在软件再次交付使用之前，对整个软件配置进行评审将大大减少文档的副作用。实际上，某些维护申请的提出只是由于用户文档不够清楚。这时，只需对文档进行维护即可，并不要求修改软件设计或源程序。;7.7 软件版本控制 ;7. 8 软件工程标准中???文档标准 ;7.8.1 标准化机构与组织 ;7.8.1 标准化机构与组织 ;7.8.1 标准化机构与组织 ;7.8.1 标准化机构与组织 ;7.8.1 标准化机构与组织 ;7.8.2 文档的作用 ;7.8.2 文档的作用 ;7.8.2 文档的作用 ;7.8.2 文档的作用 ;7.8.3 文档的分类和标准 ;7.8.3 文档的分类和标准 ;7.9 软件文档编制的内容 ;7.9 软件文档编制的内容 ;7.9 软件文档编制的内容 ;7.9 软件文档编制的内容 ;7.9 软件文档编制的内容 ;7.9 软件文档编制的内容 ; 以上这些文档，在项目开发的各个阶段的工作开展时，随之编制，有的在一个阶段进行，有的则需跨越多个阶段，如图7-1所示。;7.10 文档编制的质量要求 ;7.10 文档编制的质量要求 ;7.10 文档编制的质量要求 ;7.10 文档编制的质量要求 ;7.11 文档的管理和维护 ;7.11 文档的管理和维护 ;7.11 文档的管理和维护 ;习题七 ;习题七 ;习题七 ;习题七