Predict time effort in a new J2EE project - HELP!!
Ciao,
I'm working in an analysis to investigate how much time it will take to develop e new J2EE project. With my colleagues we are analysing all the features this solution will have and then we try to imagine what kind of architecture will be suitable in order to better implement it; but when it comes the moment to predict how much time for each feature we really cannot figure out how we can proceed.
It is a tipical analysis task. What kind of metric can we use to predict our effort? is there any resource, articles, metrics, books we can use?
Any help will be very much appreciated!!
Thanx!
MarcoC
[642 byte] By [
marcocamp] at [2007-9-27 21:32:59]
That strongly depends on the developers and the techniques that will be used.
Basic algorithm:
-Do a task breakdown so that most/all of the developers agree each task will take no more than a week.
-Estimate the time for each task (tasks can be less that a week.) This includes design and developement time or those can be seperate items.
-Add risk for each task: low, medium, high. Low risk means the developers are confident it can be done in that time. High means developers are really unsure.
-Assign modifier to each risk value. Like .7, 1 and 1.4
-Sum weeks without risk. Sum weeks applying the modifier for each. This gives a best case and actual estimate. If you feel confident in the estimation skills of the staff then the developement should fall within the two values.
-For the overall task add intangibles like build support, travel time, learning time, expected time off, personnel turnover, etc.
One way to do task breakdowns for j2ee projects is by entity bean (persisted data) and GUI screens.
Even if with a different path we have applied the same procedure. We started to map the different screens (JSP views) we plan to be developed. We tried to enumerate the number of fields included in each pages (in the case of a submit mask) and the number of records to be displayed (in the case of a table view); we also divided the screens between CRUD (Create, Read, Update, delete) and RS (Read and Sort). We also identified the most important entities with the number of attributes. We also imagined to use STRUTS as framework to implement MVC2. Then we tried to give some extimation for each features (77 different tasks...) assigning more days to CRUD screens than RS and applying a contingency factor due to the difficoulties we imagine to have for each feature.
Funny thing that we also commited this job to another group to test the differencies between the two estimates: Group1 (mine) total days 700; Group2 total days 680!!!!!
Thanks for your support, very valuable!!
MarcoC
Time/labor prediction? Ha!<g>Try reading The Mythical Man Month and Peopleware.And reading coffee grinds, tarot, and the constellations.Best of luck.
Also, record your actuals as you go along and see how good your estimates are. Then, recallibrate the estimates at certain stop points, to allow for underestimating etc.
Another great clue as to how much it will take for piece of the system to be completed, I look at the history of another project that was done previously within the company (If I hadn't done such a project) or ask other colleagues. Or you could draw that conclusion from your own experience.
Cheers
>
> Time/labor prediction? Ha!<g>
> Try reading The Mythical Man Month and Peopleware.
> And reading coffee grinds, tarot, and the
> constellations.
It is possible. For a brief period I actually had the joy of working on two projects where precise time lines were projected using something like I described. And they worked.
In the vast majority of places it doesn't happen however. For various reasons. Such as poor or no requirements. Or severe misunderstandings about what the requirements mean. Or management, driven by marketing and sales, throwing out real estimates and imposing impossible deadlines. Or no change order control. Or because the time line is not broken down enough or sections are missing. Or because promised personnel are not available when needed or multi-tasked, etc. And sometimes because the developers are over optimistic.
Note that most of these failures are due to management failures and not estimation nor developement failures.
Most of the industry, both management and developers, are unwilling to put the time into process control (of which project management is only a part.) So most of the industry can't make accurate estimates (time or cost.)
> Another great clue as to how much it will take for
> piece of the system to be completed, I look at the
> history of another project that was done previously
> within the company (If I hadn't done such a project)
> or ask other colleagues. Or you could draw that
> conclusion from your own experience.
>
We also had this approach trying to verify starting from a first analysis of the fatures of the new project and check against a similar project. In fact our estimate was more or less similar (even if- funny! - the other project is a .NET portal!!!).
> Or management, driven by
> marketing and sales, throwing out real estimates and
> imposing impossible deadlines.
TRUE! You should have seen when we went to the management guys and to sales managers with our estimates. When we started to explain from where it came our estimates their heads moved from right to left disagreeing!!!
"Our customer is expected to spend a sum and from your estimates that sum seems what the project costs to us!! We have to cut the days...".
And then it started a true war between us and these guys. At the end the decision was to mantain our estimate but to divide the features in sub activities and sub projects allowing the customer to choose among different options: small, low cost and basic features to big highly expensive and full features.
Now everything is done. We will see if we win the project or not!
Ciao!
Marco
> > And reading coffee grinds, tarot, and the> constellations.> Best of luck.:-))
