IT项目成本管理(1).pptVIP

成本管理的理论 内容上涵盖更广泛： 涉及到决策中的资源计划编制； 涉及到成本估算和成本预算； 涉及市场营销活动和售后服务； 方法工具进展迅速： 引进投资的资金时间效益概念， 引进成本动态控制的挣值概念， 引进最优化计算机软件模型 成本管理的理论 全方位成本管理的理论方法 横向伸延，把成本管理的范围扩大到资源最优化配置，价值分析，风险分析等领域，以系统观点，注重各领域之间的效益关系； 生命周期成本管理的理论方法 纵向伸延，把成本管理链条向前扩大到决策投标阶段，向后伸延到项目使用维护阶段，使项目成本在整个项目生命达到最小化； 分类： 每位专家根据软件系统规格说明书进行估算 协调员整理专家估算，给出平均期望值 在此基础上各位专家进行再次估算 以上过程可重复多次，直到专家评估值之差达到要求 方法的使用说明 影响估算结果的因素 失败因素： 无根据的估算完全不可信 估算依赖的是经验而不是猜测 人们容易低估小项目的工作量，而过分夸大大项目的工作量 成功因素： 留出估算的时间，并做好计划 估算本身也是一个项目 开发人员参与估算，并使用几种不同的估算技术，并比较它们的结果 影响估算结果的因素（续） 失败因素： 多些时间做估算，并不能得到更准确的结果 单点估计的结果往往不正确 成功因素： 估算的群体讨论，依靠更多的意见而不是时间提高估算准确度 理智的方法是先给出大的区间，在软件开发过程本身中逐步缩小区间 案例：过分乐观的估算 Microsoft Word for Windows 1.0开发。包含249，000行代码，投入660人月，前后历时5年，实际花费时间为预期时间的5倍 案例介绍 案例分析（续） 导致WinWord1.0开发延迟的几个主要因素： 项目初期制定的开发目标是不可实现的。 盖茨下达的指示是用最快的速度开发最好的字处理软件，争取在12月内完成。实现这两个目标中的任何一个都是困难的，同时达到则是不可能的。 过紧的进度计划降低了计划的精确度。 开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因而离职。 案例分析（续） 迫于进度压力，开发人员匆忙写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。 由于该项目中，创新比速度更重要，因而试图缩短开发周期，反而使周期变长 案例总结 高层的决定不总是睿智的 启示：估算应该征求所有项目相关人员的意见 案例总结（续） 过大的压力带来意想不到的结果 案例总结（续） Brook法则：当人数增加后，项目所需的工作量 将不成比例的增加。 软件项目估算的基础 历史数据 在参考历史数据时需要考虑不同的环境。如编程语言，软件工具，复杂程度，标准和人员的经验。 软件项目估算的基础（续） 工作度量 直接计算真正的成本或时间是不可能的。编写相同的程序，不同的人将有显著的区别。 通常将工作量表达为如源代码的数量（SLOC），或者千行代码量（KLOC）；或表达为功能点数（FP） 复杂性 相同KLOC的两个程序花费的时间将会不同，要根据复杂性进行修正，但是复杂性的度量通常是主观的 功能点计算实例 FP=UFC*TCF UFC=301 TCF=0.65+0.01(14*3)=1.07 FP=301*1.07=322 功能点可按照一定的条件转换为软件代码（LOC）。 LOC=AVC×功能点的数量 AVC：指该语言在实现一个功能点时所要用的平均代码行。 业界标准：开发软件产品的生产率不低于0.86千行等价汇编语言代码0.86KLOC/人月 功能点计算实例 FP=322 则该项目若用C语言编写，查阅前表得C的功能点置换为128行，则代码量为： LOC=322*128=41216 若用C++语言编写，查阅前表得C++的功能点置换为53行，则代码量为： LOC=322*53=17066 IBM模型 (1)1977年IBM的Walston和Felix提出如下的估算公式： IBM模型（续） 该模型是静态单变量模型 在此模型中，一般指一条机器指令为一行源代码 源代码行数一般不包括程序注释、作业命令、调试程序在内 对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑 定义: 转换系数＝机器指令条数／非机器语言执行步数。如：Fortran的转换系数为4~6 软件项目估算的时机 时机选择的标准 项目早期，估算精度低、意义大 项目后期，估算精度高、意义小 项目结束，估算精度100%，无意义 估算本身需要成本，过多估算导致项目成本上升 多次估算可以提高精度 项目分为多个阶段，阶段性估算可以指导后续工作 …… 软件估量的三个要素 项目