To all:
I don't know why all the BABOK authors used something called input/output diagrams to basically provide the higher level organization for a large part of BABOK 2.O. With that organization, coming up with a comprehensive, integrated understanding of the essential functions/tasks and their relationships is next to impossible. If you try to data flow diagram out those input/output diagrams, it is very easy to see why!
However, when you properly data flow diagram out the BABOK 2.0 diagrams, then the BABOK is alot easier to understand.
Tony
Tony - the way I read it, the BABOK 2 is not an integrated approach to doing work. It's a loose collection of non-integrated practices.
The problem a DFD presented fort his version of the BABOK would be the lack of 'one best way.' THey wanted a toolkit that is flexible enough for several different contexts.
Craig:
Section 1.5.2 of the BABOK 2.0 states : "Each task [on the diagrams] should be performed at least once during the vast majority of initiatives....." Earlier, the handbook states that the given tasks are perfomed most of the time, tailored to specific conditions. So typically, each task would be done whether the project is, for example, Waterfall or Agile.
Section 1.5.2 also states that [the diagrams are constructed to reflect that]: "Iterative or Agile lifecycles may require that tasks in all knowledge areas be performed in parallel, and lifecycles with clearly defined phases will still require tasks from multiple knowledge areas to be performed in every phase.".
The way I read it, the problem is not that one set of input/process/output diagrams does not capture the majority of situations (contexts), it is that the diagrams are not integrated input/process/output diagrams, making them very difficult to understand as the reader must do this integration in order to understand how things systematically flow .
brought to you by enabling practitioners & organizations to achieve their goals using: