第2章 软件开发过程管理.pptx

1、软件项目管理 清华大学 出版社（ 2012） 第2章 软件开发过程管理 渤海大学 信息科学与技术学院 任永昌 2012年7月,7,2.1 软件生命周期,软件生命周期是“从设计软件产品开始到软件产品不能再使用为止的时间周期。 典型的软件生命周期包括：需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段、运行和维护阶段，有时还包括引退阶段”。 软件生命周期可以划分成若干个相互独立而又相互联系的阶段，每一阶段工作以上一阶段工作的结果为依据，并为下一阶段工作提供基础。,7,2.2 软件过程,1. 软件过程的定义 软件过程是指软件生命周期中的一系列相关过程，是将用户需求转化为可执行系统的演化过程所进行

2、的软件工程的全部活动，是用于生产软件产品的工具、方法和实践的集合。 软件过程是关系复杂的软件活动的集合，各活动之间有着严格密切的关系，有的是异步并行，有的是互为条件，因此实际软件过程中的软件活动存在复杂的网状关系。 软件过程是改进软件质量和组织性能的主要因素之一。,7,2.2 软件过程,2. 软件过程管理的必要性 提高软件企业的开发效率和产品质量； 有效地对软件开发项目进行管理； 有帮助软件机构做出正确决策； 提高软件的可重用性和组间协作； 改善软件机构对软件的维护； 不断采用新的、更好的软件开发经验。,7,2.2 软件过程,3. 软件过程管理的组成,7,2.3 软件开发过程,软件开发过程是以

3、生命周期各阶段的活动划分为基础，将用户需求转化为软件系统活动集合的过程。,1. 开发计划和可行性研究阶段 2. 需求分析阶段 3. 软件设计阶段 4. 编写代码阶段 5. 软件测试阶段,7,2.4 软件开发过程模型,由于这种方法是从一个阶段成瀑布流入下一个阶段，所以称为“瀑布模型”。 瀑布模型是从时间角度对软件开发和维护的复杂问题进行分解。按软件生命周期依次划分为六个阶段：可行性研究、需求分析、软件设计、软件编码、软件测试、运行与维护。,2.4.1 瀑布模型,7,2.4 软件开发过程模型,1. 理论的瀑布模型 2. 实际的瀑布模型,2.4.1 瀑布模型,7,2.4 软件开发过程模型,3. 瀑布

4、模型总结 运用瀑布模型应坚持做到以下两点： （1）每个阶段都完成规定的文档，没有交出合格的文档就没有完成阶段性工作。 （2）每个阶段结束前都要对提交的文档进行评审，以便尽早发现问题，改正错误。,2.4.1 瀑布模型,7,2.4 软件开发过程模型,3. 瀑布模型总结,2.4.1 瀑布模型,7,2.4 软件开发过程模型,2.4.2 V模型,V模型是瀑布模型的一种变体，由于整个开发过程构造成一个V字形而得名。,7,2.4 软件开发过程模型,1. 从水平方向看 垂直虚线左边是分析和设计，是软件设计实现的过程，同时伴随着质量保证活动审核的过程，也就是静态的测试过程；垂直虚线右边是对左边结果的验证，是动态

5、测试的过程，即对分析和设计的结果进行测试，以确认是否满足用户需求。左右两边的对应关系如下： （1）需求分析对应验收测试。 （2）概要设计对应系统测试。 （3）详细设计对应集成测试。 （4）软件编码对应单元测试。,2.4.2 V模型,7,2.4 软件开发过程模型,2. 从垂直方向看 水平虚线上部，需求分析、系统定义和验收测试等工作主要是面向用户。水平虚线下部是技术工作，主要由工程师、技术人员完成。 从垂直方向看，越在下面，白盒测试方法使用越多，中间部分是灰盒测试方法。在验收测试过程中，使用黑盒测试方法。,2.4.2 V模型,7,2.4 软件开发过程模型,为解决瀑布模型需求理解困难、开发周期长、见

6、效慢等问题，借助第4代程序开发语言而产生的一种软件开发方法。 软件开发人员先根据用户提出的软件定义，快速开发一个原型，向用户展示。然后用户根据这个原型提出修改意见，再进一步修改、完善，确认软件系统的需求并达到一致的理解。,2.4.3 原型模型,7,2.4 软件开发过程模型,2.4.3 原型模型,1. 原型模型的基本过程,7,2.4 软件开发过程模型,2.4.3 原型模型,2. 原型模型的软件支撑环境 方便灵活的关系数据库系统； 完整的程序生成软件； 与数据库对应的、方便灵活的数据字典； 可以快速抽象或者容易提炼的原型。,7,2.4 软件开发过程模型,2.4.3 原型模型,3. 原型模型的优缺点

7、和适用情况,7,2.4 软件开发过程模型,2.4.4 螺旋模型,勃姆（Boehm，B.W）将瀑布模型与快速原型模型结合起来提出了螺旋模型。 要求不断迭代，同时要象螺旋一样不断前进，即每次迭代都不是在原水平上进行，是对整个开发过程进行迭代，而不仅仅对编码、测试进行迭代。,7,2.4 软件开发过程模型,2.4.4 螺旋模型,1. 工作步骤和内容 （1）确定下一阶段目标、开发方案及约束条件。 （2）风险分析、构造原型。 （3）开发、验证阶段软件产品。 （4）制订下一阶段计划。,7,2.4 软件开发过程模型,2.4.4 螺旋模型,2. 螺旋模型对经常遇见问题提供的解决方案,7,2.4 软件开发过程模型

8、,2.4.4 螺旋模型,3. 螺旋模型的优缺点和适用情况,7,2.4 软件开发过程模型,2.4.5 增量模型,首先创建一组核心功能，或者是项目至关重要的最高优先级的系统，或者是能够降低风险的系统。随后基于核心功能反复扩展，逐步增加功能以提高性能。 增量模型降低了取得初始功能之前的成本，强调采用构建方法来控制更改需求的影响，提高了创建可操作软件系统的速度。 增量模型综合了瀑布模型和原型模型，提倡以功能渐增方式开发软件。,7,2.4 软件开发过程模型,2.4.5 增量模型,增量模型结构,7,2.4 软件开发过程模型,2.4.5 增量模型,1. 增量开发必须注意的问题 良好的可扩展性架构设计，是增量

9、开发成功的基础； 由于一些模块必须在另一个模块之前完成，所以必须定义良好的接口； 与完整系统相比，增量方式正式评审更难于实现，所以必须定义可行的过程； 要避免把难题往后推，首先完成的应该是高风险和重要的部分； 客户必须认识到总体成本不会更低； 分析阶段采用总体目标而不是完整的需求定义，可能不适应管理； 需要良好的计划和设计，管理必须注意动态分配工作，技术人员必须注意相关因素的变化。,7,2.4 软件开发过程模型,2.4.5 增量模型,2. 增量模型的优缺点和适用情况,7,2.4 软件开发过程模型,是增量型的软件开发过程模型，强调极短的开发周期，是瀑布模型的一个“高速”变种，通过大量使用可复用构

10、件，采用基于构件的建造方法进行快速开发。,2.4.6 RAD模型,7,2.4 软件开发过程模型,1. RAD模型各个活动期要完成的任务 如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，则是RAD的一个候选。一个主要功能可由一个单独的RAD组来实现，最后集成起来形成一个整体。 （1）业务建模。 （2）数据建模。 （3）过程建模。 （4）应用生成。 （5）测试交付。,2.4.6 RAD模型,7,2.4 软件开发过程模型,2. RAD模型的缺陷 （1）并非所有应用都适合RAD。 （2）开发人员和客户必须在很短时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目

11、失败。 （3）RAD不适合技术风险很高的软件项目。,2.4.6 RAD模型,7,2.4 软件开发过程模型,2.4.7 软件包模型,主要用于开发依赖于外购（协）软件产品和可重用软件包的系统。,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 软件开发

12、过程模型,2.4.8 遗留系统维护模型,7,2.5 软件开发过程模型选择,目前，大多数软件开发项目都采用瀑布模型作为规范化开发的基础，主要原因如下： （1）软件开发单位的软件工程工作尚处于初级阶段，软件开发人员和管理人员既缺乏经验，又无历史数据可供借鉴，因此，需要一种简单易行的组织方式。 （2）结构化方法学是系统工程中最成熟的方法学，目前大多数软件开发都以结构化开发方法学为基础。在与结构化方法学相适应的软件开发过程模型中，瀑布模型最为简单实用，行之有效。 （3）有关软件开发的现行国家标准和国家军用标准都是以瀑布模型为基础制定的。,7,2.5 软件开发过程模型选择,选择开发过程模型时，一般应遵循

13、下述原则： 开发过程模型应与软件项目的特点相适应； 开发过程模型应与采用的软件开发技术相适应； 开发过程模型应满足整个应用系统的开发进度要求； 开发过程模型应有助于控制和消除软件开发风险； 开发过程模型应有可用的计算机辅助工具的支持； 开发过程模型应与用户和软件开发人员的知识和技能水平相适应； 开发过程模型应有利于软件开发的管理和控制。,7,2.6 传统开发过程存在的问题,传统开发过程基本是单纯的技术实施过程，既没有定义必要的项目过程管理，也没有定义技术过程如何与项目管理相结合。这种软件开发过程模式产生的结果很难预测，极容易造成管理上的失控。,7,2.6 传统开发过程存在的问题,2.6.1 管

14、理方面,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）牢固性设

15、计难以重用。 （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.7.2 技术方面,1. 需求分析阶段 （1）加强客户沟通。 （2）适应需求不断改变的现状。 （3）