Engineering Papers⌕ Search

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Wireless Sensor Networks for Developmental and Flight Instrumentation

Wireless sensor networks (WSN) based on the IEEE 802.15.4 Personal Area Network and ZigBee Pro 2007 standards are finding increasing use in home automation and smart energy markets providing a framework for interoperable software. The Wireless Connections in Space Project, funded by the NASA Engineering and Safety Center, is developing technology, metrics and requirements for next-generation spacecraft avionics incorporating wireless data transport. The team from Stennis Space Center and Mobitrum Corporation, working under a NASA SBIR grant, has developed techniques for embedding plug-and-play software into ZigBee WSN prototypes implementing the IEEE 1451 Transducer Electronic Datasheet (TEDS) standard. The TEDS provides meta-information regarding sensors such as serial number, calibration curve and operational status. Incorporation of TEDS into wireless sensors leads directly to building application level software that can recognize sensors at run-time, dynamically instantiating sensors as they are added or removed. The Ames Research Center team has been experimenting with this technology building demonstration prototypes for on-board health monitoring. Innovations in technology, software and process can lead to dramatic improvements for managing sensor systems applied to Developmental and Flight Instrumentation (DFI) aboard aerospace vehicles. A brief overview of the plug-and-play ZigBee WSN technology is presented along with specific targets for application within the aerospace DFI market. The software architecture for the sensor nodes incorporating the TEDS information is described along with the functions of the Network Capable Gateway processor which bridges 802.15.4 PAN to the TCP/IP network. Client application software connects to the Gateway and is used to display TEDS information and real-time sensor data values updated every few seconds, incorporating error detection and logging to help measure performance and reliability in relevant target environments. Test results from our prototype WSN running the Mobitrum software system are summarized and the implications to the scalability and reliability for DFI applications are discussed. Our demonstration system, incorporating sensors for life support system and structural health monitoring is described along with test results obtained by running the demonstration prototype in relevant environments such as the Wireless Habitat Testbed at Johnson Space Center in Houston. An operations concept for improved sensor process flow from design to flight test is outlined specific to the areas of Environmental Control and Life Support System performance characterization and structural health monitoring of human-rated spacecraft. This operations concept will be used to highlight the areas where WSN technology, particularly plug-and-play software based on IEEE 1451, can improve the current process, resulting in significant reductions in the technical effort, overall cost and schedule for providing DFI capability for future spacecraft. RELEASED -

Alena, Richard↗
NASA NTRS1990

Multiversion software reliability through fault-avoidance and fault-tolerance

In this project we have proposed to investigate a number of experimental and theoretical issues associated with the practical use of multi-version software in providing dependable software through fault-avoidance and fault-elimination, as well as run-time tolerance of software faults. In the period reported here we have working on the following: We have continued collection of data on the relationships between software faults and reliability, and the coverage provided by the testing process as measured by different metrics (including data flow metrics). We continued work on software reliability estimation methods based on non-random sampling, and the relationship between software reliability and code coverage provided through testing. We have continued studying back-to-back testing as an efficient mechanism for removal of uncorrelated faults, and common-cause faults of variable span. We have also been studying back-to-back testing as a tool for improvement of the software change process, including regression testing. We continued investigating existing, and worked on formulation of new fault-tolerance models. In particular, we have partly finished evaluation of Consensus Voting in the presence of correlated failures, and are in the process of finishing evaluation of Consensus Recovery Block (CRB) under failure correlation. We find both approaches far superior to commonly employed fixed agreement number voting (usually majority voting). We have also finished a cost analysis of the CRB approach.

Vouk, Mladen A.↗
NASA NTRS1997

The Web Measurement Environment (WebME): A Tool for Combining and Modeling Distributed Data

Many organizations have incorporated data collection into their software processes for the purpose of process improvement. However, in order to improve, interpreting the data is just as important as the collection of data. With the increased presence of the Internet and the ubiquity of the World Wide Web, the potential for software processes being distributed among several physically separated locations has also grown. Because project data may be stored in multiple locations and in differing formats, obtaining and interpreting data from this type of environment becomes even more complicated. The Web Measurement Environment (WebME), a Web-based data visualization tool, is being developed to facilitate the understanding of collected data in a distributed environment. The WebME system will permit the analysis of development data in distributed, heterogeneous environments. This paper provides an overview of the system and its capabilities.

Tesoriero, Roseanne↗
NASA NTRS1993

Measurement of HO2 and other trace gases in the stratosphere using a high resolution far-infrared spectrometer at 28 km

This report covers the time period 1 January 1993 to 30 June 1993. During this reporting period we had our third Upper Atmosphere Research Satellite (UARS) correlative balloon flight and submitted the results from this flight to the Central Data Handling Facility (CDHF). We made a number of improvements in our data processing software in preparation for a new analysis of our old balloon data sets. Finally, we continue to analyze the data obtained during the second Airborne Arctic Stratospheric Expedition (AASE 2).

Traub, Wesley A.↗
NASA NTRS2004

Space Flight Software Development Software for Intelligent System Health Management

The slide presentation examines the Marshall Space Flight Center Flight Software Branch, including software development projects, mission critical space flight software development, software technical insight, advanced software development technologies, and continuous improvement in the software development processes and methods.

Trevino, Luis C.↗
NASA NTRS2002

Quantitative software models for the estimation of cost, size, and defects

The presentation will provide a brief overview of the SQI measurement program as well as describe each of these models and how they are currently being used in supporting JPL project, task and software managers to estimate and plan future software systems and subsystems.

software metrics process improvement↗
NASA NTRS2004

Mars Exploration Rovers navigation results

The twin Mars Exploration Rovers, Spirit and Opportunity, were launched on June 10, 2003(dagger), and July 8, 2003, from Cape Canaveral, Florida. Spirit and Opportunity were targeted for landings at Gusev Crater (arrival on January 4, 2004) and Meridiani Planum (arrival on January 25, 2004). The primary navigation challenge was to deliver each spacecraft to the desired atmospheric entry interface point with sufficient accuracy such that each lander would touch down within a specified landing ellipse (about 70 km x 5 km) determined to be safe for landing and also judged to be scientifically interesting. In order to achieve landing within the target ellipse, precise control of the inertial entry flight path angle (FPA) at atmospheric entry was required. The maximum allowable errors in FPA following TCM-5 (trajectory correction maneuver #5) at Entry (E) - 2 days were +/-0.12(deg) (3(sigma)) for Spirit and +/-0.14(deg) (3(sigma)) for Opportunity. Achieving these entry delivery accuracies necessitated significant improvements to the interplanetary avigation system used for MER. These improvements included new processes and software for orbit determination, propulsive maneuver design, and entry, descent, and landing (EDL) trajectory simulation. The actual achieved atmospheric entry accuracies for Spirit and Opportunity significantly exceeded the requirements. At the navigation data cutoff for the TCM-5 final design, the orbit determination FPA knowledge error was +/-0.028(deg) (3(sigma) ) for Spirit and +/-0.035(deg) (3(sigma)) for Opportunity. Because of exceptionally accurate navigation performance, TCM-5 (E - 2 days) and TCM-6 (E - 4 hours) were canceled for both Spirit and Opportunity. The actual landing locations (determined from in-situ Doppler tracking between the MER rovers and the Mars Odyssey orbiter) differed from the target landing points by 10.1 km (downtrack) for Spirit and 24.6 km (downtrack) for Opportunity. The majority of the landing position offsets for both landers was primarily caused by variations in atmosphere and spacecraft aerodynamic modeling from what was predicted. The amount of the landing position offset caused by navigation-only errors was only 3.3 km (uptrack) for Spirit and 9.7 km (downtrack) for Opportunity.

Mars Exploration Rover (MER)↗
NASA NTRS2004

Mars Exploration Rovers navigation results

The twin Mars Exploration Rovers, Spirit and Opportunity, were launched on June 10, 2003, and July 8, 2003, from Cape Canaveral, Florida. Spirit and Opportunity were targeted for landings at Gusev Crater (arrival on January 4, 2004) and Meridiani Planum (arrival on January 25, 2004). The primary navigation challenge was to deliver each spacecraft to the desired atmospheric entry interface point with sufficient accuracy such that each lander would touch down within a specified landing ellipse (about 70 km x 5 km) determined to be safe for landing and also judged to be scientifically interesting. In order to achieve landing within the target ellipse, precise control of the inertial entry flight path angle (FPA) at atmospheric entry was required. The maximum allowable errors in FPA following TCM-5 (trajectory correction maneuver #5) at Entry (E) -2 days were +/-0.12 deg(3 sigma) for Spirit and +/-0.14 deg(3 sigma) for Opportunity. Achieving these entry delivery accuracies necessitated significant improvements to the interplanetary navigation system used for MER. These improvements included new processes and software for orbit determination, propulsive maneuver design, and entry, descent, and landing (EDL) trajectory simulation. The actual achieved atmospheric entry accuracies for Spirit and Opportunity significantly exceeded the requirements. At the navigation data cutoff for the TCM-5 final design, the orbit determination FPA knowledge error was 0.028 deg(3 sigma) for Spirit and 0.035 deg(3 sigma) for Opportunity. Because of exceptionally accurate navigation performance, TCM-5 (E - 2 days) and TCM-6 (E - 4 hours) were canceled for both Spirit and Opportunity. The actual landing locations (determined from in-situ Doppler tracking between the MER rovers and the Mars Odyssey orbiter) differed from the target landing points by 10.1 km (downtrack) for Spirit and 24.6 km (downtrack) for Opportunity. The majority of the landing position offsets for both landers was primarily caused by variations in atmosphere and spacecraft aerodynamic modeling from what was predicted. The amount of the landing position offset caused by navigation-only errors was only 3.3 km (uptrack) for Spirit and 9.7 km (downtrack) for Opportunity.

Mars Exploration Rover (MER)↗
NASA NTRS2004

Mars Exploration Rover - a new standard for interplanetary navigation

The twin Mars Exploration Rovers, Spirit and Opportunity, arrived at Mars for landings respectively at Gusev Crater (on January 4, 2004) and Meridiani Planum (on January 25, 2004). During the development of the mission, the capability of the navigation system to deliver the landers within a particular accuracy played a major role in landing site selection. This process ultimately resulted in commitments to deliver each lander within a specified landing ellipse (about 70 km x 5 km) determined to be safe for landing and also judged to be scientifically interesting. Achieving atmospheric entry delivery accuracies consistent with this landing requirement necessitated significant improvements to the interplanetary navigation system used for MER. These improvements included new processes and software for orbit determination, aggressive, mission-critical use of interferometric ADOR tracking data, propulsive maneuver design, and entry, descent, and landing (EDL) trajectory simulation. Because these advances pressed the state -of -the art, innovative methods to verify the assumptions in the pre-launch covariance analyses were also developed. The actual achieved atmospheric entry accuracies for Spirit and Opportunity significantly bettered the requirements.

navigation↗
NASA NTRS2003

Analyzing Discrepancies in a Software Development Project Change Request (CR) Assessment Process and Recommendations for Process Improvements

The Change Request (CR) assessment process is essential in the display development cycle. The assessment process is performed to ensure that the changes stated in the description of the CR match the changes in the actual display requirements. If a discrepancy is found between the CR and the requirements, the CR must be returned to the originator for corrections. Data was gathered from each of the developers to determine the type of discrepancies and the amount of time spent assessing each CR. This study sought to determine the most common types of discrepancies, and the amount of time required to assessing those issues. The study found that even though removing discrepancy before an assessment would save half the time needed to assess an CR with a discrepancy, the number of CR's found to have a discrepancy was very small compared to the total number of CR's assessed during the data gathering period.

Cunningham, Kenneth James↗
NASA NTRS2002

Descriptive Study Analyzing Discrepancies in a Software Development Project Change Request (CR) Assessment Process and Recommendations for Process Improvements

The Change Request (CR) assessment process is essential in the display development cycle. The assessment process is performed to ensure that the changes stated in the description of the CR match the changes in the actual display requirements. If a discrepancy is found between the CR and the requirements, the CR must be returned to the originator for corrections. Data will be gathered from each of the developers to determine the type of discrepancies and the amount of time spent assessing each CR. This study will determine the most common types of discrepancies and the amount of time spent assessing those issues. The results of the study will provide a foundation for future improvements as well as a baseline for future studies.

Cunningham, Kenneth J.↗
NASA NTRS1981

AVE-SESAME program for the REEDA System

The REEDA system software was modified and improved to process the AVE-SESAME severe storm data. A random access file system for the AVE storm data was designed, tested, and implemented. The AVE/SESAME software was modified to incorporate the random access file input and to interface with new graphics hardware/software now available on the REEDA system. Software was developed to graphically display the AVE/SESAME data in the convention normally used by severe storm researchers. Software was converted to AVE/SESAME software systems and interfaced with existing graphics hardware/software available on the REEDA System. Software documentation was provided for existing AVE/SESAME programs underlining functional flow charts and interacting questions. All AVE/SESAME data sets in random access format was processed to allow developed software to access the entire AVE/SESAME data base. The existing software was modified to allow for processing of different AVE/SESAME data set types including satellite surface and radar data.

Hickey, J. S.↗
NASA NTRS1998

Development and Testing of Automatically Generated ACS Flight Software for the MAP Spacecraft

By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.

ODonnell, James R., Jr.↗
NASA NTRS1999

Advances in Projection Moire Interferometry Development for Large Wind Tunnel Applications

An instrument development program aimed at using Projection Moire Interferometry (PMI) for acquiring model deformation measurements in large wind tunnels was begun at NASA Langley Research Center in 1996. Various improvements to the initial prototype PMI systems have been made throughout this development effort. This paper documents several of the most significant improvements to the optical hardware and image processing software, and addresses system implementation issues for large wind tunnel applications. The improvements have increased both measurement accuracy and instrument efficiency, promoting the routine use of PMI for model deformation measurements in production wind tunnel tests.

Fleming, Gary A.↗
NASA NTRS1994

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗
NASA NTRS2011

Bootstrapping Process Improvement Metrics: CMMI Level 4 Process Improvement Metrics in a Level 3 World

The measurement techniques for organizations which have achieved the Software Engineering Institutes CMMI Maturity Levels 4 and 5 are well documented. On the other hand, how to effectively measure when an organization is Maturity Level 3 is less well understood, especially when there is no consistency in tool use and there is extensive tailoring of the organizational software processes. Most organizations fail in their attempts to generate, collect, and analyze standard process improvement metrics under these conditions. But at JPL, NASA's prime center for deep space robotic exploration, we have a long history of proving there is always a solution: It just may not be what you expected. In this paper we describe the wide variety of qualitative and quantitative techniques we have been implementing over the last few years, including the various approaches used to communicate the results to both software technical managers and senior managers.

Hihn, Jairus↗
NASA NTRS1992

Description of research interests and current work related to automating software design

Enclosed is a list of selected and recent publications. Most of these publications concern applied research in the areas of software engineering and human-computer interaction. It is felt that domain-specific knowledge plays a major role in software development. Additionally, it is believed that improvements in the general software development process (e.g., object-oriented approaches) will have to be combined with the use of large domain-specific knowledge bases.

Kaindl, Hermann↗