Clouds to Code

Jesse Liberty

Mentioned 1

PC developers are being called on to develop ever more complex systems, and in response the established tools for program design are now available on PC. "Clouds" is the colloquial name for the object diagrams that are central to UML. This book is a complete walk-through of the transition from design to development for programmers.

More on Amazon.com

Mentioned in questions and answers.

I am new to software project time estimation.

I have learned that people are using some techniques such as ‘Function point analysis’ , ‘Cocomo model’ etc.

Can you tell me the some of the latest and best techniques? Also would you please let me know some good tutorial links for these models so that I could go through them and understand?

Many Thanks,

Regards.

Anusha.

I want to suggest a few time-consuming areas often ignored when breaking down strict requirements but always come into play during implementation. Especially be aware of these if you're contracting and every hour is your own. You'll be surprised at how often employers count these hours against development time because they are piecemeal tasks and expected in due course of the project - of course these things add up. I suggest allocating time for these - and explicitly outline them as such in your estimation process so there is no confusion:

  • Meetings about the code - in person, conference calls, distractions of being taken out of your immediate zone
  • Test/debug cycles of the code at project "completion", i.e. during user acceptance. It's amazing how many tweaks can be argued into original requirements even when scope is well defined because it's about dotted 'i's and crossed 't's and often subjective stuff. Hopefully client or employer expectation can be managed to a degree.
  • Integration - often integration of code results in new complexities or unforeseen circumstances, and often the timeline doesn't account for this because timeline is based on modules.
  • Checking your check-ins - represents all those little things around any piece of code like checking it into source control, tweaking its source comments or documentation, etc.
  • Support - lots of questions and answers will be directed your way - you may not have to write a line of code during this time but will spend time looking at it to provide answers.
  • Getting stuck - every coder does it. Allow some time for things to take a bit longer.

These are truly parts of real-world software project estimation. There are more gotchas but this might help provide some direction about kinds of things to pragmatically consider outside an ideal or academic process. I think a lot of text books give sound advice; one book I fondly remember is Clouds to Code (for the sake of throwing out a link).

In my experience full-time employees don't necessarily have to be as concerned because organizations tend to absorb salaried time outside strict project timelines as a cost of doing business.

Realated tags

estimationprojecttime