《软件工程基础》第2章-软件开发过程.ppt

1 38 第2章软件开发过程 2 1软件过程2 2常见的软件过程模型2 3软件过程的新发展 2 38 第2章软件开发过程 2 1软件过程2 1 1软件过程的概念与理论基础2 1 2软件过程讨论的主要内容2 2常见的软件过程模型2 3软件过程的新发展 3 38 2 1 1软件过程的概念与理论基础 软件过程的概念软件过程模型的理论基础 4 38 软件过程的概念 软件过程是为了获得高质量软件所需要完成的一系列任务的框架 它规定了完成各项任务的工作步骤 在完成开发任务时必须进行一系列开发活动 并且使用适当的资源 在过程结束时将把输入转化为输出 因此 ISO9000把过程定义为 使用资源将输入转化为输出的活动所构成的系统 过程定义了运用方法的顺序 应该交付的文档资料 为保证软件质量和协调变化所需要采取的管理措施 以及标志软件开发各个阶段任务完成的里程碑 5 38 软件过程模型及理论基础 通常使用生命周期模型简洁地描述软件过程 建立软件开发过程模型的理论基础是软件生命周期理论和相关的软件工程原则 因此 软件过程模型又称软件生命周期模型 SoftwareLifeCycleModel 其核心思想主张把软件过程划分成若干个阶段 每个阶段所包含的活动内容和性质具有 高内聚 低藕合 的特征 这样有助于简化问题 有助于验证阶段性的工作成果 有助于对软件工程的施工与管理 生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序 因此 也称为过程模型 软件过程模型是对软件开发活动进行有效地组织 协调 管理与控制的一种策略过程模型化是为了便于理解和操作 6 38 SoftwareLifeCycleModel 7 38 2 1 2软件过程讨论的主要内容 软件过程讨论的主要内容包括软件过程模型 项目软件过程定义 软件过程裁剪 软件过程改进及软件能力成熟度的评价等内容 软件过程模型给出了适合不同软件项目的软件过程活动组织的参考框架 对不同的软件组织来讲 典型软件过程模型仅仅是理论参考框架 为了不断提高软件能力 软件组织 企业与团队 应该不断积累经验 针对不同的软件项目和软件组织自身的特点 在软件过程定义 软件过程裁剪 软件过程改进等方面不断努力和提高 软件能力成熟度模型 CMM 是对一个软件组织的软件能力成熟度进行评价的框架模型 它同时对软件组织不断提高软件能力具有的一定的促进作用 8 38 2 2常见的软件过程模型 软件过程包括软件开发过程和软件维护过程 实践中 人们基于软件工程方法论和软件项目特点总结出了不同的软件过程模型 好的过程模型吸收了成功的软件工程经验和有效的软件工程原则 因此参考软件过程模型框架组织软件项目有利于提高工作效率 把握开发质量 总体上可以提高软件项目的成功率 为获得高质量的软件产品 软件过程必须科学 有效 没有一个适用于所有软件项目的任务集合 因此 科学 有效的软件过程应该定义一组适合于所承担的项目特点的任务集合 通常 一个任务集合包括一组软件工程任务 里程碑和应该交付的产品 9 38 典型的过程模型 实际的软件开发活动中 应该项目的特点来划分阶段 但是 下面讲述典型的软件过程模型时并不是针对某个特定项目讲的 因此只能使用 通用的 阶段划分方法 由于瀑布模型与快速原型模型的主要区别是获取用户需求的方法不同 因此 下面在介绍生命周期模型时把 规格说明 作为一个阶段独立出来 此外 问题定义和可行性研究的主要任务都是概括地了解用户的需求 为了简洁地描述软件过程 把它们都归并到需求分析中去了 同样 为了简洁起见 把总体设计和详细设计合并在一起称为 设计 10 38 1 4 1瀑布模型 在20世纪80年代之前 瀑布模型一直是惟一被广泛采用的生命周期模型 现在它仍然是软件工程中应用得最广泛的过程模型 传统软件工程方法学的软件过程 基本上可以用瀑布模型来描述 图1 2所示为传统的瀑布模型 按照传统的瀑布模型开发软件 有下述的几个特点 11 38 图1 2传统的瀑布模型 12 38 1 阶段间具有顺序性和依赖性这个特点有两重含义 必须等前一阶段的工作完成之后 才能开始后一阶段的工作 前一阶段的输出文档就是后一阶段的输入文档 因此 只有前一阶段的输出文档正确 后一阶段的工作才能获得正确的结果 2 推迟实现的观点对于规模较大的软件项目来说 往往编码开始得越早最终完成开发工作所需要的时间反而越长 这是因为 前面阶段的工作没做或做得不扎实 过早地考虑进行程序实现 往往导致大量返工 有时甚至发生无法弥补的问题 带来灾难性后果 13 38 瀑布模型在编码之前设置了系统分析与系统设计的各个阶段 分析与设计阶段的基本任务规定 在这两个阶段主要考虑目标系统的逻辑模型 不涉及软件的物理实现 清楚地区分逻辑设计与物理设计 尽可能推迟程序的物理实现 是按照瀑布模型开发软件的一条重要的指导思想 3 质量保证的观点软件工程的基本目标是优质 高产 为了保证所开发的软件的质量 在瀑布模型的每个阶段都应坚持两个重要做法 14 38 1 每个阶段都必须完成规定的文档 没有交出合格的文档就是没有完成该阶段的任务 完整 准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介 也是运行时期对软件进行维护的重要依据 2 每个阶段结束前都要对所完成的文档进行评审 以便尽早发现问题 改正错误 事实上 越是早期阶段犯下的错误 暴露出来的时间就越晚 排除故障改正错误所需付出的代价也越高 因此 及时审查 是保证软件质量 降低软件成本的重要措施 15 38 传统的瀑布模型过于理想化了 事实上 人在工作过程中不可能不犯错误 在设计阶段可能发现规格说明文档中的错误 而设计上的缺陷或错误可能在实现过程中显现出来 在综合测试阶段将发现需求分析 设计或编码阶段的许多错误 因此 实际的瀑布模型是带 反馈环 的 如图1 3所示 图中实线箭头表示开发过程 虚线箭头表示维护过程 当在后面阶段发现前面阶段的错误时 需要沿图中左侧的反馈线返回前面的阶段 修正前面阶段的产品之后再回来继续完成后面阶段的任务 16 38 图1 3实际的瀑布模型 17 38 瀑布模型有许多优点 可强迫开发人员采用规范的方法 例如 结构化技术 严格地规定了每个阶段必须提交的文档 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证 各个阶段产生的文档是维护软件产品时必不可少的 没有文档的软件几乎是不可能维护的 遵守瀑布模型的文档约束 将使软件维护变得比较容易一些 由于绝大部分软件预算都花费在软件维护上 因此 使软件变得比较容易维护就能显著降低软件预算 可以说 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型 18 38 但是 瀑布模型是由文档驱动的 这个事实也是它的一个主要缺点 在可运行的软件产品交付给用户之前 用户只能通过文档来了解产品是什么样的 但是 仅仅通过写在纸上的静态的规格说明 很难全面正确地认识动态的软件产品 而且事实证明 一旦一个用户开始使用一个软件 在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化 这就使得最初提出的需求变得不完全适用了 事实上 要求用户不经过实践就提出完整准确的需求 在许多情况下都是不切实际的 总之 由于瀑布模型几乎完全依赖于书面的规格说明 很可能导致最终开发出的软件产品不能真正满足用户的需要 19 38 1 4 2快速原型模型 所谓快速原型是快速建立起来的可以在计算机上运行的程序 它所能完成的功能往往是最终产品能完成的功能的一个子集 如图1 4所示 图中实线箭头表示开发过程 虚线箭头表示维护过程 快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统 让用户在计算机上试用它 通过实践来了解目标系统的概貌 20 38 通常 用户试用原型系统之后会提出许多修改意见 开发人员按照用户的意见快速地修改原型系统 然后再次请用户试用 一旦用户认为这个原型系统确实能做他们所需要的工作 开发人员便可据此书写规格说明文档 根据这份文档开发出的软件可以满足用户的真实需求 从图1 4可以看出 快速原型模型是不带反馈环的 这正是这种过程模型的主要优点 软件产品的开发基本上是线性顺序进行的 能做到基本上线性顺序开发的主要原因如下 21 38 图1 4快速原型模型 22 38 1 原型系统已经通过与用户交互而得到验证 据此产生的规格说明文档正确地描述了用户需求 因此 在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工 2 开发人员通过建立原型系统已经学到了许多东西 至少知道了 系统不应该做什么 以及怎样不去做不该做的事情 因此 在设计和编码阶段发生错误的可能性也比较小 这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性 软件产品一旦交付给用户使用之后 维护便开始了 根据所需完成的维护工作种类的不同 可能需要返回到需求分析 规格说明 设计或编码等不同阶段 如图1 4中虚线箭头所示 23 38 快速原型的本质是 快速 开发人员应该尽可能快地建造出原型系统 以加速软件开发过程 节约软件开发成本 原型的用途是获知用户的真正需求 一旦需求确定了 原型将被抛弃 因此 原型系统的内部结构并不重要 重要的是 必须迅速地构建原型然后根据用户意见迅速地修改原型 UNIXShell和超文本都是广泛使用的快速原型语言 最近的趋势是 广泛地使用第四代语言 4GL 构建快速原型 当快速原型的某个部分是利用软件工具由计算机自动生成的时候 可以把这部分用到最终的软件产品中 24 38 1 4 3增量模型 增量模型也称为渐增模型 如图1 5所示 使用增量模型开发软件时 把软件产品作为一系列的增量构件来设计 编码 集成和测试 每个构件由多个相互作用的模块构成 并且能够完成特定的功能 使用增量模型时 第一个增量构件往往实现软件的基本需求 提供最核心的功能 第二个增量构件提供更完善的编辑和文档生成功能 第三个增量构件实现拼写和语法检查功能 第四个增量构件完成高级的页面排版功能 25 38 把软件产品分解成增量构件时 应该使构件的规模适中 规模过大或过小都不好 最佳分解方法因软件产品特点和开发人员的习惯而异 分解时惟一必须遵守的约束条件是 当把新构件集成到现有软件中时 所形成的产品必须是可测试的 采用瀑布模型或快速原型模型开发软件时 目标都是一次就把一个满足所有需求的产品提交给用户 增量模型则与之相反 它分批地逐步向用户提交产品 整个软件产品被分解成许多个增量构件 开发人员一个构件接一个构件地向用户提交产品 从第一个构件交付之日起 用户就能做一些有用的工作 显然 能在较短时间内向用户提交可完成部分工作的产品 是增量模型的一个优点 26 38 图1 5增量模型 27 38 增量模型的另一个优点是 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品 从而减少一个全新的软件可能给客户组织带来的冲击 使用增量模型的困难是 在把每个新的增量构件集成到现有软件体系结构中时 必须不破坏原来已经开发出的产品 此外 必须把软件的体系结构设计得便于按这种方式进行扩充 向现有产品中加入新构件的过程必须简单 方便 也就是说 软件体系结构必须是开放的 但是 从长远观点看 具有开放结构的软件拥有真正的优势 这样的软件的可维护性明显好于封闭结构的软件 28 38 因此 尽管采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计 但在设计阶段多付出的劳动将在维护阶段获得回报 如果一个设计非常灵活而且足够开放 足以支持增量模型 那么 这样的设计将允许在不破坏产品的情况下进行维护 事实上 使用增量模型时开发软件和扩充软件功能 完善性维护 并没有本质区别 都是向现有产品中加入新构件的过程 29 38 从某种意义上说 增量模型本身是自相矛盾的 它一方面要求开发人员把软件看作一个整体 另一方面又要求开发人员把软件看作构件序列 每个构件本质上都独立于另一个构件 除非开发人员有足够的技术能力协调好这一明显的矛盾 否则用增量模型开发出的产品可能并不令人满意 30 38 图1 5所示的增量模型表明 必须在开始实现各个构件之前就全部完成需求分析 规格说明和概要设计的工作 由于在开始构建第一个构件之前已经有了总体设计 因此风险较小 图1 6描绘了一种风险更大的增量模型 一旦确定了用户需求之后 就着手拟定第一个构件的规格说明文档 完成后规格说明组将转向第二个构件的规格说明 与此同时设计组开始设计第一个构件 用这种方式开发软件 不同的构件将并行地构建 因此有可能加快工程进度 但是 使用这种方法将冒构件无法集成到一起的风险 除非密切地监控整个开发过程 否则整个工程可能毁于一旦 31 38 图1 6风险更大的增量模型 32 38 1 4 4螺旋模型 软件风险是任何软件开发项目中都普遍存在的实际问题 项目越大 软件越复杂 承担该项目所冒的风险也越大 软件风险可能在不同程度上损害软件开发过程和软件产品质量 因此 在软件开发过程中必须及时识别和分析风险 并且采取适当措施以消除或减少风险的危害 33 38 构建原型是一种能使某些类型的风险降至最低的方法 正如1 4 2节所述 为了降低交付给用户的产品不能满足用户需要的风险 一种行之有效的方法是在需求分析阶段快速地构建一个原型 在后续的阶段中也可以通过构造适当的原型来降低某些技术风险 当然 原型并不能 包治百病 对于某些类型的风险 原型方法是无能为力的 螺旋模型的基本思想是 使用原型及其他方法来尽量降低风险 理解这种模型的一个简便方法 是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型 如图1 7所示 完整的螺旋模型如图1 8所示 34 38 图1 7简化的螺旋模型 35 38 图1 8完整的螺旋模型 36 38 螺旋模型有许多优点 对可选方案和约束条件的强调有利于已有软件的重用 也有助于把软件质量作为软件开发的一个重要目标 减少了过多测试 浪费资金 或测试不足 产品故障多 所带来的风险 更重要的是 在螺旋模型中维护只是模型的另一个周期 在维护和开发之间并没有本质区别 螺旋模型主要适用于内部开发的大规模软件项目 如果进行风险分析的费用接近整个项目的经费预算 则风险分析是不可行的 事实上 项目越大 风险也越大 因此 进行风险分析的必要性也越大 此外 只有内部开发的项目 才能在风险过大时方便地中止项目 37 38 螺旋模型的主要优势在于 它是风险驱动的 但是 这也可能是它的一个弱点 除非软件开发人员具有丰富的风险评估经验和这方面的专门知识 否则将出现真正的风险 当项目实际上正在走向灾难时 开发人员可能还认为一切正常