Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “agile software development”

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.

At least 37 records · Page 2

Collaborative Software Development in Support of Fast Adaptive AeroSpace Tools (FAAST)

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.

Kleb, William L.↗

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗

Approaches for Synthesis and Deployment of Controller Models on Automated Vehicles for Car-following in Mixed Autonomy

This paper describes the software design patterns and vehicle interfaces that were employed to transition vehicle controllers from simulation environments to open-road field experiments. The approach relies on a life cycle that utilizes model-based design and code generation, along with agile software development, and both software and hardware-in-the-loop testing, with additional safety margins. Autonomous designs should consider the dynamics of mixed autonomy in traffic to safely operate among humans. The software that provides a vehicle’s behavior intelligence is often developed through simulation, which may have a mismatch between dynamics, or as a result of a reinforcement learning workflow, which may be a black box with challenges to analyze. In each of these cases, it is important to have research interfaces that provide strongly typed data streams accessible to researchers who are not software experts while continuing to satisfy safety and liveness constraints. This paper describes how we design the hardware platform interfaces and software design process for a mixed autonomy traffic experiment with a leader-follower scenario. Controller synthesis for these vehicles requires clearly articulated vehicle interfaces and software design patterns for successful onboard deployment. Testing strategies for such controllers are also described before algorithms are transitioned to full-scale field experiments with safety operators for the vehicles. Testing strategies include software-in-the-loop simulation testing, hardware-in-the-loop simulation, ghost-car testing, and read-only testing in live traffic. With our approach, we were not only able to validate our controller synthesized in scripts and simulation, but also able to scale deployment to multiple vehicles.

Bhadani, Rahul↗

Agile Acceleration of LLVM Flang Support for Fortran 2018 Parallel Programming

The LLVM Flang compiler ("Flang") is currently Fortran 95 compliant, and the frontend can parse Fortran 2018. However, Flang does not have a comprehensive 2018 test suite and does not fully implement the static semantics of the 2018 standard. We are investigating whether agile software development techniques, such as pair programming and test-driven development (TDD), can help Flang to rapidly progress to Fortran 2018 compliance. Because of the paramount importance of parallelism in high-performance computing, we are focusing on Fortran’s parallel features, commonly denoted “Coarray Fortran.” We are developing what we believe are the first exhaustive, open-source tests for the static semantics of Fortran 2018 parallel features, and contributing them to the LLVM project. A related effort involves writing runtime tests for parallel 2018 features and supporting those tests by developing a new parallel runtime library: the CoArray Fortran Framework of Efficient Interfaces to Network Environments (Caffeine).

Rasmussen, Katherine↗

Marrying Social Media Approaches and Space Flight Control: Eight Years at SpaceOps

Three previous SpaceOps papers [1-3] - published in 2010, 2012 (honored by the Conference as a "Best Paper"), and 2014 - have discussed paths to using social media concepts and techniques to enhance space flight controller effectiveness by a) reducing clutter of nonverbal communications (e.g., visual flow with minimal headers and shared content instead of multiple copies), b) moving some voice communication to non-verbal transmission (virtually eliminating "say again" requests because non-verbal comm can be re-read), thus making remaining voice comm easier to focus on, and c) reducing short-term and long-term flight stress on flight control personnel. This paper shows how Marshall Space Flight Center's (MSFC) ISS Payload Operations Integration Center (POIC) is realizing the above goals via the Communications Dashboard (CommDash) software suite deployed in 2017 (including enhancements to the Console Log Tool (CoLT) discussed in earlier papers). Two larger-scope benefits spawned by CommDash evolution are also chronicled: a) emergence of an Agile Software Development (ASD) process adapted to the not-always-nimble environment of government projects, and b) the sprouting of a Human Factors Engineering (HF or HFE) community of practice within MSFC's Payload and Mission Operations Division (PMOD).

Scott, David W.↗

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases, they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At the Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and processes for developing software. This paper will discuss some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies and processes.

software methodology↗

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and procedure for developing software. This paper will discuss the some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies.

Agile Development↗

Extreme Programming: Maestro Style

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Norris, Jeffrey↗

Final Report of the NASA Office of Safety and Mission Assurance Agile Benchmarking Team

To ensure that the NASA Safety and Mission Assurance (SMA) community remains in a position to perform reliable Software Assurance (SA) on NASAs critical software (SW) systems with the software industry rapidly transitioning from waterfall to Agile processes, Terry Wilcutt, Chief, Safety and Mission Assurance, Office of Safety and Mission Assurance (OSMA) established the Agile Benchmarking Team (ABT). The Team's tasks were: 1. Research background literature on current Agile processes, 2. Perform benchmark activities with other organizations that are involved in software Agile processes to determine best practices, 3. Collect information on Agile-developed systems to enable improvements to the current NASA standards and processes to enhance their ability to perform reliable software assurance on NASA Agile-developed systems, 4. Suggest additional guidance and recommendations for updates to those standards and processes, as needed. The ABT's findings and recommendations for software management, engineering and software assurance are addressed herein.

Software Assurance↗

Ground System Architectures Workshop GMSEC SERVICES SUITE (GSS): an Agile Development Story

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.

Software Development/Agile↗

SLS Flight Software Testing: Using a Modified Agile Software Testing Approach

NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.

Bolton, Albanie T.↗

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile↗

Agile Project Management for Research Software [Slides]

Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

97 MATHEMATICS AND COMPUTING↗

Verification and Validation of START: A Spent Nuclear Fuel Routing and Decision Support Tool

This is a technical presentation that does not take into account contractual limitations or obligations under the Standard Contract for Disposal of Spent Nuclear Fuel and/or High-Level Radioactive Waste (Standard Contract) (10 CFR Part 961). For example, under the provisions of the Standard Contract, spent nuclear fuel in multi-assembly canisters is not an acceptable waste form, absent a mutually agreed to contract amendment.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Agile collaboration: Citizen science as a transdisciplinary approach to heliophysics

Citizen science connects scientists with the public to enable discovery, engaging broad audiences across the world. There are many attributes that make citizen science an asset to the field of heliophysics, including agile collaboration. Agility is the extent to which a person, group of people, technology, or project can work efficiently, pivot, and adapt to adversity. Citizen scientists are agile; they are adaptable and responsive. Citizen science projects and their underlying technology platforms are also agile in the software development sense, by utilizing beta testing and short timeframes to pivot in response to community needs. As they capture scientifically valuable data, citizen scientists can bring expertise from other fields to scientific teams. The impact of citizen science projects and communities means citizen scientists are a bridge between scientists and the public, facilitating the exchange of information. These attributes of citizen scientists form the framework of agile collaboration. In this paper, we contextualize agile collaboration primarily for aurora chasers, a group of citizen scientists actively engaged in projects and independent data gathering. Nevertheless, these insights scale across other domains and projects. Citizen science is an emerging yet proven way of enhancing the current research landscape. To tackle the next-generation’s biggest research problems, agile collaboration with citizen scientists will become necessary.

79 ASTRONOMY AND ASTROPHYSICS↗

Automation of Flight Software Regression Testing

NASA is developing the Space Launch System (SLS) to be a heavy lift launch vehicle supporting human and scientific exploration beyond earth orbit. SLS will have a common core stage, an upper stage, and different permutations of boosters and fairings to perform various crewed or cargo missions. Marshall Space Flight Center (MSFC) is writing the Flight Software (FSW) that will operate the SLS launch vehicle. The FSW is developed in an incremental manner based on "Agile" software techniques. As the FSW is incrementally developed, testing the functionality of the code needs to be performed continually to ensure that the integrity of the software is maintained. Manually testing the functionality on an ever-growing set of requirements and features is not an efficient solution and therefore needs to be done automatically to ensure testing is comprehensive. To support test automation, a framework for a regression test harness has been developed and used on SLS FSW. The test harness provides a modular design approach that can compile or read in the required information specified by the developer of the test. The modularity provides independence between groups of tests and the ability to add and remove tests without disturbing others. This provides the SLS FSW team a time saving feature that is essential to meeting SLS Program technical and programmatic requirements. During development of SLS FSW, this technique has proved to be a useful tool to ensure all requirements have been tested, and that desired functionality is maintained, as changes occur. It also provides a mechanism for developers to check functionality of the code that they have developed. With this system, automation of regression testing is accomplished through a scheduling tool and/or commit hooks. Key advantages of this test harness capability includes execution support for multiple independent test cases, the ability for developers to specify precisely what they are testing and how, the ability to add automation, and the ability of the harness and cases to be executed continually. This test concept is an approach that can be adapted to support other projects.

Tashakkor, Scott B.↗

Agile Development Methods for Space Operations

Main stream industry software development practice has gone from a traditional waterfall process to agile iterative development that allows for fast response to customer inputs and produces higher quality software at lower cost. How can we, the space ops community, adopt state of the art software development practice, achieve greater productivity at lower cost, and maintain safe and effective space flight operations? At NASA Ames, we are developing Mission Control Technologies Software, in collaboration with Johnson Space Center (JSC) and, more recently, the Jet Propulsion Laboratory (JPL).

Trimble, Jay↗

Adaptive IV&V for Increasingly Complex Software Systems

As NASA software systems continue to innovate, becoming more complex and nondeterministic, the need for the NASA IV&V Program to become systemically adaptive to ensure mission success is paramount. To ensure adaptability within resource constraints, IV&V has developed an agile, risk-based approach to identify, characterize, scope, focus, and prioritize mission assurance activities. This risk based adaptive framework has been applied to trends such as increased reliance on data driven algorithms for safety and mission critical software behavior, use of MBSE in system design, and application of agile principles to embedded software development. The framework is enabled by continuous innovation of new approaches such as software only test beds, assurance design tools, and initiatives that augment IV&V assurance methods with artificial intelligence and machine learning techniques. This presentation will highlight the trends the NASA IV&V Program is seeing, the innovative steps it is taking to address those challenges, and how it is postured to address evolving risk and constantly changing and new technologies.

Wesley W Deadrick↗