0

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.

Community
  • 1
Devesh
  • 427
  • 1
  • 5
  • 16
  • Have your superiors indicated their expectations out of your estimates? Do you feel a need for them to be perfect? There is always a certain amount of risk especially at the early stages of planning. – JeffO Jul 24 '13 at 16:56
  • @JeffO Superiors(Program manager / Team lead) expect that this work should be completed by this time. So I wan't those estimates to be nearly perfect and scientific (not intuition based as it may lead to personal biasing around the team, some will say that it can be done in x time others say it can be done in y times and then some time petty politics takes it part.. thats life :)). – Devesh Jul 24 '13 at 17:06
  • I always start my software process by creating use cases, exactly because there is an estimate process named Use Case Points (UCP). However, UCP requires a time for calibration. During this period you will produce estimates with large margins of error. Each time you run UCP there will be a correction until the margin of error fits in your precision requirement. From time to time you will feel the need for a recalibration, since your actual development cost changes with experience, technology and other external factors. – AlexSC Jul 24 '13 at 17:34
  • @shankbond You should likely give [Software Estimation: Demystifying the Black Art](http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351) a read. There is a section on estimates and politics. –  Jul 24 '13 at 17:35
  • @MichaelT I thought it would be very verbose too lengthy book, but after seeing it now, I guess I will be buying it. :) – Devesh Jul 25 '13 at 01:34
  • @AlexSC You are right we were using UCP, we even estimated the time based on that for some projects, but due to organization problems and etc( organization is unable to calibrate hours used to complete a UCP). it will no longer be used in estimation. – Devesh Jul 25 '13 at 01:37
  • @MichaelT can You please advice whether this book literature is written as a reference book, one time read and You understand all of it. just thinking whether I should buy the book by myself or buy it as an organisation asset. :) – Devesh Jul 25 '13 at 03:42
  • @shankbond there are three sections of the book. The first is on estimating itself - what is an estimate, reining estimates and broad topics such as that. The second is specific ways to estimate - this is more a reference. The third section is about what to do with estimates, the politics of them and timelines. The authors site http://www.stevemcconnell.com/est.htm may help you get an idea of it (table of contents, excerpts and such) –  Jul 25 '13 at 03:46

2 Answers2

4

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.

Aaronaught
  • 44,005
  • 10
  • 92
  • 126
  • Thanks for the wonderful answer. However I don't understand, *then spend a few days or weeks developing an architecture*? What is a usability model? It would be nice if You could elaborate more on the formula "adjusted estimate for time", something like in terms of z=a+b/c, where z is ...., a is ..... – Devesh Sep 23 '13 at 16:04
  • @shankbond: Sorry, "usability model" might be a weird phrasing, I was referring mainly to the combination of your [Information Architecture](http://en.wikipedia.org/wiki/Information_architecture), [UX Design](http://en.wikipedia.org/wiki/User_experience_design), and also how you plan to do usability tests (e.g. prototypes, A/B testing, hopefully not none at all?). I'm not sure what was unclear about the architecture part. And I gave you the equation: adjusted hours = estimated hours / % of uninterrupted time. If you spend 75% of your day in meetings then max 250 h / 0.25 = 1000 h adjusted. – Aaronaught Sep 23 '13 at 23:47
  • with architecture: I am confused that I am at "estimation at just finished definition phase" developing architecture takes week/ days/ months no body knows? **Note:** By definition phase I mean only requirement analysis no requirement feasibility or deign. – Devesh Sep 24 '13 at 16:34
  • @shankbond: Architecture comes *before* design. Design is about features. Architecture is about your overall strategy for building the application. And of course nobody can know what the architecture is before they even understand the scope. I have to say, I wouldn't place a lot of confidence in any estimate provided without *some* kind of architecture documentation. – Aaronaught Sep 25 '13 at 00:32
0

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.

Kiran
  • 1