软件需求讲义-第二部分.pptVIP

第二部分 需求工程与需求工程过程 穆静 mujing@xatu.edu.cn 就理论而言，理论和实践并无差异。但真付诸实行，差异即开始显现。 ——Jan L.A. van de Snepscheut 需求工程与需求工程过程 软件需求与产品生命周期 瀑布模型 快速应用开发(RAD) 模型 螺旋模型 RUP 迭代式模型 形式化方法 关于选择生命周期模型的总结 需求工程 什么是需求工程 需求工程的内容 需求工程过程 需求工程的涉众人员 需求工程的方法 面向对象的需求工程方法 面向对象的需求工作流 需求过程的改进 第3章 主要软件生命周期模型 软件产品从相关概念提出的那一刻开始，就进入了软件生命周期。 定义：在经历了需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，知道最后逐渐消亡，------称为软件生命周期（LIFE CYCLE MODEL） 是一种路线图，指引涉众的方向，并指明大家的各自位置。 几种生命周期模型 瀑布模型 快速应用开发模型（RAD） 螺旋模型 RUP 迭代式模型 3.1.瀑布模型（Waterfall Model） 瀑布模型提出了软件开发的系统化的、顺序的方法。 瀑布模型的活动 系统级需求?分析-设计-编码-测试和维护 系统工程和建模：建立所用系统级的需求，然后将其中某个自己分配给软件。 软件需求分析：分析开发的软件的本质，分析员了解软件的应用领域，需求的功能、行为、性能和接口。 设计：所做的工作：设计数据结构、软件体系结构、界面表示和过程算法的实现。 实现：代码实现的过程。 瀑布模型的活动 测试：排除错误。保证软件能正常运行。 维护：遇到问题，修改；用户提出新功能，增加。 瀑布模型的优点 客户很容易熟悉该模型。 以有序的方式解决复杂的问题，易于理解，目标简单—完成所需要的活动（严格线性的）。 可以严格控制项目进程，使项目管理易于实施。 方便按阶段设置里程碑，便于项目跟踪。 定义了质量控制过程。运用该过程来确定系统的质量。 自上而下，独立的顺序阶段组成，分阶段评审。 瀑布模型的缺点 （一） 它有内在的线性顺序，尝试重新使用两个或更多阶段开改正一个问题或缺陷，会导致成本上升和进度安排上工作量的急剧增加。 它不能准确反映软件开发中解决问题的特点。各阶段严格与活动一致，而不管开发团队的实际工作如何。 它的状态和进展容易给人以错觉，实际工作中“完成50%的工作”对项目经理来说并无实际意义。 最后集成造成较大的风险。由于过程中的线性传递特点，常常在集成中出现问题时就已为时太晚。最后会发现前期未发现的错误或设计缺陷，由于没有时间恢复而增加了风险。 它是文档驱动的，文档工作量非常大。 当瀑布模型必须面对范围管理的挑战时，就显得力不从心了。如果把这个模型应用于大范围的项目时，会出现最后期限到来时，没有任何实质性的成果，系统集成和测试被迫推迟或放弃，在前期需求规格说明、设计和编码中可观的投入未能产生有效的成果，没有任何可提交的产品。 瀑布模型的缺点 （二） 实际的项目很少按照该模型给出的顺序进行。虽然瀑布模型能够容许迭代，但却是间接的。结果，在项目组的开发过程中变化可能引起混乱。 用户常常难以清楚地给出所有需求，而瀑布模型却要求如此，它还不能接受在许多项目的开始阶段自然存在的不确定性。 开发者常常被不必要地耽搁。在对实际项目的分析中，Bradac［BRA ,1994］发现传统生命周期的线性特征会导致“阻塞状态”，其中某些项目组成员不得不等待组内其他成员先完成其依赖的任务。事实上，花在等待上的时间可能会超过花在开发工作上的时间。阻塞状态经常发生在线性顺序过程的开始和结束。 采用瀑布模型需要具备的项目特征 在系统开发前要对需求有完整、全面、清晰的了解。 上述需求不存在隐含的不可克服的风险。 需求变更不能过于频繁。 不同涉众的需求互相兼容，不存在明显的冲突。 开发团队掌握了解决需求问题的有效方法。 开发期限允许分阶段地串行工作。 3.2.快速应用开发(RAD) 模型 RAD是一个线性顺序的软件开发模型，强调极短的开发周期。 RAD活动 用户参与到生命周期的各个阶段 需求计划阶段：使用联合需求计划（JRP）收集需求信息，以结构化的方法（SA）讨论业务问题； 用户描述:采用联合应用设计（JAD）管理用户的参与； 构建阶段：进行详细设计、编码和测试及发布给客户； 结束：验收，系统安装和培训 RAD模型的优点 采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。 用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。 工作重点从文档转为构建，所见即所得 。 RAD模型的缺点 如果用户不能持续地参与整个生命周期中，最