一年代码功能点的创新性怎么写_软件功能点技术与应用创新.ppt

* * 基于功能点的经验公式 8 项目平均人员规模 功能点/150 2014.02 * 基于功能点的经验公式 9 软件维护人员数目 功能点数/750 2014.02 * 基于功能点的经验公式 10 软件工作量 规则7与规则8 假设有1000功能点 工期 (FP^0.4) = 16 个月 人员 (FP/150) = 6.6人 工作量(16 * 6.6) = 106 人月 2014.02 * 功能点应用场景 1 项目前期的可行性分析 关注技术可行性之外的内容 采用快速功能点方法判断项目所需完成的工期和初步预算，从而决定组织是否能够支撑或接受该项目 示例：某组织希望启动一个网上书城的应用项目，涉及的业务实体大概为30个左右，可以快速得到项目的功能点数为1200(30*10*4)个。所以对应的工作量为40到80人月，需要的预算为120万到240万左右，对应的开发时间为8到17个月 2014.02 * 功能点应用场景 2 甲方确立项目范围与标的 甲方在招标的过程中首先需要在内部立项、申请预算 功能点方法有助于给出明确的预算申请依据，使得预算过程更加透明 示例：1000个功能点的项目，甲方内部申请的预算为1000*2K=2000K，其中1000FP是根据功能点标准得到，而每个功能点的费用为2K则可以依据行业数据得到(假定一个功能点的开发成本为1.5K左右，考虑到乙方的利润为20%，以及甲方10%左右的管理成本) 2014.02 * 功能点应用场景 3 为乙方确立项目的范围与标的 甲方要求乙方在投标过程中采用功能点报价或评估工期，便于甲方从第三方的角度审查核实乙方的报价是否过高或偏低 2014.02 * 功能点应用场景 4 甲乙双方合同谈判的依据 与传统的基于模块的报价方法相比较，基于功能点的谈判过程对双方更为透明。 甲方不必再单独依赖于所谓的“最低价中标”或“中间价中标”等评判方式 甲方可以依据乙方所提供的软件功能点数量进行验收并支付合同款项 如何确保质量标准？ 2014.02 * 功能点应用场景 5 乙方项目立项的依据 基于功能点方法，乙方内部的人员配备、费用安排以及工期设定等都可以更透明 乙方比较不同项目的预算 可以更好地将市场因素与技术因素区分开来，从而给定相对客观的立项依据 示例：项目的项目，它们的合同价分别是50万、100万、150万，那么乙方内部立项的预算是否会有所不同？ 2014.02 * 功能点应用场景 6 项目计划与跟踪的基础 对于增量型项目，采用功能点可以直接衡量项目的产出，甚至可以作为依据向客户收取与功能点数量对应的费用 对于瀑布型项目则可以考虑引入转换机制，使得每阶段产出都可用功能点衡量 问题：如何减小双向转换所带来的误差？ 2014.02 * 功能点应用场景 7 评审质量目标的确定 每次评审会议的出口约束条件如何设定？基于过程约束的相对标准往往效果有限 例如，评审会议要关闭所有已经发现的问题？那些没有发现的问题如何处理？ 例如需求评审的质量目标为0.1-0.3缺陷/FP，则规模为1000FP的需求应该在需求评审之后发现100到300个缺陷，否则应该进行原因分析 2014.02 * 功能点应用场景 8 测试阶段的质量目标设定 软件测试除了关注测试用例是否充分外，还要考虑所发现的问题是否已经足够 测试用例的充分性可以功能点去衡量，测试发现的问题也用功能点去衡量，再结合缺陷趋势分析、缺陷正交分析，最后可以判断测试后质量状况 2014.02 * 功能点应用场景 9 基于功能点的验收方式 与需求的功能点一一对应进行验收 考虑完整的需求变更流程，否则无法使用功能点严格对应方法 基于功能点评价质量标准 基于功能点预估应用系统的运营质量 2014.02 * 功能点应用场景 10 项目需求变更的测量 软件项目往往都面临需求变更的可能，采用功能点方法有助于将变更的程度和粒度描述清楚 开发过程中新增加了2个需求,修改了1个需求，则有可能是50功能点，也有可能是80个或者100个功能点，所以使用功能点方法可以统一对需求变更程度的衡量。 从过程度量的角度，需求稳定度指标才更有意义 2014.02 * 功能点应用场景 11 软件需求详细程度的约束条件 甲乙双方往往无法界定需求描述的详细程度，从而为后续需求变更“埋下伏笔”。 使用功能点的方法可以有效地指导需求描述的详细程度，将需求评审的标准由相对标准转变为绝对标准 最大程度避免因为前期需求描述不清晰而导致需求频繁变更 2014.02 * 功能点应用场景 12 大项目与组合项目管理 大项目与组合项目管理要解决的关键问题之一就是在不同的项目间进行比较 而采用功能点方法可以对不同的项目进行归一化处理，从而比较单位生产率、单位成本或者单位质量状况 2014.02 * 功能点