软件生命周期选择指南.docx
《软件生命周期选择指南.docx》由会员分享，可在线阅读，更多相关《软件生命周期选择指南.docx（25页珍藏版）》请在冰豆网上搜索。
软件生命周期选择指南
软件生命周期选择指南
1.目的
本指南的制定是为了在项目研发过程中，能够有一个完整统一的方法来分析项目需求，预先识别项目特征，并提供可供项目选择的软件生命周期模型，使其可以和组织标准软件过程结合在一起使用。
2.适用范围
软件生命周期是指从软件产品开始到软件停止使用为止的时间间隔。
对生命周期细分阶段进行管理称为周期模型，典型的几种生命周期模型包括瀑布模型、增量模型、螺旋模型和快速原型模型、迭代模型。
项目组应在软件项目计划阶段，认真考虑项目的特征和目标，在此基础上参考原有模型，或为项目开发新设计出一个软件生命周期模型。
无论选择何种模型，都要包括下列一般软件工程过程必须包含的内容：
Ø项目启动
Ø项目计划
Ø需求分析
Ø软件设计
Ø编码
Ø测试
Ø交付与验收
Ø运行维护
Ø项目停止使用
3.责任
1.1项目经理
1）快速归纳软件项目研发需求
2）总结类似项目的开发经验
3）提出项目开发参考模型
4）与项目组成员一起讨论裁剪模型
1.2项目成员
1）总结类似项目的开发经验
2）与其他项目成员一起裁剪模型
4.规定
1.3启动准则
项目计划开始制定。
1.4输入
初始用户需求及初始项目计划。
1.5主要步骤
软件生命周期模型一般都是在原有的模型基础上根据客户的需求变更和最终的目标实现判断项目特征进行裁剪产生的，主要经历四个步骤：
需求分析、原型参考、裁剪定义和模型实施。
1.5.1需求分析
从软件概念第一次被提出，并且明确了实现目标，就进入项目概念阶段，这个时候项目组开始组建，同时收集需求，，项目经理应积极配合业务代表参与需求研讨和项目的策划，安排有经验的人员进入项目组，迅速对需求进行初步分析，概括项目的特征。
此部分的需求分析还应该包括对历史项目的回顾，总结成功实施经验和吸取失败教训，并归档备案作为组织的过程资产库。
1.5.2原型参考
当项目最终实现目标确定，同时识别出项目特征，从组织批准使用的软件生命周期模型中挑选出一个以供参考，该周期原型必须在很大程度上适合项目的具体特征以及能够结合组织标准软件过程一起使用。
项目一开始，周期模型仅作参考，下一步还必须结合实际的越来越丰富的需求进行裁剪以达到新模型的指导目的。
新裁剪出的模型可以归档成为下一个类似项目的原始参考模型。
原型的描述主要包括软件生命周期模型的原理、优缺点、阶段定义和选用规则。
1.5.3裁剪定义
裁剪基于项目特征项目特征是裁剪工作的出发点，包括项目规模（如大、中、小等）、项目类型（如新开发、维护等），以及技术难度、产品类型、项目周期等要素。
✧明确可裁剪的对象
可裁剪对象确定了裁剪的范围，不仅仅限于过程元素和活动，还包括参照标准、方法和工具、输出产品及模板等。
✧确定裁剪所考虑的要素
裁剪要素界定了裁剪的方向和尺度。
例如，对于某个裁剪对象，其范围与频度都是裁剪要素。
对于有开发经验的小项目，可以适当减少对于技术方面的评审的频度。
✧裁剪的决定要基于风险进行考虑
基于风险可检验裁剪的适当性。
对过程或活动的调整或放弃，需要通过分析其所带来的风险和影响再做决定。
1.5.3.1模型实施
裁剪后的周期模型，是个具有项目特征的组织标准软件过程，该过程包含软件生命周期模型的原理、优缺点等描述，能够帮助软件开发人员更好地理解和运用组织已批准的软件生命周期进行项目开发。
新模型对于项目开发具有指导意义，必须将该模型下达通知到项目组所有成员，项目经理必须监督保证模型的推广，实现“项目可控，质量可靠”的最终目标。
1.5.3.2模型选择建议
✧在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型。
✧在用户无信息系统使用经验，需求分析人员技能不足情况下一定要借助原型。
✧在不确定性因素很多，很多东西前面无法计划情况下，尽量采用增量迭代和螺旋模型。
✧在需求不稳定情况下尽量采用增量、迭代模型。
✧在资金和成本无法一次到位情况下可以采用增量模型，软件产品分多个版本进行发布。
✧对于完全多个独立功能开发可以在需求阶段就分功能并行，但每个功能内都应该遵循瀑布模型。
✧对于全新系统的开发必须在总体设计完成后再开始增量或并行。
✧对于编码人员经验较少情况下，建议不要采用敏捷或迭代等生命周期模型。
✧增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口准则。
1.5.4输出
具有项目特征的软件生命周期模型。
1.5.5结束准则
项目生命周期模型已确定。
1.6度量
本指南暂无度量要求。
1.7剪裁
本指南不允许剪裁。
5.定义与缩略语
1.8定义
无
1.9缩略语
SLCSoftwareLiftCycle软件生命周期
SLCMSoftwareLiftCycleModel软件生命周期模型
PMProjectManager项目经理
SEISoftwareEngineeringInstitute软件工程学院
SLCPSLC-Process软件生命周期流程文档
2.附录
✧附录A软件生命周期模型
附录A软件生命周期模型
2.1瀑布模型
2.1.1模型介绍
概要设计
发布
测试
实现
详细设计
需求分析
维护
瀑布模型规定了各项软件工程活动是按照自上而下、相互衔接的固定次序逐步完成。
其形如瀑布流水，逐级而下，其状连续不断，直到项目后期才能开
图瀑布模型
发出软件产品。
瀑布模型为软件开发和软件维护提供了一种有效的管理图示。
根据这一图示制定开发计划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证软件产品及时交付，并达到预期的质量要求。
2.1.2优缺点
瀑布模型强调开发的阶段性，强调早期计划和需求调查，强调产品的测试和验收。
对于软件外包这样强调阶段性检查的项目具有很大的适用性。
但模型突出的缺点是缺乏灵活性，依赖于早期进行的需求调查，特别是无法解决软件需求不明确或不准确的问题，这种情况往往需要进行返工或者在维护中纠正需求的偏差，极大的增加了风险成本，并由于是单向流动，开发过程中的阶段经验教训很难反馈在项目同阶段的实施过程中。
2.1.3阶段定义
阶段
进入标准
任务
退出标准
需求分析
分配到软件的系统需求已确定；
项目计划已批准
进行软件需求分析
软件需求分析完成并形成基线。
概要设计
软件需求规格说明书已经完成并通过评审
进行数据库设计、各模块的概要设计、集成测试用例编写
数据库设计、概要设计、集成测试用例编写完成并形成基线。
详细设计
数据库设计、概要设计、集成测试用例编写完成并形成基线。
进行详细设计及单元测试用例编写。
详细设计及单体测试用例编写完成并形成基线。
实现
详细设计及单体测试用例编写完成
进行编码及单元测试
编码及单体测试完成并形成基线。
测试
编码完成
进行集成、系统测试
集成、系统测试报告
发布
测试已经完成
用户手册、在线帮助等文档编写，安装程序制作
用户手册、在线帮助等文档编写完成并形成基线，安装程序制作完成
2.1.4选用规则
当项目的需求明确、理解充分、并且较为稳定时，适合选择瀑布模型，绝大部分的标准软件过程都可以应用瀑布模型。
2.2增量模型
2.2.1模型介绍
增量模型是瀑布模型的一种变化模型。
这种方式是首先建立概要设计，然后设计的实现是通过一系列小的、相互交错的子项目，每个子项目完成一个独特的功能。
第一个增量往往是核心的产品，即实现了基本的要求，但很多补充的特性还没有开发。
核心产品交用户使用的结果是下一个增量的开发计划。
该计划包括对核心产品的修改，也包括新增的特点和功能。
这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
交付
系统集成测试
编码单元测试
软件系统测试
概要设计
分析
需求
图增量模型
2.2.2优缺点
增量模型强调开发的分散性，项目需求可以分批获取，任意一个子项目的需求一经确定就可进入设计和编码阶段，最后提交验证测试，可以及早地从测试过程中发现实现过程中存在的问题，并将经验教训反馈在项目的下一个循环过程。
因为在项目早期就能获得项目监控数据，有助于识别和分析风险，并可对后期开发做出确实的项目估算，增加项目的成功率。
同样模型也是存在明显的缺点的。
开发的分散，削弱了需求设计的完整性，主要问题反应在项目的系统集成阶段，影响了系统性能和产品的可维护性，同时也增加版本控制等不安定的因素。
2.2.3阶段定义
阶段
进入标准
任务
退出标准
增量1
项目计划已批准并进行了总体的需求分析及概要设计
进行第一阶段的详细设计、编码、测试及发布。
第一阶段产品完成并形成基线
增量2
增量1产品已经完成并完善了本阶段的需求分析及概要设计
进行第二阶段的详细设计、编码、测试及发布。
第二阶段产品完成并形成基线
增量3
增量2产品已经完成并完善了本阶段的需求分析及概要设计
进行第三阶段的详细设计、编码、测试及发布
第三阶段产品完成并形成基线
各阶段中包含的详细阶段请参照瀑布模型。
2.2.4选用规则
当项目可清晰地划分为多个功能独立的子项目，或采用阶段开发时，适合选择增量模型。
2.3螺旋模型
2.3.1模型介绍
螺旋模型也是瀑布模型的一种变化模型，其中的每个回旋代表一个特定开发阶段。
每个特定开发阶段都结合了风险分析和瀑布原型，这也是与瀑布模型的区别之处。
图螺旋模型
螺旋模型沿着螺线旋转，如图所示，在笛卡尔坐标的四个象限上分别表达了四个方面的活动，即：
1）制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件
2）风险分析：
分析所选方案，考虑如何识别和消除风险
3）实施工程：
实施软件开发
4）客户评估：
评价开发工作，提出修正建议
螺旋模型在每一个开发阶段之前，都引入非常严格的风险识别、风险分析和风险控制，直到采取了消除风险的措施之后，才开始计划该阶段的开发工作，而每次回旋都开发出更为完善的一个新的软件版本。
例如：
在第一圈，确定了初步的目标、方案和限制条件后，转入右上相限，对风险进行识别和分析。
如果风险分析表明，需求有不确定性，那么在右下的实施工程相限内，所建的原型会帮助开发人员和客户，考虑其它开发模型，并对需求做进一步修正。
客户对工程成果做出评价之后，给出修正建议。
在此基础上需再次计划，并进行风险分析。
每出现一个新的版本都越来越符合客户需求，逐步消除或减少风险的损害。
在每一圈螺线上，做出风险分析的终点是否继续下去的判断。
假如风险过大，开发者和用户无法承受，项目有可能终止。
多数情况下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。
2.3.2优缺点
螺旋模型强调风险管理，强调对项目的各个阶段审查，提供机会讨论项目是否有价值继续进展下去，可以及早地发现和终止亏损项目。
由于引入严格的风险管理，这对项目管理水平提出更高的要求，需要更多的人员、资金和时间的投入，增加了项目成本。
2.3.3阶段定义
阶段
进入标准
任务
退出标准
原型1
项目计划已批准
进行原型1制作
原型1提交并形成基线
原型2
原型1形成基线
进行原型2制作
原型2提交并形成基线
原型3
原型2形成基线
进行原型3制作
原型3提交并形成基线
各阶段中包含的详细阶段请参照瀑布模型。
2.3.4选用规则
对于大规模、复杂而需求理解不充分、风险较大、产品要求质量高且对开发周期没有严格要求的项目适合选择螺旋模型。
2.4快速原型模型
2.4.1模型介绍
快速原型模型不同于传统的瀑布模型，其核心是套用原型，快速开发。
由于客户对需求的不明朗，无法在早期就能对需求进行明确分析和对应的风险管理，将在设计阶段不断返工，导致项目成本增大，而快速原型模型能够很好地解决这个问题。
在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求，使得客户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。
随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。
图快速原型模型
快速原型模式类似于增量模式和螺旋模型的结合，只是，由于强调快，所以在功能和性能上有所取舍，同时不强调阶段审查和风险管理。
需要注意的是构造原型的目的是反映最终系统的重要特性，因此，我们必须明确规定对原型进行考核和评价的内容，如界面形式、系统结构、功能或模拟性能等。
2.4.2优缺点
快速原型模型强调快速分析，鼓励与客户互动，能够掌握客户第一手需求资料，并通过与客户的交流使开发者学习到应用范围的专业知识，能够更好地帮助开发者理解和设计最终系统。
该模型强调快的同时一般忽略了性能要求，所以通常原型版本并不是最终版本，最终版本都是在原型基础上重新设计开发的，无形中增加了项目成本，同时要准确地构造一个原型并不是件容易的事情，要求开发者具有丰富的项目开发经验和对应用范围具有一定的专业知识，也要求项目经理具备与客户反复沟通的交流能力。
客户是对开发原型进行评价得出需求的，因此，需求存在多变性，必须加强对需求的管理能力。
2.4.3阶段定义
阶段
进入标准
任务
退出标准
分析
客户提出部分需求
对需求进行快速分析
分析得到概要设计
构造
需求的概要设计已经完成
根据设计开发原型系统
系统开发完毕并体现重要特性
运行
系统开发完毕
发布系统提交客户评估
新的原型系统开发完毕
评估
系统正常运行
与客户沟通进一步明确系统需求
需求变更程度达到新一轮的原型构造
2.4.4选用规则
对于从项目概念到项目立项周期要求较短但无法提供明确需求、具备演示性质或者试点工程之类的的项目适合选择快速原型模型。
2.5RUP迭代模型
2.5.1模型介绍
RUP（RationalUnifiedProcess）是IBMRational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。
它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。
RUP为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。
RUP具有两个轴，一个轴是时间轴，这是动态的。
另一个轴是工作流轴，这是静态的。
在时间轴上，RUP划分了四个阶段：
初始阶段、细化阶段、构造阶段和发布阶段。
每个阶段都使用了迭代的概念。
在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：
业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。
核心支撑工作流包括：
环境工作流、项目管理工作流和配置与变更管理工作流。
RUP与增量迭代不完全相同，但是二者往往互相包含，在一个项目中往往一起使用。
图RUP模型
2.5.2优缺点
RUP汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。
作为一个商业模型，它具有非常详细的过程指导和模板，由于该模型通过多次迭代来完成软件项目开发任务，具有适应变更、及早降低风险、提高软件质量的优点。
但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。
尤其对项目管理者提出了比较高的要求。
2.5.3阶段定义
阶段
进入标准
任务
退出标准
先启
项目计划和迭代计划已制定
1了解需创建的系统，确定愿景、范围、边界
2确定系统的主要功能
3制定至少一个可行的方案
4了解与项目有关的成本、时间进度与风险
5确定遵循的过程和相关工具
项目目标通过评审
精化
先启阶段结束
1细化需求
2设计、实现、验证系统架构并建立架构基线
3化解主要风险，更精确的制定进度表和成本估算
4细化开发用例并搭建开发环境
系统架构通过评审
构建
精化阶段结束
迭代开发准备交付给用户的完整产品，包括设计、实现及测试相关工作
具备产品BETA测试条件
产品化
功能齐全的BETA版本
1进行BETA测试
2用户培训
3准备产品环境并转换数据库
与相关方完成验收工作
2.5.4选用规则
RUP模型是一个高规范度的迭代化方法，所有的文档需要基于UML，对项目成员技能要求较高，如果用户提出的项目对时间进度要求相对宽松，风险管理要求较高同时又能组建有足够经验的项目团队的情况下可选用RUP方法。
2.6敏捷开发模型
2.6.1模型介绍
敏捷开发（agiledevelopment）是一种以人为核心、迭代、循序渐进的开发方法，是一种迭代和增量（发展）的方法，通过项目涉众以高度协作和自组织的方式执行，利用适量资源以经济有效且及时的方式生产能满足涉众不断变化的需求的高质量软件。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
但敏捷开发并不是一种创新，敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。
因此敏捷开发继承了不少原有方法的优势。
敏捷开发方法过程设计的几个原理：
1、交互的面对面的交流是代价最小，最迅速的交换信息的方法；
2、超过实际需要的过程是浪费的；
3、大的团队需要重量级方法；
4、处理重大问题的项目需要重量级方法强调；
5、增加反馈和交流可以减少中间产品和文档的需求；
6、轻量级方法更强调理解（understanding），自律（discipline）和技能（skill），重量级方法更强调文档（documentation），过程（process）和正式（formality）；
understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分；discipline是指个人主动的完成工作，process指个人根据指令完成工作，skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作。
7、确定开发中间的瓶径，提高它的效率；
对于瓶颈处的工作应该尽量加快，减少重复，（使用更熟练的人，使用更多的人，使用更好的工具，使瓶颈处的工作的深入尽量稳定）对于非瓶颈处的工作可以多一些重复，在输入还不确定的情况下也可以尽早开始。
上述原理的几个结论：
1、向一个项目增加人员要花费较大代价，因为原有人员和新加入人员之间的交流要花费大量时间；
2、团队的规模经常是跳跃的，例如：
需要6个熟练的程序员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，最后增加到了20个不熟练的程序员；
3、应该侧重于提高团队的技能而不是扩充团队；
4、对不同的项目使用不同的过程；
5、在适用的条件下，轻量级的方法优于重量级的方法；
6、对不同的项目要裁减过程。
2.6.2优缺点
敏捷开发模型对于需求已经明确而且内容较少，技术方面的风险较少的项目，适合采用这种模型。
敏捷模型剪裁了过程，并要求过程间快速跟进，可以出现边分析、边设计、边编码、边测试的情形，但是这些过程不要相重叠得太多，原则上允许两个阶段的过程同时进行。
此模型为规模小，周期短的项目简化了项目跟踪控制，减少了过程支撑部分的时间花费。
敏捷模型注重的是项目各过程的快速跟进，即前一过程已经基本完成，等待评审或验证，就可以开始开展下一过程的工作，利用阶段评审或验证的时间快速跟进，加快了项目推进速度。
再一个优点就是可以减少一些把握性比较高评审。
缺点是在项目剪裁掉的过程或者评审，增加了项目的风险，定义小项目才采取这种模型，改正起来比较容易。
2.6.3阶段定义
图敏捷开发模型
敏捷软件开发生命周期开始于初始需求和架构设想，以创建初始工作项堆栈并为团队设定技术方向。
团队从每个迭代中生成一个可论证的产品，该产品可能对外提供。
在此过程中，涉众通过描述，确定优先级和改进需求积极参与。
该产品继续经过开发团队、涉众和独立测试人员的验证。
敏捷项目要经过不同的阶段，在各个阶段，团队的重点会发生变化，过程严密性在开始并不重要，在转换期间会变得很重要。
2.6.4选用规则
项目的需求明确、理解充分、并且需求内容较少；
软件的应用环境是常规的、主流的和成熟的；
项目拟采用的技术是成熟的，拟使用的开发工具是为项目组人员所熟练掌握的；
项目组人员有类似的项目经验；
项目的风险较少，对风险管理要求不高的；
项目投入人员少于10人，并且开发周期在6个月以内的；
2.7V模型
2.7.1V模型介绍
如V模型图中所示，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。
在模型图中的开发阶段一侧，先从定义业务需求和需求分析开始，然后把这些需求不断地转换到概要设计和详细设计中去，最后开发为程序代码。
在测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和验收测试。
V模型的价值在于它非常明确地标明了测试过程中存在的不同测试层次，模型图将测试层次和软件开发阶段的关系表现得非常清晰，纵向关系体现了验证的对象，横向的对应关系则体现了各类型的测试所确认的对象。
这些测试阶段和开发过程期间各阶段的对应关系如下：
Ø单元测试的主要目的是针对编码过程中可能存在的各种错误。
Ø集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。
Ø系统测试的主要针对概要设计，检查了系统作为一个整体是否有效地得到运行。
Ø验收测试通常由业务专家或用户进行，以确认软件产品能真正符合用户业务上的需要。
图V模型
另外，项目经理要按不同阶段适时运用人员，恰当掌握用人标准。
一般来说，软件项目不同阶段不同层次技术人员的参与情况是不一样的。
下图是V模型的软件开发人员参与情况曲线：
2.7.2优缺点
✧为测试用例的设计提供了更广泛的信息
在传统的软件生命周期中，测试阶段的顺序被置于中后期，测试用例的设计就主要依据于前期各阶段的文档，而文档更新的速度远远不及代码变化的速度，文档的信息也有所失真；而V模型就可以克服传统软件生命周期在测试方面的缺点，在需求分析与设计的同时就可以进行相应层次的测试用例的设计，有效的保证测试的目标和覆盖率，通过团队成员间的及时沟通，充分利用了需求人员，设计人员的力量来指导测试工作，使得测试工作不仅仅是依赖于文档。
✧测试与编码的混合状态
如果等到所有的编码完成再开始单元测试，集中测试发现的结果必将让开发团队措手不及；V模型的方法就是：
开发一段，测试一点；发现缺陷，修复缺陷；再开发，再测试。
编码和测试是处于一种反复轮换的状态，可以及时有效地处理测试缺陷。
✧ 阶段的并行性
在 V模型中，软件分析与设计阶段在逻辑上分别对应于右侧的各个测试阶段。
对于严格按照顺序执行的各个测试阶段，允许其灵活的做适当的提前和推后，使得相邻，甚至非相邻的阶段之间会出现
升级会员 