Printable View
We used to have a template that broke down tasks into
1) Analysis
2) Code Design
3) Coding
4) Testing
Then you count lines of code and factor in your experience on the specific app.
Presto - Estimate in no of days.
Since I left that company (Aug - 2007), I no longer have access to the estimation template.
How do you folks do it?
:wave:
I've never broken down by lines of code. Not sure that's even helpful. If you learn a new method that is faster, but takes 20 lines instead of 10, it certainly doesn't take twice as long to code that. But I digress.
We usually break the tasks down to activities that would take about a day, and add them up. Testing can double it, but if we just skip the testing and close our eyes, then we can eliminate that altogether. Now management likes the answers we give. Ship it.
Moved to General Developer!
Rough estimation involves taking into account previous experience of a similar project and weighing the abilities and technologies required against available resources. If you're lucky enough to have all the resources you need then it's usually done in a straightforward manner. You could use your own experience to make the ballpark numbers for estimation.
From my experience, senior managers does the estimation based on functionality or requirements asked for by the client on a per Man-Day Basis mindless of the actual availability of resources and developers.
Benchmark used is usually Man days required by our highest technical boss to develop the modules, multiply some percentage to it for the lesser developers and then add them all up to determine Man Months. And voila, estimation complete!
A note of caution though, because of the large gap of this technical head and lesser developers a lot of projects gets severely under-estimated or under-manned so they pump lots of resources in the middle of the project or do a lot of overtime to compensate and make the deadline.
anyways this is the usual template
1) Analysis 30% of development
2) Code Design and Coding (development) (estimate the ballpark based on experience or input from developers/designers)
4) Testing = 30% of development
Oceane,
You are right about the overtime. Almost every project I have seen has developers compensate to make up the project deadline.
Its easier with maintenance projects in the sense, you mostly know the code that's out there.
I have been wondering, if there are estimation templates available for development projects.
Ocean, youre saying that coding is only 40%? Seems low.
Analysis/R&D should take about 20% max, then testing and deployment another 20% and 60% would be left for actual coding. Alot of times I do testing while coding so that 20% would be more like 10% and coding 9including testing) would be 70%. I would also list out "assumptions". These would be stipulations on the project requirements that iif changed (like upgrading of a Server to a newer version that breaks the app) then if that happens its not included in the project to upgrade the code to make it work with the new server etc. and they have to sign on to a new project to upgrade the application to work with the new environment etc
If you have 60% of the time given to coding, then you're not testing enough! This is not including unit testing or any of the testing-while-coding, because that's a natural part of coding.
I once worked for a project, where our manager told us the project policy was "no testing while coding".Quote:
Originally Posted by mendhak
Of course, nobody bothered to adhere to that advice.
:wave:
I got back a few links. Check 'em out.
http://www.google.com/search?hl=en&q...te+programming
I think the estimates greatly vary between different project areas, customers and employed technologies. I'm not even sure that an estimate template is always a good idea unless you take on more or less the same type of projects. One major factor that comes into play when estimating is the general size of the project. I've been lucky enough so far to deal with medium to long running projects (my quickie is a couple of man-months). The reason I'm saying this is because it's so much easier to slip up on projects that have short timeframes. If you have a one-year project and you drop the ball somewhere and lose a man month or discover an unpleasant surprise somewhere, it's easier to catch up later.
I've generally worked with banking systems for several years. That means tons of information and specs, some things that are supposed to work in one particular way work in a totally different way and there are lots of interfaces with other systems.
What I've learned and try to apply to each situation as best as I can is that I cannot pin down an estimate unless I have a detailed spec or I go through the analysis phase first. Obviously I give estimates out on proposals. However, unless I'm sure that my estimate will not deviate more than 10%,there is a small clause in the proposal that says that the final project plan and cost estimate will be given once the customer signs off the deliverables of the analysis phase. This may seem preposterous but it works pretty well if the customer knows and trusts you.
My experience so far for coding a system mostly in house (custom code) is:
~20% analysis
~10% design
~20% coding
~45% testing/certification
~5% overhead, installation, configuration & go-live support.
This changes when I'm extending existing systems to something like:
~30% analysis
~5% design
~10% coding
~50% testing/certification
~5% overhead, configuration & go-live support.
I'm sure that other areas of development experience a wildly different state of affairs and the things that I wrote won't make any sense there.
We don't break ours down by % .... it is what it is... sometimes the analysis and design make up 60%, development 10%, and test the remaining 30%.... other times it'll shift back to development... each department is responsible for coming up with the estimates for each of their part of the cycle. I generally follow this formula - figure how long it would take me, double it, then take any where from 50% (depending on the developer projected) to 80% of that estimate.... it's been pretty acurate at times....
-tg
How do you arrive at a number? Apart from gut feeling?Quote:
Originally Posted by techgnome
:wave:
Well you also got to use experience to judge the overal hours and cost/value to the client. Even if it can be done in 20 hours the total cost of 20 hours may be way too low for the value the client is getting :D
Automated Unit Testing = minimal time. :afrog:Quote:
Originally Posted by mendhak
How do I arrive at that number? I've been working this application for 10 years. I helped write the first lines of code that formed the app. In other words, I have an extremely good handle on what it takes to get things done in the app. I also know what is within my skills, and how long it would take me to do something. Sometimes I'm wrong, and it takes less time than I think (the BA's have a way of making the most simplest of things and making it sound complicated..... and yet at the same time they can do the exact opposite....) and that's OK, better to come in under the estimate. Clients like it when they think they are saving money. Yeah, it's a gut check, but there's nothing wrong with that.... it's called an "estimate" for a reason. We've had many ocassions where the client then said "umm.... never mind we don't need it that badly" and others times say "Wow! That's it? Do it!"
Oddly enough, we had one potential client on the hook one time that when we gave them the figures for a complete install, licensing, data conversions and initial development, they nearly balked.... not because they thought we were charging too much.... but because it WASN'T enough! :eek: They couldn't understand why the competitors had many more 0's on the end of their price than we did.... and this was after we had jacked it up knowing they can afford it.... They ended up going in-house for it in the end (they'll be back.... they always come back in a couple of years.). Anywho, I'm rambling so I'll stop now.
-tg
That has happened to us as well. Client got the impression that our bid wasn't worth it because, hey, if we give it out at such a low price it must be of inferior quality:confused:. Perception management is very important.Quote:
Originally Posted by techgnome
it wasn't that they thought it was inferior, they couldn't figure out why ours was so significantly cheaper than competitors. But we've been doing this for so long, and the software is so highly specialized, customizations aren't a big deal. Most of our competitors have software that then has to be shoe-horned into what the clients need.... ours is the glass slipper that already fits...
-tg
How do you give an estimate on something which you never worked with? Very very early in my career I was asked to give an estimate on a project which involved interfacing with the google documents. Google documents had an api for python, but the client wanted the project done in php. I didn't do anything more than 100-150 line script at that time, much less write an interface for another application. Project was awarded to some one else.
Even now I am not sure how an estimate can be given for something I never worked with.
Quote:
Originally Posted by RobDog888
No, it's 30% of whatever time it takes for development.
For example,
Analysis = 30 MD
Dev = 100 MD
Test = 30 MD
total of 160 MD.
So development is about 60 - 65%.
The managers follow that rule after getting feedback from the technical team on the development ball park time. Then based on client feedback and negotiations, testing time and analysis time will be cut short (as is always the case... sadly). Hence, almost 100% of the projects are under estimated.
I do not have any scientific method to arrive at the estimate either.Quote:
Originally Posted by srisa
Lots of project managers swear by function point estimation. I told my project manager to explain this and to simplify things he said "Number of functions you will write to get this project done".
I don't think its that simple.
Sound like name that tune....
Contestant 1: I can develop that app if 57 functions.
Contestant 2: I can develop that app in 21 functions.
Contestant 1: I can develop that app in 5 functions.
Contestant 2: Develop that app!
-tg
It also sounds like lines of code, which we all know is a useless measure...
The 'function points' in function point analysis don't actually refer to code functions. I think they refer to application functions, but I'm not very familiar with the method so I can't say for sure.
Quote:
Originally Posted by abhijit
In my experience Managers at my previous work place usually give the overview of what the system will do. You'd be lucky if they already outlined what the major functionalities the system will provide if not then you'll have to sit down and do a high-level design of the system listing all functions which management calls "function list".
The first time I heard about it, I thought those are methods to be created but it has evolved into parts of the application which could mean per module, per subsystem, per class, etc.
A lot of companies in India collect metrics on time required to build a particular screen. Unfortunately, very few programmers are interested in doing the additional work to enter time-sheet information correctly. Project managers are interested in showing that the projects were completed in time.Quote:
Originally Posted by oceanebelle
For example, if a programmers spent 2 hours having coffee along with this co-worker, he will usually put down that time against some activity.
On the other hand, if a manager sees a lot of programmers doing over-time, he will "condition the data", to show his superiors that the project is on schedule.
So the metrics are skewed.
The new manager who gets a similar project will look in the database and propose an estimate based on this metrics, often citing the example of the previous project, with developers trying to figure out "how the previous team did it?"
Everybody is wise to this, and I still question the sanctity of the metrics.
:wave:
Quote:
Originally Posted by abhijit
Yep I agree to this, in my previous work place they tried to address the issue of correctly inputting time spent on projects with several measures.
The most effective was to leave it to the project leaders to ensure that the information gathered or entered is closest to what is happening in reality. Project leaders answer to Project Managers.
Some groups were able to provide correct data and the bosses were able to determine the productivity of that group, however when it comes to the development group, the documentation-lazy developers often skew data too much to make it of any use. It will take a long time for developers to follow SOP unless stricter measures are put in place.