项目开发进度管理方法论——功能点

功能点

功能点作为需求调研的主要成果产物,用于说明项目的所有功能性要求

功能点的整理形式为逐级拆分形式,采用恰当的文档形式,对应项目需求。最高层的结点即为项目名称,对应项目的全部需求。其余结点逐层拆分,每一个结点的所有子节点的内容相加,应等价于该结点

根据以上形式,功能点的形式应为一棵,其叶子节点是任务安排的最小单位。一般来讲,每个叶子节点的开发工作量预期不应超过4人时。同时,应同构任务的拆分,逐步明确技术方案。至叶子节点处,应做到实现方案明确,即通过项目架构下的成熟方案的简单组合,可实现该节点对应的功能。

在文档形式选择上,应利于形成以上的树结构,并且利于修改。在实践中,我们采用xmind软件,用思维导图的形式体现功能点。

功能点估算模型

优先级

  • 未定(?):是否实现该功能点,由于某些原因尚未确定。
  • 核心级(零级):该产品之所以为该产品的核心特性对应的功能点。例如学生管理系统中的添加学生功能。
  • 重要级(一级):保证该产品能够成功运行的功能点,换言之,该功能点没有完成时,该产品整体处于不能使用状态。例如Web项目中的大部分框架功能(如用户登录),学生管理系统中的学生列表显示。
    以上两级,都属于产品发布时必须实现的功能。区别在于,核心级的需要更多考虑优化问题。
  • 亮点级(二级):完成后,可以使产品增加亮点,从而增加客户的满意程度。
  • 期望级(三级):用户期望拥有的功能。
    以上两级应争取实现。如果项目发布周期紧而放弃,应评价该项目完成情况较差。
  • 非重要级(四级):实现后有好处,但不实现,也不存在太大的坏处。
    项目周期紧时,优先放弃此级。
  • 反向级(九级):功能点的实现目标,与其它功能点(特别是前四级的功能点)有冲突。开发此类功能点的任务,必须在通盘考虑所有功能点,并且有对冲突有明确结论的情况下才能开展。

复杂度

  • 0:未定义,还未能做到有明确用例。此级的功能点倾向于暂不实现,必须先确定用例后划定复杂度,再进行实现。
  • 1:简单级,包含2个以下正常用例和3个以下异常用例。或用常识即可取得一致理解。
  • 2:复杂级,包含3~5个正常用例或4~8个异常用例。
  • 3~5:根据用例数类推。一般不超过5级。
  • 9:待定级,没有明确用例。此类功能点归入9级而不是0级的原因是,由于某些原因,无法明确用例,因此需要特殊的方案处理,例如先随意实现一版做思维引导。此级别的功能点的开发方案,需要特殊处理。

技术风险

  • 0:无任何技术风险,由1个项目架构中的成熟方案即可实现,或者由不超过3个项目架构中的成熟方案组合实现,且组合方式也有明确方案或丰富经验。项目组任何一个人对其进行独立实现时,选择的技术方案不会与项目技术负责人的想法有差别,且最终完成时间与项目负责人的预估不会有明显偏差。
  • 1:一般,由项目架构中的成熟方案即可实现,接近于无风险。
  • 2:有风险:由项目架构中的成熟方案+高度内聚的特定技术方案可实现,例如某流程中包含微信支付功能。定义为此级别的功能点,需明确指出其技术风险点,如“微信支付”。实现此级别功能点时,需要有特定技术方案的详细参考资料和解决方案。
  • 3:有较大风险:对现有架构方案中的通用性约定作调整,如之前的架构方案是简单页面,而新功能点中需要大量使用iframe。
  • 3:有较大风险:需对现有架构方案中的内容做结构性调整,如之前的架构方案是直连数据库,某功能点则要求提供缓存。
  • 9:极大风险:与现有架构方案完全不兼容,如之前的架构方案是Java Web,但此功能点要求开发iOs app。

 

 

项目开发进度管理方法论——功能点》上有1条评论

  1. Pingback引用通告: 从一事无成到仅成一事

发表评论

电子邮件地址不会被公开。 必填项已用*标注