commercial specifications opensyst

8/7/2019 COMMERCIAL SPECIFICATIONS opensyst

1/33

COMMERCIAL SPECIFICATIONS/OPEN STANDARDS

FOCUS AREA: REQUIREMENTS Systems Engineering

Definition and Summary: Taking an open systems approach (using commercial specs and

standards) to systems development. Military specs and standards are replaced by performancespecifications; the burden of selecting the specifications and standards lies with the developer,not the acquirer.

The Open Systems Approach represents a paradigm shift in system development focus to adesign methodology that addresses affordability as well as performance. Implementationrequires different skills and a different technical knowledge base than traditional design. Itrequires adherence to a systems engineering process that addresses affordability and performancegoals at the architecture level. Performance goals relating to the functional capability of thesubject system are equally important, but are not addressed in detail here because they are

already the focus of development and have been for years. The Open Systems Approach is aboutcontinuing to provide required functional capabilities, but making them affordable.

Successful implementation of the practice of using a Commercial Specifications and Standards/OpenSystems Approach can result in:

Improving the affordability of systems over their life cycle

Greater adaptability to evolving requirements and threats Mitigating the risk associated with technology obsolescence Reducing development cycle time Achieving higher levels of performance

DESCRIPTION OF THE PRACTICE:

SUMMARY DESCRIPTION

The Open Systems Approach, as represented by this Commercial Specifications/Open Standardspractice, represents a paradigm shift in system development focus to a design methodology thataddresses affordability as well as performance. Implementation requires different skills and adifferent technical knowledge base than traditional design. It requires adherence to a systemsengineering process that addresses affordability and performance goals at the architecture level.The figure below identifies the essential activities of Open Systems Approach as it relates to


2/33

affordability. Performance goals relating to the functional capability of the subject system areequally important, but are not addressed in detail here because they are already the focus ofdevelopment and have been for years. The Open Systems Approach is about continuing toprovide required functional capabilities, but making them affordable.

The Open Systems Process for Achieving Affordability

Some key open systems principles are:

1. Build an architecture using a disciplined systems engineering process

2. Identify and define interfaces early in the development cycle, but delay implementationas long as practical

3. Define criteria for interface choices: at a minimum measure openness, maturity, andapplicability

4. Consider system evolution (and how it might impact an interface decision)

5. Identify firewall interfaces to isolate the impact that changes in one component have onanother, and to enable seamless evolution

6. Consider how the interfaces will enable reuse, potentially reducing development andproduction costs


3/33

7. Define domain specific catalogs of preferred standards

8. Manage interfaces to reduce the risks involved in using COTS

9. Define the open system architecture-first insert COTS where appropriate. (COTS does

not equal OPEN; non-open COTS leads to vendor dependencies)

10. Employ a commercial check of COTS prior to finalizing implementation decisions

11. Perform market analysis to assess the future support for a candidate interface standard

12. Build strategic supplier relationships to ensure support for maintenance and integrationof COTS

13. Ensure product compliance to standards for both COTS and custom products. Tie testsfor compliance to the selection process. Ensure product certification.

14. Use innovative approaches during upfront engineering to ensure that systems will meetperformance and environmental requirements using commercial components andproducts


4/33

DETAILED DESCRIPTION

Due to the scope and breadth of this practice, it makes sense to describe it from the long acceptedframework of questions as follows:

Why? Why would this practice be implemented? What are the key motivating factors?What problems does this practice try to solve?

What? What exactly is the practice? What are its key elements? What are its guidingprinciples?

Who? Who needs to be involved? Who are the stakeholders and what are theirrespective responsibilities?

Where? At what levels within and/or across organizations/programs does this practice

make sense? Where are the boundaries, or what criteria would serve as a basis fordefining its boundaries?

When? When should this practice be implemented relative to the life cycle of a projector program?

How? How does the practice get implemented? How do you make it happen? What arethe essential activities? What are some of the lessons learned?

Why?

Why would this practice be implemented? What are the key motivating factors? What problemsdoes this practice try to solve?

There are a multitude of reasons for implementing this practice asindicated in the many references from the Interim DefenseAcquisition Guidebook cited above (see C5.2.3.5.5.2). Inessence, the Open Systems Approach (OSA) is viewed as the keyto integrating the initiatives that impact affordability withthose that impact performancein order to achieve/sustain the

appropriate balance of those broad goals (See Figure 1).

Open Systems Approach addresses a rapidly changing technicalenvironment characterized by a need to address:

Complex systems

Faster delivery of increasing capability

Evolving requirements and capabilities


5/33

Maintaining a technology base for the system life cycle

Increasing demand for interoperability

What?

What exactly is the open systems approach? What are the essential elements of the practice?What are its guiding principles?

Lets examine the key phrases from the Open Systems Approach definition provided by the Open Systems Joint

Task Force:

integrated business AND technicalstrategy a strategy for building software-intensive systems thataddresses both business and technical goals (issues of affordability and performance) from an integratedperspective in order to achieve a balance that will ensure needs of the warfighter are met while

sustaining/improving affordability.

employs a modular design Modular design is the key to achieving flexibility, enablingtechnology insertion and evolvability, and ultimately having a positive impact on affordability overthe life cycle of the system. Modular design, in this context, also implies independence.

Figure 2(a) illustrates the structure of a typical system under the traditional design approach of the 80sand early 90s, in which the modules were tightly coupled with the subsystems they supported. Theconnectivity of modules to subsystems, and subsystems to systems, was generally customized and,therefore, unique to each system. This structure offered some degree of modularity in that a subsystem(or module) could be added or removed without having to redesign the entire system provided itoriginated from the same development environment (language). Some benefits were also derived fromreusing common modules (functions) typically provided with the development language library in

multiple systems/subsystems. However, each new system had to be built from scratch (even thoughideas were reused) and required significant resources for its sustainment over the life cycle. As newtechnology emerges, the cost of sustaining these legacy systems goes up, making them less affordableas time passes.

With modular design implied by Open Systems Approach (see Figure 2(b)) individualcomponents, which arethe buildingblocks of systems, are independent entitiesthat plug &play together, and can be updated or replaced as needed quickly, without requiring a redesignof the entire system. Components need not originate from the same development environment,but must conform to the required interface standard. Modularity, with implied interfacestandards, is typically addressed at the architecture level in order to focus on the most important

problems of communication, connectivity, and evolving requirements early in the life cycle.Addressing modularity through architecture typically ensures that a system will be scalable,evolvable, and flexible, and, therefore, longer lasting at less cost.


6/33

defines key interfaces As illustrated in Figure 2(b), interfaces (based on standards) are the focusof the Open Systems Approach. All systems have structures that allow their subsystems andcomponents to work together to provide the required functionality, but use ofstandards-basedinterfaces (versus proprietary or custom designed elements) permit greater interchangeability,interconnection, compatibility and/or communications within a system, as well as across systems,and facilitate technology insertion over the system life cycle. Well-defined open interfaces arecritical to the success of the Open Systems Approach. The components and sub-systems areindependent entities that can be applied to various systems within a domain without re-design.

Which interfaces are the most important? Identifying the critical or key interfaces within a system is

essentially making an educated guess about which components and subsystems might/should beleveraged for other capabilities in the future. Part of the decision involves assessing the long term valuederived from including an open interface. This is sometimes very difficult because there is no immediatevalue to the current project but an interface may be necessary to ensure the interoperability of futuresystems in the domain.

using widely supported, consensus-based standards that are published and maintained by arecognized industrial standards organization. How do we determine what interface standards to use?Historically the government has developed and maintained its own set of standards to specify thephysical, functional, and operational relationships between various elements. Extensive governmentresources were required to support the initiative and developers incurred additional costs of complyingwith both the government standards and the more viable commercial standards. These factors combinedto drive up the cost of sustaining systems across their life cycle. Under Open Systems Approach, and

primarily driven by affordability issues, as well as the need to sustain a commercial technology base tosupport the demand for increased capability, the government, through acquisition policy, is shiftingthe responsibility for selecting (and maintaining) standards to the developer community. In doingthis, it expects to reap the benefits of innovative commercial technology, including a stable technologybase, at a reduced cost. Open interfaces are defined as those specifications and standards that are (1)widely used, (2) consensus-based, and (3) published and maintained by a recognized industrialstandards organization. The degree of openness that a system has is characterized by the extent towhich it uses standards that are mature, widely accepted, and allows for future technology insertion. Theprocess/activities for selecting the right standards are critical to achieving an open system solution, andthat focus represents a significant change in how systems are developed.


7/33

Who?

Who needs to be involved in this practice and what are their respective responsibilities?

Open Systems Approach works best with on-going interaction among the following

stakeholders operating under the structure of an Integrated Process and ProductDevelopment (IPPD) team. Interaction/participation from recognized standardsorganizations might enhance the solution space as well.

Program Manager establishes the necessary communication with other PMs in thedomain in order to assess interoperability issues, and opportunities for reuse

Domain Experts provide the operational expertise to help drive requirementsdefinition (including performance requirements)

System & SW Architects help define an architecture solution that addresses the

desired degree of openness in meeting the desired performance objectives of the system.Note: Architects represent highly skilled technical roles with significant designexperience. Project Managers typically do not have the required expertise to fulfill thisrole.

Developer Team follows a disciplined engineering process that includes participatingin specifying requirements, as well as developing the system. Development includes awell-defined marketing research process that results in knowledge of innovativetechnology and emerging commercial standards and specifications that may be candidatesfor the system architecture.

Where?

At what levels within and/or across organizations/programs does this practice make sense?Where are the boundaries, or what criteria would serve as a basis for defining its boundaries?

To achieve affordability results, open systems issues must be addressed at the architecture levelof a domain, or among groups of program managers, or within an Integrated Product Team (IPT)at the program office level or higher. To begin at the project level and establish an opensystems architecture in isolation makes no sense. The value of decision-making regardinginterface standards is based on the notion of reuse, compatibility, or interoperability amongseveral systems/programs within a domain. Although significant knowledge of interface

standards is required to implement an open systems approach, it is not a bottom-up strategy,because it is not possible to address the affordability issues from that level. A bottom-upapproach typically would weight the scale in favor of performance over affordability.

When?

When should this practice be implemented relative to the life cycle of a project or program?


8/33

Open Systems Approach is, by definition, focused on architecture. Therefore, most of theactivities associated with this approach should occur early in the life cycle, during architecting,or during inception and elaboration. It makes no sense to build a system based on whateverstrategy is dominant in the developer organization and then, after-the-fact, try to re-engineer it tobe an open system.

However, if you are in the middle of a phased development that is not using Open SystemsApproach, is it possible to alter the approach in favor of Open Systems Approach? In somecases, yes! For example, if you have completed requirements definition and are ready to startdesign, or to solicit for a developer, it may be possible to re-visit requirements by adding someperformance requirements relating to the use of interface standards, and a modular designapproach, that would set the stage for open systems development. The closer you are to actualcode development or production, the more difficult it will be to migrate to Open SystemsApproach.

The task of migrating legacy systems to open systems is complex. The feasibility of re-

engineering a legacy system versus building a new system must be studied. Keep in mind thekey motivators of affordability, as well as performance.

How?

How does the practice get implemented? How do you make it happen? What are the essentialactivities? What are some of the lessons learned?

Open systems concepts are founded on a set of principles that are used in the development andapplication of an open systems architecture that, in turn, is defined by open systems interfacestandards.

Some key open systems principles are:

1. Build an architecture using a disciplined systems engineering process

2. Identify and define interfaces early in the development cycle, but delay implementationas long as practical

3. Define criteria for interface choices: at a minimum measure openness, maturity, andapplicability

4.

Consider system evolution (and how it might impact an interface decision)

5. Identify firewall interfaces to isolate the impact that changes in one component have onanother, and to enable seamless evolution

6. Consider how the interfaces will enable reuse, potentially reducing development andproduction costs


9/33

7. Define domain specific catalogs of preferred standards

8. Manage interfaces to reduce the risks involved in using COTS

9. Define the open system architecture-first insert COTS where appropriate. (COTS does

not equal OPEN; non-open COTS leads to vendor dependencies)

10. Employ a commercial check of COTS prior to finalizing implementation decisions

11. Perform market analysis to assess the future support for a candidate interface standard

12. Build strategic supplier relationships to ensure support for maintenance and integrationof COTS

13. Ensure product compliance to standards for both COTS and custom products. Tie testsfor compliance to the selection process. Ensure product certification.

14. Use innovative approaches during upfront engineering to ensure that systems will meetperformance and environmental requirements using commercial components andproducts

Figure 3: The Open Systems Process for Achieving Affordability


10/33

The Open Systems Approach represents a paradigm shift in system development focus to adesign methodology that addresses affordability as well as performance. Implementationrequires different skills and a different technical knowledge base than traditional design. Itrequires adherence to a systems engineering process that addresses affordability and performancegoals at the architecture level. Figure 3 identifies the essential activities of Open Systems

Approach as it relates to affordability. Performance goals relating to the functional capability ofthe subject system are equally important, but are not addressed in detail here because they arealready the focus of development and have been for years. The Open Systems Approach is aboutcontinuing to provide required functional capabilities, but making them affordable.


11/33

CHARACTERISTICS OF IMPLEMENTATION:

SUMMARY CHARACTERISTICS

NO DATA CURRENTLY AVAILABLE

ANTICIPATED BENEFITS OF IMPLEMENTATION:

Successful implementation of the practice of using Commercial Specifications and Standards/OpenSystems Approach can result in:

Improving the affordabilityof systems over their life cycle by:

o Allowing programs to leverage commercially funded or developed technology

o Achieving economies that were previously unrealizable

o Taking advantage of increased competition

o Providing a lower cost path for insertion of new technologies in existing platforms

Greater adaptability to evolving requirements and threats Mitigating the risk associated with technology obsolescence

o Systems supported by a wide range of readily available products

Reducing development cycle time

o Faster upgrade of legacy systems with less complexity and cost

o Development of subsystems and components that are testable

o Enable application of a Product Line Approach to acquisition of weapons systems

y [Encompasses the assembly line idea, where basic platforms or frameworks are fittedwith subsystems or components to form a larger system to deliver a specified capability.The subsystems and components are designed to specified levels of openness and featuremodularity and interchangeable parts. Some subsystems or components may be commonto a variety of weapon platforms and identically interface with each platform.]


12/33

Achieving higher levels of performance

o Contributes to ensuring interoperability among systems without major modification of existingcomponents


13/33

DETAILED CHARACTERISTICS

Key Characteristics of the Commercial Specifications and Standards/Open Systems GoldPractice

Characteristic CommentsFocus onInterfaces

Complexity is managed via interfaces

Evolvability is managed via interfaces

Components are decoupled using interfacesDisciplined

Systems

EngineeringProcess

Systems dont just happen to be affordable

A disciplined process is required to address affordability over the life cycleof the project

Process must balance affordability with performanceWell-defined

Open Interfaces Key interfaces are based on widely used, consensus-based commercial

standards maintained by recognized standards organizationsRely on

PerformanceSpecifications

Acquirer provides performance specs, leaving decisions about how to thedeveloper

Developer is responsible for selecting the most appropriate standardsCommercial

Leverage

Commercial investment in innovative technology keeps a viable technologybase

Commercially developed and maintained interface standards are used inplace of government standards where possible

Seek to ImproveAffordability

Projects have an affordability plan

Evidenced by trade-off analysis relating to performance vs. affordability


14/33

RELATIONSHIPS TO OTHER PRACTICES:

The Figure below represents a high-level process architecture for the subject practice, depicting

relationships among this practice and the nature of the influences on the practice (describing howother practices might relate to this practice). These relationship statements are based ondefinitions of specific best practices found in the literature and the notion that the successfulimplementation of practices may influence (or are influenced by) the ability to successfullyimplement other practices. A brief description of these influences is included in the table below.

Process Architecture for the "Commercial Specifications & Standards/Open Systems" GoldPractice

Summary of Relationship Factors

INPUTS TO THE PRACTICE


15/33

Develop a strategy to supportuse of an open systemsapproach

ThePlanning for Technology Insertion practice parallels theOpen Systems Approach with respect to addressingaffordability issues. Open Systems Approach encompassesplanning for TI and is, therefore, impacted by the quality ofthe TI plan.

Integrated Product and Process Development (IPPD) bringstogether the key stakeholders, ensuring that domain experts,as well as system architects, participate in identifying keyopen interface candidates and interoperability requirementswithin a domain that help to determine which componentsand interfaces are most important. Developing andMaintaining a Life Cycle Business Case is part of the OpenSystems Approach because it addresses the affordability side

of the balance scale which, in turn, influences decisionsabout the design of the system and the degree of opennessit should have. Requiring Structured Development Methodsis more likely to result in a sound disciplined engineeringprocess being applied to requirements elicitation and to theidentification and selection of interfaces.

Promote use of an open systemsapproach during acquisition

Performance-Based Specifications identify required resultsand free the developer to make the best decisions about howto achieve those results. Performance specifications mustaddress all significant performance attributes such asinteroperability. Using Past Performance as part of the

criteria forBest Value Awards provides a way to secureknowledgeable, experienced developers who can actuallybuild open systems, and reduces the risk of acquisitionfailure.

Define an approach to elicitopen systems requirements

All three of the practices mentioned below accept the OpenSystems Approach tenet of balancing affordability withperformance. Negotiating Trade-Offs is a realistic approachto preserving the necessary balance. AchievingAgreementon Interfaces is part of theArchitecture-First Approach thatimproves affordability by addressing interfaces at thearchitecture level where necessary changes can be made with

the least impact on cost, and the greatest positive impact onperformance.


16/33

Identify management activitiesthat facilitate an open systemsapproach

Open Systems Approach, by definition, involves makingdecisions about COTS; COTS products have varying lifecycles that differ from the cycle of the product underdevelopment. Therefore, there is risk associated with usingCOTS (and the corresponding technology insertion

practices). Assessing the Risk of Reuse (implied by use ofCOTS), andFormally Managing Those Risks, is a significantfactor of the Open Systems Approach. The rationale forOpen Systems Approach is premised on the recognition thatthe operational environment of a system undergoes change,and with that comes changes to requirements over the lifecycle. Accepting requirements volatility andManaging theRequirements process is essential to achieving theaffordability gains purported for the Open SystemsApproach.

OUTPUTS FROM THE PRACTICE

Leverage technology to supportaffordability andinteroperability

Open Systems Approach is an essential activity forEnsuringInteroperability because the use of standards-basedinterfaces provides the structure that enables componentreuse across multiple programs and resolves issues with datainterchange. Since Open Systems Approach is based onwidely used consensus-based commercial interfacestandards, it facilitatesLeveraging COTS/NDIto achieveaffordability gains through innovative COTS integration andTechnology Insertion Initiatives.

RESOURCES:

Websites

o Defense Standardization Program OfficeWeb Site provides access to government andmilitary standards and specifications, and their status. It also provides guidance on writingperformance specifications.

http://www.dsp.dla.mil/

o Open Systems Joint Task ForceWeb Site contains documents describing the open systemsapproach and guidance for its implementation, as well as active pilot programs anddemonstration projects

http://www.acq.osd.mil/osjtf/

Tools and Methods


17/33

State-of-the-art methods and tools that may be useful in implementing and improving the effectiveness ofimplementing Open Systems Approach include:

Quality Function Deployment. Quality Function Deployment (QFD) is one technique for

evaluating trade-off scenarios. It is predicated on gaining an understanding of what the end userreally needs and expects. The QFD methodology allows for tracking/tracing trade-offs throughvarious levels of the project hierarchy, from requirements analysis, through the softwaredevelopment process, to operational and maintenance support.

Systems Thinking Techniques as defined by Peter Senge in his book titled The FifthDiscipline. Systems Thinking approaches the solution space on the premise that the whole is notonly greater than the sum of its parts, it is also fundamentally different than the sum of its parts.This is in contrast to the more traditional linear functional decomposition method. It is applied toproblems that are assumed to be complex (multivariate, with multiple linkages and feedbackloops), adaptive (able to respond to an environment of constant change without either stagnatingor dissolving) and non-linear.

Open Systems Joint Task ForceWeb Site/ Tools andGuides/ - provides several documents

addressing specific aspects of implementing an open systems approach.

http://www.acq.osd.mil/osjtf/implement/implement_tools.html

Turbo SpecRight - an online tool to assist those who develop, or review, performance specifications ... co-sponsored by the Defense Standardization Program Office and the Navy Acquisition Reform Office.http://www.ar.navy.mil/navyaos/content/view/full/223

JTA Referenced Standards Collection - an electronic compilation of all versions of the JTA document andquick-link to full text of most of the standards it specifies. http://global.ihs.com/news/gov1_4.html

ASSIST ON-LINE - a robust, comprehensive web site providing access to current information associatedwith military and federal specifications and standards in the management of the Defense StandardizationProgram (DSP). It is the official source of DoD specifications and standards. It can also be used to findout about standards that have been canceled. http://assist.daps.dla.mil/online/start/

Experts/Contact Points

NormanW. Kowalski, a Computer Scientist at the Naval Undersea Warfare Center(NUWC) Division Newport, Newport, Rhode Island. [See Kowalski bio]

Phone: 401-832-1298Email: [email protected]

Experts from the Open Systems Joint Task Force Operations


18/33

Lt. Col Glen Logan, OSD-ATLPhone: (703) 602-0851Email: [email protected]

Duane Hardy, OSD-ATLPhone: (703) 602-0851

Email: [email protected]. Cyrus Azani, OSD-ATLPhone: (703) 602-0851Email: [email protected]

Open Systems Joint Task ForceWeb Site identifies active pilot programs and demonstrationprojects, and has a library of downloadable documents describing various implementations of theOpen Systems Approach.

http://www.acq.osd.mil/osjtf/

Training Opportunities:

o OSJTF Training: Tutorials, courses, and related DAU courses are listed.

http://www.acq.osd.mil/osjtf/how_to_do_os/training/index.html

Specific relevant courses include:

y Open Systems Engineering: A downloadable PowerPoint presentation

http://www.acq.osd.mil/osjtf/mspowerpoint/apmc_en_mgmt_feb_2000.ppt

y The Open Systems Approach And Acquisition Management: A downloadablePowerPoint presentation

http://www.acq.osd.mil/osjtf/mspowerpoint/apmc_prmgmt_mar_2000.ppt

y Open Systems for Executives: An overview of open systems principles and major

weapon system procurements (in downloadable PowerPoint units)

http://www.acq.osd.mil/osjtf/how_to_do_os/training/osexec/index.html

y Open Systems Acquisition ofWeapons Systems: A 3-day workshop designed to giveparticipants practical skills for using Open Systems concepts in defense weapon systemsprograms

http://institute.brtrc.com/open.htm


19/33

Slides relating to the content for this course are available at the following URL:http://www.acq.osd.mil/osjtf/html/course.htm

o DSPO Training: SD-17 Making Standardization Decisions A course designedto help

engineers, logisticians, and other technical and acquisition personnel decide when andwhen not to standardize items and systems. Call the Document Automation & PrintingService at (215) 697-2179 and ask for a free copy of the SD-17 CD or download a copy fromthe SD-17 page.

o American National Standards Institute (ANSI) Portal to On-Line Learning: A basicorientation to standards for students, faculty, new employees or new committee members,and for non-standard professionals such as engineers, technologists, government andcorporate management staff. Go to www.standardslearn.org for more information.

o Defense Acquisition University (DAU) Standardization Training Courses

These courses do not address Open Systems Approach principles in general but they doaddress specific activities/skills that are used in an Open Systems Approach implementation.

y PQM 103, "Defense SpecificationManagement"http://www.dau.mil/catalog/Chapter%203.pdf

y PQM 104, "Specification Selection and

Application"http://www.dau.mil/catalog/Chapter%203.pdf

y PQM 202, "Commercial and Non-developmental ItemAcquisition"http://www.dau.mil/catalog/Chapter%203.pdf

y PQM 203, "Preparation of Commercial ItemDescriptions"http://www.dau.mil/catalog/Chapter%203.pdf

y PQM 212, "Market Research"http://www.dau.mil/catalog/Chapter%203.pdf

Bibliography:

[Anderson, 1998] Anderson, M. H. and Rebentisch, E., (1998). Commercial Practices -Dilemma or Opportunity?Program Manager27(2),pp. 16-21, 1998

http://www.dau.mil/pubs/pm/pmpdf98/andersma.pdf


20/33

[ARO Website] DoN Acquisition One Source website: Acquisition Topics -SystemsPlanning, Research, Development and Engineering (SPRDE)

http://www.ar.navy.mil/navyaos/acquisition_topics/systems_planning_research_development_and_engineering_sprde_/specifications_and_standards

[Bradley, 1996] Bradley, Ryan and Wimberly, Gary, Acquisition Reform of ExistingContracts: The Secretary of Defense Single Process Initiative,Crosstalk, 1996

http://www.stsc.hill.af.mil/crosstalk/1996/09/Acquisit.asp[CMU/SEI-2002-TR-011]

Capability Maturity Model Integration (CMMI), Version 1.1 ContinuousRepresentation, Software Engineering Institute, CMU/SEI-2002-TR-011,March 2002

http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr001.pdf

[CMU/SEI-2002-TR-012]

Capability Maturity Model Integration (CMMI), Version 1.1 StagedRepresentation, Software Engineering Institute, CMU/SEI-2002-TR-012,March 2002

http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr002.pdf

[DODD 5000.2] DoD 5000.2-R, Mandatory Procedures for Major Defense AcquisitionPrograms (MDAPS) and Major Automated Information System (MAIS)

Acquisition Programs, 5 April 2002

http://www.acq.osd.mil/dpap/Docs/020405.Regulation.pdf

[DSP, 2001] Frequently Asked Questions, Version 1.3.1, DSP Web Site, DefenseStandardization Program Office, 2001

http://www.dsp.dla.mil/faq/faq.htm

[GOVNEWSLTR,2003a]

Joint Technical Architecture Standards and Related Publications,Government Newsletter, Issue 2, Vol. 2, 2003

http://global.ihs.com/news/gov1_4.html[GOVNEWSLTR,2003b]

New JTA Referenced Standards Collection Compliance MadeEasier, Government Newsletter, Issue 2, Vol. 2, 2003

http://global.ihs.com/news/gov1_3.html


21/33


22/33


23/33

APPENDICES

DEFINITIONS:

The practice of taking an open systems approach (premised on using commercialspecifications and standards) to systems development and sustainment. Military specs andstandards are replaced by performance specifications where possible and the burden of selectingthe appropriate specifications and standards (to meet the performance specification) lies with thedeveloper, rather than with the acquirer.

Related Definitions:

[Authors Note: The Open Systems Approach is NOT THE SAME as the Open Source Initiative(OSI), although an Open Systems Approach may use open source material in its solution. SeeGlossary].

An Open Systems Approach (OSA)defines key systems interfaces by widely used,

consensus-based interface standards to leverage commercial products and practicesin order to field superior war fighting capability more quickly and affordably. An OpenSystems Approach mitigates technology obsolescence risk over the service life of theweapons systems by achieving multiple sources of supply and technology insertion.

[Software Collaborators Workshop (SCW), 1999]

An Open Systems Approach is an integrated business and technical strategy that employs amodular design and, where appropriate, defines key interfaces using widely supported,consensus-based standards that are published and maintained by a recognized industrial

standards organization. [Open Systems Joint Task Force (OSJTF), 2001]

A performance specification states requirements in terms of the required results with criteria forverifying compliance, but without stating the methods for achieving the required results. Aperformance specification defines the functional requirements for the item, the environment inwhich it must operate, and interface and interchangeability characteristics. [NAVY AcquisitionReform Office (ARO) Website]


24/33

SOURCES (Origins of the Practice):

NONE INDICATED


25/33

RECOMMENDING SOURCES:

William J. Perry, Specifications and Standards a NewWay of Doing

Business, Memorandum to Defense Secretaries, 29 June 1994

I have repeatedly stated that moving to greater use of performance and commercial specifications and standards isone of the most important actions that DoD must take to ensure we are able to meet our military, economic, and

policy objectives in the future.[Perry, 1994]

DoD 5000.2-R, Mandatory Procedures for Major Defense AcquisitionPrograms (MDAPS) and Major Automated Information System (MAIS)Acquisition Programs, 5 April 2002 [CANCELLED 30 October 2002]

Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

C2.6.6.1.2 Acquisition strategies shall incorporate a performance-based business environment(PBBE) to enable Government customers and contractor suppliers to jointly capitalize oncommercial process efficiencies to improve acquisition and sustainment processes.

C2.6.6.3 Applying Best Practices. In tailoring an acquisition strategy, the ProgramManager (PM) shall address management constraints imposed on the contractor(s). PMsshall avoid imposing Government-unique restrictions that significantly increase industrycompliance costs or unnecessarily deter qualified contractors, including non-traditionaldefense firms, from proposing. Examples of practices that support the implementation of

these policies include ; performance-based specifications ; an open systemsapproach that emphasizes commercially supported practices, products, performancespecifications, and performance-based standards; replacement of Government-uniquemanagement and manufacturing systems with common, facility-wide systems;technology insertion for continuous affordability improvement throughout the productlife cycle ; Government-Industry partnerships, consistent with contract documents;

C2.7.1 Open Systems. PMs shall apply the open systems approach as an integratedbusiness and technical strategy upon defining user needs. PMs shall assess thefeasibility of using widely supported commercial interface standards in developingsystems. The open systems approach shall be an integral part of the overall acquisition

strategy to enable rapid acquisition with demonstrated technology, evolutionary andconventional development, interoperability, life cycle supportability, and incrementalsystem upgradeability without major redesign during initial procurement and re-procurement of systems, subsystems, components, spares, and services, and during post-production support. It shall enable continued access to cutting edge technologies andproducts and prevent being locked in to proprietary technology. PMs shall documenttheir approach for using open systems and include a summary of their approach as part oftheir overall acquisition strategy.


26/33

C2.8.3.1 Product Support Management Planning. At a minimum, product supportmanagement planning shall address how the program will accomplish the followingobjectives: C2.8.3.1.8 Improve product affordability, system reliability, maintainability,and supportability via continuous, dedicated investment in technology refreshmentthrough adoption of performance specifications, commercial standards, non-

developmental items (NDI), and Commercial-Off-The-S

helf (COTS

) items wherefeasible, in both the initial acquisition design phase and in all subsequent

modification and re-procurement actions.

C2.9.1.4.2.2 The commercial marketplace widely accepts and supports open interfacestandards, set by recognized standards organizations. These standards supportinteroperability, portability, scalability, and technology insertion. When selecting

commercial or non-developmental items, the PM shall prefer open interfacestandards and commercial item descriptions. If acquiring products with closedinterfaces, the PM shall conduct a business case analysis to justify acceptance of theassociated economic impacts on Total Ownership Costs (TOC) and risks to technology

insertion and maturation over the service life of the system.

C5.2.3.5.5.1 Open Systems Design. PMs shall use a modular, standards-basedarchitecture in the design of systems. They shall identify key interfaces and define

the system level (system-of-systems, system, subsystem, or component) at and above

which these interfaces use various types of standards. Preference shall be given to

the use of open interface standards first, then to de facto interface standards, andfinally to Government and proprietary interface standards. PMs shall report on theirprogress using open standards for key interfaces at both Milestones B and C.

C5.2.3.5.5.2 PMs shall use an open systems approach to achieve the following

objectives:

To adapt to evolving requirements and threats

To accelerate transition from science and technology into acquisition and deployment

To enhance modularity and facilitate systems integration

To leverage commercial investment in new technologies and products

To reduce the development cycle time and total life cycle cost

To ensure the system is fully interoperable with all systems with which it must interface, withoutmajor modification of existing components

To achieve commonality and reuse of components among systems

To provide users the ability to quickly and affordably interconnect and assemble existing platforms,systems, subsystems, and components, as needed


27/33

To maintain continued access to cutting edge technologies and products from multiple suppliersduring initial procurement, re-procurement, and post-production support

To mitigate the risks associated with technology obsolescence, being locked into proprietarytechnology, and reliance on a single source of supply over the life of a system

To conduct business case analyses to justify decisions to enhance life cycle supportability andcontinuously improve product affordability through technology insertion during initial procurement,re-procurement, and post-production support

To facilitate modular contracting

C5.3.2 PerformanceSpecifications. The Department shall use performancespecifications (i.e., DoD performance specifications, commercial item descriptions, andperformance-based non-government standards) when purchasing new systems, majormodifications, upgrades to current systems, and commercial and non-developmental

items for programs in all acquisition categories. The Department shall emphasizeconversion to performance specifications for re-procurements of existing systems at thesubsystems level, and for components, spares, and services, where supported by abusiness case analysis, for programs in all acquisition categories.


28/33

GLOSSARY

Affordability Affordability of Software-Intensive Systems aims to provide the bestvalue among available solution alternatives within life cycle budget andschedule constraints through reliance on software acquisition,management, and development practices/processes to maximize bothfunctional and quality properties for a technology.

- AFRL Affordability IPTAirlie Council Refers to a group of experts convened by the Navys Software Program

Managers Network (SPMN) in 1995 who established/identified nine bestpractices. These practices have been augmented with other practices since

1995, and in current literature are referenced as the original Airlie bestpractices.Best Practice A documented practice aimed at lowering an identified risk in a system

acquisition and is required or recommended by a bona fide DoD, industry,or academic source.

Methodologies and tools that consistently yield productivity and qualityresults when implemented in a minimum of 10 organizations and 50software projects, and is asserted by those who use it to have beenbeneficial in all or most of the projects.

Closed Interfaces Privately controlled system/subsystem boundary descriptions that are not

disclosed to the public or are unique to a single supplier.CommercialPractices

The techniques, methods, customs, processes, rules, guides, and standardsnormally used by business but either applied differently or not used by theFederal Government (Defense Systems Management College, 1998).

COTS Commercial-Off-The-ShelfDe FactoStandard

A standard that is widely accepted and used, but lacks formal approval bya recognized standards organization (FED-STD-1037C).

F3I Form, Fit & Function, Interface (F3I): As defined in Document EIAStandard IS-649-Draft-1997. Form: The shape, size, dimensions, andother physical measurable parameters that uniquely characterize aproduct. For software, form denotes the language and media. Fit: Theability of a product to interface or interconnect with an integral part ofanother product. Function: The actions that a product is designed toperform. Interface: The performance, functional, and physical attributesrequired to exist at a common boundary.


29/33

FederalSpecifications

These cover materials, products or services used by more than two federalagencies. They are issued by the General Services Administration (GSA)and must be used by all federal agencies. Federal specifications can beobtained at http://apps.fss.gsa.gov/pub/fedspecs/ or from your localProcurement Technical Assistance Center (PTAC).

IEWCS Intelligence ElectronicW

arfare CommonS

ensorInterface The functional and physical characteristics required to exist at a commonboundary or connection between systems or items (DoD 4120.214-M).

InterfaceStandard

A standard that specifies the physical, functional, and operationalrelationships between various elements (hardware and software), topermit interchangeability, interconnection, compatibility and/orcommunications.

Interoperability The ability of systems, units, or forces to provide data, information,materiel, and services to (and accept the same from) other systems, units,or forces, and to use the data, information, materiel, and services soexchanged to enable them to operate effectively together(DoD 5000.1).

IPPD Integrated Product &Process DevelopmentIPT Integrated Product TeamKey Interface An interface for which the preferred implementation uses an open

standard to design the system for affordable change and enhancecommonality and reuse of components.

MAIS MajorAutomated Information SystemsMDAPS MajorDefense Acquisition ProgramsMilitarySpecifications

These cover items or services that are intrinsically military in character, orcommercial items modified to meet special requirements of the military.ASSIST-Quick Search provides direct access to nearly 100,000 full text DoDSpecifications and Standards available in the DoD master repository -ASSIST!

ASSIST-Quick Search does not require an account and password and makesdocuments available to the public free of charge.http://assist.daps.dla.mil/quicksearch/

They are also distributed in hard copy form by Naval Publications andForms Center (NPFC), located in Philadelphia, PA (PHONE (215) 697-3321). NPFC stocks and issues Department of Defense printed and digitalmatter without charge to federal agencies and the general public.Documents distributed by NPFC include military specifications andstandards, federal specifications and standards, Qualified Product Lists(QPLs), Military Handbooks, and Departmental Documents. Here again,many PTACs offer military specifications and standards as a part of theirservices to their clients.

Model A simplification of reality that provides a complete description of asystem.


30/33

Modular Design Characterized by the following:

Functionally partitioned into discrete scalable, reusable modulesconsisting of isolated, self-contained functional elements

Rigorous use of disciplined definition of modular interfaces, toinclude object oriented descriptions of module functionality

Designed for ease of change to achieve technology transparency and,to the extent possible, makes use of commonly used industrystandards for key interfaces

NDI Non-Developmental ItemNGS Non-Government StandardsOpenArchitecture

An architecture that employs open standards for key interfaces within asystem.

Open Source A method and philosophy for software licensing and distribution designed

to encourage use and improvement of software written by volunteers byensuring that anyone can copy the source code and modify it freely. Freemeans free of distribution restrictions, not necessarily free of charge. Seethe Open Source Initiative for further details.

http://www.opensource.org/docs/definition_plain.php

The public release of source code by a commercial organization for othersto use or enhance as they see fit.

Open Standards Standards that are widely used, consensus-based, and published andmaintained by recognized industry standards organizations.

Open Systems Computer systems that provide either interoperability, portability, orfreedom from proprietary standards, depending on your perspective. Foryears, the term was applied loosely to the many flavors of Unix.

Open SystemsApproach (OSA)

An integrated business and technical strategy that employs a modulardesign and, where appropriate, defines key interfaces using widelysupported, consensus-based standards that are published and maintainedby a recognized industry standards organization.

OSCAR Open Systems Core Avionics Replacement ProgramOSJTF Open Systems Joint TaskForcePBBE Performance-Based Business EnvironmentPerformanceSpecification

A performance specification states requirements in terms of the requiredresults with criteria for verifying compliance, but without stating themethods for achieving the required results. A performance specificationdefines the functional requirements for the item, the environment in whichit must operate, and interface and interchangeability characteristics.

PM Program ManagerProprietaryStandard

A standard that is exclusively owned by an individual or organization, theuse of which generally would require a license and/or fee.

PTAC Procurement Technical Assistance Center


31/33

QFD Quality Function DeploymentSCW Software CollaboratorsWorkshopSDOs Standards Developing OrganizationsSLOC Source Lines OfCodeSPMN Software Program Managers Network

Standard A document that establishes engineering and technical requirements forproducts, processes, procedures, practices, and methods that have beendecreed by authority or adopted by consensus (EIA-632, Annex A).

SystemsEngineering (SE)

The interdisciplinary approach governing the total technical andmanagerial effort required to transform a set of customer needs,expectations, and constraints into a product solution, and support thatsolution throughout the products life.

TDP Technical Data PackageTOC Total Ownership Costs


32/33


33/33

handle on high-level performance requirements. They determined that it was not feasible toachieve precise requirements traceability. They achieved a significant software developmentaffordability improvement (defined in terms of labor hours/source lines of code (SLOC))attributable to reuse, COTS tools, change containment, desktop testing, and use of high orderlanguage.

- [Logan, 2000]