软件工程
第1讲 软件工程概述
软件危机与软件工程的产生
软件工程的基本概念
软件工程研究的主要内容
软件开发模型
软件危机与软件工程的产生
软件与软件的特点
软件的定义：
软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。
简略地说：
软件＝程序＋文档
软件的复杂性
软件是一种逻辑实体，而不是具体的物理实体，它具有抽象性
软件是“开发”出来的，不是“制造”出来的
软件维护不同于硬件维修（参看硬件和软件失效率的对比图）
软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性
软件的开发效率仍相当低，至今尚未完全摆脱手工作坊式的开发方式
硬件和软件失效率的对比：
软件的三个发展阶段
第1个阶段：程序时期（约为20世纪50至60年代）
程序规模小，每一个程序都是为求解某一个问题而专门设计的，几乎没有什么系统的方法可遵循，程序设计常常是设计者头脑中进行的隐含过程，除了程序清单，基本没有设计文档资料，其生产方式完全是“个体手工方式”，人们只有程序的概念而没有软件的概念。
第2个阶段：程序+说明时期（约为20世纪60至70年代）
软件技术取得了很大的进展，如多用户人机交互、文件管理、多种高级语言的出现、形式语言理论、编译技术的突破等，给计算机的广泛应用奠定了基础。
但是，软件应用的需求变多，规模变大，复杂程度变高，使得“个体生产方式”已经不能适应生产要求，而是需要多人分工合作共同编制程序，形成了所谓的“作坊式生产方式”，这种方式造成了开发约定不清晰、程序说明不完整，导致了软件质量不高、成本失控、生产效率过低、工期延误，后期难于维护，甚至一个软件项目在开发过程中途夭折等，最终导致“软件危机”的开始。
软件危机
软件危机是指在计算机软件的开发和维护中所遇到的一系列严重问题
原因：
1）软件本身的复杂性
2）软件维护和开发方法不正确
表现：
软件开发周期大大超过规定日期;
软件开发成本严重超标;
软件质量难于保证。
例: Windows95有1000万行代码
Windows2000有5000万行代码
Exchange2000和 Windows2000开发人员结构
约3200人
350人
测试人员
约1700人
140人
开发人员
约250人
25人
项目经理
Windows2000
Exchange2000
为了摆脱软件危机这一困境，北大西洋公约组织NATO （North Atlantic Treaty Organization ) 于1968年召开软件研讨会（Conference on Software Engineering），并首次提出“软件工程”这个术语，从此诞生了软件工程这个新兴学科。
从70年代初开始，软件工作者主要围绕软件过程和开发模型、开发方法和技术、开发工具和环境，开发规范和标准以及软件管理等各个方面的研究和实践，使“作坊式生产方式”，逐步过渡到“软件工厂式的生产方式”，软件的生产步入了系列化、产品化、工程化和标准化的进程。
第3个阶段：软件工程时期(约为20世纪70年代以后)
软件工程的基本概念
软件工程定义
是指导软件开发和维护的工程类学科，它以计算机科学理论及其他相关学科的理论为指导，采用工程化的概念、原理、方法和技术，进行软件的开发和维护，并与经过时间证明正确的管理方法与措施相结合，以较少的代价获取高质量的软件。
软件工程的目标
具体包括：
付出较低的开发成本
达到要求的软件功能
取得较好的软件性能
开发的软件易于移植
需要较低的维护费用
能按时完成开发工作，及时交付使用
软件生存周期SLC（Software Life Cycle）
一个软件产品通常是从模糊的概念开始，逐步建立起产品的需求，并对需求进行说明，然后进行设计、实现和测试。如果客户是满意的，那么就可安装产品，并且开始运行和维护它。如果产品到达了其有用生命的尽头就会退役、报废或停止使用。这一系列过程，我们称为软件的生命周期。
软件生命周期
软件的生命周期可以归结为以下几个主要阶段：软件计划、需求分析、软件设计、编码、测试、维护与运行、退役等。
实际上，每个软件的生命周期有所不同，如有的软件可能在需求阶段花费几年的时间，有的软件在设计和实现阶段只需几个月时间，有的软件则在维护阶段可能长达十几年。
软件生存周期划分的意义
把软件的整个生存周期划分为较小的阶段，给每个阶段赋予确定而有限的任务，就能简化每一步的工作，使软件开发过程易于控制和管理。
采用这种划分，使得每一个阶段的工作相对独立，有利于简化整个问题的解决，且便于不同人员分工协作。而且严格的科学的评审制度提高了软件的质量，从而大大提高了软件开发的生产率和成功率。
第一个阶段：软件计划（Planning）
确定要解决的“问题是什么”及“解决问题的可行方案”
即确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的概要性要求；
从技术方面、经济方面、法律方面探讨解决问题的可能方案
对可利用的资源（如计算机硬件、软件、人力等）、成本、可取得的经济效益、开发的进度做出估计，
制定出完成开发任务的实施计划等，提交管理机构评审。
第二个阶段：需求分析和规格说明（Requirement Analysis and Specification）
确定目标系统要“做什么”。
对软件计划阶段的要求进一步细化和求精，强调软件分析人员与用户、软件分析人员与软件开发人员的交互。
充分理解软件的作用域、所需功能、性能及接口、安全与保密、人机工程与人机界面、数据定义及数据库、安装及验收等需求，落实用户所需文档、用户操作和运行需求、用户维护需求，然后写出软件需求规格说明书，提交管理机构评审。
第三个阶段：设计（Software Design）
确定目标系统要“怎么做”。
软件设计是将需求转换成为软件的表示，包括数据结构、软件结构、接口表示和过程细节。
通常将前三者划为软件的初步（概要）设计，后者则归为软件的详细设计。
这些软件表示应该按照规定的标准形式加以描述，形成软件设计规格说明书，提交管理机构评审。
第四个阶段：编码（Coding）
编码体现了目标系统的“具体实现”。
编码是将设计转换成计算机可以接受的语言代码——源程序。如果设计给出的描述很详细，那么编码几乎可以机械地完成。自然，编码必须与设计表示一致、具有结构简单、清晰易读等良好的编码风格。
第五个阶段：软件测试（Software Testing）
软件测试是保证软件质量的重要手段，其主要任务是检查该软件是否符合要求，其目的是发现软件存在的错误。
软件测试依据软件规格说明设计测试用例，并施加在已经编码的程序上进行执行，经过对预期结果和实际执行结果的比较、分析，来发现程序的错误，最后形成测试报告。
测试的主要过程有单元、集成、系统、验收和安装测试等。
第六个阶段：运行/维护（Running/Maintenance）
该阶段体现软件是否能够持久满足用户的需求。已交付的软件投入正式使用后，便进入运行和维护阶段。
软件维护的实质是对软件继续进行查错、纠错、修改和确认的过程。无论是应用软件或系统软件，都要在使用期间不断改善和加强产品的功能和性能、适应运行环境的改变、纠正在开发期间未能发现的遗留错误。
第七个阶段：报废/退役（Retirement）
当软件经过一段时期运行和服务后，便可能报废或退役。
主要的原因有：
为满足用户的需求所做的维护费用太高，可能比新开发一个软件所花费的代价更高。
维护的少量变化对于依赖性很强的软件的整体功能而言，有极大的危险。
环境的变更（如硬件或操作系统）导致软件的更换。
用户不再需要这个软件。
软件工程研究的主要内容
规范和标准
方法和技术
工具和环境
过程与管理
规范和标准
(1) 一个好的企业，应有一套良好的标准来配套
软件的工业化生产过程应具备的特点：
明确的工作步骤
详细具体的规范化文档
明确的质量评价标准
(2)软件工程标准的意义
提高软件的质量
提高软件的生产率
提高软件人员之间的通信效率
提高软件管理水平
降低软件的成本
缩短软件开发周期
软件产品的标准化
软件开发过程的标准化
(3)软件工程标准的层次
根据软件工程标准制定的机构和标准适用的范围有所不同，它分为5个级别：
国际标准:如ISO 8631-86Information Processing-program constructs and conventions for their representation《信息处理-程序构造与表示法的约定》。
国家标准
行业标准: IEEE（Institute Electrical and Electronic Engineers）美国电气与电子工程师学会。例如ANSI/IEEE Str 828-1983(软件配置管理计划标准）。
企业规范: 国内某企业软件开发规范
项目规范
国家标准： GB/T8567-1988
《GB/T8567-1988计算机软件产品开发文件编制指南》建议：在一项计算机软件的开发过程中，一般地说，应该产生14种文件。这些文件是：
可行性研究报告
项目开发计划
软件需求说明书
数据要求说明
概要设计说明书
详细设计说明书
数据库设计说明书
用户手册
操作手册
模块开发卷宗
测试计划
测试分析报告
开发进度月报
项目开发总结报告
软件质量国家标准
软件工程研究的主要内容
规范和标准
方法和技术
工具和环境
过程与管理
方法和技术
软件方法
软件方法体现了软件开发人员看待系统的立场和观点，它确定开发的各个阶段，规定每个阶段的活动、产品、实施步骤和完成准则。
软件方法与技术的例子
（1）面向数据流的方法
（2）面向数据结构的方法
（3）面向功能的方法
（4）面向对象的方法
（5）形式化方法
软件工程研究的主要内容
规范和标准
方法和技术
工具和环境
过程与管理
工具和环境
软件工具
软件工具可以帮助软件项目开发过程中某些阶段或某个环节实现软件过程自动化，从而提高软件的劳动生产率和质量、缩短软件开发周期、降低软件生产成本。有时，人们称其为“帮助开发软件的软件”。
按其功能大致可分为：
需求分析工具 设计工具
实现工具 测试工具
维护工具 项目管理工具
配置管理工具等。
（1）需求分析工具
用以辅助系统分析员生成完整、正确、一致的需求说明，改善软件开发人员之间的通信状况。
例如，具有代表性的有1977年美国密执安大学研制的ISDOS（Information System Design and Optimization System）中用于需求分析的工具PSL/PSA（Problem Statement Language/Problem Statement Analyzer）。
又如，美国TRW公司研制的SREM （Software Requirements Engineering Methodology)中的RSL/REVS（Requirements Statement Language/Requirements Engineering and Validation System）。
又如，Sybase公司生产的S-Designor ProcessAnlyst可以辅助分析人员利用面向数据流的方法如Gane & Sarson、Yourdon/DeMarco、SSADM (Structured System Analysis and Design Methodology) 、 以及OMT（一种object-oriented method）中的functional model。它可以生成RTF格式的文档。
（2）设计工具
用来进行系统设计，数据设计，接口设计，形成设计规格说明，检查并排除规格说明中的错误。
如美国Hughes飞机公司80年代初开发的AIDES（Automated Interactive Design and Evaluation System）系统，它可以辅助设计人员用结构化设计方法以交互方式对软件系统作模块分解，从而得到系统的结构图及相应的设计文档和报告，并可对设计质量作定量分析和评价。
又如，日立公司80年代开发了一个试验性系统SDL/PAD（Software Design Language/Problem Analysis Diagram），该系统接受用结构化分析方法确定的模块说明书（即详细设计文档——模块内部执行过程的描述），输出则可以是用PAD描述的全套详细设计文档以及从PAD自动产生用高级语言编写的源程序。
又如，Sybase公司生产的S-Designor的 DataArchitect ，它可以在Windows操作系统支持下，与分析、设计人员交互生成概念数据模型（CDM），从而可以自动生成依赖于某种关系库（如Oracle、Sybase、MS SQLServer等）的物理模型（PDM），由此可生成建立数据库的SQL（Structured Query Language）脚本，同时还可获得相应RTF格式的文档。
（3）编码工具
为程序设计人员提供各种方便的编程环境，包括编辑、编译、链接、调试和运行等。这类工具可以从辅助程度分为2类：
第一类工具的主要功能是接受设计阶段产生的文档，自动生成特定计算机语言编制的程序，属于这类工具的有各种应用程序生成器。
第二类工具不能完全自动产生代码，但提供了包括编辑、编译、链接、调试和运行等集成开发环境。
如美国的Cornell大学的Program Synthesizer即程序综合器，它是建立在Unix上的一个交互式编辑环境，它能辅助程序员以结构树的形式进行程序的建立、编辑、执行和排错等多种活动。
另外一个非常有用的工具是Unix中的YACC（Yet Another Compiler Compiler）它可接受一个语法说明，然后可以生成一个语法分析子程的C源代码。编译这个语法分析子程，然后和一个调用它以便对输入进行语法分析的程序组合在一起。
用于编码的工具还有Turbo C、VB、Delphi、PowerBuilder、JBuilder、Winsql、Develop2000等。
（4）测试工具
支持整个测试流程，包括选择测试用例、生成测试程序、执行测试、评价测试结果等。
测试工具更广义的说法是确认工具。所谓“确认”就是确定程序编码执行和需求说明之间的符合程度，这就包括了各种分析、测试、验证、证明以及排错工作。三大类工具:
静态分析工具（Static Analysis Tools）
动态分析工具（Dynamic Analysis Tools）
测试支持工具（Test Supporting Tools）
静态分析工具
是对需求说明和设计文档以及程序的结构方面等作出检查和评审。代表工具有微软的FxCop，它分析代码程序集并报告其中与阐述的编程和设计规则相冲突的地方, C++代码静态分析工具Prefast .
动态分析工具
主要思想是使程序有控制地执行，并从多种角度观察程序运行时的行为，如跟踪、调试、仿真、符号执行、断言检查以及约束评价等工具均属此类。代表工具包括Junit（白盒测试），Abbot（测试Java GUIs），DBMonster（数据库压力测试） MockEJB（测试EJB），LoadRunner（性能测试）
（5）维护工具
维护工具主要用来辅助维护人员对代码及有关文档进行各种维护活动，如协助开发人员控制代码的改变、协调对软件的更新、帮助理解源程序等。
版本控制程序-用来存储、更新、恢复和管理一个软件的多个版本；
文档分析工具-用来对开发过程中形成的文档资料进行分析，给出维护活动所需的维护信息；
逆向工程工具-辅助软件人员将某种形式表示的软件转换成更高抽象形式表示的软件；
再工程工具-支持软件重构，提高软件的功能、性能及其可维护性。
例如，ERWin、S-Designor等工具提供了可以从指定SQL脚本或可连接的应用数据库反向生成关系模型以及概念模型的功能，这有助于理解和修改软件系统。
Rational Rose也提供了反向从Java/C＋＋源码生成类图的功能
（6）项目管理与支持工具
项目管理工具-辅助管理人员进行项目的计划、成本估算、资源分配、质量控制等管理活动；
配置管理工具-完成软件配置的标识、版本控制、变化控制等基本任务；
软件评价工具-辅助管理人员进行质量保证的有关活动。
配置管理工具
源代码控制系统SCCS
版本控制系统RCS (Revision Code System）
面向过程的配置管理系统
CCC/HARVEST(Configuration&Change Control,CA)
基于构件复用的配置管理系统JBCM(北大软件研究所）
并发版本系统CVS(Concurrent Versions System,自由）
可视化源控制系统VSS(Visual SourceSafe,Microsoft)
基于文件访问透明的统一变更管理系统Rational Clear Case等
项目管理工具
Symantec公司的TIMELINE
Microsoft公司的Project Manager
Primavera公司的P3
Softstar Systems公司的Costar等
软件评价工具
嵌入式软件测试工具LOGISCOPE
黑盒测试工具QACenter 等
（7）计算机辅助软件工程CASE
（1）计算机辅助软件工程CASE
（Computer-Aided Software Engineering）
CASE技术是系统开发工具与方法的结合，它的目标是为系统开发人员提供一组优化的、集成的且能大量节省人力的系统开发工具，它着眼于系统分析和设计以及程序实现和维护等各个环节的自动化，并使之成为一个整体。
开发方法
自动化工具
CASE =
+
CASE工具
环境体系结构
硬件平台
操作系统
可移植服务
集成框架
CASE系统结构
平台集成：工具运行在相同的硬件/操作系统平台上。
数据集成：工具使用共享数据结构，工具之间可以交换数据。数据集成的方式有：
共享文件：所有工具识别一个单一的文件格式。
例如字符流文件。
共享文件
工具1
工具2
转换过滤器
CASE的五级集成机制
表示集成（用户界面集成）：指系统中的工具使用
共同的风格或采用共同的用户交互标准。
控制集成：支持环境中的一个工具对另一工具的访问。
包括：启动、停止以及调用另一工具提供的服务。
消 息 服 务 器
工具1
工具2
工具3
控制接口
控制接口
控制接口
通过消息传递的控制集成
过程集成：意指CASE系统嵌入了关于过程活动、
约束以及支持这些活动所需的工具等。 CASE
系统可以辅助用户调用相应工具完成有关活动
过程模型
活 动
CASE工具
结 果
用户
过程翻译机
提议
调用
CASE的例子
20世纪80年代具有影响力的例子是Ada程序设计支持环境APSE（the Ada Programming Support Environment）
装入
程序
MAPSE
其它工具
编
译
器
调
试
器
连接程序
配置
管理
KAPSE
APSE
我国研制的集成化软件工程开发环境青鸟系统
日立公司的 SEWB3（Software Engineering WorkBench3）
支持UML的Rational Rose（可与Rational Clear Case集成）
JBCASE For Windows体系结构
用 户 界 面
系统平台(PWIN,中文之星,四通利方等)
结构化分析
工具 SAT
结构化设计
工具 SDT
文档追踪
工具DATT
数据库设计
工具 DDT
需求文档
一般设计
文 档
详细设计
文 档
数据库
文 档
其它文档
文档出版工具DPT
外部工具集成
界面工具
编程工具
调试工具
........
Client
其它
厂家
工具
Word
Execl
Powerpoint
........
Server
工作
站版
青鸟
环境
OLE或
文件
(开放性)
软件工程研究的主要内容
规范和标准
方法和技术
工具和环境
过程与管理
过程与管理
过程
过程是为了达到给定目标所实施的一系列步骤。
软件过程
软件工程过程规定了在获取、供应、开发、运行和维护软件时需要实施的过程、活动和任务。
软件过程定义由 谁 在 什么时候 做 什么事情，并且 如何 去达到一定的目标
软件过程：活动的一个集合；
活动：任务的一个集合；
任务：将一个输入转换为一个输出的操作
ISO12207将所有过程分为3大过程周期
基本过程——对应于工程开发；
支持过程——对应于工程支持；
组织过程——对应于工程管理。
基本过程
获取过程
供应过程
开发过程
运行过程
维护过程
支持过程
文档编制过程
配置管理过程
质量保证过程
验证过程
确认过程
联合评审过程
审核过程
问题解决过程
组织过程
管理过程
基础设施过程
改进过程
培训过程
软件过程
例如：开发过程是软件开发者所从事的一系列活动。它包括13个子过程：
过程的实施准备 系统需求分析系统结构设计
软件需求分析 软件体系结构设计 软件详细设计
软件编码 单元测试 软件集成
软件合格性测试 系统集成测试 系统验收测试
软件安装 软件验收支持
单元测试过程：
软件（开发）过程模型
软件开发模型的基本概念
软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
软件开发模型也常称为：
软件过程模型
软件生存周期模型
软件工程范型
瀑布模型
瀑布模型
瀑布模型规定了软件过程的6项活动：制定计划、需求分析、软件设计、编码、软件测试、运行与维护。
规定了这些活动按自上而下、相互衔接的固定顺序进行，如同瀑布，逐级下落。
软件开发的实践表明，上述各项活动之间并非完全是自上而下、呈线性形式。
实际情况是，每项开发活动均处于一个质量环（输入-处理-输出-评审）中。
只有当本项工作得到确认，才能继续进行下一项活动；否则返工。
瀑布模型
瀑布模型的特点
强调阶段间的顺序性和依赖性。
逻辑设计和物理实现划分清楚,推迟物理实现。
重视质量保证，每个阶段均需要进行审查。
瀑布模型的缺点
不能解决项目开始阶段需求不明确或不正确的问题 ；
阶段和阶段划分完全固定，阶段间产生大量的文档，极大地增加了工作量；
软件与用户见面的时间间隔较长，也增加了一定的风险；
这些问题对软件开发会带来严重影响，最终可能导致开发出的软件并不是用户真正需要的软件。
原型化模型
原型化模型的主要思想
首先快速建立一个能够反映用户主要需求的原型，以便用户判断哪些功能是符合需要的，哪些方面还需要改进。然后将原型反复改进，最终建立完全符合用户要求的新系统。
原型的建立实际上是用户和开发者弄清用户需求的一种机制。
原型化模型图
快速设计
需求的采集和细化
建造原型
客户评价原型
对原型
加工
产生样品
开始
停止
原型化模型的类型
抛弃型：完全弄清楚用户的需求-抛弃原型-设计开发
增量型：每个增量通过详细设计、实现、测试，提交给用户一个可运行的部分。
螺旋模型
螺旋模型
将“原型模型”的迭代特征与“瀑布模型”中的控制和系统化方法结合起来，并增加了风险分析。
软件风险：是普遍存在于软件开发项目中的实际问题。项目规模越大，问题越复杂，资源、成本、进度等因素的不确定性越大，承担项目所冒的风险也越大。
螺旋模型被划分为若干任务区域。
(1) 制定计划：确定目标，选择方案，设定约束条件；
(2) 风险分析：评估方案，分析该策略可能存在的风险；
(3) 实施工程：实现本螺旋周期的目标；
(4) 评估：评价前一步的结果，并且计划下一轮的工作。
快速应用开发模型(RAD)
快速应用开发（RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。
RAD模型是线性顺序模型的一个“高速”变种，通过使用构件的建造方法赢得了快速开发。
RAD过程强调的是复用，复用已有的或开发可复用的构件。
业务建模
确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以辅之以数据流图。
二. 数据建模
为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可辅之以E-R图。
三. 过程建模
创建过程描述以增加、修改、删除或检索一个数据对象。
四. 应用生成
利用第4代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成以构造出整个的应用系统。
五. 测试
RAD模型的阶段
RAD（快速应用开发）模型图
业务建模
60-90天
过程建模
测试
数据建模
应用生成
过程建模
测试
数据建模
应用生成
业务建模
业务建模
数据建模
过程建模
应用生成
测试
小组2
小组1
小组3
RAD模型的缺点
RAD模型对模块化要求比较高，如果哪一个功能不能被模块化，那么建造RAD所需要的构件就会有问题。
RAD不适合技术风险很高的情况。
对于大型软件项目，需要足够的人力资源以建立足够的项目小组。
敏捷方法与XP
敏捷开发背景 2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发FDD，自适应软件开发(Adaptive Software Development，简称ASD)，以及极限编程(eXtreme Programming,简称XP)。
极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。
XP简介
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；
通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
什么情况下用XP
如果从一开始你并不是很完全的知道客户要的系统是怎么样的，这个时候应用XP 可以取得别的方法不可能取得的成功。
假如你的客户在特定的时间内，需要一个对你的项目组来说，比较难开发的系统，那么采用XP 将可以减少风险，增加成功的可能。
XP方法是为小团体开发建立的，在2-10 个人之间。
XP最适合开发小型或中等规模的业务系统，对非常复杂或开发要求极高的系统则不合适。
XP经验
增量式计划
频繁的小版本发布
简单设计
测试优先的开发
重构
结对编程
集体所有代码
连续集成
在场客户
编码标准
测试优先的开发
工匠一：先拉上一根水平线，砌每一块砖时，都与这根水平线进行比较，使得每一块砖都保持水平。
工匠二：先将一排砖都砌完，然后拉上一根水平线，看看哪些砖有问题，再进行调整。
重构
重构是在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。
本质上说，重构就是“在代码写好之后改进它的设计”
XP开发模型
为当前版本选择用户脚本
分解为任务
版本计划
评估系统
发布
开发/集成/测试
一个简单例子-文档下载
编写脚本
一个简单例子-文档下载
任务分解
一个简单例子-文档下载
测试用例设计
本讲结束，谢谢！
