Software Estimation Thesis

#1 I know we geeks are famous for having our own acronyms and speach

i never knew we did any of this


im gonna ask for a raise



(after i figure out what he was talkng about)

#2 We are estimating Time to complete some functionality, so we can do accurate project planning and budgeting.


SLOC/LOC is (Source)Lines of Code, SM is Staff Month. SLOC is fairly inaccurate (try to guess how many lines of code atlas is before decomposing it) but can be improved with good decomposition and experience with the technology.

Most people would use Expert Judgment (which is informal guessing how long something would take to do)

Structured Expert Judgment is the easiest to move to and it involved doing best case, worst case, and using PERT (http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique) to do the Expected and Most Likely case.


So in Banking a Software Engineer would on average write 270 Lines of code (including specification analysis, design, implementation, testing etc).

The issue is that its hard to get good estimates (well with typical methods) or it took a lot of historical data to get accurate estimates with the available tools. But with the method i'm making, you can improve your accuracy dramatically over the first 4 months of recording data, and more from project to project. Industry avg data is what we use for the first milestone of the first project.

Also i should point out that all the number above come from 80% 3GL and 20% 4/5GL (X Generation Language)

Any other questions and i'm happy to respond :)

It doesnt surprise me that most indy's dont estimate, as a hobby it isnt necessary. As an individual we usually use an Agile methodology and have an excuse to skip it :) But when i finish the thesis there is a "Managers Guide" which is a 10-15 page tutorial on how to implement cost estimation easily in a small/med company.

I'd be happy to blog it when im done if people are interested.

Kind Regards.
Ashley Leach

*edit i can spell i promise :)

#3 Tks mate

[quote] It doesnt surprise me that most indy's dont estimate,[\quote]

but im "nose to the coal face coder" for the last 15 years and in all comapnies ive been in

we didnt do none of this

Esitmates consist of thumbs sucks based on amount of work expected to be dun

#4 One day you will finish this Ash :)

#5 I learned all kinds of estimation techniques, including PERT, and it's hard to be accurate. Firstly, most of those numbers are derived from companies that use the waterfall method. It varies greatly on whether you're coding in Ada v. C v. C++ and if your using Win32, MFC or .NET. I develop using the Scrum method. I define a couple weeks worth of tasks and use that as an estimate for the next two weeks. It will take months before I can come up with reasonable estiamtes because I'm always improving my skills, I'm tackling problems I haven't solved yet, I'm spending more time testing to make sure I haven't broken old code. I'm from the side of the fence that has a rough idea of what I can accomplish in the next two weeks and a very rough idea of what I can accomplish in six months but never particularly accurately.

#6 Ashley,

I wrote my Master's thesis on Quantitative Methods in Software Estimation Models. A version of it was actually just selected by peer review for publication. I'm actuallly going to be doing a couple of presentations on it at the the annual Decision Sciences Insitute conference this year. Send me an email via my profile, and I'd be happy to share it with you. I may be able to help you with some sources. You can find my email on my profile.

I am new to game programming, but have 10 years expereince with project and program management for enterprise IT projects.

I'm not sure which source you are using for the LOC ratios listed above, but Web is probably the closes analogy on the list you have provided. LOC has some severe limitations when trying to estimate object-oriented programs such as those in game development. You are going to be better off with something like Function Points, or better yet, Expert Judgement. Building games are often difficult to predict because requirements and design may be very vague and iterative development is the norm. So much is going to depend on the expertise of the individual contributors. Also the target platform is going to make a huge difference. For example, the effort to create and texture a model with 5000 polys is a lot different than one with 100K polys.

Of course, take what I say about estimating games worth a grain of salt, as I said before, I am new to this industry.

Also, I never use 160/hours per month for capacity planning. The most optimistic that I use is 120, which assumes 6 hours of productivity per day. In reality, most programmers are not going to be productive 6 hours a day. [Editorial: I know that I am going to get flamed now about Dew-binging Devs doing 30 hour days, but I am talking about averages--how many days did it take for you to rebuild your Dev machine? How productive were you then? ;-) ].

I'll stop now before I start another thesis...

Jay

#7 Sounds great Jay,

Yeah my thesis is designed to be tailored to diff studios.

So the first project (with no project or historical data) uses Industry Data and Structured Group Expert (wide band delphi for software research and straight expert judgment for non research development)
Then after the first milestone we use Earned Value to bias the industry data. After the first project we use Exp Judgment and Estimation by Analogy.

That the brief version the actual report is a lot bigger, but i will email you :)

Kind Regards,
Ashley Leach