bluuebunny/crossref_metadata_2025_split huggingface dataset:
ISO
9000
Authors: Radice R. A. 
Published: February 2015

Abstract
The ISO mission is to provide international standardization to facilitate a worldwide exchange of goods and services. ISO standards are used in many areas aside from quality systems; ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing international standards is normally carried out through ISO technical committees. Each country (member body) interested in a subject for whom a technical committee has been established has the right to be represented on that committee. International organizations, both governmental and nongovernmental, in liaison with ISO, also take part in the work. The ISO Council circulates draft international standards adopted by the technical committees to the member bodies for approval before their acceptance as international standards. They are approved in accordance with ISO procedures.
ISO 9000 is a series of generic standards for building, operating, and documenting a quality management system. Aside from software organizations, the series of standards is being applied across manufacturers of various domains, banks, legal firms, health service providers, educational institutions, and chemical processing plants, among others. The ISO 9000 series is composed of five major parts. There are other guidelines in the ISO 9000 series and in related series worth noting and these are discussed. The standards are not intended to prescribe or define procedures, but to give requirements to the supplier. There are many ways to address the procedural elements of a quality management system such as for configuration management, document control, quality records, measurement, and training. The use and concerns involved with ISO 9000 are discussed.
ISO/IEC15504 and Spice
Authors: Rout Terence P. 
Published: February 2015

AbstractThe SPICE Project (Software Process Improvement and Capability dEtermination) is an international collaborative effort to support the development of a new international standard for software process assessment. The project was established by the international committee on software engineering standards, ISO/IEC JTC1/SC7 in January 1993. This followed the recommendations of the committee's Study Group on the Needs and Requirements for a standard for software process assessment. The SPICE Project, when established, had three defined goals:Assist the standardization project in its preparatory stage to develop initial working drafts.Undertake user trials in order to gain early experience data that will form a basis for revision of the published technical reports prior to review as full international standards.Create market awareness and takeup of the evolving standards.ISO/IEC TR 15504 consists of nine parts. The parts of the document set, and their relationships, are shown. Two of the components—parts 2 and 3—are the only normative elements, and contain all of the requirements for process assessment. All other parts contain guidance of one form or another.The reference model defined in ISO 15504‐2 is described as a “two dimensional model of processes and process capability.” It provides a common scale for the expression of the results of process assessment. Each process is defined through a detailed statement of the purpose of the process, together with a list of the expected outcomes of executing the process. An assessment model is a process model designed to support the conduct of process assessment. The assessment model plays a vital role in the conduct of an assessment. It supports the judgment of the assessor in rating process capability, by providing a means for collating the evidence collected during the assessment. The goal of the assessment is to relate the capability of the assessed process to the measurement scheme of the reference model. The assessment model provides indicators related to the reference model; the evidence from the assessed process can be related to these indicators. Result of process assessement use are given.
IST
Program and Software Engineering
Authors: Bus Jacques 
Published: February 2015

Abstract
The IST program is the result of objectives set forth in the Treaty establishing the European Community. Article 163 of the Treaty has the objective of “strengthening the scientific and technological basis of Community industry and encouraging it to become more competitive at international level.” To this end the Community shall carry out various activities, including implementation of research, technological development, and demonstration (RTD), by promoting cooperation with and between undertakings, research centers, and universities. The RTD activities are set out in a multiannual framework program (FP), which is renewed every four years.

The thematic program for
creating a user‐friendly information society
, usually called the Information Society Technologies (IST) program, focuses on information and communication technologies and their application in industry and services and various other fields of societal activity (education, government, healthcare).

The IST program emerged, as a consequence of the converging technologies in the field, from three programs in the ICT field that existed in the fourth Framework program: ACTS (communications technology), Esprit (information technology), and the Telematics Applications program. It is structured around four
key actions
, each focusing on a tightly interrelated set of technologies, issues, and objectives of strategic importance to Europe systems and services for the citizen; new methods of working and electronic commerce; multimedia content and tools; and essential technologies and infrastructure.

Each key action encompasses the complete range of R&D and takeup activities, from long‐term research through demonstration and dissemination projects. Research on technologies and engineering and the future of 1
st
die discessed in this article.
Management Indicators
Authors: Clapp Judith A. 
Published: February 2015

AbstractSoftware management indicators are aids to the management of software projects. By collecting data at all stages of development, a manager can learn to detect early warnings of problems and to control the growth of problems. The data can become the basis for planning long‐term improvements in the productivity and quality achieved by an organization in its software developments.Managers of large software development projects usually have two goals: to develop software systems that will satisfy the customers and to stay within their budgets while doing it. This requires the control of three different, often conflicting, dimensions of the development effort: cost, schedule, and quality.In any large and complex process, whether software development or the manufacture of a high technology product, there is no shortage of measures that can be taken. The real challenge is to select those few measures that can give the most useful information at the lowest cost. One approach advocated by Basili for the use of metrics is to establish goals, enumerate the questions whose answers will indicate if those goals have been met, and then collect the data to compute the metrics that will answer those questions.This article presents descriptions of a set of metrics, the measures they depend on, and how they may serve as indicators.Metrics such as those discussed here must be interpreted to serve as indicators. They may indicate a problem, a minor perturbation, or a change that is already being managed. The article also presents methods of interpreting metrics, along with examples.To use software management indicators requires establishing a metrics program. This can mean a change in the culture of an organization as well as an investment in data collection and in training in the use of metrics. The metrics cannot be effective if the data are not well defined, collected regularly, and reasonably accurate. guidelines are recommended.Although the need for software management indicators is strong, software engineering managers have lagged behind their counterparts in manufacturing in using metrics to control processes and products. It takes an investment of time and money to establish a metrics program in an organization. Even a small number of indicators can be a valuable tool to a manager.
Methodology for Validating Software Product Metrics
Authors: El Emam Khaled , Schneidewind Norman F. 
Published: February 2015

AbstractA large number of software product metrics have been proposed in software engineering. We use the termmetrichere to be consistent with prevailing international standards. Product metrics quantitatively characterize some aspect of the structure of a software product, such as a requirements specification, a design, or source code. They are also commonly collectively known ascomplexity metrics.While many of these metrics are based on good ideas about what is important to measure in software to capture its complexity, it is still necessary to systematically validate them.Two types of validation are recognized internal and external.Internal validationis a theoretical exercise that ensures that the metric is a proper numerical characterization of the property it claims to measure. Demonstrating that a metric measures what it purports to measure is a form of theoretical validation. Typically, one defines the properties of the attribute that is to be measured, for example, the properties of module coupling. Then one demonstrates analytically that the product metric satisfies these properties.External validationinvolves empirically demonstrating that the product nature is associated which is important external metter or an improvement is shown above. Internal and external validation are also commonly referred to astheoreticalandempiricalvalidation respectivelyThis article presents a comprehensive methodology for validating software product metrics. Our focus will be limited toempiricalvalidation.
Modula Languages
Authors: Williams Shirley A. 
Published: February 2015

Abstract
Niklaus Wirth and others at his institution (ETH, Zurich) have a long standing interest in programming languages and their implementation. In the late 1960s Wirth developed Pascal. Subsequent work on a personal workstation led to the systems programming language Modula (Wirth, 1977). Modula was based on Pascal with additional features for using modules and running concurrent processes. The concept of processes was lost when Modula was refined into Modula‐2, the module was retained and formed an important component for software engineers using Modula‐2. Modula‐2 is a procedural programming language that facilitates the development of large programs in a systematic and modular fashion.
Both Modula‐3 and Oberon are languages for the systems programmer, based around the concept of modules and as such allow good software engineering practice to be followed even when programming at a low level.
Module Interconnection Languages
Authors: Prieto‐Diaz Ruben 
Published: February 2015

AbstractModule interconnection languages are considered essential tools in the development of large software systems. The current state of the art in software development environments is due mainly to the pioneering work on module interconnection languages of the late 1970s and early 1980s. Module Interconnection Languages (MILs) provide formal grammer constructs for deciding the various module interconnection specifications required to assemble a complete software system. An MIL code listing is a formal description of the global structure of a software system. Automatic processing of these formal descriptions results in a verification of system integrity and intermodular compatibility.An MIL can be considered a structural design language because it states what the system modules are and how they fit together to implement the system's function. This is architectural design information. MILs are not concerned with what the system does (specification of information), how the major parts of the system are embedded into the organization (analysis of information), or how the individual modules implement their function (detailed design information).The major payoff of using MILs is during system design but substantial payoffs are also obtained during system integration, evolution, and maintenance.
Mutation Testing
Authors: Mathur Aditya P. 
Published: February 2015

AbstractMutation testing, hereafter referred to asmutation, is a technique for software testing. Specifically, it provides a tester with one or more measures of “goodness” of a test set. Such goodness measures are also known astest adequacy criteria. A test set may consist of zero or more test cases, where each test case is a set of values input to the program under test.Several other testing techniques also provide one or more adequacy criteria. For example, path‐based testing methods provide statement coverage as one adequacy criterion. This criterion is satisfied by a test set if each statement in the program under test is executed at least once by one or more of its elements. Mutation differs significantly from path‐oriented testing techniques in terms of the ways in which it examines and manipulates the program syntax. Mutation introduces a simple syntactic change in the program under test. The program thus produced is known as amutant. More than one mutant is usually generated by making various types of simple syntactic changes at different places in the program. The goal of the tester is to find a test case that causes the mutant to generate an output different from that of the program under test thereby distinguishing the mutant from the program. The adequacy of a test setis measured by how many mutants can be distinguished collectively by the tests that belong to.
Neural Networks in Software Engineering
Authors: Partridge Derek 
Published: February 2015

AbstractThe steady buildup of interest, activity, and consequent expertise in software engineering since 1970 has been shadowed by a similar interest and activity in the development of neural networks, although activity in this latter area has tended to ebb and flow quite dramatically. Activity reached a peak in the late 1960s, but died down when analysis of the scope and limitations of the “perceptron” nets revealed that their computational power was restricted to the implementation of only very simple functions. By the end of the 1970s, however, more elaborate nets together with appropriate training algorithms had shown a way round the limitations of the perceptron, and throughout the 1980s computation with such networks has flourished and is still expanding vigorously. The general field of neural network implementations (or simulations) is also termed “connectionism” or “parallel distributed processing” (PDP), and even “brain modeling,” but this particular branch of the technology does not concern us here.A neural network is an information processing system that is composed of a collection of similar primitive processing units, or nodes, interconnected by means of explicit information passing links. Typically, each processing unit can accumulate “activity” values received on its incoming links; it then thresholds (or “squashes”) the total activity; and may then pass a computed activity value to each of its outgoing links. Individual links have an associated “weight” (usually a real number) that is used to modify any activity value that they pass along from one unit to another.A number of characteristics of neural net technology set it apart as a novel implementation strategy for software engineering and are duscussed, hue.
Object‐Oriented Design
Authors: Berard Edward V. 
Published: February 2015

AbstractWork on what was to become “structured design” began in the early 1960s. Structured design, as a well‐defined and named concept, did not achieve appreciable visibility until the publication of an article in theIBM Systems Journalin 1974. There is more than one way to accomplish a “structured design.”Like structured design, the termobject‐oriented design(OOD) means different things to different people. For example, OOD has been used to imply such things asThe design of individual objects, and/or the design of the individual methods contained in those objectsThe design of an inheritance (specialization) hierarchy of objectsThe design of a library of reusable objectsThe process of specifying and coding of an entire object‐oriented applicationThe term nonformal is used to describe approaches to OOD that are not well defined, step‐by‐step, or repeatable, such as those that emphasize the design of individual objects, specialization (inheritance) hierarchies, and libraries of objects. A survey of such approaches indicates that there may indeed be some repeatable rigor (and some sage advice) given for these approaches, but they are severely lacking when it comes to defining the software architecture of large and critical systems. Different approaches, techniques and experienced with object oriented design are discussed here.
Object‐Oriented Development
Authors: Northrop Linda M. 
Published: February 2015

Abstract
The object‐oriented model for software development has become exceedingly attractive as the best answer to the increasingly complex needs of the software development community. What was first viewed by many as a research curiosity and an impractical approach to industrial strength software is now being enthusiastically embraced. Object‐oriented versions of most languages have been or are being developed. Numerous object‐oriented methodologies have been proposed. Conferences, seminars, and courses on object‐oriented topics are extremely popular. New journals and countless special issues of both academic and professional journals have been devoted to the subject. Contracts for software development that specify object‐oriented techniques and languages currently have a competitive edge. Object‐oriented development is to the 1990s what structured development was to the 1970s, and the object‐oriented movement is still accelerating.
The object‐oriented model is more than a collection of new languages; it is a new way of thinking about what it means to compute and about how information can be structured. In the object‐oriented model, systems are viewed as cooperating objects that encapsulate structure and behavior and that belong to classes which are hierarchically constructed. All functionality is achieved by messages that are passed to and from objects. The object‐oriented model can be viewed as a conceptual framework with the following elements: abstraction, encapsulation, modularity, hierarchy, typing, concurrence, persistence, reusability, and extensibility. Programming and the use of object‐oriented language are discussed. Object‐oriented transition and the future and also discussed.
OMG/CORBA: An Object‐Oriented Middleware
Authors: Emmerich Wolfgang 
Published: February 2015

AbstractIn this short article, we give a concise overview of the distributed object technology supported by the mature part of the OMG/CORBA standard that is widely implemented by CORBA products. We discuss the object model and its availability in the OMG interface definition language, the different programming language bindings, the object management architecture, and the components that are involved when an object request is made. Finally, we give a brief overview of the different object services that have been accepted so far.OMG/CORBA is just a standard, but there are many products implementing that standard.
Software Performance Engineering
Authors: Smith Connie U. 
Published: February 2015

AbstractSoftware performance engineering(SPE) is a method for constructing software systems to meet performance objectives. The process begins early in the software life cycle and uses quantitative methods to identify satisfactory combinations of requirements and designs, and to eliminate those that are likely to have unacceptable performance, before developers begin implementation. SPE continues through the detailed design, coding, and testing stages to predict and manage the performance of the evolving software, and to monitor and report actual performance against specifications and predictions. SPE methods cover performance data collection, quantitative analysis techniques, prediction strategies, management of uncertainties, data presentation and tracking, model verification and validation, critical success factors, and performance design principles.In this article,performancerefers to the response time or throughput as seen by the users. For real‐time, orreactive, systems, this is the time required to respond to events. Reactive systems must meet performance objectives to be correct. Other software has less stringent requirements, but responsiveness limits the amount of work processed, so it determines a system's effectiveness and the productivity of its users.This article first covers the evolution of SPE then it gives an overview of the SPE process and the SPE methods. It presents the general principles for performance‐oriented design, then it introduces the quantitative techniques for predicting and analyzing performance. The SPE techniques used throughout the software life cycle follow. Finally, the conclusion reviews the status and future of SPE.
Problem Statement Language/Problem Statement Analyzer
Authors: Sayani Hasan H. 
Published: February 2015

Abstract
The Problem Statement Language (PSL) and the Problem Statement Analyzer (PSA) were first described in 1971. PSL™ was introduced in that paper as the equivalent of a blueprinting language for an information systems “factory,” and PSA™ as the software to support its usage. This first version (1) was used mainly by the sponsors of the Information Systems Design and Optimization System (ISDOS) project at the University of Michigan. A more widely introduced version, 2. 1, was described inter.
The goal this article is to describe PSL/PSA, to lend a perspective to the chances that have taken place in the PSL/PSA system over 15 years, to examine its acceptance by the information systems community, to portray a scenario of usage, and to comment on the trends in the industry that not only affect PSL/PSA but also similar productivity tools that are now becoming available in the industry.
PSL/PSA is sometimes dismissed as showing its age, although the counter could be that it has matured with experience; it has improved its user interface and there is a great deal of auxiliary software available to use with it. PSL/PSA has obvious potential as a repository and we look forward to widened interest in its use.
Procedural Languages
Authors: Ghezzi Carlo 
Published: February 2015

Abstract
This article addresses procedural, or imperative, programming languages, i.e., languages that focus the programmer's attention on the definition of algorithms, through the composition of individual commands or statements, representing elementary computational steps combined into larger units. Fine‐grain composition is achieved by means of control structures, such as sequencing, selection, and iteration; and coarse‐grain composition, by encapsulating a composite statement within a program unit, such as blocks, functions, and procedures.
This article provides a historical view of imperative languages and starts by providing a definition of imperative programming languages. It then discusses how the development of programming languages has evolved from machine dependence to a greater orientation to the humans involved in software production, i.e., toward higher levels of abstraction. Early high level imperative languages are covered, and data, control, and programming‐in‐the‐large features are discussed. Modern high level imperative languages are examined, and types and newer in‐the‐large issues (such as exception handling, concurrency and distribution, and object‐oriented decomposition) are presented.