[comp.software-eng] Information Systems is an Engineering Discipline

wtwolfe@hubcap.clemson.edu (Bill Wolfe) (09/10/89)

  The following letter appears in the September 1989 issue of the
  _Communications of the ACM_, and is presented for general discussion:

    INFORMATION SYSTEMS IS AN ENGINEERING DISCIPLINE 

    The industrialized world is in the process of significantly enhancing
    its information system infrastructure.  New information systems are
    being designed and built in such diverse areas as: air traffic control,
    funds transfer, military command and control, stock transactions, 
    manufacturing, and engineering.  During the next decade and beyond,
    the lives and safety of our citizens as well as the competitiveness
    of our country will depend on the correct functioning and efficiency
    of these new systems.

    It should be self evident that the specification, design, implementation,
    and validation of such systems is an engineering project of considerable
    difficulty.  Information systems must meet exacting standards of 
    performance and must be constructed within strict time and budget
    constraints.  Many contain hundreds of thousands, even millions, of
    lines of code.  Indeed the complexity of some of these systems rivals
    that of any artifact ever constructed by man.  By any reasonable 
    definition, information systems is an engineering discipline.

    The question I would like to raise is: who is going to be responsible
    for building these new systems that are so important to our national
    economy?  To make the issue specific, suppose you were a manager 
    responsible for developing one of these systems.  Suppose your boss 
    reminds you that the proposed system will operate in an environment
    in which human lives and property are at stake.  He also reminds you
    of the many failures of such development projects -- systems that are
    late, grossly over budget, or never really work correctly.  Your career
    as a manager is on the line.  What professional would you select to be
    the manager of the system development project?

    A computer scientist?  Not likely.  By and large, the computer science
    community has ignored the entire area of information systems.  Most
    computer scientists view people who implement information systems as
    rather low-tech COBOL programmers who were not smart enough to get a
    computer science degree.  Many academic computer science departments
    actively brainwash their undergraduates that it is below their
    professional dignity to work in the information systems area.  If you
    could find a computer scientist willing to undertake the job, you might
    find that he has the technical skills to design and implement the
    internals of the system -- the database, algorithms, communications,
    etc. -- but is weak in the engineering skills required to plan, 
    organize, and manage the project.  Most computer science departments
    simply do not consider it part of their job to instill in their
    graduates the engineering approach and engineering ethic that are
    part of the educational process in other engineering disciplines.

    The required software engineering course or senior project hardly
    makes up for four years of being immersed in a non-engineering 
    culture.  Indeed sometimes the computer science culture is actually
    anti-engineering.  Instead of "If a bridge you design ever falls down,
    it is a personal blot on your professional career," we hear: "Everyone
    knows software has bugs in it when it is released."

    An electrical engineer?  Quite likely, if the application is in
    military or engineering systems.  You might find that the engineer
    has technical knowledge in the application area (for example, radar
    systems), the ability to design and build to specifications, and, if
    a senior engineer, the skills to plan, organize, and manage the project.
    However, you might also find that the engineer is weak in the computer
    science skills to design and implement the system internals.  Thus, the
    project might be completed on time and budget, but might not employ
    up-to-date computer science technology (a situation that occurs all too
    often in military systems).

    An information systems professional?  Quite likely, if the application
    is in business or management information systems.  Unfortunately, you
    might well find that the information systems professional -- particularly
    one educated in one of the existing academic information systems programs
    -- is weak in both technical and engineering skills.

    As evidence for the last statement, I turn to the most recent report of
    the ACM Curriculum Committee on Information Systems, which proposes  
    goals and a curriculum for academic information systems programs.  Of
    the many possible quotes from that report, I include one that compares
    the information systems and computer science curricula:

      The IS curriculum differs from the computer science curriculum
      in the environment in which the program is taught, the employment
      environment for the graduate, and the depth of the technical
      environment required.  

        1. The IS curriculum teaches information systems concepts
           and processes within two contexts, organization knowledge
           and management knowledge and technical information systems
           knowledge, whereas computer science tends to be taught within
           an environment of mathematics, algorithms, and engineering
           technology.  

        2. The IS graduate is expected to work within the environment of
           an organization and to interact with both organizational functions
           and computer technology.  The computer science graduate has less
           interaction with organization functions and more interaction with
           hardware and software technology.

        3. In technical expertise, the IS curriculum places substantial
           emphasis on the ability to develop an information system structure
           for an organization and to design and implement applications. 
           There is less emphasis on in depth skills in hardware and software
           design.  The computer science graduate typically has less exposure
           to information requirement analysis and organization considerations
           but obtains greater expertise in algorithm development, programming,
           and system software and hardware.

    I interpret this quote as saying that the graduate of an information
    systems program may well have a good understanding of management and
    business applications, but is highly likely to be weak in both the
    technical and engineering skills referred to above.

    I can hear the criticism of the last remark:  "Sure, you might need
    technical people down in the trenches doing the actual implementation,
    but the manager of the project does not need detailed technical and
    engineering skills."  That view is succinctly expressed in a recent
    _Business Week_ article discussing failed information systems projects.
    Among the advice given is:

       Put senior, nontechnical management in charge of the project to
       help ensure that it is finished on time and within budget.

    Rubbish!  Managing a large information system development project is
    a professional skill requiring significant technical and engineering
    background.  The overwhelming body of experience shows that successful
    system development projects are managed by people who have both project
    management skills and technical knowledge in the application area.  
    Projects fail, not because they are managed by technical people, but
    because they are managed by *incompetent* technical people who lack
    the necessary engineering skills and experience.

    Who then would you select to manage your information systems development
    project?  In the broader context, which technical discipline will take
    the lead in designing and building the complex information systems our
    country needs to support its information infrastructure?

    Unfortunately, no academic discipline is providing the education and
    training needed to produce the people who will be the technical leaders
    in this important area:

      (1) Computer science departments do not view information systems
          as within their charter and produce graduates which lack the
          required engineering orientation and skills.

      (2) Electrical engineering departments produce graduates with an
          engineering orientation but without the required computer
          science skills.

      (3) Information systems departments do not view building information
          systems as an engineering task and produce graduates which lack
          both the required engineering and technical skills.

    One reason why academia is not producing information systems 
    professionals with the required skills is that many of the businesses
    that employ their graduates also do not realize that building an
    information system is a highly technical, engineering endeavor.  I
    include one additional quote from a recent article in _Datamation_
    by a corporate personnel director describing the type of information
    system people he is seeking:

      We are going after the business graduate with a computer science
      minor, if we can get it.  Business skills are more important than
      technical skills, which we can teach ourselves.  We only require 
      that candidates have one COBOL course.  Then we put them through
      a six-week training course, and they receive additional training
      as their job requires it.

    This particular company is willing to entrust its information system 
    development to people with no technical training whatsoever!

    One source of confusion is the name "information systems" itself.
    The academic and industrial information systems community commonly 
    uses the term information systems in a rather narrow sense to refer
    only to management or business information systems.  Yet the technology
    underlying information systems has applications in a large number of
    other fields; a military command and control systems is not unlike a
    factory management system, and an air traffic control system is the
    ultimate material tracking system.  In the past, there have been 
    significant differences in scale; business information systems were
    often relatively small (systems that could be built by a person who
    had taken only one COBOL course), while military and related systems
    were significantly larger, sometimes requiring millions of lines of
    code.  That scale difference, however, is disappearing.  Many modern
    business information systems are quite large and rival in complexity
    their military counterparts.  If we want to attract bright 
    engineering-oriented professionals to build these complex information
    systems, for business as well as military and related applications,
    we have to broaden our perspective as to what constitutes an information
    system.  Information systems should be viewed as an engineering discipline
    that can be applied to a large number of application areas, including
    business information systems and military command and control systems,
    to name just two.

    It is much easier to state the problem than to propose a solution.  
    Ideally an information system professional should have the technical
    knowledge of a computer scientist, the engineering skills of an
    electrical engineer, and the application knowledge of an information
    systems graduate (but for a wider range of applications than just
    business systems).  An appropriate course of study might be taught
    within a computer science department, an electrical engineering
    department, or an information systems department, although the
    orientation and content of the curriculum would have to be quite
    different than that of most present departments.

    I believe that many of the most successful programs will be housed
    within a school or college of engineering.  Information systems is
    an engineering discipline; engineers are the professionals in our
    society who build useful systems that are implemented on time and 
    on budget; and engineering schools provide the educational environment
    in which future engineers are imbued over a four year period with the
    culture, the ethic, and the sense of professional responsibility that
    shape their entire professional lives and enable them to perform the
    engineering function.  If we want our information systems to work
    correctly and reliably and be useful to real people, if we want them
    to be built within budgetary constraints, we have no choice but to
    place the responsibility for their development in the hands of people
    who have the necessary technical skills, but even more important, the
    engineering skills and orientation to get the job done -- and within
    our present university system, these kinds of people receive their
    education in schools of engineering.

    Although I believe that engineering schools are an appropriate place
    to house such programs, the issues go beyond any organizational entity
    within the university.  My concerns can be summarized in two statements:

      (1) A large part of the information systems community, both academic
          and industrial, does not appear to understand the self evident fact
          that building a large information system is an engineering endeavor
          requiring significant technical and engineering skills.

      (2) No academic discipline views it as their job to educate technically
          trained, engineering oriented, information systems professionals.

    We say we are moving toward an information-based economy.  Who is going
    to build our information systems infrastructure?

    Author: Philip M. Lewis
            Department of Computer Science
            State University of New York
            Stony Brook, NY  11794-4400

            ARPA: pml@sbcs.sunysb.edu

diamond@csl.sony.co.jp (Norman Diamond) (09/13/89)

_Business Week_ writes:

>       Put senior, nontechnical management in charge of the project to
>       help ensure that it is finished on time and within budget.

In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:

>    Rubbish!  Managing a large information system development project is
>    a professional skill requiring significant technical and engineering
>    background.

Absolutely true.  Business Week's advice results in products that don't
work.  It is important to produce the wrong answer as quickly AND as
cheaply as possible, eh?  This kind of practice is the reason why the
U.S. (and especially Canada) now fall behind industrialized countries'
economies.  (In private industry, people get fired for expressing
Mr. Wolfe's opinion, or mine.)

--
-- 
Norman Diamond, Sony Corporation (diamond@ws.sony.junet)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.

alpope@token.Sun.COM (Alan L Pope) (09/15/89)

> _Business Week_ writes:
> 
> >       Put senior, nontechnical management in charge of the project to
> >       help ensure that it is finished on time and within budget.
> 
> In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> 
> >    Rubbish!  Managing a large information system development project is
> >    a professional skill requiring significant technical and engineering
> >    background.
> 
In article <10835@riks.csl.sony.co.jp>, diamond@csl.sony.co.jp (Norman Diamond) writes:
>
> Absolutely true.  Business Week's advice results in products that don't
> work.  It is important to produce the wrong answer as quickly AND as
> 
This topic was noticed only in time to see this last excerpting, so I may
have missed some main point.

Speaking of managerial hierarchies:  There is no problem if the
top-level management is non-technical.  As long as no micro-
management is done.  I.e., the non-tech sticks to profits, markets,
etc., and the tech mgmt stick to technical matters.  Mutual respect --
if the Mgr (tech, or otherwise) is forced (or insists) upon having
direct responsibility for realms not within their expertise, they
are not good managers.  Delegation of tasks to experts is appropriate
management.

I have managed projects under tech and non-tech people.  The more they
interfere the less likley the project will end successfully.  I have
worked for managers who did not know what a byte was (other than some
computer term) but who had respect for my technical ability -- these
projects cmae in under the proverbial "on time and within budget"
category.  I have worked for technical managers who were micro-managers,
continously overriding any authority I was supposed to have.  Staff were
in constant turmoil -- projects didn't get done on time and went way
over budget.

I think Business Week is correct (based on just the quote above, not
having read the article): if the company exists for "bottom line", as
do most, get an expert in "bottom line" to manage.  I presume that
BW was referring to upper-level mgmt and not that for every four engineers
you need one non-tech manager.

I acknowledge that the Summary line is like "This is not a pipe".
Alan L. Pope   alpope@sun.com OR sun.com!token.Eng!alpope OR sun.com!Eng!alpope
			(depending on which mailer is running this week)

jimb@athertn.Atherton.COM (Jim Burke) (09/15/89)

In article <10835@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
>_Business Week_ writes:

>>       Put senior, nontechnical management in charge of the project to
>>       help ensure that it is finished on time and within budget.

>In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:

>>    Rubbish!  Managing a large information system development project is
>>    a professional skill requiring significant technical and engineering
>>    background.

>Absolutely true.  Business Week's advice results in products that don't
>work.  

I would like to state this even more emphatically.  Business Week seems
to cater to all the proffessional managers in the U.S.  It places a 
premium on MBA type managers for all aspects of managing the corporate
world.  I have worked with projects headed by proffessional managers.
They seldom succeed (if ever).  Unfortunately, the only way to get into
a position of being a competent manager is to get a technical degree, work
a few years (long enough to become technically competent) and then go and
get an MBA.  It is unfortunate that, in the U.S., you must climb the
corporate management ladder in order to have a voice.  Precious few
technically competent people do this.  In other countries, namely Japan,
the senior engineer has a voice and is highly respected.  A manager of
finance would never presume to tell him how he should build his product.
Unfortunately, engineers do not have a voice in most U.S. companies
when the decisions are made.  You can have a Phd in engineering and
20 years of experience and some snivelling little Harvard MBA will set
the parameters within which the project will proceed, often times
encroaching very heavily into technical issues.  I would assert that
a highly experienced engineer understands his market far better than
some recent MBA graduate.  I know of one specific company that was totally
ruined (ultimately was taken over for peanuts) because the president
(who was fairly technical himself) placed most of the control in the 
hands of a young V.P. who was three years out of Harvard.  (Sorry to
pick on Harvard, but if they produce a fair number of bozo's , what are
the rest of the pack doing?).  Anyway, this guy proceeded to piss off
the entire technical organization, the customer base, and anyone else
he came into contact with because he fundamentally didn't understand
that the engineering business is very different than banking, or retailing,
or manufacturing, or anything else he had encountered in his vast
three years.   

Anyway, what else would you expect Business Week to say???




-- 
******                Views expressed herin are my own               ******* 
Jim Burke - consultant  408) 734-9822   | I'll stop posting when they pry my 
jimb@Atherton.COM                       | cold, dead fingers from the smoking
{decwrl,sun,hpda,pyramid}!athertn!jimb  | keyboard.

mal@PacBell.COM (Martin A. Lodahl) (09/15/89)

In article <10835@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
|_Business Week_ writes:
|
|>       Put senior, nontechnical management in charge of the project to
|>       help ensure that it is finished on time and within budget.
|
|In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
|
|>    Rubbish!  Managing a large information system development project is
|>    a professional skill requiring significant technical and engineering
|>    background.
|
|Absolutely true.  Business Week's advice results in products that don't
|work.  It is important to produce the wrong answer as quickly AND as
|cheaply as possible, eh? ...

It amazes me to find myself agreeing with Bill Wolfe, but I also agree
with this statement, and would like to extend it to cover any large,
technically-intensive project.  My principal assignment at the moment 
is to help salvage a collapsing data center move project that non-technical
managers had nearly run into the ground ...
-- 
= Martin Anders Lodahl       Pac*Bell Minicomputer Ops Support Staff =
= {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!mal     916/972-4821 =
= If it's good for ancient Druids, runnin' nekkid through the wuids, =
= Drinkin' strange fermented fluids, it's good enough for me!!  8-)} =

karl@ficc.uu.net (Karl Lehenbauer) (09/18/89)

> |>       Put senior, nontechnical management in charge of the project to
> |>       help ensure that it is finished on time and within budget.

> |>    Rubbish!  Managing a large information system development project is
> |>    a professional skill requiring significant technical and engineering
> |>    background.

The question is, what is the job of management?  While I think technical
decisions should be made by people with an understanding of the technical
aspects of the project, I think management can often be too involved
with the technical issues.

When a manager in charge of twelve programmers gets too technical, they
become the thirteenth programmer in the group, rather than the manager.
At that level, it is the manager's job (IMHO) to get his or her people
to work, to get them to work mostly on what they're supposed to be working
on, and to badger them to do some of the more unpleasant-to-programmers
things like schedules and status reports.

Inability or unwillingness to delegate responsibility is a common criticism
of many new managers, usually levied at those fresh from a direct technical 
job.  Once they "correctly" start delegating stuff, they lose direct contact 
with the technical end, and in a few years, their technical knowledge is out 
of date, unless they are very, very committed to maintaining it.  Typically,
the higher they are in the organization, the more technically out of date
they are, because it has been that many more years since they were technical.

Another question, how technical should they be?  Our big project has well
over a million lines & 400K statements of disk-resident software, plus
firmware, diagnostics and a good deal of built-here hardware.  It would
take years for a committed programmer to achieve a comfortable knowledge
of the innards of half the software.  Clearly, management must deal with
it at a significantly more abstract, hence less technical, level.

(Pardon the disjointedness of this.  I must hurry.  ...more later if the
discussion continues & warrants it.)
-- 
-- uunet!ficc!karl	"Have you debugged your wolf today?"

crm@romeo.cs.duke.edu (Charlie Martin) (09/19/89)

In article <6198@ficc.uu.net> karl@ficc.uu.net (Karl Lehenbauer) writes:
>> |>       Put senior, nontechnical management in charge of the project to
>> |>       help ensure that it is finished on time and within budget.
>
>> |>    Rubbish!  Managing a large information system development project is
>> |>    a professional skill requiring significant technical and engineering
>> |>    background.
>
>The question is, what is the job of management?  While I think technical
>decisions should be made by people with an understanding of the technical
>aspects of the project, I think management can often be too involved
>with the technical issues.

Fred Brooks makes an interesting distinction on this question between
the "producer" and "director" --- names chosen by analogy with movies.

The producer role is what is spoken of in the first quotation: get it
done on time and within budget.  The director is in charge of getting a
good product.  They ought, by rights, to be considered equal, and to
understand that they have equal roles in arriving at the desired result.

Clearly, there are some points that have to be settled by negotiation
between producer and director, like buying every programmer a second
workstation (they have two hands, after all).  But in general, the
producer acts as the director's buffer against upper management, and the
director keeps up with the technical details that the fiddling details
of budgets don't leave the producer time for.

I think Brooks talks about these roles reasonably clearly and in depth
in Mythical Man Month.  everyone should read it.

Just don't pay attention to his suggestions about commenting PL/I
programs.
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 

UH2@PSUVM.BITNET (Lee Sailer) (09/20/89)

<6043@pbhyf.PacBell.COM> <6198@ficc.uu.net> <15624@duke.cs.duke.edu>

The distinction between a 'producer' and 'director' is a good one.  While
I usually argue in favor of more technical expertise rather than less,
in this case I'll do the opposite.

In this train of argument being discussed here, people have been attacking
the idea of putting a "manager" in charge.  I think the original poster
might have misinterpreted the original case being made.  In the case study
literature, there are many cases of well built, useful systems *failing*
because the people they were built for weren't interested.  There are
even more examples of technical projects *failing* because senior management
didn't care, or know to care, whether the project was successful.

Because of these experiences, the current party line is that advanced
information technology projects should not be funded

                         UNLESS

their is a committed person with funding and decision making powers who
is willing and able to pursue the project to its finish (completion or
cancelation).  This, I think, is the 'Producer'.  This person need not
be technical.  This person must understand the goals, strategy, and "bottom
line" of the enterprise.

rcd@ico.ISC.COM (Dick Dunn) (09/20/89)

In article <6198@ficc.uu.net>, karl@ficc.uu.net (Karl Lehenbauer) writes:
> > |>       Put senior, nontechnical management in charge of the project...
> > |>... Rubbish!  Managing a large information system development project is
> > |>    a professional skill requiring significant technical and engineering
> > |>    background...
>...When a manager in charge of twelve programmers gets too technical, they
> become the thirteenth programmer in the group, rather than the manager...
. . .
> Inability or unwillingness to delegate responsibility is a common criticism
> of many new managers, usually levied at those fresh from a direct technical 
> job...

Karl's right--and there are practices which encourage this to happen.  The
worst is "promoting" people from engineering to management.  In some com-
panies, if you rise high enough you MUST become a manager--you run out of
room for technical advancement after a while.  The result is then that your
best technical people get turned into managers whether they like it or not.
It may be overt--"If you want to advance your career, it's time to take on
some management responsibilities"--or relatively subtle.

The saying some of us use for this is "It's always possible to turn a good
engineer into a bad manager."  Promote someone who likes engineering but
not managing into a management position; the person will find a way to
neglect the management and dabble in the engineering.

(More enlightened companies have a nearly-complete "dual ladder" structure
for advancement, where you can stay technical if you want.)

>...Once they "correctly" start delegating stuff, they lose direct contact 
> with the technical end, and in a few years, their technical knowledge is out 
> of date, unless they are very, very committed to maintaining it...

This is mostly OK; they'll retain some of the important understanding of
what sorts of tasks are inherently easy or hard.  You won't have to explain
why finding a timing-related bug (critical-section failure, deadlock, etc.)
with new hardware and new software might take anywhere from an hour to a
week.  That's (one example of) the sort of knowledge that a former technical
person will retain through a lot of management.  It's very hard to teach a
completely non-technical manager (i.e., a never-technical manager) this
sort of thing.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...I'm not cynical - just experienced.

simpson@trwarcadia.uucp (Scott Simpson) (09/21/89)

My boss just handed me this.  Some excerpts from

Golson, Dr. Hodges L., "How to Fail in Management", 
Georgia Tech Alumni Magazine, Spring, 1988.

Dr. Golson is the president of Management Psychology Group in Atlanta.

1. Have all the answers.  Don't admit that you don't know.  Bluff
your way through.

2. Manage tightly, inspect closely and delegate only what you have to.

3. Hire in your own image.

4. Don't worry about interpersonal skills.  Managers are supposed to
be tough-minded, hard-nosed, abrasive and even arrogant.

5. Always keep your next job in sight.  Learn to play politics, avoid
blame and sell upwardly.  Be quick to rationalize and to project blame
outwardly.

6. Don't worry about the long term.  Keep focused on the immediate,
here-and-now needs of the situation.  Mortgage your future by making
short-term, "earnings-per-share" decisions.

7. Focus only on the positive.  Avoid bad news.  If you do get bad
news, shoot the messenger.  Do anything you can to discourage
subordinates from giving you bad news (i.e., by accusing them of being
negative, not being on the team, etc.)

8. Pay an inordinate amount of attention to your image.  Don't be
caught without your three-piece dark suit, power tie, gold cufflinks,
pocket hankies, pinky rings, Rolex, etc.

9. Have a problem with integrity.
	Scott Simpson
	TRW Space and Defense Sector
	usc!trwarcadia!simpson  	(UUCP)
	trwarcadia!simpson@usc.edu	(Internet)

rpb@dasys1.UUCP (Robert Brady) (09/21/89)

	Although an understanding of the technical aspects of a job
is neccesary for any decent manager, this is not all there is to it. The
computer field is the first time in business history where the employees
have had more skill than the management (ignoring easily learnable tasks).
This throws some strange twists onto the management selection process as
it would be an extraordinary man who learned the equivalent of 20 years in
the field in both business and comp-sci. Although in the perfect world
you would want to have each manager work through every position beneath him, 
this is not likely to happen in any near large company.

 
-- 
+---------------------+------------------------------------------------------+
|  Robert Brady       | rpb@dasys1.UUCP                                      |
|     Logic.          | !cmcl2!{ccnysci,cucard,hombre}!dasys1!rpb            | 
|"An elective despotism was not the government we fought for..." T.Jefferson |

markh@rtech.rtech.com (Mark Hanner) (09/22/89)

I definitely agree with the view that managers who micro-manage their product
development cycle are doomed to failure. We follow the basic "producer"/
"director" model here where I (the product marketing manager) specify only
the basic product requirements, and leave it to the project managers to 
design and build the product. There DOES need to be negotiation on the 
design spec, since I'm the one who spends the time to talk with customers
follow market trends, and have insights into how the product should behave
externally. To extend the analogy, the producer often has to go back to the
director and say "you have to cut 20 minutes out of the final cut, or we'll
only be able to show the picture twice a day, and won't make as much money."
I don't think I should tell the director what to cut, just that something
has to be cut (don't read too much into this as the analogy gets strained).
Francis Coppola lucked out with "Apocalypse Now," but the fact that no 
producer has been able to rein him in has contributed to his failure to 
create another hit (IMHO).

In defense of MBA's, sure there are a few "duds" floating around, but I've
seen alot of startups fail because they had no non-techies and got so caught
up in building "neat" or "theoretically correct" products that they forgot
to make sure they knew where (and how much) their income was coming from.

cheers,
mark

-- 
markh@rtech.COM
"Crass generalizations may be justified by admitting 10 exceptions."
			-- marnie applegate

chrisp@regenmeister.uucp (Chris Prael) (09/23/89)

From article <10743@dasys1.UUCP>, by rpb@dasys1.UUCP (Robert Brady):
> The
> computer field is the first time in business history where the employees
> have had more skill than the management (ignoring easily learnable tasks).

I suggest that you earn a little bit about the histories of electrical,
electronic, mechanical, civil, chemical, aeronautical, and automotive
engineering.  The biggest difference between those fields and computing
is that no where near as many technicians managed to pretend that they
were engineers in any of those fields as have done so in computing.

Chris Prael

joannz@halley.UUCP (Joann Zimmerman) (09/26/89)

In article <34348@regenmeister.uucp>, chrisp@regenmeister.uucp (Chris Prael) writes:
> I suggest that you earn a little bit about the histories of electrical,
> electronic, mechanical, civil, chemical, aeronautical, and automotive
> engineering.  The biggest difference between those fields and computing
> is that no where near as many technicians managed to pretend that they
> were engineers in any of those fields as have done so in computing.


One other very noticeable difference between other engineering fields and
computing is in the amount of failure analysis to be found in the field. Did
anybody reading this EVER take a course in failure analysis of software? In
fact, where's the literature on this? There's all sorts of stuff on how
bridges fail, and why buildings do/don't stand up, but there seems to be no
real ability to analyze the stress on a software module, or the failure rate
of software components. All I've ever seen is the anecdotal evidence
(comp.risks and the like) and various platitudes about a quality development
process producing quality software. How would we go about developing this
into a real engineering discipline?


-- 
"Come, my friends, 'tis not too late to seek a a newer world - "

Joann Zimmerman            Tandem Computers        Austin, TX 
...!{rutgers,harvard,gatech,uunet}!cs.texas.edu!halley!joannz

chrisp@regenmeister.uucp (Chris Prael) (09/27/89)

From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman):
> One other very noticeable difference between other engineering fields and
> computing is in the amount of failure analysis to be found in the field. 

A superb point.  And one I have consistently overlooked.  

This is pure speculation, but it seems to me that there are two impediments 
to failure analysis in software.  The first is my previous point of people
functioning like technicians rather than like engineers, which means just 
hacking things until you have something that looks like it works (also 
known as prototyping).  It is very hard to analize a design when there is 
none.

The second impediment is the programmerly habit of patching things up as
fast as they break.

It would be interesting to analize the reported bugs from, say, a series
of OS or translator releases.

> How would we go about developing this into a real engineering discipline?

Why not follow the leaders?  Do what the real engineers do.

Chris Prael

gary@dgcad.SV.DG.COM (Gary Bridgewater) (09/28/89)

In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman):
>> One other very noticeable difference between other engineering fields and
>> computing is in the amount of failure analysis to be found in the field. 
>> How would we go about developing this into a real engineering discipline?
>Why not follow the leaders?  Do what the real engineers do.

Yes! Go buy a $1M software tester, hire a team of programmers to generate test
patterns, another team to program the tester to run the patterns, another
team to build a simulator to generate simulated output to compare to the
tester output, another team to take your specs and generate code, another
team to take your specs and emulate the machine to compare to the output from
the simulator to see that is does the right thing (did we forget the team to
write down what the right thing is?). But wait a minute wasn't this what 4GL
was going to free us from? 
Engineers deal with systems that have a finite (possibly large) number of states
so they can actually test or at least simulate all of them. If they can't then
they cheat and make generalizations. Example: to test the load bearing limits
on a bridge build a model and start with a lot of weight and keep adding big
chunks of weight until it breaks then divide that by 2 (or 4, some fudge factor)
and call that the limit. They don't have to get the exact limit just a safe one.
So how do you apply that to software? Tell your boss "This foo works for all
files less than 10Mb in size?" Your boss tells you "Make it work for all
files - software isn't bridge-building."
But look at a simple subroutine with, say, 4 32bit inputs. How many states?
2^128. How do you test them all or whittle that down automatically without a
program that understands programs?
It's got to be pretty smart and understand what can happen if you call a
subroutine or if there are any possible side-effects.
And for a reasonable project, you can have, what? hundreds of these subroutines?
Thousands?
If you have a program that understands programs then you should be able to
synthesize the code from the spec and you can forget testing. You just need
to verify the spec. Now we're back to 4GL. Where the heck is it?

The only thing I think we can get from engineers is the same thing that the
Structured Methodology people have been saying for years - design it right
from the top down and then code to the design. Then get someone to check
both these things. Have a test methodology and stick to it. Do regression
testing on any changes. Document everything, always.
Still, $1M chunks of otherwise useless hardware and hordes of expensive
Computer Aided Software Developement types bowing and scrapping all over
the place is an appealing thought. :-)
-- 
Gary Bridgewater, Data General Corp., Sunnyvale Ca.
gary@sv4.ceo.sv.dg.com or 
{amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary
No good deed goes unpunished.

chrisp@regenmeister.uucp (Chris Prael) (09/29/89)

From article <1142@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater):
> In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>>From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman):
>>> One other very noticeable difference between other engineering fields and
>>> computing is in the amount of failure analysis to be found in the field. 
>>> How would we go about developing this into a real engineering discipline?
>>Why not follow the leaders?  Do what the real engineers do.
 
> Yes! Go buy a $1M software tester, hire a team of programmers to generate test
> patterns, another team to program the tester to run the patterns, another
> team to build a simulator to generate simulated output to compare to the
> tester output, another team to take your specs and generate code, another
> team to take your specs and emulate the machine to compare to the output from
> the simulator to see that is does the right thing (did we forget the team to
> write down what the right thing is?). 

In case you hadn't noticed, noone has ever figured out how to build a
tester for the Golden Gate Bridge or the Sears Tower.

Boy did/do you miss the point.  The point is that real engineers DESIGN!
And they document the design.  Before they try to build what ever it is.
Reletively few "programmers", "software engineers", etc. even know what
the verb design means, let alone how to do it.  I have been
reading/hearing about magic pills, such as 4GL or CASE, that will be the
perfect substitute for basic competence for 20 years.  Oddly, not one of
them has worked yet.

> The only thing I think we can get from engineers is the same thing that the
> Structured Methodology people have been saying for years - design it right
> from the top down and then code to the design. Then get someone to check
> both these things. Have a test methodology and stick to it. Do regression
> testing on any changes. Document everything, always.

Exactly!  It works for them and it works when you do it in software too.
There is no substitute for discipline and competence.  

Some of the new things may help a disciplined software engineer to do it
better and/or faster, but they will never be a substitute for figuring
out what you are going to do so that it is not significant who executes
the design.

Chris P

eugene@eos.UUCP (Eugene Miya) (09/30/89)

>DESIGN

Noble words, wish I could agree.

The problem is (best noted by Butler Lampson and Fred Brooks in various
articles and one book) is that software is an intrinsically different
thing that "hardware."  The hardware people make mistakes (so you get cries
for certification).  The software people try to mimic with design and
documentation.  I don't think these will ever be enough.

I say this because I contrast the pre-computer parts of my
pre-engineering: things like mechanical drawing, etc. to the computer parts.
I can remember one teacher saying, "It's not adequate just to design
and something.  You have to know and be able to construct it as well."
This of course lead to those drawings E shaped forms which have n roots
and n-1 spokes, something Escher would design: optical illusions.

In software on two flight projects, I've used 2 design languages and 1
requirements specification language (SDDL, PDL, and RSL/RSA).  I think
the people who use and design some of this stuff are dreaming.  Language
is kinda of a poor basis for modeling things.  Real world hardware can utilize
geometric and mathematics.    It follows conservation principles.  Software
doesn't have any of this, and it still has to work.  We will have a computer
literate public before we have design languages which "work."

The thing which disturbs me so much about software engineering education is
the emphasis on software project managerment.  It's all taught late in a
programmer's life.  If design languages and
specification languages were so good, we should be able to have little
kids using them:  they use geometry at a very early age, and can be
good draftsman at a young age.  I know the objections to this, but I think
it has to be that simple to use these tools.  The need for software isn't
set by programmers and engineers for these types of projects.  Engineers
design the best tools for themselves BECAUSE they have to use them.  It's
also an iterative thing.  Said managers and other politicians, etc.
who ask for big software projects have to learn to understand the consequences
of their requests, the side-effects, etc.  Life's tough, computers aren't
going to resolve moral issues.

If engineers are going to get criticized for being engineers, this is part
of the reason why.  No simple answers.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

ejp@abvax.icd.ab.com (Ed Prochak) (10/03/89)

In article <5296@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:

   >DESIGN

   Noble words, wish I could agree.

   The problem is (best noted by Butler Lampson and Fred Brooks in various
   articles and one book) is that software is an intrinsically different
   thing that "hardware."  The hardware people make mistakes (so you get cries
   for certification).  The software people try to mimic with design and
   documentation.  I don't think these will ever be enough.

   I say this because I contrast the pre-computer parts of my
   pre-engineering: things like mechanical drawing, etc. to the computer parts.
   I can remember one teacher saying, "It's not adequate just to design
   and something.  You have to know and be able to construct it as well."
   This of course lead to those drawings E shaped forms which have n roots
   and n-1 spokes, something Escher would design: optical illusions.

   In software on two flight projects, I've used 2 design languages and 1
   requirements specification language (SDDL, PDL, and RSL/RSA).  I think
   the people who use and design some of this stuff are dreaming.  Language
   is kinda of a poor basis for modeling things.  Real world hardware
   can utilize
   geometric and mathematics.    It follows conservation principles.  Software
   doesn't have any of this, and it still has to work.  We will have a computer
   literate public before we have design languages which "work."

[text deleted]

   ... Said managers and other politicians, etc. who ask for big
   software projects have to learn to understand the consequences
   of their requests, the side-effects, etc.  Life's tough, computers aren't
   going to resolve moral issues.

   If engineers are going to get criticized for being engineers, this is part
   of the reason why.  No simple answers.

   Another gross generalization from

   --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
    resident cynic at the Rock of Ages Home for Retired Hackers:
    "You trust the `reply' command with all those different mailers out there?"
    "If my mail does not reach you, please accept my apology."
    {ncar,decwrl,hplabs,uunet}!ames!eugene
				   Live free or die.

Eugene,
	I agree with you for the most part. I think you hinted at the
key difference between software and hardware: model building, based on
known mathematical fact. For example, aircraft designers can build a
scale model and test its characteristics at a very low cost compared
to the final product. They make use of Reynolds number and other
aerodynamic parameters to be sure the model will behave like the
real thing.
	We need a rule for scaling software so that we can test
small, cheap models of the software system. I think this is what
top-down design, structured design and object oriented design all are
striving for. We need to be able to build the model based on the
design, test it, if it doesn't work throw it away, if it does work then
build the real thing.
	The problem has been that we don't build models.
There has been proposals that we build prototypes instead.
This may be okay as long as the prototype never leaves the
development lab. Prototypes have to be treated as throw-aways,
especially when they work!
	My personal opinion is that prototypes are not good enough,
and that models of software systems are possible. What the techniques
will be, I don't know. I agree that verbal descriptions cannot be good
enough. Pictures are better (data flow diagrams and the like) but they
aren't models, they can't be easily tested. There must be something
we can use. Suggestions? Opinions?
 (BTW I am still looking for a reference to petri nets.
  If anyone can suggest a good introductory text, I would
  be very grateful.)

	Well, I made my point. Time to get out of here.
	bye
	ed prochak
--
Edward J. Prochak        (216)646-4663       I think. 
{cwjcc,pyramid,decvax,uunet}!abvax!ejp       I think I am.
Allen-Bradley Industrial Computer Div.       Therefore, I AM!
Highland Heights,OH 44143                    I think?  --- Moody Blues

varnau@cs.purdue.EDU (Steve Varnau) (10/04/89)

In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes:
>
>Eugene,
>	I agree with you for the most part. I think you hinted at the
>key difference between software and hardware: model building, based on
>known mathematical fact. For example, aircraft designers can build a
>scale model and test its characteristics at a very low cost compared
>to the final product. They make use of Reynolds number and other
>aerodynamic parameters to be sure the model will behave like the
>real thing.
>	We need a rule for scaling software so that we can test
>small, cheap models of the software system. 
     [deleted text]

Here at Purdue University, I attended a talk about "Software Windtunnels"
by Dr. D. Comer.  In this talk he explored ways to test software (or 
software development methods) in ways similar to airplanes.  He even
used analogies to the Reynolds number.  (Which is a dimensionless number.)
All physics equations are homogeneous in their units, i.e. they are 
algebraically the same on both sides of the equal sign.  (I can't recall
the exact term he used for this concept.)  Software engineering hasn't 
discovered this concept, or at least any equations using it yet.  He seemed
to think we should work on this and that scale factors could be found.

On another topic (software safety), everyone is blaming errors on design,
but many systems have been around so long that they no longer resemble
the system designed.  Has anyone considered preventative maintenance?  People
compare software reliability to bridge reliability.  Even bridges fall down
when they are not maintained (i.e. NYC is having this problem in a big way).


-- 
Steve Varnau  =  varnau@medusa.cs.purdue.edu
Purdue University, West Lafayette, IN     (Software Engr. Research Center)
IBM, Poughkeepsie, NY

varnau@cs.purdue.EDU (Steve Varnau) (10/04/89)

In article <8160@medusa.cs.purdue.edu> varnau@cs.purdue.edu (Steve Varnau) writes:
>
>Here at Purdue University, I attended a talk about "Software Windtunnels"
>by Dr. D. Comer.   

Oooops, That was Dr. Richard DeMillo, not Dr. Comer.

Sorry

-- 
Steve Varnau  =  varnau@medusa.cs.purdue.edu
Purdue University, West Lafayette, IN     (Software Engr. Research Center)
IBM, Poughkeepsie, NY

sharam@munnari.oz.au (Sharam Hekmatpour) (10/04/89)

In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes:
>	The problem has been that we don't build models.
>There has been proposals that we build prototypes instead.
>This may be okay as long as the prototype never leaves the
>development lab. Prototypes have to be treated as throw-aways,
>especially when they work!
>	My personal opinion is that prototypes are not good enough,
>and that models of software systems are possible. What the techniques
>will be, I don't know. I agree that verbal descriptions cannot be good
>enough. Pictures are better (data flow diagrams and the like) but they
>aren't models, they can't be easily tested. There must be something
>we can use. Suggestions? Opinions?

My opinion is that prototypes and models are both good, so long as we
understand their limitations. Any abstraction or simplification -- and
this is exactly what models and prototypes lead to -- involves loss of
information. This is not necessarily bad, but the trick is to decide
WHEN to abstract WHAT and HOW. I strongly belive that no tool or
language can answer these questions. The only reliable source for
answers has been, and still is, EXPERIENCE. 
	In this respect, systems that have been developed for decades
over and over again pose no problem, since there is such a vast body
of knowledge and experience gathered around them. The real problem are
NOVEL systems which, because of the success of this industry, are
growing in number. Because we know little about the application domain
of such systems, and because our experience from other systems does not
usually scale up to such systems, development runs into complications.
	Now, compare this to other engineering disciplines. There, novel
systems are few and far in between, so these difficulties are far less
expressed.
	Hoping to find 'something' that can all of a sudden rescue us
from this maze is like trying to answer unknown questions. Sure, there
are notations, techniques, and ideas that are generally useful, but
there is NO simple, universal solution. I for one think that our
efforts are better spent thinking how we might train "Great Designers"
(see F. Brookes) than to strive for "Great Notations". If only 1 in 10
people in this industry were as good as the best, we would have no
problem to worry about.

+----------------------------------------------+
| Sharam Hekmatpour <sharam@munnari.oz.au>     |
| Computer Science Dept., Melbourne University |
| Parkville, Victoria, Australia 3052          |
+----------------------------------------------+

eugene@eos.UUCP (Eugene Miya) (10/04/89)

In article <8161@medusa.cs.purdue.edu> varnau@cs.purdue.edu (Steve Varnau) writes:
>>
>>Here at Purdue University, I attended a talk about "Software Windtunnels"
>>by Dr. D. Comer.   
>
>Oooops, That was Dr. Richard DeMillo, not Dr. Comer.

Distribution: comp.edu
^^^^^^^^^^^^^^^^^^^^^^ actually this isn't a followup field.

DeMillo: Parnas's student who recently defended SDI at Stanford with Parnas
on the opposite side.

Actually, I have given some thought to this.  I've written up a couple of
pages of notes on the wind tunnel analogy.  We have 24 (momentary 23)
of the world's largest wind tunnels here.  But I'm bad about writing
real papers.

Wind tunnels are kind of a neat laboratory for aerodynamics.  The Wright Bros.
invited the wind tunnel, and it probably gave them the edge in developing
airplanes.  Wind tunnels are now reaching their limits because their flows
are fair too stable, far too linear.  Cross flows, turns, dynamic things
are difficult to simulate.

I have thought lots about all kinds of other scientific apparatus:
telescopes, refineries, reactors, "atom smashers," "tokomacs,"
lasers, etc.  I've thought lots about other sciences and that other sciences
don't regard "computer science" as a science, notably those which fund CS.

My interest came as a result of a NASA internal effort to improve its
use of computers.  Efforts were directed by NASA HQ because we had the usual
major computers problems: the software problem, the database, problem, and
the performance problem.  In time I became somewhat disillusioned.

But about a year ago, I started thinking about aand have given 3 seminars
on the topic of what I regard as "Empirical Compuert Science."  This is a
topic lacking books, having few articles, no methodology, etc.  I've
give the talk at OSU (Oregon), UCD, and UCSC.  I'm giving it to a tough
audience at Livermore in 4 weeks.  Physicists: "real scientists" 8).

Basically, my thesis notes that CS and SE are traditionally viewed as
an offshoot of mathematics.  True CS can use a lot more mathematical
technique, but theory isn't enough. (Good Ref D. Knuth, AMM 1985)
We sometimes spend too much time with math. It's the "Conservation Laws" which
make physics so powerful.  We don't have these, but I think we must learn
two important things from other less than mathematical sciences:
1) we must learn how to be better observers, we must not leave this to chance
as we do now, and 2) we must learn experiment design techniques, not
from the statisticans, but from simple logic.

I turn back to a good book on 2) from Campbell and Stanley.  There are more
elaborate books, but few simpler, and we have to start at a simpler level.
We have a somewhat perverted idea of "Control" in computing which
other sciences lack.  It's both good and bad.  The idea that a
"Program" is an "experiment" is a wrong one.  I think Feigenbaum said this
originally.

The seminar "ECS" covers these things.  I've left out the section on
the role of "Observation."  I've no articles on this topic, but I'm
trying to formulate something.  I draw on some of the original ideas
which got systems analysis started.  

I think computer scientists probably spend a little too much time with their
own kind and need to mix with people in other disciplines.  I do see other
sciences coming in and learning CS principles, and I do get some moral support
outside.

Generally I am hopeful, some optimism, for the funding fo CS and SE, but
I think we have something of an elitist/snobbish view.  A tiny bit
too academic (going back to Turing in fact).

There are other consequences in education with the trend to computing and
other sciences.  I see the lack of interest in the more "experimental"
sciences: chemistry: few chemistry sets, biology: yes we have to cut up a
few frogs.  We in CS are unfortunately a little too concern with minute
details without seeing grander problems.  So I have to spend time convincing
physicists, chemists, geologists, that we need funding.  (If you 
read Feynman's "Surely Your Joking," you will know he "sat at the tables"
of other disciplines.  We must do this, too.)

If this sounds interesting, and I should publish, you are right, but
part of my problem is the difficulty in bouncing ideas off on NASA
people, we are kind of a jaded lot.  NASA also has some strict ideas about
the release of written information, and they have not discovered networks.
They are worried about foreign governments, etc.  Anyways, my problem
not yours.  Net flaming is easier.  And I have to do my other work
with priority.  Hope you guys make it an engineering discipline.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

UH2@PSUVM.BITNET (Lee Sailer) (10/04/89)

>                       I agree that verbal descriptions cannot be good
>enough. Pictures are better (data flow diagrams and the like) but they
>aren't models, they can't be easily tested. There must be something
>we can use. Suggestions? Opinions?

I think DFD's are models, though you are right that the testing is problematic.
The test is called a "walk thru."  Some procedures (or perhaps better, guide-
lines) have been developed that make some walk throughs more effective than
others, and some people are better at it thena others.

"Verbal descriptions" can be models too, especially if they are in
languages like PDL, or structured English, or whatever.  The final source
code is a "verbal desription" is it not?  That is, I can verbalize it
over the phone to you, and you can write it down, and then you know
more about the system than you used to.

However, I didn't write this to quibble about whether these are models or not.

I wanted to point out that models are reductions of the actual system, and
by definition they omit some detail.  It is usually necessary to build two or
three different models of the system, using differnt modeling tools, in
order to get a well rounded view of how the final system will behave.

                                                                     lee

bill@pd1.ccd.harris.com (Bill Davis) (10/04/89)

In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes:
>	The problem has been that we don't build models.
>There has been proposals that we build prototypes instead.
>This may be okay as long as the prototype never leaves the
>development lab. Prototypes have to be treated as throw-aways,
>especially when they work!

I agree with throwing away prototypes when appropriate.
But, what makes a prototype something that should be
thrown away if it is working and providing useful
functions?  Is it because it has "lower quality" or
because it has bugs?  I use lots of software with
bugs and the variation in "quality" is large.
But, this "buggy" software still provides useful
functions to me when I avoid the bugs.

>	My personal opinion is that prototypes are not good enough,
>and that models of software systems are possible. What the techniques
>will be, I don't know. I agree that verbal descriptions cannot be good
>enough. Pictures are better (data flow diagrams and the like) but they
>aren't models, they can't be easily tested. There must be something
>we can use. Suggestions? Opinions?

If a prototype is done in a language that uses constructs
at a high enough level, then why is it not a design description?
I do not have access to such a language, but it does
seem reasonable that such a language could exist.
The code executed might be high overhead and not suitable
for many purposes that require lower overhead.  But, wouldn't
this still be a "model" in that it functions "to scale" (where
scale involves slower instead of smaller).

-- 
* Truth comes as an enemy only to those who have lost the ability to welcome  *
* it as a friend. ** Be thankful for your troubles.  If your job did not have *
* problems, they could hire someone else to do your job at half the cost.     *
Bill Davis   EMAIL: w.davis@ccd.harris.com (<-best) uunet!hcx1!pd1!bill

rsd@sei.cmu.edu (Richard S D'Ippolito) (10/05/89)

This discussion began with an article by Bill Wolfe highlighting a September
CACM letter by Philip Lewis of SUNY.  My only comment on the letter itself
is that there is no reason to limit the application of engineering software
to information systems -- all software systems should be truly engineered.
The discussion has strayed into the typical dead-end concerns of who should
manage software and how it should be managed, instead of properly focusing
on how it should be engineered.  Ed Prochak has brought the discussion back
to the real issue.

Ed writes in article <EJP.89Oct3090900@abvax.icd.ab.com>:

>	We need a rule for scaling software so that we can test
> small, cheap models of the software system. I think this is what
> top-down design, structured design and object oriented design all are
> striving for. We need to be able to build the model based on the
> design, test it, if it doesn't work throw it away, if it does work then
> build the real thing.
>	The problem has been that we don't build models.
> There has been proposals that we build prototypes instead.
> This may be okay as long as the prototype never leaves the
> development lab. Prototypes have to be treated as throw-aways,
> especially when they work!
>	My personal opinion is that prototypes are not good enough,
> and that models of software systems are possible. What the techniques
> will be, I don't know. I agree that verbal descriptions cannot be good
> enough. Pictures are better (data flow diagrams and the like) but they
> aren't models, they can't be easily tested. There must be something
> we can use. Suggestions? Opinions?


Ed, we (Richard D'Ippolito, Kenneth Lee, Charles Plinta, Michael Rissman,
Roger Van Scoy, and Jeffrey Stewart) have spent over three years here doing
exactly what you suggest.  Last spring I posted an article describing our
efforts and successes with engineering modeling of software.  I have updated
the article to reflect more recent publications and conferences and have
reposted it below.



In article <1014@afit-ab.arpa> William A. Bralick writes:

>It seems to me that architecture (as in buildings, not computer systems :-) 
>should provide a useful set of lessons for software engineers.  The parallels
>between software engineering and architecture (especially for a large, unique
>building) are striking -- both are labor intensive, lengthy, expensive, 
>prone to schedule slippages and cost overruns, require not only a sound
>design but also good management practices, both can benefit from standardized
>parts, etc.  Has any formal attempt been made to draw on (this pun
>is intentionally left blank) architecture as a model for solving some
>of the problems in software engineering?


I am currently the project leader of a group here at the SEI called Software
Architectures Engineering.  Our primary focus for the last three years has
been to apply traditional engineering practices and techniques to the
development of software.  Most notable among these techniques is the
practice of modeling.

I have found building design (architectural engineering) to be a
particularly fruitful source of examples, parallels, and metaphors when
describing the uses and value of software models.

We have been able to show improvements in the software design process in
several large-scale Ada projects by developing and applying engineering
models.  These models are just what you'd think they are -- architectural
components representing solutions to the recurring patterns encountered in
the various domains.  As modeled solutions, they have known performance
characteristics and structural style, and can be applied with other models
of the same style to create the system architecture.  In effect, one obtains
reuse at the design level, as opposed to the component level.

For example, in the flight-simulator domain, we developed a model (Object
Connection and Update, or OCU) for connecting and updating the objects that
comprise a system[1,2].  This model was used as the architectural base for
the electrical and engine systems within the simulator.  It has been
successfully used on other flight simulator systems (C-17, MV-22, UH-1 and
others), and is being considered as the model to be used in a tri-service
agreement to train engineers, acquisition agents, and program managers in
simulator development issues.

In the C3I domain, we have produced a model for translating and validating
incoming messages[3].  This model, the MTV (Message Translator and
Validator), is being used on one large-scale project and is being considered
for another.  Preliminary reports by the customer indicate that by using the
MTV model, they have achieved over a two-fold increase in productivity and
an order of magnitude reduction in errors.  

Additionally, we are developing models for Ada real-time embedded systems and
are presenting general papers on the uses of models for software
development.  One, in particular, that I have already presented discusses the
models using examples from building architecture[4].  Another will be
presented at the upcoming Tri-Ada conference here in Pittsburgh.  

So, to summarize an answer to Mr. Bralick's question, yes, we have made
formal attempts to introduce the design practices of architects and other
engineers to software development, and have already achieved successes.

We invite you to come to the Tri-Ada conference to hear the following
reports:

	Using Models in Software Engineering.  Richard D'Ippolito, SEI.

	A Model Solution for the C3I Domain.  Charles Plinta, Ken Lee, SEI.

	The Software Life-cycle With Ada: A Command & Control Application.
	Major Mike Goyden, USAF.

	Millimeter Wave Ada Shadow Program.  Steven Pate, Hercules
	Defense Electronics, Inc.

The first presentation is a general discussion of the models and techniques
we used to create them.  The second is a discussion in detail of the MTV
model.  The third, presented by the manager of the project that used the MTV
model, gives the customer's experience with it.  The fourth is a presentation
by a customer who successfully used the OCU model, originally developed to
solve the synchronizing and updating problems in flight simulators, to
structure the executive in a missile seeker.  If you can not make it to the
conference, you can obtain these papers in the proceedings.


Richard S. D'Ippolito
rsd@sei.cmu.edu
412/268-6752



[1] An OOD Paradigm for Flight Simulators, 2nd ed.  CMU/SEI-88-TR-30.

[2] An Object-Oriented Solution Example: A Flight Simulator Electrical
System Example.  CMU/SEI-89-TR-5.

[3] A Model Solution for C3I Message Translation and Validation.
CMU/SEI-89-TR-12.  Due November, 1989.

[4] Software Development Using Models.  International Workshop on Software
Specification and Design, Pittsburgh, May, 1989.
-- 
It is not the possible that determines what to hope for --   
it is hope that determines what is possible.
Richard J. Oman                                               rsd@sei.cmu.edu
-----------------------------------------------------------------------------

diamond@csl.sony.co.jp (Norman Diamond) (10/05/89)

In article <5328@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:

>But about a year ago, I started thinking about aand have given 3 seminars
>on the topic of what I regard as "Empirical Compuert Science."

So who says chaaos theory doesn't apply to our filed?  :-) :-) -):)

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.

jgn@nvuxr.UUCP (Joe Niederberger) (10/05/89)

In article <1142@svx.SV.DG.COM> gary@svx.SV.DG.COM () writes:
>In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:

>Engineers deal with systems that have a finite (possibly large) number of states
>so they can actually test or at least simulate all of them.

So how is this different from computerized systems ? Anyways, I always
thought that "real engineers" used continuous models (i.e., differential
equations) for many systems of concern.

>But look at a simple subroutine with, say, 4 32bit inputs. How many states?
>2^128. How do you test them all or whittle that down automatically without a
>program that understands programs?

Logic and mathematical reasoning have been shown to be equal to the
task. Check, for example, "The Science of Programming" by David Gries. 
Of course, these techniques work best when run on an extremely exotic
type of supercomputer known as the human mind. Fortunately, these
are relatively ubiquitous these days.

Joe Niederberger

munck@chance.uucp (Robert Munck) (10/06/89)

In article <89277.091206UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes:
>I think DFD's are models, ...
>"Verbal descriptions" can be models too, ...
>I wanted to point out that models are reductions of the actual system, and
>by definition they omit some detail.  ...

A good working definition of "model" is "X is a _model_ of Y if X can
be used to answer certain questions about Y."  This makes clear a number
of things about the use of models, including the importance of defining
the question set that a model is intended to answer and being careful
to limit your questions to that set.  It also says that the thing itself
is a model of itself, with no sense of "reduction."
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

shf@well.UUCP (Stuart H. Ferguson) (10/13/89)

+-- bill@pd1.ccd.harris.com (Bill Davis) writes:
| In article <> ejp@abvax.icd.ab.com (Ed Prochak) writes:
| >Prototypes have to be treated as throw-aways,
| >especially when they work!
| 
| I agree with throwing away prototypes when appropriate.
| But, what makes a prototype something that should be
| thrown away if it is working and providing useful
| functions?  Is it because it has "lower quality" or
| because it has bugs?

No.  Prototypes should be treated as a design lab.  The original paper
design invariably gets changed when being implemented, as concerns and
collisions appear that were masked in the "pure thought" stage.  As
result, prototypes tend to be a Krazy Kwilt (tm) of patchs and partially
abandoned approaches.  Once the problem is fully understood, however, the
experiment should be thrown away and the real system built.  Why?  Not
because the prototype doesn't work, but because the design is bad.

The first implementation of any program is, by definition, a prototype.
The real problem is that many so-called products are really prototypes.

|  I use lots of software with
| bugs and the variation in "quality" is large.
| But, this "buggy" software still provides useful
| functions to me when I avoid the bugs.

Functionality is only a part of the picture.  The rest of the picture
includes reliability, support and enhancements.  A good design makes this
part of the process infinitely easier.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(ferguson@metaphor.com)