bluuebunny/crossref_metadata_2025_split huggingface dataset:
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

Abstract
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.
Software Requirements Engineering Methodology
Authors: Alford Mack 
Published: February 2015

Abstract

SREM is an acronym for software requirements engineering methodology and is also a shorthand name for the technology for specifying and designing systems resulting from a series of research efforts that started with SREM. The SREM approach is characterized by the following features:

The use of an executable graphic notation to describe system and software behavior (e.g., RNETs and FNETs).

The use of a user‐extensible element‐relation‐attribute (ERA) language to describe the various system requirements and design characteristics, including traceability and decisions.

The use of automated tools to accept the above information, perform static and dynamic consistency–completeness checking, validate the specifications by executing them, and generate required specification documents.

The definition of a method for using the language and tools described as a sequence of steps, each of which adds a specific subset of the ERA and executable information and then uses the tools to check a subset of the consistency–completeness conditions.

An intent to provide a smooth transition from system requirements and design through software requirements and design and testing.

The SREM technology was developed over a 25‐year period, with alternate periods of research, development, and prototype application to validate the concepts. Its research results were at the edge of the state of the art for more than 15 yr. It is unique in its breadth of coverage, and focuses on providing a smooth transition between the different phases of system design.
Test Automation
Authors: Fewster Mark 
Published: February 2015

Abstract

Test automation
generally means automated execution of test cases including automated verification of the test results. However, this is a rather narrow view. This term is more usefully taken to refer to any type of tool support of a testing activity. Tools that support testing activities are almost all computer programs that are generally referred to as test tools. The different types of test tools are outlined.

Almost any testing activity can be tool‐supported in some way, but this is not to say that the activity can be performed entirely by the tool or automatically. In most cases tool‐supported activities require some manual intervention. The main role of a testing tool is usually to support, not replace, a person's efforts.
This article discusses issues associated with most types of tool support for testing, but much of the later sections deal with issues that are most applicable to tool support for test execution automation, the most popular type of test automation.
Software Tools
Authors: Grundy John , Hosking John 
Published: February 2015

AbstractThe demand for computer software applications steadily increases as numbers of users, problem domains, and application areas grow the need for good tools to support the myriad of activities that occur during software development is thus greater than ever. This article provides an overview of current practice in software tool features and usage. It also surveys research work in the area of software tools, indicating recent and likely near‐future trends in tools development. A section outlines recent directions in software process evolution, product domains and people management. As different software tools are used throughout the software process for different activities, changes in processes, products and project organization have introduced a variety of new demands on tools and tool developers. A categorization of software tools aligned with software process activities is then presented, including examples of tools in the various categories, along with a brief explanation of common terms used to describe software tools. We describe key elements of the structure of software tools, ranging from repository and data management to multiple‐view presentation and editing. We then focus on the key issue of tool integration, outlining current approaches to integration, current research trends, and likely near‐future integration support in software tools. We describe various strategies for supporting collaborative work with different software tools, facilitating improved teamwork with tools. We review and discuss current research, practice, and likely trends in automated support in software tools, alleviating developers of tedious tasks and helping manage ever‐growing software complexity. We conclude with a summary of some important factors in successful tool development and deployment.
Space Systems
Authors: Keller T. W. , Rone Kyle Y. 
Published: February 2015

Abstract
A space system is created to operate in the environment of outerspace as opposed to a system which operates near the earth in the presence of the atmosphere. Compared to most places on earth, the space environment is extremely hostile to humans and to the systems humans build and use. Normal means of system support, such as ambient air‐cooling, are no longer viable and so more difficult, costly methods must be used. To ensure that a system remains in space for a reasonable time, it must either attain orbit or escape velocity. Very expensive launch systems must be developed to achieve the speeds necessary to attain orbit or escape velocity. Thus, a fundamental problem is encountered: the cost of launching each pound of a system into space is very high; therefore, components of space systems have always remained small and lightweight. Power on‐board is either supplied by heavy solar panels or electricity generators. The size and weight of these elements can be reduced by minimizing the power consumption of the space systems they support. Because space systems must operate in a remote environment where modifications are not easily made, space systems must be extremely reliable, to reduce the need for repair, and modular to make unavoidable repairs manageable. Safe operation is also required of these systems to protect humans and expensive hardware. These requirements and constraints combine to offer a daunting challenge to the space systems developer who must skillfully balance them against the needs of the user.
Other articles have thoroughly addressed the general problems facing software engineers and the practices established to solve those problems. The purpose of this article is to survey these unique problems applying to data‐processing systems designed to operate in the space environment. This discussion will also include current engineering solutions to those problems and will provide actual examples. An introductory overview of the history of space data‐processing systems will be followed by a discussion of space‐system design considerations including: hardware constraints, compilers and languages, communications and interfaces, software complexity and functionality, environmental factors, and remote maintenance. A discussion of quality assurance processes to “space qualify” data processing systems will then be followed by sections addressing unique aspects of: testing and simulation, autonomy, and problem diagnosis. The article will be completed with a perspective on future challenges facing the engineers of software systems for space applications.
Specification‐Driven Tools and Techniques
Authors: Cleaveland J. Craig 
Published: February 2015

Abstract
Specification‐driven tools (SDTs) translate specifications to products such as programs, documentation, tables, and test scripts. SDTs represent a large class of techniques that have independently evolved under a variety of names including application generators, program generators, 4GLs (fourth generation languages), automatic programming, lower CASE tools, and application‐oriented languages. SDTs increase productivity and quality and are most successful in programming areas that are well understood and repetitive such as databases, user interfaces, and translators. SDTs are an effective way to reuse software code and design. Unlike code reuse libraries, SDTs generate customized software that is not modified by the user. A typical SDT for building parsers from grammar descriptions is shown.
The productivity and quality of SDTs is achieved by two major factors: narrow domains and understandable specification languages. A “domain” is the area of applicability. General‐purpose programming languages are useful for very large problem domains.
The second major factor for increased productivity and quality of SDTs is the specification language. It must be significantly easier to understand than the generated code. It should be much shorter, should not contain unnecessary implementation details, and it should be understandable to nonprogrammers—ideally, the customer. However, specification languages are not necessarily simple. Example problem domains and tools for building SDTs are described.
Subdomain Testing
Authors: Hamlet Richard 
Published: February 2015

Abstract
In subdomain testing, the input domain of a program is conceptually divided into subdomains, each subdomain intuitively composed of input points that are “the same” in some sense. Systematic testing of the program is then organized around these subdomains. In the simplest scheme, a test set is required to include at least one point from each subdomain. The subdomains may be disjoint and exhaust the input space, in which case they constitute the equivalence classes of a partition in the mathematical sense, hence the name “partition testing.” However, in general, subdomains may overlap and some input points may appear in no subdomain.
In so‐called statistical testing, instead of requiring a test set to have at least one subdomain member, uniform random sampling within each subdomain is required.
Any systematic test method can be thought of as a subdomain method.
Software Technology Transfer, Diffusion, Adoption, and Implementation
Authors: Fowler Priscilla , Scacchi Walt 
Published: February 2015

AbstractSoftware technologytransferis the movement of a technology from one owner to another, typically by commercial transaction. This type of movement of technology ignores both the technology creation process and the process of its use after transfer. Thus, for a complete understanding of what happens when technology moves from one context to another, we also need to consider “diffusion of innovations” and “adoption” as well as “implementation” or “deployment”.Software technology transfer, diffusion, adoption, and implementation (STTDAI) cannot be defined without understanding first the maturity of the particular technology, and second, the point of view taken within these constituent transfer processes. Technologies mature as they move from research prototypes into products and make the transition into use within organizations and communities and by individuals. Thus, STTDAI plays a major role in the maturation process.There are three major life cycles of technology maturation: research and development (R&D), new‐product development, and technology adoption and implementation. Together, these three life cycles cover technology development, popularization within an intended market, and deployment, from the inception of a technology until its retirement. How software technology transfer, diffusion, adoption, and implementation work is best understood in the context of this composite life cycle.A simplified model of the software technology maturation life cycle is given. The model is described in terms of each subordinate life cycle, and the interactions among them.
Test Generators
Authors: Poston Robert M. 
Published: February 2015

Abstract
Many people think of automated software testing as executing or running test cases. Actually software testing involves three technical activities: creating, executing, and evaluating test cases. Creating test cases is the most essential activity in software testing, because all other testing activities depend on having test cases to run or evaluate.
Tools called test case generators can create test cases automatically. However, to do so, a test case generator needs a precise definition of a test case.
A test case is a set of information that contains

A unique identifier: a name that distinguishes this test case from all others

A list of actions (functions, processes, services, etc.) that this test case will exercise

A list of names and values for inputs to actions that this test case will exercise

A list of outputs that will result when this test case exercises actions

Item 3 is particularly important. A test case is hard to use unless it includes both names and values for all inputs (also called causes or stimuli). For example, if a test case provides the name of an input such as “valid telephone number” but does not include a value such as 911, the test case is incomplete. The tester must finish the test case by adding the telephone number—a simple enough job for one input. But suppose the input to the software under test is a file containing thousands of telephone numbers. Then the tester is confronted with creating and managing huge numbers of input values.
Test case generators can produce test cases, as just defined, at rates exceeding 300 test cases per minute. Considering that the average tester in the U.S. creates 30 to 300 test cases by hand in one month automated test case generators offer compelling productivity gains.
Test Management and Organization
Authors: Black Rex 
Published: February 2015

Abstract
Organizations choose (whether consciously or otherwise) to invest in quality in general, and testing specifically, because they expect the time, money, and care spent prior to releasing a system to pay dividends after the release. These dividends may come in the reverse form they are an improved reputation for quality with internal and external customers; lower post‐release maintenance costs, smoother, better‐understood, and more‐timely release cycles; increased confidence that mission‐critical operations will be performed properly; protection from lawsuits resulting from faulty systems are; in some cases, whole missions and even lives rescued from total loss
Testing is, therefore, a risk management exercise that helps the organization reduce the likelihood of bearing unanticipated future costs. This resembles insurance, except that the actuarial certainty that comes with pooling risk across large numbers of insured seldom applies when a handful of projects present make‐or‐break risks. With such high stakes involved, testing is an endeavor that deserves careful planning, crisp execution, a talented team, and significant resources.
A test effort is a subproject of a development or maintenance project, providing risk management services to various other teams, including project management, senior management, and executive management. As such, it must fit within the project and the organization logically, and in a way that promotes rather than retards the risk management functions it is set up to perform. The specific tests to be performed arise from the customers’ or business users’ reasonable expectations of quality. Once this is understood, the test manager can implement a test process, a test system, and a test team to perform these tests.
Ultrareliability
Authors: Musa John D. 
Published: February 2015

Abstract

Ultrareliability concerns functions for which failure entails exceptionally heavy costs, frequently including loss of life, resulting in a requirement for very low frequency of such failures. There is no clear dividing line between high reliability and ultrareliability, but the term ultrareliability generally is used to refer to failure intensities of less than

failures/hour (one failure per million hours). In order to give a physical feel to failure intensities, some common failure intensities and risks are noted. Note that the need for ultrareliability really does refer to
functions
rather than systems. An important distinction is to be made in regard to reliability of hardware and software components.

The expense, development time, and difficulties involved in building ultrareliable functions are such that we need to take a very realistic attitude in setting failure intensity objectives. It is also important that we separate functions by criticality and apply ultrahigh reliability objectives only to those functions that require them many have concluded that we therefore cannot certify ultrareliable software through testing. This is overly pessimistic.
Unified Process (
UP
)
Authors: Alhir Sinan Si 
Published: February 2015

Abstract
The Unified Process (UP) is a use‐case‐driven, architecture‐centric, iterative, and incremental software development process framework. The UP is broadly applicable to different types of software systems, including small‐scale and large‐scale projects having various degrees of managerial and technical complexity, across different application areas and organizational cultures. The UP leverages the Object Management Group's (OMG) Unified Modeling Language (UML), but may utilize any modeling language. The UML is an evolutionary general‐purpose, broadly applicable, tool‐supported, and industry‐standardized modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system‐intensive process.
Vienna Development Method
Authors: Bartley Michael 
Published: February 2015

AbstractVDM (Vienna Development Method) is a Formal Method that can be used for both the specification and development of software. It ismodel based, i.e., system behavior is defined by the construction of a mathematical model with an underlying state (data) and a collection of operations on that state. It is based on discrete mathematics, i.e., set theory and logic.The original VDM Specification Language (VDM‐SL) grew out of an attempt to define formal denotational semantics for the programming PL/1 at the IBM Laboratory in Vienna. The language and method have developed much since then through both academic research and industrial application.
Work Breakdown Structure
Authors: Servello Mark , Evans Michael W. 
Published: February 2015

Abstract

The
work breakdown structure
(WBS) consists of the defined set of tasks that must be accomplished and milestones that must be met on a project. Each task represents the creation or modification of a part of the product and may include items such as

Hardware and/or software products to be produced

Services and support tasks that must be accomplished

Procurement of equipment, tools, and facilities

Training of project personnel

The WBS defines the basis for planning the project, allocating work, and tasking resources in a coordinated and focused manner. The WBS serves as the mechanism for program scheduling and fiscal planning and provides the means to coordinate and control the diverse activities of a program, and to report on progress and status during the project.
The WBS subdivides projects into manageable units of work to be performed through the definition of various levels of hierarchy described and illustrated. The top of the hierarchy is the scope of the project. Each succeeding level in the hierarchy provides greater detail of the groupings and individual tasks to be performed. An example of a typical breakdown of levels in the hierarchical structure for a WBS is provided.

There are typically three different forms of the WBS that can be applied to define and allocate work in a software project: An
end‐item
or
product
WBS structure. A
functional
WBS and an
organizational
WBS structure. Creating and using WBS are detailed in other article.
Requirement
Authors: Davis Alan Mark 
Published: February 2015

Abstract

A requirement is an externally observable characteristic of a desired system. When trying to determine whether a candidate requirement is really a requirement, two criteria from this definition must be met: (
1
) it must be externally observable, and (
2
) it must be desired.
Externally observable
implies that there exists some means by which an observer (whether this is a human, machine, animal, or another system) can sense that the system satisfies the requirement from a perspective external to the system itself.
Desired
implies that some stakeholder (q.v.) wants to have that characteristic present in the system.

In addition to being externally observable and desired, there are numerous other characteristics that a requirement should exhibit and these are discussed.
Life‐Cycle Compression
Authors: Davis Alan Mark 
Published: February 2015

Abstract
Life‐cycle compression is the process of reducing the elapsed time for development from whatever it normally is to a shorter time. The expression “Internet time” generally refers to compression of the development life cycle from its usual elapsed time to 50% or less.
Companies attempt to compress their development life cycles because of competitive pressure. With the introduction of increased competition in every industry that incorporates software, and the wide variety of software development techniques in use today, no matter how long it takes you to build software, some other company will find a way to deliver a similar product faster.