Search NASA⌕ Search

SEARCH · Search NASA

Results for “agile,”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗
DOE OSTI2020

Agile Cradle-to-Grave (Agile C2G) v1

The concept for the AgileC2G Model is based on well-documented input-output methods first introduced by Wassily Leontief. These matrices are more commonly used to represent monetary inputs and outputs by sector. In contrast, the developers have constructed a model that uses a customized matrix consisting of key products and services (in place of sectors) that are directly and/or indirectly relevant to bioenergy systems (and energy systems more broadly). Their matrix tracks inputs and outputs based on physical units and uses prices only to complete the required calculations before converting total requirements back to physical units of interest.

Scown, Corinne↗
NASA NTRSDate not supplied

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↗
NASA NTRS1993

An investigation of fighter aircraft agility

This report attempts to unify in a single document the results of a series of studies on fighter aircraft agility funded by the NASA Ames Research Center, Dryden Flight Research Facility and conducted at the University of Kansas Flight Research Laboratory during the period January 1989 through December 1993. New metrics proposed by pilots and the research community to assess fighter aircraft agility are collected and analyzed. The report develops a framework for understanding the context into which the various proposed fighter agility metrics fit in terms of application and testing. Since new metrics continue to be proposed, this report does not claim to contain every proposed fighter agility metric. Flight test procedures, test constraints, and related criteria are developed. Instrumentation required to quantify agility via flight test is considered, as is the sensitivity of the candidate metrics to deviations from nominal pilot command inputs, which is studied in detail. Instead of supplying specific, detailed conclusions about the relevance or utility of one candidate metric versus another, the authors have attempted to provide sufficient data and analyses for readers to formulate their own conclusions. Readers are therefore ultimately responsible for judging exactly which metrics are 'best' for their particular needs. Additionally, it is not the intent of the authors to suggest combat tactics or other actual operational uses of the results and data in this report. This has been left up to the user community. Twenty of the candidate agility metrics were selected for evaluation with high fidelity, nonlinear, non real-time flight simulation computer programs of the F-5A Freedom Fighter, F-16A Fighting Falcon, F-18A Hornet, and X-29A. The information and data presented on the 20 candidate metrics which were evaluated will assist interested readers in conducting their own extensive investigations. The report provides a definition and analysis of each metric; details of how to test and measure the metric, including any special data reduction requirements; typical values for the metric obtained using one or more aircraft types; and a sensitivity analysis if applicable. The report is organized as follows. The first chapter in the report presents a historical review of air combat trends which demonstrate the need for agility metrics in assessing the combat performance of fighter aircraft in a modern, all-aspect missile environment. The second chapter presents a framework for classifying each candidate metric according to time scale (transient, functional, instantaneous), further subdivided by axis (pitch, lateral, axial). The report is then broadly divided into two parts, with the transient agility metrics (pitch lateral, axial) covered in chapters three, four, and five, and the functional agility metrics covered in chapter six. Conclusions, recommendations, and an extensive reference list and biography are also included. Five appendices contain a comprehensive list of the definitions of all the candidate metrics; a description of the aircraft models and flight simulation programs used for testing the metrics; several relations and concepts which are fundamental to the study of lateral agility; an in-depth analysis of the axial agility metrics; and a derivation of the relations for the instantaneous agility and their approximations.

Valasek, John↗
NASA NTRSDate not supplied

Results from NASA Agile Teams Study

In order to meet the demands of the current global economy, a study of agile teams at NASA was conducted by the NASA Engineering and Safety Center (NESC) to explore how the Agency can become more adaptable and flexible due to several influences, including the maturity and availability of digital tools and NASA’s increased reliance on commercial providers. NESC Technical Discipline Teams (TDTs) perform annual studies to understand the needs of their stakeholders, establish a state of the discipline, and inform strategic planning efforts. As part of the 2022 interview series, the Systems Engineering TDT utilized the dissertation work of Dr. Jackelynne Silva-Martinez that focused on NASA agile teams. The Systems Engineering TDT partnered with the Software and Human Factors TDTs on the formulation of interview questions and subsequent solicitation of customer inputs, which helped attract diverse agile teams across the Agency. 34 participants were interviewed, including civil servants and contractors, with open-ended questions related to their teams’ adoption and transition to agile. Participants were also questioned about their perceptions of the implementation of agile approaches across the Agency. Results showed a consistent framing of agile as incremental knowledge growth, a way of showing progress, and as the incorporation of frequent customer feedback. However, participants emphasized a lack of a common understanding of agile across the Agency, which sometimes caused managers and engineers to be reluctant to accept and support them. Results also showed the most successful agile teams had formal training with over five years of agile experience, used retrospectives, and tailored their agile processes for their specific situation and needs. This paper provides details of the interview responses gathered in the study and suggests actions for NASA to become more agile.

NASA↗
NASA NTRS2017

Applying Standard Independent Verification and Validation (IVV) Techniques Within an Agile Framework: Is There a Compatibility Issue?

Agile methods have gained wide acceptance over the past several years, to the point that they are now a standard management and execution approach for small-scale software development projects. While conventional Agile methods are not generally applicable to large multi-year and mission-critical systems, Agile hybrids are now being developed (such as SAFe) to exploit the productivity improvements of Agile while retaining the necessary process rigor and coordination needs of these projects. From the perspective of Independent Verification and Validation (IVV), however, the adoption of these hybrid Agile frameworks is becoming somewhat problematic. Hence, we find it prudent to question the compatibility of conventional IVV techniques with (hybrid) Agile practices.This paper documents our investigation of (a) relevant literature, (b) the modification and adoption of Agile frameworks to accommodate the development of large scale, mission critical systems, and (c) the compatibility of standard IVV techniques within hybrid Agile development frameworks. Specific to the latter, we found that the IVV methods employed within a hybrid Agile process can be divided into three groups: (1) early lifecycle IVV techniques that are fully compatible with the hybrid lifecycles, (2) IVV techniques that focus on tracing requirements, test objectives, etc. are somewhat incompatible, but can be tailored with a modest effort, and (3) IVV techniques involving an assessment requiring artifact completeness that are simply not compatible with hybrid Agile processes, e.g., those that assume complete requirement specification early in the development lifecycle.

Agile↗
DOE OSTI2023

Agilent CRADA (Abstract)

The CRADA between Agilent Technologies Inc. and Battelle will focus on five software components as listed below: Prototype 4D Feature Finding functionality with a particular focus on recovering low level features and extending the bottom end dynamic range of IM-MS technology. Compare and contrast developments to current 4D Feature Finding capabilities. Highlight important algorithmic aspects employed. Implement the PNNL saturation correction algorithm. Agilent will give PNNL the needed data file access API and assistance in understanding it implementation and any needed instrumental aspects. Supported high resolution products to include Agilent’s TOF, QTOF and IM-QTOF mass spectrometers. PNNL will then work with Agilent to benchmark performance. Implementation of the PNNL Hadamard de-multiplexing algorithm. Agilent will give provide PNNL the needed date file access API access and as needed assistance in understanding the current Agilent multiplexed IM offering. PNNL will then work with Agilent on benchmark performance. Add ion mobility collision cross sections to existing and new metabolomic libraries for data analysis with Agilent’s informatics program MPP/ID Browser. PNNL will work with Agilent to create a software pipeline that takes data from chemical and metabolic standards and properly formats it for inclusion in MPP accessible libraries, using the collision cross section as a new separation dimension. Improvements of MPP multidimensional matching to identify metabolomic features using multiple characteristics beyond retention time and accurate mass. Most significantly matching will include analyte collision cross section with proposed support for sample fraction or RapidFire cartridge and fragmentation spectra. PNNL will work with Agilent to modify and improve the current MPP analysis pipeline to allow for creating, aligning, and identifying MS features defined by accurate mass, collision cross section and chromatographic retention time. As additional criteria such as fraction or RapidFire cartridge type are supported in the identification process, then they also will become part of the automation workflow. This includes the automation of said system to work with command line program (i.e. not a GUI) sufficient for programmatic execution in a pipeline.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2006

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↗
NASA NTRS2006

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↗
NASA NTRS1991

The measurement and improvement of the lateral agility of the F-18

The effect of vehicle configuration and flight control system performance on the roll agility of a modern fighter aircraft has been investigated. A batch simulation of a generic F-18 Hornet was used to study the roll agility as measured by the time to roll through 90 deg metric. Problems discussed include definition of agility, factors affecting the agility of a vehicle, the development of the time to roll through 90 deg agility metric, and a simulation experiment. It is concluded that the integral of stability or wind axis roll rate should be used as a measure of the roll measure traversed. The time through roll angle 90 deg metric is considered to be a good metric for measuring the transient performance aspect of agility. Roll agility of the F-18, as measured by 90 deg metric, can be improved by 10 to 30 percent. Compatible roll and rudder actuator rates can significantly affect 90 deg agility metric.

Eggold, David P.↗
NASA NTRS1993

Analysis and optimization of preliminary aircraft configurations in relationship to emerging agility metrics

This paper discusses the development of a FORTRAN computer code to perform agility analysis on aircraft configurations. This code is to be part of the NASA-Ames ACSYNT (AirCraft SYNThesis) design code. This paper begins with a discussion of contemporary agility research in the aircraft industry and a survey of a few agility metrics. The methodology, techniques and models developed for the code are then presented. Finally, example trade studies using the agility module along with ACSYNT are illustrated. These trade studies were conducted using a Northrop F-20 Tigershark aircraft model. The studies show that the agility module is effective in analyzing the influence of common parameters such as thrust-to-weight ratio and wing loading on agility criteria. The module can compare the agility potential between different configurations. In addition one study illustrates the module's ability to optimize a configuration's agility performance.

Sandlin, Doral R.↗
NASA NTRS1996

Development of an agility assessment module for preliminary fighter design

A FORTRAN computer program is presented to perform agility analysis on fighter aircraft configurations. This code is one of the modules of the NASA Ames ACSYNT (AirCraft SYNThesis) design code. The background of the agility research in the aircraft industry and a survey of a few agility metrics are discussed. The methodology, techniques, and models developed for the code are presented. FORTRAN programs were developed for two specific metrics, CCT (Combat Cycle Time) and PM (Pointing Margin), as part of the agility module. The validity of the code was evaluated by comparing with existing flight test data. Example trade studies using the agility module along with ACSYNT were conducted using Northrop F-20 Tigershark and McDonnell Douglas F/A-18 Hornet aircraft models. The sensitivity of thrust loading and wing loading on agility criteria were investigated. The module can compare the agility potential between different configurations and has the capability to optimize agility performance in the preliminary design process. This research provides a new and useful design tool for analyzing fighter performance during air combat engagements.

Ngan, Angelen↗
NASA NTRS1996

Utilization of an agility assessment module in analysis and optimization of preliminary fighter configuration

A study has been conducted to develop and to analyze a FORTRAN computer code for performing agility analysis on fighter aircraft configurations. This program is one of the modules of the NASA Ames ACSYNT (AirCraft SYNThesis) design code. The background of the agility research in the aircraft industry and a survey of a few agility metrics are discussed. The methodology, techniques, and models developed for the code are presented. The validity of the existing code was evaluated by comparing with existing flight test data. A FORTRAN program was developed for a specific metric, PM (Pointing Margin), as part of the agility module. Example trade studies using the agility module along with ACSYNT were conducted using a McDonnell Douglas F/A-18 Hornet aircraft model. Tile sensitivity of thrust loading, wing loading, and thrust vectoring on agility criteria were investigated. The module can compare the agility potential between different configurations and has capability to optimize agility performance in the preliminary design process. This research provides a new and useful design tool for analyzing fighter performance during air combat engagements in the preliminary design.

Ngan, Angelen↗
NASA NTRS1993

Development of a Computer Program for Analyzing Preliminary Aircraft Configurations in Relationship to Emerging Agility Metrics

This paper discusses the development of a FORTRAN computer code to perform agility analysis on aircraft configurations. This code is to be part of the NASA-Ames ACSYNT (AirCraft SYNThesis) design code. This paper begins with a discussion of contemporary agility research in the aircraft industry and a survey of a few agility metrics. The methodology, techniques and models developed for the code are then presented. Finally, example trade studies using the agility module along with ACSYNT are illustrated. These trade studies were conducted using a Northrop F-20 Tigershark aircraft model. The studies show that the agility module is effective in analyzing the influence of common parameters such as thrust-to-weight ratio and wing loading on agility criteria. The module can compare the agility potential between different configurations. In addition, one study illustrates the module's ability to optimize a configuration's agility performance.

Bauer, Brent↗
NASA NTRSDate not supplied

Introduction of an Agile Systems Engineering Process to the NASA Armstrong Flight Research Center

This paper will provide background on the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD) ARMD Test Data Portal (ATDP) effort along with the rationale that motivated the ATDP team to consider implementing an agile systems engineering (SE) process. The primary motivation for using this new SE process was based on the desire to mitigate a major risk to project success. Since the agile SE process had never been used before at the NASA Armstrong Flight Research Center (AFRC), utilizing this new SE process required a trailblazing effort to introduce it to NASA AFRC leadership. As a result, the ATDP team chose to adhere to the agile SE process in addition to the trusted classical waterfall SE process on ATDP. Through successful execution of this hybrid SE process during Phase I, along with demonstrating the value and rigor of the agile SE process, NASA AFRC leadership ultimately permitted the ATDP project to solely use the agile SE process for developments beyond Phase I. While it is the opinion of the authors that the classical SE process is more effective for most projects at NASA AFRC, some projects may deem that the agile SE process is more advantageous. Although this paper is focused on introducing the agile SE process to NASA AFRC, lessons learned will be valuable to other organizations as well. Details of how the ATDP team implemented the agile SE process during Phase I will be summarized, along with how the team met all required classical SE milestones. Lessons learned throughout Phase I of this effort will also be highlighted.

Daniel S. Jones↗