软件工程01-概论幻灯片.ppt

软件过程 微软过程 Microsoft拥有自己的软件开发过程 微软过程准则 项目计划应该兼顾未来的不确定因素 用有效的风险管理来减少不确定因素 经常生成并快速地测试软件的过度版本 采用快速循环、迭代的开发过程 用创造性的工作来平衡产品特性和产品成本 项目进度表应该具有较高的稳定性和权威性 使用小型项目组并发地完成工作 个人成果，妥善保存，请勿传播 软件过程 微软过程 微软过程准则 在项目早期把软件配置基线化，项目后期则冻结产品 使用原型验证概念，对项目进行早期论证 把零缺陷作为追逐的目标 里程碑评审的目的是改进工作，切忌相互指责 个人成果，妥善保存，请勿传播 软件过程 微软过程 微软软件生命周期 个人成果，妥善保存，请勿传播 软件过程 微软过程 微软过程模型 个人成果，妥善保存，请勿传播 个人成果，妥善保存，请勿传播 本章结束 － 下一章节导读：“可行性研究” * * * * * 个人成果，妥善保存，请勿传播 软件过程 是为获得高质量软件所需完成的一系列任务的框架，他规定了完成各项任务的工作步骤 过程定义了 运用方法的顺序、应交付的文档、所需采取的管理措施，以及标示阶段任务的里程碑 通常使用生命周期模型简洁地描述软件过程 软件过程 个人成果，妥善保存，请勿传播 瀑布模型 在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型 现在仍是软件工程中应用最广泛的过程模型 瀑布模型特点 阶段间具有顺序性和依赖性 推迟实现的观点 清楚地区分逻辑设计与物理设计 软件过程 个人成果，妥善保存，请勿传播 可行性研究 需求分析 概要设计 详细设计 实 现 组装测试 确认测试 使用与维护 软件过程 个人成果，妥善保存，请勿传播 传统的瀑布模型 软件过程 瀑布模型特点 质量保证的观点：每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务 每个阶段结束前都要对所完成的文档进行评审 个人成果，妥善保存，请勿传播 实际的瀑布模型 实际的瀑布模型是带“反馈环”的 缺点 缺乏灵活性 在交付之前，缺乏可见性 软件过程 个人成果，妥善保存，请勿传播 瀑布模型的优缺点 瀑布模型的优点： 可强迫开发人员采用规范的方法； 严格地规定了每个阶段必须提交的文档； 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型 瀑布模型的缺点： “瀑布模型是由文档驱动的”，缺乏灵活性： 仅通过静态的规格说明很难全面正确地认识动态的软件产品。 要求用户不经过实践就提出完整准确的需求是不切实际的。 由于瀑布模型完全依赖于书面的规格说明，很可能导致最终开发出的软件不能真正满足用户的需要。 个人成果，妥善保存，请勿传播 快速原型模型 快速原型 是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。 个人成果，妥善保存，请勿传播 快速原型模型 软件过程 快速原型的本质是“快速” 采用软件重用技术 在算法的时/空开销方面也可以让步 原型应充分展示软件的可见部分 个人成果，妥善保存，请勿传播 优点： 有助于获取用户需求，加强对需求的理解 尽早发现软件中的错误 支持需求的动态变化 不足： 不能支持风险分析 适合于需求动态变化，事先难以确定系统 软件过程 个人成果，妥善保存，请勿传播 增量模型也称为渐增模型 使用增量模型开发软件时，把产品作为一系列的增量构件来设计、编码、集成和测试。 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。 使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。 软件过程 个人成果，妥善保存，请勿传播 增量模型 软件过程 个人成果，妥善保存，请勿传播 风险更大的增量模型 （并行地构造部件） 软件过程 个人成果，妥善保存，请勿传播 软件过程 增量模型的优点： 能在较短的时间内向用户提交可完成部分功能的产品 逐步增加产品功能可以使用户有较充裕的时间学习和适应 困难： 在把每个新的增量构件集成到现有的软件体系结构中时，必须不破坏原来已经开发的产品 软件体系结构必须是开放的 本身具有矛盾性 一方面要求开发人员把软件看作一个整体 另一方面要求开发人员把软件看作构件序列，构件间彼此独立 个人成果，妥善保存，请勿传播 螺旋模型 螺旋模型是瀑布模型、原型模型的有机结合，同时增加了风险分析 软件过程 个人成果，妥善保存，请勿传播 简化的螺旋模型 软件过程 个人成果，妥善保存，请勿传播 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即： 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制 风险分析──分析所选方案，考虑如何识别和消除风险 实施工程──实施软件开发 客户评估──