Quantcast

Maximum PC

It is currently Wed Oct 01, 2014 11:08 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 20 posts ] 
Author Message
 Post subject: How do you estimate your software projects?
PostPosted: Mon Oct 27, 2008 12:02 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
/discuss

I am working on estimating my first project, where I am participating in the architecture and performing nearly 100% of the coding work. I have some (what I consider) to be "accurate" guesses, based on my last set of changes to the application (which was estimated by the original developer who no longer works here).

Halp?


Top
  Profile  
 
 Post subject:
PostPosted: Mon Oct 27, 2008 12:06 pm 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
Estimate time cost?

Practice, mostly. Tough question!


Top
  Profile  
 
 Post subject:
PostPosted: Mon Oct 27, 2008 12:44 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Yeah... The original "random number from the air" estimate for the entire project (from the guy whom is no longer here) was 750 hours. Admittedly he had less info about the scope that I do now, but my number is coming in around 460-480 and that includes a full week for IT testing a week for client acceptance, and a week for documentation (roughly).

I know that I won't be able to get help with the actual estimate, but some techniques might be helpful. I am going to dig out the software engineering book and see if it has anything useful. I am totally okay with being 30-35% higher than what I need. Even maybe 5% under... but that is about my range.

What my PM, Supervisor, and Clients think is acceptable is another story. I am hoping my tolerances are tight enough.

"Under promise, over deliver".


Top
  Profile  
 
 Post subject:
PostPosted: Mon Oct 27, 2008 3:56 pm 
Million Club - 5 Plus*
Million Club - 5 Plus*
User avatar

Joined: Sun Sep 12, 2004 6:37 pm
Posts: 4745
Location: In the monkey's litterbox
I haven't done much real work but I'd take your estimate and add 5% at a minimum.


Top
  Profile  
 
 Post subject:
PostPosted: Tue Oct 28, 2008 4:15 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
I'd add at least 30% because you haven't done this before.

A week for testing? Are you testing as you go, building units around tests, etc.? If not, a week seems like a VERY small amount.

Time coding == time testing is a general rule that works well. It really depends on the project, obviously.


Top
  Profile  
 
 Post subject:
PostPosted: Tue Oct 28, 2008 4:36 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
I am going to be testing things as I go of course. The only way I can know that it is done. The week for testing is where I practice my roll-out scrips on from dev to test to simulate the actual roll out. We have 3 other members of the team who will help test and document. That week is 100% testing where I am going to try to build some time in to test things myself as I go. Then the clients play for a while before we get serious about moving it out to the users.

I had a VERY successful roll out of my first batch of changes/updates/fixes (which amounted to around 150 hours or so of work, with some additional overhead for me learning the system being the new guy). I am guessing this will be closer to a 400 hour effort over all (code-wise). I spent a lot of time going from the current version all the way through the steps to get to the new version. I did it several times over the course of a few weeks. It was helpful to test my roll-back scripts as well (for the database).

I just want to make sure I am reasonable with my estimates, but I don't want to cut myself short and then end up spending 10 or 12 hour days to make up for low estimates (we only have to record 8 hours a day, obviously). I am going to go through the notes on what new screens and fields, features that need to be developed. I am pretty sure I have a solid idea but this is my first HUGE project where I am going to be responsible for all of the development.


Top
  Profile  
 
 Post subject:
PostPosted: Tue Oct 28, 2008 4:37 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
Well, so long as they know that, you should be fine. :)

Document / take notes of every part of the process ... it will be helpful with the next project, and so on.


Top
  Profile  
 
 Post subject:
PostPosted: Wed Oct 29, 2008 6:12 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
After talking with the developer whom is my SR and will be kind of supervising my work, I don't feel too bad. He already added almost 200 hours, and we haven't really looked at my numbers yet!


Top
  Profile  
 
 Post subject:
PostPosted: Tue Nov 04, 2008 1:30 pm 
Willamette
Willamette
User avatar

Joined: Fri Jul 06, 2007 9:29 am
Posts: 1447
Estimating time is tough to do in the beginning. As you get more experience you'll be able to better estimate things. However, I've found in programming that things always take longer than you expect. There's always the unexpected.

Without knowing anything about your project or you, I would add more time (the 30% mentioned earlier sounds about right). You need dedicated testing by other parties (other than programmers, ideally some of the end users), then you need to fix the problems and make adjustments for the business requirements that didn't really mean what the users thought they would mean...

As a developer, what you'll find is that you are too close to the code to see some of the problems (you'll get a ton of them through your regular work). Your other programmer types there will help, but sometimes you also need a non-programmer to give it a run through. Programmers tend to think the same way on logical things, and will miss some things.


Top
  Profile  
 
 Post subject:
PostPosted: Tue Nov 04, 2008 5:50 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Well, once all was said and done, and we had a few meetings with the clients, I turned my estimate in. If I am the only one working on the project (which I won't be, but it will be close...) I will be occupied till the middle of next year...

We are looking at close to 1000 hours total.


Top
  Profile  
 
 Post subject: Re: How do you estimate your software projects?
PostPosted: Sun Nov 09, 2008 2:29 pm 
8086
8086

Joined: Sun Nov 09, 2008 12:37 pm
Posts: 1
CrashTECH wrote:

I am working on estimating my first project, where I am participating in the architecture and performing nearly 100% of the coding work. I have some (what I consider) to be "accurate" guesses, based on my last set of changes to the application (which was estimated by the original developer who no longer works here).

Halp?

The firm I used to work for used a proprietary development system named SPECTRUM (I don't know whether it's still around, or if it's connected to various companies with the word in their names). I never got to use it much (I was a programmer, not so much an analyst), and "waterfall" development systems are not entirely appropriate in these days of quick prototyping (http://en.wikipedia.org/wiki/Waterfall_model--this introduced me to the neat term "sashimi model") , but I remember that some of the principles seem to me to be applicable still:
    --Realizing that you can estimate some parts of the development process only after you have done some of the earlier work. You have to do the User Requirements before you can estimate preparing the Design, and that has to be done before you can really estimate the programming. These days there's much more feedback and iteration, but, having given more than a few back-of-an-envelope estimates before truly realizing the scope of a project, I think that it's more important than ever to get an idea of the scope of a project, or better still the scope of the parts of the project, before committing to an estimate.
    --Getting a good idea of just how much work is involved. In SPECTRUM, one of the phases involved creating an inventory of the various screens and reports that will be required. There are often more of these than one might expect at first blush, and each one will take a certain minimum time to complete. When clients would cavil at some of the Programming estimates, we'd be able to say something like, "Well, there are twenty reports to program, and each one will take at least an hour, maybe two. If you don't like the estimate for the reports, which reports would you like to do away with?"
    --There are factors that make development harder. SPECTRUM had a bunch of factors for many of these: if the development team has more than three members, multiply the estimated hours by 1.3 (or whatever) for coordination; if the client contact/"chief customer" changes, multiply by 1.x; and so on. There was a big list of these, most of which, of course, I've completely forgotten.
    --Minimize changes during the development process: SPECTRUM had a very hard line on this: each phase had to be signed off by a client committee, the estimate for the next phase was based on this, and no changes were permitted without a very heavy penalty. (Requested changes were put on a post-project to-do list.) As I say, these days we wouldn't be that hard-line, but there are some changes that are so big that they change the rules completely. I was on an RPG project where we casually assented to the client's request that dates be displayed a certain way; this required about six lines of code every time a date was input or displayed, in every program, and for every screen field or report line, a huge job. I also remember reading about a large project in which the hardware was changed about half-way through--"Well, all Unix is the same, right?" Not really--it put the project a year or more behind.
    --Leave room for implementation, testing, documentation, and training; these are all non-trivial, and they tend to be overlooked.
Using SPECTRUM and common sense, and with a few exceptions like the RPG project in which we took a big bath, my former firm was able to have an excellent record of on-time on-or-below-budget projects. (When we came in below budged, we were able to start working on the wish lists.)

Software development has changed a lot since those days (I'd look now at a couple of Steve McConnell books, Code Complete and Rapid Development; I haven't read his Software Estimation (http://www.microsoft.com/mspress/books/2425.aspx), but I bet it's a winner), but I think that many of these SPECTRUM principles still apply.

There's a lot of stuff out there on what is generally known as System Development Life Cycle models, of which programming estimation is just a small but essential part. Just randomly Googling, I found thousands of thousands of hits, including http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx, http://en.wikipedia.org/wiki/Software_development_process, http://www.elucidata.com/refs/sdlc.pdf, and so on.

Hope that some of this helps. Cheers, --Howard[/list]


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 5:18 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
We did have the requirements pretty well nailed and I had done a release where I spent about 140 hours making changes and updates. So I am pretty confident in what I ended up turning in. Although I pretty much am relying on being able to reuse a lot of objects that are already there. If I can't It is going to add maybe 40 or so more hours... which is almost 10% of my entire estimate... /sigh

Lets hope I can re-use what is already there!


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 5:22 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
What kind of development model are you using? (Waterfall, agile)?


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 5:30 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
TBH, I am not really sure what you'd call it.

Basically, what we have is an application that existed when I got here. My first task as a bug fix / small enhancements release (the intent was to have 4 releases per year, mostly maintenance stuff. Given that this goes to ~350 people who are in remote locations, sometimes it takes them 3 weeks or more to get the newest version so quarterly is looking like it is too often. I am really hoping I can go to bi-yearly... but I digress...).

There was "project" created with a set number of hours for me to complete the process. One of my first meetings was to meet the owners of the application on the business side and we talked about the outstanding issues, prioritized them, and that was my task list. I made the changes, we did our testing, the clients did their testing, and I rolled the app out.

I imagine that I will be starting another one of those releases this month (which is NOT related to the project I am going going to be starting FOY). This is probably going to be an on going fix/enhancement thing, probably twice a year. Same process, meeting with clients, prioritize bugs etc, do the work, test and release.

This is another project involving a brand new module for the application (can you believe they are not tracking their equipment and parts inventory right now??? Apparently this is more common than I thought). It is going to involve a lot of work (just shy of 600 hours to complete). Same process though, meet with clients, get requirements, do the work, test, let them test, and then release.

So I guess that was a long-winded way to say it is close to waterfall where the maintenance goes on till it is replaced, with additional projects jumping to the top and falling through? The big thing is that you can have maintenance tasks going on while you are getting requirements for new features.


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 5:51 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
I'm going to guess waterfall as well, but all you've told us about is the schedule .. not the process.

Waterfall is still the 'default' software development paradigm, though, so if you aren't making an effort to implement a different system, you're probably a waterfall dev team.

I asked because I'm working in an agile shop for the first time and the differences are very interesting. It has become one of those 'why didn't we ALWAYS do it like this?' moments.


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 5:59 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Image

Requirements -> Get from Clients.
Design, Implimentation - > Do the work.
Verification -> Testing.
Maintenance -> ? Rinse and repeat?

Doesn't the process kind of dictate the schedule?

I am not making any call to change anything. Not that I don't think it could be better, but ::shrug:: I am still the new guy. I am mostly just doing as I am told for the time being. I think the new developer that has taken over the whole collection of applications (one of which is becoming "mine") wants to make some changes to the way we do things but we haven't been able to do that.

The guy who was going to be my main mentor left, so the other took over. There are a ton of things going on that we are trying to wrap up. Lots of stuff got behind with the attrition and loss of inherent knowledge.

Not exactly sure of the specifics on Agile development. Although I am sure that some concepts are used. I am betting it is more of a hybrid than anything else.


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 7:05 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
That is PURE waterfall. Heck, your little image there shows how the process was named. ;)

To be honest, I'm not sure that a hybrid waterfall / agile model is possible, but if it was, it would be a horribly cumbersome monstrosity.

For instance, the process that you show above from Requirements to finished product is repeated bi-weekly on my team. Every 2 weeks, we finish a cycle, demo our competed modules, and spend an hour planning the next spring (2 week cycle).


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 7:23 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Here is where the hybrid deal came from. Sometimes, if there is a good break off point, the clients see the "progress so far". Sometimes the requirements get tweaked a little, but usually not.

::shrug::


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 7:34 am 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24224
Location: Granite Heaven
Yeah .. that is not a hybrid of the two so much as one of those instances where both models share something.

I'm not criticising .. just curious. :)


Top
  Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2008 7:41 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Meh, wrong choice of words? Nobody ever really said what model we follow so I am just going off what I observe.

Looks like the project is getting split and the second half won't be looked at again till 2010 or 2011.


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.