Thanks to the many, many of you who have sent E-mails of support for the
opinions expressed regarding processes and process maturity.
Dr. Terry Bahill, from the University of Arizona, has published "The
Design-Methods Comparison Project" Page 80, IEEE Transactions on Systems,
Man, and Cybernetics, February, 1998, Volume 28, Number 1.
Terry's Design-Methods Comparison Project is a significant paper because it
actually compares a number of approaches to solving relatively simple design
problems. Although superficially simple, the more one reviews this paper,
the more issues it seems to bring out. Dr. Bahill (and his co-authors)
should be commended for this foot-in-the-door towards establishing cost
effectiveness of various technical approaches.
If Dr. Bahill has no objections, I'd like to suggest that we spend some time
considering his paper on this discussion group as a mechanism to lessen the
arm-waving and perhaps better understand each other's positions.
Here is a simplified copy of the DMC Traffic Light Problem. It is
requested that each SE expert "show their stuff".
To clarify, the system in question (the form) is a Controller System.
The context (that part of the world which influences, or is influenced by the
form, includes the timer, lights, etc.
The Design-Methods Comparison Problem, A. Terry Bahill, et al,
Extracted from: IEEE Transactions on Systems, Man, and Cybernetics, Part C:
Applications and Reviews, Vol. 28, No. 1, pp. 80-103, February 1998.
Statement of The Traffic-Light Problem
There is an intersection between a seldom-used farm road and a busy
highway. A farmer has difficulty getting across the highway,
so we are to install a traffic-light system.
Design a controller for this traffic-light system.
Normally, the highway light shall be green and the farm road light shall be
red. When a sensor signals that a tractor is on the farm road, the highway
light shall change to yellow. After a short-time interval (STI, nominally 10
seconds) the highway light shall change to red and the farm road light shall
change to green. The farm road light shall stay green until the tractor
clears the sensor or after a long-time interval (LTI, nominally 50 seconds),
whichever comes first. Then the farm road light shall become yellow.
After a short time interval the farm road light shall become red and the highway
light shall become green. The system shall stay in that state for a least a
long time interval. After a long time interval the highway light shall be
switched when the sensor detects a tractor. A timer that produces output
signals after short time intervals and long time intervals will be
available. It can be restarted at anytime.
My version of a solution will follow in a few days.
Since Terry Bahill was so kind as to post the Design Methods Comparison
paper, I thought I'd take up Sten's challenge to comment. For those who
haven't read it, it applies a variety of design methods (primarily, though
not exclusively, discrete event system description methods) to a simple
traffic light controller problem.
First, as to Sten's point about applying ones advocated method to the
problem, I have nothing to say. From a systems architecting perspective the
problem is over before it begins. By the time we get to the end of the
problem statement in the paper the architecture is defined, at least in the
terms that I use. The problem statement already defines:
Stakeholders and concerns (farmer and drivers)
A behavioral view (a few traces of desired operational scenarios)
A structural view (a sensor, a controller, and a light)
A performance view (timing characteristics)
Hence, we already know that a satisfactory and feasible solution exists and
its essential structure. The architecture is defined. The authors don't use
these words, but they say as much late in the paper when pointing out that
the problem statement excludes consideration of disparate alternatives
(like a bridge instead of a light).
If I were to apply the design methods I have advocated somewhat longer ago,
my solution would closely resemble the state transition diagram solution,
but would add an explicit structural model of the implementation (two or
more physical block diagrams).
Several general points about art, heuristics, multiple views, and design
progression are illuminated by the paper's examples. As the authors point
out, the solutions offered to this relatively simple problem differ
considerably both in content and in level of detail. Taking just a
behavioral description, the original problem statement already gives a
behavioral description in terms of example operational sequences. The
applied methods mostly try to embody those sequences, rendering not just
the given examples but all other possible sequences. Some do this in great
detail, some in relatively little. From my perspective this is not
surprising, nor is it a problem. Different methods have evolved to address
different audiences, which need different kinds of information. The
informal, example based original problem statement sufficed to allow design
to start. Only a precisely complete behavioral model can eventually be
implemented. On a complex system (for which some of the methods were
designed) it is likely that intermediate representations will be needed and
will have ready audiences. It would be nice if all possible views and
levels of detail could be constructed from a single core representation,
but no such representation seems to be available. Some behavioral notations
are theoretically capable of this, but I have not seen practical examples
of their scaling over problems of very large scope.
Since the focus of the applied methods is description rather than synthesis
we would not expect to see explicit application of heuristics or art. The
heuristics and art are buried in the invisible steps. Given the informal
problem statement of behavior, how do you generate the state machine? The
original statement is not formal, and is not complete, and a potentially
infinite number of state machines could produce the required traces. Who do
you get to one, and how do you select among the many? Thinking about my own
approach to state machines I can see a few heuristics at work. First, I
usually draw a state sequence corresponding to the main scenarios, choosing
states wherever there appears to be a wait with choice. Then I add
secondary scenarios off the main state sequence. Then I try for the error
conditions. Then I see if it all hangs together or if I need to do some
repartitioning. I also have some basic patterns in mind (patterns in the
sense of modern software patterns as prescriptive heuristics) such as
blocks of states that represent logical concurrent states.
It seemed that all the methods drove toward producing a single, compliant
representation rather than a multiplicity with evaluation criteria. In some
cases there was mention of evaluation issues, such as the problem with
concurrent active objects being implemented on a very simple
microcontroller. That, incidently, was a heuristic I learned quite a while
ago. You CAN implement concurrent active objects on any computer, you
shouldn't unless the computer is powerful and information hiding or timing
issues dictate it over a periodic executive structure.
It would be interesting to see the association of explicit synthesis or
model-building heuristics with the methods. Some methods, such as ADARTS
for software, have explicit synthesis heuristics in parallel with a
syntactically and semantically well defined description method. In most
methods classes I been in, including some for the methods used in the DMC
paper, the instructor informally passed on myriad "principles," or
"guidelines," for building the models and choosing among alternatives. This
is just applying heuristics without writing them down, though some of the
classes did that, too.
Something else the paper brings up as larger issue is how to do a serious
comparison on large problems. Experience suggests that a major impediment
to applying methods on really complex systems is the scaling problem.
Things that look good on small problems just aren't feasible on very large
problems. Methods may have "bands" of applicability or suitability along
the project size spectrum. Direct comparison would be desirable, but the
effort involved seems to preclude it. Who is going to burn up man-years
re-describing a complex system in alternative ways?
I certainly thought it was interesting.
Some of the Carnegie-Mellon folks have compiled a list of model problems
for method comparison (mainly for software). Mary Shaw published a
comparison of methods in an IEEE Software article in Nov. 95, I think. I've
used a slightly altered version of one of the model problems, called the
"Host at Sea Buoy System" in my software engineering class at UAH. The
solutions run rather larger, usually 20 pages or so for the behavioral
model, depending on the students cleverness. Not huge, but pretty good
size. It would probably be feasible to run a comparison on that model
problem, but I don't know where you'd publish it, unless as a reference
book to methods. It would be nice to compile a set of model problems,
although organizing the documentation might be a formidable task.
Anything new coming out in the Systems Engineering series? The latest I
heard from CRC Press on our book indicates it must have gone over 3,000
copies sold. That is really more than I expected.
I find that there always will be a need to translate an original problem
into a problem statement that the developer or designs understands.
Ideally, it is better is the developer and the original problem owner come
to an agreement on the problem. As Mark suggests if you get a clean sheet
of paper to begin the discussion and search for solution, his concept of
an architect is needed. In many cases, you get a problem that has a lot
of constraints and system definition that have been already made. You
still must translate such problems and reach a shared vision on what the
developer thinks the problem is. Terry's et al paper attempts to develop
the shared vision of a fairly well defined problem. This is not a trivial
systems engineering effort as can be seen from the paper. There are still
a lot of assumptions and decisions that are made during the translation of
a problem by the developers. Every day in class, students take well
defined problems and interpret them much differently. On the job, this
same thing happens when an employee has a different view of the problem
that those that assign the problem.
At any level of product development, the ability to decompose the system
definition one level is not trivial, and graphics and formal languages are
more precise, but can be more confusing if the stakeholders do not
understand how to read the graphics and formal languages. As a result the
methods used are often not the most appropriate method, but the easiest to
understand, which unfortunately is text. Rather than search for the best
formal language or graphic representation, INCOSE needs to continue the
stimulation of translators and more comparison of methods. In the long
run may be a simple, yet powerful language can evolve which will allow
developing shared visions of any system component at any level.
Randy,
Of course the Traffic Light problem statement is incomplete. What system
have you ever worked on that didn't have an incomplete problem statement.
If Terry Bahill were to start selling problem statements, he could charge
extra for this one. There are many other real life aspects to the Traffic
Light problem which may severely stress some approaches to SE.
I love it! Now we are getting to what I think separates SEs from other
engineering disciplines. Here we are given a very specific problem to solve.
The traditional engineering disciplines (I am stereo-typing terribly here) will
go at it and come up with a very elegant solution to the problem stated. The
SE, IMHO, looks beyond the problem, as stated, to what is the need that is not
being satisfied and what is the context of that need. The SE anticipates issues
that will fall outside the very specific problem statement to satisfy all the
stakeholders as well as possible. Why do we need a signal control system in the
first place?!
Would each of you be so kind as to apply your "FRAT" (or preferred
approach) to the DMC Traffic Light Problem and submit it so that we
may include it in
the comparison analyses to follow? This is a valuable opportunity to
significantly increase our understanding of the strengths and weaknesses
of each approach.
Perhaps we can set aside some of the posturing for a while and just let
the technical results speak for themselves!
James,
This is the first time, to my knowledge, that we have some some chance of
dodging the consultant's crutch of un-defined terms and jargon and actually
seeing some meat, instead of all bun.
Many of us are very much looking forward to being able to finally understand
the technical excellence of each respective approach on its own merit.
Please let 'em rip!
After review of the traffic controller User Case, I
extracted a few requirements and did a trade study
on the value of designing it myself, or communicating
the requirements in an RFQ and asking sub-contractors
or supporting government agencies to respond with a
proposal.
Due to the time and cost savings, I decided to submit
an RFQ and award the contract to the best proposal based
on the technical solution, cost and schedule.
Since this problem was based in a rural setting in the
county, I reviewed the responses and awarded the contract
to the Department of Transportation for this county.
The light was installed, tested to the requirements and
will be maintained by the County Highway Department
throughout it's life cycle.
The DMCP (ref: Bahill et al, "Design Methods Comparison Project" IEEE,
1998) is a trivial *toy* systems design problem that concerns a fully
*precedented* system (a traffic light) that each of us has observed
thousands of times in operation. Comparison of the 11 "solutions" using
different methods has absolutely *no* relevance to solution of
*realistic* systems design problems, particularly those related to
*unprecedented* systems!
Indeed, all the paper proved to me was: (1) any of the methods could be
used to solve this *toy* problem and (2) none of the authors have ever
designed a real traffic control system (nor have I).
Of all the posts so far on this subject, only RNewman raises real
Systems Engineering questions about the *Problem Statement*
RNewman wrote:
Indeed, real Systems Engineering does not consist of blindly following
the Problem Statement, but of questioning it in the light of stressful
cases and failure modes. Before jumping to the detailed design step, as
the authors did, one must *derive* requirements that are implied by the
stated requirements or by common sense. Detailed state diagrams and
multiple-view charts or the *wrong* problem are of little use!
For example, a traffic light system should be designed such that:
1) Lights are *never* green for both the highway and farmroad.
(Figure 14 has the order wrong, "2. Command HW light green" *then* "3.
Command FR light red" !!! Although some of the authors asked whether
there was a confirmation signal that lights actually changed, none of
them included fail-safe logic to assure that traffic light failures, or
vehicle actions did not fool that system and lead to accidents.)
2) A tractor or car parked on the farmroad does not cause the system to
cycle repeatedly.
(The problem statement needs to be interpreted correctly when it says:
"Sen=1 the sensor is detecting a tractor (or car) *on* the farmroad". In
Figure 23, for example, if there is a parked "car waiting" on the
farmroad, the Controller will continually be triggered to command the HW
Router to "Change to red". The system should react when a vehicle
*appears* at the intersection.)
4) A car that turns from the farmroad onto the highway does not cause
the system to stop operating.
(In Section K, the author assumes a "tractor clear event (Terminate TR)
[that] provides a signal that the tractor is safely across the
highway". That signal will *never* appear if a vehicle turns from the
farmroad onto the highway, so the highway lights will be red forever.)
5) Horse-carts, people on horseback, bicycles, and pedestrians can use
the traffic light to cross the highway.
(None of the authors suggested a push-button for use by vehicles or
pedestrians incapable of triggering the automatic sensor.)
--
Ira, et al,
I had a high degree of confidence that a number of individuals would choose
to address the DMC Project technical challenge by criticizing the problem
instead of providing their approach to a SE solution.
You have not earned the right to offer criticism of the solutions provided
until you have shown us the "right" way. It would be rude and disrespectful
to trivialize the work performed by our colleagues and I'm certain that you
did not intend to convey what seemed to come across in your message.
Consider this a formal glove slap to your face... Show 'em if you got 'em,
or kindly mind your peace. A number of highly regarded experts have taken
advantage of this opportunity to share their approaches with us. If you
don't choose to do so, that is your right, but please respect the effort
that has been put into this thus far and the rights of others to carry this
forward for a while. Many, many people have been pleading for such a
comparison for a long time. I have received over 30 personal E-mails in
support of this!
This is a severely constrained problem, by design. It has been
over-simplified, by design. If you have been unable to comprehend this, and
the merits of what Terry Bahill is attempting, then I suggest that your
words impute your support for the INCOSE goals of fostering communication
and understanding of SE.
The issue here is to compare technical approaches to SE. Please direct the
rocks at those who would strive to deny us the rare privilege of working a
common technical problem and comparing results.
The alternative seems to be endlessly arguing over un-defined terms- is that
what you would have us pursue? If this problem is too narrow, suggest a
"better" one for next time.
Ira, et al,
Please add the words, "A sense of fairness would suggest that", prior to my
statement about 'You have not earned the right to offer criticism of the
solutions provided until you have shown us the "right" way" and the words
"in my book" to the end.
It is, of course, everyone's right to criticize anything. I am trying to
suggest that a sense of "fairness" would have you provide the better
alternative to what has already been provided, rather than merely dismiss
the merits of the work.
I apologize for the imprecise choice of wordings in the earlier E-mail.
Sorry to have raised your hackles. I did not intend to be "criticizing
the problem instead of providing [an] approach to a SE solution". The
problem statement, as it appears in the DMCP paper is better, more
detailed, and more on-point than most I have received in my professional
career.
One of the points in my response is that even the *best* problem
statement does not contain *all* requirements, and that the *first*
thing an SE must do before jumping to a solution methodology and
cranking out logic equations and view diagrams is to consider stressful
cases and failure modes and *derive* the *real* requirements based on
them and on common sense. This, as shown by my few examples based upon
faults in the published "solutions" (unsafe due to green lights both
ways, repeated cycling due to car parked on farmroad near intersection,
highway lights red forever due to car turning from farmroad onto
highway, no provisions for pedestrians and other traffic that does not
trigger auto sensor) was *not* accomplished by any of the authors.
My second point was that *toy* problems provide limited (if any) *real*
insight into the usefulness of alternative methodologies. During the
frenzy about Artificial Intelligence some decades back, great success
was reported in endowing computers with "general" intelligence. Indeed
many very smart people (including me) believed that success with *toy*
problems was an indicator that AI would soon solve *real* problems.
Unfortunately, the techniques that worked so well for *toy* problems
failed to work for *real* problems, and the bubble was burst. It turned
out that the problem of *searching* a solution space had been solved,
but the much more difficult problem of *defining* the solution space for
a complex problem was not solved, and that it was the more difficult
part of the total problem.
As far as your "Show 'em if you got 'em," challenge, I don't see the
need to join the other methodology experts in shooting cockroaches with
a cannon. If you want the solution to the traffic light problem, I'm
sure there are dozens of companies out there with ready made,
time-tested, fail-safe solutions, and I'll bet *none* of them used any
of the 11 methodologies in the DMCP.
However, I am sorry that my post appeared to "be rude and disrespectful
[and] to trivialize the work performed by our colleagues". That was not
my intent. The DMCP paper has considerable value in *describing* and
*comparing* different methodologies, per se, and I agree that such
comparison would have been unwieldy if a more complex, unprecedented
system had been the subject of this exercise. The paper serves a useful
SE purpose in demonstrating different detailed design alternatives.
However, as many of us found out in the AI debacle, *defining* the
problem space adequately and correctly is far more difficult than
searching that problem space for a solution.
Whether Bahill's DMC article accomplished its goals can be debated, but I
think it has some real value in addition to generating this discussion.
First, it lets us look at a set of different methods, with a common
reference system - no matter how real. The miles/gallon figures shown on
new car stickers aren't realistic relative to YOUR driving, but they do
permit some comparison so long as they aren't looked at at gospel.
Second, it is interesting what is NOT covered and discussed in any of
the techniques.
In respect to comparing techniques, it seems to me that there are many
major overlaps among them. In fact the overall scope of approach and
content is relatively narrow. In some respects this isn't surprising. When
Yourdon started the structured analysis frenzy, it didn't take long for
some of us to see some shortcomings. The result was a profusion of variants
developed to deal with the perceived problems. Ward-Mellor is one of the
best known, but far from the only one. It seem to me that we still have
essentially the same basic grouping of techniques - functional analysis,
structured analysis and object oriented analysis. Changes to the symboloby,
symbol names or adding/subtracting a view still leave the basic approach the
same.
More significant to me is what isn't covered. The DMC article deals with
sequential machines, and emphasizes the software logic of the problem.
However, the real world problems of new systems involve much more. Parallel
processing, shifting state definitions, systems for which distinct states
may not be definable, decision making in its many forms, so called
intelligent software, human decision making and the tendency of people to
bring extraneous data and processes into the system operation, etc. etc. To
use the example in the article of the restaurant kitchen, I don't know of
any busy kitchen where sequential processing of food occurs. If three
customers order linguine with different sauces, resource allocation puts
all three orders of pasta into one large pot to cook, while the chef(s)
work on the different sauces at the same time. That is a more realistic, if
far less analytically tractable, system. Where are the tools to deal with
that? Perhaps a modeling approach is the way?
And, leaving most important to last, where is the discussion of system
context and environment. A real world system exists to perform a function,
embedded in an environment. As my earlier post indicated, more
consideration of that environment is needed. The traffic problem as written
might apply here in New Jersey, where farms are an endangered species,
sometimes literally split by a highway to housing. But in much of the
world, even if there is an intercity highway, the farm traffic will be
animal powered carts, not tractors, and the solutions given here won't
apply. A system exists because of, and within, some environmental
consideration, and we need to consider environment in our analyses.
Finally, from all this, I come to a conclusion. The underlying problem
with selection of tools is only partly that the boss likes one. More
critically, the problem comes from an inability to identify the parameters
of the system function and structure as they relate to the tools and to the
system mission. Several people have noted that one tool doesn't fit all
systems. No one has come up with a means of determining how well a
particular tool satisfied a particular system problem. What we don't have,
and do need, is a "correlation function" to relate the two. Its an
interesting problem in itself, and far from trivial. It will require new
definitions of relationships among functional and environmental variables
just as a start. Maybe its a project for the SE Center of Excellence.
Richard Newman
I think we are once again seeing a difference in definition of what
people consider "systems engineering."
It seems Bahill and the others who are asking for "systems engineering"
solutions are talking about systems analysis: call it functional or
requirements analysis as you will; I lump them both together under the
"system analyst" role.
It seems John Nallon is taking the "technical manager" role and
government-customer point of view when he is saying how HE would solve
the problem, namely award the contract to the county Dept. of
Transportation. My husband pooh-poohed Nallon's approach when I told him
about it, but hey, lots of people call what he does "systems
engineering." Who is to say the system analyst role is "real" and John
Nallon is "kidding"? I think he was serious!
Ira Glickstein took what I would call the Glue and maybe Customer
Interface role, or even doing a good job at Requirements Owner (what Joe
DeFoe used to suggest you do is "try to break the requirements") in
looking at ways the problem statement might have been deficient. This
is seriously good systems engineering to some people. I did not take
Glickstein's post to mean Bahill was wrong -- just that there is more to
good systems engineering than just solving the problem as defined. Some
people try to see if the definition is right and add to it.
I am glad we are having this dialogue. I hate to see people throwing
rocks at each other, and as a result I have been absenting myself from
this discussion for a while (particularly when two or three people post
more than one or two notes in a week whose entire content seems to be,
"Here is why you are wrong"), but I think we are learning some things
here.
1. If you pose something as a "systems engineering" problem, people are
going to answer or criticize it according to their definition of systems
engineering, which is likely to be different from yours. If you pose it
as a "systems analysis" problem (or other role, perhaps), this is
narrower and perhaps more specific, and most people will either play
according to your rules or hold their peace.
2. Perhaps we should define the kinds of questions we want to answer,
and scope the problem tightly. I did not pay much attention to the
initial posts due to pressing work problems, so I am not sure how
tightly the original problem was defined. Did it include the following?
a) an admission that the problem was toy
b) a request to "suspend disbelief" and play along
c) a promise of the benefit if you did that (we will be able to rank
different methods' applicability to this problem and maybe generalize to
others)
d) a "system boundary": saying what we are NOT looking for, e.g. other
ways to phrase the problem, points of view other than systems analyst,
etc.
Maybe if it was, we wouldn't have hard feelings. Placing the problem in
context often solves problems in advance.
Advertisement:
See "12 SE Roles" paper in INCOSE '96. or download it from the WMA
chapter web site at
http://www.vtcorp.com/wma-incose/library/resources.htm.
Personal opinion on the DMC problem:I know one of the research topics
proposed to the SE Center of Excellence is what methods are best applied
to what kinds of problems. I think the DMC problem is a step toward
determining that. Very few INCOSE-discuss participants would pooh-pooh
research results that rate applicability of different methods to solving
various problems. The fact that this is a toy problem means it is doable
for a first step, and I assume this will lead to more and better
solutions in the future. So I say "Go for it."
I have not responded to the technical problem, because my strength is
not in systems analysis. Others are far better at applying methods and
tools, and have fun doing so. I do not go to bed at night wishing I'd
had more time to do a case study in detail. You guys play, you will
have fun, and maybe it will help me eventually. Thanks!
Let me extend Sarah Sheard's comment a little.
One of the first questions we should always ask is the C question:
If someone starts talking about a "strike" you would likely ask whether is
in connection with a union, bowling, baseball, assault and battery,
lightning, or something I haven't thought of. If you heard someone talking
about "10 strikes in a row" you might think that baseball is the wrong
context might not be baseball.
Sometimes we assume that we are in the same SE context with everyone
else. We just are not accustomed to asking the "C question." For me, one
of the major uses of Sarah's 12 Roles paper is to explicitly identify the
context and get everyone on the same wavelength.
Bill Schoening
I believe that the systems engineering process requires all
of Sarah's types at some point in the process, even the classified ad
specialist. I will try to map out who does what in my second draft.
I will read Sarah's paper after sending you my stuff.
I hope to have time to compare all methods and give you some input.
My first impression, is that one from Cal State Fullerton was interesting.
More later.
At 9:33 AM 4/2/98, Terry Bahill wrote:
Terry, Sten -
I am very enamored of the DMC project that you have undertaken. I have no
idea what your funding status is, nor your future plans for the DMC - but
Dennis Buede and I were both very interested in adding it to the list of
potential SECOE projects. He and I spoke on this a couple of weeks ago.
The recent flurry of discussion list activity only makes the desire
stronger for me.
I can picture extending the project significantly. The current approach
has been criticized by some as being too constrained a problem. The
responses have been criticized as coming from different SE "roles."
Perhaps a far more complex problem, addressed by widely-spread experts in
specific approaches, with results evaluated by a different group of
"customer advocates," would yield an even better result.
Another approach would be to make the extension of the DMC compatible with
the SECOE project 98-01. Then the data gathered during 98-01 could feed a
more extensive analysis of design methods comparison.
What do you think?
From terry Wed Apr 1 09:55 MST 1998
>Terry, Sten -
Contrary to what Ira G. said, I think we can learn much more from this
"toy" problem than we can from a real-world problem.
Perhaps after we all agree on this toy problem,
then we could approach a real-world problem.
However, I would enjoy seeing solutions from all of Sarah's 12 roles.
We have 12 solutions from designers.
Sanchez has given us an SE solution (at one time we had 2 others).
We also had one from John Nallon (?) that seemed to be an administrators role.
This extension would not cost much money, just my time and money for a secretary
By the way constructing a good problem is Really hard.
I would be willing to try to find a new problem out of the 98-01 project,
but I would guarantee nothing.
I sense from your response that perhaps my original words came across
wrong. I was *not* criticizing the project - only citing some of what I
saw from detractors.
I think what you're doing is outstanding! And it is drawing an excellent
discussion from the list, as well as several more inputs. If I can find
some time to think about it, I'll try tackling one of the other lesser-used
SE roles.
My offer was *not* to replace or denigrate what you've done already and are
doing. I agree that even a model problem ("toy" seems to be a put-down to
me) has a great deal to offer in learning. Rather than putting it down, I
was looking ahead to how to get funding to do even more in the same vein.
Andy, Dennis, Eric, Terry, Wayne, and Wolt,
I have included myself in the address field so you have my correct work
address. Your message just barely squeaked through the Boeing firewall
and addressing filters.
It is my opinion that Terry's DMC Project offers the potential to
proceed to a new level of technical communication within INCOSE, if we
pick up the ball and run with it! By focusing on a specific problem
and examining the effectiveness of alternate techniques we may start to
actually establish technique/method/process cost effectiveness. It also
offers us a means to try and get off the endless discussion of
un-defined terms bandwagon.
However, this will only happen with your understanding, agreement, and
support. There are a number of conflicting agenda within INCOSE which
tend to undermine much technical agreement.
The DMC problem is actually much more complex than has been identified
on the incose-discuss web. It offers where is the system as an issue,
who is the customer, incorporation of commercial OTS interfaces,
significant effectiveness parameter/functionality trade-offs, hidden
regulatory authority issues, and a whole wealth of nuances. It provides
the opportunity to clearly establish the difference between SE and
design engineering in terms of practical results, the primary/secondary
functions of SE, and start looking at the cost-effectiveness of SE!
It may be worthwhile to devote the Concepts and Terms WG meetings in
Vancouver to detailed exploration and characterization of the DMC
solutions. If we can get past all the terms confusion and arm-waving, it
is likely that we will rapidly find that many of us are actually not
very far apart technically- just speaking in Latin, Greek, Russian, and
French equivalents.
Please advise if you have a problem with where we are headed with this,
or have a better idea.
What a wonderful discussion! Even the simplest problems have
something to offer in lessons.
-------
One of my own very personal "lessons learned" had to do with
questioning the requirements space.
It was about ten years ago that I was the chief system engineer for a
$20M job. The customer had given us, as part of the contract, a
*very* detailed specification. The requirements analysis phase of the
project was therefore made quite easy. My team was proud of the
detail and correctness that we were able to apply to ensuring that
each requirement was well-stated, that all the requirements fit
together, and that the performance/functionality all worked to do what
the customer wanted. In so many systems projects, it is pure luxury
to have enough time to do all this analysis properly.
We involved the customer (COTR) in the analysis, with several
preliminary meetings to get his concurrence on our analysis and
conclusions. He was also pleased with the thorough analysis. We held
a preliminary System Requirements Review (SRR) with a core group of
customer people, which went smoothly.
Then we held the formal SRR. For the first time, the COTR's boss (a
Navy Captain, if it matters) was able to see the results. As things
progressed, he was obviously becoming more and more uncomfortable. In
the middle of the presentation, he called into question the *breadth*
of our analysis. Had we really looked to see if the requirements were
needed? He became quite upset at the answers and verbally considered
giving a formal thumbs-down to the SRR.
(Reset. Wait a second. We had a *contract*. These detailed
requirements were part of the *contract*. Such an analysis would be
definitely out of scope!)
There was a reason behind his upset.
It seems that a companion program had just been proposed
competitively, and *all* of the bids were over the cost budget.
Without the companion system, our system wasn't needed. If we had
taken the initiative to identify lesser sets of requirements that
could suffice, then the parent program might still have succeeded.
By our SRR, however, it was too late. They had to make a decision.
They canceled the companion RFP. And they terminated our contract
for convenience. We had done everything contractually right, but...
Always watch the broader view. Always.
-------
Maybe an *overpass* is the right solution to the DMCP.
Dear Terry,
When the DMC problem hit the INCOSE-discuss list I was underwhelmed.
It seemed not to be a system engineering challenge at all (unless one
considers a system to be a board with THREE chips in it). Hardly the
problem that 777's are made of. But with a long-time respect for any of
"Wymore's Weenies," prodded by Sten's urging to "let 'er rip" and tired of
the chorus of naysayers, yes-but'ers and non-doers I took a small envelope
and proceeded to jot a diagram on the back of it for your amazement or
amusement. I am now up to a large envelope and printing very small. (I
see you smiling.) The DMC has been quite a mind opener. Mainly, of
course, for the reason that if we can't solve the little, tightly
constrained problem how can we hope to solve the bigger ones (other than
carefully selecting dumb customers, but fewer of them seem to be still
around.) After all, a pool table with three balls on it is a systems
problem. Also, I was motivated to show that the baroque decor of some of
the 11 solutions seemed to be more due to the "hierarchical decomposition"
glasses worn by the designer than to the inherent nature of the DMC problem
statement.
Separately, and hopefully by Monday, I will be sending you a file (in
WinWord6) in response to the DMC problem. The file will contain;
1) a description of the system design. This includes predictions of
cost, reliability and safety factors which were not specifically requested
in the DMC problem statement but which I feel are a requisite part of a
systems-level design materials.
2) notes to your design validation agent regarding the system design.
3) notes to your method comparison agent regarding some important
aspects of the method.
4) notes to your design and implementation phase Project Manager(s)
regarding recommended steps for a) confirming the design with the Sponsor,
b) confirming that the component-level engineers understand the design
materials and the underlying technology assumptions and collaborating with
them to improve and refine the design and its allocation to components and
c) confirming that the (presumed) validation and verification engineers
understand the design and the underlying technology assumptions. These PM
notes were not specifically requested in the DMC problem statement but
likewise are felt to be a requisite part of systems-level design materials.
I understand that your interest is in comparing the methods used to
engineer a system-level solution. I look forward to the comparison. But
I suggest, also, that you compare the resulting designs in terms of
implementation risk, system reliability, Total Cost of Ownership and other
such factors that will be important to a sponsor -- and even to a farmer on
a tractor. Regarding implementation risk, I encourage you to compare the
methods in terms of the how well the solution is represented/communicated
in the design materials. This is because "specialty" engineers will have to
design and develop the components called out in the design materials and I
think it is important that you evaluate how well the materials communicate
with these engineers and encourage their creativity in nominating component
solutions. These suggestions are not meant to predict MOE's for SE methods
but simply to highlight some potential discrimminators that may "separate
the variables" among the example methods.
This DMC design was produced according to a Complex, Adaptive System
Modeling, CASM, method that I have been evolving over the past few years.
The details of CASM are currently proprietary (my clients already know the
value of SE) so my response to the DMC problem is being sent directly to
you instead of being posted on a web page. I think enough of the method is
visible to explain how the Problem Statement was transformed into the
design materials but you will have to be the judge of that.
As you will see, the CASM emphasizes finding the problem and problem
intervention strategy, first, before designing. In the DMC case, although
the problem presented to the "contestants" is Design a Controller the real
problem is framed by CASM as "the allocation of a scarce resource, the
intersection of the farmroad and highway." The design materials will
conform to your requirement by presenting the system-level design of a
(distributed) controller but the method provides a viewpoint that makes the
design quite simple. How about a tractor object, a resource
allocation/scheduling object and an interlocutor object (to control the
light)? Looks like the components will be one each microprocessor, a
LonWorks(TM) comm/control chip, and less than 50 Jave statements (but, of
course, those decisions will be made by the component engineers, not by
me)?
The CASM method is different from the EIA 632 and similar prescriptions for
Systems Engineering because it presumes that practitioners of collaboration
and discovery will outperform practitioners of omniscience and prescience.
The method is based on the advice that form follows function, thus is
oriented not only a) toward the design of systems which are composed of
distributed, cooperating modules but also b) toward a method of design that
is composed of distributed, collaborating modeling activities and is even
oriented c) toward distributed (dual lobe), co-learning decision processes
in the minds of the designers. Whee!
Only part of the CASM method was used because the CASM method features
spirited design reviews but this has not been possible for the DMC case
because there is only one of me (see, SE is larger than an integer person).
Therefore, you will be the first design reviewer as well as method
reviewer. If it becomes necessary to clarify the design or to correct
errors, please let me know. In parallel I will seek other review
resources.
If you conclude that this example passes your review and is pertinent to
your comparison objective, you are hereby granted permission to include my
materials in your other materials or on your web page.
I hope to publish more details on the method in 1999. In fact, the real
target method is the Optimal Response Complex, Adaptive System Modeling
method, ORCASM, but as you might imagine if am have a little difficulty
getting the Service Mark approved, let alone new personalized license
plates.
Also included on the diskette are some comments regarding some of the eleven
methods described in the IEEE paper. For example, assuming you are
familiar with computer-based aids to music composition, I think you will
find that the CASM method is rather like being able to compose a melody,
associate it with harmony, try different chord progressions and meters and
even transpose keys, all automatically. In contrast the majority of the 11
methods presented so far seem to be oriented towards figuring out where to
punch the holes on a player piano role.
After all of this, if I can't get my design past a Design Review, I can
always claim April Fool.
till then,
At 10:11 PM 4/1/98 -0700, you wrote:
Jack,
I enjoyed reading your CASM and ORCASM "theses". Like Martin Luther, you
have eloquently stated your case and "nailed them to the doors of the
cathedral".
Now, let's see if this results in a "Reformation" ... or perhaps *merely* a
Protestant Movement.
Moreover, within this domain, there are several currents of analysis that
don't rely on examples. For example, is the method sufficiently precise and
structured that it can be machine executable? Does the method include
continuous or discrete-time system behavior as well as discrete event? Can
the method descriptions be synthesized into implementation (code, gates,
etc.)? Are the products of the method readily understandable by
non-specialists?
If we are looking for a larger problem to compare system design methods on,
I recommend the following characteristics:
1. The required behavior should involve the interaction of continuous,
discrete-time, and discrete-event systems.
2. Solutions should represent the physical implementation, and cover
several disciplines.
3. There should be additional quantitative requirements involving issues in
several design dimensions (Ex: sensitivity that includes disparate physical
as well as functional characteristics).
4. The problem should include some significant retained data complexity
The Host-at-Sea problem comes close to providing these elements. It also
has a considerable history of being used as a methodology comparison
problem. It is, however, too large for a comparative study in a Journal
paper. When I've done the problem (in an ADARTS class and in my own
classes) solutions run 20 to 50 pages. I'll post my version (modified for
use in a class) of the problem next week, but it needs a few changes to
make a real system design problem rather than a software oriented problem.
There are several versions of this problem floating around, as well as many
solutions using different methodologies. You won't find them in journals as
they are too long. I believe the model problems web pages at
Carnegie-Mellon has pointers.
When I was more interested in design methods I published a problem and
solution with most of these attributes. You can find it in the Journal of
Systems and Software, with a reference and information at
http://eb-p5.eb.uah.edu/~maier/ In the architecture area there has been
some direct comparison associated with intelligent transport systems.
Excerpts of my approach were published in the Joint INCOSE/IEEE AES Journal
issue. The references point to many of the alternative approaches. There
are pointers at the previous web site.
If we are looking to compare process oriented standards we need model
problems that are intended to produce process oriented solutions. I am not
aware of any, but maybe others can suggest something.
And Sten, if you are throwing gloves, remember that the throwee gets to
pick the weapon :-)
Mark,
You have made many good points. There are many problems which could be
stated to expose other strengths and weaknesses- let's bring them on. I
also agree that the glove slapper doesn't get to pick the weapon. In this
case, however, the challenge is to show your proposed technique to solve
this problem. The weapon is the technique you elect to apply. In my mind,
this is only a round 1. The bout may go on for awhile!
If there is one technique which works best on all problems, then this would
tend to support the process maturity folks. If various techniques have
various degrees of effectiveness, depending on the problem, then this might
suggest that we should carefully examine the parameters which drive
technique effectiveness. It is my experience that each SE practitioner
picks one technique or approach, which they then call SE- wouldn't it be
extremely valuable to know when a technique is cost-effective, and when it
is not? ... or to confirm that your's is best? ... or that mine is worst?
Aren't we all tired of endless arguing, mostly over terms? Our terms are so
fuzzy that we can't even have a very satisfying debate, because one never
really knows if we actually disagree. I think I disagree with you about
several things, but am not sure enough to engage in a civilized engagement.
If we can get each expert to show their solution approach to one problem,
then we will have a place to start in actually understanding each other. I
will gladly tackle your choice of problem if you will show us your SE
approach to this one (DMC Traffic Light).
With regard to this problem, it poses many of the actual issues that we face
in developing systems- issues such as: where is the interface; Off-the-shelf
equipment; who is the customer; what is a "good" system; what functions are
required; where are the requirement manipulation advocates going to get
their requirements from; and on and on. To me, the potential complexity of
the system, such as interaction of continuous, discrete-time, and
discrete-event systems is a second-order aspect. I'm suggesting that a
valid approach should handle relatively simple systems, also. The DMC
Traffic light actually includes far more than meets the eye!
Terry Bahill and many others have put considerable effort into what is a
very good start. It is not the problem I would have posed, nor what you
would have posed, but it is the problem which was posed. If we nitpick his
problem, we probably never will get around to solving anything!
Let's generate some solutions and look at some results --then we can have
some real debates!!
Hi Terry
Many thanks for the paper you mailed about the design methods
comparison project. I have thought for some days that I should comment
on it, but been too busy with my own projects (are we not all?).
However, some fast comments:
I do agree that you can and should view systems as collections of state
machines.
The example does not include requirements' analysis:
- what happens if the farmer parks the tractor on the sensor. Seems to
me that at least some of the designs go into a slow loop. Error in
requirement: it is not sufficient that the tractor is on the road, it
must show some kind of intention of crossing!
- what happens when there is a horse or a bull on the farmroad?
Missions:
None of the solutions seem to have considered what the missions of this
system really are:
- allow the farmer to cross the highway
- keep fast traffic flowing on the highway.
Maybe the missions are too simple in this example?
The table II
I do not like this one. It is in the tradition of bad programmers
calling their variables "a", "b", "q" etc and forgetting what they meant
at debugging time. I prefer understandable names. This is a problem with
many notations: if you cannot get it both formal and explainable to the
end user you will not understand your real errors until deployment time.
Fig 6 and dependability
I may not have understood this one or maybe I read too much into it, but
it seems that if the red light on the highway fails, the farm road will
still get green. I do not see the dependability analysis.
Fig 8, missing phase?
Seems to me that this figure shows a perfect world where you can go
directly from installation to a working system without any test phase.
Seems a bit too simple.
Fig 9
I like this one as it includes the dynamics of the system. A closer
study may reveal why this system solution is rarely seen: the detection
and deacceleration ranges will probably show that the system will not
work in misty or snowy conditions?
Fig 10
This one is difficult and I did not quite figure out if it is sufficient
for the tractor to arrive or if it must leave the sensor before the
lights are triggered. However, the solution is interesting as it shows
the need for state-machine graphics to be accompanied by explaining
text.
Fig 12
Good one, the need of acknowledgment understood.
I also looked a bit on Cafe problem. Not too simple, but can be modeled.
reminds me of the air force problem with the fighter commander who needs
to deploy his (few) fighters to take care of the incoming bombers.
Your paper has in fact taught me a lot about the state of the art in
this area. I am really grateful for that.
If you are interested in a free systems engineering tool for education, I
can tell you that we plan to launch a new web site late next week
(http://www.toolforsystems.com). For the time being it points at Romet's
website but soon the new site will include free download of the Tofs
tool (educational version), working after the compositive
object-oriented principle. The educational version will include full
functionality for education and evaluation, but limited performance to
give commercial users a reason to buy the product.
Thanks again for the paper and you tip of above/Ingmar Ogren
--
These are my comments after organizing the above
comments from the International Council on
Systems Engineering (INCOSE) discussion site.
First we tried very hard to present a very restricted problem statement.
We also restricted each author to two page solutions.
Yet we got tremendous variability in responses.
There is a lesson to be learned here.
Second, we did not provide figures of merit to determine the "Best" solution,
because we did not want our authors to design their solutions
to fit our criteria.
We let each of our authors do their best and we let the journal readers
decide which methods "seem" the best.
There is a lesson to be learned here, too.
Third, Systems Engineering is expensive.
The published paper is 24 pages long and includes a dozen design methods.
The Systems Engineering solutions that were generated were not included,
because they were 25 pages each!
And we would have had to pay mandatory page charges of $175 per page.
We all know that expense is a problem with Systems Engineering.
Fourth, length will not be a problem for web solutions.
So, for those who want to see Systems Engineering solutions,
please write some, give me the URL and I will link them.
For people who cannot post their own solutions,
because of fire walls, lack of web access, or other reasons,
I will provide a site, but little support (I have no money).
I am going to group the solutions according to Sarah Sheard's
categorization of the 12 Systems Engineering roles
.
The first group will assume the Life-Cycle Roles,
which include Requirements Engineers, System Architects,
Validation and Verification Engineers,
Logistics and Operations Engineers, and Systems Analysts.
I will call them Systems Engineering.
The second group takes on Sarah's Program Management Roles,
such as Technical Management, Information Management, Coordination,
and Customer Interface.
The last group includes the Design Engineers,
which constitute solutions published in IEEE SMC.
Would you like to go back to the Design-Methods
Comparison paper?
From: "Sten Dahlberg"
Subject: Design-Methods Comparison Project
Date: Mon, 16 Mar 1998 04:58:40 -0800
Regards,
Sten
From: Sten Dahlberg
To: incose-discuss@xor.com
Subject: Copy of DMC Problem
Date: Thursday, March 26, 1998 10:55 PM
Regards,
Sten
Date: Wed, 25 Mar 1998 12:52:36 -0600
To: incose-discuss@xor.com
From: Mark Maier
Subject: Comments on DMC Paper
Mark Maier
Dr. Mark W. Maier maier@ece.uah.edu
Associate Professor 205-890-6642
Elec. and Computer Engineering 205-890-6803 FAX
University of Alabama in Huntsville
Huntsville, AL 35899 http://eb-p5.eb.uah.edu/~maier
Date: Wed, 25 Mar 1998 15:03:55 -0600
To: Terry Bahill
From: Mark Maier
Subject: Re: methods
>Thanks for your comments about our methods paper.
>As we said it is only a baby step, but it is a first step.
>I hope we showed more problems than solutions.
>terry
Mark
Dr. Mark W. Maier maier@ece.uah.edu
Associate Professor 205-890-6642
Elec. and Computer Engineering 205-890-6803 FAX
University of Alabama in Huntsville
Huntsville, AL 35899 http://eb-p5.eb.uah.edu/~maier
Date: Wed, 25 Mar 1998 15:27:30 -0800 (PST)
From: "B. Mar"
To: Mark Maier
cc: incose-discuss@xor.com
Subject: Re: Comments on DMC Paper
Brian Mar, 206 722-3764
10615 -60th Avenue So.
Seattle WA 98178
>
From: "RNewman"
To: "Sten Dahlberg"
Subject: Re: Copy of DMC Problem
Date: Fri, 27 Mar 1998 20:58:50 -0500
Sten Dahlberg's statement of the traffic light problem defines much of the
functionality, but not all. If, during harvest season, the farmer has hired
several hands to work the crop, and there is a line of five or six tractors
with loaded carts behind them crossing the road, how will the system
behave?? All the tractors and loads won't cross the road in fifty seconds,
and the sensor will be triggered either repeatedly or continuously. Is the
cross road green time extended? If not, getting the harvest across the road
will take at least three cycles, and the farmer will be less than pleased.
In the other direction, how much can traffic on the main road be backed up
by the light, without causing congestion or other blocked intersections?
What happens if a tractor breaks down while over the sensor? Will it be
continuously triggered? If so what happens to the light cycle? And what
happens if the sensor dies? Degraded mode operation can be critical.Also,
is a "smart" system possible or feasible or cost effective, which can
determine from main road sensors what the traffic is and adjust the cycle,
or one which operates on a timer, so that the rush hour traffic has
priority?? As a real world problem, as defined, there is a lot of data
missing. But identifying these issues, their effects on system
functionality and design, and then solving the problems is what SE is
about, isn't it??
Richard Newman
From: "Sten Dahlberg"
To:
Subject: DMC Problem Incomplete- Hurray!
Date: Sat, 28 Mar 1998 16:10:43 -0800
Regards,
Sten
Date: Mon, 30 Mar 1998 18:06:48 -0800
From: pmckeon@acuson.com (Pat McKeon)
Subject: Re[2]: Copy of DMC Problem
To: "Sten Dahlberg"
"RNewman"
Pat McKeon
Acuson Corp.
At 08:15 PM 3/26/98 -0800, Sten Dahlberg wrote:
Brian, et al,
From: James N Martin
To: Sten Dahlberg
Cc: B. Mar
Date: Saturday, March 28, 1998 2:03 PM
Subject: Re: Invitation for Solutions to DMC Paper
Sten,
What are your "success criteria" for this exercise?
In other words, what are your Measures of Effectiveness (MOEs)?
I suspect that 10 different people will define success differently, perhaps
in 10 different ways.
James N Martin j-martin@ti.com
Raytheon TI Systems, Inc. 6600 Chase Oaks Blvd
Bldg 3, M/S 8497 Plano, TX 75023
972.575.0182
From: "Sten Dahlberg"
To: "James N Martin"
Cc: "B. Mar"
Subject: Re: Invitation for Solutions to DMC Paper
Date: Sat, 28 Mar 1998 14:46:17 -0800
You have missed the point! Success is having each expert show their stuff
on a level playing field. The objective functions such as Measures of
Effectiveness will likely define themselves. My particular approach is
designed to be fully responsive to AFSCM 375-5, MIL-STD-499, and
MIL-STD-499A. One might expect yourself and such experts as Jerry Lake to
craft a IEEE P-1220 or EIA-632 compliant response. We might even have some
basis for evaluating a proposed standard based on what a compliant response
accomplishes!
Regards,
Sten
Date: Mon, 30 Mar 1998 08:12:46 -0600
From: nallon@tdtech.com (John Nallon)
To: incose-discuss@xor.com
DMCP SOLUTION:
Regards,
John Nallon
Director
INCOSE NT Chapter
Date: Mon, 30 Mar 1998 17:34:03 -0500
From: "Ira Glickstein, PhD"
To: incose-discuss@xor.com
Subject: What DMC Problem Shows About Systems Design Methods
> [the] statement of the traffic light problem defines much of the
> functionality, but not all. If, during harvest season, the farmer has hired
> several hands to work the crop, and there is a line of five or six tractors
> with loaded carts behind them crossing the road, how will the system
> behave?? ...
_ ___ _
| | \ / \ Ira Glickstein, PhD ira.glickstein@lmco.com << I'VE GOT
| | ~ |_|_|\_\/ \_\ Fed. Sys. 0902 | FAX: 607-751-2008 ira@prodigy.net
Owego, NY 13827| WWW: http://pages.prodigy.net/ira
From: "Sten Dahlberg"
To:
Subject: Re: What DMC Problem Shows About Systems Design Methods
Date: Mon, 30 Mar 1998 20:58:21 -0800
Regards,
Sten
From: "Sten Dahlberg"
To: "in Ira Glickstein"
Subject: Re: What DMC Problem Shows About Systems Design Methods
Date: Tue, 31 Mar 1998 05:23:02 -0800
Regards,
Sten
Date: Tue, 31 Mar 1998 09:18:18 -0500
From: "Ira Glickstein, PhD"
To: Sten Dahlberg
CC: incose-discuss@xor.com
Subject: Re: What DMC Problem Shows About Systems Design Methods
Sten:
Ira
| | \ / \ Ira Glickstein, PhD ira.glickstein@lmco.com << I'VE GOT
| | ~ |_|_|\_\/ \_\ Fed. Sys. 0902 | FAX: 607-751-2008 ira@prodigy.net
Owego, NY 13827| WWW: http://pages.prodigy.net/ira
From: "RNewman"
To:
Subject: More on DMC
Date: Mon, 30 Mar 1998 22:03:21 -0500
From:
To:
Subject: SE Roles, again
Date: Tue, 31 Mar 1998 10:25:54 -0500
Sten Dahlberg clearly took offense at Glickman's post and considered it
a criticism. When he says, "Please direct the rocks at those who would
strive to deny us the rare privilege of working a common technical
problem and comparing results." it tells me Sten thinks of SE as
solving a technical problem.
Sarah
Sarah Sheard Senior Systems Engineer
Software Productivity Consortium sheard@software.org
2214 Rock Hill Rd, Herndon VA 20170 (703) 742-7106
Date: Tue, 31 Mar 1998 10:42:01 -0600
From: William Schoening
To: incose-discuss@xor.com
Subject: RE: SE Roles, again
> What is the context?
Date: Thu, 2 Apr 1998 07:20:20 -0800 (PST)
From: "B. Mar"
To: Terry Bahill
Subject: Re: DMCP
Brian Mar, 206 722-3764
10615 -60th Avenue So.
Seattle WA 98178
Date: Fri, 3 Apr 1998 09:05:43 -0700
To: Terry Bahill
From: jring@amug.org (Jack Ring)
Subject: Re: It is ripping
>Contrary to what Ira G. said, I think we can learn much more from this
>"toy" problem than we can from a real-world problem.
>Perhaps after we all agree on this toy problem,
>then we could approach a real-world problem.
>However, I would enjoy seeing solutions from all of Sarah's 12 roles.
>The paper has 12 solutions from implementors.
>Sanchez has given us an SE solution (at one time we had 2 others).
>We also a solution from John Nallon (?) that seemed to be an administrator's
>role.
Jack Ring
sendmail:jring@amug.org
From: Eric Honour
To: "Terry Bahill (E-mail)"
> "Sten Dahlberg (E-mail)"
Cc: "Dennis Buede (E-mail)"
Subject: Design methods comparison
Date: Tue, 31 Mar 1998 14:12:01 -0500
Cordially,
Eric Honour
Date: Wed, 1 Apr 1998 09:55:05 -0700 (MST)
From: Terry Bahill
To: dahlbergs@net.a1.boeing.com, ehonour@iu.net, terry@sie.arizona.edu
Subject: Re: Design methods comparison
Cc: DMBuede@aol.com, terry
>From: Eric Honour
>To: "Terry Bahill (E-mail)"
> "Sten Dahlberg (E-mail)"
>Cc: "Dennis Buede (E-mail)"
>Subject: Design methods comparison
>Date: Tue, 31 Mar 1998 14:12:01 -0500
>I am very enamored of the DMC project that you have undertaken.
>I can picture extending the project significantly. The current approach
>as been criticized by some as being too constrained a problem. The
>responses have been criticized as coming from different SE "roles."
>Perhaps a far more complex problem, addressed by widely-spread experts in
>specific approaches, with results evaluated by a different group of
>"customer advocates," would yield an even better result.
>Another approach would be to make the extension of the DMC compatible
>with the SECOE project 98-01. Then the data gathered during 98-01
>could feed a more extensive analysis of design methods comparison.
terry
From: Eric Honour
To: "'Terry Bahill'"
"Sten Dahlberg (E-mail)"
Cc: "Dennis Buede (E-mail)"
Subject: RE: Design methods comparison
Date: Thu, 2 Apr 1998 10:57:43 -0500
Cordially,
Eric Honour
From: "Dahlberg, Sten O"
Subject: RE: Design Methods Comparison
Date: Thu, 2 Apr 1998 06:34:51 -0800
Regards,
Sten
home- sten@connectexpress.com
work- sten.o.dahlberg@boeing.com
Date: Wed, 31 Mar 98 14:50:33 est
From: "ehonour"
To: incose-discuss@xor.com
Subject: DMC and Lessons Learned
Eric Honour
Date: Wed, 1 Apr 1998 22:11:15 -0700
To: terry@sie.arizona.edu
From: jring@amug.org (Jack Ring)
Subject: It is ripping
Cc: incose-discuss@xor.com, wymore@azstarnet.com
Jack Ring
Innovation Management
32712 N. 70th St.
Scottsdale, AZ 85262-7143
Phone) 602-488-4615
Fax) 602-488-4616
sendmail:jring@amug.org
Date: Thu, 02 Apr 1998 07:11:23 -0600
To: jring@amug.org (Jack Ring)
From: James N Martin
Subject: Re: It is ripping
Cc: incose-discuss@xor.com
>Dear Terry,
>
>When the DMC problem hit the INCOSE-discuss list I was underwhelmed.
...
>After all of this, if I can't get my design past a Design Review, I can
>always claim April Fool.
Regards,
James N Martin j-martin@ti.com
Raytheon TI Systems, Inc. 6600 Chase Oaks Blvd
Bldg 3, M/S 8497 Plano, TX 75023
972.575.0182
Date: Wed, 1 Apr 1998 23:49:38 -0600
To: "Sten Dahlberg"
Cc: incose-discuss@xor.com
From: Mark Maier
Subject: Re: What DMC Problem Shows About Systems Design Methods
Sten Dahlberg writes:
>Ira, et al,
>I had a high degree of confidence that a number of individuals would choose
>to address the DMC Project technical challenge by criticizing the problem
>instead of providing their approach to a SE solution.
>
>You have not earned the right to offer criticism of the solutions provided
>until you have shown us the "right" way. It would be rude and disrespectful
>to trivialize the work performed by our colleagues and I'm certain that you
>did not intend to convey what seemed to come across in your message.
>
>Consider this a formal glove slap to your face... Show 'em if you got 'em,
>or kindly mind your peace. A number of highly regarded experts have taken
[....]
>
>The alternative seems to be endlessly arguing over un-defined terms- is that
>what you would have us pursue? If this problem is too narrow, suggest a
>"better" one for next time.
>
Oh come on, Sten. The DMC problem is a design problem that emphasizes
discrete event behavior. Those who advocate methods for that class of
problems are hardly short of examples. The data flow, statechart, VHDL, etc
crowd have many books out, piles of papers, and write-ups available on the
web. Many of these include examples on relatively large problems. The VHDL
crowd even have real-time "shoot-offs" at the major conferences.
Mark Maier
Dr. Mark W. Maier maier@ece.uah.edu
Associate Professor 205-890-6642
Elec. and Computer Engineering 205-890-6803 FAX
University of Alabama in Huntsville
Huntsville, AL 35899 http://eb-p5.eb.uah.edu/~maier
From: "Sten Dahlberg"
To: "Mark Maier"
Cc:
Subject: Re: What DMC Problem Shows About Systems Design Methods
Date: Sun, 5 Apr 1998 20:39:07 -0700
Regards,
Sten
Date: Tue, 07 Apr 1998 20:19:45 +0200
From: Ingmar Ogren
Reply-To: iog@romet.se
To: Terry Bahill
Subject: Re: Systems Engineering newsletter, April
>
> I can't remember if I told you about our Tools site
> http://www.sie.arizona/sysengr/methods2
> terry
Ingmar Ogren, Romet AB Home of the O4S (Objects For Systems) method
Fridhem 2 S 76040 Vaddo Develops Tofs (Tool For O4S)
Sweden, URL: www.romet.se Free handbooks and educational software
e-mail: iog@romet.se voice +46 176 54580 fax: +46 176 54441
Makes complex systems with operators, software and hardware manageable
Date: May 9, 1998
From: Terry Bahill