CMMI过程管理OPD软件生命周期模型描述V.docx
- 文档编号:4829430
- 上传时间:2022-12-10
- 格式:DOCX
- 页数:24
- 大小:237.40KB
CMMI过程管理OPD软件生命周期模型描述V.docx
《CMMI过程管理OPD软件生命周期模型描述V.docx》由会员分享,可在线阅读,更多相关《CMMI过程管理OPD软件生命周期模型描述V.docx(24页珍藏版)》请在冰豆网上搜索。
CMMI过程管理OPD软件生命周期模型描述V
软件生命周期模型描述
文档编号:
GZCY_OPD_PRS-V1.0
文档信息:
文档名称:
文档类别:
CMMI模板
密级:
机密
版本信息:
V1.0
建立日期:
创建人:
审核者:
批准人:
批准日期:
保管人:
存放位置:
编辑软件:
MicrosoftOffice2003英文版
CONFIDENTIAL
文档修订记录
版本编号或者更改记录编号
变化状态
简要说明(变更内容
和变更范围)
日期
变更人
批准日期
批准人
V1.0
C
初次创建
2004-07-21
CMM事业部
*变化状态:
C――创建,A——增加,M——修改,D——删除
文档审批信息
序号
审批人
角色
审批日期
签字
备注
前言
本文描述组织级定义的软件生命周期模型,供项目策划时根据项目的具体情况选择或裁剪使用,由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。
但是“所有的模型都是错误,有些模型是有用的”。
模型是对它们所代表的真实世界的简化,这种简化更多的是为了规范管理的需要,它只能够照顾大多数。
如果它不适合你的项目或者有更能真实表达现实世界的模型出现,因为涉及到组织管理方式的变化,任何模型的修改或新模型的加入都需要通过组织的审批。
第一章简介
软件生命周期由制定计划、需求开发、设计、编码、测试、维护等各项活动组成,而如何将这些活动合理、有效地衔接组织起来,就需要在软件项目策划阶段选择合适的软件生命周期模型。
正如每个项目的目的是唯一的,每个项目的软件生命周期模型也将是唯一的,定义软件生命周期是项目计划的一个重要步骤,它将直接影响到WBS及软件开发计划的制定。
一.1目的
本文的目的是为了指导软件项目策划人员如何选用软件生命周期模型。
一.2适用范围
本文档适用于公司中的所有软件项目。
一.3术语表
●软件生命周期(Softwarelifecycle):
从软件产品的设想开始到软件不再使用而结束的时间周期。
软件生命周期一般包括需求阶段、设计阶段、实现阶段、测试阶段、运行和维护阶段,有时还包括退役阶段。
●软件过程:
有关开发和维护软件及其相关产品(例如:
项目计划、设计文档、代码、测试用例、用户手册等)的活动、方法、实践和变更的集合。
●CASE工具:
计算机辅助软件工程工具,为与软件过程相关的每个活动中的软件工程管理者和实践者提供帮助,它们自动化项目管理活动,管理所有在过程中产生的工作产品并且辅助工程师完成他们的分析、设计、编码和测试工作。
一.4参考资料
●《软件工程Java语言实现》,StephenR.Schach著,袁兆山等译,机械工业出版社,1999年9月
●《软件工程实践者的研究方法》,RogerS.Pressman著,梅宏等译,机械工业出版社,2002年9月
●《实用软件工程》郑人杰、殷人昆、陶永雷著,清华大学出版社,1997年4月
●《软件需求》,KarlE.Wiegers著,陆丽娜、王忠民、王志敏等译,机械工业出版社,2000年7月
●《统一软件开发过程》,IvarJacobson、GradyBooch、JamesRumbaugh著,周伯生、冯学民、樊东平等译,机械工业出版社,2002年1月
第二章过程概述
为了使项目在定义软件过程时能够依据其特性选择适用的软件生命周期,使得项目开发过程流程化、易于管理、提高开发速度和产品质量,以达到更好的满足客户的要求,组织规定了以下几种适于本组织使用的生命周期模型:
●V字模型
●中等简化V字模型
●最简化V字模型
●迭代模型
●以需求、计划、设计为重点的迭代模型
●以计划、设计、编码、测试为重点的迭代模型
●原型+瀑布模型
●增量模型
●增量的迭代过程模型
●快速应用开发模型
●螺旋模型
注:
1.在组织中有些需求不清晰的项目中也会使用快速原型法,但这主要起到需求获取的作用,通常不作为生命周期模型描述,开发过程使用的生命周期模型以上述几种为主。
第三章生命周期模型描述
三.1V字模型
三.1.1概述
V字模型其实就是瀑布模型,它是一种线型顺序模型,是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用,它提供了一种结构化的、自顶向下的软件开发方法,每阶段主要工作成果从一个阶段传递到下一个阶段,必须经过严格的评审或测试,以判定是否可以开始下一阶段工作,各阶段相互独立、不重叠。
V字模型是所有软件生命周期模型的基础。
V字模型的开发流程如下图:
图1V字模型示意图
三.1.2阶段定义
No
阶段
入口标准
任务
出口标准
1
需求开发
项目立项报告已经由高层经理签字,项目开始启动。
需求访谈及分析
系统测试设计
软件需求规格说明书及系统测试设计完成并形成基线
2
概要设计
软件需求规格说明书已经完成并形成基线。
进行数据库设计
各模块的概要设计
集成测试设计
概要设计说明书及集成测试设计完成并形成基线。
3
详细设计
概要设计已完成并形成基线
进行详细设计及单元测试用例编写。
详细设计及单元测试用例编写完成并形成基线。
4
实现
详细设计完成并形成基线
进行编码及单元测试
编码及单元测试完成并形成基线。
5
测试
系统测试设计完成
集成测试设计完成
编码及单元测试完成
用户文档完成(安装、操作、维护)
进行集成、系统测试
集成、系统测试完成并形成基线
6
运行维护
测试已经完成
系统安装、运行、维护
组织不再对产品进行维护
三.1.3适用情况
●充分理解用户需求,且需求是确定不变的
●用户有一定的能力,对需求的表述是确切的
●充分理解该解决方案的技术和体系
●需要一个可维护性和可支持性较高的解决方案
●所有过程工作产品的控制基线,需要有可见度和可靠性
●适用于新的有较多用户的产品、平台/中间件开发项目,或者是用户对开发过程有严格要求的工程定制项目
●项目经理有一定的项目管理经验
●要求开发周期时间较充分
三.1.4优点
●强调开发的阶段性
●强调早期的计划及需求调查与分析
●强调产品测试的完备性
●过程文档齐全,便于追溯和重用
●过程的可见性强,便于过程质量控制
●只要需求是稳定的,则进度也是稳定的
三.1.5缺点
●无法解决软件需求不明确或不准确的问题
●灵活性差,依赖于早期进行的需求调查,不能适应需求的变化
●由于是单一流程,开发中的经验教训不能及时反馈并应用于本产品的过程改进
三.1.6本企业适合项目类型
组织所熟悉领域的应用系统开发;例如:
联行子系统的开发。
三.2中等简化V字模型
三.2.1概述
针对组织中项目的实际情况,对V字(瀑布)模型进行演化是必要的。
中等简化V字模型就是在标准瀑布模型基础上根据组织中一些小项目等的实际需要演化来的。
流程图如下所示:
图2中等简化V字模型示意图
三.2.2阶段定义
参见V字模型。
三.2.3适用情况
●项目的复杂度、团队的规模、工作量和周转时间都是中等程度的
●需求和技术都已被充分理解
●项目经理有较高的项目管理和控制的经验
三.2.4优点
●可以适应中等和较小项目的较灵活的管理需要
●提供中度的进度控制,相对标准V字模型,可以减少部分项目管理工作量和开支
●在产品交付方面进行合理的控制
三.2.5缺点
●因项目开发流程相对简化,项目的风险增大,质量隐患增大
三.2.6本企业适合项目类型
在已经运行过的成型系统之上,根据客户的不同需求进行客户化改造的项目,客户对原系统有充分的了解,能够提出比较成熟的需求,则项目过程可以采用中等简化V字模型。
例如:
廊坊农信综合业务系统客户化改造项目。
三.3最简化V字模型
三.3.1概述
针对组织中项目的实际情况,对V字(瀑布)模型进行演化是必要的。
最简化V字模型就是在标准瀑布模型基础上根据组织中的小项目和维护项目等的实际需要演化出来的。
一般情况下,不建议使用此种模型。
流程图如下所示:
图3最简化V字模型示意图
三.3.2阶段定义
参见V字模型。
三.3.3适用情况
●项目的规模和工作量都比较小
●项目具有较小的开发团队
●需求和技术都是被充分确定和理解的
●系统具有低复杂度,不需要独立的设计阶段
●产品的体系结构是稳定的
●项目经理经验丰富,对项目有较好的管理控制能力
●项目开发周期较短
三.3.4优点
●可以适应小项目的灵活性
●减少过程复杂带来的产品提交时间延长
●过程相对简单,项目管理控制的工作量相对较少
●提供中度的进度控制
●减少开支
三.3.5缺点
●对阶段性的控制较弱,问题不能及时发现
●项目前期控制较弱,使得项目产品质量留有隐患
三.3.6本企业适合项目类型
单项功能的修改或增加的项目,开发时间小于10天的项目可以选用最简化V字模型;例如:
综合业务系统中储蓄批量自动结息的效率优化项目。
三.4迭代模型
三.4.1概述
在项目做计划的过程中,选用迭代模型时,有如下要求:
●进行第一次项目计划时,确定所选择的生命周期模型为迭代模型时,要求在计划中明确进行迭代流程阶段、迭代的次数、每次迭代所选的生命周期模型以及每次迭代的起止日期。
●每次迭代所选的生命周期模型,可以根据本次迭代的重点,选择瀑布型-标准V模型、中等简化V字模型、最简化V字模型中的一种,或者是某种瀑布模型的某几个流程阶段,确定为本次迭代的工作流程阶段。
●对项目WBS的要求:
以下表格可以与WBS结合,用于明确各流程阶段的工作任务、该任务在本次迭代中的重要程度(强、中、弱)、该流程阶段的控制点及控制手段(如重要程度为“强”的任务须进行评审,“中”的任务可以通过变更过程进行控制,“弱”的任务可以通过批准直接在文档的修订页中注明)。
迭代次数
流程阶段
工作任务
重要程度
(强、中、弱)
工作产品
控制点及控制手段
●根据每次迭代的WBS任务和各WBS任务在本次迭代中的重要程度(强、中、弱),参照迭代模型样例图,绘制本项目的迭代模型图。
●从第二次到第N次的迭代,在不与第一次计划冲突的基础上,制定本次迭代的小计划,也可以直接在项目的PROJECT图上进行本次迭代计划的细化。
●如果后几次迭代对第一次计划的内容有变动,如进度的调整,控制点的变化等,则须进行变更及批准。
迭代模型的开发流程图如下:
图4迭代模型示意图
三.4.2阶段定义
参见V字模型。
三.4.3适用情况
●规模较大的项目或产品
●需求的清晰度低,且需要进一步的调查
●技术或体系结构方面的知识匮乏
三.4.4优点
●允许变更需求,中途的修改是容易的,如果在项目组内部和外部之间有良好的沟通渠道
●有助于项目组的学习和提高,团队成员有机会在整个生命周期中边做边学,各显其能
●迭代流程自身可在进行过程中得到改进和精炼
●生成性能更强壮的产品
●风险管理比较容易,可及早降低风险,前提是存在良好的信息传递渠道
●与其他生命周期模型相比,它在开发周期内具有更好的性能
三.4.5缺点
●因本模型较为灵活,对管理的要求较高,项目经理需要有丰富的项目管理经验
●迭代的次数和任务规划难把握,对项目策划要求较高
三.4.6本企业适合项目类型
新领域、新技术的研发项目。
三.4.7以需求、计划、设计为重点的迭代模型
此种模型是根据组织目前的实际情况制定的,常用于需求不明确的项目:
使用此模型的要求与迭代模型相同,流程图如下所示
图5以需求、计划、设计为重点的迭代模型示意图
三.4.8以计划、设计、编码、测试为重点的迭代模型
此种模型是根据组织目前的实际情况制定的,常用于算法型等技术难度较高的项目:
使用此模型的要求与迭代模型相同,流程图如下所示
图6以计划、设计、编码、测试为重点的迭代模型示意图
三.5原型+瀑布模型
三.5.1概述
原型模型本身是一个迭代的模型,是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题,通过建立原型使开发者进一步确定其应开发的产品,使开发者的想象更具体化,也更易于被客户所理解。
原型只是真实系统的一部分或一个模型,完全可能不完成任何有用的事情,通常包括抛弃型和进化型两种,抛弃型指原型建立、分析之后要扔掉,整个系统重新分析和设计;进化型则是对需求的定义较清楚的情形,原型建立之后要保留,作为系逐渐增加的基础,采用进化型一定要重视软件设计的系统性和完整性,并且在质量要求方面没有捷径,因此,对于描述相同的功能,建立进化型原型比建立抛弃型原型所花的时间要多。
原型建立确认需求之后采用瀑布模型的方式完成项目开发。
图表7原型+瀑布模型开发流程图
三.5.2阶段定义
No
阶段
入口标准
任务
出口标准
1
需求开发
项目立项报告已经由高层经理签字,项目开始启动。
需求访谈及分析
软件需求说明
2
原型设计
软件需求说明
快速设计系统原型
原型设计说明
3
原型实现
原型设计说明
快速进行原型的制作
系统原型
4
原型测试
系统原型
用户测试评估原型,进一步精化需求,开发人员制作新的软件需求
改进后的软件需求,并作为下个原型的设计入口
5
瀑布开发
原型得到用户认可
按照V字瀑布模型进行产品开发
参照V字模型
三.5.3适用情况
●项目包含一种新技术,例:
新硬件、新的开发语言、新的系统架构等;
●需求不很清楚;
●存在关于性能、可靠性和可行性方面的主要的、未解决的问题;
●用户界面对系统成功是很关键的,但不很清楚。
三.5.4优点
●开发者可以很快的构建系统,客户也可以尽快的感受到实际的系统。
●客户和开发者对系统有更好的理解。
●客户充分参与,可以减少部分培训的工作。
三.5.5缺点
●由于原型并非最终产品,如果原型不能利用,可能导致成本的增加;同时会引起客户的误解,以为产品即将完成。
●开发者为了使原型能够尽早工作,常常会采取一些临时性的做法,而不管这些做法是否合理,如:
使用一个效率低的算法仅仅是为了演示功能。
在经过一段时间后,开发者对这些做法已经习惯了,忘记了它们不合理的原因。
于是这些不合理的做法就成了系统的组成部分。
三.5.6本企业适合的项目类型
新领域的应用项目的开发;如企业应用系统开发项目等。
三.6增量模型
三.6.1概述
增量模型是一种进化软件过程模型,融合了线性顺序模型的基本成分(重复地应用)和原型模型的迭代特征,如下图所示。
当使用增量模型时,第一个增量往往是核心产品,即实现了基本的需求;核心产品交用户使用(或进行更详细的复审),使用和/或评估的结果是下一个增量的开发计划,该计划包括对核心产品的修改,使其能更好的满足用户的需要,并发布一些新增的特点和功能。
增量模型和原型模型不一样,强调每一个增量均要发布一个可操作产品。
早期的增量是最终产品的“可拆卸”版本,但能提供用户服务功能和用户评估的平台。
图表8增量模型开发流程图
三.6.2阶段定义
No
阶段
入口标准
任务
出口标准
1
需求开发
项目立项报告已经由高层经理签字,项目开始启动。
需求访谈及分析
系统分析
软件需求规格说明书完成并形成基线
2
软件结构设计
软件需求规格说明书已经完成并形成基线。
进行系统总体结构设计和概要设计
系统结构设计及概要设计说明书
3
增量1
立项报告已经由高层经理签字,并进行了总体的需求开发及概要设计。
进行第一阶段的详细设计、编码、测试及发布。
第一阶段产品完成。
4
增量2
增量1产品已经完成并完善了本阶段的需求开发及概要设计。
进行第二阶段的详细设计、编码、测试及发布。
第二阶段产品完成。
5
增量3
增量2产品已经完成并完善了本阶段的需求开发及概要设计。
进行第三阶段的详细设计、编码、测试及发布。
第三阶段产品完成。
6
维护
产品全部投入运行
进行系统维护
组织不再对产品进行维护
三.6.3适用情况
●当项目可清晰地划分为多个功能独立的子项目,或采用阶段开发时,适合选择增量模型。
●市场期限或资源非常紧迫,不可能完成一个完善的产品时,但可以提交一个有限的版本以应付竞争和商业压力时,适合选择增量模型。
●核心产品或系统需求能够被很好的理解,但是细节尚需要进一步明确时,适合选择增量模型。
三.6.4优点
●有利于控制成本,可以用较少的成本先生成“产品核心”,然后根据需要适时生成完善的产品。
●可以有计划的管理技术风险,新的技术可以在增量版本中使用,减少在最初就采用新技术的风险。
●提供了用户评估的平台,能够更好的满足用户需求。
三.6.5缺点
由于增量模型的灵活性,往往容易退化成边做边改方法,使软件过程的控制丧失了整体性,最终的产品也不是开放的,而是成为维护人员的恶梦。
三.6.6本企业适合的项目类型
各种中、大规模的项目类型;已有系统技术路线发生改变但需求明确的移植类项目。
三.7增量的迭代过程模型
三.7.1概述
该模型是一个不断迭代和增量的过程,迭代过程首先要处理一组客户的业务需求,这些业务需求合起来能够辨别所开发产品的可用性。
其次,迭代过程要解决最突出的风险问题。
后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。
一个增量不一定是对原有产品的增加,尤其在生命周期初期,开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。
在较后的阶段,增量通常是对原有产品的增加。
采用此种模型最好是基于构件和有相应的构件开发工具。
图表9增量的迭代模型
三.7.2阶段定义
No
阶段
入口标准
任务
出口标准
1
迭代1
立项报告已经由高层经理签字,并进行了总体的需求开发及概要设计。
进行第一阶段的详细设计、编码、测试及发布。
第一阶段产品完成。
2
迭代2
迭代1产品已经完成并完善了本阶段的需求开发及概要设计。
进行第二阶段的详细设计、编码、测试及发布。
第二阶段产品完成。
3
迭代3
迭代2产品已经完成并完善了本阶段的需求开发及概要设计。
进行第三阶段的详细设计、编码、测试及发布。
第三阶段产品完成。
┆
三.7.3适用情况
●规模较大的项目或产品,但是需求的清晰度低,且需要进一步的调查。
●新领域或有大量新技术的应用。
●项目可清晰地划分为多个功能独立的子项目,或可以采用阶段开发。
●市场期限或资源非常紧迫,不可能完成一个完善的产品时,但可以提交一个有限的版本以应付竞争和商业压力。
三.7.4优点
●允许变更需求,中途的修改是容易的。
●有助于项目团队的建设,团队成员有机会边做边学,积累知识和经验。
●有利于控制成本,可以用较少的成本先生成“产品核心”,然后根据需要适时生成完善的产品。
●可以有计划的管理技术风险,新的技术可以在增量版本中使用,减少在最初就采用新技术的风险。
●提供了用户评估的平台,能够更好的满足用户需求。
三.7.5缺点
需要相当的风险评估的技术;每个迭代循环控制不好会变成边做边改模式。
三.7.6本企业适合的项目类型
较复杂的应用项目,如:
新一代银行综合业务系统。
三.8快速应用开发模型
三.8.1概述
快速应用开发模型(RAD)是一个线性顺序的软件开发模型,强调极短的开发周期(2-3个月)。
该模型是线性顺序模型的一个“高速”变种,如果需求理解得很好,且约束了项目范围,就可通过使用基于构件或可得用软件包的建造方法获得快速开发。
主要适用于信息系统应用软件的开发。
图表10快速应用开发模型
三.8.2阶段定义
No
阶段
入口标准
任务
出口标准
1
业务建模
立项报告已经由高层经理签字,并对客户需求进行充分的理解和进行可系统的结构设计
分析业务信息流程,建立业务模型
业务模型获得批准
2
数据建模
业务模型已经建立
根据业务模型,对信息进行细化,形成一组支持业务所需要的数据对象,标识出每个对象的属性,并且定义对象间的关系,形成数据模型
数据模型获得批准
3
处理建模
数据模型已经建立
把数据模型定义的数据对象变换,以实现完成一个业务功能所需要的信息流
处理模型获得批准
4
应用生成
模型已经建立
根据模型,使用自动化辅助工具和构造系统构件
构件构造完成
5
测试
构件构造完成
反复进行构件和构件接口的测试,根据测试结果修改自动生成的代码,以达到设计要求,如效率和可维护性等
构件测试通过,达到设计要求
6
集成和测试
构件测试通过
反复进行系统集成和测试,以达到设计要求
系统测试通过
7
验收
系统测试通过
用户进行系统验收
用户验收通过
8
维护
用户验收通过,系统投入运行
进行系统维护
组织不在对产品进行维护
三.8.3适用情况
当项目必须在最短的时间内完成,而且需求理解的很好且约束了项目范围,适合选择该模型。
三.8.4优点
开发周期短。
三.8.5缺点
对大型的、但可伸缩的项目,RAD需要足够的人力以创建足够的RAD小组。
RAD要求开发者和用户在一个很短的时间内完成一个系统,如果双方中的任何一方没完成约定,都会导致RAD项目失败。
三.8.6本企业适合的项目类型
具有可重用的构件库和CASE工具的应用项目:
如信息系统等。
三.9螺旋模型
三.9.1概述
螺旋模型也是瀑布模型的一种变化模型,其中的每个回旋代表一个特定开发阶段。
它区别于瀑布式的不同点是,它在每个主要阶段结合了风险分析和原型。
提交线
实施工程
客户评估
评审
制定计划、决定目标、方案和限制
风险分析
累计
成本
原型
图表11螺旋模型
螺旋模型沿着螺线旋转,如图所示,在笛卡尔坐标的四个象限上分别表达了四个方面的活动,即:
●制定计划:
确定软件目标,选定实施方案,弄清项目开发的限制条件
●风险分析:
分析所选方案,考虑如何识别和消除风险
●实施工程:
实施软件开发
●客户评估:
评价开发工作,提出修正建议
螺旋模型的每个回旋都开发出更为完善的一个新的软件版本。
例如:
在第一圈,确定了初步的目标、方案和限制条件后,转入右上象限,对风险进行识别和分析。
如果风险分析表明,需求有不确定性,那么在右下的工程象限内,所建的原型会帮助开发人员和客户,考虑其它开发模型,并对需求做进一步修正。
客户对工程成果做出评
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMMI 过程 管理 OPD 软件 生命周期 模型 描述