soft-eng@MITRE.ARPA (Alok Nigam) (12/06/88)
Software Engineering Digest Monday, 5 Dec 1988
Volume 5 : Issue 46
Today's Topics:
Software Uniformity Legislation
CASE Inquiry
Software Maintenance
Software Quality (was: Re: rtm and uucp)
Intelligent Tools Program
Re: Software Quality (was: Re: rtm and uucp)
The Mythical Man Month
AI maths reasoning research
- ------------------------------------------------------------
Date: Mon, 28 Nov 88 16:06 GMT
From: Colin M Thomson <mcvax!gm.rl.ac.uk!CMTA@uunet.UU.NET>
Subject: Software Uniformity Legislation
Conleth O'Connell sent a note to the soft-eng list about US uniformity
legislation for software.
I guess there's a risk lurking in there. Either we get legislation
appropriate to life-critical software, and all the commercial games outfits
go bust, or we end up with nuclear reactors and flight control systems
required to meet mickey-mouse standards.
Maybe the legislators will try to classify software, and set up rules
appropriate to different sorts of products; if they do, will they get it
right?
- ------------------------------
Date: Thu, 1 Dec 88 16:07:27 CST
From: Jerry Brookshire <brookshir@skvax2.csc.ti.com>
Subject: CASE Inquiry
I am looking for evidence or speculation about the probable improvements
gained from the use of integrated Computer Aided Software Engineering (CASE)
systems (also known as SEE - Software Engineering Environments, or SDS -
Software Development Systems). I am interested mainly in improvements in
productivity, but would also like to hear about other improvements, such
as quality, reusability, etc. I am familiar with some of the software
productivity literature, but do not find much about this CASE/SEE acpect.
Might this be because there has been no experience with such systems yet?
I will be happy to summarize whatever I get back to the list.
- ------------------------------
Date: Wed, 30 Nov 88 16:44:57 GMT
From: Gordon Howell <mcvax!hci.hw.ac.uk!gordon@uunet.UU.NET>
Subject: Software Maintenance
Dick Botting at CalState says....
> ** SOON, ALL SOFTWARE ENGINEERING WILL BE MAINTENANCE **
Well, Dick, I knew I could count on you for the controversial viewpoint...
Interestingly enough, I have just today polished off a grant proposal and
managed to convince my colleagues that *after* the 18-month implementation
period, a further 18-month maintenance period (with an RA hired full time
for this job) was not only not unreasonable but essential.
I think your conclusion could be statistically justified to some arbitrarily
small epsilon if you measure:
a. The total universal person-hours committed to original software
implementation, and
b. The total universal person-hours committed to software maintenance*
*defining "software maintenance" as any activity which involves software
modification, explanation, upgrading [and how many hour did it take *you* to
upgrade to VMS v4 (have you done v5?)], etc... (please add to this list)
I suspect that the ratio a/b is already near-zero, and diminishing. [anyone
hear of anyone actually attempting a proof like this?]
Is this the software variation of the Malthus Catastrophe?
- ------------------------------
Date: 29 Nov 88 23:48:09 GMT
From: tektronix!percival!qiclab!sopwith!snoopy@bloom-beacon.mit.edu (Snoopy T. Beagle)
Organization: The Daisy Hill Puppy Farm
Subject: Software Quality (was: Re: rtm and uucp)
> The popular software distribution from a certain
> university in southern California is a good example of interesting ideas
> often marred by first-cut [i.e. poorly thought out, messy, sometimes
> incomplete] designs and implementations.
> This is not to say that any random commercial organization, like, say,
> one whose name has three initials and an "&" in it, will *necessarily*
> do better. But those people can, in theory, afford to spend some money
> on quality assurance. Universities generally can't.
Does this mean I should "rm -rf cnews" rather than trying to get it to
build? :-) Can I trust software from a certain university in eastern
Canada? :-)
These days, a vender is likely to be pushing both hardware and software
out the door as soon as possible so that they can rake in the bucks for
whizzy new feature foobar before their competitor beats them to it. They
may very well argue that they can't spend any more time/money on quality.
If you want better quality, you need to get customers to demand it.
Customers with large budgets.
It isn't who you work for, it is your state-of-mind that counts. Tools like
code inspections can help, but they may not buy you much if you're just going
through the motions.
- ------------------------------
Date: 30 Nov 88 03:57:56 GMT
From: munnari!murtoa.cs.mu.oz.au!ditmela!latcs1!kreed@uunet.uu.net (Karl Reed)
Organization: Comp Sci, La Trobe Uni, Australia
Subject: Intelligent Tools Program
THE AMDAHL AUSTRALIAN INTELLIGENT TOOLS PROGRAM
----------------------------------------------
at
La Trobe University Department of Computer Science
Bundoora, Victora, Australia
is offering an appointment as Senior Tutor-Lecturer,
and a number of Research Scholarships for Graduate Students.
The project is aimed at producing a set of softwwre tools
using "intelligent" systems which will improve the productivity of
the front-end of the software design process, and to experriment with
new approachs in modular programming and system design.
Salary for the Senior Tutor-Lecturer is in the range A$26,010 to
A$40,100 (approx, subject to award variations), and the Research Scholarships
will be A$10,000 p.a. for appointees eligble for direct entry into an MSc
or PhD program. Support would also be provided for Honours or MSc Prelim
candidates. The project has an adequate budget for overseas visitors
and for travel.
The Program is funded by Amdahl Australia under the Victorian Offset
Program, is being supported by La Trobe University, and involves
one of Australia's largest software companies as an industrial partner.
The Program is aimed at raising the productivity of the software
industry, will run for atleast four years, and have a total of eight
staff and research students by the end of 1989.
This is a unique opportunity to become involved in a major
research program with clear industrial links and results.
Enquiries should be directed to Mr. Karl Reed at the project director
kreed@latcs1.oz, or to Prof. Dillon at tharam@latcs1.oz
phone messages may be left on the recorded message machine on +61-(0)3-660-2343
or with the Dept. of Computer Science at La Trobe on +61-(0)3-479 2598
- ------------------------------
Date: 1 Dec 88 21:36:51 GMT
From: attcan!utzoo!henry@uunet.uu.net (Henry Spencer)
Organization: U of Toronto Zoology
Subject: Re: Software Quality (was: Re: rtm and uucp)
>| This is not to say that any random commercial organization, like, say,
>| one whose name has three initials and an "&" in it, will *necessarily*
>| do better. But those people can, in theory, afford to spend some money
>| on quality assurance. Universities generally can't.
>
>Does this mean I should "rm -rf cnews" rather than trying to get it to
>build? :-) Can I trust software from a certain university in eastern
>Canada? :-)
You pays your money and you takes your chances! :-)
Some people can write good software without a QA group standing over them
with a club. Some can't. If there *is* a club-equipped QA-group, the odds
of getting consistently good software are better. If there isn't, as in
universities, much depends on who wrote the stuff, and on whether they got
out on the right side of bed that morning. (Even I, normally the absolute
pinnacle of programming perfection, have been known to produce code with
occasional trivial, unimportant flaws on a bad day. :-) :-) :-) :-))
>These days, a vender is likely to be pushing both hardware and software
>out the door as soon as possible so that they can rake in the bucks for
>whizzy new feature foobar before their competitor beats them to it. They
>may very well argue that they can't spend any more time/money on quality.
Yes, unfortunately, some QA departments come with a leash rather than a
club as standard equipment...
- ------------------------------
Date: 2 Dec 88 02:47:29 GMT
From: fluke!mce@beaver.cs.washington.edu (Brian McElhinney)
Organization: SRS Recursive Software, Castrovalva, WA
Subject: The Mythical Man Month
> 1) OS 360 was written in assembly language. Even today there are not a
> whole lot of programs equivalent in either size or complexity.
> Remember, we're talking somewhere around 1965-1968. Read
> "The Mythical Man Month" by ?? Brooks. The issue isn't complexity,
> it's lines of code.
You read a different "Mythical Man Month" than I. The issue was the
complexity of:
* Understanding what they were supposed to be producing.
* Understanding how they should go about designing it.
* Understanding how they go about implementing that design.
One *part* of the solution to the implentation is HOLs.
There are presently many, many, systems with more complexity that OS 360 --
they are just organized in a manner that reduces the complexity of individual
parts to something that is more understandable. OS theory, compiler theory,
software engineering practices were all in their infancies when Brooks managed
the OS 360 project.
See Brooks' more recent paper "No More Silver Bullets" (IEEE Computer in 1987).
> The only reason HOLs are considered an advantage is because most
> programmers are really coders
Assembly language is inherently more complex, leading to less real work done,
and more time wasted on complexities that are not a part of the real problem
(the real problem is getting the job done, correctly, not organizing register
usage for every line of code you write, etc.). Thus HOLs are an advantage
because they help reduce complexity. The lines-of-code stat is a side effect
(and should be taken with a grain of salt, as should any software metric).
> Automate coding from design specs and you lose all advantage of
> HOLs.
There is a great deal of difference between specifications and a design that
implements them. Because of this, automated coding for specifications is, in
Brooks' words, a "silver bullet"; a potential part of any real gain in
productivity, but not a general answer in and of itself. Since it is only a
partial solution, the need for HOLs remains (and indeed, given the difficulty
of creating such a program, it would likely be a lot more efficient *in
development time* to have the automated code generator emit HOL).
> 2) One of the major savings in using assembly language IS due to
> "tricks of the chip". I remember doing assembly programming on a CDC
> 6600 (1975). Two techniques in particular were used to speed up
> programs; First, we coded inner loops to keep the entire intruction
> stream in the instruction cache - no memory access (for
> instructions) - major gain; second, we interleaved instructions to
> take advantage of mutually independant asynchronous functional units
> - the units only synchronized to access common registers - depending
> upon the task, this could gain little to a lot.
But this is 1988. You are simple describing what people are doing with with
modern compilers (MIPS is a good example). And what others are doing inside
the CPU (the 80960 transparently does the interleave you describe; SPARC
*requires* the compiler to do be doing it).
> 3) The other major saving in using assembly language is "optimization".
> Yes, having to include support code and other general library
> routines from the compiler cuts down on code efficiency, but the
> major problem is that most commercial compilers generate horrible
> code. Hand coding in assembly makes up for the stupidity of
> compilers. Of course, good compilers can be written but I suspect
> that the R&D effort involved would push the potential selling price
> out of the reach of most buyers. However, take a look at the IBM
> FORTRAN H (optimizing) compiler or the original PASCAL compiler
> written specifically for the CDC 6600.
By this same logic, we should all be riding horses. Yes, poor compilers have
been written. But just as cars improved, so will compilers. The need for
extensive R&D decreases as the knowledge base increases, so you can expect
compilers to get better. Look at the GNU C compiler. It's a very good
compiler, yet it is free. Also FORTRAN H and the original PASCAL are very
different from "modern" HOLs, which solve very different, much more difficult
problems.
> 4) It's still a truism that appropriate algorithms buy you far more
> than hand optimization. However, once you have a working program you
> can substantially improve it's speed by analyzing the bottlenecks
> and recoding the critical procedures (or loops) in assembly
> language.
As I said, assemble language is useful in its place. This, and a very few
others, are the useful places. Assembly language will never disappear, but it
has already faded away considerably, and will continue to do so.
- ------------------------------
Date: 2 Dec 88 00:16:48 GMT
From: mcvax!ukc!etive!aiva!smaill@uunet.uu.net (Alan Smaill)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: AI maths reasoning research
Department of Artificial Intelligence
University of Edinburgh
RESEARCH ASSOCIATE
(Mathematical Reasoning)
Applications are invited for an SERC supported post, tenable, as soon
as possible, on a mutually agreed date. Appointment will be to
September 30 1989, initially, but with a strong possibility of renewal to at
least September 30 1991. The research is to develop E\em proof plansL, a
technique for guiding the search for a proof in automatic theorem
proving. The main application is to the automatic synthesis,
verification and transformation of logic programs using constructive
logic. The project is led by Professor Alan Bundy and Dr Alan Smaill.
Candidates should possess a PhD or have equivalent research or industrial
experience. Knowledge of logic is essential and knowledge of
artificial intelligence, formal methods in software engineering or
logic programming would be an advantage. Salary is on the AR1A scale in
the range 9,865 - 15,105 pounds p.a., according to age and experience.
Applicants should send a CV and the names of two referees to:
Prof. Alan Bundy.
Department of Artificial Intelligence,
University of Edinburgh,
80 South Bridge,
Edinburgh,
EH1 1HN,
SCOTLAND.
as soon as possible. The closing date for applications is 16th
January 1989. Further details may be obtained from Prof. Bundy (at
the above address or email to bundy@uk.ac.edinburgh or
bundy@rutgers.edu) quoting reference number 5613.
- ------------------------------
End of Software Engineering Digest
**********************************