CMMI生命周期模型选用指南

合集下载

第二章 TC-CMMI生命周期手册

第二章 TC-CMMI生命周期手册

生命周期模型选择
如无合适生命周期模型供选择,则向EPG提 出申请,由EPG指导来定制项目生命周期; 其它阶段在特殊情况下如需要剪裁,则必须 得到QA和EPG的确认。
生命周期模型裁减指南
1、产品的开发复杂度相对较低,可以将概要设计和详细设 计两个阶段合并,输出一份软件设计说明书,其中包含了概 要设计和详细设计的内容。 2、在概要设计和详细设计复杂度不高的情况下,可以输出 一份软件设计说明书,包含架构设计和详细设计的内容。 3、业务成熟度较高,项目规模15人月以上,技术成熟度在 10%~30%左右。开发如果基于比较稳定的架构,那么概要 设计可以省略,但是需要输出详细设计。如果需要采用一个 新的架构,那么需要概要设计说明和详细设计说明。 4、业务成熟度很低、技术成熟度较低,项目规模较小。主 要研究系统实现在技术、业务、市场等方面的可行性分析目 标。系统预研类的项目,在系统预研活动中输出技术方案书 或者可行性分析报告,不经过概要设计和详细设计活动
最后一个里程碑的产品状态就绪意味着产品的交付使用天创软件开发生命周期模型支持过程项目管理配置管理质量保证度量与分析决策分析与决定评审培训管理项目监控风险与问题管理需求管理概要设计编码与单元测客户验收立项需求开发立项需求开发测试验收详细设计集成系统测验收dar计划项目计划生命周期中的每一个活动都是我们实际使用过的 Nhomakorabea总结
软件生命周期是可裁剪的,但必须符合裁剪 指南的规定 任何项目的裁剪都必须征得EPG的同意, 且要EPG经理签字通过才能实施
生命周期中的每一个活动都是我们实际使用 过的。我们平常也就是这么做的。 只不过我们把我们平时司空见惯了的活动进 行了文档化,和制度化。 所以理论都是来自于实践而高于实践。是在 实践的基础上的升华、浓缩与抽象。再用于 指导实践。如此周而复始,良性循环。

生命周期模型的选择

生命周期模型的选择

在CMMI的各种构件中,只有目标是必需的,实践是期望的,子实践是解释说明的。

所以首先要满足模型里每个目标的要求,目标的达成是根据实践的执行情况来判断的,模型里给出的实践是可以替换的。

只要能达成目标,采用什么实践都是可以的。

静态测试是相对于动态测试而言的,静态测试是不动态执行程序代码而寻找程序中可能存在的错误或评估程序的过程。

相对于动态测试而言,静态测试成本更低,效率更高。

因为静态测试可以在软件开发生命周期的早期就发现缺陷和问题,从而减少返工的成本。

对过程改进的一大疑虑是担心丧失灵活性。

反对过程改进的人,总是拿“活学活用”当作挡箭牌,其实这几个字应该有次序的,即先学、后用、再活。

过程改进的目标是寻求制度和灵活的恰当平衡,其中制度乃是灵活之本。

丹明(Deming):“质量由满足需求的能力组成。

”左兰(Juran):“质量就是适于使用。

”克罗斯比(Ceosby):“质量意味着符合基于用户需要而制定出来的要求。

”关于选择生命周期模型的最后的总结1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型4.在需求不稳定情况下尽量采用增量迭代模型5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.。

CMMI5文档之软件生命周期模型描述

CMMI5文档之软件生命周期模型描述

软件生命周期模型描述文档编号:FHI_CMMI_OPD_PRD_SLCM文档信息:软件生命周期模型描述文档名称:软件生命周期模型描述文档类别:CMMI规程密级:内部秘密版本信息:1.2建立日期:2016-1-8创建人:EPG批准人:李庆林批准日期:2016.2.25存放位置:集成公司组织资产库/组织标准过程编辑软件:MicrosoftOffice2003中文版文档修订记录*变化状态:C――U建,A――增加,M――修改,D――删除目录1简介4...1.1目的4...1.2适用范围4...1.3术语表4...2过程概述4...3生命周期模型描述5...3.1V字模型5...3.1.1概述5...3.1.2阶段定义5...3.1.3适用情况6...3.1.4优点7...3.1.5缺点7...3.1.6本企业适合项目类型7..3.2中等简化V字模型7..3.2.1概述7...3.2.2阶段定义8...3.2.3适用情况8...3.2.4优点8...3.2.5缺点9...3.2.6本企业适合项目类型9..本文描述组织级定义的软件生命周期模型,供项目策划时根据项目的具体情况选择或裁剪使用,由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。

但是“所有的模型都是错误,有些模型是有用的”。

模型是对它们所代表的真实世界的简化,这种简化更多的是为了规范管理的需要,它只能够照顾大多数。

如果它不适合你的项目或者有更能真实表达现实世界的模型出现,因为涉及到组织管理方式的变化,任何模型的修改或新模型的加入都需要通过组织的审批。

1简介软件生命周期由制定计划、需求开发、设计、编码、测试、维护等各项活动组成,而如何将这些活动合理、有效地衔接组织起来,就需要在软件项目策划阶段选择合适的软件生命周期模型。

正如每个项目的目的是唯一的,每个项目的软件生命周期模型也将是唯一的,定义软件生命周期是项目计划的一个重要步骤,它将直接影响到WBS及软件开发计划的制定。

CMMI组织标准生命周期

CMMI组织标准生命周期

附录《组织标准生命周期》模板组织标准生命周期(Organizational Standard Life-Cycle)编号: OSSP/PRM-OPD-LC版本: v2.0发布时间: 2008-10-10变更记录(RECORD OF CHANGES)目录1介绍(INTRODUCTION) (5)1.1目的(P URPOSE) (5)2瀑布模型(WATERFALL MODEL) (5)2.1模型描述(D ESCRIPTION OF THE M ODEL) (5)2.2模型分析(T HE ANALYSIS OF M ODEL) (5)2.2.1优点 (5)2.2.2缺点 (6)2.2.3补救措施 (6)3迭代模型(ITERATIVE MODEL) (6)3.1模型描述(D ESCRIPTION OF THE M ODEL) (6)3.2模型分析(T HE ANALYSIS OF M ODEL) (7)3.2.1优点 (7)3.2.2缺点 (7)3.2.3补救措施 (7)4原型法(PROTOTYPING) (7)4.1模型描述(D ESCRIPTION OF THE M ODEL) (7)4.2模型分析(T HE ANALYSIS OF M ODEL) (8)4.1.1优点 (8)4.1.2缺点 (8)4.1.3补救措施 (8)5喷泉模型(FOUNTAIN MODEL) (8)5.1模型描述(D ESCRIPTION OF THE M ODEL) (8)5.2模型分析(T HE ANALYSIS OF M ODEL) (9)5.2.1优点 (9)5.2.2缺点 (9)5.2.3补救措施 (10)6增量模型(INCREMENTAL MODEL) (10)6.1模型描述(D ESCRIPTION OF THE M ODEL) (10)6.2模型分析(T HE ANALYSIS OF M ODEL) (10)6.2.1优点 (10)6.2.2缺点 (10)6.2.3补救措施 (11)7螺旋模型(SPIRAL MODEL) (11)7.1模型描述(D ESCRIPTION OF THE M ODEL) (11)7.2模型分析(T HE ANALYSIS OF M ODEL) (11)7.2.1优点 (12)7.2.2缺点 (12)7.2.3补救措施 (12)8演化模型(INCREMENTAL MODEL) (12)8.1模型描述(D ESCRIPTION OF THE M ODEL) (12)8.2模型分析(T HE ANALYSIS OF M ODEL) (13)8.2.1优点 (13)8.2.2缺点 (13)8.2.3补救措施 (14)9.智能模型(四代技术(4GL)) (14)9.1模型描述(D ESCRIPTION OF THE M ODEL) (14)9.2模型分析(T HE ANALYSIS OF M ODEL) (14)8.2.1优点 (15)2.2.2缺点 (15)2.2.3补救措施 (15)10.混合模型(HYBRID MODEL) (15)1介绍(Introduction)1.1 目的(Purpose)描述适合公司目前现状,可供项目选择的标准生命周期模型。

生命周期模型及选择指南

生命周期模型及选择指南

·生命周期模型及选择指南Version 1.1文档名称:ZD-MMI-Guidelines-生命周期及模型选择指南-V1.1修订历史记录目录1 目的和围 (1)2 生命周期可选模型简介 (1)2.1 瀑布模型 (1)2.1.1 标准瀑布模型 (1)2.1.2 V模型 (3)2.1.3 中等简化V字模型(V4模型) (4)2.1.4 最简化V字模型(V3模型) (6)2.2 原型模型 (8)2.2.1 原型模型的形式 (8)2.2.2 特点 (8)2.2.3 缺点 (9)2.2.4 适用项目 (9)2.2.5 阶段划分 (9)2.3 螺旋模型 (10)2.3.1 特点 (10)2.3.2 适用项目 (11)2.3.3 阶段划分 (11)2.4 增量模型 (11)2.4.1 特点 (11)2.4.2 适用项目 (12)2.4.3 阶段划分 (12)2.5 迭代模型 (12)2.5.1 特点 (14)2.5.2 适用情况 (14)2.5.3 迭代分类 (15)3 生命周期模型选择指南 (16)3.1 生命周期模型选择特性指标 (16)3.1.1 需求清晰性、完整性、稳定性 (16)3.1.2 项目规模 (16)3.1.3 项目类型 (17)3.1.4 技术复杂度 (17)3.1.5 可重用性 (18)3.1.6 重用已有产品 (18)3.2 生命周期模型选择决策参考 (18)3.3 生命周期模型与特性指标对应关系 (19)3.4 生命周期选择 (20)附录:标准项目生命周期图 (21)软件生命周期模型及选择指南1 目的和围本文用以描述中地公司推荐的软件项目生命周期(以下简称LC)模型,并说明如何根据项目特性选择合适的LC模型。

2 生命周期可选模型简介软件生命周期指软件开发全部过程、活动和任务的结构框架。

软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。

2.1 瀑布模型2.1.1 标准瀑布模型.1 特点1、阶段间具有顺序性和依赖性:必须等前一阶段的工作完成之后,才能开始后一阶段的输入。

生命周期模型选用指南

生命周期模型选用指南

生命周期模型选用指南文档编号:文档信息:公司级别指南文档名称:生命周期模型选用指南文档类别:过程管理类密级:内部版本信息:1.0建立日期:2006-9-1创建人:审核者:批准人:批准日期:保管人:存放位置:编辑软件:MicrosoftOffice2003中文版文档修订记录*A——M——D——文档批准信息目录1概述41.1目的41.2适用范围41.3引用文件41.4术语41.5参考资料42软件生命周期模型模型选择指南42.1选择生命周期模型的参考决策树52.2软件生命周期模型描述82.2.1瀑布模型82.2.2原型+瀑布模型82.2.3增量模型92.2.4增量+迭代模型92.2.5快速应用开发模型102.3其它模型采用说明103附录103.1软件过程结构图103.2附录A—相关过程113.3附录B—相关规程123.4附录C—相关指南123.5附录D—相关模板列表12图索引:图1选择模型的参考决策树5图2瀑布模型8图3原型+瀑布模型8图4增量模型9图5增量+迭代模型9图6快速应用开发模型10图7附录图表——软件过程结构图111概述1.1目的本文档描述组织定义的几种软件生命周期模型,供项目策划时根据项目的具体情况选择或裁剪使用,从而确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。

1.2适用范围适用于公司的软件项目策划。

1.3引用文件无。

1.4术语•软件生命周期一从软件设想开始到软件不再使用而结束的时间周期。

软件生命周期一般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段,有时还包括退役阶段。

•软件过程-有关开发和维护软件及其相关产品(例如:项目计划、设计文档、代码、测试用例、用户手册等)的活动、方法、实践和变更的集合。

•RAD—快速软件开发1.5参考资料•《软件工程实践者的研究方法》,RogerS.Pressman著,黄柏素、梅宏等译,机械工业出版社,1999年10月•《实用软件工程》郑人杰、殷人昆、陶永雷著,清华大学出版社,1997年4月•《软件需求》,KarlE.Wiegers著,陆丽娜、王忠民、王志敏等译,机械工业出版社,2000年7月•《统一软件开发过程》,IvarJacobson、GradyBooch、JamesRumbaugh著,周伯生、冯学民、樊东平等译,机械工业出版社,2002年1月2软件生命周期模型模型选择指南所有的项目软件开发过程都应遵循一个生命周期模型,每个模型都具有能够帮助实际软件项目进行控制及协调的特征。

CMMI过程管理OPD软件生命周期模型描述V

CMMI过程管理OPD软件生命周期模型描述V

软件生命周期模型描述文档编号:GZCY_OPD_PRS-V1.0文档信息:文档名称:文档类别:CMMI模板密级:机密版本信息:V1.0建立日期:创建人:审核者:批准人:批准日期:保管人:存放位置:编辑软件:Microsoft Office 2003英文版CONFIDENTIAL文档修订记录文档审批信息前言本文描述组织级定义的软件生命周期模型,供项目策划时根据项目的具体情况选择或裁剪使用,由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。

但是“所有的模型都是错误,有些模型是有用的”。

模型是对它们所代表的真实世界的简化,这种简化更多的是为了规范管理的需要,它只能够照顾大多数。

如果它不适合你的项目或者有更能真实表达现实世界的模型出现,因为涉及到组织管理方式的变化,任何模型的修改或新模型的加入都需要通过组织的审批。

目录第一章简介11.1 目的11.2 适用范围11.3 术语表11.4 参考资料1第二章过程概述2第三章生命周期模型描述33.1 V字模型33.1.1 概述33.1.2 阶段定义43.1.3 适用情况43.1.4 优点53.1.5 缺点53.1.6 本企业适合项目类型53.2 中等简化V字模型53.2.1 概述53.2.2 阶段定义63.2.3 适用情况63.2.4 优点63.2.5 缺点63.2.6 本企业适合项目类型63.3 最简化V字模型73.3.1 概述73.3.2 阶段定义73.3.3 适用情况73.3.4 优点83.3.5 缺点83.3.6 本企业适合项目类型83.4 迭代模型83.4.1 概述83.4.2 阶段定义103.4.3 适用情况103.4.4 优点103.4.5 缺点113.4.6 本企业适合项目类型113.4.7 以需求、计划、设计为重点的迭代模型113.4.8 以计划、设计、编码、测试为重点的迭代模型12 3.5 原型+瀑布模型133.5.1 概述133.5.2 阶段定义143.5.3 适用情况143.5.4 优点143.5.5 缺点153.5.6 本企业适合的项目类型153.6 增量模型153.6.1 概述153.6.2 阶段定义163.6.3 适用情况173.6.4 优点173.6.5 缺点173.6.6 本企业适合的项目类型173.7 增量的迭代过程模型173.7.1 概述173.7.2 阶段定义183.7.3 适用情况193.7.4 优点193.7.5 缺点193.7.6 本企业适合的项目类型19 3.8 快速应用开发模型193.8.1 概述193.8.2 阶段定义203.8.3 适用情况213.8.4 优点213.8.5 缺点213.8.6 本企业适合的项目类型21 3.9 螺旋模型223.9.1 概述223.9.2 阶段定义233.9.3 适用情况233.9.4 优点233.9.5 缺点233.9.6 本企业适合的项目类型23第一章简介软件生命周期由制定计划、需求开发、设计、编码、测试、维护等各项活动组成,而如何将这些活动合理、有效地衔接组织起来,就需要在软件项目策划阶段选择合适的软件生命周期模型。

生命周期模型选择指南

生命周期模型选择指南

生命周期模型选择指南生命周期模型选择指南目录1.目的 (1)2.范围 (1)3.项目生命周期 (1)3.1.瀑布模型 (3)3.1.1.V字模型 (4)3.1.2.中等简化V字模型 (6)3.1.3.最简化V字模型 (7)3.2.原型模型 (9)3.3.螺旋模型 (10)3.4.增量模型 (12)3.5.迭代模型 (13)1.目的1)根据项目类型和实际情况,从公司认可的生命周期模型选择合适的生命周期模型;2)根据所选择的生命周期模型,裁剪和细化标准过程,使裁剪后的过程符合项目的特点和实际情况。

2.范围本文件适用于公司所有类型的项目。

3.项目生命周期生命周期模型是从项目需求定义直至经使用后废弃为止,跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。

生命周期模型一般分为:瀑布模型、原型模型、迭代模型、增量模型。

软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。

目前软件开发实践中使用的各种生命周期模型,都是下面各阶段的不同排列与组合。

∙系统需求∙需求分析∙设计(概要设计和详细设计)∙编码实现∙测试∙使用与维护各阶段主要工作、应完成的文档、质量控制手段见下表。

该生命周期模型适合于所有项目。

一个完整的开发类项目生命周期一般分为:需求分析、设计、编码、测试、发布、实施以及运行维护阶段。

3.1.瀑布模型1)特点●阶段间具有顺序性和依赖性:必须等前一阶段的工作完成之后,才能开始后一阶段的输入。

对本阶段工作进行评审,若得到确认,则继续下阶段工作,否则返回前一阶段,甚至更前阶段。

只有前一阶段输出正确,后一阶段才能正确;●推迟实现的观点:在编码之前,设置了需求分析与设计的各个阶段,分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现;●质量保证的观点是每个阶段都坚持两个做法:规定文档,没有文档就没有完成该段任务;每个阶段结束前都要对完成的文档进行评审,以便尽早发现问题,改正错误。

CMMI软件生命周期模型选用指南

CMMI软件生命周期模型选用指南

编码:生命周期模型选择指南修订历史目录1目的 (1)2适用范围 (1)3模型介绍 (1)3.1瀑布模型 (1)3.1.1模型说明 (1)3.1.2模型分析 (1)3.2迭代模型 (2)3.2.1模型说明 (2)3.2.2模型分析 (2)3.3快速原型模型 ........................................................................ 错误!未定义书签。

3.3.1模型说明.......................................................................... 错误!未定义书签。

3.3.2模型分析.......................................................................... 错误!未定义书签。

3.4精简模型 (3)3.4.1模型说明 (3)3.4.2模型分析 (4)4模型选择 (5)4.1模型选择原则 (5)4.2项目分类 (5)4.3模型选择指南 (6)1目的描述适合公司现状、可供项目选择的组织级生命周期模型。

2适用范围公司所有软件项目。

3模型介绍3.1瀑布模型3.1.1模型说明图1 瀑布模型对于需求比较明确的项目,可以使用瀑布模型进行项目开发,每个阶段的输入都是依靠上一个阶段的输出,每个阶段内都需要完成与最终产品相关的所有工作。

3.1.2模型分析优点:1.可以明确划分项目的各个阶段,便于管理;2.项目成员只需要在被安排的阶段开展项目工作,不需要全程参与;3.阶段工作内容清晰,降低了开发难度。

缺点:1.对项目的启动条件要求较高;2.如果出现需求不明确或设计开发技术瓶颈,将会影响后续阶段的工作启动;3.最终产品提交给用户确认的时间比较晚,存在一定的风险。

3.2迭代模型3.2.1模型说明图2 迭代模型通常有许多项目不能在需求开发阶段提供准确的需求,对于这样的项目,可以选择迭代开发模型,将能够确定的需求分析确定下来。

CMMI-3生命周期选择表

CMMI-3生命周期选择表

瀑布模型 N Y
Y
N
N Y Y
选择的结果是:所有项目特征中“Y”最多的那个
USDP N N Y Y Y Y Y
USDP Y N Y Y Y Y N
USDP Y N Y
USDP N Y Y Y Y
USDP Y Y
Nபைடு நூலகம்
Y
Y N Y
增量模型 N Y N N N Y Y
增量模型 Y N Y Y Y N N
增量模型 Y Y Y
OPD-SP12-2 需求类型 需求容易被定义或熟知? 需求可以在早期被完整定义? 需求经常变更? 需要是通过DEMO来定义功能吗? 需要通过DEMO来验证操作概念?
需求功能复杂? 功能模块之间接口清晰?
责任公司 生命周期选择表
项目是
瀑布模型 Y Y N N N N Y
项目风险 项目是组织中的新方向? 项目过程中有稳定的预算? 项目要求高可靠性? 项目会发生非预期的修改和变化? 项目可以严格按照计划执行? 有可重用部件? 有资源不足问题?
项目是
瀑布模型 N Y N N N N N
项目类型 是系统集成项目? 项目是已有系统的一个升级版? 产品在组织中有一个长的生命周期?
项目是
瀑布模型 N N Y
用户类型 用户代表在项目期间很少参与? 用户代表对定义新系统很陌生? 用户代表是问题领域的专家? 用户希望全程参与项目? 用户希望跟踪项目进度?
项目是
瀑布模型 Y N N N N
团队类型
大部分成员对于问题领域不了解? 大部分成员对于涉及的技术领域不了 解? 大部分成员对于项目中要使用的工具 不了解? 项目组成员在项目过程中会被重新安 排? 需要时,项目组人员会得到有效的培 训?

CMMI文件-(生命周期模型选用指南)

CMMI文件-(生命周期模型选用指南)
3.2.2
优点:
1.项目的启动条件比较灵活、只要用户有基本的立项意向和需求范围就可以开始计划工作;
2.可以在项目早期识别和管理风险;
3.可以较快的展示项目开发的成果,有益于增强客户授信度和满意度。
缺点:
1.迭代过程和范围划分比较复杂,项目的过程管理难度较大;
2.产品的设计开发是迭代过程完成的,容易出现产品构件兼容性问题,如果处理不当会出大量返工的工作。
生命周期模型选用指南
更改控制页
序号
版本号
更改时间
更改内容描述
填写人
1
描述适合公司现状、可供项目选择的组织级生命周期模型。
2
公司所有软件项目。
3
1
3.1.1
图1瀑布模型
对于需求比较明确的项目,可以使用瀑布模型进行项目开发,每个阶段的输入都是依靠上一个阶段的输出,每个阶段内都需要完成与最终产品相关的所有工作。
主要是需求变更风险和进度风险
实现客户需求,维护客户满意度。进行前瞻性技术研究,完成科研成果向应用的转换。锻炼队伍,发现新的项目目标和机会。
管理级别D
10~30
2~3
12~20
主要是需求变更风险和进度风险
实现客户需求,维护客户满意度,锻炼队伍,发现新的项目目标和机会。
管理级别E
<10
<2
<12
主要是需求变更风险和进度风险
按期按质实现项目目标,锻炼队伍、固化管理,协调资源,解决风险问题,积累客户需求,提供确定类型客户需求解决方案
B
50~100
4~10
40~70
主要是需求变更风险和进度风险
按期按质实现项目目标,锻炼队伍、固化管理,协调资源,解决风险问题,积累客户需求,提供确定类型客户需求解决方案。

生命周期模型选用指南

生命周期模型选用指南

生命周期模型选用指南版本1.0发布时间:烟台海颐软件股份有限公文件变更记录1.目的本文档统一规范描述了组织内软件开发过程中可以使用的各种生命周期模型,供项目策划时根据项目的具体情况选用,由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序,从而加强项目管理,提高过程能力成熟度级别,保证产品质量。

2.适用范围机构:产品部、开发部、工程部、质量部。

业务:本指南适用于组织内的全部软件项目。

3.名词术语软件生命周期:软件生命周期,是指从开始策划软件产品到软件不再使用为止这段时间。

典型的软件生命周期包括策划阶段、需求阶段、分析与设计阶段、实现阶段(构造阶段)、测试阶段、实施和维护阶段。

软件生命周期模型软件生命周期模型是对软件工程活动的组织方式。

软件生命周期模型通过确定软件开发活动的顺序和相互制约关系来保证软件工程活动的流程化。

4.软件生命周期模型4.1瀑布模型(Waterfall)4.1.1模型定义该模型首先由Royce[1970]提出,又称线性顺序模型,或典型生命周期模型,指软件生命周期的各项活动始终按照固定顺序执行:需求、设计、构造、集成、测试、维护,各活动之间有明确的界限,非连续的,对阶段结束的成果进行判断以确定是否可以开始下一阶段的工作,形如瀑布流水,最终得到软件产品。

瀑布模型是所有软件生命周期模型的基础。

4.1.2模型图4.1.3模型特点1)优点瀑布模型是一种文档驱动模型,主要的工作产品通过文档从一个阶段传递到下一阶段,瀑布模型的每个活动的完成都是以该活动的评审通过作为标志的。

当项目有着明确的产品定义以及易于理解的技术方案的情况下,瀑布模型有助于及早发现问题,降低阶段成本。

瀑布模型的主要特点:·简单、易于理解·要求严格的管理,包括周密的项目计划、明确的交付物、严格的质量控制手段(如阶段的评审)等·客户在项目的后期才可以见到的产品以及判断产品的质量·强调产品的测试2)缺点:·缺乏灵活性瀑布模型要求在项目的初期明确定义全部需求,然而客户在项目初期很难明确描述所有的需求,这种不确定性难以满足模型要求的“稳定的、明确定义的需求”的要求。

生命周期模型选择指南

生命周期模型选择指南

生命周期模型选择指南修订记录目录1.前言....................................................... 错误!未指定书签。

1.1目的.............................................. 错误!未指定书签。

1.2范围.............................................. 错误!未指定书签。

2.瀑布模型................................................. 错误!未指定书签。

2.1模型描述........................................ 错误!未指定书签。

2.2阶段和任务 .................................... 错误!未指定书签。

2.3选择瀑布模型的原则........................ 错误!未指定书签。

2.4适用项目类型 ................................. 错误!未指定书签。

3.迭代增量模型().................................... 错误!未指定书签。

3.1模型描述........................................ 错误!未指定书签。

3.2阶段和任务 .................................... 错误!未指定书签。

3.3选择迭代增量模型的原则.................. 错误!未指定书签。

3.4适用项目类型 ................................. 错误!未指定书签。

1.前言1.1目的本文作为项目经理在制定项目计划时,根据项目和产品的特点确定采用何种生命周期模型的依据。

1.2范围适用于所有软件开发项目。

生命周期选择的指南

生命周期选择的指南

目录1. 目的 (2)2. 围 (2)3. 职责 (2)4.工作程序 (2)4.1公司定义的软件生存周期模型 (2)4.2软件生存周期模型的选择准则 (2)4.2.1 瀑布模型选择准则 (2)4.2.2增量模型选择准则 (2)4.2.3 快速原型选择准则 (3)4.3软件生存周期模型 (3)4.3.1 瀑布模型 (3)4.3.2 增量模型 (3)4.3.3 快速原型模型 (4)4.4各阶段的任务、活动、工作产品和质量控制 (5)4.4.1 标准型 (5)4.5软件生存周期裁剪指南 (7)4.5.1裁剪指南 (8)5.参考资料 (9)1. 目的指导项目组在制定项目开发计划阶段,选择适合项目特点的生存周期,并能按照软件生存周期定义的工作流程进行工作。

2. 围本过程适用于新开发的软件项目。

3. 职责软件项目经理负责根据项目的特点选择合适的生存周期。

4.工作程序4.1公司定义的软件生存周期模型软件生存周期定义可视软件项目特性识别和所选软件开发模型而异,公司拟推荐采用的软件生存周期模型有1、瀑布模型2、增量模型3、快速原型模型4.2 软件生存周期模型的选择准则定义一个适用的软件生存周期是软件项目策划的基点,也是用以规项目管理的重要手段。

为此,对项目定义软件生存周期时,应首先根据各项目的特性和选择准则从本规中选取一个合用的软件生存周期模型,随后再通过裁剪给出适用于本项目的软件生存周期定义。

4.2.1 瀑布模型选择准则1、用户开始就给出明确的需求,且在开发过程中需求没有或很少变化;2、分析设计人员对应用领域很熟悉;3、低风险项目(对目标、开发环境很熟悉);4、用户应用环境稳定;5、用户除提出需求以外,很少参与开发工作;6、用户接受在项目的开发晚期才能得到程序的运行版本。

4.2.2增量模型选择准则1、用户需求在整个项目开发过程中可能发生变化;2、客户接受分阶段交付;3、分析设计人员对应用领域不熟悉或难以全面把握;4、中等或高风险项目(对工期过紧且可分阶段提交的项目或对系统目标、开发环境不熟悉的项目);5、用户需要参与整个软件开发过程;6、使用面向对象的语言或第四代语言。

生命周期选择的指南

生命周期选择的指南

生命周期选择的指南目录1. 目的 (2)2. 围 (2)3. 职责 (2)4.工作程序 (2)4.1公司定义的软件生存周期模型 (2)4.2软件生存周期模型的选择准则 (2)4.2.1 瀑布模型选择准则 (2)4.2.2增量模型选择准则 (2)4.2.3快速原型选择准则 (3)4.3软件生存周期模型 (3)4.3.1 瀑布模型 (3)4.3.2增量模型 (4)4.3.3快速原型模型 (4)4.4各阶段的任务、活动、工作产品和质量控制 (6)4.4.1 标准型 (6)4.5软件生存周期裁剪指南 (8)4.5.1裁剪指南 (8)5.参考资料 (9)1. 目的指导项目组在制定项目开发计划阶段,选择适合项目特点的生存周期,并能按照软件生存周期定义的工作流程进行工作。

2. 围本过程适用于新开发的软件项目。

3. 职责软件项目经理负责根据项目的特点选择合适的生存周期。

4.工作程序4.1公司定义的软件生存周期模型软件生存周期定义可视软件项目特性识别和所选软件开发模型而异,公司拟推荐采用的软件生存周期模型有1、瀑布模型2、增量模型3、快速原型模型4.2 软件生存周期模型的选择准则定义一个适用的软件生存周期是软件项目策划的基点,也是用以规项目管理的重要手段。

为此,对项目定义软件生存周期时,应首先根据各项目的特性和选择准则从本规中选取一个合用的软件生存周期模型,随后再通过裁剪给出适用于本项目的软件生存周期定义。

4.2.1 瀑布模型选择准则1、用户开始就给出明确的需求,且在开发过程中需求没有或很少变化;2、分析设计人员对应用领域很熟悉;3、低风险项目(对目标、开发环境很熟悉);4、用户应用环境稳定;5、用户除提出需求以外,很少参与开发工作;6、用户接受在项目的开发晚期才能得到程序的运行版本。

4.2.2增量模型选择准则1、用户需求在整个项目开发过程中可能发生变化;2、客户接受分阶段交付;3、分析设计人员对应用领域不熟悉或难以全面把握;4、中等或高风险项目(对工期过紧且可分阶段提交的项目或对系统目标、开发环境不熟悉的项目);5、用户需要参与整个软件开发过程;6、使用面向对象的语言或第四代语言。

在实际开发项目中如何选择软件生存周期模型?

在实际开发项目中如何选择软件生存周期模型?

在实际开发项⽬中如何选择软件⽣存周期模型?如果你要做⼀个项⽬,你更倾向于选择哪⼀个或⼏个软件⽣存周期模型?为什么?付兴乐:所选软件开发模型:增量模型原因:其可以尽早的看到部分软件的功能,发现问题并改正,在⼀定程度上减少了软件开发的风险,并且其第⼀个可交付版本所需的时间很短,如果不满意可以再进⾏改变修正,所以担负的风险很少。

适合于我们进⾏软件开发。

张易⽅:所选软件开发模型:增量模型原因 :1.⾸先我们的项⽬有⼀定的明确需求,但是不是特别完整,这有利于我们之后添加新的需求。

2.其次选择增量模型,我们可以在⽐较短的时间中交付第⼀个版本,减少来开发风险。

3.随着版本的改进,我们能及时发现软件的不⾜,有利于我们对软件进⾏及时更新与修改。

4.有益于开发步骤的清晰,更好体会软件开发的各个阶段所做的⼯作。

曹威龙:所选软件开发模型:增量模型原因:1、短时间内向⽤户提供可完成部分⼯作的产品;2、逐步增加产品功能可以使⽤户有时间了解和适应新产品;3、开放结构的软件拥有的维护性明显好于封闭结构的软件。

⽥⾬林:所选软件开发模型:增量模型原因:1.项⽬周期相对更短。

2.可以先发布部分功能出来起到镇定客户的作⽤。

3.可以根据前⼀版本功能表现,制定后⼀增量计划。

经过讨论以下是我们团队预期使⽤的软件开发模型以及原因:所选软件开发模型:增量模型原因:综合⼩组各个成员的意见,我们最终选择增量模型来作为我们团队预期的软件开发模型。

但在软件开发过程中不能让⼀个死的模型所牢牢控制住,应该根据实际情况灵活运⽤软件开发模型。

在主体选择增量模型的同时,开发过程中也应该借鉴其他模型的优点和长处,这样将会更有利于开发,使得开发更加⾼效,便捷。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

编码:SHZIM-O-OPD-P02 xxxx技术股份有限公司
生命周期模型选用指南
更改控制页
目录
1目的 (1)
2范围 (1)
3模型介绍 (1)
3.1瀑布模型 (1)
3.1.1模型说明 (1)
3.1.2模型分析 (1)
3.2迭代模型 (2)
3.2.1模型说明 (2)
3.2.2模型分析 (3)
3.3快速原型模型 (3)
3.3.1模型说明 (3)
3.3.2模型分析 (4)
3.4精简模型 (4)
3.4.1模型说明 (4)
3.4.2模型分析 (5)
3.5V模型 (6)
3.5.1模型说明 (6)
3.5.2模型分析 (6)
4模型选择 (8)
4.1模型选择原则 (8)
4.2项目分类 (8)
4.3模型选择指南 (9)
1目的
描述适合公司现状、可供项目选择的组织级生命周期模型。

2范围
公司所有软件项目。

3模型介绍
3.1瀑布模型
3.1.1模型说明
图1 瀑布模型
对于需求比较明确的项目,可以使用瀑布模型进行项目开发,每个阶段的输入都是依靠上一个阶段的输出,每个阶段内都需要完成与最终产品相关的所有工作。

3.1.2模型分析
优点:
1.可以明确划分项目的各个阶段,便于管理;
2.项目成员只需要在被安排的阶段开展项目工作,不需要全程参与;
3.阶段工作内容清晰,降低了开发难度。

缺点:
1.对项目的启动条件要求较高;
2.若出现需求不明确或设计开发技术瓶颈,将会影响后续阶段的工作启动;
3.最终产品提交给用户确认的时间比较晚,存在一定的风险。

3.1.3模型参照
参见《瀑布模型》。

3.2迭代模型
3.2.1模型说明
图2 迭代模型
通常有许多项目不能在需求开发阶段提供准确的需求,对于这样的项目,可以选择迭代开发模型,将能够确定的需求分析确定下来。

之后便可以对这部分确定的需求进行系统设计、编码和测试。

整个项目可以进行多次迭代的过程,一般情况下迭代的起点从需求开发开始,然后进行设计、编码和测试,但是有时候也可能出现从设计或编码阶段安排新的迭代过程。

优点:
1.项目的启动条件比较灵活、只要用户有基本的立项意向和需求范围就可以
开始计划工作;
2.可以在项目早期识别和管理风险;
3.可以较快的展现项目开发的成果,有益于增强客户受信度和满意度。

缺点:
1.迭代过程和范围划分比较复杂,项目的过程管理难度较大;
2.产品的设计开发是迭代过程完成的,容易出现产品构件兼容性问题,如果
处理不当会出大量返工的工作。

3.3快速原型模型
3.3.1模型说明
图3 快速原型模型
在很多时候,需求分析人员无法通过与用户交谈就能获得明确的、详细的需求。

这种情况可以选择快速原型开发方法,它的主要目的就是获得与验证需求。

首先由开发人员构造原型,然后让用户试验该原型。

一般地,当用户面对一个可操作的软件时,他比较容易说清楚“需要什么”和“不要什么”。

从而有助于分析人员获取更详细的需求,以及验证需求是否正确。

不断迭代上述过程,直至满足用户的所有需求为止。

优点:
1.可以直观地让用户确定其需求,降低了用户对其提供的需求的不确定性。

缺点:
1.原型开发需要较早投入开发成本,如果原型不能在产品开发过程中进行复
用,将会导致项目成本的增加。

3.3.3模型参照
参见《快速原型模型》。

3.4精简模型
3.4.1模型说明
图4 精简模型1
图5 精简模型2
对于一些规模较小、版本升级、或者是有大量可复用构件的项目,这些项目需求相对比较明确、产品架构比较成熟和稳定,因此可以选择精简生命周期模型。

根据项目的不同情况:可以将设计阶段和编码阶段精简为一个工程阶段(如图4);也可将需求开发阶段和设计阶段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段(如图5)。

3.4.2模型分析
优点:
1.缩短开发周期、降低各阶段工作的衔接工作;
2.可以一定程度降低项目的成本。

缺点:
1.如果精简方式选择不合理,可能会造成产品质量降低。

3.4.3模型参照
参见《精简瀑布模型-1》和《精简瀑布模型-2》。

3.5 V模型
3.5.1模型说明
图6 V模型
V模型是在快速应用开发 (RAD,Rap Application Development)模型基础上演变而来,由于将整个开发过程构造成一个V字形而得名。

V模型强调软件开发的协作和速度,将软件实现和验证有机地结合起来,在保证较高的软件质量情况下缩短开发周期。

对于一些规划较小、版本升级、或者是有大量可复用构件的项目,这些项目需求相对比较明确、产品架构比较成熟和稳定,因此亦可以选择V模型。

(如图6)。

3.5.2模型分析
从水平对应关系看
左边是设计和分析,是软件设计实现的过程,同时伴随着质量保证活动——审核的过程,也就是静态的测试过程;右边是对左边结果的验证,是动态测试的过程,即对设计和分析的结果进行测试,以确认是否满足用户的需求。

如:
·需求分析和功能设计对应验收测试,说明在做需求分析、产品功能设计的同时,测试人员就可以阅读、审查需求分析的结果,从而了解产品的设计特性、用户的真正需求,确定测试目标,可以准备用例(Use Case)并策划测试活动。

·当系统设计人员在做系统设计时,测试人员可以了解系统是如何实现的,基于什么样的平台,这样可以设计系统的测试方案和测试计划,并事先准备系统的测试环境,包括硬件和第三方软件的采购。

因为这些准备工作,实际上是要花去很多时间。

·当设计人员在做在做详细设计时,测试人员可以参与设计,对设计进行评审,找出设计的缺陷,同时设计功能、新特性等各方面的测试用例,完善测试计划,并基于这些测试用例以开发测试脚本。

·在编程的同时,进行单元测试,是一种很有效的办法,可以尽快找出程序中的错误,充分的单元测试可以大幅度提高程序质量、减少成本。

从中可以看出,V模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动,软件测试的工作也就启动了,避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。

从垂直方向看
水平虚线上部表明,其需求分析、定义和验收测试等主要工作是面向用户,要和用户进行充分的沟通和交流,或者是和用户一起完成。

水平虚线下部的大部分工作,相对来说,都是技术工作,在开发组织内部进行,主要是由工程师、技术人员完成。

从垂直方向看,越在下面,白盒测试方法使用越多,到了集成、系统测试,更多是将白盒测试方法和黑盒测试方法结合起来使用,形成灰盒测试方法。

而在验收测试过程中,由于用户一般要参与,使用黑盒测试方法。

3.5.3模型参照
参见《V模型》。

4模型选择
4.1模型选择原则
●能够满足公司“开发管理方针”的要求;
●不会降低项目开发过程和工作产品的质量;
●不会失去对工作进展的(跟踪)可视性;
●不会失去对软件工作产品的配置管理和控制,也不会额外增加无益的工作;
●不会降低工程师的开发效率;
●在维持现有人力资源的情况下,能够按计划如期完成工作;
●项目资金可以控制在目标成本范围内。

4.2项目分类
4.3模型选择指南
公司的项目生命周期选择参见下表:。

相关文档
最新文档