[comp.software-eng] CSCs and CSUs

abbott@aero.org (Russell J. Abbott) (03/12/91)

There has been some discussion recently about the relationship between
Ada constructs and the MIL-STD 2167A categories Computer Software
Components (CSC) and Computer Software Unit (CSU).

Arguments range from claims that:

(a) mapping Ada to CSCs and CSUs is overly burdensome and a waste of
time and energy;

to claims that:

(b) CSCs and CSUs are important software organizational categories that
should be used independently of the language in which a software system
is coded.

I would appreciate comments from anyone with an interest in this area.

I am especially interested in focusing on (b).  If CSCs and CSUs
represent independently useful software organizational categories (and I
think that they probably are): (1) how should those categories be
defined, and (2) can those definitions be made compatible with OO
approaches to software design?

According to MIL-STD 2167A:

A CSC is "A distinct part of a computer software configuration item
(CSCI).  CSCs may be further decomposed into other CSCs and Computer
Software Units (CSUs)."

[Nothing in this definition establishes properties that would qualify or
disqualify something from being a CSC other than it be part of a CSCI
and (implicitly and in practice but not explicitly) that it include
CSUs.]

A CSU is "An element specified in the design of a Computer Software
Component (CSC) that is separately testable." 

[The key phrase here is "separately testable."  The notion of
"testability" is generally interpreted broadly.  One form of testing is
inspection in which one looks at something and draws conclusions about
it.  This leads to the argument that a package of type declarations or
constants is separately testable.  That pushes the idea of "testing" a
little further than I would like.]

A CSCI is "A configuration item for computer software."

[I don't have the definition of "configuration item" handy, but
essentially it is an item that is placed under configuration control,
i.e., an item that is purchased and delivered and whose specification
and design are written down and subject to approval by the purchasing
agency.]

An issue that strikes me as important (and that might help resolve the
"testing" problem mentioned above) is whether CSCs and CSUs should be
defined in terms of the expected operational product or in terms of the
source code that defines it.  The implication of the definitions given
above is that CSCIs, CSCs, and CSUs are all to be understood in terms of
the delivered product.  I believe that that approach is appropriate.

In some cases, though, that perspective may lead to a different result
from the one one would get if they were defined in terms of software
constructs.  For example, imagine that the architecture of a software
system includes two components X and Y with two distinct functions
within the system.  It is conceivable that those two components are
generated as two instances of a single Ada task type or generic.

Thus one chunk of software gives rise to what from the perspective of
the intuitive software architecture would be considered two CSCs or two
CSUs.  In fact, if the software were developed differently, these two
components could presumably be derived from two completely separate
chunks of source code.

Although this sounds like a confusing situation, I would argue that it
is in fact desirable as software developers strive for increased
abstraction and reuse.  This points out, though, how important it is to
understand independently the role that the categories CSC and CSU play
in software development and (in my opinion) to decouple that role from
unduly tight mappings to source code constructs.

Thanks for your comments.

-- Russ Abbott@uniblab.aero.org

pukite@vz.acs.umn.edu (J. PUKITE) (03/12/91)

In article <1991Mar11.164855.24098@aero.org>, abbott@aero.org (Russell J. Abbott) writes...
>There has been some discussion recently about the relationship between
>Ada constructs and the MIL-STD 2167A categories Computer Software
>Components (CSC) and Computer Software Unit (CSU).
> 
>Arguments range from claims that:
> 
>(a) mapping Ada to CSCs and CSUs is overly burdensome and a waste of
>time and energy;
> 
>to claims that:
> 
>(b) CSCs and CSUs are important software organizational categories that
>should be used independently of the language in which a software system
>is coded.
> 
>I would appreciate comments from anyone with an interest in this area.
> 
>I am especially interested in focusing on (b).  If CSCs and CSUs
>represent independently useful software organizational categories (and I
>think that they probably are): (1) how should those categories be
>defined, and (2) can those definitions be made compatible with OO
>approaches to software design?

Assuming that one follows 2167A software development process, then
the following applies:

CSCs and CSUs are defined prior to the start of actual coding.
As such they are not dependent on a specific language, but actually
describe the functional requirements in terms input, processing, and
output (this could be a HIPO chart).

The governing document is:

Software Design Document (DID: DI-MCCR-80012A)
DID - Data Item Description

Official description from the corresponding DID

Description and Purpose:

1. The Software Design Document (SDD) describes the complete design
of a Computer Software Configuration Item (CSCI).  It describes the
CSCI as composed of Computer Software Components (CSCs) and Computer
Software Units (CSUs).

2. The SDD describes the allocation of requirements from a CSCI to its
CSCs and CSUs.  Prior to Preliminary Design Review, the SDD is entered
into the Developmental Configuration for the CSCI.  Upon completion of
Physical Configuration Audit (PCA), the SDD, as part of the Software
Product Specification, is entered into the Product Baseline for the CSCI.

3. The SDD is used by the contractor for three primary purposes, namely:
(1) present the preliminary design at the Preliminary Design Review(s),
(2) present the detailed design at the Critical Design Review(s), and
(3) use the design information as the basis for coding each CSU.

4. The SDD is used by the Government to assess the preliminary and
detailed design of a CSCI.

------ end of quote ------

Thus, arguments (a) and (b) are not really applicable in a true 2167A if
the recommended approach is used.
It is always possible, that some people may want to start at the end and
after writing the program attempt to determine what it does and what kind
of structure it exhibits.

I hope that this may clear up the situation!

J. Pukite/DAINAe
pukite@vz.acs.umn.edu

jls@rutabaga.Rational.COM (Jim Showalter) (03/13/91)

I have spent the last three years of my career helping customers
to do decent OO and Ada software engineering within the confines
of 2167A.

My basic position is that 2167A is essentially worthless, gets in
the way of anything approaching a reasonable modern methodology
(e.g. rapid prototyping, iterative development, interface definition,
abstraction, modularity, reuse, Ada, etc), generates reams and
reams of fundamentally pointless documentation, encourages a
functional decomposition despite claims to the contrary, constrains
developers to an essentially waterfall lifecycle model, etc etc etc.

In short, it is an abomination and should be shitcanned, or at least
heavily tailored.

I was always amazed that the DoD did something right for once when
it came out with Ada. I kept waiting for the other shoe to drop.
2167A is that shoe.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
                   -- "When I want your opinion, I'll beat it out of you."