软件需求讲义第二部分解析.ppt

软件需求（二） 周勇 yzhou@sei.ecnu.edu.cn 就理论而言，理论和实践并无差异。但真付诸实行，差异即开始显现。 ——Jan L.A. van de Snepscheut 需求工程与需求工程过程 软件需求与产品生命周期 瀑布模型 快速应用开发(RAD) 模型 螺旋模型 RUP 迭代式模型 形式化方法 关于选择生命周期模型的总结 需求工程 什么是需求工程 需求工程的内容 需求工程过程 需求工程的涉众人员 需求工程的方法 面向对象的需求工程方法 面向对象的需求工作流 需求过程的改进 第3章 主要软件生命周期模型 瀑布模型 快速应用开发模型（RAD） 螺旋模型 RUP 迭代式模型 瀑布模型（Waterfall Model） 瀑布模型的优点 客户很容易熟悉该模型。 以有序的方式解决复杂的问题，易于理解，目标简单—完成所需要的活动。 可以严格控制项目进程，使项目管理易于实施。 方便按阶段设置里程碑，便于项目跟踪。 定义了质量控制过程。运用该过程来确定系统的质量。 瀑布模型的缺点 （一） 它有内在的线性顺序，尝试重新使用两个或更多阶段开改正一个问题或缺陷，会导致成本上升和进度安排上工作量的急剧增加。 它不能准确反映软件开发中解决问题的特点。各阶段严格与活动一致，而不管开发团队的实际工作如何。 它的状态和进展容易给人以错觉，实际工作中“完成50%的工作”对项目经理来说并无实际意义。 最后集成造成较大的风险。由于过程中的线性传递特点，常常在集成中出现问题时就已为时太晚。最后会发现前期未发现的错误或设计缺陷，由于没有时间恢复而增加了风险。 它是文档驱动的，文档工作量非常大。 当瀑布模型必须面对范围管理的挑战时，就显得力不从心了。如果把这个模型应用于大范围的项目时，会出现最后期限到来时，没有任何实质性的成果，系统集成和测试被迫推迟或放弃，在前期需求规格说明、设计和编码中可观的投入未能产生有效的成果，没有任何可提交的产品。 瀑布模型的缺点 （二） 实际的项目很少按照该模型给出的顺序进行。虽然瀑布模型能够容许迭代，但却是间接的。结果，在项目组的开发过程中变化可能引起混乱。 用户常常难以清楚地给出所有需求，而瀑布模型却要求如此，它还不能接受在许多项目的开始阶段自然存在的不确定性。 开发者常常被不必要地耽搁。在对实际项目的分析中，Bradac［BRA ,1994］发现传统生命周期的线性特征会导致“阻塞状态”，其中某些项目组成员不得不等待组内其他成员先完成其依赖的任务。事实上，花在等待上的时间可能会超过花在开发工作上的时间。阻塞状态经常发生在线性顺序过程的开始和结束。 采用瀑布模型需要具备的项目特征 在系统开发前要对需求有完整、全面、清晰的了解。 上述需求不存在隐含的不可克服的风险。 需求变更不能过于频繁。 不同涉众的需求互相兼容，不存在明显的冲突。 开发团队掌握了解决需求问题的有效方法。 开发期限允许分阶段地串行工作。 快速应用开发(RAD) 模型 RAD模型的优点 采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。 用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。 工作重点从文档转为构建，所见即所得 。 RAD模型的缺点 如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。 要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。 盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。 对于大型的、但可伸缩的项目，RAD 需要足够的人力资源以创建足够的RAD 组。 RAD 要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统。如果两方中的任何一方没有完成约定，都会导致RAD 项目失败。 采用RAD模型的项目特征 系统可模块化（基于组件的结构）和可缩放。 用户能参与到整个生命周期中。 项目开发周期很短通常约60天。 项目团队熟悉问题领域，能熟练使用开发工具。 螺旋模型 螺旋模型的优点 螺旋模型的缺点 如果项目本身是低风险的或者规模较小，采用该模型可能产生昂贵的成本。每一次螺旋结束后评估风险的时间及人工耗费都较大。 模型本身比较复杂，开发人员和用户难于掌握。 大量的中间阶段会产生额外的内外部文档。 难以定义每阶段的目标。 采用螺旋模型的项目特征 适用于大型项目；更适用于内部开发（指没有外包的开发内容）。 用于新功能、新产品或需要采用新技术时。 收益不确定，项目不能确保成功时。 用户不能确定其需求或需求很复杂时。 统一软件过程 （RUP） RUP的核心概念 RUP的核心工作流（一） 6个核心过程工作流 商业建模（Business Mod