[comp.software-eng] Accepted Practices

hsrender@happy.colorado.edu (06/06/91)

In article <1991Jun6.125833.18549@dec254.uucp>, toolsmit@dec254.uucp (Toolsmith) writes:
> My point is that I think we (the software engineering community) need to
> establish some sort of program or process to define accepted practices in the
> same sense as the accepted practices of the other engineering disciplines.
> 
> Anyone care to comment?

A few comments:

First, the IEEE is trying to do this (after a fashion) by establishing 
guidelines and standards for various kinds of project documents (Requirements
docs, design docs, user docs, etc.)  They also have standards for creating
QA plans, CM plans and test plans.  Together, these go a fair way towards
defining what it is that a software engineer is supposed to know about and
do on the job.  The DoD's 2167 standard also seems to have this goal in mind.

Second, a problem with the standards is that they tend to "freeze" the
current way that things are done (at least if they are followed to the letter).
This can stifle innovation.  Since I think very few people would say that we
now know exactly how software should be created and maintained, anything that
leads people (particularly project sponsors and managers) to think that we
do could inhibit their acceptance of new ideas. 

Third, there is some certification for programmers.  I know that there is a 
Data Processing Certificate (or something like it) that one can receive by
taking some kind of test.  I know this because I have seen study guides for
the test in amongst the Schaum's outlines in the local bookstore.  It seems
pretty much a test of terminology and a few practices.  I think such a test
could be useful for certifying software engineers if we ever do come up with
a standard set of terminology and practices.

hal.

toolsmit@dec254.uucp (Toolsmith) (06/06/91)

I have this (probably naive) thought that what we really lack in the field
of software engineering is a complete set of "accepted practices".  Other
engineering disciplines such as mechanical, electrical or civil have a well
developed and widely understood set of accepted practices, some of which are
embedded in formal codes (i.e. the electrical code).

People engaged in the other engineering professions also enjoy(?) the legal
status of professional certification.  Anyone heard of a registered 
professional software engineer?  The exams for certification seem to me
to be a means for assessing the engineer's knowledge of accepted practices
in his/her discipline.

I think the reason for this situation is that the software engineering 
profession is quite immature compared to the other engineering professions.
The underlying theory of current practices is not as old (well-tested) as
that of the other engineering disciplines and is not as complete.

My point is that I think we (the software engineering community) need to
establish some sort of program or process to define accepted practices in the
same sense as the accepted practices of the other engineering disciplines.

Anyone care to comment?


 ---------------------------------------------------------------------------
| Bill Brown                           |voicenet: (513) 841-8646             |
| Cincinnati Milacron Inc., Dept. 82G  |uucp: uunet!dec254!brown           |
| 4701 Marburg Avenue                  |also: uunet!dec254!toolsmit        |
| Cincinnati, OH 45209                 |compuserve: 70205,1146              |
 ---------------------------------------------------------------------------
| DISCLAIMER: I don't speak for the company; they don't speak for me.  :-)  |
 ---------------------------------------------------------------------------
-- 
 ---------------------------------------------------------------------------
| Bill Brown                           |dimenet: (513) 841-8646             |
| Cincinnati Milacron Inc., Dept. 82G  |uunet: uunet!dec254!brown           |
| 4701 Marburg Avenue                  |also:  uunet!dec254!toolsmit        |

orville@weyrich.UUCP (Orville R. Weyrich) (06/07/91)

In article <1991Jun6.125833.18549@dec254.uucp> toolsmit@dec254.uucp (Toolsmith) writes:
>
>People engaged in the other engineering professions also enjoy(?) the legal
>status of professional certification.  Anyone heard of a registered 
>professional software engineer?  The exams for certification seem to me
>to be a means for assessing the engineer's knowledge of accepted practices
>in his/her discipline.
>

I am not a PE, and have seen the exam procedure for PE's, but there is
something in the software world that may be somewhat analagous. There is
an Institute for Certification of Software Professionals that offers
exams and certification as follows:

	CDP -- Certified Data Processor (emphasis on MIS and management)
	CSP -- Certified Systems Professional (emphasis on A/D and S-E)
	CCP -- Certified Computer Programmer (emphasis on scientific or systems
					      programming)
	ACP -- Associate Computer Professional (tests entry-level skills in
					      one of several languages, such
					      as Ada, C, FORTRAN, COBOL, Pascal)

I have ACP and CSP certifications. To date, they have not gotten me a job,
but there is one job that I was told I would have a better chance at if I
had a CDP.

Is there anyone with both a PE and one of {CDP,CSP,CCP} that would care to
comment on how the two relate?

The ICCP member societies include:
	ACM	Association for Computing Machinery
	AIM	Association for Information Management
	ASM	Association for Systems Management
	AWC	Association for Women in Computing
	CIPS	Canadian Information Processing Society
	COMMON	An IBM Computer User's Group
	DPMA	Data Processing Management Association
	HKCS	Hong Kong Computer Society
	IEEE-CS	Computer Society of the IEEE
	ISTE	International Society for Technology in Education

By the way, the ICCP can be contacted at:

	2200 East Devon Avenue, Suite 268
	Des Plaines, IL 60018

	Phone (708) 299-4227

--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

wicklund@intellistor.com (Tom Wicklund) (06/08/91)

In <1991Jun6.101639.1@happy.colorado.edu> hsrender@happy.colorado.edu writes:

>In article <1991Jun6.125833.18549@dec254.uucp>, toolsmit@dec254.uucp (Toolsmith) writes:
>> My point is that I think we (the software engineering community) need to
>> establish some sort of program or process to define accepted practices in the
>> same sense as the accepted practices of the other engineering disciplines.
>> 
>> Anyone care to comment?

>A few comments:

>First, the IEEE is trying to do this (after a fashion) by establishing 
>guidelines and standards for various kinds of project documents (Requirements
>docs, design docs, user docs, etc.)  They also have standards for creating
>QA plans, CM plans and test plans.  Together, these go a fair way towards
>defining what it is that a software engineer is supposed to know about and
>do on the job.  The DoD's 2167 standard also seems to have this goal in mind.


Unfortunately, from what I can tell the emphasis in documentation
standards (whether IEEE or DOD 2167) seems to be in generating paper
in the correct format.  Very often format is more important than
content when documents are required.  While supposed to improve
software quality, they seem to do so by making it as hard as possible
to make a change to allegedly working software.

warren@eecs.cs.pdx.edu (Warren Harrison) (06/08/91)

>I have ACP and CSP certifications. To date, they have not gotten me a job,
>but there is one job that I was told I would have a better chance at if I
>had a CDP.
>
>Is there anyone with both a PE and one of {CDP,CSP,CCP} that would care to
>comment on how the two relate?

How about a CDP and CPA? My CDP is old (I first took the exam in 1979),
so they may have changed things, but one thing's for sure, back when I
took it, it was all multiple choice. The CPA exam isn't, I'm not sure
about teh PE exam. About the only thing you could be tested on with the
CDP was terminology back then. How does the testing procedure for the CDP
work now? I now it's been beefed up since 1979, but I'm not sure how. I
contributed questions to the CDP exam in the early 80's and it still seemed
to be multiple choice then.

Warren

==========================================================================
Warren Harrison                                          warren@cs.pdx.edu
Center for Software Quality Research                          503/725-3108
Portland State University/CMPS   

jls@netcom.COM (Jim Showalter) (06/08/91)

>Unfortunately, from what I can tell the emphasis in documentation
>standards (whether IEEE or DOD 2167) seems to be in generating paper
>in the correct format.  Very often format is more important than
>content when documents are required.  While supposed to improve
>software quality, they seem to do so by making it as hard as possible
>to make a change to allegedly working software.

You'll get no argument from me: almost all of the documentation
standards I've encountered are the triumph of form over function, of
style over substance, of sizzle over steak (the European HOOD standard
is a notable exception). I've seen projects mired in documentation
overhead to the extent that the tail wagged the dog--legitimate design
improvements were weighed against their impact on the documentation,
and the documentation group wound up wielding more political might than
the developers! I think the emphasis on form over content is pretty
easy to explain--form can be checked by people with no understanding
at all of software, design, or much of anything else (after all, how
hard can it be to verify that all 6-level nested paragraphs are in
12 point font?), whereas actually evaluating the CONTENT requires skill
and expertise.

Fortunately, for projects that have such standards inflicted on them,
there is a ray of hope: much of this sort of documentation can be
programmatically generated. Some might argue that this defeats the
whole purpose of documentation--which, allegedly, is to produce USEFUL
documentation--but so little of the documentation I've seen is actually
useful that it might as well be generated automatically. Note that this
ability to regenerate all of the documentation at will is a boon to those
projects wishing to use a more iterative (as opposed to waterfall) style
of development, since it removes the cost associated with constantly
reworking the documents. I can point you to a system that generates
documents automatically from Ada PDL and bubble-and-arc diagrams if
you're interested.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

alan@tivoli.UUCP (Alan R. Weiss) (06/11/91)

In article <1991Jun7.171606.5862@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes:
>>> 
>>> Anyone care to comment?
>
>>A few comments:
>
>>First, the IEEE is trying to do this (after a fashion) by establishing 
>>guidelines and standards for various kinds of project documents (Requirements
>>docs, design docs, user docs, etc.)  They also have standards for creating
>>QA plans, CM plans and test plans.  Together, these go a fair way towards
>>defining what it is that a software engineer is supposed to know about and
>>do on the job.  The DoD's 2167 standard also seems to have this goal in mind.
>
>
>Unfortunately, from what I can tell the emphasis in documentation
>standards (whether IEEE or DOD 2167) seems to be in generating paper
>in the correct format.  Very often format is more important than
>content when documents are required.  While supposed to improve
>software quality, they seem to do so by making it as hard as possible
>to make a change to allegedly working software.


Oh, I don't know ... I just used ANSI/IEEE 829-1983, "IEEE Standard
for Software Test Documentation" in creating my System Test Plan.
I found it to be tailorable, succinct, and not at all difficult
to understand.  It forced me (well, more like reminded me) to think
of various aspects of testing, and most importantly my Plan was
under 25 pages long and is well-organized for inspection.  BTW,
we're using the standard as the reference standard.

(Yes, that's right:  the QA/Test deliverables get inspected just
like the Development deliverables.  What's good for the goose ...)

I do agree that MIL-SPEC 2167a and 2168 are not very useful for commercial
software projects, but the ANSI/IEEE standard is great.  Considering
that it was developed with the input of some of Software Testing's
finest minds :-) this is not surprising.


_______________________________________________________________________
Alan R. Weiss                           TIVOLI Systems, Inc.
E-mail: alan@tivoli.com                 6034 West Courtyard Drive,
E-mail: alan@whitney.tivoli.com	        Suite 210
Voice : (512) 794-9070                  Austin, Texas USA  78730
Fax   : (512) 794-0623
_______________________________________________________________________