图76软件维护的机构 维护申请提交给一个维护管理员,他把申请交给某个系统监督员去评价。一旦做出评价, 由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中,由配置管理员严格 把关,控制修改的范围,对软件配置进行审计。 维护管理员、系统监督员、修改负责人等,均代表维护工作的某个职责范围。修改负责 人、维护管理员可以是指定的某个人,也可以是一个包括管理人员、高级技术人员在内的小 组。系统监督员可以有其他职责,但应具体分管某一个软件包。 在开始维护之前,就把责任明确下来,可以大大减少维护过程中的混乱。 (2)软件维护工作流程 先确认维护要求。这需要维护人员与用户反复协商,弄清错误概况以及对业务的影响 大小,以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。 对于改正性维护申请,从评价错误的严重性开始。如果存在严重的错误,则必须安排 人员,在系统监督员的指导下,进行问题分析,寻找错误发生的原因,进行“救火”性的紧 急维护;对于不严重的错误,可根据任务、机时情况、视轻重缓急,进行排队,统一安排时 对于适应性维护和完善性维护申请,需要先确定每项申请的优先次序。若某项申请的 优先级非常高,就可立即开始维护工作,否则,维护申请和其它的开发工作一样,进行排队, 统一安排时间 尽管维护申请的类型不同,但都要进行同样的技术工作。这些工作有:修改软件需求 说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试(回归测试) 确认测试、软件配置评审等 ■在每次软件维护任务完成后,最好进行一次情况评审,确认:在目前情况下,设计、 编码、测试中的哪一方面可以改进?哪些维护资源应该有但没有?工作中主要的或次要的障 碍是什么?从维护申请的类型来看是否应当有预防性维护? (3)维护评价 评价维护活动比较困难,因为缺乏可靠的数据。但如果维护记录做得比较好,就可以得 出一些维护“性能”方面的度量值。可参考的度量值如: 每次程序运行时的平均出错次数 花费在每类维护上的总“人时”数 每个程序、每种语言、每种维护类型的程序平均修改次数 因为维护,增加或删除每个源程序语句所花费的平均“人时”数: 用于每种语言的平均“人时”数 维护申请报告的平均处理时间 各类维护申请的百分比。 这七种度量值提供了定量的数据,据此可对开发技术、语言选择、维护工作计划、资源 分配、以及其它许多方面做出判定。因此,这些数据可以用来评价维护工作 4.程序修改的步骤及修改的副作用 (1)分析和理解程序 经过分析,全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面, 软件的可理解性和文档的质量非常重要。必须: 理解程序的功能和目标 掌握程序的结构信息,即从程序中细分出若干结构成分。如程序系统结构、控制结8 图 7.6 软件维护的机构 维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价， 由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格 把关，控制修改的范围，对软件配置进行审计。 维护管理员、系统监督员、修改负责人等，均代表维护工作的某个职责范围。修改负责 人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小 组。系统监督员可以有其他职责，但应具体分管某一个软件包。 在开始维护之前，就把责任明确下来，可以大大减少维护过程中的混乱。 (2) 软件维护工作流程 ▪ 先确认维护要求。这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响 大小，以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。 ▪ 对于改正性维护申请，从评价错误的严重性开始。如果存在严重的错误，则必须安排 人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，进行“救火”性的紧 急维护； 对于不严重的错误，可根据任务、机时情况、视轻重缓急，进行排队，统一安排时 间。 ▪ 对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。若某项申请的 优先级非常高，就可立即开始维护工作，否则，维护申请和其它的开发工作一样，进行排队， 统一安排时间。 ▪ 尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求 说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试( 回归测试)、 确认测试、软件配置评审等。 ▪ 在每次软件维护任务完成后，最好进行一次情况评审，确认：在目前情况下，设计、 编码、测试中的哪一方面可以改进？哪些维护资源应该有但没有？工作中主要的或次要的障 碍是什么？从维护申请的类型来看是否应当有预防性维护？ (3) 维护评价 评价维护活动比较困难，因为缺乏可靠的数据。但如果维护记录做得比较好，就可以得 出一些维护“性能”方面的度量值。可参考的度量值如： ▪ 每次程序运行时的平均出错次数； ▪ 花费在每类维护上的总“人时”数； ▪ 每个程序、每种语言、每种维护类型的程序平均修改次数； ▪ 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； ▪ 用于每种语言的平均“人时”数； ▪ 维护申请报告的平均处理时间； ▪ 各类维护申请的百分比。 这七种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源 分配、以及其它许多方面做出判定。因此，这些数据可以用来评价维护工作。 4. 程序修改的步骤及修改的副作用 (1) 分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面， 软件的可理解性和文档的质量非常重要。必须： ▪ 理解程序的功能和目标； ▪ 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结