HDTenEightyP/NetNews huggingface dataset:
From: kirby@xerox.com (Mike Kirby)
Newsgroups: comp.software-eng
Subject: Re: Debugging the process
Date: 30 Dec 92 15:43:16 GMT
Reply-To: kirby@xerox.com
Organization: Xerox Corporation, Webster NY

In article 725662638@pjd.dev.cdx.mot.com, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>kirby.roch803@xerox.com (Mike Kirby) writes:
>
>[lots of interesting points...]
>
>>All the SEI is saying is that you need to have a management process in
>>place before an engineering process will be able to take hold.  and you
>>need both processes before you can determine if a product failure is
>>due to engineering or to management.  AND you need to be able to
>>measure both.  Once you can do these things then you will be able to
>>continously improve the processes.
>
>This is the clearest statement I've seen yet of the SEI
>misunderstanding that generates so much opposition among engineers.
>
>Management is not engineering. Management has the ability to hinder
>engineering, and it has the ability to facilitate it. However, good
>engineering can be performed (with difficulty) under bad managers;
>conversely, good management does not guarantee good engineering.
>
>				Peter Desnoyers
>-- 


If good engineering is performed under bad management it is because if the
skills of the people.  When those people leave, the bad management will "take over"
and everything will be back to level 1.

Contrary to popular belief, software engineering is more management then engineering.
If a stable management process exists, and no engineering exists, a stable product
can still be delivered.  And this is indepenedent of the engineering talent in
the organization.  

Explain how an engineering is going to tell his boss to go shove it when the boss
comes and asks for another demo.  After a while you will develop a perceived 
attitude problem and your performance evaluations will drop.  You might not
get fired, but you certainly won't get promoted, because the boss sees you as
yet another whining engineer who doesn't understand what needs to be done
to get funding, or to establish the necessary political connections.  There
becomes no economic incentive for performing good engineering because there
is no understanding among management of what good engineering really is.

Please explain how my statement was a misunderstanding of the SEI model.

Mike Kirby
Xerox Corp
E-mail: kirby.roch803@xerox.com
Xref: sparky comp.software-eng:5154 comp.lang.c:18884
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.software-eng,comp.lang.c
Subject: Re: C code Layout
Date: Thu, 24 Dec 92 19:13:40 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
> ... am I in the minority here by preferring style C:
> 
>       keyword (condition) 
>               {
>               statement1;
>               statement2;
>               statement3;
>               }
> 

    Yes, and what's worse, (with 4-character tabs) I prefer:

    keyword ( condition )
       {
        statement1;
        statement2;
        statement3;
       }


    And since my editor (epsilon) handles all the indentation...


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.software-eng,alt.sources.d,comp.sources.d
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: cscope? trus?
Organization: AT&T
Date: Tue, 22 Dec 1992 08:43:25 GMT

the equivalent of truss is trace on suns.
There is also a PD version strace available somewhere

Nick Hounsome
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: What is Software Design?
Organization: :
Distribution: usa
Date: Sun, 27 Dec 1992 01:49:34 GMT

In article <1992Dec23.170143.1876@mixcom.com>, kevin.jessup <kevin.jessup@mixcom.mixcom.com> writes:
> In <7-PCNews-124beta@alpha.saar.de> Georg@alpha.saar.de (Georg Edelmann) writes:
> >feathers@serss0 (Michael Feathers @ Florida International University, Miami) once wrote....

>>>-The only document developed when software is designed that can be considered
>>> this complete is the source code.

>>False. At the end of SW design is the Structured Chart (compare it to the
>>HW schemes)   ^^^
 
> You guys do your structure charts AFTER you write your code rather
> than BEFORE?  Maybe that's your problem!  ;-)

Youse guys do your code BEFORE you finish your design?!?
Maybe that's YOUR problem! ;'>
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.software-eng
From: alec@stortek.com (Alec Sharp - x2955)
Subject: book publication
Reply-To: alec@stortek.com
Organization: Storage Technology Corp
Date: Mon, 28 Dec 1992 21:54:17 GMT

Please forgive the commercial nature of this post, but I thought that there
would be at least a few net users interested in it, and couldn't figure out a
way to disseminate the information in a way that would please everyone.

Title:		Software Quality and Productivity
Author:		Alec Sharp
Publisher:	Van Nostrand Reinhold
ISBN:		0-442-01218-7
Price:		$44.95

Synopsis:	This book is targeted at software developers, and attempts to
apply the philosophy of W. Edwards Deming to software development.  Throughout
the book the emphasis is on two things - reducing rework, and continually
improving the system.

However, adopting the philosphy of continual improvement means little unless
you worry about the details of what you will do and how you will do it. The
book contains both general ideas and specific suggestions of ways to improve
things.  Most people learn better from examples, so there are lots of examples.
All code examples are in C.

The book is not about doing it perfectly - I suspect perfection is impossible
because different projects have different complexities, people vary too much in
their needs, skill sets and personalities, and every solution contains the
seeds of the new set of problems.

Instead, a key theme of the book is to slowly but surely try to improve every
facet of the way that software is developed, always keeping in mind the goal of
reducing rework. This means trying new things and giving new ideas a chance,
then evaluating the results.


Alec

Alec_Sharp@stortek.com		Storage Tek, 2270 S. 88th Street
(303)-673-2955			Louisville, CO 80028-4286
"The real problem is not whether machines think, but whether men do."
Burrhus Skinner, 1969

Newsgroups: comp.software-eng
From: claird@NeoSoft.com (Cameron Laird)
Subject: Appeal to SEI (was: Debugging the process)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Wed, 23 Dec 1992 03:33:47 GMT
Keywords: "sie cmm" "sw engineering" "process improvement" "sw quality"

In article <1992Dec22.201249.23289@den.mmc.com> jhull@vulcan-gw.den.mmc.com writes:
>Bill Watt's excellent article focusses our attention once again on
>the real goal:  producing high quality (sw) porducts.  In general,
			.
			.
			.
>My understanding of the CMM differs from what I infer is Bill's in
>that he seems to believe that the CMM requires (or suggests or even
>encourages) delaying the implementation of product quality metrics
>and atomic process quality metrics until "the final level" while my
>understanding of the model is that a company should make its own
>decision about when to implement these metrics, but that the company 
>cannot be deemed to have achieved Level 4 until after they have been
>implemented.  I would agree with Bill that a company would (probably)
>be making a serious mistake to defer implementation of such metrics
>until after they had done everything else to achieve Level 4.
Time-out.  Someone get the attention of the SEI--oh,
OK, I'll write them, over the break--and tell them
that the consensus position of c.s-e readers on this
point is that we have no consensus.

Hard-working, thoughtful engineers keep writing about
"my understanding of the CMM regarding implementation
of metrics ...", and coming to all sorts of conclusions.
At some point, I'm going to invoke the tiny bit of
human-factors goop that I know, and decide that it's
time for the SEI to make the point more clear, one way
or another.  As intellectual customers of the SEI pro-
duct, we're having to work too hard.  SEI needs to add
just a bit of value in this one area.
			.
			.
			.
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
Newsgroups: comp.software-eng
From: jmargono@opus.starlab.csc.com (Johan Margono AAS SSD 301-921-3041)
Subject: Concurrent Engineering
Keywords: Concurrent Engineering
Organization: University of Delaware
Date: Mon, 21 Dec 1992 22:00:05 GMT

Does anyone know what Concurrent Engineering is, who the industry expert
is, and if there are any papers/articles written on it?

Thanks in advance.

-- 
+-------------------------------+----------------------------------------------+
| Johan Margono                 | Tel  : (301) 921-3041                        |
| Computer Sciences Corp.       | Fax  : (301) 840-8934                        |
| FAA/AAS - Reuse Department    | email: jmargono@starlab.csc.com              |
Newsgroups: comp.software-eng
From: kudzu@netcom.com (Michael Sierchio)
Subject: Re: Appeal to SEI (was: Debugging the process)
Keywords: "sei cmm" "sw engineering" "process improvement" "sw quality"
Organization: True Love, and Home-Grown Tomatoes
Date: Tue, 29 Dec 1992 18:27:40 GMT

In article <1992Dec28.193911.20735@asl.dl.nec.com> 
	 terry@asl.dl.nec.com writes:

>...Indeed,
>one of my complaints was that it unclear what a level 2 organization as
>defined in early SEI materials would DO with their metrics it was clearly
>supposed to collect.

Initially, nothing.  Level 2 implies that you use a documented procedure
for estimating artifact size -- lines of code, function points, whatever.

A disciplined process needs to be in place for some time in order for
any measurements to be useful.
-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+
Newsgroups: comp.software-eng
From: pindar@uxmail.ust.hk (Wong Pindar)
Subject: Who's Who?
Organization: Hong Kong University of Science and Technology
Date: Mon, 21 Dec 1992 10:39:02 GMT

Subject: Who's Who?
Summary: 
Expires: 
Followup-To: 
Distribution: Distribution: 
Organization: Hong Kong University of Science and Technology
Keywords: 


SE reading-lists are fine ... but I'm sure you may have wondered just
who are the 'key' people in each of the software engineering areas and
why are they considered 'key'? ( I deliberately leave the definition
of 'key' up to *you* )

Now each of us probably have an idea on who we think are 'key' and
why - this will undoubtedly differ from person to person.

One possible definition of 'key' is an author of a article/book that
has been cited again and again (e.g. Brook's, "The Mythical Man-Month:
Essays on Software Engineering").

I would like to create a ranked list of "frequency of being cited" (
most cited to least cited ) of such authors and see what the resulting
list looks like.

Q:"Do you know if such a list already exists and where I can get a
copy of it?" 
		
Any suggestions? (Please reply by e-mail)

Thanks in advance!

Pindar



-- 
Pindar Wong                      |   The Hong Kong University of     | 
Internet: pindar@uxmail.ust.hk   |     Science and Technology        |
Phone:    (852) 358-7023         |  Department of Computer Science   |

Newsgroups: comp.software-eng
From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
Subject: Re: How does TQM set priorities? (was: When do we inspect [long ago])
Keywords: Process
Organization: Teknekron Communications Inc.
Date: Tue, 29 Dec 1992 23:42:50 GMT

In article <1992Dec29.144738.8171@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
>In article <BzzB0s.MI@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:
>
>>This is one of the foggy areas of Total Quality Management
>>and Continuous Process Improvement
>
>AAACCKKKKKK!!!! Those words! Brrrr!!! How about "The Five Keys to
>Self-Renewal"? Or "Zero Defects"? (Image here of me brandishing a
>cross against the forces of darkness.)
>
>>for me; at what level
>>are decisions made?  Maybe "[t]he proper procedure" you
>>describe is itself too parochial; maybe there should be an
>>organization-wide initiative to address all kinds of lighting
>>questions.
>
>Now I seriously hope you are in jest. This is PRECISELY the
>cause of paralysis by process. Let's form a committee to study
>the problem... Hell, all the guy wants is (the equivalent of)
>more light on his work area. Why not "empower" this poor soul
>and let him figure out how that should be done. Meanwhile,
>everyone else continues working, instead of going to the
>newly-formed "Lighting Improvement Committee" meetings. If
>this person comes up with an approach that is beneficial to
>everyone, give him a bonus and implement it.
>
>>When a Total Quality Manager starts off on Monday morning, and
>>finds two initiatives he wants to pursue, on which one does he or
>>she start first?
>
>Preferably one that, as the Hippocratic oath advises, "does no harm."
>But if you are going to force a "Total Quality" manager on us, that
>would be hoping for too much. :-\  
>
>Mark Shanks
>shanks@saifr00.cfsat.honeywell.com

I can't resist pitching my $.02 against this wall.

My girlfriend works in a retail setting, and they've had these management
consultants in there for a while.  Periodically (maybe once every two
weeks) everybody is invited to small group meetings, with their choice
of theme: "Communications" or "Accountability".  The people who go to
these two kinds of meetings form mutually-exclusive subsets of the
employee pool.  They tend to despise each other socially, too.

Excellent scam on the part of these consultants, I think.  "Yes, we're
closing in on a solution -- could be any day now, it's hard to tell
with these things...."
---
Michael Turner
miket@tcs.com
Newsgroups: comp.software-eng
From: kirby@xerox.com (Mike Kirby)
Subject: Re: Is SEI's CMM being used in Anger or ju
Reply-To: kirby@xerox.com
Organization: Xerox Corporation, Webster NY
Date: Tue, 22 Dec 1992 16:26:44 GMT

In article 740@sei.cmu.edu, bwb@sei.cmu.edu (Bruce Benson) writes:
>In article <1992Dec9.134601.29459@vitro.com> mmangieri@vitro.com (Mikey) writes:
>>
>>If you believe that defining a process in the first place is an improvement
>>effort, then I agree. The level 1 organizations I have seen have no process at
>>all, or the process is so vague that no one can describe it in words. Until you
>>have something, you can't improve it.
>>
>>I don't think improvement efforts really start until level 2. 
>
>I've tried to sell level two efforts by saying the management practices
>help to "stabilize" the current process. Once we figure out what we are doing
>we can then try and improve the process.  However, the way we are trying
>to get to level 2 is through stabilizing the management processes and
>continuously improving them.
>* Bruce Benson                 + Internet  - bwb@sei.cmu.edu  +       +
>* SSC/XPE                      +      bbenson@xpe.ssc.af.mil  +    >--|>
>* Gunter AFB, AL 36114         +                              +       +
>* (SEI Affiliate Alumni)       + Voice     - 205 416-4445     +  US Air Force


There is an interesting article on the management (or lack there of) of software
projects.

Redmill, F. J., "Considering quality in the management of software-based development
	systems," Information and Software Technology, Vol 32, no 1, Jan/Feb 1990

It basically is a management bashing article.  Its quite amusing to read through
this article and say to ones self. "Yes.. My management does that...And that...
and that..."  The article describes common reasons management gives for software
projects being late and over budget.  Management also claims that these "reasons"
are technical in nature and not in the domain of management.  The author
spends several pages explaining why this is not true and how it is managements job
to provide solutions to many of the "technical" barriers that plague software
projects.  


Mike Kirby
Xerox Corp
E-mail: kirby.roch803@xerox.com
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: <None>
Date: 22 Dec 92 07:43:22 EST

In article <1992Dec19.063729@eklektix.com>, rcd@raven.eklektix.com (Dick Dunn) writes:
[...]
> -- 
> Dick Dunn    rcd@eklektix.com   -or-   raven!rcd    Boulder, Colorado USA

Dick,

Please identify alternate email addresses.  I seem to be unable to send or
reply to eklektix.com.  Thanks.  

George Kambic
kambic@iccgcc.decnet.ab.com
From: gordon@siemens.com. (Igor Gordon)
Newsgroups: comp.software-eng
Subject: Looking for software to evaluate CMs
Date: 21 Dec 92 22:11:12 GMT



We are in the process of evaluating several CM systems. I am looking for
software (source + [repository] + make files) to be used in the evaluation 
process.

Could anyone point me in the right direction for public domain
software that I could use for my purposes. The desirable characteristics
of such software are, in order of importance:

1. Number of modules (files): 500 -  3000

2. Executables are built using make

3. The software is organized hierarchally (not all files are
   dumped into one directory).

4. Language C/C++ (other languages are ok if public domain
   compilers are avaiable on Sun).

5. Large number of versions per file.

Pointers to any reasonably large piece of software are appriciated, 
even if it does not meet the above criteria.

-----------------------------------------------------------------
I speak only for myself

Igor V. Gordon			tel:   (609) 734-3321
Siemens Corporate Research      fax:   (690) 734-6565
Princeton NJ			email: gordon@siemens.siemens.com



Newsgroups: comp.software-eng
From: rharmon@uucp (Robert Harmon)
Subject: Re: Putting Engineering into Software Engineering
Organization: Arinc Research Corporation, Annapolis MD
Date: 21 Dec 92 11:39:56
	<BzHKr6.DGr@fiu.edu>

In article <BzHKr6.DGr@fiu.edu> feathers@serss0 (Michael Feathers) writes:

   >> What is needed to call Software Engineering "engineering"?
   >
   >Models that assist understanding, communication and recording of analysis
   >and design, and that are universally applicable and universally indispensible.
   Gee..   what about logic, computability theory, formal languages, cohesion,
   coupling, and knowledge representation?

Yes, logic, languages, cohesion etc DO apply to software engineering.
Unfortunately, they have to be computed for each individual software
system to be valid, this is expensive.

The Physical sciences can use mathematics to compute the New
characteristics of a system based on the differences between it and the
old system.  How do we do that with software today?  I belive that software
only qualifies as a 'black' science.  We can experimentally characterize
a system but perturbations to the system have to be completely retested.

I guess we are much better off that the medical/biological sciences.  It
takes almost 10 years to develop a new drug and bring it to market.  That's
a testing and documentation driven industry!

Anyway, what do we expect from a system invented by us?  Newton, Bohr and
Rutherford invented models for systems actually designed by 'nature'.

VonNeumann and his collegues invented a new science from scratch.  Did
they forsee the consequences or limitations of their model?  


--
rharmon@srg.uunet.uu.net        |
Robert B. Harmon ms:5-230       |  Causing touble, ...again?
Arinc Research 2551 Riva Rd.    |  
Annapolis, Md 21401             | 
Newsgroups: comp.software-eng
From: volks@snowhite.cis.uoguelph.ca (Lorraine Van Wingerden)
Subject: Interface Builders ?
Organization: Indiana University
Date: Tue, 22 Dec 1992 20:14:38 GMT


Hello, 
I am planning to compile an informal list of Interface Developing/Building/
Prototyping tools (such as Visual Basic for Windows, Interface Builder for 
NeXT).

If you know of any software systems or toolkits which you found particularly 
useful, or not useful, please drop me a note.

Also, if you know of any other sources of information on this topic (books, 
other newsgroups, mailing lists, etc) please let me know.

I'd prefer responses to come directly to me and I will post a summary if I get
any response.

Thank you,

Lorraine Van Wingerden
volks@snowhite.cis.uoguelph.ca
Newsgroups: comp.software-eng
Subject: Request for C Coding Standards
From: cmeiburg@mcl.saic.com
Date: 23 Dec 92 10:20:01 EDT

i am in process of developing a C coding standard for my organization.
i'm sure that many of you out there already have some sort of formal
standard your must adhere to for a project.  i am interested in
receiving copies any available standards to use as a start for 
development of a standard for our organization.  if you can't provide
a standard, perhaps an outline for what you consider important.

please e-mail replies to: cmeiburg@mcl.saic.com

happy holidays...

Newsgroups: comp.software-eng
From: altizer@figaro (Robert Altizer)
Subject: Survey: Use of FMEA in SW risk analysis
Reply-To: altizer@chdasic.sps.mot.com
Organization: Motorola SPS
Date: Mon, 28 Dec 1992 19:11:11 GMT

To the net -

I am interested in any software developer or organization using Failure
Mode Effects Analysis (FMEA) as part of the risk analysis procedure in
their development cycle.

If you use software FMEA, know about anyone who uses SW-FMEA, would like
to use SW-FMEA, or have any interest in research into SW-FMEA, please
contact me.  Respond by posting to comp.risks or comp.software-eng, or
just send email to me at the address below.

Regards,
Bob

---
#-------------------------------------------------------------------------#
# Robert Altizer - Motorola ASIC SQA          altizer@chdasic.sps.mot.com #
# 1300 North Alma School Road, M/S CH240                     R10908@email #
# Chandler AZ 85224-8517 USA                (602) 821-4249(v)/821-4167(f) #
#-------------------------------------------------------------------------#
# Nature has neither kernel nor shell, she is everything at once. -Goethe #                    #-------------------------------------------------------------------------#

Newsgroups: comp.software-eng
From: bwb@sei.cmu.edu (Bruce Benson)
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Organization: Software Engineering Institute
Date: Mon, 21 Dec 1992 16:16:31 EST

In article <1992Dec9.134601.29459@vitro.com> mmangieri@vitro.com (Mikey) writes:
>
>If you believe that defining a process in the first place is an improvement
>effort, then I agree. The level 1 organizations I have seen have no process at
>all, or the process is so vague that no one can describe it in words. Until you
>have something, you can't improve it.
>
>I don't think improvement efforts really start until level 2. 

I've tried to sell level two efforts by saying the management practices
help to "stabilize" the current process. Once we figure out what we are doing
we can then try and improve the process.  However, the way we are trying
to get to level 2 is through stabilizing the management processes and
continuously improving them.
* Bruce Benson                 + Internet  - bwb@sei.cmu.edu  +       +
* SSC/XPE                      +      bbenson@xpe.ssc.af.mil  +    >--|>
* Gunter AFB, AL 36114         +                              +       +
* (SEI Affiliate Alumni)       + Voice     - 205 416-4445     +  US Air Force
Newsgroups: comp.software-eng