soft_eng%mwvms@MITRE.ARPA (05/22/88)
--------
Received: From MWULTRIX(SOFT-ENG) by MWVMS with RSCS id 4613
for SOFT_ENG@MWVMS; Wed, 18 May 88 19:57 EDT
Full-Name: Alok Nigam
To: soft_eng%mwvms@mitre.arpa
Subject: Soft-Eng-Digest
Date: Wed, 18 May 88 19:27:50 EDT
From: soft-eng
Soft-Eng Digest Wed, 18 Apr 88 V: Issue 2
Today's Topics:
Administrivia
Computer aided test procedure/case development.
Re: Theory vs. Practice
Request for information
Usage of sccs - a summary of replies
----------------------------------------------------------------------
Date: 18 May 88 18:01:04 EDT
From: nigam@mitre.arpa (Alok C. Nigam)
Subject: Administrivia
Apologies to those who received 2 copies of the last digest.
Hopefully this will go out with fewer problems. This, and
the next several digests contain messages semi grouped by
subject, as you may have noticed.
All submissions or administrative requests should be sent
to the following addresses:
soft-eng@mitre.arpa
soft-eng-request@mitre.arpa
or nigam@mitre.arpa
------------------------------
Date: 4 May 88 17:17:34 GMT
From: rti!tijc02!fcc349@mcnc.org (Fariba Cavitt )
Subject: Computer aided test procedure/case development.
I am interested in anyone who knows of a commercial software or anyone
who is developing or researching a software capable of doing the
following:
* A software tool running on a PC machine or mainframe that will
allow developers to enter test cases into a database as they are
designing and developing their product. This will allow test
procedures being developed at the same time the design and coding
is taking place. The major benefits of this product would be
online access to the test cases and online update of the test
cases.
* It is preferable that this software run on a mainframe and allow
multiple users access the database. Here some security checking
must take place. Also locking to avoid two people updating the
same test cases must be provide.
* As an example lets say 7 system engineers are developing a
factory automation software. As the interfaces between different
processes and different pieces of hardware are defined the test
cases for them must be written. These test cases will go under
headings such as man/machine interface, controller/measuring
device interface, ... and data gathering/database interface.
* So the software must allow a user to enter the test cases under
different headings. A heading covers a package that performs a
task. Examples of headings for the factory automation software
would be man/machine interface or data gathering/database
interface. Also it must allow headings that test the
interactions of two or more operations that may appear under
different headings. In the above example if part of the factory
automation is to save the operator's inputs in the database then
a heading to test the arrival and consistency of data entered by
the operator must be created.
* When software is ready to be turned to the system test the test
cases will go along with it. This will give the system test a
starting point and make sure that they do test the decisions made
at design.
* During the testing of the product system engineers or developers
who are maintaining the software now can look at the history of
test cases. If for example the man/machine interface changes
completely new test cases must be entered and perhaps some of the
old tests repeated.
* At the same time during system test the testers must update the
test cases. The information they put in is to the problems they
encountered during tests and whether or not the test was
successful. Also if they see a need for more and different test
cases under a subject they must have the freedom to enter their
cases.
I personally believe a system like this makes the testing cycle a lot
less painful. It also keeps a history of the tests performed on the
different parts of the product. This will assures that testers don't
repeat tests unless the code in that section has changed. Also
managers and engineers can check the hardiness and quality of the
product by looking at number of tests and types of tests performed.
Please let me know if you know of a product or of any development that
will perform some or all of the above.
Thank you for your time.
Fariba Cavitt
------------------------------
Date: 20 Apr 88 00:40:06 GMT
From: mtunx!mtune!codas!flnexus!kimbal!rick@rutgers.edu (Rick Kimball)
Subject: Re: Theory vs. Practice
>From article <619@psu-cs.UUCP>, by warren@psu-cs.UUCP (Warren Harrison):
> Anyway, I'm really looking forward to some insight on the problem.
COBOL Mentality 101
o Use Globals whenever possible (You have no other choice!)
o MOVE statements are much more efficient than using address manipulatio
n.
o Compilers written in COBOL do things the most efficient way.
o Create interpreted P-Code, not true excutables.
o Execute code from a data segment
o Modify the executable code on the fly
o Interface well to code written in other languages.
o UPPER CASE CODE IS THE EASIEST TO READ.
o Never use one bit when a byte will do.
o Never use 'Y' when 'YES' will do.
o READABLE CODE IS EASIER TO THROW AWAY WHEN IT DOESN'T WORK.
o NEVER use GOTO's; they are a sign of a Bad Programmer.
o ABOVE ALL, readabilty is most important, not functionality.
I left my last company because they tried to implement a PC
based product using COBOL. Originally, it was to be
written in 'C' and XENIX. I wasted five months trying to
make it work without any success. On my own time I
re-designed and re-implemented all the code in 'C'. The
goal of the product was to give the user sub-second response.
With COBOL they got ten second response. With the 'C'
version they got the target response.
When I showed them the results their response was; "Well we
don't have any 'C' programmers except you and two other
people. So we'll write sub-routines for the COBOL programmers"
(the other 20 people). At that point, I got a real job and
have been enjoying every productive moment since.
I really don't hate COBOL. :-) It just doesn't fit well with the
UNIX way of thinking. What I hate most of all is COBOL
thinking.
BTW: After I left, they cancelled the project after wasting
a lot of money on that could have been better spent on
improving PC-Pursuit. :-)
------------------------------
Date: Fri, 06 May 88 14:37:38 EDT
From: "William J. Joel" <JZEM%MARIST.BITNET@MITVMA.MIT.EDU>
Subject: Request for information
TITLE: REQUEST FOR INFORMATION ON PC'S AND WORKSTATIONS
I am the information center manager at marist college in
poughkeepsie, n.y.. I am trying to find out the types of
pc's and workstations used by the computer science students
at colleges of our size. Marist has approximately 3000
students. We have undergraduate and graduate degree
programs in computer science. Each degree program offers
two disciplines, one in software development and the second,
in information systems. I would appreciate any school of
our size responding with the following information 1) what
types of pc's and workstations do you have? 2) in what
capacities are these pc's and workstations used? Thanks for
any info you can provide. Send it to urkmarist.
------------------------------
Date: 29 Apr 88 11:22:58 GMT
From: mcvax!ukc!stl!stc!idec!camcon!igp@uunet.uu.net (Ian Phillipps)
Subject: Usage of sccs - a summary of replies
A few weeks ago I posted a request for 'sccs' users to tell me of hints or
problems. Here is a short summary of the responses; more info on request.
>From Marc Evans <marc@ima.isc.com>
... BSD sccs assumed...
- Create a directory structure in which the SCCS sources will be
placed. All of these directories should be owned by sccs, group
set to sccs, and mode 750 or 755.
- Create a second directory structure which is a mirror image of the
first, but this time the owners, and groups can be almost anything.
If you want anybody to be able to use any of the directories, set
the mode to 777. In each of these directories, create the standard
SCCS symbolic link to the corresponding directory in the first
directory structure.
- Have each programmer copy (not move) their code into the proper
directory in the second directory structure. You should then
create the SCCS version of each before they do any more work
(sccs create -r1 [other admin flags] source files). Also, archive
onto tape the orignal sources from their original directories, and
then delete them.
- Chances are, each programmer has created makefiles in their own
manner. You will probably want to create all of the makefiles
yourself, following some standard. At the end of this message, I
will enclose a makefile generator and dependancy list generator
that I use here. This can make your job alot easier.
[Sun's 'cc' will generate dependancy lists from c sources]
- When creating the makefiles, remember that you need 2 things to
happen; they should traverse directories, and also make targets.
I also had a reply from Robert Hartman <rdh@sun.uucp>, who is in charge of
the Sun 'make' and 'sccs' files, who also mentioned symbolic linking. (It also
made sure I read the make and sccs manuals more thoroughly :) He also dealt
with techniques like
/usr/src/lib/foo/libfoo.a: FORCE
cd $(@D) ; make $(@F)
FORCE:
# null rule
to perform nested makes.
Andy Greener <andy@ist.co.uk> writes:
Administer everything, even README files. It makes things easier in the
long run, even if it sounds like overkill.
The major problem with SCCS is the lack of any sort of "symbolic"
tagging of versions. ... However it can be dealt with. We have
built some tools for automatically constructing releases from ...
snapshot files.
Avoid SCCS branching. It sucks (basically!).
Use SCCS id keywords in sources so they appear in the binaries...
We use: "%Z%%Q%%M% %I%" , where %Q% is set to the path segment from
the root of the source tree to the current dir.
Beware of administering non-printable files (e.g. icons).
Charles Lambert <cl@datlog.co.uk>:
... Keep a System Description File that
lists all the version-numbered sources needed for a correct build. This
is simply a text document that has to be kept up to date. Since nobody
remembers to keep documents up to date, it is wise to have your shell
scripts do it automatically: every time someone deltas a file, the new
version number gets written into the SDF.
John Dempsey <john@cam.unisys.com>
At home, I have a Unix PC ...
I really don't see any pitfalls to using SCCS.
However, RCS is the better source code control system, because
it will instantly give you the most recent version of a source file. ...
I think SCCS is pretty straight forward.
Thanks to everyone who replied.
------------------------------
End of Soft-Eng Digest
******************************