Comments on: Software Cost Estimation With Use Case Points – Technical Factors http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/ Software product success. Sun, 12 Feb 2012 19:10:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: accidental business analyst » Blog Archive » Estimating With Use Case Points http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/comment-page-1/#comment-72195 accidental business analyst » Blog Archive » Estimating With Use Case Points Tue, 20 Feb 2007 21:55:20 +0000 http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/#comment-72195 [...] Technical Factors of the Implementation. Primarily non-functional requirements of the system. [...] [...] Technical Factors of the Implementation. Primarily non-functional requirements of the system. [...]

]]> By: Levent Gurses http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/comment-page-1/#comment-70704 Levent Gurses Wed, 14 Feb 2007 04:38:49 +0000 http://tynerblain.com/blog/2007/02/13/software-cost-estimation-ucp-2/#comment-70704 Great points! I would add the following: 1. Quality - still very difficult to quantify in software projects, therefore difficult to plan. A quality coefficient should be developed indicating how much of it will be incorporated into the product. 2. Portability - if the killer app needs to run on Linux and Windows, on WebLogic and WebSphere and OracleOS, on IE and Firefox and Oprera, you get the picture..., someone needs to factor it into the estimates 3. Configurability - Point 9. Easy To Change touches part of the aspect, however some applications require more configuration than others. This should also be made part of the estimation. Finally, the 13 points of estimation seem to assume that developers are trained in the language and the platform they develop in. What if an innovative language or protocol is proposed? How will developer training and the degree of novelty will affect the use-case LOE? Great points!

I would add the following:

1. Quality – still very difficult to quantify in software projects, therefore difficult to plan. A quality coefficient should be developed indicating how much of it will be incorporated into the product.

2. Portability – if the killer app needs to run on Linux and Windows, on WebLogic and WebSphere and OracleOS, on IE and Firefox and Oprera, you get the picture…, someone needs to factor it into the estimates

3. Configurability – Point 9. Easy To Change touches part of the aspect, however some applications require more configuration than others. This should also be made part of the estimation.

Finally, the 13 points of estimation seem to assume that developers are trained in the language and the platform they develop in. What if an innovative language or protocol is proposed? How will developer training and the degree of novelty will affect the use-case LOE?

]]>