软件工程项目管理精品PPT课件
合集下载
软件项目管理教材PPT89页
核心三计划
范围计划 进度计划 成本计划
－－成本基准，进度基准
0
软件项目管理
第三讲 软件项目范围计划
1
本章要点
一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、案例分析
2
1 软件项目需求管理
影响软件项目成败的因素
其它
过少的用户输入
13%
12% 50%
场景串联提供了用户界面以说明系统操作流程，它容易创 建和修改，能让用户知道系统的操作方式和流程。
根据与用户交互的方式，场景串联被分成三种模式：静态 的场景串联、动态的场景串联以及交互的场景串联。
选择提供哪种场景串联是根据系统的复杂性和需求缺陷的 风险来确定的。
23
如何记录需求------需求跟踪矩阵
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
缺乏应用领域专家
4
1 软件项目需求管理
软件开发的目标——按时按预算开发出满足用户真实需要的软件。 需求—— 一个软件项目的开始阶段。在软件工程中，需求分析阶 段是 包括客户、用户、业务或需求分析员、开发人员、测试人员、用 户文档编写者、项目管理者和客户管理者在内的所有的风险承担者都 需要参与的阶段。
5
1 软件项目需求管理
结构化分析方法的优点与局限性。
28
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
范围计划 进度计划 成本计划
－－成本基准，进度基准
0
软件项目管理
第三讲 软件项目范围计划
1
本章要点
一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、案例分析
2
1 软件项目需求管理
影响软件项目成败的因素
其它
过少的用户输入
13%
12% 50%
场景串联提供了用户界面以说明系统操作流程，它容易创 建和修改，能让用户知道系统的操作方式和流程。
根据与用户交互的方式，场景串联被分成三种模式：静态 的场景串联、动态的场景串联以及交互的场景串联。
选择提供哪种场景串联是根据系统的复杂性和需求缺陷的 风险来确定的。
23
如何记录需求------需求跟踪矩阵
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
缺乏应用领域专家
4
1 软件项目需求管理
软件开发的目标——按时按预算开发出满足用户真实需要的软件。 需求—— 一个软件项目的开始阶段。在软件工程中，需求分析阶 段是 包括客户、用户、业务或需求分析员、开发人员、测试人员、用 户文档编写者、项目管理者和客户管理者在内的所有的风险承担者都 需要参与的阶段。
5
1 软件项目需求管理
结构化分析方法的优点与局限性。
28
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
软件项目管理课程(PPT 80张)
六盘水师范学院 孙新杰
3
◆ 人员： 人员是一个成功软件项目中最重要的因素。 可分为5类： ⑴高级管理者：负责定义业务问题，影响着项目。 ⑵技术管理者：组织、激励和控制开发人员。 ⑶开发人员：负责开发一个产品或应用所需的技术。 ⑷客户（customer)：负责说明待开发的软件需求。 ⑸最终用户（user)：直接使用发布的软件。
六盘水师范学院 孙新杰
25
2. 软件度量的方法
（1）面向规模的度量 是对软件和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某 些信息。该表格列出了在过去几年完成的每一个软件开 发项目和关于这些项目的相应面向规模的数据。
六盘水师范学院 孙新杰
26
基于所生产软件的“规模”，使用代码行作为其他 计算的规范化因子。计算： •每千行代码（KLOC) 的错误数。 •每KLOC 的缺陷数。 •每个LOC的花费成本。 •每KLOC 的文档页数 •每人月的错误数。 •每人月的代码行。 •每页文档的成本。
六盘水师范学院 孙新杰
23
◆项目度量： 是战术的，使项目管理者能够以实时的方式改进项 目的工作流程及技术方法，如软件项目的工作量及时间 的估算。 项目度量的基础是历史项目中收集的数据。随着项 目的进展，所花费的工作量及时间和预算的值进行比较， 从而控制项目的进展。 另外，可根据文档的页数、评审的时间、功能点及 源代码行数来度量软件的生产率。
六盘水师范学院 孙新杰
21
1. 过程和项目的度量
◆过程度量： 使一个组织从战略上考察已有过程的功效，如开发 范型、工程任务的划分、工作产品、里程碑等，使管理者 评估那些部分起了作用。度量数据的收集跨越所有的项目， 经历较长的时间，目的是改善软件过程。 间接的度量一个软件过程的功效： • 软件发布之前发现的错误数 • 交付给用户后报告的缺陷数 • 花费的工作量、时间、成本 • 与进度计划是否一致
软件项目管理课程PPT88页
一周的工作量（40小时）。
8 .2 软件项目任务分解
5．责任分配及成本分解
WBHS编o号t Ti预p算
责任者
1
0.1
张明
2
0.46
李立
3
0. 46
张明、李立
3.1
0.04
张明
3.2
0.15
李立
WBS编号 预算
3.3
0.15
3.4
0.1
3.5
0.02
4
0.08
5
0.1
责任者 李立 李立 张明 万风 张明
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴？
❖5W + 1H + 8C ❖5W就是 Who、When、Where、What、Why ❖ Why是关键 ❖1H就是 How – 需求本身的流程 ❖ 8C指的是8个约束和限制，即8个Constraints： ❖ 包括性能Performance、成本Cost、时间Time、
• •
H需流o求程t 分 优T析 化ip计划
• 编写需求说明书
• 编写需求规格词汇表
• 绘制业务流程
• 抽象业务类
• 建立数据模型
• 将需求分析图示加入规格文档
• 需求规格测试
① 需求规格确认
8 .2 软件项目任务分解
• 任务分解过程 1．H分ot解T步i骤p
（1）确认并分解项目的主要组成要素。 （2）确定分解标准 （3）确认分解是否详细，分解结果是否可以作为
东西时就会知道—感觉会随环境变化）
❖过早作出结论（截断需要表达过程——需求分析 需要耐心和自我控制）
8 .2 软件项目任务分解
5．责任分配及成本分解
WBHS编o号t Ti预p算
责任者
1
0.1
张明
2
0.46
李立
3
0. 46
张明、李立
3.1
0.04
张明
3.2
0.15
李立
WBS编号 预算
3.3
0.15
3.4
0.1
3.5
0.02
4
0.08
5
0.1
责任者 李立 李立 张明 万风 张明
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴？
❖5W + 1H + 8C ❖5W就是 Who、When、Where、What、Why ❖ Why是关键 ❖1H就是 How – 需求本身的流程 ❖ 8C指的是8个约束和限制，即8个Constraints： ❖ 包括性能Performance、成本Cost、时间Time、
• •
H需流o求程t 分 优T析 化ip计划
• 编写需求说明书
• 编写需求规格词汇表
• 绘制业务流程
• 抽象业务类
• 建立数据模型
• 将需求分析图示加入规格文档
• 需求规格测试
① 需求规格确认
8 .2 软件项目任务分解
• 任务分解过程 1．H分ot解T步i骤p
（1）确认并分解项目的主要组成要素。 （2）确定分解标准 （3）确认分解是否详细，分解结果是否可以作为
东西时就会知道—感觉会随环境变化）
❖过早作出结论（截断需要表达过程——需求分析 需要耐心和自我控制）
软件工程与项目管理课程(PPT 78页)
性努力
课程综述
本课程是计算机专业的专业课之一， 通过本课程的学习， 要求学生理解在软件开发过程中应用软件工程方法的必要 性和迫切性，要求学生掌握软件工程的基本原理、概念与 技术方法
本门课程最主要的作用就是帮助学生建立系统、完整的专 业基础理论体系，不仅培养学生分析问题、解决问题的能 力，而且全面锻炼学生将来成为现代软件工程师需要的团 队协作、谈判沟通、适应发展等等能力，为在今后工作中 从事计算机大规模软件开发与维护打下扎实的基础
系统分析能力、需求分析能力、设计能力
要求高、一般要求 有较长时间的开 发经验
熟练掌握某种语言、能看动相关设计文档，MIS 一般 系统编码一般要求掌握一种数据库系统
熟练了解某种特定的软件、能解决客户提出的各 一般 种技术问题、对软件硬件都应当有所了解
熟练了解某种特定软件、能接收并解决客户提出 一般 的问题、能进行软件的二次开发、熟悉某种 开发语言、掌握一种数据库系统
造房的方法论-总结
小型工程可边做边设计 施工过程中修改方案不会带来致命影响 以经验为主 造房和施工方不一定需要通过图纸来沟通，不需要太多的
工程知识，双方边商量边施工
造房的方法论-金贸大厦
谈可行性
设计原形并讨论
造房的方法论-金贸大厦
严格按照图纸施工
可耸立百年的大楼是精确设计的产物
软件过程模型
计划阶段 开发阶段 维护阶段
制定计划 需求分析 软件设计 程序编写 软件测试
运行维护
软件过程模型
软件计划
问题定义
“要解决的问题是什么？”
可行性研究
经济 技术 管理 社会环境
40
软件过程模型
需求分析
确定系统逻辑模型 确定目标系统必须具备的如下内容
课程综述
本课程是计算机专业的专业课之一， 通过本课程的学习， 要求学生理解在软件开发过程中应用软件工程方法的必要 性和迫切性，要求学生掌握软件工程的基本原理、概念与 技术方法
本门课程最主要的作用就是帮助学生建立系统、完整的专 业基础理论体系，不仅培养学生分析问题、解决问题的能 力，而且全面锻炼学生将来成为现代软件工程师需要的团 队协作、谈判沟通、适应发展等等能力，为在今后工作中 从事计算机大规模软件开发与维护打下扎实的基础
系统分析能力、需求分析能力、设计能力
要求高、一般要求 有较长时间的开 发经验
熟练掌握某种语言、能看动相关设计文档，MIS 一般 系统编码一般要求掌握一种数据库系统
熟练了解某种特定的软件、能解决客户提出的各 一般 种技术问题、对软件硬件都应当有所了解
熟练了解某种特定软件、能接收并解决客户提出 一般 的问题、能进行软件的二次开发、熟悉某种 开发语言、掌握一种数据库系统
造房的方法论-总结
小型工程可边做边设计 施工过程中修改方案不会带来致命影响 以经验为主 造房和施工方不一定需要通过图纸来沟通，不需要太多的
工程知识，双方边商量边施工
造房的方法论-金贸大厦
谈可行性
设计原形并讨论
造房的方法论-金贸大厦
严格按照图纸施工
可耸立百年的大楼是精确设计的产物
软件过程模型
计划阶段 开发阶段 维护阶段
制定计划 需求分析 软件设计 程序编写 软件测试
运行维护
软件过程模型
软件计划
问题定义
“要解决的问题是什么？”
可行性研究
经济 技术 管理 社会环境
40
软件过程模型
需求分析
确定系统逻辑模型 确定目标系统必须具备的如下内容
《软件工程与项目管理》课件_第5章
图5.6 信息内聚模块
(7) 功能内聚。若一个模块中各个部分都是为完成一项 具体功能而协同工作、紧密联系、不可分割的，则称该模块 为功能内聚模块。功能内聚模块是内聚性最强的模块。
2．耦合性 耦合性是对模块之间的相对独立性(互相连接的紧密程 度)的度量。它取决于各个模块之间接口的复杂程度、调用 模块的方式以及哪些信息通过接口。 一般模块之间可能的连接方式有七种，构成耦合性的七 种类型。不同类型耦合的强弱关系如图5.7所示。
析，确定系统具体的实施方案，然后进行结构设计，确定软件结构。 总体设计的一般步骤如下：
(1) 设计系统方案。 (2) 选取一组合理的方案。 (3) 推荐最佳实施方案。 (4) 功能分解。 (5) 设计软件结构。 (6) 设计数据库和文件结构。 (7) 制定测试计划。 (8) 编写概要设计文档。 (9) 审查与复审概要设计文档。
(5) 标记耦合。如果一组模块通过参数表传递记录信息， 则它们之间的耦合称为标记耦合。事实上，这组模块共享了 某一数据结构的子结构，而不是简单变量。这就要求这些模 块都必须清楚该记录的结构，并按结构要求对记录进行操作。
图5.9 控制耦合
(6) 数据耦合。如果一个模块访问另一个模块时，彼此 之间通过数据参数(不是控制参数、公共数据结构或外部变 量)来交换输入、输出信息，而且交换的信息仅限于数据， 则称这种耦合为数据耦合。数据耦合是松散的耦合，模块之 间的独立性比较强。
(2) 逻辑内聚。这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块的控制型参数来确定该模块应 执行哪一种功能。逻辑内聚模块比巧合内聚模块的内聚程度 要高，因为它表明了各部分之间在功能上的相关关系。
(3) 时间内聚(经典内聚)。这种模块大多为多功能模块， 但要求模块的各个功能必须在同一时间段内执行，例如初始 化模块和终止模块。时间内聚模块比逻辑内聚模块的内聚程 度又稍高一些。在一般情况下，时间内聚模块各部分可以以 任意的顺序执行，所以它的内部逻辑更简单。
软件工程项目管理ppt课件
最新版整理ppt
10
甘特图
甘特图是一种条形图，表示了项目的日程 安排和各项活动的开始和完成时间。从右 往左读，条形图清晰地给出了活动的开始 和结束。
最新版整理ppt
11
MS Project--甘特图
最新版整理ppt
12
资源分配问题
除了考虑进度安排外，项目管理者还要考 虑参加项目活动人员 的分配。可以生成条 形图。
人员
源于开发团队成员的风险 如招聘不到符合要求的职员 在项目关键时期，关键人员出现意外事情 职员培训跟不上
机构
源于开发的机构环境的风险 重新的机构调整，管理层的变更 开发过程中财务出现问题
工具
源于CASE工具和其他支持软件的风险 如CASE效率低 CASE工具不能集成
需求
源于客户对需求变更的风险 如需求发生变更，主题设计要返工，客户的不了解。
T7
20
T1(M1)
T8
25
T4(M5)
T9
15
T3，T6(M4)
T10
15
ห้องสมุดไป่ตู้T5，T7(M7)
T11
7
T9(M6)
T12
10
T11(M8)
最新版整理ppt
7
MS Project—活动网络图
最新版整理ppt
8
关键路径解释
关键路径（CPM，Critical Path Method） 从起点到终点，可以有许多条路径，我们
风险识别
风险分析
风险规划
风险监控
潜在的风险 列表
优先级高的 风险列表
风险规避和 应急计划
风险评估
图：风险管理过程
最新版整理ppt
软件项目管理教材PPT41页
3.2 项目经理的责任和权力
二.项目经理的权力 1．生产指挥权 2．项目团队的组建权 3．财权 4．技术决策权
责任大于权力!!!
3.2 项目经理的责任和权力
• 项目经理的能力
12． ．获消H得除ot项障T目 碍ip资 和源 解的 决能问力题的能力
3．领导能力和权衡能力 4．沟通能力 5．管理时间的能力 6．灵敏性
这既是矩阵型组织的优点也是它的缺点。资源在 项目经理之间流动容易引起项目经理之间的争斗， 每个项目经理都更关心自己项目的成功，而不是 整个公司的目标。 ➢ 许多因素使矩阵项目团队非常难以管理。团队成 员觉得这样的团队是临时的，所以对团队的忠诚 是有限的。
3.3 项目组织类型
四. 项目组织的设计
1H．o目t标T一ip致性原则
3 .1 项目相关利益主体
• 项目相关利益主体之间的关系
1．业H主ot与T项ip目实施组织之间的利益关系
二者的利益关系中相互一致的一面使项目业主与项目的
实施组织最终形成一种委托和受托，或者委托与代理的关 系。但是双方的利益有一定的对立性和冲突，如果处理不
好会给项目的成功带来许多不利的影响。这种利益冲突一 般需要按照互利的原则，通过友好协商，最终达成项目合 同的方法解决。因此在项目管理中，项目业主与项目实施
矩阵项目组织类型-弱矩阵 弱矩阵型组织管理形式
矩阵项目组织类型-平衡矩阵 平衡矩阵型组织管理形式
矩阵项目组织类型-强矩阵 强矩阵型组织管理形式
3.3 项目组织类型
矩阵型组织结构具有以下优点：
➢H项矩ot目阵T是型ip工组作织的具重有点项，目项型目组经织理的负长责处管。理整个项目，
➢ 可以有效地利用资源，项目可以分享各个部门的 技术、人才和设备。当多个项目同时进行时，公 司可以平衡资源以保证各个项目都能完成各自的 进度、费用和质量要求。
软件工程导论软件项目管理PPT资料优秀版
险等。 项目管理贯穿软件生命周期全过程。 度量的重要性：没有数字就没有管理！ 软件项目管理的主要任务：
➢ 成本管理的任务 ➢ 质量管理的任务 ➢ 配置管理的任务 ➢ ……
2.1 软件度量——基本概念
度量：是软件产品、软件开发过程或资源简单属 性的定量描述。度量具有数字特征。
测量：涉及测量的方法、过程、工具和数值结果。 用于事后或实时状态。
2.5 软件可靠性度量——可靠性概念
软件可靠性：在某个给定时间间隔内，程序按照规 格说明成功运行的概率。
R(t) = 1 - ∫0t f(t)dt
（t表示程序发生故障的时刻， f(t)表示t的概率密度函数）
运行时间越长、故障次数越多、可靠性越小。
R(t) = exp [ -∫0t Z(x)dx]
小组人数2~5 主程序员小组、民主制小组 各阶段需要的技术人员类型、层次和数量不同。
2.6 软件开发过程的管理——过程管理
常用的跟踪方式 P68-69
2.7 软件过程及软件成熟度模型CMM
背景 开发组织：通过CMM度量找到自己的优势和差
距 客户：寻求适宜的开发商 发展 1986年11月， 卡内基.梅隆大学，启动 1991年8月，公开发布 1993年2月， 近几年来，CMM又推出了2.0 版本，同时进入
2.4 软件复杂性度量——文本复杂性
5 软件可靠性度量—H—可a靠ls性估te算ad，70年代，从统计学和心理学角度研 究，程序是由操作符和操作数组成的符号序列。 1 软件度量——两种度量比较
软件测量:直接(简单属性)、间接(涉及多个属性) 7 软件过程及软件成熟度模型CMM
程序语言符号长度N 按11，指正定相方关法、修负改相程关序，的➢根难据度具；体情况折衷平衡，达到用户和开发人员满意的目标。 程序量V 按指定方法修改程序的难度；
➢ 成本管理的任务 ➢ 质量管理的任务 ➢ 配置管理的任务 ➢ ……
2.1 软件度量——基本概念
度量：是软件产品、软件开发过程或资源简单属 性的定量描述。度量具有数字特征。
测量：涉及测量的方法、过程、工具和数值结果。 用于事后或实时状态。
2.5 软件可靠性度量——可靠性概念
软件可靠性：在某个给定时间间隔内，程序按照规 格说明成功运行的概率。
R(t) = 1 - ∫0t f(t)dt
（t表示程序发生故障的时刻， f(t)表示t的概率密度函数）
运行时间越长、故障次数越多、可靠性越小。
R(t) = exp [ -∫0t Z(x)dx]
小组人数2~5 主程序员小组、民主制小组 各阶段需要的技术人员类型、层次和数量不同。
2.6 软件开发过程的管理——过程管理
常用的跟踪方式 P68-69
2.7 软件过程及软件成熟度模型CMM
背景 开发组织：通过CMM度量找到自己的优势和差
距 客户：寻求适宜的开发商 发展 1986年11月， 卡内基.梅隆大学，启动 1991年8月，公开发布 1993年2月， 近几年来，CMM又推出了2.0 版本，同时进入
2.4 软件复杂性度量——文本复杂性
5 软件可靠性度量—H—可a靠ls性估te算ad，70年代，从统计学和心理学角度研 究，程序是由操作符和操作数组成的符号序列。 1 软件度量——两种度量比较
软件测量:直接(简单属性)、间接(涉及多个属性) 7 软件过程及软件成熟度模型CMM
程序语言符号长度N 按11，指正定相方关法、修负改相程关序，的➢根难据度具；体情况折衷平衡，达到用户和开发人员满意的目标。 程序量V 按指定方法修改程序的难度；
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
开始进行技术评审和可能的修正 end if end loop
(开发过程)项目计划
▪ 有些机构的项目计划包含：开发计划、质量计划、 有效性验证计划、配置管理计划、维护计划和人 员开发计划。有些机构只涉及开发过程。
▪ 项目计划书的具体内容随着项目和开发机构类型 不同而改变。不过多数计划书应该包括以下几个 部分：
项目进度过程
识别活动
识别活动 依赖关系
估算活动 的资源
为活动 分配人员
创建 项目图表
软件需求
活动图表 及条形图
有些活动是并行进行的，调度人员必须协调这些并行活动， 并把整个工作组织起来，使人力资源得到充分利用。
一定要避免出现因一项关键任务没有完成而使整个项目延 期交付的情形。
活动分解及进度管理
▪ 项目规划在项目之初拟定，它是整个项
目的驱动器。
▪ 项目规划是一个反复的过程，只有当项
目完成时规划才告一段落。
项目规划过程
确定项目的约束条件 初步评估各项项目参数 定义项目里程碑和可交付的文档 while 项目未完成或被取消 loop
拟定项目进度表 根据项目进度表启动各项活动 等待（一定的时间） 评审项目进展状况 修正对项目参数的初步估算 更新项目进度表 重新协商项目约束条件和可交付的文档 if (出现问题) then
软件工程
--软件项目管理
内容提要
▪软件项目管理活动 ▪项目规划 ▪项目进度 ▪质量管理 ▪软件成本估算 ▪人员管理
软件项目管理概述
随着信息技术的飞速发展，软件产品的规模也越来越 庞大，个人单打独斗的作坊式开发方式已经越来越不 适应发展的需要。各软件企业都在积极将软件项目管 理引入开发活动中，对开发实行有效的管理。
▪ 写建议书没有固定的格式供参考，它是
一种经验性的技巧。
项目监督
▪ 项目监督是一种连续性的活动。管理人
员必须密切关注项目进展情况，将实际 进展和成本与原计划的进度和成本作比 较。
▪ 项目监督可以划分为：
✓正式监督 ✓非正式监督
项目规划
▪ 对软件项目的有效管理取决于对该项目
进展状况的全面规划。项目管理者必须 能预见可能出现的问题，并且准备好相 应的解决方案予以应对。
软件项目管理就是通过合理地组织和利用一切可 以利用的资源，按照计划的成本和计划的进度， 完成一个计划的目标，它包含团队管理、风险管 理、采购管理、流程管理、时间管理、成本管理 和质量管理等。 是否需要管理是专业软件开发
和业余编程程管理者与其他工程管理者的性质是相同的， 但软件工程管理很多方面有显著的区别，这导致了 软件工程管理的难度相当大。许多大型软件项目的 失败也告诉我们：软件管理困难重重。
▪ 软件产品是无形的； ▪ 没有标准的软件过程； ▪ 大型软件项目经常是“一次性的”。
软件项目管理的特点
▪ 项目管理是一项复杂的工作。 ▪ 项目管理具有创造性。 ▪ 项目管理需要集权领导和建立专门的
项目组织。
▪ 项目负责人在项目管理中起着非常重
要的作用。
具有创新性的工程项目经常会存在进度问题。
软件项目管理活动
▪ 以需求工程为例(以建立原型来帮助验证需求)：
活动
可行性研究
需求分析
原型开发
设计研究
需求描述
可行性研究 报告
用户需求
估算报告
里程碑
体系结构设 计
系统需求
项目进度
▪ 项目进度对软件管理者的要求是十分苛刻 的。管理人员必须估算完成各项活动所需 要的时间和资源，并按照一定的顺序把他 们紧密组织起来。
▪ 项目进度包括把一个项目所有工作分解为 若干独立活动，以及完成这些活动所需的 时间。
木板房的第 2、4两面墙 的长度是第 1、3两面墙 的一倍。
甘特图
各道工序估计需要时间（小时）
墙壁 工序 刮旧漆 刷新漆
1或3
2
3
2或4
4
6
清理 1 2
一种做法是，先刮掉4面墙的旧漆，然后给每面墙刷 新漆，最后清除每个窗户上的油漆，共需时间36小时。 显然，这是效率最低的做法，任何时候都有10名工人 闲着没事干。
▪ 提出项目建议书 ▪ 项目规划与进度 ▪ 项目成本管理 ▪ 项目监督和评审 ▪ 人员管理 ▪ 拟定工作报告
项目建议书
▪ 项目建议书要写清楚：项目的目标和实
现该目标的方法；还要估算项目的成本 和进度；有时还要说明与某一特定机构 或团队签约的理由。
▪ 许多软件机构之所以存在是因为其手头
有大量的建议书和合同。
可交付的文档
▪ 可交付的文档是交付给客户的项目成果， 通常是在项目的描述、设计等主要项目 阶段结束时交付。
✓ 可交付的文档也是里程碑，但里程碑不一定要 交付。里程碑是项目内部的阶段性成果，供项 目管理者来检查项目进展情况。
软件过程中的里程碑
▪ 要建立里程碑，软件过程就一定要分解成一系 列相关的基本活动，而每一个这样的基本活动 都要建立相应的输出结果。
✓引言 ✓项目组织 ✓风险分析 ✓软硬件资源需求
✓工作分解 ✓项目进度 ✓监控和报告机制
项目里程碑
▪ 一个项目里程碑就是一个软件过程活动的 终结。在每个里程碑都应该有一个正式的 可以提交给管理层的输出结果。
▪ 里程碑应代表该项目的一个特定的逻辑意 义上的阶段的终结。
▪ 里程碑的两个必要特征：
与软件开发进展相关联； 在完成时必须非常明显。
进度管理工具
项目进度通常用一系列的图表表示，通过 这些图表可以了解任务分解、活动依赖关 系和人员分配情况。
常用的项目进度表示法有：
✓甘特图（Gantt） ✓活动网络图（PERT）
常用软件管理工具是：MS-Project
甘特图
▪ 是历史悠久、应用广泛的制定进度计划的 工具。
例： 假设有一座陈旧的矩形木板房需要重新油漆。这项工作必 须分3步：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗 户上的油漆。 一共分配了15名工人去完成这项工作，而工具只有：5把 刮旧漆的刮板，5把刷漆用的刷子，5把清除溅在窗户上油 漆的小刮刀。 如何安排工作，最有效？
正常情况，各活动应至少持续1周； 对所有活动安排一个最高的时间限制（8～10周
左右），如一项活动持续时间超过限制，就应该 再次细分； 估算进度时，管理者不能想当然认为项目的每个 阶段都不会出问题； 初时间外，还必须估算完成每项任务所需的资源： 人力资源和其他可能的资源。
经验法则：估算时先假定什么问题也没有，然后再把预计出 现的问题加到估计中去（＋30％）。还要考虑因偶然因素带 来的意想不到的问题（＋20％）。
(开发过程)项目计划
▪ 有些机构的项目计划包含：开发计划、质量计划、 有效性验证计划、配置管理计划、维护计划和人 员开发计划。有些机构只涉及开发过程。
▪ 项目计划书的具体内容随着项目和开发机构类型 不同而改变。不过多数计划书应该包括以下几个 部分：
项目进度过程
识别活动
识别活动 依赖关系
估算活动 的资源
为活动 分配人员
创建 项目图表
软件需求
活动图表 及条形图
有些活动是并行进行的，调度人员必须协调这些并行活动， 并把整个工作组织起来，使人力资源得到充分利用。
一定要避免出现因一项关键任务没有完成而使整个项目延 期交付的情形。
活动分解及进度管理
▪ 项目规划在项目之初拟定，它是整个项
目的驱动器。
▪ 项目规划是一个反复的过程，只有当项
目完成时规划才告一段落。
项目规划过程
确定项目的约束条件 初步评估各项项目参数 定义项目里程碑和可交付的文档 while 项目未完成或被取消 loop
拟定项目进度表 根据项目进度表启动各项活动 等待（一定的时间） 评审项目进展状况 修正对项目参数的初步估算 更新项目进度表 重新协商项目约束条件和可交付的文档 if (出现问题) then
软件工程
--软件项目管理
内容提要
▪软件项目管理活动 ▪项目规划 ▪项目进度 ▪质量管理 ▪软件成本估算 ▪人员管理
软件项目管理概述
随着信息技术的飞速发展，软件产品的规模也越来越 庞大，个人单打独斗的作坊式开发方式已经越来越不 适应发展的需要。各软件企业都在积极将软件项目管 理引入开发活动中，对开发实行有效的管理。
▪ 写建议书没有固定的格式供参考，它是
一种经验性的技巧。
项目监督
▪ 项目监督是一种连续性的活动。管理人
员必须密切关注项目进展情况，将实际 进展和成本与原计划的进度和成本作比 较。
▪ 项目监督可以划分为：
✓正式监督 ✓非正式监督
项目规划
▪ 对软件项目的有效管理取决于对该项目
进展状况的全面规划。项目管理者必须 能预见可能出现的问题，并且准备好相 应的解决方案予以应对。
软件项目管理就是通过合理地组织和利用一切可 以利用的资源，按照计划的成本和计划的进度， 完成一个计划的目标，它包含团队管理、风险管 理、采购管理、流程管理、时间管理、成本管理 和质量管理等。 是否需要管理是专业软件开发
和业余编程程管理者与其他工程管理者的性质是相同的， 但软件工程管理很多方面有显著的区别，这导致了 软件工程管理的难度相当大。许多大型软件项目的 失败也告诉我们：软件管理困难重重。
▪ 软件产品是无形的； ▪ 没有标准的软件过程； ▪ 大型软件项目经常是“一次性的”。
软件项目管理的特点
▪ 项目管理是一项复杂的工作。 ▪ 项目管理具有创造性。 ▪ 项目管理需要集权领导和建立专门的
项目组织。
▪ 项目负责人在项目管理中起着非常重
要的作用。
具有创新性的工程项目经常会存在进度问题。
软件项目管理活动
▪ 以需求工程为例(以建立原型来帮助验证需求)：
活动
可行性研究
需求分析
原型开发
设计研究
需求描述
可行性研究 报告
用户需求
估算报告
里程碑
体系结构设 计
系统需求
项目进度
▪ 项目进度对软件管理者的要求是十分苛刻 的。管理人员必须估算完成各项活动所需 要的时间和资源，并按照一定的顺序把他 们紧密组织起来。
▪ 项目进度包括把一个项目所有工作分解为 若干独立活动，以及完成这些活动所需的 时间。
木板房的第 2、4两面墙 的长度是第 1、3两面墙 的一倍。
甘特图
各道工序估计需要时间（小时）
墙壁 工序 刮旧漆 刷新漆
1或3
2
3
2或4
4
6
清理 1 2
一种做法是，先刮掉4面墙的旧漆，然后给每面墙刷 新漆，最后清除每个窗户上的油漆，共需时间36小时。 显然，这是效率最低的做法，任何时候都有10名工人 闲着没事干。
▪ 提出项目建议书 ▪ 项目规划与进度 ▪ 项目成本管理 ▪ 项目监督和评审 ▪ 人员管理 ▪ 拟定工作报告
项目建议书
▪ 项目建议书要写清楚：项目的目标和实
现该目标的方法；还要估算项目的成本 和进度；有时还要说明与某一特定机构 或团队签约的理由。
▪ 许多软件机构之所以存在是因为其手头
有大量的建议书和合同。
可交付的文档
▪ 可交付的文档是交付给客户的项目成果， 通常是在项目的描述、设计等主要项目 阶段结束时交付。
✓ 可交付的文档也是里程碑，但里程碑不一定要 交付。里程碑是项目内部的阶段性成果，供项 目管理者来检查项目进展情况。
软件过程中的里程碑
▪ 要建立里程碑，软件过程就一定要分解成一系 列相关的基本活动，而每一个这样的基本活动 都要建立相应的输出结果。
✓引言 ✓项目组织 ✓风险分析 ✓软硬件资源需求
✓工作分解 ✓项目进度 ✓监控和报告机制
项目里程碑
▪ 一个项目里程碑就是一个软件过程活动的 终结。在每个里程碑都应该有一个正式的 可以提交给管理层的输出结果。
▪ 里程碑应代表该项目的一个特定的逻辑意 义上的阶段的终结。
▪ 里程碑的两个必要特征：
与软件开发进展相关联； 在完成时必须非常明显。
进度管理工具
项目进度通常用一系列的图表表示，通过 这些图表可以了解任务分解、活动依赖关 系和人员分配情况。
常用的项目进度表示法有：
✓甘特图（Gantt） ✓活动网络图（PERT）
常用软件管理工具是：MS-Project
甘特图
▪ 是历史悠久、应用广泛的制定进度计划的 工具。
例： 假设有一座陈旧的矩形木板房需要重新油漆。这项工作必 须分3步：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗 户上的油漆。 一共分配了15名工人去完成这项工作，而工具只有：5把 刮旧漆的刮板，5把刷漆用的刷子，5把清除溅在窗户上油 漆的小刮刀。 如何安排工作，最有效？
正常情况，各活动应至少持续1周； 对所有活动安排一个最高的时间限制（8～10周
左右），如一项活动持续时间超过限制，就应该 再次细分； 估算进度时，管理者不能想当然认为项目的每个 阶段都不会出问题； 初时间外，还必须估算完成每项任务所需的资源： 人力资源和其他可能的资源。
经验法则：估算时先假定什么问题也没有，然后再把预计出 现的问题加到估计中去（＋30％）。还要考虑因偶然因素带 来的意想不到的问题（＋20％）。