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
还有其它解决办法吗？ the original problem with customer dissatisfaction can be solved much more simply by
a financial investment, some amount of personnel training, and an increased budget for equipment maintenance.
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
The requirements and specification phases must be completed before
determine more precisely the requirements that the software product must satisfy, specify the expected input and output of the system in detail.
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. should
include 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., in
the 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 selfcontained 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
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?
statements in the specifications every statement in the specifications document should be reflected in some aspect of the design.
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
top-down
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. 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 想躲躲 不了的 )
It is also a good idea to keep a record of
internal code documentation, external documentation testing documents. 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-ofa-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 buildand-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
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.
flaws in the specification, design, and/or implementation are not discovered until after the entire product has been constructed.
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 precoding 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
stabilization
checking in all source code,( 把完成的组件都放在一起 ) building the product, and testing the product 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-andstabilize 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-andstabilize 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-andstabilize model Limited scope:
Frequent iteration through a build/test cycle is not useful for some products. 过渡频繁的迭代对某些产品不合适
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., 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.
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-andstabilize 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:
Well-informed testing: 经过充分的测试
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. 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
Build-and-Fix
Fine for short programs that do not require maintenance
Totally unsatisfactory for nontrivial programs
Waterfall
Disciplined; Documentdriven
Product may not meet customer needs
Rapid Prototyping
Ensures product will meet client's needs
Temptation to reuse code that should be reimplemented instead
Incremental
Maximized early return on investment; Promotes maintainability
Requires open architecture; May degenerate into buildand-fix
Life-Cycle Model
Strengths
Weaknesses
Synchronize-andStabilize
Future users' needs are met; Ensures components can be integrated
Has not been widely used outside Microsoft
Spiral
Incorporates features of all the models above
Can be used only for large-scale, in-house projects; Developers must be competent in risk management
Object-Oriented
Supports iteration within May degenerate into phases, parallelism CABTAB between phases