LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  November 1996

TEAM-ADA November 1996

Subject:

FW: OSD C4I Commissioned Ada Study Complete by NCR (fwd)

From:

AdaWorks <[log in to unmask]>

Reply-To:

AdaWorks <[log in to unmask]>

Date:

Sun, 3 Nov 1996 18:07:10 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (402 lines)

Some of you teamers have not seen the report. I am forwarding what
I received from OTG

----------
----------
From:  [log in to unmask][SMTP:[log in to unmask]]
Sent:  Saturday, November 02, 1996 5:48 AM

Dear DMIM Partners,

It looks like the Ada issue may soon be resolved.  It is likely that the
following recommendations will be incorporated in future policy after this
report is forwarded for congressional review and approval.

John Weiler
The OBJECTive TECHNOLOGY GROUP, Ltd.
[log in to unmask]
www.theotg.com
703-768-0400

------- Forwarded Message


Date: Fri, 1 Nov 1996 20:11:03 GMT
Reply-To: [log in to unmask]
Originator: [log in to unmask]
Sender: [log in to unmask]
From: Software Engineering Information Center
<[log in to unmask]>
To: [log in to unmask]
Subject: NRC CSTB Ada Public Briefing Summary

Computer Science and Telecommunications Board
National Research Council
210 Constitution Avenue, N.W., Washington, D.C.  20418

Phone: (202)334-2318
Fax: (202)334-2318
Internet: [log in to unmask]
World Wide Web: WWW2.NAS.EDU/CTSBWEB

Office Location
Milton Harris BLDG.RM 560
2001 Wisconsin Avenue, NW
Washington, D.C. 20007
(Off Whitehaven Street)

Committee on the Past and Present Contexts for the Use of
Ada in the Department of Defense

Barry Boehm, Chair
University of Southern California

Theodore Baker
Florida State University

Wesley Embry
Silicon Graphics, Inc.

Joseph Fox
Template Software

Paul Hilfinger
University of California at Berkeley

Maretta Holden
Boeing Defense and Space Group

J. Elliot B. Moss
University of Massachusetts at Amherst

Walker Royce
Rational Software Corporation

William Scherlis
Carnegie Mellon University

S. Tucker Taft
Intermetrics, Inc.

Rayford Vaughn
Electronic Data Systems Corporation

Anthony Wasserman
Interactive Development Environments, Inc.

Barbara Liskov, Special Advisor
Massachusetts Institute of Technology

Staff

Paul Semenza
Study Director, CSTB

Ada and Beyond: Software Policies for the Department of
Defense

What should the Department of Defense do about the Ada
programming language?  Despite the languages technical
capabilities, it has not been widely used outside of
military and other safety-critical applications, as was
hoped when the language was developed in the 1970s.  The
Defense Departments policy on programming languages, which
requires the use of Ada for all new software development,
has resulted in many conflicts and has not been implemented
evenly.  Meanwhile, commercial software applications have
grown rapidly, and do not generally use Ada.

The Committee on the Past and Present Contexts for the Use
of Ada in the Department of Defense was created by the
National Research Councils Computer Science and
Telecommunications Board to review the current policy, and
to examine the role of Ada in software development.  The
study was requested by the Office of the Assistant secretary
of Defense for Command, Control, Communications, and
Intelligence.  Released today, Ada and Beyond: Software
Policies for the Department of Defense presents the
committees findings and recommendations.

The committee concluded the vigorous support of Ada would
benefit warfighting systems, and recommends that the
Department of Defense should continue to use and promote Ada
in such systems.  However, the committee found significant
problems with the two primary components of the Defense
Departments current strategy for Ada.  First, the current
programming language policy requires the use of Ada for all
new defense software, which the committee finds to be overly
broad in scope.  Second, the Defense Departments plan to
discontinue investments in both Ada technology and user-
community support will weaken the Ada infrastructure, and
will work against any requirement to use Ada in the future.

In summary, Ada and Beyond:  Software Policies for the
Department of Defense concludes that the Defense Department
should  take the following steps regarding Ada:

1. Continue to require Ada for its warfighting software and
drop the Ada requirement for its other software.  In
commercially dominated areas, using Ada is generally less
cost-effective than using other languages.  Requiring the
use of Ada in these areas would place the Defense Department
at a competitive disadvantage.  In warfighting application
areas, however, Adas technical capabilities for real-time,
high assurance custom software are generally superior to
those of other languages.  The Defense Departments
investments in Ada to date have created a set of Ada-based
production factors that give its system advantages in these
areas.

2. Provide roughly $15 million per year for Ada
infrastructure support, or drop the requirement to use Ada
entirely.  The commercial marketplace will not sustain a
robust Ada infrastructure.  However, a relatively modest
($15 million per year) investment at the margin by the
Defense Department would be sufficient to sustain a robust
Ada infrastructure for warfighting applications.  The
Defense Departments inventory of more than 50 million lines
of warfighting software must either be maintained in Ada or
converted to another programming language.  The recommended
investment is modest with this maintenance burden.

3. Make programming language decisions in the context of a
Software Engineering Plan Review process.  The choice of
programming language is one component of the software-
engineering process, and should be considered in the broader
context of decisions regarding architecture, software reuse,
and software process management.

In the course of this study, the committee also concluded
that the currently available data are insufficient, on their
own, to accurately determine the impact of programming
language choice on the outcome of defense programs.
Committee briefings also highlighted the difficulty that
program managers have in finding data on which they can make
informed decisions.  Based on the limitations of
availability data, the committee has made an additional
recommendation that the Defense Department institute a
corporate effort to collect software metrics to guide future
policy and management decisions.

The committee developed its recommendations, presented in
detail in Ada and Beyond:  Software Policies for the
Department of Defense, in light of changes in the
environment for military software development.  A decade
ago, the policy preference for Ada had some merit.  Most
software was custom made, and Ada had a good track record in
delivering custom software with higher quality and lower
life-cycle costs.  However, custom Ada solutions are no
longer competitive in many application areas, due to several
trends.  First, software solutions increasingly depend on
commercial-off-the-shelf, or COTS, software, which provides
much of an applications information infrastructure,
including operating system, database management, networking,
user interface, and distributed processing functions.  Much
of this software is written in programming languages other
than Ada, that often do not have readily available
interfaces to programs written in Ada.

Second, software for many application areas is increasingly
developed in so-called product-line architectures, which
enable software assets to be reused across families of
applications.  These product-line solutions are driven by
strongly coupled production factors, including software
components, processes and methods, human resources, and
expertise in particular domains.  In warfighting
applications areas such as weapon control and electronic
warfare, there is little commercial development, and the
Defense Department has established a strong community of
warfighting software developers whose production factors are
oriented to Ada.  However, for the numerous defense
applications in which the market is dominated by commercial
solutions, such as finance and logistics, production factors
have been built around programming languages other than Ada
putting solutions at a disadvantage.

Several other factors have strongly influenced the
committees findings and recommendations.  One is the
Defense Departments increasing emphasis on information
dominance.  According to Secretary of Defense William Perry,
the Defense Departments warfighting strategy sustains and
builds on ... the application of information technology to
gain great military leverage to continue to give us [an]
unfair competitive advantage.  A second factor is that the
Defense Department now has more than 50 million lines of
operational weapon systems software written in Ada, with a
great deal more under development.  Most of this software is
in critical warfighting applications areas.  There are no
quick and cheap ways to translate this software into other
languages.  Polices and investment strategies that weaken
Ada support for this software are very risky.

A third factor is that, while language proliferation has
decreased, "polylingualism" is here to stay.  One goal of
developing Ada was to reduce the proliferation of
programming languages used in defense systems, estimated to
be approximately 450 in the 1970s.  The number of languages
used in defense systems has indeed decreased.  The use of
machine and assembly languages has diminished, and the
number of third-generation languages in use has been
reduced.  However, there has been a rapid increase in
development of fourth-generation languages by the commercial
sector, and increased use of these languages by defense
programs.  A final factor is that choosing a programming
language is one of several key software engineering
decisions.  The requirement to use Ada and the waiver
process both isolate programming language decisions from
other key software engineering decisions.  Modern software
engineering considerations include the choices of computer
and software architectures, COTS components, and milestone
schedules.  This arrangement creates an incentive for
defense programs to make decisions that are not optimal for
the Defense Department as an organization.  Future
programming language decisions need to be part of an
integrated software engineering process.



This report will be available electronically on the World
Wide Web in mid-November at <www2.nas.edu/cstbweb>.  Paper
copies will be made available in December.

Computer Science and Telecommunications Board
National Research Council
210 Constitution Avenue, N.W., Washington, D.C.  20418

Phone: (202)334-2318
Fax: (202)334-2318
Internet: [log in to unmask]
World Wide Web: WWW2.NAS.EDU/CTSBWEB

Office Location
Milton Harris BLDG.RM 560
2001 Wisconsin Avenue, NW
Washington, D.C. 20007
(Off Whitehaven Street)

Committee on the Past and Present Contexts for the Use of
Ada in the Department of Defense

Barry Boehm, Chair
University of Southern California

Theodore Baker
Florida State University

Wesley Embry
Silicon Graphics, Inc.

Joseph Fox
Template Software

Paul Hilfinger
University of California at Berkeley

Maretta Holden
Boeing Defense and Space Group

J. Elliot B. Moss
University of Massachusetts at Amherst

Walker Royce
Rational Software Corporation

William Scherlis
Carnegie Mellon University

S. Tucker Taft
Intermetrics, Inc.

Rayford Vaughn
Electronic Data Systems Corporation

Anthony Wasserman
Interactive Development Environments, Inc.

Barbara Liskov, Special Advisor
Massachusetts Institute of Technology

Staff

Paul Semenza
Study Director, CSTB



This report will be available electronically on the World
Wide Web in mid-November at <www2.nas.edu/cstbweb>.  Paper
copies will be made available in December.

*******************************************************

The Defense Information Systems Agency (DISA) Software
Engineering Information Center (SEIC) "Software Engineering
News Brief" is a compilation of summaries from software
engineering-related articles in trade magazines, newsletters
and press releases. The DISA SEIC welcomes suggestions for,
and pointers to, software engineering-related articles.

Contact the DISA SEIC at:

[log in to unmask]

To subscribe to the "Software Engineering News Brief"
electronic mailing list, send a message to:
        [log in to unmask]
In the body of the message, write:
        subscribe newslist <your name>
To unsubscribe, write:
        unsubscribe newslist
No signatures please.


------- End of Forwarded Message


--
Scott L. Surer
The MITRE Corporation
617-271-8886


----------------------- Headers --------------------------------
>From [log in to unmask]  Fri Nov  1 16:03:55 1996
Return-Path: [log in to unmask]
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by
emin16.mail.aol.com (8.6.12/8.6.12) with ESMTP id QAA18792; Fri, 1 Nov 1996
16:03:54 -0500
Received: from mail91.mitre.org (mail91.mitre.org [129.83.20.13]) by
mbunix.mitre.org (8.7.6/8.7.3/mitre.0) with SMTP id PAA23340; Fri, 1 Nov 1996
15:57:28 -0500 (EST)
Received: from mail91.mitre.org by mail91.mitre.org;
(5.65v3.2/1.1.8.2/22Jun94-0628PM)
        id AA23457; Fri, 1 Nov 1996 15:57:18 -0500
Received: from MAIL91.MITRE.ORG by MAIL91.MITRE.ORG (LISTSERV-TCP/IP release
          1.8b) with spool id 252440 for [log in to unmask];
Fri,
          1 Nov 1996 15:57:18 -0500
Received: from mbunix by mail91.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM)
id
          AA24015; Fri, 1 Nov 1996 15:57:17 -0500
Received: from scotty.mitre.org (scotty.mitre.org [129.83.70.27]) by
          mbunix.mitre.org (8.7.6/8.7.3/mitre.0) with SMTP id PAA23306 for
          <[log in to unmask]>; Fri, 1 Nov 1996 15:57:17 -0500
          (EST)
Received: from charity.mitre.org by scotty.mitre.org (8.6.7/ITF-Bedford) id
          PAA04362; Fri, 1 Nov 1996 15:57:14 -0500
Received: by charity.mitre.org (4.1/RCF-4C) id AA14294; Fri, 1 Nov 96
16:02:32
          EST
X-Mailer: exmh version 1.6.4 10/10/95
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id:  <[log in to unmask]>
Date:         Fri, 1 Nov 1996 16:02:31 -0500
Reply-To: [log in to unmask]
Sender: GCCS Distributed Computing Working Group
              <[log in to unmask]>
From: "Scott L. Surer" <[log in to unmask]>
Subject:      text of NRC report
To: Multiple recipients of list GCCS-DCWG-LIST
              <[log in to unmask]>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager