MDAY@XX.LCS.MIT.EDU (Moderator, Mark S. Day) (02/09/88)
Soft-Eng Digest Mon, 8 Feb 88 Volume 4 : Issue 5
Today's Topics:
Data For Large Scale Software Projects
Business View of Software Productivity
Coordinating Software Development (6 msgs)
Correctness in Parallel and Distributed Systems. (2 msgs)
Correctness Proofs (3 msgs)
----------------------------------------------------------------------
Date: Thu, 28 Jan 88 15:55:05 pst
From: Bharat Shah - cs597 <bshah@cs1.wsu.edu>
Subject: Data For Large Scale Software Projects
I am working on a masters project, and we are trying to modify
the Putnams Eqn. for Software Effort Estimation.
I am wondering if any one out there can give us data for large
scale projects.. or even any leads on where I could get such
data. Specifically, the data that we are interested in is
Rate of Spending vs Time over the entire SW Development stage
or
(DSLOC per Time) vs Time.
The data should be for large scale projects (20000 DSLOC or more)
I have tried the Rome Air Development Center, and though they said
they could get me the data I havent got any and doesnt seem like
I would get any.
I would appreciate any help that I can get!!
Thanks in advance..
Bharat Shah
Computer Science Dept.
Washington State Univ., Pullman WA 99163.
CSNET Address (bshah@cs1.wsu.edu)
------------------------------
Date: 27 Jan 88 13:21:14 PST (Wednesday)
From: Rodney Hoffman <Hoffman.es@Xerox.COM>
Subject: Business View of Software Productivity
The 'Wall Street Journal' for Friday, Jan. 22, 1988 ran a page 1 story with the
headline PATCHING UP SOFTWARE OCCUPIES PROGRAMMERS AND DISABLES SYSTEMS
The story breaks no new ground. Using mainly examples from the banking and
securities industry, it recites the typical stories:
* Programmers spending 80% of their time repairing and updating software.
* Projects 100% over budget and a year behind schedule.
* Computer hardware and speed overwhelming programmers.
* Computer departments with three years backlog.
* New management changng specs or discarding whole systems.
* Little correlation between management goals and the way the
computer department spends its money.
* Program documentation shortcomings.
* Productivity of 5 to 10 lines of code a day.
* Unrealized promises of fourth-generation programming languages and
computer-aided software engineering.
A couple of quotes:
Ken Hamilton, a senior VP at Manufacturers Hanover, says one programmer
labeled the parts of his program using the initials of his friends...
Once dozens of programmers leave their mark on software as it starts moving
through its life cycle of 10 to 20 years, it becomes like a dangerous inner
tube. "It's been patched and extended and enhanced to the point that it is
now a maintenance nightmare," says Michael Bealmear, a partner at Coopers
& Lybrand.
Some hope for a solution [to low software productivity] is seen in what
are called fourth-generation languages... This is like giving reporters
something that would let them just write an outline for an article rather
than having to write the whole thing. Some users talk of quintupled
productivity... But the new languages... may work just for one part of a
project on one type of operating-system software on one type of computer.
Software that uses them also runs more slowly.... New Jersy's vehicle-
registration and driver-license operations slowed almost to a halt a few
years ago, and officials are still sorting through the mess....
IBM says it has been improving its programmers' productivity about 7% a
year simply by managing matters more carefully.
"It took us a lot of years to get into this mess," says Ray Stanley, a VP
at American Express Co., "and it's going to take us a lot of years to get
out of it."
------------------------------
Date: 20 Jan 88 23:56:40 GMT
From: linus!philabs!ttidca!hollombe@husc6.harvard.edu (The Polymath)
Subject: Coordinating Software Development
stank@orca.UUCP (Stan Kalinowski) writes:
> >When a development team needs to alter a component, they take a copy
> >from the first "build" in the view that contains a version of that
> >component; it may be copied from a shared "build" if a cooperating
> >team has already altered it, or it may be copied from the public
> >build. After they have started work on their copy, someone may
> >alter the version from which they started - their "antecedent"
> >version. Eventually, the team must combine that alteration with
> >their own so that a unified version of the file can be deposited in
> >the shared or public "build".
> >
> >We have called this operation "reconciliation"; clumsy - any offers?
>
>Yeah, call it "programmer's hell". ...
Better yet, call it "unnecessary". I've run into this situation in
several shops where people simply didn't know better (not that there was
any excuse for that). The solution is a configuration management system
wherein only one person can work on a module at a time. In order to work
on the module they have to check it out of the system in such a way that
no one else can check it out until it's been checked in again.
I've worked with systems that handle this automatically and I've set up
systems where it was handled manually because nothing else was available.
However you handle it, it's absolutely essential to a rational code
maintenance system.
Letting two people work on the same module in parallel, even if they're
office mates, is almost certain to cause conflicts and rework, sooner or
later. One at a time will save time in the long run.
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
------------------------------
Date: 26 Jan 88 18:48:35 GMT
From: ihnp4!alberta!calgary!jonesb@ucbvax.Berkeley.EDU (Bill Jones)
Subject: Coordinating Software Development
Okay, suppose your company is working on the next release of a product
already in the field. An important customer reports a critical bug,
and you find that the fix for it involves several modules which are
checked out and being modified for the next release. Should that team
be held up while you yank back the modules and figure out how to
recompose the customer's configuration? Or do you mean to tell the
customer that his bug can't be fixed until the next release is out?
Parallel development paths may have the danger of conflict, but proper
management and tool support can minimize it. I would be interested in
hearing of any non-parallel system which cleanly supports both new
development and maintenance of past releases.
------------------------------
Date: 1 Feb 88 23:08:43 GMT
From: linus!philabs!ttidca!hollombe@husc6.harvard.edu (The Polymath)
Subject: Coordinating Software Development
=Should that team
=be held up while you yank back the modules and figure out how to
=recompose the customer's configuration? Or do you mean to tell the
=customer that his bug can't be fixed until the next release is out?
Neither. You ship the customer(s) a temporary patch for the existing
code. Patched versions of code don't get checked in (but the patches do,
for the record). Then you include the fix in the next release (based on
the patch). This causes minimal disruption to the work on the next
release.
If you're working in a high-level language you probably aren't going to
literally patch the code, but the process can logically be treated in the
same way. The people working on the release still have only one version
of each module to work with, and the patch becomes an addition to their
task list.
--
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
------------------------------
Date: 31 Jan 88 22:39:10 GMT
From: trwrb!desint!geoff@ucbvax.Berkeley.EDU (Geoff Kuenning)
Subject: Coordinating Software Development
RCS supports this very nicely; you simply create a branch for the bug fix
while development continues on the main path. RCS even provides the "-j"
switch (admittedly a very hard switch to use correctly) to help you merge
that fix back into the main branch later. (You can also use System V's
sdiff program, or Larry Wall's patch program, to achieve similar results).
I believe you can also do this with SCCS, though I haven't personally
created an SCCS branch while another revision was actually checked out.
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
------------------------------
Date: 2 Feb 88 12:05:10 GMT
From: cca!g-rh@husc6.harvard.edu (Richard Harter)
Subject: Coordinating Software Development
Although an adequate tool set is critical, the most important factor
is proper management. I can speak to this from some experience since
SMDS is in the business -- our product is a software management system
and our customers are software managers and CM people in companies of a
variety of sizes -- and we get to see what works and doesn't work.
What happens in most organizations is that development happens first,
an ad hoc system is worked out by the developers, CM, QA, and customer
support get tacked on as an after thought, and things get rather messy
after a while. Once things get sufficiently entrenched it becomes very
hard to restore order. I don't want to go into a lot of detail, but
I will make two observations. (1) Once you have an existing organization,
there is a political problem. (2) Good CM and QA require organizational
commitment; they are not an add on.
As to parallel development -- "new development and maintenance
of past releases" is inherently parallel. Actually "parallel" is a
misleading term. It suggests independent paths of equal priority.
What really goes on is that one has a mainline product(s) with variants.
The variants may be enduring (separate supportable releases) or transient
(development efforts). What one tries to do is, so to speak, minimize
the distance between variants and the mainline.
From the developers perspective, however, the process is linear.
The developer ordinarily is working with a single variant that is
evolving over time. Going back to previous versions, and merging changes
are useful, but not essential. Development is implicitly constrained
by the need to keep the distance between the variant and the mainline
small. A lot of 'good software practice' is really an expression of
this requirement.
One should, of course, understand that a tool for merging is not
the same thing as successfully merging. Merging, at the mechanical level,
is not terribly difficult. The real problem is that the merged software
is neither fish nor fowl; there is an interaction between the two lines
that were merged that is not present in either parent line. Ideally one
creates lines that are orthogonal; i.e. the changes in line A are
independent of the changes in line B. Arranging orthogonality is a part
of good software management. In practice complete orthoganality cannot
be ensured, and the merge process must take this into account.
--
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.
------------------------------
Date: 2 Feb 88 18:21:11 GMT
From: bunker!shap@YALE-ZOO.ARPA (Joseph D. Shapiro)
Subject: Coordinating Software Development
yes, SCCS allows different revisions to be checked out concurrently.
there is also a means to apply the same fix to different revisions,
as follows:
get -e -r4.1.1.2 s.x.c # gets 4.1.1.2 for editing
vi x.c # make your changes
delta s.x.c # creates 4.1.1.3 (assuming 4.1.1.2 was a 'leaf')
get -e -r4.2 -i4.1.1.3 s.x.c # gets 4.2, includes 4.1.1.3 changes
delta s.x.c # creates 4.3 (assuming 4.2 was a leaf), with 4.1.1.3
changes.
Note that the second get could complain about conflicts, e.g.
overlapping areas of change on the different branches.
--
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Joe Shapiro "My other car is a turbo...
Bunker Ramo Olivetti too."
{decvax,yale,philabs,oliveb}!bunker!shap
------------------------------
Date: 29 Jan 88 14:33:25 GMT
From: hubcap!steve@gatech.edu ("Steve" Stevenson)
Subject: Correctness in Parallel and Distributed Systems.
I would like to find a reasonably up-to-date bibliography on
proving parallel programs correct. I would also like same for
distributed programs, say for the huge hypercube numerical programs being
developed.
Thanks.
--
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
------------------------------
Date: 31 Jan 88 16:16:03 GMT
From: siegel@svax.cs.cornell.edu (Alexander Siegel)
Subject: Correctness in Parallel and Distributed Systems.
This is very much an open research problem. I suspect you will only be
able to find flaky journal articles and miserably out of date texts on
this subject.
--
Alex Siegel
(607)255-1165 (Low Bandwidth Audio)
4161 Upson Hall, Cornell University, Ithaca NY 14853 (Hard Copy)
siegel@svax.cs.cornell.edu (ARPAnet)
siegel@CRNLCS (BITNET)
{uw-beaver,ihnp4,decvax,vax135}!cornell!siegel (UUCP)
------------------------------
Date: 27 Jan 88 22:25:22 GMT
From: mtune!lzaz!lznv!psc@rutgers.edu (Paul S. R. Chisholm)
Subject: Correctness Proofs
UH2@PSUVM.BITNET (Lee Sailer) writes:
> PROGRAM CORRECTNESS PROOFS: All the work on this seems to require the
> addition of "assertions" to the code, that is, logical statements of
> all the assumptions that must hold before, after, and even during the
> execution of a piece of program. (See Gries, the Science of Programming)
Um, sort of, but the other way 'round would be closer to the truth.
It's quite impossible to prove most software "correct", either because
it's not correct (no smiley), or the structure of the program doesn't
resemble the structure of the definition of "correct". Not long after
playing with correctness proofs, folks such as Dijkstra and Gries found
that it was far easier to write the correctness proof and add the code
than vice versa. Even so, the proof of a trivial code segment is
longer than the code, and the length of proofs grow much faster than
the code they can prove. Gries' THE SCIENCE OF PROGRAMMING is an
excellent introduction to this subject.
In my personal experience, it's impractically difficult to "prove" any
non-trivial program correct. On the other hand, the skills you need
for correctness proofs are very useful. My programming environment
(writing UNIX applications in C) can't "understand" proofs and compile
time assertions, but it lets me add run time assertions. I've done
this often, and found them a great aid in testing and debugging code.
The assertions I add are the same ones I used to develop the
code/proof.
-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc
AT&T Mail !psrchisholm, Internet psc@lznv.att.com
------------------------------
Date: 28 Jan 88 14:56:49 GMT
From: siegel@svax.cs.cornell.edu (Alexander Siegel)
Subject: Correctness Proofs
I recently took a course from Gries using his book and also took other
loosely related classes. That style of program proof, Hoare logic, is
being supplanted by newer methods. The biggest efforts are being made
in automatic progarm verification. So that even though the proof my
be 10 times as long as the program, a human never has to read or write
it so it doesn't matter. At the moment the whole subject seems to be
in a state of flux and chaos of competing ideas. In five years,
Hoare logic may seem archaic and weird.
[For a very different view of proofs and verification, readers
can read "Social Processes and Proofs of Theorems and
Programs" by DeMillo, Lipton and Perlis in
_Communications_of_the_ACM_ 22 #5 (May 1979). There is
a related exchange between Dijkstra and the authors in
Software Engineering Notes 3 #2 (April 1978). The arguments
still seem relevant 10 years later...]
--
Alex Siegel
(607)255-1165 (Low Bandwidth Audio)
4161 Upson Hall, Cornell University, Ithaca NY 14853 (Hard Copy)
siegel@svax.cs.cornell.edu (ARPAnet)
siegel@CRNLCS (BITNET)
{uw-beaver,ihnp4,decvax,vax135}!cornell!siegel (UUCP)
------------------------------
Date: 29 Jan 88 00:10:10 GMT
From: agate!garnet.berkeley.edu!csm@labrea.stanford.edu
Subject: Correctness Proofs
It will take more than five years to prove the automatic program verifier
software is "correct" (also no smiley). However, using "assertive"
comments is a lot of help to you and to other savvy programmers who might
want to muck around with your code.
-- Brad Sherman
------------------------------
End of Soft-Eng Digest
******************************
-------