soft-eng@MITRE.ARPA (Alok Nigam) (12/12/88)
Software Engineering Digest Sunday, 11 Dec 1988
Volume 5 : Issue 47
Today's Topics:
Summary of Software Uniformity Legislation issue
Peephole optimizers using expert systems
RE:Software Maintenance
Software Maintenance for the UNIX Operating System
REFERENCES FOR ALGORITHMS
Re: Software Maintenance for the UNIX Operating System
Projects on which programmers work
- ------------------------------------------------------------
Date: 6 Dec 88 04:01:58 GMT
From: cso@ohio-state.arpa (Conleth OConnell)
Organization: The Ohio State University Dept of Computer and Information Science
Subject: Summary of Software Uniformity Legislation issue
I want to thank all of you who have expressed opinions
on the Software Uniformity issue. I also want to forward the thanks
of the organization, described below, for your opinions/concerns.
After describing the organization, I give a brief summary of the
opinions that were sent. To the best of my knowledge, the
organization is meeting towards the end of January, so should you
still want to send an opinion to me, I am setting a deadline of
January 15, 1989, to insure forwarding. Once again THANKS!!
The organization that was requesting the information is "The
National Conference of Commissioners on Uniform State Laws." The best
known act that came out of this organization is the Uniform Commercial
Code. It is made up of practicing lawyers, college law professors and
deans, as well as some judges. The members donate their time to this
organization although some states pay actual expenses, no member
receives a salary for working on the organization. The organization
has NO association with the Federal Government or with Congress. For
those of you so inclined, the representatives from each state can be
sought out via the State Bar or Secretary of State.
Pros
- Something needs to be done along the lines of truth in
advertising of a particular product. For example, the packaging
of some products with "lavish painted covers of the boxes". When
in fact, the product has nothing to do with the artwork. This is
not acceptable in other industries like videotapes, toys or
plastic models.
- The industry has been lax with self-regulation, so
something needs to be done.
- Some minimum standards are needed, but who monitors them,
what are the reporting/registration requirements, what would be
the penalties, but "Don't feed the lawyers."
Cons
- Most of the opinions were dubious of federal legislation
even the opinions in the above section.
- A major concern is for the smaller companies/individuals.
- A bad product tends to get negative publicity anyway,
thus there seems to be some quality control by the community, but
the inexperienced/isolated user can get burned.
- Concern about price increase blamed on the regulation,
which, in the end, hits the consumer and the small companies.
- "Control will only close off creativity."
- The Uniform Commercial Code has been used in the past.
- The feeling that the industry is "moving towards
warranties, guarantees, and efforts for solid support" without
legislation.
- Legislation may be obsolete by the new technologies.
- Similar feelings towards the "stifling" of public domain
and free/shareware packages.
- ------------------------------
Date: 6 Dec 88 21:54:22 GMT
From: pasteur!sim.berkeley.edu!shuvra@ames.arpa (Shuvra S. Bhattacharyya)
Organization: University of California, Berkeley
Subject: Peephole optimizers using expert systems
Does anyone know of any past work on peephole optimizers
which use expert systems?
Please send replies to shuvra@sim.berkeley.edu.
- ------------------------------
Date: Wed, 07 Dec 88 15:56:15 PST
From: PAAAAAR@CALSTATE.BITNET (Dick Botting)
Subject: RE:Software Maintenance
gordon@HCI.HW.AC.UK writes (Soft-eng v5 n46)
<Given>
>a. The total universal person-hours committed to original software
>implementation, and
>b. The total universal person-hours committed to software maintenance>I >suspe
>hear of anyone actually attempting a proof like this?]
Perhaps a better analogy is radio-active decay...
A given "atom" in a piece of software (a statement/LOC/function call)
has a finite but small chance of being changed
because - 1. it was wrong in the first place
2. the program's environment has changed.
*If* this is constant then
In software with enough "atoms" we get a "Half life law":
There is a fixed length of time (on average) during which 50%
of the code is changed independent of the size of the code.
(because chance of change is roughly = changes/size = constant)
So if 100 lines out 10000 are changed in the first year then about the
same number will change next year...
Similarly 1 line out 100 of a similar but smaller project's code will change
every year.
Has anyone got any figures like this or (better) destroying (improving) this
idea?
>Is this the software variation of the Malthus Catastrophe?
No - but if the "atoms" spin off changes when they are changed we
get the likelihood of an undamped chain reaction.
Thus we conlude that if a piece of sufficiently unstable software is
larger than a critical mass it will self destruct
in a blast of hot air and fall out...
{hum - something familiar about that:-)}
- ------------------------------
Date: 8 Dec 88 05:31:54 GMT
From: apple!earlw@bloom-beacon.mit.edu (Earl Wallace)
Organization: Apple Computer Inc, Cupertino, CA
Subject: Software Maintenance for the UNIX Operating System
I'm looking for final solution in maintaining UNIX source code. I know about
SCCS, RCS, Make and NewMake, but I was wondering if there is something out
there that goes beyond these programs. Maybe a database-driven software
maintenance system that keeps all module information in the database
and allows you to build any release of your UNIX software at anytime.
I have an open mind and if anyone has any knowledge of any product, at any
cost (including free or Public-Domain) that can do a better job of maintaining
UNIX source code than the UNIX programs mentioned above, please send your
information to me and I summarize it for everyone.
- ------------------------------
Date: 8 Dec 88 22:28:49 GMT
From: rochester!kodak!ektools!thomas@cu-arpa.cs.cornell.edu (Thomas B. Kinsman)
Organization: Eastman Kodak, Dept. 47, Rochester NY
Subject: REFERENCES FOR ALGORITHMS
~~~ Please reply directly to the author. ~~~
Note: This is a language independent question.
It may be cross posted.
Note: This is a question on DESIGN, NOT on implementation.
Question: Which books are frequently used as INITIAL
references for algorithm design?
Situation: Imagine you know what you want to do, and you are about
to look in a book to see what methods have been used before.
You aren't doing anything out of the mainstream like strange
attractor modeling...
You are about to do a search on a tree, a hashing function...
i.e.: *** Which book do YOU go to first??? ***
Reply: Please mail directly to ME. Serious responses only please.
Results: I will post a list on December 22, 1988,
and you can all tear it apart then.
Thanks: In advance for all those that respond.
Joke: "We asked two thousand Software Engineers, if stranded in orbit,
which reference they would want to have along."
Author: Thomas B. Kinsman
...rochester!kodak!ektools!thomas
- ------------------------------
Date: 9 Dec 88 06:17:27 GMT
From: pitstop!rterek@sun.com (Robert Terek)
Organization: Sun Microsystems, Inc., Mountain View, CA.
Subject: Re: Software Maintenance for the UNIX Operating System
In article <21896@apple.Apple.COM> earlw@apple.com (Earl Wallace) writes:
>I'm looking for final solution in maintaining UNIX source code. I know about
>SCCS, RCS, Make and NewMake, but I was wondering if there is something out
>there that goes beyond these programs. Maybe a database-driven software
>maintenance system that keeps all module information in the database
>and allows you to build any release of your UNIX software at anytime.
I've often wondered about this, especially after using Apollo Computer's
DSEE system (Domain Software Engineering Environment). DSEE is much more
sophisticated than make/sccs (build according to a "thread", distributed
building, etc.), it's too bad it only runs under AEGIS. Does anyone know
if Apollo plans to port DSEE to UNIX? Has anyone else designed a software
maintenance tool that approaches DSEE in functionality, but runs under
UNIX?
- ------------------------------
Date: 9 Dec 88 16:03:27 GMT
From: cs.utexas.edu!sm.unisys.com!aero!abbott@husc6.harvard.edu (Russell J. Abbott)
Organization: The Aerospace Corporation, El Segundo, CA
Subject: Projects on which programmers work
Does anyone know of work done to determine how the country's (the
world's?) programming talent is employed, that is: the percentage of
professional programmers who work on real-time embedded systems; the
percentage who work on traditional business data processing
applications; the percentage who develop tools, operating systems, etc.
for hardware/software manufacturers; etc.?
- ------------------------------
End of Software Engineering Digest
**********************************