-
-
Notifications
You must be signed in to change notification settings - Fork 255
-
-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Maybe) Incorrect cost in COCOMO calculations #281
Comments
So... I based the calculations on what COCOMO said, and you might be right on it. However I also compared it to what sloccount produced, given commit
and from searchcode,
The cost is close, although the effort is not, although number of developers is. Need some more investigation. I copied the COCOMO from a Python implementation back when I wrote it. Keep in mind COCOMO is meant to account for the cost of a building + electricity and everything else that goes into writing the code as well. Which might explain it being too high? You can also tweak all of the values if you need, although that might be moot if I got the implementation wrong. |
I see... I also checked the SLOCCount source code and your calculations are really an adaptation of it.
Indeed, but the calculated cost still seems quite high to me. In fact, there is something interesting in the SLOCCount source code, in the get_sloc file, there's a snippet with: # Overhead; the person cost is multiplied by this value to determine
# true annual costs.
$overhead = 2.4; This 'overhead' variable seems to be exactly what you suspected, and it is actually used in your code too, but with no indication of what it would be. Without it, the results are exactly the same, as expected. Maybe it could be interesting, if just as there is the parameter ' Anyway, feel free to close the issue if necessary and thank you very much for the feedback =). |
Adding overhead as an additional value to tweak seems sensible. The whole COCOMO model is configurable at present anyway so adding that makes sense. Not going to close, ill add that as an additional value you can play with. |
I'm just investigating
Quoting from SLOCCount User's Guide:
So you're absolutely right: the
If I get this right, |
Add a overhead commandline flag to set the multiplier for corporate overhead. #281
That looks correct to me, and is in line with expectations of my understanding of COCOMO and how it is derived and works. So all looks good, and the new code by @fschaefer allows this to be configured even further now. I think thats probably good enough. Especially, with a combination of Going to leave this open but will close on the next release once I get into really doing it. |
Latest updates for 3.1.0 release should resolve all of the above. |
Description & steps to reproduce
Hi,
I've been testing
scc
on a project of mine (PBD) and the estimated cost just seems to be way higher than expected:I may be completely equivocated (and I apologize in advance), but 179k$ for a 6096 SLOC project, 2 developers and 7 months, seems far above the average developer salary.
Initial investigation
Although I'm not a Go programmer, below is my attempt to understand better the issue.
The organic COCOMO calculation code (
cocomo.go
) can be quickly implemented with the following Python code:and the project cost showed above could be calculated as (using the same avg wage found on
processor.go
):that matches exactly with the one reported by scc.
However, the
EstimateCost
method only takeseffort
andwage
into account, and effort does not represent the number of people in the project nor the estimated time in months.Maybe I got it wrong, but in my head the correct way to generate the cost would be:
cost = (avg_wage/12) * D * P
.Thus, the PBD's real cost would be:
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: