Leaning Military

1
Leaning Military

• Software Acquisition

Joan L. Stredler
Rohit P.
Sheth stredlerj_at_prodigy.net
rohit.p.sheth_at_boeing.com 562 805-3261
562 593-1327
2
Overview

• Paradigms
• New processes
• New Tools

3
Background

• US military is seeking equivalency to the civil
  standards, particularly DO-178B, in order to
  gain access to civil airspace during peacetime
  operation

U.S. MILITARY

• The international civil aviation community is
  increasing requirements for accuracy, continuity
  and containment in CNS equipment

4
Lean Global Enterprise
Process
Moving Line
World-class, large-scale system
integration Customer preferred options and
shorter order to delivery flow time Fewer and
simpler assemblies that go together easier and
faster
Engineering, production and supplier management
aligned and globalized

• Safety
• Quality
• Cycle Time
• Unit Cost
• Assets

Engine Assembly
Fewer and simpler parts and assemblies
Bulkhead Assembly
5
Paradigm Differences

• Cost
• Responsibility Differences
• Military Standards versus Commercial
• Safety Analysis
• COTS, MOTS and GFE

6
Cost Paradigms
Cost Ratio 1 15-30 Commercial vs. Military
7
Responsibility Paradigms

• Military
• Deliberately changing hierarchy
• No say in who works a program at the developers
  site
• Many layers of oversight
• No defined software acquisition process

• Commercial
• More consistent distributed network
• Concurrence with delegated
• responsibility
• Process defined by the Job Aide

8
Greatest Opportunity for Improvement

• Eliminate Multiple Levels of oversight

• Give up the right to interpret the standard
  independently (Go with FAAs interpretation or
  equivalent level of safety )

• Adopt the Job Aide process

9
Standards Paradigm

• Military Standards
• Issued once
• High cost of maintenance
• Interpreted widely
• Replaced constantly
• No incentive to develop tools

10
Standards Paradigm

• DO-178B
• Mature Guidance
• Wide Acceptance

• Constant training available
• Constant refinement of interpretation

• Supporting Tools
• Practical approach
• Increasing levels of rigor

11
Greatest Opportunity for Improvement

• Use FAAs standard
• FAAs interpretation or equivalent level of
  safety agreeable to the FAA
• Great Cost and Schedule Benefit to use Commercial
  Methods and Tools

12
Safety Analysis

• Commercial
• Top-down

• Military
• Bottom-up

• Impact on software

• Must consider the Full Worst Case Airplane FHA
  case

13
COTS, MOTS and GFE
Military
Much confusion Procurement differences Quality differences Oversight differences
Commercial
TSO System attempts to streamline COTS means truly COTS (like operating systems) Changes always handled the same Oversight the same

• Benefit
• Fosters realignment with definitions and
  commercial standards

14
New Methods and Tools
Where are we NOW?
HOW do we do this?
Where do we want to BE?

• Delegate Authority
• Gap Analysis
• Change Impact Analysis
• Software Tools
• Can be part of a certification project
• Perform the required analyses
• Help improve costs over time

WHAT do we need to do to get there?
15
Lean Opportunities for the Military

• Develop a Designee System

• Adopt selected/mature commercial processes

• Look to available tools

16
Develop a Designee System

• Military/Developer Agree on Designees

• Full understanding of their training

• Cooperation among designees
• Designee oversight of development

17
This Can Work!

• Use DERs
• DERs have the knowledge andexperience to assist
  these programs
• They understand what equivalence is and how to
  develop the technical arguments supporting
  equivalence
• They can determine what will work and what will
  not

The independent role promotes the credibility of
the entire process
18
Benefits of Designee System

• Eliminate individual interpretation/subjective
  decisions/emphasis on format vs contents
• Eliminate layers of military oversight
• SPO software expert/frequent, unstructured
  reviews
• DCMA/format oriented reviews/weak on process
• User software expert/trained to objectively
  resolve process issues

19
Important Reuse Processes

• Gap Analysis

• Change Plan

• Change Impact Analysis

20
Gap Analysis Benefits

• Helps create uniformity
• Compare Military Standard implementation to
  guidance of DO-178B
• May reveal safety risks
• Provides evaluation information for deciding
  where to apply resources
• Provides context for using alternate means of
  compliance (e.g. Service history, software
  methodology,

• safety assurance)

21
Gap Analysis Method

• Analysis and evaluation of the artifacts that
  represent the proposed reused code

• Documentation of the data and findings
• Realistic proposal for eliminating the gap

22
Gap Analysis Results

• Data that allows comparison across software
• systems that can
• Reveal risks

• Aid in evaluating suppliers
• Form the basis for improving intended
  functionality and safety

23
Change Impact Analysis Benefits

• Innovative way to evaluate changes
• Major or minor change
• Checklist to ensure all factors are considered

• Consistent basis for determining extent of
  regression testing (through

CIA/software traceability)
24
Change Impact Analysis Method

• Develop template
• Utilize FAA report on CIA (Rierson)
• Develop checklist

25
Change Impact Analysis Process
26
Change Impact Analysis Results

• Uniform method for regression testsuite analysis
• Developer acceptance-enhancement
• Consistency, repeatability

27
Project Planning Documents

• DO-178B

28
Improvement Opportunity

• PSAC
• A plan that tailors the organizational process to
  the specific project

• SDP, SCMP, SVP and SQAP
• Written one time for the organization level and
  updated with continuous process improvements
• Supportive of organizational deployment of
  process
• Used in proposals and audits easily

29
Accept What You Cannot Change
Congress funds military programs in
incrementally, forcing completion of an upgrade
of an existing aircraft into multiple phases

• The work package identified via the gap
  analysis/change impact analysis may need to be
  implemented over several update programs
• The DER assessments are fairly independent of
  the program and contract constraints and
  decisions

30
Summary

• Many Benefits
• New Tools
• New Processes
• Gap Analysis
• Job Aide
• PSAC
• Change Impact Analysis
• Challenge Is Implementation
• Can be LEAN only if done right using sound
  methodology and process guidance

31
Questions?

32

• Perform Change Impact Analysis
• Following components of the change impact
  analysis must be addressed. These items must be
• addressed by the change impact analysis, as
  applicable. The items listed below are related
  to the
• overall safety and performance characteristics of
  the system
•  
• Traceability analysis. The requirements
  traceability matrix (RTM) must be used to
  determine the
• impact of change on the software project. It
  helps to identify the requirements, design
  elements, code,
• and test cases and procedures that may be
  either directly or indirectly affected by the
  change.
• (2) Memory margin analysis. It must be performed
  to assure that the memory allocation requirements
  
• are not altered, the original memory map is
  maintained, and adequate memory margins are
  maintained.
• (3) Timing margin analysis. It must be used to
  assure that the original timing requirements,
  central
• processing unit (CPU) task scheduling
  requirements, system resource contention
  characteristics, and
• interface timing requirements are met and
  that adequate timing margins are maintained.
• (4) Data flow analysis. It comprises analysis of
  each variable and interface affected by the
  change to
• assure that the original initialization of
  that variable is still valid, that the change was
  made
• consistently, and that the change does not
  affect any other usage of that data element.
• (5) Control flow analysis. To identify any
  adverse effects due to changes to the control
  flow and
• coupling of components, the control flow
  must be assessed with respect to task scheduling,
  
• execution flow, prioritization, and
  interrupt structure, etc.

33
(No Transcript)