软件工程项目管理课件
合集下载
《软件工程》教学课件 第11章 软件项目管理
式为组织型、半独立型或嵌入型。
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
软件工程项目沟通管理
状态报告 进度报告 预测 变更请求
项目计划 工作成果
绩效报告
绩效报告一般有三种形式： 绩效报告一般有三种形式： 定期项目报告、阶段审查、 定期项目报告、阶段审查、紧急报告 状态评审会议是绩效报告的重要方法之一。 状态评审会议是绩效报告的重要方法之一
项目绩效报告内容
自上次报告以来的主要绩效成果 前期问题解决的情况 项目实施的计划完成情况及其与计划的差距
项目经理需要控制沟通，但不能控制所有信息
项目经理的沟通时间与沟通对象
对于一般项目而言，项目经理70~90%的时间花在沟通上；
大量的项目干系人、信息源、信息类型、信息渠道可能都需要通过项 目经理而发生作用，项目经理必须保持沟通畅通，避免成为 “bottleneck
of communication”
及时发现并排除沟通障碍
项目沟通管理 Project Communication Management
1 2 3 4 5 6 7 为什么要进行沟通管理 什么是项目沟通管理 沟通计划编制 信息发送 绩效报告 管理收尾 改善沟通的建议
1 Why沟通管理 沟通管理？ 沟通管理
沟通是把一个组织中的成员联系在一起， 沟通是把一个组织中的成员联系在一起，以 实现共同目标的手段。 实现共同目标的手段。
2.1 项目经理在沟通中的中心角色
沟通促成者 (communication facilitator) 协调者 (coordinator) 领导者 沟通仲裁者 (referee) (conflict solver) 谈判者 (negotiator) 聆听者 (listener) 解释者 (interpreter)
聆听和接收信息的技巧
使用目光接触 展现恰当的面部表情 避免表示分心的举动或手势 提问、 提问、复述 避免随便打断对方 多听少说 使听者与说者的角色顺利转换。 使听者与说者的角色顺利转换。
项目计划 工作成果
绩效报告
绩效报告一般有三种形式： 绩效报告一般有三种形式： 定期项目报告、阶段审查、 定期项目报告、阶段审查、紧急报告 状态评审会议是绩效报告的重要方法之一。 状态评审会议是绩效报告的重要方法之一
项目绩效报告内容
自上次报告以来的主要绩效成果 前期问题解决的情况 项目实施的计划完成情况及其与计划的差距
项目经理需要控制沟通，但不能控制所有信息
项目经理的沟通时间与沟通对象
对于一般项目而言，项目经理70~90%的时间花在沟通上；
大量的项目干系人、信息源、信息类型、信息渠道可能都需要通过项 目经理而发生作用，项目经理必须保持沟通畅通，避免成为 “bottleneck
of communication”
及时发现并排除沟通障碍
项目沟通管理 Project Communication Management
1 2 3 4 5 6 7 为什么要进行沟通管理 什么是项目沟通管理 沟通计划编制 信息发送 绩效报告 管理收尾 改善沟通的建议
1 Why沟通管理 沟通管理？ 沟通管理
沟通是把一个组织中的成员联系在一起， 沟通是把一个组织中的成员联系在一起，以 实现共同目标的手段。 实现共同目标的手段。
2.1 项目经理在沟通中的中心角色
沟通促成者 (communication facilitator) 协调者 (coordinator) 领导者 沟通仲裁者 (referee) (conflict solver) 谈判者 (negotiator) 聆听者 (listener) 解释者 (interpreter)
聆听和接收信息的技巧
使用目光接触 展现恰当的面部表情 避免表示分心的举动或手势 提问、 提问、复述 避免随便打断对方 多听少说 使听者与说者的角色顺利转换。 使听者与说者的角色顺利转换。
软件工程导论软件项目管理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 按指定方法修改程序的难度；
SE1101-lecture16_软件项目管理49——【软件工程 精品资源】
• （3）其他硬件设备——专用软件开发时需要的特殊硬件 资源。
• 宿主机连同必要的软件工具构成软件开发系统。 • 软件资源包括用于开发的运行平台、各种CASE工具可以
帮助分析和设计软件、开发程序所有的编程语言等。
2020/9/18
广东工业大学计算机学院
5
3. 可复用构件资源
• 为了促成软件的复用，以提高软件的生产率和软件产品的质量， 可建立可复用的软件部件库。根据需要，对软件部件稍做加工， 就可以构成一些大的软件包。这要求这些软件部件应加以编目， 以利于引用，并进行标准化和确认，以利于应用和集成。
• 对一些规模较大的项目，在整个软件生存期中，各种人员的参与情 况是不一样的。如图初1级1-技2所术人示员
高
高高级级技技术术人人员员
初级技术人员
管理人员
管理人员
计 需 概详 编单 划 求 要细 码元
分 设设 测 析 计计 试
整确 体认 测测 试试
图11-2 管理人员与技术人员的参与情况
2020/9/18
这是一种常见的估算方法。它的优点是估算各个部分的准确性高。 缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多 与软件开发有关的系统级工作量（配置管理、质量管理、项目管 理）。所以往往估算值偏低，必须用其他方法进行检验和校正。
• 3. 差别估算法
这种方法综合了上述两种方法的优点，其想法是把待开发的软件项 目与过去已完成的软件项目进行类比，从其开发的各个子任务中区 分出类似的部分和不同的部分。类似的部分按实际量进行计算，不 同的部分则采用相应的方法进行估算。这种方法的优点是可以提高 估算的准确度，缺点是不容易明确“类似”的界限。
• IBM模型是一个静态单变量模型，它利用已估算的特性，例如源代码
• 宿主机连同必要的软件工具构成软件开发系统。 • 软件资源包括用于开发的运行平台、各种CASE工具可以
帮助分析和设计软件、开发程序所有的编程语言等。
2020/9/18
广东工业大学计算机学院
5
3. 可复用构件资源
• 为了促成软件的复用，以提高软件的生产率和软件产品的质量， 可建立可复用的软件部件库。根据需要，对软件部件稍做加工， 就可以构成一些大的软件包。这要求这些软件部件应加以编目， 以利于引用，并进行标准化和确认，以利于应用和集成。
• 对一些规模较大的项目，在整个软件生存期中，各种人员的参与情 况是不一样的。如图初1级1-技2所术人示员
高
高高级级技技术术人人员员
初级技术人员
管理人员
管理人员
计 需 概详 编单 划 求 要细 码元
分 设设 测 析 计计 试
整确 体认 测测 试试
图11-2 管理人员与技术人员的参与情况
2020/9/18
这是一种常见的估算方法。它的优点是估算各个部分的准确性高。 缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多 与软件开发有关的系统级工作量（配置管理、质量管理、项目管 理）。所以往往估算值偏低，必须用其他方法进行检验和校正。
• 3. 差别估算法
这种方法综合了上述两种方法的优点，其想法是把待开发的软件项 目与过去已完成的软件项目进行类比，从其开发的各个子任务中区 分出类似的部分和不同的部分。类似的部分按实际量进行计算，不 同的部分则采用相应的方法进行估算。这种方法的优点是可以提高 估算的准确度，缺点是不容易明确“类似”的界限。
• IBM模型是一个静态单变量模型，它利用已估算的特性，例如源代码
软件工程与项目管理
软件工程与项目管理软件工程与项目管理是现代信息技术发展过程中的两个重要领域。
软件工程是指通过系统化、规范化的方法，运用工程学原理和方法来开发、维护和管理软件的学科；项目管理则是指利用特定的管理技术和方法，组织、计划、实施、控制和评估项目的整个过程，以实现项目目标。
本文将探讨软件工程与项目管理之间的关系以及它们在实践中起到的作用。
一、软件工程与项目管理的关系软件工程和项目管理在软件开发过程中有着密切的联系。
软件工程强调的是运用系统工程原理和方法来管理和开发软件，而项目管理则是软件工程的具体实施手段之一。
项目管理方法和技术可以帮助软件工程师更好地规划、组织和控制软件开发过程，确保项目能按时、按质量、按成本达到预期目标。
在软件开发项目中，项目管理包括项目计划、需求分析、设计、编码、测试、交付等多个阶段。
软件工程师需要根据项目要求，合理安排资源，制定开发计划，并将其分解成可管理的任务，对任务的进展进行跟踪和控制。
项目管理还包括风险管理、质量管理、团队管理等方面，这些都是软件工程师需要具备的综合能力。
二、软件工程与项目管理的作用1. 提高软件开发效率：软件工程和项目管理的结合，可以提高软件开发的效率。
通过规范化的软件开发过程和项目管理流程，可以准确估算任务量、合理分配资源，避免重复劳动和资源浪费，提高开发效率。
2. 管理需求变更：软件开发过程中，需求变更是常见的情况。
软件工程师需要及时响应需求变更，并通过项目管理方法进行有效管理，确保变更后的需求能够及时、准确地实施到软件开发中。
3. 控制项目进度和质量：软件工程和项目管理可以帮助软件开发项目有效控制进度和质量。
在项目计划阶段，可以通过制定合理的计划和阶段性目标，确保项目按时完成；在质量管理方面，可以通过制定测试计划和质量标准，进行严格的测试和评估，提高软件质量。
4. 提高团队协作能力：软件开发项目通常由多个人组成的团队来完成，团队成员之间的沟通和协作能力对项目的成功至关重要。
软件工程培训课件(PPT)
编码效率技巧：在保证代 码质量的前提下，应该尽 可能提高编码效率，减少 不必要的重复工作。
单元测试的方法与工具
测试用例设 计
执行测试流 程
测试工具选 择
测试结果分 析和报告
集成测试的方法与工具
测试方法：自 下而上、自上
而下
测试工具： JUnit、
Te s t N G 、 Selenium等
测试目的：检 测模块之间的 接口是否正确
方法：采用版本控制、变更 控制、状态报告等手段进行
管理
感谢观看
汇报人：
软件风险管理的方法与策略
风险识别：识别潜在的风险和 问题
风险评估：评估风险的大小和 影响
风险应对：制定应对策略和措 施
风险监控：持续监控风险的变 化和进展
软件配置管理的基本概念与方法
目的：确保软件产品的完整 性、一致性和可追溯性
范围：包括文档、程序、数 据等所有软件工程产品
定义：软件配置管理是一种 标识、组织和控制修改的技 术
质量控制：通过测试、统计等方 法，对软件开发过程中的质量进 行监控和评估，及时发现和解决 问题。
添加标题
添加标题
添加标题
添加标题
质量保证：通过一系列的质量保 证活动，如代码审查、测试、文 档编写等，确保软件质量的稳定 性和可靠性。
工具和技术：使用一些工具和技 术来辅助软件质量管理，如代码 审查工具、测试工具、项目管理 工具等。
编写要求：清晰明了，易于理解，方便查阅，及时更新
编写目的：方便用户和系统管理员使用和维护系统
06
软件工程管理
软件项目计划与进度安排
定义项目目标和范围 确定关键路径和里程碑 分配资源和工作任务 监控和控制项目进度
软件工程课件(全)ppt
第1章 1.2软件工程
1.2.1 软件工程的定义和目标
为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计 算机科学会议上，Fritz Bauer首次提出“软件工程”的概念。
按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一 条主要出路。
软件工程的主要思想是强调软件开发过程中应用工程化原则的重要性。软 件工程的目标是实现软件的优质高产。软件工程的目的是在经费的预算范围内， 按期交付出用户满意的、质量合格的软件产品。
第1章 1.1软件与软件危机
1.1.3 软件危机
2. 软件危机产生的原因
（1）忽视软件开发前期的调研和需求分析工作。 （2）缺乏软件开发的经验和有关软件开发数据的积累，使得开发计划很难制定。 （3）开发过程缺乏统一的、规范化的方法论指导。 （4）忽视与用户、开发组成员间的及时有效的沟通。 （5）文档资料不规范或不准确。导致开发者失去工作的基础，管理者失去管理的依据。 （6）没有完善的质量保证体系。
第1章 1.1软件与软件危机
1.1.1 软件的定义及其特点
2.软件具有下列特点：
比硬件发展慢
是逻辑产品
软件
生产与硬件不同 不会磨损和老化
成本高、风险高
手工开发为主
依赖硬件
第1章 1.1软件与软件危机
1.1.2 软件的发展及其分类
1.软件技术的发展
程序设计
程序系统
软件工程
第1章 1.1软件与软件危机
第1章 1.1软件与软件危机
1.1.3 软件危机
3. 软件危机解决途径
要解决软件危机问题，需要采取以下措施： （1）使用好的软件开发技术和方法。 （2）使用好的软件开发工具，提高软件生产率。 （3）有良好的组织、严密的管理，各方面人员相互配合共同完成任务。 为了解决软件危机，既要有技术措施（好的方法和工具），也要有组织管理措施。软件工 程正是从技术和管理两方面来研究如何更好地开发和维护计算机软件的。
2020年10月自考计算机专业《软件工程》自学课件第十三章 软件项目管理
E＝5.5＋0.73×(KLOC)1.16 （3）Boehm简单模型
E＝3.2×(KLOC)1.05 （4）Doty模型（在KLOC＞9的情况下）
E＝5.288×(KLOC)1.047
2. 面向FP的估算模型
（1）Albrecht & Gaffney模型 E＝－13.39＋0.0545FP
（2）Kemerer模型 E＝60.62＋7.728×10－8FP3
LET＝23－2＝21
类似地，事件9的最迟时刻为
LET＝21－1＝20
事件8的最迟时刻为
LET＝min｛21－6，20－0｝＝15
图13.4中每个圆圈内右下角的数字就是该事件的最迟时刻。
13.3.5 关键路径
➢ 关键路径上的事件（关键事件）必须准时发生， 组成关键路径的作业（关键作业）的实际持续时 间不能超过估计的持续时间，否则工程就不能准 时结束。
这个例子说明了工程网络比Gantt图优越的地方： 它显式地定义事件及作业之间的依赖关系，Gantt 图只能隐含地表示这种关系。但是Gantt图的形式 比工程网络更简单更直观，为更多的人所熟悉， 因此，应该同时使用这两种工具制定和管理进度 计划，使它们互相补充取长补短。
13.4 人员组织
13.4.1 民主制程序员组 民主制程序员组通常采用非正式的组织方式，
估算功能点的步骤
（1）计算未调整的功能点数UFP
UFP＝a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf 其中，ai（1≤i≤5）是信息域特性系数
（2）计算技术复杂性因子TCF
14
DI Fi i 1
技术复杂性因子TCF由下式计算： TCF＝0.65+0.01×DI
因为DI的值在0～70之间，所以TCF的值在 0.65～1.35之间。
E＝3.2×(KLOC)1.05 （4）Doty模型（在KLOC＞9的情况下）
E＝5.288×(KLOC)1.047
2. 面向FP的估算模型
（1）Albrecht & Gaffney模型 E＝－13.39＋0.0545FP
（2）Kemerer模型 E＝60.62＋7.728×10－8FP3
LET＝23－2＝21
类似地，事件9的最迟时刻为
LET＝21－1＝20
事件8的最迟时刻为
LET＝min｛21－6，20－0｝＝15
图13.4中每个圆圈内右下角的数字就是该事件的最迟时刻。
13.3.5 关键路径
➢ 关键路径上的事件（关键事件）必须准时发生， 组成关键路径的作业（关键作业）的实际持续时 间不能超过估计的持续时间，否则工程就不能准 时结束。
这个例子说明了工程网络比Gantt图优越的地方： 它显式地定义事件及作业之间的依赖关系，Gantt 图只能隐含地表示这种关系。但是Gantt图的形式 比工程网络更简单更直观，为更多的人所熟悉， 因此，应该同时使用这两种工具制定和管理进度 计划，使它们互相补充取长补短。
13.4 人员组织
13.4.1 民主制程序员组 民主制程序员组通常采用非正式的组织方式，
估算功能点的步骤
（1）计算未调整的功能点数UFP
UFP＝a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf 其中，ai（1≤i≤5）是信息域特性系数
（2）计算技术复杂性因子TCF
14
DI Fi i 1
技术复杂性因子TCF由下式计算： TCF＝0.65+0.01×DI
因为DI的值在0～70之间，所以TCF的值在 0.65～1.35之间。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程项目管理
甘特图
• 甘特图是一种条形图，表示了项目的日程安排和各项活动的开始 和完成时间。从右往左读，条形图清晰地给出了活动的开始和结 束。
软件工程项目管理
MS Project--甘特图
软件工程项目管理
资源分配问题
• 除了考虑进度安排外，项目管理者还要考虑参加项目活动人员 的 分配。可以生成条形图。
人员
源于开发团队成员的风险 如招聘不到符合要求的职员 在项目关键时期，关键人员出现意外事情 职员培训跟不上
机构
源于开发的机构环境的风险 重新的机构调整，管理层的变更 开发过程中财务出现问题
工具
源于CASE工具和其他支持软件的风险 如CASE效率低 CASE工具不能集成
需求
源于客户对需求变更的风险 如需求发生变更，主题设计要返工，客户的不了解。
项目管理
•1.项目调度 •2.风险管理
软件工程项目管理
1.项目调度
项目调度包括把一个项目所有工作分解为若干独 立活动，以及判断完成这些活动所需的时间。
项目调度对软件管理者的要求是十分苛刻的。管 理人员必须估算完成各项活动所需要的时间和资 源，并按照一定的顺序把他们紧密组织起来。
软件工程项目管理
识别活动
软件需求
识别活动 依赖关系
估算活动 的资源
为活动分 配人员
创建项目 图表
图 1 项目调度过程
软件工程项目管理
活动图表 及条形图
活动分解及进度管理
• 正常情况，各活动至少持续一周。 • 对所有活动安排一个最高时限（8-10周），如一
项活动持续时间超过限制，就应该再次细分。 • 在估算进度时，管理者不能认为项目的每个阶段
• 风险管理在项目管理中不可缺少，因为绝大多数项目都有不确定 性。（不确定性包括过宽泛的需求，对开发时间和资源估算的困 难，项目对个人的技术依赖以及客户需求发生变化）
• 对项目管理者的要求：应该预见风险，及时制定应急计划。并采 取措施规避这些风险。
软件工程项目管理
风险管理的过程风险识别Fra bibliotek风险分析
风险规划
• 条形图是表示在哪些时间段雇佣哪些员工。
软件工程项目管理
人员分配及其时间表
软件工程项目管理
项目调度总结
• 项目调度对管理者要求严格。 • 项目调度就是把项目计划的某些部分用图形的情形给描述出来。 • 项目调度包括项目活动之间相互关系的网络活动图和表示各个活
动持续的条形图。
软件工程项目管理
2.风险管理
• 风险管理要求管理者能够预见可影响项目进度或正在开发的软件 产品质量的风险，并采取行动避免这些风险。是管理者的一项重 要任务。
• 有效的风险管理能使我们从容面对问题，避免这些风险带来无法 承受的开支或进度失控。
软件工程项目管理
风险种类
• 项目风险：项目进度或资源的风险。（如有经验的设计人员的流 失）
• 产品风险：开发的软件的质量或性能的风险。 • 业务风险：软件开发机构和软件购买机构的风险。
软件工程项目管理
可能存在的风险
可能存在的风险表
风险
风险类型 描述
职员跳槽
项目
有经验的职员将会未完成项目就跳槽
管理层变更 硬件缺乏
项目 项目
管理层结构发生变化，不同的管理者考虑和管 理的事情不同
项目所需的硬件没有按时交付
需求变更
项目和产品 软件需求与预期相比，变化很多
描述延迟
项目和产品 主要接口的描述未能按时完成
低估系统规模
项目和产品 过低估计了系统规模
CASE工具性能较差 产品
支持项目的CASE工具达不到要求
技术变更
业务
系统的基础技术被新技术的代替
产品竞争
业务
系统还未交付，就已经有其他产品上市
软件工程项目管理
风险管理的必要性
条形图（甘特图（Gantt）） 活动网络图（PERT） • 常用软件管理工具是：MS-Project
软件工程项目管理
进度管理实践—MS Project
表1： 任务的持续时间及其依赖关系
任务
持续时间（天数）
依赖关系
T1
8
T2
15
T3
15
T1(M1)
T4
10
T5
10
T2，T4(M2)
T6
5
T1，T2(M3)
关键路径。关键路径耗时等于整个工程的耗时，因此，要想缩短 工程时间，就必须找出关键路径，并研究如何减少关键路径的耗 时。
软件工程项目管理
关键路径
• 关键路径是指完成项目所需的最少时间。可以通过考察活动图中 最长的路径（关键路径）来估算。
• 项目 总体安排进度时由关键路径决定的。任何关键活动与进度安 排的偏离都会导致项目的延期交付。
估算
源于系统特性和系统资源的风险 如低估软件开发时间，规模，等等。
软件工程项目管理
风险分析
• 进行风险分析时，要逐一考虑每个已经识别出的风险，并对风险 出现的可能性和严重性做出判断。
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)
软件工程项目管理
MS Project—活动网络图
软件工程项目管理
关键路径解释
• 关键路径（CPM，Critical Path Method） • 从起点到终点，可以有许多条路径，我们把耗时最长的路径称作
风险监控
潜在的风险 列表
优先级高的 风险列表
风险规避和 应急计划
风险评估
图：风险管理过程
软件工程项目管理
风险管理的过程
• 风险识别：识别可能的项目，产品和业务风险。 • 风险分析：评估这些风险出现的可能性及其后果。 • 风险规划：制定计划说明如何规避风险和降低风险对项目的影响。 • 风险控制：不断的进行评估，并及时修改风险计划。
都不会出问题。 • 除时间外，还必须估算完成每项任务所需的资源，
包含人力资源和其他资源。
软件工程项目管理
估算进度的经验法则
• 估算时先假定什么问题也没有，然后再把预计出现的问题加到估 计中去（＋30％）。还要考虑因偶然因素带来的意想不到的问题 （＋20％）。
软件工程项目管理
项目进度管理工具
• 项目进度通常用一系列的图表表示。 • 常用的项目进度表示法有：
软件工程项目管理
风险识别
• 风险识别是风险管理的第一阶段。风险识别过程需要列出可能的 风险类型。
• 包括：技术风险，人员风险，机构风险，工具风险，需求风险， 估算风险。
软件工程项目管理
风险及其风险类型
风险类型 潜在存在的风险
技术
源于开发系统的软件和硬件的风险 如数据库处理速度不快 复用的软件组件有缺陷，限制项目功能。
甘特图
• 甘特图是一种条形图，表示了项目的日程安排和各项活动的开始 和完成时间。从右往左读，条形图清晰地给出了活动的开始和结 束。
软件工程项目管理
MS Project--甘特图
软件工程项目管理
资源分配问题
• 除了考虑进度安排外，项目管理者还要考虑参加项目活动人员 的 分配。可以生成条形图。
人员
源于开发团队成员的风险 如招聘不到符合要求的职员 在项目关键时期，关键人员出现意外事情 职员培训跟不上
机构
源于开发的机构环境的风险 重新的机构调整，管理层的变更 开发过程中财务出现问题
工具
源于CASE工具和其他支持软件的风险 如CASE效率低 CASE工具不能集成
需求
源于客户对需求变更的风险 如需求发生变更，主题设计要返工，客户的不了解。
项目管理
•1.项目调度 •2.风险管理
软件工程项目管理
1.项目调度
项目调度包括把一个项目所有工作分解为若干独 立活动，以及判断完成这些活动所需的时间。
项目调度对软件管理者的要求是十分苛刻的。管 理人员必须估算完成各项活动所需要的时间和资 源，并按照一定的顺序把他们紧密组织起来。
软件工程项目管理
识别活动
软件需求
识别活动 依赖关系
估算活动 的资源
为活动分 配人员
创建项目 图表
图 1 项目调度过程
软件工程项目管理
活动图表 及条形图
活动分解及进度管理
• 正常情况，各活动至少持续一周。 • 对所有活动安排一个最高时限（8-10周），如一
项活动持续时间超过限制，就应该再次细分。 • 在估算进度时，管理者不能认为项目的每个阶段
• 风险管理在项目管理中不可缺少，因为绝大多数项目都有不确定 性。（不确定性包括过宽泛的需求，对开发时间和资源估算的困 难，项目对个人的技术依赖以及客户需求发生变化）
• 对项目管理者的要求：应该预见风险，及时制定应急计划。并采 取措施规避这些风险。
软件工程项目管理
风险管理的过程风险识别Fra bibliotek风险分析
风险规划
• 条形图是表示在哪些时间段雇佣哪些员工。
软件工程项目管理
人员分配及其时间表
软件工程项目管理
项目调度总结
• 项目调度对管理者要求严格。 • 项目调度就是把项目计划的某些部分用图形的情形给描述出来。 • 项目调度包括项目活动之间相互关系的网络活动图和表示各个活
动持续的条形图。
软件工程项目管理
2.风险管理
• 风险管理要求管理者能够预见可影响项目进度或正在开发的软件 产品质量的风险，并采取行动避免这些风险。是管理者的一项重 要任务。
• 有效的风险管理能使我们从容面对问题，避免这些风险带来无法 承受的开支或进度失控。
软件工程项目管理
风险种类
• 项目风险：项目进度或资源的风险。（如有经验的设计人员的流 失）
• 产品风险：开发的软件的质量或性能的风险。 • 业务风险：软件开发机构和软件购买机构的风险。
软件工程项目管理
可能存在的风险
可能存在的风险表
风险
风险类型 描述
职员跳槽
项目
有经验的职员将会未完成项目就跳槽
管理层变更 硬件缺乏
项目 项目
管理层结构发生变化，不同的管理者考虑和管 理的事情不同
项目所需的硬件没有按时交付
需求变更
项目和产品 软件需求与预期相比，变化很多
描述延迟
项目和产品 主要接口的描述未能按时完成
低估系统规模
项目和产品 过低估计了系统规模
CASE工具性能较差 产品
支持项目的CASE工具达不到要求
技术变更
业务
系统的基础技术被新技术的代替
产品竞争
业务
系统还未交付，就已经有其他产品上市
软件工程项目管理
风险管理的必要性
条形图（甘特图（Gantt）） 活动网络图（PERT） • 常用软件管理工具是：MS-Project
软件工程项目管理
进度管理实践—MS Project
表1： 任务的持续时间及其依赖关系
任务
持续时间（天数）
依赖关系
T1
8
T2
15
T3
15
T1(M1)
T4
10
T5
10
T2，T4(M2)
T6
5
T1，T2(M3)
关键路径。关键路径耗时等于整个工程的耗时，因此，要想缩短 工程时间，就必须找出关键路径，并研究如何减少关键路径的耗 时。
软件工程项目管理
关键路径
• 关键路径是指完成项目所需的最少时间。可以通过考察活动图中 最长的路径（关键路径）来估算。
• 项目 总体安排进度时由关键路径决定的。任何关键活动与进度安 排的偏离都会导致项目的延期交付。
估算
源于系统特性和系统资源的风险 如低估软件开发时间，规模，等等。
软件工程项目管理
风险分析
• 进行风险分析时，要逐一考虑每个已经识别出的风险，并对风险 出现的可能性和严重性做出判断。
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)
软件工程项目管理
MS Project—活动网络图
软件工程项目管理
关键路径解释
• 关键路径（CPM，Critical Path Method） • 从起点到终点，可以有许多条路径，我们把耗时最长的路径称作
风险监控
潜在的风险 列表
优先级高的 风险列表
风险规避和 应急计划
风险评估
图：风险管理过程
软件工程项目管理
风险管理的过程
• 风险识别：识别可能的项目，产品和业务风险。 • 风险分析：评估这些风险出现的可能性及其后果。 • 风险规划：制定计划说明如何规避风险和降低风险对项目的影响。 • 风险控制：不断的进行评估，并及时修改风险计划。
都不会出问题。 • 除时间外，还必须估算完成每项任务所需的资源，
包含人力资源和其他资源。
软件工程项目管理
估算进度的经验法则
• 估算时先假定什么问题也没有，然后再把预计出现的问题加到估 计中去（＋30％）。还要考虑因偶然因素带来的意想不到的问题 （＋20％）。
软件工程项目管理
项目进度管理工具
• 项目进度通常用一系列的图表表示。 • 常用的项目进度表示法有：
软件工程项目管理
风险识别
• 风险识别是风险管理的第一阶段。风险识别过程需要列出可能的 风险类型。
• 包括：技术风险，人员风险，机构风险，工具风险，需求风险， 估算风险。
软件工程项目管理
风险及其风险类型
风险类型 潜在存在的风险
技术
源于开发系统的软件和硬件的风险 如数据库处理速度不快 复用的软件组件有缺陷，限制项目功能。