第7章维护(完整)要点.ppt

* 上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。 * 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。 本书前面各章已经较详细地介绍了各个阶段应该产生的文档，此处不再重复。 * * * 每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中很可能因文档不完全符合实际而不能正确理解软件，从而在维护中引入过多的错误。 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。 如果在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档做必要的维护。 * 在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%～40%，1980年上升为40%～60%，1990年上升为70%～80%。 维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有： * M表示维护工作的总工作量，P表示生产性活动的工作量，K表示经验常数， C表示复杂性程度，D表示维护人员对软件的熟悉程度。　　这个公式表明，若C越大，D越小，则维护工作量将成指数规律增加。C增加表示软件未采用软件工程方法开发，D减小表示维护人员不是原来的开发人员，对软件的熟悉程度低，重新理解软件花费很多的时间。 * （1） 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。 （2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 （3） 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。 （4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 * * 为了有效地进行软件维护，应该事先开始组织工作，建立维护机构。这种维护机构通常以维护小组形式出现，维护小组分为临时维护小组和长期维护小组。 虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。图8.1描绘了上述组织方式。 在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。 * * * * * * * 首先，要求确定即将进行维护工作的类型。在多数情况下，用户把维护申请看成是软件错误的一个征状，即改正性维护，而开发人员将此维护申请当作适应性维护或完善性维护。如果存在不同意见，必须经过协商解决。　　在图6.2中，改正性维护工作是从评价错误的严重程度开始的，如果存在某个关键功能不能运行，这样的错误就应在系统管理员的指导下分派人员，立即开始分析问题；对于错误不严重的改正性维护，则要与其他需要软件开发资源的任务一起，统一安排进行。　　在有些情况下，有的错误非常严重，以致不得不临时放弃正常的维护控制工作程序，即不对修改可能带来的副作用作出评价，也不对文档作相应的更新，而立即进行代码的修改。这是一种救火式的改正性维护，只有在非常紧急的情况下才使用，这种维护在全部维护中只占很小的比例。应当说明的是，救火式不是取消，只是推迟了维护所需要的控制和评价。一旦危机取消，这些控制和评价活动必须进行，以确保当前的修改不会增加更为重要的问题。　　适应性维护和完善性维护的申请则采用不同的路线。对于适应性维护，首先进行评价和按优先次序分类，然后排出在维护活动中的位置。对于完善性维护，同样要进行评价。但出于商业的策略、当今和今后软件产品的方向等方面的考虑，不是所有完善性维护都被接受。被接受的完善性维护也要在维护的队列中确定它们的位置。每一个维护申请的优先次序确定之后，就像另一项开发工作一样安排它们所需的工作。如果有的优先级很高，就应立即着手工作。 * 事实上，软件维护就是实际的软件工程的