Reuse Working Group

1. Reuse Working Group Co-chairs: Robert Wolfe, NASA GSFC Vic Delnore, NASA LaRC 6th Earth Science Data Systems Working Group Meeting Philadelphia, PA October 23–25, 2007

2. Agenda • Working Group Members • Activities and Accomplishments • Summary of Activities • Recommendations to Headquarters • Reuse Portal Web Site • Architecture Study • Reuse Readiness Levels • Breakout Session Agenda

3. Gary Jackson (University of Maryland) Tommy Jasmin (University of Wisconsin, Space Science Engineering Center) James Marshall (Innovim / NASA GSFC) David McComas (NASA GSFC) Steve Olding (Everware–CBDI / NASA GSFC) Shahin Samadi (Innovim / NASA GSFC) Mark Sherman (SGT Inc. / NASA GSFC) Maciek Smuga-Otto (University of Wisconsin, Space Science Engineering Center) Ross Swick (NSIDC – Boulder) Bill Teng (SSAI / NASA GSFC) Curt Tilmes (NASA GSFC) Frederick Watson (California State University, Monterey Bay) Jonathan Wilmot (NASA GSFC) Robert Wolfe (NASA GSFC) Members 2007 / Mailing List • Nadine Alameh (MobiLaps / NASA GSFC) • Stephen Berrick (NASA GSFC) • Angelo Bertolli (Innovim / NASA GSFC) • Howard Burrows (AUSI/NSDL) • Nancy Casey (SSAI / NASA GSFC) • Bradford Castalia (University of Arizona) • Victor Delnore (NASA LaRC) • Robert Downs (CIESIN, Columbia University) • Yonsook Enloe (SGT Inc. / NASA GSFC) • Stephan Falke (Washington University in St. Louis) • Mike Folk (National Center for Supercomputing Applications) • Neil Gerard (Innovim / NASA GSFC) • Ryan Gerard (Innovim / NASA GSFC) • Emily Greene (Raytheon / NASA JPL) • Mary Hunter (Innovim / NASA GSFC) 29 Members on the Mailing List

4. Major Accomplishments • Software Reuse Enablement System (RES) • Completed architecture study • Preparing presentation of architecture study and recommendations to NASA HQ • Began developing prototype RES for internal NASA use • Procured system • Developed schedule/plan • Completed Build 1 and Build 2 • Software Reuse Portal Web Site • Moved site to new host; application software upgraded during move • Added bottom-up reuse guidelines, technology transfer guideline, definitions of reuse, and recent publications • Worked with Metrics WG to upgrade to NetInsight for site statistics • Recreated collaboration web site under newest version of Microsoft SharePoint • Began discussion of Reuse Readiness Levels (RRLs) • Continued weekly support team telecons and monthly WG telecons

5. 2007 Goals Met • Reuse Enablement System: completed architecture study; began development of prototype system • Reuse portal: provided more content and kept up to date; promoted portal to community • Metrics/measurement: generated/analyzed statistics for portal web site activity • Promote reuse: continued publishing and presenting work; will hold special session at AGU fall meeting; developing Reuse Readiness Levels • Incentives: created peer-recognition award policies and rationale

6. Publications and Conferences • 5th ESDS WG Meeting • 2 posters • 6 breakout talks • Abstracts and poster presentations • 2006 Fall AGU Meeting • 2007 GSA Annual Meeting • 2007 Fall AGU Meeting • Papers and oral presentations • 2007 IEEE Aerospace Conference • 2007 IEEE Information Reuse and Integration conference • Special sessions • 2007 Summer ESIP meeting • 2007 Fall AGU Meeting

7. Recommendations to Headquarters

8. Recommendations to HQ • Enabling Systems Recommendations • NASA should establish a web-based system to facilitate cataloging and a web-based repository system for distributing reusable assets for the Earth science community. • Architecture study completed and submitted to HQ. • NASA should establish a web-based information portal for the sharing and dissemination of information about software reuse practices for the Earth science community. • Software Reuse portal web site has been established; actively updated and maintained. • Reuse Incentives • NASA should recognize and officially support a Peer-Recognition Software Reuse Award operated by the Reuse WG. • Award process is being reviewed by Kathy Fontaine before the recommendation is forwarded to HQ.

9. Software Reuse Portal Web Site

10. Portal Web Site Content Status http://www.esdswg.org/softwarereuse • Home/News • Latest news and information • Upcoming events • Links to important/new items (new) • Reusable Assets • Links to various catalogs (e.g., GCMD, GSFC open source site) • Open Source • Funding Opportunities • Information about funding opportunities for reuse • Resources (overall) • Some specific resources are shown in the next column. • Suggest Content • Books/Articles • Events and Highlights • Featured Projects/Tech. • Groups (new) • Guidelines (new) • Library • TRLs • Tools

11. Architecture Study Summary

12. Architecture Study Background • Enabling Systems Recommendations • NASA should establish a system to facilitate the cataloging and distribution of reusable assets for the Earth science community. • NASA Headquarters tasked the Working Group to look at the roles of the GCMD, Open Source Agreement site, and other sites in serving the community and meeting reuse needs. • Ensure that there are no existing systems that already fulfill the role proposed by the reuse working group for a reuse enablement system. • A trade study was conducted for this purpose. • The trade study concluded that none of the existing operational sites fulfilled the role of a software repository for the Earth science community. • An architecture study was conducted by the Working Group to determine the most suitable way to create the recommended reuse catalog/repository.

13. Requirements Satisfaction • 18 Requirements Satisfied (75%-100%) • 18 Requirements Partially Satisfied (35%-75%) • 10 Requirements Not Satisfied (0%-35%) • 26 Requirements Satisfied (75%-100%) • 14 Requirements Partially Satisfied (35%-75%) • 6 Requirements Not Satisfied (0%-35%)

14. Technical Evaluations It is important to note that (lack of) satisfaction with the requirements does not necessarily correspond to (not) meeting the requirements. See Section 7 of the Reuse Enablement System (RES) Architecture Study document for additional information.

15. Architecture Study Conclusions • XOOPS meets more and fails fewer of our requirements than Savane • XOOPS meets 40, fails 9; Savane meets 24, fails 20 • XOOPS has a significantly lower estimated development time • About 8 months for XOOPS compared to about 34 months for Savane • XOOPS uses modules to provide functionality for the system, and each module is a self-contained component. • This makes it easier to modify XOOPS. • The estimated effort for modifying the GCMD is similar to Savane, based on the requirements met. However, • modifications would have to go through the existing GCMD team, and • adding capabilities to support a reuse enablement system is not currently a goal of the GCMD project. • Since XOOPS requires the least amount of development, this open source content management system should be used to create a prototype RES for internal NASA use.

16. Reuse Readiness Levels (RRLs)

17. Introduction to RRLs • Issue of how to measure the maturity of software, in a reusability sense, was discussed at last year’s meeting. • Having a measure of the reusability of an asset: • Provides potential reusers with additional information about the reuse maturity of the asset • Lets them know what they’re getting • Gives them a basic feel for what modifications may be needed • Helps potential reusers make better informed choices about: • What to reuse • What best meets their needs • This measure can be used as a piece of metadata for assets placed in the RES (or anywhere else). • Volunteers from WG wrote up levels for particular topic areas within software reuse. • These topic levels will be combined into a single scale.

18. Topic areas included: Portability Extensibility Documentation Support Packaging Licensing Standards compliance Verification/Testing Modularity A scale of 1–9 was used to match the Technology Readiness Levels (TRLs) scale. Currently working on combining topic levels into a single RRL scale. Example from Testing/Verification RRL 4 – Software application testedand validated in laboratory environment Following successful testing of inputs and outputs, the testing would include integrating an application to establish that the “pieces” will work together to achieve concept-enabling levels. This validation must be devised to support the concept that was formulated earlier and should also be consistent with the requirements of potential system applications. The validation is relatively “low-fidelity” compared to the eventual system: it could be composed of ad hoc discrete components in a laboratory; for example, an application tested with simulated inputs. RRL Topic Areas and Levels

19. Reuse Breakout Sessions

20. Meeting Agenda

21. Reuse Breakout Agenda • Day 1 • Introduction/Summary [Robert / Vic] • Reuse Readiness Level (RRL) discussion [All] • Invited speaker: Michael Leyton, Rutgers University • A Generative Theory of Shape / A Mathematical Theory of Reusability • Day 2 • Joint WG breakout [All] • Demonstration of prototype Reuse Enablement System [Neil/Jim] • Poster on Reuse Readiness Levels (RRLs) [All] • Day 3 • Joint breakout on RRLs with Technology Infusion WG [All] • Feedback on RES prototype demonstration and RRLs [All] • Elections for WG chairs [All] • Planning for 2008 and creating report-back [All] • Report-back [Robert/Vic or new chair(s)]

22. Backup Slides

23. Publications and Conferences • 2 posters and 6 breakout talks at 5th ESDS WG Meeting • 1 abstract published from 2006 Fall AGU Meeting • 1 paper published from 2007 IEEE Aerospace Conference • Held a session at the 2007 Summer ESIP meeting • 1 paper published from 2007 IEEE Information Reuse and Integration conference • 1 poster accepted for the 2007 GSA Annual Meeting • Will hold software reuse special session at 2007 Fall AGU Meeting • Session has 5 abstracts • 1 abstract in the session by the general WG

24. Software Reuse Portal Web Sitehttp://www.esdswg.org/softwarereuse • Software Reuse portal goals: • Raise awareness of software reuse within the Earth science community • Establish a platform for community members to share/exchange resources with each other • Publish reuse information relevant to the community • Enable access to reuse resources • Serve as an easy starting point to create NASA web sites Web search results for software reuse: 1st on Yahoo (old URL) 3rd and 5th on MSN (old and new URLs) 8th on Google (old URL)

25. About the Reuse Portal • Uses Plone (with Zope) • Open source content management system running on Linux • Update content using a simple browser-based interface • Follows NASA Portal Affinity • Consistent NASA look and feel • External service provider hosts Reuse, Tech. Infusion, and SPG portals on one instance. Site content management using Plone Zope Administrator/ Management GUI - easy interface for reusing and maintaining portals

26. Reuse Enablement System Requirements 1. Users and User Information 1.1. Support of User Types 1.1.1. Consumer 1.1.2. Provider 1.1.3. Administrator 1.1.4. Content Manager 1.2. User Information Storage 1.2.1. Common User Information 1.2.2. Provider Information 1.3. User Interface 1.3.1. Profile Management 1.3.2. Request Account Deletion 2. Asset Storage and Management 2.1. Asset Information Storage 2.1.1. Asset Information 2.1.2. Asset Resources 2.1.3. Asset Versions 2.1.4. Asset Uploads 2.2. Asset Discovery 2.2.1. Alphabetic Listing 2.2.2. Search 2.2.3. Hierarchical Navigation 2.3. Asset Management 2.3.1. Register New Asset 2.3.2. Modify Asset 2.3.3. Approve Asset 2.3.4. Remove/Delete Asset 2.3.5. Categorize Asset 2. Asset Storage and Management (continued) 2.4. Feedback 2.4.1. Collect Comments 2.4.2. Collect Quantitative Feedback 2.4.3. User Registration of Asset Usage 2.4.4. Provider Contact 2.4.5. Display Feedback 2.5. Metrics 2.5.1. Downloads 2.5.2. Links 2.5.3. Registered Users 2.5.4. Rating Summary 3. Notifications 3.1. Send Notifications for Assets 3.1.1. Notify on Modification 3.1.2. Notify on Feedback 3.2. Notification for System Events 3.2.1. Asset Information 3.2.2. System Information 3.3. Notification Management 3.3.1. Add Notifications 3.3.2. Remove Notifications 4. System Operations 4.1. Feedback 4.1.1. System Problems 4.1.2. System Suggestions 4.1.3. Administrator Contact 4.2. Policy Compliant 4.2.1. Verify Provider Info. 4.2.2. Verify Provider by Contact 4.2.3. Security, Transmitted Info 4.2.4. Security, Stored Info 4.2.5. Deletion of Users 4.2.6. Protect Private Info 4.2.7. Technical and Other 4.2.8. Policy Availability 4.3. Repository and Catalog 4.3.1. Function as Repository 4.3.2. Function as Catalog 4.3.3. Provider Selects Behavior 4.3.4. Asset Storage Limit 4.4. Asset Cleanup 4.4.1. Deprecation by Content Managers 4.4.2. Removal by Administrators 4.5. Data Integrity 4.5.1. Verification of Data by Providers Formalized Requirements