Adaptation of the Agile Scrum Methodology for the Implementation of Multi-Mission Relay Coordination Software
No abstract available
SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
No abstract available
Jet Propulsion Laboratory uses multi-mission software produced by the Mission Planning and Sequencing (MPS) team to process, simulate, translate, and package the commands that are sent to a spacecraft. MPS works under the auspices of the Multi-Mission Ground Systems and Services (MGSS). This software consists of nineteen applications that are in maintenance. The MPS software is classified as either class B (mission critical) or class C (mission important). The scheduling of tasks is difficult because mission needs must be addressed prior to performing any other tasks and those needs often spring up unexpectedly. Keeping track of the tasks that everyone is working on is also difficult because each person is working on a different software component. Recently the group adopted the Scrum methodology for planning and scheduling tasks. Scrum is one of the newer methodologies typically used in agile development. In the Scrum development environment, teams pick their tasks that are to be completed within a sprint based on priority. The team specifies the sprint length usually a month or less. Scrum is typically used for new development of one application. In the Scrum methodology there is a scrum master who is a facilitator who tries to make sure that everything moves smoothly, a product owner who represents the user(s) of the software and the team. MPS is not the traditional environment for the Scrum methodology. MPS has many software applications in maintenance, team members who are working on disparate applications, many users, and is interruptible based on mission needs, issues and requirements. In order to use scrum, the methodology needed adaptation to MPS. Scrum was chosen because it is adaptable. This paper is about the development of the process for using scrum, a new development methodology, with a team that works on disparate interruptible tasks on multiple software applications.
A collaborative software development approach is described. The software product is an adaptation of proven computational capabilities combined with new capabilities to form the Agency's next generation aerothermodynamic and aerodynamic analysis and design tools. To efficiently produce a cohesive, robust, and extensible software suite, the approach uses agile software development techniques; specifically, project retrospectives, the Scrum status meeting format, and a subset of Extreme Programming's coding practices are employed. Examples are provided which demonstrate the substantial benefits derived from employing these practices. Also included is a discussion of issues encountered when porting legacy Fortran 77 code to Fortran 95 and a Fortran 95 coding standard.
A collaborative approach to software development is described. The approach employs the agile development techniques: project retrospectives, Scrum status meetings, and elements of Extreme Programming to efficiently develop a cohesive and extensible software suite. The software product under development is a fluid dynamics simulator for performing aerodynamic and aerothermodynamic analysis and design. The functionality of the software product is achieved both through the merging, with substantial rewrite, of separate legacy codes and the authorship of new routines. Examples of rapid implementation of new functionality demonstrate the benefits obtained with this agile software development process. The appendix contains a discussion of coding issues encountered while porting legacy Fortran 77 code to Fortran 95, software design principles, and a Fortran 95 coding standard.
It is found that two adaptive parametric functions can be introduced into the basic ocean equations for utilizing the optimal or hybrid features of commonly used z-level, terrain- following, isopycnal, and pressure coordinates in numerical ocean models. The two parametric functions are formulated by combining three techniques: the arbitrary vertical coordinate system of Kasahara (1 974), the Jacobian pressure gradient formulation of Song (1 998), and a newly developed metric factor that permits both compressible (non-Boussinesq) and incompressible (Boussinesq) approximations. Based on the new formulation, an adaptive modeling strategy is proposed and a staggered finite volume method is designed to ensure conservation of important physical properties and numerical accuracy. Implementation of the combined techniques to SCRUM (Song and Haidvogel1994) shows that the adaptive modeling strategy can be applied to any existing ocean model without incurring computational expense or altering the original numerical schemes. Such a generalized coordinate model is expected to benefit diverse ocean modelers for easily choosing optimal vertical structures and sharing modeling resources based on a common model platform. Several representing oceanographic problems with different scales and characteristics, such as coastal canyons, basin-scale circulation, and global ocean circulation, are used to demonstrate the model's capability for multiple applications. New results show that the model is capable of simultaneously resolving both Boussinesq and non-Boussinesq, and both small- and large-scale processes well. This talk will focus on its applications of multiple satellite sensing data in eddy-resolving simulations of Asian Marginal Sea and Kurosio. Attention will be given to how Topex/Poseidon SSH, TRMM SST; and GRACE ocean bottom pressure can be correctly represented in a non- Boussinesq model.
The GMSEC (Goddard Mission Services Evolution Center) Services Suite (GSS) is a collection of tools and software services along with a robust customizable web-based portal that enables the user to capture, monitor, report, and analyze system-wide GMSEC data. Given our plug-and-play architecture and the needs for rapid system development, we opted to follow the Scrum Agile Methodology for software development. Being one of the first few projects to implement the Agile methodology at NASA GSFC, in this presentation we will present our approaches, tools, successes, and challenges in implementing this methodology. The GMSEC architecture provides a scalable, extensible ground and flight system for existing and future missions. GMSEC comes with a robust Application Programming Interface (GMSEC API) and a core set of Java-based GMSEC components that facilitate the development of a GMSEC-based ground system. Over the past few years, we have seen an upbeat in the number of customers who are moving from a native desktop application environment to a web based environment particularly for data monitoring and analysis. We also see a need to provide separation of the business logic from the GUI display for our Java-based components and also to consolidate all the GUI displays into one interface. This combination of separation and consolidation brings immediate value to a GMSEC-based ground system through increased ease of data access via a uniform interface, built-in security measures, centralized configuration management, and ease of feature extensibility.
The Systems Engineering team within the Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has been transforming its development processes to be more efficient, robust,and responsive to change and to its stakeholders. To these ends, the Systems Engineering team trialed the integration of agile development techniques into existing and new processes. Agile development methods are well understood within the software development community. Outside ofsoftware development, however, how non-software project management (PM) and systems engineering (SE) teams implement agile development techniques is less well understood. In its transformation efforts, the ExMC SE team focused on three main areas: Improving the project communications among subsystem teams and stakeholders by adopting a scrum-like process, Changing the status and reporting mechanisms to improve schedule coordination between the subsystem team, SE leadership, and ExMC Element leadership, and Unifying the model-based SE workflow to improve understanding of Concepts of Operations across projects.This presentation highlights several of these transformations and what the SE team learned while undergoing the transformation.