MDAY@xx.lcs.mit.EDU ("Mark S. Day") (03/14/88)
Soft-Eng Digest Sun, 13 Mar 88 Volume 4 : Issue 20
Today's Topics:
Art or Engineering
Bugs from Changes in Environment
CASE Tools
CASE Tool Usage
Documentation Revision Control System
Programmer Productivity
Quality and the Object-Oriented Approach
Rebuttal to Review: Software Specification Techniques
User Interface Help
Workstations, Object-Oriented Languages, CASE
----------------------------------------------------------------------
Date: 11 Mar 88 9:49 -0800
From: Rainer Schoenrank <schoenrank%admin.camosun.bcc.cdn@ean.ubc.ca>
Subject: Art or Engineering
>I think Fred Brook's recent "No Silver Bullets" article in Computer
>gave a lots of the reasons why we don't have engineering yet. I don't
>think conventional ideas of engineering would stand the flexibility
>that computer systems have. Tables and models do not make engineering
>they are its artifacts.
Tables may not make engineering, but models do. The conceptual engineering
model gives the engineer the basic structure in which he will be working.
The civil engineer (as do most of us) has a well defined concept and highly
differeniated concept of bridge. A suspension bridge is a different model
than a truss bridge, etc. A software engineer does not have these types of
well defined models to work with.
When a civil engineer is asked to design and build a suspension bridge, he
can layout a structure diagram, know the parameters of the specification
that he must determine and begin the design within the parameters.
By contrast a software engineer can not layout the structure diagram of a
real time system, can not parameterize the specification without a lot of
research unique to this instance of the system and has no formal guidance
in the design of the system.
The difference is the conceptual and formal models available in the two
disciplines.
Rainer Schoenrank
Systems Development
Camosun College
Victoria, B.C.
schoenrank@admin.camosun.bcc.cdn
------------------------------
Date: 10 Mar 88 17:28:26 GMT
From: spaf@purdue.edu (Gene Spafford)
Subject: Bugs from Changes in Environment
I need to develop a body of references to published descriptions of
bugs resulting from changes in environment. That is, programs
which worked fine on one machine, but failed to work when ported
to another machine or had the current system upgraded, either due
to a change in data type precision, change in memory size, timing
differences, etc. Also appropriate are references to programs
that failed to work simply because the machine involved didn't
have the precision or range or memory that the programmer
assumed, even though the code itself was "correct."
I'm *not* interested in hearing anecdotal references; I want examples
(compilations would be best) that have appeared in the literature in
the past 10 years. Note that I'm not asking about portability
problems, per se, but about failures of the actual machine to
match the programmer's virtual machine.
Thanks in advance!
--
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
------------------------------
Date: 11 Mar 88 10:36 -0800
From: Rainer Schoenrank <schoenrank%admin.camosun.bcc.cdn@ean.ubc.ca>
Subject: CASE Tools
See New Product Review in COMPUTER November 1987 or the entire issue
of SOFTWARE March 1988.
I have purchased Visible Systems Analyst Workbench for delivery in
April 1988 to be used in specification of online transaction
processing systems. I believe that it will reduce the manual
processing of the specification and so allow for more iterations of
the specification in the available time. Since each iteration of the
specification should find some errors or omissions, the specification
should be of higher quality and therefore so should the system.
Rainer Schoenrank
Systems Development
Camosun College
Victoria, B.C.
schoenrank@admin.camosun.bcc.cdn
------------------------------
Date: 11 Mar 88 11:33 -0800
From: Rainer Schoenrank <schoenrank%admin.camosun.bcc.cdn@ean.ubc.ca>
Subject: CASE Tool Usage
>One of the reasons I am submitting this to SOFT-ENG DIGEST is to learn
>whether other readers believe this is a correct and fair appraisal, or
>whether I am missing something.
I believe that you are missing something. Your view of structured
analysis and its use is too simplistic, but natural when the user,
analyst and programmer of the required computer application is the
same person and all the communication about the system can take place
at the level of implementation and programming language.
You must understand that the application you are creating in your
computer is a model of (and necessarily less than) the system as it
exists in the real world.
Your application and its data requirements can and will be modelled at
many different levels of understanding and from many different points
of view. Structured Analysis lets you specify the application so that
all the views of the application can be reconciled uniformly.
Structured Analysis is a tool for understanding the application you
are trying to model in your computer (see M. Jackson and the JSD
methodology). It is not the only tool, but probably the most labour
intensive.
After the application is specified, different models of the
application can be evaluated to determine the best design and
implementation. There should not necessarily be a one to one
correspondence between the specification and the application modules
to be built.
Rainer Schoenrank
Systems Development
Camosun College
Victoria, B.C.
schoenrank@admin.camosun.bcc.cdn
------------------------------
Date: Fri, 11 Mar 88 13:25:47 CST
From: mlw@ncsc.ARPA (Williams)
Subject: Documentation Revision Control System
I am looking for the equivalent of a version control system for documentation.
Functionally, the product, which can be targeted for a PC, a UNIX installation,
or a VMS installation, must be able to provide text editing and formatting
capabilities and combine those features with a "successive versions" control
system. Two kinds of output must be available:
(1) current revision and
(2) changes only.
The idea is
(1) enter the original document
(2) print the initial version (user's manual, specification document,
etc.)
(3) as changes are required, enter the updates to the document
(4) print change pages, which should be marked-text (change bars,
possibly underlined/struck-through text that has been changed) and
page-controlled (all changes for a given page are printed on the
specified page...if changes cause page overflow, subsequent pages are
numbered at a lower level of indenture (e.g., page 3 fills up, print
pages 3.1 and 3.2 as required) (5) when a new documentation release is
scheduled, print the current version with full repagination.
If anyone has any clues about systems (public domain or otherwise) that support
a scheme similar to the above scenario, please forward your response as soon as
you possibly can to mlw@ncsc.arpa. I am putting this request on several
interest groups, so I apologize to those of you who see this in different
areas. Also, I do not subscribe to all the interest groups I'm targeting with
this request, so please mail your responses directly to me. Finally, if one of
my destination user groups perceives this as an indication that I am not
familiar with that group and believes that my answer may lie in their group's
archives, please let me know that. Knowing where to look is always important
in a search!
Thanks in advance...
Mark L. Williams
Naval Coastal Systems Center
Panama City, FL 32407
(904)235-5153
mlw@ncsc.arpa
------------------------------
Date: 10 Mar 88 05:40:05 GMT
From: neff@shasta.stanford.edu (Randy Neff)
Subject: Programmer Productivity
Programmer Productivity References:
Measuring Programmer Productivity and Software Quality by Arthur, Lowell Jay
Wiley, 1985 (Cobol based)
Programmer Productivity by Arthur, Lowell Jay
Wiley, 1983 (Cobol based)
Programmer Productivity by Parikh, Girish
Reston Pub, 1984 (Cobol based)
Software Productivity by Mills, Harlan
Little, Brown 1983 (JCL, flow charts, mathematics)
Most standard Software Engineering books have a section or chapter on P.P.
Software Engineering, Shooman, Martin
McGraw-Hill, 1983
Software Engineering: A Pratitioner's Approach 2nd edition
McGraw-Hill, 1987
Unfortunately, the following book is still very true:
The Mythical Man Month Brooks, Fred
I also strongly recommend the following book as an example of "how it could be"
Programmers at Work Lammers, Susan
Microsoft Press 1986
----------------------------------------------------------------------------
Cynics' Law of Programming Productivity:
A programmer's productivity is directly proportional to the size of his
or her stock option in the company.
(think about it!)
------------------------------
Date: 9 Mar 88 13:57:59 GMT
From: ece-csc!ncrcae!ncr-sd!ncrlnk!fenix!kcby@mcnc.org (kcby)
Subject: Quality and the Object-Oriented Approach
We are involved in doing our first "major" development using an
object-oriented approach. I am wondering if anyone has any experience or
statistics which show what the effect of using an OO approach is on program
or product quality.
My "gut feeling" is that quality ought to be (at least slightly) improved
over the quality of a product developed using a "standard" sturctured
approach (assuming same quality designers, sufficient time applied to
project, etc) due to
a) inheritance promoting the reuse of tested code
b) data encapsulation promoting modularity which reduces
the "ripple effect" of fixing bugs and making changes
However, some nice hard statistics would be useful. "Gut feelings" or rough
estimates from someone who's had experience actually developing an OO
product (particularly in C++) would also be encouraging.
Also, does anyone know of other quality related issues concerning the use
of an OO design or C++ programming language? What I am thinking of here
might be things like "the use of OO approach forced more thought to go into
the design to a more detailed level than usally done at an early stage of
development" or "we found problems with...".
K.C. Burgess Yakemovic "Say I'm a philosopher, say I'm a seeker for truth,
kcby@Atlanta.NCR.com say I'm a lover of my kind, or best of all,
....ncrlnk!fenix!kcby say I'm a Student" ...... Henry James, Sr.
------------------------------
Date: Thu, 10 Mar 88 10:51:53 EST
From: Mark Ardis <maa@SEI.CMU.EDU>
Subject: Rebuttal to Review: Software Specification Techniques
RE: Review - Software Specification Techniques
In a previous digest PAAAAAR%CALSTATE.BITNET@MITVMA.MIT.EDU
(Dick Botting) writes:
>Subjective Reaction -- Disappointment
>It is easy to get a quick feeling for what a specification might look
>like using a one of the discussed techniques. However all the stuff
>you need to be able to (1) verify the author's assertions and (2) test
>the ideas have been removed. All the syntax and semantics of the
>systems have been removed from the papers.
I disagree with this assessment. There are several examples provided
that illustrate the points that the authors were trying to make about
their languages and methods. The "Case Studies" section of the book
provides more than enough detail to "test the ideas".
If what you want is a reference manual for each language discussed,
see the references cited or write to the authors. I have been very
happy using this book as a text for specification languages and
methods in a graduate level course. Moreover, students told me that
they appreciated buying a text that they could use later as a
reference to these methods.
Mark A. Ardis
Software Engineering Institute
Carnegie-Mellon University
Pittsburgh, PA 15213
(412) 268-7636
maa@sei.cmu.edu
------------------------------
Date: Fri, 11 Mar 88 7:54:14 EST
From: "Gary B. Wirth" <gwirth@CC6.BBN.COM>
Subject: User Interface Help
I have some rather complex and involved testing to perform over the
next several month which requires that I utilize two type tools.
a. A VMS driver that can be used to script an INGRES user interface.
b. A Driver that can run on Ultrix and issue commands (and get responses)
on VMS.
I know little about VMS so any type response would be helpful. I am informed
by another group here at BBN that the VMS Ingres scripting isn't trivial
because there isn't a Unix/Shell virtual terminal type control mechanism
on VMS. This group has had problems with their driver getting ahead of
Ingres if it is slow doing its thing. They have to build in all these
waits by hand (yuk!).
My second request stems from the fact that I do not want to incur the
overhead of script processing on my test host. I want it to operate
as much as possible like a typical people driven system. The shells and
DCL processors screw up the timing/performance statistics.
thanx, Gary Wirth @cc6.bbn.com
------------------------------
Date: 10 Mar 88 00:08:24 GMT
From: macomw!dtraver@nosc.mil (George Andrew Traver)
Subject: Workstations, Object-Oriented Languages, CASE
We are currently evaluating the the following technologies:
1) Workstations.
2) Object Oriented Languages.
3) Computer Aided Software Eng.
I would appreciate any pointers to good information, manufactures, or
experiences with these technologies.
------------------------------
End of Soft-Eng Digest
******************************
-------