Software Quality and Interoperability Working Group SQ

1
Software Quality and Interoperability Working
Group (SQIWG)

• Second Status Report
• January 6, 2000
• DoD Chair Ron Torezan (OSD C3I)
• Industry Chair Hal Wilson (Litton PRC)
• FECC Sponsor/Mentor John Weiler (ICH)
• www.ICHnet.org

2
Agenda

• Problem Statement in Perspective
• Summary survey results
• Synthesis of All Inputs
• Preliminary Process Recommendations
• Recommended Actions

3
Initial WG Problem Statement

• COTS software quality is still suspect
• Understanding of software product capabilities
  needed
• Interoperability is a critical problem area
• Current architectural initiatives (C4ISR, JTA)
  dont quite fit the E-Business problem space
• Integration with legacy systems offer unique
  challenges
• Rate of Technology Change Exacerbates the Problem
• Haunting Question
• Why does Industry maintain software quality isnt
  as big an issue for them as DoD claims?

4
SQIWG Approach

• Market survey developed
• Vendors, users and integrators present quality
  and interoperability approaches
• Develop conclusions and recommendations
  considering multiple perspectives of participants

5
SQIWG Survey Status

• Industry/Govt. Briefings
• Oct/Nov Dec Scheduled
• SAP AIA Unisys
• GIG Interop. WG LISI SEI
• Interop. Clearing House SPS Oracle
• Microsoft EDS
• OUSD Litton PRC
• Initial set of survey responses
• Some responses combined roles in a consolidated
  response
• 3 industry 4 Government - 3 unspecified
• 7 Developers
• 1 End User
• 4 Integrator/Implementor
• 2 Acquirers

6
SQIWG Preliminary Survey Results

• Respondents definitions of quality
• Meets the expected and gracefully handles the
  unexpected
• Performs as advertised - meets requirements with
  low defects
• Maintainable
• Easy to use
• Performs to requirements
• Respondents rankings of importance when
  procuring COTS

7
Synthesis of All Inputs (to date)

• Clearly understand the functions and implications
  of the current business processes before
  considering products
• Minimize the number of choices (architecture and
  process)
• Get the users involved as early as possible and
  keep them involved
• Encourage user buy-in through determining what
  is in it for the user and emphasizing it from
  the outset
• Deliver promised value to the user first
• Industry makes decisions based upon ROI and value
  received - based trade-offs facilitate most
  decisions
• Standards today have difficulty keeping up with
  technology - choose wisely in areas of immaturity
  and rapid change

8
Conclusions for e-Business

• Product to Process Matching
• is critical to e-Business success

Process Product
Well Defined Functionality Satisfy essential
Functionality Improve Business Process Ease of
use User Value Achieved Meet Statutory Requireme
nts

• Few Product bugs
• Performs stated function
• Easy to use
• Handles the unexpected

Software Quality
e-Business Solutions

• Works with other products
• Exchanges needed information
• Works within the required environments

Interoperability
Recommendations focus on product to process
matching to improve software product quality and
interoperability
9
Preliminary Recommendations

• First understand the business process and its
  hidden costs
• Apply COTS with efficiency / consolidation of
  cost and architectural fit as goals
• Choose among candidate product capabilities based
  upon thorough understanding of features and
  benefits
• Address interoperability through the architecture
  process
• Establish equivalents for ROI Bottom Line for
  DoD to aid decision making make it a standard
  measure for all COTS/ process decisions

10
Next Steps

• Continue Industry and Government presentations to
  SQIWG
• Complete gathering and analyzing surveys and
  presentations
• Continue to isolate root causes of problems
• Refine immediate and long term recommendations
• Verify from each of the four perspectives
• Coordinate with other panels
• Develop key recommendations for DepSecDef Review

11
Backup Material
12
Summary of Government Briefings

• Interoperability
• General
• Standards alone are insufficient
• Need discipline, agreement, data structure, etc.
• Combinatorials create risks
• Multiplicity of products and interfaces
  exacerbates the problem
• Infrastructure variants add to complexity and
  increase risk
• Treat COTS as black box assume that you cant
  change whats inside
• Product Interoperability
• Functionality between product lines good at low
  levels for basic use.
• Advance features and proprietary extensions
  probably not interoperable
• Training
• Teaches the newer process and enables departure
  from older culture
• Must have a resourced and integrated training
  strategy
• Requires leadership and mentoring down to the
  site implementation

13
Summary of Government Briefings (cont.)

• Architecture
• Operational (Business) Architecture is driver.
• Must synchronize IT architectures (operational,
  systems, technical implementation views)
• Develop domain architectures with defined COTS
  products that conform.
• COTS and Business Process Change
• Carefully address the commercial business
  practice in COTS versus Govt
• Must agree on degree of change before COTS is
  chosen
• Managing Expectations
• Buyer and Vendor understanding must be validated
  as consistent
• Early test planning must include verification of
  functionality claimed
• Partner with contractor to understand product
  language structure, database and data use

14
Summary of Industry Briefings

• Industry is driven by bottom line, ROI, and
  competitive edge- a common way to define value of
  change
• This makes their decisions easier than DoD
• Industry is choosing products that are built on a
  component model (e.g., Java, XML)
• Object/Internet paradigm is a means of improving
  interoperability/ adaptability
• Industry is shifting from custom software (COTS)
  development to COTS component integration
• Multiple products are expected to be integrated
• Object technology is used to integrate products
  and processes while still allowing substitution
  as technology progresses (provide transparency)
• Business processes drive IT architectures
• Industry often plans to adapt processes as it
  plans to adopt COTS products
• Reaffirmed need to base a solution on a
  thoroughly understood business model

15
Summary of Industry Briefings (cont.)

• How industry leaders make COTS work
• Separate data from applications
• Drill down data to the lowest level
• Eliminate false expectations by defining required
  functions
• Eliminate false expectations by fully
  investigating COTS product functions and
  implications
• Mandate object oriented implementations that can
  be tailored instead of internally modified
• Baseline as is model then develop to be model
  and application portfolio targets

16
SQIWG Survey Quotations

• Software standardization is very important but
  hard to achieve.
• Standards (software) alone arent enough you
  need discipline in applying the products so that
  you only use functions that are standard. You
  either impose discipline or youll have to invent
  ways to inter-operate in spite of proprietary
  extensions.
• Most deficiencies were due to misunderstandings
  of the written requirements with the expected
  functionality.
• If you don't understand your biz process,
  applying all the software (even high-quality,
  interoperable software) in the world won't make
  it better.
• Module testing is not common Systems Testing
  is.
• The technique that has been very successful is
  having our customers/users involved to a degree
  all the time during the development cycle
• Our problem is dealing with older software that
  does not inter-operate with new software.
• Performance requirements must be detailed enough
  such that if two teams implemented it would
  look the same to the tester/users.