Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking for a reference to the following. I commonly hear that one-third of a projects time will be spent in design, one-third in implementation, and one-third in testing. The three phases of development seems to be derived from the waterfall model. But, where did the time division originate (1/3, 1/3, 1/3)? Is there a paper or book that this is from?

share|improve this question
6  
[Citation needed] –  Dour High Arch Dec 5 '12 at 19:08
    
This was discussed on MSO prior to being migrated here. The way I read the question it's about finding the source of an oft quoted rule of thumb (I've heard the "1/3 rule" quite a few times myself), and not about discussing its merits - we have a ton of questions about estimation in general were answers discussing the merits of various estimation techniques would be more appropriate. –  Yannis Rizos Dec 10 '12 at 10:38
    
What makes you think this is a standard rule of thumb? Can you site a reference? –  Bryan Oakley Dec 10 '12 at 12:13
1  
Bryan Oakley, you are asking my question. I am asking for a reference when I ask, "Is there a paper or a book that this is from?" What person originated this rule of thumb? Brooks (Mythical Man Month), Yourdon, etc.? –  zooropa Dec 11 '12 at 3:54
1  
Who cares?..... –  Jim G. Dec 11 '12 at 4:32
show 1 more comment

migrated from stackoverflow.com Dec 10 '12 at 6:37

This question came from our site for professional and enthusiast programmers.

1 Answer

The rule of thumb you're describing sounds extremely similar to Brooks' rule of thumb, as presented in the Mythical Man-Month:

For some years I have been successfully using the following rule of thumb for scheduling a software task:

1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand.

This differs from conventional scheduling in several important ways:

  1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.
  2. The half of the schedule devoted to debugging of completed code is much larger than normal.
  3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.

I don't know where exactly your rule of thumb comes from, but it certainly looks like a derivative of Brooks' rule of thumb.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.