赞
踩
可以直接进入的github上面下载试卷,课后答案,以及对应的笔记总结,点击进入
为了创造一个唯一的产品或者提供一个唯一的服务而进行的临时性的努力,所以说项目具有临时性特性
项目 | 日常运作 |
---|---|
以目标为导项 | 通过效率和有效性的体现 |
通过项目经理及其团队工作完成的 | 职能式的线性管理 |
项目是一次性的 | 日常运作可以重复进行 |
共同点:
都需要人来做;而且都受资源限制;都需要规划,执行,控制
(1)启动过程组:主要是确定一个项目或一个阶段可以开始了,并要求着手实行;定义
和授权项目或者项目的某个阶段。 (2)计划过程组: 为完成项目所要达到的商业要求而进行
的实际可行的工作计划的设计、 维护, 确保实现项目的既定商业目标。 计划基准是后面跟踪
和监控的基础。 (3)执行过程组:根据前面制定的基准计划,协调人力和其他资源,去执行
项目管理计划或相关子计划。 (4)控制过程组: 通过监控和检测过程确保项目达到目标, 必
要时采取一些修正措施。 集成变更控制是一个重要的过程。 (5)收尾过程组: 取得项目或阶
段的正式认可并且有序地结束该项目或阶段。 向客户提交相关产品, 发布相关结束报告, 并
且更新组织过程资产并释放资源。
关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。
其中,计划过程组、执行过程组、控制过程组是核心管理过程组。
目标性、相关性、临时性、独特性、资源约束性、不确定性
(招标书定义) 、(供方选择)、(合同签署)
(项目分析) 、(竞标)、(合同签署)
总而言之:甲方:客户(上帝),乙方:软件开发方
自制方案:
制造费 30000 元 维护费 3500 元/月
购买方案:
购买费 18000 元 维护费 4200 元/月
制造差额: 30000-18000=12000 元
服务差额: 4200-3500=700 元
自制方案承受月份: 12000/700=17.14
如果产品在 17 个月以内可以选择购买方案,如果超过 17 个月选择自造方案。
项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件, 包括对项
目的确认、对项目经理的授权和项目目标的概述等。
招标书主要包括三部分内容:技术说明、 商务说明和投标说明。技术说明主要对采购的
产品或者委托的项目进行详细的描述, 商务说明主要包括合同条款。 投标说明主要是对项目
背景、标书的提交格式、内容、提交时间等做出规定。
模型 | 特点 | 缺点 | 使用范围 |
---|---|---|---|
瀑布模型 | 线性,阶段计划分明,以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导 | 缺乏灵活性,无法解决需求不明确或者不准确的情况;(2)由于开发是线性的,只有到末期才能见到开发成果,增加了开发的风险;(3)早期的错误到后期才能发现 | 适用于需求明确,解决方案明确的项目 |
V模型 | 纠正了人民不重视测试阶段的重要性的错误认识,将测试分等级,并且和前面的开发阶段对应 | 仍然将测试作为一个独立的阶段,并没有提高抗风险能力 | 与瀑布模型类似 |
快速原型模型 | 有助于增进软件人员和用户对系统服务需求的理解 | 文档容易被忽略,建立原型的许多工作会被浪费掉,项目难以规划和管理 | 适用于需求不明确,动态变化的项目 |
增量模型 | 增强了客户使用的信心,逐步提出对后续增量的需求;增量由高到低的优先级确定保障了系统重要功能部分的可靠性;项目总体失败的风险比较低 | 增量粒度选择问题,确定所有的基本服务比较苦难 | 适用于需求大部分明确,系统较为复杂,有一定的技术风险 |
渐进式模型:
个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;相应变化胜过遵循计划
适用于需求不明确的情况下采用
(1)瀑布模型
适用于软件需求很明确的软件项目, 即一般适用于功能明确、 完成、 无重大变化的软件系统
的开发,即:
1) 在项目开始前,项目的需求已经被很好的理解、也很明确,而且项目经理很熟悉为实现
这一模型所需要的过程。
2) 解决方案在项目开始前也很明确。
3) 短期项目可采用瀑布模型。
(2)V 模型
适用于项目需求在项目开始前很明确、解决方案在项目开始前也很明确,项目对系统的
安全很严格,如航天飞机控制系统、公司的财务系统等。
(3)快速原型模型
适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候。
甘特图(甘特图用于做计划的视图)
属于需求的视图的是:用例图,状态图,顺序图
(1)让用户参与开发
(2)开发用户界面原型
(3)需求讨论会议
(4)强化需求分析和评审
帮助组织工作,防止遗漏工作,为项目估算提供依据 但是不包括确定团队成员责任
自顶向下 ,自底向上 ,模板参照,不包括控制方法
(自底向上)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组织起来,形成更高级别的 WBS层。
(自顶向下)方法从一般到特殊的方向进行,从项目的大局着手,然后逐步分解子细目,将项目变为更细、更完善的部分
(1)WBS是任务分解的结果;(2)不包括再 WBS中的任务就不是该项目的工作;(3)可以采用清单或者图表的形式标识WBS的结果
任务分解的基本步骤:
任务分解方法:
将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理、 更易操作,这样可以提高估算成本、时间和资源的准确性,使工作变得更易操作,责任分工更加明确。
检验任务分解结果的标准有:
- 最底层的要素是否是实现目标的充分必要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人
- 是否可以进行成本估算和进度安排
代码行,功能点,类比法;记住不包括关键路径法
UFC:未调整功能点计数
包括:外部输出,外部文件,内部文件
1)代码行,功能点;2)参数估算法;3)专家估算法;记住不包括函数估算法
专家一: Ei=(ai+4mi+bi)/6= (2+47+12)/6=7
专家二: Ei=(ai+4mi+bi)/6=(4+46+8)/6=6
专家三: Ei=(ai+4mi+bi)/6= (2+4*6+10 )/6=6
Ei=(7+6+6)/3=6.33 (万元)
Effort=a* (KLOC)b F
查表 a=3,b=1.12,F=1
Effort=3.050
1.12 1.31=311.82 (人月)
所以项目的费用为 2* Effort=623.64 万元
C 语言代码行与功能点的关系近似为 150LOC/FP,所以, 85 个功能点代码行数为
L=85150=12750 行=12.75KLOC,则:工作量估算 E=(5.2L)的0.91次方 =(5.212.75)的0.91次方≈52.725(人月)
项目时间 D=(4.1L)的0.36次方 =(4.112.75)的 0.36次方 ≈10.25(月)
人员需求量 S=(0.54E)的 0.6次方 =0.5452.725的0.6次方 ≈5.829(人)
文档数量 DOC=49L 的1.01次方 =49*12.75的1.01次方≈640.857(页)
E=(6+24+4*12)/6=13 , δ=(24-6)/6=3
E-δ =10
E+δ=16
查表(p139)得任务历时估算介于 10—— 16 天的概率为: 68.3%
上图对应的 ADM 图如下所示:
标准差:δ=(P-O)/6;
质量计划中可以采用以下几种方法:
(1)试验设计:试验设计是一种统计学方法,确定哪些因素可能会对特定变量产生影响。
(2)基准对照:是一种寻找最佳实践的方法,是利用其他项目的实施情况作为当前项目性能衡量的标准。
(3)质量成本分析:质量计划必须进行质量成本的综合分析,以便决定质量活动。
(4)流程图方法:可以显示系统的各种成分是相互的关系,帮助我们预测在何处可能发生何种质量问题。
(5)因果分析图:也称鱼刺图。描述相关的各种原因和子原因如何产生潜在问题或影响,将影响质量问题的 “人员、 设备、参考资料、 方法、环境”等各方面的原因进行细致的分解,方便地在质量计划中制定相应的预防措施。
质量保证的主要活动是项目执行过程审计和项目产品审计。
质量保证的要点是:对项目进行评价、推测能否达到质量指标、建立对项目的信心
质量保证( QA)是通过评价项目整体绩效 ,建立对质量要求的信任,提供项目和产品可
视化的管理报告。 这个任务本身并不能提高产品的质量, 但是通过质量保证的一系列工作可
以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。
质量控制( QC)是确定项目结果与质量标准是否相符 ,同时 ,确定消除不符的原因和方法,它
控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。
质量保证是后期质量活动,质量控制是前期质量活动。它们是有区别的 :质质量保证是针对
项目实施过程的管理手段,质量控制是针对项目产品的技术手段 ;实施质量保证是针对过程
改进和审计的, 强调的是过程改进和信心保证。 实施质量控制是按照质量要求, 检查具体可
交付成果的质量,强调的是具体的可交付成果。
可以变化,但是必须通过基线变更控制流程处理
(1)配置项标识、跟踪; ( 2)配置管理环境建立; (3)基线变更管理; (4)配置管理审
计;(5)配置状态统计; ( 6)配置管理计划。
评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项
目管理层沟通。
软件配置管理是软件项目管理的重要内容,也是保证软件质量的重要手段。它能
够对软件开发过程进行有效管理和控制, 从而实现软件产品的完整性、 一致性、可控性,使
产品极大程度地与用户需求相吻合。 它能够控制、 记录、追踪对软件的修改并形成规范文档,
方便日后维护和升级,更重要的是能够保护代码资源,积累软件财富,提高软件重用率。
配置管理工具有: Harvest、 Perforce、ClearCase、PVCS、CVS\SVN、 VSS
软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清
单、厕所规格说明书、 测试计划、 测试用例与实验结果、 可执行程序、 用户手册、 维护文档。
公式:N(N-1)/2 其中N:表示人员总数
沟通方式主要有书面沟通和口头沟通、 语言沟通和非语言沟通、 正式沟通和非正式沟通、
单向沟通和双向沟通、网络沟通等
优点是: 1、专职的项目经理负责整个项目,以项目为中心,能迅速解决问题。在最短的时间内调配人才,组成一个团队,把不同职能的人才集中在一起。
2、多个项目可以共享各个职能部门的资源。在矩阵管理中,人力资源得到了更有效的利用,减少了人员冗余。
3、既有利于项目目标的实现,也有利于公司目标方针的贯彻
4、项目成员的顾虑减少了,因为项目完成后,他们任然可以回到原来的职能部门,不用担心被解散,而且他们能有更多机会接触自己企业的不同部门。
缺点是 1、容易引起职能经理和项目经理权利的冲突。
2、资源共享可能引起项目之间的冲突
3、项目成员有多位领导,即员工必须要接受双重领导,因此经常有焦虑与压力
EMV:损益期望值
公式:EMV=(outcome(回报)*成功概率-亏本 * 亏本概率)
EMV=(50000 * 30%-10000 * 70%) =8000
20+10% * 20=22万
20+1.5=21.5万
项目总价=成本+奖金(节约成本 * 20%)+利润=16+(节约成本=20-16=4)4 * 20%+4=20.8万
8+20%*8=9.6
11+1+(12-11)20%=12.2
1)建立计划标准; 2)观察项目的性能; 3)测量和分析结果; 4)采取必要措施; 5)做好计划修订工作,控制反馈。
CPI(成本效能指标)=BCWP(已经完成工作的成本预算)/ACWP(到目前为止花了多少钱) * 100%
* CPI>1:低于预算 ;=1:按照计划进行;<1:超过预算
SV(进度差异)=BCWP(到目前为止实现了多少价值)-BCWS(到目前为止应该完成多少)
所以SV=850-1000=-150
CV(费用差异)=BCWP(到目前为止实现了多少价值)-ACWP(到目前为止花了多少钱)
所以CV=900-850=50
BCWS=10+15+5+10+10+10+20+10+10+5+5=100;
ACWP=10+16+8+10+10+12+24+12+5+5=112
BCWP=10+15+5+(10+10+10+20+10+10)/2+(5+5+25+5)/2=95
CV=BCWP-ACWP= -17
SV=BCWP-BCWS= -5
CPI=BCWP/ACWP=84%
EAC=BAC/CPI=170/84% = 202
BAC=5+25+120+40+60+80=330
BCWP=5+25+40=70
BCWS=10+20=30
ACWP=10+20+50=80
SV=BCWP-BCWS=40
SPI=BCWP/BCWS=175%
CV=BCWP-ACWP=-10
CPI=BCWP/ACWP=87.5%
80%的问题是由 20%的原因引起。
项目经理、架构分析师、系统分析师、 DBA、程序开发人员、测试人员、系统工程师、
质量管理人员
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。