《現代软件工程》.pptVIP

2.1 软件工程的生存周期 1. “生存周期”的起源 人类解决复杂问题时普遍采用的一个策略是“各个击破”，也就是对问题进行分解，然后再分别解决各个子问题的策略。 软件工程采用的“生存周期法”，就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后再逐步完成每个阶段的任务。 定义软件生存周期的另一个目的，是提供一个公共的框架，以便软件人员可以用相同的语言，在各自的环境中，开展工作。 这是传统软件工程的基本想法。 2.1 软件工程的生存周期 2. 生存周期划分的原则 各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。 3. “生存周期法”的特点 阶段具有顺序性和依赖性 推迟实现的观点 不到最后阶段，不知道真正的结果 质量保证的观点 每个阶段都必须完成规定的文档 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。 4. 生存周期的划分 传统软件生存周期一般分为：软件定义（问题定义、可行性研究、需求分析）、软件开发（总体设计、详细设计、编码和单元测试、综合测试）、软件维护等三个时期。 生存周期各阶段的工作 生存周期各阶段的工作 2.2 软件开发过程模型—瀑布模型 一、瀑布模型（waterfall Model) 传统的生命周期模型 70年由Royce提出 典型瀑布模型具有顺序性和依赖性 2.2 软件开发过程模型—瀑布模型 瀑布模型的特征 从上一项活动中接受该项活动的工作成果（工作产品），作为输入。 利用这一输入实施该项活动应完成的内容 给出该项活动的工作成果，作为输出传给下一项活动 对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。 瀑布模型的优点： 1.强调开发的阶段性； 2.强调早期计划及需求调查； 3.强调产品测试。 瀑布模型与全生命周期——另一种看法 2.2 软件开发过程模型—瀑布模型 瀑布模型的缺点： 从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。 特别是瀑布模型过于依赖早期进行的唯一一次需求调查，不能适应需求的变化； 软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。特别是由于瀑布模型是单一流程，开发中的经验教训不能反馈应用于本产品的过程。 思考题： 1、我们的日常生活中，有哪些活动是符合瀑布模型的？ 2、为什么我们的小型开发团队连瀑布模型都不能坚持做到？客观因素是什么？ 3、瀑布模型的现实实用价值在哪里？ 2.2 软件开发过程模型—瀑布模型 软件的变更、维护往往经历软件生存期的各个阶段，因此，瀑布模型也有反馈，构成生存期循环。 下图：上下阶段间循环： 2.2 软件开发过程模型—瀑布模型 具有维护阶段循环的软件生存期的瀑布模型 2.3 软件开发过程模型——原型模型 二、原型（迭代）模型 1. 基本思想 在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本-原型，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。 经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。 原型：一个真实的可执行模型，它实现了系统的若干基本功能。 原型法：不断地运行系统“原型”来进行启发、揭示和判断的系统开发方法。 2.3 软件开发过程模型——原型模型 2.原型（迭代）模型的来源： 利用相应原型开发工具快速开发 已经完成核心产品开发和试点，进行本地化、客户化的过程，称为二次开发（迭代和演化） 2.3 软件开发过程模型——原型模型 3. 快速建立原型的目的，是获取需求 2.3 软件开发过程模型——原型模型 在“需求分析” 阶段，开发团队和用户一起为想象中的系统的某些主要部分，定义需求和规格说明，并由开发团队在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括哪些为满足用户需求的必要属性。 该原型可用来帮助分析和设计工作，而不是一个软件产品。 2.3 软件开发过程模型——原型模型 通过演示原型，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发团队重新定义需求。 该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。 在这期间，用户和开发团队都不要为程序算法或设计技巧等枝节问题分心，而是要确定开