bluuebunny/crossref_metadata_2025_split huggingface dataset:
Software Safety
Authors: Hatton Les 
Published: February 2015

Abstract
This is an age of rapidly increasing technological dependence on computer‐controlled systems. Given the relative and obvious unreliability of the humble but ubiquitous PC , the reader may wonder just how safe this trend might be. In this article, the author try to answer this question.
The safety of any system is reflected in its inability to do harm. A system is unsafe if harm can result from its operation and we then call this a safety‐critical system. If a system is safe only within certain operating bounds, then these must be explored and defined. Assessing the safety of a system can be a very complex process involving many factors including but not limited to reliability, design resilience, human interaction, and interactions with other systems. As systems evolve into ever more complex forms, this just gets harder.

From this we can see that safety is a property of a system
as a whole
. In this article, only systems are addressed. By definition, any computer‐controlled system contains software of one kind or another, and computer‐controlled systems and software‐controlled systems are treated as synonymous. The software contained therein might be embedded in the system in the form of
firmware
or may be readily accessible. From the point of view of safety, however, there is no effective distinction. Software‐controlled systems are essentially treated in the same way as conventional engineering systems such as bridges, but the scale of software‐controlled systems is now much larger and many of the associated risks turn out to be essentially unquantifiable at the current state of knowledge.

Computer‐controlled systems can take many forms. In some systems, software may contribute only a small part to the overall operation and the failure of the software component may not prejudice the overall behaviour at all. In such systems, we say that software is a
noncritical
component.

In contrast, for other systems, software may contribute a major part or even the entire behavior of the system. Failure of the software in such a system prejudices the overall behavior of the system, perhaps catastrophically. In these systems, we say that software is a
critical
component.

It is getting more and more difficult to assess the safety or reliability of software controlled systems. There are essentially five contributing factors: Size, Complexity, Coupling, Ubiquity, and Sensitivity. The influence of design and implementation and standardization initiatives are discussed.
Scripting Languages
Authors: Glas Michael 
Published: February 2015

Abstract
Scripting languages have been around since the early days of the UNIX operating system, circa 1970. One of the earliest examples of a scripting language is the shell script. Still in use today (with a variety of “flavors”—csh, bash, sh), it in essence allows programmers to string together a number of programs and commands in a text file and run them all at once (as compared to entering them one at a time on the command line).
Scripting languages are designed for different tasks than traditional (system) programming languages, and this leads to fundamental differences in the languages. System programming languages were designed for building data structures and algorithms from scratch, starting from the most primitive computer elements such as words of memory. In contrast, scripting languages are designed for “gluing.” They assume the existence of a set of powerful components and are intended primarily for connecting components together. In general, system programming languages are strongly typed to help manage complexity, while scripting languages are typeless to simplify connections between components and provide rapid application development. (In statically known types).
Security Models
Authors: McLean John , Schell Roger R. , Brinkley Donald L. 
Published: February 2015

AbstractThe termsecurity modelhas been used to describe any formal statement of a system's confidentiality, availability, or integrity requirements. In this article we focus on the primary use of security models, which has been to describe general confidentiality requirements. We then give pointers to security model work in other areas.Even if we limit ourselves to models of confidentiality, there are two related, but distinct, senses of the termsecurity modelin the computer security literature. In the more limited use of the term, a security model specifies a particular mechanism for enforcing confidentiality, calledaccess control, which was brought over into computer security from the world of documents and safes. In the more general usage of the term, security models are specifications of a system's confidentiality requirements and are not “models” at all in that they specify security requirements without describing any particular mechanism for implementing these requirements. These models specify restrictions on a system's interface (usually its input/output relation) that are sufficient to ensure that any implementation that satisfies these restrictions will enforce confidentiality. We consider access control models and interface models in turn after types are also descussed.
Computer Security
Authors: Kemmerer Richard A. 
Published: February 2015

AbstractComputer security is an area that is growing in importance as more business applications are being automated and more vital and sensitive information is being stored in computers. Almost daily one can read newspaper accounts of computer abuse. Stealing information from a computer is just like stealing goods from a warehouse, for information is a commodity. The primary difference is that the loss of information often goes unnoticed.The termcomputer securitymeans the protection of resources (including data and programs) from unauthorized disclosure, modification, or destruction. In addition, the system resources must also be protected (i.e., access to system services should not be denied). These computer security properties are usually referred to asconfidentiality,integrity, andavailability. More precisely:Confidentialityensures that sensitive information is not disclosed to unauthorized recipients.Integrityensures that data and programs are modified or destroyed only in a specified and authorized manner.Availabilityensures that the resources of the system will be usable whenever they are needed by an authorized user.The degree to which each of these three properties is needed varies from application to application and are discussed.
Smalltalk
Authors: Goldberg Adele , Deutsch L. Peter 
Published: February 2015

AbstractThe Smalltalk programming language currently available in the commercial and educational marketplace is the outcome of research dating from 1971. The original research project, carried out at the Xerox Palo Alto Research Center, was founded on the belief that computer technologies represented the key with which we could improve technology‐mediated communication among people. The goal was to support both business and personal information exchange and processing needs. Project activities focused on finding new ways in which to organize information stored in a computer, and to allow end users more direct access and manipulation of this information. There are a number of commercial products that deliver programming tools and libraries for the Smalltalk‐80 language. This article documents the language and basic system components that are thede factostandard; it also identifies additional aspects of the commercial offering provided by the original researchers. Notably, the approach taken by this group aimed to provide applications developers with portability across multiple industrial standards. This was accomplished by identifying usefully reusable interfaces.The result of all this is that the Smalltalk‐80 systems today that resulted from the original Xerox work are not bound to a single proprietary hardware and software base. Rather, they provide the applications developer with the most portability of any programming environment of comparable power.
Software Development Folder
Authors: Baker Emanuel R. 
Published: February 2015

Abstract

The use of software development folders began at TRW in the early 1970s on a project known as the
Site Defense Program
. This program began as a development effort for a tactical Anti‐Ballistic Missile System. The system was effectively an unmanned one, and relied quite heavily on software for all the mission functions. Development of the software for the system involved a staff of several hundred people. With such a major software development effort, management of that effort became an important consideration. There were considerations that entered into the picture of management visibility into the effort, support for the production of massive amounts of design documentation, and support for the maintenance of the software. Many innovations in managing software development were introduced during this effort. One of these innovations was the
unit development folder
(UDF), which is a particular form of a development notebook.

A method was needed for tying together unit development schedules, milestones, and the products of that effort in a highly visible form. The UDF was such a device.
The UDF was intended as an informal document; it was not intended to be a deliverable document to the customer. The intent was for it to be a tool that the developer could use to maintain a current status of the development of a unit of software. A UDF was generally organized around a single compilable or assemblable unit of software. The content of the UDF was organized in a way that it provided all the information necessary to evolve the design for the unit from the requirements allocated to it, code it, and test it. The format for the content of the design section was structured such that it and the source‐code listings contained in the UDF could migrate, in toto, into the deliverable design documentation for the entire application under development. The UDF cover pages included a schedule for each section showing the due date and the actual completion date, as well as the date that the content of that section was reviewed for technical adequacy. Consequently, the actual status of the development effort for the unit could be ascertained.
Because of the great utility of the development folder concept, a requirement for defense contractors to implement it was specified in DOD‐STD‐2167. The SDF concept is well established in the defense community use in non‐defense sector is rare.
Software Development Library
Authors: Baker Emanuel R. 
Published: February 2015

AbstractThe software development library concept is defined as “A software library containing computer readable and human readable information relevant to a software development effort”. It is closely linked to the practice of configuration management, but is seldom considered to be a part of the configuration management process. Many, but not all, of the items contained in the software development library are under configuration control. In many respects, the software development library can be used as an arm of the configuration management function as an adjunct to the release process. The definition of the software development library that was contained in DOD‐STD‐2167A alluded to that notion by noting (in part) that it “provides storage and controlled access to software and documentation in human‐readable form, machine‐readable form, or both”. When MIL‐STD‐498 superseded DOD‐STD‐2167A, it also specified the need for a software development library “to facilitate the orderly development and subsequent support of software”. The Capability Maturity Model (CMM), version 1.1, identifies the need for a “configuration management library system,” specifying a more explicit relationship to configuration management.
Software Engineering Environments
Authors: Adomeit Reinhard , Deiters Wolfgang , Schülke Frank , Weber Herbert , Holtkamp Bernhard , Rockwell Robert 
Published: February 2015

Abstract

A software factory is meant to be capable of providing computer support for the coordinated work of software developers in large software development projects. The term
software factory
hence denotes a number of things: people and their respective roles in software development; computer supported tools and their combined use in software development; and a co‐ordination process model to guide people in their proper use of tools and in their proper joined work integration as depicted below.

Recent developments have led from closed environments, comprising fixed sets of tightly coupled tools for specific phases, to open environments that enable the plugging of new tools as the requirements evolve.
To cope with this new dimension in CASE technology, standards organizations intend to support the effort with reference models;
The concepts presented in this article have been primarily developed in the Eureka Software Factory (ESF) project. This article hence carries the flavor of that project in the way it introduces software factory concepts and in the way it explains these concepts in the larger context of computer‐aided software development.

Computer support in a software factory will be provided by a software system that is called
factory support environment
(FSE). In order to support software development in the manner outlined above, the FSE is needed to provide a number of integration services. FSE integration services will be explained first by introducing a conceptual view of a software factory and later on as an architectural view. The conceptual view, called the software factory core, introduces a number of integration stages: interworking, interaction, interoperation, and interconnection. The architectural view introduces the mechanisms that support integration at the respective stages.
Software Engineering in Aviation
Authors: Ferrell Uma D. , Ferrell Thomas K. 
Published: February 2015

AbstractThe Wright brothers' first flight took place in 1903, and for the next 60 years flight was purely a mechanical activity. This all changed in the early 1960s, when computers first began to find their way onto airplanes. The first onboard computers were hybrid electromechanical devices and made use of very specialized and limited instruction sets. There was a substantial lag between the appearance of digital technology in military aircraft and those flown in civilian applications. Although many people view aviation as an extremely high technology field, there is often a lag in technology adoption, particularly in the airborne segment of civil aviation. This lag is the result of conservatism due to safety concerns as well as a need to constrain both the weight and the cost of onboard systems.While slow to embrace the digital age, aviation‐related applications of software engineering are now at the forefront of this new science. Software applications are now found in all phased of aviation and include among the many, aircraft design, flight safety, air traffic control, maintenance, etc. Ever greater levels of automation onboard aircraft and in ATC systems require highly complex designs while demanding the utmost reliability and dependability of the software and the hosting hardware. Time and experience has shown that such reliability is the result of disciplined, well‐planned, thorough development processes. Current regulatory guidance for airborne systems containing software invokes DO‐178B/ED‐12B as the design assurance standard of choice to ensure safe software. Where software blends with hardware to produce firmware in the form of application‐specific integrated circuits and programmable logic devices, a new standard, DO‐254/ED‐80, has been introduced to extend design assurance to this area of software engineering for airborne systems.The software engineering approaches and techniques discussed here are a result of ongoing debate and consensus among the industry, regulators, and researchers. There is much engineering judgment in the techniques described, although there is no empirical basis or measurement of how best these techniques can eliminate safety‐related problems. Models have been developed to predict the latent fault density by correlating the maturity of the development process. Such models have not yet been applied and tested in the aviation industry. It should be noted that as the amount of software has steadily risen in commercial aircraft, the fatal accident rate has steadily fallen over the same time period. While a direct cause–effect relationship has yet to be established between the design assurance approaches discussed in this article and overall system safety, the trends provide significant confidence in our modern aerospace infrastructure.
Software Engineering Standards
Authors: Moore James W. 
Published: February 2015

Abstract
Although not a recognized engineering profession, the discipline called “software engineering” is evolving toward professional acceptance. One element of this evolution is the creation of a body of standards for the responsible practitioners. This article describes those standards.
The standards described in this article have been developed by Standards Developing Organizations (SDOs) operating on the principles of consensus development. The community of consensus varies, though. For example, the Institute of Electrical and Electronic Engineers (IEEE) generally develops its standards by achieving a consensus of technical professionals self‐selected from the membership of the organization. On the other hand, international standards are formed by a consensus of “national bodies,” representatives of nations who cast ballots presumably representing national interests.
Nearly all of the standards discussed in this article are intended for voluntary adoption; that is, an organization makes its own decision, without coercion, to adopt the standard. (This contrasts with regulatory standards, imposed by processes similar to law, and mandated stadards, such as military standards, required as a precondition of doing business with a dominant customer.) Organizations adopt voluntary standards because they improve their products, or improve the perception of their products in a competitive marketplace. Alternatively, the standards may improve the organization's business processes, allowing them to make their products more cost‐effectively.
Examples of benefits that standards may provide are given.
Software Engineering Standards in the Nuclear Power Industry—Safety‐Related Applications
Authors: Harauz John 
Published: February 2015

AbstractNuclear power is very much an international industry. U.S., Canadian, and European vendors are actively involved in the deployment of modern nuclear reactors (including I&C systems) in Asia. I&C systems are routinely delivered across national boundaries; for instance U.S. designed systems have been implemented in Czech Republic, Ukraine, and South Korea; German designed systems have been implemented throughout Europe and proposed for the United States; Canadian designed systems have been installed in Canada and South Korea. The Canadian software engineering technology for safety critical software has been considered for adoption in the development of new I&C safety‐related systems outside of Canada. Japanese I&C systems have proven reliable and should attract wider interest.The global nature of nuclear power points to the strong need for consistency in international sets of nuclear and other standards in addition to consistent approaches to licensing such systems. The application of standards in the nuclear industry is a nontrivial exercise. Many standards organizations worldwide develop standards that affect nuclear I&C systems. Developing a system in one country to one set of standards is no longer sufficient. As such systems cross national boundaries, they need to demonstrate conformance to more than one set of standards and must be licensable in the country of implementation.There is a broad consensus on general principles and approaches in the standards, and national licensing approaches are converging. However, there remain a number of specific issues on which consensus is still outstanding. Examples are the benefits to be gained from the use of formal methods, how to quantify the benefits from applying diversity principles to software, methods for measuring and achieving software reliability and requirements, and methods for the validation of transformation tools and of their output. As technology advances, issues of concern today may be solved, or new issues may arise. Nuclear industry standards and regulatory criteria will have to be periodically updated to keep pace with new international standards, increasing regulatory rigor with respect to software, fast‐paced computer technology advances, and experience gained, both within and outside the nuclear industry, for safety‐related computer‐based I&C systems.
Software Factory
Authors: Cusumano Michael A. 
Published: February 2015

AbstractThe story of the “software factory” within the field of software engineering is about how companies have attempted to push forward the state of programming practice in order to move beyond loosely organized craft or job‐shop modes of operation that treated each project as unique, to a more structured process and organization for multiple projects. Factorylike approaches have tended to emphasize standardization of development methods and tools, systematic reuse of program components or designs, some divisions of labor and functional departments, and disciplined project management, as well as product quality control. Many firms, led by IBM in the United States, have introduced these and other concepts for large‐scale programming operations but in varying degrees. This discussion focuses on the specific origins of the term “factory” as used in software and the histories of several companies that have explicitly used this term to describe their approaches to managing software development: System Development Corporation (SDC) in the United States, and Hitachi, Toshiba, NEC, and Fujitsu in Japan. The latter part of this article also includes a brief discussion of other factorylike efforts in the United States and Europe.
Software Productivity Center Inc.
Authors: Strigel Wolfgang 
Published: February 2015

Abstract
Software Productivity Center Inc. (SPC) was formed in 1992 as a nonprofit organization promoting the use of best practices and processes to increase the efficiency, reliability, and predictability of the software development process. The SPC is located in Vancouver, BC, Canada. Its clients are situated around the world with the majority in the United States. The goal outlined in the original business plan was for the center to become self‐sustaining in five years. It reached this and privatized in 1997.
SPC has a few attributes that set it apart from other leading centers for software process. SPC has a business perspective. SPC advocates best practices that will have the greatest initial impact on the success of the business, while helping to put a structure in place to ensure ongoing learning and advancement of the organization and its staff.
SPC has over 100 member companies that enjoy benefits such as discounts on training and products, free monthly seminars, and advice and information from SPC experts. Interaction with these member companies ensures SPC stays current with the challenges and issues facing software organizations each day. Member companies also benefit from SPC's affiliation and participation in international organizations such as the International Organization for Standardization (ISO standards), The Institute of Electrical and Electronics Engineers, Inc. (IEEE), and the Project Management Institute (PMI).