SEEDS Reuse Study

1
SEEDS Reuse Study

• Software Reuse FrameworkStructure and Content
  Recommendations
• Draft

2
Overview

• Purpose
• Prepare for SEEDS working group efforts to enable
  and incentivize software reuse
• Define a framework of supporting mechanisms for
  software reuse
• Broaden the investigation of reference
  architectures to consider other factors important
  to software reuse
• Contents
• Reuse study goals and objectives (summary)
• Community input and study recommendations
  (summary)
• Candidate elements of a reuse framework
• Implementation concepts for selected framework
  elements
• Next steps

3
Overall Goals Objectives

• SEEDS Goals Objectives
• Reduce the cost of supporting future missions,
  science, applications
• Reduce the effort needed for data systems
  developers to build ESE data systems
• Increase the ability to acquire needed systems
  and services from small, established, efficient
  teams of experts
• Ensure effective competition in the acquisition
  of needed systems and services
• Eliminate unnecessary redundant development
  maintenance efforts
• Increase flexibility responsiveness to future
  missions, science, applications
• Reduce the effort needed for data systems
  maintainers to incorporate proven components and
  enhancements that meet end user needs
• Enable needed capabilities to be acquired quickly
  in incremental chunks
• Increase effective accountable community
  participation
• Reduce the effort needed for science and
  application teams to offer ESE data services
• Increase common understanding of the
  responsibilities associated with providing a
  given capability or service
• SEEDS Reuse Goal
• Enable reuse of existing ESE software assets to
  achieve SEEDS goals

4
Review of Community Recommendations

• Reuse
• ESE should work to enable software reuse
• Use improved clone own approach for mission
  critical systems
• Use open source software approach for mission
  success systems
• ESE should not pursue product line approach
• Unlikely to realize theoretical benefits across a
  large and diverse enterprise like ESE
• Reference Architecture
• ESE should develop reference architecture to help
  enable reuse
• Coarse-grained (subsystem level, not software
  module level)
• Notional (high-level descriptions not specific
  service details)
• Concrete details in a limited set of functional
  areas
• ESE should not develop a fine-grained, specific
  reference architecture
• Unlikely to realize theoretical benefits to
  component-level reuse and software
  interoperability
• Too costly to develop and too constraining for
  use by the science community

Source SEEDS Formulation Team Draft
Recommendations Report, Section 6 Reuse and
Reference Architectures
5
Reuse Framework Overview

• What is a reuse framework?
• A structure for organizing the elements of a
  software reuse initiative
• A place to share information and tools that can
  be used to enable software reuse
• An evolving set of content related to software
  reuse
• Why a reuse framework?
• Expands original concept of using a reference
  architecture to enable reuse
• Adds other critical enabling mechanisms
• Organizes the material from various SEEDS reuse
  activities so they can be shared effectively for
  use across the ESE community

6
Context Keeping a Reuse Framework in Perspective

• A reuse framework could be the primary output of
  the reuse support/enablement activity
• The reuse working groups (not the SEEDS program
  office) are responsible for developing and
  populating the reuse framework

7
Community Perspective Many Barriers to Software
Reuse

• Policy, Process, and Cultural Issues
• Intellectual property policies restrict code
  sharing
• Policy/cultural restrictions against open source
  development
• Contractual restrictions on access to vendors
  source code
• NIH tendencies
• Cultural emphasis on invention over reuse
• Organizational biases to use certain software
• Cumbersome code release processes
• Knowledge Skill Issues
• Lack of knowledge about existing/available
  software
• Lack of needed skills to understand/incorporate
  existing assets
• Mismatch of programming language with team
  skills/preferences
• Lack of experience with reuse in a development
  team
• Technical Issues
• Poor fit of an existing subsystem with the
  intended application
• Lack of modularity
• Unwillingness to accept some product limitations
• Inconsistent coding and documentation conventions
• Lack of test cases

• Tool Infrastructure Issues
• No asset repository
• No reuse infrastructure
• Lack of a forum for advertising/marketing
  components
• Lack of contributions to an asset base
• Funding and Resource Alignment Issues
• Mission-oriented funding not conducive to
  investing effort needed to make software reusable
• Lack of funds or desire to document and support
  assets
• Lack of access to experts familiar with an asset
• No schedule/funds/policy requirement to make
  contributions to an asset base
• Risk Uncertainty Issues
• Perceived technical risk
• Inability to assume some risk in development
• Liability concerns
• Security concerns
• Uncertainty in payoff of reusability investment
• Hesitation to share because SW was not
  designed/documented to be shared

Source SEEDS Public Workshops Note all these
barriers can be addressed by a reuse framework or
framework contents.
8
Project Perspective Reuse Decisions Require
Practical Information

• Developers and program managers need pragmatic
  answers when making reuse decisions
• What types of subsystems are needed?
• What is available?
• Which are relevant to my class/scale of data
  system?
• Which ones fit together?
• Which are easily reused/adapted?
• Which are best supported?

9
Reuse Framework Elements Deriving Needs by
Addressing Barriers Questions

• What should a reuse framework contain?

10
Reuse Framework Elements Deriving Needs by
Addressing Barriers Questions (contd)

• What should a reuse framework contain?

11
Reuse Framework Elements Deriving Needs by Reuse
Lifecycle Phase

• Build ensure reusability of new assets
• Reusability guidelines recommendations
• Reference architectures
• Harvest identify reusable assets
• Reusability assessment tools
• Security assessment tools
• Asset catalog (store)
• Reuse employ reusable assets
• Asset catalog (search/browse)
• Developer contacts and forums

12
Candidate Reuse Framework Elements (Summary)

• Reusable assets
• ESE asset catalog (code, test cases, development
  artifacts)
• Links to other catalogs repositories
• Document templates samples
• Reuse support tools
• Reusability security assessment tools
• Component cataloging tools (for federated
  catalogs)
• Software porting tools
• Open/community source foundry
• Reference library
• Reference architectures arch. patterns
• Reference policies (data rights SW licensing)
• Consensus functional requirements
• Reusability guidelines recommendations
• Quality metrics
• Best practices lessons-learned
• Developer contacts forums
• Coding/framework conventions/templates
• News information

SEEDS Reuse Initiatives (Process)
Reusable Assets
Asset Catalog
Reference Library Tool Catalog
Reuse Incentive List
Contacts
Reference Information
Reuse Support Tools
Reference Architecture
Reference Policies
Reference Licenses
The reuse framework provides a structure for
capturing and sharing the results of SEEDS reuse
initiatives.
13
Candidate Reuse Framework Elements Notional Web
Presentation

• Reuse enablement relies on sharing information
• A reuse framework can be partially represented as
  an information sharing portal

14
Candidate Reuse Framework Elements

• Implementation Concepts forSelected Candidate
  Reuse Framework Elements

15
Candidate Reuse Framework ElementsReusable
Asset Catalog/Repository

• Description
• Catalog of reusable software assets
• Includes asset repository only as needed to
  ensure access
• Identifies asset owner, capabilities,
  characteristics, type, contact person, systems
  where used, etc.
• Rationale
• Helps developers find reusable assets
• Candidate catalog items
• Subsystem-level software components
• Reusable software development artifacts
• Reusable templates

16
Candidate Reuse Framework ElementsReuse Support
Tools Open Source Foundry

• Description
• Provides a set of Web-based services to support
  open source or community source development
• Supports individual projects and collections of
  projects
• Services include software dissemination, software
  configuration management, bug reporting, task
  management, etc.
• Rationale
• ESE community does not currently have a focal
  point for open source development
• OSS foundries encourage software to be developed
  as open source, not just licensed as open source
• Availability of an OSS foundry can make an open
  source approach more attractive to developers
• Candidate foundry software
• SourceForge

17
Candidate Reuse Framework Elements Reference
Library Data Rights Guidance

• Description
• Provides guidance for those writing contracts and
  grants to ensure that appropriate data rights are
  included to enable reuse
• Rationale
• Current contract and language doesnt generally
  preclude reuse, but also doesnt best ensure that
  reuse is enabled
• Candidate targets for specific data rights
• Critical infrastructure software data rights
• Appropriate for mission-critical software
  including flight segment through L0
• Community resource software data rights
• Appropriate for mission-success software
  including L1-L4 data product generation
• Commercial potential software data rights
• Appropriate for components best reused through
  commercial distribution

18
Candidate Reuse Framework Elements Reference
Library Architecture Patterns

• Description
• A small number (less than 10) of generic, ESE
  domain-specific architectures that capture the
  essential architectural characteristics of the
  variety of systems used by data service providers
• Identifies applicable environment and solution
  characteristics, including functional components
  (at the subsystem level), services provided, and
  unique architectural features
• Developed and evolved through relatively informal
  processes since they are not controlled or used
  like enterprise architectures
• Rationale
• Patterns can be reused
• Provide proven design solutions for problems in
  different contexts
• High benefit/cost ratio relative to code reuse
• Patterns can be used to classify or identify
  reusable components
• Provide proven implementations matching a given
  design pattern
• Helps developers find components that fit their
  needs
• Promotes reusability for newly developed software
• Candidate patterns
• One for each class of data service provider
  identified by the Levels of Service study
• One for each community mission-critical
  (production emphasis) and mission success
  (analysis emphasis)

Reusable Subsystem Catalog/Library
Pattern Catalog/Library
Context

• Pattern P1
• Examples
• S1, S3

Problem
S1
19
Candidate Reuse Framework Elements Reference
Library Architecture Patterns (contd)

• Architecture patterns should include multiple
  views of the architecture
• A high-level definition of components and data
  flows
• A list of categorized system services

The Producer establishes a Submission Agreement
with the OAIS, which identifies the SIPs to be
submitted and may span any length of time for
this submission.
20
Candidate Reuse Framework Elements Reference
Library Architecture Patterns (contd)

• Example Pattern Publish Subscribe
• Applicability/Context
• A component uses data provided by another
  component
• Information consumer components are not known
  ahead of time
• The number of data consumers is relatively small
• Problem
• Need a way to restore consistency when data are
  changed
• Solution
• Allow components to subscribe to changes in the
  data source (publisher)
• When changes are made, the publisher propagates
  them to the subscriber
• Structure
• Publisher ?(data)? Subscriber(s)
• Implementation guidelines
• Subscriptions should be stored in a linked list
• Variants
• Gatekeeper separate process handles
  notifications and data distribution
• Event channel events are published to a topical
  channel which others can subscribe to
• Known Uses
• News service subscriptions

ESE architecture patterns might be similar in
structure but higher level and more comprehensive
21
Next Steps
22
Next Steps

• Determine if a software reuse framework is needed
  to help enable software reuse within NASAs ESE
• Identify the most important elements of the
  framework
• Establish and begin populating the framework