From:	HENRY::IN%"soft-eng-request%louie.udel.EDU%relay.cs.net@RCA.COM" 27-APR-1987 20:03
To:	Soft-Eng@xx.lcs.mit.edu
Subj:	Soft-Eng Digest V3 #3


Soft-Eng Digest             Mon, 27 Apr 87       Volume 3 : Issue   3 

Today's Topics:
    "Reliability Theory Applied to Software Testing" in HP Journal
                         Scale of Difficulty
                         Literate Programming
                   One-Person Programming Projects
                      Posting Fake News (2 msgs)
Seminar: "I Can't Tell What in the Code Implements What in the Specs"
       HICSS-21 "Code Analysis and Maintainability" Mini Track
----------------------------------------------------------------------

Date: Wednesday, 15 Apr 1987 10:18:21-PDT
From: rosenbaum%boehm.DEC%decwrl.DEC.COM%relay.cs.net@RCA.COM
Subject: "Reliability Theory Applied to Software Testing" in HP Journal

     [ From the RISKS Digest V4 #75, RISKS@CSL.SRI.COM ]

The April 1987 issue of the Hewlett-Packard Journal contains a short
(four page) article entitled "Reliability Theory Applied to Software Testing."

From the abstract:
    The execution-time theory of software reliability is extended to
    the software testing process by introduction of an accelerating 
    factor.   It is shown that the accelerating factor can be determined 
    from repair data and used to make prerelease estimates of software 
    reliability for similar products.

The article describes how the model was applied to the firmware for two
HP terminals.

(Subscriptions to the HP Journal are available without charge from
Hewlett-Packard Journal, 3200 Hillview Avenue, Palo Alto, CA  94304).

------------------------------

Date: Tue, 21 Apr 87 10:53:35 EDT
From: Bruce Nevin <bnevin%cch.bbn.COM%relay.cs.net@RCA.COM>
Subject: Scale of Difficulty

And this oft-forgot obviousness from an article by Walter Zintz titled
New tools for programming productivity (UNIX/World for May 1987, p. 50):

	Of all the theories floating around as to what sort of
	programming is the most demanding, it's hard to outdo the one
	from Gene Dronek, creator of the Aim benchmark suites.  Dronek's
	thought is that it all depends on who will be using the final
	product.  Software written for the programmer's own use is
	entry-level work, in Dronek's view, because it's so easy for the
	programmer-as-user to dodge around the flaws in her or his own
	code.  Software that will be used by other people within the
	programmer's company or institution is one step up, in that
	those other people have to find the program workable and
	understandable with only occasional help from its creator.
	Programs to be distributed to outsiders are the real challenge,
	because users can't depend at all on direct help from the
	original programmer.

(But it's all self-documenting code, right?)

Bruce Nevin
bn@cch.bbn.com

------------------------------

Date: Fri, 17 Apr 87 16:44:05 PDT
From: Mike Meyer <mwm%violet.Berkeley.EDU%BERKELEY.EDU%relay.cs.net@RCA.COM>
Subject: Literate Programming

I've recently acquired an interest in Knuth's "Literate Programming."
At this point, I'm curious if anyone is putting those ideas to
practice for non-trivial programming projects.

BTW, the comment that WEB was mostly a hack to get around the problems
with Pascal and the OS is only about half right. The missing half is
that most languages require such a hack if you're trying to approach
the level literacy to be found in TeX.

	Thanx,
	<mike

------------------------------

Date: Fri, 17 Apr 87 17:10:36 -0500
From: Ken Yap <ken%rochester.ARPA%relay.cs.net@RCA.COM>
Subject: One-Person Programming Projects

Although TeX was written by one person, remember that Donald Knuth had
the help of many other people talented in typography at and around
Stanford. Minix draws on many of the ideas from Unix.  Good software is
not created in a vacumn, it's partly a social process. It means nothing
to churn out 100 pages of code if the solution doesn't solve some real
problem well.

	Ken

------------------------------

Date: Sat, 18 Apr 87 10:10:56 PDT
From: sun!plaid!chuq%seismo.CSS.GOV%relay.cs.net@RCA.COM
Subject: Posting Fake News

     [ From the RISKS Digest V4 #75, RISKS@CSL.SRI.COM ]

 To: darrell@beowulf.ucsd.edu, mod-back

    I'm curious: how can you fake a posting without being root?  When I post
    anything to mod.os (er, excuse me, comp.os.research) I'm always listed as
    the sender.  Not wanting to be the bad guy I've never tried to crack it,
    but I am curious as to the hole that causes the problem.

Darrell asks an interesting question, and I might as well let everyone know
while I'm at it.

As background, be aware that USENET has a major security hole, in that there
is no way for the program rnews to know where a message came from.  It has
to implicitly trust the information in the header of the message.  While
uucp does site verification across the net, that information is not passed
along through uux to the executed program on the other side.  It has to
trust the data it gets.

This leads to a trivial hack for creating bogus and untraceable messages.
Take an existing message (I borrowed this one from mod.announce):

	Path: sun!cbosgd!mark
	From: mark@cbosgd.ATT.COM (Mark Horton)
	Newsgroups: mod.announce,news.announce.important
	Subject: mod.announce is being renamed news.announce.important
	Message-ID: <3525@cbosgd.ATT.COM>
	Date: 13 Apr 87 15:09:20 GMT
	Organization: AT&T Bell Laboratories, Columbus, Oh
	Lines: 9
	Approved: mark@cbosgd.MIS.OH.ATT.COM
	Xref: sun mod.announce:24 news.announce.important:1

This is your template. Now, change the header lines to fit, and delete the
Xref line:

	Path: cbosdg!mark
	From: mark@cbosdg.ATT.COM (Mark Horton)
	Newsgroups: mod.announce
	Subject: Newgroup renaming is a failure, film at 11.
	Message-ID: <3.14159@cbosdg.ATT.COM>
	Date: 1 Apr 87 00:00:00 GMT
	Organization: The Backbone Cabal, Inc.
	Lines: 9
	Approved: mark@cbosdg.MIS.OH.ATT.COM

Don't worry about the # of lines, inews will be nice enough to adjust it for
you.  Store that in a file, add the message body to it, and execute:

	% /bin/rnews < file

rnews will read it just as if it had come over the network, and install it.
It believes everything you said in the header.  When it passes it along, the
Path: becomes "sun!cbsogd!mark" and it gets passes along just like a real
message.  The only place where this is traceable is the Path variable,
because you can see that my site is at the beginning of the list of real
paths.  You can avoid this in a couple of ways if you want to be real
sneaky:

	o the kremvax syndrome:  instead of having a single address in the
	path, put in a bunch:

	    Path:  kremvax!nsacyber!prarie!wobegon!himom!cbosdg!mark

	depending on your ingenuity, you make make it almost impossible to
	tell where the message joined the net for real.

	o drop out of the loop:  even more fun, rather than execute rnews on
	YOUR site, execute it on someone else's.

	    % uux - -z ihnp4\!rnews < file
	
	the Path is now "ihnp4!cbosdg!mark" and your own site is nowhere to
	be seen.  Completely untraceable, unless someone wants to compare
	uucp's LOGFILE entry times with news 'log' entries and backtrack.
	Which assumes that they figure out it is happening before they flush
	the logs.  And that they have the time, and care.

That's how you forge messages.  And as long as the uucp links exist, there
is no way to fix this, because a vital piece of information isn't passed out
of uucp.

The possibilities are endless, of course.  You can not only post April
Fool's messages, but post messages FOR people that they can never prove they
didn't post.  completely untraceable.  You can change your name, your
machine, your religious background, all untraceable.  Possibly even skip out
on child support, if you find the right control message.  

Kids, don't try this at home!  These people are paid professionals, and know
the risks involved... (grin)

chuq (next week, how to kick a site off the net with cancel messages!)

   [For those of you who never saw the KREMVAX 1984 April Fools' Day hoax, 
   see ACM SIGSOFT Software Engineering Notes. July 1984. vol 9 no 4.  PGN]

------------------------------

Date: Mon, 20 Apr 87 14:40:47 EST
From: philabs!rob@briar(Rob Robertson)
Subject: Posting Fake News

     [ From the RISKS Digest V4 #75, RISKS@CSL.SRI.COM ]

The only place you can be traced using chuq's "posting techniques" is the
log files.  In the `uux - -z ihnp4!rnews < file` example, the machine and
user name will appear in ihnp4's LOGFILE or HDB's uucico, and uuxqt logs.

I'm not sure but have a funny feeling one can trace the user (by logs) if he
posts it on his machine, beside having his machine on the path list.

The brahms people did a good job of tracking down a person faking articles
by using log files.
                                        rob

------------------------------

Date: Mon 27 Apr 87 13:20:20-EDT
From: AHAAS%G.BBN.COM%relay.cs.net@RCA.COM
Subject: Seminar: "I Can't Tell What in the Code Implements What in the Specs"

     [ Forwarded by ezf@CC5.BBN.COM ]

  Elliot Soloway will give a BBN AI Seminar on Thursday April 30th 
at 10:30 in the 2nd floor large conference room at 10 Moulton Street.
[Cambridge, MA]

His abstract:

   "I CAN'T TELL WHAT IN THE CODE IMPLEMENTS WHAT IN  THE  SPECS."

Elliot Soloway
Cognition and Programming Project
Department of Computer Science
Yale University
New Haven, CT.  06520

The  problem  in  software  can be simply stated:  software changes.  As
functionality is added -- as it invariably is -- to the software, as the
bugs in the software are dealt with, the integrity of the software tends
to degrade.  Moreover, as the integrity of a system degrades,  the  ease
and  effectiveness  of  making  additional  enhancements/patches  to the
system increases -- dramatically.  We argue that there are two types  of
integrity:   Brooks' notion of integrity as "ease of use" of the system,
we refer to as external integrity,  while  internal  integrity  are  the
design   principles  and  constraints  that  structure  the  system.   A
necessary condition  for  preserving  a  system's  integrity,  then,  is
preserving the "code to specs" linkage:  to effectively change a system,
one must understand the system's original design.   Unfortunately,  many
of  the  key design considerations (both external and internal) are left
implicit, i.e., never written down.

In  this  talk  we  provide  zillions  of  examples  to  illustrate  the
considerable  effort  and  resources  programmers  expend  in  trying to
reconstruct the otherwise implicit linkage  between  the  code  and  the
specs,   and  precious  few  examples  of  how  we  can  facilitate  the
programmers' endeavours.  Lest AI/cognitive types think that this  is  a
boring software engineering talk, let me point out that the key, in both
our analyses of the software processes and  prescriptions  we  have  put
forward,  is  the  cognitive/AI  approach  that  we  have  taken:  while
mathematical approaches to software have their place, the real  leverage
to  the  problems  of programming-in-the-large will come from looking at
the programmer, and not the program.


------------------------------

Date: 20 April 1987, 10:59:51 EDT
From: Thomas Corbi <GROKLIB%ibm.COM%relay.cs.net@RCA.COM>
Subject: HICSS-21 "Code Analysis and Maintainability" Mini Track

            HICSS-21 "Code Analysis and Maintainability" Mini-Track
            _______________________________________________________


                              Twenty-First Annual
                        HAWAII INTERNATIONAL CONFERENCE
                               on SYSTEM SCIENCES
                               January 5-8, 1988

                                Thomas A. Corbi
                             Mini-Track Coordinator
                             Department 563/H0-C24
                                  P.O. Box 704
                        IBM T.J. Watson Research Center
                        Yorktown Heights, New York 10598
                                 (914)-789-7654
                             CSNET: GROKLIB@IBM.COM


          MINI-TRACK CONCEPT
          __________________

          As a software industry, we are continuing to grow and change
          our large software systems to:

          o   Remove Defects
          o   Address New Requirements
          o   Improve Design and/or Performance
          o   Interface to New Programs
          o   Adjust to  Changes in Data  Set Format and/or  Data Base
              Structure
          o   Modify Code to Exploit New Hardware/Software Features

          As we extend the lifetimes of these systems by continuing to
          modify and enhance them, we  are also increasing our already
          significant data processing investments in them and continu-
          ing to increase our reliance on them.

          However,  as changes  are introduced  into our  systems, the
          structure of these systems begins to deteriorate.  Modifica-
          tions  alter originally  "clean" designs.  Fix is  made upon
          fix.  Data structures are altered.  The systems steadily be-
          come less and less  maintainable and increasingly difficult,
          error prone, and expensive to modify.

          So, while  we are increasing  the lifetimes of  our systems,
          our investments in them, and  dependencies upon them, we are
          also creating "old code" maintenance nightmares.

          This  mini-track invites  papers  which explore  techniques,
          tools, and environments to  assist in the reconstruction and
          analysis of information in previously developed and modified
          systems to  aid in reverse engineering,  maintaining, and/or
          re-writing "old code".

          INSTRUCTIONS FOR SUBMITTING PAPERS
          __________________________________


          1.  Submit three copies of the  full paper, not to exceed 20
              double-spaced pages, including diagrams, directly to the
              appropriate track coordinator.

          2.  Each paper should  have a title page  which includes the
              title  of the  paper, the  full name  of its  author(s),
              affiliation(s),  complete   address(es),  and  telephone
              number(s).

          3.  The second page should include  the title and a 200-word
              abstract of the paper.


          DEADLINES
          _________


          o   Abstracts  may be  submitted to  track coordinators  for
              guidance and  indication of  appropriate content  by May
              15, 1987.

          o   Full papers  must be prepared and  arrive at appropriate
              track coordinator by July 6, 1987.

          o   Notification of  accepted papers  will be mailed  to the
              author on or before September 7, 1987.

          o   Final papers in  camera-ready form will be  due by Octo-
              ber, 19, 1987.

------------------------------

End of Soft-Eng Digest
******************************
-------
