《软件工程过程模型及其选择》由会员分享，可在线阅读，更多相关《软件工程过程模型及其选择（4页珍藏版）》请在金锄头文库上搜索。
1、软件工程过程模型及其选择 摘要 软件工程过程是开发或维护软件及其相关产品的一系列活动 它包括 四个基本过程活动软件规格说明软件开发软件确认软件严谨 在一个良好的软 件过程中 还应该包括软件项目的跟踪监控 技术审核 配里管理 质保证与测 试 风险管理等 本文就目前市场的主要应用软件工程模型及其选择做一些探讨 在一个具体的实际工程活动中 软件工程师必须设计 提炼出一个工程开发 策略 用以渡盖软件过程中的基本阶段 确定所设计的过程 方法 工具 这种 策略常被称为软件工程模型 对于模型的选择应当是根据组织定义的标准软件 过程 参考具体工程项目的特点和资源状况裁剪来进行的 在软件工程实践中 有许多专家致
2、力于过程模型的研究 像瀑布模型 原型 模型 快速应用开发模型 螺旋模型 敏捷过程模型 开发模型等 下面谈谈几 种主要过程模型布模型每一个阶段都不应该重叠 而应该是在评审通过 相关 产出物都已经基线后才能够进人到下一个阶段 瀑布模型 改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决 但爆布模型仍然是最基本的和 最效的一种可供选择的软件开发生命周期模型 瀑布模型要求软件开发严格按 照需求 分析 设计 编码 测试的阶段进行 每一个阶段都可以定义明确的 产出物和验证准则 瀑布模型在每一个阶段完成后都可以组织相关的评审和验证 只有在评审通过后才能够进人到下一个阶段 由于需要对每一个阶段进行验证 添
3、布模型要求每一个阶段都有明确的文 档产出 对于严格的瀑瀑布模型的优点仍然是可以保证整个软件产品较高的质 量 保证缺陷能够提前的被发现和解决 采用澡布模型可以保证系统在整体上的充分把握 使系统具备良好的扩展性 和可维护性 但对于前期需求不明确 而又很难短时间明确清楚的项目则很难很 好地利用瀑布模型 另外对于中小型的项目 需求设计和开发人员往往在项目开 始后就会全部投入到项目中 而不是分阶段投人 因此采用爆布模型会导致项 目人力资源过多的闲置的情况 这也是必须要考虑的问题 很多人往往会以进度约束而不选择澡布模型 这往往是一个错误的观点 导 致这种情况的一个关键因素往往是概念需求阶段人力不足 因此在
4、概念需求阶段 人力 能够得到充分保证的情况下 爆布模型和迭代模型在开发周期上并不会存 在太大的差别 反而是很多项目对于迭代或敏捷模型用不好 为了赶进度在前期 需求不明确 没有经过一个总体的架构设计情况下就开始编码 后期出现大量 的返工而严重影响进度 架构设计是软件开发中一个重要的关注点 因此在中也提及软件开发要以架 构为核心 因此在架构设计完成后系统会被分为相关的子系统和功能模块 每个 功能 模块间的接口都可以定义清楚 在这种情况下 当模块的详细设计做完成 后往往就没有必要等到其他模块的详细设计都要完全作完才开始编码 因此在 架构设计完成后可以将系统分为多个模块并行开发 每个模块仍然遵循先设计
5、 和编码测试的瀑布模型思路 这是瀑布模型的一种最重要的改进思路 也可以说 这是一种增量开发的模型 当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候 这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作 这种方式的最大问题就是没有一个完全总体的设计 架构设计人员无法在洞悉 了所有需求后从系统的可扩展性 复用等方面总体规划 在项目管理中有一种压缩进度的方法叫赶工 因此添布模型的另外改进处就 在适当的重叠各个阶段过程 达到资源的有效利用 比如我们通过讨论 会议确 定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付 物文档化出来 螺旋模型 首先螺旋模型是
6、遵从澡布模型的 即需求一架构一设计一开发一测试的路 线 螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的 通过将瀑布模 型的多个阶段转化到多个迭代过程中 以减少项目的风险 螺旋模型的每一次迭代都包含了以下六个步骤正确性 1 决定目标 替代方案和约束 2 识别和解决项目的风险 3 评估技术方案和替代解决方案 4 开发本次迭代的交付物和验证迭代产出的正确性 5 计划下一次迭代 6 提交下一次迭代的步骤和方案 螺旋模型实现了随着项目成本投人不断增加 风险逐渐减小 以帮我们加强 项目的管理和跟踪 在每次迭代结束后都需要对产出物进行评估和验证 当发现 无法继续进行下去时可以及早地终止项目 螺旋模型复
7、杂的地方在于尽责 专心和知识渊博的管理 因为对于每一次迭 代我们要制定出清晰的目标 分析出相关的关键风险和计划中可以验证和测试 的交付物并不是一件容易的事情 螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段 如第二次迭 代重点是需求 第三次迭代是总体设计和后续设计开发计划等 因此这是和 RUP 提倡的迭代模型是有区别的 RUP的每一次迭代都会包含需求 设计 开发和测 试等各个阶段的活动 迭代的目的在于逐步求精而不是仅仅完成解布模型某一 阶段的工作 原型法增童和迭代模型增量迭代是RUP 统一过程常采用的软件开发 生命周期模型 增和迭代有区别但两者又经常一起使用 所以这里要先解释增 和迭代的
8、概念 假设现在要开发A B C D 四个大的业务功能 每个功能都需要 开发两周的时间 则对于增量方法而言可以将四个功能分两次增量来完成第一个 增量完成 A B 功能 第二次增量完成C D 功能而对于迭代开发来讲则是分两次 迭代来开发 第一次迭代完成 A B C D 四个基本业务功能但不含复杂的业务逻 辑 而第二个功能再逐渐细化补充完整相关的业务逻辑 在第一个月过去后采用 增量开始时候 全部开发完成而 还一点都没有动而采用迭代开发的时候 A B C D 四个的基础功能都已经完成 强调的每次迭代都包含了需求 设计和开发 侧试等各个过程 而且每次迭 代完成后都是一个可以交付的原型 迭代不是并行 在每
9、次迭代过程中仍然要遵 循需求 设计 开发的澡布过程 迭代周期的长度跟项目的周期和规模有很大的 关系 小型项目可以一周一次迭代 而对于大型项目则可以2 4 周一次迭代 如 果项目没有一个很好的架构师 很难规划出每次迭代的内容和要到达的目标 验证相关的交付和产出 因此迭代模型虽然能够很好的满足与用户的交付 需求 的变化 但确是一个很难真正用好的模型 就对风险的消除上 增量和迭代模型都能够很好地控制前期的风险并解 决 迭代模型更多的可以从总体方面去系统地思考问题 从最早就可以给出 相对完善的框架或原型 后期的每次迭代都是针对上次迭代的逐步精化 业界比较标准的增量模型往往要求在软件需求规格说明书全部出
10、来后后续 的设计开发再进行增量 同时每个增量也可以是独立发布的小版本 由于系统的 总体设 计往往对一个系统的架构和可扩展性有重大的影响 因此我们推荐的增 量最好是在架构设计完成后再开始进行增量 这样可以更好地保证系统的健壮 性和可扩展性 原型法 原型一般都不是单独采用的一种生命周期模型 往往会结合澡布和增迭代 等方法一起使用 对于螺旋模型就可以理解为澡布迭代原型风险的一种生命周期 模型 对于迭代开发来讲 每一个迭代周期的产出都可以着做是下个阶段要精化 的原型 而对于澡布模型开发来讲 我们在需求阶段也可以进行界面和操作建模 形成 RUP后和用户做进一部的需求沟通和确认 当你的用户没有信息系统的使
11、用经验 你的系统分析员也没有过多的需求 分析和挖掘经验的时候 需求分析和调研过程则更需要是一个启发式的过程 而 原型则是这种很好的启发式方法 可以快速地挖掘用户需求并达成需求理解上 的一致 否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西 原型可以分为抛弃型的和不抛弃型的 如果原型仅仅是需求阶段方面和用户 沟通画的 DEMO 则这种原型一般都建议抛弃掉 而对于迭代开发来将 每次迭 代的产出都是可以独立运行和包含基础功能的系统 是后续细化的基础 这类 原型一般都不建议抛弃 后期的设计开发也要基于该原型逐渐地进行完善 快速和敏捷开发 我们一般将快速和敏捷开发做为方法论 而很少将其做为一种
12、软件开发生 命周期模型 敏捷的目的是减少萦重和不必要的工件的输出 提高效率 而不是 要我们去挑阶段或过程 不是分析设计都还没有做就去做开发 因此对于添布 增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践 这些实践都是对 传统的生命周期模型很好的补充 对于敏捷方法论在此不再做过多的叙述 结束语 通过以上分析 对于软件工程过程模型的选择 得出以下总结 1 在前期需求明确的情况下 尽量采用浮布模型或改进型的澡布模型在用 户无信息系统使用经验 需求分析人员技能不足情况下 一定要借助原型在不 确定性因素很多 很多东西前面无法计划情况下 尽量采用增量迭代和螺旋模 型在需求不稳定情况下 尽量采用增量迭代模型 2 在资金和成本无法一次到位情况下 可以采用增量模型 软件产品分多 个版本进行发布 对于完全多个独立功能开发可以在需求阶段就分功能并行 但每个功能内都应该遵循添布模型 对于全新系统的开发必须在总体设计完成 后再开始增量或并行 3 对于编码人员经验较少情况下 建议不要采用敏捷或迭代等生命周期模 型 4 增量 迭代和原型可以综合使用 但每一次增量或迭代都必须有明确的 交付和出口准则
