Software Lifecycle and Components

Researchers and engineers involved in software for earth, ecological, and life science will convene to assess the critical relationship between software and environmental science issues that are important to society.

Dates: August 13-14, 2013.
Venue: National Center for Ecological Analysis and Synthesis (NCEAS), UCSB (Directions to NCEAS)
Co-chairs: Matt Jones, Chris Mattmann, Peter Fox, Mark Schildhauer.


Software Lifecycle. The operations of ISEES must encompass all stages of the software lifecycle to successfully serve the broad environmental science community.  Software systems used today vary in their maturity, interoperability, generality, and usability, making it difficult to assess how these might be better enhanced, integrated, used, and sustained.  For example, much code that is used for modeling and analysis in environmental science is produced in individual academic labs, often by lone graduate students with little or no training in software engineering or design.  The advances in algorithms and science that they make might be highly useful to other researchers, but the software itself is not yet mature enough to be reused broadly within and across disciplines, or it might be inefficient, or even produce erroneous output.  In contrast, larger open source products arising from investments in cyberinfrastructure might be fully mature, vetted, and reusable, but have difficulty with long-term maintenance and community support due to a lack of resources.  Thus, different products can be placed along different phases of a software development lifecycle. We envision that ISEES will fully develop a software lifecycle model that can be used to help the community identify relevant software, mature it into useful products that can be used to revolutionize science, and support and sustain that software to maximize its utility to the science community. Part of this lifecycle model would include an integration strategy and framework that provides mechanisms for semantic interoperability among software elements that evolve independently (e.g., the use of semantics in workflow systems to enable modular extension and interoperability among components).

Software Components. To fulfill its mission, ISEES will need to support valuable software components that are critical to earth and environmental science. An enormous variety of software is used in environmental science; any viable catalog would easily list thousands of packages, including: 1) general purpose computing frameworks that support a wide variety of disciplines through modular extension mechanisms (e.g., R, Matlab, Kepler, VisTrails); 2) middleware components that expose and facilitate use of cyberinfrastructure resources (e.g., grid managers like Condor); 3) desktop analysis and visualization tools (e.g., ArcGIS, HydroDesktop); 4) domain-specific models and components that encode specific simulations, experiments, and models (e.g., Ecosim, Maxent, NCAR Community Climate System Model); 5) data management, storage, and manipulation tools (e.g., GridFTP, postgreSQL, GeoNetwork); and, 6) Software as a Service (e.g., Web Coverage Service, Sensor Observation Service). ISEES will optimize use of resources by empowering the science community to drive the selection of software elements for inclusion in various software lifecycle activities such as testing and verification, integration, or support. One potential approach would be to use community-nominated environmental science challenge foci to drive the investment of ISEES resources to produce software to accelerate the solution of that problem, and iterate over many of these science challenges each year.  An alternative approach might be to solicit proposals from the community for support for development, maturation, and maintenance of particular software components and frameworks, and then support these groups through a combination of community hackathons, agile development sprints, and support services.