We are basically using Waterfall life cycle methodology.
Requirement Analysis: I get a use case created by some one else.
Design (talking only about Low level design): I get some little feeling about how would I design it, may be either instantly/ or after some time.
Coding+Unit Testing: In case of unit Testing I am not using any TDD, but I am trying to get full code coverage, through mocks and etc. after the coding is done.
I am being asked about estimates just after the Requirement walk through.
Since I have only a fair amount of idea about how the design will look like, I have no way to say about estimates.
As for the coding part is considered, how can I get the total number of methods at the “just finished definition phase” (I never know how much will I be refactoring at this stage), Unit Testing with full code coverage: I haven’t written a code, then How can I know how many behaviors are there to test for one method and hence time.
Is there some scientific way/ or other way to know this at this stage?
Note: I have already read this possible similar question.
I can break down all my tasks to small units, but I am having problem to give an estimate for each unit.
Edit1
This is part of my problem too it all started from here. Our Organization also unit tested (or correctly saying performed integration testing) manually or through emulators etc. So whenever some enhancements come for a particular client You need to create test data again, and what about any breaking changes You have introduced. So, I introducing Automated Unit Testing, but now there is again a problem for correct estimation which is necessary to give the organization farsighted view of “time estimate of creating a test suite with code” in simple words build to validation team.
Kindly help.
8
I suggest that you read about something called the Cone of Uncertainty.
It is provably impossible to accurately estimate the completion date of a project before implementation or even design has actually started. That’s not to say you can’t estimate at all, but at this stage of planning, the actual duration could be as much as 4x your estimate, even if you are able to come up with highly accurate task estimates.
This is why waterfall is evil. Even Royce only proposed it as a straw-man for what you shouldn’t do. At least try to get buy-in for the RUP and allow for some degree of iteration, otherwise you’re screwed.
If you’re really going to be held to whatever estimate you come up with (in other words, it’s not actually an estimate, but rather a deadline), then spend a few days or weeks developing an architecture and usability model, estimate your features/tasks, add it up, and multiply by 4. That is about the best heuristic available.
If you anticipate any problems with overhead (organizational busywork), training, turnover, etc… then add more fudge factor to account for it. Estimate the percentage of time per day that the project team will actually spend on project work, and divide by that number to get an adjusted estimate. This is separate from the 400% margin of error above; that estimate is for effort whereas your adjusted estimate is for time.
4
When I need to provide estimates, after completing the analysis, I would do the following:
1. Look at the individual functions that we will be coding.
2. Use the total of all the functions as a count, and then divide these functions into simple, medium and hard level, which indicates again the amount of coding we need to do.
For each, I would allocate a time, based on my experience and how much I would take to complete it.
Now, for the total application, I will be getting a value, if I need to do the task myself.
Then, I start working on the fine tuning.
Like removing duplicate methods, adding in time for refactoring (which actually reduces the time if we use a tool to refactor and start refactoring as we code instead of refactoring after completion), little bit of margin of errors.
By following this method, even if there are any unforeseen delays, I will be able to deliver the task on time, and more often early.
One important thing that makes a difference is the technology to be used, and the skill level in that technology.
Like others said above, there is a risk at early stages of planning. The estimates need to be improved as the project starts and goes forward.
Resources, skillset, technology (existing/new) , all make a difference.