第2章 软件开发过程管理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
结束
2.2 软件过程
2. 软件过程管理的必要性
提高软件企业的开发效率和产品质量; 有效地对软件开发项目进行管理;
7
有帮助软件机构做出正确决策; 提高软件的可重用性和组间协作; 改善软件机构对软件的维护;
不断采用新的、更好的软件开发经验。
结束
2.2 软件过程
3. 软件过程管理的组成
结束
2.4 软件开发过程模型
2.4.6 RAD模型
2. RAD模型的缺陷
(1)并非所有应用都适合RAD。
7
( 2)开发人员和客户必须在很短时间内完成一系列 的需求分析,任何一方配合不当都会导致 RAD 项目失败。 (3)RAD不适合技术风险很高的软件项目。
结束
2.4 软件开发过程模型
2.4.7 软件包模型
2.4.2 V模型
7
V模型是瀑 布模型的一种 变体,由于整 个开发过程构 造成一个V字 形而得名。
结束
2.4 软件开发过程模型
2.4.2 V模型
1. 从水平方向看
垂直虚线左边是分析和设计,是软件设计实现的过程, 同时伴随着质量保证活动 ──审核的过程,也就是静态的测试 过程;垂直虚线右边是对左边结果的验证,是动态测试的过 7 程,即对分析和设计的结果进行测试,以确认是否满足用户 需求。左右两边的对应关系如下:
结束
2.6 传统开发过程存在的问题
2.6.2 技术方面
3. 代码编写
(1)程序员各自为战,缺乏分工合作。 (2)对于编程语言及工具不能准确掌握。 (3)不必要的重复。 (4)晦涩混乱的表达。
7
4. 测试
(1)认为规范化软件测试是增加项目成本。 (2)期望短期通过增加软件测试投入,迅速达到零Bug率。 (3)期望用测试自动化代替大部分手工劳动。 (4)忽视前期需求分析和设计阶段的参与。 (5)忽视用户操作密集及核心功能的回归测试。 (6)忽视软件测试文档。
7
结束
2.4 软件开发过程模型
2.4.8 遗留系统维护模型
7
主要用 于纠错性 维护或者 稍加改进 一个运行 系统。
结束
2.4 软件开发过程模型
2.4.8 遗留系统维护模型
7
结束
2.5 软件开发过程模型选择
目前,大多数软件开发项目都采用瀑布模型 作为规范化开发的基础,主要原因如下:
( 1 )软件开发单位的软件工程工作尚处于初级阶段, 软件开发人员和管理人员既缺乏经验,又无历史数据可供借 鉴,因此,需要一种简单易行的组织方式。
(1)没有规范和切实可行的管理体系。 (2)不能真正区分技术实施和过程管理的工作任务。
(1)项目管理计划粗略。 (2)开发计划不充分。
2. 计划过程粗略,执行控制不力
7
3. 缺乏需求基准 4. 缺乏成本控制体系和过程 5. 质量保证过程薄弱
(1)开发过程不规范。 (2)测试过程不规范。 (3)缺少SQA相关质量保证过程。
(1)加强客户沟通。 (2)适应需求不断改变的现状。 (3)避免理解不一致。
7
2. 软件设计阶段
(1)邀请业务专家参与设计过程。 (2)可维护性需求作为度量需求。 (3)测试人员提前参与。
结束
2.7 实施软件开发过程管理
2.7.2 技术方面
3. 编码阶段
(1)交叉检视评审。 (2)单元测试。 (3)避免拷贝复制代码。 (4)制定统一的规范。
2.4 软件开发过程模型
2.4.4 螺旋模型
3. 螺旋模型的优缺点和适用情况
7
结束
2.4 软件开发过程模型
2.4.5 增量模型
首先创建一组核心功能,或者是项目至关重要的最 高优先级的系统,或者是能够降低风险的系统。随后基 于核心功能反复扩展,逐步增加功能以提高性能。
7
增量模型降低了取得初始功能之前的成本,强调采 用构建方法来控制更改需求的影响,提高了创建可操作 软件系统的速度。 增量模型综合了瀑布模型和原型模型,提倡以功能 渐增方式开发软件。
结束
2.7 实施软件开发过程管理
2.7.1 管理方面 1. 加强对技术过程的管理控制
2. 完备的计划过程,严格的执行控制
7
3. 建立需求基准和项目范围基准
4. 基于WBS的成本控制体系,基于进度 的成本控制过程 5. 质量保证过程贯穿项目始终
结束
2.7 实施软件开发过程管理
2.7.2 技术方面
1. 需求分析阶段
软件项目管理
清华大学 出版社( 2012)
第2章 软件开发过程管理
渤海大学 信息科学与技术学院
任永昌 2012年7月
结束பைடு நூலகம்
2.1 软件生命周期
软件生命周期是“从设计软件产品开始到软件产 品不能再使用为止的时间周期。
典型的软件生命周期包括:需求阶段、设计阶段、 实现阶段、测试阶段、安装和验收阶段、运行和维 7护阶段,有时还包括引退阶段”。 软件生命周期可以划分成若干个相互独立而又相 互联系的阶段,每一阶段工作以上一阶段工作的结 果为依据,并为下一阶段工作提供基础。
2.4.3 原型模型
3. 原型模型的优缺点和适用情况
7
结束
2.4 软件开发过程模型
2.4.4 螺旋模型
勃姆( Boehm , B.W )将瀑布模型与 快速原型模型结合起 来提出了螺旋模型。 要求不断迭代, 7 同时要象螺旋一样不 断前进,即每次迭代 都不是在原水平上进 行,是对整个开发过 程进行迭代,而不仅 仅对编码、测试进行 迭代。
结束
7
2.4 软件开发过程模型
2.4.5 增量模型 2. 增量模型的优缺点和适用情况
7
结束
2.4 软件开发过程模型
2.4.6 RAD模型
是增量型的软件开发过程模型,强调极短的开发 周期,是瀑布模型的一个“高速”变种,通过大量使用 可复用构件,采用基于构件的建造方法进行快速开发。
7
结束
2.4 软件开发过程模型
7
结束
2.3 软件开发过程
软件开发过程是以生命周期各阶段的活动划分为 基础,将用户需求转化为软件系统活动集合的过程。
7
1. 开发计划和可行性研究阶段 2. 需求分析阶段 3. 软件设计阶段 4. 编写代码阶段 5. 软件测试阶段
结束
2.4 软件开发过程模型
2.4.1 瀑布模型
由于这种方法是从一个阶段成瀑布流入下 一个阶段,所以称为“瀑布模型”。
结束
2.2 软件过程
1. 软件过程的定义
软件过程是指软件生命周期中的一系列相关过程,是将用 户需求转化为可执行系统的演化过程所进行的软件工程的全 部活动,是用于生产软件产品的工具、方法和实践的集合。
7
软件过程是关系复杂的软件活动的集合,各活动之间有着 严格密切的关系,有的是异步并行,有的是互为条件,因此 实际软件过程中的软件活动存在复杂的网状关系。 软件过程是改进软件质量和组织性能的主要因素之一。
3. 瀑布模型总结
运用瀑布模型应坚持做到以下两点:
7
( 1 )每个阶段都完成规定的文档,没有交 出合格的文档就没有完成阶段性工作。
( 2 )每个阶段结束前都要对提交的文档进 行评审,以便尽早发现问题,改正错误。
结束
2.4 软件开发过程模型
2.4.1 瀑布模型
3. 瀑布模型总结
7
结束
2.4 软件开发过程模型
(1)需求分析对应验收测试。 (2)概要设计对应系统测试。 (3)详细设计对应集成测试。 (4)软件编码对应单元测试。
结束
2.4 软件开发过程模型
2.4.2 V模型
2. 从垂直方向看
水平虚线上部,需求分析、系统定义和验收测试等 工作主要是面向用户。水平虚线下部是技术工作,主要 由工程师、技术人员完成。 从垂直方向看,越在下面,白盒测试方法使用越多, 中间部分是灰盒测试方法。在验收测试过程中,使用黑 盒测试方法。
结束
2.4 软件开发过程模型
2.4.5 增量模型 增量模型结构
7
结束
2.4 软件开发过程模型
2.4.5 增量模型
1. 增量开发必须注意的问题
良好的可扩展性架构设计,是增量开发成功的基础; 由于一些模块必须在另一个模块之前完成,所以必须定义良好的 接口; 与完整系统相比,增量方式正式评审更难于实现,所以必须定义 可行的过程; 要避免把难题往后推,首先完成的应该是高风险和重要的部分; 客户必须认识到总体成本不会更低; 分析阶段采用总体目标而不是完整的需求定义,可能不适应管理; 需要良好的计划和设计,管理必须注意动态分配工作,技术人员 必须注意相关因素的变化。
结束
7
2.6 传统开发过程存在的问题
传统开发过程基本是 单纯的技术实施过程,既 没有定义必要的项目过程 管理,也没有定义技术过 程如何与项目管理相结合。 这种软件开发过程模式产 生的结果很难预测,极容 易造成管理上的失控。
7
结束
2.6 传统开发过程存在的问题
2.6.1 管理方面
1. 忽视软件过程管理
7
结束
2.4 软件开发过程模型
2.4.3 原型模型
为解决瀑布模型需求理解困难、开发周期 长、见效慢等问题,借助第4代程序开发语言 而产生的一种软件开发方法。
7
软件开发人员先根据用户提出的软件定义, 快速开发一个原型,向用户展示。然后用户 根据这个原型提出修改意见,再进一步修改、 完善,确认软件系统的需求并达到一致的理 解。
7
瀑布模型是从时间角度对软件开发和维护 的复杂问题进行分解。按软件生命周期依次划 分为六个阶段:可行性研究、需求分析、软件 设计、软件编码、软件测试、运行与维护。
结束
2.4 软件开发过程模型
2.4.1 瀑布模型
1. 理论的瀑布模型 2. 实际的瀑布模型
7
结束
2.4 软件开发过程模型
2.4.1 瀑布模型
结束
2.6 传统开发过程存在的问题
2.6.2 技术方面
1. 需求分析
问题1:客户并不知道自己需要什么。 问题2:需求在项目进行过程中发生改变。
7
2. 软件设计
(1)僵化──设计难以改变。 (2)脆弱性──设计易于遭到破坏。 (3)牢固性──设计难以重用。 (4)粘滞性──难以做正确的事情。 (5)不必要的复杂性──过度设计。
2.4.6 RAD模型
1. RAD模型各个活动期要完成的任务
如果一个业务能够被模块化使得其中每一个主要功能 均可以在不到 3个月的时间内完成,则是 RAD的一个候选。 一个主要功能可由一个单独的RAD组来实现,最后集成起来 形成一个整体。
7
(1)业务建模。 (2)数据建模。 (3)过程建模。 (4)应用生成。 (5)测试交付。
结束
2.4 软件开发过程模型
2.4.4 螺旋模型 1. 工作步骤和内容
(1)确定下一阶段目标、开发方案及约束条件。
7
(2)风险分析、构造原型。 (3)开发、验证阶段软件产品。 (4)制订下一阶段计划。
结束
2.4 软件开发过程模型
2.4.4 螺旋模型
2. 螺旋模型对经常遇见问题提供的解决方案
7
结束
7
4. 测试阶段
(1)加强观念教育,重视测试。 (2)利用分阶段集成、自动化测试等手段。 (3)测试人员从前期就开始参与。 (4)建立缺陷跟踪流程。
主 要 用于开发 依赖于外 购(协) 7软 件 产 品 和可重用 软件包的 系统。
结束
2.4 软件开发过程模型
2.4.7 软件包模型
1. 软件包模型的开发步骤
(1)需求分析和软件包标识。
7
(2)结构定义和软件包选择。
(3)系统集成和测试。 (4)技术修改和系统维护。
结束
2.4 软件开发过程模型
2.4.7 软件包模型 2. 软件包模型的优缺点和适用情况
结束
2.4 软件开发过程模型
2.4.3 原型模型 1. 原型模型的基本过程
7
结束
2.4 软件开发过程模型
2.4.3 原型模型 2. 原型模型的软件支撑环境
方便灵活的关系数据库系统;
7
完整的程序生成软件; 与数据库对应的、方便灵活的数据字典; 可以快速抽象或者容易提炼的原型。
结束
2.4 软件开发过程模型
开发过程模型应与软件项目的特点相适应; 开发过程模型应与采用的软件开发技术相适应; 开发过程模型应满足整个应用系统的开发进度要求; 开发过程模型应有助于控制和消除软件开发风险; 开发过程模型应有可用的计算机辅助工具的支持; 开发过程模型应与用户和软件开发人员的知识和技 能水平相适应; 开发过程模型应有利于软件开发的管理和控制。
7
( 2 )结构化方法学是系统工程中最成熟的方法学,目 前大多数软件开发都以结构化开发方法学为基础。在与结构 化方法学相适应的软件开发过程模型中,瀑布模型最为简单 实用,行之有效。 ( 3 )有关软件开发的现行国家标准和国家军用标准都 是以瀑布模型为基础制定的。
结束
2.5 软件开发过程模型选择
选择开发过程模型时,一般应遵循下述原则: