Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software development”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

Status of SPCA-ANL Software Development, Software Quality Assurance, and Application (FY2025)

SPCA-ANL is a simulation tool used to perform deterministic analyses of sodium spray and pool fires. Development of the SPCA-II (Spray Pool Combustion Analysis) code began in the mid- 1980s as part of the Clinch River Breeder Reactor (CRBR) Project. At that time, development of SPCA-II, which was led by Rockwell International, was focused on treatment of large-scale sodium spray, stream, and pool fires that were anticipated to be prototypic of the steam generator building cells in CRBR. Under more recent DOE NE programmatic activities, the SPCA-II code was recovered from existing literature and underwent minor modifications to generate a stable executable. This recovered version of the code was not formally released. As part of the Versatile Test Reactor (VTR) Project in the 2010s, the SPCA-II code underwent key modifications to improve stability, address modeling deficiencies, improve consistency between the code manual and software, and address numerous bugs. At this point, SPCA-II was renamed SPCA-ANL. Given that SPCA-II served as the original basis for SPCA-ANL, both codes share an integrated history. Following termination of the VTR Project, the DOE NE Fast Reactor Program resumed support of the software with the goal of building and maintaining software infrastructure that can enable commercial-grade dedication of SPCA-ANL by an end user. Version 1.0, the first external release of SPCA-ANL, was generated in June 2024. This report summarizes the development and maintenance activities completed for SPCAANL in FY2025. This year’s work was focused on improving quality and usability of the code. The provisional Software Quality Assurance (SQA) program has been established and was used to test the procedures for infrastructure improvements, code development, bug fixes, and code releases, as described in the following sections of this report. A code Version 1.0.1 was released in FY25, as described in Chapter 4.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1981

Cleanroom software development

The 'cleanroom' software development process is a technical and organizational approach to developing software with certifiable reliability. Key ideas behind the process are well structured software specifications, randomized testing methods and the introduction of statistical controls; but the main point is to deny entry for defects during the development of software. This latter point suggests the use of the term 'cleanroom' in analogy to the defect prevention controls used in the manufacturing of high technology hardware. In the 'cleanroom', the entire software development process is embedded within a formal statistical design, in contrast to executing selected tests and appealing to the randomness of operational settings for drawing statistical inferences. Instead, random testing is introduced as a part of the statistical design itself so that when development and testing are completed, statistical inferences are made about the operation of the system.

Dyer, M.↗
NASA NTRS1980

Microcomputer software development facilities

A more efficient and cost effective method for developing microcomputer software is to utilize a host computer with high-speed peripheral support. Application programs such as cross assemblers, loaders, and simulators are implemented in the host computer for each of the microcomputers for which software development is a requirement. The host computer is configured to operate in a time share mode for multiusers. The remote terminals, printers, and down loading capabilities provided are based on user requirements. With this configuration a user, either local or remote, can use the host computer for microcomputer software development. Once the software is developed (through the code and modular debug stage) it can be downloaded to the development system or emulator in a test area where hardware/software integration functions can proceed. The microcomputer software program sources reside in the host computer and can be edited, assembled, loaded, and then downloaded as required until the software development project has been completed.

Gorman, J. S.↗
NASA NTRS1981

Evaluating software development characteristics: A comparison of software errors in different environments

Error data obtained from two different software development environments are compared. To obtain data that was complete, accurate, and meaningful, a goal-directed data collection methodology was used. Changes made to software were monitored concurrently with its development. Similarities common to both environments are included: (1) the principal error was in the design and implementation of single routines; (2) few errors were the result of changes, required more than one attempt to correct, and resulted in other errors; (3) relatively few errors took more than a day to correct.

Weiss, D. M.↗
NASA NTRS1981

Software metrics: The quantitative impact of four factors on work rates experienced during software development

A model of a software development process is described. The software development process is seen to consist of a sequence of activities, such as 'program design' and 'module development' (or coding). A manpower estimate is made by multiplying code size by the rates (man months per thousand lines of code) for each of the activities relevant to the particular case of interest and summing up the results. The effect of four objectively determinable factors (organization, software product type, computer type, and code type) on productivity values for each of nine principal software development activities was assessed. Four factors were identified which account for 39% of the observed productivity variation.

Gaffney, J. E., Jr.↗
NASA NTRS1982

Evaluating software development by analysis of changes: The data from the software engineering laboratory

An effective data collection methodology for evaluating software development methodologies was applied to four different software development projects. Goals of the data collection included characterizing changes and errors, characterizing projects and programmers, identifying effective error detection and correction techniques, and investigating ripple effects. The data collected consisted of changes (including error corrections) made to the software after code was written and baselined, but before testing began. Data collection and validation were concurrent with software development. Changes reported were verified by interviews with programmers.

Source record↗
NASA NTRS1977

Reliability measurement during software development

Measurement of software reliability was carried out during the development of data base software for a multi-sensor tracking system. Every run made during this project was scored as success or failure, and supporting data were collected on forms for further analysis. The failure ratio (number of failures per calendar interval divided by total number of runs) and failure rate (number of failures divided by CPU time for the interval) were found to be consistent measures, on a month-to-month basis as well as from module to module, and therefore considered valid indicators of reliability in this environment. Trend lines could be established from these measurements that provide good visualization of the progress on the job as a whole as well as on individual modules. Over one-half of the observed failures were due to factors associated with the specific run submission rather than with the code proper.

Hecht, H.↗
NASA NTRS1981

A high order approach to flight software development and testing

The use of a software development facility is discussed as a means of producing a reliable and maintainable ECS software system, and as a means of providing efficient use of the ECS hardware test facility. Principles applied to software design are given, including modularity, abstraction, hiding, and uniformity. The general objectives of each phase of the software life cycle are also given, including testing, maintenance, code development, and requirement specifications. Software development facility tools are summarized, and tool deficiencies recognized in the code development and testing phases are considered. Due to limited lab resources, the functional simulation capabilities may be indispensable in the testing phase.

Steinbacher, J.↗
NASA NTRS1981

Management of the Galileo attitude and articulation control flight software development

Management concepts are presented for software development for a new technology area, i.e., real-time autonomous, computer-based spacecraft control. Flight computer selection and sizing are done initially to maximize performance within constraints of size, power, and cost. A higher order language is chosen to enhance productivity. Because the computer is embedded in the control systems hardware and is tied to the iterative design process of the spacecraft, the management and configuration control of the software is different from more typical applications. The development process must permit early coding but accept late changes. Margin management must be a continuing process in the development. Validation and verification is a special problem because it is not feasible to test the software in the actual operating environment prior to launch.

Pace, G. D.↗
NASA NTRS1980

Software development environments: Present and future, appendix D

Computerized environments which facilitate the development of appropriately functioning software systems are discussed. Their current status is reviewed and several trends exhibited by their history are identified. A number of principles, some at (slight) variance with the historical trends, are suggested and it is argued that observance of these principles is critical to achieving truly effective and efficient software development support environments.

Riddle, W. E.↗
NASA NTRS1973

Design of the software development and verification system (SWDVS) for shuttle NASA study task 35

An overview of the Software Development and Verification System (SWDVS) for the space shuttle is presented. The design considerations, goals, assumptions, and major features of the design are examined. A scenario that shows three persons involved in flight software development using the SWDVS in response to a program change request is developed. The SWDVS is described from the standpoint of different groups of people with different responsibilities in the shuttle program to show the functional requirements that influenced the SWDVS design. The software elements of the SWDVS that satisfy the requirements of the different groups are identified.

Drane, L. W.↗
NASA NTRS1980

User involvement in IPAD software development

The extensive user involvement in the software development of IPAD and the functionality of the IPAD prototype as viewed by the user are addressed. Although not a production system that can support an ongoing design process, the IPAD prototype is useful for the potential user as well as the interested system designer and is an essential tool for the companies committed to the use of the IPAD system. User refers to the engineer or manager responsible for the design, manufacture, or maintenance of a product, together with those supporting these functions.

Bryant, W. A.↗
NASA NTRS1978

Measuring software development characteristics in the local environment

In a brief evaluation of software-related considerations, it is found that suitable approaches for software development depend to a large degree on the characteristics of the particular project involved. An analysis is conducted of development problems in an environment in which ground support software is produced for spacecraft control. The amount of work involved is in the range from 6 to 10 man-years. Attention is given to a general project summary, a programmer/analyst survey, a component summary, a component status report, a resource summary, a change report, a computer program run analysis, aspects of data collection on a smaller scale, progress forecasting, problems of overhead, and error analysis.

Basili, V. R.↗
NASA NTRS1980

Software development environment, appendix F

The current status in the area of software development environments is assessed. The purposes of environments, the types of environments, the constituents of an environment, the issue of environment integration, and the problems which must be solved in preparing an environment are discussed. Some general maxims to guide near-term future work are proposed.

Riddle, W. E.↗