SEARCH · Search NASA

Results for “software development management”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 595 records · Page 33

All sources NASA NTRS DOE OSTI

NASA NTRS2003

Virtual Reality Training: "Cybersickness" and Effects on Sensorimotor Functions

The overall goal of this study is to examine the extent to which exposure to virtual reality (VR) systems produces motion sickness and disrupts sensorimotor functions. Two of the major problems in using VRs are: 1) potential "cybersickness", a form of motion sickness, and 2) maladaptive sensorimotor coordination following virtual environment (VE) training. It is likely that users will eventually adapt to any unpleasant perceptual experiences in a virtual environment. However the most critical problem for training applications is that sensorimotor coordination strategies learned in the VE may not be similar to the responses required in the real environment. This study will evaluate and compare responses to the two types of VR delivery systems (head-mounted display [HMD] and a dome-projection system [DOME]), two exposure duration periods (30 minutes or 60 minutes), and repeated exposures (3 sessions). Specific responses that we will examine include cybersickness severity and symptom patterns, and several sensorimotor functions (eye-hea.d and eye-head-hand coordination, and postural equilibrium). To date, all hardware and software acquisition, development, integration and testing has been completed. A database has been developed and tested for the input, management and storage of all questionnaire data. All data analysis scripts have been developed and tested. Data was collected from 20 subjects in a pilot study that was conducted to determine the amount of training necessary to achieve a stable performance level. Seven subjects are currently enrolled in the study designed to examine the effects of exposure to VE systems on postural control. Data has been collected from two subjects, and it is expected that the results from ten subjects will be presented.

Harm, Deborah L.↗

NASA NTRS2014

Software Engineering for Human Spaceflight

The Spacecraft Software Engineering Branch of NASA Johnson Space Center (JSC) provides world‐class products, leadership, and technical expertise in software engineering, processes, technology, and systems management for human spaceflight. The branch contributes to major NASA programs (e.g. ISS, MPCV/Orion) with in‐house software development and prime contractor oversight, and maintains the JSC Engineering Directorate CMMI rating for flight software development. Software engineering teams work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements. They seek to infuse automation and autonomy into missions, and apply new technologies to flight processor and computational architectures. This presentation will provide an overview of key software‐related projects, software methodologies and tools, and technology pursuits of interest to the JSC Spacecraft Software Engineering Branch.

Fredrickson, Steven E.↗

NASA NTRS2008

Web Based Tool for Mission Operations Scenarios

A conventional practice for spaceflight projects is to document scenarios in a monolithic Operations Concept document. Such documents can be hundreds of pages long and may require laborious updates. Software development practice utilizes scenarios in the form of smaller, individual use cases, which are often structured and managed using UML. We have developed a process and a web-based scenario tool that utilizes a similar philosophy of smaller, more compact scenarios (but avoids the formality of UML). The need for a scenario process and tool became apparent during the authors' work on a large astrophysics mission. It was noted that every phase of the Mission (e.g., formulation, design, verification and validation, and operations) looked back to scenarios to assess completeness of requirements and design. It was also noted that terminology needed to be clarified and structured to assure communication across all levels of the project. Attempts to manage, communicate, and evolve scenarios at all levels of a project using conventional tools (e.g., Excel) and methods (Scenario Working Group meetings) were not effective given limitations on budget and staffing. The objective of this paper is to document the scenario process and tool created to offer projects a low-cost capability to create, communicate, manage, and evolve scenarios throughout project development. The process and tool have the further benefit of allowing the association of requirements with particular scenarios, establishing and viewing relationships between higher- and lower-level scenarios, and the ability to place all scenarios in a shared context. The resulting structured set of scenarios is widely visible (using a web browser), easily updated, and can be searched according to various criteria including the level (e.g., Project, System, and Team) and Mission Phase. Scenarios are maintained in a web-accessible environment that provides a structured set of scenario fields and allows for maximum visibility across the project. One key aspect is that the tool was built for a scenario process that accounts for stakeholder input, review, comment, and concurrence. By creating well-designed opportunities for stakeholder input and concurrence and by making the scenario content easily accessible to all project personnel, we maximize the opportunities for stakeholders to both understand and agree on the concepts for how their mission is to be carried out.

Boyles, Carole A.↗

NASA NTRS2016

Developing the Next Generation of Science Data System Engineers

At Goddard, engineers and scientists with a range of experience in science data systems are needed to employ new technologies and develop advances in capabilities for supporting new Earth and Space science research. Engineers with extensive experience in science data, software engineering and computer-information architectures are needed to lead and perform these activities. The increasing types and complexity of instrument data and emerging computer technologies coupled with the current shortage of computer engineers with backgrounds in science has led the need to develop a career path for science data systems engineers and architects.The current career path, in which undergraduate students studying various disciplines such as Computer Engineering or Physical Scientist, generally begins with serving on a development team in any of the disciplines where they can work in depth on existing Goddard data systems or serve with a specific NASA science team. There they begin to understand the data, infuse technologies, and begin to know the architectures of science data systems. From here the typical career involves peermentoring, on-the-job training or graduate level studies in analytics, computational science and applied science and mathematics. At the most senior level, engineers become subject matter experts and system architect experts, leading discipline-specific data centers and large software development projects. They are recognized as a subject matter expert in a science domain, they have project management expertise, lead standards efforts and lead international projects. A long career development remains necessary not only because of the breadth of knowledge required across physical sciences and engineering disciplines, but also because of the diversity of instrument data being developed today both by NASA and international partner agencies and because multidiscipline science and practitioner communities expect to have access to all types of observational data.This paper describes an approach to defining career-path guidance for college-bound high school and undergraduate engineering students, junior and senior engineers from various disciplines.

Next Generation of Science↗

NASA NTRS2019

Workforce for the Future Development of Space Access Vehicles

The development of advanced vehicles that will travel between planetary surfaces with atmospheres and space requires the availability of experimental and computational capabilities that accomplish the research leading to new technologies and the development, test, and evaluation (RDT&E) of new flight systems. The United States is at risk of not having the required RDT&E workforce – qualified and in sufficient numbers – in place and ready to meet the future market’s commercial and defense needs. Systemic challenges include uncertain Federal budgets that limit and interrupt government research and development, the projectized nature of new space access systems that drive boom/bust cycles, an aging aerospace workforce (compounded by a mid-age demographic gap), limited to declining investment in sustaining and advancing experimental and computational tools infrastructure, lack of standards for sharing (and leveraging) data, dramatically changing technologies, changing social norms, and potentially large increases in commercial market needs. Flight systems have mission-based trajectories to and from space and designers must ensure risk is properly assessed across the entire trajectory. Thus, physics questions must be answered at each stage of flight, which requires a suite of experimental and computational tools. The RDT&E workforce utilizing these tools include subject matter experts from the producers, interested in acquiring data and information on the product, and from the capabilities being utilized, interested in addressing the product customer’s needs (providing robust data collection techniques, data quality, timeliness – available when needed, efficient with cost management, and teaming on data analysis). This requires a range of skills – in addition to aerospace, other engineers, and software developers, a highly trained and certified craft and technician workforce is critical to future success. This paper will present a human resources construct that addresses the system of needs for people – including, but more than just technical skills and an application of that construct in the hypersonic Test and Evaluation (T&E) community. This is part of a larger AIAA effort to document challenges and associated best practices for the aerospace RDT&E workforce.

Steven C Dunn↗

DOE OSTI2025

PUFFIn Software Modeling for Quality Management

PUFFIn (PENELOPE User Friendly Fast Interface) was designed as a fast and simple Monte Carlo simulation tool for the transport of photons and electrons, with a primary purpose as a learning and education tool for a broad range of static configurations in the radiation processing industry. Development of the PUFFIn software is funded by the Office of Radiological Security (ORS) within the United States National Nuclear Security Administration (NNSA). PUFFIn helps fill the education and knowledge gaps in the industry, as identified in reports by Fermilab (2017) and the IAEA (2020). PUFFIn uses the PENELOPE (NEA-2023) physics engine to perform simulations on static configurations. PUFFIn has support for multiple geometry types from simple, single material simulations to full 3D configurations created from CAD input files or images from X-Ray Tomography scans. PUFFin was designed to be easy for the novice user, it will generate the input and geometry files required by PENLOPE and will display the output plots within the PUFFIn interface. PUFFin is distributed for free but requires a free workshop so users can be adequately trained in its use. Workshops have been presented in the past at Texas A&M university, the Aerial-CRT facility in Strasbourg France and Jakarta Indonesia. PUFFIn simulations have been validated by 10 MeV ebeam experiments done at Aerial-CRT in France (Radiation Physics and Chemistry 222 (2024) 111774). Further user experimental comparisons were made at the medical product hands on workshop at Texas A&M in October 2024.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

DOE OSTI2024

WETO Software Stack Best Practices

Wind energy researchers typically share one key characteristic: a passion for increasing wind energy in the global energy mix. The U.S. Department of Energy (DOE) supports this mission in a number of ways including allocating funding directly to various aspects of wind energy research through the Office of Energy Efficiency and Renewable Energy (EERE) via the Wind Energy Technologies Office (WETO). While the traditional output of research is academic publication, software development efforts are increasingly a major focus. Software tools in the research environment allow researchers to describe an idea and quickly increase the scope and scale as they study it further. As a product of research, these tools represent a direct pipeline from researcher to industry practitioners since they are the implementation of ideas described in academic publications. Given this vital role in wind energy research and commercial development, the broad research software portfolio supported by WETO must maintain a minimum level of quality to support the wind energy field in the growing transition to renewable energy. This report outlines a series o f best practices to be adopted by all WETO-supported software projects, as well as expectations that the communities interacting with these projects should have of the developers and tools themselves. Wind energy research software has a unique standing in the field of scientific software. The stakeholders are varied with a subset being: (1) DOE EERE leadership, (2) DOE WETO leadership and program managers, (3) National lab leadership, (4) Associated project principle investigators, (5) Research software engineers, (6) Wind energy researchers in academia (including graduate students, post docs, and national lab staff), (7) Industry researchers and practitioners, (8) Commercial software developers, and (9) The general public interested in wind energy. These software are typically the end-user of other generic software libraries, so the funding cycles are often tied to applied research rather than the development of the software itself. Since the developers are also wind energy researchers, these tools are typically designed in a way that closely resembles the application in which they're used. Additionally, the expertise and incentives for the developers have a high variability, and often neither are aligned with software engineering or computer science. Given the unique environment in which wind energy research software is produced and consumed, it is critical for model owners to understand the context of their software. A framework for developing this understanding is to answer the following questions of a given software project: What is it's purpose? What is its role in the field of wind energy? What is the profile of the expected users? For how long will it be relevant? What is the expected impact? These questions allow model owners to identify the appropriate methods for the design, development, and long term maintenance of their software. Additionally, the answer provide context for future planners to understand why particular decisions were made and discern the consequences of changing course. The information is aggregated from experience within WETO-supported software development groups as well as external organizations and efforts to define the craft of research software engineering. These best practices aim to make the collaborative development process efficient and effective while improving the model understanding across stakeholders. Additionally, the general adoption of a common framework for software quality ensures that the end users of WETO software can trust these tools and accurately understand the risks to workflow integration.

17 WIND ENERGY↗

NASA NTRS2009

Surface Habitat Systems

The Surface Habitat Systems (SHS) Focused Investment Group (FIG) is part of the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) effort to provide a focused direction and funding to the various projects that are working on human surface habitat designs and technologies for the planetary exploration missions. The overall SHS-FIG effort focuses on directing and guiding those projects that: 1) develop and demonstrate new surface habitat system concepts, innovations, and technologies to support human exploration missions, 2) improve environmental systems that interact with human habitats, 3) handle and emplace human surface habitats, and 4) focus on supporting humans living and working in habitats on planetary surfaces. The activity areas of the SHS FIG described herein are focused on the surface habitat project near-term objectives as described in this document. The SHS-FIG effort focuses on mitigating surface habitat risks (as identified by the Lunar Surface Systems Project Office (LSSPO) Surface Habitat Element Team; and concentrates on developing surface habitat technologies as identified in the FY08 gap analysis. The surface habitat gap assessment will be updated annually as the surface architecture and surface habitat definition continues to mature. These technologies are mapped to the SHS-FIG Strategic Development Roadmap. The Roadmap will bring to light the areas where additional innovative efforts are needed to support the development of habitat concepts and designs and the development of new technologies to support of the LSSPO Habitation Element development plan. Three specific areas of development that address Lunar Architecture Team (LAT)-2 and Constellation Architecture Team (CxAT) Lunar habitat design issues or risks will be focused on by the SHS-FIG. The SHS-FIG will establish four areas of development that will help the projects prepare in their planning for surface habitat systems development. Those development areas are the 1) surface habitat concept definition, 2) inflatable surface habitat development, and 3) autonomous habitat operations, and 4) cross-cutting / systems engineering. In subsequent years, the SHS-FIG will solicit a call for innovations and technologies that will support the development of these four development areas. The other development areas will be assessed yearly and identified on the SHS-FIG s Strategic Development Roadmap. Initial investment projects that are funded by the Constellation Program Office (CxPO), LSSPO, or the Exploration Technology Development Projects (ETDP) will also be included on the Roadmap. For example, in one or two years from now, the autonomous habitat operations and testbed would collaborations with the Integrated Systems Health Management (ISHM) and Automation for Operations ETDP projects, which will give the surface habitat projects an integrated habitat autonomy testbed to test software and systems. The SHS-FIG scope is to provide focused direction for multiple innovations, technologies and subsystems that are needed to support humans at a remote planetary surface habitat during the concept development, design definition, and integration phases of that project. Subsystems include: habitability, lightweight structures, power management, communications, autonomy, deployment, outfitting, life support, wireless connectivity, lighting, thermal and more.

Kennedy, Kriss J.↗

NASA NTRS1988

Knowledge-based assistance in costing the space station DMS

The Software Cost Engineering (SCE) methodology developed over the last two decades at IBM Systems Integration Division (SID) in Houston is utilized to cost the NASA Space Station Data Management System (DMS). An ongoing project to capture this methodology, which is built on a foundation of experiences and lessons learned, has resulted in the development of an internal-use-only, PC-based prototype that integrates algorithmic tools with knowledge-based decision support assistants. This prototype Software Cost Engineering Automation Tool (SCEAT) is being employed to assist in the DMS costing exercises. At the same time, DMS costing serves as a forcing function and provides a platform for the continuing, iterative development, calibration, and validation and verification of SCEAT. The data that forms the cost engineering database is derived from more than 15 years of development of NASA Space Shuttle software, ranging from low criticality, low complexity support tools to highly complex and highly critical onboard software.

Henson, Troy↗

NASA NTRS1980

The work breakdown structure in software project management

A work breakdown structure (WBS) is defined as an enumeration of all work activities in hierarchic refinement of detail which organizes work to be done into short manageable tasks with quantifiable inputs, outputs, schedules, and assigned responsibilities. Some of the characteristics and benefits of the WBS are reviewed, and ways in which these can be developed and applied in software implementation projects are discussed. Although the material is oriented principally toward new-software production tasks, many of the concepts are applicable to continuing maintenance and operations tasks.

Tausworthe, R. C.↗

NASA NTRS1981

Payload carrier systems for conducting sortie mode science

The capabilities and characteristics of the payload carriers developed to provide structural and operational interfaces between the Space Shuttle and the various types of experiments designed to operate in the sortie mode are discussed. The Spacelab is a flexible laboratory system composed of interchangeable elements that can be put together in eight different combinations of pallets and pressurized modules, and provides considerable standard services to users in such areas as equipment installation, power distribution, thermal control, command and data management, software, pointing systems and crew participation. A modular three-axis pointing control system designated the Annular Suspension and Pointing System, is being developed to provide additional pointing capabilities to those payloads that require capabilities not provided by the Spacelab instrument pointing system. Two engineering models of the Spacelab pallet have been designated Orbital Flight Test Pallets which, together with a special experiment support structure, are intended for initial and operational payloads that do not constitute a complete Spacelab mission. The simplest and smallest payload carriers are the Getaway Special cans, intended for small, self-contained, self-sufficient payloads, and the orbiter middeck lockers. In this way, most of the user requirements for Shuttle sortie missions identified to date can be fulfilled.

Jean, O. C.↗

NASA NTRS2019

Mapping the User Journey: Building a User Persona and Story Repository to Improve NASA EOSDIS Application Development

Understanding the needs of the end user is vital to producing quality, usable software that solves real problems. Additionally, making sure those needs are communicated to managers, engineers, and designers at the project level is vital. On complex projects, it's important to build out resources for your team that make it easy to put yourself in the shoes of the specific user you're building for. NASA's Earth Observing System is a collection of data, applications, and a diverse user and scientific community that's trying to answer tough questions about our planet and its climate. Over the last few years, we've spoken to hundreds of users, performed many user testing sessions, and built a collection of user personas, user stories, and design assets that help guide new software and feature development within NASA EOSDIS. We've also developed methods for synthesizing this information and making it actionable for teams, and worked to foster a design first approach on new projects always starting from a core user need and working backward from interface development to software engineering. This process has allowed us to design better, more usable software and features that directly meet the needs of our user community.

Siarto, Jeff↗

NASA NTRS1999

Roll-Out and Turn-Off Display Software for Integrated Display System

This report describes the software products, system architectures and operational procedures developed by Lockheed-Martin in support of the Roll-Out and Turn-Off (ROTO) sub-element of the Low Visibility Landing and Surface Operations (LVLASO) program at the NASA Langley Research Center. The ROTO portion of this program focuses on developing technologies that aid pilots in the task of managing the deceleration of an aircraft to a pre-selected exit taxiway. This report focuses on software that produces a system of redundant deceleration cues for a pilot during the landing roll-out, and presents these cues on a head up display (HUD). The software also produces symbology for aircraft operational phases involving cruise flight, approach, takeoff, and go-around. The algorithms and data sources used to compute the deceleration guidance and generate the displays are discussed. Examples of the display formats and symbology options are presented. Logic diagrams describing the design of the ROTO software module are also given.

Johnson, Edward J., Jr.↗

NASA NTRS1986

Object-oriented development

Object Oriented Development (OOD) is one of the extremely few software development methods actually designed for modern Ada language, real-time, embedded applications. OOD is a significant improvement over more traditional functional decomposition and modeling methods in that ODD: Better manages the size, complexity, and concurrancy of today's systems; Better addresses important software engineering principles such as abstract data types, levels of abstraction, and information hiding; Produces a better design that more closely matches reality; Produces more maintainable software by better localizing data and thus limiting the impact of requirements changes; and Specifically exploits the power of Ada. OOD is further explored in detail.

Firesmith, Donald G.↗

DOE OSTI2025

American-Made Solar Prize: Edgeli Enables DER Integration (CRADA 615) (Final Report)

The purpose of this project was to demonstrate how granular time series data and automated data transformation, and impact assessment tools could speed interconnection approvals for distributed energy resource projects of various types and sizes. Types included community solar, rooftop solar, and EV charging projects. Using software routines to automate the transformation of data (e.g. GIS) to a network database and power flow model then applying scenarios to create hourly (8760) hosting capacity values and voltage and thermal impacts for specific projects, we were able to demonstrate the feasibility of quickly assembling and analyzing key utility data sets for interconnection purposes. The outcomes of this effort will become the foundation for future work that will enhance and encapsulate the software components developed as part of this project, into web services (e.g. APIs) that can be integrated into queue management systems and automate interconnection screening processes.

14 SOLAR ENERGY↗

NASA NTRS1985

User's operating procedures. Volume 3: Projects directorate information programs

A review of the user's operating procedures for the scout project automatic data system, called SPADS is presented. SPADS is the results of the past seven years of software development on a prime mini-computer. SPADS was developed as a single entry, multiple cross-reference data management and information retrieval system for the automation of Project office tasks, including engineering, financial, managerial, and clerical support. This volume, three of three, provides the instructions to operate the projects directorate information programs in data retrieval and file maintenance via the user friendly menu drivers.

Haris, C. G.↗

NASA NTRS1990

GCS programmer's manual

A variety of instructions to be used in the development of implementations of software for the Guidance and Control Software (GCS) project is described. This document fulfills the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, 'Software Considerations in Airborne Systems and Equipment Certification' requirements for document No. 4, which specifies the information necessary for understanding and programming the host computer, and document No. 12, which specifies the software design and implementation standards that are applicable to the software development and testing process. Information on the following subjects is contained: activity recording, communication protocol, coding standards, change management, error handling, design standards, problem reporting, module testing logs, documentation formats, accuracy requirements, and programmer responsibilities.

Lowman, Douglas S.↗

NASA NTRS1994

End effector monitoring system: An illustrated case of operational prototyping

Operational prototyping is introduced to help developers apply software innovations to real-world problems, to help users articulate requirements, and to help develop more usable software. Operational prototyping has been applied to an expert system development project. The expert system supports fault detection and management during grappling operations of the Space Shuttle payload bay arm. The dynamic exchanges among operational prototyping team members are illustrated in a specific prototyping session. We discuss the requirements for operational prototyping technology, types of projects for which operational prototyping is best suited and when it should be applied to those projects.

Malin, Jane T.↗