soft-eng@MITRE.ARPA (Alok Nigam) (01/08/89)
Software Engineering Digest Saturday, 7 Jan 1989
Volume 6 : Issue 1
Today's Topics:
Re: Software Metrics
Re: Vendors of Ada ADTs
New mailing list for DSEE (high-powered alternative to SCCS/make)
Workshop on Software Metrics
Call for Papers - TENCON'89 - in Bombay (India) - November 89
Saturn V Launcher (WAS: "big endian" and "little endian" - first usage for computer)
------------------------------------------------------------
Date: Tue, 3 Jan 89 10:29:30 EST
From: hunt@lti.com (Jody Hunt x35)
Subject: Re: Software Metrics
One reason for the popularity of the McCabe and Halstead metrics is
their sober approach to measuring complexity at various levels of
granularity. Both can be measured at function/procedure, program
or system levels without getting ridiculously large numbers; whereas
a complexity metric which tries to count actual paths thru a program
would show numbers increasing geometrically for each graduation. In
practical application of complexity metrics, it is imperative that
they apply equally well to programming in the small as to programming
in the large.
------------------------------
Date: 4 Jan 89 05:15:26 GMT
From: imagen!atari!portal!cup.portal.com!Jerome_V_Vollborn@bloom-beacon.mit.edu
Organization: The Portal System (TM)
Subject: Re: Vendors of Ada ADTs
Bill Wolfe sent a note saying that I should clarify my previous posting.
EVB Software Engineering has a package of ADT's that generally follow Grady
Booch's taxonomy. They are a family of generic packages for stacks, lists,
queues, ... There are versions of each ADT for managed/unmanaged, single user/
multi-user, balking/non-balking, ... Write to EVB and they will supply a
sales brochure with all of the details.
Each of the components has three major pieces: a design description, a test
program, and the Ada code. The design description and test cases will answer
Dr. McKay's questions (what services are provided, how well are the services
provided, and under what circumstances) without having to reference the code
itself.
The most impressive things about the GRACE package (to me at least) are (1)
the design documentation is complete for all of the components; (2) the
components are consistantly well commented, documented and tested; (3) the
code is very clean and a very good example of what Ada code should look like
(e.g., exceptions are only used for exceptional conditions not as sneaky
goto's as in Grady Booch's book on reusable components); and (4) Ed Berard
envisions these components as the equivalent of SSI IC's in the hardware
world. Note that the GRACE components have the three elements necessary to
be truly reusable: a design document element, test cases, and source code.
The address for EVB is:
EVB Software Engineering, Inc.
5303 Spectrum Drive
Frederick, Maryland 21701
301-695-6960
I don't have the name of the lady who handles the orders and shipping. I
have changed companies recently and her name got lost.
------------------------------
Date: Thu, 5 Jan 89 11:39:03 EST
From: Steve Hirtle <hirtle@unix.cis.pittsburgh.edu>
UNIVERSITY OF PITTSBURGH
Department of Information Science
The Department of Information Science announces two open
positions for tenure track Assistant or Associate Professors,
with appointments beginning in the Fall Term, 1989.
Candidates must have a Ph.D. in information science, computer
science, or a closely related field. We are particularly
seeking applicants with teaching and research interests in
information systems design, database management, knowledge
bases, information storage and retrieval, microcomputer
systems, image databases, visual interfaces, software
engineering, or the design of interactive systems. We strongly
encourage women and minority candidates to apply. The
Department has eighteen faculty members and offers a Ph.D.
and master's degrees in information science and telecommuni-
cations, and a bachelor's degree in information science.
Current research interests within the Department are broadly
centered on meeting the information needs of the individual
user. Research topics include: information storage and re-
trieval, telecommunications, standards, natural language
processing, visual languages, human-computer interface design,
human information processing, electronic publishing,
and database systems design, including image databases.
The Department has extensive computing facilities, including
a VAX11/780, six Sun workstations, three TI Explorers,
three Xerox Viewpoints, and a large number of microcomputers.
The Telecommunications Laboratory is also well equipped with
an AT&T 3B/15, several smaller computers, and a wide variety
of communications equipment. In addition the Department has
access to the University's computing resources, which include
VAX Clustered 8650s, 8800s and the Cray XMP/48 at the Pittsburgh
Supercomputer Center.
The University of Pittsburgh offers a wide variety of oppor-
tunities to interact with faculty of other departments and
schools including an interdisciplinary program in intelligent
systems and a joint program (with Carnegie-Mellon University)
in computational linguistics. In addition, the Department and
the University have close relations with several major corpora-
tions that are funding research and teaching (Texas Instruments,
XEROX, AT&T, IBM, and DEC).
We seek applicants with balanced research and teaching interests.
Our salaries, benefits, and teaching schedules are highly
competitive. Applicants should send a vita, a statement of re-
search interests, any relevant reprints or preprints, and
three references to: Robert R. Korfhage, Chairman, Department
of Information Science, LIS Building, University of Pittsburgh,
Pittsburgh, PA 15260. The University of Pittsburgh is an
Equal Opportunity/Affirmative Action employer.
------------------------------
Date: 4 Jan 89 17:31:00 GMT
From: apollo!lubkin@beaver.cs.washington.edu (David Lubkin)
Organization: Apollo Computer, Chelmsford, MA
Subject: New mailing list for DSEE (high-powered alternative to SCCS/make)
Preamble, if you don't know what DSEE is:
DSEE is a software engineering environment from Apollo that elegantly and
efficiently solves many common problems -- how to work on multiple versions
of a program at a time, how to tell when someone has made a change you need
to know about, how to develop software for multiple target machines, how to
KNOW the right version of each source file was used, etc. It's used
world-wide by tens of thousands of programmers, on projects up to 5,000,000
lines of code.
If all this sounds like hype, join the mailing list, and ask our users
yourself.
#
At the last ADUS session, I ran an Open Forum on DSEE, where DSEE users could
give us direct feedback on their problems, and what they wanted to see in
future product releases. Often, one user in the room had written a DSEELIB
application which leveraged DSEE in just the way needed by another user.
It became clear to everyone there that user networking was a Good Thing, and
should be perpetuated electronically. Hence:
Submissions to: (ARPA) info-dsee@apollo.com
(UUCP) {mit-eddie,umix,decvax,attunix}!apollo!info-dsee
Requests to be added, deleted or modified:
(ARPA) info-dsee-request@apollo.com
(UUCP) {mit-eddie,umix,decvax,attunix}!apollo!info-dsee-request
------------------------------
Date: 5 Jan 89 05:34:58 GMT
From: oliveb!intelca!mipos3!omepd!psu-cs!warren@ames.arpa (Warren Harrison)
Organization: Dept. of Computer Science, Portland State University; Portland OR
Subject: Workshop on Software Metrics
Thank you to everyone who responded to my earlier posting about the
First Annual Oregon Workshop on Software Metrics, to be held March 1
and 2 in Portland Oregon. If I have your US Mail address already,
you are on our mailing list to receive the brochure.
I am taking the liberty of duplicating it in this posting in case anyone
would like to find out what will be going on at the Workshop. If you
send me your US Mail address, I will make sure you receive a copy of
the brochure when it gets back from the printers. If you'd like to
find out more about the Workshop, give me a call at 503-464-3108, or to
register, call the Oregon Center for Advanced Technology Education
(OCATE) at 503-464-4860, and mention the Workshop on Software Metrics.
While I am partly responsible for the technical program, administrative
details are handled by OCATE so if you want to know if we can take Purchase
Orders or bank cards, if you can just register for one day, or whatever,
call OCATE.
- --------------------------------------------------------------------------
The First Annual Oregon Workshop on
Software Metrics
One of the most exciting developments in the software
industry today is the growing interest in software
measurement and metrics. In response to interest from local
industry, the Oregon Center for Advanced Technology
Education, Portland State University and Oregon State
University are proud to present The First Annual Oregon
Workshop on Software Metrics. The goal of the Workshop will
be to focus on the use of software metrics by industry.
When
The Workshop will be held March 1 and 2, 1989 from 8:30 AM
to 4:00 PM.
Where
The Workshop will be held in the Ballroom at Smith Center on
the Portland State University campus in Portland, Oregon.
Maps, parking permits and hotel information will be sent to
each registrant.
What
Wednesday Morning, March 1.
8:00-8:15 Registration and coffee.
8:15-8:30 Welcome and Introduction, Len Shapiro, PSU and
Walt Rudd, OSU
8:30-11:30 Warren Harrison, PSU A Software Metrics Tutorial
11:30-1:00 Lunch
Wednesday Afternoon
1:00-4:00 The User's Perspective:
o+ Steve Wilkinson, Ashton-Tate, Adding Value to
Metrics for Managers.
o+ Samuel Hon, III, Bell Communications, Assessing
Software Quality Through Measurements - A Buyer's
Perspective.
o+ Ken Oar, Hewlett-Packard, The Use of Metrics for
Improvement of Products and Processes.
o+ Alberto Savoia and Dave Kehlet, Sun Microsystems,
Software Quality Metrics and Applications at Sun
Microsystems.
4:00-5:30 Reception
Thursday Morning, March 2
8:30-11:30 The Researcher's Perspective:
o+ Albert Baker, Iowa State University, Metrics Do's
and Don'ts: Practical Implications from a
Mathematical Perspective on Software Metrics.
o+ Sallie Henry, Virginia Tech, Validation of Metric
Analysis Requires Commercial Software.
o+ Ken Magel, North Dakota State University,
Configuring Metric Use to a Specific Industrial
Situation.
11:30-1:00 Lunch
Thursday Afternoon
1:00-3:00 Panel Session, Participants TBA, How can we
improve metrics and their application?
Coordinated by Curt Cook, OSU.
3:00-3:30 Opportunities for Industry-Academic Cooperation,
Curt Cook, OSU and Warren Harrison, PSU
3:30-4:00 Wrap up and discussion.
The number of attendees is limited, so register early. All
registrations will be handled on a first-come, first-served
basis. The registration fee is $195 for two days, including
lunch.
------------------------------
Date: 6 Jan 89 15:42:50 GMT
From: att!whuts!homxb!hou2d!ssh@bloom-beacon.mit.edu (S.HEGDE)
Organization: AT&T Bell Laboratories, Holmdel
Subject: Call for Papers - TENCON'89 - in Bombay (India) - November 89
Dear Colleagues:
I am organizing a technical session on SOFTWARE TECHNOLOGIES
FOR THE COMMUNICATIONS SYSTEMS at the I.E.E.E. TENCON'89
Conference to be held in BOMBAY, India from November 22-24,
1989.
I am requesting you to mail me an abstract of the paper (400
words, one page) that will fit into the overall session
topics outlined below ON or BEFORE MARCH 1, 1989.
SESSION TOPICS
o Communications Software - what are the customer's
expectations?
o Software Technologies to meet customer's expectations.
o Software Development Environment.
o Distributed System Model - combining the concepts of
functional objects with layered abstraction to support
the cost-effective design and development of new
software.
o Object Oriented Design - applicability in a large
communication system software development.
o Distributed Computing - challenges and opportunities in
the communication network development.
Please feel free to contact me for additional information
about the conference or the session:
Dr. Shankar S. Hegde
AT&T Bell Laboratories
Room 1J327
480 Red Hill Road
Middletown, N.J., U.S.A.
Telephone: (201)-615-2822
FAX: (201)-615-4637
Telex: 219879
email: att!hr3ar!ssh
------------------------------
Date: 7 Jan 89 22:45:19 GMT
From: pardo@june.cs.washington.edu (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Subject: Saturn V Launcher (WAS: "big endian" and "little endian" - first usage for computer)
[From: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc]
In article <2702@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
>[Classic Fortran "do 100 i=1,10" vs. "do 100 i=1.10"]
>[...] until the satelite got dumped in the ocean and NASA had lots
>of egg on its face.
That's an URBAN LEGEND!!! Fortran may deserve bashing, but the rumor
that it crashed a satellite launcher is false (and should be put to
rest).
The real story is as follows: a formula was written with a logical
"complement". Somewhere between the original formula and its
implementation in ASSEMBLY language, the complement was dropped.
This was discussed at length a while back on comp.risks and several
other newsgroups. Followups to comp.software-eng.
;-D on ( I take risks, I read USENET! ) Pardo
- -----------> Excerpt from comp.risks (RISKS Digest 5.73): <------------
Date: Sun, 13 Dec 87 05:30:10 PST
>From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
To: RISKS@KL.SRI.COM
Subject: Finally, a primary source on Mariner 1
My friend Ted Flinn at NASA (flinn@toad.com) dug up this reference
to the Mariner 1 disaster, in a NASA publication SP-480, "Far Travelers --
The Exploring Machines", by Oran W. Nicks, NASA, 1985. "For sale by the
Superintendent of Documents, US Government Printing Office, Wash DC."
Nicks was Director of Lunar and Planetary Programs for NASA at the time.
The first chapter, entitled "For Want of a Hyphen", explains:
"We had witnessed the first launch from Cape Canaveral of a spacecraft
that was directed toward another planet. The target was Venus, and the
spacecraft blown up by a range safety officer was Mariner 1, fated to
ride aboard an Atlas/Agena that wobbled astray, potentially endangering
shipping lanes and human lives."
..."A short time later there was a briefing for reporters; all that
could be said -- all that was definitely known -- was that the launch
vehicle had strayed from its course for an unknown reason and had been
blown up by a range safety officer doing his prescribed duty."
"Engineers who analyzed the telemetry records soon discovered that two
separate faults had interacted fatally to do in our friend that
disheartening night. The guidance antenna on the Atlas performed
poorly, below specifications. When the signal received by the rocket
became weak and noisy, the rocket lost its lock on the ground guidance
signal that supplied steering commands. The possibility had been
foreseen; in the event that radio guidance was lost the internal
guidance computer was supposed to reject the spurious signals from the
faulty antenna and proceed on its stored program, which would probably
have resulted in a successful launch. However, at this point a second
fault took effect. Somehow a hyphen had been dropped from the guidance
program loaded aboard the computer, allowing the flawed signals to
command the rocket to veer left and nose down. The hyphen had been
missing on previous successful flights of the Atlas, but that portion of
the equation had not been needed since there was no radio guidance
failure. Suffice it to say, the first U.S. attempt at interplanetary
flight failed for want of a hyphen."
- ------------------------------------------------------------
>From: mink%cfa@harvard.harvard.edu (Doug Mink)
To: risks@csl.sri.com
Subject: Mariner 1 from NASA reports
JPL's Mariner Venus Final Project Report (NASA SP-59, 1965)
gives a chronology of the final minutes of Mariner 1 on page 87:
4:21.23 Liftoff
4:25 Unscheduled yaw-lift maneuver
"...steering commands were being supplied, but faulty application
of the guidance equations was taking the vehicle far off course."
4:26:16 Vehicle destroyed by range safety officer 6 seconds before
separation of Atlas and Agena would have made this impossible.
In this report, there is no detail of exactly what went wrong, but "faulty
application of the guidance equations" definitely points to computer error.
"Astronautical and Aeronautical Events of 1962," is a report of NASA to the
House Committee on Science and Astronautics made on June 12, 1963. It
contains a chronological list of all events related to NASA's areas of
interest. On page 131, in the entry for July 27, 1962, it states:
NASA-JPL-USAF Mariner R-1 Post-Flight Review Board determined that
the omission of a hyphen in coded computer instructions transmitted
incorrect guidance signals to Mariner spacecraft boosted by two-stage
Atlas-Agena from Cape Canaveral on July 21. Omission of hyphen in
data editing caused computer to swing automatically into a series of
unnecessary course correction signals which threw spacecraft off
course so that it had to be destroyed.
So it was a hyphen, after all. The review board report was followed by a
Congressional hearing on July 31, 1962 (ibid., p.133):
In testimony befre House Science and Astronautics Committee, Richard
B. Morrison, NASA's Launch Vehicles Director, testified that an error
in computer equations for Venus probe launch of Mariner R-1 space-
craft on July 21 led to its destruction when it veered off course.
Note that an internal review was called AND reached a conclusion SIX DAYS
after the mission was terminated. I haven't had time to look up Morrison's
testimony in the Congressional Record, but I would expect more detail
there. The speed with which an interagency group could be put together
to solve the problem so a second launch could be made before the 45-day
window expired and the lack of speed with which more recent problems
(not just the Challenger, but the Titan, Atlas, and Ariane problems
of 1986 says something about 1) how risks were accepted in the 60's,
2) growth in complexity of space-bound hardware and software, and/or
3) growth of the bureaucracy, each member of which is trying to avoid
taking the blame. It may be that the person who made the keypunch
error (the hyphen for minus theory sounds reasonable) was fired, but
the summary reports I found indicated that the spacecraft loss was
accepted as part of the cost of space exploration.
Doug Mink, Harvard-Smithsonian Center for Astrophysics, Cambridge, MA
Internet: mink@cfa.harvard.edu
UUCP: {ihnp4|seismo}!harvard!cfa!mink
- ---------> End excerpt from comp.risks (RISKS Digest 5.73): <----------
- --
pardo@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
------------------------------
End of Software Engineering Digest
**********************************