MDAY@XX.LCS.MIT.EDU (Moderator, Mark S. Day) (02/23/88)
Soft-Eng Digest Tue, 23 Feb 88 Volume 4 : Issue 10
Today's Topics:
CASE tool usage
C Portability Metrics
Fourth Generation Language (4GL) Assessment
Is it Art or Engineering? (4 msgs)
Call for Papers: HICSS 22
Call For Papers: MIDCON/88
----------------------------------------------------------------------
Date: 19 February 88 11:16-PAC
From: COSTEST%IDUI1.BITNET@CUNYVM.CUNY.EDU
Subject: CASE tool usage
I'm interested in investigating the degree to which the current
generation of CASE tool products are actually being used in software
development organizations. Examples of the tools that I have in mind
follow (this in not intended to be a thorough list):
Excelerator from Index Technology
IEW/Analysis Workbench and Design Workbench from KnowledgeWare
Teamwork from Cadre
These products have been on the market for several years. But, despite
considerable advertising and marketing efforts by the vendors and a
lot of articles devoted to CASE in the journals and trade
publications, the contacts that I've made with industry indicates to
me that CASE isn't making its way into the software development
organizations. Have you seen similar indications?
Another interesting reaction that I've seen is that many software
developers view CASE tools as not being appropriate for analysts and
software developers to use directly. Rather, they view them as
appropriate for a "software technician" to use under the general
guidance of the analyst or designer. The analyst/designer would
rather spend his/her time "sketching" on paper, then let the
technician worry about how to get it represented effectively with the
CASE tool. My own recent experience in evaluating one of the
KnowledgeWare products (for the March issue of IEEE Software) tended
to support this observation. I found that I spent too much time
trying to get data flow diagrams to "look right" rather than spending
my time on the technical issues. Has anyone experienced a similar
situation?
For those who have not had direct experience in using CASE tools I'd
be interested in your reaction to the products that are currently on
the market. Specifically, if there is a reason why you (or your
organization) don't use CASE tools, I'd like to know about it.
Finally, for those people in organizations that have developed their
own CASE tools can you give me some insight into what advantages
and/or disadvantages your in-house tools have? Are the current,
commercially available tools deficient in some way?
Bill Junk, Computer Science Dept., University of Idaho, Moscow, ID
83843 (208) 885-7530
E-Mail: COSTEST at IDUI1 on BITNET
------------------------------
Date: Tue, 16 Feb 88 10:03 EDT
From: <CLSTAM01%ULKYVX.BITNET@MITVMA.MIT.EDU>
Subject: C Portability Metrics
I am working on a thesis dealing with C portability between ULTRIX and
UNIX System V. Do you know of any C portability metrics? Please send
reply thru gmail. Thanks.
------------------------------
Date: Wed, 17 Feb 88 17:08:02 EST
From: nigam@mitre.arpa
Subject: Fourth Generation Language (4GL) Assessment
I am investigating the use of fourth generation languages in
large software projects. I am interested in specific
experiences, and information on the factors which affect the
success or failure of such projects, such as type of
application, complexity, language selected, and
characteristics of data base. I would also like to hear
about the availability of software engineering tools and
techniques for 4GLs, software development life-cycle models,
and other issues relating to the use of 4GLs.
If you can recommend any material on this subject, or have
experiences of your own you are willing to share, please send
me a note. Thanks.
Alok C. Nigam ARPA: nigam@mitre.arpa
The MITRE Corporation Phone: (703) 883-6751
7525 Colshire Drive
McLean. VA 22102-3481
------------------------------
Date: 11 Feb 88 14:41:18 GMT
From: ihnp4!ihlpf!warren@ucbvax.Berkeley.EDU (Montgomery)
Subject: Is it Art or Engineering?
The question of whether software art or software engineering more
correctly describes what software people do is age old. While
software development has aspects of both to it, I'd like to suggest
that the dominant aspect for any large project is neither, it's
management of complexity.
In large systems, there are tasks that are clearly engineering.
Picking data structures and algorithms to achieve a desired level of
fault tolerance is one that comes to mind, as is figuring out how to
cope with widely varying loads with acceptible performance.
The enterprise that to me most clearly models a software development
is that of publishing a large multi-author document, such as a
newspaper, a magazine, or an encyclopaedia. There is a large part
of the input that is creative in nature, both in determining overall
structure and in filling in the sections. There are also many
specialized sub-problems, such as page layout, printing, production
of figures, obtaining the rights to material taken from other
sources, etc. A lousy product will be produced if the basic
creative talent of the people who must supply it isn't up to the
task. The best printing and layout in the world won't sell a
newspaper with poor writers. Assuming that this is taken care of,
though, the dominant concern is managing the thousands of individual
tasks involved so that they come together when required to make a
product.
Warren Montgomery ihlpf!warren
------------------------------
Date: 13 Feb 88 01:42:20 GMT
From: noise@eneevax.umd.edu (Johnson Noise)
Subject: Is it Art or Engineering?
In article <1879@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes:
>Engineers typically work with known quantities and predictable results.
>What they're doing has usually been done before and is well understood.
>(e.g.: We've built a lot of office buildings. We know how long it takes
>to put up girders and floors and wiring. There are tables of beam sizes
>and riveting codes, etc.). That's why PERT charts work so well with
>engineering projects.
I think you are quite wrong. There are many types of buildings
that have not been designed or built (e.g. sufficient structure to with-
stand natural forces etc.), but what do I know? I'm an electrical clown
myself.
>Software designers/builders, on the other hand, are usually doing something
>that hasn't been done before. If it had been, why do it again? Why not
>just copy it? (It's a bit difficult to copy an office building (-: ).
Uh, no. Think about the algorithms that are commonly used in
most programs. I think you will find that most of the ideas were
conceived 20-30 years ago. I am not suggesting that new techniques are
not discovered or "designed", but think about it.
>Software is a more creative, seat-of-the-pants endeavor than "hard"
>engineering. There are no tables of beam strengths or fluid flows to
>refer to. There are standard references for limited types of algorithms
>and these generally are copied rather than built from scratch. But the
>reason for any new software project is to make a computer do something it
>hasn't done before. There are many unknowns in such an undertaking, which
>is why the PERT model doesn't fit software development very well. There's
>still some art to it.
I think you should spend a little more time on the other end of
your RS-232 cable before making such a statement. I am an electrical
engineer, but I have been programming for almost as long. I try to look
at both worlds and I think that there not enough poeple with open minds.
Philosophy about man-machine interaction is useful, but a machine is still
a machine, and man is not.
There has been change. In machines it is mostly speed, not concepts.
In programs, mostly nomenclature. We are not programmers any more, we
software engineers. Fortran, LISP, SNOBOL, Unix, they are all very important
milestones, but not of this generation. What more has been accomplished
through the change of names? Not nearly as much. We should focus more on
what to do, how to do it, and not the labels.
Art is subjective, and that can't be changed. A friend of mine is
making the final fixes to a 500MW pulsed power modulator. He designed it,
built it, and will sign it like any artist would.
------------------------------
Date: 15 Feb 88 14:59:08 GMT
From: uh2@psuvm.bitnet (Lee Sailer)
Subject: Is it Art or Engineering?
In article <1553@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) says:
>
>In article <hpisod2.16520001> decot@hpisod2.HP.COM (Dave Decot) writes:
>>I agree that the distinguishing characteristic between what this
>>"industry" does and engineering is the general unexpectation that what
>>is produced will perform exactly as specified.
> ^^ ^^^^^^^^^
>
>There's the rub. If we had a notation sufficiently precise to completely
>specify what our programs were supposed to do, we would use this specification
>language as a programming language, write a compiler, and then they would
>perform exactly as specified. Denotational semantics has been pushed in that
Yes, but...
A specification language would specify exactly *what* was to be done,
but not necessarily *how*. E.g., "...ans sort the file in less than
5 seconds..." is a specification, but not a compilable program.
Of course, languages like Prolog are moving that way...
lee
------------------------------
Date: Tue, 16 Feb 88 13:37:29 PST
From: Jennifer Dyck <dyck@csufresno.edu>
Subject: Call for Papers: HICSS 22
CALL FOR PAPERS AND REFEREES
HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES - 22
COGNITIVE ASPECTS OF SOFTWARE DEVELOPMENT
KAILUA-KONA, HAWAII - JANUARY 3-6, 1989
The Software Track of HICSS-22 will contain a special set of papers
focusing on a broad selection of topics in the area of Cognitive
Aspects of Software Development. The presentations will provide a
forum to discuss new advances in theory and applications in human-
computer interaction (HCI). In particular, this session concerns the
application of HCI research to the solution of a fundamental software
engineering problem: improving human productivity. The field of HCI is
sufficiently broad to include investigations of user interfaces, pro-
gramming language factors that influence code development, and human
problem solving and system design techniques.
Papers are invited that may be theoretical, conceptual, tutorial
or descriptive in nature. Those papers selected for presentation
will appear in the Conference Proceedings which is published by
the Computer Society of the IEEE. HICSS-22 is sponsored by the
University of Hawaii in cooperation with the ACM, the Computer
Society, and the Pacific Research Institute for Information Systems
and Management (PRIISM). Submissions are solicited in:
* Recent developments in interface design.
* Methods for maximizing acquisition of programming skill.
* Models of human problem solving and their relation to software design.
* Empirical comparisons of existing interface technologies.
* Expert-novice differences with respect to use of operating systems and
programming languages.
* Empirical results of teaching and using software design techniques.
* Aspects of programming language design that affect productivity,
maintainability, and reliability.
* Mental models of operating systems and the implications for learning
and design.
* Transfer of training and experience between systems.
INSTRUCTIONS FOR SUBMITTING PAPERS
Manuscripts should be 22-26 typewritten, double-spaced pages in
length. Do not send submissions that are significantly shorter or
longer than this. Papers must not have been previously presented
or published, nor currently submitted for journal publication.
Each manuscript will be put through a rigorous refereeing pro-
cess. Manuscripts paper should have a title page that includes the
title of the paper, full name of its author(s), affiliation(s),
complete physical and electronic address(es), telephone number(s)
and a 300-word abstract of the paper.
DEADLINES
* A 300-word abstract is due by March 30, 1988.
* Feedback to author concerning abstract by April 15, 1988.
* Six copies of the manuscript are due by June 6, 1988.
* Notification of accepted papers by September 1, 1988.
* Accepted manuscripts, camera-ready, are due by October 3, 1988.
SEND SUBMISSIONS AND QUESTIONS TO
Dr. Brent Auernheimer Dr. Jennifer L. Dyck
Computer Science Department Psychology Department
California State University California State University
Fresno, CA 93740-0109 Fresno, CA 93740-0011
(209) 294-4373 (209) 294-2691
csnet: brent@CSUFresno.edu csnet: dyck@CSUFresno.edu
------------------------------
Date: 17 Feb 88 15:25:12 PST (Wednesday)
From: "Alan_T._Cote.OsbuSouth"@Xerox.COM
Subject: Call For Papers: MIDCON/88
I have been asked to chair a technical session at MIDCON/88. The intended
topics for the session range from methods for management of a distributed
software development environment to software engineering methodologies and
strategies.
Admittedly, the time is short. I've only just received the details given below,
or I'd have posted sooner. If you plan to submit a paper, would you be kind
enough to respond to this message by E-mail? My receipt of the DL may be
occasional, at best.
Please feel free to REDISTRIBUTE THIS MESSAGE as you see fit.
Thanks to all who respond.
- Alan T. Cote'
----------------
Call For Papers
MIDCON/88 Technical Conference
Sponsored by IEEE Regions 5 & 4, Dallas and Chicago IEEE Sections, Southwest
and Chicago ERA Chapters and Central U.S. ERA Council
August 30 - September 1, 1988
Dallas, Texas
SUBMISSION OF PAPERS
Papers describing original work, tutorials, or reviews are solicited for a 25
minute presentation and printing in the Conference Digest for topics related
to Software Engineering and the Distributed Development Environment.
Student papers are encouraged.
INSTRUCTIONS TO AUTHORS:
Authors are requested to submit two copies of a one page summary (single
sided; 500 words maximum) which clearly describes the work, and at most
two additional pages of figures, drawings, and references.
The summary should clearly state:
a) the purpose of this reported work
b) the manner and degree to which this work contributes to the art
c) specific results and their significance
Each page should include the following information:
1) title of paper
2) name, mailing address, and telephone number of primary author
3) name, affiliations, city, state, country of additional authors
4) person to whom correspondence should be sent if other than primary
author
DEADLINE
These materials should be sent by 25 February, 1988 to:
Midcon/88 Technical Conference Committee
c/o Electronic Conventions Management
Educational Activities Department
8110 Airport Boulevard
Los Angeles, CA 90045
Appropriate company and government clearances must be obtained prior to
this date for both summary and paper.
ACCEPTANCE AND TIMETABLES
Authors will be notified of the Committee's decision on acceptance by mid-
March, 1988. Authors of accepted papers will receive an author's kit with
instructions for the preparation of the camera-ready copy (four pages
maximum) of the paper to be published in the Midcon/88 Conference Digest.
The camera-ready copy will be due May 27, 1988.
Other information can be obtained from:
Alan T. Cote'
Xerox Corporation
Mail Stop ESM4-53
401 Coral Circle
El Segundo, CA 90245
(213) 333-9288
(see return address, above, for E-mail)
TECHNICAL CONFERENCE CHAIRMAN
Alton L. Estes
Texas Instruments Incorporated
GaAs Operations
Defense Systems & Electronics Group
Mail Stop 404
P. O. Box 655474
Dallas, Texas 75265
(214) 995-5230
TECHNICAL CONFERENCE VICE CHAIRMAN
John Barnett, Jr., P.E.
Texas Instruments Incorporated
System Engineering
Semiconductor Group
Mail Stop 8201
P. O. Box 655303
Dallas, Texas 75265
(214) 995-3000
------------------------------
End of Soft-Eng Digest
******************************
-------cl@datlog.co.uk (Charles Lambert) (03/11/88)
In Soft-Eng Digest V4 #10: >Subject: CASE tool usage > >I'm interested in investigating the degree to which the current >generation of CASE tool products are actually being used in software >development organizations. This subject is probably of sufficiently general interest for an open discussion in this newsgroup; I vote that respondents post instead of mailing. --------------------- Charles Lambert Data Logic UK