软件项目管理第二章

是多加点功能而已，这都搞不定。我要是签不到合同，大家 都喝西北风。
S
P
1 2 3
软件生命周期、软件过程 软件开发过程 软件开发过程模型及选择
4
5
传统开发过程存在的问题
实施软件开发过程管理
软件开发过程是以生命周期各阶段的活动划分为 基础，将用户需求转化为软件系统活动集合的过程。
开发计划和可行性研究阶段：做什么？如何做？能否完成？ 需求分析阶段：需求获取、分析、编需求规格说明书、评审
S
P
高茜
gq@qlu.edu.cn
S
P
软件开发过程管理
S
P
1 2 3
软件生命周期、软件过程 软件开发过程 软件开发过程模型及选择
4
5
传统开发过程存在的问题
实施软件开发过程管理
软件生命周期是“从设计软件产品开始到软件
产品不能再使用为止的时间周期。典型的软件生
命周期包括：需求阶段、设计阶段、实现阶段、
静态的测试
为解决瀑布模型需求理解困难、开发周期长、 见效慢等问题。 软件开发人员先根据用户提出的软件定义，快 速开发一个原型，向用户展示。然后用户根据这 个原型提出修改意见，再进一步修改、完善，确 认软件系统的需求并达到一致的理解。
方便灵活的关系数据库系统； 完整的程序生成软件；
与数据库对应的、方便灵活的数据字典；
史数据可供借鉴，因此，需要一种简单易行的 组织方式。
结构化方法学是系统工程中最成熟的方法学，
目前大多数软件开发都以结构化开发方法学为
基础。Biblioteka Baidu与结构化方法学相适应的软件开发过
程模型中，瀑布模型最为简单实用，行之有效。
有关软件开发的现行国家标准和国家军用标准 都是以瀑布模型为基础制定的。
开发过程模型应与软件项目的特点相适应；
通过需求分配过程将已经基准化的需求分配到各个项目的各 参与方，并通过检查确保需求分析的正确性和可行性，以此 为依据制定项目开发责任合同书。
加强客户沟通，必要时通过原型描述，澄清不明确的需求。 分阶段、分批锁定需求，适应需求不断改变的现状。 对关键点的澄清必须有书面记录并归档，避免理解不一致。
须定义可行的过程；
要避免把难题往后推，首先完成的应该是高风险和重要的 部分；
客户必须认识到总体成本不会更低； 分析阶段采用总体目标而不是完整的需求定义，可能不适
应管理；
需要良好的计划和设计，管理必须注意动态分配工作，技
术人员必须注意相关因素的变化。
是增量型的软件开发过程模型，强调极短的开发 周期，是瀑布模型的一个“高速”变种，通过大 量使用可复用构件，采用基于构件的建造方法进 行快速开发。
4
5
传统开发过程存在的问题
实施软件开发过程管理
设置执行评审委员会、变化控制委员会、项目核心组、里 程碑评审委员会等。
对计划的过程、跟踪、变更进行全程指导，同时保证计划的 “粒度”和执行的严肃性。除了高层的概要计划外，制定贯穿 项目全程的详细开发计划，并在每个里程碑进行评审、检查和 调整。此外还要强调充分的开发计划和切实可行的开发目标。
软件生命周期、软件过程 软件开发过程 软件开发过程模型及选择
4
5
传统开发过程存在的问题
实施软件开发过程管理
传统开发过程基本是单纯的技术实施过程，既没
有定义必要的项目过程管理，也没有定义技术过程
如何与项目管理相结合。这种软件开发过程模式产
生的结果很难预测，极容易造成管理上的失控。
管理方面 忽视软件过程管理 （1）没有规范和切实可行的管理体系。 （2）不能真正区分技术实施和过程管理的工作任务。 计划过程粗略，执行控制不力 （1）项目管理计划粗略。 （2）开发计划不充分。
软件过程是关系复杂的软件活动的集合，各活 动之间有着严格密切的关系，有的是异步并行， 有的是互为条件，因此实际软件过程中的软件活 动存在复杂的网状关系。
软件过程是改进软件质量和组织性能的主要因
素之一。
帮助软件机构做 出正确决策 有效地对软件开发
3 2 1 6 必要性 4 5
提高软件的可重
用性和组间协作 改善软件机构对
运用瀑布模型应坚持做到以下两点： 每个阶段都完成规定的文档，没有交出合格 的文档就没有完成阶段性工作。 每个阶段结束前都要对提交的文档进行评审， 以便尽早发现问题，改正错误。
水平虚线上部，需求分析、 系统定义和验收测试等工 V 模型是瀑布模型的一种变体，由于整个开发 作主要是面向用户。水平 虚线下部是技术工作，主 过程构造成一个V字形而得名。 要由工程师、技术人员完 成。越在下面，白盒测试 强调软件开发的协作和速度，将软件实现和验 方法使用越多，中间部分 证有机地结合起来。 是灰盒测试方法。在验收 对左边结果的验证 测试过程中，使用黑盒测 试方法。 增加回溯，强调测试工作。
产品质量完全依赖个人 而依赖于企业的过程 的素质和能力 能力
用户需求
过程A 产品
关注点
过程B
产品
过程C
产品
关注点
产品 过程
产品
产品
项目管理用于保证项目的成功， 过程管理用于管理最佳实践。
这两项管理不是相互孤立的，而是有机地紧密
地结合的。
S
P
1 2 3
软件生命周期、软件过程 软件开发过程 软件开发过程模型及选择
项目进行管理
提高软件企业的开 发效率和产品质量
软件的维护
不断采用新的、更好的软件开发经验
当攻城狮们日夜加班，终于完成所有功能，拿给客户一看。 客户大骂，这根本不是我想要的！
攻城狮只能骂做设计的：我们这么辛苦，你是怎么设计的，
做出来了，才说不是这样，设计要修改。
做设计的只能骂做需求调研的：什么烂需求，我当时可是
问题2：需求在项目进行过程中发生改变。
软件设计 （1）僵化──设计难以改变。（2）脆弱性──设计易于 遭到破坏。（ 3 ）牢固性──设计难以重用。（ 4 ）粘滞性 ──难以做正确的事情。（5）不必要的复杂性──过度设计。
技术方面 代码编写 （1）程序员各自为战，缺乏分工合作。 （2）对于编程语言及工具不能准确掌握。 （3）不必要的重复。 （4）晦涩混乱的表达。
开发过程模型应与采用的软件开发技术相适应；
开发过程模型应满足整个应用系统的开发进度要
求；
开发过程模型应有助于控制和消除软件开发风险；
开发过程模型应有可用的计算机辅助工具的支持；
开发过程模型应与用户和软件开发人员的知识和
技能水平相适应；
开发过程模型应有利于软件开发的管理和控制。
S
P
1 2 3
测试阶段、安装和验收阶段、运行和维护阶段，
有时还包括引退阶段”。
软件生命周期可以划分成若干个相互独立而又
相互联系的阶段，每一阶段工作以上一阶段工作
的结果为依据，并为下一阶段工作提供基础。
软件开发周期。它是指从决定开发一个软件产
品开始到产品交付为止的时间间隔。
软件过程是指软件生命周期中的一系列相关过
首先创建一组核心功能，或者是项目至关重要的最高优先 级的系统，或者是能够降低风险的系统。随后基于核心功能 反复扩展，逐步增加功能以提高性能。
增量模型降低了取得初始功能之前的成本，强调采用构建
方法来控制更改需求的影响，提高了创建可操作软件系统的
速度。
增量模型综合了瀑布模型和原型模型，提倡以功能渐增方 式开发软件。
程，是将用户需求转化为可执行系统的演化过程
所进行的软件工程的全部活动，是用于生产软件 “过程”是创建一个产品或完成某些任务的一种系统化
的方法和工作过程。执行者不再仅仅是计算机，而经常 产品的工具、方法和实践的集合。 是由具体承担任务的软件开发人员使用给定的开发工具
来执行，甚至可以是一个无法在计算机上运行的过程， 完全由人工或人工借助计算机以外的工具来完成。
软件设计阶段：概要设计阶段、详细设计阶段
编写代码阶段：根据设计编代码、加入注释便于维护
软件测试阶段：单元测试、集成测试、确认测试、系统测试
只关注于产品而不关注 关注于过程 过程 不管谁来做，都采用 则不同个人可能采用不 统一的过程 同的过程 产品质量不依赖于个 导致产品的质量不同 人
按照你的需求说明书去设计的。
做需求的只能骂销售了：这能怪我吗？当时做需求的时候 已经说好的，那销售为了签合同，竟然额外答应客户这么要
求，这个我怎么解决？
销售也在那里大骂：我起早贪黑，喝得胃出血，才能把合 同拿下，你们这班整天坐在空调房间的高材生竟然一点都不
体谅，竟然拿出这么烂的系统给客户。怎么做事情的，不就
在生命周期的早期阶段（软件规划、需求分析），需要建
立整个系统架构，这个架构应该具有较强的可集成性，后续 的构件方式开发，都是建立在这个架构之上。
良好的可扩展性架构设计，是增量开发成功的基础； 由于一些模块必须在另一个模块之前完成，所以必须定义
良好的接口；
与完整系统相比，增量方式正式评审更难于实现，所以必
4
5
传统开发过程存在的问题
实施软件开发过程管理
由于这种方法是从一个阶段像瀑布流入下一个 阶段，所以称为“瀑布模型”。 瀑布模型是从时间角度对软件开发和维护的复 杂问题进行分解。按软件生命周期依次划分为六 个阶段：可行性研究、需求分析、软件设计、软 件编码、软件测试、运行与维护。
反馈环
尽可能地推迟软件 编码，是按照瀑布 模型开发软件的一 条重要的指导原则
对系统进行技 术修改和维护 以改进系统
外购软件包，不 能进行单元测试， 直接进行系统集 成和测试
主要用于纠错性维护或者稍加改进一个运行系
统。
目前，大多数软件开发项目都采用瀑布模型作
为规范化开发的基础，主要原因如下：
软件开发单位的软件工程工作尚处于初级阶段，
软件开发人员和管理人员既缺乏经验，又无历
可以快速抽象或者容易提炼的原型。
勃姆（Boehm，B.W）将瀑布模型与快速原型模型 结合起来提出了螺旋模型。 要求不断迭代，同时要象螺旋一样不断前进，即 每次迭代都不是在原水平上进行，是对整个开发过
程进行迭代，而不仅仅对编码、测试进行迭代。 如果某些风险不能排除，
该方案立即终止，否则 启动下一个开发步骤。
查找数据对象集合、定义 则是 RAD 的一个候选。一个主要功能可由一个单独 确定驱动业务过程运作
数据对象属性，并其他数 的信息、欲生成的信息、 据对象的关系构成数据模 的 RAD 组来实现，最后集成起来形成一个整体。 如何生成、信息流的去 型，可辅之以E-R图。 向及其处理等，可以辅 之以数据流图。
并非所有应用都适合RAD。 开发人员和客户必须在很短时间内完成一系列 的需求分析，任何一方配合不当都会导致RAD项目 失败。 RAD不适合技术风险很高的软件项目。
确定要使用的外购 软件包，构造原型 系统，确定系统初 步结构
确定与系统其 余部分的结构， 确定系统结构
主要用于开发依赖于外购（协）软件产品和重 用软件包的系统。
管理方面 缺乏需求基准 缺乏成本控制体系和过程 质量保证过程薄弱 （1）开发过程不规范。 （2）测试过程不规范。
（ 3 ）缺少 SQA （ SQA-Software Quality Assurance 软件 质量保证）相关质量保证过程。
技术方面 需求分析 问题1：客户并不知道自己需要什么。
技术方面 测试 （1）认为规范化软件测试是增加项目成本。 （ 2 ）期望短期通过增加软件测试投入，迅速达到零 Bug 率。
（3）期望用测试自动化代替大部分手工劳动。
（4）忽视前期需求分析和设计阶段的参与。 （5）忽视用户操作密集及核心功能的回归测试。 （6）忽视软件测试文档。
S
P
1 2 3
软件生命周期、软件过程 软件开发过程 软件开发过程模型及选择
利用第四代语言（4GL）写出 处理程序，重用已有构件或 创建新的可重用构件，利用 环境提供的工具自动生成以 构造出整个应用系统。 一般只做总体测试，但新创 建的构建要进行其他测试。 测试完成后进行系统集成， 然后交付用户使用。
使数据对象在信息流中完成 各业务功能，创建过程以描 述数据对象的增加、删除、 修改、查找，即细化数据流 图中的处理。
RAD 模型不采用传统的第三代程序设计语言来创 建软件，而是采用基于构件的开发方法，复用已 有的程序结构、使用可复用构件、创建可复用构 件，并使用自动化工具辅助软件开发。
RAD 模型项目上的时间约束需要“一个可伸缩的 范围”。如果一个业务能够被模块化使得其中每 一个主要功能均可以在不到 3 个月的时间内完成， 为支持业务过程的数据流