Engineering PapersSearch

SEARCH · Engineering Papers

Results for “software process improvement”

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 109 records · Page 6

Library reuse in a rapid development environment

The Aeroscience and Flight Mechanics Division (AFMD) established a Rapid Development Laboratory (RDL) to investigate and improve new 'rapid development' software production processes and refine the use of commercial, off-the-shelf (COTS) tools. These tools and processes take an avionics design project from initial inception through high fidelity, real-time, hardware-in-the-loop (HIL) testing. One central theme of a rapid development process is the use and integration of a variety of COTS tools: This paper discusses the RDL MATRIX(sub x)(R) libraries, as well as the techniques for managing and documenting these libraries. This paper also shows the methods used for building simulations with the Advanced Simulation Development System (ASDS) libraries, and provides metrics to illustrate the amount of reuse for five complete simulations. Combining ASDS libraries with MATRIX(sub x)(R) libraries is discussed.

Uhde, JO

Deep-Space Conjunction Assessment: Recent Developments and Future Evolution

The Multi-mission Automated Deep-space Conjunction Assessment Process (MADCAP) is a NASA Jet Propulsion Laboratory (JPL) capability used to perform conjunction assessment in shared deep-space environments. MADCAP began performing conjunction assessment at Mars and the Moon in 2011, with the Sun/Earth libration points added to its functionality in 2020. There has been an increasing number of missions operating in these environments in recent years, leading to an elevated frequency of close conjunction events, especially in the Lunar orbital environment. MADCAP provides this service not only to NASA missions, but to any operator who is willing to share ephemerides. Since there is no space surveillance network for deep space environments, ephemeris sharing is the only way in which spacecraft operators can ensure the safety of their spacecraft from collision in these orbit regimes. NASA published a set of conjunction assessment best practices in 2020 that cover the MADCAP process. This paper details recent MADCAP operational experience in the deep space environments, including statistics and process improvements. Updates to the MADCAP software and automation framework implemented to handle the recent growth in the number of deep space missions are also discussed. Future enhancements planned in anticipation of increasingly crowded deep-space environments, such as non-standard runs based on exploratory scenarios, are also discussed.

conjunction assessment

Using Pilots to Assess the Value and Approach of CMMI Implementation

At Goddard Space Flight Center (GSFC), we have chosen to use Capability Maturity Model Integrated (CMMI) to guide our process improvement program. Projects at GSFC consist of complex systems of software and hardware that control satellites, operate ground systems, run instruments, manage databases and data and support scientific research. It is a challenge to launch a process improvement program that encompasses our diverse systems, yet is manageable in terms of cost effectiveness. In order to establish the best approach for improvement, our process improvement effort was divided into three phases: 1) Pilot projects; 2) Staged implementation; and 3) Sustainment and continual improvement. During Phase 1 the focus of the activities was on a baselining process, using pre-appraisals in order to get a baseline for making a better cost and effort estimate for the improvement effort. Pilot pre-appraisals were conducted from different perspectives so different approaches for process implementation could be evaluated. Phase 1 also concentrated on establishing an improvement infrastructure and training of the improvement teams. At the time of this paper, three pilot appraisals have been completed. Our initial appraisal was performed in a flight software area, considering the flight software organization as the organization. The second appraisal was done from a project perspective, focusing on systems engineering and acquisition, and using the organization as GSFC. The final appraisal was in a ground support software area, again using GSFC as the organization. This paper will present our initial approach, lessons learned from all three pilots and the changes in our approach based on the lessons learned.

Godfrey, Sara

An overview of the Software Engineering Laboratory

This report describes the background and structure of the SEL organization, the SEL process improvement approach, and its experimentation and data collection process. Results of some sample SEL studies are included. It includes a discussion of the overall implication of trends observed over 17 years of process improvement efforts and looks at the return on investment based on a comparison of total investment in process improvement with the measurable improvements seen in the organization's software product.

Source record

Status of Precise Orbit Determination for Jason-2 Using GPS

The JASON-2 satellite, launched in June 2008, is the latest follow-on to the successful TOPEX/Poseidon (T/P) and JASON-I altimetry missions. JASON-2 is equipped with a TRSR Blackjack GPS dual-frequency receiver, a laser retroreflector array, and a DORIS receiver for precise orbit determination (POD). The most recent time series of orbits computed at NASA GSFC, based on SLR/DORIS data have been completed using both ITRF2005 and ITRF2008. These orbits have been shown to agree radially at 1 cm RMS for dynamic vs SLRlDORIS reduced-dynamic orbits and in comparison with orbits produced by other analysis centers (Lemoine et al., 2010; Zelensky et al., 2010; Cerri et al., 2010). We have recently upgraded the GEODYN software to implement model improvements for GPS processing. We describe the implementation of IGS standards to the Jason2 GEODYN GPS processing, and other dynamical and measurement model improvements. Our GPS-only JASON-2 orbit accuracy is assessed using a number of tests including analysis of independent SLR and altimeter crossover residuals, orbit overlap differences, and direct comparison to orbits generated at GSFC using SLR and DORIS tracking, and to orbits generated externally at other centers. Tests based on SLR and the altimeter crossover residuals provide the best performance indicator for independent validation of the NASAlGSFC GPS-only reduced dynamic orbits. For the ITRF2005 and ITRF2008 implementation of our GPS-only obits we are using the IGS05 and IGS08 standards. Reduced dynamic versus dynamic orbit differences are used to characterize the remaining force model error and TRF instability. We evaluate the GPS vs SLR & DORIS orbits produced using the GEODYN software and assess in particular their consistency radially and the stability of the altimeter satellite reference frame in the Z direction for both ITRF2005 and ITRF2008 as a proxy to assess the consistency of the reference frame for altimeter satellite POD.

Melachroinos, S.

The Standard Autonomous File Server, a Customized, Off-the-Shelf Success Story

The Standard Autonomous File Server (SAFS), which includes both off-the-shelf hardware and software, uses an improved automated file transfer process to provide a quicker, more reliable, prioritized file distribution for customers of near real-time data without interfering with the assets involved in the acquisition and processing of the data. It operates as a stand-alone solution, monitoring itself, and providing an automated fail-over process to enhance reliability. This paper will describe the unique problems and lessons learned both during the COTS selection and integration into SAFS, and the system's first year of operation in support of NASA's satellite ground network. COTS was the key factor in allowing the two-person development team to deploy systems in less than a year, meeting the required launch schedule. The SAFS system his been so successful, it is becoming a NASA standard resource, leading to its nomination for NASA's Software or the Year Award in 1999.

Semancik, Susan K.

Modeling and managing risk early in software development

In order to improve the quality of the software development process, we need to be able to build empirical multivariate models based on data collectable early in the software process. These models need to be both useful for prediction and easy to interpret, so that remedial actions may be taken in order to control and optimize the development process. We present an automated modeling technique which can be used as an alternative to regression techniques. We show how it can be used to facilitate the identification and aid the interpretation of the significant trends which characterize 'high risk' components in several Ada systems. Finally, we evaluate the effectiveness of our technique based on a comparison with logistic regression based models.

Briand, Lionel C.

Changes and challenges in the Software Engineering Laboratory

Since 1976, the Software Engineering Laboratory (SEL) has been dedicated to understanding and improving the way in which one NASA organization, the Flight Dynamics Division (FDD), develops, maintains, and manages complex flight dynamics systems. The SEL is composed of three member organizations: NASA/GSFC, the University of Maryland, and Computer Sciences Corporation. During the past 18 years, the SEL's overall goal has remained the same: to improve the FDD's software products and processes in a measured manner. This requires that each development and maintenance effort be viewed, in part, as a SEL experiment which examines a specific technology or builds a model of interest for use on subsequent efforts. The SEL has undertaken many technology studies while developing operational support systems for numerous NASA spacecraft missions.

Pajerski, Rose

Software Formal Inspections Standard

This Software Formal Inspections Standard (hereinafter referred to as Standard) is applicable to NASA software. This Standard defines the requirements that shall be fulfilled by the software formal inspections process whenever this process is specified for NASA software. The objective of this Standard is to define the requirements for a process that inspects software products to detect and eliminate defects as early as possible in the software life cycle. The process also provides for the collection and analysis of inspection data to improve the inspection process as well as the quality of the software.

Source record

NASA Tech Briefs, July 2004

Topics: Optoelectronic Sensor System for Guidance in Docking; Hybrid Piezoelectric/Fiber-Optic Sensor Sheets; Multisensor Arrays for Greater Reliability and Accuracy; Integrated-Optic Oxygen Sensors; Ka-Band Autonomous Formation Flying Sensor; CMOS VLSI Active-Pixel Sensor for Tracking; Lightweight, Self-Deploying Foam Antenna Structures; Electrically Small Microstrip Quarter-Wave Monopole Antennas; A 2-to-28-MHz Phase-Locked Loop; Portable Electromyograph; Open-Source Software for Modeling of Nanoelectronic Devices; Software for Generating Strip Maps from SAR Data; Calibration Software for use with Jurassicprok; Software for Probabilistic Risk Reduction; Software Processes SAR Motion-Measurement Data; Improved Method of Purifying Carbon Nanotubes; Patterned Growth of Carbon Nanotubes or Nanofibers; Lightweight, Rack-Mountable Composite Cold Plate/Shelves; SiC-Based Miniature High-Temperature Cantilever Anemometer; Inlet Housing for a Partial-Admission Turbine; Lightweight Thermoformed Structural Components and Optics; Growing High-Quality InAs Quantum Dots for Infrared Lasers; Selected Papers on Protoplanetary Disks; Module for Oxygenating Water without Generating Bubbles; Coastal Research Imaging Spectrometer; Rapid Switching and Modulation by use of Coupled VCSELs; Laser-Induced-Fluorescence Photogrammetry and Videogrammetry; Laboratory Apparatus Generates Dual-Species Cold Atomic Beam; Laser Ablation of Materials for Propulsion of Spacecraft; Small Active Radiation Monitor; Hybrid Image-Plane/Stereo Manipulation; Partitioning a Gridded Rectangle into Smaller Rectangles; Digital Radar-Signal Processors Implemented in FPGAs; Part 1 of a Computational Study of a Drop-Laden Mixing Layer; and Some Improvements in Signal-Conditioning Circuits.

Source record

The Package-Based Development Process in the Flight Dynamics Division

The Software Engineering Laboratory (SEL) has been operating for more than two decades in the Flight Dynamics Division (FDD) and has adapted to the constant movement of the software development environment. The SEL's Improvement Paradigm shows that process improvement is an iterative process. Understanding, Assessing and Packaging are the three steps that are followed in this cyclical paradigm. As the improvement process cycles back to the first step, after having packaged some experience, the level of understanding will be greater. In the past, products resulting from the packaging step have been large process documents, guidebooks, and training programs. As the technical world moves toward more modularized software, we have made a move toward more modularized software development process documentation, as such the products of the packaging step are becoming smaller and more frequent. In this manner, the QIP takes on a more spiral approach rather than a waterfall. This paper describes the state of the FDD in the area of software development processes, as revealed through the understanding and assessing activities conducted by the COTS study team. The insights presented include: (1) a characterization of a typical FDD Commercial Off the Shelf (COTS) intensive software development life-cycle process, (2) lessons learned through the COTS study interviews, and (3) a description of changes in the SEL due to the changing and accelerating nature of software development in the FDD.

Parra, Amalia

Software Formal Inspections Standard

The purpose of this Standard is to define the requirements for a software inspection process aimed at detecting and eliminating defects as early as possible in the software life cycle. This process can be used for any documented product; however, this Standard focuses on its use for software products - i.e., software code, plans, manuals, etc. The process provides for the collection and analysis of inspection data to improve the inspection process as well as the quality of the software.

Wetherholt, Martha S.

Importance of Requirements Analysis & Traceability to Improve Software Quality and Reduce Cost and Risk

The goal of this paper is to emphasize the importance of developing complete and unambiguous requirements early in the project cycle (prior to Preliminary Design Phase). Having a complete set of requirements early in the project cycle allows sufficient time to generate a traceability matrix. Requirements traceability and analysis are the key elements in improving verification and validation process, and thus overall software quality. Traceability can be most beneficial when the system changes. If changes are made to high-level requirements it implies that low-level requirements need to be modified. Traceability ensures that requirements are appropriately and efficiently verified at various levels whereas analysis ensures that a rightly interpreted set of requirements is produced.

Kapoor, Manju M.

Software Formal Inspections Guidebook

The Software Formal Inspections Guidebook is designed to support the inspection process of software developed by and for NASA. This document provides information on how to implement a recommended and proven method for conducting formal inspections of NASA software. This Guidebook is a companion document to NASA Standard 2202-93, Software Formal Inspections Standard, approved April 1993, which provides the rules, procedures, and specific requirements for conducting software formal inspections. Application of the Formal Inspections Standard is optional to NASA program or project management. In cases where program or project management decide to use the formal inspections method, this Guidebook provides additional information on how to establish and implement the process. The goal of the formal inspections process as documented in the above-mentioned Standard and this Guidebook is to provide a framework and model for an inspection process that will enable the detection and elimination of defects as early as possible in the software life cycle. An ancillary aspect of the formal inspection process incorporates the collection and analysis of inspection data to effect continual improvement in the inspection process and the quality of the software subjected to the process.

Source record

Software Development Standard Processes (SDSP)

A JPL-created set of standard processes is to be used throughout the lifecycle of software development. These SDSPs cover a range of activities, from management and engineering activities, to assurance and support activities. These processes must be applied to software tasks per a prescribed set of procedures. JPL s Software Quality Improvement Project is currently working at the behest of the JPL Software Process Owner to ensure that all applicable software tasks follow these procedures. The SDSPs are captured as a set of 22 standards in JPL s software process domain. They were developed in-house at JPL by a number of Subject Matter Experts (SMEs) residing primarily within the Engineering and Science Directorate, but also from the Business Operations Directorate and Safety and Mission Success Directorate. These practices include not only currently performed best practices, but also JPL-desired future practices in key thrust areas like software architecting and software reuse analysis. Additionally, these SDSPs conform to many standards and requirements to which JPL projects are beholden.

Lavin, Milton L.

Achieving dependability throughout the development process - A distributed software experiment

Distributed software engineering techniques and methods for improving the specification and testing phases are considered. With multiversion development, multiple implementations allow the use of an automated approach to testing called back-to-back (B/B) testing in which the outputs are compared to detect any discrepancies. However, a specification defect may lead to similar errors in the multiple versions and the underlying fault may not be detected with a B/B testing approach. The use of diverse formal specifications has been proposed as a solution to this problem, since defects in independently written specifications are likely to be different. To examine these issues, an experiment was performed using the design diversity approach in the specification, design, implementation, and testing of distributed software. In the experiment, three diverse formal specifications were used to produce multiple independent implementations of a distributed communication protocol in Ada. The problems encountered in building complex concurrent processing systems in Ada were also studied. Many pitfalls were discovered in mapping the formal specifications into Ada implementations.

Kelly, John P. J.

Exploring the Nature of Neutrinos with the Deep Underground Neutrino Experiment (DUNE)

The Deep Underground Neutrino Experiment (DUNE) is a next-generation experimental program designed to study the behaviour of neutrino oscillation. DUNE will utilize a neutrino beam originating at Fermilab, near Chicago, and will leverage a detector at Fermilab (Near Detector) and a detector 1300 km away in South Dakota (Far Detector), south of Saskatchewan. In the first phase of DUNE, its Far Detector will comprise of two 10,000 ton (fiducial) liquid argon (LAr) time-projection chamber (TPC) modules – powerful tracking calorimeter detectors – placed nearly a mile underground. With this large, sensitive, underground detector, DUNE aims to collect a high statistics and pure sample of neutrinos at the Far Detector. This setup also offers the potential to study non-beam physical processes via e.g. neutrinos produced in the atmosphere, supernova neutrino bursts, and/or solar neutrinos, etc. A second phase will aim to add more detector mass and expand the program. The Near Detector will consist of a LAr TPC module as well: critical to constraining systematic uncertainties in the oscillation analysis. However, this LAr TPC will have a novel design using a pixel-based readout instead of the traditional wire-based readout. This and the segmentation of the LAr TPC into multiple units are crucial in mitigating the high multiplicity of neutrino interactions expected in any readout window given its proximity to the beam. The Near Detector will feature additional components and capability beyond the LAr TPC, allowing one to deeply characterize the neutrino flux. Due to the complexity of this experimental program, several smaller-scale prototype detectors have been operating to test, validate, and improve both the technical designs and software for processing and analyzing events. By operating in charged particle test beams or neutrino beams, several of the prototypes are also capable of producing valuable results. Canadian institutions are involved in the realization of the DUNE through efforts with both the Near and Far Detectors and prototypes. DUNE is anticipated to begin operating near the end of this decade/the beginning of the next. This talk will focus on the overall DUNE program, for example its ultimate plans, status, and the efforts with prototypes.

Howard, Bruce [York U., Canada; Fermilab]