软件项目规模估算.PPT

* 在组织中推行功能点分析法—FPA的优点 基于定义良好的计算标准 基于客户视角。容易理解和接受 可应用于新项目，升级项目和维护项目 与技术和计算机语言无关 简单，易于计算，只需花费较少的工作量 一致的规模度量尺度。可用来比较不同组织和技术之间的比较 * 在组织中推行功能点分析法—FPA的缺点 只考虑可见部分的复杂度，对系统内部的复杂性考虑太少 功能复杂度的三级划分比较武断，对一些非常复杂的功能，统计误差较大 FPA简单假设全部是部分的和，没有考虑系统集成带来的额外开销 FPA在不断进化，MARK II 功能点分析法能克服一些缺点。 * 在组织中推行功能点分析法—推行FPA的建议 得到老板的支持和指导。 使度量成为每一个人工作的一部分。 安排专人总管和支持度量活动，不一定是全职。 培训技术人员和用户。让用户有功能点的概念。 关注在项目团队的收益上，不要一上来就资产管理什么的。 提供自动化的支持。 与组织的过程模式整合。 度量的结果应当发布出来，并得到利用。 * 在组织中推行功能点分析法—不应该做的 不要觉得度量可有可无，或不可达到。 不要苛求完美的度量系统和环境。 不要依赖不准确的数据。 不要用于衡量个人的绩效。 * 在组织中推行功能点分析法—度量功能点的工作量 　 项目/应用系统的规模 很小 小 中 大 很大 功能点数 5 ~ 20 20 ~ 100 100 ~ 500 500 ~ 10K 10K ~ 100K C++代码行 265 ~ 1K 1K ~ 5K 5K ~ 26K 26K ~ 500K 500K ~ 5M 开发工作量 0.5人天 ~ 1人月 1人月 ~ 10人月 10人月 ~ 72人月 72人月 ~ 200人年 200人年~ 8K人年 FPA工作量 15分钟 ~ 30分钟 30分钟 ~ 1小时 1小时 ~ 5小时 5小时 ~ 100小时 100小时 ~ 1K小时 很多公司不能推行FPA ,并非主观上认为它没用。其主要原因有二： 没有FPA的专家指导，不知从何做起，如何持续。 迫于项目进度压力，担心FPA带来大量额外的工作量。 大多数组织平均1小时估算出100个功能点，FPA带来的额外工作量参考： * 问题讨论？ * 完， ！ * * 主要内容 零、项目估算概述 一、软件项目规模估算 二、功能点分析法概述 三、功能点分析法流程 四、在组织中推行功能点分析法 * 功能点分析法流程—概述 确定FPA类型 定义分析范围和边界 计算未调整功能点数 以文件为单位，列出所有数据功能 根据文件的DET、RET确定其功能点数 以处理元为单位，列出所有处理功能 根据处理元的DET、FTR确定其功能点数 计算调整后功能点数 评估14项GSC的DI值 计算功能点调整因子 计算调整后功能点 * 功能点分析法流程—1确定FPA类型 不同类型的项目FPA的度量目的不同，计算公式也不同 新开发项目Development Project的度量目的： 度量新增及系统切换的功能点 定义需求 为项目计划提供估算数据 度量软件质量 度量生产率 升级项目Enhancement Project的度量目的： 度量新增、改变、删除及系统切换的功能点 应用软件Application：已经交付或从第三方获得的软件、软件包的度量目的： 作为升级项目的基线 度量软件质量 确定维护策略 确定维护生产率 返回流程图 * 功能点分析法流程—2定义分析范围和边界 相关应用之间的边界是由用户看到的不同功能区域划分，而不是由技术考虑来划分。 应用之间的初始边界不会因为功能点分析而改变。 定义边界的技巧 获得一个系统的流程图，在系统周围画上边框，作为边界。 察看数据的维护方式。 确定维护策略。 察看数据的应用范围。 返回流程图 * 功能点分析法流程—3计算未调整的功能点 第一步：分解功能 数据功能 内部逻辑文件ILF (Internal Logic File) 外部接口文件EIF (External Interface File) 处理功能 外部输入EI (External Input) 外部输出EO (External Output) 外部查询EQ (External Query) 第二步：分析功能复杂度 复杂度分为：高、中、低 数据功能复杂度分析：根据DET和RET确定复杂度 RET （记录元素类型） ：一个文件中用户可以识别的数据元素组 DET （数据元素类型）：用户可以识别的，不重复的字段 处理功能复杂度分析：根据DET和FTR，确定复杂度 FTR（引用文件类型）：处理涉及的文件，包括读取、新建、修改的文件。 第三步：根据复杂度确定未调整功能点数 根据复杂度和功能点的矩阵表，计算得到未调整的功能点 返回流程图 * 功能点分析法