网资酷

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 97|回复: 1

16 Postdelivery Maintenance(交付后维护)

[复制链接]

4

主题

5

帖子

12

积分

新手上路

Rank: 1

积分
12
发表于 2022-12-8 06:28:49 | 显示全部楼层 |阅读模式
16 Postdelivery Maintenance(交付后维护)

已收录至专栏
已完成章节索引 00《软件工程-面向对象和传统方法》笔记索引
声明

本文为以下图书的学习笔记,图书中的内容更为丰富,并且各章课后参考文献列表丰富,案例丰富。如对内容感兴趣,请至出版社网站购买。
<hr/>软件工程:面向对象和传统的方法(原书第8版)
作者:韩松
ISBN:978-7-111-36273-9
所属丛书:计算机科学丛书
交付后维护

  • 在产品通过验收测试后,对产品的任何组成部分(包括文档)进行的任何更改
  • Postdelivery maintenance Any change to any component of the product (including documentation) after it has passed the acceptance test


  • 这一章很短

    • 但整本书本质上讲的是交付后的维护

  • This is a short chapter

    • But the whole book is essentially on postdelivery maintenance



  • 在本章中,我们将介绍如何确保在交付后的维护过程中,可维护性不会受到影响
  • In this chapter we explain how to ensure that maintainability is not compromised during postdelivery maintenance
16.1 Development and Maintenance(开发与维护)


  • 交付后维护

    • 在产品交付给客户后,对文档、手册或任何其他组件的更改都是交付后维护的例子。

  • postdelivery maintenance

    • any changes to the documentation, manuals, or any other component of the product after it has been delivered to the client are examples of postdelivery maintenance.

  • 演变

    • 一些计算机科学家更喜欢使用演变这个术语而不是维护来表示产品随着时间的推移而进化。

  • 事实上,有些人将整个软件生命周期,从开始到结束,视为一个演变过程。
  • evolution

    • Some computer scientists prefer to use the term evolution rather than maintenance to indicate that a product evolves over time.

  • In fact, some view the entire software life cycle, from beginning to end, as an evolutionary process.


  • 维护这个词很少出现在Jacobson, Booch, and Rumbaugh [1999](的著述)中
  • The word maintenance hardly occurs anywhere in Jacobson, Booch, and Rumbaugh [1999].


  • (补充)然而,开发和维护之间有一个基本的区别
  • However, there is a basic difference between development and maintenance
<hr/>

  • 尽管对现有制品进行更改比从头开始构建新的制品要困难,但是经济上的考虑使得维护比重新开发更可取。
  • Even though it is harder to make changes to existing artifacts than to construct new artifacts from scratch, economic considerations make maintenance far preferable to redevelopment.
16.2 Why Postdelivery Maintenance Is Necessary(为什么交付后维护是必要的)


  • 纠错性维护

    • 修订残留的差错

      • 分析、设计、实现、文档,或者任何其他类型的差错


  • Corrective maintenance

    • To correct residual faults

      • Analysis, design, implementation, documentation, or any other type of faults


<hr/>

  • 完善性维护

    • 客户要求变更以提高产品的有效性

      • 添加额外的功能
      • 让产品运行得更快
      • 提高可维护性


  • Perfective maintenance

    • Client requests changes to improve product effectiveness

      • Add additional functionality
      • Make product run faster
      • Improve maintainability


<hr/>

  • 适应性维护

    • 对产品运行环境的变化作出反应

      • 该产品被移植到新的编译器、操作系统和/或硬件上
      • 税号的改变
      • 9位邮政编码(原来为5位)


  • Adaptive maintenance

    • Responses to changes in the environment in which the product operates

      • The product is ported to a new compiler, operating system, and/or hardware
      • A change to the tax code
      • 9-digit ZIP codes


16.3 What Is Required of Postdelivery Maintenance Programmers?(对交付后维护程序员的要求是什么)


  • 产品总成本的至少67%是在交付后维护期间产生的
  • At least 67% of the  total cost of a product accrues during postdelivery maintenance


  • 维护费用是主要的收入来源
  • Maintenance is a major income source


  • 然而,即使在今天,许多组织仍将维护任务分配给

    • 无人监督的初学者,
    • 不称职的程序员

  • Nevertheless, even today many organizations assign maintenance to

    • Unsupervised beginners, and
    • Less competent programmers

<hr/>

  • 交付后维护是软件生产中最困难的部分之一,因为

    • 交付后维护包含所有其他工作流的各个方面

  • Postdelivery maintenance is one of the most difficult aspects of software production because

    • Postdelivery maintenance incorporates aspects of all other workflows

<hr/>

  • 假设将缺陷报告交给维护程序员(之后会发生什么?)

    • 回想一下,“缺陷”是故障、失败或错误的通用术语(所以用户认为产品没有按照手册运行就会提交缺陷报告)

  • Suppose a defect report is handed to a maintenance programmer

    • Recall that a “defect” is a generic term for a fault, failure, or error

  • (而产生“缺陷”的真实)原因是什么?

    • 可能什么问题也没有
    • 也可能是用户手册错误,而不是代码有差错
    • 然而,通常情况下,代码中会有差错

  • What is the cause?

    • Nothing may be wrong
    • The user manual may be wrong, not the code
    • Usually, however, there is a fault in the code

(备注:但是交付后维护的程序员需要做什么呢?)
<hr/>纠错性维护(Corrective Maintenance)

  • 维护程序员有什么工具来查找故障?

    • 用户提交的缺陷报告
    • 源代码
    • 通常没有别的

  • What tools does the maintenance programmer have to find the fault?

    • The defect report filed by user
    • The source code
    • And often nothing else

<hr/>

  • 因此,维护程序员必须具有高超的调试技能

    • 差错可能出现在产品的任何地方
    • 差错的最初原因可能在于目前不存在的规格说明或者设计文件

  • A maintenance programmer must therefore have superb debugging skills

    • The fault could lie anywhere within the product
    • The original cause of the fault might lie in the by now non-existent specifications or design documents

<hr/>

  • 假设维护程序员已经定位了差错
  • Suppose that the maintenance programmer has located the fault


  • 问题:

    • 如何在不引入回归错误的情况下修复它?

  • Problem:

    • How to fix it without introducing a regression fault

<hr/>

  • 如何最小化回归错误

    • 查阅整个产品的详细文档
    • 查阅每个模块的详细文档

  • How to minimize regression faults

    • Consult the detailed documentation for the product as a whole
    • Consult the detailed documentation for each individual module

  • 通常会发生什么

    • 根本没有文档,或者
    • 文档不完整,或者
    • 文档是有错误的

  • What usually happens

    • There is no documentation at all, or
    • The documentation is incomplete, or
    • The documentation is faulty

<hr/>

  • 程序员必须从源代码本身推断出所有需要的信息,以避免引入回归错误
  • The programmer must deduce from the source code itself all the information needed to avoid introducing a regression fault


  • 程序员现在修改源代码
  • The programmer now changes the source code
<hr/>程序员现在必须(The Programmer Now Must)

  • 测试修改是否正确

    • 使用专门构造的测试用例

  • Test that the modification works correctly

    • Using specially constructed test cases

  • 测试回归错误

    • 用之前存储的测试数据

  • Check for regression faults

    • Using stored test data



  • 将专门构造的测试用例添加到存储的测试数据中,以便将来进行回归测试
  • Add the specially constructed test cases to the stored test data for future regression testing


  • 将所有更改写入文档
  • Document all changes
<hr/>

  • 纠错性维护需要掌握的主要技能

    • 出色的诊断技能
    • 出色的测试技能
    • 出色的文档技能

  • Major skills are required for corrective maintenance

    • Superb diagnostic skills
    • Superb testing skills
    • Superb documentation skills

<hr/>适应性和完善的维护(Adaptive and Perfective Maintenance)

  • 维护程序员必须使用现有产品作为起点,完成

    • 需求工作流
    • 分析工作流
    • 设计工作流
    • 实现和集成工作流

  • The maintenance programmer must go through the

    • Requirements
    • Specifications
    • Design
    • Implementation and integration   workflows, using the existing product as a starting point

<hr/>

  • 开发程序时

    • 规格由分析专家制作
    • 设计由设计专家制作
    • 代码由编程专家编写

  • When programs are developed

    • Specifications are produced by analysis experts
    • Designs are produced by design experts
    • Code is produced by programming experts

  • 但是一个维护程序员必须精通这三个领域,并且精通

    • 测试和
    • 文档

  • But a maintenance programmer must be expert in all three areas, and also in

    • Testing, and
    • Documentation

<hr/>结论(Conclusion)

  • 没有任何一种形式的维护

    • (可以作为)无监督的初学者的任务,或者
    • 应该由不太熟练的计算机专业人员完成

(备注:换言之,任何一种形式的维护都不应该交给初学者或者不熟练的计算机专业人员完成。)

  • No form of maintenance

    • Is a task for an unsupervised beginner, or
    • Should be done by a less skilled computer professional

<hr/>维护的回报(The Rewards of Maintenance)

  • 维护是一项吃力不讨好的工作

    • 维护者与不满意的用户打交道
    • 如果用户满意,产品就不需要维护
    • 用户的问题通常是由开发产品的人引起的,而不是维护者
    • 代码本身可能写得很糟糕
    • 交付后的维护被许多软件开发人员所轻视
    • 除非提供良好的维护服务,否则客户将来有开发业务的话,会找其他公司
    • 交付后维护是软件生产中最具挑战性的部分,也是最吃力不讨好的

  • Maintenance is a thankless task in every way

    • Maintainers deal with dissatisfied users
    • If the user were happy, the product would not need maintenance
    • The user’s problems are often caused by the individuals who developed the product, not the maintainer
    • The code itself may be badly written
    • Postdelivery maintenance is despised by many software developers
    • Unless good maintenance service is provided, the client will take future development business elsewhere
    • Postdelivery maintenance is the most challenging aspect of software production — and the most thankless

<hr/>

  • 如何才能改变这种情况?
  • How can this situation be changed?


  • 管理人员必须将维护工作分配给他们最好的程序员,并且
  • Managers must assign maintenance to their best programmers, and


  • 给他们相应的回报
  • Pay them accordingly
16.4 Postdelivery Maintenance Mini Case Study(交付后维护迷你案例研究)

案例略

  • 从中吸取的教训

    • 问题是由开发人员引起的,而不是维护者
    • 维护者经常负责修复其他人的错误
    • 客户经常不理解交付后的维护可能很困难,或者几乎不可能
    • 当执行之前明显类似的完善和自适应维护任务时,这种情况会加剧
    • 所有的软件开发活动都必须着眼于未来的交付后维护

  • Lessons to be learnt from this

    • The problem was caused by the developer, not the maintainer
    • A maintainer is often responsible for fixing other people’s mistakes
    • The client frequently does not understand that postdelivery maintenance can be difficult, or all but impossible
    • This is exacerbated when previous apparently similar perfective and adaptive maintenance tasks have been carried out
    • All software development activities must be performed with an eye on future postdelivery maintenance

16.5 Management of Postdelivery Maintenance(交付后维护的管理)


  • 现在考虑以下有关交付后维护管理的各种问题
  • Various issues regarding management of postdelivery maintenance are now considered
16.5.1 Defect Reports(缺陷报告)


  • 我们需要一种改变产品的机制
  • We need a mechanism for changing a product


  • 如果产品显示功能不正常,用户将提交缺陷报告

    • 它必须包含足够的信息,使维护程序员能够重现问题

  • If the product appears to function incorrectly, the user files a defect report

    • It must include enough information to enable the maintenance programmer to recreate the problem



  • 理想情况下,每个缺陷都应该立即修复

    • 实际上,立即进行初步调查才是是我们应该做的最好的事情

  • Ideally, every defect should be fixed immediately

    • In practice, an immediate preliminary investigation is the best we can do

<hr/>

  • 维护程序员应该首先查阅缺陷报告文件
  • The maintenance programmer should first consult the defect report file


  • 它包括

    • 所有已报告但尚未修复的缺陷
    • 解决这些问题的建议

  • It contains

    • All reported defects not yet fixed, and
    • Suggestions for working around them

<hr/>如果该缺陷以前已经报告过(If the Defect Has Been Previously Reported)

  • 将缺陷报告文件中的信息提供给用户
  • Give the information in the defect report file to the user
<hr/>假如是新的缺陷(If it Is a New Defect)

  • 维护程序员应该尝试找到

    • 原因,
    • 一种修复它的方法
    • 一种解决问题的方法

  • The maintenance programmer should try to find

    • The cause,
    • A way to fix it, and
    • A way to work around the problem

  • 新的缺陷现在与以下支持文档一起归档在缺陷报告文件中

    • 清单(用以得出上述结论的清单)
    • 设计
    • 手册

  • The new defect is now filed in the defect report file, together with supporting documentation

    • Listings
    • Designs
    • Manuals

<hr/>

  • 该文件还应包含客户对完善和适应性维护的要求

    • 文件内容必须按客户优先级排序
    • 下一个修改的是具有最高优先级的那一个

  • The file should also contain the client’s requests for perfective and adaptive maintenance

    • The contents of the file must be prioritized by the client
    • the next modification is the one with the highest priority

  • 缺陷报告的副本必须分发给所有人

    • 包括:对缺陷何时可以修复的估计

  • Copies of defect reports must be circulated to all

    • Including: An estimate of when the defect can be fixed

  • 如果在其他地方发生同样的故障,用户可以决定

    • 是否有可能绕过缺陷,以及
    • 多长时间可以修复

  • If the same failure occurs at another site, the user can determine

    • If it is possible to work around the defect, and
    • How long until it can be fixed

<hr/>

  • 在理想的世界里

    • 我们立即修复每个缺陷
    • 然后我们将产品的新版本分发到所有地点

  • In an ideal world

    • We fix every defect immediately
    • Then we distribute the new version of the product to all the sites

  • 在现实世界中

    • 我们将缺陷报告分发到所有站点
    • 我们没有能立即维修缺陷的人员
    • 同时进行多个更改成本会更低,尤其是在有多个地点的情况下(备注:所以有缺陷也可以暂不修复,而选择累积多个缺陷,集中一次性完成修复)

  • In the real world

    • We distribute defect reports to all sites
    • We do not have the staff for instant maintenance
    • It is cheaper to make a number of changes at the same time, particularly if there are multiple sites

16.5.2 Authorizing Changes to the Product(批准对产品的修改)


  • 纠错性维护

    • 指定一名维护人员确定差错及其成因,然后进行修复
    • 测试修复,测试整个产品(回归测试)
    • 更新文档以反映所做的修改
    • 更新序言注释以反映

      • 修改了什么,
      • 为什么要修改
      • 谁完成的修改,还有
      • 什么时候做的修改


  • Corrective maintenance

    • Assign a maintenance programmer to determine the fault and its cause, then repair it
    • Test the fix, test the product as a whole (regression testing)
    • Update the documentation to reflect the changes made
    • Update the prologue comments to reflect

      • What was changed,
      • Why it was changed,
      • By whom, and
      • When


<hr/>

  • 适应性和完善性维护

    • 除了没有缺陷报告外,与纠错性维护一样
    • (适应性和完善性维护与纠错性维护相比,有一点区别是)修改是源于需求的变化而不是(源于缺陷报告)

  • Adaptive and perfective maintenance

    • As with corrective maintenance, except there is no defect report
    • There is a change in requirements instead

<hr/>

  • 如果程序员没有对修复进行充分的测试呢?

    • 在产品发布之前,它必须经过SQA小组的测试

  • What if the programmer has not tested the fix adequately?

    • Before the product is distributed, it must be tested by the SQA group

  • 交付后的维护非常困难
  • Postdelivery maintenance is extremely hard
  • 测试是困难和耗时的

    • 由质量保证小组执行

  • Testing is difficult and time consuming

    • Performed by the SQA group

<hr/>

  • 使用基线技术和个人副本(来修复软件时),必须(保证工作程序得到严格)遵守
  • The technique of baselines and private copies must be followed


  • 程序员对代码制品的个人副本进行更改,并且测试它们
  • The programmer makes changes to private copies of code artifacts, tests them


  • 程序员冻结以前的版本,并将修改后的版本提供给SQA进行测试
  • The programmer freezes the previous version, and gives the modified version to SQA to test


  • SQA对所有代码制品的当前基线版本执行测试
  • SQA performs tests on the current baseline version of all code artifacts
16.5.3 Ensuring Maintainability(确保可维护性)


  • 维护不是一次性工作
  • Maintenance is not a one-time effort


  • 在整个生命周期,我们都必须对维护进行计划

    • 设计工作流程(使用信息隐藏技术)
    • 实现工作流(选择对未来维护程序员有意义的变量名)
    • 文档必须是完整和正确的,并且反映每个制品的当前版本

  • We must plan for maintenance over the entire life cycle

    • Design workflow — use information-hiding techniques
    • Implementation workflow — select variable names meaningful to future maintenance programmers
    • Documentation must be complete and correct, and reflect the current version of every artifact

<hr/>

  • 在交付后的维护过程中,(在保持)可维护性(方面)不能妥协

    • 始终意识到进一步维护是不可避免的

  • During postdelivery maintenance, maintainability must not be compromised

    • Always be conscious of the inevitable further maintenance



  • (开发期间确立的)可维护性的原则同样适用于交付后维护本身
  • Principles leading to maintainability are equally applicable to postdelivery maintenance itself
16.5.4 Problem of Repeated Maintenance(迭代维护的问题)


  • 需求变更问题让开发团队感到懊恼
  • The moving target problem is frustrating to the development team


  • 频繁的变更会对产品的可维护性产生不利影响
  • Frequent changes have an adverse effect on the maintainability of the product
<hr/>

  • 需求变更问题
  • The Moving Target Problem


  • 在交付后维护过程中,这个问题会恶化
  • The problem is exacerbated during postdelivery maintenance


  • 修改的越多

    • 产品越偏离最初的设计
    • 将来的修改就会变得更加困难
    • 文档变得比以往更不可靠
    • 回归测试文件也不是最新的
    • 如果做更多的维护,(软件)可能需要完全重写

  • The more changes there are

    • The more the product deviates from its original design
    • The more difficult further changes become
    • Documentation becomes even less reliable than usual
    • Regression testing files are not up to date
    • A total rewrite may be needed for further maintenance

<hr/>

  • 明显的解决方案

    • 一旦签署了规格说明书,就将其冻结,直到产品交付
    • 每次要求完善维护后,将规格说明冻结(例如)3个月或1年

  • Apparent solution

    • Freeze the specifications once they have been signed off until delivery of the product
    • After each request for perfective maintenance, freeze the specifications for (say) 3 months or 1 year

  • 在实践中

    • 客户可以在第二天就提出修改
    • 如果愿意支付价格,客户可以每天提出修改的要求

  • In practice

    • The client can order changes the next day
    • If willing to pay the price, the client can order changes on a daily basis



  • "谁出钱谁说了算"
  • “He who pays the piper calls the tune”
<hr/>警告(Warning)

  • 缓慢地实现修改(即:拖延时间)是没有用的
  • It is no use implementing changes slowly


  • (拖延时间只会导致)相关人员被(愿意快速实现修改的人员)替换
  • The relevant personnel are replaced


  • 如果要求迭代修改的人有足够的影响力/权力,(那么对于需求变更的问题)就无能为力。(备注:所以负责实现的程序员处在食物链的底端:p)
  • Nothing can be done if the person calling for repeated change has sufficient clout
16.6 Maintenance of Object-Oriented Software(面向对象软件的维护)


  • 面向对象范型似乎以四种方式促进维护

    • 产品由独立的单元组成
    • 封装(概念独立)
    • 信息隐藏(物理独立)
    • 消息传递是唯一的通信方式

  • The object-oriented paradigm apparently promotes maintenance in four ways

    • The product consists of independent units
    • Encapsulation (conceptual independence)
    • Information hiding (physical independence)
    • Message-passing is the sole communication



  • 实际情况有所不同
  • The reality is somewhat different
<hr/>

  • 三个障碍

    • 完整的继承层次结构可能很大
    • 多态和动态绑定的后果
    • 继承的后果

  • Three obstacles

    • The complete inheritance hierarchy can be large
    • The consequences of polymorphism and dynamic binding
    • The consequences of inheritance

<hr/>代码例子 略
<hr/>

  • 继承层次结构的大小(的问题)
  • 解决方案

    • CASE工具可以扁平化继承树(使用CASE工具,可以将层次较深的继承树变得扁平化)

  • Size of the Inheritance Hierarchy
  • Solution

    • A CASE tool can flatten the inheritance tree

<hr/>多态和动态绑定问题(Polymorphism and Dynamic Binding)
代码例子略

  • 多态和动态绑定可以

    • 对开发有积极的影响,但是
    • 对维护有负面影响

  • Polymorphism and dynamic binding can have

    • A positive effect on development, but
    • A negative effect on maintenance

<hr/>继承的后果(Consequences of Inheritance)

  • 通过继承创建一个新的子类
  • 新的子类

    • 不影响任何超类
    • 不影响任何其他子类

  • Create a new subclass via inheritance
  • The new subclass

    • Does not affect any superclass, and
    • Does not affect any other subclass

  • 修改这个新的子类

    • 同样,没有影响

  • Modify this new subclass

    • Again, no affect

  • 修改超类

    • 所有的子类都会受到影响
    • “脆弱的基类问题”

  • Modify a superclass

    • All descendent subclasses are affected
    • Fragile base class problem”

<hr/>

  • 继承可以

    • 对开发有积极的影响,但是
    • 对维护有负面影响

  • Inheritance can have

    • A positive effect on development, but
    • A negative effect on maintenance

16.7 Postdelivery Maintenance Skills versus Development Skills(交付后维护技能与开发技能)


  • 维护所需的技能包括

    • 确定大型产品失效原因的能力

      • 在集成和产品测试期间也需要

    • 在没有足够文档的情况下有效工作的能力

      • 文档很少在交付之前完成

    • 具备分析、设计、实现和测试的能力

      • 所有四项活动都在开发过程中进行


  • The skills needed for maintenance include

    • The ability to determine the cause of failure of a large product

      • Also needed during integration and product testing

    • The ability to function effectively without adequate documentation

      • Documentation is rarely complete until delivery

    • Skills in analysis, design, implementation, and testing

      • All four activities are carried out during development


<hr/>

  • 交付后维护所需的技能与其他工作流所需的技能相同
  • The skills needed for postdelivery maintenance are the same as those for the other workflows


  • 重点

    • 维护程序员不仅要精通各种领域,他们必须在所有这些领域都非常熟练
    • 对于维护程序员来说,专业化是不可能的(备注:维护需要的是多面手)

  • Key Point

    • Maintenance programmers must not merely be skilled in a broad variety of areas, they must be highly skilled in all those areas
    • Specialization is impossible for the maintenance programmer



  • 交付后维护与开发(需要的技能)相同,甚至(比开发要求会的技能)更多
  • Postdelivery maintenance is the same as development, only more so
16.8 Reverse Engineering(逆向工程)


  • 当交付后维护的唯一文档是代码本身时,

    • 从代码开始
    • 重新创建设计
    • 重新创建规格说明(非常困难)
    • CASE工具可以提供帮助(流程图,其他视觉辅助)

  • When the only documentation for postdelivery maintenance is the code itself

    • Start with the code
    • Recreate the design
    • Recreate the specifications (extremely hard)
    • CASE tools can help (flowcharters, other visual aids)

<hr/>再工程(Reengineering)

  • 再工程

    • 先逆向工程,然后是正向工程
    • 从低到高再到低的抽象层次

  • Reengineering

    • Reverse engineering, followed by forward engineering
    • Lower to higher to lower levels of abstraction



  • 重组

    • 在不改变产品功能的情况下改进产品
    • 例如:

      • 格式化代码(以增加阅读性)
      • 构建代码
      • 提高可维护性
      • 重组(极限编程,敏捷流程)


  • Restructuring

    • Improving the product without changing its functionality
    • Examples:

      • Prettyprinting
      • Structuring code
      • Improving maintainability
      • Restructuring (XP, agile processes)


<hr/>

  • 如果我们只有可执行代码呢?

    • 将产品视为黑盒子
    • 从当前产品的行为推断规格说明

  • What if we have only the executable code?

    • Treat the product as a black box
    • Deduce the specifications from the behavior of the current product

16.9 Testing during Postdelivery Maintenance(交付后维护期间的测试)


  • 维护者倾向于将产品视为一组松散相关的组件

    • 他们没有参与产品的开发

  • Maintainers tend to view a product as a set of loosely related components

    • They were not involved in the development of the product

  • 回归测试是必不可少的

    • 存储测试用例及其结果,并根据需要进行修改

  • Regression testing is essential

    • Store test cases and their outcomes, modify as needed

16.10 CASE Tools for Postdelivery Maintenance(交付后维护的CASE工具)


  • 需要配置控制工具

    • 商用工具

      • CCC

    • 开源工具

      • cvs
      • Subversion


  • Configuration-control tools are needed

    • Commercial tool

      • CCC

    • Open-source tools

      • cvs
      • Subversion




  • 再工程工具

    • 商用工具

      • IBM Rational Rose, Together

    • 开源工具

      • Doxygen


  • Reengineering tools

    • Commercial tools

      • IBM Rational Rose, Together

    • Open-source tool

      • Doxygen


<hr/>

  • 缺陷跟踪工具

    • 商用工具

      • IBM Rational ClearQues

    • 开源工具

      • Bugzilla


  • Defect-tracking tools

    • Commercial tool

      • IBM Rational ClearQuest

    • Open-source tool

      • Bugzilla


16.11 Metrics for Postdelivery Maintenance(交付后维护的度量)


  • 交付后维护的活动本质上就是开发的活动

    • (所以对于交付后维护的度量和)开发工作流的度量(一样)

  • The activities of postdelivery maintenance are essentially those of development

    • Metrics for development workflows

  • 缺陷报告度量

    • 缺陷分类
    • 缺陷状态

  • Defect report metrics

    • Defect classifications
    • Defect status

16.12 Postdelivery Maintenance: The MSG Foundation Case Study(交付后维护:MSG基金案例研究)


16.13 Challenges of Postdelivery Maintenance(交付后维护的挑战)


  • 本章描述了许多挑战
  • The chapter describes numerous challenges


  • 最难的挑战是

    • 维护比开发难,但是
    • 开发人员往往看不起维护人员
    • (开发人员)经常得到(比维护人员)更多的报酬

  • The hardest challenge to solve

    • Maintenance is harder than development, but
    • Developers tend to look down maintainers, and
    • Are frequently paid more

回复

使用道具 举报

1

主题

7

帖子

15

积分

新手上路

Rank: 1

积分
15
发表于 2025-5-18 06:20:10 | 显示全部楼层
好,很好,非常好!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|网资酷

GMT+8, 2025-8-28 03:38 , Processed in 0.103695 second(s), 24 queries .

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表