软件生命周期选择指南

1、软件生命周期选择指南目的本指南的制定是为了在项目研发过程中，可以有一种完整统一的措施来分析项目需求，预先辨认项目特性，并提供可供项目选择的软件生命周期模型，使其可以和组织原则软件过程结合在一起使用。合用范畴软件生命周期是指从软件产品开始到软件停止使用为止的时间间隔。对生命周期细分阶段进行管理称为周期模型，典型的几种生命周期模型涉及瀑布模型、增量模型、螺旋模型和迅速原型模型、迭代模型。项目组应在软件项目筹划阶段，认真考虑项目的特性和目的，在此基本上参照原有模型，或为项目开发新设计出一种软件生命周期模型。无论选择何种模型，都要涉及下列一般软件工程过程必须涉及的内容：项目启动项目筹划需求分析软件设计

2、编码测试交付与验收运营维护项目停止使用责任项目经理1）迅速归纳软件项目研发需求2）总结类似项目的开发经验3）提出项目开发参照模型4）与项目构成员一起讨论裁剪模型项目成员总结类似项目的开发经验与其她项目成员一起裁剪模型规定启动准则项目筹划开始制定。输入初始顾客需求及初始项目筹划。重要环节软件生命周期模型一般都是在原有的模型基本上根据客户的需求变更和最后的目的实现判断项目特性进行裁剪产生的，重要经历四个环节：需求分析、原型参照、裁剪定义和模型实行。需求分析 从软件概念第一次被提出，并且明确了实现目的，就进入项目概念阶段，这个时候项目组开始组建，同步收集需求，项目经理应积极配合业务代表参与需求研讨和

3、项目的筹划，安排有经验的人员进入项目组，迅速对需求进行初步分析，概括项目的特性。 此部分的需求分析还应当涉及对历史项目的回忆，总结成功实行经验和吸取失败教训，并归档备案作为组织的过程资产库。原型参照 当项目最后实现目的拟定，同步辨认出项目特性，从组织批准使用的软件生命周期模型中挑选出一种以供参照，该周期原型必须在很大限度上适合项目的具体特性以及可以结合组织原则软件过程一起使用。 项目一开始，周期模型仅作参照，下一步还必须结合实际的越来越丰富的需求进行裁剪以达到新模型的指引目的。新裁剪出的模型可以归档成为下一种类似项目的原始参照模型。 原型的描述重要涉及软件生命周期模型的原理、优缺陷、阶段定义和

4、选用规则。裁剪定义 裁剪基于项目特性 项目特性是裁剪工作的出发点，涉及项目规模（如大、中、小等）、项目类型（如新开发、维护等），以及技术难度、产品类型、项目周期等要素。明确可裁剪的对象可裁剪对象拟定了裁剪的范畴，不仅仅限于过程元素和活动，还涉及参照原则、措施和工具、输出产品及模板等。拟定裁剪所考虑的要素裁剪要素界定了裁剪的方向和尺度。例如，对于某个裁剪对象，其范畴与频度都是裁剪要素。对于有开发经验的小项目，可以合适减少对于技术方面的评审的频度。裁剪的决定要基于风险进行考虑基于风险可检查裁剪的合适性。对过程或活动的调节或放弃，需要通过度析其所带来的风险和影响再做决定。模型实行 裁剪后的周期模型，

5、是个具有项目特性的组织原则软件过程，该过程涉及软件生命周期模型的原理、优缺陷等描述，可以协助软件开发人员更好地理解和运用组织已批准的软件生命周期进行项目开发。 新模型对于项目开发具有指引意义，必须将该模型下达告知到项目组所有成员，项目经理必须监督保证模型的推广，实现“项目可控，质量可靠”的最后目的。模型选择建议在前期需求明确的状况下尽量采用瀑布模型或改善型的瀑布模型。在顾客无信息系统使用经验，需求分析人员技能局限性状况下一定要借助原型。在不拟定性因素诸多，诸多东西前面无法筹划状况下，尽量采用增量迭代和螺旋模型。在需求不稳定状况下尽量采用增量、迭代模型。在资金和成本无法一次到位状况下可以采用增量

6、模型，软件产品分多种版本进行发布。对于完全多种独立功能开发可以在需求阶段就分功能并行，但每个功能内都应当遵循瀑布模型。对于全新系统的开发必须在总体设计完毕后再开始增量或并行。对于编码人员经验较少状况下，建议不要采用敏捷或迭代等生命周期模型。增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口准则。输出具有项目特性的软件生命周期模型。结束准则项目生命周期模型已拟定。度量本指南暂无度量规定。剪裁本指南不容许剪裁。定义与缩略语定义无缩略语SLCSoftware Lift Cycle软件生命周期SLCMSoftware Lift Cycle Model软件生命周期模型PMProje

7、ct Manager项目经理SEISoftware Engineering Institute 软件工程学院SLCPSLC-Process软件生命周期流程文档附录附录A软件生命周期模型附录A 软件生命周期模型瀑布模型模型简介概要设计发布测试实现具体设计需求分析维护概要设计发布测试实现具体设计需求分析维护瀑布模型规定了各项软件工程活动是按照自上而下、互相衔接的固定顺序逐渐完毕。其形如瀑布流水，逐级而下，其状持续不断，直到项目后期才干开图 瀑布模型发出软件产品。瀑布模型为软件开发和软件维护提供了一种有效的管理图示。根据这一图示制定开发筹划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手

8、段有效地对整个开发过程进行指引，从而保证软件产品及时交付，并达到预期的质量规定。优缺陷瀑布模型强调开发的阶段性，强调初期筹划和需求调查，强调产品的测试和验收。对于软件外包这样强调阶段性检查的项目具有很大的合用性。但模型突出的缺陷是缺少灵活性，依赖于初期进行的需求调查，特别是无法解决软件需求不明确或不精确的问题，这种状况往往需要进行返工或者在维护中纠正需求的偏差，极大的增长了风险成本，并由于是单向流动，开发过程中的阶段经验教训很难反馈在项目同阶段的实行过程中。阶段定义阶段进入原则任务退出原则需求分析分派到软件的系统需求已拟定；项目筹划已批准 进行软件需求分析软件需求分析完毕并形成基线。概要设计软

9、件需求规格阐明书已经完毕并通过评审进行数据库设计、各模块的概要设计、集成测试用例编写数据库设计、概要设计、集成测试用例编写完毕并形成基线。具体设计数据库设计、概要设计、集成测试用例编写完毕并形成基线。进行具体设计及单元测试用例编写。具体设计及单体测试用例编写完毕并形成基线。实现具体设计及单体测试用例编写完毕进行编码及单元测试编码及单体测试完毕并形成基线。测试编码完毕进行集成、系统测试集成、系统测试报告发布测试已经完毕顾客手册、在线协助等文档编写，安装程序制作顾客手册、在线协助等文档编写完毕并形成基线，安装程序制作完毕选用规则当项目的需求明确、理解充足、并且较为稳定期，适合选择瀑布模型，绝大部分

10、的原则软件过程都可以应用瀑布模型。增量模型模型简介增量模型是瀑布模型的一种变化模型。这种方式是一方面建立概要设计，然后设计的实现是通过一系列小的、互相交错的子项目，每个子项目完毕一种独特的功能。第一种增量往往是核心的产品，即实现了基本的规定，但诸多补充的特性还没有开发。核心产品交顾客使用的成果是下一种增量的开发筹划。该筹划涉及对核心产品的修改，也涉及新增的特点和功能。这个过程在每个增量发布后不断反复，直到产生最后的完善产品。增量1具体设计编码单元测试系统集成测试交付增量2具体设计增量3具体设计编码单元测试系统集成测试系统集成测试编码单元测试软件系统测试概要设计分析需求增量1具体设计编码单元测试

11、系统集成测试交付增量2具体设计增量3具体设计编码单元测试系统集成测试系统集成测试编码单元测试软件系统测试概要设计分析需求图 增量模型优缺陷增量模型强调开发的分散性，项目需求可以分批获取，任意一种子项目的需求一经拟定就可进入设计和编码阶段，最后提交验证测试，可以及早地从测试过程中发现实现过程中存在的问题，并将经验教训反馈在项目的下一种循环过程。由于在项目初期就能获得项目监控数据，有助于辨认和分析风险，并可对后期开发做出的确的项目估算，增长项目的成功率。同样模型也是存在明显的缺陷的。开发的分散，削弱了需求设计的完整性，重要问题反映在项目的系统集成阶段，影响了系统性能和产品的可维护性，同步也增长版本

12、控制等不安定的因素。阶段定义阶段进入原则任务退出原则增量1项目筹划已批准并进行了总体的需求分析及概要设计进行第一阶段的具体设计、编码、测试及发布。第一阶段产品完毕并形成基线增量2增量1产品已经完毕并完善了本阶段的需求分析及概要设计进行第二阶段的具体设计、编码、测试及发布。第二阶段产品完毕并形成基线增量3增量2产品已经完毕并完善了本阶段的需求分析及概要设计进行第三阶段的具体设计、编码、测试及发布第三阶段产品完毕并形成基线各阶段中涉及的具体阶段请参照瀑布模型。选用规则当项目可清晰地划分为多种功能独立的子项目，或采用阶段开发时，适合选择增量模型。螺旋模型模型简介螺旋模型也是瀑布模型的一种变化模型，其

13、中的每个回旋代表一种特定开发阶段。每个特定开发阶段都结合了风险分析和瀑布原型，这也是与瀑布模型的区别之处。制定筹划制定筹划风险分析客户评估工程实行图 螺旋模型螺旋模型沿着螺线旋转，如图所示，在笛卡尔坐标的四个象限上分别体现了四个方面的活动，即：制定筹划：拟定软件目的，选定实行方案，弄清项目开发的限制条件风险分析：分析所选方案，考虑如何辨认和消除风险实行工程：实行软件开发客户评估：评价开发工作，提出修正建议螺旋模型在每一种开发阶段之前，都引入非常严格的风险辨认、风险分析和风险控制，直到采用了消除风险的措施之后，才开始筹划该阶段的开发工作，而每次回旋都开发出更为完善的一种新的软件版本。例如：在第一

14、圈，拟定了初步的目的、方案和限制条件后，转入右上相限，对风险进行辨认和分析。如果风险分析表白，需求有不拟定性，那么在右下的实行工程相限内，所建的原型会协助开发人员和客户，考虑其他开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。在此基本上需再次筹划，并进行风险分析。每浮现一种新的版本都越来越符合客户需求，逐渐消除或减少风险的损害。在每一圈螺线上，做出风险分析的终点与否继续下去的判断。如果风险过大，开发者和顾客无法承受，项目有也许终结。多数状况下沿螺线的活动会继续下去，自内向外，逐渐延伸，最后得到所盼望的系统。优缺陷螺旋模型强调风险管理，强调对项目的各个阶段审查，提供机会

15、讨论项目与否有价值继续进展下去，可以及早地发现和终结亏损项目。由于引入严格的风险管理，这对项目管理水平提出更高的规定，需要更多的人员、资金和时间的投入，增长了项目成本。阶段定义阶段进入原则任务退出原则原型1项目筹划已批准进行原型1制作原型1提交并形成基线原型2原型1形成基线进行原型2制作原型2提交并形成基线原型3原型2形成基线进行原型3制作原型3提交并形成基线各阶段中涉及的具体阶段请参照瀑布模型。选用规则对于大规模、复杂而需求理解不充足、风险较大、产品规定质量高且对开发周期没有严格规定的项目适合选择螺旋模型。迅速原型模型模型简介迅速原型模型不同于老式的瀑布模型，其核心是套用原型，迅速开发。由于

16、客户对需求的不明朗，无法在初期就能对需求进行明确分析和相应的风险管理，将在设计阶段不断返工，导致项目成本增大，而迅速原型模型可以较好地解决这个问题。在获得一组基本需求阐明后，通过迅速分析构造出一种小型的软件系统，满足顾客的基本规定，使得客户可在试用原型系统的过程中得到亲身感受和受到启发，做出反映和评价，然后开发者根据顾客的意见对原型加以改善。随着不断实验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐渐减少分析和通信中的误解，弥补局限性之处，进一步拟定多种需求细节，适应需求的变更，从而提高了最后产品的质量。原型评估迅速分析或修改构造运营原型评估迅速分析或修改构造运营图 迅速原型模型

17、迅速原型模式类似于增量模式和螺旋模型的结合，只是，由于强调快，因此在功能和性能上有所取舍，同步不强调阶段审查和风险管理。需要注意的是构造原型的目的是反映最后系统的重要特性，因此，我们必须明确规定对原型进行考核和评价的内容，如界面形式、系统构造、功能或模拟性能等。优缺陷迅速原型模型强调迅速分析，鼓励与客户互动，可以掌握客户第一手需求资料，并通过与客户的交流使开发者学习到应用范畴的专业知识，可以更好地协助开发者理解和设计最后系统。该模型强调快的同步一般忽视了性能规定，因此一般原型版本并不是最后版本，最后版本都是在原型基本上重新设计开发的，无形中增长了项目成本，同步要精确地构造一种原型并不是件容易的

18、事情，规定开发者具有丰富的项目开发经验和相应用范畴具有一定的专业知识，也规定项目经理具有与客户反复沟通的交流能力。客户是对开发原型进行评价得出需求的，因此，需求存在多变性，必须加强对需求的管理能力。阶段定义阶段进入原则任务退出原则分析客户提出部分需求对需求进行迅速分析分析得到概要设计构造需求的概要设计已经完毕根据设计开发原型系统系统开发完毕并体现重要特性运营系统开发完毕发布系统提交客户评估新的原型系统开发完毕评估系统正常运营与客户沟通进一步明确系统需求需求变更限度达到新一轮的原型构造选用规则对于从项目概念到项目立项周期规定较短但无法提供明确需求、具有演示性质或者试点工程之类的的项目适合选择迅速

19、原型模型。RUP迭代模型模型简介RUP（Rational Unified Process）是 IBM Rational公司提出的一套开发过程模型，它是一种面向对象软件工程的通用业务流程。它描述了一系列有关的软件工程流程，它们具有相似的构造，即相似的流程构架。RUP 为在开发组织中分派任务和职责提供了一种规范措施，其目的是保证在可估计的时间安排和预算内开发出满足最后顾客需求的高品质的软件。RUP具有两个轴，一种轴是时间轴，这是动态的。另一种轴是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个

20、核心工作流程和三个核心支撑工作流程，核心工作流轴涉及：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流涉及：环境工作流、项目管理工作流和配备与变更管理工作流。RUP与增量迭代不完全相似，但是两者往往互相涉及，在一种项目中往往一起使用。图 RUP模型优缺陷RUP 汇集现代软件开发中多方面的最佳经验，并为适应多种项目及组织的需要提供了灵活的形式。作为一种商业模型，它具有非常具体的过程指引和模板，由于该模型通过多次迭代来完毕软件项目开发任务，具有适应变更、及早减少风险、提高软件质量的长处。但是同样由于该模型比较复杂，因此在模型的掌握上需要耗费比较大的成本

21、。特别对项目管理者提出了比较高的规定。阶段定义阶段进入原则任务退出原则先启项目筹划和迭代筹划已制定1 理解需创立的系统，拟定愿景、范畴、边界2 拟定系统的重要功能3 制定至少一种可行的方案4理解与项目有关的成本、时间进度与风险5 拟定遵循的过程和有关工具项目目的通过评审精化先启阶段结束1细化需求2 设计、实现、验证系统架构并建立架构基线3 化解重要风险，更精确的制定进度表和成本估算4 细化开发用例并搭建开发环境系统架构通过评审构建精化阶段结束迭代开发准备交付给顾客的完整产品，涉及设计、实现及测试有关工作具有产品BETA测试条件产品化功能齐全的BETA版本1进行BETA测试2顾客培训3准备产品环

22、境并转换数据库与有关方完毕验收工作选用规则RUP模型是一种高规范度的迭代化措施，所有的文档需要基于UML，对项目成员技能规定较高，如果顾客提出的项目对时间进度规定相对宽松，风险管理规定较高同步又能组建有足够经验的项目团队的状况下可选用RUP措施。敏捷开发模型模型简介敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发措施，是一种迭代和增量（发展）的措施，通过项目涉众以高度协作和自组织的方式执行，运用适量资源以经济有效且及时的方式生产能满足涉众不断变化的需求的高质量软件。在敏捷开发中，软件项目的构建被切提成多种子项目，各个子项目的成果都通过测试，具有集成和可运营的

23、特性。简言之，就是把一种大项目分为多种互相联系，但也可独立运营的小项目，并分别完毕，在此过程中软件始终处在可使用状态。但敏捷开发并不是一种创新，敏捷开发可理解为在原有软件开发措施基本上的整合取其精髓，去其糟粕。因此敏捷开发继承了不少原有措施的优势。敏捷开发措施过程设计的几种原理：1 、交互的面对面的交流是代价最小，最迅速的互换信息的措施；2、 超过实际需要的过程是挥霍的；3 、大的团队需要重量级措施；4 、解决重大问题的项目需要重量级措施强调；5、 增长反馈和交流可以减少中间产品和文档的需求；6、 轻量级措施更强调理解（understanding），自律（discipline）和技能(skil

24、l)，重量级措施更强调文档（documentation），过程（process）和正式（formality）；understanding指整个团队有关项目的所有知识，涉及讨论的过程，documentation只能记录其中的一部分；discipline是指个人积极的完毕工作，process指个人根据指令完毕工作，skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定环节完毕工作。7、 拟定开发中间的瓶径，提高它的效率；对于瓶颈处的工作应当尽量加快，减少反复，（使用更纯熟的人，使用更多的人，使用更好的工具，使瓶颈处的工作的进一步尽量稳定）对于非瓶颈处的工作可以多某些反复，

25、在输入还不拟定的状况下也可以尽早开始。上述原理的几种结论：1、向一种项目增长人员要耗费较大代价，由于原有人员和新加入人员之间的交流要耗费大量时间；2、团队的规模常常是跳跃的，例如：需要6个纯熟的程序员，但是只有4个，于是增长不纯熟的程序员，成果团队的大量时间耗费在培训不纯熟的程序员上面，最后增长到了20个不纯熟的程序员；3、应当侧重于提高团队的技能而不是扩大团队；4、对不同的项目使用不同的过程；5、在合用的条件下，轻量级的措施优于重量级的措施；6、对不同的项目要裁减过程。优缺陷敏捷开发模型对于需求已经明确并且内容较少，技术方面的风险较少的项目，适合采用这种模型。敏捷模型剪裁了过程，并规定过程间

26、迅速跟进，可以浮现边分析、边设计、边编码、边测试的情形，但是这些过程不要相重叠得太多，原则上容许两个阶段的过程同步进行。此模型为规模小，周期短的项目简化了项目跟踪控制，减少了过程支撑部分的时间耗费。敏捷模型注重的是项目各过程的迅速跟进，即前一过程已经基本完毕，等待评审或验证，就可以开始开展下一过程的工作，运用阶段评审或验证的时间迅速跟进，加快了项目推动速度。再一种长处就是可以减少某些把握性比较高评审。缺陷是在项目剪裁掉的过程或者评审，增长了项目的风险，定义小项目才采用这种模型，改正起来比较容易。阶段定义图 敏捷开发模型敏捷软件开发生命周期开始于初始需求和架构设想，以创立初始工作项堆栈并为团队设

27、定技术方向。团队从每个迭代中生成一种可论证的产品，该产品也许对外提供。在此过程中，涉众通过描述，拟定优先级和改善需求积极参与。该产品继续通过开发团队、涉众和独立测试人员的验证。敏捷项目要通过不同的阶段，在各个阶段，团队的重点会发生变化，过程严密性在开始并不重要，在转换期间会变得很重要。选用规则项目的需求明确、理解充足、并且需求内容较少；软件的应用环境是常规的、主流的和成熟的；项目拟采用的技术是成熟的，拟使用的开发工具是为项目组人员所纯熟掌握的；项目组人员有类似的项目经验；项目的风险较少，对风险管理规定不高的；项目投入人员少于10人，并且开发周期在6个月以内的；V模型V模型简介如V模型图中所示，

28、左边下降的是开发过程各阶段，与此相相应的是右边上升的部分，即测试过程的各个阶段。在模型图中的开发阶段一侧，先从定义业务需求和需求分析开始，然后把这些需求不断地转换到概要设计和具体设计中去，最后开发为程序代码。在测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和验收测试。V模型的价值在于它非常明确地标明了测试过程中存在的不同测试层次，模型图将测试层次和软件开发阶段的关系体现得非常清晰，纵向关系体现了验证的对象，横向的相应关系则体现了各类型的测试所确认的对象。这些测试阶段和开发过程期间各阶段的相应关系如下： 单元测试的重要目的是针对编码过程中也许存在的多种错误。 集成测试的重要目的

29、是针对具体设计中也许存在的问题，特别是检查各单元与其他程序部分之间的接口上也许存在的错误。 系统测试的重要针对概要设计，检查了系统作为一种整体与否有效地得到运营。 验收测试一般由业务专家或顾客进行，以确认软件产品能真正符合顾客业务上的需要。 图 V模型此外，项目经理要按不同阶段适时运用人员，恰当掌握用人原则。一般来说，软件项目不同阶段不同层次技术人员的参与状况是不同样的。下图是V模型的软件开发人员参与状况曲线：优缺陷为测试用例的设计提供了更广泛的信息在老式的软件生命周期中，测试阶段的顺序被置于中后期，测试用例的设计就重要根据于前期各阶段的文档，而文档更新的速度远远不及代码变化的速度，文档的信息

30、也有所失真；而V模型就可以克服老式软件生命周期在测试方面的缺陷，在需求分析与设计的同步就可以进行相应层次的测试用例的设计，有效的保证测试的目的和覆盖率，通过团队成员间的及时沟通，充足运用了需求人员，设计人员的力量来指引测试工作，使得测试工作不仅仅是依赖于文档。测试与编码的混合状态如果等到所有的编码完毕再开始单元测试，集中测试发现的成果必将让开发团队措手不及；V模型的措施就是：开发一段，测试一点；发现缺陷，修复缺陷；再开发，再测试。编码和测试是处在一种反复轮换的状态，可以及时有效地解决测试缺陷。阶段的并行性在V模型中，软件分析与设计阶段在逻辑上分别相应于右侧的各个测试阶段。对于严格按照顺序执行的各个测试阶段，容许其灵活的做合适的提前和推后，使得相邻，甚至非相邻的