bluuebunny/crossref_metadata_2025 huggingface dataset:
Reactive Programming
Authors: Berry Gerard
Published: February 2015

A reactive system is a system that is in charge of maintaining a permanent interaction with its environment at a pace that is governed by this environment. A reactive program is a program that drives a reactive system. This comparatively recent unifying concept covers a number of domains that were considered as quite distinct in the past but bear actually more similarities than differences: real‐time process control, hardware and software controllers, communication protocols, systems and human–machine interface drivers, and signal processing. The priviledged but nonexclusive application field of reactive programming is that of embedded computing, where computers drive plants, transportation middles, house appliances, and ever more and more everyday's life objects. In these domains, it is clear that program quality and safety are very crucial concerns.

Reactive programming has always shown up to be a technically difficult area. Even small programs require considerable efforts to be specified, written, and debugged. It is easily seen that reactive programming has two essential requirements:
concurrency
and
determinism
. Concurrency is mandatory since the natural architecture of most reactive programs has the form of logically related but well‐individualized concurrent components, a structure that should be preserved to obtain good quality source code. Determinism means that a program placed twice in the same environment should react twice in the same way, a constraint that is clear in most of the aforementioned applications.
Software Reading Techniques
Authors: Shull Forrest
Published: February 2015

Software readingis defined as the process by which a developer gains an understanding of the information encoded in a work product sufficient to accomplish a particular task. Software reading is an important skill in software development, occurring potentially many times throughout a system’s life cycle, applied to a number of different work products for a number of different tasks. One example of a process that supports software reading is stepwise abstraction, a procedure by which sequences of steps in an algorithmic document are abstracted to descriptions of functionality at various levels. Stepwise abstraction helps a developer to understand a code document in order to complete a particular task, namely, checking whether it conforms to the specifications set for it.

In the current state of the practice, support for software reading is often not available or not used; developers may be taught how to write intermediate work products but rarely how to read and analyze them effectively. Instead, developers rely onad hocmethods or checklists to analyze documents. In anad hoc, or unstructured, reading process, the reader is not given direction on how to read, and The practical result is that software document reviewers build up skills in document understanding slowly, based on individual experiences acquired over time. Without a standardized process, training and skill development are difficult, individual practices vary greatly, and controlled improvement is not possible.

Software reading techniques address these problems. Asoftware reading techniqueis a series of steps for the individual analysis of a textual software product to achieve the understanding needed for a particular task. This definition has three main parts. They are individual analysis, series of steps, and a particular task. A reading technique is focussed on some specific task. Specific reading techniques that analyze software work product for the purpose of defect detection are discussed.
Real‐Time Languages
Authors: Kaisler Stephen H.
Published: February 2015

A real‐time language (RTL) is a programming language used to implement an information processing system that can respond to externally generated stimuli within a finite and specifiable delay. Real‐time languages are typically used to program embedded computer systems that interface directly to physical equipment and are dedicated to monitoring and operating that equipment in a larger information processing system. The type of stimuli, the length of the delay, and the type of response depend on the application context. A delay of 15 seconds may be acceptable in an ATM transaction, but intolerable when flying an advanced fighter such as the F‐18. Because the definition of “real time” varies so widely, the features of real time languages also vary widely.

Real‐time software is usually comprised of multiple processes that are executed concurrently and interact, where necessary, to synchronize on events and exchange information. Real‐time software must be extremely reliable, must be capable of responding to a wide variety of events with differing, but guaranteed, response times, and must be able to interface with a variety of nonstandard I/O devices as well as conventional peripherals. It is not sufficient to verify that real‐time software performs its function correctly, but that it does so in a predictable, timely manner.

To meet the requirements of real‐time systems, an RTL requires both conventional programming constructs such as abstract data types, structured and dynamic data types, and classical program control structures, as well as specific features to support real‐time programming (Young, 1982). To produce real‐time software with predictable timing properties, a real‐time language must provide, among other things, features for: specifying time constraints, estimating resource requirements, and providing predictable synchronization mechanisms. These features are discussed availability and the future of real‐time language systems are detailed
Recovery Blocks
Authors: Randell B.
Published: February 2015

It is normal to employ fault tolerance techniques for copying with the occurrence and the effects of anticipated hardware component faults, and mistakes by users and operators. In complex systems whose failures could lead to loss of human life or great financial loss, the fault tolerance strategies used may well also include ones aimed at coping with residual design faults. The systems and applications software are typically of far greater logical complexity than the hardware on which they are running, so such design fault tolerance is usually aimed at software faults, and at complementing the verification and validation efforts that have been used to try to minimize the number of faults present when the software is deemed operational.

The recovery block scheme was developed with the aim of facilitating the provision of software fault tolerance.

To this end the recovery block scheme provides a single coherent error recovery strategy.

Since its introduction the recovery block scheme has been the subject of experimental evaluations and now, increasingly, industrial application.
Software Maintenance
Authors: Pigoski Thomas M.
Published: February 2015

Software maintenance is a much‐maligned and misunderstood area of software engineering. Although systems have been maintained for years, relatively little is written about the topic. Funding for research is essentially nonexistent, and thus the academic researchers publish very little about software maintenance. Practitioners publish even less because of corporate fear of giving away the “competitive edge.” Whereas several books have been written specifically about software maintenance, only a few are suitable as textbooks. Further, periodicals address the topic infrequently.

This lack of publications contributes to the misunderstanding of software maintenance. This article attempts to provide a better appreciation of software maintenance by providing a historical perspective on maintenance and a discussion of current practices. Sections provide information which suggests that maintenance is more than fixing bugs or mistakes and is in fact performed prior to delivery of a software product. Finally, the article provides some insight into future directions of software maintenance.
Regression Testing
Authors: White Lee , White Lee , Leung Hareton K. N.
Published: February 2015

Regression testing is a testing process that is applied after a program is modified. It involves testing the modified program with test cases in order to reestablish our confidence that the program will perform according to the (possibly modified) specification.

In the development phase, regression testing may begin after the detection and correction of errors in a tested program. Regression testing is a major component in the maintenance phase where the software system may be corrected, adapted to new environment, or enhanced to improve its performance. Modifying a program involves creating new logic to correct an error or to implement a change, and incorporating that logic into an existing program. The new logic may involve minor modifications such as adding, deleting, or rewriting a few lines of code, or it may involve major modifications such as adding, deleting, or replacing one or more modules or subsystems. Regression testing aims to check the correctness of the new logic, to ensure the continuous working of the unmodified portions of a program, and to validate that the modified program as a whole functions correctly.

Many modifications may occur during the maintenance phase where the software system is corrected, updated, and fine‐tuned. Software maintenance is defined as the performance of those activities required to keep a software system operational and responsive after it is accepted and placed into production (FIPS, 1984). There are three types of modifications, each arising from different types of maintenance.Corrective maintenance, commonly called “fixes,” involves correcting software failures, performance failures, and implementation failures in order to keep the system working properly. Adapting the system in response to changing data requirements or processing environments constitutesadaptive maintenance.Perfective maintenancecovers any enhancements to the system, where the objective may be to provide additional functionality, increased processing efficiency, or improved maintainability.

During adaptive or perfective maintenance, new modules are usually introduced. The specification of the system is modified to reflect the required improvement or adaptation. However, in corrective maintenance, the specification is not likely to be changed, and no new modules are likely to be introduced. Most modifications involve adding, deleting, and modifying instructions. Many program modifications occurring during the development phase are similar to that of corrective maintenance, because the specification will not normally be modified due to a discovery of an error in the program.
Requirements Management
Authors: Davis Alan Mark
Published: February 2015

Requirements management is the discipline of elicitation, triage, and specification of the initial and evolving requirements (q.v.) for a system. Requirements management includes principles (e.g., general rules or tenets), techniques (i.e., step‐by‐step procedures or recipes), languages (i.e., the syntax and semantics with which one can represent requirements, whether formal or informal), and tools (i.e., pieces of software that aid in the enforcement or automation of the principles, techniques, or languages). Notice that the domain of requirements management spans both user needs (which exist within the problem domain) and the external behavior of the system to satisfy those user needs (which exist within the solution domain). The word “engineering” can be used to replace “management,” but the word “management” is more consistent with the common use of these terms.

Requirements management may be applied to (
1
) building an entire system at one time, (
2
) building a system incrementally, where each iteration is delivered to customers, and (
3
) building a system incrementally, where some of the iterations result in a build for internal purposes only. In all cases, the process of performing requirements management is identical, except for the obvious differences.

Requirements management may be applied to (
1
) a software system alone, (
2
) a software system composed of major software systems, or (
3
) a system composed of hardware and software. In the first two cases, it is often termed
software requirements management,
and in the last case, it is often termed
system requirements management.

This article focuses exclusively on requirements management for software‐only systems. In all cases, requirements management is usually the first development activity to be initiated by the development team. After all, it makes little sense to try to build something before you know what you want to build. Although requirements management is the first activity to be initiated, it rarely is completed before some design has transpired. Reasons for this include (
1
) some applications are being pursued solely to utilize a new architecture, so clearly the architecture is defined early; (
2
) prototypes) are often constructed to uncover new requirements; (
3
) new requirements can often be derived by observing the behavior of (a partial implementation of) the system; and (
4
) after “leaving” the requirements phase and moving on to design, return to requirements activities is inevitable whenever new requirements are learned or existing requirements are deemed impossible to meet.
Resource Estimation in Software Engineering
Authors: Briand Lionel C. , Wieczorek Isabella
Published: February 2015

This article presents a comprehensive overview of the state of the art in software resource estimation. We describe common estimation methods and also provide an evaluation framework to systematically compare and assess alternative estimation methods. Although we have tried to be as precise and objective as possible, it is inevitable that such a comparison exercise be somewhat subjective. We however, provide as much information as possible, so that the reader can form his or her own opinion on the methods to employ. We also discuss the applications of such estimation methods and provide practical guidelines.

Understanding this article does not require any specific expertise in resource estimation or quantitative modeling. However, certain method descriptions are brief and the level of understanding that can be expected from such a text depends, to a certain extent, on the reader's knowledge. Our objective is to provide the reader with a comprehension of existing software resource estimation methods as well as with the tools to reason about estimation methods and how they relate to the reader's problems.

The second section (on resource estimation) briefly describes the problems at hand, the history, and the current status of resource estimation in software engineering research and practice. The third section (on overview of estimation models) provides a comprehensive, although certainly not complete, overview of resource estimation methods. Project sizing, an important issue related to resource estimation, is then discussed in the fourth section (on sizing projects). The fifth section (on framework for com parison and evaluation) defines an evaluation framework that allows us to make systematic and justified comparisons in the sixth section (on evaluation and comparison effort estimation methods). The seventh section (on considerations influencing choice of estimating method) provides guidelines regarding the selection of appropriate estimation methods, in a given context. The eighth section (on typical applications) describes typical scenarios for using resource estimation methods, thereby relating them to software management practice. The ninth section (on future directions) attempts to define important research and practice directions, requiring the collaboration of academia and industry. This article then concludes by summarizing the main points made throughout the article.
Reuse
Authors: Braun Christine L.
Published: February 2015

Software development costs are a major factor in the world's economy. This situation is a result of systems becoming increasingly sophisticated (with software implementing most of the added functionality), while engineering salaries are rising and hardware costs are decreasing. Motivation to find more efficient and predictable ways to create software is growing annually.

Comparing the software and hardware industries is interesting. Hardware costs are going down not because hardware engineers are getting cheaper, but because of standardization on common parts, in other words,reuse. Is there a way to achieve the same benefits by practicing reuse in the software field? Hardware engineers today build systems from components that perform complex functions on a single chip, rather than depending on gate level design and wiring. Can software be built from more complex software components, rather than from individual lines of code?, this can be regulated as a “software components industry.”

Several trends in software engineering technologies have encouraged this interest in reuse. One of these is the increasing prominence ofobject‐orienteddesign and development. Object‐oriented methods encourage software engineers to design components around invariant objects—objects that have meaning outside the system and therefore might be usable by multiple systems. Another factor is the emergence of higher level programming languages and tools, for example, visual programming environments, that support principles of packaging and abstraction. These languages allow development of components with the cohesiveness and parameterization needed to make software more reusable.

These technological enablers, coupled with a growing need to control software costs, have made software reuse a major field of research and development. Its promises are great, but there are many open issues and challenges. This article summarizes many of the major ideas and developments in this growing field.
Risk Management in Software Development
Authors: Gemmer Art
Published: February 2015

Risk management's importance to software development is greater now than ever before. The importance stems from the growing role software plays in delivering value to customers. As we move to a knowledge economy, software embodies the knowledge that brings value. Software applications have become larger, more complex, more susceptible to attack and unanticipated interactions. They are being called on to solve problems for which solutions may not be possible; either the knowledge doesn't yet exist to solve the problem or a reliable solution doesn't exist (Charette, ; Neumann,).

This trend is coupled with a growing liability. Although Y2K was for most a nonevent, many people cried for accountability in the event of catastrophe and made elaborate preparations. This is especially true for software applications in the e‐commerce, banking, health, safety, aviation, and nuclear industries.

The volatility that drives risk in software development is now predominantly from outside the software development process. It comes from the business arena, not the software one. It is not enough to ensure requirements traceability or configuration control. In a knowledge economy, the basis for competition is knowledge and the delivery vehicle is software. Although this article focuses on software risk management, software risk management is not a standalone or unique process but must be integrated with other system, project and organizational management processes to be effective.

Software development risks can be categorized according to the domain of the application produced. Although the risks differ from domain to domain, the risks are systemic to developments within any particular domain.

The purpose of the risk management process is to identify risks and make decisions regarding them on individual projects. It is one of a variety of techniques software projects use to manage risk. Although the specific actions taken to manage these risks are specific to the risk, the process for identifying and making decisions to manage them must be systematic and requires three elements to make it effective.

Functional behavior is the key element in achieving effective risk management. Implementing and honing a repeatable process and making available adequate sources of knowledge, while necessary, cannot by itself change behavior. All three of these elements will be discussed relative to the process. In order to manage risk effectively, a formal process is required.
Software Safety
Authors: Hatton Les
Published: February 2015

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

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

The 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

Computer 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

The 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

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

The 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

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

The 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

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

Nuclear 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

The 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

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).
Software Reliability Engineering
Authors: Everett William W. , Musa John D. , Musa John D. , Everett William W. , Ackerman A. Frank , Wilson Geoffrey A.
Published: February 2015

Reliability is the ability to operate failure‐free. More specifically, it is defined as the probability of a product to operate free of failures for a specified period of time under specified operating conditions. This definition applies to products, services, systems, hardware, and also software. Reliability is a quality attribute that is highly valued by customers and users of products and services.

We need a consistent definition of reliability between software, hardware, and systems. This is so they may be combined to determine the reliability of a product or service as a whole delivered to a user. However, there are differences between hardware and software that affect how we analyze their respective reliabilities. These differences are described.

Software reliability engineering (SRE) assesses how well software‐based products and services meet users' operational needs. SRE uses quantitative methods based on reliability measures to do this assessment. The primary goal of SRE is to maximize customer satisfaction. SRE uses such quantitative methods as statistical estimation and prediction, measurement, and modeling. As the reliability of a product or service is highly dependent on operating conditions and the reliability of software is related to how the software is used, the quantitative characterization of the use of software is an integral part in SRE. This characterization of use of software is captured in an Operational Profile and is discussed.

Software engineering is a broader discipline of which SRE is a subdiscipline. Software engineering is concerned with all aspects of designing, implementing, and managing the development of software. Other aspects of software engineering include the economics of developing software and the interfaces between software, systems, and humans and with the practices and processes for ensuring the quality of delivered software. Software quality assurance (SQA) monitors the processes and practices for ensuring software quality to ensure they are being followed and that they conform to established industry norms.

SRE has been used on a wide variety of products and services. SRE is not limited by what software development methodology is used. There are no known theoretical or practical limits on its application except possibly on very small projects. Software under 1,000 source lines and possibly up to as high as 5,000 source lines may experience few operational failures. Analysis using few failure events results in large error bounds when estimating reliability. However, reliability estimation is only a part of SRE. The other parts of SRE such as determining the operational profile and using it to guide development and test are still useful for very small projects.