| Re: [epf-dev] A few potentially controversial assertions... |
|
Steve ----- Original Message ----- Hello Everyone As I am writing up a white paper for understanding the OpenUP core
principles I realize I am making several potentially controversial (or even
incorrect) assertions that could start a flame war (or just reveal my
ignorance J,
but that’s good too, it’s the only way to learn ) The purpose of
the white paper is to:
However, before I go through all that I wanted to get your feedback on
these assertions and ideas before I surprise you with them in a white paper. OpenUP Not your
parent’s UP
One of my first assertions and probably least controversial is OpenUP
is not re-packaged RUP, or the next contender in a long line of “yet
another UP process”. Three features distinguish OpenUP:
Software Development
Processes are Coordinating Processes
The next assertion I want to make is software development processes
exist to coordinate people. I want to make a statement to the effect of
“for most software of significant value people must work together to
create it. Software development processes
are about coordinating how people work together” I am putting forward the assertion there are two dimensions to
coordination, coordination of action and coordination of understanding.
Actually according to Holly Arrow from whom I taking much of this theory from,
there is also a third dimension, coordination of goals. OpenUP only
describes coordination of action
I want to argue the OpenUP delivery process describes only one
dimension of coordination, the coordination of action which is the spatial and temporal synchronization of two or
more people so that those actions fit together into a spatial and temporal
pattern. Our capability patterns and delivery process nicely fit
into this example and the OpenUP delivery process is a classic
Input-Process-Output model describing who does what, and when. However, the
Input-Process-Output model is falling out of favour with many industrial
psychologists and is being replaced by what is called an Input-Mediator-Output-Input
model. The dual “Input” imply feedback, and Mediator is more
descriptive of how work is accomplished. What is missing from this delivery process is attention to a second
dimension of coordination known as coordination of understanding, which is achieving either explicit or tacit meaning
among members of the group regarding the meaning of information and events. In
other words, does everyone perceive and interpret information the same way? Agile Processes
attempt to foster coordination of understanding
Most of the XP and Scrum practices (e.g. planning game, co-location,
on-site customer, daily stand-ups) are intended to get a team communicating
with one another and building a common shared understanding of the project. In
on coordination of action the agilists have drawn our attention back to the
importance of coordinating understanding. In my opinion, the agile
methodologies have addressed this second dimension of coordination sometimes at
the expense of the first. OpenUP Meta model
does not readily accommodate mechanisms for coordination of understanding
Another assertion that I would make is the difficulty with describing
coordination of understanding in OpenUP results from the meta model because the
meta model seems based on a strict Input-Process-Output model. I’m not a
UMA expert so I can only speculate. When you look at a capability pattern, and
follow the task network, each task seems to imply that it is performed by an
individual who takes some inputs, does some thinking, and creates a work
product that is then handed off to another individual. There is no mechanism
for describing the ongoing conversation that may take place between
individuals. For example, when the developer
is designing the solution, there
is nothing to indicate an ongoing conversation with a tester, a stake holder,
the project manager, or even a “buddy developer”. The architect is listed as an “additional
performer” Oh by the way, one of the first steps “understand the requirements”
suggests the developer should talk
to the analyst, shouldn’t
the analyst be listed as an
additional performer? The way the process is documented it could be seen as
encouraging a caste system and document based isolationism. Agile
Methodologies may be inadequate for coordinating action
The next controversial assertion that I want to make is the agile
methodologies may be inadequate for coordinating action. This may be one of the
factors that inhibit scalability. Taken to the extreme (pun intended) a strict
reliance on tacit knowledge, refactoring, and emergence leads to local
optimizations at the expense of the overall system. Architecture and
Requirements are collaborative tools to foster coordination of understanding
In my humble opinion, architecture and requirements are still
important, and this leads to my final controversial assertion, that in OpenUP
architecture and requirements are powerful collaborative tools that enable to
the team to collectively build a common understanding of the project. Based on this last assertion I am planning to write things like Like all UP processes, OpenUP has architectural focus. In
OpenUP however, the intention behind the architecture is to serve as a
collaborative tool that helps project participants build a shared common
understanding of the system. The purpose is not to create pretty UML models,
rather it is to ensure that not only does each project participant see the big
picture, but they see the same big picture. Of course there are other consumers of the requirements and
architecture, but I see the primary role of the architectural artifacts for the
development team as a focal point for coordinating the mental models they have
of the system and providing a vocabulary for reasoning about the system. Summary
Here are the assertions that I think are controversial (or at least may
raise a few eyebrows):
I think from the above you see the outline of the white paper. So
before I get too deep into this, I want get your feedback. After all while
these may be my assertions, this is a collaborative effort J Best regards, Steve Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever. This email and any files transmitted with it are confidential and protected by client privilege. It is solely for the use of the intended recipient. Please delete it and notify the sender if you have received it in error. Unauthorised use is prohibited. Any opinions expressed in this email are those of the individual and not necessarily the organisation. Xansa, Registered Office: 420 Thames Valley Park Drive, Thames Valley Park, Reading, RG6 1PU, UK. Registered in England No.1000954. t +44 (0)8702 416181 w www.xansa.com |
_______________________________________________ epf-dev mailing list epf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/epf-dev