SSD9: Software Specification, Testing, and

Maintenance
 Unit 8. Deployment and Maintenance
 8.1 What is Maintenance?
 8.2 Managing Maintenance
 8.3 Maintaining Object-Oriented Software
 8.4 Aids to Maintenance

 Assessments
 Exercise 9
 Multiple-Choice Quiz 8
 8.1 What is Maintenance?
 Types of Maintenance
 Skills Required for Maintenance
 Types of Maintenance
 Maintenance should be considered part of product
development. 而不是额外做的事情
 Few if any software products are completely free of faults,
even after undergoing extensive testing.
 the client’s requirements or environment may change,
necessitating corresponding changes to the product.
 There are 3 basic types of maintenance reflecting different
motivations for making changes to the software product:
 Corrective maintenance removes residual faults in the product.
 Perfective maintenance enhances the product with respect to
performance and functionality.
 Adaptive maintenance occurs in response to changes in the client�s
computing facilities and environment.
 maintenance time
 One study found that
 perfective maintenance claims the bulk of time devoted to
maintenance, approximately 60 percent.
 Corrective maintenance consume about 18 percent of the
time
 Adaptive maintenance consume about 18 percent of the time
 the remainder is accounted for by other types of activities.
 When releasing a new version of the product after
performing maintenance, it is usually a good idea
 not to include more than one kind of maintenance in the
same release. 每次只做一种类型的维护！
 维护程序 员的难堪！
 Maintenance of a software product is a rather thankless
task.
 Many programmers perceive
 it as a low-glamour activity:
 all the fun and glory in software construction are in the design and
development phases.
 Instead of building a shiny new product, maintenance
programmers 遭批评及白眼（替别人受的）
 have to deal with criticisms and requests from unhappy customers.
 Often they are faced with poorly documented software to
the design of which they did not contribute. 文档很差
 Management perpetuates the myth and bad reputation of
maintenance programming by assigning less-skilled and
lower-paid programmers to this activity. 公司也不重视
 The reality is that maintenance programming is extremely
 Maintenance is difficult
 Maintenance is difficult because
 it incorporates aspects of all other phases of software
development. 需要各开发阶段的技巧
 locating
 When a user files a problem report, the maintenance
programmer must
 first determine whether it is indeed a software problem.
 The user could have misunderstood 用户不明白是否真有错
误
 what the product is supposed to do,
 there may be a problem in the documentation.
 Sometimes faults are triggered by a sequence of user
commands only.
 The user 用户通常描述不清，得依靠维护程序员查错！
 may have trouble duplicating the fault and
 may be able to specify only vaguely the circumstances under which the
error occurs.
 locating
 If indeed the software does not conform to its
specifications and documentation
 the maintenance programmer must try to locate the source of
the fault in the code.
 This requires significant diagnostic and debugging
skills.
 Not only is the code likely to be complex and poorly
documented
 but also the fault itself may be poorly documented.
 testing
 After the fault has been removed, the maintenance
programmer must
 test the module(s) in which the fault occurred and
 test integration of the repaired module(s) with the rest of the
system.
 regression testing against existing testing suites in
order to verify that
 other faults have not been introduced inadvertently
 documenting
 Finally, before considering the fault fixed and
releasing a new version of the product,
 the maintainer must also document each change and update
the relevant
 specification
 design

 testing documents

 any other affected documentation.

 Unlike the software professionals participating in
the earlier phases of product development who may
specialize in different aspects of the software
process,
 the maintenance programmer needs to specialize in all
aspects. 强人一个！
 The ability to do end-to-end product refinement is
particularly essential for perfective maintenance.
 Repeated enhancements to the product without
updates to all relevant documents make it
 increasingly difficult to understand the software's
functionality
 increasingly frustrating to change it.
 8.2 Managing Maintenance
 Fault Reports
 Managing Workflow
 Fault Prioritization
 Workarounds
 Before Delivering a New Version
 Fault Reports
 Fault reports usually originate with the user.
 A fault report should include:
 The name of the user who found or reported the fault
 The version of the product and hardware platform on which it was
detected
 If possible, the exact input or action sequence leading to the fault
 If possible, actual test data
 If the user encounters a fault that is serious but is not
systematically repeatable, 偶然随机发生的错误也要记录
报告！
 the fault should still be reported —
 even though the information may be insufficient for finding and fixing
the problem.
 An example of a fault report managing system
 GNATS system used at Carnegie Mellon University
for managing a large industrial application of
machine translation.
 GNATS was initially used to coordinate fault reports
among three organizations (a developer, a client,
and a contractor) and several individuals within
each organization.
 GNATS contains a database of problem reports
(PRs) that can be accessed through an editor.
 When a PR is created, the creator describes the
nature of the problem.
 Once the PR is submitted, a mail message is
generated, notifying the GNATS administrator of
 Managing Workflow
 Ideally, faults should be fixed as soon as they are
reported
 but in reality, faults must be researched and
prioritized according to 要评估
 their impact on the overall usability of the system and
 the cost of fixing them.
 This requires a process for managing
 problem reports
 software updates.
 A problem reporting system (GNATS), which places all fault reports in a
central repository and makes them accessible to multiple interested
entities, is an important tool in managing workflow.
 Reports and research concerning the faults can be updated and viewed by
both maintainers and management.
 They are a shared source of information that the client and the developer
can consult prior to engaging in discussions regarding prioritization and
scheduling of fixes for future version releases.
 The results of the discussions can be recorded in the GNATS database.
 Test cases for scheduled fault fixes can be automatically extracted from the
problem reports and used to check that the new version of the product
indeed repairs the problem reported.
 The test cases can be accumulated in test suites, to test for inadvertently
introduced errors during successive product releases.
 Fault Prioritization
 While everybody would like all faults to be fixed as
soon as they are detected,
 it is often the case that time, cost, and manpower
resources impose constraints on
 which problems can actually be dealt with during any one
period of time. 多种因素决定改错的时机
 方法
 Faults must be prioritized 划分错误的严重等级
 the most critical are fixed sooner
 less critical are delayed — or their impact is somehow
minimized.
 criteria for rating the seriousness of faults
 Important criteria for rating the seriousness of faults
include
 frequency of occurrence,
 estimated effort to diagnose and fix, and
 its impact on user productivity.
 E.g.,
 Faults that occur rarely, have low impact, and cost a lot to fix should be
considered low priority.
 Faults that occur frequently and have a high impact should be rated as
having high priority, regardless of the cost of fixing them.
 There are different shades between these two extremes, and
it will be up to the client and the developer to agree on the
priority to assign to these faults. 最好使用双方都认可的
分级标准
 an example
 consider the automated machine translation system
that was previously used to illustrate various aspects
of software life-cycle phases.
 In any particular source and target language pair, it
seems that there are always some grammatical
constructions that are difficult to translate.
 For example, the construction NOUN PHRASE + BE +
ADJECTIVE in English (for example, the door was shut) is
difficult to translate into Spanish because the appropriate
translation for the verb "was" depends on its meaning in the
source sentence. If the door was in a shut state, the appropriate
translation would be "estaba"; if the door used to be open but
was shut by someone, who may not be mentioned, the
appropriate translation would be "fue" or "ha sido."
 an example （ cont. ）
 Unfortunately, there is usually not enough
information in the sentence to determine which
meaning was intended, so there is no good way for the
machine translation software to choose the right
translation reliably.
 Depending on the text, this problem occurs with low
to medium frequency, and, while very difficult to
handle automatically, it is very easy for a translator
who is post-editing an automatically corrected text to
spot and correct.
 Therefore, this kind of translation error would be
considered a low priority fault.
 an example （ cont. ）
 An example of a high priority fault in the same
machine translation system is the translation of the
definite determiner "the" in Italian.
 Unlike English, Italian uses a different version of the
determiner, depending on whether the following
word is masculine or feminine, plural or singular,
and depending on the noun's initial sequence of
letters. Suppose that the initially delivered version of
the translation software, when translating English
into Italian, always outputs the same translation for
"the."
 an example （ cont. ）
 This translation would be wrong in a high
percentage of cases.
 This problem would be extremely annoying, because
even though it would be easy for the post-editor to
fix, it would also occur very frequently.
 Moreover, the system has all the information it
needs to apply the right rule.
 Therefore, even though the fix may be somewhat
labor-intensive, it is feasible, and the fault should be
considered high priority because of its unnecessary
negative impact on the productivity of the post-
editor.
 Workarounds
 Sometimes a fault has a high impact, but fixing it
may be too costly or take too much time.
 In this case, short of removing the fault, it may be
possible to find a workaround. 处理这类 问题的简
便方法 ： “旁敲 侧击”的 替代 方案或规避 措施
 A workaround is a change in another part of the system or
process that reduces or eliminates the impact of the fault.
 An example of workarounds
 a product that crashes or becomes unacceptably
slow when processing large files.
 While in the long term, the product will need to be able to
process files of the size found in normal input
 in the short term the problem can be alleviated by using a
preprocessor to cut the original input files into smaller ones
before passing them to the component of the system that
must process them.
 Before Delivering a New Version
 Updated software must undergo rigorous testing before
delivery.
 Especially in large software products with complex
interconnections between modules, repairing a fault can
 introduce new faults or
 bring to light existing faults in other parts of the product.
 The product should undergo regression testing
 it should be tested against a standard test suite passed by the previous
version of the product.
 New test cases employed to verify that a fault was fixed
should be added to the test suite for regression testing of
future versions. 新测试 用例用户下个 版本软件回归 测试
用例
 Documentation
 Before delivering a new version, all fault fixes must
be documented for future maintainers
 any adjustments to specifications or design that are required
by the fixes.
 Release notes detailing updates and workarounds
should also be distributed to the customer.
8.3 Maintaining Object-Oriented Software
 In theory, an OO software product easier to maintain
 because of the properties of objects.
 Encapsulation ：
 Well-designed objects have conceptual independence
 all information pertaining to an object (variables, methods, etc.) resides locally in
the object itself.
 information hiding
 objects have physical independence from each other:
 no other object needs to know the details of the implementation of the object
 just the interface that the object presents.
 Encapsulation and information hiding
 make objects easier to maintain than conventional programs,
 in which these characteristics may be significantly watered down or not present at
all. 但是并不如想象的那么好！
 In reality, it also presents special maintenance challenges
 On the positive side
 it is easier to isolate faults and to identify places where
functionality should be improved.
 changes inside objects should have no impact outside the
object, thereby reducing the chance of regression faults.
 On the negative side,
 the features of object-oriented languages can cause other
types of maintenance difficulties.
 Inheritance can make the product difficult to understand
 the definition of inherited fields may be spread out
all over the code for the product.
 Modify a superclass
 All descendent subclasses are affected
 In order to understand the code for an object in the
lowest tier of the hierarchy
 a programmer may need to understand the code for
the entire hierarchy. 从基类 开始阅读 代码及设 计
说明
 example of a
hierarchy of classes
that define more and
more specialized tree
structures, each of
which may redefine
some methods and/or
variables
 Inheritance can also give rise to the fragile class problem
 changes to base classes from which dependent
classes derive their information can create
unexpected faults.
 a class Bag to store an expendable collection of elements.
 The class provides instance variable b, a bag of char, which is initialized to
empty.
 The class also provides the method add to add an element to a bag, the
method addAll to add several elements by calling add, and the method
cardinality to return the number of elements in a bag.
 Later, a programmer decides to create a specialized class, CountingBag,
which introduces the variable n to keep track of the number of elements in
a bag object.
 The programmer also overrides add to increment n every time that an
element is added to the bag, and overrides cardinality to return the value
of n.
 So far, so good. Still later, a different programmer decides to improve the
efficiency of the system and creates the class Bag', reimplementing addAll
so that it does not call add. The next user of Bag' as the base class for
CountingBag discovers that cardinality no longer returns the right value
after using addAll—because n is not getting updated.
 On the surface, however, the new Bag' base class and the existing
CountingBag class are perfectly compatible.
 Polymorphism and dynamic binding
 Polymorphism and dynamic binding, as powerful as
they are, can also make the software difficult to
understand and debug
 because there usually will be no way to understand which
actual method is being used, except by tracing the product at
run time.
 Schach gives an example of this type of problem on
pages 502-504, 5th Edition or pages 487-489, 6th
Edition.
 Product fails on the invocation myFile.open ()
 Which version of open contains the fault?
 A CASE tool cannot help (static tool)
 We must trace
 8.4 Aids to Maintenance
 In addition to the usual CASE tools for
documenting, compiling, and linking code, and the
tools for recording and tracking fault reports
 维护时 最大的问题及 挑战是什么 ？版本控制
 CASE tools that are particularly useful during the
maintenance phase are version control (or software-
versioning) tools and configuration control tools.
 Also used in the integration phase, these tools
include
 sccs (source code control system),
 rvs (revision control system), and
 cvs (concurrent versions system).
 CASE tools
 They are used to manage different versions of the
same module as it is updated due to fault fixes and
enhancements.
 To keep track of the versions of different modules
that are required in a whole product version, what is
needed is a configuration control tool,
 CCC (change and configuration control) is a commercial
example.
 版本控制过 程
 During maintenance, when a product is undergoing
updates,
 the previous version should be frozen as a baseline and
 new (experimental) revisions should be treated as branches
from the baseline.
  rigorous testing and approval,
  module is released back into shared module pool
  the baseline is updated.
 Since the maintenance phase include the activities of
all previous phases of the software life-cycle process,
 metrics that are relevant to those phases are also applicable to
maintenance.
 In addition, a few more metrics are useful for
tracking fault reports. These include 度量指 标
 the total number of faults reported (in total, during a specific
period),
 a classification of fault reports, and
 the status of those reports.