02软件开发过程(精品·公开课件).ppt

软件开发过程 第2章 知识点 2.1.1 软件过程的概念与理论基础 Software Life Cycle Model 知识点 边改边做模型 主要问题： 缺少分析与设计环节，软件的结构将随着不断修改越来越糟； 忽略需求环节，给软件开发带来很大的风险； 没有考虑测试和程序的可维护性，缺少完整的文档，软件的维护十分困难 瀑布模型 (Waterfall model) 快速原型模型（Rapid Prototype Model） 对所开发领域较熟悉，且有快速的原型开发工具。 项目招投标时，已有类似产品模型。 进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。 增量模型（Incremental Model） 基本思想：要开发一个大的软件系统，先开发其中的一个核心模块或子系统，然后再开发其他模块或子系统，这样一个个的增加，就像搭积木一样，直到整个系统开发完毕为止。 采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品——非整体开发。 有何风险？ 软件开发过程中，需求可能发生变化，用户接受分阶段交付 分析设计人员对应用领域不熟悉，难以一步到位 项目风险较高 用户可以参与到整个软件开发过程 使用面向对象语言或第四代语言（非过程化语言） 软件公司自己已有较好的类库、构件库 螺旋模型（Spiral Model） 简化的螺旋模型：瀑布模型+风险分析 每个阶段之前 每个阶段之后 螺旋模型的优点 螺旋模型主要适用于内部开发的大规模软件项目。 喷泉模型（Fountain Model） 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间； 适应于面向对象的软件开发过程。 知识点 2.3.1 敏捷过程与极限编程 为了使软件开发团队具有高效工作和快速响应变化的能力，17位著名的软件专家于2001年2月联合起草了敏捷软件开发宣言。 我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也具有价值， 但我们认为左项具有更大的价值。 12条原则： 1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5．围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7．工作的软件是首要的进度度量标准。 8．敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9．不断地关注优秀的技能和好的设计会增强敏捷能力。 10．简单——使未完成的工作最大化的艺术——是根本的。 11．最好的构架、需求和设计出自于自组织的团队。 12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 极限编程（eXtreme Programming,XP）是敏捷过程中最负盛名的一个，“极限”指把好的开发实践运用到极致。 极限编程的有效实践： 客户作为开发团队的成员 使用用户素材 短交付周期 验收测试 结对编程 测试驱动开发 集体所有 持续集成 可持续的开发速度 开放的工作空间 及时调整计划 简单的设计 重构 使用隐喻 2.3.2 统一过程模型RUP RUP(Rational Unified Process，Rational统一过程)，是由Rational软件公司推出的一种完整且完美的软件过程。 生存周期分为4个阶段： 初始、精化、构建、移交 降低了在一个增量上的开支风险。 降低了产品无法按照既定进度进入市场的风险。 加快了整个开发工作的进度。 迭代过程这种模式使适应需求的变化会更容易些。 极易让人误解是重型的过程，实施推广有一定难度。 在质量管理方面，每次迭代进行系统集成、系统测试，达到对软件质量的持续验证。每次系统测试，需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户（包括内部客户、外部客户）进行评价，通过演示操作等方式，评价该次迭代是否达到预定的目标，并以此为依据来制定下一次迭代的目标。 在其他方面，每次迭代成果须进行配置管理，版本控制很重要。在整个迭代过程中风险无处不