From: dalamb@qucis.queensu.ca (David Alex Lamb)
Subject: FAQ: comp.software-eng questions and answers
Followup-To: comp.software-eng
Keywords: FAQ
Supersedes: <questmsg_699919500@qucis.QueensU.CA>
Reply-To: dalamb@qucis.queensu.ca (David Alex Lamb)
Organization: Computing and Information Science, Queen's University at Kingston, Ontario,  K7L 3N6, Canada
Date: Sat, 11 Apr 1992 02:59:38 GMT
Expires: Mon, 25 May 1992 02:59:31 GMT


Archive-name: software-eng/part4

This message gives brief answers to questions that have occurred in
comp.software-eng; in many cases they are also topics many readers would like
NOT to see discussed again soon.  Questions are:
   What's a CASE Tool?
   What's a 'function point'?
   What is a 'specmark'?
   Where can I find a public-domain tool to compute metrics?
   How do I write good C style?
   What is 'Hungarian Notation'?
   Are lines-of-code (LOC) a useful productivity measure?
   Should software professionals be licenced/certified?
   How do I get in touch with the SEI?
   What is the SEI maturity model?
   Where can I get information on API?
   What's a 'bug'?



------------------------------------------------------------------------
Subject: What's a CASE Tool?
Date:  3 Feb 1991


(see also the archive file "casemsg") (thanks to Scott McGregor
<mcgregor@atherton.com> for inspiring this question)
CASE stands for Computer Aided Software Engineering;  it can be used to mean
any computer-based tool for software planning, development, and evolution.
Various people regularly call the following 'CASE': Structured Analysis (SA),
Structured Design (SD), Editors, Compilers, Debuggers, Edit-Compile-Debug
environments, Code Generators, Documentation Generators, Configuration
Management, Release Management, Project Management, Scheduling, Tracking,
Requirements Tracing, Change Management (CM), Defect Tracking, Structured
Discourse, Documentation editing, Collaboration tools, Access Control,
Integrated Project Support Environments (IPSEs), Intertool message systems,
Reverse Engineering, Metric Analyzers.


------------------------------------------------------------------------
Subject: What's a 'function point'?
Date: 10 Apr 1992


(see also the archive file "funcpoints")

Function points and feature points are methods of estimating the "amount of
functionality" required for a program, and are thus used to estimate project
completion time.  The basic idea involves counting inputs, outputs, and other
features of a description of functionality..QU "What's the 'spiral model'" "19
Sep 1991" (see also the archive file "spiral")
(1)  Barry Boehm, "A Spiral Model of Software Development and Enhancement",
     ACM SIGSOFT Software Engineering Notes, August 1986.
(2)  Barry Boehm "A Spiral Model of Software Development and Enhancement" IEEE
     Computer, vol.21, #5, May 1988, pp 61-72.

Basically, the idea is incremental development, using the waterfall model for
each step; it's intended to help manage risks.  Don't define in detail the
entire system at first.  The developers should only define the highest
priority features. Define and implement those.  With this knowledge, they
should then go back to define and implement more features in smaller chunks.


------------------------------------------------------------------------
Subject: What is a 'specmark'?
Date: 19 Sep 1991


(see also the archive file "specmark") The SPECmark is the geometric mean of a
series of benchmarks done by the SPEC group. There are a couple of suites, but
in general SPECmark refers to the results of the first suite.  The suite
includes FORTRAN and C codes, mostly well known codes but slightly hacked
versions.
    SPEC
    c/o NCGA
    2722 Merrilee Drive, Suite 200
    Fairfax, VA 22031
    Phone: (703) 698-9600
    FAX:   (703) 560-2752


------------------------------------------------------------------------
Subject: Where can I find a public-domain tool to compute metrics?
Date: 17 Jan 1992


(see also the archive file "metrics") Volume 20 of newsgroup comp.sources.unix
contained a public-domain package called "metrics", which computes McCabe and
Halstead metrics.  There are many comp.sources.unix archives around the net.


------------------------------------------------------------------------
Subject: How do I write good C style?
Date: 19 Sep 1991


This is answered regularly in the comp.lang.c FAQ.  Try "Recommended C style
and Coding Standards", on host archive.cis.ohio-state.edu (128.146.8.52) via
anonymous ftp in directory pub/style-guide.


------------------------------------------------------------------------
Subject: What is 'Hungarian Notation'?
Date: 19 Sep 1991


(see also the archive file "hungarian") A naming convention for C code.  See
Charles Simonyi and Martin Heller, "The Hungarian Revolution", BYTE, Aug. 1991
(vol. 16, no. 8).  There are other naming conventions;  see, e.g.  "A Guide to
Natural Naming", Daniel Keller, ETH, Projekt-Zentrum IDA, CH-8092 Zurich,
Switzerland. Published in SIGPLAN Notices, Vol. 25, No. 5, pages 95-102.


------------------------------------------------------------------------
Subject: Are lines-of-code (LOC) a useful productivity measure?
Date: 19 Sep 1991


(see also the archive file "metrics") Usually not, unless you are very
careful.  Capers Jones' book has a detailed and insightful discussion of Lines
of Code, including anomalies, and shows how to use it sensibly (eg in a single
job shop, with a single language, and a standard company coding style).
Pathological cases should get caught in code inspections.  References:
-    T. Capers Jones, Programming Productivity, McGraw-Hill, New York, 1986
-    Capers Jones, Applied Software Measurement: Assuring Productivity and
     Quality, McGraw-Hill, Inc., 1991, 494 pages ISBN 0-07-032813-7

The appendices of the latter give rules for counting procedural source code,
as well as rules for counting function points and feature points.


------------------------------------------------------------------------
Subject: Should software professionals be licenced/certified?
Date: 19 Sep 1991


This is a very controversial and political question.  Generally, certification
is something voluntary, while licencing is regulated by governments.
Certification generally means some agency warrants you meet its standards;
licencing generally means that to claim to practice a certain profession
requires a government licence, often administered through a professional
organization.  In theory both are supposed to help judge if someone is capable
of doing certain jobs.

Licencing isn't currently required for computing professionals;  some people
would like to see some jobs require it, as with established branches of
engineering.  Others don't like government intervention, and/or believe many
people who wouldn't get licenced are perfectly competent.

Computing professionals in the USA have had a certification program for years,
administered by the Institute for Certification of Computer Professionals
(708-299-4227), a meta-organization with representatives from ACM, IEEE-CS,
ADAPSO, ICCA, IACE, AIM, DPMA, AISP, COMMON, ASM, CIPS, and AWC.  There are
three certificates aimed at different broad types of practitioner, and many
areas of specialization.  To keep a certificate requires at least 40 hours of
continuing education each year; credit can also be obtained for self-study,
teaching, publication, etc.


------------------------------------------------------------------------
Subject: How do I get in touch with the SEI?
Date: 10 Apr 1992


The customer relations department of the Software Engineering Institute can be
reached at:
    internet:  customer-relations@sei.cmu.edu
    Phone:  (412) 268-5800
A subscriber service is available to U.S. mailing addresses. Subscribers
receive the SEI quarterly newsletter, Bridge; invitations to SEI public
events; and first notification of course offerings and new publications.  To
become a subscriber, contact Customer Relations.

To order an SEI publication, contact NTIS, DTIC, or RAI directly:
    National Technical Information Service (NTIS)
    U.S. Department of Commerce
    Sprinfield, VA 22161-2103
    Telephone: (703) 487-4600

    Defense Technical Information Center (DTIC)
    ATTN: FDRA Cameron Station
    Alexandria, VA 22304-6145
    Telephone: (703) 274-7633

    Research Access Inc. (RAI)
    3400 Forbes Avenue
    Suite 302
    Pittsburgh, PA 15213
    Telephone: (412) 682-6530
    FAX: (412) 682-6530
For general information about the SEI, contact George Heidekat
(grh@sei.cmu.edu).


------------------------------------------------------------------------
Subject: What is the SEI maturity model?
Date: 31 Jan 1992
Originally-From: mcp@sei.cmu.edu (Mark Paulk)


(see also the archive file "maturity")

Maturity is not an easy concept to get down to a single paragraph, but
consider this.

Premise:  The quality of a software system is largely governed by the quality
of the process used to develop and maintain the software.  Basics:  The first
step in improving the existing situation is to get management buy-in and
management action to clean up the software management processes (walk the
talk, as TQMers frequently say).  Integration:  The second step is to get
everyone working together as a team.  Measurement:  The third step is to
establish objective ways of understanding status and predict where things are
going in your process.  Continuous improvement:  Understand that this is
building a foundation for continually getting better.


------------------------------------------------------------------------
Subject: Where can I get information on API?
Date: 14 Feb 1992



API stands for Application Programming Interface.  For general information on
API standards, you can look at NIST Spec. Pub.  500-187, "Application
Portability Profile." (contact Barbara Blickenstaff, 301-975-2816). Many of
the open systems APIs are being developed in the IEEE POSIX groups.  An
article in the Dec. 1991 IEEE Spectrum describes these and related API
standards. IEEE standards aren't distributed electronically, but both of the
documents above tell how to obtain copies.


------------------------------------------------------------------------
Subject: What's a 'bug'?
Date: 10 Apr 1992



Don't use "bug", use "fault" (an incorrect instruction or definition),
"failure" (an incorrect result), or "mistake" (a human action leading to a
failure).  Paraphrased from
    IEEE Standard Computer Dictionary
    Standard 610, ISBN 1-55937-079-3
    Institute of Electrical and Electronic Engineers, Inc.
    345 East 47th Street
    New York, NY 10017-2394  USA
    $49.50 (US$) for IEEE members