Re: 2167A Questions

Re: 2167A Questions

[Donn Hines]

In article 26847@sctc.com, aldrin@sctc.com (John Aldrin) writes:
>I assume most people involved with this group work in the defense 
>community so I thought I would post these questions here.
>The company I work for has just decided to write their doco
>to the 2167A format.  The concept of what the definition of CSU's, CSC's and
>CSCI's are somewhat vague.  I was hoping those of u who have dealt with
>this standard may be able to provide good definitions of CSU's, CSC's and
>CSCI's.  Any real-life examples would be greatly appreciated.
>

Hello.

We are undertaking a project that "wants" 2167A documentation also. I attended
WAdaS (Washington Ada Symposium) in late June. One focus was the upcoming repla
cement
for 2167A, currently referred to as MIL-STD-SDD (probably will be 498). It appe
ars
that it will be more flexible, supporting any design paradigm
(OOD, structured design, whatever) and any lifecycle methodology (waterfall, sp
iral,
etc.) Hopefully it will eliminate CSC's and CSU's also. I believe it is due to
be out in the spring-summer '94 timeframe (maybe earlier?), and you can obtain 
draft
copies.

Lewis Gray, Chair of Software Development Standards and Ada Working Group (SDSA
WG)
is an important point of contact. Email for him is gray@ajpo.sei.cmu.edu, and
he can point you in the right direction. I know you can get copies on floppy, a
nd
probably via ftp (I need to get a copy myself).

Anyway, we intend to shoot towards the new standard rather than tie ourselves
in knots with 2167A. Our approach will be to "tailor 2167A towards the new stan
dard"
(whatever that means).

We (a coworker and I) drew up a trip report that highlighted some of the benifi
ts
of the new standard. Email me and I will send you the relevant exerpts from our
report.

-donn hines    hines@paloverde.lanl.gov

Re: 2167A Questions

[Morris J. Zwick]

In article <1993Jul21.142339.20342@schbbs.mot.com> tannen@tigger.geg.mot.com
(David Tannen) writes:
>When working in 2167A I have tried to organize system in the following manner:
>
>	CSU = package (ie Unit test is @ the package level)
>	CSC = subsystem(s) There can be multiple layers of CSCs if you want.
>	CSCI = whole system (all the CSCs)
>
>For instance:
>	Your system will have three different pieces of hardware (A,B,C) and 
>	the system is called XYZ.
>
>	Subdivide the system as so:
>		XYZ CSCI
>		A CSC
>		B CSC
>		C CSC
>

I'm not sure I agree with this. Typically, CSCI's are determined to be
"autonomous" systems or subsystems. Code running on each piece of hardware can
generally be considered as separate subsystems. Perhaps my disagreement further
highlights some of the problems with 2167A.

I'll try a different example. Say we have some weapons control system with two
computers, A&B. Let's say that computer A contains subsystems to track the
target(a), determine if we can shoot at the target(b), and tell the equipment
to do something about it(c). Let's say computer B contains subsystems to accept
sensor data (d) and control display devices (e).

First, the CSUs in the system are represented by each procedure, function, or
package in the system. This is the easiest part. Let's say in computer A, CSU's
(a1),(a2),(a3),and(a4) concern tracking the target, (b1),(b2), and (b3) concern
determining if we can shoot at the target, etc. In this (very) simplistic case,
I would say that (a),(b),(c),(d),and(e) are all CSCs, and CSC (a) has component
CSUs (a1),(a2),(a3),and(a4), CSC (b) has component CSUs (b1),(b2),and(b3), etc.
Last, depending on the designers, we COULD have CSCIs A and B, where CSCI A is
called something like Target Tracking and Scheduling Subsystem and CSCI B is
Sensor Data and Display Subsystem. CSCI A would be composed of CSCs (a), (b),
and (c) and CSCI B would be composed of CSCs (d) and (e).

Of course, in a real system we would probably have many more lower-level CSCs
and the highest level CSCs, (a) and (b) for example, would be made up of other
CSCs. However, you get the idea. The whole purpose of the exercise is to
decompose the system into manageable components. There is no "right" way to do
this for any given system. That's why they pay us the big bucks ;)

Hope this helps,
         ___________________________________________________________________
        /  Morris J. Zwick	                 Internet: mzwick@vitro.com
__     /   Vitro Corporation	             Voice:    (301) 231-2784
  \   /    14000 Georgia Ave.                ___________________________
   \ /     Silver Spring, MD 20906-2972      |"I don't want the world; |
    *                                        | I just want your half!" |
                                             |  - They Might Be Giants |

Re: 2167A Questions

[david.c.willett]

>From article <1993Jul21.200159.32712@source.asset.com>, by vand@source.asset.c
om (Laurence VanDolsen):

	{good advise on using 2167A deleted}


> There are many criticisms of 2167A that are specious.  In my opinion
> there is only one which is really true and important.  The 2167A
> document set is reasonably well designed to afford a customer an
> opportunity to review the design in progress and to 'participate' in the
> development of his/her system.  The documentation which results from an
> unimginative compliance with the Data Item Descriptions does NOT,
> however, provide very good support for the poor soul who will maintain
> the software after deployment.
> 
> Laurence L. Van Dolsen - Der fliegender Hollander
> My opinions are my own, but you are welcome to them.
> Paramax - (805) 987-9302 - vandolsen@cam.paramax.com
> 

Brother, will I second that observation!  Using the 2167A documentation set
for maintenance is terribly frustrating because you *know* that what you're
looking for is in there *somewhere* but where is it!

DOD-STD-2168 could use some help too.  It doesn't seem to consider the needs
of the maintainer either.  I suppose that since they've decided to rewrite
the standard(s), this observation is academic, but I've always maintained
that the problem could be fixed with the DIDs, leaving the standard(s) 
untouched.

-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
If you want to know --- ASK!  -- Linda Ellerbee

RE: 2167A Questions

[MMC/CS 609-338-2922/8-794-2922]

>Date: 21 Jul 93 20:01:59 GMT
>From: agate!howland.reston.ans.net!darwin.sura.net!source.asset.com!vand@ucbva
x.Berkeley.EDU  (Laurence VanDolsen)
>Subject: Re: 2167A Questions
>Message-ID: <1993Jul21.200159.32712@source.asset.com>

>In article <1993Jul21.143352.17146@newshost.lanl.gov> hines@paloverde.lanl.gov
 writes:
>
>In article 26847@sctc.com, aldrin@sctc.com (John Aldrin) writes:
>> ...  The concept of what the definition of CSU's, CSC's and
>>CSCI's are somewhat vague.  I was hoping those of u who have dealt with
>>this standard may be able to provide good definitions of CSU's, CSC's and
>>CSCI's.
>
>Anyway, we intend to shoot towards the new standard rather than tie ourselves
>in knots with 2167A. Our approach will be to "tailor 2167A towards the new sta
ndard"
>(whatever that means).
>>>Mr Van Dolson's response to the above was good - I add my 2 
cents.

CSCI/CSC/CSU:
1.  Look at CSCI/CSC/CSU like Book/Chapter/Paragraph.  You 
declare something a paragraph because it has sentences which 
convey a thought; chapters are groupings of paragraphs addressing 
some aspect of a theme; the book addresses the entire theme.  Your 
chapter may be my book - there is no *right* answer.
2.  When defining CSCIs, think about how you are going to be 
doing configuration management (documenting changes, bumping up 
rev levels, etc).  If you have defined 2 CSCIs and think 
modifying one will almost always require modification of the 
other, they should probably be merged.
3.  For a DoD job, it is better to *err* with too few rather than 
twoo many CSCIs - CSCI documentation is a major cost driver.
4.  If you are working Ada, many people declare a package to be a 
CSC and procedures to be CSUs.  For a DoD job, you often have to 
report progress at the CSC level so it is important to group CSUs 
or you'll get in a tight loop writing progress reports on why 
you are late because you are always writing progress reports.
5.  When declaring a CSC, plan on testing all its CSUs at the 
same time.  This should save you a lot of drivers and stubs.

2167A:
1.  Agree that it is a pretty good framework for guiding projects 
- but it must be intelligently tailored to your project.
2.  If your customer thinks Moses brought 2167A down on a second 
set of stone tablets, find a good sector mutual fund that 
concentrates in pharmaceuticals - look for holdings in 
manufacturers of Maalox, Aspirin, etc.
3.  2167A requires traceability of requirements to CSUs.  Type 1 
customers require this; Type 2 customers go for the CSC level.  
Everyone should have a Type 1 customer so they appreciate Type 2. 
One of the purposes of requirements allocation is to establish 
the basis for test plans.  Test Plans/Procedures are usually 
written to test CSCs rather than CSUs  It's similar to trying to 
understand the significance of a paragraph - you normally need to 
read the chapter to find out the significance of a paragraph and 
whether the paragraph hits its mark.

Allen L. Starr, Martin Marietta Corp/Communications Systems/AE-2E
One Federal Street, Camden, NJ 08102  astarr@carib.vf.ge.com
phone:  609-338-2922; fax: 609-338-4686
-----------------------------

Re: 2167A Questions

[Colin James 0621]

  
Several writers have classified Computer Software Configuration Item
(CSCI), Computer Software Component (CSC), and Computer Software Unit
(CSU), eg, respectively as book, chapter, and paragraph.   This is
not exact because a CSC may be composed of other lower level CSCs.
However a CSCI may not be composed of other CSCIs nor are CSUs
composed of other CSUs.
  
The confusion with these items seems to arise when designing and 
mapping them to Ada.  David Maibor, one of the principal authors of
DoD-STD-2167A/2168, makes the important point that CSCs may be
composed of other CSCs;  Donald Firesmith of Advanced Software 
Technology Specialists, Ossian, IN has invented a convenient methodology
of mapping design objects within the 2167A cycle to Ada objects in
general;  and I have invented a method, based on Jackson, of directly
mapping objects on a one-to-one basis from the requirements/specifications
phase into Ada implementation objects (known as Object Oriented Life
Cycle [OOLC]).  This decomposes specifications from users into objects
and operations, recomposes them into software requirements and
documentsion, maps these into the software design components of
Dod-STD-2167A, implements them directly into the language structures
of Ada-83, and traces quality assurance and configuration control for
managers according to Dod-STD-2168. (OOLC won't brush your teeth :-<  .)
  
In recent times, many other methods have attempted to address the 2167A
to Ada connection.  As I recall, Rational abandoned trying.  But there
are at least two successful methods, namely Firesmith's and mine.
  

Re: 2167A Questions

[Andy Simmons]

In article <9307230603.aa19185@dsc.blm.gov>, cjames@DSC.BLM.GOV (Colin James 06
21) writes:
> 
>   
> Several writers have classified Computer Software Configuration Item
> (CSCI), Computer Software Component (CSC), and Computer Software Unit
> (CSU), eg, respectively as book, chapter, and paragraph.   This is
> not exact because a CSC may be composed of other lower level CSCs.
> However a CSCI may not be composed of other CSCIs nor are CSUs
> composed of other CSUs.
>   
> The confusion with these items seems to arise when designing and 
> mapping them to Ada.  David Maibor, one of the principal authors of
> DoD-STD-2167A/2168, makes the important point that CSCs may be
> composed of other CSCs;  Donald Firesmith of Advanced Software 
> Technology Specialists, Ossian, IN has invented a convenient methodology
> of mapping design objects within the 2167A cycle to Ada objects in
> general;  and I have invented a method, based on Jackson, of directly
> mapping objects on a one-to-one basis from the requirements/specifications
> phase into Ada implementation objects (known as Object Oriented Life
> Cycle [OOLC]).  This decomposes specifications from users into objects
> and operations, recomposes them into software requirements and
> documentsion, maps these into the software design components of
> Dod-STD-2167A, implements them directly into the language structures
> of Ada-83, and traces quality assurance and configuration control for
> managers according to Dod-STD-2168. (OOLC won't brush your teeth :-<  .)
>   
> In recent times, many other methods have attempted to address the 2167A
> to Ada connection.  As I recall, Rational abandoned trying.  But there
> are at least two successful methods, namely Firesmith's and mine.
>   

As one of the people at Rational responsible for addressing the use of various 
methods with Ada and 2167A I must take exception with your statement that "...R
ational abandonded trying."

At the Nov.`92 Tri-Ada conference Grady Booch and I presented a tutorial on usi
ng OO for 2167A compliant Ada development.  In that tutorial we describe a meth
od that recommends mapping class categories to CSCIs, nested class categories t
o CSCs and collections of Ada units to CSUs.  This is consistent with approache
s I have observed througout the industry and an earlier posting from Laurence V
anDolsen that suggests that CSCIs and CSCs are management abstractions and CSUs
 correspond to Ada compilation units.

  VanDolsen's posting conveys some very good advice about the standards.  I als
o recommend reading the report on Implementing the DOD-STD-2167 and DOD-STD-216
7A Software Organizational Structure in Ada, by the Software Organization Subgr
oup of the Software Development Standards and Ada Working Group (SDSAWG), Assoc
iation for Computing Machinery (ACM), Special Interest Group on Ada (SIGAda), A
ugust 1990.
Copies of the tutorial including guidelines for tailoring the SRS, IRS, SDD, an
d IDD are available upon request.  Send E-Mail to Mike Ruf (mpr@rational.com) t
o request a hardcopy.

We are actively engaged with our customers in applying this method to real proj
ects.  We continue to evolve and refine the method based on experience.

Rational is committed to supporting Ada and assisting our customers with its us
e including methods that address "the 2167A to Ada connection".  Our products a
nd services demonstrate that we are far from abandoning this effort.

Re: 2167A Questions

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!spool.mu.ed]

Morris J. Zwick (mzwick@vitro.com) wrote:
: In article <1993Jul21.142339.20342@schbbs.mot.com> tannen@tigger.geg.mot.com
: (David Tannen) writes:
: >When working in 2167A I have tried to organize system in the following manne
r:
: >
: >	CSU = package (ie Unit test is @ the package level)
: >	CSC = subsystem(s) There can be multiple layers of CSCs if you want.
: >	CSCI = whole system (all the CSCs)
: >
: >For instance:
: >	Your system will have three different pieces of hardware (A,B,C) and 
: >	the system is called XYZ.
: >
: >	Subdivide the system as so:
: >		XYZ CSCI
: >		A CSC
: >		B CSC
: >		C CSC
: >

: I'm not sure I agree with this. Typically, CSCI's are determined to be
: "autonomous" systems or subsystems. Code running on each piece of hardware ca
n
: generally be considered as separate subsystems. Perhaps my disagreement furth
er
: highlights some of the problems with 2167A.

: I'll try a different example. Say we have some weapons control system with tw
o
: computers, A&B. Let's say that computer A contains subsystems to track the
: target(a), determine if we can shoot at the target(b), and tell the equipment
: to do something about it(c). Let's say computer B contains subsystems to acce
pt
: sensor data (d) and control display devices (e).

: First, the CSUs in the system are represented by each procedure, function, or
: package in the system. This is the easiest part. Let's say in computer A, CSU
's
 
**** line deleted ****

Look at the name  CSCI.  A *Computer Software Configuration Item* is just
that.  It is a deliverable unit.  It is something a bean counter checks off
and pays for and does not know that is has CSCs inside.  A system can have
more than one CSCI.  In most cases one CSCI per executable unit.

A CSU is the thing that you unit test.  Do you test the *seperates* or
the packages?  you choice.  mine is packages.

CSC can be anything to aid decomposition.

-- Chris ALbertson   pasadena@netcom.com