Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software measurement”

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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Towards a mature measurement environment: Creating a software engineering research environment

Software engineering researchers are building tools, defining methods, and models; however, there are problems with the nature and style of the research. The research is typically bottom-up, done in isolation so the pieces cannot be easily logically or physically integrated. A great deal of the research is essentially the packaging of a particular piece of technology with little indication of how the work would be integrated with other prices of research. The research is not aimed at solving the real problems of software engineering, i.e., the development and maintenance of quality systems in a productive manner. The research results are not evaluated or analyzed via experimentation or refined and tailored to the application environment. Thus, it cannot be easily transferred into practice. Because of these limitations we have not been able to understand the components of the discipline as a coherent whole and the relationships between various models of the process and product. What is needed is a top down experimental, evolutionary framework in which research can be focused, logically and physically integrated to produce quality software productively, and evaluated and tailored to the application environment. This implies the need for experimentation, which in turn implies the need for a laboratory that is associated with the artifact we are studying. This laboratory can only exist in an environment where software is being built, i.e., as part of a real software development and maintenance organization. Thus, we propose that Software Engineering Laboratory (SEL) type activities exist in all organizations to support software engineering research. We describe the SEL from a researcher's point of view, and discuss the corporate and government benefits of the SEL. The discussion focuses on the benefits to the research community.

Basili, Victor R.↗
NASA NTRS1992

Preliminary efforts toward development of data handling and analysis software for unsteady flow measurements: An application for aeroelastic transonic flow configurations

A few years ago the Structural Dynamics Division at LaRC started ambitious experimental research efforts known as the Benchmark Models Program. The primary objective of this program was to provide experimental data that may serve as a calibration source for computational fluid dynamics (CFD) efforts that deal with aeroelastic unsteady flow configurations. It also focuses on the understanding of complex flow phenomenon associated with unsteady flow developments. The overall plan for the program has been described by Bennett, including a presentation of initial test results of flutter of a rigid wing mounted on flexible supports. An example of a test model employed to measure the dynamic response along with corresponding pressure distributions is shown. This model incorporates eighty pressure transducers distributed along two spanwise stations. In addition, the models are equipped with four accelerometers and two strain gages. The data handling system for the Benchmark Model Program is under development. Several interactive computer routines designed for the user interface, dynamic memory allocation, unsteady flow measurements data extraction, and further data processing were developed. To present a few examples of measured data, the unsteady pressure distributions and the wing model dynamic response were plotted.

Finaish, Fathi↗
DOE OSTI2026

A Scalable Test-Bed for Direct Current Current Transformer Automated Functional Testing and Characterization

This article describes a scalable test-bed for automation of measurements of the direct current current transformers (DCCT). Automation of measurement involves functional measurements, fault event based measurements and data validation. The test-bed is designed to measure up to 20 DCCTs at a time with software based measurement repetition checks and validation of the measurements.

43 PARTICLE ACCELERATORS↗
NASA NTRS1993

Developing interpretable models with optimized set reduction for identifying high risk software components

Applying equal testing and verification effort to all parts of a software system is not very efficient, especially when resources are limited and scheduling is tight. Therefore, one needs to be able to differentiate low/high fault frequency components so that testing/verification effort can be concentrated where needed. Such a strategy is expected to detect more faults and thus improve the resulting reliability of the overall system. This paper presents the Optimized Set Reduction approach for constructing such models, intended to fulfill specific software engineering needs. Our approach to classification is to measure the software system and build multivariate stochastic models for predicting high risk system components. We present experimental results obtained by classifying Ada components into two classes: is or is not likely to generate faults during system and acceptance test. Also, we evaluate the accuracy of the model and the insights it provides into the error making process.

Briand, Lionel C.↗
NASA NTRS1974

Software and modifications for automated microwave spectral measurements on the Hewlett Packard 8460 spectrometer

A Hewlett-Packard 8460A spectrometer was adapted for automatic spectral searches and measurements under computer control. Software consists of a BASIC language control program and assembly language equipment drivers. Complete software listings are given including cross reference tables. Each equipment driver program is discussed, and wiring diagrams are given for the additions required for computer control.

White, W. F.↗
NASA NTRS2004

Defect measurement and analysis of JPL ground software: a case study

Ground software systems at JPL must meet high assurance standards while remaining on schedule due to relatively immovable launch dates for spacecraft that will be controlled by such systems. Toward this end, the Software Quality Improvement (SQI) project's Measurement and Benchmarking (M&B) team is collecting and analyzing defect data of JPL ground system software projects to build software defect prediction models. The aim of these models is to improve predictability with regard to software quality activities. Predictive models will quantitatively define typical trends for JPL ground systems as well as Critical Discriminators (CDs) to provide explanations for atypical deviations from the norm at JPL. CDs are software characteristics that can be estimated or foreseen early in a software project's planning. Thus, these CDs will assist in planning for the predicted degree to which software quality activities for a project are likely to deviation from the normal JPL ground system based on pasted experience across the lab.

defects↗
NASA NTRS1986

An empirical study of software design practices

Software engineers have developed a large body of software design theory and folklore, much of which was never validated. The results of an empirical study of software design practices in one specific environment are presented. The practices examined affect module size, module strength, data coupling, descendant span, unreferenced variables, and software reuse. Measures characteristic of these practices were extracted from 887 FORTRAN modules developed for five flight dynamics software projects monitored by the Software Engineering Laboratory (SEL). The relationship of these measures to cost and fault rate was analyzed using a contingency table procedure. The results show that some recommended design practices, despite their intuitive appeal, are ineffective in this environment, whereas others are very effective.

Card, David N.↗
NASA NTRS1988

Software system safety

Software itself is not hazardous, but since software and hardware share common interfaces there is an opportunity for software to create hazards. Further, these software systems are complex, and proven methods for the design, analysis, and measurement of software safety are not yet available. Some past software failures, future NASA software trends, software engineering methods, and tools and techniques for various software safety analyses are reviewed. Recommendations to NASA are made based on this review.

Uber, James G.↗
NASA NTRS1995

Object-Oriented Software Metrics for Predicting Reusability and Estimating Size

As object-oriented software development methods come into more widespread use, basic questions of software quality assurance must be reconsidered. We will highlight efforts now underway at NASA's Jet Propulsion Laboratory to both assess the quality of software systems developed using object oriented technology and develop guidelines for future development of such systems. The current focus is on design and code reusability., and system size estimation. A number of metrics are proposed and two software systems measured and analyzed. The preliminary results reported here should be useful to software development and quality assurance personnel working in C++ implementation environment.

Sanderson, D. Peter↗
NASA NTRS1977

Measurement, estimation, and prediction of software reliability

Quantitative indices of software reliability are defined, and application of three important indices is indicated: (1) reliability measurement, (2) reliability estimation, and (3) reliability prediction. State of the art techniques for each of these procedures are presented together with considerations of data acquisition. Failure classifications and other documentation for comprehensive software reliability evaluation are described.

Hecht, H.↗
NASA NTRS1994

The development and application of composite complexity models and a relative complexity metric in a software maintenance environment

A great deal of effort is now being devoted to the study, analysis, prediction, and minimization of software maintenance expected cost, long before software is delivered to users or customers. It has been estimated that, on the average, the effort spent on software maintenance is as costly as the effort spent on all other software costs. Software design methods should be the starting point to aid in alleviating the problems of software maintenance complexity and high costs. Two aspects of maintenance deserve attention: (1) protocols for locating and rectifying defects, and for ensuring that noe new defects are introduced in the development phase of the software process; and (2) protocols for modification, enhancement, and upgrading. This article focuses primarily on the second aspect, the development of protocols to help increase the quality and reduce the costs associated with modifications, enhancements, and upgrades of existing software. This study developed parsimonious models and a relative complexity metric for complexity measurement of software that were used to rank the modules in the system relative to one another. Some success was achieved in using the models and the relative metric to identify maintenance-prone modules.

Hops, J. M.↗
NASA NTRS2013

Orion MPCV GN and C End-to-End Phasing Tests

End-to-end integration tests are critical risk reduction efforts for any complex vehicle. Phasing tests are an end-to-end integrated test that validates system directional phasing (polarity) from sensor measurement through software algorithms to end effector response. Phasing tests are typically performed on a fully integrated and assembled flight vehicle where sensors are stimulated by moving the vehicle and the effectors are observed for proper polarity. Orion Multi-Purpose Crew Vehicle (MPCV) Pad Abort 1 (PA-1) Phasing Test was conducted from inertial measurement to Launch Abort System (LAS). Orion Exploration Flight Test 1 (EFT-1) has two end-to-end phasing tests planned. The first test from inertial measurement to Crew Module (CM) reaction control system thrusters uses navigation and flight control system software algorithms to process commands. The second test from inertial measurement to CM S-Band Phased Array Antenna (PAA) uses navigation and communication system software algorithms to process commands. Future Orion flights include Ascent Abort Flight Test 2 (AA-2) and Exploration Mission 1 (EM-1). These flights will include additional or updated sensors, software algorithms and effectors. This paper will explore the implementation of end-to-end phasing tests on a flight vehicle which has many constraints, trade-offs and compromises. Orion PA-1 Phasing Test was conducted at White Sands Missile Range (WSMR) from March 4-6, 2010. This test decreased the risk of mission failure by demonstrating proper flight control system polarity. Demonstration was achieved by stimulating the primary navigation sensor, processing sensor data to commands and viewing propulsion response. PA-1 primary navigation sensor was a Space Integrated Inertial Navigation System (INS) and Global Positioning System (GPS) (SIGI) which has onboard processing, INS (3 accelerometers and 3 rate gyros) and no GPS receiver. SIGI data was processed by GN&C software into thrust magnitude and direction commands. The processing changes through three phases of powered flight: pitchover, downrange and reorientation. The primary inputs to GN&C are attitude position, attitude rates, angle of attack (AOA) and angle of sideslip (AOS). Pitch and yaw attitude and attitude rate responses were verified by using a flight spare SIGI mounted to a 2-axis rate table. AOA and AOS responses were verified by using a data recorded from SIGI movements on a robotic arm located at NASA Johnson Space Center. The data was consolidated and used in an open-loop data input to the SIGI. Propulsion was the Launch Abort System (LAS) Attitude Control Motor (ACM) which consisted of a solid motor with 8 nozzles. Each nozzle has active thrust control by varying throat area with a pintle. LAS ACM pintles are observable through optically transparent nozzle covers. SIGI movements on robot arm, SIGI rate table movements and LAS ACM pintle responses were video recorded as test artifacts for analysis and evaluation. The PA-1 Phasing Test design was determined based on test performance requirements, operational restrictions and EGSE capabilities. This development progressed during different stages. For convenience these development stages are initial, working group, tiger team, Engineering Review Team (ERT) and final.

Neumann, Brian C.↗
NASA NTRS1991

Metrics

A development status evaluation is presented for practical software performance measurement, or 'metrics', in which major innovations have recently occurred. Metrics address such aspects of software performance as whether a software project is on schedule, how many errors can be expected from it, whether the methodology being used is effective and the relative quality of the software employed. Metrics may be characterized as explicit, analytical, and subjective. Attention is given to the bases for standards and the conduct of metrics research.

Mcgarry, Frank↗
NASA NTRS1988

The TAME Project: Towards improvement-oriented software environments

Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture.

Basili, Victor R.↗
NASA NTRS1998

Tropospheric- Stratospheric Measurement Studies Summary

The two high altitude aircraft, ER-2 NASA #706 and 709 and the DC-8 NASA #717 are in active use in several programs of upper atmospheric research to study polar ozone changes, stratospheric-tropospheric exchange processes and atmospheric effects of aviation aircraft. The ER-2 has participated in seven major missions which mainly concentrated on vortex dynamics and the large losses of Ozone in the Polar regions (Ozone hole) observed in the spring. One mission verified the complex dynamical chemical and physical processes that occur during sunrise and sunset. Stratospheric Tracers of Atmospheric Transport (STRAT) obtained background measurements using the full ER-2 suite of instruments. Photochemistry of Ozone Loss in the Arctic Region in Summer (POLARIS) in 1997 assisted in understanding the mid-latitude and Arctic Ozone losses during the Northern Summer. The DC-8 with the Meteorological Measurement System (MMS) has participated in the Subsonic Aircraft: Cloud and Contrail Effects Special Study (SUCCESS), in 1996 and the Subsonic assessment Ozone and Nitrogen oxide experiment (SONEX) in 1997 missions. The MMS with its sophisticated software accurately measures ground speed and attitude, in-situ static and dynamic pressure total temperature, which are used to calculate the three dimensional wind fields, static pressure, temperature and turbulence values to meteorological accuracy. The meteorological data is not only of interest for its own sake in atmospheric dynamical processes such as mountain waves and flux measurements; but is also required by other ER-2 experiments that simultaneously measure water vapor, O3, aerosols, NO, HCl, CH4, N2O, ClO, BrO, CO2, NOy, HOx and temperature gradients. MMS products are extensively used to assist in the interpretation of their results in understanding the importance of convective effects relative to in-situ chemical changes, as may be noted by examining the list of references attached. The MMS consists of three subsystems: (a) aircraft instrumentation, inertial navigation system (INS), static and dynamic pressure taps, (b) additional dedicated instrumentation measuring angle of attack, yaw, total temperature, and a GPS which on the DC-8 measures position, velocity and attitude (c) an on board data, storage and computing acquisition system. This instrumentation and the associated software requires both an on-going laboratory ground calibration procedure for the total air temperature, static and total pressure inputs, verification of the INS dynamic response and also extensive air measurements and intercomparisons which ultimately verify and calibrate the complete system and its software. More than the usual accuracy is required because of the near cancellation occurring in the difference between the ground speed and true airspeed vectors used to give the wind vector. In the past year we have redesigned, recalibrated and used the MMS system on the NASA DC-8 that was previously used in the SUCCESS mission for the SONEX mission. Two papers were co-authored based on SUCCESS flights. Several reports and handouts were written for SONEX. Calibrations of the DC-8 pressure transducer temperature measuring thermistors was completed and an extensive analysis spanning several years of data files of the DC-8 Rosemount pressure transducer calibrations was done.

Browen, Stuart W.↗
NASA NTRS1992

Modeling software systems by domains

The Software Architectures Engineering (SAE) Project at the Software Engineering Institute (SEI) has developed engineering modeling techniques that both reduce the complexity of software for domain-specific computer systems and result in systems that are easier to build and maintain. These techniques allow maximum freedom for system developers to apply their domain expertise to software. We have applied these techniques to several types of applications, including training simulators operating in real time, engineering simulators operating in non-real time, and real-time embedded computer systems. Our modeling techniques result in software that mirrors both the complexity of the application and the domain knowledge requirements. We submit that the proper measure of software complexity reflects neither the number of software component units nor the code count, but the locus of and amount of domain knowledge. As a result of using these techniques, domain knowledge is isolated by fields of engineering expertise and removed from the concern of the software engineer. In this paper, we will describe kinds of domain expertise, describe engineering by domains, and provide relevant examples of software developed for simulator applications using the techniques.

Dippolito, Richard↗
NASA NTRS1996

Qualitative Analysis for Maintenance Process Assessment

In order to improve software maintenance processes, we first need to be able to characterize and assess them. These tasks must be performed in depth and with objectivity since the problems are complex. One approach is to set up a measurement-based software process improvement program specifically aimed at maintenance. However, establishing a measurement program requires that one understands the problems to be addressed by the measurement program and is able to characterize the maintenance environment and processes in order to collect suitable and cost-effective data. Also, enacting such a program and getting usable data sets takes time. A short term substitute is therefore needed. We propose in this paper a characterization process aimed specifically at maintenance and based on a general qualitative analysis methodology. This process is rigorously defined in order to be repeatable and usable by people who are not acquainted with such analysis procedures. A basic feature of our approach is that actual implemented software changes are analyzed in order to understand the flaws in the maintenance process. Guidelines are provided and a case study is shown that demonstrates the usefulness of the approach.

Brand, Lionel↗