北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第七讲
软件项目管理
软件项目策划
内容和目的
? 了解软件项目和软件项目管理的概念
? 了解对软件策划的要求
? 掌握软件策划的工作内容和过程
? 掌握软件项目计划文档的内容
? 了解软件项目计划文档的格式条目
项目与项目管理
项目
? 项目 是以一套独特的、相互联系的任务
为前提，有效地利用资源，为实现一个
特定的目标所做的努力。
? 项目在工作范围、计划进度和成本方面
都有明确界定的标准。
? 当客户 —— 愿意提供资金以实现需求的
组织或个人 —— 明确提出需求时，项目
就产生了。
项目概念要素
? 项目的总体属性,项目是一系列工作，
产品是项目的目的或结果。
? 项目的过程,项目是必须完成的、临时
性的、一次性的、有限的任务
? 项目的结果,项目都有一个特定的目标。
? 项目的共性,项目只能在资金、时间、
质量（三大目标）的约束下进行。
项目特征
? 项目有一个明确界定的目标 —— 一个期望的结
果或产品。
? 项目的执行要通过完成一系列相互关联的任务
来达到项目目标。
? 项目需要运用各种资源来执行任务。
? 项目有具体的时间计划或有限的寿命。
? 项目可能是独一无二的、一次性的努力。
? 每个项目都有客户。
? 项目包含一定的不确定性。
制约项目成功的因素
? 项目目标的成功实现通常受四个因素制约：工作范围、成本、进
度计划和客户满意度。
工作范围
成本 进度计划
客户
满意程度
? 实现项目目标就是在一定时间内、在预算内完成工作范围，以使
客户满意。
项目生命周期
识别
需求
提出
解决
方案
执行项目 结束项目
时间
投
入
力
量
项目管理
? 项目管理 是通过项目经理和项目组织的努力，运用系统理
论和方法对项目及其资源进行计划、组织、协调、控制，
旨在实现项目的特定目标的管理方法。
? 项目管理是一种管理方法体系。
? 项目管理的 对象 是项目。
? 项目管理的主要 目的 是实现项目的预定目标。
? 项目管理的 职能 是对组织的资源进行计划、组织、指挥、
控制。
? 项目管理的 任务 是对项目及其资源的计划、组织、协调、
控制。
? 项目管理运用系统理论和思想。
? 项目管理职能主要由项目经理执行。
项目管理的要素
? 人员（ People）
? 软件工程是人的智力密集的劳动
? 问题（ Problem）
? 必须明确项目的目的和范围，考虑可选的解
决方案
? 过程（ Process）
? 提供框架
项目经理
? 项目经理的职责就是确保客户满意。
? 对项目经理的挑战是防止、预测和克服计划的意外情
况，以便能够在预算内按时地、使客户满意地实现项
目工作范围。
? 良好的计划和沟通对于防止问题发生，以及当问题发
生时，使问题对实现项目目标的影响降到最小，都是
很必要的。
? 项目经理必须在计划和沟通上提前做好准备，并领导
项目团队实现项目目标。
? 客户满意意味着把客户作为一个合作伙伴加入到项目
中来，在整个项目过程中积极参与，以获得项目的成
功。
项目管理的基本内容
? 项目定义
? 项目计划
? 项目执行
? 项目控制
? 项目结束
? 项目管理被认为是一种建立在公认的管理原理
基础上的方法和技术，用于计划、估算和控制
项目活动，以工具规范在预算之内，按时实现
项目的最终目标。
PDCA环
? 戴明环 —— PDCA
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理
P
D
C
A
项目管理过程
项目管理过程
就是
制定计划
然后
按计划工作
软件项目与软件项目管理
项目与软件项目
? 项目是一个被承担来产生唯一的产品或服务的
临时工作。
? 项目包括一组人员、资源和活动，满足下列共
同特征,
? 主要目标是产生产品、服务和结果。
? 项目具有共知的起始、结束点，即项目是临时的。
? 项目不是多数机构常规、正在进行的工作的一部分，
即它通常具有唯一的需求。有些机构存在仅为了执
行项目。
? 软件项目是强调将软件作为其产品、服务或结
果的项目。
软件项目与一般项目的区别
? Watts Humphrey,
? 软件通常更复杂。
? 软件更改相对更容易出现。
? 许多晚期发现的硬件问题被要求通过软件更改来处理。
? 由于其低廉的重复生产成本，软件没有发布生产的自然约
束。
? 软件学科不是建立在自然科学的基础上，它缺乏关于可行
的测试与设计模型的成熟技术。
? 软件通常是一个完整系统的集成元素，这增加了其复杂性
和产生后期更改的出现。
? 软件通常更可见，因此更多出现需求更改和更多遭受用户
抱怨。
软件项目管理
? 由于软件与非软件产品、服务、结果不同，软件项目
管理也有其特别之处。关键是管理必须意识到软件项
目管理的独特领域以预防问题。
? 软件项目管理是保证项目成功的方法和技术，它被要
求,
? 预见并因此预防和最小化问题的不利影响
? 作出及时和坚定的决定
? 当问题发生时解决问题
? 对项目的行为、过程、活动、资源、产品和结果明
确职责
? 软件项目管理方法的执行被许多因素所确定，例如人
员、机构、合同要求和项目复杂性。
软件项目组织
项目组织
? 职能式
? 项目式
? 矩阵式
? 弱矩阵
? 平衡矩阵
? 强矩阵
软件的项目式组织结构
软件
经理
项目
经理 1
项目
经理 2
项目
经理 3
审查
小组
第 1 组 第 2 组 第 3 组 第 1 组 第 2 组 第 3 组 第 1 组 第 2 组 第 3 组
程序设计小组的组织
? 程序设计小组的人数不能太多，否则组员间彼此通信
时间将多于程序设计时间，而且出现接口错误的可能
性增加。
? 一般来说，程序设计小组的规模应该较小，视工程规
模以 2-8人为宜。若项目规模大，可同时设几个小组，
每个小组承担一部分任务。
? 小组规模小，不仅可以减少通信问题，而且还有其它
好处。如，容易确定小组的质量标准，而且用民主方
式确定的标准更容易被大家遵守；组员间关系密切，
能够互相学习等。
? 小型的程序设计小组通常采用非正式的组织方式。
软件项目组织
? 民主制程序员组
? 主程序员组
? 现代程序员组
? 软件项目组
民主制程序员组
? 有两种极端方法可用来组织程序员组，
这两种组织方法分别称为
? 民主制程序员组
? 主程序员组
? 构成民主制程序员组的基本概念 是, 无
私编程,
无私编程
? 必须改变评价程序员价值的标准，每名程序员都
应该鼓励该组其他成员找出自己编写的代码中的
错误。
? 不要认为存在错误是坏事，而应该认为是正常的
事情，应该把找出模块中的一个错误看作是取得
了一个胜利。
? 任何人都不能嘲笑程序员所犯的编码错误。程序
员组作为一个整体，将培养一种平等的团队精神，
坚信, 每个模块都是属于整个程序员组的，而不
是属于某个人的, 。
? 一组无私的程序员将构成一个民主制程序员组。
民主制程序员组的特点
? 民主制程序员组的一个重要特点是，小组成员完全平
等，享有充分民主，通过协商做出技术决策。
? 小组成员间的通信是平行的，如果一个小组有 n个成员，
则可能的通信信道有 n(n-1)/2条。
? 一般说来，程序设计小组的规模应该比较小，以 2～ 8
名成员为宜。
? 如果项目规模很大，用一个小组不能在预定时间内完
成开发任务，则应该使用多个程序设计小组，每个小
组承担工程项目的一部分任务，在一定程度上独立自
主地完成各自的任务。
? 系统总体设计应该能够保证由各个小组负责开发的各
部分之间的接口是良好定义的，并且是尽可能简单的。
民主制程序员组的特点
? 小组规模小，不仅可以减少通信问题，而且还有其他
好处。例如，容易确定小组的质量标准，而且用民主
方式确定的标准更容易被大家遵守；组员间关系密切，
能够互相学习等。
? 民主制程序员组通常采用非正式的组织方式，也就是
说，虽然名义上有一个组长，但是他和组内其他成员
完成同样的任务。在这样的小组中，由全体讨论决定
应该完成的工作，并且根据每个人的能力和经验分配
适当的任务。
? 为了使少数经验丰富、技术高超的程序员在软件开发
过程中能够发挥更大作用，程序设计小组可以采用主
主程序员组
? 美国 IBM公司在 20世纪 70年代初期开始采
用主程序员组的组织方式。采用这种组
织方式主要出于下述几点考虑,
? 软件开发人员多数比较缺乏经验；
? 程序设计过程中有许多事务性的工作，例如，
大量信息的存储和更新；
? 多渠道通信很费时间，将降低程序员的生产
率。
典型的主程序员组
? Baker描述的一个典型的主程序员组
? 由主程序员、后备程序员、编程秘书以及 1～ 3名程
序员组成
? 在必要的时候，该组还有其他领域的专家 (例如，
法律专家，财务专家等 )协助
主程序员组的三人核心
1） 主程序员是经验丰富, 能力强的高级程序员,
全面负责系统的设计, 编码, 测试和安装；
2） 辅助程序员也应该技术熟练且富于经验, 他
协助主程序员并且在必要时能代替主程序员 。
他的主要任务是设计测试方案和分析测试结果,
以验证主程序员的工作 。
3） 程序管理员完成和项目有关的全部事务性工
作, 如：提交上机程序, 保存运行记录, 进行
软件配置管理等 。
人员 -时间折中
根据 应用规模和类型，可能需要临时或长期向组内增加
一些其它方面的专门人员，如：项目管理员，工具员，
文档编辑，测试员，一个或多个后援程序员。
这种人员组织形式的成败主要取决于主程序员的技术和
管理水平。
人员 -时间 折中 定律：在时间允许的情况下，适当减少人
员会提高工作效率，降低软件开发成本。即软件开发
宁可时间长一点，人员少一点。这样可以大大减少人
员之间的通信开销，工作效率会更高。
现代程序员组
? 实际的, 主程序员, 应该由两个人来担任,
? 一个技术负责人，负责小组的技术活动
? 一个行政负责人，负责所有管理决策
大项目的组织
? 由于程序员组的成员人数不宜过多，当软件项目规模
较大时，应该把程序员分成若干个小组。
? 产品的实现作为一个整体是在项目经理的指导下进行
的，程序员向他们的组长汇报工作，而组长向项目经
理汇报工作。当产品规模更大时，可以增加中间管理
层次。
民主制程序员组和主程序员组的结合
? 把民主制程序员组和主程序员组的优点结合起来的另一种方法，
是在合适的地方采用分散做决定的方法。
? 这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的
积极性和主动性，集思广益攻克技术难关。这种组织方式对于适
合采用民主方法的那类问 题 (例如，研究性项目或遇到技术难题需
要用集体智慧攻关 )非常有效。
软件项目组
? 如前所述，程序员组的组织方式主要用
于实现阶段，当然，也适用于软件生命
周期的其他阶段 (当考虑在更广阔范围的
应用时，把程序员组更名为软件项目组
更恰当一些 )。本节从更广阔的角度进一
步讨论软件项目组的组织方式。
通用的项目组组织方式
? Mantei提出了下述的三种通用的项目组
组织方式
? 民主分权式
? 控制分权式
? 控制集权式
民主分权式
? Democratic Decentralized，缩写为 DD
? 这种软件工程小组没有固定的负责人
?, 任务协调人, 是临时指定的，随后将
由协调别的任务的人取代
? 用全体组员协商一致的方法对问题及解
决问题的方法做出决策
? 小组成员间的通信是平行的
控制分权式
? Controlled Decentralized，缩写为 CD
? 有一个固定的负责人，他协调特定任务的完成
并指导负责子任务的下级领导人的工作
? 解决问题仍然是一项群体活动，但是通过小组
负责人在子组之间划分任务来实现解决方案
? 子组和个人之间的通信是平行的，但是也有沿
着控制层的上下级之间的通信
控制集权式
? Controlled Centralized，缩写为 CC
? 小组负责人管理顶层问题的解决过程并
负责组内协调
? 负责人和小组成员之间的通信是上下级
式的 。
选择软件组织结构的 7个因素
? 待解决的问题的困难程度；
? 要开发的程序的规模 (用代码行或功能点度量 )；
? 小组成员在一起工作的时间 (小组生命期 )；
? 问题能够被模块化的程度；
? 对待开发的系统的质量和可靠性的要求；
? 交付日期的严格程度；
? 项目要求的社交 (通信 )程度。
项目特性对组织方式的影响
小组类型
项目特性
DD CD CC
困难程度
高 ×
低 × ×
规模
大 × ×
小 ×
小组生命期
短 × ×
长 ×
项目特性对组织方式的影响
模块化程度
高 × ×
低 ×
可靠性
高 × ×
低 ×
支付日期
紧 ×
松 × ×
社交
高 ×
低 × ×
Mantei组织方式的比较
? 集权式结构能够更快地完成任务，它最适于处理简单
问题。分权式的小组比起个人来，能够产生更多，更
好的解决方案，这种小组在解决复杂问题时成功的可
能性更大。因此,CD或 CC小组结构能够成功地用来解
决简单的问题，而 DD结构则适于解决难度较大的问题。
? 小组的性能与必须进行的通信量成反比，所以开发规
模很大的项目时最好采用 CC或 CD结构的小组。
? 小组生命期长短影响小组的士气。经验表明,DD小组
结构能导致较高的士气和较高的工作满意度，因此适
合于生命期长的小组。
Mantei组织方式的比较
? DD小组结构最适于解决模块化程度较低的问题，因为
解决这类问题需要更大的通信量。如果能够达到较高
的模块化程度 (人们自己独自做自己的事情 )，则 CC或
CD结构更适宜。
? 人们曾经发现,CC和 CD小组产生的缺陷比 DD小组少，
但是这些数据在很大程度上取决于小组采用的质量保
证活动。
? 完成同一个项目，分权式结构通常需要比集权式结构
更多的时间，不过当需要高社交性时分权式结构是最
适宜的。
? 历史上最早的软件项目组是控制集权式 (CC)结构，当
时人们把这样的软件项目组称为主程序员组。
Constantine四种组织范型
? Constantine提出了软件工程小组的下述
4种, 组织范型,
? 封闭式范型
? 随机式范型
? 开放式范型
? 同步式范型
封闭式范型
? 按照传统的权力层次来组织项目组 (类似
于 CD小组 )
? 当开发与过去已经做过的产品相似的软
件时可以工作得很好
? 在这种封闭式范型下难以进行创新性的
工作。
随机式范型
? 松散地组织项目组
? 小组工作依靠小组成员发挥个人的主动
性
? 当需要创新或技术上的突破时，用随机
式范型组织起来的项目组能工作得很好
? 当需要, 有次序地执行, 才能完成任务
时，这样的项目组就可能陷入困境
开放式范型
? 试图以一种既具有封闭式范型的控制性，
又包含随机式范型的创新性的方式来组
织项目组
? 通过大量协商和基于一致意见做出的决
策，项目组成员相互协作完成工作任务
? 用开放式范型组织起来的项目组很适于
解决复杂问题
? 但是可能没有其他类型小组的效率高
同步式范型
? 按照对问题的自然划分，组织项目组成
员各自解决一些子问题
? 他们之间很少有主动的通信需求
有关组织结构的注记
? 对任何软件项目而言，最关键的因素都
是承担项目的人员
? 必须合理地组织项目组，使项目组有较
高生产率
?, 最佳的, 小组结构取决于管理风格、
组里的人员数目和他们的技术水平，以
及所承担的项目的难易程度
团队沟通与协调的方式
? 正式、非个人方式：使用文档、交付物、备忘
录、里程碑、进度与控制工具、修改请求、错
误跟踪报告、中心库数据
? 正式、个人间方式：管理评审、技术评审、代
码审查
? 非正式、个人间方式：信息传播、问题解决、
小组讨论
? 电子通信：电子邮件、电子公告栏,WEB站点、
视频会议
? 个人间的网络：与小组外人员讨论
软件项目定义
项目定义
? 定义在项目范围内要做的工作
? 回答好五个主要问题,
? 被提出的问题是什么？
? 项目的目的是什么？
? 为实现该目的，有哪些目标是必要的？
? 如果项目成功，将如何确认？
? 是否存在可能影响项目成功的假设、风险、
障碍？
项目定义
? 项目目标管理
? 项目目标：实施项目所要达到的预期结果。
? 项目范围管理
? 项目范围：为了成功达到目标，项目所规定
要做的。即为项目界定一个界限，划定哪些
方面是属于项目要做的，哪些不应该包括在
项目之内，定义项目管理的工作边界，确定
项目的主要交付产品。
项目目标的特点
? 多目标性 。
? 基本目标：时间、成本、技术性能
? 目标间会冲突，需要权衡
? 优先性 。权重。
? 层次性 。项目目标的表达通常有 3个层次
? 战略性目标，总体目标，项目使命
? 策略性目标，具体目标
? 具体计划，说明如何实现目标
确定项目目标的意义
? 明确项目及项目组成员共同努力的方向。
作为各方沟通的方式。
? 产生激励作用。
? 为制定项目计划打下基础，为项目计划
指明方向。
? 作为评价项目成功的依据。
确定项目目标的方式
? 项目的目标应该被所有项目组成员及组织内各
个层次的经理人员所了解。
? 项目目标一般由项目的发起人或提议人来确定。
? 项目经理是确定项目目标的重要主体。项目经
理对项目目标的正确理解与定义决定了项目的
成败。
? 为了明确定义项目如何才算完成，怎样才算成
功，最终结果如何，需要对目标具体描述。
? 项目目标的确定有一个由一般到具体逐渐细化
的过程，特别是对于 R&D项目。
描述项目目标的准则
应该
? 定量的、可度量的
? 使每个项目成员都能
清楚认识
? 现实的
? 简单的
? 面向结果的
? 能够起激励作用
不应该
? 定性、不可度量的
? 与项目成员无关
? 理想化的
? 复杂的
? 面向成本的
? 无激励作用
项目目标的基本内容
? 成果、交付物、功能、质量
? 工期、对外承诺的里程碑
? 费用
项目的目标管理
? 目标管理是一种把总体目标与具体计划
向联系的管理方式。
? 目标管理的过程是一个参与式的过程,
? 高层管理人员设定总体目标，该目标作为下
属制定各自工作计划的依据；
? 下属员工根据该目标和各自的期望相应地确
定每个人的职责范围和工作结果；
? 经理人员定期对工作结果进行评价。
目标管理的优点
? 有效激励员工，调动积极性
? 面向结果而不是面向过程
? 为经理人员及下属提供一种有效的沟通渠道
? 使项目组成员更加注重组织目标，了解各自工
作结果与组织目标的关系，明确对项目目标实
现的贡献大小
? 是一种系统的管理方法，有效连接组织目标、
部门目标、项目目标、个人目标
确定项目范围的意义
? 提高费用、时间和进度估算的准确性。
? 确定进度测量和控制的基准。
? 有助于清楚地分派责任。
? 正确确定项目范围对项目成功非常重要，如果
确定的不好，会导致意外的变更，从而打断实
施步骤，造成返工，延长完成时间，降低劳动
生产率，影响成员的干劲，造成最终项目费用
的提高。
项目范围的管理
? 对项目应该包括什么和不应该包括什么
进行定义和控制。
? 启动：开始进入项目。
? 范围计划：起草书面的范围说明书。
? 范围定义：把项目的主要可交付成果划分为
较小的、更容易管理的部件。
? 范围核实：确认项目范围定义的可接受性。
? 范围变化控制：对变化进行控制。
软件项目策划
项目计划（策划 -Planning）
? 计划,计划是为实现一定目标而科学地预测并
确定未来的行动方案。
? 计划解决三个问题：确定目标，确定为达到目标的
行动时序，确定行动所需的资源比例
? 项目计划,根据项目目标对项目实施工作进行
的各项活动作出周密安排。
? 项目计划围绕项目目标的完成系统地确定项目的任
务、安排任务进度、编制完成任务需要的资源预算
等，从而保证项目能够在合理的工期内，用尽可能
低的成本和尽可能高的质量完成。
项目计划的目的
? 确定并描述为完成项目目标所需的各项
任务（活动）范围。
? 确定负责执行项目各项任务（活动）的
全部人员。
? 制定各项任务（活动）的时间进度表。
? 阐明各项任务（活动）所必需的人力、
物力、财力。
? 确定各项任务（活动）的预算。
项目计划的作用
? 确定人员、工作的责任范围、地位、职权，以便安要
求去指导和控制项目工作，减少风险
? 促进项目组、委托人、管理部门的交流与沟通，增强
客户满意度，使项目工作协调一致，并了解关键因素
? 明确奋斗目标、实现目标的方法、途径、期限，确保
以最小的时间、成本、资源实现目标
? 作为分析、协商、记录项目范围变化的基础，约定时
间、人员、经费的基础
? 了解结合部在何处，并使结合部最少
? 把叙述性报告的需要减少到最低量。
项目计划的原则
? 目的性,计划制定的目的是实现目标。
? 系统性,计划与子计划成为相关又独立
的系统。
? 动态性,动态以适应不断变化的环境。
? 相关性,计划与子计划相关。
? 职能性,项目计划以项目何项目管理的
总体及职能为出发点，涉及个管理部门。
项目基准计划
? 项目基准计划是项目在最初启动时订出
的计划，即初始拟定的计划。
? 在项目管理过程中，对项目基准计划与
实际进展计划进行比较、对照、参考，
便于对变化进行管理与控制，从而监督
保证使项目计划得到顺利实施。
项目计划的制作过程和形式
? 概念性计划 。自上而下的计划。
? 确定项目的工作分解结构，并根据任务进行估计，
从而汇总出最高层的项目计划。
? 详细计划 。由下而上的计划。
? 制定详细、包括所有具体任务的工作分解结构，自
下而上汇总，成为详细项目计划。
? 滚动计划 。
? 用滚动的方法对可预见的将来逐步制定详细计划，
随着项目的推进，分阶段地重估自上而下计划制定
过程中所定的进度和预算。
项目计划管理的基本问题
? 做什么,明确的目标
? 如何做,制定工作分解结构实现目标
? 谁去做,将工作具体分配到人和机构
? 何时做,确定工作的延续、开始时间
? 花费多少,实施项目所需费用
项目计划过程的步骤
? 定义产品。含中间产品
? 确定任务。建立 WBS。
? 建立逻辑关系图。紧前任务。
? 为任务分配时间。
? 确定项目组成员的可支配时间。
? 为任务分配资源并进行平衡。
? 确定管理支持性任务。 15%~20%规则。
? 重复上述过程直到完成。
? 准备计划汇总。
项目进度计划（ Schedule)
? 项目进度计划是在 WBS的基础上对项目、活动
做出的一系列时间计划。
? 进度计划将表示预计、实际在何时开始。
? 保证按时获利以补偿已经发生的费用支出；
? 协调资源；
? 使资源在需要时可以利用；
? 预测在不同时间上所需的资金和资源的级别以便赋
予项目以不同的优先级；
? 满足严格的完工时间约束。
项目计划的工具
? 工作分解结构（ WBS）
? 线性责任图（ LRC）
? 项目行动计划表
? 图示评审技术（ GERT）
? 关键路径法（ CPM）
? 计划评审技术（ PERT）
项目策划 — SW-CMM的要求
活动 1 软件工程组参加项目建议群组。
活动 2 在整个项目策划的早期阶段起动软件项目策划，此两项
策划平行进行。
活动 3 在项目的整个生存期内，软件工程组和其它受影响的组
一起参加整个项目的策划。
活动 4 高级管理者参加按照已文档化的规程评审对组织外部的
个人和组所作的软件项目约定。
活动 5 识别或确定具有可管理规模的预先规定阶段的软件生存
周期。
活动 6 按照已文档化的规程制定项目的软件开发计划。
活动 7 对有关软件项目的计划建立文档。
活动 8 识别为建立和保持对软件项目的控制所必须的工作产品。
项目策划 — SW-CMM的要求
活动 9 按照已文档化的规程导出对软件工作产品规模
（或对软件工作产品规模的更改）的估计。
活动 10 按照已文档化的规稆出对软件项目的工作量及成
本的估计。
活动 11 按照已文档化的规程导出对项目的关键计算机资
源的估计。
活动 12 按照已文档化的规程导出项目的软件进度表。
活动 13 对与项目成本资源、进度和技术方面相联系的软
件风险进行鉴别、评估和建立文档。
活动 14 制定关于项目软件工程设施和支持工具的计划。
活动 15 记录软件策划数据。
软件项目策划过程
? 界定目标
? 确定开发模型
? 确定里程碑
? 阶段设置和工作分解
? 编排进度计划
? 成本计划和资源计划
? 关于配置管理计划
? 关于质量
? 编制软件项目计划文档
? 评审
界定目标
? 明确项目的目标
? 成果、工期、成本
? 界定项目的范围
? 用工作陈诉（ Statement of Work,SOW ）
描述项目目标和范围
? 根据项目的目标和范围进行项目策划
工作陈述
? 项目的工作陈述, 包括目标和范围
? 目标用一两句话, 概括说明开展项目的
目的要求, 以及顾客和最终用户
? 项目范围是为完成项目而对各参数、执
行的标准和约束条件进行的明确的简短
说明，项目约束通常与进度（时间）、
质量、成本相对应，并与项目的可交付
性直接相关
项目描述表格示例
项目名称
项目目标
交付物
交付物完成准则
工作描述
工作规范
所需资源估计
重大里程碑
项目负责人审核意见
签名,日期,
确定开发模型
? 瀑布模型
? 增量模型
? 渐进模型
? 原型模型
? 螺旋模型
? RAD模型
? 基于构件的开发模型
? 喷泉模型
? RUP模型
软件开发模型的选择
1）模型应符合软件本身的性质（规模、复杂性）
2）模型应满足软件应用系统整体开发进度要求
3）模型应有可能控制并消除软件开发风险
4）模型应有可用的计算机辅助工具（如快速原
型工具）的支持
5）模型应与用户和软件开发人员的知识和技能
相匹配
6）模型应有利于软件开发的管理与控制
确定里程碑
? 确定对软件项目的进行和成败具有关键
和标志性意义的事件，作为软件项目的
里程碑事件
? 根据工期和甲方的要求，确定合理的里
程碑事件达到控制时刻
? 参照里程碑计划进行详细的软件项目策
划
里程碑计划表示例
1月 2月 3月 4月 5月 6月
里程碑事件 上中下 上中下 上中下 上中下 上中下 上中下
需求分析完成
设计完成
编码完成
集成完成
合格性测试完成
阶段设置和工作分解
? 目的,明确项目所包含的各项工作
? 内容,项目分解就是先把复杂的项目逐
步分解成一层一层的要素（工作），直
到具体明确为止,
? 工具,项目分解的工具是工作分解结构
ＷＢＳ原理，它是一个分级的树型结构，
是一个对项目工作由粗到细的分解过程。
工作分解结构
? WBS(Work Breakdown Structure)主要是将一个项目分
解成易于管理的几个部分或几个细目，以便确保找出
完成项目工作范围所需的所有工作要素。它是一种在
项目全范围内分解和定义各层次工作包的方法,WBS
按照项目发展的规律，依据一定的原则和规定，进行
系统化的、相互关联和协调的层次分解。结构层次越
往下层则项目组成部分的定义越详细,WBS最后构成
一份层次清晰，可以具体作为组织项目实施的工作依
据。
? WBS通常是 一种面向, 成果, 的, 树,,其最底层是
细化后的, 可交付成果,,该树组织确定了项目的整
个范围。但 WBS的形式并不限于, 树, 状，还有多种
形式。
某机构软件开发项目 WBS
1 立项
1.1 市场部经理确定课题
1.2 （任务提出方准备任务书或合同）
1.3 必要时由市场部经理与工程部经理协商确定
立项技术人员
1.4 必要时由立项技术人员编制项目任务书（合
同）
1.5 评审任务书（合同）
1.6 批准任务书（合同）
1.7 工程部经理确定课题组成员和课题组长
2 计划
2.1 课题组讨论任务书（合同）
2.2 建立任务书（合同）配置管理基线
2.3 确定项目开发模型和开发阶段
2.4 建立项目工作分解结构（ WBS）
2.5 估计项目规模、工作量、成本、关键资源
2.6 计划进度
2.7 计划配置管理工作
2.8 计划质量保证工作
2.9 编制项目计划文档
2.10 评审项目计划
3 需求分析
3.1 分析分配需求和参考系统
3.2 建立系统逻辑模型
3.3 分析功能性能等需求
3.4 编制软件需求规格说明文档
3.5 评审软件需求规格说明
3.6 建立配置管理基线
3.7 管理评审
4 设计
4.1 进行系统高层结构设计
4.2 进行系统部件和单元流程设计
4.3 编制软件设计说明文档
4.4 评审软件设计说明
4.5 建立配置管理基线
4.6 管理评审
5 实现
5.1 编程
5.2 调试
5.3 单元测试
5.4 建立配置管理基线
5.5 管理评审
6 集成及测试
6.1 设计和确定集成方案
6.2 设计集成测试
6.3 编制集成测试说明文档
6.4 实施集成及测试
6.5 实施配置控制
6.6 记录测试结果
6.7 完成集成测试说明文档
6.8 建立配置管理基线
6.9 管理评审
7 合格性测试
7.1 完成软件使用说明文档
7.2 设计合格性测试方案
7.3 计划合格性测试工作
7.4 编制合格性测试计划文档
7.5 评审合格性测试计划
7.6 设计合格性测试
7.7 编制合格性测试说明文档
7.8 实施合格性测试
7.9 实施配置控制
7.10 记录测试结果
7.11 分析测试结果
7.12 编制合格性测试报告文档
7.13 建立配置管理基线
7.14 管理评审
8 归档
8.1 准备归档材料
8.2 填写归档表格
8.3 提交归档
9 鉴定
9.1 查新
9.2 获得用户使用报告
9.3 提交鉴定申请
9.4 组建鉴定委员会
9.5 组建鉴定测试组
9.6 组建鉴定资料审查组
9.7 准备测试大纲
9.8 进行鉴定测试
9.9 进行鉴定资料审查
9.10 准备鉴定汇报
9.11 召开鉴定会议
9.12 填写相关表格
10 验收
10.1 提交验收申请
10.2 组建验收委员会
10.3 配置审计
10.4 准备验收汇报
10.5 召开验收会议
10.6 移交验收产品
10.7 填写相关表格
11 结束
11.1 召开项目结束会议
11.2 课题组长处理收尾事项
WBS图示意
XXX软件开发项目
需求分析 设计 实现 测试 项目管理
获
取
需
求
分
析
需
求
需
求
规
格
说
明
结
构
设
计
详
细
设
计
设
计
说
明
编
码
调
试 单元
测
试
集
成
测
试
合
格
性
测
试
WBS表示例
序号 活动和任务 紧前事件 负责人 估计工期 开始时间 结束时间 备注
1 需求分析 A 20
2 设计 1 B 20
3 实现 2 C 30
4 测试 1 A 70
5 验收 4 B 10
任务（工作）描述表
任务名
任务交付物
验收标准
技术条件
任务描述
假设条件
信息源
约束
其它
签名
工作列表
工作代码
工作名称
输入
输出
内容
负责单位
协作单位
子工作
指派责任人
? 目的, 对项目的每一项任务分配责任者
和落实责任 。
? 用途, 明确各单位或个人的责任, 便于
项目管理部门在项目实施过程中的管理
协调 。
? 依据, 以工作分解结构图表和项目组织
结构图表为依据制作此表 。
? 结果,工作责任分配表
责任分配表示例
角色 1 角色 2 角色 3 角色 4 角色 5 角色 6
任务 1 P=批准 F J
任务 2 F=负责 J P
任务 3 C=参加 F J P
任务 4 J=监督 F J P
任务 5 T=通报 F J P
任务 6 C F J P
确定搭接关系
? 任何工作的执行必须依赖于一定工作的完成，
也就是说它的执行必须在某些工作完成之后才
能执行，这就是 工作的先后依赖关系 。
? 工作的先后依赖关系有两种,
? 一种是工作之间本身存在的、无法改变的 逻辑关系 ；
? 另一种是人为组织确定的，两项工作可先可后的 组
织关系 。
? 先保证逻辑关系，后保证组织关系
工作之间的先后关系类型
? 结束到开始的关系
? 结束到结束的关系
? 开始到开始的关系
? 开始到结束的关系
? 结束到开始的关系
最为常用，它是一
种最为典型的逻辑
关系
A
B FST
A
B SST
A
B
FFT
A
B
SFT
案例讨论 — 仪表检测工作
仪表检测项目工作关系
估计规模、工作量、成本、工期
? 软件项目的工作量、成本和工期主要受
软件产品规模的制约
? 应当参照规模估计工作量、成本、工期
? 软件项目的成本主要受工作量制约
? 根据软件产品的规模和项目的工作量、
成本、工期，对各个子活动、任务进行
工作量、成本、工期的分解
? 估计的方法和程序在下一节介绍
编排进度计划
? 目标,制定项目的详细安排计划，明确每项工
作的起始终止时间，作为项目控制的有效手段
? 依据,项目内容的分解、各组成要素工作的先
后顺序、工作延续时间的估计结果
? 人员,安排时间进度时，项目主管要组织有关
职能部门参加，明确对各部门的要求，据此各
职能部门可拟定本部门的项目进度计划,
? 形式,项目的进度计划目前多采用网络计划技
术的形式，其有助于明确反映项目各工作单元
之间的相互关系，有利于项目执行过程中各工
作之间的协调与控制,
计划进度的常用方法和技术
? 横道图（ GANT，甘特图，条形图）
? 网络图
? 单代号网络图
? 双代号网络图
? CPM关键路径法
? PERT计划评审技术
? 表格
? Microsoft Project,P3
单代号网络图
? 节点及其编号（圆圈或矩形）表示一项
工作
? 箭线（直线和折线）表示相邻工作之间
的逻辑关系
? 线路为从起始接点开始，沿着箭线的方
向连续通过一系列箭线与接点，最后到
达终止接点的通路
单代号 —— 节点
? 节点必须唯一编号
? 可连续编号，也可间
断编号，但禁止重复
编号
? 箭线箭尾节点的编号
最好小于箭头节点的
编号
? 一项工作必须有唯一
的一个节点和编号
工作编号
工作名称
持续时间
工作编号
工作名称
持续时间
单代号 —— 箭线
? 实线（不用虚线）
? 箭线的水平投影应自
左向右，表示工作的
进展方向
单代号 —— 线路
单代号网络图绘图规则
? 必须正确表达工作的逻辑关系
? 严禁出现循环回路
? 不能出现双向箭头或无箭头的连
线
? 比能出现无箭尾节点的箭线和无
箭头节点的箭线
? 箭线不宜交叉（若交叉不可避免，
可采用过桥法或指向法连接）
? 只能有一个起始节点和一个终止
节点（必要时可设虚工作）
案例讨论 — 绘制网络图
开始
A
B
E
D
C
F
G
H
结束
网络计划时间参数计算
? 最早开始时间 ES
? 最早结束时间 EF
? 最迟开始时间 LS
? 最迟结束时间 LF
? 总时差 TF
? 自由时差 FF
最早时间参数计算
? 最早开始时间 ES
ES＝ MAX{紧前工作的 EF}
? 最早结束时间 EF
EF＝ ES＋工作延续时间 t
最早时间参数计算示例：顺排
最早参数时间计算示例
最早参数计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
最迟时间参数计算
? 最迟结束时间 LF
LF＝ MIN{紧后工作的 LS}
? 最迟开始时间 LS
LS＝ LF— 工作延续时间 t
最迟时间参数计算
最迟参数时间计算示例
最迟参数计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
时差 (机动时间 )计算
? 总时差的计算
总时差＝ LF— EF
或 总时差＝ LS— ES
? 自由时差
自由时差＝ min{ES(紧后工作 )}
— max{LF(紧前工作 )}
— 工作时间
或 自由时差＝ min{ES(紧后工作 )}
— ES — 工作时间
总工期 =MAX（活动最大的最早结束时间）
? 总时差：活动不改变计
划总工期的机动时间
? 活动在总时差的范围内
调整不影响项目的总工
期
? 总时差最小的活动是关
键活动
? 关键活动组成的路径是
关键路径
? 关键路径是工期最长
（等于总工期）的路径
? 自由时差：活动不改
变紧前紧后活动的计
划安排的机动时间
? 活动在自由时差的范
围内调整对项目计划
没有影响
网络计划时间参数计算 (复习 )
? 最早开始时间 ES＝ MAX{紧前工作的 EF
? 最早结束时间 EF＝ ES＋工作延续时间 t
? 最迟结束时间 LF＝ MIN{紧后工作的 LS}
? 最迟开始时间 LS＝ LF— 工作延续时间 t
? 总时差 TF＝ LF— EF＝ LS— ES
? 自由时差 FF
＝ min{ES(紧后工作 )}-max{LF(紧前工作 )}-工作时间
＝ min{ES(紧后工作 )}-ES-工作时间
= min{ES(紧后工作 )}-EF
总机动时间计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
时间计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
0 3
3 5
3 10
3 7
10 16
10 18
18 23
18 23 12 18
10 18 8 10
3 10
8 12
0 3
0
5
0
5
0
2 0
0
3
0
0
0
5
2
横道图示意
网络图示意
112/10
121/20
142/10 141/20
134/20 133/15 132/25 131/15
143/20
122/20 123/10
144/15
151/10 152/10 SS10 FS5
111/10 112/10
121/20
142/10 141/20
134/20 133/15 132/25 131/15
143/20
122/20 123/10
144/15
151/10 152/10 SS10 FS5
0 10 10 20 20 35 30 55 55 70 70 90 95 105
20 40 40 60 60 70
20 40 40 50 50 70 70 85
105 115
105 115 95 105
85 95 65 85 45 65
20 35 10 20 0 10 30 55 55 70 70 90
30 50 50 60 60 80 80 95
25
25 0
10
25 25
0
10 10 10 10
0 0 0
最早开始时间 总时差 最早结束时间
工作代码 工作名称 工期
最迟开始时间 自由时差 最迟结束时间
工作时间的压缩
? 工作时间的压缩是数学分析方法为了缩短项目
工期的一种特殊情况, 通常是由于遇到一些特
别的限制或者是其他进度目标的要求 。 延续时
间压缩的技术主要包括,
? 费用交换,在进度和费用之间往往存在一定的转换
关系, 这里的目的是寻求压缩进度所需追加的最小
费用, 或者在最佳费用限额确定下如何保证压缩的
工期最大, 寻求工期和费用的最佳结合点 。
? 并行处理,对于一个正常进行的工作可考虑按照并
行方式进行, 当然这种转换容易带来一定的风险 。
费用计划和资源计划
? 根据 WBS和进度安排制定费用计划
? 计划在项目过程中所需的资源
? 费用、资源、工期、进度间具有相关性
? 确定在不同阶段所需的人员资质、数量、
工作周期
? 确定需要的制约项目进展的关键资源计
划表
关键资源计划表示例
序号 名称 版本 /型号 数量 技术指标 使用起始时间 使用持续时间 备注
关于配置管理计划
? 配置管理是指：标识和确定系统中配置项的过
程, 在系统整个生存周期内控制这些项的投放
和更动, 记录并报告配置的状态和更动要求,
验证配置项的完整性和正确性
? 配置管理计划包括：人员组织结构与职责, 基
线与配置项, 配置项标识, 配置控制过程与权
限, 配置状态记录和统计报告, 配置审计等
? 有关配置管理以及配置管理计划的详细内容在
以后描述
关于质量
? 确定质量目标
? 确定过程和产品规程和标准
? 确定对各项工作的质量要求
? 计划和安排质量活动
? 评审、测试、配置管理
? 计划质量保证工作
? 项目组的质量工作与其它开发活动一起计划
? 有关项目组质量保证工作在项目计划中专门进
行，详细内容在以后描述
编制软件项目计划文档
? 按照规定的格式编制软件项目计划文档，记录
项目策划的结果
? 所有在项目策划过程中的假设条件、估计原始
数据应当在软件项目计划文档中记录
? 可以用电子文件作为软件项目计划的文档，或
将电子文件作为文档的附录
? 项目的配置管理计划和质量保证计划可以纳入
软件项目计划中，也可以单独形成文档
软件项目计划文档条目
1 范围
2 引用文档
3 软件开发管理
3.1 项目组织与资源
3.2 进度与里程碑
3.3 风险管理
3.4 安全保密
3.5 与其他承制方的接
口
3.6 与其它软件独立验
证与确认机构的接
口
3.7 转承制方的管理
3.8 正式审查
3.9 软件开发库
3.10 纠正过程
3.11 问题 /更改报告
4 软件工程
4.1 组织和资源
4.2 软件标准和研制程
序
4.3 非开发软件
5 正式合格性测试
5.1 组织机构和资源
5.2 测试方法 /基本原理
5.3 测试计划的假设条
件和约束
6 软件产品评价
6.1 组织机构和资源
6.2 软件产品评价规程
和工具
6.3 转承制方的产品
6.4 软件产品评价记录
6.5 依赖活动的产品评
价
7 软件配置管理
7.1 组织机构和资源
7.2 配置标识
7.3 配置控制
7.4 配置状态报表
7.5 配置审核
7.6 认可规格说明的准
备
7.7 配置管理主要里程
碑
8 其它软件开发功能
评审
? 软件项目计划必须进行评审
? 项目组成员、甲方代表、相关小组代表、质量
保证人员应当参加评审
? 高层管理人员对评审通过的软件项目计划进行
审查批准
? 批准生效的软件项目计划成为项目的基准计划
? 对软件项目计划实施管理和控制（配置管理）
练习题
? 对以下软件项目建立软件项目计划文档,
? 辅助银行处理定期储蓄取款业务的软件系统
? 与需求分析和设计的练习题相一致
? 缺少条件可自行假设
? 有关配置管理、风险等内容等后面的课
程结束后陆续添加
? 在复习前和其它练习题结果一起提交
软件项目的失败
? 如果定义阶段确定的需求不能被满足，如果大大超过了成本和进
度，如果需方不满意这个系统，那么这个项目就是失败了。
? 早在失败发生之前，有一系列的信号可以警告管理员有潜在的问
题,
1）开发方和需方之间没作什么交流讨论，提出项目计划和软件需求规
格说明时没有人提出建议或表示赞成，也没有经过严格的评审；
2）软件工程阶段性评审落在原进度之后，没有进行所需的修改就算完
成了，或者是在某一步无休止地反复；
3）在软件需求分析和概要设计之后，没有对进度和预算作变动；
4）在整个进度只进行了 20%时，程序就已编写出来了；
5）重新委派了开发人员。
? 上述危险信号是按其重要性依次列出的，管理员应及时地在项目
的早期就发现这些信号。
失败的托辞（ 1/8）
? 需求规格说明变动了
? 不管项目的复杂性如何，所有项目的需求规
格说明总会有不同程度的变动，管理员真正
应说的是,
1）早期分析做得不完全或很差；
2）项目估算得不正确；
3）计划得不完全或没有作计划；
4）用户从未审查过软件需求规格说明；
5）没有预料到预算或进度的变动带来的实际影响。
失败的托辞（ 2/8）
? 用户不知道他究竟需要什么
? 这是一种很典型的托辞，企图为拙劣的项目
辩解。管理员真正应说的是,
1）开发人员从未问过用户需要什么；
2）开发人员感到这个项目很有趣，所以决定照自
己的想法就这么去做它；
3）不称职的分析员和不称职的用户一起工作；
4）开发人员和用户之间没有进行交流讨论。
失败的托辞（ 3/8）
? 缺乏机时所以影响了开发
? 这一托辞将随着计算机资源的不断出现（如
终端和微型机都很容易获得）而越来越不成
,理由, 了。项目管理员应该说的是,
1）我没有计划好测试时间，直到年底才发觉机时
不够；
2）在讨论这个问题时，我缺乏想像力，没有想到
加夜班、周未加班或使用服务部门等方案。
失败的托辞（ 4/8）
? 供应商没有及时提供设备和软件
? 在 1965年那时 CPU和操作系统还在婴儿时期，
这曾经是个绝妙的托辞。但今天，管理员应
说的可能是,
1）据供应商说第一批货将在第三季度发出，我就不加思索
地认为第一台机器将交付给我；
2）由于我对使用新机器过于兴奋，以致忘了必须先使系统
正常工作起来；
3）除了管理不善之外，对项目落后于原定的进度我确实没
有什么合适的理由，所以我只好怪供应商。
失败的托辞（ 5/8）
? 我们造了一辆, 卡迪拉克, 而他们要的
是, 大众,
? 这种共同的托辞常见于首次使用计算机的情
形，或由不很精通的人操作该系统（例如翻
砂厂使用一个复杂的生产控制系统）的情形。
管理员真正应说的是,
1）我们从未问过用户需要什么；
2）我只是对自己学过的或实现过的东西更感兴趣，
而不是对用户如何使用该系统感兴趣。
失败的托辞（ 6/8）
? 估算差得太远了
? 当其它托辞都无济于事的情况下，这将是一
个很好的托辞，然而也只能用一次。因为这
样辩解，可能会引起反问：, 好，那么你的
估算是什么呢？,,因此这个托辞以后就不
能再用了。实际上这个托辞意味着,
1）我没有估算或计划这个项目；
2）我没有监督和管理这个项目，如果我管了的话，
可能在几个月之前就会告诉你估算是不精确的了。
失败的托辞（ 7/8）
? 人员流动过多，造成项目延期
? 很明显，人员的流动会影响项目的进展。然
而项目管理员应该承认他未搞清以下两点原
因,
1）是由于人员流动，才导致拙劣的项目；
2）还是由于这个项目本身是拙劣的，所以造成人
员流动。
失败的托辞（ 8/8）
? 最高层的管理人员没有支持
? 没有他们的支持确实会引起项目各方面的问
题。然而，项目管理员应说的可能是,
1）由于过去的表现，最高层管理人员对职员的能
力没有信心；
2）没有向最高层管理人员说明这个项目将带来的
影响。
失败的理由
? 软件项目失败有三类问题存在,
1）不适当的计划：拙劣地决定开发组织，模糊地定
义项目范围，不适当的资源，对需求的含糊说明，
缺乏预见性。
2）草率地评审或根本不评审：没有及时的、可评审
的里程碑，拙劣的文档，没有能主持评审的人员，
没有可依据的评审指导原则，用户／需方没参加评
审。
3）缺乏组织得很好的方法：没有明确的，或根本没
有设计方法，无组织地设计和编码，没有正规的测
试，缺乏标准，（没有很好地借鉴、继承和重用，
从而使得每个项目都要“重新发明车轮”。
明智地实现软件工程方法将为
防止软件项目的失败提供主
要的安全措施
谢谢！
汤铭端
68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
bicast@public3.bta.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第七讲
软件项目管理
软件项目策划
内容和目的
? 了解软件项目和软件项目管理的概念
? 了解对软件策划的要求
? 掌握软件策划的工作内容和过程
? 掌握软件项目计划文档的内容
? 了解软件项目计划文档的格式条目
项目与项目管理
项目
? 项目 是以一套独特的、相互联系的任务
为前提，有效地利用资源，为实现一个
特定的目标所做的努力。
? 项目在工作范围、计划进度和成本方面
都有明确界定的标准。
? 当客户 —— 愿意提供资金以实现需求的
组织或个人 —— 明确提出需求时，项目
就产生了。
项目概念要素
? 项目的总体属性,项目是一系列工作，
产品是项目的目的或结果。
? 项目的过程,项目是必须完成的、临时
性的、一次性的、有限的任务
? 项目的结果,项目都有一个特定的目标。
? 项目的共性,项目只能在资金、时间、
质量（三大目标）的约束下进行。
项目特征
? 项目有一个明确界定的目标 —— 一个期望的结
果或产品。
? 项目的执行要通过完成一系列相互关联的任务
来达到项目目标。
? 项目需要运用各种资源来执行任务。
? 项目有具体的时间计划或有限的寿命。
? 项目可能是独一无二的、一次性的努力。
? 每个项目都有客户。
? 项目包含一定的不确定性。
制约项目成功的因素
? 项目目标的成功实现通常受四个因素制约：工作范围、成本、进
度计划和客户满意度。
工作范围
成本 进度计划
客户
满意程度
? 实现项目目标就是在一定时间内、在预算内完成工作范围，以使
客户满意。
项目生命周期
识别
需求
提出
解决
方案
执行项目 结束项目
时间
投
入
力
量
项目管理
? 项目管理 是通过项目经理和项目组织的努力，运用系统理
论和方法对项目及其资源进行计划、组织、协调、控制，
旨在实现项目的特定目标的管理方法。
? 项目管理是一种管理方法体系。
? 项目管理的 对象 是项目。
? 项目管理的主要 目的 是实现项目的预定目标。
? 项目管理的 职能 是对组织的资源进行计划、组织、指挥、
控制。
? 项目管理的 任务 是对项目及其资源的计划、组织、协调、
控制。
? 项目管理运用系统理论和思想。
? 项目管理职能主要由项目经理执行。
项目管理的要素
? 人员（ People）
? 软件工程是人的智力密集的劳动
? 问题（ Problem）
? 必须明确项目的目的和范围，考虑可选的解
决方案
? 过程（ Process）
? 提供框架
项目经理
? 项目经理的职责就是确保客户满意。
? 对项目经理的挑战是防止、预测和克服计划的意外情
况，以便能够在预算内按时地、使客户满意地实现项
目工作范围。
? 良好的计划和沟通对于防止问题发生，以及当问题发
生时，使问题对实现项目目标的影响降到最小，都是
很必要的。
? 项目经理必须在计划和沟通上提前做好准备，并领导
项目团队实现项目目标。
? 客户满意意味着把客户作为一个合作伙伴加入到项目
中来，在整个项目过程中积极参与，以获得项目的成
功。
项目管理的基本内容
? 项目定义
? 项目计划
? 项目执行
? 项目控制
? 项目结束
? 项目管理被认为是一种建立在公认的管理原理
基础上的方法和技术，用于计划、估算和控制
项目活动，以工具规范在预算之内，按时实现
项目的最终目标。
PDCA环
? 戴明环 —— PDCA
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理
P
D
C
A
项目管理过程
项目管理过程
就是
制定计划
然后
按计划工作
软件项目与软件项目管理
项目与软件项目
? 项目是一个被承担来产生唯一的产品或服务的
临时工作。
? 项目包括一组人员、资源和活动，满足下列共
同特征,
? 主要目标是产生产品、服务和结果。
? 项目具有共知的起始、结束点，即项目是临时的。
? 项目不是多数机构常规、正在进行的工作的一部分，
即它通常具有唯一的需求。有些机构存在仅为了执
行项目。
? 软件项目是强调将软件作为其产品、服务或结
果的项目。
软件项目与一般项目的区别
? Watts Humphrey,
? 软件通常更复杂。
? 软件更改相对更容易出现。
? 许多晚期发现的硬件问题被要求通过软件更改来处理。
? 由于其低廉的重复生产成本，软件没有发布生产的自然约
束。
? 软件学科不是建立在自然科学的基础上，它缺乏关于可行
的测试与设计模型的成熟技术。
? 软件通常是一个完整系统的集成元素，这增加了其复杂性
和产生后期更改的出现。
? 软件通常更可见，因此更多出现需求更改和更多遭受用户
抱怨。
软件项目管理
? 由于软件与非软件产品、服务、结果不同，软件项目
管理也有其特别之处。关键是管理必须意识到软件项
目管理的独特领域以预防问题。
? 软件项目管理是保证项目成功的方法和技术，它被要
求,
? 预见并因此预防和最小化问题的不利影响
? 作出及时和坚定的决定
? 当问题发生时解决问题
? 对项目的行为、过程、活动、资源、产品和结果明
确职责
? 软件项目管理方法的执行被许多因素所确定，例如人
员、机构、合同要求和项目复杂性。
软件项目组织
项目组织
? 职能式
? 项目式
? 矩阵式
? 弱矩阵
? 平衡矩阵
? 强矩阵
软件的项目式组织结构
软件
经理
项目
经理 1
项目
经理 2
项目
经理 3
审查
小组
第 1 组 第 2 组 第 3 组 第 1 组 第 2 组 第 3 组 第 1 组 第 2 组 第 3 组
程序设计小组的组织
? 程序设计小组的人数不能太多，否则组员间彼此通信
时间将多于程序设计时间，而且出现接口错误的可能
性增加。
? 一般来说，程序设计小组的规模应该较小，视工程规
模以 2-8人为宜。若项目规模大，可同时设几个小组，
每个小组承担一部分任务。
? 小组规模小，不仅可以减少通信问题，而且还有其它
好处。如，容易确定小组的质量标准，而且用民主方
式确定的标准更容易被大家遵守；组员间关系密切，
能够互相学习等。
? 小型的程序设计小组通常采用非正式的组织方式。
软件项目组织
? 民主制程序员组
? 主程序员组
? 现代程序员组
? 软件项目组
民主制程序员组
? 有两种极端方法可用来组织程序员组，
这两种组织方法分别称为
? 民主制程序员组
? 主程序员组
? 构成民主制程序员组的基本概念 是, 无
私编程,
无私编程
? 必须改变评价程序员价值的标准，每名程序员都
应该鼓励该组其他成员找出自己编写的代码中的
错误。
? 不要认为存在错误是坏事，而应该认为是正常的
事情，应该把找出模块中的一个错误看作是取得
了一个胜利。
? 任何人都不能嘲笑程序员所犯的编码错误。程序
员组作为一个整体，将培养一种平等的团队精神，
坚信, 每个模块都是属于整个程序员组的，而不
是属于某个人的, 。
? 一组无私的程序员将构成一个民主制程序员组。
民主制程序员组的特点
? 民主制程序员组的一个重要特点是，小组成员完全平
等，享有充分民主，通过协商做出技术决策。
? 小组成员间的通信是平行的，如果一个小组有 n个成员，
则可能的通信信道有 n(n-1)/2条。
? 一般说来，程序设计小组的规模应该比较小，以 2～ 8
名成员为宜。
? 如果项目规模很大，用一个小组不能在预定时间内完
成开发任务，则应该使用多个程序设计小组，每个小
组承担工程项目的一部分任务，在一定程度上独立自
主地完成各自的任务。
? 系统总体设计应该能够保证由各个小组负责开发的各
部分之间的接口是良好定义的，并且是尽可能简单的。
民主制程序员组的特点
? 小组规模小，不仅可以减少通信问题，而且还有其他
好处。例如，容易确定小组的质量标准，而且用民主
方式确定的标准更容易被大家遵守；组员间关系密切，
能够互相学习等。
? 民主制程序员组通常采用非正式的组织方式，也就是
说，虽然名义上有一个组长，但是他和组内其他成员
完成同样的任务。在这样的小组中，由全体讨论决定
应该完成的工作，并且根据每个人的能力和经验分配
适当的任务。
? 为了使少数经验丰富、技术高超的程序员在软件开发
过程中能够发挥更大作用，程序设计小组可以采用主
主程序员组
? 美国 IBM公司在 20世纪 70年代初期开始采
用主程序员组的组织方式。采用这种组
织方式主要出于下述几点考虑,
? 软件开发人员多数比较缺乏经验；
? 程序设计过程中有许多事务性的工作，例如，
大量信息的存储和更新；
? 多渠道通信很费时间，将降低程序员的生产
率。
典型的主程序员组
? Baker描述的一个典型的主程序员组
? 由主程序员、后备程序员、编程秘书以及 1～ 3名程
序员组成
? 在必要的时候，该组还有其他领域的专家 (例如，
法律专家，财务专家等 )协助
主程序员组的三人核心
1） 主程序员是经验丰富, 能力强的高级程序员,
全面负责系统的设计, 编码, 测试和安装；
2） 辅助程序员也应该技术熟练且富于经验, 他
协助主程序员并且在必要时能代替主程序员 。
他的主要任务是设计测试方案和分析测试结果,
以验证主程序员的工作 。
3） 程序管理员完成和项目有关的全部事务性工
作, 如：提交上机程序, 保存运行记录, 进行
软件配置管理等 。
人员 -时间折中
根据 应用规模和类型，可能需要临时或长期向组内增加
一些其它方面的专门人员，如：项目管理员，工具员，
文档编辑，测试员，一个或多个后援程序员。
这种人员组织形式的成败主要取决于主程序员的技术和
管理水平。
人员 -时间 折中 定律：在时间允许的情况下，适当减少人
员会提高工作效率，降低软件开发成本。即软件开发
宁可时间长一点，人员少一点。这样可以大大减少人
员之间的通信开销，工作效率会更高。
现代程序员组
? 实际的, 主程序员, 应该由两个人来担任,
? 一个技术负责人，负责小组的技术活动
? 一个行政负责人，负责所有管理决策
大项目的组织
? 由于程序员组的成员人数不宜过多，当软件项目规模
较大时，应该把程序员分成若干个小组。
? 产品的实现作为一个整体是在项目经理的指导下进行
的，程序员向他们的组长汇报工作，而组长向项目经
理汇报工作。当产品规模更大时，可以增加中间管理
层次。
民主制程序员组和主程序员组的结合
? 把民主制程序员组和主程序员组的优点结合起来的另一种方法，
是在合适的地方采用分散做决定的方法。
? 这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的
积极性和主动性，集思广益攻克技术难关。这种组织方式对于适
合采用民主方法的那类问 题 (例如，研究性项目或遇到技术难题需
要用集体智慧攻关 )非常有效。
软件项目组
? 如前所述，程序员组的组织方式主要用
于实现阶段，当然，也适用于软件生命
周期的其他阶段 (当考虑在更广阔范围的
应用时，把程序员组更名为软件项目组
更恰当一些 )。本节从更广阔的角度进一
步讨论软件项目组的组织方式。
通用的项目组组织方式
? Mantei提出了下述的三种通用的项目组
组织方式
? 民主分权式
? 控制分权式
? 控制集权式
民主分权式
? Democratic Decentralized，缩写为 DD
? 这种软件工程小组没有固定的负责人
?, 任务协调人, 是临时指定的，随后将
由协调别的任务的人取代
? 用全体组员协商一致的方法对问题及解
决问题的方法做出决策
? 小组成员间的通信是平行的
控制分权式
? Controlled Decentralized，缩写为 CD
? 有一个固定的负责人，他协调特定任务的完成
并指导负责子任务的下级领导人的工作
? 解决问题仍然是一项群体活动，但是通过小组
负责人在子组之间划分任务来实现解决方案
? 子组和个人之间的通信是平行的，但是也有沿
着控制层的上下级之间的通信
控制集权式
? Controlled Centralized，缩写为 CC
? 小组负责人管理顶层问题的解决过程并
负责组内协调
? 负责人和小组成员之间的通信是上下级
式的 。
选择软件组织结构的 7个因素
? 待解决的问题的困难程度；
? 要开发的程序的规模 (用代码行或功能点度量 )；
? 小组成员在一起工作的时间 (小组生命期 )；
? 问题能够被模块化的程度；
? 对待开发的系统的质量和可靠性的要求；
? 交付日期的严格程度；
? 项目要求的社交 (通信 )程度。
项目特性对组织方式的影响
小组类型
项目特性
DD CD CC
困难程度
高 ×
低 × ×
规模
大 × ×
小 ×
小组生命期
短 × ×
长 ×
项目特性对组织方式的影响
模块化程度
高 × ×
低 ×
可靠性
高 × ×
低 ×
支付日期
紧 ×
松 × ×
社交
高 ×
低 × ×
Mantei组织方式的比较
? 集权式结构能够更快地完成任务，它最适于处理简单
问题。分权式的小组比起个人来，能够产生更多，更
好的解决方案，这种小组在解决复杂问题时成功的可
能性更大。因此,CD或 CC小组结构能够成功地用来解
决简单的问题，而 DD结构则适于解决难度较大的问题。
? 小组的性能与必须进行的通信量成反比，所以开发规
模很大的项目时最好采用 CC或 CD结构的小组。
? 小组生命期长短影响小组的士气。经验表明,DD小组
结构能导致较高的士气和较高的工作满意度，因此适
合于生命期长的小组。
Mantei组织方式的比较
? DD小组结构最适于解决模块化程度较低的问题，因为
解决这类问题需要更大的通信量。如果能够达到较高
的模块化程度 (人们自己独自做自己的事情 )，则 CC或
CD结构更适宜。
? 人们曾经发现,CC和 CD小组产生的缺陷比 DD小组少，
但是这些数据在很大程度上取决于小组采用的质量保
证活动。
? 完成同一个项目，分权式结构通常需要比集权式结构
更多的时间，不过当需要高社交性时分权式结构是最
适宜的。
? 历史上最早的软件项目组是控制集权式 (CC)结构，当
时人们把这样的软件项目组称为主程序员组。
Constantine四种组织范型
? Constantine提出了软件工程小组的下述
4种, 组织范型,
? 封闭式范型
? 随机式范型
? 开放式范型
? 同步式范型
封闭式范型
? 按照传统的权力层次来组织项目组 (类似
于 CD小组 )
? 当开发与过去已经做过的产品相似的软
件时可以工作得很好
? 在这种封闭式范型下难以进行创新性的
工作。
随机式范型
? 松散地组织项目组
? 小组工作依靠小组成员发挥个人的主动
性
? 当需要创新或技术上的突破时，用随机
式范型组织起来的项目组能工作得很好
? 当需要, 有次序地执行, 才能完成任务
时，这样的项目组就可能陷入困境
开放式范型
? 试图以一种既具有封闭式范型的控制性，
又包含随机式范型的创新性的方式来组
织项目组
? 通过大量协商和基于一致意见做出的决
策，项目组成员相互协作完成工作任务
? 用开放式范型组织起来的项目组很适于
解决复杂问题
? 但是可能没有其他类型小组的效率高
同步式范型
? 按照对问题的自然划分，组织项目组成
员各自解决一些子问题
? 他们之间很少有主动的通信需求
有关组织结构的注记
? 对任何软件项目而言，最关键的因素都
是承担项目的人员
? 必须合理地组织项目组，使项目组有较
高生产率
?, 最佳的, 小组结构取决于管理风格、
组里的人员数目和他们的技术水平，以
及所承担的项目的难易程度
团队沟通与协调的方式
? 正式、非个人方式：使用文档、交付物、备忘
录、里程碑、进度与控制工具、修改请求、错
误跟踪报告、中心库数据
? 正式、个人间方式：管理评审、技术评审、代
码审查
? 非正式、个人间方式：信息传播、问题解决、
小组讨论
? 电子通信：电子邮件、电子公告栏,WEB站点、
视频会议
? 个人间的网络：与小组外人员讨论
软件项目定义
项目定义
? 定义在项目范围内要做的工作
? 回答好五个主要问题,
? 被提出的问题是什么？
? 项目的目的是什么？
? 为实现该目的，有哪些目标是必要的？
? 如果项目成功，将如何确认？
? 是否存在可能影响项目成功的假设、风险、
障碍？
项目定义
? 项目目标管理
? 项目目标：实施项目所要达到的预期结果。
? 项目范围管理
? 项目范围：为了成功达到目标，项目所规定
要做的。即为项目界定一个界限，划定哪些
方面是属于项目要做的，哪些不应该包括在
项目之内，定义项目管理的工作边界，确定
项目的主要交付产品。
项目目标的特点
? 多目标性 。
? 基本目标：时间、成本、技术性能
? 目标间会冲突，需要权衡
? 优先性 。权重。
? 层次性 。项目目标的表达通常有 3个层次
? 战略性目标，总体目标，项目使命
? 策略性目标，具体目标
? 具体计划，说明如何实现目标
确定项目目标的意义
? 明确项目及项目组成员共同努力的方向。
作为各方沟通的方式。
? 产生激励作用。
? 为制定项目计划打下基础，为项目计划
指明方向。
? 作为评价项目成功的依据。
确定项目目标的方式
? 项目的目标应该被所有项目组成员及组织内各
个层次的经理人员所了解。
? 项目目标一般由项目的发起人或提议人来确定。
? 项目经理是确定项目目标的重要主体。项目经
理对项目目标的正确理解与定义决定了项目的
成败。
? 为了明确定义项目如何才算完成，怎样才算成
功，最终结果如何，需要对目标具体描述。
? 项目目标的确定有一个由一般到具体逐渐细化
的过程，特别是对于 R&D项目。
描述项目目标的准则
应该
? 定量的、可度量的
? 使每个项目成员都能
清楚认识
? 现实的
? 简单的
? 面向结果的
? 能够起激励作用
不应该
? 定性、不可度量的
? 与项目成员无关
? 理想化的
? 复杂的
? 面向成本的
? 无激励作用
项目目标的基本内容
? 成果、交付物、功能、质量
? 工期、对外承诺的里程碑
? 费用
项目的目标管理
? 目标管理是一种把总体目标与具体计划
向联系的管理方式。
? 目标管理的过程是一个参与式的过程,
? 高层管理人员设定总体目标，该目标作为下
属制定各自工作计划的依据；
? 下属员工根据该目标和各自的期望相应地确
定每个人的职责范围和工作结果；
? 经理人员定期对工作结果进行评价。
目标管理的优点
? 有效激励员工，调动积极性
? 面向结果而不是面向过程
? 为经理人员及下属提供一种有效的沟通渠道
? 使项目组成员更加注重组织目标，了解各自工
作结果与组织目标的关系，明确对项目目标实
现的贡献大小
? 是一种系统的管理方法，有效连接组织目标、
部门目标、项目目标、个人目标
确定项目范围的意义
? 提高费用、时间和进度估算的准确性。
? 确定进度测量和控制的基准。
? 有助于清楚地分派责任。
? 正确确定项目范围对项目成功非常重要，如果
确定的不好，会导致意外的变更，从而打断实
施步骤，造成返工，延长完成时间，降低劳动
生产率，影响成员的干劲，造成最终项目费用
的提高。
项目范围的管理
? 对项目应该包括什么和不应该包括什么
进行定义和控制。
? 启动：开始进入项目。
? 范围计划：起草书面的范围说明书。
? 范围定义：把项目的主要可交付成果划分为
较小的、更容易管理的部件。
? 范围核实：确认项目范围定义的可接受性。
? 范围变化控制：对变化进行控制。
软件项目策划
项目计划（策划 -Planning）
? 计划,计划是为实现一定目标而科学地预测并
确定未来的行动方案。
? 计划解决三个问题：确定目标，确定为达到目标的
行动时序，确定行动所需的资源比例
? 项目计划,根据项目目标对项目实施工作进行
的各项活动作出周密安排。
? 项目计划围绕项目目标的完成系统地确定项目的任
务、安排任务进度、编制完成任务需要的资源预算
等，从而保证项目能够在合理的工期内，用尽可能
低的成本和尽可能高的质量完成。
项目计划的目的
? 确定并描述为完成项目目标所需的各项
任务（活动）范围。
? 确定负责执行项目各项任务（活动）的
全部人员。
? 制定各项任务（活动）的时间进度表。
? 阐明各项任务（活动）所必需的人力、
物力、财力。
? 确定各项任务（活动）的预算。
项目计划的作用
? 确定人员、工作的责任范围、地位、职权，以便安要
求去指导和控制项目工作，减少风险
? 促进项目组、委托人、管理部门的交流与沟通，增强
客户满意度，使项目工作协调一致，并了解关键因素
? 明确奋斗目标、实现目标的方法、途径、期限，确保
以最小的时间、成本、资源实现目标
? 作为分析、协商、记录项目范围变化的基础，约定时
间、人员、经费的基础
? 了解结合部在何处，并使结合部最少
? 把叙述性报告的需要减少到最低量。
项目计划的原则
? 目的性,计划制定的目的是实现目标。
? 系统性,计划与子计划成为相关又独立
的系统。
? 动态性,动态以适应不断变化的环境。
? 相关性,计划与子计划相关。
? 职能性,项目计划以项目何项目管理的
总体及职能为出发点，涉及个管理部门。
项目基准计划
? 项目基准计划是项目在最初启动时订出
的计划，即初始拟定的计划。
? 在项目管理过程中，对项目基准计划与
实际进展计划进行比较、对照、参考，
便于对变化进行管理与控制，从而监督
保证使项目计划得到顺利实施。
项目计划的制作过程和形式
? 概念性计划 。自上而下的计划。
? 确定项目的工作分解结构，并根据任务进行估计，
从而汇总出最高层的项目计划。
? 详细计划 。由下而上的计划。
? 制定详细、包括所有具体任务的工作分解结构，自
下而上汇总，成为详细项目计划。
? 滚动计划 。
? 用滚动的方法对可预见的将来逐步制定详细计划，
随着项目的推进，分阶段地重估自上而下计划制定
过程中所定的进度和预算。
项目计划管理的基本问题
? 做什么,明确的目标
? 如何做,制定工作分解结构实现目标
? 谁去做,将工作具体分配到人和机构
? 何时做,确定工作的延续、开始时间
? 花费多少,实施项目所需费用
项目计划过程的步骤
? 定义产品。含中间产品
? 确定任务。建立 WBS。
? 建立逻辑关系图。紧前任务。
? 为任务分配时间。
? 确定项目组成员的可支配时间。
? 为任务分配资源并进行平衡。
? 确定管理支持性任务。 15%~20%规则。
? 重复上述过程直到完成。
? 准备计划汇总。
项目进度计划（ Schedule)
? 项目进度计划是在 WBS的基础上对项目、活动
做出的一系列时间计划。
? 进度计划将表示预计、实际在何时开始。
? 保证按时获利以补偿已经发生的费用支出；
? 协调资源；
? 使资源在需要时可以利用；
? 预测在不同时间上所需的资金和资源的级别以便赋
予项目以不同的优先级；
? 满足严格的完工时间约束。
项目计划的工具
? 工作分解结构（ WBS）
? 线性责任图（ LRC）
? 项目行动计划表
? 图示评审技术（ GERT）
? 关键路径法（ CPM）
? 计划评审技术（ PERT）
项目策划 — SW-CMM的要求
活动 1 软件工程组参加项目建议群组。
活动 2 在整个项目策划的早期阶段起动软件项目策划，此两项
策划平行进行。
活动 3 在项目的整个生存期内，软件工程组和其它受影响的组
一起参加整个项目的策划。
活动 4 高级管理者参加按照已文档化的规程评审对组织外部的
个人和组所作的软件项目约定。
活动 5 识别或确定具有可管理规模的预先规定阶段的软件生存
周期。
活动 6 按照已文档化的规程制定项目的软件开发计划。
活动 7 对有关软件项目的计划建立文档。
活动 8 识别为建立和保持对软件项目的控制所必须的工作产品。
项目策划 — SW-CMM的要求
活动 9 按照已文档化的规程导出对软件工作产品规模
（或对软件工作产品规模的更改）的估计。
活动 10 按照已文档化的规稆出对软件项目的工作量及成
本的估计。
活动 11 按照已文档化的规程导出对项目的关键计算机资
源的估计。
活动 12 按照已文档化的规程导出项目的软件进度表。
活动 13 对与项目成本资源、进度和技术方面相联系的软
件风险进行鉴别、评估和建立文档。
活动 14 制定关于项目软件工程设施和支持工具的计划。
活动 15 记录软件策划数据。
软件项目策划过程
? 界定目标
? 确定开发模型
? 确定里程碑
? 阶段设置和工作分解
? 编排进度计划
? 成本计划和资源计划
? 关于配置管理计划
? 关于质量
? 编制软件项目计划文档
? 评审
界定目标
? 明确项目的目标
? 成果、工期、成本
? 界定项目的范围
? 用工作陈诉（ Statement of Work,SOW ）
描述项目目标和范围
? 根据项目的目标和范围进行项目策划
工作陈述
? 项目的工作陈述, 包括目标和范围
? 目标用一两句话, 概括说明开展项目的
目的要求, 以及顾客和最终用户
? 项目范围是为完成项目而对各参数、执
行的标准和约束条件进行的明确的简短
说明，项目约束通常与进度（时间）、
质量、成本相对应，并与项目的可交付
性直接相关
项目描述表格示例
项目名称
项目目标
交付物
交付物完成准则
工作描述
工作规范
所需资源估计
重大里程碑
项目负责人审核意见
签名,日期,
确定开发模型
? 瀑布模型
? 增量模型
? 渐进模型
? 原型模型
? 螺旋模型
? RAD模型
? 基于构件的开发模型
? 喷泉模型
? RUP模型
软件开发模型的选择
1）模型应符合软件本身的性质（规模、复杂性）
2）模型应满足软件应用系统整体开发进度要求
3）模型应有可能控制并消除软件开发风险
4）模型应有可用的计算机辅助工具（如快速原
型工具）的支持
5）模型应与用户和软件开发人员的知识和技能
相匹配
6）模型应有利于软件开发的管理与控制
确定里程碑
? 确定对软件项目的进行和成败具有关键
和标志性意义的事件，作为软件项目的
里程碑事件
? 根据工期和甲方的要求，确定合理的里
程碑事件达到控制时刻
? 参照里程碑计划进行详细的软件项目策
划
里程碑计划表示例
1月 2月 3月 4月 5月 6月
里程碑事件 上中下 上中下 上中下 上中下 上中下 上中下
需求分析完成
设计完成
编码完成
集成完成
合格性测试完成
阶段设置和工作分解
? 目的,明确项目所包含的各项工作
? 内容,项目分解就是先把复杂的项目逐
步分解成一层一层的要素（工作），直
到具体明确为止,
? 工具,项目分解的工具是工作分解结构
ＷＢＳ原理，它是一个分级的树型结构，
是一个对项目工作由粗到细的分解过程。
工作分解结构
? WBS(Work Breakdown Structure)主要是将一个项目分
解成易于管理的几个部分或几个细目，以便确保找出
完成项目工作范围所需的所有工作要素。它是一种在
项目全范围内分解和定义各层次工作包的方法,WBS
按照项目发展的规律，依据一定的原则和规定，进行
系统化的、相互关联和协调的层次分解。结构层次越
往下层则项目组成部分的定义越详细,WBS最后构成
一份层次清晰，可以具体作为组织项目实施的工作依
据。
? WBS通常是 一种面向, 成果, 的, 树,,其最底层是
细化后的, 可交付成果,,该树组织确定了项目的整
个范围。但 WBS的形式并不限于, 树, 状，还有多种
形式。
某机构软件开发项目 WBS
1 立项
1.1 市场部经理确定课题
1.2 （任务提出方准备任务书或合同）
1.3 必要时由市场部经理与工程部经理协商确定
立项技术人员
1.4 必要时由立项技术人员编制项目任务书（合
同）
1.5 评审任务书（合同）
1.6 批准任务书（合同）
1.7 工程部经理确定课题组成员和课题组长
2 计划
2.1 课题组讨论任务书（合同）
2.2 建立任务书（合同）配置管理基线
2.3 确定项目开发模型和开发阶段
2.4 建立项目工作分解结构（ WBS）
2.5 估计项目规模、工作量、成本、关键资源
2.6 计划进度
2.7 计划配置管理工作
2.8 计划质量保证工作
2.9 编制项目计划文档
2.10 评审项目计划
3 需求分析
3.1 分析分配需求和参考系统
3.2 建立系统逻辑模型
3.3 分析功能性能等需求
3.4 编制软件需求规格说明文档
3.5 评审软件需求规格说明
3.6 建立配置管理基线
3.7 管理评审
4 设计
4.1 进行系统高层结构设计
4.2 进行系统部件和单元流程设计
4.3 编制软件设计说明文档
4.4 评审软件设计说明
4.5 建立配置管理基线
4.6 管理评审
5 实现
5.1 编程
5.2 调试
5.3 单元测试
5.4 建立配置管理基线
5.5 管理评审
6 集成及测试
6.1 设计和确定集成方案
6.2 设计集成测试
6.3 编制集成测试说明文档
6.4 实施集成及测试
6.5 实施配置控制
6.6 记录测试结果
6.7 完成集成测试说明文档
6.8 建立配置管理基线
6.9 管理评审
7 合格性测试
7.1 完成软件使用说明文档
7.2 设计合格性测试方案
7.3 计划合格性测试工作
7.4 编制合格性测试计划文档
7.5 评审合格性测试计划
7.6 设计合格性测试
7.7 编制合格性测试说明文档
7.8 实施合格性测试
7.9 实施配置控制
7.10 记录测试结果
7.11 分析测试结果
7.12 编制合格性测试报告文档
7.13 建立配置管理基线
7.14 管理评审
8 归档
8.1 准备归档材料
8.2 填写归档表格
8.3 提交归档
9 鉴定
9.1 查新
9.2 获得用户使用报告
9.3 提交鉴定申请
9.4 组建鉴定委员会
9.5 组建鉴定测试组
9.6 组建鉴定资料审查组
9.7 准备测试大纲
9.8 进行鉴定测试
9.9 进行鉴定资料审查
9.10 准备鉴定汇报
9.11 召开鉴定会议
9.12 填写相关表格
10 验收
10.1 提交验收申请
10.2 组建验收委员会
10.3 配置审计
10.4 准备验收汇报
10.5 召开验收会议
10.6 移交验收产品
10.7 填写相关表格
11 结束
11.1 召开项目结束会议
11.2 课题组长处理收尾事项
WBS图示意
XXX软件开发项目
需求分析 设计 实现 测试 项目管理
获
取
需
求
分
析
需
求
需
求
规
格
说
明
结
构
设
计
详
细
设
计
设
计
说
明
编
码
调
试 单元
测
试
集
成
测
试
合
格
性
测
试
WBS表示例
序号 活动和任务 紧前事件 负责人 估计工期 开始时间 结束时间 备注
1 需求分析 A 20
2 设计 1 B 20
3 实现 2 C 30
4 测试 1 A 70
5 验收 4 B 10
任务（工作）描述表
任务名
任务交付物
验收标准
技术条件
任务描述
假设条件
信息源
约束
其它
签名
工作列表
工作代码
工作名称
输入
输出
内容
负责单位
协作单位
子工作
指派责任人
? 目的, 对项目的每一项任务分配责任者
和落实责任 。
? 用途, 明确各单位或个人的责任, 便于
项目管理部门在项目实施过程中的管理
协调 。
? 依据, 以工作分解结构图表和项目组织
结构图表为依据制作此表 。
? 结果,工作责任分配表
责任分配表示例
角色 1 角色 2 角色 3 角色 4 角色 5 角色 6
任务 1 P=批准 F J
任务 2 F=负责 J P
任务 3 C=参加 F J P
任务 4 J=监督 F J P
任务 5 T=通报 F J P
任务 6 C F J P
确定搭接关系
? 任何工作的执行必须依赖于一定工作的完成，
也就是说它的执行必须在某些工作完成之后才
能执行，这就是 工作的先后依赖关系 。
? 工作的先后依赖关系有两种,
? 一种是工作之间本身存在的、无法改变的 逻辑关系 ；
? 另一种是人为组织确定的，两项工作可先可后的 组
织关系 。
? 先保证逻辑关系，后保证组织关系
工作之间的先后关系类型
? 结束到开始的关系
? 结束到结束的关系
? 开始到开始的关系
? 开始到结束的关系
? 结束到开始的关系
最为常用，它是一
种最为典型的逻辑
关系
A
B FST
A
B SST
A
B
FFT
A
B
SFT
案例讨论 — 仪表检测工作
仪表检测项目工作关系
估计规模、工作量、成本、工期
? 软件项目的工作量、成本和工期主要受
软件产品规模的制约
? 应当参照规模估计工作量、成本、工期
? 软件项目的成本主要受工作量制约
? 根据软件产品的规模和项目的工作量、
成本、工期，对各个子活动、任务进行
工作量、成本、工期的分解
? 估计的方法和程序在下一节介绍
编排进度计划
? 目标,制定项目的详细安排计划，明确每项工
作的起始终止时间，作为项目控制的有效手段
? 依据,项目内容的分解、各组成要素工作的先
后顺序、工作延续时间的估计结果
? 人员,安排时间进度时，项目主管要组织有关
职能部门参加，明确对各部门的要求，据此各
职能部门可拟定本部门的项目进度计划,
? 形式,项目的进度计划目前多采用网络计划技
术的形式，其有助于明确反映项目各工作单元
之间的相互关系，有利于项目执行过程中各工
作之间的协调与控制,
计划进度的常用方法和技术
? 横道图（ GANT，甘特图，条形图）
? 网络图
? 单代号网络图
? 双代号网络图
? CPM关键路径法
? PERT计划评审技术
? 表格
? Microsoft Project,P3
单代号网络图
? 节点及其编号（圆圈或矩形）表示一项
工作
? 箭线（直线和折线）表示相邻工作之间
的逻辑关系
? 线路为从起始接点开始，沿着箭线的方
向连续通过一系列箭线与接点，最后到
达终止接点的通路
单代号 —— 节点
? 节点必须唯一编号
? 可连续编号，也可间
断编号，但禁止重复
编号
? 箭线箭尾节点的编号
最好小于箭头节点的
编号
? 一项工作必须有唯一
的一个节点和编号
工作编号
工作名称
持续时间
工作编号
工作名称
持续时间
单代号 —— 箭线
? 实线（不用虚线）
? 箭线的水平投影应自
左向右，表示工作的
进展方向
单代号 —— 线路
单代号网络图绘图规则
? 必须正确表达工作的逻辑关系
? 严禁出现循环回路
? 不能出现双向箭头或无箭头的连
线
? 比能出现无箭尾节点的箭线和无
箭头节点的箭线
? 箭线不宜交叉（若交叉不可避免，
可采用过桥法或指向法连接）
? 只能有一个起始节点和一个终止
节点（必要时可设虚工作）
案例讨论 — 绘制网络图
开始
A
B
E
D
C
F
G
H
结束
网络计划时间参数计算
? 最早开始时间 ES
? 最早结束时间 EF
? 最迟开始时间 LS
? 最迟结束时间 LF
? 总时差 TF
? 自由时差 FF
最早时间参数计算
? 最早开始时间 ES
ES＝ MAX{紧前工作的 EF}
? 最早结束时间 EF
EF＝ ES＋工作延续时间 t
最早时间参数计算示例：顺排
最早参数时间计算示例
最早参数计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
最迟时间参数计算
? 最迟结束时间 LF
LF＝ MIN{紧后工作的 LS}
? 最迟开始时间 LS
LS＝ LF— 工作延续时间 t
最迟时间参数计算
最迟参数时间计算示例
最迟参数计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
时差 (机动时间 )计算
? 总时差的计算
总时差＝ LF— EF
或 总时差＝ LS— ES
? 自由时差
自由时差＝ min{ES(紧后工作 )}
— max{LF(紧前工作 )}
— 工作时间
或 自由时差＝ min{ES(紧后工作 )}
— ES — 工作时间
总工期 =MAX（活动最大的最早结束时间）
? 总时差：活动不改变计
划总工期的机动时间
? 活动在总时差的范围内
调整不影响项目的总工
期
? 总时差最小的活动是关
键活动
? 关键活动组成的路径是
关键路径
? 关键路径是工期最长
（等于总工期）的路径
? 自由时差：活动不改
变紧前紧后活动的计
划安排的机动时间
? 活动在自由时差的范
围内调整对项目计划
没有影响
网络计划时间参数计算 (复习 )
? 最早开始时间 ES＝ MAX{紧前工作的 EF
? 最早结束时间 EF＝ ES＋工作延续时间 t
? 最迟结束时间 LF＝ MIN{紧后工作的 LS}
? 最迟开始时间 LS＝ LF— 工作延续时间 t
? 总时差 TF＝ LF— EF＝ LS— ES
? 自由时差 FF
＝ min{ES(紧后工作 )}-max{LF(紧前工作 )}-工作时间
＝ min{ES(紧后工作 )}-ES-工作时间
= min{ES(紧后工作 )}-EF
总机动时间计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
时间计算 (练习 )
A 3
E 8
C 7 F 6
D 4
B 2
G 5
代号 时间 示例,
0 3
3 5
3 10
3 7
10 16
10 18
18 23
18 23 12 18
10 18 8 10
3 10
8 12
0 3
0
5
0
5
0
2 0
0
3
0
0
0
5
2
横道图示意
网络图示意
112/10
121/20
142/10 141/20
134/20 133/15 132/25 131/15
143/20
122/20 123/10
144/15
151/10 152/10 SS10 FS5
111/10 112/10
121/20
142/10 141/20
134/20 133/15 132/25 131/15
143/20
122/20 123/10
144/15
151/10 152/10 SS10 FS5
0 10 10 20 20 35 30 55 55 70 70 90 95 105
20 40 40 60 60 70
20 40 40 50 50 70 70 85
105 115
105 115 95 105
85 95 65 85 45 65
20 35 10 20 0 10 30 55 55 70 70 90
30 50 50 60 60 80 80 95
25
25 0
10
25 25
0
10 10 10 10
0 0 0
最早开始时间 总时差 最早结束时间
工作代码 工作名称 工期
最迟开始时间 自由时差 最迟结束时间
工作时间的压缩
? 工作时间的压缩是数学分析方法为了缩短项目
工期的一种特殊情况, 通常是由于遇到一些特
别的限制或者是其他进度目标的要求 。 延续时
间压缩的技术主要包括,
? 费用交换,在进度和费用之间往往存在一定的转换
关系, 这里的目的是寻求压缩进度所需追加的最小
费用, 或者在最佳费用限额确定下如何保证压缩的
工期最大, 寻求工期和费用的最佳结合点 。
? 并行处理,对于一个正常进行的工作可考虑按照并
行方式进行, 当然这种转换容易带来一定的风险 。
费用计划和资源计划
? 根据 WBS和进度安排制定费用计划
? 计划在项目过程中所需的资源
? 费用、资源、工期、进度间具有相关性
? 确定在不同阶段所需的人员资质、数量、
工作周期
? 确定需要的制约项目进展的关键资源计
划表
关键资源计划表示例
序号 名称 版本 /型号 数量 技术指标 使用起始时间 使用持续时间 备注
关于配置管理计划
? 配置管理是指：标识和确定系统中配置项的过
程, 在系统整个生存周期内控制这些项的投放
和更动, 记录并报告配置的状态和更动要求,
验证配置项的完整性和正确性
? 配置管理计划包括：人员组织结构与职责, 基
线与配置项, 配置项标识, 配置控制过程与权
限, 配置状态记录和统计报告, 配置审计等
? 有关配置管理以及配置管理计划的详细内容在
以后描述
关于质量
? 确定质量目标
? 确定过程和产品规程和标准
? 确定对各项工作的质量要求
? 计划和安排质量活动
? 评审、测试、配置管理
? 计划质量保证工作
? 项目组的质量工作与其它开发活动一起计划
? 有关项目组质量保证工作在项目计划中专门进
行，详细内容在以后描述
编制软件项目计划文档
? 按照规定的格式编制软件项目计划文档，记录
项目策划的结果
? 所有在项目策划过程中的假设条件、估计原始
数据应当在软件项目计划文档中记录
? 可以用电子文件作为软件项目计划的文档，或
将电子文件作为文档的附录
? 项目的配置管理计划和质量保证计划可以纳入
软件项目计划中，也可以单独形成文档
软件项目计划文档条目
1 范围
2 引用文档
3 软件开发管理
3.1 项目组织与资源
3.2 进度与里程碑
3.3 风险管理
3.4 安全保密
3.5 与其他承制方的接
口
3.6 与其它软件独立验
证与确认机构的接
口
3.7 转承制方的管理
3.8 正式审查
3.9 软件开发库
3.10 纠正过程
3.11 问题 /更改报告
4 软件工程
4.1 组织和资源
4.2 软件标准和研制程
序
4.3 非开发软件
5 正式合格性测试
5.1 组织机构和资源
5.2 测试方法 /基本原理
5.3 测试计划的假设条
件和约束
6 软件产品评价
6.1 组织机构和资源
6.2 软件产品评价规程
和工具
6.3 转承制方的产品
6.4 软件产品评价记录
6.5 依赖活动的产品评
价
7 软件配置管理
7.1 组织机构和资源
7.2 配置标识
7.3 配置控制
7.4 配置状态报表
7.5 配置审核
7.6 认可规格说明的准
备
7.7 配置管理主要里程
碑
8 其它软件开发功能
评审
? 软件项目计划必须进行评审
? 项目组成员、甲方代表、相关小组代表、质量
保证人员应当参加评审
? 高层管理人员对评审通过的软件项目计划进行
审查批准
? 批准生效的软件项目计划成为项目的基准计划
? 对软件项目计划实施管理和控制（配置管理）
练习题
? 对以下软件项目建立软件项目计划文档,
? 辅助银行处理定期储蓄取款业务的软件系统
? 与需求分析和设计的练习题相一致
? 缺少条件可自行假设
? 有关配置管理、风险等内容等后面的课
程结束后陆续添加
? 在复习前和其它练习题结果一起提交
软件项目的失败
? 如果定义阶段确定的需求不能被满足，如果大大超过了成本和进
度，如果需方不满意这个系统，那么这个项目就是失败了。
? 早在失败发生之前，有一系列的信号可以警告管理员有潜在的问
题,
1）开发方和需方之间没作什么交流讨论，提出项目计划和软件需求规
格说明时没有人提出建议或表示赞成，也没有经过严格的评审；
2）软件工程阶段性评审落在原进度之后，没有进行所需的修改就算完
成了，或者是在某一步无休止地反复；
3）在软件需求分析和概要设计之后，没有对进度和预算作变动；
4）在整个进度只进行了 20%时，程序就已编写出来了；
5）重新委派了开发人员。
? 上述危险信号是按其重要性依次列出的，管理员应及时地在项目
的早期就发现这些信号。
失败的托辞（ 1/8）
? 需求规格说明变动了
? 不管项目的复杂性如何，所有项目的需求规
格说明总会有不同程度的变动，管理员真正
应说的是,
1）早期分析做得不完全或很差；
2）项目估算得不正确；
3）计划得不完全或没有作计划；
4）用户从未审查过软件需求规格说明；
5）没有预料到预算或进度的变动带来的实际影响。
失败的托辞（ 2/8）
? 用户不知道他究竟需要什么
? 这是一种很典型的托辞，企图为拙劣的项目
辩解。管理员真正应说的是,
1）开发人员从未问过用户需要什么；
2）开发人员感到这个项目很有趣，所以决定照自
己的想法就这么去做它；
3）不称职的分析员和不称职的用户一起工作；
4）开发人员和用户之间没有进行交流讨论。
失败的托辞（ 3/8）
? 缺乏机时所以影响了开发
? 这一托辞将随着计算机资源的不断出现（如
终端和微型机都很容易获得）而越来越不成
,理由, 了。项目管理员应该说的是,
1）我没有计划好测试时间，直到年底才发觉机时
不够；
2）在讨论这个问题时，我缺乏想像力，没有想到
加夜班、周未加班或使用服务部门等方案。
失败的托辞（ 4/8）
? 供应商没有及时提供设备和软件
? 在 1965年那时 CPU和操作系统还在婴儿时期，
这曾经是个绝妙的托辞。但今天，管理员应
说的可能是,
1）据供应商说第一批货将在第三季度发出，我就不加思索
地认为第一台机器将交付给我；
2）由于我对使用新机器过于兴奋，以致忘了必须先使系统
正常工作起来；
3）除了管理不善之外，对项目落后于原定的进度我确实没
有什么合适的理由，所以我只好怪供应商。
失败的托辞（ 5/8）
? 我们造了一辆, 卡迪拉克, 而他们要的
是, 大众,
? 这种共同的托辞常见于首次使用计算机的情
形，或由不很精通的人操作该系统（例如翻
砂厂使用一个复杂的生产控制系统）的情形。
管理员真正应说的是,
1）我们从未问过用户需要什么；
2）我只是对自己学过的或实现过的东西更感兴趣，
而不是对用户如何使用该系统感兴趣。
失败的托辞（ 6/8）
? 估算差得太远了
? 当其它托辞都无济于事的情况下，这将是一
个很好的托辞，然而也只能用一次。因为这
样辩解，可能会引起反问：, 好，那么你的
估算是什么呢？,,因此这个托辞以后就不
能再用了。实际上这个托辞意味着,
1）我没有估算或计划这个项目；
2）我没有监督和管理这个项目，如果我管了的话，
可能在几个月之前就会告诉你估算是不精确的了。
失败的托辞（ 7/8）
? 人员流动过多，造成项目延期
? 很明显，人员的流动会影响项目的进展。然
而项目管理员应该承认他未搞清以下两点原
因,
1）是由于人员流动，才导致拙劣的项目；
2）还是由于这个项目本身是拙劣的，所以造成人
员流动。
失败的托辞（ 8/8）
? 最高层的管理人员没有支持
? 没有他们的支持确实会引起项目各方面的问
题。然而，项目管理员应说的可能是,
1）由于过去的表现，最高层管理人员对职员的能
力没有信心；
2）没有向最高层管理人员说明这个项目将带来的
影响。
失败的理由
? 软件项目失败有三类问题存在,
1）不适当的计划：拙劣地决定开发组织，模糊地定
义项目范围，不适当的资源，对需求的含糊说明，
缺乏预见性。
2）草率地评审或根本不评审：没有及时的、可评审
的里程碑，拙劣的文档，没有能主持评审的人员，
没有可依据的评审指导原则，用户／需方没参加评
审。
3）缺乏组织得很好的方法：没有明确的，或根本没
有设计方法，无组织地设计和编码，没有正规的测
试，缺乏标准，（没有很好地借鉴、继承和重用，
从而使得每个项目都要“重新发明车轮”。
明智地实现软件工程方法将为
防止软件项目的失败提供主
要的安全措施
谢谢！
汤铭端
68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
bicast@public3.bta.net.cn
