HDTenEightyP/NetNews huggingface dataset:
From: awb@sei.cmu.edu (Alan Brown)
Subject: CASE Tool Integration Survey
Keywords: CASE integration
Organization: Software Engineering Institute
Date: Wed, 12 Aug 1992 20:54:25 GMT


Call for Information/Help on CASE Tool Integration Survey
=========================================================


We are trying to gather information on the current ``state-of-the-practice''
with respect to CASE tool integration.  Our interest is in what is really
being used by companies to develop operational systems --- not research
prototypes or demo applications.


In order to be of interest to us the development environment must satisfy
either 1 or 2 below AND 3 (the sticky part).

1.  Two or more CASE tools within the environment are integrated (i.e.,
    via data communication or control communication)  -- whether this 
    ``integration'' is vendor supplied,  end-user supplied, or both.
or
2.  Some form of ``integration product'' (such as a database/repository
    product, framework product, or message-based product) is in use.

AND
3.  The environment must have been used, or is currently in use, to
    develop a system that is intended for operational use. 


Our goal is to produce a report that describes the current
state-of-the-practice by collecting real user experiences in CASE tool
integration, and to provide insight into issues of practical concern for
software engineering environments. We are hoping to help bridge the gap
between the literature and environment users.


Months of research to date have yielded little beyond isolated instances of
point-to-point integrations between two tools.  Are we looking in the wrong
places ??? As implied above, the sticky requirement is number 3. Numerous
integration projects have been found. Production projects USING integrated 
CASE tools appear to be scarce.


If you are willing to help us by pointing us to an appropriate project,
please contact:


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                  Jock Rader and Alan W. Brown
                  Software Engineering Institute
                  Carnegie Mellon University
                  Pittsburgh
                  PA 15213

                  Tel:    412-268-6807  412-268-6914
                  Fax:    412-268-5758
                  e-mail: jrader@sei.cmu.edu  awb@sei.cmu.edu

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: What is Software Engineering
Date: 17 Aug 92 09:09:49 EST

In article <1992Aug17.061725.10802@sei.cmu.edu>, goodsenj@ajpo.sei.cmu.edu (John Goodsen) writes:
[...]
> 
> The  above discussion is  premised  upon a more  classical  (outdated)
> software development lifecycle based upon or  similar to the waterfall
> model, which has been  shown  over  and  over again  to  be a  totally
> innappropriate model of software development reality.
[...]
I recommend that everyone read Royce's paper on the waterfall model.  The
common misunderstanding, and what he recommended in the paper are totally
different.  The reference: Managing the Development of Large Software Systems,
Winston Royce, IEEE WESCON, 1970, pages 1-9.

I believe that I have stated this before but will do so again.  At some scale,
every software development process looks like a waterfall.  The "classical"
waterfall looks like the ETVX model (Entry, Task, Validate, eXit).  Even
assembling a prototype takes some planning, even though it may be minutes
rather than months.  

Less focus on the model_of_the_month club and more focus on the similarities
between them and the contained tasks would help us get our jobs done.

I personally prefer the Monty Python "Confuse-a-cat" model for planning
purposes.  You never get any questions about where you are at.

George X. Kambic
standard evolutionary revolutionary chaotic sprial waterfall disclaimer

Newsgroups: comp.software-eng
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: sofware reuse
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 14 Aug 1992 03:16:23 GMT

scott@shuksan.boeing.com (Scott Moody) writes:

>It is sad that there isn't a 'reuse' group on the net.

I believe that comp.components is supposed to be about 'reuse'.
From: mframpto@axion.bt.co.uk (Mike Frampton)
Newsgroups: comp.software-eng
Subject: components reuse other issues
Keywords: Software Reuse
Date: 14 Aug 92 08:51:56 GMT
Reply-To: mframpto@axion.bt.co.uk (Mike Frampton)
Organization: British Telecom Research Labs


on  13 Aug 92  paul@hal.COM (Paul Sander) writes 

->Actually, comp.sw.components is a newsgroup whose charter is to discuss
->resuable software components.  It hasn't much traffic over its lifetime,
->though.

There doesnt seem to have been a very strong reuse thread on comp.software-eng so far so Im not sure that an independant group is the answer. As far as comp.sw.components goes I beieve that reuse issues span a greater diversity than just the reuse of components.

ie

component reengineering
component maintenance 
component configuration management - a library issue
component classification 
interface definition  
reuse library systems
domain analysis 
identification of cost benefits 
reuse infrastructure 
reuse incentive schemes 


Mike Frampton

standard disclaimer here
From: johnm@cajal.uoregon.edu (John Martin)
Newsgroups: comp.software-eng
Subject: Re: >>>>>>> Most Widely Used Language?
Keywords: n
Date: 22 Aug 92 19:11:41 GMT
Organization: Institute of Neuroscience, University of Oregon

In article <seZHlOz0BwwZ9f8wIy@transarc.com>, Erik_Brown@transarc.com writes:

>ssimmons@convex.com (Steve Simmons) writes:
>	- My company is in on-line transaction processing (OLTP), and
>	  you don't have a good OLTP product unless you can support
>	  COBOL integration and development.

Huh? I don't understand. You mean that you cannot make a solid and useful
OLTP system unless you use COBOL? I beg to differ...

Although I can program in both COBOL and FORTRAN, I primarily use C, so I
cannot claim personal experience with this -- but friends have told me that
you would find great difficulty finding a job unless you could program in
C, and/or common Assembly languages.

-- 
John Martin                                        johnm@cajal.uoregon.edu
Institute of Neuroscience,   University of Oregon,    Eugene, OR,    97402
Newsgroups: comp.software-eng
From: adams@pooh.sdd.trw.com (allen Adams)
Subject: Re: What is Software Engineering
Organization: TRW Inc., Redondo Beach, CA
Date: Tue, 18 Aug 92 20:55:21 GMT

bradlee@cg-atla.UUCP (Rob Bradlee) writes:

>In article <1992Aug9.181448.22302@hubcap.clemson.edu> ofut@hubcap.clemson.edu (A. Jeff Offutt) writes:
>>
>>Here is my perception of what the above list is for the software industry:
>>
>>MECHANICAL ENGINEERING          SOFTWARE ENGINEERING
>>______________________          ____________________
>>   1. Safety                       1. Delivery date
>>   2. Quality                      2. Cost
>>   3. Cost                         3. Use latest "whiz-bang" technique (OO)
>>   4. Delivery date                 ...
>>                                   n. Quality
>>
>Here at my company the list is this:

>SOFTWARE ENGINEERING
>--------------------
>1. Delivery Date
>2. Delivery Date
>3. Delivery Date
>4. Cost

>And cost really means "do it with the available bodies unless you can make it
>look like a crisis and then we'll pull some people off one of the other crises
>so that you can meet your first three priorities."  The obvious reply is 
>"Well your company doesn't do Software Engineering".  I agree.

Well if your company is like mine and considers every electronic message 
you work on as company property, they will be unhappy with the above 
statement (good luck on you job search :) ).

As an aside, last week I went on a job interview at SEI Information 
Technology, which provides consulting in the 'commercial' arena.  Since my 
work background involves the defense area, one of the two consultants who 
was interviewing me wanted to know what I could provide to commercial 
businesses.  When I proposed that I could not only develop software and the 
same time as engineer it, he was surprised.  He indicated that most 
commercial companies consider software engineering an unnecessary expense and 
that for me to do that might offend the companies I would consult.  I 
certainly would like to get out of the defense industry, but at what cost!!  
I guess if I get layed off, maybe my tune would change.

Allen Adams

Please do not be confused - The above opinions are certainly not those of 
TRW Inc. or any one associated with them.
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Surveys - general comment
Date: 18 Aug 92 08:12:01 EST

In article <1992Aug17.133756.13870@seg.npl.co.uk>, sma@seg.npl.co.uk (Stephen Mark Austin) writes:
> 
>          Request for Participation: Formal Methods in Industry Survey
[...]

I will state this again.  The purpose of the survey is good.  The questions are
appropriate.  I cannot and will not participate since you are potentially
asking for company confidential information, that I am not permitted to just
mail out.

I see these requests for info fairly often (1/month?).  I doubt if the
responses give the right kind of coverage of the industry that is needed in
order to be valid.

George Kambic
From: sjlai@fcit-c1.fcit.monash.edu.au (SIMON LAI)
Newsgroups: comp.software-eng
Subject: ISO IRDS (DIS 10027)
Keywords: Repository, Information Resource Dictionary System
Date: 12 Aug 92 07:18:11 GMT
Organization: FCIT, Monash University


Just a general request for information in this area.

I have the services interface (DIS 10728), and will be getting
DIS 10027 soon.  If you've constructed one of these or know of one,
pls email me.

Thanks.

Simon.
Newsgroups: comp.software-eng
From: lukito@coral.cs.jcu.edu.au (Lukito Nugroho)
Subject: info request about persistent programming
Keywords: persistent programming, C language
Organization: James Cook University
Date: 14 Aug 92 02:25:25 GMT

I'm a student and I'm starting to do my project about persistent
programming. The aim of my project is to  extend the ability of C
language so that it can be used to implement a persistent data
structure.

At this point I'm doing my literature review, and I think I need more
reading articles. So I will be very thankful if someone can tell me
where and how I can get them.

Regards, Lukito.
contact : lukito@coral.cs.jcu.edu.au
From: marick@m.cs.uiuc.edu (Brian Marick)
Newsgroups: comp.software-eng
Subject: Re: Testing Parallel Components
Date: 22 Aug 92 17:19:19 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

wiley@cactus.org (Mark S. Wiley) writes:

>It depends on what type of parallel software you are testing.  When I
>was testing Sequent's symmetric multiprocessor OS (Dynix/ptx) I wrote a
>parallel test driver to run 100's to 1,000's of test processes in
>parallel.  This tends (-: to put it mildly :-) to stress the operating
>system and expose previously unknown race conditions in the OS.

Some colleagues and I did a similar thing when testing for locking
problems in a multiprocessing version of System V.  Because I'd just
spent some time working on a flexible coverage tool, we were able to
go one step further.

We were worried about whether our tests stressed what they were
supposed to stress.  It seemed possible that our tests might
bottleneck in one part of the system, leaving other parts only lightly
exercised. We devised "race coverage" to measure whether that
happened.

Race coverage counts how often a thread (processor) enters a routine
while another thread is already in it.  We ran existing stress
tests, measured their race coverage, then designed more stress tests
to fill in the gaps.  They found bugs.

We learned some good rules of thumb for writing stress tests, and
dabbled a bit with extensions to race coverage, but we didn't take it
as far as it could go.  I'd like to do that someday.

For more about race coverage, see my GCT documentation.  To get that,
start by fetching cs.uiuc.edu:pub/testing/GCT.README

Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick, marick@testing.com (pending)
Testing Foundations:  Consulting, Training, Tools.
From: scott@shuksan.boeing.com (Scott Moody)
Newsgroups: comp.software-eng
Subject: Re: sofware reuse
Date: 13 Aug 92 17:36:48 GMT
Organization: The Boeing Co., MMST, Seattle, Wa.
X-Newsreader: Tin 1.1 PL4


Bill Franks distributes an electronic report on reuse called
	ReNews    frakes@neptune.cs.virginia.edu

It is sad that there isn't a 'reuse' group on the net.

-- 
Scott Moody   (206) 477-4295   "There are no answers .. just cross references"
     scott@shuksan.boeing.com  
     uunet!bcstec!shuksan!scott
Newsgroups: comp.software-eng
From: brothers@mdd.comm.mot.com (Joseph Brothers)
Subject: Re: What is Software Engineering
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Thu, 20 Aug 1992 16:58:48 GMT

Various netpersons wrote:
>>MECHANICAL ENGINEERING          SOFTWARE ENGINEERING
>>______________________          ____________________
>>   1. Safety                       1. Delivery date
>>   2. Quality                      2. Cost
>>   3. Cost                         3. Use latest "whiz-bang" technique (OO)
>>   4. Delivery date                 ...
>>                                   n. Quality
>>
>Here at my company the list is this:
>
>SOFTWARE ENGINEERING
>--------------------
>1. Delivery Date
>2. Delivery Date
>3. Delivery Date
>4. Cost

It took me a while to notice that the one item missing from all these lists is

					Effectiveness.

My dictionary defines engineering as "applying scientific knowledge to practical ends".
It's embarassing to me how often I get caught up in irrelevancies while trying
to put what I know to work.  Hmmm, like posting this when I should be reading old
grotty code 8-).


-- 
			Joseph L. Brothers			
brothers@mdd.comm.mot.com		uunet!mdisea!brothers	         
	"I am speaking solely for my self, not my employer."
Newsgroups: comp.software-eng
From: doc@magna.com (Matthew J. D'Errico)
Subject: Re: Wanted: CDIF Info (CASE Data Interchange Format)
Keywords: CDIF Teamwork EDIF
Organization: Magna Software Corporation
Date: Mon, 17 Aug 1992 18:09:08 GMT

In article <22852@hacgate.SCG.HAC.COM> hayes%valkris@hac2arpa.hac.com (Brian Hayes 74-35 x65129) writes:
>Does any one have some information on CDIF (CASE Data Interchange Format
>based on EDIF)?  I am particularly interested in the Specification 
>for CDIF; but info describing and showing examples would be okay too.
>
>I have references to EDIF in the back of a Teamwork manual; but, I am
>more interested in CDIF.  Are there any on-line sources?

While it may be true that CDIF was once an extension to EDIF, that is
far from the case (pardon the pun)...  CDIF is its own entity as can
be attested to by the various design components.

Your best source for reference information is the CDIF Technical Committee.
Contact :

	Mike Imber (CDIF TC Chair) at: 100031.700@compuserve.com
		&/or
	Mary Lomas (CDIF TC Sec'y) at: mlomas@oracle.com

I would strongly urge you to consider joining the Technical Committe if
you are seriously interested.  For a nominal fee, you can easily obtain
the entire specification and the support of a really great group of people.

Regards --

-- Doc		(Magna Software is a member of the CDIF Technical Committee)
+-------------------------------+---------------------------------------+
|    Matthew J. D'Errico	| DOMAIN:	mderrico@magna.com	|
| Magna Software Corporation	| uucp:		uunet!magna!mderrico	|
|     275 Seventh Avenue	| CompuServe:	70744,3405		|
|	 20th Floor		+---------------------------------------+
|    New York, NY   10001	|	Voice	: 212 / 727 - 6737	|
|	    USA			|	Fax	: 212 / 691 - 1968	|
+-------------------------------+---------------------------------------+
From: daves@hpopd.pwd.hp.com (Dave Straker)
Date: Fri, 14 Aug 1992 16:56:03 GMT
Subject: Re: Do you use SADT ?
Organization: Hewlett-Packard ISG-SBU-PWD, UK.
Newsgroups: comp.software-eng

Book: SADT
by: David A Marca and Clement L McGowan
published by: McGraw Hill, 1988
ISBN: 0-07-040235-3

Dave Straker            Pinewood Information Systems Division (PWD not PISD)
(}-8]                   HPDESK: David Straker/HP1600/01
#define opinions mine   Unix:   daves@hpopd.pwd.hp.com
From: mobej@thaad-1g%hac2arpa.hac.com (Mario Obejas)
Newsgroups: comp.software-eng
Subject: Rough Draft: eval. of IDE strand_RT: Reviewers?
Date: 14 Aug 92 16:21:00 GMT
X-Newsreader: Tin 1.1 PL4

I have started doing an evaluation of IDE's Software through Pictures (StP).
*The objective is to focus only on its support of Hatley-Pirbhai methodology*

So before I go too far down this path, I wonder about the level of usefulness of
this document to the interested reader. My approach is to go through the
Hatley-Pirbhai book, quote rules/notation that the TOOL does/does not support,
and also give any additional clarifying comments along the way. Sorry folks, I
can't give an example with quotes "without the prior written consent of the
publisher" (I hope to get) as the copyright notice states, so I'll have to avoid
a direct quote here. 

The framework of my approach is something like the following excerpt.

The Hatley-Pirbhai rules for data stores are ALMOST all supported in StP:
a. Unlabeled flows to/from a store carry the whole data group of the store
b. Flows carrying subgroups of stored data are labeled with subgroup names.
c. Write only stores don't serve a useful purpose, so they are not used.
   StP will report an error in this case.
The Hatley-Pirbhai rule for data stores NOT supported in StP:
a. Data stores can only be read-only.  Flows into a data store occur outside
   the system being modeled. StP has no way of knowing this. Hence StP reports
   the error, and you must hand verify that this situation is correct.
b. A unique Data store appears on one DFD only. StP does not enforce this rule.
   However, a data store that appears on more than one DFD is the same object in
   the Data Dictionary.

As I go along, I am adding to a summary which I will place at the very front.
For now, I have chosen to keep this document in electronic straight-ahead ASCII
format so that ANYBODY can grab it and read it no matter what the host platform.

Comments, criticisms, warnings? Would you like to be a reviewer in the end? No
promises but I may as well get a list of interested parties now. Thanks for your
time.


--
Mario Obejas    mobej@thaad-1g.hac.com    (714) 732 2954
                mobej@thaad-1g@hac2arpa.hac.com   if the above doesn't work
Hughes Aircraft, 676/Z341, P.O. Box 3310, Fullerton, CA 92634
ex-THAAD sysadmin: will work for food or Internet address
Disclaimer: my opinions are mine, not necessarily my employer's.
From: mframpto@axion.bt.co.uk (Mike Frampton)
Newsgroups: comp.software-eng
Subject: RE:  sofware reuse
Keywords: reuse contacts
Date: 12 Aug 92 11:59:43 GMT
Reply-To: mframpto@axion.bt.co.uk (Mike Frampton)
Organization: British Telecom Research Labs



Check out the ASSET bulletin board via Katherine Bean
 -  beank@source.asset.com

Also there is an electronic news letter of some sort  ...  
contact - gardner@Stars.Reston.Unisys.COM


but I honestly think you would be better off raising a thread in nthis news
group.

Mike Frampton
Newsgroups: comp.software-eng
From: lagemaat@cs.utwente.nl (Jeroen van de Lagemaat)
Subject: For your LOTOS information
Organization: University of Twente, Dept. of Computer Science
Date: Wed, 12 Aug 1992 13:07:34 GMT

Dear all,

At the moment it seems that a lot of people are interested in getting
a grasp of what formal methods are about.

As a result of the ESPRIT 2304 project Lotosphere the following information
is available:
- a LOTOS based methodology for the design of complex hard/software systems
- Tools to support Lotos
- Experience from industrial partners in applying the above to both
  ISDN and OSI system design

In Sept 1992 (14-16) a workshop will take place in Pisa where results 
are presented.


The results are otherwise available in the form of:
- several european companies and universities which can introduce you
  to LOTOS, the method, tools in the form of cooperation, consultancy
  and courses (e.g. on LOTOS what, how, why, tools, introduction in
    excisting development environment etc).
- Several contributions to conferences, such as Forte 92, PSTV 92,
  RACE Telecommunications Software Engineering Symposium 92, FME 93.
- Tools: these are available both "as is" or "maintained" from several
  companies and universities.


Anyone interested in the above can contact me. I will provide you with 
the information you require and/or with the coordinates of relevant people.



-- 
    ___
 __/   \__________  Jeroen van de Lagemaat    <lagemaat@cs.utwente.nl>
|  \___/          |         
|___     __   ___ | University of Twente     
| |  |  /  \ (__  | Tele-Informatics & Open Systems
| |__|__\__/____) | P.O. Box 217  NL-7500 AE Enschede  The Netherlands
|_________________| tel. +31 53 893684              tfx. +31 53 333815

                    Humour, you're making me laugh.
                                    - Herman Finkers, Dutch comedian -
From: Erik_Brown@transarc.com
Newsgroups: comp.software-eng
Subject: Re: >>>>>>> Most Widely Used Language?
Date: 21 Aug 92 10:56:26 GMT
Article-I.D.: transarc.seZHlOz0BwwZ9f8wIy
Organization: Carnegie Mellon, Pittsburgh, PA

ssimmons@convex.com (Steve Simmons) writes:
> COBOL and FORTRAN are still the most dominant languages today in terms 
> of code that has been written (and running).  However, I think that 
> C is now the dominant language for new code underdevelopment.  Both 
> COBOL and FORTRAN are the languages on the old mainframes and mini-computers.
> C is really dominant in both the Unix and PC worlds.  Whatever?!?!?

You say "I think that...."  I assume this means you're not really
sure.  I'm not really sure, either, but I do note the following:

	- Many supercomputer tasks are still written in FORTRAN (see,
	  for example, this month's CACM).
	- My company is in on-line transaction processing (OLTP), and
	  you don't have a good OLTP product unless you can support
	  COBOL integration and development.
	- For the 1990 Census, the Census Bureau wrote a brand-new
	  program in FORTRAN to compile and present census data.

I'm sure many other recent-day examples exist.  Regardless of the
"hacker" viewpoint, COBOL and FORTRAN are widely used languages even
today.  I don't know if they are the *most* widely used.

> Most application software is not very complex in terms of system programming.
> Therefore, both FORTRAN and COBOL fit this paradigm nicely.  However, both 
> FORTRAN and COBOL programmers should be nervous because many of these
> jobs are being exported to countries like India and South Korea. 

I think many FORTRAN programs are much more complex than most C
programs.  I think you might be wrong on this point.  You may be wrong
for COBOL as well, since size breeds complexity, and supporting and
enhancing a huge COBOL program would be a complex task indeed.

> Only a few years ago, there were these Data Processing Institutes that would
> churn out COBOL programmers.  These programmers did not necessarily have
> either college, engineering, or mathematic backgrounds.  As a summer job
> 8 years ago, I worked for a company that did product development on
> mainframes.  Most of my fellow employees were trained at these places.
> They were good at what they did.

I think many institutes still do this.  Whole companies exist to train
people to program on IBM's CICS system, still one of the most widely
used pieces of software available.  In CICS, most (if not all)
development is solely in COBOL.

I am not arguing that COBOL and FORTRAN are better than new, "modern"
languages, but your "I think" post may be way off the mark (I think).

Anybody out there know of some real statistics?

-eeb