• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

审计功能点估算(下)—审计功能点估算20步曲

发布: 2008-1-24 13:05 | 作者: 翻译:邹凤 | 来源: 不详 | 查看: 42次 | 进入软件测试论坛讨论

领测软件测试网 The Auditor
  审计师
  The auditor must be a qualified to understand the criteria used and competent to know the types and amount of evidence to accumulate to reach the proper conclusion after the evidence has been examined. The auditor also must have an independent mental attitude. It does little good to have a competent person who is biased performing the audit.
  审计师必须有资质理解将要使用到的标准,有能力知道要收集哪些证据类型、数量大小,以便在审查完这些证据后可以得出正确的结论。同时,审计师必须能保持中立的态度,一个有能力但不能保持立场中立的审计师对整个审计来说帮助不大。
  Independence cannot be absolute by any means, but it must be a goal. For example, even though an auditor may be paid a fee by a company they may still be sufficiently independent to conduct audits that can be relied upon by users. Auditors may not be sufficiently independent if they are also company employees.
  保持中立不能一概而论,但必须是一个目标。比方说,虽然审计师受人酬金,但他仍然能够保持足够的中立去执行让用户认可的审计。然而如果他们也是公司的雇员之一,也可能不能保持足够的中立。
  Types of Reports
  报告的类型
  The final stage of the audit process is the audit report - the communication of findings to the users. Reports differ in nature, but in all cases they must inform readers of the compliance with IFPUG Counting Guidelines. The auditor can have three types of reports.
  审计过程的最后阶段是交付审计报告---即把发现的信息反馈给用户。各类报告虽有本质不同,但都必须告诉用户报告和IFPUG估算指导方针的吻合程度。审计师可以有以下三种类型的报告。
  Like in all audits, the most common report should be the Standard Unqualified Audit Report. It is used in 90 percent of all audits, and a function point audit should be no different. The standard unqualified report is used when the following conditions are met.
  和所有的审计一样,最常用的报告是“标准不合格项审计报告”。它在90%的审计中使用,功能点审计也不例外。标准不合格项报告在以下条件符合的情况下使用:
  1. All systems and users documentation have been included in the original function point count.
  1.最初的功能点估算包含所有系统和用户文档。
  2. IFPUG Counting Practices Guidelines were followed.
  2.遵守了IFPUG估算实践指南
  3. The function point count is thoroughly documented and with no outstanding issues.
  3.功能点估算被详尽记录且没有大的问题。
  Another type of audit report is "conditions requiring a departure." There are two conditions requiring a departure from a Standard Unqualified Audit.
  另一个审计报告是“需拆离情况报告”。以下两种情况需要从标准不合格项审计报告中拆离出来:
  1. The scope of the auditor has been restricted. This is the case when the auditor has not accumulated enough evidence to conclude if the function point was completed in accordance with IFPUG 4.0 Counting Guidelines.
  1.审计师的范围受限。当审计师没有收集足够的证据来判定功能点估算是遵守IFPUG 4.0估算指南完成时使用。
  2. The function point count was not completed in accordance with IFPUG 4.0 Counting Guidelines. In this case, a detail analysis outlining the specific areas should be included in the final report.
  2.功能点估算不遵守IFPUG 4.0估算指南完成。在这种情况下,最终报告中要包含一份详细分析报告,分析哪些关键域不遵守估算指南。

  Additionally, the auditor may create an adverse opinion. An adverse opinion is used only when the auditor believes the overall function point counts are so materially misstated or misleading that they do no present fairly the functional size of the application being counted. The auditor should be very specific on why they are making this conclusion.
  另外,如果审计师确信整个功能点估算中存在材料虚假或者让人容易误解的情况,以致于估算结果无法公正地体现被评估应用的功能范围时,审计师也会提出不利的结论。这种情况下,审计师应该非常明确的知道他们为什么做出这样的结论。
  A 20 Step Procedure for Auditing a Function Point Count
  审计功能点估算20步曲
  1. Was the task of counting function points included in the overall project plan?
  All activities the project team engages in should be an item in the project plan. Ensure that adequate amount of time has been dedicated to achieve to complete the task.
  1.功能点估算任务是否被包含在总体项目计划内?所有项目团队成员参与的活动都应列入项目计划,确保投入了足够的工时来完成估算任务。
  2. Is the person performing the function point count trained in Function Point Counting? Are they certified?
  2.执行功能点估算的人可曾接受功能点估算培训?他们有证书么?
  To often function point counts are completed by individuals not trained in function point counting. Formal class room training may not be necessary, but the individual conducting the count should be familiar with IFPUG 4.0 counting rules.
  很多功能点估算是由没经过功能点估算培训的人完成。正规的课堂培训虽然不一定是必须的,但执行功能点估算的个人应该熟悉IFPUG 4.0估算原则。
  It is even better if the person completing the count has passed the IFPUG Certification exam. Passing he exam does not guarantee accurate counts, but it does guarantee a minimal level of competency.
  所以,最好是完成估算的人是通过IFPUG认证考试的。通过验证考试并不保证估算的准确性,但它一定程度上保证了个人能力。
  3.Were IFPUG 4.0 Counting Practices Manual followed?
  3.是否遵守IFPUG 4.0估算实践手册?
  4.Did the function point counter use current project documentation to count function points? If not How old was the documentation?
  4.功能点估算者使用了当前项目文档去估算功能点?如果不是,文档有多旧?
  5.Did the project team participate in the function point count?
  5.项目组成员是否参与功能点估算
  The project team should be the most knowledgeable individuals regarding the functionality being delivered to the user. They are the best source of information regarding the project. Frequently the project team is left in the dark when a function point count is completed. The function point counter gathers some documentation and sits in a room for a few days and out comes a function point number. This will cause the project team to question the accuracy of the number.
  项目组成员应该是最透彻理解将要交付给用户的系统功能的人,因此,他们是提供项目信息的最好资源。但实际情况是常常一个功能点估算都完成了,项目组成员还被蒙在鼓里。功能点估算者只是收集一些文档,然后在一个房间里坐几天就出来一个功能点数字,这样项目组成员难免会质疑该数字的正确性。
  6.Were internally developed function point counting guidelines followed?
  6.是否遵守内部开发的功能点估算指南?
  7.Was the application counted from the user's point of view?
  7.应用是否从用户的角度进行估算?
  8.Was the system counted from a logical and not a physical point of view?
  8.系统是否从一个逻辑而不是纯粹物理的角度估算?
  9.Does the established boundary for the FP count match the boundary of other metrics (time reporting, defect tracking)? If not, why?
  9.为功能点估算建立的边界是否与其他度量(时间报告,缺陷跟踪)的边界匹配?如果不,为什么?
  10. f the function point count was for an enhancement was boundary the same as the boundary for the application? If not, why?
  10.如果是对一个优化功能的估算,则它的边界和一个应用系统的边界是否一样,如果不是,为什么?
  11. as the boundary changed? If so, why?
  11.边界改变过么,如果改变过,为什么?
  12. Was any tool used for function point counting or was the count done manually?
  if the count was done manual a review of the arithmetic needs to be done.
  12.是否使用工具进行估算,还是手工完成?
  如果是手工完成,则需要复审数学计算的正确性。
  13. Do the individual Function Point components (ILF, EIF, EI, EO, and EQ) percentages conform to industry averages. If not, is there a valid reason?
If auditing several applications, are the percentages of transactions and files similar.
  13.每个单独的功能点元素(ILF,EIF,EI,EO,和EQ)的比率是否符合行业均值,如果不是,是否有合理的理由?如果审计几个应用,事务和文件的比率是否相似?
  14. Has an inventory of transactions (EI, EO and EQ) and files (ILF and EIF) been reviewed by the project team. The greatest error counting function point is the error of omission (not including everything). It is important that the application team review the function point count for completeness and accuracy.
  14.事务(EI,EO和EQ)和文件(ILF和EIF)清单是否被项目组成员评审过。功能点估算最大的错误是疏漏(没有包含所有东西),所以,项目组对功能点估算的完整性和准确性进行复审就非常重要.
  15. Does the total Value Adjustment Factor agree with other projects? The total Value Adjustment Factor should fall within +/- 5 percent of the average value adjustment factor for all applications reviewed. If it falls outside of this range a written explanation needs to be included with the function point count. For example, if the average VAF was 1.05, then the VAF would have to be between 1.0 and 1.10.
  15.总的数值调整参数是否和其他项目一致?总的数值调整参数应落在所有被评审的应用的平均调整参数的正/负5%之间。如果超出这个范围,需要有书面文档说明。举个例子,如果VAF的平均值是1.05,则VAF应该在1.0和 1.10间。
  16. Does each of the 14 General System Characteristics fall within the ranges of other projects? Is each General System Characteristics within 1 point of the average GSC.. For example, if a particular GSC was rated as 2.0 then the GSC would have to be either be 1, 2 or 3. If the GSC was outside this range a written explanation needs to be included with the function point count.
  16. 是否14个通用系统特性中的每一个都落在其他项目的范围内? 是否每个通用系统特性都在平均 GSC的一个点内。比如,如果一个特定的GSC被定级为2.0,则该GSC必须是1,2或3。如果GSC超出这个范围,则需要有一个书面说明。
  17. Have all the assumptions associated with the function point count be documented. All assumptions should be documented so they can be reviewed at later date if necessary.
  17.是否所有和功能点估算有关的假设条件都被文档化了?所有假设条件都应当文档化以便日后需要的时候备查。
  18. Are these assumptions consistent with other projects ?
  18.这些假设条件是否与其他项目一致?
  19. Have all the assumptions impacting Function Point Counting been forwarded to a the central function point group? All assumptions should be reviewed by the central function point group.
  19.是否所有的影响功能点估算的假设条件都被提交给一个中心功能点团队?所有的假设都应被中心功能点团队评审。
  20. Has the count been reviewed by an independent Certified Function Point Specialist?
  20.估算是否被一个独立的功能点认证专家组评审?
  Conclusions
  结论
  In almost every sophisticated industry there are auditors and inspectors function point analysis should not be any different. There is not need to fear audits or auditors. If they are done appropriately they should provide valuable feedback on the function point counting process. The audit report may allow you to correct any incorrect function point counts, and re-evaluate the decisions you have made to date.
  在几乎所有大企业里,都有审计师和监督员,功能点分析员也不例外。我们没必要去惧怕审计或审计师。因为如果他们审计正确,将会给功能点估算过程提供非常有价值的反馈。审计报告允许你去纠正任何不正确的功能点估算,并按最新结果修正原来的结论。
  注释:
  1. IFPUG--The International Function Point Users Group,即国际功能点用户组,该组织在1994年发布了 IFPUG 4.0估算实践手册。
  2. GSC---General System’s Characteristics,即系统通用功能特性。
  3. VAF---Value Adjustment Factors,即参数调整因子。
  (全文完)

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 审计功能


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网