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

软件需求（二） 需求工程与需求工程过程 主要的软件生命周期模型 瀑布模型 快速应用开发(RAD) 模型 快速原型模型 螺旋模型 RUP 迭代式模型 形式化方法 关于选择生命周期模型的总结 需求工程 什么是需求工程 需求工程的内容 需求工程过程 需求工程的涉众人员 需求工程的方法 面向对象的需求工程方法 面向对象的需求工作流 需求过程的改进 第3章 主要软件生命周期模型 瀑布模型 快速应用开发模型（RAD） 快速原型模型 螺旋模型 RUP 迭代式模型 瀑布模型（Waterfall Model） 瀑布模型的优点 客户很容易熟悉该模型。 是一种严格线性的按阶段顺序的、逐步细化的开发模式，消除了软件开发的随意性。 各阶段工作任务明确，要求文档完备性，可方便按阶段设置里程碑，便于项目跟踪 可以严格控制项目进程，使项目管理易于实施。 定义了质量控制过程。运用该过程来确定系统的质量。 瀑布模型的缺点 需求：客户常常难以表达真正的需求，而这种模型却要求严格的阶段性成果，返工困难，变更代价很大 风险：客户要等到开发周期的晚期才能看到程序运行的测试版本，这时若发现大的错误，可能引起客户的惊慌，其后果也可能是灾难性的 效率：因为前后任务的依赖关系，成员不能并行工作，有可能花在等待的时间比开发的时间要长，即所谓的“堵塞状态” 快速应用开发(RAD) 模型 RAD模型的优点 采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。 用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。 工作重点从文档转为构建，所见即所得 。 RAD模型的缺点 如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。 要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。 盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。 对于大型的、但可伸缩的项目，RAD 需要足够的人力资源以创建足够的RAD 组。 RAD 要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统。如果两方中的任何一方没有完成约定，都会导致RAD 项目失败。 采用RAD模型的项目特征 系统可模块化（基于组件的结构）和可缩放。 用户能参与到整个生命周期中。 项目开发周期很短通常约60天。 项目团队熟悉问题领域，能熟练使用开发工具。 快速原型模型 原型——快速建立起来的可以在计算机上运行的程序，通常选取系统中某个关键功能作为原型。 快速原型的基本思想和开发步骤 基本思想 在投入大量的人力、物力之前，在限定的时间内，用最经济的方法构造一个系统原型，使用户尽早看到系统的概貌，在系统原型的实际运行中与用户一起发现问题，提出修改意见，不断完善原型，使它逐步满足用户要求。 开发步骤 明确用户基本信息需求 建立初始原型（集成原则、最小系统原则） 评价原型 修改和完善原型 快速原型的开发工具 第四代技术 可复用软件构件 形式化规约和原型环境 快速原型的类型 抛弃式原型。将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境中。主要解决需求的不确定性，二义性，不完整性等。 进化式原型。会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式系统中。 水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能导航，并未真实实现功能。主要用在用户界面上。 垂直原型也称为结构化原型，实现了一部分功能。主要用在复杂的算法实现上。 快速原型的典型应用 快速原型的评价 这个原型所实现的功能与你所期望的一致吗？ 有遗漏的功能吗？ 有多余的功能吗？ 你能考虑一下这个原型所没有涉及到的一些出错情况吗？ 这些功能导航的逻辑性和完整性如何？ 有更简单的方法来完成这一任务吗？ 快速原型的特点和应用场合 用户积极参与 原型的开发没有严密的阶段性 短期获得测试版本，降低风险 应用于以下场合： 需求含糊，用户不能标识出详细的输入、处理和输出需求 设计方案不明确，开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性 快速原型的不足 降低风险的同时，引入了其他风险： 用户随意无止境的需求变化，因为用户容易产生误解，认为系统很容易被构造和修改 如果采用原型基础上继续构造，由于修补过度，软件质量不易于保证 开发人员为了快速构造原型，可能会采用不合适的操作系统、语言、算法等，造成后期风险，如系统适应性差、维护困难等 快速原型开发的原则 你的项目计划中应包括原型风险。 计划开发多个原型，因为你很少能一次成功。 尽快并且廉价地建立抛弃型原型。 在抛弃型原型中不应含有代码注释、输入数据有效性检查、保护性编码技术，或者错误处理的