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?
-
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 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
-
@BryanOakley It probably isn't a standard rule of thumb, but I've heard it (or slight variations of) constantly since my early days in the field, a little bit over a decade ago. I'm certain I also read it somewhere online, but I can't remember where (and it probably was some blog or something like that). – yannis Dec 10 '12 at 12:37
-
1Bryan 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
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:
- 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.
- The half of the schedule devoted to debugging of completed code is much larger than normal.
- 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.
