SSD9: Software Specification, Testing, and

Maintenance
 Unit 2. Software Life Cycle
 2.1 Overview of the Life Cycle
 2.2 Life-Cycle Methodologies

 Assessments
 Exercise 1
 Multiple-Choice Quiz 2
 2.1 Overview of the Life Cycle
 2.1.1 Problem Identification and Scope
 2.1.2 Requirements Analysis and Specification
 2.1.3 System Design
 2.1.4 Implementation
 2.1.5 Testing and Delivery
 2.1.6 Maintenance
 2.1.1 Problem Identification 确定 and Scope 范
围
 The decision to develop a new software system, either
internally or via external contracting is typically
justified:
 需要开发软件以应付局面了

 Perhaps there is no software currently supporting

certain crucial activities.
 Maybe some existing software has become obsolete
and is no longer able to perform effectively the tasks
it was designed to do.
 Perhaps the requirements of the task itself have
changed.
 2.1.1 Problem Identification 确定 and Scope 范
围
 When making a decision to develop (or
purchase) new software, it is essential to
 first understand the problem well,

 verify that a software solution is appropriate

 confirm that there are not other (possibly simpler

and cheaper) ways to solve the problem.
 E.g., a small family-run restaurant
 Initially, with only a few tables, limited clientele, and
short operating hours, the accounting books are kept on
paper manually.
 As the business expands, 生意 越来越 好… …
 They are starting to spend too much time balancing the
books and making sure that expenses and income.
 At that point, they may find it sufficient to purchase a
computer with a small, off-the-shelf accounting
package. ( 想用会 计软件 来管 理了 )
 the business keeps growing, requiring much more floor
space and acquiring many more customers. it is
becoming a real success—the customers love the food
and keep coming back for more. 生意 还在扩 展… …但
 customers begin complaining that it takes too long to
process their orders, 还经常想 点的 都没有 ……
 E.g., a small family-run restaurant
 The restaurant decides that they would like a system
 in addition to balancing the books,
 allows the waiters to key in the orders 输入订单
 send the order to the kitchen right at the table
 customers will know immediately whether their choice is
available.
 而且还 能够… …
 keeps track of what customers want,
 helping the management make better decisions about
menu planning, including the quantities of different
foodstuffs to have on hand.
 as each order is placed, the inventory of basic food
ingredients can be automatically updated,
 making it easier for the management to make daily
purchasing decisions.
 投资有 必要吗？
 the restaurant chooses may result in a order and inventory
management system, but it require
 a financial investment,
 some amount of personnel training, and
 an increased budget for equipment maintenance.
 还有其它解决办法吗？
 the original problem with customer dissatisfaction can be
solved much more simply by
 adding waiters
 giving them radios to communicate customer orders back to the kitchen.
 The inventory update problem might
 be solved by connecting the cash register with an inventory management
software
 allowing dynamic inventory update based on each new order.
 问题确认
 The first part of problem identification is to
 define the problem as precisely as possible
 consider a range of solutions and their associated costs.
 This analysis is essential in determining to build software.
 Another aspect of problem identification is determining the
scope of a solution. E.g.,
 if an organization decides that they must have custom-built 定制
software,
 does the resulting software product need to be implemented for different
hardware platforms 需要在多种平台上实现，我们的都是 pc ＋ win ？
 Depending on the type of software application desired, developing for
one or more hardware platforms may require 有了新软件，还有花钱
买硬件……升级换代 , 处处要钱呀 !
 The responsibility for problem identification
 usually rests with the client ( 取决于客 户 , 客户提
出问题 )
 The software engineer must be sensitive to
mismatches between the problem as described by
the client and the solution the client believes to be
appropriate.
 software developer may use a contract in which
adequately address the customer's problem.
 Statement of Scope 开发范围 的陈述
 An effective strategy for balancing the perspectives
of both customers and engineers is to
 write a formal statement of scope.
 A typical scope statement might include
 Preliminary requirements checklist ( 初步需求表 ) :
 a brief summary of all the primary functionality the customer requires
 "The software must support online ordering of products from our Web site"
 "The software must generate monthly ordering statistics sorted by product
and geographic area";
 etc.
 Customer scope constraints （客户范围约束） :
 The customer's idea of scope is typically expressed in terms of
constraints that identify minimal expectations for the operation of the
software
 "The software must handle at least 100 transactions per minute";
 "The software must run on Windows NT4.0";
 etc.
 A typical scope statement might include
 Developer scope constraints ( 开发者 的范围 约束 ):
 There may be a wide range of software solutions that
satisfy the preliminary functional requirements and
customer scope constraints.
 In the developer‘s best interest, it is to propose the
simplest solution with these characteristics, because it
will typically be the most cost-effective system for the
customer. 实现最简单的方案 , 当然开发者最划算
 it is important for the developer to delimit the
functionality of the proposed system. 最小的功能集
 A typical scope statement might include
 Developer scope constraints ( 开发者 的范围约束 ):
 By defining what will and will not be included, one can
keep the customer from feeling cheated if software
requirements become more demanding after the project
is started or after the software is delivered. 以免客户觉
得受骗上当！
 Additional scope constraints are placed on the software
in order to identify the maximal expectations placed on
the final product
 "The software will be designed to handle a maximum
of 100 transactions per minute";
 "The software will only be guaranteed to run under
Windows NT4.0";
 A well-written scope statement
 the most precise way to specify
 the problem to be solved,
 And the characteristics of the possible software solution(s)
to the problem.
 需求、 规格描述越详 细越好！
 2.1.2 Requirements Analysis and Specification
 Requirements Analysis Phase
 Specification Phase
 Software Project Management Plan (SPMP)
 requirements and specification phases
 After the client and the developer have agreed on the
general goals of the software development effort, the next
step is to
 determine more precisely the requirements that the software product
must satisfy,
 specify the expected input and output of the system in detail.
 The requirements and specification phases must be
completed before
 detailed design can begin
 any coding is attempted certainly.
 In the case of object-oriented design, an analysis of the
characteristics of the required software objects may begin as
early as the specifications phase, even though "objects" are
also considered part of the design and implementation
phases.
 Requirements Analysis Phase
 The requirements phase is of great importance to the
success of a software project.
 Unfortunately, requirements phase is often carried out
incompletely or else neglected altogether.
 During the requirements phase, the client and developer
must determine exactly what functionality the software must
have in order to meet the customer's requirements.
 They must also negotiate important constraints, like
 limitations on development cost,
 major deadlines that the project must respect,
 the performance and reliability expected of the system,
 other constraints imposed by the hardware and operating system.
 A precise definition of software requirements
 A precise definition of software requirements (that is,
the desired functionality) may be one of the most
difficult aspects of the requirements phase.
 The client may not be able to articulate 清晰 明白 表达
in a clear and precise manner what the software needs
are.
 The developer may need a variety of techniques to use
to elicit the client‘s real requirements. 启发用 户说出
需求
 Traditional methods for eliciting requirements include
 structured and unstructured interviews 口头交谈
 Questionnaires
 examination of the process 过程审查 that the client is trying
to automate.
 structured and unstructured interviews
 In structured( 程式化 ) interviews, the developer asks
preplanned, close-ended( 既定的 ) questions — questions
for which a particular form of answer is desired. E.g.,
 how many people will be using the system at the same time
 what kinds of data input the system will need to process.
 To gain a better understanding of how the client will use the
software product, the developer may also engage the end
users of the product in interviews that are more informal.
 In an unstructured( 非程式化 ) interview, the developer
asks open-ended( 随意的 ) questions.
 describe the tasks they will perform and the way they normally process
information.
 observing the users
 Less direct but potentially very informative ways
of learning about
 the process that the software product will support
include examining forms used to process
information, spending time
 observing the users as they perform their normal activities
in order to understand the nature of the task,
 recording those activities with a video camera.

 Observation and recording can be perceived as

intrusions( 客户觉得受到打扰，也许会影响正
常工作 ), so this method should be discussed with
the client and the users.
 The "client" and the "user"
 different individuals belonging to the same
organization.
 In discussions with the developer,
 the "client" is often represented by technical
management personnel
 but the real day-in-day-out( 天天 ) "users" of the
software are likely to be other members of the staff.
 It is important to talk to the users in order to
understand their tasks in detail, and to discern
whether the proposed functional requirements
will really meets their needs.
 An alternative method for requirements definition
 rapid prototyping.
 A rapid prototype is a piece of software
 is developed quickly to demonstrate the visible aspects of the
desired functionality.
 Robustness and error handling are typically not present in a
rapid prototype
 the internal computation may be simulated or left out.
 E.g.,
 if the major aspect of a software product is the interface it
will present to the users, it may be sufficient to “mock-up”
( 模拟 ) an interface using a graphical user interface (GUI)
toolkit, without actually writing any application code.
 An alternative method for requirements definition
 Rapid prototyping is a particularly good approach to take
when the client is not able to give the developer a clear idea
of how the software should operate.
 By building a rapid prototype, the developer provides the
client with a concrete proposal based on the information the
client can offer.
 The prototype can then serve as a focus for discussing,
modifying, and refining ideas further.
 可能会建设多个原型
 Under the rapid prototyping approach, several prototype systems may be
built before the client is satisfied that the prototype reflects his or her
needs;
 when agreement is reached, the requirements for the actual software
product can be derived from the final prototype.
 when the requirements have been made explicit
 Once the requirements have been made explicit, through
elicitation and/or rapid prototyping, the developer can
assess
 the technical feasibility( 技术上的可行性 ) of the proposed software
 provide cost estimates.
 会不会有这些问题
 technically impossible
 impossible within the time and financial constraints
 Any perceived gaps between the required functionality and
the feasibility assessment are cause for 不一致如何解决？
 further discussion and refinement
 even for a decision not to proceed at all, if the requirements and
constraints cannot be changed.
 Testing requirements
 The requirements (in a rapid prototype or a
requirements document) should undergo
thorough testing before the requirements phase
is finished.
 The development organization's software quality
assurance (SQA) group should verify that the
prototype and/or the requirements document are
completely satisfactory to both client and user,
before these documents become the basis for a
more detailed specification.
 牢记：总有新需求提出，不断地有……
 such a document does provide a precise
statement regarding the software that the
developer is under contract to develop.

 But, unfortunately, the existence of an approved

requirements document will not prevent the
client from trying to change the requirements
later
 Specification Phase
 The ultimate goal of the specification phase
(system analysis phase), is to model the desired
software product. 给系统 建模
 We build
 models of the data the system must process (data
dictionaries and entity relationship models),
 models of the transmission of data among
different components (data flow analysis), and
 models of the flow of control from component to
component based on the state of the system
(control flow analysis).
 Different techniques, many of them graphical
(data flow diagrams), are used for specifying the
various aspects of the product.
 The goal of the specification phase
 is to transform the general requirements for a
software product into a concrete document
describing what the system will and will not do:
 this document to be produced is called
 the specification document or
 the specifications.
 The specification document
 What for The specification document ?
 describes the functionality of the system,
 makes explicit the constraints the system
must satisfy (speed or maximum error rate),
and
 specifies the expected input and
corresponding output.
 shouldinclude a description of how the system
should respond to unexpected and erroneous
input.
 specifications may include acceptance
criteria
 These may just be a restatement of the
constraints and input-output behavior,
or a set of tests that a system must pass.
E.g.,
 inthe case of a system designed to translate
between English and other languages, the
acceptance criteria could stipulate( 规定为 )
that the system will be accepted if it
translates correctly 90% of the sentences
contained in texts that have not been used
previously during development and testing.
 The specification functions as a legal contract
 按合同 执行，保障双 方的利益
 The developer will consider the contract completed
when it delivers a software product that satisfies the
acceptance criteria set out in the specifications.
 To avoid complications and disagreements about
whether or not a delivered product meets
specifications, how can you do?
 the specification document should be carefully
checked!
 Checked for ……
 Vagueness of the language: 用词含糊，不精确
 The document should not use terms that are not or cannot be defined
precisely.
 obviously vague terms as "ample memory" or "sufficient speed,"
 sound precise but are not, like "optimal speed" or "98% complete."
 Ambiguity of the language: 指示摸棱两可
 The document should be checked for statements that can be interpreted
in more than one way.
 "The interface module will call the arithmetic module. If the module
receives erroneous input, it will signal an error to the error handler."
 The phrase "the module" in the second sentence can refer to either the
interface module or the arithmetic module.
 Checked for ……
 Incompleteness of the specifications: 不完整
 failure to consider all legal values of an input,
 failure to specify system behavior under unexpected or
incorrect input,
 failure to consider all possible combinations of input when a
system makes decisions based on multiple inputs.
 Checked for ……
 Inconsistency of the specifications: 不一致
 In the specification document for a large system, it is possible that the
same situation arises in more than one context, and it is easy to specify
different behaviors for that situation in different places of the document.
 E.g., the specification document for a database interface system might say
that when the data in an entry form is committed, errors in any of the data
areas of the form will prevent the commit process from completing
successfully.
 Elsewhere in the document, it might say that each field in the data entry
form is individually checked for incorrect values when the cursor leaves the
field, and that no further action is permitted until the error is rectified.
 In a subtle way, these statements are inconsistent or contradictory, because
if the second statement is true and the user enters an incorrect value, then
the interface should not even allow the user to request a commit action.
 specifications document checking
 Like the requirements document, the specifications
document must be carefully examined by the
developer's SQA group, as well as the specification
team and the client, before it is approved and used
as the basis for further work.
 In addition to checking for problems such as
vagueness, ambiguity, incompleteness, and
inconsistency, the SQA group should determine the
feasibility of the specifications based on information
provided by the client.
 specifications document checking
 A very desirable characteristic of the specification
document is traceability 高要求、所以 要认真做
好记录
 the ability to trace every one of its statements to something
the client said during the requirements phase.
 Ideally, it should be possible to
 link each statement in the specification document either to
 a statement in the requirements document or to
 the rapid prototype from which requirements were derived.

 A formal review process 而且还需要 一个正式评 审

的过程
 developer and client teams go through the entire document
systematically
 Software Project Management Plan
 specifications finished  Detailed planning can begin
 only after the specifications have been completed and reviewed
 With a thorough understanding of the software to be built,
the developer can provide firm estimates of how much time
and money it will take to complete the product.
 The detailed plan for development of the software, called the
software project management plan (SPMP) includes
 the personnel 人员 that must be assigned to different phases of
development,
 the deliverables 产品 (what the client will actually get),
 the milestones 里程碑 (when the client will get them), and
 the budget 预算 (what it will cost).
 Note for developer
 If the developer needs the client to provide specific types of
information or files during the development process, the
time when these will be made available should also be
specified in the plan. 用户需要提供的资源及时间也须纳
入计划
 The cost and the duration of the project must be considered
and negotiated carefully.
 The developer must be reasonably sure that it is feasible ( 可
行 ) to develop the product within the allotted time and
budget, or run the risk of losing money and credibility. 丢
钱又丢人啦 !
 At the same time, the developer should not try to inflate
excessively ( 过度夸大 ) the estimates of time and cost, since
this might only prompt the client, especially an external
client, to find another contractor who can do it faster and
cheaper. 这样会失去订单！
 2.1.3 System Design
 specification phase  what the product will do
 design phase  how it will do it.
 The design team uses the specification document to
determine
 the internal structure
 operation of the software product.
 The objectives of the design phase
 Choosing the data structures that will represent the
information manipulated by the program
 Choosing the algorithms that will operate on and
manipulate the data structures
 Determining the internal data flows
 how the information will move from component to
component of the program
 Breaking the product into modules, or self-
contained pieces of code that interact with other
modules in the product through a well-defined
interface 模块分解
 Designing the interface for each module
 The output of the design phase
 consists of two documents:
 The architectural design document describes
 the structure of the system in terms of modules,
 their interfaces, and their interactions (the data flow).
 The process of breaking a software product into smaller
independent modules is called modular decomposition( 模块
分解 ).
 the detailed design, gives
 a description of each module,
 including the data structures and algorithms to be used.
 It specifies and guides the programmers' task during the
implementation phase.
 balance off considerations
 the design team need to such as generality and
complexity, anticipate how the design can handle
 future enhancements
 maintainability
 future reusability of the software.

 new requirements for the product will surface(

出现 ) as soon as the product is delivered, if not
earlier, it is difficult to predict what form they
will take and what enhancements will be needed.
 choose a design accommodate enhancements
 Certainly the designers should choose a design that will
accommodate future enhancements
 that the client has mentioned but are not part of the
current specifications 客户以提出但暂不实现
 that the developer foresees being clearly desirable. 开发
者已预见的
 the design should be as general as possible to allow for
reusability in similar products and adjustment to future
changes, but the cost of this flexibility may be a more
complex design:
 harder to understand,
 take longer to code
 be trickier to test

 record the reasons for any decisions
 The design team should carefully record the
rationale( 基本考虑 ) for any decisions taken
during the design process.
 Two reasons for why it is very desirable to document
the design decisions.
 May need to redesign some aspect of the program,.
 help designers determine whether a redesign is really
necessary or desirable. 回头看看当初这样设计的原因，决
定是否真的要重新设计
 requested enhancements or modifications
 be helpful in determining if the requests can be accommodated
without overthrowing key design assumptions. 增加新内容时
是否要推翻关键的设计构想
 Useful in other aspect 为了忘却 的记忆……
 In the long term, a record of design decisions is
useful in deciding whether the design
 for a program has become obsolete( 废弃 ) in the face of
changing requirements, or
 was flexible enough to accommodate the necessary changes.
 Having a record of design decisions is particularly
crucial in an organization with a high rate of
turnover( 剧变， 如跳槽 ) of technical personnel
 it is risky to rely on the continued presence and memory of
individuals who participated in the design process.
 design documents should be tested
 Like the specification document, the design documents
should be traceable.
 each design choice should be linked to
 statements in the specifications
 every statement in the specifications document should be reflected in some
aspect of the design.
 The developer's SQA group and design team should jointly
perform a formal review of the design documents, carefully
inspecting them to insure the design
 complete and correct
 respects the specifications.
 Examined what?
 Both the individual modules and
 the overall design.
 In addition, the reviewers should be alert to possible faults
and oversights ( 疏忽 ) in the specification. 防止检查错误
的人出错！
 2.1.4 Implementation
 design phase  Implementation
 programmers receive the detailed design document
 begin implementing the modules, data structures, and
algorithms according to the document's content.
 In addition to the code itself, the main output of the
implementation phase include: 光有 程序源码够 吗
？
 In-line documentation of the code
 Separate written documentation of the code
 Testing document and test cases
 Code documentation is an essential part of implementation
 Code documentation is an essential part of
implementation and has extensive repercussions( 影
响 ) for ease of maintenance.
 the individuals maintaining the code once it is
delivered will not be the same persons who wrote it
 It is exceedingly difficult to understand code that is not well
documented.
 Even if the code developer and maintainer is the
same person,
 it does not take long before understanding one‘s own
program without the help of documentation becomes far
from straightforward. 时间长了，自己也会记忆模糊
 Appropriate locations for comments in the code
 Appropriate locations for comments in the code
include:
 top of modules or object class definitions;
 declarations of important local variables and global
variables;
 procedure/function or method definitions
 interspersed with the lines of code, especially if the code is
long or complex. 代码行中，便于阅读者理解
 Decisions to implement data structures or algorithms in
unusual and non-obvious ways 异常处理的数据结构与算法
.
 Some programming languages provide built-in
support for automatic generation of documentation
from the source code comments
 a separate document explaining the code
 除了代码注释 , 还要有
 a separate document explaining the code in less detail but
highlighting major aspects of it.
 External documentation should be geared towards ( 注重于
) extensibility and maintainability of the code.
 It is the first documentation that a new programmer on a
project will read.
 For a module, such a document will include
 a description of the interface,
 all accessors 存取方法
 their input arguments
 the kind of output.
 An accessor is a general term that refers to functions,
procedures, or methods defined in a module and operate on
its internal data structures.
 document should include …
 The document should also include
 specific input-output pairs 在规格文档中指定的 I/O 配对
 a general description of the data structures used in the module,
 the algorithms incorporated in the module
 individual accessors 每个存取方法
 any assumptions governing the use of the module. 模块使用的条件设
定
 This module-specific, high-level documentation will be
combined with similar documents for other modules into a
top-level document 各模块文档形成更高层的说明文档
 includes a general description of how the modules fit together
 the data flows among them.
 Testing during implementation
 Testing during implementation and on the
module level, referred to as desk checking ( 部件
检测 ), is the responsibility of the programmer.
 Testing should be performed right along with
coding. 模块 编码完成了 就可以开始 测试
 While testing code, a programmer should put
together a suite of test cases for each externally
visible accessor to the module.
 test suite
 The test suite should cover
 all possible input to that accessor

 The programmer should also compile a test document,

which includes
 general instructions for testing the module,

 the test cases (or a reference to the location of the test

cases)
 any remarks relevant to the testing process ( the required
order of testing).
 Test cases will be used in regression testing ( 回归测 试 )
 in checking that a module, or an entire system after it has
been changed still performs correctly.
 uses the test document to test the module
 In the final stage of implementation, the SQA group
uses the test document to test the module
methodically.
 A formal code walkthrough( 代码走查 ) is another
important type of review
 the programmer guides the members of the review team,
including an SQA representative, through the listing of the
module.
 It is similar to the formal reviews carried out for
requirements, specification, and design documents.
 2.1.5 Testing and Delivery
 Integration Testing
 Product Testing
 Acceptance Testing
 Alpha and Beta Testing

 The integration phase begins when all modules have been

individually tested and documented.
 The purpose of this phase is to combine all the modules, test
their operation together, and verify that the product as a
whole satisfies the specifications and behaves correctly in all
circumstances.
 Testing is the SQA group ’s responsibility, but the developers
should be testing all along, constructing, and saving test
cases that the SQA group can run as part of their testing.
 Integration Testing
 The first step is to perform integration testing.
 The design document will include a module
interconnection graph, which shows how modules fit
together.
 One aspect of integration testing is making sure that
 the module interfaces are called with the right number of
parameters
 in the right order
 of the right type
 If the programming language is a strongly typed( 强
类型 ) one, this test is performed by the compiler
and linker, but in more weakly typed( 弱类型 )
languages, it must be done by humans.
 two ways of Integration testing
 In bottom-up integration
 integration and testing of modules proceeds by
 beginning with basic modules appearing lower in the graph,
 then by working up toward higher-level modules that rely on
them.
 In top-down integration
 the order is reversed.
 advantages and disadvantages of each approach
 bottom up
 the lower modules are likely to undergo thorough testing( 全
面测试 )
 but basic design faults that have gone unnoticed ( 容易被忽
视 ) will show up late in the testing process
 will require extensive rewriting and retesting.
 top-down
 testing from the top down will identify integration faults
early,
 but due to time constraints will probably result in less
thorough testing of the lower modules. 对底层模块测试不
全面
 Because of the weaknesses of each approach, they
should really be combined into an approach that has
been called sandwich integration.
 When make integration testing?
 Ideally, integration testing should not wait until the
coding of all modules is completed. 不必等 到编码
结束
 it should begin during implementation.
 If design faults are discovered, they can be corrected
before all the code is written.
 However, integration testing during implementation
does not obviate( 省去 ) the need for a formal
integration testing stage before delivery.
 Product Testing
 integration testing  product testing
 This stage of testing has several aspects to it:
 Performance testing consists of
 comparing the product to the specifications,
 particularly on performance constraints like speed or response
time that were stated in that document.
 Robustness testing seeks to
 determine whether the product responds in an acceptable
manner to bad input.
 The expected response may be described in the specification
document.
 Product Testing
 This stage of testing has several aspects to it:
 Installation testing is performed by
 running the product with the client’s currently installed
software.
 The objective is to verify that the product will have no
negative impact on the client’s existing computer operations.
 Documentation testing requires
 performing a final check that the documentation describes the
source code and its use completely and consistently.
 Acceptance Testing
 It is The final stage of integration testing
 During this stage, the client tests the software product on
their own hardware and uses actual data instead of the data
used by the developer during development and testing.
 actual data vs. test data
 No matter how carefully assembled the test data is
 it may differ in some important ways from the actual data.
 Once the client has verified that the product performs as
desired on actual data, the client accepts the software.
 At that point, the developer will have satisfied its side of the
contract embodied in the specification document.
 Alpha and Beta Testing
 They are 2 terms that are frequently associated
with product testing -- Alpha and Beta Testing
 These terms have different definitions,
depending on the kind of software being
developed.
 software product that is being developed for a specific client
( 项目委托开发 )
 alpha testing
 usually refers to testing in a controlled environment 在一个可控
的环境下— in the developer's site.
 This phase of testing focuses on the functionality of the software
rather than on its performance or robustness.
 A member of the developer‘s team is on hand to help resolve any
problems caused by faults in the software as it is being tested. 有
专人随时解决问题
 beta test
 is a quasi-final version( 准最终版本 ) of the software product,
installed at the client's site and on the client's hardware, and being
used to perform real tasks in a production-like setting.
 This type of testing addresses performance and robustness.
 Its intent is to identify problems that might not show up except
through extended use in a realistic setting.
 commercial off-the-shelf or COTS software
商用软件产品
 Whereas with a one-of-a-kind type of product
 there is usually a close relationship between client and developer
 a friendly process for handling faults discovered both during product testing
and after delivery.
 The manufacturer of shrink-wrapped software does not have a
specific client and cannot afford to deliver a product with
significant problems.
 Alpha and beta testing are often conducted with selected
individuals or organizations getting the finished product at no
cost( 免费 ), in exchange for testing and providing feedback on
the product in a variety of realistic environments.
 The testers need to be aware that there are risks in using an
alpha or beta version of a product, and to balance them against
the advantages that might result from getting a head start( 领先 )
on the use of the product.
 2.1.6 Maintenance
 the software product has been accepted by the client
 Maintenance  before it has been retired
(replacement or full removal)
 This phase should not be considered unpleasant or
inconvenient.
 Rather, it should be regarded as a natural and
integral part of the software process.
 软件总 要毛病… …
 Do you remember ?
 that by far more money is spent on maintenance than on any
other software-related activities—on average 67% of the
development cost.
 Through actual use, the users may find residual
problems with the system that will need to be
corrected.
 enhancements are desirable 总有新的 内容要添加
 Certain enhancements are desirable in order to
increase the usefulness of the product to the client
and the users —enhancements, in functionality or
performance.
 Some of these enhancements will have been foreseen, though
not included in the original specifications;
 others may surface through use.
 If the software product was designed with flexibility
in mind, these changes will be relatively easy to
perform.
 the developer is usually responsible for required
changes
 Unless the client has the necessary resources and agrees
to maintain the product after acceptance, the developer
is usually responsible for implementing required
changes.
 Changes or enhancements to any part of the software
require thorough testing before delivery to the client.
 Testing must check that specific problems were indeed
fixed and that new functionality behaves as it should.
 不要因 修改引 入错 误！
 regression testing
 In addition, because software systems are complex
interdependent( 相互关 联 ) systems, it is essential to
check that changes did not have an adverse impact ( 不
利的影 响 ) on seemingly unrelated parts of the product,
no matter how modular the design.
 This type of testing is called regression testing.
 In order to perform regression testing reliably, all
previously used test cases and their output must be
retained. 进行 对比测 试
 How to do?
 New test cases for enhancements should also become part of the
test suite
 testing documents must be updated to reflect the addition of new
test cases or changes in testing procedures.
 updating the documentation
 updating the documentation, including (one is tempted
to skip or perform less than thoroughly 想躲躲 不了的
)
 internal code documentation,
 external documentation
 testing documents.
 It is also a good idea to keep a record of
 what changes were performed
 why they were performed, and
 what approach was taken.
 This amounts to ( 相当 于 ) updating the requirements,
specification, and design documents. 它适 时的 记录了
变化， 在原有 文档 上做增 量
 updating the documentation
 Members of the SQA group should participate in
 testing the modified product
 reviewing the changes to affected documents.
 It is expected that the product will undergo
maintenance several times, possibly over a period of
many years. 太有 可能了 ！
 Documentation that no longer reflects the actual state of
the software can be as or more misleading than no
documentation at all.
 So, it is crucial that documentation be kept up to date so
it can always give an accurate description of the current
state of the product.
 the approach to maintaining
 As with testing, the approach to maintaining a
software product depends upon whether it is one-of-
a-kind or shrink-wrapped software.
 A significant difference from the one-of-a-kind
software product for the shrink-wrapped product is
that
 in the latter case the developer cannot afford to send out a
product that still contains significant faults.
 the approach to maintaining
 one-of-a-kind
 It is one thing for a developer to fix a bug and send an
updated copy of the product to a client with whom it has a
close relationship;
 shrink-wrapped software
 it is quite another to send updated copies to everyone who
has purchased an off-the shelf software package.
 the cost of the redistribution effort,
 the customers will lose confidence in the product and turn to
a competitor's offering.
 much more thorough testing is essential for shrink-wrapped
software.
 一般都能做到的 善后工作
 Nonetheless, a software package is seldom perfect when it is
first released. 但事情总 是不 尽如人意 ……
 A company producing shrink-wrapped software, if it wants
to maintain good relations with its customers and improve
the viability of its product, will typically set up a help desk
to handle phone-in or mail-in problem reports and
inquiries.( 做好客服工作 )
 Many common questions and problems, however, can be
handled effectively through a product support Web page,
one that includes a Frequently Asked Questions (FAQ) list
and information about product updates and patches that the
customer can order or download directly from the Web
page.
 2.2 Life-Cycle Methodologies
 2.2.1 Build-and-Fix Model
 2.2.2 Waterfall Model
 2.2.3 Rapid Prototyping Model
 2.2.4 Incremental Model
 2.2.5 Synchronize-and-Stabilize Model
 2.2.6 Spiral Model
 2.2.7 Object-Oriented Life-Cycle Models
 2.2.8 Comparison of the Models
 2.2.1 Build-and-Fix Model
 When a software product is constructed without
specifications or preliminary design, the developers
typically have to rebuild the product several times
before they "get it right."
 This development model is referred to as the build-
and-fix model.
 Build-and-Fix Model
 an initial version  reviewed by the customer builds a new
version  reviewed  ……
 until the customer feels the product is ready for operation.
 drawbacks to the build-and-fix model
 The most important disadvantage is that
 flaws in the specification, design, and/or implementation are not
discovered until after the entire product has been constructed.
 If significant changes to completed modules are required
because of customer reviews, then the overall time and cost
of the development will be much greater.
 because a lack of formal specification, design, and reviews almost
guarantees that some faults will not be identified until after the system is
completed.
 the build-and-fix model is a poor choice for software systems
larger than a few hundred lines of code. 除非是很小的软件
 drawbacks to the build-and-fix model
 Another disadvantage of the build-and-fix model is
that
 the systems produced by this approach are typically difficult
to understand and maintain, because they completely lack
any specifications or design documentation.
 some occasions where build-and-fix model is used
 Because the build-and-fix model does not include the pre-
coding development phases (requirements, specification,
design), it is not considered a complete life-cycle model.
 some occasions where build-and-fix model is used:
 the requirements are simple and well known
 the desired behavior of the software is easy to conceptualize 易于解释
及理解
 the success / failure of the implementation is easy to verify
 Small programs that provide a well-defined, simple function
(like sorting an array) can
 be built through a few build-and-test iterations in a relatively short
period.
 a full-blown life-cycle model ( 完整的生命周期模型 ) may be
inappropriate in terms of time and cost.
 2.2.2 Waterfall Model
 Until the early 1980s, the only widely accepted life-cycle
model was the waterfall model.
 The waterfall model includes the full set of development
phases (Requirements, Specification, Design,
Implementation, Integration, Operation, and Retirement).
 The phases are arranged sequentially in the order given.
 When each phase is completed, it is capped( 封闭，结束 )
by a Verify or Test activity, which implies that each phase
must be approved by a Software Quality Assurance (SQA)
group before it is considered done.
 For some types of software development (especially contract
software development for an external customer), the
Verification step may also include a formal review or test
performed by the customer.
 The key feature of the waterfall model
 it supports feedback from later phases to earlier
phases. E.g.,
 When a flaw in the original design is found during the
Implementation phase.
 In the waterfall model, the required changes to the design are
input to a second iteration of the Design phase, which must
accommodate those changes and undergo an additional
Verify step before work continues.
 Then all subsequent phases must be adjusted to
accommodate the Design change. 以下的每个步骤都要调
整以适应设计变更
 The presence of a formal feedback mechanism
 It ensures that adjustments during the development
cycle can be handled with a minimum of disruption(
中断 ).
 Since the waterfall model requires that the
requirements, specification, and design are precisely
documented before implementation begins, it
addresses 克服了 the fundamental flaws of the
build-and-fix model.
 In general, the addition of formal documentation,
plus testing and verification at each step,
dramatically reduces the amount of work that must
be redone after implementation has already begun.
磨刀不 误砍柴功
 waterfall model has a significant potential weakness.
 This model relies on detailed specification documents to
achieve a consensus with the customer regarding the
requirements and functionality of the software.
 it requires technical skill to understand detailed software
specifications
 this approach risks a situation in which the customer and
developer do not share the same understanding of the
software. 说的是一回事，想的又是一回事
 This can lead to scenarios in which the developer builds
software that meets its specifications exactly, and yet is not
what the customer actually expected.
 This drawback is addressed by the rapid prototyping model.
 2.2.3 Rapid Prototyping Model
 瀑布模 型不灵的时候
 if not all the requirements analysis and specification can
happen before any code is written and any modules are
tested.
 when the customer lacks technical skill, is unable to write a
detailed requirements checklist
 unable to participate fully in the requirements process.
 The rapid prototyping model stresses the quick
creation of a software system that is really just a
prototype.
 It include an extensive subset of the intended
functionality or user interface,
 The advantage of the rapid prototype
 It is a focal point for discussions with the customer
about requirements.
 Even if the customer lacks the technical skill to describe
requirements in software engineering terms, 没有吃过猪肉
也见过猪跑呀
 the customer can talk about a user interface
 how it should be organized, what functions it should provide
 If the developer can create a “working model” of the
system to be built, after a “test drive”( 试用 ) of the
proposed software
 much valuable feedback, and constructive criticism will arise
from discussing the model with the customer.
 The advantage of the rapid prototype
 it can help to mitigate( 减轻 ) technical risk.
 By trying quickly to build a basic version of the
software using the planned software technology,
 the developer can uncover any unforeseen
problems with the proposed technology.
 This happens before beginning to a full-scale
schedule and budget.( 不是全部构造完，再拿给
用户看 )
 A disadvantage of the rapid prototyping model
 the developers may succumb( 屈从于 ) to the
temptation to reuse code that was not developed
according to the guidelines of a software
engineering process. 经常将 类似系统改 造一
下
 Prototype code is often low-quality code,
produced very quickly in limited time (and with
limited testing, documentation, etc.).
 Such code usually does not form a solid basis for
a full-scale implementation.
 On the other hand, the
work done on a rapid
prototype is an important
source of ideas for the
design of the full-scale
system.
 有了参 考评论的依据
 可以启 发很多人的 想象
力
 2.2.4 Incremental Model
 In the incremental model, a single product is split up
into a set of successive releases.
 The development cycle makes a distinction between
the “core product” and various incremental
enhancements to the core product. 核心版本或 基
础版本
 Each incremental enhancement is a fully
operational product.
 The major advantage of the incremental model
 it produces an operational product at every step.
 The first delivered product usually includes the core
functionality, which gives the highest degree of cost benefit
to the customer.
 new functionality (and corresponding complexity) is
introduced gradually at the customer site.
 incremental development has easier maintainability, because
the architecture of the system must support straightforward
extension( 简单直接的扩展 ) of the core modules.
 disadvantages of The incremental model
 the problem to be solved must allow an incremental
software solution.
 If the required software must all be present for any product to be
considered functional, then the incremental model is not
appropriate. 什么功能都急着需要，就不适用
 It must be possible to scope out the architecture of the
entire system. 还要 设计适 应这 种开发 模式 的架构 —
如插件 模式
 It is also true that the incremental model presupposes a
stable upgrade path from product to product, and that
an incremental design is feasible.
 Attempts to use the incremental model (instead of the
spiral model) with a rapidly changing product can
degenerate into using the build-and-fix approach.
 disadvantages of The incremental model
 Not all products fit this description.
 Products that evolve rapidly beyond their original conception
during development are a difficult challenge for this model
 need a complete view of the final product for an effective
incremental design.
 Note ：
 Attempts to use the incremental model (instead of the spiral
model) with a rapidly changing product can degenerate into ( 变
成 )using the build-and-fix approach.
 为什么呢？同学们思考一下
 2.2.5 Synchronize-and-Stabilize Model
 The synchronize-and-stabilize model is also known
as the "Microsoft model."
 This approach has been used extensively in software
development at Microsoft.
 Features of Synchronize-and-Stabilize Model
 The development of a product is split up into three or four
incremental versions 组件 .
 核心组件 + 重要组件 + 次要组件 + 其它组件
 As each version is implemented, the developer team follows
a regular cycle that includes
 synchronization
 checking in all source code,( 把完成的组件都放在一起 )
 building the product, and
 testing the product
 stabilization
 all of the faults identified during testing are fixed
 freeze
 Once the system is stabilized, not change the set of the program sources ,
providing a working "snapshot" of the product at that point in time.
 The primary advantages of the synchronize-and-
stabilize model
 Support for early testing:
 Since the model requires that all aspects of the product be synchronized
and tested together at each step, the product can be tested "early and
often."
 This helps to find and fix faults as early as possible,
 reducing the overall cost of software faults over the life of the project.
 Constant interoperability 不变的互操作性 :
 Each version of the product contains modules that have been tested
together successfully.
 there is always a working (though perhaps incomplete) version of the
product that can be examined, tested, etc.
 This advantage is useful in integrating with external software;
 the development process can be structured so that connections to other
products can be implemented and tested early.
 The primary advantages of the synchronize-and-
stabilize model
 Early feedback on design:
 A development model that requires a full, testable
build of early versions of a product will help to
uncover design flaws that are typically only
discovered during implementation.
 the synchronize-and-stabilize model requires
 all modules be synchronized and tested
together,
 any flaws in the design that result in faults in
the implementation will be discovered earlier
rather than later,
 reducing the overall cost of faults and potential
redesign activities.
 The primary disadvantages of the synchronize-and-
stabilize model
 Limited scope:
 Frequent iteration through a build/test cycle is not useful for some
products. 过渡频繁的迭代对某些产品不合适
 E.g., if testing cannot be largely automated, then the cost of performing a
full test can place a limitation on how much testing can be done early in the
process.
 The relationship between the amount of development activity and the
amount of synchronize/stabilize activity in a given time period must be
appropriate. 时间分配比例要合适
 E.g.,, consider a scenario in which one day of development work is
followed by a day of synchronize-and-stabilize work. While this might be
appropriate for systems in which small changes have widespread effect, it
will be highly inefficient in scenarios where the quality of the code
produced is high, and faults do not occur with great frequency.
 On the other hand, the build/test cycle must be carried out often enough
to ensure that there is an up-to-date snapshot of the current product
version. 也要频率适中，保证产品具备最新特性
 A weekly, biweekly, or monthly cycle may be appropriate, depending on
the particular project.
 The primary disadvantages of the synchronize-and-
stabilize model
 Limited experience:
 So far, the synchronize-and-stabilize model has not been
used widely outside of Microsoft.
 2.2.6 Spiral Model
 The spiral model extends the advantages of rapid
prototyping to a full life-cycle approach.
 a risk analysis is performed
 At the beginning of each phase, a risk analysis is
performed.
 The goal of the risk analysis is to identify and
resolve the software risks that have the greatest
likelihood and most significant impact on the
project.
 If any risks are identified that cannot be resolved,
then the project may be terminated.
spiral model
 In simplified form,
the spiral model is
like a waterfall
model in which each
phase is preceded by
risk analysis.
 the four fundamental activities
 只要时间、经费允许，怎么做都可以，只要把活练好
！
 there is no reason why the development model cannot contain several
prototyping steps .
 There is no limit to the number of iterations through the spiral that can
be included in a project development plan.
 The only invariants are the presence of the four
fundamental activities, represented by the four quadrants of
the spiral, starting in the upper left:
 Determine objectives, alternatives, constraints.
 Evaluate alternatives, identify, and resolve risks.
 Develop and verify next-level product.
 Plan next phase.
Simplistic version of spiral model
the full IEEE version of the spiral model
 The advantages of the spiral model
 Support for software reuse:
 Because the model includes an explicit activity in which alternatives are
evaluated, it is natural to consider reuse of existing code modules as part
of the spiral model.
 Well-informed testing: 经过充分的测试
 Because each phase includes a detailed risk analysis, the testing for that
phase can be focused on precisely those risk factors that are crucial for
successful validation of that phase.
 It is therefore more likely that each phase will conduct appropriate
testing for that phase.
 Seamless transition( 无缝转移到 ) to maintenance:
 Post-delivery update of the software (maintenance, enhancements, etc.)
involves simply going through additional cycles of the spiral model,
which works equally well for post-delivery software activities. 与开发
中的形式完全相同
 The disadvantages of the spiral model
 Applicable only for internal projects
 The spiral model is iterative, and it is extremely useful
where the overall requirements, risks, etc. of a product
have not been completely investigated in advance.
 external software contracts typically involve a contract
up front ( 签合同时都约定好了的 ), with specific
deliverables and time commitments.
 Projects that require the spiral models because
 several alternatives are to be explored
 overall design, cost, and schedule are indeterminate.
 For that reason, the spiral model has only been applied
for internal software development.
 The disadvantages of the spiral model
 Limited to large-scale products:
 Because the spiral model requires quite a bit of global process
activity at each phase (e.g., risk analysis), it may not be
appropriate for projects where the overall amount of development
is small.
 It is not cost effective if the cost of the iterative risk analysis is
comparable to the cost of the project overall. 小项目频繁做风险
分析不划算
 Requires risk analysis expertise: 需要风 险分 析的高 手
 If the developers are not skilled at risk analysis, they may miss an
important risk or limitation.
 The success of the spiral model depends on the availability of
competent risk analysts. 能够胜任的风险分析师
 2.2.7 Object-Oriented Life-Cycle Models
 As mentioned earlier, there are differences between
traditional approaches to software development and
the object-oriented approach.
 In particular, with the object-oriented approach
there is much more interaction between the phases
of the life cycle.
 Object-oriented life-cycle models have been
proposed that explicitly model the iteration( 迭代 )
between phases.
 For example,
consider the
fountain model(
喷泉模型 )
 没有明显 的边界
 different phases overlap with each other
 The circles indicating the different phases overlap
with each other, reflecting an overlap in those
activities.
 E.g., overlap is necessary between the object-oriented
analysis phase and the requirements phase.
 This is because the requirements analysis methods used in
object-oriented development typically include some steps
(use case analysis, object modeling) that are also part of the
object-oriented analysis phase.
 The arrows within each phase indicate iteration
within that phase.
 The central upward line and downward arrows
represent the iteration might require a return to an
earlier phase as well. 从头开始迭 代
 The fountain model is useful for OO development
 it provides a better description of the overlap between
phases and the need for iteration and interaction.
 weakness of this The fountain model
 the lack of any other constraints on the development process
 it can degenerate( 退化 ) into random build-and-fix if the developers are
undisciplined.
 The fountain model is best accompanied by a linear process
that indicates the overall flow of development (while
admitting the possibility of some iteration).
 2.2.8 Comparison of the Models
 A comparison of the various life-cycle models
 Comparison of the Models
Life-Cycle Model Strengths Weaknesses

Fine for short programs

Totally unsatisfactory for
Build-and-Fix that do not require
nontrivial programs
maintenance

Disciplined; Document- Product may not meet

Waterfall
driven customer needs
Temptation to reuse code
Ensures product will that should be
Rapid Prototyping
meet client's needs reimplemented
instead

Maximized early return Requires open

on investment; architecture; May
Incremental
Promotes degenerate into build-
maintainability and-fix
Life-Cycle Model Strengths Weaknesses
Future users' needs are
Has not been widely
Synchronize-and- met; Ensures
used outside
Stabilize components can be
Microsoft
integrated
Can be used only for
large-scale, in-house
Incorporates features of
Spiral projects; Developers
all the models above
must be competent in
risk management

Supports iteration within

May degenerate into
Object-Oriented phases, parallelism
CABTAB
between phases