soft-eng@MITRE.ARPA (Alok Nigam) (11/03/88)
Soft-Eng Digest Thu, 3 Nov 88 V: Issue 41
Today's Topics:
'Runaway' Computer Projects
Call for Papers/Participation
CASE
Environments, maintenance
ethics
Instructional CASE tools desired
Quality Metrics in Software
Re: Software Maintenance
Software Library
Software Maintenance
Structured Editor vs. Text Editor (2 msgs)
Wanted: Info on Full-Featured CASE Tools w/Real-Time Support
----------------------------------------------------------------------
Date: 30 Oct 88 13:22:13 PST (Sunday)
From: Rodney Hoffman <Hoffman.es@Xerox.COM>
Subject: 'Runaway' Computer Projects
In the November 7, 1988 issue, 'Business Week' has a two-page story
headlined "IT'S LATE, COSTLY, INCOMPETENT -- BUT TRY FIRING A COMPUTER
SYSTEM: Companies get stuck with 'runaways' that trample all over their
budgets and reputations." Nothing amazingly new, but a good summary of the
problems, with several case histories.
>From the article: "A recent Peat Marwick Mitchell & Co. survey of 600 of
the accounting firm's largest clients highlighted the problem: Some 35%
currently have major runaways.... In 1986, [a management consultant] set up
a group at Peat Marwick to rein in runaways. Since then, he has had $30
million in revenues from nearly 20 clients...."
Two sidebars are of interest:
A SAMPLING OF 'RUNAWAY' PROJECTS
* ALLSTATE INSURANCE. In 1982, with software from Electronic Data
Systems, the insurer began to build an $8 million computer
system that would automate it from top to bottom. Completion
date: 1987. An assortment of problems developed, delaying
completion until 1993. The new estimated price: $100 million.
* CITY OF RICHMOND. In 1984 it hired Arthur Young to develop a
$1.2 million billing and information sytem for its water and
gas utilities. Completion date: March, 1987. After paying
out close to $1 million, Richmond recently canceled the contract,
saying no system had been delivered. Arthur Young has filed
a $2 million breach of contract suit against the city.
* BUSINESS MEN'S ASSURANCE. In 1985 the reinsurer began a one-
year project to build a $500,000 system to help minimize the
risk of buying insurance policies held by major insurers. The
company has spent nearly $2 million to date on the project, which
is in disarray. The new completion date is early 1990.
* STATE OF OKLAHOMA. In 1983 it hired a Big Eight accounting firm
to design a $500,000 system to handle explosive growth in workers'
compensation claims. Two years and more than $2 million later,
the system still didn't exist. It finally was finished last year
at a price of nearly $4 million.
* BLUE CROSS AND BLUE SHIELD UNITED OF WISCONSIN. In late 1983 it
hired Electronic Data Systems to build a $200 million computer
sytem. It was ready 18 months later -- on time. But it didn't
work. The system spewed out some $60 million in overpayments
and duplicate checks before it was harnessed last year. By
then, Blue Cross says, it had lost 35,000 policyholders.
[Several of these are discussed in more detail in the article.]
---
HOW TO KEEP A PROJECT UNDER CONTROL
* Before designing the system, get suggestions from the people
who will use it.
* Put senior, nontechnical management in charge of the project
to help ensure that it is finished on time and within budget
* Set up 12-month milestones -- interim deadlines for various
parts of the project
* Insist on performance clauses that hold suppliers legally
responsible for meeting deadlines
* Don't try to update the system in midstream, before the original
plan is finished
------------------------------
Date: 1 Nov 88 19:55:57 GMT
From: sei!gibbs@pt.cs.cmu.edu (Norman Gibbs)
Subject: Call for Papers/Participation
Call for Papers
THIRD SEI CONFERENCE ON SOFTWARE ENGINEERING EDUCATION
PITTSBURGH, PENNSYLVANIA
JULY 17-18, 1989
The SEI Conference on Software Engineering Education is an annual
conference that brings together educators from universities,
industry and government to discuss issues of mutual interest, with
the goal of promoting educational improvements for the emerging
discipline of software engineering.
The program committee invites papers and proposals for panels and
special sessions on all aspects of software engineering education.
We are interested in discussions of successful experiences at any
level (industrial, undergraduate, graduate) and on any pertinent
topic. We are particularly interested in papers and proposals in
the following areas:
- Industry Education Issues: How should in-house education
and training be structured to be most cost-effective?
What is an effective mix of in-house, vendor, university,
and technology-based education and training? How can
education and training be integrated with process groups
or other technology transfer mechanisms?
- Teaching Large Systems Issues: How can concepts of large
software systems be taught within the constraints of the
educational setting? Can the objectives of reuse be
extended from the level of algorithms and data structures
to the realm of large systems architectures? How can we
teach the team cooperation and communication skills
required for building large systems? How should we teach
system integration testing?
- Foundations for Software Maintenance: What disciplines
and principles underlie the skills required for software
understanding and modification? How can these skills be
taught and their importance communicated early in the
curriculum?
- Teaching Issues of Embedded Systems: What are the
foundations and principles of embedded, real-time,
distributed, and concurrent systems? How can these be
taught in a personal computer-based educational
environment?
All papers will be refereed. The proceedings will be published by
Springer-Verlag in its Lecture Notes in Computer Science series.
Authors should submit five copies of complete papers by February
10, 1989. Notification of acceptance or rejection of papers will
be sent March 10, 1989. Final versions of accepted papers in
camera-ready form must be received by April 17, 1989. Authors will
be asked to sign a copyright release form.
Papers, proposals and requests for additional information should be
addressed to:
Norman E. Gibbs ARPAnet: gibbs@sei.cmu.
CSEE Program Committee Telephone: (412) 268-77
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Program Committee
Alan Adamson, IBM For the SEI:
Jon Bentley, AT&T Bell Labs Mark Ardis
John Brackett, Boston University Maribeth Carpenter
Rick Cobello, General Electric Lionel Deimel
James Collofello, Arizona State Charles Engle
Richard Fairley, George Mason Robert Firth
Susan Gerhart, MCC Gary Ford
Hassan Gomaa, George Mason Norman Gibbs
David Lamb, Queen's University John Goodenough
Dieter Rombach, Maryland Harvey Hallman
Rebecca Smith, Hewlett-Packard John Maher
James Tomayko, Wichita State Scott Stevens
David Weiss, SPC Nelson Weidermann
The Software Engineering Institute (SEI) is a federally funded
research and development center operated by Carnegie Mellon
University. Part of its mission is to promote and support software
engineering education throughout the educational community.
------------------------------
Date: Mon 31 Oct 88 17:33:50-EST
From: G. Batt <BATTG@a.isi.edu>
Subject: CASE
1) Over 100 vendors are offering CASE tools that purportedly
increase productivity from 10% to 1000%, yet none has verifiable
proof to the claims.
2) The Department of the Air Force claims to have over four years
of software development backlog. The Navy and Army either refuse
to make those facts public or haven't bothered to measure the
backlog - I believe the latter.
3) The Department of Defense sticks to the waterfall paperwork
monster of DoD-STD 2167A that generates 48 lines of text per line
of Code (per SEI). Increased productivity is almost impossible
under those conditions.
4) The Navy Supply Systems Command has standardized on the Texas
Instruments CASE tool IEF without any command working for them
having used it (to my knowledge).
5) Everyone from Barry Boehm to Ed Yourdon claims that CASE will
increase software productivity. Ed Yourdon is even building a
tool with your institution that will have a repository of
software modules that will be recallable by an expert system for
reuse.
6) At the Navy Postgraduate School we are attempting to teach
Computer Systems students how to improve software qualify and
software productivity. My thesis research is an attempt to find
those commands in DoD and firms associated with DoD using CASE
tools, quantify how the tools have effected the life cycle of
software developed using CASE and most importantly what realistic
expectations both end users and systems developers should have by
the adoption of CASE. The thesis research is be conducted for
the Department of the Navy and is public domain information that
will be available through the Navy Postgraduate School.
-----------------------------------------------------------
CASE **** Computer Aided Software Engineering
I-CASE **** Integrated Computer Aided Systems Engineering
Thanks for reading this message!
I am researching how CASE and I-CASE are effecting the Life Cycle
of Software Development (including those required to comply with
DoD-STD 2167A and 2168). I would like to talk to both software
development managers and end-users regarding applications
software that has been developed using CASE tools.
If you are using CASE or I-CASE (Excelerator, Design Aid, CASE
2000, Code generators, Code regenerators, etc.) please send me
mail with Points of Contact (Names, E-mail address, and Phone
numbers) at:
BATTG@A.ISI.EDU or 2753P@NPS.ARPA.
Gary T. Batt
Naval Postgraduate School
SMC 1994
Monterey, CA 93943
------------------------------
Date: Mon, 31 Oct 88 21:34:35 CST
From: johnson@p.cs.uiuc.edu (Ralph Johnson)
Subject: Environments, maintenance
I will disagree that the Lisp machine environment is best---I think
that Smalltalk has the better environment. Although the documentation
is not as well done, the libraries are better organized, and the tools
in the environment are every bit as good. Of course, I have never used
a Lisp machine long enough to be an expert in it, and the Lisp machine
experts around here have never used Smalltalk. I only know one person
who has a fair bit of experience with both. He prefers Smalltalk, but
a sample size of one is not significant.
The ability of a system to support software reuse depends in large part
on the quality of its library. The Smalltalk library excels in building
user interfaces, while Lisp machines are mostly used for AI and so
probably excel in that area.
There is no doubt that object-oriented programming (which is a lot more
than "programming with objects") can dramatically reduce the cost of
software maintenance. Careful use of polymorphism and inheritance
can greatly reduce the size of a system. Reuse of software and design
can reduce the effort in learning what a system does and how to change
it. The main reason that maintenance is so expensive is that it is
very hard to figure out how existing system work and so be able to
change them. Thus, object-oriented programming can greatly reduce
the cost of maintenance.
------------------------------
Date: Tue, 1 Nov 88 16:42:18 -0500 (EST)
From: Leslie Burkholder <lb0q+@andrew.cmu.edu>
Subject: ethics
I'd appreciate lists or accounts of ethical problems faced by software engineers
in practicing their profession.
------------------------------
Date: 27 Oct 88 20:07:18 GMT
From: edrbtsn@iuvax.cs.indiana.edu (Ed Robertson)
Subject: Instructional CASE tools desired
Our department is planning to establish an instructional laboratory for CASE
(Computer Aided Software Engineering) tools. This lab will be for graduate
and advanced undergraduate students. Our budget is limited so we are looking
for advice on the most cost-effective software and hardware.
The hardware environment for this lab will almost certainly be 286-class
machines or Macs (hard disk, enough primary memory, decent monitor & mouse).
However, we don't expect to be able to afford Sun-Apollo class machines.
The software we are looking for includes tools for specification and design
(data flow, entity-relationship, HIPO, Warnier-Orr, Jackson, ... diagrams),
implementation (change and configuration control, generic application
generation), testing, verification and validation, and project management
(PERT, milestones, and other scheduling, resource managment, ...).
Any suggestions about inexpensive, high-quality software (and hardware) would
be appreciated (especially public-domain software). I would appreciate
hearing from other institutions with experience in setting up such a lab.
------------------------------
Date: 28 Oct 88 20:57:31 GMT
From: mnetor!motto!russ@uunet.uu.net (Russell Crook)
Subject: Quality Metrics in Software
I am looking for references (both practical and theoretical) on
metrics that can be applied to software quality. I have
no idea what research has been done on such things; I imagine
that things like number of bugs found per [module, line, program,
system], number of reported problems, average time taken to correct a
given problem, ratio of design time expended to coding time ... whatever
has been done (or even proposed to be done) could be used. Reports on
language issues (i.e., certain languages make it easier to write "high
quality" programs than others, general availability of certain software
tools in certain environments (e.g., "lint" for C, PFORT for profiling
Fortran-66)) are also of interest.
Please send e-mail; if there is enough information, I will post
a summary of what is found.
------------------------------
Date: 31 Oct 88 04:31:32 GMT
From: tektronix!reed!psu-cs!warren@bloom-beacon.mit.edu (Warren Harrison)
Subject: Re: Software Maintenance
It's funny someone should ask about software maintenance just now. I just
returned from about a week in Phoenix at the Annual Conference on Software
Maintenance. Anyone seriously interested in maintenance should start with
the proceedings of the last four or five CSMs. They can be ordered from
IEEE (I saw at least the last two proceedings for sale at the conference).
You might also want to check into the Software Maintenance News Newsletter (?)
published by Nicholas Zvegintzov - call 718-816-5522 $30 per year. Not much
research, but well worth teh price to see what the issues seem to be and how
they are being attacked by commercial groups.
------------------------------
Date: 1 Nov 88 21:50:32 GMT
From: mailrus!ulowell!cg-atla!duane@ohio-state.arpa (Andrew Duane)
Subject: Software Library
I have just been placed into a Corrective Action Team at my company
to look into the issues involved with starting and running a
company-wide software library. This library would serve primarily as
a safe place to archive "part-numbered" product code at release time.
This is code that is REQUIRED in various product lines, and should be
shared among projects. It is not entire projects, but simple pieces
that will need to be used elsewhere now and in the future. Examples
are:
* Production kernel drivers for one of our in-house
built boards.
* The standard composition package for our composition
machines.
* Diagnostic boot ROMs for various sun3-based products.
* Useful bitmap/mouse menu packages and fill routines.
All of these items (and we have many more) share several attributes:
they are written once to a spec, and then will need to be used in
other places besides where they were originally written. They are
actual product code: we sell them with our machines, and customers
would like to know that composition would be the same on CG model 1
and CG model 2 and CG model foobar-12345.
The software engineers on the various projects currently use a very
informal approach; I need the driver to this board, so I call up
someone else that I know uses it and get his local pathname to copy
it from. The obvious result is a chaos of different versions, bug
fixes that only make it to some machines, and so on.
I am interested in how other companies deal with this. We are trying
to keep it as simple as posible, knowing how engineers even hate to
be forced to use (ACK!) sccs. We envision something like a UUCP
public archive site (on ethernet) that keeps an index of what is
available and allows retrieval of copies, almost like a lending
library. The problem is how to ENFORCE putting these pieces there,
and how smooth the ruffled managerial feathers when they find out
they won't get the credit for writing this piece of code in their
department.
Please try to E-MAIL (decvax is the preferred route). I will
summarize if I get enough useful responses.
Andrew L. Duane (JOT-7) w:(508)-658-5600 X5993 h:(603)-434-7934
Compugraphic Corp. decvax!cg-atla!duane
200 Ballardvale St. ulowell/ \laidback
Wilmington, Mass. 01887 cbosgd!ima/ \cgeuro
Mail Stop 200II-3-5S ism780c/ \wizvax
------------------------------
Date: Tue, 01 Nov 88 17:35:49 PST
From: PAAAAAR@CALSTATE.BITNET
Subject: Software Maintenance
I'd like to stir this up a bit so I'll stick my neck out on a preposterous
prognostication:-)} (time for a beard trim).
** SOON, ALL SOFTWARE ENGINEERING WILL BE MAINTENANCE **
The reason for this conclusion is the following:
First
Last spring I was drawing a diagram of the trad "Sofware Life Cycle" for
a class. It was a Data Flow Diagram that showed:
External entities like 'System', 'users',...
Data stores like 'Requirements' 'Specifications' 'User Documentation',...
Processes like 'Analysis', 'Design', 'Implement' 'Maintenance',...
All went well until I got to the last process - 'Maintenance' -- and
noticed that it was connected to all the data stores in the system.
So I redrew the DFD with 'Maintenance' in the centre of the Software
Life Cycle, rather than at the end of it.
Later,
I needed to analyse 'Maintenance'.
When done I had got 'Analyse', 'Specify change', 'Implement',...
It looked like a a copy of the software life cycle.
I had found 'software life cycle' as a part of
the 'software life cycle'.
I redrew the first DFD with the original Maintenance bubble expanded
so it surrounded the Software Life Cycle
which becomes ... an endless cycle of analyse, specify,
implement, train, monitor, etc with no separate maintenance phase at all,
just one long maintenance cycle.
------------------------------
Date: 27 Oct 88 19:43:12 GMT
From: mtxinu!sybase!alf!malcolm@bloom-beacon.mit.edu (Malcolm Colton)
Subject: Structured Editor vs. Text Editor
In the PC marketplace, Brief from Underware and Associates (?)
is fully programmable, using a lisp-like language. There are sets of macros
available that support syntax construction in C, dBase, and (I think) Pascal.
This is somewhat short of syntax _checking_, but gives you faster
syntactically correct program entry. You can override the actions of the
macros at any time with the cursor keys.
With a lot of ingenuity and skill, you could write syntax checking macros.
------------------------------
Date: 29 Oct 88 00:17:21 GMT
From: martin@umn-cs.arpa (Johnny Martin)
Subject: Structured Editor vs. Text Editor
>>The structure editor will guarantee the
>>result of editing is legal for the specific programming language, of course.
^^^^^
-- NOT ALWAYS TRUE.
>>So, in that point, it is superior to the simple text editor. But, I feel
>>most of the existing structure editors are not so friendly for me. Say,
>>when I want to move a cursor downward and to insert words, I may not do it
>>straight in the structured editor. How do you think? I know, it may
>>depend on programmers' taste. Or, does anyone around there know the editor
>>that has both characteristics of the text editor and those of the structured
>>editor, i.e., in which we can move the cursor in the same way as in the text
>>editor and which guarantees the result of editing are legal to the language?
>
>My research group at the University of Illinois has written a language
>oriented editor, Leif, that has most of the characteristics you describe.
>First, the program may be edited with text editing commands and the text is
>also analyzed to locate syntax errors. Also, commands are available to select
>syntactic elements of the program. Leif may be targeted to several
>different languages by writing a new specification in Bison and Lex.
>
>I believe that guaranteeing that the result of the editing is legal in the
>language is too strict.
-- I CANNOT DISAGREE MORE.
> When I am translating a program from one language to
>another, or performing a complex editing change, I often make the program
>syntactically incorrect but will the later correct the error. Leif
>accommodates this desire by postponing its analysis until a request is made.
-- IN A TRUE SDE, TRANSLATION CAN BE AUTOMATED.
>The command move-to-error will find any syntactic errors and help correct
>them.
There appears to be much confusion about the current state of development
in language-based editors. Perhaps this is due to the fact that most of the
research issues have been settled, and that building a good editor has become
an engineering problem. We must now rely on industry to produce syntax-
directed editors that are of production quality.
First of all, lets get the terminology straight.
LBE, language based editor = an editor that knows something of the program
under construction. This is a broad definition. For example, emacs with
its minor modes probably qualifies as an LBE, as do some of the PC-based
Pascal editors. CPS (the Cornell Program Synthesizer) also falls under
this definition.
SDE, syntax directed editor = an editor that rigidly conforms to the syntax
of a program language, i.e. its CFG or BNF definition. These editors have
the BNF built right in.
structure editor = although this refers to any editor that is capable of
editing some possibly non-syntactic structural object, its common use
in the literature refers to SDE.
Now, back to the state of the point...
Syntax-directed editors can be as "user-friendly" as text editors, and
Syntax-directed editors can provide editing (transformational) power than
text editors.
1. SDE's do not guarantee that (just because the syntax is correct) a program
will compile correctly. Consider type checking or scoping errors.
2. The SDE's that are popular in the literature (e.g. Cornell's CPS,
Carnegie-Mellon's ALOE, etc.) are wonderful, "proof-of-concept"
projects, but are basically unusable tools. Poor user interface, slow
as molasses, etc. I have not seen Leif, but its description does not
sound promising, as a research project or otherwise.
3. Editors which claim to be syntax directed, but are actually just text
editors with a syntax checker running in the background, are a sorry
excuse for avoiding the user interface problem of SDE's. They won't
be able to perform some of the powerful transformations that a true
syntax-directed editor might. (Note Bill Smith's comments above about
introducing errors intentionally to effect a transformation!)
DISCLAIMER: obviously, since emacs is Turing complete it could simulate
everything a SDE does, but slowly.
4. True syntax-directed editors with nice user interfaces are a godsend.
The hardest part about implementing a syntax directed editor is the user
interface. Getting those arrow keys to correspond to the right tree
traversal, while appearing to move only one character on the screen
is tough. It seems our friend has avoided this by implementing a text
editor, instead.
True SDE's have great power, since the program tree is right there
they can perform seemingly impossible transformations.
Besides the neato stuff for filling in templates, at the
touch of a button a good SDE might...
A. transform one indentation scheme to another
B. highlight keywords
C. conversion from Pascal code to Ada code
D. display only procedure calls without bodies
E. other types of summaries (showing only relevant details of constructs)
F. ellipsis (hide the parts of the program I don't want to see)
G. display only documentation/comments
(nice for managers that can't read code)
H. display only raw code
(nice for hackers that can't read documentation)
I. display the code in another spoken language
(nice for immigrant workers that can't read English)
I would suggest taking the time to become familiar with a good SDE with
all the bells, and whistles, and user interface stuff before you decide
that text editors are the only answer.
For example, my favorite SDE in the Program Composer, by Xinotech Inc.
The Composer is perhaps the first production quality syntax directed editor
ever made. It has all of the features above, uses fancy windows and a mouse
interface. I don't know how much it costs, but it's probably worth whatever
they charge.
Their address is,
Xinotech Research, Inc.
Technology Center, Suite 203
Minneapolis, MN 55414
(612) 379-3844
I think they give out demo copies, but I'm not sure...--
------------------------------
Date: 31 Oct 88 17:46:05 GMT
From: pacbell!varian!vaxwaller!davem@ames.arpa (David Michelsen)
Subject: Wanted: Info on Full-Featured CASE Tools w/Real-Time Support
We have decided that it is time to jump on the CASE bandwagon
and are looking for recommendations for full-featured Structured
Analysis and Design systems that support the the Real-Time
Extensions (Ward/Mellor, Hatley, State Transition Diagrams).
We have looked at several of the PC-Based systems and have
decided that Excelerator/RTS (Index Technology) is probably
the only one that would minimally meet our requirements.
Unfortunately, the user interface and the graphics capabilities
leave something to be desired.
Based on our findings, we have decided to expand our search to
include those that run on workstations (Sun, Apollo, VaxStation, etc.).
Has anyone had any experience (good/bad) with systems such as
Teamwork (Cadre) or Software Through Pictures (IDE) or any others?
The real important features we must have include:
o Full Set of Models (Context Diagrams, Trans. Graphs,
DFDs, STDs, ERDs, Structure Charts, etc)
o Data Dictionary (With Records, Elements)
o Verification and Validation Tools for both the Diagrams and
the Data Dictionary.
o Full Real-Time Support
o Good Graphics and User Interface
o Configuration Management
------------------------------
End of Soft-Eng Digest
******************************jameson@cpsc.ucalgary.ca (Kevin Jameson) (11/04/88)
For the record, the Xinotech Program Composer mentioned earlier in this group retails in a PC version for $2250.00 US, with quantity discounts, implementations for Vaxes, etc, etc. The glossy (and price) seem to be heavily oriented toward ADA.