软件工程导论课件第13章+软件项目管理概述

合集下载

软件工程导论概要.优秀精选PPT

软件工程导论概要.优秀精选PPT

。这时软件危机出
这个阶段要回答的关键问题是:“对上一阶段所确定的问题有行得通的解决办法吗?” 系统分析员需要进行一次大大压缩和简化了的
现,随之而来人们开始研究消除危机的途径,从而形成一 系统分析和设计的过程,也就是在较抽象的高层次上进行的分析和设计的过程。
这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。
通常把在软件生命周期全过程中使用的一整套技术方法 的集合称为方法学(Methodology),也称为范型 (Paradigm)。
软件工程方法学的3要素:方法、工具和过程
一. 传统方法学
也称为生命周期方法学或结构化范型。从时间角度
1)对软件开发成本和进度的估计常常很不准确; 2)用户对完成的软件系统不满意的现象经常发生; 3)软件产品的质量往往靠不住; 4)软件常常是不可维护的; 5)软件通常没有适当的文档资料; 6)软件成本在计算机系统总成本中所占的比例逐年上升; 7)软件开发生产率提高的速度跟不上计算机应用的发展
趋势。
1)软件本身特点造成;
极限编程的整体开发过程:
如何开发门软件新,以的满足学对软科件日—益增—长的软需求件工程学。
软件危机:计算机软件的开发和维护过程中所遇 到的一系列严重问题。(正常、不正常运行软件都 具有这种问题)
软件危机的实质: 如何开发软件,以满足对软件日益增长的需求 如何维护数量不软件工程学:主要应用工程的方法和技术 研究软件开发与维护的方法、工具和管理的一 门交叉学科。
2)程序设计方法学:主要应用数学的方法研 究程序的性质以及程序设计的理论和方法的学 科。
1.2 软件工程
软件工程的介绍 1968年NATO会议:软件工程就是为了经济地获 得可靠的且能在实际机器上有效地运行的软件, 而建立和使用完善的工程原理。

软件工程第13章 软件项目管理

软件工程第13章 软件项目管理
通常在项目的目标确定和软件基本功能确定之后,就应 该着手项目计划的制定工作。项目估算是制订计划项目开展初期阶段的重要工作,其主要目 标是得到项目计划,或者说计划(plan)是策划 (planning)的结果。
13.2 项目估算
• 项目策划中需要开展的活动
13.2 项目估算
成本计算
一个软件组织在完成多个项目以后积累了一些数据,进行 成本分析后便可得到自己的生产率数值和人工价格。 ➢ 生产率是平均每个人月完成的源程序行数,可记为 KLOC/人月或FP/人月。 ➢ 人工价则为每人月的价值。 有了这两个数值,如果在估出项目规模以后就可以很容易 得到项目的工作量和成本,即
当然,在项目的开始只是对代码行的估计值。另一表示 方法是功能点,记为FP,它是根据软件需求中的功能估算 的。
13.2 项目估算
(2)工作量。项目的工作量按项目将要投入的人工来考 虑,以一个人工作一个月为单位,记为“人月”。 (3)成本。软件项目的成本通常只考虑投入的人工成本, 如某项目投入的总人工费用为12万元。
工作量=规模/生产率 成本=工作量×人工价
项目估算的功能点方法
• 功能点方法(function point)简称FP方法,该 方法克服了项目开始时无法得知源程序行数的实 际困难,从软件产品的功能度(functionality) 出发估算出软件产品的规模。
项目估算的功能点方法
1.功能度
功能点方法是以项目的需求规格说明中已经得到确认的软 件功能为依据,着重分析要开发系统的功能度,并且认为, 软件的大小与软件的功能度相关,而与软件功能如何描述无 关,也与功能需求如何设计和实现无关。
(2)时限要求。项目应在合同规定的期限内完成。 (3)项目开销限制在预算之内。

软件项目管理课程PPT80页

软件项目管理课程PPT80页

36
10
155 60 8
5
对该方法的有效性有争议:
支持:易计算,很多软件估算模型以它为关键的输入。 反对:LOC依赖于语言,不适用于非过程化语言,在 分析与设计完成之前难以估算。
六盘水师范学院 孙新杰
27
(2)面向功能的度量
“功能”不能直接测量,利用其他的测量数据间接 地导出。 Albrecht提出来的一种称为功能点的度量。用 下表计算5个信息域的值:
另外,可根据文档的页数、评审的时间、功能点及 源代码行数来度量软件的生产率。
六盘水师范学院 孙新杰
23
项目度量可在项目进行的基础上评估产品的质量, 以指导在必要时修改技术方法以改进质量。
软件项目度量建议每个项目都应该测量: • 输入:完成工作所需要的资源(如人员、环境); • 输出:软件工程过程中产生的工作产品; • 结果:最终产品的有效性。 项目度量集成起来产生对整个软件组织公用的过程 度量。
六盘水师范学院 孙新杰
6
⑴列出需要澄清问题的清单
⑵安排与用户进行讨论的会议 ⑶评审用户要求及范围的陈述 ⑷研究推荐的解决方案 ⑸为正式的会议准备工作文档 ⑹共同制订能反映软件的数据、功能和行为特
征的规约,形成软件范围的文档 ⑺评审文档 ⑻根据需求修改文档 …… 庇护性活动贯穿于整个过程。
六盘水师范学院 孙新杰
2名在转换期间数据输入人员
$960
(40小时/名,12美元/小时)
六盘水师范学院 孙新杰
16
培训: 三天的开发人员内部培训课程 30个用户,三天的内部培训课程
复印 磁盘、纸张等消耗品 购买硬件、软件:
20台工作站Windows软件 20台工作站内存升级 网络软件 20台工作站办公软件产品

《软件工程导论》课件

《软件工程导论》课件

定义
软件维护是指在软件运行过程中,为了改 正错误、满足新的需求或改进性能等目的 ,对软件进行的修改和调整。
预防性维护
为了提高软件的可维护性和可靠性而进行 的维护活动。
改正性维护
为了纠正软件中存在的错误而进行的维护 活动。
完善性维护
为了扩充和增强软件功能而进行的维护活 动。
适应性维护
为了使软件适应外部环境的变化而进行的 维护活动。
介绍如何评估软件架构的合理性 、可扩展性和可维护性,以及如 何根据业务需求和系统规模选择 合适的架构。
架构设计原则
强调架构设计时应遵循的几个重 要原则,如模块化、开放-封闭原 则、单一职责原则等。
数据设计
数据模型
介绍常见的数据模型,如关系模型、面向对象模型、键-值存储模型等,以及它们的应 用场景和优缺点。
02
03
界面设计原则
交互设计
强调界面设计时应遵循的几个重 要原则,如用户友好、一致性、 可用性等。
介绍常见的交互方式,如按钮、 菜单、对话框等,以及如何通过 良好的交互设计提高用户体验。
05
CHAPTER
软件测试
单元测试
总结词
单元测试是对软件中的最小可测试单元进行检查和验 证,通常以函数或方法为单位进行测试。
详细描述
单元测试主要关注软件中的细节问题,检查单个函数 或方法的正确性、性能和边界条件等。通过单元测试 ,可以尽早发现代码中的错误和缺陷,提高软件质量 。
集成测试
总结词
集成测试是在单元测试的基础上,将多个模块或组件 组合在一起进行测试,以验证它们之间的集成是否正 常工作。
详细描述
集成测试的主要目的是检查模块之间的接口和通信是否 正常,以及是否存在潜在的缺陷或问题。通过集成测试 ,可以确保软件在组合时能够正常工作,满足设计要求 。

软件项目管理课件(完整版)

软件项目管理课件(完整版)
(1)职责; (2)当前系统需要; (3)目标; (4)系统将来的需要。
第三章 项目范围管理
• 软件需求收集遵循的步骤
(1)客户和开发组织确定各自单一联系点,授予 做决定的权利,并代表各自的组织利益行事;
(2)双方举行会议和面谈,讨论各种需求; (3)软件开发组织分析需求的一致性和完整性; (4)开发组织以需求规格说明文档的形式得出讨
• 活动工期估计
工期是开展活动的实际时间加上占用时间。例 如,尽管可能只花一周或5天就能完成一项实际的 工作,但估计的工期可能是两周,目的是根据外 部信息留出一些额外的时间进行调整。
人工量是指完成一项任务所需的工作天数和工作 小时。工期是指时间估计,而不是人工量估计。
第五章 项目时间管理
• 常用的工期估算方法
精度多少
粗数量级
项目生命周期前期, 提供选择决策的成本
经常是项目完成前
估计
得3~5年
-50%~100%
预算估计/概算 早期,1~2年 把钱分配到预算计划 -10%~25%
确定性
项目后期,少于1 为采购提供详细内容, -5%~10%

估计实际费用
第四章 软件项目成本管理
• 估算方法
(1)代码行方法 ; (2)功能点方法; (3)类比估算法; (4)自下而上估算; (5)专家估算法; (6)参数估算法。
第二章 项目集成管理
• 指导和管理项目执行
指导与管理项目执行过程要求项目经理和项目团 队采取多种行动执行项目管理计划,完成项目范 围说明书中明确的工作 。
指导与管理项目执行过程最直接会受到项目应用 领域的影响。
可交付成果是为完成项目管理计划中列入并做了 时间安排的项目工作而进行的过程的成果。

软件工程导论课件之第13章 软件项目管理(第五版)(张海藩编著)

软件工程导论课件之第13章 软件项目管理(第五版)(张海藩编著)

13.1.2 功能点技术

功能点技术依据对软件信息域特性和软件复杂
性的评估结果,估算软件规模。 这种方法用功能点(FP)为单位度量软件规模。

1. 信息域特性 功能点技术定义了信息域的5个特性: 输入项数(Inp):用户向软件输入的项数,这 些输入给软件提供面向应用的数据。 输出项数(Out):软件向用户输出的项数,它 们向用户提供面向应用的信息, 查询数(Inq):查询即是一次联机输入,它导 致软件以联机输出方式产生某种即时响应。 主文件数(Maf):逻辑主文件的数目。 外部接口数(Inf):机器可读的全部接口的数量, 用这些接口把信息传送给另一个系统。



新增加了4个成本因素,它们分别是要求的可重用性、需要 的文档量、人员连续性(即人员稳定程度)和多地点开发。 略去了原始模型中的2个成本因素(计算机切换时间和使用 现代程序设计实践)。 某些成本因素(分析员能力、平台经验、语言和工具经验) 对生产率的影响(即工作量系数最大值与最小值的比率)增 加了,另一些成本因素(程序员能力)的影响减小了。
工序 刮旧漆 2 4 刷新漆 3 6 清理 1 2
表 13.5 各道工序估计需用的时间( 小时) 墙壁 1 或3 2 或4
小时 作业 刮旧漆 刷新漆 清理
2
4
6
8
10 12 14 16 18 20 22 24
第一面墙
第二面墙
第三面墙
第四面墙
Gantt图的主要优点: Gantt图能很形象地描绘任务分解情况,以及 每个子任务(作业)的开始和结束时间。 具有直观简明和容易掌握、容易绘制的优点。 Gantt图的3个主要缺点: 不能显式地描绘各项作业彼此间的依赖关系; 进度计划的关键部分不明确,难于判定哪些部 分应当是主攻和主控的对象; 计划中有潜力的部分及潜力的大小不明确,往 往造成潜力的浪费。

软件工程项目管理ppt课件

软件工程项目管理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

第1讲软件项目管理概述-PPT精选

第1讲软件项目管理概述-PPT精选

©Copyright Xinjun Mao 2005
22
软件项目管理概述
3.3 产品管理
软件需求管理 软件质量保证 软件配置管理
©Copyright Xinjun Mao 2005
23
软件项目管理概述
3.3.1 软件需求管理
获取、文档化和评审用户需求,并对用户需 求的变更进行控制和管理
©Copyright Xinjun Mao 2005
19软件项目管理概述3.2 人员管理 软件项目团队 纪律和激励机制
©Copyright Xinjun Mao 2005
20
软件项目管理概述
3.2.1 软件开发团队
确定团体的结构、明确人员的角色和任务、 加强人员之间的交流与合作,结构合理、任 务明确、团结协作、交流顺畅
©Copyright Xinjun Mao 2005
18
软件项目管理概述
3.1.5 风险管理
对软件开发过程中各种风险进行分析、预测、 评估、监控的过程
– 什么是软件开发风险? – 软件开发可能会有哪些风险? – 如何客观地预测风险? – 如何评估风险带来的影响? – 如何避免和消除风险? – 如何提供工具支持风险分析?……
6
软件项目管理概述
管理是重要的(1/4)
软件项目开发的任务
– 按照预定的进度、成本和质量,开发出满足用 户要求的软件产品
用户需求
确保软件质量
用户需求
成本限制 进度限制
进度 约束
软件开发
成本 约束
高质量软件
©Copyright Xinjun Mao 2005
7
软件项目管理概述
管理是重要的(2/4)

1软件项目管理概述PPT课件

1软件项目管理概述PPT课件

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
提问与解答环节
Questions and answers
56
结束语 CONCLUSION
感谢参与本课程,也感激大家对我们工作的支持与积极的参与。课程 后会发放课程满意度评估表,如果对我们课程或者工作有什么建议和 意见,也请写在上边,来自于您的声音是对我们最大的鼓励和帮助, 大家在填写评估表的同时,也预祝各位步步高升,真心期待着再次相 会!
1
整体 概述
一 请在这里输入您的主要叙述内容

请在这里输入您的主要 叙述内容
三 请在这里输入您的主要叙述内容
2
3
4
5
6
7
8
9ቤተ መጻሕፍቲ ባይዱ
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
57
感谢观看
The user can demonstrate on a projector or computer, or print the presentation and make it into a film
58

《软件项目管理概述》课件

《软件项目管理概述》课件

测试与质量保证
测试计划与策略
制定详细的测试计划和策略,包括测试范围、 方法、资源和时间安排等。
测试执行与跟踪
按照测试计划执行测试,记录测试结果并跟踪 缺陷管理。
质量保证与改进
通过质量保证活动,确保软件质量符合要求,并持续改进软件过程。
发布与维护
发布计划
制定软件发布计划,包括发布时间、发布渠道和宣传推广等。
04
软件项目管理的挑战与解决方案
需求变更与风险管理
在此添加您的文本17字
需求变更管理
在此添加您的文本16字
需求变更在软件开发过程中是常见的,但频繁变更可能导 致项目延期、成本增加和降低质量。
在此添加您的文本16字
应对策略:建立需求变更管理流程,明确变更请求的提出 、评估、批准和实施步骤,确保变更对项目的影响可控。
02
软件项目管理的主要内容
项目计划与组织
项目计划制定
制定详细的项目计划,包括项目目标 、范围、时间表、预算和资源分配等 。
项目组织结构
确定项目团队的组织结构,包括角色 和职责的分配,以及沟通渠道和决策 机制的建立。
需求分析与管理
需求收集
通过访谈、问卷调查和原型演示等方式收集用户需求 。
需求分析
详细描述
软件项目管理的重要性在于,它能够有效地协调和管理软件开发过程中的各种活动,确 保项目按计划进行,及时发现和解决潜在问题,提高软件质量,降低开发成本,并满足
用户需求。
软件项目管理的基本原则
要点一
总结词
软件项目管理的基本原则包括灵活性、沟通、预见性、控 制和持续改进。
要点二
详细描述
灵活性原则要求软件项目管理能够适应变化和不确定性, 及时调整项目计划和策略。沟通原则强调项目团队成员之 间的有效沟通,确保信息的准确传递。预见性原则要求对 可能出现的问题和风险进行预测和预防。控制原则是对项 目过程进行监控和调整,确保项目按计划进行。持续改进 原则要求不断总结经验教训,优化项目管理过程和方法。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

甘特图
甘特图与网络图的比较
甘特图
在进度报告中很有效 在做管理陈述时易于读懂和使用。 作为计划编制工具不是太强。 没有表示活动间的逻辑关系。 网络图
表明活动和事件间的相互关系。 识别关键路径,项目历程和活动排序。 表明工作流程。 帮助编制计划和组织工作。
关键路径法
查找关键路径实例: • 使用箭线图来确定关键路径。 • 使用前导图来确定关键路径。
13.2.3 COCOMO2模型
构造性成本模型:COCOMO(COnstructive COst Model) 。1981年Boehm在《软件工程经济学》中 首次提出了COCOMO模型。1997年Boehm等人提 出的COCOMO2,修订了COCOMO。 3个层次的软件开发工作量估算模型: (1) 应用系统组成模型用于估算构建原型的工作量。 (2) 早期设计模型适用于体系结构设计阶段。 (3)后体系结构模型适用于完成体系结构设计之后的 软件开发阶段。
这类模型的总体结构形式如下: E=A+B×(ev)C 其中,A、B和C是由经验数据导出的常数,E是以 人月为单位的工作量,ev是估算变量(KLOC或 FP)。下面给出几个典型的静态单变量模型。 1.面向FP的估算模型 (1) Albrecht & Gaffney模型 E=-13.39+0.0545FP (2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP
13.3.1 估算开发时间
工期 >=工作量/人力 正常情况下, 估算开发时间的模型方程: (1) Walston_Felix模型: T=2.5E0.35 (2) 原始的COCOMO模型: T=2.5E0.38 (3) COCOMO2模型: T=3.0E0.33+0.2×(b-1.01) (4) Putnam模型: T=2.4E1/3 E是开发工作量(以人月为单位), T是开发时间(以月为单位)。
P生产率参数,反映了下述因素对工作量的影响: 总体过程成熟度及管理水平; 使用良好的软件工程实践的程度; 使用的程序设计语言的级别; 软件环境; 软件项目组的技术及经验; 应用系统的复杂程度。 开发实时嵌入式软件时:P~=2000;电信系统和系 统软件时:P=10000;商业应用系统:P=28000。 如果把项目持续时间延长一些,则可降低完成 项目所需的工作量。
对于相同的KLOC或FP值,用不同模型估算将 得出不同的结果。 主要原因是,这些模型多数都是仅根据若干应 用领域中有限个项目的经验数据推导出来的,适用 范围有限。 因此,必须根据当前项目的特点选择适用的估 算模型,并且根据需要适当地调整(例如,修改模 型常数)估算模型。
13.2.2 动态多变量模型
2. 面向KLOC的估算模型 (1) Walston_Felix模型 E=5.2×(KLOC)0.91 (2) Bailey_Basili模型 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
后体系结构模型软件开发工作量函数: 17 E= a KLOC b f i (13.3)
i 1
E是开发工作量(以人月为单位), a是模型系数, KLOC是估计的源代码行数(以千行为单位), b是模型指数, fi(i=1~17)是成本因素,见下表。
(1) 新增加了4个成本因素: 要求的可重用性、需 要的文档量、人员连续性(即人员稳定程度)和多 地点开发。 (2) 略去了原始模型中的2个成本因素(计算机 切换时间和使用现代程序设计实践)。 (3) 某些成本因素(分析员能力、平台经验、语 言和工具经验)对生产率的影响(即工作量系数最 大值与最小值的比率)增加了,另一些成本因素 (程序员能力)的影响减小了。
项目组规模与项目组总生产率的关系。 P名项目组员之间的通信路径数: MIN= P-1, MAX= P(P-1)/2 通信路径数大约为Pα,其中1<α<2。 一个组员不与任何人通信时个人生产率为L, 每条通信路径导致生产率减少l, 组员个人平均生产率为: Lr=L-l(P-1)r (13.5) 其中,r是对通信路径数的度量,0<r≤1
由多名有经验的软件工程师分别做出估计。 每个人都估计程序的最小规模(a)、最大规模 (b)和最可能的规模(m),分别算出这3种规模的平 均值, 再用下式计算程序规模的估计值: a 4m b L= (13.1)
6
单位是代码行数(LOC) 或千行代码数(KLOC)
代码行技术的优点: 代码是所有软件开发项目都 有的“产品”,且容易计算行数。 代码行技术的缺点是: 源程序仅是软件配置的一 个成分。 为了克服代码行技术的缺点,人们提出了功能 点技术。
下图是用PROJECT制作的甲项目的最简单的一个甘特图
早期的甘特图的最大缺点是通常不反映依赖关系, 但是如果在Project上建立了依赖关系,这种依赖关系会自动 显示在甘特图上。
甘特图
使用项目管理软件可以创建更为复杂的甘特图
甘பைடு நூலகம்图
跟踪甘特图可以用来评价项目的进展
注意: 任务用两种水平横线表示。下部表示计划历史(基准计划历史); 上部表示实际历史。 由于跟踪甘特图是建立在实际开始与完成日期的基础之上,将计划 与实际的项目进度信息进行比较,所以,项目经理可以用它来监控 单个任务和整体项目的进展情况。
i 1
13.3 进度计划
目的:保证项目按时完成 影响工期的因素: 工作量, 资源(人力,设备), 项目特点 方法:把项目分解成许多小任务以利于估计, 执行, 监控 难点:根据项目, 合理分配任务, 优化使用资源, 留有余地 工具: 经验模型, GANTT图, 工程网络 项目管理者必须定义全部项目任务,识别出关键任 务,跟踪关键任务的进展状况。 制定一个详细的进度表,监督项目进度并控制整个 项目。
2. 估算功能点的步骤 用下述3个步骤,可估算出一个软件的功能点 数(即软件规模)。 FP=UFP×TCF
(1) 计算未调整的功能点数UFP 每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简 单级、平均级或复杂级 UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf 其中,ai(1≤i≤5)是特性系数,其值由相应特性的复 杂级别决定,如表13.1
动态多变量模型是根据从4000多个当代软件 项目中收集的生产率数据推导出来的。 工作量是软件规模和开发时间这两个变量的函数。 E=(LOC×B0.333/P)3×(1/t)4 (13.2) E是以人月或人年为单位的工作量; t>1是以月或年为单位的项目持续时间; B是特殊技术因子,它随着规模和要求的增加而缓 慢增加:小的程序(KLOC=5~15),B=0.16, 超过70 KLOC的程序,B=0.39; P是生产率参数 (2000-30000)
COCOMO2采用了更加精细得多的b分级模型,这 个模型使用5个分级因素Wi(1≤i≤5): 划分成从甚低 (Wi=5)到特高 5 (Wi=0)的6个级别 b= 1.01 1.01 Wi (13.4)
b的取值范围为1.01~1.26。 5个分级因素如下所述: (1) 项目先例性: 该项目的新奇程度。 (2) 开发灵活性: 约束多少。 (3) 风险排除度: 重大风险已被消除的比例。 (4) 项目组凝聚力: 开发人员相互协作度。 (5) 过程成熟度: 按照能力成熟度模型(见13.7 节)
13.2 工作量估算
软件估算模型由经验导出的公式来预测软件开 发工作量,工作量是软件规模(KLOC或FP)的函 数,工作量的单位通常是人月(pm)。 估算模型的经验数据,是从有限个项目的样本 集中总结出来的,因此,没有一个估算模型可以适 用于所有类型的软件和开发环境。
13.2.1 静态单变量模型
(2) 输出项数: 软件向用户输出的项数,它们 向用户提供面向应用的信息,例如,报表和出错信 息等。报表内的数据项不单独计数。 (3) 查询数: 查询即是一次联机输入,它导致 软件产生某种即时响应(输出)。 (4) 主文件数: 逻辑主文件(即数据的一个逻 辑组合,它可能是大型数据库的一部分或是一个独 立的文件)的数目。 (5) 外部接口数: 机器可读的全部接口(例如, 磁盘或磁带上的数据文件)的数量,用这些接口把 信息传送给另一个系统。
甲项目的箭线图(ADM)或 双代号网络图(AOA)示例
采用PDM绘制的甲项目的网络图示例
活动历时估计
活动历时估计是根据任务分解中定义的项目活动
和项目活动清单来估计完成这些项目所需要的工期。 工期包括一项活动所消耗的实际工作时间 加上间歇时间。
制定进度计划
甘特图
甘特图,通过日历形式列出项目活动及其相 应的开始和结束日期,它为反映项目进度信 息提供了一种标准形式。
制定进度计划
项目网络图
什么是项目网络图?
项目网络图是项目的所有活动以及它们之间逻辑关系或排 序的图形显示。
项目网络图是活动排序的输出,它有以下作用:
(1)能表示项目活动,并表示活动之间的依赖关系。 (2)表明项目活动将以什么顺序继续。 (3)在进行工期估计时,表明项目将需要多长时间。 (4)当改变某项活动工期时,表明项目工期将如何变化。
13.1.2 功能点技术
依据软件信息域特性和软件复杂性,用功能 点(FP)为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性: 输入项 数(Inp)、输出项数(Out)、查询数(Inq)、主文件数 (Maf)和外部接口数(Inf)。 (1) 输入项数: 用户向软件输入的项数,这些 输入给软件提供面向应用的数据。
项目网络图有两种表示形式:
(1)前导图法(PDM:Precedence Diagramming Method) (2)箭线图法(ADM:Arrow Diagramming Method)
相关文档
最新文档