Analysis activities during software maintenance involve understanding the scope and effect of a desired change， as well as the constraints on making the change. Design during maintenance involves redesigning the product to incorporate the desired changes. The changes must then be implemented， internal documentation of the code must be updated， and new test cases must be designed to assess the adequacy of the modification. Also， the supporting documents （requirements， design specifications， test plan， principles of operation， user’s manual， cross reference directories， etc.） must be updated to reflect the changes. Updated versions of the software （code and supporting documents） must then be distributed to various customer sites， and configuration control records for each site must be updated.
All of these tasks must be accomplished using a systematic， orderly approach to tracking and analysis of change requests， and careful redesign， reimplementation， revalidation， and documentation of the changes. Otherwise， the software product will quickly degrade as a result of the maintenance process. It is not unusual for a well designed， properly implemented， and adequately documented initial version of a software product to become un-maintainable due to inadequate maintenance procedures. This can result in situations in which it becomes easier and less expensive to implement a module or subsystem than to modify the existing version. Software maintenance activities must not destroy the maintainability of software. A small change in the source code often requires extensive changes to the test suite and the supporting documents. Failure to recognize the true cost of a “small change” in the source code is one of the most significant problems in software maintenance.
【Vocabulary】
enhancement
n. 增进，增加
revalidation
n. 重新生效，重具法律效力
adaptation
n. 适应，改编，改写
telecommunication
n. 电信，无线电通信
documentation
n. 文件
maintainable
adj. 可维持的，主张的
implement
vt. 贯彻，实现，执行
scheduled
adj. 预定的
periodic
n. 定期的，周期的
evolution
n. 进展，发展，演变，演化
primary
adj. 主要的，初步的，初级的
modularity
n. 模块性
rein
n. 统治，支配，驾驭
microcosm
n. 微观世界
potentially
adv. 潜在地
redesign
v. 重新设计
configuration
n. 构造，结构，外形
reimplementation
n. 执行
initial
adj. 最初的，初始的，词首的
rule of thumb
经验法则
life-cycle
生命周期
【参考译文】
软件维护
“软件维护”这个术语用来描述在软件产品交付给用户以后所进行的软件工程活动。软件生存周期维护阶段是指软件产品完成有效工作的时间段。典型的情形是：一个软件产品的开发周期持续1年或2年，但是它的维护阶段却要历时5到10年。
维护活动包含增强软件产品、调整软件产品以适应新的环境和纠正软件中的问题。软件产品增强可以包含：提供新的功能，改进用户显示和交互模式，升级外部文档和内部文件说明，或是升级系统的性能指标。软件对新环境的适应可以包括把软件移植到不同的机器，或者修改软件以适应于新的远程通信协议或添加的磁盘驱动器。问题的纠正包括修改和重新确认软件以纠正错误。有些错误需要立即采取措施，有些则可按照计划定期进行纠正，而另一些错误虽然已经测知但是却从未作纠正。
维护活动在整个生存周期的预算中占有很大的比例是公认的。它通常占软件生存周期费用的70％（而软件开发费用只占30％）。按一般经验法则，软件维护预算分配比例为：用于功能增强的占60％，适应新环境和纠错各占20％。
如果维护要花费某一个软件产品整个生存周期的70％，而维护费用的60％用于此产品的功能增强，那么产品功能增强要占产品整个生存周期的42％。很明显，据此观点产品在开发周期结束时交给用户的仅仅是系统的最初版本。有一些作者已经建议比较合适的软件生存周期模型应该是开发→进化→进化→进化……
据此观点可见，软件开发的主要目标是生产可维护的软件系统产品。像所有高层质量属性一样，可维护性可用包含在产品内部的属性来表达。影响软件可维护性的主要产品属性有清晰度、模块性、良好的内部源代码文档说明以及适当的支持文档。
软件维护是软件开发周期的缩影。软件的功能增强和适应使开发重新回到分析阶段，而软件纠错可使开发周期回到分析阶段、设计阶段或实现阶段。因此，所有用于开发软件的工具和技术对于软件维护都具有潜在的用途。
软件维护的分析活动包括理解所希望做的更改的范围和影响，以及对所做的更改的限制条件。维护阶段的设计包括根据想做的更改来重新设计产品，然后必须实现更改，代码的内部文档说明必须更新，必须设计新的测试案例来评估修改的恰当性。还必须更新支持文档（需求、设计规格说明、测试计划、操作原理、用户手册、交叉参考目录等）来反映所做的修改。更新后的软件版本（代码和支持文档）必须分发到各个用户站点，各站点的配置控制记录必须更新。
所有这些任务都必须通过系统的，有条理的方法去跟踪和分析更改要求，仔细地重新设计、重新实现、重新确认和重新对所作更改编制文档来完成。否则，软件产品将因为维护过程而很快降级。常常有设计良好、实现合理和有合适文档的初版产品因为不恰当的维护过程而变得不可维护，这会导致重新实现一个模块或子系统比修改已经存在的版本更容易和花费更少。软件维护活动一定不要损坏软件的可维护性。源代码中的一个细微更改往往需要测试套件和支撑文档做大规模的变动。因为忽视源代码中所谓“小的变动”而付出代价是软件维护中最重大的问题之一。
【Reading Material】
Manage Requirements
What is Requirements Management？
Requirements management is a systematic approach to finding， documenting， organizing and tracking the changing requirements of a system.
We define a requirement as：
A condition or capability to which the system must conform. Our formal definition of requirements management is that it is a systematic approach to eliciting， organizing， and documenting the requirements of the system， and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system.
Keys to effective requirements management include maintaining a clear statement of the requirements， along with applicable attributes and traceability to other requirements and other project artifacts.
In real projects， you will run into difficulties because：
Requirements are not always obvious， and can come from many sources.
Requirements are not always easy to express clearly in words.r
There are many different types of requirements at different levels of detail.
The number of requirements can become unmanageable if not controlled.
Requirements are related to one another and also to other deliverables ofthe software engineering process.l
Requirements have unique properties or property values.
Requirements change.
So， we have learned that the following skills are important to master：
Problem analysis
