软件工程过程模型及其选择

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

软件工程过程模型及其选择

摘要:软件工程过程是开发或维护软件及其相关产品的一系列活动。它包括四个基本过程活动软件规格说明软件开发软件确认软件严谨。在一个良好的软件过程中, 还应该包括软件项目的跟踪监控、技术审核、配里管理、质保证与测试、风险管理等。本文就目前市场的主要应用软件工程模型及其选择做一些探讨。

在一个具体的实际工程活动中, 软件工程师必须设计、提炼出一个工程开发策略, 用以渡盖软件过程中的基本阶段, 确定所设计的过程、方法、工具。这种策略常被称为软件工程模型。对于模型的选择应当是根据组织定义的标准软件过程, 参考具体工程项目的特点和资源状况裁剪来进行的。

在软件工程实践中, 有许多专家致力于过程模型的研究。像瀑布模型、原型模型、快速应用开发模型、螺旋模型、敏捷过程模型、开发模型等。下面谈谈几种主要过程模型布模型每一个阶段都不应该重叠, 而应该是在评审通过, 相关

产出物都已经基线后才能够进人到下一个阶段。

瀑布模型/改进的瀑布模型

虽然瀑布模型仍然存在很多的问题有待解决,但爆布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型。瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行, 每一个阶段都可以定义明确的

产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证, 只有在评审通过后才能够进人到下一个阶段。

由于需要对每一个阶段进行验证, 添布模型要求每一个阶段都有明确的文

档产出, 对于严格的瀑瀑布模型的优点仍然是可以保证整个软件产品较高的质量, 保证缺陷能够提前的被发现和解决。

采用澡布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性。但对于前期需求不明确, 而又很难短时间明确清楚的项目则很难很好地利用瀑布模型。另外对于中小型的项目,需求设计和开发人员往往在项目开始后就会全部投入到项目中, 而不是分阶段投人, 因此采用爆布模型会导致项

目人力资源过多的闲置的情况, 这也是必须要考虑的问题。

很多人往往会以进度约束而不选择澡布模型,这往往是一个错误的观点。导致这种情况的一个关键因素往往是概念需求阶段人力不足。因此在概念需求阶段人力能够得到充分保证的情况下, 爆布模型和迭代模型在开发周期上并不会存在太大的差别。反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确, 没有经过一个总体的架构设计情况下就开始编码, 后期出现大量

的返工而严重影响进度。

架构设计是软件开发中一个重要的关注点。因此在中也提及软件开发要以架构为核心。因此在架构设计完成后系统会被分为相关的子系统和功能模块。每个功能模块间的接口都可以定义清楚。在这种情况下, 当模块的详细设计做完成后往往就没有必要等到其他模块的详细设计都要完全作完才开始编码, 因此在

架构设计完成后可以将系统分为多个模块并行开发, 每个模块仍然遵循先设计

和编码测试的瀑布模型思路。这是瀑布模型的一种最重要的改进思路, 也可以说这是一种增量开发的模型。

当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候, 这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作。这种方式的最大问题就是没有一个完全总体的设计, 架构设计人员无法在洞悉了所有需求后从系统的可扩展性, 复用等方面总体规划。

在项目管理中有一种压缩进度的方法叫赶工,因此添布模型的另外改进处就在适当的重叠各个阶段过程, 达到资源的有效利用。比如我们通过讨论, 会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来。

螺旋模型

首先螺旋模型是遵从澡布模型的。即需求一架构一设计一开发一测试的路线。螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的。通过将瀑布模型的多个阶段转化到多个迭代过程中, 以减少项目的风险。

螺旋模型的每一次迭代都包含了以下六个步骤正确性。

1. 决定目标, 替代方案和约束。

2.识别和解决项目的风险。

3.评估技术方案和替代解决方案。

4.开发本次迭代的交付物和验证迭代产出的正确性。

5.计划下一次迭代。

6.提交下一次迭代的步骤和方案。

螺旋模型实现了随着项目成本投人不断增加,风险逐渐减小。以帮我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证, 当发现无法继续进行下去时可以及早地终止项目。

螺旋模型复杂的地方在于尽责、专心和知识渊博的管理。因为对于每一次迭代我们要制定出清晰的目标, 分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情。

螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段。如第二次迭代重点是需求, 第三次迭代是总体设计和后续设计开发计划等。因此这是和RUP 提倡的迭代模型是有区别的,RUP的每一次迭代都会包含需求、设计、开发和测试等各个阶段的活动。迭代的目的在于逐步求精而不是仅仅完成解布模型某一阶段的工作。原型法增童和迭代模型增量迭代是RUP统一过程常采用的软件开发生命周期模型。增和迭代有区别但两者又经常一起使用。所以这里要先解释增和迭代的概念。假设现在要开发A,B,C,D 四个大的业务功能, 每个功能都需要开发两周的时间。则对于增量方法而言可以将四个功能分两次增量来完成第一个增量完成A,B 功能, 第二次增量完成C,D 功能而对于迭代开发来讲则是分两次迭代来开发, 第一次迭代完成A,B,C ,D 四个基本业务功能但不含复杂的业务逻辑, 而第二个功能再逐渐细化补充完整相关的业务逻辑。在第一个月过去后采用增量开始时候, 全部开发完成而, 还一点都没有动而采用迭代开发的时候

A,B,C,D四个的基础功能都已经完成。

强调的每次迭代都包含了需求、设计和开发、侧试等各个过程, 而且每次迭代完成后都是一个可以交付的原型。迭代不是并行, 在每次迭代过程中仍然要遵循需求->设计->开发的澡布过程。迭代周期的长度跟项目的周期和规模有很大的关系。小型项目可以一周一次迭代, 而对于大型项目则可以2-4周一次迭代。如果项目没有一个很好的架构师, 很难规划出每次迭代的内容和要到达的目标, 验证相关的交付和产出。因此迭代模型虽然能够很好的满足与用户的交付, 需求

相关文档
最新文档