Software Best Practices

Voices on Software Development Best Practices
Welcome to Software Best Practices Sign in | Join | Help
in Search

Test Software Estimation

Last post 04-20-2009 11:04 AM by Anonymous. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 02-11-2009 1:48 PM

    Test Software Estimation

    Hi,

    I'm working actually with a software estimation theory that until now is working pretty good.

    The case is:

    In a general mode Concept proof are hard to estimate, since this a new technology and 80% is unknown. In my case the project is a low level project working with C and sometimes Assembly language, when the project was assigned to me I felt a stoma freeze, thinking "Jesus if this is complex and hard to implent, how I'll gonna test and more than this, how I'll estimate this, this is like try to capture a Yeti, you need capture but you never saw one."

    BTW the main idea of the topic is not the project, but the philosofy of the project and estimation Test Software. Well my technique used was:

    1. Planning poker for general scope of the project "I know, everybody already hear this technique"

    2. Based on Steve McConnell's book, I got a math formula common on Operational Administration, called PERT.

    3. The result until is: We are in good way of work, complain the estimated before starts the first phase project.

     

    I'm curious to hear your point of view about this, feel free to write anything... "People shot me with rocks, I'll get these rocks to build my garden."

    Filed under:
  • 04-20-2009 11:04 AM In reply to

    Re: Test Software Estimation

    Fernando,

    You used two interesting approaches.

    Planning poker is a structured group technique commonly used to create a size number that is calibrated to your actual work during incremental development. So,  you need to run a few increments before you can create an duration estimate.

    The PERT formula works with three estimates, (Best Case, Worst Case, and Most Likely Case) and then shift it a bit to the Worst Case to deal with developer optimism.

    Did the two techniques converge on a similar effort and/or duration number? If they didn't converge, you may want to go back and look at both of them.

    Given the 80% is unknown, I am curious if all the parts share the same uncertainty as the whole. That is, while the overall application is new, we have built modules of this complexity before, we have built interfaces, etc. That it the parts are fairly standard even thought they are building something new and, perhaps, complex. (Ever been to Lego Land?) These "standard components" may be a third way to estimate.

Page 1 of 1 (2 items)
Seminars           www.Construx.com           Consulting