There might also be a need to apply the (genuine) scientific method here.
One of the problem with up-front specifications is that they are usually
ambiguous, and therefore untestable. It's almost impossible to tell from a
set of use cases or an analysis model if they actually got it "right". You
mend up having to deliver working code - and when you do waterfall
development that means going to enormous expense just to check some
assumptions...
I see iterative development as a series of "theories" put forward which are
then tested against "reality" (such that it is) to see if they fit the
facts. One of the problems we face is that reality is a moving target. The
inherent complexity of business (or any endevour involving so many complex
components like people, organisations, markets, economies, weather systems,
etc) makes it very difficult to pin down. So, not only are we looking for
the "right" answer through a series of best-guess solutions, we must deal
with the fact that even the most accurate models only stay accurate for a
limited amount of time.
I'm reminded of a Dr Who episode where a fantastically intelligent machine
was sent to Earth millions of years ago to classify and catalogue all forms
of life on the planet, only to discover that life kept evolving and making
his catalogue irrelevant. In the end the machine decides the only practical
solution is to destroy all life on earth, guaranteeing that his catalogue
will remain forever up-to-date and allowing him to complete his task.
Waterfall development often leads to similar kinds of insanity, where
project teams try to froce the customer to "freeze the problem" so they can
make it fit the solution they've come up with.
Jason Gorman
http://www.objectmonkey.com
-----Original Message-----
From: Philippe Back (High Octane) [mailto:***@highoctane.be]
Sent: 28 September 2003 08:14
To: ***@topica.com
Subject: Re: Not connected to reality; was Relational Model was RE: [AM]
As they put it in NLP:
"The map is not the territory, what I think being the world is my own
perception of it"
--> as many realities as there are people
while I am at it:
"Language is a secondary representation of experience"
--> information given does not reflect "subjective reality"
As there are as many perceptions as there are people, and as experience
(usually) accumulate, we are bound to live in :
- evolving and inherently subjective realities
Add the emotional component to the mix and a tendency to try to get it
"right" (which is impossible).
The question is then : "how can we build a system that satisfies the
stakeholders and users given that state of affairs ?"
Right now, a way to build such a system is in following a process that
creates "incremental buy in" by the target organization.
By that I mean that we try to lower the rejection threshold for the system.
If user representatives get invited to workshops and see their input valued,
if stakeholders are given a chance to experience what they asked in a
tangible way,
if developers see that they work for real people with understandable
concerns,
if "models" (UML or (active) sketches or data samples) are used to clear the
fog in everyone's head to a reasonable level
then
there is a chance to get the system done in my view.
Philippe Back
www.highoctane.be
----- Original Message -----
From: "Jason Gorman" <***@objectmonkey.com>
To: <***@topica.com>
Sent: Saturday, 27 September, 2003 22:00
Subject: RE: Not connected to reality; was Relational Model was RE: [AM]
Post by Jason GormanAnd of course, let's not forget that programs written in Java, C#, or any
programming language, are also models. Mathematical equations are models.
When I give someone directions I am using verbal models, and the picture on
your TV is just a model... In fact, the distinction between a thing and
information about a thing is pretty blurred. Everyone we perceive is just a
model of whatever's out there, built by our minds. In that sense, nothing we
model is necessarily real :)
Jason Gorman
http://www.objectmonkey.com
-----Original Message-----
Sent: 27 September 2003 20:18
To: Steven Gordon
Subject: RE: Not connected to reality; was Relational Model was RE: [AM]
I did not make myself clear.
The definition of model is not a Rose model. I use Rose model as an example,
because it is something that everyone in the group is familiar with abd
therefore easy to grasp the same concept. It does not matter what modeling
tool
is used, the model definition is th same.
The point I'm trying to get across is that a model is more than simply a
diagram. It is the contents of ALL diagrams plus their semantic meanings and
underlying information that may not be explicitely stated in the diagrams.
Here's an attempt at an example of what I mean. I draw two classes and
connect
them with an association. This could be a model in Rose, but not on a
whiteboard. The difference - in Rose there is an implied cardinality at each
end
of the association, but I chose not to show it on the class diagram, but it
is
there. On the whiteboard diagram there is not. (I'll be happy to respond to
arguments that say that it is there in the whiteboard picture too.)
Similarly, if I print the Rose diagram onto paper, what is on the paper is a
diagram, even though it captures all classes and associations in my model,
it is
not THE model.
These arguments work well for the process group that I am a member of, and
these
are not inexperienced or stupid people that I work with. Does not imply that
these definitions will work for eeryone, but it saves much confusion in my
workplace.
Hope this clarifies a little,
Les.
Post by Steven GordonI could accept this as the definition for Rose Model, but not for Model.
I
could even accept a
Post by Steven Gordondefinition of the form "A Rose Model is ...; The term Model will be
taken
Post by Jason Gormanto
mean a Rose Model except
Post by Steven Gordonwhen the context clearly indicates a more general meaning".
It does your company a disservice to saddle it with an unqualified
tool-specific definition for
Post by Steven GordonModel. This short-sighted tactic will not only limit your company's
current
agility, but may also
Post by Steven Gordoninhibit its future ability to adapt and compete.
Post by Scott Ambler<snip>
On the subject of 'UML diagrams', when I first joined my present
company,
Post by Jason GormanI
Post by Steven GordonPost by Scott Amblerfound that people were using the term 'model' inconsistently. This was
particularly bad, because I work for the process group. After
investigation
I
Post by Steven GordonPost by Scott Amblerfound the most common use of the word was to describe a UML diagram. I.e.
a Use
Case diagram or Class diagram. Whereas a diagram is not IMO a model, but
simply
a view into a model.
The concept I introduced is that the Model is the thing that Rational
Rose
Post by Steven GordonPost by Scott Amblerproduces (yes there's that Rational word again). The diagrams are part of
this
Post by Steven GordonPost by Scott Amblermodel, as is a class or a use case.
It appears that everyone has now got the same understanding, and
conversations
Post by Steven GordonPost by Scott Ambleron the subject of Rose models cause significantly less discussion than
before I
joined.
Just an example of how a glossary can benefit a company.
<snip>
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com
Post by Steven GordonATTACHMENT 1: application/ms-tnef; name=winmail.dat
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------