bluuebunny/crossref_metadata_2025_split huggingface dataset:
Assembly Language
Authors: Lacher Karl P. 
Published: February 2015

Abstract
Assembly language is a generic term that refers to a whole class of computer programming languages that are specific to particular computers or processors. The assembly language for a specific computer is derived from its machine language. An assembly language uses mnemonic abbreviations to facilitate the writing of computer programs. It is common to use the hardware platform on which it is implemented, when referring to a specific assembly language.

Assembly language is limited to a basic set of operations that do not easily lend themselves to higher levels of abstraction. There are four basic types of operations in assembly language:

Loading data from memory and storing data to memory

Addition of two data items

Comparison of two data items

Jumping from one location to another

there are three major advantages to programming in assembly language versus high level language. They are speed, control, and efficiency in memory use. The decision of whether to use a high level language versus assembly language will be an evaluation of the tradeoff between higher productivity in a high level language and the speed, control, and efficiency advantages of assembly language.
C++
Authors: Stroustrup Bjarne , Koenig Andrew , Moo Barbara E. 
Published: February 2015

AbstractC++was originally designed to combine Simula's facilities for program organization with C's efficiency and flexibility for systems programming. It later grew to include facilities for generic programming and an extensive library of algorithms and data structures.C++was originally intended for systems programming projects such as operating systems, network simulators, compilers, CAD/CAM systems, user interfaces, and graphics systems, as well as for the multitude of minor tasks traditionally written in C. It is a general‐purpose programming language that, in addition to systems applications, is extensively used for scientific computation, financial applications, embedded systems, realtime control, and other applications.C++started as a part‐time research project in 1979 and has, by 2000, grown to spawn a tools and library industry supporting millions of C++programmers. Originally designed by Bjarne Stroustrup in AT&T Bell Laboratories, C++became an ANSI and ISO standard in 1998.Compared to other languages that support object‐oriented programming, C++'s strengths include efficiency, a more expressive type system, and better facilities for interoperation with code written in other languages.The main features of ISO standard C++are given. C++use has grown dramatically since its first commercial release from AT&T in 1985.C++is available on essentially all general‐purpose computing systems from PCs to supercomputers. It is not possible to count the number of C++programmers accurately. Estimates vary between 1.5 million and 5 million.
Case
Authors: Chikofsky Elliot , Norman Ronald 
Published: February 2015

Abstract
Computer‐aided software engineering (CASE) is both a field of study and a marketplace. As a field of study, it is the collection of research and development over many years in software development management, methods, environments, and software tools. In general terms, CASE is the industrialization of software engineering techniques and computer technology to improve and automate the practice of information systems development. It is an integration technology that incorporates software development techniques, tools, and approaches into common and consistent frameworks. CASE draws on technologies from computer‐aided design, software engineering, operating systems, database, networking, and many other computer disciplines. Thus CASE is not principally a field of new invention. Rather, it is a field of application, integration, and synthesis.

As a marketplace, CASE represents a diverse set of products and services for software development and systems integration. The acronym
CASE
is used as an umbrella for a wide variety of claims regarding software tools and software development productivity. Definitions of CASE are given. CASE evironments, automation of analusis, computer‐supported collaboration, apportunities for quality engineering, maintenance and reengineering are discussed.
Software Certification
Authors: Voas Jeffrey 
Published: February 2015

Abstract

Certification is simply a process that validates conformance to an expectation or standard. Demonstrating that software was produced in a particular manner is probably the easiest type of certification to offer. (See

.) Software standards exist that define how software is to be developed in order to provide increased confidence in the quality of the software, particularly in government regulated industries (medical, avionics, nuclear, manufacturing control). The problem, however, is that most of these standards define processes that must be employed during development and testing without addressing how the software will behave or interoperate with its environment. Demonstrating that the software will behave in a certain manner or interoperate in a certain way is far more difficult than demonstrating that the software was developed and tested in a particular way. The reason for this is because software is non‐physical, thus making quality difficult to assess, measure, and evaluate.

This article includes information on the state of the practice today, the benefits of knowing what process a software developer/publisher uses, and the certifying of the software itself.
Chief Programmer Team
Authors: Baker F. Terry 
Published: February 2015

Abstract

The Chief Programmer Team organization and methodology are aimed at improving software quality and manageability. It was conceived in the late 1960s as a response to increasing cost and schedule problems in the development of large software systems, primarily due to the inability of the software development methods of the time to cope with the greater levels of complexity such systems required. The
chief programmer
would be the team's leader, a highly skilled programmer personally resposible for all aspects of developing a substantial programming project. The
backup programmer
would be an assistant chief programmer.
Cleanroom Software Engineering: Developing Software Under Statistical Quality Control
Authors: Mills Harlan D. , Linger Richard C. 
Published: February 2015

Abstract
Cleanroom software engineering is a theory‐based, team‐oriented engineering process for developing and certifying very high quality software under statistical quality control. (The name “Cleanroom” was chosen in analogy to the precision engineering of hardware cleanrooms.) Cleanroom software engineering methods include box structure specification and design, function‐theoretic correctness verification, incremental development, and usage‐based statistical testing for certification of software fitness for use. Cleanroom teams are organized into specification, development, and certification (testing) roles. The Cleanroom process originated in IBM in the mid‐1980s to bring engineering rigor to software development. Cleanroom software engineering has been applied with excellent results in a variety of system developments, and continues to evolve as an engineering technology.
Capability Maturity Model Integrated
Authors: Menezes Winifred 
Published: February 2015

AbstractThe Capability Maturity Model Interation (CMMI) is an integrated model that can be used as a reference model by organizations wishing to better control their product development processes. Although the term “product” is most often used, the scope of the model is the development of both products and services. Organizations can choose the combination of disciplines—systems engineering, software engineering, concurrent engineering (which is a set of practices and an environment that facilitate interdisciplinary team work within projects), or acquisition, as well as the architectures—staged or conti nuous—that best suit their culture and business needs.The basic elements of the CMMI are practices, the activities that are performed when developing a product or service, as well as the activities needed to ensure that the practices are effective, repeatable, and lasting.Related practices are grouped in process areas (PAs). Practices that are unique to a process area are calledspecific practices. Practices geared to institutionalizing the process are calledgeneric practices. These practices are the same in all process areas.Each process area has a number of goals that describe the outcomes expected from an effective implementation of the corresponding practices. The process areas are organized in either of two model architectures, calledrepresentations—the staged or the continuous.This article describes the purpose and expected outcomes of each process area (PA). Since the staged and continuous representation orders the PAs differently, they are presented in alphabetical order. The actual placement in both the staged and continuous representation is also provided. The section starts with the process areas for the core model, i.e., the CMMI for systems engineering and software engineering. The modifications and additions to for IPPD and subsequently Acquisition are then discussed.
COCOMO
Authors: Chulani Sunita , Ferens Daniel V. 
Published: February 2015

AbstractThis article introduces the reader to the constructive cost model (COCOMO) II—a well‐known model used in software cost and schedule estimation. First, the background of the model is presented, tracing the history of COCOMO from its inception to the present time. Second, a detailed description of COCOMO II is presented, including inputs and outputs, internal algorithms, and calibration results. Third, some of the major differences between COCOMO 81, Ada COCOMO, and COCOMO II are described. Fourth, some currently available computerized editions of COCOMO II are briefly discussed. Finally, an independent evaluation of COCOMO II is presented. Although this article cannot provide all the information required to understand thoroughly or use COCOMO II, it will give the reader a basic comprehension of the model and its capabilities.
Compiler Portability
Authors: Burkhart Helmar 
Published: February 2015

Abstract

Translators for modern high level languages are among the most complex software components in daily use. Because software development costs are high, particular efforts are necessary to improve their portability. The basic two fold structure of a compiler has language‐oriented parts (scanner, syntax checker, semantic analyzer) and it has architecture‐oriented parts (code generator, code optimizer). When porting a compiler from system A—the host system, to system B—the target system, the architecture‐oriented parts cause significant portability problems if A and B differ. Compiler portability problems can be classified under the following two headings:
machine architecture dependencies
and
operating system dependencies
.

Comparing these two types of dependencies for both host and target system, four porting scenarios are identified. Same machine architecture, same operating system: Different machine architecture, different operating system: Different machine architecture, same operating system Same machine architecture, different operating system.
There is a small set of portability techniques that the user should be aware of. The final choice is mostly dictated by the run‐time efficiency of the expected program. Even for complex software components such as compilers, there is a potential for getting a software tool that consists of up to 95% reuseable source code.
Computer–Human Interaction
Authors: Bisantz Ann M. 
Published: February 2015

AbstractComputer–human interaction (CHI) [also termed human–computer interaction (HCI)] is concerned with the analysis and design of the interaction between humans and the computer systems they use. A goal of computer–human interaction is to purposefully design aspects of the computing system so that it can be used in an efficient, effective, and error‐free manner by people to support their tasks and goals. As such, CHI is concerned not only with the design of usable interfaces between the user and the computer system but also with the provision of appropriate and complete functionality necessary for users to accomplish the tasks they set out to do with the computer system. Thus, computer systems must be designed to be both usable, and useful.CHI is interdisciplinary in nature, having historical roots and/or current practitioners in the fields of computer science, human factors and ergonomics, psychology, sociology, anthropology, and industrial design the issues and guidelines described here are applicable to design of Web sites and pages as well as more traditional software systems, the guidelines and discussions specific to Web usability can be found in the refernece.This article describes theoretical perspectives on CHI, presents design issues regarding the computer‐human interface, describes individual characteristics of users, summarizes the methods relevant to designers of computer systems, and discusses issues specific to the design of help systems and user documentation.
Concept of Operations
Authors: Thayer Richard H. , Bjorke Per 
Published: February 2015

Abstract
Computer systems programming was first developed by those expected to benefit from the system, i.e., the “users.” Therefore, the need to communicate system “requirements” was minimal. As the computer industry developed, hardware became increasingly more complex, powerful, and extensive, resulting in an increased demand for computer software. Therefore, programming became the purview of separate organizations specializing in software development. It is generally accepted that difficulties in discovering and documenting software requirements has become the major source of software development problems.

Software engineering was introduced as a method of applying a more rigorous approach to the development of computer systems. Although software engineering has many facets, the basic components of software engineering were and still are
software requirements, software design, implementation
(
coding
), and
testing
. As the field matured, many of the simpler software engineering components became engineering fields in their own right, for example: software requirements engineering, configuration management, software quality assurance, and project management.

In turn, software requirements engineering consists of
requirements elicitation, requirements analysis, requirements specifications, requirements verification
, and
requirements management
.

Software requirements elicitation is the process through which the acquirers (customers, buyers, or users) and suppliers (developers or contractors) of a software system discover, review, articulate, and understand a requirement.
Concept of operations
(
ConOps
)
analysis and the ConOps document are the premier tool of the requirements elicitation procession
.

Concept analysis and development of a ConOps document helps assists users and acquirers with the clarification of user needs and requirements in addition to easing the problems of communication among users, acquirers, and developers. ConOps provide a bridge from user needs and acquirers requirements to the system development process. Guidelines for concept analysis and development of a ConOps document are presented.
Concurrent Systems Design
Authors: Gomaa Hassan 
Published: February 2015

Abstract
A characteristic of all concurrent systems is that of concurrent processing; that is, many activities occurring simultaneously whereby, frequently, the order of incoming events is not predictable. Consequently, as concurrent systems deal with several concurrent activities, it is highly desirable for a concurrent system to be structured into concurrent tasks (also known as concurrent processes).
This article starts by providing an overview of concurrent processing concepts. In the next section, run‐time support for concurrent tasks is briefly discussed. With this background, an overview of a design method for concurrent systems, including distributed and real‐time applications, is given. The COMET method integrates object‐oriented and concurrent processing concepts, and uses the Unified Modeling Language (UML) notation.
Software Configuration Management
Authors: Berlack H. Ronald 
Published: February 2015

Abstract
Configuration management is a discipline that governs the identification, control, status accounting, audit, and interface of a given software product. It is one of the many processes that occur within an engineering development environment in which several engineering, software, and manufacturing process are performed concurrently.
Configuration management (CM) is a process that provides lines of communication within a software programming enmity during the design, development, build, test, and delivery of a software product. A configuration management activity may be an individual or group designated by an entity's management to ensure that all the people participating in the software program/project know what is being designed, developed, built, tested, and delivered. In the end these same people and the ultimate users have to know what was built, tested, and delivered so that the software product is used as intended and can be supported and maintained in its environment.
The CM activity interprets a customer's design and development requirements and ensures that these requirements can be traced from the initial implementation of the software to the final software product. As changes occur, the CM activity ensures they are managed in a cost‐effective and timely manner.
The successful performance of a CM activity requires early involvement in the development phases, early planning for support and maintenance, and assignment of the necessary authority and resources to implement the CM process on a software program or project. Success is enhanced if the organizational entity has designated an overall focal point for the promulgation of CM policy and procedure or standards CM planning, documented in a CM plan, providing the basis for the project's members understanding of their role in the CM process.
For cost, the CM activity provides proven techniques for processing changes. It prevents unauthorized changes from occurring without review or approval of the requested changes, identifies all documentation and protects such documents from the incorporation of unauthorized changes, and also assures the immediate update of changed software or software documentation, thus providing for least cost of maintenance and reuse.
The CM activity prevents unauthorized changes, thus helping to avoid schedule slippage. Interface requirements are addressed and documented and provide a readily available trace for impact analysis. By controlling changes and providing good communication, initial requirements are kept up‐to‐date and changes are noted and available for review via timely status accounting records. Requirements must be reviewed during the functional review and physical configuration audit, where requirements are compared against what was produced. Finally, all system and component interface documentation is accounted for and under control, enabling the impact analysis (of change) activity to be performed efficiently.
Risk‐Based Software Estimation
Authors: Fairley Richard 
Published: February 2015

Abstract
Estimation for software projects is, by nature, a high‐risk endeavor because every software project is unique. In contrast to replication in construction and manufacturing, software replication is a trivial process that can be accomplished with very little effort. Every software project thus involves some degree of novelty and innovation. In addition, a software project is rarely conducted under identical circumstances and environmental factors as previous projects. Novelty, innovation, changing circumstances, and different environmental factors make every software project different from every other software project; these factors also make it difficult to provide accurate estimates for software projects. This article describes some widely used estimation methods, points out how estimation risk can be dealt with when using these methods, and provides a format for recording and communicating estimates that emphasizes the risk factors in an estimate.
Knowledge Discovery in Databases
Authors: Dong Guozhu 
Published: February 2015

AbstractKnowledge discovery in databases(KDD), commonly known asdata mining, (In the KDD community, it is common to consider data mining as a step of KDD. This article, is concerned with the identification of knowledge from data. The discovered knowledge is represented as patterns defined in a broad sense, and is required to be novel, potentially useful, and ultimately understandable. Many pattern types have been studied, including classifiers, association rules, and clustering. Many new ones will be introduced in the future, to capture the diverse range of human knowledge and to meet the diverse needs of different applications.It is a complex process to identify novel knowledge patterns from data, requiring different techniques and multiple steps, including data cleaning and preparation, the efficient search of patterns, and the evaluation of the usefulness and novelty of patterns. This process may be iterated many times, where later iterations utilize the insights from earlier iterations. Proper use of background knowledge can greatly improve the quality of the resulting knowledge patterns. A good data mining system architecture is needed to allow coupling with databases and data warehouses, iterative data selection, and interaction between different data mining algorithms and between patterns of different types and so on.The subsequent sections of this article will give an overview of some of the major concepts and techniques of KDD, including a brief introduction and some pointers to representative literature. There are six sections in addition to the introduction, namely, data types and preprocessing, pattern and pattern search space, popular pattern types and search algorithms, understandability and interestingness, concluding remarks, and references.