北京中科忽悠 http://m.39.net/pf/a_5131648.html为什么会有这篇文章
5月26日到5月28日期间我参加了由北京软件造价评估技术创新联盟（以下简称为创新联盟）组织的软件工程造价师培训，本文根据培训课上学到的内容所整理，难免会有理解上的偏差、知识点上的疏漏，所有关于快速功能点内容如与创新联盟发布存在冲突，请以创新联盟发布或解释为准。我目前就职于一家城商行，从事科技部项目管理的工作。在工作中，难免会和厂商打交道，也就是俗称的乙方，不可避免的会涉及到软件工作量的评估、对乙方的评价等等。但这不是最让人头疼的，最头疼的反而是来自于组织内部：科技部门评估的工作量会面临业务、审计等部门的质疑，一是因为没有标准支撑，二是考虑项目经理有没有和乙方配合提高软件成本的可能，即使科技部内部经过了DELPHI这类专家评估的方法，即使经过了内部层层审批把关，即使形成了内部制度，仍然不足以打消其他部门的疑虑。带着这些问题，我参加了5月26日到5月28日的软件工程造价师培训，目的还是想通过这个培训了解快速功能点方法是否能够解决我的问题。
培训梳理
根据培训，我整理了一些关键的知识点，具体如下图所示：
软件工程造价师培训
标准
工信部行业标准SJ/T-《软件研发成本度量规范》
中国国家标准GB/T-《软件工程软件开发成本度量规范》
估算内容
规模
成本
工期
估算方法（需了解各自特点）
估
经验法
类推法
算
类比法
方程法
估算要点
方法选择：引入以算为主的方法
估算结果宜为一范围而非固定值（规模是固定值，工作量、成本、工期是范围）
交叉验证（经验法通常用来做交叉验证）
交叉验证结果相差较大时，根据实际需要确认是否偏差在可接受范围内，如超出可接受范围，则应通过沟通、假设条件检查等方法修正结果。
培训内容
培训重点在方程法，方程法重点在规模估算，规模估算主要使用快速功能点方法
行业级模型：SDC=(S*PDR)*SWF*RDF/*F+DNC
SDC：软件研发成本，单位为万元
S：规模，单位为功能点数
PDR：生产率/功能点耗时率，单位为人时每功能点
SWF：软件因素调整因子
RDF：开发因素调整因子
：8*21.75，根据人社部发布的数据，每天8小时，每月21.75个工作日
F：人力成本费率，单位为万元每人月
DNC：直接非人力成本，单位为万元
估算过程：软件规模度量-工作量估算-成本估算，得出软件开发成本
软件规模度量
方法
业务视角：功能点、对象点、用例点、故事点。。。
开发视角：代码行（要理解优缺点）、数据库表、函数数量。。。
功能点
1、预估功能点（项目早期）
2、估算功能点（项目中期，采用中等复杂度，国际采用简单复杂度）
3、详细/标准功能点（项目中后期，根据管理需要确定是否采用）
只估算ILF/EIF，规模=ILF*35+EIF*15
规模=ILF*10+EIF*7+EI*4+EO*5+EQ*4
了解
14个因子，了解。调整范围在0.65~1.35之间
理解DET（数据元素类型）、RET（记录元素类型，DET子集）、FTR（文件引用类型）等概念
数据元素全集是自己的子集，因此RET至少为1
根据DET、RET以及FTR的数量查表确定复杂度
数据功能（数出ILF、EIF）
事务功能（数出EI、EO、EQ，都有数据穿越系统边界）
找到潜在的逻辑文件（剔除编码数据，要理解业务数据、引用数据以及编码数据）
是否有逻辑差异或依赖关系（要理解逻辑差异、依赖关系，尤其是依赖关系[删除其中一个，另外一个是否有独立存在的业务价值，有则为两个文件，无则为一个文件]）
数据文件分类（本系统维护为ILF，本系统引用、外系统维护则为EIF）
去重
主要目的是对内部逻辑文件进行维护，或改变系统行为，则为EI
主要目的是向系统边界边界之外发送/呈现数据，如发生了以下四种中的一种则认为是EO：计算、产生衍生数据、维护逻辑文件、改变系统行为
主要目的是向系统边界边界之外发送/呈现数据，仅是对数据的简单输出（不能计算、不能产生衍生数据、不可维护ILF或改变系统行为，可以排序、筛选、等值代换等）则认为是EQ
找基本过程（用户可以明确感知其业务意义的一次原子操作，中间判断过程不是基本过程。一次基本过程结束后，数据是完整/稳定的）
分类（一看目的、二看行为）
去重（三原则：逻辑文件/用户可见数据元素/处理逻辑，三个都相同才是一个过程）
用户：实际用户以及本系统的上下游系统
穿越系统边界，可理解为数据从用户和本系统之间存在数据交互
新开发（识别所有新增功能）
增强（识别变化功能）
已有系统计数（识别最终交付功能）
3.1、确定技术类型
3.2、识别系统边界
3.3、识别功能点计数项
3.4、调整计数项复杂度
3.5、确定GSC因子
3.6、计算调整后功能点
IFPUG（标准功能点）
NESMA（快速功能点）
MarkII-FPA
COSMIC-FFP
FISMA-FFP
功能点是度量软件规模的一种单位
从用户视角，和敏捷思想有一定的相似度，考虑业务价值
核心思想是系统维护的信息（数据功能）及处理的复杂程度（事务功能）决定系统价值
国际标准的功能点分析方法
了解适用/不适用领域
估算过程（目前主要使用预估功能点和估算功能点）
工作量估算
类推法
强调高度相似的历史项目数据
类比法
具备基准数据库
样本不足时，可按不同属性条件查找样本
方程法
AE：调整后工作量，认为为人时
S：规模，单位为功能点数
PDR：生产率/功能点耗时率，单位为人时每功能点
SWF：软件因素调整因子（规模、业务类型、应用类型、质量要求等）
RDF：开发因素调整因子（开发语言、团队经验、过程能力、资源约束、重用等）
行业级模型：AE=(S*PDR)*SWF*RDF
成本工期估算
成本（直接人力成本、直接非人力成本[不同项目不同，因此不计入人力单价]、间接人力成本、间接非人力成本），要理解各种情况归属于哪一类成本
工期（有模型，不过估计用处不大）
以上为本次培训整理的部分知识点，很多用词应该是直接翻译的国际标准，国内看起来会觉得比较怪，另外最重要的一点是对需求的澄清，对需求理解有问题，会导致数出来的功能点数差距很大。另外，快速功能点和实际工作中评估出来的差距有多大，这个还需要时间来检验，毕竟最难的还是数据积累。
预览时标签不可点收录于话题#个上一篇下一篇
