Here's an article talking about Use Case Points - via Normalized Use Case. I think the one factor overlooked in your approach is the productivity which is suppose to be based on past projects. 20 seems to be the average HOWEVER if you are VERY productive (there's a known 10 to 1 ratio of moderate to good programmers) the productivity could be 5 bringing the UCP est. close to what you think it should be. I would suggest looking at past projects, calculating the UCP, getting the total hours and determining what your productivity really is. Productivity being a key factor needs to be calculated for individuals and teams to be able to be used in the estimation effectively.
Ironically, the prototypical two box logon form is much more complicated than a 2 box CRUD form because the logon form needs to be secure and the CRUD form only needs to save to a database table (and read and update and delete).
A logon form needs to decide if where to redirect to, how to cryptographically secure an authentication token, if and how to cache roles, how to or if to deal with dictionary attacks.
I don't know what this converts to in UCP points, I just know that the logon screen in my app has consumed much more time a form with a similar number of buttons and boxes.
Last time I was encouraged to count function points, it was a farce because no one had the time to set up a "function points court" to get rulings on hard to measure things, especially ones that didn't fall neatly into the model that function point counting assumes.
Part of the issue may be how you're counting transactions. According to the author of UCP, transactions are a "round trip" from the user to the system back to the user; a transaction is finished when the system awaits a new input stimulus. In this case, unless the system is responding...a logon is probably just 1 transaction unless there are several round trips to and from the system.
second it is clear that this kind of estimation like, also Function Points, is more accurate when there are a lot of use-case and not one. You are not considering for example, startup of the project, project management, creation of environments etc. that are all packed in the 20 hours.
发布评论
评论（5）
这是一篇讨论用例点的文章 - 通过标准化用例。 我认为您的方法中忽视的一个因素是生产力，它应该基于过去的项目。 20 似乎是平均值，但是，如果您的工作效率非常高（众所周知，中等与优秀程序员的比例为 10 比 1），那么工作效率可能会达到 5，从而使 UCP 预估值接近您认为应有的水平。 我建议查看过去的项目，计算 UCP，获取总时间并确定您的实际生产力。 生产力是个人和团队需要计算的一个关键因素，以便能够有效地用于估算。
Here's an article talking about Use Case Points - via Normalized Use Case. I think the one factor overlooked in your approach is the productivity which is suppose to be based on past projects. 20 seems to be the average HOWEVER if you are VERY productive (there's a known 10 to 1 ratio of moderate to good programmers) the productivity could be 5 bringing the UCP est. close to what you think it should be. I would suggest looking at past projects, calculating the UCP, getting the total hours and determining what your productivity really is. Productivity being a key factor needs to be calculated for individuals and teams to be able to be used in the estimation effectively.
讽刺的是，原型的两框登录表单比两框 CRUD 表单复杂得多，因为登录表单需要安全，而 CRUD 表单只需保存到数据库表（以及读取、更新和删除）。
登录表单需要决定是否重定向到哪里、如何以加密方式保护身份验证令牌、是否以及如何缓存角色、如何或是否处理字典攻击。
我不知道这会转换成 UCP 点，我只知道我的应用程序中的登录屏幕比具有类似数量的按钮和框的表单消耗了更多的时间。
上次我被鼓励计算功能点，这是一场闹剧，因为没有人有时间建立一个“功能点法庭”来对难以衡量的事物做出裁决，尤其是那些没有完全落入模型的事物功能点计数假设。
Ironically, the prototypical two box logon form is much more complicated than a 2 box CRUD form because the logon form needs to be secure and the CRUD form only needs to save to a database table (and read and update and delete).
A logon form needs to decide if where to redirect to, how to cryptographically secure an authentication token, if and how to cache roles, how to or if to deal with dictionary attacks.
I don't know what this converts to in UCP points, I just know that the logon screen in my app has consumed much more time a form with a similar number of buttons and boxes.
Last time I was encouraged to count function points, it was a farce because no one had the time to set up a "function points court" to get rulings on hard to measure things, especially ones that didn't fall neatly into the model that function point counting assumes.
部分问题可能在于您如何计算交易。 UCP的作者认为，交易是从用户到系统再到用户的“往返”； 当系统等待新的输入刺激时，交易就完成了。 在这种情况下，除非系统正在响应……除非有多次往返系统的操作，否则登录可能只是 1 个事务。
查看此链接以获取更多信息...
http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/index.html
Part of the issue may be how you're counting transactions. According to the author of UCP, transactions are a "round trip" from the user to the system back to the user; a transaction is finished when the system awaits a new input stimulus. In this case, unless the system is responding...a logon is probably just 1 transaction unless there are several round trips to and from the system.
Check out this link for more info...
http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/index.html
首先请注意，Ribu 在之前的工作中表示，1 UCP 的工作时间为 15 到 30 小时（请参阅：http://thoughtoogle-en.blogspot.com/2011/08/software-quotation.html 了解一些详细信息）；
其次，很明显，当有很多用例而不是一个用例时，这种估计（例如功能点）会更准确。 例如，您没有考虑项目的启动、项目管理、环境创建等，这些都集中在 20 小时内。
first note that in a previous work of Ribu he stated that effort for 1 UCP ranges from 15 to 30 hrs (see: http://thoughtoogle-en.blogspot.com/2011/08/software-quotation.html for some details);
second it is clear that this kind of estimation like, also Function Points, is more accurate when there are a lot of use-case and not one. You are not considering for example, startup of the project, project management, creation of environments etc. that are all packed in the 20 hours.
我认为你的计算有问题：“我得到 5 和 3，所以总数是 15”。 UAW 和 UUCW 必须相加，而不是相乘。
I think there is something wrong in your computation: "I get 5 and 3 so the total is 15". UAW and UUCW must be added, not multiplied.