SEARCH · Engineering Papers

Results for “software lifecycle”

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.

SourceResearch connectionFrom yearThrough year

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

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

DOE OSTI2023

Software Bill of Materials (SBOM) Sharing Lifecycle Report

As Software Bill of Materials (SBOM) adoption efforts mature, SBOM sharing continues to occur, but no single solution or set of solutions have become ubiquitous. The purpose of this report is to enumerate and describe the different parties and phases of the SBOM sharing lifecycle and assist readers in choosing suitable SBOM sharing solutions based on the amount of time, resources, subject-matter expertise, effort, and access to tooling that is available to the reader to implement a phase of the SBOM sharing lifecycle. The SBOM sharing lifecycle consists of the Discovery, Access, and Transport of an SBOM and this report details these individual phases and how an SBOM goes from author to the consumer. This report also details how potential enrichment activities may be performed on an SBOM to create a new product before or after it has been shared. The concept of a sophistication classification for SBOM sharing solutions is concurrently introduced with a focus on the inclusion or lack of certain features and effort associated with their implementation. Examples of low, medium, and high-sophistication solutions are provided; however, these examples and associated categorizations should not be seen as a qualitative judgment meant to push the reader towards a particular adoption strategy since sharing solutions are chosen based on the unique needs of the user. This report does recommend the SBOM community consider how to make current and future sharing solutions interoperable with each other as well as more automated methods to facilitate sharing and broader SBOM adoption. This report also highlights an SBOM sharing survey results obtained from interviews with stakeholders to understand the current SBOM sharing landscape. The categorized results of the survey suggest that SBOMs are currently transported directly to the receiver through email or similar informal communication mechanisms or alternatively the SBOM resides on a repository available to consumers. In addition to these transport methods, this report captures industry efforts to create private sharing solutions and services that can store and transport enrichment data and may use higher sophistication features that are cloud-based or using distributed ledger technologies.

97 MATHEMATICS AND COMPUTING↗

NASA NTRSDate not supplied

Implementing the Infosec Color Wheel into an UAM Software and System Development Lifecycle

This research will provide information on the importance of collaboration between software development teams and cyber security teams. As Urban Air Mobility software services are developed, a collaborative approach between software development and software assurance teams will limit the exposed vulnerabilities and weaknesses.

Urban Air Mobility↗

NASA NTRS2007

NASA's Software Safety Standard

NASA relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft launched that does not have a computer on board that will provide command and control services. There have been recent incidents where software has played a role in high-profile mission failures and hazardous incidents. For example, the Mars Orbiter, Mars Polar Lander, the DART (Demonstration of Autonomous Rendezvous Technology), and MER (Mars Exploration Rover) Spirit anomalies were all caused or contributed to by software. The Mission Control Centers for the Shuttle, ISS, and unmanned programs are highly dependant on software for data displays, analysis, and mission planning. Despite this growing dependence on software control and monitoring, there has been little to no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Meanwhile, academia and private industry have been stepping forward with procedures and standards for safety critical systems and software, for example Dr. Nancy Leveson's book Safeware: System Safety and Computers. The NASA Software Safety Standard, originally published in 1997, was widely ignored due to its complexity and poor organization. It also focused on concepts rather than definite procedural requirements organized around a software project lifecycle. Led by NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard has recently undergone a significant update. This new standard provides the procedures and guidelines for evaluating a project for safety criticality and then lays out the minimum project lifecycle requirements to assure the software is created, operated, and maintained in the safest possible manner. This update of the standard clearly delineates the minimum set of software safety requirements for a project without detailing the implementation for those requirements. This allows the projects leeway to meet these requirements in many forms that best suit a particular project's needs and safety risk. In other words, it tells the project what to do, not how to do it. This update also incorporated advances in the state of the practice of software safety from academia and private industry. It addresses some of the more common issues now facing software developers in the NASA environment such as the use of Commercial-Off-the-Shelf Software (COTS), Modified OTS (MOTS), Government OTS (GOTS), and reused software. A team from across NASA developed the update and it has had both NASA-wide internal reviews by software engineering, quality, safety, and project management. It has also had expert external review. This presentation and paper will discuss the new NASA Software Safety Standard, its organization, and key features. It will start with a brief discussion of some NASA mission failures and incidents that had software as one of their root causes. It will then give a brief overview of the NASA Software Safety Process. This will include an overview of the key personnel responsibilities and functions that must be performed for safety-critical software.

Ramsay, Christopher M.↗

NASA NTRS2011

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.↗

DOE OSTI2022

Reproduced Computational Results Report for “Ginkgo: A Modern Linear Operator Algebra Framework for High Performance Computing”

The article titled “Ginkgo: A Modern Linear Operator Algebra Framework for High Performance Computing” by Anzt et al. presents a modern, linear operator centric, C++ library for sparse linear algebra. Experimental results in the article demonstrate that Ginkgo is a flexible and user-friendly framework capable of achieving high-performance on state-of-the-art GPU architectures. In this report, the Ginkgo library is installed and a subset of the experimental results are reproduced. Specifically, the experiment that shows the achieved memory bandwidth of the Ginkgo Krylov linear solvers on NVIDIA A100 and AMD MI100 GPUs is redone and the results are compared to what presented in the published article. Upon completion of the comparison, the published results are deemed reproducible.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2006

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures

Many software failures stem from inadequate requirements engineering. This view has been supported both by detailed accident investigations and by a number of empirical studies; however, such investigations can be misleading. It is often difficult to distinguish between failures in requirements engineering and problems elsewhere in the software development lifecycle. Further pitfalls arise from the assumption that inadequate requirements engineering is a cause of all software related accidents for which the system fails to meet its requirements. This paper identifies some of the problems that have arisen from an undue focus on the role of requirements engineering in the causes of major accidents. The intention is to provoke further debate within the emerging field of forensic software engineering.

Johnson, C. W.↗

NASA NTRS1984

Executable assertions and flight software

It is pointed out that executable assertions can be used for dynamic testing of software. An executable assertion is a logical statement about the variables or a block of code. If there is no error during execution then the assertion statement results in a true value. Assertions are useful for testing purposes throughout the lifecycle of software. They can be used for validation during the design phase, and for exception handling and error detection during the operation phase. The present investigation has the objective to study the use of executable assertions for testing flight software. Attention is given to details regarding executable assertions, the digital flight control system, testing flight software, and preliminary experimental results.

Mahmood, A.↗

NASA NTRS1993

Software metrics: The key to quality software on the NCC project

Network Control Center (NCC) Project metrics are captured during the implementation and testing phases of the NCCDS software development lifecycle. The metrics data collection and reporting function has interfaces with all elements of the NCC project. Close collaboration with all project elements has resulted in the development of a defined and repeatable set of metrics processes. The resulting data are used to plan and monitor release activities on a weekly basis. The use of graphical outputs facilitates the interpretation of progress and status. The successful application of metrics throughout the NCC project has been instrumental in the delivery of quality software. The use of metrics on the NCC Project supports the needs of the technical and managerial staff. This paper describes the project, the functions supported by metrics, the data that are collected and reported, how the data are used, and the improvements in the quality of deliverable software since the metrics processes and products have been in use.

Burns, Patricia J.↗

NASA NTRS1986

Choosing a software design method for real-time Ada applications: JSD process inversion as a means to tailor a design specification to the performance requirements and target machine

The validity of real-time software is determined by its ability to execute on a computer within the time constraints of the physical system it is modeling. In many applications the time constraints are so critical that the details of process scheduling are elevated to the requirements analysis phase of the software development cycle. It is not uncommon to find specifications for a real-time cyclic executive program included to assumed in such requirements. It was found that prelininary designs structured around this implementation abscure the data flow of the real world system that is modeled and that it is consequently difficult and costly to maintain, update and reuse the resulting software. A cyclic executive is a software component that schedules and implicitly synchronizes the real-time software through periodic and repetitive subroutine calls. Therefore a design method is sought that allows the deferral of process scheduling to the later stages of design. The appropriate scheduling paradigm must be chosen given the performance constraints, the largest environment and the software's lifecycle. The concept of process inversion is explored with respect to the cyclic executive.

Withey, James V.↗

NASA NTRS2003

Modeling defect trends for iterative development

The Employment of Defects (EoD) approach to measuring and analyzing defects seeks to identify and capture trends and phenomena that are critical to managing software quality in the iterative software development lifecycle at JPL.

modeling defects metrics↗

NASA NTRS1998

Applying Simulation to the Development of Spacecraft Flight Software

We describe how the application of simulation and emulation to the lifecycle of spacecraft software can improve quality and aid in schedule compression cost reduction.

simulation↗

NASA NTRS1990

System testing of a production Ada (trademark) project: The GRODY study

The use of the Ada language and design methodologies that utilize its features has a strong impact on all phases of the software development project lifecycle. At the National Aeronautics and Space Administration/Goddard Space Flight Center (NASA/GSFC), the Software Engineering Laboratory (SEL) conducted an experiment in parallel development of two flight dynamics systems in FORTRAN and Ada. The teams found some qualitative differences between the system test phases of the two projects. Although planning for system testing and conducting of tests were not generally affected by the use of Ada, the solving of problems found in system testing was generally facilitated by Ada constructs and design methodology. Most problems found in system testing were not due to difficulty with the language or methodology but to lack of experience with the application.

Seigle, Jeffrey↗

DOE OSTI2016

Solar Asset Management Software (Final Report)

Ra Power Management (RPM) has developed a cloud based software platform that manages the financial and operational functions of third party financed solar projects throughout their lifecycle. RPM’s software streamlines and automates the sales, financing, and management of a portfolio of solar assets. The software helps solar developers automate the most difficult aspects of asset management, leading to increased transparency, efficiency, and reduction in human error. More importantly, our platform will help developers save money by improving their operating margins

14 SOLAR ENERGY↗

DOE OSTI2016

Final Report Ra Power Management 1255 10-15-16 FINAL_Public

14 SOLAR ENERGY↗

DOE OSTI2016

Solar Asset Management Software

14 SOLAR ENERGY↗

NASA NTRS2017

The NASA Analogy Software Cost Model: A Web-Based Cost Analysis Tool

This paper provides an overview of the many new features and algorithm updates in the release of the NASA Analogy Software Cost Tool (ASCoT). ASCoT is a web-based tool that provides a suite of estimation tools to support early lifecycle NASA Flight Software analysis. ASCoT employs advanced statistical methods such as Cluster Analysis to provide an analogy based estimate of software delivered lines of code and development effort, a regression based Cost Estimating Relationships (CER) model that estimates cost (dollars), and a COCOMO II based estimate. The ASCoT algorithms are designed to primarily work with system level inputs such as mission type (earth orbiter vs. planetary vs. rover), the number of instruments, and total mission cost. This allows the user to supply a minimal number of mission-level parameters which are better understood early in the life-cycle, rather than a large number of complex inputs.

Hihn, Jairus↗

DOE OSTI2015

Model of the Product Development Lifecycle.

While the increased use of Commercial Off-The-Shelf information technology equipment has presented opportunities for improved cost effectiveness and flexibility, the corresponding loss of control over the product's development creates unique vulnerabilities and security concerns. Of particular interest is the possibility of a supply chain attack. A comprehensive model for the lifecycle of hardware and software products is proposed based on a survey of existing literature from academic, government, and industry sources. Seven major lifecycle stages are identified and defined: (1) Requirements, (2) Design, (3) Manufacturing for hardware and Development for software, (4) Testing, (5) Distribution, (6) Use and Maintenance, and (7) Disposal. The model is then applied to examine the risk of attacks at various stages of the lifecycle.

He, Sunny L.↗

DOE OSTI2014

Workshop on Software Productivity for Extreme-scale Science, January 13-14, 2014, Hilton Hotel, Rockville, MD

While emerging extreme-scale computing systems provide unprecedented resources for scientific discovery, DOE’s scientific communities now face a crisis in extreme-scale scientific software productivity due to a powerful confluence of factors: ongoing disruptive changes in computer architectures and new frontiers in modeling, simulation, and analysis of complex multiscale and multiphysics phenomena. Research in mission-critical science and energy problems has become increasingly dependent on high-performance computing, but productivity in extreme-scale scientific application development has not kept pace. The principal issues are (1) a significant lag between extreme-scale hardware and algorithmic innovations and their effective use in applications, leading to poorly scaling codes; (2) obstacles in the combined use of independently developed software components; (3) lack of agile yet rigorous software engineering practices for high-performance computing; and (4) failure to consider the entire lifecycle of large scientific software efforts, leading to fragile, complicated application codes that are increasingly difficult to enhance.

97 MATHEMATICS AND COMPUTING↗