Estimate of hours to be spent on a project

Discussion in 'ASP .Net' started by Bob, Jul 9, 2004.

  1. Bob

    Bob Guest

    I have recently joined a healthcare company where I am the solo
    programmer. I am going to be starting work on a project. The
    management has asked me to provide an estimate of hours I am going to
    spend on the project.

    How do I estimate the number of hours I am going to spend on
    programming in a project?

    Thanks for help

    Bob
    Bob, Jul 9, 2004
    #1
    1. Advertising

  2. Bob

    TJS Guest

    google this

    "help desk" asp.net


    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    TJS, Jul 9, 2004
    #2
    1. Advertising

  3. Bob

    TJS Guest

    --break the job down into small tasks
    --estimate the time to do each task

    for help, contact the guy at http://www.ASPkey.net he's a project
    management professional




    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    TJS, Jul 9, 2004
    #3
  4. Bob

    Randy Howard Guest

    In article <>,
    says...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?


    Have you ever worked on a similar project before?
    If so, then you should have an idea of how long it took overall.
    Where you part of a team or working on your own?
    If you were on your own, then you should have a very good idea,
    but as part of a team, you should also have a feel for time to complete.
    How much will you have to learn new to complete it, or are you already
    technically familiar with what is required?
    If it's all new to you, try to imagine the worst case time it would
    take you, then double it. :)

    If it's your very first solo project, multiply by 3.

    Unfortunately, there is no perfect way. If you have worked on a lot
    of projects, particularly similar ones, you'll almost instinctively
    know how long it will take. If you haven't, you'll be way off, no
    matter what method you use. Better to overestimate it, and come in
    early than vice versa.

    You might also ask your management chain if similar projects have been
    done before, and how much effort was required to complete them satisfactorily.

    Even better, find a programmer more familiar with the goal and ask for an
    opinion.

    --
    Randy Howard
    To reply, remove FOOBAR.
    Randy Howard, Jul 9, 2004
    #4
  5. Randy Howard wrote:
    > In article <>,
    > says...
    >
    >>I have recently joined a healthcare company where I am the solo
    >>programmer. I am going to be starting work on a project. The
    >>management has asked me to provide an estimate of hours I am going to
    >>spend on the project.
    >>How do I estimate the number of hours I am going to spend on
    >>programming in a project?

    >
    >
    > Have you ever worked on a similar project before?
    > If so, then you should have an idea of how long it took overall.
    > Where you part of a team or working on your own?
    > If you were on your own, then you should have a very good idea,
    > but as part of a team, you should also have a feel for time to complete.
    > How much will you have to learn new to complete it, or are you already
    > technically familiar with what is required?
    > If it's all new to you, try to imagine the worst case time it would
    > take you, then double it. :)
    >
    > If it's your very first solo project, multiply by 3.
    >
    > Unfortunately, there is no perfect way. If you have worked on a lot
    > of projects, particularly similar ones, you'll almost instinctively
    > know how long it will take. If you haven't, you'll be way off, no
    > matter what method you use. Better to overestimate it, and come in
    > early than vice versa.
    >
    > You might also ask your management chain if similar projects have been
    > done before, and how much effort was required to complete them satisfactorily.
    >
    > Even better, find a programmer more familiar with the goal and ask for an
    > opinion.
    >


    Hmmm....

    Randy provided some good advice, but I find the kicker in all of
    this is "how well is the project defined in the first place?"

    What your (non-technical) coworkers may feel is "well
    defined" you will probably find is rather vague as you go
    along. (I presume this is what Randy's comment about
    multiply by 3 was based on.)

    Second of all, given your situation, it sounds like your
    only "testers" will be the end users. For certain you have
    to plan for a debug cycle after it gets out, no matter how
    much up front testing you do. So, I would change that
    "multiply by 3 to multiply by 4 or 5" for the total effort.

    Just opinion.,

    NPL


    --
    "It is impossible to make anything foolproof
    because fools are so ingenious"
    - A. Bloch
    Nick Landsberg, Jul 9, 2004
    #5
  6. (Bob) wrote in
    news::

    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am
    > going to spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?


    Bob,

    Read chapter 8 ("Estimation") in "Rapid Development" by Steve
    McConnell.

    --
    Hope this helps.

    Chris.
    -------------
    C.R. Timmons Consulting, Inc.
    http://www.crtimmonsinc.com/
    Chris R. Timmons, Jul 9, 2004
    #6
  7. Bob writes:

    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?


    Well, it seems to me, that if you're the solo programmer and you
    have one (1) project, you'll be spending ALL your hours on programming.

    So just tell them "All".
    Programmer Dude, Jul 9, 2004
    #7
  8. Bob

    TLOlczyk Guest

    On 8 Jul 2004 18:23:12 -0700, (Bob) wrote:

    >I have recently joined a healthcare company where I am the solo
    >programmer. I am going to be starting work on a project. The
    >management has asked me to provide an estimate of hours I am going to
    >spend on the project.
    >
    >How do I estimate the number of hours I am going to spend on
    >programming in a project?
    >

    Break the project up into parts. Order the parts by importance ie
    part 1 is the part where you know the project is failed if you fail
    to finish this part. Make an estimate on each part. Keep that
    list of estimates in a set of envelopes. Make sure that the envelopes
    have been hermetically sealed in a mayonnaise jar and stored under
    Funk & Wagnall's porch. Then multiply each estimate by 10, total
    and hand them in.

    After you finish the first part, write down how long you took to
    finish it. Compare to the estimate of how long first part took,
    and tweek accordingly. If the new estimate is lower then hand in a
    revised estimate of course with the factor of ten. If higher say
    nothing, unless it is more then ten times the estimate, in which
    case hand in a new estimate.





    The reply-to email address is .
    This is an address I ignore.
    To reply via email, remove 2002 and change yahoo to
    interaccess,

    **
    Thaddeus L. Olczyk, PhD

    There is a difference between
    *thinking* you know something,
    and *knowing* you know something.
    TLOlczyk, Jul 9, 2004
    #8
  9. Bob

    Lloyd Dupont Guest

    I think one good advice give previously was to cut the big project in small
    task an evaluate the small task.

    if you have no idea, you should say, it will be long I need to spend
    sometime working on that

    time you should spend writing a small draft/mockuyp application which cover
    a little bit of everything (a prototype), then think clearly of how much
    work you will need to complete each task.

    the firsty answer you could give next day is "writting a prototype which
    would help me giving a more accurate estimat would take: that much time"

    then when he prototype is done spend 2 days thinking, estimate each part and
    sum them up !

    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    Lloyd Dupont, Jul 9, 2004
    #9
  10. Bob

    Phlip Guest

    Bob wrote:

    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?


    Tell them you have a ball-park estimate - 60, 80, 240, whatever - but you
    will know much more in just one week.

    Before that week, write the name of each _small_ feature they request on a
    card. Ask whoever owns these features to sort them by business priority (not
    technical risk, or alphabetical order, or whatever). The feature with
    highest business priority is the feature that will boost end-user
    productivity the most.

    Take the top 8 cards.

    For a week, implement those cards. Write lots of Unit Tests as you go, and
    run them between each 1~10 edits, the fewer the better. Always rapidly
    return the code to a condition where you can predict the results of the next
    test run.

    After one week, compile everything into a deliverable, deliver it, and make
    them use it. Watch them operating the features they just request. (Oh, and
    all those tests made sure you implemented very fast, but with absolutely no
    bugs. You will be surprised. A few short minutes writing tests, and simple
    code, can prevent many long hours running a debugger.)

    Count the number of cards you finished. It could be 6, or 8, or 10, or
    whatever. Suppose it's 9.

    Now tell them, "If we keep going like this, I can finish 9 of these cards
    per week. What's the next 9 cards to do? And does running the program make
    you think of new cards?"

    They will add any new cards they think of, remove any cards that might no
    longer make sense, and then sort the stack by business priority. You will
    pull off the top 9 cards.

    When you implement these, refactor your code to merge the new features into
    the old code. The tests that constrained the old code will support this
    activity. Bugs come when you add new features to old code, so adding tests
    to all features defeats this risk.

    After the second week, you may finish 5, or 9, or 11, or whatever, number of
    cards. And you will not slow down, no matter how many features, because the
    tests maintain your velocity.

    By this time, your stakeholders will have such a clear picture of your
    velocity that they will no longer ask to "estimate" any number of hours.
    They will have a perfectly clear understanding of your throughput, and will
    not consider your velocity - 9 or whatever - as an estimate. This process
    makes them feel very in-control of your project, and very reassured. They
    can easily select features in batches that steer the project towards its
    business goals.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    Phlip, Jul 9, 2004
    #10
  11. Bob

    Nick Malik Guest

    very agile.
    nice.

    --- N

    "Phlip" <> wrote in message
    news:n2qHc.860$...
    > Bob wrote:
    >
    > > I have recently joined a healthcare company where I am the solo
    > > programmer. I am going to be starting work on a project. The
    > > management has asked me to provide an estimate of hours I am going to
    > > spend on the project.
    > >
    > > How do I estimate the number of hours I am going to spend on
    > > programming in a project?

    >
    > Tell them you have a ball-park estimate - 60, 80, 240, whatever - but you
    > will know much more in just one week.
    >
    > Before that week, write the name of each _small_ feature they request on a
    > card. Ask whoever owns these features to sort them by business priority

    (not
    > technical risk, or alphabetical order, or whatever). The feature with
    > highest business priority is the feature that will boost end-user
    > productivity the most.
    >
    > Take the top 8 cards.
    >
    > For a week, implement those cards. Write lots of Unit Tests as you go, and
    > run them between each 1~10 edits, the fewer the better. Always rapidly
    > return the code to a condition where you can predict the results of the

    next
    > test run.
    >
    > After one week, compile everything into a deliverable, deliver it, and

    make
    > them use it. Watch them operating the features they just request. (Oh, and
    > all those tests made sure you implemented very fast, but with absolutely

    no
    > bugs. You will be surprised. A few short minutes writing tests, and simple
    > code, can prevent many long hours running a debugger.)
    >
    > Count the number of cards you finished. It could be 6, or 8, or 10, or
    > whatever. Suppose it's 9.
    >
    > Now tell them, "If we keep going like this, I can finish 9 of these cards
    > per week. What's the next 9 cards to do? And does running the program make
    > you think of new cards?"
    >
    > They will add any new cards they think of, remove any cards that might no
    > longer make sense, and then sort the stack by business priority. You will
    > pull off the top 9 cards.
    >
    > When you implement these, refactor your code to merge the new features

    into
    > the old code. The tests that constrained the old code will support this
    > activity. Bugs come when you add new features to old code, so adding tests
    > to all features defeats this risk.
    >
    > After the second week, you may finish 5, or 9, or 11, or whatever, number

    of
    > cards. And you will not slow down, no matter how many features, because

    the
    > tests maintain your velocity.
    >
    > By this time, your stakeholders will have such a clear picture of your
    > velocity that they will no longer ask to "estimate" any number of hours.
    > They will have a perfectly clear understanding of your throughput, and

    will
    > not consider your velocity - 9 or whatever - as an estimate. This process
    > makes them feel very in-control of your project, and very reassured. They
    > can easily select features in batches that steer the project towards its
    > business goals.
    >
    > --
    > Phlip
    > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    >
    >
    Nick Malik, Jul 9, 2004
    #11
  12. Bob

    Nick Malik Guest

    I'm amazed at how many answers you got, and not one that takes a
    quantitative approach to estimating.

    So, I'll offer an alternative:

    Take your requirements, perform a Function Point Analysis on them. Get a
    count of your function points (a measurement of the SIZE of your application
    based on a scientific method for measuring the size of the requirements).
    Multiply the function point count by your estimated productivity per FP (you
    can get an excellent starting point by using the national averages from
    Capers Jones book on software cost estimation). A good number to start with
    is 14.5 hours per function point. (Including project mgmt, analysis,
    requirements, design, coding, unit test, functional test, integration test,
    UAT, documentation, and deployment).

    Of course, learning to perform an FPA is a career activity, not something
    you do for one project. However, after teaching a session on FPA recently,
    I had a project manager come up to me and tell me something I found quite
    gratifying. He said that his group has been using FPA for estimation for
    about a year, on about a half-dozen projects (mostly ASP.NET projects), and
    FPA has been their most accurate estimation method in the history of the
    organization.

    So, for all the useful advice from ad-hoc specialists, especially those of
    us who are old enough to actually assume that we'd be able to make a good
    guess, realize that all that advice is a method of guessing. Using
    measurements will produce a far more accurate number.

    Consider it.

    --- Nick Malik
    Certified Scrum Master
    Certified Function Point Specialist

    For more information, see www.ifpug.org



    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    Nick Malik, Jul 9, 2004
    #12
  13. Bob

    Brian Henry Guest

    it's very hard to estimate until you are actually working on the project...
    you have no sense of how hard the task is or how long it takes you to
    complete it until you really start getting into it... our latest project we
    estimated would take a half year... now it's virging on two years because
    some of the pieces were way more complex then believed to be or were even
    documented to be....



    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    Brian Henry, Jul 9, 2004
    #13
  14. Gabriele G. Ponti, Jul 9, 2004
    #14
  15. The most common method is to break down the specs into individual tasks.
    Estimate each task based on the time it took you to do similar things in the
    past. Then, add a confidence factor to the estimate. If the project is very
    similar to what you have done before, confidence is high. If you are getting
    into deep water, confidence is low.

    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    ************************************************
    Think Outside the Box!
    ************************************************
    "Bob" <> wrote in message
    news:...
    > I have recently joined a healthcare company where I am the solo
    > programmer. I am going to be starting work on a project. The
    > management has asked me to provide an estimate of hours I am going to
    > spend on the project.
    >
    > How do I estimate the number of hours I am going to spend on
    > programming in a project?
    >
    > Thanks for help
    >
    > Bob
    Cowboy \(Gregory A. Beamer\) [MVP], Jul 9, 2004
    #15
  16. Bob

    rossum Guest

    On 8 Jul 2004 18:23:12 -0700, (Bob) wrote:

    >I have recently joined a healthcare company where I am the solo
    >programmer. I am going to be starting work on a project. The
    >management has asked me to provide an estimate of hours I am going to
    >spend on the project.
    >
    >How do I estimate the number of hours I am going to spend on
    >programming in a project?
    >
    >Thanks for help
    >
    >Bob


    Read all your other replies. This is another approach.

    The basic phases of a project are:

    Specify
    Design
    Build
    Test
    Implement
    Run

    If you can get away with it just estimate how long it will take to
    specify the project, that is to get the scope of the whole project
    *agreed in writing*. Without that you are in no position to be able
    to say how long the other parts will take.

    Whenever anyone subsequently asks for a change present then with a
    written estimate of how much time and cost it will add to the project.
    Ask them if they wish to proceed and get the time/cost change *agreed
    in writing*. Without agreement the change does not go ahead.

    As you get to the end of each phase give a detailed estimate for the
    next phase only, and a rough estimate for the phase after.

    Allow more time for testing than you think you will need, at least two
    run throughs of the entire test suite as well as user acceptance
    testing.

    rossum


    --

    The Ultimate Truth is that there is no Ultimate Truth
    rossum, Jul 9, 2004
    #16
  17. Bob

    Phlip Guest

    rossum wrote:

    > The basic phases of a project are:
    >
    > Specify
    > Design
    > Build
    > Test
    > Implement
    > Run
    >
    > If you can get away with it just estimate how long it will take to
    > specify the project, that is to get the scope of the whole project
    > *agreed in writing*. Without that you are in no position to be able
    > to say how long the other parts will take.


    Waterfall is a completely discredited methodology. No phase has any driver
    except guesses and any exit criteria except boredom. There's no way to know
    how to track or pace each phase, or estimate a percent completion. And each
    phase has different durations.

    > Whenever anyone subsequently asks for a change present then with a
    > written estimate of how much time and cost it will add to the project.


    This penalizes stakeholders for learning from the finished app how to make
    it better. Teams who indulge in this kind of contract are usually just
    trying to get paid to fix their own bugs.

    > Ask them if they wish to proceed and get the time/cost change *agreed
    > in writing*. Without agreement the change does not go ahead.


    Right. If you can't time and can't steer, then you need a written agreement
    that you will get paid no matter what happens.

    > As you get to the end of each phase give a detailed estimate for the
    > next phase only, and a rough estimate for the phase after.


    That burdens a project with a design created with the least possible
    understanding of the implementation issues. Driving a process with
    speculative paperwork is like driving a car at night without headlights. You
    don't know where you are, and if you miss your goal you'l spend a lot of
    time recovering.

    > Allow more time for testing than you think you will need, at least two
    > run throughs of the entire test suite as well as user acceptance
    > testing.


    Manual testing, after debugging, after implementing without tests is a very
    efficient way to burn an incredible amount of money.

    If tests accompany implementation, the bug rate is much lower, and the
    software is much easier to change. That technique permits change requests to
    drive the system, not trail it.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    Phlip, Jul 9, 2004
    #17
  18. Bob

    Nick Malik Guest

    jeez, Phlip,

    that's a little harsh, don't you think?

    I find Agile methods to be more effective than predictive methods. I'm
    guessing that we are on the same page on that.
    I also find that it is difficult to teach, or pursuade, when you are on the
    attack.

    The method that rossum describes is very common in consulting models,
    because of the business practices of the employers, not because of
    intentional misconduct, or even ignorance, on the part of the consultants.
    Think about it... if a company tells you, in no uncertain terms, that they
    want you to deliver a dung-heap, and your company agrees to deliver a
    dung-heap, is it your fault that the final product doesn't smell good?

    Some of the most avid advocates of agile methods are consultants, who are
    finding that they are spending more time educating their clients than they
    are developing software! (Perhaps that's because you can develop your
    software in half the time using agile methods :). It takes time to change
    an industry.

    And, to be fair, until the majority of agilists can come up with a way to
    answer the following fundamental business question with a straight face,
    agile methods will be hampered. I outlined a method for doing this in my
    previous response on this thread.

    The question is: "I'm deciding between 10 different priorities for my budget
    for next year. I have a one-page description of each problem. How much
    will each one cost, and how many resources will each one take?"

    This is the business question that the original requester is trying to
    answer. This is the question that rossum completely ducked, and the answer
    that you attacked.

    If you answer the question, first, you will gain the credibility that you
    need to instruct and pursuade.

    --- Nick Malik
    Certified Scrum Master

    "Phlip" <> wrote in message
    news:R2FHc.2219$...
    > rossum wrote:
    >
    > > The basic phases of a project are:
    > >
    > > Specify
    > > Design
    > > Build
    > > Test
    > > Implement
    > > Run
    > >
    > > If you can get away with it just estimate how long it will take to
    > > specify the project, that is to get the scope of the whole project
    > > *agreed in writing*. Without that you are in no position to be able
    > > to say how long the other parts will take.

    >
    > Waterfall is a completely discredited methodology. No phase has any driver
    > except guesses and any exit criteria except boredom. There's no way to

    know
    > how to track or pace each phase, or estimate a percent completion. And

    each
    > phase has different durations.
    >
    > > Whenever anyone subsequently asks for a change present then with a
    > > written estimate of how much time and cost it will add to the project.

    >
    > This penalizes stakeholders for learning from the finished app how to make
    > it better. Teams who indulge in this kind of contract are usually just
    > trying to get paid to fix their own bugs.
    >
    > > Ask them if they wish to proceed and get the time/cost change *agreed
    > > in writing*. Without agreement the change does not go ahead.

    >
    > Right. If you can't time and can't steer, then you need a written

    agreement
    > that you will get paid no matter what happens.
    >
    > > As you get to the end of each phase give a detailed estimate for the
    > > next phase only, and a rough estimate for the phase after.

    >
    > That burdens a project with a design created with the least possible
    > understanding of the implementation issues. Driving a process with
    > speculative paperwork is like driving a car at night without headlights.

    You
    > don't know where you are, and if you miss your goal you'l spend a lot of
    > time recovering.
    >
    > > Allow more time for testing than you think you will need, at least two
    > > run throughs of the entire test suite as well as user acceptance
    > > testing.

    >
    > Manual testing, after debugging, after implementing without tests is a

    very
    > efficient way to burn an incredible amount of money.
    >
    > If tests accompany implementation, the bug rate is much lower, and the
    > software is much easier to change. That technique permits change requests

    to
    > drive the system, not trail it.
    >
    > --
    > Phlip
    > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    >
    >
    Nick Malik, Jul 10, 2004
    #18
  19. Bob

    Phlip Guest

    Nick Malik wrote:

    > The question is: "I'm deciding between 10 different priorities for my

    budget
    > for next year. I have a one-page description of each problem. How much
    > will each one cost, and how many resources will each one take?"


    No prob. You request the difference between selecting a direction and
    targetting a destination.

    Directions are safe to select up-front, and to schedule and budget
    proactively. Destinations (such as Features A thru N before the Trade Show
    in September) cannot be scheduled and budgetted up front. The features
    require tracking.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    Phlip, Jul 10, 2004
    #19
  20. Bob

    rossum Guest

    On Sat, 10 Jul 2004 14:57:21 GMT, "Nick Malik"
    <> wrote:

    [snip]

    >
    >The method that rossum describes is very common in consulting models,
    >because of the business practices of the employers, not because of
    >intentional misconduct, or even ignorance, on the part of the consultants.


    Well spotted Nick. If I don't get what I am delivering agreed in
    writing then the company doesn't get paid and I don't get paid.


    Philip wrote

    >Manual testing, after debugging, after implementing without tests is a very
    >efficient way to burn an incredible amount of money.


    Very true for small scale module testing which is done "in line".
    However I am not going to deliver a whole system to the users until it
    has been well tested as a whole and I am reasonably sure that it works
    well. Just because each subsystem passes all its own tests does not
    mean that the whole thing is going to work together. I have seen too
    many cases where different parts of the system pass their own tests
    but the system as a whole does not work:

    Server: "Come in unit number 1"
    Unit: "I am unit number 32."
    Server: "Come in unit number 1"
    Unit: "I am unit number 32."
    etc. ad infitum.

    Both the server and the unit had passed their own tests. The problem
    was only found when the whole system was tested. One tesm had set up
    the server and a different team had set up the unit. Whole system
    testing can only be done at the end when the whole system is
    available.

    rossum

    --

    The Ultimate Truth is that there is no Ultimate Truth
    rossum, Jul 10, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan
    Replies:
    0
    Views:
    350
  2. Replies:
    5
    Views:
    582
    Laurent Bugnion
    Apr 26, 2006
  3. Rahmi Acar
    Replies:
    0
    Views:
    549
    Rahmi Acar
    Jul 17, 2003
  4. Tom Siltwater
    Replies:
    8
    Views:
    133
    Bob Barrows
    Nov 1, 2003
  5. rutherf
    Replies:
    2
    Views:
    409
    rutherf
    Oct 28, 2006
Loading...

Share This Page