Search

17 USC 105 interim-entered record; under review. The article of record as published may be found at http://dx.doi.org/10.1109/MC.2021.3064435 Hackathons have been around for decades. This article is a primer on what constitutes a hackathon, how hackathons have evolved, and why it can be advantageous to participate in and sponsor hackathons. U.S. Government affiliation is unstated in article text.

The article of record as published may be found at https://doi.org/10.1109/MC.2020.2983529

The Fifth Workshop on Software Assessment was held in conjunction with the IEEE Sixteenth International Symposium on Software Reliability Engineering. The workshop serves as an annual forum for practitioners and educators to discuss software assessment. This document contains the proceedings of the workshop.--p. i.

Achieving what is often termed software trustworthiness has been an elusive goal, in part because of the lack of a clear understanding of why we sometimes succeed but often fail to produce trustworthy software. In order to better understand the challenges the United States faces in achieving the goal of producing and acquiring trustworthy software systems and products, a workshop on the subject of trustworthy software was held April 8-9, 2004 in Monterey, California. The results of the workshop are documented in this report and intended to be used as input to a national research and development (R&D) agenda on software trustworthiness.

The field of testability is an active, well-established part of engineering of modern computer systems. However, only recently have technologies for software testability began to be developed. These technologies focus on accessing the aspects of software that improve or depreciate the ease of testing. As both the size of implemented software and the amount of effort required to test that software increase, so will the important of software testability technologies in influencing the software design process...

This paper presents a dynamic technique for predicting the effect that a "location" of a program will have on the program''s computational behavior. The technique is based on the three necessary and sufficient conditions for software failure to occur: (1) a fault must be executed, (2) the fault must adversely affect the data state, and (3) the adverse effect in a data state must affect program output. In order to predict the effect that a location of a program will have on the program''s computational behavior, the following characteristics of each program location are estimated: (1) the probability that a location of the program is executed, (2) the probability that a location of the program noticeably affects the program state created by the location, and (3) the probability that the data states created by a location affect the program''s output. With estimates of these charactistics for each location in a program, we can predict those locations where a fault can more easily remain undetected during testing, as well as predict the degree of testing necessary to be convinced that a fault is not remaining undetected in a particular location.

Legislation has not kept up with the many innovation leapfrogs that characterize computing technology. The recent legal tangle between the US Federal Bureau of Investigation and Apple about installing back doors in iOS for surveillance brings concerns about sensing, surveillance, privacy, security, secrecy, communication, and trust to the forefront of users' minds.

This thesis addresses software evolution from the perspective of standards interoperability. We address the issue of how to apply contemporary software safety assurance standards to legacy safety-critical systems, with the aim of recertifying the legacy systems to the contemporary standards. The application of RTCA DO-178B Software Considerations in Airborne Systems and Equipment Certification to modified legacy software is the primary focus of this thesis. We present a model to capture the relationships between pre- and post-modification software and standards. The proposed formal model is then applied to the requirements for RTCA DO-178B and MIL-STD-498 as representative examples of contemporary and legacy software standards. The results provide guidance on how to achieve airworthiness certification for modified legacy software, whilst maximizing the use of software products from the previous development. http://archive.org/details/standardsinterop109452985 Approved for public release; distribution is unlimited.