[计算机软件及应用]第2章 软件开发过程管理.pptVIP

喷泉模型 7 2.4 软件开发过程模型 2.4.7 软件包模型 1. 软件包模型的开发步骤 （1）需求分析和软件包标识。 （2）结构定义和软件包选择。 （3）系统集成和测试。 （4）技术修改和系统维护。 7 2.4 软件开发过程模型 2.4.7 软件包模型 2. 软件包模型的优缺点和适用情况 7 2.4 软件开发过程模型 2.4.8 遗留系统维护模型 主要用于纠错性维护或者稍加改进一个运行系统。 7 2.4 软件开发过程模型 2.4.8 遗留系统维护模型 维护 进一步 开发 程序使用 系统测试 系统组装 构件设计 系统设计 分析 需求分析与可行性研究 软件平台 真实世界 基于复用的面向对象软件生命周期“喷泉”模型 喷泉模型中每个活动阶段用一个圆圈表示。说明每个活动相对独立地完成一定的任务。圆圈之间的重叠显示了面向对象 方法各阶段是比较平稳地过渡且反复进行的。每个圆圈中的一对向下的小箭头表示各个活动均可将信息返回到前面的活动，这又体现了原型化的思想。 从图中可以看出，喷泉模型有以下特征： ·各项活动的步进性 步进性指明了活动的先后顺序，强调软件的增量开发，它体现了设计一点，开发一点的原则。 ·覆盖性 覆盖性指明了能同时进行的活动，反映了软件开发的并行性。不与其它任何活动发生覆盖的活动（如系统测试），只有在以前的活动完成之后方能进行。 ·反复性 喷泉的每次“喷射”都是对系统的一次提炼，一次逼近，也就是说开发过程的任何点只要需要都可以反复到它以前的任何活动继续步进地开发，这又反映软件开发的原型化思想 7 2.5 软件开发过程模型选择 目前，大多数软件开发项目都采用瀑布模型作为规范化开发的基础，主要原因如下： （1）软件开发单位的软件工程工作尚处于初级阶段，软件开发人员和管理人员既缺乏经验，又无历史数据可供借鉴，因此，需要一种简单易行的组织方式。 （2）结构化方法学是系统工程中最成熟的方法学，目前大多数软件开发都以结构化开发方法学为基础。在与结构化方法学相适应的软件开发过程模型中，瀑布模型最为简单实用，行之有效。 （3）有关软件开发的现行国家标准和国家军用标准都是以瀑布模型为基础制定的。 7 2.5 软件开发过程模型选择 选择开发过程模型时，一般应遵循下述原则： 开发过程模型应与软件项目的特点相适应； 开发过程模型应与采用的软件开发技术相适应； 开发过程模型应满足整个应用系统的开发进度要求； 开发过程模型应有助于控制和消除软件开发风险； 开发过程模型应有可用的计算机辅助工具的支持； 开发过程模型应与用户和软件开发人员的知识和技能水平相适应； 开发过程模型应有利于软件开发的管理和控制。 7 2.6 传统开发过程存在的问题 传统开发过程基本是单纯的技术实施过程，既没有定义必要的项目过程管理，也没有定义技术过程如何与项目管理相结合。这种软件开发过程模式产生的结果很难预测，极容易造成管理上的失控。 7 2.6 传统开发过程存在的问题 2.6.1 管理方面 1. 忽视软件过程管理 （1）没有规范和切实可行的管理体系。 （2）不能真正区分技术实施和过程管理的工作任务。 2. 计划过程粗略，执行控制不力 （1）项目管理计划粗略。 （2）开发计划不充分。 3. 缺乏需求基准 4. 缺乏成本控制体系和过程 5. 质量保证过程薄弱 （1）开发过程不规范。 （2）测试过程不规范。 （3）缺少SQA相关质量保证过程。 7 2.6 传统开发过程存在的问题 2.6.2 技术方面 1. 需求分析 问题1：客户并不知道自己需要什么。 问题2：需求在项目进行过程中发生改变。 2. 软件设计 （1）僵化──设计难以改变。 （2）脆弱性──设计易于遭到破坏。 （3）牢固性──设计难以重用。 （4）粘滞性──难以做正确的事情。 （5）不必要的复杂性──过度设计。 7 2.6 传统开发过程存在的问题 2.6.2 技术方面 3. 代码编写 （1）程序员各自为战，缺乏分工合作。 （2）对于编程语言及工具不能准确掌握。 （3）不必要的重复。 （4）晦涩混乱的表达。 4. 测试 （1）认为规范化软件测试是增加项目成本。 （2）期望短期通过增加软件测试投入，迅速达到零Bug率。 （3）期望用测试自动化代替大部分手工劳动。 （4）忽视前期需求分析和设计阶段的参与。 （5）忽视用户操作密集及核心功能的回归测试。 （6）忽视软件测试文档。 7 2.7 实施软件开发过程管理 2.7.1 管理方面 1. 加强对技术过程的管理控制 2. 完备的计划过程，严格的执行控制 3. 建立需求基准和项目范围基准 4. 基于WBS的成本控制体系，基于进度的成本控制过程 5. 质量保证过程贯穿项目始终 7 2.7 实施软件开发过程管理 2