Search NASA⌕ Search

SEARCH · Search NASA

Results for “research software engineering”

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
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 NTRS2022

Advocating for Equality of Contribution: The Research Software Engineer (RSE)

Heliophysics depends on RSEs to properly engineer software. However, RSEs receive unequal treatment compared to their science counterparts, resulting in unsustainable talent loss. These restrictions include lack of credit for their contributions and insufficient training. This paper describes what a RSE is and proposes solutions, including implementing appropriate recognition standards.

software↗
NASA NTRS2006

Infusing Software Assurance Research Techniques into Use

Research in the software engineering community continues to lead to new development techniques that encompass processes, methods and tools. However, a number of obstacles impede their infusion into software development practices. These are the recurring obstacles common to many forms of research. Practitioners cannot readily identify the emerging techniques that may benefit them, and cannot afford to risk time and effort evaluating and trying one out while there remains uncertainty about whether it will work for them. Researchers cannot readily identify the practitioners whose problems would be amenable to their techniques, and, lacking feedback from practical applications, are hard-pressed to gauge the where and in what ways to evolve their techniques to make them more likely to be successful. This paper describes an ongoing effort conducted by a software engineering research infusion team established by NASA s Software Engineering Initiative to overcome these obstacles. .

Pressburger, Thomas↗
NASA NTRS2005

Infusing software assurance research techniques into use

Research in the software engineering community continues to lead to new development techniques that encompass processes, methods and tools. However, a number of obstacles impede their infusion into software deveopment practices. This paper describes an ongoing effort conducted by a software engineering research infusion team established by NASA's Software Engineering Intiative to overcome these obstacles.

Trevino, Luis C.↗
NASA NTRS1977

MUST - An integrated system of support tools for research flight software engineering

The objectives of NASA's MUST (Multipurpose User-oriented Software Technology) program at Langley Research Center are to cut the cost of producing software which effectively utilizes digital systems for flight research. These objectives will be accomplished by providing an integrated system of support software tools for use throughout the research flight software development process. A description of the overall MUST program and its progress toward the release of a first MUST system will be presented. This release includes: a special interactive user interface, a library of subroutines, assemblers, a compiler, automatic documentation tools, and a test and simulation system.

Straeter, T. A.↗
NASA NTRS1977

Research flight software engineering and MUST, an integrated system of support tools

Consideration is given to software development to support NASA flight research. The Multipurpose User-Oriented Software Technology (MUST) program, designed to integrate digital systems into flight research, is discussed. Particular attention is given to the program's special interactive user interface, subroutine library, assemblers, compiler, automatic documentation tools, and test and simulation subsystems.

Straeter, T. A.↗
NASA NTRS2000

Proceedings of the Twenty-Fourth Annual Software Engineering Workshop

On December 1 and 2, the Software Engineering Laboratory (SEL), a consortium composed of NASA/Goddard, the University of Maryland, and CSC, held the 24th Software Engineering Workshop (SEW), the last of the millennium. Approximately 240 people attended the 2-day workshop. Day 1 was composed of four sessions: International Influence of the Software Engineering Laboratory; Object Oriented Testing and Reading; Software Process Improvement; and Space Software. For the first session, three internationally known software process experts discussed the influence of the SEL with respect to software engineering research. In the Space Software session, prominent representatives from three different NASA sites- GSFC's Marti Szczur, the Jet Propulsion Laboratory's Rick Doyle, and the Ames Research Center IV&V Facility's Lou Blazy- discussed the future of space software in their respective centers. At the end of the first day, the SEW sponsored a reception at the GSFC Visitors' Center. Day 2 also provided four sessions: Using the Experience Factory; A panel discussion entitled "Software Past, Present, and Future: Views from Government, Industry, and Academia"; Inspections; and COTS. The day started with an excellent talk by CSC's Frank McGarry on "Attaining Level 5 in CMM Process Maturity." Session 2, the panel discussion on software, featured NASA Chief Information Officer Lee Holcomb (Government), our own Jerry Page (Industry), and Mike Evangelist of the National Science Foundation (Academia). Each presented his perspective on the most important developments in software in the past 10 years, in the present, and in the future.

Source record↗
NASA NTRS2006

The NASA Software Research Infusion Initiative: Successful Technology Transfer for Software Assurance

New processes, methods and tools are constantly appearing in the field of software engineering. Many of these augur great potential in improving software development processes, resulting in higher quality software with greater levels of assurance. However, there are a number of obstacles that impede their infusion into software development practices. These are the recurring obstacles common to many forms of research. Practitioners cannot readily identify the emerging techniques that may most benefit them, and cannot afford to risk time and effort in evaluating and experimenting with them while there is still uncertainty about whether they will have payoff in this particular context. Similarly, researchers cannot readily identify those practitioners whose problems would be amenable to their techniques and lack the feedback from practical applications necessary to help them to evolve their techniques to make them more likely to be successful. This paper describes an ongoing effort conducted by a software engineering research infusion team, and the NASA Research Infusion Initiative, established by NASA s Software Engineering Initiative, to overcome these obstacles.

Hinchey, Michael G.↗
NASA NTRS1993

The (mis)use of subjective process measures in software engineering

A variety of measures are used in software engineering research to develop an understanding of the software process and product. These measures fall into three broad categories: quantitative, characteristics, and subjective. Quantitative measures are those to which a numerical value can be assigned, for example effort or lines of code (LOC). Characteristics describe the software process or product; they might include programming language or the type of application. While such factors do not provide a quantitative measurement of a process or product, they do help characterize them. Subjective measures (as defined in this study) are those that are based on the opinion or opinions of individuals; they are somewhat unique and difficult to quantify. Capturing of subjective measure data typically involves development of some type of scale. For example, 'team experience' is one of the subjective measures that were collected and studied by the Software Engineering Laboratory (SEL). Certainly, team experience could have an impact on the software process or product; actually measuring a team's experience, however, is not a strictly mathematical exercise. Simply adding up each team member's years of experience appears inadequate. In fact, most researchers would agree that 'years' do not directly translate into 'experience.' Team experience must be defined subjectively and then a scale must be developed e.g., high experience versus low experience; or high, medium, low experience; or a different or more granular scale. Using this type of scale, a particular team's overall experience can be compared with that of other teams in the development environment. Defining, collecting, and scaling subjective measures is difficult. First, precise definitions of the measures must be established. Next, choices must be made about whose opinions will be solicited to constitute the data. Finally, care must be given to defining the right scale and level of granularity for measurement.

Valett, Jon D.↗
NASA NTRS2002

Integrating Theory and Practice: Applying the Quality Improvement Paradigm to Product Line Engineering

My assertion is that not only are product lines a relevant research topic, but that the tools used by empirical software engineering researchers can address observed practical problems. Our experience at NASA has been there are often externally proposed solutions available, but that we have had difficulties applying them in our particular context. We have also focused on return on investment issues when evaluating product lines, and while these are important, one can not attain objective data on success or failure until several applications from a product family have been deployed. The use of the Quality Improvement Paradigm (QIP) can address these issues: (1) Planning an adoption path from an organization's current state to a product line approach; (2) Constructing a development process to fit the organization's adoption path; (3) Evaluation of product line development processes as the project is being developed. The QIP consists of the following six steps: (1) Characterize the project and its environment; (2) Set quantifiable goals for successful project performance; (3) Choose the appropriate process models, supporting methods, and tools for the project; (4) Execute the process, analyze interim results, and provide real-time feedback for corrective action; (5) Analyze the results of completed projects and recommend improvements; and (6) Package the lessons learned as updated and refined process models. A figure shows the QIP in detail. The iterative nature of the QIP supports an incremental development approach to product lines, and the project learning and feedback provide the necessary early evaluations.

Stark, Michael↗
NASA NTRS1983

Early estimation of resource expenditures and program size

A substantial amount of software engineering research effort was focused on the development of software estimation models. A measure of lines of code was derived based on the origin of the delivered code, L sub dev = N + E + 0.2 (S + O) (where L sub dev = developed lines of code, N = newly implemented lines of code, E = extensively modified lines of code, S = slightly modified lines of code, and O = old unchanged lines of code) that is substituted in the following equation H sub s = aL sup b (where H sub s = staff-hours of effort, L = lines of code, a = a constant, and b = a constant). The limitations of this model are discussed and some alternative estimation models that can be used earlier in the development process are proposed.

Card, D.↗
NASA NTRS1989

Johnson Space Center software reuse activity

There is a strong operational interest in reuse and commonality at the Johnson Space Center (JSC). Although commonality and reuse were not emphasized in the Space Shuttle Orbiter Project, it is a major goal for Space Station Freedom and the Software Support Environment (SSE). Research activities at JSC are generally conducted through the Software Engineering Research Center (SERC) of the University of Houston at Clear Lake. The Life Cycle Model developed by SERC includes reuse at each phase, but reuse is not a principal theme. The SSE is a significant entry point for new reuse technology, and the SERC can provide consultation and possible prototypes. SERC is seen as an interface to other NISE reuse researchers. The AdaNET is managed at JSC through the University of Houston at Clear Lake for the NASA Office of Technology Utilization. It may also be a gateway for reuse research.

Gorman, Steve↗
NASA NTRS1984

Proceedings of the Ninth Annual Software Engineering Workshop

Experiences in measurement, utilization, and evaluation of software methodologies, models, and tools are discussed. NASA's involvement in ever larger and more complex systems, like the space station project, provides a motive for the support of software engineering research and the exchange of ideas in such forums. The topics of current SEL research are software error studies, experiments with software development, and software tools.

Source record↗
NASA NTRS1983

Comparison of regression modeling techniques for resource estimation

The development and validation of resource utilization models is an active area of software engineering research. Regression analysis is the principal tool employed in these studies. However, little attention was given to determining which of the various regression methods available is the most appropriate. The objective of the study is to compare three alternative regession procedures by examining the results of their application to one commonly accepted equations for resource estimation. The data studied was summarized, the resource estimation equation was described, the regression procedures were explained, and the results obtained from the proceures were compared.

Card, D. N.↗
NASA NTRS1992

Data collection procedures for the Software Engineering Laboratory (SEL) database

This document is a guidebook to collecting software engineering data on software development and maintenance efforts, as practiced in the Software Engineering Laboratory (SEL). It supersedes the document entitled Data Collection Procedures for the Rehosted SEL Database, number SEL-87-008 in the SEL series, which was published in October 1987. It presents procedures to be followed on software development and maintenance projects in the Flight Dynamics Division (FDD) of Goddard Space Flight Center (GSFC) for collecting data in support of SEL software engineering research activities. These procedures include detailed instructions for the completion and submission of SEL data collection forms.

Heller, Gerard↗
NASA NTRS1993

A survey of program slicing for software engineering

This research concerns program slicing which is used as a tool for program maintainence of software systems. Program slicing decreases the level of effort required to understand and maintain complex software systems. It was first designed as a debugging aid, but it has since been generalized into various tools and extended to include program comprehension, module cohesion estimation, requirements verification, dead code elimination, and maintainence of several software systems, including reverse engineering, parallelization, portability, and reuse component generation. This paper seeks to address and define terminology, theoretical concepts, program representation, different program graphs, developments in static slicing, dynamic slicing, and semantics and mathematical models. Applications for conventional slicing are presented, along with a prognosis of future work in this field.

Beck, Jon↗
NASA NTRS1983

Current research in the Software Engineering Laboratory (SEL)

The basic goal of software engineering is to produce the best possible software at the lowest possible cost. Many practices, tools, and techniques (collectively referred to as technologies) were developed that purport to help do this, some of which have become widely accepted in the software industry. However, few of these technologies were effectively evaluated experimentally. This is due in large part to an insufficient understanding of the software development process, a lack of recognized standards for measurement, and the prohibitive cost of large-scale controlled experiments. The analysis described addresses some of these issues. The specific objectives of this study were to: measure technology use in a production environment; develop a model for evaluating software engineering technologies; and evaluate the effects of productivity and reliability of some specific technologies.

Card, D.↗