bluuebunny/crossref_metadata_2025_split huggingface dataset:
Rapid Prototyping
Authors: Luqi  , Shing Man‐Tak , Luqi  , Yeh Raymond 
Published: February 2015

Abstract

Prototypes facilitate the requirements phase for any type of software if the requirements have changed from the previous version, which is usually the case. Prototypes can demonstrate system scenarios to the affected parties as a way to (
1
) collect criticisms and feedback for updated requirements, (
2
) detect deviations from users' expectations early, (
3
) trace the evolution of the requirements, (
4
) improve the communication and integration of the users and the development personnel, and (
5
) provide early warning of mismatches between proposed software architectures and the conceptual structure of requirements.

The benefits of prototyping are widely accepted. The main incentive for using prototypes is economic—scale models and prototype versions of most systems are much less expensive to build than are the final versions. Prototypes should therefore be used to evaluate proposed systems if acceptance by the customer or the feasibility of development is in doubt. The need for software prototyping has become more urgent as systems being developed have grown more complex, are more likely to have requirements errors, and are more expensive to implement. Particularly, in real‐time applications where severe time constraints impose more challenges, the use of prototypes helps to describe the requirements in a clear, precise, consistent and executable format.
Prototyping is a class of software development methods that use software prototypes of the envisioned system. A prototype is an executable model of a proposed system that accurately reflects a chosen subset of its properties, such as display formats, computed results, or response times. Prototypes are useful for formulating and validating requirements, resolving technical design issues, and supporting computer aided design of both software and hardware components of proposed systems. Rapid prototyping refers to the capability to create a prototype with significantly less effort than it takes to produce an implementation for operational use. Rapid prototyping usually implies some degree of automated code generation.
Reactive Programming
Authors: Berry Gerard 
Published: February 2015

Abstract
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

AbstractSoftware 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

AbstractA 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

Abstract
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

AbstractSoftware 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

AbstractRegression 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

Abstract
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

AbstractThis 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

AbstractSoftware 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

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