OPG007组织软件生命周期定义.docx
- 文档编号:17428336
- 上传时间:2023-07-25
- 格式:DOCX
- 页数:16
- 大小:492.92KB
OPG007组织软件生命周期定义.docx
《OPG007组织软件生命周期定义.docx》由会员分享,可在线阅读,更多相关《OPG007组织软件生命周期定义.docx(16页珍藏版)》请在冰点文库上搜索。
OPG007组织软件生命周期定义
OP-G-007
组织软件生命周期定义
指南
编写
潘琦
编写时间
2013-03-26
审核
胡立红
审核时间
2013-03-28
文档版本
V1.0
亚信联创科技(中国)有限公司版权所有
文档中的全部内容属亚信联创科技(中国)有限公司所有,
未经允许,不可全部或部分发表、复制、使用于任何目的。
文档修订摘要
日期
版本号
修订章节
描述
作者
评审者
评审日期
2013-03-26
V0.1
基于OSSPV3.0“生命周期模型描述及选择指南”及LSSPV1.1“EPG-LC-01-软件生命周期”,进行整合。
潘琦
2013-03-28
V1.0
对模型图进行了补充和完善
潘琦
胡立红、茅红
2013-03-26
(文档修订页说明:
记录文档自首次发布以后每一次重要的修改、修订的内容。
其中各项说明如下:
日期:
按照例如“2011-5-4”的格式记录每次修订的时间。
格式居中
版本号:
VX.Y,X为主版本号,Y为修订版本号,初始版本号为V0.1。
格式居中
修订章节:
记录修改的章节号。
格式居左
描述:
概述修改的内容或原因。
格式居左.
作者:
文档编写/修订者姓名。
格式居中
评审者:
参与评审文档者姓名。
格式居中
评审日期:
按照例如“2011-5-4”的格式记录每次评审时间。
格式居中)
目录
1概述1
2名词解释1
2.1需求获取1
2.2开发客户需求1
2.3开发软件需求1
2.4确定技术方案1
2.5架构设计1
2.6功能设计1
2.7编码&单元测试1
2.8测试方案&用例设计2
2.9模块功能测试2
2.10集成测试2
2.11系统测试2
2.12业务联调测试2
2.13用户接收测试2
2.14正式版本发布2
3组织软件生命周期定义2
3.1瀑布模型(WaterfallModel)2
3.1.1标准瀑布模型3
3.1.2简化瀑布模型5
3.2原型模型(PrototypeModel)8
3.2.1生命周期阶段8
3.2.2特点8
3.2.3应用条件9
3.3迭代模型(IterationModel)9
3.3.1生命周期阶段9
3.3.2特点11
3.3.3应用条件12
4比较12
1概述
软件生命周期模型是软件开发全部过程、资源、活动和任务的结构框架,是一种软件开发策略,该策略主要包括软件开发的阶段、方法、工具以及这些因素应如何结合的原则等方面的内容。
由于公司在交付给客户的软件产品及系统存在不同的交付方式,从而使得软件产品及系统的开发策略各有不同,基于公司典型的软件产品及系统的软件开发阶段,同时参考业界的典型软件生命周期模型,制定了组织软件生命周期模型定义。
目前在公司的软件开发实践中使用的各种生命周期模型,都是12个阶段的排列和组合构成,阶段包括:
需求获取、开发客户需求、开发软件需求、确定技术方案、架构设计、功能设计、编码&单元测试、测试方案&用例设计、模块功能测试、集成测试、业务联调测试、用户接收测试及正式版本发布。
2名词解释
2.1需求获取
根据建设项目的实际情况,选择合适的方法,有计划的展开需求调研活动,获取客户需求。
2.2开发客户需求
将客户的需要、期望、限制条件和接口转换成文档化的客户需求,并与客户达成一致的理解。
2.3开发软件需求
提炼、分解客户需求,确定系统的功能需求、非功能需求、接口需求,形成一个体系完整、内容清晰的框架,以指导后续的设计、开发工作。
2.4确定技术方案
确定技术手段、技术途径、关键问题的解决思路。
2.5架构设计
把需求及需求分析得到的信息转换为软件结构和数据结构。
2.6功能设计
对架构设计进行细化,设计每个子系统/模块/组件的实现算法、所需的局部数据结构。
2.7编码&单元测试
依据需求文档、设计文档以及编码规则编写代码,实现子系统/模块/组件的功能。
为每个程序单元设计测试用例并执行单元测试,以保障算法或逻辑的准确。
2.8测试方案&用例设计
依据软件项目整体计划、测试计划、设计文档,制定总体测试方案,以及模块功能测试、集成测试、系统测试、业务联调测试及用户接收测试的测试用例设计。
2.9模块功能测试
模块功能测试是对设计划分出的每个模块进行功能验证,确认模块功能实现是否正确。
2.10集成测试
集成测试是在模块功能测试的基础上,对模块间接口、子系统间接口进行功能验证,确认其功能实现是否正确。
从集成层次上可以划分为:
子系统内集成测试(模块间集成)、子系统间集成测试。
2.11系统测试
系统测试是在生产环境或者模拟生产环境上所进行的功能、非功能以及与外围系统接口的测试,重点是验证系统是否满足客户需求规格书中功能、非功能的要求,确认系统与外围系统接口实现是否正确。
2.12业务联调测试
业务联调测试就是从客户业务流程出发,通过模拟客户核心业务验证系统是否满足客户业务流程要求。
2.13用户接收测试
用户接受测试就是由客户主导,验证系统是否满足上线要求。
2.14正式版本发布
给用户交付完整的软件和相关文档。
3组织软件生命周期定义
3.1瀑布模型(WaterfallModel)
瀑布模型从项目启动开始,逐步进行阶段行变换,直至通过测试并得到用户确认的软件产品为止。
该模型的上一阶段的变换结果是下个阶段变换的输入,相邻两个阶段具有因果关系。
为了保障软件开发的正确性,每个阶段任务完成之后,都必须对它的阶段性成果进行评审,确认之后再转入下个阶段工作。
评审过程发现错误和缺陷后,应该反馈到前面的有关阶段,修改错误,弥补疏漏,然后重复前面的工作,直至某个阶段通过评审后再进入下个阶段。
具体参照以下图例:
3.1.1标准瀑布模型
3.1.1.1生命周期阶段
3.1.1.2特点
♦优点
Ø对管理来说,有较高的可视性
Ø若需求比较稳定,则进度也会比较容易控制
♦缺点
Ø不能适应需求不明确或需求不稳定的项目
Ø因为产生的文档较多,导致管理负担较重
Ø风险往往迟至后期的开发阶段才显露,因为失去及早纠正的机会
Ø项目范围变更将导致较大的工作量
3.1.1.3应用条件
♦需求比较明确,并预期需求比较稳定
♦解决方案的技术和架构比较明确
♦对可维护性要求较高
♦要求有较高的稳定性,及对各阶段较高的可视性及可控性
3.1.2简化瀑布模型
3.1.2.1生命周期阶段
简化瀑布模型
(1)
Note:
并列排放的活动表明这些活动可以并行执行;测试阶段的工作产物可以按项目需要合并成一个产出物文档。
简化瀑布模型
(2)
Note:
并列排放的活动表明这些活动可以并行执行;测试阶段的工作产物可以按项目需要合并成一个产出物文档。
3.1.2.2特点
♦优点
Ø对进度采用适中的控制
Ø中等的管理费用
Ø对解决方案的合理控制
♦缺点
Ø在开发过程中,最终用户对开发状况不了解
Ø由于只有一次设计活动评审,对较复杂的项目不推荐使用
3.1.2.3应用条件
♦产品的用户接口比较简单,已经有原型或参考实例
♦用户接口设计的最终方案的确定依赖于系统架构的实现方法
♦详细设计必须依赖于源码修改试验的移植型项目
♦以试验为目的的新开发,希望快速的实现整个系统,对产品质量要求不高
♦单个模块的测试不能独立运行,必须集成后才能进行
♦模块间接口比较简单,集中测试不会遗漏单元测试的检查点
♦现有的测试套件将单元和集成测试结合
♦产品规模很小的新项目
3.2原型模型(PrototypeModel)
在很多时候,需求分析人员无法通过与用户交谈就能获得明确的、详细的需求,通常情况下,用户只定义了软件的一组一般性目标,但不能有效标识出详细的输入与输出及处理要求,这种情况需要采用原型实现模型。
它的主要思想是首先建立一个能够反映用户主要需求的原型,使得用户和开发者可以对目标系统的概貌进行评价和判断,让后对原型进行若干反复的扩充、改进、求精、最终建立符合用户需求的目标系统。
快速原型模型的开发基本上是线性顺序进行的。
第一系统已经通过和用户交互而得到验证,由此产生的需求能够很好反映用户现状;第二开发人员通过建立模型已经学到了很多东西,因此在设计和编码阶段发生错误的几率很小。
公司的原始模型采用的抛弃模型,原型开发后,已获得了更为清晰的需求反馈信息,原型使用完毕后无需保留而抛弃,重新建立目标系统,这相当于生命周期中需求分析和设计的过程。
如果选择了原型模型后,项目还需要依据交付的软件产品及系统,再选择合适的生命周期模型,如:
瀑布模型或迭代模型,以明确设计、测试和发布等阶段。
3.2.1生命周期阶段
3.2.2特点
♦优点
Ø开发人员和用户在“原型”上达成一致,减少了设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意度。
Ø缩短了开发周期,加快了工程进度,降低了成本。
♦缺点
Ø应该抛弃的原型不被抛弃,导致后期修改工作量加大。
3.2.3应用条件
♦需求不确定
♦解决方案的技术和架构不明确
3.3迭代模型(IterationModel)
迭代模型采取分批循环开发的方法,首先实现一部分核心功能,试运行评价后再精化系统,增强系统能力,从而不断完善产品。
实际上,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:
需求、分析设计、实施和测试工作流程,这个模型可看作是重复执行的多个“瀑布模型”。
所有的阶段都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
在质量管理方面,以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。
每次迭代进行系统集成、系统测试,达到对软件质量的持续验证。
每次系统测试,需要回归测试前一次迭代遗留发现的问题。
每次迭代发布的小版本组织客户(包括内部客户、外部客户)进行评价,通过演示操作等方式,评价该次迭代是否达到预定的目标,并以此为依据来制定下一次迭代的目标。
在其他方面,每次迭代成果须进行配置管理,版本控制很重要。
在整个迭代过程中风险无处不在,建议每周作一次风险跟踪。
同时通过重点关注进度、工作量、满意度、缺陷等数据收集,关注每次迭代情况。
迭代模型要求开发人员有能力把项目的产品需求分解为不同组,以便分批循环开发。
这种分组并不是绝对随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。
有经验指出,每个开发循环以六周到八周为适当的长度。
3.3.1生命周期阶段
迭代模型1
Note:
并列排放的活动表明这些活动可以并行执行。
迭代模型2
Note:
并列排放的活动表明这些活动可以并行执行。
3.3.2特点
♦优点
Ø由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的,软件开发可以较好地适应变化。
Ø客户可以不断地看到所开发的软件
Ø降低开发风险
Ø降低了产品无法按照既定进度进入市场的风险。
Ø加快了整个开发工作的进度。
因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
♦缺点
Ø如果所有的产品需求在一开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并影响产品性能的优化及产品的可维护性,因此需要软件具有开放式体系结构。
Ø如果缺乏严格的过程管理的话,很容易退化为边做边改模型,从而使软件过程的控制失去整体性。
Ø如果不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响。
3.3.3应用条件
♦新增各组件功能相对独立
♦主要针对事先不能完整定义需求的软件开发
♦在项目开发早期需求可能有所变化
♦高风险项目
4比较
瀑布模型
原型法
迭代模型
规范性
易管理
难度较大
易管理
版本控制
单一版本
多版本
多版本
可维护性
软件维护较容易
忽略维护
便于维护
用户需求
不能适应需求变化
适应需求变化
适应用户需求变化
风险
不容易控制
风险小
抗风险能力强
成本
降低成本
快速开发阶段成本增加,总体上降低成本
增加成本
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OPG007 组织 软件 生命周期 定义