软件开发过程生命周期模型
上一篇 / 下一篇 2008-01-25 15:38:19 / 个人分类:技术文章
一、生命周期 指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。目前软件开发实践中使用的各种生命周期模型,都是下面这些基本组成部分的不同的排列与组合。
市场分析,可行性研究,与项目定义
需求分析
设计(概要设计和详细设计)
编码实现
测试
使用与维护
主要有以下几种模型:
1.瀑布模型(waterfall model)
2.演化模型(evolutionary model)
3.螺旋模型(spiral model)
二、瀑布模型
瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作,形如瀑布流水,最终得到软件产品。
优点:
a.强调开发的阶段性;
b.强调早期计划及需求调查;
c.强调产品测试。
缺点:
a.依赖于早期进行的唯一一次需求调查,不能适应需求的变化;
b.由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程;
c.风险往往迟至后期的开发阶段才显露,因而失去及早纠正的机会。
这是最早存在的开发模型,并且现在使用的也比较多
瀑布模型的特点是首先是仔细的需求分析,开发组有步骤的制定一份功能(结构)说明,接着是概要设计,详细设计,然后才着手编码。编码结束后进行测试,然后才能发布软件。这看上去是很有逻辑的;只在理解后才开始构造。以这样严格的方式构造软件,工程师很明确每一步应该做什么。许多人提出了基本是基于这一模型的多种方法论;也有相当多的商业工具可以使这些步骤更机械化且不易出错。
瀑布模型各阶段的工作自顶向下从抽象到具体顺序进行。瀑布模型意味着在生命周期各阶段间存在着严格的顺序且相互依存。瀑布模型是早期软件设计的主要手段
瀑布模型依靠早期的需求分析,并且要求需求很明确
对于需求未定或是不断变化的软件不适合
现在这种模型一般用于做一些需求已明确的并很少变化的软件,不适于需求 不明确或是容易变化的软件(如你正在开发一个陌生的领域的软件,这时就不应该使用瀑布模型,但是如果你正在开发自己很熟悉领域的软件,就可以使用瀑布模型来加快开发速度)
由于需求已明确,所以不需要代码重构等方面的开销,因此效率较高
阶段 | 主要工作 | 应完成的文档 | 应完成的文档质量控制手段 |
系统需求 | 1. 调研用户需求及用户环境 2. 论证项目可行性 3. 制定项目初步计划 | 1. 可行性报告 2. 项目初步开发计划 | 1. 规范工作程序及编写文档 2. 对可行性报告及项目初步开发计划进行评审 |
需求分析 | 1. 确定系统运行环境 2. 建立系统逻辑模型 3. 确定系统功能及性能要求 4. 编写需求规格说明、用户手册概要、测试计划 5. 确认项目开发计划 | 1. 需求规格说明 2. 项目开发计划 3. 用户手册概要 4. 测试计划 | 1. 在进行需求分析时采用成熟的技术与工具,如结构化分析 2. 规范工作程序及编写文档 3. 对已完成的4种文档进行评审 |
设计 概要设计 | 1. 建立系统总体结构,划分功能模块 2. 定义各功能模块接口 3. 数据库设计(如果需要) 4. 制定组装测试计划 | 1. 概要设计说明书 2. 数据库设计说明书(如果有) 3. 组装测试计划 | 1. 在进行系统设计时采用先进的技术与工具,如结构化设计SD、结构图SC 2. 编写规范化工作程序及文档 3. 对已完成的文档进行评审 |
设计 详细设计 | 1. 设计各模块具体实现算法 2. 确定模块间详细接口 3. 制定模块测试方案 | 1. 详细设计说明书 2. 模块测试计划 | 1. 设计时采用先进的技术与工具,如结构图SC 2. 规范工作程序及编写文档 3. 对已完成的文档进行评审 |
实现 | 1. 编写程序源代码 2. 进行模块测试和调试 3. 编写用户手册 | 1. 程序调试报告 2. 用户手册 | 1. 在实现过程中采用先进的技术与工具,如结构图SC 2. 规范工作程序及编写文档 3. 对实现过程及已完成的文档进行评审 |
测试 集成测试 | 1. 执行集成测试计划 2. 编写集成测试报告 | 1. 系统源程序清单 2. 集成测试报告 | 1. 测试时采用先进的技术和工具 2. 规范工作程序及文档编写 3. 对测试工作及已完成的文档进行评审 |
测试 验收测试 | 1. 测试整个软件系统(健壮性测试) 2. 试用用户手册 3. 编写开发总结报告 | 1. 确认测试报告 2. 用户手册 3. 开发工作总结 | |
维护 | 1. 为纠正错误,完善应用而进行修改 2. 对修改进行配置管理 3. 编写故障报告和修改报告 4. 修订用户手册 | 1. 故障报告 2. 修改报告 | 1. 维护时采用先进的工具 2. 规范工作程序及编写文档 3. 配置管理 4. 对维护工作及已完成的文档进行评审 |
三、演化模型
该模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现。软件开发人员根据用户的需求,首先开发核心系统。当该核心系统投入运行后,用户试用之,完成他们的工作,并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈,实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成,为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法,每循环开发一部分的功能,它们成为这个产品的原型的新增功能。于是,设计就不断地演化出新的系统。 实际上,这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组,以便分批循环开发。这种分组并不是绝对随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出,每个开发循环以六周到八周为适当的长度。
优点:
a.任何功能一经开发就能进入测试以便验证是否符合产品需求。
b.帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求,它们可以分批取得。而对于已提出的产品需求,则可根据对现阶段原型的试用而作出修改。
c.风险管理可以在早期就获得项目进程数据,可据此对后续的开发循环作出比较切实的估算。提供机会去采取早期预防措施,增加项目成功的机率。
d.大大有助于早期建立产品开发的配置管理,产品构建(build ),自动化测试,缺陷跟踪,文档管理。均衡整个开发过程的负荷。
e.开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率。
f.如果风险管理发现资金或时间已超出可承受的程度,则可以决定调整后续的开发,或在一个适当的时刻结束开发,但仍然有一个具有部分功能的,可工作的产品。
g.心理上,开发人员早日见到产品的雏型,是一种鼓舞。
h.使用户可以在新的一批功能开发测试后,立即参加验证,以便提供非常有价值的反馈。
i.可使销售工作有可能提前进行,因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
缺点:
a.如果所有的产品需求在一开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性。
b.如果缺乏严格的过程管理的话,这个生命周期模型很可能退化为一种原始的无计划的“试-错-改”模式。
c.心理上,可能产生一种影响尽最大努力的想法,认为虽然不能完成全部功能,但还是造出了一个有部分功能的产品。
d.如果不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响。
四、螺旋模型
瀑布模型与演化模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998年由美国TRW公司(B.W.Boehm)提出。软件项目风险的大小作为指引软件过程的一个重要因素,引入这一概念有可能使得软件开发被看作一种元模型,因为它能包容任何一个开发过程模型。
螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前,引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后,才开始计划下一阶段的开发工作。否则,项目就很可能被取消。
另外,如果有充足的把握判断遗留的风险已降低到一定的程度,项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型,如“演化模型”,“瀑布模型”,或自定的混合模型。
优点:
a.强调严格的全过程风险管理。
导入论坛 引用链接 收藏 分享给好友 推荐到圈子 管理 举报
TAG:
